データ依存型ルーティングを使用した SQL Server のスケール アウト

このページはアーカイブです。記載されている内容は情報提供のみを目的としており、ページ内のリンクは有効でない可能性がありますが、これらの情報についてマイクロソフトはいかなる責任も負わないものとします。

公開日: 2005年10月25日

Man Xiong、Brian Goldstein

要約   世界中の何百万人もの顧客にサービスを提供するためにアプリケーションの規模が拡大するにつれて、メインフレームクラスのコンピュータを 1 台ホストするよりも、スケール アウト アーキテクチャに移行した方が有益である可能性があります。このホワイト ペーパーでは、企業がデータベース アプリケーションのスケール アウトを選択する理由について、およびサーバー連合全体でデータのパーティション分割やデータへのアクセスを実施する手法であるデータ依存型ルーティングの使用方法について説明します。管理容易性と線形スケーリングを証明するために、SQL Server スケーラビリティ テスト ラボにおいて、実際の顧客シナリオである MSN (マイクロソフト ネットワーク) のコミュニケーション サービス プラットフォーム (CSP) のシミュレーションを行いました。テストは、Microsoft Windows® Server™ 2003 Enterprise Edition 上で動作している Microsoft® SQL Server™ 2005 Beta 2 を使って実施しました。

トピック

はじめに
スケール アウトを選択する理由
データ依存型ルーティング
MSN コミュニケーション サービス プラットフォーム (CSP)
SQL Server 2005 における MSN CSP のパイロット スタディ
まとめ
付録 A : ハードウェア構成

はじめに

世界中の何百万人もの顧客にサービスを提供するためにアプリケーションの規模が拡大するにつれて、メインフレームクラスのコンピュータを 1 台ホストするよりも、スケール アウト アーキテクチャに移行した方が有益である可能性があります。このホワイト ペーパーでは、企業がデータベース アプリケーションのスケール アウトを選択する理由について、およびサーバー連合全体でデータのパーティション分割やデータへのアクセスを実施する手法であるデータ依存型ルーティングの使用方法について説明します。管理容易性と線形スケーリングを証明するために、SQL Server スケーラビリティ テスト ラボにおいて、実際の顧客シナリオである MSN (マイクロソフト ネットワーク) のコミュニケーション サービス プラットフォーム (CSP) のシミュレーションを行いました。テストは、Microsoft Windows® Server™ 2003 Enterprise Edition 上で動作している Microsoft® SQL Server™ 2005 Beta 2 を使って実施しました。

対象読者

このホワイト ペーパーは、以下の読者を対象としています。

• データベース アプリケーションのスケール アウトの実施を検討している開発者またはデータベース管理者。このホワイト ペーパー全体から参考となる情報が得られます。

• Microsoft SQL Server 上でデータベース アプリケーションのスケール アウトを実施した経験のある開発者またはデータベース管理者。高可用性およびシステム保守プラットフォームとしての SQL Server トランザクション レプリケーションの使用に関する説明から、役立つ情報を得られるでしょう。

• ストレージ エリア ネットワーク (SAN) の管理や I/O システムのスケーリングに関心のあるデータベース管理者またはシステム管理者。

スケール アウトを選択する理由

この 10 年間で、データの記憶容量が急激に増加しました。今では、多くのアプリケーションをインターネット上で利用できるため、企業は、買い物をしたり、電子メール メッセージを保存したり、金融情報を見たりしている何百万人ものオンライン ユーザーに対処する必要があります。このようなエンタープライズ アプリケーションの中心にデータベース システムがあります。そして、大規模データ センターにおける主要なデータベース プラットフォームの 1 つが、SQL Server です。

スケーラブルなデータベース プラットフォームを使用すると、アプリケーションの設計者は、システムを小規模な状態からスタートして、必要に応じて拡張することができます。従来のスケーラビリティのほとんどは、プロセッサ、メモリ、ディスク、およびネットワーク カードなどを 1 台のサーバーに追加するという完全な SMP (対称型マルチ プロセッサ) スケール アップによって実現されていました。これまでの大部分の SQL Server 実装では、スケール アップで十分でした。ただし、単一のデータベース サーバー (以下、"ノード" と表現することもあります) が能力の限界に達して、それ以上の拡張はできないアプリケーション クラスもあります。この障害は、さまざまな形で表面化する可能性がありますが、毎秒、何千件または何百万件ものユーザー リクエストが発生する顧客アプリケーションで多く見られます。これまでは、接続やリクエストごとに必要となる CPU、メモリ、ディスク、ネットワークなどのリソースは、単一システム上で強化するしかありませんでした。

アプリケーションの設計者は、単一システムに障害の発生する可能性が発生した場合、ワークロードとデータベースを SMP ノードのアレイ間でパーティション分割するスケール アウト アーキテクチャを採用することができます。このようにスケール アウトされたシステムは、アレイにノードを追加することによって拡張できます。このパーティション分割はクライアントやアプリケーションからは見えないようにすることが理想的です。クラスタは、単一システムとしてプログラムされ管理されますが、実際にはノード アレイで構成されています。

メモ   このノード アレイは、"サーバー連合" とも呼ばれることがあります。

アプリケーションをスケール アウトするには、いくつかの方法があることに注意してください。1 つのアプローチとして、サービスをノード全体に展開する、サービス指向のパーティション分割アーキテクチャを導入する方法があります。適切な例として、1 台目のサーバーにショッピング カタログを、2 台目のサーバーに商品の在庫データベースを、3 台目のサーバーにショッピング バスケット アプリケーションを、それぞれ配置したシステムが挙げられます。このアプリケーションの中間層は、情報ソースごとにどのサーバーにアクセスするかを理解しています。

このホワイト ペーパーの中心テーマでもあるもう 1 つのパーティション分割戦略は、巨大なテーブルを複数のデータベース ノードで分割するデータ パーティション分割です。

スケール アウトは、その実現手段にかかわらず、より多くのコンポーネントを管理する必要があること、および必ずしもすべてのアプリケーションをノード全体でパーティション分割できるわけではないことから、管理上の複雑な問題が発生します。したがって、スケール アウト アーキテクチャは、一部のアプリケーションには適していますが、すべてのアプリケーションに有効なわけではありません。

スケール アウトに適したアプリケーションである場合、スケール アウトは単一システムのスケール アップに比べて次のようなメリットがあります。

• 市販のコンポーネントを増やさずにアレイを拡張できるため、大幅なコスト削減につながる

• 単一ノードに障害が発生してもアプリケーション全体を停止させる必要がない

• ノードの相対的独立性によって、無理のないフェールオーバーと高可用性設計が実現する

データ依存型ルーティング

スケール アウトされたデータ プラットフォームに関する設計では、複数ノード間でデータをパーティション分割するための最良の方法を決定することが重要となります。一部のアプリケーションは、顧客名、店舗の所在地、時間/日付、登録名などのキー値でパーティション分割できます。問題は、データのアクセス方法によってパーティション分割スキーマを調整することです。たとえば、大手保険会社の各支店で、それぞれの顧客レコードを、SQL Server が動作している支店サーバー上で保持する場合を考えてみます。この場合、アプリケーションは支店を単位としてパーティション分割されます。毎夜バッチ ジョブを実行し、新しく作成されたレコードや修正されたレコードを、本社に設置した SQL Server を実行する集中管理用サーバーにレプリケーションすることができます。ほとんどの場合、支店の外で業務を行う外勤者は集中管理用サーバーにアクセスする必要がなく、一方社内のアナリストはすべての支店サーバーにアクセスしなくても中央のデータベースに対してレポート作成を実行できます。この例では、データ アクセスはローカルに実行されます。

別の例について考えてみます。あるオンライン小売業者がすべての販売トランザクションを保存することを検討しているとします。容易に推察されることですが、データ サイズが急増する可能性があります。商品 ID、日付、顧客 ID などのデータを、パーティション分割する方法は多数存在します。しかし、さまざまな顧客データを調整するには、どうすればよいでしょうか。顧客サービス担当者は、顧客サポートを要請する顧客からの情報に基づいて、日付、顧客 ID、または商品 ID で検索したいと考えます。マーケット アナリストは、商品 ID と顧客 ID で検索する必要があります。このようなあらゆるクエリが単一の SQL Server インスタンスに集中するように、このアプリケーションをスケール アップすることは大きな意味があります。ハードウェア リソースを使い果たしたという理由で、または予算が制限されているという理由で、市販のハードウェア製品を使用してこの小売販売アプリケーションをスケール アウトする必要がある場合を考えてみてください。この場合、顧客満足度を向上させるには顧客レコードの迅速な表示が最優先事項であるため、顧客 ID でパーティション分割することを選択したと仮定します。

この小売アプリケーションをスケール アウトするには、いくつかの方法があります。たとえば、SQL Server の分散パーティション ビューを使用できます。分散パーティション ビューの要件の 1 つは、データベースを水平方向にパーティション分割し、SQL Server 連合全体にパーティションを分散させることです。関係するすべてのサーバーに、同様のデータベース スキーマを設定し、UNION ALL ステートメントを発行して、1 つの更新可能なビュー (つまり分散パーティション ビュー) に、複数のテーブルを統合する必要があります。

メモ   分散パーティション ビューには特定の展開要件があります。分散パーティション ビューの詳細については、SQL Server 2000 Books Online を参照してください。または、Don Jones による電子書籍『The Definitive Guide for Scaling Out SQL Server』(英語) を参照してください。

もう 1 つのスケール アウト テクニックであるデータ依存型ルーティング (DDR : Data Dependent Routing) について考えてみます。DDR では、主として中間層にあるクライアント アプリケーションに、データベース リクエストを適切なノードにルーティングできるだけのインテリジェンスが必要となります。DDR では、ノード全体のビューがありません。つまり、連合サーバーのそれぞれが、互いに独立しています (データベース スキーマの共有は除きます)。中間層には、データのパーティション分割方法と、データがどのノードに存在するかについてのマッピングが含まれます。

パーティション分割を伴う小売アプリケーションの例に戻って、レコードの保存場所を追跡する方法を検討します。SQL Server データベースを中間層 Web サーバー上に構築したと仮定します。データベースは、複数の連合サーバー全体で顧客 ID によってパーティション分割されており、データが存在するノードに顧客 ID をマップするルックアップ テーブルを中間層に作成します。

このルックアップ テーブルには、次のようなレコードが含まれます。

顧客 ID	パーティション ID
10015	1
10016	2
10017	1
10018	3

表 1     パーティション ルックアップ テーブル

顧客サービス担当者が顧客 10015 のすべてのトランザクション レコードを表示する場合、アプリケーションは中間層からそのリクエストをノード 1 に送信する必要があることを判断できます。ノード 2 とノード 3 はリクエストを受信する必要はありません。これにより、アクセスが単一ノードに限定されます。

毎夜、商品 ID に基づいた在庫レポート作成を実行するとどうなるでしょうか。顧客 ID でアプリケーションをパーティション分割したため、各商品 ID については、すべてのデータベース ノードにレコードが格納されている可能性があります。そのため、アプリケーションは、すべてのノードに問い合わせて、各商品 ID に対応するすべてのレコードを取り出し、それらを統合して結果をソートする必要があります。アクセスが限定されていないため、この処理には非常に時間がかかります。ただし、この処理を顧客のオンライン エクスペリエンスに影響を与えないバックグラウンド ジョブとして実行することは可能です。

スケール アウトに関する課題

アプリケーションをスケール アウトするときにいくつかの課題に直面します。

• 管理   ノード数の増加は、運用管理のオーバーヘッドの増加を意味します。計画されたすべての保守タスク (データベースのバックアップ、OS やアプリケーションのサービス パック、バグ修正プログラム、およびインデックスの最適化など) を、単一ノードではなく複数ノード全体に適用する必要があります。ノードの追加と削除は、アプリケーションのユーザーに影響を与えないように行う必要があります。

• データ パーティション分割   正しいパーティション キーの選択は、必ずしも容易ではありません。アプリケーションが進化するにつれて、ビジネス ニーズの変化に気付き、パーティション キーを見直す必要が生じる可能性があります。また、ノード全体での負荷分散の実現が困難になるおそれがあります。たとえば、データベースを顧客の姓 (ラスト ネーム) でパーティション分割し、アルファベットの各文字ごとに 26 台のサーバーに展開すると、"S" で始まるラスト ネームを担当するサーバーは、"X" で始まるラスト ネームを担当するサーバーよりも読み書き動作が多くなります。

• アプリケーションの展開と更新   ビジネス ニーズとデータ アクセス ニーズは時間と共に変化します。これらの変化が、どの程度アプリケーションの可用性に影響を及ぼすでしょうか。

• 高可用性プラクティス   単一ノードに障害が発生しても、アプリケーションはユーザーへのサービスを提供し続けることができるでしょうか。データベースを単一ノードに復元するのにどのくらい時間がかかるでしょうか。ユーザーに影響を与えることなく単一ノードをオフラインにできるでしょうか。

次のセクションでは、これらの疑問を解決すると共に、スケール アウトに成功したアプリケーションを紹介します。

MSN コミュニケーション サービス プラットフォーム (CSP)

世界中の何百万人もの人々が、Microsoft の MSN Messenger と Hotmail サービスを利用しています。これらのサービスの中心に、大規模な SQL Server データベースに保存されたコミュニケーション サービス プラットフォーム (CSP) があります。現在、CSP をサポートしているデータベースは、Microsoft SQL Server 2000 Enterprise Edition が動作している 100 台の 4 プロセッサ バックエンド サーバーにパーティション分割されています。このサーバー連合によって、何億ものユーザー アカウントが処理されます。

このアプリケーションは、SQL Server が、次のことを考慮することによって、どのようにデータ依存型ルーティング (DDR) と共に連合サーバーを使用してスケール アウトに成功したかを示す良い例です。

• 実際のワークロード量が、使用可能な任意のサーバー ハードウェア システムの処理能力を超えている

• アカウントごとにクエリを分離することによって、アプリケーションが行ベースのパーティション分割と DDR に完全に適合する

• データベースを適切にパーティション分割することによって、アプリケーションを安価な市販のハードウェア (4 プロセッサ サーバー) 上で実行できる

図 1 は、システム アーキテクチャの概要を示したものです。MSN コミュニケーション サービス プラットフォームのこの部分は、次の 4 つの階層で構成されます。

1. Microsoft インターネット インフォメーション サービス (IIS) が動作している Web サーバー

2. SQL Server 2000 が動作しているルックアップ パーティション データベース サーバー (LPS)

3. SQL Server 2000 が動作しているデータベース バックエンド サーバー

4. MSN スケール アウト管理レイヤ

レコードは、PUID (Passport Unique ID) によって、バックエンド データベース サーバー全体で順序付けが行われ、パーティション分割されます。スケール アウト管理レイヤは、物理的なバックエンド データベース サーバーに対するデータ パーティションのマッピングを、LPS やバックエンド データベースから独立した専用の SQL Server データベースに格納します。LPS データベースには、データ パーティションに対する PUID のマッピングが格納され、データの増加に対応するために複数の LPS サーバー全体でパーティション分割されます。コミュニケーション サービスのユーザーは、Web サーバーにリクエストを提出し、Web サーバーは PUID を使用して LPS リポジトリに問い合わせて、レコードが格納されているデータ パーティションを取得します。次に、Web サーバーはスケール アウト管理レイヤに問い合わせて、そのユーザーに関する情報がどのバックエンド データベース サーバーに保存されているかを特定します。情報は数秒でクライアントに返されます。

図 1 **   MSN CSP** アーキテクチャの概要

拡大表示する

MSN スケール アウト管理レイヤ

MSN スケール アウト管理レイヤは、MSN CSP が、パーティション分割、DDR、およびフェールオーバー トポロジを LPS とバックエンド データベース サーバーに展開するためのプラットフォームを提供します。MSN スケール アウト管理レイヤは、管理コンソールを介して管理されます。

"MSN スケール アウト管理レイヤ" は、1 つのプライマリ データベースとそのレプリカ ("セカンダリ データベース" と呼ばれます) を含むデータベース セットとしてフェール セーフ セットを定義します。フェール セーフ セットは、MSN スケール アウト管理レイヤの高可用性の構成単位です。1 つのフェール セーフ セットに、1 つまたは複数のセカンダリ データベースを含めることができます。実際には、プライマリ データベースとセカンダリ データベースを、別々のサーバーに配置して高可用性を実現します。

CSP 用のプライマリ データベースとセカンダリ データベースは、SQL Server のトランザクション レプリケーションによって同期化されます。レプリケーションの代わりにログ配布を使用することもできます。ログ配布が待ち時間を犠牲にしてトランザクション比率を高めることを可能にする一方で、レプリケーション ソリューションは同期化にかかる待ち時間を短縮します。

"パーティション" は、データ パーティション分割と DDR の構成単位である、パーティション分割されたデータのセットとして定義されます。パーティションは、プライマリ データベース上のマスタ コピーと共にフェール セーフ セット内に格納され、そのレプリカがセカンダリ データベースに格納されます。通常は、1 つのフェール セーフ セットに 1 つまたは複数のパーティションを格納することができます。

"フェールオーバー グループ" は、互いのバックアップとして機能するサーバーのグループとして定義されます。各フェール セーフ セットのプライマリ データベースとセカンダリ データベースを、別々のサーバーに配置して高可用性を実現します。ワークロードがプライマリ データベースだけにかかるため、パーティション用のプライマリ データベースは複数のサーバー全体に慎重に配置し、フェールオーバー グループのサーバー間でワークロードを分散させてバランスを図ります。フェール セーフ セットがフェールオーバー グループの境界を超えないようにすることで、フェールオーバー グループはそれぞれが独立して機能します。

図 2 に示す例は、2 台のサーバーで構成された単純なフェールオーバー グループです。このグループは、青色と金色で色分けされた 2 つのフェール セーフ セットをホストします。この例では、各フェール セーフ セットが、パーティションを 1 つずつ格納し、セカンダリ データベースを 1 つずつ保持しています。プライマリ データベース上のデータは、セカンダリ データベース上にあるレプリカにレプリケーションされます。フェール セーフ セット 1 のプライマリ データベースは Server 1 に配置され、そのセカンダリ データベースは Server 2 に配置されます。フェール セーフ セット 2 のプライマリ データベースは Server 2 に配置され、そのセカンダリ データベースは Server 1 に配置されます。両方の配置は、高可用性のために設計されています。ワークロードのバランスを図るために、Partition #1 用のプライマリ データベースは Server 1 に配置され、Partition #2 用のプライマリ データベースは Server 2 に配置されます。

図 2     単純なフェールオーバー グループ

拡大表示する

スケール アウト管理レイヤは、展開と現在の状態に関する次の情報を保存するために、構成データベースを保守します。

• フェール セーフ セットとフェールオーバー グループのトポロジ

• DDR に適した SQL Server データベースに対する各データ パーティションのマッピング

• すべてのデータベース、SQL Server が動作しているすべてのサーバー、および自動フェールオーバーとリアルタイム DDR 用のすべてのフェール セーフ セットの現在の状態

スケール アウト管理レイヤは、データベース サーバーのパーティション分割とフェールオーバー トポロジに関する構成ファイルを読み込んで、その内容を専用の SQL Server データベースに保存し、それに従ってサーバーを構成します。また、フェールオーバー操作に関するサーバーの状態を監視して、DDR 用のパーティション マッピングを維持します。

さらに、このアプリケーションは、高可用性ソリューションとしてレプリケーションを使用したシステムのスケール アウトに対する共通のシステム保守操作のために、次のような管理インターフェイスを提供します。

• データベースの昇格。ワークロードをリダイレクトし、プライマリ データベースからセカンダリ データベースへのレプリケーションを確立することによって、セカンダリ データベースをプライマリ データベースに変換します。

• データベースの降格。プライマリ データベースをセカンダリ データベースに変換します。これによって、レプリケーション キューがクリアされ、そのデータベースに対するレプリケーションが中断します。これがフェール セーフ セット内のプライマリ データベースの場合は、適切なセカンダリ データベースが昇格されます。

• データベースを "オフライン" としてマーキング。クライアント アプリケーションのデータベースへの問い合わせを拒否し、すべてのレプリケーション プロセスを中断します。これがプライマリ データベースだけの場合は、適切なセカンダリ データベースが昇格されます。

• データベースを "オンライン" としてマーキング。このデータベースに対するレプリケーション プロセスを再開します。

• データベースを "修復が必要" としてマーキング。レプリケーション キューをクリアし、データベースに対するレプリケーションを中断します。これがプライマリ データベースの場合は、セカンダリ データベースが昇格されます。

• データベースの修復。データベースをオフライン状態にしてから、バックアップ処理または復元処理によって修復するようにマーキングされたデータベースを再構成します。

• サーバーを "オフライン" としてマーキング。サーバー上のすべてのデータベースが "オフライン" としてマーキングされます。

• サーバーを "オンライン" としてマーキング。サーバー上のすべてのデータベースが "オンライン" としてマーキングされます。

MSN スケール アウト管理レイヤのコードは、Microsoft 以外では使用できませんが、.NET Framework、分散管理オブジェクト (DMO : Distributed Management Objects)、および Transact-SQL に対する SQL Server のプログラミング サポートを利用してこれらの機能を実装することができます。

次のセクションでは、システムがスケール アウトの問題を克服する方法、特に、管理容易性と高可用性について説明します。

データとワークロードの増加に対応するためのスケール アウト

スケール アウト管理レイヤの機能を活用する CSP アーキテクチャにより、データの自然増加とクライアント リクエストの増加に対処できます。データは、全データ セットの一部を保持している複数のパーティション間で分割されます。パーティションは、高可用性を維持するために別々のサーバー上に配置されたスケール アウト管理レイヤを使用するフェール セーフ セット上でホストされます。

新しいレコードがシステムに追加されると、クライアントのリクエスト数および SQL Server が動作しているバックエンド サーバーの CPU 使用率が上昇します。サーバーのフェールオーバーに対応するために、すべてのバックエンド データベース サーバーのリソース使用率の最大運用指針が設けられています。図 2 に示した最も単純な設計に対する上限は 50% です。この上限を超えたときに、CSP は新しいデータベース サーバーを追加する必要があると判断します。これは、新しいフェールオーバー グループを追加することで解決できます。

開発中の MSN CSP では、最新のフェールオーバー グループ設計が採用されています。図 3 に示すように、サーバー リソースの有効利用を可能にするために、Server 1 上のプライマリ データベースが、Server 2、Server 3、Server 4、および Server 5 にレプリケーションされる 4 つのデータ パーティションをホストします。Server 1 に障害が発生すると、Server 2、Server 3、Server 4、および Server 5 が、Server 1 が担っていた負荷の 25% ずつをそれぞれ引き受けます。図には示していませんが、グループ内の他のサーバー上のすべてのプライマリ データベースが同様にレプリケーションされます。この構成によって、1 台のサーバーに障害が発生しても、セカンダリ サーバーの負荷が 80% * 25% = 20% しか増えないため、すべてのサーバー上のリソースの最大 80% を使用することができます。実際には、運用チームは多少の余裕を見て上限を 75% に設定します。

図 2 に示したフェールオーバー グループは、リソース使用の上限を 50% に設定した最も単純な設計になっています。フェールオーバー グループ内のパーティション数とサーバー数を増加させると、この上限を上げることができますが、その代わりに管理がより複雑になります。

図 3     開発中の MSN CSP で採用されているフェールオーバー グループ アーキテクチャ

拡大表示する

フェールオーバー グループの追加

新しいフェールオーバー グループは、スケール アウト管理レイヤ インターフェイスを使用してシステムに追加することができます。フェールオーバー グループが追加されると、DDR とフェールオーバー トポロジ用のスケール アウト管理レイヤにある構成データベース内の情報が更新されます。新しいアカウントが要求されると、LPS サーバーがバックエンド データベース サーバー全体のデータ分割を調べ、新しいフェールオーバー グループが追加されていれば、新しいアカウントが新しいグループに自動的に追加されます。図 4 は、フェールオーバー グループの追加前後のシステムの DDR と高可用性アーキテクチャを示したものです。実際の実行結果の詳細については、このホワイト ペーパーのパイロット スタディで説明します。

図 4     フェールオーバー グループの追加

拡大表示する

負荷分散

ノード追加後のデータベース サーバーの再負荷分散は、段階的な方法で自動的に実施されます。新しいアカウントが作成されると、LPS サーバーは各データベース サーバーの負荷を評価して、最も余裕のあるサーバーにそのアカウントを追加します。新しいデータベース サーバーは、データベース サーバー負荷のヒューリスティックな指標を使用して、自身の負荷が既存のデータベース サーバーと同じレベルに到達するまで、新しいユーザー アカウントとそれに伴うワークロードを引き受けます。これによって、フェールオーバー中の応答時間やパフォーマンスを犠牲にすることなく、全体のスループットがノード数に比例して増加するスムーズなスケール アウトが保証されます。

高可用性

MSN CSP に関するデータベースのアップタイム要件は、読み取りに対しては 100% です。使用環境がインターネット上に存在すると仮定した場合は、書き込みアクセスに対して年間 10 分のダウンタイムが許容されます。CSP は、2 年間の運用において、この目標を 100% 達成しました。

スケール アウト データベース設計を使用した高可用性には、長所と短所があります。サーバーの台数が増加すれば、単一システムに障害が発生する可能性も高くなります。ただし、データセット全体をホストしている単一サーバーの障害と比較して、影響を受けるデータは少量です。スケール アウト管理レイヤは、RAID や冗長な電源装置などのさまざまなハードウェア フェール セーフ メカニズムと連動する MSN CSP のレプリケーションベースのフェール セーフ セットに対して、展開と管理用の基盤を提供します。

高可用性ソリューションとしてのレプリケーション

CSP は、SQL Server のトランザクション レプリケーションを使用して、短い待ち時間とトランザクションの一貫性という保証を提供することによって、高可用性を実現します。ハードウェア、オペレーティング システム、SQL Server プライマリ インスタンスのいずれかが障害発生または保守のためにダウンした場合は、セカンダリ コピーがワークロードを引き受けます。CSP は、プライマリとセカンダリの両方を同時に読み書きするようには設計されていないため、セカンダリ コピーはフェールオーバーのためだけに使用されます。同時に読み書きしない理由として、次の 2 つがあります。

1. アプリケーションの設計がかなり複雑になります。プライマリとセカンダリ間の双方向のレプリケーションを実施する必要があります。

2. 同じノード上に、セカンダリ コピーと別のデータセット パーティションのプライマリ コピーが共存します。セカンダリ データベースからの読み取り時に、プライマリ データベースからのリソースが使用されます。

トランザクション レプリケーションは、トランザクション ログを使用して、パブリッシュされたテーブル内のデータに対して行われた増分変更をキャプチャします。Microsoft® SQL Server™ 2000 および 2005 は、INSERT、UPDATE、DELETE の各ステートメントまたはデータに対して行われたその他の変更を監視して、信頼できるキューとして動作するディストリビューション データベースにそれらの変更を保存します。その後、変更は、サブスクライバに転送され、サブスクライバ データベースへの接続をオープンして、サブスクライバ データベースに SQL コマンドを発行することによって、発生した順に適用されます。

読み取りトランザクションの割合よりも書き込みトランザクションの割合の方が高いアプリケーションでは、レプリケーションがトランザクション処理よりも遅れる可能性があります。基本的には、レプリケーション コマンドの実行速度によって制限されます。一般的な制限要因として、ネットワーク待ち時間、サブスクライバ データベース上のインデックス オーバーヘッド、およびコマンドを実行しているサブスクライバへの接続数が挙げられます。ソース システムの 1 秒間のトランザクション数がシステムのレプリケーション能力を上回った場合は、レプリケーション待ち時間はトランザクション負荷が減少するまで上昇を続けます。トランザクション レプリケーション待ち時間用のパフォーマンス カウンタ (\SQL Server: Replication dist.\ Dist: Delivery Latency) を使用して、キューの増加を監視することができます。

プライマリ システムに障害が発生すると、レプリケーション キュー内のトランザクションが失われます。トランザクション消失の許容レベルは、ビジネス ニーズと、必要なエンド ユーザー エクスペリエンスによって異なります。CSP の場合、設計上の上限は 10 分です。つまり、CSP クライアント アプリケーションは、データベースに対する書き込みリクエストの最大 10 分間の消失を許可します。このことは、サービス レベル契約 (SLA) がデータの消失を許可していない他のアプリケーションでは受け入れられない可能性があります。この場合は、別の高可用性ソリューションが必要になります。

レプリケーションの障害を回避するには、次のようにいくつかの方法があります。

• データとワークロードをより多くのサーバー コンピュータに展開し、ディストリビュータ単位のワークロードを削減します。ただし、この方法ではハードウェアが十分に活用されない可能性があります。CSP では、この方法を採用しています。

• SQL Server が動作しているサーバーごとにディストリビュータが 1 つずつしかないため、複数の SQL Server インスタンスを使用して、各サーバーのディストリビュータを増加させます。元のワークロードをこれらのインスタンス全体に展開することによって、各サーバーの増加したディストリビュータでレプリケーション負荷を処理できます。この方法では、サーバーを追加する必要はありませんが、CPU やメモリなどのハードウェア リソースをインスタンス間で割り当てるための管理を追加する必要があります。複数インスタンスの実行に関するベスト プラクティスについては、『SQL Server Consolidation on the 32-Bit Platform using a Clustered Environment』(英語) を参照してください。

• Microsoft SQL Server 2005 は、レプリケーションの並列処理をサポートし、またパブリッシャに対する場合と同じ順序でトランザクションがサブスクライバに対して処理されることを保証します。このホワイト ペーパーを執筆している時点では SQL Server 2005 がリリースされていないため、この機能はまだ CSP の開発サイトに導入されていません。

• SQL Server 2000 上に複数のパブリケーションを作成し、個別のエージェント オプションを使用して、並列処理を増加させます。この方法の場合、トランザクションは、パブリッシャに対するときと同じ順序でサブスクライバに対して処理されるとは限りません。したがって、パブリッシュされたデータ セット間のトランザクションの整合性が保証されないことになり、CSP チームではこの方法は採用しませんでした。

MSN CSP 運用チームが、各ノード上のクライアント リクエストのストレス レベルを監視します。アカウントの数やサイズが増加すると、ノードごとのクエリの数も増加します。ストレス レベルがしきい値に達すると、別のフェールオーバー グループがシステムに追加されます。

システム障害の検出とフェールオーバー

MSN スケール アウト管理レイヤは、すべてのノードの状態を監視します。サーバーまたはデータベースの障害が検出されると、ワークロード トラフィックをセカンダリ データベースにリダイレクトして、障害が発生したパーティション用にセカンダリ データベースを昇格させます。

Web サーバー アプリケーションが、スケール アウト管理レイヤにある構成データベース上の情報に基づいて、バックエンド データベースに対する接続を確立します。そして、処理中の正しい物理データベース インスタンスに対してリクエストを生成します。SQL Server からのリターン コードで、接続の問題を判断できます。接続タイムアウトも障害として扱われます。Web サーバーが、MSN スケール アウト管理レイヤのクライアントを起動して、これにより管理レイヤに障害を通知します。管理レイヤは、障害が発生したデータベースをブラックリストに載せ、瞬時にその Web サーバーをバックアップにリダイレクトします。

システムの保守

前述したように、システム管理では、システムのスケール アウト固有の課題があります。MSN CSP のような OLTP システムの場合は、共通ルーチン管理タスクとして、OS やアプリケーションの更新プログラム、ノードの追加、データベースのバックアップ、およびインデックスの最適化が含まれます。これらのタスクでは、データの有効性とワークロード パフォーマンスに対する影響を最小限に抑える必要があります。いくつかのタスクは、データベースをオフラインにしなくても実行できますが、それ以外のタスクは、オフラインで処理するか、サーバー全体をダウンさせる必要が生じることもあります。ここでは、MSN CSP がスケール アウト管理レイヤの管理操作を使用して、これらすべての共通管理タスクにおいて、どのようにアプリケーションの可用性を維持しているかを説明します。

インデックスの最適化と再構築

高可用性 SLA を満たすためには、一般に、データベースをオフラインにしなければならないインデックスの再構築 (DBCC REINDEX) よりも、オンラインによるインデックスの最適化 (DBCC INDEXDEFRAG) の方が好まれます。MSN CSP の運用チームは、クライアントのリクエストが最も少ない毎週土曜日の夜に、DBCC INDEXDEFRAG ジョブを実行します。インデックスの再構築は、それほど頻繁ではありませんが、6 ～ 8 週間ごとに、断片化が 40% まで増加したときにだけ実施されます。インデックスが再構築された後は、ワークロードのスループットが 5 ～ 10% 改善されます。インデックスの断片化の測定方法と削減方法については、『Microsoft SQL Server 2000 インデックスの最適化に関するベスト プラクティス』を参照してください。

後述のパイロット スタディのテストで説明しますが、スケール アウト管理レイヤを使用すると、アプリケーションの可用性に影響を与えずにオフライン インデックス再構築を実現することができます。

データベースの修復

ハードウェアの障害やオペレータの誤操作によって、データベースが破損することがあります。プライマリ データベースが破損した場合は、スケール アウト管理レイヤの自動フェールオーバー操作によって、ワークロードがセカンダリ コピーにリダイレクトされます。破損したコピーを復元するために、スケール アウト管理レイヤは次のように動作します。

1. データベースを "修復が必要" としてマーキングします。

2. データベースに対して "修復" 処理を実行し、データベースをオフライン状態にして、プライマリ データベースをバックアップし、それを修復が必要としてマーキングされたデータベースに復元します。

3. プライマリ データベースと新しく復元されたセカンダリ データベース間の待ち時間が目標レベル (10 分) まで下がってから、修復されたデータベースを "オンライン" としてマーキングします。

これで、オペレータの判断によって、このデータベースをプライマリに昇格させることも、またセカンダリの役割を継続させることもできます。

OS または SQL Server の修正プログラム

修正プログラムの中には、システムの再起動や SQL Server サービスの再起動を必要とするものがあります。このような場合は、次のように MSN スケール アウト管理レイヤを使用して、ノードをいったんオフラインにしてから、オンラインに戻す必要があります。

1. サーバーを "オフライン" にマーキングします。

2. サーバーに修正プログラムを適用します。

3. サーバーを "オンライン" にマーキングします。2 つのコピー間でレプリケーションが再開され、同期化されます。

4. 対になっている降格と昇格の役割を入れ替えて、手順 1 ～ 3 を繰り返します。

5. 対になっている降格と昇格の役割を入れ替えて、元の構成に戻します。

SQL Server 2005 における MSN CSP のパイロット スタディ

最も単純なフェール セーフ セットを使った小規模な MSN CSP を SQL Server スケーラビリティ テスト ラボ内に展開しました。このパイロット環境によって、テストの実施、異なる構成の試行、さまざまなスケーラビリティ データ ポイントの設定が可能になりました。パイロット ラボ展開は、12 台のクライアント、3 台の Web サーバー、2 台の LPS サーバー、4 台のバックエンド データベース サーバー、および 1 台のスケール アウト管理レイヤ用管理サーバーで構成されています。3 台の Web サーバーは、負荷分散用のスイッチを介してネットワークに接続されます。すべてのデータベース サーバーのデータ ファイルとログ ファイルは、I/O の負荷分散とフェールオーバーを提供するために、各サーバーにインストールされた 2 枚の Emulex 製ホスト バス アダプタを介して EMC Clariion SAN 上の同じグループのディスクに格納しました。ハードウェア構成の詳細については、「付録 A」を参照してください。

ノードの追加に伴うスループットの増加

図 5 は、テストにおいて、すべてのバックエンド データベース サーバーによって処理されたクエリの総数が、バックエンド データベース サーバーの台数に比例して増加するようすを示したものです。このグラフは、顧客がアプリケーションのスケール アウトを選択する理由を明らかにしています。つまり、顧客はノードの追加に比例してパフォーマンスが向上することを期待しています。さらに、この線形スケーリングは、MSN CSP チームが、ユーザー基盤の拡大に合わせて、自分たちのアプリケーションを現在の 100 台のバックエンド サーバーのサイズにまで拡張できたこと、および、必要に応じて 100 台を超えるサイズにまで拡張できることの理由の 1 つでもあります。

図 5     ワークロード パフォーマンスのスケーリングとバックエンド データベース サーバーの台数の関係

拡大表示する

ストレージ サブシステムの拡張

以下に示す理由から、直接接続ストレージ (DAS : Direct Attached Storage) ではなく、ストレージ エリア ネットワーク (SAN : Storage Area Network) を選択しました。

• 管理の一元化

• サーバーを追加せずにストレージが追加できることによる柔軟性とスケーラビリティの向上

• ストレージ リソースを追加または再配置するときの業務の継続性

• SAN によるハードウェアレベルの高可用性ソリューション

SAN の潜在的な欠点として、次のことが挙げられます。

• SAN は DAS よりもかなり高価である

• 管理するために専門知識が必要である

サーバーを追加することによって、ディスクの待ち時間が増加し、ディスク サブシステム上のパフォーマンス障害に至るおそれがあります (パフォーマンス カウンタの Logical Disk/Avg. Disk sec/[Read,Write] で監視できます)。これは、ディスク領域の不足とは別の問題です。EMC Clariion を含め、一部の SAN ベンダは、オンライン ディスク LUN 拡張をサポートしています。テストの一環として、バックエンド データベース サーバーが使用可能な物理スピンドルの数を意図的に制限することによって、EMC Clariion SAN におけるディスク サブシステムのパフォーマンス障害シミュレーションを行いました。

Microsoft Windows Server 2003 は、ストライプ セット全体を再構築するのではなく、新しいスピンドルを LUN に連結させるために使用可能なオンライン ディスク拡張機能を提供します。EMC Clariion は、ディスク レベルのデータのコピーと移動によって、ストライプ セット全体を再構築する機能を提供します。ここで使用するアプリケーションは、EMC アプローチによって、次のような恩恵を受けることができます。

1. ストライプの再構築によって、データがより均一に物理スピンドルに分配され、LUN 全体のパフォーマンスが向上します。

2. ディスク サブシステム構成の柔軟性が向上します。たとえば、LUN のサイズを変えずにスピンドル数を増やし、他のデータベースに新しい容量を割り当て、またスピンドル上に余分な領域があるときにスピンドル数を増やさずに LUN の容量を増やすことができます。

3. 操作が OS に対して透過的であるため、ベーシック ディスクとダイナミック ディスクの両方で実行することができます。

テストでは、2 つのバックエンド データベース ノードからスタートし、後から 2 つのノードを追加して、データベース ファイル用に同じグループの物理スピンドルを共有しました。2 つのノードを追加した後、ワークロードのストレス レベルが 2 倍になりました。それに応じて、ディスク キューが増加し、同様にディスク待ち時間も増加しました。ワークロード パフォーマンスは I/O バウンドでした。図 6 の赤い線は、ノードが 2 つから 4 つになってもワークロードの増加がそれに比例しないことを示しています。

メモ   実稼動環境では、ワークロードが増加する前に LUN を拡張することをお勧めします。これによって、新しいスケール アウト データベース サーバーを追加する前に、実稼動環境のパフォーマンスに影響を与えずに、ストレージを拡張して再配分することができます。

EMC は、SAN の LUN 拡張処理に対して、3 つの優先順位レベルを設定しています。テストでは、既定の設定 (下位の優先順位) を採用しました。この設定では完了までに時間はかかりますが、拡張の際のディスク処理が最小限に抑えられることで、同時に発生したワークロードに対する影響も最小限に抑えられます。

	拡張前	拡張後
データの総容量	320 GB	320 GB
ログの総容量	200 GB	200 GB
データ用のスピンドル数	24	32
ログ用のスピンドル数	16	24
ワークロードの拡大/縮小率	1.6	2.0

表 2 **   LUN** 拡張前後の EMC Clariion SAN の比較

表 2 は、LUN 拡張前後の EMC Clariion SAN のディスク構成を示したものです。LUN サイズを変えずに LUN 単位のスピンドル数を増やしていることに注意してください。プロセス全体で 44 時間かかりましたが、ワークロードへの影響はほとんどありませんでした。優先順位が中位または上位の拡張処理を使用すると完了までの時間は短縮されますが、ワークロードに対する影響は大きくなります。同じ優先順位設定にした場合、処理時間は再構成されるディスク領域に比例します。

図 6 は、拡張後に I/O 障害が解消され、ワークロード パフォーマンスが線形スケーリングのレベルにまで回復したようすを示したものです。

図 6     ディスク I/O を拡張した場合としない場合のワークロード パフォーマンスのスケーリング

拡大表示する

高可用性ソリューションとしてのレプリケーション

前述したように、スケール アウト管理レイヤとレプリケーションの組み合わせによって、優れた高可用性ソリューションが実現します。1 つの欠点は、SQL Server 2000 でのトランザクション レプリケーションが単一のスレッドに制限されることで、そのため、MSN CSP は使用可能なサーバー リソースを有効利用することができません。

この問題は、SQL Server 2005 ではレプリケーションの並列ストリーミングによって解決されます。ディストリビュータは、トランザクションの順序が完全に保証された複数のストリーム (1 ～ 64) でレプリケーション コマンドを処理することができます。最適のストリーム数とパフォーマンスは、次のような複数の要因に応じて変化します。

• CPU 数。ストリーム数は、CPU 数以下にすることをお勧めします。テストの結果、4 プロセッサ コンピュータで 64 ストリームのレプリケーションを使用すると、CPU 使用率が大幅に上昇し、ストリーム数が 1 ～ 2 のスループットに匹敵することがわかりました。

• ブロック操作。トランザクションがテーブル上で重複すると、ストリームが互いをブロックする可能性があります。CSP のトランザクション ワークロードによって発行される書き込みアクセス リクエストは、ほとんどランダムに巨大なテーブル全体に分配されるため、それぞれには数行しか含まれません。そのため、パイロット テストでは、使用するレプリケーションのストリーム数が 4 以下であれば、ブロック操作は問題になりませんでした。

• CPU の余力。ストリームを追加すると CPU 使用率が上昇するため、CPU の能力に余裕を持たせておく必要があります。

• 一定時間内のレプリケーション コマンド数。レプリケーション キューを指定時間内にクリアできれば、余分なストリームを実行する必要がなくなります。

図 7 と図 8 は、テストにおいて、レプリケーション ストリーム数が増加した場合に、レプリケーションのスループット指標 (1 秒間に発行されたレプリケーション コマンド数) が大幅に増加したことを示しています。ストリームを追加するたびに CPU 使用率が 1 ～ 2% 上昇します。

図 7     レプリケーションのスループットとストリーム数の関係

図 8 **   CPU** 使用率とレプリケーション ストリーム数の関係

DBMS の保守

次の 3 つの処理をテストした結果、アプリケーションと管理の適切な設計によって、アプリケーションの可用性への影響を最小限に抑えられることが実証されました。

1. フェールオーバー グループの追加

2. インデックスの最適化

3. SQL Server のメジャー バージョン アップグレード

フェールオーバー グループの追加

これは、新しいフェールオーバー グループをスケール アウト管理レイヤの構成ファイルに追加して、ハードウェア構成、OS、および SQL Server インスタンスを新しいコンピュータ上にセットアップすることで実現しました。その後で、スケール アウト管理レイヤが、スキーマ、ストアド プロシージャ、およびレプリケーションを含むデータベースを新しい SQL Server インスタンス上にセットアップしました。また、図 4 に示したように、スケール アウト管理レイヤが LPS サーバー上のパーティション マッピングと DDR 情報を更新し、新しく使用可能になったパーティションを反映させました。これ以降、Web サーバーからのリクエストは、新しい DDR 情報に基づいて、既存のサーバーと新しいサーバーの両方に転送されるようになりました。

インデックスの最適化

挿入 (insert) コマンドと更新 (update) コマンドを大量に実行するデータベース アプリケーションでは、データベース インデックス ファイルの断片化が発生し、特定のワークロードに対するパフォーマンスが低下する可能性があります。最適な I/O パフォーマンスを維持するためには、最終的には最適化の実行が必要です。インデックスの最適化とそのベスト プラクティスについては、『Microsoft SQL Server 2000 インデックスの最適化に関するベスト プラクティス』を参照してください。

SQL Server 2000 は、インデックスを最適化するために、DBCC INDEXDEFRAG と DBCC REINDEX の 2 つのオプションを提供しています。DBCC REINDEX は、断片化レベルが高く、複数のプロセッサが使用可能な場合に、DBCC INDEXDEFRAG よりもかなり早く動作します。ただし、SQL Server 2000 では、データベースをオフラインにしてから、インデックスを再構築する必要があります。SQL Server 2005 では、この 2 つのコマンドがそれぞれ、ALTER INDEX <テーブル> REORGANIZE と ALTER INDEX <テーブル> REBUILD WITH (OFFLINE) に置き換わっています。テスト ラボでは、スケール アウト管理レイヤを使用して、次の手順で、オフライン インデックス再構築を実施しました。

1. セカンダリ コピーを "オフライン" としてマーキングします。

2. ALTER INDEX <テーブル> REBUILD WITH (OFFLINE) を実行して、セカンダリ コピー上のすべてのインデックスを再構築します。

3. データベースを "オンライン" にマーキングします。2 つのコピー間でレプリケーションが再開され、同期化されます。プライマリ データベースと新しく復元されたセカンダリ データベース間の待ち時間が許容レベル (10 分) に達するまでに 20 分かかりました。前述したように、プライマリ データベースに障害が発生した場合は、SLA に基づいて、トランザクションの消失が許容されます。

4. 対になっている降格と昇格の役割を入れ替えて、新しいセカンダリ コピー上で手順 1 ～ 3 を繰り返します。

5. 元のプライマリを最適化してから、対になっている降格と昇格の役割を入れ替えて、元の構成に戻します。

Microsoft® SQL Server™ 2005 Beta 2 では、オンライン インデックス操作という新しい機能を使用して、オンラインでインデックスの作成、再構築、および削除を行うことができます。ONLINE オプションを使用すると、インデックス操作中に、元になるテーブルまたはクラスタ化インデックス データと、関連する非クラスタ化インデックスへのユーザーの同時アクセスが可能になります。テストでは、次の SQL Server コマンドを実行して、テーブルのすべてのインデックスをオンラインで再構築しました。

ALTER INDEX ALL ON <table> REBUILD WITH (ONLINE, MAXDOP = degree of 
parallelism desired)

インデックス再構築の並列処理の程度は、手順 1 ～ 4 で設定しました。各サーバーには、4 基の CPU が搭載されています。平均 20% の論理スキャン フラグメンテーションと標準的なストレス レベルの並列ワークロードで、3 種類の方法を使用して、55 GB のデータに対するインデックスの最適化をテストしました。ワークロードのストレス レベルは、CPU の 52% を消費するように調整され、プライマリ データベース上のトランザクション数は 286 でした。すべてのテーブルに対して、ALTER INDEX <テーブル> REORGANIZE を実行した結果、MAXDOP の値によって、オンライン インデックス再構築に CPU が大幅に消費されましたが、CPU 使用率の増加は最小限に抑えられました。MAXDOP を高く設定した場合のオンライン インデックス再構築は、ワークロード パフォーマンスに影響を与える可能性があります。オフライン インデックス再構築は、オンラインでの処理よりもはるかに高速です。オンライン インデックス再構築は、実際の時間は MAXDOP に依存しますが、オンライン ALTER INDEX <テーブル> REORGANIZE よりも高速です。高可用性環境において、操作の完了に要する時間をある程度は許容できるときは、多くの場合、オフライン インデックス再構築よりもオンライン インデックス再構築の方が選択されます。オンライン インデックス再構築とオンライン ALTER INDEX <テーブル> REORGANIZE のどちらを実行するかは、主として、次の 3 つの要因によって決まります。

• ワークロードのストレス レベル。ALTER INDEX <テーブル> REORGANIZE は、現在のストレス レベルに応じてリソース使用率を下げることができます。

• 処理の実行頻度。規模を縮小する場合は、ALTER INDEX <テーブル> REORGANIZE の方が完了までに時間がかかります。

• 断片化の特性。ALTER INDEX <テーブル> REORGANIZE は、インターリーブされたエクステントをデータ ファイル内に残します。また、ALTER INDEX <テーブル> REORGANIZE は、インデックス上のエクステントの断片化を修正しません。インデックスのエクステント (8 枚のインデックス ページをグループ化したもの) がデータ ファイル内で連続していないときにインターリーブが発生し、ファイル内で混ざり合った 1 つまたは複数のインデックスからエクステントが削除されます。

SQL Server のオンライン アップグレード

どのようなデータ センターであっても、DBMS のバージョン アップは困難な作業です。ここで、ダウンタイムを発生させずに SQL Server のアップグレードを実施する方法を紹介します。このオンラインでのローリング アップグレードは、MSN CSP のような高度なアプリケーション管理レイヤでのみ実現することができます。

2 台のバックエンド データベース サーバーのフェールオーバー グループを、次の手順で SQL Server 2000 から SQL Server 2005 にアップグレードしました。

1. バックエンド データベースに対して、SQL Server Best Practices Analyzer (BPA) を実行します。このツールによって、互換性の問題が特定され、修正されます。BPA はすべての関連ドキュメントと共に、Microsoft Download Center (英語) からダウンロードできます。この目的での BPA ツールの使用方法は、変更される可能性があります。

2. Server 1 をオフラインとしてマーキングします。Server 1 上の Partition #1 のプライマリ データベースが降格され、Server 2 上の Partition #1 のセカンダリ データベースが昇格されます。Server 1 にある両方のデータベースに対するレプリケーション プロセスが中断されます。Partition #1 と Partition #2 のすべてのワークロードが Server 2 に向けられます。

3. Server 1 で SQL Server 2005 のアップグレードを実行します。これには、30 分かかりました。

4. アップグレード後に、スケール アウト管理レイヤの管理コンソールを使用して、Server 1 をオンラインに戻します。レプリケーション待ち時間が目標値 (10 分) に到達するまで、47 分かかりました。

5. Server 2 に対して手順 2 ～ 4 を繰り返します。Partition #1 と Partition #2 のすべてのワークロードが Server 1 に向けられます。

6. Server 1 と Server 2 の間でワークロードのバランスが保たれるように、昇格と降格が行われ、プライマリ コピーとセカンダリ コピーの元の分散状態が復元されます。

この処理全体で 3 時間を要しましたが、システムの可用性を損なわずに実行することができました。

まとめ

このホワイト ペーパーでは、データベース アプリケーションのスケール アウトのメリットと問題点について説明しました。実際の顧客アプリケーションである MSN コミュニケーション サービス プラットフォーム (CSP) を使用してテスト環境でさまざまなシナリオを実行し、データ依存型ルーティングを使用すると、パフォーマンスを直線的に向上させながらデータとワークロードの増加に対処できること、SQL Server トランザクション レプリケーションによる高可用性を実現できること、およびオンライン システム保守を実施できることを実証しました。この結果により、SQL Server を使用すると、エンタープライズ クラスのアプリケーションの適切な管理とスケール アウトを実現できることが明らかになりました。

詳細情報

• SQL Server Consolidation on the 32-Bit Platform using a Clustered Environment (英語)

• Microsoft SQL Server 2000 インデックスの最適化に関するベスト プラクティス

• The Definite Guide for Scaling Out SQL Server (英語)

付録 A : ハードウェア構成

コンピュータ構成

コンピュータの役割	モデル	CPU	物理メモリ	ストレージ	OS バージョン	アプリケーション
データベース サーバー (4)	Dell 6650	2 GHz Xeon x 4	8 GB	ストレージ エリア ネットワーク (SAN : Storage Area Network)(「SAN 構成」を参照)	Windows Server 2003 Enterprise Edition	SQL Server 2005 Beta 2
LPS サーバー (2)	Dell 6650	2 GHz Xeon x 4	8 GB	直接接続 SCSI ディスク アレイ 146 GB x 5	Windows Server 2003 Enterprise Edition	SQL Server 2005 Beta 2
Web サーバー (3)	Dell 2650	2.4 GHz Xeon x 2	4 GB	ローカル ディスク	Windows Server 2003 Enterprise Edition	IIS 6.0
スケール アウト管理レイヤ サーバー	Dell 2650	2.4 GHz Xeon x 2	4 GB	ローカル ディスク	Windows Server 2003 Enterprise Edition
Web クライアント (12)	Dell 1650	1.4 GHz Pentium III x 2	2 GB	ローカル ディスク	Windows Server 2003 Standard Edition

表 3     コンピュータ構成

SAN 構成

EMC Clariion CX600
ディスク速度 : 10,000 RPM
ディスク サイズ : 146 GB
各バックエンド サーバーは、PCI-X が動作している 2 枚の HBA (「ホスト バス アダプタ (HBA)」を参照) を介して、2 Gbps の Switched SAN に接続されています。

表 4 は、スケーラビリティ テストにおける 4 台のデータベース サーバーのディスク レイアウトを示したものです。

ファイル グループ	拡張前のディスク アレイ レイアウト	拡張後のディスク アレイ レイアウト
ログと tempdb の RAID グループ	合計で 16 ディスク (RAID 10)。サーバーごとに 8 LUN (25 GB ずつ)。	合計で 24 ディスク (RAID 10)。サーバーごとに 8 LUN (25 GB ずつ)。
データ RAID グループ	合計で 24 ディスク (RAID 10)。サーバーごとに 8 LUN (40 GB ずつ)。	合計で 32 ディスク (RAID 10)。サーバーごとに 8 LUN (40 GB ずつ)。

表 4     データベース サーバーのディスク レイアウト

図 A-1 と図 A-2 は、バックエンド サーバーが 2 台から 4 台に拡張された結果、ストレージ構成が変化したことを示したものです。

図 A-1 **   2** 台のサーバーのディスク レイアウト

拡大表示する

図 A-2 **   4** 台のサーバーに対応するためのディスク グループの拡張

拡大表示する

ホスト バス アダプタ (HBA)

Emulex LP9802 Host Bus Adapter
バス速度 : 133/100/66 MHz
リンク速度 : 2 Gbps ファイバー チャネル