ペースメーカー、ハートビートなどはEC2にとって意味がありますか？
Pacemakerエコシステム（Corosyncなど）はEC2のコンテキストで意味がありますか？ある時点まで、CorosyncはIPマルチキャスト（EC2では利用できません）を必要としていましたが、現在はブロードキャストされていると思います。それでも、ペースメーカーらです。 al。クラスターがEC2上でそれ自体を管理するための適切なツール。相互に障害を監視し、障害のあるインスタンスを置き換えるために新しいインスタンスを起動しますか？
問題の一部は、ここにあるすべてのプレーヤー（Heartbeat、Corosync、OpenAISなど）をまっすぐにするためにかなりの時間を費やしてきたことだと思いますが、これらが実際に何であるかをまだ理解しようとしています- are（あいまいな用語を超えて、たとえば、Pacemakerは「クラスターリソースマネージャー」であり、Corosyncは「信頼性の高いメッセージングおよびメンバーシップインフラストラクチャ」を提供します）。
したがって、私の質問自体が少し厄介であるか、完全に意味をなさない場合は、お詫び申し上げます。どんな洞察も大歓迎です。ありがとう。
EC2はゲスト内のサービスの状態を監視していますか？
そうでない場合、そしてそれがあなたが望むものであるならば、ペースメーカーはここに関連するでしょう。 Corosyncはmcastとbcastのみを実行するため、おそらくまだオプションではないため、ペースメーカーとハートビートのシナリオになります。
これは、人々がlinodeインスタンスでそれを行う方法のガイドです。その多くはEC2にも関連している可能性があります： http://library.linode.com/linux-ha/
ピースが何であるかという質問に答えるために、Pacemakerはサービスを開始および停止するものであり、サービスが実行されていることと、サービスが1つの場所でのみ実行されていること（データの破損を回避するため）の両方を保証するロジックが含まれています。
しかし、ハートビートやcorosyncが登場する他のノードで自分自身と通信する機能がなければ、それを行うことはできません。
ハートビートとcorosyncは、任意のノードがメッセージをスローでき、すべてのピアによって受信されることを認識できるバスと考えてください。バスはまた、誰がバスに接続されているか（接続されていないか）に全員が同意し、そのリストが変更されたときに通知することを保証します。
2つのノードの場合、Pacemakerは同じように簡単にソケットを使用できますが、それを超えると複雑さが急速に増大し、正しく理解するのが非常に困難になります。したがって、信頼性が証明されている既存のコンポーネントを使用することは非常に理にかなっています。
私の直感レベルの本能は、ノーと言うことです。これらは、EC2でのクラスター管理に適したツールではありません。私はそれらをスタンドアロンハードウェアで使用しましたが、そこで実際に意味をなすには、非常に具体的な一連のニーズ/障害ケースが必要であることがわかりました。より具体的なクラウド監視システムや、プラットフォームを念頭に置いて開発されたメッセージングなどのツールよりも、これらのツールを必要とするようなユースケースを頭の中で思いつくことはできません。
とはいえ、ここでは私の答えが信頼できるとは考えていません。ec2クラウドに設定されたツールをもう少し経験して誰かがチャイムを鳴らしてくれることを本当に望んでいます。