Policies & Choosing the Right One

Policies

When creating a Placement Group, you select a policy that determines how Neevcloud places your servers on physical hosts. There are four policies available.

Affinity

All instances on the same physical host

All servers in this group are guaranteed to run on the same physical machine. Traffic between them never leaves the host, giving you the lowest possible network latency.

Best for:

• Primary + replica database setups requiring ultra-fast replication

• App server + cache server pairs that need sub-millisecond communication

• Tightly coupled services that exchange large volumes of internal data

Trade-off: If the physical host fails, all servers in the group go offline together. Do not use Affinity if uptime is more important than performance.

Anti-Affinity

Each instance on a different physical host

Every server in this group is placed on a separate physical machine. If one host fails, only the server on that host is affected — the rest continue running normally.

Best for:

• Web server replicas sitting behind a load balancer

• Application nodes where uptime is critical

• Any workload where you cannot afford multiple servers failing at the same time

Trade-off: Server creation will fail with an error if Neevcloud does not have enough distinct physical hosts available to satisfy the rule.

Soft Affinity

Best-effort same host — no error if not possible

Neevcloud will try to place all servers on the same host. If that is not possible (for example, the preferred host is at full capacity), the server will still be created on a different host — no failure, no error.

Best for:

• Development and staging environments where co-location is preferred but not critical

• Situations where you want Affinity behaviour without the risk of blocked launches

• Workloads that can tolerate occasional cross-host placement

Trade-off: You do not get a strict guarantee that all servers land on the same host. Use Affinity if co-location is mandatory.

Soft Anti-Affinity

Best-effort different hosts — no error if not possible

Neevcloud will try to place each server on a separate host. If there are not enough distinct hosts available, the server still launches — it may share a host with another group member, but will not fail.

Best for:

• Production workloads where availability matters but guaranteed separation is not mandatory

• Auto-scaling scenarios where you may launch more servers than available hosts

• The safest general-purpose policy for most production deployments

Trade-off: You do not get a strict guarantee that each server is on a different host. Use Anti-Affinity if strict separation is required.

---

Policy Comparison

Policy	Placement Goal	On Insufficient Hosts	Risk
Affinity	Same physical host	❌ Server creation fails	All servers fail together if host goes down
Anti-Affinity	Different physical hosts	❌ Server creation fails	Launch blocked if hosts unavailable
Soft Affinity	Same host (best effort)	✅ Server still launches	Occasional cross-host placement
Soft Anti-Affinity	Different hosts (best effort)	✅ Server still launches	Occasional shared-host placement

---

Choosing the Right Policy

Do you need servers placed TOGETHER for low latency?
│
├── YES
│    └── Can you accept a launch failure if the host is full?
│         ├── YES → Use Affinity
│         └── NO  → Use Soft Affinity
│
└── NO — I need servers SEPARATED for high availability
     └── Can you accept a launch failure if hosts are unavailable?
          ├── YES → Use Anti-Affinity
          └── NO  → Use Soft Anti-Affinity  ← Recommended for most production use

---

Common Use Cases

Scenario	Recommended Policy
MySQL / PostgreSQL primary + replica	Affinity
Redis + App server on same host	Affinity
Web server fleet behind a load balancer	Anti-Affinity
Kubernetes worker nodes	Anti-Affinity or Soft Anti-Affinity
Dev / staging environment servers	Soft Affinity
Production auto-scaling groups	Soft Anti-Affinity
Kafka / Cassandra / HDFS cluster nodes	Anti-Affinity or Soft Anti-Affinity