3

I am developing an Azure application (C#, .NET 6, ASP.NET Core) that uses Azure blob storage as well as table storage.

I have geo-redundancy enabled on my storage account (RA_GRS) so that if my main storage account goes down, a read-only copy will be available in another Azure region.

When reading from blob storage, as far as I understand, I should be able to get it to automatically fall back to the secondary address by setting the GeoRedundantSecondaryUri property like this:

    return new BlobServiceClient(
        new Uri($"https://{accountName}.blob.core.windows.net/"),
        sharedKeyCredential,
        new BlobClientOptions
        {
            GeoRedundantSecondaryUri = new Uri($"https://{accountName}-secondary.blob.core.windows.net/")
        });

How can I end-to-end test that I am doing this correctly?

Can I tell the storage account to go offline so that my application should fall back to the read-only backup? I know I can stop an app service using az webapp stop from the command line. Can I do anything similar for storage accounts? Otherwise, how can I test my fallback logic?

(I am asking not only because I want to test the built-in geo-redundancy functionality. I have other failover-related code I want to test.)

EDIT 1: I do not want to use Azure's built-in "initiate account failover" functionality. At least not at this time. I want to test that my application can continue in a kind of "read-only mode" while the primary storage is down.

EDIT 2-3: I have tried to block the primary address ({accountName}.blob.core.windows.net/) using C:\Windows\System32\drivers\etc\hosts. My blob client does not seem to fall back.

  • If I redirect to IP 0.0.0.0, the blob client throws this: "The requested name is valid, but no data of the requested type was found."
  • If I redirect to IP 127.0.0.1, the blob client throws this: "No connection could be made because the target machine actively refused it."
Claus Appel
  • 1,015
  • 10
  • 28
  • 1
    Do you want to do automated testing? Or just test it once? In the latter case you could add an entry for `{accountName}.blob.core.windows.net` to your `/etc/hosts` (resp. `c:\windows\system32\drivers\etc\hosts` on windows) file, pointing to an invalid ip address – derpirscher Feb 08 '22 at 10:05
  • Thanks for the suggestion. When I block the address using the hostfile, it does not fall back. It throws this: "The requested name is valid, but no data of the requested type was found." – Claus Appel Feb 08 '22 at 14:04
  • 1
    what did you use as value for the ip address? This message points towards an invalid DNS entry – derpirscher Feb 08 '22 at 14:53
  • I was using `0.0.0.0`, which I guess might be a bad IP. `127.0.0.1` gives a different error message but still no fallback. – Claus Appel Feb 08 '22 at 15:17
  • Yeah, that last message actually reflects what's happening when the designated machine does not allow a connection at that port (ie the machine can be reached, but the port is not open). You could also try using an address like 10.11.12.13 (10.x.x.x is reserved for private use) which would point to a server that cannot be reached at all. You probably will get yet another error message. But I don't have any experiance with those services, so I can't help with configuring automated failover ... – derpirscher Feb 08 '22 at 15:57

1 Answers1

0

If you just want to test the geo-redundancy of your Storage Account, you can initiate an account failover manually from Azure portal & see if your application resumes back the functionality via secondary endpoints.

This documentation might help you out in this scenario: Initiate Azure Storage Account Failover

Note that there will be a certain minimal amount of data loss if you perform a failover, so I'd recommend you to go through the implications of a failover before performing it.

Yash Gupta
  • 1,807
  • 15
  • 21
  • 1
    I would not recommend this approach primarily because when you do the manual failover, the storage account's redundancy changes to LRS and one needs to change the redundancy back. – Gaurav Mantri Feb 08 '22 at 10:00
  • 1
    Thanks, but I do not want to use Azure's standard "account failover". At least not at this time. I want to test that my application can continue in a kind of "read-only mode" while the primary storage is down. – Claus Appel Feb 08 '22 at 10:45
  • @GauravMantri - yes, I agree with that. That's one certain drawback of doing a manual failover. Thanks for adding this point! – Yash Gupta Feb 12 '22 at 06:43