HyperConverged 인프라 가이드

Red Hat OpenStack Platform 17.0

Red Hat OpenStack Platform 오버클라우드에서 Hyperconverged Infrastructure 이해 및 구성

OpenStack Documentation Team

초록

이 문서에서는 동일한 호스트에서 컴퓨팅 및 Ceph Storage 서비스를 공동 배치하는 하이퍼 컨버지(Hyperconvergence)의 Red Hat OpenStack Platform 구현에 대해 설명합니다.

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

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

Red Hat 문서에 관한 피드백 제공

문서 개선을 위한 의견을 보내 주십시오. 어떻게 하면 더 잘할 수 있는지 알려주십시오.

DDF( Direct Documentation Feedback) 기능 사용

특정 문장, 단락 또는 코드 블록에 대한 직접 의견을 받으려면 피드백 DDF 추가 기능을 사용하십시오.

  1. 다중 페이지 HTML 형식으로 문서를 봅니다.
  2. 문서 오른쪽 상단에 Feedback 버튼이 표시되는지 확인합니다.
  3. 주석 처리하려는 텍스트 부분을 강조 표시합니다.
  4. 피드백 추가를 클릭합니다.
  5. 의견을 사용하여 피드백 추가 필드를 완료합니다.
  6. 선택 사항: 문서 팀이 문제에 대한 명확히 알릴 수 있도록 이메일 주소를 추가합니다.
  7. 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 하드웨어 배포

이 섹션에는 하이퍼컨버지드 노드의 준비 및 구성에 대한 절차 및 정보가 포함되어 있습니다.

사전 요구 사항

2.1. Ceph Storage 노드 디스크 정리

Ceph Storage OSD 및 저널 파티션에는 팩토리 정리 디스크가 필요합니다. 즉, Ceph OSD 서비스를 설치하기 전에 Ceph Storage의 추가 디스크를 Bare Metal Provisioning 서비스(ironic)로 지워야 합니다. 디스크에서 모든 메타데이터를 삭제해야 합니다. 그러지 않으면 OSD가 생성되지 않습니다.

기본적으로 모든 디스크 메타데이터를 삭제하도록 director를 구성할 수 있습니다. 이 옵션을 사용하면 베어 메탈 프로비저닝 서비스에서 노드를 부팅하고 노드가 사용 가능하게 설정될 때마다 디스크를 정리하는 추가 단계를 실행합니다. 이 프로세스는 첫 번째 인트로스펙션 이후 및 각 배포 전에 추가 전원 사이클을 추가합니다. 베어 메탈 프로비저닝 서비스에서는 wipefs --force --all 명령을 사용하여 정리를 수행합니다.

절차

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

    clean_nodes=true
  2. 이 옵션을 설정한 후 openstack undercloud install 명령을 실행하여 이 설정 변경 사항을 실행합니다.

    주의

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

2.2. 노드 등록

director가 호스트와 통신할 수 있도록 노드를 등록해야 합니다.

절차

  1. stack 사용자의 디렉터리에서 JSON 형식으로 노드 인벤토리 파일을 생성합니다.

    $ vi /home/stack/instackenv.json
  2. 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"
            }
        ]
    }
  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에 등록 및 구성됩니다.

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) 서브스크립션이 필요합니다.

절차

  1. /home/stack/templates/overcloud-baremetal-deploy.yaml 파일을 엽니다.
  2. 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: node02

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

    rhsm_enforce: False
  4. 프로비저닝 명령을 실행합니다.

    (undercloud)$ openstack overcloud node provision \
    --stack overcloud \
    --output /home/stack/templates/overcloud-baremetal-deployed.yaml \
    /home/stack/templates/overcloud-baremetal-deploy.yaml
  5. overcloud-baremetal-deployed.yaml 환경 파일을 openstack overcloud deploy 명령에 전달합니다.

2.5. HCI의 노드 지정

HCI의 노드를 지정하려면 새 역할 파일을 생성하여 ComputeHCI 역할을 구성하고 ComputeHCI 의 리소스 클래스를 사용하여 베어 메탈 노드를 구성해야 합니다.

절차

  1. stack 사용자로 언더클라우드에 로그인합니다.
  2. stackrc 인증 정보 파일을 소싱합니다.

    [stack@director ~]$ source ~/stackrc
  3. 컨트롤러ComputeHCI 역할을 포함하는 roles_data.yaml 이라는 새 역할 데이터 파일을 생성합니다.

    (undercloud)$ openstack overcloud roles generate Controller ComputeHCI -o ~/roles_data.yaml
  4. roles_data.yaml 을 열고 다음 매개변수와 섹션이 있는지 확인합니다.

    섹션/ 매개변수

    역할 주석

    역할: ComputeHCI

    역할 이름

    name: ComputeHCI

    description

    HCI 역할

    HostnameFormatDefault

    %stackname%-novaceph-%index%

    deprecated_nic_config_name

    ceph.yaml

  5. 노드 정의 템플릿 node.json 또는 node.yaml 에 추가하여 오버클라우드의 ComputeHCI 노드를 등록합니다.
  6. 노드 하드웨어를 검사합니다.

    (undercloud)$ openstack overcloud node introspect --all-manageable --provide
  7. 사용자 지정 HCI 리소스 클래스로 HCI를 지정할 각 베어 메탈 노드를 태그합니다.

    (undercloud)$ openstack baremetal node set \
     --resource-class baremetal.HCI <node>

    & lt;node& gt;를 베어 메탈 노드의 ID로 바꿉니다.

  8. /home/stack/templates/overcloud-baremetal-deploy.yaml 파일에 ComputeHCI 역할을 추가하고 노드에 할당할 예측 가능한 노드 배치, 리소스 클래스 또는 기타 속성을 정의합니다.

    - name: Controller
       count: 3
    - name: ComputeHCI
    	 count: 1
       defaults:
    	   resource_class: baremetal.HCI
  9. 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 역할에 대한 네트워크 구성에는 이 네트워크가 포함되지 않습니다.

    자세한 내용은 베어 메탈 프로비저닝 에서 참조하십시오.

  10. 프로비저닝 명령을 실행합니다.

    (undercloud)$ openstack overcloud node provision \
    --stack overcloud \
    --output /home/stack/templates/overcloud-baremetal-deployed.yaml \
    /home/stack/templates/overcloud-baremetal-deploy.yaml
  11. 별도의 터미널에서 프로비저닝 진행 상황을 모니터링합니다.

    (undercloud)$ watch openstack baremetal node list
    참고

    watch 명령은 기본적으로 2초마다 업데이트됩니다. -n 옵션은 갱신 타이머를 다른 값으로 설정합니다.

  12. 감시 프로세스를 중지하려면 Ctrl-c 를 입력합니다.
  13. 검증: 프로비저닝에 성공하면 노드 상태가 available 에서 active 로 변경됩니다.

추가 리소스

2.6. 멀티 디스크 Ceph 클러스터의 root 디스크 정의

대부분의 Ceph Storage 노드는 여러 디스크를 사용합니다. 노드에서 여러 디스크를 사용하는 경우 director는 root 디스크를 식별해야 합니다. 기본적으로 director는 프로비저닝 프로세스 중에 오버클라우드 이미지를 root 디스크에 씁니다.

일련 번호로 root 장치를 확인하려면 다음 절차를 사용하십시오. root 디스크를 식별하는 데 사용할 수 있는 다른 속성에 대한 자세한 내용은 2.6.1절. “root 디스크를 식별하는 속성” 을 참조하십시오.

절차

  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. 언더클라우드에서 노드의 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> 또는 openstack overcloud ceph deploy --config <file_name > 명령으로 Ceph 클러스터를 구성하는 데 사용됩니다.

하이퍼컨버지드 노드에서 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_ autotune 옵션이 true 로 설정됩니다. autotune_memory_target_ratio 의 기본값은 0.7 입니다. 이는 자동 조정되지 않은 Ceph 데몬이 사용하는 모든 메모리를 뺀 시작 지점인 총 RAM의 70%를 나타냅니다. 그런 다음 나머지 메모리는 모든 OSD에 osd_memory_target_autotunetrue 로 설정되어 있다고 가정하여 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_affinitytrue 로 설정합니다. 또는 osd_numa_node0 으로 직접 설정할 수 있으며 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 입니다.

절차

  1. stack 사용자로 언더클라우드 노드에 로그인합니다.
  2. 다음 명령을 사용하여 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 클러스터에서 사용하는 네트워크를 설명합니다.

절차

  1. stack 사용자로 언더클라우드 노드에 로그인합니다.
  2. network_data.yaml 이라는 사용자 지정 네트워크 속성을 정의하는 YAML 형식 파일을 생성합니다.

    중요

    네트워크 분리를 사용하여 표준 네트워크 배포는 두 개의 Ceph 네트워크에 매핑되는 두 개의 스토리지 네트워크로 구성됩니다.

    • 스토리지 네트워크인 스토리지 는 Ceph 네트워크 public_network 에 매핑됩니다. 이 네트워크는 컴퓨팅 노드에서 Ceph 클러스터로의 RBD 트래픽과 같은 스토리지 트래픽을 처리합니다.
    • 스토리지 네트워크인 storage_mgmt 는 Ceph 네트워크 cluster_network 에 매핑됩니다. 이 네트워크는 Ceph OSD 간의 데이터 복제와 같은 스토리지 관리 트래픽을 처리합니다.
  3. --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_networkcluster_network 로 사용할 네트워크를 결정합니다. 이 명령은 --public-network-name--cluster-network-name 옵션에 다른 이름을 지정하지 않는 한 네트워크 데이터 파일에서 이러한 네트워크의 이름이 storagestorage_mgmt 라고 가정합니다.

    네트워크 분리로 배포할 때 --network-data 옵션을 사용해야 합니다. 이 옵션을 사용하지 않는 경우 public_networkcluster_network 에 기본 언더클라우드(192.168.24.0/24)가 사용됩니다.

3.6. 구성 파일을 사용하여 네트워크 옵션 구성

네트워크 데이터 파일의 대안으로 구성 파일을 사용하여 네트워크 옵션을 지정할 수 있습니다.

중요

이 방법을 사용하여 네트워크 옵션을 구성하여 network_data.yaml 에서 자동으로 생성된 값을 덮어씁니다. 이 네트워크 구성 방법을 사용할 때 4개의 값을 모두 설정해야 합니다.

절차

  1. stack 사용자로 언더클라우드 노드에 로그인합니다.
  2. Ceph 클러스터를 구성하는 표준 형식 초기화 파일을 생성합니다. 다른 구성 옵션을 포함하도록 파일을 이미 생성한 경우 네트워크 구성을 추가할 수 있습니다.
  3. 파일의 [global] 섹션에 다음 매개변수를 추가합니다.

    • public_network
    • cluster_network
    • ms_bind_ipv4

      중요

      public_networkcluster_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
  4. 구성 파일을 배포하려면 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 위치만 설정합니다. 이후 특성 변경은 무시됩니다.

절차

  1. stack 사용자로 언더클라우드 노드에 로그인합니다.
  2. stackrc 언더클라우드 인증 정보 파일을 소싱합니다.

    $ 소스 ~/stackrc

  3. 구성 파일을 생성하여 사용자 지정ECDHE 계층 구조(예: crush_hierarchy.yaml )를 정의합니다.
  4. 파일에 다음 구성을 추가합니다.

    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) 로 바꿉니다.
  5. 사용자 지정 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 매개변수를 사용하여 풀은 여전히 정의 및 생성됩니다.

3.8. Ceph 서비스 배치 옵션 구성

사용자 지정 역할 파일을 사용하여 Ceph 서비스를 실행하는 노드를 정의할 수 있습니다. 사용자 지정 역할 파일은 환경 때문에 기본 역할 할당을 사용하지 않는 경우에만 필요합니다. 예를 들어 하이퍼컨버지드 노드를 배포할 때 계산 인스턴스 목록이 포함된 배치 목록을 갖도록 사전 배포된 계산 노드에 osd 의 서비스 유형이 osd 로 레이블이 지정되어야 합니다.

roles_data.yaml 파일의 서비스 정의는 어떤 서비스를 실행하는 베어 메탈 인스턴스를 결정합니다. 기본적으로 Controller 역할에는 CephMon 및 CephMgr 서비스가 있으며 CephStorage 역할에는 CephOSD 서비스가 있습니다. 대부분의 구성 가능 서비스와 달리 Ceph 서비스는 서비스 구성 방법을 결정하기 위해 heat 출력이 필요하지 않습니다. roles_data.yaml 파일은 Heat가 실행되기 전에 배포된 Ceph 프로세스가 수행되는 경우에도 항상 Ceph 서비스 배치를 결정합니다.

절차

  1. stack 사용자로 언더클라우드 노드에 로그인합니다.
  2. 사용자 지정 역할을 정의하는 YAML 형식 파일을 생성합니다.
  3. 구성 파일을 배포합니다.

    $ 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 사용자를 생성할 수 있습니다.

절차

  1. stack 사용자로 언더클라우드 노드에 로그인합니다.
  2. 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 키를 제거합니다.

절차

  1. stack 사용자로 언더클라우드 노드에 로그인합니다.
  2. 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

절차

  1. stack 사용자로 언더클라우드 노드에 로그인합니다.
  2. 사용자 지정 컨테이너 레지스트리를 정의하는 YAML 형식 파일을 생성합니다.

    다음은 custom_container_image_prepare.yaml 이라는 사용자 지정 컨테이너 레지스트리 파일의 예입니다.

    ContainerImageRegistryCredentials:
      quay.io/ceph-ci:
        quay_username: quay_password
  3. --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) 파일을 사용하여 적용할 수 있습니다.

절차

  1. stack 사용자로 언더클라우드 노드에 로그인합니다.
  2. 선택사항: 표준 형식 초기화(ini) 파일을 사용하여 Ceph 클러스터를 구성합니다.

    1. 구성 옵션을 사용하여 파일을 생성합니다. 다음은 간단한 구성 파일의 예입니다.

      [global]
      osd crush chooseleaf type = 0
      log_file = /var/log/ceph/$cluster-$type.$id.log
      
      [mon]
      mon_cluster_log_to_syslog = true
    2. 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 파일 또는 환경에서 유사한 목적에 사용되는 파일을 업데이트하여 ApplyCephConfigOverridesOnUpdatefalse 로 설정합니다. 환경 작업 중에 변경한 후속 Ceph 구성은 ceph config 명령을 사용하여 수행해야 합니다. ApplyCephConfigOverridesOnUpdateCephConfigOverrides 매개변수에 대한 자세한 내용은 Overcloud Parameters 를 참조하십시오.

  3. 선택 사항: openstack overcloud ceph deploy --single-host-defaults 명령을 사용하여 단일 인스턴스에서 실행되도록 Ceph 클러스터를 구성합니다.

    참고

    이 옵션은 테스트 환경에서만 사용할 수 있습니다. 프로덕션 환경에서는 지원되지 않습니다.

  4. 선택 사항: 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 클러스터를 사용자 지정하기 위해 사용자 정의 서비스 사양을 생성할 수 있습니다.

절차

  1. stack 사용자로 언더클라우드 노드에 로그인합니다.
  2. openstack overcloud ceph spec 명령을 사용하여 사양 파일을 생성합니다. 다음 예제는 -o 스위치로 지정된 위치에 사양 파일을 출력합니다.

    openstack overcloud ceph spec -o '~/ceph_spec.yaml'
  3. 필요한 구성으로 생성된 파일을 편집합니다.
  4. 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 구성에 사용할 수 있는 속성이 나열됩니다.

절차

  1. stack 사용자로 언더클라우드 노드에 로그인합니다.
  2. OSD 사양을 정의하는 이라는 YAML 포맷 파일을 생성합니다.

    다음은 사용자 지정 OSD 사양의 예입니다.

    data_devices:
      rotational: 1
    db_devices:
      rotational: 0

    이 예제에서는 모든 회전 장치가 데이터 장치이며 모든 순환되지 않은 장치가 공유 장치로 사용되는 OSD 사양을 생성합니다. 이는 동적 Ceph 서비스 사양을 빌드할 때, service_type이 osd 인 경우 사양의 섹션에 임의 항목이 추가되기 때문입니다.

  3. 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 클라이언트 간의 통신을 암호화하여 엔드 투 엔드 암호화를 제공합니다.

절차

  1. Red Hat Ceph Storage Data Security 및 Hardening Guide 에서 메신저 v2 프로토콜 활성화에 설명된 지시문을 사용하여 ceph.conf 의 초기 ceph.conf를 구성합니다.

Ceph on-wire 암호화에 대한 자세한 내용은 Red Hat Ceph Storage Architecture GuideCeph 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 성능이 향상됩니다.

절차

  1. 언더클라우드 호스트에 stack 사용자로 로그인합니다.
  2. stackrc 언더클라우드 인증 정보 파일을 소싱합니다.

    $ source ~/stackrc
  3. 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 클러스터에 기본 설정을 적용합니다. 사용자 지정 환경 파일에서 추가 구성을 정의해야 합니다.

절차

  1. /home/stack/templates/storage-config.yaml 파일을 생성합니다. 이 예제에서 ~/templates/storage-config.yaml 파일에는 환경에 대한 대부분의 오버클라우드 관련 사용자 지정 설정이 포함되어 있습니다. 사용자 지정 환경 파일에 포함된 매개변수는 /usr/share/openstack-tripleo-heat-templates/environments/cephadm/cephadm.yaml 파일의 해당 기본 설정을 재정의합니다.
  2. ~/templates/storage-config.yamlparameter_defaults 섹션을 추가합니다. 이 섹션에는 오버클라우드의 사용자 정의 설정이 포함되어 있습니다.
  3. 선택 사항: 요구 사항에 따라 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 는 풀이 속한 영역의 이름으로 교체됩니다.

추가 리소스

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 파일을 environments/cephadm/cephadm-rbd-only.yaml 로 교체하여 RGW 대신 RGW를 계속 사용할 수 있습니다. 자세한 내용은 업그레이드 설명서를 참조하십시오. RHOSP에서는 Swift에서 RGW로의 마이그레이션을 지원하지 않습니다.

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 환경을 배포한 후 지정된 구성으로 성공적으로 배포되었는지 확인합니다.

절차

  1. ceph 쉘을 시작합니다.
  2. 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
  3. 특정 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
  4. 특정 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
  5. 컴퓨팅 노드에서 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 노드에서 인스턴스를 마이그레이션하고, 오버클라우드에서 컴퓨팅 노드를 삭제해야 합니다.

절차

  1. HCI 노드에서 Ceph OSD 서비스를 비활성화하고 리밸런스합니다. HCI 또는 Red Hat Ceph Storage 노드를 제거할 때 director가 Red Hat Ceph Storage 클러스터를 자동으로 재조정하지 않기 때문에 이 단계가 필요합니다. 자세한 내용은 director와 Red Hat Ceph Storage 및 Red Hat OpenStack Platform 배포에서 Ceph Storage 클러스터 스케일링 을 참조하십시오.
  2. HCI 노드에서 인스턴스를 마이그레이션합니다. 자세한 내용은 Configuring the Compute Service for Instance Creation 가이드의 Compute 노드 간에 가상 머신 마이그레이션을 참조하십시오.
  3. 오버클라우드에서 컴퓨팅 노드를 삭제합니다. 자세한 내용은 컴퓨팅 노드 제거 를 참조하십시오.

부록 A. 추가 정보

A.1. 하이퍼컨버지드 인프라 환경의 구성에 대한 가이드 및 리소스

다음 가이드에는 하이퍼컨버지드 인프라 환경의 구성을 지원할 수 있는 추가 정보 및 절차가 포함되어 있습니다.

  • director와 함께 Red Hat Ceph 및 OpenStack 배포

    • 이 가이드에서는 Red Hat OpenStack Platform director를 사용하여 Red Hat Ceph Storage 클러스터에서 오버클라우드를 생성하는 방법에 대한 정보를 제공합니다. 여기에는 director를 통해 Ceph 클러스터를 사용자 정의하는 지침이 포함됩니다.
  • Director 설치 및 사용

    • 이 가이드에서는 Red Hat OpenStack Platform 환경의 엔드 투 엔드 배포에 대한 지침을 제공합니다. 여기에는 director 설치, 환경 계획, director를 사용한 OpenStack 환경 구축 작업이 포함됩니다.
  • 네트워킹 가이드

    • 이 가이드에서는 Red Hat OpenStack Platform 네트워킹 작업에 대해 자세히 설명합니다.
  • 스토리지 가이드

    • 이 가이드에서는 Red Hat OpenStack Platform 환경에서 영구 스토리지를 사용하고 관리하는 다양한 절차에 대해 자세히 설명합니다. 여기에는 각 영구 스토리지 유형의 각 OpenStack 서비스를 구성하고 관리하는 절차도 포함되어 있습니다.
  • Bare Metal Provisioning

    • 이 가이드에서는 Red Hat OpenStack Platform 환경의 오버클라우드에서 베어 메탈 프로비저닝 서비스의 설치 및 구성에 대해 자세히 설명하여 클라우드 사용자를 위한 물리적 시스템을 프로비저닝 및 관리합니다.
  • 보안 및 Hardening 가이드

    • 이 가이드에서는 Red Hat OpenStack Platform 환경의 보안 강화에 대한 유용한 조언과 개념적 정보를 제공합니다.
  • 릴리스 노트

    • 이 문서에서는 Red Hat OpenStack Platform의 주요 기능, 기능 향상 및 알려진 문제에 대해 간단히 설명합니다.

법적 공지

Copyright © 2023 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.