Skip to content

Commit 51c8435

Browse files
kuthialakuthiala
committed
add disaster recovery guidance for NGINXaaS for Azure deployments
1 parent 97aea9f commit 51c8435

File tree

1 file changed

+227
-0
lines changed

1 file changed

+227
-0
lines changed

‎content/nginxaas-azure/quickstart/disaster-recovery.md

Lines changed: 227 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,227 @@
1+
---
2+
title: Disaster recovery
3+
weight: 800
4+
toc: true
5+
url: /nginxaas/azure/quickstart/disaster-recovery/
6+
type:
7+
- how-to
8+
---
9+
10+
11+
This guide describes how to configure disaster recovery (DR) for F5 NGINX as a Service for Azure deployments in separate Azure regions, ensuring upstream access remains available even if a region fails. The deployment architecture ensures users can access backend application servers (upstreams) continuously from an alternative region if the primary region becomes unavailable. The solution leverages Terraform, Azure Virtual Network (VNet) peering, and unique subnets to support failover.
12+
13+
---
14+
15+
**Architecture Overview**
16+
17+
```
18+
+-------------------+ +-------------------+
19+
| Region 1 | | Region 2 |
20+
| VNet1 | | VNet2 |
21+
| +-------------+ | Peered | +-------------+ |
22+
| | Subnet A1 | |<------->| | Subnet B | |
23+
| | NGINXaaS #1 | | | | NGINXaaS #2 | |
24+
| +-------------+ | | +-------------+ |
25+
| | Subnet A2 | | | |
26+
| | Upstreams | | | |
27+
| +-------------+ | | |
28+
+-------------------+ +-------------------+
29+
```
30+
31+
- Each region has its own VNet, subnet, and NGINXaaS for Azure deployment.
32+
- VNet peering enables cross-region connectivity.
33+
- Upstreams (for example, VMs) are accessible from either NGINX deployment.
34+
35+
---
36+
37+
## Prerequisites
38+
39+
- Two Azure regions selected for DR.
40+
- Unique, non-overlapping VNet and subnet address spaces for each region.
41+
- Terraform 1.3+ and AzureRM provider 4.23+.
42+
43+
> **Note**: Each NGINX deployment **must run on separate subnets and non-overlapping address spaces**. This is critical for [Virtual Network (VNet) peering](https://learn.microsoft.com/en-us/azure/virtual-network/how-to-configure-subnet-peering) between the two regions. For example:
44+
>
45+
> - Region 1 (Virtual Network - 1 Address Space): `10.0.0.0/16`
46+
> - Region 2 (Virtual Network - 2 Address Space): `10.1.0.0/16`
47+
48+
---
49+
50+
## Configure disaster recovery
51+
52+
### Step 1: Deploy prerequisite infrastructure
53+
54+
Each region requires its own resource group, VNet, subnet, public IP, network security group, and user-assigned identity. Example allocation in the prerequisites module:
55+
56+
```hcl
57+
# Region 1
58+
resource "azurerm_virtual_network" "deployment_primary_vnet" {
59+
address_space = ["10.0.0.0/16"]
60+
# other config...
61+
}
62+
resource "azurerm_subnet" "deployment_primary_subnet" {
63+
address_prefixes = [cidrsubnet("10.0.0.0/16", 8, 0)] # results in 10.0.0.0/24
64+
}
65+
66+
# Region 2
67+
resource "azurerm_virtual_network" "deployment_secondary_vnet" {
68+
address_space = ["10.1.0.0/16"]
69+
}
70+
resource "azurerm_subnet" "deployment_secondary_subnet" {
71+
address_prefixes = [cidrsubnet("10.1.0.0/16", 8, 0)] # results in 10.1.0.0/24
72+
}
73+
```
74+
---
75+
76+
### Step 2: Deploy NGINXaaS for Azure in each region
77+
78+
```hcl
79+
resource "azurerm_nginx_deployment" "deployment_primary_nginxaas" {
80+
name = var.name_primary
81+
resource_group_name = var.resource_group_primary
82+
location = var.location_primary
83+
...
84+
network_interface {
85+
subnet_id = azurerm_subnet.deployment_primary_subnet.id
86+
}
87+
}
88+
resource "azurerm_nginx_deployment" "deployment_secondary_nginxaas" {
89+
name = var.name_secondary
90+
resource_group_name = var.resource_group_secondary
91+
location = var.location_secondary
92+
...
93+
network_interface {
94+
subnet_id = azurerm_subnet.deployment_secondary_subnet.id
95+
}
96+
}
97+
```
98+
99+
100+
---
101+
102+
### Step 3: Peer the VNets
103+
104+
```hcl
105+
resource "azurerm_virtual_network_peering" "vnet_primary_to_vnet_secondary" {
106+
name = "peering-vnet-primary-to-vnet-secondary"
107+
resource_group_name = var.resource_group_primary
108+
virtual_network_name = azurerm_virtual_network.deployment_primary_vnet.name
109+
remote_virtual_network_id = azurerm_virtual_network.deployment_secondary_vnet.id
110+
}
111+
resource "azurerm_virtual_network_peering" "vnet_secondary_to_vnet_primary" {
112+
name = "peering-vnet-secondary-to-vnet-primary"
113+
resource_group_name = var.resource_group_secondary
114+
virtual_network_name = azurerm_virtual_network.deployment_secondary_vnet.name
115+
remote_virtual_network_id = azurerm_virtual_network.deployment_primary_vnet.id
116+
}
117+
```
118+
119+
120+
---
121+
122+
### Step 4: Configure upstreams
123+
124+
Deploy upstream VMs in a subnet separate from the NGINXaaS deployment subnet in the **primary region**. Example:
125+
126+
```hcl
127+
resource "azurerm_subnet" "upstreams" {
128+
name = "upstreams-subnet"
129+
resource_group_name = var.resource_group_primary
130+
virtual_network_name = azurerm_virtual_network.deployment_primary_vnet.name
131+
address_prefixes = [cidrsubnet(var.vnet_addr_space, 8, 1)]
132+
}
133+
```
134+
135+
136+
---
137+
138+
## Step 5: NGINX Configuration for Failover
139+
140+
Configure both NGINX deployments to include upstreams from the primary regions in their load balancing configuration. Example `nginx.conf` snippet:
141+
142+
```nginx
143+
upstream backend {
144+
server <vm1-private-ip>:80;
145+
server <vm2-private-ip>:80;
146+
}
147+
```
148+
149+
- Use private IPs reachable via VNet peering.
150+
- Health checks can be configured to detect regional failures and reroute traffic.
151+
152+
---
153+
154+
### Step 6: DNS and failover
155+
156+
- Use Azure Traffic Manager or an external DNS solution to direct traffic to the healthy NGINX deployment.
157+
- In case of a regional outage, update DNS record to point to the public IP of the NGINXaas deployment in the secondary region.
158+
159+
---
160+
161+
## Workarounds for Subnet Peering Caveats
162+
163+
- **Subnet Peering for Overlapping VNets:**
164+
If overlapping address spaces are unavoidable, use subnet-level peering to selectively peer only the required subnets.
165+
166+
```shell
167+
az network vnet peering create \
168+
--name vnet1-to-vnet2 \
169+
--resource-group <rg1> \
170+
--vnet-name <vnet1> \
171+
--remote-vnet <vnet2-id> \
172+
--allow-vnet-access \
173+
--peer-complete-vnet false \
174+
--local-subnet-names <subnet1> \
175+
--remote-subnet-names <subnet2>
176+
```
177+
178+
179+
---
180+
181+
## Failover Process
182+
183+
1. **Monitor**: Continuously monitor NGINXaaS deployment health in both regions.
184+
1. **Failover**: If a region fails, update DNS or Traffic Manager to route traffic to the surviving region's NGINXaaS deployment.
185+
1. **Recovery**: Restore the failed region and verify peering and upstream connectivity before re-enabling traffic.
186+
187+
---
188+
189+
## Diagram
190+
191+
```mermaid
192+
flowchart LR
193+
194+
subgraph Region1[Region 1]
195+
direction TB
196+
NGINX1[NGINXaaS Deployment 1]
197+
VM1["Upstreams (VMs)"]
198+
end
199+
200+
subgraph Region2[Region 2]
201+
direction TB
202+
NGINX2[NGINXaaS Deployment 2]
203+
end
204+
205+
Users["웃 Users/Clients<br/>&#40;using DNS/traffic manager&#41;"]
206+
207+
Region2 <-->|Peering| Region1
208+
NGINX1 --> Users
209+
NGINX2 --> Users
210+
211+
%% Styling
212+
style Region1 fill:#9bb1de,stroke:#4a90e2,stroke-width:2px
213+
style Region2 fill:#9bb1de,stroke:#4a90e2,stroke-width:2px
214+
style NGINX1 fill:#d9fade,stroke:#2e7d32,stroke-width:2px,color:#000
215+
style NGINX2 fill:#d9fade,stroke:#2e7d32,stroke-width:2px,color:#000
216+
style VM1 fill:#e8f3fe,stroke:#3075ff,stroke-width:2px,color:#000
217+
style Users fill:#faefd9,stroke:orange,color:orange,stroke-width:2px
218+
219+
accDescr: Diagram showing Region 1 on the left and Region 2 on the right. Region 1 contains "NGINXaaS Deployment 1" and "Upstreams (VMs)". Region 2 contains "NGINXaaS Deployment 2". A directional arrow labeled "Peering" points from Region 1 to Region 2. Both NGINXaaS deployments have arrows pointing to a box labeled "Users/Clients (using DNS/traffic manager)", indicating user traffic flows from both regions.
220+
```
221+
222+
223+
---
224+
225+
## Summary
226+
227+
By deploying NGINXaaS in separate regions with unique subnets and peered VNets, and configuring upstreams and DNS for failover, this topology ensures high availability and DR for your applications. Use subnet peering if address spaces overlap. Lastly, always monitor and test your failover paths.

0 commit comments

Comments
 (0)