使用PGPool-ii在Amazon EC2上部署高可用性Postresql 9.0

Question

我们有一个使用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？

非常感谢您的回复.

Answer 1

几个想法.首先,我们通过使用Heartbeat,Pacemaker和ElasticIP来避免像PGPool那样的SPOF.运行两个(或更多)专用于PGPool的实例.将ElasticIP分配给其中一个.设置Heartbeat和Pacemaker来监控PGPool.在故障转移时,让Pacemaker运行一个脚本,将ElasticIP分配给新的主服务器(以Pacemaker术语表示DC).如果您只运行两个节点,请确保在Pacemaker中禁用仲裁功能,因为如果一个节点从总共两个节点中断开,则无法达到仲裁.

要利用ElasticIP,请从Amazon外部对您的ElasticIP执行反向DNS查找.这将为您提供一个映射到ElasticIP的DNS名称,该名称应该以ElasticIP结尾amazonaws.com.对于以域名结尾的EC2实例进行的DNS查找amazonaws.com实际上将解析为已分配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都不支持动态更改实例类型.

Answer 2

不过，我对 pgPool 没有一个清晰的想法，我一直在对可扩展性领域进行大量研究，并且由于某种我现在不记得的原因而忽略了 pgPool。

我建议看看 plproxy。这提供了一种负载平衡方法。

此外，由于亚马逊的垂直可扩展性问题，我不会成为亚马逊的重度买家。当您想要增加服务器的配置时，您无法获得开箱即用的升级。因此，如果您升级到更高的实例，您最终将再次实施所有服务器设置。

这样，Rackspace 就令人信服，您只需要求他们将内存从 1 GB 升级到 2 GB 或更多，只需重新启动实例即可完成。

Amazon 和 Rackspace 都提供（99%）可靠的托管解决方案，剩下的 1% 我们必须注意适当的备份和分发到不同的区域等，