適用対象:
Azure SQL Managed Instance
この記事では、ローカル冗長性による可用性とゾーン冗長による高可用性を実現する Azure SQL Managed Instance のアーキテクチャについて説明します。
概要
SQL Managed Instance は、適用可能なすべてのパッチが適用された Windows オペレーティング システム上の SQL Server データベース エンジンの最新の安定バージョンで実行されます。 SQL Managed Instance は、パッチの適用、バックアップ、Windows と SQL データベース エンジンのアップグレードなどの重要なサービス タスク、および基になるハードウェア、ソフトウェア、またはネットワークのエラーなどの計画外のイベントを、自動的に処理します。 アプリで再試行ロジックが使用されている場合、インスタンスのパッチ適用やフェールオーバーのときのダウンタイムによる大きな影響はありません。 SQL Managed Instance は、クリティカルな状況であっても迅速な復旧が可能であるため、データが常に使用可能であることが保証されます。 ほとんどのユーザーは、アップグレードが継続的に実行されていることに気付きません。
既定では、Azure SQL Managed Instance はローカル冗長性によって 可用性 を実現し、インスタンスが次のような中断を確実に処理できるようにします。
- お客様が開始した管理操作によって短時間のダウンタイムが発生する
- サービス保守作業
- 以下に関する問題およびデータ センターの障害:
- サービスを支えるマシンが稼働しているラック。
- SQL データベース エンジンを実行する VM をホストする物理マシン
- SQL データベース エンジンを実行する仮想マシン
- SQL データベース エンジンに関するその他の問題
- その他の、発生する可能性がある計画外のローカル障害
既定の可用性ソリューションは、障害が原因でコミットされたデータが失われないようにし、メンテナンス操作がワークロードへの影響を最小限に抑え、インスタンスがソフトウェア アーキテクチャの単一障害点にならないように設計されています。
ただし、ゾーン全体の障害発生時にデータへの影響を最小限に抑えるために、ゾーン冗長を有効にすると、高可用性を実現できます。 ゾーン冗長がない場合、フェールオーバーは同じデータ センター内でローカルに実行されるため、障害が解決されるまでインスタンスが使用できなくなる可能性があります。フェールオーバー グループ、geo 冗長バックアップの geo リストアなどの、ディザスター リカバリー ソリューションを使用しなければ復元できません。 詳細については、「ビジネス継続性の概要」を確認してください。
高可用性により、次に関する影響からユーザーを保護することで、サービスの信頼性が向上します。
- データ センターを形成する可用性ゾーン
サービス レベルに基づいて、2 つの異なる可用性アーキテクチャ モデルがあります。
- リモート ストレージ モデルは、リモート ストレージの可用性と信頼性、および Azure Service Fabric によって管理されるコンピューティング クラスターの可用性に依存する、General Purpose および Next-gen General Purpose サービス レベルでのコンピューティングとストレージの分離に基づいています。 この可用性モデルでは、メンテナンス アクティビティ中に一定のパフォーマンスの低下を許容できる予算重視のビジネス アプリケーションを対象とします。
- ローカル ストレージ モデルは、ローカル ストレージを持つ Business Critical サービス レベルの可用性データベース エンジン ノードのクォーラムに依存するデータベース エンジン プロセスのクラスターに基づいています。 このローカル ストレージ モデルは、トランザクションレートが高く、高い IO パフォーマンスを必要とするミッション クリティカルなアプリケーションを対象とします。 高可用性アーキテクチャにより、メンテナンス アクティビティ中のワークロードへのパフォーマンスへの影響を最小限に抑えることができます。
さまざまなサービス レベルの特定の SLA について詳しくは、「Azure SQL Managed Instance のSLA」を確認してください。
ローカル冗長性による可用性
ローカル冗長可用性は、計算ノードとデータをプライマリ リージョンの 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 内のデータは移動による影響を受けず、データとログ ファイルは、新しく初期化されたデータベース エンジン プロセスにアタッチされます。 このプロセスにより高い可用性が保証されますが、新しいデータベース エンジン プロセスはコールド キャッシュを使って起動されるため、負荷の高いワークロードでは移行の間にパフォーマンスが低下する可能性があります。
次世代 General Purpose サービス階層
次世代のGeneral Purposeは、既存のGeneral Purpose Service Tierへのアーキテクチャ的なアップグレードであり、アップグレードされたリモートストレージレイヤーを使ってインスタンスデータやログファイルを Elastic SAN 上で保存し、ページブローブの代わりに使われます。
次世代汎用サービス層のゾーン冗長性は現在プレビュー段階です。 プレビューはまた、プレミアムシリーズハードウェア上のゾーン冗長インスタンス向けの 柔軟なメモリ もサポートしています。
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 は、同じリージョン内の異なる可用性ゾーンに複数のレプリカを配置します。 単一障害点をなくすため、制御リングも複数のゾーンで複製されます。 その後コントロール プレーン トラフィックは、可用性ゾーン間にもデプロイされるロード バランサーにルーティングされます。 コントロール プレーンからロード バランサーへのトラフィック ルーティングは、Azure Traffic Manager (ATM) によって制御されます。
ゾーン冗長化構成を使用することで、ビジネスクリティカル、ジェネラルパーソナル、次世代ジェネラルパーパスインスタンスを、アプリケーションロジックを変更することなく、壊滅的なデータセンター障害を含むはるかに多数の障害に対して耐性を持つようにできます。 既存のインスタンスをゾーン冗長構成に変換できます。 次世代汎用サービス層のゾーン冗長性は現在プレビュー段階です。
ゾーン冗長インスタンスは異なるデータセンターにレプリカを持ち、それらの間には一定の距離があるため、ネットワーク遅延の増加はトランザクションコミット時間を増加させ、一部のOLTPワークロードのパフォーマンスに影響を与える可能性があります。 いつでもゾーン冗長設定を無効にして単一ゾーン構成に戻ることができます。 このプロセスはオンライン操作であり、サービス レベルの通常の目標アップグレードと似ています。 プロセスの最後に、インスタンスは、ゾーン冗長リングから単一ゾーン リングに (またはその逆に) 移行されます。
SQL Managed Instance のゾーン冗長の使用を開始するには、「ゾーン冗長の構成」を確認してください。 Azure SQL Managed Instance の リージョン別のゾーン冗長性の可用性 を確認します。
汎用のサービス階層
General Purpose サービス レベルでは、ステートレス コンピューティング ノードを異なる可用性ゾーンに配置することでゾーン冗長性が実現されます。また、現在アクティブな SQL データベース エンジン プロセスを含むノードにアタッチされているステートフル ゾーン冗長ストレージ (ZRS) に依存することになります。 障害が発生した場合、SQL データベース エンジン プロセスはステートレス ノードの 1 つでアクティブになり、ステートフル ストレージ内のデータにアクセスします。
次の図は、General Purpose サービス レベルのゾーン冗長アーキテクチャを示しています。
次世代 General Purpose サービス階層
次世代汎用サービス層のゾーン冗長性は現在プレビュー段階です。 ゾーン冗長構成はサービスコンポーネントを可用性ゾーン間で分散させ、アップグレードされたElastic SANリモートストレージ層を使用します。 プレビューはプレミアムシリーズのハードウェアで柔軟なメモリをサポートしており、vCoreの数に関係なくメモリを調整できます。
Business Critical サービス レベル
Business Critical サービス レベルでは、コンピューティング レプリカとストレージ レプリカを異なる可用性ゾーンに配置し、基になる Always On 可用性グループ テクノロジを使用して、プライマリ インスタンスから他の可用性ゾーンのスタンバイ レプリカへのデータ変更をレプリケートすることで、ゾーン冗長を実現します。 障害が発生した場合、スタンバイ レプリカの 1 つをプライマリにシームレスに移行する自動フェールオーバーが発生します。
次の図は、Business Critical サービス レベルのゾーン冗長アーキテクチャを示しています。
アプリケーションの障害回復性のテスト
可用性は、データベース アプリケーションに対して透過的に機能する、SQL Managed Instance プラットフォームの基礎となる部分です。 ただし、本番環境に展開する前に、計画的または予期せぬイベント中に開始される自動フェイルオーバー操作がアプリケーションにどのような影響を与えるかをテストしたいと認識しています。 特別な API を呼び出して Managed Instance を再起動することにより、フェールオーバーを手動でトリガーできます。 再起動は負荷のかかる操作であり、数が多いとプラットフォームに負荷をかける可能性があるため、各マネージド インスタンスに対しては、15 分ごとに 1 つのフェールオーバー呼び出しのみが許可されます。
実際のフェールオーバー中、SQL サービスが別のノードでプライマリになる間には、インスタンスへの接続は失敗します。 フェールオーバーをシミュレートするには、SQL プロセスを再起動するコマンドを呼び出して、フェールオーバーがあった状態を模倣するサービスの開始をシミュレートします。 ただし、実際のフェールオーバーと比較して、実際のフェールオーバーの間に接続が長時間失敗する可能性があります。これは、実際のフェールオーバー中に、SQL プロセスがクラスター内の別の仮想マシン (ローカルまたはゾーン冗長が有効な場合は別のゾーン) のプライマリになり、シミュレートされたフェールオーバー中は既存の仮想マシンで SQL プロセスが再起動されるためです。
このセクションで紹介する手動フェールオーバー コマンドは、通常、ローカル冗長構成とゾーン冗長構成の両方で同じように動作します。 通常、このコマンドは SQL プロセスをローカルでのみ再起動し、別のノードへのフェールオーバーを開始しませんが、 いくつかの例外が適用されます。 このローカル フェールオーバーは、フェールオーバー グループで発生するフェールオーバーとは異なります。 ただし、新しいプロセスが同じノードで開始されることを保証する制約はなく、同じ可用性ゾーンまたは別の可用性ゾーン内の別のノードで開始される可能性があります。 ローカル フェールオーバーは、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は自動内部接続テストを実行して、サービスの信頼性を監視し、問題の検出を高速化します。 これらのテストは、SQL マネージド インスタンスのサブネット内の内部 IP アドレスから 10 秒ごとに実行され、ネットワーク のスループットとサービスのパフォーマンスに与えるパフォーマンスへの影響はごくわずかです。 1 つのテストでは、既知の失敗の資格情報 (AzureSQLConnectivityChecker) を使用してログインを試行することで、エンド ツー エンドの接続を検証します。この資格情報を使用すると、監査ログ、拡張イベント、および SQL エラー ログに予期される失敗したログイン エントリが生成されます。 これらのエントリは正常であり、セキュリティの問題を示すわけではありません。 ログ内のテスト署名を識別する方法など、詳細については、「 自動内部接続テスト」を参照してください。
まとめ
Azure SQL Managed Instance では、Azure プラットフォームと緊密に統合される、組み込みの高可用性ソリューションが使われています。 障害の検出と復旧に Service Fabric を、データ保護に Azure BLOB ストレージを、フォールト トレランスを高めるために Availability Zones を活用しています。 また、Business Critical サービス レベル では、データベースのレプリケーションとフェールオーバーのために、SQL Managed Instance は SQL Server の Always On 可用性グループのテクノロジを利用しています。 これらのテクノロジを組み合わせることで、アプリケーションは混合ストレージ モデルを最大限に活用し、最も要求の厳しい SLA に対応できます。