W poprzednich wpisach opisywałem:
- Upgrade VMware vCloud Director z 8.20 na 9.5 oraz
- Przygotowanie PostgreSQL10 do migracji bazy vCloud Directora z MSSQL
W tej chwili pochylimy się nad samym procesem migracji bazy MS SQL na bazę rekomendowaną przez VMware (na dzień dzisiejszy).
Migracja (informacje wstępne): Tak ja do tego podchodzę dzisiaj korzystając z dokumentacji producenta i swoich decyzji. 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 migracji danego produktu, które można podzielić jeszcze na bardziej szczegółowe.
1. Etap przygotowań
- Upewnij się ze wiesz jak zrobić backup i restore bazy MSSQL i CELLek
- Zweryfikuj hasła do CELLek root, administrator lub domenowe jeśli taka jest konfiguracja
- Zweryfikuj czy jest backup CELL1, CELL2 sprzed kilku dni (czy backup działa)
- Zweryfikuj na CELLce w pliku konfiguracyjnym do jakiej DB dokladnie łączy się CELLka (/opt/vmware/vcloud-director/etc/responses.properties)
- Zweryfikuj czy nie ma widocznych problemów z vCD i jego funkcjonalnościami
- Zaplanuj okno serwisowe dla dodatkowych komponentów w infrastrukturze jeśli istnieją na czas aktualizacji aby nikt ich nie używał w tym czasie
- Wykonaj testowy FULL backup CELLek + MSSQL + nowy PostgreSQL serwer
- Przygotuj 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
- Powiadomić klientów np. tydzień wcześniej, iż np. o 22.00 danego dnia prosimy nie wykonywać prac na środowisku vCD itp.
- Profilaktycznie użyj narzędzia np. RV tools (aby zrzucić informacji o środowisku vSphere)
2. Dzień migracji
- Skopiuj 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 migracji w sytuacji podobnej jak powyżej.
3. Kwadrans przed migracją
- Wyślij komunikację mailową do klienta oraz współpracujących zespołów (opcjonalnie, jeśli to wymagane)
- Wykonaj backup CELLek od vCD (opcjonalnie)
- Wykonaj “clone” CELLek od vCD (opcjonalnie)
- Wykonaj “snapshot” CELLek oraz MSSQL od VCD
- Wykonaj “snashoot” nowej maszyny gdzie już działa PostgreSQL (profilaktycznie gdyby trzeba było ponowić migrację)
- Wykonaj backup z poziomu MS SQL Management Studio bazy vCloud Directora
- Przełącz systemy monitoringu komponentów vCloud Directora w maintenacemode (sposób może być zależny od polityki firmy,zespołu lub używanych narzędzi)
4. Migracja z MSSQL na PostgreSQL
- 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
- 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
- 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
- Wykonanie ponownie kopie zapasowej bazy danych na poziomie MSSQL (ten moment jest dobry na kopie zapasową bo serwisy vCD są wyłączone)
- Wykonanie ponownie snapshootu CELL01, CELL02 bez pamięci (opcjonalnie)
- Migracja bazy danych z MSSQL na PostgreSQL
/opt/vmware/vcloud-director/bin/cell-management-tool dbmigrate -dbhost FQDN -dbport 5432 -dbuser vcloud -dbname vcloud -dbpassword HASLO
- Rekonfiguracja CELL02 na PostgreSQL
/opt/vmware/vcloud-director/bin/cell-management-tool reconfigure-database -dbhost FQDN -dbport 5432 -dbuser vcloud -dbname vcloud -dbpassword HASLO -dbtype postgres
- Rekonfiguracja CELL01 na PostgreSQL
/opt/vmware/vcloud-director/bin/cell-management-tool reconfigure-database -dbhost FQDN -dbport 5432 -dbuser vcloud -dbname vcloud -dbpassword HASLO -dbtype postgres
- Restart CELLki i manualny Start serwisu głównego na CELL02 (jeśli serwis nie podniósł się sam):
service vmware-vcd start
- Test czy portal wstał na CELL02: https://naszadomena.pl/cloud
- Restart CELLki i manualny Start serwisu głównego na CELL01
service vmware-vcd start
5. Testy po migracji
- Monitor logs tail -f /opt/vmware/vcloud-director/logs/cell.log
- Monitoring (na CELLkach)
netstat -an | grep 5432 (MSSQL uzywa portu 1433, PostgreSQL 5432) netstat -pn |grep ADRESIP MSSQL netstat -pn |grep ADRESIP POSTGRESQL
- Sprawdzenie pliku konfiguracyjnego:
cat /opt/vmware/vcloud-director/etc/responses.properties
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.
Dodam Cię do listy mailowej, z której możesz wypisać się w dowolnym momencie (jeden klik.) | Polityka Prywatności