검색

23.12. 하드웨어 오프로드 구성

download PDF

클러스터 관리자는 호환 노드에서 하드웨어 오프로드를 구성하여 데이터 처리 성능을 향상시키고 호스트 CPU의 부하를 줄일 수 있습니다.

23.12.1. 하드웨어 오프로드 정보

Open vSwitch 하드웨어 오프로드는 CPU에서 벗어나 네트워크 인터페이스 컨트롤러의 전용 프로세서로 오프로드하여 네트워크 작업을 처리하는 방법입니다. 이로 인해 클러스터는 데이터 전송 속도가 빨라지고 CPU 워크로드를 줄이며 컴퓨팅 비용을 절감할 수 있습니다.

이 기능의 주요 요소는 SmartNICs로 알려진 네트워크 인터페이스 컨트롤러의 최신 클래스입니다. SmartNIC는 computingly-heavy 네트워크 처리 작업을 처리할 수 있는 네트워크 인터페이스 컨트롤러입니다. 전용 그래픽 카드가 그래픽 성능을 향상시킬 수 있는 방식과 마찬가지로 SmartNIC는 네트워크 성능을 향상시킬 수 있습니다. 각 경우에서 전용 프로세서는 특정 유형의 처리 작업에 대한 성능을 향상시킵니다.

OpenShift Container Platform에서는 호환되는 SmartNIC가 있는 베어 메탈 노드에 대한 하드웨어 오프로드를 구성할 수 있습니다. 하드웨어 오프로드는 SR-IOV Network Operator에 의해 구성 및 활성화됩니다.

하드웨어 오프로드는 모든 워크로드 또는 애플리케이션 유형과 호환되지 않습니다. 다음 두 가지 통신 유형만 지원됩니다.

  • pod-to-pod
  • pod-to-service, 여기서 서비스는 일반 Pod에서 지원하는 ClusterIP 서비스

모든 경우에서 호환되는 SmartNIC이 있는 노드에 해당 Pod 및 서비스가 할당된 경우에만 하드웨어 오프로드가 수행됩니다. 예를 들어 하드웨어 오프로드가 있는 노드의 Pod가 일반 노드의 서비스와 통신하려고 한다고 가정합니다. 일반 노드에서 모든 처리가 커널에서 수행되므로 pod-to-service 통신의 전반적인 성능은 해당 일반 노드의 최대 성능으로 제한됩니다. 하드웨어 오프로드는 DPDK 애플리케이션과 호환되지 않습니다.

23.12.2. 지원되는 장치

하드웨어 오프로드는 다음 네트워크 인터페이스 컨트롤러에서 지원됩니다.

표 23.15. 지원되는 네트워크 인터페이스 컨트롤러
제조업체모델벤더 ID장치 ID

Mellanox

MT27800 제품군 [ConnectX-5]

15b3

1017

Mellanox

MT28880 제품군 [ConnectX-5 Ex]

15b3

1019

표 23.16. 기술 프리뷰 네트워크 인터페이스 컨트롤러
제조업체모델벤더 ID장치 ID

Mellanox

MT2892 제품군 [ConnectX-6 Dx]

15b3

101d

Mellanox

MT2894 제품군 [ConnectX-6 Lx]

15b3

101f

Mellanox

MT42822 ConnectX-6 NIC 모드 BlueField-2

15b3

a2d6

중요

ConnectX-6 NIC 모드 장치에서 ConnectX-6 Lx 또는 BlueField-2를 사용하는 것은 기술 프리뷰 기능입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

23.12.3. 사전 요구 사항

23.12.4. 하드웨어 오프로드를 위한 머신 구성 풀 구성

하드웨어 오프로드를 활성화하려면 먼저 전용 머신 구성 풀을 생성하고 SR-IOV Network Operator에서 작동하도록 구성해야 합니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있습니다.

절차

  1. 하드웨어 오프로드를 사용하려는 머신의 머신 구성 풀을 생성합니다.

    1. 다음 예와 같은 내용을 사용하여 mcp-offloading.yaml 과 같은 파일을 생성합니다.

      apiVersion: machineconfiguration.openshift.io/v1
      kind: MachineConfigPool
      metadata:
        name: mcp-offloading 1
      spec:
        machineConfigSelector:
          matchExpressions:
            - {key: machineconfiguration.openshift.io/role, operator: In, values: [worker,mcp-offloading]} 2
        nodeSelector:
          matchLabels:
            node-role.kubernetes.io/mcp-offloading: "" 3
      1 2
      하드웨어 오프로드를 위한 머신 구성 풀의 이름입니다.
      3
      이 노드 역할 레이블은 머신 구성 풀에 노드를 추가하는 데 사용됩니다.
    2. 머신 구성 풀의 구성을 적용합니다.

      $ oc create -f mcp-offloading.yaml
  2. 머신 구성 풀에 노드를 추가합니다. 각 노드에 풀의 노드 역할 레이블을 지정합니다.

    $ oc label node worker-2 node-role.kubernetes.io/mcp-offloading=""
  3. 선택 사항: 새 풀이 생성되었는지 확인하려면 다음 명령을 실행합니다.

    $ oc get nodes

    출력 예

    NAME       STATUS   ROLES                   AGE   VERSION
    master-0   Ready    master                  2d    v1.25.0
    master-1   Ready    master                  2d    v1.25.0
    master-2   Ready    master                  2d    v1.25.0
    worker-0   Ready    worker                  2d    v1.25.0
    worker-1   Ready    worker                  2d    v1.25.0
    worker-2   Ready    mcp-offloading,worker   47h   v1.25.0
    worker-3   Ready    mcp-offloading,worker   47h   v1.25.0

  4. SriovNetworkPoolConfig 사용자 정의 리소스에 이 머신 구성 풀을 추가합니다.

    1. 다음 예와 같은 내용으로 sriov-pool-config.yaml 과 같은 파일을 생성합니다.

      apiVersion: sriovnetwork.openshift.io/v1
      kind: SriovNetworkPoolConfig
      metadata:
        name: sriovnetworkpoolconfig-offload
        namespace: openshift-sriov-network-operator
      spec:
        ovsHardwareOffloadConfig:
          name: mcp-offloading 1
      1
      하드웨어 오프로드를 위한 머신 구성 풀의 이름입니다.
    2. 설정을 적용합니다.

      $ oc create -f <SriovNetworkPoolConfig_name>.yaml
      참고

      SriovNetworkPoolConfig 오브젝트에 지정된 구성을 적용하면 SR-IOV Operator가 드레이닝하고 머신 구성 풀의 노드를 다시 시작합니다.

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

23.12.5. SR-IOV 네트워크 노드 정책 구성

SR-IOV 네트워크 노드 정책을 생성하여 노드의 SR-IOV 네트워크 장치 구성을 생성할 수 있습니다. 하드웨어 오프로드를 활성화하려면 .spec.eSwitchMode 필드를 "switchdev" 값으로 정의해야 합니다.

다음 절차에서는 하드웨어 오프로드가 있는 네트워크 인터페이스 컨트롤러에 대한 SR-IOV 인터페이스를 생성합니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있습니다.

절차

  1. 다음 예와 같은 콘텐츠를 사용하여 sriov-node-policy.yaml 과 같은 파일을 생성합니다.

    apiVersion: sriovnetwork.openshift.io/v1
    kind: SriovNetworkNodePolicy
    metadata:
      name: sriov-node-policy <.>
      namespace: openshift-sriov-network-operator
    spec:
      deviceType: netdevice <.>
      eSwitchMode: "switchdev" <.>
      nicSelector:
        deviceID: "1019"
        rootDevices:
        - 0000:d8:00.0
        vendor: "15b3"
        pfNames:
        - ens8f0
      nodeSelector:
        feature.node.kubernetes.io/network-sriov.capable: "true"
      numVfs: 6
      priority: 5
      resourceName: mlxnics

    <.> 사용자 정의 리소스 오브젝트의 이름입니다. <.> Required. vfio-pci. <.> 필요에서는 하드웨어 오프로드가 지원되지 않습니다.

  2. 정책에 대한 구성을 적용합니다.

    $ oc create -f sriov-node-policy.yaml
    참고

    SriovNetworkPoolConfig 오브젝트에 지정된 구성을 적용하면 SR-IOV Operator가 드레이닝하고 머신 구성 풀의 노드를 다시 시작합니다.

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

23.12.5.1. OpenStack의 SR-IOV 네트워크 노드 정책 예

다음 예제에서는 RHOSP(Red Hat OpenStack Platform)에서 하드웨어 오프로드가 있는 NIC(네트워크 인터페이스 컨트롤러)의 SR-IOV 인터페이스를 설명합니다.

RHOSP에서 하드웨어 오프로드가 있는 NIC의 SR-IOV 인터페이스

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: ${name}
  namespace: openshift-sriov-network-operator
spec:
  deviceType: switchdev
  isRdma: true
  nicSelector:
    netFilter: openstack/NetworkID:${net_id}
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: 'true'
  numVfs: 1
  priority: 99
  resourceName: ${name}

23.12.6. 네트워크 연결 정의 생성

머신 구성 풀 및 SR-IOV 네트워크 노드 정책을 정의한 후 지정한 네트워크 인터페이스 카드에 대한 네트워크 연결 정의를 생성할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있습니다.

절차

  1. 다음 예와 같은 콘텐츠를 사용하여 net-attach-def.yaml 과 같은 파일을 생성합니다.

    apiVersion: "k8s.cni.cncf.io/v1"
    kind: NetworkAttachmentDefinition
    metadata:
      name: net-attach-def <.>
      namespace: net-attach-def <.>
      annotations:
        v1.multus-cni.io/default-network: openshift.io/mlxnics <.>
    spec:
      config: '{"cniVersion":"0.3.1","name":"ovn-kubernetes","type":"ovn-k8s-cni-overlay","ipam":{},"dns":{}}'

    <.> 네트워크 연결 정의의 이름입니다. <.> 네트워크 연결 정의의 네임스페이스입니다. <.> SriovNetworkNodePolicy 오브젝트에 지정한 spec.resourceName 필드의 값입니다.

  2. 네트워크 연결 정의에 대한 구성을 적용합니다.

    $ oc create -f net-attach-def.yaml

검증

  • 다음 명령을 실행하여 새 정의가 있는지 확인합니다.

    $ oc get net-attach-def -A

    출력 예

    NAMESPACE         NAME             AGE
    net-attach-def    net-attach-def   43h

23.12.7. Pod에 네트워크 연결 정의 추가

머신 구성 풀, SriovNetworkPoolConfigSriovNetworkNodePolicy 사용자 정의 리소스 및 네트워크 연결 정의를 생성한 후 Pod 사양에 네트워크 연결 정의를 추가하여 Pod에 이러한 구성을 적용할 수 있습니다.

절차

  • Pod 사양에서 .metadata.annotations.k8s.v1.cni.cncf.io/networks 필드를 추가하고 하드웨어 오프로드를 위해 생성한 네트워크 연결 정의를 지정합니다.

    ....
    metadata:
      annotations:
        k8s.v1.cni.cncf.io/default-network: net-attach-def/net-attach-def <.>

    <.> 값은 하드웨어 오프로드를 위해 생성한 네트워크 연결 정의의 이름과 네임스페이스여야 합니다.

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.