且构网

分享程序员开发的那些事...
且构网 - 分享程序员编程开发的那些事

应用交付工程师Troubleshooting经验分享2

更新时间:2022-08-22 13:46:07

 本文接续之前的文章:应用交付工程师Troubleshooting经验分享

前面讲述了设备登录管理以及可能遇到的网络问题,下面继续讲述4-7层配置及调试中可能遇到的问题:

(一)服务器负载均衡

1.    虚拟服务器(VIP)访问不通

常常有人打来电话,一开口就是我配了VIP后,为什么访问不通呢?这是个很低级而操蛋的问题,我知道你想问为什么访问不通?但一没告诉网络结构是怎样,二没告诉你是怎样配的,三没告诉你已经做了哪些分析和调试,鬼才知道是为什么。但是不解决是不行的,因为打给你电话的可能是客户,所以我们必须要整理思路,循循善诱。

1)    配置正确吗?

   这个是首先要检查的,是自己在现场解决问题,就需要自己细心检查,如果自己搞不定,请人帮忙一定要先把你做的配置发给别人,并且说清楚如下几样事情:

l  客户需求是什么?

l  网络拓扑是怎样的?(网络拓扑直接关系到应当如何配置)

l  服务器是什么应用,什么系统?(不同的应用有不同的特点和不同的配置方式)

l  用户访问流程 (越详细越好)

2)    服务器的服务是起来的吗?

总有这种情况,你的服务器是加电的,但服务是否起来了,可能没留意,所以第一步从负载均衡设备角度先确定服务是否起来了,检查方法:

l  如果设置了ICMP健康检查,检查设备Ping服务器看是否成功。(ICMP健康检查一般配置在Server下面,其他健康检查一般配置在端口下面,若Server检查为down,该所有应用都为down,所有若服务器禁Ping,则只在端口下面设置健康检查,不要用Ping检查服务器地址)

l  去服务器上查看服务是否在运行

l  在负载均衡设备上查看server状态:show slb server

l  在负载均衡设备上用telnet命令探测服务端口,例如:telnet 1.1.1.1 80,若有响应,则服务端口是起来的。

l  以上其实还不够,对于一些三层架构的平台,web服务器端口可能起来了,但应用服务器或者数据库服务器可能有问题,所以还有个检查的办法是直接访问服务器操作一下,确认服务器操作没问题。

3)    服务组是UP的吗?

设备健康检查看到服务器的服务是up的,但访问仍然不通,这时候需要继续确认服务组是否up,毕竟VIP关联的是服务组,只有服务组upVIP才会up

l  检查服务组状态:show slb service-group

l  如果上面显示相应服务组的检查为down,检查服务组中是否单独配置了健康检查,可能跟健康检查有关。

4)    健康检查

一般负载均衡设备都内置了4-7层各种常见协议的健康检查,要单独配置健康检查根据模板自己配置一个即可。有些负载均衡设备(例如A10)对于服务器缺省带四层的健康检查,若不自己对服务组手工另配健康检查,则默认沿用服务器健康检查的结果。而有些设备必须手工配置健康检查。所以健康检查问题可能如下:

l  自己创建的健康检查正确吗? 例如http健康检查要get一个url,你填的url根本就不存在,自然检查不成功。再如一些要求比较复杂的健康检查,要求多个条件进行逻辑与和或混合判断的,往往自己创建的健康检查就不正确,需要仔细调试。

l  服务器或者服务组配的是正确的健康检查吗?经常见到有人在服务组里面配了个ping的检查或者把健康检查配错,例如这不是http服务,但配了个http的健康检查。或者某个健康检查配的是对指定端口的检查,但把他用在了其他端口下面等等。

l  Port 0 仍然保留了健康检查,0代表所有端口,假设你保留了tcp的健康检查,设备可能去探测端口65535,该端口根本就不存在,健康检查自然不会成功。

l  某些特殊的服务不响应你的健康检查,这种情况确实存在,解决的办法只能根据服务器的要求,自己编写一个健康检查脚本去检查它才能成功(该功能只有少数设备能做)。

l  健康检查不停地报up/down, 这种问题很难判断,一种是情况是服务器压力过大,导致有时不能及时响应,另一种情况就比较复杂了,服务器上不知道配置了什么安全软件或者检查机制,导致健康检查不正常,这种情况需要客户自己去检查服务器,负载均衡设备除了多试几种检查策略之外,基本上没有其他可调试的办法。

5)    是否需要配置snat?

如果负载均衡设备是旁路接入,就必须考虑是否要做源地址转换。这基本上要成为本能反应。还有一种情况,如果服务器直连到负载均衡设备,或者虽然是负载均衡设备旁挂接入,但服务器网段跟客户端网段不同,而服务器指的网关是负载均衡设备地址,这个时候是可以不做snat的。需要配snat而没配基本上会出现在一些经验较少的工程师身上,一旦出现这种情况,访问肯定有问题。

6)    会话保持

负载均衡配置三部曲:分发算法,健康检查,会话保持,再加上一个是否要做源地址转换,这些是基本要素,要时刻在心,在做配置的时候就应该本能想到,这些要不要配,怎么配?而不是出问题的时候,才检查到原来这个没有配。一般来说除了一些仅仅提供浏览业务的服务器,例如各大网站的新闻频道等等,客户服务器涉及到用户登录才能操作的系统,那是必须要配会话保持的。至于配了会话保持后,分发是否均衡,以及如何均衡,我们另找专题讨论。

7)    HTTPS证书

如果对外发布的服务是HTTPS,而访问VIP却无法访问,首先检查负载均衡设备上配置的vport协议类型,如果配置的是port 443 tcp,那么负载均衡设备是按照TCP协议来处理,SSL的加解密是由客户端跟服务器之间完成,如果配置的是port 443 https,那么就要检查你在443端口下配置证书模板了吗?不配证书,负载均衡设备无法完成跟客户端之间的SSL交互,你的访问自然不通。如何导入和配置证书模板,可以参看其他文章。

2.    服务器4-7层问题Troubleshooting总结

以上描述多是基本问题的Troubleshooting,更多的疑难问题需要结合自己的经验和用户的应用特点专门分析。不过Troubleshooting的思路是一致的,具体做法总结如下:

l  明确网络拓扑,首先确保二三层工作没问题:网络互连,路由无问题。

l  检查真实服务器状态:show slb server

l  检查服务组状态:show slb service-group

l  检查虚拟服务器状态:show slb virtual-server

l  检查Log,分析Log中的告警信息。

l  万能工具:抓包,无论是二三层,还是四七层的访问,通过抓包可以实时跟踪某个访问的转发处理细节,很多情况下,我们遇到的问题无法从配置以及基本检查中获得原因,这个时候抓包分析是最有用的,例如:用户反映某客户端访问某个Web服务有异常,那么按照如下方式抓包:

Debug packet l3 ip <客户端IP> l4 tcp 80 count 0

Debug monitor

客户端IP访问目的端口为80的包都会被记录下来。对于抓包来说,不但是要会抓包,更重要的能够对抓包内容进行分析,这考验的是你对TCP/IP协议知识的深刻理解。

 

(二)链路负载均衡----容后再续


本文转自 virtualadc 51CTO博客,原文链接:http://blog.51cto.com/virtualadc/1188328