Concepts
Locations
Regions and their availability zones, how to spread servers for high availability, and why Stockholm routes traffic but runs no servers.
Ankra Cloud is organised in regions (a metro, for example eu-central in Germany) and availability zones
inside them (for example de-fsn1). Every server, volume, network and load balancer lives in one zone; private
networks and backup copies can span the zones of a region.
GET /v1/regions lists the regions with their zones and GET /v1/zones lists the zones, both in the order the
portal shows them (each zone's position, a region by its first zone). GET /v1/zones/{zone}/capabilities says what
a zone offers right now.
Current locations#
| Region | Zone | Location | What it offers |
|---|---|---|---|
Sweden, eu-north |
se-sto1 |
Stockholm | Network location: IPv6 and IPv4 routing for the whole cloud; no servers |
Germany, eu-central |
de-fsn1 |
Falkenstein 1 | Servers, storage, networks, load balancers, databases, object storage |
Germany, eu-central |
de-fsn2 |
Falkenstein 2 | Servers, storage, networks, load balancers, databases, object storage |
Germany, eu-central |
de-nbg1 |
Nuremberg 1 | Servers, storage, networks, load balancers, databases, object storage |
High availability: zones in a region#
Each availability zone is an independent failure domain: its own power, network, gateways, storage and hypervisor
hosts. Inside one zone, high availability comes from its hosts: a zone marked HA in the portal runs servers on
several hypervisor hosts with live migration (a server moves off a host without stopping) and automatic restart
on host failure. The deploy page and the overview show it per zone, from the zone's capabilities
(compute_nodes, features.live_migration, features.ha_restart).
A zone can still fail as a whole. To keep a service running through a zone outage, run it in two or more zones of the
same region: a private network can span the region's zones, a server group with spread: zone places its members in
different zones, and backups are copied to another zone of the region by default.
On the deploy page you pick the region first (Germany is the default) and then the availability zone inside it
(de-fsn1 by default).
Stockholm: a network location#
Stockholm runs no servers. It is where the cloud meets the IPv6 internet:
- IPv6 transit. The cloud's public IPv6 prefix
2a13:7c82:103a::/48is routed to Stockholm and carried from there to the zones. Each zone announces its own block of it (2a13:7c82:103a:100::/56for de-fsn1,2a13:7c82:103a:200::/56for de-fsn2), and every server gets a /64 of its zone's block. - IPv4 egress for IPv6-only servers (NAT64). Traffic from any server to
64:ff9b::/96is translated to IPv4 in Stockholm and leaves from136.148.210.54. IPv6-only servers reach IPv4-only names through their DNS64 resolvers and IPv4 literals through the CLAT every server runs (464XLAT), so a server without the IPv4 add-on still reaches the IPv4 internet. Sites it talks to see136.148.210.54as its address.
Because it has no compute nodes, the zone's capabilities report features.compute: false with the reason
network-only location: IPv6 and IPv4 routing. The deploy page shows Stockholm as a network location that takes no
servers, and POST /v1/servers with "zone": "se-sto1" is refused with 409 Conflict and the same reason, before
anything is created or billed. Deploy your servers in a zone of Germany; their IPv6 and their IPv4 egress go through
Stockholm without any setting on your side.