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/azure-cache-for-redis/cache-event-grid-quickstart-portal.md
+5-5Lines changed: 5 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -32,18 +32,18 @@ Before subscribing to the events for the cache instance, let's create the endpoi
32
32
:::image type="content" source="media/cache-event-grid-portal/deploy-to-azure.png" alt-text="Deploy to Azure button.":::
33
33
34
34
1. On the **Custom deployment** page, do the following steps:
35
-
1. For **Resource group**, select the resource group that you created when creating the cache instance. It will be easier for you to clean up after you are done with the tutorial by deleting the resource group.
35
+
1. For **Resource group**, select the resource group that you created when creating the cache instance. It will be easier for you to clean up after you're done with the tutorial by deleting the resource group.
36
36
2. For **Site Name**, enter a name for the web app.
37
37
3. For **Hosting plan name**, enter a name for the App Service plan to use for hosting the web app.
38
38
4. Select the check box for **I agree to the terms and conditions stated above**.
|**Subscription**| Drop down and select your subscription. | The subscription under which to create this web app. |
43
+
|**Subscription**| Drop down and select your subscription. | The subscription in which you want to create this web app. |
44
44
|**Resource group**| Drop down and select a resource group, or select **Create new** and enter a new resource group name. | By putting all your app resources in one resource group, you can easily manage or delete them together. |
45
-
|**Site Name**| Enter a name for your web app. | This value cannot be empty. |
46
-
|**Hosting plan name**| Enter a name for the App Service plan to use for hosting the web app. | This value cannot be empty. |
45
+
|**Site Name**| Enter a name for your web app. | This value can't be empty. |
46
+
|**Hosting plan name**| Enter a name for the App Service plan to use for hosting the web app. | This value can't be empty. |
47
47
48
48
1. Select Alerts (bell icon) in the portal, and then select **Go to resource group**.
49
49
@@ -66,7 +66,7 @@ In this step, you'll subscribe to a topic to tell Event Grid which events you wa
66
66
67
67
1. In the portal, navigate to your cache instance that you created earlier.
68
68
1. On the **Azure Cache for Redis** page, select **Events** on the left menu.
69
-
1. Select **Web Hook**. You are sending events to your viewer app using a web hook for the endpoint.
69
+
1. Select **Web Hook**. You're sending events to your viewer app using a web hook for the endpoint.
Copy file name to clipboardExpand all lines: articles/event-grid/custom-disaster-recovery-client-side.md
+18-18Lines changed: 18 additions & 18 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -9,23 +9,23 @@ ms.custom: devx-track-csharp
9
9
10
10
# Build your own client-side disaster recovery for Azure Event Grid topics
11
11
12
-
Disaster recovery focuses on recovering from a severe loss of application functionality. This tutorial will walk you through how to set up your eventing architecture to recover if the Event Grid service becomes unhealthy in a particular region.
12
+
Disaster recovery focuses on recovering from a severe loss of application functionality. This tutorial walks you through how to set up your eventing architecture to recover if the Event Grid service becomes unhealthy in a particular region.
13
13
14
-
In this tutorial, you'll learn how to create an active-passive failover architecture for custom topics in Event Grid. You'll accomplish failover by mirroring your topics and subscriptions across two regions and then managing a failover when a topic becomes unhealthy. The architecture in this tutorial fails over all new traffic. it's important to be aware, with this setup, events already in flight won't be recovered until the compromised region is healthy again.
14
+
In this tutorial, you learn how to create an active-passive failover architecture for custom topics in Event Grid. You accomplish failover by mirroring your topics and subscriptions across two regions and then managing a failover when a topic becomes unhealthy. The architecture in this tutorial fails over all new traffic. it's important to be aware, with this setup, events already in flight won't be recovered until the compromised region is healthy again.
15
15
16
16
> [!NOTE]
17
17
> Event Grid supports automatic geo disaster recovery (GeoDR) on the server side now. You can still implement client-side disaster recovery logic if you want a greater control on the failover process. For details about automatic GeoDR, see [Server-side geo disaster recovery in Azure Event Grid](geo-disaster-recovery.md).
18
18
19
19
## Create a message endpoint
20
20
21
-
To test your failover configuration, you'll need an endpoint to receive your events at. The endpoint isn't part of your failover infrastructure, but will act as our event handler to make it easier to test.
21
+
To test your failover configuration, you need an endpoint to receive your events at. The endpoint isn't part of your failover infrastructure, but acts as our event handler to make it easier to test.
22
22
23
-
To simplify testing, deploy a [pre-built web app](https://github.com/Azure-Samples/azure-event-grid-viewer) that displays the event messages. The deployed solution includes an App Service plan, an App Service web app, and source code from GitHub.
23
+
To simplify testing, deploy a [prebuilt web app](https://github.com/Azure-Samples/azure-event-grid-viewer) that displays the event messages. The deployed solution includes an App Service plan, an App Service web app, and source code from GitHub.
24
24
25
25
1.[Deploy the solution](https://portal.azure.com/#create/Microsoft.Template/uri/https%3A%2F%2Fraw.githubusercontent.com%2FAzure-Samples%2Fazure-event-grid-viewer%2Fmaster%2Fazuredeploy.json) to your subscription. In the Azure portal, provide values for the parameters.
26
26
1. The deployment may take a few minutes to complete. After the deployment has succeeded, navigate to the resource group, select the **App Service**, and then select **URL** to navigate to your web app.
27
27
`https://<your-site-name>.azurewebsites.net`
28
-
Make sure to note this URL as you'll need it later.
28
+
Make sure to note this URL as you need it later.
29
29
1. You see the site but no events have been posted to it yet.
30
30
31
31
:::image type="content" source="./media/blob-event-quickstart-portal/view-site.png" alt-text="Screenshot showing the Event Grid Viewer sample web app.":::
@@ -35,7 +35,7 @@ Make sure to note this URL as you'll need it later.
35
35
36
36
## Create primary and secondary topics
37
37
38
-
First, create two Event Grid topics. These topics will act as primary and secondary topics. By default, your events will flow through the primary topic. If there is a service outage in the primary region, your secondary will take over.
38
+
First, create two Event Grid topics. These topics act as primary and secondary topics. By default, your events flow through the primary topic. If there's a service outage in the primary region, your secondary takes over.
39
39
40
40
1. Sign in to the [Azure portal](https://portal.azure.com).
41
41
@@ -49,31 +49,31 @@ First, create two Event Grid topics. These topics will act as primary and second
49
49
1. Select the **Azure subscription** where you want to create a topic.
50
50
1. Select an existing **Azure resource group** or create a resource group.
51
51
1. Enter a **name** for the topic. Give the topic a logical name and add "-primary" as a suffix to make it easy to track.
52
-
1. Select a **region** for the topic. This topic's region will be your primary region.
52
+
1. Select a **region** for the topic. This topic's region is your primary region.
53
53
1. Select **Review + create** at the bottom of the page.
54
54
55
55
:::image type="content" source="./media/custom-disaster-recovery/create-primary-topic.png" lightbox="./media/custom-disaster-recovery/create-primary-topic.png" alt-text="Screenshot showing the Create topic page.":::
56
56
1. On the **Review + create** page, select **Create** at the bottom of the page.
57
-
1. Once the topic has been created, select **Go to resource** to navigate to it and copy the **topic endpoint**. you'll need the URI later.
57
+
1. Once the topic has been created, select **Go to resource** to navigate to it and copy the **topic endpoint**. you need the URI later.
1. Get the access key for the topic, which you'll also need later. Click on**Access keys** in the resource menu and copy Key 1.
60
+
1. Get the access key for the topic, which you also need later. Select**Access keys** in the resource menu and copy Key 1.
61
61
62
62
:::image type="content" source="./media/custom-disaster-recovery/get-primary-access-key.png" lightbox="./media/custom-disaster-recovery/get-primary-access-key.png" alt-text="Screenshot showing the access key of a primary topic.":::
63
-
1. Switch back to the **Overview** page, and click**+Event Subscription** to create a subscription connecting your subscribing the event receiver website you made in the pre-requisites to the tutorial.
63
+
1. Switch back to the **Overview** page, and select**+Event Subscription** to create a subscription connecting your subscribing the event receiver website you made in the prerequisites to the tutorial.
64
64
65
65
:::image type="content" source="./media/custom-disaster-recovery/create-event-subscription-link.png" lightbox="./media/custom-disaster-recovery/create-event-subscription-link.png" alt-text="Screenshot showing the selection of the Create event subscription link.":::
66
66
1. On the **Create Event Subscription** page, follow these steps:
67
67
1. Give the event subscription a logical **name** and add "-primary" as a suffix to make it easy to track.
68
68
1. For **Endpoint Type**, select **Web Hook**.
69
69
70
70
:::image type="content" source="./media/custom-disaster-recovery/create-event-subscription-page.png" lightbox="./media/custom-disaster-recovery/create-event-subscription-page.png" alt-text="Screenshot showing the selection of the Create Event Subscription page.":::
71
-
1.Click**Select an endpoint**.
71
+
1.Choose**Select an endpoint**.
72
72
1. On the **Select Web Hook** page, set the endpoint to your event receiver's event URL, which should look something like: `https://<your-event-reciever>.azurewebsites.net/api/updates`, and then select **Confirm Selection**. Remember to add `/api/updates` to the URL of the web app.
73
73
74
74
:::image type="content" source="./media/custom-disaster-recovery/select-webhook.png" lightbox="./media/custom-disaster-recovery/select-webhook.png" alt-text="Screenshot showing the selection of the Select Web Hook page.":::
75
-
1. Now, back on the **Create Event Subscription** page, select **Create** at the bottom pf the page.
76
-
1. Repeat the same flow to create your secondary topic and subscription. This time, replace the "-primary" suffix with "-secondary" for easier tracking. Finally, make sure you put it in a **different Azure Region**. While you can put it anywhere you want, it's recommended that you use the [Azure Paired Regions](../availability-zones/cross-region-replication-azure.md). Putting the secondary topic and subscription in a different region ensures that your new events will flow even if the primary region goes down.
75
+
1. Now, back on the **Create Event Subscription** page, select **Create** at the bottom of the page.
76
+
1. Repeat the same flow to create your secondary topic and subscription. This time, replace the "-primary" suffix with "-secondary" for easier tracking. Finally, make sure you put it in a **different Azure Region**. While you can put it anywhere you want, it's recommended that you use the [Azure Paired Regions](../availability-zones/cross-region-replication-azure.md). Putting the secondary topic and subscription in a different region ensures that your new events flow even if the primary region goes down.
77
77
78
78
You should now have:
79
79
@@ -85,11 +85,11 @@ You should now have:
85
85
86
86
## Implement client-side failover
87
87
88
-
Now that you have a regionally redundant pair of topics and subscriptions setup, you're ready to implement client-side failover. There are several ways to accomplish it, but all failover implementations will have a common feature: if one topic is no longer healthy, traffic will redirect to the other topic.
88
+
Now that you have a regionally redundant pair of topics and subscriptions setup, you're ready to implement client-side failover. There are several ways to accomplish it, but all failover implementations have a common feature: if one topic is no longer healthy, traffic will redirect to the other topic.
89
89
90
90
### Basic client-side implementation
91
91
92
-
The following sample code is a simple .NET publisher that will always attempt to publish to your primary topic first. If it doesn't succeed, it will then fail over the secondary topic. In either case, it also checks the health api of the other topic by doing a GET on `https://<topic-name>.<topic-region>.eventgrid.azure.net/api/health`. A healthy topic should always respond with **200 OK** when a GET is made on the **/api/health** endpoint.
92
+
The following sample code is a simple .NET publisher that attempts to publish to your primary topic first. If it doesn't succeed, it fails over the secondary topic. In either case, it also checks the health api of the other topic by doing a GET on `https://<topic-name>.<topic-region>.eventgrid.azure.net/api/health`. A healthy topic should always respond with **200 OK** when a GET is made on the **/api/health** endpoint.
93
93
94
94
> [!NOTE]
95
95
> The following sample code is only for demonstration purposes and is not intended for production use.
@@ -187,17 +187,17 @@ Now that you have all of your components in place, you can test out your failove
187
187
* primaryTopicKey - the key for your primary topic.
188
188
* secondaryTopicKey - the key for your secondary topic.
189
189
190
-
Try running the event publisher. You should see your test events land in your Event Grid viewer like below.
190
+
Try running the event publisher. You should see your test events land in your Event Grid viewer.
191
191
192
192
:::image type="content" source="./media/custom-disaster-recovery/event-grid-viewer.png" alt-text="Screenshot showing the Event Grid Viewer app with posted events.":::
193
193
194
-
To make sure your failover is working, you can change a few characters in your primary topic key to make it no longer valid. Try running the publisher again. You should still see new events appear in your Event Grid viewer, however when you look at your console, you'll see that they are now being published via the secondary topic.
194
+
To make sure your failover is working, you can change a few characters in your primary topic key to make it no longer valid. Try running the publisher again. You should still see new events appear in your Event Grid viewer, however when you look at your console, you see that they're now being published via the secondary topic.
195
195
196
196
### Possible extensions
197
197
198
198
There are many ways to extend this sample based on your needs. For high-volume scenarios, you may want to regularly check the topic's health api independently. That way, if a topic were to go down, you don't need to check it with every single publish. Once you know a topic isn't healthy, you can default to publishing to the secondary topic.
199
199
200
-
Similarly, you may want to implement failback logic based on your specific needs. If publishing to the closest data center is critical for you to reduce latency, you can periodically probe the health api of a topic that has failed over. Once it's healthy again, you'll know it's safe to failback to the closer data center.
200
+
Similarly, you may want to implement failback logic based on your specific needs. If publishing to the closest data center is critical for you to reduce latency, you can periodically probe the health api of a topic that has failed over. Once it's healthy again, you know it's safe to failback to the closer data center.
0 commit comments