Upgrade VMware vCloud Director z 8.20 na 9.5 | Dobre praktyki | Checklista

 

VMware vCloud Director dla service providerów przez niektórych jakiś czas temu został skazany na wyginięcie z uwagi na brak wydawania aktualizacji do swojego produktu. Jak się okazało w 2018 roku VMware postanowił wskrzesić ten produkt z przytupem i wydał wersje 9.x. Na koniec też roku wyszedł duży “update” do wersji 9.5. Z tego też powodu stanąłem przed zadaniem podniesienia jednego z komponentów środowisk z archaicznej już wersji, której wsparcie kończyło się 21 lutego 2019 ( wg. strony “Lifecycle Policies” gdzie można znaleźć link do “Lifecycle Product Matrix” . Będę zamiennie używał słowa “aktualizacja” oraz “upgrade” co w zasadzie znaczy to samo, ale kieruje to do Polskich odbiorców stąd będę się starał używać polskiego określenia (wiem wiem aktualizacja to bardziej update niż upgrade ale zostawmy ten temat na inną okazje 🙂 ).

 

 

 

“Upgrade” został przeprowadzony 20 dni przed tą datą co może nie było najrozsądniejszą decyzją, że czekaliśmy aż tak długo, ale miały na to wpływ także czynnik zależności innych komponentów infrastruktury, które testowaliśmy przez ostatnie parę miesięcy.

 

Aktualizacja (informacje wstępne): Tak ja do tego podchodzę dzisiaj korzystając z dokumentacji producenta. Twoja metodyka może być zupełnie inna lub zbliżona, ponieważ wszyscy opieramy się na zaleceniach vendorów jak i własnych doświadczeniach, które z czasem mogą ulegać zmianie.

Po pierwsze wydzielam sobie zawsze główne etapy aktualizacji danego produktu, które można podzielić jeszcze na bardziej szczegółowe.

Używana dokumentacja:

 

Używane pliki instalacyjne podczas upgrade (tzw. binaria)

vmware-vcloud-director-distribution-9.5.0-11038216.bin | MD5SUM: 02a402ace3707028710a94ccaae1fb00 | VMware vCloud Director 9.5.0.1

1. Etap przygotowań

  • Stworzenie obrazu “wysokiego poziomu co będzie działo się na każdym etapie “aktualizacji”

np.

Krok Stan CELL01 Stan CELL02 Portal Czas[min.] Uwagi
Stan początkowy
Przejście CELLek w tryb MM aby nikt nie mogł logowac sie do portalu 2
Zatrzymanie serwisu głównego na CELL2 (nieaktywnej) 5 + wczesniejsza weryfikacja statusu
Zatrzymanie serwisu głównego CELL1 (aktywnej) 5 + wczesniejsza weryfikacja statusu
Wykonanie kopi zapasowej bazy danych 10 Poprzez MS SQL Management Studio
Snapshoot CELLek (bez pamięci) 5
Aktualizacja CELL2 5
Aktualizacja bazy danych (w tym przypadku schematu na MSSQL) z CELL02 15 Wystarczy wykonać tylko na jednej CELLce
Start serwisu głównego na CELL02 5-10
Aktualizacja CELL01 5
Start serwisu głównego CELL01 5-10
Testy po upgrejdzie 60-120

 

  • Sprawdzenie czy wszystkie hosty ESXi są włączone w vCD 8.2
  • Skopiowanie numeru licencyjnego z vCD z wersji 8.x i zweryfikować możliwość zaktualizowania go w portalu VMware. Wymagane przy przejściu pomiędzy wersjami 8.x do 9.x
  • Upewnienie się ze wiesz jak zrobić backup i restore bazy MSSQL i CELLek. To samo w kwestii użycia clonu lub snapshotów (wiem trywialne, ale…).
  • Weryfikacja haseł do CELLek root, administrator lub domenowe, jeśli taka jest konfiguracja
  • Zweryfikować czy jest backup CELLek sprzed kilku dni (czy backup działa)
  • Weryfikacja hasha MD5 ściągniętego pliku ze strony VMware
  • Wgranie paczki instalacyjnej na CELLki (recznie) np. do katalogu /tmp przez WinSCP
  • Zmiana uprawnień do pliku instalacyjnego ( “chmod u+x installation-file”)
  • Sprawdzenie status Usage Meter i czy ma połączenie z vCD i vCenter https://usagemeter:8443/um/manage
  • Weryfikacja na CELL w pliku konfiguracyjnym, do jakiej DB dokladnie zapisuje CELLka (/opt/vmware/vcloud-director/etc/responses.properties)
  • Weryfikacja czy nie ma widocznych problemów z vCD i jego funkcjonalnościami
  • Zaplanować okno serwisowe dla dodatkowych komponentów w infrastrukturze jeśli istnieją na czas aktualizacji aby nikt ich nie używał w tym czasie
  • Powiadomić klientów np. tydzień wczesniej, iż np. 22.00 prosimy nie wykonywać prac na środowisku vCD itp
  • Profilaktycznie użyć narzędzia RV tools skan-zapisany lokalnie mieć roboczy zrzut informacji o środowisku (opcjonalnie)
  • Przygotować wzór komunikacji mailowej z zarysem infrastruktury dla VMware w przypadku problemów, aby w płynny sposób zaprezentować zarys naszej infrastruktury człowiekowi z supportu w przypadku awarii
  • Wykonać testowy FULL a później różnicowy backup (zweryfikować czas wykonania i wziąć to pod uwagę przy planowaniu okna serwisowego)

2. Dzien przed “upgrejdem”

  • Weryfikacja czy nie pojawiły się jakieś nowe informacje na temat vCD Release Notes -np.  link
  • Ściągnąć Tech support boundle dzień przed aktualizacją – link

3. W dzień “upgrejdu”

  • Zweryfikować, iż CELL1 jest aktywna, CELL2 jest nieaktywna (ma to wpływ na kolejność wyłączania serwisów podczas aktualizacji)
  • Skopiować bazę z hasłami (jeśli jest takie coś utrzymywane) lokalnie na komputer + informacje o środowisku (IP itp), jeśli trzymamy takie rzeczy np na Sharepoint (wersja paranoidalna, jeśli chcemy zabezpieczyć się np. przed awarią Sharepoint lub osobnej bazy z hasłami 🙂 )
  • Przygotować offlinową instrukcje z wszystkimi krokami “aktualizacji” w sytuacji podobnej jak powyżej.

4. Kwadrans przed upgrejdem

  • Wysłać komunikację mailową do klienta (opcjonalnie, jeśli to wymagane)
  • Wykonać backup CELLek od vCD
  • Wykonać “clone” CELLek od vCD

5. “Upgrejd” vCloud Directora

  1. Wykonać: Backup CELL1, CELL2 JOBem (opcjonalnie)
  2. Wykonać: Klony CELLek (opcjonalnie)
  3. Przejście CELLek w tryb MM, aby nikt nie mógł logować się do portalu
/opt/vmware/vcloud-director/bin/vmware-vcd-cell maintenance command

4. Zatrzymanie serwisu głównego na CELL2 (nieaktywnej)

service vmware-vcd status
/opt/vmware/vcloud-director/bin/cell-management-tool -u administrator cell --status-verbose
/opt/vmware/vcloud-director/bin/cell-management-tool -u administrator cell --status
/opt/vmware/vcloud-director/bin/cell-management-tool -u administrator cell --quiesce true
/opt/vmware/vcloud-director/bin/cell-management-tool -u administrator cell --shutdown
service vmware-vcd status

Albo jeśli nie będzie przyjmował (ten jest nawet bardziej preferowany).

/opt/vmware/vcloud-director/bin/cell-management-tool cell -t -u administrator
/opt/vmware/vcloud-director/bin/cell-management-tool cell -tt -u administrator
/opt/vmware/vcloud-director/bin/cell-management-tool cell -u administrator --quiesce true
/opt/vmware/vcloud-director/bin/cell-management-tool cell -u administrator --shutdown
service vmware-vcd status

5. Zatrzymanie serwisu głównego CELL1 (aktywnej)

service vmware-vcd status
/opt/vmware/vcloud-director/bin/cell-management-tool -u administrator cell --status-verbose
/opt/vmware/vcloud-director/bin/cell-management-tool -u administrator cell --status
/opt/vmware/vcloud-director/bin/cell-management-tool -u administrator cell --quiesce true
/opt/vmware/vcloud-director/bin/cell-management-tool -u administrator cell --shutdown
service vmware-vcd status

albo jeśli nie będzie przyjmował (ten jest nawet bardziej preferowany)

/opt/vmware/vcloud-director/bin/cell-management-tool cell -t -u administrator
/opt/vmware/vcloud-director/bin/cell-management-tool cell -tt -u administrator
/opt/vmware/vcloud-director/bin/cell-management-tool cell -u administrator --quiesce true
/opt/vmware/vcloud-director/bin/cell-management-tool cell -u administrator --shutdown
service vmware-vcd status

6. Wykonanie kopii zapasowej bazy danych na poziomie MSSQL

7. Wykonanie  snapshootu CELL01, CELL02 bez pamięci

8. Wykonanie clona CELLek od VCD

9. Aktualizacja CELL2

sudo -i
./vmware-vcloud-director-distribution-9.5.0-10266189.bin
service vmware-vcd status

Aktualizacja bazy danych (w tym przypadku schematu na MSSQL) z CELL2 + zgoda na start serwisu + test czy można zalogować się do vCD działając na 1 CELLce

service vmware-vcd status
/opt/vmware/vcloud-director/bin/upgrade

Start serwisu głównego na CELL2 (jeśli nie wykonano automatycznego startu powyżej)

service vmware-vcd start

Aktualizacja CELL1

sudo -i
./vmware-vcloud-director-distribution-9.5.0-10266189.bin
service vmware-vcd status

Start serwisu głównego CELL1  (jeśli nie wykonano automatycznego startu powyżej)

service vmware-vcd start

 

6. Testy po aktualizacji

  • Weryfikacja czy portal vCD działa
  • Weryfikacja czy CELLki w portalu są online
  • Weryfikacja czy nowe portal “tenant” portal działa pod nowym linkiem https://vCDdomena/tenant/nazwaorganizacji
  • Weryfikacja funkcjonowania podstawowych funkcjonalności polegających na tworzeniu i modyfikowaniu różnych komponentów compute, network, storage
  • Weryfikacja stosowanych w naszej firmie narzędzi, które integrowały się z poprzednią wersją. Czy w dalszym ciągu działają odpowiednio.

7. Roolback

Tego punktu nie ruszamy jeśli wszystko powyższe działa i nie musimy przywracać poprzednich wersji 🙂

  1. Powrót do snapshotów sprzed aktualizacji
  2. Przywrócenie bazy MS SQL sprzed aktualizacji
  3. Start CELLek od vCD

Clony, snapshoty ja osobiście zostawiam na 7 dni, po których jeśli nic się nie dzieje złego ze środowiskiem po prostu usuwam.

Tak jak pisałem kolejność ta jest moja i może się zdarzyć, iż niektóre kroki wydawać by się mogły zbędne i bezsensu. Dlatego, jeśli masz swoje doświadczenia na ten temat daj znać w komentarzach.

Informacje o nowych artykułach, świecie wirtualizacji i "cloud computingu" prosto na Twojego maila:

Dodam Cię do listy mailowej, z której możesz wypisać się w dowolnym momencie (jeden klik.) | Polityka Prywatności