Pozn.: Tento článek navazuje na starší NetApp AFF8040 - konfigurace, principy a základní postupy, který se věnuje spíše základním operacím a vychází z tehdejší verze ONTAP 9.1. Nejprve jsem se jej snažil trochu aktualizovat, ale nakonec jsem se rozhodl rozdělit do samostatných článků. Když jsem zprovozňoval nové pole NetApp AFF A250, tak jsem musel nastudovat řadu základních principů ONTAP. Tomu se věnuje tento článek.
Pozn.: Článek vychází z verze ONTAP 9.9.1, která byla aktuální v době psaní. Ta přináší řadu vylepšení oproti starším (třeba 9.8). Četl jsem o chystané verzi 9.10, která přinese další zajímavé vlastnosti.
NetApp ONTAP úvod
Většina diskových polí NetApp využívá operační systém ONTAP. Správu můžeme provádět pomocí příkazové řádky ONTAP CLI nebo webového grafického rozhraní ONTAP System Manager.
Dokumentace
- ONTAP 9 Documentation
- ONTAP & OnCommand System Manager Resources
- NetApp Knowledge Base
- ONTAP OS - NetApp Knowledge Base
- ONTAP 9 Documentation Center - CLI
- FlackBox NetApp Tutorials
NetApp diskové pole
Diskové pole (Storage Array) je tvořeno jako Cluster, který se se skládá ze dvou uzlů (Cluster Nodes) a ty mohou být dále seskupovány. Ty jsou konfigurovány jako vysoce dostupný pár (High Availability (HA) Pair), který poskytuje odolnost proti chybám (Fault Tolerance) a možnost bezvýpadkové údržby.
Uzel je představován kontrolérem (Storage Controller), jeho úložištěm, síťovou konektivitou a běžícím ONTAP systémem. Součástí kontroléru je Service Processor (SP) pro vzdálenou správu a dohled. Ten má přiřazenu IP adresu. Pro správu clusteru se využívá cluster VIP adresa a každý uzel má svoji management IP.
Přístup k datům
K datům na poli je možno přistupovat různým způsobem
- blokový přístup - klienti (Hosts - servery) jsou připojeni do SAN (Storage Area Network) sítě a pomocí protokolů Internet Small Computer System Interface (iSCSI) nebo Fibre Channel over Ethernet (FCoE) v Ethernetu nebo Fibre Channel Protocol (FCP) či Non-Volatile Memory Express over Fibre Channel (NVMe/FC) v FC přistupují k LUNům
- souborový přístup - NAS (Network Attached Storage) přístup pomocí protokolů Common Internet File Services / Server Message Block (CIFS/SMB) nebo Network File System (NFS) k souborům
- objektový přístup (Object Storage) - data se ukládají jako objekty organizované do kbelíků (buckets), pro přístup se využívá Amazon S3 rozhraní
Základní termíny SAN sítí
Více informací nalezneme v článku Storage technologie a SAN sítě aneb připojení serverů k diskovému poli.
- Initiator - klient, který se připojuje k LUNu, vyjednává připojení s Target
- Target - cílová adresa diskového pole, přes kterou se Initiator připojuje k LUNu
- Initiator Group (iGroup) - určuje, který host může přistupovat k určitému LUNu na úložišti, na poli nám reprezentuje klienta (server)
- IQN -iSCSI Qualified Name - unikátní iSCSI identifikátor Initiatoru nebo Targetu, příklad
iqn.1991-05.com.microsoft:server.firma.local
Virtualizace - Storage virtualization - SVM
- Storage - Storage VMs
ONTAP umožňuje rozdělit pole na virtuální části, které se tváří jako samostatné pole a toto virtuální pole můžeme přidělit nějakému subjektu včetně samostatné správy.
Využívá se Storage Virtual Machine (Storage VM - SVM), dříve označované vServer. SVM jsou logické entity, které abstrahují fyzické zdroje. I když celé pole využíváme sami a nepotřebujeme je dělit, tak se musí vytvářet SVM pro poskytování dat klientům určitým protokolem. SVM poskytuje data z jednoho nebo více svazků (Volume) skrze jeden nebo více LIF. Nezáleží na umístění Volume v clusteru (na libovolném agregátu), ani na hostování LIF na určitém portu. Můžeme přesouvat Volume i LIF za provoz bez přerušení služby.
Každé SVM má svůj jmenný prostor (Namespace), což je adresářová struktura. Když vytvoříme datové SVM, tak se vytvoří kořenový svazek (Root Volume), kde se ukládá kořen Namespace. Ostatní svazky v SVM jsou vzájemně propojeny prostřednictvím spojů (junctions).
Mimo datových SMV existují také speciální systémové typy, které se vytvoří automaticky (GUI je nezobrazuje).
- Admin SVM - cluster management server, representuje cluster jako jednu spravovatelnou jednotku
- Node SVM - reprezentuje individuální uzel clusteru
- System SVM (advanced) - slouží pro komunikaci clusteru v IPspace
- Data SVM - poskytuje data, musíme vytvořit a přidat svazky, abychom umožnili přístup k datům
Síťová architektura (Network Architecture)
ONTAP využívá tři sítě, jde o:
- komunikaci clusteru (cluster interconnect)
- správu (management network for cluster administration)
- data (data network)
Fyzické a logické porty
- Network - Ethernet Ports
NIC (network interface cards) poskytuje fyzické porty pro Ethernet připojení. HBA (host bus adapters) poskytuje fyzické porty pro Fibre Channel připojení. K fyzickým portům můžeme vytvářet logické porty. Link Aggregation Group (Interface Group) je seskupení více fyzických portů do jednoho logického pro větší dostupnost (PortChannel). VLAN rozdělení komunikace na portu do logických segmentů.
LIF - Logical Interface
- Network - Overview
Důležitý termín je Logical Interface (LIF), v GUI je označeno jako Network Interface. Na logické rozhraní přiřazujeme IP adresu pro Ethernet nebo World Wide Port Name (WWPN) pro Fibre Channel. To umožňuje větší flexibilitu, než kdyby byla adresa nastavena přímo na fyzický port. V rámci Failover nebo údržby může docházet k bezvýpadkové migraci LIF na jiný fyzický port, který může být na jiném nodu.
LIF přiřazujeme na fyzický port, VLAN nebo Interface Group a ke stejnému portu jich může být přiřazeno více. Jsou vyhrazeny pro jedno konkrétní SVM. LIF běží na přiřazeném uzlu (Home Node) a portu (Home Port), při migraci se může přesunout na jiný port v rámci Failover Group. Pro LIF se nastavuje Service Policy, která určuje jeho chování. Failover Policy, která definuje možnosti přepnutí při selhání (třeba pouze porty na stejném uzlu nebo naopak na jiném). Failover Group, která určuje možné porty pro přesun.
ONTAP automaticky vytváří Failover Group pro každou Broadcast Domain. Do té patří porty ve stejné L2 síti a ty se využijí pro Failover. V případě potřeby je možno vytvořit ručně.
Path Failover funguje jinak pro NAS a pro SAN. NAS LIF automaticky migruje na jiný port při selhání linky. SAN LIF nemigruje (můžeme přesunout manuálně), protože se počítá s technologií Multipath na klientovi, která odkloní provoz na jiný port.
Typy LIF
- Node Management LIF - každý uzel má svůj LIF pro správu, neopouští node
- Cluster Management LIF - pro správu celého clusteru, přesouvá se mezi uzly
- Cluster LIF - pro provoz mezi uzly v clusteru, jsou přiřazeny na fyzické porty cluster interconnect
- Data LIF - poskytuje klientský přístup pomocí SAN a NAS protokolů
- Intercluster LIF - pro SnapMirror a SnapVault replikace
Pozn.: Speciální výjimka je IP adresa pro Service Processor. Ta se nenastavuje jako LIF, ale přímo na zařízení. Cluster - Overview - vedle daného uzlu klikneme na tři tečky a Edit Service Processor.
IPspaces - adresní prostory
- Network - Overview
IPspaces umožňuje rozdělit diskové pole pro více organizací, které mohou využívat stejné IP adresy. Pro jednu organizaci se doporučuje využívat pouze jeden IPspace. Storage VM (SVM) se zařazuje do jednoho IPspace (nelze přesunout) a udržuje vlastní routovací tabulku (podobně jako VRF). Neprobíhá žádné směrování cross-SVM nebo cross-IPspace. Pro každý IPspace se vytváří systémové SVM. Jinak řečeno, IPspaces dovolují různým SVM na stejném clusteru používat stejné (překrývající se) IP adresy.
Automaticky je vytvořen IPspace Cluster, kam jsou zařazeny cluster porty a probíhá komunikace nodů (internal private cluster network). A Default pro vše ostatní, je zde i správa pole a nodů. Pro většinu případů si v praxi vystačíme s tímto.
Broadcast Domains
- Network - Overview
Broadcast Domains slouží k seskupování síťových portů, které patří do stejné L2 sítě (mohou spolu komunikovat po L2). Porty ve skupině používá SVM pro datový provoz nebo správu (nebo cluster). Broadcast Domain je zařazena do určitého IPspace. Port v Broadcast Domain (může být zařazen pouze do jedné) používá LIF. Automaticky je vytvořena Broadcast Domain Cluster a Default, případně se vytváří další Default-1, atd.
Broadcast Domains spolupracují s Failover Groups a Subnets (umožňuje, řídí a zabezpečuje chování LIF Failover). ONTAP automaticky vytváří Failover Group pro každou Broadcast Domain. To zajistí, že v případě migrace LIF na jiný fyzický port, jde o port ze stejné sítě a klienti mají stále konektivitu.
Subnets
Subnety můžeme volitelně použít pro alokaci bloku IP adres a automatické přidělování k LIF. Subnet se vytváří uvnitř Broadcast Domain, určujeme adresu brány, subnet a rozsah dostupných adres. Vytvořit můžeme pouze v CLI. Když pak vytváříme LIF, tak nemusíme zadat manuálně, ale automaticky se přidělí další dostupná adresa ze Subnetu.
Konfigurace nového pole
Pokud máme nové pole bez konfigurace, tak můžeme řadu věcí nechat nastavit automaticky pomocí ONTAP System Manager. Po úvodní inicializaci, kde nastavíme IP adresy, admin heslo, DNS a NTP, máme na Dashboard různé průvodce. Můžeme použít Prepare Storage, což nám má optimálně nastavit disky, vytvořit RAID Groupy a agregáty. Je zde i průvodce pro Configure Protocols, což je vlastně vytvoření Storage VM. SVM vytváří také LIF, ale často si musíme dopředu ručně připravit. Za určitých situací se automaticky vytváří nové Broadcast Domains.
Než se pustíme do vytváření SVM, tak si musíme připravit porty. Například pokud chceme některé porty agregovat (spojit) do PortChannelu, tak vytvoříme Link Aggregation Group. Volíme porty, mód (nejlépe LACP, v GUI nejde později měnit, musí se případně smazat a znovu vytvořit) a metodu rozvažování. U iSCSI portů asi chceme nastavit MTU 9000. U jednotlivých portů vidíme nastavenou hodnotu, ale zde ji nemůžeme měnit. Nastavení se provádí na Broadcast Domains. Asi je lepší si připravit nové Broadcast Domains (pokud jde o nové sítě).
Při vytváření SVM zadáváme adresy (vytváříme) Network Interface, tedy LIF. Zadáváme IP adresu a masku, volitelně bránu. Pokud daný subnet již existuje, tak se přiřadí odpovídající Broadcast Domain. Jinak se použije defaultní. Důležité je zvolit správnou Broadcast Domains, kde máme volné porty (Home Port). K nim se vytvoří (přiřadí) LIF. Pokud port nebude zařazen do žádné Broadcast Domain, tak se nepoužije.
Architektura úložiště (Storage Architecture)
Agregát - Aggregate
- Storage - Tiers
Architektura začíná na fyzických discích, které seskupujeme do agregátů (Aggregate). To je kontejner pro disky spravované jedním uzlem clusteru. Agregáty můžete použít k izolaci úloh s různými požadavky na výkon.
Agregát je přiřazen určitému uzlu clusteru, který vlastní disky uvnitř. V případě výpadku dojde k přepnutí na druhý uzel (active-passive). K agregátu se dá přistupovat přes síťová rozhraní na obou uzlech, ale požadavky na čtení a zápis zpracovává pouze jeden. Abychom využili výkon obou kontrolerů, tak potřebujeme dva agregáty, každý přiřazený k jinému uzlu. Více níže v popisu ADPv2.
Agregát můžeme za běhu zvětšovat přidáním disků. Ale nejde jej zmenšit. Jediná možnost je přesunout všechny svazky (Volume) na jiný agregát. Původní smazat a znovu vytvořit. Přesunem svazků mezi agregáty můžeme také ladit výkon a rozkládat zátěž na jednotlivé kontroléry.
RAID - Redundant Array of Independent Disks
ONTAP podporuje tři typy RAIDu pro agregáty, záleží na použitých discích, jejich typu (NL-SAS, SAS, SSD), velikosti a počtu.
- RAID4 může použít jeden spare disk a maximálně 14 disků
- RAID-DP (Double Parity) může použít dva spare disky a celkově až 28 disků
- RAID-TEC (Triple Erasure Encoding) nový typ, podporuje tři spare disky, celkově 29 disků a je navržen pro velké SATA a SSD nad 6TB
RAID Group
Pro agregát nastavujeme použitý typ RAIDu. Uvnitř agregátu je jedna nebo více RAID Group (default rg0). Typ RAIDu na agregátu určuje, kolik je paritních disků v RAID Group (tedy proti chybě kolika disků chrání). Pro agregát také můžeme některé disky nastavit jako Spare disk. Patrně jen tak, že je necháme volné (nepoužijeme je pro vytvoření agregátu). Ručně jsem vytvářel agregát v CLI na poli s 24 disky, zadal jsem použití 23 disků a při výpisu Spare se jeden ukazuje dostupný.
Disky v RAID Group musí být stejného typu (SAS, SATA, SSD). Měly by mít stejnou velikost a rychlost. Podle typu RAIDu může RAID Group obsahovat maximální množství disků. Když se použije více disků, tak je menší režie, větší výkon, ale delší rebuild a větší možnost, že dojde k současné poruše více disků. Proto, když máme mnoho disků, tak můžeme potřebovat v agregátu vytvořit několik RAID Group.
Plex
Co se moc nepopisuje jsou Plex. To je další kontejner uvnitř agregátu, standardně máme plex0. Uvnitř Plexu je teprve RAID Group. Plex slouží pro zrcadlení (kopii dat) SyncMirror. Pokud používáme, tak máme ještě druhý plex1. Každý Plex má svoje disky (Disk Pool) a svoje RAID Group, jsou fyzicky oddělené. Data se aktualizují současně na obou Plexech, takže se zvyšuje dostupnost dat.
RAID Group ani Plex si nemůžeme vypsat samostatně. Pomocí CLI se dají zobrazit jako součást agregátu. Logicky to vypadá, že disk je uvnitř RAID Group, ta uvnitř Plexu a ten uvnitř agregátu. Ale spíše se popisuje, že disky jsou uvnitř agregátu a ostatní jsou vlastnosti či atributy agregátu.
Advanced Drive Partitioning v2 (ADPv2)
NetAPP FAS/AFF systémy využívají převážně RAID-DP (Double Parity). Kdy každá RAID Group má 2 paritní disky a může mít až 2 Spare disky. Může se skládat maximálně z 28 SSD disků. Mimo datového agregátu (Data Aggregate) potřebujeme také Root agregát (Root Aggregate), kde jsou uloženy konfigurační soubory a logy operačního systému (má stejný RAID jako datový agregát). Fyzické disky jsou softwarově přiřazeny ke kontrolérům (ownership).
Disková police běžně podporuje 24 SSD disků. Když je rozdělíme na kontroléry, tak jeden má 12 disků. Kde se vytvoří RAID-DP (2 paritní a 1 spare disk) a zbude 9 disků pro data. A to bychom měli ještě vyhradit disky pro OS (Root), takže by zůstalo mnohem méně. Proto NetApp přišel s rozdělováním disků na části - Partitioning.
ADP v1, na každém disku přiřazeném jednomu kontroléru se oddělí malá část a v ní vytvoří Root Aggregate (přes všechny tyto disky). Označuje se Root-Data Partitioning.
ADP v2 umožňuje ještě více využít disky (méně režijních). Na každém disku se vytváří tři oddíly, proto se označuje Root-Data-Data Partitioning. Pro každý kontrolér (node) máme agregát, který vlastní (stejně velkou) část na (všech) discích. Nejlépe je to patrné na obrázku od NetAppu.
Plynou z toho různé vlastnosti
- všechny disky jsou sdílené a rozdělené na části (Shared Partitioned Disks)
- datový prostor na poli nemáme jeden, ale dva, i když nové GUI ukazuje jednu celkovou (a volnou) kapacitu, tak se musíme dívat na agregáty (v GUI se nově používá termín Tiers), aby nám nedošlo místo (další složitosti do toho vnáší fyzický vs. logický prostor, trochu lepší pohled je v ONTAP 9.9.1)
- Spare disk nějakým způsobem patří k agregátu (kontroléru), i když je na obrázku bokem
- když vytváříme svazek, tak je důležité, do jakého agregátu (Tier) se umístí, od ONTAP 9.8 se v GUI nevolí, ale má automaticky vybrat nejvhodnější, případně můžeme zvolit Custom Performance Service Level a ručně určit, nebo dodatečně svazek přesunout, 10 Common Questions about Provisioning in ONTAP System Manager 9.8
- svazky můžeme přesouvat mezi agregáty za provozu (ale je to pomalé), pokud přesuneme všechny svazky, tak je možno agregát smazat
Svazek - FlexVol Volume
- Storage - Volumes
ONTAP poskytuje data klientům z logického kontejneru zvaného Flexible Volume (FlexVol). Když mluvíme o svazcích (Volume), tak jsou vždy myšleny FlexVol. Svazky se nachází uvnitř agregátu a ukládají se do nich data. V agregátů může být více svazků. Můžeme je zvětšovat a zmenšovat, přesouvat, vytvářet kopie.
Limity na svazky záleží na použitém hardwaru. Může jít třeba o 2000 svazků u menších polí, maximální velikost 100 TB. Pokud potřebujeme větší prostor pro NAS, tak můžeme využít FlexGroup svazky (nástupce za Infinite Volumes). Ty mohou přesahovat přes různé agregáty a uzly clusteru.
Svazek je něco jako oddíl (partition) z pohledu pole. Z pohledu serveru (kterému jej přidělíme) je to disk a uvnitř můžeme vytvářet oddíly (dnes se i ve světě Windows používá spíše termín Volume).
Mimo datových svazků (Data Volumes) existuje několik speciálních svazků:
- Node Root Volume - standardně
vol0, obsahuje konfigurační informace uzlu a logy - SVM Root Volume - slouží jako vstupní bod do jmenného prostoru poskytovaného SVM, obsahuje informace o Namespace Directory
- System Volume - obsahuje speciální metadata, jako auditní logy
QTree
- Storage - Qtrees
QTree můžeme (volitelně) použít pro rozdělení svazku na více spravovatelných jednotek. Spolu s nimi můžeme využít kvóty (quota) pro omezení využití zdrojů svazku. QTree můžeme vytvořit uvnitř svazku a NAS klient je vidí jako adresář. Můžeme s nimi pracovat zhruba jako se svazkem.
LUN - Logical Unit Number
- Storage - LUNs
V NAS prostředí obsahuje svazek souborový systém. V SAN prostředí jde o LUNy. LUN (Logical Unit Number) je identifikátor pro logické zařízení (Logical Unit) adresované SAN protokolem. LUNy jsou základní jednotkou pro úložiště v SAN konfiguraci. Nachází se ve svazku (nebo v QTree), kde jich může být více, ale doporučeno je jeden LUN v jednom svazku. Pokud potřebujeme ve svazku více LUNů, tak je dobré využít QTree. LUN můžeme bez výpadku přesunout do jiného svazku.
Klient (Initiator) vidí LUN jako virtuální disk z pole (Target). Z pohledu pole jde o soubor uvnitř svazku. Když serveru přiřadíme více svazků, tak každý má jiné číslo LUN. Z pohledu SCSI je LUN logické (adresovatelné) zařízení, které je součástí fyzického zařízení (Target). Maximální velikost LUNu je 16 TB (pouze v All SAN Array (ASA) konfiguraci je to 128 TB).
Pokud využíváme Snapshoty, tak musí být ve svazku dostatek místa pro LUN i pro Snapshoty. Tedy svazek musí být větší než LUN.
WAFL - Write Anywhere File Layout
WAFL je patentovaná technologie NetAppu (souborový systém), která se nachází nad RAIDem a zprostředkovává čtecí a zápisové operace. Je optimalizován pro zápis. Podporuje velká úložiště, vysoký výkon, rychlé zotavení z chyb a zvětšování prostoru. Zapisuje více operací na disk v jednom sekvenčním bodě. Data mohou být zapisována kdekoliv na disk (metadata se nemusí zapisovat na přesně dané místo).
Různá doporučení
- můžeme využít Thin Provisioning, což nám může ušetřit hodně místa, ale tím dochází k Over Provisioning (přidělíme více místa, než je dostupné), takže musíme pečlivě monitorovat zaplnění agregátu (fyzického prostoru)
- Volume by měl být větší než LUN, záleží na využívání snapshotů, ale minimálně o 5 % nebo můžeme povolit Autogrow o 10 % (Resize Automatically)
- agregát (Aggregate, případně Tier) bychom měli zaplnit jen do 80 % pro optimální fungování pole, maximum 90 %, pak již mohou nastat problémy
- je dobré sledovat (případně upravit defaultní hodnoty v CLI) zaplnění LUN, Volume, Aggregate
- je dobré využívat Active IQ Unified Manager (který můžeme zdarma instalovat on-premises) a/nebo Active IQ Online
- já jsem zvyklý využívat iSCSI, ale pro některé účely se může hodit NFS
Efektivita ukládání - Storage Efficiency
- ONTAP 9 - Storage Efficiency
- Use deduplication, data compression, and data compaction to increase storage efficiency overview
ONTAP nabízí řadu technologií, aby efektivněji využil dostupný fyzický prostor na poli (v úložišti). Všechny jsou postaveny na WAFL. Označují se jako funkce pro efektivitu úložiště (storage efficiency features). Tyto funkce pomáhají dosáhnout optimální úspory místa (převážně) na FloxVol Volume.
Primárně jde o deduplikaci, data kompresi a zhutnění dat. V novějších verzích ONTAP na AFF systémech (All Flash FAS) jsou všechny automaticky zapnuté.
Thin Provisioning
Pro Thin Provisioned svazek (Volume) nebo LUN se dopředu nerezervuje místo v úložišti. Prostor se alokuje dynamicky podle potřeby. Volný prostor je uvolňován zpět úložišti, když jsou data ve svazku nebo LUNu smazána. Pro svazek můžeme alokovat více prostoru, než je fyzicky dostupné v agregátu. A obdobně pro LUN můžeme alokovat více prostoru, než je fyzicky dostupné ve svazku.
Výhody jsou jasné. Když přidělujeme prostor (disky) serverům, tak v praxi nejsou zaplněny na sto procent, takže ten neobsazený prostor nemusíme mít. Můžeme také na začátku přidělit větší prostor, který se zaplňuje postupně, a teprve v případě potřeby rozšiřovat prostor na poli.
Thin Provisioned svazek (Volume) má nastaveno Space Guarantee na None. Prostor není garantován, může se stát, že potřebný prostor pro uložení data nebude k dispozici. Pokud svazkům přidělíme dohromady více prostoru, než je fyzicky dostupné v agregátu, tak jde o Over Provisioning. To je často z principu chtěné, ale musíme velmi dobře hlídat zaplnění agregátu. Pokud dojde prostor v LUNu, svazku nebo agregátu, tak se přepne do Offline, aby chránil data. Thin Provisioned LUN má nastaveno Space Reservation na Disabled.
Pokud používáme Thin Provisioning, tak při smazání dat v určitém systému nemusí být tato informace předána na pole, takže zde je stále obsazeno více prostoru. Můžeme provést obnovení odstraněných bloků. Informace pro VMware Reclaiming VMFS deleted blocks on Thin Provisioned LUNs (2057513).
Oproti tomu tradiční přidělování prostoru se označuje Thick Provisioning. Přidělené místo je hned rezervováno a prostor je garantován. Volný prostor, který se zobrazuje ve svazku je fyzicky dostupný. Nemůže nastat Over Provisioning.
Deduplikace - Deduplication
Deduplikace snižuje potřebné množství fyzického úložiště pro svazek (nebo všechny svazky v agregátu) vyřazením duplicitních bloků a jejich nahrazením odkazy na jeden sdílený blok. Čtení deduplikovaných dat nemá žádný dopad na výkon, zápis má zanedbatelné snížení výkonu.
WAFL během zápisu vytváří katalog podpisů bloků. Při deduplikaci se porovnávají podpisy pro identifikaci duplicitních bloků. Pokud dojde ke shodě, tak se provádí porovnání bajt po bajtu. Pouze při kompletní shodě je blok zahozen.
Můžeme využívat několik způsobů deduplikace
- Volume-Level Inline Deduplication - deduplikace probíhá při zápisu v rámci svazku
- Volume-Level Background Deduplication - postprocess deduplikace v rámci svazku nad daty uloženými na disku, pomocí politiky auto běží kontinuálně na pozadí
- Aggregate-Level Inline Deduplication - eliminuje duplicitní bloky při zápisu napříč svazky v rámci stejného agregátu (Cross-Volume Inline Deduplication)
- Aggregate-Level Background Deduplication - aktivuje se na pozadí, když dojde k dostatečné změně dat, můžeme spustit ručně v CLI
Komprese - Compression
Komprese snižuje potřebné množství fyzického úložiště pro svazek kombinací datových bloků do kompresních skupin (compression groups), z nichž každá je uložena jako jeden blok. Při čtení se dekomprimují pouze komprimované skupiny, které obsahují požadovaná data, nikoli celý soubor nebo LUN.
Může probíhat při zápisu, kdy se komprimují data v paměti (Inline Compression) nebo naplánovaně později nad daty uloženými na disku (Postprocess Compression).
Kompakce - Compaction
Kompakce, zhuštění (redukce) dat, se uplatní pro malé soubory, které by normálně zabraly celý 4 kB blok (i když jej nezaplní). Díky kompakci se kombinují datové bloky a zapíší do jediného 4 kB bloku na disku. Inline data compaction probíhá, dokud jsou data stále v paměti. Pracuje na úrovni svazku, který musí být Thin Provisioned.
FlexClone
Díky technologii FlexClone můžeme vytvořit zapisovatelnou kopii svazku (případně souboru nebo LUNu), která sdílí datové bloky s rodičem, takže nezabírá žádné místo. Kopie vznikne téměř okamžitě a zabírá prostor pouze pro metadata a zapsané změny.
Zobrazení (logické a fyzické) kapacity a informací o Storage Efficiency
Určité informací si můžeme zobrazit v GUI (nějaké detaily byly přidány v ONTAP 9.9.1), ale pro větší podrobnosti a více možností musíme použít CLI. V popisu System Manager si také rozebereme, co znamenají na různých místech uvedené logické a fyzické hodnoty.
CLI - zobrazení informací o Storage Efficiency
Můžeme si zobrazit jaké metody jsou zapnuté pro jednotlivé svazky.
AFF::> volume efficiency config Vserver: svm-iscsi Volume: Server_vol_01 Schedule: - Policy: auto Compression: true Inline Compression: true Inline Dedupe: true Data Compaction: true Cross Volume Inline Deduplication: true Cross Volume Background Deduplication: true
Další příkaz nám zobrazí stav efektivity pro svazky, včetně informací o probíhajících operacích. Případně detaily pro jednotlivé svazky.
volume efficiency show volume efficiency show -instance
Také si můžeme zobrazit stav efektivity pro agregáty (cross volume deduplication).
storage aggregate efficiency cross-volume-dedupe show
CLI - zobrazení úspory místa a obsazeného (fyzického i logického) prostoru
Kolik místa bylo ušetřeno díky efektivitě (jednotlivým funkcím) v rámci svazku vidíme v jeho detailech. V příkladu jsou zobrazeny pouze vybrané položky.
AFF::> volume show -vserver svm-iscsi -volume Server_vol_01
Volume Size: 15TB
Available Size: 5.42TB
Filesystem Size: 15TB
Used Size: 6.21TB
Used Percentage: 41%
Space Saved by Storage Efficiency: 2.94TB
Percentage Saved by Storage Efficiency: 32%
Space Saved by Deduplication: 2.94TB
Percentage Saved by Deduplication: 32%
Space Shared by Deduplication: 892.4GB
Space Saved by Compression: 0B
Percentage Space Saved by Compression: 0%
Total Physical Used Size: 6.21TB
Physical Used Percentage: 41%
Over Provisioned Size: 3.37TB
Logical Used Size: 9.15TB
Logical Used Percentage: 61%
Performance Tier Inactive User Data: 2.11TB
Jaký je poměr efektivity v rámci agregátů, kolik máme fyzicky použito prostoru a kolik je logicky uloženo dat, nám zobrazí varianta příkazu, který se musí spustit v privilegovaném režimu. Je zobrazena pouze část výstupu.
AFF::> set -privilege advanced
Warning: These advanced commands are potentially dangerous; use them only when directed to do
so by NetApp personnel.
Do you want to continue? {y|n}: y
AFF::*> storage aggregate show-efficiency -advanced
Aggregate: AFF_A250_01_NVME_SSD_1
Node: AFF-A250-01
----- Total Storage Efficiency ----------------
Logical Physical Storage
Used Used Efficiency Ratio
----------- ----------- -----------------------
38.06TB 17.51TB 2.17:1
-- Aggregate level Storage Efficiency ---------
(Aggregate Deduplication and Data Compaction)
Logical Physical Storage
Used Used Efficiency Ratio
----------- ----------- -----------------------
28.61TB 17.51TB 1.63:1
-------- Volume level Storage Efficiency -----------
Logical Physical Total Volume Level Data
Used Used Reduction Efficiency Ratio
----------- ----------- --------------------------
38.06TB 28.27TB 1.35:1
---- Deduplication ---- ------ Compression ----
Savings Efficiency Savings Efficiency
Ratio Ratio
----------- ----------- ----------- -----------
9.80TB 1.35:1 0B 1.00:1
Příkaz má také varianty, které spustíme v běžném režimu. Ukazuje pouze celkový poměr nebo rozpad na jednotlivé fuknce, ale bez velikosti dat.
storage aggregate show-efficiency storage aggregate show-efficiency -details
CLI - obsazení agregátu
Kolik celkového prostoru zabírají jednotlivé svazky v agregátu (včetně metadat a další režie, u Thick Provisioned je také uvedeno Volume Guarantee).
AFF::> volume show-footprint Vserver : svm-iscsi Volume : Servers_vol_01 Feature Used Used% -------------------------------- ---------- ----- Volume Data Footprint 6.20TB 27% Volume Guarantee 0B 0% Flexible Volume Metadata 37.51GB 0% Deduplication 39.47GB 0% Delayed Frees 70.64GB 0% Total Footprint 6.34TB 27%
Další zajímavý příkaz zobrazí využití prostoru v agregátu.
AFF::> storage aggregate show-space Aggregate : AFF_A250_01_NVME_SSD_1 Feature Used Used% -------------------------------- ---------- ------ Volume Footprints 29.12TB 125% Aggregate Metadata 0B 0% Snapshot Reserve 0B 0% Total Used 17.41TB 74% Total Physical Used 17.30TB 74% Total Provisioned Space 54.00TB 231%
Logická a fyzická kapacita
Díky vlivu deduplikace a Thin Provisioning (a dalších funkcí pro zvýšení efektivity ukládání) mi připadaly údaje o volném a obsazeném prostoru, které zobrazuje ONTAP System Manager (ale případně i CLI), docela matoucí. Navíc se GUI hodně mění s novými verzemi a různé verze zobrazují na stejném místě různé hodnoty.
Dokumentace uvádí, že se systémová kapacita měří dvěma způsoby
- fyzická kapacita (Physical capacity) - skutečně zabraný prostor, fyzické bloky úložiště (Storage), které zabírá svazek (Volume)
- logická kapacita (Logical capacity) - využitelný prostor svazku, objem dat bez započtení efektivity (deduplikace, komprese), obsahuje také Snapshoty a klony
Tedy logicky využitý prostor je velikost uložených dat, ale fyzicky zaberou menší prostor díky efektivitě.
System Manager - kapacita svazku - Volume Capacity
- Storage - Volumes
V ONTAP 9.9.1 vidíme seznam svazků a u nich kapacitu, kde je velikost, využitý a volný prostor. Můžeme na údaje kliknout a zobrazí se detailnější rozpad.
V příkladu máme svazek (Volume) o velikosti 2 TB, je přidělen serveru, který vidí disk 2 TB. Na serveru se uložilo 1,75 TB dat a zobrazuje volné místo 0,25 TB. ONTAP ukazuje, že je logicky využito (Logical Used) 1,75 TB, což fyzicky zabírá (Data Used) pouze 1,07 TB. Ale zobrazuje se, že dostupné místo (Available) je 955 GB (jak mi bylo vysvětleno, část místa zabírají WAFL metadata, proto to není 993 GB).
Server může zaplnit pouze 2 TB (logických) dat. Ale do svazku se může uložit více. Proto dokumentace uvádí, že celková logická kapacita může být větší než přidělený (provisioned) prostor. A procentuální využití logického prostoru může ukazovat více než 100 %.
Ovšem údaj, kolik využívají data (Data Used), neodpovídá fyzicky zabraným blokům úložiště. I když v Active IQ je tato hodnota nazvaná Physical Used. Toto je hodnota s vlivem Volume Efficiency, deduplikace v rámci svazku. Ale ještě se (standardně) provádí Cross-Volume Deduplication, dedupliakce v rámci agregátu, která může značně snížit fyzicky potřebnou kapacitu.
Další situaci či hodnotu, kterou můžeme vidět u svazku, je Over Provisioning. Pokud je volný fyzický prostor v agregátu menší, než má být dostupná kapacita ve svazku. Pak se jako volné místo ve svazku ukazuje dostupný prostor v agregátu. Zbytek je v grafu zobrazen černě jako Over-provisioning. Jelikož se jako volný prostor bere dostupná fyzická kapacita, tak v praxi máme k dispozici více místa pro data (při uplatnění deduplikace, apod).
System Manager - kapacita agregátu - Aggregate (Tier) Capacity
- Storage - Tiers
V zobrazení Tiers (agregátů) vidíme kolik fyzického prostoru je zabráno (Physical Used) a kolik volné (Available). Pro využité místo (Used Space) vidíme, kolik se zde nachází klientských dat (Client Data) a kolik zabírají Snapshoty, tedy kolik je celkem logicky obsazeno (Logical Used). Z toho se počítá poměr redukce dat (Data Reduction).
Pokud se podíváme na svazky, které se nachází v daném agregátu, a sečteme (fyzicky) využitou kapacitu. Tak je většinou hodnota větší, než je obsazený fyzický prostor agregátu. Je to proto, že se ještě uplatňuje Cross-Volume deduplikace, která může dosahovat dobrých výsledků, takže svazky zabírají ještě méně místa.
Tyto údaje vidíme (ve výše popsaném) CLI příkazu
storage aggregate show-efficiency -advanced
System Manager - Cluster Capacity
- Dashboard
Na dashboardu se ukazuje celková kapacita, která může být zavádějící. Ale vidíme celkový objem dat a redukční poměr, což se hodí. Na volné místo nemůžeme spoléhat, protože standardně máme vytvořené dva agregáty a v každém musí zůstávat dostatek volného místa.
Komentáře
Za mě skvělý průvodce základem v Netappu, hodně věcí mi to osvětlilo. Děkuji za Váš článek