Resiliency by design: Azure compute

0:00 (upbeat music)- Welcome to the Core IaaS Resiliency Series.

0:17 My name is Hilary Wang, and I'm a Product Manager at Microsoft.

0:20 Today, we'll be diving into how your Azure compute workloads

0:23 can be engineered for resiliency in the modern cloud era.

0:27 We'll explore the principles,

0:28 features and best practices that keep your critical workloads running,

0:32 while also equipping you with the capabilities to mitigate

0:35 impact and recover quickly in the event of a failure.

0:39 In the world where digital services are the backbone of business,

0:42 downtime isn't just inconvenient,

0:44 it's costly, and at worst, it can erode trust and customer confidence.

0:49 Azure's approach to reliability is about building resiliency into every

0:53 layer so that your infrastructure and applications remain available,

0:57 performant and secure, even in the face of hardware faults,

1:01 maintenance events or unexpected demand.

1:04 Let's start with the fundamentals.

1:05 When we talk about compute resiliency in Azure,

1:08 it's important to understand that maintaining high

1:11 availability resilient workloads is a shared responsibility.

1:14 Think of it like a partnership.

1:16 Azure's responsibility is to provide a rock solid foundation.

1:20 We manage the physical data centers and servers

1:23 to ensure that the platform itself is reliable and secure.

1:27 Your responsibility is to use the building blocks

1:30 we provide to architect your application to withstand failure.

1:34 Even the most reliable platform cannot prevent downtime if an application

1:38 is only deployed to a single virtual machine in one location.

1:43 To help you build that architecture, we encourage you to consider the following

1:47 key principles when designing your workloads.

1:50 The first is redundancy.

1:52 This means eliminating single points of failure.

1:55 In Azure, we allow you to distribute

1:58 your workloads across multiple fault domains and availability zones.

2:02 If one component fails, there are other virtual machines ready to take over.

2:08 Second is isolation.

2:09 We use constructs like fault domains and availability zones to ensure

2:14 that failures or maintenance events are contained within a specific segment.

2:18 This physical separation ensures that an issue in one

2:22 area doesn't cascade to impact your entire workload.

2:26 Third is observability and recovery.

2:29 Resiliency requires the ability to detect issues

2:32 the moment they happen and act immediately.

2:35 By monitoring the health of your application

2:37 and connecting these signals to the platform, you can enable automated recovery,

2:42 whether that's restarting a stuck instance or recreating

2:45 an unhealthy VM in a different availability zone.

2:49 These principles, redundancy, scalability, observability and recovery,

2:54 are embedded into Azure's core services.

2:57 Understanding them is the first step to leveraging the platform effectively.

3:03 Now, let's take a look at the physical building

3:05 blocks Azure uses to isolate failures and protect your workloads.

3:10 At the base level, we have fault domains.

3:12 Simply put, a fault domain is a group of hardware

3:16 that shares a common power source and network switch.

3:19 You can think of this as a single server rack.

3:22 If a power supply fails or a network switch goes offline,

3:25 it typically only affects that one fault domain.

3:29 By spreading your virtual machines across multiple fault domains,

3:32 you ensure that a hardware failure in one

3:35 rack doesn't take down your entire application.

3:38 One level up, we have availability zones.

3:42 An availability zone is a group of one or more

3:45 physical data centers clustered together and equipped with independent power,

3:49 cooling and networking.

3:52 Availability zones within a single region

3:54 are typically separated by several kilometers,

3:57 but usually stay within a 100 kilometer range.

4:01 This allows for low latency communication across zones,

4:04 while still providing enough physical separation to ensure that a local event,

4:09 like a fire, flood or power outage, is unlikely to affect more than one zone.

4:14 Finally, we have Azure regions.

4:17 A region is a set of data centers located within a specific metropolitan area.

4:22 Every Azure region that supports availability zones

4:25 will feature at least three separate zones.

4:28 This structure design ensures that within the single region,

4:31 you will always have sufficient infrastructure redundancy

4:34 to distribute your workloads and run high availability applications.

4:39 So, how do you put these building blocks to work?

4:42 When it comes to compute workloads, there are three main deployment strategies.

4:46 Choosing the right one depends entirely

4:49 on your workload's specific resiliency goals and capacity requirements.

4:54 Strategy one is a regional deployment.

4:56 With this approach, Azure can place your VMs anywhere within the region,

5:00 giving you access to the widest pool of available capacity.

5:04 This flexibility maximizes your deployment success rate.

5:08 For Virtual Machine Scale Sets,

5:10 you also get protection against rack level failures as Azure

5:14 spreads your VMs across multiple fault domains within the region.

5:18 However, the main trade off in the regional deployment is that your compute

5:22 and storage components are not guaranteed to be placed within the same zone.

5:26 For example, with the regional VM,

5:29 your compute may be provisioned in Zone 1 while

5:31 your OS and data disks are provisioned in Zone 2.

5:35 If either zone has an issue, your VM is impacted.

5:39 This means that regional deployments are not

5:42 guaranteed to be resilient to a zone outage.

5:45 Strategy two is a zonal deployment.

5:48 This is where you explicitly pin your virtual machine or Virtual

5:52 Machine Scale Sets to a specific zone, say Zone 1.

5:55 The benefit of zonal deployments is that your compute

5:58 and storage components are guaranteed to live within the same zone.

6:02 This eliminates cross-zone dependency risk found in regional deployments.

6:07 However, because your components are only deployed to a single zone,

6:12 you're effectively putting all your eggs in one basket.

6:15 The risk here is that if Zone 1 itself experiences an outage,

6:19 such as a natural disaster or major infrastructure failure in the data center,

6:23 your resources will be impacted.

6:26 Therefore, a single zone deployment is also not

6:29 guaranteed to be resilient to a zone outage.

6:33 Finally, strategy three is a zone-spanning deployment.

6:36 This is the gold standard for compute resiliency.

6:39 Here, you would use a Virtual Machine Scale

6:42 Set to distribute your instances across multiple availability zones,

6:46 for example, Zones 1, 2 and 3.

6:49 The benefit in a zone-spanning deployment is

6:52 that each individual VM is zonally aligned,

6:55 meaning its compute and storage components are

6:57 guaranteed to be located within the same zone,

7:00 but the VMs and your overall scale

7:02 set will be distributed across the selected zones.

7:06 This strategy maximizes your resiliency to zonal outages

7:09 to ensure that even if one zone goes offline,

7:12 the rest of your fleet remains available

7:14 to handle traffic in the remaining zones.

7:17 Now that we've covered the three deployment strategies,

7:20 let's talk about best practices, starting with single instance virtual machines.

7:25 Single instance VMs are often the first step for customers moving to the cloud,

7:29 whether it's for lift and shift migrations,

7:31 development environments, or workloads that don't require horizontal scaling.

7:36 While they don't offer the same level of built-in redundancy as scale sets,

7:41 here are several best practices you can follow to maximize your resiliency.

7:46 Whenever possible, deploy your critical VMs to a specific availability zone.

7:52 This ensures that your VM, its disks and associated networking resources

7:56 are all co-located within the single zone,

7:59 eliminating cross-zone dependencies and improving

8:02 both resiliency and performance.

8:04 If your application is truly mission critical, don't rely on a single VM.

8:10 Deploy redundant instances across multiple availability

8:13 zones and replicate your data appropriately.

8:16 This way, if one zone experiences an outage,

8:19 you can have a standby ready in another.

8:22 And if you have existing regional VMs that you'd like to make zonal,

8:26 Azure provides tools to help.

8:28 Azure Resource Mover can migrate single

8:31 instance regional VMs into zonal configurations,

8:34 giving you improved resiliency without having to rebuild from scratch.

8:39 Beyond deployment strategies,

8:40 it's important to understand that stateless and stateful

8:43 workloads require fundamentally different approaches to resiliency.

8:48 The right design depends on your cost considerations,

8:51 how much blast radius protection you need, and your recovery objectives.

8:56 For stateless workloads,

8:57 resiliency focuses on minimizing downtime rather than preserving data.

9:03 Regional protection can be achieved through active-active or active-passive

9:08 deployments using virtual machines or scale sets with auto-heal capabilities.

9:13 If you need coverage across two regions, such as East US and West Europe,

9:18 you must deploy separate instances in each region and use

9:22 Azure Global Load Balancer or Traffic Manager for routing.

9:26 For zonal protection, Azure provides built-in capability through Virtual Machine

9:31 Scale Sets to span multiple zones seamlessly.

9:35 You can also achieve similar protection

9:37 by deploying individual VMs across different zones,

9:40 though, you'll need to manage each instance separately.

9:43 For stateful workloads,

9:45 data replication is critical to maintain integrity and minimize data loss.

9:50 For regional resiliency,

9:52 Azure Site Recovery enables failover to another region with a recovery

9:57 time of minutes and the recovery point of seconds.

10:00 At the zonal level, zone-redundant storage disks offers

10:03 zero data loss and a recovery time of minutes,

10:07 ensuring your data stays protected during a failover.

10:10 Backup solutions provide an additional layer

10:12 of protection for longer term recovery scenarios.

10:16 Regardless of your architecture,

10:18 we recommend that you regularly test your recovery process.

10:22 Tools like Chaos Studio and Azure Site Recovery test failovers,

10:26 allow you to simulate failures and ensure

10:28 that your workloads are prepared to handle a real outage.

10:33 For workloads that require more than one VM,

10:35 Virtual Machine Scale Sets are the natural next step.

10:39 scale sets allow you to deploy and manage

10:41 a group of virtual machines as a single logical unit,

10:44 handling the complexity of placement and coordination across your VMs.

10:50 Let's explore some key scale set features

10:52 designed to maximize the resiliency of your workloads.

10:56 First, let's look at application health monitoring.

10:59 By default, Azure monitors the underlying hardware

11:02 and ensures that your virtual machines are running.

11:05 However, it doesn't intuitively know if the application

11:08 you're running inside that VM is responsive.

11:12 By using Application Health extension or Load Balancer health probes,

11:16 you can provide precise application level signals to the platform.

11:21 This allows the platform to perform safe updates,

11:24 rebalance capacity and trigger automated recovery,

11:27 ensuring that the platform actions are always

11:30 guided by the state of your applications.

11:33 For example, with instance repairs,

11:35 if your application reports an unhealthy status,

11:38 the scale set can automatically detect the issue,

11:41 terminate the unhealthy instance, and deploy a fresh replacement.

11:46 This allows your system to self-heal

11:48 from application level failures automatically.

11:52 Next, let's talk about automatic zone balance currently in preview.

11:57 For zone-spanning deployments,

11:59 your resiliency relies on having instances evenly distributed across zones.

12:05 However, scaling actions or capacity constraints

12:08 can sometimes leave your scale sets unbalanced,

12:10 perhaps with too many VMs in Zone 1 and not enough in Zones 2 and 3.

12:16 This feature actively monitors your scale set's zone distribution.

12:20 If an imbalance is detected, the scale set will automatically

12:24 redistribute instances across the selected zones,

12:27 helping your workload maintain an optimal resiliency posture.

12:32 Third is capacity.

12:34 We mentioned earlier that pinning to zones can

12:36 sometimes limit your capacity options compared to regional deployments.

12:41 To solve this, VMSS flexible orchestration offers a feature called instance mix.

12:47 This allows you to specify up to five

12:50 different VM sizes within the same scale set.

12:53 By providing a broader list of acceptable options like

12:56 specifying both AMD and Intel sizes of a VM,

13:00 you can significantly increase your deployment success rate.

13:04 Azure can deploy a mix of these sizes simultaneously within the same scale set,

13:09 allowing different VM SKUs to run side by side.

13:12 This ensures you get the compute

13:14 power you need even in constrained environments.

13:17 Finally, what if you already have a regional scale

13:20 set today and would like to become zone spanning?

13:24 You can simply update the zone's property on your existing

13:27 scale set to include a list of availability zones.

13:30 From that point on, all new instances created during a scale out will be zonal.

13:36 This creates a natural migration path.

13:38 As your scale set expands, new zonal instances are added,

13:42 and when you scale in, we prioritize removing the regional instances first.

13:47 This allows your fleet to progressively transform from a regional

13:51 deployment to fully zone spanning all without downtime.

13:56 Now, let's see these features in action.

13:59 Here, we're creating a new Virtual Machine Scale Set in the Azure Portal.

14:04 Notice that we have selected three zones to create a zone-spanning scale set,

14:08 and we are selecting multiple VM sizes through instance mix.

14:12 We'll also be enabling automatic zone

14:15 balance to keep our instances evenly distributed.

14:19 Once deployed, we can see that our scale set has nine instances.

14:23 They're currently balanced with three VMs each in Zones 1, 2 and 3.

14:28 Now, let's simulate an imbalance.

14:31 We'll manually delete all three instances in Zone 3.

14:34 This leaves us now with an uneven distribution of three VMs in Zone 1,

14:39 three VMs in Zone 2 and zero VMs in Zone 3.

14:43 We'll step away for a moment and let the platform work in the background.

14:47 Keep in mind that automatic zone balance is designed

14:50 to gradually your scale set to a more resilient state.

14:54 Only one VM is moved at a time

14:57 with back-off periods to minimize churn on your workload.

15:01 Now, we're back.

15:02 Let's take a look at Activity log to see what happened.

15:06 We can see that automatic zone balance detected

15:08 the zonal imbalance and triggered two rebalancing operations.

15:13 By clicking into the operation,

15:15 we can see the new VM that was created and the original VM that was removed.

15:20 With the two operations,

15:22 automatic zone balance removed one instance each from Zone

15:25 1 and Zone 2 and recreated them in Zone 3.

15:30 Here, we can see that our scale set is now balanced with two instances per zone.

15:35 Without any manual intervention,

15:37 the platform was able to automatically detect and restore

15:40 the scale set back to a zone-resilient posture.

15:44 In today's session, we cover the foundational

15:47 building blocks of fault domains and availability zones,

15:50 the core deployment strategies, and active resiliency features of Azure compute.

15:56 To summarize, here is the core framework

15:58 for building resilient compute workloads on Azure.

16:02 First, prioritize isolation.

16:05 Whenever possible, use zone-spanning deployments to physically distribute

16:09 your instances across availability zones for maximum protection.

16:14 If zone-spanning deployments are not possible for your workloads,

16:17 ensure that you are distributed across three

16:20 or five fault domains to maximize rack level isolation.

16:25 Second, for any workloads running more than one virtual machine,

16:29 consider using Virtual Machine Scale Sets to simplify your orchestration.

16:34 This unlocks automated distribution,

16:36 capacity management and batch operations at no additional cost.

16:41 Third, enable active resiliency capabilities.

16:45 Use features like application health monitoring, instance repairs, instance mix,

16:50 and automatic zone balance to monitor,

16:53 repair and balance your fleet automatically.

16:57 And finally, if you are running on regional deployments today,

17:00 consider migration paths like using the zones parameter to progressively

17:04 transform your fleet to a zone-spanning architecture without downtime.

17:10 Resiliency by design means building reliability

17:13 into every layer of your compute architecture.

17:16 By leveraging Azure's built-in features,

17:18 best practices and automation, you can deliver uninterrupted service,

17:23 innovate confidently, and meet the demands of the AI era.

17:27 Thank you for joining this session.

17:29 (upbeat music)