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