7

Railsベースのアプリケーションがあり、デプロイインフラストラクチャはAWSにバインドされます。現在のスキーマには、次のレイヤーが含まれています。

  • ロードバランサー（HaProxy）
  • Rails-アプリケーション（EC2）x2
  • MySQLdデータベース（EC2マスタースレーブ）
  • Redis、DelayedJobバックグラウンドプロセス
  • Wowzaメディアサーバー（EC2）
  • S3アセットストレージ（共有データ）

3つのSPFがあります：ロードバランサー、データベース、メディアサーバー。

私の質問は冗長性についてですが、どうすればSPFを減らすことができますか？

  1. ロードバランサー。セカンダリロードバランサーをセットアップする計画がありますが、ドメイン名は同じです。その場合、 DNS A / AAAAラウンドロビンフェイルオーバーは優れたソリューションですか？AWSロードバランサーは使いやすいですか？
  2. MMM（Multi-Master Replication Manager）は信頼できますか？Rails（独立したホストへの読み取り/書き込み）ではどのように機能しますか？
  3. Wowzaメディアサーバー、使用できる有名なHAソリューションはありますか？
4

3 に答える 3

6

私はこれらの質問が大好きです。実際にはそうではないのに、答えるのはいつもとても簡単に見えるからです。

手始めに、あなたの最大のSPFは、すべてがAmazonにあるということです。私は多くの理由でAWSが大好きですが、実際の可用性が必要なすべての状況で、基本的にAWSに100％依存することで自分自身を撃っています。したがって、最初の計画は、サービスを複数のプロバイダー（クラウド、VPS、または専用）に配布することです。

質問をしたいのですが、AWSがダウンした場合、気づいてから何かをするのにどれくらいの時間がかかりますか/できますか/しますか？また、サービスをバックアップして実行するのにどれくらいの時間が必要ですか？

私が尋ねる理由は次のとおりです。A/AAAAレコードのDNS負荷分散は素晴らしいソリューションです。残念ながら、SRV/MXレコードのように重みや優先順位を設定することはできません。つまり、AWSが完全に利用できなくなった場合、IPを削除するには、DNSをすばやく変更する必要があります。DNSプロバイダーがそれを可能にするAPIを持っている場合、それは自動化できます。一方、DNSキャッシングは非常に多くの場所で実行されるため、DNSを変更する価値がない可能性があります。つまり、1つのIPが使用できない場合（2つのAレコードがあると仮定）、50％から100％の可用性が得られます。一部のブラウザは、1番目が機能しない場合に2番目のIPを試すことができるためです。

私の意見では、AWSの優れた稼働時間を考慮すると、ドメインに2つの異なるIP（2つの異なるプロバイダー上）を割り当てることに責任はありません。1つのIPがダウンしているときに0％の可用性を確保するよりはましだと思いますが、それでもリクエストの50％を失うことに喜びはありません。

各プロバイダーに2つのロードバランサーを設定し、特定のインスタンス/サーバーがダウンした場合に、他のプロバイダーにリクエストを転送できるようにすることができます。つまり、両方のプロバイダーで機能するロードバランサーと、1つのプロバイダーで機能するサーバー/インスタンスのみが必要です。AWSへのレイテンシがあまりない代替プロバイダーを選択してください;）

MMMも優れたツールですが、Railsとはまったく関係ありません。個人的には、すべてのデータベースサーバーの前にロードバランサーを配置し、誰がリクエストを受け取るかなどを処理できるようにすることを好みます。データベースサーバー上のデータは非常に重要なので、通常は人間に見てもらい、すべてが正しいことを確認することをお勧めします。ツールに可用性や構成などを管理させるのではなく、問題が発生した場合はOKです。MMMは多くの状況で機能します。おそらく、試してみて、ニーズに合っているかどうかを確認する必要があります。悪いことは何も言えません。

私はWowzaメディアサーバーにまったく精通していませんが、クイック検索でいくつかのことが説明されました。WowzaはRTSP（UDPおよびTCP）を使用するため、HAProxyはTCPのみを実行するため、ソリューションではありません。一方、KeepalivedはUDPロードバランシングを実行できます（IVPS / LVSを使用します）。実際、クエリが長い場合は、データベーススレーブの負荷分散にもキープアライブを使用する必要があります。

最後に、S3ストレージなどのAWSのようなサービスを「独自にロール」する方法はたくさんあります。SPFの使用を避けたいが、AWSサービスと同じ機能が必要な場合は、Eucalyptus / Cloud.com / Openstack/GlusterFSなどのオープンソースバリアントの実行を検討する必要があります。これらすべての設定には多くの作業が必要ですが、「Xプロバイダーがダウンした場合、Yが引き継ぐことができる」と言うことができる日は幸せです。

于 2011-08-23T15:45:24.140 に答える
1

ここにいくつかの提案があります：

1）ロードバランサー：アプリケーションレベルの負荷分散の知識と、オンデマンドで新しいインスタンスを自動的に作成する機能を使用して、2つのha_proxyインスタンスを作成します。それらの前にAmazonElasticLoad Balancingをヘルスチェックで接続して、単一のha_proxy障害を回避します。1つが失敗したときに、新しいha_proxyインスタンスを動的にミックスします。

2）データベース：MySQLでプライマリの自動フェイルオーバーを処理する方法はないと思いますが、レプリカから読み取り、プライマリに書き込むためのレイヤーを導入すると、読み取り専用機能を維持できる可能性があります。プライマリがダウンしています。

3）Wowza：ヘルスチェックを使用してha_proxyレイヤーの背後にある複数のWowzaインスタンスの負荷を分散できるため、1回のWowza障害でメディアストリーミングが無効になることはありません。

于 2011-08-22T19:44:18.860 に答える
1

Scalariumには、SPFを劇的に削減するソリューションがあります。12ページのRails intheCloudで情報グラフィックを見ることができます。

  1. Amazon Elastic Load Balancerを使用して、ha_proxyインスタンス間をルーティングします。さらにセキュリティを強化するために、アプリケーションを複数のアベイラビリティーゾーンに分割できます。

  2. MySQLマスターマスターレプリケーションは最も簡単なことではありません。単一のマスターインスタンスを持ち、複数のアベイラビリティーゾーンに複数のスレーブを持つことができます。そうすれば、マスターがいなくなった場合でも、読み取りアクションをサポートできます。フェイルオーバーを備えた実際のマスターマスターは不可能だと思います。

  3. ha_proxyは、Wowzaインスタンスの負荷を分散できる必要があります。

于 2011-08-22T20:14:07.063 に答える