ストレージアカウントのフェールオーバーを試してみた

2022年1月11日 18:54

はじめに

クラウドサービスは 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,
  ...
}

フェールオーバー前後で値を比較すると、下表のような差異があります。

$$
\begin{array}{|l|l|l|} \hline
\textbf{プロパティ} & \textbf{実行前} & \textbf{実行後} \\ \hline\hline
\text{Sku\\.Name} & \text{Standard\_GRS} & \text{Standard\_LRS} \\ \hline
\text{LastGeoFailoverTime} & \text{null} & \text{2022-01-09T08:49:29.8111298Z} \\ \hline
\text{PrimaryLocation} & \text{japaneast} & \text{japanwest} \\ \hline
\text{SecondaryLocation} & \text{japanwest} & \text{null} \\ \hline
\text{StatusOfSecondary} & \text{available} & \text{null} \\ \hline
\end{array}
$$

フェールオーバー後は、プライマリリージョンが「東日本リージョン」から「西日本リージョン」に変わっており、また「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 のみとなります。

また、プライマリリージョンが「西日本リージョン」になっていたときにアップロードしたファイルも、しっかり格納されています。

おわりに

ストレージアカウントのフェールオーバー・フェールバックを実際に試してみましたが、特に難しいところはありませんでした。
クラウドサービスによって、災害発生時の対応方法は異なりますが、探してみると今回のように簡単に対応する方法があるかもしれません。
既に災害発生時の対応をまとめている場合でも、クラウドサービスは日進月歩で進化しているので、さらに簡単・便利な機能が提供されているかもしれません。
この記事が、災害発生時の対応について考えるきっかけになれば幸いです。

参考情報

この記事が気に入ったらサポートをしてみませんか？

ストレージ アカウントのフェールオーバーを試してみた