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.
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:
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.
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.
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ą.
Zatem uzupełniłem już moją kolekcję ISO w proxmox :) - czy nie jest imponująca (żart).
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.
Wgrywanie kilku obrazów z jednego węzła powodowało błąd importu ISO.
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 :)
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:
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.
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.
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:
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:
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.
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:
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.
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.
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 - 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.
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.
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.
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).
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
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.
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.
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.
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.
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
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)
Operacje powtarzamy w celu uzyskania ZFS_STORAGE na każdym węźle w proxmox odpowiednio dla pve02 i pve03.
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.
Dodajemy nasz ZFS z poziomu klastra. Przechodzimy do menu klastra -> Storage -> Add -> ZFS
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.
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.
W przeciwieństwie do NFS i SMB, co to oznacza?
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:
HA (High Availability) - Wysoka dostępność:
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.
Celem HA jest minimalizowanie przestojów i zapewnienie, że zasoby są dostępne nawet w przypadku awarii jednego z węzłów.
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.
Replikacja:
Jest to proces tworzenia kopii danych w czasie rzeczywistym (lub niemal w czasie rzeczywistym) z jednej lokalizacji do innej.
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.
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
Lub belki z przyciskami funkcyjnymi z prawej strony ekranu po kliknięciu na dany host.
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.
Niech to będzie Ubuntu - wybieramy ISO z naszego storage gdzie przechowujemy nasz obrazy systemów opercyjnych.
Ustawienie Systemowe - można się wzorować lub ustawić własne.
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.
CPU - według uznania (lub możliwości naszego węzła).
RAM - tak z umiarem :)
Sieci. Jeszcze za dużo o sieci nie rozmawialiśmy, a więc ustawmy domyślny bridge interface.
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ć.
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.
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
HA - jego konfiguracje robimy na poziomie klastra. Z menu klastra wybieramy HA -> Groups to tu będziemy mogli stworzyć nasze grupy decyzyjne HA
Kliknijmy create by spojrzeć na konfigurację.
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.
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)
W samym menu HA możemy podejrzeć sobie Czy nasze kworum jest OK oraz który, węzeł akurat pełni role mastera (main).
A poniżej możemy ustawić nasze HA dla naszych zasobów poprzez przycisk Add. Ścieżka będzie zatem menu klastra -> HA -> Add.
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
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.
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.
Po zastosowaniu HA widzimy jak nasze maszyny przygotowywane są do rozłożenia po klastrze.
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.
Po ukończonej migracji nasze maszyny wirtualne teraz tak są rozłożone na klastrze.
Widzimy to też w GUI PROXMOX
Możemy to zweryfikować na podstawie naszych ustawień HA grupy.
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.
Po zmianie kolejności i ustawieniu pve03 z najwyższym priorytetem zaobserwujemy ze rozpoczyna się nasza migracja.
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)
Podczas procesu migracji dane zobaczymy na obu hostach pve01 i pve02. (W obrazku widnieje błąd w postaci oznaczenia dysku w dolnej czesci)
Zobaczymy ten proces na liście zadań 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.
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.
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.
Ustawiamy Target na pve01 (potem na pve02) konfigurujemy nasz Schedule: co 15 minut (w ramach testu).
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ł.
Ustawienie replikacji będzie widoczne w naszych zadaniach replikacyjnych na liscie wraz z widocznym statusem.
Teraz możemy zaobserwować że nasz dysk pojawia się na innych hostach (pve01 i pve02)
Jest to replika naszego dysku - która może posłużyć jako restore point po awarii któregoś z węzłów.
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.
Wyłączymy nasz węzeł proxmox pve02.
Po chwili nasz status page wykryje problem.
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.
Tak to wygląda po przełączeniu HA w przypadku awarii 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
Maszyny 101 i 102 wracają na swoje miejsce.
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.
Jeżeli nie wykonała się na czas z powodu awarii lub jeszcze nie została uruchomiona zawsze możemy ją uruchomić na żądanie.
Musimy poczekać na wszystkie wykonania.
Teraz jestesmy pewni że nasz HA groups i replica zadziała w przypadku awarii.
Widzimy że nasza VMka 100 cały ten czas działała ma uptime 43 minuty (a przeszła dwie migracje w międzyczasie).
Czas zatem na awarie numer dwa - teraz pve01 bedzie niedostępny. Host z naszą maszyną ubuntu-zfs (ID 100)
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).
Proxmox przeniósł maszynę i odpala ja na bazie naszego dysku z ostatniej repliki.
Oczywiście maszyny w tym przypadku zaliczyła restart. Którego nie da się uniknąc w przypadku awarii niekontrolowanej węzła.
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.
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ą)?
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?
A jak testy wydajności? Bo o nich wspominałeś.
Ale jeśli padnie nam NAS to rozumiem przestanie wszystko działać poza ZFSem?
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)?