冗長性による可用性 - Azure SQL Database

適用対象:Azure SQL DatabaseFabric の SQL データベース

この記事では、ローカル冗長により可用性を、ゾーン冗長により高可用性を実現する、Azure SQL Database および Microsoft Fabric の SQL Database のアーキテクチャについて解説します。

Overview

Azure SQL Database と Microsoft Fabric 内の SQL データベースは、適用可能なすべてのパッチが適用された Windows オペレーティング システム上で稼働しており、使用されているのは SQL Server データベース エンジンの最新の安定バージョンです。 SQL Database では、修正プログラムの適用、バックアップ、Windows や SQL エンジンのアップグレードなどの重要なサービス タスクや、計画外のイベント (ハードウェア、ソフトウェア、ネットワークの根本的な障害など) が自動的に処理されます。 SQL Database のデータベースまたはエラスティック プールに修正プログラムが適用またはフェールオーバーされた場合、アプリで 再試行ロジックを使用 する場合、ダウンタイムは影響を受けません。 SQL Database は、クリティカルな状況であっても迅速な復旧が可能であるため、データが常に使用可能であることが保証されます。 ほとんどのユーザーは、アップグレードが継続的に実行されていることに気付きません。

既定では、Azure SQL Database はローカル冗長性を通じて 可用性 を実現し、次のような中断がデータベースで処理されるようにします。

• 顧客が開始した管理操作で発生する短いダウンタイム
• サービス メンテナンス操作
• 以下に関する問題:
  • サービスを支えるマシンが設置されているラック
  • SQL データベース エンジンを実行している物理マシン
• SQL データベース エンジンに関するその他の問題
• その他、発生する可能性がある計画外のローカル障害

既定の可用性ソリューションは、障害が原因でコミットされたデータが失われないようにし、メンテナンス操作がワークロードへの影響を最小限に抑え、データベースがソフトウェア アーキテクチャの単一障害点にならないように設計されています。

ただし、ゾーン全体が停止した場合のデータへの影響を最小限に抑えるために、ゾーンの冗長性を有効にすることで 高可用性 を実現できます。 ゾーンの冗長性がない場合、フェールオーバーは同じデータ センター内でローカルに実行されるため、障害が解決されるまでデータベースが使用できなくなる可能性があります。復旧する唯一の方法は、 アクティブ geo レプリケーションによる geo フェールオーバー、 フェールオーバー グループ、geo 冗長バックアップの geo リストア などのディザスター リカバリー ソリューションを使用することです。 詳細については、 ビジネス継続性の概要を確認してください。

高可用性アーキテクチャ モデルには、次の 3 つがあります。

• コンピューティングとストレージの分離に基づくリモート ストレージ モデル。 リモート ストレージ モデルは、リモート ストレージ層の可用性と信頼性に依存します。 このアーキテクチャでは、メンテナンス作業中に一定のパフォーマンス低下を許容できる予算重視のビジネス アプリケーションを対象とします。
• データベース エンジン プロセスのクラスターに基づくローカル ストレージ モデル。 ローカル ストレージ モデルは、使用可能なデータベース エンジン ノードのクォーラムが常に存在するという事実に依存します。 このアーキテクチャは、高い IO パフォーマンス、高いトランザクション レートを備えたミッション クリティカルなアプリケーションを対象とし、メンテナンス作業中のワークロードに対するパフォーマンスの影響を最小限に抑えることを保証します。
• コンピューティング ノード、ページ サーバー、ログ サービス、永続ストレージなどの高可用性コンポーネントの分散システムを使用するハイパースケール モデル。 ハイパースケール データベースをサポートする各コンポーネントは、障害に対する独自の冗長性と回復性を持ちます。 計算ノード、ページ サーバー、ログ サービスが Azure Service Fabric で実行されることで、各コンポーネントの正常性が制御され、必要に応じて使用できる正常なノードへのフェールオーバーが行われます。 永続ストレージでは、ネイティブの高可用性と冗長性の機能を備えた Azure Storage が使用されます。 詳細については、 Hyperscale アーキテクチャに関するページを参照してください。

SQL Database では、3 つの可用性モデルのそれぞれで、ローカル冗長性とゾーン冗長オプションがサポートされています。 ローカル冗長は、データセンター内部での障害に対する復元力 (耐障害性) を提供します。一方、ゾーン冗長は、リージョン内の可用性ゾーンに障害が発生した場合にもサービスを継続できるようにすることで、さらなる耐障害性を実現します。

次の表は、サービス レベルに基づく可用性オプションを示しています。

さまざまなサービス レベルの特定の SLA の詳細については、 Azure SQL Database の SLA を確認してください。

ローカル冗長により実現される可用性

ローカル冗長可用性は、プライマリ リージョンの 1 つのデータセンター内にデータを 3 回コピーし、小規模なネットワークや電源障害などのローカル障害が発生した場合にデータを保護する ローカル冗長ストレージ (LRS) へのデータベースの格納に基づいています。 LRS は、コストが最も安い冗長オプションであり、他のオプションと比較して持続性は最も低くなります。 リージョン内で火災や洪水などの大規模な災害が発生した場合、LRS を使用しているストレージ アカウントのすべてのレプリカが失われたり、回復不能になったりする可能性があります。 そのため、ローカル冗長可用性オプションを使用するときにデータをさらに保護するには、 データベース バックアップに回復性の高いストレージ オプションを使用することを検討してください。 このようなリスクは、ハイパースケール データベースには当てはまりません。ハイパースケールでは、データ ファイルとバックアップの両方に同じストレージが使用されているためです。

ローカル冗長可用性は、プライマリ リージョンの 1 つのデータセンター内にデータを 3 回コピーし、小規模なネットワークや電源障害などのローカル障害が発生した場合にデータを保護する ローカル冗長ストレージ (LRS) へのデータベースの格納に基づいています。 LRS は、コストが最も安い冗長オプションであり、他のオプションと比較して持続性は最も低くなります。 リージョン内で火災や洪水などの大規模な災害が発生した場合、LRS を使用しているストレージ アカウントのすべてのレプリカが失われたり、回復不能になったりする可能性があります。 そのため、ローカル冗長可用性オプションを使用するときにデータをさらに保護するには、 データベース バックアップに回復性の高いストレージ オプションを使用することを検討してください。 このようなリスクは、ハイパースケール データベースには当てはまりません。ハイパースケールでは、データ ファイルとバックアップの両方に同じストレージが使用されているためです。

ローカル冗長可用性は、すべてのサービス レベルのすべてのデータベースで利用可能であり、データ損失がゼロであることを示す回復ポイント目標 (RPO) を満たしています。

Basic、Standard、General Purpose サービス レベル

DTU ベースの購入モデルの Basic サービス レベルと Standard サービス レベルの概要と、仮想コアベースの購入モデルの General Purpose サービス レベルでは、サーバーレスコンピューティングとプロビジョニング済みコンピューティングの両方にリモート ストレージ可用性モデルが使用されます。 次の図は、分離されたコンピューティング レイヤーとストレージ レイヤーを持つノードを示しています。

リモート記憶域可用性モデルには、次の 2 つのレイヤーがあります。

• ステートレス コンピューティング レイヤーは、データベース エンジン プロセスを実行し、アタッチされた SSD 上の tempdb や model データベース、メモリ内のプラン キャッシュ、バッファー プール、列ストア プールなどの一時的なデータとキャッシュ データのみが含まれています。 このステートレス ノードは、データベース エンジンの初期化、ノードの正常性の制御、他のノードへのフェールオーバーを必要に応じて実行する Azure Service Fabric によって操作されます。

• ステートフル データ レイヤー。データベース ファイル (.mdf および .ldf) は Azure Blob Storage に保存されています。 Azure Blob Storage には、ビルトインのデータ可用性と冗長性の機能があります。 データベース エンジン プロセスがクラッシュした場合でも、ログ ファイル内のすべてのレコードやデータ ファイル内のすべてのページが保持されることを保証します。

データベース エンジンまたはオペレーティング システムがアップグレードされたとき、または障害が検出されるたびに、Azure Service Fabric はステートレス データベース エンジン プロセスを、十分な空き容量を持つ別のステートレス コンピューティング ノードに移動します。 Azure Blob Storage 内のデータは移行による影響を受けず、データ/ログ ファイルは、新しく初期化された データベース エンジン プロセスにアタッチされます。 このプロセスでは高可用性が保証されますが、新しいデータベース エンジン プロセスがコールド キャッシュ状態で起動するため、移行中に高負荷なワークロードでは一時的にパフォーマンスが低下することがあります。

Premium、Business Critical サービス レベル

DTU ベースの購入モデルの Premium サービス レベルと仮想コアベースの購入モデルの Business Critical サービス レベルでは、コンピューティング リソース (データベース エンジン プロセス) とストレージ (ローカルに接続された SSD) を 1 つのノードに統合するローカル ストレージ可用性モデルが使用されます。 高可用性は、追加ノードにコンピューティングとストレージの両方をレプリケートすることで実現されます。

基になるデータベース ファイル (.mdf/.ldf) は、非常に低い待機時間の IO をワークロードに提供するために、アタッチされている SSD ストレージ上に配置されています。 高可用性は、SQL Server Always On 可用性グループと同様のテクノロジを使用して実装されます。 クラスターには、読み取り/書き込みの顧客ワークロードにアクセス可能な単一のプライマリ レプリカと、データのコピーを格納する最大 3 つのセカンダリ レプリカ (計算とストレージ) が含まれます。 プライマリ レプリカは常にセカンダリ レプリカへ順番に変更をプッシュし、各トランザクションをコミットする前に、十分な数のセカンダリ レプリカにデータが保持されるようにします。 このプロセスにより、プライマリ レプリカまたは読み取り可能なセカンダリ レプリカが何らかの理由でクラッシュしても、常にフェールオーバー可能な完全に同期されたレプリカが存在することが保証されます。 フェールオーバーは、Azure Service Fabric によって開始されます。 セカンダリ レプリカが新しいプライマリ レプリカになると、クォーラムを維持するのに十分な数のレプリカがクラスターに確保されるように、別のセカンダリ レプリカが作成されます。 フェールオーバーが完了すると、Azure SQL 接続は新しいプライマリ レプリカまたは読み取り可能なセカンダリ レプリカに自動的にリダイレクトされます。

その他の利点としては、ローカル記憶域可用性モデルには、セカンダリ レプリカの 1 つに読み取り専用の Azure SQL 接続をリダイレクトする機能が含まれています。 この機能は 、読み取りスケールアウトと呼ばれます。プライマリ レプリカから、分析ワークロードなどの読み取り専用操作をオフロードするために、100% 追加のコンピューティング容量を追加料金なしで提供します。

ハイパースケール サービス レベル

Hyperscale サービス レベルのアーキテクチャについては、詳細な図を含む 分散関数アーキテクチャで説明されています。

ハイパースケールの可用性モデルには、次の 4 つのレイヤーが含まれます。

• ステートレスな計算レイヤーは、データベース エンジンのプロセスを実行し、一時的なデータやキャッシュされたデータのみを保持するレイヤーです。具体的には、一部データのみを対象とする RBPEX キャッシュtempdb、model接続された SSD 上のデータベースやその他の一時的データ、メモリ内のプラン キャッシュ、バッファ プール、列ストア プールなどが含まれます。 このステートレス レイヤーには、プライマリ計算レプリカと、必要に応じて、フェールオーバー ターゲットとして機能できる多くのセカンダリ計算レプリカが含まれています。

• ページ サーバーによって形成されるステートレス ストレージ レイヤー。 このレイヤーは、計算レプリカで実行されているデータベース エンジン プロセス用の分散ストレージ エンジンです。 各ページ サーバーには、アタッチされた SSD 上のカバーする RBPEX キャッシュ、メモリにキャッシュされたデータ ページなど、一時的なデータとキャッシュされたデータのみが含まれます。 各ページ サーバーでは、負荷分散、冗長性、高可用性を提供するためのアクティブ/アクティブ構成にペアのページ サーバーがあります。

• ステートフルなトランザクション ログのストレージ レイヤー。ログ サービス プロセス、トランザクション ログのランディング ゾーン、およびトランザクション ログの長期保存を実行する計算ノードによって形成されます。 ランディング ゾーンと長期ストレージでは、トランザクション ログの可用性と 冗長性 を提供する Azure Storage が使用され、コミットされたトランザクションのデータの持続性が確保されます。

• ステートフルなデータ ストレージ レイヤー。Azure Storage に格納され、ページ サーバーによって更新される、データベース ファイル (.mdf/.ndf) が含まれます。 このレイヤーでは、Azure Storage のデータの可用性と冗長性の機能 を 使用します。 これにより、ハイパースケール アーキテクチャの他のレイヤーのプロセスがクラッシュした場合や、計算ノードで障害が発生した場合でも、データ ファイル内のすべてのページが保持されることが保証されます。

すべてのハイパースケール レイヤー内の計算ノードは、Azure Service Fabric で実行されます。これにより、各ノードの正常性が制御され、必要に応じて使用できる正常なノードへのフェールオーバーが行われます。

Hyperscale での高可用性の詳細については、「Hyperscale での データベースの高可用性」を参照してください。

ゾーン冗長による高可用性

ゾーン冗長デプロイの場合、Azure SQL Database では、特定のリージョン (2 つ以上の一般的な 3 つ) の Azure 可用性ゾーンの数が使用されます。 コンピューティングおよびストレージ コンポーネントは、Azure SQL によって選択された 2 つまたは 3 つのゾーンにまたがり、最適な回復性を実現するために、独立した電源、冷却、ネットワークを備えた別々の物理的な場所に配置されます。 Azure SQL では、リージョンの可用性とサービスの最適化に基づいてゾーンの数が自動的に選択されます。 デプロイでは、回復性のために必要なゾーン数より少ない数のゾーンを使用することはありません。

ゾーン冗長可用性は、 仮想コアベースの購入モデルの Business Critical、General Purpose、Hyperscale サービス レベルのデータベースで使用でき、 DTU ベースの購入モデル の Premium サービス レベルでのみ使用できます。Basic サービス レベルと Standard サービス レベルでは、ゾーンの冗長性はサポートされません。

各サービス レベルではゾーン冗長性が異なる方法で実装されますが、すべての実装では、Azure リージョン内の単一の可用性ゾーンが使用できなくなった場合に、フェールオーバー時にコミットされたデータが失われることのない復旧ポイント目標 (RPO) が保証されます。

Azure SQL では、デプロイに合わせてゾーンの配置が自動的に最適化されます。 2 つまたは 3 つのゾーンを使用するすべての可用性ゾーン構成では、同じ高可用性 SLA と回復性の保証が提供されます。

General Purpose サービス レベル

General Purpose サービス レベルのゾーン冗長構成は、仮想コア購入モデルでサーバーレスとプロビジョニング済みの両方のコンピューティングに提供されます。 この構成では、 Azure Availability Zones を使用して、Azure リージョン内の複数の物理的な場所にデータベースをレプリケートします。 ゾーン冗長を選択することで、アプリケーション ロジックを変更することなく、データセンターの壊滅的な障害などの大規模な障害に対する回復性を、新規および既存のサーバーレスおよびプロビジョニング済みの汎用単一データベースやエラスティック プールに持たせることができます。

General Purpose レベル向けのゾーン冗長構成には、次の 2 つの層があります。

• ZRS (ゾーン冗長ストレージ) に格納されているデータベース ファイル (.mdf/.ldf) を含むステートフル データ レイヤー。 ZRS を使用すると、データ ファイルとログ ファイルは、プライマリ リージョン内の複数の Azure 可用性ゾーンに同期的にコピーされます。 これは、最適な回復性を実現するために Azure SQL によって選択された 2 つまたは 3 つのゾーンにまたがって配置されます。
• ステートレス計算レイヤー。sqlservr.exe プロセスを実行しており、一時的なデータとキャッシュ データのみ (tempdb、アタッチされた SSD 上の model データベース、およびメモリ内のプラン キャッシュ、バッファー プール、列ストア プールなど) が含まれています。 このステートレス ノードは、sqlservr.exe の初期化、ノードの正常性の制御、および他のノードへのフェールオーバーを必要に応じて実行する Azure Service Fabric によって操作されます。 ゾーン冗長のサーバーレスおよびプロビジョニング済み General Purpose データベースの場合、予備の容量があるノードをフェールオーバーのために他の Availability Zones ですぐに使用できます。

General Purpose サービス レベルの高可用性アーキテクチャのゾーン冗長バージョンを、2 ゾーンリージョンまたは 3 ゾーン リージョンの次の図に示します。

2ゾーン領域	3 ゾーン領域

• コンピューティングが 2 つの可用性ゾーンにプロビジョニングされている場合:

  • バックアップとストレージは、リージョン内の 3 つの可用性ゾーン間で同期されます。
  • ゾーン冗長ストレージは、常に 3 つの可用性ゾーン間で同期されます。

• コンピューティングが 3 つの可用性ゾーンにプロビジョニングされている場合:

  • バックアップとストレージは、リージョン内の 3 つの可用性ゾーン間で同期されます。

• 可用性ゾーンを持つすべての Azure リージョンでは ゾーン冗長の General データベースがサポートされます。

• ゾーン冗長可用性の場合、既定以外の メンテナンス期間 の選択は、現在、一部のリージョンで使用できます。 詳細については、「 Azure SQL Database のリージョン別のメンテナンス期間の可用性」を参照してください。

• ゾーン冗長は、DTU 購入モデルの Basic と Standard のサービス レベルでは使用できません。

Premium および Business Critical サービス レベル

Premium または Business Critical サービス レベルでゾーン冗長が有効になっている場合、レプリカは同じリージョン内の異なる可用性ゾーンに配置されます。 単一障害点をなくすため、制御リングも複数のゾーンで 3 つのゲートウェイ リング (GW) として複製できます。 特定のゲートウェイ リングへのルーティングは、 Azure Traffic Manager によって制御されます。 Premium または Business Critical サービス レベルでは、既存のレプリカを使用して異なる可用性ゾーンに分散配置することでゾーン冗長構成を実現してるため、追加料金なしで有効にすることができます。 ゾーン冗長構成を選択すると、アプリケーション ロジックを変更することなく、データセンターの壊滅的な障害などの大規模な障害に対するエラスティック プールの回復性を、Premium または Business Critical のデータベースに持たせることができます。 また、既存の Premium または Business Critical のデータベースやエラスティック プールをゾーン冗長構成に変換することもできます。

Business Critical サービス レベルの高可用性アーキテクチャのゾーン冗長バージョンを、2 ゾーンリージョンまたは 3 ゾーン リージョンの次の図に示します。

2ゾーン領域	3 ゾーン領域

• コンピューティングが 2 つの可用性ゾーンにプロビジョニングされている場合:

  • Business Critical ストレージの場合、データ ファイルとログ ファイルのローカル冗長可用性ストレージは、2 つの可用性ゾーン間で同期されます。
  • その他のレベルでは、バックアップとストレージはリージョン内の 3 つの可用性ゾーン間で同期されます。
  • ゾーン冗長ストレージは、常に 3 つの可用性ゾーン間で同期されます。

• コンピューティングが 3 つの可用性ゾーンにプロビジョニングされている場合:

  • Business Critical ストレージの場合、データ ファイルとログ ファイルのローカル冗長可用性ストレージは、3 つの可用性ゾーン間で同期されます。
  • その他のレベルでは、バックアップとストレージはリージョン内の 3 つの可用性ゾーン間で同期されます。

ゾーン冗長を使用して Premium または Business Critical データベースを構成する際、次の点を考慮してください。

• 可用性ゾーンのあるすべての Azure リージョンは、ゾーン冗長 Premium データベースと Business Critical データベースをサポートします。
• ゾーン冗長可用性の場合、既定以外の メンテナンス期間 の選択は、現在、一部のリージョンで使用できます。 詳細については、「 Azure SQL Database のリージョン別のメンテナンス期間の可用性」を参照してください。

ハイパースケール サービス レベル

ハイパースケール サービス レベルでは、データベースのゾーン冗長を構成できます。 詳細については、「 ゾーン冗長ハイパースケール データベースの作成」を参照してください。

この構成を有効にすると、すべてのハイパースケール レイヤーににおける Availability Zones 間のレプリケーションを通じて、ゾーン レベルの回復性が確保されます。 ゾーン冗長を選択することにより、アプリケーション ロジックを変更することなく、データセンターの壊滅的な障害など、大規模な障害に対する ハイパースケール データベースの回復性を高めることができます。

ゾーン冗長可用性は、ハイパースケール スタンドアロン データベースおよびハイパースケール エラスティック プールの両方でサポートされています。 詳細については、 Azure SQL Database のハイパースケール エラスティック プールの概要に関するページを参照してください。

次の図は、2 ゾーンリージョンまたは 3 ゾーン リージョンのゾーン冗長ハイパースケール データベースの基になるアーキテクチャを示しています。

2ゾーン領域	3 ゾーン領域

• コンピューティングが 2 つの可用性ゾーンにプロビジョニングされている場合:

  • バックアップとストレージは、リージョン内の 3 つの可用性ゾーン間で同期されます。
  • ゾーン冗長ストレージは、常に 3 つの可用性ゾーン間で同期されます。

• コンピューティングが 3 つの可用性ゾーンにプロビジョニングされている場合:

  • バックアップとストレージは、リージョン内の 3 つの可用性ゾーン間で同期されます。

次の制限が適用されます。

• 可用性ゾーンをサポートしているすべての Azure リージョンでは、ゾーン冗長 Hyperscale データベースがサポートされています。

  • Hyperscale Premium シリーズおよびメモリ最適化 Premium シリーズ ハードウェアの場合、ゾーン冗長性は特定のリージョンで利用できます。 詳細については、 Azure SQL Database のリージョン別の Hyperscale Premium シリーズの可用性に関するページを参照してください。

• ゾーン冗長構成は、データベースの作成時にのみ指定できます。 この設定は、リソースがプロビジョニングされた後は変更できません。 既存の Hyperscale データベースのゾーン冗長構成を更新するには、 データベース のコピー、 ポイントインタイム リストア、 または geo レプリカ の作成を使用します。 これらの更新オプションのいずれかを使用する場合、ターゲット データベースがソースとは異なるリージョンにある場合、またはターゲットからのデータベース バックアップ ストレージの冗長性がソース データベースと異なる場合、 コピー操作 はデータ操作のサイズになります。

• ゾーン冗長可用性の場合、既定以外の メンテナンス期間 の選択は、現在、一部のリージョンで使用できます。 詳細については、「 Azure SQL Database のリージョン別のメンテナンス期間の可用性」を参照してください。

• 現在、Azure portal を使用してデータベースをハイパースケールに移行する際に、ゾーン冗長を指定する方法はありません。 ただし、既存のデータベースを別の Azure SQL データベースサービス レベルからハイパースケールに移行する際に、Azure PowerShell、Azure CLI、REST API を使用してゾーン冗長を指定することはできます。 Azure CLI の例を次に示します。

  az sql db update --resource-group "myRG" --server "myServer" --name "myDB" --edition Hyperscale --zone-redundant true`
  

• Hyperscale のゾーン冗長構成を有効にするには、少なくとも 1 つの高可用性コンピューティング レプリカとゾーン冗長または geo ゾーン冗長バックアップ ストレージの使用が必要です。

データベースのゾーン冗長可用性

Azure SQL Database では、 サーバー は、データベースのコレクションの中央管理ポイントとして機能する論理コンストラクトです。 サーバー レベルでは、ログイン、認証方法、ファイアウォール規則、監査規則、脅威検出ポリシー、自動フェールオーバー グループを管理できます。 ログインやファイアウォール規則など、これらの機能の一部に関連するデータは、master データベースに格納されます。 同様に、 sys.resource_statsなどの一部の DMV のデータも、 master データベースに格納されます。

ゾーン冗長構成のデータベースが論理サーバーに作成されると、サーバーに関連付けられている master データベースも自動的にゾーン冗長になります。 これにより、ゾーンの障害が発生しても、ログインやファイアウォール規則などの master データベースに依存する機能は引き続き使用できるため、データベースを使用するアプリケーションは影響を受けなくなります。 master データベースをゾーン冗長にするのは非同期プロセスであり、バックグラウンドで完了するまでに時間がかかります。

サーバー上のどのデータベースもゾーン冗長でない場合、または空のサーバーを作成する場合、サーバーに関連付けられている master データベースは ゾーン冗長ではありません。 ゾーン冗長性を使用するように Azure SQL Database を移行するには、「 Azure SQL Database を可用性ゾーンのサポートに移行する」の手順に従います。

ZoneRedundant データベースの master プロパティを確認するには、「Azure SQL Database 可用性ゾーンの状態を検証する」の Azure PowerShell または Azure CLI または REST API の手順を使用します。

アプリケーションの障害回復性のテスト

高可用性は、データベース アプリケーションに対して透過的に機能する Azure SQL データベースプラットフォームの基礎となる部分です。 しかし、計画済みまたは計画外のイベント時に開始された自動フェールオーバー操作がアプリケーションにどのような影響を与えるかを、運用環境にデプロイする前にテストしておきたいと考える方もいらっしゃることは、私たちも理解しています。 特別な API を呼び出してデータベースやエラスティック プールを再起動することにより、手動でフェールオーバーをトリガーできます。 ゾーン冗長のサーバーレスまたはプロビジョニング済み General Purpose データベースまたはエラスティック プールの場合、API 呼び出しによって、クライアント接続が、古いプライマリのAvailability Zonesとは異なるAvailability Zones内の新しいプライマリにリダイレクトされます。 そのため、フェールオーバーが既存のデータベース セッションにどのように影響するかをテストするだけでなく、ネットワーク待機時間の変化によってエンドツーエンドのパフォーマンスを変化させるかどうかを確認することもできます。 再起動操作は侵入的なもので、大量に行うとプラットフォームに負荷をかける可能性があるため、各データベースまたはエラスティック プールに対しては、15 分ごとに 1 つのフェールオーバー呼び出しのみが許可されます。

Azure SQL Database の高可用性とディザスター リカバリーの詳細については、 高可用性とディザスター リカバリーのチェックリスト (Azure SQL Database) を確認してください。

フェールオーバーは、PowerShell、REST API または Azure CLI を使用して開始できます。

Conclusion

Azure SQL データベースの特徴は、Azure プラットフォームと緊密に統合される、ビルトインの高可用性ソリューションです。 障害の検出と復旧に Service Fabric を、データ保護に Azure Blob ストレージを、フォールト トレランスを高めるために Availability Zones を活用しています。 さらに、SQL データベースでは、データ同期とフェールオーバーのために、SQL Server から Always On 可用性グループのテクノロジーを活用しています。 これらのテクノロジを組み合わせることで、アプリケーションでは混合ストレージ モデルを最大限に活用して、高要件の SLA にも対応できます。

次のステップ

関連コンテンツ

• Azure Availability Zones
• Service Fabric
• Azure Traffic Manager
• Azure SQL Database でのビジネス継続性