Która wersja oprogramowania jest najbardziej „poprawna” i „działająca”? Jeśli system pamięci masowej gwarantuje odporność na awarie na poziomie 99,9999%, czy oznacza to, że będzie działał nieprzerwanie nawet bez aktualizacji oprogramowania? Czy wręcz przeciwnie, aby uzyskać maksymalną odporność na awarie, należy zawsze instalować najnowsze oprogramowanie? Postaramy się odpowiedzieć na te pytania bazując na naszym doświadczeniu.
Małe wprowadzenie
Wszyscy rozumiemy, że każda wersja oprogramowania, czy to systemu operacyjnego, czy sterownika urządzenia, często zawiera defekty/błędy i inne „funkcje”, które mogą „pojawić się” do końca okresu użytkowania sprzętu lub „otwarte” tylko pod pewnymi warunkami. Liczba i znaczenie takich niuansów zależy od złożoności (funkcjonalności) oprogramowania i jakości testów podczas jego rozwoju.
Często użytkownicy pozostają na „fabrycznym oprogramowaniu” (słynne „działa, więc nie majstruj z tym”) lub zawsze instaluj najnowszą wersję (w ich rozumieniu najnowsza oznacza najbardziej działającą). Stosujemy inne podejście – sprawdzamy informacje o wydaniu pod kątem wszystkiego, co zostało użyte sprzętu i starannie wybrać odpowiednie oprogramowanie sprzętowe dla każdego elementu wyposażenia.
Doszliśmy do tego wniosku, jak mówią, z doświadczeniem. Na naszym przykładzie działania opowiemy Ci, dlaczego obiecana niezawodność systemów pamięci masowej na poziomie 99,9999% nic nie znaczy, jeśli nie będziesz na bieżąco monitorować aktualizacji i opisów oprogramowania. Nasza obudowa jest odpowiednia dla użytkowników systemów pamięci masowej dowolnego dostawcy, ponieważ podobna sytuacja może wystąpić w przypadku sprzętu dowolnego producenta.
Wybór nowego systemu przechowywania
Pod koniec ubiegłego roku do naszej infrastruktury dołączył ciekawy system przechowywania danych: młodszy model z linii IBM FlashSystem 5000, który w momencie zakupu nosił nazwę Storwize V5010e. Teraz jest sprzedawany pod nazwą FlashSystem 5010, ale w rzeczywistości jest to ta sama baza sprzętowa z tym samym Spectrum Virtualize w środku.
Nawiasem mówiąc, główną różnicą między IBM FlashSystem jest obecność ujednoliconego systemu zarządzania. W przypadku modeli młodszej serii praktycznie nie różni się od modeli bardziej produktywnych. Wybór konkretnego modelu zapewnia jedynie odpowiednią bazę sprzętową, której cechy pozwalają na wykorzystanie tej czy innej funkcjonalności lub zapewniają wyższy poziom skalowalności. Oprogramowanie identyfikuje sprzęt i zapewnia niezbędną i wystarczającą funkcjonalność dla tej platformy.
IBM FlashSystem 5010
Krótko o naszym modelu 5010. Jest to podstawowy system przechowywania bloków z dwoma kontrolerami. Obsługuje dyski NLSAS, SAS, SSD. Umieszczenie NVMe nie jest w nim dostępne, ponieważ ten model pamięci masowej jest przystosowany do rozwiązywania problemów, które nie wymagają wydajności dysków NVMe.
System przechowywania został zakupiony w celu przechowywania informacji archiwalnych lub danych, do których nie ma częstego dostępu. Dlatego też wystarczył nam standardowy zestaw jego funkcjonalności: Tiering (Easy Tier), Thin Provision. Wydajność na dyskach NLSAS na poziomie 1000-2000 IOPS również była dla nas całkiem zadowalająca.
Nasze doświadczenie - jak nie zaktualizowaliśmy oprogramowania na czas
Teraz o samej aktualizacji oprogramowania. W momencie zakupu system posiadał już nieco przestarzałą wersję oprogramowania Spectrum Virtualize, a mianowicie: 8.2.1.3.
Przestudiowaliśmy opisy oprogramowania sprzętowego i zaplanowaliśmy aktualizację 8.2.1.9. Gdybyśmy byli trochę bardziej wydajni, ten artykuł by nie powstał – błąd nie wystąpiłby w nowszym oprogramowaniu. Jednak z pewnych powodów aktualizacja tego systemu została przełożona.
W rezultacie niewielkie opóźnienie aktualizacji doprowadziło do wyjątkowo nieprzyjemnego obrazu, jak w opisie pod linkiem: .
Tak, w oprogramowaniu tej wersji istotny był tzw. APAR (Authorized Program Analysis Report) HU02104. Wygląda to następująco. Pod obciążeniem w pewnych okolicznościach pamięć podręczna zaczyna się przepełniać, po czym system przechodzi w tryb ochronny, w którym wyłącza wejścia/wyjścia dla puli. W naszym przypadku wyglądało to na odłączenie 3 dysków dla grupy RAID w trybie RAID 6. Odłączenie następuje przez 6 minut. Następnie przywracany jest dostęp do woluminów w puli.
Jeśli ktoś nie jest zaznajomiony ze strukturą i nazewnictwem jednostek logicznych w kontekście IBM Spectrum Virtualize, teraz pokrótce wyjaśnię.
Struktura elementów logicznych systemu przechowywania
Dyski są zebrane w grupy zwane MDisk (Dysk Zarządzany). MDisk może być klasycznym RAID (0,1,10,5,6) lub wirtualnym - DRAID (Distributed RAID). Użycie DRAID pozwala zwiększyć wydajność macierzy, ponieważ... Wszystkie dyski w grupie zostaną wykorzystane, a czas odbudowy zostanie skrócony, ponieważ konieczne będzie przywrócenie tylko niektórych bloków, a nie wszystkich danych z uszkodzonego dysku.
Dystrybucja bloków danych na dyskach w przypadku korzystania z rozproszonej macierzy RAID (DRAID) w trybie RAID-5.
Ten diagram pokazuje logikę działania odbudowy DRAID w przypadku awarii jednego dysku:
Logika odbudowy DRAID w przypadku awarii jednego dysku
Następnie jeden lub więcej dysków MDisk tworzy tak zwaną pulę. W ramach tej samej puli nie zaleca się używania MDisk z różnymi poziomami RAID/DRAID na dyskach tego samego typu. Nie będziemy się w to zagłębiać, bo... planujemy omówić to w jednym z poniższych artykułów. Cóż, w rzeczywistości Pula jest podzielona na woluminy, które są prezentowane za pomocą tego lub innego protokołu dostępu blokowego do hostów.
Zatem my, w wyniku sytuacji opisanej w APAR HU02104, z powodu awarii logicznej trzech dysków, MDisk przestał działać, co z kolei skutkowało awarią Puli i odpowiadających jej Woluminów.
Ponieważ systemy te są dość inteligentne, można je podłączyć do opartego na chmurze systemu monitorowania IBM Storage Insights, który w przypadku wystąpienia problemu automatycznie wysyła zgłoszenie serwisowe do wsparcia IBM. Tworzona jest aplikacja, a specjaliści IBM zdalnie przeprowadzają diagnostykę i kontaktują się z użytkownikiem systemu.
Dzięki temu problem został rozwiązany dość szybko i otrzymano szybką rekomendację od działu wsparcia, aby zaktualizować nasz system do wcześniej wybranego oprogramowania 8.2.1.9, które w tamtym czasie było już naprawione. Potwierdza .
Wyniki i nasze rekomendacje
Jak to się mówi: „wszystko dobre, co się dobrze kończy”. Błąd w oprogramowaniu nie spowodował poważnych problemów - serwery zostały przywrócone możliwie najszybciej i bez utraty danych. Niektórzy klienci musieli ponownie uruchamiać maszyny wirtualne, ale generalnie byliśmy przygotowani na więcej negatywnych konsekwencji, ponieważ codziennie wykonujemy kopie zapasowe wszystkich elementów infrastruktury i maszyn klienckich.
Otrzymaliśmy potwierdzenie, że nawet niezawodne systemy z obiecaną dostępnością na poziomie 99,9999% wymagają uwagi i terminowej konserwacji. Na podstawie sytuacji wyciągnęliśmy dla siebie szereg wniosków i dzielimy się naszymi rekomendacjami:
-
Konieczne jest monitorowanie wydawania aktualizacji, zapoznawanie się z informacjami o wydaniu pod kątem poprawek potencjalnie krytycznych problemów i terminowe przeprowadzanie zaplanowanych aktualizacji.
Jest to kwestia organizacyjna i wręcz dość oczywista, na której, jak się wydaje, nie warto się skupiać. Jednak na tym „równym terenie” dość łatwo można się potknąć. Właściwie to właśnie ten moment dodał kłopoty opisane powyżej. Przy opracowywaniu regulaminu aktualizacji należy zachować szczególną ostrożność i nie mniej uważnie monitorować jego przestrzeganie. Ten punkt odnosi się bardziej do pojęcia „dyscypliny”.
-
Zawsze lepiej jest mieć w systemie najnowszą wersję oprogramowania. Co więcej, obecny nie jest tym, który ma większe oznaczenie numeryczne, ale raczej tym z późniejszą datą premiery.
Na przykład IBM aktualizuje co najmniej dwie wersje oprogramowania swoich systemów pamięci masowej. W chwili pisania tego tekstu są to 8.2 i 8.3. Aktualizacje dla wersji 8.2 wychodzą wcześniej. Podobna aktualizacja dla wersji 8.3 jest zwykle wydawana z niewielkim opóźnieniem.
Wersja 8.3 posiada szereg zalet funkcjonalnych, na przykład możliwość rozbudowy MDisk (w trybie DRAID) poprzez dodanie jednego lub większej liczby nowych dysków (ta funkcja pojawiła się od wersji 8.3.1). Jest to dość podstawowa funkcjonalność, ale w 8.2 niestety nie ma takiej funkcji.
-
Jeżeli z jakiegoś powodu aktualizacja nie jest możliwa, wówczas dla wersji oprogramowania Spectrum Virtualize wcześniejszych niż 8.2.1.9 i 8.3.1.0 (w przypadku których występuje opisany powyżej błąd) w celu zmniejszenia ryzyka jego wystąpienia, dział wsparcia technicznego IBM zaleca ograniczające wydajność systemu na poziomie puli, jak pokazano na poniższym rysunku (zdjęcie zostało zrobione w zrusyfikowanej wersji GUI). Wartość 10000 IOPS jest pokazana jako przykład i jest wybierana zgodnie z charakterystyką Twojego systemu.
Ograniczanie wydajności pamięci masowej IBM
-
Konieczne jest prawidłowe obliczenie obciążenia systemów magazynowania i unikanie przeciążeń. Możesz w tym celu skorzystać albo z narzędzia IBM (jeśli masz do niego dostęp), albo z pomocy partnerów, albo zasobów stron trzecich. Konieczne jest zrozumienie profilu obciążenia systemu pamięci masowej, ponieważ Wydajność w MB/s i IOPS różni się znacznie w zależności od co najmniej następujących parametrów:
-
rodzaj operacji: odczyt lub zapis,
-
rozmiar bloku operacyjnego,
-
procent operacji odczytu i zapisu w całym strumieniu we/wy.
Na szybkość operacji wpływa także sposób odczytywania bloków danych: sekwencyjnie lub w kolejności losowej. Podczas wykonywania wielu operacji dostępu do danych po stronie aplikacji istnieje koncepcja operacji zależnych. Warto to również wziąć pod uwagę. Wszystko to może pomóc w zobaczeniu całości danych z liczników wydajności systemu operacyjnego, systemu pamięci masowej, serwerów/hiperwizorów, a także w zrozumieniu funkcji operacyjnych aplikacji, systemów DBMS i innych „konsumentów” zasobów dyskowych.
-
-
I na koniec, upewnij się, że kopie zapasowe są aktualne i działające. Harmonogram tworzenia kopii zapasowych powinien być skonfigurowany w oparciu o akceptowalne dla firmy wartości RPO, a okresowe kontrole integralności kopii zapasowych powinny być weryfikowane (sporo dostawców oprogramowania do tworzenia kopii zapasowych ma wdrożoną w swoich produktach automatyczną weryfikację), aby zapewnić akceptowalną wartość RTO.
Dziękuję za przeczytanie do końca.
Jesteśmy gotowi odpowiedzieć na Twoje pytania i uwagi w komentarzach. Również, w ramach którego regularnie organizujemy promocje (rabaty na IaaS i upominki za kody promocyjne do 100% na VPS), piszemy ciekawe newsy i ogłaszamy nowe artykuły na blogu Habr.
Źródło: www.habr.com