Bądź na bieżąco - RSS

Aktualizacja XSIBackup

27 lipca, 2020 | Brak Komentarzy | Kategoria: Porady
Awaria serwera - konieczna aktualizacja XSIBackup

XSIBackup jako super wygodne narzędzie do wykonywania kopii zapasowych maszyn wirtualnych VMware sprawuje się bez zarzutu. Pisałem o tym programie wielokrotnie np. tutaj. Wspominałem również, że w połączeniu z VMware vCenter Converter Standalone stanowi szwajcarski scyzoryk na wypadek grubszej awarii tj. gdy musimy bardzo szybko odtworzyć wirtualizację np. z powodu awarii sprzętowej hosta.

W przyrodzie nie ma jednak rozwiązań doskonałych i nawet XSIBackup potrafi spłatać figla. Sytuacja, którą chciałem opisać dotyczy momentu tuż po aktualizacji VMware ESXi, kiedy mamy już powgrywane najnowsze patche a jeszcze nie aktualizowaliśmy naszego programu do kopii. Ja po prostu o tym zapomniałem – do tego stopnia, że nawet przeoczyłem brak nowych raportów email o kopiach zapasowych. A program się zwiesił.

Dość szybko znalazłem opis błędu w Internecie, odpowiedzialny był interpreter, a dokładniej jego niezgodność (w nowej wersji VMware) ze starszą wersją XSIBackup. Stanąłem przed koniecznością zainstalowania nowego wydania… i popełniłem duży błąd. Podążając za rozmaitymi poradnikami z forów użytkowników, gdzie twierdzono, że zasadniczo wystarczy podmienić odpowiednie pliki i wszystko powinno działać, pracowicie skopiowałem co trzeba. Zależało mi głównie na tym aby nie tracić tzw. jobs, czyli zadań kopiowania, które zdążyłem skonfigurować (nie jest to trywialna czynność ze względu na mnogość opcji). Zostawiłem całość bez przetestowania – kolejny błąd, a za dwa dni zadzwonił do mnie zaniepokojony użytkownik z informacją, że serwer nie działa. Chodziło o jdną z maszyn wirtualnych. Okazało się, że nie odpowiada cały host VM 🙁 Była sobota i w tym momencie runęła perspektywa wypoczynku. Po dotarciu na miejsce tzn. do serwerowni, ze zdziwieniem stwierdziłem, że serwer działa bez zarzutu, ale interfejsy sieciowe padły. Rzecz jasna restart całej jednostki pomógł, ale zmobilizowało mnie to do wykonania dwóch czynności, które powinienem zrobić od razu.

Po pierwsze usunąłem całą instalację XSIBackup. Polega to głównie na skasowaniu wszystkich plików i co ważne usunięciu zadań kopiowania na poziomie cron:

rm -rf "/vmfs/volumes/datastore1/xsi-dir"; \ 
chmod 0700 /var/spool/cron/crontabs/root; \ 
sed -i '/-dir\/jobs/d' /var/spool/cron/crontabs/root; \ 
sed -i '/cron-init/d' /etc/rc.local.d/local.sh

Po drugie zainstalowałem od nowa XSIBackup odtwarzając skopiowane wcześniej zadania automatycznego wykonywania kopii. Na szczęście pomogło.

MG

Tagi: , , , ,

Aktualizacja hosta ESXi

18 sierpnia, 2018 | Brak Komentarzy | Kategoria: Linux, Porady, Windows

VMware ESXiWirtualizacja jest obecnie praktycznie standardem. Jest powszechnie dostępna i łatwo można samemu przygotować własny host maszyn wirtualnych. Od jakiegoś czasu testuje aktualnie kilka instalacji VMware ESXi i muszę przyznać, że jestem zaskoczony wygodą obsługi oraz jak dotąd (odpukać) bezawaryjną pracą. Instalacja jest dosyć łatwa pod warunkiem, że przygotujemy się pod kątem sprzętu. Nie każdy zostanie wykryty przez instalator, ale metodą prób i błedów a także przy wsparciu forów technicznych można rozwiązać większość problemów. Potem jest już z górki. Do czasu. Jak zwykle po jakimś czasie powinniśmy pomyśleć o kwestiach bezpieczeństwa, a co się z tym wiąże aktualizacji naszego hosta.

Jeżeli podobnie jak ja używasz wersji ewaluacyjnej ESXi to znaczy, że najprawdopodobniej korzystasz z trybu standalone server, czyli posiadasz tylko jeden host maszyn wirtulanych. Instalacja tego typu wyróżnia się brakiem wygodnej czytaj graficznej obsługi aktualizacji. Pełna instalacja zarezerwowana jest dla dużych farm hostów, a tak naprawdę trzeba zapłacić za oprogramowanie zarządzające hostami, co na jedno wychodzi. W tym przypadku trzeba sobie radzić za pomocą konsoli tekstowej.  Ale po kolei…

Najpierw należy zalogować się na nasz host używając po prostu przeglądarki internetowej. Z poziomu graficznej konsoli zarządzania trzeba uruchomić usługę SSH. Nie jest ona domyślnie włączona – dla bezpieczeństwa. Wybieramy zatem opcję Manage z okienka Navigator po lewej stronie i w okienku po prawej stronie przechodzimy do zakładki Services. Uruchamiamy usługę TSM-SSH (po zakończeniu aktualizacji warto ją wyłączyć ponownie). Od tej pory możemy połączyć się za pomocą SSH do naszego hosta.

Zaczynamy od sprawdzenia wersji poleceniem:

~ # esxcli system version get
Product: VMware ESXi
Version: 6.7.0
Build: Releasebuild-469512
Update: 0
Patch: 0

Następnie udajemy się na stronę z aktualizacjami dla VMware ESXi i pobieramy właściwą dla naszego systemu. Warto zauważyć, że aktualizacje kumulują się, więc nie ma potrzeby wgrywania wszystkich – wystarczy ostatnia. Dodam, że na pewno trzeba wgrać oznaczone etykietką Critical, reszta według uznania.

Przełączamy host ESXi w tryb Maintenance (za pomocą przeglądarki i strony zarządzającej) i możemy przystąpić do działania. Rozpoczynamy od wyświetlenia listy profili dostępnych w naszym patchu:

~ # esxcli software sources profile list --depot=/vmfs/volumes/ \
datastore1/patch/update-from-esxi6.7-5.0_update03.zip
Name Vendor Acceptance Level
-------------------------------- ------------ ----------------
ESXi-6.7.0-20171002001-standard VMware, Inc. PartnerSupported
ESXi-6.7.0-20171001001s-standard VMware, Inc. PartnerSupported
ESXi-6.7.0-20171001001s-no-tools VMware, Inc. PartnerSupported
ESXi-6.7.0-20171002001-no-tools VMware, Inc. PartnerSupported

Najbezpieczniej jest skorzystać z profilu standardowego, a więc ESXi-6.7.0-20171002001-standard. Jest to zazwyczaj pierwszy dostępny profil z listy. Nim w następnym kroku przystąpimy do aktualizacji serwera, powinniśmy najpierw sprawdzić jaki będzie wynik tej operacji. Z pomocą przychodzi opcja –dry-run. Wpisujemy plecenie:

~ # esxcli software profile update --depot=/vmfs/volumes/ \
datastore1/patch/update-from-esxi6.7-5.0_update03.zip \
--dry-run --profile=ESXi-6.7.0-20131002001-standard
Update Result
Message: Dryrun only, host not changed. The following \
installers will be applied: [BootBankInstaller]
Reboot Required: true
VIBs Installed: 
VMware_bootbank_ehci-ehci-hcd_1.0-3vmw.500.1.11.623860, \
VMware_bootbank_esx-base_5.0.0-3.41.1311175, \
VMware_bootbank_esx-tboot_5.0.0-2.26.914586, \
VMware_bootbank_ipmi-ipmi-si-drv_39.1-4vmw.500.2.26.914586, \
VMware_bootbank_misc-drivers_5.0.0-3.41.1311175, \
VMware_bootbank_net-be2net_4.0.88.0-1vmw.500.0.7.515841, \ 
VIBs Removed: 
VMware_bootbank_ehci-ehci-hcd_1.0-3vmw.500.0.0.469512, \ 
VMware_bootbank_esx-base_5.0.0-0.0.469512, \
VMware_bootbank_esx-tboot_5.0.0-0.0.469512, \
VMware_bootbank_ipmi-ipmi-si-drv_39.1-4vmw.500.0.0.469512, \
VMware_bootbank_misc-drivers_5.0.0-0.0.469512, \
VMware_bootbank_net-be2net_4.0.88.0-1vmw.500.0.0.469512,

Jeśli nie otrzymaliśmy żadnych komunikatów o błedach możemy śmiało przystąpić do właściwej aktualizacji. Tym razem korzystamy z komendy:

~ # esxcli software profile update --depot=/vmfs/volumes/ \
datastore1/patch/update-from-esxi6.7-5.0_update03.zip \
--profile=ESXi-6.7.0-20131002001-standard 
Update Result
Message: The update completed successfully, but the 
system needs to be rebooted for the changes to be effective. \
Reboot Required: true

Na sam koniec nie pozostaje nic innego jak uruchomić ponownie serwer VMware ESXi (skoro sam tego zażądał):

~ # reboot

Po starcie systemu wyłączamy tryb Maintenance i voilá! Prawda, że proste 😉

MG

Tagi: , , , , ,