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

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

다음 문서에서 작업을 수행하기 전에 SR-IOV Network Operator를 설치 했는지 확인합니다.

18.2.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
  externallyManaged: false 9
  nicSelector: 10
    vendor: "<vendor_code>" 11
    deviceID: "<device_id>" 12
    pfNames: ["<pf_name>", ...] 13
    rootDevices: ["<pci_bus_id>", ...] 14
    netFilter: "<filter_string>" 15
  deviceType: <device_type> 16
  isRdma: false 17
  linkType: <link_type> 18
  eSwitchMode: "switchdev" 19
  excludeTopology: false 20

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) 플러그인 및 장치 플러그인은 선택한 노드에만 배포됩니다.

중요

SR-IOV Network Operator는 노드 네트워크 구성 정책을 순서대로 노드에 적용합니다. 노드 네트워크 구성 정책을 적용하기 전에 SR-IOV Network Operator는 노드의 MCP(Machine config pool)가 Degraded 또는 Update와 같은 비정상적인 상태에 있는지 확인합니다. 노드가 비정상 MCP에 있는 경우 MCP가 정상 상태로 돌아올 때까지 클러스터의 모든 대상 노드에 노드 네트워크 구성 정책을 적용하는 프로세스입니다.

비정상 MCP의 노드가 다른 MCP의 노드를 포함하여 다른 노드에 대한 노드 네트워크 구성 정책의 애플리케이션을 차단하지 않도록 하려면 각 MCP에 대한 별도의 노드 네트워크 구성 정책을 생성해야 합니다.

5

선택 사항: 우선순위는 0에서 99 사이의 정수 값입니다. 작은 값은 우선순위가 높습니다. 예를 들어 우선순위 10은 우선순위 99보다 높습니다. 기본값은 99입니다.

6

선택 사항: 물리적 기능의 최대 전송 단위(MTU) 및 모든 가상 기능입니다. 최대 MTU 값은 네트워크 인터페이스 컨트롤러(NIC) 모델마다 다를 수 있습니다.

중요

기본 네트워크 인터페이스에서 가상 기능을 생성하려면 MTU가 클러스터 MTU와 일치하는 값으로 설정되어 있는지 확인합니다.

함수가 pod에 할당되는 동안 단일 가상 기능의 MTU를 수정하려면 SR-IOV 네트워크 노드 정책에 MTU 값을 비워 둡니다. 그렇지 않으면 SR-IOV Network Operator에서 가상 기능의 MTU를 SR-IOV 네트워크 노드 정책에 정의된 MTU 값으로 되돌립니다. 이로 인해 노드 드레이닝이 트리거될 수 있습니다.

7

선택 사항: pod에 /dev/vhost-net 장치를 마운트하려면 needVhostNet을 true로 설정합니다. DPDK(Data Plane Development Kit)와 함께 마운트된 /dev/vhost-net 장치를 사용하여 트래픽을 커널 네트워크 스택으로 전달합니다.

8

SR-IOV 물리적 네트워크 장치에 생성할 VF(가상 기능) 수입니다. Intel NIC(Network Interface Controller)의 경우 VF 수는 장치에서 지원하는 총 VF보다 클 수 없습니다. Mellanox NIC의 경우 VF 수는 127 보다 클 수 없습니다.

9

external Managed 필드는 SR-IOV Network Operator가 모두 관리되는지 또는 VF(가상 기능) 서브 세트만 관리하는지 여부를 나타냅니다. 값을 false 로 설정하면 SR-IOV Network Operator가 PF의 모든 VF를 관리하고 구성합니다.

참고

external Managed 가 true 로 설정된 경우 SriovNetworkNodePolicy 리소스를 적용하기 전에 PF(가상 기능)에 VF(가상 기능)를 수동으로 생성해야 합니다. VF가 사전 생성되지 않은 경우 SR-IOV Network Operator의 Webhook에서 정책 요청을 차단합니다.

external Managed 가 false 로 설정되면 SR-IOV Network Operator가 필요한 경우 재설정을 포함하여 VF를 자동으로 생성하고 관리합니다.

호스트 시스템에서 VF를 사용하려면 NMState를 통해 생성하고 external Managed를 true 로 설정해야 합니다. 이 모드에서 SR-IOV Network Operator는 정책의 nicSelector 필드에 명시적으로 정의된 PF 또는 수동으로 관리되는 VF를 수정하지 않습니다. 그러나 SR-IOV Network Operator는 Pod 보조 인터페이스로 사용되는 VF를 계속 관리합니다.

10

NIC 선택기는 이 리소스가 적용되는 장치를 식별합니다. 모든 매개변수에 값을 지정할 필요는 없습니다. 실수로 장치를 선택하지 않도록 네트워크 장치를 정확하게 파악하는 것이 좋습니다.

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

11

선택사항: SR-IOV 네트워크 장치의 벤더 16진수 벤더 식별자입니다. 허용되는 값은 8086 (Intel) 및 15b3 (M#159nox)입니다.

12

선택사항: SR-IOV 네트워크 장치의 장치 16진수 장치 식별자입니다. 예를 들어 101b는 Mellanox ConnectX-6 장치의 장치 ID입니다.

13

선택 사항: 리소스가 적용해야 하는 하나 이상의 물리적 기능(PF) 이름으로 구성된 배열입니다.

14

선택 사항: 리소스가 적용해야 하는 하나 이상의 PCI 버스 주소로 구성된 배열입니다. 예: 0000:02:00.1.

15

선택 사항: 플랫폼별 네트워크 필터입니다. 지원되는 유일한 플랫폼은 RHOSP(Red Hat OpenStack Platform)입니다. 허용 가능한 값은 다음 형식을 사용합니다. openstack/NetworkID:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx. xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx를 /var/config/openstack/latest/network_data.json 메타데이터 파일의 값으로 바꿉니다. 이 필터를 사용하면 VF가 특정 OpenStack 네트워크와 연결되어 있습니다. Operator는 이 필터를 사용하여 OpenStack 플랫폼에서 제공하는 메타데이터를 기반으로 VF를 적절한 네트워크에 매핑합니다.

16

선택사항: 이 리소스에서 생성된 VF에 대해 구성할 드라이버입니다. 허용되는 값은 netdevice 및 vfio-pci입니다. 기본값은 netdevice입니다.

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

17

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

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

isRdma를 true로 설정하고 추가로 needVhostNet을 true로 설정하여 Fast Datapath DPDK 애플리케이션에서 사용할 Mellanox NIC를 구성합니다.

참고

intel NIC의 경우 isRdma 매개변수를 true 로 설정할 수 없습니다.

18

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

linkType을 ib로 설정하면 isRdma가 SR-IOV Network Operator 웹 후크에 의해 자동으로 true로 설정됩니다. linkType을 ib로 설정하면 deviceType을 vfio-pci로 설정해서는 안 됩니다.

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

19

선택 사항: 하드웨어 오프로드를 활성화하려면 eSwitchMode 필드를 "switchdev" 로 설정해야 합니다. 하드웨어 오프로드에 대한 자세한 내용은 "하드웨어 오프로드 구성"을 참조하십시오.

20

선택 사항: SR-IOV 네트워크 리소스의 NUMA 노드를 토폴로지 관리자로 알리려면 값을 true 로 설정합니다. 기본값은 false입니다.

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

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

InfiniBand 장치의 구성 예

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: <name>
  namespace: openshift-sriov-network-operator
spec:
  resourceName: <sriov_resource_name>
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  numVfs: <num>
  nicSelector:
    vendor: "<vendor_code>"
    deviceID: "<device_id>"
    rootDevices:
      - "<pci_bus_id>"
  linkType: <link_type>
  isRdma: true
# ...

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

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

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: <name>
  namespace: openshift-sriov-network-operator
spec:
  resourceName: <sriov_resource_name>
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  numVfs: 1 1
  nicSelector:
    vendor: "<vendor_code>"
    deviceID: "<device_id>"
    netFilter: "openstack/NetworkID:ea24bd04-8674-4f69-b0ee-fa0b3bd20509" 2
# ...

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

18.2.1.2. SR-IOV 네트워크 장치의 자동 검색

SR-IOV Network Operator는 작업자 노드에서 SR-IOV 가능 네트워크 장치를 클러스터에서 검색합니다. Operator는 호환되는 SR-IOV 네트워크 장치를 제공하는 각 작업자 노드에 대해 SriovNetworkNodeState CR(사용자 정의 리소스)을 생성하고 업데이트합니다.

CR에는 작업자 노드와 동일한 이름이 할당됩니다. status.interfaces 목록은 노드의 네트워크 장치에 대한 정보를 제공합니다.

중요

SriovNetworkNodeState 오브젝트를 수정하지 마십시오. Operator는 이러한 리소스를 자동으로 생성하고 관리합니다.

18.2.1.2.1. SriovNetworkNodeState 오브젝트의 예

다음 YAML은 SR-IOV Network Operator가 생성한 SriovNetworkNodeState 오브젝트의 예입니다.

SriovNetworkNodeState 오브젝트

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodeState
metadata:
  name: node-25 1
  namespace: openshift-sriov-network-operator
  ownerReferences:
  - apiVersion: sriovnetwork.openshift.io/v1
    blockOwnerDeletion: true
    controller: true
    kind: SriovNetworkNodePolicy
    name: default
spec:
  dpConfigVersion: "39824"
status:
  interfaces: 2
  - deviceID: "1017"
    driver: mlx5_core
    mtu: 1500
    name: ens785f0
    pciAddress: "0000:18:00.0"
    totalvfs: 8
    vendor: 15b3
  - deviceID: "1017"
    driver: mlx5_core
    mtu: 1500
    name: ens785f1
    pciAddress: "0000:18:00.1"
    totalvfs: 8
    vendor: 15b3
  - deviceID: 158b
    driver: i40e
    mtu: 1500
    name: ens817f0
    pciAddress: 0000:81:00.0
    totalvfs: 64
    vendor: "8086"
  - deviceID: 158b
    driver: i40e
    mtu: 1500
    name: ens817f1
    pciAddress: 0000:81:00.1
    totalvfs: 64
    vendor: "8086"
  - deviceID: 158b
    driver: i40e
    mtu: 1500
    name: ens803f0
    pciAddress: 0000:86:00.0
    totalvfs: 64
    vendor: "8086"
  syncStatus: Succeeded

1: name 필드의 값은 작업자 노드의 이름과 동일합니다.
2: 인터페이스 스탠자에는 작업자 노드에서 Operator가 감지한 모든 SR-IOV 장치 목록이 포함되어 있습니다.

18.2.1.3. 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까지의 범위 내에 있어야 합니다. 예를 들어, numVfs가 8로 설정된 정책이 있는 경우 <first_vf> 값은 0보다 작아야 하며 <last_vf>는 7보다 크지 않아야 합니다.
다른 정책의 VF 범위는 겹치지 않아야 합니다.
<first_vf>는 <last_vf>보다 클 수 없습니다.

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

정책 policy-net-1은 기본 VF 드라이버와 함께 PF netpf0의 VF 0을 포함하는 리소스 풀 net-1을 정의합니다. 정책 policy-net-1-dpdk는 vfio 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로 분할할 때 지정한 인터페이스로 바꿉니다(예: ens3f1 ).

출력 예

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

18.2.1.4. OpenStack에서 SR-IOV를 사용하는 클러스터의 테스트 Pod 템플릿

다음 testpmd Pod는 대규모 페이지, 예약된 CPU 및 SR-IOV 포트로 컨테이너 생성을 보여줍니다.

testpmd Pod의 예

apiVersion: v1
kind: Pod
metadata:
  name: testpmd-sriov
  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/sriov1: 1
      limits:
        hugepages-1Gi: 1Gi
        cpu: '2'
        memory: 1000Mi
        openshift.io/sriov1: 1
    volumeMounts:
      - mountPath: /dev/hugepages
        name: hugepage
        readOnly: False
  runtimeClassName: performance-cnf-performanceprofile 1
  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages

1: 이 예에서는 성능 프로필의 이름이 cnf-performance 프로필 이라고 가정합니다.

18.2.1.5. 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 프로필 로 지정되지 않은 경우 해당 문자열을 올바른 성능 프로필 이름으로 교체합니다.

18.2.1.6. Downward API 에 대한 대규보 페이지 리소스 주입

Pod 사양에 대규모 페이지에 대한 리소스 요청 또는 제한이 포함된 경우 Network Resources Injector는 컨테이너에 대규모 페이지 정보를 제공하기 위해 Pod 사양에 Downward API 필드를 자동으로 추가합니다.

Network Resources Injector는 podnetinfo라는 볼륨을 추가하고 Pod의 각 컨테이너에 대해 /etc/podnetinfo에 마운트됩니다. 볼륨은 Downward API를 사용하며 대규모 페이지 요청 및 제한에 대한 파일을 포함합니다. 파일 이름 지정 규칙은 다음과 같습니다.

/etc/podnetinfo/hugepages_1G_request_<container-name>
/etc/podnetinfo/hugepages_1G_limit_<container-name>
/etc/podnetinfo/hugepages_2M_request_<container-name>
/etc/podnetinfo/hugepages_2M_limit_<container-name>

이전 목록에 지정된 경로는 app-netutil 라이브러리와 호환됩니다. 기본적으로 라이브러리는 /etc/podnetinfo 디렉터리에서 리소스 정보를 검색하도록 구성됩니다. Downward API 경로 항목을 수동으로 지정하도록 선택하는 경우 app-netutil 라이브러리는 이전 목록의 경로 외에도 다음 경로를 검색합니다.

/etc/podnetinfo/hugepages_request
/etc/podnetinfo/hugepages_limit
/etc/podnetinfo/hugepages_1G_request
/etc/podnetinfo/hugepages_1G_limit
/etc/podnetinfo/hugepages_2M_request
/etc/podnetinfo/hugepages_2M_limit

Network Resources Injector에서 생성할 수 있는 경로와 마찬가지로, 이전 목록의 경로는 선택적으로 _<container-name> 접미사로 종료할 수 있습니다.

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

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

참고

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

Mellanox NIC(mlx5 드라이버)를 사용하면 물리적 기능(PF)에서 VF(가상 기능) 수가 증가할 때마다 노드 재부팅이 수행됩니다.
Intel NIC를 사용하면 커널 매개변수에 intel_iommu=on 및 iommu=pt 가 포함되지 않은 경우에만 재부팅이 수행됩니다.

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

사전 요구 사항

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

절차

SriovNetworkNodePolicy 오브젝트를 생성한 후 YAML을 <name>-sriov-node-network.yaml 파일에 저장합니다. <name>을 이 구성의 이름으로 바꿉니다.
선택 사항: SriovNetworkNodePolicy.Spec.NodeSelector 를 사용하여 SR-IOV 가능 클러스터 노드에 레이블을 지정하지 않은 경우 레이블을 지정합니다. 노드 레이블 지정에 대한 자세한 내용은 "노드에서 라벨을 업데이트하는 방법 이해"를 참조하십시오.
SriovNetworkNodePolicy 오브젝트를 생성합니다.
```
$ oc create -f <name>-sriov-node-network.yaml
```
<name>은 이 구성의 이름을 지정합니다.
구성 업데이트를 적용하면 sriov-network-operator 네임스페이스의 모든 Pod가 Running 상태로 전환됩니다.
SR-IOV 네트워크 장치가 구성되어 있는지 확인하려면 다음 명령을 입력합니다. <node_name>을 방금 구성한 SR-IOV 네트워크 장치가 있는 노드 이름으로 바꿉니다.
```
$ oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name> -o jsonpath='{.status.syncStatus}'
```

추가 리소스

노드에서 라벨을 업데이트하는 방법 이해

18.2.3. NUMA(Non-Uniform Memory Access) 정렬 SR-IOV Pod 생성

SR-IOV 및 제한된 또는 single-numa-node 토폴로지 관리자 정책으로 동일한 NUMA 노드에서 할당된 CPU 리소스를 제한하여 NUMA 정렬 SR-IOV Pod를 생성할 수 있습니다.

사전 요구 사항

OpenShift CLI(oc)가 설치되어 있습니다.
CPU 관리자 정책을 static으로 구성했습니다. CPU 관리자에 대한 자세한 내용은 "추가 리소스" 섹션을 참조하십시오.
토폴로지 관리자 정책을 single-numa-node로 구성했습니다.
참고
single-numa-node가 요청을 충족할 수 없는 경우 Topology Manager 정책을 restricted로 구성할 수 있습니다. 보다 유연한 SR-IOV 네트워크 리소스 스케줄링은 추가 리소스 섹션에서 NUMA 인식 스케줄링 중 SR-IOV 네트워크 토폴로지 제외 를 참조하십시오.

절차

다음과 같은 SR-IOV Pod 사양을 생성한 다음 YAML을 <name>-sriov-pod.yaml 파일에 저장합니다. <name>을 이 Pod의 이름으로 바꿉니다.
다음 예는 SR-IOV Pod 사양을 보여줍니다.
```
apiVersion: v1
kind: Pod
metadata:
  name: sample-pod
  annotations:
    k8s.v1.cni.cncf.io/networks: <name> 1
spec:
  containers:
  - name: sample-container
    image: <image> 2
    command: ["sleep", "infinity"]
    resources:
      limits:
        memory: "1Gi" 3
        cpu: "2" 4
      requests:
        memory: "1Gi"
        cpu: "2"
```
1
<name>을 SR-IOV 네트워크 첨부 파일 정의 CR의 이름으로 바꿉니다.
2
<image>를 sample-pod 이미지의 이름으로 바꿉니다.
3
보장된 QoS로 SR-IOV Pod를 생성하려면 메모리 제한을 메모리 요청과 동일하게 설정합니다.
4
보장된 QoS로 SR-IOV Pod를 생성하려면 cpu 제한을 CPU 요청과 동일하게 설정합니다.
다음 명령을 실행하여 샘플 SR-IOV Pod를 만듭니다.
```
$ oc create -f <filename> 1
```
1
<filename>을 이전 단계에서 생성한 파일 이름으로 바꿉니다.
sample-pod가 보장된 QoS로 구성되어 있는지 확인하십시오.
```
$ oc describe pod sample-pod
```
sample-pod에 전용 CPU가 할당되어 있는지 확인하십시오.
```
$ oc exec sample-pod -- cat /sys/fs/cgroup/cpuset/cpuset.cpus
```
sample-pod에 할당된 SR-IOV 장치 및 CPU가 동일한 NUMA 노드에 있는지 확인하십시오.
```
$ oc exec sample-pod -- cat /sys/fs/cgroup/cpuset/cpuset.cpus
```

18.2.4. NUMA 인식 스케줄링의 SR-IOV 네트워크 토폴로지 제외

SR-IOV 네트워크의 NUMA(Non-Uniform Memory Access) 노드를 토폴로지 관리자에게 알리면 NUMA 인식 Pod 예약 중에 보다 유연한 SR-IOV 네트워크 배포를 제외할 수 있습니다.

일부 시나리오에서는 단일 NUMA 노드에서 Pod의 CPU 및 메모리 리소스를 최대화하는 것이 우선 순위입니다. 토폴로지 관리자는 Pod의 SR-IOV 네트워크 리소스에 대한 NUMA 노드에 대한 힌트를 제공하지 않기 때문에 토폴로지 관리자는 SR-IOV 네트워크 리소스 및 Pod CPU 및 메모리 리소스를 다른 NUMA 노드에 배포할 수 있습니다. NUMA 노드 간 데이터 전송으로 인해 네트워크 대기 시간에 추가할 수 있습니다. 그러나 워크로드에 최적의 CPU 및 메모리 성능이 필요한 경우에는 이 기능이 허용됩니다.

예를 들어 numa0 과 numa1 이라는 두 개의 NUMA 노드가 있는 컴퓨팅 노드인 compute-1 을 고려해 보십시오. SR-IOV 지원 NIC는 numa0 에 있습니다. Pod 예약에 사용 가능한 CPU는 numa1 에만 있습니다. Topology Manager는 excludeTopology 사양을 true 로 설정하여 Pod의 CPU 및 메모리 리소스를 numa1 에 할당할 수 있으며 동일한 pod의 SR-IOV 네트워크 리소스를 numa0 에 할당할 수 있습니다. 이는 excludeTopology 사양을 true 로 설정한 경우에만 가능합니다. 그렇지 않으면 토폴로지 관리자가 동일한 NUMA 노드에 모든 리소스를 배치하려고 합니다.

18.2.5. 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가 활성화되어 있는지 확인합니다.

추가 리소스

CPU 관리자 사용

18.2.6. 다음 단계

SR-IOV 네트워크 연결 구성