I was thrilled to learn about the upcoming x-replicas-on-different feature in LINSTOR. For those who might be unfamiliar:
About a year ago I opened an issue on the Piraeus operator repo in which I wrote:
I’ve been exploring multi-availability zone setups offered by various cloud providers, aiming to architect a robust DR solution for potential datacenter failures. With the Kubernetes control plane being HA in most configurations and resilient to a datacenter outage, I’m keen on ensuring a similar resilience for my storage layer.
My primary objective is to operate predominantly in one zone (datacenter) while maintaining an additional asynchronous replica for each resource definition in another zone. This setup would act as a safety net, enabling a swift switch to the standby zone with minimal RTO and RPO should the primary zone encounter issues. While the latency between AZs is generally low, I’m specifically looking for an asynchronous solution to ensure maximum performance in the primary zone without being impacted by any inter-zone communication delays. Additionally, even with low latency, the asynchronous setup provides a buffer against any unforeseen network anomalies between zones.
While the piraeus-ha-controller has been instrumental for quick failovers, its quorum-based scheduling poses challenges. Specifically, achieving quorum becomes problematic if the primary zone goes offline. Additionally, the current placement parameters make it challenging, if not impossible, to schedule X replicas in zone A and Y replicas in zone B.
I’ve come across setups using DRBD with Pacemaker and Booth for similar requirements. It got me wondering if we could have something akin to that but tailored for a single Kubernetes cluster environment. Perhaps an additional controller that could manage this.
My questions:
-
With the new
x-replicas-on-different
feature its now possiblee to have two replica’s in one datacenter (DC) and a third in a different DC. The blog posts title by @kermat mentions “High Availability & Disaster Recovery”, but it doesn’t fully explain what happens in the event of a datacenter failure. Would we still need three datacenters to maintain quorum if one goes down? -
Can we configure asynchronous communication between datacenters based on placement parameters? As mentioned in my issue, I prefer to avoid synchronous communication between datacenters to prevent performance impacts due to inter-zone delays.
-
Overall, is the scenario I described now achievable with this new feature?