A multi-cluster Nutanix estate uses Metro availability for a set of AHV VMs. During a network test, the remote site becomes unreachable while the protected VMs are actively writing data. Which behavior should the administrator expect?
Select an answer to reveal the explanation.
Short Explanation
Think of synchronous replication like a signature that must be witnessed before the contract is final. If the witness is unreachable, you can't sign, so your writes wait. That's why a Metro write path can stall when the remote site can't acknowledge.
Full Explanation
Metro availability relies on synchronous replication between sites, so a write is not considered complete until the local and remote storage layers acknowledge it. When the remote site is impaired or unreachable, that acknowledgment cannot be returned, and the write path can stall to preserve consistency and an RPO of zero. This is the trade-off of synchronous protection: strong data consistency can reduce write availability if the peer site fails. Async replication does not require a remote acknowledgment before completing local writes, so it continues accepting writes and transfers changes in the background rather than automatically failing VMs over. NearSync is also asynchronous and is designed for low recovery point objectives, not for blocking I/O until a remote site confirms every write. Flow network policies govern traffic filtering and security rules, not the write acknowledgment semantics of replication. Exam caveat: do not confuse Metro synchronous replication with async or NearSync behavior; only synchronous paths can block writes when the peer cannot acknowledge. Operational check: review protection domain health, replication latency, and remote site connectivity before changing workloads or failover settings.