Какво бихте почувствали, ако един хубав летен ден дата центърът с вашето оборудване започне да изглежда така?
Здравейте всички! Казвам се Дмитрий Самсонов, работя като старши системен администратор в «». На снимката е един от четирите дата центрове, в които е инсталирано оборудването, обслужващо нашия проект. Зад тези стени се намират около 4000 единици техника: сървъри, система за съхранение на данни, мрежово оборудване и т.н. — почти една трета от всичкото ни оборудване.
Повечето сървъри работят с Linux. Има и няколко десетки сървъра на Windows (MS SQL) — нашето наследство, от което през годините систематично се отказваме.
И така, на 5 юни 2019 г. в 14:35 инженерите на един от нашите дата центрове съобщиха за пожарна тревога.
Отрицание
14:45. Мелките инциденти с димене в дата центровете се случват по-често, отколкото изглежда. Показателите в залите бяха в норма, затова първоначалната ни реакция беше относително спокойна: наложихме забрана за работа с продукцията, т.е. за всякакви промени в конфигурациите, издигане на нови версии и т.н., освен работата, свързана с отстраняване на проблеми.
Гняв
Опитвали ли сте някога да разберете от пожарникарите къде точно на покрива е възникнал пожар, или сами да стигнете до горящия покрив, за да оцените ситуацията? Какво би било доверието в информацията, получена през петима човек?
14:50. Получена е информация, че огънят се приближава до системата за охлаждане. Но дали ще стигне? Дежурният системен администратор изключва външния трафик от фронтовете на този дата център.
В момента фронтовете на всичките ни услуги са дублирани в три дата центрове, използва се балансиране на ниво DNS, което позволява да се премахнат адресите на един дата център от DNS, предпазвайки по този начин потребителите от потенциални проблеми с достъпа до услугите. В случай, че проблеми в дата центъра вече са настъпили, той автоматично излиза от ротацията. Подробности можете да прочетете тук:
На нас пожарът все още не е повлиял — нито потребителите, нито оборудването не пострадаха. Дали е авария? Първата част от документа „План за действие при авария“ дава определение на понятието „Авария“, а разделът завършва така:
«Ако има съмнения дали е авария или не, то това е авария!»
14:53. Назначава се координатор на аварията.
Координаторът е лице, което контролира комуникацията между всички участници, оценява мащаба на аварията, използва "План за действие при авария", ангажира необходимия персонал, следи за завършването на ремонта и, най-важното, делегира задачи. С други думи, това е човекът, който управлява целия процес на отстраняване на аварията.
Търг
15:01. Започваме да изключваме сървърите, които не са свързани с продукцията.
15:03. Коректно изключваме всички резервирани услуги.
Тук влизат не само фронтовете (на които към този момент потребителите вече не влизат) и техните помощни услуги (бизнес логика, кешове и т.н.), но и различни бази данни с репликационен фактор 2 и повече (, , , и други).
15:06. Получена е информация, че пожарът застрашава една от залите на дата центъра. В този зал нямаме оборудване, но фактът, че огънят може да се прехвърли от покрива на залите, сериозно променя картинката.
(По-късно стана ясно, че няма физическа заплаха за залата, тъй като тя е херметически изолирана от покрива. Заплахата беше само за системата за охлаждане на този зал.)
15:07. Разрешаваме изпълнението на команди на сървърите в ускорен режим без допълнителни проверки ().
15:08. Температурата в залите е в нормални граници.
15:12. Регистрирано е повишение на температурата в залите.
15:13. Повече от половината сървъри в дата центъра са изключени. Продължаваме.
15:16. Взето е решение за изключване на цялото оборудване.
15:21. Започваме да отключваме захранването на stateless-сървърите без коректно изключване на приложението и операционната система.
15:23. Назначава се група отговорни за MS SQL (те са малко, зависимостта на услугите от тях не е голяма, но процедурата за възстановяване на работоспособността отнема повече време и е по-сложна от, например, Cassandра).
Депресия
15:25. Получена е информация за изключване на захранването в четири зали от 16 (№6, 7, 8, 9). В 7-ми и 8-ми зали се намира нашето оборудване. Все още нямаме информация за другите два наши зала (№1 и 3).
Обикновено при пожари електрическото захранване веднага се изключва, но в този случай, благодарение на координираната работа на пожарникарите и техническия персонал на дата центъра, то не беше изключвано навсякъде и незабавно, а по необходимост.
(По-късно се установи, че захранването в зали 8 и 9 не е спряно.)
15:28. Започваме да разгръщаме базите MS SQL от резервни копия в други дата центрове.
Колко време ще отнеме? Ще стигне ли пропускателната способност на мрежата през целия маршрут?
15:37. Регистрирано е прекъсване на някои участъци от мрежата.
Мениджмънтът и продакшън мрежата са физически изолирани една от друга. Ако продакшън мрежата е достъпна, можете да влезете на сървъра, да спрете приложението и да изключите ОС. Ако не е достъпна, можете да влезете чрез IPMI, да спрете приложението и да изключите ОС. Ако не е налична нито една от мрежите, нищо не можете да направите. „Благодаря, капитане!“, ще си помислите.
„А и изобщо, доста е суматоха“, също може да си помислите.
Работата е там, че сървърите дори без пожар генерират огромно количество топлина. По-точно, когато има охлаждане, те генерират топлина, а когато липсва, създават адски пек, който в най-добрия случай ще разтопи част от оборудването и ще изключи друга част, а в най-лошия… ще предизвика пожар в залата, който почти сигурно ще унищожи всичко.
15:39. Регистрираме проблеми с базата conf.
Базата conf е бекенд за едноименния сервис, който се използва от всички приложения на продакшъна за оперативно изменение на настройки. Без тази база не можем да управляваме работата на портала, но самият портал може да работи.
15:41. Температурните сензори на Core мрежовото оборудване регистрират показания близки до пределно допустимите. Това е кутия, която заема цял стенд и осигурява работата на всички мрежи в дата центъра.
15:42. Issue tracker и wiki не са достъпни, преминаваме на standby.
Това не е продакшън, но при аварията наличието на всяка knowledge base може да бъде критично.
15:50. Прекъсна се една от системите за мониторинг.
Их са няколко и те отговарят за различни аспекти на работата на услугите. Част от тях са настроени за автономна работа вътре в всеки дата център (т.е. те мониторят само своя дата център), а други се състоят от разпределени компоненти, които безпроблемно преживяват загубата на всеки дата център.
В този случай спря да работи , която работи в режим master-standby. Превключихме на standby.
Приемане
15:51. Чрез IPMI изключихме без коректно приключване на работата всички сървъри, с изключение на MS SQL.
Готови ли сте за масово управление на сървъри чрез IPMI в случай на необходимост?
Това е моментът, в който спасението на оборудването в дата центъра на този етап е завършено. Всичко, което можеше да се направи, е направено. Някои колеги могат да си починат.
16:13. Получена е информация, че на покрива са се спукали фреоновите тръби от климатиците — това ще забави стартирането на дата центъра след отстраняването на пожара.
16:19. Според данните, получени от техническия екип на дата центъра, е спряло повишаването на температурата в залите.
17:10. Възстановихме работата на базата conf. Сега можем да променим настройките на приложенията.
Защо е толкова важно, ако всичко е отказоустойчиво и работи дори без един дата център?
На първо място, не всичко е отказоустойчиво. Има различни второстепенни услуги, които все още не издържат добре отказа на дата център, и има бази в режим master-standby. Възможността да управляваме настройките позволява да направим всичко необходимо, за да минимизираме влиянието на последствията от аварията върху потребителите, дори в сложни условия.
На второ място, стана ясно, че в близките часове работата на дата центъра няма да бъде напълно възстановена, така че трябваше да се предприемат мерки, за да не доведе дълготрайната недостъпност на репликите до допълнителни неприятности, като пренапълване на дисковете в останалите дата центрове.
17:29. Време за пица! При нас работят хора, а не роботи.
Рехабилитация
18:02. В залите №№8 (наш), 9, 10 и 11 температурата се е стабилизирала. В един от залите, които остават изключени (№7), се намира нашето оборудване и температурата там продължава да нараства.
18:31. Дадено е разрешение за стартиране на оборудването в залите №№1 и 3 — тези зали не бяха засегнати от пожара.
В момента се провежда стартиране на сървърите в залите №№1, 3, 8, започвайки с най-критичните. Проверява се коректността на работата на всички стартирани услуги. Все още има проблеми със залата №7.
18:44. Техническият екип на дата центъра откри, че в залата №7 (където е само нашето оборудване) много сървъри не са изключени. Според нашите данни остават включени 26 сървъра. След повторна проверка откриваме 58 сървъра.
20:18. Техническият екип на дата центъра проветрява въздуха в залата без климатици чрез мобилни въздуховоди, положени през коридорите.
23:08. Освободихме първия администратор да отиде у дома. Някой трябва да поспи през нощта, за да продължим работата утре. След това освобождаваме още част от администраторите и разработчиците.
02:56. Стартирахме всичко, което може да се стартира. Правим голямо тестване на всички услуги с автотестове.
03:02. Климатизацията в последната, 7-ма зала е възстановена.
03:36. Започнахме ротацията на фронтовете в дата центъра в DNS. От този момент започва да идва потребителски трафик.
Разпускаме голяма част от екипа администратори по домовете. Но оставяме няколко души.
Небольшой FAQ:
Q: Какво се случваше от 18:31 до 02:56?
A: Спазвайки "Плана за действия при инцидент", стартираме всички услуги, започвайки от най-важните. При това координаторът в чата предава услугата на свободния администратор, който проверява дали операционната система и приложението са стартирали, няма ли грешки, и нормални ли са показателите. След завършване на стартирането той съобщава в чата, че е свободен, и получава нова услуга от координатора.
Процесът допълнително се забавя от отказало се оборудване. Дори ако спирането на операционната система и изключването на сървърите са минали коректно, част от сървърите не се връщат поради внезапно отказали се дискове, памет, шасита. При загуба на електрическо захранване процентът на отказите нараства.
Q: Защо не може просто да стартирате всичко наведнъж, а след това да поправяте това, което се появи в мониторинга?
A: Всичко трябва да се прави постепенно, защото между услугите има зависимости. А проверката на всичко трябва да се извърши веднага, без да чакаме мониторинга, защото е по-добре да се справим с проблемите веднага, а не да чакаме да се влошат.
7:40. Последният администратор (координатор) отиде да спи. Работите от първия ден са завършени.
8:09. Първите разработчици, инженери в дата центровете и администратори (включително новия координатор) започнаха възстановителните работи.
09:37. Започнахме да подготвяме зала №7 (последната).
Паралелно продължаваме да възстановяваме това, което не успяхме да завършим в другите зали: подмяна на дискове/памет/сървъри, поправяне на всичко, което "гори" в мониторинга, обратно превключване на ролите в схемите master-standby и други малки неща, на които все пак има доста.
17:08. Разрешаваме всички стандартни работи с продукцията.
21:45. Работите от втория ден са завършени.
09:45. Днес е петък. В мониторинга все още има доста малки проблеми. Напред предстоят почивни дни, всички искат да си починат. Продължаваме масово да оправяме всичко, което можем. Официалните администраторски задачи, които могат да бъдат отложени, са отложени. Новый координатор.
15:40. Извънредно рестартираха половината от стека Core мрежово оборудване в ДРУГ дата-център. Извадихме от ротация фронтовете за минимизиране на рисковете. Няма ефект за потребителите. По-късно се оказа, че става въпрос за повредено шаси. Координаторът работи по поправката на две аварии едновременно.
17:17. Работата на мрежата в другата дата-център е възстановена, всичко е проверено. Дата-центърът е включен в ротация.
18:29. Работата на третия ден и общото възстановяване след аварията е завършено.
Следсловие
04.04.2013 г., , „Одноклассники“ —в течение на три дни порталът беше напълно или частично недостъпен. През цялото това време над 100 души от различни градове, от различни компании (отново голямо благодаря!), дистанционно и пряко в дата-центровете, ръчно и автоматично поправяха хиляди сървъри.
Извлякохме заключения. За да не се повтори нещо подобно, проведохме и продължаваме да провеждаме обширни работи.
Какви са основните разлики между настоящата авария и 404?
- Имаме „План за действие при авария“. Веднъж на тримесечие провеждаме учения — разиграваме аварийна ситуация, която група администратори (всички по ред) трябва да отстранят, използвайки „План за действие при авария“. Водещите системни администратори последователно отработват ролята на координатор.
- На тримесечна база в тестов режим изолираме дата-центровете (всички по ред) по LAN и WAN мрежа, което позволява навременна идентификация на тесните места.
- По-малко повредени дискове, защото засилихме стандартите: по-малко работни часове, по-строги прагови стойности за S.M.A.R.T.
- Напълно се отказахме от BerkeleyDB — стара и нестабилна база данни, която изискваше много време за възстановяване след рестарт на сървъра.
- Съкратихме броя на сървърите с MS SQL и намалихме зависимостта от останалите.
- Имаме собствено , в което активно мигрираме всички услуги вече две години. Облакът значително опростява целия цикъл на работа с приложението, а в случай на авария предлага уникални инструменти, като:
- коректно спиране на всички приложения с едно щракване;
- опростена миграция на приложения от неизправни сървъри;
- автоматичен подреден (по приоритет на услугите) старт на целия дата център.
Аварията, описана в тази статия, стана най-голямата от 404-та. Разбира се, не всичко мина гладко. Например, по време на недостъпността на погорелия дата център в друг дата център един диск на сървъра се провали, т.е. само една от трите реплики в Cassandra клъстера остана достъпна, поради което 4,2% от потребителите на мобилни приложения не можеха да влязат. При това вече свързаните потребители продължаваха да работят. Общият брой на проблемите, установени в резултат на аварията, надвишава 30 — от обикновени бъгове до недостатъци в архитектурата на услугите.
Но най-голямата разлика между настоящата авария и 404-та е, че докато ние отстранявахме последствията от пожара, потребителите все още общуваха и правеха видеозвънеци в , играеха игри, слушаха музика, разменяха подаръци, гледаха видеа, сериали и телевизионни канали в , а също така стриймваха в .
Как преминават вашите аварии?
Източник: habr.com
