Analysis Services ソリューションのスケールアウト
Analysis Services のデータベース管理者 (DBA) がエンド ユーザー数の増加に合わせて、クエリの応答時間を短縮させたいと考えることは少なくありません。これを実現する方法としては、既存のサーバーの処理能力を強化する方法 (スケールアップ) と、複数の小規模サーバー間で負荷を分散する方法 (スケールアウト) の 2 とおりがあります。
通常、ソリューションのスケールアップは、既存のハードウェアを拡張またはアップグレードできなくなった場合に限界にぶつかります。たとえば、既存のマザーボードが新しいバージョンの CPU に対応していない場合や、メモリの物理アドレス空間がいっぱいになった場合などがそれに該当します。一方、ソリューションのスケールアウトはこれより柔軟で、比較的容易に制約を克服することができます。ネットワーク負荷分散 (NLB) のサーバー数が上限値に達した場合は、追加の NLB をソリューションに追加し、サーバーを複数の NLB 間で分散することができます。
このドキュメントでは、Analysis Services ソリューションをスケールアウトする場合の理論的なアーキテクチャについて説明します。
シナリオ
Analysis Services の DBA は、Analysis Services ソリューションのエンド ユーザーを対象に、データ更新のための毎日のダウンタイム期間を最小化しながら、クエリの応答時間を短縮する必要があります。ユーザー数は、過去 1 か月で当初の 80 人から倍増しており、今後 6 か月でさらに 2 倍に増えることが予想されています。7 か月後からは、ユーザー数が毎月 4% ずつ増加していく見込みです。Analysis Services データベースのサイズは現在 80 GB で、毎月 6 GB ずつ増大しています。データベースには、過去 12 か月間のデータが現在格納されており、今年度に加え過去 3 営業年度の履歴が保持される予定です。平均的な処理時間は 2 時間 30 分であり、ダウンタイム期間は 30 分に制限されています。
代替手段
このシナリオを読むと、サーバーをスケールアップすることが唯一のソリューションであると思えるかもしれません。スケールアップ ソリューションでは、サービスのダウンタイムがなくなりますが、処理速度は低下します。しかし、ユーザー数は現在 160 人で、この数は今後 6 か月で 320 人に倍増する予定です。7 か月目以降は、毎月 13 ～ 16 人のペースで増え続け、このペースがいつまで続くかは不明です。このペースが続いた場合、ユーザー数は 18 か月目と 19 か月目の間に再び 2 倍に達します。こうした状況では、正しいハードウェアのサイズを設定し、今後 12 か月間に 50% 未満の容量で使用される機器に対する予算要求を正当化することが難しくなります。
しかし、読み取り専用データベース機能を備えた SQL Server 2008Analysis Services を使用すると、このソリューションをスケールアウトすることが可能です。
スケールアウト アーキテクチャ
このアーキテクチャは、次の 2 つの要素で設計されています。
エンド ユーザーのスループットを最大化することを目標とした物理レイアウト
ダウンタイムを最小限に抑えることを目標とした運用フレームワーク
物理レイアウト
ソリューションは、次の 3 つの主要コンポーネントで構成されています。
処理環境
ストレージ エリア ネットワーク (SAN)
データ アクセス環境
最初のコンポーネントである処理環境では、SAN のセグメントを使用してデータが更新され、処理されます。2 番目のコンポーネントである SAN では、処理環境とデータ アクセス環境の両方に関連したデータが保存されます。3 番目のコンポーネントであるデータ アクセス環境では、エンド ユーザーがデータを使用できるようになります。
処理環境
処理環境は、単一のサーバー、SAN に対する接続、および Analysis Services データを格納する論理 SAN ボリュームによって形成されます。
ストレージ エリア ネットワーク (SAN)
このソリューションは、2 つの独立した "SAN 論理ボリューム" (一方は処理環境用、もう一方はデータ アクセス環境用) で構成されます。
SAN は、多次元データベース用の物理ストレージを提供するデバイスの集まりです。SAN を使用すると、共有ストレージ、クラスタ、データ復旧メカニズムなどのストレージとサーバーとの間に高速接続を実現できます。
このドキュメントでは、"SAN 論理ボリューム" という用語によって、オペレーティング システムで単一の物理ドライブと見なされるストレージ ユニットを定義します。
データ アクセス環境
データ アクセス環境は、同じ SAN 論理ボリュームを共有する複数のサーバーによって形成されます。通常、初期のサーバー数は 3 台です。ユーザーは、負荷分散アルゴリズムを使用してすべての受信要求をルーティングする NLB デバイスを介してデータ アクセス サーバーに接続します。
物理レイアウトのバリエーション
次のバリエーションを必要に応じて使用することによって、ソリューションのパフォーマンスを向上できる場合があります。
処理環境
リレーショナル データベース用に 1 台、Analysis Services データベースを格納するために 1 台というように、場合によっては 2 台の処理サーバーを使用できます。
また、リレーショナル データベースと多次元データベースを SAN に別々に格納するために、複数の論理ボリュームを定義することもできます。
データ アクセス環境
NLB デバイスごとに 3 台以上のデータ アクセス サーバーを使用して、2 つ以上の NLB をソリューションの一部として定義します。
運用フレームワーク
ソリューションの運用は、次の 3 つの段階に分かれています。
データ処理
ダウンタイム期間
データ処理のリセット
データ処理
この段階では、多次元データベースが更新され、処理されます。多次元データベースの内容を送信する準備が整うとすぐに、データ アクセス環境によってデータの転送処理が行われます。このプロセスは、次の手順で構成されます。
Analysis Services データベースをデータ処理サーバーからデタッチします。
Analysis Services データベースが格納されている論理 SAN ボリュームをオフラインにします。
ダウンタイム期間
この段階では、更新されたデータベースの内容が、元のデータベースの内容と交換されます。
すべての受信要求を拒否するように NLB を設定します。
Analysis Services データベースを各データ アクセス サーバーからデタッチします。
Analysis Services データベースが格納された論理 SAN ボリュームを各データ アクセス サーバーに対してオフラインにします。
SAN のコマンドを使用して、処理環境とデータ アクセス環境の間で論理 SAN ボリュームを交換します。
Analysis Services データベースが格納された論理 SAN ボリュームを、読み取り専用デバイスとして、各データ アクセス サーバーに対してオンラインにします。
Analysis Services データベースを ReadOnly モードで各データ アクセス サーバーにアタッチします。
すべての受信要求を受け入れるように NLB を設定します。
データ処理のリセット
この段階では、古い論理 SAN ボリュームの内容が更新され、処理環境でオンライン状態になります。
SAN のコマンドを使用して、データ アクセス環境の論理 SAN ボリュームを処理環境の論理 SAN に対してミラーリングします。
Analysis Services データベースが格納された論理 SAN ボリュームを、読み取り/書き込みデバイスとして、処理環境に対してオンラインにします。
Analysis Services データベースを ReadWrite モードで処理環境サーバーにアタッチします。