11

我们有一个使用 Postgresql 9.0 和 PGPool-ii 的现有 Web 应用程序。我正在考虑将我们的基础设施迁移到 Amazon EC2，并受到以下链接的启发：http: //aws.typepad.com/aws/2008/12/running-everything-on-aws-soocialcom.html ://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 台前端服务器上的 PGPool 使用。

我的问题是我不知道这个解决方案是否足够可靠，因为多个 PGPool 将访问多个 PGSQL 服务器。PGPool 的大多数示例都演示了使用 N 个底层 PGSQL 服务器的单个 PGPool。在每个 Web 服务器上部署 PGPool 实例是一种好习惯吗？

如果没有，是否有任何其他/更好的架构来避免使用 Amazon 的 SPOF？

非常感谢您的回复。

4

2 回答 2

8

几个想法。首先，我们通过使用 Heartbeat、Pacemaker 和 ElasticIP 来避免像 PGPool 这样的 SPOF。运行两个（或更多）专用于 PGPool 的实例。将 ElasticIP 分配给其中一个。设置 Heartbeat 和 Pacemaker 来监控 PGPool。在故障转移时，让 Pacemaker 运行一个脚本，将 ElasticIP 分配给新的主节点（Pacemaker 术语中的 DC）。如果您只运行两个节点，请确保禁用 Pacemaker 中的仲裁功能，因为如果一个节点在总共两个节点中出现故障，您将无法获得仲裁。

要利用 ElasticIP，请从 Amazon 外部对您的 ElasticIP 进行反向 DNS 查找。这将为您提供一个映射到 ElasticIP 的 DNS 名称，该名称应以amazonaws.com. 从 EC2 实例中查找以 结尾的域名的 DNS 查询amazonaws.com实际上将解析为已分配 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 的常见问题解答明确建议使用像HAProxy这样的 TCP 负载均衡器。

此外，关于亚马逊存在 Rackspace 解决的垂直可扩展性问题的说法是不正确的。使用 Amazon EC2 实例，您始终可以停止实例并将其升级到更大的实例类型。Amazon 和 Rackspace 都不支持动态更改实例类型。

于 2011-09-14T02:52:07.700 回答
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.,

于 2011-08-04T15:54:49.493 回答