Seasonal Burst Capacity on NC2 with a Single-AZ Constraint
Northline Retail runs a five-node Nutanix cluster on-premises with 180 VMs. Demand triples for eight weeks each November. The order database must stay on-premises because of 3 ms latency to a mainframe; web front ends and batch reporting can move. The team proposes a six-node NC2 on AWS cluster in us-east-1, all nodes in one availability zone, with Prism Central as a VM on that same cluster. Finance will approve only eight weeks of run time and refuses to pay for idle capacity. The on-prem cluster has 22% CPU and 55% memory headroom; the burst VMs are 120 web VMs (4 vCPU/16 GB each) and 30 batch VMs (8 vCPU/32 GB). The company has no AWS operations staff and wants a repeatable annual pattern. Leadership asks whether one AZ is acceptable and how to avoid overbuilding.
1. Recommend an initial NC2 cluster size and scaling approach for the eight-week burst. State your assumptions and explain whether a six-node starting point is justified.
Read the worked answer
Use the NC2 sizing tool, but the arithmetic already shows the binding constraint. The burst tier requests 2,880 GB of guest memory: 120 × 16 GB = 1,920 GB for web, plus 30 × 32 GB = 960 GB for batch. A six-node i3.metal-class cluster gives roughly 3,072 GiB aggregate memory, so six nodes is not obviously overbuilt; it is close to the minimum if web and batch peak together. The catch is N+1: six nodes leave almost no spare memory for a node loss. Because the web tier is stateless and the order database stays on-premises, accepting reduced N+1 for eight weeks is a defensible business decision, but it must be written down. If batch can run off-peak, start with five nodes and schedule the sixth before the peak; if all 150 VMs run concurrently, start with six and treat a seventh as the resilience option. Do not call N+1 idle capacity; it is an availability trade-off that finance should price explicitly.
2. Where should Prism Central run, and what management-plane risk does that create?
Read the worked answer
Running Prism Central as a VM on the same NC2 cluster is the lowest-cost and simplest choice for an eight-week burst, and it is what the team proposed. The risk is correlated failure: if the AZ or cluster is unavailable, Prism Central is unavailable with it. For this workload that may be acceptable because the on-premises order database remains authoritative and the web tier is stateless. Mitigate by documenting Prism Element direct access for basic VM operations, taking a Prism Central backup to S3 before and after the peak, and testing restore into the NC2 cluster. If leadership requires Prism Central to survive an AZ loss, put Prism Central on-premises and register the NC2 cluster to it, or deploy a separate small management cluster in a second AZ. Both add cost and network dependencies, so the decision should be driven by whether the business needs central management during an AWS AZ event, not by a generic best practice.
3. What data protection model fits the burst tier, given that the order database never moves?
Read the worked answer
Protect only the state that matters. The web tier should be treated as disposable: build it from images or automation, store configuration in source control, and avoid local state. Batch outputs and reports should land in S3 or be replicated to on-premises storage, not left on instance disks. For any stateful VM that slips into the burst tier, create a protection domain with local snapshots and replication to the on-premises cluster or a second AWS location. Set retention to cover the eight-week window plus one month, and test a restore before the peak. Do not design a full active-active DR posture for a temporary tier; that would recreate the idle-capacity problem finance rejected. The key judgement is to separate rebuildable configuration from data that needs snapshots, and to prove the restore path while the cluster is still small.