Swapnil Bhartiya: Database administrators are tired of being told that their SQL Server is highly available when everything actually lives in one cloud. If there is an outage in one region of Azure, that means that your entire stack will go down because your primary and DR both rely and depend on the same vendor, same cloud. So how do we fix this? To talk about that, we have with us once again Dave Bermingham, Senior Technical Evangelist at SIOS Technology to explore what Multi Cloud HADR actually means. They will also be speaking at Day of Data next month, so we are going to cover our topics. Dave, it’s great to have you on the show. You are going to speak at Day of Data next month for database administrators who are managing SQL Server today. What’s the real world pain point that Multi Cloud HADR solves for them?

Dave Bermingham: Yeah, thanks for having me again, Swapnil. Yeah, we’re looking forward to going back to Jacksonville. I’ve been there a few times, always a great event and this time I have two technical sessions. One is like we mentioned, we’re going to be talking about Multi Cloud high availability, just some really great information, some technical details, some how to’s, but I’m also doing a kind of intro track for those maybe students that are graduating or looking or people making career changes on just very high level 101. What is high availability? What do you need to know? So I have two tracks in Jacksonville as far as the event. There’s going to be lots of great speakers. I’m sure there’s going to be everything from the nuts and bolts of how to optimize queries to just again there’s a whole track for students and people looking for career changes that are just going to be more high level and give you some good information to investigate. So I’m looking forward to it. My session on Multi Cloud and that you mentioned, what are some of the real world pain points that Multi Cloud HADR solves? Of course the biggest pain point is unplanned downtime that you can’t control, right? If you’re relying on a single cloud provider, you’re ultimately dependent on that cloud provider being up and available. Now you can design for multi region within that cloud and that definitely can help. But there’s a broader issue that impacts availability. If the cloud provider is having a really bad day and the worst case scenario you could be sitting there waiting for the cloud provider to fix it if you don’t have another plan in place. Well, Multi Cloud gives the DBA a way to take back some control. It allows you to recover from scenarios that would otherwise be completely out of your hands. And that’s a big deal when uptime really matters.

Swapnil Bhartiya: Can you walk us through a specific failure scenario? Say an Azure region goes down and explain how multi cloud HADR handles the recovery there?

Dave Bermingham: Yeah. So let’s say your primary workload is running in Azure and you’ve got a DR site set up in AWS. You have, like we’ve discussed, there’s ways of getting your data from Azure into DR, Azure into AWS, but essentially your data is sitting there in AWS and then you need to take some action. So if Azure goes down, typically you’re going to have some monitoring software or some clustering software that’s going to detect the outage. And at that point your DR plan takes effect and that is a written set of instructions that’s part of the larger business continuity plan. So there may be some things that are happening across the business at the same time that aren’t related to your databases at all. But it’s important that everyone knows their role and that the entire plan has been tested and not just the database piece. So from a SQL Server standpoint, this is where execution matters. There’s usually a priority list of what needs to come online first, and then you walk through that list step by step. Whenever possible you want those steps to be automated so that you’re not relying on someone trying to remember what to do. Typically under a lot of pressure. The exact process is really going to depend on the solution that you’ve enacted. But generally it comes down to bringing the replicated storage online, starting SQL Server and then updating the connectivity so that the applications and users are redirected to this new environment. If it’s designed properly, that process should be predictable and relatively fast. That comes down to automation, documentation and testing. The untested DR plan really isn’t a DR plan at all. So test, test and test again. Yeah, so the key in that sense is failover cluster instances. Often when we think about multi site SQL Server always on availability groups comes into mind. That’s a solution that can replicate data synchronously, asynchronously. Great solution within a single cloud, especially the same region, things are pretty straightforward. Now, failover cluster instances normally requires some sort of shared storage device. And when you’re talking a single cloud provider, single region, you have options. There’s hosted solutions like FSX or Azure File Shares, but in a multi cloud environment you can’t use those solutions. So instead you need to adopt a stateless approach where the data is replicated at the block level using something like SIOS DataKeeper. Client connectivity also becomes a big factor. You need a solid plan for redirecting applications and users to the active node after a failover that usually involves a DNS update. Load balancers Microsoft introduced this new thing called dynamic network names which can be a big benefit in a multi cloud environment if you configure that properly. But on top of that you need to think about security and the routing between the cloud providers. So it’s definitely doable, but it takes a bit of planning and some expertise to get it right.

Swapnil Bhartiya: And how do you balance recovery time objectives and recovery point objectives when data has to replicate between different cloud providers?

Dave Bermingham: It comes down to trade offs. So if you want zero data loss you need synchronous replication. The problem is that usually you can’t do synchronous replication across clouds because of the latency. So what most organizations end up doing is using synchronous replication locally for high availability, maybe between availability zones in the same region, and then asynchronous replication across clouds for disaster recovery. So that means your recovery point objective in a multi cloud scenario might be seconds or minutes depending on the workload. And your recovery time objective is going to depend heavily on how you automate your failover process. The key is to align those trade offs with the business, not just what’s technically possible. So in some cases hourly or even daily snapshots are perfectly fine. In other scenarios where every second counts, you need to minimize potential data loss as much as possible. You’re not going to have a one size fits all solution. Many organizations end up implementing different strategies based on the requirements of each application.

Swapnil Bhartiya: What are some of the common mistakes organizations make when they first try to implement multi Cloud SQL Server HADR?

Dave Bermingham: There are a few common mistakes I see when organizations start going down the multi cloud path. The biggest one is underestimating the complexity. It sounds great on paper, but now you’re dealing with multiple cloud providers, multiple tool sets, a different way of doing things, and if your team isn’t comfortable across all those platforms, things can get messy pretty quickly. Security is another big one. Each cloud has its own model for identity, access and security controls. So if you’re not careful you end up with inconsistent policies. And that’s where gaps start to show up. Cost is something people often overlook too, especially the egress data cost. So moving data between cloud providers isn’t free. And those charges can add up fast if you’re not paying attention. I also see people trying hard to avoid vendor lock in by using only the most basic services across each cloud. The problem is you end up leaving a lot of value on the table by not taking advantage of what each platform does well. And then there’s visibility. If you don’t have a good way to monitor and manage everything across environments, you’re basically flying blind. And that can lead to performance issues, security risk, and higher cost. So multi cloud can absolutely work, but you need the right skills, the right tools, and a consistent approach to security and operations to make it successful.

Swapnil Bhartiya: Thank you so much for joining me and walking us through these practical scenarios ahead of Day of Data. I hope you will have a lot of fun at the event and I look forward to chat with you again. Thank you.

Dave Bermingham: I look forward to it. Thanks.