一切系统管理 - @YesThatTom

2016年12月20日
第14卷，第6期

一切系统管理：你是否错误地使用了负载均衡？

任何人都可以使用负载均衡器。但正确使用它们则困难得多。

Thomas A. Limoncelli

最近一位读者联系我，询问使用负载均衡器来增加容量还是提高服务对故障的弹性更好。答案是：两者都是负载均衡器的适当用途。然而，问题在于，大多数使用负载均衡器的人都在错误地使用它。

在当今以网络为中心、以服务为中心的环境中，负载均衡器的使用非常广泛。但我认为，大多数时候它们都被不正确地使用。为了理解这个问题，我们首先需要简单讨论一下负载均衡器。然后我们可以看看问题和解决方案。

负载均衡器接收请求并将它们分配给两台或多台机器。这些机器被称为副本，因为它们提供相同的服务。为了简单起见，假设这些是来自Web浏览器的HTTP请求，但负载均衡器也可以用于HTTPS请求、DNS查询、SMTP（电子邮件）连接和许多其他协议。大多数现代应用程序都设计为在负载均衡器后面工作。

用于容量与弹性的负载均衡

使用负载均衡器主要有两种方式：增加容量和提高弹性。

使用负载均衡器来增加容量非常简单。如果单个副本的性能不足以处理整个传入的工作负载，则可以使用负载均衡器在多个副本之间分配工作负载。

假设单个副本可以处理100 QPS（每秒查询数）。只要到达的QPS少于100，它应该运行良好。如果到达的QPS超过100，则副本将过载、拒绝请求或崩溃。这些都不是令人愉快的情况。

如果负载均衡器后面配置了两台机器作为副本，则容量为200 QPS；三个副本将提供300 QPS的容量，依此类推。随着需要更多容量，可以添加更多副本。这就是水平扩展。

负载均衡器也可以用于提高弹性。弹性意味着在发生故障时生存的能力。单个机器会发生故障，但系统应继续提供服务。所有机器最终都会发生故障——这是物理定律。即使副本具有接近完美的正常运行时间，由于软件升级或物理移动机器的需求等其他外部因素，您仍然需要弹性机制。

负载均衡器可以通过保留足够的备用容量来实现弹性，以便单个副本发生故障时，其余副本可以处理传入的请求。

继续这个例子，假设已部署四个副本以实现400 QPS的容量。如果您当前接收到300 QPS，则每个副本将接收大约75 QPS（四分之一的工作负载）。如果单个副本发生故障会怎样？负载均衡器将迅速看到中断并转移流量，以便每个副本接收大约100 QPS。这意味着每个副本都以最大容量运行。这很冒险，但可以接受。

如果系统一直在接收400 QPS怎么办？在正常运行情况下，四个副本中的每个副本将接收大约100 QPS。但是，如果单个副本死亡，则其余副本将各自接收大约133 QPS。由于每个副本可以处理大约100 QPS，这意味着它们中的每一个都过载了三分之一。系统可能会缓慢爬行并变得无法使用。它可能会崩溃。

负载均衡器使用方式的决定因素是到达的工作负载是否高于或低于300 QPS。如果到达的QPS为300或更少，这将是用于弹性的负载均衡器。如果到达的QPS为301或更多，这将是用于增加容量的负载均衡器。

使用负载均衡器来增加容量或提高弹性之间的区别是操作上的区别，而不是配置上的区别。这两种用例都配置相同的硬件和网络（或虚拟硬件和虚拟网络），并使用相同的设置配置负载均衡器。

术语N+1 冗余指的是这样配置的系统：如果单个副本死亡，则在剩余的N个副本中留下足够的容量，以使系统正常工作。如果系统没有备用容量，则系统为N+0。系统也可以设计为N+2冗余，这将允许系统在两个副本死亡后仍然存活，依此类推。

三种错误的做法

现在我们了解了负载均衡器可以使用的两种不同方式，让我们检查一下大多数团队是如何失败的。

级别 1：团队意见不一致

询问团队成员负载均衡器是用于增加容量还是提高弹性。如果团队中不同的人给出不同的答案，那么您就错误地使用了负载均衡。

如果团队意见不一致，那么团队中不同的成员将做出不同的工程决策。往好了说，这会导致困惑。往坏了说，这会导致痛苦。

您会惊讶于有多少团队处于这个级别。

级别 2：容量未定义

另一个可能犯的错误是未就如何衡量系统容量达成一致。没有这个定义，您就不知道此系统是N+0还是N+1。换句话说，您可能就负载均衡是用于容量还是弹性达成了一致，但您不知道您是否正在以这种方式使用它。

要确定，您必须知道每个副本的实际容量。在理想的世界中，您会知道每个副本可以处理多少QPS。计算N+1阈值（或高水位线）的数学运算将是简单的算术。可悲的是，世界并非如此简单。

您不能简单地查看源代码并了解每个请求将需要多少时间和资源，并确定副本的容量。即使您确实知道副本的理论容量，您也需要通过实验来验证它。我们是科学家，而不是野蛮人！

容量最好通过基准测试来确定。生成查询并以不同的速率发送到系统，并测量响应时间。假设您认为200毫秒的响应时间足够了。您可以从每秒生成50个查询开始，然后缓慢增加速率，直到系统过载并且响应速度慢于200毫秒。导致响应时间足够快的最后一个QPS速率决定了副本的容量。

在测量数千或数百万个查询时，您如何量化响应时间？并非所有查询都以相同的时间运行。您不能取平均值，因为单个长时间运行的请求可能会导致误导性的统计数据。平均值还会掩盖双峰分布。（有关更多信息，请参见Thomas Limoncelli、Strata R. Chalup和Christina J. Hogan撰写的《云系统管理实践，第2卷》第17章“监控架构与实践”；Addison-Wesley，2015年）。

由于简单的平均值是不够的，因此大多数站点都使用百分位数。例如，要求可能是第90百分位数的响应时间必须为200毫秒或更短。这是一种非常容易的方法来剔除最极端的异常值。许多站点开始使用MAD（中位数绝对偏差），David Goldberg和Yinan Shan在2015年发表的论文《统计异常检测特征的重要性》（https://www.usenix.org/system/files/conference/hotcloud15/hotcloud15-goldberg.pdf）中对此进行了解释。

生成用于此类基准测试的合成查询是另一个挑战。并非所有查询都花费相同的时间。有短请求和长请求。可以处理100 QPS的副本实际上可以处理80个长查询和120个短查询。基准测试必须使用反映真实世界的混合。

如果所有查询都是只读的或不改变系统状态，则可以简单地记录一小时的实际查询并在基准测试期间重放它们。在以前的雇主那里，我们有一个包含110亿个搜索查询的数据集，用于基准测试我们的服务。我们会将前10亿个查询发送到系统以预热缓存。我们在剩余的查询期间记录测量结果以评估性能。

并非所有工作负载都是只读的。如果需要读取和写入查询的混合，则基准测试数据集和过程会复杂得多。重要的是，读取和写入查询的混合反映了真实世界的场景。

可悲的是，由于新功能的引入或用户访问模式的意外变化，查询类型组合可能会随时间变化。今天能够达到200 QPS的系统明天可能会被评为50 QPS，因为旧功能获得了新的普及。

软件性能可能会随着每个版本而变化。每个版本都应进行基准测试，以验证容量假设是否已更改。

如果此基准测试是手动完成的，则很有可能仅在主要版本或很少的情况下才完成。如果基准测试是自动化的，则可以将其集成到您的CI（持续集成）系统中。它应该使任何比生产环境中运行的版本慢得多的版本都失败。这种自动化不仅提高了工程生产力，因为它消除了手动任务，而且还提高了工程生产力，因为您可以立即知道导致回归的确切更改。如果基准测试偶尔进行，那么查找性能回归将涉及数小时或数天来搜索哪个更改导致了问题。

理想情况下，基准测试也通过测量生产环境中的实时性能来验证。这两个统计数据应匹配。如果它们不匹配，则必须校准基准测试。

基准测试如此复杂的另一个原因是缓存。缓存具有意想不到的副作用。例如，直观上您会期望随着副本的增加，系统应该变得更快。人多力量大。然而，某些应用程序随着副本的增加而变慢，因为缓存利用率下降了。如果副本具有本地缓存，则如果副本被高度利用，则更有可能发生缓存命中。

级别 3：已定义但未监控

团队可能犯的另一个错误是已就所有这些定义达成一致，但没有监控来检测您是否符合要求。

假设团队已确定负载均衡器用于提高容量和弹性，他们已定义了用于测量副本容量的算法，并且他们已完成基准测试以确定每个副本的容量。

下一步是监控系统以确定系统是否为N+1或任何期望的状态。

系统不仅应监控利用率并在系统不符合要求时向运维团队发出警报，还应在系统接近该状态时向团队发出警报。理想情况下，如果添加容量需要T分钟，则系统需要在需要该容量之前至少T分钟发送警报。

云计算系统（如AWS（亚马逊网络服务））具有可以按需增加更多容量的系统。如果您运行自己的硬件，则配置新容量可能需要数周或数月。如果添加容量始终需要拜访CFO以签署采购订单，那么您就没有生活在您认为的动态、快节奏、高科技的世界中。

总结

任何人都可以使用负载均衡器。正确使用它则困难得多。一些需要询问的问题

1. 此负载均衡器是用于增加容量 (N+0) 还是提高弹性 (N+1)？

2. 您如何衡量每个副本的容量？您如何创建基准测试输入？您如何处理基准测试结果以得出好与坏之间的阈值？

3. 您是否正在监控您是否符合您的N+M配置？您是否以提供足够时间来增加容量的方式发出警报，以便您保持合规？

如果对这些问题中的任何一个的回答是“我不知道”或“否”，那么您就做错了。

Thomas A. Limoncelli 是纽约市Stack Overflow Inc.的站点可靠性工程师。他的著作包括云管理实践 (http://the-cloud-book.com),系统和网络管理实践 (http://the-sysadmin-book.com), 和系统管理员的时间管理。他的博客在 EverythingSysadmin.com ，推特在 @YesThatTom。他拥有德鲁大学计算机科学学士学位。