Windows Azure Pack - IaaS - wdrożenie via PowerShell Deployment Toolkit

Niedawno został opublikowany mój artykuł o Azure Stack. Wciąż jest w wersji Technical Preview 1 i taki status przy ewentualnie zmieniającej się cyferce utrzyma do końca roku. Dlatego dziś na świeżo z implementacji o jego wcześniejszej inkarnacji czyli Windows Azure Pack. Poniżej chciałbym zawrzeć garść "lesson learned".

Klient to ogromny producent z przemysłu chemicznego, z rejonu GULF. Aby prace budowy podstawy infrastruktury dla wymagań funkcjonalnych przebiegły sprawnie zdecydowałem się na zrzut komponentów za pomocą PowerShell Deployment Toolkit: https://gallery.technet.microsoft.com/PowerShell-Deployment-f20bb605

PowerShell Deployment Toolkit to zestaw skryptów PowerShell służących budowaniu w całkowicie zautomatyzowany sposób całych infrastruktur Windows Azure Pack oraz System Center. Idealnie sprawdza się w scenariuszach budowania laboratorium, Proof of Concept. PDT ma też swoje ograniczenia. Dobrze jest przedsięwziąć szczególne środki planistyczne jeśli zamierzamy użyć narzędzia w produkcji. Dodatkowo wymagane będą kroki przygotowawcze zwłaszcza w architekturach wysokiej dostępności SQL Server, System Center, WAP.

O tym jak powyższe narzędzia działa napisano już wiele dlatego odsyłam do artykułów PDT step-by-step tu: https://blogs.technet.microsoft.com/privatecloud/tag/deployment-track/

Szereg elementów, które wiedziałem, że użyje onsite przygotowałem z góry. Celem było uniknięcie inwestowania czasu w odblokowywania portów pod WSUS, czekania na zatwierdzenia, konfiguracje, synchronizację. Dlatego wszystkie poprawki Windows Update ściągnąłem z góry używając WSUS Offline Update: https://download.wsusoffline.net/

Narzędzie WSUS Offline Update tylko pyta do jakiej wersji systemu potrzebujemy uaktualnień:

Wybrałem Windows 8.1/Server 2012 R2 i po kilkunastu minutach wszystkie poprawki znalazły się na moim dysku. Ze ściągniętych danych upewniłem się tylko, że Klient wcześniej ściągnie przekazany przeze mnie via OneDrive katalog źródeł poprawek WSUS Offline Update - rozmiar na chwilę obecną to trochę ponad 2GB: "w63-x64\glb".

Będąc u Klienta jedną z pierwszych czynności, które zaplanowałem, że podejmę to przygotowanie VHDX obrazu Windows 2012 R2. Zakładając, że mamy ISO, rozpakowujemy i wydobywamy install.wim sprawdzając pod którym indeksem jaka wersja OS się kryje:

dism /get-wiminfo /wimfile:D:\install.wim

Zapisałem sobie interesującą mnie wersje, w tym wypadku Server Standard (index 2).

Teraz aby wstrzyknąć przygotowane wcześniej poprawki wystarczyło użyć komendy:

dism /mount-wim /wimfile:D:\install.wim /mountdir:D:\WIMTEMP /index:2

Gdzie:

D:\install.wim to ścieżka do WIM

D:\WIMTEMP to pusty katalog do którego rozpakujemy tymczasowo WIM

Następnie:

dism /image:"D:\WIMTEMP" /Add-Package /PackagePath:"D:\w63-x64\glb"

Teraz:

dism /unmount-wim /mountdir:D:\WIMTEMP /commit

Po kilkunastu minutach nasz install.wim jest wyjęty niczym z podłączonego kablem Fiber Channel do internetu serwera WSUS. Teraz użyjemy skryptu Convert-WindowsImage.ps1: https://gallery.technet.microsoft.com/scriptcenter/Convert-WindowsImageps1-0fe23a8f

Dzięki narzędziu możemy skonwertować install.wim do VHDX w kilka chwil bez potrzeby instalacji systemu a potem uruchomiania SYSPREP - bo o uaktualnianiu OS nie wspomnę. W dokumentacji dotyczącej uruchomienia skryptu jest błąd i aby wyciosać VHDX generacji 2 postępujemy następująco wykonując polecenie z okna interpretera PowerShell:

Import-module .\Convert-WindowsImage.ps1

Oraz:

Convert-WindowsImage -SourcePath D:\install.wim -VHDPath D:\en-E-WS12R2D-G2.vhdx -VHDFormat VHDX -Edition ServerStandard -VHDType Dynamic -SizeBytes 60GB -VHDPartitionStyle GPT

Innymi słowy nie należy uruchamiać polecenia jako skryptu, a jako funkcję po tym jak moduł jest zaimportowany. Zakładam więc, że mamy na obecną chwilę:

• PDT wraz ze źródłami w odpowiedniej strukturze katalogów
• Przygotowane variable.xml  (przypominam link: https://blogs.technet.microsoft.com/privatecloud/tag/deployment-track/)
• W pełni zaktualizowany obraz Gold Windows 2012 R2, z którego będziemy budować infrastrukturę Windows Azure Pack i System Center.

Nie wahając się ani chwili dłużej odpalamy z PDT:

.\VMCreator.ps1

Skrypt utworzy wszystkie maszyny wirtualne zgodnie z instrukcjami w pliku variable.xml .

W naszym scenariuszu maszyny zostały podłączone do istniejącej domeny Active Directory. Dlatego następny krok to skopiowanie wszelkich źródeł PDT do wybranej VM (w moim przypadku maszyny POC-Deploy, katalog C:\Temp). Ze "środka" uruchomionego systemu operacyjnego, w katalogu ścieżki binariów PDT kontynuujemy odpalając skrypt PowerShell:

.\Installer.ps1

Wspomniany variable.xml odpowiadał instalacji Basic Distributed Deployment Architecture dla Windows Azure Pack jako, że jest to Proof of Concept rozwiązania: https://technet.microsoft.com/pl-pl/library/dn296433.aspx

Rezultat deploymentu był jak na obrazku poniżej:

Instalacja Service Management Automation nie powodła się. Konsekwencją było niepowodzenie integracji między komponentami WAP i System Center. Przyczyną zamieszania okazała się wersja PowerShell (build version > 5.0), która jeśli sprawdzimy wymagania wstępne SMA w kontekście wersji PowerShell zobaczymy rozbieżność i oto mamy trop. Pytanie skąd się wzięła w obrazie Gold skoro domyślnie Windows 2012 R2 dysponuje wersją 4.0? Otórz przy imporcie wszystkich poprawek za pomocą Dism jedna z nich to właśnie paczka z najnowszym PowerShell. Aby uporać się z instalacją należy na serwerach SMA oszukać chwilowo instalator Service Management Automation. W tym celu należy:

Zmienić właściciela dla klucza

• "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\3\PowerShellEngine" na "%COMPUTER%\Administrators"
• Zmienić nazwę "PowerShellVersion" w "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\3\PowerShellEngine" na "PowerShellVersion_"
• Utworzyć nowy REG_SZ "PowerShellVersion" z wartością "5.0"
• Zrestartować serwery SMA, uruchomić raz jeszcze Installer.ps1.
• Po skutecznym zainstalowaniu SMA przez PDT przywracamy wartości kluczom sprzed zmiany. W tym celu usuwamy wpis  "PowerShellVersion" w ścieżce "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\3\PowerShellEngine"
• zmieniamy nazwę dla "PowerShellVersion_" na "PowerShellVersion" .

Rezultat czynności jest następujący:

Teraz nic nie stoji na przeszkodzie zalogowania się na WAP Admin Portal w celach dalszej konfiguracji:

https://poc-wapadmptl01.___domain.poc:30091

dalej działamy z poziomu Tenant Portal:

https://POC-WAPTENPTL01.___domain.poc:30081

Aby przetestować deployment maszyn wirtualnych z Portalu Tenanta Windows Azure Pack:

Na koniec pamiętajmy o instalacji najnowszych Update Rollup 10 dla WAP oraz System Center. Dobrze jest się uczulić i upewnić się, że przeczytaliśmy wszelkie Release Notes oraz ReadMe przed rozpoczęciem instalacji UR na komponentach: https://support.microsoft.com/en-us/kb/3164172

Enjoy!

Tomasz Gościmiński