오버클라우드와 기존 Red Hat Ceph 클러스터 통합

Red Hat OpenStack Platform 16.1

독립 실행형 Red Hat Ceph Storage를 사용하도록 오버클라우드 구성

OpenStack Documentation Team

초록

이 가이드에서는 Red Hat OpenStack Platform director를 사용하여 Overcloud를 기존 독립 실행형 Red Hat Ceph 클러스터와 통합하는 방법을 설명합니다.

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

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

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

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

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

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

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

1장. 오버클라우드와 Ceph Storage 통합

Red Hat OpenStack Platform director는 오버클라우드라는 클라우드 환경을 생성합니다. director를 사용하여 Red Hat Ceph Storage와의 통합과 같은 오버클라우드의 추가 기능을 구성할 수 있습니다. 오버클라우드를 director 또는 기존 Ceph Storage 클러스터와 함께 생성된 Ceph Storage 클러스터와 통합할 수 있습니다.

이 가이드에서는 기존 Ceph Storage 클러스터를 오버클라우드와 통합하는 방법을 설명합니다. 즉, director는 스토리지 요구 사항에 Ceph Storage 클러스터를 사용하도록 오버클라우드를 구성합니다. 오버클라우드 구성 외부에서 클러스터 자체를 관리하고 확장합니다.

1.1. Ceph Storage 정보

Red Hat Ceph Storage는 성능, 안정성 및 확장성을 제공하는 분산 데이터 오브젝트 저장소입니다. 분산 개체는 구조화되지 않은 데이터를 수용하며 클라이언트는 최신 오브젝트 인터페이스와 기존 인터페이스를 동시에 사용할 수 있습니다. 모든 Ceph 배포의 핵심은 Ceph Storage 클러스터이며, 이 클러스터는 여러 유형의 데몬으로 구성됩니다. 다음은 주로 두 가지 유형의 데몬입니다.

Ceph OSD(오브젝트 스토리지 데몬)
Ceph OSD는 Ceph 클라이언트를 대신하여 데이터를 저장합니다. 또한 Ceph OSD는 Ceph 노드의 CPU 및 메모리를 사용하여 데이터 복제, 재조정, 복구, 모니터링 및 보고 기능을 수행합니다.
Ceph 모니터
Ceph 모니터는 스토리지 클러스터의 현재 상태와 함께 Ceph 스토리지 클러스터 맵의 마스터 사본을 유지 관리합니다.

Red Hat Ceph Storage에 대한 자세한 내용은 Red Hat Ceph Storage Architecture Guide를 참조하십시오.

1.2. 외부 CephFS를 사용하여 공유 파일 시스템 서비스 배포

Red Hat OpenStack Platform director는 CephFS를 사용하여 Shared File Systems 서비스(manila)를 배포할 수 있습니다. CephFS는 기본 CephFS 프로토콜 또는 NFS 프로토콜을 통해 사용할 수 있습니다.

이러한 스토리지 프로토콜에 대한 자세한 내용은 공유 파일 시스템 서비스용 CephFS 백엔드 가이드의 Ceph 파일 시스템 아키텍처를 참조하십시오.

중요

CephFS 기본 드라이버와 함께 Shared File Systems 서비스(manila)를 사용하면 Manila CSI를 통해 Red Hat OpenShift Container Platform에 대한 공유를 제공할 수 없습니다. Red Hat은 이러한 유형의 배포를 지원하지 않습니다. 자세한 내용은 Red Hat 지원팀에 문의하십시오.

중요

NFS를 통해 CephFS가 포함된 Shared File Systems 서비스(manila)는 Manila CSI를 통해 Red Hat OpenShift Container Platform에 대한 공유를 완전히 지원합니다. 이 솔루션은 대규모 배포를 위한 것이 아닙니다. 중요한 권장 사항은 https://access.redhat.com/articles/6667651 를 참조하십시오.

중요

기본 CephFS 공유 파일 시스템을 사용하려면 클라이언트에 Ceph 공용 네트워크에 액세스해야 합니다. 오버클라우드를 기존 Ceph 클러스터와 통합할 때 director는 Ceph 공용 네트워크로 지정할 격리된 스토리지 네트워크를 생성하지 않습니다. 이 네트워크는 이미 존재하는 것으로 가정합니다. Ceph 공용 네트워크에 직접 액세스하지 마십시오. 대신 테넌트에서 Ceph 공용 네트워크에 연결할 라우터를 만들 수 있습니다.

보안 고려 사항에 대한 자세한 내용은 기본 CephFS를 사용하여 공유 파일 시스템 서비스 배포 가이드의 Native CephFS 백엔드 보안 을 참조하십시오.

NFS 프로토콜을 통해 CephFS를 사용하는 경우 director는 Pacemaker(PCS)에서 관리하는 컨트롤러 노드에 NFS-Ganesha 게이트웨이를 배포합니다. PCS는 액티브-패시브 구성을 사용하여 클러스터 가용성을 관리합니다.

참고

이 기능은 Ceph 4 사이클 또는 Ceph Storage 5.0 이상에서 Ceph Storage 4.1 이상에서 지원됩니다. 최신 버전의 ceph-ansible 패키지를 언더클라우드에 설치해야 합니다. 시스템에 설치된 Ceph Storage 릴리스를 결정하는 방법에 대한 자세한 내용은 Red Hat Ceph Storage 릴리스 및 해당 Ceph 패키지 버전을 참조하십시오.

언더클라우드에서 ceph-ansible 패키지를 업데이트하는 방법에 대한 자세한 내용은 3.1절. “ceph-ansible 패키지 설치” 을 참조하십시오.

사전 요구 사항

다음 사전 요구 사항은 외부 Ceph Storage 클러스터를 사용하여 공유 파일 시스템 서비스를 구성해야 합니다.

  • 외부 Ceph Storage 클러스터에 활성 MDS가 있어야 합니다.
  • 외부 Ceph Storage 클러스터에는 CephFS 데이터(ManilaCephFSDataPoolName) 및 CephFS 메타데이터 풀(ManilaCephFSMetadataPoolName) 값을 기반으로 하는 CephFS 파일 시스템이 있어야 합니다. 자세한 내용은 3.2절. “사용자 정의 환경 파일 생성”의 내용을 참조하십시오.
  • 외부 Ceph Storage 클러스터에는 공유 파일 시스템 서비스의 cephx 클라이언트 이름과 키가 있어야 합니다. 자세한 내용은 3.2절. “사용자 정의 환경 파일 생성”의 내용을 참조하십시오.

Red Hat Ceph Storage에 대한 자세한 내용은 Red Hat Ceph Storage 파일 시스템 가이드를 참조하십시오.

1.3. 외부 Ceph Object Gateway를 사용하도록 Ceph Object Store 구성

RHOSP(Red Hat OpenStack Platform) director는 외부 Ceph Object Gateway(RGW)를 오브젝트 스토어 서비스로 구성하는 작업을 지원합니다. 외부 RGW 서비스로 인증하려면 ID 서비스(keystone)에서 사용자와 해당 역할을 확인하도록 RGW를 구성해야 합니다.

외부 Ceph Object Gateway를 구성하는 방법에 대한 자세한 내용은 Ceph Object Gateway 사용 가이드에서 Keystone 인증을 사용하도록 Ceph Object Gateway 구성을 참조하십시오.

2장. 오버클라우드 노드 준비

이 시나리오에 배포된 오버클라우드는 6개의 노드로 구성됩니다.

  • 고가용성 컨트롤러 노드 세 개
  • 컴퓨팅 노드 세 개

director는 별도의 Ceph Storage 클러스터와 자체 노드를 오버클라우드에 통합합니다. 이 클러스터를 오버클라우드와 독립적으로 관리합니다. 예를 들어 director가 아닌 Ceph 관리 툴을 사용하여 Ceph Storage 클러스터를 확장합니다. 자세한 내용은 Red Hat Ceph Storage 설명서 라이브러리를 참조하십시오.

2.1. Ceph Storage에 대한 사전 배포 검증

오버클라우드 배포 실패를 방지하려면 서버에 필요한 패키지가 있는지 확인합니다.

2.1.1. ceph-ansible 패키지 버전 확인

언더클라우드에는 오버클라우드를 배포하기 전에 잠재적인 문제를 식별하기 위해 실행할 수 있는 Ansible 기반 검증이 포함되어 있습니다. 이러한 검증을 통해 일반적인 문제가 발생하기 전에 식별하여 오버클라우드 배포 실패를 방지할 수 있습니다.

절차

ceph-ansible 패키지의 수정 버전이 설치되어 있는지 확인합니다.

$ ansible-playbook -i /usr/bin/tripleo-ansible-inventory /usr/share/ansible/validation-playbooks/ceph-ansible-installed.yaml

2.1.2. 사전 프로비저닝된 노드의 패키지 확인

Ceph는 특정 패키지 집합이 있는 Overcloud 노드만 서비스할 수 있습니다. 사전 프로비저닝된 노드를 사용하는 경우 이러한 패키지가 있는지 확인할 수 있습니다.

사전 프로비저닝된 노드에 대한 자세한 내용은 사전 프로비저닝된 노드를 사용하여 기본 오버클라우드 구성을 참조하십시오.

절차

서버에 필수 패키지가 포함되어 있는지 확인합니다.

ansible-playbook -i /usr/bin/tripleo-ansible-inventory /usr/share/ansible/validation-playbooks/ceph-dependencies-installed.yaml

2.2. 기존 Ceph Storage 클러스터 구성

OSD 풀을 만들고, 기능을 정의하며, Ceph Storage 클러스터의 키와 ID를 만듭니다.

절차

  1. 사용자 환경과 관련된 Ceph 클러스터에 다음 풀을 생성합니다.

    • 볼륨: OpenStack 블록 스토리지(cinder)용 스토리지
    • images: OpenStack Image Storage(glance)용 스토리지
    • vms: 인스턴스의 스토리지
    • 백업: OpenStack 블록 스토리지 백업용 스토리지(cinder-backup)
    • 메트릭: OpenStack Telemetry Metrics(gnocchi)용 스토리지

      다음 명령을 가이드로 사용하십시오.

      [root@ceph ~]# ceph osd pool create volumes <_pgnum_>
      [root@ceph ~]# ceph osd pool create images <_pgnum_>
      [root@ceph ~]# ceph osd pool create vms <_pgnum_>
      [root@ceph ~]# ceph osd pool create backups <_pgnum_>
      [root@ceph ~]# ceph osd pool create metrics <_pgnum_>

      오버클라우드에서 CephFS가 지원하는 Shared File Systems(manila)를 배포하는 경우 CephFS 데이터 및 메타데이터 풀도 생성합니다.

      [root@ceph ~]# ceph osd pool create manila_data PGNUM
      [root@ceph ~]# ceph osd pool create manila_metadata PGNUM

    <_pgnum_>을 배치 그룹 수로 바꿉니다. OSD당 약 100개의 배치 그룹이 모범 사례입니다. 예를 들어 총 OSD 수에 100을 곱한 경우 전체 복제본 수, osd 풀 기본 크기입니다. 풀 계산기당 Ceph PG(배치 그룹) 를 사용하여 적절한 값을 결정할 수도 있습니다.

  2. 다음 기능을 사용하여 Ceph 클러스터에 client.openstack 사용자를 생성합니다.

    • cap_mgr: "allow *"
    • cap_mon: profile rbd
    • cap_osd: profile rbd pool=volumes, profile rbd pool=vms, profile rbd pool=images, profile rbd pool=backups, profile rbd pool=metrics

      다음 명령을 가이드로 사용합니다.

      [root@ceph ~]# ceph auth add client.openstack mgr 'allow *' mon 'profile rbd' osd 'profile rbd pool=volumes, profile rbd pool=vms, profile rbd pool=images, profile rbd pool=backups, profile rbd pool=metrics'
  3. client. openstack 사용자에 대해 생성된 Ceph 클라이언트 키를 확인합니다.

    [root@ceph ~]# ceph auth list
    ...
    [client.openstack]
    	key = AQC+vYNXgDAgAhAAc8UoYt+OTz5uhV7ItLdwUw==
    	caps mgr = "allow *"
    	caps mon = "profile rbd"
    	caps osd = "profile rbd pool=volumes, profile rbd pool=vms, profile rbd pool=images, profile rbd pool=backups, profile rbd pool=metrics"
    ...

    예의 값인 A✓+vYNXgDAgAhAAc8UoYt+OTz5uhV7ItLdwUw== 는 Ceph 클라이언트 키입니다.

  4. 오버클라우드에서 CephFS에서 지원하는 공유 파일 시스템 서비스를 배포하는 경우 다음 기능을 사용하여 Ceph 클러스터에 client.manila 사용자를 생성합니다.

    • cap_mds: allow *
    • cap_mgr: allow *
    • cap_mon: allow r, allow 명령 "auth del", allow command "auth caps", allow command "auth get", allow command "auth get-or-create"
    • cap_osd: allow rw 다음 명령을 가이드로 사용합니다.

      [root@ceph ~]# ceph auth add client.manila mon 'allow r, allow command "auth del", allow command "auth caps", allow command "auth get", allow command "auth get-or-create"' osd 'allow rw' mds 'allow *' mgr 'allow *'
  5. manila 클라이언트 이름과 오버클라우드 배포 템플릿에서 사용할 키 값을 기록해 둡니다.

    [root@ceph ~]# ceph auth get-key client.manila
         AQDQ991cAAAAABAA0aXFrTnjH9aO39P0iVvYyg==
  6. Ceph Storage 클러스터의 파일 시스템 ID를 기록해 둡니다. 이 값은 [global] 섹션의 클러스터 구성 파일에서 fsid 설정을 사용하여 지정합니다.

    [global]
    fsid = 4b5c8c0a-ff60-454b-a1b4-9747aa737d19
    ...
참고

Ceph Storage 클러스터 구성 파일에 대한 자세한 내용은 Red Hat Ceph Storage 구성 가이드의 Ceph 구성을 참조하십시오.

Ceph 클라이언트 키와 파일 시스템 ID를 사용하고, manila 클라이언트 IDS 및 키를 사용합니다. 3.1절. “ceph-ansible 패키지 설치”.

2.3. stack 사용자 초기화

stack 사용자를 초기화하여 director CLI 툴에 액세스하는 데 사용되는 인증 세부 정보를 구성합니다.

절차

  1. director 호스트에 stack 사용자로 로그인합니다.
  2. 다음 명령을 입력하여 director 구성을 초기화합니다.

    $ source ~/stackrc

2.4. 노드 등록

인벤토리 파일에는 노드에 대한 하드웨어 및 전원 관리 세부 정보가 포함되어 있습니다. 인벤토리 파일을 생성하여 director에 노드를 구성하고 등록합니다.

절차

  1. 인벤토리 파일을 생성합니다. 예제 노드 정의 템플릿인 instackenv.json 을 참조로 사용합니다.

    {
        "nodes":[
            {
                "mac":[
                    "bb:bb:bb:bb:bb:bb"
                ],
                "cpu":"4",
                "memory":"6144",
                "disk":"40",
                "arch":"x86_64",
                "pm_type":"pxe_ipmitool",
                "pm_user":"admin",
                "pm_password":"p@55w0rd!",
                "pm_addr":"192.0.2.205"
            },
            {
                "mac":[
                    "cc:cc:cc:cc:cc:cc"
                ],
                "cpu":"4",
                "memory":"6144",
                "disk":"40",
                "arch":"x86_64",
                "pm_type":"pxe_ipmitool",
                "pm_user":"admin",
                "pm_password":"p@55w0rd!",
                "pm_addr":"192.0.2.206"
            },
            {
                "mac":[
                    "dd:dd:dd:dd:dd:dd"
                ],
                "cpu":"4",
                "memory":"6144",
                "disk":"40",
                "arch":"x86_64",
                "pm_type":"pxe_ipmitool",
                "pm_user":"admin",
                "pm_password":"p@55w0rd!",
                "pm_addr":"192.0.2.207"
            },
            {
                "mac":[
                    "ee:ee:ee:ee:ee:ee"
                ],
                "cpu":"4",
                "memory":"6144",
                "disk":"40",
                "arch":"x86_64",
                "pm_type":"pxe_ipmitool",
                "pm_user":"admin",
                "pm_password":"p@55w0rd!",
                "pm_addr":"192.0.2.208"
            }
            {
                "mac":[
                    "ff:ff:ff:ff:ff:ff"
                ],
                "cpu":"4",
                "memory":"6144",
                "disk":"40",
                "arch":"x86_64",
                "pm_type":"pxe_ipmitool",
                "pm_user":"admin",
                "pm_password":"p@55w0rd!",
                "pm_addr":"192.0.2.209"
            }
            {
                "mac":[
                    "gg:gg:gg:gg:gg:gg"
                ],
                "cpu":"4",
                "memory":"6144",
                "disk":"40",
                "arch":"x86_64",
                "pm_type":"pxe_ipmitool",
                "pm_user":"admin",
                "pm_password":"p@55w0rd!",
                "pm_addr":"192.0.2.210"
            }
        ]
    }
  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에 등록되어 구성됩니다.

2.5. 수동으로 노드 태그 지정

각 노드를 등록한 후에는 하드웨어를 검사하고 특정 프로필에 노드를 태그해야 합니다. 프로필 태그를 사용하여 노드를 플레이버에 일치시킨 다음 배포 역할에 플레이버를 할당합니다.

절차

  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 프로필을 사용하려면 다음 프로필 옵션을 생성합니다.

    $ ironic node-update 1a4e30da-b6dc-499d-ba87-0bd8a3819bc0 add properties/capabilities='profile:control,boot_option:local'
    $ ironic node-update 6faba1a9-e2d8-4b7c-95a2-c7fbdc12129a add properties/capabilities='profile:control,boot_option:local'
    $ ironic node-update 5e3b2f50-fcd9-4404-b0a2-59d79924b38e add properties/capabilities='profile:control,boot_option:local'
    $ ironic node-update 484587b2-b3b3-40d5-925b-a26a2fa3036f add properties/capabilities='profile:compute,boot_option:local'
    $ ironic node-update d010460b-38f2-4800-9cc4-d69f0d067efe add properties/capabilities='profile:compute,boot_option:local'
    $ ironic node-update d930e613-3e14-44b9-8240-4f3559801ea6 add properties/capabilities='profile:compute,boot_option:local'

3장. 기존 Ceph Storage 클러스터와 통합

Red Hat OpenStack Platform을 기존 Ceph Storage 클러스터와 통합하려면 ceph-ansible 패키지를 설치해야 합니다. 그런 다음 사용자 지정 환경 파일을 만들고 노드와 플레이버를 역할에 할당할 수 있습니다.

3.1. ceph-ansible 패키지 설치

Red Hat OpenStack Platform director는 ceph-ansible 을 사용하여 기존 Ceph Storage 클러스터와 통합하지만 ceph-ansible 은 언더클라우드에 기본적으로 설치되지 않습니다.

절차

다음 명령을 입력하여 언더클라우드에 ceph-ansible 패키지를 설치합니다.

sudo dnf install -y ceph-ansible

3.2. 사용자 정의 환경 파일 생성

director는 환경 파일을 통해 외부 Ceph Storage 클러스터와 통합하기 위해 ceph-ansible 에 매개변수를 제공합니다.

  • /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible-external.yaml

외부 CephFS를 사용하여 공유 파일 시스템 서비스를 배포하는 경우 별도의 환경 파일에 추가 매개 변수를 제공합니다.

  • 기본 CephFS의 경우 환경 파일은 /usr/share/openstack-tripleo-heat-templates/environments/manila-cephfsnative-config.yaml 입니다.
  • NFS를 통한 CephFS의 경우 환경 파일은 /usr/share/openstack-tripleo-heat-templates/environments/manila-cephfsganesha-config.yaml 입니다.

director는 배포 중에 이러한 환경 파일을 호출하여 기존 Ceph Storage 클러스터를 오버클라우드와 통합합니다. 자세한 내용은 3.5절. “오버클라우드 배포” 확인할 수 있습니다.

통합을 설정하려면 director에 Ceph Storage 클러스터의 세부 정보를 제공해야 합니다. 이렇게 하려면 사용자 지정 환경 파일을 사용하여 기본 설정을 재정의합니다.

절차

  1. 사용자 정의 환경 파일을 생성합니다.

    /home/stack/templates/ceph-config.yaml

  2. 파일에 parameter_defaults: 섹션을 추가합니다.

    parameter_defaults:
  3. parameter_defaults 를 사용하여 /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible-external.yaml 에서 재정의하려는 모든 매개변수를 설정합니다. 다음 매개변수를 최소한 설정해야 합니다.

    • CephClientKey: Ceph Storage 클러스터의 Ceph 클라이언트 키입니다. 2.2절. “기존 Ceph Storage 클러스터 구성” 에서 검색한 값입니다. 예를 들어 AQDL1VgEp6FRAAFzT7Zw+Y9V6JJExQAsRnRQ== 입니다.
    • CephClusterFSID: Ceph Storage 클러스터의 파일 시스템 ID입니다. 2.2절. “기존 Ceph Storage 클러스터 구성” 에서 검색한 Ceph Storage 클러스터 구성 파일의 fsid 값입니다. 예를 들면 4b5c8c0a-ff60-454b-a1b4-9747aa737d19 입니다.
    • CephExternalMonHost: Ceph Storage 클러스터에 있는 모든 MON 호스트의 쉼표로 구분된 IP 목록입니다(예: 172.16.1.7, 172.16.1.8 ).

      예를 들면 다음과 같습니다.

      parameter_defaults:
        CephClientKey: AQDLOh1VgEp6FRAAFzT7Zw+Y9V6JJExQAsRnRQ==
        CephClusterFSID: 4b5c8c0a-ff60-454b-a1b4-9747aa737d19
        CephExternalMonHost: 172.16.1.7, 172.16.1.8
  4. 필요한 경우 Ceph Storage 클러스터와 일치하도록 기본 풀 이름 또는 Red Hat OpenStack Platform 클라이언트 사용자의 이름을 재정의합니다.

    • CephClientUserName: openstack
    • NovaRbdPoolName: vms
    • CinderRbdPoolName: 볼륨
    • GlanceRbdPoolName: images
    • CinderBackupRbdPoolName: 백업
    • GnocchiRbdPoolName: 메트릭
  5. CephFS에서 지원하는 공유 파일 시스템 서비스를 배포하는 경우 데이터 및 메타데이터 풀의 이름을 설정합니다.

      ManilaCephFSDataPoolName: manila_data
      ManilaCephFSMetadataPoolName: manila_metadata
    참고

    이러한 이름이 생성한 풀의 이름과 일치하는지 확인합니다.

  6. manila에 대해 생성한 클라이언트 키와 해당 키의 Ceph 사용자 이름을 설정합니다.

      ManilaCephFSCephFSAuthId: 'manila'
      CephManilaClientKey: 'AQDQ991cAAAAABAA0aXFrTnjH9aO39P0iVvYyg=='
    참고

    기본 클라이언트 사용자 이름 ManilaCephFSCephFSAuthIdmanila 입니다. CephManilaClientKey 가 항상 필요합니다.

  7. 사용자 지정 환경 파일에 오버클라우드 매개변수를 추가할 수도 있습니다. 예를 들어 vxlanneutron 네트워크 유형으로 설정하려면 parameter_defaults 에 다음을 추가합니다.

      NeutronNetworkType: vxlan

사용자 지정 환경 파일을 생성한 후 오버클라우드를 배포할 때 포함해야 합니다. 오버클라우드 배포에 대한 자세한 내용은 3.5절. “오버클라우드 배포” 을 참조하십시오.

3.3. 역할에 노드 및 플레이버 할당

Overcloud 배포를 계획하려면 각 역할에 할당할 노드 수와 플레이버를 지정해야 합니다. 모든 Heat 템플릿 매개변수와 마찬가지로 이러한 역할 사양은 사용자 지정 환경 파일의 parameter_defaults 섹션에 선언됩니다(이 경우 /home/stack/templates/ceph-config ).

이를 위해 다음 매개변수를 사용합니다.

표 3.1. 오버클라우드 노드의 역할 및 플레이버

heat 템플릿 매개변수설명

ControllerCount

확장할 컨트롤러 노드 수

OvercloudControlFlavor

컨트롤러 노드에 사용할 플레이버(제어)

ComputeCount

확장할 컴퓨팅 노드 수

OvercloudComputeFlavor

컴퓨팅 노드에 사용할 플레이버(컴퓨팅)

예를 들어 각 역할에 대해 세 개의 노드인 Controller 및 Compute를 배포하도록 오버클라우드를 구성하려면 parameter_defaults 에 다음을 추가합니다.

parameter_defaults:
  ControllerCount: 3
  ComputeCount: 3
  OvercloudControlFlavor: control
  OvercloudComputeFlavor: compute
참고

자세한 내용 및 Heat 템플릿 매개변수의 전체 목록은 Director 설치 및 사용 가이드 의 CLI 툴을 사용하여 Overcloud 생성을 참조하십시오.

3.4. Ceph Storage를 사용하는 Red Hat OpenStack Platform용 Ceph 컨테이너

외부 Ceph 클러스터에서도 Ceph를 사용하도록 OpenStack Platform을 구성하는 데 Ceph 컨테이너가 필요합니다. Red Hat Enterprise Linux 8과 호환되려면 RHOSP(Red Hat OpenStack Platform) 16에 Red Hat Ceph Storage 4가 필요합니다. Ceph Storage 4 컨테이너는 인증이 필요한 레지스트리인 registry.redhat.io에 호스팅됩니다.

heat 환경 매개변수 ContainerImageRegistryCredentials 를 사용하여 registry.redhat.io 에서 인증할 수 있습니다. 자세한 내용은 컨테이너 이미지 준비 매개변수를 참조하십시오.

3.5. 오버클라우드 배포

참고

언더클라우드를 설치하는 동안 undercloud.conf 파일에 generate_service_certificate=false 를 설정합니다. 그러지 않으면 오버클라우드를 배포할 때 신뢰 앵커를 삽입해야 합니다. 신뢰 앵커를 주입하는 방법에 대한 자세한 내용은 Advanced Overcloud Customization 가이드의 Overcloud Public Endpoints에서 SSL/TLS 활성화 를 참조하십시오.

절차

  • 오버클라우드를 생성하려면 openstack overcloud deploy 명령에 추가 인수가 필요합니다.

    $ openstack overcloud deploy --templates \
      -e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible-external.yaml \
      -e /home/stack/templates/ceph-config.yaml \
      -e --ntp-server pool.ntp.org \

    이 예제 명령은 다음 옵션을 사용합니다.

  • --templates - 기본 heat 템플릿 컬렉션 /usr/share/openstack-tripleo-heat-templates/ 에서 오버클라우드를 생성합니다.
  • -e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible-external.yaml - director를 설정하여 기존 Ceph 클러스터를 오버클라우드에 통합합니다.
  • -e /home/stack/templates/ceph-config.yaml - 사용자 지정 환경 파일을 추가하여 -e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible-external.yaml 로 설정된 기본값을 재정의합니다. 이 경우 3.1절. “ceph-ansible 패키지 설치” 에서 생성한 사용자 지정 환경 파일입니다.
  • --ntp-server pool.ntp.org - NTP 서버를 설정합니다.

3.5.1. CephFS에서 지원하는 공유 파일 시스템 서비스에 대한 추가 환경 파일 추가

CephFS에서 지원하는 공유 파일 시스템 서비스를 사용하는 오버클라우드를 배포하는 경우 추가 환경 파일을 추가해야 합니다.

절차

  1. 다음 옵션 중 하나를 사용하여 환경 파일을 생성하고 추가합니다.

    • 기본 CephFS 백엔드 드라이버를 사용하는 오버클라우드를 배포하는 경우 /usr/share/openstack-tripleo-heat-templates/environments/manila-cephfsnative-config.yaml 을 사용합니다.
    • NFS를 통해 CephFS를 사용하는 오버클라우드를 배포하는 경우 /usr/share/openstack-tripleo-heat-templates/environments/manila-cephfsganesha-config.yaml 을 사용합니다.

      NFS를 통한 CephFS의 경우 사용자 지정 컨트롤러 역할도 배포하여 Ganesha CephFS를 NFS 게이트웨이로 실행해야 합니다. 또한 이 역할은 클라이언트에 공유를 제공하도록 격리된 StorageNFS 네트워크를 구성합니다. StorageNFS 네트워크 및 사용자 지정 컨트롤러 역할에 대한 자세한 내용은 공유 파일 시스템 서비스의 NFS 백엔드 가이드를 통해 CephFS에서 업데이트된 환경 배포를 참조하십시오.

  2. 사용하는 CephFS 백엔드에 따라 openstack overcloud deploy 명령의 양식을 변경합니다.

    • 기본 CephFS의 경우:

       $ openstack overcloud deploy --templates \
         -e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible-external.yaml \
         -e /usr/share/openstack-tripleo-heat-templates/environments/manila-cephfsnative-config.yaml \
         -e /home/stack/templates/ceph-config.yaml \
         -e --ntp-server pool.ntp.org
    • NFS를 통한 CephFS의 경우:

        $ openstack overcloud deploy --templates \
            -n /usr/share/openstack-tripleo-heat-templates/network_data_ganesha.yaml \
            -r /home/stack/custom_roles.yaml \
            -e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible-external.yaml \
            -e /usr/share/openstack-tripleo-heat-templates/environments/manila-cephfsganesha-config.yaml \
            -e /home/stack/templates/ceph-config.yaml \
            -e --ntp-server pool.ntp.org
참고

사용자 지정 ceph-config.yaml 환경 파일은 ceph-ansible-external.yaml 파일의 매개 변수와 manila-cephfsnative-config.yaml 파일 또는 manila-cephfsganesha-config.yaml 파일의 매개변수를 재정의합니다. 따라서 ceph- ansible-external.yaml 및 manila- cephfsnative-config.yaml 또는 manila- cephfsganesha-config.yaml 다음에 배포 명령에 사용자 지정 ceph -config.yaml 환경 파일을 포함합니다.

환경 파일 예

parameter_defaults:
    CinderEnableIscsiBackend: false
    CinderEnableRbdBackend: true
    CinderEnableNfsBackend: false
    NovaEnableRbdBackend: true
    GlanceBackend: rbd
    CinderRbdPoolName: "volumes"
    NovaRbdPoolName: "vms"
    GlanceRbdPoolName: "images"
    CinderBackupRbdPoolName: "backups"
    GnocchiRbdPoolName: "metrics"
    CephClusterFSID: <cluster_ID>
    CephExternalMonHost: <IP_address>,<IP_address>,<IP_address>
    CephClientKey: "<client_key>"
    CephClientUserName: "openstack"
    ManilaCephFSDataPoolName: manila_data
    ManilaCephFSMetadataPoolName: manila_metadata
    ManilaCephFSCephFSAuthId: 'manila'
    CephManilaClientKey: '<client_key>'
    ExtraConfig:
        ceph::profile::params::rbd_default_features: '1'

  • <cluster_ID>, <IP_address>, <client_key> 변수를 환경에 적합한 값으로 바꿉니다.

3.5.2. 오브젝트 스토리지용 외부 Ceph Object Gateway(RGW)를 위한 추가 환경 파일 추가

오브젝트 스토리지에 기존 RGW 서비스를 사용하는 오버클라우드를 배포하는 경우 추가 환경 파일을 추가해야 합니다.

절차

  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

3.5.3. 템플릿 및 환경 파일 호출

응답 파일을 사용하여 모든 템플릿과 환경 파일을 호출할 수도 있습니다. 예를 들어 다음 명령을 사용하여 동일한 오버클라우드를 배포할 수 있습니다.

$ openstack overcloud deploy \
  --answers-file /home/stack/templates/answers.yaml \
  --ntp-server pool.ntp.org

이 경우 /home/stack/templates/answers.yaml 응답 파일에는 다음이 포함됩니다.

templates: /usr/share/openstack-tripleo-heat-templates/
environments:
  - /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible-external.yaml \
  - /home/stack/templates/ceph-config.yaml \

자세한 내용은 Director 설치 및 사용 가이드의 오버클라우드 배포에 환경 파일 포함 을 참조하십시오.

3.5.4. OpenStack overcloud deploy 명령 옵션

다음 명령을 입력하여 openstack overcloud deploy 명령과 함께 사용할 수 있는 전체 옵션 목록을 확인할 수 있습니다.

$ openstack help overcloud deploy

자세한 내용은 Director 설치 및 사용 가이드 의 CLI 툴을 사용하여 기본 오버클라우드 구성을 참조하십시오.

3.5.5. 오버클라우드 생성 상태 보기

오버클라우드 생성 프로세스가 시작되고 director가 노드를 프로비저닝합니다. 이 프로세스를 완료하는 데 다소 시간이 걸립니다.

절차

오버클라우드 생성 상태를 보려면 stack 사용자로 별도의 터미널을 열고 다음 명령을 입력합니다.

$ source ~/stackrc
$ openstack stack list --nested

4장. 외부 Ceph Storage 클러스터 통합 확인

오버클라우드를 배포한 후 RHOSP(Red Hat OpenStack Platform) 서비스가 Ceph Storage 클러스터에 쓸 수 있는지 확인합니다.

주의

RHOSP는 Ceph 복제 형식 v2 이상을 사용하지 않습니다. Ceph 복제 형식 v2가 활성화된 Ceph 클러스터에서 이미지 또는 볼륨을 삭제하면 예기치 않은 동작과 데이터가 손실될 수 있습니다. 따라서 Ceph 복제 형식 v2를 활성화하는 다음 방법 중 하나를 사용하지 마십시오.

  • rbd 기본 복제 형식 = 2설정
  • ceph osd set-require-min-compat-client mimic실행

4.1. ID 수집

Ceph Storage 클러스터를 통합했는지 확인하려면 먼저 이미지, 계산 인스턴스 및 볼륨을 만들고 해당 ID를 수집해야 합니다.

절차

  1. Image 서비스(glance)로 이미지를 만듭니다.

    이미지 생성 방법에 대한 자세한 내용은 Creating and Managing Images 가이드의 이미지 가져오기를 참조하십시오.

  2. 나중에 사용할 수 있도록 Glance 이미지 ID를 기록합니다.
  3. Compute(nova) 인스턴스를 만듭니다.

    인스턴스를 만드는 방법에 대한 자세한 내용은 인스턴스 생성 및 관리 가이드에서 인스턴스 시작을 참조하십시오.

  4. 나중에 사용할 수 있도록 nova 인스턴스 ID를 기록합니다.
  5. 블록 스토리지(cinder) 볼륨을 만듭니다.

    블록 스토리지 볼륨을 생성하는 방법에 대한 자세한 내용은 스토리지 가이드에서 볼륨 생성을 참조하십시오.

  6. 나중에 사용할 수 있도록 cinder 볼륨 ID를 기록합니다.

4.2. Ceph Storage 클러스터 확인

외부 Ceph Storage 클러스터를 구성할 때 풀과 client.openstack 사용자를 생성하여 해당 풀에 액세스합니다. 오버클라우드를 배포한 후 client.openstack 사용자의 자격 증명이 포함된 파일을 사용하여 RHOSP(Red Hat OpenStack Platform) 풀의 콘텐츠를 나열할 수 있습니다.

풀의 콘텐츠를 나열하고 Glance 이미지, Compute 인스턴스 및 cinder 볼륨의 ID가 Ceph Storage 클러스터에 있는지 확인합니다.

절차

  1. 언더클라우드 자격 증명을 가져옵니다.

    [stack@undercloud-0 ~]$ source stackrc
  2. 사용 가능한 서버를 나열하여 시스템에 있는 노드의 IP 주소를 검색합니다.

    (undercloud) [stack@undercloud-0 ~]$ openstack server list
    
    +---------------+----------------+---------------+
    | ID | Name | Status | Networks | Image | Flavor |
    +---------------+----------------+---------------+
    | d5a621bd-d109-41ae-a381-a42414397802 | compute-0 | ACTIVE | ctlplane=192.168.24.31 | overcloud-full | compute |
    | 496ab196-d6cb-447d-a118-5bafc5166cf2 | controller-0 | ACTIVE | ctlplane=192.168.24.37 | overcloud-full | controller |
    | c01e730d-62f2-426a-a964-b31448f250b3 | controller-2 | ACTIVE | ctlplane=192.168.24.55 | overcloud-full | controller |
    | 36df59b3-66f3-452e-9aec-b7e7f7c54b86 | controller-1 | ACTIVE | ctlplane=192.168.24.39 | overcloud-full | controller |
    | f8f00497-246d-4e40-8a6a-b5a60fa66483 | compute-1 | ACTIVE | ctlplane=192.168.24.10 | overcloud-full | compute |
  3. SSH를 사용하여 모든 컴퓨팅 노드에 로그인합니다.

    (undercloud) [stack@undercloud-0 ~]$ ssh heat-admin@192.168.24.31
  4. root 사용자로 전환합니다.

    [heat-admin@compute-0 ~]$ sudo su -
  5. /etc/ceph/ceph.conf/etc/ceph/ceph.client.openstack.keyring 파일이 있는지 확인합니다.

    [root@compute-0 ~]# ls -l /etc/ceph/ceph.conf
    
    -rw-r--r--. 1 root root 1170 Sep 29 23:25 /etc/ceph/ceph.conf
    [root@compute-0 ~]# ls -l /etc/ceph/ceph.client.openstack.keyring
    
    -rw-------. 1 ceph ceph 253 Sep 29 23:25 /etc/ceph/ceph.client.openstack.keyring
  6. 다음 명령을 입력하여 nova_compute 컨테이너가 rbd 명령을 사용하여 적절한 풀의 내용을 나열하도록 강제 적용합니다.

    # podman exec nova_compute /usr/bin/rbd --conf /etc/ceph/ceph.conf --keyring /etc/ceph/ceph.client.openstack.keyring --cluster ceph --id openstack ls vms

    풀 이름은 Ceph Storage 클러스터를 구성할 때 생성한 이미지, VM 및 볼륨의 풀 이름과 일치해야 합니다. 자세한 내용은 기존 Ceph Storage 클러스터 구성을 참조하십시오. 이미지, Compute 인스턴스 및 볼륨의 ID는 4.1절. “ID 수집” 에 기록한 ID와 일치해야 합니다.

    참고

    ceph-common 패키지에서 제공하는 /usr/bin/rbd 는 기본적으로 Overcloud 노드에 설치되지 않으므로 예제 명령 앞에 podman exec nova_compute 가 있습니다. 그러나 nova_compute 컨테이너에서 사용할 수 있습니다. 명령은 블록 장치 이미지를 나열합니다. 자세한 내용은 Ceph Storage 블록 장치 가이드의 블록 장치 이미지 나열 을 참조하십시오.

    다음 예제에서는 4.1절. “ID 수집” 의 ID를 사용하여 각 서비스의 ID가 있는지 확인하는 방법을 보여줍니다.

    # podman exec nova_compute /usr/bin/rbd --conf /etc/ceph/ceph.conf --keyring /etc/ceph/ceph.client.openstack.keyring --cluster ceph --id openstack ls images | grep 4485d4c0-24c3-42ec-a158-4d3950fa020b
    
    # podman exec nova_compute /usr/bin/rbd --conf /etc/ceph/ceph.conf --keyring /etc/ceph/ceph.client.openstack.keyring --cluster ceph --id openstack ls vms | grep 64bcb731-e7a4-4dd5-a807-ee26c669482f
    
    # podman exec nova_compute /usr/bin/rbd --conf /etc/ceph/ceph.conf --keyring /etc/ceph/ceph.client.openstack.keyring --cluster ceph --id openstack ls volumes | grep aeac15e8-b67f-454f-9486-46b3d75daff4

4.3. 문제 해결 실패 확인

확인 절차에 실패하는 경우, RHOSP(Red Hat OpenStack Platform)에 대해 생성한 Ceph Storage 풀에서 openstack.client 사용자의 Ceph 키와 Ceph Storage 모니터 IP 또는 호스트 이름을 함께 사용하여 읽기, 쓰기 및 삭제할 수 있는지 확인합니다.

절차

  1. 이 절차에서 수행해야 하는 입력 양을 줄이려면 컴퓨팅 노드에 로그인하고 rbd 명령의 별칭을 생성합니다.

    # alias rbd="podman exec nova_compute /usr/bin/rbd --conf /etc/ceph/ceph.conf --keyring /etc/ceph/ceph.client.openstack.keyring --cluster ceph --id openstack"
  2. 테스트 데이터를 풀에 새 오브젝트로 작성할 수 있는지 확인합니다.

    # rbd create --size 1024 vms/foo
  3. 테스트 데이터가 표시되는지 확인합니다.

    # rbd ls vms | grep foo
  4. 테스트 데이터를 삭제합니다.

    # rbd rm vms/foo
참고

이 절차가 실패하는 경우 Ceph Storage 관리자에게 문의하십시오. 이 절차가 성공하지만 Compute 인스턴스, Glance 이미지 또는 cinder 볼륨을 생성할 수 없는 경우 Red Hat 지원에 문의하십시오.

5장. 오버클라우드 액세스

director는 언더클라우드에서 오버클라우드와의 상호 작용을 설정하고 인증하는 스크립트를 생성합니다. director는 overcloudrc 파일을 stack 사용자 홈 디렉터리에 저장합니다.

절차

  1. overcloudrc 파일을 사용하려면 다음 명령을 입력합니다.

    $ source ~/overcloudrc

    이렇게 하면 언더클라우드 CLI에서 오버클라우드와 상호 작용하는 데 필요한 환경 변수가 로드됩니다.

  2. 언더클라우드로 돌아가려면 다음 명령을 입력합니다.
$ source ~/stackrc

법적 공지

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.