20.10. DPDK 및 RDMA 사용
컨테이너화된 DPDK(Data Plane Development Kit) 애플리케이션은 OpenShift Container Platform에서 지원됩니다. DPDK(Data Plane Development Kit) 및 RDMA(Remote Direct Memory Access)와 함께 SR-IOV(Single Root I/O Virtualization) 네트워크 하드웨어를 사용할 수 있습니다.
지원되는 장치에 대한 자세한 내용은 지원되는 장치를 참조하십시오.
20.10.1. Intel NIC와 함께 DPDK 모드에서 가상 기능 사용
사전 요구 사항
-
OpenShift CLI(
oc
)를 설치합니다. - SR-IOV Network Operator 설치.
-
cluster-admin
권한이 있는 사용자로 로그인합니다.
프로세스
다음
SriovNetworkNodePolicy
오브젝트를 생성한 다음 YAML을intel-dpdk-node-policy.yaml
파일에 저장합니다.apiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetworkNodePolicy metadata: name: intel-dpdk-node-policy namespace: openshift-sriov-network-operator spec: resourceName: intelnics nodeSelector: feature.node.kubernetes.io/network-sriov.capable: "true" priority: <priority> numVfs: <num> nicSelector: vendor: "8086" deviceID: "158b" pfNames: ["<pf_name>", ...] rootDevices: ["<pci_bus_id>", "..."] deviceType: vfio-pci 1
- 1
- 가상 기능의 드라이버 유형을
vfio-pci
로 지정합니다.
참고SriovNetworkNodePolicy
의 각 옵션에 대한 자세한 설명은Configuring SR-IOV network devices
섹션을 참조하십시오.SriovNetworkNodePolicy
오브젝트에 지정된 구성을 적용하면 SR-IOV Operator가 노드를 비우고 경우에 따라 노드를 재부팅할 수 있습니다. 구성 변경 사항을 적용하는 데 몇 분이 걸릴 수 있습니다. 제거된 워크로드를 사전에 처리하는 데 클러스터에 사용 가능한 노드가 충분한지 확인하십시오.구성 업데이트가 적용되면
openshift-sriov-network-operator
네임스페이스의 모든 Pod 상태가Running
으로 변경됩니다.다음 명령을 실행하여
SriovNetworkNodePolicy
오브젝트를 생성합니다.$ oc create -f intel-dpdk-node-policy.yaml
다음
SriovNetwork
오브젝트를 생성한 다음 YAML을intel-dpdk-network.yaml
파일에 저장합니다.apiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetwork metadata: name: intel-dpdk-network namespace: openshift-sriov-network-operator spec: networkNamespace: <target_namespace> ipam: |- # ... 1 vlan: <vlan> resourceName: intelnics
- 1
- ipam CNI 플러그인의 구성 오브젝트를 YAML 블록 스칼라로 지정합니다. 플러그인은 연결 정의에 대한 IP 주소 할당을 관리합니다.
참고SriovNetwork
의 각 옵션에 대한 자세한 설명은 " SR-IOV 추가 네트워크 구성" 섹션을 참조하십시오.선택적 라이브러리인 app-netutil은 컨테이너의 상위 pod에 대한 네트워크 정보를 수집하기 위한 여러 API 메서드를 제공합니다.
다음 명령을 실행하여
SriovNetwork
오브젝트를 생성합니다.$ oc create -f intel-dpdk-network.yaml
다음
Pod
사양을 생성한 다음 YAML을intel-dpdk-pod.yaml
파일에 저장합니다.apiVersion: v1 kind: Pod metadata: name: dpdk-app namespace: <target_namespace> 1 annotations: k8s.v1.cni.cncf.io/networks: intel-dpdk-network spec: containers: - name: testpmd image: <DPDK_image> 2 securityContext: runAsUser: 0 capabilities: add: ["IPC_LOCK","SYS_RESOURCE","NET_RAW"] 3 volumeMounts: - mountPath: /dev/hugepages 4 name: hugepage resources: limits: openshift.io/intelnics: "1" 5 memory: "1Gi" cpu: "4" 6 hugepages-1Gi: "4Gi" 7 requests: openshift.io/intelnics: "1" memory: "1Gi" cpu: "4" hugepages-1Gi: "4Gi" command: ["sleep", "infinity"] volumes: - name: hugepage emptyDir: medium: HugePages
- 1
SriovNetwork
오브젝트intel-dpdk-network
가 생성되는 동일한target_namespace
를 지정합니다. 다른 네임스페이스에서 포드를 생성하려면Pod
사양과SriovNetowrk
오브젝트 모두에서target_namespace
를 변경합니다.- 2
- 애플리케이션 및 애플리케이션이 사용하는 DPDK 라이브러리를 포함하는 DPDK 이미지를 지정합니다.
- 3
- hugepage 할당, 시스템 리소스 할당 및 네트워크 인터페이스 액세스를 위해 컨테이너 내부의 애플리케이션에 필요한 추가 기능을 지정합니다.
- 4
/dev/hugepages
아래 DPDK pod에 hugepage 볼륨을 마운트합니다. hugepage 볼륨은 매체가Hugepages
인 emptyDir 볼륨 유형으로 지원됩니다.- 5
- 선택사항: DPDK Pod에 할당된 DPDK 장치 수를 지정합니다. 명시적으로 지정되지 않은 경우 이 리소스 요청 및 제한은 SR-IOV 네트워크 리소스 인젝터에 의해 자동으로 추가됩니다. SR-IOV 네트워크 리소스 인젝터는 SR-IOV Operator에서 관리하는 승인 컨트롤러 구성 요소입니다. 기본적으로 활성화되어 있으며 기본
SriovOperatorConfig
CR에서enableInjector
옵션을false
로 설정하여 비활성화할 수 있습니다. - 6
- CPU 수를 지정합니다. DPDK pod는 일반적으로 kubelet에서 배타적 CPU를 할당해야 합니다. 이를 위해 CPU 관리자 정책을
static
으로 설정하고 QoS가Guaranteed
Pod를 생성합니다. - 7
- hugepage 크기
hugepages-1Gi
또는hugepages-2Mi
를 지정하고 DPDK Pod에 할당할 hugepage 수량을 지정합니다.2Mi
및1Gi
hugepage를 별도로 구성합니다.1Gi
hugepage를 구성하려면 커널 인수를 노드에 추가해야 합니다. 예를 들어, 커널 인수default_hugepagesz = 1GB
,hugepagesz = 1G
및hugepages = 16
을 추가하면 시스템 부팅 시16 * 1Gi
hugepage가 할당됩니다.
다음 명령을 실행하여 DPDK Pod를 생성합니다.
$ oc create -f intel-dpdk-pod.yaml
20.10.2. Mellanox NIC와 함께 DPDK 모드에서 가상 기능 사용
Mellanox NIC와 함께 DPDK 모드의 가상 기능을 사용하여 네트워크 노드 정책을 생성하고 DPDK(Data Plane Development Kit) Pod를 생성할 수 있습니다.
사전 요구 사항
-
OpenShift CLI(
oc
)가 설치되어 있습니다. - SR-IOV(Single Root I/O Virtualization) Network Operator를 설치했습니다.
-
cluster-admin
권한이 있는 사용자로 로그인했습니다.
프로세스
다음
SriovNetworkNodePolicy
YAML 구성을mlx-dpdk-node-policy.yaml
파일에 저장합니다.apiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetworkNodePolicy metadata: name: mlx-dpdk-node-policy namespace: openshift-sriov-network-operator spec: resourceName: mlxnics nodeSelector: feature.node.kubernetes.io/network-sriov.capable: "true" priority: <priority> numVfs: <num> nicSelector: vendor: "15b3" deviceID: "1015" 1 pfNames: ["<pf_name>", ...] rootDevices: ["<pci_bus_id>", "..."] deviceType: netdevice 2 isRdma: true 3
참고SriovNetworkNodePolicy
오브젝트의 각 옵션에 대한 자세한 설명은 SR-IOV 네트워크 장치 구성을 참조하십시오.SriovNetworkNodePolicy
오브젝트에 지정된 구성을 적용하면 SR-IOV Operator가 노드를 비우고 경우에 따라 노드를 재부팅할 수 있습니다. 구성 변경 사항을 적용하는 데 몇 분이 걸릴 수 있습니다. 제거된 워크로드를 사전에 처리하는 데 클러스터에 사용 가능한 노드가 충분한지 확인하십시오.구성 업데이트가 적용되면
openshift-sriov-network-operator
네임스페이스의 모든 Pod 상태가Running
으로 변경됩니다.다음 명령을 실행하여
SriovNetworkNodePolicy
오브젝트를 생성합니다.$ oc create -f mlx-dpdk-node-policy.yaml
다음
SriovNetwork
YAML 구성을mlx-dpdk-network.yaml
파일에 저장합니다.apiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetwork metadata: name: mlx-dpdk-network namespace: openshift-sriov-network-operator spec: networkNamespace: <target_namespace> ipam: |- 1 ... vlan: <vlan> resourceName: mlxnics
- 1
- IP 주소 관리(IPAM) CNI(Container Network Interface) 플러그인의 구성 오브젝트를 YAML 블록 스칼라로 지정합니다. 플러그인은 연결 정의에 대한 IP 주소 할당을 관리합니다.
참고SriovNetwork
오브젝트 의 각 옵션에 대한 자세한 설명은 SR-IOV 네트워크 장치 구성을 참조하십시오.app-netutil
옵션 라이브러리는 컨테이너의 상위 포드에 대한 네트워크 정보를 수집하기 위한 여러 API 메서드를 제공합니다.다음 명령을 실행하여
SriovNetwork
오브젝트를 생성합니다.$ oc create -f mlx-dpdk-network.yaml
다음
Pod
YAML 구성을mlx-dpdk-pod.yaml
파일에 저장합니다.apiVersion: v1 kind: Pod metadata: name: dpdk-app namespace: <target_namespace> 1 annotations: k8s.v1.cni.cncf.io/networks: mlx-dpdk-network spec: containers: - name: testpmd image: <DPDK_image> 2 securityContext: runAsUser: 0 capabilities: add: ["IPC_LOCK","SYS_RESOURCE","NET_RAW"] 3 volumeMounts: - mountPath: /dev/hugepages 4 name: hugepage resources: limits: openshift.io/mlxnics: "1" 5 memory: "1Gi" cpu: "4" 6 hugepages-1Gi: "4Gi" 7 requests: openshift.io/mlxnics: "1" memory: "1Gi" cpu: "4" hugepages-1Gi: "4Gi" command: ["sleep", "infinity"] volumes: - name: hugepage emptyDir: medium: HugePages
- 1
SriovNetwork
오브젝트mlx-dpdk-network
가 생성되는 동일한target_namespace
를 지정합니다. 다른 네임스페이스에서 Pod를 생성하려면Pod
사양 및SriovNetwork
오브젝트 모두에서target_namespace
를 변경합니다.- 2
- 애플리케이션 및 애플리케이션에서 사용하는 DPDK 라이브러리를 포함하는 DPDK 이미지를 지정합니다.
- 3
- hugepage 할당, 시스템 리소스 할당 및 네트워크 인터페이스 액세스를 위해 컨테이너 내부의 애플리케이션에 필요한 추가 기능을 지정합니다.
- 4
- hugepage 볼륨을
/dev/hugepages
아래의 DPDK Pod에 마운트합니다. hugepage 볼륨은 매체가Hugepages
인emptyDir
볼륨 유형으로 지원됩니다. - 5
- 선택 사항: DPDK Pod에 할당된 DPDK 장치 수를 지정합니다. 명시적으로 지정하지 않으면 SR-IOV 네트워크 리소스 인젝터에 의해 이 리소스 요청 및 제한이 자동으로 추가됩니다. SR-IOV 네트워크 리소스 인젝터는 SR-IOV Operator에서 관리하는 승인 컨트롤러 구성 요소입니다. 기본적으로 활성화되어 있으며 기본
SriovOperatorConfig
CR에서enableInjector
옵션을false
로 설정하여 비활성화할 수 있습니다. - 6
- CPU 수를 지정합니다. DPDK Pod는 일반적으로 kubelet에서 전용 CPU를 할당해야 합니다. 이렇게 하려면 CPU 관리자 정책을
static
으로 설정하고 QoS(Quality of Service)가보장된
Pod를 생성합니다. - 7
- hugepage 크기
hugepages-1Gi
또는hugepages-2Mi
를 지정하고 DPDK Pod에 할당할 hugepage 수량을 지정합니다.2Mi
및1Gi
hugepage를 별도로 구성합니다.1Gi
hugepages를 구성하려면 커널 인수를 노드에 추가해야 합니다.
다음 명령을 실행하여 DPDK Pod를 생성합니다.
$ oc create -f mlx-dpdk-pod.yaml
20.10.3. 특정 DPDK 라인 비율 달성 개요
특정 DPDK(Data Plane Development Kit) 라인 속도를 달성하려면 Node Tuning Operator를 배포하고 SR-IOV(Single Root I/O Virtualization)를 구성합니다. 다음 리소스의 DPDK 설정도 조정해야 합니다.
- 분리된 CPU
- hugepages
- 토폴로지 스케줄러
이전 버전의 OpenShift Container Platform에서는 OpenShift Container Platform 애플리케이션에 대해 짧은 대기 시간 성능을 실현하기 위해 자동 튜닝을 구현하는 데 Performance Addon Operator를 사용했습니다. OpenShift Container Platform 4.11 이상에서는 이 기능이 Node Tuning Operator의 일부입니다.
DPDK 테스트 환경
다음 다이어그램은 트래픽 테스트 환경의 구성 요소를 보여줍니다.
![DPDK 테스트 환경](https://access.redhat.com/webassets/avalon/d/OpenShift_Container_Platform-4.11-Networking-ko-KR/images/3feade4011d56df9247e6e040ee32404/261_OpenShift_DPDK_0722.png)
- 트래픽 생성기: 대량의 패킷 트래픽을 생성할 수 있는 애플리케이션입니다.
- SR-IOV 지원 NIC: SR-IOV와 호환되는 네트워크 인터페이스 카드입니다. 이 카드는 물리적 인터페이스에서 여러 가상 기능을 실행합니다.
- PF(물리적 기능 ): SR-IOV 인터페이스를 지원하는 네트워크 어댑터의 PCI Express(PCI Express) 기능입니다.
- VF(가상 기능): SR-IOV를 지원하는 네트워크 어댑터의 경량 DASD 기능입니다. VF는 네트워크 어댑터의 controlPlane PF와 연결되어 있습니다. VF는 네트워크 어댑터의 가상화된 인스턴스를 나타냅니다.
- Switch: 네트워크 스위치입니다. 또한 노드는 back-to-back으로 연결할 수 있습니다.
-
testpmd
: DPDK에 포함된 예제 애플리케이션입니다.testpmd
애플리케이션을 사용하여 packet-forwarding 모드에서 DPDK를 테스트할 수 있습니다.testpmd
애플리케이션은 DPDK 소프트웨어 개발 키트(SDK)를 사용하여 완전한 애플리케이션을 빌드하는 방법의 예입니다. - worker 0 및 worker 1: OpenShift Container Platform 노드
20.10.4. SR-IOV 및 Node Tuning Operator를 사용하여 DPDK 라인 속도 달성
Node Tuning Operator를 사용하여 분리된 CPU, hugepages 및 토폴로지 스케줄러를 구성할 수 있습니다. 그런 다음 Node Tuning Operator를 SR-IOV(Single Root I/O Virtualization)와 함께 사용하여 특정 DPDK(Data Plane Development Kit) 라인 속도를 달성할 수 있습니다.
사전 요구 사항
-
OpenShift CLI(
oc
)가 설치되어 있습니다. - SR-IOV Network Operator가 설치되어 있습니다.
-
cluster-admin
권한이 있는 사용자로 로그인했습니다. 독립 실행형 Node Tuning Operator를 배포했습니다.
참고이전 버전의 OpenShift Container Platform에서는 OpenShift 애플리케이션에 대해 짧은 대기 시간 성능을 실현하기 위해 자동 튜닝을 구현하는 데 Performance Addon Operator를 사용했습니다. OpenShift Container Platform 4.11 이상에서는 이 기능이 Node Tuning Operator의 일부입니다.
프로세스
다음 예제를 기반으로
PerformanceProfile
오브젝트를 생성합니다.apiVersion: performance.openshift.io/v2 kind: PerformanceProfile metadata: name: performance spec: globallyDisableIrqLoadBalancing: true cpu: isolated: 21-51,73-103 1 reserved: 0-20,52-72 2 hugepages: defaultHugepagesSize: 1G 3 pages: - count: 32 size: 1G net: userLevelNetworking: true numa: topologyPolicy: "single-numa-node" nodeSelector: node-role.kubernetes.io/worker-cnf: ""
- 1
- 시스템에서 하이퍼 스레딩이 활성화되면 관련 심볼릭 링크를
분리
및예약된
CPU 그룹에 할당합니다. 시스템에 NUMA(Non-uniform 메모리 액세스 노드)가 여러 개 포함된 경우 두 NUMA에서 두 그룹으로 CPU를 할당합니다. 이 작업에 Performance Profile Creator를 사용할 수도 있습니다. 자세한 내용은 성능 프로필 생성을 참조하십시오. - 2
- 대기열이 예약된 CPU 수로 설정될 장치 목록을 지정할 수도 있습니다. 자세한 내용은 Node Tuning Operator를 사용하여 NIC 대기열 단축을 참조하십시오.
- 3
- 필요한 hugepages의 수와 크기를 할당합니다. hugepages에 대한 NUMA 구성을 지정할 수 있습니다. 기본적으로 시스템은 시스템의 모든 NUMA 노드에 짝수를 할당합니다. 필요한 경우 노드에 실시간 커널 사용을 요청할 수 있습니다. 자세한 내용은 실시간 기능이 있는 작업자 프로비저닝 을 참조하십시오.
-
yaml
파일을mlx-dpdk-perfprofile-policy.yaml
로 저장합니다. 다음 명령을 사용하여 성능 프로필을 적용합니다.
$ oc create -f mlx-dpdk-perfprofile-policy.yaml
20.10.4.1. 가상 기능을 위한 SR-IOV Network Operator의 예
SR-IOV(Single Root I/O Virtualization) Network Operator를 사용하여 노드의 SR-IOV 지원 물리적 기능 NIC에서 VF(가상 기능)를 할당하고 구성할 수 있습니다.
Operator 배포에 대한 자세한 내용은 SR-IOV Network Operator 설치를 참조하십시오. SR-IOV 네트워크 장치 구성에 대한 자세한 내용은 SR-IOV 네트워크 장치 구성을 참조하십시오.
Intel VF와 Mellanox VF에서 DPDK(Data Plane Development Kit) 워크로드 실행 사이에 몇 가지 차이점이 있습니다. 이 섹션에서는 두 VF 유형의 오브젝트 구성 예제를 제공합니다. 다음은 Intel NIC에서 DPDK 애플리케이션을 실행하는 데 사용되는 sriovNetworkNodePolicy
오브젝트의 예입니다.
apiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetworkNodePolicy metadata: name: dpdk-nic-1 namespace: openshift-sriov-network-operator spec: deviceType: vfio-pci 1 needVhostNet: true 2 nicSelector: pfNames: ["ens3f0"] nodeSelector: node-role.kubernetes.io/worker-cnf: "" numVfs: 10 priority: 99 resourceName: dpdk_nic_1 --- apiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetworkNodePolicy metadata: name: dpdk-nic-1 namespace: openshift-sriov-network-operator spec: deviceType: vfio-pci needVhostNet: true nicSelector: pfNames: ["ens3f1"] nodeSelector: node-role.kubernetes.io/worker-cnf: "" numVfs: 10 priority: 99 resourceName: dpdk_nic_2
다음은 Mellanox NIC의 sriovNetworkNodePolicy
오브젝트의 예입니다.
apiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetworkNodePolicy metadata: name: dpdk-nic-1 namespace: openshift-sriov-network-operator spec: deviceType: netdevice 1 isRdma: true 2 nicSelector: rootDevices: - "0000:5e:00.1" nodeSelector: node-role.kubernetes.io/worker-cnf: "" numVfs: 5 priority: 99 resourceName: dpdk_nic_1 --- apiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetworkNodePolicy metadata: name: dpdk-nic-2 namespace: openshift-sriov-network-operator spec: deviceType: netdevice isRdma: true nicSelector: rootDevices: - "0000:5e:00.0" nodeSelector: node-role.kubernetes.io/worker-cnf: "" numVfs: 5 priority: 99 resourceName: dpdk_nic_2
20.10.4.2. SR-IOV 네트워크 Operator의 예
다음은 sriovNetwork
오브젝트 정의의 예입니다. 이 경우 Intel 및 Mellanox 구성은 동일합니다.
apiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetwork metadata: name: dpdk-network-1 namespace: openshift-sriov-network-operator spec: ipam: '{"type": "host-local","ranges": [[{"subnet": "10.0.1.0/24"}]],"dataDir": "/run/my-orchestrator/container-ipam-state-1"}' 1 networkNamespace: dpdk-test 2 spoofChk: "off" trust: "on" resourceName: dpdk_nic_1 3 --- apiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetwork metadata: name: dpdk-network-2 namespace: openshift-sriov-network-operator spec: ipam: '{"type": "host-local","ranges": [[{"subnet": "10.0.2.0/24"}]],"dataDir": "/run/my-orchestrator/container-ipam-state-1"}' networkNamespace: dpdk-test spoofChk: "off" trust: "on" resourceName: dpdk_nic_2
20.10.4.3. DPDK 기본 워크로드의 예
다음은 DPDK(Data Plane Development Kit) 컨테이너의 예입니다.
apiVersion: v1 kind: Namespace metadata: name: dpdk-test --- apiVersion: v1 kind: Pod metadata: annotations: k8s.v1.cni.cncf.io/networks: '[ 1 { "name": "dpdk-network-1", "namespace": "dpdk-test" }, { "name": "dpdk-network-2", "namespace": "dpdk-test" } ]' irq-load-balancing.crio.io: "disable" 2 cpu-load-balancing.crio.io: "disable" cpu-quota.crio.io: "disable" labels: app: dpdk name: testpmd namespace: dpdk-test spec: runtimeClassName: performance-performance 3 containers: - command: - /bin/bash - -c - sleep INF image: registry.redhat.io/openshift4/dpdk-base-rhel8 imagePullPolicy: Always name: dpdk resources: 4 limits: cpu: "16" hugepages-1Gi: 8Gi memory: 2Gi requests: cpu: "16" hugepages-1Gi: 8Gi memory: 2Gi securityContext: capabilities: add: - IPC_LOCK - SYS_RESOURCE - NET_RAW - NET_ADMIN runAsUser: 0 volumeMounts: - mountPath: /mnt/huge name: hugepages terminationGracePeriodSeconds: 5 volumes: - emptyDir: medium: HugePages name: hugepages
SLEEP
로 Pod를 시작한 다음 Pod로 실행하여 testpmd 또는 DPDK 워크로드를 시작합니다. 그러면 exec
프로세스가 CPU에 고정되지 않으므로 추가 인터럽트가 추가될 수 있습니다.
20.10.4.4. testpmd 스크립트의 예
다음은 testpmd
를 실행하는 스크립트의 예입니다.
#!/bin/bash set -ex export CPU=$(cat /sys/fs/cgroup/cpuset/cpuset.cpus) echo ${CPU} dpdk-testpmd -l ${CPU} -a ${PCIDEVICE_OPENSHIFT_IO_DPDK_NIC_1} -a ${PCIDEVICE_OPENSHIFT_IO_DPDK_NIC_2} -n 4 -- -i --nb-cores=15 --rxd=4096 --txd=4096 --rxq=7 --txq=7 --forward-mode=mac --eth-peer=0,50:00:00:00:00:01 --eth-peer=1,50:00:00:00:00:02
이 예에서는 두 개의 다른 sriovNetwork
CR을 사용합니다. 환경 변수에는 Pod에 할당된 VF(가상 기능) PCI 주소가 포함됩니다. Pod 정의에서 동일한 네트워크를 사용하는 경우 pciAddress
를 분할해야 합니다. 트래픽 생성기의 올바른 MAC 주소를 구성하는 것이 중요합니다. 이 예에서는 사용자 정의 MAC 주소를 사용합니다.
20.10.5. Mellanox NIC와 함께 RDMA 모드에서 가상 기능 사용
RoCE(RDMA over Converged Ethernet)는 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.
OpenShift Container Platform에서 RDMA를 사용할 때 RoCE(RDMA over Converged Ethernet)가 지원되는 유일한 모드입니다.
사전 요구 사항
-
OpenShift CLI(
oc
)를 설치합니다. - SR-IOV Network Operator 설치.
-
cluster-admin
권한이 있는 사용자로 로그인합니다.
프로세스
다음
SriovNetworkNodePolicy
오브젝트를 생성한 다음 YAML을mlx-rdma-node-policy.yaml
파일에 저장합니다.apiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetworkNodePolicy metadata: name: mlx-rdma-node-policy namespace: openshift-sriov-network-operator spec: resourceName: mlxnics nodeSelector: feature.node.kubernetes.io/network-sriov.capable: "true" priority: <priority> numVfs: <num> nicSelector: vendor: "15b3" deviceID: "1015" 1 pfNames: ["<pf_name>", ...] rootDevices: ["<pci_bus_id>", "..."] deviceType: netdevice 2 isRdma: true 3
참고SriovNetworkNodePolicy
의 각 옵션에 대한 자세한 설명은Configuring SR-IOV network devices
섹션을 참조하십시오.SriovNetworkNodePolicy
오브젝트에 지정된 구성을 적용하면 SR-IOV Operator가 노드를 비우고 경우에 따라 노드를 재부팅할 수 있습니다. 구성 변경 사항을 적용하는 데 몇 분이 걸릴 수 있습니다. 제거된 워크로드를 사전에 처리하는 데 클러스터에 사용 가능한 노드가 충분한지 확인하십시오.구성 업데이트가 적용되면
openshift-sriov-network-operator
네임스페이스의 모든 Pod 상태가Running
으로 변경됩니다.다음 명령을 실행하여
SriovNetworkNodePolicy
오브젝트를 생성합니다.$ oc create -f mlx-rdma-node-policy.yaml
다음
SriovNetwork
오브젝트를 생성한 다음 YAML을mlx-rdma-network.yaml
파일에 저장합니다.apiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetwork metadata: name: mlx-rdma-network namespace: openshift-sriov-network-operator spec: networkNamespace: <target_namespace> ipam: |- 1 # ... vlan: <vlan> resourceName: mlxnics
- 1
- ipam CNI 플러그인의 구성 오브젝트를 YAML 블록 스칼라로 지정합니다. 플러그인은 연결 정의에 대한 IP 주소 할당을 관리합니다.
참고SriovNetwork
의 각 옵션에 대한 자세한 설명은 " SR-IOV 추가 네트워크 구성" 섹션을 참조하십시오.선택적 라이브러리인 app-netutil은 컨테이너의 상위 pod에 대한 네트워크 정보를 수집하기 위한 여러 API 메서드를 제공합니다.
다음 명령을 실행하여
SriovNetworkNodePolicy
오브젝트를 생성합니다.$ oc create -f mlx-rdma-network.yaml
다음
Pod
사양을 생성한 다음 YAML을mlx-rdma-pod.yaml
파일에 저장합니다.apiVersion: v1 kind: Pod metadata: name: rdma-app namespace: <target_namespace> 1 annotations: k8s.v1.cni.cncf.io/networks: mlx-rdma-network spec: containers: - name: testpmd image: <RDMA_image> 2 securityContext: runAsUser: 0 capabilities: add: ["IPC_LOCK","SYS_RESOURCE","NET_RAW"] 3 volumeMounts: - mountPath: /dev/hugepages 4 name: hugepage resources: limits: memory: "1Gi" cpu: "4" 5 hugepages-1Gi: "4Gi" 6 requests: memory: "1Gi" cpu: "4" hugepages-1Gi: "4Gi" command: ["sleep", "infinity"] volumes: - name: hugepage emptyDir: medium: HugePages
- 1
SriovNetwork
오브젝트mlx-rdma-network
가 생성되는 동일한target_namespace
를 지정합니다. 다른 네임스페이스에서 포드를 생성하려면Pod
사양과SriovNetowrk
오브젝트 모두에서target_namespace
를 변경합니다.- 2
- 애플리케이션 및 애플리케이션에서 사용하는 RDMA 라이브러리를 포함하는 RDMA 이미지를 지정합니다.
- 3
- hugepage 할당, 시스템 리소스 할당 및 네트워크 인터페이스 액세스를 위해 컨테이너 내부의 애플리케이션에 필요한 추가 기능을 지정합니다.
- 4
- hugepage 볼륨을
/dev/hugepages
아래의 RDMA Pod에 마운트합니다. hugepage 볼륨은 매체가Hugepages
인 emptyDir 볼륨 유형으로 지원됩니다. - 5
- CPU 수를 지정합니다. RDMA Pod는 일반적으로 kubelet에서 전용 CPU를 할당해야 합니다. 이를 위해 CPU 관리자 정책을
static
으로 설정하고 QoS가Guaranteed
Pod를 생성합니다. - 6
- hugepage 크기
hugepages-1Gi
또는hugepages-2Mi
를 지정하고 RDMA Pod에 할당할 hugepage 수량을 지정합니다.2Mi
및1Gi
hugepage를 별도로 구성합니다.1Gi
hugepage를 구성하려면 커널 인수를 노드에 추가해야 합니다.
다음 명령을 실행하여 RDMA Pod를 생성합니다.
$ oc create -f mlx-rdma-pod.yaml
20.10.6. OpenStack에서 OVS-DPDK를 사용하는 클러스터에 대한 테스트 Pod 템플릿
다음 testpmd
pod는 대규모 페이지, 예약된 CPU 및 SR-IOV 포트로 컨테이너 생성을 보여줍니다.
예제 testpmd
Pod
apiVersion: v1 kind: Pod metadata: name: testpmd-dpdk namespace: mynamespace annotations: cpu-load-balancing.crio.io: "disable" cpu-quota.crio.io: "disable" # ... spec: containers: - name: testpmd command: ["sleep", "99999"] image: registry.redhat.io/openshift4/dpdk-base-rhel8:v4.9 securityContext: capabilities: add: ["IPC_LOCK","SYS_ADMIN"] privileged: true runAsUser: 0 resources: requests: memory: 1000Mi hugepages-1Gi: 1Gi cpu: '2' openshift.io/dpdk1: 1 1 limits: hugepages-1Gi: 1Gi cpu: '2' memory: 1000Mi openshift.io/dpdk1: 1 volumeMounts: - mountPath: /dev/hugepages name: hugepage readOnly: False runtimeClassName: performance-cnf-performanceprofile 2 volumes: - name: hugepage emptyDir: medium: HugePages
20.10.7. OpenStack에서 OVS 하드웨어 오프로드를 사용하는 클러스터의 테스트 pod 템플릿
다음 testpmd
pod는 RHOSP(Red Hat OpenStack Platform)에서 OVS(Open vSwitch) 하드웨어 오프로드를 보여줍니다.
예제 testpmd
Pod
apiVersion: v1
kind: Pod
metadata:
name: testpmd-sriov
namespace: mynamespace
annotations:
k8s.v1.cni.cncf.io/networks: hwoffload1
spec:
runtimeClassName: performance-cnf-performanceprofile 1
containers:
- name: testpmd
command: ["sleep", "99999"]
image: registry.redhat.io/openshift4/dpdk-base-rhel8:v4.9
securityContext:
capabilities:
add: ["IPC_LOCK","SYS_ADMIN"]
privileged: true
runAsUser: 0
resources:
requests:
memory: 1000Mi
hugepages-1Gi: 1Gi
cpu: '2'
limits:
hugepages-1Gi: 1Gi
cpu: '2'
memory: 1000Mi
volumeMounts:
- mountPath: /dev/hugepages
name: hugepage
readOnly: False
volumes:
- name: hugepage
emptyDir:
medium: HugePages
- 1
- 성능 프로필의 이름이
cnf-performance 프로필
인 경우 해당 문자열을 올바른 성능 프로필 이름으로 바꿉니다.
20.10.8. 추가 리소스
- 성능 프로파일 작성
- Node Tuning Operator를 사용하여 NIC 큐 감소
- 실시간 기능이 있는 작업자 프로비저닝
- SR-IOV Network Operator 설치
- SR-IOV 네트워크 장치 구성
- Whereabouts를 사용한 동적 IP 주소 할당 구성
- 개별 pod에 대한 인터럽트 처리 비활성화
- SR-IOV 이더넷 네트워크 연결 구성
- app-netutil 라이브러리 는 컨테이너의 상위 포드에 대한 네트워크 정보를 수집하기 위한 여러 API 메서드를 제공합니다.