Analysis Services の高可用性とスケーラビリティ

適用対象: SQL Server Analysis Services Azure Analysis Services Fabric/Power BI Premium

この記事では、Analysis Services データベースを高可用性およびスケーラブルにするための最も一般的に使用される手法について説明します。 それぞれの目的に個別に対処できますが、実際のところ、この 2 つはほとんどのケースで連携しています。つまり、大規模なクエリまたは処理ワークロードをスケーラブルな方法で配置すると、通常は、高可用性を期待できます。

ただし、その逆については必ずしも正しいとは限りません。 ミッションクリティカルで中程度のクエリ ワークロードに対して厳格なサービス レベル契約が存在する場合は、スケーラビリティが伴わない高可用性が唯一の目的になることがあります。

Analysis Services で高可用性とスケーラビリティを確保する手法は、すべてのサーバー モード (多次元、表形式、および SharePoint 統合モード) で同じになる傾向があります。 特に明記しない限り、この記事の情報はすべてのモードに適用されます。

重要なポイント

可用性とスケーラビリティの手法はリレーショナル データベース エンジンの手法とは異なるため、Analysis Services で使用される手法の導入部として、重要なポイントを簡単に説明しておきます。

• Analysis Services では、Windows のサーバー プラットフォームに組み込まれている高可用性とスケーラビリティ メカニズムであるネットワーク負荷分散 (NLB) または Windows Server フェールオーバー クラスタリング (WSFC)、あるいはその両方が使用されます。

  注意

  リレーショナル データベース エンジンの Always On 機能は、Analysis Services には拡張されません。 また、Analysis Services インスタンスを、Always On 可用性グループで実行されるように構成することはできません。

  Analysis Services は、Always On 可用性グループで実行されませんが、Always On リレーショナル データベースからデータを取得して、処理することはできます。 高可用性リレーショナル データベースを、Analysis Services で使用できるように構成する方法の手順については、「 Analysis Services と Always On 可用性グループ」をご覧ください。

• フェールオーバー クラスターでサーバーの冗長性が確保されている場合は、唯一の目的として高可用性を実現できます。代替ノードのハードウェアおよびソフトウェアの構成は、アクティブ ノードと同じと見なされます。 WSFC はそれ自体で高可用性を提供しますが、スケーラビリティは確保されません。

• 可用性の有無にかかわらず、スケーラビリティは、読み取り専用データベースよりも NLB によって実現されます。 スケーラビリティが心配になるのは、通常、クエリ量が多く、急激なスパイクの影響を受けやすい場合です。

  負荷分散と複数の読み取り専用データベースを組み合わせると、スケーラビリティと高可用性の両方を実現できます。すべてのノードがアクティブになり、1 台のサーバーで障害が発生しても、残りのノードに要求が自動的に再分散されるためです。 スケーラビリティと可用性の両方が必要な場合、NLB クラスターを選択するのが適切です。

処理については、操作のタイミングとスコープを制御できるため、高可用性とスケーラビリティはそれほど心配する必要はありません。 モデルは部分処理と増分処理の両方が可能ですが、ある時点で、単一サーバーでモデル全体を処理して、すべてのインデックスと集計でデータの整合性を確保する必要があります。 堅牢でスケーラブルなアーキテクチャは、どのような負荷のパターンも完全に処理できるハードウェアに依存します。 大規模なソリューションでは、この作業は、独自のハードウェア リソースを備えた独立した操作として構成されます。

単一サーバーとマルチサーバーの構成

通常の単一サーバーデプロイでは、両方のアクティビティにシステム リソースで十分であると仮定して、処理ワークロードとクエリ ワークロードが同時に実行されます。 Analysis Services の既存のデータ構造はそのままでクエリをサポートし、更新バージョンの処理はバックグラウンドで実行されます。 一時的なデータ構造を処理するための十分なメモリとディスク領域を確保するというハードウェア要件はすべてのサーバー モードに共通して存在しますが、システム リソースに対する要求や NUMA 対応レベルは、モードによってそれぞれ異なります。

単一サーバーとスケーラビリティ

単一のハイエンド、マルチコア サーバーは、それ自体で十分なスケーラビリティが用意されていることがあります。 多数のコア、RAM、およびディスク領域を備えたハイエンド システムでは、単一システム内でスケール アップできる可能性があります。

多次元データベースの場合は、サーバー構成プロパティを調整して、プロセスとプロセッサの間にアフィニティを作成できます。 詳細については、「 スレッド プール プロパティ 」をご覧ください。

マルチサーバーの配置

運用上の要件で複数のサーバーを使用するように指定されることがあります。 たとえば、定義上、フェールオーバー クラスターはマルチサーバーであり、同じハードウェアおよびソフトウェア構成で各ノードが実行されています。

同様に、クエリのワークロードの高可用性が重要な要件となっている場合も、通常、複数のサーバーが必要です。 このシナリオでは、Analysis Services の推奨構成として、Analysis Services の個別のインスタンスで実行される読み取り専用データベースと読み取り/書き込みデータベースを専用ハードウェア上で組み合わせて使用することをお勧めします。 読み取り専用データベースはクエリ要求を処理します。 一方、読み取り/書き込みデータベースは、処理実行に使用されます。 よく使用されるこの手法の詳細については、次のセクションで説明します。

仮想マシンと高可用性

高可用性の要件に満たすためのもう 1 つの戦略として、仮想マシンを使用することもできます。 代替サーバーを数時間 (数分ではありません) で起動して可用性に対応できる場合は、要求時に開始可能な仮想マシンが使用できる可能性があります。この仮想マシンには、一元化された場所から取得された最新のデータベースを読み込むことができます。

読み取り専用データベースと読み取り/書き込みデータベースを使用したスケーラビリティ

ネットワーク負荷分散は、クエリと処理のワークロードが多い場合、またはこれをエスカレートする場合にお勧めします。 NLB ソリューションの Analysis Services のデータベースは、クエリ間の一貫性を確保するために、読み取り専用のデータベースとして定義されます。

「 Scale-out querying for Analysis Services using read-only databases 」(読み取り専用データベースを使用して Analysis Services クエリをスケール アウトする)(2008 年公開) のガイダンスはかなり前のものですが、基本的にはまだ利用できます。 サーバーのオペレーティング システムやコンピューター ハードウェアは進化しているため、プラットフォーム、CPU 制限に関する説明の中には古いものもありますが、読み取り専用データベースと読み取り/書き込みデータベースで大量のクエリを処理する方法は基本的には変わっていません。

このアプローチをまとめると次のようになります。

• 専用のハードウェアと Analysis Services のインスタンスを使用して、データベースを処理します。 処理完了後、データベースを読み取り専用に設定します。 手順については、「 Analysis Services データベースの ReadOnly モードと ReadWrite モードの切り替え 」をご覧ください。

• 複数の同じクエリ サーバーを使用して、同じ読み取り専用 Analysis Services データベースのコピーを実行します。 サーバーは NLB クラスターに展開され、クラスターへの単一のエントリ ポイントとして機能する 1 つの仮想サーバー名を介してアクセスされます。

• robocopy を使用して、データ ディレクトリ全体を、処理サーバーから各クエリ サーバーにコピーし、同じデータベースを読み取り専用モードですべてのクエリ サーバーにアタッチします。 SAN スナップショット、同期、または実稼働データベースの移動に使う他のツールまたは方法を使用することもできます。

表形式および多次元ワークロードに対するリソース要求

次の表では、Analysis Services がクエリと処理でシステム リソースをどのように使用しているかを、サーバー モードとストレージ モードに分けて大まかに説明します。 これは、分散ワークロードを処理するマルチサーバー配置での重要事項を把握するうえで役立ちます。

WSFC による高可用性と冗長性

Analysis Services は、最短時間でサービスを復元する高可用性を実現するために、既存の Windows Server フェールオーバー クラスター (WSFC) サービスにインストールできます。

フェールオーバー クラスターは、データベースへのフル アクセス (読み取りと書き戻し) を 1 ノードずつ提供します。 最初のノードがダウンした場合、セカンダリ データベースは、クラスター内の追加ノードで代替サーバーとして実行されます。

フェールオーバー クラスタリングの主なメリットは、サービスの障害から迅速に回復できることです。 この利点には、制限がいくつか伴います。 その 1 つとして、フェールオーバーが不要な場合は、クラスター内の専用リソースがアイドル状態になります。 また、フェールオーバーが発生すると、すべての接続と、その接続に対応するコミットされていない作業が失われます。 ほとんどの場合、この状況はクライアント アプリケーションで処理することができます。通常、アプリケーションで更新ボタンを押すことによって、再び結果が表示されます。

WSFC を検討する場合は、次の点に留意してください。

• アクティブ/アクティブは現在サポートされていません。 Analysis Services でサポートされている WSFC 構成は、アクティブ/パッシブ (フェールオーバー) のみです。
• Analysis Services をクラスター化するときは、クラスターに参加するすべてのノードが同じハードウェアまたは非常によく似たハードウェアで実行され、各ノードの操作コンテキストがオペレーティング システムのバージョンとサービス パック、Analysis Services のバージョンとサービス パック (または累積更新プログラム)、およびサーバー モードに関して同じであることを確認してください。
• パッシブ ノードを別のワークロードのアクティブ ノードとして再利用しないでください。 ノードが両方のワークロードを処理できないと、実際のフェールオーバー状況が発生した場合に、コンピューター使用率の短期的な効果が失われます。

フェールオーバー クラスターで Analysis Services を配置するための詳細な手順と背景情報については、ホワイトペーパー「 SQL Server Analysis Services をクラスター化する方法」をご覧ください。 このガイダンスは SQL Server 2012 を対象にしていますが、最新バージョンの Analysis Services にも引き続き適用されます。

参照

Analysis Services データベースの同期
Forcing NUMA Node affinity for Analysis Services Tabular Databases (Analysis Services 表形式データベースに対する NUMA ノード アフィニティの強制)
An Analysis Services Case Study: Using Tabular Models in a Large-scale Commercial Solution (Analysis Services のケース スタディ: 大規模な商用ソリューションにおける表形式モデルの使用)