Deploy four nodes across two regions in the Azure portal

The 4 nodes, two regions (high availability) plan deploys two DTM nodes in each of two regions, into your existing VNets, as one cluster. All four nodes replicate to each other, so zone data and health state are the same everywhere. Clients in each region use their local pair, region-aware routing gives them their local backends first, and if a whole region is lost, failover happens in the answers DTM returns, with no client change.

The deployment template is free. Each of the four nodes is billed per VM-hour by the Hayami DTM virtual machine offer, plus your normal Azure costs for the VMs, disks and networking. Your first deployment may ask you to accept the Hayami DTM virtual machine offer’s terms.

Before you start

Read Before you start on the deploy page. For this plan you need:

• Owner, or Contributor plus User Access Administrator, on the target resource group. The deployment creates role assignments, so Contributor alone fails. See Deployment permissions.
• An existing VNet in each region, with address spaces that do not overlap. The wizard does not create a VNet.
• The two VNets already connected, by VNet peering or through a hub, VPN or ExpressRoute, so that all four nodes reach each other on TCP and UDP 7946 (cluster replication) and on TCP 8443 (the API, which a node uses to check that a peer is ready). The wizard does not create or change any peering. If the nodes cannot reach each other, the two regions cannot form one cluster.
• Two free private IPs in one subnet in each region.

Open the plan in the portal

1. Open the Hayami DTM Cluster listing and select Get it now.
2. Choose the 4 nodes, two regions (high availability) plan and select Create. The Azure portal opens the wizard.

Basics

Field	What to enter
Subscription	The subscription that holds your VNets.
Resource group	A new, dedicated resource group is recommended. See a dedicated resource group per region.
Region	The primary region, for nodes 1 and 2.
Resource name prefix	Names all four nodes’ resources, with the suffixes -n1 to -n4. Default dtm-ha4, at most 20 characters. Choose a stable name: the nodes’ private IPs are the long-lived resolver addresses.
Secondary region	The region for nodes 3 and 4, which keep DNS answering if the primary region is lost. It must differ from the primary region. Default North Europe when the primary region is West Europe, otherwise West Europe.

Virtual machines

The VM size and OS login apply to all four nodes.

Field	What to enter
VM size (all nodes)	D2s_v5 is the recommended floor. See Sizing and storage. A later resize restarts that VM, so resize one node at a time.
Availability zones (primary region)	The pair of zones nodes 1 and 2 are placed in, one node per zone. Only pairs the region offers are listed. No zone placement (regional) lets both nodes share a zone. Default Zones 1 and 2 where the region has availability zones, otherwise No zone placement (regional). A node’s zone cannot be changed after deployment.
SSH public key	Paste your SSH public key (ssh-ed25519 or ssh-rsa). The wizard has no password option: the OS has no password login. This is not the DTM admin password, which is generated in Key Vault at first boot.
OS admin username	Default dtmadmin. This login is for break-glass access only; you run DTM from its web console.
Serve the Terraform provider from the cluster	Default No. Choose Yes only if you will manage DTM with Terraform: the endpoints that serve the provider are unauthenticated.

Primary region networking

Nodes 1 and 2 deploy into one subnet of your existing VNet in the primary region. node1 is the cluster’s primary node.

Field	What to enter
Primary VNet	Your VNet in the primary region. The list shows each VNet’s address space.
Primary subnet	Use an existing subnet (default) or Create a new subnet.
Subnet (existing)	The subnet nodes 1 and 2 take their IPs from.
New subnet name and CIDR	Shown when you create a subnet. Defaults dtm-subnet and 10.60.250.0/27, carved out of the primary VNet’s address space.
node1 static private IP	A free IP inside the primary subnet. Default 10.60.250.10 on a new subnet; on an existing subnet you enter it.
node2 static private IP	A second free IP inside the primary subnet, different from node1’s. Default 10.60.250.11 on a new subnet.

Secondary region networking

Nodes 3 and 4 deploy into one subnet of your existing VNet in the secondary region.

Field	What to enter
Availability zones (secondary region)	The pair of zones nodes 3 and 4 are placed in, as for the primary region, with the same default.
Secondary virtual network	Your VNet in the secondary region. Its address space must not overlap the primary VNet’s.
Secondary subnet	Use an existing subnet (default) or Create a new subnet.
Subnet (existing)	The subnet nodes 3 and 4 take their IPs from.
New subnet name and CIDR	Shown when you create a subnet. Defaults dtm-subnet and 10.61.250.0/27, carved out of the secondary VNet’s address space.
node3 static private IP	A free IP inside the secondary subnet. Default 10.61.250.10 on a new subnet; on an existing subnet you enter it.
node4 static private IP	A second free IP inside the secondary subnet, different from node3’s. Default 10.61.250.11 on a new subnet.

No public IP address is created. Configure the clients in each region with both of that region’s node IPs.

Connectivity & access

This step repeats the requirement that the two VNets are already connected and that all four nodes reach each other on TCP and UDP 7946. The two ranges below become inbound rules on all four nodes’ network security groups (NSGs). You can change them after deployment by editing the rules.

Field	What to enter
DNS client CIDR	Default VirtualNetwork, which is recommended: it covers each node’s VNet, peered VNets and networks behind a VPN or ExpressRoute gateway. Enter a CIDR only to restrict DNS to one client range.
Admin CIDR	Default VirtualNetwork. The range that can reach the web console (8080) and API (8443) on any node. Restrict it to your operator or jump box subnet where you can.

Key Vault

The deployment creates one Key Vault for the cluster’s admin password and replication encryption key. Each node reads it at first boot with its own managed identity. Choose how the nodes reach it under Network access:

• Private endpoint (recommended) (default): public access to the vault is disabled. The deployment adds a private endpoint in the primary node subnet and resolves it through a privatelink.vaultcore.azure.net private DNS zone linked to both node VNets. Under Private DNS zone, keep Create a new zone, or choose Use an existing zone if your organisation manages that zone centrally, as an Azure landing zone does. With an existing zone, both node VNets must already be linked to it, and you need permission to add records to it (for example Private DNS Zone Contributor). Azure cannot link a VNet to two zones with the same name, so creating a second one would fail.
• Service endpoint: the vault keeps its public endpoint behind a firewall that admits only the node subnets. Both subnets must already exist with the Microsoft.KeyVault service endpoint enabled, and you tick a box to confirm it. A subnet this deployment creates cannot have it yet.
• Public: the vault’s public endpoint is open; access is still limited by Azure RBAC to the node identities. For evaluations only.

See Key Vault network access for the trade-offs.

Review and create

Select Review + create, check the summary, then Create. node1 creates the cluster’s secrets at first boot and the other three nodes join it across your existing connection between the two VNets.

What the deployment creates

• Four DTM VMs from the Hayami DTM image, two per region, each with its own data disk (deleted with the VM), network interface on a static private IP, and system-assigned managed identity with the role grants in What the managed identity can do.

• A network security group on each node’s network interface:

  Allows	Port	From
  DNS, DNS over TLS, DNS over HTTPS	53, 853, 443	DNS client CIDR
  Web console and API	8080, 8443	Admin CIDR
  Cluster replication	7946 (TCP, UDP)	Both node subnets

  It also denies the console, API, cluster replication (7946) and SSH (22) to the rest of the VNet, so SSH is closed by default.

• One Key Vault. With the private option, also a private endpoint and, unless you chose an existing zone, a private DNS zone linked to both node VNets.

• A new subnet in each region, only where you chose to create one.

The deployment never creates a VNet, a public IP or a VNet peering.

After the deployment

Open the deployment’s Outputs. They give each node’s VM name, private IP and web console address, and a recoverAdminAccessCommand.

1. Sign in for the first time with the password that command retrieves.
2. Verify the cluster: all four nodes should report ready. If a node in the secondary region stays not ready (/readyz returns 503), first check that the two VNets reach each other on TCP and UDP 7946 and on TCP 8443.
3. Point the clients in each region at that region’s two node IPs, then follow the Quickstart to create your first zone and records. For how clients are matched to regions, see Regions and subnet mapping.

Upgrades

The Upgrades step has one checkbox, Grant each node’s managed identity the Network Contributor role on each cluster subnet now. It is off by default. Turn it on when a node’s cluster subnet is in another resource group, unless your network team grants the role. Without it, the Lifecycle stable-IP swap cannot join those subnets.

Day 2

• Upgrades: a portal deployment updates through the Lifecycle page’s stable-IP swap, one node at a time, while the other nodes keep answering. See Path A.
• OS patching: see OS patching.
• Grow the cluster: add nodes. A node you add in a node subnet needs no NSG change; a node in another subnet needs that subnet added to the existing nodes’ port 7946 rules.