Tailspin - Latency-Sensitive Tiers and a Legacy Windows Container

Web tier

• Four VMs in an availability set or spread across availability zones. Stateless, no latency coupling, so maximise fault tolerance.

App + SQL tiers

• Put them in a proximity placement group to co-locate them on the same datacenter-scale cluster and remove the cross-cluster hop that produced the 14 ms p95.
• Combine the PPG with an availability set: the PPG alone carries no SLA. Two or more VMs in an availability set (or across zones) is what produces the 99.95% compute SLA; a single VM with Premium SSD is only 99.9%.

The trade-off to state explicitly

• A PPG constrains members to one cluster, which is the same thing that gives low latency and the same thing that removes datacenter-level separation. You cannot co-locate and zone-spread the same pair of VMs.
• Resolution: keep the latency-critical app/SQL pair co-located, and rely on the availability group's second replica plus tested backup/restore for datacenter-level failure. If the business will not accept that, the alternative is zone-spreading the AG nodes and accepting higher synchronous-commit latency - decide it in writing.

Verify the region supports zones and that the required VM sizes are available inside the PPG before committing to the design; PPG allocation failures are a real deployment risk.

Short answer: not as-is in the default mode.

• A Windows Server 2019 base image (ltsc2019) on a Windows Server 2022 host cannot run in process isolation, because process isolation requires the container's OS version to match the host's. The container starts and fails, or is rejected outright.
• Hyper-V isolation gives the container its own kernel and allows the older image to run on the newer host. Cost: a heavier boundary, more memory per instance, and slower start-up.

Recommendation

1. Rebuild on an ltsc2022 base image and run process isolation - best density and the simplest operational model, provided the app passes testing on the newer .NET/host combination.
2. Fall back to Hyper-V isolation only where rebuild is impossible (vendor-supplied component, certification constraints).

The real blocker is the kernel-mode print driver

• Kernel-mode drivers are not something you install into Windows containers; they must be present in the image and the underlying kernel.
• If the driver cannot be packaged, or the vendor will not support it under either isolation mode, this component does not belong in a container. Keep it on a VM and containerise the rest. Flagging that early is cheaper than discovering it during cutover.
• Also confirm the HKCU write is tolerable - container user profiles are ephemeral, so any state that must survive a restart needs to move to a volume or external store.

No - the availability group is an application-level construct, not an Azure SLA construct.

• The Azure SLA is determined by how the VMs are deployed:
  • Two or more VMs in the same availability set, or spread across availability zones: 99.95%.
  • A single VM using Premium SSD (or Ultra Disk) for all disks: 99.9%.
  • A single VM on standard managed disks: no infrastructure SLA.
• An Always On availability group gives you data redundancy and fast failover, but each replica VM is still subject to its own deployment SLA. Two standalone SQL VMs, one per zone, each in no availability construct, do not add up to 99.95% for the pair.

What to do

• Place each AG node in a distinct availability zone (or an availability set if zones are unavailable), so each VM is individually covered.
• Confirm the quorum/witness design does not depend on a resource in the same zone as both replicas.
• Note the tension with the latency design in the previous task: zone-spreading the AG costs synchronous-commit latency. Present the numbers and let the business choose between latency and fault-domain separation, rather than claiming both.