应用交付工程师Troubleshooting经验分享
Posted lsgxeva
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了应用交付工程师Troubleshooting经验分享相关的知识，希望对你有一定的参考价值。
应用交付工程师Troubleshooting经验分享
应用交付设备在网络中的作用比较特殊，一边跟客户端通信，需要支持二三层交换机的功能，另一边跟后面的服务器或者其他应用设备相连，需要支持Layer 4的协议转换，但是这只是基本功能，应用交付设备作为具体应用的代理或者中转器，需要支持Layer7的功能，根据不同的应用协议，做出不同的分析处理或者优化。
以上特点决定了一个应用交付工程师不是简单地学习一下手册或者接受一下培训，再加上一定的知识基础就立刻能够胜任，必须不断地丰富知识范围，并且对各方面精研原理，才能成为专家。
能力的缺陷在Troubleshooting的时候特别能够显现出来，做技术的每个人都经历过菜鸟阶段，不同的人可能出过不同的丑，前人栽树，后人乘凉，希望本文的经验能够对从事这一行业的同行有一些启示和帮助。
下面我们来对具体问题一一分析：
- 1. 登录问题
某一天你去客户那儿做测试，你对设备并不熟悉，因此心里有些胆怯，然而怕什么来什么，倒弄了半天，连设备都没登录上去，客户一脸愠色地在旁边看着，你的心越来越乱，这是很多人曾经经历过的场面。今天颇有经验的你，对此有何对策？我们分为各种现象讨论：
1）设备加电了吗？
切莫笑，这个低级错误真有人犯过。一个场景是设备之前就拿到了客户机房，你是后来去做配置，机房嘈杂，你以为已经加电，加上客户在旁边看着，心里慌张，上前连上电脑就开始登录，试了Web界面不行，命令行还是不行，Console口仍然没有反应，弄了半天，反而是客户在旁边说了句:还没开机吧? 你恍然大悟，继而无地自容。这种事没什么可说的，没有任何技术因素，克服心理慌张即可。
2）Console口无法登录
设备确认已经启动，但是Console口无法登录，终端上没有任何显示，这也是很急人的事情。不慌张，检查一下：
l 波特率等配置是否跟设备手册要求的一致？
l 你是不是把Console线插到了Mgmt口？（某些设备Console口和Mgmt口外观是一样的）
l 换根Console线试试：Console线可能坏了？或者你的Console线是不是电脑城买的便宜货？（某些厂家的设备对Console线有一定要求，不是什么线都行）
l 如果可能，重启一下设备试试？
l 先不管Console口，试试从管理口登录一下？
3）管理口没有回应
l 你电脑配地址了吗？
l 如果电脑配了地址仍然没有显示，管理口的地址是否被人改过？先试着从Console口进去看一下，如果console口也登录不上，那么赶紧问问是否有人改了管理口地址吧。
l 设备启动成功了吗？
４）管理口无法登录
命令行和Web界面都有登录提示，但用默认密码登录不进去，最大的可能是密码被人改了，小部分可能是设备启动的不完全，登录认证模块有问题。
如何恢复默认密码？
一般设备都有reset password的方法，打电话问人也好找资料也好，学会恢复初始密码即可。
５）无法通过数据口登录
l 你的电脑上IP地址配对了吗？
l 电脑连接的设备端口是否是UP的？有些设备需要Enable端口才能通。
l Web登录不了？配置中开放了Web访问吗？
l Telnet登录不了？配置中开放了Telnet访问吗？
l SSH登录不了？配置中开放了SSH访问吗？
- 2. 网络问题
设备能够登录，我们开始进行配置，先根据客户的规划，配置网络，划分vlan，配好地址，然后测试连通性，问题又出现了。
1） 网关不通
直接ping对端网关不通，有多个因素需要检查，最基本的我们应该首先验证设备是否学到了对端的mac地址，这个通过show arp或者show mac这样的命令可以看到，如果本机根本没有学到对端的mac地址，那么必须注意如下几点：
l 端口是否up的？无论是本设备端口还是对端设备端口，如果没有up，自然网络不通，这个通过类似show interface的命令看一下就知道了。
l 对端网关配地址了吗？客户告诉你网关是某某地址，但不见得已经配好或者启用。
l 自己配的地址是否不小心配错了？总有这样粗心大意的工程师。
l 是否把线错误地插到了别的vlan/端口？
2） 路由不通
从设备上ping跟设备非直连的内部服务器或者ping外部公网地址不通。检查如下几方面：
l 设备上配了到目的地址的路由吗？
l 中间的交换机/路由器等配了返回路由吗？
l 中间是否有防火墙没有开放访问策略？
l 你访问的地址存在吗？
3） 网络问题Troubleshooting工具/命令
l Arp : 检查二层连通性。
l Ping: 检查三层连通性。
l Traceroute: 在到达某一目的地址存在多条路由的情况下，验证数据包路径。
l Debug: 某些设备厂家会内置Debug命令，可以做到二到七层的数据包检查，通过Debug命令，数据包的流向等一清二楚，这是应用交付工程师的终极工具，在后面分析应用问题时还要提到它，一定要掌握。
（未完待续，后文将讲述跟应用相关的各种问题）
前面讲述了设备登录管理以及可能遇到的网络问题，下面继续讲述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协议知识的深刻理解。
以上是关于应用交付工程师Troubleshooting经验分享的主要内容，如果未能解决你的问题，请参考以下文章