使用群集最佳策略进行扩展

Question

我正在考虑使用服务器集群扩展的最佳策略。我知道没有严格的规则，但我很好奇人们对这些场景的看法：

1. 使用dnsmadeeasy平衡循环（具有故障转移）的组合app / db服务器的集群。 db使用复制同步。具有以下优点：通过向群集添加另一台服务器可以轻松扩充容量，并且它自然是安全的。

2. 应用服务器集群，再次使用dnsmadeeasy进行循环负载平衡（使用故障转移），所有这些都报告给后面的大型数据库服务器。易于添加应用服务器，但单个数据库服务器会创建单个故障点。可以添加具有复制功能的热备用。

3. app服务器集群（如上所述）使用两个数据库，一个处理只读，一个处理只写。

此外，如果您有其他想法，请提出建议。数据主要是非规范化和非关系数据，DB是50/50读写。

Answer 1

使用2台物理计算机并将其设为Xen台服务器

• 甲。 Xen Base alpha
• B中。 Xen Base beta

每个人都做三个虚拟机：

1. 用于静态的“web”服务器（css​​，jpg，js ...）+动态请求的负载均衡代理（apache + mod-proxy-balancer，nginx + fair）
2. 动态请求的“app”服务器（mongrel，thin，passenger）
3. “db”服务器（mySQL，PostgreSQL ...）

然后你的功能分配如下：

• A1拥有您的公共IP并处理对A2和B2的请求
• B1 ping A1并在ping失败时接管
• A2和B2采用动态请求查询A3数据
• A3是您的专用数据服务器
• B3备份A3秒到秒，并提供只读访问权限以进行复制，备份等。 如果A3无法到达，则B3 ping A3并成为主人

希望这可以帮助你，或者至少给你一些想法。

Answer 2

这实际上取决于你的申请。

我花了一些时间为我的公司采用各种技术，而我们已经确定的（目前）是在一组Web服务器前运行反向代理/负载均衡器，这些服务器都指向一个掌握DB。理想情况下，我们想要一个解决方案，其中DB在主/从配置中设置，如果有任何问题，我们可以将从站提升为主站。 所以选项2，但有一个从DB。同样对于高可用性，DNS循环的两个反向代理将是好的。我建议使用具有“公平”算法的负载均衡器，而不是简单的循环法;你会获得更好的吞吐量。 甚至还有解决方案可以对数据库进行负载平衡，但这些解决方案可能会有些复杂，我会在你需要它之​​前避免使用它们。

Rightscale提供了一些关于此类内容的良好文档：http://wiki.rightscale.com/ 他们为云托管解决方案提供这些类型的服务。

特别有用的我认为这两个条目带有图片，可以给你一个很好的视觉表现。

“简单”设置：
http://wiki.rightscale.com/1._Tutorials/02-AWS/02-Website_Edition/2._Deployment_Setup

“高级”设置：
http://wiki.rightscale.com/1._Tutorials/02-AWS/02-Website_Edition/How_do_I_set_up_Autoscaling%3f

Answer 3

我只想对数据库方面发表评论：

对于正常的RDBMS，DB的50/50读/写负载将使复制在开销方面“昂贵”。几乎所有具有简单故障转移解决方案的情况都比实施复制主动/主动DB设置成本低。在管理/维护和许可成本方面（如果适用）。

由于您的数据“主要是非规范化且非关系型”，您可以查看HBase这是一个基于列的键/值数据库系统的Google Bigtable的OSS实现。 HBase再次建立在Hadoop之上，这是Google GFS的OSS实现。

要使用哪种解决方案取决于您的预期容量增长，其中Hadoop可以扩展到可能的1000个节点，但也应该少运行。

我管理了主动/主动复制数据库，单写/多读数据库和简单故障转移群集。超越简单的故障转移群集将为您在故障转移设置中永远看不到的潜在问题开辟新的维度。

如果您要使用传统的SQL RDBMS，我建议使用内存较多的相对“大铁”服务器，并使其成为故障转移群集。如果写入比率缩小，则可以使用故障转移写入群集和只读服务器场。

答案在于细节。您的应用程序CPU或I / O是否受约束？您需要TB级存储空间还是仅需几GB？