SQL Databaseのアーキテクチャと高可用性の概要（SQL Azure）

Windows Azureは、NoSQLリポジトリとSQLリレーショナルリポジトリの両方を提供します。 NoSQLストレージは、たとえば、Windows Azureテーブル（キー\値）またはブロブ（写真、ビデオ、ドキュメントなどのバイナリデータ）です。 リレーショナルリポジトリには、 SQLデータベース （以前のSQL Azure ）が含まれます 。







この記事は、 Inside Windows Azure SQL Databaseという記事に基づいて作成されました。この記事は、2つの部分に分割することにしました。 最初の部分では、SQL Databaseのアーキテクチャと高可用性の提供方法（障害検出、再構成）に関する情報を提供します。 2番目の部分では、スケーラビリティ（パフォーマンス管理、負荷分散）、および開発者向けの推奨事項について説明します。

SQLデータベースアーキテクチャの概要

SQL Databaseは共有クラウドデータベースであり、Database as Service（DaaS）と言えます。 大容量のSQL Serverは、標準装備に基づいて構築されたMicrosoftデータセンターにインストールされます 。 データセンター内の各SQL Serverには、いくつかの異なるクライアントデータベース（論理データベース）が含まれています。 共有モードになります。 データにアクセスするには、ネットワーク接続の自動負荷分散とルーティングが使用されます。



物理的または実際にデータが1つのデータベースに保存されるのではなく、 複製されることに注意してください。 データは、同じデータセンターの3つの物理サーバー（1つのプライマリレプリカと2つの追加レプリカ）に分散された3つのSQL Serverデータベースに複製されます。 すべての読み取りおよび書き込み操作はプライマリレプリカで実行され、変更は非同期で追加のレプリカに複製されます。 これらのレプリカは、SQLデータベースの高可用性を提供します。 ほとんどのMicrosoftデータセンターには、SQLデータベースのレプリカをホストする数百のSQL Serverインスタンスを持つ数百のコンピューターが含まれています。 プライマリおよびセカンダリSQLデータベースのレプリカが同じコンピューターに保存されることはほとんどありません。



論理サーバーは、Windows Azure管理Webポータルに表示されるSQLデータベースサーバーです。 SQL Database Gatewayサービスはプロキシサーバーとして機能し、表形式データストリーム（TDS）要求を論理サーバーにリダイレクトします。 SQL Database Gatewayは、資格情報の検証、ファイアウォールコンプライアンス、およびサービス拒否攻撃に対するゲートウェイの背後のSQL Serverインスタンスの保護を提供するセキュリティフロンティアです。 ゲートウェイは多くのコンピューターで構成され、各コンピューターはクライアントからネットワーク接続要求を受信し、接続情報を確認し、接続で指定されたデータベース名に応じて、対応する物理サーバーに表形式のデータストリーム要求を送信します。





SQL Serverの同じ論理インスタンスの一部であるデータベースの物理的分布は、各ネットワーク接続がSQL Serverの1つのインスタンスではなく、1つのデータベースに関連付けられていることを意味します。 接続にUSEを使用した場合、表形式のデータストリームをデータセンター内のまったく異なる物理コンピューターにリダイレクトする必要があります。 このため、USEコマンドはSQLデータベース接続ではサポートされていません。

ネットワークトポロジー

アプリケーションは、クライアント層を使用してSQL Databaseと直接通信します。 クライアント層は、ローカルデータセンターに配置するか、Windows Azureでホストできます。 ネットワークを介した伝送用の表形式データストリームを作成するすべてのプロトコルがサポートされています。 使い慣れたツールとライブラリを使用して、クラウド内のデータを使用するクライアントアプリケーションを作成できます。

サービスレベル

サービスレベルは、ルーティング、プロビジョニング、メトリック、および請求を提供するゲートウェイサービスをホストするコンピューターで構成されます。 これらのサービスは、コンピューターの4つのグループによってサポートされています。







インターフェイスクラスターには、ゲートウェイの物理コンピューターが含まれます。 アプリケーションレベルのコンピューターは、サーバーとデータベースの要求を承認し、課金を管理します。 サービスプラットフォームコンピューターは、データセンターのSQL Serverインスタンスの状態を監視および管理します。 メインクラスターコンピューターは、データセンターのSQL Serverの各インスタンスに物理的に存在する特定のデータベースのレプリカを監視します。



図のワークフローの番号付きの行は、クライアント接続を確認および作成する手順を反映しています。

1. テーブルデータストリーム（TDS）を送信するための新しい着信接続の要求を受信するインターフェイスクラスター内のゲートウェイは、クライアントとの接続を確立できます。 サポートされる機能の最小セットを持つパーサーは、データベースへの送信のために受信したコマンドの有効性をチェックします。 タイプCREATE DATABASEのコマンドは、アプリケーション層で処理する必要があるため許可されません。
2. ゲートウェイは、クライアントのSSL確認手順を実行します。 クライアントがSSLの使用を拒否すると、ゲートウェイは切断されます。 完全なトラフィック暗号化を提供する必要があります。 プロトコルパーサーには、IPアドレスからの要求を監視するサービス拒否攻撃保護ツールも含まれています。 IPアドレスまたはアドレス範囲から過剰な数の要求が来た場合、これらのアドレスからの接続試行は拒否されます。
3. ユーザーが指定したサーバー名とユーザー資格情報を検証する必要があります。 ファイアウォールレベルのチェックでは、指定された範囲からのIPアドレスへの接続のみが許可されます。
4. サーバーをチェックした後、メインクラスターはクライアントが使用するデータベース名を内部データベース名にマップします。 プライマリクラスタは、マッピング情報を処理するコンピューターのセットです。 SQLデータベースで作業する場合、パーティションの概念は、SQL Serverのローカルインスタンスで作業する場合とはまったく異なる意味を持ちます。 SQLデータベース環境では、パーティションは、単一のSQLデータベースにマップされるデータセンターのSQL Serverデータベースの一部です。 たとえば、図では、各データベースには3つのSQLデータベースデータベースが含まれているため、各データベースには3つのセクションが含まれています。
5. データベースが検出されると、ユーザー名が認証されます。 テストが失敗すると、接続は終了します。 ゲートウェイは、ユーザーが接続するデータベースをチェックします。
6. すべての接続パラメーターを確認した後、新しい接続を作成できます。
7. 新しい接続は、ユーザーのコンピューターと内部サーバーノードの間で直接確立されます。
8. 接続が確立されると、ゲートウェイはクライアントとデータ処理プラットフォーム間で送信されるパケットのプロキシサーバーとして機能します。

プラットフォームレベル

プラットフォームレベルは、データセンターで物理SQL Serverデータベースをホストするコンピューターで構成されます。 これらのコンピューターはデータノードと呼ばれます。 この図は、データノードの内部構成を示しています。 各データノードは、SQL Serverの1つのインスタンスで構成されます。 これらの各インスタンスには、1つのユーザーデータベースがパーティション分割されています。 各セクションには、プライマリまたはセカンダリレプリカとして表示される1つのSQL Databaseクライアントデータベースが含まれます。







一般的なSQL ServerデータベースSQL Serverデータベースには、最大650個のパーティションを含めることができます。 データセンターでホストされるこれらのデータベースは、ローカルのSQL Serverデータベースと同じ方法で管理されます。 唯一の違いは、定期的なメンテナンスとバックアップがデータセンターの専門家によって実行されることです。 データノードでホストされるすべてのデータベースは、同じログファイルを使用します 。 これにより、順次バッチI / Oを使用したロギングパフォーマンスが向上します。 ローカルデータベースとは異なり、SQL Databaseデータベースログは事前に割り当てられ無効化されたディスク領域に保存されます。 これにより、ログファイルのサイズが自動的に増加するときに記録の一時停止が回避されます。



SQL Databaseのログ管理のもう1つの特徴は、 クォーラムコミットの必要性です。 これは、トランザクションがコミットされたと見なされる前に、メインレプリカと少なくとも1つの追加レプリカがログファイルが書き込まれたことを確認する必要があることを意味します。



この図は、データノード内の各コンピューターに、構造とも呼ばれる一連のプロセスが含まれていることを示しています。 構造プロセスは、次のタスクを解決するのに役立ちます。

1. 障害検出：プライマリまたはセカンダリレプリカの可用性を制御します。 それらが使用できなくなった場合、再構成エージェントが開始される場合があります。
2. 再構成エージェント：ノード障害後のプライマリまたはセカンダリレプリカの再作成を管理します。
3. パーティションマネージャーの場所：パーティションマネージャーにメッセージを提供します。
4. カーネルの負荷調整：論理サーバーがノードリソースを排他的に使用したり、物理的な制限を超えたりすることを防ぎます。
5. リングトポロジ：論理リング内のクラスターコンピューターを制御します。 各コンピューターには、緊急シャットダウンを検出できる2つの近隣があります。

SQLデータベースの高可用性

Microsoft SQL Databaseプラットフォームは、99.9％のサブスクライバーデータベース可用性を提供します。 これは、コンピューターまたはドライブの障害が発生した場合に簡単かつ迅速に交換できるコンシューマ機器を使用することにより、また各SQLデータベースのレプリカを管理することにより実現されます（1つのプライマリレプリカと2つの追加レプリカがサポートされます）。

故障検出

コンピューターの完全な障害のケースだけでなく、コンピューターのパフォーマンスがゆっくりと低下する傾向や、コンピューターとのデータ交換の中断も特定する必要があります。 クォーラム固定の上記の概念により、これらの問題を解決できます。 まず、プライマリレプリカと少なくとも1つの追加レプリカがトランザクションのログを確認しない場合、トランザクションはコミットされたと見なされません。 次に、プライマリレプリカとセカンダリレプリカが記録の成功を確認した場合、トランザクションのコミットを妨げないが、深刻な問題を引き起こす可能性がある小さな誤動作を検出できます。

再構成

破損したレプリカを交換する手順は、 再構成と呼ばれます。 ハードウェア障害やオペレーティングシステムの異常なシャットダウン中、およびSQL Serverインスタンスの障害の場合には、再構成が必要になる場合があります。 再構成は、オペレーティングシステム、SQL Server、またはSQL Databaseプラットフォームのアップグレード時にも使用されます。



各ノードのヘルスモニタリングは、異なるラックにある6つの同様のノードによって実行されます。 これらのノードはネイバーと呼ばれます。 障害は、障害が発生したノードのいずれかのネイバーによって記録されます。 障害が発生したノードにレプリカを格納したデータベースごとに、再構成手順が実行されます。 各コンピューターには何百ものSQLデータベースのレプリカが含まれ、そのうちのいくつかはプライマリーであり、いくつかはオプションです。 したがって、ノードに障害が発生した場合、何百もの再構成操作が実行されます。 ノード障害に起因する数百のエラーを処理する場合、優先順位付けは使用されません。 パーティションマネージャーは、障害のあるノードのすべてのレプリカが処理されるまで、操作を完了した後、次のレプリカを選択するなど、処理するレプリカをランダムに選択します。



再起動のためにノードが切断された場合、ノードのネイバーが例外メッセージを受信するため、これは純粋な障害と見なされます。



別の可能なオプションは、未定義のエラーが記録されたときに、不明な理由でコンピューターとの通信を停止することです。 この場合、 調停手順が適用され、ノード障害の事実を確実に判断できます。



個々のレプリカの障害を判別することに加えて、システムはノード全体の障害の結果を識別し、排除します。 ノードは、最大650の異なるデータベースのレプリカを含む複数のパーティションを持つSQL Serverのインスタンス全体で構成されます。 一部のレプリカはプライマリであり、他のレプリカはセカンダリです。 ノードに障害が発生した場合、影響を受ける各データベースで上記の手順が実行されます。 プライマリレプリカに障害が発生した一部のデータベースでは、調停プロセスによって既存の追加レプリカから新しいプライマリレプリカが選択され、追加レプリカに障害が発生した他のデータベースでは、新しい追加レプリカが作成されます。



ほとんどのSQL Databaseレプリカはコミットを確認する必要があります。 現在、ユーザーデータベースは3つのレプリカをサポートしています。 したがって、クォーラムレプリカのコミットには、他の2つのレプリカによるトランザクションの確認が必要です。 データセンターゲートウェイコンポーネントの一部であるメタデータストアは、5つのレプリカをサポートしています。 クォーラムの固定には3つの確認が必要です。 7つのレプリカをサポートするプライマリクラスタは、トランザクションをコミットするために4つのレプリカからの確認を必要とします。 7つのレプリカすべてに障害が発生した場合でも、メインクラスターからの情報を復元できます。 このような大規模な障害では、メインクラスタの自動回復のメカニズムがあります。



プライマリレプリカの障害

すべての読み取りおよび書き込み操作は、最初にプライマリレプリカで実行されます。 したがって、メインレプリカの障害がすぐに検出され、以降の作業が妨げられます。 プライマリレプリカに障害が発生した場合の再構成中に、パーティションマネージャは追加のレプリカの1つを選択し、それをプライマリに割り当てます。 通常、ワークロードが最小のノード上の追加のレプリカが新しいプライマリレプリカとして選択されます。 プライマリレプリカステータスをメインレプリカステータスに割り当てる手順は、データベースのダウンタイムを引き起こさず、ほとんどのユーザーには気付きません。 ゲートウェイは切断メッセージをクライアントアプリケーションに送信します。その後、アプリケーションはすぐに再接続を試行する必要があります。 新しいプライマリレプリカに関する情報をすべてのゲートウェイサーバーに配布するには、最大30秒かかります。 そのため、再接続を数回試行し、試行が失敗するたびに少し休止することをお勧めします。



余分なレプリカの障害

追加のレプリカが失敗した場合、データベースにはクォーラムコミット用のレプリカが2つしかありません。 再構成手順は、追加レプリカの1つのステータスがメインレプリカに増加したときに、メインレプリカの障害後に実行される手順に似ています。 どちらの場合も、追加のレプリカは1つだけ残ります。 少し待ってから、パーティションマネージャは、新しい追加レプリカを作成するために、この障害が永続的かどうかを判断しようとします。



場合によっては、たとえば、オペレーティングシステムの障害またはアップグレード中に、追加のレプリカの障害に明らかな特性がある場合があります。 障害が発生したノードでの追加レプリカの障害は一時的なものにすぎません。 したがって、新しいレプリカの即時作成は行われません。 追加のレプリカが動作状態に戻ると、レプリカが動作していることを確認するために、データ検証コマンド（チェックディスクなど）が実行されます。



レプリカが2時間以上動作しない場合、パーティションマネージャは、新しいレプリカを作成して置き換えます。 場合によっては、修復不可能なハードウェア障害が原因でコンピューターがクラッシュした場合など、このような固定遅延は最適なソリューションではありません。 SQL Databaseプラットフォームの新しいリリースには、さまざまなタイプのレプリカ障害を検出する機能と、修復不可能な障害の結果をより迅速に排除する機能が含まれる場合があります。



修復不可能なノード障害が発生した場合、新しい追加レプリカを作成するには、十分なディスク容量とプロセッサパフォーマンスマージンを持つクラスターコンピューターの1つを選択します。 このコンピューターは、新しい追加のレプリカをホストするために使用されます。 データベースはプライマリレプリカからコピーされ、このコピーは既存の構成に接続されます。 データベースのコンテンツ全体をコピーするのに必要な時間は、SQLデータベース管理データベースの最大サイズの制限要因です。



データセンター内のすべてのコンピューターは、平均レベルのパフォーマンスとコンポーネント品質を備えたコンシューマコンピューティングシステムです。 この記事の執筆時点では、32 GBのRAM、8コアプロセッサ、および12個のディスクがあります。 このようなシステムのコストは約3,500ドルでした。 経済的で手頃な価格の構成により、致命的な障害が発生した場合にコンピューターをすばやく簡単に交換できます。 Windows Azureは同じコンシューマハードウェアを使用します。 これにより、SQL DatabaseまたはWindows Azureのサポートに使用されているかどうかに関係なく、データセンター内のすべてのコンピューターが交換可能になります。



合計すると、異なるサーバー間でのデータベースレプリカの分散と、メインレプリカのステータスに追加レプリカを割り当てるための効率的なアルゴリズムにより、すべてのデータセンターコンピューターの15％の同時障害でも可用性が保証されます。 つまり、すべてのコンピューターの最大15％に障害が発生した場合、サポートされるワークロードのレベルは低下しません。



これでSQL Databaseの話は終わりではなく、継続があります（継続があります）。



PS。 誰かがタイトルの写真を気に入ったら、ここに大きなポスターへのリンクがあります。