A company named OrbitCargo Systems is designing a disaster recovery strategy for its critical flight cargo tracking application. The application stores transaction logs in an Azure Block Blob storage account that is currently configured with Read-Access Geo-Redundant Storage (RA-GRS). The primary region is East US, and the secondary region is West US.
During a simulated primary region outage in East US, the operations team needs to ensure that the tracking application can continue to read existing logs and write new transaction logs with minimal downtime. The solution must ensure that once the primary region becomes healthy again, data redundancy is maintained.
Which two actions should you include in the design to meet these requirements?
- Initiate a customer-managed storage account failover to promote the secondary region to the new primary region.Answer
- Reconfigure the storage account to geo-redundant storage after the failover is complete to re-establish replication.Answer
- CRe-route the application's write operations directly to the secondary storage endpoint ending in -secondary.blob.core.windows.net during the outage.
- DChange the replication setting of the storage account to Locally Redundant Storage (LRS) and configure client-side application logic to write data to both regions.
Answer
Initiating a customer-managed failover of the storage account and reconfiguring it to geo-redundant storage after the failover is complete.
Initiating a customer-managed failover changes the secondary endpoint to the primary endpoint, making it writeable. Once failover is complete, the storage account replication automatically reverts to locally redundant storage (LRS), meaning that re-establishing geo-redundancy (GRS or RA-GRS) is necessary to ensure disaster recovery capabilities are maintained.
Step-by-Step Solution
Key Concept
Azure Storage Account Failover Mechanics and Write Restrictions on Secondary Endpoints
Estimated Time:2m 0s