#はじめに
先日、Azureストレージサービスの地理的に冗長化されたレプリケーション同士を手動でフェールオーバーさせて切り替えることができる機能が Public Preview となりましたので早速動作を確認してみました。
Account failover now in public preview for Azure Storage
https://docs.microsoft.com/en-us/azure/storage/common/storage-disaster-recovery-guidance
なお、今回のプレビューは、"US West 2"と"US West Central"リージョンでのみ公開となっています。
#Azure Storageとレプリケーションオプション
Azure Storageは、AWSでいうところのS3とよく比較されている気がしますが、S3のオブジェクトストレージとしての機能以外にも、SMB接続可能な共有ファイルストレージとしてのFiles機能や、テーブルなどの構造化データなども保持することができるTableなどの機能を持ち、S３単一よりもかなり広い機能を内包したサービスです。
（AWSユーザは、AWS サービスと Azure サービスの比較を見るとイメージしやすいかもしれません）
多様な構造のデータを格納できるStorageですが、データのレプリケーションは次の4つのオプションから選択できます。この中でGeo 冗長ストレージ (GRS)と読み取りアクセス geo 冗長ストレージ (RA-GRS)は、自然災害などの影響を同時に受けにくい数百Km以上離れたリージョン（ペアリージョン）にデータをレプリケートするオプションです。日本だと東日本と西日本がペアリージョンになっており、東日本リージョンが万が一災害でデータ消失しても西日本のデータ複製を使ってデータロストを防ぐことができます。（参考：ペアになっているリージョンとは）
<抜粋：[Azure Storage の概要](https://docs.microsoft.com/ja-jp/azure/storage/common/storage-introduction#replication)>
・ローカル冗長ストレージ (LRS):
単純な低コストのレプリケーション戦略。
データは、単一のストレージ スケール ユニット内でレプリケートされます。
・ゾーン冗長ストレージ (ZRS):
高可用性と持続性を備えたレプリケーション。
データは、3 つの可用性ゾーン間で同期的にレプリケートされます。
・Geo 冗長ストレージ (GRS):
リージョン全体が利用不可になる事態に備えたリージョン間レプリケーション。
・読み取りアクセス geo 冗長ストレージ (RA-GRS):
レプリカへの読み取りアクセス権を持つリージョン間レプリケーション。
#今までのGeo 冗長ストレージのフェールオーバー
ペアとなったリージョン間でデータを複製するGeo 冗長ストレージ（GRSとRA-GRS）ですが、ストレージの主系統（プライマリ）と副系統（セカンダリ）の切り替えは、今までMicrosoftがプライマリリージョンでのデータ復元ができないと結論した場合にのみ実施されることになっていました。
ストレージサービスの地理冗長 (GRS) の障害時の挙動について [2018/10/31追記]
https://blogs.technet.microsoft.com/jpaztech/2016/08/09/storage-service-grs-failover/
Storage のフェールオーバーが発生した場合
https://docs.microsoft.com/ja-jp/azure/storage/common/storage-disaster-recovery-guidance
<抜粋>
地域的な災害がプライマリ リージョンに影響する場合、Microsoft では、まず、そのリージョン内のサービスを復元して、RTO と RPO の最適な組み合わせを提供しようとします。 災害の性質とその影響によっては、まれではありますが、プライマリ リージョンを復元できないことがあります。 その場合は geo フェールオーバーを実行します。 リージョン間のデータ レプリケーションは非同期プロセスのため、遅延が発生し、セカンダリ リージョンにレプリケートされていない変更は失われる可能性があります。
つまり、ユーザ側の判断では、大規模障害が発生した際にペアリージョンの複製データに切り替えることができませんでした。
そのため、例えば災害時のDR挙動をテストしておきたいといった場合も厳密に実施できず不便、また万が一大規模障害が発生してストレージへのデータアクセスができない状態になった場合にMicrosoftが結論を出すまでストレージを利用することができないといった状況が想定されていました。
しかしながら今回ユーザ操作でプライマリ/セカンダリの切り替えができる機能がアナウンスされたため上記の課題を解決できます。
#実際フェールオーバーしてみた
###事前準備
事前準備としてフェールオーバーをおこなうサブスクリプションでリソースプロバイダーを登録しておく必要があります。リソースプロバイダーはサブスクリプションでリソース操作の権利を管理する機能ですが、ここで深く述べずおまじないと思っていただければと思います。
Connect-AzureRmAccount -SubscriptionId <subscription-id>
Register-AzureRmProviderFeature -FeatureName CustomerControlledFailover -ProviderNamespace Microsoft.Storage
プレビュー利用者数を調整しているのか登録完了までには1-2日間かかるようです。私も1.5日くらいかかりました。Stateが次のようにRegisteredになればOKです。フェイルオーバーが実際に実行できるようになります。
Get-AzureRmProviderFeature -FeatureName CustomerControlledFailover -ProviderNamespace Microsoft.Storage
FeatureName ProviderName RegistrationState
----------- ------------ -----------------
CustomerControlledFailover Microsoft.Storage Registered
###Let's フェールオーバー
◾️Azure ポータル(https://portal.azure.com)の場合
ストレージ画面から 設定カテゴリのgeo レプリケーションを開きます。下部の「フェールオーバーの準備」ボタンで実行できます。
クリックすると確認画面になるので、進みます
◾️Azure Powershellの場合
Azure Powershellで実行するには、現在PreviewのModuleをインストールしないといけません。なので既存のPowershell環境を崩したくない人は異なる端末でやるかPortal or Azure CLIを使うのが良いと思います
Install-Module PowerShellGet –Repository PSGallery –Force
Install-Module Az –Repository PSGallery –AllowClobber
Install-Module -Name AzureRM.Storage -AllowPrerelease
Invoke-AzureRmStorageAccountFailover -ResourceGroupName <resource-group-name> -Name <account-name>
◾️Azure CLIの場合
az storage account show \ --name accountName \ --expand geoReplicationStats
az storage account failover \ --name accountName
###フェールオーバーの確認
ほんとに切り替わってるのかを確認することは大事いうことで確認してみました。（疑うわけじゃないですが）
まずフェールオーバー実行前のストレージアカウントのプライマリとセカンダリのエンドポイントを名前解決した際のIPアドレスです
nslookup failovertest0207.blob.core.windows.net
Server: xxx.xxx.xxx.xxx
Address: xxx.xxx.xxx.xxx#53
Non-authoritative answer:
failovertest0207.blob.core.windows.net canonical name = blob.mwh01prdstr06a.store.core.windows.net.
Name: blob.mwh01prdstr06a.store.core.windows.net
Address: 52.183.104.36
nslookup failovertest0207-secondary.blob.core.windows.net
Server: xxx.xxx.xxx.xxx
Address: xxx.xxx.xxx.xxx#53
Non-authoritative answer:
failovertest0207-secondary.blob.core.windows.net canonical name = blob.cy4prdstr06b.store.core.windows.net.
Name: blob.cy4prdstr06b.store.core.windows.net
Address: 52.161.112.46
プライマリは52.183.104.36で名前解決され、セカンダリは52.161.112.46に解決されています。
AzureのパブリックIPアドレスのレンジはリージョンごとに決まっており公開されています。Microsoft Azure Datacenter IP Rangesにて確認すると、52.183.104.36はus west2（米国西部2）、52.161.112.46は確かにuswestcentral（米国中西部）に属しています。
<Region Name="uswest2">
<IpRange Subnet="52.183.0.0/17" />
</Region>
<Region Name="uswestcentral">
<IpRange Subnet="52.161.0.0/16" />
</Region>
フェールオーバーの操作後は次の通りプライマリが元のセカンダリのIPアドレス（米国中西部）として解決されるようになり、無事切り替えが完了していることが確認できました。
nslookup failovertest0207.blob.core.windows.net
Server: xxx.xxx.xxx.xxx
Address: xxx.xxx.xxx.xxx#53
Non-authoritative answer:
failovertest0207.blob.core.windows.net canonical name = blob.cy4prdstr06b.store.core.windows.net.
Name: blob.cy4prdstr06b.store.core.windows.net
Address: 52.161.112.46
#補足
マニュアルフェイルオーバーを実際試して気づいた点として、フェールオーバー実行後は、元のセカンダリリージョンをプライマリとしたLRS構成に変更される動作のようです。なのでフェールオーバー実行後セカンダリエンドポイントは使用できなくなりますが、再度ストレージアカウントをLRSからGRS/RA-GRSに設定変更することもできます。
#参考