Как бихте се почувствали, ако един хубав летен ден центърът за данни с вашето оборудване изглеждаше така?
Здравейте всички! Казвам се Дмитрий Самсонов, работя като водещ системен администратор в "" На снимката е един от четирите центъра за данни, в които е инсталирано оборудването, обслужващо нашия проект. Зад тези стени има около 4 хиляди единици оборудване: сървъри, системи за съхранение на данни, мрежово оборудване и др. - почти ⅓ от цялото ни оборудване.
Повечето сървъри са 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. Започваме да изключваме захранването на сървъри без състояние, без правилно да изключим приложението и операционната система.
15:23 ч. Разпределя се група от хора, отговорни за MS SQL (има малко от тях, зависимостта на услугите от тях не е голяма, но процедурата за възстановяване на функционалността отнема повече време и е по-сложна от, например, Cassandra).
депресия
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 ч. Температурните сензори на оборудването на основната мрежа записват показания, близки до максимално допустимите. Това е кутия, която заема цял стелаж и осигурява работата на всички мрежи в центъра за данни.
15:42 ч. Инструментът за проследяване на проблеми и wiki не са достъпни, превключете в режим на готовност.
Това не е производство, но в случай на авария наличието на всякаква база от знания може да бъде критично.
15:50 часа. Една от системите за наблюдение е изключена.
Те са няколко и отговарят за различни аспекти на услугите. Някои от тях са конфигурирани да работят автономно във всеки център за данни (т.е. наблюдават само своя собствен център за данни), други се състоят от разпределени компоненти, които прозрачно преживяват загубата на всеки център за данни.
В този случай спря да работи , който работи в режим master-standby. Превключен в режим на готовност.
Приемане
15:51 часа. Всички сървъри с изключение на MS SQL бяха изключени чрез IPMI, без да се изключат правилно.
Готови ли сте за масивно управление на сървъра чрез IPMI, ако е необходимо?
Моментът, в който на този етап приключи спасяването на оборудването в центъра за данни. Всичко, което можеше да се направи, беше направено. Някои колеги могат да си починат.
16: 13. Получена е информация, че на покрива са се спукали фреонови тръби от климатици - това ще забави пускането на центъра за данни след ликвидиране на пожара.
16:19 ч. По данни, получени от техническия персонал на центъра за данни, повишаването на температурата в залите е спряно.
17:10 часа. Базата данни conf е възстановена. Сега можем да променим настройките на приложението.
Защо това е толкова важно, ако всичко е устойчиво на грешки и работи дори без един център за данни?
Първо, не всичко е устойчиво на грешки. Има различни вторични услуги, които все още не са преживели повреда в центъра за данни достатъчно добре, и има бази данни в режим на готовност. Възможността за управление на настройките ви позволява да направите всичко необходимо, за да сведете до минимум въздействието на последствията от инцидент върху потребителите дори при трудни условия.
Второ, стана ясно, че работата на центъра за данни няма да бъде напълно възстановена в близките часове, така че беше необходимо да се вземат мерки дългосрочната липса на реплики да не доведе до допълнителни проблеми като пълни дискове в останалите центрове за данни.
17:29 часа. Време за пица! Ние наемаме хора, а не роботи.
Рехабилитация
18:02 ч. В зали № 8 (нашата), 9, 10 и 11 температурата е стабилизирана. В една от тези, които остават офлайн (№ 7), се помещава нашето оборудване и там температурата продължава да се покачва.
18:31 ч. Дадоха зелена светлина за пускане на оборудването в зали № 1 и 3, които не са засегнати от пожара.
В момента се пускат сървъри в зали № 1, 3, 8, като се започне от най-критичните. Проверява се правилната работа на всички работещи услуги. Все още има проблеми със зала No7.
18:44 ч. Техническият персонал на центъра за данни установи, че в стая № 7 (където се намира само нашето оборудване) много сървъри не са изключени. По наши данни там остават онлайн 26 сървъра. След втора проверка намираме 58 сървъра.
20:18 ч. Техници от център за данни издухват въздух през неклиматизирана стая чрез мобилни канали, минаващи през коридорите.
23:08 часа. Първият админ беше изпратен у дома. Някой трябва да спи през нощта, за да продължи да работи утре. След това ще освободим още няколко администратори и разработчици.
02:56 ч. Пускахме всичко, което можеше да се пусне. Правим много проверки на всички услуги с помощта на автоматични тестове.
03:02 ч. Възстановена е климатизацията на последната, 7-ма зала.
03:36 ч. Внесохме фронтовете в центъра за данни в ротация в DNS. От този момент започва да пристига потребителски трафик.
Изпращаме по-голямата част от административния екип у дома. Но оставяме няколко души след себе си.
Малък ЧЗВ:
Въпрос: Какво се случи от 18:31 до 02:56?
О: Следвайки „Плана за действие при бедствия“, ние стартираме всички услуги, започвайки с най-важните. В този случай координаторът в чата издава услугата на безплатен администратор, който проверява дали ОС и приложението са стартирали, дали има грешки и дали индикаторите са в норма. След като стартирането приключи, той съобщава на чата, че е свободен и получава нова услуга от координатора.
Процесът допълнително се забавя от повреден хардуер. Дори ако спирането на операционната система и изключването на сървърите е преминало правилно, някои сървъри не се връщат поради внезапна повреда на дискове, памет и шаси. При загуба на захранване честотата на отказ се увеличава.
Въпрос: Защо не можете просто да стартирате всичко наведнъж и след това да поправите това, което се появява в мониторинга?
A: Всичко трябва да става постепенно, защото има зависимости между услугите. И всичко трябва да се провери веднага, без да се чака наблюдение - защото е по-добре да се справите с проблемите веднага, без да чакате да се влошат.
7:40. Последният админ (координатор) си легна. Работата за първия ден приключи.
8:09. Първите разработчици, инженери и администратори на центрове за данни (включително новият координатор) започнаха работа по възстановяване.
09:37 ч. Започнахме да вдигаме зала № 7 (последната).
В същото време продължаваме да възстановяваме това, което не е коригирано в други стаи: подмяна на дискове/памет/сървъри, коригиране на всичко, което "гори" в мониторинга, превключване на роли обратно в схемите master-standby и други малки неща, от които има все пак доста.
17:08 часа. Разрешаваме всякаква редовна работа с производство.
21:45 часа. Работата от втория ден приключи.
09:45 ч. Днес е петък. Все още има доста малки проблеми в мониторинга. Предстои уикенд, всички искат да си починат. Продължаваме масово да ремонтираме всичко, което можем. Редовните административни задачи, които можеха да бъдат отложени, бяха отложени. Координаторът е нов.
15:40 часа. Внезапно половината от оборудването на основната мрежа в ДРУГ център за данни се рестартира. Фронтовете бяха извадени от ротация, за да се минимизират рисковете. Няма ефект за потребителите. По-късно се оказа, че става дума за дефектно шаси. Координаторът работи по отстраняването на две аварии едновременно.
17:17 ч. Работата на мрежата в друг център за данни е възстановена, всичко е проверено. Центърът за данни се въвежда в ротация.
18:29 часа. Работата от третия ден и като цяло възстановяването след аварията приключи.
послеслов
04.04.2013 , "Съученици" — в продължение на три дни порталът беше напълно или частично недостъпен. През цялото това време повече от 100 души от различни градове, от различни компании (още веднъж много благодаря!), дистанционно и директно в центрове за данни, ръчно и автоматично, ремонтираха хиляди сървъри.
Направихме изводи. За да предотвратим това да се случи отново, ние извършихме и продължаваме да извършваме обширна работа и до днес.
Какви са основните разлики между настоящата катастрофа и 404?
- Имаме „План за действие при злополука“. Веднъж на тримесечие провеждаме учения - разиграваме извънредна ситуация, която група администратори (всички на свой ред) трябва да отстранят с помощта на „Плана за действие при извънредни ситуации“. Водещи системни администратори се редуват в ролята на координатор.
- На тримесечие, в тестов режим, ние изолираме центрове за данни (всички на свой ред) чрез LAN и WAN мрежи, което ни позволява незабавно да идентифицираме тесните места.
- По-малко счупени дискове, защото сме затегнали стандартите: по-малко работни часове, по-строги прагове за SMART,
- Напълно изоставихме BerkeleyDB, стара и нестабилна база данни, която изискваше много време за възстановяване след рестартиране на сървъра.
- Намалихме броя на сървърите с MS SQL и намалихме зависимостта от останалите.
- Имаме собствени , където вече две години активно мигрираме всички услуги. Облакът значително опростява целия цикъл на работа с приложението и в случай на авария предоставя такива уникални инструменти като:
- правилно спиране на всички приложения с едно кликване;
- лесна миграция на приложения от повредени сървъри;
- автоматично класирано (по приоритет на услугите) стартиране на цял център за данни.
Аварията, описана в тази статия, е най-голямата от 404-ия ден насам. Разбира се, не всичко мина гладко. Например, по време на недостъпност на повреден от пожар център за данни в друг център за данни, диск на един от сървърите се повреди, тоест само една от трите реплики в клъстера Cassandra остана достъпна, поради което 4,2% от мобилните потребителите на приложението не можаха да влязат. В същото време вече свързаните потребители продължиха да работят. Общо в резултат на аварията бяха идентифицирани повече от 30 проблема - от банални грешки до недостатъци в архитектурата на услугата.
Но най-важната разлика между сегашната авария и 404-та е, че докато ликвидирахме последствията от пожара, потребителите все още изпращаха текстови съобщения и провеждаха видео разговори на , играеха игри, слушаха музика, подаряваха си подаръци, гледаха видеоклипове, сериали и телевизионни канали в , а също и поточно предаване .
Как протичат катастрофите ви?
Източник: www.habr.com