Optimalizované IT - portál pro IT pro komunitu

DELL PERFORMANCE ANALYSIS COLLECTION KIT

DPACK je jednoduchý nástroj, který umožňuje měření zátěže Windows, Linux a ESX serverů. DPACK sbírá data o počtu IO operací, jejich velikosti, době odezvy, hloubce fronty, MB/s, vytížení CPU a operační paměti.

 

ÚVOD

Tento nástroj byl vytvořen specialistou ze společnosti EqualLogic v době, kdy přišel na trh FC4 a disková pole EqualLogic měla “jen” 1Gbit. Obchodníci konkurence pak chodili po zákaznících a vysvětlovali jak je strašně důležité mít co největší “rouru” k diskovému poli. Skutečnost je ale naprosto někde jinde, jak také ukazují drtivá většina měření kde se ukazuje, že je velkou výjimkou pokud společnost přesáhne agregovanou propustnost větší než 100MB/s tedy 1Gbit konektivita ! Dnes jsme tento nástroj dali k dispozici našim zákazníkům zdarma, aby zjistili co opravdu potřebují a nekupovali si zbytečně technologie, které vůbec nevyužijí, nebo naopak dokonce technologie, které jim nebudou fungovat správě pro jejich prostředí.

 

Aktuální verze aplikace je ke stažení na: http://www.dell.com/downloadDPACK

 

Windows verze umožňuje měření Windows serverů pomocí PDH/WMI protokolů a ESX serverů přes vCenter. DPACK může běžet přímo na vCenter serveru.

Linux verze podporuje 32bit, ale ve většině případů správně funguje i na 64bit Linuxech. Měření probíhá přes SSH připojení.

 

 

Aplikace se nemusí instalovat a nevyžaduje instalaci agentů.

 

 

Aplikace se pouze spustí z libovolného stroje s LAN přístupem k měřeným serverům a po konfiguraci se nechá běžet. Aplikace standardně měří maximálně 24h.

V případě potřeby delšího časového intervalu stačí aplikaci spustit z příkazové řádky

s parametrem /extended (DellPack /extended v případě Linuxu ./dellpack -e) a pak je v GUI

možné zvolit až 7dní.

 

Linuxová verze nemá GUI, ale jednoduché textové menu.

Doba měření je závislá na konkrétním prostředí a je potřeba ji zvolit po dohodě s Vaším Dell konzultantem.

 

 

Upozornění:

Virtuální stroje běžící na ESX serverech spravovaných přes vCenter se do DPACKu nepřidávají, protože by došlo k duplicitám.

Passthrough disky (v případě iSCSI/FC iniciátoru ve virtuálním stroji) nejsou podporovány a je nutné

přidat virtuální stroj do dpacku samostatně To samé platí o NFS volume. RDM u ESX je podporováno.

Linux verze zatím nepodporuje clustery.

NFS Datastore je podporovaný na ESX 4.1 a vyšší.

Volba „Generate Uncompressed XML file“ kromě standardního šifrovaného/komprimovaného výstupu vytvoří i nešifrovaný XML soubor pro kontrolu sebraných dat (v případě obavy o bezpečnost)

DPACK nepodporuje ESX bez vCenter serveru. V tomto případě je nutné přidat VM samostatně.

V prostředí s ESX servery a fyzickými Windows servery spusťte měření dvakrát. Jednou pouze ESX a

podruhé ostatní windows servery z důvodu snadnější analýzy.

 

 

VMware a WINDOWS

Po spuštění aplikace stačí přidat všechny servery, které se budou měřit (aplikace se v případě potřeby zeptá na přihlašovací údaje – žádná jména/hesla nejsou ukládána ve výstupním souboru).

Přidání VMware vCenter:

Přidání serverů s OS Windows:

Zvolit požadovaný časový interval a stisknout START CAPTURE:

Aplikace se zeptá na kontaktní údaje:

a kam má uložit šifrovaný a komprimovaný soubor s výsledky a poté se nechá běžet:

 

LINUX

Linux verze se po spuštění zeptá na kontaktní údaje

[radek@localhost dpack]$ ./dellpack -e

Dell Performance Analysis Collection Kit BETA (version 0.9.2.202100) running.

By typing "yes" below, you acknowledge that you have read and accept the terms of the EULA

found in the EULA.rtf file included with this tool.

If you do not accept any of the terms for any reason, please type "no." (yes/no): y

Outputting debug trace to DPACK_TroubleshootingTrace0.txt

Please provide your contact information.

This information will be embedded into the resulting data file.

Enter contact first name (return to skip entering any contact info): Jan

Enter contact last name: Novak

Enter contact company name: Společnost XY

Enter contact phone: 725079774

Enter contact e-mail: jan_novak@firma.cz

Pak se zeptá zdali chcete měřit lokální disky stanice na které aplikace běží

Identified 1 physical disk on server 'localhost.localdomain'. Machine.................................Disk.......................... localhost.localdomain sda

Press any key to continue.

Physical disk identified: sda

Size: 20.00 GB Used: 16.96 GB Free: 3.04 GB

Would you like to monitor this disk during the session (yes/no)? Y

A pak zobrazí jednoduché menu

1 server(s) and 1 disk(s) in list out of a maximum limit of 256 servers and 256 disks. Please select one of the following options by pressing the key in parentheses:

(1) Begin monitoring

(2) Change the output filename. (currently localhost.localdomain.iokit) (3) Change the session duration. (currently 24 hours)

(4) Show a table of the current machines and disks to be monitored. (5) Add a remote machine to be monitored using a remote shell.

(6) Change the name of a machine to hide it's identiy.

(7) Toggle setting for creating non-compressed xml copy of output (currently false). (8) Remove a disk from the list of disks to be monitored.

(9) Quit.

Volbou 5 přidáte další servery (přes SSH)

Volbou 3 upravíte dobu měření

Volbou 2 změníte jméno výstupního souboru

Volbou 1 spustíte měření

 

Závěr

Po ukončení měření stačí vytvořený soubor *.IOKIT odeslat emailem do Dellu nebo Dell Certified Partner k analýze.

My data zpracujeme a výsledný report bude kromě souhrnných informací o I/0, propustnosti a latenci obsahovat detailní informace o jednotlivých měřených serverech.

Ukázka vytvořeného reportu zde :

V případě jakýchkoli nejasností neváhejte kontaktovat našeho certifikovaného partnera na www.dell.cz/findapartner  nebo Value Added Distributora DNS http://www.dns.cz/cs/produkty-a-sluzby/vyrobci/dell/

Pokud máte přímého Dell obchodníka neváhejte samozřejmě kontaktovat jeho.

 

Tento článek vytvořil Radek Schutz, Dell Storage Architekt a následně doplnil Ondřej Bajer, Dell Storage Sales Executive

Jaké jsou největší výzvy migrace dat a co jsou důvody pro migraci. Jak nám může pomoci virtualizace a nebo přímo diskové pole s HW podporou migrace ? Odpovědi najdete v tomto článku.

Tak jak jsme zde již několikráte popisovali v článcích o diskových polích (např. http://www.optimalizovane-it.cz/storage/storage-pro-smb.html ) je v současné době nárůst dat opravdu významný a je to aktuální problém skoro každé společnosti. Tento problém se pak projeví nejen ve vlastní datové správě této kapacity, ale také v případě migrace z jednoho zařízení na druhé. Migraci dat chápejme jako kompletní přesun dat celé aplikace nebo dokonce celého diskového pole.

Největší výzvy migrace dat ?

Migrace dat z jednoho diskového pole na druhé je velice těžce proveditelná pokud diskové pole nebo OS nám v tomto nějak neumějí pomoci. V takovém případě se přesun dá udělat pouze v Off-line režimu, tzn. musíme aplikaci vypnout a odpojit od serveru a pak přesunout data. Po úspěšném přesunutí dat se musí provést přemapování svazku mezi diskovým polem a serverem a pak teprve opět nastartovat aplikaci.

Jak rychle se to přesune ?

Zde je jeden z mála příkladů, kdy se OPRAVDU využije propustnost diskového pole, nicméně to jako vždy závisí na spoustě dalších faktorů než jen na “trubce”, která mi vede z diskového pole. Podíváme-li se na čísla (ve kterých je dost často zmatek) tak hodnota přenosu dat je udávána v b per second tedy bps (Bit  http://en.wikipedia.org/wiki/Bit ) ukládání dat se ale udává v B (tedy Byte http://en.wikipedia.org/wiki/Byte) jak se dopočítat ?

Jeden Byte = 8xbit

Mám-li k dispozici propojení mezi diskovými poli 1Gb pak je to 1024(Mega bit)/8= 128(Mega Byte) TEORETICKA maximální propustnost (která ale není nikdy v reálném nasazení dosažená) je 128MB za jedu vteřinu. Reálně se můžeme bavit o hodnotě kolem 100MB/s přes 1Gb síť.

Pokud máme diskový svazek velký 1TB a chceme ho přesunout přes 1Gb síť (1024GB = 1048576MB /100 = 10485,76 Sekund přenosu /60 = 174,7626666666667 minut /60 = 2,912711111111111 Hodiny) pak ho přenášíme v ideálním případě skoro 3 hodiny. Pokud se jedná o data kritické aplikace jistě je takováto doba naprosto neakceptovatelná ! Teoreticky mohu použít propojení 10Gbit a můžu se dostat k 10ti násobku na nějakých 30min. jenže praxe není tak jednoduchá jako teorie. Nehledě na to, pokud budeme přenášet data z celého diskového pole, kde to mohou být Tera Bajty dat, pak mi ani větší “roura” nepomůže k tomu, abych neměl výpadek.

Jaké jsou omezující faktory ?

Celý systém je pouze tak rychlý jako je nejpomalejší součást celého systému.

Disky

Pokud budu mít v systému pouze pár pevných disků nepomůže mi ani kdybych byl propojen 100Gbitem. Je to samozřejmě závislé od výrobce disku. Běžně počítá s hodnotou kolem 40MB/s na jeden disk. Dnes jsou již na trhu disky s větší propustností, nicméně pokud budeme přesouvat data z diskového pole staršího na novější tak můžeme typicky počítat s takovouto hodnotou. Pak pokud budu mít 10 HDD dostanu se k nějaké teoretické rychlosti 400MB/s a nebudu tedy schopen využít ani 1x 10Gbit linku.

Čím rychleji chci, aby se data přenesla, tím více HDD/SSD musím v systému mít (na obou stranách !)

Storage Procesory diskového pole

Další omezující faktor celého systému migrace dat jsou vlastní procesory diskových úložišť. Nejen, že záleží na tom jak moc je výkonný procesor daného modelu, ale také jakým způsobem je udělána architektura celého diskového pole. Nehledě na to, že pokud se bavíme o migraci ONLINE musíme počítat s tím, že diskové pole nedělá pouze migraci dat, ale právě naopak ! Jeho hlavním úkolem je poskytování výkonu a služby pro produkční prostředí a migraci provádí “na pozadí” nejlépe s nižší prioritou, nebo v lepším případě stejně rychle jako vše ostatní. Většina diskových polí k tomto přistupují tak, že uměle omezují propustnost jednoho Threadu ( http://en.wikipedia.org/wiki/Thread_(computing) ) pokud bych provedl kopírování na úrovni HOSTA (tedy serveru) pak se mi každé kopírování bude tvářit jako jeden thread. Běžné je omezení kolem 100MB/s na jeden thread. Pak se opět dostáváme do situace, že můžu mít kolik chci pevných disků a “rouru” jak od kanalizace, ale udělám-li jedno kopírování nikdy nevyužiji plný potenciál celého systému. Viz. obrázek, kde každý thread je rozdělen na svůj tok dat bez možnosti využít šířku celého dostupného pásma.

Storage Area Network

Samozřejmě, že je také velice důležité, abych nebyl omezován nějakými nekvalitními nebo výkonově nedostatečnými síťovými přepínači. Zde je nejdůležitější celková propustnost CPU celého přepínače. Často se stává, že hlavně ty cenově nižší přepínače používají tzv. oversubscribtion. Jedná se o nižší propustnost celého switche než je jeho maximální osazení. U iSCSI je pak důležitá podpora JUMBO FRAMES (http://en.wikipedia.org/wiki/Jumbo_frames) a vůbec celkově optimalizace switche na iSCSI jako jsou např. naše switche PowerConnect hlavně třídy 6000 a výše, protože ty mají automatické nastavení parametrů pro iSCSI a dokonce rozeznají např. diskové pole EqualLogic a nastaví se přesně pro jeho potřeby. Nebo je ideální zapojit do procesu nějaké Cache na úrovni switche jako máme např. u Dell Force10 S60, který má buffer až 1,25GB ! Dokáže tak pojmout výkonové špičky nejen storage komunikace. (http://www.dell.com/us/enterprise/p/force10-networking)

Host

Jedná se o server, který řídí celou operaci datového přenosu. Zde může být jeden z největších limitů celé operace. Propojení serveru s diskovými poli probíhá pomocí tzv. HBA (http://en.wikipedia.org/wiki/Host_bus_adapter) Toto je jedno z úzkých hrdel systému, protože obvykle nemá jeden server stejnou propustnost jako disková pole ke kterým je připojen. Zrovna tak je třeba myslet na to, že díky řízení celého přesunu dat musí z jednoho diskového pole data číst a do druhého pole data zapisovat. Probíhá zde tedy IN/OUT operace přecházející přes OS daného serveru a pokud jsou zde nějaké další procesy běžící na serveru dojde logicky ke zpomalení celého procesu.

TUTO ČÁST PŘESUNU DAT LZE VYNECHAT POKUD MI PŘESUN DAT PODPORUJE PŘIMO STORAGE tzv. SAN TO SAN MIGRACE

SAN to SAN migrace

Moderní disková pole tento způsob migrace dat často nativně podporují. U některých výrobců je funkcionalita v základní ceně, u jiných se licencuje per zařízení či per Terabyte. Nejznámější disková pole, která tuto technologii podporují jsou Hitachi USP, IBM SVC(StorWize) či DELL Compellent. Princip takovéhoto fungování je, že si diskové pole připojí to “staré” pole, jako kdyby bylo “server” a provede kopírování maximální možnou rychlostí na blokové úrovni.

Například DELL Compellent umožňuje pro účely migrace připojení těchto polí jiných výrobců, aniž by k tomu byla vyžadována speciální licence:

EMC AX, EMC CX, DELL MD, HP MSA, HP EVA, HP 3PAR, HP XP, IBM FastT, IBM ESS, IBM DS, IBM StorWize, IBM XIV, IBM SVC, SUN StorageTek, NetApp FAS, Hitachi USP, Infortrend EonStor, a další …

 

Migrace pomocí virtualizace

Migraci velice usnadňuje virtualizace serverů a možnosti, které přináší Hyper-V a VMware ESX. Dnes mohu provést ONLINE Migraci dat z jednoho typu storage na druhou pomocí nativních funkcionalit virtualizace. Tyto schopnosti jsou ale licencovány a např. u VMWARE se jedná o funkcionalitu dostupnou v poslední verzi již v Standard edici.

Složitější migrace nastává tam, kde je zapotřebí migrovat Pass-Through disky (Hyper-V), RDM disky (VMware), případně disky, které jsou součástí High-Availability clusterů. V takových chvílích můžou pomoci nástroje jako např. DoubleTake nebo Dell AppAssure.

Dále také většina společností ještě není 100% zvirtualizováno. Zrovna tak, jsou systémy jako např. Tru64, AIX či HP-UX pro které se migrační nástroje shánějí těžko, případně jsou velice drahé. Zde je nejvhodnější použít možnosti externí SAN virtualizace a migrace dat SAN to SAN.

Nehledě na to, že migrace probíhá na SW úrovni a zatěžuje tak virtualizaci.

Pomoc s migrací

Nástroje jsou krásná věc, ale k jejich úspěšnému používání jsou třeba zkušenosti z praxe. Rozhodně lze tedy doporučit každou migraci pečlivě naplánovat a objednat její provedení od certifikovaných specialistů.

Při migraci formou služby se často využívají různé migrační appliance, které umožní přenášet data mezi diskovými poli i během běžného provozu. V Dellu si můžete objednat službu, která využívá Fluid Data Mover a umožnuje připojit jakékoli diskové pole a jen s drobným odstavením z provozu přesunout data za chodu na jakékoli Dell pole.

Při nákupu diskového pole si nechte nabídnout i pomoc s migrací dat. Nezapomeňme, že tato práce storage administrátora potká jednou za x let, kdežto odborníci od dodavatele to dělají každý den. 

Kdy potřebuji migrovat ?

Migrace dat může být nutná v těchto případech :

Horizontální Tiering

Jedná se rozdělení více diskových polí dle vlastností použitelnosti a hlavně tzv. SLA ( http://en.wikipedia.org/wiki/Service-level_agreement ) toto můžeme vidět hlavně ve velkých společnostech. Můžeme si to představit na příkladu, kdy společnost potřebuje nastartovat např. marketingovou kampaň, jak je to ukázáno na obrázku. Pak na jejím začátku se jedná o velice důležitou aplikaci, která směřuje na Tier 1 Diskové pole. Kampaň může běžet třeba půl roku a po jejím zakončení a vyhodnocení jsou data použitelná pouze pro referenční a archivační účely. Je tedy velice neekonomické ponechat tato data v té nejdražší a nejlepší T1 Storage. Pro dosažení optimálního poměru cena/výkon bychom měli data přesunout na archivační typ storage T3+.

 

Fluid Data architektura plnohodnotný tiering

Naše architektura nezná pouze klasický vertikální tiering o kterém jsme si již psali zde : http://www.optimalizovane-it.cz/storage/co-to-je-automaticky-storage-tiering.html

Nýbrž také horizontální tiering ONLINE bez výpadkový a naprosto transparentní vůči připojeném serveru. Díky přesunu v rámci SAN 2 SAN konverze se jedná o maximální možnou rychlost přesunu dat, ale hlavně bez omezení chodu společnosti. Tyto technologie jsou dostupné jak v Dell EqualLogic tak v Dell Compellent.

Diskové pole přeroste kapacitu nebo je třeba technologický update

Většina výrobců nabízí diskové pole schopné růst jen do určité velikosti, pak je třeba provést velice drahý upgrade na větší model. Nejhorší je případ, kdy tento upgrade směřuje do jiné vývojové řady, kde tento upgrade v drtivé většině případů znamená zahození prvotní investice. V USA se začalo tomuto způsobu říkat tzv. Fork-lift upgrade, tedy upgrade pomoci vysokozdvižného vozíku, kterým naložíte vaší původní investici a vyhodíte jí. Na obrázku je vidět typické rozdělení storage dle segmentů a jejich omezení.

Tento upgrade v naší Fluid Data architektuře nehledejte. Fluid Data architektura dokáže více diskových polí brát jako jedno a využívat tak zdroje z obou a růst pomocí tzv. Scale Out (http://en.wikipedia.org/wiki/Scale_out#scale_out) Znamená to, že začnete s menší konfigurací a pokud potřebujete růst není problém dokoupit další puzzle do mozaiky a dojde k rozšíření infrastruktury.

Jediné co je důležité si vybrat, je způsob konektivity a zaměření storage, zkrátka pokud půjdete do Dell EqualLogic nebo Dell Compellent. Co je opravdu důležité je, že naše architektura dokáže mixovat i různé druhy technologií a tedy vás nenutí k drahému upgrade při změně technologie jako se to děje v současné době např. u diskových polí s FC Back End (http://en.wikipedia.org/wiki/Disk_array_controller#Front-end_and_back-end_side) na nové s konektivitou SAS 2.0. Jak je zřejmé z obrázku níže u naší architektury se nemusíte obávat nových technologií. Pokud hodláte nakoupit diskové pole teď, jistě počítáte s provozem min. 5 let, aby se vám investice dobře vrátila. V tom případě je VELICE důležité, aby jste si ověřili, jakým způsobem bude váš dodavatel tuto záležitost řešit, protože v těchto 5ti letech se bude přecházet na novou back end technologii SAS 3.0 (a kdo ví co ještě), které velice pravděpodobně bude mít nový konektor = bude třeba novou storage. Nová storage pak většinou znamená migrace dat a jste zase na začátku našeho článku. Pokud výrobce umožňuje upgrade bez migrace, tak se připravte na to, že si to také nechá velice dobře zaplatit. Mám zprávy od zákazníků, kteří zažili nabídky na 90% ceny nového diskového systému.

Jak vidíte na obrázku níže u Fluid Data architektury tyto problémy neexistují. Je možné provádět nejen rozšiřování, ale i přidávat nové technologie bez nutnosti migrací dat a drahých re-investic.

 

Konec životního cyklu diskového pole

Toto je jeden z nejčastějších důvodů pro migraci dat. Pokud máte současné diskové pole a to vám vychází ze záruky, je na čase podívat se po náhradě. Pokud budete nakupovat u jiného výrobce než máte aktuální storage, pak vás čeká migrace dat. Nejhorší je ale situace, že existuje spousta případů, kdy vás toto čeká i když zůstanete u stávajícího výrobce. Může to být způsobeno jednak změnou technologie, jak jsme popisovali v přechozím odstavci, nebo nutností jít do jiného typu storage, kde pak mezi sebou nejsou použité komponenty kompatibilní.

Na obrázku níže máme příklad kdy jsme koupili větší diskové pole a v průběhu jeho používání výrobce představil novou řadu. To poznáte podle toho, že vám zaťuká obchodník na dveře a začne vám vysvětlovat jak strašně potřebujete jedinečnou technologii, kterou má právě tato generace. Zde jsme odolali “útokům” a nechali si stávající technologii, protože nám ještě zbývala záruka. Po dalších letech již ale naše storage vychází ze záruky a my jsme nuceni provést upgrade na novou generaci. Velice pravděpodobně nás bude obchodník chlácholit, že se technologie vyvinula a  že již nepotřebujeme tak výkonnou storage a aby snížil cenu, tak vám nabídne nižší model. Je to asi stejné  jako, když budete jezdit 3 roky Superbem a pak vám obchodník “natlačí” Oktavii. Srovnání uživatelského komfortu nechám na vás. Díky tomu, že dříve byla připojení disků FC a tato nová storage již má SAS 2.0 tak i když jste si před dvěma lety zakoupili diskové police s funkčními disky ještě pod zárukou, můžete teď použít vysokozdvižný vozík a poslat disky do věčných lovišť, protože je nemůžete připojit do nového diskového pole. Právě zažíváte Fork-lift upgrade.

U naší Fluid Data architektury se tohoto nemusíme obávat. Ať Dell EqualLogic nebo Dell Compellent, obě disková pole umožní pokračovat online bez výpadku i na novém HW. V České republice díky tomu, že zde byl EqualLogic přítomen již před akvizicí společností Dell, máme reálné zákazníky, kteří používají dohromady původní EqualLogic PS100 spolu s novými PS5000 a nejnovějšími PS6100, což je  opravdu nejlepší ukázka ochrany investice zákazníka. U Compellentu naopak můžeme použít referenci z našeho Co-Pilot centra (Proaktivní supportní středisko pro diskové systémy Compellent). Zákazníku, který provede propojení  storage s naším Co-Pilotem, je automaticky nastaven jeho profil a hlídání funkce storage. Máme tak přehled o všech aktivních Compellentech připojených do tohoto systému. Můžeme hrdě sdělit, že 98% Compellentů prodaných od r. 2004 je STÁLE ONLINE A FUNKČNÍCH ! Samozřejmě, že ne všechny běží na původním HW, ale jejich upgrade na nový HW proběhl bez výpadku a transparentně vůči serverům. Tyto upgrady proběhli také za příznivějších cenových podmínek, protože Compellent má life-time licencing model, který zabezpečuje, že v případě přechodu na nový HW zákazník platí pouze upgrade HW nikoli SW jako u většiny konkurence.

 

Nejdůležitější je, že všechny tyto upgrade v rámci Fluid Data architektury probíhají bez nutnosti problematické migrace dat ! Nemusíte se tedy zabývat touto složitou otázkou.

Definice pojmů

Začneme rychlou definicí co chápu pod pojmem SMB. Jedná se o rozdělení trhu horizontálně, tedy podle velikosti zákazníka. SOHO (Small Office Home Office) je obecně vnímáno do 10 - 15 uživatelů. SMB je složeno ze Small Business a Medium Business. Small Business je do 100 uživatelů (v USA do 1000) a Medium Business je kolem 1000 (v USA kolem 10 000 uživatelů). Jak je vidět tak „americké“ SMB je v Čechách vnímáno poměrně níže, je to díky velikosti trhu. Já se budu zaměřovat na to „české“ SMB.

Storage neboli diskové úložiště je místem kam se ukládají data všech zaměstnanců a serverů společnosti. Stává se z něj tedy velice kritické místo, které nesmí selhat. Čím více zaměstnanců a dat na něm mám, tím lepší musí být, jak kvůli výkonu, tak kvůli dostupnosti.

PROČ ?

Tento článek vznikl na popud potřeby uvést na pravou míru předsudky, se kterými se setkávám nejen mezi menšími partnery, ale bohužel i v renomovaných časopisech, jako je třeba Reseller magazine, kde jsem se účastnil již několika kulatých stolů na téma SMB storage a seděl jsem tam s výrobci SOHO storage. Ukázka je např. : http://www.reselleronline.cz/svezte-se-na-vlne-cloudu-storage-pro-smb ,kde není zastoupen jediný výrobce SMB Storage. Toto pak vytváří nedůvěřivé zkušenosti u partnerů, kteří bohužel uvěří, že něco, co bylo určeno na ukládání fotek z dovolené, zvládne virtualizaci menší společnosti. Po negativní zkušenosti pak zavrhují storage jako celek.

Produkty určené SOHO nedostačují pro SMB !

Bohužel často se setkávám s předsudkem u menších partnerů a zákazníků : „Co mi stačí domů na filmy, můžu také použít v malé společnosti.“ Je důležité mít na paměti, že produkty určené primárně pro domácí použití do SMB nepatří. Stejně jako profesionální dělník nebude pracovat se ZELENÝMI produkty spol. BOSCH ale s MODRYMI (tedy určenými pro profesionály) stejně tak SOHO storage do větší společnosti nepatří. Pokud by si totiž pořídil ty zelené musel by si na každou stavbu kupovat toto zařízení nové. Jednoduše proto, že každé má svoje použití a cenu. Zelené kutilské produkty jsou určeny na občasnou práci nikoli na 8h „šichtu“. Diskové produkty dle segmentů poznáte dle těchto parametrů :

“Domácí kutil” : Consumer – SOHO

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

• NAS (storage připojená po počítačové sítí) Omezené možnosti redundance
• Vytvořeno pro zálohování uživatelských dat v domácnosti
• Limity těchto řešení se pohybují v jednotkách HDD
• Benefity : Pořizovací cena
• Omezení : Dostupnost, rozšiřitelnost, zálohování

“Profesionál” : Small & Medium Business

(primární zaměření na společnosti s více zaměstnanci)

• NAS, iSCSI s plnou redundancí všech komponent
• Určeno jako místo kde jsou data originální nikoli jen zálohy
• Limity jsou v stovkách HDD
• Benefity : Vysoká dostupnost, velká rozšiřitelnost (dokonce i bez výpadku, zjednodušené zálohování pomocí technologie snapshotů : http://www.optimalizovane-it.cz/storage/snapshoty-zpusob-jak-posunout-zalohovani-a-obnovu-dale.html )
• Omezení : nemají N+1 redundanci, hranice rozšiřitelnosti je kolem 1000 HDD

Obr. 1 – Srovnání prvků úložných systémů “Kutil = SOHO úložiště” a “Profesionál = SMB diskové pole”

Podrobněji o roztřídění storage jsem již psal v tomto článku : http://www.optimalizovane-it.cz/storage/storage-jak-se-segmentuje.html 

Způsoby konektivity

Konektivita k diskovému poli může být buď provedena napřímo mezi serverem a diskovým polem. Takovéto propojení se označuje DAS (Direct Attached Storage), nebo přes separátní izolovanou (buď fyzicky nebo virtualně) síť tedy SAN (Storage Area Network)

obr. 2 – Ukázka připojení serverů k diskovému poli s využitím SAN

Disková pole se připojují k serverům různými technologiemi. Zde jsem se pokusil udělat přehlednou tabulku jakými technologiemi se můžeme připojovat a jak vypadají konektory a kabely pro propojení :

obr. 3 – Ukázka způsobů konektivity k diskovým polím vč. konektorů a kabelů

Důležité parametry diskového pole

Výkonové parametry

IOPS

(vstupně/výstupní operace za sekundu)

Pokud to přirovnáme k autu, tak by se dal tento parametr přirovnat k maximální rychlostí vozu jakou jsme schopni s ním dosáhnout. Tato hodnota je ve společnosti většinou statická a v čase neměnná (pouze spuštění nové aplikace atp. Může vyžadovat vyšší IOPS). Tento parametr je velice důležité zjistit před pořízením diskového pole a pak ho v průběhu sledovat, abychom byli schopni včas zareagovat pro případ nutnosti jeho navýšení. Tento parametr se v zásadě zvyšuje počtem disků v systém. Tedy čím vice disků v systém mám tím vice IOPS dosáhnu.

Latence

(zpoždění)

V autě by to mohlo být rychlost odezvy na řízení. Pokud pojedu po prázdné silnici tak mi moc nebude vadit, že bude chvíli trvat, než zatočím. Pokud bych byl ale v hustém provozu už bych nebyl schopen řídit. Odlehčeně něco podobného je v diskovém poli. Latence je doba za jakou pole zareaguje na daný požadavek. Toto je důležité zejména u databází a projevuje se to pak pomalou funkčností systému. Je to také průvodní jev nedostatku IOPS.

Cache

(Mezi paměť pro neuložená data)

slouží jako dočasné úložiště schopné pokrýt krátkodobé výkonové špičky. Obecně platí, že čím větší Cache tím by to mělo být lepší, ale zde je to také dost závislé na technologii diskového pole.

Propustnost a šířka pásma

V autě by se to dalo přirovnat k tomu jak velké auto mám, tedy jestli mám osobní auto nebo dodávku či TIR. Tedy kolik toho za jednu cestu vezu. Šířka pásma je pak velikost silnice po,které jedu. Zde je jeden z největších omylů, které zažíváme dnes a denně. Na tento parametr se zaměřuje většina společností při nákupu diskového pole a přitom se jedná o nejméně důležitý parametr (speciálně v SMB). Díky tomu, že v menších a středních firmách není velký počet serverů (tedy aut na vozovce) není ani nutné abych používal dálnici. Bohatě mi stačí “okresní silnice” s mrštným a silným vozem. Přeloženo do řeči diskového pole : Nejdůležitější je IOPS s nízkou latencí, šířka pásma většině SMB firem dostačuje kolem 100MB/s tedy síťová konektivita 1Gbit. Jsem-li SMB zákazník je naprosto zbytečné hnát se za FC technologií, když mi bohatě dostačuje iSCSI. Nehledě na to, že 10Gbit iSCSI dokáže dodat větší propustnost než FC8. Problém může být právě ve špatné zkušenosti ze SOHO storage, která sice “hlásí” připojení 1Gbit, ale dostanete z ní horko těžko 10-15MB/s tedy skoro 10x méně než z SMB storage. Stejná situace je s propojovacími přepínači (Switch) pokud použiji na propojení serveru a diskového pole switch určený do SOHO segmentu můžu být rozčarován nad výkonem, který z celého systému dostanu. Přitom pokud bych použil switch určený a certifikovaný pro SAN neměl bych problém.

Nevýkonový parametr

Kapacita

Jediný parametr, který neutišeně roste. Viz obr. 4 Kde vidíme typický 30% meziroční nárůst kapacity, oproti téměř konzistentním IOPS. Kapacita se nejlépe řeší velkými, ale pomalými nlSAS HDD. Jak dosáhnout kombinace IOPS a kapacity s ohledem na to, že kolem 70% z dat, které mám jsou statická a tudíž k nim nepotřebuji pravidelně přistupovat ?

Obr. 4 – Typický růst storage ve společnosti. IOPS mi narůstají pouze při nárůstu zaměstnanců nebo nové aplikaci. Kapacita oproti tomu roste neustále

Jeden příklad z praxe

Problém s ukládáním dat si můžeme představit například takto: Máme několik důležitých virtuálních serverů, které nám na diskovém poli dohromady zabírají cca 2TB a vyžadují 1500 IOPS. Aby servery pracovali svižně, uložíme jejich data na 10ks pevných disků SAS s rychlostí 15.000 otáček (počítejme, že jeden disk má 150 IOPS) a kapacitou cca 600GB na disk. Tuto skupinu disků „naformátujeme“ pomocí RAID10. Tento typ RAID je nejvýkonnější, ale také nejméně efektivní. Jeho efektivita je 50% využijeme tedy jen ½ zakoupeného místa. V našem případě je to tedy 3TB před formátováním. Vznikne nám tedy prostor pro náš původní požadavek 2TB i s prostorem pro určitý růst.

Problém nastane ve chvíli, kdy se nám servery začnou rozrůstat, ať už do počtu(IOPS) či objemu(TB). Velmi brzy přesáhneme kapacitu našich 10-ti disků a bude potřeba dokoupit disky další, aby nám nedošlo místo. Brzy však pochopíme, že takové řešení nelze aplikovat do nekonečna, neboť pro uložení 50TB dat nám při této konfiguraci vychází, že musíme zakoupit cca 160ks pevných disků. A to už je docela velké číslo.

Toto se dá řešit technologií zvanou Automatický Tiering o kterém jsem již psal v tomto článku : http://www.optimalizovane-it.cz/storage/co-to-je-automaticky-storage-tiering.html

Jak získat informace jaké pole je pro mne to nejlepší ?

Obraťte se na odborníky !

Nemohu hovořit jak to dělají ostatní výrobce, ale my v Dellu spolu s našimi Dell partnery nabízíme našim zákazníkům software ke stažení zdarma zde: (http://content.dell.com/us/en/business/d/sb360/dpack-sc ). DPACK: Dell Performance Analysis Collection Kit. Tento nástroj neinvazivně zjistí potřebné informace pro správný návrh diskového pole. Výsledky shromažďování informací se pak pošlou k nám (jeden nebo více .xml souborů) a my vypracujeme analýzu jak váš systém funguje nyní a co se na něm dá zlepšit a jaké diskové pole bude vyhovovat a proč.

Dell serverová platforma mě dělá opravdu šťastným. Jsem velice rád, že mám na starosti nejlepší servery na světě ! Jak poznám, že máme nejlepší technologie na trhu ? Když vás konkurenti začínají kopírovat ! Udělalo mi velkou radost, když jsem po nedávném oznámení konkurence nové generace serverů viděl drtivou většinu věcí z naší předchozí 11.  Generace !

Je mi potěšením, že vám můžeme představit naší 12. Generaci serverů, která jde o více než jednu generaci dále.

Je toho opravdu hodně, proto udělám článek na pokračování.

Nepřekonatelná jednoduchost, výkon a hustota

Vylepšené procesory

Servery Dell PowerEdge 12. Generace jsou poháněny nejnovějšími procesory Intel řady E5 - 2600. Tyto procesory byli oficiálně uvedeny 7.3. a v české republice má Intel uvedení připraveno na 27.3.

• Až o 80 % lepší výkon ve srovnání s předchozí generací při stejné úrovni napájení
• Výrazné zkrácení času potřebného pro výpočty díky instrukcím Intel® Advanced Vector Extensions (více níže)
• Technologie Intel® Turbo Boost 2.0 podává výkon, když ho potřebujete
• Integrované DIRECT I/O rozhraní Intel® snižuje latenci a zároveň zvyšuje kapacitu a propustnost (více níže)

Architektura paměti

• Až 24 modulů DIMM ve dvou soketovém serveru
• O 33 % větší propustnost než u předchozí generace
• DELL : Memory Page Retire - Funkce pro ochranu RAM. Fungující podobně jako SMART na HDD. V případě, že nalezne vadný blok označí ho pro systém jako vadný a nevhodný pro používání.

Vysoce flexibilní síťové I/O rozhraní

• Možnost výběru z široké řady technologií a výrobců síťových adaptérů LOM (Lan On Motherboard)

Flexibilní síťové I/O VIDEO : 

• DELL : NPAR je nezávislá technologie na switchi i operačním systému, takže zákazníci mohou využívat takovou infrastrukturu síťových přepínačů, jaká jim vyhovuje. Vytvořte si až 4 nezávislé síťové adaptéry z jedné 10GB konektivity.

Výrazné vylepšení úložišť serverů

• Až 26 HDD do 2U

• Až 10 HDD do 1U

• Nové možnosti pole RAID zlepšují
flexibilitu a výkon (více níže) včetně v určitých serverech udělat konfiguraci dvou RAID řadičů pro vyšší CACHE a ostatní parametry storage  (toto nastavení je kvůli výkonu nikoli redundanci).

• Vysoce výkonná úložiště SSD
Express Flash (více níže)

• Hypervizor s funkcí SD FAIL OVER

Technologie CacheCade (vylepšeno z 11Generace)

Rozpoznává nejčastěji používaná data a průběžně je kopíruje na disky CacheCade SSD, z nichž jsou data získávána přímo namísto přístupu na pevné disky. Výsledkem je vyšší efektivita zpracovávání pracovních úloh. K stávajícímu RAID nastavenému na lokálním řadiči v serveru se dají přidat SSD, které se chovají jako READ cache.

Disky SSD PCIe Express Flash

Vysoce výkonné PCIe SSD, které fungují díky nové technologii Intel Direct I/O integrované do nejnovějších procesorů a novému způsobu propojení PCIe SSD NVMe propojeným novým typem HOT PLUG konektoru, jež bylo navrženo konsorciem vedeným společností Dell a Intel. Technologie Express Flash zvládá až 100 000 I/O operací za sekundu, což je nesrovnatelně víc než jakékoli jiné současné enterprise úložiště Flash. Jedná se o konkurenci Fusion-IO nicméně tato technologie je novější a hot plug, nezabírá tak cenné PCI-E sloty.

PCIe Flash je navíc díky nové technologii INTEL Integrated I/O velice blízko CPU ! V Nové generaci procesorů, které mají integrován řadič PCI-E v CPU. Dostáváme se tedy u PCIe Flash s latencí blízko RAM. Také technologie Data Direct I/O pomáhá ve snížení latence.

GPGPU – General Purpouse Graphical Processing Unit

Technologie poslední doby jak urychlit výpočty vyžadující masivní počet CPU. Před určitou dobou se zjistilo, že pro jisté matematické výpočty (konkrétně maticové a vektorové výpočty) je vhodné využití více CPU jader. Tato jádra byla součástí ne úplně naplno využitých grafických karet. Původně pro výpočet reálné fyziky ve hrách společnost nVIDIA vynalezla architekturu CUDA . Netrvalo dlouho a začala se tato technologie prosazovat v business aplikacích pod technologií TESLA. Jedná se v zásadě o grafické karty, které ale nejsou určeny pro hraní her, ale pro matematické výpočty. V současné  době je běžně dostupná karta s 1024 jádry !

• Servery 12. Generace jsou připraveny na integraci této technologie
• velká většina je schopna pojmout karty od 75-300W příkonu !
• Servery jsou tak vhodné jako výpočetní clustery pro HPC

Společnost INTEL neusíná na vavřínech a zakomponovala odpověď na nVIDIA CUDA technologii, která je součástí 12. Generace :

• Nové instrukce CPU zaměřené na pomoc při HPC a podobně. Ano je třeba mít aplikaci připravenu pro tyto výpočty, aby z nich brala benefit, nicméně situace není jiná oproti CUDA výpočtům.

Fresh Air

To co zaujme většinu zákazníků když s nimi mluvím o našich serverech je naše nedávná aktivita kterou nazýváme Fresh Air.

O co jde ?

• Jednoduše jde o to, že jsme vyladili všechny komponenty IT zařízení (nejedná se pouze o servery ! máme Fresh Air cetified i storage, switche a UPS)
• Standardní IT zařízení mají pracovní teplotu v rozmezí 10-35 stupňů celsia. Většina datových center je chlazena na 18-22 stupňů.
• Představte si, že výrobce vybere nejlepší součástky ze všech. Udělá design, který dovoluje výborné proudění vzduchu, vše je připraveno na nejlepší odvod tepla.
• Výrobce potom převezme na sebe zodpovědnost případných poruch a zvýší dovolenou teplotu až o 10 stupňů !
• TO JE FRESH AIR !
• Co to znamená ? Zákazník může vytvořit datové centrum nové generace, které umožňuje fungovat bez klimatizace ! ANO  -  čtete správně ! Klimatizace, která spotřebuje většinou skoro to samé co IT technika samotná již není potřeba !
• Nicméně,  pokud nemáte možnost vybudovat datové centrum nové generace, tak stále můžete benefitovat :
  • Pokud máte v datovém centru pouze jednu klimatizaci,  tak vám tato technologie dá čas navíc pro řešení krizové situace.
  • Pokud máte redundantní klimatizované jednotky, tak vám tato technologie umožní zvýšit vstupní teplotu o několik stupňů a tím dramaticky zvednout efektivitu vašeho datového centra a snížit náklady na chlazení !

Přehled Serverů 12té Generace 1. Vlna :

 

Další články na téma 12. Generace serverů budou následovat …

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 !

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

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

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.

Číst dál: Co to je Automatický Storage Tiering