Що б ви відчули, якщо одного прекрасного літнього дня дата-центр із вашим обладнанням став би виглядати ось так?
Всім привіт! Мене звуть Дмитро Самсонов, я працюю провідним системним адміністратором». На фотографії один із чотирьох дата-центрів, де встановлено обладнання, яке обслуговує наш проект. За цими стінами знаходиться близько 4 тис. одиниць техніки: сервери, система зберігання даних, мережеве обладнання та ін. - майже ⅓ всього нашого обладнання.
Більшість серверів – це Linux. Є й кілька десятків серверів на Windows (MS SQL) — наша спадщина, від якої протягом багатьох років ми планомірно відмовляємося.
Отже, 5 червня 2019 р. о 14:35 інженери одного з наших дата-центрів повідомили про пожежну тривогу.
Заперечення
14:45. Дрібні інциденти із задимленням у дата-центрах трапляються частіше, ніж здається. Показники всередині залів були в нормі, тому перша наша реакція була відносно спокійною: запровадили заборону на роботи з продакшеном, тобто на будь-які зміни конфігурацій, на викочування нових версій тощо, крім робіт, пов'язаних з ремонтом чогось.
Гнів
Чи намагалися ви коли-небудь дізнатися у пожежників, в якому саме місці на даху сталася пожежа, чи самому потрапити на дах, що горить, щоб оцінити ситуацію? Яким буде ступінь довіри до інформації, отриманої через п'ять осіб?
14:50. Надійшла інформація, що вогонь підбирається до системи охолодження. Але чи дійде? Черговий системний адміністратор виводить зовнішній трафік із фронтів цього дата-центру.
На даний момент фронти всіх наших сервісів продубльовані в трьох дата-центрах, використовується балансування на рівні DNS, що дозволяє прибрати адреси одного дата-центру з DNS, убезпечивши цим користувачів від потенційних проблем з доступом до сервісів. Якщо проблеми в дата-центрі вже відбулися, він виходить з ротації автоматично. Докладніше можна почитати тут:
На нас пожежа поки що ніяк не вплинула — ні користувачі, ні обладнання не постраждали. Чи це аварія? Перший розділ документа «План дій під час аварії» дає визначення поняття «Аварія», а закінчується розділ так:
«Якщо є сумніви, аварія чи ні, це аварія!»
14:53. Призначається координатор аварії.
Координатор — це людина, яка контролює комунікацію між усіма учасниками, оцінює масштаб аварії, використовує «План дій при аварії», залучає необхідний персонал, контролює завершення ремонту, найголовніше делегує будь-які завдання. Іншими словами, це людина, яка керує всім процесом ліквідації аварії.
торг
15:01. Починаємо відключати сервери, які не зав'язані на продакшен.
15:03. Коректно вимикаємо всі зарезервовані послуги.
Сюди входять не тільки фронти (на які до цього моменту користувачі вже не заходять) та їх допоміжні сервіси (бізнес-логіка, кеші тощо), а й різні бази даних із replication factor 2 і більше (, , , та ін.).
15:06. Надійшла інформація, що пожежа загрожує одному із залів дата-центру. У цьому залі ми не маємо обладнання, але те, що вогонь може перекинутися з даху, на зали, сильно змінює картину того, що відбувається.
(Пізніше з'ясувалося, що фізичної загрози для залу не було, оскільки він герметично ізольований від даху. Загроза була лише для системи охолодження цього залу.)
15:07. Дозволяємо виконання команд на серверах у прискореному режимі без додаткових перевірок ().
15:08. Температура у залах у межах норми.
15:12. Зафіксовано підвищення температури у залах.
15:13. Більше половини серверів у дата-центрі вимкнено. Продовжуємо.
15:16. Ухвалено рішення про вимкнення всього обладнання.
15:21. Починаємо відключати живлення на stateless-серверах без коректного вимикання програми та операційної системи.
15:23. Виділяється група відповідальних за MS SQL (їх мало, залежність сервісів від них невелика, але процедура відновлення працездатності займає більше часу і вона складніша, ніж, наприклад, у Cassandra).
Депресія
15:25. Надійшла інформація про вимкнення харчування у чотирьох залах із 16 (№6, 7, 8, 9). У 7-му та 8-му залах знаходиться наше обладнання. Ще про дві наші зали (№1 і 3) інформації немає.
Зазвичай при пожежах електроживлення одразу відключають, але в даному випадку, завдяки скоординованій роботі пожежників та технічного персоналу дата-центру, його вимикали не скрізь і не одразу, а за потребою.
(Пізніше з'ясувалося, що харчування у залах 8 та 9 не відключалося.)
15:28. Починаємо розгортати бази MS SQL із бекапів в інших дата-центрах.
Скільки часу потрібно на це? Чи вистачить пропускну здатність мережі на всьому маршруті?
15:37. Зафіксовано вимкнення деяких ділянок мережі.
Менеджмент та продакшен-мережа ізольовані один від одного фізично. Якщо продакшен-мережа доступна, то ви можете зайти на сервер, зупинити програму та вимкнути OS. Якщо ж недоступна, можна зайти через IPMI, зупинити програму і вимкнути OS. Якщо немає жодної з мереж, зробити ви нічого не можете. «Дякую, кеп!», — подумаєте ви.
«Та й взагалі, якось багато метушні», — можливо, також подумаєте ви.
Справа в тому, що сервери навіть без пожежі генерують величезну кількість тепла. Точніше, коли є охолодження, вони генерують тепло, а коли його немає, то вони створюють пекло пекло, яке в кращому разі розплавить частину обладнання і відключить іншу частину, а в гіршому ... викличе пожежу всередині зали, яка практично гарантовано знищить все.
15:39. Фіксуємо проблеми із базою conf.
База conf є бекендом для однойменного сервісу, який використовується всіма програмами продакшена для оперативної зміни налаштувань. Без цієї бази ми можемо управляти роботою порталу, але сам портал у своїй працювати може.
15:41. Температурні датчики на Core мережевому обладнанні фіксують показання близькі до гранично допустимих. Це коробочка, що займає цілу стійку та забезпечує роботу всіх мереж усередині дата-центру.
15:42. Issue tracker і wiki недоступні, перемикаємося на standby.
Це не продакшено, але при аварії доступність будь-якого знання 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: Наслідуючи «Плану дій при аварії», ми запускаємо всі сервіси, починаючи з найважливіших. При цьому координатор у чаті видає сервіс вільному адміністратору, який перевіряє, чи запустилися OS і додаток, чи немає помилок, чи в нормі показники. Після завершення запуску він повідомляє чат, що вільний, і отримує від координатора новий сервіс.
Процес додатково гальмується залізом, що відмовив. Навіть якщо зупинка OS і вимкнення серверів пройшли коректно, частина серверів не повертається через диски, що раптово відмовили, пам'яті, шасі. При втраті електроживлення відсоток відмов збільшується.
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, що дозволяє своєчасно виявляти вузькі місця.
- Менше битих дисків, тому що ми посилили нормативи: менше напрацювання годин, суворіші порогові значення для SMART,
- Повністю відмовилися від BerkeleyDB - старої та нестабільної бази даних, що вимагала багато часу на відновлення після рестарту сервера.
- Скоротили кількість серверів з MS SQL і зменшили залежність від решти.
- У нас з'явилося своє , куди ми вже протягом двох років активно мігруємо усі сервіси. Хмара значно спрощує весь цикл роботи з додатком, а у разі аварії дає такі унікальні інструменти, як:
- коректна зупинка всіх програм в один клік;
- проста міграція додатків зі збійних серверів;
- автоматичний ранжований (у порядку пріоритету сервісів) запуск цілого дата-центру.
Аварія, описана в цій статті, стала найбільшою з 404-го дня. Звісно, не все йшло гладко. Наприклад, під час недоступності дата-центру-погорільця в іншому дата-центрі вилетів диск на одному із серверів, тобто залишилася доступна лише одна з трьох реплік у Cassandra-кластері, через що 4,2% користувачів мобільних додатків не могли залогінитися . У цьому вже підключені користувачі продовжували працювати. Загалом за наслідками аварії виявлено понад 30 проблем — від банальних багів до недоліків архітектури сервісів.
Але найголовніша відмінність нинішньої аварії від 404-ї в тому, що поки ми усували наслідки пожежі, користувачі, як і раніше, переписувалися і робили відеодзвінки в , грали в ігри, слухали музику, дарували один одному подарунки, дивилися відео, серіали та телеканали у , а також стримали в .
А як відбуваються ваші аварії?
Джерело: habr.com