现有网络产品不能满足云计算的需求？举个栗子告诉你真相！

我们知道，在云中，包括计算、存储、网络在内的所有资源都被虚拟化了。

租户按照自己的需求在部署业务时申请各种资源、在运行过程中随时扩展或缩减对资源的需求、在业务结束后释放各种资源。

那么，云的运营者则需要为租户提供对各种资源申请、调整、释放的操作接口云计算需求，同时还要动态、灵活地将虚拟化的计算和存储资源通过虚拟化的网络连接起来。

因此，云对网络提出了新的需求。

我们以云中虚拟负载均衡系统（以下简称为“vLB”，Virtual Load Balancer）为例来观察和探讨这些新的需求。

一般来说，在云中，vLB有两种可能的部署方式：

1、集中式/集群化的硬件

2、分布式/虚拟化的软件

1

集中式/集群化 硬件的负载均衡系统

针对不同租户、不同业务的负载均衡服务是由集中式地部署在 UnderlayNetwork 世界中的硬件形态的专业负载均衡设备所提供的。（以下简称为“硬件vLB”）

图 1：集中式/集群化/硬件的负载均衡系统

如上图所示，在集群化部署的负载均衡系统上，云为不同租户的不同业务创建不同的 vLB，互联网针对不同业务VIP（VirtualIP，指业务系统集群对外提供的 IP 地址，如果这个业务系统是通过互联网可访问的， 那么这个 VIP 就是公网地址）的访问通过 Underlay Network 的三层转发抵达这些 vLB，vLB 终结对 VIP 的访问、按照一定的算法选择出后端提供业务的 VM 后，通过 VXLAN 隧道，再将这个访问请求送到被选中 的 VM。

需要强调的是，在这种部署模式中，负载均衡系统一般是专业厂家提供的专业设备，往往具备同时支持 4-7层的负载均衡服务的能力（如图中的 vLB-L4/7）。

但是，这样的负载均衡系统也往往是以黑盒的形式提供给云，因此云的管理也只能到 Overlay Network、Tenant、VPC这个维度，一般无法自动化地管理 vLB、Service。

2

分布式/虚拟化/软件的负载均衡系统

针对不同租户、不同业务的负载均衡服务是由分布式地部署在 Overlay Network 世界中的虚拟形态的负载均衡软件所提供的。（以下简称为“软件vLB”）

图 2：分布式/虚拟化/软件的负载均衡系统

如上图所示，云为不同租户的不同业务提供的vLB是以虚拟化、软件的形态存在于每个Service的“旁边“的。互联网针对不同业务VIP的访问通过Underlay Network 的三层转发抵达这些 vLB（更严格地说，应该 是“抵达这些vLB所在的物理服务器”），vLB终结对VIP的访问、按照一定的算法选择出后端提供业务的VM后，通过VXLAN隧道，再将这个访问请求送到被选中的VM。在这种部署模式中，虚拟化、软件的vLB一般源自于业界知名的开源软件，其4层和7层的负载均衡服务的能力往往是分开的（如LVS提供4层负载均衡能力、HAProxy和Nginx提供7层负载均衡能力），因此图中使用vLB-L4和vLB-L7 来区分这两种能力。因为这样的vLB是以开源、开放软件的形式提供给云的，因此云的自动化管理能够从OverlayNetwork、Tenant、VPC 一直延伸到vLB-L4、vLB-L7、Service等维度。

3

云对网络产品的新需求

通过以上的分析，不难看出，二者各有所长也各有所短：

硬件vLB：性能高、功能全面，可获得性很强，但是不灵活、难以自由调度，增加新的业务功能很困难，而且各家自成一套管理体系、彼此不同，很难被集成到云中统一管理；软件vLB：虽然解决了软件定义、按需弹性、统一管理等问题，但是因为对服务器算力的大量消耗和软件处理所有网络流量的本质，使得其成本和性能是硬伤，继而影响其可获得性。

分析到这里，我们可以轻而易举地总结出云对网络产品的需求：

?开放、灵活、弹性

?性能与成本兼得?应云而动、随需而变

在云计算时代，我们将满足这些新需求的网络产品称之为“开放网络产品”。事实上，这些新的需求对于 vLB 是如此，对于云中的其他功能性网元——虚拟交换机（Virtual Switch，vSwitch）、虚拟路由器（Virtual Router，vRouter）、虚拟地址转换网关（Virtual NAT，vNAT）、虚拟防火墙（VirtualFirewall，vFW）等——亦是如此。

（编辑：晋中站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!