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.

Výpadek napájení

Hned ze začátku se chceme omluvit všem našim uživatelům za situaci, ke které došlo před týdnem v sobotu večer. Bohužel došlo k situaci, která byla nepříjemná pro všechny zúčastněné strany a došlo k několika hodinovému výpadku Roští.cz. V pražském datacentru Master DC, kde máme všechny naše servery, došlo k výpadku proudu.

O situaci jsme se dozvěděli z monitoringu a informovali o tom co nejrychleji na Twitteru. Když jsme na podpoře Masteru zjistili, co se děje, nahodili jsme část služeb vzdáleně, ale dva servery bohužel nereagovaly. Jeden z nich nebyl restartován několik měsíců a protože má ještě HDD disky, běžela na něm dlouho jejich kontrola. V době, kdy jsme do serverovny dorazili už naběhl. Druhý server, který nenaběhl, byl backup, kde se objevily problémy s konfigurací sítě, ale na Roští jako takové to nemělo žádný vliv.

Bohužel Roští není aktuálně navržené tak, aby po takovémto výpadku bylo schopné naběhnout samo. Úplně jsme nepočítali s tím, že je možné, aby došlo k vypnutí všeho najednou a tak jsme na to nebyli připravení. Když vypneme nějaký server, musíme kontejnery na něm zapnout v administraci. Používáme pro správu kontejnerů Docker a ten má jednu nepříjemnou vlastnost, že kontejner, který se vypne a zapne, změní IP adresu, což pak vede k takovým situacím na load balanceru, že doména A zobrazí obsah domény B a podobně. Zabránit tomu můžeme jen tak, že všechno řídíme z jednoho místa.

Museli jsme tedy servery zkontrolovat, nahodit administraci a pak postupně nahazovat jednotlivé kontejnery. Chvilku to trvalo a narazili jsme u toho ještě na problémy se sítí, kterých jsme si během zmatků kolem celé situace nevšimli. Některé weby tedy naběhly až druhý den ráno.

Nakonec jsme všechno dali dohromady a odnesli si z toho spoustu zážitku. Nebyli jsme jediní, komu nenaběhly všechny servery a tak to v datacentru vypadalo jak na nádraží a každý chtěl svůj monitor a klávesnici. Viděli jsme chudáka technika, který běhal s telefonem na uchu od serveru k serveru a zapínal je, protože ne všichni mají nastavené zapnutí po obnovení napájení. Také jsme si všimli, že v části serverovny, kde jsou desktopy nebyla ani noha, ale u rackové skříně byly v obležení svých provozovatelů.

Napsali jsme vyjádření na tento blog ještě ten den co se to stalo, ale nakonec jsme ho nezveřejňovali. Bylo napsané ve vlně emocí, kterou později ještě umocnila situace hned z následujícího pondělí, kdy nám někdo vytáhl jeden server ze zásuvky. To už jsme opravdu nevěděli co budeme dělat, protože to je věc, které nemáme jak zabránit. Měli jsme v poslední době více problémů a za ty největší, které nám způsobily několik hodin downtime celé služby, jsme navíc nemohli. Nějak jsme si ale poradili a doufáme, že nás teď smůla na chvilku opustí.

Let’s encrypt už brzy

Špatných zpráv bylo za poslední týden víc než jsme zvyklí a tak trochu odlehčím atmosféru. Před 14 dny jsme dokončili kód, který umožní spustit podporu Let’s encrypt na Roští. Zmiňoval jsem to i dřív, ale raději ještě jednou napíši: Museli jsme kompletně přepsat způsob, jakým jsou domény u aplikací uloženy. A co z toho plyne? Čeká nás masivní migrace.

V současné době jsou domény u aplikací uloženy ve velkém text fieldu a oddělené mezerou nebo novým řádkem. Systém s tím doposud nějak pracoval, ale určitě vás napadne, že spravovat tímto způsobem domény je nepohodlné. Nejvážnější problém jsou oprávnění. Tedy že subdomény z jedné domény druhého řádu je možné používat mezi více účty. Kontrola tohoto stavu je v současné době obalena hromadou kódu, který není nutný, protože ho může pohlídat databáze. A to je také to, oč jsme se snažili.

V nové verzi administraci bude mít každá doména druhého řádu zónu a v ní subdomény a tyto subdomény budou přiřazeny aplikacím. Pokud budete chtít použít u aplikace jen doménu třetího řádu, tak to samozřejmě nevadí, ale zónu pro celou doménu vám stejně vytvoříme. Není nějak povinné ji používat, ale je lepší, když na ní svoji doménu u registrátora namíříte.

Nicméně, tímto krokem získáme záznam v databázi pro každou doménu/subdoménu a můžeme k němu ukládat i další věci jako třeba informaci, že má být s SSL certifikátem nebo že pro ni máme získat certifikát ze služby Let’s encrypt.

A to je důvod, proč to tak dlouho trvá a ještě chvilku trvat bude. Migrace, kterou chystáme nebude snadná, nebude bez problémů a nebude hotová během pár minut. Musíme se na ní připravit, upravit naše vývojové prostředí a všechno pořádně otestovat. Všechno by se mělo rozjet příští týden ve čtvrtek a pokud to půjde dobře, další týden už bude možné aktivovat Let’s encrypt u vašich domén.

Kromě toho budeme schopni začít s implementací registrace domén, ale ještě předtím se chceme věnovat nové funkci „Služby“, která vrátí MongoDB tam kam patří, do naší administrace.

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.

Jsme pod DDOS útokem 5 Gbps

Řada z vás si všimla, že máme poslední dva dny problémy s dostupností. S pomocí technické podpory datacentra Master DC se nám je daří držet na uzdě, bohužel tím, že máme vypnutý provoz směrem ze zahraničí. Ale pojďme se na to podívat popořadě.

DDOS je typ útoku, u kterého desítky tisíc počítačů z celého internetu posílají požadavky na jeden server. V našem případě jde o UDP flood a TCP SYN flood o síle 3 až 5 Gbps v závislosti na denní době. Přes noc útok ustal a ráno zase začal.

V serverech máme 1 Gbps síťové karty, takže podle grafů server končil se svým firewallem někde u 890 Mbps, což je tak 200-400 × víc, než běžný průměrný provoz. Cokoli dalšího se už k serverů nedostalo a bylo zahozeno switchi na cestě přes datacentrum. Na běžný provoz na lince už nedostalo a tak se server tvářil, že neodpovídá. Packet loss v této době byl 95 %, tedy 19 paketů z 20 se nedostalo do cíle.

Podobné útoky jsou bohužel každodenní realitou internetu a neexistuje proti nim efektivnější obrana než linka a síťové prvky, které ten provoz zvládnou.

Cílem útoku jsme s jistotou nebyli my, protože by nám útočník pravděpodobně šel po homepage, která je oddělená od ostatních aplikací. Cílem je jeden z našich klientů a bohužel nemáme jak zjistit, který to je. Všechny aplikace z nového Roští jsou schovány za IP adresu určenou pro load balancery, takže pokud někdo má útočit na našeho klienta, půjde po této adrese, což se stalo.

Naším současným opatřením je vypnutí provozu ze zahraničí. Klienti, o kterých víme, že jsou na tomto provozu závislí, tak je přesměrováváme na jiný load balancer, který není pod útokem. Nemůžeme ale takto přesunout všechny, protože nevíme, na který konkrétní web je veden útok.

Naštěstí ale víme, je infrastruktura Master DC si s něčím takovým umí poradit, takže jediným problém je, dostat tento provoz od serverů pryč. Rozhodli jsme se tedy load balancer umístit do Master Cloudu, kde je k dispozici služba Radware DefensePro. Všechen provoz tedy půjde sem a odsud bude přesměrován na server, kde běží konkrétní aplikace. Řešení je tedy stejné, jen load balancer se přesune z našich serverů do cloudu.

Radware DefensePro funguje na základě statistiky. Dokáže si zmapovat běžný provoz a všechno ostatní odfiltruje. Nemáme s tímto řešením žádné zkušenosti, ale věříme, že v Master DC vědí, proč ho mají. Teď jen doufáme, že útok opadne na dostatečně dlouhou dobu, aby se Radware DefensePro naučilo, jak naši uživatelé komunikují. Tahle změna bude vyžadovat úpravu DNS záznamů. Uživatelé, kteří mají DNS u nás, se nemusí o nic starat. Ostatním pošleme email s informacemi. Ke změně dojde během neděle, takže příští týden už pojedeme zase bez zádrhelů.