本文接续之前的文章：应用交付工程师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关联的是服务组，只有服务组up，VIP才会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 万能工具：抓包，无论是二三层，还是四七层的访问，通过抓包可以实时跟踪某个访问的转发处理细节，很多情况下，我们遇到的问题无法从配置以及基本检查中获得原因，这个时候抓包分析是最有用的，例如：用户反映某客户端访问某个Ｗeb 服务有异常，那么按照如下方式抓包： Debug packet l3 ip < 客户端IP> l4 tcp 80 count 0 Debug monitor 客户端IP 访问目的端口为80 的包都会被记录下来。对于抓包来说，不但是要会抓包，更重要的能够对抓包内容进行分析，这考验的是你对TCP/IP 协议知识的深刻理解。
（二）链路负载均衡----容后再续
本文转自 virtualadc 51CTO博客，原文链接:http://blog.51cto.com/virtualadc/1188328
