Kaip atrodytų Proxmox klasteris 20–50 vartotojų įmonei

Nuo ko pradedame: ne nuo serverių skaičiaus

20–50 darbuotojų įmonėje gali veikti tik keli serveriai arba keliolika kritinių sistemų: Active Directory ir DNS, failų serveris, apskaita ar ERP, SQL, nuotolinių darbalaukių serveris, dokumentų valdymas, telefonija, monitoringas ir įvairios gamybinės aplikacijos. Todėl klasterį projektuojame pagal realų procesorių, RAM, IOPS, talpos ir atkūrimo laiko poreikį, o ne vien pagal vartotojų skaičių.

Pirmiausia inventorizuojame esamas virtualias ir fizines sistemas, jų priklausomybes, užimamą vietą, piko apkrovas ir leistiną prastovą. Tada numatome augimą bent artimiausiems trejiems metams ir gedimo režimą: likę mazgai turi aptarnauti svarbiausias sistemas, kai vienas serveris neveikia.

2 ar 3 Proxmox mazgai?

Proxmox klasterio sprendimai remiasi balsų dauguma – quorum. Trijų mazgų klasteryje su vienodu balsų skaičiumi vienam mazgui dingus lieka du balsai iš trijų, todėl klasteris išlaiko quorum. Dviejų mazgų atveju vienam dingus lieka tik vienas balsas iš dviejų ir patikimam sprendimui reikia trečio balso – QDevice – atskiroje, stabilioje sistemoje.

Konkretus 3 mazgų architektūros pavyzdys

Toliau pateiktas dydis yra atskaitos taškas, o ne universalus pirkinių sąrašas. Tikslūs procesoriai, RAM ir diskai parenkami po apkrovų matavimo.

Projektuojant N+1 režimu, vieno mazgo gedimas neturi priversti likusių dviejų nuolat veikti ties 95–100 % apkrova. Praktinis tikslas – kad po HA perkėlimo liktų rezervas apkrovos šuoliui, backup užduotims ir administravimo darbams.

                                  INTERNETAS / VPN
                                         │
                              ┌────────── FIREWALL ──────────┐
                              │ segmentacija ir administravimas │
                              └──────────────┬───────────────┘
                                             │
                          ┌──────────────────┴──────────────────┐
                          │      redundantiški core switch'ai   │
                          └───────┬────────────┬────────────┬────┘
                                  │            │            │
                           ┌──────┴─────┐ ┌────┴──────┐ ┌───┴────────┐
                           │ PVE NODE 1 │ │ PVE NODE 2│ │ PVE NODE 3│
                           │ VM + data  │ │ VM + data │ │ VM + data │
                           └──────┬─────┘ └────┬──────┘ └───┬────────┘
                                  └────────────┼────────────┘
                                               │
                        atskiri loginiai / fiziniai srautai
          ┌───────────────────────┬───────────────────────┬───────────────────┐
          │ Management + Corosync │ VM / migration       │ Storage / Ceph    │
          │ 1 GbE, redundantiškas │ 10 GbE               │ 10/25 GbE         │
          └───────────────────────┴───────────────────────┴───────────────────┘

                     Backup srautas 10 GbE → atskiras PBS serveris
                                             │
                                  antra kopija kitame objekte
                                  arba offline / immutable laikmenoje

Storage pasirinkimas: Ceph ar vietinis ZFS?

Ceph: kai svarbus tikras paskirstytas storage

Trijuose vienoduose mazguose Ceph leidžia paskirstyti VM duomenis tarp serverių ir pašalinti vieną bendrą SAN/NAS kaip gedimo tašką. VM diskai lieka pasiekiami mazgo gedimo metu, o HA gali paleisti virtualią mašiną kitame mazge. Už tai mokame didesniais RAM, tinklo, diskų ir eksploatavimo reikalavimais.

Ceph ypač jautrus tinklo pralaidumui atkūrimo metu. Proxmox dokumentacijoje Ceph srautui rekomenduojama bent 10 Gb/s dedikuota jungtis, o NVMe ir didesnio našumo scenarijams – 25 Gb/s ar daugiau. Mažame klasteryje diskus ir jų skaičių stengiamės išlaikyti vienodus visuose mazguose.

Vietinis ZFS: paprasčiau, bet su kita HA logika

Jeigu apkrova nedidelė, o biudžetas ribotas, kiekviename mazge galime naudoti vietinį ZFS mirror arba RAIDZ ir Proxmox replikaciją. Tai paprastesnis sprendimas, tačiau replikacija nėra sinchroninis bendras storage: gedimo metu galima prarasti pakeitimus nuo paskutinės sėkmingos replikacijos, o HA paleidimo scenarijus turi būti aiškiai ištestuotas.

Išorinis SAN arba NAS

Bendras patikimas SAN/NAS supaprastina VM migravimą, tačiau pats storage tampa kritiniu komponentu. Todėl vertiname valdiklių, diskų lentynų, maitinimo ir tinklo dubliavimą. Vienas nebrangus NAS su viena maitinimo grandine nėra HA vien todėl, kad prie jo prijungti trys Proxmox mazgai.

Tinklai: atskiriame srautus pagal paskirtį

Atskyrimas gali būti fizinis arba atliktas VLAN ir QoS priemonėmis, tačiau Corosync srautas turi išlikti stabilus ir mažos delsos. Jo negalima paskandinti Ceph recovery, VM migracijos ar backup sraute.

Redundantiškumas turi tęstis iki switch'ų: dvigubos serverių jungtys nepadeda, jei visi kabeliai sueina į vieną komutatorių ar vieną maitinimo šaltinį. Tinklo gedimų scenarijus testuojame fiziškai atjungdami jungtis, o ne tik perskaitydami konfigūraciją.

Kaip realiai veikia HA

HA stebi klasterio būseną ir, patvirtinus mazgo gedimą, paleidžia saugomas VM kitame mazge. Tai nėra nepertraukiamas veikimas: operacinė sistema ir aplikacija startuoja iš naujo, todėl prastova priklauso nuo gedimo aptikimo, fencing, VM paleidimo ir pačios aplikacijos starto.

Prieš įjungdami automatinį HA, nustatome VM prioritetus ir starto seką: pirmiausia DNS/AD bei tinklo servisai, tada duomenų bazės, aplikacijos ir tik galiausiai mažiau kritinės sistemos. Taip pat patikriname, ar likę mazgai turi pakankamai RAM ir CPU svarbiausioms VM.

Backup architektūra: už klasterio ribų

Proxmox Backup Server laikome atskirame fiziniame serveryje ar bent atskiroje saugumo zonoje. Jam naudojame atskiras paskyras, ribojame administravimo prieigą ir numatome antrą kopiją kitoje vietoje arba offline / immutable saugykloje. Pats PBS palaiko deduplikaciją, retention, periodinį backup duomenų tikrinimą ir sinchronizavimą į kitą datastore.

Backup laikome veikiančiu tik tada, kai turime sėkmingo atkūrimo įrodymą. Žalias užduoties statusas patvirtina, kad duomenys buvo įrašyti, bet ne tai, kad visa aplikacija teisingai startuos ir pasieks priklausomus servisus.

Ką testuojame prieš perduodami klasterį eksploatacijai

• vieno Proxmox mazgo, vienos tinklo jungties ir vieno switch'o gedimą;
• quorum ir redundantiškų Corosync jungčių veikimą;
• kritinių VM HA paleidimą kitame mazge ir teisingą starto seką;
• Ceph arba kito storage veikimą disko bei mazgo gedimo metu;
• VM live migration ir jos poveikį vartotojams;
• atkūrimą iš PBS į atskirą testinį tinklą;
• backup kopijos pasiekiamumą praradus gamybinio tinklo administratoriaus paskyrą;
• monitoringo, temperatūros, diskų, UPS, storage ir sertifikatų perspėjimus;
• konfigūracijų, IP/VLAN plano, paskyrų ir disaster recovery dokumentaciją.

Kiek toks sprendimas turi rezervo?

Teisingas atsakymas gaunamas ne iš vartotojų skaičiaus, o iš matavimų. Vis dėlto tipinėje 20–50 vartotojų aplinkoje trys mazgai po 256–384 GB RAM ir tinkamai parinktas SSD/NVMe sluoksnis dažnai suteikia pakankamai vietos 8–20 VM, vieno mazgo gedimui ir artimiausių metų augimui. Duomenų bazių, VDI, vaizdo analitikos ar didelių failų darbo krūviams skaičiavimą atliekame atskirai.

Galutinė rekomendacija

Daugumai 20–50 vartotojų įmonių, kurioms svarbios vietoje veikiančios verslo sistemos, racionalus atskaitos taškas yra trys vienodi Proxmox VE mazgai, N+1 resursų planas, redundantiški core switch'ai, stabilus atskiras Corosync/management tinklas, 10 GbE VM ir backup srautas bei 10/25 GbE storage tinklas. Storage pasirenkame pagal apkrovą ir riziką: Ceph – kai reikia paskirstyto storage, vietinis ZFS su replikacija – kai priimtinas kitoks RPO, o išorinis SAN/NAS – tik įvertinus visus jo gedimo taškus.

Atskiras Proxmox Backup Server ir antra izoliuota kopija yra privaloma projekto dalis, o ne papildomas priedas po klasterio įdiegimo.

Šaltiniai