Jak byś się czuł, gdyby pewnego pięknego letniego dnia centrum danych z Twoim sprzętem wyglądało tak?
Cześć wszystkim! Nazywam się Dmitry Samsonov, pracuję jako wiodący administrator systemu w „" Na zdjęciu jedno z czterech data center, w którym zainstalowany jest sprzęt obsługujący nasz projekt. Za tymi murami kryje się około 4 tysięcy urządzeń: serwerów, systemów przechowywania danych, sprzętu sieciowego itp. - prawie ⅓ całego naszego wyposażenia.
Większość serwerów to Linux. Istnieje również kilkadziesiąt serwerów na platformie Windows (MS SQL) - nasze dziedzictwo, z którego od wielu lat systematycznie porzucamy.
I tak 5 czerwca 2019 roku o godzinie 14:35 inżynierowie w jednym z naszych centrów danych zgłosili alarm pożarowy.
Odmowa
14:45. Drobne incydenty związane z dymem w centrach danych są częstsze niż myślisz. Wskaźniki wewnątrz hal były w normie, więc nasza pierwsza reakcja była w miarę spokojna: wprowadzono zakaz pracy na produkcji, czyli wszelkich zmian konfiguracyjnych, wypuszczania nowych wersji itp., za wyjątkiem prac związanych z naprawianiem czegoś.
Złość
Czy kiedykolwiek próbowałeś dowiedzieć się od strażaków, gdzie dokładnie pojawił się pożar na dachu, lub samodzielnie wejść na płonący dach, aby ocenić sytuację? Jaki będzie stopień zaufania do informacji otrzymanych za pośrednictwem pięciu osób?
14: 50. Otrzymano informację, że ogień zbliża się do układu chłodzenia. Ale czy nadejdzie? Dyżurujący administrator systemu usuwa ruch zewnętrzny z frontów tego centrum danych.
W chwili obecnej fronty wszystkich naszych usług są zduplikowane w trzech centrach danych, stosowane jest równoważenie na poziomie DNS, co pozwala nam na usuwanie adresów jednego centrum danych z DNS, chroniąc tym samym użytkowników przed potencjalnymi problemami z dostępem do usług . Jeżeli w data center wystąpiły już problemy, automatycznie opuszcza rotację. Więcej możesz przeczytać tutaj:
Pożar na razie w żaden sposób nas nie dotknął – ani użytkownicy, ani sprzęt nie ucierpiał. Czy to wypadek? Pierwsza część dokumentu „Plan działania w razie wypadku” definiuje pojęcie „wypadku”, a kończy się w następujący sposób:
«Jeśli są jakiekolwiek wątpliwości, czy doszło do wypadku, czy nie, to jest to wypadek!»
14:53. Wyznacza się koordynatora ds. sytuacji nadzwyczajnych.
Koordynator to osoba, która kontroluje komunikację pomiędzy wszystkimi uczestnikami, ocenia skalę wypadku, korzysta z Planu Działań Awaryjnych, pozyskuje niezbędny personel, monitoruje zakończenie napraw, a co najważniejsze, deleguje wszelkie zadania. Inaczej mówiąc, jest to osoba zarządzająca całym procesem reagowania kryzysowego.
Handlowanie
15:01. Zaczynamy wyłączać serwery niezwiązane z produkcją.
15:03. Prawidłowo wyłączamy wszystkie zarezerwowane usługi.
Obejmuje to nie tylko fronty (do których użytkownicy nie mają już dostępu) i ich usługi pomocnicze (logika biznesowa, pamięci podręczne itp.), ale także różne bazy danych o współczynniku replikacji 2 lub większym (, , , itp.).
15: 06. Otrzymano informację, że pożar zagraża jednej z hal centrum danych. Nie mamy sprzętu w tej sali, jednak fakt, że ogień może przedostać się z dachu na hale, znacznie zmienia obraz tego, co się dzieje.
(Później okazało się, że nie było fizycznego zagrożenia dla hali, gdyż była ona hermetycznie oddzielona od dachu. Zagrożenie dotyczyło jedynie systemu chłodzenia tej hali.)
15:07. Umożliwiamy wykonywanie poleceń na serwerach w trybie przyspieszonym bez dodatkowych kontroli ().
15:08. Temperatura w salach mieści się w normalnych granicach.
15: 12. Odnotowano wzrost temperatury w halach.
15:13. Ponad połowa serwerów w centrum danych jest wyłączona. Kontynuujmy.
15:16. Podjęto decyzję o wyłączeniu całego sprzętu.
15:21. Zaczynamy wyłączać zasilanie serwerów bezstanowych bez prawidłowego zamykania aplikacji i systemu operacyjnego.
15:23. Przydzielana jest grupa osób odpowiedzialnych za MS SQL (jest ich niewiele, zależność usług od nich nie jest duża, ale procedura przywracania funkcjonalności trwa dłużej i jest bardziej skomplikowana niż np. Cassandra).
Depresja
15: 25. Otrzymano informację o wyłączeniu prądu w czterech z 16 hal (nr 6, 7, 8, 9). Nasz sprzęt znajduje się w halach 7 i 8. Brak informacji o naszych dwóch halach (nr 1 i 3).
Zwykle podczas pożarów zasilanie jest natychmiast wyłączane, jednak w tym przypadku, dzięki skoordynowanej pracy strażaków i personelu technicznego centrum danych, nie zostało ono wyłączone wszędzie i nie od razu, ale w razie potrzeby.
(Później odkryto, że w halach 8 i 9 nie wyłączono prądu.)
15:28. Rozpoczynamy wdrażanie baz danych MS SQL z kopii zapasowych w innych centrach danych.
Jak długo to zajmie? Czy przepustowość sieci jest wystarczająca na całej trasie?
15: 37. Odnotowano wyłączenie niektórych części sieci.
Zarządzanie i sieć produkcyjna są od siebie fizycznie odizolowane. Jeśli sieć produkcyjna jest dostępna, możesz udać się do serwera, zatrzymać aplikację i wyłączyć system operacyjny. Jeśli nie jest dostępny, możesz zalogować się przez IPMI, zatrzymać aplikację i wyłączyć system operacyjny. Jeśli nie ma żadnej sieci, nie możesz nic zrobić. „Dzięki, Cap!”, pomyślisz.
„I ogólnie jest tam dużo zamieszania” – możesz także pomyśleć.
Rzecz w tym, że serwery nawet bez pożaru generują ogromną ilość ciepła. A dokładniej, gdy jest chłodzenie, wytwarzają ciepło, a gdy nie ma chłodzenia, tworzą piekielne piekło, które w najlepszym wypadku stopi część sprzętu i wyłączy inną część, a w najgorszym... wywoła pożar w środku hali, która prawie na pewno wszystko zniszczy.
15:39. Naprawiamy problemy z bazą danych conf.
Baza danych conf jest backendem dla usługi o tej samej nazwie, która jest wykorzystywana przez wszystkie aplikacje produkcyjne do szybkiej zmiany ustawień. Bez tej bazy nie możemy kontrolować działania portalu, ale sam portal może działać.
15:41. Czujniki temperatury urządzeń sieci szkieletowej rejestrują odczyty zbliżone do maksymalnych dopuszczalnych. Jest to skrzynka zajmująca całą szafę rack i zapewniająca działanie wszystkich sieci wewnątrz centrum danych.
15:42. Narzędzie do śledzenia problemów i wiki są niedostępne. Przełącz w tryb gotowości.
To nie jest produkcja, ale w razie wypadku dostępność jakiejkolwiek bazy wiedzy może być krytyczna.
15:50. Jeden z systemów monitorowania wyłączył się.
Jest ich kilka i odpowiadają za różne aspekty usług. Niektóre z nich są skonfigurowane do autonomicznej pracy w obrębie każdego centrum danych (tzn. monitorują tylko własne centrum danych), inne składają się z rozproszonych komponentów, które w przejrzysty sposób przetrwają utratę dowolnego centrum danych.
W tym przypadku przestało działać , który działa w trybie master-standby. Przełączono w tryb gotowości.
Przyjęcie
15:51. Wszystkie serwery z wyjątkiem MS SQL zostały wyłączone przez IPMI bez prawidłowego zamknięcia.
Czy jesteś gotowy na masowe zarządzanie serwerami przez IPMI, jeśli to konieczne?
Właśnie na tym etapie kończy się ratowanie sprzętu w centrum danych. Wszystko, co można było zrobić, zostało zrobione. Niektórzy koledzy mogą odpocząć.
16: 13. Otrzymano informację, że na dachu pękły rury freonowe z klimatyzatorów – opóźni to uruchomienie centrum danych po wyeliminowaniu pożaru.
16:19. Według danych otrzymanych od personelu technicznego centrum danych, wzrost temperatury w halach ustał.
17:10. Baza danych conf została przywrócona. Teraz możemy zmienić ustawienia aplikacji.
Dlaczego jest to takie ważne, skoro wszystko jest odporne na awarie i działa nawet bez jednego centrum danych?
Po pierwsze, nie wszystko jest odporne na awarie. Istnieją różne usługi dodatkowe, które nie przetrwały jeszcze wystarczająco dobrze awarii centrum danych, a istnieją bazy danych w trybie gotowości głównego. Możliwość zarządzania ustawieniami pozwala zrobić wszystko, co niezbędne, aby zminimalizować wpływ skutków wypadku na użytkowników nawet w trudnych warunkach.
Po drugie, stało się jasne, że w ciągu najbliższych godzin działanie centrum danych nie zostanie w pełni przywrócone, dlatego konieczne było podjęcie działań, aby długoterminowa niedostępność replik nie doprowadziła do dodatkowych problemów, takich jak zapełnienie dysków w pozostałe centra danych.
17:29. Czas pizzy! Zatrudniamy ludzi, a nie roboty.
Rehabilitacja
18:02. W halach nr 8 (nasza), 9, 10 i 11 temperatura się ustabilizowała. W jednym z tych, który pozostaje offline (nr 7), znajduje się nasz sprzęt, a temperatura w nim stale rośnie.
18:31. Wydali zgodę na uruchomienie urządzeń w halach nr 1 i 3 – hale te nie zostały dotknięte pożarem.
Obecnie uruchamiane są serwery w halach nr 1, 3, 8, zaczynając od tych najbardziej krytycznych. Sprawdzana jest poprawność działania wszystkich uruchomionych usług. Nadal są problemy z halą nr 7.
18:44. Personel techniczny centrum danych odkrył, że w pokoju nr 7 (w którym znajduje się wyłącznie nasz sprzęt) wiele serwerów nie jest wyłączonych. Według naszych danych, 26 serwerów pozostaje tam online. Po drugim sprawdzeniu znajdujemy 58 serwerów.
20:18. Technicy centrum danych przedmuchują powietrze przez nieklimatyzowane pomieszczenie ruchomymi kanałami biegnącymi przez korytarze.
23:08. Pierwszy administrator został odesłany do domu. Ktoś musi spać w nocy, żeby jutro móc kontynuować pracę. Następnie udostępnimy więcej administratorów i programistów.
02:56. Uruchomiliśmy wszystko, co dało się uruchomić. Wykonujemy wiele kontroli wszystkich usług za pomocą testów automatycznych.
03:02. W ostatniej, 7. sali odnowiono klimatyzację.
03:36. Wprowadziliśmy rotację frontów w centrum danych w DNS. Od tego momentu zaczyna napływać ruch użytkowników.
Wysyłamy większość zespołu administracyjnego do domu. Ale zostawiamy kilka osób w tyle.
Małe często zadawane pytania:
P: Co się wydarzyło od 18:31 do 02:56?
Odp.: Zgodnie z „Planem działania na wypadek katastrofy” uruchamiamy wszystkie usługi, zaczynając od najważniejszych. W takim przypadku koordynator na czacie przekazuje usługę bezpłatnemu administratorowi, który sprawdza, czy system operacyjny i aplikacja uruchomiły się, czy nie występują błędy i czy wskaźniki są w porządku. Po zakończeniu startu zgłasza na czacie, że jest wolny i otrzymuje od koordynatora nową usługę.
Proces jest dodatkowo spowalniany przez awarię sprzętu. Nawet jeśli zatrzymanie systemu operacyjnego i zamknięcie serwerów przebiegło prawidłowo, niektóre serwery nie zostaną przywrócone z powodu nagłej awarii dysków, pamięci i obudowy. W przypadku utraty zasilania wzrasta wskaźnik awaryjności.
P: Dlaczego nie można po prostu uruchomić wszystkiego na raz, a następnie naprawić to, co pojawia się podczas monitorowania?
Odp.: Wszystko trzeba robić stopniowo, bo pomiędzy usługami istnieją zależności. A wszystko należy sprawdzić od razu, bez czekania na monitoring – bo z problemami lepiej jest walczyć od razu, nie czekając, aż się pogłębią.
7:40. Ostatni administrator (koordynator) poszedł spać. Pierwszy dzień pracy dobiegł końca.
8:09. Pierwsi programiści, inżynierowie i administratorzy data center (w tym nowy koordynator) rozpoczęli prace renowacyjne.
09:37. Rozpoczęliśmy budowę hali nr 7 (ostatniej).
Jednocześnie kontynuujemy przywracanie tego, czego nie udało się naprawić w innych pomieszczeniach: wymianę dysków/pamięci/serwerów, naprawianie wszystkiego, co „wypala się” w monitorowaniu, ponowne przełączanie ról w schematach master-standby i inne drobne rzeczy, z których jest mimo wszystko całkiem sporo.
17:08. Umożliwiamy wszelką regularną pracę z produkcją.
21:45. Praca drugiego dnia została ukończona.
09:45. Dzisiaj jest piątek. Nadal istnieje kilka drobnych problemów w monitorowaniu. Przed nami weekend, każdy chce odpocząć. Kontynuujemy masowe naprawy wszystkiego, co możemy. Regularne zadania administracyjne, które można było przełożyć, zostały przełożone. Koordynator jest nowy.
15:40. Nagle połowa stosu sprzętu sieci Core w INNYM centrum danych została uruchomiona ponownie. Fronty zostały wycofane z obrotu, aby zminimalizować ryzyko. Nie ma to żadnego wpływu na użytkowników. Później okazało się, że było to wadliwe podwozie. Koordynator pracuje nad naprawą dwóch wypadków jednocześnie.
17:17. Przywrócono działanie sieci w innym centrum danych, wszystko zostało sprawdzone. Centrum danych zostaje wprowadzone w rotację.
18:29. Praca trzeciego dnia i ogólnie odbudowa po wypadku została zakończona.
Posłowie
04.04.2013, , "Koledzy z klasy" —przez trzy dni portal był całkowicie lub częściowo niedostępny. Przez cały ten czas ponad 100 osób z różnych miast, z różnych firm (jeszcze raz serdecznie dziękujemy!), zdalnie i bezpośrednio w centrach danych, ręcznie i automatycznie, naprawiło tysiące serwerów.
Wyciągnęliśmy wnioski. Aby zapobiec takim sytuacjom w przyszłości, wykonaliśmy i nadal prowadzimy szeroko zakrojone prace.
Jakie są główne różnice między obecnym wypadkiem a numerem 404?
- Mamy „Plan działania w razie wypadku”. Raz na kwartał przeprowadzamy ćwiczenia – odgrywamy sytuację awaryjną, którą grupa administratorów (wszyscy po kolei) musi wyeliminować, korzystając z „Planu Działań Awaryjnych”. Wiodący administratorzy systemów na zmianę pełnią rolę koordynatora.
- Co kwartał, w trybie testowym, izolujemy centra danych (wszystkie po kolei) poprzez sieci LAN i WAN, co pozwala nam na szybką identyfikację wąskich gardeł.
- Mniej uszkodzonych dysków, bo zaostrzyliśmy standardy: mniej godzin pracy, bardziej rygorystyczne progi dla SMART,
- Całkowicie porzuciliśmy BerkeleyDB, starą i niestabilną bazę danych, która wymagała dużo czasu na odzyskanie po ponownym uruchomieniu serwera.
- Zmniejszyliśmy liczbę serwerów z MS SQL i zmniejszyliśmy zależność od pozostałych.
- Mamy swoje , gdzie już od dwóch lat aktywnie migrujemy wszystkie usługi. Chmura znacznie upraszcza cały cykl pracy z aplikacją, a w razie wypadku udostępnia tak unikalne narzędzia jak:
- prawidłowe zatrzymanie wszystkich aplikacji jednym kliknięciem;
- łatwa migracja aplikacji z uszkodzonych serwerów;
- automatyczne, rankingowe (w kolejności priorytetów usług) uruchomienie całego centrum danych.
Wypadek opisany w tym artykule był największym od 404. dnia. Oczywiście nie wszystko poszło gładko. Przykładowo, podczas niedostępności uszkodzonego przez pożar centrum danych w innym centrum danych, uległ awarii dysk na jednym z serwerów, czyli dostępna tylko jedna z trzech replik w klastrze Cassandra pozostała dostępna, dlatego 4,2% mobilnych użytkownicy aplikacji nie mogli się zalogować. W tym samym czasie już podłączeni użytkownicy kontynuowali pracę. W sumie w wyniku wypadku zidentyfikowano ponad 30 problemów - od banalnych błędów po niedociągnięcia w architekturze usługi.
Jednak najważniejsza różnica między obecnym wypadkiem a 404. polega na tym, że podczas gdy my eliminowaliśmy skutki pożaru, użytkownicy nadal wysyłali SMS-y i prowadzili rozmowy wideo z numerami telefonów. , graliśmy w gry, słuchaliśmy muzyki, dawali sobie prezenty, oglądaliśmy filmy, seriale i kanały telewizyjne , a także przesyłane strumieniowo .
Jak przebiegają Twoje wypadki?
Źródło: www.habr.com