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

开发 架构
负载均衡是衡量初中级以上运维技术水平的重要标尺! 负载均衡是普通运维人员很难有机会接触和系统学习的知识!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

责任编辑:赵宁宁 来源: Cisco思科CCIE俱乐部
相关推荐

2020-06-03 15:25:27

运维架构技术

2024-11-08 17:04:03

Linux运维

2019-05-15 11:14:22

监控工具运维

2018-12-20 10:40:12

Redis架构运维

2019-07-05 07:49:19

TCPIP网络协议

2023-12-15 10:42:05

2009-09-11 10:33:52

招聘秘籍

2020-04-21 10:11:12

运维体系趋势

2011-02-25 09:18:50

WebPHPMySQL

2022-07-27 11:10:27

Kubectl命令运维

2018-12-28 09:11:28

运维监控开源

2021-02-27 17:13:21

前端代码逻辑

2020-05-14 10:27:33

PythonGUI开发

2019-10-17 16:02:44

高并发缓存浏览器

2021-09-18 10:01:25

运维架构技术

2020-07-02 09:55:32

运维架构技术

2023-11-02 10:24:30

KubectlKubernetes

2022-12-02 08:47:36

2014-08-08 15:50:43

性能移动应用性能管理性能监测

2023-11-23 10:21:37

点赞
收藏

51CTO技术栈公众号