ストレージ アカウントのフェールオーバーを開始する
Microsoft は、Azure サービスを常に使用できるようにする作業に取り組んでいます。 そうはいっても、計画外のサービス停止が発生する可能性はあります。 ダウンタイムを最小限に抑えるために、Azure Storage はカスタマーマネージド フェールオーバーをサポートしており、部分的な停止と完全な停止のどちらであってもデータの使用可能性を維持します。
この記事では、Azure portal、PowerShell、または Azure CLI を使用して、ストレージ アカウントのアカウントのフェールオーバーを開始する方法を示します。 アカウントのフェールオーバーの詳細については、Azure ストレージ ディザスター リカバリー計画とフェールオーバーに関する記事をご覧ください。
重要
Azure Data Lake Storage Gen2 が有効になっているアカウントのカスタマーマネージド (計画外) フェールオーバーは、現在プレビュー段階であり、すべてのパブリック GRS/GZRS リージョンでサポートされています。
プレビューにオプトインする方法については、「Azure サブスクリプションでプレビュー機能を設定する」を参照してください。機能名は AllowHNSAccountFailover
を指定します。
重要
SSH ファイル転送プロトコル (SFTP) が有効になっているアカウントのお客様が管理する (計画外の) フェールオーバーは、現在プレビュー段階であり、次のリージョンでのみサポートされています。
- (アジア太平洋) インド中部
- (アジア太平洋) 東南アジア
- (ヨーロッパ) 北ヨーロッパ
- (ヨーロッパ) スイス北部
- (ヨーロッパ) スイス西部
- (ヨーロッパ) 西ヨーロッパ
- (北米) カナダ中部
- (北米)米国東部 2
- (北米) 米国中南部
プレビューにオプトインする方法については、「Azure サブスクリプションでプレビュー機能を設定する」を参照してください。機能名は AllowHNSAccountFailover
を指定します。
ベータ版、プレビュー版、または一般提供としてまだリリースされていない Azure の機能に適用される法律条項については、「Microsoft Azure プレビューの追加使用条件」を参照してください。
プライマリ リージョンに影響する重大な障害が発生した場合、Microsoft は階層型名前空間を持つアカウントのフェールオーバーを管理します。 詳細については、「Microsoft が管理するフェールオーバー」を参照してください。
前提条件
カスタマーマネージド フェールオーバーを開始する前に、ディザスター リカバリー ガイダンスの記事で詳しく説明されている重要なトピックを確認してください。
- データ損失の可能性: 計画外のストレージ アカウントのフェールオーバー時にデータ損失が発生することが予想されます。 計画外のアカウント フェールオーバーの影響とデータ損失に備える方法の詳細については、「データ損失と不整合を予測する」セクションを参照してください。
- geo 冗長: フェールオーバーを実行する前に、ストレージ アカウントが geo 冗長用に構成されている必要があります。 フェールオーバー プロセスを開始するには、プライマリ リージョンからセカンダリ リージョンへの初期同期が完了している必要があります。 アカウントが geo 冗長用に構成されていない場合は、「ストレージ アカウントがレプリケートされる方法を変更する」の記事で説明されている手順に従ってアカウントを変更できます。 Azure Storage の冗長オプションの詳細については、「Azure Storage の冗長性」の記事を参照してください。
- さまざまなアカウント フェールオーバーの概要: カスタマーマネージド フェールオーバーには 2 つの種類があります。 各種類で考えられるユース ケースとその違いについては、「フェールオーバーの計画」の記事を参照してください。
- サポートされていない機能とサービスの計画: 「サポートされていない機能とサービス」の記事を確認し、フェールオーバーを開始する前に適切なアクションを実行します。
- サポートされているストレージ アカウントの種類: ストレージ アカウントの種類を使用してフェールオーバーを開始できることを確認します。 サポートされるストレージ アカウントの種類を参照してください。
- タイミングとコストについての予想を設定する: カスタマーマネージド フェールオーバー プロセスが完了するまでにかかる時間は状況によって異なりますが、通常は 1 時間未満です。 計画外のフェールオーバーが発生すると、geo 冗長構成が失われます。 通常、geo 冗長ストレージ (GRS) の再構成には追加の時間とコストがかかります。 詳細については、「フェールオーバーの時間とコスト」セクションを参照してください。
フェールオーバーを開始する
Azure portal、PowerShell、または Azure CLI を使用して、計画または計画外のカスタマーマネージド フェールオーバーを開始できます。
注意
Azure を操作するには、Azure Az PowerShell モジュールを使用することをお勧めします。 作業を始めるには、「Azure PowerShell をインストールする」を参照してください。 Az PowerShell モジュールに移行する方法については、「AzureRM から Az への Azure PowerShell の移行」を参照してください。
Azure portal を使用してアカウント フェールオーバーを開始するには、次の手順を実行します。
ストレージ アカウントに移動します。
[データ管理] グループ内から [冗長] を選びます。 次の図では、ストレージ アカウントの geo 冗長性の構成とフェールオーバーの状態を示します。
お使いのストレージ アカウントが、geo 冗長ストレージ (GRS、RA-GRS、GZRS、RA-GZRS) 用に構成されていることを確認します。 そうでない場合は、[冗長] ドロップダウンから目的の冗長構成を選び、[保存] を選んで変更を確定します。 geo 冗長構成が変更されると、データはプライマリ リージョンからセカンダリ リージョンに同期されます。 この同期には数分かかり、すべてのデータがレプリケートされるまでフェールオーバーを開始できません。 同期が完了するまで、次のメッセージが表示されます。
次の図に示すように、[カスタマーマネージド フェールオーバーの準備] を選びます。
準備するフェールオーバーの種類を選びます。 確認ページは、選択したフェールオーバーの種類によって異なります。 以下を選択した場合
Unplanned Failover
:データ損失の可能性を警告し、フェールオーバー後に geo 冗長を手動で再構成する必要があることを知らせるアラートが表示されます。
Planned failover
(プレビュー) を選択した場合:[最終同期時刻] の値が表示されます。 すべてのデータがセカンダリ リージョンに同期されるまでフェールオーバーは発生しないため、データが失われることはありません。
計画フェールオーバーまたはフェールバック中に各リージョン内の冗長性構成は変更されないため、フェールオーバー後に geo 冗長性を手動で再構成する必要はありません。
[フェールオーバーの準備] ページを確認します。 準備ができたら、「はい」と入力し、[フェールオーバー] を選んでフェールオーバー プロセスを確認して開始します。
フェールオーバーが進行中であることを示すメッセージが表示されます。
フェールオーバーを監視する
フェールオーバーの状態は、Azure portal、PowerShell、または Azure CLI を使用して監視できます。
フェールオーバーの状態は、Azure portal の [通知]、アクティビティ ログ、ストレージ アカウントの [冗長] ページに表示されます。
通知
フェールオーバーの状態を確認するには、Azure portal のグローバル ページ ヘッダーの右端にあるベル型の通知アイコンを選びます。
アクティビティ ログ
フェールオーバーの詳細な状態を表示するには、通知の [アクティビティ ログのその他のイベント] リンクを選択するか、ストレージ アカウントの [アクティビティ ログ] ページに移動します。
冗長性ページ
ストレージ アカウントの冗長ページに、フェールオーバー状態の更新を示すメッセージが表示されます。
フェールオーバーが完了に近付いている場合、冗長性ページには元のセカンダリ リージョンが新しいプライマリとして表示されますが、フェールオーバーが進行中であることを示すメッセージが引き続き表示される場合があります。
フェールオーバーが完了すると、冗長ページに最後のフェールオーバー時刻と新しいプライマリ リージョンの場所が表示されます。 計画フェールオーバーの場合は、新しいセカンダリ リージョンも表示されます。 次の図は、計画外のフェールオーバー後の新しいストレージ アカウントの状態を示しています。
計画外のフェールオーバーの重要な影響
ストレージ アカウントの計画外のフェールオーバーを開始すると、セカンダリ エンドポイントがプライマリ エンドポイントになるように、セカンダリ エンドポイントの DNS レコードが更新されます。 フェールオーバーを開始する前に、ストレージ アカウントに対して可能性のある影響について理解しておいてください。
フェールオーバーを始める前に、可能性のあるデータ損失の範囲を見積もるには、 [最終同期時刻] プロパティを確認します。 [最終同期時刻] プロパティの詳細については、「ストレージ アカウントの最終同期時刻プロパティを確認する」を参照してください。
開始後のフェールオーバーにかかる時間は異なりますが、通常 1 時間未満です。
フェールオーバーの後、新しいプライマリ リージョンでのストレージ アカウントの種類は、ローカル冗長ストレージ (LRS) に自動的に変換されます。 アカウントに対して geo 冗長ストレージ (GRS) または読み取りアクセス geo 冗長ストレージ (RA-GRS) を再び有効にすることができます。 LRS から GRS または RA-GRS に変換すると、追加コストが発生することに注意してください。 このコストは、データを新しいセカンダリ リージョンにレプリケートするためのネットワーク エグレス料金によるものです。 詳しくは、「帯域幅の料金詳細」をご覧ください。
ストレージ アカウントの GRS を再度有効にすると、アカウント内のデータの新しいセカンダリ リージョンへのレプリケートが開始されます。 レプリケーション時間は、次のような多くの要因に依存します。
- ストレージ アカウント内のオブジェクトの数とサイズ。 数の多くい小さなオブジェクトは、数の少ない大きなオブジェクトよりも時間がかかる場合があります。
- CPU、メモリ、ディスク、WAN の容量など、バックグラウンド レプリケーションに使用できるリソース。 ライブ トラフィックは geo レプリケーションよりも優先されます。
- BLOB ストレージを使用している場合は、BLOB ごとのスナップショットの数。
- Table ストレージを使用する場合は、 データのパーティション分割戦略。 レプリケーション プロセスでは、使用するパーティション キーの数を超えて拡張することはできません。
計画外のフェールオーバーが発生すると、セカンダリ リージョンが新しいプライマリ リージョンになるため、プライマリ リージョンのすべてのデータが失われます。 プライマリ リージョンのストレージ アカウントに対して行われたすべての書き込み操作は、geo 冗長が再度有効になった後に繰り返す必要があります。 詳細については、「Azure ストレージのディザスター リカバリー計画とフェールオーバー」を参照してください。
Azure Storage リソース プロバイダーは、フェールオーバー プロセス中にフェールオーバーしません。 その結果、Azure Storage REST API の Location プロパティは、フェールオーバーの完了後も引き続き元の場所を返します。
ストレージ アカウントのフェールオーバーは、サービス停止の一時的な解決策なので、データ移行戦略の一部として使わないでください。 ストレージ アカウントを移行する方法の詳細については、「Azure Storage の移行の概要」を参照してください。