web-dev-qa-db-ja.com

IIS / SQLServerアプリケーションをスケールアップするための最良の方法

ASPおよびSQLServerで開発したアプリケーションがあります。Rackspaceを使用してホストします。各「顧客」には独自のIISサイトとSQLデータベース。各顧客は、アプリケーションにアクセスするユーザーが数十人または数百人いる可能性があります。

現在、数百のお客様がいます。これまで行ってきたことは、パフォーマンス上の理由で必要なときに、サーバーの別のペア（1つのIIS、1つのSQL）を追加することです。現在、最大4ペアのサーバーになっています。

私たちは新しい顧客を追加し続けており、サーバーのペアを追加するだけでスケールアップする別の方法を検討しています。

検討しているアプローチの1つは、IIS側にWebファームを用意し、データベース側にSQL ServerクラスターとSANを用意することです。

これは良いアプローチですか？現在、400人の顧客がいて、それぞれが独自のIISサイトとSQLデータベースを持っています。1,000に増えたらどうなるでしょうか？5,000？1つのSQLクラスターで数千のデータベースを処理できますか？

各データベースには数百のテーブルがあります。一部の大口顧客のメインテーブルには、数十万のレコードがある場合があります。

大きなIIS Webファームと大きなSQLクラスターに移行することの魅力の1つは、1つのサーバーがダウンした場合、他のサーバーが負荷を負担する可能性があることです。現在、SQLサーバーの1つがダウンした場合、または、IISサーバーの1つがダウンし、顧客の4分の1がシステムを使用できなくなったため、信頼性を高め、新しい顧客を追加する能力を高めたいと考えています。

sql-serveriisscaling
2
user35697

SQL Serverクラスターはスケーラビリティソリューションではなく、厳密には高可用性ソリューションです。 SQL Serverクラスターでは、1つのノードのみがアクティブで負荷を処理し、他のすべてのノードはパッシブスタンバイであり、アクティブノードにハードウェア障害が発生した場合に備えて待機します。そのため、SQL Serverクラスターからは、せいぜい単一のSQLServerインスタンスのパフォーマンスが得られます。いわゆる「アクティブ-アクティブ」デプロイメントへの参照が見つかることもありますが、それはSQLServerクラスターではありません。いわゆる「アクティブ-アクティブ」は、2つの別々のクラスターであり、互いのノードを逆の役割で使用します（1つのクラスターはノードAでアクティブで、Bでパッシブです）。 、もう一方はアクティブBで、パッシブA）です。

アプリケーションがすでにパーティション化されていて、各顧客が個別のデータベースを持っている場合は、スケールアウトを継続する方がはるかに良いでしょう。管理とメンテナンスの問題に対処できます。4台のサーバーの管理を自動化すると（つまり、現在）、1000台のサーバーの管理を自動化できます。バージョン管理、展開、アカウントプロビジョニングの問題も同様です。

現在、スケールアップソリューションからの管理、トラブルシューティング、および調整の容易さに惹かれるかもしれませんが、新しい問題が発生し、解決がより困難になり、スケールアップできる高さの制限に至ります。

更新スケールアウトに関連する懸念事項の説明とともにOPを編集した後。

実際、スケールアップとクラスタリングは高可用性ソリューションを提供します。 SQL Serverには、基本的に2つのHAソリューションがあります。クラスタリングとデータベースミラーリングです。何千もの個別のデータベースを計画しているので、これはミラーリングをほとんど除外します。ただし、SQL Serverクラスターは ハードウェアの組み合わせ の制限されたリストでのみサポートされていることに注意する必要があります。

Microsoftサーバークラスターは、WindowsServerカタログの[クラスターソリューション]にリストされているクラスターソリューションでのみサポートされます。 Windows Serverカタログを表示するには、次のMicrosoft Webサイトにアクセスしてください。 http://www.windowsservercatalog.com/

これは、共有SCSIバスを持つハードウェアペア/グループでクラスターを実行できないという意味ではありません。これは、承認されていないハードウェアに問題がある場合、MicrosoftCSSにサポートを要求できないことを意味します。

SQL Serverクラスタリングは、メディア障害を除くハードウェア障害に対する保護を提供します（メディアはノード間で共有されるため）。それが保護を提供しないのは、残念ながらダウンタ​​イムの主な理由である人間の管理エラーです。 1つのクラスターに1,000の顧客データベースがあるため、1つのバスケットで非常に大きなオムレツを調理できます...

クラスターで実行できるデータベースの数について質問すると、最終的にクラスターには常にアクティブなインスタンスが1つしかないため、単一のインスタンスの制限がクラスターにも適用されます。 1000個のデータベースを接続することは大きな問題ではありません。本当の問題は、負荷、つまりクエリを同時に実行するユーザーの数です。数字の球場領域を取得するには、SQL Server用に公開されたTPC-Cベンチマークが64ウェイSuperdomeで1分あたり約120万トランザクション、つまり1秒あたり約16kトランザクションであると考えてください。約5,000のクライアントが接続されていると予想します。これにより、クライアントあたり1秒あたり3クエリのマージンが得られます。そのためには、非常に優れたハードウェアと例外的に適切に調整されたアプリケーションが必要です。

2
Remus Rusanu

以前のポスターに同意します。スケーリングについてもっと考え始める必要がある状況にあるように聞こえます。しかし、今のような環境があれば、現在の時間の多くを自動化に費やし、自分の環境を確実に俯瞰できるようにすることになります。どのようにスケールアウトすることを選択したとしても、プロセスのスクリプト作成と自動化を行わないと、管理上の悪夢に遭遇することになります。

実際のスケール戦略に関しては、次のような設定が考えられます。

1）すべての顧客のWebファイルはすべてのWebサーバー上にあります

2）すべてのサーバーでIIS）で構成されたすべての顧客のWebサイト

3）顧客のWebファイルへの変更はすべてのWebサーバーに同期されます

4）次のWeb構成

          - - - - - - - - - - - - - -
         |      Load Balancer       |
          - - - - - - - - - - - - - -
                        |
                        |
 - - - -    - - - -     - - - -     - - - -
| web |   | web |   | web |   | web |
 - - - -    - - - -     - - - -     - - - -
    |            |             |            |
          - - - - - - - - - - - - - -
         |      SQL Cluster          |
          - - - - - - - - - - - - - -
                      |
                      |
          - - - - - - - - - - - - - -
         |    Warm SQL Cluster    |
          - - - - - - - - - - - - - -

次に、SQL Clusterの制限を確認し始めたら、新しいSQL Clusterを作成し、データベースを2つのクラスターに分割し、顧客の接続文字列を変更して、それぞれのクラスターを指すようにします。

ここでの考え方は、ロードバランサーに最善を尽くさせ、トラフィックをWeb層に分散させることです。トラフィックが増加するにつれて、常に新しいWebサーバーをローテーションに投入して、少しバランスを取ることができます。ここで重要なのは、すべてのWebサーバーの同期を維持することです。

また、データベースサーバーに最善を尽くさせ、行き詰まり始めたら、新しいサーバー\クラスターをミックスに追加して作業のバランスを取ります。ウォームSQLServerはある程度の冗長性を提供しますが、それが本当に必要かどうかについては、ここで私と意見の相違があるかもしれません。

最近、Foursquareとそれらがどのように負荷を分散するかについての記事がありました。彼らは基本的に、MongoDBでは別々のサーバーであるパー​​ティション間でユーザーを分散させるアプローチを使用しています。これは、たまたまヘビーユーザーであり、同じパーティション（シャード）にいるユーザーのグループがシャードを限界に達するまでダウンさせるまで、彼らにとってはかなりうまく機能しました。もちろん、もう少し多くのことがありましたが、要点は、マシン間で分散し、使用状況を監視して、負荷を分割して再バランスするタイミングがわかるようにすることでした。

とにかく....それは私の2セントです。

1
Sage

アマゾンウェブサービスのEC2や補完的なデータベースおよびストレージサービスのようなクラウドソリューションを検討することをお勧めします。スケーリングは非常に簡単で、完全にプログラム可能です。カスタムダッシュボードを構築して、すべてのサーバーを管理し、必要に応じてスケールアップすることができます。使用した分だけ支払い、IISを含むWindowsおよびLinuxプラットフォームをサポートします。複数のサーバーにスケールアウトする必要がある場合、または東海岸と西海岸、さらにはヨーロッパでサーバーをホストすることによって地理的な冗長性を提供する必要がある場合は、独自のカスタムイメージを構築できます。 Rackspaceにも同様のソリューションがありますが、Windowsサポートがまだリリースされているかどうかはわかりません。リリースされている可能性があります。私は両方を試しましたが、Amazonの方が柔軟で包括的であることがわかりましたが、すでにRackspaceを使用しているので、もっと理にかなっているかもしれません。幸運を！

0
John Virgolino