Azure SQL Managed Instance の高可用性

  • [アーティクル]

適用対象:Azure SQL Managed Instance

この記事では、Azure SQL Managed Instance での高可用性について説明します。

重要

ゾーン冗長構成は、General Purpose サービス レベルではパブリック プレビュー段階にあり、Business Critical サービス レベルでは一般提供が開始されています。

概要

Azure SQL Managed Instance の高可用性アーキテクチャの目的は、短時間のダウンタイム、サービスのメンテナンス操作、予期しない停止など、お客様が開始した管理操作によるお客様のワークロードへの影響を最小限に抑えることです。 さまざまなサービス レベルの特定の SLA について詳しくは、Azure SQL Managed Instance に関する記事をご覧ください。

高可用性により、以下への影響から保護されます。

  • データセンターを形成する可用性ゾーン (複数ゾーン リージョンの場合)
  • サービスに電源を供給するノードが実行されているラック
  • ノード自体
  • アプリケーション レイヤー

地域的または大規模な障害が発生した場合の影響を最小限に抑えるために、ビジネス継続性の概要に記載されている利用可能な手法のいずれかを使用することができます。

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

高可用性ソリューションは、コミットされたデータが障害によって失われないこと、メンテナンス操作がワークロードに影響を及ぼさないこと、そしてインスタンスがソフトウェア アーキテクチャでの単一障害点にならないことを保証するように設計されています。

サービス レベルに基づいて、2 つの異なる高可用性アーキテクチャ モデルがあります。

  • リモート ストレージ モデルは、リモート ストレージの高可用性と信頼性、および Azure Service Fabric によって管理されるコンピューティング クラスターの高可用性に依存する、General Purpose および Next-gen General Purpose サービス レベルでのコンピューティングとストレージの分離に基づいています。 この高可用性モデルでは、メンテナンス アクティビティ中に一定のパフォーマンスの低下を許容できる予算重視のビジネス アプリケーションを対象とします。
  • ローカル ストレージ モデルは、ローカル ストレージを持つ Business Critical サービス レベルの可用性データベース エンジン ノードのクォーラムに依存するデータベース エンジン プロセスのクラスターに基づいています。 このローカル ストレージ モデルは、トランザクションレートが高く、高い IO パフォーマンスを必要とするミッション クリティカルなアプリケーションを対象とします。 高可用性アーキテクチャにより、メンテナンス アクティビティ中のワークロードへのパフォーマンスへの影響を最小限に抑えることができます。

ローカル冗長可用性

ローカル冗長可用性は、計算ノードとデータをプライマリ リージョンの 1 つのデータセンター内に格納することに基づいており、小規模なネットワークや停電などのローカル障害が発生した場合にデータが保護されます。 火災や洪水などの大規模な災害がリージョン内で発生した場合、計算ノードのストレージ アカウントやデータのすべてのレプリカが失われたり、回復不能になる可能性があります。 そのため、ローカル冗長可用性オプションを使用するときにデータをさらに保護するには、データベースのバックアップに回復性の高いストレージ オプションを使用することを検討してください。

汎用のサービス階層

General Purpose サービス レベルでは、リモート ストレージの可用性アーキテクチャが使われます。 次の図は、計算レイヤーとストレージ レイヤーが分離されている4 つの異なるノードを示しています。

計算とストレージの分離を示す図。

リモート ストレージの可用性モデルには、2 つのレイヤーが含まれます。

  • ステートレス計算レイヤー。データベース エンジン プロセスが実行され、一時的なデータとキャッシュ データ (アタッチされた SSD 上の tempdb と model データベース、およびメモリ内のプラン キャッシュ、バッファー プール、列ストア プールなど) のみが含まれています。 このステートレス ノードは、データベース エンジンの初期化、ノードの正常性の制御、必要に応じた他のノードへのフェールオーバーの実行を行う Azure Service Fabric によって操作されます。
  • ステートフル データ レイヤー。データベース ファイル (.mdf および .ldf) は Azure Blob Storage に保存されています。 Azure Blob Storage には、データの可用性と冗長性の機能が組み込まれています。 ローカル冗長可用性は、データをローカル冗長ストレージ (LRS) に格納することに基づいています。これにより、プライマリ リージョンの 1 つのデータセンター内でデータが 3 回コピーされます。 データベース エンジン プロセスがクラッシュした場合でも、ログ ファイル内のすべてのレコードまたはデータ ファイル内のすべてのページが保持されることが保証されます。

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

Next-gen General Purpose サービス レベル

Note

Next-gen General Purpose サービス レベルのアップグレードは現在プレビュー段階です。

Next-gen General Purpose は、ページ BLOB ではなくマネージド ディスクにインスタンス データとログ ファイルを格納するアップグレードされたリモート ストレージ レイヤを使用する、既存の General Purpose サービス レベルへのアーキテクチャ アップグレードです。

Business Critical サービス レベル

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

データベース エンジン ノードのクラスターの図。

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

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

ゾーン冗長可用性

ゾーン冗長可用性は、プライマリ リージョンの 3 つの Azure 可用性ゾーンに計算ノードとストレージ レプリカを配置する方法に基づいています。 各可用性ゾーンは、独立した電源、冷却装置、ネットワークを備えた独立した物理的な場所です。

既定では、ローカル ストレージ可用性モデル用のノードのクラスターは、同じデータセンター内に作成されます。 Azure Availability Zones の導入により、SQL Managed Instance は、同じリージョン内の異なる可用性ゾーンに、Business Critical インスタンスの異なるレプリカを配置できます。 同様に、General Purpose サービス レベルのステートレス コンピューティング ノードは別の可用性ゾーンに配置され、ステートフル ストレージではゾーン冗長ストレージ (ZRS) 構成が使用されます。

単一障害点をなくすため、制御リングも複数のゾーンで 3 つのゲートウェイ リング (GW) として複製できます。 特定のゲートウェイ リングへのルーティングは Azure Traffic Manager (ATM) によって制御されます。 ゾーン冗長構成を選ぶことで、アプリケーション ロジックを変更しなくても、Business Critical インスタンスや General Purpose インスタンスに、データセンターの壊滅的な障害などの極めて大規模な障害に対する回復性を持たせることができます。 また、任意の既存の Business Critical インスタンスや General Purpose インスタンスを、ゾーン冗長構成に変換することもできます。

ゾーン冗長インスタンスでは、少し離れたところの異なるデータセンターにレプリカがあるため、ネットワーク待ち時間が長くなるとトランザクションのコミット時間が長くなり、一部の OLTP ワークロードのパフォーマンスに影響を及ぼす可能性があります。 いつでもゾーン冗長設定を無効にして単一ゾーン構成に戻ることができます。 このプロセスはオンライン操作であり、サービス レベルの通常の目標アップグレードと似ています。 プロセスの最後に、インスタンスは、ゾーン冗長リングから単一ゾーン リングに (またはその逆に) 移行されます。

ゾーン冗長による高可用性アーキテクチャを、次の図に示します。

ゾーン冗長高可用性アーキテクチャの図。

ゾーン冗長を使うときは、次の点を考慮してください。

Business Critical インスタンスでサポートされているリージョン

Business Critical SQL Managed Instance のゾーン冗長は、次のリージョンでサポートされています。

アメリカ ヨーロッパ 中東 アフリカ アジア太平洋
ブラジル南部 フランス中部 カタール中部 南アフリカ北部 オーストラリア東部
カナダ中部 イタリア北部 イスラエル中部 インド中部
米国中部 ドイツ中西部 東日本
米国東部 ノルウェー東部 韓国中部
米国東部 2 北ヨーロッパ 東南アジア
米国中南部 英国南部 東アジア
米国西部 2 スウェーデン中部
米国西部 3 スイス北部
ポーランド中部

General Purpose インスタンスでサポートされているリージョン

Note

ゾーン冗長構成は、General Purpose サービス レベルのパブリック プレビューにあります。

アメリカ ヨーロッパ 中東 アフリカ アジア太平洋
ブラジル南部 フランス中部 カタール中部 南アフリカ北部 オーストラリア東部
米国東部 イタリア北部 イスラエル中部 インド中部
米国東部 2 ドイツ中西部 東日本
米国中南部 ノルウェー東部 韓国中部
米国西部 2 北ヨーロッパ 東南アジア
米国西部 3 英国南部 東アジア
スウェーデン中部
スイス北部
ポーランド中部

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

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

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

PowerShell REST API Azure CLI
Invoke-AzSqlInstanceFailover SQL Managed Instance - フェールオーバー Azure CLI から REST API 呼び出しを呼び出すために az sql mi failover が使用できます

まとめ

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

次のステップ