Optimalizované IT - portál pro IT pro komunitu

Jak zjistit hodnoty pro správný výběr diskového pole ? DPACK

Vytisknout E-mail

Ondřej Bačina Datum zveřejnění: 25. 4. 2013 7:42 Zobrazeno: 3821
Jak zjistit hodnoty pro správný výběr diskového pole ? DPACK - 5.0 out of 5 based on 2 votes
1 1 1 1 1 1 1 1 1 1 Rating 5.00 (2 Votes)

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

clip_image002

Přidání VMware vCenter:

clip_image004

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

clip_image006

clip_image008

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

clip_image010

Aplikace se zeptá na kontaktní údaje:

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

clip_image012

 

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: Tato e-mailová adresa je chráněna před spamboty. Pro její zobrazení musíte mít povolen Javascript.">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 :

image

image

image

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

Migrace dat : jak a proč

Vytisknout E-mail

Ondřej Bačina Datum zveřejnění: 10. 3. 2013 7:13 Zobrazeno: 5297
Migrace dat : jak a proč - 4.7 out of 5 based on 6 votes
1 1 1 1 1 1 1 1 1 1 Rating 4.67 (6 Votes)

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.

image

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.

image

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.

image

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.

image

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

image

 

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.

image

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

image

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.

image

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.

image 

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.

image

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.

image

 

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.

Storage pro SMB

Vytisknout E-mail

Ondřej Bačina Datum zveřejnění: 22. 1. 2013 12:36 Zobrazeno: 3641
Storage pro SMB - 5.0 out of 5 based on 3 votes
1 1 1 1 1 1 1 1 1 1 Rating 5.00 (3 Votes)

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)

image

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)

image

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í :

image

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 ?

clip_image008

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 !

image

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

Storage – Jak se segmentuje?

Vytisknout E-mail

Ondřej Bačina Datum zveřejnění: 15. 11. 2011 9:33 Zobrazeno: 4253
Storage – Jak se segmentuje? - 5.0 out of 5 based on 1 vote
1 1 1 1 1 1 1 1 1 1 Rating 5.00 (1 Vote)

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

image

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

web : www.dell.com/powervault

EqualLogic

image

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

web : www.equallogic.com

Compellent

image

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

web : www.compellent.com

Snapshoty - způsob jak posunout zálohování a obnovu dále

Vytisknout E-mail

Ondřej Bačina Datum zveřejnění: 2. 11. 2011 10:58 Zobrazeno: 6173
Snapshoty - způsob jak posunout zálohování a obnovu dále - 5.0 out of 5 based on 2 votes
1 1 1 1 1 1 1 1 1 1 Rating 3.50 (3 Votes)

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

image

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

Co to je Automatický Storage Tiering

Vytisknout E-mail

Ondřej Bačina Datum zveřejnění: 18. 10. 2011 10:38 Zobrazeno: 5315
Co to je Automatický Storage Tiering - 4.5 out of 5 based on 2 votes
1 1 1 1 1 1 1 1 1 1 Rating 4.50 (2 Votes)

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

Přihlašovací formulář