// Poradnik techniczny // HA · Reguły affinity

Reguły HA affinity
w Proxmox VE

Proxmox VE 9 wprowadził nowy system reguł HA, który zastępuje dawne „HA groups”. Decydujesz, które maszyny mają działać razem, które osobno, a które trzymać na wybranych węzłach — to odpowiednik reguł affinity z DRS w vSphere.

// 01 · Po co reguły

Kontrola rozmieszczenia w klastrze

W klastrze HA to menedżer decyduje, na którym węźle wskrzesić maszynę po awarii. Bez dodatkowych wskazówek może umieścić obok siebie dwie maszyny, które dla bezpieczeństwa powinny być rozdzielone — albo rozdzielić te, które muszą być blisko.

Reguły HA dają tę kontrolę deklaratywnie. Konfiguracja trafia do pliku /etc/pve/ha/rules.cfg w /etc/pve, więc automatycznie rozjeżdża się na wszystkie węzły — cały klaster ma spójny zestaw reguł. Ustawisz je też w panelu: Datacenter → HA → Rules.

// 02 · Trzy typy reguł

Affinity, anti-affinity i node affinity

  • Node affinity — przypnij zasób do wybranych węzłów. Zastępuje dawne HA groups i jest z nimi funkcjonalnie zgodne.
  • Resource affinity (positive) — trzymaj wskazane maszyny na tym samym węźle (np. aplikacja blisko swojej bazy danych).
  • Resource anti-affinity (negative) — rozłóż maszyny na różne węzły, by awaria jednego hosta nie położyła całej redundantnej usługi.
ℹ️

Klasyczne zastosowania anti-affinity: dwa kontrolery domeny, para load-balancerów, węzły tej samej bazy w replikacji — zawsze na osobnym sprzęcie.

// 03 · Strict vs non-strict

Twarde i miękkie ograniczenia

Reguły node affinity domyślnie nie są ścisłe: jeśli żaden z wskazanych węzłów nie jest dostępny, maszyna i tak zostanie uruchomiona gdzie indziej — dostępność wygrywa. Gdy zależność jest twarda (np. licencja przypięta do konkretnego sprzętu albo lokalny storage), użyj reguły strict — wtedy menedżer ogranicza umieszczanie, odzyskiwanie i migrację wyłącznie do węzłów z reguły.

Zachowanie powrotu kontroluje flaga failback (domyślnie włączona) — po przywróceniu preferowanego węzła maszyna na niego wraca. To następca dawnego nofailback z HA groups, przeniesiony na poziom zasobu HA.

// 04 · Migracja i dobre praktyki

Z HA groups na reguły

  • Automatyczna migracja — przy aktualizacji do 9.x dawne HA groups są konwertowane na reguły node affinity, a przypisanie grupy trafia do pola „resources” reguły.
  • Zaczynaj od anti-affinity dla par redundantnych — to największy zysk niezawodności przy minimalnym wysiłku.
  • Strict tylko gdy trzeba — nadmiar twardych reguł potrafi zablokować failover. Domyślny tryb miękki jest bezpieczniejszy.
💡

Reguły affinity współpracują z Dynamic Load Balancerem — automatyczne równoważenie zawsze respektuje Twoje reguły node i resource affinity.

Zaprojektujemy reguły HA pod Twój klaster

Dobierzemy affinity, anti-affinity i node affinity tak, by zmaksymalizować niezawodność usług po migracji z VMware — zgodnie z Twoimi wymaganiami SLA.

⚡ Bezpłatna konsultacja → Proxmox 9 vs 8: różnice
// Technical guide // HA · Affinity rules

HA affinity rules
in Proxmox VE

Proxmox VE 9 introduced a new HA rules system that replaces the old "HA groups". You decide which VMs run together, which stay apart, and which are kept on specific nodes — the equivalent of vSphere DRS affinity rules.

// 01 · Why rules

Control over cluster placement

In an HA cluster the manager decides which node to restart a VM on after a failure. Without hints it may place two VMs that should be separated side by side — or split apart those that must stay close.

HA rules give you that control declaratively. The config lives in /etc/pve/ha/rules.cfg under /etc/pve, so it is distributed to every node automatically — the whole cluster shares one consistent rule set. You can also set them in the UI: Datacenter → HA → Rules.

// 02 · Three rule types

Affinity, anti-affinity and node affinity

  • Node affinity — pin a resource to chosen nodes. Replaces the old HA groups and is feature-compatible with them.
  • Resource affinity (positive) — keep selected VMs on the same node (e.g. an app close to its database).
  • Resource anti-affinity (negative) — spread VMs across different nodes, so a single host failure doesn't take down a whole redundant service.
ℹ️

Classic anti-affinity uses: two domain controllers, a pair of load balancers, replica nodes of the same database — always on separate hardware.

// 03 · Strict vs non-strict

Hard and soft constraints

Node affinity rules are non-strict by default: if none of the listed nodes is available, the VM still starts elsewhere — availability wins. When the dependency is hard (e.g. a license tied to specific hardware, or local storage), use a strict rule — then the manager limits placement, recovery and migration to the rule's nodes only.

Return behaviour is governed by the failback flag (on by default) — once the preferred node is back, the VM returns to it. It's the successor of the old nofailback from HA groups, moved onto the HA resource.

// 04 · Migration and best practices

From HA groups to rules

  • Automatic migration — on upgrade to 9.x, old HA groups are converted to node affinity rules and the group assignment moves into the rule's "resources" field.
  • Start with anti-affinity for redundant pairs — the biggest reliability gain for minimal effort.
  • Strict only when needed — too many hard rules can block failover. The default soft mode is safer.
💡

Affinity rules work together with the Dynamic Load Balancer — automatic balancing always respects your node and resource affinity rules.

We'll design HA rules for your cluster

We'll set up affinity, anti-affinity and node affinity to maximise service reliability after your VMware migration — in line with your SLA requirements.

⚡ Free consultation → Proxmox 9 vs 8 differences