Evaluate with the PoC lab

The PoC lab deploys DTM plus everything needed to see it work: two demo backend VMs serving self-identifying landing pages (a green “BACKEND A” and a teal “BACKEND B”), and a jumpbox to drive it all from. Load balancing, health-gated failover, and weighted canary answers become something you watch happen, not just dig output.

The lab kit (deploy/terraform/environments/poc-lab/) is available from support, and deploys in two stages by design:

1. Stage 1: the lab surroundings: a dedicated VNet (standalone mode), the two demo backends, and the jumpbox (or optional Azure Bastion).
2. Stage 2: the DTM cluster itself, deployed by the standard Terraform starter into the same VNet, exactly the way production deployments work. The lab never forks DTM’s deployment path, so what you evaluate is what you would run.

./deploy.sh runs both stages in order; ./destroy.sh tears them down in reverse.

Caution

The lab bills. Stage 2 deploys the DTM Azure Marketplace plan, so the DTM licence charge applies for as long as the lab runs, on top of the Azure infrastructure (two Standard_D2s_v5 DTM nodes are the dominant cost, plus three small lab VMs, disks, and a Key Vault: budget in the low tens of GBP/EUR per day). Deallocating the VMs overnight pauses both charges, which is the cheap way to stretch an evaluation across days; only ./destroy.sh ends everything.

Modes

Mode	Set	You get
Standalone (default)	nothing extra	A dedicated 10.60.0.0/16 lab VNet, jumpbox with SSH locked to your IP. Fully isolated; teardown removes everything.
BYO VNet	create_vnet = false + existing_vnet_* + free subnet ranges	Lab subnets carved into your VNet; access over your existing connectivity. Your VNet is referenced, never created or destroyed.

Either mode can add Azure Bastion (deploy_bastion = true) for organisations that forbid public IPs on VMs; Bastion bills hourly while the lab exists.

A portal-first ARM variant of stage 1 (standalone mode only) ships under deploy/arm/poc-lab/; its README has the sequencing.

Prerequisites

• Terraform 1.11 or later (the lab’s second stage deploys the standard Terraform starter, which requires it) and the Azure CLI, logged in to the target subscription.
• Rights to create resources and role assignments there (Owner, or Contributor plus User Access Administrator), as for any DTM deployment.
• An SSH keypair.

Deploy

cd deploy/terraform/environments/poc-lab
cp terraform.tfvars.example terraform.tfvars   # fill in: subscription, SSH key, admin_cidr
./deploy.sh

The script finishes by printing the demo backend IPs, the DTM resolver IPs, and the command that retrieves the initial admin password from Key Vault.

Everything is private except the jumpbox’s SSH port (restricted to your admin_cidr). To use the DTM web UI and API from your own browser, tunnel through the jumpbox:

ssh -L 8443:<dtm-node-ip>:8443 -L 8080:<dtm-node-ip>:8080 labadmin@<jumpbox-public-ip>
# then browse https://localhost:8080 (UI) and https://localhost:8443 (API)

Run ./lab-verify.sh <dtm-node-ip> <dtm-node-ip-2> on the jumpbox for a quick smoke test of cluster readiness and both landing pages. Re-run it after exercise 1 and its round-robin check will pass too, because that exercise creates the www.lab.dtm.internal name the script looks for.

The exercises (about 30 minutes)

Work these in order; each one demonstrates a capability the previous one set up. Commands run on the jumpbox unless noted; UI steps happen in the tunnelled browser session, signed in as admin with the Key Vault password.

1. Create the lab zone and a two-value record

In the web UI: Zones > Create Zone > lab.dtm.internal (the name lab-verify.sh checks). Then in the zone: Add record, name www, type A, TTL 5, two values: 10.60.1.10 and 10.60.1.11 (the two demo backends; the deploy output printed them). Set the load-balancing policy to round-robin.

Verify from the jumpbox:

dig @<dtm-node-ip> www.lab.dtm.internal +short

Each query returns one address, alternating between 10.60.1.10 and 10.60.1.11: that is round-robin at work.

2. Watch load balancing in a browser

The landing pages make the rotation visible. Fetch whatever DNS answers first, a few times:

for i in 1 2 3 4 5 6; do
  ip=$(dig @<dtm-node-ip> www.lab.dtm.internal +short | head -1)
  curl -s "http://$ip/" | grep -o "BACKEND [AB]"
done

You should see BACKEND A and BACKEND B alternating as DTM alternates which backend answers each query.

3. Health-gate the record, then break a backend

On the www record, enable a health check: protocol http, port 80, path /. Within a probe interval both values show healthy on the Health Checks page.

Now break one backend (from your workstation, not the jumpbox):

az vm deallocate -g rg-dtm-poc-lab -n backend-b

Within a couple of minutes (three failed probes at the form’s prefilled 30-second interval; the product default is 15 seconds; about 90 seconds after the VM stops answering) DTM stops answering with 10.60.1.11:

dig @<dtm-node-ip> www.lab.dtm.internal +short
# only 10.60.1.10 now

The browser loop from exercise 2 now only ever prints BACKEND A: clients are steered around the failure with no client-side changes. Bring it back (az vm start -g rg-dtm-poc-lab -n backend-b) and watch it return to rotation once probes pass again. This is the health-check engine doing in the lab exactly what it does in production.

4. Flip to a weighted canary

Edit the www record’s load-balancing policy to weighted, with weights 90 for 10.60.1.10 and 10 for 10.60.1.11. Then sample the answers:

for i in $(seq 1 20); do
  dig @<dtm-node-ip> www.lab.dtm.internal +short | head -1
done | sort | uniq -c

Roughly nine answers in ten lead with backend A: a 90/10 canary split, declared on the record rather than built out of extra infrastructure. Flip the weights to shift traffic, or return the policy to round-robin when done.

5. Tour the rest

• Dashboard: cluster health, query volume, and both nodes visible.
• Health Checks: per-probe status for the checks you created.
• Audit Log: every change you just made, attributed and timestamped.
• The same operations, scripted over the API or managed with Terraform: the lab cluster is a full DTM, so anything in these docs works against it.

Optional: add a second region

The core lab is deliberately single-region. To demonstrate region-aware answers: deploy stage 1 again in a second region (new terraform.tfvars, new resource group, a new address space such as 10.61.0.0/16), peer the two VNets both ways, then add a DTM node in the second region joined to the existing cluster. The dual-region tutorial covers region mapping and the failover drills from there.

Teardown

./destroy.sh   # stage 2 first, then stage 1

Standalone mode removes everything the lab created. In BYO mode your VNet and resource groups are untouched; on a BYO Key Vault, the cluster secrets written at bootstrap survive destroy, so remove them deliberately if you are done with them.