You may ask yourself: Why blog about a VMware environment? In parallel to “learn to crawl before you run” I feel that a lot of people working with kubernetes have a requirement (or at least THINK they have a requirement) for active/active metro storage solutions under their kubernetes setup. Building out a metro environment seems really easy, but as I run through this series you’ll discover that metro is anything-but-simple; there are many things to consider… Things that VMware figured out in their stretched cluster setup where kubernetes will struggle. I hope that people will start to see what metro is all about when I revisit the world of Virtual Machines.
The different parts of this series
There is just SO MUCH to tell!! At first I did not really know where to begin, until I came up with a run through of all things metro. This has turned out to be quite a large series, and I will update this post as I add episodes. The episodes I will be covering are listed below. As I add episodes these items will change into hyperlinks:
- A Brief History of Metro part 1 – Replication versus Metro
- A Brief History of Metro part 2 – Metro Architectures (Uniform and non-uniform access methods)
- A Brief History of Metro part 3 – Sidedness, Witness and APD/PDL scenarios
- Lab Setup overview and walkthrough – What runs where, how are things connected, configs of PowerStore and vSphere
- Break Stuff 1 – Datacenter Interlink failure – What is the impact when I cut the interlink between the twin datacenters?
- Break Stuff 2 – Failing all hosts in a Datacenter – What is the impact of loosing all hosts in one datacenter at the same time?
- Break Stuff 3 – Failing an entire DC (no witness). What if we loose an entire datacenter when we have no witness?
- Break Stuff 4 – Failing an entire DC+witness. How will the addition of a metro witness service change what gets recovered?
- Break Stuff 5 – Failing one Array – Is VMware HA smart enough to recover the workloads even if no ESX hosts have failed?