U
umeshpanwar1
In today’s post, I’m excited to shed light on a creative solution I devised to meet a unique client requirement. Azure Blob storage, in its native form, doesn’t inherently support multi-region active-active architectures. However, as every cloud architect knows, challenges often pave the way for innovative solutions.
My client was on the hunt for a method to achieve a multi-region active-active configuration with Azure blob storage. Rising to the occasion, I devised two potential designs, presenting both to the client. After a thorough discussion, the client chose the design that fit their needs seamlessly. I believe sharing these designs might prove beneficial for others faced with a similar challenge.
At the heart of this solution, the client’s application is exposed to its users through Azure Traffic Manager. Traffic manager efficiently routes traffic to Virtual Machines (VMs) located in two separate regions. These VMs, operating behind a load balancer, interact with the Azure blob storage, writing data from both regions. For bolstered security against unforeseen calamities, it’s imperative that the Azure storage account is set to be Geo-redundant. This ensures that in case of disasters, it can be failed over to the secondary region, ensuring accessibility with little to no interruption.
Accessing Storage via Service Endpoint
In this model, Blob storage can be reached from both regions using the Service Endpoint. To counteract potential data exfiltration, Service Endpoint Policies are put into place.
Accessing Storage via Service Endpoint
Accessing Storage via Private Endpoint
The alternate model has Blob storage accessed via a private endpoint from both regions. Given that this model integrates the Azure service into the VNET, Private endpoint options is always a top pick for most of our customers.
Accessing Storage via Private Endpoint
Both these designs boast robustness at every layer. With two VMs set up in each region, the system ensures that even if one VM faces issues, the service remains undisturbed. Should both VMs in a single region falter, the other region swiftly steps in to guarantee continued service. Thanks to the Geo-redundant nature of the storage, even in the face of major disruptions, the storage account can switch from the primary to the secondary region. This transition refreshes the DNS entry for the storage account, transforming the secondary endpoint into the primary.
I hope this deep dive into my design solutions offers insights for fellow cloud architects and enthusiasts alike. As the world of cloud computing continually evolves, so does our quest for pioneering solutions.
Continue reading...
My client was on the hunt for a method to achieve a multi-region active-active configuration with Azure blob storage. Rising to the occasion, I devised two potential designs, presenting both to the client. After a thorough discussion, the client chose the design that fit their needs seamlessly. I believe sharing these designs might prove beneficial for others faced with a similar challenge.
At the heart of this solution, the client’s application is exposed to its users through Azure Traffic Manager. Traffic manager efficiently routes traffic to Virtual Machines (VMs) located in two separate regions. These VMs, operating behind a load balancer, interact with the Azure blob storage, writing data from both regions. For bolstered security against unforeseen calamities, it’s imperative that the Azure storage account is set to be Geo-redundant. This ensures that in case of disasters, it can be failed over to the secondary region, ensuring accessibility with little to no interruption.
Accessing Storage via Service Endpoint
In this model, Blob storage can be reached from both regions using the Service Endpoint. To counteract potential data exfiltration, Service Endpoint Policies are put into place.
Accessing Storage via Service EndpointAccessing Storage via Private Endpoint
The alternate model has Blob storage accessed via a private endpoint from both regions. Given that this model integrates the Azure service into the VNET, Private endpoint options is always a top pick for most of our customers.
Accessing Storage via Private EndpointBoth these designs boast robustness at every layer. With two VMs set up in each region, the system ensures that even if one VM faces issues, the service remains undisturbed. Should both VMs in a single region falter, the other region swiftly steps in to guarantee continued service. Thanks to the Geo-redundant nature of the storage, even in the face of major disruptions, the storage account can switch from the primary to the secondary region. This transition refreshes the DNS entry for the storage account, transforming the secondary endpoint into the primary.
I hope this deep dive into my design solutions offers insights for fellow cloud architects and enthusiasts alike. As the world of cloud computing continually evolves, so does our quest for pioneering solutions.
Continue reading...