Zone-Down simulation 

Introduction:  

Zone down is a drill for Availability zones in public cloud computing. Availability Zones are massive assets for a public cloud. They build resilience and availability for applications and services. It comprises of multiple datacenters and are almost indistinguishable from one another.  A region may have three availability zones for redundancy and availability and each zone may host a variety of cloud computing resources – small or big. Since there are several stakeholders in an availability zone, it is a challenge to see what happens when one fails. Even the method to finding that information is quite drastic which involves powering down the zone. There are a lot of network connections to and from cloud resources, so it becomes hard to find an alternative. This article proposes a solution based on diversion of traffic between zones. 

Proposal:  

This is a multi-tiered approach to the problem statement. 

Step 1. The first tier is about the use of virtual network around the PaaS services from the cloud from which resources have been provisioned under a subscription. This can be done with the help of Azure Private Link which helps connect resources over an internal subnet so that we don’t have to access them publicly. Setting up this virtual network is critical to the stated goal of isolating zones which would otherwise have participated in a shared zone-redundancy. If each zone could be put in a separate virtual network and if the networks do not share anything, it can be assumed that traffic flowing to one network only will prevent the utilization of the other zones, thus simulating a network zone-down.  The internal traffic goes over the Microsoft backbone network and does not have to traverse the internet. 

The following PowerShell command describes the steps to do this: 

New-AzPrivateLinkService 

   -Name <String> 

   -ResourceGroupName <String> 

   -Location <String> 

   -LoadBalancerFrontendIpConfiguration <PSFrontendIPConfiguration[]> 

   -IpConfiguration <PSPrivateLinkServiceIpConfiguration[]> 

Which is used in the steps like this. 

$vnet = Get-AzVirtualNetwork -ResourceName 'myvnet' -ResourceGroupName 'myresourcegroup' 

$subnet = $vnet | Select-Object -ExpandProperty subnets | Where-Object Name -eq 'mysubnet' 

$IPConfig = New-AzPrivateLinkServiceIpConfig -Name 'IP-Config' -Subnet $subnet -PrivateIpAddress '10.0.0.5' 

$publicip = Get-AzPublicIpAddress -ResourceGroupName 'myresourcegroup' 

$frontend = New-AzLoadBalancerFrontendIpConfig -Name 'FrontendIpConfig01' -PublicIpAddress $publicip 

$lb = New-AzLoadBalancer -Name 'MyLoadBalancer' -ResourceGroupName 'myresourcegroup' -Location 'West US' -FrontendIpConfiguration $frontend 

New-AzPrivateLinkService -Name 'mypls' -ResourceGroupName myresourcegroup -Location "West US" -LoadBalancerFrontendIpConfiguration $frontend -IpConfiguration $IPConfig 

Step 2. The second tier is an application gateway that onboards user traffic to one of the virtual networks 

$ResourceGroup = New-AzResourceGroup -Name "ResourceGroup01" -Location "West US" -Tag @{Name = "Department"; Value = "Marketing"}  

$Subnet = New-AzVirtualNetworkSubnetConfig -Name "Subnet01" -AddressPrefix 10.0.0.0/24 

$VNet = New-AzVirtualNetwork -Name "VNet01" -ResourceGroupName "ResourceGroup01" -Location "West US" -AddressPrefix 10.0.0.0/16 -Subnet $Subnet 

$VNet = Get-AzVirtualNetwork -Name "VNet01" -ResourceGroupName "ResourceGroup01" 

$Subnet = Get-AzVirtualNetworkSubnetConfig -Name "Subnet01" -VirtualNetwork $VNet  

$GatewayIPconfig = New-AzApplicationGatewayIPConfiguration -Name "GatewayIp01" -Subnet $Subnet 

$Pool = New-AzApplicationGatewayBackendAddressPool -Name "Pool01" -BackendIPAddresses 10.10.10.1, 10.10.10.2, 10.10.10.3 

$PoolSetting = New-AzApplicationGatewayBackendHttpSettings -Name "PoolSetting01" -Port 80 -Protocol "Http" -CookieBasedAffinity "Disabled" 

$FrontEndPort = New-AzApplicationGatewayFrontendPort -Name "FrontEndPort01" -Port 80 

$PublicIp = New-AzPublicIpAddress -ResourceGroupName "ResourceGroup01" -Name "PublicIpName01" -Location "West US" -AllocationMethod "Dynamic" 

$FrontEndIpConfig = New-AzApplicationGatewayFrontendIPConfig -Name "FrontEndConfig01" -PublicIPAddress $PublicIp 

$Listener = New-AzApplicationGatewayHttpListener -Name "ListenerName01" -Protocol "Http" -FrontendIpConfiguration $FrontEndIpConfig -FrontendPort $FrontEndPort 

$Rule = New-AzApplicationGatewayRequestRoutingRule -Name "Rule01" -RuleType basic -BackendHttpSettings $PoolSetting -HttpListener $Listener -BackendAddressPool $Pool 

$Sku = New-AzApplicationGatewaySku -Name "Standard_Small" -Tier Standard -Capacity 2 

$Gateway = New-AzApplicationGateway -Name "AppGateway01" -ResourceGroupName "ResourceGroup01" -Location "West US" -BackendAddressPools $Pool -BackendHttpSettingsCollection $PoolSetting -FrontendIpConfigurations $FrontEndIpConfig  -GatewayIpConfigurations $GatewayIpConfig -FrontendPorts $FrontEndPort -HttpListeners $Listener -RequestRoutingRules $Rule -Sku $Sku 

 

An application gateway can be used with both public and private addresses.  It comprises of Frontend IP addresses, Listeners, Request routing rules, HTTP settings and backend pools.  A backend pool routes request to backend servers, which serve the request. Backend pools can contain: 

  

NICs 

Virtual machine scale sets 

Public IP addresses 

Internal IP addresses 

FQDN 

Multitenant backends (such as App Service) 

This allows an Application Gateway to communicate with instances outside of the virtual network. Application Gateway backend pool members aren't tied to an availability set. An application gateway can communicate with instances outside of the virtual network that it's in. As a result, the members of the backend pools can be across clusters, across datacenters, or outside Azure, if there's IP connectivity. 

  

With the use of internal IPs as backend pool members, virtual network peering or a VPN gateway must be used. Virtual network peering is supported and beneficial for load-balancing traffic in other virtual networks. Different backend pools for different types of requests. For example, one backend pool for private network traffic, and then another backend pool for public IP members. 

We don’t require more than one load balancer or a load balancer per availability zone.  

Step 3: the use of a traffic manager to switch between the traffic to application gateway for experiment purposes and to the default where the traffic is not diverted and reaches the public endpoints. The traffic manager is not a replacement for application gateway which is required but it facilitates cases where there is a designated public IP address destination for the undiverted traffic and the application gateway ip address for the diverted traffic.   

https://1drv.ms/u/s!Ashlm-Nw-wnWzWDDWMXCinJgxN0Q  

Conclusion: 

The use of a multi-tiered approach is needed only because the virtual network is internal, and the customer traffic is external, but diversion of traffic is a simple and elegant solution for zone-drill power statement.