次の方法で共有

Storage Replica czyli WVR

  • [アーティクル]

Redundancja to trudne slowo, ale nawet, jezeli ktos nie umie go wymówic, to wie, ze w swiecie IT jest niezwykle wazna. Do calego ogromnego portfolio rozwiazan dotykajacych tego tematu (tak pochodzacych od Microsoft jak i od firm trzecich), dolacza w Windows 10 kolejne – tytulowa Storage Replica zwana dawniej Windows Volume Replication.

UWAGA 1: Caly ten wpis dotyczy wersji Beta a dokladnie 6.4.9841. W wiekszosci srodowisk ta wersja nie jest wspierana w produkcyjnym uzyciu.

UWAGA 2: Nawet, jezeli w twoim srodowisku Windows w wersji 6.4 Beta jest wspierany, to Storage Replica na pewno nie jest.

Tak wiec, nawet jezeli nie powiem "nie próbujcie tego w domu", to mówie "nie róbcie tego z danymi, których utrata (chocby chwilowa) moze zabolec".

Podobnie, jak we wszystkich innych rozwiazaniach tego typu, absolutnie kluczowa jest wiedza na temat tego jak to wszystko dokladnie dziala. Bez tej wiedzy mamy ogromna szanse potknac sie o jakies ograniczenia albo uzyc rozwiazania zupelnie niedopasowanego do faktycznych potrzeb biznesowych. Pól biedy, jezeli zbudujemy rozwiazanie niepotrzebnie kosztowne. Gorzej, jezeli nasze rozwiazanie w chwili próby stwierdzi "nie mamy pana plasz^H^H^H^H^H danych i co nam pan teraz zrobi?".

Myslac o Storage Replica, zapamietac nalezy w zasadzie tylko dwie najwazniejsze rzeczy:

  • Storage Replica dziala na poziomie bloków i operacji I/O. Jest zapis na wolumenie = blok sie replikuje. Obojetne czy to zapisany wlasnie dokument Word, kawalek SQLowego pliku .ldf, maszyna wirtualna czy wipe pliku samymi zerami.
  • Dopóki dziala oryginal, jego replika jest niedostepna. To nie jest DFSR. Tu nie chodzi o latwy dostep do danych w wielu miejscach. Tu chodzi o to, zeby dane, które znajda sie na wolumenie zródlowym, jak najszybciej skopiowane zostaly na zapasowy. W jedna strone. Warto wiedziec, ze sterownik odpowiedzialny za replikacje jest umieszczony naprawde bardzo nisko w stosie. Pod filesystemem, pod volsnap.sys, pod bitlockerem a nawet pod volume managerem. Oznacza to, ze pracuje po prostu na blokach. A co w nich jest – nic go nie obchodzi. Moze dlatego nie da sie replikowac woluminów zawierajacych pagefile.

Niespotykane dotad w systemach Microsoft podejscie sprawia, ze nic nie zginie nawet, jezeli w serwerowni zdarzy sie katastrofa. Gorzej, jezeli zlosliwy wirus zaszyfruje wszystkie pliki, bo i replika bedzie zaszyfrowana wersje zawierac. Usuniecie plików przez administratora tez sie blyskawicznie zreplikuje. Moze tak byc powinno a moze nie, ale jak zwykle – sukces w zabezpieczaniu danych polega na tym, ze dobierzemy dobra ochrone do faktycznej potrzeby i ryzyk, które w swiadomy sposób powinny byc zdefiniowane i zarzadzane.

OK. Pora na to, co techniczni lubia najbardziej, czyli maly test. W najprostszym scenariuszu potrzebujemy dwóch maszyn (u mnie NODE1 i NODE2), polaczonych szybkim (ponizej 5ms RTT, zwlaszcza dla potrzeb replikacji synchronicznej) laczem, nalezacych do jednej domeny Active Directory. Oczywiscie maszyny musza miec jakies woluminy do replikowania. Dyski systemowe sprawdzaja sie tu z oczywistych powodów dosc slabo.

Dodatkowo, poza dyskiem replikowanym i trzymajacym replike, na kazdej z maszyn potrzebne sa (szybkie, najlepiej SSD) dyski na logi replikacji. Czyli kolejne dwa woluminy, po jednym na kazda z maszyn. Jedna para dysków na logi moze byc uzywana przez replikacje wielu róznych par dysków na dane, o ile tylko nie zabraknie nam IOPsów. Dobór rozmiaru logu jest calkiem sporym wyzwaniem. Zajecie zbyt duzej ilosci miejsca nie jest rozsadne a zbyt malej – tez niekoniecznie. Generalnie, w logu powinny zmiescic sie bloki zmodyfikowane w czasie, kiedy nie mozna skomunikowac sie z partnerem replikacyjnym. Rozmiar logu na pewno nie ma za to wplywu na szybkosc dzialania, co czasem bywa nieslusznie zakladane. Log trzymany jest w „System Volume Information”, glównie w postaci plików *.wvr. Oczywiscie uzytkownik nie ma praw dostepu tam i nie ma zwykle po co zagladac.

Wszystkie dyski musza byc spartycjonowane jako GPT a nie MBR i to jest jedna z najczestszych przyczyn „u mnie nie dziala”. Poza tym, dwa dyski na dane powinny miec ten sam rozmiar i dwa dyski na logi – tak samo.

Na maszynach kolejno, zgodnie z podrecznikiem dostepnym na stronach Microsoft, wykonac nalezy:

  • Przygotowac niezawodne polaczenie sieciowe
  • Zezwolic na komunikacje po TCP/445 (SMB) i TCP/5985 (WS-MAN)
  • Zainstalowac na serwerach funkcjonalnosc Storage Replica albo przez Install-WindowsFeature -Name WVR albo przez GUI.
    SR1
    Jak widac, marketing zdazyl juz zmienic nazwe, podczas gdy produkt jeszcze za tym nie nadaza.
  • Wykonac cmdlet z modulu WVR (pisalem juz, ze nie wszyscy nadazaja za nowym nazewnictwem?) New-SRPartnership -SourceComputerName NODE1 -SourceRGName rg01 -SourceVolumeName W: -SourceLogVolumeName L: -DestinationComputerName NODE2 -DestinationRGName rg02 -DestinationVolumeName W: -DestinationLogVolumeName L: -LogSizeInBytes 3gb
  • Poczekac pare chwil. Replikuje sie...

I gotowe. Weryfikacja jest bardzo prosta: Get-WinEvent -LogName Microsoft-Windows-WVR/Admin -max 20 | Format-List. Albo napisane bedzie, ze sie udalo, albo niekoniecznie. Uczuleni na PowerShella moga oczywiscie z GUI eventvwr to samo zobaczyc, ale czasy mamy takie, ze lepiej siasc nad nauka PS niz kombinowac jak by go tu na serwerze nie uzywac. Mozna tez oczywiscie Get-SRGroup zapytac jaka replikacje mamy ustawiona.

To, co w widoczny sposób równiez sie wydarzy, to znikniecie woluminu na serwerze docelowym. Tak ma byc. Replika jest po to, zeby w razie potrzeby ratowac honor admina i pieniadze firmy a nie po to, zeby sobie latwo w zdalnej lokalizacji zagladac na dysk. A juz na pewno nie po to, zeby cokolwiek na nim zapisywac. Póki wszystko dziala, dysk-replika widoczny nie bedzie.

Pora teraz na sprawdzenie replikacji w praktyce. Na dysku zakladamy plik, cos w nim zmieniamy, zapisujemy i wierzymy, ze zadzialalo. To, co na pewno mozemy poobserwowac, to liczniki w Performance Monitor – sluzy do tego grupa liczników Storage Replication Statistics.

SR2

Warto sie z nimi oswoic póki wszystko dziala poprawnie, bo gdy beda potrzebne do zdiagnozowania potencjalnego problemu – lepiej wiedziec, co który z nich oznacza i jak zachowuje sie w codziennej pracy.

Mozemy teraz na przyklad przelaczyc kierunek replikacji. Wtedy dysk zródlowy stanie sie replika i odwrotnie: Set-SRPartnership –NewSourceComputer node2 –SourceRGName rg02 –DestinationComputerName node1 –DestinationRGName rg01

Jezeli chcemy cos zepsuc, to zabijamy NODE1 i dobrze byloby teraz jakos siegnac do naszych danych. W chwili obecnej nie ma do tego prostego mechanizmu, ale to sie zmieni w przyszlosci. Nie warto wiec specjalnie przyzwyczajac sie do obecnie dostepnych metod "dlubanych".

Na koniec garsc uwag luznych, ale chyba wartych zanotowania:

  • Calosc ruchu odbywa sie po SMB3.1. Fakt ten odpowiada na pytanie "co z bezpieczenstwem przesylanych przez WAN danych?" i na wiele innych pytan takich jak na przyklad: "czy mozna uzyc wielu polaczen WAN równoczesnie?".
  • Calosc pieknie dziala z klastrami. Wrecz mozna powiedziec, ze dopiero wtedy rozwija skrzydla. Klastrowe srodowisko jest jednak nieco trudniejsze do zasymulowania w typowym laboratorium typu "Hyper-V na laptopie" i dlatego tutaj tego tematu glebiej nie draze. Z drugiej strony – konsolka Failover Cluster Management pozwala na uzycie czegos na ksztalt GUI do ustawiania replikacji. Ale i tak nie draze. Chetni latwo znajda ciekawy artykul na ten temat.
  • Storage Replica jest relacja A:B. Nie da sie ustawic replikacji A do B i tego samego woluminu z B do C. Z A do B i C równoczesnie – tez nie. Da sie za to technicznie (tylko po co?) ustawic replikacje miedzy dwoma woluminami na jednej maszynie.
  • Za replikacje odpowiada sterownik wvrf.sys, z którym rozmawia serwis WVRService czyli wvrsvc.exe.
  • Parametry pracy Storage Replica (to, co ustawiamy przy pomocy PowerShella) zapisywane sa w HKLM\SOFTWARE\Microsoft\WVR, zwlaszcza w galezi ConfigStore.
  • Dla przypomnienia i podkreslenia: Storage Replica nie uzywa VSS i snapshotów. Kazdy zmieniony blok jest replikowany natychmiast. Snapshoty po prostu zreplikuja sie tak, jak i inne bloki.
  • Bitlocker jest powyzej sterownika odpowiedzialnego za replikacje, co oznacza, ze dane sa replikowane po zaszyfrowaniu. Trzeba tylko upewnic sie, ze w czasie naszej katastrofy mamy potrzebne klucze.
  • Deduplikacja tez jest powyzej replikacji. Wiec tez dziala.
  • Storage Replica nie jest backupem! Skasowane albo nadpisane przypadkiem dane natychmiast kasuja sie/nadpisuja i na replice.
  • Przygotowane rozwiazanie bedzie mozna sprawdzic poleceniem Test-SRTopology. Nie mówi sie o nim jeszcze oficjalnie, ale podobno ma byc. Dostaniemy od niego odpowiedz czy siec jest dobra, czy logi maja odpowiednia wydajnosc i pojemnosc a nawet, sprawdzic ile potrwa pierwsza synchronizacja.

Podsumowujac, musze stwierdzic, ze to naprawde ciekawe rozwiazanie. Wiem, ze niektóre macierze to potrafia, ze sa produkty firm trzecich, ale rozwiazanie wbudowane w OS jest mila rzecza. Produkcyjne uzycie na chwile obecna (koniec 2014) odradzam, ale gdy wyjdzie finalna wersja serwera – dobrze byloby juz znac mechanizmy Storage Replica, miec z nimi pewne doswiadczenie i dokladnie je rozumiec, zeby zastosowac je we wlasciwym miejscu. Samodzielne spróbowanie nie wymaga wiele czasu ani zasobów, wiec zdecydowanie zachecam.

Autor: Grzegorz Tworek [MVP]