Red Hat Summit Red Hat Summit지원콘솔개발자평가판 시작연락처

확장 및 성능

OpenShift Container Platform 4.6

프로덕션 환경에서 OpenShift Container Platform 클러스터 스케일링 및 성능 튜닝

초록

이 문서에서는 OpenShift Container Platform 환경의 클러스터를 스케일링하고 성능을 최적화하는 방법을 설명합니다.

4장. Node Tuning Operator 사용

Node Tuning Operator에 대해 알아보고, Node Tuning Operator를 사용하여 Tuned 데몬을 오케스트레이션하고 노드 수준 튜닝을 관리하는 방법도 알아봅니다.

4.1. Node Tuning Operator 정보

Node Tuning Operator는 Tuned 데몬을 오케스트레이션하여 노드 수준 튜닝을 관리하는 데 도움이 됩니다. 대부분의 고성능 애플리케이션에는 일정 수준의 커널 튜닝이 필요합니다. Node Tuning Operator는 노드 수준 sysctls 사용자에게 통합 관리 인터페이스를 제공하며 사용자의 필요에 따라 지정되는 사용자 정의 튜닝을 추가할 수 있는 유연성을 제공합니다.

Operator는 OpenShift Container Platform의 컨테이너화된 Tuned 데몬을 Kubernetes 데몬 세트로 관리합니다. 클러스터에서 실행되는 모든 컨테이너화된 Tuned 데몬에 사용자 정의 튜닝 사양이 데몬이 이해할 수 있는 형식으로 전달되도록 합니다. 데몬은 클러스터의 모든 노드에서 노드당 하나씩 실행됩니다.

컨테이너화된 Tuned 데몬을 통해 적용되는 노드 수준 설정은 프로필 변경을 트리거하는 이벤트 시 또는 컨테이너화된 Tuned 데몬이 종료 신호를 수신하고 처리하여 정상적으로 종료될 때 롤백됩니다.

버전 4.1 이상에서는 Node Tuning Operator가 표준 OpenShift Container Platform 설치에 포함되어 있습니다.

4.2. Node Tuning Operator 사양 예에 액세스

이 프로세스를 사용하여 Node Tuning Operator 사양 예에 액세스하십시오.

프로세스

  1. 다음을 실행합니다. 

    $ oc get Tuned/default -o yaml -n openshift-cluster-node-tuning-operator

기본 CR은 OpenShift Container Platform 플랫폼의 표준 노드 수준 튜닝을 제공하기 위한 것이며 Operator 관리 상태를 설정하는 경우에만 수정할 수 있습니다. Operator는 기본 CR에 대한 다른 모든 사용자 정의 변경사항을 덮어씁니다. 사용자 정의 튜닝의 경우 고유한 Tuned CR을 생성합니다. 새로 생성된 CR은 노드 또는 Pod 라벨 및 프로필 우선 순위에 따라 OpenShift Container Platform 노드에 적용된 기본 CR 및 사용자 정의 튜닝과 결합됩니다.

주의

특정 상황에서는 Pod 라벨에 대한 지원이 필요한 튜닝을 자동으로 제공하는 편리한 방법일 수 있지만 이러한 방법은 권장되지 않으며 특히 대규모 클러스터에서는 이러한 방법을 사용하지 않는 것이 좋습니다. 기본 Tuned CR은 Pod 라벨이 일치되지 않은 상태로 제공됩니다. Pod 라벨이 일치된 상태로 사용자 정의 프로필이 생성되면 해당 시점에 이 기능이 활성화됩니다. Pod 레이블 기능은 Node Tuning Operator의 향후 버전에서 더 이상 사용되지 않을 수 있습니다.

4.3. 클러스터에 설정된 기본 프로필

다음은 클러스터에 설정된 기본 프로필입니다. 

apiVersion: tuned.openshift.io/v1
kind: Tuned
metadata:
  name: default
  namespace: openshift-cluster-node-tuning-operator
spec:
  profile:
  - name: "openshift"
    data: |
      [main]
      summary=Optimize systems running OpenShift (parent profile)
      include=${f:virt_check:virtual-guest:throughput-performance}

      [selinux]
      avc_cache_threshold=8192

      [net]
      nf_conntrack_hashsize=131072

      [sysctl]
      net.ipv4.ip_forward=1
      kernel.pid_max=>4194304
      net.netfilter.nf_conntrack_max=1048576
      net.ipv4.conf.all.arp_announce=2
      net.ipv4.neigh.default.gc_thresh1=8192
      net.ipv4.neigh.default.gc_thresh2=32768
      net.ipv4.neigh.default.gc_thresh3=65536
      net.ipv6.neigh.default.gc_thresh1=8192
      net.ipv6.neigh.default.gc_thresh2=32768
      net.ipv6.neigh.default.gc_thresh3=65536
      vm.max_map_count=262144

      [sysfs]
      /sys/module/nvme_core/parameters/io_timeout=4294967295
      /sys/module/nvme_core/parameters/max_retries=10

  - name: "openshift-control-plane"
    data: |
      [main]
      summary=Optimize systems running OpenShift control plane
      include=openshift

      [sysctl]
      # ktune sysctl settings, maximizing i/o throughput
      #
      # Minimal preemption granularity for CPU-bound tasks:
      # (default: 1 msec#  (1 + ilog(ncpus)), units: nanoseconds)
      kernel.sched_min_granularity_ns=10000000
      # The total time the scheduler will consider a migrated process
      # "cache hot" and thus less likely to be re-migrated
      # (system default is 500000, i.e. 0.5 ms)
      kernel.sched_migration_cost_ns=5000000
      # SCHED_OTHER wake-up granularity.
      #
      # Preemption granularity when tasks wake up.  Lower the value to
      # improve wake-up latency and throughput for latency critical tasks.
      kernel.sched_wakeup_granularity_ns=4000000

  - name: "openshift-node"
    data: |
      [main]
      summary=Optimize systems running OpenShift nodes
      include=openshift

      [sysctl]
      net.ipv4.tcp_fastopen=3
      fs.inotify.max_user_watches=65536
      fs.inotify.max_user_instances=8192

  recommend:
  - profile: "openshift-control-plane"
    priority: 30
    match:
    - label: "node-role.kubernetes.io/master"
    - label: "node-role.kubernetes.io/infra"

  - profile: "openshift-node"
    priority: 40

4.4. Tuned 프로필이 적용되었는지 검증

다음 절차를 통해 모든 노드에 Tuned 프로필이 적용되었는지 확인하십시오.

프로세스

  1. 각 노드에서 Tuned Pod가 실행되고 있는지 확인합니다. 

    $ oc get pods -n openshift-cluster-node-tuning-operator -o wide

    출력 예

    NAME                                            READY   STATUS    RESTARTS   AGE    IP             NODE                                         NOMINATED NODE   READINESS GATES
cluster-node-tuning-operator-599489d4f7-k4hw4   1/1     Running   0          6d2h   10.129.0.76    ip-10-0-145-113.eu-west-3.compute.internal   <none>           <none>
tuned-2jkzp                                     1/1     Running   1          6d3h   10.0.145.113   ip-10-0-145-113.eu-west-3.compute.internal   <none>           <none>
tuned-g9mkx                                     1/1     Running   1          6d3h   10.0.147.108   ip-10-0-147-108.eu-west-3.compute.internal   <none>           <none>
tuned-kbxsh                                     1/1     Running   1          6d3h   10.0.132.143   ip-10-0-132-143.eu-west-3.compute.internal   <none>           <none>
tuned-kn9x6                                     1/1     Running   1          6d3h   10.0.163.177   ip-10-0-163-177.eu-west-3.compute.internal   <none>           <none>
tuned-vvxwx                                     1/1     Running   1          6d3h   10.0.131.87    ip-10-0-131-87.eu-west-3.compute.internal    <none>           <none>
tuned-zqrwq                                     1/1     Running   1          6d3h   10.0.161.51    ip-10-0-161-51.eu-west-3.compute.internal    <none>           <none>

  2. 각 Pod에서 적용된 프로필을 추출하여 이전 목록과 대조합니다. 

    $ for p in `oc get pods -n openshift-cluster-node-tuning-operator -l openshift-app=tuned -o=jsonpath='{range .items[*]}{.metadata.name} {end}'`; do printf "\n*** $p ***\n" ; oc logs pod/$p -n openshift-cluster-node-tuning-operator | grep applied; done

    출력 예

    *** tuned-2jkzp ***
2020-07-10 13:53:35,368 INFO     tuned.daemon.daemon: static tuning from profile 'openshift-control-plane' applied

*** tuned-g9mkx ***
2020-07-10 14:07:17,089 INFO     tuned.daemon.daemon: static tuning from profile 'openshift-node' applied
2020-07-10 15:56:29,005 INFO     tuned.daemon.daemon: static tuning from profile 'openshift-node-es' applied
2020-07-10 16:00:19,006 INFO     tuned.daemon.daemon: static tuning from profile 'openshift-node' applied
2020-07-10 16:00:48,989 INFO     tuned.daemon.daemon: static tuning from profile 'openshift-node-es' applied

*** tuned-kbxsh ***
2020-07-10 13:53:30,565 INFO     tuned.daemon.daemon: static tuning from profile 'openshift-node' applied
2020-07-10 15:56:30,199 INFO     tuned.daemon.daemon: static tuning from profile 'openshift-node-es' applied

*** tuned-kn9x6 ***
2020-07-10 14:10:57,123 INFO     tuned.daemon.daemon: static tuning from profile 'openshift-node' applied
2020-07-10 15:56:28,757 INFO     tuned.daemon.daemon: static tuning from profile 'openshift-node-es' applied

*** tuned-vvxwx ***
2020-07-10 14:11:44,932 INFO     tuned.daemon.daemon: static tuning from profile 'openshift-control-plane' applied

*** tuned-zqrwq ***
2020-07-10 14:07:40,246 INFO     tuned.daemon.daemon: static tuning from profile 'openshift-control-plane' applied

4.5. 사용자 정의 튜닝 사양

Operator의 CR(사용자 정의 리소스)에는 두 가지 주요 섹션이 있습니다. 첫 번째 섹션인 profile:은 Tuned 프로필 및 해당 이름의 목록입니다. 두 번째인 recommend:은 프로필 선택 논리를 정의합니다.

여러 사용자 정의 튜닝 사양은 Operator의 네임스페이스에 여러 CR로 존재할 수 있습니다. 새로운 CR의 존재 또는 오래된 CR의 삭제는 Operator에서 탐지됩니다. 기존의 모든 사용자 정의 튜닝 사양이 병합되고 컨테이너화된 Tuned 데몬의 해당 오브젝트가 업데이트됩니다.

관리 상태

Operator 관리 상태는 기본 Tuned CR을 조정하여 설정됩니다. 기본적으로 Operator는 Managed 상태이며 기본 Tuned CR에는 spec.managementState 필드가 없습니다. Operator 관리 상태에 유효한 값은 다음과 같습니다.

  • Managed: 구성 리소스가 업데이트되면 Operator가 해당 피연산자를 업데이트합니다.
  • Unmanaged: Operator가 구성 리소스에 대한 변경을 무시합니다.
  • Removed: Operator가 프로비저닝한 해당 피연산자 및 리소스를 Operator가 제거합니다.

프로필 데이터

profile: 섹션에는 Tuned 프로필 및 해당 이름이 나열됩니다. 

profile:
- name: tuned_profile_1
  data: |
    # Tuned profile specification
    [main]
    summary=Description of tuned_profile_1 profile

    [sysctl]
    net.ipv4.ip_forward=1
    # ... other sysctl's or other Tuned daemon plugins supported by the containerized Tuned

# ...

- name: tuned_profile_n
  data: |
    # Tuned profile specification
    [main]
    summary=Description of tuned_profile_n profile

    # tuned_profile_n profile settings

권장 프로필

profile: 선택 논리는 CR의 recommend: 섹션에 의해 정의됩니다. recommend: 섹션은 선택 기준에 따라 프로필을 권장하는 항목의 목록입니다. 

recommend:
<recommend-item-1>
# ...
<recommend-item-n>

목록의 개별 항목은 다음과 같습니다. 

- machineConfigLabels: 1
    <mcLabels> 2
  match: 3
    <match> 4
  priority: <priority> 5
  profile: <tuned_profile_name> 6
1
선택 사항입니다.
2
키/값 MachineConfig 라벨 사전입니다. 키는 고유해야 합니다.
3
생략하면 우선 순위가 높은 프로필이 먼저 일치되거나 machineConfigLabels가 설정되어 있지 않으면 프로필이 일치하는 것으로 가정합니다.
4
선택사항 목록입니다.
5
프로필 순서 지정 우선 순위입니다. 숫자가 작을수록 우선 순위가 높습니다(0이 가장 높은 우선 순위임).
6
일치에 적용할 Tuned 프로필입니다. 예를 들어 tuned_profile_1이 있습니다.

<match>는 다음과 같이 재귀적으로 정의되는 선택사항 목록입니다. 

- label: <label_name> 1
  value: <label_value> 2
  type: <label_type> 3
    <match> 4
1
노드 또는 Pod 라벨 이름입니다.
2
선택사항 노드 또는 Pod 라벨 값입니다. 생략하면 <label_name>이 있기 때문에 일치 조건을 충족합니다.
3
선택사항 오브젝트 유형(node 또는 pod)입니다. 생략하면 node라고 가정합니다.
4
선택사항 <match> 목록입니다.

<match>를 생략하지 않으면 모든 중첩 <match> 섹션도 true로 평가되어야 합니다. 생략하면 false로 가정하고 해당 <match> 섹션이 있는 프로필을 적용하지 않거나 권장하지 않습니다. 따라서 중첩(하위 <match> 섹션)은 논리 AND 연산자 역할을 합니다. 반대로 <match> 목록의 항목이 일치하면 전체 <match> 목록이 true로 평가됩니다. 따라서 이 목록이 논리 OR 연산자 역할을 합니다.

machineConfigLabels 가 정의되면 지정된 recommend: 목록 항목에 대해 머신 구성 풀 기반 일치가 설정됩니다. <mcLabels> 는 머신 구성의 라벨을 지정합니다. 머신 구성은 <tuned_profile_name> 프로필에 대해 커널 부팅 매개변수와 같은 호스트 설정을 적용하기 위해 자동으로 생성됩니다. 여기에는 <mcLabels>와 일치하는 머신 구성 선택기가 있는 모든 머신 구성 풀을 찾고 머신 구성 풀이 할당된 모든 노드에서 <tuned_profile_name> 프로필을 설정하는 작업이 포함됩니다. 마스터 및 작업자 역할이 모두 있는 노드를 대상으로 하려면 마스터 역할을 사용해야 합니다.

목록 항목 match 및 machineConfigLabels는 논리 OR 연산자로 연결됩니다. match 항목은 단락 방식으로 먼저 평가됩니다. 따라서 true로 평가되면 machineConfigLabels 항목이 고려되지 않습니다.

중요

머신 구성 풀 기반 일치를 사용하는 경우 동일한 하드웨어 구성을 가진 노드를 동일한 머신 구성 풀로 그룹화하는 것이 좋습니다. 이 방법을 따르지 않으면 Tuned 피연산자가 동일한 머신 구성 풀을 공유하는 두 개 이상의 노드에 대해 충돌하는 커널 매개변수를 계산할 수 있습니다.

예: 노드 또는 Pod 라벨 기반 일치

- match:
  - label: tuned.openshift.io/elasticsearch
    match:
    - label: node-role.kubernetes.io/master
    - label: node-role.kubernetes.io/infra
    type: pod
  priority: 10
  profile: openshift-control-plane-es
- match:
  - label: node-role.kubernetes.io/master
  - label: node-role.kubernetes.io/infra
  priority: 20
  profile: openshift-control-plane
- priority: 30
  profile: openshift-node

위의 CR은 컨테이너화된 Tuned 데몬의 프로필 우선 순위에 따라 recommended.conf 파일로 변환됩니다. 우선 순위가 가장 높은 프로필(10)이 openshift-control-plane-es이므로 이 프로필을 첫 번째로 고려합니다. 지정된 노드에서 실행되는 컨테이너화된 Tuned 데몬은 tuned.openshift.io/elasticsearch 라벨이 설정된 동일한 노드에서 실행되는 Pod가 있는지 확인합니다. 없는 경우 전체 <match> 섹션이 false로 평가됩니다. 라벨이 있는 Pod가 있는 경우 <match> 섹션을 true로 평가하려면 노드 라벨도 node-role.kubernetes.io/master 또는 node-role.kubernetes.io/infra여야 합니다.

우선 순위가 10인 프로필의 라벨이 일치하면 openshift-control-plane-es 프로필이 적용되고 다른 프로필은 고려되지 않습니다. 노드/Pod 라벨 조합이 일치하지 않으면 두 번째로 높은 우선 순위 프로필(openshift-control-plane)이 고려됩니다. 컨테이너화된 Tuned Pod가 node-role.kubernetes.io/master 또는 node-role.kubernetes.io/infra 라벨이 있는 노드에서 실행되는 경우 이 프로필이 적용됩니다.

마지막으로, openshift-node 프로필은 우선 순위가 가장 낮은 30입니다. 이 프로필에는 <match> 섹션이 없으므로 항상 일치합니다. 지정된 노드에서 우선 순위가 더 높은 다른 프로필이 일치하지 않는 경우 openshift-node 프로필을 설정하는 데 catch-all 프로필 역할을 합니다.

결정 워크플로

예: 머신 구성 풀 기반 일치

apiVersion: tuned.openshift.io/v1
kind: Tuned
metadata:
  name: openshift-node-custom
  namespace: openshift-cluster-node-tuning-operator
spec:
  profile:
  - data: |
      [main]
      summary=Custom OpenShift node profile with an additional kernel parameter
      include=openshift-node
      [bootloader]
      cmdline_openshift_node_custom=+skew_tick=1
    name: openshift-node-custom

  recommend:
  - machineConfigLabels:
      machineconfiguration.openshift.io/role: "worker-custom"
    priority: 20
    profile: openshift-node-custom

노드 재부팅을 최소화하려면 머신 구성 풀의 노드 선택기와 일치하는 라벨로 대상 노드에 라벨을 지정한 후 위의 Tuned CR을 생성하고 마지막으로 사용자 정의 머신 구성 풀을 생성합니다.

4.6. 사용자 정의 튜닝 예

다음 CR에서는 tuned.openshift.io/ingress-node-label 레이블이 임의의 값으로 설정된 OpenShift Container Platform 노드에 대해 사용자 정의 노드 수준 튜닝을 적용합니다. 관리자는 다음 명령을 사용하여 사용자 정의 Tuned CR을 생성합니다.

사용자 정의 튜닝 예

$ oc create -f- <<_EOF_
apiVersion: tuned.openshift.io/v1
kind: Tuned
metadata:
  name: ingress
  namespace: openshift-cluster-node-tuning-operator
spec:
  profile:
  - data: |
      [main]
      summary=A custom OpenShift ingress profile
      include=openshift-control-plane
      [sysctl]
      net.ipv4.ip_local_port_range="1024 65535"
      net.ipv4.tcp_tw_reuse=1
    name: openshift-ingress
  recommend:
  - match:
    - label: tuned.openshift.io/ingress-node-label
    priority: 10
    profile: openshift-ingress
_EOF_

중요

사용자 정의 프로필 작성자는 기본 Tuned CR에 제공된 기본 Tuned 데몬 프로필을 포함하는 것이 좋습니다. 위의 예에서는 기본 openshift-control-plane 프로필을 사용하여 작업을 수행합니다.

4.7. 지원되는 Tuned 데몬 플러그인

Tuned CR의 profile: 섹션에 정의된 사용자 정의 프로필을 사용하는 경우 [main] 섹션을 제외한 다음 Tuned 플러그인이 지원됩니다.

  • audio
  • cpu
  • disk
  • eeepc_she
  • modules
  • mounts
  • net
  • scheduler
  • scsi_host
  • selinux
  • sysctl
  • sysfs
  • usb
  • video
  • vm

일부 플러그인에서 제공하는 동적 튜닝 기능 중에는 지원되지 않는 기능이 일부 있습니다. 다음 Tuned 플러그인은 현재 지원되지 않습니다.

  • bootloader
  • script
  • systemd

자세한 내용은 사용 가능한 Tuned 플러그인 및 Tuned 시작하기를 참조하십시오.

5장. Cluster Loader 사용

Cluster Loader는 많은 수의 다양한 오브젝트를 클러스터에 배포하여 사용자 정의 클러스터 오브젝트를 생성하는 툴입니다. Cluster Loader를 빌드하고, 구성하고, 실행하여 다양한 클러스터 상태에서 OpenShift Container Platform 배포의 성능 지표를 측정하십시오.

5.1. Cluster Loader 설치

프로세스

  1. 컨테이너 이미지를 가져오려면 다음을 실행합니다. 

    $ podman pull quay.io/openshift/origin-tests:4.6

5.2. Cluster Loader 실행

전제 조건

  • 리포지토리에서 인증하라는 메시지를 표시합니다. 레지스트리 자격 증명을 사용하면 공개적으로 제공되지 않는 이미지에 액세스할 수 있습니다. 설치의 기존 인증 자격 증명을 사용하십시오.

프로세스

  1. 다섯 개의 템플릿 빌드를 배포하고 완료될 때까지 대기하는 내장 테스트 구성을 사용하여 Cluster Loader를 실행합니다. 

    $ podman run -v ${LOCAL_KUBECONFIG}:/root/.kube/config:z -i \
quay.io/openshift/origin-tests:4.6 /bin/bash -c 'export KUBECONFIG=/root/.kube/config && \
openshift-tests run-test "[sig-scalability][Feature:Performance] Load cluster \
should populate the cluster [Slow][Serial] [Suite:openshift]"'

    또는 VIPERCONFIG 환경 변수를 설정하여 사용자 정의 구성으로 Cluster Loader를 실행합니다. 

    $ podman run -v ${LOCAL_KUBECONFIG}:/root/.kube/config:z \
-v ${LOCAL_CONFIG_FILE_PATH}:/root/configs/:z \
-i quay.io/openshift/origin-tests:4.6 \
/bin/bash -c 'KUBECONFIG=/root/.kube/config VIPERCONFIG=/root/configs/test.yaml \
openshift-tests run-test "[sig-scalability][Feature:Performance] Load cluster \
should populate the cluster [Slow][Serial] [Suite:openshift]"'

    이 예에서는 ${LOCAL_KUBECONFIG}가 로컬 파일 시스템의 kubeconfig 경로를 참조합니다. test.yaml 구성 파일이 있는 컨테이너에 마운트되는 ${LOCAL_CONFIG_FILE_PATH} 디렉터리도 있습니다. test.yaml이 외부 템플릿 파일 또는 podspec 파일을 참조하는 경우 해당 파일도 컨테이너에 마운트되어야 합니다.

5.3. Cluster Loader 구성

이 툴에서는 여러 템플릿 또는 Pod를 포함하는 여러 네임스페이스(프로젝트)를 생성합니다.

5.3.1. Cluster Loader 구성 파일 예

Cluster Loader 구성 파일은 기본 YAML 파일입니다. 

provider: local 1
ClusterLoader:
  cleanup: true
  projects:
    - num: 1
      basename: clusterloader-cakephp-mysql
      tuning: default
      ifexists: reuse
      templates:
        - num: 1
          file: cakephp-mysql.json

    - num: 1
      basename: clusterloader-dancer-mysql
      tuning: default
      ifexists: reuse
      templates:
        - num: 1
          file: dancer-mysql.json

    - num: 1
      basename: clusterloader-django-postgresql
      tuning: default
      ifexists: reuse
      templates:
        - num: 1
          file: django-postgresql.json

    - num: 1
      basename: clusterloader-nodejs-mongodb
      tuning: default
      ifexists: reuse
      templates:
        - num: 1
          file: quickstarts/nodejs-mongodb.json

    - num: 1
      basename: clusterloader-rails-postgresql
      tuning: default
      templates:
        - num: 1
          file: rails-postgresql.json

  tuningsets: 2
    - name: default
      pods:
        stepping: 3
          stepsize: 5
          pause: 0 s
        rate_limit: 4
          delay: 0 ms
1
엔드 투 엔드 테스트에 대한 선택적 설정입니다. 추가 로그 메시지가 생성되지 않도록 하려면 local로 설정하십시오.
2
튜닝 세트를 사용하면 속도 제한 및 스테핑이 허용되므로 세트 간에 정지하는 동안 Pod에 대한 여러 일괄 처리를 생성할 수 있습니다. Cluster Loader에서는 이전 단계가 완료되는지를 모니터링한 후 작업을 계속합니다.
3
스테핑은 N개의 오브젝트가 생성될 때마다 M초 동안 정지하는 것입니다.
4
속도 제한은 오브젝트 생성 간에 M밀리초 동안 대기하는 것입니다.

이 예에서는 외부 템플릿 파일 또는 Pod 사양 파일에 대한 참조도 컨테이너에 마운트되었다고 가정합니다.

중요

Microsoft Azure에서 Cluster Loader를 실행하는 경우 AZURE_AUTH_LOCATION 변수를 설치 프로그램 디렉터리에 있는 terraform.azure.auto.tfvars.json 출력이 포함된 파일로 설정해야 합니다.

5.3.2. 구성 필드

표 5.1. 최상위 수준 Cluster Loader 필드
필드설명

cleanup

true 또는 false로 설정합니다. 구성당 정의가 하나입니다. true로 설정되면 테스트 종료 시 cleanup이 Cluster Loader에서 생성한 모든 네임스페이스(프로젝트)를 삭제합니다.

projects

정의가 하나 이상인 하위 오브젝트입니다. projects 아래에는 생성할 각 네임스페이스가 정의되며 projects에는 여러 개의 필수 부제목이 있습니다.

tuningsets

구성당 하나의 정의가 있는 하위 오브젝트입니다. tuningsets 를 사용하면 사용자가 구성 가능한 타이밍을 프로젝트 또는 개체 생성(Pod, 템플릿 등)에 추가하도록 튜닝 세트를 정의할 수 있습니다.

sync

구성당 정의가 하나인 선택적 하위 오브젝트입니다. 오브젝트 생성 중 동기화 가능성을 추가합니다.

표 5.2. projects 아래 필드
필드설명

num

정수입니다. 생성할 프로젝트 수에 대한 하나의 정의입니다.

basename

문자열입니다. 프로젝트의 기본 이름에 대한 하나의 정의입니다. 충돌을 방지하도록 동일한 네임스페이스 수가 Basename에 추가됩니다.

tuning

문자열입니다. 오브젝트에 적용할 튜닝 세트에 대한 하나의 정의로, 이 네임스페이스 내에서 배포합니다.

ifexists

reuse 또는 delete가 포함된 문자열입니다. 실행 중에 생성되는 프로젝트 또는 네임스페이스와 이름이 동일한 프로젝트 또는 네임스페이스를 찾는 경우 툴에서 수행할 작업을 정의합니다.

configmaps

키-값 쌍 목록입니다. 키는 구성 맵 이름이고 값은 구성 맵을 생성하는 파일의 경로입니다.

secrets

키-값 쌍 목록입니다. 키는 보안 이름이고 값은 보안을 생성하는 파일의 경로입니다.

pods

배포할 Pod 정의가 하나 이상인 하위 오브젝트입니다.

templates

배포할 템플릿 정의가 하나 이상인 하위 오브젝트입니다.

표 5.3. pods 및 templates 아래 필드
필드설명

num

정수입니다. 배포할 Pod 또는 템플릿 수입니다.

image

문자열입니다. docker 이미지를 가져올 수 있는 리포지토리에 대한 docker 이미지 URL입니다.

basename

문자열입니다. 생성할 템플릿(또는 Pod)의 기본 이름에 대한 하나의 정의입니다.

file

문자열입니다. 생성할 Pod 사양 또는 템플릿이 있는 로컬 파일에 대한 경로입니다.

parameters

키-값 쌍입니다. parameters 아래에서는 Pod 또는 템플릿에서 재정의할 값 목록을 지정할 수 있습니다.

표 5.4. tuningsets 아래 필드
필드설명

name

문자열입니다. 프로젝트에서 튜닝을 정의할 때 지정된 이름과 일치하는 튜닝 세트의 이름입니다.

pods

Pod에 적용할 tuningsets를 식별하는 하위 오브젝트입니다.

templates

템플릿에 적용할 tuningsets를 식별하는 하위 오브젝트입니다.

표 5.5. tuningsets pods 또는 tuningsets templates 아래 필드
필드설명

stepping

하위 오브젝트입니다. 단계 생성 패턴으로 오브젝트를 생성하려는 경우 사용되는 스테핑 구성입니다.

rate_limit

하위 오브젝트입니다. 오브젝트 생성 속도를 제한하는 속도 제한 튜닝 세트 구성입니다.

표 5.6. tuningsets pods 또는 tuningsets templates, stepping 아래 필드
필드설명

stepsize

정수입니다. 오브젝트 생성을 정지하기 전 생성할 오브젝트 수입니다.

pause

정수입니다. stepsize에 정의된 오브젝트 수를 생성한 후 정지하는 시간(초)입니다.

timeout

정수입니다. 오브젝트 생성에 성공하지 못하는 경우 실패 전 대기하는 시간(초)입니다.

delay

정수입니다. 생성 요청 간에 대기하는 시간(밀리초)입니다.

표 5.7. sync 아래 필드
필드설명

server

enabled 및 port 필드가 있는 하위 오브젝트입니다. 부울 enabled는 Pod 동기화를 위해 HTTP 서버를 시작할지 여부를 정의합니다. 정수 port는 청취할 HTTP 서버 포트(기본적으로 9090)를 정의합니다.

running

부울입니다. selectors와 일치하는 레이블이 있는 Pod가 Running 상태가 될 때까지 기다립니다.

succeeded

부울입니다. selectors와 일치하는 레이블이 있는 Pod가 Completed 상태가 될 때까지 기다립니다.

selectors

Running 또는 Completed 상태의 Pod와 일치하는 선택기 목록입니다.

timeout

문자열입니다. Pod가 Running 또는 Completed 상태가 될 때까지 대기할 동기화 시간 제한 기간입니다. 값이 0이 아닌 경우 [ns|us|ms|s|m|h] 단위를 사용하십시오.

5.4. 알려진 문제

  • 구성없이 Cluster Loader를 호출하는 경우 실패합니다. (BZ#1761925)

  • IDENTIFIER 매개변수가 사용자 템플릿에 정의되어 있지 않으면 템플릿 생성에 실패하고 error: unknown parameter name "IDENTIFIER"가 표시됩니다. 템플릿을 배포하는 경우 다음과 같이 이 매개변수를 템플릿에 추가하여 오류를 방지하십시오. 

    {
  "name": "IDENTIFIER",
  "description": "Number to append to the name of resources",
  "value": "1"
}

    Pod를 배포하는 경우 매개변수를 추가할 필요가 없습니다.

6장. CPU 관리자 사용

CPU 관리자는 CPU 그룹을 관리하고 워크로드를 특정 CPU로 제한합니다.

CPU 관리자는 다음과 같은 속성 중 일부가 포함된 워크로드에 유용합니다.

  • 가능한 한 많은 CPU 시간이 필요합니다.
  • 프로세서 캐시 누락에 민감합니다.
  • 대기 시간이 짧은 네트워크 애플리케이션입니다.
  • 다른 프로세스와 조정하고 단일 프로세서 캐시 공유를 통해 얻는 이점이 있습니다.

6.1. CPU 관리자 설정

절차

  1. 선택 사항: 노드에 레이블을 지정합니다. 

    # oc label node perf-node.example.com cpumanager=true

  2. CPU 관리자를 활성화해야 하는 노드의 MachineConfigPool을 편집합니다. 이 예에서는 모든 작업자의 CPU 관리자가 활성화됩니다. 

    # oc edit machineconfigpool worker

  3. 작업자 머신 구성 풀에 레이블을 추가합니다. 

    metadata:
  creationTimestamp: 2020-xx-xxx
  generation: 3
  labels:
    custom-kubelet: cpumanager-enabled

  4. KubeletConfig, cpumanager-kubeletconfig.yaml, CR(사용자 정의 리소스)을 생성합니다. 이전 단계에서 생성한 레이블을 참조하여 올바른 노드가 새 kubelet 구성으로 업데이트되도록 합니다. machineConfigPoolSelector 섹션을 참조하십시오. 

    apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  name: cpumanager-enabled
spec:
  machineConfigPoolSelector:
    matchLabels:
      custom-kubelet: cpumanager-enabled
  kubeletConfig:
     cpuManagerPolicy: static 1
     cpuManagerReconcilePeriod: 5s 2
    1
    정책을 지정합니다.
    • none. 이 정책은 기존 기본 CPU 선호도 체계를 명시적으로 활성화하여 스케줄러가 자동으로 수행하는 것 이상으로 선호도를 제공하지 않도록 합니다.
    • static. 이 정책을 사용하면 노드에서 특정 리소스 특성을 가진 Pod에 더 높은 CPU 선호도 및 배타성이 부여되도록 할 수 있습니다.
    2
    선택사항입니다. CPU 관리자 조정 빈도를 지정합니다. 기본값은 5s입니다.

  5. 동적 kubelet 구성을 생성합니다. 

    # oc create -f cpumanager-kubeletconfig.yaml

    그러면 kubelet 구성에 CPU 관리자 기능이 추가되고 필요한 경우 MCO(Machine Config Operator)가 노드를 재부팅합니다. CPU 관리자를 활성화하는 데는 재부팅이 필요하지 않습니다.

  6. 병합된 kubelet 구성을 확인합니다. 

    # oc get machineconfig 99-worker-XXXXXX-XXXXX-XXXX-XXXXX-kubelet -o json | grep ownerReference -A7

    출력 예

           "ownerReferences": [
            {
                "apiVersion": "machineconfiguration.openshift.io/v1",
                "kind": "KubeletConfig",
                "name": "cpumanager-enabled",
                "uid": "7ed5616d-6b72-11e9-aae1-021e1ce18878"
            }
        ]

  7. 작업자에서 업데이트된 kubelet.conf를 확인합니다. 

    # oc debug node/perf-node.example.com
sh-4.2# cat /host/etc/kubernetes/kubelet.conf | grep cpuManager

    출력 예

    cpuManagerPolicy: static        1
cpuManagerReconcilePeriod: 5s   2

    1 2
    이러한 설정은 KubeletConfig CR을 생성할 때 정의됩니다.

  8. 코어를 하나 이상 요청하는 Pod를 생성합니다. 제한 및 요청 둘 다 해당 CPU 값이 정수로 설정되어야 합니다. 해당 숫자는 이 Pod 전용으로 사용할 코어 수입니다. 

    # cat cpumanager-pod.yaml

    출력 예

    apiVersion: v1
kind: Pod
metadata:
  generateName: cpumanager-
spec:
  containers:
  - name: cpumanager
    image: gcr.io/google_containers/pause-amd64:3.0
    resources:
      requests:
        cpu: 1
        memory: "1G"
      limits:
        cpu: 1
        memory: "1G"
  nodeSelector:
    cpumanager: "true"

  9. Pod를 생성합니다. 

    # oc create -f cpumanager-pod.yaml

  10. 레이블 지정한 노드에 Pod가 예약되어 있는지 검증합니다. 

    # oc describe pod cpumanager

    출력 예

    Name:               cpumanager-6cqz7
Namespace:          default
Priority:           0
PriorityClassName:  <none>
Node:  perf-node.example.com/xxx.xx.xx.xxx
...
 Limits:
      cpu:     1
      memory:  1G
    Requests:
      cpu:        1
      memory:     1G
...
QoS Class:       Guaranteed
Node-Selectors:  cpumanager=true

  11. cgroups가 올바르게 설정되었는지 검증합니다. pause 프로세스의 PID(프로세스 ID)를 가져옵니다. 

    # ├─init.scope
│ └─1 /usr/lib/systemd/systemd --switched-root --system --deserialize 17
└─kubepods.slice
  ├─kubepods-pod69c01f8e_6b74_11e9_ac0f_0a2b62178a22.slice
  │ ├─crio-b5437308f1a574c542bdf08563b865c0345c8f8c0b0a655612c.scope
  │ └─32706 /pause

    QoS(Quality of Service) 계층 Guaranteed의 Pod는 kubepods.slice에 있습니다. 다른 QoS 계층의 Pod는 kubepods의 하위 cgroups에 있습니다. 

    # cd /sys/fs/cgroup/cpuset/kubepods.slice/kubepods-pod69c01f8e_6b74_11e9_ac0f_0a2b62178a22.slice/crio-b5437308f1ad1a7db0574c542bdf08563b865c0345c86e9585f8c0b0a655612c.scope
# for i in `ls cpuset.cpus tasks` ; do echo -n "$i "; cat $i ; done

    출력 예

    cpuset.cpus 1
tasks 32706

  12. 작업에 허용되는 CPU 목록을 확인합니다. 

    # grep ^Cpus_allowed_list /proc/32706/status

    출력 예

     Cpus_allowed_list:    1

  13. Guaranteed Pod용으로 할당된 코어에서는 시스템의 다른 Pod(이 경우 burstable QoS 계층의 Pod)를 실행할 수 없는지 검증합니다. 

    # cat /sys/fs/cgroup/cpuset/kubepods.slice/kubepods-besteffort.slice/kubepods-besteffort-podc494a073_6b77_11e9_98c0_06bba5c387ea.slice/crio-c56982f57b75a2420947f0afc6cafe7534c5734efc34157525fa9abbf99e3849.scope/cpuset.cpus
0
# oc describe node perf-node.example.com

    출력 예

    ...
Capacity:
 attachable-volumes-aws-ebs:  39
 cpu:                         2
 ephemeral-storage:           124768236Ki
 hugepages-1Gi:               0
 hugepages-2Mi:               0
 memory:                      8162900Ki
 pods:                        250
Allocatable:
 attachable-volumes-aws-ebs:  39
 cpu:                         1500m
 ephemeral-storage:           124768236Ki
 hugepages-1Gi:               0
 hugepages-2Mi:               0
 memory:                      7548500Ki
 pods:                        250
-------                               ----                           ------------  ----------  ---------------  -------------  ---
  default                                 cpumanager-6cqz7               1 (66%)       1 (66%)     1G (12%)         1G (12%)       29m

Allocated resources:
  (Total limits may be over 100 percent, i.e., overcommitted.)
  Resource                    Requests          Limits
  --------                    --------          ------
  cpu                         1440m (96%)       1 (66%)

    이 VM에는 두 개의 CPU 코어가 있습니다. system-reserved 설정은 500밀리코어로 설정되었습니다. 즉, Node Allocatable 양이 되는 노드의 전체 용량에서 한 코어의 절반이 감산되었습니다. Allocatable CPU는 1500 밀리코어임을 확인할 수 있습니다. 즉, Pod마다 하나의 전체 코어를 사용하므로 CPU 관리자 Pod 중 하나를 실행할 수 있습니다. 전체 코어는 1000밀리코어에 해당합니다. 두 번째 Pod를 예약하려고 하면 시스템에서 해당 Pod를 수락하지만 Pod가 예약되지 않습니다. 

    NAME                    READY   STATUS    RESTARTS   AGE
cpumanager-6cqz7        1/1     Running   0          33m
cpumanager-7qc2t        0/1     Pending   0          11s

7장. 토폴로지 관리자 사용

토폴로지 관리자는 동일한 NUMA(Non-Uniform Memory Access) 노드의 모든 QoS(Quality of Service) 클래스에 대해 CPU 관리자, 장치 관리자, 기타 힌트 공급자로부터 힌트를 수집하여 CPU, SR-IOV VF, 기타 장치 리소스 등의 Pod 리소스를 정렬합니다.

토폴로지 관리자는 토폴로지 관리자 정책 및 요청된 Pod 리소스를 기반으로 수집된 힌트의 토폴로지 정보를 사용하여 노드에서 Pod를 수락하거나 거부할 수 있는지 결정합니다.

토폴로지 관리자는 하드웨어 가속기를 사용하여 대기 시간이 중요한 실행과 처리량이 높은 병렬 계산을 지원하는 워크로드에 유용합니다.

참고

토폴로지 관리자를 사용하려면 정책이 static 상태인 CPU 관리자를 사용해야 합니다. CPU 관리자에 대한 자세한 내용은 CPU 관리자 사용을 참조하십시오.

7.1. 토폴로지 관리자 정책

토폴로지 관리자는 CPU 관리자 및 장치 관리자와 같은 힌트 공급자로부터 토폴로지 힌트를 수집하고 수집된 힌트로 Pod 리소스를 정렬하는 방법으로 모든 QoS(Quality of Service) 클래스의 Pod 리소스를 정렬합니다.

참고

Pod 사양에서 요청된 다른 리소스와 CPU 리소스를 정렬하려면 static CPU 관리자 정책을 사용하여 CPU 관리자를 활성화해야 합니다.

토폴로지 관리자는 cpumanager-enabled CR(사용자 정의 리소스)에서 할당하는 데 다음 4가지 할당 정책을 지원합니다.

none 정책
기본 정책으로, 토폴로지 정렬을 수행하지 않습니다.
best-effort 정책
best-effort 토폴로지 관리 정책을 사용하는 Pod의 각 컨테이너에서는 kubelet이 각 힌트 공급자를 호출하여 해당 리소스 가용성을 검색합니다. 토폴로지 관리자는 이 정보를 사용하여 해당 컨테이너의 기본 NUMA 노드 선호도를 저장합니다. 선호도를 기본 설정하지 않으면 토폴로지 관리자가 해당 정보를 저장하고 노드에 대해 Pod를 허용합니다.
restricted 정책
restricted 토폴로지 관리 정책을 사용하는 Pod의 각 컨테이너에서는 kubelet이 각 힌트 공급자를 호출하여 해당 리소스 가용성을 검색합니다. 토폴로지 관리자는 이 정보를 사용하여 해당 컨테이너의 기본 NUMA 노드 선호도를 저장합니다. 선호도를 기본 설정하지 않으면 토폴로지 관리자가 노드에서 이 Pod를 거부합니다. 그러면 Pod는 Terminated 상태가 되고 Pod 허용 실패가 발생합니다.
single-numa-node 정책
single-numa-node 토폴로지 관리 정책을 사용하는 Pod의 각 컨테이너에서는 kubelet이 각 힌트 공급자를 호출하여 해당 리소스 가용성을 검색합니다. 토폴로지 관리자는 이 정보를 사용하여 단일 NUMA 노드 선호도가 가능한지 여부를 결정합니다. 가능한 경우 노드에 대해 Pod가 허용됩니다. 단일 NUMA 노드 선호도가 가능하지 않은 경우 토폴로지 관리자가 노드에서 Pod를 거부합니다. 그러면 Pod는 Terminated 상태가 되고 Pod 허용 실패가 발생합니다.

7.2. 토폴로지 관리자 설정

토폴로지 관리자를 사용하려면 cpumanager-enabled CR(사용자 정의 리소스)에서 할당 정책을 구성해야 합니다. CPU 관리자를 설정한 경우 해당 파일이 존재할 수 있습니다. 파일이 없으면 파일을 생성할 수 있습니다.

전제 조건

  • CPU 관리자 정책을 static으로 구성하십시오. 확장 및 성능 섹션에서 CPU 관리자 사용을 참조하십시오.

프로세스

토폴로지 관리자를 활성화하려면 다음을 수행합니다.

  1. cpumanager-enabled CR(사용자 정의 리소스)에서 토폴로지 관리자 할당 정책을 구성합니다. 

    $ oc edit KubeletConfig cpumanager-enabled
    apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  name: cpumanager-enabled
spec:
  machineConfigPoolSelector:
    matchLabels:
      custom-kubelet: cpumanager-enabled
  kubeletConfig:
     cpuManagerPolicy: static 1
     cpuManagerReconcilePeriod: 5s
     topologyManagerPolicy: single-numa-node 2
    1
    이 매개변수는 static이어야 합니다.
    2
    선택한 토폴로지 관리자 할당 정책을 지정합니다. 여기서는 정책이 single-numa-node입니다. 허용 가능한 값은 default, best-effort, restricted, single-numa-node입니다.

추가 리소스

7.3. Pod와 토폴로지 관리자 정책 간의 상호 작용

아래 Pod 사양의 예는 Pod와 토폴로지 관리자 간 상호 작용을 보여주는 데 도움이 됩니다.

다음 Pod는 리소스 요청 또는 제한이 지정되어 있지 않기 때문에 BestEffort QoS 클래스에서 실행됩니다. 

spec:
  containers:
  - name: nginx
    image: nginx

다음 Pod는 요청이 제한보다 작기 때문에 Burstable QoS 클래스에서 실행됩니다. 

spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      limits:
        memory: "200Mi"
      requests:
        memory: "100Mi"

선택한 정책이 none이 아니면 토폴로지 관리자는 이러한 Pod 사양 중 하나를 고려하지 않습니다.

아래 마지막 예의 Pod는 요청이 제한과 동일하기 때문에 Guaranteed QoS 클래스에서 실행됩니다. 

spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      limits:
        memory: "200Mi"
        cpu: "2"
        example.com/device: "1"
      requests:
        memory: "200Mi"
        cpu: "2"
        example.com/device: "1"

토폴로지 관리자는 이러한 Pod를 고려합니다. 토폴로지 관리자는 사용 가능한 CPU의 토폴로지를 반환하는 CPU 관리자 static 정책을 참조합니다. 토폴로지 관리자는 example.com/device에 대해 사용 가능한 장치의 토폴로지를 검색하는 장치 관리자도 참조합니다.

토폴로지 관리자는 이러한 정보를 사용하여 이 컨테이너에 가장 적합한 토폴로지를 저장합니다. 이 Pod의 경우 CPU 관리자와 장치 관리자는 리소스 할당 단계에서 이러한 저장된 정보를 사용합니다.

8장. Cluster Monitoring Operator 스케일링

OpenShift Container Platform에서는 Cluster Monitoring Operator가 수집하여 Prometheus 기반 모니터링 스택에 저장하는 지표를 공개합니다. 관리자는 시스템 리소스, 컨테이너, 구성 요소 지표를 하나의 대시보드 인터페이스인 Grafana에서 볼 수 있습니다.

8.1. Prometheus 데이터베이스 스토리지 요구사항

Red Hat은 여러 스케일링 크기에 대해 다양한 테스트를 수행했습니다.

참고

아래 Prometheus 스토리지 요구 사항은 규정되어 있지 않습니다. 워크로드 활동 및 리소스 사용량에 따라 클러스터에서 리소스 사용량이 높아질 수 있습니다.

표 8.1. 클러스터의 노드/Pod 수에 따른 Prometheus 데이터베이스 스토리지 요구사항
노드 수Pod 수Prometheus 스토리지 증가(1일당)Prometheus 스토리지 증가(15일당)RAM 공간(스케일링 크기당)네트워크(tsdb 청크당)

50

1800

6.3GB

94GB

6GB

16MB

100

3600

13GB

195GB

10GB

26MB

150

5400

19GB

283GB

12GB

36MB

200

7200

25GB

375GB

14GB

46MB

스토리지 요구사항이 계산된 값을 초과하지 않도록 예상 크기의 약 20%가 오버헤드로 추가되었습니다.

위의 계산은 기본 OpenShift Container Platform Cluster Monitoring Operator용입니다.

참고

CPU 사용률은 약간의 영향을 미칩니다. 50개 노드 및 1,800개 Pod당 비율이 약 40개 중 1개 코어입니다.

OpenShift Container Platform 권장 사항

  • 인프라 노드를 3개 이상 사용하십시오.
  • NVMe(Non-Volatile Memory Express) 드라이브를 사용하는 경우 openshift-container-storage 노드를 3개 이상 사용하십시오.

8.2. 클러스터 모니터링 구성

클러스터 모니터링 스택에서 Prometheus 구성 요소의 스토리지 용량을 늘릴 수 있습니다.

프로세스

Prometheus의 스토리지 용량을 늘리려면 다음을 수행합니다.

  1. YAML 구성 파일 cluster-monitoring-config.yaml 을 생성합니다. 예를 들면 다음과 같습니다. 

    apiVersion: v1
kind: ConfigMap
data:
  config.yaml: |
    prometheusK8s:
      retention: {{PROMETHEUS_RETENTION_PERIOD}} 1
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      volumeClaimTemplate:
        spec:
          storageClassName: {{STORAGE_CLASS}} 2
          resources:
            requests:
              storage: {{PROMETHEUS_STORAGE_SIZE}} 3
    alertmanagerMain:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      volumeClaimTemplate:
        spec:
          storageClassName: {{STORAGE_CLASS}} 4
          resources:
            requests:
              storage: {{ALERTMANAGER_STORAGE_SIZE}} 5
metadata:
  name: cluster-monitoring-config
  namespace: openshift-monitoring
    1
    일반적인 값은 PROMETHEUS_RETENTION_PERIOD=15d입니다. 단위는 s, m, h, d 접미사 중 하나를 사용하는 시간으로 측정됩니다.
    2 4
    클러스터의 스토리지 클래스입니다.
    3
    일반적인 값은 PROMETHEUS_STORAGE_SIZE=2000Gi입니다. 스토리지 값은 일반 정수이거나 이러한 접미사 중 하나를 사용하는 고정 포인트 정수일 수 있습니다. E, P, T, G, M, K. 2의 거듭제곱을 사용할 수도 있습니다: EI, Pi, Ti, Gi, Mi, Ki.
    5
    일반적인 값은 ALERTMANAGER_STORAGE_SIZE=20Gi입니다. 스토리지 값은 일반 정수이거나 이러한 접미사 중 하나를 사용하는 고정 포인트 정수일 수 있습니다. E, P, T, G, M, K. 2의 거듭제곱을 사용할 수도 있습니다: EI, Pi, Ti, Gi, Mi, Ki.
  2. 보존 기간, 스토리지 클래스 및 스토리지 크기에 대한 값을 추가합니다.
  3. 파일을 저장합니다.

  4. 다음을 실행하여 변경사항을 적용합니다. 

    $ oc create -f cluster-monitoring-config.yaml

9장. 오브젝트 최대값에 따른 환경 계획

OpenShift Container Platform 클러스터를 계획하는 경우 다음과 같은 테스트된 오브젝트 최대값을 고려하십시오.

이러한 지침은 가능한 가장 큰 클러스터를 기반으로 합니다. 크기가 작은 클러스터의 경우 최대값이 더 낮습니다. etcd 버전 또는 스토리지 데이터 형식을 비롯하여 명시된 임계값에 영향을 주는 요인은 여러 가지가 있습니다.

중요

이러한 지침은 OVN(Open Virtual Network)이 아닌 SDN(소프트웨어 정의 네트워킹)을 사용하는 OpenShift Container Platform에 적용됩니다.

대부분의 경우 이러한 수치를 초과하면 전체 성능이 저하됩니다. 반드시 클러스터가 실패하는 것은 아닙니다.

9.1. OpenShift Container Platform에 대해 테스트된 클러스터 최대값(주요 릴리스)

OpenShift Container Platform 3.x에 대해 테스트된 클라우드 플랫폼은 다음과 같습니다. RHOSP(Red Hat OpenStack Platform), Amazon Web Services 및 Microsoft Azure. OpenShift Container Platform 4.x에 대해 테스트된 클라우드 플랫폼은 다음과 같습니다. Amazon Web Services, Microsoft Azure 및 Google Cloud Platform.

최대값 유형3.x 테스트된 최대값4.x 테스트된 최대값

노드 수

2,000

2,000

Pod 수 [1]

150,000

150,000

노드당 Pod 수

250

500 [2]

코어당 Pod 수

기본값 없음

기본값 없음

네임스페이스 수 [3]

10,000

10,000

빌드 수

10,000(기본 Pod RAM 512Mi) - Pipeline 전략

10,000(기본 Pod RAM 512Mi) - S2I(Source-to-Image) 빌드 전략

네임스페이스당 Pod 수 [4]

25,000

25,000

Ingress 컨트롤러당 경로 및 백엔드 수

라우터당 2,000개

라우터당 2,000개

보안 수

80,000

80,000

구성 맵 수

90,000

90,000

서비스 수 [5]

10,000

10,000

네임스페이스당 서비스 수

5,000

5,000

서비스당 백엔드 수

5,000

5,000

네임스페이스당 배포 수 [4]

2,000

2,000

빌드 구성 수

12,000

12,000

보안 수

40,000

40,000

CRD(사용자 정의 리소스 정의) 수

기본값 없음

512 [6]

  1. 여기에 표시된 Pod 수는 테스트 Pod 수입니다. 실제 Pod 수는 애플리케이션 메모리, CPU 및 스토리지 요구사항에 따라 달라집니다.
  2. 이 테스트는 작업자 노드가 100개이며 작업자 노드당 Pod가 500개인 클러스터에서 수행되었습니다. 기본 maxPods는 계속 250입니다. maxPods가 500이 되도록 하려면 사용자 정의 kubelet 구성을 사용하여 500으로 설정된 maxPods가 포함된 클러스터를 생성해야 합니다. 500개의 사용자 Pod가 필요한 경우 노드에서 이미 실행되고 있는 시스템 Pod가 10~15개가 있으므로 hostPrefix 22가 필요합니다. 연결된 PVC(영구 볼륨 클레임)가 있는 Pod의 최대 수는 PVC가 할당된 스토리지 백엔드에 따라 달라집니다. 이 테스트에서는 OCS v4(OpenShift Container Storage v4)만 이 문서에서 설명하는 노드당 Pod 수를 충족할 수 있었습니다.
  3. 활성 프로젝트 수가 많은 경우 키 공간이 지나치게 커져서 공간 할당량을 초과하면 etcd 성능이 저하될 수 있습니다. etcd 스토리지를 확보하기 위해 조각 모음을 포함한 etcd의 유지보수를 정기적으로 사용하는 것이 좋습니다.
  4. 시스템에는 일부 상태 변경에 대한 대응으로 지정된 네임스페이스의 모든 오브젝트에서 반복해야 하는 컨트롤 루프가 많습니다. 단일 네임스페이스에 지정된 유형의 오브젝트가 많이 있으면 루프 비용이 많이 들고 지정된 상태 변경 처리 속도가 느려질 수 있습니다. 이 제한을 적용하면 애플리케이션 요구사항을 충족하기에 충분한 CPU, 메모리 및 디스크가 시스템에 있다고 가정합니다.
  5. 각 서비스 포트와 각 서비스 백엔드는 iptables에 해당 항목이 있습니다. 지정된 서비스의 백엔드 수는 끝점 오브젝트의 크기에 영향을 미치므로 시스템 전체에서 전송되는 데이터의 크기에 영향을 미칩니다.
  6. OpenShift Container Platform에는 OpenShift Container Platform에서 설치한 제품, OpenShift Container Platform 및 사용자 생성 CRD와 통합된 제품을 포함하여 총 512개의 CRD(사용자 정의 리소스 정의) 제한이 있습니다. 512개 이상의 CRD가 생성되는 경우 oc 명령 요청이 제한될 수 있습니다.
참고

Red Hat은 OpenShift Container Platform 클러스터 크기 조정에 대한 직접적인 지침을 제공하지 않습니다. 이는 클러스터가 지원되는 OpenShift Container Platform 범위 내에 있는지 여부를 확인하기 때문에 클러스터 규모를 제한하는 모든 다차원 요소를 고려해야 하기 때문입니다.

9.2. 클러스터 최대값 테스트를 위한 OpenShift Container Platform 환경 및 구성

AWS 클라우드 플랫폼:

노드플레이버vCPURAM(GiB)디스크 유형디스크 크기(GiB)/IOS수량리전

Master/etcd [1]

r5.4xlarge

16

128

io1

220 / 3000

3

us-west-2

인프라 [2]

m5.12xlarge

48

192

gp2

100

3

us-west-2

워크로드 [3]

m5.4xlarge

16

64

gp2

500 [4]

1

us-west-2

Worker

m5.2xlarge

8

32

gp2

100

3/25/250/500 [5]

us-west-2

  1. etcd는 I/O 집약적이고 지연 시간에 민감하므로 3000 IOPS가 있는 io1 디스크는 master/etcd 노드에 사용됩니다.
  2. 인프라 노드는 모니터링, Ingress 및 레지스트리 구성 요소를 호스팅하는데 사용되어 대규모로 실행할 수 있는 충분한 리소스가 있는지 확인합니다.
  3. 워크로드 노드는 성능 및 확장 가능한 워크로드 생성기 실행 전용입니다.
  4. 성능 및 확장성 테스트 실행 중에 수집되는 대량의 데이터를 저장할 수 있는 충분한 공간을 확보 할 수 있도록 큰 디스크 크기가 사용됩니다.
  5. 클러스터는 반복적으로 확장되며 성능 및 확장성 테스트는 지정된 노드 수에 따라 실행됩니다.

9.3. 테스트된 클러스터 최대값에 따라 환경을 계획하는 방법

중요

노드에서 물리적 리소스에 대한 서브스크립션을 초과하면 Pod를 배치하는 동안 Kubernetes 스케줄러가 보장하는 리소스에 영향을 미칩니다. 메모리 교체가 발생하지 않도록 하기 위해 수행할 수 있는 조치를 알아보십시오.

테스트된 최대값 중 일부는 단일 차원에서만 확장됩니다. 클러스터에서 실행되는 오브젝트가 많으면 최대값이 달라집니다.

이 문서에 명시된 수치는 Red Hat의 테스트 방법론, 설정, 구성, 튜닝을 기반으로 한 것입니다. 고유한 개별 설정 및 환경에 따라 수치가 달라질 수 있습니다.

환경을 계획하는 동안 노드당 몇 개의 Pod가 적합할 것으로 예상되는지 결정하십시오. 

required pods per cluster / pods per node = total number of nodes needed

노드당 최대 Pod 수는 현재 250입니다. 하지만 노드에 적합한 Pod 수는 애플리케이션 자체에 따라 달라집니다. 애플리케이션 요구사항에 따라 환경을 계획하는 방법에 설명된 대로 애플리케이션의 메모리, CPU 및 스토리지 요구사항을 고려하십시오.

시나리오 예

클러스터당 2,200개의 Pod로 클러스터 규모를 지정하려면 노드당 최대 500개의 Pod가 있다고 가정하여 최소 5개의 노드가 있어야 합니다. 

2200 / 500 = 4.4

노드 수를 20으로 늘리면 Pod 배포는 노드당 110개 Pod로 변경됩니다. 

2200 / 20 = 110

다음과 같습니다. 

required pods per cluster / total number of nodes = expected pods per node

9.4. 애플리케이션 요구사항에 따라 환경을 계획하는 방법

예에 나온 애플리케이션 환경을 고려해 보십시오.

Pod 유형Pod 수량최대 메모리CPU 코어 수영구 스토리지

apache

100

500MB

0.5

1GB

node.js

200

1GB

1

1GB

postgresql

100

1GB

2

10GB

JBoss EAP

100

1GB

1

1GB

예상 요구 사항: 550개의 CPU 코어, 450GB RAM 및 1.4TB 스토리지.

노드의 인스턴스 크기는 기본 설정에 따라 높게 또는 낮게 조정될 수 있습니다. 노드에서는 리소스 초과 커밋이 발생하는 경우가 많습니다. 이 배포 시나리오에서는 동일한 양의 리소스를 제공하는 데 더 작은 노드를 추가로 실행하도록 선택할 수도 있고 더 적은 수의 더 큰 노드를 실행하도록 선택할 수도 있습니다. 운영 민첩성 및 인스턴스당 비용과 같은 요인을 고려해야 합니다.

노드 유형수량CPURAM(GB)

노드(옵션 1)

100

4

16

노드(옵션 2)

50

8

32

노드(옵션 3)

25

16

64

어떤 애플리케이션은 초과 커밋된 환경에 적합하지만 어떤 애플리케이션은 그렇지 않습니다. 대부분의 Java 애플리케이션과 대규모 페이지를 사용하는 애플리케이션은 초과 커밋에 적합하지 않은 애플리케이션의 예입니다. 해당 메모리는 다른 애플리케이션에 사용할 수 없습니다. 위의 예에 나온 환경에서는 초과 커밋이 약 30%이며, 이는 일반적으로 나타나는 비율입니다.

애플리케이션 Pod는 환경 변수 또는 DNS를 사용하여 서비스에 액세스할 수 있습니다. 환경 변수를 사용하는 경우 노드에서 Pod가 실행될 때 활성 서비스마다 kubelet을 통해 변수를 삽입합니다. 클러스터 인식 DNS 서버는 새로운 서비스의 Kubernetes API를 확인하고 각각에 대해 DNS 레코드 세트를 생성합니다. 클러스터 전체에서 DNS가 활성화된 경우 모든 Pod가 자동으로 해당 DNS 이름을 통해 서비스를 확인할 수 있어야 합니다. 서비스가 5,000개를 넘어야 하는 경우 DNS를 통한 서비스 검색을 사용할 수 있습니다. 서비스 검색에 환경 변수를 사용하는 경우 네임스페이스에서 서비스가 5,000개를 넘은 후 인수 목록이 허용되는 길이를 초과하면 Pod 및 배포가 실패하기 시작합니다. 이 문제를 해결하려면 배포의 서비스 사양 파일에서 서비스 링크를 비활성화하십시오. 

---
apiVersion: v1
kind: Template
metadata:
  name: deployment-config-template
  creationTimestamp:
  annotations:
    description: This template will create a deploymentConfig with 1 replica, 4 env vars and a service.
    tags: ''
objects:
- apiVersion: v1
  kind: DeploymentConfig
  metadata:
    name: deploymentconfig${IDENTIFIER}
  spec:
    template:
      metadata:
        labels:
          name: replicationcontroller${IDENTIFIER}
      spec:
        enableServiceLinks: false
        containers:
        - name: pause${IDENTIFIER}
          image: "${IMAGE}"
          ports:
          - containerPort: 8080
            protocol: TCP
          env:
          - name: ENVVAR1_${IDENTIFIER}
            value: "${ENV_VALUE}"
          - name: ENVVAR2_${IDENTIFIER}
            value: "${ENV_VALUE}"
          - name: ENVVAR3_${IDENTIFIER}
            value: "${ENV_VALUE}"
          - name: ENVVAR4_${IDENTIFIER}
            value: "${ENV_VALUE}"
          resources: {}
          imagePullPolicy: IfNotPresent
          capabilities: {}
          securityContext:
            capabilities: {}
            privileged: false
        restartPolicy: Always
        serviceAccount: ''
    replicas: 1
    selector:
      name: replicationcontroller${IDENTIFIER}
    triggers:
    - type: ConfigChange
    strategy:
      type: Rolling
- apiVersion: v1
  kind: Service
  metadata:
    name: service${IDENTIFIER}
  spec:
    selector:
      name: replicationcontroller${IDENTIFIER}
    ports:
    - name: serviceport${IDENTIFIER}
      protocol: TCP
      port: 80
      targetPort: 8080
    portalIP: ''
    type: ClusterIP
    sessionAffinity: None
  status:
    loadBalancer: {}
parameters:
- name: IDENTIFIER
  description: Number to append to the name of resources
  value: '1'
  required: true
- name: IMAGE
  description: Image to use for deploymentConfig
  value: gcr.io/google-containers/pause-amd64:3.0
  required: false
- name: ENV_VALUE
  description: Value to use for environment variables
  generate: expression
  from: "[A-Za-z0-9]{255}"
  required: false
labels:
  template: deployment-config-template

네임스페이스에서 실행할 수 있는 애플리케이션 Pod 수는 서비스 검색에 환경 변수가 사용될 때 서비스 수와 서비스 이름의 길이에 따라 달라집니다. ARG_MAX는 새로운 프로세스의 최대 인수 길이를 정의하고 기본적으로 2097152 KiB로 설정됩니다. Kubelet은 네임스페이스에서 실행되도록 예약된 각 pod에 환경 변수를 삽입합니다. 여기에는 다음이 포함됩니다.

  • <SERVICE_NAME>_SERVICE_HOST=<IP>
  • <SERVICE_NAME>_SERVICE_PORT=<PORT>
  • <SERVICE_NAME>_PORT=tcp://<IP>:<PORT>
  • <SERVICE_NAME>_PORT_<PORT>_TCP=tcp://<IP>:<PORT>
  • <SERVICE_NAME>_PORT_<PORT>_TCP_PROTO=tcp
  • <SERVICE_NAME>_PORT_<PORT>_TCP_PORT=<PORT>
  • <SERVICE_NAME>_PORT_<PORT>_TCP_ADDR=<ADDR>

인수 길이가 허용된 값을 초과하고 서비스 이름의 문자 수에 영향을 미치는 경우 네임스페이스의 Pod가 실패합니다. 예를 들어, 5000개의 서비스가 있는 네임스페이스에서 서비스 이름의 제한은 33자이며, 네임스페이스에서 5000개의 Pod를 실행할 수 있습니다.

10장. 스토리지 최적화

스토리지를 최적화하면 모든 리소스에서 스토리지 사용을 최소화할 수 있습니다. 관리자는 스토리지를 최적화하여 기존 스토리지 리소스가 효율적으로 작동하도록 합니다.

10.1. 사용 가능한 영구 스토리지 옵션

OpenShift Container Platform 환경을 최적화할 수 있도록 영구 스토리지 옵션에 대해 알아보십시오.

표 10.1. 사용 가능한 스토리지 옵션
스토리지 유형설명예

블록

  • 운영 체제(OS)에 블록 장치로 제공됩니다.
  • 스토리지에 대한 모든 권한이 필요하며 파일 시스템을 우회하여 파일의 낮은 수준에서 작동하는 애플리케이션에 적합합니다.
  • SAN(Storage Area Network)이라고도 합니다.
  • 공유가 불가능합니다. 즉, 한 번에 하나의 클라이언트만 이 유형의 끝점을 마운트할 수 있습니다.

AWS EBS 및 VMware vSphere는 OpenShift Container Platform에서 기본적으로 동적 PV(영구 볼륨) 프로비저닝을 지원합니다.

파일

  • OS에 마운트할 파일 시스템 내보내기로 제공됩니다.
  • NAS(Network Attached Storage)라고도 합니다.
  • 동시성, 대기 시간, 파일 잠금 메커니즘 및 기타 기능은 프로토콜, 구현, 벤더 및 스케일링에 따라 크게 다릅니다.

RHEL NFS, NetApp NFS [1] 및 Vendor NFS

개체

  • REST API 끝점을 통해 액세스할 수 있습니다.
  • OpenShift Container Platform 레지스트리에서 사용하도록 구성할 수 있습니다.
  • 애플리케이션에서 해당 드라이버를 애플리케이션 및/또는 컨테이너에 빌드해야 합니다.

AWS S3

  1. NetApp NFS는 Trident 플러그인을 사용하는 경우 동적 PV 프로비저닝을 지원합니다.
중요

OpenShift Container Platform 4.6에서는 현재 CNS가 지원되지 않습니다.

10.3. 데이터 스토리지 관리

다음 표에는 OpenShift Container Platform 구성 요소가 데이터를 쓰는 기본 디렉터리가 요약되어 있습니다.

표 10.3. OpenShift Container Platform 데이터를 저장하는 기본 디렉터리
디렉터리참고크기 조정예상 증가

/var/log

모든 구성 요소의 로그 파일입니다.

10~30GB입니다.

로그 파일이 빠르게 증가할 수 있습니다. 크기는 디스크를 늘리거나 로그 회전을 사용하여 관리할 수 있습니다.

/var/lib/etcd

데이터베이스를 저장할 때 etcd 스토리지에 사용됩니다.

20GB 미만입니다.

데이터베이스는 최대 8GB까지 증가할 수 있습니다.

환경과 함께 천천히 증가합니다. 메타데이터만 저장합니다.

추가로 메모리가 8GB 증가할 때마다 추가로 20~25GB가 증가합니다.

/var/lib/containers

CRI-O 런타임의 마운트 옵션입니다. Pod를 포함한 활성 컨테이너 런타임에 사용되는 스토리지 및 로컬 이미지 스토리지입니다. 레지스트리 스토리지에는 사용되지 않습니다.

16GB 메모리가 있는 노드의 경우 50GB가 증가합니다. 이 크기 조정은 최소 클러스터 요구사항을 결정하는 데 사용하면 안 됩니다.

추가로 메모리가 8GB 증가할 때마다 추가로 20~25GB가 증가합니다.

컨테이너 실행 용량에 의해 증가가 제한됩니다.

/var/lib/kubelet

Pod용 임시 볼륨 스토리지입니다. 런타임 시 컨테이너로 마운트된 외부 요소가 모두 포함됩니다. 영구 볼륨에서 지원하지 않는 환경 변수, kube 보안 및 데이터 볼륨이 포함됩니다.

변동 가능

스토리지가 필요한 Pod가 영구 볼륨을 사용하는 경우 최소입니다. 임시 스토리지를 사용하는 경우 빠르게 증가할 수 있습니다.

11장. 라우팅 최적화

OpenShift Container Platform HAProxy 라우터는 스케일링을 통해 성능을 최적화합니다.

11.1. 기본 Ingress 컨트롤러(라우터) 성능

OpenShift Container Platform Ingress 컨트롤러 또는 라우터는 OpenShift Container Platform 서비스를 대상으로 하는 모든 외부 트래픽의 Ingress 지점입니다.

초당 처리된 HTTP 요청 측면에서 단일 HAProxy 라우터 성능을 평가할 때 성능은 여러 요인에 따라 달라집니다. 특히 중요한 요인은 다음과 같습니다.

  • HTTP 연결 유지/닫기 모드
  • 경로 유형
  • TLS 세션 재개 클라이언트 지원
  • 대상 경로당 동시 연결 수
  • 대상 경로 수
  • 백엔드 서버 페이지 크기
  • 기본 인프라(네트워크/SDN 솔루션, CPU 등)

특정 환경의 성능은 달라질 수 있으나 Red Hat 랩은 크기가 4 vCPU/16GB RAM인 퍼블릭 클라우드 인스턴스에서 테스트합니다. 1kB 정적 페이지를 제공하는 백엔드에서 종료한 100개의 경로를 처리하는 단일 HAProxy 라우터가 처리할 수 있는 초당 트랜잭션 수는 다음과 같습니다.

HTTP 연결 유지 모드 시나리오에서는 다음과 같습니다.

EncryptionLoadBalancerServiceHostNetwork

none

21515

29622

edge

16743

22913

passthrough

36786

53295

re-encrypt

21583

25198

HTTP 닫기(연결 유지 제외) 시나리오에서는 다음과 같습니다.

EncryptionLoadBalancerServiceHostNetwork

none

5719

8273

edge

2729

4069

passthrough

4121

5344

re-encrypt

2320

2941

ROUTER_THREADS=4로 설정된 기본 Ingress 컨트롤러 구성이 사용되었고 두 개의 서로 다른 끝점 게시 전략(LoadBalancerService/HostNetwork)이 테스트되었습니다. 암호화된 경로에는 TLS 세션 재개가 사용되었습니다. HTTP 연결 유지 기능을 사용하면 단일 HAProxy 라우터가 8kB의 작은 페이지 크기에서 1Gbit NIC를 수용할 수 있습니다.

최신 프로세서가 있는 베어 메탈에서 실행하는 경우 성능이 위 퍼블릭 클라우드 인스턴스의 약 2배가 될 것을 예상할 수 있습니다. 이 오버헤드는 퍼블릭 클라우드에서 가상화 계층에 의해 도입되며 프라이빗 클라우드 기반 가상화에도 적용됩니다. 다음 표는 라우터 뒤에서 사용할 애플리케이션 수에 대한 가이드입니다.

애플리케이션 수애플리케이션 유형

5-10

정적 파일/웹 서버 또는 캐싱 프록시

100-1000

동적 콘텐츠를 생성하는 애플리케이션

일반적으로 HAProxy는 사용 중인 기술에 따라 5~1,000개의 애플리케이션 경로를 지원할 수 있습니다. Ingress 컨트롤러 성능은 언어 또는 정적 콘텐츠 대비 동적 콘텐츠 등 지원하는 애플리케이션의 기능과 성능에 따라 제한될 수 있습니다.

Ingress 또는 라우터 샤딩을 사용하여 애플리케이션에 대한 경로를 더 많이 제공하면 라우팅 계층을 수평으로 확장하는 데 도움이 됩니다.

Ingress 샤딩에 대한 자세한 내용은 경로 레이블을 사용하여 Ingress 컨트롤러 샤딩 구성 및 네임스페이스 레이블을 사용하여 Ingress 컨트롤러 샤딩 구성을 참조하십시오.

11.2. Ingress 컨트롤러(라우터) 성능 최적화

OpenShift Container Platform에서는 ROUTER_THREADS, ROUTER_DEFAULT_TUNNEL_TIMEOUT, ROUTER_DEFAULT_CLIENT_TIMEOUT, ROUTER_DEFAULT_SERVER_TIMEOUT 및 RELOAD_INTERVAL과 같은 환경 변수를 설정하여 Ingress 컨트롤러 배포를 수정하는 작업을 더 이상 지원하지 않습니다.

Ingress 컨트롤러 배포를 수정할 수 있지만 Ingress Operator가 활성화된 경우 구성을 덮어씁니다.

12장. 네트워킹 최적화

OpenShift SDN은 OpenvSwitch, VXLAN(Virtual Extensible LAN) 터널, OpenFlow 규칙 및 iptables를 사용합니다. 이 네트워크는 점보 프레임, NIC(네트워크 인터페이스 컨트롤러) 오프로드, 멀티 큐 및 ethtool 설정을 사용하여 조정할 수 있습니다.

OVN-Kubernetes는 VXLAN 대신 Geneve(Generic Network Virtualization Encapsulation)를 터널 프로토콜로 사용합니다.

VXLAN은 VLAN에 비해 네트워크 수가 4096개에서 1600만 개 이상으로 증가하고 물리적 네트워크 전반에 걸쳐 계층 2 연결과 같은 이점을 제공합니다. 이를 통해 서비스 뒤에 있는 모든 Pod가 서로 다른 시스템에서 실행되는 경우에도 서로 통신할 수 있습니다.

VXLAN은 사용자 데이터그램 프로토콜(UDP) 패킷의 터널링된 모든 트래픽을 캡슐화합니다. 그러나 이로 인해 CPU 사용량이 증가합니다. 이러한 외부 및 내부 패킷은 전송 중에 데이터가 손상되지 않도록하기 위해 일반 체크섬 규칙을 따릅니다. CPU 성능에 따라 이러한 추가 처리 오버헤드는 처리량이 감소하고 기존 비 오버레이 네트워크에 비해 대기 시간이 증가할 수 있습니다.

클라우드, 가상 머신, 베어 메탈 CPU 성능은 많은 Gbps의 네트워크 처리량을 처리할 수 있습니다. 10 또는 40Gbps와 같은 높은 대역폭 링크를 사용하는 경우 성능이 저하될 수 있습니다. 이 문제는 VXLAN 기반 환경에서 알려진 문제이며 컨테이너 또는 OpenShift Container Platform에만 국한되지 않습니다. VXLAN 터널에 의존하는 네트워크는 VXLAN 구현으로 인해 비슷한 작업을 수행할 수 있습니다.

Gbps을 초과하여 푸시하려는 경우 다음을 수행할 수 있습니다.

  • BGP (Border Gateway Protocol)와 같은 다른 라우팅 기술을 구현하는 네트워크 플러그인을 평가합니다.
  • VXLAN 오프로드 가능 네트워크 어댑터를 사용합니다. VXLAN 오프로드는 패킷 체크섬 계산 및 관련 CPU 오버헤드를 시스템 CPU에서 네트워크 어댑터의 전용 하드웨어로 이동합니다. 이를 통해 Pod 및 애플리케이션에서 사용할 CPU 사이클을 확보하고 사용자는 네트워크 인프라의 전체 대역폭을 사용할 수 있습니다.

VXLAN 오프로드는 대기 시간을 단축시키지 않습니다. 그러나 대기 시간 테스트에서도 CPU 사용량이 감소합니다.

12.1. 네트워크에 대한 MTU 최적화

중요한 최대 전송 단위(MTU)는 NIC(네트워크 인터페이스 컨트롤러) MTU와 클러스터 네트워크 MTU입니다.

NIC MTU는 OpenShift Container Platform을 설치할 때만 구성됩니다. MTU는 네트워크 NIC에서 지원되는 최대 값과 작거나 같아야 합니다. 처리량을 최적화하려면 가능한 가장 큰 값을 선택합니다. 최소 지연을 최적화하려면 더 낮은 값을 선택합니다.

SDN 오버레이의 MTU는 NIC MTU보다 최소 50바이트 작아야 합니다. 이 계정은 SDN 오버레이 헤더에 대한 계정입니다. 일반적인 이더넷 네트워크에서는 이 값을 1450으로 설정합니다. 점보 프레임 이더넷 네트워크에서는 이 값을 8950으로 설정합니다.

OVN 및 Geneve의 경우 MTU는 NIC MTU보다 최소 100바이트 작아야 합니다.

참고

50바이트 오버레이 헤더는 OpenShift SDN과 관련이 있습니다. 기타 SDN 솔루션에서는 이 값이 더 크거나 작아야 할 수 있습니다.

12.3. IPsec 영향

노드 호스트의 암호화 및 암호 해독은 CPU를 사용하기 때문에 사용 중인 IP 보안 시스템에 관계없이 암호화를 사용할 때 노드의 처리량과 CPU 사용량 모두에서 성능에 영향을 미칩니다.

IPsec은 NIC에 도달하기 전에 IP 페이로드 수준에서 트래픽을 암호화하여 NIC 오프로드에 사용되는 필드를 보호합니다. 즉, IPSec가 활성화되면 일부 NIC 가속 기능을 사용할 수 없으며 처리량이 감소하고 CPU 사용량이 증가합니다.

추가 리소스

13장. 베어 메탈 호스트 관리

베어 메탈 클러스터에 OpenShift Container Platform을 설치할 때 클러스터에 있는 베어 메탈 호스트에 대한 machine 및 machineset CR(사용자 정의 리소스)을 사용하여 베어 메탈 노드를 프로비저닝하고 관리할 수 있습니다.

13.1. 베어 메탈 호스트 및 노드 정보

RHCOS(Red Hat Enterprise Linux CoreOS) 베어 메탈 호스트를 클러스터에서 노드로 프로비저닝하려면 먼저 베어 메탈 호스트 하드웨어에 해당하는 MachineSet CR(사용자 정의 리소스) 오브젝트를 생성합니다. 베어 메탈 호스트 머신 세트는 구성과 관련된 인프라 구성 요소를 설명합니다. 이러한 머신에 특정 Kubernetes 레이블을 적용한 다음 해당 머신 세트에서만 실행되도록 인프라 구성 요소를 업데이트합니다.

machine CR은 metal3.io/autoscale-to-hosts 주석이 포함된 관련 MachineSet을 확장하면 자동으로 생성됩니다. OpenShift Container Platform은 Machine CR을 사용하여 MachineSet CR에 지정된 대로 호스트에 해당하는 베어 메탈 노드를 프로비저닝합니다.

13.2. 베어 메탈 호스트 유지관리

OpenShift Container Platform 웹 콘솔에서 클러스터의 베어 메탈 호스트의 세부 정보를 유지 관리할 수 있습니다. 컴퓨팅 → 베어 메탈 호스트로 이동하여 작업 드롭다운 메뉴에서 작업을 선택합니다. 여기에서 BMC 세부 정보, 호스트의 MAC 주소 부팅, 전원 관리 활성화 등의 항목을 관리할 수 있습니다. 네트워크 인터페이스의 세부 정보와 호스트에 대한 드라이브도 검토할 수 있습니다.

베어 메탈 호스트를 유지 관리 모드로 이동할 수 있습니다. 호스트를 유지 관리 모드로 이동할 때 스케줄러는 모든 관리 워크로드를 해당 베어 메탈 노드에서 이동합니다. 유지 관리 모드에서는 새 워크로드가 예약되지 않습니다.

웹 콘솔에서 베어 메탈 호스트를 프로비저닝 해제할 수 있습니다. 호스트 프로비저닝 해제는 다음 작업을 수행합니다.

  1. cluster.k8s.io/delete-machine: true를 사용하여 베어 메탈 호스트 CR에 주석을 답니다.
  2. 관련 머신 세트를 축소합니다.
참고

먼저 데몬 세트와 관리되지 않는 정적 Pod를 다른 노드로 이동하지 않고 호스트의 전원을 끄면 서비스가 중단되고 데이터가 손실될 수 있습니다.

추가 리소스

13.2.1. 웹 콘솔을 사용하여 클러스터에 베어 메탈 호스트 추가

웹 콘솔의 클러스터에 베어 메탈 호스트를 추가할 수 있습니다.

사전 요구 사항

  • 베어 메탈에 RHCOS 클러스터 설치
  • cluster-admin 권한이 있는 사용자로 로그인합니다.

절차

  1. 웹 콘솔에서 Compute → Bare Metal Hosts로 이동합니다.
  2. Add Host → New with Dialog를 선택합니다.
  3. 새 베어 메탈 호스트의 고유 이름을 지정합니다.
  4. Boot MAC address를 설정합니다.
  5. Baseboard Management Console (BMC) Address를 설정합니다.
  6. 선택적으로 호스트의 전원 관리를 활성화합니다. 이를 통해 OpenShift Container Platform에서 호스트의 전원 상태를 제어할 수 있습니다.
  7. 호스트의 BMC(Baseboard Management Controller)에 대한 사용자 인증 정보를 입력합니다.
  8. 생성 후 호스트 전원을 켜도록선택하고 Create를 선택합니다.
  9. 사용 가능한 베어 메탈 호스트 수와 일치하도록 복제본 수를 확장합니다. Compute → MachineSets로 이동하고 Actions 드롭다운 메뉴에서 Edit Machine count을 선택하여 클러스터에서 머신 복제본 수를 늘립니다.
참고

oc scale 명령 및 적절한 베어 메탈 머신 세트를 사용하여 베어 메탈 노드 수를 관리할 수도 있습니다.

13.2.2. 웹 콘솔에서 YAML을 사용하여 클러스터에 베어 메탈 호스트 추가

베어 메탈 호스트를 설명하는 YAML 파일을 사용하여 웹 콘솔의 클러스터에 베어 메탈 호스트를 추가할 수 있습니다.

사전 요구 사항

  • 클러스터에 사용할 RHCOS 컴퓨팅 머신을 베어메탈 인프라에 설치합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.
  • 베어 메탈 호스트의 Secret CR을 생성합니다.

절차

  1. 웹 콘솔에서 Compute → Bare Metal Hosts로 이동합니다.
  2. Add Host → New from YAML을 선택합니다.

  3. 아래 YAML을 복사하고 붙여넣고 호스트의 세부 정보로 관련 필드를 수정합니다. 

    apiVersion: metal3.io/v1alpha1
kind: BareMetalHost
metadata:
  name: <bare_metal_host_name>
spec:
  online: true
  bmc:
    address: <bmc_address>
    credentialsName: <secret_credentials_name>  1
    disableCertificateVerification: True
  bootMACAddress: <host_boot_mac_address>
  hardwareProfile: unknown
    1
    credentialsName은 유효한 Secret CR을 참조해야 합니다. baremetal-operator는 credentialsName에서 참조되는 유효한 Secret 없이 베어 메탈 호스트를 관리할 수 없습니다. 시크릿 및 시크릿 생성 방법에 대한 자세한 내용은 시크릿 이해하기에서 참조하십시오.
  4. Create를 선택하여 YAML을 저장하고 새 베어 메탈 호스트를 생성합니다.

  5. 사용 가능한 베어 메탈 호스트 수와 일치하도록 복제본 수를 확장합니다. Compute → MachineSets로 이동하고 Actions 드롭다운 메뉴에서 Edit Machine count를 선택하여 클러스터의 머신 수를 늘립니다.

    참고

    oc scale 명령 및 적절한 베어 메탈 머신 세트를 사용하여 베어 메탈 노드 수를 관리할 수도 있습니다.

13.2.3. 사용 가능한 베어 메탈 호스트 수로 머신 자동 스케일링

사용 가능한 BareMetalHost 오브젝트 수와 일치하는 Machine 오브젝트 수를 자동으로 생성하려면 MachineSet 오브젝트에 metal3.io/autoscale-to-hosts 주석을 추가합니다.

사전 요구 사항

  • 클러스터에서 사용할 RHCOS 베어 메탈 컴퓨팅 머신을 설치하고 해당 BareMetalHost 오브젝트를 생성합니다.
  • OpenShift Container Platform CLI (oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.

절차

  1. metal3.io/autoscale-to-hosts 주석을 추가하여 자동 스케일링을 구성할 머신 세트에 주석을 답니다. <machineset>를 머신 세트 이름으로 바꿉니다. 

    $ oc annotate machineset <machineset> -n openshift-machine-api 'metal3.io/autoscale-to-hosts=<any_value>'

    새로 확장된 머신이 시작될 때까지 기다립니다.

참고

BareMetalHost 오브젝트를 사용하여 클러스터에 머신을 생성하고 레이블 또는 선택기가 BareMetalHost에서 변경되면 Machine 오브젝트가 생성된 MachineSet에 대해 BareMetalHost 오브젝트가 계속 계산됩니다.

추가 리소스

14장. 대규모 페이지의 기능과 애플리케이션에서 대규모 페이지를 사용하는 방법

14.1. 대규모 페이지의 기능

메모리는 페이지라는 블록으로 관리됩니다. 대부분의 시스템에서 한 페이지는 4Ki입니다. 1Mi 메모리는 256페이지와 같고 1Gi 메모리는 256,000페이지에 해당합니다. CPU에는 하드웨어에서 이러한 페이지 목록을 관리하는 내장 메모리 관리 장치가 있습니다. TLB(Translation Lookaside Buffer)는 가상-물리적 페이지 매핑에 대한 소규모 하드웨어 캐시입니다. TLB에 하드웨어 명령어로 전달된 가상 주소가 있으면 매핑을 신속하게 확인할 수 있습니다. 가상 주소가 없으면 TLB 누락이 발생하고 시스템에서 소프트웨어 기반 주소 변환 속도가 느려져 성능 문제가 발생합니다. TLB 크기는 고정되어 있으므로 TLB 누락 가능성을 줄이는 유일한 방법은 페이지 크기를 늘리는 것입니다.

대규모 페이지는 4Ki보다 큰 메모리 페이지입니다. x86_64 아키텍처의 일반적인 대규모 페이지 크기는 다음과 같습니다. 2Mi 및 1Gi. 다른 아키텍처에서는 크기가 달라집니다. 대규모 페이지를 사용하려면 애플리케이션이 인식할 수 있도록 코드를 작성해야 합니다. THP(투명한 대규모 페이지)에서는 애플리케이션 지식 없이 대규모 페이지 관리를 자동화하려고 하지만 한계가 있습니다. 특히 페이지 크기 2Mi로 제한됩니다. THP에서는 THP 조각 모음 작업으로 인해 메모리 사용률이 높아지거나 조각화가 발생하여 노드에서 성능이 저하될 수 있으며 이로 인해 메모리 페이지가 잠길 수 있습니다. 이러한 이유로 일부 애플리케이션은 THP 대신 사전 할당된 대규모 페이지를 사용하도록 설계(또는 권장)할 수 있습니다.

OpenShift Container Platform에서는 Pod의 애플리케이션이 사전 할당된 대규모 페이지를 할당하고 사용할 수 있습니다.

14.2. 앱에서 대규모 페이지를 사용하는 방법

노드에서 대규모 페이지 용량을 보고하려면 노드가 대규모 페이지를 사전 할당해야 합니다. 노드는 단일 크기의 대규모 페이지만 사전 할당할 수 있습니다.

대규모 페이지는 hugepages-<size> 리소스 이름으로 컨테이너 수준 리소스 요구사항에 따라 사용할 수 있습니다. 여기서 크기는 특정 노드에서 지원되는 정수 값이 사용된 가장 간단한 바이너리 표현입니다. 예를 들어 노드에서 2,048KiB 페이지 크기를 지원하는 경우 예약 가능한 리소스 hugepages-2Mi를 공개합니다. CPU 또는 메모리와 달리 대규모 페이지는 초과 커밋을 지원하지 않습니다. 

apiVersion: v1
kind: Pod
metadata:
  generateName: hugepages-volume-
spec:
  containers:
  - securityContext:
      privileged: true
    image: rhel7:latest
    command:
    - sleep
    - inf
    name: example
    volumeMounts:
    - mountPath: /dev/hugepages
      name: hugepage
    resources:
      limits:
        hugepages-2Mi: 100Mi 1
        memory: "1Gi"
        cpu: "1"
  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages
1
hugepages의 메모리 양은 할당할 정확한 양으로 지정하십시오. 이 값을 hugepages의 메모리 양과 페이지 크기를 곱한 값으로 지정하지 마십시오. 예를 들어 대규모 페이지 크기가 2MB이고 애플리케이션에 100MB의 대규모 페이지 지원 RAM을 사용하려면 50개의 대규모 페이지를 할당합니다. OpenShift Container Platform에서 해당 계산을 처리합니다. 위의 예에서와 같이 100MB를 직접 지정할 수 있습니다.

특정 크기의 대규모 페이지 할당

일부 플랫폼에서는 여러 대규모 페이지 크기를 지원합니다. 특정 크기의 대규모 페이지를 할당하려면 대규모 페이지 부팅 명령 매개변수 앞에 대규모 페이지 크기 선택 매개변수 hugepagesz=<size>를 지정합니다. <size> 값은 바이트 단위로 지정해야 하며 스케일링 접미사 [kKmMgG]를 선택적으로 사용할 수 있습니다. 기본 대규모 페이지 크기는 default_hugepagesz=<size> 부팅 매개변수로 정의할 수 있습니다.

대규모 페이지 요구사항

  • 대규모 페이지 요청은 제한과 같아야 합니다. 제한은 지정되었으나 요청은 지정되지 않은 경우 제한이 기본값입니다.
  • 대규모 페이지는 Pod 범위에서 격리됩니다. 컨테이너 격리는 향후 반복에서 계획됩니다.
  • 대규모 페이지에서 지원하는 EmptyDir 볼륨은 Pod 요청보다 더 많은 대규모 페이지 메모리를 사용하면 안 됩니다.
  • SHM_HUGETLB로 shmget()를 통해 대규모 페이지를 사용하는 애플리케이션은 proc/sys/vm/hugetlb_shm_group과 일치하는 보조 그룹을 사용하여 실행되어야 합니다.

추가 리소스

14.3. 대규모 페이지 구성

노드는 OpenShift Container Platform 클러스터에서 사용되는 대규모 페이지를 사전 할당해야 합니다. 대규모 페이지 예약은 부팅 시 예약하는 방법과 런타임 시 예약하는 방법 두 가지가 있습니다. 부팅 시 예약은 메모리가 아직 많이 조각화되어 있지 않으므로 성공할 가능성이 높습니다. Node Tuning Operator는 현재 특정 노드에서 대규모 페이지에 대한 부팅 시 할당을 지원합니다.

14.3.1. 부팅 시

프로세스

노드 재부팅을 최소화하려면 다음 단계를 순서대로 수행해야 합니다.

  1. 동일한 대규모 페이지 설정이 필요한 모든 노드에 하나의 레이블을 지정합니다. 

    $ oc label node <node_using_hugepages> node-role.kubernetes.io/worker-hp=

  2. 다음 콘텐츠로 파일을 생성하고 이름을 hugepages-tuned-boottime.yaml로 지정합니다. 

    apiVersion: tuned.openshift.io/v1
kind: Tuned
metadata:
  name: hugepages 1
  namespace: openshift-cluster-node-tuning-operator
spec:
  profile: 2
  - data: |
      [main]
      summary=Boot time configuration for hugepages
      include=openshift-node
      [bootloader]
      cmdline_openshift_node_hugepages=hugepagesz=2M hugepages=50 3
    name: openshift-node-hugepages

  recommend:
  - machineConfigLabels: 4
      machineconfiguration.openshift.io/role: "worker-hp"
    priority: 30
    profile: openshift-node-hugepages
    1
    Tuned 리소스의 name을 hugepages로 설정합니다.
    2
    대규모 페이지를 할당할 profile 섹션을 설정합니다.
    3
    일부 플랫폼에서는 다양한 크기의 대규모 페이지를 지원하므로 매개변수 순서가 중요합니다.
    4
    머신 구성 풀 기반 일치를 활성화합니다.

  3. Tuned hugepages 프로필을 생성합니다. 

    $ oc create -f hugepages-tuned-boottime.yaml

  4. 다음 콘텐츠로 파일을 생성하고 이름을 hugepages-mcp.yaml로 지정합니다. 

    apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfigPool
metadata:
  name: worker-hp
  labels:
    worker-hp: ""
spec:
  machineConfigSelector:
    matchExpressions:
      - {key: machineconfiguration.openshift.io/role, operator: In, values: [worker,worker-hp]}
  nodeSelector:
    matchLabels:
      node-role.kubernetes.io/worker-hp: ""

  5. 머신 구성 풀을 생성합니다. 

    $ oc create -f hugepages-mcp.yaml

조각화되지 않은 메모리가 충분한 경우 worker-hp 머신 구성 풀의 모든 노드에 50개의 2Mi 대규모 페이지가 할당되어 있어야 합니다. 

$ oc get node <node_using_hugepages> -o jsonpath="{.status.allocatable.hugepages-2Mi}"
100Mi
주의

이 기능은 현재 RHCOS(Red Hat Enterprise Linux CoreOS) 8.x 작업자 노드에서만 지원됩니다. RHEL(Red Hat Enterprise Linux) 7.x 작업자 노드에서는 현재 Tuned [bootloader] 플러그인이 지원되지 않습니다.

15장. 대기 시간이 짧은 노드를 위한 Performance Addon Operator

15.1. 짧은 대기 시간 이해

Telco/5G 영역에서 Edge 컴퓨팅이 등장하여 대기 시간 및 정체 문제를 줄이고 애플리케이션 성능을 개선하는 데 핵심적인 역할을 하고 있습니다.

간단히 말해, 대기 시간이 데이터(패킷)가 발신자에서 수신자로 이동하고 수신자의 처리 후 발신자로 반환되는 속도를 결정합니다. 5G의 네트워크 성능 요구사항을 충족하려면 대기 시간 지연이 가능한 한 짧아지도록 네트워크 아키텍처를 유지보수하는 것이 중요합니다. 평균 대기 시간이 50ms인 4G 기술에 비해, 5G에서는 1ms 이하의 대기 시간 수치에 도달하는 것을 목표로 합니다. 이렇게 대기 시간이 감소하면 무선 처리량이 10배 증가합니다.

Telco 공간에 배포된 많은 애플리케이션에서는 제로 패킷 손실이 가능한 짧은 대기 시간을 요구하고 있습니다. 제로 패킷 손실 튜닝은 네트워크 성능을 저하시키는 고유한 문제를 완화하는 데 도움이 됩니다. 자세한 내용은 RHOSP(Red Hat OpenStack Platform)에서 제로 패킷 손실 튜닝을 참조하십시오.

Edge 컴퓨팅 이니셔티브는 대기 시간을 줄이는 데에도 큰 역할을 합니다. 말 그대로 클라우드 엣지(Edge)에 있어 사용자에게 더 가깝다고 생각해 보십시오. 이렇게 되면 멀리 있는 데이터 센터와 사용자 간 거리를 크게 줄여 애플리케이션 응답 시간과 성능 대기 시간이 단축됩니다.

관리자는 많은 엣지 사이트와 로컬 서비스를 중앙 집중식으로 관리하여 가능한 한 가장 낮은 관리 비용으로 모든 배포를 실행할 수 있어야 합니다. 또한, 실시간 짧은 대기 시간과 높은 성능을 실현할 수 있도록 클러스터의 특정 노드를 쉽게 배포하고 구성할 수 있어야 합니다. 대기 시간이 짧은 노드는 CNF(클라우드 네이티브 네트워크 기능) 및 DPDK(데이터 플레인 개발 키트)와 같은 애플리케이션에 유용합니다.

OpenShift Container Platform에서는 현재 실시간 실행과 짧은 대기 시간(약 20마이크로초 미만의 반응 시간)을 지원하기 위해 OpenShift Container Platform 클러스터의 소프트웨어를 튜닝하는 메커니즘을 제공합니다. 이 메커니즘에는 커널 및 OpenShift Container Platform 설정 값 튜닝, 커널 설치, 머신 재구성이 포함되어 있습니다. 하지만 이 방법을 사용하려면 4가지 Operator를 설정해야 하며 수동으로 수행할 경우 복잡하고 실수하기 쉬운 많은 구성을 수행해야 합니다.

OpenShift Container Platform에서는 OpenShift 애플리케이션에 대해 짧은 대기 시간 성능을 실현할 수 있도록 자동 튜닝을 구현하는 Performance Addon Operator를 제공합니다. 클러스터 관리자는 이 성능 프로필 구성을 사용하여 보다 안정적인 방식으로 이러한 변경을 더욱 쉽게 수행할 수 있습니다. 관리자는 커널을 커널-rt로 업데이트할 것인지 여부, 하우스키핑용으로 예약할 CPU, 워크로드 실행에 사용할 CPU를 지정할 수 있습니다.

15.2. Performance Addon Operator 설치

Performance Addon Operator는 노드 세트에서 고급 노드 성능 튜닝을 활성화하는 기능을 제공합니다. 클러스터 관리자는 OpenShift Container Platform CLI 또는 웹 콘솔을 사용하여 Performance Addon Operator를 설치할 수 있습니다.

15.2.1. CLI를 사용하여 Operator 설치

클러스터 관리자는 CLI를 사용하여 Operator를 설치할 수 있습니다.

전제 조건

  • 클러스터가 베어 메탈 하드웨어에 설치되어 있어야 합니다.
  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.

프로세스

  1. 다음 조치를 완료하여 Performance Addon Operator의 네임스페이스를 생성합니다.

    1. openshift-performance-addon-operator 네임스페이스를 정의하는 다음 네임스페이스 CR(사용자 정의 리소스)을 생성하고 해당 YAML을 pao-namespace.yaml 파일에 저장합니다. 

      apiVersion: v1
kind: Namespace
metadata:
  name: openshift-performance-addon-operator

    2. 다음 명령을 실행하여 네임스페이스를 생성합니다. 

      $ oc create -f pao-namespace.yaml

  2. 다음 오브젝트를 생성하여 이전 단계에서 생성한 네임스페이스에 Performance Addon Operator를 설치합니다.

    1. 다음 OperatorGroup CR을 생성하고 해당 YAML을 pao-operatorgroup.yaml 파일에 저장합니다. 

      apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: openshift-performance-addon-operator
  namespace: openshift-performance-addon-operator
spec:
  targetNamespaces:
  - openshift-performance-addon-operator

    2. 다음 명령을 실행하여 OperatorGroup CR을 생성합니다. 

      $ oc create -f pao-operatorgroup.yaml

    3. 다음 명령을 실행하여 후속 단계에 필요한 채널 값을 가져옵니다. 

      $ oc get packagemanifest performance-addon-operator -n openshift-marketplace -o jsonpath='{.status.defaultChannel}'

      출력 예

      4.6

    4. 다음 서브스크립션 CR을 생성하고 해당 YAML을 pao-sub.yaml 파일에 저장합니다.

      서브스크립션의 예

      apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: openshift-performance-addon-operator-subscription
  namespace: openshift-performance-addon-operator
spec:
  channel: "<channel>" 1
  name: performance-addon-operator
  source: redhat-operators 2
  sourceNamespace: openshift-marketplace

      1
      .status.defaultChannel 매개변수에 이전 단계에서 가져온 값을 지정합니다.
      2
      redhat-operators 값을 지정해야 합니다.

    5. 다음 명령을 실행하여 서브스크립션 오브젝트를 생성합니다. 

      $ oc create -f pao-sub.yaml

    6. openshift-performance-addon-operator 프로젝트로 변경합니다. 

      $ oc project openshift-performance-addon-operator

15.2.2. 웹 콘솔을 사용하여 Performance Addon Operator 설치

클러스터 관리자는 웹 콘솔을 사용하여 Performance Addon Operator를 설치할 수 있습니다.

참고

이전 섹션에서 언급한 것처럼 Namespace CR 및 OperatorGroup CR을 생성해야 합니다.

프로세스

  1. OpenShift Container Platform 웹 콘솔을 사용하여 Performance Addon Operator를 설치합니다.

    1. OpenShift Container Platform 웹 콘솔에서 Operator → OperatorHub를 클릭합니다.
    2. 사용 가능한 Operator 목록에서 Performance Addon Operator를 선택하고 설치를 클릭합니다.
    3. Operator 설치 페이지의 클러스터의 특정 네임스페이스에서 openshift-performance-addon-operator를 선택합니다. 그런 다음, 설치를 클릭합니다.

  2. 선택 사항: performance-addon-operator가 성공적으로 설치되었는지 확인합니다.

    1. Operator → 설치된 Operator 페이지로 전환합니다.

    2. Performance Addon Operator 가 openshift-operators 프로젝트에 성공 상태로 나열되어 있는지 확인합니다.

      참고

      설치 중에 Operator는 실패 상태를 표시할 수 있습니다. 나중에 Succeeded 메시지와 함께 설치에 성공하면 실패 메시지를 무시할 수 있습니다.

      Operator가 설치된 것으로 나타나지 않으면 추가 문제를 해결할 수 있습니다.

      • Operator → 설치된 Operator 페이지로 이동하고 Operator 서브스크립션 및 설치 계획 탭의 상태에 장애나 오류가 있는지 검사합니다.
      • 워크로드 → Pod 페이지로 이동하여 openshift-operators 프로젝트에서 Pod 로그를 확인합니다.

15.3. Performance Addon Operator 업그레이드

웹 콘솔을 사용하여 수동으로 Performance Addon Operator의 다음 마이너 버전으로 업그레이드하고 업데이트 상태를 모니터링할 수 있습니다.

15.3.1. Performance Addon Operator 업그레이드 정보

  • OpenShift 웹 콘솔을 사용하여 Operator 서브스크립션 채널을 변경하면 Performance Addon Operator의 다음 마이너 버전으로 업그레이드 할 수 있습니다.
  • Performance Addon Operator 설치 중에 자동 z-stream 업데이트를 활성화할 수 있습니다.
  • 업데이트는 OpenShift Container Platform 설치 중에 배포되는 Marketplace Operator를 통해 제공됩니다. Marketplace Operator는 클러스터에서 외부 Operator를 사용할 수 있도록 합니다.
  • 업데이트를 완료하는 데 걸리는 시간은 네트워크 연결에 따라 달라집니다. 대부분의 자동 업데이트는 15분 이내에 완료됩니다.
15.3.1.1. Performance Addon Operator 업그레이드가 클러스터에 미치는 영향
  • 대기 시간이 짧은 튜닝이나 많은 페이지 수는 클러스터에 영향을 미치지 않습니다.
  • Operator 업데이트로 인해 예기치 않은 재부팅이 발생하지 않습니다.
15.3.1.2. Performance Addon Operator를 다음 마이너 버전으로 업그레이드

OpenShift Container Platform 웹 콘솔을 사용하여 Operator 서브스크립션 채널을 변경하면 수동으로 Performance Addon Operator를 다음 마이너 버전으로 업그레이드할 수 있습니다.

전제 조건

  • cluster-admin 역할을 가진 사용자로 클러스터에 액세스합니다.

프로세스

  1. OpenShift 웹 콘솔에 액세스하여 Operator → 설치된 Operator로 이동합니다.
  2. Performance Addon Operator를 클릭하여 Operator 세부 정보 페이지를 엽니다.
  3. 서브스크립션 탭을 클릭하여 서브스크립션 개요 페이지를 엽니다.
  4. 채널 창에서 버전 번호 오른쪽의 연필 아이콘을 클릭하여 서브스크립션 업데이트 채널 변경 창을 엽니다.
  5. 다음 마이너 버전을 선택합니다. 예를 들어 Performance Addon Operator 4.6으로 업그레이드하려면 4.6을 선택합니다.
  6. 저장을 클릭합니다.

  7. Operator → 설치된 Operator로 이동하여 업그레이드 상태를 확인합니다. 다음 oc 명령을 실행하여 상태를 확인할 수도 있습니다. 

    $ oc get csv -n openshift-performance-addon-operator

15.3.2. 업그레이드 상태 모니터링

Performance Addon Operator 업그레이드 상태를 모니터링하는 가장 좋은 방법은 CSV(ClusterServiceVersion) PHASE를 확인하는 것입니다. 웹 콘솔에서 또는 oc get csv 명령을 실행하여 CSV 상태를 모니터링할 수도 있습니다.

참고

PHASE 및 조건 값은 사용 가능한 정보를 기반으로 한 근사치입니다.

전제 조건

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

절차

  1. 다음 명령을 실행합니다. 

    $ oc get csv

  2. PHASE 필드를 확인하여 출력을 검토합니다. 예를 들면 다음과 같습니다. 

    VERSION    REPLACES                                         PHASE
4.6.0      performance-addon-operator.v4.5.0                Installing
4.5.0                                                       Replacing

  3. get csv를 다시 실행하여 출력을 검증합니다. 

    # oc get csv

    출력 예

    NAME                                DISPLAY                      VERSION   REPLACES                            PHASE
performance-addon-operator.v4.5.0   Performance Addon Operator   4.6.0     performance-addon-operator.v4.5.0   Succeeded

15.4. 실시간 및 짧은 대기 시간 워크로드 프로비저닝

많은 업계와 조직에서 매우 높은 성능의 컴퓨팅을 필요로 하고 있으며 특히 금융 및 통신 업계에서는 짧고 예측 가능한 대기 시간이 요구될 수 있습니다. 고유한 요구사항을 가지고 있는 이러한 업계에서 사용할 수 있도록 OpenShift Container Platform에서는 OpenShift Container Platform 애플리케이션에 대해 짧은 대기 시간 성능과 일관된 응답 시간을 실현할 수 있도록 자동 튜닝을 구현하는 Performance Addon Operator를 제공합니다.

클러스터 관리자는 이 성능 프로필 구성을 사용하여 보다 안정적인 방식으로 이러한 변경을 더욱 쉽게 수행할 수 있습니다. 관리자는 커널을 커널-rt(실시간)로 업데이트할 것인지 여부, 하우스키핑용으로 예약할 CPU, 워크로드 실행에 사용할 CPU를 지정할 수 있습니다.

주의

보장된 CPU가 필요한 애플리케이션과 함께 실행 프로브를 사용하면 대기 시간이 급증할 수 있습니다. 올바르게 구성된 네트워크 프로브 세트와 같은 기타 프로브를 대안으로 사용하는 것이 좋습니다.

15.4.1. 실시간에 대한 알려진 제한 사항

참고

RT 커널은 작업자 노드에서만 지원됩니다.

실시간 모드를 완전히 활용하려면 상승된 권한으로 컨테이너를 실행해야 합니다. 권한 부여에 대한 자세한 내용은 컨테이너에 대한 기능 설정을 참조하십시오.

OpenShift Container Platform에서는 허용되는 기능을 제한하므로 SecurityContext를 생성해야 할 수도 있습니다.

참고

RHCOS(Red Hat Enterprise Linux CoreOS) 시스템을 사용하는 베어 메탈 설치에서는 이러한 절차가 완전하게 지원됩니다.

적합한 성능 기대치를 설정한다는 것은 실시간 커널이 만능 해결책이 아니라는 것을 나타냅니다. 설정의 목표는 예측 가능한 응답 시간을 제공하는 일관되고 대기 시간이 짧은 결정성을 갖추는 것입니다. 실시간 커널에는 연관된 추가 커널 오버헤드가 있습니다. 이러한 오버헤드는 주로 별도로 예약된 스레드에서 하드웨어 중단을 처리하는 데서 발생합니다. 일부 워크로드에서 오버헤드가 증가하면 전반적으로 처리량 성능이 저하됩니다. 정확한 저하 수치는 워크로드에 따라 달라지며, 범위는 0%에서 30% 사이입니다. 하지만 이러한 저하는 결정성에 대한 대가입니다.

15.4.2. 실시간 기능이 있는 작업자 프로비저닝

  1. 클러스터에 Performance Addon Operator를 설치합니다.
  2. 선택 사항: OpenShift Container Platform 클러스터에 노드를 추가합니다. BIOS 매개변수 설정을 참조하십시오.
  3. oc 명령을 사용하여 실시간 기능이 필요한 작업자 노드에 worker-rt 레이블을 추가합니다.

  4. 실시간 노드에 대한 새 머신 구성 풀을 생성합니다. 

    apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfigPool
metadata:
  name: worker-rt
  labels:
    machineconfiguration.openshift.io/role: worker-rt
spec:
  machineConfigSelector:
    matchExpressions:
      - {
           key: machineconfiguration.openshift.io/role,
           operator: In,
           values: [worker, worker-rt],
        }
  paused: false
  nodeSelector:
    matchLabels:
      node-role.kubernetes.io/worker-rt: ""

    worker-rt 레이블이 있는 노드 그룹에 대해 머신 구성 풀 worker-rt 가 생성됩니다.

  5. 노드 역할 레이블을 사용하여 적절한 머신 구성 풀에 노드를 추가합니다.

    참고

    실시간 워크로드로 구성된 노드를 결정해야 합니다. 클러스터의 모든 노드 또는 노드의 하위 집합을 구성할 수 있습니다. 모든 노드를 예상하는 Performance Addon Operator는 전용 머신 구성 풀의 일부입니다. 모든 노드를 사용하는 경우 작업자 노드 역할 레이블을 Performance Addon Operator를 가리켜야 합니다. 서브 세트를 사용하는 경우 해당 노드를 새 머신 구성 풀로 그룹화해야 합니다.

  6. 적절한 하우스키핑 코어 세트와 realTimeKernel: enabled: true를 사용하여 PerformanceProfile을 생성합니다.

  7. PerformanceProfile 에서 machineConfigPoolSelector 를 설정해야 합니다. 

      apiVersion: performance.openshift.io/v2
  kind: PerformanceProfile
  metadata:
   name: example-performanceprofile
  spec:
  ...
    realTimeKernel:
      enabled: true
    nodeSelector:
       node-role.kubernetes.io/worker-rt: ""
    machineConfigPoolSelector:
       machineconfiguration.openshift.io/role: worker-rt

  8. 레이블과 일치하는 머신 구성 풀이 있는지 검증합니다. 

    $ oc describe mcp/worker-rt

    출력 예

    Name:         worker-rt
Namespace:
Labels:       machineconfiguration.openshift.io/role=worker-rt

  9. OpenShift Container Platform에서 노드 구성을 시작합니다. 이 작업에서는 여러 번 재부팅이 수행될 수 있습니다. 노드가 설정될 때까지 기다리십시오. 사용하는 하드웨어에 따라 시간이 오래 걸릴 수 있으며 노드당 20분으로 예상됩니다.
  10. 모든 요소가 예상대로 작동하는지 검증하십시오.

15.4.3. 실시간 커널 설치 검증

다음 명령을 사용하여 실시간 커널이 설치되었는지 검증합니다. 

$ oc get node -o wide

4.18.0-211.rt5.23.el8.x86_64 문자열이 포함된 worker-rt 역할의 작업자를 확인합니다. 

NAME                               	STATUS   ROLES           	AGE 	VERSION                  	INTERNAL-IP
EXTERNAL-IP   OS-IMAGE                                       	KERNEL-VERSION
CONTAINER-RUNTIME
rt-worker-0.example.com	            Ready	 worker,worker-rt   5d17h   v1.22.1
128.66.135.107   <none>    	        Red Hat Enterprise Linux CoreOS 46.82.202008252340-0 (Ootpa)
4.18.0-211.rt5.23.el8.x86_64   cri-o://1.19.0-90.rhaos4.6.git4a0ac05.el8-rc.1
[...]

15.4.4. 실시간으로 작동하는 워크로드 생성

실시간 기능을 사용할 워크로드를 준비하려면 다음 절차를 사용하십시오.

프로세스

  1. QoS 클래스가 Guaranteed인 Pod를 생성합니다.
  2. 선택 사항: DPDK의 CPU 로드 밸런싱을 비활성화합니다.
  3. 적절한 노드 선택기를 할당합니다.

애플리케이션을 작성하는 경우 애플리케이션 튜닝 및 배포에 설명된 일반 권장 사항을 따르십시오.

15.4.5. QoS 클래스가 Guaranteed인 Pod 생성

QoS 클래스가 Guaranteed로 지정된 Pod를 생성하는 경우 다음 사항에 유의하십시오.

  • Pod의 모든 컨테이너에는 메모리 제한과 메모리 요청이 있어야 하며 동일해야 합니다.
  • Pod의 모든 컨테이너에는 CPU 제한과 CPU 요청이 있어야 하며 동일해야 합니다.

다음 예에서는 컨테이너가 하나인 Pod의 구성 파일을 보여줍니다. 이 컨테이너에는 메모리 제한과 메모리 요청이 있으며 둘 다 200MiB입니다. 이 컨테이너에는 CPU 제한과 CPU 요청이 있으며 둘 다 CPU 1개입니다. 

apiVersion: v1
kind: Pod
metadata:
  name: qos-demo
  namespace: qos-example
spec:
  containers:
  - name: qos-demo-ctr
    image: <image-pull-spec>
    resources:
      limits:
        memory: "200Mi"
        cpu: "1"
      requests:
        memory: "200Mi"
        cpu: "1"

  1. Pod를 생성합니다. 

    $ oc  apply -f qos-pod.yaml --namespace=qos-example

  2. Pod에 대한 자세한 정보를 봅니다. 

    $ oc get pod qos-demo --namespace=qos-example --output=yaml

    출력 예

    spec:
  containers:
    ...
status:
  qosClass: Guaranteed

    참고

    컨테이너가 자체 메모리 제한은 지정하지만 메모리 요청은 지정하지 않으면 OpenShift Container Platform에서 제한과 일치하는 메모리 요청을 자동으로 할당합니다. 마찬가지로, 컨테이너가 자체 CPU 제한은 지정하지만 CPU 요청은 지정하지 않으면 OpenShift Container Platform에서 제한과 일치하는 CPU 요청을 자동으로 할당합니다.

15.4.6. 선택 사항: DPDK의 CPU 로드 밸런싱 비활성화

CPU 부하 분산을 비활성화하거나 활성화하는 기능은 CRI-O 수준에서 구현됩니다. CRI-O 아래의 코드는 다음 요구사항이 충족되는 경우에만 CPU 부하 분산을 비활성화하거나 활성화합니다.

  • Pod는 performance-<profile-name> 런타임 클래스를 사용해야 합니다. 다음과 같이 성능 프로필의 상태를 보고 적절한 이름을 가져올 수 있습니다. 

    apiVersion: performance.openshift.io/v1
kind: PerformanceProfile
...
status:
  ...
  runtimeClass: performance-manual
  • Pod에는 cpu-load-balancing.crio.io: true 주석이 있어야 합니다.

Performance Addon Operator는 관련 노드 아래에 고성능 런타임 처리기 구성 스니펫을 생성해야 하고 클러스터 아래에 고성능 런타임 클래스를 생성해야 합니다. CPU 부하 분산 구성 기능을 활성화하는 것을 제외하고는 기본 런타임 처리기와 콘텐츠가 동일합니다.

Pod에 대해 CPU 부하 분산을 비활성화하려면 Pod 사양에 다음 필드가 포함되어야 합니다. 

apiVersion: v1
kind: Pod
metadata:
  ...
  annotations:
    ...
    cpu-load-balancing.crio.io: "true"
    ...
  ...
spec:
  ...
  runtimeClassName: performance-<profile_name>
  ...
참고

CPU 관리자 static 정책이 활성화되어 있는 경우 전체 CPU를 사용하는 guaranteed QoS가 있는 Pod에 대해서만 CPU 부하 분산을 비활성화하십시오. 그렇지 않은 경우 CPU 부하 분산을 비활성화하면 클러스터에 있는 다른 컨테이너의 성능에 영향을 미칠 수 있습니다.

15.4.7. 적절한 노드 선택기 할당

노드에 Pod를 할당하는 기본 방법은 다음과 같이 성능 프로필에서 사용한 것과 동일한 노드 선택기를 사용하는 것입니다. 

apiVersion: v1
kind: Pod
metadata:
  name: example
spec:
  # ...
  nodeSelector:
    node-role.kubernetes.io/worker-rt: ""

자세한 내용은 노드 선택기를 사용하여 특정 노드에 Pod 배치를 참조하십시오.

15.4.8. 실시간 기능이 있는 작업자에 대해 워크로드 예약

Performance Addon Operator에서 짧은 대기 시간을 위해 구성한 머신 구성 풀에 연결된 노드와 일치하는 레이블 선택기를 사용합니다. 자세한 내용은 노드에 Pod 할당을 참조하십시오.

15.5. 대규모 페이지 구성

노드는 OpenShift Container Platform 클러스터에서 사용되는 대규모 페이지를 사전 할당해야 합니다. Performance Addon Operator를 사용하여 특정 노드에 대규모 페이지를 할당하십시오.

OpenShift Container Platform에서는 대규모 페이지를 생성하고 할당하는 방법을 제공합니다. Performance Addon Operator는 성능 프로필을 사용하여 더 쉽게 이 작업을 수행하는 방법을 제공합니다.

예를 들어 성능 프로필의 hugepages pages 섹션에서 size, count 및 node(선택사항)로 된 여러 블록을 지정할 수 있습니다. 

hugepages:
   defaultHugepagesSize: "1G"
   pages:
   - size:  "1G"
     count:  4
     node:  0 1
1
node는 대규모 페이지가 할당된 NUMA 노드입니다. node를 생략하면 페이지가 모든 NUMA 노드에 균등하게 분산됩니다.
참고

관련 머신 구성 풀 상태에 업데이트가 완료된 것으로 나타날 때까지 기다립니다.

대규모 페이지를 할당하기 위해 수행해야 하는 구성 단계는 이것이 전부입니다.

검증

  • 구성을 검증하려면 노드의 /proc/meminfo 파일을 참조하십시오. 

    $ oc debug node/ip-10-0-141-105.ec2.internal
    # grep -i huge /proc/meminfo

    출력 예

    AnonHugePages:    ###### ##
ShmemHugePages:        0 kB
HugePages_Total:       2
HugePages_Free:        2
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       #### ##
Hugetlb:            #### ##

  • oc describe를 사용하여 새 크기를 보고합니다. 

    $ oc describe node worker-0.ocp4poc.example.com | grep -i huge

    출력 예

                                       hugepages-1g=true
 hugepages-###:  ###
 hugepages-###:  ###

15.6. 여러 대규모 페이지 크기 할당

동일한 컨테이너에서 다양한 크기의 대규모 페이지를 요청할 수 있습니다. 이 경우 다양한 대규모 페이지 크기 요구사항이 있는 컨테이너로 구성된 더 복잡한 Pod를 정의할 수 있습니다.

예를 들어 1G 및 2M 크기를 정의할 수 있습니다. 그러면 Performance Addon Operator가 다음과 같이 노드에서 크기를 둘 다 구성합니다. 

spec:
  hugepages:
    defaultHugepagesSize: 1G
    pages:
    - count: 1024
      node: 0
      size: 2M
    - count: 4
      node: 1
      size: 1G

15.7. 인프라 및 애플리케이션 컨테이너의 CPU 제한

일반 하우스키핑 및 워크로드 작업은 대기 시간에 민감한 프로세스에 영향을 미칠 수 있는 방식으로 CPU를 사용합니다. 기본적으로 컨테이너 런타임은 모든 온라인 CPU를 사용하여 모든 컨테이너를 함께 실행하여 컨텍스트 스위치와 대기 시간이 급증할 수 있습니다. CPU를 분할하면 noisy 프로세스가 서로 분리되어 대기 시간에 민감한 프로세스를 방해할 수 없습니다. 다음 표에서는 Performance Addon Operator를 사용하여 노드를 튜닝한 후 CPU에서 프로세스가 실행되는 방법을 설명합니다.

표 15.1. 프로세스의 CPU 할당
프로세스 유형세부 정보

Burstable 및 BestEffort Pod

대기 시간이 짧은 워크로드가 실행 중인 위치를 제외하고 모든 CPU에서 실행

인프라 Pod

대기 시간이 짧은 워크로드가 실행 중인 위치를 제외하고 모든 CPU에서 실행

인터럽트

예약된 CPU로 리디렉션(OpenShift Container Platform 4.6 이상에서 선택 사항)

커널 프로세스

예약된 CPU에 고정

대기 시간에 민감한 워크로드 Pod

분리된 풀에서 특정 전용 CPU 세트에 고정

OS 프로세스/systemd 서비스

예약된 CPU에 고정

모든 QoS 프로세스 유형, Burstable,BestEffort 또는 Guaranteed 의 Pod에 대해 노드에 있는 코어의 할당 가능 용량은 격리된 풀의 용량과 동일합니다. 예약된 풀의 용량은 클러스터 및 운영 체제 하우스키핑 작업에서 사용할 노드의 총 코어 용량에서 제거됩니다.

예시 1

노드에는 100개의 코어 용량이 있습니다. 클러스터 관리자는 성능 프로필을 사용하여 분리된 풀에 50개의 코어를 할당하고 예약된 풀에 50개의 코어를 할당합니다. 클러스터 관리자는 BestEffort 또는 Burstable Pod에 대해 QoS가 보장된 Pod 및 25개의 코어를 25개에 할당합니다. 이는 격리된 풀의 용량과 일치합니다.

예시 2

노드에는 100개의 코어 용량이 있습니다. 클러스터 관리자는 성능 프로필을 사용하여 분리된 풀에 50개의 코어를 할당하고 예약된 풀에 50개의 코어를 할당합니다. 클러스터 관리자는 QoS가 보장된 Pod에 50개의 코어를 할당하고 BestEffort 또는 Burstable Pod의 코어 1개를 할당합니다. 이는 하나의 코어로 격리된 풀의 용량을 초과합니다. CPU 용량이 부족하여 Pod 예약에 실패합니다.

사용할 정확한 파티션 패턴은 하드웨어, 워크로드 특성 및 예상되는 시스템 로드와 같은 여러 요인에 따라 달라집니다. 일부 샘플 사용 사례는 다음과 같습니다.

  • 대기 시간에 민감한 워크로드에서 NIC(네트워크 인터페이스 카드)와 같은 특정 하드웨어를 사용하는 경우 분리된 풀의 CPU가 이 하드웨어에 최대한 가깝게 있어야 합니다. 최소한 동일한 NUMA(Non-Uniform Memory Access) 노드에 워크로드를 배치해야 합니다.
  • 예약된 풀은 모든 인터럽트를 처리하는 데 사용됩니다. 시스템 네트워킹에 따른 경우 충분한 크기의 예약 풀을 할당하여 들어오는 모든 패킷 인터럽트를 처리합니다. 4.6 이상 버전에서 워크로드는 선택적으로 중요로 레이블을 지정할 수 있습니다. 예약 및 분리된 파티션에 사용할 특정 CPU에 대한 결정에는 자세한 분석과 측정이 필요합니다. 장치 및 메모리의 NUMA 선호도와 같은 요인은 역할을 합니다. 선택 사항은 워크로드 아키텍처 및 특정 사용 사례에 따라 달라집니다.
중요

예약 및 격리된 CPU 풀이 겹치지 않아야 하며 작업자 노드에서 사용 가능한 모든 코어에 걸쳐 있어야 합니다.

하우스키핑 작업 및 워크로드가 서로 간섭하지 않도록 성능 프로파일의 spec 섹션에 두 개의 CPU 그룹을 지정합니다.

  • isolated - 애플리케이션 컨테이너 워크로드의 CPU를 지정합니다. 이러한 CPU에서 실행되는 워크로드는 짧은 대기 시간과 제로 중단을 경험하고 예를 들어 높은 제로 패킷 손실 대역폭에 도달할 수 있습니다.

  • reserved - 클러스터 및 운영 체제 하우스키핑 작업의 CPU를 지정합니다. 예약 그룹의 스레드는 종종 사용 중입니다. 예약된 그룹에서 대기 시간에 민감한 애플리케이션을 실행하지 마십시오. 대기 시간에 민감한 애플리케이션은 격리된 그룹에서 실행됩니다. .Procedure

    1. 환경 하드웨어 및 토폴로지에 적합한 성능 프로필을 생성합니다.

    2. 인프라 및 애플리케이션 컨테이너에 대해 reserved 및 isolated하려는 CPU와 함께 예약 및 격리된 매개변수를 추가합니다. 

      apiVersion: performance.openshift.io/v2
kind: PerformanceProfile
metadata:
  name: infra-cpus
spec:
  cpu:
    reserved: "0-4,9" 1
    isolated: "5-8" 2
  nodeSelector: 3
    node-role.kubernetes.io/worker: ""
      1
      클러스터 및 운영 체제 하우스키핑 작업을 수행하기 위해 인프라 컨테이너의 CPU를 지정합니다.
      2
      애플리케이션 컨테이너가 워크로드를 실행하는 CPU를 지정합니다.
      3
      성능 프로필을 특정 노드에 적용하려면 노드 선택기를 지정합니다.

15.8. 성능 프로필을 사용하여 짧은 대기 시간을 실현하도록 노드 튜닝

성능 프로필을 사용하면 특정 머신 구성 풀에 속한 노드의 대기 시간 튜닝 측면을 제어할 수 있습니다. 설정을 지정하면 PerformanceProfile 오브젝트가 실제 노드 수준 튜닝을 수행하는 여러 오브젝트로 컴파일됩니다.

  • MachineConfig 파일은 노드를 조작합니다.
  • KubeletConfig 파일은 토폴로지 관리자, CPU 관리자 및 OpenShift Container Platform 노드를 구성합니다.
  • Tuned 프로필은 Node Tuning Operator를 구성합니다.

프로세스

  1. 클러스터를 준비합니다.
  2. 머신 구성 풀을 생성합니다.
  3. Performance Addon Operator를 설치합니다.

  4. 하드웨어 및 토폴로지에 적합한 성능 프로필을 생성합니다. 성능 프로필에서는 커널을 커널-rt로 업데이트할 것인지 여부, 대규모 페이지 할당, 운영 체제 하우스키핑 프로세스용으로 예약할 CPU, 워크로드 실행에 사용할 CPU를 지정할 수 있습니다.

    일반적인 성능 프로필은 다음과 같습니다. 

    apiVersion: performance.openshift.io/v1
kind: PerformanceProfile
metadata:
 name: performance
spec:
 cpu:
  isolated: "5-15"
  reserved: "0-4"
 hugepages:
  defaultHugepagesSize: "1G"
  pages:
  -size: "1G"
   count: 16
   node: 0
 realTimeKernel:
  enabled: true  1
 numa:  2
  topologyPolicy: "best-effort"
 nodeSelector:
  node-role.kubernetes.io/worker-cnf: ""
1
유효한 값은 true 또는 false입니다. true 값을 설정하면 노드에 실시간 커널이 설치됩니다.
2
이 필드를 사용하여 토폴로지 관리자 정책을 구성합니다. 유효한 값은 none(기본값), best-effort, restricted 및 single-numa-node입니다. 자세한 내용은 토폴로지 관리자 정책을 참조하십시오.

15.9. 플랫폼 검증을 위해 엔드 투 엔드 테스트 수행

CNF(클라우드 네이티브 네트워크 기능) 테스트 이미지는 CNF 페이로드를 실행하는 데 필요한 기능을 검증하는 컨테이너화된 테스트 모음입니다. 이 이미지를 사용하여 CNF 워크로드 실행에 필요한 모든 구성 요소가 설치된 CNF 지원 OpenShift 클러스터를 검증할 수 있습니다.

이미지를 통해 실행되는 테스트는 세 단계로 나뉩니다.

  • 간단한 클러스터 검증
  • 설정
  • 엔드 투 엔드 테스트

검증 단계에서는 테스트에 필요한 모든 기능이 클러스터에 올바르게 배포되어 있는지 확인합니다.

검증 작업은 다음과 같이 이루어져 있습니다.

  • 테스트할 머신에 속한 머신 구성 풀을 대상으로 지정
  • 노드에서 SCTP 활성화
  • Performance Addon Operator 설치
  • SR-IOV Operator 설치
  • PTP Operator 설치
  • OVN kubernetes를 SDN으로 사용

테스트를 실행할 때마다 환경 구성을 수행해야 합니다. 여기에는 SR-IOV 노드 정책, 성능 프로필 또는 PTP 프로파일 생성과 같은 항목이 포함됩니다. 테스트에서 이미 구성된 클러스터를 구성하도록 허용하는 경우 클러스터의 기능에 영향을 미칠 수 있습니다. 또한 SR-IOV 노드 정책과 같은 구성 항목을 변경하면 구성 변경이 처리될 때까지 환경을 일시적으로 사용할 수 없게 될 수 있습니다.

15.9.1. 전제 조건

  • 테스트 진입점은 /usr/bin/test-run.sh입니다. 설정 테스트 세트와 실제 적합성 테스트 모음을 모두 실행합니다. 최소 요구사항은 볼륨을 통해 마운트된 kubeconfig 파일 및 관련 $KUBECONFIG 환경 변수를 제공하는 것입니다.
  • 테스트에서는 지정된 기능을 Operator, 클러스터에서 활성화된 플래그 또는 머신 구성의 형태로 클러스터에서 이미 사용할 수 있다고 가정합니다.

  • 일부 테스트에서는 변경사항을 추가할 기존 머신 구성 풀이 필요합니다. 이러한 풀은 테스트 실행 전 클러스터에 생성되어 있어야 합니다.

    기본 작업자 풀은 worker-cnf이며, 다음 매니페스트를 사용하여 생성할 수 있습니다. 

    apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfigPool
metadata:
  name: worker-cnf
  labels:
    machineconfiguration.openshift.io/role: worker-cnf
spec:
  machineConfigSelector:
    matchExpressions:
      - {
          key: machineconfiguration.openshift.io/role,
          operator: In,
          values: [worker-cnf, worker],
        }
  paused: false
  nodeSelector:
    matchLabels:
      node-role.kubernetes.io/worker-cnf: ""

    ROLE_WORKER_CNF 변수를 사용하여 작업자 풀 이름을 재정의할 수 있습니다. 

    $ docker run -v $(pwd)/:/kubeconfig -e KUBECONFIG=/kubeconfig/kubeconfig -e
ROLE_WORKER_CNF=custom-worker-pool registry.redhat.io/openshift4/cnf-tests-rhel8:v4.6 /usr/bin/test-run.sh
    참고

    현재는 풀에 속한 노드에서 일부 테스트가 선택적으로 실행되지 않습니다.

15.9.2. 테스트 실행

파일이 현재 폴더에 있다고 가정하면 테스트 모음을 실행하는 명령은 다음과 같습니다. 

$ docker run -v $(pwd)/:/kubeconfig -e KUBECONFIG=/kubeconfig/kubeconfig registry.redhat.io/openshift4/cnf-tests-rhel8:v4.6 /usr/bin/test-run.sh

이 명령을 사용하면 실행 중인 컨테이너 내부에서 kubeconfig 파일을 사용할 수 있습니다.

15.9.3. 이미지 매개변수

요구사항에 따라 테스트에서 다른 이미지를 사용할 수 있습니다. 테스트에 사용되며 환경 변수를 통해 변경할 수 있는 이미지는 다음 두 가지입니다.

  • CNF_TESTS_IMAGE
  • DPDK_TESTS_IMAGE

예를 들어 사용자 정의 레지스트리로 CNF_TESTS_IMAGE를 변경하려면 다음 명령을 실행합니다. 

$ docker run -v $(pwd)/:/kubeconfig -e KUBECONFIG=/kubeconfig/kubeconfig -e CNF_TESTS_IMAGE="custom-cnf-tests-image:latests" registry.redhat.io/openshift4/cnf-tests-rhel8:v4.6 /usr/bin/test-run.sh
15.9.3.1. Ginkgo 매개변수

테스트 모음은 ginkgo BDD 프레임워크를 기반으로 빌드됩니다. 즉, 테스트를 필터링하거나 건너뛰는 매개변수를 사용할 수 있습니다.

-ginkgo.focus 매개변수를 사용하면 테스트 세트를 필터링할 수 있습니다. 

$ docker run -v $(pwd)/:/kubeconfig -e KUBECONFIG=/kubeconfig/kubeconfig registry.redhat.io/openshift4/cnf-tests-rhel8:v4.6 /usr/bin/test-run.sh -ginkgo.focus="performance|sctp"
참고

SR-IOV 및 SCTP가 둘 다 필요한 특정 테스트가 있습니다. 이 테스트는 focus 매개변수의 선택적 특성을 고려하여 sriov 선택기 배치를 통해서만 트리거됩니다. SR-IOV는 설치되어 있지만 SCTP는 설치되어 있지 않은 클러스터에 대해 이 테스트를 실행하는 경우 -ginkgo.skip=SCTP 매개변수를 추가하면 테스트에서 SCTP 테스트를 건너뜁니다.

15.9.3.2. 사용 가능한 기능

필터링할 수 있는 기능 세트는 다음과 같습니다.

  • performance
  • sriov
  • ptp
  • sctp
  • dpdk

15.9.4. 시험 실행

시험 실행 모드로 실행하려면 다음 명령을 사용하십시오. 이 모드는 테스트 모음의 내용을 확인하는 데 유용하며 이미지가 실행하는 모든 테스트에 대한 출력을 제공합니다. 

$ docker run -v $(pwd)/:/kubeconfig -e KUBECONFIG=/kubeconfig/kubeconfig registry.redhat.io/openshift4/cnf-tests-rhel8:v4.6 /usr/bin/test-run.sh -ginkgo.dryRun -ginkgo.v

15.9.5. 연결 해제 모드

CNF 테스트 이미지는 연결이 해제된 클러스터 즉, 외부 레지스트리에 접근할 수 없는 클러스터에서의 테스트 실행을 지원합니다. 이러한 테스트는 다음 두 단계로 이루어져 있습니다.

  1. 미러링을 수행합니다.
  2. 사용자 정의 레지스트리의 이미지를 사용하도록 테스트에 지시합니다.
15.9.5.1. 클러스터에서 액세스할 수 있는 사용자 정의 레지스트리로 이미지 미러링

이미지에 mirror 실행 파일이 있어서 oc에서 테스트를 실행하는 데 필요한 이미지를 로컬 레지스트리로 미러링하는 데 사용해야 하는 입력을 제공합니다.

인터넷을 통해 registry.redhat.io 및 클러스터 둘 다에 액세스할 수 있는 임시 머신에서 다음 명령을 실행하십시오. 

$ docker run -v $(pwd)/:/kubeconfig -e KUBECONFIG=/kubeconfig/kubeconfig registry.redhat.io/openshift4/cnf-tests-rhel8:v4.6 /usr/bin/mirror -registry my.local.registry:5000/ |  oc image mirror -f -

그런 다음, 이미지 가져오기에 사용되는 레지스트리를 재정의하는 방법에 대한 다음 섹션의 지침을 따릅니다.

15.9.5.2. 사용자 정의 레지스트리의 이미지를 사용하도록 테스트에 지시

이 작업은 다음과 같이 IMAGE_REGISTRY 환경 변수를 설정하여 수행합니다. 

$ docker run -v $(pwd)/:/kubeconfig -e KUBECONFIG=/kubeconfig/kubeconfig -e IMAGE_REGISTRY="my.local.registry:5000/" -e CNF_TESTS_IMAGE="custom-cnf-tests-image:latests" registry.redhat.io/openshift4/cnf-tests-rhel8:v4.6 /usr/bin/test-run.sh
15.9.5.3. 클러스터 내부 레지스트리로 미러링

OpenShift Container Platform은 클러스터에서 표준 워크로드로 실행되는 내장 컨테이너 이미지 레지스트리를 제공합니다.

프로세스

  1. 경로를 통해 레지스트리를 공개하여 레지스트리에 대한 외부 액세스 권한을 얻습니다. 

    $ oc patch configs.imageregistry.operator.openshift.io/cluster --patch '{"spec":{"defaultRoute":true}}' --type=merge

  2. 레지스트리 끝점을 가져옵니다. 

    REGISTRY=$(oc get route default-route -n openshift-image-registry --template='{{ .spec.host }}')

  3. 이미지를 공개하는 데 사용할 네임스페이스를 생성합니다. 

    $ oc create ns cnftests

  4. 테스트에 사용되는 모든 네임스페이스에서 해당 이미지 스트림을 사용할 수 있도록 합니다. 테스트 네임스페이스가 cnftests 이미지 스트림에서 이미지를 가져올 수 있도록 하는 데 필요합니다. 

    $ oc policy add-role-to-user system:image-puller system:serviceaccount:sctptest:default --namespace=cnftests
    $ oc policy add-role-to-user system:image-puller system:serviceaccount:cnf-features-testing:default --namespace=cnftests
    $ oc policy add-role-to-user system:image-puller system:serviceaccount:performance-addon-operators-testing:default --namespace=cnftests
    $ oc policy add-role-to-user system:image-puller system:serviceaccount:dpdk-testing:default --namespace=cnftests
    $ oc policy add-role-to-user system:image-puller system:serviceaccount:sriov-conformance-testing:default --namespace=cnftests

  5. Docker 보안 이름 및 인증 토큰을 검색합니다. 

    SECRET=$(oc -n cnftests get secret | grep builder-docker | awk {'print $1'}
TOKEN=$(oc -n cnftests get secret $SECRET -o jsonpath="{.data['\.dockercfg']}" | base64 --decode | jq '.["image-registry.openshift-image-registry.svc:5000"].auth')

  6. 다음과 유사한 dockerauth.json을 작성합니다. 

    echo "{\"auths\": { \"$REGISTRY\": { \"auth\": $TOKEN } }}" > dockerauth.json

  7. 미러링을 수행합니다. 

    $ docker run -v $(pwd)/:/kubeconfig -e KUBECONFIG=/kubeconfig/kubeconfig registry.redhat.io/openshift4/cnf-tests-rhel8:v4.6 /usr/bin/mirror -registry $REGISTRY/cnftests |  oc image mirror --insecure=true -a=$(pwd)/dockerauth.json -f -

  8. 테스트를 실행합니다. 

    $ docker run -v $(pwd)/:/kubeconfig -e KUBECONFIG=/kubeconfig/kubeconfig -e IMAGE_REGISTRY=image-registry.openshift-image-registry.svc:5000/cnftests cnf-tests-local:latest /usr/bin/test-run.sh
15.9.5.4. 다른 이미지 세트 미러링

프로세스

  1. mirror 명령은 기본적으로 u/s 이미지를 미러링합니다. 다음 형식의 파일을 이미지에 전달하여 재정의할 수 있습니다. 

    [
    {
        "registry": "public.registry.io:5000",
        "image": "imageforcnftests:4.6"
    },
    {
        "registry": "public.registry.io:5000",
        "image": "imagefordpdk:4.6"
    }
]

  2. mirror 명령에 전달하여 예를 들어 images.json으로 로컬에 저장합니다. 다음 명령을 사용하면 로컬 경로가 컨테이너 내 /kubeconfig에 마운트되어 mirror 명령에 전달될 수 있습니다. 

    $ docker run -v $(pwd)/:/kubeconfig -e KUBECONFIG=/kubeconfig/kubeconfig registry.redhat.io/openshift4/cnf-tests-rhel8:v4.6 /usr/bin/mirror --registry "my.local.registry:5000/" --images "/kubeconfig/images.json" |  oc image mirror -f -

15.9.6. 검색 모드

검색 모드에서는 구성을 변경하지 않고 클러스터 기능을 검증할 수 있습니다. 기존 환경 구성이 테스트에 사용됩니다. 테스트에서는 필요한 구성 항목을 찾고 해당 항목을 사용하여 테스트를 실행합니다. 특정 테스트를 실행하는 데 필요한 리소스를 찾을 수 없는 경우에는 테스트를 건너뛰고 사용자에게 적절한 메시지를 제공합니다. 테스트 완료 후 사전 구성한 구성 항목을 정리하지 않으며, 테스트 환경을 다른 테스트 실행에 즉시 사용할 수 있습니다.

일부 구성 항목은 계속 테스트에서 생성됩니다. 생성되는 항목은 SR-IOV 네트워크와 같이 어떤 테스트를 실행하는 데 필요한 특정 항목입니다. 이러한 구성 항목은 사용자 정의 네임스페이스에서 생성되며 테스트가 실행된 후에는 정리됩니다.

추가로 얻게 되는 이점은 테스트 실행 시간이 줄어드는 것입니다. 구성 항목이 이미 있으므로 환경 구성 및 안정화 시간이 필요하지 않습니다.

검색 모드를 활성화하려면 다음과 같이 DISCOVERY_MODE 환경 변수를 설정하여 테스트에 지시해야 합니다. 

$ docker run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig -e
DISCOVERY_MODE=true registry.redhat.io/openshift-kni/cnf-tests /usr/bin/test-run.sh
15.9.6.1. 필수 환경 구성 전제 조건

SR-IOV 테스트

대부분의 SR-IOV 테스트에는 다음 리소스가 필요합니다.

  • SriovNetworkNodePolicy.
  • SriovNetworkNodePolicy를 통해 지정한 리소스를 하나 이상 할당할 수 있어야 합니다. 리소스 수가 5개 이상이면 충분한 것으로 간주됩니다.

일부 테스트에는 추가 요구사항이 있습니다.

  • 사용 가능한 정책 리소스가 있으며 링크 상태가 DOWN이고 브릿지 슬레이브가 아닌 노드의 미사용 장치.
  • MTU 값이 9000인 SriovNetworkNodePolicy.

DPDK 테스트

DPDK 관련 테스트에는 다음이 필요합니다.

  • 성능 프로필.
  • SR-IOV 정책.
  • SR-IOV 정책에 사용할 수 있고 PerformanceProfile 노드 선택기와 함께 사용할 수 있는 리소스가 있는 노드.

PTP 테스트

  • 슬레이브 PtpConfig(ptp4lOpts="-s" ,phc2sysOpts="-a -r").
  • 슬레이브 PtpConfig와 일치하는 레이블이 있는 노드.

SCTP 테스트

  • SriovNetworkNodePolicy.
  • SCTP를 활성화하는 MachineConfig 및 SriovNetworkNodePolicy 둘 다와 일치하는 노드.

Performance Operator 테스트

다양한 테스트에는 다양한 요구사항이 있습니다. 요구사항 중 일부는 다음과 같습니다.

  • 성능 프로필.
  • profile.Spec.CPU.Isolated = 1인 성능 프로필.
  • profile.Spec.RealTimeKernel.Enabled == true인 성능 프로필.
  • 대규모 페이지를 사용하지 않는 노드.
15.9.6.2. 테스트 중 사용되는 노드 제한

NODES_SELECTOR 환경 변수를 지정하여 테스트가 실행되는 노드를 제한할 수 있습니다. 그러면 테스트에서 생성되는 모든 리소스가 지정된 노드로 제한됩니다. 

$ docker run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig -e
NODES_SELECTOR=node-role.kubernetes.io/worker-cnf registry.redhat.io/openshift-kni/cnf-tests /usr/bin/test-run.sh
15.9.6.3. 단일 성능 프로필 사용

DPDK 테스트에 필요한 리소스는 성능 테스트 모음에 필요한 리소스보다 많습니다. 실행 속도를 높이기 위해 DPDK 테스트 모음에도 사용할 수 있는 프로필로 이 테스트에서 사용하는 성능 프로필을 재정의할 수 있습니다.

이렇게 하려면 컨테이너 내부에 마운트할 수 있는 다음과 같은 프로필을 사용하며 해당 프로필을 배포하도록 성능 테스트에 지시합니다. 

apiVersion: performance.openshift.io/v1
kind: PerformanceProfile
metadata:
  name: performance
spec:
  cpu:
    isolated: "4-15"
    reserved: "0-3"
  hugepages:
    defaultHugepagesSize: "1G"
    pages:
    - size: "1G"
      count: 16
      node: 0
  realTimeKernel:
    enabled: true
  nodeSelector:
    node-role.kubernetes.io/worker-cnf: ""

사용되는 성능 프로필을 재정의하려면 컨테이너 내부에 매니페스트를 마운트하고 다음과 같이 PERFORMANCE_PROFILE_MANIFEST_OVERRIDE 매개변수를 설정하여 테스트에 지시해야 합니다. 

$ docker run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig -e
PERFORMANCE_PROFILE_MANIFEST_OVERRIDE=/kubeconfig/manifest.yaml registry.redhat.io/openshift-kni/cnf-tests /usr/bin/test-run.sh
15.9.6.4. 성능 프로필 정리 비활성화

검색 모드로 실행하지 않는 경우 테스트 모음에서는 생성된 모든 아티팩트 및 구성을 정리합니다. 성능 프로필도 정리에 포함됩니다.

성능 프로필을 삭제하면 머신 구성 풀이 수정되고 노드가 재부팅됩니다. 새로 반복되면 새 프로필이 생성됩니다. 이 경우 실행 간 테스트 주기가 길어집니다.

이 프로세스의 속도를 높이려면 CLEAN_PERFORMANCE_PROFILE="false"를 설정하여 성능 프로필을 정리하지 않도록 테스트에 지시합니다. 그러면 다음에 반복할 때 프로필을 생성할 필요도 없고 프로필이 적용되는 것을 기다릴 필요도 없습니다. 

$ docker run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig -e
CLEAN_PERFORMANCE_PROFILE="false" registry.redhat.io/openshift-kni/cnf-tests /usr/bin/test-run.sh

15.9.7. 문제 해결

컨테이너 내에서 클러스터에 접근할 수 있어야 합니다. 다음 명령을 실행하여 접근할 수 있는지 검증할 수 있습니다. 

$ docker run -v $(pwd)/:/kubeconfig -e KUBECONFIG=/kubeconfig/kubeconfig
registry.redhat.io/openshift-kni/cnf-tests oc get nodes

접근할 수 없다면 DNS, MTU 크기 또는 방화벽 문제 때문일 수 있습니다.

15.9.8. 테스트 보고서

CNF 엔드 투 엔드 테스트에서는 두 가지 출력 즉, JUnit 테스트 출력 및 테스트 실패 보고서가 생성됩니다.

15.9.8.1. JUnit 테스트 출력

--junit 매개변수를 보고서가 덤프되는 경로와 함께 전달하면 JUnit 호환 XML이 생성됩니다. 

$ docker run -v $(pwd)/:/kubeconfig -v $(pwd)/junitdest:/path/to/junit -e KUBECONFIG=/kubeconfig/kubeconfig registry.redhat.io/openshift4/cnf-tests-rhel8:v4.6 /usr/bin/test-run.sh --junit /path/to/junit
15.9.8.2. 테스트 실패 보고서

--report 매개변수를 보고서가 덤프되는 경로와 함께 전달하면 클러스터 상태에 대한 정보와 문제 해결을 위한 리소스가 포함된 보고서를 생성할 수 있습니다. 

$ docker run -v $(pwd)/:/kubeconfig -v $(pwd)/reportdest:/path/to/report -e KUBECONFIG=/kubeconfig/kubeconfig registry.redhat.io/openshift4/cnf-tests-rhel8:v4.6 /usr/bin/test-run.sh --report /path/to/report
15.9.8.3. podman에 대한 참고사항

podman을 루트가 아닌 사용자 또는 권한 없는 사용자로 실행하는 경우 마운트 경로가 실패하고 "권한이 거부됨" 오류가 발생할 수 있습니다. 작업이 수행되도록 하려면 볼륨 생성에 :Z를 추가하여(예: -v $(pwd)/:/kubeconfig:Z) podman에서 적절한 SELinux 레이블 재지정을 수행할 수 있게 합니다.

15.9.8.4. OpenShift Container Platform 4.4에서 실행

다음을 제외하면 CNF 엔드 투 엔드 테스트는 OpenShift Container Platform 4.4와 호환됩니다. 

[test_id:28466][crit:high][vendor:cnf-qe@redhat.com][level:acceptance] Should contain configuration injected through openshift-node-performance profile
[test_id:28467][crit:high][vendor:cnf-qe@redhat.com][level:acceptance] Should contain configuration injected through the openshift-node-performance profile

-ginkgo.skip “28466|28467" 매개변수를 추가하여 이러한 테스트를 건너뛸 수 있습니다.

15.9.8.5. 단일 성능 프로필 사용

DPDK 테스트에는 성능 테스트 모음에 필요한 것보다 더 많은 리소스가 필요합니다. 실행 속도를 높이기 위해 DPDK 테스트 모음에도 사용할 수 있는 프로필로 이 테스트에서 사용하는 성능 프로필을 재정의할 수 있습니다.

이렇게 하려면 컨테이너 내부에 마운트할 수 있는 다음과 같은 프로필을 사용하며 해당 프로필을 배포하도록 성능 테스트에 지시합니다. 

apiVersion: performance.openshift.io/v1
kind: PerformanceProfile
metadata:
 name: performance
spec:
 cpu:
  isolated: "5-15"
  reserved: "0-4"
 hugepages:
  defaultHugepagesSize: "1G"
  pages:
  -size: "1G"
   count: 16
   node: 0
 realTimeKernel:
  enabled: true
 numa:
  topologyPolicy: "best-effort"
 nodeSelector:
  node-role.kubernetes.io/worker-cnf: ""

성능 프로필을 재정의하려면 컨테이너 내부에 매니페스트를 마운트하고 PERFORMANCE_PROFILE_MANIFEST_OVERRIDE를 설정하여 테스트에 지시해야 합니다. 

$ docker run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig -e PERFORMANCE_PROFILE_MANIFEST_OVERRIDE=/kubeconfig/manifest.yaml registry.redhat.io/openshift4/cnf-tests-rhel8:v4.6 /usr/bin/test-run.sh

15.9.9. 클러스터에 미치는 영향

기능에 따라 테스트 모음 실행이 클러스터에 미치는 영향은 달라집니다. 일반적으로 SCTP 테스트만 클러스터 구성을 변경하지 않습니다. 다른 모든 기능은 구성에 다양한 영향을 미칩니다.

15.9.9.1. SCTP

SCTP 테스트는 다양한 노드에서 다양한 Pod를 실행하여 연결을 확인합니다. 클러스터에 미치는 영향은 두 노드에서 단순 Pod를 실행하는 것과 관련이 있습니다.

15.9.9.2. SR-IOV

SR-IOV 테스트를 수행하려면 SR-IOV 네트워크 구성을 변경해야 합니다. 이 테스트에서는 다양한 유형의 구성을 생성하고 제거합니다.

기존 SR-IOV 네트워크 구성이 클러스터에 이미 설치되어 있는 경우 이러한 구성의 우선 순위에 따라 충돌이 발생할 수 있으므로 테스트가 영향을 미칠 수 있습니다.

테스트 결과도 기존 구성의 영향을 받을 수 있습니다.

15.9.9.3. PTP

PTP 테스트는 클러스터의 노드 집합에 PTP 구성을 적용합니다. SR-IOV와 마찬가지로 이미 지정되어 있는 기존 PTP 구성과 충돌할 수 있으며, 예기치 않은 결과가 발생할 수 있습니다.

15.9.9.4. 성능

성능 테스트는 클러스터에 성능 프로필을 적용합니다. 이 테스트를 실행하면 노드 구성이 변경되고, CPU가 예약되고, 메모리 대규모 페이지가 할당되고, 커널 패키지가 실시간으로 설정됩니다. performance라는 기존 프로필이 클러스터에 이미 제공되어 있는 경우 테스트에서 새 프로필을 배포하지 않습니다.

15.9.9.5. DPDK

DPDK는 성능 및 SR-IOV 기능 둘 다의 영향을 받기 때문에 테스트 모음에서 성능 프로필과 SR-IOV 네트워크를 둘 다 구성하므로 그 영향은 SR-IOV 테스트 및 성능 테스트에 설명된 것과 동일합니다.

15.9.9.6. 정리

테스트 모음을 실행한 후에는 모든 무위 리소스가 정리됩니다.

15.10. 짧은 대기 시간 CNF 튜닝 상태 디버깅

PerformanceProfile CR(사용자 정의 리소스)에는 튜닝 상태를 보고하고 대기 시간 성능 저하 문제를 디버깅하기 위한 상태 필드가 있습니다. 이러한 필드는 상태를 보고하여 Operator 조정 기능의 상태에 대해 설명합니다.

일반적으로 성능 프로필에 연결된 머신 구성 풀의 상태가 성능 저하 상태이면 PerformanceProfile이 성능 저하 상태가 되는 문제가 발생할 수 있습니다. 이 경우 머신 구성 풀에서 실패 메시지를 발행합니다.

Performance Addon Operator에는 performanceProfile.spec.status.Conditions 상태 필드가 있습니다. 

Status:
  Conditions:
    Last Heartbeat Time:   2020-06-02T10:01:24Z
    Last Transition Time:  2020-06-02T10:01:24Z
    Status:                True
    Type:                  Available
    Last Heartbeat Time:   2020-06-02T10:01:24Z
    Last Transition Time:  2020-06-02T10:01:24Z
    Status:                True
    Type:                  Upgradeable
    Last Heartbeat Time:   2020-06-02T10:01:24Z
    Last Transition Time:  2020-06-02T10:01:24Z
    Status:                False
    Type:                  Progressing
    Last Heartbeat Time:   2020-06-02T10:01:24Z
    Last Transition Time:  2020-06-02T10:01:24Z
    Status:                False
    Type:                  Degraded

Status 필드에는 성능 프로필의 상태를 나타내는 Type 값을 지정하는 Conditions가 포함되어 있습니다.

Available
모든 머신 구성 및 Tuned 프로필이 성공적으로 생성되었으며 구성 요소에서 처리해야 하는 클러스터에 사용할 수 있습니다(NTO, MCO, Kubelet).
Upgradeable
Operator에서 유지보수하는 리소스가 업그레이드하기에 안전한 상태인지를 나타냅니다.
Progressing
성능 프로필의 배포 프로세스가 시작되었음을 나타냅니다.
Degraded

다음과 같은 경우 오류를 표시합니다.

  • 성능 프로필 검증에 실패했습니다.
  • 모든 관련 구성 요소 생성이 성공적으로 완료되지 않았습니다.

이러한 각 유형에는 다음 필드가 포함되어 있습니다.

상태
특정 유형의 상태(true 또는 false)입니다.
Timestamp
트랜잭션 타임스탬프입니다.
Reason string
머신에서 읽을 수 있는 이유입니다.
Message string
상태 및 오류 세부 정보(있는 경우)를 설명하는 사람이 읽을 수 있는 이유입니다.

15.10.1. 머신 구성 풀

성능 프로필 및 생성된 제품은 연관 MCP(머신 구성 풀)에 따라 노드에 적용됩니다. MCP에는 성능 애드온을 통해 생성되었고 커널 인수, kube 구성, 대규모 페이지 할당, rt-커널 배포를 포괄하는 머신 구성의 적용 진행 상황에 대한 중요한 정보가 들어 있습니다. 성능 애드온 컨트롤러는 MCP의 변경사항을 모니터링하여 성능 프로필 상태를 적절하게 업데이트합니다.

MCP가 성능 프로필 상태로 값을 반환하는 유일한 상태는 MCP가 Degraded인 경우이며, 이 경우에는 performaceProfile.status.condition.Degraded = true가 됩니다.

예

다음은 생성된 연관 머신 구성 풀(worker-cnf)이 있는 성능 프로필의 예입니다.

  1. 연관 머신 구성 풀이 성능 저하 상태입니다. 

    # oc get mcp

    출력 예

    NAME         CONFIG                                                 UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
master       rendered-master-2ee57a93fa6c9181b546ca46e1571d2d       True      False      False      3              3                   3                     0                      2d21h
worker       rendered-worker-d6b2bdc07d9f5a59a6b68950acf25e5f       True      False      False      2              2                   2                     0                      2d21h
worker-cnf   rendered-worker-cnf-6c838641b8a08fff08dbd8b02fb63f7c   False     True       True       2              1                   1                     1                      2d20h

  2. MCP의 describe 섹션은 이유를 보여줍니다. 

    # oc describe mcp worker-cnf

    출력 예

      Message:               Node node-worker-cnf is reporting: "prepping update:
  machineconfig.machineconfiguration.openshift.io \"rendered-worker-cnf-40b9996919c08e335f3ff230ce1d170\" not
  found"
    Reason:                1 nodes are reporting degraded status on sync

  3. degraded = true로 표시된 성능 프로필 status 필드 아래에도 성능 저하 상태가 표시되어야 합니다. 

    # oc describe performanceprofiles performance

    출력 예

    Message: Machine config pool worker-cnf Degraded Reason: 1 nodes are reporting degraded status on sync.
Machine config pool worker-cnf Degraded Message: Node yquinn-q8s5v-w-b-z5lqn.c.openshift-gce-devel.internal is
reporting: "prepping update: machineconfig.machineconfiguration.openshift.io
\"rendered-worker-cnf-40b9996919c08e335f3ff230ce1d170\" not found".    Reason:  MCPDegraded
   Status:  True
   Type:    Degraded

15.11. Red Hat 지원을 받기 위한 짧은 대기 시간 튜닝 디버깅 데이터 수집

지원 사례를 여는 경우 클러스터에 대한 디버깅 정보를 Red Hat 지원에 제공하면 도움이 됩니다.

must-gather 툴을 사용하면 노드 튜닝과 NUMA 토폴로지, 짧은 대기 시간 설정으로 인한 문제를 디버깅하는 데 필요한 다른 정보를 비롯하여 OpenShift Container Platform 클러스터에 대한 진단 정보를 수집할 수 있습니다.

즉각 지원을 받을 수 있도록 OpenShift Container Platform 및 짧은 대기 시간 튜닝 둘 다에 대한 진단 정보를 제공하십시오.

15.11.1. must-gather 툴 정보

oc adm must-gather CLI 명령은 다음과 같이 문제를 디버깅하는 데 필요할 가능성이 높은 클러스터 정보를 수집합니다.

  • 리소스 정의
  • 감사 로그
  • 서비스 로그

--image 인수를 포함하여 명령을 실행하는 경우 이미지를 하나 이상 지정할 수 있습니다. 이미지를 지정하면 툴에서 해당 기능 또는 제품과 관련된 데이터를 수집합니다. oc adm must-gather를 실행하면 클러스터에 새 Pod가 생성됩니다. 해당 Pod에 대한 데이터가 수집되어 must-gather.local로 시작하는 새 디렉터리에 저장됩니다. 이 디렉터리는 현재 작업 디렉터리에 생성됩니다.

15.11.2. 짧은 대기 시간 튜닝 데이터 수집 정보

oc adm must-gather CLI 명령을 사용하여 다음과 같은 짧은 대기 시간 튜닝과 연관된 기능 및 오브젝트를 포함한 클러스터 정보를 수집합니다.

  • Performance Addon Operator 네임스페이스 및 하위 오브젝트.
  • MachineConfigPool 및 연관 MachineConfig 오브젝트.
  • Node Tuning Operator 및 연관 Tuned 오브젝트.
  • Linux Kernel 명령줄 옵션.
  • CPU 및 NUMA 토폴로지.
  • 기본 PCI 장치 정보 및 NUMA 위치.

must-gather 를 사용하여 Performance Addon Operator 디버깅 정보를 수집하려면 Performance Addon Operator must-gather 이미지를 지정해야 합니다. 

--image=registry.redhat.io/openshift4/performance-addon-operator-must-gather-rhel8:v4.6.

15.11.3. 특정 기능에 대한 데이터 수집

oc adm must-gather CLI 명령을 --image 또는 --image-stream 인수와 함께 사용하여 특정 기능에 대한 디버깅 정보를 수집할 수 있습니다. must-gather 툴은 여러 이미지를 지원하므로 단일 명령을 실행하여 둘 이상의 기능에 대한 데이터를 수집할 수 있습니다.

참고

특정 기능 데이터 외에도 기본 must-gather 데이터를 수집하려면 --image-stream=openshift/must-gather 인수를 추가하십시오.

사전 요구 사항

  • cluster-admin 역할을 가진 사용자로 클러스터에 액세스합니다.
  • OpenShift Container Platform CLI(oc)가 설치되어 있어야 합니다.

프로세스

  1. must-gather 데이터를 저장하려는 디렉터리로 이동합니다.

  2. --image 또는 --image-stream 인수를 하나 이상 사용하여 oc adm must-gather 명령을 실행합니다. 예를 들어 다음 명령은 기본 클러스터 데이터와 Performance Addon Operator 관련 정보를 모두 수집합니다. 

    $ oc adm must-gather \
 --image-stream=openshift/must-gather \ 1

 --image=registry.redhat.io/openshift4/performance-addon-operator-must-gather-rhel8:v4.6 2
    1
    기본 OpenShift Container Platform must-gather 이미지입니다.
    2
    짧은 대기 시간 튜닝 진단을 위한 must-gather 이미지입니다.

  3. 작업 디렉터리에 생성된 must-gather 디렉터리의 압축 파일을 생성합니다. 예를 들어 Linux 운영 체제를 사용하는 컴퓨터에서 다음 명령을 실행합니다. 

     $ tar cvaf must-gather.tar.gz must-gather.local.5421342344627712289/ 1
    1
    must-gather-local.5421342344627712289/를 실제 디렉터리 이름으로 바꿉니다.
  4. Red Hat Customer Portal에서 해당 지원 사례에 압축 파일을 첨부합니다.

추가 리소스

16장. Intel FPGA PAC N3000 및 Intel vRAN Dedicated Accelerator ACC100을 사용하여 데이터 플레인 성능 최적화

16.1. OpenShift Container Platform용 Intel 하드웨어 액셀러레이터 카드 이해

Intel의 하드웨어 액셀러레이터 카드는 4G/LTE 및 5G VRAN(가상화된 라디오 액세스 네트워크) 워크로드를 가속화합니다. 그 결과 상용 상용 플랫폼에서의 전반적인 컴퓨팅 용량이 증가합니다.

Intel FPGA PAC N3000

Intel FPGA PAC N3000은 참조 FPGA이며 5G 또는 4G/LTE RAN 계층 1(L1) 기본 스테이션 네트워크 기능을 가속화하는 예제 워크로드로 4G/LTE 또는 5G 전달 오류 수정(FEC)을 사용합니다. vRAN 워크로드를 지원하려면 4G/LTE 또는 5G 비트스트림이 있는 Intel FPGA PAC N3000 카드를 플래시합니다.

Intel FPGA PAC N3000은 멀티 워크로드 네트워킹 애플리케이션 가속화를 위한 전이중 100Gbps의 시스템 내 프로그래밍 가능한 가속 카드입니다.

Intel FPGA PAC N3000이 4G/LTE 또는 5G 비트스트림으로 프로그래밍되면 vRAN 워크로드에서 FEC를 가속화하는 데 사용되는 SR-IOV(Single Root I/O Virtualization) VF(가상 기능) 장치를 노출합니다. 클라우드 네이티브 배포를 위해 이 기능을 활용하려면 장치의 물리적 기능(PF)을 pf-pci-stub 드라이버에 바인딩하여 여러 VF를 생성해야 합니다. VF가 생성된 후 vRAN 워크로드를 실행하는 특정 Pod에 할당하려면 VF를 DPDK 사용자 공간 드라이버(vfio)에 바인딩해야 합니다.

OpenShift Container Platform에서 Intel FPGA PAC N3000 지원은 다음 두 Operator에 따라 다릅니다.

  • Intel FPGA PAC N3000 (Programming)용 Openness Operator
  • FEC Accelerator용 openness Operator
vRAN Dedicated 액셀러레이터 ACC100

Intel의 eASIC 기술을 기반으로 하는 vRAN Dedicated Accelerator ACC100은 4G/LTE 및 5G 기술에 대한 전방향 오류 수정을 위한 컴퓨팅 집약적인 프로세스를 오프로드하고 가속화하여 처리 능력을 확보하도록 설계되었습니다. Intel eASIC 장치는 FPGA와 표준 애플리케이션별 통합 회로(ASIC) 사이의 중간 기술인 ASIC 구조화되어 있습니다.

OpenShift Container Platform에서 Intel vRAN Dedicated Accelerator ACC100 지원에서는 하나의 Operator를 사용합니다.

  • FEC Accelerator용 openness Operator

16.2. Intel FPGA PAC N3000용 OpenNESS Operator 설치

Intel FPGA PAC N3000용 OpenNESS Operator는 OpenShift Container Platform 클러스터 내의 Intel FPGA PAC N3000 카드에서 노출하는 리소스 또는 장치를 오케스트레이션하고 관리합니다.

vRAN 사용 사례의 경우 Intel FPGA PAC N3000의 OpenNESS Operator가 FEC Accelerator용 OpenNESS Operator와 함께 사용됩니다.

클러스터 관리자는 OpenShift Container Platform CLI 또는 웹 콘솔을 사용하여 Intel FPGA PAC N3000에 대한 OpenNESS Operator를 설치할 수 있습니다.

16.2.1. CLI를 사용하여 Operator 설치

클러스터 관리자는 CLI를 사용하여 Operator를 설치할 수 있습니다.

사전 요구 사항

  • 클러스터가 베어 메탈 하드웨어에 설치되어 있어야 합니다.
  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.

절차

  1. 다음 작업을 완료하여 N3000 Operator의 네임스페이스를 생성합니다.

    1. 다음 예와 같이 n3000 -namespace.yaml 파일 파일을 생성하여 vran-acceleration-operators 네임스페이스를 정의합니다. 

      apiVersion: v1
kind: Namespace
metadata:
    name: vran-acceleration-operators
    labels:
        openshift.io/cluster-monitoring: "true"

    2. 다음 명령을 실행하여 네임스페이스를 생성합니다. 

      $ oc create -f n3000-namespace.yaml

  2. 이전 단계에서 생성한 네임스페이스에 N3000 Operator를 설치합니다.

    1. 다음 OperatorGroup CR을 생성하고 YAML을 n3000-operatorgroup.yaml 파일에 저장합니다. 

      apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
    name: n3000-operators
    namespace: vran-acceleration-operators
spec:
    targetNamespaces:
    - vran-acceleration-operators

    2. 다음 명령을 실행하여 OperatorGroup CR을 생성합니다. 

      $ oc create -f n3000-operatorgroup.yaml

    3. 다음 명령을 실행하여 후속 단계에 필요한 채널 값을 가져옵니다. 

      $ oc get packagemanifest n3000 -n openshift-marketplace -o jsonpath='{.status.defaultChannel}'

      출력 예

      stable

    4. 다음 Subscription CR을 생성하고 YAML을 n3000-sub.yaml 파일에 저장합니다. 

      apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
    name: n3000-subscription
    namespace: vran-acceleration-operators
spec:
    channel: "<channel>"        1
    name: n3000
    source: certified-operators 2
    sourceNamespace: openshift-marketplace
      1
      . status.defaultChannel 매개변수에 대해 이전 단계에서 얻은 값에서 채널 값을 지정합니다.
      2
      certified-operators 값을 지정해야 합니다.

    5. 다음 명령을 실행하여 서브스크립션 CR을 생성합니다. 

      $ oc create -f n3000-sub.yaml

검증

  • Operator가 설치되었는지 확인합니다. 

    $ oc get csv

    출력 예

    NAME            DISPLAY                                         VERSION  REPLACES    PHASE
n3000.v1.1.0    OpenNESS Operator for Intel® FPGA PAC N3000     1.1.0                Succeeded

    이제 Operator를 성공적으로 설치했습니다.

16.2.2. 웹 콘솔을 사용하여 Intel FPGA PAC N3000 Operator용 OpenNESS Operator 설치

클러스터 관리자는 웹 콘솔을 사용하여 Intel FPGA PAC N3000에 대한 OpenNESS Operator를 설치할 수 있습니다.

참고

이전 섹션에서 언급한 것처럼 네임스페이스 및 OperatorGroup CR을 생성해야 합니다.

절차

  1. OpenShift Container Platform 웹 콘솔을 사용하여 Intel FPGA PAC N3000용 OpenNESS Operator를 설치합니다.

    1. OpenShift Container Platform 웹 콘솔에서 Operator → OperatorHub를 클릭합니다.
    2. 사용 가능한 Operator 목록에서 Intel FPGA PAC N3000용 OpenNESS Operator를 선택한 다음 설치를 클릭합니다.
    3. Install Operator 페이지에서 All namespaces on the cluster를 선택합니다. 그런 다음, 설치를 클릭합니다.

  2. 선택 사항: N3000 Operator가 성공적으로 설치되었는지 확인합니다.

    1. Operator → 설치된 Operator 페이지로 전환합니다.

    2. Intel FPGA PAC N3000 의 OpenNESS Operator 가 InstallSucceeded 상태로 vran-acceleration-operators 프로젝트에 나열되어 있는지 확인합니다.

      참고

      설치하는 동안 Operator는 실패 상태를 표시할 수 있습니다. 나중에 InstallSucceeded 메시지와 함께 설치에 성공하면 이 실패 메시지를 무시할 수 있습니다.

      콘솔에서 Operator가 설치되었음을 나타내지 않으면 다음 문제 해결 단계를 수행합니다.

      • Operator → 설치된 Operator 페이지로 이동하고 Operator 서브스크립션 및 설치 계획 탭의 상태에 장애나 오류가 있는지 검사합니다.
      • 워크로드 → Pod 페이지로 이동하여 vran-acceleration-operators 프로젝트에서 Pod 로그를 확인합니다.

16.3. Intel FPGA PAC N3000용 OpenNESS Operator 프로그래밍

Intel FPGA PAC N3000이 vRAN 5G 비트스트림으로 프로그래밍되면 하드웨어는 vRAN 5G 비트스트림으로 Intel FPGA PAC N3000을 노출합니다. 이 비트스트림은 vRAN 워크로드에서 FEC를 가속화하는 데 사용되는 SR-IOV(Single Root I/O Virtualization) VF(가상 기능) 장치를 노출합니다.

클러스터 관리자는 OpenShift Container Platform CLI 또는 웹 콘솔을 사용하여 Intel FPGA PAC N3000에 대한 OpenNESS Operator를 설치할 수 있습니다.

16.3.1. vRAN 비트스트림으로 N3000 프로그래밍

클러스터 관리자는 vRAN 5G 비트스트림을 사용하여 Intel FPGA PAC N3000을 프로그래밍할 수 있습니다. 이 비트스트림은 vRAN 워크로드에서 전달 오류 수정(FEC)을 가속화하는 데 사용되는 SR-IOV(Single Root I/O Virtualization) VF(가상 기능) 장치를 노출합니다.

FEC(전달 오류 수정)의 역할은 메시지의 특정 비트를 손실하거나 무시할 수 있는 전송 오류를 수정하는 것입니다. 전송 미디어, 간섭 또는 신호 강도의 노이즈로 인해 메시지를 손실하거나 숨길 수 있습니다. FEC가 없으면 가파른 메시지가 다시 전송되어 네트워크 부하에 추가하고 처리량과 대기 시간에 모두 영향을 미칩니다.

사전 요구 사항

  • Intel FPGA PAC N3000 카드
  • RT 커널 구성을 사용한 Performance Addon Operator
  • Intel FPGA PAC N3000용 OpenNESS Operator와 함께 설치된 노드 또는 노드

  • cluster-admin 권한이 있는 사용자로 로그인합니다.

    참고

    모든 명령은 vran-acceleration-operators 네임스페이스에서 실행됩니다.

절차

  1. vran-acceleration-operators 프로젝트로 변경합니다. 

    $ oc project vran-acceleration-operators

  2. pod가 실행 중인지 확인합니다. 

    $ oc get pods

    출력 예

    NAME                                        READY       STATUS          RESTARTS    AGE
fpga-driver-daemonset-8xz4c                 1/1         Running         0           15d
fpgainfo-exporter-vhvdq                     1/1         Running         1           15d
N3000-controller-manager-b68475c76-gcc6v    2/2         Running         1           15d
N3000-daemonset-5k55l                       1/1         Running         1           15d
N3000-discovery-blmjl                       1/1         Running         1           15d
N3000-discovery-lblh7                       1/1         Running         1           15d

    다음 섹션에서는 설치된 Pod에 대한 정보를 제공합니다.

    • FPGA-driver-daemonset 는 필요한 OPAE(Open Programmable Accelerator Engine) 드라이버를 제공하고 로드합니다.
    • fpgainfo-exporter 는 Prometheus에 N3000 Telemetry 데이터를 제공합니다.
    • n 3000-controller-manager 가 N3000Node CR을 클러스터에 적용하고 모든 피연산자 컨테이너를 관리합니다.
    • N3000-daemonset 은 주요 작업자 애플리케이션입니다. 각 노드의 CR의 변경 사항을 모니터링하고 변경 사항에 적용됩니다. 이 데몬에 구현된 논리는 카드의 FPGA 사용자 이미지 및 NIC 펌웨어를 업데이트하는 작업을 담당합니다. 업데이트에 필요한 경우 노드를 드레이닝하고 커미션을 해제합니다.
    • N3000-discovery 가 설치된 N3000 Accelerator 장치를 검색하고 장치가 있는 경우 작업자 노드에 레이블을 지정합니다.

  3. Intel FPGA PAC N3000 카드가 포함된 모든 노드를 가져옵니다. 

    $ oc get n3000node

    출력 예

    NAME                       FLASH
node1                      NotRequested

  4. 각 노드의 카드 정보를 가져옵니다. 

    $ oc get n3000node node1 -o yaml

    출력 예

    status:
  conditions:
  - lastTransitionTime: "2020-12-15T17:09:26Z"
    message: Inventory up to date
    observedGeneration: 1
    reason: NotRequested
    status: "False"
    type: Flashed
  fortville:
  - N3000PCI: 0000:1b:00.0
    NICs:
    - MAC: 64:4c:36:11:1b:a8
      NVMVersion: 7.00 0x800052b0 0.0.0
      PCIAddr: 0000:1a:00.0
      name: Ethernet Controller XXV710 Intel(R) FPGA Programmable Acceleration Card N3000 for Networking
    - MAC: 64:4c:36:11:1b:a9
      NVMVersion: 7.00 0x800052b0 0.0.0
      PCIAddr: 0000:1a:00.1
      name: Ethernet Controller XXV710 Intel(R) FPGA Programmable Acceleration Card N3000 for Networking
    - MAC: 64:4c:36:11:1b:ac
      NVMVersion: 7.00 0x800052b0 0.0.0
      PCIAddr: 0000:1c:00.0
      name: Ethernet Controller XXV710 Intel(R) FPGA Programmable Acceleration Card N3000 for Networking
    - MAC: 64:4c:36:11:1b:ad
      NVMVersion: 7.00 0x800052b0 0.0.0
      PCIAddr: 0000:1c:00.1
      name: Ethernet Controller XXV710 Intel(R) FPGA Programmable Acceleration Card N3000 for Networking
  fpga:
  - PCIAddr: 0000:1b:00.0 1
    bitstreamId: "0x23000410010310" 2
    bitstreamVersion: 0.2.3
    deviceId: "0x0b30"

    1
    PCIAddr 필드는 카드의 PCI 주소를 나타냅니다.
    2
    bitstreamId 필드는 현재 플래시로 저장된 비트스트림을 나타냅니다.

  5. "0x" 패딩 없이 현재 bitstreamId,PCIAddr, 이름 및 deviceId 를 저장합니다. 

    $ oc get n3000node -o json

  6. Intel FPGA PAC N3000 카드의 사용자 비트스트림을 업데이트합니다.

    1. 다음 예와 같이 n3000-cluster.yaml이라는 파일을 생성하여 프로그래밍할 N3000 클러스터 리소스를 정의합니다. 

      apiVersion: fpga.intel.com/v1
kind: N3000Cluster
metadata:
    name: n3000 1
    namespace: vran-acceleration-operators
spec:
    nodes:
      - nodeName: "node1" 2
        fpga:
          - userImageURL: "http://10.10.10.122:8000/pkg/20ww27.5-2x2x25G-5GLDPC-v1.6.1-3.0.0_unsigned.bin" 3
            PCIAddr: "0000:1b:00.0" 4
            checksum: "0b0a87b974d35ea16023ceb57f7d5d9c" 5
      1
      이름을 지정합니다. 이름은 n3000 이어야 합니다.
      2
      프로그램할 노드를 지정합니다.
      3
      사용자 bitstream의 URL을 지정합니다. 이 비트스트림 파일은 HTTP 또는 HTTPS 서버에서 액세스할 수 있어야 합니다.
      4
      프로그램할 카드의 PCI 주소를 지정합니다.
      5
      userImageURL 필드에 지정된 비트 스트림의 MD5 체크섬을 지정합니다.

      N3000 데몬은 Open Programmable Acceleration Engine(OPAE) 도구를 사용하여 FPGA 사용자 비트스트림을 업데이트하고 PCI 장치를 재설정합니다. FPGA 사용자 비트스트림 업데이트에는 카드당 최대 40분이 걸릴 수 있습니다. 여러 노드의 프로그래밍 카드의 경우 프로그래밍은 한 번에 하나의 노드씩 실행됩니다.

    2. 비트스트림으로 카드 프로그래밍을 시작하려면 업데이트를 적용합니다. 

      $ oc apply -f n3000-cluster.yaml

      N3000 데몬은 20ww27.5-2x2x25G-5GLDPC-v1.6.1-3.0.0_unsigned.bin과 같이 적절한 5G FEC 사용자 비트스트림이 프로비저닝된 후 비트스트림 프로그래밍을 시작합니다.

    3. 상태를 확인합니다. 

      oc get n3000node

      출력 예

      NAME             FLASH
node1            InProgress

  7. 로그를 확인합니다.

    1. N3000 데몬의 Pod 이름을 확인합니다. 

      $ oc get pod -o wide | grep n3000-daemonset | grep node1

      출력 예

      n3000-daemonset-5k55l              1/1     Running   0          15d

    2. 로그를 확인합니다. 

      $ oc logs n3000-daemonset-5k55l

      출력 예

      ...
{"level":"info","ts":1608054338.8866854,"logger":"daemon.drainhelper.cordonAndDrain()","msg":"node drained"}
{"level":"info","ts":1608054338.8867319,"logger":"daemon.drainhelper.Run()","msg":"worker function - start"}
{"level":"info","ts":1608054338.9003832,"logger":"daemon.fpgaManager.ProgramFPGAs","msg":"Start program","PCIAddr":"0000:1b:00.0"}
{"level":"info","ts":1608054338.9004142,"logger":"daemon.fpgaManager.ProgramFPGA","msg":"Starting","pci":"0000:1b:00.0"}
{"level":"info","ts":1608056309.9367146,"logger":"daemon.fpgaManager.ProgramFPGA","msg":"Program FPGA completed, start new power cycle N3000 ...","pci":"0000:1b:00.0"}
{"level":"info","ts":1608056333.3528838,"logger":"daemon.drainhelper.Run()","msg":"worker function - end","performUncordon":true}
...

      로그 파일은 다음과 같은 이벤트 흐름을 나타냅니다.

      • 비트스트림을 다운로드하고 검증합니다.
      • 노드가 드레인되어 이 시간 동안 실행할 수 있는 워크로드가 없습니다.

      • 플래시가 시작됨:

        • 비트스트림은 카드로 깜박여집니다.
        • 비트스트림이 적용됩니다.
      • 플래시를 완료하면 노드 또는 노드의 PCI 장치 또는 장치가 다시 로드됩니다. 이제 FEC Accelerator용 OpenNESS SR-IOV Operator에서 새로 깜빡이는 장치 또는 장치를 찾을 수 있습니다.

검증

  1. FPGA 사용자 비트스트림 업데이트가 완료된 후 상태를 확인합니다. 

    oc get n3000node

    출력 예

    NAME             FLASH
node1            Succeeded

  2. 카드의 비트 스트림 ID가 변경되었는지 확인합니다. 

    oc get n3000node node1 -o yaml

    출력 예

    status:
      conditions:
          - lastTransitionTime: "2020-12-15T18:18:53Z"
            message: Flashed successfully 1
            observedGeneration: 2
            reason: Succeeded
            status: "True"
            type: Flashed
      fortville:
      - N3000PCI: 0000:1b:00.0
        NICs:
        - MAC: 64:4c:36:11:1b:a8
          NVMVersion: 7.00 0x800052b0 0.0.0
          PCIAddr: 0000:1a:00.0
          name: Ethernet Controller XXV710 Intel(R) FPGA Programmable Acceleration Card N3000 for Networking
        - MAC: 64:4c:36:11:1b:a9
          NVMVersion: 7.00 0x800052b0 0.0.0
          PCIAddr: 0000:1a:00.1
          name: Ethernet Controller XXV710 Intel(R) FPGA Programmable Acceleration Card N3000 for Networking
        - MAC: 64:4c:36:11:1b:ac
          NVMVersion: 7.00 0x800052b0 0.0.0
          PCIAddr: 0000:1c:00.0
          name: Ethernet Controller XXV710 Intel(R) FPGA Programmable Acceleration Card N3000 for Networking
        - MAC: 64:4c:36:11:1b:ad
          NVMVersion: 7.00 0x800052b0 0.0.0
          PCIAddr: 0000:1c:00.1
          name: Ethernet Controller XXV710 Intel(R) FPGA Programmable Acceleration Card N3000 for Networking
      fpga:
      - PCIAddr: 0000:1b:00.0 2
        bitstreamId: "0x2315842A010601" 3
        bitstreamVersion: 0.2.3
        deviceId: "0x0b30" 4

    1
    메시지 필드는 장치가 성공적으로 깜빡임을 나타냅니다.
    2
    PCIAddr 필드는 카드의 PCI 주소를 나타냅니다.
    3
    bitstreamId 필드는 업데이트된 비트스트림 ID를 나타냅니다.
    4
    deviceID 필드는 시스템에 노출된 카드 내의 비트스트림의 장치 ID를 나타냅니다.

  3. 노드에서 FEC PCI 장치를 확인합니다.

    1. 노드 구성이 올바르게 적용되었는지 확인합니다. 

      $ oc debug node/node1

      예상 출력

      Starting pod/<node-name>-debug ...
To use host binaries, run `chroot /host`

Pod IP: <ip-address>
If you don't see a command prompt, try pressing enter.

sh-4.4#

    2. 노드 파일 시스템을 사용할 수 있는지 확인합니다. 

      sh-4.4# chroot /host

      예상 출력

      sh-4.4#

    3. 시스템의 액셀러레이터와 연결된 PCI 장치를 나열합니다. 

      $ lspci | grep accelerators

      예상 출력

      1b:00.0 Processing accelerators: Intel Corporation Device 0b30
1d:00.0 Processing accelerators: Intel Corporation Device 0d8f (rev 01)

      FPGA에 속하는 장치는 출력에 보고됩니다. 장치 ID 0b30 은 카드를 프로그래밍하는 데 사용되는 RSU 인터페이스이며 0d8f 는 새로 프로그래밍된 5G 장치의 물리적 기능입니다.

16.4. FEC Accelerator용 OpenNESS SR-IOV Operator 설치

FEC Accelerator용 OpenNESS SR-IOV Operator의 역할은 OpenShift Container Platform 클러스터 내의 Intel vRAN FEC 가속 하드웨어에서 노출하는 장치를 오케스트레이션하고 관리하는 것입니다.

가장 컴퓨팅 집약적인 4G/LTE 및 5G 워크로드 중 하나는 RAN 계층 1(L1) 전달 오류 수정(FEC)입니다. FEC는 불안정하거나 노후한 통신 채널을 통해 데이터 전송 오류를 해결합니다. FEC 기술은 재전송 없이 4G/LTE 또는 5G 데이터에서 제한된 오류 수를 감지하고 수정합니다.

FEC 장치는 Intel FPGA PAC N3000 및 vRAN Dedicated Accelerator ACC100에서 vRAN 사용 사례에 사용할 수 있습니다.

참고

Intel FPGA PAC N3000 FPGA에는 4G/LTE 또는 5G 비트스트림을 사용한 플래시가 필요합니다.

FEC Accelerator용 OpenNESS SR-IOV Operator는 FEC 장치에 대한 VF(가상 기능)를 생성하고 적절한 드라이버에 바인딩하고 4G/LTE 또는 5G 배포의 기능에 대한 VF 큐를 구성하는 기능을 제공합니다.

클러스터 관리자는 OpenShift Container Platform CLI 또는 웹 콘솔을 사용하여 FEC Accelerator용 OpenNESS SR-IOV Operator를 설치할 수 있습니다.

16.4.1. CLI를 사용하여 FEC Accelerator용 OpenNESS SR-IOV Operator 설치

클러스터 관리자는 CLI를 사용하여 FEC Accelerator용 OpenNESS SR-IOV Operator를 설치할 수 있습니다.

사전 요구 사항

  • 클러스터가 베어 메탈 하드웨어에 설치되어 있어야 합니다.
  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.

절차

  1. 다음 작업을 완료하여 FEC Accelerator용 OpenNESS SR-IOV Operator의 네임스페이스를 생성합니다.

    1. 다음 예와 같이 sriov -namespace.yaml이라는 파일을 생성하여 vran-acceleration-operators 네임스페이스를 정의합니다. 

      apiVersion: v1
kind: Namespace
metadata:
    name: vran-acceleration-operators
    labels:
       openshift.io/cluster-monitoring: "true"

    2. 다음 명령을 실행하여 네임스페이스를 생성합니다. 

      $ oc create -f sriov-namespace.yaml

  2. 다음 오브젝트를 생성하여 이전 단계에서 생성한 네임스페이스에 FEC Accelerator용 OpenNESS SR-IOV Operator를 설치합니다.

    1. 다음 OperatorGroup CR을 생성하고 YAML을 sriov-operatorgroup.yaml 파일에 저장합니다. 

      apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
    name: vran-operators
    namespace: vran-acceleration-operators
spec:
    targetNamespaces:
      - vran-acceleration-operators

    2. 다음 명령을 실행하여 OperatorGroup CR을 생성합니다. 

      $ oc create -f sriov-operatorgroup.yaml

    3. 다음 명령을 실행하여 후속 단계에 필요한 채널 값을 가져옵니다. 

      $ oc get packagemanifest sriov-fec -n openshift-marketplace -o jsonpath='{.status.defaultChannel}'

      출력 예

      stable

    4. 다음 Subscription CR을 생성하고 YAML을 sriov-sub.yaml 파일에 저장합니다. 

      apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
    name: sriov-fec-subscription
    namespace: vran-acceleration-operators
spec:
    channel: "<channel>" 1
    name: sriov-fec
    source: certified-operators 2
    sourceNamespace: openshift-marketplace
      1
      . status.defaultChannel 매개변수에 대해 이전 단계에서 얻은 값에서 채널 값을 지정합니다.
      2
      certified-operators 값을 지정해야 합니다.

    5. 다음 명령을 실행하여 서브스크립션 CR을 생성합니다. 

      $ oc create -f sriov-sub.yaml

검증

  • Operator가 설치되었는지 확인합니다. 

    $ oc get csv -n vran-acceleration-operators -o custom-columns=Name:.metadata.name,Phase:.status.phase

    출력 예

    Name                                        Phase
sriov-fec.v1.1.0                            Succeeded

16.4.2. 웹 콘솔을 사용하여 FEC Accelerator용 OpenNESS SR-IOV Operator 설치

클러스터 관리자는 웹 콘솔을 사용하여 FEC Accelerator용 OpenNESS SR-IOV Operator를 설치할 수 있습니다.

참고

이전 섹션에서 언급한 것처럼 네임스페이스 및 OperatorGroup CR을 생성해야 합니다.

절차

  1. OpenShift Container Platform 웹 콘솔을 사용하여 FEC Accelerator용 OpenNESS SR-IOV Operator를 설치합니다.

    1. OpenShift Container Platform 웹 콘솔에서 Operator → OperatorHub를 클릭합니다.
    2. 사용 가능한 Operator 목록에서 OperatorHub FEC Accelerator용 OpenNESS SR-IOV Operator를 선택한 다음 설치를 클릭합니다.
    3. Install Operator 페이지에서 All namespaces on the cluster를 선택합니다. 그런 다음, 설치를 클릭합니다.

  2. 선택 사항: SRIOV-FEC Operator가 성공적으로 설치되었는지 확인합니다.

    1. Operator → 설치된 Operator 페이지로 전환합니다.

    2. FEC Accelerator용 OpenNESS SR-IOV Operator 가 Install Succeeded 상태로 vran-acceleration-operators 프로젝트에 나열되어 있는지 확인합니다.

      참고

      설치 중에 Operator는 실패 상태를 표시할 수 있습니다. 나중에 InstallSucceeded 메시지와 함께 설치에 성공하면 이 실패 메시지를 무시할 수 있습니다.

      콘솔에서 Operator가 설치되었음을 나타내지 않으면 다음 문제 해결 단계를 수행합니다.

      • Operator → 설치된 Operator 페이지로 이동하고 Operator 서브스크립션 및 설치 계획 탭의 상태에 장애나 오류가 있는지 검사합니다.
      • 워크로드 → Pod 페이지로 이동하여 vran-acceleration-operators 프로젝트에서 Pod 로그를 확인합니다.

16.4.3. Intel FPGA PAC N3000용 SR-IOV-FEC Operator 구성

이 섹션에서는 Intel FPGA PAC N3000의 SR-IOV-FEC Operator를 프로그래밍하는 방법에 대해 설명합니다. SR-IOV-FEC Operator는 vRAN L1 애플리케이션에서 FEC 프로세스를 가속화하는 데 사용되는 전달 오류 수정(FEC) 장치의 관리를 처리합니다.

SR-IOV-FEC Operator 구성에는 다음이 포함됩니다.

  • FEC 장치에 원하는 VF(가상 기능) 생성
  • VF를 적절한 드라이버에 바인딩
  • 4G 또는 5G 배포에서 원하는 기능에 대한 VF 큐 구성

FEC(전달 오류 수정)의 역할은 메시지의 특정 비트를 손실하거나 무시할 수 있는 전송 오류를 수정하는 것입니다. 전송 미디어, 간섭 또는 신호 강도의 노이즈로 인해 메시지를 손실하거나 숨길 수 있습니다. FEC가 없으면 가파른 메시지를 다시 전송하여 네트워크 부하에 추가하고 처리량과 대기 시간에 영향을 미칩니다.

사전 요구 사항

  • Intel FPGA PAC N3000 카드
  • Intel FPGA PAC N3000(Programming)용 OpenNESS Operator와 함께 설치된 노드 또는 노드
  • FEC Accelerator용 OpenNESS Operator와 함께 설치된 노드 또는 노드
  • Performance Addon Operator로 구성된 RT 커널

절차

  1. vran-acceleration-operators 프로젝트로 변경합니다. 

    $ oc project vran-acceleration-operators

  2. SR-IOV-FEC Operator가 설치되었는지 확인합니다. 

    $ oc get csv -o custom-columns=Name:.metadata.name,Phase:.status.phase

    출력 예

    Name                                        Phase
sriov-fec.v1.1.0                            Succeeded
n3000.v1.1.0                                Succeeded

  3. N3000 및 sriov-fec Pod가 실행 중인지 확인합니다. 

    $  oc get pods

    출력 예

    NAME                                            READY       STATUS      RESTARTS    AGE
fpga-driver-daemonset-8xz4c                     1/1         Running     0           15d
fpgainfo-exporter-vhvdq                         1/1         Running     1           15d
N3000-controller-manager-b68475c76-gcc6v        2/2         Running     1           15d
N3000-daemonset-5k55l                           1/1         Running     1           15d
N3000-discovery-blmjl                           1/1         Running     1           15d
N3000-discovery-lblh7                           1/1         Running     1           15d
sriov-device-plugin-j5jlv                       1/1         Running     1           15d
sriov-fec-controller-manager-85b6b8f4d4-gd2qg   1/1         Running     1           15d
sriov-fec-daemonset-kqqs6                       1/1         Running     1           15d

    다음 섹션에서는 설치된 Pod에 대한 정보를 제공합니다.

    • FPGA-driver-daemonset 는 필요한 OPAE(Open Programmable Accelerator Engine) 드라이버를 제공하고 로드합니다.
    • fpgainfo-exporter 는 Prometheus에 N3000 Telemetry 데이터를 제공합니다.
    • n 3000-controller-manager 가 N3000Node CR을 클러스터에 적용하고 모든 피연산자 컨테이너를 관리합니다.
    • N3000-daemonset 이 주요 작업자 애플리케이션입니다.
    • N3000-discovery 가 설치된 N3000 Accelerator 장치를 검색하고 장치가 있는 경우 작업자 노드에 레이블을 지정합니다.
    • sriov-device-plugin 은 FEC 가상 기능을 노드 아래의 리소스로 노출
    • sriov-fec-controller-manager 가 노드에 CR을 적용하고 피연산자 컨테이너를 유지 관리합니다.

    • sriov-fec-daemonset 는 다음을 담당합니다.

      • 각 노드에서 SRIOV NIC 검색.
      • 6단계에 정의된 CR(사용자 정의 리소스)의 상태 동기화.
      • CR의 사양을 입력으로 사용하고 검색된 NIC를 구성합니다.

  4. 지원되는 vRAN FEC 액셀러레이터 장치 중 하나를 포함하는 모든 노드를 검색합니다. 

    $ oc get sriovfecnodeconfig

    출력 예

    NAME             CONFIGURED
node1            Succeeded

  5. SR-IOV FEC 액셀러레이터 장치의 물리적 기능(PF)을 검색하여 구성합니다. 

    $ oc get sriovfecnodeconfig node1 -o yaml

    출력 예

    status:
    conditions:
    - lastTransitionTime: "2021-03-19T17:19:37Z"
      message: Configured successfully
      observedGeneration: 1
      reason: ConfigurationSucceeded
      status: "True"
      type: Configured
    inventory:
        sriovAccelerators:
        - deviceID: 0d5c
          driver: ""
          maxVirtualFunctions: 16
          pciAddress: 0000.1d.00.0 1
          vendorID: "8086"
          virtualFunctions: [] 2

    1
    이 필드는 카드의 PCI 주소를 나타냅니다.
    2
    이 필드는 가상 기능이 비어 있음을 보여줍니다.

  6. 원하는 설정으로 FEC 장치를 구성합니다.

    1. 다음 CR(사용자 정의 리소스)을 생성하고 YAML을 sriovfec_n3000_cr.yaml 파일에 저장합니다. 

      apiVersion: sriovfec.intel.com/v1
kind: SriovFecClusterConfig
metadata:
    name: config
    namespace: vran-acceleration-operators
spec:
  nodes:
    - nodeName: node1 1
      physicalFunctions:
        - pciAddress: 0000:1d:00.0 2
          pfDriver: pci-pf-stub
          vfDriver: vfio-pci
          vfAmount: 2 3
          bbDevConfig:
            n3000:
              # Network Type: either "FPGA_5GNR" or "FPGA_LTE"
              networkType: "FPGA_5GNR"
              pfMode: false
              flrTimeout: 610
              downlink:
                bandwidth: 3
                loadBalance: 128
                queues: 4
                  vf0: 16
                  vf1: 16
                  vf2: 0
                  vf3: 0
                  vf4: 0
                  vf5: 0
                  vf6: 0
                  vf7: 0
              uplink:
                bandwidth: 3
                loadBalance: 128
                queues: 5
                  vf0: 16
                  vf1: 16
                  vf2: 0
                  vf3: 0
                  vf4: 0
                  vf5: 0
                  vf6: 0
                  vf7: 0
      1
      노드 이름을 지정합니다.
      2
      SR-IOV-FEC Operator를 설치할 카드의 PCI 주소를 지정합니다.
      3
      가상 함수 수를 지정합니다. 두 개의 가상 함수를 만듭니다.
      4
      vf0 에서 16개의 버스(downlink 및 uplink)를 사용하여 대기열 한 개를 만듭니다.
      5
      vf1 에서 16개의 버스(downlink 및 uplink)로 하나의 대기열을 만듭니다.
      참고

      Intel PAC N3000 for vRAN Acceleration의 경우 사용자는 최대 8개의 VF 장치를 생성할 수 있습니다. 각 FEC PF 장치는 구성할 총 64개 대기열, 업링크는 32개 대기열, 다운링크는 32개 대기열을 제공합니다. 일반적으로 큐는 VF 전체에 균등하게 배포됩니다.

    2. CR을 적용합니다. 

      $ oc apply -f sriovfec_n3000_cr.yaml

      CR을 적용하면 SR-IOV FEC 데몬이 FEC 장치 구성을 시작합니다.

검증

  1. 상태를 확인합니다. 

    $ oc get sriovfecclusterconfig config -o yaml

    출력 예

    status:
    conditions:
    - lastTransitionTime: "2020-12-15T17:19:37Z"
      message: Configured successfully
      observedGeneration: 1
      reason: ConfigurationSucceeded
      status: "True"
      type: Configured
    inventory:
      sriovAccelerators:
      - deviceID: 0d8f
        driver: pci-pf-stub
        maxVirtualFunctions: 8
        pciAddress: 0000:1d:00.0
        vendorID: "8086"
        virtualFunctions:
        - deviceID: 0d90
          driver: vfio-pci
          pciAddress: 0000:1d:00.1
        - deviceID: 0d90
          driver: vfio-pci
          pciAddress: 0000:1d:00.2

  2. 로그를 확인합니다.

    1. SR-IOV 데몬 Pod의 이름을 확인합니다. 

      $ oc get pod | grep sriov-fec-daemonset

      출력 예

      sriov-fec-daemonset-kqqs6                      1/1     Running   0          19h

    2. 로그를 확인합니다. 

      $ oc logs sriov-fec-daemonset-kqqs6

      출력 예

      2020-12-16T12:46:47.720Z        INFO    daemon.NodeConfigurator.applyConfig     configuring PF  {"requestedConfig": {"pciAddress":"0000:1d:00.0","pfDriver":"pci-pf-stub","vfDriver":"vfio-pci","vfAmount":2,"bbDevConfig":{"n3000":{
"networkType":"FPGA_5GNR","pfMode":false,"flrTimeout":610,"downlink":{"bandwidth":3,"loadBalance":128,"queues":{"vf0":16,"vf1":16}},"uplink":{"bandwidth":3,"loadBalance":128,"queues":{"vf0":16,"vf1":16}}}}}}
2020-12-16T12:46:47.720Z        INFO    daemon.NodeConfigurator.loadModule      executing command       {"cmd": "/usr/sbin/chroot /host/ modprobe pci-pf-stub"}
2020-12-16T12:46:47.724Z        INFO    daemon.NodeConfigurator.loadModule      commands output {"output": ""}
2020-12-16T12:46:47.724Z        INFO    daemon.NodeConfigurator.loadModule      executing command       {"cmd": "/usr/sbin/chroot /host/ modprobe vfio-pci"}
2020-12-16T12:46:47.727Z        INFO    daemon.NodeConfigurator.loadModule      commands output {"output": ""}
2020-12-16T12:46:47.727Z        INFO    daemon.NodeConfigurator device's driver_override path   {"path": "/sys/bus/pci/devices/0000:1d:00.0/driver_override"}
2020-12-16T12:46:47.727Z        INFO    daemon.NodeConfigurator driver bind path        {"path": "/sys/bus/pci/drivers/pci-pf-stub/bind"}
2020-12-16T12:46:47.998Z        INFO    daemon.NodeConfigurator device's driver_override path   {"path": "/sys/bus/pci/devices/0000:1d:00.1/driver_override"}
2020-12-16T12:46:47.998Z        INFO    daemon.NodeConfigurator driver bind path        {"path": "/sys/bus/pci/drivers/vfio-pci/bind"}
2020-12-16T12:46:47.998Z        INFO    daemon.NodeConfigurator device's driver_override path   {"path": "/sys/bus/pci/devices/0000:1d:00.2/driver_override"}
2020-12-16T12:46:47.998Z        INFO    daemon.NodeConfigurator driver bind path        {"path": "/sys/bus/pci/drivers/vfio-pci/bind"}
2020-12-16T12:46:47.999Z        INFO    daemon.NodeConfigurator.applyConfig     executing command       {"cmd": "/sriov_workdir/pf_bb_config FPGA_5GNR -c /sriov_artifacts/0000:1d:00.0.ini -p 0000:1d:00.0"}
2020-12-16T12:46:48.017Z        INFO    daemon.NodeConfigurator.applyConfig     commands output {"output": "ERROR: Section (FLR) or name (flr_time_out) is not valid.
FEC FPGA RTL v3.0
UL.DL Weights = 3.3
UL.DL Load Balance = 1
28.128
Queue-PF/VF Mapping Table = READY
Ring Descriptor Size = 256 bytes

--------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
        |  PF | VF0 | VF1 | VF2 | VF3 | VF4 | VF5 | VF6 | VF7 |
--------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
UL-Q'00 |     |  X  |     |     |     |     |     |     |     |
UL-Q'01 |     |  X  |     |     |     |     |     |     |     |
UL-Q'02 |     |  X  |     |     |     |     |     |     |     |
UL-Q'03 |     |  X  |     |     |     |     |     |     |     |
UL-Q'04 |     |  X  |     |     |     |     |     |     |     |
UL-Q'05 |     |  X  |     |     |     |     |     |     |     |
UL-Q'06 |     |  X  |     |     |     |     |     |     |     |
UL-Q'07 |     |  X  |     |     |     |     |     |     |     |
UL-Q'08 |     |  X  |     |     |     |     |     |     |     |
UL-Q'09 |     |  X  |     |     |     |     |     |     |     |
UL-Q'10 |     |  X  |     |     |     |     |     |     |     |
UL-Q'11 |     |  X  |     |     |     |     |     |     |     |
UL-Q'12 |     |  X  |     |     |     |     |     |     |     |
UL-Q'13 |     |  X  |     |     |     |     |     |     |     |
UL-Q'14 |     |  X  |     |     |     |     |     |     |     |
UL-Q'15 |     |  X  |     |     |     |     |     |     |     |
UL-Q'16 |     |     |  X  |     |     |     |     |     |     |
UL-Q'17 |     |     |  X  |     |     |     |     |     |     |
UL-Q'18 |     |     |  X  |     |     |     |     |     |     |
UL-Q'19 |     |     |  X  |     |     |     |     |     |     |
UL-Q'20 |     |     |  X  |     |     |     |     |     |     |
UL-Q'21 |     |     |  X  |     |     |     |     |     |     |
UL-Q'22 |     |     |  X  |     |     |     |     |     |     |
UL-Q'23 |     |     |  X  |     |     |     |     |     |     |
UL-Q'24 |     |     |  X  |     |     |     |     |     |     |
UL-Q'25 |     |     |  X  |     |     |     |     |     |     |
UL-Q'26 |     |     |  X  |     |     |     |     |     |     |
UL-Q'27 |     |     |  X  |     |     |     |     |     |     |
UL-Q'28 |     |     |  X  |     |     |     |     |     |     |
UL-Q'29 |     |     |  X  |     |     |     |     |     |     |
UL-Q'30 |     |     |  X  |     |     |     |     |     |     |
UL-Q'31 |     |     |  X  |     |     |     |     |     |     |
DL-Q'32 |     |  X  |     |     |     |     |     |     |     |
DL-Q'33 |     |  X  |     |     |     |     |     |     |     |
DL-Q'34 |     |  X  |     |     |     |     |     |     |     |
DL-Q'35 |     |  X  |     |     |     |     |     |     |     |
DL-Q'36 |     |  X  |     |     |     |     |     |     |     |
DL-Q'37 |     |  X  |     |     |     |     |     |     |     |
DL-Q'38 |     |  X  |     |     |     |     |     |     |     |
DL-Q'39 |     |  X  |     |     |     |     |     |     |     |
DL-Q'40 |     |  X  |     |     |     |     |     |     |     |
DL-Q'41 |     |  X  |     |     |     |     |     |     |     |
DL-Q'42 |     |  X  |     |     |     |     |     |     |     |
DL-Q'43 |     |  X  |     |     |     |     |     |     |     |
DL-Q'44 |     |  X  |     |     |     |     |     |     |     |
DL-Q'45 |     |  X  |     |     |     |     |     |     |     |
DL-Q'46 |     |  X  |     |     |     |     |     |     |     |
DL-Q'47 |     |  X  |     |     |     |     |     |     |     |
DL-Q'48 |     |     |  X  |     |     |     |     |     |     |
DL-Q'49 |     |     |  X  |     |     |     |     |     |     |
DL-Q'50 |     |     |  X  |     |     |     |     |     |     |
DL-Q'51 |     |     |  X  |     |     |     |     |     |     |
DL-Q'52 |     |     |  X  |     |     |     |     |     |     |
DL-Q'53 |     |     |  X  |     |     |     |     |     |     |
DL-Q'54 |     |     |  X  |     |     |     |     |     |     |
DL-Q'55 |     |     |  X  |     |     |     |     |     |     |
DL-Q'56 |     |     |  X  |     |     |     |     |     |     |
DL-Q'57 |     |     |  X  |     |     |     |     |     |     |
DL-Q'58 |     |     |  X  |     |     |     |     |     |     |
DL-Q'59 |     |     |  X  |     |     |     |     |     |     |
DL-Q'60 |     |     |  X  |     |     |     |     |     |     |
DL-Q'61 |     |     |  X  |     |     |     |     |     |     |
DL-Q'62 |     |     |  X  |     |     |     |     |     |     |
DL-Q'63 |     |     |  X  |     |     |     |     |     |     |
--------+-----+-----+-----+-----+-----+-----+-----+-----+-----+

Mode of operation = VF-mode
FPGA_5GNR PF [0000:1d:00.0] configuration complete!"}
2020-12-16T12:46:48.017Z        INFO    daemon.NodeConfigurator.enableMasterBus executing command       {"cmd": "/usr/sbin/chroot /host/ setpci -v -s 0000:1d:00.0 COMMAND"}
2020-12-16T12:46:48.037Z        INFO    daemon.NodeConfigurator.enableMasterBus commands output {"output": "0000:1d:00.0 @04 = 0102\n"}
2020-12-16T12:46:48.037Z        INFO    daemon.NodeConfigurator.enableMasterBus executing command       {"cmd": "/usr/sbin/chroot /host/ setpci -v -s 0000:1d:00.0 COMMAND=0106"}
2020-12-16T12:46:48.054Z        INFO    daemon.NodeConfigurator.enableMasterBus commands output {"output": "0000:1d:00.0 @04 0106\n"}
2020-12-16T12:46:48.054Z        INFO    daemon.NodeConfigurator.enableMasterBus MasterBus set   {"pci": "0000:1d:00.0", "output": "0000:1d:00.0 @04 0106\n"}
2020-12-16T12:46:48.160Z        INFO    daemon.drainhelper.Run()        worker function - end   {"performUncordon": true}

  3. 카드의 FEC 설정을 확인합니다. 

    $ oc get sriovfecnodeconfig node1 -o yaml

    출력 예

    status:
    conditions:
    - lastTransitionTime: "2020-12-15T17:19:37Z"
      message: Configured successfully
      observedGeneration: 1
      reason: ConfigurationSucceeded
      status: "True"
      type: Configured
    inventory:
      sriovAccelerators:
      - deviceID: 0d8f 1
        driver: pci-pf-stub
        maxVirtualFunctions: 8
        pciAddress: 0000:1d:00.0
        vendorID: "8086"
      virtualFunctions:
      - deviceID: 0d90 2
        driver: vfio-pci
        pciAddress: 0000:1d:00.1
      - deviceID: 0d90
        driver: vfio-pci
        pciAddress: 0000:1d:00.2

    1
    0d8f 는 FEC 장치의 deviceID 물리적 기능입니다.
    2
    0d90 은 FEC 장치의 deviceID 가상 기능입니다.

16.4.4. Intel vRAN Dedicated Accelerator ACC100에 대한 SR-IOV-FEC Operator 구성

Intel vRAN Dedicated Accelerator ACC100을 프로그래밍하면 vRAN 워크로드에서 FEC를 가속화하는 데 사용되는 SRIOV(Single Root I/O Virtualization) VF(가상 기능) 장치가 표시됩니다. Intel vRAN Dedicated Accelerator ACC100은 4G 및 5G VRAN(가상화된 라디오 액세스 네트워크) 업무 부하를 가속화합니다. 그 결과 상용 상용 플랫폼에서의 전반적인 컴퓨팅 용량이 증가합니다. 이 장치는 Bryce 마운트라고도 합니다.

SR-IOV-FEC Operator는 vRAN L1 애플리케이션에서 FEC 프로세스를 가속화하는 데 사용되는 전달 오류 수정(FEC) 장치의 관리를 처리합니다.

SR-IOV-FEC Operator 구성에는 다음이 포함됩니다.

  • FEC 장치의 VF(가상 기능) 생성
  • VF를 적절한 드라이버에 바인딩
  • 4G 또는 5G 배포에서 원하는 기능에 대한 VF 큐 구성

FEC(전달 오류 수정)의 역할은 메시지의 특정 비트를 손실하거나 무시할 수 있는 전송 오류를 수정하는 것입니다. 전송 미디어, 간섭 또는 신호 강도의 노이즈로 인해 메시지를 손실하거나 숨길 수 있습니다. FEC가 없으면 가파른 메시지를 다시 전송하여 네트워크 부하에 추가하고 처리량과 대기 시간에 영향을 미칩니다.

사전 요구 사항

  • Intel FPGA ACC100 5G/4G 카드
  • FEC Accelerator용 OpenNESS Operator와 함께 설치된 노드 또는 노드
  • 노드의 BIOS에서 글로벌 SR-IOV 및 VT-d 설정 활성화
  • Performance Addon Operator로 구성된 RT 커널
  • cluster-admin 권한이 있는 사용자로 로그인합니다.

절차

  1. vran-acceleration-operators 프로젝트로 변경합니다. 

    $ oc project vran-acceleration-operators

  2. SR-IOV-FEC Operator가 설치되었는지 확인합니다. 

    $ oc get csv -o custom-columns=Name:.metadata.name,Phase:.status.phase

    출력 예

    Name                                        Phase
sriov-fec.v1.1.0                            Succeeded

  3. sriov-fec Pod가 실행 중인지 확인합니다. 

    $  oc get pods

    출력 예

    NAME                                            READY       STATUS      RESTARTS    AGE
sriov-device-plugin-j5jlv                       1/1         Running     1           15d
sriov-fec-controller-manager-85b6b8f4d4-gd2qg   1/1         Running     1           15d
sriov-fec-daemonset-kqqs6                       1/1         Running     1           15d

    • sriov-device-plugin 은 FEC 가상 기능을 노드 아래의 리소스로 노출
    • sriov-fec-controller-manager 가 노드에 CR을 적용하고 피연산자 컨테이너를 유지 관리합니다.

    • sriov-fec-daemonset 는 다음을 담당합니다.

      • 각 노드에서 SRIOV NIC 검색.
      • 6단계에 정의된 CR(사용자 정의 리소스)의 상태 동기화.
      • CR의 사양을 입력으로 사용하고 검색된 NIC를 구성합니다.

  4. 지원되는 vRAN FEC 액셀러레이터 장치 중 하나를 포함하는 모든 노드를 검색합니다. 

    $ oc get sriovfecnodeconfig

    출력 예

    NAME             CONFIGURED
node1            Succeeded

  5. SR-IOV FEC 액셀러레이터 장치의 물리적 기능(PF)을 검색하여 구성합니다. 

    $ oc get sriovfecnodeconfig node1 -o yaml

    출력 예

    status:
    conditions:
    - lastTransitionTime: "2021-03-19T17:19:37Z"
      message: Configured successfully
      observedGeneration: 1
      reason: ConfigurationSucceeded
      status: "True"
      type: Configured
    inventory:
       sriovAccelerators:
       - deviceID: 0d5c
         driver: ""
         maxVirtualFunctions: 16
         pciAddress: 0000:af:00.0 1
         vendorID: "8086"
         virtualFunctions: [] 2

    1
    이 필드는 카드의 PCI 주소를 나타냅니다.
    2
    이 필드는 가상 기능이 비어 있음을 보여줍니다.

  6. FEC 장치에 가상 함수 및 대기열 그룹 수를 구성합니다.

    1. 다음 CR(사용자 정의 리소스)을 생성하고 YAML을 sriovfec_acc100cr.yaml 파일에 저장합니다.

      참고

      이 예제에서는 5G의 ACC100 8/8 큐 그룹, Uplink에 대한 4개 큐 그룹 및 Downlink에 대한 다른 4개 큐 그룹을 구성합니다. 

      apiVersion: sriovfec.intel.com/v1
kind: SriovFecClusterConfig
metadata:
  name: config 1
spec:
  nodes:
   - nodeName: node1 2
     physicalFunctions:
       - pciAddress: 0000:af:00.0 3
         pfDriver: "pci-pf-stub"
         vfDriver: "vfio-pci"
         vfAmount: 16 4
         bbDevConfig:
           acc100:
             # Programming mode: 0 = VF Programming, 1 = PF Programming
             pfMode: false
             numVfBundles: 16
             maxQueueSize: 1024
             uplink4G:
               numQueueGroups: 0
               numAqsPerGroups: 16
               aqDepthLog2: 4
             downlink4G:
              numQueueGroups: 0
              numAqsPerGroups: 16
              aqDepthLog2: 4
             uplink5G:
              numQueueGroups: 4
              numAqsPerGroups: 16
              aqDepthLog2: 4
             downlink5G:
              numQueueGroups: 4
              numAqsPerGroups: 16
              aqDepthLog2: 4
      1
      CR 오브젝트의 이름을 지정합니다. 지정할 수 있는 유일한 이름은 config 입니다.
      2
      노드 이름을 지정합니다.
      3
      SR-IOV-FEC Operator를 설치할 카드의 PCI 주소를 지정합니다.
      4
      생성할 가상 함수 수를 지정합니다. Intel vRAN Dedicated Accelerator ACC100의 경우 16 VF를 모두 생성합니다.
      참고

      이 카드는 그룹당 최대 16개의 큐가 있는 최대 8개의 큐 그룹을 제공하도록 구성됩니다. 큐 그룹은 5G 및 4G 및 Uplink 및 Downlink에 할당된 그룹 간에 나눌 수 있습니다. Intel vRAN Dedicated Accelerator ACC100은 다음을 위해 구성할 수 있습니다.

      • 4G 또는 5G 전용
      • 4G 및 5G 동시에

      구성된 각 VF는 모든 큐에 액세스할 수 있습니다. 각 큐 그룹에는 고유한 우선 순위 수준이 있습니다. 지정된 큐 그룹에 대한 요청은 FEC 장치를 활용하는 vRAN 애플리케이션인 애플리케이션 수준에서 이루어집니다.

    2. CR을 적용합니다. 

      $ oc apply -f sriovfec_acc100cr.yaml

      CR을 적용하면 SR-IOV FEC 데몬이 FEC 장치 구성을 시작합니다.

검증

  1. 상태를 확인합니다. 

    $ oc get sriovfecclusterconfig config -o yaml

    출력 예

    status:
    conditions:
    - lastTransitionTime: "2021-03-19T11:46:22Z"
      message: Configured successfully
      observedGeneration: 1
      reason: Succeeded
      status: "True"
      type: Configured
    inventory:
      sriovAccelerators:
      - deviceID: 0d5c
        driver: pci-pf-stub
        maxVirtualFunctions: 16
        pciAddress: 0000:af:00.0
        vendorID: "8086"
        virtualFunctions:
        - deviceID: 0d5d
          driver: vfio-pci
          pciAddress: 0000:b0:00.0
        - deviceID: 0d5d
          driver: vfio-pci
          pciAddress: 0000:b0:00.1
        - deviceID: 0d5d
          driver: vfio-pci
          pciAddress: 0000:b0:00.2
        - deviceID: 0d5d
          driver: vfio-pci
          pciAddress: 0000:b0:00.3
        - deviceID: 0d5d
          driver: vfio-pci
          pciAddress: 0000:b0:00.4

  2. 로그를 확인합니다.

    1. SR-IOV 데몬의 Pod 이름을 확인합니다. 

      $ oc get po -o wide | grep sriov-fec-daemonset | grep node1

      출력 예

      sriov-fec-daemonset-kqqs6                      1/1     Running   0          19h

    2. 로그를 확인합니다. 

      $ oc logs sriov-fec-daemonset-kqqs6

      출력 예

      {"level":"Level(-2)","ts":1616794345.4786215,"logger":"daemon.drainhelper.cordonAndDrain()","msg":"node drained"}
{"level":"Level(-4)","ts":1616794345.4786265,"logger":"daemon.drainhelper.Run()","msg":"worker function - start"}
{"level":"Level(-4)","ts":1616794345.5762916,"logger":"daemon.NodeConfigurator.applyConfig","msg":"current node status","inventory":{"sriovAccelerat
ors":[{"vendorID":"8086","deviceID":"0b32","pciAddress":"0000:20:00.0","driver":"","maxVirtualFunctions":1,"virtualFunctions":[]},{"vendorID":"8086"
,"deviceID":"0d5c","pciAddress":"0000:af:00.0","driver":"","maxVirtualFunctions":16,"virtualFunctions":[]}]}}
{"level":"Level(-4)","ts":1616794345.5763638,"logger":"daemon.NodeConfigurator.applyConfig","msg":"configuring PF","requestedConfig":{"pciAddress":"
0000:af:00.0","pfDriver":"pci-pf-stub","vfDriver":"vfio-pci","vfAmount":2,"bbDevConfig":{"acc100":{"pfMode":false,"numVfBundles":16,"maxQueueSize":1
024,"uplink4G":{"numQueueGroups":4,"numAqsPerGroups":16,"aqDepthLog2":4},"downlink4G":{"numQueueGroups":4,"numAqsPerGroups":16,"aqDepthLog2":4},"uplink5G":{"numQueueGroups":0,"numAqsPerGroups":16,"aqDepthLog2":4},"downlink5G":{"numQueueGroups":0,"numAqsPerGroups":16,"aqDepthLog2":4}}}}}
{"level":"Level(-4)","ts":1616794345.5774765,"logger":"daemon.NodeConfigurator.loadModule","msg":"executing command","cmd":"/usr/sbin/chroot /host/ modprobe pci-pf-stub"}
{"level":"Level(-4)","ts":1616794345.5842702,"logger":"daemon.NodeConfigurator.loadModule","msg":"commands output","output":""}
{"level":"Level(-4)","ts":1616794345.5843055,"logger":"daemon.NodeConfigurator.loadModule","msg":"executing command","cmd":"/usr/sbin/chroot /host/ modprobe vfio-pci"}
{"level":"Level(-4)","ts":1616794345.6090655,"logger":"daemon.NodeConfigurator.loadModule","msg":"commands output","output":""}
{"level":"Level(-2)","ts":1616794345.6091156,"logger":"daemon.NodeConfigurator","msg":"device's driver_override path","path":"/sys/bus/pci/devices/0000:af:00.0/driver_override"}
{"level":"Level(-2)","ts":1616794345.6091807,"logger":"daemon.NodeConfigurator","msg":"driver bind path","path":"/sys/bus/pci/drivers/pci-pf-stub/bind"}
{"level":"Level(-2)","ts":1616794345.7488534,"logger":"daemon.NodeConfigurator","msg":"device's driver_override path","path":"/sys/bus/pci/devices/0000:b0:00.0/driver_override"}
{"level":"Level(-2)","ts":1616794345.748938,"logger":"daemon.NodeConfigurator","msg":"driver bind path","path":"/sys/bus/pci/drivers/vfio-pci/bind"}
{"level":"Level(-2)","ts":1616794345.7492096,"logger":"daemon.NodeConfigurator","msg":"device's driver_override path","path":"/sys/bus/pci/devices/0000:b0:00.1/driver_override"}
{"level":"Level(-2)","ts":1616794345.7492566,"logger":"daemon.NodeConfigurator","msg":"driver bind path","path":"/sys/bus/pci/drivers/vfio-pci/bind"}
{"level":"Level(-4)","ts":1616794345.74968,"logger":"daemon.NodeConfigurator.applyConfig","msg":"executing command","cmd":"/sriov_workdir/pf_bb_config ACC100 -c /sriov_artifacts/0000:af:00.0.ini -p 0000:af:00.0"}
{"level":"Level(-4)","ts":1616794346.5203931,"logger":"daemon.NodeConfigurator.applyConfig","msg":"commands output","output":"Queue Groups: 0 5GUL, 0 5GDL, 4 4GUL, 4 4GDL\nNumber of 5GUL engines 8\nConfiguration in VF mode\nPF ACC100 configuration complete\nACC100 PF [0000:af:00.0] configuration complete!\n\n"}
{"level":"Level(-4)","ts":1616794346.520459,"logger":"daemon.NodeConfigurator.enableMasterBus","msg":"executing command","cmd":"/usr/sbin/chroot /host/ setpci -v -s 0000:af:00.0 COMMAND"}
{"level":"Level(-4)","ts":1616794346.5458736,"logger":"daemon.NodeConfigurator.enableMasterBus","msg":"commands output","output":"0000:af:00.0 @04 = 0142\n"}
{"level":"Level(-4)","ts":1616794346.5459251,"logger":"daemon.NodeConfigurator.enableMasterBus","msg":"executing command","cmd":"/usr/sbin/chroot /host/ setpci -v -s 0000:af:00.0 COMMAND=0146"}
{"level":"Level(-4)","ts":1616794346.5795262,"logger":"daemon.NodeConfigurator.enableMasterBus","msg":"commands output","output":"0000:af:00.0 @04 0146\n"}
{"level":"Level(-2)","ts":1616794346.5795407,"logger":"daemon.NodeConfigurator.enableMasterBus","msg":"MasterBus set","pci":"0000:af:00.0","output":"0000:af:00.0 @04 0146\n"}
{"level":"Level(-4)","ts":1616794346.6867144,"logger":"daemon.drainhelper.Run()","msg":"worker function - end","performUncordon":true}
{"level":"Level(-4)","ts":1616794346.6867719,"logger":"daemon.drainhelper.Run()","msg":"uncordoning node"}
{"level":"Level(-4)","ts":1616794346.6896322,"logger":"daemon.drainhelper.uncordon()","msg":"starting uncordon attempts"}
{"level":"Level(-2)","ts":1616794346.69735,"logger":"daemon.drainhelper.uncordon()","msg":"node uncordoned"}
{"level":"Level(-4)","ts":1616794346.6973662,"logger":"daemon.drainhelper.Run()","msg":"cancelling the context to finish the leadership"}
{"level":"Level(-4)","ts":1616794346.7029872,"logger":"daemon.drainhelper.Run()","msg":"stopped leading"}
{"level":"Level(-4)","ts":1616794346.7030034,"logger":"daemon.drainhelper","msg":"releasing the lock (bug mitigation)"}
{"level":"Level(-4)","ts":1616794346.8040674,"logger":"daemon.updateInventory","msg":"obtained inventory","inv":{"sriovAccelerators":[{"vendorID":"8086","deviceID":"0b32","pciAddress":"0000:20:00.0","driver":"","maxVirtualFunctions":1,"virtualFunctions":[]},{"vendorID":"8086","deviceID":"0d5c","pciAddress":"0000:af:00.0","driver":"pci-pf-stub","maxVirtualFunctions":16,"virtualFunctions":[{"pciAddress":"0000:b0:00.0","driver":"vfio-pci","deviceID":"0d5d"},{"pciAddress":"0000:b0:00.1","driver":"vfio-pci","deviceID":"0d5d"}]}]}}
{"level":"Level(-4)","ts":1616794346.9058325,"logger":"daemon","msg":"Update ignored, generation unchanged"}
{"level":"Level(-2)","ts":1616794346.9065044,"logger":"daemon.Reconcile","msg":"Reconciled","namespace":"vran-acceleration-operators","name":"pg-itengdvs02r.altera.com"}

  3. 카드의 FEC 설정을 확인합니다. 

    $ oc get sriovfecnodeconfig node1 -o yaml

    출력 예

    status:
    conditions:
    - lastTransitionTime: "2021-03-19T11:46:22Z"
      message: Configured successfully
      observedGeneration: 1
      reason: Succeeded
      status: "True"
      type: Configured
    inventory:
      sriovAccelerators:
      - deviceID: 0d5c 1
        driver: pci-pf-stub
        maxVirtualFunctions: 16
        pciAddress: 0000:af:00.0
        vendorID: "8086"
        virtualFunctions:
        - deviceID: 0d5d 2
          driver: vfio-pci
          pciAddress: 0000:b0:00.0
        - deviceID: 0d5d
          driver: vfio-pci
          pciAddress: 0000:b0:00.1
        - deviceID: 0d5d
          driver: vfio-pci
          pciAddress: 0000:b0:00.2
        - deviceID: 0d5d
          driver: vfio-pci
          pciAddress: 0000:b0:00.3
        - deviceID: 0d5d
          driver: vfio-pci
          pciAddress: 0000:b0:00.4

    1
    값 0d5c 는 FEC 장치의 deviceID 물리적 기능입니다.
    2
    값 0d5d 는 FEC 장치의 deviceID 가상 기능입니다.

16.4.5. OpenNESS에서 애플리케이션 Pod 액세스 및 FPGA 사용 확인

개방성은 모든 유형의 네트워크에서 애플리케이션 및 네트워크 기능을 온보드하고 관리하는 데 사용할 수 있는 에지 컴퓨팅 소프트웨어 툴킷입니다.

SR-IOV 바인딩, 장치 플러그인,bbdev(bbdev) 구성, 루트가 아닌 Pod 내의 SR-IOV(FEC) VF 기능을 포함하여 모든 OpenNESS 기능이 함께 작동하는지 확인하기 위해 이미지를 빌드하고 장치에 대한 간단한 검증 애플리케이션을 실행할 수 있습니다.

자세한 내용은 openess.org 에서 확인하십시오.

사전 요구 사항

  • 선택 사항: Intel FPGA PAC N3000 카드
  • n3000-operator와 함께 설치된 노드 또는 노드
  • SR-IOV-FEC Operator와 함께 설치된 노드 또는 노드
  • Performance Addon Operator로 구성된 실시간 커널 및 대규모 페이지
  • cluster-admin 권한이 있는 사용자로 로그인합니다.

절차

  1. 다음 작업을 완료하여 테스트의 네임스페이스를 생성합니다.

    1. 다음 예와 같이 test-bbdev -namespace.yaml 파일 파일을 생성하여 test-bbdev 네임스페이스를 정의합니다. 

      apiVersion: v1
kind: Namespace
metadata:
  name: test-bbdev
  labels:
    openshift.io/run-level: "1"

    2. 다음 명령을 실행하여 네임스페이스를 생성합니다. 

      $ oc create -f test-bbdev-namespace.yaml

  2. 다음 Pod 사양을 생성한 다음 YAML을 pod-test.yaml 파일에 저장합니다. 

    apiVersion: v1
kind: Pod
metadata:
  name: pod-bbdev-sample-app
  namespace: test-bbdev 1
spec:
  containers:
  - securityContext:
      privileged: false
      capabilities:
        add:
         - IPC_LOCK
         - SYS_NICE
    name: bbdev-sample-app
    image: bbdev-sample-app:1.0  2
    command: [ "sudo", "/bin/bash", "-c", "--" ]
    runAsUser: 0 3
    resources:
      requests:
        hugepages-1Gi: 4Gi 4
        memory: 1Gi
        cpu: "4" 5
        intel.com/intel_fec_5g: '1' 6
        #intel.com/intel_fec_acc100: '1'
        #intel.com/intel_fec_lte: '1'
      limits:
        memory: 4Gi
        cpu: "4"
        hugepages-1Gi: 4Gi
        intel.com/intel_fec_5g: '1'
        #intel.com/intel_fec_acc100: '1'
        #intel.com/intel_fec_lte: '1
    1
    1단계에서 생성한 네임스페이스 를 지정합니다.
    2
    이는 컴파일된 DPDK를 포함하는 테스트 이미지를 정의합니다.
    3
    컨테이너를 root 사용자로 내부적으로 실행하도록 설정합니다.
    4
    hugepage 크기 hugepages-1Gi 를 지정하고 Pod에 할당할 hugepage 수량을 지정합니다. Performance Addon Operator를 사용하여 대규모 페이지 및 분리된 CPU를 구성해야 합니다.
    5
    CPU 수를 지정합니다.
    6
    intel.com/intel_fec_5g 에서 N3000 5G FEC 구성 테스트를 지원합니다.
    참고

    ACC100 구성을 테스트하려면 # 기호를 제거하여 intel.com/intel_fec_acc100 의 주석을 제거합니다. N3000 4G/LTE 구성을 테스트하려면 # 기호를 제거하여 intel.com/intel_fec_lte 의 주석을 제거합니다. 언제든지 하나의 리소스만 활성화할 수 있습니다.

  3. Pod를 생성합니다. 

    $ oc apply -f pod-test.yaml

  4. Pod가 생성되었는지 확인합니다. 

    $ oc get pods -n test-bbdev

    출력 예

    NAME                                            READY           STATUS          RESTARTS        AGE
pod-bbdev-sample-app                            1/1             Running         0               80s

  5. 원격 쉘을 사용하여 pod-bbdev-sample-app 에 로그인합니다. 

    $ oc rsh pod-bbdev-sample-app

    출력 예

    sh-4.4#

  6. 환경 변수 목록을 인쇄합니다. 

    sh-4.4# env

    출력 예

    N3000_CONTROLLER_MANAGER_METRICS_SERVICE_PORT_8443_TCP_ADDR=172.30.133.131
SRIOV_FEC_CONTROLLER_MANAGER_METRICS_SERVICE_PORT_8443_TCP_PROTO=tcp
DPDK_VERSION=20.11
PCIDEVICE_INTEL_COM_INTEL_FEC_5G=0.0.0.0:1d.00.0 1
~/usr/bin/env
HOSTNAME=fec-pod

    1
    가상 기능의 PCI 주소입니다. pod-test.yaml 파일에서 요청한 리소스에 따라 다음 세 개의 PCI 주소 중 하나일 수 있습니다.
    • PCIDEVICE_INTEL_COM_INTEL_FEC_ACC100
    • PCIDEVICE_INTEL_COM_INTEL_FEC_5G
    • PCIDEVICE_INTEL_COM_INTEL_FEC_LTE

  7. test-bbdev 디렉터리로 변경합니다. 

    sh-4.4# cd test/test-bbdev/
    참고

    디렉터리는 로컬 컴퓨터가 아닌 포드에 있습니다.

  8. Pod에 할당된 CPU를 확인합니다. 

    sh-4.4# export CPU=$(cat /sys/fs/cgroup/cpuset/cpuset.cpus)
sh-4.4# echo ${CPU}

    그러면 the fec.pod 에 할당된 CPU가 출력됩니다.

    출력 예

    24,25,64,65

  9. test-bbdev 애플리케이션을 실행하여 장치를 테스트합니다. 

    sh-4.4# ./test-bbdev.py -e="-l ${CPU} -a ${PCIDEVICE_INTEL_COM_INTEL_FEC_5G}" -c validation \ -n 64 -b 32 -l 1 -v ./test_vectors/*"

    출력 예

    Executing: ../../build/app/dpdk-test-bbdev -l 24-25,64-65 0000:1d.00.0 -- -n 64 -l 1 -c validation -v ./test_vectors/bbdev_null.data -b 32
EAL: Detected 80 lcore(s)
EAL: Detected 2 NUMA nodes
Option -w, --pci-whitelist is deprecated, use -a, --allow option instead
EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
EAL: Selected IOVA mode 'VA'
EAL: Probing VFIO support...
EAL: VFIO support initialized
EAL:   using IOMMU type 1 (Type 1)
EAL: Probe PCI driver: intel_fpga_5ngr_fec_vf (8086:d90) device: 0000:1d.00.0 (socket 1)
EAL: No legacy callbacks, legacy socket not created



===========================================================
Starting Test Suite : BBdev Validation Tests
Test vector file = ldpc_dec_v7813.data
Device 0 queue 16 setup failed
Allocated all queues (id=16) at prio0 on dev0
Device 0 queue 32 setup failed
Allocated all queues (id=32) at prio1 on dev0
Device 0 queue 48 setup failed
Allocated all queues (id=48) at prio2 on dev0
Device 0 queue 64 setup failed
Allocated all queues (id=64) at prio3 on dev0
Device 0 queue 64 setup failed
All queues on dev 0 allocated: 64
+ ------------------------------------------------------- +
== test: validation
dev:0000:b0:00.0, burst size: 1, num ops: 1, op type: RTE_BBDEV_OP_LDPC_DEC
Operation latency:
        avg: 23092 cycles, 10.0838 us
        min: 23092 cycles, 10.0838 us
        max: 23092 cycles, 10.0838 us
TestCase [ 0] : validation_tc passed
 + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +
 + Test Suite Summary : BBdev Validation Tests
 + Tests Total :        1
 + Tests Skipped :      0
 + Tests Passed :       1 1
 + Tests Failed :       0
 + Tests Lasted :       177.67 ms
 + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +

    1
    일부 테스트를 건너뛸 수 있지만 벡터 테스트가 통과되는지 확인하십시오.

16.5. 추가 리소스

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

© 2024 Red Hat, Inc.