5.14. Node Tuning Operator 사용
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 설치에 포함되어 있습니다.
5.14.1. Node Tuning Operator 사양 예에 액세스
이 프로세스를 사용하여 Node Tuning Operator 사양 예에 액세스하십시오.
프로세스
다음을 실행합니다.
$ 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의 향후 버전에서 더 이상 사용되지 않을 수 있습니다.
5.14.2. 사용자 정의 튜닝 사양
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 operand: 7 debug: <bool> 8
- 1
- 선택 사항입니다.
- 2
- 키/값
MachineConfig
라벨 사전입니다. 키는 고유해야 합니다. - 3
- 생략하면 우선 순위가 높은 프로필이 먼저 일치되거나
machineConfigLabels
가 설정되어 있지 않으면 프로필이 일치하는 것으로 가정합니다. - 4
- 선택사항 목록입니다.
- 5
- 프로필 순서 지정 우선 순위입니다. 숫자가 작을수록 우선 순위가 높습니다(
0
이 가장 높은 우선 순위임). - 6
- 일치에 적용할 TuneD 프로필입니다. 예를 들어
tuned_profile_1
이 있습니다. - 7
- 선택적 피연산자 구성입니다.
- 8
- TuneD 데몬의 디버깅을 켜거나 끕니다. off의 경우 on 또는
false
의 경우 옵션이true
입니다. 기본값은false
입니다.
<match>
는 다음과 같이 재귀적으로 정의되는 선택사항 목록입니다.
- label: <label_name> 1 value: <label_value> 2 type: <label_type> 3 <match> 4
<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을 생성하고 마지막으로 사용자 정의 머신 구성 풀을 생성합니다.
5.14.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
5.14.4. 지원되는 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 시작하기 를 참조하십시오.