Што б вы адчулі, калі ў адзін цудоўны летні дзень дата-цэнтр з вашым абсталяваннем стаў бы выглядаць вось так?
Ўсім прывітанне! Мяне клічуць Зміцер Самсонаў, я працую кіроўным сістэмным адміністратарам у «». На фатаграфіі адзін з чатырох дата-цэнтраў, дзе ўсталявана абсталяванне, якое абслугоўвае наш праект. За гэтымі сценамі знаходзіцца каля 4 тыс. адзінак тэхнікі: серверы, сістэма захоўвання даных, сеткавае абсталяванне і г.д. - амаль ⅓ усяго нашага абсталявання.
Большасць сервераў - гэта Linux. Ёсць і некалькі дзясяткаў сервераў на Windows (MS SQL) - наша спадчына, ад якога мы на працягу многіх гадоў планамерна адмаўляемся.
Такім чынам, 5 чэрвеня 2019 г. у 14:35 інжынеры аднаго з нашых дата-цэнтраў паведамілі аб пажарнай трывозе.
Адмаўленне
14:45. Дробныя інцыдэнты з задымленне ў дата-цэнтрах здараюцца часцей, чым здаецца. Паказчыкі ўнутры залаў былі ў норме, таму першая наша рэакцыя была адносна спакойнай: увялі забарону на працы з прадакшэнам, гэта значыць на любыя змены канфігурацый, на выкатку новых версій і да т.п., акрамя работ, звязаных з папраўкай чаго-небудзь.
Гнеў
Ці спрабавалі вы калі-небудзь даведацца ў пажарных, у якім менавіта месцы на даху адбыўся пажар, ці самому патрапіць на падпаленую дах, каб ацаніць сітуацыю? Якой будзе ступень даверу да інфармацыі, атрыманай праз пяць чалавек?
14: 50. Паступіла інфармацыя, што агонь падбіраецца да сістэмы астуджэння. Але ці дойдзе? Дзяжурны сістэмны адміністратар выводзіць вонкавы трафік з франтоў гэтага дата-цэнтра.
На дадзены момант франты ўсіх нашых сэрвісаў прадубліраваны ў трох дата-цэнтрах, выкарыстоўваецца балансіроўка на ўзроўні DNS, што дазваляе прыбраць адрасы аднаго дата-цэнтра з DNS, засцерагшы тым самым карыстальнікаў ад патэнцыйных праблем з доступам да сэрвісаў. У тым выпадку, калі праблемы ў дата-цэнтры ўжо адбыліся, ён выходзіць з ратацыі аўтаматычна. Падрабязней можна пачытаць тут:
На нас пажар пакуль ніяк не паўплываў - ні карыстальнікі, ні абсталяванне не пацярпелі. Ці аварыя гэта? Першы раздзел дакумента "План дзеянняў пры аварыі" дае вызначэнне паняццю "Аварыя", а заканчваецца раздзел так:
«Калі ёсць сумневы, аварыя ці не, то гэта аварыя!»
14:53. Прызначаецца каардынатар аварыі.
Каардынатар - гэта чалавек, які кантралюе камунікацыю паміж усімі ўдзельнікамі, ацэньвае маштаб аварыі, выкарыстоўвае «План дзеянняў пры аварыі», прыцягвае неабходны персанал, кантралюе завяршэнне папраўкі, самае галоўнае - дэлегуе любыя задачы. Іншымі словамі, гэта чалавек, які кіруе ўсім працэсам ліквідацыі аварыі.
торг
15. Пачынаем адключаць серверы, якія не завязаныя на прадакшэн.
15. Карэктна выключаем усе зарэзерваваныя сэрвісы.
Сюды ўваходзяць не толькі франты (на якія да гэтага моманту карыстачы ўжо не заходзяць) і іх дапаможныя сэрвісы (бізнес-логіка, кэшы і г.д.), але і розныя базы дадзеных з 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.
Гэта не прадакшэны, але пры аварыі даступнасць любога 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: Прытрымліваючыся «Плану дзеянняў пры аварыі», мы запускаем усе сэрвісы, пачынаючы з самых важных. Пры гэтым каардынатар у чаце выдае сэрвіс вольнаму адміністратару, які правярае, ці запусціліся OS і дадатак, ці няма памылак, ці ў норме паказчыкі. Пасля завяршэння запуску ён паведамляе ў чат, што вольны, і атрымлівае ад каардынатара новы сэрвіс.
Працэс дадаткова тармозіцца які адмовіў жалезам. Нават калі прыпынак OS і выключэнне сервераў мінулі карэктна, частка сервераў не вяртаецца з-за раптоўна якія адмовілі кружэлак, памяці, шасі. Пры страце электрасілкавання працэнт адмоў павялічваецца.
Q: Чаму нельга проста запусціць усё зараз, а потым правіць тое, што вылезе ў маніторынгу?
A: Усё трэба рабіць паступова, таму што паміж сэрвісамі ёсць залежнасці. А правяраць усё варта адразу, не чакаючы маніторынгу - таму што з праблемамі лепш разабрацца адразу, не чакаць іх пагаршэння.
7:40. Апошні адмін (каардынатар) пайшоў спаць. Работы першага дня завершаны.
8:09. Першыя распрацоўшчыкі, інжынеры ў дата-цэнтрах і адміністратары (уключаючы новага каардынатара) прыступілі да аднаўленчых работ.
09. Прыступілі да ўзняцця залы №37 (апошняй).
Раўналежна працягваем аднаўляць тое, што не дачынілі ў іншых залах: замена кружэлак/памяці/сервераў, папраўка ўсяго, што «гарыць» у маніторынгу, зваротнае пераключэнне роляў у схемах master-standby і іншыя дробязі, якіх тым не менш досыць шмат.
17:08. Дазваляем усе штатныя працы з прадакшэнам.
21:45. Работы другога дня завершаны.
09. Сёння пятніца. У маніторынгу па-ранейшаму дастаткова шмат дробных праблем. Наперадзе выходныя, усім жадаецца адпачыць. Працягваем масава правіць усё, што можна. Штатныя адмінскія задачы, якія можна было адкласці, адкладзены. Каардынатар новы.
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