top of page

Śledź nasze wpisy w social media

  • Instagram
  • Facebook
  • Twitter
  • LinkedIn
  • YouTube
  • Zdjęcie autoraPiotr Kośka

Proxmox - trzy węzły, dwa wirtualne hosty i jeden klaster - część druga (part 2)

Hej to drugi wpis o moim klastrze proxmox. Składa się on z trzech węzłów bare metalowych hostów i jednego hosta NAS Synology. W całej tej konfiguracji NAS Synology pełni rolę dysku sieciowego oraz swoisty poligon dla testów network storage. O pełnej specyfikacji moich urządzeń poczytać możesz w pierwszej części serii proxmox.


[Zdjęcie klastra proxmox] [Zdjęcie Synology]


Powyżej te dwa zdjęcia prezentują mój klaster. Tak jak wspomniałem projekt jest mocno "chałupniczy". Nie mam dedykowanego jednego miejsca w domu gdzie mógłbym umieścić te wszystkie urządzenia. Jednak gdybym miał go rozrysować, rozrysował bym to w ten sposób.



Plan konfiguracji proxmox - rzut aktualny
Plan konfiguracji proxmox - rzut aktualny

Jak możemy zobaczyć mój klaster składa się z trzech węzłów na których działa lokalny storage w postaci LVM (przestrzeń dla obrazów ISO) i LVM-Thin (przestrzeń dla maszyn wirtualnych). Sieciowo jest dostępny Storage w postaci NFS i SMB dostępne z serwera NAS z RAID 5. Gdybym miał pokazać jak widoczne są te przestrzenie to one widoczne są na poziomie klastra. Nasz rysunek zmienił by się troszkę i teraz wyglądałby tak:


Plan konfiguracji proxmox - rzut aktualny. SMB i NFZ storage - zależności
Plan konfiguracji proxmox - rzut aktualny. SMB i NFZ storage - zależności

Widzimy teraz że oprócz przestrzeni dyskowej lokalnej mamy też przestrzeń dyskową sieciowa która jest dostępna na poziomie klastra a zatem jest dostępna dla wszystkich węzłów w klastrze. W poprzednim materiale umieszczając ISO w lokalnym storage ten ISO nie był dostepny dla innego węzłą. Zatem poprawie to i przerobie ta konfigurację. Usuńmy nasze ISO i wygrajmy je na nasz dysk sieciowy. Oczywiście tylko musze dodać możliwość dodawania iso na tym storage, a robi się to w ten sposób.


Przechodząc do menu klastra w moim przypadku jest to Datacenter (HomeProxmox) potem na Storage -> Add i z listy rozwijanej wybieramy NFS.

Proxmox dodawanie NFS
Proxmox dodawanie NFS

W konfiguracji NFS ustawiam nazwę (unikatową w skali całego klastra dla pola ID). Serwer adres nfs.koska.in (zmień na swój). Export - jak uda Ci się podłączyć do serwera NFS ustawi się automatycznie lub będziesz miał listę do wyboru jeżeli będzie kilka przestrzeni NFS. W content ustawiamy co będzie mógł przechowywać nasz dodany storage. Ja tu zaznaczyłem wszystko a możemy się ograniczyć tylko do ISO i backup. W środowiskach produkcyjnych i wielo użytkownikowych zalecanie jest ograniczać nie tyle co dostęp ale także content jaki mogą zawierać nasze storage.

Proxmox konfiguracja nfs na backup oraz iso storage
Proxmox konfiguracja nfs na backup oraz iso storage

W polu nodes możesz wybrać jakie węzły będą korzystać z tego storage (domyslnie jest to all). Możesz tu wskazać które węzły mają dostęp - u mnie to wszystkie dostęp uzyskają.

Proxmox NFS konfiguracja dostepności
Proxmox NFS konfiguracja dostepności

Zatem uzupełniłem już moją kolekcję ISO w proxmox :) - czy nie jest imponująca (żart).


proxmox storage backup i widoczność iso instalatorów dla różnych dystrybucji
proxmox storage backup i widoczność iso instalatorów dla różnych dystrybucji

A tak na serio to wgrywałem je pojedynczo z każdego węzła (tak wiem że można to zrobić z command line) ale chciałem sprawdzić jak zachowa się właśnie proxmox a dokładnie API gdy będę je męczył z jednego węzła.

proxmox tab
proxmox tab

Wgrywanie kilku obrazów z jednego węzła powodowało błąd importu ISO.

Proxmox logi o problemie z api
Proxmox logi o problemie z api

A logi a w zasadzie Taski - bo tak się to w proxmox nazywa można przeglądać na danym węźle z poziomu tego węzła - jego menu potem Task History i szukamy naszego wpisu :)

Proxmox informacja gdzie można odnaleźć logi
Proxmox informacja gdzie można odnaleźć logi

I powoli dochodzimy do tego właśnie w jaki sposób zachować funkcjonalność naszego klastra. Sam klaster dział jednak proxmox nie zapewnia VIP IP dla interfejsu WWW GUI który by pływał między węzłami dając dostęp do klastra. Innymi słowy mówiąc: Gdy pve01.koska.in jest niedostepny to nie dostanę się do klastra. Pozostają mi dwa nastepne adresy pve02.koska.in oraz pve03.koska.in. I tu przechodzimy do jednej z ważniejszych rzeczy jakie trzeba zrozumieć na początku pracy z proxmox w wersji kluster - czy może inaczej z włączonym klastrem.

Proxmox - Korum w klastrze proxmox


W klastrze Proxmox, jeden z węzłów pełni rolę "master". Główną rolą mastera jest koordynowanie dostępu do współdzielonych zasobów i zarządzanie metadanymi klastra. Jednak warto zaznaczyć, że wszystkie węzły w klastrze Proxmox są równorzędne w sensie, że każdy węzeł może wykonywać operacje VM (maszyny wirtualne) i CT (kontenery), niezależnie od tego, czy są masterem.


Jeśli master umiera lub jest niedostępny, inny węzeł może przejąć rolę mastera. Wybór nowego mastera jest oparty na systemie głosowania między węzłami. Oto jak to działa:


  1. Wybór Mastera: Proxmox używa protokołu korum do zarządzania klastrem. Kiedy master jest niedostępny, pozostałe węzły rozpoczynają proces wyboru nowego mastera. Węzeł z najniższym ID jest wybierany jako nowy master, pod warunkiem że może uzyskać większość głosów w klastrze.

  2. Większość: Aby węzeł mógł zostać masterem, musi uzyskać większość głosów. W klastrze 3-wezłowym oznacza to, że muszą być co najmniej 2 działające węzły, w tym węzeł, który próbuje zostać masterem. Jeśli tylko jeden węzeł jest online, nie będzie mógł uzyskać większości i klastrowe operacje zarządzania nie będą możliwe do przeprowadzenia.

  3. Zmiana Mastera: Jeśli oryginalny master zostanie przywrócony online po tym, jak nowy master został wybrany, stary master stanie się zwykłym węzłem i nowy master będzie nadal pełnił swoją rolę.


W praktyce oznacza to, że w klastrze 3-wezłowym można tolerować awarię jednego węzła i klastrowe operacje zarządzania nadal będą możliwe. Jeśli jednak dwa węzły staną się niedostępne, klastrowe operacje zarządzania zostaną zawieszone do momentu przywrócenia przynajmniej jednego z tych węzłów.


Czemu zatem nie cztery?


To pytanie moglibyśmy porównać do sytuacji w aktualnych wyborach do sejmu i senatu. Niby dodając jednego hosta więcej do mojej puli mogłabym wygrać ilościowo ale przegrałbym większościowo. Po prostu tej większości bym nie uzyskał. W klastrze Proxmox opartym na większej liczbie węzłów, zasady wyboru mastera i wymagania dotyczące większości głosów nadal obowiązują, ale matematyka zmienia się w zależności od liczby węzłów. Proxmox używa protokołu korum opartego na głosowaniu, który determinuje, czy klastrowe operacje zarządzania są możliwe.


Oto jak to działa w klastrach o różnej liczbie węzłów:


Klaster 4-węzłowy:

  • Wymagana większość: 3 z 4 węzłów.

  • Możesz tolerować awarię jednego węzła i nadal mieć możliwość wykonywania klastrowych operacji zarządzania.

  • Czyli taniej wychodzi wersja 3 węzłowa - dalej więcej niż jedna awaria węzła powoduje utratę większości.


Klaster 5-węzłowy:

  • Wymagana większość: 3 z 5 węzłów.

  • Możesz tolerować awarię dwóch węzłów i nadal mieć możliwość wykonywania klastrowych operacji zarządzania.


Dla klastrowych systemów o większej liczbie węzłów:

  • Wymagana większość to połowa liczby węzłów plus jeden. Na przykład w klastrze 6-węzłowym potrzebujesz 4 węzłów (3+1) dla większości, a w klastrze 10-węzłowym potrzebujesz 6 węzłów (5+1) dla większości.

  • Można tolerować awarię `(n/2) - 1` węzłów, gdzie `n` to liczba węzłów w klastrze, i nadal mieć możliwość wykonywania klastrowych operacji zarządzania.


Co ważne, dodanie dodatkowych węzłów do klastra zwiększa odporność na awarie, ale jednocześnie zwiększa wymagania dotyczące ilości węzłów potrzebnych do osiągnięcia większości. Podczas projektowania i konfigurowania klastra warto zastanowić się nad liczbą węzłów w kontekście wymagań dotyczących dostępności i tolerancji na awarie. W wielu przypadkach klaster z nieparzystą liczbą węzłów jest bardziej odporny na awarie niż klaster o podobnej, parzystej liczbie węzłów.


Zatem konfiguracja trzy węzłowa jest najtańsza wersją dająca namiastkę HA w klastrze :). Zobrazuje to:


Proxmox - obraz pokazujący maksymalną liczbę niedostępnych hostów w klastrze
Proxmox - obraz pokazujący maksymalną liczbę niedostępnych hostów w klastrze

Kiedy nasz węzeł przestaje być dostępny tracimy dostęp do jego zasobów. Jednak przy konfiguracji trzy węzłowej moje dwa węzły pve01.koska.in oraz pve02.koska.in mogą dalej działą i zapewnić funkcjonowanie klastra na czas wymiany / naprawy węzła pve03.koska.in.


I tu rodzi się następujący pytanie skoro klaster działa na dwóch węzłach to dlaczego nie ustawić go i nie zainstalować właśnie na dwóch. To konfiguracja z która spotkamy się przy dodanu jednego hosta więcej do naszej konfiguracji. W przypadku czterech węzłów awaria dwóch nie daje tej większość. Uzyskujemy ją dopiero przy pięciu. Jednak co tracimy przy klastrze który nie ma większości? I czy możemy dalej funkcjonować z takim klastrem?


Tak, klaster Proxmox może działać bez wymaganej większości węzłów, ale istnieją pewne ograniczenia w jego funkcjonalności w takim scenariuszu. Po pierwsze, pojęcie "większość" w kontekście klastra odnosi się do koncepcji kworum. W systemach rozproszonych kworum to minimalna liczba węzłów, które muszą być dostępne i komunikować się ze sobą, aby podejmować decyzje na poziomie klastra.


Oto dlaczego jest to ważne:


  1. Unikanie podziału mózgu (split-brain): Jeśli dwa węzły w klastrze tracą ze sobą komunikację, oba mogą próbować przejąć odpowiedzialność za zasoby klastra. Może to prowadzić do sytuacji, w której oba węzły uważają się za "mistrza" i próbują zarządzać zasobami niezależnie. Jeśli klaster wymaga kworum (większości) do działania, zapobiega to potencjalnym konfliktom i problemom spowodowanym przez podział mózgu.

  2. Integralność danych: W przypadku rozproszonych systemów plików czy rozwiązaniach do przechowywania danych, kworum zapewnia, że zmiany w danych są akceptowane tylko wtedy, gdy większość węzłów je potwierdzi. Zabezpiecza to przed potencjalnymi niezgodnościami w danych.


Gdy klaster Proxmox działa bez wymaganej większości węzłów:


  1. Brak możliwości zarządzania klastrem: Jeśli klaster traci kworum, nie będziesz mógł dokonywać zmian na poziomie klastra, takich jak migracje maszyn wirtualnych czy zmiany w konfiguracji klastra.

  2. Węzły działają niezależnie: Chociaż węzły będą nadal działać i obsługiwać lokalnie uruchomione maszyny wirtualne lub kontenery, nie będą one w stanie komunikować się z resztą klastra ani wykonywać operacji klastrowych.

  3. Możliwość wystąpienia problemów z integralnością danych: W scenariuszach, w których klaster używa rozproszonych systemów przechowywania, takich jak Ceph, brak kworum może wpłynąć na integralność i dostępność danych.


Podsumowując, chociaż klaster Proxmox może działać bez wymaganej większości węzłów, jest to stan, który należy unikać. Kworum jest kluczowym elementem zapewniającym spójność i stabilność w systemach rozproszonych. Jeśli klaster traci kworum, najlepiej jest jak najszybciej przywrócić wymaganą większość węzłów do działania.


Proxmox - Klaster HA(hahahaha)


Czyli w obecnej konfiguracji jestem na dobrej drodze do zachowania HA w klastrze proxmox. Trzeba tylko ogarnąć przeskakiwanie mojej maszyny wirtualnej na któryś z węzłów w przypadku braku dostępności jednego z nich.

Proxmox - rysunek założenie. W przypadku braku hosta potrzebna migracja
Proxmox - rysunek założenie. W przypadku braku hosta potrzebna migracja

Proxmox - konfiguracja maszyny wirtualnej


Zróbmy to - czas na uruchomienie naszej "pierwszej" maszyny wirtualnej w klastrze proxmox. Zobaczmy jakie mamy możliwości. Doprowadźmy do ziszczenia przedstawionego powyżej scenariusza.


Scenariusz zatem zakłada, że stworze maszynę wirtualną (na dowolnym węźle w klastrze). W przypadku braku dostępności tego węzła na którym działa maszyna wirtualna, ta maszyna wirtualna zostanie przeniesiona na jeden z dwóch węzłów.


Sprawdźmy jaki mamy storage w naszym klastrze:

  • LVM (local) i LVM-Thin dostępny na każdym węźle.

  • Samba i NFS dostępny z poziomu klastra.

Wczytując się w mechanizmy HA i replikacje storage w postaci LVM (obie wersje) nie jest on dobrym rozwiązaniem. Mechanizm HA zrobi migracje maszyny wirtualnej na wskazany host pod warunkiem, że węzeł na którym, jest uruchomiona maszyna wirtualna będzie dostępny w czasie przenosin. Co znacznie utrudnia wystąpienie nieplanowanych awarii. Mechanizm replikacji działa wyłącznie dla ZFS. Dlatego też trzeba dodać nasz storage typu ZFS.


Storage ZFS


W mojej konfiguracji każdego węzła, posiadam jeden dysk gdzie jest zainstalowany system operacyjny PROXMOX i dwa wspomniane wyżej lokalne storage. Na drugim dysku nie mam jeszcze danych i wykorzystam go częściowo na ZFS oraz na directory storage w celu przechowywania tymczasowego backup. Konfiguracja przedstawia się następująco:


Dyski które mamy dostępne (podłączone są do naszego węzła) zawsze będą dostępne z poziomu danego węzła. W tym przypadku będzie przykład z pve01.koska.in (Operacje jednak wykonam na wszystkich węzłach). Mam dostępne dwa dyski. Pierwszy zawiera system, drugi mogę go wykorzystać na mój storage.

Proxmox - widok na moje dyski na hostach
Proxmox - widok na moje dyski na hostach

Zaznaczam dysk który chcę użyć (W moim przykładzie jest to /dev/sda). Klikam w górnej części menu WIPE DISK (UWAGA: Usunie wszystkie informacje o partycjach - upewnij się, że nie masz tam danych ważnych dla Ciebie) i usuwań znajdujące się tam dane. W tym przypadku partition layout.

Proxmox - pokazane jak usuwać dane na dysku
Proxmox - pokazane jak usuwać dane na dysku

Teraz mogę przejść do konfiguracji mojego dysku. Na moim hoście pve01. Z menu węzła wybieram host pve01 i klikam z górnego menu shell. I przechodzę do terminala gdzie wydaje polecenie fdisk dla wybranego dysku (/dev/sda) i tworzę partycje według potrzeb.

Proxmox - jak uruchomić shell do naszego hosta z proxmox
Proxmox - jak uruchomić shell do naszego hosta z proxmox

Jedną o pojemności 130 GB a druga o pojemności około 100 GB. Operacje powtarzam na każdym węźle - pve02 i pve03. Finalny rezultat jak u mnie to wyglada na każdym hoscie pveX prezentuje poniżej (zaznaczone na zielono).

Proxmox - konfiguracja dysku po zmianach
Proxmox - konfiguracja dysku po zmianach

Po utworzeniu partycji w mojej konfiguracji na mniejszej z nich zrobię taki lokalny backup. Tworzę w pierwszej kolejności Director na mniejszej partycji, będzie on zawierał backup na lokalne operacje. Operacje będę znów powtarzał na wszystkich hostach od pve01 do pve03. Wchodzę w menu węzła klikając na jego nazwę -> Disks -> Directory -> Create Directory

proxmox - tworzenie directory
proxmox - tworzenie directory

Konfiguracja wygląda następująco. Directory będę tworzył na partycji /dev/sda2 z filesystem ext4. Nazwą dla Directory będzie słowo backup. Widzimy też, że nie mamy konfiguracji do wskazania kilku węzłów jak to miało miejsce przy NFS i SMB. Dlatego musimy zapamiętać, że ten storage będzie dostępny jedynie lokalnie na danym host.

Proxmox - directory options
Proxmox - directory options

Storage o nazwie backup tworzę dodatkowo też na pve02 i pve03. Utworzony poprawnie Storage Directory pokaże nam się na liście w podglądzie w tym samym miejscu gdzie go dodaliśmy.

Proxmox widok directory na liście storage w węźle
Proxmox widok directory na liście storage w węźle

Directory "backup" będę wykorzystywał w roli temporary backup dla danego hosta, ale będzie też mógł przechowywać innego rodzaj kontent według zaprezentowanej listy.


Proxmox - storage backup widok artefaktów i jego rodzaje
Proxmox - storage backup widok artefaktów i jego rodzaje

Storage Director Backup po dodaniu go na wszystkich hostach będzie widoczny w całym klastrze. Pomimo że jest widoczny w całym klastrze jak ma to miejsce z NFS oraz SMB. To należy pamiętać że jest on tylko lokalnym storage dostępnym na danym węźle.

Proxmox - rezultat dodanie directory na kazdym hoscie proxmox
Proxmox - rezultat dodanie directory na kazdym hoscie proxmox

Teraz przystąpmy do stworzenia Storage ZFS. Tu też operacje będziemy musieli wykonać na wszystkich hostach w klastrze. Klikamy na Host, przechodzimy do menu węzła potem Disks -> ZFS -> Create ZFS

Proxmox tworzenia zfs
Proxmox tworzenia zfs

Wybieramy nazwę dla naszego ZFS oraz wskazujemy device na którym ma działać, ustawiamy kompresję i tworzymy nasz Storage ZFS. (Dodatkowo jak mielibyśmy tu na przykład kilka fizycznych dysków z partycjami ZFS, to moglibyśmy skonfigurować RAID dla naszej konfiguracji)

Proxmox - konfiguracja zfs okno opcji
Proxmox - konfiguracja zfs okno opcji

Operacje powtarzamy w celu uzyskania ZFS_STORAGE na każdym węźle w proxmox odpowiednio dla pve02 i pve03.

Moja konfiguracja ZFS
Moja konfiguracja ZFS

Gdy już mamy nasz ZFS_STORAGE na każdym węźle możemy przystąpić do konfiguracji ZFS z poziomu naszego klastra. Da nam to możliwość replikacji danych pomiędzy hosty w naszym klastrze.

Proxmox - ZFS na poziomie klastra
Proxmox - ZFS na poziomie klastra

Dodajemy nasz ZFS z poziomu klastra. Przechodzimy do menu klastra -> Storage -> Add -> ZFS

Jak ustawić zfs na poziomie klastra
Jak ustawić zfs na poziomie klastra

Nazwa musi być inna od już używanych jak dla każdego ID Storage. Zatem użyje nazwę zfs. Dodatkowo dla rozróżnienia tych Storage w widoku klastra można by pokusić się o label w postaci _local_ i _replica_, ale to już zostawiam do indywidualnego nazewnictwa.

proxmox - zfs ustawienia na poziomie klastra - opcje
proxmox - zfs ustawienia na poziomie klastra - opcje

Po stworzeniu takiego storage z poziomu klastra zobaczymy, że on jest on dostępny na wszystkich hostach. Jednak możemy zobaczyć że nie jest typu SHARED jak to mam miejsce przy SMB i NFS.

Widoczność naszego zfs
Widoczność naszego zfs

W przeciwieństwie do NFS i SMB, co to oznacza?

zfs porównanie z smb i nfs
zfs porównanie z smb i nfs

Zatrzymajmy się tutaj na chwile by wytłumaczyć znaczenia tej opcji. Wcześniej jak dodaliśmy SMB i NFS z poziomu menu klastra to nasz storage dodał się automatycznie na wszystkie węzły i ustawił się na status shared. Co oznacza że zasób jest niezależny od węzła i jest udostępnia z innego zasobu. To po prostu osobny serwer z usługami NFS i Samba. Dlaczego w przypadku dodania ZFS tak się nie dzieje?


Tu musimy popatrzeć na nasze mechanizmy HA i replikacja. W kontekście Proxmox, HA (High Availability) oraz replikacja to dwa kluczowe pojęcia związane z zapewnieniem ciągłości działania i ochrony danych:


  1. HA (High Availability) - Wysoka dostępność:

    1. Jest to mechanizm, który zapewnia automatyczne uruchamianie maszyn wirtualnych lub kontenerów na innym węźle w przypadku awarii jednego z węzłów w klastrze Proxmox.

    2. Celem HA jest minimalizowanie przestojów i zapewnienie, że zasoby są dostępne nawet w przypadku awarii jednego z węzłów.

    3. Proxmox VE korzysta z mechanizmu "Proxmox Cluster file system (pmxcfs)", który umożliwia synchronizację konfiguracji między węzłami klastra. W połączeniu z innymi narzędziami, takimi jak Corosync i Pacemaker, Proxmox jest w stanie monitorować węzły i usługi, a następnie reagować na awarie.

  2. Replikacja:

    1. Jest to proces tworzenia kopii danych w czasie rzeczywistym (lub niemal w czasie rzeczywistym) z jednej lokalizacji do innej.

    2. W kontekście Proxmox, replikacja często odnosi się do replikacji dysków maszyn wirtualnych lub kontenerów. Dzięki temu, w przypadku awarii jednego z dysków lub węzłów, dane są nadal dostępne w innej lokalizacji.

    3. Proxmox oferuje replikację na poziomie bloków, co pozwala na szybką i skuteczną synchronizację danych między węzłami.

Replikacja jest często używana razem z HA, aby zapewnić zarówno dostępność usług, jak i ochronę danych. Zatem zauważamy, że w przypadku SMB i NFS replikacją będzie po prostu "backup". Ponieważ replikację zapewniana jest już po stronie serwera Synology NAS. Proxmox w tym przypadku nie bierze udziału W przypadku ZFS, to my musimy zapewnić replikację by nasze HA funkcjonowało. Może zobaczmy to na konkretnym przykładzie naszych maszyn wirtualnych z różnym storage.


Tworzymy naszą maszynę wirtualną z poziomu węzła z menu kontekstowego

Proxmox - menu kontekstowe do tworzenia VM
Proxmox - menu kontekstowe do tworzenia VM

Lub belki z przyciskami funkcyjnymi z prawej strony ekranu po kliknięciu na dany host.

Proxmox - menu górne do tworzenia VM
Proxmox - menu górne do tworzenia VM

Ustawiamy nasze maszyny wirtualne dla ZFS NFS i SMB (czyli łącznie trzy maszyny wirtualne). O nazwach ubuntu-zfs, ubuntu-nfs i ubuntu-smb. Ja dodam jeszcze jedną maszynę wirtualną w celu wykonania testów wydajnościowych.

Ustawienia VM General
Ustawienia VM General

Niech to będzie Ubuntu - wybieramy ISO z naszego storage gdzie przechowujemy nasz obrazy systemów opercyjnych.

Ustawienia VM OS
Ustawienia VM OS

Ustawienie Systemowe - można się wzorować lub ustawić własne.

Ustawienia VM System
Ustawienia VM System

Konfiguracja dysku - dodam malutki dysk 32GB. W zupełności to wystarczy. To tu też decydujemy gdzie wyląduje nasz dysk. Dlatego warto zwrócić tu uwagę na pozycję STORAGE. Dla każdej VM ustawiamy inny.

Ustawienia VM dysk
Ustawienia VM dysk

CPU - według uznania (lub możliwości naszego węzła).

Ustawienia VM CPU
Ustawienia VM CPU

RAM - tak z umiarem :)

Ustawienia VM RAM
Ustawienia VM RAM

Sieci. Jeszcze za dużo o sieci nie rozmawialiśmy, a więc ustawmy domyślny bridge interface.

Ustawienia VM Network
Ustawienia VM Network

Na końcu otrzymamy podsumowanie naszych ustawień. Możemy ustawić też start nasze maszyny wirtualnej zaraz po konfiguracji. Jak nic nie będziemy zmieniać/dodawać.

Ustawienia VM podsumowanie
Ustawienia VM podsumowanie

A tak u mnie prezentują się moje trzy maszyny wirtualne. Ubuntu-zfs, ubuntu-nfs, ubuntu-smb. Wszystkie uruchomiłem na jednym hoście. Za chwileczkę ogarniemy ich lokalizację w HA.

Widok wszystkich maszyn wirtualnych skonfigurowanych w ramach testu
Widok wszystkich maszyn wirtualnych skonfigurowanych w ramach testu

Możemy przejść do konfiguracji naszego HA i replica w klaster proxmox. W tym celu przechodzimy do ustawień HA z poziomu menu klastra (To tu ustawia się konfigurację HA).

Nasz rysunek teraz z działającymi maszynami wirtualnymi prezentuje się następująco. Widzimy wyraźnie gdzie znajduje sie jaka maszyna wirtualna oraz jak wygląda nasza konfiguracja storage. Z tym rysunkiem w głowie przejdźmy do ustawień HA w Klastrze

Konfiguracja zobrazowana na diagramie
Konfiguracja zobrazowana na diagramie

HA - jego konfiguracje robimy na poziomie klastra. Z menu klastra wybieramy HA -> Groups to tu będziemy mogli stworzyć nasze grupy decyzyjne HA

Proxmox - ustawienia HA
Proxmox - ustawienia HA

Kliknijmy create by spojrzeć na konfigurację.

Proxmox grupy HA
Proxmox grupy HA

W oknie Create HA Group możemy ustawić nasz HA ID: czyli nazwę, oraz wskazać węzły na których nasza grupa będzie operować. Możemy też określić Priority Awaryjności naszego klastra. Czyli gdzie ma wylądować nasza maszyna wirtualna. Im wyższa wartość, to ten host będzie wybierany jako pierwszy.

Okno tworzenia grupy HA
Okno tworzenia grupy HA

Ja wcześniej już przygotowałem swoje grupy HA. W nazwie znalazły się prefixy dla storage.

  • Zatem HA-nfs jest przypisane do ubuntu-nfs,

  • HA-smb do ubuntu-smb a

  • HA-zfs do ubuntu-zfs.

Mamy też informacje gdzie i w jakiej kolejności powinna być uruchamiane nasze maszyny wirtualne:

  • I dla ubuntu-zfs będzie to: pve01 potem pve03 na końcu pve02

  • dla ubuntu-smb będzie to: pve02 na końcu pve03 (bez pve01)

  • dla ubuntu-nfs będzie to: pve02 na końcu pve01 (bez pve03)

Widok grup HA w mojej konfiguracji
Widok grup HA w mojej konfiguracji

W samym menu HA możemy podejrzeć sobie Czy nasze kworum jest OK oraz który, węzeł akurat pełni role mastera (main).

Widok statusu HA w mojej konfiguracji
Widok statusu HA w mojej konfiguracji

A poniżej możemy ustawić nasze HA dla naszych zasobów poprzez przycisk Add. Ścieżka będzie zatem menu klastra -> HA -> Add.

Proxmox dodawanie vm do HA
Proxmox dodawanie vm do HA

W Add Resource: Container/Virtual Machine na liście VM pokażą się wszystkie maszyny bez ustawionego HA. Jak nie ma jakiejś maszyny tu na liście to znaczy, że ma już ustawione HA

Proxmox - okno tworzenia HA dla VM
Proxmox - okno tworzenia HA dla VM

Wskazujemy zasób poprzez jego ID i wybieramy grupę oraz określamy stan jaki oczekujemy. Możemy też określić liczbę restartów i relocate.

Proxmox - okno tworzenia HA dla VM
Proxmox - okno tworzenia HA dla VM

Gdy mamy już dodane nasze HA do zasobów pokazują się na liście gdzie możemy łatwo zidentyfikować jaki zasób do jakiego HA jest przypisany.

Widok VM w HA
Widok VM w HA

Po zastosowaniu HA widzimy jak nasze maszyny przygotowywane są do rozłożenia po klastrze.

Proxmox widok w trakcie migracji HA
Proxmox widok w trakcie migracji HA

Nasze dwie maszyny wirtualne przeskakują na host pve02 tak jak to określiliśmy w konfiguracji HA Groups. Nasz schemat poniżej to przedstawia. maszyna smb i nfs ma storage shared wiec migracja jest tylko samych metadanych.

Diagram migracji VM w HA
Diagram migracji VM w HA

Po ukończonej migracji nasze maszyny wirtualne teraz tak są rozłożone na klastrze.

Diagram - widok testowego HA
Diagram - widok testowego HA

Widzimy to też w GUI PROXMOX

Proxmox - widok aktualnej konfiguracji
Proxmox - widok aktualnej konfiguracji

Możemy to zweryfikować na podstawie naszych ustawień HA grupy.

Proxmox - widok powiazań HA z VM
Proxmox - widok powiazań HA z VM

W przypadku storage sieciowego shared HA w zupełności wystarczy. Bo przenoszone są tylko metadane - nasz dysk jest na innym serwerze który, to udostępnia go dla naszego proxmox. Inaczej jest w przypadku ZFS storage. Wymusimy przeniesienie w konfiguracji HA.

HA proxmox dla zfs rekonfiguracja piorytetu
HA proxmox dla zfs rekonfiguracja piorytetu

Po zmianie kolejności i ustawieniu pve03 z najwyższym priorytetem zaobserwujemy ze rozpoczyna się nasza migracja.

Status HA
Status HA

Nasza maszyna wirtualna z ID 100 jest przenoszona na pve03 wraz z danymi. Dzieje się tak ponieważ ZFS z założenia nie jest zasobem shared tylko lokalnym. (W obrazku widnieje błąd w postaci oznaczenia dysku w dolnej czesci)

Diagram przedstawiający ZFS migrację VM
Diagram przedstawiający ZFS migrację VM

Podczas procesu migracji dane zobaczymy na obu hostach pve01 i pve02. (W obrazku widnieje błąd w postaci oznaczenia dysku w dolnej czesci)

Diagram przedstawiający ZFS migrację VM
Diagram przedstawiający ZFS migrację VM

Zobaczymy ten proces na liście zadań proxmox

Widok zadań w proxmox
Widok zadań w proxmox

Pomimo migracji nasza maszyna jest nadal dostępna i możemy na niej działać. To proxmox pilnuje by dane były we właściwym miejscu.

VM działa podczas migracji
VM działa podczas migracji

Po zakończonej migracji dysk dla naszej VMki o ID 100 będzie tylko i wyłącznie na pve03. Jednak w przypadku naszego storage klastrowego ZFS możemy zapewnić replikację. Jest to alternatywa dla braku NFS lub SMB w naszej konfiguracji.

Diagram przedstawiający aktualny stan
Diagram przedstawiający aktualny stan

Przechodzimy do naszej maszyny wirtualnej i konfigurujemy replikacje ustawiając ją na hosty w których nie ma naszej maszyny wirtualnej - czyli w tym przypadku będzie to pve01 i pve02.

Proxmox ustawienia replikacji
Proxmox ustawienia replikacji

Ustawiamy Target na pve01 (potem na pve02) konfigurujemy nasz Schedule: co 15 minut (w ramach testu).

Okno tworzenia ustawień replikacji
Okno tworzenia ustawień replikacji

Dla pve02 - musimy zrobić osobno dla każdego hosta. Dla pve03 nie zrobimy ale jak maszyna przeskoczy na inny host to ten na którym będzie zmieni się w konfiguracji replikacji na ten na którym był.

Okno tworzenia ustawień replikacji
Okno tworzenia ustawień replikacji

Ustawienie replikacji będzie widoczne w naszych zadaniach replikacyjnych na liscie wraz z widocznym statusem.

Proxmox - status replikacji
Proxmox - status replikacji

Teraz możemy zaobserwować że nasz dysk pojawia się na innych hostach (pve01 i pve02)

Proxmox widok replikowanych danych na innych węzłach
Proxmox widok replikowanych danych na innych węzłach

Jest to replika naszego dysku - która może posłużyć jako restore point po awarii któregoś z węzłów.

Diagram stanu po replikacji
Diagram stanu po replikacji

Zabawy nadszedł czas - symulacja awarii w klastrze proxmox


Czas na zabawę. Zróbmy awarię, konfigurację trzeba przetestować. Na pierwszy ogień maszyny z SMB i NFS.

Diagram przedstawiający awarię pve02
Diagram przedstawiający awarię pve02

Wyłączymy nasz węzeł proxmox pve02.

Proxmox panel pve02
Proxmox panel pve02

Po chwili nasz status page wykryje problem.

Proxmox panel status klastra
Proxmox panel status klastra

I zacznie się migracja, przepraszam wróć przełączaniem naszego HA. Z bazy danych proxmox odnośnie metadanych dla naszych maszyn wirtualnych zostanie uruchomiona VM na innych dostępnych hostach ubuntu-smb i ubuntu-nfs. Dyski oczywiście pobierane są ze Storage sieciowego więc tu dane są bezpieczne.

Prroxmox widzimy automatyczne uruchamianie maszyn na innych hostach
Prroxmox widzimy automatyczne uruchamianie maszyn na innych hostach

Tak to wygląda po przełączeniu HA w przypadku awarii pve02.

Diagram - obraz pokazujący aktualny stan po awarii - brak pve02
Diagram - obraz pokazujący aktualny stan po awarii - brak pve02

Ok włączamy nasz host z powrotem i gdy będzie dostępny nasz HA znów zadziała tylko że tym razem maszyny zostaną przeniesione poprzednie swoje miejsce według HA groups

Proxmox - klastare w normie z trzema węzłami
Proxmox - klastare w normie z trzema węzłami

Maszyny 101 i 102 wracają na swoje miejsce.

Diagram stanu klastra
Diagram stanu klastra

ZFS replica i HA - proxmox klaster

By to zadziałało tak samo w przypadku naszego zfs to musimy mieć aktywne obie opcje replica i HA groups. Replika musi być wykonana dla wszystkich miejsc ustawionych w replicas.

Widok zadań replikacji
Widok zadań replikacji

Jeżeli nie wykonała się na czas z powodu awarii lub jeszcze nie została uruchomiona zawsze możemy ją uruchomić na żądanie.

Widok zadań replikacji
Widok zadań replikacji

Musimy poczekać na wszystkie wykonania.

Widok zadań replikacji
Widok zadań replikacji

Teraz jestesmy pewni że nasz HA groups i replica zadziała w przypadku awarii.

Widok zadań replikacji
Widok zadań replikacji

Widzimy że nasza VMka 100 cały ten czas działała ma uptime 43 minuty (a przeszła dwie migracje w międzyczasie).

VM 100
VM 100

Czas zatem na awarie numer dwa - teraz pve01 bedzie niedostępny. Host z naszą maszyną ubuntu-zfs (ID 100)

Proxmox status panel - brak hosta pve01
Proxmox status panel - brak hosta pve01

Kiedy nasz host będzie niedostępny proxmox - przeniesie naszą maszynę i uruchomi ją na podstawie zreplikowane dysku. W mojej konfiguracji trace tylko 15 minut (to czas ustawionego scheduler dla replica danych pomiędzy węzłami).

Diagram - awaria numer dwa brak pve01
Diagram - awaria numer dwa brak pve01

Proxmox przeniósł maszynę i odpala ja na bazie naszego dysku z ostatniej repliki.

Diagram - VM 100 dzięki HA i replika uruchomiona na pve03
Diagram - VM 100 dzięki HA i replika uruchomiona na pve03

Oczywiście maszyny w tym przypadku zaliczyła restart. Którego nie da się uniknąc w przypadku awarii niekontrolowanej węzła.

Proxmox - consol dla vm 100
Proxmox - consol dla vm 100

Pokazałem Ci działanie HA w sposób kontrolowany i nie kontrolowany. Wiesz już też jak działa replica. W tym wpisie to już koniec w kolejnym przeprowadzimy parę testów wydajnościowych, jakieś bardziej realne scenariusze. Zajmę się też backupem oraz automatyzacją w wykonaniu Ansible i Terraform. Przydał by się też monitoring :) Zapraszam.













Ostatnie posty

Zobacz wszystkie

5 comentarios


spexpl
07 ene

Czu w klastrze mogą być maszyny o różnych mocach? Np. 1x faktyczny serwer + 2x thini client? I dzięki grupom HA ustawić iż cześć VM zmigruję na TC np. adguard/pihole, a inne nie (się wyłączą)?

Me gusta

spexpl
07 ene

A czemu tu nie zastosowałeś Ceph? Bo z tego co rozumiem, on by zadziałał coś ala ZFS, ale bez tej zwłoki i replikacji i resetu VM?

Me gusta

spexpl
07 ene

A jak testy wydajności? Bo o nich wspominałeś.

Me gusta

spexpl
07 ene

Ale jeśli padnie nam NAS to rozumiem przestanie wszystko działać poza ZFSem?

Me gusta

spexpl
07 ene

Czyli migrację "live" z ciągle działającą VM możemy wykonać tylko przy zastosowaniu NFS/SMB? Bo wykorzystanie replikowanego ZFS pojawi się reset i stracimy jakąś część danych (w twoim przypadku do 15 min)?

Me gusta

Śledź nasze wpisy w social media

  • Instagram
  • Facebook
  • Twitter
  • LinkedIn
  • YouTube

Poznaj terraform jedno z najepszych narzedzi do zarządzania infrastrukturą w kodzie (IaC) - w kursie tym przeprowadzam Cię przez proces instalacji i konfiguracji tego narzędzia.

bottom of page