国内共有云互通测试

这是一篇部署网络同时又如何分析遥测数据，并涉及一些简单的python分析统计数据的操作，供大家学习参考。
起因是昨天想测试一下分布式SDWAN部署的可靠性以及验证国内几个公有云的互联带宽情况如何，于是就做了一些测试，大概就按照如下的拓扑组了一张网，构建了一个基于公有云的覆盖全国的网络，共计13个VPC，一个私有云，还有一个电信宽带接入路由器。
如果使用传统的VPN组网或者物理设备组网，这么大的一个工程可能要耗时几个月，而基于公有云VPC和SDWAN构建，我一个人用了2小时不到就全网连通了，这在以前是难以想象的。

1.测试环境概述
前一篇文章<企业应该如何上云？>提到了TLOC的编址方式,也就是说根据不同的区域配置Site-ID，根据不同的接入设备配置SystemIP，根据不同的运营商配置Color

我们这次测试也根据这样的规则来进行编址，由于阿里云的UI橙色偏红，腾讯云UI偏蓝色，我们就按照Red/Blue区分这两个云，而私有云标记为了MPLS，中国电信标记成土豪金？Site-ID编码上，阿里云统一使用5000号段，腾讯云6000号段，自己家里和公司私有云为101和201，System-IP作用和Router-ID类似，不做路由。
云上虚拟主机的区域私网和公网地址以及主机类型如下图所示：

某司SDWAN路由器开局非常简单，指定Site-ID/System-IP和ZTP的Vbond地址就好，然后公网地址由于各个VPC都有NAT，直接DHCP动态获取，VPC内部的网络可以选择具有双网卡的虚机，但是这次测试并不做应用流量的测试，仅配置了Loopback口做路由通告和连通性测试。

2.测试结果
2.1 SLA数据获取和预处理

SLA结果采用SDWAN的Edge路由器进行的SLA测量获得，并通过控制器北向接口查询链路SLA的历史值，主要包括延迟抖动和丢包统计，按照每三十分钟聚合一次，选取过去24小时的数据，具体API的使用看文末。

然后这种临时的测试我也懒得写分析的脚本了，多抓了几行然后python里面直接json.loads就好，最后Pandas里再处理一下时间戳和时区就好了,然后把各列整理一下，总共大概有一万行数据

system_ip = { "5.0.0.1":"阿里云北京", "5.0.2.1":"阿里云呼和浩特", "5.0.3.1":"阿里云杭州", "5.0.4.1":"阿里云深圳", "5.0.5.1":"阿里云香港", "6.0.0.1":"腾讯云广州", "6.0.0.2":"腾讯云南京", "6.0.0.3":"腾讯云北京", "6.0.0.4":"腾讯云上海", "6.0.0.5":"腾讯云成都", "6.0.0.6":"腾讯云重庆", "6.0.0.7":"腾讯云东京", "6.0.0.8":"腾讯云莫斯科", "101.0.0.1":"香港私有云", "201.0.0.2":"上海电信"}
color = { "red":"阿里云", "blue":"腾讯云", "mpls":"私有云", "gold":"电信宽带"}

df['datetime']=pd.to_datetime(df['entry_time']+8*3600*1000,unit='ms')
df[['src_t','dst_t']]=df['name'].str.split("-", n=1,expand=True)df[['src_ip_t','src_sp_t']]=df['src_t'].str.split(":", n=1,expand=True)df[['dst_ip_t','dst_sp_t']]=df['dst_t'].str.split(":", n=1,expand=True)
df['src'] = df['src_ip_t'].apply(lambda x:system_ip[x])df['src_sp'] = df['src_sp_t'].apply(lambda x:color[x])df['dst'] = df['dst_ip_t'].apply(lambda x:system_ip[x])df['dst_sp'] = df['dst_sp_t'].apply(lambda x:color[x])data = df[['datetime','src','src_sp','dst','dst_sp','latency','jitter','loss_percentage']]

‍

2.2 延迟数据分析例如我们要看从对比上海电信访问腾讯云和阿里云大陆主要AZ线路的平均统计，按照如下方式过滤就好

t1=data[ (data['src']=='上海电信') & (data['dst_sp']=='腾讯云') & (data['dst']!='腾讯云莫斯科')& (data['dst']!='腾讯云东京')].groupby(data['datetime']).mean()t2=data[ (data['dst']=='上海电信') & (data['src_sp']=='阿里云')& (data['src']!='阿里云香港') ].groupby(data['datetime']).mean()stats=t1.join(t2,lsuffix='_t', rsuffix='_a')
//然后用了一个zartbot.Fin的量化风险分析库//其实就是bokeh外面加了一个wrapper比较容易处理时序chart1 =ptrisk.bokeh_multi_line_chart(stats,['latency_t','latency_a'],['腾讯云','阿里云'],title='延迟统计')chart2 =ptrisk.bokeh_multi_line_chart(stats,['loss_percentage_t','loss_percentage_a'],['腾讯云','阿里云'],title='丢包统计')ptrisk.show_column([chart1,chart2])

‍

总体来看延迟都是可以接受的，阿里在夜间延迟明显降低，而腾讯云在夜间网络空置状态延迟还在加高不知道是什么问题，另外腾讯平均延迟高于阿里，主要是因为在腾讯云新增了两个西部节点. 
互相访问的统计表也好做,
 
先把这一天的
值
求
平均中位数和方差

t2=data.groupby([data['dst'],data['src']]).agg(['mean','median','std'])t2.columns =[ "_".join(x) for x in t2.columns.ravel()]t3=t2.iloc[:,0:9].reset_index()

然后利用pivot_table画表格就好了呀：

t4= t3.pivot_table(index=['src'],columns='dst')['latency_mean']
//顺便用seaborn染个色好看点import seaborn as snscm=sns.light_palette("green",as_cmap=True)t4.fillna(0).style.background_gradient(cmap=cm).format("{:3.1f}").highlight_max(color='red')

丢包率的统计:

t4= t3.pivot_table(index=['src'],columns='dst')['loss_percentage_mean']
t4.fillna(0).style.background_gradient(cmap=cm).format("{:3.2f}%").highlight_max(color='red')

‍

可以看到公有云互访丢包率还是有区别的，例如腾讯云广州到腾讯云莫斯科有明显的优化，在很多企业做跨境生意的时候，例如去往莫斯科的流量就可以从广州或者重庆绕行，SDWAN配置相应的policy就好。最后是抖动统计：

t4= t3.pivot_table(index=['src'],columns='dst')['jitter_mean']t4.fillna(0).style.background_gradient(cmap=cm).format("{:3.2f}ms").highlight_max(color='red')

两家云都有好多老朋友，大家都一个圈子混的，就不评价不比较了，有兴趣咱私下聊聊人生~

2.3 SDWAN控制器界面呈现
回到SDWAN来多说几句，毕竟这些传统的电信设备厂商在UI和前端框架上比起互联网厂商还差一大截，总体来说界面比较土，但是还好基本功能还在：

设备层面的功能显示也还不错，信息还算清楚：

应用识别也还算准确，并且可以应用分组和单个应用显示

zartbot.Front: 整个网页仿佛利用了固定尺寸的<div>搞得滚动条让人看起来不爽….整个界面也没有使用webpack封装并split成多个文件，所以单个app.js和vendor.js，跟后台交互采用定期的pull notification的方式，没有websocket，整体技术栈还是最老的angular.js 页面刷新慢…

2.4 SDWAN控制器北向接口
UI做的一般，但北向的Restful API接口还算不错,访问
https://<vmanageip>/apidocs 
即可获得详细的文档，而且直接可以在文档上进行API测试

例如访问这个API<
https://vmanage.ip/dataservice/statistics/approute/fec/aggregation
>可以使用类似于ElasticSearch的Query API接口或许不同的链路类型

{ "query": { "condition": "AND", "rules": [ { "value": [ "24" ], "field": "entry_time", "type": "date", "operator": "last_n_hours" }, { "value": [ "6.0.0.6:blue-6.0.0.8:blue", "6.0.0.1:blue-5.0.0.1:red" ], "field": "name", "type": "string", "operator": "in" } ] }, "aggregation": { "field": [ { "property": "name", "sequence": 1 }, { "property": "state", "sequence": 1 }, { "property": "proto", "sequence": 2 } ], "histogram": { "property": "entry_time", "type": "minute", "interval": 30, "order": "asc" }, "metrics": [ { "property": "latency", "type": "avg" }, { "property": "jitter", "type": "avg" }, { "property": "loss_percentage", "type": "avg" } ] }}

好了，该下课啦~ 
下集预告，如何在家通过SDR自制4G LTE基站~