搭建高速负载均衡服务器集群——web/db/NFS

Question

我正在寻求有关以预算（例如 2,000 英镑 - 3,000 英镑）设置高速负载平衡服务器集群的最佳方式（主要是在硬件方面）的建议，以在单个 IP 地址后托管 Web 服务，支持db 服务器和通用文件系统。全部在 linux 上。

对于网络服务器，我知道我想用 apache 设置 IPVS，但我不知道在硬件上花费的最佳方式。我会设想有一台机器（最好有一个备份）从互联网上获取请求并在一系列 apache 服务器之间对这些请求进行负载平衡。阵列中的每台服务器都具有对公共文件系统的共享访问权限。随着时间的推移，我会向阵列添加更多服务器以增加容量。

1. 系统始终在负载平衡器处遇到瓶颈。我需要什么样的机器才能支持非常高/不太高的流量？哪个更重要 - 处理器/内存

2. 对于 apache 阵列中的机器，我要做什么 - 更多的处理器，更快的处理器，更多的内存等 - 这是最重要的，如果我打算添加更多机器，它甚至很重要

3. 为了提供可扩展性（易于添加更多磁盘空间）和性能（因为它也是一个瓶颈），实现共享文件系统的最佳方法是什么？在这里，我想要软件和硬件建议。

4. 用于各种任务的机器的成本/性能估计。

5. 关于使用此设置可以为给定数量的机器提供的流量类型的任何想法。

Answer 1

我最近不得不设计类似的东西。这是我的信封设计的概念背面

负荷分配

我假设网络运维人员已经设置了一个冗余且高度可用的路由、防火墙和交换结构，将请求传送到负载平衡器。

（如果没有，我会使用 PF 或 IPtables 的有状态 HA 设置，并使用 carp 或 keepalived 进行自动故障转移。）负载平衡器规范将取决于 Web 应用程序负载分配方法和成本以及其他指标。

根据预算，负载平衡可以使用 - 基于硬件的负载平衡器，往往价格昂贵 - 基于软件的代理，如 HAProxy

负载平衡器必须是高度可用的，所以我会使用备用备份进行一些活动负载（比如 2 个 HAProxy 实例，其中 2 个处于备用模式）。

我会让路由层将请求发送到负载均衡器。如果其中一个负载均衡器出现故障，将使用基于 keepalived 的解决方案来无缝替换故障框。

一旦负载平衡器接受请求，它们就会将它们传递给缓存层。缓存层将处理：

• 对静态内容的请求。
• 具有表明尚未过期的 HTTP 标头的内容。
• 压缩静态文本内容，例如 CSS 和 JS 文件。

缓存层可以使用反向代理中的 SQUID 或 NGINX 等解决方案来实现。通过这样做，我们将通过仅向 Apache/PHP 服务器发送动态请求来减少应用服务器上的负载。

为了将成本保持在最低限度，我会将 HAProxy 和 NGINX 放在同一个盒子上。

一种简单且可扩展的方法是让网站的子域（比如http://cdn.myservice.com/static）提供 CSS、JS 和静态图像。使用这样的设置，我们将来可以全局安装缓存实例，并让 DNS 向最近的 CDN 实例发送静态请求。但最初，CDN 工作可以由这些 NGINX 实例处理以保持低成本。

处理层

处理层由为 Apache/PHP 优化的服务器池组成。他们将从 NFS 或分布式文件系统共享加载他们的配置文件，并通过处理来自另一个远程共享（NFS 或 DFS）的 PHP 脚本来满足他们的请求。使用这些远程共享可以减轻维护和同步服务器配置的配置开销。

Apache 和 PHP 可以进一步优化，例如：

• 删除 PHP 和 Apache 中不需要的模块。
• 使用 PHP Opcode 缓存（例如 APC）来减少 PHP 编译开销。
• 优化 Apache 的设置，例如 MPM 和 keep-alive 设置。

内存缓存服务器池还可以配置为存储常见且昂贵的数据库查询的结果。如果它们不在内存缓存层中，读取查询通常会被发送到从属节点，然后它们的结果将被缓存。写入将发送到主服务器，并且可能涉及使内存缓存层中的数据无效。PHP 会话数据也可以通过 memcached 共享，这样如果任何单个 Apache/PHP 服务器出现故障，剩余的服务器可以从 memcache 中获取会话数据。

扩展处理池中的负载将是添加更多服务器和更新反向代理的问题。服务器池可以划分为多个逻辑组。然后，逻辑组将使用通过 NFS 共享的公共配置，并且可以作为块升级。

然后可以监控升级，如果检测到问题，可以实施修复或实施回滚。逻辑组可以分布在不共享任何内容（电源、网络交换机等）的机架上，并由不同的成员（比如戴尔的服务器型号 A、B 和 C）组成，因此块迁移测试是全面的。

数据库

对于数据库，我有一个在主/多从设置中运行的 MySQL 服务器。master 将针对写入进行优化，并为复制启用二进制日志记录。这通常意味着我们会对 MySQL 使用通常的优化，例如：

• 使用 RAID 10 和高 RPM 驱动器。
• 在 mysql 数据目录上禁用 atime/mtime。
• 调整 CPU 和 RAM 的 innodb 设置。
• 表的正确索引和分区。
• 监控慢查询日志并使用解释来分析慢查询。
• 监控数据库性能。

从站将被配置为读取，并且需要使用诸如 maatkit 的 mk-heartbeat 之类的实用程序不断监视复制延迟。滞后的服务器可能会从 PHP 读取集中删除，直到它赶上。

如果 master 失败：

• 一个奴隶将被提升为主人。
• 将更改 DNS 以指向新的主服务器。
• 重新加载网络中的解析器以反映 DNS 更改。
• 其他从站自动从新的主站中选择（我们可以使主站和从站上的 binlog 位置和文件相同，使迁移变得容易）
• Apache/PHP 服务器会自动写入新的主服务器，因为 DNS 解析器将返回新的主服务器。通过使用带有 A/AAAAA 记录的从属集的 DNS 循环，读取也将发送到适当的服务器。

DNS 的替代方案可能是将好的从站列表存储在诸如 memcache 之类的缓存中并适当地更新它。

最重要的是，我有一个或两个工作站用于网络监控和报告聚合。我会使用 Munin/Zenoss 进行趋势分析，使用 syslog 服务器来聚合服务器日志，使用自定义脚本进行日志分析和警报。Nagios 还可用于提供基础设施和警报的全局概览。

缩放

升级基础设施以增加负载将通过以下方式处理：

• 增加负载平衡器反向代理服务器以处理更多静态内容。
• 静态内容的地理分布。根据成本，CDN 工作可能会外包给 Amazon 的 cloudfront 等服务。
• 增加 Apache/PHP 服务器的数量以处理更多负载。
• 增加 MySQL 从站的数量。
• 将 master 和 MySQL 联合分片以呈现分布在数据库服务器集群上的表的统一视图