2

サーバーのクラスターでスケーリングするための最良の戦略について考えています。厳格なルールがないことはわかっていますが、これらのシナリオについて人々がどう思うか興味があります。

  1. dnsmadeeasy を使用してバランス調整されたラウンド ロビン (フェールオーバーあり) のアプリ/データベース サーバーの組み合わせのクラスター。データベースはレプリケーションを使用して同期されます。クラスターに別のサーバーを追加することで容量を簡単に拡張できるという利点があり、当然フェールセーフです。

  2. アプリ サーバーのクラスター、ここでも dnsmadeeasy を使用してラウンド ロビン負荷分散 (フェールオーバーあり) を行い、すべて背後の大きな DB サーバーに報告します。アプリ サーバーを追加するのは簡単ですが、単一の db サーバーは単一の障害点を作成します。レプリケーションを使用してホット スタンバイを追加できる可能性があります。

  3. 2 つのデータベースを使用するアプリ サーバーのクラスター (上記のように)、1 つは読み取り専用、もう 1 つは書き込みのみを処理します。

また、追加のアイデアがあれば提案をお願いします。データはほとんどが非正規化されており、リレーショナルではなく、DB は 50/50 の読み取り/書き込みです。

4

3 に答える 3

3

2台の物理マシンを取り、それらをXenサーバーにします

  • A. Xen Base alpha
  • B.XenBaseベータ版

それぞれで3つの仮想マシンを実行します。

  1. statics（css、jpg、js ...）用の「web」サーバー+動的リクエスト用の負荷分散プロキシ（apache + mod-proxy-balancer、nginx + fair）
  2. 動的リクエスト用の「アプリ」サーバー（雑種、薄型、乗客）
  3. 「db」サーバー（mySQL、PostgreSQL ...）

次に、関数の分布は次のようになります。

  • A1はパブリックIPを所有し、A2とB2へのリクエストを処理します
  • B1はA1にpingを実行し、pingが失敗した場合は引き継ぎます
  • A2とB2は、A3にデータを照会する動的リクエストを受け取ります
  • A3は専用のデータサーバーです
  • B3はA3を2秒ごとにバックアップし、コピーやバックアップなどを作成するための読み取り専用アクセスを提供します。B3はA3にpingを送信し、A3が到達不能になった場合にマスターになります。

これが何らかの形で役立つか、少なくともいくつかのアイデアが得られることを願っています。

于 2009-05-08T07:33:00.200 に答える
2

それは本当にあなたのアプリケーションに依存します。

私は会社のためにさまざまな手法に少し時間を費やしましたが、(今のところ) 決めたのは、すべて単一のマスター DB を指す Web サーバーのクラスターの前でリバース プロキシ/ロードバランサーを実行することです。理想的には、DB がマスター/スレーブ構成でセットアップされ、問題が発生した場合にスレーブをマスターに昇格できるソリューションが必要です。したがって、オプション 2 ですが、スレーブ DB を使用します。また、高可用性を実現するには、DNS ラウンド ロビンである 2 つのリバース プロキシが適しています。単純なラウンド ロビンではなく、「公平な」アルゴリズムを備えたロード バランサーを使用することをお勧めします。スループットが向上します。DB の負荷を分散するソリューションもありますが、それらはやや複雑になる可能性があるため、必要になるまで避けます。

Rightscale は、この種のものに関する優れたドキュメントを以下で入手できます: http://wiki.rightscale.com/ 彼らは、クラウド ホスティング ソリューションにこれらのタイプのサービスを提供します。

これらの 2 つのエントリと写真が特に役立つと思います。

「簡単な」セットアップ:
http://wiki.rightscale.com/1._Tutorials/02-AWS/02-Website_Edition/2._Deployment_Setup

「高度な」セットアップ:
http://wiki.rightscale.com/1._Tutorials/02-AWS/02-Website_Edition/How_do_I_set_up_Autoscaling%3f

于 2009-05-08T15:27:31.157 に答える
1

データベース側についてのみコメントします。

通常の RDBMS では、DB の 50/50 の読み取り/書き込み負荷により、オーバーヘッドの点でレプリケーションが「高価」になります。ほとんどの場合、単純なフェイルオーバー ソリューションを使用する方が、アクティブ/アクティブ DB セットアップをレプリケートするよりもコストがかかりません。管理/メンテナンスとライセンス コスト (該当する場合) の両方の観点から。

データは「ほとんど非正規化されており、リレーショナルではない」ため、列ベースのキー/値データベース システムであるGoogle Bigtableの OSS 実装であるHBaseを見ることができます。HBase は、 Google GFSの OSS 実装であるHadoopの上に構築されています。

どのソリューションを使用するかは、Hadoop が潜在的に数千のノードにスケーリングすることを意図しているが、はるかに少ない数で実行する必要がある、予想される容量の増加によって異なります。

私は、アクティブ/アクティブのレプリケートされた DB、単一書き込み/多読み取り DB、および単純なフェールオーバー クラスターを管理してきました。単純なフェールオーバー クラスターを超えると、フェールオーバー セットアップでは決して見られない潜在的な問題の新しい次元が開かれます。

従来の SQL RDBMS を使用する場合は、大量のメモリを備えた比較的 "大規模な" サーバーを使用し、それをフェールオーバー クラスターにすることをお勧めします。書き込み率が減少した場合は、フェールオーバー書き込みクラスターと読み取り専用サーバーのファームを使用できます。

答えは細部にあります。アプリケーションの CPU または I/O バウンドはありますか? テラバイトのストレージが必要ですか、それとも数 GB しか必要ありませんか?

于 2009-05-08T16:07:12.390 に答える