Windows Server 2016 - a tárolóalrendszer (1. rész)
Szokás szerint minisorozatban ismerkedünk meg a következő generációs Windows Server újdonságaival. Az első rész a tárolós alrendszerrel foglalkozik - milyen újdonságokat hoz ezen a területen a Windows Server 2016?
A Windows Server 2016 Technical Preview 4 (innentől TP4) a következő Windows Server negyedik (de még nem az utolsó) béta kiadása. November 19-én jelent meg, és az előző, augusztusban elkészült verzióhoz (TP3) képest számos újdonságot kaptunk a kezünkbe, jónéhányat már egészen kiforrott állapotban. A főbb területek, amelyeken megtapasztalhatjuk ezeket a változásokat az aktuális szerver kiadásokhoz (pl. Windows Server 2012 R2) képest a következőek: szoftveralapú infrastruktúra - szervervirtualizáció, hálózat, tárolás, biztonság; a Nano Server és a konténeres technológiák.
Természetesen ez a lista kicsit szubjektív, plusz átfedéseket is tartalmaz, és nem egyforma terjedelmű a kategóriákban szereplő újdonságok mennyisége .De egyelőre nem is törekszünk/törekedhetünk a teljességre, úgyhogy ebben a cikkben önkényesen kiemeltem az egyik fő témakört, a tárolási alrendszert.
A Microsoft tárolási stratégiája
Mióta az adatközpont infrastuktúra már nemcsak helyi, hanem tipikusan hibrid, vagy éppen teljesen a publikus felhőszolgáltatásokon alapuló, azóta az általában a „faltól-falig” vonalat képviselő Microsoft ezen a területen is egymás után tette le a „garasait”, egy konzisztens és komplett platform mellett. A részletek, három kategóriába sorolva:
Helyi, klasszikus tárolás: Ide tartozik a jól ismert Storage Spaces (tárolóvirtualizáció) és a klasszikus SAN/NAS kapcsolatok teljeskörű támogatása pl. a Hyper-V és a privát felhős megoldások alatt is, folytatva mindezt a jövőben érkező, következő generácós privát felhő megoldással, a Microsoft Azure Stack-kel.
Hibrid tárolás: Ebben a kategóriában a különleges, vegyes használatú tároló, a StorSimple mellett az egyéb 3rd party tárolók Azure támogatása a kiemelendő. Plusz ide tartozik az igazán komplex Azure Site Recovery (VM, fizikai gép és komplett storage replikáció és replikáció szervezés) illetve az Azure Backup szoftveres megoldásai is.
Publikus felhős tárolás: A skálázható, gyakorlatilag végtelen kapacitású és teljesítményű, földrajzilag is elosztott, sokszorosan redundáns Azure Storage direkt használata akár a szimpla felhasználók (pl. OneDrive), akár a vállalatok (virtuális gépek, adatbázisok, stb.) számára.
A Windows Server 2016 tárolási újdonságai
E cikkben értelemszerűen az első kategóriát tárgyaljuk, hiszen ez kapcsolódik közvetlenül a Windows Serverhez. Kezdjük rögtön az eddig a legnagyobb durranásnak bizonyult Storage Spaces Direct-tel. Ez nagyon leegyszerűsítve a szervereinkbe kötött bármilyen (kommersz SATA/SAS, HDD/SSD, a legutóbbi utóbbi akár NVMe vagy SATA) helyi lemezek egy megosztott tárolóba szervezését és közös használatát jelenti – pl. egy fájlszerver fürt, vagy egy virtuális gépeket vagy SQL adatbázisokat tartalmazó SCOFS (Scale-Out File Server) felépítése apropóján. De a sztenderd lemezek helyett/mellett az olcsó és egyszerű JBOD-okat (DAS, Direct Attached Storage) is képes ez a megoldás használni.
Akár integrált, belső lemezekkel, akár külső JBOD-okkal - mindegy. Redundáns, hibatűrő, olcsó.
Ünnepi mix a bértranszparenciától a kódoló vezetőkig Négy IT karrierrel kapcsolatos, érdekes témát csomagoltunk a karácsonyfa alá.
Egy konkrét példát elővéve, a minimum 8 fizikai (vagy virtuális) lemez egységes, a gépek között „lebegő” elosztott tárolót alkot, amely a Server Manager vagy a Failover Cluster Manager segítségével Storage Pool-okba, majd virtuális kötetekbe (VD, nem .vhdx!), majd LUN-okba köthető. Azért minimum 8 a minimális lemez szám, mert akár fizikai akár virtuális gépekről van szó, minimum 4 host kell, hostonként minimum 2 adatlemezzel. Hogy aztán ezekből már 2 vagy 3 utas paritásos vagy tükör lemezt hozunk létre, hot spare-rel vagy anélkül, HDD-ket SSD-kkel keverve tárolórétegezéssel (tiering) vagy deduplikációval, vagy Thin Provisioningal, vagy fix mérettel – az már csak rajtunk áll, a Windows Server ezeket és más tároló képességeket is a kezünkbe adja.
Szépen látszik a poolban használt 8 meghajtó [+]
De ugyanezzel a megoldással ledőlt még egy fal, nézzük meg figyelmesen a következő ábrát!
Lehetőségektől és céloktól függően szeparálhatunk is
Ugyanis például egy kis- de inkább azért középvállalati környezetben innentől akár 4 izmosabb szerverrel, de drága, hardveres tároló nélkül is építhetünk egy szoftveres irányítású (software defined) tárolót, egyberagasztva a Hyper-V fürtünkkel (ezt „hyper-converged” névvel is illethetjük, szokjunk hozzá). De ha tágabb lehetőséggel rendelkezünk, azaz vastagabb pénztárcánk van, akkor értelemszerűen egy szeparált fájlszerver fürtünk is lehet, egy vagy több további Hyper-V fürttel pl. az igencsak izmos, rugalmas, és gyors és alacsony késleltetésű SMB3 vagy SMB Direct (RDMA) felhasználásával.
A megoldás felépítéséről a következő ábra gyakorlatilag mindent elmond, azonban két össztevőt mégis kiemelnék. A „Software Storage Bus” új komponens és ez biztosítja a tároló „lebegését” a hostok között. Jelenleg a kiépítés egy pontján Powershellből „kapcsolható” be, egészen egyszerű módon, feltéve ha minden követelménynek megfelel a rendszerünk. A ReFS NTFS-sel szembeni elsődlegessége nem megalapozatlan javaslat, oka hogy az ReFS számos ponton jobban optimalizált (például a Hyper-V műveleteknél), azaz embertelenül gyorsra sikerednek az export, a merge vagy egy virtuális lemez (.vhdx) létrehozása a TP4 alatt. Komolyan mondom, pl. az én tesztrendszeremben egy 50GB-os fix virtuális lemez ugyanazon a (nem túl gyors) fizikai háttértáron 92 mp helyett 4 mp, de ezt bárki tudja tesztelni, nem túlzok.
A következő és kapcsolódó megoldás az ún. „Storage Replica”, amely egy tárolóhardver-független, blokkszintű szinkron vagy aszinkron replikáció szerverek vagy fürtök között. Komplex DR célokra, vagy pl. egy stretch cluster (többtelephelyes fürt) alá tökéletes és olcsó megoldás, különösen ha tudjuk, hogy pl. a szinkron replikációval az adattükrözés konzisztens marad baleset esetén is, zéró fájlrendszer szintű adatvesztéssel.
No és persze ez is teljeskörű megoldás: Hyper-V, Storage Spaces, fürt, Scale-Out File Server, SMB3, deduplikáció, ReFS és NTFS, illetve PowerShell támogatás is jár hozzá, plusz a a megszokott felügyeleti eszközökkel piszkálhatjuk pl. a Failover Cluster Manager-rel.
A Storage Spaces Direct kötet is replikálható [+]
További, immár csak felsorolásszerű, vegyes felvágott a TP4 által támogatott tárolási képességekből vagy a korábban már debütált megoldások újdonságaiból:
- Storage Quality of Service (QoS): A WS2012R2-ben kezdődött virtuális lemezek IOPS szabályozása „történet” folytatása, az üzemeltetők számára lényegesen kifinomultabb konfigurációs lehetőségekkel.
- VM Storage Resiliency: A virtuális gépek tároló nélküli (mármint nem rendeltetésszerűen nélküli) életének egyszerűsítése, azaz a kiesés adatvesztést nem, vagy kevésbé okozhat egy WS16 TP4 Hyper-V alatt. A folyamatos monitorozás védi a virtuális gép konzisztenciáját, és azonnal szünetelteti a működését, ha tároló elérési probléma van.
- Deduplikáció: Akár 64 TB-os kötetek használata, és akár a max 1TB fájloké is, Nano Server támogatás és a háttérban történő optimalizáció gyorsítása.
- Storage Health Service: új cmdletekkel az ellenőrzés, a monitorozás, és a jelentések elkészítése gyorsabb, egyszerűbb és szárazabb érzés.
- Az ún. „rolling upgrade” a fájlszerver fürtökre is vonatkozik, azaz ideiglenesen a fürt tagjai lehetnek korábbi OS verziók is, így a frissítés nem annyira fájdalmas, és természetesen leállás nélküli. Bevezetésre került a cluster „működési szint”, ami az AD DS-ben megszokott módon eleinte a kompatibilitást szolgálja, majd az összes fürttag frissítése után átkapcsolva új képességek használatát is lehetővé teszi.
Szorosan ide kapcsolódik az az információ is, hogy nemcsak a Windows Server 2016 készül gőzerővel, hanem a System Center 2016 is. Az együtthaladás egyik fő bizonyítéka, az hogy például minden új WS16 tárolási képességet a megfelelő Syster Center komponens is támogat, ergo pl. a Storage Spaces Direct megoldást a SCVMM Fabric része - az eddig megszokott módon - simán lekezeli, azaz az SMAPI-n keresztül (Storage Management API), a provizionálás, a besorolás, a kötetek Hyper-V hostokhoz, fürthöz és a virtuális gépekhez kapcsolása is működik - már most is, a System Center VMM TP4-ben is.
A kipróbálható szoftverek a Microsoft oldaláról tölthetőek le, ez a Windows Server 2016 TP4, ez pedig a System Center 2016 TP4 elérhetősége.
Gál Tamás, adatközpont specialista, Microsoft Magyarország