Tip:
Highlight text to annotate it
X
Kolejnym mechanizmem, na który chciałbym zwrócić uwagę, jest mechanizm replikacji maszyn wirtualnych.
Jest to absolutnie nowa funkcjonalność.
Do tej pory nie mieliśmy z nią do czynienia we wcześniejszej wersji Hyper – V.
W ramach omawiania mechanizmu replikacji opowiem: jak przygotować środowisko do replikacji maszyn wirtualnych,
jak ten mechanizm włączyć, jak przetestować czy działa poprawnie,
oraz jak wykonać operację planowanej awarii czy jak skorzystać z mechanizmu „planned failover”,
a jak zareagować na mechanizm „unplanned failover” na sytuacje, kiedy awaria jest nieplanowana.
Na co nam pozwala replikacja maszyn wirtualnych?
Przede wszystkim pozwala na przesyłanie maszyny wirtualnej z jednego hosta do drugiego.
Czyli maszyna jest uruchomiona na jednym hoście, na jednym serwerze, natomiast jej stan jest replikowany do hosta znajdującego się gdzie indziej,
najlepiej oczywiście, w zdalnej lokalizacji, innej lokalizacji fizycznej tak,
żeby w przypadku awarii i uszkodzenia fizycznego czy fizycznej awarii jednej lokalizacji,
była możliwość uruchomienia tych maszyn wirtualnych w lokalizacji zdalnej.
Replikowana jest cała maszyna.
Co więcej, w momencie, kiedy definiujemy taką replikację,
mamy także możliwość określenia, jak często mają być tworzone i replikowane Snapshoty takiej maszyny wirtualnej,
co pozwala nam na stworzenie kopii odroczonej w czasie.
W sytuacji awarii możemy określić, że maszyna wirtualna ma być podniesiona z określonego punktu na osi czasu.
Co jeżeli chodzi o przygotowanie takiej maszyny wirtualnej i infrastruktury do mechanizmu replikacji?
Jak skonfigurować środowisko, żeby mechanizm replikacji działał poprawnie?
Przede wszystkim należy zadbać o to, aby na serwerze,który będzie odbierał ruch replikacyjny,
był odpowiednio skonfigurowany Firewall.
Zaraz będzie demonstracja, także pokażę na co należy zwrócić uwagę, gdzie to skonfigurować.
Należy także uwzględnić czy serwer docelowy nie jest przypadkiem członkiem klastra.
Jeżeli maszyna docelowa, do której ma być wysyłana replikacja, jest częścią klastra
należy na klastrze zainstalować rolę Hyper – V Replica Broker tak,
aby do tego węzła można było taki ruch replikacyjny wysyłać.
Kolejna kwestia to szyfrowanie replikacji.
I tutaj, w sytuacji, kiedy decydujemy się na konfigurowanie mechanizmu replikacyjnego,
mamy możliwość wybrania, czy replikacja ma się odbywać po protokole HTTP
– wtedy mamy uwierzytelnianie Kerberosem –
czy po protokole HTTPS.
Wtedy jeżeli mamy protokół HTTPS, mamy także replikację szyfrowaną.
W przypadku uwierzytelniania tylko i wyłącznie Kerberosem,
replikacja odbywa się po porcie 80 i ta transmisja nie jest szyfrowana.
Kolejna kwestia warta rozważenia to mechanizm czy sytuacja, jak zainicjować replikację.
W przypadku dużej liczby maszyn, albo w przypadku dużych maszyn wirtualnych
będzie przesyłana przez sieć spora ilość informacji.
W momencie, kiedy definiujemy mechanizm replikacyjny, możemy określić jak ta początkowa replikacja ma się odbyć
– czy całe maszyny wirtualne mają być przesłane przez sieć
czy może mamy już odtworzoną, wyeksportowaną i zaimportowaną na serwerze docelowym maszynę wirtualną
i ten stan chcemy użyć jako stan początkowy.
Dzięki temu, oczywiście, zostaną przesłane tylko różnice w maszynie wirtualnej od momentu, kiedy była wyeksportowana.
Mamy także możliwość przeniesienia tych informacji na jakimś dysku, nośniku tak,
żeby ich nie przesyłać przez sieć.
I dodatkowo, tak jak wspomniałem, jest możliwość tworzenia punktów przywracania Snapshotów takiej maszyny wirtualnej tak,
aby można było przywrócić tę maszynę wirtualną z określonego punktu na osi czasu.
Jeżeli chodzi o włączanie mechanizmu replikacji, należy skonfigurować serwer docelowy,
czyli ten, który będzie odbierał ruch replikacyjny.
Tu wybieramy, jak ma przebiegać uwierzytelnianie – czy po protokole Kerberos, czy po protokole SSL.
Dzięki temu, jeżeli mamy protokół SSL, będziemy mieli także możliwość szyfrowania transmisji.
Niestety, oczywiście, wymaga to zaimplementowania infrastruktury klucza publicznego
i zadbania o to, aby certyfikaty serwerów były traktowane jako wzajemnie zaufane.
Kolejny mechanizm, który pozwala nam także zabezpieczyć transmisję ruchu replikacyjnego, to jest autoryzacja.
Czyli możemy określić np. od jakich serwerów nasz host docelowy może otrzymywać ruch replikacyjny.
W momencie, kiedy dokonamy konfiguracji serwera docelowego dla konkretnej maszyny wirtualnej, musimy włączyć taki ruch replikacyjny.
W chwili, kiedy go włączymy, rozpocznie się proces synchronizacji danych pomiędzy serwerami.
Co jest istotne?
Ponieważ mechanizm pozwala nam także na nadmiarowość, na „failover”,
możemy się zdecydować na zdefiniowanie replikacji powrotnej jako opcję już na tym etapie.
Będzie to przydatne w takiej sytuacji, kiedy właśnie nastąpi awaria
i maszyna zostanie uruchomiona przez nas w lokalizacji zdalnej.
Należy zadbać o to, żeby działająca właśnie maszyna w lokalizacji zdalnej replikowała swoje zmiany do swojej lokalizacji pierwotnej,
czyli trzeba zadbać o zdefiniowanie replikacji powrotnej.
W momencie, kiedy ta replikacja jest już zdefiniowana,
wypadałoby sprawdzić czy zdefiniowana jest poprawnie i czy działa poprawnie.
We właściwościach maszyny wirtualnej na serwerze docelowym jest polecenie „test failover...”,
które pozwala nam na wybranie punktu przywracania oraz na uruchomienie repliki takiej maszyny do celów testowych.
Ta replika będzie się nazywała tak, jak maszyna z dodatkiem „test”.
Taką replikę możemy podnieść, zweryfikować czy maszyna działa poprawnie,
czy aplikacje wewnątrz takiej maszyny wirtualnej działają poprawnie,
czy można ją zrestartować, zamknąć.
Także w ten sposób możemy zweryfikować poprawność działania naszego środowiska.
W sytuacji, kiedy zakończymy testy, wybieramy z menu kontekstowego maszyny wirtualnej polecenie „stop test failover”
i ta testowa maszyna jest usuwana.
W sytuacji, kiedy pojawia się „planned failover”, czyli wiemy, że chcemy przełączyć maszynę wirtualną pomiędzy lokalizacjami,
to tak jak powiedziałem wstępnie to, co poprzednio było krokiem opcjonalnym, jest koniecznością – musimy skonfigurować najpierw replikację powrotną.
Kreator nie pozwoli nam na przełączenie maszyny do zdalnej lokalizacji,
dopóki replikacja powrotna nie jest zdefiniowana.
Żeby to wykonać, trzeba serwer źródłowy też skonfigurować tak, aby mógł otrzymywać ruch replikacyjny.
Kolejnym krokiem jest zatrzymanie maszyny wirtualnej i przeniesienie operacji na maszynę wirtualną uruchomioną w lokalizacji docelowej.
W sytuacji, kiedy wystąpi nieplanowana awaria,
musimy uruchomić maszynę na serwerze docelowym
i skonfigurować replikację powrotną tak,
aby ta maszyna zaczęła replikować swój stan do serwera pierwotnego uruchomionego już ponownie po awarii.
Jak te mechanizmy skonfigurować?
Przede wszystkim trzeba dokonfigurować odpowiednie komponenty w maszynie docelowej.
Tutaj także mam już te opcje skonfigurowane we właściwościach serwera Hyper – V.
W opcji „Replica Configuration” trzeba przede wszystkim znowu włączyć mechanizm tak,
aby umożliwiał przyjmowanie ruchu replikacyjnego.
Wybieramy za pomocą jakiego mechanizmu ma to być zabezpieczone.
W moim przypadku jest to Kerberos.
Dodatkowo możemy określić z jakich serwerów ta replika może być wysyłana do mojego środowiska.
To są ustawienia, które muszę skonfigurować w momencie definiowania
czy przygotowywania hosta do otrzymywania ruchu replikacyjnego.
Dodatkowo należy pamiętać o tym, żeby w konsoli Firewalla,
na serwerze mającym otrzymywać ruch replikacyjny, w regułach na ruch przychodzący
włączyć zezwolenie na Hyper – V Replica HTTP Listener.
Ta funkcjonalność musi być włączona.
Oczywiście, jeżeli decydujemy się na replikację po protokole HTTPS,
to też należy włączyć odpowiednią regułę na Firewallu.
W momencie, kiedy serwer docelowy mamy skonfigurowany na serwerze pierwotnym,
możemy wybrać maszynę wirtualną i w menu kontekstowym włączyć replikację.
Tutaj już mam maszynę wirtualną, na której ta replikacja jest włączona.
Dołożę szybko nową maszynę wirtualną, określę rozmiar pamięci,
określę z jakiego Interfejsu sieciowego ta maszyna ma korzystać, wybiorę dysk.
Tu mam też przygotowany dysk Initial Replica.
Muszę mu zdjąć atrybut „Read only”.
W związku z tym wybierzemy ten dysk.
Dołożyliśmy maszynę, dla której chcemy włączyć mechanizm replikacji.
Pojawia się opcja „Enable Replication”, uruchamia się Kreator, który pozwala nam na określenie serwera docelowego.
W moim przypadku, to będzie NODE – B.
Ponieważ odpowiednie komponenty na serwerze docelowym pozwalające na replikację
oraz odpowiednie wyjątki na Firewallu zostały już skonfigurowane,
ustawienia tutaj zostały zaczytane po protokole WMI.
Na chwilę obecną, mogę określić jakie dyski mają być dla tej maszyny wirtualnej replikowane do zdalnej lokalizacji.
Tutaj mamy jeden dysk twardy, więc dużego wyboru nie ma.
I teraz pytanie, czy chcemy korzystać z historii odzyskiwania
czy chcemy tworzyć punkty odzyskiwania czy nie.
Mogę pozwolić, że mają być tworzone 4 punkty.
Dodatkowo mogę zdecydować się na tworzenie punktów, które pozwolą na utrzymanie spójności aplikacji wewnątrz maszyny wirtualnej.
Wspomniane przeze mnie miejsce, gdzie mogę zdecydować w jaki sposób ma się odbywać początkowa replikacja,
czyli czy ma być przesłana przez sieć, nośnik zewnętrzny czy może wykorzystam istniejącą maszynę wirtualną.
Jeżeli zdecyduję się na konfigurację w ten sposób, mogę zakończyć Kreator.
Włączona jest replikacja dla tej maszyny.
Jeżeli popatrzymy na „Replication Health”, widzimy ilość danych, która musi zostać zreplikowana.
Jak widać, chwilę to trwa.
Proszę bardzo, ilość danych zaczęła ubywać.
Możemy sprawdzić, że faktycznie „Initial Replica” pojawiła się na drugim węźle.
Natomiast tej maszyny nie jesteśmy jeszcze w stanie uruchomić.
Ona się musi cała najpierw zreplikować.
Jeżeli replikacja się zakończy, tak jak wspomniałem, dobrą praktyką jest przetestowanie czy z repliką jest wszystko w porządku.
Proszę zwrócić uwagę, ta maszyna już od pewnego czasu się replikuje, pojawiają się punkty przywracania.
Natomiast w menu kontekstowym, w menu „Replication” mam opcję „test failover”.
Mogę wybrać punkt przywracania, z którego chcę skorzystać
i zdecydować się na testowanie mechanizmu „failover”.
Pojawiła się maszyna o nazwie „Replica test”.
Tę maszynę jestem w stanie w tej chwili uruchomić, przetestować jej działanie.
W momencie, kiedy chcę zakończyć testy, wybieram polecenie „stop test failover”, „Tak”.
Maszyna jest usuwana.
Sprawdźmy, jak nasza replikacja.
Proszę bardzo, ok. 6,5 GB danych zostało jeszcze do zreplikowania.
I kolejny mechanizm – mechanizm planowany „failover”, planowane przełączenie.
System zwraca nam uwagę na to, jakie wymogi muszą zostać spełnione.
Jeżeli zdecydujemy się na mechanizm „failover”, przede wszystkim dostaniemy informację o tym,
że najpierw należy wyłączyć maszynę wirtualną oraz zadbać o to, żeby była zdefiniowana replikacja powrotna,
czyli to, o czym przed chwilą wspominałem.
Kolejna kwestia, jeżeli chodzi o Hyper – V, to rozwiązania wysokiej dostępności,
czyli co nowego pojawiło się w technologiach klastrowych.
Najpierw powiemy o opcjach wysokiej dostępności oraz o nowościach w usłudze klastra dla Hyper – V.
Jeżeli chodzi o opcję wysokiej dostępności, mamy do wyboru trzy mechanizmy. Są to: Host Clustering, Guest Clustering i Network Load Balancing.
Host Clustering jest to mechanizm, który umożliwia Wam klastrowanie maszyn, hostów,
wewnątrz których będą potem uruchamiane maszyny wirtualne.
Buduję normalny klaster w oparciu o Server 2012 i na takiej usłudze, takim klastrze,
uruchamiam maszynę wirtualną, która funkcjonuje jako maszyna wysokodostępna,
czyli w przypadku awarii jest przełączana pomiędzy węzłami klastra.
Zaletą tego rozwiązania jest fakt, iż wewnątrz maszyny wirtualnej mogą być uruchomione aplikacje,
które nie muszą być aplikacjami świadomymi wysokiej dostępności.
Drugą opcją jest Guest Clustering, czyli mechanizm pozwalający na klastrowanie już samych maszyn wirtualnych.
Uruchamiamy maszyny wirtualne, kilka maszyn wirtualnych w obrębie hosta
i te maszyny wirtualne spinamy w rozwiązanie wysokiej dostępności.
To już powoduje, że aplikacje działające na tych maszynach wirtualnych
muszą być aplikacjami klastrowymi,
same sobie radzić z przełączaniem się pomiędzy węzłami klastra, być świadome rozwiązań klastrowych.
Trzecia opcja to mechanizm NLB (Network Load Balancing) wykorzystywany najczęściej w przypadku serwerów webowych,
czyli budujemy klaster NLB i np. w jego obrębie hostujemy maszyny wirtualne, które obsługują ruch webowy.
Co jeżeli chodzi o nowości w klastrze, które pojawiły się ze względu na usługę Hyper – V?
Przede wszystkim, na chwilę obecną mamy wsparcie do 4000 maszyn wirtualnych pracujących w obrębie jednego klastra.
Tak jak wspominałem wcześniej, w momencie kiedy omawiałem mechanizm Live Migration,
mamy możliwość zlecenia migracji wielu maszyn wirtualnych naraz.
Sami jesteśmy w stanie zdecydować, ile maszyn wirtualnych równocześnie ma się migrować.
Natomiast, korzystając np. z Controla, możemy zaznaczyć więcej niż jedną maszynę wirtualną.
Do tej pory tego nie mieliśmy.
Jeżeli decydowaliśmy się na przemigrowanie więcej niż jednej maszyny wirtualnej,
musieliśmy każdej pojedynczo wydać polecenie migracji.
Kolejna kwestia to obsługa priorytetów dla maszyn wirtualnych w obrębie klastra,
co nam pozwala na określenie m.in. tego, w jakiej kolejności maszyny wirtualne mają być uruchamiane np. po restarcie,
a także jaki jest priorytet przydzielania zasobów dla maszyn wirtualnych.
Maszyny z wyższym priorytetem są w stanie dostać więcej zasobów
niż maszyny z niższym priorytetem np. ilość przydzielonej pamięci.
Maszyna z niższym priorytetem zwolni pamięć tak,
aby maszyna z wyższym priorytetem, jeżeli potrzebuje więcej tej pamięci, ją dostała.
Kolejną nowością jest możliwość przechowywania maszyn wirtualnych na klastrze SMB.
Czyli, już sam zasób sieciowy, wewnątrz którego będą przechowywane pliki dla maszyn wirtualnych,
jest dostępny w obrębie usługi klastrowej.
Jeszcze jedna istotna kwestia.
Mianowicie, migracja istniejących rozwiązań wysokiej dostępności
zbudowanych w oparciu np. o Server 2008 czy 2008 R2 do klastrów zbudowanych w oparciu o Server 2012.
Mamy dwa sposoby przemigrowania istniejących rozwiązań:
pierwszy sposób to wykorzystanie wbudowanego w usługę klastrową Kreatora do migracji zasobów klastra Cluster Migration Wizard
– tutaj wspieranymi systemami operacyjnymi są minimalnie Windows 2008 z Service Packiem 2,
albo 2008 R2 z Service Packiem 1 oraz, oczywiście, Server 2012.
Jak taką migrację wykonać?
Uruchamiamy nowe środowisko w oparciu o Server 2012,
budujemy Klaster i na Klastrze 2012 uruchamiamy Kreator migracji zasobów starego klastra,
a następnie po zakończeniu pracy Kreatora, kiedy zasoby są przemigrowane,
postępujemy zgodnie z raportem, który nakazuje wykonanie kolejnych kroków,
czyli wyłączenie maszyn wirtualnych na starym klastrze i przepięcie zasobów dyskowych Cluster Shared Volume
ze starego do nowego klastra i uruchomienie środowiska już na nowym klastrze.
Drugim sposobem przeniesienia maszyn wirtualnych jest wykorzystanie narzędzia z pakietu System Center,
czyli wykorzystanie narzędzia System Center Virtual Machine Manager.
To narzędzie pozwoli nam na przemigrowanie klastrów zbudowanych w oparciu o Server 2008 R2 z Service Packiem 1, bądź 2012.
Na koniec, parę słów o certyfikacji i szkoleniach.
Do tej pory Microsoft posługiwał się certyfikatami Microsoft Certified Technology Specialist, Microsoft Certified IT Professsional.
Natomiast, ponieważ starsze certyfikaty, czyli Microsoft Certified System Administrator czy Microsoft Certified System Engineer
jako takie były bardzo dobrze rozpoznawalne, Microsoft zdecydował się do nich powrócić .
Na chwilę obecną, mamy możliwość zdobycia certyfikatu MCSA 2012.
Są dwa sposoby:
Dla specjalistów, którzy posiadają już certyfikat np. z 2008 roku, jest możliwość odbycia szkolenia upgrade’owego 20417
i zdania oczywiście, odpowiadającego temu szkoleniu egzaminu,
który pozwoli na zaktualizowanie posiadanej certyfikacji 2008 bezpośrednio do certyfikatu MCSA 2012.
Dla ludzi, którzy dopiero zaczynają przygodę z serwerami i certyfikacją
jest przygotowana pełna ścieżka szkoleń 20410, 20411, 20412
oraz odpowiadających im oczywiście, egzaminów po zdaniu których, profesjonalista uzyskuje certyfikat MCSA 2012.
Nie jest to, oczywiście, koniec.
Można dokonywać dalszej specjalizacji.
Można dokonać specjalizacji MCSE z Infrastruktury Serwerowej.
I tutaj oczywiście, są dwa kolejne szkolenia 20413, 20414 oraz odpowiadające im egzaminy
pozwalające na nabycie wiedzy o projektowaniu i wdrażaniu Infrastrukutry Serwerowej,
czyli bardziej zaawansowanej, poświęconej nie tylko administracji
oraz szkolenia i certyfikat z Infrastruktury Desktopowej.
Czyli, specjalizacja po zdobyciu certyfikatu MCSA 2012, możliwość zdobycia certyfikatu czy specjalizacji MCSE Desktop Infrastructure
i dwa szkolenia przygotowywujące do wdrożenia Infrastruktury Stacji Roboczej
oraz do wdrażania aplikacji na stacjach roboczych – 20415 i 20416 oraz oczywiście odpowiadające im egzaminy.
Dziękuję za uwagę.