Spread Your VPS Across Hosts with Availability Groups

An Availability Group keeps your servers from sharing a single point of failure. Put several VPS in a group and CubePath places each one on a different physical host, so if one machine goes down, the rest keep running. It's how you run a redundant pair or a small cluster without manually checking where each server landed.

It's the standard setup for anything that needs to stay up: load-balanced web tiers, database replicas, and any service where two servers on the same host would defeat the point of having two.

How it works

You create a group in a project and location, then add VPS to it. A host here is one of CubePath's hypervisors: a physical server in the datacenter that runs many virtual machines at once. As each VPS is placed, CubePath puts it on a different hypervisor from the group's other members, so a single hardware failure can only take down one of them. For example, a group of three web servers lands on three separate hypervisors; if one of those machines fails or reboots for maintenance, you lose one server while the other two keep serving. The group is just this placement rule plus a handy way to see your servers together; the VPS run exactly as normal. You manage it in the dashboard or over the API.

Before you start

• In the dashboard: my.cubepath.com → VPS → Availability Groups.
• Over the API: base URL https://api.cubepath.com, authenticate with Authorization: Bearer <token> (scopes vps:read / vps:write), and add X-Requested-With: XMLHttpRequest on writes. Get a token under Account → API Tokens.
• A group lives in one project and one location; the VPS you add must be in that same project and location.

Create a group

curl -X POST https://api.cubepath.com/vps/availability-groups/ \
  -H "Authorization: Bearer $CUBEPATH_TOKEN" \
  -H "X-Requested-With: XMLHttpRequest" \
  -H "Content-Type: application/json" \
  -d '{
    "project_id": 1,
    "name": "web-tier",
    "description": "Web servers spread across hosts",
    "location_name": "us-mia-1"
  }'

That's all a group needs: a project, a name, and a location. A group spreads its members across hosts and holds up to 50 VPS.

Add servers to a group

Add an existing VPS by its id:

curl -X POST https://api.cubepath.com/vps/availability-groups/<group_uuid>/vps/<vps_id> \
  -H "Authorization: Bearer $CUBEPATH_TOKEN" \
  -H "X-Requested-With: XMLHttpRequest"

Or assign the group when you create a VPS, by passing availability_group_uuid in the create request, so it's placed correctly from the start.

To take a server out, DELETE /vps/availability-groups/<group_uuid>/vps/<vps_id>. The VPS keeps running; it just stops being part of the group's spread. A few rules:

• The VPS must be in the same project and location as the group.
• It has to be in a state where it can be modified (not mid-deploy or mid-deletion).

See the group together

GET /vps/availability-groups/<group_uuid> lists the group and its member servers, and GET /vps/availability-groups/<group_uuid>/metrics gives you the group's combined performance metrics, so you can watch the whole tier in one place. You can also point a Cloud Alert at an availability group to be notified on the group's metrics.

Limits

What this doesn't do

• It's placement, not a load balancer. It only controls which physical hypervisor each VPS runs on so your servers don't end up on the same one; it doesn't distribute traffic between them. Put a Load Balancer in front to share requests across the members.
• It doesn't move running servers. The spread is applied as VPS are placed. Adding an existing VPS groups it for management and future placement decisions; it doesn't live-migrate a server that's already running elsewhere.
• It's single-location. A group spreads across hosts within one location. For resilience across regions, run a group in each location.

API reference

GET    /vps/availability-groups/project/{project_id}     List a project's groups.        (scope: vps:read)
GET    /vps/availability-groups/{uuid}                    Get a group and its members.    (scope: vps:read)
POST   /vps/availability-groups/   { project_id, name, location_name }  Create a group.   (scope: vps:write)
DELETE /vps/availability-groups/{uuid}                    Delete a group (must be empty). (scope: vps:write)
POST   /vps/availability-groups/{uuid}/vps/{vps_id}       Add a VPS to the group.         (scope: vps:write)
DELETE /vps/availability-groups/{uuid}/vps/{vps_id}       Remove a VPS from the group.    (scope: vps:write)
GET    /vps/availability-groups/{uuid}/metrics            Combined group metrics.         (scope: vps:read)
POST   /vps/availability-groups/{uuid}/move-project  { project_id }  Move to another project. (scope: vps:write)

All requests authenticate with Authorization: Bearer <token> (or X-API-Key). Write requests also need X-Requested-With: XMLHttpRequest.