Fake a stretched cluster for fun and profit


Become An Insider

Sign up now and get free access to hundreds of Insider articles, guides, reviews, interviews, blogs, and other premium content from the best tech brands on the Internet: CIO, CSO, Computerworld, InfoWorld, IT World and Network World Learn more.

True stretched clusters are out of reach for many, but you can use the concepts to avoid downtime -- even amid major upgrades

Last week, I wrote about the huge benefits and associated challenges of implementing "stretched" virtualization clusters. These offer tangible benefits over traditional hot/warm site implementations in that they allow workloads to be seamlessly migrated from one site to the other. In some cases, they even allow site fail-over to take place automatically.

But the expense of clustered storage -- not to mention the complexity involved -- put true stretched clusters out of reach for many organizations that could benefit from them. In spite of that, even if you don't have the right kind of back-end storage to implement a true stretched cluster, you may still be able to reap some of the flexibility benefits they bring to the table and ease the heavy lifting of complex upgrades and stringent uptime requirements.

Recently, I found myself faced with the prospect of upgrading a sizable dual-site virtualization infrastructure. Though each upgrade taken individually wasn't that complicated, a strict zero-downtime requirement meant that careful planning would be required. In the end, the solution leveraged many of the same concepts present in stretched clusters, illustrating that you can enjoy some of the benefits without having all of the pieces in place.

The challenge
The pre-upgrade infrastructure consisted of two fiber-attached sites each with their own synchronously replicated Fibre Channel-based storage arrays and blade-based virtualization clusters. During the course of the upgrade, new virtualization blades would be implemented at the production site, the older production virtualization blades would be migrated to the recovery site, and the recovery site virtualization blades would be retired. Along the way, the hypervisor -- VMware vSphere in this case -- would also undergo a major version upgrade, along with all of its dependent components: vCenter, Site Recovery Manager, View, and so on.

To continue reading, please begin the free registration process or sign in to your Insider account by entering your email address:
From CIO: 8 Free Online Courses to Grow Your Tech Skills
View Comments
You Might Like
Join the discussion
Be the first to comment on this article. Our Commenting Policies