Która wersja oprogramowania jest "najlepsza" i "najbardziej funkcjonalna"? Jeśli macierz dyskowa gwarantuje niezawodność na poziomie 99,9999%, czy oznacza to, że będzie pracować bez zakłóceń nawet bez aktualizacji oprogramowania? A może wręcz przeciwnie - dla uzyskania maksymalnej niezawodności należy zawsze instalować najnowszą wersję firmware'u? Postaramy się odpowiedzieć na te pytania, opierając się na naszym doświadczeniu.
Krótkie wprowadzenie
Wszyscy rozumiemy, że w każdej wersji oprogramowania, czy to systemu operacyjnego, czy sterownika dla jakiegoś urządzenia, często występują niedociągnięcia/błędy oraz inne „cechy”, które mogą, ale nie muszą „ujawniać się” aż do końca życia sprzętu, a także mogą „ujawnić się” tylko w określonych warunkach. Liczba i znaczenie takich szczegółów zależy od złożoności (funkcjonalności) oprogramowania oraz jakości jego testowania podczas rozwoju.
Często użytkownicy pozostają przy „firmware fabrycznym” (słynne - „działa, więc nie ruszaj”) lub zawsze instalują najnowszą wersję (w ich rozumieniu najnowsza oznacza najbardziej funkcjonalną). My stosujemy inne podejście - analizujemy noty wydania dla całego używanego sprzętu i starannie wybieramy odpowiednie oprogramowanie dla każdego urządzenia.
Do takiego wniosku doszliśmy, można powiedzieć, z doświadczeniem. Na naszym przykładzie eksploatacji opowiemy, dlaczego obiecywana niezawodność 99,9999% macierzy dyskowej nic nie znaczy, jeśli nie będziesz na bieżąco śledzić aktualizacji i opisu oprogramowania. Nasz przypadek nadaje się dla użytkowników macierzy dyskowych dowolnego dostawcy, ponieważ podobna sytuacja może wystąpić z sprzętem każdego producenta.
Wybór nowego systemu przechowywania danych
Pod koniec ubiegłego roku nasza infrastruktura wzbogaciła się o interesujący system przechowywania danych: młodszy model z serii IBM FlashSystem 5000, który w momencie zakupu był znany jako Storwize V5010e. Obecnie sprzedawany jest pod nazwą FlashSystem 5010, jednak w rzeczywistości to ta sama baza sprzętowa z tym samym Spectrum Virtualize wewnątrz.
Jednolita systema zarządzania to, nawiasem mówiąc, podstawowa różnica IBM FlashSystem. W modelach z serii podstawowej prawie nie różni się ona od modeli bardziej wydajnych. Wybór określonego modelu daje jedynie odpowiednią bazę sprzętową, której parametry umożliwiają korzystanie z określonego funkcjonalności lub zapewniają wyższy poziom skalowalności. Oprogramowanie identyfikuje część sprzętową i zapewnia niezbędną oraz wystarczającą funkcjonalność dla tej platformy.
IBM FlashSystem 5010
Krótko o naszym modelu 5010. Jest to dwu kontrolerowy blokowy system przechowywania danych poziomu podstawowego. Potrafi pomieścić dyski NLSAS, SAS oraz SSD. Umieszczenie NVMe nie jest możliwe, ponieważ ten model SAN jest pozycjonowany do rozwiązywania zadań, które nie wymagają wydajności dysków NVMe.
SAN została zakupiona do przechowywania informacji archiwalnych lub danych, do których nie ma częstego dostępu. Dlatego standardowy zestaw jej funkcjonalności: tiering (Easy Tier), Thin Provision był dla nas wystarczający. Wydajność na dyskach NLSAS na poziomie 1000-2000 IOPS również nas zadowalała.
Nasze doświadczenie — jak nie zaktualizowaliśmy oprogramowania na czas
Teraz przechodząc do samej aktualizacji oprogramowania. W momencie zakupu system miał już nieco przestarzałą wersję oprogramowania Spectrum Virtualize, a mianowicie, 8.2.1.3.
Zbadaliśmy opisy firmware’u i zaplanowaliśmy aktualizację do 8.2.1.9. Gdybyśmy byli nieco bardziej zwinni, nie byłoby tego artykułu — na nowszym oprogramowaniu ten błąd by się nie pojawił. Niemniej jednak z określonych powodów aktualizacja tego systemu została odłożona.
W rezultacie niewielkie opóźnienie w aktualizacji doprowadziło do niezwykle nieprzyjemnego obrazu, jak opisano w podanym linku: .
Tak, w firmware tej wersji był актуальный tzw. APAR (Authorized Program Analysis Report) HU02104. Objawia się on w sposób następujący. Pod obciążeniem, w określonych okolicznościach, zaczyna przepełniać się pamięć podręczna, a następnie system przechodzi w tryb ochrony, w którym wyłącza wejście-wyjście dla puli (Pool). W naszym przypadku wyglądało to jak odłączenie 3 dysków dla grupy RAID w trybie RAID 6. Odłączenie trwa 6 minut. Następnie dostęp do wolumenów w puli jest przywracany.
Jeśli ktoś nie jest zaznajomiony ze strukturą i nazewnictwem logicznych jednostek w kontekście IBM Spectrum Virtualize, krótko o tym opowiem.
Struktura elementów logicznych STHD
Dyski są grupowane w tzw. MDisk (Managed Disk). MDisk może przedstawiać klasyczny RAID (0,1,10,5,6) lub wirtualizowany – DRAID (Distributed RAID). Użycie DRAID pozwala zwiększyć wydajność macierzy, ponieważ będą wykorzystywane wszystkie dyski grupy, i skrócić czas odbudowy dzięki temu, że trzeba będzie odtworzyć tylko określone bloki, a nie wszystkie dane z uszkodzonego dysku.
Rozmieszczenie bloków danych na dyskach przy użyciu Distributed RAID (DRAID) w trybie RAID-5.
A ten schemat pokazuje logikę pracy odbudowy DRAID w przypadku awarii jednego dysku:
Logika pracy odbudowy DRAID przy awarii jednego dysku
Następnie jeden lub kilka MDisk tworzy tzw. Pool. W obrębie jednego poola nie zaleca się używania MDisk z różnymi poziomami RAID/DRAID na dyskach tego samego typu. Nie będziemy się w to zbytnio zagłębiać, ponieważ planujemy opisać to w ramach jednego z kolejnych artykułów. A zatem Pool dzieli się na Tomy (Volumes), które są prezentowane za pomocą danego protokołu dostępu blokowego w kierunku hostów.
Jak więc widać, w wyniku wystąpienia sytuacji opisanej w APAR HU02104, z powodu logicznej awarii trzech dysków, przestał być operacyjny MDisk, co z kolei spowodowało awarię poola i odpowiednich Tomów.
Ponieważ te systemy są dość "inteligentne", można je podłączyć do chmurowego systemu monitorowania IBM Storage Insights, który automatycznie, w przypadku wystąpienia awarii, wysyła zgłoszenie do wsparcia technicznego IBM. Tworzy się zgłoszenie, a specjaliści IBM przeprowadzają zdalną diagnostykę i kontaktują się z użytkownikiem systemu.
Dzięki temu problem został rozwiązany stosunkowo szybko, a od wsparcia technicznego otrzymaliśmy szybką rekomendację dotyczącą aktualizacji naszego systemu do wybranej wcześniej wersji oprogramowania 8.2.1.9, w której ten problem był już naprawiony. Potwierdza to .
Podsumowanie i nasze rekomendacje
Jak mówi przysłowie: „dobrze to, co dobrze się kończy”. Błąd w oprogramowaniu nie spowodował poważnych problemów – praca serwerów została przywrócona w krótkim czasie i bez utraty danych. U niektórych klientów konieczne było ponowne uruchomienie maszyn wirtualnych, ale generalnie byliśmy gotowi na bardziej negatywne konsekwencje, ponieważ codziennie wykonujemy kopie zapasowe wszystkich elementów infrastruktury i maszyn klientów.
Otrzymaliśmy potwierdzenie, że nawet niezawodne systemy z obiecanym czasem dostępności na poziomie 99,9999% wymagają uwagi i terminowej konserwacji. W związku z sytuacją wyciągnęliśmy kilka wniosków i dzielimy się naszymi rekomendacjami:
Należy bezwzględnie śledzić wydania aktualizacji, zapoznawać się z informacjami o wersjach w celu usunięcia potencjalnie krytycznych problemów oraz terminowo przeprowadzać zaplanowane aktualizacje.
To organizacyjny i dość oczywisty aspekt, na którym, zdawałoby się, nie warto skupiać uwagi. Jednak na tym „głównym punkcie” można dość łatwo się potknąć. To właśnie ten aspekt spowodował opisane wyżej problemy. Podchodźcie do sporządzania regulaminu aktualizacji z dużą uwagą i równie uważnie śledźcie jego przestrzeganie. Ten punkt bardziej odnosi się do pojęcia „dyscyplina”.
Zawsze lepiej trzymać system z aktualną wersją oprogramowania. Przy czym aktualna – to nie ta, która ma wyższą numerację, ale właśnie ta z późniejszą datą wydania.
Na przykład IBM dla swoich systemów przechowywania danych utrzymuje na bieżąco przynajmniej dwa wydania oprogramowania. W momencie pisania tego artykułu są to wersje 8.2 i 8.3. Aktualizacje dla 8.2 wychodzą wcześniej. Następnie z niewielkim opóźnieniem zwykle wychodzi odpowiednia aktualizacja dla 8.3.
Wydanie 8.3 ma szereg funkcjonalnych zalet, na przykład możliwość rozszerzenia MDisk (w trybie DRAID) o dodanie jednego lub więcej nowych dysków (taka możliwość pojawiła się od wersji 8.3.1). To dość podstawowa funkcjonalność, ale w 8.2 niestety takiej opcji nie ma.
Jeżeli nie ma możliwości aktualizacji z jakichkolwiek powodów, to dla wersji oprogramowania Spectrum Virtualize, wcześniejszych od wersji 8.2.1.9 i 8.3.1.0 (gdzie opisany powyżej błąd jest aktualny), w celu zredukowania ryzyka jego wystąpienia, wsparcie techniczne IBM zaleca ograniczenie wydajności systemu na poziomie puli, jak zaprezentowano na rysunku poniżej (zrzut ekranu został wykonany w polskiej wersji GUI). Wartość 10000 IOPS jest podana jako przykład i dobierana zgodnie z charakterystyką Twojego systemu.
Ograniczenie wydajności macierzy IBM
Należy prawidłowo obliczać obciążenie systemów magazynowania i unikać przeciążenia. W tym celu można skorzystać lub z narzędzia do szacowania IBM (jeśli jest dostępne), udziału partnerów, lub zasobów zewnętrznych. Konieczne jest również zrozumienie profilu obciążenia na systemie magazynowania, ponieważ wydajność w MB/s i IOPS znacznie różni się w zależności co najmniej od następujących parametrów:
typ operacji: odczyt lub zapis,
rozmiar bloku operacji,
procentowe proporcje operacji odczytu i zapisu w całkowitym strumieniu wejścia-wyjścia.
Ponadto, na prędkość wykonywania operacji wpływa również sposób odczytywania bloków danych: sekwencyjnie czy losowo. Przy wykonywaniu wielu operacji dostępu do danych na poziomie aplikacji istnieje pojęcie operacji zależnych. To także warto uwzględnić. Wszystko to może pomóc zobaczyć zestawienie danych ze wskaźników wydajności systemu operacyjnego, systemu magazynowania, serwerów/hypervisorów, a także zrozumienie specyfiki działania aplikacji, baz danych i innych "konsumentów" zasobów dyskowych.
Na koniec, należy zawsze mieć kopie zapasowe w aktualnym i działającym stanie. Harmonogram tworzenia kopii zapasowych należy ustawiać na podstawie akceptowalnych wartości RPO dla biznesu i okresowo sprawdzać integralność kopii zapasowych (dość wielu producentów oprogramowania do tworzenia kopii zapasowych zrealizowało w swoich produktach automatyczną kontrolę) w celu zapewnienia akceptowalnej wartości RTO.
Dziękujemy, że dotarłeś do końca.
Jesteśmy gotowi odpowiedzieć na Twoje pytania i uwagi w komentarzach. Również, w którym regularnie organizujemy akcje (zniżki na IaaS i losowania kodów promocyjnych do 100% na VPS), piszemy ciekawe wiadomości i zapowiadamy nowe artykuły na blogu Habr.
Źródło: habr.com
