V nasledujucom clanku by som rad upriamil pozornost tych, koho to zaujima, na ine formy virtualizacie. Pojde o virtualne ulozisko dat od firmy 3PAR, ktora je nenapadnym a malym novacikom, ale z hladiska pomeru vykon/cena, pouzitych technologii a noviniek, s akymi sme sa predtym nikdy nestretli, nam ponuka prekvapivo inovativne riesenie.
Firmu 3PAR zalozili traja byvali pracovnici Sun Microsystems v roku 1999. Okrem obrowskeho know-how si priniesli aj podporu nielen zo strany Sun-u. Do firmy investovalo mnozstvo patentov, know-how a v neposlednom rade aj pomerne vela penazi niekolko velkych firiem (Cisco, Sun Microsystems, a dalsie). Vysledkom je virtualizovany storage od firmy 3PAR, ktory by som vam chcel aspon trosku predstavit.
Cely system je postaveny na baze LVM, ako ju pozname z platforiem AIX alebo Linux. Fyzicke disky su rozdelene na male casti, ktore sa volaju “chunklets”. Ich velkost je na rozdiel od inych LVM systemov (napr. AIX) vzdy rovnaka a cini 256MB. Pouzity HW podporuje hotplug a je dost pekne skalovatelny – na zaciatku si mozete kupit 2 kontrolery po 8 diskov a podla potreby tento storage system rozsirovat az do hranice 8 kontrolerov a dohromady 2560 diskov, pricom system nemusite ani raz odstavit. Zaujimavostou je, ze pridavanie diskov zvysuje nielen kapacitu samotneho diskoveho pola, ale aj jeho rychlost. Preco su stripovane disky rychlejsie? Pretoze sa zapisuje naraz n pruzkov (stripe) dat na n diskoch, rychlost takehoto zapisu je teda n krat rychlost zapisu na jeden disk. Limitujucim faktorom disku je v podstate jeho schopnost vykonavat I/O operacie rychlo za sebou. Cim viac ich stihne za dany cas, tym je rychlejsi. V podstate sa takmer vsetky jeho charakteristicke vlastnosti odvijaju od poctu I/O operacii, ktore dokaze za jednu sekundu uskutocnit. Data, ktore sa vsak na tento disk maju zapisovat, mozu prudit smerom na disk ovela rychlejsie (napr. Z CPU cache, alebo z fibre channel adapteru). Tieto data sa teda narezu na pruzky a naraz sa zapisuje niekolko takychto pruzkov na niekolko diskov naraz. Predstavte si ale, ze mate v diskovom poli 256 diskov, data sa stripuju na 128 z nich a na dalsich 128 sa este zrkadlia. To uz musi byt pekne rychle a aj bezpecne, samozrejme vsak treba mysliet na kontrolery a dostatocne ich na taketo pouzitie nadimenzovat a spravne interconnectnut. 3PAR tvrdi, ze sa im to podarilo.
Vinikajucou novinkou je Get-Thin-Stay-Thin. Umoznuje pozoruhodnu usporu HW a teda aj energie a fyzickeho priestoru. Figel je v tom, ze 3PAR umoznuje zdielat volne miesto medzi roznymi logickymi particiami. Volne alokovane miesto na danej logickej particii sa zaroven pouziva aj ako priestor pre realne data inej particie. S rukou na srdci urcite vsetci uzname, ze s diskovym priestorom by sa takmer vzdy dalo hospodarit lepsie ako sa hospodari. Vsade si nechavame rezervy, tvorime 100G filesystemy a 90% casu su tieto fs naplnene len na 70, dokonca i menej percent. Administrator 3PAR diskoveho pola ma moznost pridelovat jednotlivym logickym particiam priestor, ktory sa na strane uzivatela priestoru (df -h) javi ako alokovany priestor. Avsak sucet velkosti vsetkych logickych particii je vacsi, ako sucet velkosti vsetkych fyzickych diskov v poli. Nastava tak podobny blahodarny efekt vyhodnej utilizacie prostriedkov ako ten, co sme si ho popisali v poslednom clanku o DLPAR. Administrator len sleduje, kolko priestoru ma k dispozicii na svojich fyzickych diskoch a ked sa toto cislo priblizi k nejakemu trashholdu, jednoducho vytiahne zo suflika 2 disky (alebo si ich objedna od vyrobcu), zasunie ich do pola a system ich automaticky zaradi a zacne pouzivat. Vsetci uzivatelia su spokojni, lebo maju alokovane obrovske priestory, ich filesystemy su pohodlne predimenzovane, pritom vsak nedochadza k plytvaniu priestorom a energiou (aj prazdny disk sa musi napajat elektrinou a chladit).
Dalsou peknou vlastnostou 3PAR diskovych poli je tzv. Automaticka distribucia (loadballancing) dat rovnomerne po vsetkych diskoch v poli, pricom sa dosahuje zvysenie max. poctu I/O operacii za sekundu (vid vyssie). System sa automaticky stara o to, aby casto a vydatne pouzivane logicke particie boli vzdy rozdistribuovane na co najvacsom pocte diskov kvoli rychlosti a aby boli vzdy aj mirrorovane pre pripad zlyhania disku. Riesenie zlyhania disku je samozrejme plne automaticke. Data, ktore sa stratia z mrtveho disku sa automaticky nakopiruju z mirrorov na novy disk (ktory by podla mna dokonca mohol cakat zasunuty do diskoveho pola, ale zapol by sa az v pripade potreby, t.j. hned po zlyhani jedneho z diskov... to je uz ale len polemika, nie som si isty, ci 3PAR takuto funkcionalitu ma.
System dokaze monitorovat pracu jednotlivych fyzickych diskov, pocitat ich odpracovane hodiny a predikovat ich zlyhanie. Disky, o ktorych sa predpoklada, ze by mohli zlyhat sa pouzivaju len na nedolezite ulohy (napr. Drzanie tretej kopie mirroru). System tiez dokaze identifikovat mnozstvo priznakov, ktore sa prejavuju pred zlyhanim disku a dokaze na ne reagovat bud to vyradenim disku z prevadzky, alebo upozornenim administratora.
Jednou z moznosti 3PAR je mat cele pole nakonfigurovane ako jeden velky RAID10.
Cely system sa moze skladat aj z roznych diskov (kapacitne i rychlostne roznych) a umoznuje administratorovi si vybrat, ktore logicke particie sa budu nachadzat na ktorych diskoch.
Situacia v oblasti storage rieseni sa teda pohybuje tym spravnym smerom. Uz coskoro by sa diskove pole mohlo stat autonomnym robotom, ktory sa sam bude administrovat, objednavat si u vyrobcu diskov nove disky, vyradovat stare a zlyhane, resp. by mohol z casu nacas administratorovi poslat mail, ze by sa hodilo kupit par diskov a strcit ich tam, lebo dochadza priestor. Administrator by to urobil a diskove pole by si disk samo automaticky pripojilo a vydistribuovalo by nanho potrebne data.
Zdroj: prezentacia spolocnosti 3PAR
Tomas catcher Tudja, 17. oktobra 2008
Zaujimvy, dobry clanok, tento aj predosly. Otazocka: ako funguje ten automaticky loadballancing pr pridavani novych diskov? Ak mam povedzme 8 diskov, medzi ne rozdistribuovane stripy povedzme do 80% kapacity (po 10%) a pridame dalsie dva, ako zabezpeci aby bolo na kazdom disku rovnako dat (8%), popripade ako zaruci, ze sa bude citat a pisat na vsetky disky naraz?
Je to jednoduche. System automaticky presunie data z chunkletov na staruch diskoch na nove tak, aby zostalo vsade rovnako/rovnako mirrorovane.
Jo, to mi tiez prislo ako jedine riesenie, ale nieje to enormna zataz pri velkych poliach? povedzme 10 - 20 TB?
Takze tu mame ukazku prezentovania produktu. Zhrnutia cisel a popis zakladneho konceptu.
Ale z uzivatelskeho hladiska - popisane sa podoba napriklad na Enterprise Virtual Array od HP. Ku ktoremu mam dokumentaciu a skusenosti. Ceny som po zbeznom prelezeni stranky nikde nenasiel. Je mozne ze niektore veci ma lepsie alebo horsie vyriesene - k detailnej dokumentacii neviem ci sa da tak lahko dostat aby to mohol niekto potvrdit.
Ohladom zazracneho zdielania volneho miesta. Tebou popisana vec s df -h je zavisla od pouziteho filesystemu a bolo by dost cudne keby array vedelo rozoznat ci su na urcitej casti filesystemu data alebo nie. Pri pouziti modifikovanych ovladacov je aj toto mozne ale ... zatial som s podobnym riesenim nemal docinenia.
Pouzivas pojem rozdistribuovania po vsetkych diskoch v poli. Pri vypadku disku je v podobnych rieseniach implementovany napr. resilencing kedy sa ti v danej grupe rozmiestnia chunky ako keby bolo v tej grupe o 1 disk menej. To uz pri 8 diskoch vie vytvorit pekne I/O a kedze operacia musi bezat degradovane na pozadi (nesmie narusit performance celkoveho pola) dokaze trvat pekne dlho. Nechcem vidiet co by to robilo pri 2000 diskoch :)
Hovoris ze budu standby disky pripravene ako zaloha => cize musi byt zohladnena velkost disku ktory maju nahradit + je to nevyuzita kapacita ktora sa v dnesnej dobe nenosi.
Nemozes pocitat s human vymenou disku - pole sa musi dostat same do stavu ze bude mat vsetko mirorrovane ako predtym a znizit sa mu musi len kapacita o ten failnuty disk. Garantovat ludsky faktor v kritickych oblastiach sa neoplati.
Cize je to pekne marketingovo popisane na presvedcenie managerov. Akurat par popisanych veci je revolucnych a pripomina mi len mylne popisane features.
Aka je zavislost medzi df- h a filesystemom? Pokial viem, tak df -h zobrazi volne miesto na particii, bez ohladu na to, o aky fs type ide.
Ano, array sa v tomto pripade nezaobera len tym, ci je chunklet priradeny nejakemu LV, ale aj ci sa na nom realne nachadzaju nejake data. Presne v tomto spociva vyhra pri virtualizacii diskovych poli.
Moderne diskove polia maju vyhradeny bandwidth medzi diskami urceny na vlastnu reziu - t.j. presne resilencing, mirror restore, atd. (Aj HP-EVA to ma, aj IBM-SVC to ma...), resp... nie uplne vyhradeny, ale ked tieto rezijne veci bezia na pozadi, su jednak dostatocne rychle a vobec nezasahuju do schopnosti pripojenych systemov pracovat z vyexportovanymi particiami.
Clanok bol napisany nazaklade marketingoveho popisu a nasledneho precitania technickych dokumentov od firmy 3PAR. Ja som jeden z tych "managerov", ktorych nepresvedcili (nepracujem pre 3PAR), lebo mame vlastne riesenie (HP-EVA, IBM-SVC, Shark), ktore nam zatial staci. Zapacilo sa mi vsak par myslienok obsiahnutych v tomto rieseni a preto som to sem uverejnil.
Mam skoro off-topic dotaz. Myslis, ze popisovany produkt bol vyvijany uz od 1999 -- teda po 9 luds. rokov je to v takom stave? Momentalne je to jedno tip-top riesenie. Vychadzajuc zo sucas. stavu trhu s ulozis. rieseniami bude to niekde sluzit aspon taku dobu, za aku sa to vyvijalo?
Mam na mysli zmeny HW a SW -- ze na nieco, naco sme sa mohli zvykat v poslednych 30ich rokoch, v buducnosti budeme mat tak maximalne 15 rokov. A ze sa ta doba neustale skracuje.
Zaujima ma nazor kazdeho.