はじめに
クラウドサービスは SLA で示されているとおり、非常に高い可用性が保証されています。
大規模災害が発生した場合も、クラウドサービス側である程度の対応は実施してもらえますが、私達 利用者側でも対策・対応手順を考えておく必要があります。
今回は、Azure のストレージ アカウントにおけるフェールオーバー・フェールバックを試してみます。
使用するツール類
- Azure ポータル
- PowerShell 7.2.1
- Azure PowerShell 7.1.0
検証
ストレージ アカウントの準備
ストレージ アカウントのフェールバック機能を使用するには、下記のいずれかの冗長オプションを指定する必要があります。
- geo 冗長ストレージ (GRS)
- 読み取りアクセス geo 冗長ストレージ (RA-GRS)
- geo ゾーン冗長ストレージ (GZRS)
- 読み取りアクセス geo ゾーン冗長ストレージ (RA-GZRS)
今回は、「東日本リージョン」に「geo 冗長ストレージ (GRS)」でストレージ アカウントを作成します。
Azure PowerShell を使用してストレージ アカウントの情報を取得すると、下記のような結果が戻ってきます。
(この記事に関連する部分のみ抜粋)
{
...,
"Location": "japaneast",
"Sku": {
"Name": "Standard_GRS",
...
},
...,
"LastGeoFailoverTime": null,
...,
"PrimaryLocation": "japaneast",
"ProvisioningState": "Succeeded",
"SecondaryEndpoints": null,
"SecondaryLocation": "japanwest",
"StatusOfPrimary": "available",
"StatusOfSecondary": "available",
...
}
「test」というコンテナーを作成し、テキスト ファイルを検証のためにアップロードします。
$info = Get-AzStorageAccount -ResourceGroupName "tst-mm-rgp" -Name "tstmmsatmp1"
Set-AzStorageBlobContent -File "C:/_Tmp/work/before_failover.txt" -Container "test" -Blob "before_failover.txt" -Context $info.Context
フェールオーバーの実行
準備ができたのでフェールオーバーを実行したいと思いますが、実行前に必ず確認しなければいけないことがあります。
それは “アップロードしたファイルがプライマリ リージョンからセカンダリ リージョンに同期 (コピー) されているか？” の確認です。
「geo 冗長ストレージ (GRS)」で作成したストレージ アカウントは、プライマリ リージョンとセカンダリ リージョンの両方にデータの書き込みが行われますが、セカンダリ リージョンへの書き込みは非同期で行われます。
そのため、タイミングによってはセカンダリ リージョンにデータが書き込まれていない可能性があります。
セカンダリ リージョンへの書き込みが実行される前にフェールオーバーを実行してしまうと、プライマリ リージョンにしかないデータは消えてしまいます。
最後に書き込みしたデータの最終更新日時と、Azure PowerShell を使用して取得できる「最終同期時刻」を比較して、すべてのデータが同期されていることを確認してください。
※「最終同期時刻」は GMT で取得されるので、注意！
$(Get-AzStorageAccount -ResourceGroupName "tst-mm-rgp" -Name "tstmmsatmp1" -IncludeGeoReplicationStats).GeoReplicationStats.LastSyncTime
2022年1月9日 8:07:06
同期が問題ないことを確認したら、いよいよフェールオーバーを実行します。
ストレージ アカウントのメニューで「geo レプリケーション」を選択すると、下のような画面が表示されます。
この画面の「フェールオーバーの準備」ボタンをクリックすると、下のような画面がさらに表示されます。
「フェールオーバーの確認」に「はい」と入力し、「フェールオーバー」ボタンをクリックすると、フェールオーバーが開始されます。
または、Azure PowerShell でもフェールオーバーの実行が可能です。
Invoke-AzStorageAccountFailover -ResourceGroupName "tst-mm-rgp" -AccountName "tstmmsatmp1"
フェールオーバー実行中に Azure PowerShell を使用してストレージ アカウントの情報を取得すると、FailoverInProgress の値が true に変わっていることがわかります。
【フェールオーバー実行前】
{
...,
"FailoverInProgress": null,
...
}
【フェールオーバー実行中】
{
...,
"FailoverInProgress": true,
...
}
フェールオーバーの完了後にストレージ アカウントの情報を取得すると、下記のような結果が戻ってきます。
{
...,
"Location": "japaneast",
"Sku": {
"Name": "Standard_LRS",
...
},
...,
"LastGeoFailoverTime": "2022-01-09T08:49:29.8111298Z",
...,
"PrimaryLocation": "japanwest",
"ProvisioningState": "Succeeded",
"SecondaryEndpoints": null,
"SecondaryLocation": null,
"StatusOfPrimary": "available",
"StatusOfSecondary": null,
...
}
フェールオーバー前後で値を比較すると、下表のような差異があります。
| プロパティ | 実行前 | 実行後 |
|---|---|---|
| Sku.Name | Standard_GRS | Standard_LRS |
| LastGeoFailoverTime | null | 2022-01-09T08:49:29.8111298Z |
| PrimaryLocation | japaneast | japanwest |
| SecondaryLocation | japanwest | null |
| StatusOfSecondary | available | null |
フェールオーバー後は、プライマリ リージョンが「東日本リージョン」から「西日本リージョン」に変わっており、また「geo 冗長ストレージ (GRS)」ではなく「ローカル冗長ストレージ (LRS)」となっています。
フェールオーバーを実行するような状況の場合、元のプライマリ リージョン (今回の場合、「東日本リージョン」) は使用できない状態だと考えられます。
Azure の「geo 冗長」は、ペアとなるリージョンが決まっており、任意のリージョンをセカンダリ リージョンに指定することはできません。
そのため、ペアとなるリージョンが復旧するまでは、下記のような対応になるかと思います。
- ペアとなるリージョンが復旧するまで「ローカル冗長ストレージ (LRS)」のまま運用する。
- 異なるリージョンに「geo 冗長ストレージ (GRS)」のストレージ アカウントを作成し、そちらにデータをコピーする。
- ストレージ アカウントの「オブジェクト レプリケーション」機能を使用して、任意のストレージ アカウントにデータをコピーする。
今回は『ペアとなるリージョンが復旧するまで「ローカル冗長ストレージ (LRS)」のまま運用する。』想定で、元のプライマリ リージョンにフェールバックします。
フェールバックの準備
まず、「ローカル冗長ストレージ (LRS)」のまま運用していたときにアップロードしたファイルが、フェールバック時に消えたりしないか検証するため、テキスト ファイルをアップロードします。
$info = Get-AzStorageAccount -ResourceGroupName "tst-mm-rgp" -Name "tstmmsatmp1"
Set-AzStorageBlobContent -File "C:/_Tmp/work/after_failover.txt" -Container "test" -Blob "after_failover.txt" -Context $info.Context
ファイルをアップロードしたら、ストレージ アカウントを「ローカル冗長ストレージ (LRS)」から「geo 冗長ストレージ (GRS)」に変更します。
Set-AzStorageAccount -ResourceGroupName "tst-mm-rgp" -AccountName "tstmmsatmp1" -SkuName "Standard_GRS"
「ローカル冗長ストレージ (LRS)」から「geo 冗長ストレージ (GRS)」への変更中、ストレージ アカウントの「geo レプリケーション」の画面は、下図のようにメッセージが表示され、フェールオーバーの実行ができなくなります。
Azure PowerShell を使用して無理に実行しようとしても、下記のようにエラーが発生して、実行に失敗します。
Invoke-AzStorageAccountFailover -ResourceGroupName "tst-mm-rgp" -AccountName "tstmmsatmp1" -Force
Invoke-AzStorageAccountFailover: Last sync time is unavailable for account tstmmsatmp1.
フェールバックの実行
しばらくすると「geo 冗長ストレージ (GRS)」への変更が完了し、フェールオーバーの実行ができるようになります。
そうしたら、下記の手順を実行していきます。
(詳細な手順は、ここまでに記載した内容と重複しますので、割愛します。)
- 最後に書き込みしたデータの最終更新日時と、ストレージ アカウントの「最終同期時刻」を比較し、問題ないことを確認する。
- Azure ポータルや Azure PowerShell を使用して、フェールオーバーを実行する。
- フェールオーバーの完了後、「geo 冗長ストレージ (GRS)」に変更する。
ここまでで、フェールバックが完了となります。
“最初の状態” と “フェールバック後” のストレージ アカウントの情報を比較すると、差異は LastGeoFailoverTime のみとなります。
また、プライマリ リージョンが「西日本リージョン」になっていたときにアップロードしたファイルも、しっかり格納されています。
おわりに
ストレージ アカウントのフェールオーバー・フェールバックを実際に試してみましたが、特に難しいところはありませんでした。
クラウドサービスによって、災害発生時の対応方法は異なりますが、探してみると今回のように簡単に対応する方法があるかもしれません。
既に災害発生時の対応をまとめている場合でも、クラウドサービスは日進月歩で進化しているので、さらに簡単・便利な機能が提供されているかもしれません。
この記事が、災害発生時の対応について考えるきっかけになれば幸いです。