Replikacja maszyn Hyper-V w Windows 2012/2012R2 to jeden z tych „killing features”, który może wiele osób przekonać co wirtualizacji Microsoftu. Zapewnia nam niemal te same możliwości co sprzętowa asynchroniczna replikacja macierzy bez potrzeby ponoszenia dodatkowych kosztów. Jest dostępna również w darmowej wersji Hyper-V Server.
Zasada działania
Działanie replikacji jest dość proste. Replikacja to rozwinięcie innych rozwiązań systemu Windows Server 2012 takich jak m.in VSS czy możliwość scalania snapshotów online.
Maszyna źródłowa rejestruje historię zmian w plikach VHD/VHDX i co 5 minut przesyła je do serwera repliki, gdzie są one dogrywane do pliku logów. Jeśli zdecydujemy by przechowywać dodatkowe kopie stanu maszyn (co godzinę) to co godzinę na replice zmiany zostaną wgrane do plików VHD/VHDX i jako takie zapisane na dysku.
W Windows 2012R2 Microsoft wprowadził parę modyfikacji; po pierwsze możemy określić okres synchronizacji na 30 sekund, 5 lub 15 minut, ponadto przy przechowywaniu dodatkowych kopii maszyn na replice system nie przechowuje całych obrazów VHD a jedynie jedną + skonsolidowany co godzinę plik logów. Dzięki czemu trzymanie nawet 24 kopii typowych systemów zajmie mam 120-150% rozmiaru danych źródłowych.
Autoryzacja
Replikacja może być realizowana pomiędzy serwerami jak i klastrami. Ze względu na to iż przy klastrach jest to nieco bardziej złożone dla poniższego przykładu opiszę to dla replikacji hostów bez klastra.
Aby można było zrepliować maszyny z hosta A do hosta B to musi nastąpić autoryzacja. Microsoft przewidział tu dwie możliwości:
- Kerberos – autoryzacja oparta o autoryzację w Active Directory. Aby z niej skorzystać oba hosty muszą móc autoryzować się wspólnie w AD, można to osiągnąć tworząc np. dwukierunkowy węzeł zaufania pomiędzy lasami.
- Certyfikat – rozwiązanie, którym się zajmiemy polegające na autoryzacji certyfikatami SSL. Jest to o tyleż bezpieczne, że umożliwia replikację np. z mniej zaufanych środowisk – np. systemów naszego klienta.
Aby autoryzacja oparta o certyfikaty SSL zachodziła wymagane jest spełnienie następujących warunków:
- Serwer Repliki musi mieć uruchomioną replikację opartą o autoryzację SSL
- Do celów autoryzacji musi zostać użyty certyfikat, który zgodny jest z nazwą serwera repliki (w przypadku klastra musi być to nazwa usługi klastra Repliki), nie może być nim certyfikat Self-Signed, musi być zaufany dla drugiego serwera. Czyli albo jest wystawiony przez zaufane centrum certyfikacji, albo certyfikat publiczny jakim został podpisany musi być wgrany do serwera wzorcowego.
- W przypadku serwera wzorcowego sytuacja jest analogiczna – tez musi posiadać certyfikat zgodny z nazwą, nie Self-Signed i pochodzący z zaufanego centrum CA.
Przygotowanie certyfikatów bez usługi CA
Pierwszym zadaniem jest przygotowanie certyfikatów dla usług. Jeśli mamy wdrożone własne centrum certyfikacji to mamy ułatwione zadanie, jeśli nie to musimy sobie wygenerować komplet certyfikatów.
W tym celu polecam instalację paczki z OpenSSL który umożliwi łatwe tworzenie i zarządzanie certyfikatami SSL.
http://slproweb.com/products/Win32OpenSSL.htmlWystarczy nam paczka Win64 OpenSSL Light + Visual C++ 2008 Redistributables (x64).
- Otwieramy okno CMD (nie PowerShell)
- Wpisujemy adres ścieżki do konfiguracji OpenSSL.
set OPENSSL_CONF=C:\OpenSSL-Win64\bin\openssl.cfg
set path=C:\OpenSSL-Win64\bin;%path%mkdir demoCA mkdir demoCA\newcerts type NUL > demoCA\index.txt type NUL > demoCA\serial - Generujemy sobie certyfikat CA którym będziemy podpisywać certyfikat dla serwera i który zainstalujemy na drugim serwerze.
- Tworzymy klucz dla certyfikatu CA
openssl.exe genrsa -out Host1-CA-key.txt 4096
- Tworzymy żądanie certyfikat CA, w polu Common Name podajemy nazwę naszego certyfikatu CA. Np. Host1-CA
openssl.exe req -new -key Host1-CA-key.txt -out Host1-CA.csr
- Podpisujemy żądanie certyfikatu CA. Certyfikat będzie mieć 10 lat ważności.
openssl.exe x509 -req -days 3650 -in Host1-CA.csr -signkey Host1-CA-key.txt -out Host1-CA.crt
- Tworzymy paczkę dystrybucji CA (PKCS12). Paczkę zabezpieczamy hasłem.
openssl.exe pkcs12 -export -in Host1-CA.crt -inkey Host1-CA-key.txt -out Host1-CA.p12
- Tworzymy klucz dla certyfikatu CA
- Jeśli istnieje taka potrzeba możemy utworzyć drugie CA dla drugiego hosta w analogiczny sposób
- Tworzymy certyfikaty dla hostów
- Tworzymy klucz dla certyfikatu Hosta
openssl.exe genrsa -out Host1-key.txt 4096
- Tworzymy żądanie certyfikat Hosta, w polu Common Name podajemy nazwę naszego serwera (nazwę Netbios + domenę) Np. HOST1.contoso.com
openssl.exe req -new -key Host1-key.txt -out Host1.csr
- Podpisujemy żądanie certyfikatu Hosta. Ważność certyfikatu np. 10 lat. Certyfikat podpisujemy kluczem CA.
openssl.exe ca -out Host1.crt -in Host1.csr -keyfile Host1-CA-key.txt -cert Host1-CA.crt -days 3065
- Tworzymy paczkę dystrybucji Certyfikatu Hosta (PKCS12). Paczkę zabezpieczamy hasłem.
openssl.exe pkcs12 -export -in Host1.crt -inkey Host1-key.txt -out Host1.p12
- Tworzymy klucz dla certyfikatu Hosta
- Gotowe certyfikaty importujemy do magazynu certyfikatów.
- Do hosta1 i Hosta2 importujemy Certyfikaty CA. Jeśli generowaliśmy dwa osobne CA – to importujemy oba.
$pwd = ConvertTo-SecureString -String "nasze_haslo_certyfikatu_CA" -AsPlainText -Force Import-PfxCertificate .\Host1-CA.p12 -CertStoreLocation Cert:\LocalMachine\AuthRoot -Password $pwd
- Do hostów importujemy dedykowane dla nich certyfikaty
$pwd = ConvertTo-SecureString -String "nasze_haslo_certyfikatu_Hosta" -AsPlainText -Force Import-PfxCertificate .\Host1.p12 -CertStoreLocation Cert:\LocalMachine\My -Password $pwd
- Do hosta1 i Hosta2 importujemy Certyfikaty CA. Jeśli generowaliśmy dwa osobne CA – to importujemy oba.
Przygotowanie certyfikatów z usługą CA
Jeśli mamy własne centrum certyfikacji to powinniśmy mieć też gotowe certyfikaty maszyn. Można to sprawdzić otwierając konsolę mmc i ładując przystawkę certyfikatów lokalnych komputera.
W sekcji Personal powinien być certyfikat zgodny z nazwą naszego hosta. W kolumnie Intended Purposses powinny być pozycje: Server Authentication oraz Client Authentication
Wyłączenie sprawdzania listy wykluczeń certyfikatów
Ze względu na fakt iż posługujemy się certyfikatami generowanymi przez lokalne CA to serwery nie mają możliwości dostępu do listy wykluczeń certyfikatów (CRL). Aby wyłączyć ten wymóg należy po obu stronach dodać do rejestru Windows następujący klucz:
reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\FailoverReplication" /v DisableCertRevocationCheck /d 1 /t REG_DWORD /f reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\Replication” /v DisableCertRevocationCheck /d 1 /t REG_DWORD /f
Ustawienie DNS
Aby zdalny host mógł dostać się do hosta z replikami musi łączyć się po nazwie zgodnej z nazwą użytego certyfikatu, czyli po nazwie DNS z domeną AD. To rodzi pewien problem, bowiem jeśli serwery są w różnych lokalizacjach i nie mamy połączenia VPN to się nie zobaczą.
Najprostsze rozwiązanie – to:
- Wystawienie portów 443 serwera repliki na jakiś adres publiczny (poprzez NAT)
- Ustawienie na hoście głównym wpisu DNS (albo na serwerze DNS albo w pliku hosts), dla nazwy docelowej serwera i adresu IP pod jakim jest on wystawiony.
Czemu jest to istotne. Autoryzacja SSL w replikacji oparta jest o certyfikaty. Konieczne jest zatem by certyfikat na serwerze repliki miał nazwę zgodną z tą jakiej wymaga serwer źródłowy. W innym przypadku usługa nie będzie działać.
Ustawienie Firewall
Na serwerze w firewall dla usługi Hyper-V Replication SSL otwieramy połączenie dla wszystkich połączeń.
Ustawienie replikacji
Konfiguracja replikacji w tym przypadku niczym się nie różni od replikacji w ramach tego samego AD. Podajemy adres docelowy serwera z replikami (nazwę Netbios+Domenę AD), wybieramy autoryzację SSL i port 443. i już.
Samo łączenie może trwać nieco dłużej, bowiem serwer najpierw próbuje skontaktować się z docelowym serwerem na porcie UDP 143, ale jego otwarcie nie jest niezbędne.
Replikacja odtwrotna
Jeśli chcemy zachować możliwość replikacji z powrotem, to pozycje związane z DNS i firewall realizujemy też w drugą stronę.
1. Replikacja, co: 30s, 5min, 15min.
2. Silnik replikacyjny odkłada zmiany (operacje zapisu) na dysku do plików HRL(Hyper-V Replica Log, coś podobnego do logów transakcyjnych sql). VSS używany jest tylko, gdy zażyczymy sobie jego wykonywanie i przesyłanie, domyślnie wyłączony. Funkcja snapshotów wykorzystywana jest na serwerze zapasowym do scalania i odpalaniu przełączeniu lub testów repliki.
3. Na Windowsie nie ma sensu używać OpenSSL i doinstalować dodatkowe pakiety, jeśli możemy użyć makecert w postaci jednego nieinstalowanego exe. Drugi plus mniej poleceń.
4. Brakuje wpisu reg add „HKLMSOFTWAREMicrosoftWindows NTCurrentVersionVirtualizationReplication” /v DisableCertRevocationCheck /d 1 /t REG_DWORD /f
5. DNS nie jest potrzebny, wystarczy wpis w hosts i dobrze dodane poświadczenia.
PS. Wygląd bloga czytelniejszy 🙂
Ad 1. Faktycznie – mój bład. Nie mniej jednak szkoda, że nie ma wartości wyższych 🙂
Ad 2. Dzięki za wyjaśnienie. Aczkolwiek na zapasowym jest coś innego – pliki dodatkowych godzinnych kopii mają rozszerzenie HRU i to raczej są logi odwrotne, bo sam plik VHD/VHDX jest taki jak ostatnia kopia. Te plik zawierają logi pozwalające na odtworzenie stanu VHD/VHDX z danej godziny.
Ad 3. Przyzwyczajenie z Linux. makecert nie znałem – muszę sprawdzić.
Ad 4. U mnie działał ten pierwszy wpis – aczkolwiek realizowałem replikację tylko w jedną stronę i jej celem była migracja kilku maszyn klienta tak by przerwa była minimalnie krótka 🙂
Ad 5. Przecież napisałem 🙂 ja posłużyłem się wpisami do hosts, bo to rozwiązanie tymczasowe – osobiście tego nie lubię, bo wole mieć jedno centralne miejsce z powiązaniami nazwaIP… czyli DNS. Od paru lat staram się „tępić” używanie IP dla usług, i korzystanie wyłącznie z DNSów 🙂
Tak na marginesie – ten element wygląda na wymagający jeszcze dopieszczenia przez MS, tak by dało się np. użyć certyfikatu z inną nazwą np. normalnej domeny DNS, jak w IIS :)W
Wygląd odświeżyłem, ale brak mi czasu by w końcu zrobić bloga na swoim CMSie i po swojemu.. WordPress ma jednak parę ograniczeń 🙂
Ad 2. W 2012R2 wprowadzano undo log dla poprawy wydajności, a w 2012 był użyty mechanizm snapshotów, jak dobrze pamiętam diagramy.
Ad 5. Dziś już labu nie chce mi się odpalać żeby potwierdzić, ale możesz użyć opcji MakePrimary w netdom, żeby nadać alternatywną nazwę fqdn dla hosta.
Do normalnych usług DNS tak, ale z punktu widzenia procesu DR wykorzystanie pliku hosts ma parę zalet, np replikacja nie jest zależna od poprawności konfiguracji dns 😉
Ad 2. Zgadza się w Win 2012 są snapshoty. Rozwiązanie z 2012R2 jest fajne bo zajmuje mniej miejsca, aczkolwiek to stare pozwalało na przywrócenie stanu maszyny nawet jeśli padł nam np. host. Snapshoty można było zwinąć ręcznie. Do HRU nie znalazłem żadnego narzędzia.
Ad 5. Próbowałem używać certyfikatów, które miały dodatkowe nazwy dodane – ale to niestety nie działa 🙁
Co do DNS to fakt – ale poprawność działania i konfiguracji DNS jest kluczowa również dla innych systemów, to wg. mnie jeden z ważniejszych systemów w środowisku.
Witam
Troszkę nie poszło mi z generowaniem certyfikatów opisaną przez Ciebie metodą. Próbowałem różych wersji openssl, ale nie udało mi się. Poszukałem więc analogicznego sposobu tworzenia certyfikatów na innych blogach i poniżej wklejam sposób. Może komuś się przyda, u mnie poszło.
Konfiguracja 2 x HyperV 2016. Serwer01 i Serwer02
Pobieramy Microsoft Windows SDK dla Windows 10 – lub innej wersji oczywiście, zależnie jaką posiadamy. To się zainstaluje i możemy wtedy użyć programu makecert.exe.
Plik znajduje się u mnie akurat C:\Program Files (x86)\Windows Kits\10\bin\10.0.15063.0\x86 , ale na forum podają inną lokalizację, więc może będzie trzeba jak w moim przypadku poszukać.
Plik makecert.exe kopiujemy na oba serwery do folderu c:\cert. Na oba, ba ja akurat robiłem replikację w obie strony. Jak ktoś robi w jedną stronę to wystarczy na serwer źródłowy skopiować.
Tworzymy główny certyfikat:
makecert -pe -n „CN=Serwer01RootCA” -ss root -sr LocalMachine -sky signature -r „Serwer01RootCA.cer”
Tworzymy certyfikat maszyny:
makecert -pe -n „CN=Serwer01” -ss my -sr LocalMachine -sky exchange -eku 1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2 -in „Serwer01RootCA” -is root -ir LocalMachine -sp „Microsoft RSA SChannel Cryptographic Provider” -sy 12 Serwer01.cer
Eksportujemy certyfikat z kluczem prywatnym. Na blogu znalazłem tylko opcję przy pomocy konsolki certyfikatów lokalnego serwera. HyperV nie ma gui, więc pozostał wiersz polecenń. Próbowałem też wyeksportować przy pomocy konsolki mmc, którą wpiąłem się do serwera Serwer01, ale takiej opcji nie miałem. Podobnie nie mogłem zaimportować certyfikatu w kolejnym kroku.
Pewnie są lepsze sposoby, ale ja tych certyfikatów aż tak nie ogarniam, więc użyłem poniższego sposobu.
Przy pomocy wspomnianej konsolki mmc – certyfikaty – konto komputera – wpinamy się do serwera źródłowego. W moim przypadku Serwer01. Certyfikaty osobiste i otwieramy wygenerowany certyfikat – u mnie Serwer01.
W zakładce Szczegóły zaznaczamy numer seryjny i kopujemy sobie do notatnika. Kasujemy spacje i możemy przygotować polecenie, które odpalamy na serwerze źródłowym:
certutil -exportPFX -p a my NUMER_SERYJNY Serwer01.pfx
literka „a” w poleceniu to hasło. Można być bardziej twórczym 🙂
Kopiujemy wyeksportowany klucz (Serwer01.pfx) na serwer docelowy. I importujemy go w PS poleceniami:
$pwd = ConvertTo-SecureString -String a -AsPlainText -Force
Import-PfxCertificate .\Serwer01.pfx -CertStoreLocation Cert:\LocalMachine\My -Password $pwd
Na koniec warto otworzyć porty na firewallach:
netsh advfirewall firewall add rule name=”Https Replica in” dir=in protocol=TCP localport=443 action=allow
W drugą stronę analogicznie. Działa aż miło. W moim przypadku oba serwery były w tej samej sieci lokalnej.