本產品的文件集力求使用無偏見用語。針對本文件集的目的,無偏見係定義為未根據年齡、身心障礙、性別、種族身分、民族身分、性別傾向、社會經濟地位及交織性表示歧視的用語。由於本產品軟體使用者介面中硬式編碼的語言、根據 RFP 文件使用的語言,或引用第三方產品的語言,因此本文件中可能會出現例外狀況。深入瞭解思科如何使用包容性用語。
思科已使用電腦和人工技術翻譯本文件,讓全世界的使用者能夠以自己的語言理解支援內容。請注意,即使是最佳機器翻譯,也不如專業譯者翻譯的內容準確。Cisco Systems, Inc. 對這些翻譯的準確度概不負責,並建議一律查看原始英文文件(提供連結)。
本檔案介紹使用SR-IOV和主動備份繫結在OpenStack Cisco Virtualized Infrastructure Manager(CVIM)上逐步部署CPNR。
思科建議您瞭解以下主題:
本文件所述內容不限於特定軟體和硬體版本。
本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除(預設)的組態來啟動。如果您的網路運作中,請確保您瞭解任何指令可能造成的影響
在當前網路環境中,虛擬網路功能(VNF)在實現靈活、可擴展且高效的網路服務方面發揮著關鍵作用。對於需要高效能網路連線的VNF,SR-IOV是一項常用的技術。SR-IOV允許VNF繞過虛擬機器監控程式虛擬交換機,直接訪問物理網路介面控制器(NIC)資源,從而減少延遲並提高吞吐量。
繼續進行部署之前,請確保滿足這些前提條件。
英特爾XL710和E810CQDA2 NIC卡通常用於高效能SR-IOV網路。若要驗證主機上的NIC卡型號,請參閱以下步驟:
執行以下命令列出與網路控制器相關的外圍元件互連(PCI)裝置:
lspci | grep -i ethernet
輸出示例:
81:00.0 Ethernet controller: Intel Corporation Ethernet Controller XL710 for 40GbE QSFP+ (rev 02)
82:00.0 Ethernet controller: Intel Corporation Ethernet Controller E810-C for QSFP (rev 03)
如果網絡卡是Intel XL710,您可以在輸出中看到Ethernet Controller XL710。
如果網絡卡是Intel E810CQDA2,您可以在輸出中看到乙太網控制器E810-Cin。
要檢查正在使用的NIC驅動程式,請運行:
ethtool -i
XL710的輸出示例:
driver: i40e
version: 2.13.10
E810CQDA2的輸出示例:
driver: ice
version: 1.7.12
確保驅動程式版本與OpenStack和Linux分發版的相容性清單相匹配。
確保在伺服器BIOS/UEFI中啟用SR-IOV。
必須啟用Intel VT-d或AMD-Vi才能實現PCI直通和SR-IOV功能。
確保安裝和配置了OpenStack服務,例如Nova、Neutron、Glance和Keystone。
Neutron必須同時支援用於協調/管理網路的Openvswitch(OVS)和用於應用/服務網路的SR-IOV。
必須將計算節點配置為支援SR-IOV,並在NIC上建立虛擬功能(VF)。
CPNR VNF映像必須支援SR-IOV介面並包含必需的驅動程式。
確保OpenStack概覽中提供了CPNR VNF映像。
確保訪問OpenStack CLI以建立網路、風格和啟動VNF。
用於在Linux主機和VNF內配置網路的根或管理訪問許可權。
斯里奧夫
以下是Cisco Elastic Services Controller(ESC)XML示例,演示使用SR-IOV網路(使用type>direct</type>)為名為test-tenant的租戶和名為sriov-vm-1的VM部署虛擬機器(VM)。這包括多個介面,包括SR-IOV(直接)介面:
test-tenant
true
false
sriov-vm-deployment
sriov-vm-1-group
vim1
default
sriov-image
custom-flavor
300
30
REBOOT_ONLY
0
mgmt-net
192.168.10.101
1
direct
sriov-net-1
0
sriov-subnet-1
10.10.10.10
2
direct
sriov-net-2
0
sriov-subnet-2
10.10.20.10
1
1
false
--user-data
file://tmp/init/sriov-vm-1.cfg
type>direct</type>under<interface>為該NIC啟用SR-IOV(PCI通過)。
每個SR-IOV介面都有自己的網路和子網。
您可以根據需要在<addresses>中關聯IPv4/IPv6。
要通過Cisco ESC XML傳遞的Day0檔案示例:
Content-Type: multipart/mixed; boundary="===============2678395050260980330=="
MIME-Version: 1.0`
--===============2678395050260980330==
MIME-Version: 1.0
Content-Type: text/cloud-boothook; charset="us-ascii"
#cloud-boothook
#!/bin/bash
if [ ! -f /etc/cloud/cloud.cfg.orig ]; then
cp /etc/cloud/cloud.cfg /etc/cloud/cloud.cfg.orig
cp /etc/cloud/cloud.cfg.norootpasswd /etc/cloud/cloud.cfg
fi
--===============2678395050260980330==
MIME-Version: 1.0
Content-Type: text/cloud-config; charset="us-ascii"
#cloud-config
hostname: cpnr
ssh_authorized_keys:
- ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQC7pf8gvOWH/Zv8iAlTv6LWEiPGA3B6t96G6LwTHF6iXOqQxyIUkg8IkqZ6wNwxsDV8DYESOzFGp//aXO6wZDtoawMExe9sNEx0qVOt/ueP3IYQ8731fNJwFtWQsCQTM7VQjpcg5/d6eMxQ8zvmiIYo2huwfclE+zLdihjL/Y6v4HK760u/DQ+OaEIgqTgrwePJK5Db/gMDf+oXI9KvNxDb2vtxzroX0APEnZ9JX+Ic0JGWTkD4smMkTdWsjaqDYXqW6SUsyCc4Bf9tHL5Irr1AgUR4hEbLnbk6NlIqWrgVeI5CQVMMFpWqV0o2hyDz2rMA7tbBeYzD/ynslQAerU7DmBRb1FDVh79+JeaCNIM8EpwbCUKHT6CQAjPK8cYBieO1yEHKjHyFTsZgpvdi4rVMP+Qsvab+J5RPPcJeKj7o8KIrtyyESXbLNcZv1uGwZ8nLZKfZQSJP04HUkRKoQJ/JoMvMurEKG/cJ1VtocV4AJiRHj+367D3uzrKd6eHYlM9oD+zpPeJ1P1J2TDPUp2K7GcKCrItn9blSGo/n/+gYBO793QjSdkmc/Ag4TEVhUfG17l0WlSvAw4L0csMlYBAGGqKAUEEx3BJGYNJ851bj23m6JBe83OVWGRWrDIIE+G14/tx8qYXDaFxFUFPb2zj+gmDXq80hYpv++/yFtTocbw== cpnr@INVITN14SLM1BULD01CO
- ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDAmkQGCZUrYqkZ0C0J9t7mF9La9zYOqfzzFkk1wWtPga+aANOaFgjqbjj+VlBdd3zJy1p6BMWZhaZIcOh0+knCisJArcHM3HlurQZXO45zHtBcm7tB1FQ0W1HI9GbvJ+IPIe7kpPme/socd5ytTx0ZkYtlcRDDZuxTwYY4P4/vpnzXuwPS2dfcfQscubj6MkSlx4JHhc/hkDsmtJUipkWEungE/UsldjQzkj8oJorymYHQXE/czNxwzCGizK1YinhebeHFcmHd6Jcqd5oZZWnmkGKGeW6o0ddSFI5NmwzHd5RzwjztU2nqmiyOA8mu7YkCm6X82uhACwQlfY0pGRpTVkIhlf+tKDwKQRuwpcbR1ZUHmli0zi5QZtbzc31aLNlUPpR21BptS4GSfbKJaMOaDUClfe8rGk+9GCgm6wnZiT+SMa4/wEA9NILlwobrwHxVsb/kFlFKXg0aPkdvmqWPNcd09vF50enrs0aXFsqCyl6CPMJpZtGAgckvX8iU2bCJkxzD9F4rAu2D/FNb8KG5cbw7uptiwB4yoek6Q36NyxHYYJyOGiV4oQJ02T9MRPkvjLf7ASx9HA25nG+J4CZXWkuV7XYX1N5DFvOg/kwA7xMPyNgTEkblTRpIcfXU2PCWYSZcn1vYmsazf2uVCY+mjfLcvi85c/1mLnUGikiovQ== admin@invitn14slm1escx01co
runcmd:
- /usr/sbin/useradd FMLVL1 -d /home/FMLVL1 -s /bin/bash -g users; (/bin/echo changeme; /bin/echo changeme) | /usr/bin/passwd FMLVL1
- nmcli con add type ethernet con-name eth0 ifname eth0 ip4 10.xx.xx.xx/24
- nmcli con add type ethernet con-name eth1 ifname eth1 ip4 172.xx.xx.xx/23
- nmcli connection add type bond con-name bond0 ifname bond0 bond.options "mode=active-backup,miimon=1000,fail_over_mac=1" ipv4.addresses 'xx.xx.xx.xx/29' ipv4.gateway 'xx.xx.xx.xx' ipv4.method manual ipv6.addresses '2402:xxxx:xx:0025::5/64' ipv6.gateway '2402:xxxx:xx:0025::1' ipv6.method manual
- nmcli connection add type ethernet ifname ens6 master bond0
- nmcli connection add type ethernet ifname ens7 master bond0
- nmcli con up eth0
- nmcli con up eth1
- nmcli con up bond-slave-ens6
- nmcli con up bond-slave-ens7
- nmcli con down bond0
- nmcli con up bond0
- nmcli connection reload
- hostnamectl set-hostname CPNRDNS01CO
--===============2678395050260980330==
CPNR是一種重要的虛擬網路功能(VNF),為企業和服務提供商網路提供IP地址管理(IPAM)、DHCP和域名伺服器(DNS)服務。在OpenStack中將CPNR部署為VNF需要仔細規劃,特別是在利用SR-IOV埠、跨NUMA配置和Active-Backup繫結介面以實現冗餘和效能時。
本文分步說明了在OpenStack上部署CPNR VNF的過程。它包括:
跨NUMA意識:
Active-Backup繫結:
OpenStack網路:
NUMA是一種記憶體體系結構,其中每個CPU(及其本地記憶體和裝置)被分組到一個NUMA節點。在OpenStack中,支援NUMA的放置可確保將VNF最佳地分配給同一NUMA節點上的資源,以最小化延遲並最大化效能。
SR-IOV NIC為NUMA-Local:
Single-NUMA模式限制:
CPNR VNF需要訪問:
在此部署中,CPNR VNF要求從NUMA 0(sriov0)和NUMA 1(sriov1)訪問SR-IOV NIC,以提供冗餘和高可用性。為了實現這一目標:
Contrack是一種Linux核心功能,用於跟蹤網路連線,特別是網路地址轉換(NAT)和防火牆規則。對於OpenStack中基於OVS的埠,contrack用於管理連線狀態和實施安全組規則。
Contrack表:
預設限制:
對OVS埠的影響:
增大跟蹤表大小:
sysctl net.netfilter.nf_conntrack_max
sysctl -w net.netfilter.nf_conntrack_max=262144
echo "net.netfilter.nf_conntrack_max=262144" >> /etc/sysctl.conf
監控連線使用情況:
檢查連線統計資訊:cat /proc/sys/net/netfilter/nf_conntrack_count
最佳化安全組規則:
減少應用於OVS埠的規則數量,以最小化控制開銷。SR-IOV埠繞過OVS資料路徑和Linux核心功能(如contrack)。這完全消除了連線跟蹤開銷。
與OVS埠不同(受contrack表大小(nf_contrack_max)的限制),SR-IOV埠可以處理幾乎無限數量的連線。
通過將資料包處理解除安裝到NIC硬體,SR-IOV埠消除了基於軟體的連線處理帶來的延遲。
Active-Backup繫結模式由於其簡單、容錯以及與SR-IOV介面的相容性,特別適合於此部署。原因如下:
Active-Backup模式獨立於底層物理交換機或硬體運行。故障切換邏輯完全駐留在Linux核心中,使其具有高度可移植性和通用性。
SR-IOV VF繫結到特定物理NIC和NUMA節點。通過使用主用備份模式,您可以將來自不同NUMA節點的VF合併到單個邏輯繫結介面(bond0)。 這可確保高可用性,同時有效利用NUMA資源。
Active-Backup模式是Linux繫結中最簡單、使用最廣泛的模式之一。它旨在提供高可用性,確保即使某個繫結介面發生故障,流量也能繼續無縫流動。這是對活動備份模式的工作方式、主要特性和優勢的深入解釋。
Linux中的bond介面將兩個或多個網路介面合併到一個邏輯介面中。此邏輯介面(稱為繫結(例如bond0)用於提供:
在Active-Backup模式下,在任何給定時間都僅使用一個介面(稱為active interface)來傳輸和接收流量。其他介面仍保留備用模式。如果主用介面發生故障,其中一個備用介面將提升為主用狀態,流量將自動重新路由到新的主用介面。
單個活動介面:
自動故障轉移:
故障恢復支援:
故障介面恢復後,根據繫結配置,它可以自動再次變為活動狀態(如果已進行配置)或保持在備用模式。無交換機端要求:
監控:
監控
所有成員介面的運行狀況。Active Interface:
監控:
活動介面上的鏈路故障:
如果活動介面(eth2)發生故障(例如,電纜拔出、NIC硬體故障或鏈路斷開),鏈路連線會立即使用MIMOON或ARP監控來檢測故障。自動故障轉移:
故障轉移及時性:
故障轉移過程幾乎是瞬時的(通常在幾毫秒內,具體取決於最小間隔)。恢復故障介面:
流量連續性:
回切是無縫的,確保不會中斷持續流量。Active-Backup模式尤其適用於SR-IOV介面,因為:
舉例來說:
CPNR VNF需要以下四個網路:
逐步部署:
協調網路:
openstack network create --provider-network-type vxlan orchestration-network
管理網路:
openstack network create --provider-network-type vxlan management-network
業務流程子網:
openstack subnet create --network orchestration-network \
--subnet-range 192.168.100.0/24 orchestration-subnet
管理子網:
openstack subnet create --network management-network \
--subnet-range 10.10.10.0/24 management-subnet
SR-IOV網路1:
openstack network create --provider-network-type vlan \
--provider-physical-network sriov0 --provider-segment 101 sriov-network-1
SR-IOV網路2:
openstack network create --provider-network-type vlan \
--provider-physical-network sriov1 --provider-segment 102 sriov-network-2
為了確保VNF可以訪問來自兩個NUMA節點的SR-IOV NIC,請建立具有跨NUMA支援的風格:
openstack flavor create --ram 8192 --vcpus 4 --disk 40 cross-numa-flavor
設定NUMA特定的屬性:
openstack flavor set cross-numa-flavor \
--property hw:numa_nodes=2 \
--property hw:cpu_policy=dedicated \
--property hw:mem_page_size=large
啟動VNF後,為VNF上的SR-IOV埠(eth2和eth3)配置繫結介面。
在活動備份模式下建立繫結介面(bond0):
vi /etc/sysconfig/network-scripts/ifcfg-bond0
DEVICE=bond0
BOOTPROTO=static
ONBOOT=yes
BONDING_OPTS="mode=active-backup miimon=100"
IPADDR=172.16.1.10
NETMASK=255.255.255.0
GATEWAY=172.16.1.1
eth2:
vi /etc/sysconfig/network-scripts/ifcfg-eth2
DEVICE=eth2
ONBOOT=yes
MASTER=bond0
SLAVE=yes
eth3:
vi /etc/sysconfig/network-scripts/ifcfg-eth3
DEVICE=eth3
ONBOOT=yes
MASTER=bond0
SLAVE=yes
重新啟動網路服務以應用組態:
systemctl restart network
部署VNF後,使用以下步驟驗證其功能:
檢查VNF例項是否處於活動狀態:
openstack server show cpnr-instance
確保狀態為ACTIVE。
Ping測試:驗證VNF是否可以通過所有網路通訊:
ping
ping
Bond Interface:
確認bond0處於活動狀態:
cat /proc/net/bonding/bond0
尋找:
確保VNF正在使用來自兩個NUMA節點的資源:
nova show --human | grep numa
監控和故障排除:使用工具(例如keetcpdumpandethtoolkit)監控SR-IOV介面。
資安:小心管理對物理網路的訪問,並在租戶之間實施嚴格隔離。
擴展:在擴展SR-IOV部署時規劃物理NIC容量,因為可用VF的數量受NIC硬體的限制。
如果部署未按預期工作,請參閱以下故障排除步驟:
dmesg | grep -i "SR-IOV"
lspci | grep Ethernet
如果VNF無法訪問兩個NIC,請確保啟用跨NUMA模式:
openstack flavor show cross-numa-flavor
cat /proc/net/bonding/bond0
systemctl restart network
openstack port list --server cpnr-instance
ip addr show
在具有SR-IOV埠的OpenStack上部署CPNR VNF需要跨NUMA模式,以使VNF從兩個NUMA節點連線到NIC。這是至關重要的,因為OpenStack將VNF限制在單NUMA模式下,只訪問啟動VNF的NUMA節點內的資源(NIC、CPU、記憶體)。將跨NUMA模式與Active-Backup繫結結合使用可確保高可用性、容錯性和高效的資源利用率,從而使此部署具有極高的彈性和效能。
修訂 | 發佈日期 | 意見 |
---|---|---|
1.0 |
10-Jul-2025
|
初始版本 |