VLAN 模式下的 OpenStack 管理 vSphere 集群方案

本文轉載自查看原文 2018-02-07 11:44 2841 VMware/ OpenStack/ 原理

關於為什么要用OpenStack 管理 vSphere 集群，原因可以有很多，特別是一些傳統企業中 VMware 的使用還是很普遍的，用 OpenStack 納管至少會帶來存量VMware環境管理上的便捷性。

1. 部署架構

1.1 vSphere 網絡的有關概念

vSphere DVS的架構圖：

VMware 在發布 vSphere 4.0時推出了 vSphere Distributed Switch。與 vSphere 傳統交換機 vSphere Standard Switch (VSS) 相比，VDS 擴展了虛擬網絡的特性和功能，同時簡化了資源調配以及日常的配置、監控和管理過程。VDS將網絡作為一個聚合資源進行處理，減輕了針對每個主機級虛擬交換機配置進行管理的負擔。各個主機級別的虛擬交換機被抽象處理成一個大型的 VDS，此 VDS 跨數據中心級別的多個主機。在此設計中，數據板保持在每個 VDS 的本地，但管理板采用集中機制，將 vCenter Server 作為所有已配置的 VDS 實例的控制點。

VDS 可以划分為兩個邏輯部分，分別是數據面板和管理面板。數據面板執行實際的數據包交換、篩選、標記等。管理面板是一個控制結構，供操作員用來配置數據板的功能。而在VSS中每一個標准交換機上都有數據板和管理板。

使用VDS 后，每個 ESXi 主機上的虛擬交換機都會被抽象為一個大的池子。每個 VDS 交換機可以跨一個數據中心之內的多台ESXi 主機。每個 vCenter server 可以管理多大128 個 VDS，每個VDS 最多可以添加到 500 台ESXi 主機上。

幾個概念的說明：

DVS：vSphere 分布式虛擬交換機，如上圖中的 vDS_Tanent 和 vDS_SDN。
PortGroup：端口組。端口組存在於DVS之上，連接到DVS的端口都存在於PG中。
Port：端口。外部設備通過端口連接到DVS。典型地，包括上聯端口，與物理網卡連接，如圖中的10G網卡；連接虛機的端口（上圖中業務虛機通過端口連接到vDS_Tanent，OVSvAPP虛機通過端口連接到vDS_Tanent 和 vDS_SDN），這是生產網絡；VMkernel 端口，這是用於ESXi自己的服務使用的網絡。

端口組分類：

Uplink Port Group：上聯端口組成的端口組。可以配置宿主機的物理網絡連接，以及failover 和 load balancing 策略等。在宿主機側，每個物理網卡都連到到一個上聯端口，都擁有一個特定ID。
Distributed Port Group：分布式端口組，包括VMkernel 和虛機使用的端口組成的組。可以在這種端口組上配置NIC teaming, failover, load balancing, VLAN, security, traffic shaping等功能。

三種端口組：VMkernel、VM、Uplink

VMkernel 端口組：主要用於ESXi 自己的各種功能，比如管理、HA， FT等

上聯端口組：

添加物理網卡：每個 vmnic 是宿主機的一塊物理網卡

VM 網絡：將虛擬機連接到DVS。這是生產網絡。

關於 vSphere 網絡的更多資料，可以參考 https://www.altaro.com/vmware/vsphere-networking-basics-part-1/ https://www.altaro.com/vmware/vsphere-networking-basics-part-2/等文章。

1.2在生產環境中的部署架構

節點

網卡數

網卡用途

KVM宿主機

10G：存儲網絡

10G：SDN網絡

1G：管理網絡

1G: IPMI網絡

ESXi 宿主機

HBA：存儲網絡

10G：SDN網絡

10G：vmKernel 網絡

1G：管理網絡

1G: IPMI網絡

在一台ESXi 宿主機內的網絡連接：

說明：

vDS_internal 是一個 vSphere分布式交換機。它不綁定宿主機的物理網卡，因此其網絡包出不了宿主機。生產虛擬機和OVSvAPP 虛擬機都連接到它上面，其作用是讓生產虛擬機出來的網絡包流入 OVSvAPP，經過其中的 OVS 處理，然后發到 vDS_SDN 分布式交換機。其中，生產虛擬機按照所在的VLAN 網絡，划分到若干個端口組中，每個端口組的VLAN是唯一的。下面的『有趣的環路』部分會有涉及。
vDS_SDN 是一個vSphere分布式交換機。它的主要作用是讓經過 OVSvAPP 虛擬機中處理過的生產虛機的流量留出宿主機。因此它支持兩個網絡流量：一種是跨ESXI 但同虛擬網絡的虛機之間的網絡流量，以及在一個 ESXI 內虛機出宿主機的網絡流量。因此，它需要跨宿主機通信，所以需要綁定物理網卡。
vmKernel 網絡也需要支持跨宿主機通信，因此也需要綁定物理網卡，用於vMotion之類的vSphere內部服務。
另外還需要考慮物理網卡高可用，因此還需要添加更多的網卡。

2.組件

本質上，OpenStack 將 vSphere Cluster 作為一 Nova compute 節點。OpenStack Nova 負責將虛機調度到 vSphere Cluster 上（該調度可以基於AZ），然后 vSphere DRS 負責虛機在集群內部的調度。

備注：OVSvAPP 方案只是多個候選方案中的一種。

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 7。若 VM1 和 VM2 在同一個 vlan 中，兩者的通訊會直接在 Port Grp 7 內進行。

紫線：ESXi 2 上，VM2 和 VM3 在兩個 vlan 上。網絡包從 VM2 出發，首先經過 ESX2 上的 OVSvAPP 虛機，再經過 vDS_SDN 出宿主機，然后經過網絡節點做路由交換，再經過 vDS_SDN 返回ESX2 上的 OVSvAPP 虛機，再到達 VM3。圖中的紫線其實有點誤導，因為它實際上出了ESXI 到了網絡節點（Network Node）。

綠線：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 驅動。