search

MicrosoftDocs / azure-docs

Open source documentation of Microsoft Azure
https://docs.microsoft.com/azure
Creative Commons Attribution 4.0 International
10.2k stars 21.35k forks source link

Return ADLS gen 2 back to initial primary region after Microsoft-managed failover #111411

Closed PKPublicCode closed 7 months ago

PKPublicCode commented 1 year ago

Article says: Customer-managed account failover is not yet supported in accounts that have a hierarchical namespace (Azure Data Lake Storage Gen2). To learn more, see Blob storage features available in Azure Data Lake Storage Gen2.

In the event of a disaster that affects the primary region, Microsoft will manage the failover for accounts with a hierarchical namespace. For more information, see Microsoft-managed failover.

It would be great to describe how ADLS Gen2 can be reverted back to initial primary region after microsoft-managed failover to secondary region, and when initial primary region became available again.

Document Details

⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

YashikaTyagii commented 1 year ago

@PKPublicCode Thanks for your feedback! We will investigate and update as appropriate.

SaibabaBalapur-MSFT commented 1 year ago

hi @PKPublicCode When an ADLS Gen2 account is failed over to the secondary region due to a disaster or outage in the primary region, you can initiate a failback to the primary region once it becomes available again. To initiate a failback, you can use the Azure portal, Azure PowerShell, Azure CLI, or the Azure Storage Resource Provider API. Once the failback is complete, the primary region becomes the primary again, and the secondary region becomes the secondary. It's important to note that during the failover, any data that was written to the secondary region while it was the primary region will be lost. To avoid data loss, you should check the value of the Last Sync Time property before initiating a failback. This will help you evaluate any discrepancies between data in the primary and secondary regions and determine the expected data loss.

Here's an example of how to initiate a failback using Azure PowerShell:

Connect to your Azure account Connect-AzAccount Set the context to the subscription containing the ADLS Gen2 account Set-AzContext -SubscriptionId Initiate the failback Invoke-AzStorageAccountFailover -ResourceGroupName -Name -SecondaryRegion

if there are any further questions regarding the documentation, please tag me in your reply and we will be happy to continue the conversation.

PKPublicCode commented 1 year ago

Hi @SaibabaBalapur-MSFT, Thank you. Very much appreciate quick and detailed response. It's very helpful and I believe it would be great to reflect it in docs!

And now I see more important thing to update in the doc. According to your answer, Microsoft-managed failover for ADLS and user-managed failover (for storage account) work too differently. I mean that after user managed failover of GRS, storage account becomes LRS. But for microsoft-managed failover, according to your answer, ADLS remains GRS. Will it work same way for conventional storage account? I believe it would be great to add this info into Microsoft-manged failover section

SaibabaBalapur-MSFT commented 1 year ago

Hi @PKPublicCode Azure Data Lake Storage (ADLS) supports two replication options, Locally Redundant Storage (LRS) and Geo-Redundant Storage (GRS). However, it's important to note that ADLS Gen1 only supports GRS, while ADLS Gen2 supports both LRS and GRS. If you're referring to conventional Azure Storage accounts, such as Blob storage, File storage, or Queue storage, they also offer LRS and GRS replication options. However, it's worth mentioning that the replication options for Azure Storage accounts are separate from those of ADLS. In both cases, LRS provides redundancy within a single Azure region, ensuring data durability, while GRS provides additional redundancy by replicating data to a paired region, offering data resiliency in the event of a regional outage. ADLS and Azure Storage accounts have separate replication options, but both offer LRS and GRS choices.

I'd recommend working closer with our Q&A forum by posting your issue there so our community, and MVPs can further assist you in troubleshooting this issue or finding potential workarounds. [Teams Q&A forum] (https://docs.microsoft.com/en-us/answers/topics/46488/office-teams-windows-itpro.html) for technical questions about the configuration and administration of Microsoft Teams on Windows.

PKPublicCode commented 1 year ago

Hi @SaibabaBalapur-MSFT, I'm referring exactly to the documentation specified in issue description.

Key points in the document: a) Page explains failover options of storage accounts including accounts with hieratical namespace (aka ADLS Gen2). b) Page says that ADLS Gen2 doesn't support user managed failover c) Page has detailed explanation how user-managed failover works and what happens when it's done. d) Page doesn't have detailed explanation how Microsoft-managed failover works and when it's done, that makes reader assume that it works similarly to user-managed account (c)

Key points of your answer (that I very much appreciate): e) Microsoft managed failover (d) works completely differently than user managed failover (c) f) After microsoft managed failover, when initial primary region recovered available again, user can manually trigger "failover back" to the initial primary region. that contradicts to documentation (b)

So, my request is to update documentation and so make my initial question answered for everybody, who reads the doc.

PS. Regarding Q&A, there is exactly my initial question asked 1 year ago by another person, and it has not answered yet

SaibabaBalapur-MSFT commented 1 year ago

@PKPublicCode I'm going to assign this to the document author so they can take a look at it accordingly.

@jimmart-dev Can you please check and add your comments on this doc update request as applicable.

PKPublicCode commented 1 year ago

@SaibabaBalapur-MSFT Thank you very much. Very much appreciate your help.

akashdubey-ms commented 7 months ago

Thanks for your contribution to our documentation

Unfortunately, we have been unable to review this issue in a timely manner. We sincerely apologize for the delayed response. We are closing this issue. If you feel that the problem persists, please respond to this issue with additional information. ? Please continue to provide feedback about the documentation. We appreciate your contributions to our community.

please-close