Linked-Clone Boot Storm at Shift Start
FusionAccess 8.x serves 900 users from one site with two ITA nodes, two HDC nodes, two WI nodes, and 10 GE links. Desktops are linked clones from a 60 GB Windows 10 template, sized 4 vCPU / 8 GB, spread across 12 datastores on one all-flash array rated 45,000 IOPS at 1 ms. At 08:30 nearly all users log in within a 20-minute window. From 08:45 the array reaches 95,000 IOPS and 28 ms latency, users see preparing desktop for 9 to 14 minutes, HDC CPU stays near 35 percent, and network peaks at 2 Gbps. Logs show most desktops were powered off overnight by a power-saving policy and are cold-booting. The customer blames FusionAccess and asks for two more HDC and ITA VMs.
1. Identify the bottleneck and explain which measurements support your conclusion.
Read the worked answer
The bottleneck is shared storage IOPS during a cold-boot storm, not the connection brokers. Three observations point the same way. First, array IOPS doubles from a 45,000 rating to 95,000 observed while latency rises from 1 ms to 28 ms; saturation and queueing are visible at the device. Second, HDC CPU remains at 35 percent and the network at 2 Gbps, so neither broker processing nor link capacity is exhausted. Third, the time window matches mass cold boots after the overnight power-off policy, and the user-visible phase is preparing desktop, which is dominated by reading the clone and starting services. Adding HDC or ITA nodes would add broker capacity that is not the constraint and would not reduce a single read from the array. A useful confirmation is per-datastore IOPS and latency: if a few datastores carrying many clones show the highest latency, the boot-storm diagnosis is confirmed rather than a general array fault.
2. Rank remediation options by effect and effort, and say which one you would implement first.
Read the worked answer
The highest-effect, lowest-effort change is to stop the synchronized cold boot. Stagger desktop power-on before the shift, or remove the aggressive overnight power-off for the majority of users, so boots spread over 30 to 40 minutes. This directly cuts peak IOPS and can be piloted with one desktop group. Next, use the platform's desktop pre-start and login control features to cap concurrent boots per datastore, accepting a slightly longer queue for a much shorter per-user wait. Then apply per-VM or per-datastore IOPS limits so infrastructure and management traffic are not starved during the peak, and separate infrastructure VMs onto their own datastore. Medium effort: rebalance clones across more datastores and enable read caching where the array supports it. Higher effort: add all-flash capacity or move heavy users to full copies. I would implement staggered power-on first because it changes demand rather than buying capacity for a 20-minute spike.
3. What would you monitor after the change, and what would make you reopen the design?
Read the worked answer
Monitor peak array IOPS and latency, per-datastore queue depth, the time from user login to desktop ready at the 50th and 95th percentile, concurrent boot counts, HDC and ITA CPU, and network utilization. The target is not zero latency but a predictable login time under the agreed service level, for example 95 percent of users ready within 3 minutes. Reopen the design if latency still exceeds 10 ms after staggering, if the 95th percentile login time remains above the service level, or if IOPS growth suggests the next hardware refresh is less than six months away. Also watch for a shifted peak: if users ignore the stagger and all arrive at 08:30, the demand-side fix is fragile and a capacity or caching change becomes necessary. Track the boot-storm fix separately from any later template change, so the effect is measurable.