WebSupport blog

Urobili sme 4 dôležité kroky pre zlepšenie kvality služieb

Návrat ku kvalite. Tri slová, ktoré sú aktuálne najfrekventovanejšie v celej firme. Od helpdesku až po marketing si je každý vedomý, čo sa od neho očakáva. Dnes vám prinášame ďalší blogpost o tom, ako pokračujú práce na zlepšovaní dostupnosti hostingových služieb.

1. Záložné pripojenie do Cogentu

Problém: Síce zdvojená konektivita, ale od jedného poskytovateľa.
Riešenie: Mať konektivitu aj od iného poskytovateľa, ideálne nadnárodného.

Už pred letom sme sa rozhodli, že okrem klasického pripojenia v dátovom centre od nášho poskytovateľa Lightstorm a jeho záložnej trasy musíme mať aj ďalšie pripojenia do internetu. Síce naše linky boli štandardne zdvojené, ale neochránilo nás to od možných problémov priamo u poskytovateľa alebo v peeringovom centre. Množstvo klientov a dostupnosť služieb, ktoré prevádzkujeme, sú priveľmi dôležité, aby sme v prípade nedostupnosti poskytovateľa kontektivity boli vystavení problémom.

Cieľom bolo pripojiť našu infraštruktúru k ďalšiemu poskytovateľovi konektivity tak, aby spĺňala niekoľko podmienok:

Rozhodli sme sa nakoniec pripojiť do siete Cogent, ktorá spĺňala všetky nami požadované podmienky, a konektivita od tejto spoločnosti bola priamo dostupná v dátovom centre.

Pripojenie sme testovali v niekoľkých fázach: Simulovali sme vypadnutie primárnej aj sekundárnej linky od Lightstormu, merali sme časy na aktiváciu záložného pripojenia a v neposlednej rade sme skúsili viac ako 24-hodinovú prevádzku počas bežného pracovného dňa. V auguste ste si tak mohli všimnúť, že naše servery nie sú dostupné cez klasické trasy:

ale cez trasy cez pripojenie od Cogentu:

2. Nová verzia Open vSwitch

Problém: Padajúce blade-y spôsobovali výpadky služieb.
Riešenie: Zistenie príčiny výpadku, aktualizácia chybného komponentu – Open vSwitch.

Počas leta sme narazili na problém, pri ktorom nám v náhodných intervaloch medzi 60 až 90 dňami padali blade servery – bez jasného vysvetlenia a spoločných znakov. Blade servery spolu s diskovým poľom NetApp tvoria srdce infraštruktúry, takže výpadok blade servera sa vždy podpísal na nedostupnosti niektorých služieb. Tým, že sme nevedeli chybu simulovať, museli sme čakať na jej opätovné spustenie v produkcii. Aby sme odhalili, čo sa presne stalo, nasadili sme tzv. Linux Crash Kernel, ktorý v prípade pádu systému zachytí aktuálny stav. Postupne sme pomocou Linux Crash Kernelu vysledovali, že blade servery padajú na virtuálnom switchi Open vSwitch a nasadili sme jeho opravenú verziu.

3. Z CFEngine na SaltStack

Problém: Zložitý nástroj pre konfiguračný manažment a jeho neobľúbenosť.
Riešenie: Výber nového nástroja demokratickým procesom a jeho postupná implementácia.

Jednou zo skrytých prác, ktoré sme započali v lete po dlhých diskusiách, bol prechod z konfig. manažmentu CFEngine na SaltStack. Po dlhej diskusii sme usporiadali súťaž v rámci IT tímu o novom konfig. manažmente, kde sme stanovili kritériá a každý z tímu mal vyskúšať jeden nástroj, spísať jeho výhody a nevýhody, vytvoriť vzorové zadanie a následne sme počas hlasovania vybrali nástupcu CFEngine. CFEngine ako nástroj sa neosvedčil ako úplne vhodný.

Ukázalo sa, že aj napriek tomu, že je napísaný v C jazyku, tak je relatívne náročný na čítanie z diskov, čo pri rozsahu nášho využitia nad centrálnym poľom spôsobovalo nárazovú záťaž. Postupom času sa vďaka jeho zložitosti začala zhoršovať kvalita nášho kódu a celkovo nástroj nebol obľúbený v tíme. Poučení z chýb sme sa rozhodli teda postupne presunúť automatizáciu infraštruktúry na nové riešenie postavené nad SaltStackom.

Treba však stále mať na pamäti, že nástroj na automatizáciu je iba tak dobrý, ako je jeho kód. O SaltStacku ešte určite napíšeme viac. Ak by ste však nevedeli vydržať, môžete si zatiaľ pozrieť aspoň slidy z prednášky nášho kolegu, ktorú mal na DevStars.cz v Brne 19.októbra.

4. Presun hostingov na dedikáče

Problém: Prevádzka hostingov nad centrálnym diskovým poľom nie je ideálna, čo sa týka rýchlosti ani stability.
Riešenie: Postupný presun hostingov na dedikované SSD servery.

Poslednou veľkou zmenou, ktorú už spomínal Michal vo svojom blogposte, je presun hostingov z centralizovaného diskového poľa na samostatné dedikované servery. Rozhodli sme sa tak po dlhých váhaniach, keďže centrálne riešenie malo množstvo výhod (ale aj nevýhod). Centralizované riešenie a prístup k súborom cez NFS protokol sa neukázalo ako vhodné a prinieslo viac problémov ako radosti.

Naše nové riešenie je postavené na 1U serveroch s čisto SSD diskami v raidz2 (obdoba raid6), 64 alebo 128GB RAM, najnovšími 6-jadrovými CPU – Intel Xeon 2620v3 a Ubuntu Linuxom. Technicky zdatnejší si mohli všimnúť, že na serveroch používame súborový systém ZFS, ktorý nám zabezpečuje pravidelné konzistentné zálohy pomocou snapshotov a ich replikáciu na backup serveri, odkiaľ ich vieme v prípade fatálneho zlyhania serveru „poslať“ v priebehu pár desiatok minút na náhradný server a tak obnoviť prevádzku.

Toto riešenie z pohľadu biznis kontinuity poskytuje najlepší pomer medzi pravdepodobnosťou výpadku servera, jeho dopadom na prevádzku a časom na obnovu služby v prípade fatálneho zlyhania.

Vďaka zmene architektúry a nasadením OPCache v PHP sme dokázali zvýšiť rýchlosť načítania stránok na najrýchlejšiu možnú úroveň, viac ako 99% požiadaviek ide z pamäte serverov a v prípade potreby čítania z diskov vieme na jednotlivých serveroch získať desiatky tisíc IOPS.


V týchto dňoch sa venujeme tvorbe nového srdca OpenStack systému a budovaniu novej farmy pre databázy, ktorá je veľmi podobná už spomenutej architektúre pre webové servery. Radi by sme vám postupne prinášali aj krajší a novší WebAdmin, do ktorého vývoja sa dnes môžete zapojiť, sme otvorení nápadom na vylepšenia.

[mc4wp_form]

Komentáre