9.2. PolicyGenerator 리소스를 사용한 고급 관리 클러스터 구성

프로세스

1. 다음과 같이 out/argocd/example/acmpolicygenerator// 에서 acm-group-du-sno-ranGen.yaml 참조 파일에서 PerformanceProfile 의 PolicyGenerator 항목을 업데이트합니다.

   - path: source-crs/PerformanceProfile.yaml
     patches:
       - spec:
           workloadHints:
                realTime: true
                highPowerConsumption: false
                perPodPowerManagement: false

2. Git에서 PolicyGenerator 변경 사항을 커밋한 다음 GitOps ZTP Argo CD 애플리케이션에서 모니터링하는 Git 리포지토리로 내보냅니다.

프로세스

1. 다음과 같이 out/argocd/example/acmpolicygenerator/ 에서 acm-group-du-sno-ranGen.yaml 참조 파일에서 PerformanceProfile 의 PolicyGenerator 항목을 업데이트합니다.

   - path: source-crs/PerformanceProfile.yaml
     patches:
       - spec:
           workloadHints:
                realTime: true
                highPowerConsumption: true
                perPodPowerManagement: false

2. Git에서 PolicyGenerator 변경 사항을 커밋한 다음 GitOps ZTP Argo CD 애플리케이션에서 모니터링하는 Git 리포지토리로 내보냅니다.

프로세스

1. 전원 저장 모드를 구성하려면 다음과 같이 out/argocd/example/acmpolicygenerator/ 에서 acm-group-du-sno-ranGen.yaml 참조 파일에서 PerformanceProfile 에 대한 PolicyGenerator 항목을 업데이트합니다. 추가 커널 인수 오브젝트를 통해 전원 저장 모드에 대한 CPU governor를 구성하는 것이 좋습니다.

   - path: source-crs/PerformanceProfile.yaml
     patches:
       - spec:
           # ...
           workloadHints:
             realTime: true
             highPowerConsumption: false
             perPodPowerManagement: true
           # ...
           additionalKernelArgs:
             - # ...
             - "cpufreq.default_governor=schedutil" 1

   1

   그러나 schedutil governor를 사용하는 것이 좋습니다. 그러나 온디맨드 및 전원저장 을 포함한 다른 governor도 사용할 수 있습니다.

2. Git에서 PolicyGenerator 변경 사항을 커밋한 다음 GitOps ZTP Argo CD 애플리케이션에서 모니터링하는 Git 리포지토리로 내보냅니다.

검증

1. 다음 명령을 사용하여 식별된 노드 목록에서 배포된 클러스터에서 작업자 노드를 선택합니다.

   $ oc get nodes

2. 다음 명령을 사용하여 노드에 로그인합니다.

   $ oc debug node/<node-name>

   & lt;node-name >을 전원 상태를 확인할 노드의 이름으로 바꿉니다.

3. 디버그 쉘 내에서 /host를 root 디렉터리로 설정합니다. 디버그 Pod는 Pod 내의 /host에 호스트의 루트 파일 시스템을 마운트합니다. root 디렉토리를 /host 로 변경하면 다음 예와 같이 호스트의 실행 경로에 포함된 바이너리를 실행할 수 있습니다.

   # chroot /host

4. 다음 명령을 실행하여 적용된 전원 상태를 확인합니다.

   # cat /proc/cmdline

프로세스

1. out/argocd/example/acmpolicygenerator/ 에서 acm-group-du-sno-ranGen.yaml 참조 파일에서 TunedPerformancePatch 에 대한 PolicyGenerator 항목을 업데이트합니다. 전원 절감을 극대화하려면 다음 예와 같이 max_perf_pct 를 추가합니다.

   - path: source-crs/TunedPerformancePatch.yaml
     patches:
       - spec:
         profile:
           - name: performance-patch
             data: |
               # ...
               [sysfs]
               /sys/devices/system/cpu/intel_pstate/max_perf_pct=<x> 1

   1

   max_perf_pct 는 cpufreq 드라이버가 지원되는 최대 CPU 빈도의 백분율로 설정할 수 있는 최대 빈도를 제어합니다. 이 값은 모든 CPU에 적용됩니다. /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq 에서 지원되는 최대 빈도를 확인할 수 있습니다. 시작점으로 모든 CPU를 모든 코어 frequency로 제한하는 백분율로 사용할 수 있습니다. All Cores Cryostat 빈도는 코어가 완전히 비어 있을 때 모든 코어가 실행되는 빈도입니다.

   참고

   전력 절감을 극대화하려면 더 낮은 가치를 설정하십시오. max_perf_pct 에 대한 더 낮은 값을 설정하면 최대 CPU 빈도가 제한되므로 전력 소비가 줄어들지만 잠재적으로 성능에 영향을 미칠 수 있습니다. 다양한 값을 실험하고 시스템의 성능 및 전력 소비를 모니터링하여 사용 사례에 가장 적합한 설정을 찾습니다.

2. Git에서 PolicyGenerator 변경 사항을 커밋한 다음 GitOps ZTP Argo CD 애플리케이션에서 모니터링하는 Git 리포지토리로 내보냅니다.

프로세스

1. 요구 사항에 따라 acm-group-du-3node-ranGen.yaml,acm-group-du-sno-ranGen.yaml 또는 acm-group-du-standard-ranGen.yaml 파일에 다음 PolicyGenerator 변경 사항을 적용합니다.

   1. policies.manifests 에서 전송 호스트를 구성하는 PtpOperatorConfig CR 파일을 추가합니다.

      - path: source-crs/PtpOperatorConfigForEvent.yaml
        patches:
        - metadata:
            name: default
            namespace: openshift-ptp
            annotations:
              ran.openshift.io/ztp-deploy-wave: "10"
          spec:
            daemonNodeSelector:
              node-role.kubernetes.io/$mcp: ""
            ptpEventConfig:
              enableEventPublisher: true
              transportHost: "http://ptp-event-publisher-service-NODE_NAME.openshift-ptp.svc.cluster.local:9043"

      참고

      OpenShift Container Platform 4.13 이상에서는 PTP 이벤트와 함께 HTTP 전송을 사용할 때 PtpOperatorConfig 리소스에서 transportHost 필드를 설정할 필요가 없습니다.

   2. PTP 클럭 유형 및 인터페이스에 대해 linuxptp 및 phc2sys 를 구성합니다. 예를 들어 policies.manifests 에 다음 YAML을 추가합니다.

      - path: source-crs/PtpConfigSlave.yaml 1
        patches:
        - metadata:
            name: "du-ptp-slave"
          spec:
            recommend:
            - match:
              - nodeLabel: node-role.kubernetes.io/master
              priority: 4
              profile: slave
            profile:
            - name: "slave"
              # This interface must match the hardware in this group
              interface: "ens5f0" 2
              ptp4lOpts: "-2 -s --summary_interval -4" 3
              phc2sysOpts: "-a -r -n 24" 4
              ptpSchedulingPolicy: SCHED_FIFO
              ptpSchedulingPriority: 10
              ptpSettings:
                logReduce: "true"
              ptp4lConf: |
                [global]
                #
                # Default Data Set
                #
                twoStepFlag 1
                slaveOnly 1
                priority1 128
                priority2 128
                domainNumber 24
                #utc_offset 37
                clockClass 255
                clockAccuracy 0xFE
                offsetScaledLogVariance 0xFFFF
                free_running 0
                freq_est_interval 1
                dscp_event 0
                dscp_general 0
                dataset_comparison G.8275.x
                G.8275.defaultDS.localPriority 128
                #
                # Port Data Set
                #
                logAnnounceInterval -3
                logSyncInterval -4
                logMinDelayReqInterval -4
                logMinPdelayReqInterval -4
                announceReceiptTimeout 3
                syncReceiptTimeout 0
                delayAsymmetry 0
                fault_reset_interval -4
                neighborPropDelayThresh 20000000
                masterOnly 0
                G.8275.portDS.localPriority 128
                #
                # Run time options
                #
                assume_two_step 0
                logging_level 6
                path_trace_enabled 0
                follow_up_info 0
                hybrid_e2e 0
                inhibit_multicast_service 0
                net_sync_monitor 0
                tc_spanning_tree 0
                tx_timestamp_timeout 50
                unicast_listen 0
                unicast_master_table 0
                unicast_req_duration 3600
                use_syslog 1
                verbose 0
                summary_interval 0
                kernel_leap 1
                check_fup_sync 0
                clock_class_threshold 7
                #
                # Servo Options
                #
                pi_proportional_const 0.0
                pi_integral_const 0.0
                pi_proportional_scale 0.0
                pi_proportional_exponent -0.3
                pi_proportional_norm_max 0.7
                pi_integral_scale 0.0
                pi_integral_exponent 0.4
                pi_integral_norm_max 0.3
                step_threshold 2.0
                first_step_threshold 0.00002
                max_frequency 900000000
                clock_servo pi
                sanity_freq_limit 200000000
                ntpshm_segment 0
                #
                # Transport options
                #
                transportSpecific 0x0
                ptp_dst_mac 01:1B:19:00:00:00
                p2p_dst_mac 01:80:C2:00:00:0E
                udp_ttl 1
                udp6_scope 0x0E
                uds_address /var/run/ptp4l
                #
                # Default interface options
                #
                clock_type OC
                network_transport L2
                delay_mechanism E2E
                time_stamping hardware
                tsproc_mode filter
                delay_filter moving_median
                delay_filter_length 10
                egressLatency 0
                ingressLatency 0
                boundary_clock_jbod 0
                #
                # Clock description
                #
                productDescription ;;
                revisionData ;;
                manufacturerIdentity 00:00:00
                userDescription ;
                timeSource 0xA0
            ptpClockThreshold: 5
              holdOverTimeout: 30 # seconds
              maxOffsetThreshold: 100  # nano seconds
              minOffsetThreshold: -100

      1

      요구 사항에 따라 PtpConfigMaster.yaml,PtpConfigSlave.yaml 또는 PtpConfigSlaveCvl.yaml 중 하나일 수 있습니다. PtpConfigSlaveCvl.yaml 은 Intel E810 Columbiaville NIC의 linuxptp 서비스를 구성합니다. acm-group-du-sno-ranGen.yaml 또는 acm-group-du-3node-ranGen.yaml 기반 구성의 경우 PtpConfigSlave.yaml 을 사용합니다.

      2

      장치별 인터페이스 이름입니다.

      3

      PTP 빠른 이벤트를 활성화하려면 .spec.sourceFiles.spec.profile 의 ptp4lOpts 에 --summary_interval -4 값을 추가해야 합니다.

      4

      필수 phc2sysOpts 값. -m 은 메시지를 stdout 에 출력합니다. linuxptp-daemon DaemonSet 은 로그를 구문 분석하고 Prometheus 지표를 생성합니다.

      5

      선택 사항: ptpClockThreshold 스탠자가 없으면 ptpClockThreshold 필드에 기본값이 사용됩니다. 스탠자는 기본 ptpClockThreshold 값을 표시합니다. ptpClockThreshold 값은 PTP 이벤트가 트리거되기 전에 PTP 마스터 클록의 연결이 해제된 후의 시간을 구성합니다. holdOverTimeout 은 PTP 마스터 클록의 연결이 끊어지면 PTP 클럭 이벤트 상태가 Free RUN 으로 변경되기 전의 시간(초)입니다. maxOffsetThreshold 및 minOffsetThreshold 설정은 CLOCK_REALTIME (phc2sys) 또는 master 오프셋(ptp4l)의 값과 비교하는 오프셋 값을 나노초로 구성합니다. ptp4l 또는 phc2sys 오프셋 값이 이 범위를 벗어나는 경우 PTP 클럭 상태가 Free RUN으로 설정됩니다. 오프셋 값이 이 범위 내에 있으면 PTP 클럭 상태가 LOCKED 로 설정됩니다.

2. 기타 필요한 변경 사항 및 파일을 사용자 지정 사이트 리포지토리와 병합합니다.
3. GitOps ZTP를 사용하여 새 사이트에 PTP 빠른 이벤트를 배포하려면 사이트 구성 리포지토리로 변경 사항을 푸시합니다.

프로세스

1. storage.bu 파일을 생성합니다.

   variant: fcos
   version: 1.3.0
   storage:
     disks:
     - device: /dev/disk/by-path/pci-0000:01:00.0-scsi-0:2:0:0 1
       wipe_table: false
       partitions:
       - label: var-lib-containers
         start_mib: <start_of_partition> 2
         size_mib: <partition_size> 3
     filesystems:
       - path: /var/lib/containers
         device: /dev/disk/by-partlabel/var-lib-containers
         format: xfs
         wipe_filesystem: true
         with_mount_unit: true
         mount_options:
           - defaults
           - prjquota

   1

   root 디스크를 지정합니다.

   2

   MiB로 파티션의 시작을 지정합니다. 값이 너무 작으면 설치에 실패합니다.

   3

   파티션의 크기를 지정합니다. 값이 너무 작으면 배포에 실패합니다.

2. 다음 명령을 실행하여 storage.bu 를 Ignition 파일로 변환합니다.

   $ butane storage.bu

   출력 예

   {"ignition":{"version":"3.2.0"},"storage":{"disks":[{"device":"/dev/disk/by-path/pci-0000:01:00.0-scsi-0:2:0:0","partitions":[{"label":"var-lib-containers","sizeMiB":0,"startMiB":250000}],"wipeTable":false}],"filesystems":[{"device":"/dev/disk/by-partlabel/var-lib-containers","format":"xfs","mountOptions":["defaults","prjquota"],"path":"/var/lib/containers","wipeFilesystem":true}]},"systemd":{"units":[{"contents":"# # Generated by Butane\n[Unit]\nRequires=systemd-fsck@dev-disk-by\\x2dpartlabel-var\\x2dlib\\x2dcontainers.service\nAfter=systemd-fsck@dev-disk-by\\x2dpartlabel-var\\x2dlib\\x2dcontainers.service\n\n[Mount]\nWhere=/var/lib/containers\nWhat=/dev/disk/by-partlabel/var-lib-containers\nType=xfs\nOptions=defaults,prjquota\n\n[Install]\nRequiredBy=local-fs.target","enabled":true,"name":"var-lib-containers.mount"}]}}

3. JSON Pretty Print 와 같은 도구를 사용하여 출력을 JSON 형식으로 변환합니다.

4. 출력을 SiteConfig CR의 .spec.clusters.nodes.ignitionConfigOverride 필드에 복사합니다.

   예

   [...]
   spec:
     clusters:
       - nodes:
           - ignitionConfigOverride: |
             {
               "ignition": {
                 "version": "3.2.0"
               },
               "storage": {
                 "disks": [
                   {
                     "device": "/dev/disk/by-path/pci-0000:01:00.0-scsi-0:2:0:0",
                     "partitions": [
                       {
                         "label": "var-lib-containers",
                         "sizeMiB": 0,
                         "startMiB": 250000
                       }
                     ],
                     "wipeTable": false
                   }
                 ],
                 "filesystems": [
                   {
                     "device": "/dev/disk/by-partlabel/var-lib-containers",
                     "format": "xfs",
                     "mountOptions": [
                       "defaults",
                       "prjquota"
                     ],
                     "path": "/var/lib/containers",
                     "wipeFilesystem": true
                   }
                 ]
               },
               "systemd": {
                 "units": [
                   {
                     "contents": "# # Generated by Butane\n[Unit]\nRequires=systemd-fsck@dev-disk-by\\x2dpartlabel-var\\x2dlib\\x2dcontainers.service\nAfter=systemd-fsck@dev-disk-by\\x2dpartlabel-var\\x2dlib\\x2dcontainers.service\n\n[Mount]\nWhere=/var/lib/containers\nWhat=/dev/disk/by-partlabel/var-lib-containers\nType=xfs\nOptions=defaults,prjquota\n\n[Install]\nRequiredBy=local-fs.target",
                     "enabled": true,
                     "name": "var-lib-containers.mount"
                   }
                 ]
               }
             }
   [...]

   참고

   .spec.clusters.nodes.ignitionConfigOverride 필드가 없는 경우 생성합니다.

검증

1. 설치 중 또는 설치 후 hub 클러스터에서 BareMetalHost 오브젝트가 다음 명령을 실행하여 주석을 표시하는지 확인합니다.

   $ oc get bmh -n my-sno-ns my-sno -ojson | jq '.metadata.annotations["bmac.agent-install.openshift.io/ignition-config-overrides"]

   출력 예

   "{\"ignition\":{\"version\":\"3.2.0\"},\"storage\":{\"disks\":[{\"device\":\"/dev/disk/by-id/wwn-0x6b07b250ebb9d0002a33509f24af1f62\",\"partitions\":[{\"label\":\"var-lib-containers\",\"sizeMiB\":0,\"startMiB\":250000}],\"wipeTable\":false}],\"filesystems\":[{\"device\":\"/dev/disk/by-partlabel/var-lib-containers\",\"format\":\"xfs\",\"mountOptions\":[\"defaults\",\"prjquota\"],\"path\":\"/var/lib/containers\",\"wipeFilesystem\":true}]},\"systemd\":{\"units\":[{\"contents\":\"# Generated by Butane\\n[Unit]\\nRequires=systemd-fsck@dev-disk-by\\\\x2dpartlabel-var\\\\x2dlib\\\\x2dcontainers.service\\nAfter=systemd-fsck@dev-disk-by\\\\x2dpartlabel-var\\\\x2dlib\\\\x2dcontainers.service\\n\\n[Mount]\\nWhere=/var/lib/containers\\nWhat=/dev/disk/by-partlabel/var-lib-containers\\nType=xfs\\nOptions=defaults,prjquota\\n\\n[Install]\\nRequiredBy=local-fs.target\",\"enabled\":true,\"name\":\"var-lib-containers.mount\"}]}}"

2. 설치 후 단일 노드 OpenShift 디스크 상태를 확인합니다.

   1. 다음 명령을 실행하여 단일 노드 OpenShift 노드에서 디버그 세션에 들어갑니다. 이 단계는 <node_name>-debug라는 디버그 Pod를 인스턴스화합니다.

      $ oc debug node/my-sno-node

   2. 다음 명령을 실행하여 디버그 쉘 내에서 /host 를 root 디렉터리로 설정합니다. 디버그 Pod는 Pod 내의 /host에 호스트의 루트 파일 시스템을 마운트합니다. root 디렉토리를 /host로 변경하면 호스트의 실행 경로에 포함된 바이너리를 실행할 수 있습니다.

      # chroot /host

   3. 다음 명령을 실행하여 사용 가능한 모든 블록 장치에 대한 정보를 나열합니다.

      # lsblk

      출력 예

      NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
      sda      8:0    0 446.6G  0 disk
      ├─sda1   8:1    0     1M  0 part
      ├─sda2   8:2    0   127M  0 part
      ├─sda3   8:3    0   384M  0 part /boot
      ├─sda4   8:4    0 243.6G  0 part /var
      │                                /sysroot/ostree/deploy/rhcos/var
      │                                /usr
      │                                /etc
      │                                /
      │                                /sysroot
      └─sda5   8:5    0 202.5G  0 part /var/lib/containers

   4. 다음 명령을 실행하여 파일 시스템 디스크 공간 사용량에 대한 정보를 표시합니다.

      # df -h

      출력 예

      Filesystem      Size  Used Avail Use% Mounted on
      devtmpfs        4.0M     0  4.0M   0% /dev
      tmpfs           126G   84K  126G   1% /dev/shm
      tmpfs            51G   93M   51G   1% /run
      /dev/sda4       244G  5.2G  239G   3% /sysroot
      tmpfs           126G  4.0K  126G   1% /tmp
      /dev/sda5       203G  119G   85G  59% /var/lib/containers
      /dev/sda3       350M  110M  218M  34% /boot
      tmpfs            26G     0   26G   0% /run/user/1000

프로세스

1. 적절한 PolicyGenerator CR에서 스토리지 클래스, 영구 볼륨 클레임, 영구 볼륨 및 이미지 레지스트리 구성을 구성합니다. 예를 들어 개별 사이트를 구성하려면 acm-example-sno-site.yaml 파일에 다음 YAML을 추가합니다.

   sourceFiles:
     # storage class
     - fileName: StorageClass.yaml
       policyName: "sc-for-image-registry"
       metadata:
         name: image-registry-sc
         annotations:
           ran.openshift.io/ztp-deploy-wave: "100" 1
     # persistent volume claim
     - fileName: StoragePVC.yaml
       policyName: "pvc-for-image-registry"
       metadata:
         name: image-registry-pvc
         namespace: openshift-image-registry
         annotations:
           ran.openshift.io/ztp-deploy-wave: "100"
       spec:
         accessModes:
           - ReadWriteMany
         resources:
           requests:
             storage: 100Gi
         storageClassName: image-registry-sc
         volumeMode: Filesystem
     # persistent volume
     - fileName: ImageRegistryPV.yaml 2
       policyName: "pv-for-image-registry"
       metadata:
         annotations:
           ran.openshift.io/ztp-deploy-wave: "100"
     - fileName: ImageRegistryConfig.yaml
       policyName: "config-for-image-registry"
       complianceType: musthave
       metadata:
         annotations:
           ran.openshift.io/ztp-deploy-wave: "100"
       spec:
         storage:
           pvc:
             claim: "image-registry-pvc"

   1

   사이트, 일반 또는 그룹 수준에서 이미지 레지스트리를 구성하는지 여부에 따라 ztp-deploy- ECDSA에 대한 적절한 값을 설정합니다. ztp-deploy-ECDHE: "100" 은 참조된 소스 파일을 함께 그룹화할 수 있으므로 개발 또는 테스트에 적합합니다.

   2

   ImageRegistryPV.yaml 에서는 SiteConfig CR의 mount_point 필드에 설정된 값과 일치하도록 spec.local.path 필드가 /var/imageregistry 로 설정되어 있는지 확인합니다.

   중요

   complianceType: mustonlyhave for the - fileName: ImageRegistryConfig.yaml 설정을 설정하지 마십시오. 이로 인해 레지스트리 Pod 배포가 실패할 수 있습니다.

2. Git에서 PolicyGenerator 변경 사항을 커밋한 다음 GitOps ZTP ArgoCD 애플리케이션에서 모니터링하는 Git 리포지토리로 내보냅니다.