负载均衡！中级运维必知的10个问题

Posted 2021-04-15 网络民工

点击蓝字

2020

负载均衡！中级运维必知的10个问题

负载均衡是衡量初中级以上运维技术水平的重要标尺！

负载均衡是普通运维人员很难有机会接触和系统学习的知识！

一、负载均衡转发数重要吗？

keepalived + lvs 的组合，执行ipvsadm ，输出的数据显示了每个后端服务器连接的数量，一些服务器的值高些，而一些却低一些。一些人纠结：怎么a服务器活跃数是90，而b服务器才55？

负载均衡的均衡是相对的，当访问量很小的时候，这个差异会明显一些。一旦上量，差别就会缩小。比如活跃数都是数千个，一些机器多几十或者少几百，你不会觉得有什么不妥。

负载均衡的主要目标是高可用，只要负载均衡、监控检查、失败切换三个功能正常，并且从用户的角度出发，访问应用（比如网站）一切正常，才是重点，多几个负载量，少几个负载量无关紧要。

二、哪种负载均衡工具更好？

lvs + keepalived、haproxy+nginx、nginx + keepalived几种组合，keepalived倒是一致之选，而其它几个工具，选谁更好呢？

看场景吧，缓存类的应用，如squid适合lvs；其它情形可根据自己的使用习惯来选择。

现在一般的web服务，弃用apache而选nginx居多，如果负载均衡再部署一个nginx，变成keepalived + nginx + nginx 的形式，个人感觉有点别扭，更愿意选择haproxy。

三、vip不漂移怎么办？

很多时候可能是输入的时候不小心，犯了低级的错误。比如keepalived里边，主备两系统的router_id不一致、或者virtual_router_id不一致。

这类错误比较难以排查，在书写的时候，一定要仔细。

另外一个情况可能是，在同一个局域网内，有多个负载均衡集群存在，集群之间的router_id 、virtual_router_id 要注意分别，保持唯一性。

四、完成负载均衡的最佳实践？

经常在网上有人求助，按文档部署的集群不能正常的工作。通过沟通，发现工作方式往往不正确。

那么正确、高效的方式是什么呢（有些人称最佳实践）？请往下看：

1. 检查后端真实服务是否正常。

   
   

2. 绑定负载均衡器的本地ip（不要绑vip），测试访问是否正常。

   
   

3. 绑定vip进行访问，检查访问是否正常。

五、什么情况下需要负载均衡？

有人说我没那么大的访问量，用负载均衡有点浪费。负载均衡是实现高可用的手段之一，不是以流量大小为出发点的。

如果你的公司或者机构，主要收入来自与网络的话，发生故障造成服务不可访问，造成的损失是否可以忍受，考虑好这个，再做决策。

还有人说，我用了阿里云、腾讯云，弹性计算、高可用，买个高配的云主机，要什么负载均衡！建议多了解一下，这些云服务商有专门的负载均衡，要花钱的，用不着的话，它推这个有啥意义？

六、开源软件不稳定吗？

这是商业解决供应商的说辞，他们的市场做得比较成功，以至于一些技术人员，一旦提及开源解决方案，第一反应就是：开源的稳定么？性能上得去么？

前几天有个系统集成商也只要质疑，我回答他：“你拿一个商业软件，我找一个对应的开源软件比比如何？”

七、公有云上的负载均衡？

大部分公有云不提供havip支持，因此在技术上不太容易实现负载均衡。

从产品设计上考虑，用户自己部署负载均衡，会与云服务商推出的服务产生冲突。

从其不断推出的产品线来看，恨不得把所有的服务都囊括进去，让用户从此依赖服务商，财源滚滚。

八、如何快速排查负载均衡故障？

步骤如下：

A.确定问题是部分还是全部？是网络问题还是系统问题？

B.检查后端服务是否正常。因为后端才是真实提供服务的场所，是整个负载均衡存在的根基（就算负载均衡体系暂时崩溃了，只要后端服务正常，可临时采取措施，把用户请求直接暴露给用户，可最快速度恢复业务）。在实际的工作中，大部分的故障集中在后端服务器，比如大名鼎鼎的502。

C.排查负载均衡是否正常。一般情况下，负载均衡服务器基本不安装其它服务（一机多用者慎重），因此，除了硬盘被日志塞满产生故障外，另外一个可能就是硬件损坏。本人管理的系统，运行时间最长的负载均衡服务器，有超过八年没趴窝的。

九、有负载均衡就完事无忧了么？

部署了负载均衡，后端服务器可以部分失效、负载均衡器本身也可以有一个失效。看起来很让人放心，就算发生故障，也暂时能顶一阵。是不是慢吞吞地地心情好了，想起来了再去做故障恢复？

最好不要这样干，有故障发生，发现以后，尽可能快的把故障修复并再次加入集群，不玩心跳。

十、负载均衡能承载多大的并发？

这与后端服务关系密切，后端程序、逻辑性能极佳，承载的并发数就大；反之就小，无确切的数据支撑。

上线前，有可能对系统做压力测试，但这种测试大部分是一致性测试（至少是同一个访问源），与真实的用户访问还是存在很大差异。

真实的用户访问，来源不同，访问的对象不同，比如有的用户网络环境差，访问速度慢，完成一次连接的时间长，占有资源的释放时间就要久一些。这种测试可做大概的参考，评估时应该预留余量。

本文来源

出于传播网络知识之目的，转载该文章，如需删除，请私信。

2020

加入“网络工程师”交流群

更多内容

1
2
3
4
5

我知道你在看哟