Draining Service Bus 

Introduction: Service Bus is an Azure public cloud computing resource that acts as a message broker between publishers and subscribers. As a cloud resource, it can scale to arbitrary loads and become mission-critical. Its availability is improved by providing redundancy across regions so that when one goes down, it can failover to another. It comprises a variety of message holders such as Queues, Topics, Relays, and Event Hub listed within a namespace. They differ primarily in how they are used. For example, a queue enables one producer and consumer to send and receive ordered messages. A Topic allows a subscription so that many subscribers can receive messages. There can be several of each type of Service Bus entity and millions of messages in transit. This article describes the proper way to failover from one SB instance to another. 

Description: The availability of the Service Bus is further improved by its deployment to multiple low-latency availability zones in a geographical region. While the deployment across regions allows different instances to be provisioned, the deployments within a region across multiple availability zones are for the same instance. The service bus resource does not allow in-place enablement of zone redundancy to improve availability which requires some steps to be taken to preserve the structure and content of the original instance. There are no options to transfer both the structure and content at the same time and the only way to do that is to first replicate the structure on a target instance and then copy the data over after that.  This happens with the help of the logic that enumerates them and copies them one by one to the destination. The same logic applies to data migration. This control and data plane duplication can be custom-written into a single program, but it is better to leverage the built-in features of the resource that support the redundancy based on replicating the entities via internal automation. The steps for this migration can be listed as follows: Step 1: Create a new Premium Stock Keeping Unit (SKU) namespace. Step 2: Pair the source and destination namespaces with each other. Step 3: Sync or copy over the entities from the source to the destination namespace. Step 4: Commit the migration. Step 5: Drain entities from the source namespace using the post-migration name of the namespace Step 6: Delete the source namespace. Pairing a source namespace and destination namespace automatically copies over all the SB entities from the source namespace to the destination namespace. It is an in-build feature of the pairing mechanism of the Service Bus. The only catch in that replication is that pairing must be across regions and if we want to have another instance in the same region, we perform the structure and content migration to a new instance in a different region, break the pairing and then create a new pairing between that instance and a third instance back in the original region. Pairing does not replicate the messages that may still be held in the SB entities of the source namespace during the migration and just before it is completed. These messages must be drained. Each of the SB entities is enumerated and their messages read and copied to the corresponding entity in the destination namespace.  There are options in the programmability features of this Azure resource to automate the enumeration and transfer of messages. However, it is also possible to avoid writing this code. In such a case, a maintenance window must be in effect during the migration and the following steps will need to be taken. The sender applications are stopped. The receiver applications will process the messages currently in the source namespace and drain the queue. The queues and subscriptions in the source If the source namespace is empty, the migration steps listed earlier are performed. When the migration steps are complete, the sender applications may be restarted. The senders and receivers will now automatically connect with the destination namespace with the help of the alias that was set up for post-migration handling of the traffic from senders. This completes the structure and content replication of the Service Bus.