19.9. 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) 네트워크 하드웨어를 사용할 수 있습니다.
다음 문서에서 작업을 수행하기 전에 SR-IOV Network Operator를 설치 했는지 확인합니다.
19.9.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: /mnt/huge 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를 생성하려면Pod
사양과SriovNetwork
오브젝트 모두에서target_namespace
를 변경합니다.- 2
- 애플리케이션 및 애플리케이션이 사용하는 DPDK 라이브러리를 포함하는 DPDK 이미지를 지정합니다.
- 3
- hugepage 할당, 시스템 리소스 할당 및 네트워크 인터페이스 액세스를 위해 컨테이너 내부의 애플리케이션에 필요한 추가 기능을 지정합니다.
- 4
/mnt/huge
의 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가보장
된 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
19.9.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
- IPAM(IP Address Management) 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: /mnt/huge 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 볼륨을
/mnt/huge
아래의 DPDK Pod에 마운트합니다. hugepage 볼륨은 medium가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
19.9.3. Cryostat CNI를 사용하여 커널 액세스로 루트리스 DPDK 워크로드 실행
DPDK 애플리케이션은 virtio-user
를 예외 경로로 사용하여 로그 메시지와 같은 특정 유형의 패킷을 처리를 위해 커널에 삽입할 수 있습니다. 이 기능에 대한 자세한 내용은 Exception Path로 Virtio_user 를 참조하십시오.
OpenShift Container Platform 버전 4.14 이상에서는 권한이 없는 Pod를 사용하여 탭 CNI 플러그인과 함께 DPDK 애플리케이션을 실행할 수 있습니다. 이 기능을 활성화하려면 SriovNetworkNodePolicy
오브젝트 내에서 needVhostNet
매개변수를 true
로 설정하여 vhost-net
장치를 마운트해야 합니다.
그림 19.1. DPDK 및 Cryostat 예제 구성
사전 요구 사항
-
OpenShift CLI(
oc
)가 설치되어 있습니다. - SR-IOV Network Operator가 설치되어 있습니다.
-
cluster-admin
권한이 있는 사용자로 로그인합니다. setsebools container_use_devices=on
이 모든 노드에서 root로 설정되어 있는지 확인합니다.참고Machine Config Operator를 사용하여 이 SELinux 부울을 설정합니다.
프로세스
다음 예와 같은 콘텐츠를 사용하여
test-namespace.yaml
과 같은 파일을 생성합니다.apiVersion: v1 kind: Namespace metadata: name: test-namespace labels: pod-security.kubernetes.io/enforce: privileged pod-security.kubernetes.io/audit: privileged pod-security.kubernetes.io/warn: privileged security.openshift.io/scc.podSecurityLabelSync: "false"
다음 명령을 실행하여 새
Namespace
오브젝트를 생성합니다.$ oc apply -f test-namespace.yaml
다음 예와 같은 콘텐츠를 사용하여
sriov-node-network-policy.yaml
과 같은 파일을 생성합니다.apiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetworkNodePolicy metadata: name: sriovnic namespace: openshift-sriov-network-operator spec: deviceType: netdevice 1 isRdma: true 2 needVhostNet: true 3 nicSelector: vendor: "15b3" 4 deviceID: "101b" 5 rootDevices: ["00:05.0"] numVfs: 10 priority: 99 resourceName: sriovnic nodeSelector: feature.node.kubernetes.io/network-sriov.capable: "true"
- 1
- 이는 프로파일이 Mellanox Network Interface Controller(NIC)에 맞게 조정됨을 나타냅니다.
- 2
isRdma
를true
로 설정하는 것은 Mellanox NIC에만 필요합니다.- 3
- 그러면 애플리케이션이 탭 장치를 생성하고 탭 장치를 DPDK 워크로드에 연결할 수 있도록
/dev/net/tun
및/dev/vhost-net
장치를 컨테이너에 마운트합니다. - 4
- SR-IOV 네트워크 장치의 벤더 16진수 코드입니다. 값 15b3은 Mellanox NIC와 연결되어 있습니다.
- 5
- SR-IOV 네트워크 장치의 장치 16진수 코드입니다.
다음 명령을 실행하여
SriovNetworkNodePolicy
오브젝트를 생성합니다.$ oc create -f sriov-node-network-policy.yaml
다음
SriovNetwork
오브젝트를 생성한 다음 YAML을sriov-network-attachment.yaml
파일에 저장합니다.apiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetwork metadata: name: sriov-network namespace: openshift-sriov-network-operator spec: networkNamespace: test-namespace resourceName: sriovnic spoofChk: "off" trust: "on"
참고SriovNetwork
의 각 옵션에 대한 자세한 설명은 " SR-IOV 추가 네트워크 구성" 섹션을 참조하십시오.선택적 라이브러리인
app-netutil
은 컨테이너의 상위 pod에 대한 네트워크 정보를 수집하기 위한 여러 API 메서드를 제공합니다.다음 명령을 실행하여
SriovNetwork
오브젝트를 생성합니다.$ oc create -f sriov-network-attachment.yaml
다음 예와 같은 콘텐츠를 사용하여 네트워크 연결 정의를 정의하는
tap-example.yaml
과 같은 파일을 생성합니다.apiVersion: "k8s.cni.cncf.io/v1" kind: NetworkAttachmentDefinition metadata: name: tap-one namespace: test-namespace 1 spec: config: '{ "cniVersion": "0.4.0", "name": "tap", "plugins": [ { "type": "tap", "multiQueue": true, "selinuxcontext": "system_u:system_r:container_t:s0" }, { "type":"tuning", "capabilities":{ "mac":true } } ] }'
- 1
SriovNetwork
오브젝트가 생성되는 동일한target_namespace
를 지정합니다.
다음 명령을 실행하여
NetworkAttachmentDefinition
오브젝트를 생성합니다.$ oc apply -f tap-example.yaml
다음 예와 같은 콘텐츠를 사용하여
dpdk-pod-rootless.yaml
과 같은 파일을 만듭니다.apiVersion: v1 kind: Pod metadata: name: dpdk-app namespace: test-namespace 1 annotations: k8s.v1.cni.cncf.io/networks: '[ {"name": "sriov-network", "namespace": "test-namespace"}, {"name": "tap-one", "interface": "ext0", "namespace": "test-namespace"}]' spec: nodeSelector: kubernetes.io/hostname: "worker-0" securityContext: fsGroup: 1001 2 runAsGroup: 1001 3 seccompProfile: type: RuntimeDefault containers: - name: testpmd image: <DPDK_image> 4 securityContext: capabilities: drop: ["ALL"] 5 add: 6 - IPC_LOCK - NET_RAW #for mlx only 7 runAsUser: 1001 8 privileged: false 9 allowPrivilegeEscalation: true 10 runAsNonRoot: true 11 volumeMounts: - mountPath: /mnt/huge 12 name: hugepages resources: limits: openshift.io/sriovnic: "1" 13 memory: "1Gi" cpu: "4" 14 hugepages-1Gi: "4Gi" 15 requests: openshift.io/sriovnic: "1" memory: "1Gi" cpu: "4" hugepages-1Gi: "4Gi" command: ["sleep", "infinity"] runtimeClassName: performance-cnf-performanceprofile 16 volumes: - name: hugepages emptyDir: medium: HugePages
- 1
SriovNetwork
오브젝트가 생성되는 동일한target_namespace
를 지정합니다. 다른 네임스페이스에서 Pod를 생성하려면Pod
사양과SriovNetwork
오브젝트 모두에서target_namespace
를 변경합니다.- 2
- 볼륨 마운트 디렉토리 및 해당 볼륨에서 생성된 파일의 그룹 소유권을 설정합니다.
- 3
- 컨테이너 실행에 사용되는 기본 그룹 ID를 지정합니다.
- 4
- 애플리케이션 및 애플리케이션에서 사용하는 DPDK 라이브러리를 포함하는 DPDK 이미지를 지정합니다.
- 5
- 컨테이너의 securityContext에서 모든 기능(
ALL
)을 제거하면 컨테이너에 일반 작업에 필요한 것 이상으로 특별한 권한이 없습니다. - 6
- hugepage 할당, 시스템 리소스 할당 및 네트워크 인터페이스 액세스를 위해 컨테이너 내부의 애플리케이션에 필요한 추가 기능을 지정합니다. 이러한 기능은
setcap
명령을 사용하여 바이너리 파일에서 설정해야 합니다. - 7
- Mellanox NIC(네트워크 인터페이스 컨트롤러)에는
NET_RAW
기능이 필요합니다. - 8
- 컨테이너 실행에 사용되는 사용자 ID를 지정합니다.
- 9
- 이 설정은 Pod 내의 컨테이너 또는 컨테이너에 호스트 시스템에 대한 권한 액세스 권한을 부여하지 않아야 함을 나타냅니다.
- 10
- 이 설정을 사용하면 컨테이너가 할당되었을 수 있는 초기 루트 권한이 아닌 초기 권한을 에스컬레이션할 수 있습니다.
- 11
- 이 설정을 사용하면 컨테이너가 루트가 아닌 사용자로 실행됩니다. 이렇게 하면 컨테이너 손상 및 공격 면적 감소의 잠재적인 영향을 제한하여 최소 권한 원칙을 적용하는 데 도움이 됩니다.
- 12
/mnt/huge
의 DPDK Pod에 hugepage 볼륨을 마운트합니다. hugepage 볼륨은 매체가Hugepages
인 emptyDir 볼륨 유형으로 지원됩니다.- 13
- 선택 사항: DPDK Pod에 할당된 DPDK 장치 수를 지정합니다. 명시적으로 지정하지 않으면 SR-IOV 네트워크 리소스 인젝터에 의해 이 리소스 요청 및 제한이 자동으로 추가됩니다. SR-IOV 네트워크 리소스 인젝터는 SR-IOV Operator에서 관리하는 승인 컨트롤러 구성 요소입니다. 기본적으로 활성화되어 있으며 기본
SriovOperatorConfig
CR에서enableInjector
옵션을false
로 설정하여 비활성화할 수 있습니다. - 14
- CPU 수를 지정합니다. DPDK pod는 일반적으로 kubelet에서 배타적 CPU를 할당해야 합니다. 이를 위해 CPU 관리자 정책을
static
으로 설정하고 QoS가보장
된 Pod를 생성합니다. - 15
- hugepage 크기
hugepages-1Gi
또는hugepages-2Mi
를 지정하고 DPDK Pod에 할당할 hugepage 수량을 지정합니다.2Mi
및1Gi
hugepage를 별도로 구성합니다.1Gi
hugepage를 구성하려면 커널 인수를 노드에 추가해야 합니다. 예를 들어, 커널 인수default_hugepagesz = 1GB
,hugepagesz = 1G
및hugepages = 16
을 추가하면 시스템 부팅 시16 * 1Gi
hugepage가 할당됩니다. - 16
- 성능 프로필의 이름이
cnf-performance 프로필
로 지정되지 않은 경우 해당 문자열을 올바른 성능 프로필 이름으로 교체합니다.
다음 명령을 실행하여 DPDK Pod를 생성합니다.
$ oc create -f dpdk-pod-rootless.yaml
추가 리소스
19.9.4. 특정 DPDK 라인 비율 달성 개요
특정 DPDK(Data Plane Development Kit) 라인 속도를 달성하려면 Node Tuning Operator를 배포하고 SR-IOV(Single Root I/O Virtualization)를 구성합니다. 다음 리소스에 대한 DPDK 설정도 조정해야 합니다.
- 분리된 CPU
- hugepages
- 토폴로지 스케줄러
이전 버전의 OpenShift Container Platform에서는 Performance Addon Operator를 사용하여 OpenShift Container Platform 애플리케이션에 대한 짧은 대기 시간 성능을 달성하기 위해 자동 튜닝을 구현했습니다. OpenShift Container Platform 4.11 이상에서 이 기능은 Node Tuning Operator의 일부입니다.
DPDK 테스트 환경
다음 다이어그램은 트래픽 테스트 환경의 구성 요소를 보여줍니다.
- 트래픽 생성기: 대용량 패킷 트래픽을 생성할 수 있는 애플리케이션입니다.
- SR-IOV-supporting NIC: SR-IOV와 호환되는 네트워크 인터페이스 카드입니다. 이 카드는 물리적 인터페이스에서 여러 가상 기능을 실행합니다.
- 물리적 기능(PF ): SR-IOV 인터페이스를 지원하는 네트워크 어댑터의 PCI Express(PCIe) 기능입니다.
- VF(가상 기능): SR-IOV를 지원하는 네트워크 어댑터의 경량 PCIe 기능입니다. VF는 네트워크 어댑터의 PCIe PF와 연결되어 있습니다. VF는 네트워크 어댑터의 가상화된 인스턴스를 나타냅니다.
- Switch: 네트워크 스위치 노드를 뒤로 연결할 수도 있습니다.
-
testpmd
: DPDK에 포함된 예제 애플리케이션입니다.testpmd
애플리케이션을 사용하여 패킷 전달 모드에서 DPDK를 테스트할 수 있습니다.testpmd
애플리케이션은 DPDK SDK(Software Development Kit)를 사용하여 완전한 애플리케이션을 빌드하는 방법의 예이기도 합니다. - 작업자 0 및 작업자 1: OpenShift Container Platform 노드.
19.9.5. SR-IOV 및 Node Tuning Operator를 사용하여 DPDK 라인 속도 달성
Node Tuning Operator를 사용하여 분리된 CPU, hugepages 및 토폴로지 스케줄러를 구성할 수 있습니다. 그런 다음 SR-IOV(Single Root I/O Virtualization)와 함께 Node Tuning Operator를 사용하여 특정 DPDK(Data Plane Development Kit) 라인 속도를 얻을 수 있습니다.
사전 요구 사항
-
OpenShift CLI(
oc
)가 설치되어 있습니다. - SR-IOV Network Operator가 설치되어 있습니다.
-
cluster-admin
권한이 있는 사용자로 로그인했습니다. 독립 실행형 Node Tuning Operator를 배포했습니다.
참고이전 버전의 OpenShift Container Platform에서는 Performance Addon Operator를 사용하여 OpenShift 애플리케이션에 대해 짧은 대기 시간 성능을 달성하기 위해 자동 튜닝을 구현했습니다. 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 그룹과예약된
CPU 그룹에 관련 심볼릭 링크를 할당합니다. 시스템에 NUMA(Non-Uniform Memory Access nodes)가 여러 개 포함된 경우 두 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
19.9.5.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
19.9.5.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
19.9.5.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에 고정되지 않으므로 추가 인터럽트를 추가할 수 있습니다.
19.9.5.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 주소가 포함되어 있습니다. 포드 정의에서 동일한 네트워크를 사용하는 경우 pciAddress
를 분할해야 합니다. 트래픽 생성기의 올바른 MAC 주소를 구성하는 것이 중요합니다. 이 예에서는 사용자 지정 MAC 주소를 사용합니다.
19.9.6. 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: /mnt/huge 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를 생성하려면Pod
사양과SriovNetwork
오브젝트 모두에서target_namespace
를 변경합니다.- 2
- 애플리케이션 및 애플리케이션에서 사용하는 RDMA 라이브러리를 포함하는 RDMA 이미지를 지정합니다.
- 3
- hugepage 할당, 시스템 리소스 할당 및 네트워크 인터페이스 액세스를 위해 컨테이너 내부의 애플리케이션에 필요한 추가 기능을 지정합니다.
- 4
- hugepage 볼륨을
/mnt/huge
아래의 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
19.9.7. OpenStack에서 OVS-DPDK를 사용하는 클러스터의 테스트 포드 템플릿
다음 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: /mnt/huge name: hugepage readOnly: False runtimeClassName: performance-cnf-performanceprofile 2 volumes: - name: hugepage emptyDir: medium: HugePages
19.9.8. OpenStack에서 OVS 하드웨어 오프로드를 사용하는 클러스터의 테스트 포드 템플릿
다음 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: /mnt/huge
name: hugepage
readOnly: False
volumes:
- name: hugepage
emptyDir:
medium: HugePages
- 1
- 성능 프로필의 이름이
cnf-performance 프로필
로 지정되지 않은 경우 해당 문자열을 올바른 성능 프로필 이름으로 교체합니다.
19.9.9. 추가 리소스
- 지원되는 장치
- 성능 프로파일 작성
- 성능 프로파일을 사용하여 NIC 큐 조정
- 실시간 및 짧은 대기 시간 워크로드 프로비저닝
- SR-IOV Network Operator 설치
- SR-IOV 네트워크 장치 구성
- Whereabouts를 사용한 동적 IP 주소 할당 구성
- 개별 pod에 대한 인터럽트 처리 비활성화
- SR-IOV 이더넷 네트워크 연결 구성
- app-netutil 라이브러리는 컨테이너의 상위 pod에 대한 네트워크 정보를 수집하기 위한 여러 API 메서드를 제공합니다.