Co se dělo

Trochu nervózně koukám, že poslední příspěvek na tomto blogu je ještě z minulého roku. Rád bych to tedy napravil a řekl vám, co jsme poslední půl rok dělali. Důvodem bylo, že jsme udělali špatné rozhodnutí, které nás poslalo o několik měsíců dozadu. Takovým rozhodnutím si dřív nebo později projde každý a tak to bereme hlavně jako zkušenost. Nakonec nám to pomohlo si ujasnit priority a jimi se pak řídit.

Před rokem nás kontaktovala firma, která chtěla skončit s poskytováním hostingu pro pythoní projekty a nabízela nám jejich zákazníky. Bohužel jsme si nepoložili tu nejdůležitější otázku a to je PROČ, v tomto případě „Proč to dělají?“. Po dlouhých odkladech jsme nakonec migraci začali realizovat a narazili na několik věcí, které byly vyloženě nůž do zad.

Servery byly staré, na jednom běžel ještě Debian Lenny a migrace na něco jiného nepřipadala v úvahu. Souhlasili jsme se stejnými cenovými podmínkami po dobu jednoho roku a tak by se nám investice do kompletního migrování pod naši administraci nevyplatila.

Náklady byly o třetinu vyšší než nám bylo řečeno, protože na poslední chvíli k tomu přibyl třetí server. Dokonce byly o kousek větší než příjem.

Fakturační údaje jsme dostaly v Google Spreadsheetu s nepřesnostmi. Kvůli jinému typu fakturace jsme museli upravovat administraci. Fakturaci jsme řešili poslední dva měsíce.

Byla nám slíbena změna nastavení DNS, ale nedošlo k ní u všech webů. I tři měsíce po vypnutí původních serverů, se občas někdo ozve, že mu nejede web.

Podařilo se nám s tím nějak poprat. Upravovali jsme administraci, aby zvládala platby i mimo svoji oblast, přemigrovali jsme aplikace a poštu z jednoho serveru pod administraci a srazili náklady na další dva servery. Celkově jsme asi na třetině. Do budoucna plánujeme zrušení těchto dvou serverů a nabídku na migraci pro konkrétní klienty a tak bychom se těchto serverů mohli během příštího roku zbavit.

Pracovali jsme na tom od března. Vyvinuli jsme spoustu jednoúčelových nástrojů, které nám jsou už k ničemu a museli jsme do administrace implementovat věci, které pravděpodobně na nic jiného nevyužijeme.

I přes to všechno, když na to kouknu zpětně, to nebylo zas tak zlé rozhodnutí, protože víme, že do něčeho podobného už nikdy nepůjdeme. Budeme se soustředit primárně na službu jako takovou a nesystémové věci přenecháme ostatním.

Doufám, že je tato kapitola za námi a můžeme se podívat na to, co nás čeká. Ale to až v dalším postu.

Nový ceník

Když jsme před dvěma lety začali pracovat na novém Roští, cenová politika byla jedním z velkých otazníků. Neměli jsme zkušenosti s vedením firmy a věděli jsme, že špatně nastavenou cenou bychom mohli potopit Roští ještě před tím, než se rozjede. Máme nyní data ze dvou let provozu a rozhodli jsme se proto upravit ceník tak, abychom mohli Roští dlouhodobě dále rozvíjet.

Nebylo to jednoduché rozhodování a strávili jsme spoustu času debatami nad výší jednotlivých částek. Dnes víme kolik v průměru stojí každá aplikace, takže počítání bylo jednoduché. Nicméně je tu i psychologický aspekt, který řeší každý projekt „Bude to konkurenceschopná cena?“, „Budou to uživatelé ochotni zaplatit?“.

Roští není hosting, který by mířil na masy. Nabízí toho svým uživatelům hodně. Každá aplikace má velmi blízko k prostředí virtuálního serveru a to pro nás dělá správu o poznání komplikovanější než u běžných hostingů, kde je jen PHP a centrem všeho je Apache. Pokud jsme tedy něco za ty dva roky zjistili, tak je to to, že nemůžeme nabízet hosting za 26 Kč měsíčně.

A se současným ceníkem jsme měli ještě jeden problém, nebyli jsme schopni s uživateli komunikovat kolik je vlastně bude hosting stát. Neměli jsme pevné mantinely, do kterých by mohli svou aplikaci zařadit a tak se ptali na otázku, na kterou jsme neznali odpověď: „Kolik mě bude hostingu u vás stát?“. Podle nového ceníku už tedy nebudeme počítat aplikace dynamicky, ale vytvořili jsme 4 balíčky, u kterých budeme schopni říct, k čemu jsou vhodné.

Změnou tedy vyřešíme dva palčivé problémy, které nás aktuálně trápí. Doufáme, že přestaneme odrazovat uživatele, kteří se s ceníkem neztotožnili a zbavíme se aplikací, které jsou pro nás aktuálně ztrátové. U těch nejmenších aplikací (myšleno ve velikosti RAM) dojde k nejcitelnějšímu zdražení. U průměrných aplikací (192 a 256 MB RAM) to už není tak znatelné.

Nemá to smysl dále protahovat, tady je aktuální náhled na balíčky, které budeme od tohoto týdne nabízet:

Start Normal PRO business
256 MB RAM
2 GB prostoru
99 Kč
512 MB RAM
10 GB prostoru
189 Kč
1024 MB RAM
25 GB prostoru
499 Kč
4096 MB RAM
50 GB prostoru
999 Kč

Máte teď asi nějaké otázky, tak na některé zkusím odpovědět a pokud nenajdete odpovědi níže, tak se klidně ptejte v komentářích.


Proč je minimum 256 MB RAM?

Requesty na aplikace s 64 a 128 MB RAM jsou často sestřelovány OOM killerem, protože kontejner nemá dostatek paměti. Hranice 256 MB RAM je rozumná pro 80 % projektů, které aktuálně na Roští hostují. Poběží v tom WordPress i Django a dají se v tom provozovat i velké projekty, pokud jsou dobře napsané. Zatím bohužel nemáme jak detekovat, pokud se OOM killer přihlásí ke slovu, ale rozjeli jsme ukazatel využité RAMky a zkusíme implementovat notifikace, když se bude obsazení paměti dlouhodobě blížit 100 %.

Co za cenu navíc dostanu?

Rozrostli jsme se o dalšího člena týmu, který se věnuje vývoji full time. Pomalu přecházíme na cloudové služby, takže jsme přestali kupovat vlastní hardware. Díky tomu máme více možností na zabezpečení provozu aplikací například před DDOS útoky a také jsme schopni rychleji reagovat na problémy se servery.

Od kdy začnou balíčky platit?

Podporu v administraci máme nasazenou, takže všechny nové aplikace už používají balíčky.

Musím na balíčky přejít?

Zatím ne, ale od nového roku přepneme současné aplikace na nový způsob účtování. Chceme vám tímto dát čas zvážit změny v našem ceníku a rozhodnout se, zda u nás zůstanete nebo použijete alternativní služby.


Změny ceníku, zvlášť když dochází ke zdražení, nejsou nikdy příjemné a chápeme to. Snažíme se s vámi komunikovat důvody, které nás k tomu vedly. Nový ceník je založen na číslech z reálného provozu a všechny alternativní možnosti jsou horší než tato. Omlouváme se za špatné zprávy a doufáme, že na nás i přes to nezanevřete.

Jak Roští dostalo Let’s encrypt

Máme za sebou víkend s velkým V. Poslední dva měsíce jsme strávili vývojem a máme hromadu novinek, které se během minulého víkendu sešly do jedné větve a nakonec se dostaly i do produkce. Některé vlastnosti ještě nejsou aktivované, protože bychom asi nespali vůbec, ale přijde i na ně.

Nejlépe bych dění shrnul asi následujícím seznamem:

  • Let’s encrypt
  • Automatické nabíhání
  • Podpora více lokalit
  • Vylepšení vývojového prostředí
  • Quoty
  • Vylepšená validace DNS záznamů
  • Nový Docker (1.12.2)
  • Nová verze Docker API (1.24)
  • Přišli jsme na to, proč byl pomalý řadič

Změn bylo hodně, u některých jsme počítaly s problémy, ale u žádné s tak velkými. Nedostupnost nebyla úplně malá, ale podařilo se nám ji udržet mezi přibližně jednou a sedmou hodinou ranní, což nám doufám odpustíte, protože odměna za to fakt stojí. Sobotní výpadek mezi 3:00 a 7:00 byl způsobem řadičem a nepočítali jsme s ním. Nicméně se nám podařilo vyřešit i to. Ale pojďme na to postupně.

Let’s encrypt

LE se stávalo takovou naší Nemesis. Celkem jsme ho implementovali třikrát. Ne že by se minimálně druhý pokus nepovedl, ale výsledek byl takový, že bychom ho do produkčního prostředí nedostali. Měli jsme to spojené s provázáním domén u aplikací s DNS zónou, což se ukázalo tak komplikované, že jsme nakonec od nasazení upustili. Několik desítek hodin práce tak vylétlo komínem. O prvním pokusu raději ani nebudu mluvit, byl to výstřel do tmy a nesedlo by to.

Nakonec jsme vyvinuli vlastního daemona, který konfiguruje Nginx tak, aby se choval jako reverzní proxy a stará se o získávání certifikátů. Je napsaný v Go. Vybrali jsme Go spíše jako pokus, ale výsledek je ohromující. Daemon má REST API, které si poradí se stovkami konkurenčních požadavků, aniž by se to nějak významně projevilo na CPU.

Let’s encrypt si můžete zkusit u své aplikace v záložce parametry, kde se dá zapnout. Musíte mít doménu nasměrovanou na náš hlavní load balancer, což jsou záznamy:

Na starém load balanceru to fungovat nebude. U LE přepínače je k tomu velké varování. Také nebudou fungovat wildcard domény, protože je LE nepodporuje. Takové domény zůstanou automaticky na HTTP a ostatní pojedou přes HTTPS.

Hned v prvních dnech jsme narazili na limit dvaceti subdomén k jedné doméně druhého řádu. S tím nic neuděláme, takže subdomény pod rostiapp.cz mohou získávat certifikát i několik týdnů. Mezitím pojedou všechny na HTTP jak jste byli zvyklí.

Automatické nabíhání

Během posledních pár měsíců jsme měli problémy s výpadky napájení. Když už došlo k restartu serveru, nemohli jsme nahodit kontejnery hned a už vůbec nemohly naběhnout sami, protože se load balancer připojuje na jejich interní IP adresy. Ty se s každým startem mění, takže jsme to museli řešit přes administraci a to chvilku trvalo.

Kvůli tomu se také stávalo, že se na chvilku a nebo v případě nějaké chyby i na delší dobu, objevila na doméně A aplikace z domény B. Minimalizovali jsme to procesními změnami, ale teď už je takové chování velmi nepravděpodobné.

Nyní když naběhne server, automaticky se nastartují i všechny kontejnery s pevně danou konfigurací (ta se dřív dynamicky měnila). I díky novému Dockeru, který už umí pracovat s více kontejnery najednou, se tak výpadek služeb během restartu zmenší z řádově desítek minut na minuty.

Doufáme, že neplánované výpadky už nebudeme mít, ale naštěstí nám tato vlastnost pomůže i při těch plánovaných.

Podpora více lokalit

Problémy se servery v posledních měsících nás vedly k tomu, že bychom se mohli porozhlédnout po nějaké cloudové službě a provozovat Roští tam. K tomu potřebujeme, aby administrace párovala server s aplikací a databázový server tak, aby byly u sebe. Nemusí to být úplně stejný server, ale mělo by to být stejné datacentrum. To znamená, že když aplikace poběží v Německu, tak nesmí používat databázi v Česku a podobně.

Nová verze administrace tuto vlastnost má a tak můžeme začít testovat různé cloudové služby a nakonec snad jednu či dvě vybrat.

Ideálně bychom se chtěli dostat do stavu, aby případné problémy nepostihly 50 % služeb, jako tomu je často teď, ale třeba jen 5 nebo 10 %.

Vylepšení vývojového prostředí

Na vývoj používáme Vagrant a jeho konfiguraci jsme řešili skriptem. Teď jsme přešli na Ansible a sestavení vývojového prostředí je díky tomu stabilnější a spolehlivější. Můžeme teď také začít pracovat na integračních testech a stagingu. Administrace je už docela velká a tahle změna nám hodně pomůže.

Staging prostčedí se subsetem produkčních dat by nám měl pomoci minimalizovat problémy, které máme při nasazování nových vlastností. Bohužel to na Roští není tak jednoduché jako u jiných projektů, protože administrace ovládá spoustu serverů a zrcadlení celého stacku je nákladné finančně i časově. Musíme najít tedy nějaký kompromis.

Quoty

Moc jsme o tom nemluvili, ale když jsme přišli o souborový systém Btrfs, přišli jsme i o možnost quote, tedy omezení diskového prostoru pro jednotlivé aplikace. Nechávali jsme to tedy být, ale občas nám to způsobilo nějaké problémy, třeba když jedna aplikace začala vytvářet velké množství obrázků v /tmp a zaplnila celý disk.

Implementace není snadná a ani naše řešení není čisté, protože linuxové quoty jsou vázané na UID a GID procesu a naše kontejnery používají obě čísla stejná, takže tudy cesta nevedla. Druhou možností je Btrfs, přece jen za ty dva pokročilo, ale quoty tam pořád ještě nejsou stabilní a nemáme na to zatím odvahu.

Tak nakonec vytváříme každé aplikaci image s filesystémem a mountujeme ho na místo, kde kontejner očekává data. Nevýhodou je, že s quotami nejde jít dolů, ale jen nahoru. I tak myslíme, že to je lepší řešení než žádné.

Tato vlastnost ještě není zapnutá, ale během pár dnů bude.

Vylepšená validace DNS záznamů

Občas se stávalo, že uživatel udělal chybu při zadávání záznamů v DNS zóně a to vedlo k problému v konfiguraci Bindu a doména zmizela z DNS po přibližně dvou týdnech. Problém je samozřejmě v naší administraci, kde jsme měli chyby ve validaci. Nová verze administrace validaci vylepšila a toto se už nebude stávat. Vycházeli jsme z chyb, se kterými jsme se v posledních pár měsících uživatelé setkali.

Nový Docker (1.12.2) a Docker API (1.24)

Nejstarší server pluto.rosti.cz ještě běžel na Dockeru 1.8 a ostatní servery také byly trochu pozadu, takže jsme aktualizovali na verze 1.12. S tím jsme změnily i verzi API, se kterou komunikuje administrace s Dockerem a to na 1.24. Nejdůležitější změnou pro vás je rychlost startu kontejnerů, protože Docker od verze 1.11 umí pracovat s kontejnery paralelně a je možné spustit stovky kontejnerů během několika sekund.

Přišli jsme na to, proč byl pomalý řadič

Minulý týden v sobotu jsme narazili na novém poli s RAID 5 na problém. Server se začal kolem třetí hodiny ranní chovat neuvěřitelně pomalu a skončilo to vesměs samovolně někdy kolem deváté hodiny ráno. Netušili jsme o co jde a asi si dokážete představit, jak nám bylo. Problém se teď opakoval a naštěstí jsme byli vzhůru a nakonec ho identifikovali. šlo o Patrol Read, funkci, která kontroluje zda v poli nejsou nějaké problémy. Díky tomu může řadič včas odstranit vadný disk.

Patrol Read bylo nastaveno na 30 % zatížení disků, ale u disků je taková hodnota dost imaginární, takže i toto číslo sestřelilo kompletně výkon IO operací. Po nastavení na 2 % se všechno uklidnilo a tento týden už to bylo v pořádku.

A co bude dál

Během prvních pár dní v tomto týdnu se objevil problém, který nás mrzí. Nasazovaly jsme třeba nový PHP image s minoritní opravou composeru, což vedlo k neočekávanému výsledku, kdy v imagi nebylo rozšíření mbsting. Snažíme se problémy vychytat procesními změnami, ale i tak občas narazíme na něco nového. V tomto případě šlo o lidskou chybu. Necommitnul jsem změny v imagích do gitu a když Martin dělal ten malý fix, tak se tam moje změny nedostaly.

V dalších týdnech se zaměříme na zmíněný Cloud, emaily a DDOS útoky, ke kterým ještě vydáme jeden blogpost, protože to je komplikovaná oblast. Taky se chystáme zapnout v současné době vypnuté quoty. Mezitím bychom ještě rádi upravili naši homepage a změnili ceník tak, aby byl čitelnější. K ceníku také přidáme speciální blogpost.

Byl to náročný víkend i týden. Nejlépe to asi zprostředkuje tento tweet:

Držte nám palce a pokud narazíte na chybu, tak nám napište.

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í.

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ů.