写点什么

构建健壮的混合云网络——BJS DX+VPN 篇

  • 2019-11-19
  • 本文字数:4502 字

    阅读完需:约 15 分钟

构建健壮的混合云网络——BJS DX+VPN篇

背景介绍:


近年来,随着公有云的普及,一方面,越来越多的用户选择利用公有云在弹性、灵活性等方面的优势,在云上部署新的应用系统,另一方面,大量的企业有很多现有的本地基础设施投资,所以企业上云的过程并不是一触而就的,期间势必存在云应用与本地数据中心应用并存的局面,为了更好的融合云与本地数据中心的应用环境,实现整体应用系统的稳定性和高可用性,构建一个健壮的混合云网络至关重要。


在 AWS 上,用来连接 AWS 与本地数据中心的方式主要有以下 3 种:


  1. 纯 VPN 组网

  2. 纯专线组网

  3. VPN 与专线的混合组网


其中,对于 AWS 中国区来讲,由于 AWS 自身的 VPN 服务 VGW 目前尚未落地,客户急需要一个替代方案,能够达到类似于 VGW 的冗余及故障切换功能。


本篇主要讲述第三种组网方式,着眼点在于如何实现混合云网络的健壮性及故障自愈。


此外笔者始终认为“Network is not just ping success”,尤其对于大型企业来说,网络流量的监控,故障事件的告警,日志的搜集检索等功能并非可选项,所以本篇也会顺带介绍如何在 AWS 云上实现这些功能。


对于第一,第二种组网方式的高可用实现,请参考:


《构建健壮的混合云网络——BJS VPN 篇》


《构建健壮的混合云网络——BJS DX 篇》


注意:本篇以 AWS 中国区 VGW 尚未落地为前提,VPN 部分以开源软件实现,但应用场景并不仅限于 AWS 中国区,如何客户需要一些 VGW 暂时无法满足的功能,同样可以在 AWS Global 利用本篇搭建符合自身需求的解决方案,具体可能的需求包括但不限于:


  1. 需要使用 VGW 暂时不支持的加解密算法

  2. 需要使用 VGW 暂时不支持的 hash 算法

  3. 需要使用证书认证

  4. All in one 解决方案,VPN 设备除了提供 VPN 功能外,还需要提供防火墙,NAT 等功能


拓扑图:



对于 DX 与 VPN 互备的场景,有如下几种情况:


  1. 1 条 DX+1 条 VPN

  2. 2 条 DX+1 条 VPN

  3. 1 条 DX+2 条 VPN

  4. 2 条 DX+2 条 VPN


对于 1,2 两种场景下,可以简单地通过调整 Private-1,Private-2 的路由表实现 AWS 侧的主备,即:流量优先选择 DX 专线,在专线故障时切换到 VPN 链路。


启用路由传递,路由表中会出现一条 10.10.0.0/16,target 为 VGW 的路由



设置一条静态路由 10.0.0.0/8,target 为 VPN 设备的 eni



由于路由最长匹配的原则,默认去往本地站点 10.10.0.0/16 的流量会通过 VGW 走专线,当专线发生故障的时候,10.10.0.0/16 的路由不会传递进入路由表,此时 10.0.0.0/8 的路由生效,流量切换到 VPN 链路。


对于 3,4 两种场景下,无法通过上述方式在两条 VPN 链路之间切换,需要部署拓扑图中的 monitor 设备来监控 DX 和 VPN 链路及 VPN 设备的健康状态并实现链路切换。


本例主要介绍 monitor 及 Strongswan 设备上的脚本功能,及如何与监控,告警相结合。


VPC 基本配置,DX 基本配置,Strongswan 配置及本地站点切换方式请参考:


《构建健壮的混合云网络——BJS VPN 篇》


《构建健壮的混合云网络——BJS DX 篇》


  1. 链路切换逻辑:



当专线链路正常时,设置服务器的路由指向 VGW,流量通过专线传输,当监测到专线故障时,将服务器路由指向相同 AZ 中的 Strongswan,并且开始监测 Strongswan 实例及 VPN 链路的健康状态,当一条 VPN 链路发生故障时,切换相应流量跨 AZ 传输给另一个 AZ 中的 Strongswan,当其中一个 AZ 的 Strongswan 发送故障时,切换流量的同时,通过 stop/start 该 Strongswan 恢复实例。


  1. 除了链路切换功能外,通过 monitor 及 Strongswan 上运行脚本能实现故障告警,VPN 流量统计及事件日志收集检索功能:



SNS 邮件及短信告警:




CloudWatch 针对 VPN 流量监控:



Elasticsearch & Kibana 做事件日志收集及检索:



可以针对 site,dx,vpn 做检索:





所有脚本可以从如下的 github 上下载得到:



  1. 脚本功能说明:


3.1 monitor 实例上运行的脚本:


monitor.sh:


  1. 实现 DX 链路,VPN 链路及 VPN 设备的健康检测并修改服务器路由切换流量

  2. 发现故障后,产生告警通知,通过 SNS 服务邮件及短信通知相关运维人员

  3. 本地产生故障日志,通过 logstash 输出到 Elasticsearch 服务存储


注:SNS 短信通知目前 BJS 暂不支持,Elasticsearch & Kibana 服务在 BJS 需要自己搭建


monitor 实例需要对路由表做操作,并与 SNS 服务交互,所以需要赋予相关的角色



其中,monitor policy 的配置如下:


{


"Version": "2012-10-17",


"Statement": [


{


"Action": [


"ec2:DescribeInstances",


"ec2:CreateRoute",


"ec2:ReplaceRoute",


"ec2:StartInstances",


"ec2:StopInstances"


],


"Effect": "Allow",


"Resource": "*"


}


]


}


3.2 Strongswan 实例上运行的脚本:


tunnel_init.sh:创建 tunnel 接口及路由相关流量到 tunnel 口


traffic_monitor.sh:收集进出 tunnel 口的 VPN 流量统计信息,通过自定义 metric 发送到 CloudWatch 中,实现 VPN 流量的监控


ipsec.conf/ipsec.secrets 配置文件:Strongswan 配置文件,建立 ipsec vpn 隧道


Strongswan 实例需要收集 VPN 流量信息并与 CloudWatch 交互,所以需要赋予相关的角色



  1. 脚本使用方法:


monitor.sh:运行在 monitor 实例上,monitor 实例需要拥有操控路由表,SNS 等


monitor.sh 的如下脚本语句需要做相应的修改


VPN_ID1="i-0e1466e8a5dd4892c"


VPN_ID2="i-0430fe110cdec5835"


VGW_ID="vgw-078bcc55"


VPN_RT_ID1="rtb-468f5222"


VPN_RT_ID2="rtb-4b8f522f"


DX_IP="10.10.3.100"


Remote_IP1="169.254.100.1"


Remote_IP2="169.254.200.1"


logstash_site="Singapore"


litterbin=$(aws sns publish --region ap-southeast-1 --topic-arn "arn:aws:sns:ap-southeast-1:93870664XXXX:DCI-Status" --subject "Status of DCI between Singapore and Ireland Changed!" --message file://logfile)


litterbin=$(aws sns publish --region ap-southeast-1 --phone-number "+861860135XXXX" --message file://logfile)


其中 VPN_ID1,VPN_ID2 分别为 Strongswan-1,Strongswan-2 的 instance id,VGW_ID 为 VGW 的 id,VPN_RT_ID1,VPN_RT_ID2 分别为 Private-1,Private-2 关联的路由表 id,DX_IP 为 DX 链路的检测 ip,通常为专线提供商 MPLS VPN 网络的 PE 设备或者是本地站点的出口路由器公网 ip,Remote_IP1,Remote_IP2 分别为本地站点两条 VPN 的隧道口 ip,logstash_site 为 AWS 站点标示,该值会体现在告警及日志中,用于区分多个 AWS 站点。


–region,–topic-arn,–phone-number 根据需要修改,其中 SNS 的 topic 需要事先创建并且通过相关邮箱订阅来接收消息。


所有事件日志会先写入本地/tmp/logstash.txt 文件中,通过 logstash 上传给 elasticsearch。


修改/etc/logstash/conf.d/logstash.conf


input {


file {


path => "/tmp/logstash.txt"


codec => json


}


}


output {


elasticsearch {


hosts => "http://search-test-cfwkwatg5unnpsgvbd5lyruquy.ap-southeast-1.es.amazonaws.com"


index => "XXXX"


}


}


可以设置/etc/rc.d/rc.local 文件,使 monitor 实例开机运行 monitor.sh 脚本


vpn_monitor.sh:运行在 Strongswan 实例上,创建 VPN 隧道接口及相关路由


traffic_monitor.sh:运行在 Strongswan 实例上,收集隧道接口的流量信息并以自定义 metric 的方式传输给 CloudWatch 服务


可以设置/etc/rc.d/rc.local 文件,使 Strongswan 实例开机运行 vpn_monitor.sh 和 traffic_monitor 脚本


作者介绍:


余骏


亚马逊 AWS 解决方案架构师,负责基于 AWS 的云计算方案架构的咨询和设计,同时致力于 AWS 云服务在国内的应用和推广。在加入 AWS 之前,在思科中国担任系统工程师,负责方案咨询和架构设计,在企业私有云和基础网络方面有丰富经验。


本文转载自 AWS 技术博客。


原文链接:


https://amazonaws-china.com/cn/blogs/china/hybrid-bjs-dx-vpn/


2019-11-19 08:00873

评论

发布
暂无评论
发现更多内容

架构师训练营第一章作业一:就餐管理系统UML图

zenfery

极客大学架构师训练营

Python 之父为什么嫌弃 lambda 匿名函数?

Python猫

Python 学习 编程

架构师训练营第一期作业

sean

第1周内容总结

paul

架构师训练营 - week1 - 食堂就餐系统设计

month

极客大学架构师训练营

架构师训练营第1期-Week1-食堂就餐卡系统设计

鲁大江

极客大学架构师训练营 食堂就餐卡系统设计

第一周总结

积极&丧

为什么开发工程师要架构图

Bear

极客大学架构师训练营

「架构师训练营第 1 期」第一周作业

张国荣

极客大学架构师训练营

食堂就餐卡系统设计

积极&丧

架构师训练营第1周课后练习

叶纪想

极客大学架构师训练营

第一周课后练习 - 作业 1

致星海

第一周课后练习 - 作业2

致星海

第一周学习笔记及uml设计

橘子皮嚼着不脆

架构师训练营第1期-Week1 架构方法学习总结

鲁大江

软件工程 极客大学架构师训练营 UML 架构方法

架构训练营1期-第1周练习

balsamspear

极客大学架构师训练营 第一周命题作业

架构师一期二班-吴水金-第一课总结

吴水金

学习

作业-食堂就餐卡系统设计

solike

极客大学架构师训练营

第一周作业

kevin

极客大学架构师训练营

第一周作业

极客大学架构师训练营

第10周总结

纯纯

week1总结

willson

架构师训练营作业:第一周

m

【架构师训练营】第一周作业:画图

MindController

架构师

架构师训练营第一章作业二 - 学习总结

zenfery

极客大学架构师训练营

week12--课后作业

Geek_165f3d

架构师训练营第 1 期-week1-食堂就餐卡系统设计

习习

架构师第一期作业2

sean

第一周学习总结

kevin

架构师训练营第一周学习笔记

一马行千里

学习 极客大学架构师训练营

架构师训练营第一周心得

CmHuang

构建健壮的混合云网络——BJS DX+VPN篇_语言 & 开发_亚马逊云科技 (Amazon Web Services)_InfoQ精选文章