Deploy two nodes in one region in the Azure portal
The 2 nodes, one region (high availability) plan deploys two DTM nodes into one subnet of your existing VNet, in different availability zones where the region has them. It is the usual production shape: the nodes replicate to each other, so a client configured with both node IPs keeps getting answers while one node restarts or is upgraded.
The deployment template is free. Each node 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
Section titled “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 the region you deploy to. The wizard does not create a VNet.
- Two free private IPs in one subnet, either an existing subnet or a new subnet the wizard creates.
Open the plan in the portal
Section titled “Open the plan in the portal”- Open the Hayami DTM Cluster listing and select Get it now.
- Choose the 2 nodes, one region (high availability) plan and select Create. The Azure portal opens the wizard.
Basics
Section titled “Basics”| Field | What to enter |
|---|---|
| Subscription | The subscription that holds your VNet. |
| Resource group | A new, dedicated resource group is recommended. See a dedicated resource group per region. |
| Region | The region of the VNet you deploy into. |
| Resource name prefix | Names both nodes’ resources, with the suffixes -n1 and -n2. Default dtm-ha, at most 20 characters. Choose a stable name: the nodes’ private IPs are the long-lived resolver addresses. |
Virtual machines
Section titled “Virtual machines”The VM size and OS login apply to both nodes.
| Field | What to enter |
|---|---|
| VM size (both 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 | The pair of zones the two nodes are placed in, one node per zone, so a single zone outage cannot take both. Only pairs the region offers are listed. No zone placement (regional) lets both nodes share a zone, and is the only option in a region without zones. 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. |
Networking
Section titled “Networking”| Field | What to enter |
|---|---|
| Virtual network | Your VNet in the chosen region. The list shows each VNet’s address space. |
| Subnet | Use an existing subnet (default) or Create a new subnet. Both nodes share it. |
| Subnet (existing) | The subnet the nodes take their IPs from. |
| New subnet name and CIDR | Shown when you create a subnet. Defaults dtm-subnet and 10.62.250.0/27, carved out of your VNet’s address space. |
| node1 static private IP | A free IP inside the subnet. node1 is the cluster’s primary node. Default 10.62.250.10 on a new subnet; on an existing subnet you enter it. |
| node2 static private IP | A second free IP inside the subnet, different from node1’s. Default 10.62.250.11 on a new subnet. |
No public IP address is created. Configure your VNet’s DNS servers, or your conditional forwarders, with both node IPs.
Access
Section titled “Access”These two ranges become inbound rules on each node’s network security group (NSG). You can change them after deployment by editing the rules.
| Field | What to enter |
|---|---|
| DNS client CIDR | Default VirtualNetwork, which is recommended: it covers the node 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 either node. Restrict it to your operator or jump box subnet where you can. |
Upgrades
Section titled “Upgrades”The Upgrades step has one checkbox, Grant each node’s managed identity the Network Contributor role on the cluster subnet now. It is off by default. Turn it on when the VNet is in another resource group, unless your network team grants the role. Without it, the Lifecycle stable-IP swap cannot join the subnet.
Key Vault
Section titled “Key Vault”The deployment creates a 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 and the deployment adds a private endpoint in the node subnet.
Under Private DNS zone, keep Create a new zone, or choose
Use an existing zone if your organisation manages
privatelink.vaultcore.azure.netcentrally, as an Azure landing zone does. 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 subnet. The subnet must already exist with the
Microsoft.KeyVaultservice 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
Section titled “Review and create”Select Review + create, check the summary, then Create. The deployment takes a few minutes. node1 creates the cluster’s secrets at first boot and node2 joins it.
What the deployment creates
Section titled “What the deployment creates”-
Two DTM VMs from the Hayami DTM image, 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) The node subnet It also denies the console, API, cluster replication (7946) and SSH (22) to the rest of the VNet, so SSH is closed by default.
-
A Key Vault. With the private option, also a private endpoint and, unless you chose an existing zone, a private DNS zone linked to the node VNet.
-
A new subnet, only if you chose to create one.
The deployment never creates a VNet, a public IP or a VNet peering.
After the deployment
Section titled “After the deployment”Open the deployment’s Outputs. They give each node’s private IP, web
console and API addresses, and a recoverAdminAccessCommand.
- Sign in for the first time with the password that command retrieves.
- Verify the cluster: both nodes should report ready.
- Point your clients at both node IPs, then follow the Quickstart to create your first zone and records.
- Upgrades: a portal deployment updates through the Lifecycle page’s stable-IP swap, one node at a time, while the other node keeps 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.