I want to enable Geo-DR and fail-over, but don’t want to update the connection string

  • [アーティクル]

Data centers experience downtime. We still want to ensure the data processing continue to happen event if this means from a different region or data center. Azure Event Hubs supports your geographical disaster recovery plan by enabling geo-replication of the namespace metadata in a different region. With this feature, often the customers ask a question,

My client applications need an update when a failover happens?

Let me answer this question by describing how the feature works with Azure Event Hubs. The service enables the feature by pairing a primary namespace in a region with a secondary namespace in another region. You pair both the regions using an alias. An alias is a name that you provide for your geo-disaster recovery configurations and provides a single stable Fully Qualified Domain Name (FQDN) connection string. You can use this connection string in your client applications.

In the event of disaster, the customer (you) initiates a failover to your secondary namespace. Your alias now points only to your secondary namespace. However, the connection string remains the same. This concept solves many customer scenarios. Nevertheless, what about the client applications that are currently in production and depending on your current primary namespace? We have tried to solve this problem by introducing the concept of an alternate name that is tied to your current primary namespace.

So what is an alternate name?

Azure Event Hubs lets you use your current primary namespace to be the alias name when creating a geo-pair for your disaster recovery configurations. When doing so, you have the option of providing the alternate name to identify your primary namespace.

I urge you to read the following considerations before you opt for this approach.

  1. An alternate name is simply an identifier name that you give to your primary namespace.
  2. If you provide your primary namespace to be your alias, you current primary connection string is your alias connection string as well.
  3. When you do a failover in the event of a disaster – your secondary namespace becomes your primary with the same connection string (remember, your alias connection string is same as your current existing primary connection string).
  4. This means, when you want to connect back to your old primary (to drain any data or connect for any other reasons), this is not possible with the connection string.
  5. Your alternate name now comes into consideration, as this is the only way you can access your old primary.
  6. Your primary namespace name in this context remains the same. The connectionstring though will change to reflect the alternate name
  7. In addition, after the fail-over your new primary (old secondary) will now have the existing primary connection string and the alias connection string.
  8. If you want to pair the same set of namespaces again, this will not be possible to avoid confusions with the connection string

The following script walks you through this experience of providing an alternate name and failing over using the existing primary namespace as your alias.

 #Step1 - Login to your Azure subscription
az login

#Optional - set your desired subscription
az account set --subscription "your subscription name"

#Step 2 – following parameters are used while creating the resources.

#geo location where the primarynamespace is
export location1=SouthCentralUS

#geo location where the secondarynamespace should be created
export location2=NorthCentralUS

#provide your exisitng resourcegroup which has the primarynamespace
export resourcegroup=myresourcegroup

#provide your existing primary namespace
export primarynamespace=myexistingprimarynamespace
export secondarynamespace=myexistingsecondarynamespace

# here your primarynamespace is your alias name
export aliasname=myexistingprimarynamespace
export alternatename=testehalternatename1

#Step 3 - create your secondary namespace. Copy the ARM ID from the output as you need it later for -PartnerPartnernamespace.
# sample ARM ID looks like this - /subscriptions/your subscriptionid/resourceGroups/$resourcegroup/providers/Microsoft.EventHub/namespaces/secondarynamespace
az eventhubs namespace create --name $secondarynamespace --resource-group $resourcegroup --location $location2 --sku Standard

#Step 4 - Create a geo-dr configuration with primarynamespace name as the alias name and pair the namespaces. Note, you will also provide the alternatename here.
# It is using this alternatename that you will access your old primary once you have triggered the failover
az eventhubs georecovery-alias set --resource-group $resourcegroup --alias $primarynamespace --namespace-name $primarynamespace --partner-namespace "ARM ID of secondary namespace" --alternate-name $alternatename

#Optional - Once your geo-dr configurations are set, you can get the details using this
az eventhubs georecovery-alias show --resource-group $resourcegroup --alias $aliasname --namespace-name $primarynamespace

#Step 5 - you can now do a failover on your secondary namespace with the following command
az eventhubs georecovery-alias fail-over --resource-group $resourcegroup --alias $aliasname --namespace-name $secondarynamespace

#Optional - check you geo-dr configuration details to reflect the fail-over
#Note - your secondarynamespace after the failover will be your new primary, but the connection string remains the same
az eventhubs georecovery-alias show --resource-group $resourcegroup --alias $aliasname --namespace-name $secondarynamespace -- this is your current primary

You can download this script from azure-event-hubs GitHub repo. The PowerShell version of this script can be found here.

Geo-Disaster Recovery requires a lot of planning and consideration as this is vital to the proper and continual functioning of your business and its needs. This blog aims to educate the considerations when enabling this feature for Azure Event Hubs. As a best practice, our recommendation would be to update your clients. This is much cleaner, even though you have the option of retaining the current connection string. We also recommend you to delete the old primary namespace once you have drained your data on it.

We currently support the feature for meta-data replication at namespace and in future may add the data replication as well. We would love to hear what you have to say to us. Leave us your comments/feedback.

Happy Event-ing!

Azure Event Hubs Team