You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/reliability/reliability-health-data-services-deidentification.md
+25-25Lines changed: 25 additions & 25 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -20,23 +20,21 @@ This article describes reliability support in the de-identification service (pre
20
20
[!INCLUDE [introduction to disaster recovery](includes/reliability-disaster-recovery-description-include.md)]
21
21
22
22
Each de-identification service (preview) is deployed to a single Azure region. In the event of a region-wide degredation or outage:
23
-
- ARM control plane functionality will be limited to read-only for the duration of the outage. Your service metadata (such as resource properties) will be backed up outside of the region by Microsoft. Once the outage is over, you can read and write to the control plane.
24
-
- All data plane requests will fail for the duration of the outage, such as de-identification or job API requests. No customer data will be lost, but there is the potential for job progress metadata to be lost. Once the outage is over, you can read and write to the data plane.
23
+
- ARM control plane functionality is limited to read-only during the outage. Your service metadata (such as resource properties) is always backed up outside of the region by Microsoft. Once the outage is over, you can read and write to the control plane.
24
+
- All data plane requests fail during the outage, such as de-identification or job API requests. No customer data is lost, but there is the potential for job progress metadata to be lost. Once the outage is over, you can read and write to the data plane.
25
25
26
26
### Disaster recovery tutorial
27
-
You can assure high availability of your workloads even during a region-wide outage or degradation by deploying two or more de-identification services in an active-active configuration.
28
-
In active-active disaster recovery architecture, de-identification services are deployed in two separate regions and Azure Front door is used to route traffic to both regions.
27
+
If an entire Azure region is not available, you can still assure high availability of your workloads. You can deploy two or more de-identification services in an active-active configuration, with Azure Front door used to route traffic to both regions.
29
28
30
29
With this example architecture:
31
30
32
31
- Identical de-identification services are deployed in two separate regions.
33
32
- Azure Front Door is used to route traffic to both regions.
34
-
- During a disaster, one region becomes offline, and Azure Front Door routes traffic exclusively to the other region. The recovery time objective during such a geo-failover is near-zero.
35
-
- Your application should be able to re-run jobs that were last observed as running but cannot be found. This ensures that the recovery point objective is limited to the job progress that is not available.
33
+
- During a disaster, one region becomes offline, and Azure Front Door routes traffic exclusively to the other region. The recovery time objective during such a geo-failover is limited to the time Azure Front Door takes to detect that one service is unhealthy.
36
34
37
35
#### RTO and RPO
38
36
39
-
If you adopt the active-active configuration described above, you should expect a recovery time objective (RTO) of **5 minutes**. In any configuration, you should expect a recovery point objective (RPO) of **0 minutes** (no customer data will be lost).
37
+
If you adopt the active-active configuration, you should expect a recovery time objective (RTO) of **5 minutes**. In any configuration, you should expect a recovery point objective (RPO) of **0 minutes** (no customer data will be lost).
40
38
41
39
### Validate disaster recovery plan
42
40
#### Prerequisites
@@ -49,7 +47,7 @@ To complete this tutorial:
49
47
50
48
#### Create a resource group
51
49
52
-
You need two instances of a de-identification service (preview) in different Azure regions for this tutorial. The tutorial will use the [region pair](../availability-zones/cross-region-replication-azure.md#azure-paired-regions) East US/West US as your two regions, but feel free to choose your own regions.
50
+
You need two instances of a de-identification service (preview) in different Azure regions for this tutorial. The tutorial uses the [region pair](../availability-zones/cross-region-replication-azure.md#azure-paired-regions) East US/West US as your two regions, but feel free to choose your own regions.
53
51
54
52
To make management and clean-up simpler, you use a single resource group for all resources in this tutorial. Consider using separate resource groups for each region/resource to further isolate your resources in a disaster recovery situation.
Run [`az afd origin-group create`](/cli/azure/afd/origin-group#az-afd-origin-group-create) to create an origin group that contains your two web apps.
106
+
Run [`az afd origin-group create`](/cli/azure/afd/origin-group#az-afd-origin-group-create) to create an origin group that contains your two de-identification services.
|`origin-group-name`|`myorigingroup`|Name of the origin group. |
117
115
|`probe-request-type`|`GET`|The type of health probe request that is made. |
118
-
|`probe-protocol`|`Http`|Protocol to use for health probe. |
116
+
|`probe-protocol`|`Https`|Protocol to use for health probe. |
119
117
|`probe-interval-in-seconds`|`60`|The number of seconds between health probes. |
120
-
|`probe-path`|`/`|The path relative to the origin that is used to determine the health of the origin. |
118
+
|`probe-path`|`/health`|The path relative to the origin that is used to determine the health of the origin. |
121
119
|`sample-size`|`4`|The number of samples to consider for load balancing decisions. |
122
120
|`successful-samples-required`|`3`|The number of samples within the sample period that must succeed. |
123
121
|`additional-latency-in-milliseconds`|`50`|The extra latency in milliseconds for probes to fall into the lowest latency bucket. |
122
+
|`enable-health-probe`|| Switch to control the status of the health probe. |
124
123
125
-
### Add an origin to the group
124
+
### Add origins to the group
126
125
127
-
Run [`az afd origin create`](/cli/azure/afd/origin#az-afd-origin-create) to add an origin to your origin group. For the `--host-name`parameter, replace the placeholder for`<web-app-east-us>` with your app name in that region. Notice the `--priority` parameter is set to `1`, which indicates all traffic is sent to your primary app.
126
+
Run [`az afd origin create`](/cli/azure/afd/origin#az-afd-origin-create) to add an origin to your origin group. For the `--host-name`and `--origin-host-header` parameters, replace the placeholder value`<service-url-east-us>` with your East US service URL, leaving out the scheme (`https://`). You should have a value like `abcdefghijk.api.eastus.deid.azure.com`.
|`host-name`|`<service-url-east-us>`|The hostname of the primary de-identification service. |
136
-
|`origin-name`|`primarydeid`|Name of the origin. |
137
-
|`origin-host-header`|`<service-url-east-us>`|The host header to send for requests to this origin. If you leave this blank, the request hostname determines this value. Azure CDN origins, such as Web Apps, Blob Storage, and Cloud Services require this host header value to match the origin hostname by default. |
135
+
|`origin-name`|`deid1`|Name of the origin. |
136
+
|`origin-host-header`|`<service-url-east-us>`|The host header to send for requests to this origin. |
138
137
|`priority`|`1`|Set this parameter to 1 to direct all traffic to the primary de-identification service. |
139
138
|`weight`|`1000`|Weight of the origin in given origin group for load balancing. Must be between 1 and 1000. |
140
139
|`enabled-state`|`Enabled`|Whether to enable this origin. |
141
140
|`https-port`|`443`|The port used for HTTPS requests to the origin. |
142
141
143
-
Repeat this step to add your second origin. Pay attention to the `--priority` parameter. For this origin, it's set to `2`. This priority setting tells Azure Front Door to direct all traffic to the primary origin unless the primary goes down. If you set the priority for this origin to `1`, Azure Front Door treats both origins as active and direct traffic to both regions. Be sure to replace both instances of the placeholder for`<service-url-east-us>` with the service url.
144
-
142
+
Repeat this step to add your second origin. For the `--host-name` and `--origin-host-header` parameters, replace the placeholder value`<service-url-west-us>` with your West US service URL, leaving out the scheme (`https://`).
Pay attention to the `--priority` parameters in both commands. Because both origins are set to priority `1`, Azure Front Door treats both origins as active and direct traffic to both regions. If the priority for one origin is set to `2`, Azure Front Door will treat that origin as secondary and will direct all traffic to the other origin unless it goes down.
149
+
149
150
#### Add a route
150
151
151
152
Run [`az afd route create`](/cli/azure/afd/route#az-afd-route-create) to map your endpoint to the origin group. This route forwards requests from the endpoint to your origin group.
|`endpoint-name`|`myendpoint`|Name of the endpoint. |
160
-
|forwarding-protocol |MatchRequest |Protocol this rule uses when forwarding traffic to backends. |
161
+
|`forwarding-protocol`|MatchRequest |Protocol this rule uses when forwarding traffic to backends. |
161
162
|`route-name`|`route`|Name of the route. |
162
-
|https-redirect |`Enabled`|Whether to automatically redirect HTTP traffic to HTTPS traffic. |
163
163
|`supported-protocols`|`Https`|List of supported protocols for this route. |
164
164
|`link-to-default-domain`|`Enabled`|Whether this route is linked to the default endpoint domain. |
165
165
@@ -169,7 +169,7 @@ Allow about 15 minutes for this step to complete as it takes some time for this
169
169
170
170
When you create the Azure Front Door Standard/Premium profile, it takes a few minutes for the configuration to be deployed globally. Once completed, you can access the frontend host you created.
171
171
172
-
Run [`az afd endpoint show`](/cli/azure/afd/endpoint#az-afd-endpoint-show) to get the hostname of the Front Door endpoint.
172
+
Run [`az afd endpoint show`](/cli/azure/afd/endpoint#az-afd-endpoint-show) to get the hostname of the Front Door endpoint. It should look like `abddefg.azurefd.net`
173
173
174
174
```azurecli-interactive
175
175
az afd endpoint show --resource-group my-deid --profile-name myfrontdoorprofile --endpoint-name myendpoint --query "hostName"
@@ -190,7 +190,7 @@ To test instant global failover:
190
190
1. Refresh your browser. This time, you should see an error message.
191
191
1. Re-enable public network access for one of the de-identification services. Refresh your browser and you should see the health status again.
192
192
193
-
You've now validated that you can access your apps through Azure Front Door and that failover functions as intended. Enable public network access on the other service if you're done with failover testing.
193
+
You've now validated that you can access your services through Azure Front Door and that failover functions as intended. Enable public network access on the other service if you're done with failover testing.
194
194
195
195
#### Clean up resources
196
196
@@ -207,4 +207,4 @@ In the case of disaster, you can check the health status of your de-identificati
207
207
208
208
## Related content
209
209
210
-
-[Reliability in Azure](/azure/availability-zones/overview.md)
210
+
-[Reliability in Azure](/azure/reliability/overview)
0 commit comments