Replikacja

Windows Server Technical Preview

Posted on Updated on

Remote Desktop

Dodanie OpenGL oraz OpenCL.

MultiPoint Server jest obecnie dostępny jako rola Windows Server.

Cluster

Upgrade klastra On-Line. Węzeł oparty o Windows Server Technical Preview można podłączyć do obecnego klastra 2012 R2. Po aktualizacji każdego z węzłów podnosimy funkcjonalność klastra do nowej wersji.

Możliwość wykorzystania Azure jako miejsca na dysk witness dla Cluster Quorum.

W przypadku awarii klastra host zostanie odizolowany a wszystkie usługi będą działać dalej.

Storage – QoS

Scale-Out File Server został wzbogacony o funkcjonalność QoS – możemy zarządzać politykami wydajności.

Z poziomu QoS ustalać możemy rezerwę (minimum) oraz limit (maximum) wydajności dla poszczególnych plików VHD lub grup plików VHD.

Storage – Replikacja

Nowa funkcjonalność któa pozwala na replikację całości storage na poziomie bloków, nie zależnie od sprzętu pomiędzy serwerami. Dla zapewnienia integralności danych replikacja odbywa się w trybie synchronicznym.

Funkcjonalność pozwala ponadto na budowę rozproszonych klastrów Hyper-V.

Hyper-V

W przypadku awarii Storage, maszyna wirtualna zostanie przedstawiona w tryb Pauzy, co pozwoli uchronić system przed awarią.

Hyper-V – pliki konfiguracyjne

Zmiana formatu plików konfiguracji maszyny z XML na binarny plik .VMCX oraz .VMRS dla stanu maszyny. Nowy format ma zwiększyć wydajność korzystania z nich oraz zabezpieczyć przed ew. uszkodzeniem. Trochę będzie mi szkoda edycji starych XML – zawsze można było ręcznie wyjść z opresji importując maszynę.

Pocieszające jest, że Hyper-V jest zgodny w dół więc import starego XML się powinien udać.

Hyper-V – snapshoty

Snapshoty realizowane za pośrednictwem VSS wewnątrz systemu gościa.

Hyper-V – Integration Services

W Windows Server Technical Preview nie ma już vmguest.iso – aktualizacje sterowników Hyper-V dla maszyn będą realizowane poprzez usługę Windows Update.

Hyper-V – dodawanie/usuwanie kart swieciowych oraz pamięci RAM.

Można dodawać na gorąco oraz usuwać karty sieciowe oraz pamięć RAM bez restartu systemy gościa. Funkcjonalność działa tylko dla maszyn Generacji 2-giej.

Zmiana ilości pamięci nie wymaga włączonej opcji Dynamic Memory i jest wspierana tylko dla systemów gościa Windows Server Technical Preview.

Hyper-V – Linux Secure Boot

Dodano wsparcie dla Secure Boot dla maszyn Linux. Ubuntu 14.04 lub nowszy, SUSE Linux Enterprise Server 12 są już przystosowane do korzystania z Secure Boot.

Sieć

Dodano rolę Widows Server Gateway, której jedną z funkcjonalności jest możliwość konfiguracji tuneli GRE (Generic Routing Encapsulation).

Podczas dodawania wirtualnych kart sieciowych do maszyny, ta sama nazwa będzie widoczna wewnątrz systemu gościa.

 

Hyper-v replikacja – zmiany w konfiguracji maszyn

Posted on

Jeśli korzystacie z Hyper-V to zakładam, że korzystacie też z replikacji maszyn. To jest świetna funkcja do zapewnienia automatycznie realizowanej kopii naszych środowisk np. w zapasowym centrum danych. Samo rozwiązanie jest łatwe w konfiguracji i w większości przypadków nie sprawia problemów. Po prostu działa 🙂

Są jednak dwie rzeczy o których trzeba pamiętać:

  1. Zmiana konfiguracji maszyny wzorcowej nie jest replikowana do kopii. Co to oznacza? Jeśli zmodyfikujemy ilość CPU, pamięci, kart sieciowych itp w źródłowej maszynie – musimy analogiczne zmiany wprowadzić w kopii.
  2. Jeśli zmienimy rozmiar dysków VHDX/VHD na maszynie wzorcowej – musimy też zmienic rozmiar dysków na replice.

W/w sytuacje są do opanowania (o ile nie dotyczą zmian dla setek serwerów jednocześnie), jest jednak jedna sytuacja, której tak nie rozwiążemy: Dodanie nowego dysku do maszyny wzorcowej. Tu jest inne rozwiązanie

  1. Wyłączenie replikacji
  2. Skopiowanie nowego dysku do repliki (lub jego utworzenie ręczne jeśli jest pusty)
  3. Ponowne uruchomienie replikacji wykorzystując znajdujące się na replice dyski jako bieżącej kopii.

Tę operację musimy koniecznie przeprowadzić w trybie off-line.

Zapasowe centrum danych w Azure

Posted on Updated on

Microsoft uruchomił publicznie usługę replikacji maszyn do Azure jako zapasowe centrum danych. Usługa nie jest droga – utrzymanie pojedynczej maszyny kosztuje od 14 EUR (limit do 100GB na maszynę).

Usługa pozwala na realizację zapasowego centrum danych na wypadek awarii naszego własnego serwera lub klastra. Replikacja maszyn może zostać zrobiona całkowicie online, bez przerwy w działaniu środowiska głównego.

Jest to dobra alternatywa dla firm, których nie stać na wynajem serwerów w zapasowym centrum danych lub choćby zakup rezerwowych serwerów.

Zmiana rozmiaru dysków na replikowanych maszynach

Posted on Updated on

Windows Server 2012R2 wprowadził przydatną funkcję, która umożliwia zmianę rozmiaru dysków (VHDX) w locie – bez restartu maszyny.

Co jeśli maszyna jest replikowana. Po zmianie rozmiaru dysku replika się rozjedzie 😦

Rozwiązanie:

  1. Zmieniamy rozmiar dysku VHDX na serwerze master
  2. Zmieniamy rozmiar partycji logicznej na wirtualnej maszynie np. narzędziem Disk Management
  3. Zmieniamy rozmiar dysku VHDX na serwerze repliki.
  4. Przywracamy replikację i dyski zostaną zsynchronizowane.

 

 

Hyper-V Replikacja pomiędzy różnymi domenami

Posted on Updated on

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:

  1. Serwer Repliki musi mieć uruchomioną replikację opartą o autoryzację SSL
  2. 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.
  3. 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).

  1. Otwieramy okno CMD (nie PowerShell)
  2. 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
  3. 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
  4. Jeśli istnieje taka potrzeba możemy utworzyć drugie CA dla drugiego hosta w analogiczny sposób
  5. 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
  6. 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

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ę.