いくつかの考え。まず、Heartbeat、Pacemaker、ElasticIP を使用して、PGPool などの SPOF を回避します。PGPool 専用の 2 つ (またはそれ以上) のインスタンスを実行します。それらの 1 つに ElasticIP を割り当てます。Heartbeat と Pacemaker をセットアップして、PGPool を監視します。フェイルオーバー時に、ElasticIP を新しいマスター (Pacemaker 用語では DC) に割り当てるスクリプトを Pacemaker に実行させます。2 つのノードのみを実行している場合は、Pacemaker でクォーラム機能を無効にしてください。これは、合計 2 つのノードのうち 1 つのノードがダウンした場合、クォーラムを持つことができないためです。
ElasticIP を利用するには、Amazon の外部から ElasticIP でリバース DNS ルックアップを実行します。これにより、.で終わる ElasticIP にマップされる DNS 名が得られますamazonaws.com。で終わるドメイン名の EC2 インスタンスからの DNS ルックアップは、amazonaws.com実際には、ElasticIP が割り当てられたインスタンスの内部IP アドレスに解決されます。ElasticIP の DNS でアプリケーション サーバーを直接ポイントするか、独自の DNS を実行していると仮定して、ElasticIP DNS を参照する CNAME を作成できます。
とはいえ、フェイルオーバーに ElasticIP を使用することには 1 つの大きな落とし穴があります。ElasticIP の再割り当てが有効になるまでに最大 120 秒かかります。ほとんどの時間は、変更が Amazon の DNS サーバーを介して伝播するのを待つために費やされます。
また、各アプリケーション サーバーで PGPool-ii を実行しようとしたことはありませんが、これが機能するかどうかはわかりません。マスター データベースに障害が発生した場合、各 PGPool インスタンスが競合してフェイルオーバーを処理することになると思います。それを処理する最善の方法を理解するには、私が PGPool-ii に精通していないだけかもしれません。
plproxy について言及した人に関する限り、 plproxyでの使用が推奨されているPGBouncerと混同していると思います。plproxyは、ロード バランサーではなく、パーティショニング システムです。とはいえ、PGBouncer はロード バランサーでもなく、接続プーリング システムです。PGBouncer は負荷分散機能を提供しません。実際、PGBouncer の FAQ では、HAProxyなどの TCP ロード バランサーを使用することを明示的に推奨しています。
さらに、Rackspace が解決する垂直方向のスケーラビリティの問題を Amazon が抱えているという記述は正しくありません。Amazon EC2 インスタンスでは、いつでもインスタンスを停止して、より大きなインスタンス タイプにアップグレードできます。Amazon も Rackspace も、その場でのインスタンス タイプの変更をサポートしていません。