절차

1. /home/stack/undercloud.conf 파일에 다음 설정을 추가합니다.

   clean_nodes=true

2. 이 옵션을 설정한 후 openstack undercloud install 명령을 실행하여 이 구성 변경을 실행합니다.

   주의

   wipefs --force --all 명령은 디스크의 모든 데이터와 메타데이터를 삭제하지만 안전한 지우기를 수행하지는 않습니다. 보안 지우는 시간이 훨씬 더 오래 걸립니다.

절차

1. director가 노드와 통신할 수 있도록 JSON 형식의 노드 인벤토리 파일(instackenv.json)을 director로 가져옵니다. 이 인벤토리 파일에는 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"
           }
       ]
   }

2. 인벤토리 파일을 생성한 후 stack 사용자의 홈 디렉터리(/home/stack/instackenv.json)에 파일을 저장합니다.

3. stack 사용자를 초기화한 다음 instackenv.json 인벤토리 파일을 director로 가져옵니다.

   $ source ~/stackrc
   $ openstack overcloud node import ~/instackenv.json

   openstack overcloud node import 명령은 인벤토리 파일을 가져와 각 노드를 director에 등록합니다.

4. 커널 및 ramdisk 이미지를 각 노드에 할당합니다.

   $ openstack overcloud node configure <node>

   노드가 director에 등록되어 구성됩니다.

절차

1. 하드웨어 인트로스펙션을 트리거하여 각 노드의 하드웨어 속성을 검색합니다.

   $ openstack overcloud node introspect --all-manageable --provide

   • all -manageable 옵션은 관리 상태에 있는 노드만 인트로스펙션합니다. 이 예에서는 모든 노드가 관리 상태에 있습니다.

   • --provide 옵션은 인트로스펙션 후 모든 노드를 active 상태로 재설정합니다.

     중요

     이 프로세스가 성공적으로 완료되었는지 확인합니다. 베어 메탈 노드의 경우 이 프로세스는 일반적으로 15분 정도 걸립니다.

2. 노드 목록을 검색하여 UUID를 확인합니다.

   $ openstack baremetal node list

3. profile 옵션을 각 노드의 properties/capabilities 매개변수에 추가하여 특정 프로필에 노드를 수동으로 태그합니다. profile 옵션을 추가하면 각 프로필에 노드를 태그합니다.

   참고

   수동 태그 대신 AHC(Automated Health Check) 툴을 사용하여 벤치마킹 데이터를 기반으로 다수의 노드에 자동으로 태그를 지정합니다.

   예를 들어 일반적인 배포에는 세 개의 프로필, 즉 control,compute, ceph-storage 가 포함되어 있습니다. 다음 명령을 입력하여 각 프로필에 대해 세 개의 노드를 태그합니다.

   $ openstack baremetal node set --property capabilities='profile:control,boot_option:local' 1a4e30da-b6dc-499d-ba87-0bd8a3819bc0
   $ openstack baremetal node set --property capabilities='profile:control,boot_option:local' 6faba1a9-e2d8-4b7c-95a2-c7fbdc12129a
   $ openstack baremetal node set --property capabilities='profile:control,boot_option:local' 6faba1a9-e2d8-4b7c-95a2-c7fbdc12129a
   $ openstack baremetal node set --property capabilities='profile:compute,boot_option:local' 484587b2-b3b3-40d5-925b-a26a2fa3036f
   $ openstack baremetal node set --property capabilities='profile:compute,boot_option:local' d010460b-38f2-4800-9cc4-d69f0d067efe
   $ openstack baremetal node set --property capabilities='profile:compute,boot_option:local' d930e613-3e14-44b9-8240-4f3559801ea6
   $ openstack baremetal node set --property capabilities='profile:ceph-storage,boot_option:local' 484587b2-b3b3-40d5-925b-a26a2fa3036f
   $ openstack baremetal node set --property capabilities='profile:ceph-storage,boot_option:local' d010460b-38f2-4800-9cc4-d69f0d067efe
   $ openstack baremetal node set --property capabilities='profile:ceph-storage,boot_option:local' d930e613-3e14-44b9-8240-4f3559801ea6

절차

1. 각 노드의 하드웨어 인트로스펙션에서 디스크 정보를 확인합니다. 다음 명령을 실행하여 노드의 디스크 정보를 표시합니다.

   (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"
     }
   ]

2. openstack baremetal node set --property root_device=를 입력하여 노드의 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

   참고

   각 노드의 BIOS를 설정하여 선택한 root 디스크로 부팅이 포함되도록 합니다. 먼저 네트워크에서 부팅한 다음 root 디스크에서 부팅하도록 부팅 순서를 구성합니다.

   director가 root 디스크로 사용할 특정 디스크를 식별합니다. openstack overcloud deploy 명령을 실행하면 director가 오버클라우드 이미지를 프로비저닝하고 root 디스크에 씁니다.

절차

1. overcloud-minimal 이미지를 사용하도록 director를 구성하려면 다음 이미지 정의가 포함된 환경 파일을 생성합니다.

   parameter_defaults:
     <roleName>Image: overcloud-minimal

2. <roleName>을 역할 이름으로 바꾸고 Image를 역할의 이름에 추가합니다. 다음 예에서는 Ceph 스토리지 노드의 overcloud-minimal 이미지를 보여줍니다.

   parameter_defaults:
     CephStorageImage: overcloud-minimal

3. roles_data.yaml 역할 정의 파일에서 rhsm_enforce 매개변수를 False로 설정합니다.

   rhsm_enforce: False

4. openstack overcloud deploy 명령에 환경 파일을 전달합니다.

절차

1. 사용자 지정 역할을 추가할 수 있도록 /home/stack/templates/ 에 roles_data.yaml 파일의 사본을 만듭니다.

   $ cp /usr/share/openstack-tripleo-heat-templates/roles_data.yaml /home/stack/templates/roles_data_custom.yaml

2. openstack overcloud deploy 명령에 새 사용자 지정 역할 파일을 포함합니다.

절차

1. /home/stack/templates/roles_data_custom.yaml 파일을 엽니다.
2. Controller 역할에서 Ceph MON 서비스, OS::TripleO::Services::CephMon 의 서비스 항목을 제거합니다.

3. 컨트롤러 역할에 OS::TripleO::Services::CephClient 서비스를 추가합니다.

   [...]
   - name: Controller # the 'primary' role goes first
     CountDefault: 1
     ServicesDefault:
       - OS::TripleO::Services::CACerts
       - OS::TripleO::Services::CephMds
       - OS::TripleO::Services::CephClient
       - OS::TripleO::Services::CephExternal
       - OS::TripleO::Services::CephRbdMirror
       - OS::TripleO::Services::CephRgw
       - OS::TripleO::Services::CinderApi
   [...]

4. roles_data_custom.yaml 파일 끝에 Ceph MON 서비스 및 기타 필요한 모든 노드 서비스가 포함된 사용자 지정 CephMon 역할을 추가합니다.

   - name: CephMon
     ServicesDefault:
       # Common Services
       - OS::TripleO::Services::AuditD
       - OS::TripleO::Services::CACerts
       - OS::TripleO::Services::CertmongerUser
       - OS::TripleO::Services::Collectd
       - OS::TripleO::Services::Docker
       - OS::TripleO::Services::FluentdClient
       - OS::TripleO::Services::Kernel
       - OS::TripleO::Services::Ntp
       - OS::TripleO::Services::ContainersLogrotateCrond
       - OS::TripleO::Services::SensuClient
       - OS::TripleO::Services::Snmp
       - OS::TripleO::Services::Timezone
       - OS::TripleO::Services::TripleoFirewall
       - OS::TripleO::Services::TripleoPackages
       - OS::TripleO::Services::Tuned
       # Role-Specific Services
       - OS::TripleO::Services::CephMon

5. openstack flavor create 명령을 입력하여 CephMon 역할에 대해 ceph-mon 이라는 새 플레이버를 정의합니다.

   $ openstack flavor create --id auto --ram 6144 --disk 40 --vcpus 4 ceph-mon

   참고

   이 명령에 대한 자세한 내용은 openstack flavor create --help 를 입력합니다.

6. 이 플레이버를 ceph-mon 이라는 새 프로필에 매핑합니다.

   $ openstack flavor set --property "cpu_arch"="x86_64" --property "capabilities:boot_option"="local" --property "capabilities:profile"="ceph-mon" ceph-mon

   참고

   이 명령에 대한 자세한 내용은 openstack flavor set --help 를 입력합니다.

7. 노드를 새 ceph-mon 프로필에 태그합니다.

   $ openstack baremetal node set --property capabilities='profile:ceph-mon,boot_option:local' UUID

8. 다음 구성을 node-info.yaml 파일에 추가하여 ceph-mon 플레이버를 CephMon 역할과 연결합니다.

   parameter_defaults:
     OvercloudCephMonFlavor: CephMon
     CephMonCount: 3

절차

1. /home/stack/templates/roles_data_custom.yaml 파일을 엽니다.

2. Controller 역할에서 Ceph MDS 서비스, OS::TripleO::Services::CephMds 의 서비스 항목을 제거합니다.

   [...]
   - name: Controller # the 'primary' role goes first
     CountDefault: 1
     ServicesDefault:
       - OS::TripleO::Services::CACerts
       # - OS::TripleO::Services::CephMds 1
       - OS::TripleO::Services::CephMon
       - OS::TripleO::Services::CephExternal
       - OS::TripleO::Services::CephRbdMirror
       - OS::TripleO::Services::CephRgw
       - OS::TripleO::Services::CinderApi
   [...]

   1

   이 줄을 주석 처리하십시오. 다음 단계에서는 새 사용자 지정 역할에 이 서비스를 추가합니다.

3. roles_data_custom.yaml 파일 끝에 Ceph MDS 서비스 및 기타 필요한 모든 노드 서비스가 포함된 사용자 지정 CephMDS 역할을 추가합니다.

   - name: CephMDS
     ServicesDefault:
       # Common Services
       - OS::TripleO::Services::AuditD
       - OS::TripleO::Services::CACerts
       - OS::TripleO::Services::CertmongerUser
       - OS::TripleO::Services::Collectd
       - OS::TripleO::Services::Docker
       - OS::TripleO::Services::FluentdClient
       - OS::TripleO::Services::Kernel
       - OS::TripleO::Services::Ntp
       - OS::TripleO::Services::ContainersLogrotateCrond
       - OS::TripleO::Services::SensuClient
       - OS::TripleO::Services::Snmp
       - OS::TripleO::Services::Timezone
       - OS::TripleO::Services::TripleoFirewall
       - OS::TripleO::Services::TripleoPackages
       - OS::TripleO::Services::Tuned
       # Role-Specific Services
       - OS::TripleO::Services::CephMds
       - OS::TripleO::Services::CephClient 1

   1

   Ceph MDS 서비스에는 Ceph MON 또는 Ceph 클라이언트 서비스로 설정할 수 있는 관리자 인증 키가 필요합니다. Ceph MON 서비스 없이 전용 노드에 Ceph MDS를 배포하는 경우 새 Ceph MDS 역할에 Ceph 클라이언트 서비스도 포함해야 합니다.

4. openstack flavor create 명령을 입력하여 이 역할에 대해 ceph-mds 라는 새 플레이버를 정의합니다.

   $ openstack flavor create --id auto --ram 6144 --disk 40 --vcpus 4 ceph-mds

   참고

   이 명령에 대한 자세한 내용은 openstack flavor create --help 를 입력합니다.

5. ceph-mds 라는 새 프로필에 새 ceph-mds 플레이버를 매핑합니다.

   $ openstack flavor set --property "cpu_arch"="x86_64" --property "capabilities:boot_option"="local" --property "capabilities:profile"="ceph-mds" ceph-mds

   참고

   이 명령에 대한 자세한 내용은 openstack flavor set --help 를 입력합니다.

6. 노드를 새 ceph-mds 프로필에 태그합니다.

   $ openstack baremetal node set --property capabilities='profile:ceph-mds,boot_option:local' UUID

절차

1. 다음 parameter_defaults 를 사용자 지정 환경 파일(예: swift-external-params.yaml )에 추가하고 배포에 맞게 값을 조정합니다.

   parameter_defaults:
      ExternalSwiftPublicUrl: 'http://<Public RGW endpoint or loadbalancer>:8080/swift/v1/AUTH_%(project_id)s'
      ExternalSwiftInternalUrl: 'http://<Internal RGW endpoint>:8080/swift/v1/AUTH_%(project_id)s'
      ExternalSwiftAdminUrl: 'http://<Admin RGW endpoint>:8080/swift/v1/AUTH_%(project_id)s'
      ExternalSwiftUserTenant: 'service'
      SwiftPassword: 'choose_a_random_password'

   참고

   예제 코드 스니펫에는 해당 환경에서 사용하는 값과 다를 수 있는 매개변수 값이 포함되어 있습니다.

   • 원격 RGW 인스턴스가 수신 대기하는 기본 포트는 8080 입니다. 포트는 외부 RGW 구성 방법에 따라 다를 수 있습니다.
   • Overcloud에서 생성된 swift 사용자는 SwiftPassword 매개 변수로 정의된 암호를 사용합니다. rgw_keystone_admin_password 를 사용하여 ID 서비스를 인증하도록 동일한 암호를 사용하도록 외부 RGW 인스턴스를 구성해야 합니다.

2. 다음 코드를 Ceph 구성 파일에 추가하여 ID 서비스를 사용하도록 RGW를 구성합니다. 환경에 맞게 변수 값을 바꿉니다.

       rgw_keystone_api_version = 3
       rgw_keystone_url = http://<public Keystone endpoint>:5000/
       rgw_keystone_accepted_roles = member, Member, admin
       rgw_keystone_accepted_admin_roles = ResellerAdmin, swiftoperator
       rgw_keystone_admin_domain = default
       rgw_keystone_admin_project = service
       rgw_keystone_admin_user = swift
       rgw_keystone_admin_password = <password_as_defined_in_the_environment_parameters>
       rgw_keystone_implicit_tenants = true
       rgw_keystone_revocation_interval = 0
       rgw_s3_auth_use_keystone = true
       rgw_swift_versioning_enabled = true
       rgw_swift_account_in_url = true

   참고

   director는 기본적으로 ID 서비스에 다음 역할 및 사용자를 생성합니다.

   • rgw_keystone_accepted_admin_roles: ResellerAdmin, swiftoperator
   • rgw_keystone_admin_domain: default
   • rgw_keystone_admin_project: service
   • rgw_keystone_admin_user: swift

3. 배포와 관련된 기타 환경 파일을 사용하여 추가 환경 파일을 사용하여 오버클라우드를 배포합니다.

   openstack overcloud deploy --templates \
   -e <your_environment_files>
   -e /usr/share/openstack-tripleo-heat-templates/environments/swift-external.yaml
   -e swift-external-params.yaml

검증

1. stack 사용자로 언더클라우드에 로그인합니다.

2. overcloudrc 파일을 소싱합니다.

   $ source ~/stackrc

3. 엔드포인트가 ID 서비스(keystone)에 있는지 확인합니다.

   $ openstack endpoint list --service object-store
   
   +---------+-----------+-------+-------+---------+-----------+---------------+
   | ID | Region    | Service Name | Service Type | Enabled | Interface | URL |
   +---------+-----------+-------+-------+---------+-----------+---------------+
   | 233b7ea32aaf40c1ad782c696128aa0e | regionOne | swift | object-store | True    | admin     | http://192.168.24.3:8080/v1/AUTH_%(project_id)s |
   | 4ccde35ac76444d7bb82c5816a97abd8 | regionOne | swift | object-store | True    | public    | https://192.168.24.2:13808/v1/AUTH_%(project_id)s |
   | b4ff283f445348639864f560aa2b2b41 | regionOne | swift | object-store | True    | internal  | http://192.168.24.3:8080/v1/AUTH_%(project_id)s |
   +---------+-----------+-------+-------+---------+-----------+---------------+

4. 테스트 컨테이너를 생성합니다.

   $ openstack container create <testcontainer>
   +----------------+---------------+------------------------------------+
   | account | container | x-trans-id |
   +----------------+---------------+------------------------------------+
   | AUTH_2852da3cf2fc490081114c434d1fc157 | testcontainer | tx6f5253e710a2449b8ef7e-005f2d29e8 |
   +----------------+---------------+------------------------------------+

5. 구성 파일을 생성하여 데이터를 컨테이너에 업로드할 수 있는지 확인합니다.

   $ openstack object create testcontainer undercloud.conf
   +-----------------+---------------+----------------------------------+
   | object          | container     | etag                             |
   +-----------------+---------------+----------------------------------+
   | undercloud.conf | testcontainer | 09fcffe126cac1dbac7b89b8fd7a3e4b |
   +-----------------+---------------+----------------------------------+

6. 테스트 컨테이너를 삭제합니다.

   $ openstack container delete -r <testcontainer>

절차

1. POOL 을 구성하려는 풀 이름으로 교체합니다.

   parameter_defaults:
     CephPools:
       - name: POOL

2. 다음 중 하나를 수행하여 배치 그룹을 구성합니다.

   • 기본 설정을 수동으로 재정의하려면 pg_num 을 배치 그룹 수로 설정합니다.

     parameter_defaults:
       CephPools:
         - name: POOL
           pg_num: 128
           application: rbd

   • 또는 배치 그룹을 자동으로 확장하려면 pg_autoscale_mode 를 True 로 설정하고 target_size_ratio 를 예상 Ceph 스토리지 요구 사항에 비해 백분율로 설정합니다.

     parameter_defaults:
       CephPools:
         - name: POOL
           pg_autoscale_mode: True
           target_size_ratio: PERCENTAGE
           application: rbd

     PERCENTAGE 를 10진수로 바꿉니다. 예를 들어 0.5는 50%와 같습니다. 총 백분율은 1.0 또는 100 %와 같아야합니다.

     예를 들어 다음 값은 다음과 같습니다.

     paramter_defaults:
       CephPools:
         - {"name": backups, "target_size_ratio": 0.1, "pg_autoscale_mode": True, "application": rbd}
         - {"name": volumes, "target_size_ratio": 0.5, "pg_autoscale_mode": True, "application": rbd}
         - {"name": vms,     "target_size_ratio": 0.2, "pg_autoscale_mode": True, "application": rbd}
         - {"name": images,  "target_size_ratio": 0.2, "pg_autoscale_mode": True, "application": rbd}

     자세한 내용은 Red Hat Ceph Storage 설치 가이드 의 배치 그룹 자동 확장기 를 참조하십시오.

3. 애플리케이션 유형을 지정합니다.

   Compute, Block Storage, Image Storage의 애플리케이션 유형은'rbd'입니다. 그러나 풀을 사용하는 항목에 따라 다른 애플리케이션 유형을 지정할 수 있습니다.

   예를 들어 gnocchi 지표 풀의 애플리케이션 유형은 openstack_gnocchi 입니다. 자세한 내용은 Enable Application in the Storage Strategies Guide 를 참조하십시오.

   참고

   CephPools 매개변수를 사용하지 않는 경우 director는 기본 풀 목록에 대해서만 적절한 애플리케이션 유형을 자동으로 설정합니다.

4. 선택 사항: custompool 이라는 풀을 추가하여 사용자 지정 풀을 생성하고 환경 요구 사항에 맞는 매개변수를 설정합니다.

   parameter_defaults:
     CephPools:
       - name: custompool
         pg_num: 128
         application: rbd

절차

1. CephAnsibleExtraConfig 매개변수를 업데이트하여 기본 지연 및 재시도 값을 변경합니다.

   parameter_defaults:
     CephAnsibleExtraConfig:
       health_osd_check_delay: 40
       health_osd_check_retries: 30
       health_mon_check_delay: 20
       health_mon_check_retries: 10

   이 예제에서는 클러스터가 30번 검사하고 Ceph OSD를 검사할 때마다 40초 동안 기다린 다음, 각 Ceph MON이 확인될 때까지 10초 동안 20번 기다렸다가 10초 동안 기다립니다.

2. 변경 사항을 통합하려면 openstack overcloud deploy 를 사용하여 -e 로 업데이트된 yaml 파일을 전달합니다.

절차

1. RHOSP에서 Ceph on-wire 암호화를 활성화하려면 새 또는 기존 사용자 지정 환경 파일에서 다음 매개변수를 구성합니다.

   parameter_defaults:
     CephMsgrSecureMode: true

2. 환경 파일을 업데이트한 후 오버클라우드를 다시 배포합니다.

   $ openstack overcloud deploy --templates -e <environment_file>

   이 변경 사항을 구현하면 director가 다음 설정으로 Ceph Storage 클러스터를 구성합니다.

     ms_cluster_mode: secure
     ms_service_mode: secure
     ms_client_mode: secure

절차

1. stack 사용자로 Undercloud 노드에 로그인합니다.
2. Ceph 구성 매개 변수 및 장치 클래스 변수를 포함하도록 /home/stack/templates/ceph-config.yaml 과 같은 환경 파일을 생성합니다. 또는 기존 환경 파일에 다음 구성을 추가할 수 있습니다.

3. 환경 파일에서 CephAnsibleDisksConfig 매개변수를 사용하여 Ceph OSD로 사용하려는 블록 장치를 나열합니다.

   CephAnsibleDisksConfig:
       devices:
         - /dev/sdb
         - /dev/sdc
         - /dev/sdd
       osd_scenario: lvm
       osd_objectstore: bluestore

4. 선택 사항: Ceph는 디스크 유형을 자동으로 탐지하여 해당 장치 클래스에 할당합니다. 그러나 authenticate _device_class 속성을 사용하여 특정 장치가 특정 클래스에 속하거나 고유한 사용자 정의 클래스를 만들 수 있습니다. 다음 예제에는 지정된 클래스와 동일한 OSD 목록이 포함되어 있습니다.

   CephAnsibleDisksConfig:
       lvm_volumes:
         - data: ‘/dev/sdb’
           crush_device_class: ‘hdd’
         - data: ‘/dev/sdc’
           crush_device_class: ‘hdd’
         - data: ‘/dev/sdd’
           crush_device_class: ‘ssd’
       osd_scenario: lvm
       osd_objectstore: bluestore

5. CephAnsibleExtraVars 매개변수를 추가합니다. assets _rules 매개 변수에는 Ceph가 자동으로 탐지하는 각 클래스에 대한 규칙이 포함되어야 합니다. 새 풀을 만들 때 규칙이 지정되지 않은 경우 Ceph가 기본값으로 사용할 규칙을 선택합니다.

   CephAnsibleExtraConfig:
       crush_rule_config: true
       create_crush_tree: true
       crush_rules:
         - name: HDD
           root: default
           type: host
           class: hdd
           default: true
         - name: SSD
           root: default
           type: host
           class: ssd
           default: false

6. CephPools 매개변수를 추가합니다.

   • rule_name 매개 변수를 사용하여 기본 규칙을 사용하지 않는 각 풀의 계층을 지정합니다. 다음 예에서 fastpool 풀은 빠른 계층으로 구성된 SSD 장치 클래스를 사용하여 블록 스토리지 볼륨을 관리합니다.

   • <appropriate_PG_num> 을 적절한 PG(배포 그룹) 수로 바꿉니다. 또는 배치 그룹 자동 확장기를 사용하여 Ceph 풀의 PG 수를 계산합니다.

     자세한 내용은 다른 Ceph 풀에 사용자 지정 속성 할당을 참조하십시오.

   • CinderRbdExtraPools 매개변수를 사용하여 fastpool 을 블록 스토리지 백엔드로 구성합니다.

     CephPools:
       - name: fastpool
         pg_num: <appropraiate_PG_num>
         rule_name: SSD
         application: rbd
     CinderRbdExtraPools: fastpool

7. 다음 예제를 사용하여 환경 파일에 올바른 값이 포함되어 있는지 확인합니다.

   parameter_defaults:
       CephAnsibleDisksConfig:
           devices:
               - '/dev/sdb'
               - '/dev/sdc'
               - '/dev/sdd'
           osd_scenario: lvm
           osd_objectstore: bluestore
       CephAnsibleExtraConfig:
           crush_rule_config: true
           create_crush_tree: true
           crush_rules:
               - name: HDD
                 root: default
                 type: host
                 class: hdd
                 default: true
               - name: SSD
                 root: default
                 type: host
                 class: ssd
                 default: false
       CinderRbdExtraPools: fastpool
       CephPools:
           - name: fastpool
             pg_num: <appropriate_PG_num>
             rule_name: SSD
             application: rbd

8. openstack overcloud deploy 명령에 새 환경 파일을 포함합니다.

   $ openstack overcloud deploy \
   --templates \
   …
   -e <other_overcloud_environment_files> \
   -e /home/stack/templates/ceph-config.yaml  \
   …

   <other_overcloud_environment_files> 를 배포에 포함된 다른 환경 파일 목록으로 바꿉니다.

절차

1. stack 사용자로 Undercloud 노드에 로그인합니다.

2. overcloudrc 파일을 소싱합니다.

   $ source overcloudrc

3. 블록 스토리지 볼륨 기존 유형을 확인합니다.

   $ cinder type-list

4. 새 Block Storage 볼륨 fast_tier를 만듭니다.

   $ cinder type-create fast_tier

5. Block Storage 유형이 생성되었는지 확인합니다.

   $ cinder type-list

6. fast_tier 블록 스토리지 유형을 사용할 수 있으면 fastpool 을 생성한 새 계층의 블록 스토리지 볼륨 백엔드로 설정합니다.

   $ cinder type-key fast_tier set volume_backend_name=tripleo_ceph_fastpool

7. 새 계층을 사용하여 새 볼륨을 생성합니다.

   $ cinder create 1 --volume-type fast_tier --name fastdisk

절차

1. 오버클라우드 컨트롤러 노드에 heat-admin 사용자로 로그인합니다.

2. OSD 계층이 성공적으로 설정되었는지 확인하려면 다음 명령을 입력합니다. <controller_hostname> 을 호스트 컨트롤러 노드 이름으로 바꿉니다.

   $ sudo podman exec -it ceph-mon-<controller_hostname> ceph osd tree

3. 결과 트리 보기에서 CLASS 열에 설정한 각 OSD에 대해 올바른 장치 클래스가 표시되는지 확인합니다.

4. 또한 다음 명령을 사용하여 OSD가 장치 클래스에 올바르게 할당되었는지 확인합니다. <controller_hostname> 을 호스트 컨트롤러 노드 이름으로 바꿉니다.

   $ sudo podman exec -it ceph-mon-<controller_hostname> ceph osd crush tree --show-shadow

5. 결과 계층 구조를 다음 명령의 결과와 비교하여 각 규칙에 대해 동일한 값이 적용되는지 확인합니다.

   • <controller_hostname> 을 호스트 컨트롤러 노드 이름으로 바꿉니다.

   • <rule_name>을 확인하려는 규칙의 이름으로 바꿉니다.

     $ sudo podman exec <controller_hostname> ceph osd crush rule dump <rule_name>

6. 생성한 규칙 이름과 ID가 배포 중에 사용한 convention _rules 매개변수에 따라 올바른지 확인합니다. <controller_hostname> 을 호스트 컨트롤러 노드 이름으로 바꿉니다.

   $ sudo podman exec -it ceph-mon-<controller_hostname>  ceph osd crush rule dump | grep -E "rule_(id|name)"

7. Ceph 풀이 3단계에서 검색한 올바른 CRUSH 규칙 ID에 연결되어 있는지 확인합니다. <controller_hostname> 을 호스트 컨트롤러 노드 이름으로 바꿉니다.

   $ sudo podman exec -it ceph-mon-<controller_hostname> ceph osd dump | grep pool

8. 각 풀에 대해 규칙 ID가 예상 규칙 이름과 일치하는지 확인합니다.

절차

1. stack 사용자로 언더클라우드 호스트에 로그인합니다.

2. 기본 컨테이너 이미지 준비 파일을 생성합니다.

   $ sudo openstack tripleo container image prepare default \
     --local-push-destination \
     --output-env-file containers-prepare-parameter.yaml

3. containers-prepare-parameter.yaml 파일을 편집하고 요구 사항에 맞게 수정합니다. 다음 예제 containers-prepare-parameter.yaml 파일에는 Grafana, Prometheus, Alertmanager, Node Exporter를 포함하여 대시보드 서비스와 관련된 이미지 위치 및 태그가 포함되어 있습니다. 특정 시나리오에 따라 값을 편집합니다.

   parameter_defaults:
       ContainerImagePrepare:
       - push_destination: true
           set:
               ceph_alertmanager_image: ose-prometheus-alertmanager
               ceph_alertmanager_namespace: registry.redhat.io/openshift4
               ceph_alertmanager_tag: v4.6
               ceph_grafana_image: rhceph-4-dashboard-rhel8
               ceph_grafana_namespace: registry.redhat.io/rhceph
               ceph_grafana_tag: 4
               ceph_image: rhceph-4-rhel8
               ceph_namespace: registry.redhat.io/rhceph
               ceph_node_exporter_image: ose-prometheus-node-exporter
               ceph_node_exporter_namespace: registry.redhat.io/openshift4
               ceph_node_exporter_tag: v4.6
               ceph_prometheus_image: ose-prometheus
               ceph_prometheus_namespace: registry.redhat.io/openshift4
               ceph_prometheus_tag: v4.6
               ceph_tag: latest

절차

1. stack 사용자로 Undercloud 노드에 로그인합니다.

2. 선택 사항: Ceph 대시보드 네트워크는 기본적으로 provisioning 네트워크로 설정됩니다. Ceph 대시보드를 배포하고 다른 네트워크를 통해 액세스하려면 환경 파일을 만듭니다(예: ceph_dashboard_network_override.yaml ). CephDashboardNetwork 를 기존 오버클라우드 라우팅 네트워크(예: ctlplane ) 중 하나로 설정합니다.

     parameter_defaults:
        CephDashboardNetwork: ctlplane

3. openstack overcloud deploy 명령에 다음 환경 파일을 포함합니다. 배포의 일부인 모든 환경 파일과 기본 네트워크를 변경하기로 선택한 경우 ceph_dashboard_network_override.yaml 파일을 포함합니다.

   $ openstack overcloud deploy \
    --templates \
    -e <overcloud_environment_files> \
    -e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml \
    -e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-dashboard.yaml
    -e ceph_dashboard_network_override.yaml

   <overcloud_environment_files> 를 배포에 포함된 환경 파일 목록으로 바꿉니다.

   결과

   결과 배포는 grafana, prometheus, alertmanager 및 node-exporter 컨테이너가 있는 외부 스택으로 구성됩니다. Ceph Dashboard Manager 모듈은 이 스택의 백엔드이며, 최종 사용자에게 ceph 클러스터별 지표를 제공하기 위해 grafana 레이아웃을 포함합니다.

절차

1. stack 사용자로 언더클라우드에 로그인합니다.

2. 대시보드 구성 가능 네트워크를 포함하도록 컨트롤러 특정 역할을 생성합니다.

   $ openstack overcloud roles generate -o /home/stack/roles_data_dashboard.yaml ControllerStorageDashboard Compute BlockStorage ObjectStorage CephStorage

   결과

   • 명령의 출력으로 정의된 roles_data.yaml 내부에 새 ControllerStorageDashboard 역할이 생성됩니다. overcloud deploy 명령을 사용할 때 이 파일을 템플릿 목록에 포함해야 합니다.

     알림: ControllerStorageDashboard 역할에 CephNFS 또는 network_data_dashboard.yaml 이 포함되지 않습니다.

   • director는 구성 가능 네트워크가 정의된 네트워크 환경 파일을 제공합니다. 이 파일의 기본 위치는 /usr/share/openstack-tripleo-heat-templates/network_data_dashboard.yaml 입니다. 오버클라우드 배포 명령을 사용할 때 오버클라우드 템플릿 목록에 이 파일을 포함해야 합니다.

3. openstack overcloud deploy 명령에 배포에 포함된 모든 환경 파일을 사용하여 다음 환경 파일을 포함합니다.

   $ openstack overcloud deploy \
     --templates \
     -r /home/stack/roles_data.yaml \
     -n /usr/share/openstack-tripleo-heat-templates/network_data_dashboard.yaml \
     -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
     -e /usr/share/openstack-tripleo-heat-templates/environments/network-environment.yaml \
     -e <overcloud_environment_files> \
     -e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml \
     -e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-dashboard.yaml

   <overcloud_environment_files> 를 배포에 포함된 환경 파일 목록으로 바꿉니다.

   결과

   결과 배포는 grafana, prometheus, alertmanager 및 node-exporter 컨테이너가 있는 외부 스택으로 구성됩니다. Ceph Dashboard Manager 모듈은 이 스택의 백엔드이며, 최종 사용자에게 Ceph 클러스터별 지표를 제공하기 위해 grafana 레이아웃을 포함합니다.

절차

1. stack 사용자로 언더클라우드에 로그인합니다.

2. 다음 ceph_dashboard_admin.yaml 환경 파일을 생성합니다.

     parameter_defaults:
        CephDashboardAdminRO: false

3. 오버클라우드 배포 명령을 실행하여 기존 스택을 업데이트하고 기존 배포의 일부인 다른 모든 환경 파일과 함께 환경 파일을 포함합니다.

   $ openstack overcloud deploy \
   --templates \
   -e <existing_overcloud_environment_files> \
   -e ceph_dashboard_admin.yml

   <existing_overcloud_environment_files> 를 기존 배포의 일부인 환경 파일 목록으로 바꿉니다.

절차

1. stack 사용자로 Undercloud 노드에 로그인합니다.

2. 대시보드 관리자 로그인 자격 증명을 검색합니다.

   [stack@undercloud ~]$ grep dashboard_admin_password /var/lib/mistral/overcloud/ceph-ansible/group_vars/all.yml

3. VIP 주소를 검색하여 Ceph 대시보드에 액세스합니다.

   [stack@undercloud-0 ~]$ grep dashboard_frontend_vip /var/lib/mistral/overcloud/ceph-ansible/group_vars/all.yml

4. 웹 브라우저를 사용하여 프론트엔드 VIP를 가리키고 대시보드에 액세스합니다. director는 프로비저닝 네트워크에서 대시보드를 구성하고 노출하므로 검색한 VIP를 사용하여 TCP 포트 8444에서 대시보드에 직접 액세스할 수 있습니다. 다음 조건이 충족되었는지 확인합니다.

   • 웹 클라이언트 호스트는 프로비저닝 네트워크에 연결된 계층 2입니다.

   • 프로비저닝 네트워크는 올바르게 라우팅되거나 프록시되며, 웹 클라이언트 호스트에서 연결할 수 있습니다. 이러한 조건이 충족되지 않은 경우 SSH 터널을 열어 오버클라우드의 대시보드 VIP에 도달할 수 있습니다.

     client_host$ ssh -L 8444:<dashboard_vip>:8444 stack@<your undercloud>

     <dashboard_vip>를 검색한 컨트롤 플레인 VIP의 IP 주소로 바꿉니다.

5. 대시보드에 액세스하려면 웹 브라우저에서 http://localhost:8444 로 이동하여 다음 세부 정보를 사용하여 로그인합니다.

   • ceph-ansible 이 생성하는 기본 사용자 admin.

   • /var/lib/mistral/overcloud/ceph-ansible/group_vars/all.yml 의 암호.

     결과

   • Ceph 대시보드에 액세스할 수 있습니다.
   • 대시보드에서 표시하는 숫자와 그래프는 CLI 명령인 ceph -s 가 반환하는 것과 동일한 클러스터 상태를 반영합니다.

1. 이 파일을 사용하려면 다음 명령을 실행합니다.

   $ source ~/overcloudrc

2. 이렇게 하면 언더클라우드 CLI에서 오버클라우드와 상호 작용하는 데 필요한 환경 변수가 로드됩니다. 언더클라우드와 상호 작용으로 돌아가려면 다음 명령을 실행합니다.

   $ source ~/stackrc

절차

1. 컨트롤러 노드에 heat-admin 사용자로 로그인합니다.

   $ nova list
   $ ssh heat-admin@192.168.0.25

2. 클러스터 상태를 확인합니다.

   $ sudo podman exec ceph-mon-<HOSTNAME> ceph health

   클러스터에 문제가 없는 경우 명령에서 HEALTH_OK 를 다시 보고합니다. 즉, 클러스터가 안전하게 사용할 수 있습니다.

3. Ceph 모니터 서비스를 실행하는 오버클라우드 노드에 로그인하고 클러스터의 모든 OSD 상태를 확인합니다.

   $ sudo podman exec ceph-mon-<HOSTNAME> ceph osd tree

4. Ceph Monitor 쿼럼의 상태를 확인합니다.

   $ sudo podman exec ceph-mon-<HOSTNAME> ceph quorum_status

   쿼럼에 참여하는 모니터와 리더를 보여줍니다.

5. 모든 Ceph OSD가 실행 중인지 확인합니다.

   $ sudo podman exec ceph-mon-<HOSTNAME> ceph osd stat

절차

1. ceph-mon 서비스를 실행하는 Ceph Monitor 또는 컨트롤러 노드에 로그인하고 Ceph Storage 클러스터 재조정을 일시적으로 비활성화합니다.

   $ sudo podman exec -it ceph-mon-controller-0 ceph osd set noout
   $ sudo podman exec -it ceph-mon-controller-0 ceph osd set norebalance

   참고

   다중 스택 또는 DCN(Distributed Compute node) 아키텍처가 있는 경우 noout 및 norebalance 플래그를 설정할 때 클러스터 이름을 지정해야 합니다. 예: sudo podman exec -it ceph-mon-controller-0 ceph osd set noout --cluster_name>

2. 재부팅할 첫 번째 Ceph Storage 노드를 선택하고 노드에 로그인합니다.

3. 노드를 재부팅합니다.

   $ sudo reboot

4. 노드가 부팅될 때까지 기다립니다.

5. 노드에 로그인하고 클러스터 상태를 확인합니다.

   $ sudo podman exec -it ceph-mon-controller-0 ceph status

   pgmap이 모든 pgs를 정상(active+clean)으로 보고하는지 확인합니다.

6. 노드에서 로그아웃하고, 다음 노드를 재부팅한 후 상태를 확인합니다. 모든 Ceph Storage 노드가 재부팅될 때까지 이 프로세스를 반복합니다.

7. 완료되면 ceph-mon 서비스를 실행하는 Ceph Monitor 또는 컨트롤러 노드에 로그인하고 클러스터 재조정을 다시 활성화합니다.

   $ sudo podman exec -it ceph-mon-controller-0 ceph osd unset noout
   $ sudo podman exec -it ceph-mon-controller-0 ceph osd unset norebalance

   참고

   다중 스택 또는 DCN(Distributed Compute node) 아키텍처가 있는 경우 noout 및 norebalance 플래그를 설정할 때 클러스터 이름을 지정해야 합니다. 예: sudo podman exec -it ceph-mon-controller-0 ceph osd set noout --cluster_name>

8. 최종 상태 검사를 수행하여 클러스터가 HEALTH_OK를 보고하는지 확인합니다.

   $ sudo podman exec -it ceph-mon-controller-0 ceph status

절차

1. stack 사용자로 언더클라우드에 로그인하고 director 구성을 초기화합니다.

   $ source ~/stackrc

2. 새 노드 정의 템플릿에서 새 노드의 하드웨어 및 전원 관리 세부 정보(예: instackenv-scale.json )를 정의합니다.

3. 이 파일을 director로 가져옵니다.

   $ openstack overcloud node import ~/instackenv-scale.json

   노드 정의 템플릿을 가져오면 해당 노드에 정의된 각 노드가 director에 등록됩니다.

4. 커널 및 ramdisk 이미지를 모든 노드에 할당합니다.

   $ openstack overcloud node configure

절차

1. 하드웨어 인트로스펙션을 트리거하여 각 노드의 하드웨어 속성을 검색합니다.

   $ openstack overcloud node introspect --all-manageable --provide

   • all -manageable 옵션은 관리 상태에 있는 노드만 인트로스펙션합니다. 이 예에서는 모든 노드가 관리 상태에 있습니다.

   • --provide 옵션은 인트로스펙션 후 모든 노드를 active 상태로 재설정합니다.

     중요

     이 프로세스가 성공적으로 완료되었는지 확인합니다. 베어 메탈 노드의 경우 이 프로세스는 일반적으로 15분 정도 걸립니다.

2. 노드 목록을 검색하여 UUID를 확인합니다.

   $ openstack baremetal node list

3. profile 옵션을 각 노드의 properties/capabilities 매개변수에 추가하여 특정 프로필에 노드를 수동으로 태그합니다. profile 옵션을 추가하면 각 프로필에 노드를 태그합니다.

   참고

   수동 태그 대신 AHC(Automated Health Check) 툴을 사용하여 벤치마킹 데이터를 기반으로 다수의 노드에 자동으로 태그를 지정합니다. 예를 들어 다음 명령은 ceph-storage 프로필로 세 개의 추가 노드를 태그합니다.

   $ openstack baremetal node set --property capabilities='profile:baremetal,boot_option:local' 551d81f5-4df2-4e0f-93da-6c5de0b868f7
   $ openstack baremetal node set --property capabilities='profile:baremetal,boot_option:local' 5e735154-bd6b-42dd-9cc2-b6195c4196d7
   $ openstack baremetal node set --property capabilities='profile:baremetal,boot_option:local' 1a2b090c-299d-4c20-a25d-57dd21a7085b

절차

1. 오버클라우드를 재배포하기 전에 환경 파일의 parameter_defaults (이 경우 ~/templates/storage-config.yaml )에 CephStorageCount 매개변수를 설정합니다. 7.1절. “역할에 노드 및 플레이버 할당” 에서 오버클라우드는 세 개의 Ceph Storage 노드로 배포되도록 구성되어 있습니다. 다음 예제에서는 오버클라우드를 6개의 노드로 확장합니다.

   parameter_defaults:
     ControllerCount: 3
     OvercloudControlFlavor: control
     ComputeCount: 3
     OvercloudComputeFlavor: compute
     CephStorageCount: 6
     OvercloudCephStorageFlavor: ceph-storage
     CephMonCount: 3
     OvercloudCephMonFlavor: ceph-mon

2. Overcloud를 재배포합니다. 이제 오버클라우드에 3개 대신 6개의 Ceph Storage 노드가 있습니다.

절차

1. 컨트롤러 노드에 heat-admin 사용자로 로그인합니다. director stack 사용자에게는 heat-admin 사용자에 액세스할 수 있는 SSH 키가 있습니다.

2. OSD 트리를 나열하고 노드의 OSD를 찾습니다. 예를 들어 삭제하려는 노드에는 다음 OSD가 포함될 수 있습니다.

   -2 0.09998     host overcloud-cephstorage-0
   0 0.04999         osd.0                         up  1.00000          1.00000
   1 0.04999         osd.1                         up  1.00000          1.00000

3. Ceph Storage 노드에서 OSD를 비활성화합니다. 이 경우 OSD ID는 0과 1입니다.

   [heat-admin@overcloud-controller-0 ~]$ sudo podman exec ceph-mon-<HOSTNAME> ceph osd out 0
   [heat-admin@overcloud-controller-0 ~]$ sudo podman exec ceph-mon-<HOSTNAME> ceph osd out 1

4. Ceph Storage 클러스터는 리밸런싱을 시작합니다. 이 프로세스가 완료될 때까지 기다립니다. 다음 명령을 사용하여 상태를 따릅니다.

   [heat-admin@overcloud-controller-0 ~]$ sudo podman exec ceph-mon-<HOSTNAME> ceph -w

5. Ceph 클러스터 재조정이 완료되면 제거할 Ceph Storage 노드에 heat-admin 사용자로 overcloud-cephstorage-0 에 로그인하고 노드를 중지하고 비활성화합니다.

   [heat-admin@overcloud-cephstorage-0 ~]$ sudo systemctl stop ceph-osd@0
   [heat-admin@overcloud-cephstorage-0 ~]$ sudo systemctl stop ceph-osd@1
   [heat-admin@overcloud-cephstorage-0 ~]$ sudo systemctl disable ceph-osd@0
   [heat-admin@overcloud-cephstorage-0 ~]$ sudo systemctl disable ceph-osd@1

6. OSD를 중지합니다.

   [heat-admin@overcloud-cephstorage-0 ~]$ sudo systemctl stop ceph-osd@0
   [heat-admin@overcloud-cephstorage-0 ~]$ sudo systemctl stop ceph-osd@1

7. 컨트롤러 노드에 로그인하는 동안 더 이상 데이터를 받지 않도록 CRUSH 맵에서 OSD를 제거합니다.

   [heat-admin@overcloud-controller-0 ~]$ sudo podman exec ceph-mon-<HOSTNAME> ceph osd crush remove osd.0
   [heat-admin@overcloud-controller-0 ~]$ sudo podman exec ceph-mon-<HOSTNAME> ceph osd crush remove osd.1

8. OSD 인증 키를 제거합니다.

   [heat-admin@overcloud-controller-0 ~]$ sudo podman exec ceph-mon-<HOSTNAME> ceph auth del osd.0
   [heat-admin@overcloud-controller-0 ~]$ sudo podman exec ceph-mon-<HOSTNAME> ceph auth del osd.1

9. 클러스터에서 OSD를 제거합니다.

   [heat-admin@overcloud-controller-0 ~]$ sudo podman exec ceph-mon-<HOSTNAME> ceph osd rm 0
   [heat-admin@overcloud-controller-0 ~]$ sudo podman exec ceph-mon-<HOSTNAME> ceph osd rm 1

10. CRUSH 맵에서 Storage 노드를 제거합니다.

    [heat-admin@overcloud-controller-0 ~]$ sudo docker exec ceph-mon-<HOSTNAME> ceph osd crush rm <NODE>
    [heat-admin@overcloud-controller-0 ~]$ sudo ceph osd crush remove <NODE>

    CRUSH 트리를 검색하여 CRUSH 맵에 정의된 <NODE> 이름을 확인할 수 있습니다.

    [heat-admin@overcloud-controller-0 ~]$ sudo podman exec ceph-mon-<HOSTNAME> ceph osd crush tree | grep overcloud-osd-compute-3 -A 4
                    "name": "overcloud-osd-compute-3",
                    "type": "host",
                    "type_id": 1,
                    "items": []
                },
    [heat-admin@overcloud-controller-0 ~]$

    CRUSH 트리에서 items 목록이 비어 있는지 확인합니다. 목록이 비어 있지 않으면 7단계를 다시 방문하십시오.

11. 노드를 종료하고 stack 사용자로 언더클라우드로 돌아갑니다.

    [heat-admin@overcloud-controller-0 ~]$ exit
    [stack@director ~]$

12. Ceph Storage 노드를 비활성화하여 director가 다시 프로비저닝하지 않도록 합니다.

    [stack@director ~]$ openstack baremetal node list
    [stack@director ~]$ openstack baremetal node maintenance set UUID

13. Ceph Storage 노드를 제거하려면 로컬 템플릿 파일을 사용하여 director의 오버클라우드 스택을 업데이트해야 합니다. 먼저 오버클라우드 스택의 UUID를 확인합니다.

    $ openstack stack list

14. 삭제할 Ceph Storage 노드의 UUID를 확인합니다.

    $ openstack server list

15. 스택에서 노드를 삭제하고 그에 따라 계획을 업데이트합니다.

    중요

    오버클라우드를 생성할 때 추가 환경 파일을 전달한 경우 -e 옵션을 사용하여 오버클라우드를 원치 않게 변경하지 않도록 다시 여기에 전달합니다. 자세한 내용은 Director 설치 및 사용 가이드 의 Overcloud 환경 수정을 참조하십시오.

    $ openstack overcloud node delete /
    --stack <stack-name> /
    --templates /
    -e <other-environment-files> /
    <node_UUID>

16. 스택이 업데이트가 완료될 때까지 기다립니다. heat stack-list --show-nested 명령을 사용하여 스택 업데이트를 모니터링합니다.

17. director 노드 풀에 새 노드를 추가하고 Ceph Storage 노드로 배포합니다. 환경 파일의 parameter_defaults 에서 CephStorageCount 매개 변수를 사용하여 ~/templates/storage-config.yaml 을 사용하여 오버클라우드에서 총 Ceph Storage 노드 수를 정의합니다.

    parameter_defaults:
      ControllerCount: 3
      OvercloudControlFlavor: control
      ComputeCount: 3
      OvercloudComputeFlavor: compute
      CephStorageCount: 3
      OvercloudCephStorageFlavor: ceph-storage
      CephMonCount: 3
      OvercloudCephMonFlavor: ceph-mon

    참고

    역할당 노드 수를 정의하는 방법에 대한 자세한 내용은 7.1절. “역할에 노드 및 플레이버 할당” 을 참조하십시오.

18. 환경 파일을 업데이트한 후 오버클라우드를 재배포합니다.

    $ openstack overcloud deploy --templates -e <ENVIRONMENT_FILE>

    director가 새 노드를 프로비저닝하고 새 노드의 세부 정보로 전체 스택을 업데이트합니다.

19. 컨트롤러 노드에 heat-admin 사용자로 로그인하고 Ceph Storage 노드의 상태를 확인합니다.

    [heat-admin@overcloud-controller-0 ~]$ sudo ceph status

20. osdmap 섹션의 값이 원하는 클러스터의 노드 수와 일치하는지 확인합니다. 제거한 Ceph Storage 노드는 새 노드로 교체됩니다.

1. 다음 heat 템플릿은 3개의 OSD 장치가 있는 Ceph Storage를 배포합니다.

   parameter_defaults:
     CephAnsibleDisksConfig:
       devices:
         - /dev/sdb
         - /dev/sdc
         - /dev/sdd
       osd_scenario: lvm
       osd_objectstore: bluestore

2. OSD를 추가하려면 5.3절. “Ceph Storage 노드 디스크 레이아웃 매핑” 에 설명된 대로 노드 디스크 레이아웃을 업데이트합니다. 이 예제에서는 템플릿에 /dev/sde 를 추가합니다.

   parameter_defaults:
     CephAnsibleDisksConfig:
       devices:
         - /dev/sdb
         - /dev/sdc
         - /dev/sdd
         - /dev/sde
       osd_scenario: lvm
       osd_objectstore: bluestore

3. openstack overcloud deploy를 실행하여 Overcloud를 업데이트합니다.

1. ceph-storage0 에 SSH로 연결하고 root 로 로그인합니다.

2. OSD 서비스를 비활성화하고 중지합니다.

   [root@ceph-storage0 ~]# systemctl disable ceph-osd@4
   [root@ceph-stoarge0 ~]# systemctl stop ceph-osd@4

3. ceph-storage0 에서 연결을 끊습니다.
4. controller0 에 SSH로 연결하고 root 로 로그인합니다.

5. Ceph 모니터 컨테이너의 이름을 확인합니다.

   [root@controller0 ~]# podman ps | grep ceph-mon
   ceph-mon-controller0
   [root@controller0 ~]#

6. Ceph 모니터 컨테이너를 활성화하여 바람직하지 않은 OSD를 외부로 표시합니다.

   [root@controller0 ~]# podman exec ceph-mon-controller0 ceph osd out 4

   참고

   이 명령을 사용하면 Ceph에서 스토리지 클러스터를 리밸런싱하고 데이터를 클러스터의 다른 OSD에 복사합니다. 클러스터는 리밸런싱이 완료될 때까지 active+clean 상태를 일시적으로 유지합니다.

7. 다음 명령을 실행하고 스토리지 클러스터 상태가 active+clean 이 될 때까지 기다립니다.

   [root@controller0 ~]# podman exec ceph-mon-controller0 ceph -w

8. 더 이상 데이터를 받지 않도록 CRUSH 맵에서 OSD를 제거합니다.

   [root@controller0 ~]# podman exec ceph-mon-controller0 ceph osd crush remove osd.4

9. OSD 인증 키를 제거합니다.

   [root@controller0 ~]# podman exec ceph-mon-controller0 ceph auth del osd.4

10. OSD를 제거합니다.

    [root@controller0 ~]# podman exec ceph-mon-controller0 ceph osd rm 4

11. controller0 에서 연결을 끊습니다.
12. stack 사용자로 언더클라우드에 SSH로 연결하고 CephAnsibleDisksConfig 매개변수를 정의한 heat 환경 파일을 찾습니다.

13. heat 템플릿에 OSD 4개가 포함되어 있습니다.

    parameter_defaults:
      CephAnsibleDisksConfig:
        devices:
          - /dev/sdb
          - /dev/sdc
          - /dev/sdd
          - /dev/sde
        osd_scenario: lvm
        osd_objectstore: bluestore

14. /dev/sde 를 제거하도록 템플릿을 수정합니다.

    parameter_defaults:
      CephAnsibleDisksConfig:
        devices:
          - /dev/sdb
          - /dev/sdc
          - /dev/sdd
        osd_scenario: lvm
        osd_objectstore: bluestore

15. openstack overcloud deploy를 실행하여 Overcloud를 업데이트합니다.

    참고

    이 예제에서는 OSD가 있는 모든 호스트에서 /dev/sde 장치를 제거합니다. 모든 노드에서 동일한 장치를 제거하지 않으면 heat 템플릿을 업데이트합니다. 다양한 장치 목록을 사용하여 호스트를 정의하는 방법에 대한 자세한 내용은 5.5절. “유사한 Ceph Storage 노드의 매개변수 덮어쓰기” 을 참조하십시오.

절차

1. 실행 중인 Ceph 모니터 컨테이너의 이름을 확인하고 MON 이라는 환경 변수에 저장합니다.

   MON=$(podman ps | grep ceph-mon | awk {'print $1'})

2. 실행 중인 Ceph 모니터 컨테이너 내에서 실행되도록 ceph 명령을 별칭합니다.

   alias ceph="podman exec $MON ceph"

3. 새 별칭을 사용하여 교체할 OSD가 종료되었는지 확인합니다.

   [root@overcloud-controller-0 ~]# ceph osd tree | grep 27
   27   hdd 0.04790         osd.27                    down  1.00000 1.00000

4. OSD를 삭제합니다. 다음 예제 명령은 OSD 27 을 삭제합니다.

   [root@overcloud-controller-0 ~]# ceph osd destroy 27 --yes-i-really-mean-it
   destroyed osd.27

절차

1. 실패한 OSD가 실행 중이 아닌지 확인합니다.

   systemctl stop ceph-osd@27

2. ceph 컨테이너 이미지의 이미지 ID를 식별하고 IMG 라는 환경 변수에 저장합니다.

   IMG=$(podman images | grep ceph | awk {'print $3'})

3. ceph-volume 진입점과 관련 디렉터리를 사용하여 $IMG Ceph 컨테이너 내부에서 실행되도록 ceph-volume 명령을 별칭합니다.

   alias ceph-volume="podman run --rm --privileged --net=host --ipc=host -v /run/lock/lvm:/run/lock/lvm:z -v /var/run/udev/:/var/run/udev/:z -v /dev:/dev -v /etc/ceph:/etc/ceph:z -v /var/lib/ceph/:/var/lib/ceph/:z -v /var/log/ceph/:/var/log/ceph/:z --entrypoint=ceph-volume $IMG --cluster ceph"

4. 별칭 명령이 성공적으로 실행되는지 확인합니다.

   ceph-volume lvm list

5. 새 OSD 장치가 LVM에 포함되어 있지 않은지 확인합니다. pvdisplay 명령을 사용하여 장치를 검사하고 VG Name(VG 이름 ) 필드가 비어 있는지 확인합니다. <NEW_DEVICE> 를 새 OSD 장치의 /dev/* 경로로 바꿉니다.

   [root@overcloud-computehci-2 ~]# pvdisplay <NEW_DEVICE>
     --- Physical volume ---
     PV Name               /dev/sdj
     VG Name               ceph-0fb0de13-fc8e-44c8-99ea-911e343191d2
     PV Size               50.00 GiB / not usable 1.00 GiB
     Allocatable           yes (but full)
     PE Size               1.00 GiB
     Total PE              49
     Free PE               0
     Allocated PE          49
     PV UUID               kOO0If-ge2F-UH44-6S1z-9tAv-7ypT-7by4cp
   [root@overcloud-computehci-2 ~]#

   VG Name(VG 이름 ) 필드가 비어 있지 않으면 장치는 제거해야 하는 볼륨 그룹에 속합니다.

6. 장치가 볼륨 그룹에 속하는 경우 lvdisplay 명령을 사용하여 볼륨 그룹에 논리 볼륨이 있는지 확인합니다. <VOLUME_GROUP> 을 pvdisplay 명령에서 검색한 VG 이름 필드 값으로 바꿉니다.

   [root@overcloud-computehci-2 ~]# lvdisplay | grep <VOLUME_GROUP>
     LV Path                /dev/ceph-0fb0de13-fc8e-44c8-99ea-911e343191d2/osd-data-a0810722-7673-43c7-8511-2fd9db1dbbc6
     VG Name                ceph-0fb0de13-fc8e-44c8-99ea-911e343191d2
   [root@overcloud-computehci-2 ~]#

   LV Path(LV 경로 ) 필드가 비어 있지 않으면 장치에 제거해야 하는 논리 볼륨이 포함됩니다.

7. 새 장치가 논리 볼륨 또는 볼륨 그룹의 일부인 경우 LVM 시스템 내의 물리 볼륨으로 논리 볼륨, 볼륨 그룹 및 장치 연결을 제거합니다.

   • <LV_PATH> 를 LV Path 필드 값으로 바꿉니다.
   • <VOLUME_GROUP> 을 VG 이름 필드 값으로 바꿉니다.

   • <NEW_DEVICE> 를 새 OSD 장치의 /dev/* 경로로 바꿉니다.

     [root@overcloud-computehci-2 ~]# lvremove --force <LV_PATH>
       Logical volume "osd-data-a0810722-7673-43c7-8511-2fd9db1dbbc6" successfully removed

     [root@overcloud-computehci-2 ~]# vgremove --force <VOLUME_GROUP>
       Volume group "ceph-0fb0de13-fc8e-44c8-99ea-911e343191d2" successfully removed

     [root@overcloud-computehci-2 ~]# pvremove <NEW_DEVICE>
       Labels on physical volume "/dev/sdj" successfully wiped.

8. 새 OSD 장치가 정리되었는지 확인합니다. 다음 예에서 장치는 /dev/sdj 입니다.

   [root@overcloud-computehci-2 ~]# ceph-volume lvm zap /dev/sdj
   --> Zapping: /dev/sdj
   --> --destroy was not specified, but zapping a whole device will remove the partition table
   Running command: /usr/sbin/wipefs --all /dev/sdj
   Running command: /bin/dd if=/dev/zero of=/dev/sdj bs=1M count=10
    stderr: 10+0 records in
   10+0 records out
   10485760 bytes (10 MB, 10 MiB) copied, 0.010618 s, 988 MB/s
   --> Zapping successful for: <Raw Device: /dev/sdj>
   [root@overcloud-computehci-2 ~]#

9. ceph-volume 이 OSD를 시작하지 않도록 새 장치를 사용하지만 --no-systemd 를 전달하여 기존 OSD ID로 새 OSD를 만듭니다. 컨테이너 내에서는 이 작업을 수행할 수 없습니다.

   ceph-volume lvm create --osd-id 27 --data /dev/sdj --no-systemd

   중요

   별도의 block.db 와 같은 사용자 지정 매개변수를 사용하여 Ceph를 배포한 경우 OSD를 교체할 때 사용자 지정 매개변수를 사용해야 합니다.

10. 컨테이너 외부에서 OSD를 시작합니다.

    systemctl start ceph-osd@27

절차

1. 장치 이름이 변경되었는지 확인하고 Ceph를 배포하는 데 사용한 이름 지정 방법에 따라 장치 목록을 업데이트합니다. 자세한 내용은 12.1절. “장치 이름 변경 여부 확인”의 내용을 참조하십시오.
2. 변경 사항에 불일치가 발생하지 않도록 하려면 overcloud deploy 명령을 다시 실행하여 스택 업데이트를 수행합니다.

3. 장치 목록이 다른 호스트가 있는 경우 예외를 정의해야 할 수 있습니다. 예를 들어 다음 예제 heat 환경 파일을 사용하여 OSD 장치 3개가 있는 노드를 배포할 수 있습니다.

   parameter_defaults:
     CephAnsibleDisksConfig:
       devices:
         - /dev/sdb
         - /dev/sdc
         - /dev/sdd
       osd_scenario: lvm
       osd_objectstore: bluestore

   CephAnsibleDisksConfig 매개변수는 OSD를 호스팅하는 모든 노드에 적용되므로 devices 매개 변수를 새 device 목록으로 업데이트할 수 없습니다. 대신 다른 장치 목록이 있는 새 호스트에 대한 예외를 정의해야 합니다. 예외 정의에 대한 자세한 내용은 5.5절. “유사한 Ceph Storage 노드의 매개변수 덮어쓰기” 및 5.5.1.2절. “Ceph Storage 노드의 디스크 레이아웃 변경” 을 참조하십시오.