15

Ec2 で Web アプリを管理するための費用対効果の高いツールを探しています。Rightscale は大きな犬のように見え、料金を請求します。Scalr はより費用対効果の高いソリューションのように見えますが、実際の顧客体験を見つけるのは困難です..

私が探している重要な側面は、ロード バランサー (http および https) と、負荷が増加したときに追加の Web サーバーの容量を自動的にオンラインにし、負荷が低下したときにインスタンスを終了する方法です。

私が知る限り、多くの人がここで独自のものを展開しています。私たちはアプリをリリースしようとしていますが、あまりにも多くの重いシステム管理者の戦いを戦う必要はありません. パフォーマンスなどの重要性を考えると、これについて現場からアドバイスや経験を聞いていただければ幸いです.

4

8 に答える 8

16

私は Scalr ユーザーであり、Scalr.net のサブスクライバーであり、Scalr 愛好家になりました。Rightscaleを購入する余裕はありません。

Scalr は、あなたが求めることを行うことができます。

Scalr には 3 つのイメージ (それぞれ 32/64 ビット バージョン) と、ベース (汎用) イメージがあります。

1) nginx を実行するロード バランサー イメージ。高可用性セットアップには、これらのうちの 2 つが必要です。Scalr はネームサービスを管理し、それらの間でラウンド ロビンを行います。1 つがダウンすると、Scalr はそのインスタンスを DNS から削除し、別のインスタンスを起動します。他のロード バランサーを実行することは可能ですが、nginx がデフォルトです。

2) Apache/Tomcat/Rails を実行する複数のアプリケーション サーバー イメージが利用可能です。PHP/Perl/Python/Java/Ruby など、ここでアプリケーションをセットアップします。nginx は、一意のユーザー (IP + ブラウザーに基づく) でグループ化されたこれらのインスタンス間でリクエストをルーティングします。Scalr はこれらのアップネスも監視し、壊れたインスタンスを置き換えます。

3) 自動マスター/スレーブ レプリケーションを備えた MySQL データベース イメージ。スキーマをデプロイするだけで、Scalr がレプリケーションを処理し、機能していないサーバーを置き換えます。また、定期的にデータをバックアップします。Scalr の DNS はマスターとスレーブのホスト名を提供するため、アプリでスレーブから読み取り、マスターに書き込むことができます。

これらのインスタンス タイプはすべて、負荷に基づいて自動スケーリングされます。実行している内容に最も近い基本イメージから始めて、アプリケーション用にカスタマイズします。たとえば、Perl/Catalyst アプリを Apache サーバー インスタンスにデプロイしますが、静的コンテンツは nginx フロントエンド サーバーから提供します。読み取り/書き込みデータベース ハンドルを使用するには、アプリケーションを少し変更する必要がありました。

全体として、Scalr のバグを解決するのに約 3 週間かかり、アプリケーションが信頼できる状態になり、Scalr で高い可用性が得られると確信できました。彼らのサポートは驚異的だったので、バグはそれほど気になりませんでした。システムは順調に進んでいます。深刻な信頼性に近づいています。

補足として、Scalr の最も優れた機能は、サービスを中断することなく、AMI を自動バンドルして新しいインスタンスに再デプロイする「すべてに同期」機能です。これにより、非常に単純な管理タスクに 20 分かかる長い EC2 イメージ/AMI 作成プロセスを実行する時間が節約されます。これは、サーバー ファームをスケーリングするかどうかに関係なく使用できます。単一のインスタンスでも非常に便利です。

Scalr.net に月 50 ドル払ってサービスをホストしてもらっているのは、時間とお金の節約になると思うからです。これまでの結論は次のとおりです。私の最後のギグでは、高可用性 Linux DB + アプリケーション サーバーのセットアップに 1 年間取り組んでいるシステム担当者がいました...そして彼は、私が 3 週間で達成したような信頼性を達成できませんでした。 . Scalr を使用することによる節約は、自分で作成する場合と比べて極端です。

そうは言っても、Rightscaleを買う余裕があれば、Rightscaleを使用するでしょう. しかし、前払い料金と月額 500 ドルがそれを不可能にしています。含まれているコンサルティングを手放す代わりに、前払い料金を手放すという話がありましたが、月額サービス料はどこにも行きません。

現時点では、sclar.net の Web サイトがダウンしているため、サーバー ファームのいずれかを管理したい場合 (それらを atm にしないでください)、今は単純にできませんでした。スケーリングが scar.net サブスクライバーに対して現在機能しているかどうかは明らかではありません。つまり、これはおそらくまだ成熟したソリューションではありません。これはめったに起こることではなく、今夜まで私が経験した唯一のダウンタイムは、一度に数分間の期間でした。しかし、ええ...今はダウンしているので、言及する必要があります:)

決定を下す前に、http: //groups.google.com/group/scalr-discussのサポート グループをよく読むことをお勧めします。Scalr を選択した場合は、セットアップをテストし、Google グループで発生した問題に対処する準備をしてください。

于 2008-12-24T02:12:02.470 に答える
3

具体的な答えを出すのは少し野心的なので、私はあなたの質問にコメントします。

まず、タグにhaproxyがあることがわかりました。これは間違いなく、 EC2 で証明された最高の負荷分散ソフトウェアです。AWS フォーラムには、haproxy の使用に関するドキュメントと経験があります。

scalr について意見を述べることはできませんが、Rightscale は正しい方向に進んでいます。RightScale のロードマップで最も興味深い機能の 1 つは、Amazon の EC2 だけでなく、あらゆるクラウドの管理クラウド システムであることです。これにより、必要に応じて負荷分散とアップスケーリングを要求しようとするときに、非常に有望になります。

また、rightscale で開発者の無料アカウントにサインアップして、AMI と無料のスクリプトのいくつかをテストすることもできます。それらは非常に印象的です。

まあ、これは私がそこで働いているかのように聞こえるかもしれませんが、私はただのクラウドユーザーであり、それらとは関係ありません. それがあなたの心を横切るなら。

これが役に立てば幸いです。少なくとも議論に追加されます。

ジオ

于 2008-12-18T05:20:23.143 に答える
2

現在約 2 か月間 Scalr を使用しており、いくつかの本番アプリケーションをプラットフォームにゆっくりと移行しており、良好な結果が得られています。迅速なターンアラウンド/サポートと価値のために、それらを強くお勧めします. プラットフォームの可用性が向上することを期待しています。

全体として、提示された単純なユースケースに基づく元のポスターにぴったりです。

于 2008-12-24T19:46:41.750 に答える
1

両方のサービス(rightscaleとscalr)は素晴らしいです。オファーは同じではなく、価格も同じではありません。しかし、それらは両方とも私が探していたものです。私たちの予算スケーラーを再調整することは私のニーズに合います。最初はグーグルグループでのサポートはとても奇妙だと思いましたが、とても速くて効率的です。

彼らのソリューションもオープンソース(悪くはない)であり、他のプロバイダーをサポートするV2もロードマップに含まれています。

待って見てください、でも今まではとても満足しています

于 2008-12-26T17:22:01.570 に答える
1

すべてのサービスには悪い日があります。AWSサービスはダウンタイムを認識しています。ただし、AWSでアプリを実行しているユーザーはまだいます。

Scalr.netにいくつかのファームがあり、Rightscaleと比較しています。腕と足を払う必要はありません。

全体的に、サービスは非常に信頼できます。そして今、スクリプトエンジンを使用して、インスタンスを管理するための独自のスクリプトを設定できます。

よろしくHareemHaque

于 2008-12-24T08:11:51.403 に答える
1

正しい選択を決定することは、誰もが期待するほど簡単ではないかもしれません。私は Scalr と会って彼らのプラットフォームについて話しているのを聞いたことがあります。また、RightScale が彼らのプラットフォームについて話しているのも聞いています。単純な SOA (アプリケーション サーバー - データベース サーバー - ファイル サーバー) を使用している場合は、どちらの選択も適切です。

最終的に、いくつかのカスタム ミドルウェアを作成し、既知のソケットまたはハンドシェイク用の特定のポイントに依存している場合は、可能な限り負荷分散と自動スケーリングを検討し、管理できないものについては独自のソリューションにフォール バックする必要があります。これらのサービスのいずれかで。

于 2010-10-21T18:43:25.113 に答える
0

自動スケーリングでは問題が解決しないという人もいます

于 2008-12-15T11:27:21.627 に答える
0

私は現在 Scalr を検討しています。すべて良さそうに見えますが、クラウドの管理とスケーリングを目的として、独自のスクリプト作成を続けることにしました。現在 8 台のサーバーがあり、AWS 料金のみを支払っています。シェフ (自己ホスト)、nagios、およびその他の多くのツールを使用します。私のデータベースは mysql と mongodb、ロード バランサーは haproxy、アプリ レイヤーは rails です。何百台ものサーバーが必要になるまでは、スクリプトを書き続けるつもりです ;-)

于 2012-05-30T22:25:00.107 に答える