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


  • Zdieľať na Google+

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

Ako vidno, riešenie každého typu problému si vyžadovalo minimálne kontaktovanie klienta a dohodnutie času migrácie na iný server. To je z dlhodobého hľadiska neúnosné. Nastal teda čas na niečo nové.

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.

blade serverOddelenie 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:

Softvérové vrstvy klastrového uzla

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

Stĺpce označené ako read zobrazujú množstvo čítaní z daného disku.

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

Komentáre

  • Jaro
    Odpovedať
    Autor
    Jaro

    Zacinam mat pocit ze WebSupport pripravuje plan na ovladnutie sveta 🙂

    V kazdom pripade sa vsak tesim ze moj virtual je v takych dobrych rukach. Len tak dalej.

    • Jano
      Odpovedať
      Autor
      Jano

      Po prečítaní tohto článku mám aj ja taký pocit, websupport mi pripadá ako slovenský google o-)))

  • Pavel
    Odpovedať
    Autor
    Pavel

    Zajímalo by mě, co za HW používáte jako storage. Prozradíte ? 🙂

    • tomas.corej
      Odpovedať
      Autor
      tomas.corej

      Asi som to nie velmi jasne opisal, ale ako diskove pole je pouzity server opisany v casti Server. Storage su klasicke 2TB disky Hitachi a Samsung.

  • alian
    Odpovedať
    Autor
    alian

    Super clanok, cim Xen spravujete? Mate nieco vlastne alebo open-source?

    • tomas.corej
      Odpovedať
      Autor
      tomas.corej

      Mame svoje vlastne riesenie ktore je priamo prepojene s webadminom odkial sa tahaju parametre VPS . Skusali sme aj rozne open-source xen manazovacie systemy, ale ani jeden nam velmi nesadol.

  • Jan
    Odpovedať
    Autor
    Jan

    skoda ze clanok nebol zverejneny pred pohovorom 🙂

  • n00b
    Odpovedať
    Autor
    n00b

    laika a boss 🙂

  • Nudzo
    Odpovedať
    Autor
    Nudzo

    http://www.nexentastor.org/
    Staci poklikat…
    PCIe flash pre ZIL a SATA flash disky pre cache. COMSTAR ked nestaci 1GbE, tak FC-HBA, alebo 10GbE…
    Ak je neudrzatelna potreba odchujit si to na cmdline, tak: http://openindiana.org/ Btw KVM build-in, ale do produkcie by som este asi pockal…

    • tomas.corej
      Odpovedať
      Autor
      tomas.corej

      dik za hint.

      kedze u nas tradicne pouzivame linux, bola volba jasna.

      ad GUI vs cmdline) osobne si myslim ze konfiguraciou systemov cez GUI clovek dost strati, zvlast v pripade ak je nutne riesit niektore problemy. prikazova riadka nic nezastiera, clovek lepsie pochopi system a jeho nuancie takze potom v pripade debugovania, vypadkov a podobne vie lepsie a rychlejsie reagovat.

      ak si to teda clovek odkruti na nizkej urovni moze veselo pouzivat GUI ale opacne nie. vybrali sme si teda tazsiu cestu.

      • Nudzo
        Odpovedať
        Autor
        Nudzo

        Linux sa na setko nehodi… to je fakt… aj napriek tradiciam (prip. fundamentalizmu)… 😉 Seriozny disk storage s Linuxom, to sa neda, ale zase ked by malo ist o dokumentovy storage, tak to uz je ina pesnicka…
        Ad GUI – konkretne u NexentaStor davam prednost tomu GUI, je tam fakt ze setko, co treba na ovladanie storage appliance vratane monitoringu (vdaka DTrace brut vela sond)… v takej komplexnosti je to na ~3mes. intenzivneho ‚treningu‘, aby clovek nepotreboval man. V tomto pripade sa lepsie a rychlejsie reaguje cez GUI, kedze su tam debug veci prepracovane do detailov.
        Btw http://www.freenas.org/ celkom dobry progress spravil a celkom sa dotahuje na NexentaStor…

        • Wiro
          Odpovedať
          Autor
          Wiro

          „Linux sa na setko nehodi… to je fakt… aj napriek tradiciam (prip. fundamentalizmu)… 😉 Seriozny disk storage s Linuxom, to sa neda, ale zase ked by malo ist o dokumentovy storage, tak to uz je ina pesnicka…“

          S tymto nazorom by som rozhodne nesuhlasil. Aktualne mnohe aj Hi-END profi storage pouzivaju ako zaklad niektoru linuxovu distribuciu.

          S aktualnym stavom opensource OS tazko take riesenie ako je opisane v clanku by bolo mozne uskutocnit na inom nekomercnom systeme ako linux.

          Mnohe projekty spravily uzasny pokrok, problem je, ze nieje dolezite kto aky spravil pokrok ale kde sa aktualne nachadza.
          Je to klasicky boj profi storage vs vlastne riesenie. Vyzsie popisane featury by neboli na inom systeme uskutocnitelne, firmy ktore nemaju kapacity na takyto vyvoj zvolia drahsie hotove riesenie (Compelent, Equalogic, EMC … ) ktoremu nemusia do hlbky rozumiet.

  • Alfi
    Odpovedať
    Autor
    Alfi

    Pekny popis. Mna by zaujimalo aky filesystem na tom pouzivate a ake s nim mate skusenosti. Pouzivate na tom obcas aj resize filesystemu pre jednotlive virtual servery?

    • Tomas Corej
      Odpovedať
      Autor
      Tomas Corej

      Na strane storage serverov nepouzivame ziaden filesystem iba lvm exportovane cez iscsi. VPSkam ale defaultne davame ext3 pretoze sa umoznuje online rozsirit a zmensit offline co napriklad take xfs nevie. .

  • coegorlesursE
    Odpovedať
    Autor
    coegorlesursE

    Chcel som sa rozlíšiť, čo môžu zamestnanci včela v živote celé je tak , že to nie je o tom , ktorí nemohli otočiť puntičkársky odpoveď.

  • Robix
    Odpovedať
    Autor
    Robix

    Máte to urobené na profi úrovni. Ja som mal predtým VPS inde, kde to nemali zdaleka takto. Asi mali len na normálom serveri niekoľko VPS a keď niekto zahltil disky, tak bolo mizerné IO. Prešiel som na iserver.sk, lebo tam nič netreba riešiť a cene je aj zálohovanie. No pokiaľ by som potreboval obyčajné VPS s root prístupom na nejaký špeciálny projekt zvolil by som asi WS.