NVIDIA 運(yùn)營商簡化了 Kubernetes 上的 GPU 和 SmartNIC 管理。這篇文章展示了如何使用預(yù)裝的驅(qū)動程序?qū)?NVIDIA 運(yùn)營商集成到新的 edge AI 平臺中。這是一個由兩部分組成的系列文章的第一篇。下一篇文章將介紹如何使用自定義驅(qū)動程序容器集成 NVIDIA 操作符。
面向未來的邊緣人工智能平臺
如今,每個行業(yè)都在使用 edge AI 。部署在飛機(jī)、商店和工廠中的服務(wù)器實(shí)時響應(yīng)物聯(lián)網(wǎng)傳感器。它們分別是 天氣預(yù)測 、 阻止盜竊 和 保證制造質(zhì)量 。
人工智能使傳感器數(shù)據(jù)可操作。經(jīng)過訓(xùn)練的人工智能模型能夠識別模式并觸發(fā)響應(yīng)。經(jīng)過訓(xùn)練的人工智能模型代表公司的商業(yè)智能。正如原油提煉成石油后變得有價值一樣,人工智能將傳感器數(shù)據(jù)轉(zhuǎn)化為洞察力。
但與石油不同, 物聯(lián)網(wǎng)傳感器數(shù)據(jù)量呈指數(shù)增長 。在邊緣生成的大量數(shù)據(jù)可能會壓倒邊緣服務(wù)器處理數(shù)據(jù)的能力。
這就是為什么 邊緣人工智能需要加速 。 NVIDIA GPU 和 SmartNICs 是一個面向未來的邊緣 AI 平臺,可抵御指數(shù)級數(shù)據(jù)增長。
Edge AI 是云本地的
這篇文章描述了如何將 NVIDIA 加速器與 Kubernetes 集成。為什么要關(guān)注庫伯內(nèi)特斯?因?yàn)?edge AI 是云本地的 。大多數(shù)人工智能應(yīng)用程序都是基于容器的微服務(wù)。 Kubernetes 是容器編排的非官方標(biāo)準(zhǔn)。
Edge AI 平臺基于 Kubernetes 的靈活性而構(gòu)建。 Kubernetes API 支持聲明式自動化,并可通過自定義資源定義進(jìn)行擴(kuò)展。強(qiáng)健的軟件生態(tài)系統(tǒng)支持 Kubernetes 的第一天和第二天操作。
NVIDIA Fleet Command 是基于 Kubernetes 的 Edge AI 平臺的一個示例。 Fleet Command 是一種為安全性和性能而設(shè)計(jì)的混合云服務(wù)。它管理裸機(jī)邊緣節(jié)點(diǎn)上的 AI 應(yīng)用程序生命周期。 Fleet Command 還與 NGC 集成,后者是 NVIDIA 管理的 700 多個 GPU 優(yōu)化應(yīng)用程序的注冊中心。
雖然 Fleet Command 支持 NVIDIA GPU 和 SmartNIC ,但許多邊緣平臺不支持。對于這些, NVIDIA 提供了開源 Kubernetes operators 來啟用 GPU 和 SmartNIC 加速。有兩個運(yùn)營商:NVIDIA GPU Operator 及 英偉達(dá)網(wǎng)絡(luò)運(yùn)營商 。
英偉達(dá) GPU 運(yùn)營商自動化 GPU 部署和管理上的 KubNeNETs 。 NGC 上有 GPU 操作員舵圖。它包括幾個組成部分:
這個NVIDIA GPU 驅(qū)動程序容器自動安裝 GPU 驅(qū)動程序。
NVIDIA 容器工具 允許用戶構(gòu)建和運(yùn)行支持 GPU 的容器。
NVIDIA K8s 設(shè)備插件 向吊艙和 Kubernetes 調(diào)度程序公開 GPU 。
NVIDIA DCGM 和 NVIDIA DCGM 導(dǎo)出器 自動執(zhí)行 GPU 遙測采集和管理。
NVIDIA GPU 功能發(fā)現(xiàn)根據(jù) GPU 特征標(biāo)記 Kubernetes 工人。
NVIDIA MIG 管理器監(jiān)視器多實(shí)例 GPU( MIG )用于配置更改并應(yīng)用它們。
圖 1 。這些組件構(gòu)成英偉達(dá) GPU 算子。
英偉達(dá)網(wǎng)絡(luò)運(yùn)營商為 Kubernetes PODs 實(shí)現(xiàn)了需要快速聯(lián)網(wǎng)的 CONTROX 智能配置。它也作為舵圖交付。網(wǎng)絡(luò)運(yùn)營商使用 Multus CNI 插件 向 pod 添加第二個網(wǎng)絡(luò)接口。它支持遠(yuǎn)程直接內(nèi)存訪問( RDMA )和共享根 I / O 虛擬化( SRIOV )。
英偉達(dá)網(wǎng)絡(luò)運(yùn)營商包括以下組件:
NVIDIA OFED 驅(qū)動程序容器 可自動安裝網(wǎng)絡(luò)驅(qū)動程序和庫。
Kubernetes RDMA 共享設(shè)備插件 將 RDMA 設(shè)備連接到 POD 。它支持 Infiniband 和基于聚合以太網(wǎng)( RoCE )的 RDMA 。
SRIOV 設(shè)備插件將 SRIOV 虛擬功能( VF )連接到 POD 。
Containernetworking CNI 插件是擴(kuò)展 Kubernetes 網(wǎng)絡(luò)功能的標(biāo)準(zhǔn)接口。
下落 CNI 插件管理集群范圍的自動 IP 地址創(chuàng)建和分配。
MACVLAN CNI 用作虛擬交換機(jī),將 POD 連接到網(wǎng)絡(luò)功能。
Multus CNI 插件可將多個網(wǎng)絡(luò)設(shè)備連接到 Kubernetes 吊艙。
主機(jī)設(shè)備 CNI 插件將現(xiàn)有設(shè)備(如 SRIOV VF )從主機(jī)移動到 pod 的網(wǎng)絡(luò)名稱空間。
圖 2 。這些組件構(gòu)成英偉達(dá)網(wǎng)絡(luò)運(yùn)營商組件。
兩個操作員都使用 節(jié)點(diǎn)特征發(fā)現(xiàn) 。此服務(wù)標(biāo)識哪些群集節(jié)點(diǎn)具有 GPU 和 SmartNIC 。
操作員一起工作或單獨(dú)工作。將它們部署在一起可啟用 GPUDirect RDMA 。此功能繞過主機(jī)緩沖以提高 NIC 和 GPU 之間的吞吐量。
英偉達(dá)運(yùn)營商是開源軟件。它們已經(jīng)支持在 NVIDIA 認(rèn)證服務(wù)器 上運(yùn)行的流行 Kubernetes 發(fā)行版。但許多邊緣平臺運(yùn)行運(yùn)營商不支持的定制 Linux 發(fā)行版。這篇文章解釋了如何將 NVIDIA 運(yùn)營商與這些平臺集成。
兩條路,一條路
圖 3 。此圖表示集成 NVIDIA 操作程序的兩種方法:預(yù)裝驅(qū)動程序或自定義驅(qū)動程序容器
可移植性是云本地軟件的主要優(yōu)點(diǎn)之一。容器將應(yīng)用程序與其依賴項(xiàng)捆綁在一起。這使它們能夠在不同的平臺上運(yùn)行、擴(kuò)展和遷移,而不會產(chǎn)生摩擦。
NVIDIA 運(yùn)營商是基于容器的云本地應(yīng)用程序。大多數(shù)運(yùn)營商服務(wù)不需要任何集成就可以在新平臺上運(yùn)行。但這兩個操作符都包含驅(qū)動程序容器,驅(qū)動程序是例外。驅(qū)動程序依賴于內(nèi)核。將 NVIDIA 運(yùn)營商與新平臺集成需要重建目標(biāo)內(nèi)核的驅(qū)動程序容器。該平臺可能正在運(yùn)行不受支持的 Linux 發(fā)行版或自定義編譯內(nèi)核。
提供自定義驅(qū)動程序有兩種方法:
首先,在安裝操作員之前將驅(qū)動程序安裝到主機(jī)上。許多邊緣平臺在其基本操作系統(tǒng)映像中提供簽名驅(qū)動程序,以支持 安全和有尺寸的靴子 。需要簽名驅(qū)動程序的平臺不能使用操作員部署的驅(qū)動程序容器。英偉達(dá)艦隊(duì)司令部遵循這種模式。網(wǎng)絡(luò)和 GPU 運(yùn)營商都通過禁用自己的驅(qū)動程序容器來支持預(yù)裝驅(qū)動程序。
第二種方法是將操作員的驅(qū)動程序容器替換為自定義容器。具有不可變文件系統(tǒng)的邊緣平臺更喜歡這種方法。邊緣服務(wù)器通常作為設(shè)備運(yùn)行。他們使用只讀文件系統(tǒng)來提高安全性并防止配置漂移。在內(nèi)存中運(yùn)行驅(qū)動程序和應(yīng)用程序容器,而不是將它們添加到不可變映像中,可以減少其大小和復(fù)雜性。這還允許同一映像在具有不同硬件配置文件的節(jié)點(diǎn)上運(yùn)行。
這篇文章解釋了如何設(shè)置這兩種模式。本文的第一部分介紹了驅(qū)動程序的預(yù)安裝。第二部分介紹如何構(gòu)建和安裝自定義驅(qū)動程序容器。
除了驅(qū)動程序容器外,其余的運(yùn)營商服務(wù)通常在新平臺上運(yùn)行,無需修改。 NVIDIA 在 主要容器運(yùn)行時 上測試這兩個操作符,例如 Docker Engine 、 CRI-O 和 Containerd 。 GPU 運(yùn)算符還支持 運(yùn)行時類資源 進(jìn)行每吊艙運(yùn)行時選擇。
預(yù)裝驅(qū)動程序集成
本文的其余部分將展示如何將 NVIDIA 運(yùn)營商與自定義邊緣平臺集成。它包括驅(qū)動程序預(yù)安裝和驅(qū)動程序容器方法的逐步過程。
表 1 描述了用于演示這些程序的測試系統(tǒng)。
表 1 :測試系統(tǒng)說明
兩個操作員都不支持測試系統(tǒng)上的操作系統(tǒng)、 Linux 內(nèi)核和容器運(yùn)行時組合。 Linux 內(nèi)核是自定義編譯的,因此預(yù)編譯驅(qū)動程序不可用。測試系統(tǒng)還使用 Cri-o 容器運(yùn)行時,這比 Containerd 和 Docker Engine 等替代方案更不常見。
準(zhǔn)備系統(tǒng)
- 首先,驗(yàn)證 CONNECTX SmartNIC 和 NVIDIA GPU 在測試系統(tǒng)上是否可見。
$ lspci | egrep 'nox|NVI'
23:00.0 3D controller: NVIDIA Corporation Device 20f1 (rev a1)
49:00.0 Ethernet controller: Mellanox Technologies MT2892 Family [ConnectX-6 Dx]
49:00.1 Ethernet controller: Mellanox Technologies MT2892 Family [ConnectX-6 Dx]
5e:00.0 Ethernet controller: Mellanox Technologies MT27710 Family [ConnectX-4 Lx]
e3:00.0 Ethernet controller: Mellanox Technologies MT2892 Family [ConnectX-6 Dx]
e3:00.1 Ethernet controller: Mellanox Technologies MT2892 Family [ConnectX-6 Dx]
e6:00.0 3D controller: NVIDIA Corporation Device 20f1 (rev a1)
2 .查看操作系統(tǒng)和 Linux 內(nèi)核版本。在本例中, Centos 7 3 . 10 . 0-1160 . 45 . 1 內(nèi)核被重新編譯為 3 . 10 . 0-1160 . 45 . 1 . el7 . custom . x86 _ 64 。
$ cat /etc/redhat-release CentOS Linux release 7.9.2009 (Core) $ uname -r
3.10.0-1160.45.1.el7.custom.x86_64
3 .查看 Kubernetes 版本、網(wǎng)絡(luò)配置和群集節(jié)點(diǎn)。此輸出顯示了單節(jié)點(diǎn)集群,這是邊緣 AI 部署的典型模式。該節(jié)點(diǎn)正在運(yùn)行 Kubernetes 1 . 21 版。
$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
cgx-20 Ready control-plane 23d v1.21.3
4 .查看已安裝的容器運(yùn)行時。此示例顯示了 cri-o 容器運(yùn)行時。
$ kubectl get node cgx-20 -o yaml | grep containerRuntime containerRuntimeVersion: cri-o://1.21.3
5 . NVIDIA 通過頭盔圖表為操作員提供服務(wù)。查看已安裝的舵機(jī)版本。
$ helm version
version.BuildInfo{Version:"v3.3.3", GitCommit:"55e3ca022e40fe200fbc855938995f40b2a68ce0", GitTreeState:"clean", GoVersion:"go1.14.9"}
使用預(yù)裝的驅(qū)動程序安裝網(wǎng)絡(luò)運(yùn)營商
Mellanox OpenFabrics Linux 企業(yè)發(fā)行版為高性能網(wǎng)絡(luò)安裝開源驅(qū)動程序和庫。 NVIDIA 網(wǎng)絡(luò)操作員可選地安裝一個 MOFE 容器,將這些驅(qū)動程序和庫加載到 Kubernetes 上。本節(jié)介紹在無法使用附帶的驅(qū)動程序容器的情況下在主機(jī)上預(yù)安裝 MOFED 驅(qū)動程序的過程。
- 安裝先決條件。
$ yum install -y perl numactl-libs gtk2 atk cairo gcc-gfortran tcsh libnl3 tcl tk python-devel pciutils make lsof redhat-rpm-config rpm-build libxml2-python ethtool iproute net-tools openssh-clients git openssh-server wget fuse-libs
2 .下載并解壓縮 Linux 發(fā)行版的 MOFED 歸檔文件。
$ wget https://www.mellanox.com/downloads/ofed/MLNX_OFED-5.4-1.0.3.0/MLNX_OFED_LINUX-5.4-1.0.3.0-rhel7.9-x86_64.tgz $ tar zxf MLNX_OFED_LINUX-5.4-1.0.3.0-rhel7.9-x86_64.tgz
3 .使用 mlnxofedinstall 安裝內(nèi)核空間驅(qū)動程序。安裝腳本可能會自動更新 CONNECTX SmartNIC 固件。
$ cd MLNX_OFED_LINUX-5.4-1.0.3.0-rhel7.9-x86_64 $ ./mlnxofedinstall --without-rshim-dkms --without-iser-dkms --without-isert-dkms --without-srp-dkms --without-kernel-mft-dkms --without-mlnx-rdma-rxe-dkms
4 .重新啟動以加載新的驅(qū)動程序。
$ sudo shutdown -r now
5 .重新啟動后,確保已加載驅(qū)動程序。
$ /etc/init.d/openibd status HCA driver loaded Configured Mellanox EN devices:
enp94s0
ens13f0
ens13f1
ens22f0
ens22f1 Currently active Mellanox devices:
enp94s0
ens13f0
ens13f1
ens22f0
ens22f1 The following OFED modules are loaded: rdma_ucm rdma_cm ib_ipoib mlx5_core mlx5_ib ib_uverbs ib_umad ib_cm ib_core mlxfw
一旦成功安裝 MOFED 并加載驅(qū)動程序,就開始安裝英偉達(dá)網(wǎng)絡(luò)運(yùn)營商。
6 .標(biāo)識輔助網(wǎng)絡(luò)設(shè)備名稱。這將是作為輔助網(wǎng)絡(luò)接口插入 pod 的一個或多個設(shè)備。
$ ibdev2netdev
mlx5_0 port 1 ==> ens13f0 (Up)
mlx5_1 port 1 ==> ens13f1 (Down)
mlx5_2 port 1 ==> enp94s0 (Up)
mlx5_3 port 1 ==> ens22f0 (Up)
mlx5_4 port 1 ==> ens22f1 (Down)
7 .默認(rèn)情況下,網(wǎng)絡(luò)運(yùn)營商不會部署到 Kubernetes 主機(jī)。從節(jié)點(diǎn)中刪除主標(biāo)簽以適應(yīng)一體式集群部署。
$ kubectl label nodes --all node-role.kubernetes.io/master- --overwrite
注意:這是一個臨時解決方案,允許網(wǎng)絡(luò)運(yùn)營商將 POD 調(diào)度到單節(jié)點(diǎn)群集中的主節(jié)點(diǎn)。網(wǎng)絡(luò)運(yùn)營商的未來版本將增加容忍度和節(jié)點(diǎn)親和性,以避免這種解決方法。
8 .添加 Mellanox Helm 圖表存儲庫。
$ helm repo add mellanox https://mellanox.github.io/network-operator
$ helm repo update
$ helm repo ls
NAME URL mellanox https://mellanox.github.io/network-operator
9 創(chuàng)建 values . yaml 以指定網(wǎng)絡(luò)運(yùn)營商配置。本例部署 RDMA 共享設(shè)備插件,并將 ens13f0 指定為支持 RDMA 的接口。
$ cat roce_shared_values.yaml nfd: enabled: true
deployCR: true
sriovDevicePlugin: deploy: false
rdmaSharedDevicePlugin: deploy: true resources: - name: rdma_shared_device_a vendors: [15b3] deviceIDs: [101d] ifNames: [ens13f0]
10 安裝網(wǎng)絡(luò)運(yùn)營商 Helm 圖表,使用新配置文件覆蓋 default values . yaml 。
$ helm install -f ./roce_shared_values.yaml -n network-operator --create-namespace --wait network-operator mellanox/network-operator
11 驗(yàn)證所有網(wǎng)絡(luò)運(yùn)營商吊艙是否處于運(yùn)行狀態(tài)。
$ kubectl get pods -n nvidia-network-operator-resources
NAME READY STATUS RESTARTS AGE
cni-plugins-ds-fcrsq 1/1 Running 0 3m44s
kube-multus-ds-4n526 1/1 Running 0 3m44s
rdma-shared-dp-ds-5rq4x 1/1 Running 0 3m44s
whereabouts-9njxm 1/1 Running 0 3m44s
請注意,某些版本的印花布與某些 Multus CNI 版本不兼容。在 Multus 守護(hù)程序啟動后更改 Multus API 版本。
$ sed -i 's/0.4.0/0.3.1/' /etc/cni/net.d/00-multus.conf
12Helm 圖表創(chuàng)建一個 configMap ,用于使用 values . yaml 文件中定義的選擇器標(biāo)記節(jié)點(diǎn)。驗(yàn)證 NFD 是否正確標(biāo)記了節(jié)點(diǎn),以及是否創(chuàng)建了 RDMA 共享設(shè)備。
$ kubectl describe cm -n nvidia-network-operator-resources rdma-devices | grep 15b3
{ "configList": [ { "resourceName": "rdma_shared_device_a", "rdmaHcaMax": 1000, "selectors": { "vendors": ["15b3"], "deviceIDs": ["101d"], "drivers": [], "ifNames": ["ens13f0"], "linkTypes": [] } } ] } $ kubectl describe node cgx-20 | egrep '15b3|rdma_shared' feature.node.kubernetes.io/pci-15b3.present=true feature.node.kubernetes.io/pci-15b3.sriov.capable=true rdma/rdma_shared_device_a: 1k rdma/rdma_shared_device_a: 1k rdma/rdma_shared_device_a 0 0
使用預(yù)裝的驅(qū)動程序安裝 GPU 操作器
按照相同的過程安裝帶有預(yù)編譯驅(qū)動程序的 GPU 操作符。
- 首先,禁用 nouveau GPU 驅(qū)動程序,將其從加載中列入黑名單,并重建初始 RAMdisk 。
$ cat << EOF | sudo tee /etc/modprobe.d/blacklist-nouveau.conf
blacklist nouveau
options nouveau modeset=0
EOF $ sudo dracut --force
2 .下載 Linux 的英偉達(dá) GPU 驅(qū)動程序安裝腳本。在本例中,我們使用的是驅(qū)動程序版本 470 . 57 . 02 。
$ wget https://us.download.nvidia.com/tesla/470.57.02/NVIDIA-Linux-x86_64-470.57.02.run
3 .運(yùn)行安裝腳本。該腳本自動編譯目標(biāo)操作系統(tǒng)內(nèi)核的驅(qū)動程序。
$ sh NVIDIA-Linux-x86_64-470.57.02.run -q -a -n -X -s
4 .驗(yàn)證驅(qū)動程序是否已成功加載。
$ modinfo -F version nvidia
470.57.02
5 .在 Cri-o 容器運(yùn)行時配置中禁用 SELinux 并重新啟動服務(wù)。
請注意, SELinux 在測試系統(tǒng)上處于允許模式。當(dāng) SELinux 處于強(qiáng)制模式時,需要執(zhí)行其他步驟。
$ cat << EOF | sudo tee /etc/crio/crio.conf
[crio]
[crio.runtime]
selinux = false
hooks_dir = [ "/usr/share/containers/oci/hooks.d", "/run/containers/oci/hooks.d",
]
[crio.network]
plugin_dirs = [ "/opt/cni/bin", "/usr/libexec/cni",
]
[crio.metrics]
enable_metrics = true
metrics_port = 9537
EOF $ systemctl restart crio.service
6 .刪除調(diào)度到主節(jié)點(diǎn)時的污點(diǎn)。
$ kubectl taint nodes --all node-role.kubernetes.io/master-
node/cgx-20 untainted
7 .安裝 GPU 操作員舵圖存儲庫。
$ helm repo add nvidia https://nvidia.github.io/gpu-operator $ helm repo update # helm repo ls
NAME URL nvidia https://nvidia.github.io/gpu-operator mellanox https://mellanox.github.io/network-operator
8 .安裝 GPU 操作員舵圖。將 driver . enabled 參數(shù)重寫為 false 將禁用驅(qū)動程序容器安裝。還指定 crio 作為容器運(yùn)行時。
$ helm install --generate-name nvidia/gpu-operator --set driver.enabled=false --set toolkit.version=1.7.1-centos7 --set operator.defaultRuntime=crio $ helm ls
NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
gpu-operator-1635194696 default 1 2021-10-25 16:44:57.237363636 -0400 EDT deployed gpu-operator-v1.8.2 v1.8.2
9 查看 GPU 操作員資源。所有吊艙應(yīng)處于運(yùn)行或完成狀態(tài)。
$ kubectl get pods -n gpu-operator-resources
NAME READY STATUS RESTARTS AGE
gpu-feature-discovery-6kpxt 1/1 Running 0 114s
nvidia-container-toolkit-daemonset-sprjb 1/1 Running 0 114s
nvidia-cuda-validator-ndc78 0/1 Completed 0 90s
nvidia-dcgm-exporter-n9xnp 1/1 Running 0 114s
nvidia-dcgm-pfknx 1/1 Running 0 114s
nvidia-device-plugin-daemonset-4qnh6 1/1 Running 0 114s
nvidia-device-plugin-validator-845pw 0/1 Completed 0 84s
nvidia-mig-manager-rf7vz 1/1 Running 0 114s
nvidia-operator-validator-5ngbk 1/1 Running 0 114s
10 查看驗(yàn)證 pod 日志以驗(yàn)證驗(yàn)證測試是否已完成。
$ kubectl logs -n gpu-operator-resources nvidia-device-plugin-validator-845pw
device-plugin workload validation is successful $ kubectl logs -n gpu-operator-resources nvidia-cuda-validator-ndc78 cuda workload validation is successful
11 從驗(yàn)證器容器中運(yùn)行 nvidia smi 以顯示 GPU 、驅(qū)動程序和 CUDA 版本。這還驗(yàn)證了容器運(yùn)行時預(yù)啟動掛鉤是否按預(yù)期工作。
$ kubectl exec -n gpu-operator-resources -i -t nvidia-operator-validator-5ngbk --container nvidia-operator-validator -- nvidia-smi
Mon Oct 25 20:57:28 2021 +-----------------------------------------------------------------------------+
| NVIDIA-SMI 470.57.02 Driver Version: 470.57.02 CUDA Version: 11.4 |
|-------------------------------+----------------------+----------------------+
| GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. |
| | | MIG M. |
|===============================+======================+======================|
| 0 NVIDIA A100-PCI... Off | 00000000:23:00.0 Off | 0 |
| N/A 26C P0 32W / 250W | 0MiB / 40536MiB | 0% Default |
| | | Disabled |
+-------------------------------+----------------------+----------------------+
| 1 NVIDIA A100-PCI... Off | 00000000:E6:00.0 Off | 0 |
| N/A 26C P0 32W / 250W | 0MiB / 40536MiB | 0% Default |
| | | Disabled |
+-------------------------------+----------------------+----------------------+ +-----------------------------------------------------------------------------+
| Processes: |
| GPU GI CI PID Type Process name GPU Memory |
| ID ID Usage |
|=============================================================================|
| No running processes found |
+-----------------------------------------------------------------------------+
測試預(yù)安裝的驅(qū)動程序集成
通過創(chuàng)建測試吊艙來測試預(yù)裝的驅(qū)動程序集成。
1 .創(chuàng)建網(wǎng)絡(luò)附件定義。網(wǎng)絡(luò)連接定義是一種自定義資源,允許 POD 連接到一個或多個網(wǎng)絡(luò)。此網(wǎng)絡(luò)連接定義定義了一個 MAC VLAN 網(wǎng)絡(luò),用于跨輔助接口橋接多個 POD 。下落 CNI 自動為連接到輔助網(wǎng)絡(luò)的 POD 分配 IP 地址。
$ cat << EOF | sudo tee rdma_shared_macvlan_net.yaml
apiVersion: mellanox.com/v1alpha1
kind: MacvlanNetwork
metadata: name: roce-shared-macvlan-network
spec: networkNamespace: "default" master: "ens13f0" mode: "bridge" mtu: 1500 ipam: | { "type": "whereabouts", "datastore": "kubernetes", "kubernetes": { "kubeconfig": "/etc/cni/net.d/whereabouts.d/whereabouts.kubeconfig" }, "range": "192.168.2.225/28", "exclude": [ "192.168.2.229/30", "192.168.2.236/32" ], "log_file" : "/var/log/whereabouts.log", "log_level" : "info", "gateway": "192.168.2.1" }
EOF
2 .應(yīng)用網(wǎng)絡(luò)附件定義。
$ kubectl create -f roce_shared_macvlan_net.yaml $ kubectl describe network-attachment-definition roce-shared-macvlan-network | grep Config Config: { "cniVersion":"0.4.0", "name":"roce-shared-macvlan-network", "type":"macvlan","master": "ens13f0","mode" : "bridge","mtu" : 1500,"ipam":{"type":"whereabouts","datastore":"kubernetes","kubernetes":{"kubeconfig":"/etc/cni/net.d/whereabouts.d/whereabouts.kubeconfig"},"range":"192.168.2.225/28","exclude":["192.168.2.229/30","192.168.2.236/32"],"log_file":"/var/log/whereabouts.log","log_level":"info","gateway":"192.168.2.1"} }
3 .創(chuàng)建測試吊艙規(guī)范文件。 spec 文件應(yīng)包括 RDMA 設(shè)備的網(wǎng)絡(luò)附件和資源限制的注釋。
$ cat << EOF | sudo tee roce_shared_macvlan_pod.yaml apiVersion: v1
kind: Pod
metadata: name: roce-shared-pod annotations: k8s.v1.cni.cncf.io/networks: roce-shared-macvlan-network
spec: restartPolicy: OnFailure containers: - image: mellanox/rping-test name: mofed-test-ctr securityContext: capabilities: add: [ "IPC_LOCK","NET_RAW" ] resources: requests: rdma/rdma_shared_device_a: 1 limits: rdma/rdma_shared_device_a: 1 command: - sh - -c - | ls -l /dev/infiniband /sys/class/net sleep 1000000
EOF
4 .創(chuàng)建測試吊艙。
$ kubectl create -f roce_shared_pod.yaml $ kubectl get pods | grep roce
roce-shared-pod 1/1 Running 0 6m46s
5 .查看測試盒日志以驗(yàn)證網(wǎng)絡(luò)連接。本例中的輔助接口名為 net1 。
$ kubectl describe pod roce-shared-pod | grep -B1 rdma Limits: rdma/rdma_shared_device_a: 1 Requests: rdma/rdma_shared_device_a: 1 $ kubectl logs roce-shared-pod
/dev/infiniband:
total 0
crw-rw-rw-. 1 root root 231, 64 Oct 13 22:48 issm0
crw-rw-rw-. 1 root root 10, 56 Oct 13 22:48 rdma_cm
crw-rw-rw-. 1 root root 231, 0 Oct 13 22:48 umad0
crw-rw-rw-. 1 root root 231, 192 Oct 13 22:48 uverbs0 /sys/class/net:
total 0
lrwxrwxrwx. 1 root root 0 Oct 13 22:48 eth0 -> ../../devices/virtual/net/eth0
lrwxrwxrwx. 1 root root 0 Oct 13 22:48 lo -> ../../devices/virtual/net/lo
lrwxrwxrwx. 1 root root 0 Oct 13 22:48 net1 -> ../../devices/virtual/net/net1
lrwxrwxrwx. 1 root root 0 Oct 13 22:48 tunl0 -> ../../devices/virtual/net/tunl0
6 .查看 net1 上的地址分配。
$ kubectl exec -ti roce-shared-pod -- ifconfig net1
mtu 1500 inet 192.168.2.225 netmask 255.255.255.240 broadcast 192.168.2.239 inet6 fe80::6871:9cff:fe1b:afe4 prefixlen 64 scopeid 0x20 ether 6a:71:9c:1b:af:e4 txqueuelen 0 (Ethernet) RX packets 405 bytes 24300 (23.7 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 9 bytes 698 (698.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
7 . GPU 操作員創(chuàng)建 POD 以驗(yàn)證驅(qū)動程序、容器運(yùn)行時和 Kubernetes 設(shè)備插件。創(chuàng)建一個額外的 GPU 測試盒。
$ cat << EOF | kubectl create -f -
apiVersion: v1
kind: Pod
metadata: name: cuda-vectoradd
spec: restartPolicy: OnFailure containers: - name: cuda-vectoradd image: "nvidia/samples:vectoradd-cuda11.2.1" resources: limits: nvidia.com/gpu: 1
EOF
8 .查看結(jié)果。
$ kubectl get pod cuda-vectoradd
NAME READY STATUS RESTARTS AGE
cuda-vectoradd 0/1 Completed 0 34s $ kubectl logs cuda-vectoradd
[Vector addition of 50000 elements]
Copy input data from the host memory to the CUDA device
CUDA kernel launch with 196 blocks of 256 threads
Copy output data from the CUDA device to the host memory
Test PASSED
Done
9 加載 nvidia peermem 驅(qū)動程序。它為 CONNECTX SmartNIC 提供 GPUDirect RDMA 。該驅(qū)動程序包含在 NVIDIA Linux GPU 驅(qū)動程序版本 470 及更高版本中。如果系統(tǒng)上同時存在 ib _ core 和 NVIDIA GPU 驅(qū)動程序源,則在 Linux 驅(qū)動程序安裝過程中會自動編譯該文件。這意味著 MOFED 驅(qū)動程序應(yīng)該在 GPU 驅(qū)動程序之前安裝,以便 MOFED 源代碼可用于構(gòu)建 nvidia peermem 驅(qū)動程序。
$ modprobe nvidia-peermem $ lsmod | grep nvidia_peermem
nvidia_peermem 13163 0 nvidia 35224507 113 nvidia_modeset,nvidia_peermem,nvidia_uvm
ib_core 357959 9 rdma_cm,ib_cm,iw_cm,mlx5_ib,ib_umad,nvidia_peermem,ib_uverbs,rdma_ucm,ib_ipoib
關(guān)于作者
Jacob Liberman 是 NVIDIA 企業(yè)和邊緣加速集團(tuán)的產(chǎn)品經(jīng)理。他利用 20 多年的技術(shù)計(jì)算經(jīng)驗(yàn)提供高性能、云計(jì)算原生邊緣人工智能解決方案。此前,他曾在紅帽、 AMD 和戴爾擔(dān)任產(chǎn)品管理和工程職務(wù)。
審核編輯:郭婷
-
運(yùn)營商
+關(guān)注
關(guān)注
4文章
2419瀏覽量
45346 -
NVIDIA
+關(guān)注
關(guān)注
14文章
5309瀏覽量
106448 -
gpu
+關(guān)注
關(guān)注
28文章
4949瀏覽量
131278
發(fā)布評論請先 登錄
研華推出支持雙NVIDIA GPU的高性能邊緣AI系統(tǒng)AIR-500D

NVIDIA-SMI:監(jiān)控GPU的絕佳起點(diǎn)
購買哪款Nvidia GPU
硬件幫助將AI移動到邊緣
NVIDIA 在首個AI推理基準(zhǔn)測試中大放異彩
NVIDIA Jetson的相關(guān)資料分享
基于NVIDIA Jetson Xavier NX設(shè)計(jì),飛凌 AI邊緣計(jì)算終端FCU3001來了
開箱啦!帶你玩轉(zhuǎn)飛凌高算力“魔盒”——AI邊緣計(jì)算終端FCU3001
Nvidia GPU風(fēng)扇和電源顯示ERR怎么解決
在Ubuntu上使用Nvidia GPU訓(xùn)練模型
NVIDIA “魔盒”有哪些“內(nèi)涵”
使用NVIDIA GPU和SmartNIC的邊緣AI
NVIDIA GTC 2023:GPU算力是AI的必需品

評論