Skip to content
Hayami Docs

Deployment options

Every option deploys the same Hayami DTM image from the Azure Marketplace into your own subscription and an existing VNet you choose. They differ in how many nodes you run and in how many regions, and in whether you click through the Azure portal or deploy as code.

Which option fits

Section titled “Which option fits”
Option Nodes Regions Best for
Single node 1 1 Evaluation and proofs of concept. No failover.
2-node HA, one region 2 1 Production in one region. The recommended starting point.
4-node HA, two regions 4 (2 per region) 2 Production that must survive the loss of a whole region.
Add a node +1 Any Growing a cluster you already run, for capacity or resilience.
Deploy as code 1, or 1 per region, then add nodes 1 or 2 Teams that deploy infrastructure with Terraform, Bicep, or the CLI.

Whichever you choose, read Before you start first. Two things there decide whether a first deployment succeeds: the deployment permissions (Contributor alone is not enough), and your cluster boundary (every node must be able to reach every other node).

Single node

Section titled “Single node”

One DTM node in one subnet of your VNet. It is the quickest way to see DTM answer queries and to try health-gated records, and it is the right choice for evaluation, proofs of concept, and non-production use.

A single node has no failover: if it restarts, DNS from that cluster stops until it is back, and an upgrade means a brief outage. When a pilot succeeds, you can add nodes to the same cluster, or promote the pilot to a production cluster.

2-node HA, one region

Section titled “2-node HA, one region”

Two nodes in one subnet of your VNet, forming one cluster. DNS keeps answering while either node restarts, so upgrades are rolling and need no outage.

This is the recommended starting point for production. Point your VNet’s DNS settings, or your conditional forwarders, at both node IPs.

4-node HA, two regions

Section titled “4-node HA, two regions”

Four nodes, two in each of two regions, forming one cluster. With region-aware records (the region and geo-failover load-balancing methods) and subnet mappings, DTM answers clients from their own region first and fails over to the other region automatically; see Regions and subnet mapping. Clients whose DNS settings, or conditional forwarders, include the nodes in both regions keep resolving through the loss of either region.

The two regions’ VNets must be able to reach each other, so that every node can reach every other node on TCP and UDP port 7946: through VNet peering, or by routing through a hub, VPN, or ExpressRoute. Their address spaces must not overlap.

Connect the two VNets before you deploy. The Marketplace wizard does not create or change any VNet peering, and if the regions cannot reach each other they cannot form one cluster. Each VNet must already exist: the wizard creates at most the node subnet inside it.

Add a node

Section titled “Add a node”

Adding a node grows a cluster you already run: more query capacity, and more nodes that can fail without taking DNS down. The new node joins the existing cluster, copies all of its zones and records, and shares its secrets from the cluster’s Key Vault; nothing about your zones or records changes. Running a single node today? A second node is what gives you failover.

  • Adding nodes: from the Azure Marketplace or with Terraform, including what the existing cluster needs first.

Deploy as code

Section titled “Deploy as code”

You can also deploy DTM as code, from the same Marketplace image. Each route needs a one-time acceptance of the image’s terms in your subscription, covered on its page.

Privacy policyTerms of use