3

2 つのフロントエンド サーバー (米国に 1 つ、ヨーロッパに 1 つ) を持つかなり大きな Web サイト (200 万以上のページビュー/m、多数のユーザー) を考えてみましょう。2 つの専用 URL により、訪問者はサーバーの 1 つにアクセスできます。1 つはフランス語、もう 1 つは英語です。両方のサイトはまったく同じデータを共有しています。

最も費用対効果の高いソリューションは何ですか? （社内で使用しているDB：MySQL）

1/ Amazon EC2 (米国) 上の単一のマスター サーバーと、フロントエンド サーバー上のスレーブ?

  • 利点: マスターとマスターの担当者がいないため、自動インクリメントや一意の列での重複などとデータが競合するリスクがないことを意味します。

  • 短所：ラグ！あなたがヨーロッパにいるとき、アメリカで書くのにあまりにも多くの遅れがありますか? もう 1 つの欠点は、マスターが死亡した場合に備えて、迅速で汚れた解決策がないことです。また、フロントと同じサーバーにスレーブを配置するのはどうですか?

2/ 2 つの Amazon EC2 インスタンス。1 つは米国、もう 1 つはヨーロッパにあり、マスター/マスター レプリケーション サーバーとして機能します。さらに、各フロントエンドに 2 つのスレーブ?

  • Adv: データの速度とセキュリティ。もちろん、ロードバランサーはありませんが、マスターを別のマスターに切り替えるためのハックを作成するのはかなり簡単に思えます。

  • Drwbacks: 価格です。そしてDBの破損のリスク

3/ 他の解決策はありますか?

2 つの大陸でサーバーを扱うのは初めてなので、MySQL を含むかどうか、EC2 を含むかどうかなど、その分野での経験から学ぶことができれば幸いです。

ありがとうマーシャル

4

4 に答える 4

3

いつものように、私が言おうとしていることは、アプリやデータベースの使用方法などによって異なります。次のことを自問する必要があります。

  • 既製のソフトウェアを使用している場合、この状況で他の人は何をしましたか?
  • アプリはデータセット全体で動作する必要がありますか、それとも分割できますか?
  • アプリはマルチマスター レプリケーションを処理するように構築されていますか (通常は、自動インクリメント pk を使用することを意味します)
  • 更新/削除の衝突の可能性は? 費用は？
  • 読み書き比率は？書き込みの性質は何ですか？通常、操作は更新または追加ですか?

フランスのサーバーはヨーロッパにあり、英語のサーバーはアメリカにあると思いますか? フランス語のサイトが 1 つの DB を使用し、英語のサイトがもう 1 つの DB を使用するようにデータを分割できる場合は、より良い結果が得られます。衝突を心配する必要がないため、両方のサイトが両方の DB にアクセスする場合でも。各マスター サーバーで 2 つの mysql インスタンスを実行し、両方に対してマルチマスター レプリケーションを実行することもできます。

パーティション分割ができない場合は、おそらく #2 を使用しますが、マシンの 1 つを「真の」マスターとして指定し、すべての書き込みをそれに送信して、データの破損を回避します。このように、ピンチで簡単に切り替えることができます。

コストに敏感で、とにかくフロント エンド サーバーでレプリカを実行する場合は、フロント エンド サーバーでマスター データベースを実行するだけです。後でいつでもそれをやってのけることができます。多くの場合、レプリカは、同じ読み取り負荷を持つマスターよりも CPU/IO コストが高くなる可能性があります。レプリカは、書き込みをシリアルで実行する必要があるため、実際に問題が発生する可能性があります。

また、DB に m1.small インスタンスを使用しないでください。または、少なくともパフォーマンスに注目してください。m1.smalls は大幅に処理能力が低下しており、 を見るtopと、CPU 時間のかなりの割合がハイパーバイザーによって奪われていることに気付くでしょう。c1.medium をお勧めします。

于 2009-01-10T15:27:47.343 に答える
1

私たちは、Amazon Eastcoast が今週 2 回完全にネットから切り離された後、同様のシナリオを検討しています。つまり、複数のリージョンでレプリケートすることさえできず、RDB インスタンスを使用して私たちを利用可能にしました。

しかし、DRB は東から西への横断、さらにはヨーロッパへの横断を許可していません。

私たちは現在、1 つのマスターがフェールオーバーとしてのみ機能し、非常に高速に応答する dnsmadeeasy を介してフェールオーバーする、東西またはヨーロッパでのマスター マスターのアプローチを検討しています。

利点: 迅速で信頼性の高いフェールオーバー、短いダウンタイム、フェールオーバー機能の複雑な管理が不要。

欠点: それを使用せずに実行する余分なシステムが 1 つ必要ですが、RDB を使用する場合と比べてそれほど高価ではありません

DRB は、ポイント イン タイム リカバリなどを含め、Amazon によって適切に管理されています。DRB から切り替えると、すべてが失われます。しかし、複製が1つの領域内に限定され、その領域が完全に切り離されてしまうという問題があります。RDB バックアップの代替として、バックアップ管理を行う Zmanda オープン ソース ツールを検討しています。まだテストされていませんが、フェイルオーバーとデータベースとハードウェアに関するすべての詰め込みに基づいているため、これは高可用性のための最も単純で最も有望なアプローチのように見えます.

于 2011-08-11T02:44:41.733 に答える