本文不合适转载, 只用于自我学习
关于为什么要用 OpenStack 管理 vSphere 集群, 原因可以有很多, 特别是一些传统企业, VMware 的使用还是很普遍的, 用 OpenStack 纳管至少会带来管理上的便捷性
1. 部署架构
节点 | 网卡数 | 网卡用途 |
KVM 宿主机 | 4 | 10G:存储网络 10G:SDN 网络 1G:管理网络 1G: IPMI 网络 |
ESXi 宿主机 | 5 | HBA:存储网络 10G:SDN 网络 10G:vmKernel 网络 1G:管理网络 1G: IPMI 网络 |
说明:
vDS_tenant 其实更像一个 vSwitch, 数据层面只处理本宿主机上的流量, 再加上集群范围内的统一管理
vDS_SDN 需要跨宿主机通信, 因此需要绑定物理网卡
vmKernel 网络也需要支持跨宿主机通信, 因此也需要绑定物理网卡
另外还需要考虑物理网卡高可用, 因此还需要添加更多的网卡
2. 组件
2.1 cinder volume 的 vcdriver
使用: volume_driver=cinder.volume.drivers.vmware.vmdk.VMwareVcVmdkDriver
过程: cinder-volume 从 MQ 接收到请求后, 驱动 vcdriver 连接 vCenter 调用其 API 执行操作
功能: 支持的功能包括:
- Create, delete, attach, and detach volumes.
- Create, list, and delete volume snapshots.
- Create a volume from a snapshot.
- Copy an image to a volume.
- Copy a volume to an image.
- Clone a volume.
- Backup a volume.
- Restore backup to new or existing volume.
- Change the type of a volume.
- Extend a volume
2.2 nova-compute 的 vcdriver
我们使用 compute_driver = vmwareapi.ovsvapp_vc_driver.OVSvAppVCDriver, 其配置如下:
[vmware]
host_ip=<vCenter 的 IP 地址 >
- host_username=<vCenter admin username>
- host_password=<vCenter admin password>
- cluster_name=<vSphere Cluster name>
- datastore_regex=compute*
- wsdl_location=https://<host_ip>/sdk/vimService.wsdl
代码在 https://github.com/openstack/networking-vsphere/blob/master/networking_vsphere/nova/virt/vmwareapi/ovsvapp_vc_driver.py
2.3 镜像处理
我们没有使用 vsphere 作为 glance 的 backend store, 而是把镜像放在 ceph 之中
- glance image-show a88a0000-0000-42dd-9b5f-ee0fbf313cf1
- +------------------+----------------------------------------------------------------------------------+
- | Property | Value |
- +------------------+----------------------------------------------------------------------------------+
- | checksum | 0000000000000000000000000 |
- | container_format | bare |
- | created_at | 2016-07-19T01:15:33Z |
- | direct_url | rbd://6dc80000-2675-4f31-0000-b818f00d178c/pool-0/a88a0000-0000-42dd-9b5f- |
- | | ee1fbf313cf1/snap |
- | disk_format | vmdk |
- | hw_disk_bus | scsi |
- | hw_scsi_model | paraVirtual |
- | id | a88a0000-0000-42dd-9b5f-ee1fbf313cf1 |
- | img_hv_type | vmware |
- | min_disk | 0 |
- | min_ram | 0 |
- | name | debian.vmdk |
- | owner | 00000000000000000 |
- | protected | False |
- | size | 1073741824 |
- | status | active |
- | tags | [] |
- | updated_at | 2016-10-17T06:24:48Z |
- | virtual_size | None |
- | visibility | private |
- | vmware_disktype | eagerZeroedThick |
- +------------------+----------------------------------------------------------------------------------+
nova-compute 首先从分布式存储中下载镜像文件到本地, 然后 nova 的 vmware driver 会通过 HTTP 将镜像传送到 vSphere datastore 相关代码可参考 https://github.com/openstack/nova/blob/master/nova/virt/vmwareapi/vmops.py 这么做的好处是可以统一 KVM 和 VMware 镜像的管理方式, 但是会导致新镜像第一次创建虚机时间较长
3. 网络
我们采用 OVSvAPP 网络方案, 链接在这里 https://wiki.openstack.org/wiki/Neutron/Networking-vSphere 我们采用 VLAN 网络模式
3.1 架构
3.2 租户网络流向
3.2.1 场景示意图
红线: DVS1 中, OVSvAPP agent 会为每个 network 创建一个全局性 port group, 如图中 ESXi 节点 1 上的 Port Grp 7VM1 和 VM2 在同一个 vlan 中, 因此两者的通讯直接在 Port Grp 7 内进行
紫线: ESXi 2 上, VM2 和 VM3 在两个 vlan 上网络包从 VM2 出发, 首先经过 ESX2 上的 OVSvAPP 虚机, 再经过 vDS_SDN 出宿主机, 然后经过网络节点做路由交换, 再经过 vDS_SDN 返回 ESX2 上的 OVSvAPP 虚机, 再到达 VM3.
绿线: ESX1 上的 VM3 和 ESXi2 上的 VM2 在同一个 vlan 上, 但是分开在两个宿主机上两者的通讯需要经过 ESX1 上的 OVSvAPP 虚机, 再经过 vDS_SDN 分布式交换机, 再达到 ESX2 上的 OVSvAPP 虚机, 再达到 VM2.
黄线: ESXi1 上的 VM2 和 ESXi 2 上的 VM1 在不同的 vlan 上, 且分在两个宿主机上两者的通讯需要经过各自宿主机上的 OVSvAPP 虚机以及网络节点
3.2.2 br-int 的流表
- # 这是从端口 5(br-ens192) 也就是 dVS_SDN 进来的也就是从宿主机外面发过来的网络包, 到有物理的 vlan id 修改 vlan id 后, 发到端口 1 也就是到 br-sec 去, 再到 dVS_tenant
- n_packets=110820815, n_bytes=7396114366, idle_age=0, hard_age=65534, priority=4,in_port=5,dl_vlan=192 actions=mod_vlan_vid:3,output:1
- # 把从端口 1 也就是 br-sec 进来的包也就是虚机发出的包发到端口 5 也就是 br-ens192 也就是物理网卡
- n_packets=16326229471, n_bytes=26270964185221, idle_age=0, hard_age=65534, priority=4,in_port=1,dl_vlan=2 actions=output:5
其主要职责是把物理 vlan id (dl_vlan) 修改为内部的 vlan id, 然后再发到合适的端口
3.2.3 br-ens192 的流表
- hard_age=65534, priority=10,rarp,in_port=2 actions=NORMAL
- hard_age=65534, priority=4,in_port=2,dl_vlan=3 actions=mod_vlan_vid:192,output:1hard_age=65534, priority=4,in_port=2,dl_vlan=2 actions=mod_vlan_vid:160,output:1hard_age=65534, priority=4,in_port=2,dl_vlan=5 actions=mod_vlan_vid:224,output:1hard_age=65534, priority=4,in_port=2,dl_vlan=1 actions=mod_vlan_vid:208,output:1hard_age=65534, priority=4,in_port=2,dl_vlan=6 actions=mod_vlan_vid:176,output:1
- priority=0 actions=NORMAL
它负责把内部 vlan id 转换成物理 vlan id 再发到端口 1 也就是 SDN 网卡 ens192. 而从物理网卡 ens192 进来的则直接走到 br-int
3.2.4 br-sec 的流表
- dst=42002 actions=fin_timeout(idle_timeout=1),output:1hard_age=0, priority=20,tcp,vlan_tci=0x0002/0x0fff,nw_src=10.70.160.191,nw_dst=10.70.16.187,tp_src=50706,tp_dst=8086 actions=fin_timeout(idle_timeout=1),output:1hard_age=0, priority=20,tcp,vlan_tci=0x0002/0x0fff,nw_src=10.70.160.191,nw_dst=10.70.16.187,tp_src=50716,tp_dst=8086 actions=fin_timeout(idle_timeout=1),output:1hard_age=0, priority=20,tcp,vlan_tci=0x0002/0x0fff,nw_src=10.70.160.187,nw_dst=10.70.16.191,tp_src=8086,tp_dst=50706 actions=fin_timeout(idle_timeout=1),output:2hard_age=0, priority=20,tcp,vlan_tci=0x0002/0x0fff,nw_src=10.70.160.187,nw_dst=10.70.16.191,tp_src=8086,tp_dst=50716 actions=fin_timeout(idle_timeout=1),output:2hard_age=65534, priority=0 actions=drop
- hard_age=65534, priority=0 actions=drop
它的主要职责是作为安全组和防火墙 Neutron ovs agent 负责将安全组规则转换为 OVS 流表, 对进出虚机的网络包进行过滤
3.2.5 DRS 支持
VMware DRS 可以动态地将虚机在 ESX 节点之间迁移因此, 为了支持 DRS, 在每个 OVSvAPP 虚机之内, 流表都是一样的这样, 不管虚机迁移到哪里, 其网络都不会收到影响当然, 这也会造成流表过大这会导致 CPU 占用增加, 以及网络延迟加大
下图比较了不同数量级流表下的 OVSvAPP 虚机的 CPU 占用情况
3.3 VLAN 模式下虚机网卡的处理过程
这里面能看到运行在 OVSvAPP 虚机中的 neutron agent 驱动 vSphere 根据 port 的 vlan id 创建 Port Group 过程在创建好以后, Nova Compute Proxy 再把 port 绑定到虚机, 同时创建各种 bridge(br-int,br-sec,br-ex) 的流表为了实现这逻辑, 社区提供了 nova 的 OVSvAppVCDriver 驱动
3.4 网络性能
3.4.1 官方建议网络配置
DVS 的 Uplink 网卡以及 Trunk 口的 MTU 设置为 9000
OVSvAPP 虚机里面的 br-int, br-sec 和 br-ex 的 MTU 设置为 8900
虚机的 MTU 设置为 8900
ESX 的物理 uplink 网卡的 MTU 设置为 9000
3.4.2 OVSvAPP 方案对虚机的吞吐性能影响较小
3.4.3 但是对延迟影响还是蛮严重的, 毕竟网络路径大大延长了
3.5 VMware 虚机和 KVM 虚机通讯
4. 一些局限
OVSvAPP 方案是一个比较不错的方案, 包括:
支持 neutron, 支持 VLAN 和 VXLAN
支持安全组
支持 DRS
但是也存在一些局限, 包括但不限于:
增加了单点故障风险, 比如 OVSvAPP 虚机自身的单点故障, 以及 Proxy VM 的单点故障
网络路径太长, 造成网络延迟大大增加
OVSvAPP 内的流表数目会随着集群规模的增加而成倍增加一方面这会限制集群规模, 也会进一步增加网络延迟以及资源消耗
同一个 ESX 宿主机上的同一个网络之间的虚机之间没有安全组, 因为没有经过 OVSvAPP 虚机
参考链接:
https://wiki.openstack.org/wiki/Neutron/Networking-vSphere
来源: https://www.cnblogs.com/sammyliu/p/8422529.html