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

대규모 배포 권장 사항

Red Hat OpenStack Platform 16.1

규모에 따라 Red Hat OpenStack Platform을 배포하기 위한 하드웨어 요구 사항 및 구성

초록

이 가이드에는 규모에 맞게 Red Hat OpenStack Platform 배포에 대한 몇 가지 권장 사항이 포함되어 있습니다. 이러한 권장 사항에는 하드웨어 권장 사항, 언더클라우드 튜닝 및 오버클라우드 구성이 포함됩니다.

preface
링크 복사

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

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 용어를 교체하기 위해 최선을 다하고 있습니다. 먼저 마스터(master), 슬레이브(slave), 블랙리스트(blacklist), 화이트리스트(whitelist) 등 네 가지 용어를 교체하고 있습니다. 이러한 변경 작업은 작업 범위가 크므로 향후 여러 릴리스에 걸쳐 점차 구현할 예정입니다. 자세한 내용은 CTO Chris Wright의 메시지를 참조하십시오.

Red Hat 문서에 관한 피드백 제공
링크 복사

문서 개선을 위한 의견을 보내 주십시오. Red Hat이 어떻게 이를 개선하는지 알려주십시오.

DDF(직접 문서 피드백) 기능 사용

특정 문장, 단락 또는 코드 블록에 대한 직접 주석은 피드백 추가 DDF 기능을 사용하십시오.

  1. 다중 페이지 HTML 형식으로 설명서를 봅니다.
  2. 문서 오른쪽 상단에 Feedback (피드백) 버튼이 표시되는지 확인합니다.
  3. 주석 처리하려는 텍스트 부분을 강조 표시합니다.
  4. 피드백 추가를 클릭합니다.
  5. 주석을 사용하여 Add Feedback (피드백 추가) 필드를 작성합니다.
  6. 선택 사항: 설명서 팀이 문제에 대한 자세한 내용을 문의할 수 있도록 이메일 주소를 추가하십시오.
  7. Submit(제출)을 클릭합니다.

1장. 대규모 배포 권장 사항
링크 복사

대규모 RHOSP(Red Hat OpenStack Platform) 환경을 배포하려면 다음 언더클라우드 및 오버클라우드 권장 사항, 사양 및 구성을 사용하십시오. 100개가 넘는 Overcloud 노드를 포함하는 RHOSP 16.1 배포는 대규모 환경으로 간주됩니다. Red Hat은 minion을 사용하지 않고 RHOSP 16.1을 사용하여 700개의 오버클라우드 노드의 대규모 환경에서 최적의 성능을 테스트 및 검증했습니다.

DCN 기반 배포의 경우 중앙 및 에지 사이트의 노드 수가 매우 높을 수 있습니다. DCN 배포에 대한 권장 사항은 Red Hat 글로벌 지원 서비스에 문의하십시오.

3장. Red Hat OpenStack 배포 모범 사례
링크 복사

OpenStack 배포를 계획하고 준비할 때 다음 모범 사례를 검토합니다. 이러한 사례를 사용자 환경에 하나 이상 적용할 수 있습니다.

3.1. Red Hat OpenStack 배포 준비
링크 복사

RHOSP(Red Hat OpenStack Platform)를 배포하기 전에 다음 배포 준비 작업 목록을 검토하십시오. 사용자 환경에서 하나 이상의 배포 준비 작업을 적용할 수 있습니다.

한 번에 인트로스펙션을 수행할 최대 오버클라우드 노드를 수용하도록 인트로스펙션의 서브넷 범위를 설정합니다.
director를 사용하여 RHOSP를 배포하고 구성하는 경우 컨트롤 플레인 네트워크에 CIDR 표기법을 사용하여 현재 또는 향후에 추가하는 모든 오버클라우드 노드를 수용합니다.
오버클라우드 이미지에 대한 콘솔 액세스를 허용하도록 오버클라우드 이미지에 root 암호를 설정합니다.

네트워킹이 잘못 설정될 때 콘솔을 사용하여 실패한 배포 문제를 해결합니다. 자세한 내용은 Installing virt-customize to the director 및 Setting the Root Password in the Partner Integration Guide 를 참조하십시오. 이 권장 사항을 구현할 때 암호 관리를 위해 조직의 정보 보안 정책을 준수하십시오.

또는 userdata_root_password.yaml 템플릿을 사용하여 NodeUserData 매개 변수를 사용하여 루트 암호를 구성할 수 있습니다. /usr/share/openstack-tripleo-heat-templates/firstboot/userdata_root_password.yaml 에서 템플릿을 찾을 수 있습니다.

다음 예제에서는 템플릿을 사용하여 NodeUserData 매개변수를 구성합니다. 

resource_registry:
  OS::TripleO::NodeUserData: /usr/share/openstack-tripleo-heat-templates/firstboot/userdata_root_password.yaml
parameter_defaults:
  NodeRootPassword: '<password>'
Copy to Clipboard Toggle word wrap
스케줄러 힌트를 사용하여 역할에 하드웨어 할당
  • 스케줄러 힌트를 사용하여 컨트롤러,계산,CephStorage 등과 같은 역할에 하드웨어를 할당합니다. 스케줄러 힌트를 사용하면 특정 하드웨어에만 영향을 주는 배포 문제를 보다 쉽게 파악할 수 있습니다.
  • 단일 프로세스인 nova-scheduler 는 많은 수의 노드를 예약할 때 오버아웃할 수 있습니다. 스케줄러 힌트는 스케줄러 힌트에서 태그 일치를 구현할 때 nova-scheduler 에 대한 부하를 줄입니다. 결과적으로 nova-scheduler 가 배포 중에 스케줄링 오류가 줄어듭니다. 따라서 스케줄러 힌트를 사용하는 경우 배포 시간이 단축됩니다.
  • 스케줄러 힌트를 사용할 때 프로필 태그 지정을 사용하지 마십시오.
  • 성능 테스트에서는 특정 역할에 대해 동일한 하드웨어를 사용하여 테스트 및 성능 결과의 변동성을 줄입니다.
  • 자세한 내용은 Advanced Overcloud Customization 가이드의 특정 노드 ID 할당 을 참조하십시오.
배포 및 부팅 중에 노드가 잘못된 디스크를 사용하지 못하도록 각 노드의 루트 디스크 힌트로 WWN(World Wide Name)을 설정합니다.
노드에 여러 디스크가 포함된 경우 인트로스펙션 데이터를 사용하여 WWN을 각 노드의 루트 디스크 힌트로 설정합니다. 이렇게 하면 배포 및 부팅 중에 노드가 잘못된 디스크를 사용하지 못합니다. 자세한 내용은 Director 설치 및 사용 가이드 의 다중 디스크 클러스터의 루트 디스크 정의에서 참조하십시오.
디스크가 두 개 이상인 노드에서 베어 메탈 서비스(ironic) 자동 정리 활성화

베어 메탈 서비스 자동 정리를 사용하여 디스크가 여러 개 있고 여러 부트 로더가 있는 노드에서 메타데이터를 제거합니다. 디스크에 여러 부트로더가 있기 때문에 노드가 부팅 디스크와 일치하지 않을 수 있으므로 잘못된 URL을 사용하는 메타데이터를 가져오려고 할 때 노드 배포 오류가 발생할 수 있습니다.

베어 메탈 서비스 자동 정리를 활성화하려면 언더클라우드 노드에서 undercloud.conf 파일을 편집하고 다음 행을 추가합니다. 

clean_nodes = true
Copy to Clipboard Toggle word wrap
베어 메탈(ironic) 인트로스펙션의 노드 수를 제한합니다.

모든 노드에서 동시에 인트로스펙션을 수행하는 경우 네트워크 제약 조건으로 인해 오류가 발생할 수 있습니다. 한 번에 최대 50개의 노드에서 세부 검사를 수행합니다.

undercloud.conf 파일의 dhcp_start 및 dhcp_end 범위가 환경에 있어야 하는 노드 수에 충분히 큰지 확인합니다.

사용 가능한 IP가 충분하지 않으면 범위 크기보다 크게 발행하지 마십시오. 이렇게 하면 동시에 인트로스펙션 작업 수가 제한됩니다. 인트로스펙션 DHCP 리스가 만료되도록 하려면 인트로스펙션이 완료된 후 몇 분 동안 더 많은 IP 주소를 발행하지 마십시오.

다른 유형의 구성을 위해 Ceph 준비

다음 목록은 다양한 유형의 구성에 대한 권장 사항 집합입니다.

  • all-flash OSD 구성

    각 OSD에는 장치 유형의 IOPS 용량에 따라 추가 CPU가 필요하므로 Ceph IOPS는 더 적은 수의 OSD로 제한됩니다. 이는 기존 HDD보다 2배 더 높은 IOPS 용량을 보유할 수 있는 NVM SSD의 경우 그렇습니다. SATA/SAS SSD의 경우 HDD보다 1배 더 큰 임의 IOPS/OSD를 예상하지만 순차적 IOPS 증가의 약 2-4배에 불과합니다. Ceph에 OSD 장치에 필요한 CPU 리소스를 더 적게 제공할 수 있습니다.

  • HCI(Hyper Converged Infrastructure)

    OpenStack Compute(nova) 게스트에 대해 절반 이상의 CPU 용량, 메모리 및 네트워크를 예약하는 것이 좋습니다. OpenStack Compute(nova) 게스트 및 Ceph Storage를 모두 지원하는 데 충분한 CPU 용량과 메모리가 있는지 확인합니다. Ceph Storage 메모리 사용량이 탄력적이지 않기 때문에 메모리 사용량을 관찰합니다. 멀티 CPU 소켓 시스템에서 NUMA 고정 Ceph를 사용하여 Ceph CPU 사용을 단일 소켓으로 제한합니다. 예를 들어 numactl -N 0 -p 0 명령을 사용합니다. 1소켓에 대한 Ceph 메모리 소비를 하드 고정하지 마십시오.

  • 대기 시간에 민감한 애플리케이션(예: NFV)

    Ceph를 Ceph가 사용하는 네트워크 카드와 동일한 CPU 소켓에 배치하고 다른 NUMA 소켓 및 네트워크 카드에서 실행되는 네트워크 애플리케이션을 사용하여 가능한 경우 해당 CPU 소켓으로 네트워크 카드가 중단되는 것을 제한합니다.

    듀얼 부트 로더를 사용하는 경우 OSD 맵에 disk-by-path를 사용합니다. 이렇게 하면 장치 이름을 사용하는 것과 달리 사용자에게 일관된 배포가 가능합니다. 다음 코드 조각은 disk-by-path 매핑에 대한 CephAnsibleDisksConfig 의 예입니다. 

    CephAnsibleDisksConfig:
  osd_scenario: non-collocated
  devices:
    - /dev/disk/by-path/pci-0000:03:00.0-scsi-0:2:0:0
    - /dev/disk/by-path/pci-0000:03:00.0-scsi-0:2:1:0
  dedicated_devices:
    - /dev/nvme0n1
    - /dev/nvme0n1
  journal_size: 512
    Copy to Clipboard Toggle word wrap

3.2. Red Hat OpenStack 배포 구성
링크 복사

RHOSP(Red Hat OpenStack Platform) 배포 구성에 대한 다음 권장 사항을 검토합니다.

소규모 배포로 heat 템플릿 검증
컨트롤러 3개 이상, 계산 노트 1개, Ceph Storage 노드 3개로 구성된 소규모 환경을 배포합니다. 이 구성을 사용하여 모든 heat 템플릿이 올바른지 확인할 수 있습니다.
언더클라우드에서 원격 분석 알림 비활성화

다음 OpenStack 서비스에 대해 언더클라우드에서 원격 분석 알림을 비활성화하여 RabbitMQ 대기열을 줄일 수 있습니다.

  • 컴퓨팅(nova)
  • 네트워킹(neutron)
  • 오케스트레이션(heat)
  • ID(keystone)

알림을 비활성화하려면 /usr/share/openstack-tripleo-heat-templates/environments/disable-telemetry.yaml 템플릿에서 알림 드라이버 설정을 noop 로 설정합니다.

동시에 프로비저닝되는 노드 수 제한

50만 개는 평균 엔터프라이즈급 랙 유닛에 적합할 수 있는 일반적인 서버 양이므로 한 번에 평균 하나의 랙 노드를 배포할 수 있습니다.

배포 문제를 진단하는 데 필요한 디버깅을 최소화하려면 한 번에 50개 이상의 노드를 배포합니다. 그러나 더 많은 수의 노드를 배포하려는 경우 Red Hat은 최대 100개의 노드를 동시에 성공적으로 테스트했습니다.

컴퓨팅 노드를 일괄적으로 확장하려면 --limit 옵션과 함께 openstack overcloud deploy 명령을 사용합니다. 이로 인해 언더클라우드에서 시간을 절약하고 리소스 사용량을 줄일 수 있습니다.

참고

--limit 옵션은 기술 프리뷰에 있습니다.

이 옵션을 config-download 플레이북의 쉼표로 구분된 태그 목록과 함께 사용하여 특정 config-download 작업 세트로 배포를 실행합니다.

사용하지 않는 NIC 비활성화

배포 중에 오버클라우드에 사용되지 않는 NIC가 있는 경우 NIC 구성 템플릿에서 사용되지 않은 인터페이스를 정의하고 인터페이스를 use_dhcp: false 및 defroute: false 로 설정해야 합니다.

사용하지 않는 인터페이스를 정의하지 않으면 인트로스펙션 및 확장 작업 중에 라우팅 문제 및 IP 할당 문제가 있을 수 있습니다. 기본적으로 NIC는 BOOTPROTO=dhcp 를 설정하므로 사용되지 않는 Overcloud NIC에서 PXE 배포에 필요한 IP 주소를 사용합니다. 이렇게 하면 노드에 사용 가능한 IP 주소 풀이 줄어들 수 있습니다.

사용하지 않은 베어 메탈 프로비저닝(ironic) 노드의 전원을 끕니다.
유지 관리 모드에서 사용되지 않는 베어 메탈 프로비저닝(ironic) 노드의 전원을 끕니다. Red Hat은 이전 배포의 노드가 전원이 켜진 상태에서 유지 관리 모드로 남아 있는 경우를 확인했습니다. 이는 정리에 실패한 노드가 유지 관리 모드로 설정된 베어 메탈 자동 정리에서 발생할 수 있습니다. 베어 메탈 프로비저닝은 유지보수 모드에서 노드의 전원 상태를 추적하지 않고 전원 상태를 off로 잘못 보고합니다. 이로 인해 지속적인 배포 시 문제가 발생할 수 있습니다. 배포 실패 후 재배포하는 경우 노드의 전원 관리 장치를 사용하는 사용되지 않은 모든 노드의 전원을 끕니다.

3.3. 언더클라우드 튜닝
링크 복사

RHOSP 배포를 확장하고 기본 언더클라우드 설정에 튜닝을 적용하려는 경우 이 섹션을 검토합니다.

Telemetry 서비스(ceilometer)를 사용하는 경우 서비스의 성능을 개선합니다.

원격 분석 서비스는 CPU를 많이 사용하므로 RHOSP 16.1에서는 기본적으로 Telemetry 서비스가 활성화되지 않습니다. Telemetry를 사용하려면 서비스의 성능을 향상시킬 수 있습니다.

자세한 내용은 특정 Red Hat OpenStack Platform Services 가이드의 배포 권장 사항의 Telemetry 서비스에 대한 구성 권장 사항을 참조하십시오.

프로비저닝 및 구성 프로세스 분리
  • 스택 및 관련 RHOSP 리소스만 생성하려면 --stack-only 옵션을 사용하여 배포 명령을 실행할 수 있습니다.
  • 100개 이상의 노드를 배포할 때 스택과 config-download 단계를 분리하는 것이 좋습니다.

오버클라우드에 필요한 환경 파일을 포함합니다. 

$ openstack overcloud deploy \
  --templates \
  -e <environment-file1.yaml> \
  -e <environment-file2.yaml> \
  ...
  --stack-only
Copy to Clipboard Toggle word wrap

  • 스택을 프로비저닝한 후에는 언더클라우드에서 오버클라우드로 tripleo-admin 사용자의 SSH 액세스를 활성화할 수 있습니다. config-download 프로세스는 tripleo-admin 사용자를 사용하여 Ansible 기반 구성을 수행합니다. 

    $ openstack overcloud admin authorize
    Copy to Clipboard Toggle word wrap

  • 오버클라우드 스택 생성을 비활성화하고 config-download 워크플로우만 실행하여 소프트웨어 구성을 적용하려면 --config-download-only 옵션을 사용하여 배포 명령을 실행할 수 있습니다. 오버클라우드에 필요한 환경 파일을 포함합니다. 

    $ openstack overcloud deploy \
 --templates \
 -e <environment-file1.yaml> \
 -e <environment-file2.yaml> \
  ...
 --config-download-only
    Copy to Clipboard Toggle word wrap
  • config-download 플레이북 실행을 특정 노드 또는 노드 세트로 제한하려면 --limit 옵션을 사용할 수 있습니다.

  • --limit 옵션을 사용하면 노드를 다른 역할로 분리하고 배포할 노드 수를 제한하거나 특정 하드웨어 유형으로 노드를 분리할 수 있습니다. 확장 작업의 경우 새 노드에만 소프트웨어 구성을 적용하려면 --limit 옵션을 --config-download-only 옵션과 함께 사용합니다. 

    $ openstack overcloud deploy \
--templates \
-e <environment-file1.yaml> \
-e <environment-file2.yaml> \
...
--config-download-only --config-download-timeout --limit <Undercloud>,<Controller>,<Compute-1>,<Compute-2>
    Copy to Clipboard Toggle word wrap

3.4. 오버클라우드 튜닝
링크 복사

RHOSP(Red Hat OpenStack Platform) 배포를 확장하고 기본 오버클라우드 설정에 튜닝을 적용하려는 경우 다음 섹션을 검토합니다.

장애 조치(failover)를 방지하기 위해 OVN OVSDB 클라이언트 프로브 간격을 늘립니다.

대규모 RHOSP 배포를 위한 OVSDB 클라이언트 프로브 간격을 늘립니다. Pacemaker는 구성된 타임아웃 내에서 OVN에서 응답을 받지 못하면 ovn-dbs-bundle 의 장애 조치를 트리거합니다. OVN OVSDB 클라이언트 프로브 간격을 360초로 늘리려면 heat 템플릿에서 OVNDBSPacemakerTimeout 매개변수를 편집합니다. 

OVNDBSPacemakerTimeout: 360
Copy to Clipboard Toggle word wrap

각 컴퓨팅 및 컨트롤러 노드에서 OVN 컨트롤러는 OVN SBDB를 정기적으로 검색하고 이러한 요청 시간 초과가 발생하면 OVN 컨트롤러가 다시 동기화됩니다. 리소스를 생성하기 위한 요청과 함께 여러 컴퓨팅 및 컨트롤러 노드가 로드되면 기본 60초 제한 값만으로는 충분하지 않습니다. OVN SBDB 클라이언트 프로브 간격을 180초로 늘리려면 heat 템플릿에서 OVNOpenflowProbeInterval 매개변수를 편집합니다. 

ControllerParameters:
  OVNRemoteProbeInterval: 180000
  OVNOpenflowProbeInterval: 180
Copy to Clipboard Toggle word wrap
참고

RHOSP 사용자 및 서비스에서 CPU 또는 메모리 리소스 제약 조건과 같은 리소스 제약 조건으로 인해 여러 구성 요소가 구성된 시간 제한 값에 도달할 수 있는 작업을 트리거했습니다. 이로 인해 haproxy 프런트엔드 또는 백엔드에 대한 시간 초과 요청 실패, 메시징 시간 초과, db 쿼리 관련 오류, 클러스터 불안정성 등이 발생할 수 있습니다. 시간 제한 관련 병목 현상 식별에 도움이 되도록 초기 배포 후 오버클라우드 환경을 벤치마킹합니다.

4장. 디버깅 권장 사항 및 알려진 문제
링크 복사

배포 문제를 해결하는 데 도움이 되는 디버깅 제안 사항은 다음 섹션을 검토하십시오.

4.1. 확인된 문제
링크 복사

다음 목록에서는 기존의 현재 제한 사항을 간략하게 설명합니다.

BZ#1857451 - Ansible 포크 값은 상한값이 있어야 하며 현재 계산을 변경해야 합니다.
기본적으로 mistral의 Ansible 플레이북은 ansible.cfg 파일에서 10*CPU_COUNT 포크를 사용하도록 구성됩니다. Ansible 실행을 특정 노드 또는 노드 집합으로 제한하는 데 --limit 옵션을 사용하지 않으면 Ansible 실행이 모든 기존 노드에서 실행되도록 설정된 경우 Ansible은 거의 100%의 메모리를 사용합니다.

4.2. 인트로스펙션 디버깅
링크 복사

인트로스펙션을 디버깅할 때 다음 권장 사항 목록을 검토합니다.

undercloud.conf 파일에서 인트로스펙션 DHCP 범위 및 NIC를 확인합니다.
이러한 값이 올바르지 않으면 수정한 다음 openstack undercloud install 명령을 다시 실행합니다.
DHCP 노드 범위 이상으로 인트로스펙션을 시도하지 않도록 하십시오.
각 노드의 DHCP 리스가 인트로스펙션이 완료된 후 약 2분 동안 계속 활성화됩니다.
대상 노드가 응답 중인지 확인합니다.
모든 노드가 인트로스펙션에 실패하는 경우 구성된 NIC를 사용하여 기본 VLAN을 통해 대상 노드를 ping하고 대역 외 인터페이스 자격 증명 및 주소가 올바른지 확인합니다.
콘솔에서 인트로스펙션 명령 확인
특정 노드 디버깅의 경우 노드가 부팅되고 노드에 대한 인트로스펙션 명령을 관찰할 때 콘솔을 감시합니다. 노드가 PXE 프로세스를 완료하기 전에 중지되면 연결, IP 할당 및 네트워크 로드를 확인합니다. 노드가 BIOS를 종료하고 인트로스펙션 이미지를 부팅하면 오류가 드물고 연결 문제와 거의 관련이 없습니다. 언더클라우드와 함께 인트로스펙션 이미지의 하트비트가 중단되지 않았는지 확인합니다.

4.3. 배포 디버깅
링크 복사

배포를 디버깅할 때 다음 권장 사항을 사용합니다.

프로비저닝 네트워크에서 주소를 제공하는 DHCP 서버 검사

프로비저닝 네트워크에 주소를 제공하는 추가 DHCP 서버는 Red Hat OpenStack Platform director가 머신을 검사하고 프로비저닝하지 못하도록 할 수 있습니다.

  • DHCP 또는 PXE 인트로스펙션 문제의 경우 다음 명령을 입력합니다. 

    $ sudo tcpdump -i any port 67 or port 68 or port 69
    Copy to Clipboard Toggle word wrap

  • DHCP 또는 PXE 배포 문제의 경우 다음 명령을 입력합니다. 

    $ sudo ip netns exec qdhcp tcpdump -i <interface> port 67 or port 68 or port 69
    Copy to Clipboard Toggle word wrap
실패한 디스크 또는 외부 디스크의 상태를 확인합니다.
실패한 디스크 또는 외부 디스크의 경우 시스템의 대역 외 관리에 따라 실패한 디스크 또는 외부 디스크의 상태가 Up 으로 설정되어 있는지 확인합니다. 디스크는 배포 주기 동안 Up 상태를 종료하고 디스크가 기본 운영 체제에 표시되는 순서를 변경할 수 있습니다.
다음 명령을 사용하여 실패한 오버클라우드 배포를 디버깅합니다.
  • OpenStack 스택 실패 목록 오버클라우드
  • heat resource-list -n5 overcloud | grep -i fail
  • less /var/lib/mistral/config-download-latest/ansible.log

명령의 출력을 검토하려면 오류가 발생한 노드에 로그인하고 /var/log/ 및 /var/log/ containers/ 의 로그 파일을 검토합니다.

Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

Theme

© 2026 Red Hat맨 위로 이동