原本计划先写个有关京东云网络触感的基础版，但兴致所致就把关键内容前置了。
潭主今年的主要工作是云架构实践，最近在网络上拓展了不少边界。
本文通过一个相对复杂的云场景实验来跟大家汇报一下近期学习成果，顺便探索一下应用异地双活。
应用异地双活是个伪命题？
早年间，潭主负责系统运维时曾做过一些关于应用异地双活的实践，可以看成是关于业务连续性的探索。
受限于当时的资源，虽说项目有了个好起点，只是后来没有后来了。
不过设计思想延续了下来，最近搞云项目，潭主不由自主就产生了一种路径依赖。
实验环境：京东云，主要涉及两部分网络内容。
私有网络中的VPC和子网
混合云连接中的边界网关和VPN
实验目标：
跨地域多Region的大型网络环境中实现VPC远程互联
实验步骤：
在不同Region内创建VPC和子网
创建边界网关和VPC接口
创建VPN客户网关和VPN连接
跨Region的VPC间的路由打通
Step 1：在不同Region内创建VPC和子网
这部分内容相对较基础，实战中重点是网络规划和设计，配图只展示了单Region。
Step 2：创建边界网关和VPC接口
边界网关（BGW，Border Gateway），是云平台承载VPC南北向流量的一种网关，主要用于与VPC或企业IDC等其它环境进行内网互通，平面图上总觉得是东西流量。
为避免内网地址冲突，本端VPC网段与对端跨地域的VPC网段不重叠。
2.1 创建边界网关
创建边界网关只需要指定边界网关的名称，BGW支持BGP路由协议，京东云的BGP ASN固定为65000。
2.1 创建VPC接口
潭主觉得VPC接口就是将对应的VPC和子网路由绑定到指定的边界网关上。
在设计上边界网关跟VPC是一对多的关系，即一个边界网关可以路由到多个VPC，每个VPC可以有一个VPC接口，并在VPC接口内指定相关的子网。
潭主觉得一个Region绑一个BGW最简单。
VPC接口创建后，被选择的子网将自动添加到该边界网关的传播路由表中，下一跳指向此步骤创建的VPC接口。
Step 3：创建VPN客户网关和VPN连接
客户网关(CGW，Customer Gateway)，是VPN连接中客户端设备在云端的逻辑表示。
3.1 创建VPN客户网关
创建VPN客户网关需要指定地域、客户网关名称和BPG ASN，使用默认65001即可，这里的ASN要与之前的BGW边界网关中的ASN不同。
对于VPN模式，建议选择客户端双IP机制。
实际创建过程中可以先随意输入两个公网IP。真IP会在随后对端创建VPN连接时由系统自动生成，需要再回过头来对本端CGW配置进行更新。
3.2 创建VPN连接
VPN连接将基于边界网关和客户网关进行创建。
创建成功后，系统会自动生成一对可用的公网IP，按前文所述，需要用这对IP更新替换之前远端VPN客户网关创建时临时指定的Client IP。
3.3 添加VPN连接隧道
这个步骤比较麻烦，共享密钥自己设置个字符串就行，主要是VPN客户网关的公网IP和远端VPN连接公网IP的配对，京东云的规则是其对应的关系是IP小号与IP小号配一对，大号与大号配一对。
隧道IP可以自己定义，建议采用京东提供的默认网段，根据规则做相应修改。
Step 4：跨Region的VPC间路由打通
相关路由的设置分成两部分：
一部分是Step 2中创建VPC接口时系统会自动将子网的路由信息更新到边界网关的路由表上。
另一部分就是在边界网关中指定下一跳是VPN连接的路由。
4.1 在边界网关上添加VPN连接路由
在边界网关的静态路由表中手工添加去往目标VPC的静态路由，目的端为远端VPC对应的网段，下一跳类型为VPN连接，之后选择之前创建的对应VPN连接即可。
添加完相关路由信息后，可以在边界网关的有效路由表看到相关路由，既有下一跳是VPC接口的动态路由，也有刚刚配置的下一跳为VPN连接的静态路由。
4.2 检查VPN连接的隧道状态
配置成功后在VPN的【VPN连接】详细信息中观察隧道状态，正常的隧道管理和运行状态都应该是UP。
注意：最初添加隧道时运行状态是DOWN，状态从DOWN到UP需要一个时间周期，如果较长时间为状态为DOWN，可能是之前配置出了问题，需要重新检查。
状态都UP后，连接到北京和上海对应子网的VM上进行ping测试。
京东云网络的微观体感
受限于POC环境，没有实际的专线用于测试。
潭主只好在京东云上通过VPN连接实现跨Region的VPC资源互通。
虽然VPN和专线在实现细节上有差异，但潭主觉得VPN可以模拟专线的操作流程，不影响实验效果。
此次实验增加了潭主对京东云网络的微观体感，虽说过程有些繁琐，但让潭主重新思考了多租户规划设计的问题。
多租户这个概念源自云，不过公有云的各个租户独立管理，运维工作量是分散的。
不过从潭主这次的实验体感看，租户管理和配置的复杂度较高，而这仅是冰山一角，结合专有云建设，实施和运维的工作量会跟租户的数量成正比。
显然，这种多租户方案对于统一运维模式不够友好。
我们为什么要搞多租户？是思维定式，还是为了隔离风险，又或是为了计费方便，目前没有明确答案，只能在后面测试中尝试找到平衡。
没想到，潭主刚刚一出手就把自己之前规划的方案给推翻了。
跨界搞网络，很多事情不专业，截屏和描述也不够详尽，权当学习备忘，请大家多担待，也欢迎有兴趣的读者交流。
上一次写实操类技术文章还是MSN和Blog时代的事，现在新项目测试可以为潭主的公众号提供不少素材，但对潭主来说难得不是内容，而是时效。
最后，特别感谢京东云小伙伴儿提供的技术和环境支持。
- END -
感谢阅读。如果觉得写得还不错，就请点个赞或“在看”吧。
公众号所有文章仅代表个人观点，与供职单位无关。
