A recently configured cluster is leveraging NearSync with a recovery schedule of 15 minutes. It is noticed that the cluster is consistently transitioning in and out of NearSync.
What action should be taken to potentially address this issue?
A recently configured cluster is leveraging NearSync with a recovery schedule of 15 minutes. It is noticed that the cluster is consistently transitioning in and out of NearSync.
What action should be taken to potentially address this issue?
If a cluster is consistently transitioning in and out of NearSync with a recovery schedule of 15 minutes, it indicates that the time interval might be too short for the current setup to handle the amount of data being replicated. Increasing the NearSync schedule to 30 minutes reduces the frequency of replications, allowing more time for each replication to complete and thereby stabilizing the system.
Seems like the only valid option: https://portal.nutanix.com/page/documents/details?targetId=Disaster-Recovery-DRaaS-Guide-vpc_2023_3:ecd-ecdr-procedure-nearsync-protectionpolicy-pc-c.html
From the course guide: It is also possible for replication to automatically, and repeatedly transition into and out of NearSync. This could be because: • LWS (LightWeight Snapshot) store usage may be high. • Change rate of data may be high for the available bandwidth between the primary and the remote sites. • Internal processing of LWS may take more time because the system may be overloaded. Only option here is network bandwidth
The correct answer is A. Change the NearSync schedule to 30 minutes. Explanation: NearSync with a very aggressive schedule (like 15 minutes) may cause the cluster to struggle with maintaining synchronization, especially if there are significant data changes. By extending the NearSync schedule to 30 minutes, the cluster will have more time to complete each sync cycle before starting the next one, reducing the likelihood of falling behind and transitioning in and out of NearSync frequently. Other options: Increasing network bandwidth (Option B) could help if bandwidth is the issue, but it’s not the primary solution here. Configuring a secondary schedule in the same Protection Domain (Option C) is unrelated to NearSync’s schedule stability. Adding vCPUs to the user VMs (Option D) doesn’t address the NearSync timing issue.
Sync is 0 minutes, Nearsync is 1-15 minutes only, A-sync above 60 minutes so A is an invalid answer.
NearSync only supports 1-minute or 15-minute schedules. Changing the schedule to 30 minutes is not possible, and if you increase the interval, it will fall back to Async replication, defeating the purpose of NearSync.