AWS、Azure、Google,VPC哪家强?

SSDFans 2020-12-02


点击蓝字
关注我们



故事的开始是这样的,遇到有人说他们想要去了解AWS的VPC的技术细节,然后说要在AWS的公有云上创建几个实例,希望通过抓包来分析AWS的VPC的实现细节。当时我就忍不住跳出来说,如果AWS的VPC可以提供这么的功能的话,他们的实现细节岂不早被人学会了。毕竟,VPC是基于overlay的网络,在三层的物理网络上实现一个大二层的专用网络,如果能看到物理三层的东西的话,岂不是太不安全了。


但是,后来的发展的确说明我可能想的太多,因为AWS的确从2015年开始就提供了VPC  Flow Log[1]这样的服务。当然,大家也不要想太多,这个功能的目的主要是提供给大规模上云的用户来做自家的VPC内的网络故障排除的。如果AWS真的说可以让你抓到ENA上的网络包,建议你三思。


VPC的故事和其他人一样都是从OVS+VXLAN开始的,如下图。


AWS的服务提供如下的几种类型:

  • Accepted and rejected Traffic

  • No data and skipped records

  • Security group and network ACL rules

  • IPv6 traffic

  • TCP flag sequence

  • Traffic through a NAT gateway

  • Traffic through a transit gateway

需要注意的事,AWS说提供的是VPC Flow的信息,也就可以认为这个信息只能是一跳的内容,和传统的wireshark的TCP session还是不同的。

关于AWS的VPC log的格式以及使用场景,AWS一如既往地提供了详细文档,就不赘述了。其中有意思的点如下:

 当创建一个客户可定制的flow log时候的选项包含:


${version} ${account-id} ${interface-id} ${srcaddr} ${dstaddr} ${srcport} ${dstport} ${protocol} ${packets} ${bytes} ${start} ${end} ${action} ${log-status} ${instance-id} ${subnet-id} ${vpc-id} ${pkt-srcaddr} ${pkt-dstaddr} ${tcp-flags} ${type}

其中,version 2和3 的区别:2是AWS default设置,并保存在S3上。3是客户定制的。

其中的两项需要多说一下:

pkt-srcaddr 和pkt-dstaddr. 当ena有多个IP地址,或者和NAT网关连接的时候,使用缺省的log的格式,其中的IP信息其实是不正确的,这个使用这个字段来提供正确的信息。




看了老大的服务,老二Azure肯定也要了解一下。[2] Azure毕竟是software公司出身,相对AWS的简单的CSV格式,提供了基于JSON的输出,而且比较合理地做了进一步的整合,提供了flowtuples的方式可以把一个TCPsession多个flow 保留在一起。因为包含了两个方向的,因此package_send有了两个方向的内容。


正因为做了聚合,因此不需要AWS那个相对比较别扭的pkt_srcaddr和pkt_destaddr. 和AWS相比,没有包含帐号信息,感觉是对于一个具体的VPC的subnetwork的flow信息。AWS 的格式则是包含了一个帐号内的一个VPC网络的子网内的一个EC2实例上的一个ENA网卡的包信息。


对于另一个巨头Google来讲,简直把这个log玩出了花[3]。因为google号称可以实现跨数据中心的迁移,因为在Flow log中包含了太多的信息。特别贴心的是有个五元组的结构,估计查询上肯定极为舒适。

不仅包含了实例的信息,源和目的的都有:

InstanceDetails 字段格式

字段 类型 说明
project_id 字符串 包含虚拟机的项目的 ID
vm_name 字符串 虚拟机的实例名称
region 字符串 虚拟机所在的地区
zone 字符串 虚拟机所在的区域

同时还包含了地理信息,对,你没看错:

GeographicDetails 字段格式

字段 类型 说明
continent 字符串 外部端点所在的大洲
country 字符串 外部端点所在的国家/地区,采用 ISO 3166-1 Alpha-3 国家/地区代码的形式表示。
region 字符串 外部端点所在的地区
city 字符串 外部端点所在的城市
ASN int32 此端点所属外部网络的自治系统编号 (ASN)。

当然Google的内部的cluster和pod的信息也不隐藏了。


只能说Google把一个VPC日志能够包含的,VPC可能涉及的,可以透露的信息都提供了。


而且,大家都知道Google喜欢RTT,他同样提供一个

rtt_msec int64
延迟基于时间间隔测量,仅适用于 TCP 流。测量延迟是发送 SEQ 和接收相应的 ACK 之间所经历的时间。延迟结果是网络 RTT 与应用所耗用的时间之和。

这个,可以算是很多网管都感兴趣的信息吧。


回到国内的公有云,目前能够拿到详细信息的有aliyun[4]和华为云。

浓浓的AWS风格,这个也没错,毕竟云业务要做到简单,可靠,耐操。毕竟云用户中不懂JSON和递归结构的才是优质客户。


华为云:

没有使用AWS和aliyun那种直接,扁平的方式,而是和Google一样加了一个project的概念来提供VPC中的subnetwork的信息。


最后,看到公有云上面玩的这么花,其实硬件厂家是拒绝的。network switch肯定也可以做,但是如果能做到Google这样的per cluster和pod,估计在现有架构上就难了。因此就有了INT

这下子,一个协议横跨软硬件,功能估计是复杂了很多,但是接受程度如何呢?


[1]https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs-records-examples.html

[2]https://docs.microsoft.com/en-us/azure/network-watcher/network-watcher-nsg-flow-logging-overview

[3]https://cloud.google.com/vpc/docs/flow-logs

[4]https://www.alibabacloud.com/help/zh/doc-detail/127150.htm?spm=a2c63.p38356.b99.79.60101bbfTB4SXX

[5]https://support.huaweicloud.com/intl/en-us/usermanual-vpc/FlowLog_0002.html



高端微信群介绍

创业投资群


AI、IOT、芯片创始人、投资人、分析师、券商

闪存群


覆盖5000多位全球华人闪存、存储芯片精英

云计算群


全闪存、软件定义存储SDS、超融合等公有云和私有云讨论

AI芯片群


讨论AI芯片和GPU、FPGA、CPU异构计算

5G群


物联网、5G芯片讨论

第三代半导体群

氮化镓、碳化硅等化合物半导体讨论

储芯片群

DRAM、NAND、3D XPoint等各类存储介质和主控讨论

汽车电子群

MCU、电源、传感器等汽车电子讨论

光电器件群

光通信、激光器、ToF、AR、VCSEL等光电器件讨论

渠道群

存储和芯片产品报价、行情、渠道、供应链




< 长按识别二维码添加好友 >

加入上述群聊




长按并关注

带你走进万物存储、万物智能、

万物互联信息革命新时代

微信号:SSDFans
SSDFans AI+IOT+闪存,万物存储、万物智能、万物互联的闪存2.0时代即将到来,你,准备好了吗?
评论
热门推荐
相关推荐
我要评论
0
0
点击右上角,分享到朋友圈 我知道啦
请使用浏览器分享功能 我知道啦