Josh:
Chris, let's talk about business continuity, disaster recovery and how companies might be able to get into that quickly and relatively inexpensively. Is that even a possibility today?
Chris:
So the first decision that any company needs to make when considering business continuity is determining what is required for their solution. Is there a subset of their current infrastructure that is required? If everything running in the primary data center is required then the larger the footprint of VMs and applications going to DR will increase the cost. So you want to make sure that your are covering what the organization absolutely needs.
Domain controllers are a must. Database servers most likely are critical any cloud connection servers that you have out there. Of course, whatever primary applications that they need, file shares things along those lines. Those are all part of, you know, the the footprint that I would recommend organizations have.
Josh:
It's easy to sit back and just say, put everything we have running into our business continuity plan, right? Because if it's running, we need it. But in reality, you could easily trim a lot of that back, like you said.
Chris:
That's right. Then once you have an idea of what's required, then you need to start considering your RPO and your RTO, the Recovery Point Objective and your Recovery Time Objective. The Recovery Point Objective is just that it is the point in time in the past at which you are OK with bringing your infrastructure back to.
For example, if you're OK with having your entire infrastructure set up from the previous night's configuration than you have a 24 hour recovery point objective. If you need a four hour RPO, then your solution needs to make sure that it's shipping data to your DR site every four hours to make sure that you can meet your four hour recovery point
Then, once you determine your recovery point, then you need to consider your Recovery Time Objective (RTO). How quickly do you need to have everything back up and running in the event of a dire situation? RPO is a big influencer in cost, but the RTO is the number one factor for cost. The faster that an environment has to be up, the exponential increase in cost for the DR solution. If you're OK having part of your infrastructure up within 24 hours, that could be greatly less reduced cost than if you need to make sure that your entire infrastructure is up within an hour. Because you know there's different solutions for different aspects of this. But the faster that you need DR back up and running, it increases the cost exponentially.
Josh:
Regarding backup and DR, I feel like we're seeing a lot of these these companies that maybe only did backup in the past start to take on some more disaster recovery features and vice versa. What are your thoughts on that and how does that change the decision process for choosing solutions?
Chris:
There are a number of backup vendors out there on the market that will back up your data. They also now provide replication of that data to other locations. Problem with those solutions is that even though they're backing up and replicating the data, you're not really poised to have that restored easily into whatever infrastructure you backed that up to, whether it be, you know, a DRT facility, public cloud, private cloud. Those are just the backup files from your backup, your backup infrastructure. They're ready, waiting to go and be restored out of a backup infrastructure. So if you are using a backup product to replicate your data to a DRT location but you don't have the backup infrastructure in place there, you'll be waiting to set all that up. Then you have to do the restore out of the backups which typically takes a long time (effecting your RTO), then you'll have to start bringing everything up yourself. It's a time consuming laborious process, and you may even have to put hardware at a DR facility in order to do some of that.
On the other side, there are dedicated DR products. They can get your data from your primary data center sent to your DR data center very quickly. They can spin up your infrastructure at the DR data center very, very fast using orchestration and automation features. However, they're not really designed for recovery of individual files or individual VMs. You can get data out of one of those solutions, but it's a very time consuming and laborious process.
We are seeing the two feature sets (Backup and BC/DR) coming together in many of the market leaders and that is a good thing.
Josh:
What about leveraging public cloud for the DR location? Are you seeing tools that integrate into the public cloud and let you leverage IaaS (Infrastructure as a Service) only when you're in that dire situation?
Chris:
Yeah, that is very common today, and it is a by far my number one recommendation for a DR solution because you're not relying on having to provide the hardware yourself. I'm not really a fan of having a co-location or another data center with a bunch of hardware that's just sitting there waiting. It's not a good use of funds for an organization, depending on the scale of the organization, of course, but most organizations just can't afford to have that investment in a DR facility. So going to a public or private cloud is amazing because you just have to pay for the storage and maybe a VM or two that are running in real time for your solution.
In the event you declare a DR event and you start bringing it up, of course, you're going to start incurring more costs because you're now consuming more cloud resources. But at that point, if you're declaring a DR event, you are in need of having those resources at that point so that that is totally to be expected, but you're not on the hook for any of that infrastructure cost while not having a DR event. So I'm a huge fan of going to either a public or private cloud for your DR scenarios. And again, every organization is different. There are organizations that require their standalone data centers with hardware ready to go. But for the majority of organizations, having DR into the cloud in one fashion or another is going to be the right solution for them.
Josh:
There's also a lot of As a Service solutions as well, right, whether it's going to public cloud, or keeping DR internal, the DR application itself, the implementation and management of DR including testing can be offered as a managed service?
Chris:
Yep. As with any platform, it's only as good as the management that's supporting it. So once you deploy a DR solution and get it up and running, you can't just let it sit there. You need people who are managing that platform for you, keeping up with changes in the primary data center.
DR as a service is becoming very popular because an organization can partner with a technology company that specializes in BC/DR. They will provide the software, they will provide the storage and compute resources, then they manage everything for you. They work with your team to get everything set up, get everything configured, and they then they make sure everything stays running. They also will most likely conduct a annual test of your DR to make sure that it's meeting your needs to make sure it's working.
Josh:
Connectivity between the DR site and all other business locations is often overlooked isn't it?
Chris:
It is, and not only that but connectivity to the VMs and resources that are now running at the DR site. This often requires IP address changes and possibly routing changes in the network and that can be complicated to implement which can increase RTO. I think using tools that orchestrate these changes provides the best results and having it all wrapped with a managed service can make it fool proof.
If you are facing a challenge similar to this in your IT organization, we are prepared to help get you moving in the right direction. Feel free to reach out to me and we can get the conversation started.
No comments:
Post a Comment