Neboli - nepleťme si Shared Infrastrure s Blade technologií.

Navazující článek o Blade technologiích. http://optimalizovane-it.cz/servery/blade-servery-pro-koho-jsou-urceny-jake-maji-vyhody-a-nevyhody.html

Blade řešení, které jsme si popisovali jsou určeny pro enterprise podniky, které hledají vysokou hustotu, nízkou spotřebu a jednoduchou správu prostředí. Jsou zde ale také podniky nové éry WEB 2.0 poskytující tzv. cloud. Web hosting, server hosting, free mail, Software-as-a-service atp. pro tento typ zákazníků vznikla před cca 5ti lety separátní divize v Dellu DataCenter Solutions (DCS). Tato skupina má na starosti kolem 20 zákazníků celosvětově. Obecně jsou to firmy vyznačující se instalovanou bází přesahující 100 000 serverů. Jejich vysoká dostupnost je posunuta na software úroveň, např. dobře známý systém vynalezený Dougem Cuttingem - Hadoop. Patří mezi ně giganti typu Facebook, Microsoft, atp. Pro tyto zákazníky jsme vytvořili skupiny vývojářů a designerů, kteří vyvíjejí servery přímo pro ně. Tito zákazníci se vyznačují jednorázovými objednávkami přesahujícími 10 000 serverů, proto se také vyplatí, aby měli tuto zvláštní péči. Design těchto řešení byl tak zajímavý, že někteří výrobci ho začali kopírovat. Před dvěma lety jsme zjistili, že to co je dobré pro “velké kluky” může být zajímavé i pro spoustu menších lokálních cloud firem. Co tyto firmy mají ale všechny společné je výhradní podíl OPEX nákladů za el. energii. Vytvořili jsme tedy novou řadu serverů, kterou označujeme PowerEdge C (jako Cloud)

Jednoduché zadání DCS :

Vytvořit servery, které mají obrovskou hustotu a velice nízkou spotřebu (pokud jsem schopen ušetřit biť 1W/server, může to být klidně 100KW úspory v celém DC, tím výrazně snížit OPEX ! Navíc nejde samozřejmě jen o spotřebu, ale s tím spojené chlazení. Servery nepotřebují vysokou dostupnost. Nepotřebují sofistikovaný management. Musejí být ale naopak otevřeny externím konektivitám pro použití jakýchkoli switchů. Nepotřebují certifikace na spousty OS většinou stačí Linux/windows a pouze aktualní verze, (max N-1). Nepotřebují také certifikace a schopnosti připojit se např. na FC SAN infrastrukturu ta je pro tyto instalace příliš nákladná, nehledě na to, že hadoop systém a jemu podobné pracují primárně s lokálním úložištěm přímo v serveru.

Přirovnání : Je to podobné jako, když jste byli malí a maminka vám koupila kolo plné různých “serepetiček”, ale vy jste přece chtěli závodní kolo, být co nejrychlejší = kolo muselo být lehčí. Odstrojili jste tedy blatníky držáky zvonek atp. aby kolo vážilo co nejméně a to byl pak teprve ten správný závoďák !

Servery DCS skupiny a PowerEdge C se přesně drží tohoto modelu. Jsou designovány maximálně v poměru Výkon/Spotřeba.

Nová třída serverů označovaná jako Shared Infrastructure (Sdílená infrastruktura)

SI má s blades podobné prvky : chasses s sdílenými napájecími zdroji, ale tím tato podobnost končí.

Typickým zástupcem v portfoliu Dell je např. PowerEdge C6100 (INTEL) nebo C6105 (AMD)

Jedná se o Serverový systém do 2U a 4x nezávislý Server. Servery mají jak vidíte vyvedeny eth. konektory zezadu pro připojení pro ext. switch. Rozšiřující karty, musí být LOW PROFILE, nicméně jsou to standardní PCI-E. HDD konektivita je realizována napevno 1:3 v případě 12 HDD (3,5” na obrázku) varianty nebo 1:6 v případě 24 HDD (2,5”). Tento server je tedy naprosto nevhodný např. pro virtualizaci se sdíleným diskovým prostorem. Na disky ve předu není možné přistupovat ze všech serverů, jako to vyžaduje sdílené úložiště.

Zde jsme schopni dostat až 20 Serverů do 10U (blades 16 do 10U)

System pro maximalizaci jader do U je zase PowerEdge C6145

Tento 2x 4CPU server dokáže díky nejnovější AMD Buldozer technologii dostat až 128 Jader do 2U ! Toto je největší hustota jader v x86 platfomě na světě. Tento server se právě proto používá pro HPC prostředí.

Dalším stupněm je tzv. Physicalization (tedy opak virtualizace) – Microservery

Je to systém vytvořený hlavně pro web servery a separátní pronajímané servery v cloudu. Jedná se o velice malé jak velikostí tak výkonem servery (typicky se jedná o 1xCPU počítačové řady, nikoli serverové) s cílem dostat co nejvíce serverů do min. U.

Zástupce v Dellu této třídy serverů je třeba C5020 (Intel) nebo C5025 (AMD)

Tyto microservery obsahují v sobě 1-4 HDD žádnou rozšiřitelnost o ext. karty a 2x eth.

Tímto systémem dostaneme až 36 Serverů do 9U !

Storage, nebo-li úložiště. Místo kam ukládám svoje nebo zákaznická data. S tím jak data a počet uživatelů roste, se nám typ storage významně mění. Podobně jako existují pro dopravu : osobní automobily, nákladní vozy, letadla, vlaky a lodě. Všichni dohromady řeší stejnou věc, každý ale jiným způsobem a za jinou cenu, nicméně fungují všichni dohromady, protože to trh potřebuje. Stejně tak existují různé druhy storage.

Používané pojmy:

DAS – Direct Attached Storage viz. http://en.wikipedia.org/wiki/Direct-attached_storage

SAN – Storage Area Network viz. http://en.wikipedia.org/wiki/Storage_area_network

NAS – Network Attached Storage viz. http://en.wikipedia.org/wiki/Network-attached_storage

Segmentace

Pokusím se teď v co nejjednodušší podobě ukázat, jak se dělí trh storage v současné době dle segmentů:

Consumer – HOME / SOHO

(primární zaměření je pro jednoho člověka max do 10 uživ.)

• CONSUMER/SOHO
• Interní HDD v počítači (často není třeba žádná dedikovaná storage)
• Externí HDD. USB, eSATA, FW, atp. Omezená nebo žádná redundance
• NAS (storage připojená po počítačové síťi) Omezené možnosti redundance
• Limity těchto řešení se pohybují v jednotkách HDD
• Benefity : Cena
• Omezení : Dostupnost, rozšiřitelnost, zálohování

Corporate/Public

• Small business / Small Public (cca 100 uživatelů)
• INTERNAL STORAGE v Serveru
• ENTRY LEVEL STORAGE
• DAS (Přímo připojená storage k serveru) SAS, FC, iSCSI (modely s redundancí)
• NAS (modely s redundancí)
• SAN (Storage připojená samostatnou sítí k serverům) (Plně redundantní všechny komponenty jsou zastupitelné)
• Limity těchto řešení desítky HDD
• Benefity : Dostupnost, rozšiřitelnost (omezená)
• Omezení : Většinou nedostupná integrace do aplikací pro snadnější zálohování a vysokou dostupnost. Zálohování a obnova xxTB dat
• Medium business / Medium Public
• ENTRY LEVEL STORAGE
• Použití na menší pobočky
• MIDRANGE / Enterprise Storage
• Centrální úložiště pro data ve společnosti
• SAN/NAS – Dělení více méně způsobem konektivity určující použití zařízení
• Limity těchto řešení jsou ve stovkách HDD
• Upgrade FW za chodu bez výpadku systému
• Benefity : Storage s rozšířeným Software, zjednodušující a zrychlující práci s daty. Zálohování a obnova možno na úrovni storage. Replikace dat na úrovni storage.
• Omezení : Dvě řídící jednotky. V případě výpadku jedné dochází k min. 50% výkonnostní degradaci
• Large Enterprise / Central Public
• ENTRY LEVEL STORAGE
• Použití na menší pobočky
• MIDRANGE STORAGE
• Použití na větší pobočky
• HIGH-END STORAGE
• Centrální úložiště pro nejdůležitější aplikace ve velkých společnostech
• Ztrátou komponenty neztrácím 50% výkonu
• Upgrade FW za chodu bez výpadku systému
• Možnost spustit více než dvě řídící jednoty – škálovatelnost
• Bohatá SW výbava vč. Business continuity a disaster recovery nadstaveb
• Limity na tisících disků

Pro názornost u nás v Dellu produkty začínají SMB. Consumer částí se Dell ve storage nezabývá, nehledě na to, že tato oblast začíná být nahrazována Cloud řešeními, do kterých nyní nejen Dell investuje (o tom někdy příště).

PowerVault

Model : Dell PowerVault Označení : MD (Modular Disk)    Zaměření : (10tky HDD) Small&Medium Business

web : www.dell.com/powervault

EqualLogic

Model : Dell EqualLogic    Označení : PS (Peer Storage)      Zaměření : (až 100ky HDD) SMB – Large Enterprise

web : www.equallogic.com

Compellent

Model : Dell Compellent  Označení : SC (Storage Center) Zaměření : (až 1000ce HDD) Medium Business – Large Enterprise

web : www.compellent.com

Vidíte kolem sebe spoustu lákavých nabídek na Blade řešení ? Tlačí vás váš dodavatel do Blade řešení a vy si nejste jisti, zda je to pro vás to správné ? S Příchodem virtualizace se dost změnilo na straně serverů a my se podíváme na to jak. Pokusíme si vydefinovat klady a zápory Blade řešení, abyste byli schopni se sami rozhodnout, kterou technologii zvolit. Pokusím se zmínit výhody Dell Blade řešení, které vám můžeme nabídnout.

Definice pojmů

Blade Server

Blade nebo-li  žiletka je server, který je maximálně zmenšen. Jeho vnitřní design bývá “cable-less”(bez kabelu), který by byl jen objektem potenciálního problému v budoucnu a také překážkou v proudění vzduchu. Neobsahuje žádné pohyblivé části (kromě HDD, pokud má). Jeho veškerá I/O konektivita je vyřešena multi konektorem do Blade Chassis.

    

Blade Chassis

Zasunuje se do Blade Chassis, které je jakýsi RACK v RACKu. Chassis slouží pro více Blade serverů a sdílí pro ně hlavně zdroje napájení a ventilátory. Chassis také slouží pro konsolidaci I/O modulů určených pro komunikaci žiletek s okolním světem a mezi sebou. Chassis umožňuje konsolidaci KVM (Keyboard Video Mouse) je jeho součástí a tím také šetří zákazníkovi pořizovací náklady.

Schématické zobrazení zadní části chassis :

Blade řešení vzniklo pro společnosti, které mají desítky fyzických serverů a pro tyto společnosti má nesčetné výhody.

Dell Blades :

Video při uvedení nové generace Chassis M1000e

Výhody Blade Řešení :

- Jednoduchá implementace :

Blade servery mají kolejničky, které umožňují zasunutí serveru do chassis bez jakéhokoli nástroje. Přidání tedy dalšího blade serveru do infastruktury je otázkou minut. Pokud nastavím všechny prvky prostředí (switche atp.) pro všechny budoucí žiletky, je přidání nového serveru opravdu chvilička.

Plně osazené a za kabelované chassis je např. na tomto obrázku i se schématem zapojení vnitřního InterConnect.

Dell jde o trochu dále : Dell midplane (tedy základní deska blade chassis) je 100% pasivní (nemá na sobě žádnou el. součástku). Jsou výrobci, kteří zdůrazňují, že mají redundantní midplane, ale POZOR ! Je to kvůli tomu, že je Aktivní = tedy může se na něm něco rozbít, musí mít aktivní součástky provedeny redundantně.

- Jednoduchý management :

Blade servery mají management na úrovni Chassis. (u nás CMC Chassis Management Controller) Velice jednoduše jsem tedy schopen se v mojí infrastruktuře vyznat. Také díky integraci KVM je managment jednodušší, KVM vyjde samozřejmě levněji než separátně. Navíc se blade chassis dají propojit mezi sebou. Tento management je navíc shodný s našimi RACK servery a zaslouží si podrobnější zaměření. Nechám ho na jeden z dalších článků.

Dell jde o trochu dále : KVM Switch v M1000e je vyroben ve spolupráci s špičkou na trhu AVOCENT, dá se kaskádovat do standardních DELL KVM Switchů (také AVOCENT)

- Úspora místa :

Díky konsolidaci ventilátorů, napájecích zdrojů, síťových, KVM a SAN switchů jsem schopen ušetřit nemalé prostory.

Dell jde o trochu dále : Díky naší patentované technologii FlexMemory Bridge umožňujeme to, co se zdálo nemožné s uvedením posledních verzí CPU od Intel i AMD. Využití všech DIMM SLOT, bez nutnosti osadit všechny CPU ! Je to funkcionalita našeho serveru M910 (také R810) :

Tato technologie je vhodná hlavně pro virtualizaci kde je běžné licencování na fyzické CPU. Dále na Databáze zejména Oracle, kde licencování CPU může stát lehce více než CPU samotné. Však ani virtualizace ani Databáze nemají většinou bottle neck v CPU ale právě v RAM.

- Úspora energie :

Díky již zmíněné konsolidaci jsme schopni uspořit také dosti významně spotřebu el. energie.

Dell jde o trochu dále : Velice mě zaujalo, když jsme byli na exkurzi v naší centrále Austin, Texas, USA. Budově Round Rock 5, kde je vývojové středisko pro enterprise produkty (primárně servery). Kromě vyspělých měřících zařízení, zaměstnáváme také několik hudebníků, kteří poslouchají hluk ventilátorů a pomáhají tak ladit jejich vibrace a hlučnost. Výsledkem je menší spotřeba energie a výrazně menší hlučnost, než konkurence. Zrovna tak naše zdroje dosahující na trhu nevídanou efektivitu 92%+ (převod AC / DC tedy pouze 8% je režie zdroje)

Dell Blade řešení spoří až 15% el. energie oproti HP řešení a až 22% oproti IBM řešení

Jak to dokazuje nezávislá studie : http://www.dell.com/downloads/global/products/pedge/en/BladePowerStudyWhitePaper_08112010_final.pdf 

- Flexibilita :

Vzhledem k tomu, že blade servery se mohou mezi sebou zaměňovat, je možné velice jednoduše přesunovat blade server z jednoho chassis do druhého opět v rámci minut.

Dell jde o trochu dále : Patentovaná technologie FlexAddress, která umožňuje přepsat WWN a MAC fyzické adresy na adaptérech serverů virtuálními uloženými v chassis. Obrovskou výhodou zde je, že není na úrovni switchů, jako je to třeba u konkurence. Díky tomu je naše řešení výrazně méně nákladné, než řešení konkurence vyžadující drahé proprietární switche.

FlexAddress video

- Disk Less :

Blade servery jsou ideální pro kombinaci s diskovým polem typu SAN. Dá se na nich nastavit tzv. Boot From SAN. Věděli jste, že až 30% spotřeby serveru můžou tvořit HDD ?

Boot from SAN video

Také se dá využít možnost, kterou nám nabízejí dnešní virtualizace jako je VMWARE ESXi nebo Citrix XEN SERVER,  Hypervisor bootuje z  SD Karty. Virtuální servery jsou pak umístěny většinou na diskovém poli SAN.

Dell jde o trochu dále : Nabízíme Dual SD v systemu RAID1 pro vyšší dostupnost

- Dostupnost :

Je také možné vytvoření hot-spare blade pro účely výpadku jiné žiletky.

Dell jde o trochu dále : Kombinací FlexAddress a Boot from SAN se dá vytvořit naprosto ideální systém, schopen zkrátit dobu výpadku v případě havárie nebo upgrade (Recovery Time Objective).

Nevýhody Blade Řešení (primárně souvisí s nezaplněným chassis) :

- Napájení :

I když jsou blade servery designovány na minimální spotřebu el. energie, chassis jako takové musí být dimenzováno na maximální osazení. Stejně tak je nutnost pro zachování el. vyhlášky přívodní kabely mít dimenzovány na max. osazení.  Musíme si uvědomit, že blade servery vyžadují konektor C20/C19, který je na 32A což rozhodně není standardní 16A konektor, jak jej známe z RACK/TOWER serverů a osobních počítačů,který se zasouvá do standardní 220V zásuvky.

Pokud byste chtěli Blade Chassis zastrčit rovnou do zdi, tak zástrčka vypadá nějak takto :

Realizace tedy probíhá v praxi přes tzv. PDU (Power Distribution Unit)

Zde je ukázka realizace redundantního zapojení dvou single fáze 2x30A obvody ! (zástrčka na obr. je pro USA)

Z informací zde uvedených chci říci, že implementace blade řešení vyžaduje trochu přípravy a někde může být i neproveditelná díky nedostatku přívodních el. rozvodů (tedy velikosti jističů a průřezu přívodních drátů). Také z toho vyplývá, že je výhodnější, když už se všechna ta investice a pro kabelování a přívodů udělala, aby bylo chassis zaplněno co nejvíce.

Pokud vás zajímá více informací - zde je odkaz na whitepaper zapojení Blades : http://en.community.dell.com/techcenter/blades/w/wiki/pdu-selection-whitepaper.aspx

Můžete také využít interaktivního poradce na : www.dell.com/rackadvisor

- I/O Konektivita :

Je tvořena Externí konektivitou (tj. konektivita s okolním světem mimo blade chassis) a interní konektivitou (tj.konektivita I/O modulů oproti serverům). Interní konektivita je důvod, kdy je nevýhodné provozovat nezaplněné chassis. I/O Moduly totiž mají stejný počet portů do vnitřní konektivity, jako je portů k serverům (v některých případech i 2 na server). Pak vzniká situace, kdy si koupím např. switch PowerConnect M6220, který má 4x Konektivitu na venkovní porty a 16x Konektivitu uvnitř chassis. Pokud využívám pouze 2 nebo 4 žiletky, zbývá mi poměrně hodně portů na switchi který jsem zaplatil, ale nejsem schopen využít, dokud nezaplním celé chassis.

Máme také velice zajímavé řešení zejména pro virtualizaci na 1Gb infrastruktuře. Virtualizace nám sice šetří servery, ale vyžaduje poměrně hodně síťových konektivit. Vytvořili jsme switch, který má dvě konektivity na interní port. Samozřejmě to vyžaduje speciální karty, které jsou 4portové. Takovýto switch má tedy interní konektivitu 32 Portů a 16 externích portů. Ještě více zde platí, čím více serverů zaplním, tím více se mi to vyplatí.

Tento problém u menšího počtu serverů můžu začít řešit tzv. Pass-thru moduly. Jedná se v podstatě o inteligentnější patch panely, které pouze propojují 1:1 interní konektory s těmi externími. V tomto případě je tedy nutné mít externí switch, který mi ale zabírá U v RACKu a také propoje je nutné realizovat kabely, které ve stísněném prostoru slouží jako značná překážka v proudění vzduchu. Nehledě na to, že pak právě ztrácím ostatní benefity Blade řešení, jako je jednotný management pro servery a switche, jednoduchost přidání nového serveru. Musím řešit i zapojování kabelů zezadu a nestačí již jen zastrčit žiletku a vše ostatní udělat vzdáleně.

Dell jde o trochu dále : I pro Pass-thru funguje FlexAddress. Toto je obrovská výhoda přinášející benefity velkého řešení i menším zákazníkům !

- PCI-E :

Blades díky své velikosti byli nuceni udělat kompromis na straně rozšiřitelnosti. Do Blade serveru se prostě nevejde klasická PCI-E Karta. Tudíž se nedají použít na některé účely. Jejich rozšiřitelnost se děje s pomocí tzv. mezzanin karet. Pokud bychom chtěli dát klasickou PCI-E kartu do blade serveru, je třeba udělat velký zásah do designu serveru.

Dell jde o trochu dále : Nám se to povedlo v modelu M610x. Toto řešení je určeno primárně pro zařízení typu NVIDIA TESLA (pro CUDA výpočty), hodí se do HPC prostředí na výpočty modelování např. geologického výzkumu. V dnešní době, se také objevují karty schopné akcelerovat virtuální desktopy (VDI). Dále se to dá použít pro FUSION-IO karty, PCI-E Flash paměti, které dosahují IOPS kolem 120 000 s velice nízkou latencí, což je ideální pro databáze, web search, atp. Další použití je např. SAS 2.0 řadič pro diskové pole nebo páskovou knihovnu.

Server M610x vychází z konceptu tzv. FH (Full Height) je to tedy server, který zabere dva blade sloty HH (Half Height) takových to serverů se vejde do chassis 1/2 tedy 8, nicméně typy serverů se dají bez problémů kombinovat. Jak určitě vidíte, komplikovaný design nás také donutil, že zde jsme se v tomto modelu neobešli bez kabelů.

- Storage :

Blade servery, díky jejich velikosti, mohou mít velice málo Disků. Jak jsme již psali výše, blades jsou designovány, aby pracovali s diskovým polem. Pokud nemáte diskové pole typu SAN/NAS (nikoli DAS), tak se opět pro vás výhody blade řešení zmenšují.

Dell jde o trochu dále : Naše Blade servery můžou být osazeni HW RAID řadičem. Všechny naše Blade servery mají Hot Swap HDD a sdílí stejnou platformu, jako servery stejné generace. Což přináší další flexibilitu a úsporu našim zákazníkům.

- ZaOtevřenost konkurenci :

Blade řešení je uzavřené proprietární řešení každého výrobce. Je tedy nemožné do blade chassis HP dát Dell Blade a naopak. Zrovna tak není možné dát do blade chassis jiné switche než umožňuje výrobce. Toto je hlavní důvod, proč někteří výrobci tak vehementně tlačí technologii blades jako tu “jedinou správnou”. Toto od Dellu nikdy neuslyšíte, vždy se snažíme dát to správné řešení pro zákazníka a to rozhodně není vždy Blade technologie.

Co říci závěrem ?

Dnes jsem se snažil ukázat vám jaké jsou dostupné technologie pro velká datová centra. Se současným trendem virtualizace, kde jsme schopni dosáhnout konsolidačního poměru přes 10:1 (virtualních serverů na fyzickém). To znamená, že při použití 2-3 serverů a sdíleného úložiště jsme schopni pokrýt 90% potřeb podniků české nebo slovenské kotliny.

Dokonce nám vychází vstříc i výrobci virtualizací s balíčky typu VMWARE vSphere Essentials (3 fyzické servery + management nástroj) nebo Microsoft HyperV & System Center Essentials (až 50 Serverů celkem F/V + management nástroj).

Klaďte si otázky :

- Kolik mám fyzických serverů před virtualizací ? 10 20 100 ?

- Jak je spravuji ?

- Kolikrát přidávám server do infrastruktury ?

- Jaké mám volné místo v RACKu ?

- Jaký mám přivod el.energie  do serverovny ?

- Mám pobočky ? Hodila by se mi flexibilita jednoduchého přesunu serverů mezi pobočkami ?

- Mám diskové pole typu SAN/NAS ?

- Jdu virtualizovat ? A na kolik serverů ?

Blade chassis se začíná vyplácet pokud zaplníme kolem 1/2. Avšak s tím, že mám vyhlídku na zaplnění celého chassis.

Naopak zákazníci, kteří nemusí přemýšlet, zda jsou pro ně blades vhodné či nikoli, jsou ti, co kupují plné Chassis a ne jednotlivé blady.

Co budoucnost ?

Velice zajímavé je spojení blade technologie a storage. Již dnes jsou výrobci, kteří nabízí storage do bladového řešení. Storage Blade přináší totiž obrovskou výhodu v jednoduchosti propojení s ostatními žiletkami. Tyto disková pole nejsou ale Enterprise Class, což je trochu v rozporu, kde se blade technologie používá.

Jestli bude mít Dell Enterprise Storage do Blade Chassis ? Ehm … No Comment. To je vše, co mohu dnes k tomu říci.

Tento článek bude mít pokračování ve formě srovnání Blade technologie se Sdílenou infrastrukturou (tedy HW pro Cloud poskytovatele) …

Po publikaci aktualizuji odkaz zde : http://optimalizovane-it.cz/servery/neni-blade-jako-blade-predstavujeme-sdilenou-infrastrukturu-poweredge-c.html

Začneme možná trochu zeširoka. Problémem, který pálí každou firmu, je výpadek provozu často doplněn o ztrátu dat.

Proti ztrátě dat nás chrání technologie zálohování dat, s výpadkem provozu si poradí technologie vysoké dostupnosti (viz. http://en.wikipedia.org/wiki/High_availability).

V současnosti prožíváme datovou explozi. Sami si dokážete představit, jak se v poslední době znásobila velikost soborů, které ukládáme. Ovšem jde o to, udržet tempo v oblasti zálohování dat a jejich vysoké dostupnosti, když nám jejich množství roste exponenciálně pod rukama. Důležité je uvědomit si, že když data ukládáme, děláme to většinou po menších přírůstcích, avšak zálohovat bychom měli co nejrychleji. Co to je nejrychleji? Rychlost souvisí s více faktory. Chceme-li zálohovat data, která jsme vytvořili, musí být tato data konzistentní (viz. http://en.wikipedia.org/wiki/Data_consistency ). Nejlepší konzistence dat lze dosáhnout, pokud se s daty v průběhu zálohování nepracuje. Proto je také zálohování ve firmách většinou nastaveno přes noční hodiny, tak aby se nekrylo s dobou, kdy by ještě mohli uživatelé pracovat (např. od 22:00 – 6:00 = 8h). Pokud se tedy ve firmě zálohování „vejde“ do tzv. zálohovacího okna (v našem případě 8h), je všechno v pořádku. Jestli-že by ale zálohování trvalo déle, můžeme mít velký problém.

Parametry pro určení cíle zálohování a vysokou dostupnost:

Recovery Point Objective (RPO)

(viz. http://en.wikipedia.org/wiki/Recovery_point_objective ) Parametr, který nám určuje, kolik dat zpátky od kritické události máme. Opět platí jednoduché pravidlo: pokud mám nastaveno zálohování 1xdenně je jasné, že pokud se mi něco stane ve 12:00 a přijdu o všechna data, tak jsem schopen obnovit ze zálohy pouze data vytvořená do 22:00, tedy data vytvořená včera (opět bereme náš příklad). Je na vedení firmy, aby si rozhodlo, kde chce na této časové ose být. Samozřejmě čím blíže jsme nulové ztrátě dat, tím dražší technologii musíme použít.

Technologie, které nám zde pomáhají:

- Pravidelné zálohování – Na pásky nebo na pevné disky
- Clony & Snapy
- Replikace (diskových polí) viz. (http://en.wikipedia.org/wiki/Storage_replication#Disk_storage_replication )

Recovery Time Objective (RTO)

viz. http://en.wikipedia.org/wiki/Recovery_time_objective) parametr, který nám určuje, za jak dlouho od kritické události bude systém opět 100% funkční. Zde jsou již zmíněné technologie typu High Availibility atp. Pro určení kvality řešení se uvádí systém tzv. devítek - jedná se o procenta dostupnosti systému jako celku. Ve velkých enterprise řešeních se většinou bavíme o tzv. 5ti devítkách (= 99.999% dostupnosti). Takovéto řešení musí mít maximální výpadek za rok 5.26 minuty! (Jen pro představu si můžeme vyzkoušet restartovat notebook, který již nějakou dobu používáme a hodně se přiblížíme této hodnotě!)

Technologie a procesy, které nám zde pomáhají:

- Pravidelné zálohování – (páska/HDD)
- Clony & Snapy
- Clustering (viz. http://en.wikipedia.org/wiki/High-availability_cluster )
- Servisní smlouva
- Replikace

Přirovnání:

Můžeme si to představit na vaně, do které se jdeme vykoupat. Když vanu napouštíme, máme k dispozici vodovodní baterii a určitý tlak vody. Vana se tedy nenapustí hned, ale trvá to jistou dobu (jako vytváření dat). Jakmile se vykoupeme, vanu vypustíme (přesuneme vodu do jiné oblasti - do kanalizace). To se dá přirovnat k zálohování, kde sice nedochází k přesunu, ale „jen“ kopírování dat, nicméně jako příklad to lze dobře použít. Tedy pokud začneme vypouštět vanu, pak rychlost, s jakou se vana vypustí, je závislá na tom, jak velký „otvor“ mám pro výpusť. Pokud bych chtěl mít vanu vypuštěnu „okamžitě“, musím ji překlopit a použít pak jako výpusť celý horní otvor. To je ale v našem případě v podstatě neproveditelné. Jediné, co se tomu blíží je právě technologie Klonů a Snímků (Clone & Snapshot). Nejdůležitější je tato technologie právě pro RTO, protože snap je připraven ihned k použití. Tyto technologie si teď představíme.

Co je snapshot a jak na něj

Snapshot (viz. http://en.wikipedia.org/wiki/Snapshot_(computer_storage)) je standardní termín pro schopnost zaznamenat stav paměťového zařízení k danému okamžiku, určená pro rychlou obnovu dat. Snapshot je kopií dat k určitému času (Point-in-time-copy). Většinou je Snapshot po vytvoření okamžitě k dispozici pro použití v jiných aplikacích, jako je zálohování, testování či analýza dat. Originální data jsou i nadále k dispozici aplikaci bez přerušení provozu, pouze s minimálním pozastavením datového toku. Díky snapshotům je možné rychle obnovit například omylem smazaná data bez nutnosti použití obnovy pomocí zálohovacího software. To je obzvláště přínosné, pokud úložiště umožňuje vytvořit velké množství snapshotů v krátkých časových intervalech. Vytváření snapshotů s sebou nese nároky jak na výkon, tak na kapacitu datového úložiště v závislosti na použité metodě tvorby snapshotů.

Existuje několik způsobů vytváření snapshotů, z nichž každý má své výhody a nevýhody. Nejčastěji používanou metodou je „kopie při zápisu“ (Copy-on-write). Copy-on-write snapshot je vytvořen v prostoru vyhrazeném pro snapshoty. Při úvodním vytvoření snapshotu jsou pouze zkopírována metadata s definicí umístění bloků originálních dat. Při změně originálních dat jsou nejprve bloky, které mají být přepsány, zkopírovány do prostoru vyhrazeném pro snapshoty a pak jsou teprve přepsány.

Postup fungování Copy-on-write snapshotů se dá shrnout do následujícího jednoduchého postupu:

1 - Snapshot vytvoří logickou kopii dat. (tzv. Pointry, můžeme si představit jako zástupce na ploše)
2 – Požadavek na přepis originálních dat způsobí nejprve zkopírování těchto dat do prostoru vyhrazenému pro snapshoty a pak teprve přepsání dat.
3 – Čtení ze snapshotu je přesměrováno na originální data, pokud ještě nebyla změněna.
4 – Čtení ze snapshotu dat, která již v originální lokaci byla změněna, je provedeno ze snapshotu.
5 – V případě snapshotu s povoleným zápisem, nemají zápisy do snapshotu vliv na originální data.

Největší nevýhodou Copy-on-write snapshotů je vysoký nárok na výkon zařízení, které snapshoty vytváří, jelikož při změně originálních dat je nutné provést dvě operace. Nejprve originální data zkopírovat do prostoru pro snapshoty a pak teprve provest jejich změnu. Z tohoto důvodu mají zařízení, používající tuto technologii snapshotů, poměrně nízké limity na maximální množství vytvořených snapshotů.

Druhou metodou vytváření snapshotů je metoda Split-Mirror (také známý jako Clone). Při ní dochází k zrcadlení dat na další disky a v případě potřeby snapshotu dojde k přerušení tohoto zrcadlení. Výhodou metody Split-Mirror je fyzické oddělení kopie dat, kdy při vytvoření snapshotu nedochází k zatěžování disků s originálními daty. Nevýhodou jsou vysoké nároky na kapacitu, protože je potřeba mít dvojnásobnou kapacitu diskového úložiště.

Třetí, nejzajímavější metodou je „přesměrování při zápisu“ (Redirect-on-Write). Redirect-on-write při vytvoření snapshotu zmrazí originální data a nové zápisy jsou přesměrovány do volného diskového prostoru, což platí jak pro originální data, tak pro přepis dat ve snapshotu. Díky tomu je vliv snapshotu na originální data minimální a k jejich zatěžování dochází pouze při intenzivních čtení snapshotu. Rovněž je vytvoření snapshotu touto metodou méně náročné než při použití Copy-on-Write. Věcí, na kterou je třeba si dát pozor při R-O-W snapshotu, je fragmentace. Jednoduché řešení fragmentace je například Automatický Storage Tiering (viz. http://optimalizovane-it.cz/storage/co-to-je-automaticky-storage-tiering.html )

Hlavní je být konzistentní

Při vytváření snapshotů, ať již jakoukoliv metodou, je potřeba si uvědomit, že ačkoliv se jedná o okamžitou kopii dat, je potřeba na krátkou dobu zastavit IO operace pro zajištění konzistentních dat. K zajištění konzistence nejrozšířenějších aplikací (MS SQL, Exchange, Oracle, Sharepoint a další) bývá k dispozici od dodavatele datových úložišť integrační software, který komunikuje přímo s úložištěm a stará se o pozastavení IO během vytváření snapshotů. Krátkodobé pozastavení IO má na běh aplikace zanedbatelný vliv a zaručuje snadnou obnovu dat ze snapshotu.

Přirovnání:

Pokud bychom používali diskové pole, které nemá konzistentní snapshoty je to totéž, jako kdybychom najali skupinku sice velice rychlých a šikovných dělníků, ale bez mistra, aby vyložili hromady uhlí z nákladního auta do sklepa. Oni by sice vše provedli rychle, ale neotevřeli by okénko do sklepa. Hromadu tedy máte, ale je vám to vlastně k ničemu. Snapy bez aplikační konzistence jsou na tom podobně. K čemu mi jsou data, které sice mám, ale v případě havárie, když je chci obnovit, mi aplikace napíše, že jsou nekonzistetní a já je (v lepším případě) musím podrobit nějaké kontrole konzistence, v horším případě je pak nemohu použít vůbec? Toto mi pak opět prodlužuje RTO.

Všechny typy snapshotů potřebují nějaké místo navíc. Kromě split-mirror(Clon), které potřebuje 100% kapacity ostatní typy potřebují „jen“ tolik, kolik bude změn. Jak však toto predikovat ? Velice špatně. Můžeme vycházet z nějakých doporučení cca 20-30% kapacity. Problém je, že toto místo bývá pevně prealokováno a ubírá nám tak volné místo v diskovém poli. Tato rezervovaná kapacita může zabrat opravdu velký prostor a je třeba tedy tuto část nepodcenit. To bývá také jeden z důvodů, proč u některých diskových polí není tento systém moc využíván. Nicméně jsou také výrobci, kteří používání snapshotů nijak nelimitují na prealokaci prostoru. Šetří tím velice kapacitu zákazníkova zařízení.

Důležitá je také správa snapshotů. Pokud chci snapshoty využívat pravidelně, je třeba, abych na to měl nějaký komfortní nástroj - snapshot manager. Ten mi umožní nastavit pravidelnost (tzv. schedule) a tím mi zajistí právě již zmiňovanou aplikační konzistenci. V neposlední řadě také umožní nastavit trvanlivost snapshotu. Tyto parametry pak, spolu s četností snapshotů, dají dohoromady počet snapshotů, který se bude udržovat metodou FIFO (viz. http://en.wikipedia.org/wiki/FIFO ). Dejme tomu, že nastavíme snapshot každých 15minut a jeho trvanlivost na 2dny. To je 192 snapshotů. Proto je velice důležitý parametr, kolik pole snapshotů podporuje. Z tohoto příkladu ale také vidíme, že je vhodné provést nějakou kombinaci více snapshotů k jednomu svazku. Pro dosažení co nejkratšího RPO, ale zároveň pro vylepšení zálohování, doplnění nějakého denního, týdeního popříp. měsíčního schématu.

Nechte snapshoty pomoci zlepšit RTO a RPO

Jak již bylo zmíněno výše, snapshoty nám mohou výrazně pomoci při zlepšení těchto parametrů. Jednak je to jejich četnost (zde jsme schopni se dnes již dostat na úroveň minut) = RPO, dále pak je to rychlost a jednoduchost zapojení do ostrého provozu = RTO. Snapshoty nám ale mohou pomoci i ke zlepšení „klasického“ zálohování použitím zálohovacího SW. Pokud totiž používám aplikačně konzistentní snapshoty, mohu si dovolit zkombinovat tuto technologii a připojit si tento snap k zálohovacímu serveru a čerpat data z této oblasti. Proč je toto důležité ? Opět se vraťme na začátek článku. Jestliže mi toto „klasické“ zálohování trvá 8h, tak se bohužel určitě dostanu do stavu, kdy část dat, která již mám od zálohována, odpovídají času 22:00, ale část dat odpovídá třeba 04:00. Díky tomuto logickému paradoxu se může jednoduše stát, že dokončená záloha nebude odpovídat chtěnému stavu. Použitím snapu začínám zálohovat tzv. zmražená data, jejichž konzistence odpovídá času vytvoření snapu. Jak dlouho takováto data zálohuji, mě v podstatě nezajímá (nesmím samozřejmě překročit další mezník, což je 24 hodin), jelikož se již nemohou změnit a dokonce mám zajištěnou jejich konzistenci.

Doporučená kritéria pro výběr

Rozhodneme-li se pro pořízení diskového pole s technologií Shapshots, je vhodné zjistit si dopředu několik základních parametrů:

• Jaký typ snapshotů a klonů pole skutečně podporuje? Nejlepší je Redirect On Write (pak ale, podporuje pole Automatický Storage Tiering?)
• Je nějaký limit ve vytvoření snapshotů? Nejlepší je bez omezení.
• Je nějaká prealokace prostoru pro klony a snapy? Nejepší je bez prealokace prostoru
• Umí storage provádět aplikačně konzistentní snapshoty? Důležité je pro vámi používané aplikace.
• Kolik mohu vytvořit snapshotů pro jeden svazek? Jsou pole, kde mohu vytvořit jen jeden!
• Jakým způsobem jsou snapshoty spravovány – Snapshot manager?
• Podporují snapshoty aplikační konzistenci ? Jak je řešeno licencování ?
• Jaký je nejmenší čas periody vytváření snapshotů?

Autoři článku: Radek Schutz, Dell Storage Architect, Ondřej Bačina, Dell Enterprise Brand Manager

Ještě před několika lety využívaly společnosti většinou jeden či dva terabajty diskového prostoru. Množství vytvořených a uložených dat se však každý rok zvětšuje exponenciálně.

Mezi největší konzumenty datového prostoru se řadí videa v HD kvalitě, rentgenové snímky, fotografie či virtuální servery. Problém je, že většina dat uložených v současnosti jsou tzv. nestrukturovaná data, tedy data, ke kterým máme jen málo informací pro lepší automatické třídění viz obr. 1. V současnosti tak nejsou vyjímkou společnosti, které na svých diskových polích udržují více než 50TB dat.