Co byście poczuli, gdyby pewnego pięknego letniego dnia centrum danych z waszym sprzętem wyglądało tak?
Cześć wszystkim! Nazywam się Dmitrij Samsonow, pracuję jako główny administrator systemów w „”. Na zdjęciu jedno z czterech centrów danych, w których zainstalowany jest sprzęt obsługujący nasz projekt. Za tymi ścianami znajduje się około 4 tys. jednostek sprzętu: serwery, systemy pamięci masowej, sprzęt sieciowy itd. — prawie ⅓ całego naszego wyposażenia.
Większość serwerów to Linux. Jest też kilka dziesiątek serwerów na Windows (MS SQL) — nasze dziedzictwo, od którego stopniowo się zwalniamy.
6 czerwca 2019 r. o 14:35 inżynierowie jednego z naszych centrów danych poinformowali o alarmie pożarowym.
Zaprzeczenie
14:45. Drobne incydenty z zadymieniem w centrach danych zdarzają się częściej, niż się wydaje. Wskaźniki wewnątrz sal były w normie, więc nasza pierwsza reakcja była stosunkowo spokojna: wprowadziliśmy zakaz prac z produkcją, tj. jakichkolwiek zmian w konfiguracji, wdrażania nowych wersji itp., z wyjątkiem prac związanych z naprawą czegokolwiek.
Gniew
Czy kiedykolwiek próbowaliście zapytać strażaków, w którym dokładnie miejscu na dachu wybuchł pożar, albo sami dostać się na palący dach, aby ocenić sytuację? Jakie zaufanie można mieć do informacji uzyskanej od pięciu osób?
14:50. Pojawiły się doniesienia, że ogień zbliża się do systemu chłodzenia. Ale czy dotrze? Dyżurny administrator systemów kieruje ruch zewnętrzny z frontów tego centrum danych.
Na chwilę obecną fronty wszystkich naszych usług są zdublowane w trzech centrach danych, stosujemy równoważenie na poziomie DNS, co pozwala usunąć adresy jednego centrum danych z DNS, w ten sposób chroniąc użytkowników przed potencjalnymi problemami z dostępem do usług. W przypadku, gdy w danym centrum danych już wystąpiły problemy, automatycznie wychodzi ono z rotacji. Więcej można przeczytać tutaj:
Na nas pożar jak dotąd w żaden sposób nie wpłynął — ani użytkownicy, ani sprzęt nie ucierpieli. Czy to awaria? Pierwsza część dokumentu „Plan działania w przypadku awarii” definiuje pojęcie „awaria”, a kończy się część tak:
«Jeśli są wątpliwości, czy to awaria, czy nie, to jest to awaria!»
14:53. Wyznaczany jest koordynator awarii.
Koordynator to osoba, która kontroluje komunikację między wszystkimi uczestnikami, ocenia skalę awarii, korzysta z 'Planu działań w przypadku awarii', angażuje niezbędny personel, nadzoruje zakończenie naprawy, a co najważniejsze — deleguje wszelkie zadania. Innymi słowy, to osoba, która zarządza całym procesem usuwania skutków awarii.
Targ
15:01. Zaczynamy wyłączać serwery, które nie są powiązane z produkcją.
15:03. Poprawnie wyłączamy wszystkie zarezerwowane usługi.
Wchodzą tu nie tylko fronty (na które w tym momencie użytkownicy już nie wchodzą) i ich usługi pomocnicze (logika biznesowa, cache itd.), ale także różne bazy danych z czynnikiem replikacji 2 i więcej (, , , i inne).
15:06. Otrzymano informację, że pożar zagraża jednej z sal centrum danych. W tej sali nie mamy sprzętu, ale fakt, że ogień może przerzucić się z dachu na sale, znacznie zmienia sytuację.
(Później okazało się, że fizyczne zagrożenie dla sali nie istniało, ponieważ była ona hermetycznie izolowana od dachu. Zagrożenie dotyczyło jedynie systemu chłodzenia tej sali.)
15:07. Zezwalamy na wykonywanie poleceń na serwerach w przyspieszonym trybie bez dodatkowych kontroli ().
15:08. Temperatura w salach jest w normie.
15:12. Odnotowano wzrost temperatury w salach.
15:13. Więcej niż połowa serwerów w centrum danych została wyłączona. Kontynuujemy.
15:16. Podjęto decyzję o wyłączeniu całego sprzętu.
15:21. Zaczynamy wyłączać zasilanie na serwerach bezstanowych bez poprawnego wyłączenia aplikacji i systemu operacyjnego.
15:23. Wyodrębniona zostaje grupa odpowiedzialna za MS SQL (jest ich mało, zależność usług od nich nie jest duża, ale procedura przywracania sprawności zajmuje więcej czasu i jest bardziej skomplikowana niż na przykład w przypadku Cassandry).
Depresja
15:25. Otrzymano informację o wyłączeniu zasilania w czterech salach z 16 (nr 6, 7, 8, 9). W salach 7 i 8 znajduje się nasz sprzęt. Nie ma jeszcze informacji o dwóch naszych salach (nr 1 i 3).
Zazwyczaj podczas pożarów zasilanie od razu się wyłącza, ale w tym przypadku, dzięki skoordynowanej pracy strażaków i personelu technicznego centrum danych, nie wyłączano go wszędzie i nie od razu, a w razie potrzeby.
(Później okazało się, że zasilanie w salach 8 i 9 nie zostało wyłączone.)
15:28. Zaczynamy przywracanie baz MS SQL z kopii zapasowych w innych centrach danych.
Ile czasu to zajmie? Czy przepustowości sieci wystarczy na całej trasie?
15:37. Zarejestrowano wyłączenie niektórych odcinków sieci.
Zarządzanie i sieć produkcyjna są fizycznie odizolowane od siebie. Jeśli sieć produkcyjna jest dostępna, możesz zalogować się na serwer, zatrzymać aplikację i wyłączyć system operacyjny. Jeśli nie jest dostępna, można zalogować się przez IPMI, zatrzymać aplikację i wyłączyć system operacyjny. Jeśli żadna z sieci nie działa, nic nie możesz zrobić. "Dzięki, kapitanie!" – pomyślisz.
"A tak w ogóle, to jakoś jest zbyt dużo zamieszania" – pomyślisz również.
Chodzi o to, że serwery nawet bez pożaru generują ogromne ilości ciepła. A dokładniej, gdy mają chłodzenie, generują ciepło, a gdy go nie ma, tworzą piekło, które w najlepszym przypadku stopi część sprzętu i wyłączy inną, a w najgorszym... spowoduje pożar wewnątrz sali, co praktycznie na pewno zniszczy wszystko.
15:39. Zauważone problemy z bazą conf.
Baza conf jest backendem dla tego samego serwisu, który jest używany przez wszystkie aplikacje produkcyjne do bieżącej zmiany ustawień. Bez tej bazy nie możemy zarządzać działaniem portalu, ale sam portal może działać.
15:41. Czujniki temperatury w urządzeniach sieciowych Core rejestrują wartości bliskie do maksymalnych. To pudełko zajmujące całą szafę, które zapewnia działanie wszystkich sieci wewnątrz centrum danych.
15:42. Issue tracker i wiki są niedostępne, przechodzimy na tryb awaryjny.
To nie jest produkcja, ale w przypadku awarii dostępność każdej bazy wiedzy może być krytyczna.
15:50. Jedna z systemów monitorowania przestała działać.
Jest ich kilka i odpowiadają za różne aspekty działania usług. Część z nich jest skonfigurowana do działania autonomicznego wewnątrz każdego centrum danych (monitorują tylko swoje centrum danych), inne składają się z rozproszonych komponentów, bezproblemowo przetrwających utratę dowolnego centrum danych.
W tym przypadku przestała działać , który działa w trybie master-standby. Przełączyliśmy się na standby.
Przyjęcie
15:51. Przez IPMI wyłączono wszystkie serwery bez prawidłowego zakończenia pracy, z wyjątkiem MS SQL.
Czy jesteście gotowi do masowego zarządzania serwerami przez IPMI w razie potrzeby?
To moment, w którym uratowanie sprzętu w centrum danych na tym etapie zostało zakończone. Wszystko, co można było zrobić, zostało zrobione. Niektórzy koledzy mogą odpocząć.
16:13. Otrzymaliśmy informację, że na dachu pękły rury freonowe od klimatyzatorów – to opóźni uruchomienie centrum danych po usunięciu pożaru.
16:19. Z danych otrzymanych od personelu technicznego centrum danych wynika, że wzrost temperatury w salach ustał.
17:10. Przywrócono działanie bazy conf. Teraz możemy zmienić ustawienia aplikacji.
Dlaczego to jest 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. Są różne drugorzędne usługi, które wciąż nie radzą sobie dobrze z awarią centrum danych, oraz bazy w trybie master-standby. Możliwość zarządzania ustawieniami pozwala na zrobienie wszystkiego, co konieczne, aby nawet w trudnych warunkach zminimalizować wpływ konsekwencji awarii na użytkowników.
Po drugie, stało się jasne, że w najbliższych godzinach praca centrum danych nie zostanie całkowicie przywrócona, dlatego należało podjąć kroki, aby długotrwała niedostępność replik nie doprowadziła do dodatkowych problemów, takich jak przepełnienie dysków w pozostałych centrach danych.
17:29. Czas na pizzę! Mamy ludzi, a nie robotów.
Rehabilitacja
18:02. W salach nr 8 (nasza), 9, 10 i 11 temperatura ustabilizowała się. W jednej z tych, które pozostają wyłączone (nr 7), znajduje się nasz sprzęt, a temperatura tam nadal wzrasta.
18:31. Dano zielone światło na uruchomienie sprzętu w salach nr 1 i 3 – te sale ogień nie dotknął.
Na chwilę obecną uruchamiamy serwery w salach nr 1, 3, 8, zaczynając od najważniejszych. Sprawdzana jest poprawność działania wszystkich uruchomionych usług. Wciąż są problemy z salą nr 7.
18:44. Personel techniczny centrum danych odkrył, że w sali nr 7 (gdzie znajduje się tylko nasz sprzęt) wiele serwerów nie zostało wyłączonych. Według naszych danych, pozostaje włączonych 26 serwerów. Po ponownym sprawdzeniu odkrywamy 58 serwerów.
20:18. Personel techniczny centrum danych przepuszcza powietrze w sali bez klimatyzatorów przez mobilne przewody powietrzne prowadzone przez korytarze.
23:08. Pierwszy administrator został wysłany do domu. Ktoś musi się przespać w nocy, by jutro kontynuować prace. Następnie zwalniamy kolejną część administratorów i deweloperów.
02:56. Uruchomiliśmy wszystko, co można było uruchomić. Przeprowadzamy dużą kontrolę wszystkich usług za pomocą testów automatycznych.
03:02. Klimatyzacja w ostatniej, siódmej sali została przywrócona.
03:36. Wprowadziliśmy fronty do DNS w centrum danych do rotacji. Od teraz zaczyna przychodzić ruch użytkowników.
Zwalniamy większość zespołu administratorów do domu. Pozostawiamy jednak kilka osób.
Małe FAQ:
Q: Co działo się od 18:31 do 02:56?
A: Zgodnie z „Planem działania w przypadku awarii”, uruchamiamy wszystkie usługi, zaczynając od najważniejszych. W międzyczasie koordynator w czacie przekazuje usługę wolnemu administratorowi, który sprawdza, czy systemy i aplikacje uruchomiły się poprawnie, czy nie ma błędów oraz czy metryki są w normie. Po zakończeniu uruchamiania informuje na czacie, że jest wolny, i otrzymuje od koordynatora nową usługę.
Proces dodatkowo opóźnia niesprawny sprzęt. Nawet jeśli zatrzymanie systemu operacyjnego i wyłączenie serwerów przebiegły prawidłowo, część serwerów nie wraca z powodu nagle uszkodzonych dysków, pamięci, obudowy. Przy utracie zasilania procent awarii wzrasta.
Q: Dlaczego nie można po prostu uruchomić wszystkiego na raz, a potem naprawić to, co wyjdzie w monitorowaniu?
A: Wszystko należy robić stopniowo, ponieważ istnieją zależności między usługami. Ponadto, wszystko powinno być sprawdzone od razu, nie czekając na monitorowanie — ponieważ lepiej zająć się problemami od razu, nie czekając na ich pogorszenie.
7:40. Ostatni administrator (koordynator) poszedł spać. Prace pierwszego dnia zakończone.
8:09. Pierwszy deweloperzy, inżynierowie w centrach danych oraz administratorzy (w tym nowy koordynator) przystąpili do prac naprawczych.
09:37. Rozpoczynamy podnoszenie sali nr 7 (ostatniej).
Równolegle kontynuujemy przywracanie tego, co nie zostało naprawione w innych salach: wymiana dysków/pamięci/serwerów, naprawa wszystkiego, co 'pali się' w monitorowaniu, odwracanie ról w schematach master-standby oraz inne drobiazgi, których jednak jest dość dużo.
17:08. Zezwalamy na wszystkie rutynowe prace w środowisku produkcyjnym.
21:45. Prace drugiego dnia zakończone.
09:45. Dzisiaj jest piątek. W monitorowaniu wciąż występuje dość dużo drobnych problemów. Przed nami weekend, wszyscy chcą odpocząć. Kontynuujemy masowe naprawy wszystkiego, co można. Zaległe zadania administracyjne zostały odłożone. Nowy koordynator.
15:40. Nagle połowa stosu sprzętu sieciowego w INNYM centrum danych się zrestartowała. Wycofaliśmy fronty, aby zminimalizować ryzyko. Użytkownicy nie zauważyli żadnych efektów. Później okazało się, że to była uszkodzona obudowa. Koordynator pracuje nad naprawą od razu dwóch awarii.
17:17. Praca sieci w innym centrum danych została przywrócona, wszystko sprawdzone. Centrum danych zostało włączone do rotacji.
18:29. Prace trzeciego dnia oraz ogólnie odbudowa po awarii zakończone.
Epilog
04.04.2013 r., , „Odklasowicze” — 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 wielkie dzięki!), naprawiało zdalnie i bezpośrednio w centrach danych tysiące serwerów, zarówno ręcznie, jak i automatycznie.
Wyciągnęliśmy wnioski. Aby do podobnych sytuacji nie dochodziło, przeprowadziliśmy i wciąż prowadzimy rozległe prace.
Jakie są główne różnice między obecną awarią a 404?
- Mamy teraz „Plan działania na wypadek awarii”. Co kwartał przeprowadzamy ćwiczenia — odgrywamy sytuację kryzysową, którą grupa administratorów (wszyscy po kolei) musi usunąć, korzystając z „Planu działania na wypadek awarii”. Wiodący administratorzy systemu na zmianę ćwiczą rolę koordynatora.
- Co kwartał w trybie testowym izolujemy centra danych (wszystkie po kolei) w sieci LAN i WAN, co pozwala na wczesne wykrywanie wąskich gardeł.
- Mniej uszkodzonych dysków, ponieważ zaostrziliśmy normy: mniej godzin pracy, surowsze wartości progowe dla S.M.A.R.T.
- Całkowicie zrezygnowaliśmy z BerkeleyDB — starej i niestabilnej bazy danych, która wymagała dużo czasu na przywrócenie po restarcie serwera.
- Zredukowaliśmy liczbę serwerów z MS SQL i zmniejszyliśmy zależność od pozostałych.
- Mamy swoje , do której już od dwóch lat aktywnie migrujemy wszystkie usługi. Chmura znacznie upraszcza cały cykl pracy z aplikacją, a w przypadku awarii oferuje takie unikalne narzędzia, jak:
- Jedno kliknięcie do poprawnego zatrzymania wszystkich aplikacji;
- Łatwa migracja aplikacji z awaryjnych serwerów;
- Automatyczne uruchamianie całego centrum danych w kolejności priorytetów usług.
Awaria opisana w tym artykule była największa od czasu 404. Oczywiście nie wszystko poszło gładko. Na przykład, podczas niedostępności centrum danych po pożarze, w innym centrum danych padł dysk na jednym z serwerów, co oznacza, że tylko jedna z trzech replik w klastrze Cassandra była dostępna, przez co 4,2% użytkowników aplikacji mobilnych nie mogło zalogować się. Wszyscy jednak użytkownicy już zalogowani mogli korzystać z usług. W sumie w wyniku awarii zidentyfikowano ponad 30 problemów — od banałów po wady architektury usług.
Jednak najważniejszą różnicą między obecną awarią a 404 jest to, że podczas usuwania skutków pożaru, użytkownicy wciąż rozmawiali i wykonywali wideorozmowy w , grali w gry, słuchali muzyki, wymieniali się prezentami, oglądali filmy, seriale i kanały telewizyjne w , a także streamowali w .
Jak wyglądają twoje awarie?
Źródło: habr.com
