OpenShift 4和GPU在OpenShift參考架構上的AI工作負載

Red Hat OpenShift 是一個企業(yè)級 Kubernetes 平臺，用于大規(guī)模管理 Kubernetes 集群，由 Red Hat 開發(fā)和支持。它提供了一種方法來改變組織如何在本地以及跨混合云管理復雜的基礎設施

人工智能計算給現(xiàn)代商業(yè)帶來了深遠的變革，包括金融服務中的欺詐檢測以及娛樂和電子商務的推薦引擎。 2018 年 CTA 市場研究報告顯示，與不采用人工智能的公司相比，將人工智能技術作為公司戰(zhàn)略核心的公司的利潤率提高了 15% 。

為這些新的、大量計算密集型的工作負載提供基礎設施的責任落在了 IT 的肩上，許多組織都在為 AI 部署 IT 認可的基礎設施所帶來的復雜性、時間和成本上苦苦掙扎。多達 40% 的希望部署人工智能的組織將基礎設施視為主要障礙。為人工智能工作負載部署集群通常會在網(wǎng)絡拓撲、計算和存儲資源的規(guī)模確定等方面提出問題。 NVIDIA 因此為典型應用創(chuàng)建了參考架構，以減輕猜測。

例如 DGX-POD， 它包含了多個 DGX-1 系統(tǒng)及來自多個供應商的存儲系統(tǒng)。 NVIDIA 根據(jù)部署在世界上最大的研究和企業(yè)環(huán)境中的數(shù)千個前沿加速計算節(jié)點的經(jīng)驗，開發(fā)了 DGX POD 。然而，要確保人工智能在規(guī)模上取得成功，就需要一個軟件平臺，如 KubernetesTM ，以確保人工智能基礎設施的可管理性。

紅帽 OpenShift 4 是一個主要的發(fā)行版，它結合了紅帽收購 CoreOS 的技術。其核心（不是雙關語）是基于 Red Hat Enterprise Linux CoreOS （ RHCOS ）的不可變系統(tǒng)映像。它遵循了一個新的范例，即安裝在部署之后永遠不會被修改或更新，而是被整個系統(tǒng)映像的更新版本所取代。這就提供了更高的可靠性和一致性，并提供了更可預測的部署過程。

這篇文章首先介紹了 OpenShift 4 和 GPU 操作符在 OpenShift 參考架構上的 AI 工作負載。我們基于一個需要一些手動步驟的軟件預覽，這將在最終版本中解決。

安裝和運行 OpenShift 需要一個 Red Hat 帳戶和其他訂閱。官方安裝說明見 在裸機上安裝群集 。

測試設置概述

OpenShift 集群的最小配置包括三個 主人 節(jié)點和兩個 工人 節(jié)點（也稱為 計算 節(jié)點）。集群的初始設置需要一個額外的 引導 節(jié)點，可以在安裝過程中刪除或重新調整其用途。有三個主節(jié)點的要求確保了高可用性（避免了大腦分裂的情況），并允許主節(jié)點不間斷地升級。

我們在一臺 x86 機器上使用虛擬機作為引導和主節(jié)點，兩個 DGX-1 系統(tǒng)用于計算節(jié)點（裸機）。負載平衡器在單獨的虛擬機中運行，以將請求分發(fā)到節(jié)點。使用循環(huán) DNS 也起到了作用，但要正確地配置結果卻很棘手。需要將 virsh 網(wǎng)絡設置為橋接模式，而不是 NAT ，以便節(jié)點可以相互通信。

Red Hat OpenShift 4 還沒有為裸機系統(tǒng)提供完全自動化的安裝方法，但需要外部基礎設施來提供和執(zhí)行初始安裝（ OpenShift 文檔將其稱為 用戶提供的基礎設施（ UPI ） 。在我們的例子中，我們使用 x86 服務器通過 PXE 引導來配置和引導節(jié)點。一旦安裝，節(jié)點將自動執(zhí)行升級。

創(chuàng)建系統(tǒng)配置

Red Hat Enterprise Linux CoreOS 使用點火進行系統(tǒng)配置。點火提供了與 cloud init 類似的功能，并允許在第一次引導期間配置系統(tǒng)。

點火文件由 OpenShift 起始頁 安裝程序從配置文件 install-config.yaml 生成。它通過各種參數(shù)描述集群，還包括一個 SSH 密鑰和用于從 redhat 容器存儲庫提取容器的憑據(jù)?？梢詮?OpenShift 下載 OpenShift 工具和 Pull Secret 。

apiVersion: v1
baseDomain: nvidia.com
compute:
- hyperthreading: Enabled name: worker platform: {} replicas: 2
controlPlane: hyperthreading: Enabled name: master platform: {} replicas: 3
metadata: creationTimestamp: null name: dgxpod
networking: clusterNetwork: - cidr: 10.128.0.0/14 hostPrefix: 23 networkType: OpenShiftSDN machineCIDR: 10.0.0.0/16 serviceNetwork: - 172.30.0.0/16
platform: none: {}
pullSecret: '{"auths": ….}'
sshKey: ssh-rsa ...

參數(shù)baseDomain和metadata:name構成集群的域名（dgxpod.nvidia.com）。網(wǎng)絡參數(shù)描述了 OpenShift 集群的內部網(wǎng)絡，只有在與外部網(wǎng)絡沖突時才需要修改。

以下命令為節(jié)點創(chuàng)建點火文件，并為集群創(chuàng)建身份驗證文件。因為這些命令刪除了安裝 – 組態(tài)軟件，所以我們在ignition目錄之外保留了它的一個副本。生成的身份驗證文件（ignition/auth/kubeconfig）應重命名并復制到$USERHOME/.kube/config

mkdir ignition
cp install-config.yaml ignition
openshift-install --dir ignition create ignition-configs

DHCP 和 PXE 引導

設置 PXE 引導當然不是一件容易的事；提供詳細的說明超出了本文的范圍。讀者應具備設置 PXE 引導和 DHCP 的知識。以下代碼段僅介紹 dnsmasq 的 DNS 配置。

dnsmasq 配置文件中的 address 指令允許使用通配符來解析任何帶有負載平衡器地址的*. apps 請求。 SRV 條目允許集群訪問 etcd 服務。

# Add hosts file
addn-hosts=/etc/hosts.dnsmasq # Forward all *.apps.dgxpod.nvidia.com to the load balancer
address=/apps.dgxpod.nvidia.com/10.33.3.54/ # SRV DNS records
srv-host=_etcd-server-ssl._tcp.dgxpod.nvidia.com,etcd-0.dgxpod.nvidia.com,2380,0,10
srv-host=_etcd-server-ssl._tcp.dgxpod.nvidia.com,etcd-1.dgxpod.nvidia.com,2380,0,10
srv-host=_etcd-server-ssl._tcp.dgxpod.nvidia.com,etcd-2.dgxpod.nvidia.com,2380,0,10

相應的/etc/hosts.dnsmasq文件列出了 IP 地址和主機名。注意， OpenShift 要求每個主機的第一個條目是節(jié)點名，例如master-0。api-int和api項指向負載平衡器。

10.33.3.44 worker-0.dgxpod.nvidia.com
10.33.3.46 worker-1.dgxpod.nvidia.com 10.33.3.50 master-0.dgxpod.nvidia.com etcd-0.dgxpod.nvidia.com
10.33.3.51 master-1.dgxpod.nvidia.com etcd-1.dgxpod.nvidia.com
10.33.3.52 master-2.dgxpod.nvidia.com etcd-2.dgxpod.nvidia.com 10.33.3.53 bootstrap.dgxpod.nvidia.com 10.33.3.54 api-int.dgxpod.nvidia.com api.dgxpod.nvidia.com

下面的pxelinux.cfg文件是一個非 EFI-PXE 引導配置的示例。它定義內核和初始 ramdisk ，并提供額外的命令行參數(shù)。注意，前綴為coreos的參數(shù)被傳遞給 CoreOS 安裝程序。

DEFAULT rhcos
PROMPT 0
TIMEOUT 0 LABEL rhcos kernel rhcos/rhcos-410.8.20190425.1-installer-kernel initrd rhcos/rhcos-410.8.20190425.1-installer-initramfs.img append ip=dhcp rd.neednet=1 console=tty0 console=ttyS0 coreos.inst=yes coreos.inst.install_dev=vda coreos.inst.image_url=http://10.33.3.18/rhcos/rhcos-410.8.20190412.1-metal-bios.raw coreos.inst.ignition_url=http://10.33.3.18/rhcos/ignition/master.ign

內核、 initramfs 和 raw 映像可以從 OpenShift 鏡像 獲得。安裝說明 在裸機上安裝群集 提供了最新版本和下載路徑。應將上一步驟中的映像文件和點火配置復制到 http 目錄。請確保為所有這些文件設置了正確的 http SELinux 標簽。請注意， DGX-1 系統(tǒng)僅支持 UEFI 進行網(wǎng)絡引導，因此需要不同的文件集。

負載平衡器

負載平衡器處理跨在線節(jié)點的分布式請求。我們在一個單獨的虛擬機中運行 CentOS 的實例，并使用 HAProxy 進行以下配置。

listen ingress-http bind *:80 mode tcp server worker-0 worker-0.dgxpod.nvidia.com:80 check server worker-1 worker-1.dgxpod.nvidia.com:80 check listen ingress-https bind *:443 mode tcp server worker-0 worker-0.dgxpod.nvidia.com:443 check server worker-1 worker-1.dgxpod.nvidia.com:443 check listen api bind *:6443 mode tcp server bootstrap bootstrap.dgxpod.nvidia.com:6443 check server master-0 master-0.dgxpod.nvidia.com:6443 check server master-1 master-1.dgxpod.nvidia.com:6443 check server master-2 master-2.dgxpod.nvidia.com:6443 check listen machine-config-server bind *:22623 mode tcp server bootstrap bootstrap.dgxpod.nvidia.com:22623 check server master-0 master-0.dgxpod.nvidia.com:22623 check server master-1 master-1.dgxpod.nvidia.com:22623 check server master-2 master-2.dgxpod.nvidia.com:22623 check

創(chuàng)建引導節(jié)點和主節(jié)點

virt install 命令允許輕松部署引導和主節(jié)點。 節(jié)點名稱 應替換為節(jié)點的實際名稱， 節(jié)點 MAC 應替換為節(jié)點的相應網(wǎng)絡地址（ MAC ）。

virt-install --connect qemu:///system --name --ram 8192 --vcpus 4 --os-type=linux --os-variant=virtio26 --disk path=/var/lib/libvirt/images/.qcow2,device=disk,bus=virtio,format=qcow2,size=20 --pxe --network bridge=virbr0 -m --graphics vnc,listen=0.0.0.0 --noautoconsole

初始安裝完成后，虛擬機退出，必須手動重新啟動?？梢允褂么蛴∷谢顒犹摂M機的sudo virsh list監(jiān)視虛擬機的狀態(tài)。重新啟動virsh start 節(jié)點時virsh start 會再次重新啟動virsh start 節(jié)點。

假設設置和配置正確，集群的整個安裝過程應該不到一個小時?？梢允褂靡韵旅畋O(jiān)視初始引導進程。

openshift-install --dir wait-for bootstrap-complete

引導完成后，可以刪除引導節(jié)點。接下來，等待整個安裝過程完成，使用：

openshift-install --dir wait-for install-complete

安裝程序的預發(fā)布版本有時報告錯誤，但最終成功完成。因為它也沒有自動批準掛起的證書（ CSR ），所以我們添加了以下 crontab 條目，每 10 分鐘運行一次。

*/10 * * * * dgxuser oc get csr -ojson | jq -r '.items[] | select(.status == {} ) | .metadata.name' | xargs oc adm certificate approve

GPU 支持

NVIDIA 和 Red Hat 繼續(xù)合作，為部署和管理 GPU 驅動程序提供了一個簡單明了的機制。 節(jié)點特征發(fā)現(xiàn)操作符 （ NFD ）和 GPU 算子為這種改進的機制奠定了基礎，并且可以從胡德帽操作中心獲得。這允許隨時部署和優(yōu)化軟件堆棧。以下說明描述了安裝這些操作器的手動步驟。

NFD 檢測 OpenShift 集群中的硬件特性和配置，例如 CPU 類型和擴展，或者在我們的例子中是 NVIDIA GPUs 。

git clone h?ttps://github.com/openshift/cluster-nfd-operator
cd cluster-nfd-operator/manifests
oc create -f .
oc create -f cr/nfd_cr.yaml

安裝完成后， NVIDIA GPU 應該會出現(xiàn)在 worker 節(jié)點的特性列表中；最終的軟件將提供一個人類可讀的名稱，而不是供應商 ID （0x10de表示 NVIDIA ）。

oc describe node worker-0|grep 10de feature.node.kubernetes.io/pci-10de.present=true

特種資源運營商 （ SRO ）為加速卡提供了一個模板。當檢測到組件并安裝正確的驅動程序和其他軟件組件時，它將激活。

特殊資源運營商的開發(fā)版本已經(jīng)包含了對 NVIDIA GPUs 的支持，并將在可用時并入 NVIDIA GPU 運營商。它管理所有必需的 NVIDIA 驅動程序和軟件組件的安裝過程。

git clone https://github.com/zvonkok/special-resource-operator
cd special-resource-operator/manifests
oc create -f .
cd cr
oc create -f sro_cr_sched_none.yaml

以下nvidia-smi.yamlfile defines a Kubernetes Pod that can be used for a quick validation. It allocates a single GPU and runsthenvidia-smicommand.

apiVersion: v1
kind: Pod
metadata: name: nvidia-smi
spec: containers: - image: nvidia/cuda name: nvidia-smi command: [ nvidia-smi ] resources: limits: nvidia.com/gpu: 1 requests: nvidia.com/gpu: 1

oc create -f nvidia-smi.yaml腳本創(chuàng)建并運行 pod 。要監(jiān)視 pod 創(chuàng)建的進度，請使用oc describe pod nvidia-smi。完成后，可以使用oc logs nvidia-smi查看oc logs nvidia-smi-smi 命令的輸出：

+-----------------------------------------------------------------------------+
| NVIDIA-SMI 418.56 Driver Version: 418.56 CUDA Version: 10.1 |
|-------------------------------+----------------------+----------------------+
| GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. |
|===============================+======================+======================|
| 0 Tesla V100-SXM2... On | 00000000:86:00.0 Off | 0 |
| N/A 36C P0 41W / 300W | 0MiB / 16130MiB | 1% Default |
+-------------------------------+----------------------+----------------------+ +-----------------------------------------------------------------------------+
| Processes: GPU Memory |
| GPU PID Type Process name Usage |
|=============================================================================|
| No running processes found |
+-----------------------------------------------------------------------------+

最后，可以使用 oc delete pod nvidia-smi 刪除 pod 。

結論

引入運營商和構建在 Red Hat Enterprise Linux CoreOS 之上的不可變基礎設施，為 OpenShift 4 帶來了令人興奮的改進。它簡化了多節(jié)點大規(guī)模 GPU 加速數(shù)據(jù)中心的優(yōu)化軟件堆棧的部署和管理。這些新功能現(xiàn)在看起來相當可靠，我們認為客戶將來會很樂意使用它們的。

關于作者

Chris Zankel 是 NVIDIA DGX 系統(tǒng)軟件的高級產(chǎn)品經(jīng)理。作為一名工程師轉為產(chǎn)品經(jīng)理，他擁有從嵌入式設備到大型企業(yè)系統(tǒng)的經(jīng)驗。在過去的工作中，他積極為 Linux 內核做出貢獻，并致力于存儲、虛擬化和容器化

審核編輯：郭婷