网络连通性测试 – 在青春迷失的咖啡馆

nas的上线依赖于网络，因此和网络有着千丝万缕的联系，需要验证nas在正常上线和非正常的时刻，网络的健康状况，要进行这项测试，就需要两个数据结果，一个是nas上线的时间点，另一个就是网络连通性正常的时间点，但这两点必须是独立的，因为最终的测试需要验证的是两个方面，nas正常上线的时候和网络连通性正常双方的时间间隔有多久，nas不正常的时候网络是否正常，最终的目的就是为了确认nas异常与网络的相关性

由于nas的上线和网络的连通性，最终都体现在云主机里，也就是想获取这两个数据，都绕不开云主机，正常思考大概有两种方式来获取数据，一种是外部轮询的方式，顾名思义，虚拟机外部通过nas api轮询直到判断其上线为止，获取时间戳，同理网络也可以在外部轮询连通虚拟机，获取连通的时间点；另一种是内部探针的方式，也就是获取这两组数据的过程在虚拟机内部进行，通过注入脚本到服务当中，使得开机启动的时候执行并打印对应的时间戳，保存起来，其中为了准确性这里说的全部都是独立地打印时间戳，结束之后再来进行二次分析，而不是++时间间隔来获取总的用时

这里选择后一种方法，nas理论上网络正常情况下上线用时少于1S，因此如果还通过轮询api查询的方式，肯定会有轮询耗时，最好的方式就是nas自己来将上线时间戳打印出来，这是最准确的，当然这可能只存在于测试版本当中，上线版本尽量还是要性能和稳定性，网络可以通过一个脚本持续测试连通性，连通后打印时间戳立马退出，脚本可以放到开机服务当中，如此一来，整个测试流程就比较清晰了，虚拟机内部安装打印上线时间版本的nas和打印网络连通时间的脚本，部好这两个探针之后，打一个快照，然后通过这个快照进行恢复创建云主机，每次获取两者时间，进行验证；这种测试不可能就一台虚拟机手动reboot每次看下结果，打快照的原因就是将这整个过程写在自动化脚本当中，持续进行创建删除虚拟机，每次获取验证数据，并且最终给出可视化分析结果

nas打印时间直接交给了程序当中，但network的验证脚本，则需要放到系统开机服务当中，比如一个简单的通过ping验证脚本

#!/bin/bash

while true; do
    ping -i 0.2 -c 5 114.114.114.114 > /dev/null
    if test $? -eq 0; then
        date '+%H:%M:%S:%N' > /root/network.time
        break
    fi
done

然后将脚本的启动放到/etc/rc.local里

/bin/bash /usr/local/src/network.sh &

这种方式，最终打印的时间戳，应该是network的时间比nas还要后，此时首先为了确认是否是脚本内部轮询导致，因此脚本里加一个打印轮询次数的变量

#!/bin/bash

i=1
while true; do
    ping -i 0.2 -c 5 114.114.114.114 > /dev/null
    if test $? -eq 0; then
        date '+%H:%M:%S:%N' > /root/network.time
        echo "No: $i" >> /root/network.time
        break
    fi
    i=`expr $i + 1`
done

此时无论怎么测试，打印的轮询次数$i都是1，也就是说第一次发出ping包测试，网络就已经连通性完好，如此一来可能会猛拍脑袋，/etc/rc.local是在所有服务最后执行的，此时网络早好，nas早上线了，还跑来测试网络打印时间，花儿都谢了

因此将服务提前，这次看上了nas的启动服务，直接将测试脚本放到nas启动之前的cloud-init服务里，此时测试结果依旧是network时间比nas时间后，还是只轮询一次，原因还是没想清楚，这里脚本写的时候思想是对的，不受任何干扰，直到网络通，但是有一个弊端，就是如果脚本在启动的时候，网络已经好了，那么测试就没任何作用，打印的时间戳明显滞后，这就是为什么打印的轮询次数一直是1，每次第一次发送ping包的时候，都测试成功，想到这里，可以直接将脚本放到一个开机启动顺序很前的服务即可

稍微思索了一会，抱着找问题的想法，决定将network的测试放到networking服务启动的开始执行，在测试的过程中，居然出现了偶尔network时间在前，偶尔nas时间在前的现象，出现这个问题应该就是脚本的问题了，这里每次发5个icmp包验证花了1秒，也就是脚本用时至少1秒，这区区一秒钟可能就是影响时间波动的根源，将每次发送5个icmp包改成1个，再进行测试，大部分情况network都在nas之前了，间隔基本在毫秒级别

但是最终为了测试数据准确性，脚本尽量还是放在启动时间很早的服务当中，比如/etc/rcS.d/S01hostname.sh就是一个不错的选择

最终的结果大约相差

root@nvs-nas-vm:~# date -d @1462724006
Mon May  9 00:13:26 CST 2016
root@nvs-nas-vm:~# cat network.time
00:13:25:512969970

知道了输出，下面的工作就是自动化脚本里来构建整个流程，最终挑一个合适的时间将这两个时间给抓取出来进行验证了，所谓合适的时间就是这两个时间都成功打印了，或者能够断定出现故障

这种时间的测试，我觉得关于准确性关键就是找到正确的打印时间戳的方法，而且相互之间不能有依赖或者干扰，最终再来将时间戳抓取出来进行二次分析，有关轮询或者等待越少越好

发表回复 取消回复

发表回复取消回复