我们有一个使用 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
然后，我们将在单独的 Amazon 实例上拥有 2 个仅使用 PGSQL 的数据库服务器。这 2 台 PG 服务器将由位于 3 台前端服务器上的 PGPools 使用。
我的问题是，我不知道这个解决方案是否足够可靠，因为多个 PGPool 将访问多个 PGSQL 服务器。 PGPool 的大多数示例都演示了使用 N 个底层 PGSQL 服务器的单个 PGPool。在每个 Web 服务器上部署 PGPool 实例是一个好习惯吗？
如果没有，是否有其他/更好的架构来避免使用 Amazon 出现 SPOF？
非常感谢您的回复。
We have an existing web application that uses Postgresql 9.0 and PGPool-ii. I am thinking of migrating our infrastructore to Amazon EC2 and was inspired by the following link: http://aws.typepad.com/aws/2008/12/running-everything-on-aws-soocialcom.html that uses a similar architecture.
Since Amazon RDS doesn't support PGSQL, we are going to stick with PGPool-ii to load-balance the queries on the different DB servers and keep them synchronzed between each others.
So we plan to deploy 3 frontend web servers which will contain the following :
- Web Server + PHP code
- PGPool-ii
Then, we would have 2 database servers on separate Amazon instances with only PGSQL. These 2 PG servers would be used by the PGPools located on the 3 frontend servers.
My question is that I don't know if this solution is reliable enough as multiple PGPool will access multiple PGSQL servers. Most examples of PGPool demonstrates a single PGPool that uses N underlying PGSQL servers. Is it a good pratice to deploy a PGPool instance on each web server ?
If not, is there any other/better architecture to avoid having SPOF using Amazon ?
Thank you very much for your replies.
发布评论
评论（2）
几个想法。首先，我们通过使用 Heartbeat、Pacemaker 和 ElasticIP 来避免 PGPool 之类的 SPOF。运行两个（或更多）专用于 PGPool 的实例。将 ElasticIP 分配给其中之一。设置 Heartbeat 和 Pacemaker 来监控 PGPool。故障转移时，让 Pacemaker 运行一个脚本，将 ElasticIP 分配给新的主节点（Pacemaker 术语中的 DC）。如果您只运行两个节点，请确保禁用 Pacemaker 中的仲裁功能，因为如果总共两个节点中的一个节点出现故障，您就无法获得仲裁。
要利用 ElasticIP，请从 Amazon 外部对您的 ElasticIP 进行反向 DNS 查找。这将为您提供一个映射到 ElasticIP 的 DNS 名称，该名称应以 amazonaws.com 结尾。从 EC2 实例对以
amazonaws.com结尾的域名进行的 DNS 查找实际上会解析为已分配 ElasticIP 的实例的内部 IP 地址。您可以将应用程序服务器直接指向 ElasticIP 的 DNS，或者假设您正在运行自己的 DNS，则可以创建引用 ElasticIP DNS 的 CNAME。也就是说，使用 ElasticIP 进行故障转移有一个很大的问题。重新分配ElasticIP最多需要120秒才能生效。大部分时间都花在等待更改通过 Amazon 的 DNS 服务器传播。
另外，虽然我没有尝试在每个应用程序服务器上运行 PGPool-ii，但我不确定这是否可行。如果主数据库发生故障，我认为每个 PGPool 实例都会竞争来处理故障转移。也许我只是对 PGPool-ii 不够熟悉，无法理解处理该问题的最佳方法。
至于提到 plproxy 的人，我认为他们将其与推荐的 PGBouncer 混淆了与 plproxy 一起使用。 plproxy 是一个分区系统，而不是负载均衡器。也就是说，PGBouncer 也不是负载均衡器 - 它是一个连接池系统。 PGBouncer 不提供负载平衡功能。事实上，PGBouncer 的常见问题解答明确建议使用 TCP 负载均衡器，例如 HAProxy。
此外，关于 Amazon 存在 Rackspace 解决的垂直可扩展性问题的说法是不正确的。使用 Amazon EC2 实例，您始终可以停止实例并将其升级到更大的实例类型。 Amazon 和 Rackspace 都不支持动态更改实例类型。
Couple of thoughts. First, we avoid SPOF for things like PGPool through the use of Heartbeat, Pacemaker and an ElasticIP. Run two (or more) instances dedicated to PGPool. Assign an ElasticIP to one of them. Setup Heartbeat and Pacemaker to monitor PGPool. On failover, have Pacemaker run a script that assigns the ElasticIP to new master (DC in Pacemaker terms). If you're only running two nodes, make sure that you disable quorum functionality in Pacemaker, because you can't have a quorum if one node goes down out of a total of two nodes.
To take advantage of the ElasticIP, do a reverse DNS lookup on your ElasticIP from outside of Amazon. This will give you a DNS name that maps to the ElasticIP which should end in
amazonaws.com. DNS lookups from an EC2 instance for a domain name ending inamazonaws.comwill actually resolve to the internal IP address for the instance that has been assigned the ElasticIP. You can either point your application servers directly at the DNS for the ElasticIP or, assuming you're running your own DNS, you can create a CNAME that refers to the ElasticIP DNS.That said, there's one big catch to using ElasticIPs for failover. Re-assigning the ElasticIP takes up to 120 seconds to take effect. Most of the time is spent waiting fo thte change to propagate through Amazon's DNS servers.
Also, while I have not tried running PGPool-ii on each Application Server, I'm not sure this would work. If the master database fails, I think each of the PGPool instances would be competing to handle the failover. Maybe I'm just not familiar enough with PGPool-ii to understand the best way to handle that.
As far as the person who mentioned plproxy, I think they have it confused with PGBouncer, which is recommend for use with plproxy. plproxy is a partitioning system, not a load balancer. That said, PGBouncer is not a load balancer either - it's a connection pooling system. PGBouncer does not provide load balancing functionality. In fact, the FAQ for PGBouncer explicitly recommends using a TCP load balancer like HAProxy.
In addition, the statements about Amazon having vertical scalability problems that Rackspace solves are incorrect. With Amazon EC2 instances you can always stop an instance and upgrade it to a larger instance type. Neither Amazon nor Rackspace support changing instance types on the fly.
不过，我对 pgPool 没有一个清晰的想法，我一直在对可扩展性领域进行大量研究，并且由于某种我现在不记得的原因而忽略了 pgPool。
我建议看看 plproxy。这提供了一种负载平衡方法。
此外，由于亚马逊的垂直可扩展性问题，我不会成为亚马逊的重度买家。当您想要增加服务器的配置时，您无法获得开箱即用的升级。因此，如果您升级到更高的实例，您最终将再次实施所有服务器设置。
这样，Rackspace 就令人信服，您只需要求他们将内存从 1 GB 升级到 2 GB 或更多，只需重新启动实例即可完成。
Amazon 和 Rackspace 都提供（99%）可靠的托管解决方案，剩下的 1% 我们必须注意适当的备份和分发到不同的区域等，
Though, I do not have a clear idea on pgPool I have been doing a lot of research on the scalability areas and ignored pgPool for some reason that I don't remember now.
I would suggest taking a look at plproxy. This offers a load balanced approach.
Also I wouldn't be a heavy buyer on Amazon because of vertical scalability problems with Amazon. You do not get an out of the box upgrade when you want to increase a server's configuration. So you will end up implementing all your server setup again if you upgrade to a higher instance.
That way Rackspace was convincing where you can just ask them to upgrade from 1 GB ram to 2 GB or more and it will be done with just a restart of your instance.
Both Amazon and Rackspace offer (99%) reliable hosting solution and the rest 1% we have to take note of with proper backup and distribution into different regions etc.,