你知道几个？中级运维必知的10个问题

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

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

　　1. 负载均衡转发数重要吗?

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

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

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

　　2. 哪一种负载均衡工具更好?

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

　　看场景吧，缓存类的利用，如squid合适lvs;其它情形可针对自己的使用习惯来选择。

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

　　3. vip不漂移怎样办?

　　很多时候多是输入的时候不谨慎，犯了低级的毛病。比如keepalived里边，主备两系统的router_id不一致、或virtual_router_id不一致。

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

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

　　4. 完成负载均衡的最好实践?

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

　　那末正确、高效率的方式是甚么呢(有些人称最好实践)?请往下看：

　　检查后端真实服务是不是正常。

　　绑定负载均衡器的本地ip(不要绑vip)，测试访问是不是正常。

　　绑定vip进行访问，检察访问是不是正常。

　　5. 甚么情况下需要负载均衡?

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

　　如果你的公司或机构，主要收入来自与网络的话，产生故障造成服务不可访问，酿成的损耗是不是可以忍耐，斟酌好这个，再做决策。

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

　　6. 开源软件不稳定吗?

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

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

　　7. 公有云上的负载均衡?

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

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

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

　　8. 如何快捷排查负载均衡故障?

　　步骤以下：

　　肯定问题是部份还是全部?是网络问题还是系统问题?

　　检查后端服务是不是正常。由于后端才是真实提供服务的场所，是全部负载均衡存在的根基(就算负载均衡体系暂时崩溃了，只要后端服务正常，可临时采取措施，把用户要求直接暴露给用户，可最快捷度恢复业务)。在实际的工作中，大部份的故障集中在后端服务器，比如大名鼎鼎的502。

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

　　9. 有负载均衡就完事无忧了么?

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

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

　　10. 负载均衡能承载多大的并发?

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

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

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

免责声明：
本网址（www.yingxiongyun.com）发布的材料主要源于独立创作和网友匿名投稿。此处提供的所有信息仅供参考之用。我们致力于提供准确且可信的信息，但不对材料的完整性或真实性作出任何保证。用户应自行验证相关信息的正确性，并对其决策承担全部责任。对于由于信息的错误、不准确或遗漏所造成的任何损失，本网址不承担任何法律责任。

本网站所展示的所有内容，如文字、图像、标志、音频、视频、软件和程序等的版权均属于原创作者。

如果任何组织或个人认为网站内容可能侵犯其知识产权，或包含不准确之处，请即刻联系我们进行相应处理。