怎么在私有云语境下定义VPC

这篇文章将为大家详细讲解有关怎么在私有云语境下定义VPC，文章内容质量较高，因此小编分享给大家做个参考，希望大家阅读完这篇文章后对相关知识有一定的了解。

日前，ZStack推出了新一版网络架构 VPC 2.0，作为ZStack 2.3.0版本中的重磅功能，VPC 2.0 提供全面而强大的网络功能支持，包括：灵活的网络配置，安全可靠的逻辑隔离，以及开启分布式路由功能，优化东西向网络流量、不同子网之间不通过云路由器直接完成互联互通等高级策略，可满足丰富的网络场景实现。

VPC经过多年的市场教育和实践，大部分公有云用户已经接受了公有云中 VPC 是必不可少的基础组件。但是对于私有云和混合云领域来说，如何保障业务安全？如何充分利用云的潜力？是否还是沿用过去的虚拟化的设计经验，目前尚无定数。

ZStack在私有云和混合云技术和产品上又做了哪些尝试？VPC2.0是如何解决网络灵活性、扩展性业务需求的？如何在私有云语境下定义VPC？

Q1：VPC2.0在私有云和混合云建设中，解决什么样的问题和痛点，以及其最佳应用场景？

在ZStack VPC1.0里，其VPC的概念和设计主要来源于公有云对隔离性的设计，在现网接入、网络灵活性等诸多方面有所欠缺，在面向复杂的私有云、混合云场景不能完全满足我们的需求，因此ZStack对网络模型进行了大量改造，着重提高了灵活性、易用性和性能。

目前IaaS产品VPC大多来自公有云，着重于安全和隔离性，ZStack VPC 2.0在安全性和隔离性的基础上大量考虑了用户的实际使用场景、软硬结合的使用场景、利旧的场景等，在现有的VPC1.0基础上带来了功能丰富还易用的VPC2.0，它能够满足企业从几十台虚拟机的小规模应用到几万台虚拟机的大规模部署，并将完整对接混合云VPC，完成私有云VPC的一次全新定义。

Q2：VPC2.0 给用户带来的主要价值是？

• 灵活的网络配置

• 安全可靠的隔离

• 丰富的网络场景

• 更低的管理成本

• 更高的网络性能

Q3：VPC技术会朝着什么样的方向发展，下一步产品在网络方面会进行哪些优化？

下一步首先是在更加开放的网络功能上。我们希望能将网络功能做成一个平台开放出去，不只是有我们提供的网络服务，来自各家厂商的无论NFV、防火墙、监控等产品都能无缝接入到ZStack云平台之中，这样才能更进一步的提升效率、降低用户的使用、运维成本。目前OPNFV等组织、OpenDaylight等项目都做过一些工作，但距离可交付给用户还有相当的距离。

其次是更加的自动化。目前混合云开通、隧道建立不可避免的还存在一些手工的过程，这是目前用户需要等待多的步骤，也是最容易出错的步骤，将来我们希望能够通过引入例如 SDWAN等技术将这个过程更加高效化，并能够够细致、直观的展示给客户当前网络的状态、质量，能够让用户“傻瓜化”的进行查错、管理。

接下来，我们为您详细解读ZStack VPC 2.0设计思路与架构。

安全

当用户使用公有云时，其第一考虑的往往是安全。去年一年来不断的发生了各类安全事件，使得用户心生踌躇，这样的问题在私有云中是不存在的——从机柜到电源都完全在企业自己控制下，而且往往在出口部署了高昂的网络安全设备，相比将数据走在和别人共用的网线上，这一做法自然更好保证企业的专属网络和数据，但也给用户带来不小的运维成本。

所以如何在保证安全的前提下减少用户的安全运维成本是我们的第一个考量。要知道网络隔离和弹性计算天然是对立的——隔离的越细致，快速扩容、服务编排、资源回收往往越难，而且这个难度会随业务的数量指数增长。

以往我们可能认为出口部署防火墙足以抵挡一切攻击——如同在一片暴风雨中间设一个城堡，外墙越修越高，试图抵挡一切攻击。

但是实际上，随着 SaaS 服务的兴起、企业互联网以及介入企业内网的设备越来越多，这种设计越来越难以难以维系：

企业对外的数据和网络入口越来越多，比如网站、员工 VPN、购买的 SaaS 服务、对外的 API 服务、用于所开发的网站 App 或手机 App 而提供的数据通道，甚至员工自行连入的手机都可能存在安全隐患，这样企业需要设置的外墙越来越多也越来越高；

应用的爆发式增长，过去，一个应用的扩容可能是以月为单位甚至季度为单位计的，一次上架可能在数月内都足够支撑业务增长，而现在互联网的快速爆发下，应用一旦获得好评，可能会飞速传播，这样对计算能力扩容提出极高要求，而人为配合网络变更极易出错出漏；

数据的爆发式增长带来的混合云需求，与业务的增长并行的，是存储需求的增长，以及数据价值的不断提高，越来越多的企业对存储有更为丰富的需求——除了传统的 SAN、NAS，还有一些业务可能需要超高性能，一些业务需要对象存储，还有冷热分离，大量的日志存储等等要求。此时完全自购设备是很不划算的，对接公有云组成混合云无疑是哥可行选择，但对网络要求更复杂了。

在这种现状下，Google 提出了 BeyondCorp 的安全架构，其基本思想是：安全隔离不再基于 IP、MAC 而是应用、账户访问控制不再是静态的，而是动态的、自动跟随的限制业务间相互访问的权限甚至协议，但这种先进的安全架构如何应用到企业呢？私有云如何帮助客户完成这些安全目标呢？我们看一个 ZStack 架构下的网络设计。

二层隔离

对于所有网络隔离来说，隔离最彻底的，莫过于二层网络隔离，然而传统二层网络隔离基于 VLAN 或 802.1ad，前者可供使用的域少，而后者配置过于麻烦。还好 ZStack 从 2.0 就提供了 VXLAN 作为网络隔离技术。

与市面上大多数哦 IaaS 不同，ZStack 提供了极为灵活丰富的方法来配置 VXLAN 网络，ZStack 将 VXLAN 的 Underlay 网络 Overlay 网络记为 VXLAN Pool 和 VXLAN Network，前者用于加载到集群、加载 VNI Range 等等，并且在加载时可以选择 VTEP 的地址段，ZStack 就会自动寻找到合适的 VTEP 地址并加载。

每一个集群可以使用不同的 VTEP 地址段，管理员可以任意划定 VNI 范围，并将这个 Pool 共享给最终用户或部门的运维管理人员，再在之上创建 VXLAN 网络。整个过程高度自动化和灵活——甚至服务器上 VTEP 所需要的地址由于某些原因被修改，只需要在 ZStack 界面上重连物理机即可自动同步！

在生产实践中，可以将需要的业务单独部署 VXLAN，也可以将 VXLAN 划分给业务部门供其自由配置，保证其最底层的网络隔离——无论底层的 ARP 欺骗抑或高层的服务嗅探都不可能突破这一关卡。

自定义路由

从 ZStack 2.1 开始我们提供路自定义路由这一功能，这一功能咋看之下与安全毫无关系，实则不然。

首先，在公有云中公网往往比较好定义——一定就是 Internet，唯一区别是可能是电信网络或联通网络或 BGP 网络等等。而私有云则不然，私有云中内网一定是部署业务的网络而公网却不一定是 Internet，例如下图中的架构：

假设我们有两个 VPC 部署了三个业务，其中应用和数据库为了性能考虑放在了一个 VPC，而 Web 服务是一个公共服务在一个单独的 VPC 中，此时应用服务可以通过云路由，走自定义路由走到 VPC2，这里 VPC2 运用了我们的云路由支持多公网的功能，这一功能一定是和自定义路由相互配合使用的。

此外，如何保障数据库的安全？不被渗透或探测？安全组是一方面，另一方面为了防止探测流量和意外的路由导致数据库被外部发现，我们还可以在 ZStack 中指定黑洞路由：

这样可以彻底的保证数据库服务的地址段不会泄漏到 VPC 之外了。

考虑到复杂网络的路由复杂性，ZStack 还提供了 API 供管理员查看云路由中哪些路由条目正在生效，哪些路由条目虽然配置但实际上是不生效的。

基于源的安全组

传统安全组基于 IP、协议和端口，这样的安全组除了策略跟随（虚拟机任意漂移不影响其安全策略的生效）之外很难说比传统 ACL 有多少优势，与 zone based firewall 都略显单薄。

但是 ZStack 自 2.1 起提供了基于源的安全组，也就是安全组可以当作一个安全域来使用，ZStack 可以自动识别来自不同安全组的流量，从而做到灵活的访问控制而无需反复设置 IP 或网段，减少出错，提高效率。

如上图，我们可以针对源安全组来设置安全组规则，例如安全组 1 可以配置当源来自安全组 2 时开放哪些端口，来自安全组 3 时开放那些端口。

其他

此外，ZStack 还有其他很多安全技术例如源地址过滤以防止 IP、MAC 地址伪造，DHCP 服务器防伪造避免用户从错误的服务器上获取地址等等。通过这些技术的有效运用，管理员可以根据自己的需求和实际环境配置做够安全、可信的网络。

私有云和公有云不同，这些系统的设置和使用都是可以由用户自己配置和使用的，用户与此同时可以接入一些既有的安全设备例如 WAF、防火墙、流量清洗等等，可以参考下面的内容。

灵活

对于公有云，一切规则是由供应商决定的，供应商往往会根据自身的考虑或者技术的局限而定义这些规则，一方面会导致云上的网络使用和传统存在很多不同，一些管理操作带来不便，例如公有云的数据库带来了 scale 的方便，但也带来了调试的不便；另一方面容易形成对其资源的使用形成 all in，例如可能我们只想使用公有云上的数据库，但为此将业务虚拟机也只好迁到云上，随之而来的还要迁移存储系统、备份系统甚至一套相配套的内容，带来了很多不便。

而当我们设计一款私有云时，这一切都需要考虑，而不是以一句“客户需要设计 Cloud Native”的理由认为客户的需求不合理。特别是 ZStack 是一个产品化的私有云，产品会不断升级，既要添加新的功能和场景，又要兼容旧的设计和使用，甚至是用户不合理的使用。

ZStack VPC 2.0 在灵活性上带来了下面这些亮点：

多网络服务复用地址

对于中小型的私有云，一个常见需求是——公有网络的 IP 地址不够用，特别是这个共有网络是一个真的 Internet 上 IPv4 地址时。

ZStack 为用户提供了丰富的网络服务，包括但不限于弹性 IP、负载均衡、IPSec VPN、端口转发、SNAT 等等，而与此同时用户的 IP 地址却可能捉襟见肘，比如用户只有一个地址但既想要用 SNAT 开放虚拟机到公网的访问，又想用其作为 IPSec 的地址连接混合云。

这个需求在数据平面是可行的，但对云平台的控制平面却做出很大挑战，云平台要很好的协调每个服务对 IP 的需求，将其合理的配置到云路由上。从 ZStack 2.3.0 开始，我们支持了一个 IP 同时用在负载均衡、IPSec、端口转发、SNAT 等所有不要求独占 IP 的服务上！而且用户可以任意划定其端口的使用，从此将 VIP 从一个网络属性，彻底开放成为一个可以池化的资源，大大解放了私有云对 IP 的使用。

此外，考虑到每个服务使用不同的端口（SNAT 外），ZStack 里还可以对每个端口做不同的 QoS，达到既对 VIP 本身可以做 QoS，同时可以对不同服务做 QoS 的能力。

物理网络接入

在私有云中，既有设备或既有网络的接入同样是无法绕开的问题。一来企业要避免投资浪费，二来短时间内很多软件的实现在性能或功能上都无法与硬件相媲美，例如应用交付控制器 ADC、流量清洗设备等等。

为了解决物理设备的接入，ZStack 提供了多公网、自定义路由、多网卡、VXLAN 网关等多种方案。其中前两者前面有所介绍，多网卡很好理解。基于 VXLAN 网关的方案则是因为 ZStack 采用标准的 VXLAN 协议，因此其他使用 VXLAN 协议的网络设备理论上都可以与 ZStack 的 VTEP 协商构成同一个 VXLAN Underlay 网络，达到虚拟网络与物理网络混合的效果。

很多时候，云网技术会通过 DVR 来优化流量，造成伪造网关带来的一系列问题，从而造成运维复杂度上升甚至部分需求无法实现，这个问题在 ZStack 中是不存在的，具体将在下面分布式路由中介绍。

网络服务跟随

在很多云中，网络服务定义在 VPC 中，实现在云路由之上，这样云路由成为 VPC 的关键角色，公有云中往往避免直接暴露给用户云路由，而像私有云也往往将云路由的相关操作列为一个关键操作——用户不能随意删除或卸载，否则可能会导致网络服务的消失。

而 ZStack 中却有所不同，我们认为用户的网络服务创建是面向业务的，也是服务于业务的（特别是弹性 IP、端口转发等），此时如果我们想将虚拟机转移到另一个 VPC 或者删除掉云路由就丢失网络服务是不可取的。我们通过实现网络服务跟随，达到了，网络服务一旦创建，将跟随这个虚拟机而非云路由，如果这个云路由被删除，一旦重新创建或加载，所有网络服务将自动重新应用——这就像从此的 NAT 规则不再依赖一个实际的防火墙，而是直接于你的业务绑定，即使换一个防火墙、重建一个防火墙，系统总会尝试帮你恢复业务，达到资源的真正池化、无依赖、完全灵活。

如上图，虽然网络服务定义在云路由上，但最终其用于 VM2，所以 VM2 不消失，无论云路由发生什么变化，网络服务最终会应用在 VM2 上。

性能

虽然不像公有云那样单区域承载百万台甚至更多虚拟机，但私有云也并非没有性能要求，甚至随着用户的需求变化，我们需要能够适应用户从小到大的规模要求，小规模时不浪费额外资源，大规模时也要有方案与之应对。

特别是云路由接入多个子网后，其上的流量由于企业对东西向流量的需求可能会变得很大，如果一个云路由成为整个网络的性能瓶颈是不被用户接受的，除了单点问题之外，性能上的占用也很可观。

传统的网络协议将整个过程一般都定义为集中式的，例如 DHCP 服务器、例如路由网关，而且集中控制也带来实现上的便利性——特别是 SNAT、路由表这些服务，而一些服务我们发现它其实可以通过一些手段做分布式的优化，而且其重要性也值得我们去这样做，例如 DHCP 和网关。

分布式 DHCP

ZStack 从最早的 Flat 网络即支持了分布式 DHCP，但云路由网络是集中式的 DHCP，从 2.1 开始，我们开始将云路由网络 DHCP 改为分布式的设计，并继承到了 VPC 网络之中。

分布式路由

分布式路由是 ZStack VPC 2.0 中一个极为重点的功能。与业界一些 DVR 的实现对规模有限制甚至很脆弱难以应用到生产不同，ZStack VPC 2.0 在设计之初就经过了精心的考虑，因此它有着以下的特点：

无先验知识

无消息队列

无网关欺骗

无集中式控制器

即时开关

首先，无先验知识是指整个流量优化系统无需从 ZStack 数据库拉取信息。为什么这个很重要呢？因为 ZStack 设计原则里有很重要的一点，就是管控面与数据面的分离，管控面的故障不会扩散到数据面上，任何情况下优先保证用户业务的不受影响。

在这种设计原则下，我们自然不能去拉取 ZStack 数据库的信息——即使所有网络信息都记录在了 ZStack 数据库上，但一来不能保证数据库的永久不宕机，二来数据库的数据其实是不能真实的反应网络状态的，用户随时可能修改自己的 IP、创建虚拟网卡等等。

其次，无消息队列。OpenStack 中 DVR 的控制数据通过消息队列执行最终被认为是一个欠考虑的设计，因为消息队列既有着容量限制还存在自身的可靠性问题，因此 ZStack DVR 抛弃了消息队列，实现了一种私有协议为 ZSNP（ZStack Network Protocol），通过这个协议直接在 IP 层上传递消息，并实现了无需知道虚拟机所在 Host 的信息的前提下将信令直接投递到 Host 上所在 Agent 的功能。

第三，无网关欺骗。传统的 DVR 都是基于网关欺骗实现的，这种想法非常直接——既然我要做网关，那肯定要实现一个伪网关，与此同时带来的，就是防止网关泄漏、伪网关与真网关的判断等等一系列问题，而且很容易造成用户自定义的路由难以实现、物理设备不好接入。

而 ZStack 希望在做分布式路由时，一要可靠，二要尽量避免影响用户的使用习惯，因此实现了无网关欺骗的无状态流量优化，从而完整兼容过去的所有功能，用户也可以透明的享受分布式路由带来的好处。

第四是没有集中控制器。在传统的 DVR 设计中除了与 CMS 数据库交互外，还会往往有集中化控制器这一问题，那么一旦控制器失效，轻则无法优化流量，重则网络中断，也是用户所万万无法接受的。

在 ZStack VPC 中，流量优化由在云路由中的 Agent 发起，每个 Agent 只关心自己所在云路由上的流量，因此不存在系统单点，而且这样的 Agent 类似于一种旁挂机制而非直连，那么即使 Agent 挂掉，也不会导致网络失效。而是已优化流量会逐渐回退到传统集中式路径上。

最后，一个很有意思的功能是 ZStack VPC 的分布式路由可以由用户自行决定是否开启，而且通过前面原理的介绍我们可以知道这种开关是分布在每个云路由上的，用户可以选择部分云路由开启而部分关闭，而且这种开启即时生效，关闭也会在规则老化后彻底回退到传统路径。

此外 ZStack VPC 2.0 还有着大量潜力尚待挖掘——例如基于优化数据的网络连接探测、优化流量统计等等，将在未来的版本逐步推出。

关于怎么在私有云语境下定义VPC就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。