From f486b2d3aeca9e55b9b8d7572deaef8eb58ff0aa Mon Sep 17 00:00:00 2001 From: "Joshua M. Boniface" Date: Fri, 27 Dec 2024 21:22:28 -0500 Subject: [PATCH] Fix incorrect version --- docs/architecture/georedundancy.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/architecture/georedundancy.md b/docs/architecture/georedundancy.md index ca9314b..233a7e6 100644 --- a/docs/architecture/georedundancy.md +++ b/docs/architecture/georedundancy.md @@ -60,7 +60,7 @@ It is the opinion of the author that the caveats of single-cluster georedundancy ## Multi-Cluster Georedundancy -Starting with PVC version 0.9.103, the system now supports online VM snapshot transfers between clusters. This can help enable a second georedundancy mode, leveraging a full cluster in two sites, between which important VMs replicate. In addition, this design can be used with higher-layer abstractions like service-level redundancy to ensure the optimal operation of services even if an entire cluster becomes unavailable. Service-level redundancy between two clusters is not addressed here. +Starting with PVC version 0.9.104, the system now supports online VM snapshot transfers between clusters. This can help enable a second georedundancy mode, leveraging a full cluster in two sites, between which important VMs replicate. In addition, this design can be used with higher-layer abstractions like service-level redundancy to ensure the optimal operation of services even if an entire cluster becomes unavailable. Service-level redundancy between two clusters is not addressed here. Multi-cluster redundancy eliminates most of the caveats of single-cluster georedundancy while permitting single-instance VMs to be safely replicated for hot availability, but introduces several additional caveats regarding promotion of VMs between clusters that must be considered before and during failure events.