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

18.8. vDU 애플리케이션 워크로드에 대한 단일 노드 OpenShift 클러스터 튜닝 검증

vDU(가상 분산 단위) 애플리케이션을 배포하려면 클러스터 호스트 펌웨어 및 기타 다양한 클러스터 구성 설정을 튜닝하고 구성해야 합니다. 다음 정보를 사용하여 vDU 워크로드를 지원하는 클러스터 구성을 검증합니다.

추가 리소스

18.8.1. vDU 클러스터 호스트의 권장 펌웨어 구성

다음 표를 기반으로 OpenShift Container Platform 4.14에서 실행되는 vDU 애플리케이션의 클러스터 호스트 펌웨어를 구성합니다.

참고

다음 표는 vDU 클러스터 호스트 펌웨어 구성에 대한 일반적인 권장 사항입니다. 정확한 펌웨어 설정은 요구 사항과 특정 하드웨어 플랫폼에 따라 달라집니다. 펌웨어의 자동 설정은 제로 터치 프로비저닝 파이프라인에 의해 처리되지 않습니다.

표 18.19. 권장되는 클러스터 호스트 펌웨어 설정
펌웨어 설정설정설명

HyperTransport (HT)

enabled

HT(HyperTransport) 버스는 AMD에서 개발한 버스 기술입니다. HT는 호스트 메모리의 구성 요소와 다른 시스템 주변 장치 간의 고속 링크를 제공합니다.

UEFI

enabled

vDU 호스트에 대해 UEFI에서 부팅을 활성화합니다.

CPU 전원 및 성능 정책

성능

CPU 전원 및 성능 정책을 설정하여 에너지 효율성에 대한 성능을 위해 시스템을 최적화합니다.

코어 빈도 확장 해제

비활성화됨

Uncore Frequency Scaling을 비활성화하여 CPU의 코어가 아닌 부분 및 빈도가 독립적으로 설정되지 않도록 합니다.

Uncore frequency

최대

캐시 및 메모리 컨트롤러와 같은 CPU의 코어가 아닌 부분을 최대 작업 빈도로 설정합니다.

성능 P-limit

비활성화됨

프로세서의 Uncore 빈도 조정을 방지하려면 성능 P 제한을 비활성화합니다.

향상된 Intel® SpeedStep Tech

enabled

향상된 Intel SpeedStep을 활성화하여 시스템의 프로세서 마운드 및 코어 빈도를 동적으로 조정하여 호스트의 전력 소비 및 열 생산량을 줄일 수 있습니다.

Intel® Cryostat Boost Technology

enabled

Intel 기반 CPU용 Cryostat Boost Technology를 사용하면 전력, 현재 및 온도 사양 제한 미만으로 작동하는 경우 프로세서 코어가 정격된 작동 빈도보다 빠르게 실행될 수 있습니다.

Intel Configurable TDP

enabled

CPU에 대해 TDP(rmal Design Power)를 활성화합니다.

구성 가능한 TDP 수준

수준 2

TDP 수준은 특정 성능 평가에 필요한 CPU 전력 소비를 설정합니다. TDP 수준 2는 전력 소비로 CPU를 가장 안정적인 성능 수준으로 설정합니다.

에너지 효율성:

비활성화됨

프로세서는 에너지 효율성 기반 정책을 사용하지 못하도록 energy Efficient Cryostat를 비활성화합니다.

하드웨어 P-States

활성화 또는 비활성화

OS가 제어하는 P-States를 활성화하여 전원 저장 구성을 허용합니다. P 상태(성능 상태 )를 비활성화하여 전력 소비에 따른 성능을 위해 운영 체제 및 CPU를 최적화합니다.

패키지 C-State

C0/C1 상태

C0 또는 C1 상태를 사용하여 프로세서를 완전히 활성 상태(C0)로 설정하거나 소프트웨어(C1)에서 실행되는 CPU 내부 시계를 중지합니다.

C1E

비활성화됨

CPU Enhanced Halt(C1E)는 Intel 칩의 전원 저장 기능입니다. C1E를 비활성화하면 비활성 상태에서 운영 체제가 CPU에 halt 명령을 보내지 않습니다.

프로세서 C6

비활성화됨

C6 전원은 유휴 CPU 코어 및 캐시를 자동으로 비활성화하는 CPU 기능입니다. C6을 비활성화하면 시스템 성능이 향상됩니다.

하위 NUMA

비활성화됨

하위 NUMA 클러스터링은 프로세서 코어, 캐시 및 메모리를 여러 NUMA 도메인으로 나눕니다. 이 옵션을 비활성화하면 대기 시간에 민감한 워크로드의 성능이 향상될 수 있습니다.

참고

호스트의 펌웨어에서 글로벌 SR-IOV 및 VT-d 설정을 활성화합니다. 이러한 설정은 베어 메탈 환경과 관련이 있습니다.

참고

C-states 및 OS가 제어하는 P-States 를 모두 활성화하여 Pod 전원 관리를 허용합니다.

18.8.2. vDU 애플리케이션을 실행하기 위한 권장 클러스터 구성

vDU(가상 분산 장치) 애플리케이션을 실행하는 클러스터에는 고도로 조정되고 최적화된 구성이 필요합니다. 다음 정보는 OpenShift Container Platform 4.14 클러스터에서 vDU 워크로드를 지원하는 데 필요한 다양한 요소를 설명합니다.

18.8.2.4. 실시간 커널 버전 확인

항상 OpenShift Container Platform 클러스터에서 최신 버전의 실시간 커널을 사용하십시오. 클러스터에서 사용 중인 커널 버전을 잘 모를 경우 현재 실시간 커널 버전을 릴리스 버전과 다음 절차와 비교할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.
  • podman 을 설치했습니다.

프로세스

  1. 다음 명령을 실행하여 클러스터 버전을 가져옵니다. 

    $ OCP_VERSION=$(oc get clusterversion version -o jsonpath='{.status.desired.version}{"\n"}')

  2. 릴리스 이미지 SHA 번호를 가져옵니다. 

    $ DTK_IMAGE=$(oc adm release info --image-for=driver-toolkit quay.io/openshift-release-dev/ocp-release:$OCP_VERSION-x86_64)

  3. 릴리스 이미지 컨테이너를 실행하고 클러스터의 현재 릴리스와 함께 패키지된 커널 버전을 추출합니다. 

    $ podman run --rm $DTK_IMAGE rpm -qa | grep 'kernel-rt-core-' | sed 's#kernel-rt-core-##'

    출력 예

    4.18.0-305.49.1.rt7.121.el8_4.x86_64

    이는 릴리스와 함께 제공되는 기본 실시간 커널 버전입니다.

    참고

    실시간 커널은 커널 버전의 .rt 문자열로 표시됩니다.

검증

클러스터의 현재 릴리스에 대해 나열된 커널 버전이 클러스터에서 실행 중인 실제 실시간 커널과 일치하는지 확인합니다. 다음 명령을 실행하여 실행 중인 실시간 커널 버전을 확인합니다.

  1. 클러스터 노드에 대한 원격 쉘 연결을 엽니다. 

    $ oc debug node/<node_name>

  2. 실시간 커널 버전을 확인합니다. 

    sh-4.4# uname -r

    출력 예

    4.18.0-305.49.1.rt7.121.el8_4.x86_64

18.8.3. 권장 클러스터 구성이 적용되었는지 확인

클러스터가 올바른 구성을 실행하고 있는지 확인할 수 있습니다. 다음 절차에서는 OpenShift Container Platform 4.14 클러스터에서 DU 애플리케이션을 배포하는 데 필요한 다양한 구성을 확인하는 방법을 설명합니다.

사전 요구 사항

  • 클러스터를 배포하고 vDU 워크로드에 맞게 조정했습니다.
  • OpenShift CLI(oc)가 설치되어 있습니다.
  • cluster-admin 권한이 있는 사용자로 로그인했습니다.

프로세스

  1. 기본 OperatorHub 소스가 비활성화되어 있는지 확인합니다. 다음 명령을 실행합니다. 

    $ oc get operatorhub cluster -o yaml

    출력 예

    spec:
    disableAllDefaultSources: true

  2. 다음 명령을 실행하여 모든 필요한 CatalogSource 리소스에 워크로드 파티셔닝(PreferredDuringScheduling)에 대한 주석이 있는지 확인합니다. 

    $ oc get catalogsource -A -o jsonpath='{range .items[*]}{.metadata.name}{" -- "}{.metadata.annotations.target\.workload\.openshift\.io/management}{"\n"}{end}'

    출력 예

    certified-operators -- {"effect": "PreferredDuringScheduling"}
community-operators -- {"effect": "PreferredDuringScheduling"}
ran-operators 1
redhat-marketplace -- {"effect": "PreferredDuringScheduling"}
redhat-operators -- {"effect": "PreferredDuringScheduling"}

    1
    주석이 없는 CatalogSource 리소스도 반환됩니다. 이 예에서 ran-operators CatalogSource 리소스에는 주석이 추가되지 않으며 PreferredDuringScheduling 주석이 없습니다.
    참고

    올바르게 구성된 vDU 클러스터에는 주석이 지정된 단일 카탈로그 소스만 나열됩니다.

  3. 워크로드 파티셔닝을 위해 해당하는 모든 OpenShift Container Platform Operator 네임스페이스에 주석이 추가되었는지 확인합니다. 여기에는 코어 OpenShift Container Platform과 함께 설치된 모든 Operator 및 참조 DU 튜닝 구성에 포함된 추가 Operator 세트가 포함됩니다. 다음 명령을 실행합니다. 

    $ oc get namespaces -A -o jsonpath='{range .items[*]}{.metadata.name}{" -- "}{.metadata.annotations.workload\.openshift\.io/allowed}{"\n"}{end}'

    출력 예

    default --
openshift-apiserver -- management
openshift-apiserver-operator -- management
openshift-authentication -- management
openshift-authentication-operator -- management

    중요

    추가 Operator는 워크로드 파티셔닝을 위해 주석을 달 수 없습니다. 이전 명령의 출력에서 -- separator 오른쪽에 값을 지정하지 않고 추가 Operator를 나열해야 합니다.

  4. ClusterLogging 구성이 올바른지 확인합니다. 다음 명령을 실행합니다.

    1. 적절한 입력 및 출력 로그가 구성되어 있는지 확인합니다. 

      $ oc get -n openshift-logging ClusterLogForwarder instance -o yaml

      출력 예

      apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  creationTimestamp: "2022-07-19T21:51:41Z"
  generation: 1
  name: instance
  namespace: openshift-logging
  resourceVersion: "1030342"
  uid: 8c1a842d-80c5-447a-9150-40350bdf40f0
spec:
  inputs:
  - infrastructure: {}
    name: infra-logs
  outputs:
  - name: kafka-open
    type: kafka
    url: tcp://10.46.55.190:9092/test
  pipelines:
  - inputRefs:
    - audit
    name: audit-logs
    outputRefs:
    - kafka-open
  - inputRefs:
    - infrastructure
    name: infrastructure-logs
    outputRefs:
    - kafka-open
...

    2. 큐레이션 일정이 애플리케이션에 적합한지 확인합니다. 

      $ oc get -n openshift-logging clusterloggings.logging.openshift.io instance -o yaml

      출력 예

      apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
  creationTimestamp: "2022-07-07T18:22:56Z"
  generation: 1
  name: instance
  namespace: openshift-logging
  resourceVersion: "235796"
  uid: ef67b9b8-0e65-4a10-88ff-ec06922ea796
spec:
  collection:
    logs:
      fluentd: {}
      type: fluentd
  curation:
    curator:
      schedule: 30 3 * * *
    type: curator
  managementState: Managed
...

  5. 다음 명령을 실행하여 웹 콘솔이 비활성화(managementState: Removed)인지 확인합니다. 

    $ oc get consoles.operator.openshift.io cluster -o jsonpath="{ .spec.managementState }"

    출력 예

    Removed

  6. 다음 명령을 실행하여 클러스터 노드에서 chronyd 가 비활성화되어 있는지 확인합니다. 

    $ oc debug node/<node_name>

    노드에서 chronyd 의 상태를 확인합니다. 

    sh-4.4# chroot /host
    sh-4.4# systemctl status chronyd

    출력 예

    ● chronyd.service - NTP client/server
    Loaded: loaded (/usr/lib/systemd/system/chronyd.service; disabled; vendor preset: enabled)
    Active: inactive (dead)
      Docs: man:chronyd(8)
            man:chrony.conf(5)

  7. linuxptp-daemon 컨테이너 및 PTP 관리 클라이언트(pmc) 툴에 대한 원격 쉘 연결을 사용하여 PTP 인터페이스가 기본 클록에 성공적으로 동기화되었는지 확인합니다.

    1. 다음 명령을 실행하여 linuxptp-daemon Pod의 이름으로 $PTP_POD_NAME 변수를 설정합니다. 

      $ PTP_POD_NAME=$(oc get pods -n openshift-ptp -l app=linuxptp-daemon -o name)

    2. 다음 명령을 실행하여 PTP 장치의 동기화 상태를 확인합니다. 

      $ oc -n openshift-ptp rsh -c linuxptp-daemon-container ${PTP_POD_NAME} pmc -u -f /var/run/ptp4l.0.config -b 0 'GET PORT_DATA_SET'

      출력 예

      sending: GET PORT_DATA_SET
  3cecef.fffe.7a7020-1 seq 0 RESPONSE MANAGEMENT PORT_DATA_SET
    portIdentity            3cecef.fffe.7a7020-1
    portState               SLAVE
    logMinDelayReqInterval  -4
    peerMeanPathDelay       0
    logAnnounceInterval     1
    announceReceiptTimeout  3
    logSyncInterval         0
    delayMechanism          1
    logMinPdelayReqInterval 0
    versionNumber           2
  3cecef.fffe.7a7020-2 seq 0 RESPONSE MANAGEMENT PORT_DATA_SET
    portIdentity            3cecef.fffe.7a7020-2
    portState               LISTENING
    logMinDelayReqInterval  0
    peerMeanPathDelay       0
    logAnnounceInterval     1
    announceReceiptTimeout  3
    logSyncInterval         0
    delayMechanism          1
    logMinPdelayReqInterval 0
    versionNumber           2

    3. 다음 pmc 명령을 실행하여 PTP 클럭 상태를 확인합니다. 

      $ oc -n openshift-ptp rsh -c linuxptp-daemon-container ${PTP_POD_NAME} pmc -u -f /var/run/ptp4l.0.config -b 0 'GET TIME_STATUS_NP'

      출력 예

      sending: GET TIME_STATUS_NP
  3cecef.fffe.7a7020-0 seq 0 RESPONSE MANAGEMENT TIME_STATUS_NP
    master_offset              10 1
    ingress_time               1657275432697400530
    cumulativeScaledRateOffset +0.000000000
    scaledLastGmPhaseChange    0
    gmTimeBaseIndicator        0
    lastGmPhaseChange          0x0000'0000000000000000.0000
    gmPresent                  true 2
    gmIdentity                 3c2c30.ffff.670e00

      1
      master_offset 은 -100과 100 ns 사이여야 합니다.
      2
      PTP 시계가 마스터에 동기화되고 로컬 클록이 마스터 클록이 아님을 나타냅니다.

    4. /var/run/ptp4l.0.config 의 값에 해당하는 예상 마스터 오프셋 값이 linuxptp-daemon-container 로그에 있는지 확인합니다. 

      $ oc logs $PTP_POD_NAME -n openshift-ptp -c linuxptp-daemon-container

      출력 예

      phc2sys[56020.341]: [ptp4l.1.config] CLOCK_REALTIME phc offset  -1731092 s2 freq -1546242 delay    497
ptp4l[56020.390]: [ptp4l.1.config] master offset         -2 s2 freq   -5863 path delay       541
ptp4l[56020.390]: [ptp4l.0.config] master offset         -8 s2 freq  -10699 path delay       533

  8. 다음 명령을 실행하여 SR-IOV 구성이 올바른지 확인합니다.

    1. SriovOperatorConfig 리소스의 disableDrain 값이 true 로 설정되어 있는지 확인합니다. 

      $ oc get sriovoperatorconfig -n openshift-sriov-network-operator default -o jsonpath="{.spec.disableDrain}{'\n'}"

      출력 예

      true

    2. 다음 명령을 실행하여 SriovNetworkNodeState 동기화 상태가 Succeeded 인지 확인합니다. 

      $ oc get SriovNetworkNodeStates -n openshift-sriov-network-operator -o jsonpath="{.items[*].status.syncStatus}{'\n'}"

      출력 예

      Succeeded

    3. SR-IOV용으로 구성된 각 인터페이스에서Vfs(가상 기능)의 예상 수와 구성이 있고 .status.interfaces 필드에 올바른지 확인합니다. 예를 들면 다음과 같습니다. 

      $ oc get SriovNetworkNodeStates -n openshift-sriov-network-operator -o yaml

      출력 예

      apiVersion: v1
items:
- apiVersion: sriovnetwork.openshift.io/v1
  kind: SriovNetworkNodeState
...
  status:
    interfaces:
    ...
    - Vfs:
      - deviceID: 154c
        driver: vfio-pci
        pciAddress: 0000:3b:0a.0
        vendor: "8086"
        vfID: 0
      - deviceID: 154c
        driver: vfio-pci
        pciAddress: 0000:3b:0a.1
        vendor: "8086"
        vfID: 1
      - deviceID: 154c
        driver: vfio-pci
        pciAddress: 0000:3b:0a.2
        vendor: "8086"
        vfID: 2
      - deviceID: 154c
        driver: vfio-pci
        pciAddress: 0000:3b:0a.3
        vendor: "8086"
        vfID: 3
      - deviceID: 154c
        driver: vfio-pci
        pciAddress: 0000:3b:0a.4
        vendor: "8086"
        vfID: 4
      - deviceID: 154c
        driver: vfio-pci
        pciAddress: 0000:3b:0a.5
        vendor: "8086"
        vfID: 5
      - deviceID: 154c
        driver: vfio-pci
        pciAddress: 0000:3b:0a.6
        vendor: "8086"
        vfID: 6
      - deviceID: 154c
        driver: vfio-pci
        pciAddress: 0000:3b:0a.7
        vendor: "8086"
        vfID: 7

  9. 클러스터 성능 프로필이 올바른지 확인합니다. cpu 및 hugepages 섹션은 하드웨어 구성에 따라 다릅니다. 다음 명령을 실행합니다. 

    $ oc get PerformanceProfile openshift-node-performance-profile -o yaml

    출력 예

    apiVersion: performance.openshift.io/v2
kind: PerformanceProfile
metadata:
  creationTimestamp: "2022-07-19T21:51:31Z"
  finalizers:
  - foreground-deletion
  generation: 1
  name: openshift-node-performance-profile
  resourceVersion: "33558"
  uid: 217958c0-9122-4c62-9d4d-fdc27c31118c
spec:
  additionalKernelArgs:
  - idle=poll
  - rcupdate.rcu_normal_after_boot=0
  - efi=runtime
  cpu:
    isolated: 2-51,54-103
    reserved: 0-1,52-53
  hugepages:
    defaultHugepagesSize: 1G
    pages:
    - count: 32
      size: 1G
  machineConfigPoolSelector:
    pools.operator.machineconfiguration.openshift.io/master: ""
  net:
    userLevelNetworking: true
  nodeSelector:
    node-role.kubernetes.io/master: ""
  numa:
    topologyPolicy: restricted
  realTimeKernel:
    enabled: true
status:
  conditions:
  - lastHeartbeatTime: "2022-07-19T21:51:31Z"
    lastTransitionTime: "2022-07-19T21:51:31Z"
    status: "True"
    type: Available
  - lastHeartbeatTime: "2022-07-19T21:51:31Z"
    lastTransitionTime: "2022-07-19T21:51:31Z"
    status: "True"
    type: Upgradeable
  - lastHeartbeatTime: "2022-07-19T21:51:31Z"
    lastTransitionTime: "2022-07-19T21:51:31Z"
    status: "False"
    type: Progressing
  - lastHeartbeatTime: "2022-07-19T21:51:31Z"
    lastTransitionTime: "2022-07-19T21:51:31Z"
    status: "False"
    type: Degraded
  runtimeClass: performance-openshift-node-performance-profile
  tuned: openshift-cluster-node-tuning-operator/openshift-node-performance-openshift-node-performance-profile

    참고

    CPU 설정은 서버에서 사용 가능한 코어 수에 따라 다르며 워크로드 파티셔닝 설정과 일치해야 합니다. hugepages 구성은 서버와 애플리케이션에 따라 다릅니다.

  10. 다음 명령을 실행하여 PerformanceProfile 이 클러스터에 성공적으로 적용되었는지 확인합니다. 

    $ oc get performanceprofile openshift-node-performance-profile -o jsonpath="{range .status.conditions[*]}{ @.type }{' -- '}{@.status}{'\n'}{end}"

    출력 예

    Available -- True
Upgradeable -- True
Progressing -- False
Degraded -- False

  11. 다음 명령을 실행하여 Tuned 성능 패치 설정을 확인합니다. 

    $ oc get tuneds.tuned.openshift.io -n openshift-cluster-node-tuning-operator performance-patch -o yaml

    출력 예

    apiVersion: tuned.openshift.io/v1
kind: Tuned
metadata:
  creationTimestamp: "2022-07-18T10:33:52Z"
  generation: 1
  name: performance-patch
  namespace: openshift-cluster-node-tuning-operator
  resourceVersion: "34024"
  uid: f9799811-f744-4179-bf00-32d4436c08fd
spec:
  profile:
  - data: |
      [main]
      summary=Configuration changes profile inherited from performance created tuned
      include=openshift-node-performance-openshift-node-performance-profile
      [bootloader]
      cmdline_crash=nohz_full=2-23,26-47 1
      [sysctl]
      kernel.timer_migration=1
      [scheduler]
      group.ice-ptp=0:f:10:*:ice-ptp.*
      [service]
      service.stalld=start,enable
      service.chronyd=stop,disable
    name: performance-patch
  recommend:
  - machineConfigLabels:
      machineconfiguration.openshift.io/role: master
    priority: 19
    profile: performance-patch

    1
    cmdline=nohz_full= 의 cpu 목록은 하드웨어 구성에 따라 다릅니다.

  12. 다음 명령을 실행하여 클러스터 네트워킹 진단이 비활성화되었는지 확인합니다. 

    $ oc get networks.operator.openshift.io cluster -o jsonpath='{.spec.disableNetworkDiagnostics}'

    출력 예

    true

  13. Kubelet 하우스키핑 간격이 느린 속도로 조정되었는지 확인합니다. 이는 containerMountNS 머신 구성에 설정됩니다. 다음 명령을 실행합니다. 

    $ oc describe machineconfig container-mount-namespace-and-kubelet-conf-master | grep OPENSHIFT_MAX_HOUSEKEEPING_INTERVAL_DURATION

    출력 예

    Environment="OPENSHIFT_MAX_HOUSEKEEPING_INTERVAL_DURATION=60s"

  14. 다음 명령을 실행하여 Grafana 및 alertManagerMain 이 비활성화되어 Prometheus 보존 기간이 24h로 설정되어 있는지 확인합니다. 

    $ oc get configmap cluster-monitoring-config -n openshift-monitoring -o jsonpath="{ .data.config\.yaml }"

    출력 예

    grafana:
  enabled: false
alertmanagerMain:
  enabled: false
prometheusK8s:
   retention: 24h

    1. 다음 명령을 사용하여 Grafana 및 alertManagerMain 경로가 클러스터에 없는지 확인합니다. 

      $ oc get route -n openshift-monitoring alertmanager-main
      $ oc get route -n openshift-monitoring grafana

      두 쿼리 모두 서버 오류(NotFound) 메시지를 반환해야 합니다.

  15. 다음 명령을 실행하여 PerformanceProfile,Tuned performance-patch, 워크로드 파티셔닝 및 커널 명령줄 인수에 대해 예약된 CPU가 최소 4개 이상 있는지 확인합니다. 

    $ oc get performanceprofile -o jsonpath="{ .items[0].spec.cpu.reserved }"

    출력 예

    0-3

    참고

    워크로드 요구 사항에 따라 추가 예약된 CPU를 할당해야 할 수 있습니다.

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

© 2024 Red Hat, Inc.