SQL Server 2008レプリケーションをNLBで使用して、レポートサーバーの無制限のスケーリングを可能にすることはできますか？
現在、SQL Server 2008でトランザクションレプリケーションを使用して、セカンダリレポートサーバーをプライマリデータベースサーバーと同期させています。これはうまく機能しており、プライマリサーバーの負荷の一部を抑えています。このソリューションを複数のレポートサーバーに拡張することは可能でしょうか？読み取り専用クエリの負荷が増えると予想されます。必要に応じてレポートサーバーを追加できると便利です。
一般的な考え方は次のとおりです。
- 各レポートサーバーは、「プル」サブスクリプションを使用して、プライマリデータベースパブリケーションからデータを取得します。これらのレポートデータベースは、問題なくプライマリサーバーから数分遅れる可能性があります。
- レポートサーバーは一緒にNLBされます。すべての読み取り専用クエリはNLBに送信され、NLBはサーバー全体に負荷を分散する必要があります。
私には、それがうまくいくように聞こえます。 NLB名へのクエリのみを実行している限り。ただし、MS SQLの展開とアーキテクチャのドキュメントを詳しく調べて、「Xを実行し、Yを実行しないように注意して、この方法でビルドする」または「機能しない」と書かれているものがあるかどうかを確認します。フロブのせいで全然。」
複数のサーバーでReportingServicesを実行し、それらすべてが単一のデータベースエンジンサーバーにクエリを実行する方がはるかに良いのではないでしょうか。
RSが同じマシンでDEを使用する必要はまったくありません。
NLBing Reporting Servicesについて：はい、できますが、いくつかの注意点があります。 http://technet.Microsoft.com/en-us/library/cc281307.aspx を参照してください。
通常のボトルネックはディストリビューターです。パブリッシャーが独自のディストリビューターとして機能しないようにしてください。ディストリビューターにかかるサブスクライバーの負荷を（「無制限」に）スケーリングすることが非常に重要になります。 1つの解決策は、配布をステージングし、サブスクライバーの1つ（またはそれ以上）をパブリッシャー/ディストリビューターとしても機能させることです。このようにして、元のディストリビューターにさらに負荷をかけることなく、この中古出版物のサブスクライバーとしてより多くのサブスクライバーを追加できます。
ただし、Reporting Servicesのキャッシュ機能とスケールアウト用の広範な組み込み機能（ スケールアウト展開の計画 を参照）を考えると、そのようなレプリケーショントポロジが本当に必要かどうか疑問に思う必要があります。