JetStream Software, a software development company based in San Jose, California, recently participated in Gestalt IT’s Cloud Field Day on cloud-native disaster recovery (DR) for vSphere environments.
If you want to get a thorough, technical introduction to a cloud technology in the market, the Cloud Field Day event videos are a great place to start. Vendors present to a crew of about a dozen experts in the field, called delegates. There’s a good deal of friendly, technical back-and-forth between the delegates and the vendors, so watching a video from the event feels more like listening in on a conversation than sitting through a presentation.
As part of our Expert Q&A program, we started this series with JetStream Software President and co-founder Rich Petersen sharing his perspective on the economic and operational benefits of using JetStream for DR in the cloud. Below, we are going to take a deep dive with Senior Solutions Architect Dennis Bray on several use case demos. We will wrap up in a final post with co-founder and CTO Serge Shats sharing presentations from integration partners Microsoft and NetApp.
To replay the JetStream and partner presentation videos in full, please visit https://techfieldday.com/companies/Jetstream-software.
VMblog: Hi Dennis. Can you introduce yourself?
Dennis Bray: My name is Dennis Bray, and I’m a senior solutions architect with JetStream Software. I’ve been a certified VMware trainer, consultant and architect working with issues related to storage and networking in VMware environments for longer than I care to discuss.
VMblog: You ran a demonstration of the JetStream DR software at Cloud Field Day. Tell us a little about what you showed the delegates.
Bray: I usually start a demonstration with an introduction of the core architecture. Because there are so many legacy DR architectures in which the protected site and the recovery site are somehow coupled and require communication with each other, people often assume that’s how our software works as well. But it doesn’t. We continuously replicate everything into the object store.
And I don’t mean just data – everything you would need to faithfully rebuild an exact copy of a protected domain – it’s all in that container in the object store. So, the network configuration, the recovery policies like whether to maintain MAC addresses, is just an enormous amount of information; it’s all in that object store. So, I call it the “storage site” because it really is independent of the recovery site. If at the last minute you needed to recover into a different environment from the one you had originally planned on, you could easily do that.
VMblog: That’s an important distinction, and I’m glad you took the time to make it clear. What else did you think was important to explain before starting the demo?
Bray: Well, because we use IO filters to capture data as it’s written in the production environment, we always have what we call a “near-zero” RPO, assuming a robust network, of course. But the RTO can be slower if we have to rehydrate the data from the object store (or in this case, Azure Blob Storage) into the recovery site.
We provide the option for “standard failover,” which uses the much less expensive object storage to maintain the data until it’s needed, but we also provide an option for “continuous failover,” which can sound a little confusing. But basically, it just means that some virtual machines can have their data rehydrated from the storage site into the recovery site pretty much as soon as it’s received.
In the event of an incident, there’s no need to rehydrate the data into the recovery site because it’s already there. So, your RTO for virtual machines protected in “continuous failover” mode is just the few minutes it takes transfer ownership to the recovery site and for the recovered VMs to spin up.
VMblog: That’s a good idea, but it sounds like it would increase your infrastructure costs. Isn’t the value of JetStream that you avoid expensive storage?
Bray: That’s where Azure NetApp Files (ANF) comes in. We can rehydrate data into the vSAN hosts in the recovery site, but if you’ve only got a pilot light cluster, there’s only so much data that you can locate there. ANF provides a convenient target for rehydrated data that is both economical and immediately available to the failover cluster as soon as the VMs are running. So, you can still get near-zero RTO at a lower cost than you might expect.
VMblog: OK, let’s get into the demonstration of the JetStream DR software that you ran at Cloud Field Day. Tell us a little about what you showed the delegates.
Bray: The challenge with demonstrating JetStream DR is that it’s so versatile, and different customers will use it in different ways. At the most basic level, they can recover into almost any VMware environment. But because we do so much work with Microsoft customers, we chose to show failover into an Azure VMware Solution private cloud – in this case, one that was located in Sweden. Now, there’s also the choice between on-prem to AVS failover versus failover from one AVS data center to another AVS data center. We support both, but for this demo, we chose to fail over from our on-prem data center in San Jose to the AVS data center in Sweden.
VMblog: That sounds good. That way you had a single demo to run.
Bray: No, not really, because even with the choice of on-prem to AVS, a customer has a lot of options, so we actually showed the delegates three different failover processes, all running concurrently.
VMblog: What were the three demos?
Bray: We had three domains, and they were each protected in a slightly different way, so they each failed over differently. We had three domains in our San Jose location, and all three were configured to fail over to the AVS data center in central Sweden.
- Domains 1 and 2 had continuous rehydration, also called “continuous failover,” enabled. The difference was that Domain 1 had its data continuously rehydrated directly into the vSAN cluster in the recovery site, while Domain 2 had its data continuously rehydrated into ANF. To some extent, the point of this part of the demonstration was to show that Domain 1 and Domain 2 had roughly identical RTOs.
- The demonstration with Domain 3 showed that with a smaller number of VMs and a bit less data, the RTO for standard rehydration isn’t too bad. By the time we’d observed Domains 1 and 2, Domain 3 had also been recovered and was running in the recovery site, even though the VMs and their data were recovered from the Microsoft Azure Blob Store.
VMblog: This has me curious, and I think I’m going to watch the videos now. But for people who don’t have the time, what is the take-away from your demo?
Bray: Well, the primary purpose of any demo is to show that the technology actually does what you claim it does. But there’s something more important here, and I think it’s this: We provide a single platform for cloud-based DR, and it’s very closely integrated with Microsoft AVS. I didn’t have time to show how seamlessly JetStream DR is integrated with AVS in terms of deployment, administration, licensing, etc., but there’s a lot going on behind the scenes.
More importantly, I hope that the demo shows that an administrator can adopt a single platform for cloud-based DR and a single cloud infrastructure provider like AVS and still have a range of options with respect to their DR requirements and budget constraints. Not every VM or cluster is going to be tier one, and protecting workloads with large amounts of data is always going to present difficult decisions to organizations. I hope people see this demo and it sparks some ideas that they hadn’t thought about before.
VMblog: Thanks Dennis, great insight into JetStream DR. Readers can learn more by contacting JetStream Software at www.jetstreamsoft.com. Coming up next is the final Expert Q&A in this series. JetStream Software CTO and co-founder Serge Shats will share highlights of Cloud Field Day presentations by integration partners Justin Jakowski, Azure cloud infrastructure solutions professional at Microsoft, and Prashant Desai, senior director of product management at NetApp.
##
