História a súčasnosť architektúry služby VPS – storage

Doba čítania: 12 min.

Prenájom virtuálnych serverov (VPS) sme začali ponúkať pred niečo vyše troma rokmi, keďže sa v tom čase začínala celá oblasť virtualizácie objavovať aj u nás na Slovensku. Začínali sme asi ako väčšina podobných spoločností  – našiel sa voľný server, nainštalovala sa prvá vygooglena virtualizačná technológia a služba bola na svete . Vybrali sme si Xen, toho času vo verzii 3.0 aj preto, lebo sa nachádzal už priamo v repozitároch Debianu.

Za tri roky sa služba rozrástla na takmer tri stovky virtuálnych serverov na dvanástich fyzických serveroch. V októbri minulého roka sme si však uvedomili, že technické riešenie, ako sme ho nastavili v začiatkoch, nemôže pokračovať, pretože má mnohé problémy. Virtuálne servery sme mali uložené klasicky – na serveri v LVM oddieloch. Je to najjednoduchšia a najrýchlejšia forma prevádzky virtuálnych serverov, no náročnejšia na administráciu. Dôvodov je viacero:

• škálovateľnosť – ak server narazil na svoje fyzické možností (počet CPU, pamäťových slotov, diskov…) bolo nutné servery presunúť. To znamená, že bolo treba kontaktovať zákazníka, dohodnúť výpadok – obyčajne neskoro v  noci – a následnú migráciu na iný server.
• odolnosť voči výpadkom – takmer žiadna. Ak má server, na ktorom bežia virtuálne servery vážne hardvérové alebo softvérové problémy, treba často vypnúť všetky služby, aby ich bolo možné vyriešiť. Všetky hostované VPS sú vtedy mimo, pokým nie je problém vyriešený.
• otravovanie zákazníkov kvôli systémovej údržbe – každý server je občas nutné reštartovať alebo upgradovať. To samozrejme vyžaduje poslať zákazníkom e-mail a upozorniť ich na plánovaný výpadok.
• výkon – pokiaľ boli na serveri problémy s výkonom (napríklad diskové IO), nebolo vždy možné problém vyriešiť okamžite, pretože presun virtuálnych serverov by len zhoršil situáciu. Problém sa teda riešil určením priority na IO scheduleri, prípadne výmenou IO scheduleru atď.
• nerovnomerné využitie zdrojov servera – niektoré servery mali ešte dosť RAM, ale žiadnu diskovú kapacitu – alebo naopak  – nemali RAM, ale dostatok diskového priestoru. Občas sa to sa riešilo ATA-over-Ethernet protokolom. Pomocou neho bolo možné disky exportovať a spustiť na inom serveri. Časom sa to ale ukázalo ako nevhodné riešenie, pretože  vznikali reťazce závislostí. Ak vypadol jeden server, boli nedostupné aj tie virtuálne servery, ktoré bežali inde, ale disk mali sprístupnené cez sieť.

Koncept

Vrátili sme sa úplne na začiatok a zamysleli sme sa, čo je v podstate virtuálny server:

úložisko dát + Xen = virtuálny server

Virtuálny server je teda tvorený úložiskom dát (storage) a virtualizačnou technológiou (v našom prípade Xen). Aby sme vyriešili spomínané problémy, bolo nutné tieto dva komponenty rozdeliť na samostatnú infraštruktúru, aby mohli rásť samostatne podľa vlastných potrieb. Výsledkom bude efektívnejšie využitie serverov a lepšie možnosti služby.

Na oddelenie sme použili diskové pole. Virtuálne servery sa k nemu pripoja pomocou rôznych protokolov resp. technológií ako iSCSI, AoE, NFS, FC apod. Samotné Xen servery sme vyriešili pomerne jednoducho, keďže už dlhší čas sme chceli využívať blade-technológiu a celú službu VPS hardvérovo zjednotiť. Okrem virtualizácie využívame tieto blade-servery aj ako databázové servery a web-servery.

Oddelenie má ešte jeden priaznivý efekt. V prípade, ak má  samotný Xen server problémy, ktoré si vyžadujú reštart alebo dôjde k inému problému, ktorý spôsobuje nedostupnosť virtuálnych serverov na ňom bežiacich, je najrýchlejším riešením ich spustiť inde a problémový server vyriešiť až potom. Je to vďaka tomu, že VPS nie sú viazané na konkrétny Xen server, pretože dáta sa nachádzajú na storage serveroch.

Väčší problém nastáva v momente, keď si uvedomíme, že služba je len taká dobrá, aký dobrý  je storage, na ktorom má uložené dáta. Diskové pole zvádza k tomu umiestniť na neho všetko, čím často vznikne centralizovaná architektúra. Tá vytvára SPOF (Single Point Of Failure), takže jeho nedostupnosť spôsobuje nedostupnosť všetkých služieb, ktoré sú na neho naviazané. A aj keď diskové polia bývajú kvalitné, s redundantnými zdrojmi, hot spare diskami atď., nebolo to riešenie, ktorým sme sa chceli uberať. Aspoň nie dovtedy,  kým nenájdeme riešenia niektorých očakávaných problémov. Bolo treba teda definovať, čo budeme robiť v momente ak:

• diskové pole prestane stíhať vybavovať požiadavky a VPS začnú čakať na dáta (IO wait)
• budeme nútení vykonať systémovú údržbu
• diskové pole sa zaplní a bude potrebné kopírovať dáta inam
• diskové pole nebude fungovať

Lepšie ako jedno diskové pole sú dve diskové polia. Ešte lepšie je, keď sa diskové polia vzájomne replikujú a úplne najlepšie, keď sa každé diskové pole nachádza v inom datacentre. Podľa možností čo najďalej od seba.

Určite si mnohí spomínate našu minuloročnú migráciu z jedného datacentra do datacentier dvoch. Výsledkom tohto úsilia je okrem iného aj virtualizačná a storage platforma s množstvom skvelých vlastností:

• vysoká dostupnosť – dáta sú mirrorované na svoju protiľahlú stranu. Kedykoľvek je možné prepnúť server, ktorý poskytuje virtuálnym serverom dáta. Vzdušná vzdialenosť medzi oboma datacentrami je cca 13 km.
• vertikálna škálovateľnosť – dokážeme vytvoriť toľko párov, koľko budeme potrebovať, pričom každý z nich môže exportovať dáta na virtuálny server. Virtuálny server môže mať pripojené disky z rôznych párov a nad tým vytvorene diskové pole s RAID1,RAID5… .
• horizontálna škálovateľnosť – keďže samotné disky sú pomalé, zvyšujeme rýchlosť IO operácií pomocou PCIe flash-kariet. Prebieha na nich cachovanie zápisov aj čítania.
• manažovateľnosť – je dosiahnutá použitím LVM na strane servera i na strane Xen servera
• dostupnosť pod rôznymi protokolmi (NFS, FTP, iSCSI apod.) – momentálne je podporované iba iSCSI, zvyšné protokoly pripravujeme
• on-line migrácia – schopnosť presunúť obraz pamäte virtuálneho servera na iný Xen server priamo za behu. Hodí sa v prípade predpokladaného výpadku servera.
• on-line zmena parametrov – možnosť meniť veľkosť, počet CPU, pamäť a storage za behu
• on-line migráciu storage virtuálneho servera – možnosť vymeniť storage VPS za behu na iný pár
• Xen 4

Storage platformu sme si pracovne nazvali WebSupport Storage Platform alebo aj WSP.

Technické riešenie WSP

Výsledné riešenie je postavené na serveroch v páre. Nazývame to WSP pár. Každý pár je medzi sebou mirrorovaný pomocou technológie DRBD a o klastrový manažment sa stará Redhat Cluster Suite na CentOS 5.6 .  Prierez softvérových vrstiev jedného uzla (server, ktorý je súčasťou klastra) je takýto:

Server

Server pozostáva z týchto komponentov:

• Supermicro SYS-6026TT HDRF (v jednej serverovej šasi sa nachádzajú dva servery)
• 12 × 2 TB disky (6 diskov / uzol)
• 8 GB RAM
• Intel Xeon E5506 2.13 GHz

Servery sú zapojené do dvoch nezávislých elektrických vetiev, ktoré sú chránene datacentrom vo forme UPS a motor generátorom. Konektivita servera je chránená pripojením ethernetových kariet do dvoch nezávislých switchov.

RAID10

RAID10 nám zo šiestich 2 TB diskov vytvorí 6 TB storage. Naše testovanie RAID10 vs. RAID5 ukázalo, že pre naše potreby sa lepšie hodí RAID10:

• rýchlosť zápisu bola oproti  RAID5 trikrát vyššia
• negatívne účinky výpadku disku sa týkajú iba jedného páru. V prípade RAID5 sú do rebuild procesu zapojené všetky disky, čo  výraznejšie postihne všetky prevádzkované služby.
• RAID10 je len o kopírovaní dát, kým RAID5 je nutné rátať paritu, pričom ak nie sú dáta na disku správne zarovnané, vzniká read-modify-write správanie.

Pre zvýšenie spoľahlivosti používame v mirrorovaných pároch disky od rôznych výrobcov. Takto eliminujeme aj možné výrobné chyby.

Flashcache

Aj keď samotné diskové pole ma priepustnosť presahujúcu rýchlosť 1 Gbit siete, vedeli sme, že riešenie narazí na svoje hranice, pokiaľ do neho nezakomponujeme flash disky, pretože  skôr ako narazíme na strop priepustnosti, narazíme na strop latencie resp. množstva vykonaných IO operácií. Podľa našich meraní, zvláda pole cca 500 random IO / s čo sa neda porovnať s 100 000 ranodm IO / s , ktoré dokáže dať bežná flash karta.

Keďže nám už nezostali voľné pozície pre SATA SSD disky,  použili sme flash kartu montovanú do PCIe.

Flashcache sme nakonfigurovali tak, aby cachoval IO operácie na túto kartu. Zvýšila sa tým celková rýchlosť, resp. rýchlosť odozvy IO systému. Momentálne je na cachovanie nasadená 220 GB verzia. V priemere sledujeme 80% hit rate pri čítaní (percento requestov vybavených z flash karty ) a 70% hit rate zápisov, z čoho 30 % tvoria dirty hit rate zápisy(vzniká pri updatovaní dát, keď jeden zápis zapíše dáta na to iste miesto ako skorší zápis, pričom sa tento skorší ešte nachádza na flash karte resp. v queue na zápis na disk). Ako vidno na obrázku, účinnosť tohto riešenia je taká vysoká, že disky sú často nepoužívané.

DRBD

DRBD sa stará o synchronizáciu dát medzi dvoma uzlami. Klaster je v konfigurácii Primary – Slave. Dlho sme sa pokúšali nasadiť riešenie Primary – Primary. Chceli sme dosiahnuť aby oba uzly  boli zároveň aktívne, prístupné pre zápis aj čítanie. Nakoniec sme takéto riešenie zavrhli, pretože v našich podmienkach by predstavovalo isté riziko, ktoré by mohlo vyústiť v binárny guláš na oboch stranách. Nastavenie Primary – Slave považujeme za bezpečnejšie z pohľadu integrity dát. Primárny uzol sa  nachádza vždy bližšie k serverom tak, aby bola latencia minimálna a aby dáta netiekli cez prepoj medzi datacentrami.

LVM

LVM sme zvolili pre jeho flexibilitu, ktorou zjednodušuje administráciu. Ceníme si najmä možnosť tagovať  jednotlivé LVM oddiely, čo zjednodušuje skriptovanie. Rovnako sa nám páči aj možnosť vytvárania snapshotov pre zálohovacie účely. V jednotlivých LVM oddieloch vytvárame ešte ďalšie vnorené LVM, ktoré aktivujeme na Xen serveri. Prečo vytvárať LVM v LVM? Ako som spomenul už vyššie, vedeli sme, že môže nastať situácia, že pole resp. server prestane jednoducho stíhať, alebo sa zaplní jeho kapacita. Presne v takom prípade sa nám hodí schopnosť LVM za behu presunúť dáta z jedného fyzického disku iný.

Ako to funguje

Na Xen server exportujeme LVM oddiel, v ktorom sa nachádza ďalší LVM oddiel (nazvime ho LVMB). Na strane Xen servera už vidíme iba LVMB s oddielmi root a swap . Z root oddielu virtuálny server bootuje, na swap oddiele swapuje. V momente, keď uznáme, že je nutné presunúť storage virtuálneho servera na iný WSP pár, vytvoríme na novom WSP páre LVM oddiel s rovnakou veľkosťou. Nový storage pripojíme na strane Xen servera do LVMB . Následne pomocou utility pvmove prikážeme LVM, aby presunul dátové bloky zo starého storage na storage na novom LVM páre. LVM sa už následne stará o to, aby IO operácie smerovali na správny storage.

Operáciu sme otestovali v laboratórnych podmienkach aj v ostrej prevádzke. V oboch prípadoch prebehla bez problémov. Pochopiteľne, na strane VPS dochádza k vyššiemu IO wait, čo je ale v takomto prípade logické.

dm-ioband

dm-ioband je vrstva určená na škrtenie priepustnosti k jednotlivým LVM oddielom. Momentálne ju nevyužívame, pretože priepustnosť IO systému je vyššia než priepustnosť 1Gbit siete.

iSCSI

iSCSI protokol slúži pre samotné exportovanie diskov na jednotlivé Xen servery, kde  sa tvaria ako bežne SCSI disky, s ktorými je možné pracovať ako s bežnými diskami.

Ako iSCSI target server používame IETD, ktorý ale nevie online reportovať zmenu veľkosti LVM oddielu, takže je nutné VPS vypínať . Úspešne sme však otestovali riešenie na báze scst , kde táto funkcionalita možná je.

Storage cluster

Riešenie vysokej dostupnosti si vyžaduje mať takéto storage servery dva. Keďže sme využili našu súčasnú  serverovú architektúru, umiestnili sme servery toho istého WSP páru do rôznych datacentier.  Takéto disaster recovery riešenie chráni  dáta pred katastrofickými udalosťami ako výpadok celého datacentra alebo jeho fyzické zničenie.

O klaster sa stará softvér pre manažovanie služieb klastra. My sme použili Redhat Cluster Suite . Tento softvér sa stará, aby pri neplánovanom výpadku jedného uzla, došlo k migrácii služieb na iný server. Migrácia služieb sa deje formou migrácie IP adresy, zmenou DRBD na Primary (na uzle, ktorý bol doteraz Slave) a naštartovaním iSCSI servera na žijúci uzol. RHCS sa zároveň stará, aby bol neaktívny uzol zabitý pomocou princípu STONITH (Shoot The Other Node In The Head). V praxi to znamená, že ak prestane uzol na druhej strane reagovať, je cez alternatívny komunikačný kanál zabitý reštartovaním cez IPMI, alebo vypnutím elektriny cez IP zásuvku.

Prevádzka

Sú to už takmer tri mesiace, odkedy je prvý WSP pár WSP-a nasadený v produkcii (mesiac predtým sme ho podrobili testovaniu). Za tento čas sme mali relatívne bezproblémovú prevádzku – až na jeden prípad, kedy sme mali problémy s prepojením datacentier.  Problém sme vyriešili úpravou konfigurácie (dlhšie timeouty) a umiestnením primárneho uzla do rovnakého datacentra ako virtuálne servery, ktoré na ňom majú uskladnené svoje dáta.

V praxi sa ukázalo, že je možné mať aktívny uzol prepnutý na druhej strane mesta, ako sa nachádzajú samotné virtuálne servery. Zhruba dva týždne nám teda tiekli dáta cez takmer cez celú Bratislavu bez akýchkoľvek problémov. Dokonca s lepším výkonom, lebo sme v tom čase mali nainštalovanú flash kartu iba na tom jednom serveri.  Všetky naše virtuálne servery mladšie ako dva mesiace sú už defaultne vytvorené na tejto novej architektúre. Za tento čas sme už stihli úspešne upgradovať jednotlivé uzly (bez toho, aby to ovplyvnilo vaše služby) a úspešne otestovať migráciu na iný storage (zatiaľ iba v rámci toho istého páru). Zistili sme, že v prípade výpadku jedného uzla resp. cielenej migrácie služby na druhu uzle (napríklad kvôli údržbe), dochádza k cca. 4-20s nedostupnosti storage. To by nemalo ovplyvniť virtuálne servery, pokiaľ majú dáta, s ktorými pracujú nacachované v operačnej pamäti.

Záver

Pri novej architektúre sme sa sústredili hlavne na otázku storage riešenia virtuálnych serverov. Ak vás zaujíma, či ešte budú nejaké výpadky, môžem povedať len toľko, že z pohľadu hardvérového i  softvérového riešenia a množstva redundancie sme vykonali oveľa viac, ako bolo potrebné. Veríme, že to prinesie očakávaný efekt.

V týchto dňoch pracujeme na ďalšom páre WSP-b. Bude o niečo viac up-to-date, pretože je postavené na CentOS 6 a miesto RHCS je použitý Pacemaker. Takýchto párov časom viac a budete mať možnosť si vyskladať svoje vlastné riešenia.

Virtuálne servery, ktoré existovali na pôvodnej architektúre postupne presúvame na novú. O presnom termíne a čase ich presunu budeme našich zákazníkov včas informovať.

Autor: Tomáš Čorej, senior sysadmin