Synextra Ltd.’s Post

Transcript

Jaw isn't resilient by default. It's a powerful platform, but some of the features in Azure require additional configuration to be fully resilient. Today, I'll show you a few tips to ensure your Azure environment can handle the unexpected. We all know how important uptime is known like sausages, and no business can afford them. But here's the truth, Azure doesn't guarantee resilience on its own. It gives you the tools such as Availability Zones, Groups, backups, Azure Site Recovery, but it's up to you to piece them together. In this video, I'll take you over a few of these. If you don't know how to configure in your environment correctly, your cloud platform could just be as vulnerable to failures or. Disaster as your on premise, environment as your resilience can cover multiple topics. For this video, we're going to discuss resilience in your virtual machine workload. It comes down to three core principles got redundancy, high availability and disaster recovery. So let's get started on redundancy. It's about ensuring if a resource fails, another one is there to take its place. If we start off with the most basic level of redundancy for Azure Virtual Machine, Microsoft offers availability sets. For this to work, you've require two or more machines running the same workload. When these servers have been built, they've been placed in the same availability set. So what this means each machine won't be placed into the same cabinet, so this ensures it's not using the same power, cooling or networking going to each one. This has been an issue, for instance, in this rack. Which to lose power to this rock That would ensure that DCT wouldn't be affected because that's running a separate rack. In the back end, that machine would then be moved, so that could be moved to 1/3 rack. But the key here is. The server would never be running into the same rack as your other server availability set. So that's protecting you from power failure and individual rack, a cooling failure or even a Microsoft update failure. So a Microsoft obviously need to update their racks. It could be replacing faulty hardware, replacing updates. So it means these servers would be in a different update group, meaning each rack won't be having maintenance done at the same time. So the key thing to remember, this solution, it only works for workloads. We've got 2. Identical service providing the same service, but this will give you a 99.95 SLA on the virtual machine compared to a 99.9% on a standard virtual machine. OK, so next we're going to cover availability zones. Microsoft provides regions across globe. So for this example put UK S is our region. So within here UK South it's built up of multiple data centers. These data centers are revert to availability zones. We've got availability zone 1, availability zone 2 availability zone. 3 So these represent separate data centers which are connected to each other via high performance network and all have separate cooling, power and networking interestingly. So the availability zones are labeled up in the Azure portal 1-2 and three. But for each customer within Azure there'll be different. So if I was building a machine in zone one in UK S, it wouldn't necessarily be the same zone one for you and yours. This has stopped the data centers being overloaded. So when you build your virtual machines, you can choose which availability zones place them in. So for example, build virtual machine domain controller. So call that DC1. When building it, we could select, we just want it in availability zone one, but we could also put a copy in a Z2. So this would mean if we lost this data center, then the virtual machine could then start running within a Z. So this is great for redundancy. Anything I would say is there's additional costs there. You've got to pay for the virtual machine and the storage that's running in your next availability. So if you did select multiple availability zones would incur a cost for the machine each data center. This is a powerful tool, but you need to also ensure that your services are either configured as zone redundant or zonal and be aware of the cost involved. Zoner would need resources to be pinned to a specific region and your customers are responsible for managing the data replication distribution across zones. So this would mean if an outage occurred in a single availability zone, you'll be responsible for failing to another region. While zone redundant resources are spread across multiple availability zones, Microsoft managers the spread and requests so for instance like a global. Service Microsoft would offer the variability for this. They would automatically fail between regions if it was something you were doing on your own, for instance, a virtual machine that wasn't HA, you need to manage it yourself. So we've just discussed availability zones which will allow you to have an offline copy of the virtual machine. So the next step for this, we're in virtual machines load balance between multiple regions, making the service active, active. This would have an increased costs because we need to run things like load balancers, et cetera between data centers, but it will give you more flexibility. So we've got UK South and we've got UK West. So in this example, we're going to say we've got 2 web servers. So we've got web one and Web 02 in UK W between them. We can load balance these with Azure Front Door. It's a global service. We're going to put it in the middle there. So we've got 2 web servers which are then lower bounds via Azure Front Door. So for this example, for instance, we need to some patching or anything like that, we could say Web 1 offline. So in Azure Front Door we'd have a health probe which then stopped traffic going to Web one and all your traffic will be directed to Web O2. You can carry out your work on Web 01. All users will be directed to Web 02. There be no disruption. Once you've finished, the machine could then be brought back online, allowing your staff to continue working. And then again, once that one's back online, we could then take Webo 2 off and carry out the same work on that. So really that's giving the users high availability of the application and allowing your businesses not to have any downtime. So when all else fails, you need a plan to restore environment quickly with minimal disruption. For this, we've got Azure Site Recovery and backup services, which are essential products. So first of all on this. If we discuss what jobs are, recovery does OK. So we've got UK South and UK West. So in our primary region we've got Web 01. So this is a web server, so this time. We haven't got any replication of this machine. We don't have a low balanced version. So we've got nothing running Yukos for that. What we can do for this is can use something called Azure site Recovery. So what ASR does? This runs a constant replication from one region to another region. So we've got Weber one here. This would be replicating over to the UK W into a recovery vault. Obviously it's running over Microsoft back end network, so we can get an RTO as low as 30 seconds. And what we can say is we can say this machine can be stored for X number of days. So here we've got a recovery vault that's sitting in the UK. Request this will hold 14 days worth of recovery points for this virtual machine. So if something was to happen GK self and we lost the entire region, so this is all the zones data center, everything's down, we could then ASR we could then bring the server up in UK W would have web one that would be running UK South. And the state sensible online. So it kind of gives you a full Dr. solution. It's a failover to another data center. I think the main thing is to be careful for here is obviously your subnets address spaces. They don't failover. So you need to have a separate address space. So any servers, firewall rules, etc. When working in production, you need to make sure your disaster recovery environment is kept up to date with the latest IP's. Any firewall rules to ensure when that machines failed over it will continue to work. And we always say it's fantastic having a disaster recovery situation. Solution like this, it's making sure you actually test the plan to make sure it's gonna work. And Microsoft offers a few things facilitate this, what we can do so we could have Web 01 that could be running day-to-day. We've got users on there. What we can do, we can actually complete a test failover, get rid of this. So we've got Web 01 test. So this would then fail the machine over into a test network. It's going to put it into an isolated network, and this network doesn't have any communication back to your live network. So this means you can boot up the machine, ensure it powers on, and even allow users to log on and test while your production workload is carried on as normal. And this one's isolated. And obviously you Finder one in a live disaster recovery situation, you'd fail this over to a live Vnet, and this Vnet would then be able to communicate how hopefully done any firewall rules. Things will continue to function. Once UK S came back online, you could then look at moving the machines back. So would reverse replicate the machines back this way coming from store the region to how it was before the incident. So kind of your final line of defense, this is your backup. So for this example, we've got UK S, which is again, that's our primary and this is our secondary data center. So then there we've got our recovery vault. So these are two virtual machines. So for these, we're backing up these virtual machines into this vault. So that backup occurs, for instance, every four hours. This backup and then got another copy another data sensor. So this covers you if UK S was to go down, it's still be able to restore your virtual machines from a backup then another vault. So as mentioned, we've got the vault. This is backing up the virtual machines. So this would cover you against if a machine became corrupt or maybe had a virus or it just needed rolling back. We could then restore the virtual machine from the vault. This can be restored to a new virtual machine, but it could overwrite the existing virtual machine backup can also be used to. Restore file level. So for instance, if something was to happen to a user's file, then we could mount a recovery point from this fault. So what it does it mount all the disks from Web 01. So if we've got another server, a management box here, we then mount the disks onto this server, we grab the file we need and we can then copy the file back to Web 1. So this is a really great solution to ensure your files are backed up. One key thing to note is when creating a vault, you should always enable immutability on a vault. So what this does this? Stops any backups being removed before the retention period is up. So for instance, if your tendency was compromised and so on and managed to get into your storage account and they tried to delete this from the vault, the vault 1 allow it to be deleted. If we add a one year retention on the vault, nothing could be deleted before that retention period is finished. You delete the virtual machine, the backup is still staying there. So if something more serious just happens to virtual machine, so if it became corrupt, a failed installation that happened on it and you needed to restore it back, we would go into the backup center. We would get a recovery point from within the vault. Would restore that back to a new machine. Without building resilience, you'll be setting yourself up for trouble. Here are some of the common pitfalls I see in Azure setups that lack resilience. So first, we've got manual processes. So the amount of times that we see people who are maybe adding backup policies manually to servers and there's always human error, people miss them, they put them into the wrong retention policy. Backup policies are incorrect on there. So what we would suggest on here would be looking at something like Azure policies so we can ensure each server is being backed up correctly at the right policy on it or even alerts the correct team that server is not being backed up. Next, we've got single point of failures. If your architecture as a single point of failure, it's a risk waiting to happen. Redundancy is the key. Making sure a failure in one part of your system doesn't affect your whole system. Test and Dr. this is vital. You could have all the tools, the backup policies, Azure site recovery running, but if it's not been tested, the time it's going to be tested, it's going to be a stressful situation. So it's best to get this tested on a regular basis, ensuring your machines function, you've got the correct firewalls rules in place, NSG rules to ensure everything will go smoothly. So let's put this all together. Resilient Azure setup looks like this. Redundancy at every level, high variability built into your design, disaster recovery that's fully automated and tested. By designing for resilience from the ground up, you're enjoying environment will prepare for anything from small hiccups to full scale failure. Azure isn't resilient by default, but by understanding the tools available and building redundancy, high availability and disaster recovery in mind, you can make sure your environment is rock solid. Thanks for watching and as always, make sure you always plan for the what if moment.