Nasz klaster produkcyjny: 8 węzłów pod ponad 8 tysięcy stron

Kontekst: sami jesteśmy swoim najbardziej wymagającym klientem

IQHost.pl to nasza siostrzana marka: hosting stron i aplikacji dla firm w Polsce. Fundamentem tej usługi są klastry Proxmox VE: 8 węzłów w dwóch lokalizacjach, które zbudowaliśmy od zera i utrzymujemy własnym zespołem. Każda awaria, każdy przestój i każdy nieudany backup uderzyłby najpierw w nas, a dopiero potem w kogokolwiek innego.

Dlatego traktujemy tę infrastrukturę jako stały poligon: zanim jakąkolwiek procedurę zaproponujemy klientowi wdrożeniowemu, musi przejść przez nasze własne środowisko produkcyjne. Pod realnym ruchem, nie w labie.

Architektura w skrócie

Szczegółów konfiguracji bezpieczeństwa nie opisujemy publicznie, ale sama konstrukcja jest klasyczna i sprawdzona:

• Klastry Proxmox VE, 8 węzłów łącznie. Maszyny wirtualne i kontenery rozłożone tak, żeby awaria pojedynczego węzła nie zatrzymała usług. Migracje między węzłami robimy na żywo, bez okien serwisowych dla klientów hostingu. Więcej o tym podejściu piszemy na stronie klastrów HA.
• Redundantna sieć. Osobne ścieżki dla ruchu klastra i ruchu produkcyjnego. Komunikacja corosync ma własną, odizolowaną sieć, o czym więcej w lekcjach niżej.
• Dwa serwery PBS w dwóch lokalizacjach. Proxmox Backup Server z łącznie ponad 100 TB przestrzeni stoi na oddzielnym sprzęcie, a kopie synchronizujemy do drugiej lokalizacji. Backup, który mieszka na tym samym klastrze co produkcja, nie jest backupem, tylko kopią roboczą.
• Monitoring Prometheus + Grafana. Metryki z węzłów, storage i usług, z alertingiem, który budzi nas zanim problem stanie się widoczny dla klientów.
• Automatyzacja Ansible. Konfiguracja węzłów jest powtarzalna i opisana kodem. Nowy węzeł albo odtworzenie istniejącego to procedura, nie archeologia.

Dlaczego to ważne, jeśli rozważacie Proxmox u siebie

Na rynku łatwo znaleźć firmy, które "robią wdrożenia Proxmox", ale same nie utrzymują na nim niczego krytycznego. My nie sprzedajemy niczego, czego nie utrzymujemy produkcyjnie. Każda procedura z naszych wdrożeń: backup i retencja, comiesięczny test restore, aktualizacje rolling węzeł po węźle, była najpierw przećwiczona na naszym własnym klastrze, pod obciążeniem ponad 8 tysięcy stron.

To zmienia rozmowę z klientem. Kiedy pytacie o zachowanie klastra przy utracie kworum, o czas przywracania VM z deduplikowanego backupu albo o to, jak wygląda aktualizacja Proxmox VE bez przestoju, nie odpowiadamy z dokumentacji. Odpowiadamy z własnych logów.

Czego nas to nauczyło

• Osobna sieć corosync oszczędza nerwów. Dopóki komunikacja klastra dzieli łącze z ruchem produkcyjnym, każdy pik obciążenia to potencjalne problemy z kworum i nieprzewidywalne zachowanie węzłów. Wydzielona sieć klastrowa to jedna z tańszych decyzji o największym zwrocie.
• Test restore co miesiąc wykrywa problemy zanim zrobią to klienci. Backup, którego nikt nie przywraca, jest tylko zajętym miejscem na dysku. Regularne testy wyłapały u nas rzeczy, których żaden zielony status w panelu by nie pokazał.
• Deduplikacja PBS realnie wydłuża historię backupów. Przy tysiącach podobnych do siebie środowisk dedup sprawia, że na tej samej przestrzeni trzymamy znacznie dłuższą retencję, niż wynikałoby z prostego mnożenia rozmiarów. Zasadę 3-2-1 w kontekście PBS opisujemy w bazie wiedzy.
• Dokumentację pisze się dla człowieka o 3 w nocy. Runbook, który zakłada spokojną głowę i pełny kontekst, jest bezużyteczny podczas awarii. Nasze procedury mają formę: krok, komenda, oczekiwany wynik, co zrobić gdy wynik jest inny.

Jeśli planujecie własny klaster albo chcecie zweryfikować istniejący, dobrym punktem startu jest audyt / health check: 2-3 dni pracy i raport z konkretnymi rekomendacjami.