top of page

Śledź nasze wpisy w social media

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

Q&A do warsztatów z proxmox

W tym artykule odpowiem na pytania, które się pojawiły podczas warsztatów proxmox. Pytania zostały zapisane w formie tekstowej - uczestnicy warsztatów mieli miejsce gdzie mogli zadawać pytania. Zatem nie przeciągając oto te pytania i odpowiedzi.


Proxmox - pytania i odpowiedzi

Wasze pytanie, moje odpowiedzi


Pytanie nr 1: Rozproszyłem się na Sniepetach, są gdzieś dostępne skrypty których używałeś omawiając ten temat?


Odpowiedź: Tak, skrypty użyte w warsztatach dostępne są na repozytorium git w bitbucket możesz sklonować lub użyć fork dla tego repozytorium. Jeżeli chodzi o Snippet dla Proxmox to po pierwsze w domyślnej konfiguracji musisz dla danego storage właczyć ta opcje ona domyślnie nie jest włączona. Zatem dla demonfs będzie to w /mnt/pve/demonfs/snippets a dla local-lvm bedzie to /var/lib/vz/snippets/




Pytanie nr 2: Upgrade wersji z pve 7 do 8 z Ceph , na co zwracać uwagę, jak się zabezpieczyć przed ewentualnych fckupem


Odpowiedź: Upgrade w proxmox nigdy nie był prostym tematem. Podrzucam link do oficjalnej dokumentacji proxmox już na początku by o nim nie zapomnieć. Sam proxmox w swojej dokumentacji mówi o dwóch sposobach aktualizacji.


Sposób pierwszy


Sposób najdroższy w moim odczuciu ponieważ wymaga od nas bliźniaczej konfiguracji - tzn aktualizacji robimy po prostu instalująć nowsza wersję w tej samej konfiguracji i przenosimy dane na nowa instancje klastrową. Lub Tworzymy backup i na hoscie gdzie mieliśmy stara wersje instalujemy nową. Pamietajmy o backup! proxmox w swojej dokumentacji fajnie to opisuje co należy skopiować. Przedstawione są też kroki tej operacji


  1. Wykonaj kopię zapasową wszystkich maszyn wirtualnych (VM) i kontenerów na zewnętrzne urządzenie magazynujące (zobacz Kopia zapasowa i przywracanie).


  2. Wykonaj kopię zapasową wszystkich plików w katalogu /etc.


  3. Wymagane: pliki w /etc/pve, a także /etc/passwd, /etc/network/interfaces, /etc/resolv.conf oraz wszystko, co odbiega od domyślnej instalacji.


  4. Zainstaluj najnowszą wersję Proxmox VE 8.x z pliku ISO (spowoduje to usunięcie wszystkich danych na istniejącym hoście).


  5. Wyczyść pamięć podręczną przeglądarki i/lub wymuś ponowne załadowanie (CTRL + SHIFT + R, lub dla macOS ⌘ + Alt + R) interfejsu Web UI.


  6. Odtwórz klaster, jeśli dotyczy.


  7. Przywróć plik /etc/pve/storage.cfg (spowoduje to udostępnienie zewnętrznego magazynu używanego do kopii zapasowej).


  8. Przywróć konfigurację zapory sieciowej z /etc/pve/firewall/ oraz /etc/pve/nodes/<nazwa_węzła>/host.fw (jeśli dotyczy).


  9. Przywróć wszystkie maszyny wirtualne z kopii zapasowych (zobacz Kopia zapasowa i przywracanie).


  10. Administratorzy zaznajomieni z wierszem poleceń mogą postępować zgodnie z procedurą Pomijanie kopii zapasowej i przywracania przy aktualizacji, jeśli wszystkie maszyny wirtualne i kontenery znajdują się na jednym wspólnym magazynie.


Musimy pamiętać, że to nie jest proces szablonowy i trzeba indywidualnie podchodzić do każdego przypadku przygotowywując sobie checklistę, sprawdzając podwójnie wszystkie elementy.


Sposób drugi


Aktualizacja przez pakiety - z wykorzystaniem apt. Tutaj też należy pamiętać o backup. Pamiętajmy też by nasza obecna wersje podnieść do jak najnowszej w ramach danej wersji. Czyli jak mamy wersje 7 aktualizujemy ja do wersji 7 latest. Jak mamy na klastrze Ceph to zajrzyjmy do dokumentacji jaka wersja będzie wymagana przed aktualizacją i czy mamy ja podbić przed czy po aktualizacji. Wszystko ładnie jest opisane w danym procesie aktualizacji między wersjami


Wady i zalety.


Jeden i drugi sposób ma swoje wady i zalety. Elementem wspólnym jest backup w jednym jak i w drugim przypadku powinien być wykonany i przetestowany przed aktualizacją. Wady pierwszego rozwiązania to w przypadku gdy instalujemy wersję 8 na wersji 7 to tracimy dane i mamy je tylko w backup. Posiadanie dwóch redundantnych konfiguracji jest drogim rozwiązaniem i jeszcze stwarza problem sieci. - dla drugiego osobnego klastra trzeb stworzyć nowa sieć i uważać na overlap adresów sieciowych.


I najważniejsze niestety nie ma magicznej różdżki czy skryptu który to za nas załatwi - musimy do tego przysiąść i sobie to rozpisać.




Pytanie nr 3: czy bardzo niezalecane jest korzystanie z klastra tylko w konfiguracji dwóch hostów ?


Odpowiedź: Korzystanie z klastra Proxmox w konfiguracji z tylko dwoma hostami jest ogólnie niezalecane, głównie ze względu na problemy z kworum, które mogą wpłynąć na stabilność i dostępność usług.


Dlaczego kworum jest ważne?


  1. Kworum to mechanizm, który zapewnia spójność danych w klastrze przez wymaganie większości dostępnych węzłów do podejmowania decyzji.


  2. W klastrze z dwoma węzłami większość wynosi 2, co oznacza, że jeśli jeden węzeł ulegnie awarii, klaster traci kworum i przestaje działać prawidłowo.


W konfiguracji wysokiej dostępności (HA) w klastrze Proxmox liczba hostów powinna być nieparzysta (3, 5, 7 itd.), aby zapewnić prawidłowe działanie mechanizmu kworum i uniknąć problemów z dostępnością. Oto dlaczego taka liczba hostów jest zalecana:


  1. Zapewnienie kworum:

    1. Klaster HA wymaga kworum, aby podejmować decyzje dotyczące stanu klastra. Kworum oznacza, że większość hostów musi być dostępna, aby klaster mógł działać. Przy liczbie hostów 3, 5, 7 itd., zawsze można osiągnąć większość głosów nawet po utracie jednego lub kilku węzłów.


    2. Na przykład:

      1. W klastrze 3-hostowym kworum wynosi 2. Oznacza to, że klaster może dalej działać, gdy jeden host jest niedostępny.

      2. W klastrze 5-hostowym kworum wynosi 3, co pozwala na awarię dwóch hostów.

      3. W klastrze 7-hostowym kworum wynosi 4, umożliwiając utratę do trzech hostów.


  2. Unikanie sytuacji split-brain:

    1. W przypadku parzystej liczby hostów istnieje ryzyko sytuacji split-brain, gdzie część hostów uważa się za oddzielne klastry, co może prowadzić do konfliktów i utraty danych. Użycie nieparzystej liczby węzłów minimalizuje to ryzyko, ponieważ zawsze jest możliwe osiągnięcie większości głosów.


  3. Lepsze rozłożenie zasobów i odporność na awarie:

    1. Większa liczba hostów w konfiguracji nieparzystej pozwala na lepsze rozłożenie obciążenia i zapewnia większą odporność na awarie. Im więcej węzłów, tym klaster jest bardziej odporny na utratę poszczególnych hostów, co zwiększa dostępność usług.


  4. Skalowalność i przyszłe rozszerzenia:

    1. Rozbudowa klastra w sposób skalowalny jest łatwiejsza, gdy dodaje się nieparzyste liczby hostów (np. z 3 do 5, z 5 do 7), co zachowuje odpowiednią konfigurację kworum.


Problemy z klastrem dwuwęzłowym:


  1. Brak tolerancji na awarie: Awaria jednego węzła powoduje utratę kworum i potencjalne zatrzymanie usług.


  2. Split-brain: W przypadku problemów z siecią oba węzły mogą działać niezależnie, prowadząc do niespójności danych.


  3. Ograniczone możliwości HA: Funkcje wysokiej dostępności (HA) są ograniczone lub wymagają dodatkowej konfiguracji.


Możliwe rozwiązania:


  1. Dodanie trzeciego węzła: Nawet jeśli jest to mały serwer lub urządzenie pełniące rolę tylko głosu w kworum.


  2. Użycie qdevice (Quorum Device): Dodatkowy serwer lub usługa, która pomaga w osiągnięciu kworum w klastrze dwuwęzłowym.


  3. Konfiguracja tie-breaker: Specjalne ustawienia, które pomagają w rozwiązywaniu konfliktów kworum, ale mogą być skomplikowane i nie zawsze niezawodne.


Rekomendacje:


  1. Najlepsza praktyka: Użycie co najmniej trzech węzłów w klastrze Proxmox dla zapewnienia stabilności i pełnej funkcjonalności.


  2. Jeśli musisz użyć dwóch węzłów: Dokładnie przemyśl i skonfiguruj mechanizmy dodatkowe (np. qdevice) oraz przygotuj się na potencjalne komplikacje.


Podsumowanie:


Korzystanie z klastra dwu węzłowego w Proxmox nie jest zalecane ze względu na ryzyko utraty kworum i związane z tym problemy. Jeśli zależy Ci na stabilności i wysokiej dostępności, warto zainwestować w trzeci węzeł. Oczywiście w środowisku domowym mozna to zrobić na dwóch węzłach z Quorum Device. W środowiskach produkcyjnych moim zdaniem jest to mega cebula, bo często osoby decyzyjne nie rozumieją tego mechanizmu i nie wiedzą że Quorum Device nie zapewnia nam hosta na, którym uruchomimy maszyny wirtualne a jedynie hosta do decyzji w przypadku gdy mamy 2 hosty. I decydują w takim przypadku na podstawie ceny (2 nody są tansze od 3 nodów). Dlatego uważam że w środowisku produkcyjnym powinno być to jawnie omówione wpisane w draft lub plan implementacji i podpisane przez osobe decyzyjna z zaznaczeniem że rozumie wszelkie konsekwencje zastosowanego rozwiązania.




Pytanie nr4: Jakie są podstawowe wymagania odnośnie postawienia Windows na proxmoxie? Ile najlepiej ramu wypadałoby mieć, bo słyszałem, że Windows jest pamięciożerny.


Im więcej tym lepiej, ale odpowiedź nie jest taka prosta. Zależy głownie od tego co będziesz robił na tym windows. Ja osobiście wykorzystywałem maszynę wirtualną na proxmox z windows do świadczenia jej jako agent w Team City do budowania i kompilowania bibliotek i kodu dla naszych aplikacji (w firmie w której pracowałem). Pod spodem mieliśmy dyski NVMe (w proxmox) dla maszyny wirtualnej udostępnione przez virtio ze wskazaniem na dysk NVMe, Ramu miał 12 GB, Grafika domyślna - nie była potrzebna. CPU 1 Socket, 8 Core. I działało świetnie. A i w ustawieniach vm był w trybie host.




Pytanie nr 5: Jak najlepiej robić backup wszystkich wirtualnych maszyn? Nawet jak sporo ważą to można to przenieść na dysk podpięty na sata a nie nvme?


Backup można wykonywać na NFS, SMB, CIFS, local storage itp - i tak można podpiąc dysk dodatkowy na stałe lub przez USB i tam robić backup. Jednak lepszym rozwiązaniem jest wydaje mis ie cloud storage zgodny z s3 i tam wysyłanie synchronizowanie backupu.



Pytanie nr 6: Czy postawienie proxmox na zewnątrz portami idzie dobrze zabezpieczyć pod kontem włamania? Zależy mi na ustawieniu proxmoxa na zewnątrz i mógłbym sterować wszystkimi maszynkami nie będąc w domu, zastanawiałem się nad vpn wireguard, ale jakie duże ryzyko wiąże się z takim rozwiązaniem?


Tak można dobrze zabezpieczyć interfejs GUI proxmoxa. Najprostsza metoda to firewall przed z filtracja adresów IP. Ja bym w tym przypadku użył rozwiązania Nord VPN z dedykowanym adresem IP. Wtedy ten adres dodajesz do firewall proxmox i po sprawie. Dedykowany adres IP jest przypisywany tylko do Ciebie. Fajne rozwiązanie.




Pytanie nr 7: a ja mam pytanie apropo przygotowywania tego demo-środowiska tworząc proxmoxy (poszczególne node) utworzyłeś jeden obraz, przeklikałem instalacje -> zrobiłeś template i rozrzuciłem terraformem z gotowego obrazu? czy jakas inna metoda?


Odpowiedź jest prosta i banalna - autoinstaller od proxmox on to wspiera sam w sobie. Omawiam też to w moim ostatnim wpisie. W skrócie tworzymy answer plik z konfiguracją i dodajemy go do naszego instalatora.




Pytanie nr 8: Czy zwiększanie ilości nodów poprawia wydajność dużo bardziej niż dokładanie OSD do istniejących nodów?


OSD w CEPH uruchamia się na fizycznych dyskach wtedy ma się najlepszy performance. Czyli lepiej dodac nowy fizyczny dysk i na nim utworzyć kolejny OSD. Nie ma potrzeby dodawania nowych węzłów.




Pytanie nr 9: Jeśli chodzi o FC, jaka jest możliwość podłączenia macierzy SAN do Proxmox


Możliwość podłączenia jest:


  1. Sprawdzenie kompatybilności sprzętu:

    1. Upewnij się, że serwer Proxmox jest wyposażony w odpowiednie karty HBA (Host Bus Adapter) Fibre Channel, które są kompatybilne z Twoją macierzą SAN.

    2. Sprawdź, czy sterowniki dla kart HBA są poprawnie zainstalowane w systemie.


  2. Połączenie fizyczne:

    1. Podłącz kable Fibre Channel od kart HBA w serwerze Proxmox do przełącznika FC lub bezpośrednio do macierzy SAN (w zależności od topologii sieci).




Pytanie nr 10: Jeśli na VM proxmox zabraknie RAM, to VM się zawiesza, jest szansa w jakiś sposób się do niej dostać, czy tylko siłowe ubicie? Może próbować opcji KVM shared memory?


Aby włączyć “Kernel Same-page Merging” (KSM) dla maszyn wirtualnych w Proxmox, musisz skonfigurować odpowiednie parametry na poziomie systemu operacyjnego hosta oraz w ustawieniach maszyn wirtualnych. KSM pozwala na dzielenie wspólnej pamięci pomiędzy maszynami wirtualnymi, co może prowadzić do oszczędności pamięci RAM.


Oto kroki, które należy wykonać:


  • Włącz KSM na hoście Proxmox:

    1. Sprawdź, czy KSM jest już włączony: cat /sys/kernel/mm/ksm/run


    2. Jeśli wynik to 0, KSM jest wyłączony.


    3. Aby włączyć KSM, wykonaj: echo 1 > /sys/kernel/mm/ksm/run


Opcjonalnie, możesz dostosować parametry, takie jak liczba stron do skanowania na cykl (pages_to_scan) lub interwał między cyklami skanowania (sleep_millisecs):


echo 1000 > /sys/kernel/mm/ksm/pages_to_scan

echo 200 > /sys/kernel/mm/ksm/sleep_millisecs



  • Skonfiguruj maszynę wirtualną do używania KSM:

    1. Otwórz plik konfiguracyjny maszyny wirtualnej, który znajduje się w /etc/pve/qemu-server/VMID.conf, gdzie VMID to identyfikator maszyny wirtualnej.


    2. Dodaj lub zmodyfikuj linię: balloon: 1


Opcja ta włącza “Memory Ballooning”, co jest zalecane przy używaniu KSM.


  • Automatyzacja dla grupy lub puli maszyn:

    1. Jeśli chcesz włączyć KSM dla wszystkich maszyn wirtualnych w danej grupie lub puli, możesz użyć skryptu Bash do automatycznego modyfikowania konfiguracji.


Przykładowy skrypt:


for VMID in $(pvesh get /cluster/resources --type vm | jq -r '.[] | select(.pool == "nazwa_puli") | .vmid'); do

    qm set $VMID --balloon 1

done


Ten skrypt ustawia “Memory Ballooning” dla wszystkich maszyn wirtualnych w określonej puli.


  • Restart maszyn wirtualnych:

    1. Aby zmiany zaczęły działać, konieczne może być zrestartowanie maszyn wirtualnych.


Po tych krokach KSM będzie działał dla wybranych maszyn wirtualnych, co pozwoli na lepsze wykorzystanie pamięci RAM.


Pytanie nr 11: W małym biznesie jest zazwyczaj kilka-kilkanaście VM, jakś płatnik, comarch, często muszą działać 24h. Na lokalnych dyskach SSD działa to znośnie. Jaką konfigurację byś zalecił przy przejściu na Ceph aby stworzyć prawdziwe HA? Proszę nie pisz "to zależy" :) Ceph w zwirtualizowanym labie działa dość topornie, jak by było w rzeczywistości? 3 nody? 5 nodów? W każdym nodzie kilka nvme? (ile min?) Baza ceph koniecznie na osobnych dyskach? Sieć pomiędzy nodami 10Gb wydaje się wystarczająca, ale może lepiej 25Gb?


W labie na którym pracowaliśmy działało to topornie dlatego że to było środowisko testowe do zabawy. Po drugie mieliśmy zagnieżdżoną wirtualizację. Udostępniony dla Ciebie lab w postaci serwera z Ubuntu już był maszyna wirtualną, na niej dopiero uruchomiliśmy proxmoxa a potem tam uruchomiliśmy maszynę wirtualną. Czyli mieliśmy tak naprawdę 3 zagnieżdżenie (tzw nesting virtualization).


Dyski które tworzyliśmy też były zwirtualizowane nie były to fizyczne dyski tylko pliki.


CEPH już napisałem to wcześniej najlepiej działa na fizycznych dyskach. Działa na HDD, SSD, NVMe - no i tutaj ograniczać cię już będzie interfejs. Jak wybierzesz HDD to Ceph będzie wolniejszy niż w przypadku NVMe. Ceph Storage można sprawdzić i porównać zapis fio na storage sieciowym i dedykowanym dysku. I tu im szybsza sieć tym lepiej. Musisz sprawdzić czy dyski użyte w twojej konfiguracji wykorzystają w pełni łącze. No i też należy pamiętać o przyszłej rozbudowanie czy ją planujesz.


Zwiększanie liczby nodów w klastrze Ceph ma znaczący wpływ na wydajność i niezawodność systemu. Oto kilka kluczowych punktów, które warto wziąć pod uwagę:


  1. Redundancja i odporność na awarie: Zwiększenie liczby nodów zwiększa odporność klastra na awarie. Ceph rozkłada dane na różne nody, tworząc kopie (replikacje) danych. Przy większej liczbie nodów, klaster może lepiej zarządzać redundancją, co zmniejsza ryzyko utraty danych w przypadku awarii jednego z nodów.


  2. Balansowanie obciążenia: Większa liczba nodów oznacza więcej zasobów (CPU, RAM, sieć) do dyspozycji klastra. Dzięki temu Ceph może lepiej balansować obciążenie, zwłaszcza jeśli chodzi o I/O. Zwiększenie liczby nodów rozkłada operacje zapisu i odczytu na więcej dysków (OSD), co może przyspieszyć operacje w systemie.


  3. Skalowalność wydajności I/O: Ceph jest skalowalnym systemem, co oznacza, że zwiększanie liczby nodów i OSD (Object Storage Daemons) może bezpośrednio wpłynąć na zwiększenie wydajności operacji I/O. W scenariuszu z pięcioma nodami, gdzie każdy z nich posiada po jednym OSD na dysku 300 GB, system będzie miał więcej możliwości równoległego przetwarzania operacji w porównaniu do trzech nodów. Może to poprawić przepustowość (bandwidth) oraz zmniejszyć opóźnienia (latency).


  4. Efektywność przy dużej ilości danych: Przy większej liczbie nodów Ceph lepiej radzi sobie z dużą ilością danych, ponieważ dane są przechowywane i rozpraszane na większej liczbie urządzeń, co przyspiesza operacje odczytu i zapisu.


Wiec jak widac to zależy od konfiguracji - więcej nie znaczy zawsze lepiej musimy pamiętać że w przypadku CEPH to zestaw naczyń połączonych i zwiększanie jednego parametru wpływa na inne parametry.



Pytanie nr 12: Czasami VM od strony GUI Proxmox się tak zawiesza, że nie wiadomo czy w ogóle umarła czy może jest do odratowania. Konsola nie działa. Jest szansa w jakiś sposób się do niej dostać, czy tylko siłowe ubicie? Może próbować opcji KVM shared memory?


KSM to nie jest idealne rozwiazanie. Pytanie czy zawieszanie jest spowodowane tym że uruchamiasz za dużo maszyn wirtualnych czy po stronie kodu działającego na maszynie wirtualnej.


Można też spróbować ustawić połączenie do maszyny wirtualnej z poziomu tty portu szeregowego.


Funkcja, której szukasz, to “Serial Console” w KVM (konsola szeregowa). Umożliwia ona połączenie się z maszyną wirtualną poprzez interfejs konsolowy za pomocą narzędzia virsh. Oto kroki, jak to skonfigurować:


  1. Skonfiguruj maszynę wirtualną do używania konsoli szeregowej:

    1. Musisz edytować plik XML definicji maszyny wirtualnej, aby dodać interfejs konsoli szeregowej. Możesz to zrobić, używając polecenia: virsh edit nazwa_maszyny


    2. W pliku XML dodaj następujący wpis w sekcji <devices>:


<console type='pty'>

    <target type='serial' port='0'/>

</console>



  1. Skonfiguruj system operacyjny maszyny wirtualnej:

    1. Na maszynie wirtualnej musisz skonfigurować system operacyjny, aby umożliwił logowanie przez konsolę szeregową. W systemach Linux wykonaj następujące kroki:


    2. Edytuj plik /etc/default/grub i dodaj parametr dla kernela: GRUB_CMDLINE_LINUX_DEFAULT="console=ttyS0"


    3. Zaktualizuj konfigurację GRUB: sudo update-grub


    4. Skonfiguruj getty, aby nasłuchiwał na porcie szeregowym. Dodaj lub odkomentuj linię w pliku /etc/inittab lub utwórz plik /etc/systemd/system/serial-getty@ttyS0.service.d/override.conf:


[Service]

ExecStart=

ExecStart=-/sbin/agetty --keep-baud 115200,9600 ttyS0 $TERM



  1. Połącz się z maszyną wirtualną przez virsh:

    1. Po skonfigurowaniu możesz połączyć się z konsolą szeregową używając polecenia: virsh console nazwa_maszyny


W Proxmox VE, konfiguracja dostępu do konsoli szeregowej dla maszyny wirtualnej jest podobna, ale proces jest nieco uproszczony, ponieważ interfejs graficzny Proxmox ułatwia konfigurację. Oto kroki, jak skonfigurować konsolę szeregową w Proxmox:


  1. Skonfiguruj konsolę szeregową w ustawieniach maszyny wirtualnej:

    1. W interfejsie Proxmox VE, wybierz maszynę wirtualną, którą chcesz skonfigurować.


    2. Przejdź do zakładki Hardware, a następnie kliknij Add -> Serial Port.


    3. Dodaj port szeregowy (serial0) do maszyny wirtualnej.


  2. Skonfiguruj system operacyjny maszyny wirtualnej:

    1. Jeśli maszyna wirtualna korzysta z systemu Linux, skonfiguruj ją tak, aby umożliwić logowanie przez konsolę szeregową:


    2. Edytuj plik /etc/default/grub i dodaj parametr dla kernela, np.: GRUB_CMDLINE_LINUX_DEFAULT="console=ttyS0"


    3. Zaktualizuj konfigurację GRUB: sudo update-grub


    4. Skonfiguruj getty, aby nasłuchiwał na porcie szeregowym, np. edytując lub tworząc plik /etc/systemd/system/serial-getty@ttyS0.service.d/override.conf:


[Service]

ExecStart=

ExecStart=-/sbin/agetty --keep-baud 115200,9600 ttyS0 $TERM



  1. Połącz się z konsolą szeregową:

    1. W interfejsie webowym Proxmox VE, przejdź do zakładki Console dla wybranej maszyny wirtualnej.


    2. Wybierz opcję Serial Terminal z menu rozwijanego. Zostanie wyświetlona konsola szeregowa dla maszyny wirtualnej.


Dzięki temu możesz uzyskać dostęp do maszyny wirtualnej przez konsolę szeregową, co jest przydatne do diagnostyki lub pracy z systemami bez interfejsu graficznego.




Pytanie nr 13: Czy drbd będzie wyraźnie lepszy od ceph zakładając małą ilość OSD?


W przypadku małej liczby OSD, DRBD może być lepszym wyborem niż Ceph, w zależności od specyficznych wymagań. Oto kilka kluczowych czynników do rozważenia:


  1. Replikacja danych: DRBD to rozwiązanie do replikacji blokowej, które synchronizuje dane między dwoma lub więcej węzłami w trybie aktywny-aktywny lub aktywny-pasywny. Jest bardziej wydajne przy mniejszych konfiguracjach, ponieważ wymaga mniej zasobów niż Ceph i lepiej radzi sobie z małą ilością węzłów. Ceph, z drugiej strony, jest rozproszonym systemem pamięci masowej, który osiąga większą wydajność przy większej liczbie OSD i węzłów.


  2. Skalowalność: Ceph jest projektowany z myślą o skalowalności i lepiej sprawdza się w środowiskach z większą liczbą OSD. Przy małej liczbie OSD Ceph może mieć niższą wydajność i wyższą latencję, ponieważ jego architektura rozproszona wymaga więcej metadanych i operacji kontrolnych.


  3. Zarządzanie: DRBD jest prostsze do wdrożenia i zarządzania w małych środowiskach, szczególnie tam, gdzie liczba węzłów jest ograniczona. Ceph wymaga bardziej zaawansowanej konfiguracji i monitorowania, nawet w małych środowiskach.


  4. Redundancja i dostępność: DRBD jest idealne do wysokiej dostępności w małych środowiskach, gdyż replikacja synchroniczna pozwala na szybkie przełączanie awaryjne. Ceph natomiast oferuje bardziej zaawansowane opcje odporności na awarie, takie jak erasure coding i wielopoziomowe replikowanie, które stają się bardziej efektywne przy większej liczbie OSD.


Wybór między Ceph a DRBD zależy od specyfiki środowiska, wymagań dotyczących skalowalności, wydajności, redundancji, oraz zadań, jakie chcesz realizować. Oto porównanie obu rozwiązań pod kątem różnych czynników:


  1. Skalowalność

    1. Ceph: Jest zaprojektowany z myślą o dużych, skalowalnych środowiskach. Można łatwo dodawać nowe węzły i zwiększać pojemność, co sprawia, że Ceph jest idealny dla dużych infrastruktur chmurowych i centrów danych.


    2. DRBD: Lepszy w małych środowiskach lub klastrach wysokiej dostępności (HA), gdzie liczba węzłów jest ograniczona (najczęściej 2-3). Skalowanie poza małą liczbę węzłów może być trudne i mniej efektywne.


  2. Replikacja danych

    1. Ceph: Replikuje dane w sposób rozproszony na wielu węzłach, oferując wysoką dostępność i odporność na awarie. Jest w stanie automatycznie rozproszyć dane na różnych poziomach, oferując opcje replikacji i kodowania wymazywalnego (erasure coding).


    2. DRBD: Oferuje replikację synchroniczną na poziomie blokowym pomiędzy dwoma lub więcej węzłami. Replikacja jest ściśle związana z warstwą blokową, co sprawia, że jest bardziej ograniczona niż w przypadku Ceph, który ma bardziej rozbudowane mechanizmy dystrybucji danych.


  3. Wydajność

    1. Ceph: Przy większej liczbie węzłów może zapewnić wysoką wydajność dzięki rozproszonemu modelowi zapisu i odczytu. Jednak w małych konfiguracjach (2-3 węzły) może mieć większą latencję i niższą wydajność niż DRBD.


    2. DRBD: Zapewnia niską latencję i wysoką wydajność w mniejszych środowiskach, zwłaszcza przy synchronicznej replikacji. Jest lepszym wyborem, gdy priorytetem jest szybki zapis/odczyt w małym klastrze.


  4. Zarządzanie i konfiguracja

    1. Ceph: Wymaga bardziej zaawansowanej konfiguracji i jest trudniejszy w zarządzaniu, szczególnie dla mniejszych zespołów IT. Ceph jest jednak bardzo elastyczny i może oferować różne rodzaje pamięci masowej (blokową, plikową, obiektową).


    2. DRBD: Jest prostszy w konfiguracji i zarządzaniu, co sprawia, że jest łatwiejszy do wdrożenia w małych klastrach lub jako rozwiązanie do replikacji danych.


  5. Odporność na awarie

    1. Ceph: Jest bardzo odporny na awarie dzięki swojej rozproszonej architekturze. Węzły mogą się awaryjnie wyłączać, a Ceph będzie w stanie automatycznie przenosić dane i odtwarzać replikacje, aby zapewnić dostępność danych.


    2. DRBD: Oferuje wysoką dostępność na poziomie blokowym i szybkie przełączanie awaryjne (failover), ale w przypadku większych awarii wymaga ręcznego odzyskiwania danych lub przełączania.



Pytanie nr 14: Ceph Monitor, po logrotate wywala błąd braku miejsca na dysku mimo dostępnej przestrzeni i trzeba go restartować, jak sobie z tym poradzić na produkcji


Pytanie co wrzuca komunikat ceph monitor czy logrotate jak logrotate to moze to jest problem w samym logroate. Pytanie jak jest uruchomione natywna aplikacja czy w kontenerze? To jest dużo niewiadomych. Dlatego proszę autora o przykłady i szersze opisanie problemu - może to zrobić w sekcji komentarzy pod tym artykułem.




Pytanie nr 15: Czy da sie ustawic jakis dedykowany IP klastra aby miec dostęp do GUI tylko z dedykowanego?


Tak da się - możemy wystawić nasz interface GUI bezpośrednio na publicznym IP lub przez port jakiś. I w ustawieniach firewall zezwolić na komunikację z konkretnym adresem.




Pytanie nr 16: Jak najlepiej zautomatyzować cały proces tworzenia klastra. Kilka dni temu przyjechał mi sprzet na ktorym chce zainstalowac wlasnie klaster proxmoxowy. Założenie jest takie ze wszystko ma byc oskryptowane, 0 klikania


Auto installer, ansible, terraform, bash, cloud-init tych technologi bym użył. W kolejnej edycji labów będę to poruszał więc zapraszam do obserwowania. Pojawi się to też w moim kursie proxmox (video) i dedykowanym szkoleniu online i stacjonarnym.




Pytanie nr 17: Mamy w firmie repo NFS z ISO, ale ten Repo jest read-only Proxmox nie chce go podpiac bo nie moze w nim pisac. Jest jakies obejscie?


Tak, można obejść problem podłączenia repozytorium NFS jako read-only w Proxmox, stosując poniższe rozwiązania:


  1. Podłączenie jako lokalny katalog:

    1. Możesz zamontować repozytorium NFS na serwerze Proxmox jako lokalny katalog w systemie operacyjnym hosta.


    2. Montowanie można zrobić przez dodanie wpisu do /etc/fstab, np.: nfs_server:/ścieżka/do/iso /mnt/nfs/iso nfs ro 0 0


    3. Następnie w Proxmox dodajesz katalog /mnt/nfs/iso jako zasób “Directory”. W konfiguracji zasobu wybierasz typ “ISO image”, co umożliwi dostęp do obrazów ISO w trybie read-only.


  2. Podłączenie NFS z flagą no_root_squash:

    1. Jeśli masz kontrolę nad serwerem NFS, możesz skonfigurować eksport tak, aby wyłączyć root_squash, co może rozwiązać problem dostępu do repozytorium.


    2. W pliku /etc/exports na serwerze NFS dodaj opcję no_root_squash dla danego eksportu: /ścieżka/do/iso *(ro,sync,no_root_squash)


    3. Po modyfikacji konfiguracji zrestartuj usługę NFS na serwerze.


  1. Utworzenie lokalnej kopii ISO:

    1. Alternatywnie, jeśli obrazy ISO nie są często zmieniane, można je skopiować lokalnie na serwer Proxmox i używać z lokalnej przestrzeni dyskowej.


    2. Skrypty synchronizujące mogą być używane do regularnego aktualizowania kopii lokalnej.


  2. Symboliczne linki:

    1. Możesz też utworzyć symboliczne linki w lokalnym katalogu Proxmox, które wskazują na pliki ISO na montowanym repozytorium NFS.


Któraś z tych metod powinna pozwolić na podłączenie repozytorium ISO w Proxmox mimo ograniczeń read-only.




Pytanie 18: Tworząc VM lepiej dawać np. 4 CPU i 1 Core czy 1 CPU i 4 Core? Jaka jest różnica?


Różnica między przypisaniem zasobów wirtualnych maszyn (VM) jako 4 CPU i 1 Core a 1 CPU i 4 Core polega na sposobie, w jaki system operacyjny i hypervisor zarządzają tymi zasobami. Oto główne różnice:


  1. 4 CPU i 1 Core:

    1. Oznacza to, że maszyna wirtualna otrzymuje 4 procesory fizyczne (vCPU), z których każdy ma tylko jeden rdzeń.


    2. Taka konfiguracja może być przydatna, jeśli maszyna wirtualna uruchamia aplikacje, które lepiej działają przy większej liczbie fizycznych procesorów.


    3. Niektóre starsze systemy operacyjne i aplikacje mogą korzystać z wielu procesorów, ale niekoniecznie z wielu rdzeni na jednym procesorze.


    4. Może prowadzić do większego narzutu na hypervisorze, ponieważ musi on zarządzać większą liczbą osobnych jednostek procesora.


  2. 1 CPU i 4 Core:

    1. Oznacza to, że maszyna wirtualna otrzymuje jeden procesor, który ma cztery rdzenie.


    2. W większości nowoczesnych systemów operacyjnych i aplikacji, które są zoptymalizowane pod kątem wielowątkowości, taka konfiguracja może być bardziej efektywna.


    3. Jest to bardziej naturalna reprezentacja nowoczesnych procesorów fizycznych, gdzie jeden procesor ma wiele rdzeni.


    4. Może mieć mniejszy narzut na hypervisorze, co pozwala na bardziej efektywne zarządzanie zasobami.


  1. Kiedy wybrać którą konfigurację?

    1. Aplikacje wielowątkowe (np. serwery baz danych, nowoczesne aplikacje serwerowe): Zazwyczaj lepiej wykorzystają konfigurację z mniejszą liczbą CPU i większą liczbą rdzeni (np. 1 CPU i 4 Core).


    2. Starsze aplikacje lub systemy operacyjne, które nie są zoptymalizowane do pracy na wielu rdzeniach, mogą lepiej działać przy konfiguracji z większą liczbą CPU (np. 4 CPU i 1 Core).


W praktyce warto eksperymentować z różnymi ustawieniami, aby zobaczyć, która konfiguracja działa lepiej dla konkretnego obciążenia w danym środowisku.



Podsumowanie


Odpowiedź na pytania zamyka nam warsztaty w 100%. Oczywiście to tylko pierwsza część. Zapraszam do obserwowania bo już niebawem warsztaty z proxmox część druga. Dziękuje za uwagę Piotr Kośka

222 wyświetlenia0 komentarzy

Ostatnie posty

Zobacz wszystkie

Comentários


Ś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