Historie a současnost architektury služby VPS – storage

Pronájem virtuálních serverů (VPS) jsme začali nabízet před něco před třemi lety, protože v té době se začínala celá oblast virtualizace objevovat i u nás na Slovensku. Začínali jsme asi jako většina podobných společností – našel se volný server, nainstalovala první vygooglena virtualizační technologie a služba byla na světě. Vybrali jsme si Xen, toho času ve verzi 3.0 i proto, že se nacházel již přímo v repositářích Debianu.

Za tři roky se služba rozrostla na téměř tři stovky virtuálních serverů na dvanácti fyzických serverech. V říjnu loňského roku jsme si však uvědomili, že technické řešení, jak jsme ho nastavili v začátcích, nemůže pokračovat, protože má mnohé problémy. Virtuální servery jsme měli uložené klasicky – na serveru v LVM oddílech. Je to nejjednodušší a nejrychlejší forma provozu virtuálních serverů, ale náročnější na administraci. Důvodů je několik:

• škálovatelnost – pokud server narazil na své fyzické možnosti (počet CPU, paměťových slotů,disků …) bylo nutné servery přesunout. To znamená, že bylo třeba kontaktovat zákazníka, dohodnout výpadek – obvykle pozdě v noci – a následnou migraci na jiný server.
• odolnost vůči výpadkům – téměř žádná. Pokud má server, na kterém běží virtuální servery, vážné hardwarové nebo softwarové problémy, třeba často vypnout všechny služby, aby je bylo možné vyřešit. Všechny hostované VPS jsou tehdy mimo, dokud není problém vyřešen.
• otravování zákazníků kvůli systémové údržbě – každý server je občas nutné restartovat nebo upgradovat. To samozřejmě vyžaduje poslat zákazníkům e-mail a upozornit je na plánovaný výpadek.
• výkon – pokud byly na serveru problémy s výkonem (například diskové IO), nebylo vždy možné problém vyřešit okamžitě, protože přesun virtuálních serverů by jen zhoršil situaci.Problém se tedy řešil určením priority IO scheduler, případně výměnou IO scheduler atd..
• nerovnoměrné využití zdrojů serveru – některé servery měli ještě dost RAM, ale žádnou diskovou kapacitu – nebo naopak – neměli RAM, ale dostatek diskového prostoru. Občas se to se řešilo ATA-over-Ethernet protokolem. Pomocí něj bylo možné disky exportovat a spustit na jiném serveru. Časem se to ale ukázalo jako nevhodné řešení, protože vznikaly řetězce závislostí. Pokud vypadl jeden server, byly nedostupné i ty virtuální servery, které běžely jinde, ale disk měli zpřístupněny přes síť.

Koncept

Vrátili jsme se úplně na začátek a zamysleli jsme se, co je v podstatě virtuální server:

úložiště dat + Xen = virtuální server

Virtuální server je tedy tvořen úložištěm dat (storage) a virtualizační technologií (v našem případě Xen). Abychom vyřešili zmiňované problémy, bylo nutné tyto dva komponenty rozdělit na samostatnou infrastrukturu, aby mohly růst samostatně podle vlastních potřeb. Výsledkem bude efektivnější využití serverů a lepší možnosti služby.

Na oddělení jsme použili diskové pole. Virtuální servery se k němu připojí pomocí různých protokolů resp. technologií jako iSCSI, AoE, NFS, FC apod.. Samotné Xen servery jsme vyřešili poměrně jednoduše, protože již delší dobu jsme chtěli využívat blade-technologii a celou službu VPS hardwarově sjednotit. Kromě virtualizace využíváme tyto blade-servery i jako databázové servery a web-servery.

Oddělení má ještě jeden příznivý efekt. V případě, že má samotný Xen server problémy, které vyžadují restart nebo dojde k jinému problému, který způsobuje nedostupnost virtuálních serverů na něm běžících, je nejrychlejším řešením spustit je  jinde a problémový server vyřešit až potom. Je to díky tomu, že VPS nejsou vázány na konkrétní Xen server, protože data se nacházejí na storage serverech.

Větší problém nastává v momentě, kdy si uvědomíme, že služba je jen taková dobrá, jak dobrý je storage, na kterém má uložená data. Diskové pole svádí k tomu umístit na něj vše, čím často vznikne centralizovaná architektura. Ta vytváří SPOFA (Single Point Of Failure), takže jeho nedostupnost způsobuje nedostupnost všech služeb, které jsou na něj navázány. A i když disková pole bývají kvalitní, s redundantními zdroji, hot spare disky atd.., Nebylo to řešení, kterým jsme se chtěli ubírat. Alespoň ne, dokud nenajdeme řešení některých očekávaných problémů. Bylo třeba tedy definovat, co budeme dělat v momentě pokud:

• diskové pole přestane stíhat vyřizovat požadavky a VPS začnou čekat na data (IO wait)
• budeme nuceni provést systémovou údržbu
• diskové pole se zaplní a bude třeba kopírovat data jinam
• diskové pole nebude fungovat

 

Lepší než jedno diskové pole jsou dvě disková pole. Ještě lepší je, když se diskové pole vzájemně replikují a úplně nejlépe, když se každé diskové pole nachází v jiném datacentru.Podle možností co nejdále od sebe.

Určitě si mnozí vzpomínáte naši loňskou migraci z jednoho datacentra do datacenter dvou.Výsledkem tohoto úsilí je mimo jiné virtualizační a storage platforma s množstvím skvělých vlastností:

• Vysoká dostupnost – data jsou mirrorovány na svou protilehlou stranu. Kdykoliv je možné přepnout server, který poskytuje virtuálním serverem data. Vzdušná vzdálenost mezi oběma datacentry je cca 13 km.
• Vertikální škálovatelnost – dokážeme vytvořit tolik párů, kolik budeme potřebovat, přičemž každý z nich může exportovat data na virtuální server. Virtuální server může mít připojené disky z různých párů a nad tím vytvořené diskové pole s RAID1, RAID5 ….
• Horizontální škálovatelnost – jelikož samotné disky jsou pomalé, zvyšujeme rychlost IO operací pomocí PCIe flash-karet. Probíhá na nich cachování zápisů i čtení.
• Manažovatelnost – je dosažena použitím LVM na straně serveru i na straně Xen serveru
• Dostupnost pod různými protokoly (NFS, FTP, iSCSI apod..) – Momentálně je podporováno pouze iSCSI, zbývající protokoly připravujeme
• On-line migrace – schopnost přesunout obraz paměti virtuálního serveru na jiný Xen server přímo za běhu. Hodí se v případě předpokládaného výpadku serveru.
• On-line změna parametrů – možnost měnit velikost, počet CPU, paměť a storage za běhu
• On-line migraci storage virtuálního serveru – možnost vyměnit storage VPS za běhu na jiný pár
• Xen 4

Storage platformu jsme si pracovně nazvali Websupport Storage Platform nebo i WSP.

Technické řešení WSP

Výsledné řešení je postaveno na serverech v páru. Nazýváme to WSP pár. Každý pár je mezi sebou mirrorovaný pomocí technologie DRBD a o clusterový management se stará RedhatCluster Suite na CentOS 5.6. Průřez softwarových vrstev jednoho uzlu (server, který je součástí clusteru) je následující:

Server

Server se skládá z těchto komponent:

• Supermicro SYS-6026TT HDRF (v jednom serverovém šasi se nacházejí dva servery)
• 12 × 2 TB disky (6 disků / uzel)
• 8 GB RAM
• Intel Xeon E5506 2.13 GHz

Servery jsou zapojeny do dvou nezávislých elektrických větví, které jsou chráněny datacentrem ve  formě UPS a motor generátorem. Konektivita serveru je chráněna připojením ethernetových karet do dvou nezávislých switchů.

RAID10

RAID10 nám ze šesti 2 TB disků vytvoří 6 TB storage. Naše testování RAID10 vs. RAID5ukázalo, že pro naše potřeby se lépe hodí RAID10:

• rychlost zápisu byla oproti RAID5 třikrát vyšší
• negativní účinky výpadku disku se týkají pouze jednoho páru. V případě RAID5 jsou do rebuild procesu zapojeny všechny disky, což výrazněji postihne všechny provozované služby.
• RAID10 je jen o kopírování dat, kdežto RAID5 je nutné počítat paritu, přičemž pokud nejsou data na disku správně zarovnány, vzniká read-modify-write chování.

Pro zvýšení spolehlivosti používáme v mirrorovaných párech disky od různých výrobců. Tímto způsobem eliminujeme i možné výrobní vady.

Flashcache

I když samotné diskové pole má propustnost přesahující rychlost 1 Gbit sítě, věděli jsme, že řešení narazí na své hranice, pokud do něj tradičně nezakomponujeme flash disky, protože dříve než narazíme na strop propustnosti, narazíme na strop latence resp. množství provedených IO operací. Podle našich měření, zvládá pole cca 500 random IO / s což se nedá srovnat s 100 000 ranodm IO / s, které dokáže dát běžná flash karta.

Jelikož nám už nezůstali volné pozice pro SATA SSD disky, použili jsme flash kartu montovanou do PCIe.

Flashcache  jsme nakonfigurovali tak, aby cachoval IO operace na tuto kartu. Zvýšila se tímcelková rychlost, resp. rychlost odezvy IO systému. Momentálně je na cachování nasazena 220GB verze. V průměru sledujeme 80% hit rate při čtení (procento requestu vybavených z flashkarty) a 70% hit rate zápisů, z čehož 30% tvoří dirty hit rate zápisy (vzniká při updatování dat,když jeden zápis zapíše data na to jisté místo jako dřívější zápis, přičemž se tento dřívější ještě nachází na flash kartě resp. v queue k zápisu na disk). Jak je vidět na obrázku, účinnost tohoto řešení je tak vysoká, že disky jsou často nepoužívané.

 

DRBD

DRBD zajišťuje synchronizaci dat mezi dvěma uzly. Klastr je v konfiguraci Primary – Slave. Dlouho jsme se pokoušeli nasadit řešení Primary – Primary. Chtěli jsme dosáhnout aby obauzly byly zároveň aktivní, přístupné pro zápis i čtení. Nakonec jsme takové řešení zavrhli,protože v našich podmínkách by představovalo jisté riziko, které by mohlo vyústit v binárníguláš na obou stranách. Nastavení Primary – Slave považujeme za bezpečnější z pohleduintegrity dat. Primární uzel se nachází vždy blíže k serverům tak, aby byla latence minimální aaby data netekli přes propojení mezi datacentry.

LVM

LVM jsme zvolili pro jeho flexibilitu, kterou zjednodušuje administraci. Ceníme si zejména možnosti tagovat jednotlivé LVM oddíly, což zjednodušuje skriptování. Stejně se nám líbí i možnost vytváření snapshotů pro zálohovací účely. V jednotlivých LVM oddílech vytváříme ještě další vnořené LVM,které aktivujeme na Xen serveru. Proč vytvářet LVM v LVM? Jak jsem zmínil již výše, věděli jsme, že může nastat situace, že pole resp. server přestane prostě stíhat,nebo se zaplní jeho kapacita. Přesně v takovém případě se nám hodí schopnost LVM za běhu přesunout data z jednoho fyzického disku jiný.

 

Jak to funguje

Na Xen server exportujeme LVM oddíl, ve kterém se nachází další LVM oddíl (nazvěme hoLVMB). Na straně Xen serveru již vidíme pouze LVMB s oddíly root a swap. Z root oddíluvirtuální server boot, na swap oddílu swapu. Jakmile uznáme, že je nutné přesunout storagevirtuálního serveru na jiný WSP pár, vytvoříme na novém WSP páru LVM oddíl se stejnou velikostí. Nový storage připojíme na straně Xen serveru do LVMB. Následně pomocí utilitypvmove řekneme LVM, aby přesunul datové bloky ze starého storage na storage na novémLVM páru. LVM se již následně stará o to, aby IO operace směřovaly na správný storage.

Operaci jsme otestovali v laboratorních podmínkách i v ostrém provozu. V obou případechproběhla bez problémů. Pochopitelně, na straně VPS dochází k vyššímu IO wait, což je ale v takovém případě logické.

 

Dm-ioband

dm-ioband je vrstva určená na škrcení propustnosti k jednotlivým LVM oddílem. Momentálně ji nevyužíváme, protože propustnost IO systému je vyšší než propustnost 1Gbit sítě.

iSCSI

iSCSI protokol slouží pro samotný export disků na jednotlivé Xen servery, kde se tváří jako běžně SCSI disky, se kterými je možné pracovat jako s běžnými disky.

Jak iSCSI target server používáme IETD, který ale neví online reportovat změnu velikosti LVModdílu, takže je nutné VPS vypínat. Úspěšně jsme však otestovali řešení na bázi scst, kde tato funkcionalita možná je.

Storage cluster

Řešení vysoké dostupnosti vyžaduje mít takové storage servery dva. Jelikož jsme využili naši současnou serverovou architekturu, umístili jsme servery téhož WSP páru do různých datacenter. Takové disaster recovery řešení chrání data před katastrofálními událostmi jako výpadek celého datacentra nebo jeho fyzické zničení.

 

O klastr se stará software pro manažování služeb clusteru. My jsme použili Redhat ClusterSuite. Tento software se stará, aby při neplánovaném výpadku jednoho uzlu, došlo k migraci služeb na jiný server. Migrace služeb se děje formou migrace IP adresy, změnou DRBD naPrimary (na uzlu, který byl dosud slave) a nastartováním iSCSI serveru na žijící uzel. RHCS se zároveň stará, aby byl neaktivní uzel zabit pomocí principu STONITH (Shoot The Other Node In The Head). V praxi to znamená, že pokud přestane uzel na druhé straně reagovat, je přes alternativní komunikační kanál zabit restartováním přes IPMI, nebo vypnutím elektřiny přes IPzásuvku.

Provoz

Jsou to již téměř tři měsíce, kdy je první WSP pár WSP-a nasazený v produkci (měsíc předtím jsme ho podrobili testování). Za tento čas jsme měli relativně bezproblémový provoz – až na jeden případ, kdy jsme měli problémy s propojením datacenter. Problém jsme vyřešili úpravou konfigurace (delší timeouty) a umístěním primárního uzlu do stejného datacentra jako virtuální servery, které na něm mají uskladněny svá data.

V praxi se ukázalo, že je možné mít aktivní uzel přepnut na druhé straně města, než se nacházejí samotný virtuální servery. Zhruba dva týdny nám tedy tekly data přes téměř přescelou Bratislavu bez jakýchkoliv problémů. Dokonce s lepším výkonem, protože jsme v té době měli nainstalovanou flash kartu pouze na tom jednom serveru. Všechny naše virtuální servery mladší než dva měsíce jsou již defaultně vytvořeny na této nové architektuře. Za tu dobu jsme již stihli úspěšně upgradovat jednotlivé uzly (aniž to ovlivnilo vaše služby) a úspěšně otestovat migraci na jiný storage (zatím pouze v rámci téhož páru). Zjistili jsme, že v případě výpadku jednoho uzlu resp. cílené migrace služby na druh7 uzel (například kvůli údržbě), dochází k cca.4-20s nedostupnosti storage. To by nemělo ovlivnit virtuální servery, pokud mají data, s nimiž pracují nacachované v operační paměti.

Závěr

Při nové architektuře jsme se soustředili hlavně na otázku storage řešení virtuálních serverů.Pokud vás zajímá, zda ještě budou nějaké výpadky, mohu říci jen tolik, že z pohledu hardwarového i softwarového řešení a množství redundance jsme provedli mnohem více, než bylo nutné. Věříme, že to přinese očekávaný efekt.

V těchto dnech pracujeme na dalším páru WSP-b. Bude o něco více up-to-date, protože je postaveno na CentOS 6 a místo RHCS je použit Pacemaker. Takových párů časem víc a budete mít možnost si vyskládat svá vlastní řešení.

Virtuální servery, které existovaly na původní architektuře postupně přesouváme na novou. O přesném termínu a čase jejich přesunu budeme naše zákazníky včas informovat.

Autor: Tomáš Čorej, senior sysadmin