Proxmox Health Check: audyt klastra

Po co audyt, skoro wszystko działa

Najczęstszy scenariusz, jaki widzimy: klaster Proxmox pracuje od miesięcy bez zakłóceń i wszyscy zakładają, że jest dobrze. Problem w tym, że "działa" i "przeżyje awarię" to dwie różne rzeczy. Klaster z niepoprawnym kworum albo bez fencingu działa identycznie jak poprawnie skonfigurowany, dopóki nie padnie pierwszy węzeł.

Trzy sytuacje, które wracają u naszych klientów jak bumerang:

• Nikt nie wie, czy klaster przeżyje awarię węzła. HA jest "włączone", ale nikt nigdy nie wyłączył węzła, żeby sprawdzić, czy maszyny faktycznie wstaną gdzie indziej i w jakim czasie.
• Backupy są, ale nikt nie robił restore. Zadania backupu kończą się na zielono od roku. To nie znaczy, że z tych kopii da się cokolwiek przywrócić. Pisaliśmy o tym w artykule o testach restore i disaster recovery.
• Wdrożenie robił ktoś, kogo już nie ma. Admin odszedł, firma zewnętrzna zniknęła, dokumentacji brak. Środowisko działa, ale nikt nie wie dlaczego i nikt nie odważy się niczego dotknąć.

Audyt zamyka ten temat: po 2-3 dniach wiecie dokładnie, co jest dobrze, co jest ryzykiem i co naprawić najpierw.

Co sprawdzamy

Przechodzimy przez klaster według stałej listy kontrolnej, wypracowanej na własnej infrastrukturze produkcyjnej (8 węzłów i ponad 100 TB backupów, na których działa hosting IQHost) i wdrożeniach u klientów:

• Wersje PVE i repozytoria. Aktualność Proxmox VE, kernela i pakietów, konfiguracja repozytoriów (enterprise vs no-subscription), polityka aktualizacji.
• Stan klastra i kworum corosync. Liczba węzłów a odporność na awarie, konfiguracja votequorum, QDevice tam gdzie potrzebny, opóźnienia i stabilność linków corosync.
• Fencing i konfiguracja HA. Czy grupy HA mają sens, czy watchdog działa, co się stanie przy split-brain i czy maszyny krytyczne faktycznie są objęte HA.
• Zdrowie storage: ZFS / Ceph. Stan pul i OSD, harmonogram scrubów, stopień zapełnienia, fragmentacja, ARC, replikacja, spójność konfiguracji między węzłami.
• Polityka backupu i realny test restore. Harmonogramy, retencja, weryfikacja kopii na PBS oraz faktyczne przywrócenie wybranej maszyny do izolowanego środowiska. Nie zaznaczamy "backup OK" bez udanego restore.
• Sieć. Redundancja łączy (bonding), VLAN-y, separacja ruchu corosync i storage od ruchu VM, MTU, przełączniki jako pojedynczy punkt awarii.
• Bezpieczeństwo. Kto ma dostęp i po co, 2FA na kontach administracyjnych, reguły firewalla PVE, certyfikaty, ekspozycja interfejsu zarządzania. Bazujemy na naszej checkliście bezpieczeństwa Proxmox.
• Wydajność i pojemność. Utylizacja CPU, RAM i storage, przydziały zasobów VM, zapas na awarię węzła (czy klaster N-1 udźwignie obciążenie), prognoza kiedy zabraknie miejsca.
• Logi i alerting. Co się dzieje w logach, czy ktokolwiek dowie się o problemie zanim zadzwoni użytkownik, monitoring (Prometheus/Grafana lub inny).
• Dokumentacja i runbooki. Czy istnieje opis środowiska, procedury awaryjne, schemat sieci. Czy nowy admin ogarnie środowisko bez archeologii.
• Pojedyncze punkty awarii. Zasilanie, przełączniki, storage, pojedyncze usługi, od których zależy wszystko. Często to nie Proxmox jest najsłabszym ogniwem.
• Konfiguracje niestandardowe. Ręczne zmiany w systemie, skrypty, nietypowe integracje. To one najczęściej psują się przy aktualizacjach. Przykład z życia opisaliśmy w case study o incydencie Docker i iptables.

Co dostajecie

• Raport z oceną środowiska. Stan faktyczny każdego obszaru z listy powyżej, napisany tak, żeby zrozumiał go i admin, i zarząd.
• Lista ryzyk z priorytetami. Każde znalezisko sklasyfikowane jako wysokie, średnie lub niskie, z opisem co się stanie, jeśli zostawicie je bez zmian.
• Quick wins. Rzeczy do poprawienia od ręki, własnymi siłami, często w godzinę: brakujący scrub, zła retencja, otwarty port, brak 2FA.
• Plan naprawczy z wyceną. Dla większych tematów: co, w jakiej kolejności, ile to kosztuje. Możecie zrealizować go z nami albo bez nas.
• 60 minut omówienia. Przechodzimy przez raport razem, na żywo lub na wideorozmowie, i odpowiadamy na pytania waszego zespołu.

Cena i czas realizacji

Dolna granica dotyczy małych środowisk (pojedynczy klaster, kilka do kilkunastu VM), górna klastrów z Ceph, wieloma węzłami i rozbudowaną siecią. Dokładną cenę podajemy po krótkiej rozmowie o skali środowiska, przed podpisaniem czegokolwiek.

Kiedy warto zamówić audyt

• Po samodzielnym wdrożeniu. Zespół postawił klaster na podstawie dokumentacji i forów. Działa, ale przydałaby się weryfikacja przez kogoś, kto utrzymuje Proxmox produkcyjnie.
• Po awarii lub bliskim incydencie. Coś padło albo prawie padło i chcecie wiedzieć, czy to był pech, czy objaw głębszego problemu w konfiguracji.
• Przed rozbudową. Dokładanie węzłów, storage lub nowych obciążeń do środowiska z ukrytymi wadami tylko te wady utrwala i podnosi koszt późniejszej naprawy.
• Przed oddaniem nam utrzymania. Audyt to naturalny pierwszy krok przed administracją i utrzymaniem w ramach Proxmox Care: obie strony wiedzą, w jakim stanie jest środowisko na starcie.

Pytania i odpowiedzi