Achieving Geo-Redundancy with ASA

Currently Azure Stream Analytics does not provide automatic geo-failover but you can achieve geo-redundancy by deploying identical ASA jobs in multiple Azure regions.  Each job connects to a local input and local output sources.  It is the responsibility of the customer’s application to both send input data into the two regional inputs and reconcile between the two regional outputs. The jobs are two separate entities.

The following diagram depicts a sample geo-redundant ASA job deployment with Event Hub input and Azure DB output.




Primary Secondary Strategy

It’s the responsibility of the Consumer application to manage what region’s output database is considered primary leaving the other one secondary database. On a primary region failure, the application switches to the secondary database and starts reading updates from that database. The actual mechanism allowing minimizing duplicate reads is application dependent.  By writing additional information to the output, this process can be simplified. For example, each output event can contain a timestamp, or a sequence id, so skipping duplicate rows when switching to a secondary database is a trivial operation. Once the primary region is restored, it catches up with the secondary database using similar mechanics.

Even though different input/output types allow different geo-replication options (Azure blobs, Azure DB Premium SKU), we recommend using the depicted pattern to achieve geo-redundancy as it provides flexibility and control for the both event producers and event consumers.




Comments (0)

Skip to main content