问题：我们组织目前的情况是，跨多台服务器进行负载均衡真的变得很有必要。从独立服务器过渡到服务器集群可以说是一项艰巨的任务。实现这种改变的最佳方法是什么？是否可以从小规模开始，并随着需求增长而增加“集群”？哪些服务在多台服务器上运行良好，哪些服务则不然？ -- 佐治亚州亚特兰大市的 Cory Whiteman

HPC Systems, Inc. 系统与技术总监 Kalyana Krishna Chadalavada 回答： 将集群引入您的基础设施的最佳方法是推出试点实施方案。在大多数情况下，可以从小规模开始，并随着需求的增长而扩展。然而，这是从 1000 英尺高空俯瞰的角度来看。许多应用程序都支持集群配置，数据库是第一个这样做的。文件服务器、电子邮件服务器、Web 服务器紧随其后。对于那些本身不具备集群感知能力的应用程序，可以通过在网络中引入像 IP 负载均衡器这样的新设备来实现负载均衡。

具体实施方案将根据您尝试实现的目标而有所不同。同样重要的是要注意，并非所有服务都会随着您扩展可用资源而无限扩展。简单来说，增加 10 台服务器不一定会将性能提高 10 倍。

好消息是，大多数供应商都为集群感知型应用程序（如 Oracle、SQLServer、Lustre、PVFS 等）提供预配置系统。

Adobe Systems 的 James Ward 回答： 在集群环境中，最难处理的事情之一是状态复制。您的应用程序越无状态，就越容易进行集群。如果您可以在处理有状态事物的单台服务器后面分层部署无状态服务集群，那么您的工作可能会更容易。

dthomasdigital 的 David Thomas 回答： 鉴于今天的计算机环境，集群可以帮助许多组织利用现有资源。这确实可能是一项艰巨的任务，但一个好的计划会大有帮助。选择适合您组织需求的 Linux 发行版，最好是在您的组织或外部支持团队内部存在一些专业知识的发行版。考虑额外的冷却和电力需求，以及安全性和强大的备份计划。提前做好这一切，您稍后会很高兴的。

Linux 集群具有很强的可扩展性，因此从小规模开始并发展壮大是正确的思路，但请记住，在设计集群时，可扩展性是您的首要要求，这样您在需要时就应该可以轻松添加资源。

在处理集群服务时，我喜欢从协议的角度来思考。像 HTML、DNS 和 SMTP 这样的协议可以很好地处理集群环境。从 Web 服务器开始，然后是数据库，当您越来越习惯在集群环境中工作时，再转向 FTP、DNS 和电子邮件服务器。

集群具有许多优点，例如高可用性、负载均衡，甚至可以配置用于高性能计算。如果计划得当，Linux 集群可以成为任何组织的宝贵资产。

硅谷的 IT 经理 Bill Childers 回答： 嗯，Cory，负载均衡是扩展服务以获得额外容量的好方法。传统上，人们会为服务分配更多的 CPU 和 RAM（垂直扩展），但这只能到此为止。通过将服务的负载分散到多台机器上（水平扩展），您可以获得更高的容错能力以及该服务更高的容量。水平扩展的一个好方法是使用负载均衡器。

让我们首先回答您问题的最后一部分——“哪些服务在多台服务器上运行良好，哪些服务则不然？” 大多数只读服务或可以在单个事务中执行写入的服务都非常适合负载均衡，因此像 HTTP、LDAP 读取和 DNS 查找这样的服务在部署在负载均衡器后面时效果非常好。写入密集型操作（例如数据库更新）在负载均衡器后面效果不佳（除非您的应用程序可以从不同的数据库服务器挖掘数据或您有共享存储）。任何启用 SSL 的服务（例如 HTTPS）在负载均衡时都可能构成特殊情况，因为 SSL 证书中的“cn”（通用名称）属性必须与客户端发出请求的完全限定域名 (FQDN) 匹配。有一些方法可以解决这个问题，但最好留给网络架构师来处理。

进行更改的最佳方法实际上取决于您的网络架构和服务部署。我建议从小规模开始——希望您有一个实验室环境，您可以在将其投入生产环境之前进行测试。如果计划得当且您的环境允许，则可以在对您的生产服务造成最小中断的情况下推出负载均衡。例如，假设您有一个基本的 Web 服务器，并且您希望迁移到负载均衡器后面的三个 Web 服务器集群。您将在同一子网上设置新的 Web 服务器并启动这些服务，并验证它们是否正常运行。然后，您可以将负载均衡器放置在与 Web 服务器相同的子网上，并为其提供您希望向外界展示为您的“www.mydomain.com”地址的虚拟 IP (VIP)。配置负载均衡器以在 Web 服务器之间路由流量，然后设置一个 DNS 记录，例如“test.mydomain.com”，以指向负载均衡器的 VIP。此时，（假设您的 Web 服务器也设置为为 test.mydomain.com 提供流量服务）您可以浏览到 test.mydomain.com，并且您的请求应该通过负载均衡器提供服务。这将为您提供运行测试并验证事物是否正常工作的机会。一旦您满意，只需更改您的 www.mydomain.com DNS 记录以指向负载均衡器的 VIP，您的服务将动态切换到负载均衡状态。如果出现问题，您也可以快速回滚更改。

祝你好运！

夏威夷大学教育学院的 Chris Stark 回答： 嗨，Cory。成为一名优秀的系统管理员的关键在于做出明智的决策。您问，“从独立服务器过渡到集群的最佳方法是什么？”。最好的方法是暂时走出服务器机房，制定一些可靠的计划。您的计划应以您在过去几周、几个月甚至一年中收集的性能数据为依据。而且，您的计划应该着眼于未来，以确保您在时间、精力和设备上的投资不仅仅是“创可贴”式的修复或糟糕的黑客行为。

您可能需要让您组织的管理层参与到这个过程中，因为他们肯定希望参与到组织 IT 基础设施的方向中来。提出以下问题（但这只是一个开始——您还需要提出您自己的问题）……

组织最重要的服务是什么？

如果这些核心服务在给定的时间内不可用，组织会损失多少成本？

支持核心服务需要哪些辅助服务？

关键服务器上当前的资源利用率是多少？

在给定的时间内，有多少用户正在使用关键服务？

我们预计从现在起的 1/3/5 年后，有多少用户将使用核心服务？

使用这些问题的答案（以及您提出的问题）来帮助制定您的计划并证明您的支出的合理性。尽管这似乎是一个显而易见的步骤，但我遇到的太多 IT 运营部门没有任何书面计划，这使得组织在人员不可避免地发生变化时处于不利境地。此外，适当的计划有助于避免不必要的服务器蔓延，并为您的 IT 运营部门的绩效目标提供重要的基准。

我现在要跳过您的第二个问题，直接回答您的第三个问题，“哪些服务在多台服务器上运行良好，哪些服务则不然？”。由于您的问题没有具体说明您的组织提供的服务，我将介绍一些常见的服务：DNS、LDAP、数据库、Web 应用程序、文件共享和电子邮件。

像 BIND DNS、OpenLDAP 和 MySQL 这样的服务都有自己的复制和集群规定。在大多数情况下，只需添加更多物理机即可轻松扩展这些服务。为了最大限度地利用额外的机器，您可能需要调整一些配置。

如果 servlet 容器支持集群，则通常可以对基于 Java 的 Web 应用程序进行集群。我不是 Java 专家，但我很确定 Tomcat 和 Glassfish 都可以轻松处理集群。

用 PHP 编写的 Web 应用程序可能需要进行一些调整才能处理负载均衡（尤其是那些涉及登录会话的应用程序）。PHP 中集群会话管理的关键是将会话数据存储在数据库中，而不是服务器的文件系统中。

由于 HTTP 是无状态的，因此 Web 应用程序特别适合负载均衡。但是，为了获得最佳结果，您应该让您的 Web 开发人员开始使用某种源代码管理工具，如 Subversion。这将使保持 Web 集群中每个节点上的内容同步变得容易。

电子邮件和文件共享服务更难集群，可能需要您尝试棘手的配置和基于 NAS 或 SAN 的存储。

所以回到您的第二个问题，“是否可以从小规模开始，并随着需求增长而增加‘集群’？”。对于某些服务，是的。但是，当涉及到文件共享和电子邮件时，新的且昂贵的基础设施的数量可能意味着进入集群的“第一步”要大得多。

我希望这能帮助您走上正确的道路。对于某些事情来说，没有灵丹妙药或神奇的公式，因此您需要学会依赖您的网络性能数据和您组织的 IT 计划，以便做出正确的决策。

Aloha。

Tim Chase 回答： 负载均衡请求最常见的情况涉及数据库支持的 Web 服务器。首先要做的是分析并找出瓶颈发生在哪里。瓶颈很可能是数据库或动态 HTML 内容生成（PHP、Python、Ruby、Perl 等）。在某些情况下，也可能是静态内容服务器或仅仅是网络连接。

此外，您目前是否在同一台机器上运行所有组件（DB、静态内容和动态内容）？尝试将这些组件分别拆分到它们自己的服务器中——它们之间的划分很清晰，并且可以防止它们在同一台服务器上争夺资源。Django 的人们对扩展这些组件有很好的描述 [1]。

最后，事务之间是否存在共享状态？无共享架构将所有状态保留在客户端，允许您池中的任何服务器回答请求，因为请求是自包含的。有关更多信息，请阅读 REST [2]。如果您将自己束缚在服务器上维护共享状态，那么该服务器可能会成为您的瓶颈。

数据库
这可能只是查询数量的激增，或者从数据库服务器取回大量数据，只是为了在本地对其进行过滤。查询优化（在服务器端完成所有排序/过滤/分组）可以提供帮助。往返于数据库的数百（甚至数千）个小查询可能会合并为一个往返查询。所以从智能 SQL 开始。

如果大多数查询是只读的，则主从数据库复制效果很好（尽管您必须确保紧跟在写入之后的读取来自主服务器）。对于写入量较大的站点，一些数据库也支持主主复制，但对于复制延迟存在各种注意事项。阅读您的数据库文档以了解更多信息（PostgreSQL 和 MySQL 都支持数据库集群）。了解您的应用程序对写入和传播之间延迟的容忍度也很有帮助。如果您需要最新的数据，您的要求会更高。如果您可以容忍更高的延迟，您将有更多选择——例如，一篇博客文章在服务器之间缓慢传播，如果地球另一端的人们必须等待整整一个小时才能看到它，这无关紧要。

当数据变得庞大时，需要进行特定于应用程序的重写才能扩展。选项包括

- 分片：将一个大表拆分到多个数据库服务器上

- 分区：沿用户/公司等边界进行拆分，将他们的数据保留在单个服务器上，但有一种方法可以使用该用户/公司信息来决定将他们路由到哪个服务器

- 使用像 Google 的 BigTable 或开源 Hadoop 项目这样的后端

动态内容生成
这可能涉及算法或数据结构的选择不当。许多语言都支持分析网页响应——使用这些计时工具来找出瓶颈在哪里。您是否正在使用 O(N^2) 算法，而 O(N log N) 或更好的算法会做得更好？调试（例如查询日志记录）是否在生产环境中意外启用？您是否正在执行同步操作（例如视频转码、批量电子邮件、文件转换、批量数据上传），这些操作最好外包给异步进程，甚至可能在另一台服务器上？

您的请求是否经常访问数据库以获取可以缓存的内容？考虑集成 memcached 以保存常用内容以便更快地检索。

静态内容服务
如果内容是静态的，则可以相对容易地复制和均衡它。检查您的 Web 服务器（apache、lighttpd、egenix 或 tux 都是流行的候选者）配置，以确保它已优化。简单的 DNS 轮循可以将请求分发到服务器池中。

网络连接
如果面向公众的网络连接是您的瓶颈，那么您的选择非常有限
1) 获得更粗的管道
2) 使用 DNS 将您的服务器分布在地理位置上
3) 使用内容交付网络来缓存内容

如果您的内容生成和网络连接速度很快，但将其转储到网络受到远程用户（例如，低端拨号连接）的限制，您可能会考虑使用像 perlbal [4] 这样的工具来“细水长流”地提供数据，而您的应用程序服务器可以恢复对其他请求的响应。

“进行这种更改的最佳方法是什么？是否可以从小规模开始，并随着需求增长而增加‘集群’？” 当您解决一个瓶颈时，您会在表面下找到其他瓶颈。但是，一个分层良好的架构将允许您将单个“层”视为黑匣子。该层的内容可以是单层或集群。通常，您可以相当透明地扩展每一层，而无需考虑其他层。

“哪些服务在多台服务器上运行良好，哪些服务则不然？”
扩展良好
HTTP（尤其是具有客户端维护状态的 HTTP）、数据库、DNS、NTP、计算时间、NNTP、Jabber、LDAP

通过一些额外的工作可能会很好地扩展
邮件 (SMTP/IMAP/POP)、防火墙、过滤、代理、NFS 文件服务、远程 shell

扩展性不佳：SMB 和 FTP 文件服务

不确定：IRC 和打印服务

希望这能回答您的一些问题，并为您提供更多问题来指导您的搜索。

[1] 关于扩展的部分，请访问 http://www.djangobook.com/en/beta/chapter21/

[2] http://en.wikipedia.org/wiki/Representational_State_Transfer

[3] https://hadoop.apache.ac.cn/core/

[4] http://danga.com/perlbal/

>> 专家答疑是 LinuxJournal.com 独家推出的全新每周专栏。

>> 向我们的专家提问？给他们发送电子邮件。