분산 컴퓨팅 노드 및 스토리지 배포

Red Hat OpenStack Platform 17.0

Red Hat OpenStack Platform 분산 컴퓨팅 노드 기술 배포

OpenStack Documentation Team

초록

heat 스택 분리를 통해 에지 사이트 작동을 위해 DCN(Distributed Compute node) 아키텍처를 사용하여 RHOSP(Red Hat OpenStack Platform)를 배포할 수 있습니다. 각 사이트에는 Image 서비스(glance) 다중 저장소에 대한 자체 Ceph 스토리지 백엔드가 있을 수 있습니다.

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

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

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

문서 개선을 위한 의견을 보내 주십시오. 우리가 어떻게 그것을 더 잘 만들 수 있는지 알려주십시오.

Direct Documentation feedback(DDF) 함수 사용

특정 문장, 단락 또는 코드 블록에 대한 직접 코멘트를 위해서는 DDF 함수 추가 를 사용하십시오.

  1. Multi-page HTML 형식으로 설명서를 확인합니다.
  2. 문서의 오른쪽 위에 사용자 지정 단추가 표시되는지 확인합니다.Ensure that you see the Feedback button in the upper right corner of the document.
  3. 주석하려는 텍스트 부분을 강조 표시합니다.
  4. 피드백 추가를 클릭합니다.
  5. 코멘트와 함께 피드백 추가 필드를 완료합니다.
  6. 선택 사항: 문서 팀에서 문제 해결을 위해 연락할 수 있도록 이메일 주소를 추가하십시오.
  7. 제출을 클릭합니다.

1장. DCN 이해

DCN(Distributed Compute node) 아키텍처는 공통 중앙 집중식 컨트롤 플레인을 공유하는 동안 원격 컴퓨팅 및 스토리지 노드를 원격으로 배포할 수 있는 에지 사용 사례입니다. DCN 아키텍처를 사용하면 더 높은 성능의 운영 요구에 전략적으로 워크로드를 배치할 수 있습니다.

중앙 위치는 모든 역할로 구성될 수 있지만 최소한 세 개의 컨트롤러가 필요합니다. 계산 노드는 에지 및 중앙 위치에 있을 수 있습니다.

DCN 아키텍처는 허브이며 스포크 라우팅된 네트워크 배포입니다. DCN은 Red Hat OpenStack Platform director와의 라우팅 프로비저닝 및 컨트롤 플레인 네트워킹의 스파인 및 리프 배포와 유사합니다.

  • 허브는 코어 라우터 및 데이터 센터 게이트웨이(DC-GW)가 있는 중앙 사이트입니다.
  • 이 대화는 원격 에지 또는 리프입니다.

엣지 위치에는 컨트롤러가 없으므로 Red Hat OpenStack Platform의 기존 배포와 아키텍처가 다릅니다.

  • 컨트롤 플레인 서비스는 중앙 위치에서 원격으로 실행됩니다.
  • Pacemaker가 설치되지 않았습니다.
  • Block Storage 서비스(cinder)는 활성/활성 모드로 실행됩니다.
  • etcd는 DVR(Distributed Lock Manager)으로 배포됩니다.
높은 수준의 dcn

1.1. 분산 계산 노드 아키텍처에 필요한 소프트웨어

다음 표는 DCN(Distributed compute node) 아키텍처에 Red Hat OpenStack Platform을 배포하는 데 필요한 소프트웨어 및 최소 버전을 보여줍니다.

플랫폼버전선택 사항

Red Hat Enterprise Linux

9

없음

Red Hat OpenStack Platform

17.0

없음

Red Hat Ceph Storage

5

있음

1.2. 다중 스택 설계

DCN 설계와 함께 RHOSP(Red Hat OpenStack Platform)를 배포할 때 여러 스택 배포 및 관리에 Red Hat director의 기능을 사용하여 각 사이트를 별도의 스택으로 배포합니다.

배포가 Red Hat OpenStack Platform 13에서 업그레이드되는 경우를 제외하고 DCN 아키텍처를 단일 스택으로 관리하는 것은 지원되지 않습니다. 기존 스택을 분할하는 방법은 지원되지 않지만 기존 배포에 스택을 추가할 수 있습니다. 자세한 내용은 A.3절. “다중 스택 배포로 마이그레이션”의 내용을 참조하십시오.

중앙 위치는 RHOSP의 기존 스택 배포이지만 중앙 스택을 사용하여 컴퓨팅 노드 또는 Red Hat Ceph 스토리지를 배포할 필요는 없습니다.

DCN을 사용하면 각 위치를 별도의 가용 영역(AZ)으로 배포합니다.

1.3. DCN 스토리지

스토리지 없이 또는 하이퍼컨버지드 노드의 Ceph를 사용하여 각 에지 사이트를 배포할 수 있습니다. 배포하는 스토리지는 이를 배포하는 사이트 전용입니다.

DCN 아키텍처에서는 Glance 다중 저장소를 사용합니다. 스토리지 없이 배포된 에지 사이트의 경우 이미지를 Compute 서비스(nova) 캐시에 캐시하고 저장할 수 있도록 추가 툴링을 사용할 수 있습니다. nova에서 Glance 이미지를 캐싱하면 WAN 링크를 통해 이미지를 다운로드하는 프로세스를 방지하여 인스턴스의 부팅 시간을 단축할 수 있습니다. 자세한 내용은 10장. glance 이미지를 nova로 캐싱의 내용을 참조하십시오.

1.4. DCN 에지

분산 Compute 노드 아키텍처를 사용하면 중앙 사이트에 제어 노드를 배포하고 이러한 컨트롤러를 사용하여 지리적으로 분산된 에지 사이트를 관리합니다. 에지 사이트를 배포할 때 컴퓨팅 노드만 배포하므로 에지 사이트를 Red Hat OpenStack Platform의 기존 배포와 아키텍처적으로 다릅니다. 에지 사이트에서 인스턴스를 시작하면 필요한 이미지가 로컬 Image 서비스(glance) 저장소에 자동으로 복사됩니다. Glance 다중 저장소를 사용하여 인스턴스를 시작하는 동안 시간을 절약하여 중앙 이미지 저장소에서 에지 사이트로 이미지를 복사할 수 있습니다. 자세한 내용은 여러 저장소가 있는 이미지 서비스를 참조하십시오.

엣지 사이트에서:

  • 컨트롤 플레인 서비스는 중앙 위치에서 원격으로 실행됩니다.
  • Pacemaker는 DCN 사이트에서 실행되지 않습니다.
  • Block Storage 서비스(cinder)는 활성/활성 모드로 실행됩니다.
  • etcd는 DVR(Distributed Lock Manager)으로 배포됩니다.

2장. DCN(Distributed Compute Node) 배포 계획

DCN 아키텍처를 계획할 때 필요한 기술이 사용 가능하고 지원되는지 확인합니다.

2.1. DCN 아키텍처 스토리지 고려 사항

현재 DCN 아키텍처에서는 다음 기능이 지원되지 않습니다.

  • 에지 사이트 간 볼륨 스냅샷 복사. 볼륨에서 이미지를 만들고 glance를 사용하여 이미지를 복사하여 이 문제를 해결할 수 있습니다. 이미지가 복사되면 해당 이미지에서 볼륨을 생성할 수 있습니다.
  • 에지의 Ceph Rados 게이트웨이(RGW)입니다.
  • 에지의 CephFS.
  • 에지 사이트의 인스턴스 고가용성(HA)입니다.
  • 에지 사이트 간 실시간 마이그레이션 또는 중앙 위치에서 에지 사이트로의 실시간 마이그레이션. 사이트 경계 내에서 인스턴스를 실시간 마이그레이션할 수 있습니다.
  • 사이트 간 RBD 미러링.

또한 다음을 고려해야 합니다.

  • 에지 사이트에 복사하기 전에 이미지를 중앙 위치에 업로드해야 합니다. 각 이미지의 복사본이 중앙 위치의 Image 서비스(glance)에 있어야 합니다.
  • 이미지, Compute 및 Block Storage 서비스에 RBD 스토리지 드라이버를 사용해야 합니다.
  • 각 사이트에 대해 고유한 가용성 영역을 할당하고 NovaComputeAvailabilityZone 및 CinderStorageAvailabilityZone 매개변수에 동일한 값을 사용합니다.
  • 에지 사이트에서 중앙 위치로 오프라인 볼륨을 마이그레이션하거나 그 반대의 경우도 마찬가지입니다. 에지 사이트 간에 직접 볼륨을 마이그레이션할 수 없습니다.

2.2. DCN 아키텍처 네트워킹 고려 사항

현재 DCN 아키텍처에서는 다음 기능이 지원되지 않습니다.

  • Octavia
  • DPDK 노드의 DHCP
  • Process Flower Hardware Offload를 위한 conntrack

Process Flower 하드웨어 오프로드에 대한 conntrack은 DCN에서 기술 프리뷰로 제공되므로 이러한 솔루션을 함께 사용하면 Red Hat에서 완전히 지원되지 않습니다. 이 기능은 테스트용 DCN과만 사용해야 하며 프로덕션 환경에 배포해서는 안 됩니다. 기술 프리뷰 기능에 대한 자세한 내용은 적용 범위 상세 정보를 참조하십시오.

다음 ML2/OVS 기술이 완전히 지원됩니다.

  • DPDK 노드에서 DHCP가 없는 OVS-DPDK
  • SR-IOV
  • conntrack없이 빈곤의 하드웨어 오프로드
  • 에지에 네트워크 노드가 있는 Neutron 가용성 영역(AZ)은 사이트당 하나의 AZ입니다.
  • 라우팅 공급자 네트워크

다음 ML2/OVN 네트워킹 기술이 완전히 지원됩니다.

  • DPDK 노드에서 DHCP가 없는 OVS-DPDK
  • SR-IOV(DHCP 제외)
  • conntrack없이 빈곤의 하드웨어 오프로드
  • 라우팅 공급자 네트워크
  • Neutron AZ가 지원되는 OVN GW (네트워크 노드)

또한 다음을 고려해야 합니다.

  • 네트워크 대기 시간: 허용 가능한 성능을 유지하기 위해 예상 동시 API 작업 수와 함께 RTT( round-trip time)에서 측정된 대기 시간을 분산합니다. 최대 TCP/IP 처리량은 RTT에 비례합니다. 커널 TCP 매개 변수를 조정하여 대기 시간이 높은 연결을 통해 일부 문제를 완화할 수 있습니다. 교차 사이트 통신이 100ms를 초과하는 경우 Red Hat 지원팀에 문의하십시오.
  • 네트워크 삭제: 에지 사이트에서 중앙 사이트에 대한 연결이 일시적으로 손실되면 중단 기간 동안 영향을 받는 에지 사이트에서 OpenStack 컨트롤 플레인 API 또는 CLI 작업을 실행할 수 없습니다. 예를 들어 에지 사이트의 Compute 노드는 인스턴스의 스냅샷을 만들거나 인증 토큰을 발행하거나 이미지를 삭제할 수 없습니다. 일반 OpenStack 컨트롤 플레인 API 및 CLI 작업은 이 중단 중에 계속 작동하며 연결이 작동하는 다른 에지 사이트를 계속 제공할 수 있습니다. 이미지 유형: Ceph 스토리지로 DCN 아키텍처를 배포할 때 원시 이미지를 사용해야 합니다.
  • 이미지 크기 조정:

    • 오버클라우드 노드 이미지 - 오버클라우드 노드 이미지는 중앙 언더클라우드 노드에서 다운로드됩니다. 이러한 이미지는 프로비저닝 중에 중앙 사이트에서 엣지 사이트로 모든 필요한 네트워크를 통해 전송될 가능성이 큰 파일입니다.
    • 인스턴스 이미지: 에지에는 블록 스토리지가 없는 경우, 이미지 서비스 이미지가 처음 사용하는 동안 WAN을 트래버스합니다. 이미지는 모든 후속 사용을 위해 대상 엣지 노드에 로컬로 복사되거나 캐시됩니다. Glance 이미지에는 크기 제한이 없습니다. 전송 시간은 사용 가능한 대역폭 및 네트워크 대기 시간에 따라 다릅니다.

      에지에 블록 스토리지가 있는 경우 에지에서 더 빠른 부팅 시간을 위해 WAN 비동기적으로 이미지를 복사합니다.

  • 공급자 네트워크: DCN 배포에 권장되는 네트워킹 접근 방식입니다. 원격 사이트에서 공급자 네트워크를 사용하는 경우 Networking 서비스(neutron)가 사용 가능한 네트워크를 연결할 수 있는 위치에 대한 제한 또는 검사를 수행하지 않는 것을 고려해야 합니다. 예를 들어 에지 사이트 A에서만 공급자 네트워크를 사용하는 경우 에지 사이트 B의 공급자 네트워크에 연결하지 않도록 해야 합니다. 이는 컴퓨팅 노드에 바인딩할 때 공급자 네트워크에 대한 유효성 검사가 없기 때문입니다.
  • 사이트별 네트워크: 특정 사이트에 고유한 네트워크를 사용하는 경우 DCN 네트워킹의 제한 사항이 발생합니다. 컴퓨팅 노드를 사용하여 중앙 집중식 neutron 컨트롤러를 배포할 때 neutron에는 특정 컴퓨팅 노드를 원격 노드로 식별하는 트리거가 없습니다. 결과적으로 Compute 노드는 다른 Compute 노드 목록을 수신하여 서로 자동으로 터널을 형성하며 터널은 에지에서 중앙 사이트를 통해 엣지로 구성됩니다. VXLAN 또는 Geneve를 사용하는 경우 모든 사이트의 모든 컴퓨팅 노드는 로컬 또는 원격 상태인지 여부에 관계없이 다른 모든 컴퓨팅 노드 및 컨트롤러 노드로 터널을 형성합니다. 모든 위치에서 동일한 neutron 네트워크를 사용하는 경우에는 이 문제가 발생하지 않습니다. VLAN을 사용할 때 neutron은 모든 컴퓨팅 노드에 동일한 브릿지 매핑이 있고 모든 VLAN을 모든 사이트에서 사용할 수 있을 것으로 예상합니다.
  • 추가 사이트: 중앙 사이트에서 추가 원격 사이트로 확장해야 하는 경우 Red Hat OpenStack Platform director에서 openstack CLI를 사용하여 새 네트워크 세그먼트 및 서브넷을 추가할 수 있습니다.
  • 에지 서버가 사전 프로비저닝되지 않은 경우 라우팅된 세그먼트에서 인트로스펙션 및 프로비저닝을 위해 DHCP 릴레이를 구성해야 합니다.
  • 라우팅은 클라우드 또는 각 에지 사이트를 허브에 연결하는 네트워킹 인프라에 구성해야 합니다. 각 Red Hat OpenStack Platform 클러스터 네트워크(외부, 내부 API 등)에 L3 서브넷을 할당하는 네트워킹 설계를 구현해야 합니다.

3장. 언더클라우드에서 라우팅된 spine-leaf 구성

이 섹션에서는 구성 가능 네트워크를 사용하여 스파인-리프형을 수용하도록 언더클라우드를 구성하는 방법에 대한 사용 사례에 대해 설명합니다.

3.1. 스파인 리프 프로비저닝 네트워크 구성

스파인 리프 인프라에 대한 프로비저닝 네트워크를 구성하려면 undercloud.conf 파일을 편집하고 다음 절차에 포함된 관련 매개변수를 설정합니다.

절차

  1. stack 사용자로 언더클라우드에 로그인합니다.
  2. undercloud.conf 파일이 없는 경우 샘플 템플릿 파일을 복사합니다.

    [stack@director ~]$ cp /usr/share/python-tripleoclient/undercloud.conf.sample ~/undercloud.conf
  3. undercloud.conf 파일을 편집합니다.
  4. [DEFAULT] 섹션에서 다음 값을 설정합니다.

    1. local_ipleaf0 에서 언더클라우드 IP로 설정합니다.

      local_ip = 192.168.10.1/24
    2. undercloud_public_host 를 언더클라우드의 외부 상대 IP 주소로 설정합니다.

      undercloud_public_host = 10.1.1.1
    3. undercloud_admin_host 를 언더클라우드의 관리 IP 주소로 설정합니다. 이 IP 주소는 일반적으로 leaf0에 있습니다.

      undercloud_admin_host = 192.168.10.2
    4. local_interface 를 로컬 네트워크의 bridge로 설정합니다.

      local_interface = eth1
    5. enable_routed_networkstrue 로 설정합니다.

      enable_routed_networks = true
    6. subnets 매개변수를 사용하여 서브넷 목록을 정의합니다. 라우팅된 스파크 및 리프에서 각 L2 세그먼트에 대해 하나의 서브넷을 정의합니다.

      subnets = leaf0,leaf1,leaf2
    7. local_subnet 매개변수를 사용하여 로컬의 실제 L2 세그먼트와 언더클라우드와 연결된 서브넷을 지정합니다.

      local_subnet = leaf0
    8. undercloud_nameservers 의 값을 설정합니다.

      undercloud_nameservers = 10.11.5.19,10.11.5.20
      작은 정보

      /etc/resolv.conf를 확인하여 언더클라우드 이름 서버에 사용되는 DNS 서버의 현재 IP 주소를 찾을 수 있습니다.

  5. subnets 매개변수에 정의된 각 서브넷에 대해 새 섹션을 생성합니다.

    [leaf0]
    cidr = 192.168.10.0/24
    dhcp_start = 192.168.10.10
    dhcp_end = 192.168.10.90
    inspection_iprange = 192.168.10.100,192.168.10.190
    gateway = 192.168.10.1
    masquerade = False
    
    [leaf1]
    cidr = 192.168.11.0/24
    dhcp_start = 192.168.11.10
    dhcp_end = 192.168.11.90
    inspection_iprange = 192.168.11.100,192.168.11.190
    gateway = 192.168.11.1
    masquerade = False
    
    [leaf2]
    cidr = 192.168.12.0/24
    dhcp_start = 192.168.12.10
    dhcp_end = 192.168.12.90
    inspection_iprange = 192.168.12.100,192.168.12.190
    gateway = 192.168.12.1
    masquerade = False
  6. undercloud.conf 파일을 저장합니다.
  7. 언더클라우드 설치 명령을 실행합니다.

    [stack@director ~]$ openstack undercloud install

이 구성은 프로비저닝 네트워크 또는 컨트롤 플레인에 세 개의 서브넷을 생성합니다. 오버클라우드는 각 네트워크를 사용하여 각 리프 내에 시스템을 프로비저닝합니다.

언더클라우드에 대한 DHCP 요청의 적절한 릴레이를 확인하려면 DHCP 릴레이를 구성해야 할 수 있습니다.

3.2. DHCP 릴레이 구성

요청을 전달하려는 원격 네트워크 세그먼트에 연결된 스위치, 라우터 또는 서버에서 DHCP 릴레이 서비스를 실행합니다.

참고

언더클라우드에서 DHCP 릴레이 서비스를 실행하지 마십시오.

언더클라우드는 프로비저닝 네트워크에서 두 개의 DHCP 서버를 사용합니다.

  • 인트로스펙션 DHCP 서버.
  • 프로비저닝 DHCP 서버.

DHCP 요청을 언더클라우드의 두 DHCP 서버로 전달하도록 DHCP 릴레이를 구성해야 합니다.

UDP 브로드캐스트를 이를 지원하는 장치로 사용하여 언더클라우드 프로비저닝 네트워크가 연결된 L2 네트워크 세그먼트로 DHCP 요청을 릴레이할 수 있습니다. 또는 DHCP 요청을 특정 IP 주소로 릴레이하는 UDP 유니캐스트를 사용할 수 있습니다.

참고

특정 장치 유형의 DHCP 릴레이 구성은 이 문서의 범위를 벗어납니다. 이 문서에서는 ISC DHCP 소프트웨어의 구현을 사용하여 DHCP 릴레이 구성 예제를 참조합니다. 자세한 내용은 설명서 페이지 dhcrelay(8)를 참조하십시오.

중요

DHCP 옵션 79는 일부 릴레이, 특히 DHCPv6 주소를 제공하는 릴레이와 원래 MAC 주소를 통과하지 않는 릴레이에 필요합니다. 자세한 내용은 RFC6939 를 참조하십시오.

브로드캐스트 DHCP 릴레이

이 방법은 UDP 브로드캐스트 트래픽을 사용하여 DHCP 서버 또는 서버가 상주하는 L2 네트워크 세그먼트에 DHCP 요청을 중계합니다. 네트워크 세그먼트의 모든 장치는 브로드캐스트 트래픽을 수신합니다. UDP 브로드캐스트를 사용하는 경우 언더클라우드의 두 DHCP 서버는 중계 DHCP 요청을 수신합니다. 구현에 따라 인터페이스 또는 IP 네트워크 주소를 지정하여 이 구성을 구성할 수 있습니다.

인터페이스
DHCP 요청이 중계되는 L2 네트워크 세그먼트에 연결된 인터페이스를 지정합니다.
IP 네트워크 주소
DHCP 요청이 중계되는 IP 네트워크의 네트워크 주소를 지정합니다.

유니캐스트 DHCP 릴레이

이 방법은 UDP 유니캐스트 트래픽을 사용하여 특정 DHCP 서버로 DHCP 요청을 중계합니다. UDP 유니캐스트를 사용하는 경우 DHCP 릴레이를 제공하여 DHCP 요청을 언더클라우드에서 인트로스펙션에 사용되는 인터페이스와 OpenStack Networking(neutron) 서비스에서 생성하는 네트워크 네임스페이스의 IP 주소 둘 다에 할당하여 ctlplane 네트워크에 대한 DHCP 서비스를 호스팅할 수 있는 장치를 구성해야 합니다.

인트로스펙션에 사용되는 인터페이스는 undercloud.conf 파일에서 inspection_interface 로 정의된 인터페이스입니다. 이 매개변수를 설정하지 않은 경우 언더클라우드의 기본 인터페이스는 br-ctlplane 입니다.

참고

인트로스펙션에 br-ctlplane 인터페이스를 사용하는 것이 일반적입니다. undercloud.conf 파일에서 local_ip 로 정의한 IP 주소는 br-ctlplane 인터페이스에 있습니다.

Neutron DHCP 네임스페이스에 할당된 IP 주소는 undercloud.conf 파일의 local_subnet 에 대해 구성하는 IP 범위에서 사용 가능한 첫 번째 주소입니다. IP 범위의 첫 번째 주소는 구성에서 dhcp_start 로 정의한 주소입니다. 예를 들어, 192.168.10.10 은 다음 구성을 사용하는 경우 IP 주소입니다.

[DEFAULT]
local_subnet = leaf0
subnets = leaf0,leaf1,leaf2

[leaf0]
cidr = 192.168.10.0/24
dhcp_start = 192.168.10.10
dhcp_end = 192.168.10.90
inspection_iprange = 192.168.10.100,192.168.10.190
gateway = 192.168.10.1
masquerade = False
주의

DHCP 네임스페이스의 IP 주소가 자동으로 할당됩니다. 대부분의 경우 이 주소는 IP 범위의 첫 번째 주소입니다. 이 문제가 있는지 확인하려면 언더클라우드에서 다음 명령을 실행합니다.

$ openstack port list --device-owner network:dhcp -c "Fixed IP Addresses"
+----------------------------------------------------------------------------+
| Fixed IP Addresses                                                         |
+----------------------------------------------------------------------------+
| ip_address='192.168.10.10', subnet_id='7526fbe3-f52a-4b39-a828-ec59f4ed12b2' |
+----------------------------------------------------------------------------+
$ openstack subnet show 7526fbe3-f52a-4b39-a828-ec59f4ed12b2 -c name
+-------+--------+
| Field | Value  |
+-------+--------+
| name  | leaf0  |
+-------+--------+

dhcrelay 구성 예

다음 예제에서 dhcp 패키지의 dhcrelay 명령은 다음 구성을 사용합니다.

  • 들어오는 DHCP 요청을 릴레이하는 인터페이스: eth1,eth2eth3.
  • 네트워크 세그먼트의 언더클라우드 DHCP 서버가 eth0 에 연결됩니다.
  • 인트로스펙션에 사용되는 DHCP 서버는 IP 주소에서 수신 대기 중입니다. 192.168.10.1.
  • 프로비저닝에 사용되는 DHCP 서버는 IP 주소 192.168.10.10 에서 수신 대기 중입니다.

그러면 다음과 같은 dhcrelay 명령이 생성됩니다.

  • dhcrelay 버전 4.2.x:

    $ sudo dhcrelay -d --no-pid 192.168.10.10 192.168.10.1 \
      -i eth0 -i eth1 -i eth2 -i eth3
  • dhcrelay 버전 4.3.x 이상:

    $ sudo dhcrelay -d --no-pid 192.168.10.10 192.168.10.1 \
      -iu eth0 -id eth1 -id eth2 -id eth3

Cisco IOS 라우팅 스위치 구성 예

이 예에서는 다음 Cisco IOS 구성을 사용하여 다음 작업을 수행합니다.

  • provisioning 네트워크에 사용할 VLAN을 구성합니다.
  • 리프의 IP 주소를 추가합니다.
  • IP 주소에서 수신 대기하는 인트로스펙션 DHCP 서버에 UDP 및 BOOTP 요청을 전달합니다. 192.168.10.1.
  • UDP 및 BOOTP 요청을 IP 주소 192.168.10.10 에서 수신 대기하는 프로비저닝 DHCP 서버에 전달합니다.
interface vlan 2
ip address 192.168.24.254 255.255.255.0
ip helper-address 192.168.10.1
ip helper-address 192.168.10.10
!

이제 provisioning 네트워크를 구성했으므로 나머지 오버클라우드 리프 네트워크를 구성할 수 있습니다.

3.3. 리프 노드의 역할 지정

각 리프 네트워크의 각 역할에는 해당 리프에 노드를 태그할 수 있도록 플레이버 및 역할 할당이 필요합니다. 각 플레이버를 생성하고 역할에 할당하려면 다음 단계를 완료합니다.

절차

  1. stackrc 파일을 소싱합니다.

    [stack@director ~]$ source ~/stackrc
  2. 노드 목록을 검색하여 해당 UUID를 확인합니다.

    (undercloud)$ openstack baremetal node list
  3. 리프 네트워크 및 역할을 식별하는 사용자 정의 리소스 클래스를 사용하여 역할에 대해 지정할 각 베어 메탈 노드를 할당합니다.

    openstack baremetal node set \
     --resource-class baremetal.<ROLE> <node>
    • <ROLE>을 역할을 식별하는 이름으로 바꿉니다.
    • <node>를 베어 메탈 노드의 ID로 바꿉니다.

      예를 들어 UUID 58c3d07e-24f2-48a7-bbb6-6843f0e8ee13을 Leaf2의 Compute 역할에 태그하려면 다음 명령을 입력합니다.

      (undercloud)$ openstack baremetal node set \
       --resource-class baremetal.COMPUTE-LEAF2 58c3d07e-24f2-48a7-bbb6-6843f0e8ee13
  4. 아직 정의되지 않은 경우 overcloud-baremetal-deploy.yaml 에 각 역할을 추가합니다.
  5. 역할에 대해 노드에 할당할 리소스 클래스를 정의합니다.

    - name: <role>
      count: 1
      defaults:
        resource_class: baremetal.<ROLE>
    • <role>을 역할 이름으로 바꿉니다.
    • <ROLE>을 역할을 식별하는 이름으로 바꿉니다.
  6. baremetal-deploy.yaml 파일에서 역할의 노드에 할당할 리소스 클래스를 정의합니다. 배포 중인 역할, 프로필, 수량 및 관련 네트워크를 지정합니다.

    - name: <role>
      count: 1
      hostname_format: <role>-%index%
      ansible_playbooks:
        - playbook: bm-deploy-playbook.yaml
      defaults:
        resource_class: baremetal.<ROLE>
        profile: control
        networks:
          - network: external
            subnet: external_subnet
          - network: internal_api
            subnet: internal_api_subnet01
          - network: storage
            subnet: storage_subnet01
          - network: storage_mgmt
            subnet: storage_mgmt_subnet01
          - network: tenant
            subnet: tenant_subnet01
        network_config:
          template: templates/multiple_nics/multiple_nics_dvr.j2
          default_route_network:
            - external
    • <role>을 역할 이름으로 바꿉니다.
    • <ROLE>을 역할을 식별하는 이름으로 바꿉니다.

      참고

      배포 중인 모든 스택에 대해 baremetal-deploy.yaml 환경 파일을 /home/stack/<stack> 에서 생성해야 합니다.

3.4. 베어 메탈 노드 포트를 컨트롤 플레인 네트워크 세그먼트에 매핑

L3 라우팅 네트워크에서 배포를 활성화하려면 베어 메탈 포트에서 physical_network 필드를 구성해야 합니다. 각 베어 메탈 포트는 OpenStack Bare Metal(ironic) 서비스의 베어 메탈 노드와 연결됩니다. 물리적 네트워크 이름은 언더클라우드 구성의 subnets 옵션에 포함하는 이름입니다.

참고

undercloud.conf 파일에서 local_subnet 로 지정된 서브넷의 물리적 네트워크 이름은 항상 ctlplane 라고 합니다.

절차

  1. stackrc 파일을 소싱합니다.

    $ source ~/stackrc
  2. 베어 메탈 노드를 확인합니다.

    $ openstack baremetal node list
  3. 베어 메탈 노드가 등록 또는 관리 가능한지 확인합니다. 베어 메탈 노드가 이러한 상태 중 하나에 없는 경우 baremetal 포트에 physical_network 속성을 설정하는 명령이 실패합니다. 모든 노드를 manageable 상태로 설정하려면 다음 명령을 실행합니다.

    $ for node in $(openstack baremetal node list -f value -c Name); do openstack baremetal node manage $node --wait; done
  4. 어떤 baremetal 포트가 어떤 baremetal 노드와 연결되어 있는지 확인합니다.

    $ openstack baremetal port list --node <node-uuid>
  5. 포트의 물리적 네트워크 매개 변수를 설정합니다. 아래 예제에서는 leaf0,leaf1, leaf2 와 같은 구성에 세 개의 서브넷이 정의되어 있습니다. local_subnet은 leaf0 입니다. local_subnet 의 물리적 네트워크는 항상 ctlplane 이므로 leaf0 에 연결된 baremetal 포트는 ctlplane을 사용합니다. 나머지 포트는 다른 리프 이름을 사용합니다.

    $ openstack baremetal port set --physical-network ctlplane <port-uuid>
    $ openstack baremetal port set --physical-network leaf1 <port-uuid>
    $ openstack baremetal port set --physical-network leaf2 <port-uuid>
  6. 오버클라우드를 배포하기 전에 노드를 인트로스펙션합니다. 배포에 노드를 사용할 수 있는 것으로 설정하려면 --all-manageable--provide 옵션을 포함합니다.

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

3.5. 스파인-리프 프로비저닝 네트워크에 새 리프 추가

새 물리적 사이트 추가를 포함할 수 있는 네트워크 용량을 늘릴 때는 새 리프와 서브넷을 Red Hat OpenStack Platform 스파인-리프 프로비저닝 네트워크에 추가해야 할 수 있습니다. 오버클라우드에서 리프를 프로비저닝할 때 해당 언더클라우드 리프가 사용됩니다.

사전 요구 사항

  • RHOSP 배포에서는 스파인-리프 네트워크 토폴로지를 사용합니다.

절차

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

    $ source ~/stackrc
  3. /home/stack/undercloud.conf 파일에서 다음을 수행합니다.

    1. subnets 매개변수를 찾고 추가하는 리프의 새 서브넷을 추가합니다.

      서브넷은 라우팅된 스파드 및 리프의 L2 세그먼트를 나타냅니다.

      예제

      이 예제에서는 새 리프(leaf3)에 대해 새 서브넷(leaf3)을 추가합니다.

      subnets = leaf0,leaf1,leaf2,leaf3
    2. 추가한 서브넷의 섹션을 생성합니다.

      예제

      이 예제에서는 새 서브넷 (leaf3)에 대한 섹션 [leaf3] 이 추가되었습니다.

      [leaf0]
      cidr = 192.168.10.0/24
      dhcp_start = 192.168.10.10
      dhcp_end = 192.168.10.90
      inspection_iprange = 192.168.10.100,192.168.10.190
      gateway = 192.168.10.1
      masquerade = False
      
      [leaf1]
      cidr = 192.168.11.0/24
      dhcp_start = 192.168.11.10
      dhcp_end = 192.168.11.90
      inspection_iprange = 192.168.11.100,192.168.11.190
      gateway = 192.168.11.1
      masquerade = False
      
      [leaf2]
      cidr = 192.168.12.0/24
      dhcp_start = 192.168.12.10
      dhcp_end = 192.168.12.90
      inspection_iprange = 192.168.12.100,192.168.12.190
      gateway = 192.168.12.1
      masquerade = False
      
      [leaf3]
      cidr = 192.168.13.0/24
      dhcp_start = 192.168.13.10
      dhcp_end = 192.168.13.90
      inspection_iprange = 192.168.13.100,192.168.13.190
      gateway = 192.168.13.1
      masquerade = False
  4. undercloud.conf 파일을 저장합니다.
  5. 언더클라우드를 다시 설치합니다.

    $ openstack undercloud install

4장. DCN 배포를 위한 오버클라우드 템플릿 준비

4.1. 별도의 heat 스택을 사용하기 위한 사전 요구 사항

별도의 heat 스택을 사용하여 배포를 생성하기 전에 다음 사전 요구 사항을 충족해야 합니다.

  • Red Hat OpenStack Platform director 17.0에 설치된 인스턴스입니다.
  • Ceph Storage 사용자의 경우: Red Hat Ceph Storage 5에 액세스합니다.
  • 중앙 위치: 중앙 컨트롤러 노드로 제공할 수 있는 노드 3개 세 개의 컨트롤러 노드는 모두 동일한 heat 스택에 있어야 합니다. 별도의 heat 스택에서 컨트롤러 노드 또는 컨트롤 플레인 서비스를 분할할 수 없습니다.
  • 에지에서 Ceph 스토리지를 배포하려는 경우 Ceph 스토리지가 중앙 위치에 있어야 합니다.
  • 추가 DCN 사이트의 경우 3개의 HCI 컴퓨팅 노드.
  • 모든 노드를 사전 프로비저닝하거나 중앙 배포 네트워크에서 PXE 부팅을 수행할 수 있어야 합니다. DHCP 릴레이를 사용하여 DCN에 이 연결을 활성화할 수 있습니다.
  • ironic에서 모든 노드를 세부적으로 검사했습니다.
  • <role>HostnameFormat 매개변수를 기본값인 %stackname%-<role>-%index%로 남겨 두는 것이 좋습니다. %stackname% 접두사를 포함하지 않는 경우 오버클라우드는 다른 스택의 분산 컴퓨팅 노드에 동일한 호스트 이름을 사용합니다. 분산 계산 노드에서 %stackname% 접두사를 사용하여 다른 에지 사이트와 노드를 구별하는지 확인합니다. 예를 들어 dcn0dcn1 이라는 에지 사이트를 배포하는 경우 스택 이름 접두사를 사용하면 언더클라우드에서 openstack server list 명령을 실행할 때 dcn0-distributedcompute-0과 dcn1-distributedcompute-0을 구별하는 데 도움이 됩니다.
  • centralrc 인증 파일을 가져와 에지 사이트의 워크로드와 중앙 위치에서 워크로드를 예약합니다. 에지 사이트에 대해 자동으로 생성되는 인증 파일이 필요하지 않습니다.

4.2. heat 스택 배포 예의 제한 사항

이 문서에서는 Red Hat OpenStack Platform에서 별도의 heat 스택을 사용하는 배포 예제를 제공합니다. 이 예제 환경에는 다음과 같은 제한 사항이 있습니다.

  • 스파인/리프트 네트워킹 - 이 가이드의 예제에서는 DCN(Distributed Compute Node) 배포에 필요한 라우팅 요구 사항을 설명하지 않습니다.
  • Ironic DHCP Relay - 이 안내서에는 DHCP 릴레이를 사용하여 Ironic을 구성하는 방법은 포함되어 있지 않습니다.

4.3. 별도의 heat 스택 배포 설계

별도의 heat 스택 내에서 배포를 세그먼트화하려면 먼저 컨트롤 플레인을 사용하여 단일 오버클라우드를 배포해야 합니다. 그런 다음 DCN(Distributed Compute node) 사이트에 대해 별도의 스택을 생성할 수 있습니다. 다음 예제에서는 다른 노드 유형에 대한 별도의 스택을 보여줍니다.

  • 컨트롤러 노드: 예를 들어 중앙 이라는 별도의 heat 스택(예:)은 컨트롤러를 배포합니다. DCN 사이트의 heat 스택을 새로 생성할 때는 중앙 스택의 데이터로 만들어야 합니다. 인스턴스 관리 작업에 컨트롤러 노드를 사용할 수 있어야 합니다.
  • DCN 사이트: dcn0,dcn1 등과 같이 고유하고 고유한 heat 스택 이름을 지정할 수 있습니다. DHCP 릴레이를 사용하여 프로비저닝 네트워크를 원격 사이트로 확장합니다.
참고

각 스택에 대해 별도의 가용 영역(AZ)을 생성해야 합니다.

4.4. 별도의 heat 스택 관리

이 가이드의 절차에서는 세 개의 heat 스택( central,dcn0dcn 1)에 대해 환경 파일을 구성하는 방법을 보여줍니다. 각 heat 스택의 템플릿을 별도의 디렉터리에 저장하여 각 배포에 대한 정보를 격리된 상태로 유지하는 것이 좋습니다.

절차

  1. 중앙 heat 스택을 정의합니다.

    $ mkdir central
    $ touch central/overrides.yaml
  2. 중앙 heat 스택에서 모든 DCN 사이트의 공통 디렉터리로 데이터를 추출합니다.

    $ mkdir dcn-common
    $ touch dcn-common/overrides.yaml
    $ touch overcloud-deploy/central/central-export.yaml

    central-export.yaml 파일은 나중에 openstack overcloud export 명령으로 생성됩니다.

  3. dcn0 사이트를 정의합니다.

    $ mkdir dcn0
    $ touch dcn0/overrides.yaml

더 많은 DCN 사이트를 배포하려면 번호별로 추가 dcn 디렉토리를 만듭니다.

참고

touch는 파일 조직의 예를 제공하는 데 사용됩니다. 각 파일에는 성공적인 배포에 적절한 콘텐츠가 포함되어야 합니다.

4.5. 컨테이너 이미지 검색

다음 절차와 예제 파일 콘텐츠를 사용하여 별도의 heat 스택을 사용하여 배포에 필요한 컨테이너 이미지를 검색합니다. 에지 사이트의 환경 파일과 함께 openstack 컨테이너 image prepare 명령을 실행하여 선택적 또는 에지별 서비스의 컨테이너 이미지가 포함되어 있는지 확인해야 합니다.

자세한 내용은 컨테이너 이미지 준비 를 참조하십시오.

절차

  1. containers.yaml 에 레지스트리 서비스 계정 인증 정보를 추가합니다.

    parameter_defaults:
      ContainerImagePrepare:
      - push_destination: true
        set:
          ceph_namespace: registry.redhat.io/rhceph
          ceph_image: rhceph-5-rhel9
          ceph_tag: latest
          name_prefix: openstack-
          namespace: registry.redhat.io/rhosp17-rhel9
          tag: latest
      ContainerImageRegistryCredentials:
        # https://access.redhat.com/RegistryAuthentication
        registry.redhat.io:
          registry-service-account-username: registry-service-account-password
  2. images-env.yaml 로 환경 파일을 생성합니다.

    sudo openstack tripleo container image prepare \
    -e containers.yaml \
    --output-env-file images-env.yaml

    결과 images-env.yaml 파일은 생성된 스택의 오버클라우드 배포 절차의 일부로 포함됩니다.

4.6. 엣지에 대한 빠른 데이터 경로 역할 생성

에지에서 빠른 datapath 서비스를 사용하려면 빠른 datapath 및 edge 서비스 둘 다 정의하는 사용자 지정 역할을 생성해야 합니다. 배포에 대한 역할 파일을 생성할 때 분산 컴퓨팅 노드 아키텍처와 DPDK 또는 SR-IOV와 같은 빠른 데이터 경로 서비스 모두에 필요한 서비스를 정의하는 새로 생성된 역할을 포함할 수 있습니다.

예를 들어 DPDK를 사용하여 distributedCompute에 대한 사용자 정의 역할을 생성합니다.

사전 요구 사항

성공적인 언더클라우드 설치 자세한 내용은 언더클라우드 설치를 참조하십시오.

절차

  1. 언더클라우드 호스트에 stack 사용자로 로그인합니다.
  2. 기본 역할 디렉터리를 복사합니다.

    cp -r /usr/share/openstack-tripleo-heat-templates/roles ~/.
  3. DistributedCompute.yaml 파일에서 DistributedComputeDpdk.yaml 이라는 새 파일을 생성합니다.

    cp roles/DistributedCompute.yaml roles/DistributedComputeDpdk.yaml
  4. 새로운 DistributedComputeDpdk.yaml 파일에 DPDK 서비스를 추가합니다. DistributedComputeDpdk.yaml 파일에 없는 ComputeOvsDpdk.yaml 파일의 매개변수를 식별하여 추가해야 하는 매개변수를 확인할 수 있습니다.

    diff -u roles/DistributedComputeDpdk.yaml roles/ComputeOvsDpdk.yaml

    출력에서 + 가 앞에 있는 매개변수는 ComputeOvsDpdk.yaml 파일에 있지만 DistributedComputeDpdk.yaml 파일에 존재하지 않습니다. 새 DistributedComputeDpdk.yaml 파일에 이러한 매개변수를 포함합니다.

  5. DistributedComputeDpdk.yaml 을 사용하여 DistributedComputeDpdk 역할 파일을 만듭니다.

    openstack overcloud roles generate --roles-path ~/roles/ -o ~/roles/roles-custom.yaml DistributedComputeDpdk

이 동일한 방법을 사용하여 SR-IOV에 대한 fast datapath 역할을 생성하거나 Edge에 대한 SR-IOV 및 DPDK 조합을 생성하여 요구사항을 충족할 수 있습니다.

블록 스토리지 없이 에지 사이트를 배포하려는 경우 다음을 참조하십시오.

Red Hat Ceph Storage를 사용하여 에지 사이트를 배포하려는 경우 다음을 참조하십시오.

5장. 중앙 위치 설치

DCN(Distributed Compute Node) 아키텍처를 사용하여 Red Hat OpenStack 플랫폼을 배포할 때 스토리지 전략을 미리 결정해야 합니다. Red Hat Ceph Storage 없이 Red Hat OpenStack Platform을 중앙 위치에 배포하는 경우 Red Hat Ceph 스토리지로 에지 사이트를 배포할 수 없습니다. 또한 나중에 재배포를 통해 Red Hat Ceph Storage를 중앙 위치에 추가하는 옵션이 없습니다.

DCN(분산 컴퓨팅 노드) 아키텍처의 중앙 위치를 배포할 때 클러스터를 배포할 수 있습니다.

  • 컴퓨팅 노드 중 하나 이상
  • Red Hat Ceph Storage 사용 여부

5.1. 엣지 스토리지 없이 중앙 컨트롤러 배포

중앙 위치에서 Object Storage 서비스(swift)를 백엔드로 사용하는 경우 에지 사이트에 블록 스토리지 없이 분산 계산 노드 클러스터를 배포할 수 있습니다. 블록 스토리지 없이 배포된 사이트는 각 아키텍처에 대해 다른 역할 및 네트워킹 프로필로 인해 나중에 블록 스토리지를 보유하도록 업데이트할 수 없습니다.

중요: 다음 절차에서는 production에 지원되지 않는 Cinder의 백엔드로 lvm을 사용합니다. 인증된 블록 스토리지 솔루션을 Cinder의 백엔드로 배포해야 합니다.

일반적인 오버클라우드 배포와 유사한 방식으로 중앙 컨트롤러 클러스터를 배포합니다. 이 클러스터에는 컴퓨팅 노드가 필요하지 않으므로 Compute 수를 0 으로 설정하여 기본값 1 을 덮어쓸 수 있습니다. 중앙 컨트롤러에는 특정 스토리지 및 Oslo 구성 요구 사항이 있습니다. 이러한 요구 사항을 해결하려면 다음 절차를 사용하십시오.

사전 요구 사항

절차

다음 절차에서는 중앙 위치의 초기 배포 단계를 간략하게 설명합니다.

참고

다음 단계에서는 glance 다중 저장소 예제 DCN 배포와 관련된 배포 명령 및 환경 파일을 자세히 설명합니다. 이러한 단계는 관련이 없지만 필요한 구성 요소(예: 네트워킹)를 포함합니다.

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

    [stack@director ~]$ source /home/stack/stackrc
  3. 환경 파일을 생성합니다.

    sudo openstack tripleo container image prepare \
    -e containers.yaml \
    --output-env-file /home/stack/central/central-images-env.yaml
  4. 홈 디렉터리에서 배포하려는 각 스택의 디렉터리를 생성합니다. 중앙 위치의 network_data.yaml,vip_data.yamlovercloud-baremetal-deploy.yaml 템플릿을 /home/stack/central/ 로 이동합니다.

    mkdir /home/stack/central
    mkdir /home/stack/dcn0
    mkdir /home/stack/dcn1
    
    mv network_data.yaml /home/stack/central
    mv vip_data.yaml /home/stack/central
    mv overcloud-baremetal-deploy.yaml /home/stack/central
  5. 오버클라우드의 네트워크를 프로비저닝합니다. 이 명령은 오버클라우드 네트워크의 정의 파일을 입력으로 사용합니다. 오버클라우드를 배포하려면 명령에서 출력 파일을 사용해야 합니다.

    (undercloud)$ openstack overcloud network provision \
    --output /home/stack/central/overcloud-networks-deployed.yaml \
    /home/stack/central/network_data.yaml
  6. 오버클라우드의 가상 IP를 프로비저닝합니다. 이 명령은 가상 IP의 정의 파일을 입력으로 사용합니다. 오버클라우드를 배포하려면 명령에서 출력 파일을 사용해야 합니다.

    (undercloud)$ openstack overcloud network vip provision \
    --stack central \
    --output /home/stack/central/overcloud-vip-deployed.yaml \
    /home/stack/central/vip_data.yaml
  7. 베어 메탈 인스턴스를 프로비저닝합니다. 이 명령은 베어 메탈 노드의 정의 파일을 입력으로 사용합니다. 오버클라우드를 배포하려면 명령에서 출력 파일을 사용해야 합니다.

    (undercloud)$ openstack overcloud node provision \
    --stack central \
    --network-config \
    -o /home/stack/central/deployed_metal.yaml \
    /home/stack/central/overcloud-baremetal-deploy.yaml
  8. 다음과 유사한 설정을 사용하여 central/overrides.yaml 이라는 파일을 생성합니다.

    parameter_defaults:
      NtpServer:
        - 0.pool.ntp.org
        - 1.pool.ntp.org
      GlanceBackend: swift
    • ControllerCount: 3 은 3개의 노드가 배포되도록 지정합니다. 그러면 Glance에 swift를 사용하고 cinder에 lvm을 사용하고 에지 컴퓨팅 노드에 대한 컨트롤 플레인 서비스를 호스팅합니다.
    • ComputeCount: 0 는 Compute 노드가 중앙 컨트롤러 노드와 함께 배포되지 않도록 하는 선택적 매개 변수입니다.
    • GlanceBackend: swift 는 Object Storage(swift)를 Image 서비스(glance) 백엔드로 사용합니다.

      결과 구성은 다음과 같은 방식으로 DCN(Distributed Compute nodes)과 상호 작용합니다.

    • DCN의 이미지 서비스는 중앙 오브젝트 스토리지 백엔드에서 수신하는 이미지의 캐시된 복사본을 생성합니다. 이미지 서비스는 HTTP를 사용하여 오브젝트 스토리지의 이미지를 로컬 디스크 캐시로 복사합니다.

      참고

      중앙 컨트롤러 노드는 DCN(Distributed Compute node) 사이트에 연결할 수 있어야 합니다. 중앙 컨트롤러 노드는 라우팅된 계층 3 연결을 사용할 수 있습니다.

  9. site-name.yaml 환경 파일에서 사이트의 이름 지정 규칙을 구성합니다. Nova 가용성 영역인 Cinder 스토리지 가용성 영역이 일치해야 합니다.

    cat > /home/stack/central/site-name.yaml << EOF
    parameter_defaults:
        NovaComputeAvailabilityZone: central
        ControllerExtraConfig:
            nova::availability_zone::default_schedule_zone: central
        NovaCrossAZAttach: false
    EOF
  10. 중앙 컨트롤러 노드를 배포합니다. 예를 들어 다음 내용과 함께 deploy.sh 파일을 사용할 수 있습니다.

    openstack overcloud deploy \
    --deployed-server \
    --stack central \
    --templates /usr/share/openstack-tripleo-heat-templates/ \
    -n /home/stack/central/network_data.yaml \
    -e /usr/share/openstack-tripleo-heat-templates/environments/network-environment.yaml \
    -e /usr/share/openstack-tripleo-heat-templates/environments/podman.yaml \
    -e /usr/share/openstack-tripleo-heat-templates/environments/nova-az-config.yaml \
    -e /home/stack/central/overcloud-networks-deployed.yaml \
    -e /home/stack/central/overcloud-vip-deployed.yaml \
    -e /home/stack/central/deployed_metal.yaml
참고

openstack overcloud deploy 명령에 네트워킹 설정을 위한 heat 템플릿을 포함해야 합니다. 엣지 아키텍처를 설계하려면 스파인 및 리프 네트워킹이 필요합니다. 자세한 내용은 Spine Leaf Networking 에서 참조하십시오.

5.2. 스토리지를 사용하여 중앙 사이트 배포

여러 저장소 및 Ceph Storage가 있는 이미지 서비스를 백엔드로 배포하려면 다음 단계를 완료합니다.

사전 요구 사항

  • 환경과 관련된 network_data.yamlvip_data.yaml 파일을 생성해야 합니다. /usr/share/openstack-tripleo-heat-templates/network-data-samples 에서 샘플 파일을 찾을 수 있습니다.
  • 환경과 관련된 overcloud-baremetal-deploy.yaml 파일을 생성해야 합니다. 자세한 내용은 오버클라우드의 베어 메탈 노드 프로비저닝을 참조하십시오.
  • 중앙 위치와 각 가용성 영역 또는 스토리지 서비스가 필요한 각 지리적 위치에 있는 Ceph 클러스터 하드웨어가 있습니다.
  • 중앙 위치 및 각 가용성 영역에 있는 3개의 Image 서비스(glance) 서버 또는 스토리지 서비스가 필요한 각 지리적 위치에 대한 하드웨어가 있습니다. 엣지 위치에서 이미지 서비스는 DistributedComputeHCI 노드에 배포됩니다.

절차

Red Hat OpenStack Platform 중앙 위치를 배포하여 Image 서비스(glance)를 여러 저장소와 함께 사용할 수 있습니다.

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

    [stack@director ~]$ source /home/stack/stackrc
  3. 환경 파일 /home/stack/central/central-images-env.yaml을 생성합니다.

    sudo openstack tripleo container image prepare \
    -e containers.yaml \
    --output-env-file /home/stack/central/central-images-env.yaml
  4. 환경에 적합한 역할을 사용하여 중앙 위치에 대한 역할을 생성합니다.

    openstack overcloud roles generate Compute Controller CephStorage \
    -o /home/stack/central/central_roles.yaml
  5. 홈 디렉터리에서 배포하려는 각 스택의 디렉터리를 생성합니다. 중앙 위치의 network_data.yaml,vip_data.yamlovercloud-baremetal-deploy.yaml 템플릿을 /home/stack/central/ 로 이동합니다.

    mkdir /home/stack/central
    mkdir /home/stack/dcn0
    mkdir /home/stack/dcn1
    
    mv network_data.yaml /home/stack/central
    mv vip_data.yaml /home/stack/central
    mv overcloud-baremetal-deploy.yaml /home/stack/central
  6. 오버클라우드의 네트워크를 프로비저닝합니다. 이 명령은 오버클라우드 네트워크의 정의 파일을 입력으로 사용합니다. 오버클라우드를 배포하려면 명령에서 출력 파일을 사용해야 합니다.

    openstack overcloud network provision \
    --output /home/stack/central/overcloud-networks-deployed.yaml \
    /home/stack/central/network_data.yaml
  7. 오버클라우드의 가상 IP를 프로비저닝합니다. 이 명령은 가상 IP의 정의 파일을 입력으로 사용합니다. 오버클라우드를 배포하려면 명령에서 출력 파일을 사용해야 합니다.

    openstack overcloud network vip provision \
    --stack central \
    --output /home/stack/central/overcloud-vip-deployed.yaml \
    /home/stack/central/vip_data.yaml
  8. 베어 메탈 인스턴스를 프로비저닝합니다. 이 명령은 베어 메탈 노드의 정의 파일을 입력으로 사용합니다. 오버클라우드를 배포하려면 명령에서 출력 파일을 사용해야 합니다.

    openstack overcloud node provision \
    --stack central \
    --network-config \
    -o /home/stack/central/deployed_metal.yaml \
    /home/stack/central/overcloud-baremetal-deploy.yaml
  9. 하이퍼컨버지드 스토리지를 사용하여 중앙 위치를 배포하는 경우 다음 매개변수를 사용하여 initial-ceph.conf 구성 파일을 생성해야 합니다. 자세한 내용은 Configuring the Red Hat Ceph Storage cluster for HCI 를 참조하십시오.

    [osd]
    osd_memory_target_autotune = true
    osd_numa_auto_affinity = true
    [mgr]
    mgr/cephadm/autotune_memory_target_ratio = 0.2
  10. deployed_metal.yaml 파일을 openstack overcloud ceph deploy 명령에 대한 입력으로 사용합니다. openstack overcloud ceph deploy 명령은 배포된 Ceph 클러스터를 설명하는 yaml 파일을 출력합니다.

    openstack overcloud ceph deploy \
    --stack central \
    /home/stack/central/deployed_metal.yaml \
    --config /home/stack/central/initial-ceph.conf \ 1
    --output /home/stack/central/deployed_ceph.yaml \
    --container-image-prepare /home/stack/containers.yaml \
    --network-data /home/stack/network-data.yaml \
    --cluster central \
    --roles-data /home/stack/central/central_roles.yaml
    1
    initial-ceph.com을 하이퍼컨버지드 인프라를 배포할 때만 포함합니다.
  11. 계속하기 전에 작동하는 Ceph 배포를 확인합니다. ssh 를 사용하여 ceph-mon 서비스를 실행하는 서버에 연결합니다. HCI 배포에서 이는 컨트롤러 노드입니다. 다음 명령을 실행합니다.

    cephadm shell --config /etc/ceph/central.conf \
    --keyring /etc/ceph/central.client.admin.keyring
    참고

    --config--keyring 매개변수를 사용해야 합니다.

  12. site-name.yaml 환경 파일에서 사이트의 이름 지정 규칙을 구성합니다. Nova 가용성 영역과 Cinder 스토리지 가용성 영역이 일치해야 합니다.

    parameter_defaults:
        NovaComputeAvailabilityZone: central
        ControllerExtraConfig:
            nova::availability_zone::default_schedule_zone: central
        NovaCrossAZAttach: false
        CinderStorageAvailabilityZone: central
        GlanceBackendID: central
  13. 다음과 유사한 콘텐츠로 glance.yaml 템플릿을 구성합니다.

    parameter_defaults:
        GlanceEnabledImportMethods: web-download,copy-image
        GlanceBackend: rbd
        GlanceStoreDescription: 'central rbd glance store'
        GlanceBackendID: central
        CephClusterName: central
  14. 중앙 위치에 스택을 배포합니다.

    openstack overcloud deploy \
    --deployed-server \
    --stack central \
    --templates /usr/share/openstack-tripleo-heat-templates/ \
    -r /home/stack/central/central_roles.yaml \
    -n ~/network-data.yaml \
    -e /usr/share/openstack-tripleo-heat-templates/environments/network-environment.yaml \
    -e /usr/share/openstack-tripleo-heat-templates/environments/podman.yaml \
    -e /usr/share/openstack-tripleo-heat-templates/environments/cephadm/cephadm.yaml \
    -e /usr/share/openstack-tripleo-heat-templates/environments/nova-az-config.yaml \
    -e /home/stack/central/overcloud-networks-deployed.yaml \
    -e /home/stack/central/overcloud-vip-deployed.yaml \
    -e /home/stack/central/deployed_metal.yaml \
    -e /home/stack/central/deployed_ceph.yaml \
    -e ~/central/glance.yaml
  15. 중앙 위치에 오버클라우드를 배포한 후 에지 사이트의 추가 스택 배포 입력에 필요한 데이터가 내보내서 /home/stack/overcloud-deploy 디렉터리에 배치됩니다. central-export.yaml 파일이 있는지 확인합니다.

    stat /home/stack/overcloud-deploy/central/central-export.yaml
  16. Ceph 특정 데이터를 내보냅니다.

    openstack overcloud export ceph \
    --stack central \
    --output-file /home/stack/dcn-common/central_ceph_external.yaml

5.3. 외부 Ceph 통합

DCN(분산 계산 노드) 아키텍처의 중앙 위치를 배포하고 사전 배포된 Red Hat Ceph Storage 솔루션을 통합할 수 있습니다. director 없이 Red Hat Ceph Storage를 배포할 때 director는 사용자 환경의 Red Hat Ceph 스토리지에 대한 정보가 없습니다. openstack overcloud export ceph 명령 을 실행할 수 없으며 central_ceph_external.yaml 을 수동으로 생성해야 합니다.

사전 요구 사항

  • 환경과 관련된 network_data.yamlvip_data.yaml 파일을 생성해야 합니다. /usr/share/openstack-tripleo-heat-templates/network-data-samples 에서 샘플 파일을 찾을 수 있습니다.
  • 환경과 관련된 overcloud-baremetal-deploy.yaml 파일을 생성해야 합니다. 자세한 내용은 오버클라우드의 베어 메탈 노드 프로비저닝을 참조하십시오.
  • 중앙 위치 및 각 가용성 영역의 Ceph 클러스터 또는 스토리지 서비스가 필요한 각 지리적 위치의 하드웨어입니다.

다음은 두 개 이상의 스택을 배포하는 예입니다.

  • central 라는 중앙 위치에 있는 하나의 스택.
  • dcn0 이라는 에지 사이트에 있는 스택 1개.
  • dcn0 과 유사하게 배포된 추가 스택(예: dcn1,dcn2 등)

dcn external ceph at central

절차

기존 Red Hat Ceph Storage 클러스터 통합에 설명된 프로세스에 따라 기존 Red Hat Ceph Storage 솔루션과 통합 되도록 중앙 위치를 설치할 수 있습니다. DCN 배포의 중앙 사이트와 Red Hat Ceph Storage를 통합하는 특별한 요구 사항은 없지만 오버클라우드를 배포하기 전에 DCN 특정 단계를 완료해야 합니다.

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

    [stack@director ~]$ source ~/stackrc
  3. 환경 파일 ~/central/central-images-env.yaml을 생성합니다.

    sudo openstack tripleo container image prepare \
    -e containers.yaml \
    --output-env-file ~/central/central-images-env.yaml
  4. 홈 디렉터리에서 배포하려는 각 스택의 디렉터리를 생성합니다. 이를 사용하여 각 사이트에 맞게 설계된 템플릿을 분리합니다. 중앙 위치의 network_data.yaml,vip_data.yamlovercloud-baremetal-deploy.yaml 템플릿을 /home/stack/central/ 로 이동합니다.

    mkdir /home/stack/central
    mkdir /home/stack/dcn0
    mkdir /home/stack/dcn1
    
    mv network_data.yaml /home/stack/central
    mv vip_data.yaml /home/stack/central
    mv overcloud-baremetal-deploy.yaml /home/stack/central
  5. 오버클라우드의 네트워크를 프로비저닝합니다. 이 명령은 오버클라우드 네트워크의 정의 파일을 입력으로 사용합니다. 오버클라우드를 배포하려면 명령에서 출력 파일을 사용해야 합니다.

    openstack overcloud network provision \
    --output /home/stack/central/overcloud-networks-deployed.yaml \
    /home/stack/central/network_data.yaml
  6. 오버클라우드의 가상 IP를 프로비저닝합니다. 이 명령은 가상 IP의 정의 파일을 입력으로 사용합니다. 오버클라우드를 배포하려면 명령에서 출력 파일을 사용해야 합니다.

    openstack overcloud network vip provision \
    --stack central \
    --output /home/stack/central/overcloud-vip-deployed.yaml \
    /home/stack/central/vip_data.yaml
  7. 베어 메탈 인스턴스를 프로비저닝합니다. 이 명령은 베어 메탈 노드의 정의 파일을 입력으로 사용합니다. 오버클라우드를 배포하려면 명령에서 출력 파일을 사용해야 합니다.

    openstack overcloud node provision \
    --stack central \
    --network-config \
    -o /home/stack/central/deployed_metal.yaml \
    /home/stack/central/overcloud-baremetal-deploy.yaml
  8. site-name.yaml 환경 파일에서 사이트의 이름 지정 규칙을 구성합니다. Compute(nova) 가용성 영역 및 Block Storage(cinder) 가용성 영역이 일치해야 합니다.

    cat > /home/stack/central/site-name.yaml << EOF
    parameter_defaults:
        NovaComputeAvailabilityZone: central
        ControllerExtraConfig:
            nova::availability_zone::default_schedule_zone: central
        NovaCrossAZAttach: false
        CinderStorageAvailabilityZone: central
        GlanceBackendID: central
    EOF
  9. 다음과 유사한 콘텐츠로 external-ceph.yaml 템플릿을 구성합니다.

    parameter_defaults:
        CinderEnableIscsiBackend: false
        CinderEnableRbdBackend: true
        CinderEnableNfsBackend: false
        NovaEnableRbdBackend: true
        GlanceBackend: rbd
        GlanceBackendID: central
        GlanceEnabledImportMethods: web-download,copy-image
        GlanceStoreDescription: 'central rbd glance store'
        CinderRbdPoolName: "openstack-cinder"
        NovaRbdPoolName: "openstack-nova"
        GlanceRbdPoolName: "openstack-images"
        CinderBackupRbdPoolName: "automation-backups"
        GnocchiRbdPoolName: "automation-metrics"
        CephClusterFSID: 38dd387e-837a-437c-891c-7fc69e17a3c
        CephClusterName: central
        CephExternalMonHost: 10.9.0.1,10.9.0.2,10.9.0.3
        CephClientKey: "AQAKtECeLemfiBBdQp7cjNYQRGW9y8GnhhFZg=="
        CephClientUserName: "openstack
  10. 중앙 위치를 배포합니다.

    openstack overcloud deploy \
    --stack central \
    --templates /usr/share/openstack-tripleo-heat-templates/ \
    -n /home/stack/central/network-data.yaml \
    ...
    -e /usr/share/openstack-tripleo-heat-templates/environments/network-environment.yaml \
    -e /usr/share/openstack-tripleo-heat-templates/environments/podman.yaml \
    -e /usr/share/openstack-tripleo-heat-templates/environments/external-ceph.yaml \
    -e /usr/share/openstack-tripleo-heat-templates/environments/nova-az-config.yaml \
    -e /home/stack/central/overcloud-networks-deployed.yaml \
    -e /home/stack/central/overcloud-vip-deployed.yaml \
    -e /home/stack/central/deployed_metal.yaml \
    -e /home/stack/central/external-ceph.yaml \
    -e /home/stack/central/overcloud-networks-deployed.yaml \
    -e /home/stack/central/central_roles.yaml
  11. 중앙 위치에 오버클라우드를 배포한 후 에지 사이트의 추가 스택 배포 입력에 필요한 데이터가 내보내서 /home/stack/overcloud-deploy 디렉터리에 배치됩니다. 이 control-plane-export.yaml 파일이 있는지 확인합니다.

    stat ~/overcloud-deploy/control-plane/control-plane-export.yaml
  12. Red Hat Ceph Storage 배포에 대한 세부 정보를 사용하여 central_ceph_external.yaml 이라는 환경 파일을 생성합니다. 이 파일은 에지 사이트의 추가 스택 배포에 전달할 수 있습니다.

    parameter_defaults:
      CephExternalMultiConfig:
        - cluster: "central"
          fsid: "3161a3b4-e5ff-42a0-9f53-860403b29a33"
          external_cluster_mon_ips: "172.16.11.84, 172.16.11.87, 172.16.11.92"
          keys:
            - name: "client.openstack"
              caps:
                mgr: "allow *"
                mon: "profile rbd"
                osd: "profile rbd pool=vms, profile rbd pool=volumes, profile rbd pool=images"
              key: "AQD29WteAAAAABAAphgOjFD7nyjdYe8Lz0mQ5Q=="
              mode: "0600"
          dashboard_enabled: false
          ceph_conf_overrides:
            client:
              keyring: /etc/ceph/central.client.openstack.keyring
    • fsid 매개변수는 Ceph Storage 클러스터의 파일 시스템 ID입니다. 이 값은 [global] 섹션의 클러스터 구성 파일에 지정됩니다.

      [global]
      fsid = 4b5c8c0a-ff60-454b-a1b4-9747aa737d19
      ...
    • key 매개변수는 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"
      ...

      샘플 central_ceph_external.yaml 파일에 표시된 매개변수에 대한 자세한 내용은 사용자 지정 환경 파일 생성을 참조하십시오.

6장. 스토리지 없이 엣지 배포

중앙 위치에서 Image 서비스(glance)의 백엔드로 Object Storage 서비스(swift)를 사용하는 경우 에지 사이트에서 블록 스토리지 없이 DCN(Distributed Compute 노드) 클러스터를 배포할 수 있습니다. 블록 스토리지가 없는 사이트를 배포하는 경우 나중에 블록 스토리지를 갖도록 업데이트할 수 없습니다.

스토리지 없이 에지 사이트를 배포할 때 컴퓨팅 역할을 사용합니다.

중요

다음 절차에서는 프로덕션에서는 지원되지 않는 블록 스토리지 서비스(cinder)의 백엔드로 lvm을 사용합니다. 인증된 블록 스토리지 솔루션을 블록 스토리지 서비스의 백엔드로 배포해야 합니다.

6.1. 스토리지가 없는 DCN 에지 사이트의 아키텍처

이 아키텍처를 배포하려면 Compute(계산) 역할을 사용합니다.

dcn with compute only example

엣지에 블록 스토리지 없이
  • 컨트롤 플레인의 Object Storage(swift) 서비스는 Image(glance) 서비스 백엔드로 사용됩니다.
  • 다중 백엔드 이미지 서비스를 사용할 수 없습니다.

  • 인스턴스는 계산 노드에 로컬로 저장됩니다.
  • 블록 스토리지(cinder)와 같은 볼륨 서비스는 에지 사이트에서 사용할 수 없습니다.

    중요

    Red Hat Ceph 스토리지로 중앙 위치를 배포하지 않으면 나중에 스토리지로 에지 사이트를 배포하는 옵션이 없습니다.

    에지에서 블록 스토리지 없이 배포하는 방법에 대한 자세한 내용은 6.2절. “스토리지 없이 엣지 노드 배포” 을 참조하십시오.

6.2. 스토리지 없이 엣지 노드 배포

엣지 사이트에 컴퓨팅 노드를 배포할 때 중앙 위치를 컨트롤 플레인으로 사용합니다. 배포에 새 DCN 스택을 추가하고 중앙 위치의 구성 파일을 재사용하여 새 환경 파일을 생성할 수 있습니다.

사전 요구 사항

절차

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

    [stack@director ~]$ source ~/stackrc
  3. 환경 파일 ~/dcn0/dcn0-images-env.yaml[d]을 생성합니다.

    sudo[e] openstack tripleo container image prepare \
    -e containers.yaml \
    --output-env-file ~/dcn0/dcn0-images-env.yaml
  4. 엣지 위치에 대한 역할 파일을 생성합니다. 환경에 적합한 역할을 사용하여 에지 위치에 대한 역할을 생성합니다.

    (undercloud)$ openstack overcloud roles \
     generate Compute \
     -o /home/stack/dcn0/dcn0_roles.yaml
  5. 네트워킹 오버레이에 ML2/OVS를 사용하는 경우 Compute 역할에 NeutronDhcpAgentNeutronMetadataAgent 서비스가 포함됩니다.

    1. 컴퓨팅 역할에 대한 역할 파일을 생성합니다.

      openstack overcloud roles \
      generate Compute \
      -o /home/stack/dcn0/dcn0_roles.yaml
    2. NeutronDhcpAgentNeutronMetadataAgent 서비스를 포함하도록 /home/stack/dcn0/dcn0_roles.yaml 파일을 편집합니다.

      ...
          - OS::TripleO::Services::MySQLClient
          - OS::TripleO::Services::NeutronBgpVpnBagpipe
      +   - OS::TripleO::Services::NeutronDhcpAgent
      +   - OS::TripleO::Services::NeutronMetadataAgent
          - OS::TripleO::Services::NeutronLinuxbridgeAgent
          - OS::TripleO::Services::NeutronVppAgent
          - OS::TripleO::Services::NovaAZConfig
          - OS::TripleO::Services::NovaCompute
      ...

      자세한 내용은 라우팅된 공급자 네트워크 준비를 참조하십시오.

  6. 오버클라우드의 네트워크를 프로비저닝합니다. 이 명령은 오버클라우드 네트워크의 정의 파일을 입력으로 사용합니다. 오버클라우드를 배포하려면 명령에서 출력 파일을 사용해야 합니다.

    (undercloud)$ openstack overcloud network provision \
    --output /home/stack/dcn0/overcloud-networks-deployed.yaml \
    /home/stack/dcn0/network_data.yaml
  7. 베어 메탈 인스턴스를 프로비저닝합니다. 이 명령은 베어 메탈 노드의 정의 파일을 입력으로 사용합니다. 오버클라우드를 배포하려면 명령에서 출력 파일을 사용해야 합니다.

    (undercloud)$ openstack overcloud node provision \
    --stack dcn0 \
    --network-config \
    -o /home/stack/dcn0/deployed_metal.yaml \
    ~/overcloud-baremetal-deploy.yaml
  8. site-name.yaml 환경 파일에서 사이트의 이름 지정 규칙을 구성합니다.

    parameter_defaults:
        NovaComputeAvailabilityZone: dcn0
        ControllerExtraConfig:
            nova::availability_zone::default_schedule_zone: dcn0
        NovaCrossAZAttach: false
  9. dcn0 에지 사이트의 스택을 배포합니다.

    openstack overcloud deploy \
    --deployed-server \
    --stack dcn0 \
    --templates /usr/share/openstack-tripleo-heat-templates/ \
    -r /home/stack/dcn0/dcn0_roles.yaml \
    -n /home/stack/network_data.yaml \
    -e /usr/share/openstack-tripleo-heat-templates/environments/network-environment.yaml \
    -e /usr/share/openstack-tripleo-heat-templates/environments/podman.yaml \
    -e /usr/share/openstack-tripleo-heat-templates/environments/nova-az-config.yaml \
    -e /home/stack/overcloud-deploy/central/central-export.yaml \
    -e /home/stack/dcn0/overcloud-networks-deployed.yaml \
    -e /home/stack/dcn0/overcloud-vip-deployed.yaml \
    -e /home/stack/dcn0/deployed_metal.yaml

6.3. 에지에서 특정 이미지 유형 제외

기본적으로 Compute 노드는 지원하는 모든 이미지 형식을 알립니다. 컴퓨팅 노드에서 Ceph 스토리지를 사용하지 않는 경우 이미지 형식 광고에서 RAW 이미지를 제외할 수 있습니다. RAW 이미지 형식은 QCOW2 이미지보다 네트워크 대역폭과 로컬 스토리지를 더 많이 사용하며 Ceph 스토리지가 없는 에지 사이트에서는 비효율적입니다. NovaImageTypeExcludeList 매개변수를 사용하여 특정 이미지 형식을 제외합니다.

중요

Ceph에는 RAW 이미지가 필요하므로 이 매개변수를 Ceph와 함께 사용하지 마십시오.

참고

RAW 이미지를 사용하지 않는 컴퓨팅 노드는 RAW 이미지에서 생성된 인스턴스를 호스트할 수 없습니다. 이는 snapshot-redeploy 및 보류에 영향을 미칠 수 있습니다.

사전 요구 사항

  • Red Hat OpenStack Platform director 설치
  • 중앙 위치가 설치됨
  • DCN 배포에 컴퓨팅 노드를 사용할 수 있습니다.

절차

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

    $ source ~/stackrc
  3. 사용자 지정 환경 파일 중 하나에 NovaImageTypeExcludeList 매개변수를 포함합니다.

    parameter_defaults:
      NovaImageTypeExcludeList:
            - raw
  4. 배포와 관련된 기타 환경 파일과 함께 오버클라우드 배포 명령에 NovaImageTypeExcludeList 매개 변수가 포함된 환경 파일을 포함합니다.

    openstack overcloud deploy --templates \
    -n network_data.yaml \
    -r roles_data.yaml \
    -e <environment_files> \
    -e <new_environment_file>

7장. 엣지에 스토리지 배포

Red Hat OpenStack Platform director를 활용하여 Red Hat OpenStack Platform 및 Ceph Storage 사용의 이점과 함께 에지에 분산 이미지 관리 및 영구 스토리지를 포함하도록 분산 컴퓨팅 노드 배포를 확장할 수 있습니다.

DCN 아키텍처

7.1. 스토리지를 사용한 엣지 배포의 역할

스토리지를 사용한 에지 배포에 다음 역할을 사용할 수 있습니다. 선택한 구성에 따라 환경에 적절한 역할을 선택합니다.

7.1.1. 하이퍼컨버지드 노드가 없는 스토리지

스토리지를 사용하여 에지를 배포하고 하이퍼컨버지드 노드를 배포하지 않는 경우 다음 네 가지 역할 중 하나를 사용합니다.

DistributedCompute
DistributedCompute 역할은 스토리지 배포에서 처음 세 개의 컴퓨팅 노드에 사용됩니다. DistributedCompute 역할에는 GlanceApiEdge 서비스가 포함되어 있으므로 중앙 허브 위치 대신 로컬 에지 사이트에서 이미지 서비스를 사용할 수 있습니다. 추가 노드의 경우 DistributedComputeScaleOut 역할을 사용합니다.
DistributedComputeScaleOut
DistributedComputeScaleOut 역할에는 HAproxyEdge 서비스가 포함되어 있습니다. 그러면 DistributedComputeScaleOut 역할에 생성된 인스턴스를 에지 사이트에서 해당 서비스를 제공하는 노드에 대한 이미지 서비스에 대한 요청을 프록시할 수 있습니다. DistributedCompute 역할을 사용하여 3개의 노드를 배포한 후 DistributedCompute ScaleOut 역할을 사용하여 컴퓨팅 리소스를 확장할 수 있습니다. DistrubutedComputeScaleOut 역할로 배포하는 데 필요한 최소 호스트 수는 없습니다.
CephAll
CephAll 역할에는 Ceph OSD, Ceph mon, Ceph Mgr 서비스가 포함됩니다. CephAll 역할을 사용하여 최대 3개의 노드를 배포할 수 있습니다. 추가 스토리지 용량의 경우 CephStorage 역할을 사용합니다.
CephStorage
CephStorage 역할에는 Ceph OSD 서비스가 포함됩니다. 세 개의 CephAll 노드에서 충분한 스토리지 용량을 제공하지 않으면 필요한 만큼 CephStorage 노드를 추가합니다.

7.1.2. 하이퍼컨버지드 노드가 있는 스토리지

스토리지를 사용하여 에지를 배포하고 컴퓨팅과 스토리지를 결합하는 하이퍼컨버지드 노드를 사용하려는 경우 다음 두 가지 역할 중 하나를 사용합니다.

DistributedComputeHCI
DistributedComputeHCI 역할을 사용하면 Ceph 관리 및 OSD 서비스를 포함하여 에지에서 하이퍼컨버지드 배포를 활성화합니다. DistributedComputeHCI 역할을 사용하는 경우 정확히 세 개의 노드를 사용해야 합니다.
DistributedComputeHCIScaleOut
DistributedComputeHCIScaleOut 역할에는 Ceph OSD 서비스가 포함되어 있으므로, 에지에 더 많은 노드를 추가할 때 컴퓨팅을 사용하여 스토리지 용량을 확장할 수 있습니다. 이 역할에는 이미지 다운로드 요청을 에지 사이트의 GlanceAPI Edge 노드로 리디렉션하는 HAproxy Edge 서비스도 포함되어 있습니다. 이 역할은 에지에서 하이퍼컨버지드 배포를 활성화합니다. DistributedComputeHCI 역할을 사용하는 경우 정확히 세 개의 노드를 사용해야 합니다.

7.2. 스토리지를 사용하는 DCN 에지 사이트의 아키텍처

스토리지로 DCN을 배포하려면 중앙 위치에 Red Hat Ceph Storage도 배포해야 합니다. dcn-storage.yamlcephadm.yaml 환경 파일을 사용해야 합니다. 비하이퍼컨버지드 Red Hat Ceph Storage 노드를 포함하는 에지 사이트의 경우 DistributedCompute,DistributedComputeScaleOut,CephAllCephStorage 역할을 사용합니다.

dcn with nonhci at edge example

엣지에 블록 스토리지 사용
  • Red Hat Ceph Block Devices(RBD)는 Image(glance) 서비스 백엔드로 사용됩니다.
  • 중앙 및 DCN 사이트 간에 이미지를 복사할 수 있도록 다중 백엔드 이미지 서비스(glance)를 사용할 수 있습니다.
  • Block Storage(cinder) 서비스는 모든 사이트에서 사용할 수 있으며 Red Hat Ceph Block Devices(RBD) 드라이버를 사용하여 액세스할 수 있습니다.
  • Block Storage(cinder) 서비스는 계산 노드에서 실행되며, Red Hat Ceph Storage는 전용 스토리지 노드에서 별도로 실행됩니다.
  • Nova 임시 스토리지는 Ceph(RBD)에서 지원합니다.

    자세한 내용은 5.2절. “스토리지를 사용하여 중앙 사이트 배포”의 내용을 참조하십시오.

7.3. 하이퍼컨버지드 스토리지를 사용하는 DCN 에지 사이트의 아키텍처

이 구성을 배포하려면 중앙 위치에 Red Hat Ceph Storage도 배포해야 합니다. dcn-storage.yamlcephadm.yaml 환경 파일을 구성해야 합니다. DistributedComputeHCIDistributedComputeHCIScaleOut 역할을 사용합니다. DistributedComputeScaleOut 역할을 사용하여 Red Hat Ceph Storage 서비스 제공에 참여하지 않는 컴퓨팅 노드를 추가할 수도 있습니다.

dcn with hci at edge example

엣지에 하이퍼컨버지드 스토리지 사용
  • Red Hat Ceph Block Devices(RBD)는 Image(glance) 서비스 백엔드로 사용됩니다.
  • 중앙 및 DCN 사이트 간에 이미지를 복사할 수 있도록 다중 백엔드 이미지 서비스(glance)를 사용할 수 있습니다.
  • Block Storage(cinder) 서비스는 모든 사이트에서 사용할 수 있으며 Red Hat Ceph Block Devices(RBD) 드라이버를 사용하여 액세스할 수 있습니다.
  • 블록 스토리지 서비스와 Red Hat Ceph Storage는 모두 Compute 노드에서 실행됩니다.

    자세한 내용은 7.4절. “하이퍼컨버지드 스토리지를 사용하여 에지 사이트 배포”에서 참조하십시오.

분산 컴퓨팅 아키텍처에 Red Hat OpenStack Platform을 배포할 때 각 사이트에서 고유한 구성과 함께 여러 스토리지 토폴로지를 배포할 수 있습니다. Red Hat Ceph 스토리지로 중앙 위치를 배포하여 스토리지로 모든 에지 사이트를 배포해야 합니다.

dcn with storage mixed example

7.4. 하이퍼컨버지드 스토리지를 사용하여 에지 사이트 배포

중앙 사이트를 배포한 후 에지 사이트를 구축하고 각 에지 위치가 주로 자체 스토리지 백엔드와 중앙 위치의 스토리지 백엔드에 연결되도록 합니다. 스파인 및 리프 네트워킹 구성은 이 구성에 포함되어야 하며, ceph에 필요한 스토리지 및 storage_databind 네트워크가 추가됩니다. 자세한 내용은 Spine Leaf Networking을 참조하십시오. 사이트 간에 이미지 서비스(glance) 이미지를 이동할 수 있도록 중앙 위치 및 스토리지 네트워크의 스토리지 네트워크가 연결되어 있어야 합니다.

중앙 위치에서 각 에지 사이트에서 mons 및 OSD와 통신할 수 있는지 확인합니다. 그러나 스토리지 관리 네트워크가 OSD 재조정에 사용되므로 사이트 위치 경계에서 스토리지 관리 네트워크를 종료해야 합니다.

사전 요구 사항

  • 환경과 관련된 network_data.yaml 파일을 생성해야 합니다. /usr/share/openstack-tripleo-heat-templates/network-data-samples 에서 샘플 파일을 찾을 수 있습니다.
  • 환경과 관련된 overcloud-baremetal-deploy.yaml 파일을 생성해야 합니다. 자세한 내용은 오버클라우드의 베어 메탈 노드 프로비저닝을 참조하십시오.
  • 중앙 위치 및 각 가용성 영역에 있는 3개의 Image 서비스(glance) 서버 또는 스토리지 서비스가 필요한 각 지리적 위치에 대한 하드웨어가 있습니다. 엣지 위치에서 이미지 서비스는 DistributedComputeHCI 노드에 배포됩니다.

절차

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

    [stack@director ~]$ source ~/stackrc
  3. 환경 파일 ~/dcn0/dcn0-images-env.yaml을 생성합니다.

    sudo openstack tripleo container image prepare \
    -e containers.yaml \
    --output-env-file /home/stack/dcn0/dcn0-images-env.yaml
  4. dcn0 에지 위치에 적절한 역할을 생성합니다.

    openstack overcloud roles generate DistributedComputeHCI DistributedComputeHCIScaleOut \
    -o ~/dcn0/dcn0_roles.yaml
  5. 오버클라우드의 네트워크를 프로비저닝합니다. 이 명령은 오버클라우드 네트워크의 정의 파일을 입력으로 사용합니다. 오버클라우드를 배포하려면 명령에서 출력 파일을 사용해야 합니다.

    (undercloud)$ openstack overcloud network provision \
    --output /home/stack/dcn0/overcloud-networks-deployed.yaml \
    /home/stack/network_data.yaml
  6. 베어 메탈 인스턴스를 프로비저닝합니다. 이 명령은 베어 메탈 노드의 정의 파일을 입력으로 사용합니다. 오버클라우드를 배포하려면 명령에서 출력 파일을 사용해야 합니다.

    (undercloud)$ openstack overcloud node provision \
    --stack dcn0 \
    --network-config \
    -o /home/stack/dcn0/deployed_metal.yaml \
    /home/stack/overcloud-baremetal-deploy.yaml
  7. 하이퍼컨버지드 스토리지를 사용하여 에지 사이트를 배포하는 경우 다음 매개변수를 사용하여 initial-ceph.conf 구성 파일을 생성해야 합니다. 자세한 내용은 HCI에 대한 Red Hat Ceph Storage 클러스터 구성을 참조하십시오.

    [osd]
    osd_memory_target_autotune = true
    osd_numa_auto_affinity = true
    [mgr]
    mgr/cephadm/autotune_memory_target_ratio = 0.2
  8. deployed_metal.yaml 파일을 openstack overcloud ceph deploy 명령에 대한 입력으로 사용합니다. openstack overcloud ceph deploy 명령은 배포된 Ceph 클러스터를 설명하는 yaml 파일을 출력합니다.

    openstack overcloud ceph deploy \
    /home/stack/dcn0/deployed_metal.yaml \
    --stack dcn0 \
    --config ~/dcn0/initial-ceph.conf \ 1
    --output ~/dcn0/deployed_ceph.yaml \
    --container-image-prepare ~/containers.yaml \
    --network-data ~/network-data.yaml \
    --cluster dcn0 \
    --roles-data dcn_roles.yaml
    1
    하이퍼컨버지드 인프라를 배포할 때만 initial-ceph.conf를 포함합니다.
  9. site-name.yaml 환경 파일에서 사이트의 이름 지정 규칙을 구성합니다. Nova 가용성 영역과 Cinder 스토리지 가용성 영역이 일치해야 합니다.

    parameter_defaults:
        NovaComputeAvailabilityZone: dcn0
        ControllerExtraConfig:
            nova::availability_zone::default_schedule_zone: dcn0
        NovaCrossAZAttach: false
        CinderStorageAvailabilityZone: dcn0
        CinderVolumeCluster: dcn0
        GlanceBackendID: dcn0
  10. 다음과 유사한 콘텐츠로 glance.yaml 템플릿을 구성합니다.

    parameter_defaults:
        GlanceEnabledImportMethods: web-download,copy-image
        GlanceBackend: rbd
        GlanceStoreDescription: 'dcn0 rbd glance store'
        GlanceBackendID: dcn0
        GlanceMultistoreConfig:
          central:
            GlanceBackend: rbd
            GlanceStoreDescription: 'central rbd glance store'
            CephClusterName: central
  11. dcn0 위치의 스택 배포:[d]

    openstack overcloud deploy \
    --deployed-server \
    --stack dcn0 \
    --templates /usr/share/openstack-tripleo-heat-templates/ \
    -r ~/dcn0/dcn0_roles.yaml \
    -n ~/dcn0/network-data.yaml \
    -e /usr/share/openstack-tripleo-heat-templates/environments/network-environment.yaml \
    -e /usr/share/openstack-tripleo-heat-templates/environments/podman.yaml \
    -e /usr/share/openstack-tripleo-heat-templates/environments/dcn-storage.yaml \
    -e /usr/share/openstack-tripleo-heat-templates/environments/cephadm/cephadm-rbd-only.yaml \
    -e /usr/share/openstack-tripleo-heat-templates/environments/nova-az-config.yaml \
    -e /home/stack/overcloud-deploy/central/central-export.yaml \
    -e /home/stack/dcn0/deployed_ceph.yaml \
    -e /home/stack/dcn-common/central_ceph_external.yaml \
    -e /home/stack/dcn0/overcloud-networks-deployed.yaml \yaml \
    -e /home/stack/dcn0/overcloud-vip-deployed.yaml \
    -e /home/stack/dcn0/deployed_metal.yaml \
    -e /home/stack/dcn0/overcloud-networks-deployed.yaml \
    -e ~/control-plane/glance.yaml

7.5. 사전 설치된 Red Hat Ceph Storage 클러스터 사용

기존 Ceph 클러스터를 사용하도록 Red Hat OpenStack Platform을 구성할 수 있습니다. 이를 외부 Ceph 배포라고 합니다.

사전 요구 사항

  • 대기 시간 요구 사항을 초과하지 않도록 DCN 사이트에 로컬인 사전 설치된 Ceph 클러스터가 있어야 합니다.

절차

  1. Ceph 클러스터에 다음 풀을 생성합니다. 중앙 위치에 배포하는 경우 백업지표 풀을 포함합니다.

    [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_>

    <_PGnum_>을 배치 그룹 수로 바꿉니다. 풀 계산기당 Ceph PG(Ceph Placement Groups) 를 사용하여 적절한 값을 결정할 수 있습니다.

  2. Ceph에서 OpenStack 클라이언트 사용자를 생성하여 적절한 풀에 Red Hat OpenStack Platform 환경 액세스 권한을 제공합니다.

    ceph auth add client.openstack mon 'allow r' osd 'allow class-read object_prefix rbd_children, allow rwx pool=volumes, allow rwx pool=vms, allow rwx pool=images'

    반환된 Ceph 클라이언트 키를 저장합니다. 언더클라우드를 구성할 때 이 키를 CephClientKey 매개변수 값으로 사용합니다.

    참고

    중앙 위치에서 이 명령을 실행하고 Cinder 백업 또는 원격 분석 서비스를 사용하려면 allow rwx pool=backups, allow pool=metrics를 명령에 추가합니다.

  3. Ceph Storage 클러스터의 파일 시스템 ID를 저장합니다. Ceph 구성 파일의 [global] 섹션에 있는 fsid 매개변수 값은 파일 시스템 ID입니다.

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

    언더클라우드를 구성할 때 이 값을 CephClusterFSID 매개변수 값으로 사용합니다.

  4. 언더클라우드에서 관리되지 않는 Ceph 클러스터에 연결하도록 노드를 구성하는 환경 파일을 만듭니다. ceph-external-<SITE>.yaml과 같은 인식할 수 있는 이름 지정 규칙을 사용합니다. 여기서SITE는 배포 위치(예: ceph-external-central.yaml, ceph-external-dcn1.yaml 등)입니다.

      parameter_defaults:
        # The cluster FSID
        CephClusterFSID: '4b5c8c0a-ff60-454b-a1b4-9747aa737d19'
        # The CephX user auth key
        CephClientKey: 'AQDLOh1VgEp6FRAAFzT7Zw+Y9V6JJExQAsRnRQ=='
        # The list of IPs or hostnames of the Ceph monitors
        CephExternalMonHost: '172.16.1.7, 172.16.1.8, 172.16.1.9'
        # The desired name of the generated key and conf files
        CephClusterName: dcn1
    1. CephClusterFSID 및 CephClientKey 매개변수에 이전에 저장된 값을 사용합니다.
    2. Ceph 모니터의 쉼표로 구분된 IP 주소 목록을 CephExternalMonHost 매개변수 값으로 사용합니다.
    3. 에지 사이트 중 CephClusterName 매개변수의 고유 값을 선택해야 합니다. 이름을 재사용하면 구성 파일을 덮어씁니다.
  5. Red Hat OpenStack Platform director를 중앙 위치에 사용하여 Red Hat Ceph Storage를 배포한 경우 ceph 구성을 central_ceph_external.yaml 환경 파일로 내보낼 수 있습니다. 이 환경 파일은 DCN 사이트를 중앙 허브 Ceph 클러스터에 연결하므로 해당 정보는 이전 단계에서 배포한 Ceph 클러스터에만 적용됩니다.

    sudo -E openstack overcloud export ceph \
    --stack central \
    --output-file /home/stack/dcn-common/central_ceph_external.yaml

    중앙 위치에 Red Hat Ceph Storage가 외부에 배포된 경우 openstack overcloud export ceph 명령을 사용하여 central_ceph_external.yaml 파일을 생성할 수 없습니다. 대신 central_ceph_external.yaml 파일을 수동으로 생성해야 합니다.

    parameter_defaults:
      CephExternalMultiConfig:
        - cluster: "central"
          fsid: "3161a3b4-e5ff-42a0-9f53-860403b29a33"
          external_cluster_mon_ips: "172.16.11.84, 172.16.11.87, 172.16.11.92"
          keys:
            - name: "client.openstack"
              caps:
                mgr: "allow *"
                mon: "profile rbd"
                osd: "profile rbd pool=vms, profile rbd pool=volumes, profile rbd pool=images"
              key: "AQD29WteAAAAABAAphgOjFD7nyjdYe8Lz0mQ5Q=="
              mode: "0600"
          dashboard_enabled: false
          ceph_conf_overrides:
            client:
              keyring: /etc/ceph/central.client.openstack.keyring
  6. 중앙 위치에 대해 관리되지 않는 Red Hat Ceph Storage 클러스터를 사용하여 각 사이트에 대한 유사한 세부 정보를 사용하여 환경 파일을 만듭니다. 관리되지 않는 Red Hat Ceph Storage 클러스터가 있는 사이트에서는 openstack overcloud export ceph 명령이 작동하지 않습니다. 중앙 위치를 업데이트할 때 이 파일은 에지 사이트의 스토리지 클러스터의 중앙 위치를 보조 위치로 허용합니다.

    parameter_defaults:
      CephExternalMultiConfig:
    cluster: dcn1
    …
    cluster: dcn2
    …
  7. 오버클라우드를 배포할 때 external-ceph.yaml, ceph-external-<SITE>.yaml 및 central_ceph_external.yaml 환경 파일을 사용합니다.

    openstack overcloud deploy \
        --stack dcn1 \
        --templates /usr/share/openstack-tripleo-heat-templates/ \
        -r ~/dcn1/roles_data.yaml \
        -e /usr/share/openstack-tripleo-heat-templates/environments/external-ceph.yaml \
        -e /usr/share/openstack-tripleo-heat-templates/environments/dcn-storage.yaml \
        -e /usr/share/openstack-tripleo-heat-templates/environments/nova-az-config.yaml \
        -e /home/stack/dnc1/ceph-external-dcn1.yaml  \
        ....
        -e /home/stack/overcloud-deploy/central/central-export.yaml \
        -e /home/stack/dcn-common/central_ceph_external.yaml \
        -e /home/stack/dcn1/dcn_ceph_keys.yaml \
        -e /home/stack/dcn1/role-counts.yaml \
        -e /home/stack/dcn1/ceph.yaml \
        -e /home/stack/dcn1/site-name.yaml \
        -e /home/stack/dcn1/tuning.yaml \
        -e /home/stack/dcn1/glance.yaml
  8. 모든 엣지 위치가 배포된 후 중앙 위치를 다시 배포합니다.

7.6. 중앙 위치 업데이트

샘플 절차를 사용하여 모든 에지 사이트를 구성하고 배포한 후 중앙 위치에서 구성을 업데이트하여 중앙 이미지 서비스에서 이미지를 에지 사이트로 푸시할 수 있도록 합니다.

주의

이 절차에서는 Image 서비스(glance)를 다시 시작하고 오래 실행 중인 Image 서비스 프로세스를 중단합니다. 예를 들어, 중앙 이미지 서비스 서버에서 DCN 이미지 서비스 서버로 이미지를 복사하는 경우 해당 이미지 복사본이 중단되고 다시 시작해야 합니다. 자세한 내용은 중단된 이미지 서비스 프로세스 후 남은 데이터 지우기 를 참조하십시오.

절차

  1. 다음과 유사한 ~/central/glance_update.yaml 파일을 만듭니다. 이 예는 두 개의 에지 사이트인 dcn0 및 dcn1에 대한 구성이 포함되어 있습니다.

      parameter_defaults:
        GlanceEnabledImportMethods: web-download,copy-image
        GlanceBackend: rbd
        GlanceStoreDescription: 'central rbd glance store'
        CephClusterName: central
        GlanceBackendID: central
        GlanceMultistoreConfig:
          dcn0:
            GlanceBackend: rbd
            GlanceStoreDescription: 'dcn0 rbd glance store'
            CephClientUserName: 'openstack'
            CephClusterName: dcn0
            GlanceBackendID: dcn0
          dcn1:
            GlanceBackend: rbd
            GlanceStoreDescription: 'dcn1 rbd glance store'
            CephClientUserName: 'openstack'
            CephClusterName: dcn1
            GlanceBackendID: dcn1
  2. dcn_ceph.yaml 파일을 생성합니다. 다음 예에서 이 파일은 중앙 사이트에서 에지 사이트인 dcn0dcn1 의 Ceph 클러스터의 클라이언트로 glance 서비스를 구성합니다.

    openstack overcloud export ceph \
    --stack dcn0,dcn1 \
    --output-file ~/central/dcn_ceph.yaml
  3. 원래 템플릿을 사용하여 중앙 사이트를 다시 배포하고 새로 생성된 dcn_ceph.yamlglance_update.yaml 파일을 포함합니다.

    openstack overcloud deploy \
    --deployed-server \
    --stack central \
    --templates /usr/share/openstack-tripleo-heat-templates/ \
    -r ~/control-plane/central_roles.yaml \
    -n ~/network-data.yaml \
    -e /usr/share/openstack-tripleo-heat-templates/environments/network-environment.yaml \
    -e /usr/share/openstack-tripleo-heat-templates/environments/podman.yaml \
    -e /usr/share/openstack-tripleo-heat-templates/environments/dcn-storage.yaml \
    -e /usr/share/openstack-tripleo-heat-templates/environments/cephadm/cephadm.yaml \
    -e /usr/share/openstack-tripleo-heat-templates/environments/nova-az-config.yaml \
    -e /home/stack/central/overcloud-networks-deployed.yaml \
    -e /home/stack/central/overcloud-vip-deployed.yaml \
    -e /home/stack/central/deployed_metal.yaml \
    -e /home/stack/central/deployed_ceph.yaml \
    -e /home/stack/central/dcn_ceph.yaml \
    -e /home/stack/central/glance_update.yaml
openstack overcloud deploy \
       --stack central \
       --templates /usr/share/openstack-tripleo-heat-templates/ \
       -r ~/central/central_roles.yaml \
    ...
       -e /usr/share/openstack-tripleo-heat-templates/environments/cephadm/cephadm.yaml \
       -e /usr/share/openstack-tripleo-heat-templates/environments/nova-az-config.yaml \
       -e ~/central/central-images-env.yaml \
       -e ~/central/role-counts.yaml \
       -e ~/central/site-name.yaml
       -e ~/central/ceph.yaml \
       -e ~/central/ceph_keys.yaml \
       -e ~/central/glance.yaml \
       -e ~/central/dcn_ceph_external.yaml
  1. 중앙 위치의 컨트롤러에서 cinder-volume 서비스를 다시 시작합니다. cinder-backup 서비스로 중앙 위치를 배포한 경우 cinder-backup 서비스도 다시 시작합니다.

    ssh tripleo-admin@controller-0 sudo pcs resource restart openstack-cinder-volume
    ssh tripleo-admin@controller-0 sudo pcs resource restart openstack-cinder-backup

7.6.1. 이미지 서비스 프로세스가 중단된 후 잔여 데이터 삭제

중앙 위치를 다시 시작하면 장기 실행 Image 서비스(glance) 프로세스가 중단됩니다. 이러한 프로세스를 재시작하려면 먼저 재부팅한 컨트롤러 노드와 Ceph 및 이미지 서비스 데이터베이스에서 남은 데이터를 정리해야 합니다.

절차

  1. 재부팅된 컨트롤러 노드에서 데이터를 확인하고 지웁니다. 스테이징 저장소에 대한 glance-api.conf 파일의 파일을 이미지 서비스 데이터베이스의 해당 이미지와 비교합니다(예: < image_ID>.raw ).

    • 이러한 해당 이미지에 가져오기 상태가 표시되는 경우 이미지를 다시 생성해야 합니다.
    • 이미지에 활성 상태가 표시되면 스테이징에서 데이터를 삭제하고 복사 가져오기를 다시 시작해야 합니다.
  2. Ceph 저장소의 데이터를 확인하고 지웁니다. 스테이징 영역에서 정리한 이미지에는 이미지가 포함된 Ceph 저장소의 stores 속성에 일치하는 레코드가 있어야 합니다. Ceph의 이미지 이름은 이미지 서비스 데이터베이스의 이미지 ID입니다.
  3. 이미지 서비스 데이터베이스를 지웁니다. 가져오기 작업에서 상태가 중단된 이미지를 지웁니다.

    $ glance image-delete <image_id>

7.7. DCN에 Red Hat Ceph Storage 대시보드 배포

절차

Red Hat Ceph Storage 대시보드를 중앙 위치에 배포하려면 오버클라우드 배포에 Red Hat Ceph Storage 대시보드 추가를 참조하십시오. 이러한 단계는 중앙 위치를 배포하기 전에 완료해야 합니다.

Red Hat Ceph Storage 대시보드를 에지 위치에 배포하려면 중앙에 대해 완료한 것과 동일한 단계를 완료하되 다음을 완료해야 합니다.

  • 에지 사이트를 배포하기 위해 템플릿에서 ManageNetworks 매개변수 값이 false 인지 확인합니다. ManageNetworksfalse 로 설정하면 Edge 사이트에서 중앙 스택에 이미 생성된 기존 네트워크를 사용합니다.

    parameter_defaults:
      ManageNetworks: false
  • 고가용성 가상 IP를 만들려면 로드 밸런싱을 위한 자체 솔루션을 배포해야 합니다. 에지 사이트는 haproxy 또는 pacemaker를 배포하지 않습니다. Red Hat Ceph Storage 대시보드를 에지 위치에 배포하면 스토리지 네트워크에 배포가 노출됩니다. 대시보드는 로드 밸런싱 솔루션 없이 별도의 IP 주소가 있는 3개의 DistributedComputeHCI 노드 각각에 설치됩니다.

Ceph 대시보드를 노출할 수 있는 가상 IP에 대한 추가 네트워크를 생성할 수 있습니다. 여러 스택에 네트워크 리소스를 재사용해서는 안 됩니다. 네트워크 리소스를 재사용하는 방법에 대한 자세한 내용은 여러 스택에서 네트워크 리소스 사용을 참조하십시오.

이 추가 네트워크 리소스를 생성하려면 제공된 network_data_dashboard.yaml heat 템플릿을 사용합니다. 생성된 네트워크의 이름은 StorageDashboard 입니다.

절차

  1. Red Hat OpenStack Platform Director에 stack 으로 로그인합니다.
  2. 환경에 적합한 DistributedComputeHCIDashboard 역할 및 기타 역할을 생성합니다.

    openstack overcloud roles generate DistributedComputeHCIDashboard -o ~/dnc0/roles.yaml
  3. 오버클라우드 배포 명령에 roles.yamlnetwork_data_dashboard.yaml 을 포함합니다.

    $ openstack overcloud deploy --templates \
    -r ~/<dcn>/<dcn_site_roles>.yaml \
    -n /usr/share/openstack-tripleo-heat-templates/network_data_dashboard.yaml \
    -e <overcloud_environment_files> \
    ...
    -e /usr/share/openstack-tripleo-heat-templates/environments/cephadm/cephadm-rbd-only.yaml \
    -e /usr/share/openstack-tripleo-heat-templates/environments/cephadm/ceph-dashboard.yaml \
참고

배포에서는 스토리지 네트워크에서 대시보드가 활성화된 세 개의 IP 주소를 제공합니다.

검증

대시보드가 중앙 위치에서 작동하고 Ceph 클러스터에서 표시되는 데이터가 올바른지 확인하려면 Ceph 대시보드 액세스를 참조하십시오.

유사한 단계를 통해 대시보드가 에지 위치에서 작동하는지 확인할 수 있지만 에지 위치에 로드 밸런서가 없기 때문에 예외가 있습니다.

  1. 선택한 스택과 관련된 대시보드 관리자 로그인 자격 증명을 검색합니다.

    grep grafana_admin /home/stack/config-download/<stack>/cephadm/cephadm-extra-vars-heat.yml
  2. 선택한 스택에 고유한 인벤토리 내에서 /home/stack/config-download/<stack>/cephadm/inventory.yml .yml 에서 DistributedComputeHCI 역할 호스트 목록을 찾아 storage_ip 값 중 세 개를 모두 저장합니다. 아래 예제에서 처음 두 개의 대시보드 IP는 172.16.11.84 및 172.16.11.87입니다.

    DistributedComputeHCI:
      hosts:
        dcn1-distributed-compute-hci-0:
          ansible_host: 192.168.24.16
    ...
    storage_hostname: dcn1-distributed-compute-hci-0.storage.localdomain
    storage_ip: 172.16.11.84
    ...
        dcn1-distributed-compute-hci-1:
    ansible_host: 192.168.24.22
    ...
    storage_hostname: dcn1-distributed-compute-hci-1.storage.localdomain
    storage_ip: 172.16.11.87
  3. 이러한 IP 주소 중 하나에서 Ceph 대시보드가 활성화되어 있는지 확인할 수 있습니다. 이러한 IP 주소는 스토리지 네트워크에 있으며 라우팅되지 않습니다. 이러한 IP 주소를 사용할 수 없는 경우 확인을 위해 가상 IP 주소를 가져오기 위해 인벤토리에서 가져온 세 개의 IP 주소에 대해 로드 밸런서를 구성해야 합니다.

8장. DistributedComputeHCI 노드 교체

하드웨어 유지보수 중에 에지 사이트에서 DistributedComputeHCI 노드를 확장, 확장 또는 교체해야 할 수 있습니다. DistributedComputeHCI 노드를 교체하려면 교체 중인 노드에서 서비스를 제거하고 노드 수를 축소한 다음 해당 노드를 백업하는 절차를 따릅니다.

8.1. Red Hat Ceph Storage 서비스 제거

클러스터에서 HCI(하이퍼 컨버지드) 노드를 제거하려면 먼저 Red Hat Ceph Storage 서비스를 제거해야 합니다. Red Hat Ceph 서비스를 제거하려면 제거할 노드의 클러스터 서비스에서 ceph-osd 서비스를 비활성화 및 제거한 다음 mon,mgr, osd 서비스를 중지하고 비활성화해야 합니다.

절차

  1. 언더클라우드에서 SSH를 사용하여 삭제하려는 DistributedComputeHCI 노드에 연결합니다.

    $ ssh tripleo-admin@<dcn-computehci-node>
  2. cephadm 쉘을 시작합니다. 제거 중인 호스트의 구성 파일 및 키링 파일을 사용합니다.

    $ sudo cephadm shell --config /etc/ceph/dcn2.conf \
    --keyring /etc/ceph/dcn2.client.admin.keyring
  3. 이후 단계에서 사용하기 위해 제거할 DistributedComputeHCI 노드와 연관된 OSD(오브젝트 스토리지 장치)를 기록합니다.

    [ceph: root@dcn2-computehci2-1 ~]# ceph osd tree -c /etc/ceph/dcn2.conf
    …
    -3       0.24399     host dcn2-computehci2-1
     1   hdd 0.04880         osd.1                           up  1.00000 1.00000
     7   hdd 0.04880         osd.7                           up  1.00000 1.00000
    11   hdd 0.04880         osd.11                          up  1.00000 1.00000
    15   hdd 0.04880         osd.15                          up  1.00000 1.00000
    18   hdd 0.04880         osd.18                          up  1.00000 1.00000
    …
  4. SSH를 사용하여 동일한 클러스터의 다른 노드에 연결하고 클러스터에서 모니터를 제거합니다.

    $ sudo cephadm shell --config /etc/ceph/dcn2.conf \
    --keyring /etc/ceph/dcn2.client.admin.keyring
    
    [ceph: root@dcn-computehci2-0]# ceph mon remove dcn2-computehci2-1 -c /etc/ceph/dcn2.conf
    removing mon.dcn2-computehci2-1 at [v2:172.23.3.153:3300/0,v1:172.23.3.153:6789/0], there will be 2 monitors
  5. SSH를 사용하여 클러스터에서 제거 중인 노드에 다시 로그인합니다.
  6. mgr 서비스를 중지하고 비활성화합니다.

    [tripleo-admin@dcn2-computehci2-1 ~]$ sudo systemctl --type=service | grep ceph
    ceph-crash@dcn2-computehci2-1.service    loaded active     running       Ceph crash dump collector
    ceph-mgr@dcn2-computehci2-1.service      loaded active     running       Ceph Manager
    
    [tripleo-admin@dcn2-computehci2-1 ~]$ sudo systemctl stop ceph-mgr@dcn2-computehci2-1
    
    [tripleo-admin@dcn2-computehci2-1 ~]$ sudo systemctl --type=service | grep ceph
    ceph-crash@dcn2-computehci2-1.service  loaded active running Ceph crash dump collector
    
    [tripleo-admin@dcn2-computehci2-1 ~]$ sudo systemctl disable ceph-mgr@dcn2-computehci2-1
    Removed /etc/systemd/system/multi-user.target.wants/ceph-mgr@dcn2-computehci2-1.service.
  7. cephadm 쉘을 시작합니다.

    $ sudo cephadm shell --config /etc/ceph/dcn2.conf \
    --keyring /etc/ceph/dcn2.client.admin.keyring
  8. 노드의 mgr 서비스가 클러스터에서 제거되었는지 확인합니다.

    [ceph: root@dcn2-computehci2-1 ~]# ceph -s
    
    cluster:
        id:     b9b53581-d590-41ac-8463-2f50aa985001
        health: HEALTH_WARN
                3 pools have too many placement groups
                mons are allowing insecure global_id reclaim
    
      services:
        mon: 2 daemons, quorum dcn2-computehci2-2,dcn2-computehci2-0 (age 2h)
        mgr: dcn2-computehci2-2(active, since 20h), standbys: dcn2-computehci2-0 1
        osd: 15 osds: 15 up (since 3h), 15 in (since 3h)
    
      data:
        pools:   3 pools, 384 pgs
        objects: 32 objects, 88 MiB
        usage:   16 GiB used, 734 GiB / 750 GiB avail
        pgs:     384 active+clean
    1
    mgr 서비스가 제거된 노드는 mgr 서비스가 성공적으로 제거될 때 더 이상 나열되지 않습니다.
  9. Red Hat Ceph Storage 사양을 내보냅니다.

    [ceph: root@dcn2-computehci2-1 ~]# ceph orch ls --export > spec.yml
  10. spec.yaml 파일의 사양을 편집합니다.

    • spec.yml에서 호스트 <dcn-computehci-node>의 모든 인스턴스를 제거합니다.
    • 다음에서 <dcn-computehci-node> 항목의 모든 인스턴스를 제거합니다.

      • service_type: osd
      • service_type: mon
      • service_type: host
  11. Red Hat Ceph Storage 사양을 다시 적용합니다.

    [ceph: root@dcn2-computehci2-1 /]# ceph orch apply -i spec.yml
  12. ceph osd 트리를 사용하여 식별한 OSD를 제거합니다.

    [ceph: root@dcn2-computehci2-1 /]# ceph orch osd rm --zap 1 7 11 15 18
    Scheduled OSD(s) for removal
  13. 제거 중인 OSD의 상태를 확인합니다. 다음 명령에서 출력을 반환하지 않을 때까지 계속하지 마십시오.

    [ceph: root@dcn2-computehci2-1 /]# ceph orch osd rm status
    OSD_ID  HOST                    STATE     PG_COUNT  REPLACE  FORCE  DRAIN_STARTED_AT
    1       dcn2-computehci2-1      draining  27        False    False  2021-04-23 21:35:51.215361
    7       dcn2-computehci2-1      draining  8         False    False  2021-04-23 21:35:49.111500
    11      dcn2-computehci2-1      draining  14        False    False  2021-04-23 21:35:50.243762
  14. 제거 중인 호스트에서 데몬이 남아 있지 않은지 확인합니다.

    [ceph: root@dcn2-computehci2-1 /]# ceph orch ps dcn2-computehci2-1

    데몬이 여전히 있는 경우 다음 명령을 사용하여 제거할 수 있습니다.

    [ceph: root@dcn2-computehci2-1 /]# ceph orch host drain dcn2-computehci2-1
  15. Red Hat Ceph Storage 클러스터에서 <dcn-computehci-node> 호스트를 제거합니다.

    [ceph: root@dcn2-computehci2-1 /]# ceph orch host rm dcn2-computehci2-1
    Removed host ‘dcn2-computehci2-1’

8.2. Image 서비스(glance) 서비스 제거

서비스에서 이미지를 삭제할 때 노드에서 이미지 서비스를 제거합니다.

절차

  • 이미지 서비스 서비스를 비활성화하려면 제거 중인 노드에서 systemctl 을 사용하여 비활성화합니다.

    [root@dcn2-computehci2-1 ~]# systemctl stop tripleo_glance_api.service
    [root@dcn2-computehci2-1 ~]# systemctl stop  tripleo_glance_api_tls_proxy.service
    
    [root@dcn2-computehci2-1 ~]# systemctl disable tripleo_glance_api.service
    Removed /etc/systemd/system/multi-user.target.wants/tripleo_glance_api.service.
    [root@dcn2-computehci2-1 ~]# systemctl disable  tripleo_glance_api_tls_proxy.service
    Removed /etc/systemd/system/multi-user.target.wants/tripleo_glance_api_tls_proxy.service.

8.3. Block Storage(cinder) 서비스 제거

서비스에서 Cinder를 제거할 때 DistributedComputeHCI 노드에서 cinder-volumeetcd 서비스를 제거해야 합니다.

절차

  1. 제거 중인 노드에서 cinder-volume 서비스를 식별하고 비활성화합니다.

    (central) [stack@site-undercloud-0 ~]$ openstack volume service list --service cinder-volume
    | cinder-volume | dcn2-computehci2-1@tripleo_ceph | az-dcn2    | enabled | up    | 2022-03-23T17:41:43.000000 |
    (central) [stack@site-undercloud-0 ~]$ openstack volume service set --disable dcn2-computehci2-1@tripleo_ceph cinder-volume
  2. 스택의 다른 DistributedComputeHCI 노드에 로그온합니다.

    $ ssh tripleo-admin@dcn2-computehci2-0
  3. 제거 중인 노드와 연결된 cinder-volume 서비스를 삭제합니다.

    [root@dcn2-computehci2-0 ~]# podman exec -it cinder_volume cinder-manage service remove cinder-volume dcn2-computehci2-1@tripleo_ceph
    Service cinder-volume on host dcn2-computehci2-1@tripleo_ceph removed.
  4. 제거 중인 노드에서 tripleo_cinder_volume 서비스를 중지하고 비활성화합니다.

    [root@dcn2-computehci2-1 ~]# systemctl stop tripleo_cinder_volume.service
    [root@dcn2-computehci2-1 ~]# systemctl disable tripleo_cinder_volume.service
    Removed /etc/systemd/system/multi-user.target.wants/tripleo_cinder_volume.service

8.4. DistributedComputeHCI 노드 삭제

provisioned 매개변수를 false 값으로 설정하고 스택에서 노드를 삭제합니다. nova-compute 서비스를 비활성화하고 관련 네트워크 에이전트를 삭제합니다.

절차

  1. baremetal-deployment.yaml 파일을 복사합니다.

    cp /home/stack/dcn2/overcloud-baremetal-deploy.yaml \
    /home/stack/dcn2/baremetal-deployment-scaledown.yaml
  2. baremetal-deployement-scaledown.yaml 파일을 편집합니다. 제거할 호스트를 확인하고 provisioned 매개변수를 false 값으로 설정합니다.

    instances:
    ...
      - hostname: dcn2-computehci2-1
        provisioned: false
  3. 스택에서 노드를 삭제합니다.

    openstack overcloud node delete --stack dcn2 --baremetal-deployment /home/stack/dcn2/baremetal_deployment_scaledown.yaml
  4. 선택 사항: 노드를 재사용하려면 ironic을 사용하여 디스크를 정리합니다. 이는 노드가 Ceph OSD를 호스팅하는 경우 필요합니다.

    openstack baremetal node manage $UUID
    openstack baremetal node clean $UUID --clean-steps '[{"interface":"deploy", "step": "erase_devices_metadata"}]'
    openstack baremetal provide $UUID
  5. 중앙 사이트를 재배포합니다. 초기 구성에 사용한 모든 템플릿을 포함합니다.

    openstack overcloud deploy \
    --deployed-server \
    --stack central \
    --templates /usr/share/openstack-tripleo-heat-templates/ \
    -r ~/control-plane/central_roles.yaml \
    -n ~/network-data.yaml \
    -e /usr/share/openstack-tripleo-heat-templates/environments/network-environment.yaml \
    -e /usr/share/openstack-tripleo-heat-templates/environments/podman.yaml \
    -e /usr/share/openstack-tripleo-heat-templates/environments/dcn-storage.yaml \
    -e /usr/share/openstack-tripleo-heat-templates/environments/cephadm/cephadm.yaml \
    -e /usr/share/openstack-tripleo-heat-templates/environments/nova-az-config.yaml \
    -e /home/stack/central/overcloud-networks-deployed.yaml \
    -e /home/stack/central/overcloud-vip-deployed.yaml \
    -e /home/stack/central/deployed_metal.yaml \
    -e /home/stack/central/deployed_ceph.yaml \
    -e /home/stack/central/dcn_ceph.yaml \
    -e /home/stack/central/glance_update.yaml

8.5. 삭제된 DistributedComputeHCI 노드 교체

8.5.1. 삭제된 DistributedComputeHCI 노드 교체

DCN 배포에 새 HCI 노드를 추가하려면 추가 노드를 사용하여 에지 스택을 재배포하고 해당 스택의 ceph 내보내기 를 수행한 다음 중앙 위치에 대한 스택 업데이트를 수행해야 합니다. 중앙 위치의 스택 업데이트는 에지 사이트에 고유한 구성을 추가합니다.

사전 요구 사항

노드 수는 에서 노드를 교체하려는 스택의 nodes_data.yaml 파일에 올바르거나 새 노드를 추가할 수 있습니다.

절차

  1. 배포 스크립트에서 호출한 템플릿 중 하나에서 EtcdIntialClusterState 매개변수를 existing 로 설정해야 합니다.

    parameter_defaults:
      EtcdInitialClusterState: existing
  2. 스택과 관련된 배포 스크립트를 사용하여 재배포합니다.

    (undercloud) [stack@site-undercloud-0 ~]$ ./overcloud_deploy_dcn2.sh
    …
    Overcloud Deployed without error
  3. 스택에서 Red Hat Ceph Storage 데이터를 내보냅니다.

    (undercloud) [stack@site-undercloud-0 ~]$ sudo -E openstack overcloud export ceph --stack dcn1,dcn2 --config-download-dir /var/lib/mistral --output-file ~/central/dcn2_scale_up_ceph_external.yaml
  4. 중앙 위치에 대한 배포 스크립트에서 dcn_ceph_external.yaml을 새로 생성된 dcn2_scale_up_ceph_external.yaml로 교체합니다.
  5. 중앙에서 스택 업데이트를 수행합니다.

    (undercloud) [stack@site-undercloud-0 ~]$ ./overcloud_deploy.sh
    ...
    Overcloud Deployed without error

8.6. 교체된 DistributedComputeHCI 노드의 기능 확인

  1. status 필드의 값이 활성화되어 있는지 확인하고 State 필드의 값이 up 인지 확인합니다.

    (central) [stack@site-undercloud-0 ~]$ openstack compute service list -c Binary -c Host -c Zone -c Status -c State
    +----------------+-----------------------------------------+------------+---------+-------+
    | Binary         | Host                                    | Zone       | Status  | State |
    +----------------+-----------------------------------------+------------+---------+-------+
    ...
    | nova-compute   | dcn1-compute1-0.redhat.local            | az-dcn1    | enabled | up    |
    | nova-compute   | dcn1-compute1-1.redhat.local            | az-dcn1    | enabled | up    |
    | nova-compute   | dcn2-computehciscaleout2-0.redhat.local | az-dcn2    | enabled | up    |
    | nova-compute   | dcn2-computehci2-0.redhat.local         | az-dcn2    | enabled | up    |
    | nova-compute   | dcn2-computescaleout2-0.redhat.local    | az-dcn2    | enabled | up    |
    | nova-compute   | dcn2-computehci2-2.redhat.local         | az-dcn2    | enabled | up    |
    ...
  2. 모든 네트워크 에이전트가 up 상태인지 확인합니다.

    (central) [stack@site-undercloud-0 ~]$ openstack network agent list -c "Agent Type" -c Host -c Alive -c State
    +--------------------+-----------------------------------------+-------+-------+
    | Agent Type         | Host                                    | Alive | State |
    +--------------------+-----------------------------------------+-------+-------+
    | DHCP agent         | dcn3-compute3-1.redhat.local            | :-)   | UP    |
    | Open vSwitch agent | central-computehci0-1.redhat.local      | :-)   | UP    |
    | DHCP agent         | dcn3-compute3-0.redhat.local            | :-)   | UP    |
    | DHCP agent         | central-controller0-2.redhat.local      | :-)   | UP    |
    | Open vSwitch agent | dcn3-compute3-1.redhat.local            | :-)   | UP    |
    | Open vSwitch agent | dcn1-compute1-1.redhat.local            | :-)   | UP    |
    | Open vSwitch agent | central-computehci0-0.redhat.local      | :-)   | UP    |
    | DHCP agent         | central-controller0-1.redhat.local      | :-)   | UP    |
    | L3 agent           | central-controller0-2.redhat.local      | :-)   | UP    |
    | Metadata agent     | central-controller0-1.redhat.local      | :-)   | UP    |
    | Open vSwitch agent | dcn2-computescaleout2-0.redhat.local    | :-)   | UP    |
    | Open vSwitch agent | dcn2-computehci2-5.redhat.local         | :-)   | UP    |
    | Open vSwitch agent | central-computehci0-2.redhat.local      | :-)   | UP    |
    | DHCP agent         | central-controller0-0.redhat.local      | :-)   | UP    |
    | Open vSwitch agent | central-controller0-1.redhat.local      | :-)   | UP    |
    | Open vSwitch agent | dcn2-computehci2-0.redhat.local         | :-)   | UP    |
    | Open vSwitch agent | dcn1-compute1-0.redhat.local            | :-)   | UP    |
    ...
  3. Ceph 클러스터의 상태를 확인합니다.

    1. SSH를 사용하여 새 DistributedComputeHCI 노드에 연결하고 Ceph 클러스터의 상태를 확인합니다.

      [root@dcn2-computehci2-5 ~]# podman exec -it ceph-mon-dcn2-computehci2-5 \
      ceph -s -c /etc/ceph/dcn2.conf
    2. 새 노드에 대해 ceph mon 및 ceph mgr 서비스가 모두 있는지 확인합니다.

      services:
          mon: 3 daemons, quorum dcn2-computehci2-2,dcn2-computehci2-0,dcn2-computehci2-5 (age 3d)
          mgr: dcn2-computehci2-2(active, since 3d), standbys: dcn2-computehci2-0, dcn2-computehci2-5
          osd: 20 osds: 20 up (since 3d), 20 in (since 3d)
    3. 'ceph osd tree'를 사용하여 ceph osds의 상태를 확인합니다. 새 노드의 모든 osds가 STATUS up에 있는지 확인합니다.

      [root@dcn2-computehci2-5 ~]# podman exec -it ceph-mon-dcn2-computehci2-5 ceph osd tree -c /etc/ceph/dcn2.conf
      ID CLASS WEIGHT  TYPE NAME                           STATUS REWEIGHT PRI-AFF
      -1       0.97595 root default
      -5       0.24399     host dcn2-computehci2-0
       0   hdd 0.04880         osd.0                           up  1.00000 1.00000
       4   hdd 0.04880         osd.4                           up  1.00000 1.00000
       8   hdd 0.04880         osd.8                           up  1.00000 1.00000
      13   hdd 0.04880         osd.13                          up  1.00000 1.00000
      17   hdd 0.04880         osd.17                          up  1.00000 1.00000
      -9       0.24399     host dcn2-computehci2-2
       3   hdd 0.04880         osd.3                           up  1.00000 1.00000
       5   hdd 0.04880         osd.5                           up  1.00000 1.00000
      10   hdd 0.04880         osd.10                          up  1.00000 1.00000
      14   hdd 0.04880         osd.14                          up  1.00000 1.00000
      19   hdd 0.04880         osd.19                          up  1.00000 1.00000
      -3       0.24399     host dcn2-computehci2-5
       1   hdd 0.04880         osd.1                           up  1.00000 1.00000
       7   hdd 0.04880         osd.7                           up  1.00000 1.00000
      11   hdd 0.04880         osd.11                          up  1.00000 1.00000
      15   hdd 0.04880         osd.15                          up  1.00000 1.00000
      18   hdd 0.04880         osd.18                          up  1.00000 1.00000
      -7       0.24399     host dcn2-computehciscaleout2-0
       2   hdd 0.04880         osd.2                           up  1.00000 1.00000
       6   hdd 0.04880         osd.6                           up  1.00000 1.00000
       9   hdd 0.04880         osd.9                           up  1.00000 1.00000
      12   hdd 0.04880         osd.12                          up  1.00000 1.00000
      16   hdd 0.04880         osd.16                          up  1.00000 1.00000
  4. 새로운 DistributedComputeHCI 노드의 cinder-volume 서비스가 Status 'enabled' 및 State 'up'에 있는지 확인합니다.

    (central) [stack@site-undercloud-0 ~]$ openstack volume service list --service cinder-volume -c Binary -c Host -c Zone -c Status -c State
    +---------------+---------------------------------+------------+---------+-------+
    | Binary        | Host                            | Zone       | Status  | State |
    +---------------+---------------------------------+------------+---------+-------+
    | cinder-volume | hostgroup@tripleo_ceph          | az-central | enabled | up    |
    | cinder-volume | dcn1-compute1-1@tripleo_ceph    | az-dcn1    | enabled | up    |
    | cinder-volume | dcn1-compute1-0@tripleo_ceph    | az-dcn1    | enabled | up    |
    | cinder-volume | dcn2-computehci2-0@tripleo_ceph | az-dcn2    | enabled | up    |
    | cinder-volume | dcn2-computehci2-2@tripleo_ceph | az-dcn2    | enabled | up    |
    | cinder-volume | dcn2-computehci2-5@tripleo_ceph | az-dcn2    | enabled | up    |
    +---------------+---------------------------------+------------+---------+-------+
    참고

    cinder-volume 서비스의 상태가 down 인 경우 노드에서 서비스가 시작되지 않습니다.

  5. ssh를 사용하여 새 DistributedComputeHCI 노드에 연결하고 'systemctl'을 사용하여 Glance 서비스의 상태를 확인합니다.

    [root@dcn2-computehci2-5 ~]# systemctl --type service | grep glance
      tripleo_glance_api.service                        loaded active     running       glance_api container
      tripleo_glance_api_healthcheck.service            loaded activating start   start glance_api healthcheck
      tripleo_glance_api_tls_proxy.service              loaded active     running       glance_api_tls_proxy container

8.7. DistributedComputeHCI 상태 문제 해결

EtcdInitialClusterState 매개변수 값을 기존 로 설정하지 않고 대체 노드를 배포한 경우 openstack volume service list 를 실행할 때 교체된 노드의 cinder-volume 서비스가 down 으로 표시됩니다.

절차

  1. 대체 노드에 로그인하고 etcd 서비스의 로그를 확인합니다. 로그에 etcd 서비스가 /var/log/containers/stdouts/etcd.log 로그 파일에서 클러스터 ID 불일치를 보고하고 있는지 확인합니다.

    2022-04-06T18:00:11.834104130+00:00 stderr F 2022-04-06 18:00:11.834045 E | rafthttp: request cluster ID mismatch (got 654f4cf0e2cfb9fd want 918b459b36fe2c0c)
  2. EtcdInitialClusterState 매개변수를 배포 템플릿에 있는 기존 값으로 설정하고 배포 스크립트를 재실행합니다.
  3. SSH를 사용하여 교체 노드에 연결하고 root로 다음 명령을 실행합니다.

    [root@dcn2-computehci2-4 ~]# systemctl stop tripleo_etcd
    [root@dcn2-computehci2-4 ~]# rm -rf /var/lib/etcd/*
    [root@dcn2-computehci2-4 ~]# systemctl start tripleo_etcd
  4. /var/log/containers/stdouts/etcd.log 로그 파일을 다시 확인하여 노드가 클러스터에 성공적으로 참여했는지 확인합니다.

    2022-04-06T18:24:22.130059875+00:00 stderr F 2022-04-06 18:24:22.129395 I | etcdserver/membership: added member 96f61470cd1839e5 [https://dcn2-computehci2-4.internalapi.redhat.local:2380] to cluster 654f4cf0e2cfb9fd
  5. cinder-volume 서비스의 상태를 확인하고 openstack volume service list 실행할 때 대체 노드에서 읽히는지 확인합니다.

9장. 키 관리자를 사용한 배포

Red Hat OpenStack Platform 16.1.2 릴리스 전에 에지 사이트를 배포한 경우 이 기능을 구현하려면 roles.yaml을 다시 생성해야 합니다. 기능을 구현하려면 DCN 사이트의 배포에 사용된 roles.yaml 파일을 다시 생성합니다.

$ openstack overcloud roles generate DistributedComputeHCI DistributedComputeHCIScaleOut -o ~/dcn0/roles_data.yaml

9.1. 키 관리자를 사용하여 에지 사이트 배포

에지 사이트에서 키 관리자(barbican) 서비스에 대한 액세스를 포함하려면 중앙 위치에서 barbican을 구성해야 합니다. 바비칸 설치 및 구성에 대한 자세한 내용은 Deploying Barbican 을 참조하십시오.

  • /usr/share/openstack-tripleo-heat-templates/environments/services/barbican-edge.yaml 을 포함하여 DCN 사이트의 barbican에 대한 액세스를 구성할 수 있습니다.

    openstack overcloud deploy \
        --stack dcn0 \
        --templates /usr/share/openstack-tripleo-heat-templates/ \
        -r ~/dcn0/roles_data.yaml \
        ....
        -e /usr/share/openstack-tripleo-heat-templates/environments/services/barbican-edge.yaml

10장. glance 이미지를 nova로 캐싱

로컬 임시 스토리지를 사용하도록 OpenStack Compute를 구성하면 Glance 이미지가 캐시되어 인스턴스 배포를 가속화합니다. 인스턴스에 필요한 이미지가 아직 캐시되지 않은 경우 인스턴스를 생성할 때 컴퓨팅 노드의 로컬 디스크에 다운로드됩니다.

glance 이미지를 다운로드하는 프로세스는 이미지 크기 및 대역폭 및 대기 시간과 같은 네트워크 특성에 따라 가변 시간이 걸립니다.

인스턴스를 시작하려고 하면 로컬의 Ceph 클러스터에서 이미지를 사용할 수 없는 경우 다음 메시지와 함께 인스턴스를 시작할 수 없습니다.

Build of instance 3c04e982-c1d1-4364-b6bd-f876e399325b aborted: Image 20c5ff9d-5f54-4b74-830f-88e78b9999ed is unacceptable: No image locations are accessible

Compute 서비스 로그에 다음이 표시됩니다.

'Image %s is not on my ceph and [workarounds]/ never_download_image_if_on_rbd=True; refusing to fetch and upload.',

DCN 배포의 경우 기본적으로 설정되는 never_download_image_if_on_rbd 라는 nova.conf 구성 파일의 매개 변수로 인해 인스턴스가 시작되지 않습니다. dcn-storage.yaml 파일에서 찾을 수 있는 heat 매개변수 NovaDisableImageDownloadToRbd 를 사용하여 이 값을 제어할 수 있습니다.

오버클라우드를 배포하기 전에 NovaDisableImageDownloadToRbd 값을 false 로 설정하면 다음이 수행됩니다.

  • Compute 서비스(nova)는 로컬에서 사용할 수 없는 경우 중앙 위치에서 사용 가능한 이미지를 자동으로 스트리밍합니다.
  • Glance 이미지의 COW 복사본을 사용하지 않습니다.
  • Compute(nova) 스토리지에는 사용 중인 인스턴스 수에 따라 동일한 이미지의 여러 사본이 포함될 수 있습니다.
  • nova 스토리지 풀과 중앙 위치에 대한 WAN 링크를 모두 포화시킬 수 있습니다.

Red Hat은 이 값을 true로 설정하고 인스턴스를 시작하기 전에 로컬에서 필요한 이미지를 사용할 수 있도록 권장합니다. 에지에서 이미지를 사용할 수 있도록 하는 방법에 대한 자세한 내용은 A.1.3절. “새 사이트에 이미지 복사” 을 참조하십시오.

로컬인 이미지의 경우 tripleo_nova_image_cache.yml ansible 플레이북을 사용하여 나중에 배포할 수 있는 일반적으로 사용되는 이미지 또는 이미지를 사전 캐시하여 VM 생성 속도를 높일 수 있습니다.

10.1. tripleo_nova_image_cache.yml ansible 플레이북 실행

사전 요구 사항

  • 쉘 환경에서 올바른 API에 대한 인증 자격 증명.

각 단계에서 제공한 명령 전에 올바른 인증 파일을 가져와야 합니다.

절차

  1. 스택의 ansible 인벤토리 파일을 생성합니다. 여러 스택을 쉼표로 구분된 목록으로 지정하여 두 개 이상의 사이트에서 이미지를 캐시할 수 있습니다.

    $ source stackrc
    
    $ tripleo-ansible-inventory --plan central,dcn0,dcn1 \
    --static-yaml-inventory inventory.yaml
  2. 사전 캐시할 이미지 ID 목록을 생성합니다.

    1. 사용 가능한 포괄적인 이미지 목록을 검색합니다.

      $ source centralrc
      
      $ openstack image list
      +--------------------------------------+---------+--------+
      | ID                                   | Name    | Status |
      +--------------------------------------+---------+--------+
      | 07bc2424-753b-4f65-9da5-5a99d8383fe6 | image_0 | active |
      | d5187afa-c821-4f22-aa4b-4e76382bef86 | image_1 | active |
      +--------------------------------------+---------+--------+
    2. nova_cache_args.yml 라는 ansible 플레이북 인수 파일을 생성하고 사전 캐시할 이미지의 ID를 추가합니다.

      ---
      tripleo_nova_image_cache_images:
        - id: 07bc2424-753b-4f65-9da5-5a99d8383fe6
        - id: d5187afa-c821-4f22-aa4b-4e76382bef86
  3. tripleo_nova_image_cache.yml ansible 플레이북을 실행합니다.

    $ source centralrc
    
    $ ansible-playbook -i inventory.yaml \
    --extra-vars "@nova_cache_args.yml" \
    /usr/share/ansible/tripleo-playbooks/tripleo_nova_image_cache.yml

10.2. 성능 고려 사항

ansible forks 매개변수를 사용하여 동시에 다운로드하려는 이미지 수를 지정할 수 있습니다. 기본값은 5 입니다. forks 매개변수 값을 증가하여 이 이미지를 배포하는 시간을 줄일 수 있지만 네트워크 및 glance-api 로드 증가로 이 값을 조정해야 합니다.

다음과 같이 --forks 매개변수를 사용하여 동시성을 조정합니다.

ansible-playbook -i inventory.yaml \
--forks 10 \
--extra-vars "@nova_cache_args.yml" \
/usr/share/ansible/tripleo-playbooks/tripleo_nova_image_cache.yml

10.3. DCN 사이트에 이미지 배포 최적화

Glance 이미지 배포에 프록시를 사용하여 WAN 트래픽을 줄일 수 있습니다. 프록시를 구성할 때 다음을 수행합니다.

  • Glance 이미지는 프록시 역할을 하는 단일 컴퓨팅 노드에 다운로드됩니다.
  • 프록시는 glance 이미지를 인벤토리의 다른 Compute 노드에 재배포합니다.

nova_cache_args.yml ansible 인수 파일에 다음 매개 변수를 배치하여 프록시 노드를 구성할 수 있습니다.

이미지 캐시 프록시를 활성화하려면 tripleo_nova_image_cache_use_proxy 매개변수를 true 로 설정합니다.

이미지 프록시는 보안 copy scp 를 사용하여 인벤토리의 다른 노드에 이미지를 배포합니다. SCP는 DCN 사이트 간의 WAN과 같이 대기 시간이 높은 네트워크보다 비효율적입니다. 플레이북 대상을 단일 DCN 위치로 제한하는 것이 좋습니다.

tripleo_nova_image_cache_proxy_hostname 매개변수를 사용하여 이미지 캐시 프록시를 선택합니다. 기본 프록시는 ansible 인벤토리 파일의 첫 번째 compute 노드입니다. tripleo_nova_image_cache_plan 매개변수를 사용하여 플레이북 인벤토리를 단일 사이트로 제한합니다.

tripleo_nova_image_cache_use_proxy: true
tripleo_nova_image_cache_proxy_hostname: dcn0-novacompute-1
tripleo_nova_image_cache_plan: dcn0

10.4. nova-cache 정리 구성

백그라운드 프로세스는 주기적으로 실행되어 다음 두 조건이 모두 true인 경우 nova 캐시에서 이미지를 제거합니다.

  • 이 이미지는 인스턴스에서 사용하지 않습니다.
  • 이미지 사용 기간은 nova 매개변수 remove_unused_original_minimum_age_seconds 의 값보다 큽니다.

remove_unused_original_minimum_age_seconds 매개변수의 기본값은 86400 입니다. 이 값은 초 단위로 표현되며 24시간과 동일합니다. 초기 배포 중에 NovaImageCachTTL tripleo-heat-templates 매개변수 또는 클라우드 스택 업데이트 중에 이 값을 제어할 수 있습니다.

parameter_defaults:
  NovaImageCacheTTL: 604800 # Default to 7 days for all compute roles
  Compute2Parameters:
    NovaImageCacheTTL: 1209600 # Override to 14 days for the Compute2 compute role

Compute 노드에 이미 존재하는 이미지를 사전 캐시하도록 플레이북에 지시하면 ansible에서 변경 사항을 보고하지 않지만 이미지 사용 기간이 0으로 재설정됩니다. NovaImageCacheTTL 매개변수 값보다 자주 ansible 플레이를 실행하여 이미지 캐시를 유지 관리합니다.

11장. TLS-e for DCN

주의

이 기능의 내용은 이번 릴리스에서 문서 프리뷰 로 제공되므로 Red Hat에서 완전히 확인하지 않습니다. 테스트 용도로만 사용하며 프로덕션 환경에서 사용하지 마십시오.

분산 컴퓨팅 노드 인프라용으로 설계된 클라우드에서 TLS(전송 계층 보안)를 활성화할 수 있습니다. 공용 액세스에만 TLS를 활성화하거나 TLS-e를 사용하여 모든 네트워크에서 TLS를 활성화하면 모든 내부 및 외부 데이터 흐름에서 암호화를 허용하는 옵션이 있습니다.

에지 사이트에 공용 엔드포인트가 없으므로 에지 스택에서 공용 액세스를 활성화할 수 없습니다. 공용 액세스를 위한 TLS에 대한 자세한 내용은 Overcloud Public Endpoints에서 SSL/TLS 활성화를 참조하십시오.

11.1. TLS-e를 사용하여 분산 계산 노드 아키텍처 배포

사전 요구 사항

RHOSP(Red Hat OpenStack Platform) 분산 계산 노드 아키텍처에서 Red Hat IdM(Identity Manager)을 사용하여 TLS-e를 구성하는 경우 Red Hat Identity Manager용으로 배포된 Red Hat Enterprise Linux 버전에 따라 다음 작업을 수행합니다.

Red Hat Enterprise Linux 8.4
  1. Red Hat Identity Management 노드에서 ipa-ext.conf 파일의 ACL에 신뢰할 수 있는 서브넷이 허용되었습니다.
 acl "trusted_network" {
   localnets;
   localhost;
   192.168.24.0/24;
   192.168.25.0/24;
 };
  1. /etc/named/ipa-options-ext.conf 파일에서 재귀를 허용하고 캐시를 쿼리하십시오.

    allow-recursion { trusted_network; };
    allow-query-cache { trusted_network; };
  2. 'named-pkcs11 서비스를 다시 시작하십시오.

    systemctl restart named-pkcs11
Red Hat Enterprise Linux 8.2
RHEL(Red Hat Enterprise Linux) 8.2에 IdM(Red Hat Identity Manager)이 있는 경우 Red Hat Enterprise Linux를 업그레이드한 다음 RHEL 8.4에 대한 지침을 따라야 합니다.
Red Hat Enterprise Linux 7.x
RHEL(Red Hat Enterprise Linux) 7.x에 IdM(Red Hat Identity Manager)이 있는 경우 도메인 이름에 대한 ACI(액세스 제어 명령)를 수동으로 추가해야 합니다. 예를 들어 도메인 이름이 redhat.local 인 경우 Red Hat Identity Manager에서 다음 명령을 실행하여 ACI를 구성합니다.
ADMIN_PASSWORD=redhat_01
DOMAIN_LEVEL_1=local
DOMAIN_LEVEL_2=redhat

cat << EOF | ldapmodify -x -D "cn=Directory Manager" -w ${ADMIN_PASSWORD}
dn: cn=dns,dc=${DOMAIN_LEVEL_2},dc=${DOMAIN_LEVEL_1}
changetype: modify
add: aci
aci: (targetattr = "aaaarecord || arecord || cnamerecord || idnsname || objectclass || ptrrecord")(targetfilter = "(&(objectclass=idnsrecord)(|(aaaarecord=)(arecord=)(cnamerecord=)(ptrrecord=)(idnsZoneActive=TRUE)))")(version 3.0; acl "Allow hosts to read DNS A/AAA/CNAME/PTR records"; allow (read,search,compare) userdn = "ldap:///fqdn=*,cn=computers,cn=accounts,dc=${DOMAIN_LEVEL_2},dc=${DOMAIN_LEVEL_1}";)
EOF

절차

DCN(Distributed Compute node) 아키텍처의 경우 이전 novajoin 방법과 달리 TLS-e를 구현하는 ansible 기반 tripleo-ipa 방법을 사용해야 합니다. tripleo-ipa 와 함께 TLS-e를 배포하는 방법에 대한 자세한 내용은 I ECDHE TLS-e with Ansible을 참조하십시오.

DCN 아키텍처의 tripleo-ipa 를 사용하여 TLS-e를 배포하려면 다음 단계도 완료해야 합니다.

  1. 에지에서 스토리지를 배포하는 경우 에지 스택의 수정된 tripleo heat 템플릿에 다음 매개변수를 포함합니다.

    TEMPLATES=/usr/share/openstack-tripleo-heat-templates
    
    resource_registry:
      OS::TripleO::Services::IpaClient:
        ${TEMPLATES}/deployment/ipa/ipaservices-baremetal-ansible.yaml

중앙 위치와 에지 위치 간의 설계 차이로 인해 에지 스택에 다음 파일이 포함되어 있지 않습니다.

tls-everywhere-endpoints-dns.yaml
이 파일은 에지 사이트에서 무시되며, 설정한 끝점은 중앙 스택에서 내보낸 끝점에 의해 재정의됩니다.
haproxy-public-tls-certmonger.yaml
이 파일은 에지에 공용 엔드포인트가 없으므로 배포에 실패했습니다.

12장. 외부 액세스를 위한 Ceph 키 생성

주의

이 기능의 내용은 이번 릴리스에서 문서 프리뷰 로 제공되므로 Red Hat에서 완전히 확인하지 않습니다. 테스트 용도로만 사용하며 프로덕션 환경에서 사용하지 마십시오.

Ceph 스토리지에 대한 외부 액세스는 로컬이 아닌 사이트에서 Ceph에 액세스할 수 있습니다. 에지의 Ceph 스토리지가 중앙 위치 외부에 있는 것처럼, 센티컬 위치의 Ceph 스토리지는 에지(DCN) 사이트에 대한 외부입니다.

Ceph 스토리지를 사용하여 중앙 또는 DCN 사이트를 배포할 때 로컬 및 외부 액세스에 기본 openstack 인증 키를 사용하는 옵션이 있습니다. 또는 로컬이 아닌 사이트에서 액세스할 수 있는 별도의 키를 생성할 수 있습니다.

외부 사이트에 액세스하기 위해 추가 Ceph 키를 사용하려면 각 키의 이름이 동일해야 합니다. 키 이름은 다음 예제의 외부 입니다.

로컬이 아닌 사이트를 통한 액세스를 위해 별도의 키를 사용하는 경우 로컬 액세스를 중단하지 않고 보안 이벤트에 대한 응답으로 외부 키를 삭제하고 다시 실행할 수 있는 추가 보안 이점이 있습니다. 그러나 외부 액세스를 위해 별도의 키를 사용하면 교차 가용성 영역 백업 및 오프라인 볼륨 마이그레이션과 같은 일부 기능에 대한 액세스가 손실됩니다. 원하는 기능 세트와 보안 유지의 요구 사항을 균형을 조정해야 합니다.

기본적으로 중앙 및 모든 DCN 사이트의 키가 공유됩니다.

12.1. 외부 액세스를 위한 Ceph 키 생성

로컬이 아닌 액세스에 사용할 외부 키를 생성하려면 다음 단계를 완료합니다.

process

  1. 외부 액세스를 위한 Ceph 키를 만듭니다. 이 키는 민감합니다. 다음을 사용하여 키를 생성할 수 있습니다.

    python3 -c 'import os,struct,time,base64; key = os.urandom(16) ; \
    header = struct.pack("<hiih", 1, int(time.time()), 0, len(key)) ; \
    print(base64.b64encode(header + key).decode())'
  2. 배포 중인 스택의 디렉터리에서 키에 대해 이전 명령의 출력을 사용하여 다음과 같은 내용이 포함된 ceph_keys.yaml 환경 파일을 생성합니다.

    parameter_defaults:
      CephExtraKeys:
        - name: "client.external"
          caps:
            mgr: "allow *"
            mon: "profile rbd"
            osd: "profile rbd pool=vms, profile rbd pool=volumes, profile rbd pool=images"
          key: "AQD29WteAAAAABAAphgOjFD7nyjdYe8Lz0mQ5Q=="
          mode: "0600"
  3. 사이트 배포에 ceph_keys.yaml 환경 파일을 포함합니다. 예를 들어 ceph_keys.yaml 환경 파일을 사용하여 중앙 사이트를 배포하려면 다음과 같은 명령을 실행합니다.

     overcloud deploy \
             --stack central \
             --templates /usr/share/openstack-tripleo-heat-templates/ \
             ….
             -e ~/central/ceph_keys.yaml

12.2. 외부 Ceph 키 사용

이미 배포된 키만 사용할 수 있습니다. 외부 키를 사용하여 사이트 배포에 대한 자세한 내용은 12.1절. “외부 액세스를 위한 Ceph 키 생성” 을 참조하십시오. 이 작업은 중앙 사이트와 에지 사이트에 모두 수행해야 합니다.

  • 중앙에서 제공하는 외부 키를 사용할 에지 사이트를 배포하는 경우 다음을 완료합니다.

    1. 에지 사이트에 대한 dcn_ceph_external.yaml 환경 파일을 만듭니다. 포함할 배포된 키를 지정하려면 RuntimeClass-key-client-name 옵션을 포함해야 합니다.

      sudo -E openstack overcloud export ceph \
      --stack central \
      --cephx-key-client-name external \
      --output-file ~/dcn-common/dcn_ceph_external.yaml
    2. 에지 사이트에서 중앙 사이트의 Ceph 클러스터에 액세스할 수 있도록 dcn_ceph_external.yaml 파일을 포함합니다. ceph_keys.yaml 파일을 포함하여 에지 사이트에 Ceph 클러스터에 대한 외부 키를 배포합니다.
  • 에지 사이트를 배포한 후 중앙 위치를 업데이트할 때 dcn 외부 키를 사용할 중앙 위치를 확인합니다.

    1. CephClientUserName 매개변수가 내보낼 키와 일치하는지 확인합니다. 다음 예제에 표시된 대로 외부 이름을 사용하는 경우 다음과 유사한 glance_update.yaml 을 생성합니다.

        parameter_defaults:
          GlanceEnabledImportMethods: web-download,copy-image
          GlanceBackend: rbd
          GlanceStoreDescription: 'central rbd glance store'
          CephClusterName: central
          GlanceBackendID: central
          GlanceMultistoreConfig:
          dcn0:
             GlanceBackend: rbd
            GlanceStoreDescription: 'dcn0 rbd glance store'
            CephClientUserName: 'external'
            CephClusterName: dcn0
            GlanceBackendID: dcn0
          dcn1:
            GlanceBackend: rbd
            GlanceStoreDescription: 'dcn1 rbd glance store'
            CephClientUserName: 'external'
            CephClusterName: dcn1
            GlanceBackendID: dcn1
    2. openstack overcloud export ceph 명령을 사용하여 중앙 위치에서 DCN 에지 액세스의 외부 키를 포함합니다. 이 작업을 수행하려면 --stack 인수에 대해 쉼표로 구분된 스택 목록을 제공하고 RuntimeClass -key-client-name 옵션을 포함해야 합니다.

      sudo -E openstack overcloud export ceph \
      --stack dcn0,dcn1,dcn2 \
      --cephx-key-client-name external \
      --output-file ~/central/dcn_ceph_external.yaml
    3. 원래 템플릿을 사용하여 중앙 사이트를 다시 배포하고 새로 생성된 dcn_ceph_external.yamlglance_update.yaml 파일을 포함합니다.

      openstack overcloud deploy \
             --stack central \
             --templates /usr/share/openstack-tripleo-heat-templates/ \
             -r ~/central/central_roles.yaml \
          ...
             -e /usr/share/openstack-tripleo-heat-templates/environments/cephadm/cephadm.yaml \
             -e /usr/share/openstack-tripleo-heat-templates/environments/nova-az-config.yaml \
             -e ~/central/central-images-env.yaml \
             -e ~/central/role-counts.yaml \
             -e ~/central/site-name.yaml
             -e ~/central/ceph.yaml \
             -e ~/central/ceph_keys.yaml \
             -e ~/central/glance.yaml \
             -e ~/central/dcn_ceph_external.yaml

부록 A. 배포 마이그레이션 옵션

이 섹션에는 DCN 스토리지의 관련 유효성 검사와 아키텍처 마이그레이션 또는 변경이 포함됩니다.

A.1. 에지 스토리지 검증

glance 다중 저장소 및 인스턴스 생성을 테스트하여 중앙 및 에지 사이트의 배포가 작동하는지 확인합니다.

로컬 파일 시스템에서 또는 웹 서버에서 사용할 수 있는 이미지를 Glance로 가져올 수 있습니다.

참고

중앙 위치에 이미지를 사용하는 인스턴스가 없는 경우에도 항상 중앙 사이트에 이미지 사본을 저장합니다.

사전 요구 사항

  1. glance stores-info 명령을 사용하여 이미지 서비스를 통해 사용할 수 있는 저장소를 확인합니다. 다음 예에서는 central, dcn1, dcn2의 세 가지 저장소를 사용할 수 있습니다. 이는 각각 중앙 위치 및 에지 사이트에 있는 Glance 저장소에 해당합니다.

      $ glance stores-info
      +----------+----------------------------------------------------------------------------------+
      | Property | Value                                                                            |
      +----------+----------------------------------------------------------------------------------+
      | stores   | [{"default": "true", "id": "central", "description": "central rbd glance         |
      |          | store"}, {"id": "dcn0", "description": "dcn0 rbd glance store"},                 |
      |          | {"id": "dcn1", "description": "dcn1 rbd glance store"}]                          |
      +----------+----------------------------------------------------------------------------------+

A.1.1. 로컬 파일에서 가져오기

먼저 이미지를 중앙 위치의 저장소에 업로드한 다음 이미지를 원격 사이트에 복사해야 합니다.

  1. 이미지 파일이 RAW 형식이어야 합니다. 이미지가 원시 형식이 아닌 경우 이미지를 이미지 서비스로 가져오기 전에 해당 이미지를 변환해야 합니다.

    file cirros-0.5.1-x86_64-disk.img
    cirros-0.5.1-x86_64-disk.img: QEMU QCOW2 Image (v3), 117440512 bytes
    
    qemu-img convert -f qcow2 -O raw cirros-0.5.1-x86_64-disk.img cirros-0.5.1-x86_64-disk.raw
    Import the image into the default back end at the central site:
    glance image-create \
    --disk-format raw --container-format bare \
    --name cirros --file cirros-0.5.1-x86_64-disk.raw \
    --store central

A.1.2. 웹 서버에서 이미지 가져오기

이미지가 웹 서버에서 호스팅되는 경우 GlanceImageImportPlugins 매개변수를 사용하여 여러 저장소에 이미지를 업로드할 수 있습니다.

이 절차에서는 기본 이미지 변환 플러그인이 Glance에서 활성화되어 있다고 가정합니다. 이 기능은 QCOW2 파일 형식을 Ceph RBD에 가장 적합한 RAW 이미지로 자동 변환합니다. glance image-show ID | grep disk_format 를 실행하여 glance 이미지가 RAW 형식으로 되어 있는지 확인할 수 있습니다.

절차

  1. glance 명령의 image-create-via-import 매개 변수를 사용하여 웹 서버에서 이미지를 가져옵니다. --stores 매개변수를 사용합니다.

    # glance image-create-via-import \
    --disk-format qcow2 \
    --container-format bare \
    --name cirros \
    --uri http://download.cirros-cloud.net/0.4.0/cirros-0.4.0-x86_64-disk.img \
    --import-method web-download \
    --stores central,dcn1

    이 예에서 qcow2 cirros 이미지는 공식 Cirros 사이트에서 다운로드되어 Glance에 의해 RAW로 변환되고 --stores 매개변수에 지정된 대로 중앙 사이트 및 에지 사이트 1로 가져옵니다.

또는 --stores--all-stores True 로 교체하여 모든 저장소에 이미지를 업로드할 수 있습니다.

A.1.3. 새 사이트에 이미지 복사

중앙 위치에서 에지 사이트로 기존 이미지를 복사하여 새로 설정된 위치에서 이전에 생성한 이미지에 액세스할 수 있습니다.

  1. 복사 작업에 glance 이미지의 UUID를 사용합니다.

    ID=$(openstack image show cirros -c id -f value)
    
    glance image-import $ID --stores dcn0,dcn1 --import-method copy-image
    참고

    이 예에서 --stores 옵션은 cirros 이미지가 중앙 사이트에서 에지 사이트 dcn1 및 dcn2로 복사되도록 지정합니다. 또는 현재 이미지가 없는 모든 저장소에 이미지를 업로드하는 --all-stores True 옵션을 사용할 수 있습니다.

  2. 각 저장소에 이미지 복사본이 있는지 확인합니다. properties 맵의 마지막 항목인 stores 키는 central,dcn0,dcn1 으로 설정됩니다.

      $ openstack image show $ID | grep properties
      | properties       | direct_url=rbd://d25504ce-459f-432d-b6fa-79854d786f2b/images/8083c7e7-32d8-4f7a-b1da-0ed7884f1076/snap, locations=[{u'url: u'rbd://d25504ce-459f-432d-b6fa-79854d786f2b/images/8083c7e7-32d8-4f7a-b1da-0ed7884f1076/snap', u'metadata': {u'store': u'central'}}, {u'url': u'rbd://0c10d6b5-a455-4c4d-bd53-8f2b9357c3c7/images/8083c7e7-32d8-4f7a-b1da-0ed7884f1076/snap', u'metadata': {u'store': u'dcn0'}}, {u'url': u'rbd://8649d6c3-dcb3-4aae-8c19-8c2fe5a853ac/images/8083c7e7-32d8-4f7a-b1da-0ed7884f1076/snap', u'metadata': {u'store': u'dcn1'}}], os_glance_failed_import=', os_glance_importing_to_stores=', os_hash_algo='sha512, os_hash_value=b795f047a1b10ba0b7c95b43b2a481a59289dc4cf2e49845e60b194a911819d3ada03767bbba4143b44c93fd7f66c96c5a621e28dff51d1196dae64974ce240e, os_hidden=False, stores=central,dcn0,dcn1 |
참고

해당 사이트에서 사용하는 VM이 없는 경우에도 항상 중앙 사이트에 이미지 사본을 저장합니다.

A.1.4. 에지 사이트의 인스턴스가 이미지 기반 볼륨으로 부팅될 수 있는지 확인

에지 사이트에서 이미지를 사용하여 영구 루트 볼륨을 생성할 수 있습니다.

절차

  1. 볼륨으로 생성할 이미지의 ID를 식별하고 해당 ID를 openstack volume create 명령에 전달합니다.

    IMG_ID=$(openstack image show cirros -c id -f value)
    openstack volume create --size 8 --availability-zone dcn0 pet-volume-dcn0 --image $IMG_ID
  2. 새로 생성된 볼륨의 볼륨 ID를 식별하고 openstack server create 명령에 전달합니다.

    VOL_ID=$(openstack volume show -f value -c id pet-volume-dcn0)
    openstack server create --flavor tiny --key-name dcn0-key --network dcn0-network --security-group basic --availability-zone dcn0 --volume $VOL_ID pet-server-dcn0
  3. dcn0 에지 사이트의 ceph-mon 컨테이너에서 rbd 명령을 실행하여 volumes 풀을 나열하여 볼륨이 이미지를 기반으로 하는지 확인할 수 있습니다.

    $ sudo podman exec ceph-mon-$HOSTNAME rbd --cluster dcn0 -p volumes ls -l
    NAME                                      SIZE  PARENT                                           FMT PROT LOCK
    volume-28c6fc32-047b-4306-ad2d-de2be02716b7 8 GiB images/8083c7e7-32d8-4f7a-b1da-0ed7884f1076@snap   2      excl
    $
  4. 인스턴스의 루트 볼륨의 cinder 스냅샷을 만들 수 있는지 확인합니다. 서버가 데이터를 정지하여 클린 스냅샷을 만들도록 중지되었는지 확인합니다. 인스턴스가 꺼지면 볼륨 상태가 in-use 상태로 유지되므로 --force 옵션을 사용합니다.

    openstack server stop pet-server-dcn0
    openstack volume snapshot create pet-volume-dcn0-snap --volume $VOL_ID --force
    openstack server start pet-server-dcn0
  5. dcn0 Ceph 클러스터의 volumes 풀 콘텐츠를 나열하여 새로 생성된 스냅샷을 표시합니다.

    $ sudo podman exec ceph-mon-$HOSTNAME rbd --cluster dcn0 -p volumes ls -l
    NAME                                                                                      SIZE  PARENT                                           FMT PROT LOCK
    volume-28c6fc32-047b-4306-ad2d-de2be02716b7                                               8 GiB images/8083c7e7-32d8-4f7a-b1da-0ed7884f1076@snap   2      excl
    volume-28c6fc32-047b-4306-ad2d-de2be02716b7@snapshot-a1ca8602-6819-45b4-a228-b4cd3e5adf60 8 GiB images/8083c7e7-32d8-4f7a-b1da-0ed7884f1076@snap   2 yes

A.1.5. 사이트 간에 이미지 스냅샷을 생성 및 복사할 수 있는지 확인

  1. dcn0 사이트에서 새 이미지를 만들 수 있는지 확인합니다. 새 스냅샷을 생성하려면 서버가 데이터를 정지하도록 중지되었는지 확인합니다.

    NOVA_ID=$(openstack server show pet-server-dcn0 -f value -c id)
    openstack server stop $NOVA_ID
    openstack server image create --name cirros-snapshot $NOVA_ID
    openstack server start $NOVA_ID
  2. dcn0 에지 사이트에서 다시 허브 위치에 이미지를 복사합니다. 이 위치는 Glance의 기본 백엔드입니다.

    IMAGE_ID=$(openstack image show cirros-snapshot -f value -c id)
    glance image-import $IMAGE_ID --stores central --import-method copy-image

glance multistore 작업에 대한 자세한 내용은 여러 저장소가 있는 이미지 서비스를 참조하십시오.

A.2. 스파인 및 리프 배포로 마이그레이션

기존 네트워크 구성이 있는 기존 클라우드를 스파인 리프 아키텍처가 있는 클라우드로 마이그레이션할 수 있습니다. 이를 위해서는 다음 조건이 필요합니다.

  • 모든 베어 메탈 포트에는 physical-network 속성 값이 ctlplane 로 설정되어야 합니다.
  • undercloud.conf에서 enable_routed_networks 매개변수 enable_routed_networks가 추가되어 언더클라우드 설치 명령인 openstack undercloud install.

언더클라우드가 다시 배포되면 오버클라우드는 단일 리프 0이 있는 스파인 리프 로 간주됩니다. 다음 단계를 통해 배포에 추가 프로비저닝을 추가할 수 있습니다.

  1. 언더클라우드에서 라우팅된 스파인-리프 구성과 같이 원하는 서브넷을 undercloud.conf에 추가합니다.
  2. 언더클라우드 설치 명령 openstack undercloud install 을 다시 실행합니다.
  3. 원하는 추가 네트워크 및 역할을 오버클라우드 템플릿, network_data.yamlroles_data.yaml 에 각각 추가합니다.

    참고

    네트워크 구성 파일에서 {{network.name}}InterfaceRoutes 매개변수를 사용하는 경우 NetworkDeploymentActions 매개변수에 값 UPDATE 가 포함되어 있는지 확인해야 합니다.

      NetworkDeploymentActions: ['CREATE','UPDATE'])
  4. 마지막으로 클라우드 배포에 관련된 모든 heat 템플릿을 포함하는 오버클라우드 설치 스크립트를 다시 실행합니다.

A.3. 다중 스택 배포로 마이그레이션

기존 배포를 중앙 사이트로 처리하고 에지 사이트를 추가로 추가하여 단일 스택 배포에서 다중 스택 배포로 마이그레이션할 수 있습니다.

이 릴리스에서 단일에서 다중 스택으로 마이그레이션하는 기능은 기술 프리뷰 이므로 Red Hat에서 완전히 지원되지 않습니다. 테스트 용도로만 사용해야 하며 프로덕션 환경에 배포해서는 안 됩니다. 기술 프리뷰 기능에 대한 자세한 내용은 적용 범위 상세 정보를 참조하십시오.

기존 스택을 분할할 수 없습니다. 필요한 경우 기존 스택을 축소하여 컴퓨팅 노드를 제거할 수 있습니다. 그런 다음 이러한 계산 노드를 에지 사이트에 추가할 수 있습니다.

참고

이 작업은 모든 컴퓨팅 노드가 제거되면 워크로드 중단을 생성합니다.

A.4. 에지 사이트에서 백업 및 복원

에지 사이트 및 가용성 영역의 DCN(Distributed Compute node) 아키텍처에서 Block Storage 서비스(cinder) 볼륨을 백업하고 복원할 수 있습니다. cinder-backup 서비스는 중앙 가용 영역(AZ)에서 실행되며 백업은 중앙 AZ에 저장됩니다. 블록 스토리지 서비스는 DCN 사이트에 백업을 저장하지 않습니다.

사전 요구 사항

  • 중앙 사이트는 /usr/share/openstack-tripleo-heat-templates/environments 에 있는 cinder-backup.yaml 환경 파일과 함께 배포됩니다. 자세한 내용은 Block Storage 백업 서비스 배포를 참조하십시오.
  • Block Storage 서비스(cinder) CLI를 사용할 수 있습니다.
  • 모든 사이트에서 공통의 openstack loadbalancing 클라이언트 이름을 사용해야 합니다. 자세한 내용은 외부 액세스를 위한 Ceph 키 생성 에서 참조하십시오.

절차

  1. 첫 번째 DCN 사이트에 볼륨 백업을 생성합니다.

    $ cinder --os-volume-api-version 3.51 backup-create --name <volume_backup> --availability-zone <az_central> <edge_volume>
    • <volume_backup> 을 볼륨 백업의 이름으로 바꿉니다.
    • <az_central>cinder-backup 서비스를 호스팅하는 중앙 가용 영역의 이름으로 바꿉니다.
    • <edge_volume> 을 백업할 볼륨의 이름으로 바꿉니다.

      참고

      Ceph 인증 키에 문제가 발생하면 cinder-backup 컨테이너를 다시 시작하여 호스트에서 컨테이너로의 인증 키를 복사해야 할 수 있습니다.

  2. 두 번째 DCN 사이트의 새 볼륨에 백업을 복원합니다.

    $ cinder --os-volume-api-version 3.51 create --availability-zone <az_2> --name <new_volume> --backup-id <volume_backup> <volume_size>
    • <az_2> 를 백업을 복원할 가용성 영역의 이름으로 바꿉니다.
    • <new_volume> 을 새 볼륨의 이름으로 바꿉니다.
    • <volume_backup> 을 이전 단계에서 생성한 볼륨 백업의 이름으로 바꿉니다.
    • <volume_size> 를 원래 볼륨의 크기보다 크거나 같은 GB의 값으로 바꿉니다.

법적 공지

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.