文档结构  
可译网翻译有奖活动正在进行中,查看详情 现在前往 注册?
原作者:Thomas A. Limoncelli    来源:queue.acm.org [英文]
班纳睿    计算机    2017-01-09    0评/374阅
翻译进度:已翻译   参与翻译: toypipi (16)

一位读者最近联系我,询问是否最好使用负载均衡器来增加容量或使服务对于故障可以弹性扩展。 答案是:两者都适合使用负载均衡器。 然而,问题是,大多数使用负载均衡器的人都做错了。

在当今以网络为中心,以服务为中心的环境中,负载均衡器的使用非常广泛。 然而,我断言,大多数时候,他们被错误地使用。 为了理解这个问题,我们首先需要讨论一些关于负载均衡器的内容。 然后我们可以看看问题和解决方案。

第 1 段(可获 1.3 积分)

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

负载均衡的容量与弹性

使用负载均衡器主要有两种途径:增加容量和提高弹性。

第 2 段(可获 1.11 积分)

使用负载均衡器来增加容量非常简单。 如果一个副本不够强大,无法处理整个传入工作负载,则可以使用负载均衡器在多个副本之间分配工作负载。

假设单个副本可以处理100个QPS(每秒查询)。 只要到达的QPS少于100个,它就可以正常运行。 如果到达的QPS超过100个,则副本超载,拒绝请求或崩溃。 这些都不是一个皆大欢喜的局面。

如果将两台机器配置为负载均衡器副本,则其处理的容量为200 QPS;配置三个副本将提供300 QPS的容量,以此类推。 那么需要更多容量的话,只需要添加更多的副本。 这称为水平扩展

第 3 段(可获 1.55 积分)

负载均衡器也可用于提高弹性。 弹性意味着能够承受失败。 即使单个机器出现故障,系统也应继续提供服务。 从物理学上讲:所有机器最终都会失败。 即使一个副本具有接近理想的正常运行时间,因为其他外部因素,如软件升级或移动物理机器的需要,您仍然需要恢复机制。

负载均衡器通过留下足够的备用容量从而实现弹性,单个副本可能会失败,剩余的副本可以继续处理传入的请求。

第 4 段(可获 1.16 积分)

继续该示例,假设已经部署了四个副本以实现400QPS的容量。 如果您当前正在接收300 QPS,则每个副本将接收大约75 QPS(工作负载的四分之一)。 如果单个副本故障会发生什么呢? 负载均衡器将快速处理中断并且转移流量,使得每个副本接收大约100个QPS。 这意味着每个副本以最大容量运行。 快接近它的极限了,但还是可以接受的。

如果系统已经接收400 QPS,该怎么办? 在正常操作下,四个副本中的每个将接收大约100QPS。 然而,如果单个副本宕机,则剩余的副本每个将接收大约133QPS。 由于每个副本可以处理的QPS大约为100,这意味着每个副本将超载三分之一。 系统处理速度将变慢并变得不可用。 并且可能会崩溃。

第 5 段(可获 1.84 积分)

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

使用负载均衡器增加容量或提高弹性之间的区别是操作差异,而不是配置差异。 这两个用例配置硬件和网络(或虚拟硬件和虚拟网络)相同,并使用相同的设置配置负载均衡器。
 

第 6 段(可获 1.26 积分)

术语 N+1 冗余 是指被配置为如果单个副本宕机,则在剩余的N个副本中存在足够的容量以使系统正常工作的系统。 如果没有空闲容量,则系统为 N+0 。 系统也可以被设计为 N+2 冗余,这将允许系统存在两个宕机的副本,等等。

三种错误的方式

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

1级:团队意见分歧

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

第 7 段(可获 1.68 积分)

如果团队存在意见分歧,那么团队的不同成员将做出不同的工程决策。 充其量,这会导致混乱。 在最坏的情况下,它会带来痛苦。

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

2级:容量未定义

另一个可能的错误是在如何测量系统的容量上产生分歧。 没有这个定义,你不知道这个系统是 N+0 还是 N+1。 换句话说,您可能同意负载均衡是为了容量或弹性,但您不知道您是否以这种方式使用它。

第 8 段(可获 1.3 积分)

要想知道(你是否以正确的方式使用负载均衡),你必须知道每个副本的实际容量。在理想情况下,你会知道每个副本可以处理多少QPS。数学方法计算 N+1 阈值(或高水位标记)将仅仅是简单的算术运算。可悲的是,情况并没有那么简单。

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

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

第 9 段(可获 2.19 积分)

当您测量数千或数百万个查询时,如何量化响应时间? 并非所有查询都在相同的时间量内运行。 您不能取平均值,因为单个长期运行的请求可能会导致误导性的统计。 平均值也模糊了双峰分布。 (如果要想了解更多此类信息,请参阅第17章,监测体系结构与实践,云系统管理的实践,卷2,由Thomas Limoncelli,Strata R.Chalup和Christina J.Hogan编写;Addison-Wesley,2015)。

由于取平均值的不足,大多数网站使用百分位数。 例如,可能要求第90百分位数的响应时间必须为200毫秒或更好。 这是一个非常简单的方法来抛出最极端的异常值。 许多网站开始使用MAD(中值绝对偏差),这在2015年由David Goldberg和Yinan Shan所写的论文中有解释,统计异常检测特征的重要性

(https://www.usenix.org/system/files/conference/hotcloud15/hotcloud15-goldberg.pdf).

第 10 段(可获 2 积分)

在这样的基准中使用生成合成查询是另外一个挑战。 并非所有查询都需要相同的时间。 有短期和长期请求。 可以处理100个QPS的副本实际上可以处理80个长查询和120个短查询。 基准必须使用混合查询以反映真实世界的情况。

如果所有查询都是只读的或不改变系统,您只需记录一小时的实际查询,并在基准测试期间回放。 在前雇主那儿,我们有一个110亿的搜索查询数据集用于基准测试我们的服务。 我们将向系统发送前10亿个查询以预热缓存。 我们在剩余的查询期间记录测量值以衡量性能。

第 11 段(可获 1.59 积分)

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

遗憾的是,由于引入了新功能或用户访问模式中意外的更改,查询类型的混合会随时间而变化。 现在能够达到200 QPS的系统可能会因为旧的功能重新获得流行,而在明天就被评为50 QPS。

软件性能会随每个版本而发生改变。 每个版本都应该进行基准测试,以验证假定的容量没有改变。

第 12 段(可获 1.34 积分)

如果这个基准测试是手动完成的,很有可能它将只在主要发布版上测试或很少测试。 如果基准化是自动化的,那么它可以被集成到您的CI(持续集成)系统中。 它应该测试那些明显慢于生产环境中运行版本的那些版本。 这种自动化因为消除了手动任务不仅提高了工程生产率,还提高了工程生产力,因为您能够立即知道导致回归的确切变化。 如果基准测试是偶尔进行地,那么查找性能回归需要几个小时或几天的时间来搜索是哪个更改导致了问题。

第 13 段(可获 1.3 积分)

理想情况下,通过测量生产环境中的实时性能来验证基准。 两个统计数据应该相符。 如果他们没有,你必须验证基准。

基准测试如此复杂的另一个原因是缓存。 缓存有意想不到的副作用。 例如,直观地,您会希望系统在添加副本后会变得更快。 人多好办事嘛。 然而,由于缓存利用率下降,更多的副本反而导致某些应用程序变得更慢。 如果副本具有本地高速缓存并得到高度利用,则更可能命中缓存。

第 14 段(可获 1.21 积分)

3级:定义,但没有监控

团队可能做出的另一个错误是同意所有这些定义,但没有监控以检测您是否遵守。

假设团队已经确定负载均衡器用于提高容量和恢复能力,他们已经定义了一个用于测量副本容量的算法,他们已经做了基准来确定每个副本的容量。

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

不仅应当监控系统的使用情况并在系统不符合要求时向操作团队发出警报,而且还应在系统接近该状态时向系统发出警报。 理想情况下,如果增加容量需要T 分钟,系统需要在获得所需容量之前至少T 分钟发送警报。

第 15 段(可获 1.91 积分)

诸如AWS(Amazon Web Services)的云计算系统具有可以根据需要添加更多容量的系统。 如果您运行自己的硬件,配置新容量可能需要几个星期或几个月。 如果增加容量总是需要访问CFO签署采购订单,那就会让你以为你不是生活在一个动态,快节奏,高科技的世界里。

总结

任何人都可以使用负载均衡器。 正确使用它却要困难得多。 先问问下面这些问题:

1.这个负载均衡器是用来增加容量(N+0)还是提高弹性 (N+1)?

2.如何衡量每个副本的容量? 如何创建基准输入? 如何处理基准结果以达到好与坏之间的阈值?

3.您正在监控是否符合N+M 配置? 您是否以提供足够时间添加容量的方式进行警报,以保持兼容性?

如果这些问题的答案是“我不知道”或“否”,那你就做错了。

第 16 段(可获 2.24 积分)

文章评论