Virtualizacia – vyuzitie v enterprise prostredi

Virtualizacia tak, ako ju pozname z bezneho zivota, je nemastna neslana... Rozbehame si OpenVZ, hrajkame sa s tym, pomozeme si malickym kvazi-clusterom, pre pripadne failover situacie...
A potom sa sami seba spytame : “Co nam to dalo?” a odpovieme si “Nic”. Drvivej vacsine ludi, s ktorymi som sa o nej rozpraval, nedavala zmysel. Akesi virtualne pocitace sa nachadzaju na jednom ozajstnom pocitaci... “A co?” Utilizacia vypoctovych prostriedkov...
“A co vy si tak vojine Kefaline predstavujete pod pojmem “utilizace””? Mozeme si virtualne pocitace zastavit, preniest na iny ozajstny pocitac a tam ich rozmrazit a oni budu dalej bezat...
“A to je nam na co?” Mozeme virtualnym pocitacom pridavat vypoctove prostriedky, alebo im ich odoberat a to vsetko za behu, bez ovplyvnenia aplikacii, ktore v nich bezia...
“a to mi ako pomoze, ked mam vo firme jeden webserver a jeden databazovy server?”. Je to skoda, ze vacsina ludi pouziva technologie na zivobytie a nemaju s nami sucit, ked sa s technologiami hrame a tesime sa z nich...

Plnohodnotne vyuzitie virtualizacie v enterprise prostredi umoznuje az jedna z jej najposlednejsich funkcionalit. Ide o dynamicke zmeny v “HW konfiguracii” jednotlivych virtualnych strojov za behu a bez akehokolvek ovplyvnenia aplikacii beziacich vnutri virtualneho stroja. Pri nasledujucej uvahe budem vychadzat z virtualizacnej technologie LPAR od IBM, ktoru pokladam za spicku a vrelo doporucujem (uz nepracujem pre IBM, takze ziaden flame!!)

Definicia prostredia:
Uvazujme velke enterprise prostredie, ktore obsahuje niekolko skupin sluzieb s roznymi casmi spickovej zataze CPU a potreby pamate. Vieme, ze klucove prostriedky v oblasti virtualizacie su 3 – CPU, pamat a I/O (disky). Pri dynamickom rozdelovani/prerozdelovani prostriedkov sa vsak v praxi v drvivej vacsine pripadov stretneme len s pracou z dvoch z nich – CPU a pamat.
Je to preto, lebo I/O prostriedky su skor statickeho charakteru – v diskovom poli su nakupene disky s urcitou rezervou a kolisanie v dopyte po diskovom priestore je ovela kludnejsie, ako v pripade CPU a pamate. Okrem toho si tiez treba uvedomit, ze s I/O prostriedkami sa neda velmi “dynamizovat” v zmysle rychleho priradovania a prepriradovania diskov roznym virtualnym strojom (logickym particiam – LPARom). To je totiz spojene s prenosom nemalych mnozstiev dat. Priradovanie/prepriradovanie CPU a MEMORY prostriedkov je ovela jednoduchsie uz len z ich samotnej povahy.

V prvej casti clanku si skusime predstavit riesenie na baze planovaneho prerozdelovania kapacity vzhladom k casovo orientovanej zatazi roznych sluzieb beziacich na roznych LPARoch na jednom fyzickom stroji (managed systeme). V druhej casti sa zamyslime nad este len povstavajucom trendom, ktory si pracovne nazveme ako autodynamicka virtualizacia.

Predstavme si teda, ze potrebujeme prevadzkovat 4 rozne sluzby, pricom kazda z nich ma spicku trvajucu 4 hodiny. Pocas spicky potrebuje sluzba dvojnasobne viac pamate a CPU ako pocas normalnej prevadzky. Spicky jednotlivych sluzieb sa neprelinaju, to znamena, ze spicka prvej sluzby sa zacina o polnoci, konci sa o stvrtej rano, spicka druhej sa zacina o siestej rano a konci sa o desiatej doobedu, spicka tretej sa zacina naobed a konci sa o stvrtej poobede a spicka stvrtej sluzby sa zacina o siestej vecer a konci sa o desiatej vnoci.

Teraz sem musim napisat taku vysvetlujucu vsuvku, lebo vacsina citatelov (hlavne tych, co maju skusenosti z ostreho produkcneho prostredia) si teraz tuka na celo. Ano, viem, ze priklad uvedeny v predoslom odseku je prilis umely a prilis dokonaly. Zrejme sa s nicim takym v zivote nestretnete, taketo umele, neexistujuce, cvicne prostredie som si urobil preto, aby sa mi nanom jednoduchsie vysvetloval samotny princip planovaneho dynamickeho prerozdelovania prostriedkov. Po precitani clanku zistite, ze samotny princip sa rovnako jednoducho da uplatnit aj na heterogennejsie prostredia s vacsou diverzitou spiciek a idlelike stavov a s mensimi rozdielmi medzi jednotlivymi stavmi. Okrem toho si tiez treba uvedomit, ze v dostatocne diverznom a dostatocne velkom datacentre nie je problem nechat bezat na jednotlivych LPARoch prave take sluzby, ktore maju spicky v inych casoch, ako ine sluzby beziace na tom istom managed systeme, ale v inom LPARe. Okrem denneho sa v produkcnych prostrediach tiez casto stretnete aj s mesacnym planom dynamickeho prerozdelovania kapacity (priklad – Orange, a.s. - 4 rozne fakturacne obdobia. Pocas fakturacneho obdobia je zataz daneho informacneho systemu vyssia, ako pocas beznej prevadzky – to umoznuje administratorom tohoto informacneho systemu usetrit nemale mnozstvo vypoctovych prostriedkov len vdaka virtualizacii a dynamickym LPARom. IBM v komercnych materialoch uvadza az 80% usetrenych vypoctovych prostriedkov, to je vsak mozne len pri sluzbach s obrovskym rozdielom medzi zatazou v spicke a mimo spicky, resp. pri vynimocne kratkych spickach. V praxi som sa stretol s cislami medzi 20 a 40 % (co vsak stale moze predstavovat miliony EUR rocne).

Teraz este par technickych detailov:
Jednotlive LPARy bezia na managed systeme. K managed systemu je pripojena HMC (hardware management console), co je vlastne intel-based PC, pripojene k managed systemu pomocou seriovej linky. HMC sluzi na ovladanie managed systemu, v nasom konkretnom pripade teda budeme dynamicky prerozdelovat vypoctove prostriedky medzi jednotlivymi LPARmi. Okrem toho nam HMC umoznuje pripojit sa priamo na jednotlive LPARy – velmi vyhodne v havarijnych stavoch, ked napriklad nemame sietovu konektivitu k systemu beziacemu v LPARe (AIX alebo Linux). Na HMC bezi jednoduchy system zalozeny na Linuxe, ktory nam ponuka male prostredie. Jeho sucastou je napriklad prikaz chhwres, ktorym priradujeme, odoberame, presuvame prostriedky medzi jednotlivymi LPARmi v jednom managed systeme. Jeho manualovu stranku lahko vygooglite na redbookoch, odporucam sa na nu pozriet. K HMC sa mozeme prihlasit pomocou java software, ktory nam IBM spolu s HMC doda (graficka klikacka), alebo sa na HMC mozeme pripojit pomocou SSH (z coho vyplyvaju dalsie vyhody, ako napr. Moznost pouzitia klucov bez passphrase a vykonavania prikazov na HMC z uplne inej masiny v peknom skriptiku, ci dokonca v este peknejsom cronjobe).

Nase LPARy sa budu volat jednicka, dvojka, trojka a stvorka. Kazdy z nich bude mat prideleny jeden procesor a jeden GB pamate. Managed system bude obsahovat aj tzv. free cpu pool a free memory pool. To bude skupina prostriedkov, ktore nebudu nikam alokovane a pouzivaju sa len pocas spiciek. Tieto bazeniky budu obsahovat 2 CPU a 2GB pamate (v idealnom pripade by nam stacil 1CPU a 1GB, neskor uvidime preco...). Jeden CPU a jeden GB priradime vzdy v case zaciatku spicky tomu LPARu, ktoremu sa spicka zacina. Po skonceni spicky mu ho vezmeme. Ak by sa nahodou stalo, ze sa nam spicka jedneho LPARu pretiahne za cas zaciatku spicky na inom LPARe, mame v rezerve este jeden CPU a jeden GB pamate (v realnom prostredi mame rezervu dokonca este vacsiu, pretoze byva zvykom, ze vedla ostrych LPARov bezi na tom istom managed serveri aj jeden alebo viac LPARov, ktore nie su dolezite (testovacie systemy, tretie a dalsie nody nekonkurentnych HA clusterov), ktorym sa da chybajuca kapacita v pripade multispicky odalokovat a prialokovat LPARu, ktory to potrebuje). Podme si to teraz spocitat:

Kazda sluzba potrebuje mimo spicky 1 CPU a 1 GB pamate.
Kazda sluzba potrebuje pocas spicky 2 CPU a 2 GB pamate.
V pripade standalone riesenia potrebujeme 8 CPU a 8 GB pamate.
V pripade dynamickych LPARov (DLPAR) potrebujeme v idealnom pripade 5 CPU a 5 GB pamate, pre istotu 6 CPU a 6 GB pamate.

Uspora vyplyva nielen z ceny procesorov a pamate, nielen z ceny standalone strojov oproti pomernej casti ceny strojov typu p570, ale aj z ceny supportu od 3rd party firiem, ktora sa v niektorych pripadoch vypocitava z poctu procesorov v celom informacnom systeme. Podla mojich skusenosti sme v nasom umelom, cvicnom pripade usetrili priblizne 10 000 EUR jednorazovo a dalsich 35 000 EUR za kazdy rok prevadzky. Oproti nasmu malemu prikladu si este skuste predstavit moznosti, ktore Vam ponuka napriklad server Power 570, ktory moze mat 32 procesorov a 768GB pamate. Je to sice 60 kilogramov vaziaca skrina, ale oproti standalone rieseniu predstavuje obrovsku usporu nakladov na realizaciu aj prevadzku.

A teraz kolacik nazaver:
Technologia LPAR v spojeni s HMC a moznostami DLPAR nam otvara dvere do administratorskeho raja. Nic nam nebrani v tom, aby sme si napisali skript, ktory bude monitorovat zatazenie jednotlivych LPARov a podla ich zataze im pridavat alebo odoberat prostriedky plne automaticky. Pocas pracovnej doby posielat administratorovi e-maily o tom, co sa prave deje, mimo pracovnej doby sms. Tento skript nam pocas svojej, uz aj tak velmi prospesnej praci, moze archivovat svoju cinnost a pripravit nam periodicke reporty presne popisujuce DLPAR eventy, ktore sa deju. Ich analyza nam pomoze z nadhladu hodnotit velkost tzv. bazenu (free cpu/memory pool), v ktorom sa nachadzaju rezervne a v spickach pouzivane prostriedky. A ako nam sluzby a poziadavky s casom rastu, presuvame mensie a menej potrebne sluzby na dalsiu p570ku, cim zvacsujeme bazen a tympadom sme stale pripraveni na narast poziadaviek na danu sluzbu. IBM uz ma pripraveny toolkit, ktory nieco taketo umoznuje, klik sem: http://www.alphaworks.ibm.com/tech/dlpar

Ako vidime, z takehoto uhlu pohladu vyzera byt virtualizacia ako nevyhnutnost. Zvacsovanie fyzickych rozmerov datacentier sa pouzitim virtualizacie posunie dost vyrazne do buducnosti. Spotreba elektrickej energie klesne a administratori maju moznost vyuzit HW takmer do poslednej kvapky. Koniec spiacemu HW pocas idlelike stavov, koniec problemov s rozsirovanim infrastruktury jednotlivych sluzieb... teda... uplny koniec tychto problemov to samozrejme nie je, len sa odsunu do pohodlne dalekej buducnosti...
A kto vie, co ludstvo vymysli za par rokov...
Mozno je nacase zacat sa seriozne zamyslat nad grid computingom a jednotlive managed systemy spajat, cim by sa presuvanie sluzieb este viac zjednodusilo. Nikto nevie, co prinesie zajtrajsok, nikto nevie, ako sa budu nakupovat procesory v buducnosti...
Mozno sa budu len kupovat, ale nikdy ich neuvidime fyzicky... prajem prijemne snivanie :>

Tomas catcher Tudja, 15. oktobra 2008