Portál AbcLinuxu, 26. dubna 2024 09:44
Síťová úložná zařízení. Co je NetApp a k čemu slouží? Deduplikace, virtualizace, vysoká dostupnost, replikace a zálohování na pomalých sítích. Popis funkcí, které NetApp nabízí. Srovnání souborového systému, který tato zařízení používají, s filesystémem ZFS.
Společnost Network Appliance vyrábí zařízení, kterým se zkráceně říká NetApp nebo Toastery :-). Většinou se tímto slovem označují zařízení FAS (NetApp Fabric-Attached Storage). Každý takový FAS je tzv. filer, no a filer si můžeme představit jako víceméně obyčejné PC, ve kterém jsou nějaká rozhraní (ethernet, FC, sériová linka, …), nějaká baterií zálohovaná NVRAM a nějaký operační systém, kterému se říká Data ONTAP (současná verze je 7.3.2, ale ONTAP 8 by měl být brzy na světě také).
Co že je na tom teda tak zvláštního? Nic moc, prostě je to storage box, jenž kombinuje vlastnosti zařízení SAN a NAS spolu s docela chytrým filesystémem, který nabízí takové chuťovky, jako jsou snapshoty, klony (což není nic jiného než zapisovatelný snapshot), deduplikaci… Tento filesystém se nazývá WAFL a pokud se nepletu, byl to jeden z prvních filesystémů, který kombinoval vlastnosti správce oddílů a souborového systému [volume manageru a filesystému] tak, jak to dělá například ZFS nebo BTRFS.
Co přesně tedy nabízí WAFL? Jak jsem již zmínil, jedná se o kombinaci správce oddílů a souborového systému, takže máte nějaké agregáty, což je v podstatě kombinace RAID skupin… Pojďme se na chvilku zastavit u RAID, protože NetApp filer nabízí 2 různé druhy RAID. Jeden je tzv. RAID-DP (NetApp white paper), druhý RAID 4. Při použití RAID-DP máte odolnost proti výpadku až 2 disků, při použití RAID 4 může vypadnout jen jeden disk v jedné RAID skupině. Ale jak už to u úložných systémů připravených pro podnikové nasazení [enterprise ready storage systémů] bývá, většinou je po havárii disku ihned k dispozici nějaký záložní disk, jenž může automaticky převzít místo toho, který selhal, a začne tak fáze rekonstrukce dat na tento záložní disk.
Na každém agregátu se vytvářejí takzvané FlexVolume. Nejedná se o nic jiného než o logický oddíl rozprostřený po fyzických discích. FlexVolume může být zvětšován a zmenšován víceméně dle libosti, dokud stačí velikost agregátu. V Data ONTAP 7 může být agregát velký pouze 16 TB, stejná je i tedy velikost největšího možného oddílu. Tento limit je rozšířen v Data ONTAP verze 8, a to až na 100 TB (NetApp white paper) v závislosti na tom, jaký máte filer.
Nad každým oddílem může stát další logický prvek, kterému se říká QTree. Ten z hlediska klientů vypadá jako běžný adresář, z hlediska filesystému se jedná o něco trošku víc, protože pro každý QTree můžete definovat například nějaké limity (velikost, masku pro jména souborů – pokusit se tak uživatelům zabránit v tom, aby si na firemní storage servery ukládali multimediální obsah nebo potenciálně nebezpečné spustitelné soubory), případně můžete pro každý takový QTree vytvořit Snapshot, relaci SnapMirror (Snapshot a SnapMirror vysvětlím později), změnit bezpečnostní styl [security style] (unix, NTFS, mixed – jedná se o to, jaká oprávnění budou k dispozici na takto exportovaném oddílu/QTree; ve skutečnosti má každý oddíl root QTree, takže lze říci, že se všechny tyhle operace odehrávají na úrovni QTree, přestože to není vždy patrné).
Módní trend současnosti je deduplikace. Co to vlastně je? Soubory uložené na WAFL filesystému jdou rozdělené do bloků po 4 kB a WAFL v sobě obsahuje deduplikaci právě na úrovni těchto bloků. Deduplikace v podstatě znamená, že pokud máte na disku dva stejné soubory (respektive zmiňované bloky), tak je ve skutečnosti na disk uložen blok jen jeden a pro druhý existují jen metadata. Z toho plyne nějaká úspora nákladů na ukládání dat. Deduplikace byla nedávnou uvedena i ve filesystému ZFS [zdroj]. Filesystém ZFS nabízí deduplikaci založenou jak na porovnání samotných bloků bit po bitu, tak na stejném kontrolním HASH součtu.
Oproti tomu WAFL vždy pracuje na principu srovnání jednotlivých bloků. Je to tak zejména z důvodu, že po zakoupení licence SnapLock nebo SnapLock Enterprise můžete vytvářet tzv. WORM volumes (Write Once Read Many [zapište jednou, čtěte mnohokrát]) a legislativní požadavky vyžadují, aby deduplikace fungovala na tomto principu a neopírala se o pravděpodobnost kolize HASH. Stejně jako jsou data deduplikována na discích, dochází k deduplikaci i v samotné NVRAM, což podle NetAppu snižuje výkonový dopad. Já neměl to štěstí se setkat s použitím NetApp filerů v aplikaci, kde by na výkonu zase tolik sešlo.
Kolik deduplikace ušetří na úložném řešení? Těžko říct, liší se to nasazení od nasazení. Úspory budou větší ve virtualizovaném prostředí, kde máte hromadu VMWare image disků na NetAppu se stejným operačním systémem a velice podobným aplikačním setem, mnohem menší budou v nevirtualizovaném prostředí, kde je většina vašich dat unikátních. Pokud nad nasazením deduplikace uvažujete, je určitě rozumné si udělat mirror vašeho fileserveru někam bokem a otestovat si přínos deduplikace třeba s novým ZFS, případně provést podrobnou analýzu dat nějakým jiným způsobem.
Thin Provisioning je technologie, která je určena k lepšímu využití dostupných úložných kapacit. Její princip spočívá v tom, že je k dispozici nějaký úložný prostor [storage pool] (v našem případě označován jako agregát), který se skládá z fyzických disků a obsahuje logické prvky – oddíly. S oddíly můžete – co se kapacity týče – manipulovat dle libosti, můžete je zvětšovat, či zmenšovat.
Pokud je ve společnosti nasazována nějaká nová obchodní aplikace, většinou přijde požadavek úložnému týmu, v němž si patřičná skupina vyžádá nějaký NFS oddíl, iSCSI/FC LUN o nějaké kapacitě. Zaměstnanci společnosti mají tendenci své požadavky nadsazovat. Pokud je reálný odhad pro potřebnou kapacitu 500 GB, lidé zodpovědní za aplikaci si objednají zhruba o 50 % více, tedy 750 GB – jen pro jistotu, aby člověka z úložného týmu nemuseli za chvilku zase otravovat s tím, že potřebují více místa. Stejně tak úložný specialista nechce, aby ho někdo pořád vyrušoval při hraní Farmville na Facebooku, a proto navýší původní požadavek o 50 % jen pro případ. Pokud je alokována nějaká produkční kapacita, pak se musí adekvátně naalokovat i kapacita zálohovací, která bývá několikanásobkem původní alokované storage kapacity. V konečném důsledku dojdete do situace, kdy je na storage systému naalokováno nějaké místo, ale ve skutečnosti se využívá jen jeho zlomek.
Thin Provisioning slouží k tomu, aby pro každý objekt (Volume, LUN) nebylo nutné mít velkou rezervu v podobě volného místa, ale jen v řádu několika procent (5-10). Zbytek volného místa je sdílen napříč celým agregátem, případně není vůbec k dispozici. To není problém, protože v systémech, které podporují Thin Provisioning, je možné oddíl kdykoli zvětšovat bez nutnosti odstávky služby, a to během několika sekund. Případně se dá zapnout tzv. auto grow, což znamená, že ve chvíli, kdy začne na nějakém oddílu docházet místo, systém se sám pokusí jeho velikost zvětšit – a pokud je na agregátu volné místo, tak se to povede.
Daveův blog o thin provisioningu i s pěkným vtipem.
Moderní úložné systémy nabízejí zálohování pomocí snapshotů. Podobnou funkcionalitu nabízí ZFS, LVM2 i Btrfs. Snapshoty samy o sobě však nelze považovat za zálohu, jako takové chrání jen proti chybě uživatele či aplikace (když si uživatel/rozbitá aplikace smaže nebo poškodí datový soubor). Ochranu v případě selhání hardwaru nebo pro případ havárie snapshoty samotné neposkytují. Od toho je k dispozici technologie SnapVault, která určuje tzv. primární a sekundární úložiště [primary a secondary storage]. Snapshoty jsou vytvářeny jak na primárním, tak na sekundárním úložišti. Sekundární úložiště je vzdálené úložné zařízení, které poskytuje ochranu pro případ selhání nebo havárie hardwaru. Počty primárních a sekundárních snapshotů se mohou lišit. Na primárním úložišti můžete mít zálohy za první týden (pro případ rychlé obnovy; uživatelé mohou velice jednoduše obnovovat soubory z primárního úložiště sami pomocí Windows funkce „Previous versions“, případně otevřít skrytý adresář .snapshot přes NFS nebo ~snapshot přes CIFS).
V případě sekundárního úložiště je situace komplikovanější a žádost o obnovu musí většinou provádět někdo, kdo má alespoň obecnou představu o tom, jak úložný systém a SnapVault funguje. Ale konkrétní situace bude silně záviset na síťové topologii, řízení oprávnění a podobně. Nicméně si myslím, že ve většině běžných prostředí bude v případě obnovy dat ze sekundárního úložiště potřeba použít řádkového příkazu ndmpcopy nebo snapvault restore (pokud chcete vrátit zpět v čase celý oddíl nebo QTree).
V některých aplikacích nejsou zálohy pomocí snapshotů dostatečné a je potřeba ještě navíc zálohovat na pásky; k tomu slouží protokol NDMP. Tento protokol je navržen k zálohování systémů NAS bez potřeby transportu dat přes záložní server, čímž dochází ke zvýšení rychlosti zálohy a snížení zatížení záložního serveru. Tento protokol byl vyvinut v kooperaci mezi společnostmi Legato a NetApp. NDMP je v současné době široce podporován napříč zálohovacím softwarem i NAS produkty.
V prostředí s více zákazníky je důležité oddělit jednotlivé zákazníky a zabránit jednomu zákazníkovi v přístupu k datům zákazníka jiného. Případně mohou mít jednotliví zákazníci jiné požadavky na konfigurační parametry. Přesně k tomuto slouží koncept takzvaných virtuálních filerů (vFilerů), který se vám zpřístupní po zakoupení licence Multistore. Jednotlivé vFilery můžete migrovat napříč filery dle libosti s minimální dobou odstávky služby, což můžete využít v případě, kdy je nutné provést údržbu některého z vašich filerů. Stejně tak můžete vFilery nakonfigurovat na vysokou dostupnost a použít je jako řešení při obnově po havárii [disaster recovery].
Koncept je poměrně jednoduchý. Každý fyzický filer se skládá z jednoho vFileru, který se jmenuje vfiler0, a tento může hostovat další virtuální filery. vFiler má nějaké jméno, alespoň jednu IP adresu a minimálně jeden oddíl, může však mít více IP adres i oddílů. Nevím přesně, jaká virtualizační technologie se pro Multistore používá, nicméně funguje to poměrně spolehlivě. Jednotlivé vFilery mohou být v různých IP prostorech (různých virtuálních/fyzických LAN) a mohou používat stejnou IP adresu. Každý oddíl však může být vlastněn jen jedním virtuálním filerem.
Koncept vFilerů oceníte, převážně pokud poskytujete úložný prostor jako službu [storage as a service] pro externí zákazníky nebo operujete ve velkém firemním prostředí, kde můžete mít NAS oddělen pro jednotlivá oddělení v rámci firmy. Každý vFiler může být připojen k jinému doménovému řadiči, mít jiné lokální uživatele. Například můžete mít jednoho administrátora úložného řešení pro celý filer a pak různé administrátory pro jednotlivé virtuální filery. Změna konfigurace jednoho virtuálního fileru nemění nastavení ostatních virtuálních filerů, ani hostujícího fileru. Samozřejmě v kontextu virtuálních filerů nejsou dostupné všechny příkazy, například nelze vytvářet IP prostor nebo měnit velikosti jednotlivých oddílů, které jsou přiřazeny k danému fileru. (O oddílech, které nejsou vlastněné virtuálním filerem, nemáte ani možnost se dozvědět, že existují.)
V prostředí velké společnosti se řeší různé problémy ohledně spolehlivosti IT systémů. Pro zvýšení spolehlivosti nabízí NetApp tzv. konfiguraci Active/Active nebo řešení, které se nazývá MetroCluster. Konfigurace Active/Active slouží k obnově po havárii v případě, že dojde k výpadku jednoho úložného řadiče [storage controller]. V takovém případě je druhý řadič v konfiguraci Active/Active schopen během několika desítek sekund (10-20 s) převzít kontrolu nad disky, které byly připojeny k původnímu fileru, a nastartovat vfiler0 původního fileru jako virtuální filer. Zásadním limitem tohoto řešení je geografická lokace, oba řadiče musí být poměrně blízko sobě, nejlépe ve stejném nebo vedlejším racku.
Pro případ, že potřebujete trošku vyšší spolehlivost a chcete být pojištěni i pro případ katastrofy, jako je výpadek celého datacentra, můžete svěřit svá data řešení, které se nazývá MetroCluster. Pokud má vaše společnost dvě datacentra nebo jedno primární a druhé pro obnovení po havárii ve vzdálenosti do 200 km, pak můžete využít technologii MetroCluster k zabezpečení „Business Critical“ aplikací. Jediným požadavkem je existence sítě Fibre Channel mezi těmito datacentry. Princip MetroClusteru je v tom, že každý zápis, který jde do NVRAM, je přes síť Fibre Channel přenesen i do NVRAM k druhému nodu MetroClusteru a data jsou tak k dispozici na discích, které jsou připojeny k druhému fileru. Nejedná se však jen o hloupé řešení pro obnovu po havárii; druhý filer můžete klidně využívat jako úložný systém, jen musíte počítat s tím, že pokud je vaše potřebná úložná kapacita pro aplikace 20 TB (10 TB v každém datacentru), pak musíte MetroCluster vybavit 40 TB diskového prostoru (20 TB v každém datacentru), protože ve druhém umístění je nutné mít kopii primárních dat.
V případě, že dojde k výpadku jednoho z filerů, systém se zachová stejně jako běžná konfigurace Active/Active a zbývající filer převezme úlohu toho chybějícího. Výborné řešení vysoké dostupnosti [high availability] se dá vybudovat v případě, že MetroCluster zkombinujete například s VMWare nebo používáte jiné služby po NFS.
Poznámka: Bezvýpadkové řešení by mělo být k dispozici i pro protokol SMB ve verzi 2.0 (2.1), nicméně s tímto nemám žádné zkušenosti z praktického nasazení, takže nemohu posoudit, jak je to v praxi (zdroj).
Legislativa v dnešní době u některých aplikacích vyžaduje, aby bylo u určitých dokumentů bylo zajištěno, že nebyly v průběhu času nikterak změněny. K tomu, abyste tyto legislativní požadavky splnili, musíte použít nějaké řešení, které podporuje funkci WORM, což je například NetApp s licencí SnapLock nebo SnapLock Enterprise. V případě diskových polí NetApp se nejedná o WORM z jejich fyzického principu, ale software vám neumožní po nastavenou retenční dobu uložené soubory smazat či přepsat. Základní licence SnapLock je určena ke splnění požadavků, které na společnosti klade legislativa, proto není možné zapsané soubory měnit či mazat, stejně jako smazat celé již vytvořené oddíly.
Naopak SnapLock Enterprise je určen k dodržení vnitrofiremních požadavků, proto je zde možnost v případě potřeby odstranit celý WORM oddíl, ale nikoli měnit či mazat data, která byla na WORM oddílu uloženy. V případě použití softwaru SnapLock můžete vytvořit různé oddíly s různým retenčním časem podle vašich potřeb.
SnapMirror je software určený k replikaci oddílů nebo QTree napříč sítí mezi jednotlivými filery. Pokud například nemáte vysoce dostupné řešení a stejně potřebujete ve společnosti udělat na vašem úložném systému nějakou údržbu, můžete SnapMirror použít k replikaci všech potřebných dat na jiný filer, který máte k dispozici, nastavit na cílovém fileru potřebné služby a poté přepnout samotnou službu na cílový filer, zatímco můžete na původním fileru provést veškerou potřebnou údržbu. SnapMirror je například používán, pokud se rozhodnete zmigrovat vFiler napříč filery za použití funkce vfiler migrate. SnapMirror je, jak již název napovídá, založen na vytváření snapshotů. V případě, že inicializujete relaci SnapMirror, tak se vytvoří pracovní snapshot a všechno starší, než je tento snapshot, se zreplikuje na cílový filer (včetně všech starších snapshotů). Pokud v budoucnu usoudíte, že je na čase kopii SnapMirror aktualizovat a spustíte snapmirror update, tak se vytvoří nový snapshot a přenesou se všechny změny oproti předchozímu snapshotu.
S pomocí této technologie můžete čas odstávky zkrátit z několika hodin na pár minut. Původní baseline přenos dat se může provést přímo za chodu, po jeho dokončení můžete ještě spustit pravidelný snapmirror update a pak v průběhu odstávky provést finální snapmirror update, rozbít relaci SnapMirror, obnovit provoz služby na druhém fileru a provádět cokoli se vám zlíbí s primárním filerem.
Další možnost je použít SnapMirror jako chudou náhradu za SnapVault. Jak už to v korporátním světě bývá, licence nejsou zadarmo, naopak stojí docela hodně peněz a rozpočet vám ne vždy dovoluje pořídit to nejlepší, a tak musíte hledat nějaké cestičky, jak dosáhnout toho, co chcete, za peníze, které máte k dispozici. V případě, že je licence pro SnapVault moc drahá a nebo do ní nechcete investovat z nějakého jiného důvodu, můžete použít SnapMirror k přenosu dat mezi vaším primárním a sekundárním filerem a na sekundárním fileru pak používat lokální snapshoty, jejichž podpora je zaplacena již v základní licenci.
Nejzajímavější věcí na každé hračce, ať již se jedná o soukromé zařízení, nebo drahý korporátní hardware, jsou zajisté různé skryté režimy, easter eggs a vůbec to, co není patrné na první pohled. Člověk je od přírody tvor zvídavý, a proto si rád hraje s věcmi, které nejsou zdokumentované a na první pohled viditelné. Pro lidi, kteří rádi zkoumají neprozkoumané, jsou k dispozici minimálně dva režimy: priv set advanced a priv set diag. První zmiňovaný režim je zmíněn v dokumentaci k příkazu priv set, o existenci režimu priv set diag jsem se dozvěděl až na jednom školení, které školil zaměstnanec z Network Appliance.
Přestože o existenci advanced režimu se lze dozvědět z dokumentace, o tom, co dělají příkazy, které vám tento režim zpřístupní, se toho už tolik nedozvíte. Pokud vím, všechny tyto „advanced“ příkazy nemají žádnou veřejně přístupnou dokumentaci, a proto pokud je chcete používat, je dobré si pořídit simulátor Data ONTAP a vyzkoušet si je nejdříve mimo produkční prostředí. Pokud s nimi cokoli pokazíte, můžete totiž nadávat jen a jen sobě. Mezi zpřístupněné příkazy v advanced režimu patří například velice nebezpečné příkazy ls nebo rm, které dělají přesně to, co si pravděpodobně myslíte, že dělají… Nicméně ke zmiňovanému příkazu rm žádné parametry -rf prostě nepřidáte (možná jo, ale nevím jak, dokumentace není, já to zkoušel a jednoduchým rm -rf jsem se k cíli nedostal.
toaster> priv set advanced
Warning: These advanced commands are potentially dangerous; use
them only when directed to do so by Network Appliance
personnel.
toaster*> rm -rf /vol/007_test_marek/adresar
-rf: Invalid argument
/vol/007_test_marek/adresar: Is a directory
toaster*>
toaster*> priv set diag
Warning: These diagnostic commands are for use by Network Appliance
personnel only.
toaster*> rm -rf /vol/007_test_marek/adresar
-rf: Invalid argument
/vol/007_test_marek/adresar: Is a directory
toaster*> priv set
toaster>
Doba je zlá, informací je mnoho, jejich cena narůstá a ne vždy je možné mít všechny důležité informace v nějakém centralizovaném datacentru, kde lze pohodlně zálohovat na pásky a přenášet každý týden všechna data po záložní síti. Občas se stane, že je potřeba nasadit zálohování na serverech, které jsou přímo v sídle společnosti [on-site]. V takovém případě společnost řeší, zda je pro ni výhodnější pořídit nějakou páskovou knihovnu/mechaniku a člověka, který bude schopen se o tento hardware starat, nebo nasadit virtuální páskovou knihovnu. V případě, že má společnost k dispozici NetApp, může ještě zvážit použití technologie OSSV a zálohovat do svého centralizovaného datacentra i své on-site servery.
V případě použití OSSV je potřeba přenést základní zálohu a dále probíhá inkrementální zálohování na úrovni jednotlivých datových bloků o velikosti 4 kB. Největší problém je v tomto případě provedení základní zálohy. Pokud je vzdálená kancelář na opravdu tak pomalé lince, že nelze provést základní zálohu po síti ani během například víkendu, pak je nutné vyslat někoho s dostatečnými znalostmi na místo, provést základní zálohu na externí médium (NetApp FAS250 by mohl být dobrá volba, ale můžete klidně použít externí USB disk) a dopravit ji zpět do datového centra, kde je možné data přesunout na cílový NetApp a dále pokračovat v přenosu změněných bloků podle potřeby. Tento postup je označován zkratkou LREP – Logical Replication for Seeding Baselines.
Protože však mezi zálohovaným serverem a cílovým úložným systémem zpravidla chybí nějaká rychlá linka, je zde problém s obnovou po havárii nebo rychlou obnovou velkých souborů. Vše je to samozřejmě jako vždy o síti, případně o rychlosti zásilkové společnosti/administrátora na dálnici v případě, že se rozhodnete provést obnovu/disaster recovery tzv. kabelovou metodou.
Stojí to peníze, hodně peněz, jak jednou jeden člověk poznamenal…
Cos čekal, že to bude za kabelu hrušek?
V závislosti na konfiguraci, kterou požadujete, se můžete ocitnout na ceně 15 000 eur za ne-HA řešení (jen jedna hlava, žádné Active/Active). Pokud si však myslíte na MetroCluster, připravte si v peněžence víc než 500 000 eur a nezapomeňte na cenu SAN mezi oběma datacentry. Kdybyste se však na základě tohoto článku opravdu rozhodli si nějaký ten NetApp koupit, nezapomeňte svému dodavateli říct, ať mi pošle alespoň tričko :-)
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.