Mit érezne, ha egy szép nyári napon így nézne ki az adatközpont az Ön berendezéseivel?
Sziasztok! A nevem Dmitry Samsonov, vezető rendszergazdaként dolgozom a "" A képen a négy adatközpont egyike látható, ahol a projektünket kiszolgáló berendezéseket telepítik. E falak mögött mintegy 4 ezer berendezés található: szerverek, adattároló rendszerek, hálózati berendezések stb. - az összes berendezésünk majdnem egyharmada.
A legtöbb szerver Linux. Több tucat kiszolgáló is található Windowson (MS SQL) – örökségünk, amelyet évek óta szisztematikusan elhagyunk.
Így 5. június 2019-én 14:35-kor az egyik adatközpontunk mérnökei tűzriasztást jelentettek.
Tagadás
14:45. Az adatközpontokban előforduló kisebb füstesemények gyakoribbak, mint gondolná. A csarnokokon belül normálisak voltak a mutatók, így az első reakciónk viszonylag nyugodt volt: betiltották a gyártással való munkát, vagyis minden konfiguráció változtatást, új verziók kigörgetését stb., kivéve a javítási munkákat.
harag
Próbálta már valaha is megtudni a tűzoltóktól, hogy pontosan hol keletkezett a tűz a tetőn, vagy maga is feljutott egy égő tetőre, hogy felmérje a helyzetet? Milyen mértékű lesz a bizalom az öt emberen keresztül kapott információ iránt?
14: 50. Olyan információ érkezett, hogy a tűz közeledik a hűtőrendszerhez. De eljön-e? Az ügyeletes rendszeradminisztrátor eltávolítja a külső forgalmat az adatközpont előlapjáról.
Jelenleg minden szolgáltatásunk frontja három adatközpontban duplikálva van, a kiegyenlítés DNS szinten történik, ami lehetővé teszi, hogy egy adatközpont címét eltávolítsuk a DNS-ből, ezzel megóvva a felhasználókat a szolgáltatásokhoz való hozzáférés esetleges problémáitól. . Ha már problémák merültek fel az adatközpontban, az automatikusan kilép a forgatásból. Bővebben itt olvashatsz:
A tűz minket még semmilyen módon nem érintett – sem a felhasználók, sem a berendezések nem sérültek meg. Ez egy baleset? A „Baleseti cselekvési terv” dokumentum első része meghatározza a „baleset” fogalmát, és a rész így végződik:
«Ha kétség merül fel, hogy baleset történt vagy sem, akkor az baleset!»
14:53. Vészhelyzeti koordinátort neveznek ki.
A koordinátor az a személy, aki az összes résztvevő közötti kommunikációt felügyeli, felméri a baleset mértékét, alkalmazza a vészhelyzeti intézkedési tervet, bevonja a szükséges személyzetet, figyelemmel kíséri a javítások befejezését, és ami a legfontosabb, bármilyen feladatot delegál. Más szóval, ez az a személy, aki a teljes vészhelyzeti reagálási folyamatot irányítja.
Alku
15:01. Elkezdjük letiltani azokat a szervereket, amelyek nem kapcsolódnak a termeléshez.
15:03. Minden fenntartott szolgáltatást megfelelően kikapcsolunk.
Ez nem csak a frontokat (amelyeket ekkorra már nem fér hozzá a felhasználók) és azok kiegészítő szolgáltatásait (üzleti logika, gyorsítótárak stb.), hanem különféle, 2-es vagy annál nagyobb replikációs tényezővel rendelkező adatbázisokat is magában foglal., , , stb.).
15: 06. Információ érkezett arról, hogy tűz fenyegeti az adatközpont egyik csarnokát. Nincsenek felszereléseink ebben a helyiségben, de az a tény, hogy a tűz a tetőről átterjedhet a csarnokokra, nagyban megváltoztatja a történések képét.
(Később kiderült, hogy a csarnokot nem fenyegette fizikai veszély, mivel hermetikusan el volt zárva a tetőtől. A fenyegetés csak ennek a csarnoknak a hűtőrendszerét jelentette.)
15:07. Megengedjük a parancsok végrehajtását a szervereken gyorsított módban további ellenőrzések nélkül ().
15:08. A csarnokokban a hőmérséklet a normál határokon belül van.
15: 12. A csarnokokban hőmérséklet-emelkedést regisztráltak.
15:13. Az adatközpont szervereinek több mint fele ki van kapcsolva. Folytassuk.
15:16. Döntés született az összes berendezés kikapcsolásáról.
15:21. Elkezdjük az állapot nélküli kiszolgálók áramellátását az alkalmazás és az operációs rendszer megfelelő leállítása nélkül.
15:23. Kijelölik az MS SQL-ért felelős emberek csoportját (kevés van belőlük, a szolgáltatások függősége nem nagy, de a funkcionalitás helyreállításának folyamata hosszabb és bonyolultabb, mint például a Cassandra).
depresszió
15: 25. Információ érkezett arról, hogy 16 teremből négyben (6., 7., 8., 9. sz.) áramszünet történt. Berendezéseink a 7-es és 8-as csarnokban találhatók. Két csarnokunkról (1. és 3. sz.) nincs információ.
Általában tüzek idején azonnal lekapcsolják az áramellátást, de ebben az esetben a tűzoltók és az adatközpont műszaki személyzetének összehangolt munkájának köszönhetően nem mindenhol és nem azonnal, hanem szükség szerint kapcsolták ki.
(Később kiderült, hogy a 8-as és 9-es csarnokban nem kapcsolták ki az áramot.)
15:28. Elkezdjük telepíteni az MS SQL adatbázisokat más adatközpontok biztonsági másolataiból.
Mennyi időbe telik? Van elég hálózati kapacitás a teljes útvonalra?
15: 37. A hálózat egyes részeinek leállását rögzítették.
A menedzsment és a termelési hálózat fizikailag el van szigetelve egymástól. Ha elérhető az éles hálózat, akkor ugorhat a szerverre, leállíthatja az alkalmazást, és kikapcsolhatja az operációs rendszert. Ha nem érhető el, akkor IPMI-n keresztül bejelentkezhet, leállíthatja az alkalmazást és kikapcsolhatja az operációs rendszert. Ha nincs egyik hálózat sem, akkor nem tehet semmit. „Köszönöm, Cap!” – gondolod.
„És általában, nagy a zűrzavar” – gondolhatnánk.
A helyzet az, hogy a szerverek még tűz nélkül is hatalmas mennyiségű hőt termelnek. Pontosabban, amikor hűtés van, hőt termelnek, ha pedig nincs hűtés, akkor pokoli pokolgépet hoznak létre, amely a legjobb esetben is megolvasztja a berendezés egy részét, és kikapcsol egy másik részt, rosszabb esetben pedig... tűz a teremben, ami szinte garantáltan elpusztít mindent.
15:39. Javítjuk a conf adatbázissal kapcsolatos problémákat.
A conf adatbázis az azonos nevű szolgáltatás háttérrendszere, amelyet minden éles alkalmazás használ a beállítások gyors megváltoztatására. Ezen alap nélkül nem tudjuk irányítani a portál működését, de maga a portál működhet.
15:41. A központi hálózati berendezések hőmérséklet-érzékelői a megengedett maximális értékhez közeli értékeket rögzítenek. Ez egy olyan doboz, amely egy teljes racket foglal el, és biztosítja az adatközponton belüli összes hálózat működését.
15:42. A problémakövető és a wiki nem érhető el, váltson készenléti állapotba.
Ez nem termelés, de baleset esetén bármilyen tudásbázis elérhetősége kritikus lehet.
15:50. Az egyik felügyeleti rendszer kikapcsolt.
Több ilyen is van, és a szolgáltatások különböző aspektusaiért felelősek. Némelyikük úgy van beállítva, hogy az egyes adatközpontokon belül önállóan működjön (vagyis csak a saját adatközpontjukat figyeli), mások elosztott komponensekből állnak, amelyek átláthatóan túlélik bármely adatközpont elvesztését.
Ebben az esetben leállt , amely master-standby módban működik. Készenléti állapotba kapcsolt.
Örökbefogadás
15:51. Az MS SQL kivételével minden szervert kikapcsoltak az IPMI-n keresztül anélkül, hogy megfelelően leálltak volna.
Készen áll a masszív szerverkezelésre IPMI-n keresztül, ha szükséges?
Az a pillanat, amikor az adatközpontban lévő berendezések mentése ebben a szakaszban befejeződik. Minden megtörtént, amit meg lehetett tenni. Néhány kolléga pihenhet.
16: 13. Információ érkezett arról, hogy a klímaberendezések freoncsövei szétrepedtek a tetőn – ez késlelteti az adatközpont beindítását a tűz elhárítása után.
16:19. Az adatközpont műszaki munkatársaitól kapott adatok szerint a csarnokokban megállt a hőmérséklet emelkedés.
17:10. A conf adatbázis helyreállt. Most már módosíthatjuk az alkalmazás beállításait.
Miért olyan fontos ez, ha minden hibatűrő, és egyetlen adatközpont nélkül is működik?
Először is, nem minden hibatűrő. Vannak különböző másodlagos szolgáltatások, amelyek még nem élték túl jól az adatközpont meghibásodását, és vannak master-standby módban lévő adatbázisok. A beállítások kezelésének lehetősége lehetővé teszi, hogy mindent megtegyen annak érdekében, hogy a balesetek következményeinek a felhasználókra gyakorolt hatását még nehéz körülmények között is minimalizálja.
Másodsorban világossá vált, hogy az adatközpont működése a következő órákban nem áll helyre teljesen, ezért intézkedéseket kellett tenni annak érdekében, hogy a replikák hosszú távú elérhetetlensége ne vezessen további problémákhoz, például megtelt lemezekhez. a fennmaradó adatközpontok.
17:29. Pizza ideje! Embereket alkalmazunk, nem robotokat.
Rehabilitáció
18:02. A 8-as (miénk), a 9-es, a 10-es és a 11-es csarnokokban a hőmérséklet stabilizálódott. Az egyikben, amely offline állapotban marad (7. szám), a berendezéseink találhatók, és ott a hőmérséklet tovább emelkedik.
18:31. Engedélyt adtak az 1-es és 3-as csarnok berendezéseinek beindítására – ezeket a csarnokokat nem érintette a tűz.
Jelenleg az 1-es, 3-as, 8-as csarnokokban indítanak szervereket, kezdve a legkritikusabbakkal. Minden futó szolgáltatás megfelelő működését ellenőrzik. Továbbra is gondok vannak a 7-es csarnokkal.
18:44. Az adatközpont műszaki munkatársai felfedezték, hogy a 7-es számú szobában (ahol csak a mi berendezéseink találhatók) sok szerver nincs kikapcsolva. Adataink szerint 26 szerver maradt online. Egy második ellenőrzés után 58 szervert találunk.
20:18. Az adatközpont technikusai a folyosókon áthaladó mobil csatornákon keresztül fújják át a levegőt egy nem légkondicionált helyiségen.
23:08. Az első admint hazaküldték. Valakinek aludnia kell éjjel, hogy holnap folytathassa a munkát. Ezután még néhány adminisztrátort és fejlesztőt adunk ki.
02:56. Elindítottunk mindent, amit elindítani lehetett. Az összes szolgáltatást nagyon sokszor ellenőrizzük automatikus tesztekkel.
03:02. Az utolsó, 7. terem légkondicionálása helyreállt.
03:36. Elkezdtük a frontok forgatását az adatközpontban a DNS-ben. Ettől a pillanattól kezdve megérkezik a felhasználói forgalom.
Az adminisztratív csapat nagy részét hazaküldjük. De néhány embert magunk mögött hagyunk.
Kis GYIK:
K: Mi történt 18:31 és 02:56 között?
V: A „Katasztrófavédelmi Cselekvési Terv” alapján minden szolgáltatást elindítunk, a legfontosabbakkal kezdve. Ebben az esetben a chat koordinátora kiadja a szolgáltatást egy ingyenes adminisztrátornak, aki ellenőrzi, hogy az operációs rendszer és az alkalmazás elindult-e, vannak-e hibák, és a mutatók normálisak-e. Az indítás befejezése után jelenti a chaten, hogy szabad, és új szolgáltatást kap a koordinátortól.
A folyamatot tovább lassítja a meghibásodott hardver. Még ha az operációs rendszer leállítása és a kiszolgálók leállítása megfelelően történt is, egyes szerverek nem térnek vissza a lemezek, a memória és a ház hirtelen meghibásodása miatt. Ha áramszünet, a hibaarány növekszik.
K: Miért nem lehet mindent egyszerre futtatni, majd kijavítani azt, ami a megfigyelés során felmerül?
V: Mindent fokozatosan kell megtenni, mert a szolgáltatások között függőségek vannak. És mindent azonnal ellenőrizni kell, anélkül, hogy megvárná a megfigyelést - mert jobb, ha azonnal kezeljük a problémákat, anélkül, hogy megvárnánk, hogy súlyosbodjanak.
7:40. Az utolsó admin (koordinátor) lefeküdt. Az első napi munka befejeződött.
8:09. Az első fejlesztők, adatközponti mérnökök és rendszergazdák (beleértve az új koordinátort is) megkezdték a helyreállítási munkálatokat.
09:37. Elkezdtük emelni a 7-es csarnokot (az utolsót).
Ezzel párhuzamosan folytatjuk a más helyiségekben nem javított dolgok visszaállítását: lemezek/memória/szerverek cseréje, mindent megjavítunk, ami a felügyeletben „ég”, szerepek visszaváltása a master-standby sémákban és egyéb apróságok, amiből van. ennek ellenére elég sokat.
17:08. Megengedünk minden rendszeres termelési munkát.
21:45. A második nap munkája befejeződött.
09:45. Ma péntek van. Még mindig van néhány apró probléma az ellenőrzéssel. Közeleg a hétvége, mindenki pihenni szeretne. Továbbra is nagymértékben javítunk mindent, amit csak tudunk. Elhalasztották a rendszeres adminisztrációs feladatokat, amelyeket el lehetett volna halasztani. A koordinátor új.
15:40. Hirtelen újraindult a MÁSIK adatközpontban található Core hálózati berendezések fele. A kockázatok minimalizálása érdekében a frontokat kivonták a rotációból. Nincs hatással a felhasználókra. Később kiderült, hogy hibás alvázról van szó. A koordinátor egyszerre két baleset elhárításán dolgozik.
17:17. A hálózat működése egy másik adatközpontban helyreállt, mindent ellenőriztek. Az adatközpont forgásba kerül.
18:29. A harmadik nap munkája és általában a baleset utáni helyreállítás.
utószó
04.04.2013 , "Osztálytársak" — a portál három napig teljesen vagy részben nem volt elérhető. Ezalatt az egész idő alatt több mint 100 ember különböző városokból, különböző cégektől (ezért is köszönjük!), távolról és közvetlenül az adatközpontokban, manuálisan és automatikusan javított szerverek ezreit.
Következtetéseket vontunk le. Hogy ez ne ismétlődhessen meg, a mai napig kiterjedt munkát végeztünk és folytatunk.
Mi a fő különbség a jelenlegi baleset és a 404 között?
- Van egy „baleseti cselekvési tervünk”. Negyedévente gyakorlatokat tartunk - eljátsszuk a vészhelyzetet, amelyet a rendszergazdák egy csoportjának (mindegyiknek) meg kell szüntetnie a „Vészhelyzeti Intézkedési Terv” segítségével. A vezető rendszergazdák felváltva töltik be a koordinátor szerepét.
- Negyedévente tesztüzemmódban LAN- és WAN-hálózatokon keresztül különítjük el az adatközpontokat (mindegyik), ami lehetővé teszi a szűk keresztmetszetek azonnali azonosítását.
- Kevesebb törött lemez, mert szigorítottuk a szabványokat: kevesebb üzemóra, szigorúbb küszöbértékek a SMART számára,
- Teljesen elhagytuk a BerkeleyDB-t, egy régi és instabil adatbázist, amelynek helyreállítása sok időt igényelt a szerver újraindítása után.
- Csökkentettük az MS SQL-t használó szerverek számát, és csökkentettük a fennmaradóktól való függést.
- Megvan a sajátunk , ahol már két éve aktívan migrálunk minden szolgáltatást. A felhő nagyban leegyszerűsíti az alkalmazással való munkavégzés teljes ciklusát, és baleset esetén olyan egyedi eszközöket biztosít, mint:
- az összes alkalmazás helyes leállítása egyetlen kattintással;
- alkalmazások egyszerű migrálása meghibásodott szerverekről;
- egy teljes adatközpont automatikus rangsorolt (szolgáltatások prioritási sorrendjében) elindítása.
A cikkben leírt baleset a 404. nap óta a legnagyobb. Persze nem ment minden simán. Például egy másik adatközpont tűzkárosult adatközpontjának elérhetetlensége során az egyik szerver lemeze meghibásodott, vagyis a Cassandra-fürt három replikájából csak egy maradt elérhető, ezért a mobilok 4,2%-a alkalmazás felhasználói nem tudtak bejelentkezni. Ugyanakkor a már csatlakoztatott felhasználók folytatták a munkát. Összességében a baleset következtében több mint 30 problémát azonosítottak - a banális hibáktól a szolgáltatási architektúra hiányosságaiig.
De a legfontosabb különbség a mostani baleset és a 404-es között az, hogy amíg a tűz következményeit felszámoltuk, a felhasználók még mindig SMS-eztek és videohívásokat kezdeményeztek , játszott, zenét hallgatott, megajándékozta egymást, videókat, tévésorozatokat és tévécsatornákat néztek , és streamelve is .
Hogyan zajlanak a baleseteid?
Forrás: will.com