23.4. SR-IOV 네트워크 장치 구성

클러스터에서 SR-IOV(Single Root I/O Virtualization) 장치를 구성할 수 있습니다.

23.4.1. SR-IOV 네트워크 노드 구성 오브젝트

SR-IOV 네트워크 노드 정책을 생성하여 노드의 SR-IOV 네트워크 장치 구성을 지정합니다. 정책의 API 오브젝트는 sriovnetwork.openshift.io API 그룹의 일부입니다.

다음 YAML은 SR-IOV 네트워크 노드 정책을 설명합니다.

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: <name> 1
  namespace: openshift-sriov-network-operator 2
spec:
  resourceName: <sriov_resource_name> 3
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true" 4
  priority: <priority> 5
  mtu: <mtu> 6
  needVhostNet: false 7
  numVfs: <num> 8
  nicSelector: 9
    vendor: "<vendor_code>" 10
    deviceID: "<device_id>" 11
    pfNames: ["<pf_name>", ...] 12
    rootDevices: ["<pci_bus_id>", ...] 13
    netFilter: "<filter_string>" 14
  deviceType: <device_type> 15
  isRdma: false 16
    linkType: <link_type> 17
  eSwitchMode: "switchdev" 18
1
사용자 정의 리소스 오브젝트의 이름입니다.
2
SR-IOV Network Operator가 설치된 네임스페이스입니다.
3
SR-IOV 네트워크 장치 플러그인의 리소스 이름입니다. 리소스 이름에 대한 SR-IOV 네트워크 노드 정책을 여러 개 생성할 수 있습니다.

이름을 지정할 때 resourceName 에서 허용된 구문 표현식 ^[a-zA-Z0-9_]+$ 를 사용해야 합니다.

4
노드 선택기는 구성할 노드를 지정합니다. 선택한 노드의 SR-IOV 네트워크 장치만 구성됩니다. SR-IOV CNI(Container Network Interface) 플러그인 및 장치 플러그인은 선택한 노드에만 배포됩니다.
5
선택 사항: 우선순위는 0 에서 99 사이의 정수 값입니다. 작은 값은 우선순위가 높습니다. 예를 들어 우선순위 10 은 우선순위 99 보다 높습니다. 기본값은 99 입니다.
6
선택사항: 가상 기능의 최대 전송 단위(MTU)입니다. 최대 MTU 값은 네트워크 인터페이스 컨트롤러(NIC) 모델마다 다를 수 있습니다.
7
선택 사항: Pod에 /dev/vhost-net 장치를 마운트하려면 needVhostNettrue 로 설정합니다. DPDK(Data Plane Development Kit)와 함께 마운트된 /dev/vhost-net 장치를 사용하여 트래픽을 커널 네트워크 스택으로 전달합니다.
8
SR-IOV 물리적 네트워크 장치에 생성할 VF(가상 기능) 수입니다. Intel NIC(Network Interface Controller)의 경우 VF 수는 장치에서 지원하는 총 VF보다 클 수 없습니다. Mellanox NIC의 경우 VF 수는 128 보다 클 수 없습니다.
9
NIC 선택기는 Operator가 구성할 장치를 식별합니다. 모든 매개변수에 값을 지정할 필요는 없습니다. 실수로 장치를 선택하지 않도록 네트워크 장치를 정확하게 파악하는 것이 좋습니다.

rootDevices 를 지정하는 경우 공급 업체,deviceID 또는 pfNames 의 값도 지정해야 합니다. pfNamesrootDevices 를 동시에 지정하는 경우 동일한 장치를 참조하는지 확인하십시오. netFilter 의 값을 지정하는 경우 네트워크 ID가 고유하므로 다른 매개변수를 지정할 필요가 없습니다.

10
선택 사항: SR-IOV 네트워크 장치의 벤더 16진수 코드입니다. 허용되는 값은 808615b3 입니다.
11
선택사항: SR-IOV 네트워크 장치의 장치 16진수 코드입니다. 예를 들어 101b 는 Mellanox ConnectX-6 장치의 장치 ID입니다.
12
선택사항: 장치에 대해 하나 이상의 물리적 기능(PF) 이름으로 구성된 배열입니다.
13
선택 사항: 장치의 PF에 대해 하나 이상의 PCI 버스 주소로 구성된 배열입니다. 주소를 0000:02:00.1 형식으로 입력합니다.
14
선택 사항: 플랫폼별 네트워크 필터입니다. 지원되는 유일한 플랫폼은 RHOSP(Red Hat OpenStack Platform)입니다. 허용 가능한 값은 다음 형식을 사용합니다. openstack/NetworkID:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx. xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/var/config/openstack/latest/network_data.json 메타데이터 파일의 값으로 바꿉니다.
15
선택사항: 가상 기능의 드라이버 유형입니다. 허용되는 값은 netdevicevfio-pci 입니다. 기본값은 netdevice 입니다.

베어 메탈 노드에서 Mellanox NIC가 DPDK 모드에서 작동하려면 netdevice 드라이버 유형을 사용하고 isRdmatrue 로 설정합니다.

16
선택 사항: 원격 직접 메모리 액세스(RDMA) 모드를 활성화할지 여부를 구성합니다. 기본값은 false입니다.

isRdma 매개변수가 true 로 설정된 경우 RDMA 가능 VF를 일반 네트워크 장치로 계속 사용할 수 있습니다. 어느 모드에서나 장치를 사용할 수 있습니다.

Fast Datapath DPDK 애플리케이션과 함께 사용할 Mellanox NIC를 구성하려면 isRdmatrue 로 설정하고 추가로 needVhostNettrue 로 설정합니다.

17
선택사항: VF의 링크 유형입니다. 기본값은 이더넷의 eth 입니다. InfiniBand의 경우 이 값을 'ib'로 변경합니다.

linkTypeib 로 설정하면isRdma 는 SR-IOV Network Operator Webhook에서 자동으로 true 로 설정됩니다. linkTypeib 로 설정하면deviceTypevfio-pci 로 설정하지 않아야 합니다.

장치 플러그인에서 보고한 사용 가능한 장치가 잘못될 수 있으므로 SriovNetworkNodePolicy의 linkType을 'eth'로 설정하지 마십시오.

18
선택 사항: 하드웨어 오프로드를 활성화하려면 'eSwitchMode' 필드를 "switchdev" 로 설정해야 합니다.

23.4.1.1. SR-IOV 네트워크 노드 구성 예

다음 예제에서는 InfiniBand 장치의 구성을 설명합니다.

InfiniBand 장치의 구성 예

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: policy-ib-net-1
  namespace: openshift-sriov-network-operator
spec:
  resourceName: ibnic1
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  numVfs: 4
  nicSelector:
    vendor: "15b3"
    deviceID: "101b"
    rootDevices:
      - "0000:19:00.0"
  linkType: ib
  isRdma: true

다음 예제에서는 RHOSP 가상 머신의 SR-IOV 네트워크 장치에 대한 구성을 설명합니다.

가상 머신의 SR-IOV 장치 구성 예

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: policy-sriov-net-openstack-1
  namespace: openshift-sriov-network-operator
spec:
  resourceName: sriovnic1
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  numVfs: 1 1
  nicSelector:
    vendor: "15b3"
    deviceID: "101b"
    netFilter: "openstack/NetworkID:ea24bd04-8674-4f69-b0ee-fa0b3bd20509" 2

1
가상 머신에 대한 노드 네트워크 정책을 구성할 때 numVfs 필드는 항상 1 로 설정됩니다.
2
가상 머신이 RHOSP에 배포될 때 netFilter 필드는 네트워크 ID를 참조해야 합니다. netFilter 에 유효한 값은 SriovNetworkNodeState 오브젝트에서 사용할 수 있습니다.

23.4.1.2. SR-IOV 장치의 VF(가상 기능) 파티셔닝

경우에 따라 동일한 물리적 기능(PF)의 VF(가상 기능)를 여러 리소스 풀로 분할할 수 있습니다. 예를 들어 일부 VF를 기본 드라이버로 로드하고 나머지 VF를 vfio-pci 드라이버를 사용하여 로드할 수 있습니다. 이러한 배포에서 SriovNetworkNodePolicy CR(사용자 정의 리소스)의 pfNames 선택기를 사용하여 < pfname>#<first_vf>-<last_vf > 형식을 사용하여 풀의 VF 범위를 지정할 수 있습니다.

예를 들어 다음 YAML은 VF 2 에서 7 까지의 netpf0 인터페이스에 대한 선택기를 보여줍니다.

pfNames: ["netpf0#2-7"]
  • netpf0 은 PF 인터페이스 이름입니다.
  • 2 는 범위에 포함된 첫 번째 VF 인덱스(0 기반)입니다.
  • 7 은 범위에 포함된 마지막 VF 인덱스(0 기반)입니다.

다음 요구 사항이 충족되면 다른 정책 CR을 사용하여 동일한 PF에서 VF를 선택할 수 있습니다.

  • 동일한 PF를 선택하는 정책의 경우 numVfs 값이 동일해야 합니다.
  • VF 인덱스는 0 에서 < numVfs>-1 까지의 범위에 있어야 합니다. 예를 들어 numVfs8 로 설정된 정책이 있는 경우 < first_vf > 값은 0 보다 작아야 하며 < last_vf >는 7 보다 크지 않아야 합니다.
  • 다른 정책의 VF 범위는 겹치지 않아야 합니다.
  • &lt ;first_vf >는 < last_vf>보다 클 수 없습니다.

다음 예는 SR-IOV 장치의 NIC 파티셔닝을 보여줍니다.

정책 policy-net-1 은 기본 VF 드라이버와 PF net pf 0 의 VF 0을 포함하는 리소스 풀 net -1 을 정의합니다. 정책 policy-net-1-dpdkvfio VF 드라이버를 사용하여 PF netpf0 의 VF 8 에서 15 에 포함된 리소스 풀 net-1-dpdk 를 정의합니다.

정책 policy-net-1:

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: policy-net-1
  namespace: openshift-sriov-network-operator
spec:
  resourceName: net1
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  numVfs: 16
  nicSelector:
    pfNames: ["netpf0#0-0"]
  deviceType: netdevice

정책 policy-net-1-dpdk:

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: policy-net-1-dpdk
  namespace: openshift-sriov-network-operator
spec:
  resourceName: net1dpdk
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  numVfs: 16
  nicSelector:
    pfNames: ["netpf0#8-15"]
  deviceType: vfio-pci

인터페이스가 성공적으로 분할되었는지 확인

다음 명령을 실행하여 SR-IOV 장치의 VF(가상 기능)로 분할된 인터페이스가 있는지 확인합니다.

$ ip link show <interface> 1
1
& lt;interface >를 SR-IOV 장치의 VF로 파티셔닝할 때 지정한 인터페이스로 바꿉니다(예: ens3f 1).

출력 예

5: ens3f1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether 3c:fd:fe:d1:bc:01 brd ff:ff:ff:ff:ff:ff

vf 0     link/ether 5a:e7:88:25:ea:a0 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
vf 1     link/ether 3e:1d:36:d7:3d:49 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
vf 2     link/ether ce:09:56:97:df:f9 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
vf 3     link/ether 5e:91:cf:88:d1:38 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
vf 4     link/ether e6:06:a1:96:2f:de brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off

23.4.2. SR-IOV 네트워크 장치 구성

SR-IOV Network Operator는 SriovNetworkNodePolicy.sriovnetwork.openshift.io CustomResourceDefinition을 OpenShift Container Platform에 추가합니다. SriovNetworkNodePolicy CR(사용자 정의 리소스)을 만들어 SR-IOV 네트워크 장치를 구성할 수 있습니다.

참고

SriovNetworkNodePolicy 오브젝트에 지정된 구성을 적용하면 SR-IOV Operator가 노드를 비우고 경우에 따라 노드를 재부팅할 수 있습니다.

구성 변경 사항을 적용하는 데 몇 분이 걸릴 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있습니다.
  • SR-IOV Network Operator가 설치되어 있습니다.
  • 비운 노드에서 제거된 워크로드를 처리하기 위해 클러스터에 사용 가능한 노드가 충분합니다.
  • SR-IOV 네트워크 장치 구성에 대한 컨트롤 플레인 노드를 선택하지 않았습니다.

절차

  1. SriovNetworkNodePolicy 오브젝트를 생성한 다음 YAML을 < name>-sriov-node-network.yaml 파일에 저장합니다. < name& gt;을 이 구성의 이름으로 변경합니다.
  2. 선택 사항: SR-IOV 가능 클러스터 노드에 아직 레이블이 지정되지 않은 경우 SriovNetworkNodePolicy.Spec.NodeSelector 로 레이블을 지정합니다. 노드에 레이블을 지정하는 방법에 대한 자세한 내용은 "노드에서 라벨을 업데이트하는 방법"을 참조하십시오.
  3. SriovNetworkNodePolicy 오브젝트를 생성합니다.

    $ oc create -f <name>-sriov-node-network.yaml

    & lt;name& gt;은 이 구성의 이름을 지정합니다.

    구성 업데이트를 적용하면 sriov-network-operator 네임스페이스의 모든 Pod가 Running 상태로 전환됩니다.

  4. SR-IOV 네트워크 장치가 구성되어 있는지 확인하려면 다음 명령을 입력합니다. & lt;node_name >을 방금 구성한 SR-IOV 네트워크 장치가 있는 노드 이름으로 바꿉니다.

    $ oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name> -o jsonpath='{.status.syncStatus}'

23.4.3. SR-IOV 구성 문제 해결

SR-IOV 네트워크 장치를 구성하는 절차를 수행한 후 다음 섹션에서는 일부 오류 조건을 다룹니다.

노드 상태를 표시하려면 다음 명령을 실행합니다.

$ oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name>

여기서 < node_name >은 SR-IOV 네트워크 장치가 있는 노드의 이름을 지정합니다.

오류 출력 : 메모리를 할당할 수 없음

"lastSyncError": "write /sys/bus/pci/devices/0000:3b:00.1/sriov_numvfs: cannot allocate memory"

노드가 메모리를 할당할 수 없음을 나타내는 경우 다음 항목을 확인합니다.

  • 글로벌 SR-IOV 설정이 노드의 BIOS에서 활성화되어 있는지 확인합니다.
  • BIOS에서 노드에 대해 VT-d가 활성화되어 있는지 확인합니다.

23.4.4. SR-IOV 네트워크를 VRF에 할당

클러스터 관리자는 CNI VRF 플러그인을 사용하여 SR-IOV 네트워크 인터페이스를 VRF 도메인에 할당할 수 있습니다.

이렇게 하려면 SriovNetwork 리소스의 선택적 metaPlugins 매개변수에 VRF 구성을 추가합니다.

참고

VRF를 사용하는 애플리케이션은 특정 장치에 바인딩해야 합니다. 일반적인 사용은 소켓에 SO_BINDTODEVICE 옵션을 사용하는 것입니다. SO_BINDTODEVICE 는 소켓을 전달된 인터페이스 이름(예: eth 1)에 지정된 장치에 바인딩합니다. SO_BINDTODEVICE 를 사용하려면 애플리케이션에 CAP_NET_RAW 기능이 있어야 합니다.

OpenShift Container Platform Pod에서는 ip vrf exec 명령을 통해 VRF를 사용할 수 없습니다. VRF를 사용하려면 애플리케이션을 VRF 인터페이스에 직접 바인딩합니다.

23.4.4.1. CNI VRF 플러그인으로 추가 SR-IOV 네트워크 연결 생성

SR-IOV Network Operator는 추가 네트워크 정의를 관리합니다. 생성할 추가 SR-IOV 네트워크를 지정하면 SR-IOV Network Operator가 NetworkAttachmentDefinition CR(사용자 정의 리소스)을 자동으로 생성합니다.

참고

SR-IOV Network Operator가 관리하는 NetworkAttachmentDefinition 사용자 정의 리소스를 편집하지 마십시오. 편집하면 추가 네트워크의 네트워크 트래픽이 중단될 수 있습니다.

CNI VRF 플러그인으로 추가 SR-IOV 네트워크 연결을 생성하려면 다음 절차를 수행합니다.

사전 요구 사항

  • OpenShift Container Platform CLI, oc를 설치합니다.
  • cluster-admin 역할의 사용자로 OpenShift Container Platform 클러스터에 로그인합니다.

절차

  1. 추가 SR-IOV 네트워크 연결에 대한 SriovNetwork CR(사용자 정의 리소스)을 생성하고 다음 예제 CR과 같이 metaPlugins 구성을 삽입합니다. YAML을 sriov-network-attachment.yaml 파일로 저장합니다.

    apiVersion: sriovnetwork.openshift.io/v1
    kind: SriovNetwork
    metadata:
      name: example-network
      namespace: additional-sriov-network-1
    spec:
      ipam: |
        {
          "type": "host-local",
          "subnet": "10.56.217.0/24",
          "rangeStart": "10.56.217.171",
          "rangeEnd": "10.56.217.181",
          "routes": [{
            "dst": "0.0.0.0/0"
          }],
          "gateway": "10.56.217.1"
        }
      vlan: 0
      resourceName: intelnics
      metaPlugins : |
        {
          "type": "vrf", 1
          "vrfname": "example-vrf-name" 2
        }
    1
    typevrf 로 설정해야 합니다.
    2
    vrfname 은 인터페이스가 할당된 VRF의 이름입니다. 포드에 없는 경우 생성됩니다.
  2. SriovNetwork 리소스를 생성합니다.

    $ oc create -f sriov-network-attachment.yaml

NetworkAttachmentDefinition CR이 성공적으로 생성되었는지 확인합니다.

  • SR-IOV Network Operator가 다음 명령을 실행하여 NetworkAttachmentDefinition CR을 생성했는지 확인합니다.

    $ oc get network-attachment-definitions -n <namespace> 1
    1
    & lt;namespace >를 네트워크 연결을 구성할 때 지정한 네임스페이스(예: additional-sriov-network-1) 로 바꿉니다.

    출력 예

    NAME                            AGE
    additional-sriov-network-1      14m

    참고

    SR-IOV Network Operator가 CR을 생성하기 전에 지연이 발생할 수 있습니다.

추가 SR-IOV 네트워크 연결에 성공했는지 확인

VRF CNI가 올바르게 구성되어 추가 SR-IOV 네트워크 연결이 연결되었는지 확인하려면 다음을 수행하십시오.

  1. VRF CNI를 사용하는 SR-IOV 네트워크를 생성합니다.
  2. 포드에 네트워크를 할당합니다.
  3. 포드 네트워크 연결이 SR-IOV 추가 네트워크에 연결되어 있는지 확인합니다. Pod로 원격 쉘을 설치하고 다음 명령을 실행합니다.

    $ ip vrf show

    출력 예

    Name              Table
    -----------------------
    red                 10

  4. VRF 인터페이스가 보조 인터페이스의 마스터인지 확인합니다.

    $ ip link

    출력 예

    ...
    5: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master red state UP mode
    ...

23.4.5. 다음 단계