本帖最后由 eying 于 2016-1-13 16:50 编辑
问题导读:
1.OpenStack 内部网络有哪些?
2.虚拟二层网络有哪几种实现方法? 3.Neutron 租户网络是怎样隔离的?
3. Neutron中的网络连通性 如上面第二章节所述,一个标准 OpenStack 环境中的物理网络配置往往包括:
- Internet(Pulic network):传统意义上的公共网络,使用往往由电信运营商提供的公共IP。
- 外部网络(External network):数据中心 Intranet,从这里分配浮动IP地址。
- OpenStack 内部网络:
- 管理网络(management network):提供 OpenStack 各个组件之间的内部通信,以及 API 访问端点(Endpoint)。为安全考虑,该网络必须限制在数据中心之内。
- API 网络:其实这不是一个单独的网络,而是包含在外部和内部网络中。API 的 Endpoint 包括 publicurl 和 internalurl,其中,publicurl 包含的是 externa network 的 IP 地址,internal network 包含的是 management network IP 地址。为了简单起见,提供给内外网络访问的API的 publicurl 和 internalurl 相同,而只给内部网络访问的 API 只使用 internalurl。
- 数据网络(data network):除管理网络以外的其它网络,往往还可以细分为下面几种。它们可以合为一种,也可以从性能方面考虑分离出一种或几种作为单独的网络。
- 租户网络(Tenant network):提供虚机在计算节点之间,以及计算节点和网络节点之间的通信。同样这也是数据中心的内部网络。
- 存储访问网络(storage access network):访问存储的网络。
- 存储后端网络(storage backend network):比如 Ceph 和 Swift 集群用于后端数据复制的网络。
- 除了以上网络外,往往还有各种功能网络,包括 IPMI 网络,PXE 网络,监控网络等等。这部分就略去不谈了。
这几种网络,在物理交换机上,往往都使用 VLAN 来做网络隔离。现在讨论的只是租户网络即虚机之间通信的网络,在 Neutron 的实现看来,该网络的连通性包括几个层次:
- 同主机和不同主机上一个网段内的虚机之间的连接性:虚拟二层网络,走物理二层(VLAN)或者三层(GRE/VxLAN)网络。
- 不同网段内的虚机之间的连通性:经过物理(VLAN)或者 Neutron Virtual router
- 虚机和外部网络之间的连通性:经过物理路由器(给 VLAN 虚拟网络实用的物理交换机连接的路由器)或者 Neutron Virtual router
为了支持这些网络连通性,Neutron 需要实现跨主机的二层网络和虚拟路由器。可以参考 学习OpenStack之(5):在Mac上部署Juno版本OpenStack 四节点环境。
3.1 虚拟二层网络的实现 所谓虚拟二层网络,就是提供给虚机的一种虚拟网络,使得虚机可以和同网段中的其它虚机就像在物理二层网络一样在网络二层直接通信,不管目的虚机处于什么物理位置。也就是说,对虚机来说,物理三层网络对它是透明的。
3.1.1 使用 VLAN 实现虚拟二层网络
这种实现方式基于物理网络上的使用 VLAN 的交换机。请参考 (2)Neutron OpenvSwitch + VLAN 虚拟网络。
3.1.2 基于 GRE/VxLAN 实现的二层网络 (L2) 除了 VLAN 方式的物理的二层网络,另一种方式使用Tunnel/Overlay 方式实现虚机二层网络。那Overlay如何应对云计算网络的挑战呢?
(1)首先,Overlay的核心是重新构建一个逻辑网络平面,其技术手段的关键是采用隧道技术实现L2oIP的封装。通过隧道实现各虚拟机之间的二层直连。这样网络只看见Overlay边缘节点的MAC地址,物理网络学习到的MAC表项非常有限,现有接入交换机32K的MAC表项足以满足需求(如下图所示)。对应的Overlay边缘节点实现基于会话的地址学习机制,也就是说只学习有交互流量的虚拟机MAC地址。这样也严格限制了边缘节点的地址表项。
Overlay网络如何应对云计算网络的挑战
(2)其次,Overlay网络仅仅是一个逻辑上的二层直连网络。其依赖的物理网络,是一个传统的路由网络。这个路由网络是一个三层到边缘的网络。也就是说二层广播域被缩小到极致。这样,网络风暴潜在的风险大幅度降低。同时,对于一些需要依赖二层广播的协议报文,例如:ARP报文,Overlay网络通过ARP代理等方式实现协议的内容透传,不会影响协议报文的正常运作。
(3)再次,针对4K VLAN上限问题,Overlay网络通过L2oIP的封装字段,提供24bits长度的隔离ID,最大可以支持16M租户或业务。
(4)最后,针对网络虚拟化问题。Overlay网络本身就是一个从物理网络中抽离的逻辑网络,通过名址分离使得内层IP地址完全作为一个寻址标签,不再具备路由功能,可以实现不同subnet之间二层互通,保证二层网络的连通性不受IP地址段的限制。 (资料来源)
在 Neutron 中,Neutron 将虚机发出的数据帧打包,走三层物理网络到达目的虚机的主机,解包给虚机。这种实现使得两个虚机的通信看起来是二层网络通信。
请参考:(3)Neutron OpenvSwitch + GRE/VxLAN 虚拟网络
3.2 虚拟路由器 (virtual router) 跨子网的通信需要走虚拟路由器。同物理路由器一样,虚拟路由器由租户创建,拥有多个 virtual interface,连接一个租户的子网,以及外部网络。它具有以下特性:
- 一个 VR 只属于创建它的租户,只用于该租户的子网之间和子网与外网的路由
- 同一网络内的若干子网可以挂在一个 VR 上
- 同一租户的不同网络的没有 IP 地址重叠的子网可以挂在一个 VR 上
- 不同租户之间的内网之间是不能使用 VR 的
- 同一租户的不同网络内的有 IP 地址重叠的两个子网不能使用同一个 VR(添加子网到 VR 时会报错)
- 在网络节点上,一个 VR 运行在一个 Network namespace 内,该namespace 的名称包含该 VR 的 UUID
具体会在后面的文章中分析。
请参考:(6)Neutron L3 Agent
3.3 DHCP 服务 DHCP 服务是网络环境中必须有的。Neutron 提供基于 Dnamasq 实现的虚机 DHCP 服务,向租户网络内的虚机动态分配固定 IP 地址。它具有以下特性:
- 一个网络可以有多个运行在不同物理网络节点上的 DHCP Agent,同时向网络内的虚机提供服务
- 一个 DHCP Agent 只属于一个网络,在网络节点上运行在一个 network namespace 内
- 网络内的子网共享该 DHCP Agent
具体请参考 (5)Neutron DHCP Agent。
4. Neutron 租户网络的隔离性(isolation of tenant network) Neutron 实现了不同层次的租户网络隔离性:
- 租户之间的网络是三层隔离的,连通过 VR 做路由都不行,实在要连通的话,需要走物理网络
- 一个租户内的不同网络之间二层隔离的,需要通过 VR 做三层连通
- 一个网络内的不同子网也是二层隔离的,需要通过 VR 做三层连通
对一个租户的不同网络,Neutron 给每一个网络(network)产生的流量(traffic)在二层或者三层分配一个唯一的 segmentation_id,使得同一网络内的两个虚机之间好像建立了一个虚机的通道(tunnel)一样,而不同网络的tunnel之间是互相隔离的。根据物理实现不同,该ID被实现为:
- VLAN ID
- GRE Tunnel ID
- VxLAN VNI
以下图描述的 GRE 类型的网络为例:
- (1)计算节点的 br-int 上,neutron 为每个虚机连接 OVS 的 access port 分配了内部的 VLAN Tag。这种 tag 限制了网络流量只能在 tenant network 之内。
- (2)计算节点的 br-tun 上,neutron 将内部的 VLAN Tag 转化为 GRE Tunnel ID,是的不同 network 的流量走不通的 tunnel。
- (3)网络节点的 br-tun 上,neutron 将 GRE Tunnel ID 转发了一一对应的 内部 VLAN Tag,使得网络流被不同的服务处理。
- (4)网络节点的 br-int 上连接的 DHCP 和 L3 agent 使用 Linux network namespace 进行隔离。
请参考: (2)Neutron OpenvSwitch + VLAN 虚拟网络 (3)Neutron OpenvSwitch + GRE/VxLAN 虚拟网络
5. Neutron 租户网络的安全性(security)除了租户的隔离性以外,
- Neutron 还提供数据网络与外部网络的隔离性。默认情况下,所有虚机通往外网的流量全部走网络节点上的 L3 agent。在这里,内部的固定 IP 被转化为外部的浮动 IP 地址。这种做法一方面保证了网络包能够回来,另一方面也隐藏了内部的 IP 地址。
- Neutron 还是用 Linux iptables 特性,实现其 Security Group 特性,从而保证访问虚机的安全性。
- Neutorn 利用网络控制节点上的 network namespace 中的 iptables,实现了进出租户网络的网络包防火墙,从而保证了进出租户网络的安全性。
请参考下面的文章:
(8)Neutron Security Group (9)Neutron FWaas 和 Nova Security Group
6. Neutron 租户网络的可用性(HA)和扩展性(Scalability)OpenStack 云中可能用于成千上万台虚机,成千上万个租户,因此,Neutron 的数据网络的可用性和扩展性非常重要。Neutron 中,这些特性包括几个层次:
(1)软件架构上,Neutron 实现OpenStack 标准的去中心化架构和插件机制,有效地保证了其扩展性。
(2)Neutron 为每个 provider/tenant network 分配一个唯一的 segmentation_id。该 ID 的数目是影响可扩展性的因素之一。在规模不大的私有云中,往往是用 VLAN 模式,简单、可靠、能够满足规模要求;而在大型的私有云或者公有云中,往往使用 VxLAN。
网络类型 | ID 数目 | 说明 | flat | 1 | 通常不用于数据网络,因为其不具备租户隔离型。 | vlan | 4094 | 802.1Q 定义了 VLAN ID 占 12-bit | GRE | 16777216 | RFC 2637 定义的 GRE 的 ID 占 24-bit | VxLAN | 16777216 | RFC 7348 定义的 VxLAN 的 ID 占 24-bit |
(3)分布式 Virtual Router (DVR) 和 分布式 DHCP agent
默认情况下,L3 agent 和 DHCP agent 部署在网络节点上,这在大规模的云环境中可能会存在性能问题。这是 Blueprint。
(图16,使用了DVR-分布式虚拟路由器。来源。)
通过使用 DVR,L3 转发和 NAT 会被分布在计算节点上,这使得计算节点变成了网络节点,这样集中式的网络节点的负载就被分担了。这个 Blueprint 实现了分布式的 DHCP Agent,这进一步释放了集中式网络节点的压力。
(4)L2 Population 和 ARP Responder:这两个功能大大减少了网络的复杂性,提交了网络效率,从而促进了扩展性。
(5)高可用:虽然 Neutron 在高可用实现方面走在了 OpenStack 所有组件的前列,目前已经实现了多种 L3 Agent 的 HA 方案,但是,这些方案目前还不是很成熟,大都是在 Juno 版本中添加的,而且现在还在持续优化中,离正式进入生产环境还有一些距离。但是,我们可以相信,再经过两三个版本,这些功能就能够进入生产环境。
请参考这个文章: (4)Neutron OVS OpenFlow 流表 和 L2 Population (11)Neutron DVR (12)Neutron VRRP (13)High Availability (HA)
7. Neutron 扩展服务(extension service) 在实际的网络中,除了网络的核心功能以外,还有一些普遍应用的网络服务,比如 VPN, Load Balancing 和 Firewall 等。Neutron 针对这些普遍的服务,也提供了参考实现。需要注意的是,目前这些实现更多类似于一种原型实现(PoC),其目的是向给产品实现者提供一种参考架构,因此,这些功能往往还不能直接应用到生产系统。正是考虑到这些特点,目前 Neutron 项目组将这些代码挪出了 Neutorn 的主代码库。
具体请参考: (7)Neutron LBaas (9)Neutron FWaas 和 Nova Security Group (10)Neutron VPNaas
8. Neutron REST API Neutron 的 neutron-server 模块提供 REST API 来操作上文提到的各种网络组件,包括 network,subnet,port,router 等。可参考上图13。具体的 API 可以参考 这里和这里。
|