2

我正在考虑使用服务器集群进行扩展的最佳策略。我知道没有硬性规定,但我很好奇人们对这些场景的看法:

  1. 使用 dnsmadeeasy 进行循环(带故障转移)平衡的组合应用程序/数据库服务器集群。数据库使用复制同步。优点是可以通过向集群添加另一台服务器来轻松增加容量,并且它自然是故障安全的。

  2. 应用服务器集群,再次使用 dnsmadeeasy 循环负载平衡(带故障转移),所有都向后面的大型数据库服务器报告。易于添加应用服务器,但单个数据库服务器会创建单个故障点。可以通过复制添加热备用。

  3. 使用两个数据库的应用服务器集群(如上),一个只处理读取,一个只处理写入。

另外,如果您有其他想法,请提出建议。数据大多是非规范化和非关系型的,数据库是 50/50 读写。

4

3 回答 3

3

Take 2 physical machines and make them Xen servers

  • A. Xen Base alpha
  • B. Xen Base beta

In each one do three virtual machines:

  1. "web" server for statics(css,jpg,js...) + load balanced proxy for dynamic request (apache+mod-proxy-balancer,nginx+fair)
  2. "app" server (mongrel,thin,passenger) for dynamic requests
  3. "db" server (mySQL, PostgreSQL...)

Then your distribution of functions can be like this:

  • A1 owns your public ip and handle requests to A2 and B2
  • B1 pings A1 and takes over if ping fails
  • A2 and B2 take dynamic request querying A3 for data
  • A3 is your dedicated data server
  • B3 backups A3 second to second and offer readonly access to make copies, backups etc. B3 pings A3 and become master if A3 becomes unreachable

Hope this can help you some way, or at least give you some ideas.

于 2009-05-08T07:33:00.200 回答
2

这实际上取决于您的应用程序。

我花了一些时间为我的公司使用各种技术,我们(目前)确定的是在所有指向单个主数据库的 Web 服务器集群前运行反向代理/负载均衡器。理想情况下,我们想要一个解决方案,在主/从配置中设置数据库,如果有任何问题,我们可以将从属提升为主。所以选项2,但有一个从数据库。同样对于高可用性,两个作为 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

于 2009-05-08T15:27:31.157 回答
1

我只会在数据库方面发表评论:

对于普通的 RDBMS,数据库的 50/50 读/写负载将使复制在开销方面“昂贵”。对于几乎所有情况,拥有一个简单的故障转移解决方案都比实施复制的主动/主动数据库设置成本更低。在管理/维护和许可成本(如果适用)方面。

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

使用哪种解决方案取决于您预期的容量增长,其中 Hadoop 旨在扩展到潜在的 1000 个节点,但也应该在更少的节点上运行。

我管理过主动/主动复制数据库、单写/多读数据库和简单的故障转移集群。超越简单的故障转移集群会打开一个新的潜在问题维度,您在故障转移设置中永远不会看到。

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

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

于 2009-05-08T16:07:12.390 回答