A hospital group is replacing its ISE hardware appliances with VMs on a cluster that also runs other security workloads. The replacement must sustain the same peak RADIUS authentication rate as the appliance, absorb heavy session-log volume without slowing authentication, and stay predictable when neighboring VMs spike. Which VM sizing approach meets all of these requirements?
Select an answer to reveal the explanation.
Short Explanation
You sized it like a physical box: the ISE VM gets CPU, memory and disk speed that nothing else can borrow, and it's that exclusivity that holds latency steady. Reserved resources are the rush-hour lane you own instead of share. The shared-disk and overcommit habits look efficient but quietly give that lane away.
Full Explanation
ISE keeps pace with its hardware counterpart only when the virtual machine has CPU cycles, memory and disk bandwidth it does not share, so reserving vCPUs, pinning RAM and backing the data disks with fast local storage reproduces appliance-class authentication throughput. The shared thin-provisioned NFS approach fails the log-volume requirement because session and syslog writes queue behind array contention, and snapshot jobs land on the same spindles right when logging spikes. Sizing above the appliance baseline while the host overcommits resources fails the predictability requirement, since borrowed capacity disappears exactly when neighboring guests surge. Starting with fewer vCPUs than the appliance fails throughput parity, because peak authentication rate depends on ready cores rather than generous memory or quick disks. Exam caveat: published sizing guidance shifts between releases, so learn the principles instead of memorizing core counts. Practical check: during a peak login window, watch CPU ready time and disk latency and confirm the VM holds the rate of the appliance it replaced.