Storage replica ve Windows Server 2016

Úvod

Do Windows Serveru dorazila plnotučná replikace a jde na to pěkně od podlahy. V Microsoftu si řekli: „Ano, budeme replikovat data a ano uděláme to pořádně.“ Pojďme se podívat, jak to dopadlo.

V rámci úvodu, zejména pro ty, kteří chtějí pouze návod jak Storage replica nakonfigurovat, tady je nutné minimum pro pochopení o co se jedná

· Storage agnostic – je jedno jestli vaše data jsou na iSCSI, Fibre Chanel, SAS nebo na jakémkoliv zařízení s podporovaným ovladačem. Replikujte jednoduše odkudkoliv.

· Block level – replikujeme na blokové úrovni. Jak máte velkou allocation unit ve filesystému, tak máte granulární repliku.

· Synchronous – ano, synchronní replika. Storage replica garantuje, že to co je zapsáno na lokální disk, je na 100% zapsáno také na ten vzdálený.

· Asynchronous – ano, jestli máte pomalou linku, můžete replikovat asynchronně.

· Cluster supported – ano, můžete vytvořit Stretch Cluster a ještě jednou ano, můžete replikovat data mezi dvěma Clustery.

· SMB 3 – Storage replica podporuje SMB 3 protokol se všemi výhodami, které tato technologie nabízí (multichannel, RDMA, RoCE, iWRAP)

· Seeding – potřebujete replikovat opravdu velký objem dat a úvodní replika by trvala týdny? Převezte data do záložní lokality, třeba na páskách, obnovte a Storage replica doreplikuje jenom změny.

Kdo se nechce zatěžovat nudnou teorií, může se rovnou vrhnout do Instalace, my ostatní se teď podíváme co má Storage Replica pod kapotou.

Předpoklady

Předpoklady pro nasazení. Jako všude, i pro Storage Replica je nutné splnit požadované prerekvizity a máme i nějaká omezení, tady jsou

· Active Directory Domain Services forest – všechny servery, které se na replice účastní, musí být členy domény.

· Minimálně dva servery s OS Windows Server 2016, to jsou ty, mezi kterými budeme replikovat

· Dva Storage sety (pokud potřebujete obousměrnou replikaci). Storage set může být tvořený z mixu SSD a rotačních disků.

· Na každém Storage setu musí být možné vytvořit minimálně dva volumy. Jeden pro vlastní replikovaná data, druhý pro replikační log. Fyzický Storage musí mít stejnou velikost sektorů na disku.

· Zdrojový a cílový Volume musí být stejně velké. Opravdu, na bit přesně.

· Alespoň jednu 1GbE síťovou kartu pro synchronní repliku, pro dostatečný výkon je doporučena karta s podporou RDMA.

· Povolená síťová komunikace mezi všemi účastníky replikace ICMP, SMB (port 445, plus 5445 pro SMB Direct) a WS-MAN (port 5985).

· Síťová konektivita s dostatečnou propustností a latencí ≤5ms round trip pro synchronní repliku. Asynchronní replika nemá z hlediska latencí žádné omezení, tam se prostě musíte vejít do šířky pásma.

· Není možné replikovat Volume, kde je nainstalovaný operační systém.

K čemu je to dobré

To co se v angličtině označuje jako use cases, je v případě Storage replica poměrně široké téma. Začněme tím nejjednodušším a to je prostá replika Volumu z jednoho serveru na druhý. Jak již bylo nastíněno výše, může být replika synchronní i asynchronní.

1

V tomto případě jsou data na serveru B nedostupná a vše co se zapíše na datový disk v serveru A je replikováno na Server B. Data na serveru B je možné zpřístupnit tak, že se provede plánovaný promote tj. otočí se směr repliky (na serveru A přestanou být data čitelná) nebo neplánovaný. Neplánovaný promote se provádí v případě, kdy Server A je nedostupný a Server B musí převzít jeho roli.

Jak je z příkladu zřejmé, jeho použití v reálném světě je možné, ale významně omezené především proto, že oba servery mají rozdílnou síťovou identitu. I když budeme udržovat aplikaci na serveru A i B v identické konfiguraci (což v praxi není jednoduchý úkol), stále při přepnutí repliky musíme vyřešit jak jednoduše přesměrovat klienty na nový server.

Jednou variantou řešení je nainstalovat na oba servery Hyper-V a replikovat celé virtuální servery (oproti Hyper-V Replica získáme možnost provádět synchronní repliku. Vlastní přepnutí však bude vždy manuální a bude se skládat z více kroků (Promote replica, registrace VM’s na Serveru B atd.)

Další variantou je zařadit do řešení Windows Failover Cluster. S Failover Clusterem máme dva základní scénáře nasazení. Prvním je Stretch Cluster, konfigurace, kdy jsou uzly Clusteru instalované ve dvou nezávislých lokalitách mezi kterými je konfigurována Storage Replica. Protože se replikované volumy stanou zdroji Clusteru, při přepnutí do vzdálené lokality se automaticky provede i otočení směru repliky. Velmi sympatická varianta je v kombinaci s Hyper-V Clusterem.

2

Druhou podporovanou konfigurací v kombinaci Windows Failover Clusterem je replikace mezi dvěma Clustery. Konfigurace pak vypadá takto

3

Přepnutí v této konfiguraci není automatické, ale je nutné na cílovém Clusteru provést manuální zásahy. Tato konfigurace je vhodná pro velmi vzdálené lokality, kde není možné použít synchronní repliku.

Pro všechny scénáře je možné konfigurovat jak synchronní tak asynchronní.

Dalším problémem, se kterým se můžeme při nasazení repliky setkat, je potřeba udržení konzistence mezi dvěma nebo více volumy. Například pokud budeme replikovat 2 virtuální servery, které provozují jeden aplikační celek a budou si mezi sebou vyměňovat data, budeme potřebovat zajistit, že stav repliky na cílovém serveru je pro oba stroje identický. Toho dosáhneme pomocí volby EnableConsistencyGroups při vytváření repliky cmdletem New-SRPartnership.

Instalace

Storage replica je standardní Feature Windows serveru, instalace je snadná

4 5

Nebo takto, pomocí cmdletu Install-WindowsFeature.

6

Pro fungování replikace je nutné povolit SMB3 na firewallu.

7

Teď když máme nachystané servery, podíváme se na Volumy, které budeme replikovat. V nejjednodušším případě stačí 2 Volumy, jeden pro Log a druhý na kterém budou replikovaná Data

8

Oba mohou být umístněné na jednom disku, který ovšem musí být vytvořen jako GPT

9

Velmi užitečným cmdletem je Test-SRTopology, který vám umožní otestovat nejenom to, zda jsou na obou nodech nainstalované potřebné komponenty a infrastruktura je s technologií Storage Replica kompatibilní, ale také provede výkonový test na propustnost linky a její latence. Malé upozornění pro jistotu, výkonnostní test znamená, že po síti poteče tolik dat, kolik se do ní vejde, tj. v produkčním prostředí buďte opatrní. Příklad syntaxe

Test-SRTopology -SourceComputerName w2k16Node1 -SourceVolumeName f: -SourceLogVolumeName e: -DestinationComputerName w2k16Node2 -DestinationVolumeName f: -DestinationLogVolumeName e: -DurationInMinutes 10 -ResultPath c:\temp

Report o výsledku testu ve formátu html naleznete ve složce ResultPath.

10

Konfigurace

Pokud je vše v pořádku, můžeme přikročit k vytvoření vlasní repliky. Syntaxe je následující

New-SRPartnership -SourceComputerName w2k16Node1 -SourceRGName repgroup01 -SourceVolumeName f: -SourceLogVolumeName e: -DestinationComputerName w2k16Node2 -DestinationRGName repgroup02 -DestinationVolumeName f: -DestinationLogVolumeName e: 11

Nyní je replika nastavena a data jsou replikována na disk v cílovém serveru. Stav repliky je možné ověřit následujícím cmdletem

(Get-SRGroup -ComputerName %server%).replicas 12

Dalším ze základních procesů, které musí mít administrátor k dispozici je „otočení“ směru replikace. Cmdlet Set-SRPartnership slouží obecně k ovládání replik. Pro revert je syntaxe

Set-SRPartnership -NewSourceComputerName w2k16Node2 -SourceRGName repgroup01 -DestinationComputerName w2k16Node1 -DestinationRGName repgroup01 13

Posledním, ze základních kroků při ovládání repliky je její korektní zrušení. Začneme cmdletem Remove-SRPartnership

Get-SRPartnership | Remove-SRPartnership 14

Nyní se data přestala replikovat. Datové volumy jsou na obou serverech přístupné pro čtení i zápis. Replikovaná data nejsou smazána. To co v konfiguraci zůstává, je konfigurace replikačních skupin, o čemž se můžeme přesvědčit pomocí příkazu Get-SRGroup

15

Odstranění provedeme pomocí následující syntaxe

Get-SRGroup | Remove-SRGroup

Závěr

V článku jsme se seznámili s novou technologií a nastínili možnosti využití. Je zřejmé, že s novou verzí operačního systému přichází opravdu nové pojetí jak přístupu k diskovému subsystému (Software Defined Storage) tak síťovému stacku (Software Defined Network). Storage replica je jedním z dílků skládačky a bude záležet i na souvisejících technologiích jak se nakonec prosadí. Co je však jasné už dnes, že pro menší prostředí je Storage Replica nadějnou a ekonomicky výhodnou technologií pro Disaster Recovery řešení.

- Lukáš Radil, KPCS CZ

 

Mohlo by vás též zajímat:

Windows Server 2016 - Storage Replica on Thin-Provisioned Storage