我们有一个使用Postgresql 9.0和PGPool-ii的现有Web应用程序。我正在考虑将我们的基础架构迁移到Amazon EC2，并受到以下链接的启发：使用类似架构的http://aws.typepad.com/aws/2008/12/running-everything-on-aws-soocialcom.html。
由于Amazon RDS不支持PGSQL，我们将坚持使用PGPool-ii对不同数据库服务器上的查询进行负载均衡，并使它们保持同步。
因此我们计划部署3个前端Web服务器，其中包含以下内容： - Web服务器+ PHP代码 - PGPool-ii
然后，我们将在仅具有PGSQL的单独Amazon实例上拥有2个数据库服务器。这两个PG服务器将由位于3个前端服务器上的PGPools使用。
我的问题是我不知道这个解决方案是否足够可靠，因为多个PGPool将访问多个PGSQL服务器。大多数PGPool示例演示了一个使用N个底层PGSQL服务器的PGPool。在每个Web服务器上部署PGPool实例是一个很好的实践吗？
如果没有，是否有其他/更好的架构可以避免使用亚马逊的SPOF？
非常感谢您的回复。
答案 0 :(得分：8)
几个想法。首先，我们通过使用Heartbeat，Pacemaker和ElasticIP来避免像PGPool那样的SPOF。运行两个（或更多）专用于PGPool的实例。将ElasticIP分配给其中一个。设置Heartbeat和Pacemaker来监控PGPool。在故障转移时，让Pacemaker运行一个脚本，将ElasticIP分配给新的主服务器（以Pacemaker术语表示DC）。如果您只运行两个节点，请确保在Pacemaker中禁用仲裁功能，因为如果一个节点从总共两个节点中断开，则无法达到仲裁。
要利用ElasticIP，请从Amazon外部对您的ElasticIP执行反向DNS查找。这将为您提供一个映射到ElasticIP的DNS名称，该名称应以amazonaws.com结尾。对于以amazonaws.com结尾的域名，来自EC2实例的DNS查找实际上将解析为已分配ElasticIP的实例的内部 IP地址。您可以将应用程序服务器直接指向ElasticIP的DNS，或者假设您运行自己的DNS，则可以创建引用ElasticIP DNS的CNAME。
也就是说，使用ElasticIP进行故障转移是一个很大的问题。重新分配ElasticIP最多需要120秒才能生效。大部分时间都花在等待更改通过亚马逊的DNS服务器进行传播。
此外，虽然我没有尝试在每个Application Server上运行PGPool-ii，但我不确定这是否可行。如果master数据库失败，我认为每个PGPool实例都将竞争处理故障转移。也许我对PGPool-ii不太熟悉，无法理解处理它的最佳方法。
至于提到plproxy的人，我认为他们与PGBouncer混淆了，建议与plproxy一起使用。 plproxy是分区系统，而不是负载均衡器。也就是说，PGBouncer也不是负载均衡器 - 它是一个连接池系统。 PGBouncer不提供负载平衡功能。事实上，PGBouncer的FAQ明确建议使用像HAProxy这样的TCP负载均衡器。
此外，关于具有Rackspace解决的垂直可伸缩性问题的Amazon的陈述是不正确的。使用Amazon EC2实例，您始终可以停止实例并将其升级为更大的实例类型。亚马逊和Rackspace都不支持动态更改实例类型。
答案 1 :(得分：1)
尽管如此，我对pgPool没有一个明确的想法，我一直在对可伸缩性领域进行大量研究，并且由于某些我现在不记得的原因而忽略了pgPool。
我建议看看plproxy。这提供了负载均衡的方法。
由于亚马逊的垂直可扩展性问题，我也不会成为亚马逊的重要买家。当您想要增加服务器的配置时，您不会获得开箱即用的升级。因此，如果升级到更高的实例，最终将再次实施所有服务器设置。
那样Rackspace就说服你可以让他们从1 GB ram升级到2 GB或更多，只需重新启动你的实例即可完成。
亚马逊和Rackspace都提供（99％）可靠的托管解决方案，剩下的1％我们必须注意适当的备份和分发到不同的地区等。