Čtvrteční výpadek

Ve čtvrtečních ranních hodinách došlo k výpadku napájení v datacentru Master DC vinou selhání jednoho z aktivních prvků. Šlo o výpadek webů, které stále používají starý load balancer (83.167.253.87) a také naší administrace. Nové Roští jako takové nebylo ovlivněno, protože běží v jiném datacentru. Pošta a staré Roští vypadlo zhruba na hodinu a půl zhruba mezi 5:00 a 6:30.

K problému došlo kvůli změnám na napájení, které v Master DC prováděli. Byli jsme o změně informováni s dostatečným předstihem a protože máme dva zdroje, poprosili jsme Master, zda by nám alespoň ten nejdůležitější stroj, kde je DNS server, pošta a staré Roští, nepřipojili na dobu změny ke větvi, která nevypadne. Druhý, kde je administrace a starý load balancer, jsme vypnuli a poprosili technika, aby ho po provedení změny zapnul. Pro tento server mělo jít o výpadek mezi 2:00 a 7:00 maximálně.

Bohužel ale jedna z UPSek nepracovala správně a vypnuly se nám všechny čtyři servery. Servery jsou po dvou ve dvou místnostech, takže bylo jasné, že výpadek napájení byl mnohem větší, než v Masteru čekali a technici neměli čas náš server, který nenaběhl, zapnout. Ostatní tři naběhly v pořádku. Nakonec jsme se do datacentra dostali sami a stroj zapnuli ručně přibližně kolem osmé hodiny ranní. Pak vše naběhlo.

Všem zákazníkům se omlouváme za potíže.

Problémy s disky

Těžko se o takovýchto situacích píše, ale napsat o nich musíme. V jednom ze serverů, které provozujeme, začaly odcházet oba disky v RAID 1 najednou. Server patří k těm starším co máme a i když jsme vydrželi datově bez úhony, nevyhnuli jsme se výpadku.

Celá situace proběhla velmi rychle. Dostali jsme notifikaci, že na jednom z disků se začínají objevovat chybné sektory. Disk jsme odstranili z pole a začali zařizovat disky nové. Máme už delší dobu plán rozšířit kapacity jednoho z nových serverů, který pojme dva naše nejstarší, takže jsme plán jen urychlili.

Chvíli jsme řešili problémy se šroubky a šuplíky, ale než bylo všechno připraveno, začaly se objevovat problémy na druhém disku. Měli jsme připraveny zálohy, ale se zálohama se to má tak, že je nemáme real time, takže když je obnovíme, uživatelé přijdou o část dat mezi dobou zálohy a aktuálním časem.

Rozhodli jsme se situaci ještě zkusit zachránit a virtuální servery přesunout pomalu, s rozvahou a bez velkých neplánovaných výpadků. Disk ještě fungoval, i když občas nemohl nějaký sektor přečíst. Koupili jsme k serveru externí disk, připojili ho přes USB 3.0 a přidali do pole. Přesně v ten moment došlo k poškození obrazů některých virtuálních serverů. Nejvíce byl zasažen jeden ze serverů mimo veřejné Roští, který jsme museli také jako jediný obnovit ze zálohy. Všechna ostatní data se podařilo dostat ven.

Výpadek nového Roští byl v sobotu pod jednu hodinu. Problém totiž zasáhl databáze, kterým jsme dávali prioritu a protože jich není tolik, přestěhovaly se rychle. Hned potom jsme se vrhli na poštu a zmíněný virtuální server. Pošta neběžela kolem šesti hodin někdy od 17 do 23. O emaily uživatelé nepřišli, čekaly ve frontě na serveru, ze kterého měly přijít.

O stavu postiženého serveru a řešení jsme informovali po půlhodinách na Twitteru a naší homepage.

Aby toho nebylo málo, druhý den začal zlobit server alpha-node-2, se kterým máme dlouhodobé problémy. Nicméně jsme přišli na to, co se na něm děje a v nejbližších dnech to vyřešíme. Skript, který měl pomoci s diagnostikou se bohužel ukázal jako problémový, takže musíme opatrně.

Ve stejný týden jsme ještě měli problém s dalším serverem, který ovlivnil jen nové Roští. V serverovně nám dali špatné zásuvky v PDU. Přišli jsme na to náhodou, ale vysvětlily se tím restarty, ke kterým v posledních třech měsících docházelo. Nyní máme nové zásuvky a tak je to také vyřešeno.

Výpadků nám je líto, ale každý takový problém nám pomáhá se posunout dopředu. Celé nové Roští je nyní na novém hardwaru. Zbytek starého Roští čeká migrace během víkendu. Na problémovém serveru už teď nic neběží.

V blízké budoucnosti bychom chtěli prozkoumat možnosti běhu Roští mimo náš vlastní hardware a upravíme zálohování tak, abychom měli k dispozici čerstvější data a hlavně rychleji dostupná.

Problémy s alpha-node-2 by měly být tento týden dočasně vyřešené a do administrace právě implementujeme vlastnost, která by je měla odstranit napořád.

Víme, že Roští ještě není dokonalé a že má své mouchy. Omlouváme se za potíže, které vám tyto problémy způsobily a doufáme, že kroky, které jsme podnikli, vás přesvědčí, že se tyto problémy nebudou opakovat.

Jsme stále pod útokem

Dnes ráno došlo k dalšímu útoku na náš load balancer a proto jsme byli opět nuceni odpojit připojení ze zahraničí pro jeho IP adresu. Během včerejška jsme přesunuli všechny weby, které  u nás měly DNS zóny, na nový load balancer s Anti-DDOS ochranou a rozeslali emaily s informacemi pro domény, které u nás zóny nemají.

Tady je znění rozeslaného emailu:

Dobrý den,

v minulém týdnu jsme se stali objetí DDOS útoku, který na nějaký čas vyřadil náš load balancer. Došlo k jeho zahlcení a jedinou účinnou ochrannou, kterou jsme mohli rychle nasadit, bylo odpojení příchozího provozu ze zahraničí s výjimkou Slovenska. Útok nebyl veden přímo na nás, ale na jednoho z našich zákazníků. Během víkendu se nám podařilo vymyslet plán, jak se podobným problémům vyhnout. Rozhodli jsme se ve spolupráci s datacentrem Master DC umístit provoz na Roští.cz za technologii Radware DefensePro, která umí podobné útoky odfiltrovat a nepouštět je až k serveru. Ten totiž není uzpůsoben k tomu, aby se s nimi vyrovnal. Více informací si můžete přečíst na našem blogu na následující URL adrese:

http://blog.rosti.cz/jsme-pod-ddos-utokem-5-gbps/

Součástí řešení je bohužel změna IP adres. Uživatelům, kteří u nás mají vedené DNS záznamy jsme nastavení už změnili, ale jak možná tušíte, tento email dostáváte proto, že DNS záznamy k vaší doméně či doménám u nás nemáte. Chceme vás tedy poprosit o změnu A a AAAA záznamů na následující hodnoty:

A: 185.58.41.93 (z 83.167.253.87)
AAAA: 2a01:430:144::2 (z 2a01:430:225::9)

Změnu nemusíte uspěchat, ale důrazně ji doporučujeme. Netušíme, který konkrétní web byl pod útokem, protože charakter útoku nám to neprozradil. Pokud se jednalo zrovna o váš web, tak bez změny DNS záznamů nebudeme příště schopni ho efektivně ochránit. Níže posíláme seznam domén, které v současné době ukazují na původní IP adresy:

* SEZNAM DOMÉN

Omlouváme se za nepříjemnosti a děkujeme za pochopení.


Vaše Roští.cz.

Současně s tímto bychom vás chtěli poprosit, abyste zvážili, zda k nám DNS zóny nepřesunout. U CZ domén stačí nastavit NSSET ROSTICZ, u ostatních domén NS servery:

  • ns1.rosti.cz
  • ns2.rosti.cz

Budeme pak schopni takto nečekané změny provádět operativně sami.

Už to je dobré

Mám radost, že vám mohu oznámit, že teď už je vše v pořádku. Je neděle večer, server má load 0.4 a běží už více než 24 hodin bez zádrhelu. Dnešní plánovaný výpadek jsme museli trochu urychlit a provést ho už v pátek v noci a pokud sledujete náš status twitter, víte že to dopadlo dobře.

Tento servisní zásah jsme měli připravený, takže jsme se výrazně nezasekli. Služby na novém Roští jsme vypnuli kolem 0:30 a kolem 2:30 bylo hotovo. K poškození souborového systému tentokrát nedošlo, takže jsme neměli problémy s nahozením služeb. Jedeme teď na kombinaci Docker+ext4+aufs, což byste měli výrazně pocítit na výkonu IO operací, samozřejmě v tom dobrém slova smyslu 🙂 Kontejnery jsou teď opravdu svižnější.

Btrfs jsme původně vybrali, protože Docker týmem byl označen za stabilní a neměli jsme s ním po celý rok vývoje administrace žádné problémy. Hodně se nám líbili funkce snapshotů, které jsme používali pro zálohování a quote, které nám pomáhali omezovat množství dat, která můžete uložit. Spolehlivost je ale samozřejmě důležitější, takže tyto věci budeme řešit tak, jak jsme je řešili doposud.

Byl to náročný víkend, takže to jen shrnu. Všechno už je v pořádku, systém je teď rychlejší a i když vyšel Docker 1.8. teď rozhodně aktualizovat nebudeme 🙂

Doplněk: Aktualizovat budeme asi až na Docker 1.9, protože 1.8 pro nás nepřináší nic zásadního, ale 1.9 bude podporovat volume pluginy a to nám dá do ruky nástroj, jak decentralizovaně ukládat vaše data. Díky tomu by nás podobné problémy v budoucnu netrápily, protože bychom mohli migrovat vaše aplikace mezi servery v řádu sekund.

Trápí nás Btrfs :-(

Když jsme začali před rokem a kousek pracovat s Dockerem, postupně jsme si vybudovali vztah k souborovému systému Btrfs, který uměl vše co jsme potřebovali. Snapshoty, quoty, roztahoval se na více blokových zařízení a byl rychlý a odolný vůči výpadkům díky COW. Rozhodnutí Btrfs použít nás ale nakonec dostalo do tohoto bodu. Měli jsme dnes další neplánovaný výpadek.

Více než půl roku používáme Btrfs na zálohování dat. Snapshoty nám hodně to ulehčily udržování více verzí jedněch dat. Používáme Btrfs několik let i na desktopech a noteboocích, kde vyvíjíme administraci. V kombinaci s Dockerem nás ale už několikrát vypeklo. Před dvěma dny začalo stoupat iowait na hlavním serveru pro novou administraci a nedařilo se nám zjistit čím to je. Měli jsme v plánu problém pořádně prozkoumat v noci, až bude provoz na serveru minimální, ale dneska večer, kolem 22:00 stoupl load serveru na 180 a kontejnery přestaly reagovat. Monitoring nás upozornil a hned jsme na odstraňování problému začali pracovat.

Až po pádu jsme zjistili, že došlo k poškození souborového systému s daty kontejnerů a to byl také důvod, proč na serveru začal původně stoupat load. Podařilo se nám souborový systém odpojit, ale nepodařilo se nám ho bez restartu serveru opravit.

Rozhodli jsme se Btrfs nadobro opustit. Vrátíme se zpět k Ext4 a jako storage backend pro Docker použijeme buď autfs nebo overlayfs. S obojím máme zkušenosti, ale musíme provést nejdříve pár testů, abychom vybrali správně.

Držte nám palce. Psali jste nám během výpadku a my vám hned odpovídali. Byli jste rádi, že s vámi komunikujeme a že na odstranění problému pracujeme. To je v těchto chvílích velká vzpruha a víme, že to co děláme, děláme správně. Tak nám zůstaňte věrní, tohle společně zvládneme.