Migracja maszyny wirtualnej Windows Server do chmury obliczeniowej – przygotowanie i uruchomienie maszyny w Azure

13 Paź
13 października 2016 Posted by tuczap 0

Z poprzedniego artykułu wiemy że Azure toleruje tylko maszyny wirtualne uruchamiane z dysków VHD oraz dowiedzieliśmy się jak konwertować inne dyski wirtualne na ten format. W niniejszym wpisie podejmiemy decyzję o odpowiednim przygotowaniu dysku przed wgraniem go do Azure’a oraz w zależności od tego jaki był nasz wybór uruchomimy maszynę wirtualną. UWAGA – mimo że tytuł artykułu sugeruje że poniższe czynności mają zastosowanie tylko przy przenoszeniu maszyny z serwerowni do chmury to nic nie stoi na przeszkodzie by to samo zrobić z maszyną już znajdującą się w chmurze.

Przed wgraniem dysku maszyny wirtualnej do Azure’a musimy podjąć decyzję czy chcemy na niej uruchamiać sysprep, co usunie z niej wszelkie dane specyficzne dla tej konkretnej instalacji, zresetuje status aktywacji systemu, usunie konto administratora lokalnego, itd. Natomiast stan zainstalowanych programów i przechowywanych plików się nie zmieni, więc nasze dane powinny pozostać nietknięte. Jeśli zdecydujemy by nie sysprepować maszyny wtedy przerzucamy maszynę wirtualną wraz z wszelkimi zainstalowanymi sterownikami, informacjami na temat konfiguracji sieci, itp. do Azure’a więc część konfiguracji którą chmura zrobiłaby za nas po pierwszym uruchomieniu maszyny musimy zrobić sami, ale w ten sposób mamy pewność, że maszyna będzie wierną kopią tego co mamy w serwerowni.

Którą opcję wybrać? Decyzję pozostawiam Tobie, ale poniżej wskazówki, które mam nadzieję pomogą w dokonaniu właściwego wyboru:

  1. Sys-prepować wtedy gdy chcemy z maszyny wirtualnej zrobić szablon dla nowych maszyn tworzonych w chmurze, lub nie obawiamy się że sysprep może coś zepsuć w konfiguracji maszyny lub aplikacji na niej działających. W większości przypadków ta opcja powinna wystarczyć
  2. Nie sys-prepować wtedy gdy maszyna wirtualna jest skonfigurowana pod konkretne potrzeby i każda zmiana w jej konfiguracji może mieć wpływ na stabilność jej pracy lub pracy aplikacji na niej zainstalowanych. Co prawda w takich przypadkach wątpliwe w ogóle jest czy maszyna będzie prawidłowo działać w chmurze, ale sysprep może dodatkowo więcej napsuć niż pomóc.

Po dokonaniu decyzji jak by ona nie była warto zrobić backup dysku VHD, żeby w razie czego dysponować kopią zapasową jakby coś poszło nie tak.

Dalsze kroki są uzależnione od tego którą metodę wybierzemy. Dla ułatwienia nagłówki będę numerował, jeśli powtórzy się ta sama liczba oznacza to że krok należy wykonać w zależności od tego czy robiliśmy sysprep czy nie. W tytule nagłówka znajduje się informacja której metody dotyczy opis. Do dzieła!

1. Przygotowanie systemu

Od razu zaznaczę, że kroki opisane w tym akapicie nie są konieczne aczkolwiek z pewnością są zalecane. Wykonanie ich wszystkich znacząco zwiększa lub wręcz gwarantuje poprawną pracę maszyny wirtualnej w Azure – szczególnie polecam sprawdzić konfigurację Windows Firewall. Nic tak nie wkurza gdy na koniec próbujemy dostać się do maszyny przez zdalny pulpit i okazuje się, że zapomnieliśmy wyłączyć zaporę. Po aktualny zestaw kroków odsyłam do dokumentacji Azure.

  1. Uruchom linię komend jako administrator. Wpisz

    Jeśli w sekcji Persistence Routes są jakieś wpisy to usuń je za pomocą komendy route delete.
  2. Usuń proxy
  3. Skonfiguruj politykę zarządzania dyskami by wszystkie nowe dyski były automatycznie podłączane
  4. Zmień ustawienia czasu w Windows i ustawienia uruchomienia usługi czasu
  5. Sprawdź czy tryb uruchamiania wszystkich usług Windows jest ustawiony na wartości domyślne. Poniżej lista komend jak to powinno wyglądać
  6. Usuń wszelkie certyfikaty powiązane z RDP o ile występują
  7. By wykluczyć timeout’y przy połączeniach RDP zmodyfikuj ustawienia KeepAlive
  8. Upewnij się, że usługa RDP jest poprawnie skonfigurowane w kwestii uwierzytelniania
  9. Upewnij się, że usługa RDP jest włączona
  10. Windows Firewall – trzeba dodać wyjątki w Firewallu. Jeśli Windows Firewall jest wyłączony to krok można pominąć.
    Inbound:

    Inbound oraz Outbound

    Outbound
  11. Upewnij się, że WMI jest skonfigurowane poprawnie
  12. Upewnij się, że ustawienia BCD są spójne z tymi poniżej
  13. Sprawdź czy są błędy na dysku
  14. Upewnij się, że nic nie używa portu 3389, który jest używany przez Azure do połączeń RDP
  15. Upewnij się, że do maszyny można połączyć się przez RDP z wykorzystaniem konta lokalnego administratora
  16. Włącz zbieranie logów
  17. W Powershell wykonaj komendę włączającą WinRM
  18. Zainstaluj Azure Virtual Machines Agent
  19. Zainstaluj aktualizacje!

2. Sysprep: przygotowanie maszyny do przeniesienia do Azure

Na początku musimy uruchomić sysprep na maszynie wirtualnej którą będziemy przenosić do Azure. W tym celu logujemy się na serwer, uruchamiany linię komend jako administrator i wpisujemy

W okienku, które się pojawi zaznaczamy Generalize i wybieramy Shutdown

sysprep

Po kliknięciu OK  rozpocznie się proces generalizacji systemu, a po jego zakończeniu serwer zostanie wyłączony. Od teraz nie możemy się na niego dostać zdalnym pulpitem, a po ponownym uruchomieniu zostaniemy powitani przez kreator jak przy nowej instalacji Windows Server (trzeba między innymi podać poświadczenia administratora).

2. Nie-sysprep: przygotowanie maszyny do przeniesienia do Azure

Przygotowanie systemu w tej metodzie sprowadza się do włączenia możliwości połączeń zdalnych (RDP) oraz usunięciu ustawień sieciowych. Maszyna musi dostawać ustawienia z DHCP żeby działała poprawnie w Azure. Następnie instalujemy Azure Virtual Machines Agent. Na koniec warto włączyć zbieranie logów – w razie jakby z maszyną działo się coś złego to z poziomu portalu Azure będziemy mogli to sprawdzić.

3. Wgranie dysku VHD do Azure

Teraz uruchamiamy Powershell, najlepiej jako administrator i logujemy się do Azure’a

nazwa_subskrypcji to oczywiście nazwa subskrypcji w której znajduje się konto magazynu do którego będziemy wgrywać dysk za pomocą poniższej komendy, ewentualnie można też wykorzystać AzCopy

Przykład:

Add-AzureRmVhd -ResourceGroupName „VHDvmRG” -Destination „https://vhdvm.blob.core.windows.net/vhds/vhdvm.vhd” -LocalFilePath „C:\Users\ttuczapski\Documents\vhdVM.vhd”

Chwilę się zejdzie zanim wgrywanie pliku się zakończy, oczywiście to jak długo będziemy czekać zależy od tego jak dużo waży plik i jakim łączem dysponujemy. Proces wgrywania powinien zakończyć się komunikatem w stylu

4. Sysprep: utworzenie maszyny wirtualnej

Utworzenie maszyny zaczniemy od stworzenia sieci i jej konfiguracji. Oczywiście możesz skorzystać z już istniejącej wirtualnej infrastruktury ale przyjmuję że tworzę wszystko od zera.

$rg – jeśli chodzi o grupę zasobów to wszędzie używam tej samej grupy zasobów w której jest wgrany wcześniej dysk – takie jest wymaganie

$location – nazwa lokacji centrum danych Azure np. „West Europe”

Jako AddressPrefix należy podać przestrzeń adresową podsieci. Najlepiej sprawdzić w Azure jakie są przestrzenie już istniejących podsieci i wybrać taki sam lub jakiś podobny.

Teraz tworzymy zasób sieci wirtualnej

AddressPrefix  można podać taki sam jak przy wykonywaniu wcześniejszej komendy. założenie jest takie że $subnet powinien mieć mniejszą pulę adresów niż $vnet np.:

$subnet = 10.2.0.0/24

$vnet = 10.2.0.0/16

U mnie to wyglądało następująco:

$rg = „vhdvmRG”

$location = „West Europe”

$subnet = New-AzureRmVirtualNetworkSubnetConfig -Name „vhdvmSubnet” -AddressPrefix 10.12.0.0/16

$vnet = New-AzureRmVirtualNetwork -Name „vhdvmNetwork” -ResourceGroupName $rg -Location $location -AddressPrefix 10.12.0.0/16 -Subnet $subnet

Teraz w grupie zasobów powinien pojawić się nowy zasób sieci wirtualnej. A mając sieć wirtualną możemy stworzyć publiczny adres IP i kartę sieciową dla naszej maszyny.

Oczywiście nazwy zasobów możesz zastąpić własnymi wartościami. Kolejne dwa zasoby powinny pojawić się w danej grupie zasobów.

Mając podwaliny pod infrastrukturę sieciową możemy w końcu utworzyć maszynę wirtualną

Utworzenie maszyny wirtualnej powinno zostać potwierdzone komunikatem

Teraz po zalogowaniu się do portalu Azure powinna być widoczna utworzona maszyna wirtualna. W ramach testu podłączyłem się do niej i okazało się że baza danych znajduje się tam gdzie powinna i w dodatku jest online 🙂 Wszystkie pliki (oprócz tych w folderze użytkownika – są one usuwane przez sysprep) były na swoim miejscu. Reasumując – na pierwszy rzut oka wygląda na to że przeniesienie maszyny wirtualnej z serwerowni do Azure nic nie pogubiło 🙂

5. Nie-sysprep: utworzenie maszyny wirtualnej

Tworzenie maszyny wirtualnej w Azure z dysku z systemem który nie został potraktowany sysprepem, robi się analogicznie jak w przypadku maszyny sysprepowanej z tą różnicą że w Powershell przy ustawianiu dysku OS maszyny należy podać opcję „Attach” zamiast „fromImage„. Dla nas ma to takie dodatkowe znaczenie że taki dysk można użyć a dokładniej podłączyć tylko do jednej maszyny naraz. Natomiast w przypadku opcji „fromImage” dysk bazowy jest klonowany i dopiero z klonu powstaje dysk systemowy. W ten sposób dysk bazowy można wykorzystać wiele razy do tworzenia nowych maszyn wirtualnych.

Utworzenie maszyny zaczniemy od stworzenia sieci i jej konfiguracji. Oczywiście możesz skorzystać z już istniejącej wirtualnej infrastruktury ale przyjmuję że tworzę wszystko od zera.

$rg – jeśli chodzi o grupę zasobów to wszędzie używam tej samej grupy zasobów w której jest wgrany wcześniej dysk – takie jest wymaganie

$location – nazwa lokacji centrum danych Azure np. „West Europe”

Jako AddressPrefix należy podać przestrzeń adresową podsieci. Najlepiej sprawdzić w Azure jakie są przestrzenie już istniejących podsieci i wybrać taki sam lub jakiś podobny.

Teraz tworzymy zasób sieci wirtualnej

AddressPrefix  można podać taki sam jak przy wykonywaniu wcześniejszej komendy. założenie jest takie że $subnet powinien mieć mniejszą pulę adresów niż $vnet np.:

$subnet = 10.2.0.0/24

$vnet = 10.2.0.0/16

U mnie to wyglądało następująco:

$rg = „vhdvmRG”

$location = „West Europe”

$subnet = New-AzureRmVirtualNetworkSubnetConfig -Name „vhdvmSubnet” -AddressPrefix 10.12.0.0/16

$vnet = New-AzureRmVirtualNetwork -Name „vhdvmNetwork” -ResourceGroupName $rg -Location $location -AddressPrefix 10.12.0.0/16 -Subnet $subnet

Teraz w grupie zasobów powinien pojawić się nowy zasób sieci wirtualnej. A mając sieć wirtualną możemy stworzyć publiczny adres IP i kartę sieciową dla naszej maszyny.

Oczywiście nazwy zasobów możesz zastąpić własnymi wartościami. Kolejne dwa zasoby powinny pojawić się w danej grupie zasobów.

Mając podwaliny pod infrastrukturę sieciową możemy w końcu utworzyć maszynę wirtualną

Utworzenie maszyny wirtualnej powinno zostać potwierdzone komunikatem

Teraz po zalogowaniu się do portalu Azure powinna być widoczna utworzona maszyna wirtualna. W ramach testu podłączyłem się do niej używając tych samych poświadczeń jakich używałem logując się on premise. Okazało się że baza danych znajduje się tam gdzie powinna i w dodatku jest online 🙂 Wszystkie pliki były na swoim miejscu. Reasumując – na pierwszy rzut oka wygląda na to że przeniesienie maszyny wirtualnej z serwerowni do Azure nic nie pogubiło i w dodatku nie trzeba było jej traktować sysprepem co oznacza że cały czas można działać z jednym dyskiem vhd bez konieczności tworzenia z niego obrazu.

5. Nie-sysprep: po utworzeniu maszyny w Azure

Na maszynie, która nie została przygotowana sysprepem trzeba jeszcze ustawić plik stronicowania na tymczasowym dysku D, tak jak ma to miejsce gdy tworzymy nową maszynę z obrazu dostępnych w Azure:

 

I to by było na tyle, teraz możesz przerzucać maszyny wirtualne między chmurą a lokalnym serwerem w celu np. optymalizacji obciążeń lub ograniczenia kosztów 🙂

To czego brakuje a co na pewno warto skonfigurować to Network Security Group (NSG) – bez niej cały ruch z i do internetu jest przepuszczany przez maszynę wirtualną co może powodować poważne zagrożenie bezpieczeństwa. Możesz dodać NSG na własną rękę (jest taka możliwość zarówno z poziomu portalu jak i Powershell) lub poczekać na następny wpis, w którym opiszę to zagadnienie 🙂

Dodaj komentarz