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