タグ付けされた質問 「scalr」

独自のクラスターを管理している（つまり、Amazon Autoscale、Rightscale、Scalrなどを使用していない/支払う）うち、EC2でインスタンスを管理し、フェイルオーバー（たとえば）を処理していますか？私が疑うように、ほとんどの人がEC2 APIに対してボートの独自のスクリプトを書くことになってしまうのではないかと思っています。 それは確かに私たちのアプローチです：オフサイトで実行され、インスタンスからのUDPキープアライブをリッスンするPython Botoベースの監視/再起動デーモンを作成します。障害が発生すると、ボリュームのスナップショットを作成し、イメージを登録し、新しいインスタンスを起動し、古いボリュームを削除します。 スクリプトをハッキングするときは、これらの問題に対処するオープンソースのツールがすでに存在している必要があり、Scalrの制約はないと思いますが、私は常にGoogleから戻ってきます手ぶらで。（Scalrのようなものは、サポートされているソフトウェアのセット/バージョン/構成がかなり制限されており、これらのセットアップを操作する専門的でIMOの面倒な方法があります。） また、Linux-HA / Pacemakerエコシステム（Heartbeat、ldirectordなど）は、EC2にはあまり適していないようです。（しかし、私はこれを見つけました -これが本当に高品質のソリューションであるかどうかはわかりませんが）。

13 amazon-ec2  failover  heartbeat  amazon-elastic-ip  scalr 

トラフィックが急増しているサイトを運営しています。そのため、この場合、自動スケーリングソリューションは非常に有益です。現在、Webサーバーは水平方向に自動スケーリングできますが、ボトルネックはMySQLサーバーにあります。 私はAmazon RDSマルチAZを試してみましたが、12 GBのデータベースをアップグレードするには、数分のダウンタイムで15分程度かかります。ある特定の瞬間にトラフィックの急増が起こることをすでに知っていたとき、それは多くの助けとなりました。 Xeroundも検討しました。このサイズのデータ​​ベースでは非常にコストがかかりますが、これはおそらく最良のソリューションです。とにかく、データベースをEUに置くことを法的に必要とするため、これは選択肢ではありません。 私はScalrについて読みましたが、それが役立つかどうか、またどのように役立つかはわかりません。 多くのクラウドホスティングプロバイダーが垂直スケーリングソリューションを提供し、ダウンタイムがゼロであると考えています（Xenハイパーバイザーを使用している限り、それが本当に可能かどうかはわかりません）。それは解決策になるかもしれませんが、ダウンタイムがないのか、MySQL構成（およびOS上の他の多くのこと）がダウンタイムなしでもアップグレードできるのかと思います。 MySQLスレーブサーバーを試しましたが、まったく役に立ちませんでした。 memcacheを使用していますが、これは非常に役立ちますが、それだけでは不十分です。読み取りのためだけでなく、書き込みのためにアップグレードする必要があります。 助言がありますか？前もって感謝します

8 mysql  scalability  amazon-rds  scalr