Asseco Helios 1
facebook LinkedIN LinkedIN - follow

Průvodce software defined storage

AlefV dnešní době hledá stále více organizací způsob, jak získat volnost v nákupu hardwaru pro podnikové úložiště. Slibují si, že se při použití Software Defined Storage zbaví takzvaného vendor lock in a současně získají finančních úsporu, protože SDS vytváří z běžných komoditních serverů připojených k Ethernet síti úložiště s plnohodnotným data managementem. Snížení nákladů také bývá jeden z častých důvodů, proč sáhnout po SDS řešení.


V současnosti pozorujeme navýšení propustnosti LAN sítí, kdy běžně dostupných 10 -100Gbps uspokojí i ty nejnáročnější aplikační požadavky. To opět nahrává SDS, protože nižší optimalizace proti FC blokovým storage systémům je kompenzována hrubým výpočetním výkonem a vyšší síťovou propustností. Organizace tak dnes přemýšlí intenzivně nad opuštěním SAN, protože udržovat dva typy sítí přestává mít takový význam, jako tomu bylo v minulosti. Na trhu však existuje nepřeberné množství SDS produktů od renomovaných výrobců storage, virtualizace, ale i open source a není proto jednoduché si vybrat to správné řešení pro daný záměr. Navíc ve světě SDS bývá často mnoho kompromisů, ať už funkčních, ekonomických anebo výkonnostních. Abych vám usnadnil orientaci v této oblasti, připravil jsem pro vás průvodce software defined storage. Vychází z praktických zkušeností a mého působení ve společnosti ALEF, která dodává NetApp i další informační technologie.

Open Source nebo Entrerprise produkt?

Asi se většina z nás shodne, že primární funkcí storage systému má být vytvoření úložného prostoru pro aplikace a poskytování dat s rozumnou dostupností a odolností proti ztrátě dat. Open source SDS má ambici nahradit Enterprise storage. Výrobci podnikových úložišť však posledních 40 let investují miliardy dolarů do vývoje a podpory svých produktů. Má open source komunita na to, aby byla lepší?

Existuje celá řada open source projektů, které mají ambice kombinovat SW RAID kontrolér se souborovým systémem, odtud je to už jen krůček k poskytování dat po síti. Asi nejznámější je Open ZFS pro BSD nebo ZFS on Linux, projekt vznikl někdy okolo roku 2013 forkem ZFS poté, co Oracle uvolnil OpenSolaris jako open source. ZFS je robustní souborový systém, který vymyslel Sun Microsystems v době točivých disků a velmi podrobně kopíroval funkcionalitu WAFL od NetApp (write anywhere file layout). ZFS byl de facto produktem snahy Sunu někdy z roku 2001 zbavit se do té doby vysoké závislosti na enterprise storage systémech od společnosti NetApp. Protože NetApp vyráběl tehdy prémiový SDS produkt, ale vázaný na proprietární hardware, chtěl si Sun vyrábět vlastní HW, aby vydělal víc a nemusel používat NetApp. Je vtipné, že podobná snaha existovala v enterprise světě už v roce 2001 a motivace byla vlastně podobná, jako mají firmy nyní. Pokud vám jde o konzistenci dat a nechcete kupovat enterprise storage, je ZFS prakticky jediná volba v Unix a Linux světě díky extrémnímu důrazu na spolehlivost a odolnost. Podporuje hashování každého zapsaného bloku dat, scrubbing, tedy průběžnou kontrolu konzistence dat, replikaci dat a RAID až s trojitou paritou. Má to však svoje ale. Škálování je velmi nepraktické, protože ZFS neumí rozšiřovat velikost RAID skupiny, a to je do malých prostředí nevhodné, protože škálování lze řešit pouze přidáváním celých RAID skupin do poolu. Enkrypce dat se stala noční můrou řady uživatelů ZFS, protože ta byla řešena externím modulem a bohužel při nedodržení celé řady nutných postupů vedla ke ztrátě dat při výměně vadných disků. ZFS nebylo optimalizováno pro SSD, takže chyběly funkce jako TRIM a obecně ochrana před předčasným vypsáním SSD. Obecně lze tvrdit, že ZFS narazilo na svůj limit a open source komunita se začala snažit napsat lepší řešení pro ukládání dat. I tak ZFS používá celá řada populárních projektů, jako Freenas, Proxmox, NexentaStor, QNAP a Oracle (nikoliv v open source verzi), protože funkcionalita ZFS se prostě nepodařila open source komunitě překonat do roku 2020.

Zhruba v roce 2009 se začal prosazovat nový open source linuxový projekt BTRFS, který měl ambici zajistit to stejné, co ZFS, ale měl být víc nadčasový. Měl to být moderní škálovatelný souborový systém s integrovaným RAID kontrolérem, vyššími kapacitními limity, optimalizovaný pro flash, měl mít velmi efektivní snapshoty, replikaci dat a měl řešit konzistenci a scrubbing dat, podobně jako ZFS. Ač se projekt jevil zajímavě, bohužel ho v roce 2019 RedHat stáhnul ze své linuxové distribuce, protože BTRFS ztrácel data. Projevila se velmi těžko řešitelná „write hole“ chyba implementace RAID 5 a 6. Zajímavé je, že i přes takto závažné problémy se najdou výrobci SDS, jako například Synology, Rockstor, Suse a další, kteří mají BTRFS nasazen jako defaultní souborový systém. Open source systémy řešící SDS formou NAS a SAN mají obvykle problém s vysokou dostupností, komplexitou, technologickou zastaralostí a špatnou rozšiřitelností. Zdá se, že investici do vývoje velkých specializovaných storage vendorů, se open source komunitě ještě chvíli nepodaří přetlačit.

Mnoho lidí argumentuje tím, že na open source projektech běží velké organizace jako Facebook, AWS a Google. Je důležité si uvědomit, že sice používají open source základ, ale mají armádu vlastních vývojářů, které drží prostředí při životě. Navíc většina cloudových služeb, které jsou zadarmo, negarantují naprosto žádným způsobem odolnost dat. Dokonce i AWS, které je placené u svých blokových služeb nabízí většinou 99,9 % durabilitu dat. Což znamená, že z jednoho TB dat, je tolerovatelná ztráta 1 GB ročně. Když se v tom jednom GB nachází fotky koťátek a jídla, jako v případě Facebooku, je to asi perfektně tolerovatelné. Když ale ztratí firma 1 GB z 1 TB podnikové databáze, rozpadne se databáze celá. To je důvod, proč i v hyperscale cloudech, jako je AWS, Google nebo Azure najdete specializované storage služby enterprise vendorů, jako je NetApp. Případně, když jde o opravdu vysokou durabilitu dat, je zajímavá volba objektového úložiště, které řeší durabilitu dat často několikanásobnou replikací napříč regiony.

Když se dva perou, třetí se směje

Zajímavou snahou zvítězit v boji o ultimátní SDS řešení je počin firem VMware, Nutanix nebo SolidFire (nyní také NetApp), které de facto definují současný trend hyperkonvergence. Tito výrobci překonali v nesmírně krátkém čase snahu open source komunity vyvinout SDS produkt pro komoditní servery. Cesta to nebyla jednoduchá, protože i VMware například v roce 2017 ztrácel ještě data, protože neměl implementovaný checksum dat a zpětnou kontrolu. Takže se čas od času stalo, že se vlivem silent bit rotu na discích rozpadl celý cluster. VMware se však poučil a nyní je již produkt vhodný pro produkční nasazení. Takové štěstí BTRFS nemělo…

Jak udělat škálovatelnou storage, která neztrácí data a není omezena rozšiřováním RAID skupin v rámci serveru? Odpověď je vyhodit ochranu RAID technologií úplně a založit storage na „Shared Nothing“ architektuře, která je u SDS velice populární. Sází při ochraně dat na N násobnou replikaci dat mezi servery, které nemají chráněna data lokálně RAIDem. Škálování probíhá přidáváním celých serverů s disky do mnohauzlových clusterů. Když byly tyto technologie uvedeny na trh, disponovaly tolika výhodami, že se na okamžik zdálo, že zastíní tradiční storage výrobce. Až doba ukázala, že pro ochranu před výpadkem 2 disků současně je nutné použít u shared nothing architektury čtyřnásobek disků a serverů než u tradiční architektury. Problém tkví v tom, že u tradičního dvou nebo tří paritního RAID, jako nabízí WAFL od NetApp mohu z 24 SSD disků použít defacto 21 disků pro data, protože jeden disk je použit pro hotspare kapacitu a 2 nebo 3 disky jsou použity pro paritu. Systém je tak odolný proti výpadku 2 až 3 disků. Ve vSAN je nutné pro docílení obdobné ochrany před výpadkem použití tří kopií dat uvnitř jednoho clusteru. Musím mít tedy 3 servery, každý s 8 disky. Jeden disk je použit 1 pro write buffer, data jsou pak uložena na zbylých 7 disků ve 3 kopiích, kdy na každém serveru je jedna kopie. Platí ale, že na každém vSAN serveru musím mít 30 % kapacitní rezervu, kterou nesmím použít pro data. Což znamená, že pro dosažení podobné kapacity, jako by dal 24 diskový NetApp storage system, musím použít 96 diskový vSAN cluster. Protože efektivita pod 20 % NET kapacity proti RAW kapacitě není nic oslňujícího, pořád si stále většina zákazníků kupuje tradiční enterprise storage, kde se efektivita pohybuje okolo 70 % a výše. Podobnou neefektivitou trpí i objektové storage, ty však kompenzují svoji neefektivitu a pomalý výkon ve smyslu odezvy vysokou škálovatelností a odolností dat. Přestože shared nothing architektura není levná a v určitých ohledech ani praktická, můžeme jí poděkovat za to, že vyvinula tlak na tradiční storage vendory, jako NetApp, a ti uvolnili čistě SDS varianty svých storage operačních systémů pro komoditní servery. Dalším obrovským přínosem je integrace s aplikačními prostředími a virtualizační vrstvou, což jde naproti trendu automatizace. Existují tedy scénáře, ve kterých je HW nehospodárnost hyperkonvergence ekonomicky kompenzována nižšími náklady na správu díky automatizaci.

Co si tedy vybrat? Odpověď je velmi individuální.

Data Fabric for the Hubrid Multi-Cloud

Objektové, blokové nebo souborové úložiště?

Na začátku je velmi důležité položit si otázku: Pro jaký záměr chci úložiště stavět? Marketingová oddělení většiny výrobců HCI nebo SDS řešení Vám říkají: „Naše řešení je nejlepší pro všechny účely, můžete je nasadit kdekoliv.“ Každý, kdo má ale nějakou životní zkušenost, tuší, že neexistuje nic jako „jedna velikost padne všem“. Ve zkratce se dá říci, že existují SDS úložiště určená pro běh business kritických aplikací, ta bývají nejčastěji bloková (iSCSI). To ale neznamená, že blokový přístup je ten nejlepší. Je velmi tradiční a umí s ním pracovat všechny hypervizory a operační systémy, což z něj dělá velmi univerzální volbu. Tuto roli někdy přebírají i souborová úložiště s NFS protokolem z důvodu mnohem pružnější práce s daty. Přeci jen zvětšit, zmenšit nebo smazat soubor se dá snadněji než provádět stejné operace u blokových zařízení nad LUNem. U blokového přístupu a virtualizace je problematický fakt, že úložiště nevidí a nerozumí souborovému systému OS virtuálního stroje a často neumí jednat v souladu s operacemi OS. Když například OS smaže dříve zapsaná data na virtuálním disku, úložiště nemá ponětí, že k vymazání dat došlo a vidí je jako obsazená, dokud se neprovede operace pro navrácení volného prostoru zpět úložišti ze strany hypervizoru. U NFS přístupu se nic podobného řešit nemusí. NAS s NFS protokolem jsou navíc velmi vhodná pro databáze a persistentní úložiště kontejnerových aplikací nebo obecně pro sdílení souborů v Linux/Unix prostředích. VMware VVOLs jsou implementovány jak pro NFS tak iSCSI.

Ve světě Microsoft je vhodné pro kolaboraci nad soubory a pro domácí složky nasadit souborové úložiště s protokolem CIFS/SMB. Organizace vyvíjející aplikace běžící nativně v cloudu pak často rády využívají objektová úložiště využívající S3 nebo Swift protokol.

Velikou otázkou je zálohování a archiv. Zálohovací software umí většinou používat blokový, souborový i objektový přístup k datům, ale ne všechny protokoly nabízejí rovnocennou funkcionalitu. Není nic špatného na tom, když zálohujete data na blokové úložiště, ale pokud zálohujeme např. souborový systém nebo databázi na souborové úložiště formou storage replikace s archivem snapshotů, je možné zajistit okamžitý uživatelský přístup ke všem historickým verzím souboru bez nutnosti obnovy dat ze zálohy, což by u blokového backupu VM se souborovým serverem nebylo možné. Toto opět nabízí vyšší rychlost práce s daty a lepší pružnost. Pokročilejší NAS úložiště navíc nabízí ještě funkcionalitu zámků souborů po určenou retenční periodu. Tato funkcionalita je výhodná, pokud chcete mít například jistotu, že vaše data nepůjdou nijak aplikačně pozměnit (prevence proti smazání logů, prevence proti ransomware, archiv důležitých dokumentů). Tím, že tyto funkcionality bývají relativně proprietární, backup SW s nimi většinou neumí pracovat, zámek je tak nutné aplikovat například na celý volume. Problém se souborovými úložišti také nastává, pokud je potřeba uložit řádově vyšší miliardy malých souborů, na tento limit lze narazit například při ukládání nestrukturovaných vědeckých nebo průmyslových dat, nebo při tvorbě webových aplikací s funkcionalitou ala DropBox, YouTube atd. Souborová úložiště totiž většinou používají souborové systémy vyvinuté v době, kdy si nikdo takové množství dat ani neuměl představit. Problém škálovatelnosti do stovek miliard objektů a dlouhodobou archivaci dat řeší objektová úložiště, ta navíc přidávají i funkcionalitu pro geodistribuci dat podle různých politik. Objektová úložiště se stala de facto synonymem pro cloudové úložiště. Díky oblibě vývojářů při psaní nejen webových aplikací a díky relativně nízké ceně se S3 storage v AWS stala de facto standardem. Většina podnikových objektových úložišť adoptovala S3 komunikační protokol jako defaultní právě i kvůli kompatibilitě s AWS. Díky škálovatelnosti, vysoké odolnosti proti ztrátě dat a možnostem zamknout objekt proti smazání a díky adopci cloudu pro backup u velkých firem, začínají vývojáři zálohovacího software volit objektová úložiště jako primární volbu. Velikou nevýhodou objektových úložišť pak ale bývá horší latence proti souborovým a obzvláště blokovým úložištím, takže jsou naprosto nevhodná pro jakékoliv lokální databáze, virtualizaci a podobně.

SDS - Jak propojit Cloud s on premise

SDS dává organizacím šanci expandovat se svými daty a aplikacemi za hranice vlastního data centra. Společnost NetApp se svým storage operačním systémem ONTAP dává IT managerům volbu protokolu i formy nasazení storage služeb. ONTAP lze nasadit formou vendorsky vyrobeného storage systému, existuje jako SDS varianta pro komoditní servery a existuje i jako cloudová instance v AWS, Google a Azure. Nabízí protokoly NFS, CIFS, iSCSI ve svých SDS a cloud variantách a na vendorsky vyráběných systémech přidává navíc objektový S3 protokol nebo blokové FC a moderní NVMe over Fabrics protokoly. Fakt, že si lze vybrat všechny hlavní protokoly na jediné data management platformě je obrovské plus, ale mnohem zásadnější je fakt, že lze pomocí ONTAP replikovat nebo tierovat data mezi on prem prostředím a public cloudem. Toto je obzvlášť potřebné pro scénáře disaster recovery nebo zálohování do cloudu nebo naopak, pokud se organizace rozhodne formou lift and shift migrovat aplikační data do cloudu. ONTAP dává správcům IT prostředí jeden nástroj, kterým řídí tok dat, ať už do cloudu, z cloudu nebo mezi cloudy. To nás přivádí k dalšímu bodu, který spoustu IT managerů na počátku přechodu do cloudu neřeší, ale později se často stává velkým tématem, a tím je exit strategy. Není neobvyklé, že se v průběhu nasazení aplikace v cloudu stane, že hyperscale cloud je nejvýhodnější jen v malém měřítku, ale od určité velikosti nebo výkonnostních požadavků je mnohem výhodnější aplikaci přenést opět do on premise prostředí nebo jiného cloudu. Tím, že služby v různých cloudech mají různé parametry a funkcionality a různou úroveň správy není někdy opuštění cloudu úplně jednoduché. ONTAP funkcionalitu data managementu unifikuje napříč různými prostředími, ale stejně tak unifikuje i zabezpečení a dává volnost data mezi cloudy data snadno přenášet nebo sdílet. S touto SDS je například možné i tierovat data mezi S3/objektovými úložišti a all flash rychlou vrstvou. To znamená, že data, která musí být dostupná rychle a s nejnižší latencí, jsou na nejrychlejším možném tieru a studená data nebo snapshoty mohou být odkládány na nejlevnějším možném tieru.

I přes vysokou univerzalitu ONTAP, má NetApp specializovaný produkt pro objektová úložiště. Ten se nazývá StorageGRID a lze nasadit jako VM, docker kontejner nebo na specializované appliance přímo od výrobce. Důvod, proč NetApp udržuje dva produkty nabízející objektový přístup, je ten, že StorageGRID je specializovaný produkt, proti ONTAP nabízí řádově vyšší maximální množství uložených objektů a lepší schopnosti geodistribuce objektů podle politik nad metadaty a také nabízí lepší kompatibilitu API s AWS S3. Oba systémy spolu ale spolupracují a je například možné zdarma tierovat data mezi ONTAP all flash úložištěm nebo SDS a StorageGRID SDS.

Pro vývojáře je tedy možné začít vyvíjet a testovat například kontejnerovou aplikaci v on premise, ale při masovém nasazení, lze plynule přejít do cloudu, a to vše díky SDS a její integraci například s Kubernetes. Díky NetApp jen tento přechod snadný obousměrně.

David Rusín
Datacenter consultant, cz-netapp@alef.com