HyperConverged 인프라 가이드
Red Hat OpenStack Platform 오버클라우드에서 Hyperconverged Infrastructure 이해 및 구성
OpenStack Documentation Team
rhos-docs@redhat.com초록
보다 포괄적 수용을 위한 오픈 소스 용어 교체
Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 용어를 교체하기 위해 최선을 다하고 있습니다. 먼저 마스터(master), 슬레이브(slave), 블랙리스트(blacklist), 화이트리스트(whitelist) 등 네 가지 용어를 교체하고 있습니다. 이러한 변경 작업은 작업 범위가 크므로 향후 여러 릴리스에 걸쳐 점차 구현할 예정입니다. 자세한 내용은 CTO Chris Wright의 메시지를 참조하십시오.
Red Hat 문서에 관한 피드백 제공
문서 개선을 위한 의견을 보내 주십시오. 어떻게 하면 더 잘할 수 있는지 알려주십시오.
DDF( Direct Documentation Feedback) 기능 사용
특정 문장, 단락 또는 코드 블록에 대한 직접 의견을 받으려면 피드백 DDF 추가 기능을 사용하십시오.
- 다중 페이지 HTML 형식으로 문서를 봅니다.
- 문서 오른쪽 상단에 Feedback 버튼이 표시되는지 확인합니다.
- 주석 처리하려는 텍스트 부분을 강조 표시합니다.
- 피드백 추가를 클릭합니다.
- 의견을 사용하여 피드백 추가 필드를 완료합니다.
- 선택 사항: 문서 팀이 문제에 대한 명확히 알릴 수 있도록 이메일 주소를 추가합니다.
- Submit 을 클릭합니다.
1장. Red Hat OpenStack Platform 하이퍼컨버지드 인프라 구성 및 배포
1.1. 하이퍼컨버지드 인프라 개요
RHOSP(Red Hat OpenStack Platform) 하이퍼컨버지드 인프라(HCI)는 하이퍼컨버지드 노드로 구성됩니다. RHOSP HCI에서 컴퓨팅 및 스토리지 서비스는 최적화된 리소스 사용을 위해 이러한 하이퍼컨버지드 노드에 배치됩니다. 하이퍼컨버지드 노드만 있는 오버클라우드를 배포하거나 일반 컴퓨팅 및 Red Hat Ceph Storage 노드가 있는 하이퍼컨버지드 노드를 혼합할 수 있습니다.
Red Hat Ceph Storage를 스토리지 공급자로 사용해야 합니다.
BlueStore를 HCI 배포의 백엔드로 사용하여 BlueStore 메모리 처리 기능을 사용합니다.
하이퍼컨버지드 인프라는 director와 함께 Red Hat Ceph 및 OpenStack 배포에 설명된 배포 프로세스의 변형을 사용하여 구축됩니다. 이 배포 시나리오에서 RHOSP director는 director가 오버클라우드 및 Red Hat Ceph Storage를 호출하는 클라우드 환경을 배포합니다. 오버클라우드 구성과 별도로 Ceph 클러스터 자체를 관리하고 확장합니다.
2장. HCI 하드웨어 배포
이 섹션에는 하이퍼컨버지드 노드의 준비 및 구성에 대한 절차 및 정보가 포함되어 있습니다.
사전 요구 사항
- director와 함께 Red Hat Ceph 및 OpenStack 배포의 오버클라우드 및 Red Hat Ceph Storage 배포를 읽습니다.
2.1. Ceph Storage 노드 디스크 정리
Ceph Storage OSD 및 저널 파티션에는 팩토리 정리 디스크가 필요합니다. 즉, Ceph OSD 서비스를 설치하기 전에 Ceph Storage의 추가 디스크를 Bare Metal Provisioning 서비스(ironic)로 지워야 합니다. 디스크에서 모든 메타데이터를 삭제해야 합니다. 그러지 않으면 OSD가 생성되지 않습니다.
기본적으로 모든 디스크 메타데이터를 삭제하도록 director를 구성할 수 있습니다. 이 옵션을 사용하면 베어 메탈 프로비저닝 서비스에서 노드를 부팅하고 노드가 사용 가능하게 설정될 때마다 디스크를 정리하는 추가 단계를 실행합니다. 이 프로세스는 첫 번째 인트로스펙션 이후 및 각 배포 전에 추가 전원 사이클을 추가합니다. 베어 메탈 프로비저닝 서비스에서는 wipefs --force --all 명령을 사용하여 정리를 수행합니다.
절차
/home/stack/undercloud.conf파일에 다음 설정을 추가합니다.clean_nodes=true
이 옵션을 설정한 후
openstack undercloud install명령을 실행하여 이 설정 변경 사항을 실행합니다.주의De
fs --force --all명령은 디스크의 모든 데이터와 메타데이터를 삭제하지만 안전한 지우는 수행하지 않습니다. 안전한 클리닝은 훨씬 더 오래 걸립니다.
2.2. 노드 등록
director가 호스트와 통신할 수 있도록 노드를 등록해야 합니다.
절차
stack사용자의홈디렉터리에서 JSON 형식으로 노드 인벤토리 파일을 생성합니다.$ vi /home/stack/instackenv.json
director가 노드를 등록하는 데 사용할 수 있는 하드웨어 및 전원 관리 세부 정보를 사용하여 인벤토리 파일을 구성합니다.
{ "nodes":[ { "mac":[ "b1:b1:b1:b1:b1:b1" ], "cpu":"4", "memory":"6144", "disk":"40", "arch":"x86_64", "pm_type":"ipmi", "pm_user":"admin", "pm_password":"p@55w0rd!", "pm_addr":"192.0.2.205" }, { "mac":[ "b2:b2:b2:b2:b2:b2" ], "cpu":"4", "memory":"6144", "disk":"40", "arch":"x86_64", "pm_type":"ipmi", "pm_user":"admin", "pm_password":"p@55w0rd!", "pm_addr":"192.0.2.206" }, { "mac":[ "b3:b3:b3:b3:b3:b3" ], "cpu":"4", "memory":"6144", "disk":"40", "arch":"x86_64", "pm_type":"ipmi", "pm_user":"admin", "pm_password":"p@55w0rd!", "pm_addr":"192.0.2.207" }, { "mac":[ "c1:c1:c1:c1:c1:c1" ], "cpu":"4", "memory":"6144", "disk":"40", "arch":"x86_64", "pm_type":"ipmi", "pm_user":"admin", "pm_password":"p@55w0rd!", "pm_addr":"192.0.2.208" }, { "mac":[ "c2:c2:c2:c2:c2:c2" ], "cpu":"4", "memory":"6144", "disk":"40", "arch":"x86_64", "pm_type":"ipmi", "pm_user":"admin", "pm_password":"p@55w0rd!", "pm_addr":"192.0.2.209" }, { "mac":[ "c3:c3:c3:c3:c3:c3" ], "cpu":"4", "memory":"6144", "disk":"40", "arch":"x86_64", "pm_type":"ipmi", "pm_user":"admin", "pm_password":"p@55w0rd!", "pm_addr":"192.0.2.210" }, { "mac":[ "d1:d1:d1:d1:d1:d1" ], "cpu":"4", "memory":"6144", "disk":"40", "arch":"x86_64", "pm_type":"ipmi", "pm_user":"admin", "pm_password":"p@55w0rd!", "pm_addr":"192.0.2.211" }, { "mac":[ "d2:d2:d2:d2:d2:d2" ], "cpu":"4", "memory":"6144", "disk":"40", "arch":"x86_64", "pm_type":"ipmi", "pm_user":"admin", "pm_password":"p@55w0rd!", "pm_addr":"192.0.2.212" }, { "mac":[ "d3:d3:d3:d3:d3:d3" ], "cpu":"4", "memory":"6144", "disk":"40", "arch":"x86_64", "pm_type":"ipmi", "pm_user":"admin", "pm_password":"p@55w0rd!", "pm_addr":"192.0.2.213" } ] }stack 사용자를 초기화한 다음
instackenv.json인벤토리 파일을 director로 가져옵니다.$ source ~/stackrc $ openstack overcloud node import ~/instackenv.json
openstack overcloud node import명령은 인벤토리 파일을 가져와서 각 노드를 director에 등록합니다.각 노드에 커널 및 ramdisk 이미지를 할당합니다.
$ openstack overcloud node configure <node>
노드는 director에 등록 및 구성됩니다.
2.3. 사용 가능한 Red Hat Ceph Storage 패키지 확인
오버클라우드 배포 실패를 방지하려면 필요한 패키지가 서버에 있는지 확인합니다.
2.3.1. cephadm 패키지 설치 확인
Ceph Storage 클러스터의 첫 번째 노드를 부트스트랩하려면 cephadm 패키지를 하나 이상의 오버클라우드 노드에 설치해야 합니다. cephadm 패키지는 overcloud-hardened-uefi-full.qcow2 이미지에 포함되어 있습니다. tripleo_cephadm 역할은 Ansible package 모듈을 사용하여 이미지에 있는지 확인합니다.
2.4. HCI 환경의 소프트웨어 이미지 배포
HCI 환경에 맞게 구성된 노드는 overcloud-hardened-uefi-full.qcow2 소프트웨어 이미지를 사용해야 합니다. 이 소프트웨어 이미지를 사용하려면 RHOSP(Red Hat OpenStack Platform) 서브스크립션이 필요합니다.
절차
-
/home/stack/templates/overcloud-baremetal-deploy.yaml파일을 엽니다. overcloud-hardened-uefi-full이미지가 필요한 노드의 이미지 속성을 추가하거나 업데이트합니다. 특정 노드에서 또는 특정 역할을 사용하는 모든 노드에서 사용할 이미지를 설정할 수 있습니다.특정 노드
- name: Ceph count: 3 instances: - hostname: overcloud-ceph-0 name: node00 image: href: file:///var/lib/ironic/images/overcloud-minimal.qcow2 - hostname: overcloud-ceph-1 name: node01 image: href: file:///var/lib/ironic/images/overcloud-hardened-uefi-full.qcow2 - hostname: overcloud-ceph-2 name: node02 image: href: file:///var/lib/ironic/images/overcloud-hardened-uefi-full.qcow2특정 역할에 대해 구성된 모든 노드
- name: ComputeHCI count: 3 defaults: image: href: file:///var/lib/ironic/images/overcloud-hardened-uefi-full.qcow2 instances: - hostname: overcloud-ceph-0 name: node00 - hostname: overcloud-ceph-1 name: node01 - hostname: overcloud-ceph-2 name: node02roles_data.yaml역할 정의 파일에서rhsm_enforce매개변수를False로 설정합니다.rhsm_enforce: False
프로비저닝 명령을 실행합니다.
(undercloud)$ openstack overcloud node provision \ --stack overcloud \ --output /home/stack/templates/overcloud-baremetal-deployed.yaml \ /home/stack/templates/overcloud-baremetal-deploy.yaml
-
overcloud-baremetal-deployed.yaml환경 파일을openstack overcloud deploy명령에 전달합니다.
2.5. HCI의 노드 지정
HCI의 노드를 지정하려면 새 역할 파일을 생성하여 ComputeHCI 역할을 구성하고 ComputeHCI 의 리소스 클래스를 사용하여 베어 메탈 노드를 구성해야 합니다.
절차
-
stack사용자로 언더클라우드에 로그인합니다. stackrc인증 정보 파일을 소싱합니다.[stack@director ~]$ source ~/stackrc
컨트롤러및ComputeHCI역할을 포함하는roles_data.yaml이라는 새 역할 데이터 파일을 생성합니다.(undercloud)$ openstack overcloud roles generate Controller ComputeHCI -o ~/roles_data.yaml
roles_data.yaml을 열고 다음 매개변수와 섹션이 있는지 확인합니다.섹션/ 매개변수 값 역할 주석
역할: ComputeHCI역할 이름
name: ComputeHCIdescriptionHCI 역할HostnameFormatDefault%stackname%-novaceph-%index%deprecated_nic_config_nameceph.yaml-
노드 정의 템플릿
node.json또는node.yaml에 추가하여 오버클라우드의 ComputeHCI 노드를 등록합니다. 노드 하드웨어를 검사합니다.
(undercloud)$ openstack overcloud node introspect --all-manageable --provide
사용자 지정 HCI 리소스 클래스로 HCI를 지정할 각 베어 메탈 노드를 태그합니다.
(undercloud)$ openstack baremetal node set \ --resource-class baremetal.HCI <node>
&
lt;node>를 베어 메탈 노드의 ID로 바꿉니다./home/stack/templates/overcloud-baremetal-deploy.yaml파일에ComputeHCI역할을 추가하고 노드에 할당할 예측 가능한 노드 배치, 리소스 클래스 또는 기타 속성을 정의합니다.- name: Controller count: 3 - name: ComputeHCI count: 1 defaults: resource_class: baremetal.HCI
baremetal.yaml파일을 열고 HCI에 필요한 네트워크 구성이 포함되어 있는지 확인합니다. 다음은 구성의 예입니다.- name: ComputeHCI count: 3 hostname_format: compute-hci-%index% defaults: profile: ComputeHCI network_config: template: /home/stack/templates/three-nics-vlans/compute-hci.j2 networks: - network: ctlplane vif: true - network: external subnet: external_subnet - network: internalapi subnet: internal_api_subnet01 - network: storage subnet: storage_subnet01 - network: storage_mgmt subnet: storage_mgmt_subnet01 - network: tenant subnet: tenant_subnet01참고ComputeHCI역할의 네트워크 구성에는storage_mgmt네트워크가 포함되어 있습니다. CephOSD 노드는 이 네트워크를 사용하여 데이터의 중복 복사본을 만듭니다.Compute역할에 대한 네트워크 구성에는 이 네트워크가 포함되지 않습니다.자세한 내용은 베어 메탈 프로비저닝 에서 참조하십시오.
프로비저닝 명령을 실행합니다.
(undercloud)$ openstack overcloud node provision \ --stack overcloud \ --output /home/stack/templates/overcloud-baremetal-deployed.yaml \ /home/stack/templates/overcloud-baremetal-deploy.yaml
별도의 터미널에서 프로비저닝 진행 상황을 모니터링합니다.
(undercloud)$ watch openstack baremetal node list
참고watch명령은 기본적으로 2초마다 업데이트됩니다.-n옵션은 갱신 타이머를 다른 값으로 설정합니다.-
감시프로세스를 중지하려면Ctrl-c를 입력합니다. -
검증: 프로비저닝에 성공하면 노드 상태가
available에서active로 변경됩니다.
추가 리소스
- 노드 등록 방법에 대한 자세한 내용은 Director 설치 및 사용 가이드 의 오버클라우드 노드 등록을 참조하십시오.
- 노드 하드웨어 검사에 대한 자세 한 내용은 Director 설치 및 사용 가이드의 베어 메탈 노드 하드웨어 인벤토리 생성 을 참조하십시오.
-
ComputeHCI역할 및storage_mgmt네트워크의 네트워크 구성에 대한 자세한 내용은 베어 메탈 프로비저닝 을 참조하십시오.
2.6. 멀티 디스크 Ceph 클러스터의 root 디스크 정의
대부분의 Ceph Storage 노드는 여러 디스크를 사용합니다. 노드에서 여러 디스크를 사용하는 경우 director는 root 디스크를 식별해야 합니다. 기본적으로 director는 프로비저닝 프로세스 중에 오버클라우드 이미지를 root 디스크에 씁니다.
일련 번호로 root 장치를 확인하려면 다음 절차를 사용하십시오. root 디스크를 식별하는 데 사용할 수 있는 다른 속성에 대한 자세한 내용은 2.6.1절. “root 디스크를 식별하는 속성” 을 참조하십시오.
절차
각 노드의 하드웨어 인트로스펙션에서 디스크 정보를 확인합니다. 노드의 디스크 정보를 표시하는 다음 명령을 실행합니다.
(undercloud)$ openstack baremetal introspection data save 1a4e30da-b6dc-499d-ba87-0bd8a3819bc0 | jq ".inventory.disks"
예를 들어 노드 1개의 데이터에서 디스크 3개가 표시될 수 있습니다.
[ { "size": 299439751168, "rotational": true, "vendor": "DELL", "name": "/dev/sda", "wwn_vendor_extension": "0x1ea4dcc412a9632b", "wwn_with_extension": "0x61866da04f3807001ea4dcc412a9632b", "model": "PERC H330 Mini", "wwn": "0x61866da04f380700", "serial": "61866da04f3807001ea4dcc412a9632b" } { "size": 299439751168, "rotational": true, "vendor": "DELL", "name": "/dev/sdb", "wwn_vendor_extension": "0x1ea4e13c12e36ad6", "wwn_with_extension": "0x61866da04f380d001ea4e13c12e36ad6", "model": "PERC H330 Mini", "wwn": "0x61866da04f380d00", "serial": "61866da04f380d001ea4e13c12e36ad6" } { "size": 299439751168, "rotational": true, "vendor": "DELL", "name": "/dev/sdc", "wwn_vendor_extension": "0x1ea4e31e121cfb45", "wwn_with_extension": "0x61866da04f37fc001ea4e31e121cfb45", "model": "PERC H330 Mini", "wwn": "0x61866da04f37fc00", "serial": "61866da04f37fc001ea4e31e121cfb45" } ]언더클라우드에서 노드의 root 디스크를 설정합니다. root 디스크를 정의하는 데 가장 적절한 하드웨어 속성값을 포함시킵니다.
(undercloud)$ openstack baremetal node set --property root_device='{"serial":"<serial_number>"}' <node-uuid>예를 들어, root 장치를 일련 번호가
61866da04f380d001ea4e13c12e36ad6인 disk 2로 설정하려면 다음 명령을 입력합니다.(undercloud)$ openstack baremetal node set --property root_device='{"serial": "61866da04f380d001ea4e13c12e36ad6"}' 1a4e30da-b6dc-499d-ba87-0bd8a3819bc0참고선택한 root 디스크에서 부팅하도록 각 노드의 BIOS를 구성합니다. 먼저 네트워크에서 부팅한 다음 root 디스크에서 부팅하도록 부팅 순서를 구성합니다.
director가 root 디스크로 사용할 특정 디스크를 식별합니다. openstack overcloud node provision 명령을 실행하면 director가 오버클라우드 이미지를 프로비저닝하고 root 디스크에 씁니다.
2.6.1. root 디스크를 식별하는 속성
director가 root 디스크를 쉽게 식별할 수 있도록 다음과 같은 속성을 정의할 수 있습니다.
-
model(문자열): 장치 식별자 -
vendor(문자열): 장치 벤더 -
serial(문자열): 디스크 일련번호 -
hctl(문자열): Host:Channel:Target:Lun (SCSI 용) -
size(정수): 장치의 크기(GB 단위) -
wwn(문자열): 고유한 스토리지 식별자 -
wwn_with_extension(문자열): 벤더 확장이 첨부된 고유한 스토리지 식별자 -
wwn_vendor_extension(문자열): 고유한 벤더 스토리지 식별자 -
rotational(부울): 회전 장치인 경우(HDD) True, 그렇지 않은 경우 false(SSD) -
name(문자열): 장치의 이름(예: /dev/sdb1)
name 속성은 영구적인 이름이 있는 장치에만 사용합니다. 노드가 부팅될 때 값이 변경될 수 있으므로 name을 사용하여 다른 장치에 대해 root 디스크를 설정하지 마십시오.
3장. HCI를 위한 Red Hat Ceph Storage 클러스터 구성
이 장에서는 HCI 환경을 위한 Red Hat Ceph Storage 클러스터를 구성하고 배포하는 방법을 설명합니다.
3.1. 배포 사전 요구 사항
Red Hat Ceph Storage 클러스터를 구성하고 배포하기 전에 다음 작업이 수행되었는지 확인합니다.
- Bare Metal Provisioning 서비스(ironic)를 사용하여 베어 메탈 인스턴스 및 해당 네트워크를 프로비저닝합니다. 베어 메탈 인스턴스 프로비저닝에 대한 자세한 내용은 베어 메탈 프로비저닝 을 참조하십시오.
3.2. openstack overcloud ceph deploy 명령
director를 사용하여 Ceph 클러스터를 배포하는 경우 openstack overcloud ceph deploy 명령을 사용해야 합니다. 명령 옵션 및 매개변수의 전체 목록은 명령줄 인터페이스 참조 의 openstack overcloud ceph deploy 를 참조하십시오.
openstack overcloud ceph deploy --help 명령은 현재 사용 가능한 옵션과 매개변수를 제공합니다.
3.3. HCI의 Ceph 구성 덮어쓰기
표준 형식 초기화 파일은 Ceph 클러스터 구성에 대한 옵션입니다. 그러면 이 초기화 파일은 cephadm boottap --config <file_name> 또는 > 명령으로 Ceph 클러스터를 구성하는 데 사용됩니다.
openstack overcloud ceph deploy --config <file_name
하이퍼컨버지드 노드에서 Ceph OSD 및 Compute 서비스를 변경하면 Red Hat Ceph Storage와 Compute 서비스 간의 리소스 경합이 발생할 수 있습니다. 이는 서비스가 호스팅을 인식하지 못하기 때문에 발생합니다. 리소스 경합으로 인해 서비스 성능 저하가 발생할 수 있으며 이로 인해 하이퍼컨버지의 이점을 오프셋할 수 있습니다.
초기화 파일을 사용하여 리소스 할당을 조정하여 리소스 경합을 관리할 수 있습니다. 다음으로 initial-ceph.conf 라는 초기화 파일을 생성한 다음 openstack overcloud ceph deploy 명령을 사용하여 HCI 배포를 구성합니다.
$ cat <<EOF > initial-ceph.conf [osd] osd_memory_target_autotune = true osd_numa_auto_affinity = true [mgr] mgr/cephadm/autotune_memory_target_ratio = 0.2 EOF $ openstack overcloud ceph deploy --config initial-ceph.conf
OSD 데몬이 osd_memory_target_target config 옵션에 따라 메모리 사용량을 조정하도록 옵션이 osd_memory_target_ autotunetrue 로 설정됩니다. autotune_memory_target_ratio 의 기본값은 0.7 입니다. 이는 자동 조정되지 않은 Ceph 데몬이 사용하는 모든 메모리를 뺀 시작 지점인 총 RAM의 70%를 나타냅니다. 그런 다음 나머지 메모리는 모든 OSD에 osd_memory_target_autotune 이 true 로 설정되어 있다고 가정하여 OSD로 나뉩니다. HCI 배포의 경우 mgr/cephadm/autotune_memory_target_ratio 를 0.2로 설정하여 Compute 서비스에 더 많은 메모리를 사용할 수 있도록 합니다. 0.2 값은 신중한 출발점입니다. 배포 후 ceph 명령을 사용하여 필요한 경우 이 값을 변경합니다.
두 개의 NUMA 노드 시스템은 대기 시간에 민감한 Nova 워크로드를 하나의 NUMA 노드에서 호스팅할 수 있으며 다른 NUMA 노드에서 Ceph OSD 워크로드를 호스트할 수 있습니다. 컴퓨팅 워크로드에서 사용하지 않는 특정 NUMA 노드를 사용하도록 Ceph OSD를 구성하려면 다음 Ceph OSD 구성 중 하나를 사용합니다.
-
osd_numa_node는 유사성을 numa 노드로 설정합니다. -
osd_numa_auto_affinity는 스토리지 및 네트워크가 일치하는 NUMA 노드에 유사성을 자동으로 설정합니다.
NUMA 노드와 디스크 컨트롤러가 모두 NUMA 노드 0에 있는 경우 스토리지 네트워크 0에서 네트워크 인터페이스를 사용하고 NUMA 노드 0에서 Ceph OSD 워크로드를 호스팅합니다. NUMA 노드 1에서 Nova 워크로드를 호스팅하고 NUMA 노드 1에서 네트워크 인터페이스를 사용하도록 합니다. 이 구성을 달성하려면 osd_numa_auto_affinity 를 true 로 설정합니다. 또는 osd_numa_node 를 0 으로 직접 설정할 수 있으며 osd_numa_auto_affinity 에 값이 설정되어 기본값이 false 로 설정됩니다.
OSD가 오프라인 상태가 되면 하이퍼컨버지드 클러스터가 다시 입력되면 백필 프로세스가 느려질 수 있습니다. 복구 속도가 느린 복구를 위해 백필 작업은 배치된 컴퓨팅 워크로드에 영향을 미치지 않습니다. Red Hat Ceph Storage 5에는 백필 활동 비율을 제어하기 위한 다음과 같은 기본값이 있습니다.
-
osd_recovery_op_priority = 3 -
osd_max_backfills = 1 -
osd_recovery_max_active_hdd = 3 osd_recovery_max_active_ssd = 10참고기본값이므로 초기화 파일에서 이러한 기본값을 전달할 필요가 없습니다. 기본값 이외의 값이 inital 구성에 필요한 경우 배포 전에 필요한 값을 사용하여 초기화 파일에 추가합니다. 배포 후 'ceph config set osd' 명령을 사용합니다.
3.4. Red Hat Ceph Storage 클러스터 이름 구성
구성하는 이름으로 Red Hat Ceph Storage 클러스터를 배포할 수 있습니다. 기본 이름은 ceph 입니다.
절차
-
stack사용자로 언더클라우드 노드에 로그인합니다. 다음 명령을 사용하여 Ceph Storage 클러스터의 이름을 구성합니다.
OpenStack overcloud ceph deploy \ --cluster <cluster_name>$ OpenStack overcloud ceph deploy \ --cluster central \
인증 키 파일은 현재 생성되지 않습니다. 키링 파일은 오버클라우드 배포 중에 생성됩니다. 키링 파일은 이 프로세스 중에 구성된 클러스터 이름을 상속합니다. 오버클라우드 배포에 대한 자세한 내용은 다음을 참조하십시오. 5.8절. “HCI에 대한 오버클라우드 배포 시작”
위의 예에서 Ceph 클러스터의 이름은 central 입니다. 중앙 Ceph 클러스터의 구성 및 키링 파일은 배포 프로세스 중 /etc/ceph 에 생성됩니다.
[root@oc0-controller-0 ~]# ls -l /etc/ceph/ total 16 -rw-------. 1 root root 63 Mar 26 21:49 central.client.admin.keyring -rw-------. 1 167 167 201 Mar 26 22:17 central.client.openstack.keyring -rw-------. 1 167 167 134 Mar 26 22:17 central.client.radosgw.keyring -rw-r--r--. 1 root root 177 Mar 26 21:49 central.conf
문제 해결
Ceph Storage 클러스터의 사용자 지정 이름을 구성하면 다음 오류가 표시될 수 있습니다.
monclient: get_monmap_and_config는 다음과 같이 모니터를 식별할 수 없기 때문에
이 오류가 표시되면 Ceph 배포 후 다음 명령을 사용합니다.
cephadm shell --config <configuration_file> --keyring <keyring_file>
예를 들어 클러스터 이름을 중앙 으로 구성할 때 이 오류가 표시되면 다음 명령을 사용합니다.
cephadm shell --config /etc/ceph/central.conf \
--keyring /etc/ceph/central.client.admin.keyring다음 명령을 대안으로 사용할 수도 있습니다.
cephadm shell --mount /etc/ceph:/etc/ceph export CEPH_ARGS='--cluster central'
3.5. 네트워크 데이터 파일을 사용하여 네트워크 옵션 구성
네트워크 데이터 파일은 Red Hat Ceph Storage 클러스터에서 사용하는 네트워크를 설명합니다.
절차
-
stack사용자로 언더클라우드 노드에 로그인합니다. network_data.yaml이라는 사용자 지정 네트워크 속성을 정의하는 YAML 형식 파일을 생성합니다.중요네트워크 분리를 사용하여 표준 네트워크 배포는 두 개의 Ceph 네트워크에 매핑되는 두 개의 스토리지 네트워크로 구성됩니다.
-
스토리지 네트워크인
스토리지는 Ceph 네트워크public_network에 매핑됩니다. 이 네트워크는 컴퓨팅 노드에서 Ceph 클러스터로의 RBD 트래픽과 같은 스토리지 트래픽을 처리합니다. -
스토리지 네트워크인
storage_mgmt는 Ceph 네트워크cluster_network에 매핑됩니다. 이 네트워크는 Ceph OSD 간의 데이터 복제와 같은 스토리지 관리 트래픽을 처리합니다.
-
스토리지 네트워크인
--crush-hierarchy옵션과 함께openstack overcloud ceph deploy명령을 사용하여 구성을 배포합니다.openstack overcloud ceph deploy \ deployed_metal.yaml \ -o deployed_ceph.yaml \ --network-data network_data.yaml중요openstack overcloud ceph deploy명령은--network-data옵션에 지정된 네트워크 데이터 파일을 사용하여public_network및cluster_network로 사용할 네트워크를 결정합니다. 이 명령은--public-network-name및--cluster-network-name옵션에 다른 이름을 지정하지 않는 한 네트워크 데이터 파일에서 이러한 네트워크의 이름이storage및storage_mgmt라고 가정합니다.네트워크 분리로 배포할 때
--network-data옵션을 사용해야 합니다. 이 옵션을 사용하지 않는 경우public_network및cluster_network에 기본 언더클라우드(192.168.24.0/24)가 사용됩니다.
3.6. 구성 파일을 사용하여 네트워크 옵션 구성
네트워크 데이터 파일의 대안으로 구성 파일을 사용하여 네트워크 옵션을 지정할 수 있습니다.
이 방법을 사용하여 네트워크 옵션을 구성하여 network_data.yaml 에서 자동으로 생성된 값을 덮어씁니다. 이 네트워크 구성 방법을 사용할 때 4개의 값을 모두 설정해야 합니다.
절차
-
stack사용자로 언더클라우드 노드에 로그인합니다. - Ceph 클러스터를 구성하는 표준 형식 초기화 파일을 생성합니다. 다른 구성 옵션을 포함하도록 파일을 이미 생성한 경우 네트워크 구성을 추가할 수 있습니다.
파일의
[global]섹션에 다음 매개변수를 추가합니다.-
public_network -
cluster_network ms_bind_ipv4중요public_network및cluster_network가 storage 및와 동일한 네트워크에 매핑되는지 확인합니다.storage_mgmt다음은 여러 서브넷 및 사용자 지정 네트워킹 이름이 있는 네트워크 구성에 대한 구성 파일 항목의 예입니다.
[global] public_network = 172.16.14.0/24,172.16.15.0/24 cluster_network = 172.16.12.0/24,172.16.13.0/24 ms_bind_ipv4 = True ms_bind_ipv6 = False
-
구성 파일을 배포하려면
openstack overcloud ceph deploy명령을--config옵션과 함께 사용합니다.$ openstack overcloud ceph deploy \ --config initial-ceph.conf --network-data network_data.yaml
3.7. OSD의 DestinationRule 계층 구성
OSD 배포 중에 CRUSH(Controlled Replication Under Scalable Hashing) 계층을 구성하여 OSD 위치 속성을 Ceph Storage 클러스터 호스트 사양에 추가할 수 있습니다. location 속성은 OSD가 DestinationRule 계층 내에 배치되는 위치를 구성합니다.
location 속성은 초기ECDHE 위치만 설정합니다. 이후 특성 변경은 무시됩니다.
절차
-
stack사용자로 언더클라우드 노드에 로그인합니다. stackrc언더클라우드 인증 정보 파일을 소싱합니다.$ 소스 ~/stackrc-
구성 파일을 생성하여 사용자 지정ECDHE 계층 구조(예:
crush_hierarchy.yaml)를 정의합니다. 파일에 다음 구성을 추가합니다.
ceph_crush_hierarchy: <osd_host>: root: default rack: <rack_num> <osd_host>: root: default rack: <rack_num> <osd_host>: root: default rack: <rack_num>-
&
lt;osd_host>를 OSD가 배포된 노드의 호스트 이름으로 바꿉니다(예:ceph-0). -
&
lt;rack_num>을 OSD가 배포된 랙 수(예:r0)로 바꿉니다.
-
&
사용자 지정 OSD 레이아웃을 사용하여 Ceph 클러스터를 배포합니다.
openstack overcloud ceph deploy \ deployed_metal.yaml \ -o deployed_ceph.yaml \ --osd-spec osd_spec.yaml \ --crush-hierarchy crush_hierarchy.yaml
Ceph 클러스터는 사용자 지정 OSD 레이아웃을 사용하여 생성됩니다.
위의 예제 파일에서는 다음과 같은 OSD 레이아웃이 생성됩니다.
ID CLASS WEIGHT TYPE NAME STATUS REWEIGHT PRI-AFF -1 0.02939 root default -3 0.00980 rack r0 -2 0.00980 host ceph-node-00 0 hdd 0.00980 osd.0 up 1.00000 1.00000 -5 0.00980 rack r1 -4 0.00980 host ceph-node-01 1 hdd 0.00980 osd.1 up 1.00000 1.00000 -7 0.00980 rack r2 -6 0.00980 host ceph-node-02 2 hdd 0.00980 osd.2 up 1.00000 1.00000
장치 클래스는 Ceph에서 자동으로 감지되지만 CRUSH 규칙은 풀과 연결됩니다. 오버클라우드 배포 중에 CephCrushRules 매개변수를 사용하여 풀은 여전히 정의 및 생성됩니다.
추가 리소스
자세한 내용은 Red Hat Ceph Storage 설치 가이드의 Red Hat Ceph Storage 워크로드 고려 사항을 참조하십시오.
3.8. Ceph 서비스 배치 옵션 구성
사용자 지정 역할 파일을 사용하여 Ceph 서비스를 실행하는 노드를 정의할 수 있습니다. 사용자 지정 역할 파일은 환경 때문에 기본 역할 할당을 사용하지 않는 경우에만 필요합니다. 예를 들어 하이퍼컨버지드 노드를 배포할 때 계산 인스턴스 목록이 포함된 배치 목록을 갖도록 사전 배포된 계산 노드에 osd 의 서비스 유형이 osd 로 레이블이 지정되어야 합니다.
roles_data.yaml 파일의 서비스 정의는 어떤 서비스를 실행하는 베어 메탈 인스턴스를 결정합니다. 기본적으로 Controller 역할에는 CephMon 및 CephMgr 서비스가 있으며 CephStorage 역할에는 CephOSD 서비스가 있습니다. 대부분의 구성 가능 서비스와 달리 Ceph 서비스는 서비스 구성 방법을 결정하기 위해 heat 출력이 필요하지 않습니다. roles_data.yaml 파일은 Heat가 실행되기 전에 배포된 Ceph 프로세스가 수행되는 경우에도 항상 Ceph 서비스 배치를 결정합니다.
절차
-
stack사용자로 언더클라우드 노드에 로그인합니다. - 사용자 지정 역할을 정의하는 YAML 형식 파일을 생성합니다.
구성 파일을 배포합니다.
$ openstack overcloud ceph deploy \ deployed_metal.yaml \ -o deployed_ceph.yaml \ --roles-data custom_roles.yaml
3.9. Ceph 노드에 대한 SSH 사용자 옵션 구성
openstack overcloud ceph deploy 명령은 사용자와 키를 생성하여 이 섹션의 절차를 수행할 필요가 없도록 호스트에 배포합니다. 그러나 지원되는 옵션입니다.
Cephadm은 SSH를 사용하여 관리되는 모든 원격 Ceph 노드에 연결합니다. Red Hat Ceph Storage 클러스터 배포 프로세스는 모든 오버클라우드 Ceph 노드에 계정 및 SSH 키 쌍을 생성합니다. 그러면 노드와 통신할 수 있도록 키 쌍이 Cephadm에 제공됩니다.
3.9.1. Red Hat Ceph Storage 클러스터 생성 전에 SSH 사용자 생성
openstack overcloud ceph user enable 명령을 사용하여 Ceph 클러스터를 생성하기 전에 SSH 사용자를 생성할 수 있습니다.
절차
-
stack사용자로 언더클라우드 노드에 로그인합니다. SSH 사용자를 생성합니다.
$ OpenStack overcloud ceph 사용자 활성화참고기본 사용자 이름은
ceph-admin입니다. 다른 사용자 이름을 지정하려면--cephadm-ssh-user옵션을 사용하여 다른 사용자 이름을 지정합니다.OpenStack overcloud ceph user enable --cephadm-ssh-user <custom_user_name>기본 이름을 사용하고
--cephadm-ssh-user매개변수를 사용하지 않는 것이 좋습니다.사용자가 사전에 생성된 경우
openstack overcloud ceph deploy를 실행할 때--skip-user-create매개변수를 사용합니다.
3.9.2. SSH 사용자 비활성화
SSH 사용자를 비활성화하면 Cephadm이 비활성화됩니다. Cephadm을 비활성화하면 Ceph 클러스터를 관리하는 서비스가 제거되고 관련 명령이 작동하지 않습니다. 또한 Ceph 노드 오버클라우드 확장 작업을 방지할 수 있습니다. 또한 모든 공개 및 개인 SSH 키를 제거합니다.
절차
-
stack사용자로 언더클라우드 노드에 로그인합니다. openstack overcloud ceph 사용자 disable --fsid <FSID> ceph_spec.yaml명령을 사용하여 SSH 사용자를 비활성화합니다.참고FSID는
deployed_ceph.yaml환경 파일에 있습니다.중요Cephadm을 비활성화하려면
openstack overcloud ceph user disable명령을 사용하지 않는 것이 좋습니다.중요비활성화된 후 SSH 사용자 및 Cephadm 서비스를 활성화하려면
openstack overcloud ceph user enable --fsid <FSID> ceph_spec.yaml명령을 사용합니다.참고이 명령을 실행하려면 Ceph 사양 파일의 경로가 필요합니다.
- SSH 사용자가 필요한 호스트는 무엇입니까.
- 다음 중 _admin 레이블이 있고 개인 SSH 키가 필요한 호스트는 무엇입니까.
- 다음 중 공용 SSH 키가 필요한 호스트는 무엇입니까.
사양 파일 및 생성 방법에 대한 자세한 내용은 서비스 사양 생성을 참조하십시오.
3.10. 컨테이너 레지스트리 구성
언더클라우드를 Ceph 컨테이너의 컨테이너 레지스트리로 구성할 수 있습니다. 기본적으로 openstack overcloud ceph deploy 는 기본 container_image_prepare_defaults.yaml 파일에서 Ceph 컨테이너를 가져옵니다. 파일에 push_destination 속성을 정의한 경우 오버클라우드는 로컬 레지스트리에 액세스하여 Ceph 컨테이너를 다운로드합니다. 이렇게 하면 --skip-hosts-config 및 --skip-container-registry-config 옵션이 사용되지 않거나 push_destination 이 정의되지 않은 경우 오버클라우드 /etc/hosts 및 /etc/containers/registries.conf 파일이 수정됩니다.
이 명령을 사용하여 현재 Ceph 버전을 볼 수 있습니다.
+
$ egrep "ceph_namespace|ceph_image|ceph_tag" \ /usr/share/tripleo-common/container-images/container_image_prepare_defaults.yaml
절차
-
stack사용자로 언더클라우드 노드에 로그인합니다. 사용자 지정 컨테이너 레지스트리를 정의하는 YAML 형식 파일을 생성합니다.
다음은
custom_container_image_prepare.yaml이라는 사용자 지정 컨테이너 레지스트리 파일의 예입니다.ContainerImageRegistryCredentials: quay.io/ceph-ci: quay_username: quay_password--container-image-prepare옵션과 함께openstack overcloud ceph deploy명령을 사용하여 사용자 정의 컨테이너 레지스트리를 정의합니다.openstack overcloud ceph deploy \ deployed_metal.yaml \ -o deployed_ceph.yaml \ --container-image-prepare custom_container_image_prepare.yaml
4장. HCI용 Red Hat Ceph Storage 클러스터 사용자 정의
RHOSP(Red Hat OpenStack Platform) director는 기본 구성을 사용하여 컨테이너화된 Red Hat Ceph Storage를 배포합니다. 기본 설정을 재정의하여 Ceph Storage를 사용자 지정할 수 있습니다.
사전 요구 사항
- 서버가 배포되고 해당 스토리지 네트워크가 구성됩니다.
-
배포된 베어 메탈 파일은
openstack overcloud node provision -o ~/deployed_metal.yaml에 의해 출력됩니다.
4.1. 구성 옵션
Red Hat Ceph Storage는 Ceph 클러스터의 초기 구성을 사용자 정의할 수 있는 몇 가지 옵션을 제공합니다.
초기 Red Hat Ceph Storage 구성은 .conf 확장자가 있는 표준 형식 초기화(ini) 파일을 사용하여 적용할 수 있습니다.
절차
-
stack사용자로 언더클라우드 노드에 로그인합니다. 선택사항: 표준 형식 초기화(ini) 파일을 사용하여 Ceph 클러스터를 구성합니다.
구성 옵션을 사용하여 파일을 생성합니다. 다음은 간단한 구성 파일의 예입니다.
[global] osd crush chooseleaf type = 0 log_file = /var/log/ceph/$cluster-$type.$id.log [mon] mon_cluster_log_to_syslog = true
openstack overcloud ceph deploy --config <configuration_file_name> 명령을 사용하여 구성을 배포합니다.$ openstack overcloud ceph deploy --config initial-ceph.conf
중요openstack overcloud ceph deploy명령을 통한deployed_ceph.yaml환경 파일 출력에는ApplyCephConfigOverridesOnUpdate속성이true로 설정되어 있습니다. 이 값을 사용하면 오버클라우드 배포 중에 RGW와 같은 초기 클러스터 생성 중에 포함되지 않은 서비스를 설정할 수 있습니다. 오버클라우드 배포가 완료되면deployed_ceph.yaml파일 또는 환경에서 유사한 목적에 사용되는 파일을 업데이트하여ApplyCephConfigOverridesOnUpdate를false로 설정합니다. 환경 작업 중에 변경한 후속 Ceph 구성은ceph config명령을 사용하여 수행해야 합니다.ApplyCephConfigOverridesOnUpdate및CephConfigOverrides매개변수에 대한 자세한 내용은 Overcloud Parameters 를 참조하십시오.
선택 사항:
openstack overcloud ceph deploy --single-host-defaults명령을 사용하여 단일 인스턴스에서 실행되도록 Ceph 클러스터를 구성합니다.참고이 옵션은 테스트 환경에서만 사용할 수 있습니다. 프로덕션 환경에서는 지원되지 않습니다.
선택 사항:
openstack overcloud ceph deploy --force \ --cephadm-extra-args '<optional_arguments>' \명령을 사용하여 추가 구성 값을cephadm 부트스트랩명령에 전달합니다.--log-to-file인수와--skip-prepare-host인수가 필요한 경우openstack overcloud ceph deploy --force \ --cephadm-extra-args '-log-to-file --skip-prepare-host' \명령을 사용합니다. 기본cephadm 부트스트랩명령cephadm boostrap --log-to-file --skip-prepare-host가 실행됩니다.참고가능한 모든
옵션이 기능 배포를 보장하기 때문에 -force옵션은-cephadm-extra-args를 사용할 때 필요합니다.
4.2. 서비스 사양 생성 (선택 사항)
Red Hat Ceph Storage 클러스터 서비스 사양은 Ceph 서비스 배포를 설명하는 YAML 파일입니다. Ceph 클러스터를 배포하기 전에 tripleo 에서 자동으로 생성되며 일반적으로 별도로 생성할 필요가 없습니다.
Red Hat Ceph Storage 클러스터를 사용자 지정하기 위해 사용자 정의 서비스 사양을 생성할 수 있습니다.
절차
-
stack사용자로 언더클라우드 노드에 로그인합니다. openstack overcloud ceph spec명령을 사용하여 사양 파일을 생성합니다. 다음 예제는-o스위치로 지정된 위치에 사양 파일을 출력합니다.openstack overcloud ceph spec -o '~/ceph_spec.yaml'
- 필요한 구성으로 생성된 파일을 편집합니다.
openstack overcloud ceph deploy명령을 사용하여 사용자 정의 서비스 사양을 배포합니다.openstack overcloud ceph deploy \ deployed_metal.yaml \ -o deployed_ceph.yaml \ --ceph-spec ~/ceph_spec.yaml
4.3. Red Hat Ceph Storage를 사용한 Red Hat OpenStack Platform용 Ceph 컨테이너
NFS Ganesha에서 Red Hat Ceph Storage를 사용하도록 RHOSP(Red Hat Openstack Platform)를 구성하려면 Ceph 컨테이너가 있어야 합니다. 외부 Ceph Storage 클러스터가 블록( RBD를 통해) 또는 오브젝트(RGW) 스토리지를 제공하는 경우에만 Ceph 컨테이너가 필요하지 않습니다.
Red Hat Enterprise Linux 9와 호환되려면 RHOSP 17에 Red Hat Ceph Storage 5(Ceph 패키지 16.x)가 필요합니다. Ceph Storage 5 컨테이너는 인증이 필요한 레지스트리인 registry.redhat.io 에서 호스팅됩니다. 자세한 내용은 컨테이너 이미지 준비 매개변수를 참조하십시오.
4.4. 고급 OSD 사양 구성
운영 체제가 설치된 디스크를 제외한 모든 디스크는 기본적으로 OSD로 사용됩니다. 이는 기본 OSD 사양 파일에 다음과 같은 정의가 있기 때문입니다.
data_devices: all: true
data_devices 속성은 Ceph 서비스 사양에서 OSD를 구성하는 데 사용되는 여러 OSD 관련 속성 중 하나입니다. OSD 서비스 사양에서 OSD 구성에 사용할 수 있는 속성이 나열됩니다.
절차
-
stack사용자로 언더클라우드 노드에 로그인합니다. OSD 사양을 정의하는 이라는 YAML 포맷 파일을 생성합니다.
다음은 사용자 지정 OSD 사양의 예입니다.
data_devices: rotational: 1 db_devices: rotational: 0
이 예제에서는 모든 회전 장치가 데이터 장치이며 모든 순환되지 않은 장치가 공유 장치로 사용되는 OSD 사양을 생성합니다. 이는 동적 Ceph 서비스 사양을 빌드할 때, service_type이
osd인 경우 사양의 섹션에 임의 항목이 추가되기 때문입니다.openstack overcloud ceph deploy \ --osd-spec <osd_specification_file> 명령을 사용하여 구성을 배포합니다.$ openstack overcloud ceph deploy \ --osd-spec osd_spec.yaml \
다음은 osd_spec.yaml 파일의 또 다른 예입니다.
data_devices: model: 'SAMSUNG' osds_per_device: 2
이 예에서 model 매개 변수는 data_devices 와 함께 사용되어 장치당 OSD가 두 개 있는 해당 장치 모델에 OSD만 생성합니다. osds_per_device 매개변수는 data_devices 아래에 있지 않습니다.
4.5. 노드별 오버라이드에서 마이그레이션
Red Hat Openstack Platform 17.0 이전에는 노드별 재정의를 사용하여 모호하지 않은 서버 하드웨어를 관리했습니다. 이제 사용자 지정 OSD 사양 파일을 사용하여 수행됩니다. 사용자 지정 OSD 사양 파일을 생성하는 방법에 대한 자세한 내용은 고급 OSD 사양 구성 을 참조하십시오.
4.6. Ceph on-wire 암호화 활성화
메신저 버전 2 프로토콜이 도입되어 네트워크를 통해 모든 Ceph 트래픽에 대한 암호화를 활성화할 수 있습니다. v2의 보안 모드 설정은 Ceph 데몬과 Ceph 클라이언트 간의 통신을 암호화하여 엔드 투 엔드 암호화를 제공합니다.
절차
-
Red Hat Ceph Storage Data Security 및 Hardening Guide 에서 메신저 v2 프로토콜 활성화에 설명된 지시문을 사용하여
ceph.conf의 초기 ceph.conf를 구성합니다.
Ceph on-wire 암호화에 대한 자세한 내용은 Red Hat Ceph Storage Architecture Guide 의 Ceph on-wire encryption 에서 참조하십시오.
5장. HCI에 대한 스토리지 서비스 사용자 정의
RHOSP(Red Hat OpenStack Platform) director는 기본 Ceph Storage 구성을 활성화하는 데 필요한 heat 템플릿 및 환경 파일을 제공합니다.
director는 /usr/share/openstack-tripleo-heat-templates/environments/cephadm/cephadm.yaml 환경 파일을 사용하여 openstack overcloud ceph 배포에서 배포된 Ceph 클러스터에 추가 구성을 추가합니다.
RHOSP의 컨테이너화된 서비스에 대한 자세 한 내용은 Director 설치 및 사용에서 CLI 툴을 사용하여 기본 오버클라우드 구성 을 참조하십시오.
5.1. HCI의 Compute 서비스 리소스 구성
하이퍼컨버지드 노드에서 Ceph OSD 및 Compute 서비스를 변경하면 Red Hat Ceph Storage와 Compute 서비스 간의 리소스 경합이 발생할 수 있습니다. 이는 서비스가 충돌을 인식하지 못하기 때문에 발생합니다. 리소스 경합으로 인해 서비스 성능 저하가 발생할 수 있으며 이로 인해 하이퍼컨버지의 이점을 오프셋할 수 있습니다.
계산 서비스에서 사용하는 리소스를 구성하면 리소스 경합이 완화되고 HCI 성능이 향상됩니다.
절차
- 언더클라우드 호스트에 stack 사용자로 로그인합니다.
stackrc 언더클라우드 인증 정보 파일을 소싱합니다.
$ source ~/stackrc
ceph-overrides.yaml파일에NovaReservedHostMemory매개변수를 추가합니다. 다음은 사용 예입니다.parameter_defaults: ComputeHCIParameters: NovaReservedHostMemory: 75000
NovaReservedHostMemory 매개변수는 /etc/nova/nova.conf 에서 reserved_host_memory_mb 의 기본값을 덮어씁니다. 이 매개변수는 Ceph OSD에 필요한 메모리를 가상 시스템에 제공하는 Nova 스케줄러를 중지하도록 설정됩니다.
위의 예제에서는 하이퍼바이저의 기본 예약된 메모리 외에도 호스트당 OSD당 5GB를 예약합니다. IOPS 최적화 클러스터에서는 OSD당 더 많은 메모리를 예약하여 성능을 개선할 수 있습니다. 5GB 번호는 필요에 따라 보다 구체화할 수 있는 시작점으로 제공됩니다.
openstack overcloud deploy 명령을 사용하는 경우 이 파일을 포함합니다.
5.2. 사용자 정의 환경 파일 구성
director는 배포된 Red Hat Ceph Storage 클러스터에 기본 설정을 적용합니다. 사용자 지정 환경 파일에서 추가 구성을 정의해야 합니다.
절차
-
/home/stack/templates/에storage-config.yaml파일을 생성합니다. 이 예제에서~/templates/storage-config.yaml파일에는 환경에 대한 대부분의 오버클라우드 관련 사용자 지정 설정이 포함되어 있습니다. 사용자 지정 환경 파일에 포함된 매개변수는/usr/share/openstack-tripleo-heat-templates/environments/cephadm/cephadm.yaml파일의 해당 기본 설정을 재정의합니다. -
~/templates/storage-config.yaml에parameter_defaults섹션을 추가합니다. 이 섹션에는 오버클라우드의 사용자 정의 설정이 포함되어 있습니다. 선택 사항: 요구 사항에 따라
parameter_defaults아래에 다음 옵션을 설정합니다.옵션 설명 기본값 CinderEnableIscsiBackend
iSCSI 백엔드 활성화
false
CinderEnableRbdBackend
Ceph Storage 백엔드 활성화
true
CinderBackupBackend
ceph 또는 swift를 볼륨 백업의 백엔드로 설정합니다.
Ceph
NovaEnableRbdBackend
Nova 임시 스토리지용 Ceph Storage 사용
true
GlanceBackend
Image 서비스에서 사용할 백엔드(Ceph),
swift또는파일을 정의합니다.rbd
참고기본 설정을 사용하려는 경우
~/templates/storage-config.yaml에서 옵션을 생략할 수 있습니다.
사용자 지정 환경 파일의 내용은 다음 섹션에 적용된 설정에 따라 변경됩니다. 완료된 예제는 를 참조하십시오.
5.3. Ceph 메타데이터 서버 활성화
Ceph Metadata Server(MDS)는 CephFS에 저장된 파일과 관련된 메타데이터를 관리하는 ceph-mds 데몬을 실행합니다. CephFS는 NFS를 통해 사용할 수 있습니다. NFS를 통한 CephFS 사용에 대한 자세한 내용은 파일 시스템 가이드 및 NFS 를 통해 CephFS를 사용하여 공유 파일 시스템 서비스 배포 를 참조하십시오.
Red Hat은 공유 파일 시스템 서비스의 NFS 백엔드를 통해 CephFS에서만 Ceph MDS 배포를 지원합니다.
절차
-
Ceph Metadata Server를 활성화하려면 오버클라우드를 생성할 때 다음 환경 파일을 호출합니다.
/usr/share/openstack-tripleo-heat-templates/environments/cephadm/ceph-mds.yaml
기본적으로 Ceph 메타데이터 서버는 컨트롤러 노드에 배포됩니다. Ceph 메타데이터 서버를 자체 전용 노드에 배포할 수 있습니다.
5.4. Ceph Object Gateway 개체 스토리지
Ceph Object Gateway(RGW)는 Red Hat Ceph Storage 클러스터 내에서 오브젝트 스토리지 기능에 액세스할 수 있는 인터페이스를 제공합니다.
director를 사용하여 Ceph를 배포할 때 director는 Object Storage 서비스(swift)를 직접 대체하는 RGW를 자동으로 활성화합니다. 일반적으로 Swift를 사용하는 다른 모든 서비스는 추가 구성 없이 RGW를 사용할 수 있습니다. Swift는 업그레이드된 Ceph 클러스터에 오브젝트 스토리지 옵션으로 계속 사용할 수 있습니다.
RGW는 기본적으로 활성화되어 있으므로 활성화하기 위해 별도의 RGW 환경 파일이 필요하지 않습니다. 다른 오브젝트 스토리지 옵션에 대해 openstack overcloud deploy 명령에 전달할 수 있는 환경 파일에 대한 자세한 내용은 5.5절. “Red Hat OpenStack Platform 오브젝트 스토리지에 대한 배포 옵션” 을 참조하십시오.
기본적으로 Ceph Storage는 OSD(오브젝트 스토리지 데몬)당 250개의 배치 그룹을 허용합니다. RGW를 활성화하면 Ceph Storage에서 RGW에 필요한 다음 여섯 개의 추가 풀을 생성합니다.
- .rgw.root
- default.rgw.control
- default.rgw.meta
- default.rgw.log
- default.rgw.buckets.index
- default.rgw.buckets.data
배포에서 default 는 풀이 속한 영역의 이름으로 교체됩니다.
추가 리소스
- RGW에 대한 자세한 내용은 Red Hat Ceph Storage Object Gateway Guide 를 참조하십시오.
- Swift 대신 RGW 사용에 대한 자세한 내용은 블록 스토리지 백업 가이드 를 참조하십시오.
5.5. Red Hat OpenStack Platform 오브젝트 스토리지에 대한 배포 옵션
openstack overcloud ceph deploy 명령을 사용하여 Red Hat Ceph Storage 클러스터를 배포한 경우 openstack overcloud deploy 명령을 사용하여 오버클라우드를 배포 합니다. 오버클라우드를 배포하면 다양한 오브젝트 스토리지 옵션에 대해 다른 환경 파일을 openstack overcloud deploy 명령에 전달할 수 있습니다.
5.5.1. Ceph Object Gateway(RGW)를 사용하는 RHOSP 배포
5.4절. “Ceph Object Gateway 개체 스토리지” 에 설명된 대로 RGW를 배포하려면 다음 환경 파일을 포함합니다.
-e environments/cephadm/cephadm.yaml
이 환경은 Ceph 블록 스토리지(RBD) 및 RGW를 둘 다 구성합니다.
5.5.2. RGW 대신 Swift를 사용하여 RHOSP 배포
RGW 대신 Swift 오브젝트 스토리지로 Ceph를 배포하려면 다음 환경 파일을 포함합니다.
-e environments/cephadm/cephadm-rbd-only.yaml
cephadm-rbd-only.yaml 파일은 Ceph RBD를 구성하지만 RGW는 구성하지 않습니다. 이 파일을 사용하는 경우 기본적으로 Swift를 사용하여 오브젝트 스토리지가 설치됩니다.
Red Hat Ceph Storage 클러스터를 업그레이드하기 전에 Swift 오브젝트 스토리지를 사용한 경우 업그레이드 중 environment/cephadm /ceph-ansible.yaml 파일을 로 교체하여 RGW 대신 RGW를 계속 사용할 수 있습니다. 자세한 내용은 업그레이드 설명서를 참조하십시오. RHOSP에서는 Swift에서 RGW로의 마이그레이션을 지원하지 않습니다.
environments/cephadm/cephadm-rbd-only.yaml
5.5.3. 오브젝트 스토리지를 사용하지 않고 RHOSP 배포
RBD가 있지만 RGW 또는 Swift가 아닌 Ceph를 배포하려면 다음 환경 파일을 포함합니다.
-e environments/cephadm/cephadm-rbd-only.yaml -e environments/disable-swift.yaml
cephadm-rbd-only.yaml 파일은 RBD를 구성하지만 RGW는 구성하지 않습니다. disable-swift.yaml 파일을 사용하면 Object Storage 서비스(swift)가 배포되지 않습니다.
5.6. Ceph를 사용하도록 블록 스토리지 백업 서비스 구성
Block Storage Backup 서비스(cinder-backup)는 기본적으로 비활성화되어 있습니다. 블록 스토리지 백업 서비스를 활성화하려면 다음 단계를 완료합니다.
절차
-
오버클라우드를 생성할 때
/usr/share/openstack-tripleo-heat-templates/environments/cinder-backup.yaml을 생성할 때 다음 환경 파일을 호출합니다.
5.7. Ceph 노드를 위한 여러 본딩 인터페이스 구성
결합된 인터페이스를 사용하여 여러 NIC를 결합하고 네트워크 연결에 중복성을 추가합니다. Ceph 노드에 NIC가 충분한 경우 각 노드에 결합된 인터페이스를 여러 개 생성하여 중복 기능을 확장할 수 있습니다.
그런 다음 노드에 필요한 각 네트워크 연결에 본딩된 인터페이스를 사용할 수 있습니다. 중복과 각 네트워크에 대한 전용 연결을 제공합니다.
자세 한 내용은 Director Installation and Usage 가이드의 오버클라우드 네트워크 프로비저닝 을 참조하십시오.
5.8. HCI에 대한 오버클라우드 배포 시작
RHOSP(Red Hat OpenStack Platform) 환경에 대한 변경 사항을 구현하려면 오버클라우드를 배포해야 합니다.
사전 요구 사항
-
언더클라우드 설치 전에
undercloud.conf파일에서generate_service_certificate=false를 설정합니다. 그렇지 않으면 보안 및 Hardening 가이드 의 오버클라우드 공용 끝점에서 SSL/TLS 활성화에 설명된 대로 오버클라우드에서 SSL/TLS를 설정해야 합니다.
오버클라우드 배포 중에 Ceph 대시보드를 추가하려면 director와 함께 Red Hat Ceph Storage 및 Red Hat OpenStack Platform 배포의 오버클라우드 배포에 Red Hat Ceph Storage 대시보드 추가를 참조하십시오.
절차
오버클라우드를 배포합니다. 배포 명령에는 추가 인수가 필요합니다. 예를 들면 다음과 같습니다.
$ openstack overcloud deploy --templates -r /home/stack/templates/roles_data_custom.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/cephadm/cephadm.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/cephadm/ceph-mds.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/cinder-backup.yaml \ -e /home/stack/templates/storage-config.yaml \ -e /home/stack/templates/deployed-ceph.yaml \ --ntp-server pool.ntp.org
예제 명령은 다음 옵션을 사용합니다.
-
--templates- 기본 heat 템플릿 컬렉션/usr/share/openstack-tripleo-heat-templates/에서 오버클라우드를 생성합니다. -
-r /home/stack/templates/roles_data_custom.yaml- 사용자 지정 역할 정의 파일을 지정합니다. -
-e /usr/share/openstack-tripleo-heat-templates/environments/cephadm/cephadm.yaml- director를 이전에 배포한 Ceph Storage 클러스터를 종료하도록 설정합니다. 이 환경 파일은 기본적으로 RGW를 배포합니다. 또한 풀, 키 및 데몬을 생성합니다. -
-e /usr/share/openstack-tripleo-heat-templates/environments/cephadm/ceph-mds.yaml- Ceph Metadata Server를 활성화합니다. -
-e /usr/share/openstack-tripleo-heat-templates/environments/cinder-backup.yaml- Block Storage Backup 서비스를 활성화합니다. -
-e /home/stack/templates/storage-config.yaml- 사용자 지정 Ceph Storage 구성이 포함된 환경 파일을 추가합니다. -
-e /home/stack/templates/deployed-ceph.yaml-openstack overcloud ceph deploy명령의 출력으로 Ceph 클러스터 설정이 포함된 환경 파일을 추가합니다. --NTP-server pool.ntp.org- NTP 서버를 설정합니다.참고전체 옵션 목록은
openstack help overcloud deploy명령을 실행합니다.
-
추가 리소스
6장. HCI 구성 확인
배포가 완료되면 HCI 환경이 올바르게 구성되었는지 확인합니다.
6.1. HCI 구성 확인
HCI 환경을 배포한 후 지정된 구성으로 성공적으로 배포되었는지 확인합니다.
절차
- ceph 쉘을 시작합니다.
NUMA 및 메모리 대상 구성을 확인합니다.
[ceph: root@oc0-controller-0 /]# ceph config dump | grep numa osd advanced osd_numa_auto_affinity true [ceph: root@oc0-controller-0 /]# ceph config dump | grep autotune osd advanced osd_memory_target_autotune true [ceph: root@oc0-controller-0 /]# ceph config get mgr mgr/cephadm/autotune_memory_target_ratio 0.200000
특정 OSD 구성을 확인합니다.
[ceph: root@oc0-controller-0 /]# ceph config get osd.11 osd_memory_target 4294967296 [ceph: root@oc0-controller-0 /]# ceph config get osd.11 osd_memory_target_autotune true [ceph: root@oc0-controller-0 /]# ceph config get osd.11 osd_numa_auto_affinity true
특정 OSD 백필 구성을 확인합니다.
[ceph: root@oc0-controller-0 /]# ceph config get osd.11 osd_recovery_op_priority 3 [ceph: root@oc0-controller-0 /]# ceph config get osd.11 osd_max_backfills 1 [ceph: root@oc0-controller-0 /]# ceph config get osd.11 osd_recovery_max_active_hdd 3 [ceph: root@oc0-controller-0 /]# ceph config get osd.11 osd_recovery_max_active_ssd 10
컴퓨팅 노드에서
reserved_host_memory_mb구성을 확인합니다.$ sudo podman exec -ti nova_compute /bin/bash bash-5.1$ grep reserved_host_memory_mb /etc/nova/nova.conf
7장. 하이퍼컨버지드 노드 확장
HCI 노드를 확장 또는 축소하려면 컴퓨팅 노드 또는 Red Hat Ceph Storage 노드 확장과 동일한 원칙이 적용됩니다.
7.1. HCI 환경에서 하이퍼컨버지드 노드 확장
HCI 환경에서 하이퍼컨버지드 노드를 확장하려면 비하이퍼 컨버지드 노드를 확장하는 것과 동일한 절차를 따릅니다. 자세한 내용은 오버클라우드에 노드 추가를 참조하십시오.
새 노드에 태그를 지정하는 경우 오른쪽 플레이버를 사용해야 합니다.
7.2. HCI 환경에서 하이퍼컨버지드 노드 축소
HCI 환경에서 하이퍼컨버지드 노드를 축소하려면 HCI 노드에서 Ceph OSD 서비스를 재조정하고, HCI 노드에서 인스턴스를 마이그레이션하고, 오버클라우드에서 컴퓨팅 노드를 삭제해야 합니다.
절차
- HCI 노드에서 Ceph OSD 서비스를 비활성화하고 리밸런스합니다. HCI 또는 Red Hat Ceph Storage 노드를 제거할 때 director가 Red Hat Ceph Storage 클러스터를 자동으로 재조정하지 않기 때문에 이 단계가 필요합니다. 자세한 내용은 director와 Red Hat Ceph Storage 및 Red Hat OpenStack Platform 배포에서 Ceph Storage 클러스터 스케일링 을 참조하십시오.
- HCI 노드에서 인스턴스를 마이그레이션합니다. 자세한 내용은 Configuring the Compute Service for Instance Creation 가이드의 Compute 노드 간에 가상 머신 마이그레이션을 참조하십시오.
- 오버클라우드에서 컴퓨팅 노드를 삭제합니다. 자세한 내용은 컴퓨팅 노드 제거 를 참조하십시오.
부록 A. 추가 정보
A.1. 하이퍼컨버지드 인프라 환경의 구성에 대한 가이드 및 리소스
다음 가이드에는 하이퍼컨버지드 인프라 환경의 구성을 지원할 수 있는 추가 정보 및 절차가 포함되어 있습니다.
director와 함께 Red Hat Ceph 및 OpenStack 배포
- 이 가이드에서는 Red Hat OpenStack Platform director를 사용하여 Red Hat Ceph Storage 클러스터에서 오버클라우드를 생성하는 방법에 대한 정보를 제공합니다. 여기에는 director를 통해 Ceph 클러스터를 사용자 정의하는 지침이 포함됩니다.
- 이 가이드에서는 Red Hat OpenStack Platform 환경의 엔드 투 엔드 배포에 대한 지침을 제공합니다. 여기에는 director 설치, 환경 계획, director를 사용한 OpenStack 환경 구축 작업이 포함됩니다.
- 이 가이드에서는 Red Hat OpenStack Platform 네트워킹 작업에 대해 자세히 설명합니다.
- 이 가이드에서는 Red Hat OpenStack Platform 환경에서 영구 스토리지를 사용하고 관리하는 다양한 절차에 대해 자세히 설명합니다. 여기에는 각 영구 스토리지 유형의 각 OpenStack 서비스를 구성하고 관리하는 절차도 포함되어 있습니다.
- 이 가이드에서는 Red Hat OpenStack Platform 환경의 오버클라우드에서 베어 메탈 프로비저닝 서비스의 설치 및 구성에 대해 자세히 설명하여 클라우드 사용자를 위한 물리적 시스템을 프로비저닝 및 관리합니다.
- 이 가이드에서는 Red Hat OpenStack Platform 환경의 보안 강화에 대한 유용한 조언과 개념적 정보를 제공합니다.
- 이 문서에서는 Red Hat OpenStack Platform의 주요 기능, 기능 향상 및 알려진 문제에 대해 간단히 설명합니다.