多次元モデル ソリューションの配置要件の確認

  • [アーティクル]

あるソリューションのパフォーマンスと可用性は、多くの因子に左右されます。たとえば、基になるハードウェアの機能、サーバーの配置トポロジ、ソリューションの特性 (たとえば、パーティションが複数サーバーに分散されているとか、リレーショナル エンジンへの直接アクセスを必要とする ROLAP ストレージを使用するなど)、サービス レベル契約、データ モデルの複雑さなどです。

メモリおよびプロセッサの要件

次のような場合、Analysis Services にはより大きなメモリおよびプロセッサ リソースが必要です。

  • 大規模または複雑なキューブを処理する場合。 このようなキューブには、小規模または単純なキューブよりも大きなメモリおよびプロセッサ リソースが必要です。

  • 1 つのデータベース内のキューブ数が増加した場合。

  • Analysis Services の 1 つのインスタンス内のデータベース数が増加した場合。

  • 1 つのコンピューター上の Analysis Services のインスタンス数が増加した場合。

  • Analysis Services リソースに同時にアクセスするユーザー数が増加した場合。

Analysis Services で使用可能なメモリおよびプロセッサ リソースの量は、SQL Server のエディション、オペレーティング システム、ハードウェアの機能、および仮想プロセッサまたは物理プロセッサのどちらを使用しているかによって異なります。 詳細については、次のリンクを参照してください。

SQL Server 2012 のインストールに必要なハードウェアおよびソフトウェア

SQLServer のエディション別の計算容量制限

SQL Server 2012 の各エディションがサポートする機能

最大容量仕様 (Analysis Services)

必要なディスク領域

Analysis Services インストールのさまざまな側面とオブジェクト処理に関連するタスクによって、必要なディスクの空き容量が異なります。 次の一覧では、このような要件について説明します。

  • キューブ
    大きなファクト テーブルを持つキューブでは、小さなファクト テーブルを持つキューブよりも大きなディスク空き容量が必要です。 同様に、小さなエクステントでも、多くの大きなディメンションを持つキューブでは、ディメンション メンバーが少ないキューブよりも大きなディスク空き容量が必要です。 通常、Analysis Services データベースでは、基になるリレーショナル データベースに保存されている同じデータに必要な空き容量の約 20% が必要です。

  • 集計
    集計では、追加される集計に比例した空き容量が必要であり、集計が多くなるほど、大きな空き容量が必要です。 不要な集計を作成しないようにするには、通常、集計に必要な追加の空き容量が、基になるリレーショナル データベースに保存されているデータのサイズの約 10% を超えないようにする必要があります。

  • データ マイニング
    既定では、マイニング構造によって、トレーニングされるデータセットがディスクにキャッシュされます。 このキャッシュされたデータをディスクから削除するには、マイニング構造オブジェクトで [構造消去の処理] の処理オプションを使用できます。 詳細については、「処理の要件および注意事項 (データ マイニング)」を参照してください。

  • オブジェクトの処理
    Analysis Services では、処理が終了するまで、処理トランザクションで処理中のオブジェクトのコピーがディスクに保存されます。 処理が終了すると、オブジェクトの処理済みのコピーによって元のオブジェクトが置き換えられます。 このため、処理する各オブジェクトの 2 番目のコピー用に十分な空き容量を確保する必要があります。 たとえば、1 つのトランザクションでキューブ全体を処理する場合、キューブ全体の 2 番目のコピーを保存するために十分なハード ディスク容量が必要です。

トップに戻る

可用性に関する注意点

Analysis Services 環境では、ハードウェアまたはソフトウェアの障害によって、キューブまたはマイニング モデルをクエリに使用できない場合があります。 また、キューブも処理する必要があるので使用できない場合があります。

ハードウェアまたはソフトウェアの障害時における可用性の提供

ハードウェアやソフトウェアでは、さまざまな理由により障害が発生します。 ただし、Analysis Services インストールの可用性を維持すると、そのような障害の原因をトラブルシューティングできるだけでなく、障害が発生した場合にユーザーがシステムの使用を続行できるように代替のリソースを提供することもできます。 サーバーのクラスター化と負荷分散は、通常、ハードウェアまたはソフトウェアの障害が発生した場合に可用性の維持に必要な代替のリソースを提供するために使用されます。

ハードウェアまたはソフトウェアの障害が発生した場合に可用性を維持するには、Analysis Services をフェールオーバー クラスターに配置することを検討してください。 フェールオーバー クラスターでは、なんらかの理由でプライマリ ノードで障害が発生した場合や、プライマリ ノードを再起動する必要がある場合、Microsoft Windows のクラスター化によってセカンダリ ノードにフェールオーバーされます。 フェールオーバーは非常に短時間で行われ、その後にユーザーがクエリを実行すると、そのクエリはセカンダリ ノードで実行されている Analysis Services のインスタンスにアクセスします。 フェールオーバー クラスターの詳細については、「Windows Server テクノロジ: フェールオーバー クラスター」を参照してください。

可用性の問題に対する別の解決方法としては、Analysis Services プロジェクトを 2 つ以上の実稼働サーバーに配置することです。 Windows サーバーのネットワーク負荷分散 (NLB) 機能を使用して、実稼働サーバーを 1 つのクラスターに結合できます。 NLB クラスターでは、クラスター内のサーバーがハードウェアまたはソフトウェアの問題が原因で使用できない場合、NLB サービスによって使用可能なサーバーにクエリするように指示されます。

構造的変更の処理時における可用性の提供

キューブに特定の変更を行うと、キューブが処理されるまで使用できなくなることがあります。 たとえば、キューブ内のディメンションに構造的変更を行うと、ディメンションを再処理した場合でも、変更したディメンションを使用する各キューブも処理する必要があります。 このようなキューブを処理しない限り、そのキューブをクエリできません。また、変更したディメンションが含まれているキューブに基づいたマイニング モデルもクエリできません。

Analysis Services プロジェクトの 1 つまたは複数のキューブに影響を与える可能性がある構造的変更を処理しているときに可用性を確保するには、ステージング サーバーを組み込むか、データベースの同期ウィザードを使用することを検討してください。 この機能を使用すると、ステージング サーバー上でデータとメタデータを更新し、実稼働サーバーとステージング サーバーの同期をオンラインで実行できます。 詳細については、「Analysis Services データベースの同期」を参照してください。

ソース データの増分更新を簡単に処理するには、プロアクティブ キャッシュを有効にします。 プロアクティブ キャッシュでは、新しいソース データを使用してキューブが更新されます。手動での処理は必要なく、キューブの可用性に影響を与えることもありません。 詳細については、「プロアクティブ キャッシュ (パーティション)」を参照してください。

トップに戻る

スケーラビリティに関する注意点

同じコンピューター上に Microsoft SQL Server と Analysis Services の複数のインスタンスがあると、パフォーマンスの問題が発生する場合があります。 このような問題を解決する 1 つの方法は、サーバー上のプロセッサ、メモリ、およびディスク リソースを増やすことです。 ただし、複数のコンピューターで SQL Server と Analysis Services のインスタンスをスケーリングすることが必要な場合もあります。

複数のコンピューターにおける Analysis Services のスケーリング

複数のコンピューターで Analysis Services のインストールをスケーリングするには、いくつかの方法があります。 これらのオプションについては、次の一覧を参照してください。

  • 1 つのコンピューターに Analysis Services の複数のインスタンスがある場合は、1 つまたは複数のインスタンスを別のコンピューターに移動できます。

  • 1 つのコンピューターに複数の Analysis Services データベースがある場合は、1 つまたは複数のデータベースを別のコンピューターの Analysis Services の独自のインスタンスに移動できます。

  • 1 つまたは複数のリレーショナル データベースから Analysis Services データベースにデータが提供される場合は、これらのデータベースを別のコンピューターに移動できます。 データベースを移動する前に、Analysis Services データベースと基になるデータベース間に存在するネットワークの速度と帯域幅を検討してください。 ネットワークが低速であるか混雑している場合、基になるデータベースを別のコンピューターに移動すると、処理のパフォーマンスが低下します。

  • 処理がクエリのパフォーマンスに影響を与えるが、クエリの負荷が低いときに処理できない場合は、処理タスクをステージング サーバーに移動し、実稼働サーバーとステージング サーバーの同期をオンラインで実行することを検討してください。 詳細については、「Analysis Services データベースの同期」を参照してください。 また、リモート パーティションを使用して、Analysis Services の複数のインスタンスに処理を分散することもできます。 リモート パーティションの処理では、ローカル コンピューターのリソースではなく、リモート サーバーのプロセッサおよびメモリ リソースを使用します。 リモート パーティションの管理の詳細については、「多次元モデル パーティション管理」を参照してください。

  • クエリのパフォーマンスは低いが、ローカル サーバーのプロセッサおよびメモリ リソースを増やすことができない場合は、2 つ以上の実稼働サーバーに Analysis Services プロジェクトを配置することを検討してください。 ネットワーク負荷分散 (NLB) を使用して、サーバーを 1 つのクラスターに結合できます。 NLB クラスターでは、クエリは NLB クラスター内のすべてのサーバーに自動的に分散されます。

トップに戻る