Red Hat Summit Red Hat Summit지원콘솔개발자평가판 시작연락처

7.4. 사전 프로비저닝된 노드를 사용하여 기본 오버클라우드 설정

사전 프로비저닝된 노드를 사용하여 RHOSP(Red Hat OpenStack Platform) 환경을 구성할 수 있습니다. 이 시나리오는 여러 방식에서 표준 오버클라우드 생성 시나리오와 다릅니다.

  • 외부 툴을 사용하여 노드를 프로비저닝하고 director가 오버클라우드 구성만 제어하도록 할 수 있습니다.
  • director 프로비저닝 방법에 의존하지 않고 노드를 사용할 수 있습니다. 이 시나리오는 전원 관리 제어 없이 오버클라우드를 생성하거나 DHCP/PXE 부팅 제한이 있는 네트워크를 사용하려는 경우에 유용합니다.
  • director에서 노드 관리에 OpenStack Compute(nova), OpenStack Bare Metal(ironic) 또는 OpenStack Image(glance)를 사용하지 않습니다.
  • 사전 프로비저닝된 노드에서는 QCOW2 overcloud-full 이미지를 사용하지 않는 사용자 지정 파티션 레이아웃을 사용할 수 있습니다.

이 시나리오에는 사용자 지정 기능이 없는 기본 설정만 포함됩니다.

사전 프로비저닝된 노드 확장에 대한 자세한 내용은 오버클라우드 노드 스케일링을 참조하십시오.

중요

사전 프로비저닝된 노드와 director 프로비저닝된 노드를 결합할 수 없습니다.

7.4.1. 사전 프로비저닝된 노드 요구 사항
링크 복사

사전 프로비저닝된 노드가 있는 오버클라우드 배포를 시작하기 전에 사용자 환경에 다음 구성이 있는지 확인합니다.

  • 4장. 언더클라우드에 director 설치에서 생성한 director 노드
  • 노드에 사용할 베어 메탈 시스템 세트. 필요한 노드 수는 생성하려는 오버클라우드 유형에 따라 다릅니다. 해당 머신은 각 노드 유형에 설정된 요구 사항을 준수해야 합니다. 이러한 노드에는 Red Hat Enterprise Linux 9.2를 호스트 운영 체제로 설치해야 합니다. 최신 버전을 사용하는 것이 좋습니다.
  • 사전 프로비저닝된 노드를 관리하기 위한 하나의 네트워크 연결. 이 시나리오를 수행하려면 오케스트레이션 에이전트 구성을 위해 노드에 SSH 액세스가 중단되지 않도록 해야 합니다.

  • 컨트롤 플레인 네트워크에 대한 하나의 네트워크 연결. 이 네트워크에는 두 가지 시나리오가 있습니다.

    • 프로비저닝 네트워크를 컨트롤 플레인으로 사용(기본 시나리오). 이 네트워크는 일반적으로 사전 프로비저닝된 노드에서 director로 연결되는 계층 3(L3) 라우팅 가능한 네트워크 연결입니다. 이 시나리오의 예에서는 다음 IP 주소 할당을 사용합니다.

      Expand
      표 7.11. 프로비저닝 네트워크 IP 할당
      노드 이름IP 주소

      director

      192.168.24.1

      Controller 0

      192.168.24.2

      Compute 0

      192.168.24.3

    • 별도 네트워크 사용. director의 프로비저닝 네트워크가 라우팅 불가능한 개인 네트워크인 경우, 서브넷에서 노드의 IP 주소를 정의하고 공용 API 엔드포인트를 통해 director와 통신할 수 있습니다. 이 시나리오의 요구 사항에 대한 자세한 내용은 7.4.6절. “사전 프로비저닝된 노드에 별도의 네트워크 사용”을 참조하십시오.
  • 이 예에 있는 다른 모든 네트워크 유형에서도 OpenStack 서비스에 컨트롤 플레인 네트워크를 사용합니다. 하지만 다른 네트워크 트래픽 유형에 대해 추가 네트워크를 생성할 수 있습니다.
  • 노드가 Pacemaker 리소스를 사용하는 경우 서비스 사용자 hacluster 및 서비스 그룹 haclient의 UID/GID는 189여야 합니다. 이는 CVE-2018-16877 때문입니다. Pacemaker를 운영 체제와 함께 설치한 경우 설치 시 이러한 ID가 자동으로 생성됩니다. ID 값을 잘못 설정한 경우에는 OpenStack minor update / fast-forward upgrade can fail on the controller nodes at pacemaker step with "Could not evaluate: backup_cib"의 절차에 따라 ID 값을 변경합니다.
  • 일부 서비스가 잘못된 IP 주소에 바인딩되고 배포 실패가 발생하지 않게 하려면 /etc/hosts 파일에 node-name=127.0.0.1 매핑이 포함되지 않도록합니다.

7.4.2. 사전 프로비저닝된 노드에서 사용자 생성
링크 복사

사전 프로비저닝된 노드를 사용하여 오버클라우드를 구성하는 경우 director는 오버클라우드 노드에 대한 SSH 액세스 권한이 필요합니다. 사전 프로비저닝된 각 노드에서 SSH 키 인증을 사용하여 사용자를 생성하고 해당 사용자의 암호 없이 sudo 액세스를 구성해야 합니다. 사전 프로비저닝된 노드에 사용자를 생성한 후 openstack overcloud deploy 명령과 함께 --overcloud-ssh-user 및 --overcloud-ssh-key 옵션을 사용하여 사전 프로비저닝된 노드가 있는 오버클라우드를 생성할 수 있습니다.

오버클라우드 SSH 사용자 및 오버클라우드 SSH 키의 기본값은 tripleo-admin 사용자 및 ~/.ssh/id_rsa 이므로 사전 프로비저닝된 각 노드에 tripleo-admin 이라는 사용자를 생성합니다. 다음 절차에서는 컨트롤러 노드에 tripleo-admin 사용자를 생성합니다. 오버클라우드에 추가할 사전 프로비저닝된 각 노드에 대해 절차를 반복합니다.

절차

  1. tripleo-admin 사용자를 생성하고 컨트롤러 노드에 암호를 설정합니다. 

    [root@controller-0 ~]# useradd tripleo-admin
[root@controller-0 ~]# passwd <password>
    • & lt;password >를 tripleo-admin 사용자의 암호로 바꿉니다.

  2. sudo 사용 시 이 사용자가 암호를 요구하지 않도록 합니다. 

    [root@controller-0 ~]# echo "tripleo-admin ALL=(root) NOPASSWD:ALL" | tee -a /etc/sudoers.d/tripleo-admin
[root@controller-0 ~]# chmod 0440 /etc/sudoers.d/tripleo-admin
  3. 컨트롤러 노드의 SSH 구성에 PasswordAuthentication Yes 를 설정합니다.

  4. director 노드에서 컨트롤러 노드로 tripleo-admin 사용자의 공용 SSH 키를 복사합니다. 

    [stack@director ~]$ ssh-copy-id tripleo-admin@192.168.24.2
  5. 컨트롤러 노드의 SSH 구성에 PasswordAuthentication No 를 설정합니다.
  6. 노드에 액세스할 때 SSH 키를 사용하여 인증할 수 있는지 확인합니다.

7.4.3. 사전 프로비저닝된 노드의 운영 체제 등록
링크 복사

각 노드는 Red Hat 서브스크립션에 액세스할 수 있어야 합니다. 노드를 Red Hat Content Delivery Network에 등록하려면 각 노드에서 다음 단계를 완료합니다. root 사용자로 또는 sudo 권한이 있는 사용자로 명령을 실행합니다.

중요

나열된 리포지토리만 활성화합니다. 추가 리포지토리를 사용하면 패키지와 소프트웨어가 충돌할 수 있습니다. 추가 리포지토리를 활성화하지 마십시오.

절차

  1. 등록 명령을 실행하고 메시지가 표시되면 고객 포털 사용자 이름과 암호를 입력합니다. 

    [root@controller-0 ~]# sudo subscription-manager register

  2. RHOSP(Red Hat OpenStack Platform) 17.1의 인타이틀먼트 풀을 찾습니다. 

    [root@controller-0 ~]# sudo subscription-manager list --available --all --matches="Red Hat OpenStack"

  3. 이전 단계에 있는 풀 ID를 사용하여 RHOSP 17.1 인타이틀먼트를 연결합니다. 

    [root@controller-0 ~]# sudo subscription-manager attach --pool=pool_id

  4. 모든 기본 리포지토리를 비활성화합니다. 

    [root@controller-0 ~]# sudo subscription-manager repos --disable=*

  5. 필요한 RHEL(Red Hat Enterprise Linux) 리포지토리를 활성화합니다. 

    [root@controller-0 ~]# sudo subscription-manager repos \
 --enable=rhel-9-for-x86_64-baseos-eus-rpms \
 --enable=rhel-9-for-x86_64-appstream-eus-rpms \
 --enable=rhel-9-for-x86_64-highavailability-eus-rpms \
 --enable=openstack-17.1-for-rhel-9-x86_64-rpms \
 --enable=fast-datapath-for-rhel-9-x86_64-rpms

  6. 오버클라우드에서 Red Hat Ceph Storage 노드를 사용하는 경우 관련 Red Hat Ceph Storage 리포지토리를 활성화합니다. 

    [root@cephstorage-0 ~]# sudo subscription-manager repos \
 --enable=rhel-9-for-x86_64-baseos-rpms \
 --enable=rhel-9-for-x86_64-appstream-rpms \
 --enable=openstack-deployment-tools-for-rhel-9-x86_64-rpms

  7. Red Hat Ceph Storage 노드를 제외한 모든 오버클라우드 노드에 RHEL 버전을 잠급니다. 

    [root@controller-0 ~]# subscription-manager release --set=9.2

  8. 시스템을 업데이트하여 기본 시스템 패키지를 최신 상태로 유지합니다. 

    [root@controller-0 ~]# sudo dnf update -y
[root@controller-0 ~]# sudo reboot

이제 노드에서 오버클라우드를 사용할 준비가 되었습니다.

7.4.4. director로의 SSL/TLS 액세스 설정
링크 복사

director가 SSL/TLS를 사용하는 경우 사전 프로비저닝된 노드에 director의 SSL/TLS 인증서에 서명하는 데 사용된 인증 기관 파일이 필요합니다. 고유한 인증 기관을 사용하는 경우 각 오버클라우드 노드에서 다음 작업을 수행합니다.

절차

  1. 인증 기관 파일을 사전 프로비저닝된 각 노드의 /etc/pki/ca-trust/source/anchors/ 디렉터리에 복사합니다.

  2. 각 오버클라우드 노드에서 다음 명령을 실행합니다. 

    [root@controller-0 ~]#  sudo update-ca-trust extract

이 단계를 수행하면 오버클라우드 노드에서 SSL/TLS를 통해 director의 공용 API에 액세스할 수 있습니다.

7.4.5. 컨트롤 플레인 네트워킹 구성
링크 복사

사전 프로비저닝된 오버클라우드 노드는 표준 HTTP 요청을 사용하여 director에서 메타데이터를 가져옵니다. 따라서 모든 오버클라우드 노드에 다음 중 하나에 대한 L3 액세스 권한이 필요합니다.

  • director의 컨트롤 플레인 네트워크. undercloud.conf 파일의 network_cidr 매개변수로 정의된 서브넷입니다. 오버클라우드 노드에는 이 서브넷에 대한 직접 액세스 권한이나 서브넷으로 라우팅 가능한 액세스 권한이 필요합니다.
  • director의 공용 API 엔드포인트. undercloud.conf 파일의 undercloud_public_host 매개변수로 지정합니다. 이 옵션은 컨트롤 플레인에 대한 L3 경로가 없거나, SSL/TLS 통신을 사용하려는 경우에 사용할 수 있습니다. 공용 API 엔드포인트를 사용하도록 오버클라우드 노드를 구성하는 방법에 대한 자세한 내용은 7.4.6절. “사전 프로비저닝된 노드에 별도의 네트워크 사용”을 참조하십시오.

director는 컨트롤 플레인 네트워크를 사용하여 표준 오버클라우드를 관리하고 설정합니다. 노드가 사전 프로비저닝된 오버클라우드의 경우 director와 사전 프로비저닝된 노드 간에 통신할 수 있도록 네트워크 구성을 일부 변경해야 할 수 있습니다.

네트워크 분리 사용

네트워크 분리를 사용하여 컨트롤 플레인을 비롯한 특정 네트워크를 사용하도록 서비스를 그룹화할 수 있습니다. 컨트롤 플레인에서 노드의 특정 IP 주소를 정의할 수도 있습니다.

참고

네트워크 분리를 사용하는 경우 NIC 템플릿에 언더클라우드 액세스에 사용된 NIC가 포함되지 않도록 합니다. 이러한 템플릿은 NIC를 재구성할 수 있으므로, 배포 중에 연결 및 설정 문제가 발생할 수 있습니다.

IP 주소 할당

네트워크 분리를 사용하지 않는 경우 단일 컨트롤 플레인 네트워크를 사용하여 모든 서비스를 관리할 수 있습니다. 이렇게 하려면 컨트롤 플레인 네트워크 범위 내에 있는 IP 주소를 사용하도록 각 노드에서 컨트롤 플레인 NIC를 수동으로 설정해야 합니다. director의 프로비저닝 네트워크를 컨트롤 플레인으로 사용하는 경우 선택한 오버클라우드 IP 주소가 프로비저닝(dhcp_start 및 dhcp_end)과 인트로스펙션 (inspection_iprange)에 대한 DHCP 범위를 벗어나는지 확인합니다.

표준 오버클라우드 생성 중에 director는 OpenStack Networking(neutron) 포트를 생성하고 프로비저닝/컨트롤 플레인 네트워크의 오버클라우드 노드에 IP 주소를 자동으로 할당합니다. 하지만 이로 인해 director에서 각 노드에 대해 수동으로 구성된 주소에 다른 IP 주소를 할당할 수 있습니다. 이 경우 예측 가능한 IP 주소 할당 방법을 사용하여 director에서 컨트롤 플레인에 사전 프로비저닝된 IP 할당을 사용하도록 강제 적용합니다.

네트워크 분리를 사용하는 경우 사용자 정의 환경 파일 deployed-ports.yaml 을 생성하여 예측 가능한 IP 전략을 구현합니다. 다음 예제 사용자 지정 환경 파일인 deployed-ports.yaml 은 리소스 레지스트리 매핑 및 매개변수 세트를 director에 전달하고 사전 프로비저닝된 노드의 IP 할당을 정의합니다. NodePortMap,ControlPlaneVipData 및 VipPortMap 매개변수는 각 오버클라우드 노드에 해당하는 IP 주소와 서브넷 CIDR을 정의합니다. 

resource_registry:
  # Deployed Virtual IP port resources
  OS::TripleO::Network::Ports::ExternalVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/deployed_vip_external.yaml
  OS::TripleO::Network::Ports::InternalApiVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/deployed_vip_internal_api.yaml
  OS::TripleO::Network::Ports::StorageVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/deployed_vip_storage.yaml
  OS::TripleO::Network::Ports::StorageMgmtVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/deployed_vip_storage_mgmt.yaml

  # Deployed ControlPlane port resource
  OS::TripleO::DeployedServer::ControlPlanePort: /usr/share/openstack-tripleo-heat-templates/deployed-server/deployed-neutron-port.yaml

  # Controller role port resources
  OS::TripleO::Controller::Ports::ExternalPort: /usr/share/openstack-tripleo-heat-templates/network/ports/deployed_external.yaml
  OS::TripleO::Controller::Ports::InternalApiPort: /usr/share/openstack-tripleo-heat-templates/network/ports/deployed_internal_api.yaml
  OS::TripleO::Controller::Ports::StorageMgmtPort: /usr/share/openstack-tripleo-heat-templates/network/ports/deployed_storage_mgmt.yaml
  OS::TripleO::Controller::Ports::StoragePort: /usr/share/openstack-tripleo-heat-templates/network/ports/deployed_storage.yaml
  OS::TripleO::Controller::Ports::TenantPort: /usr/share/openstack-tripleo-heat-templates/network/ports/deployed_tenant.yaml

  # Compute role port resources
  OS::TripleO::Compute::Ports::InternalApiPort: /usr/share/openstack-tripleo-heat-templates/network/ports/deployed_internal_api.yaml
  OS::TripleO::Compute::Ports::StoragePort: /usr/share/openstack-tripleo-heat-templates/network/ports/deployed_storage.yaml
  OS::TripleO::Compute::Ports::TenantPort: /usr/share/openstack-tripleo-heat-templates/network/ports/deployed_tenant.yaml

  # CephStorage role port resources
  OS::TripleO::CephStorage::Ports::StorageMgmtPort: /usr/share/openstack-tripleo-heat-templates/network/ports/deployed_storage_mgmt.yaml
  OS::TripleO::CephStorage::Ports::StoragePort: /usr/share/openstack-tripleo-heat-templates/network/ports/deployed_storage.yaml

parameter_defaults:
  NodePortMap:
1 

    # Controller node parameters
    controller-00-rack01:
2 

      ctlplane:
3 

        ip_address: 192.168.24.201
        ip_address_uri: 192.168.24.201
        ip_subnet: 192.168.24.0/24
      external:
        ip_address: 10.0.0.201
        ip_address_uri: 10.0.0.201
        ip_subnet: 10.0.0.10/24
      internal_api:
        ip_address: 172.16.2.201
        ip_address_uri: 172.16.2.201
        ip_subnet: 172.16.2.10/24
      management:
        ip_address: 192.168.1.201
        ip_address_uri: 192.168.1.201
        ip_subnet: 192.168.1.10/24
      storage:
        ip_address: 172.16.1.201
        ip_address_uri: 172.16.1.201
        ip_subnet: 172.16.1.10/24
      storage_mgmt:
        ip_address: 172.16.3.201
        ip_address_uri: 172.16.3.201
        ip_subnet: 172.16.3.10/24
      tenant:
        ip_address: 172.16.0.201
        ip_address_uri: 172.16.0.201
        ip_subnet: 172.16.0.10/24
    ...

    # Compute node parameters
    compute-00-rack01:
      ctlplane:
        ip_address: 192.168.24.11
        ip_address_uri: 192.168.24.11
        ip_subnet: 192.168.24.0/24
      internal_api:
        ip_address: 172.16.2.11
        ip_address_uri: 172.16.2.11
        ip_subnet: 172.16.2.10/24
      storage:
        ip_address: 172.16.1.11
        ip_address_uri: 172.16.1.11
        ip_subnet: 172.16.1.10/24
      tenant:
        ip_address: 172.16.0.11
        ip_address_uri: 172.16.0.11
        ip_subnet: 172.16.0.10/24
    ...

    # Ceph node parameters
    ceph-00-rack01:
      ctlplane:
        ip_address: 192.168.24.101
        ip_address_uri: 192.168.24.101
        ip_subnet: 192.168.24.0/24
      storage:
        ip_address: 172.16.1.101
        ip_address_uri: 172.16.1.101
        ip_subnet: 172.16.1.10/24
      storage_mgmt:
        ip_address: 172.16.3.101
        ip_address_uri: 172.16.3.101
        ip_subnet: 172.16.3.10/24
    ...

  # Virtual IP address parameters
  ControlPlaneVipData:
    fixed_ips:
    - ip_address: 192.168.24.5
    name: control_virtual_ip
    network:
      tags: [192.168.24.0/24]
      subnets:
      - ip_version: 4
  VipPortMap
    external:
      ip_address: 10.0.0.100
      ip_address_uri: 10.0.0.100
      ip_subnet: 10.0.0.100/24
    internal_api:
      ip_address: 172.16.2.100
      ip_address_uri: 172.16.2.100
      ip_subnet: 172.16.2.100/24
    storage:
      ip_address: 172.16.1.100
      ip_address_uri: 172.16.1.100
      ip_subnet: 172.16.1.100/24
    storage_mgmt:
      ip_address: 172.16.3.100
      ip_address_uri: 172.16.3.100
      ip_subnet: 172.16.3.100/24

  RedisVirtualFixedIPs:
    - ip_address: 192.168.24.6
        use_neutron: false
1
NodePortMap 매핑은 노드 할당의 이름을 정의합니다.
2
<node _hostname> 형식을 따르는 노드의 짧은 호스트 이름입니다.
3
노드의 네트워크 정의 및 IP 할당입니다. 네트워크에는 ctlplane,external,internal_api,management,storage _mgmt, tenant 가 포함됩니다. IP 할당에는 ip_address, ip_address_uri, ip_subnet:이 포함됩니다.
  • IPv4: ip_address 및 ip_address_uri 를 동일한 값으로 설정해야 합니다.

  • IPv6:

    • IP_AD DRESS : 대괄호 없이 IPv6 주소로 설정합니다.
    • ip_address_uri: 대괄호에 있는 IPv6 주소로 설정합니다(예: [2001:0db8:85a3:0000:0000:8a2e:0370:7334] ).

7.4.6. 사전 프로비저닝된 노드에 별도의 네트워크 사용
링크 복사

기본적으로 director는 프로비저닝 네트워크를 오버클라우드 컨트롤 플레인으로 사용합니다. 하지만 이 네트워크가 분리되어 라우팅이 불가능한 경우 구성 중에 노드에서 director 내부 API와 통신할 수 없습니다. 이 경우 노드에 대해 별도의 네트워크를 정의하고, 공용 API로 director와 통신하도록 구성해야 할 수 있습니다.

이 시나리오에는 다음과 같은 여러 요구 사항이 있습니다.

  • 오버클라우드 노드는 7.4.5절. “컨트롤 플레인 네트워킹 구성”의 기본 네트워크 설정을 수용해야 합니다.
  • director에서 공용 API 엔드포인트 사용에 대해 SSL/TLS를 활성화해야 합니다. 자세한 내용은 오버클라우드 공용 끝점에서 SSL/TLS 활성화를 참조하십시오.
  • director에 대해 FQDN(정규화된 도메인 이름)을 정의해야 합니다. 이 FQDN은 director의 라우팅 가능 IP 주소로 확인되어야 합니다. undercloud.conf 파일에서 undercloud_public_host 매개변수를 사용하여 이 FQDN을 설정합니다.

이 섹션의 예에서는 기본 시나리오와 다른 IP 주소 할당을 사용합니다.

Expand
표 7.12. 프로비저닝 네트워크 IP 할당
노드 이름IP 주소 또는 FQDN

director(내부 API)

192.168.24.1(프로비저닝 네트워크 및 컨트롤 플레인)

Director(공용 API)

10.1.1.1 / director.example.com

오버클라우드 가상 IP

192.168.100.1

Controller 0

192.168.100.2

Compute 0

192.168.100.3

다음 섹션에서는 오버클라우드 노드에 별도의 네트워크가 필요한 경우 추가 설정 방법을 설명합니다.

IP 주소 할당

IP 할당 방법은 7.4.5절. “컨트롤 플레인 네트워킹 구성”과 비슷합니다. 그러나 컨트롤 플레인은 배포된 서버에서 라우팅할 수 없으므로 NodePortMap,ControlPlaneVipData 및 VipPortMap 매개변수를 사용하여 컨트롤 플레인에 액세스할 가상 IP 주소를 포함하여 선택한 오버클라우드 노드 서브넷의 IP 주소를 할당할 수 있습니다. 다음 예제는 이 네트워크 아키텍처를 수용하는 7.4.5절. “컨트롤 플레인 네트워킹 구성” 의 deployed-ports.yaml 사용자 정의 환경 파일의 수정된 버전입니다. 

parameter_defaults:
  NodePortMap:
    controller-00-rack01
      ctlplane
        ip_address: 192.168.100.2
        ip_address_uri: 192.168.100.2
        ip_subnet: 192.168.100.0/24
...
    compute-00-rack01:
      ctlplane
        ip_address: 192.168.100.3
        ip_address_uri: 192.168.100.3
        ip_subnet: 192.168.100.0/24
...
  ControlPlaneVipData:
    fixed_ips:
    - ip_address: 192.168.100.1
    name: control_virtual_ip
    network:
      tags: [192.168.100.0/24]
    subnets:
    - ip_version: 4
  VipPortMap:
    external:
      ip_address: 10.0.0.100
      ip_address_uri: 10.0.0.100
      ip_subnet: 10.0.0.100/24
....
  RedisVirtualFixedIPs:
1 

    - ip_address: 192.168.100.10
      use_neutron: false
1
RedisVipPort 리소스는 network/ports/noop.yaml에 매핑됩니다. 이 매핑이 필요한 이유는 기본 Redis VIP 주소가 컨트롤 플레인에서 제공되기 때문입니다. 이 경우 noop를 사용하여 이 컨트롤 플레인 매핑을 비활성화합니다.

7.4.7. 사전 프로비저닝된 노드 호스트 이름 매핑
링크 복사

사전 프로비저닝된 노드를 구성할 때 ansible-playbook이 확인 가능한 호스트에 도달할 수 있도록 heat 기반 호스트 이름을 실제 호스트 이름에 매핑해야 합니다. HostnameMap을 사용하여 이러한 값을 매핑할 수 있습니다.

절차

  1. 환경 파일(예: hostname-map.yaml)을 생성하고 HostnameMap 매개변수와 호스트 이름 매핑을 추가합니다. 다음 구문을 사용합니다. 

    parameter_defaults:
  HostnameMap:
    [HEAT HOSTNAME]: [ACTUAL HOSTNAME]
    [HEAT HOSTNAME]: [ACTUAL HOSTNAME]

    [HEAT HOSTNAME]은 일반적으로 [STACK NAME]-[ROLE]-[INDEX] 의 표기법을 따릅니다. 

    parameter_defaults:
  HostnameMap:
    overcloud-controller-0: controller-00-rack01
    overcloud-controller-1: controller-01-rack02
    overcloud-controller-2: controller-02-rack03
    overcloud-novacompute-0: compute-00-rack01
    overcloud-novacompute-1: compute-01-rack01
    overcloud-novacompute-2: compute-02-rack01
  2. hostname-map.yaml 파일을 저장합니다.

7.4.8. 사전 프로비저닝된 노드에 대해 Ceph Storage 설정
링크 복사

이미 배포된 노드에 대해 Ceph를 설정하려면 언더클라우드 호스트에서 다음 단계를 완료합니다.

프로세스

  1. 언더클라우드 호스트에서 OVERCLOUD_HOSTS 환경 변수를 생성하고, Ceph 클라이언트로 사용하려는 오버클라우드 호스트 IP 주소의 공백으로 구분된 목록으로 변수를 설정합니다. 

    export OVERCLOUD_HOSTS="192.168.1.8 192.168.1.42"

  2. 기본 오버클라우드 계획 이름은 overcloud입니다. 다른 이름을 사용하는 경우 사용자 지정 이름을 저장할 환경 변수 OVERCLOUD_PLAN을 생성합니다. 

    export OVERCLOUD_PLAN="<custom-stack-name>"
    • <custom-stack-name>을 스택 이름으로 바꿉니다.

  3. enable-ssh-admin.sh 스크립트를 실행하여 Ansible이 Ceph 클라이언트를 설정하는 데 사용할 수 있는 오버클라우드 노드에 사용자를 설정합니다. 

    bash /usr/share/openstack-tripleo-heat-templates/deployed-server/scripts/enable-ssh-admin.sh

openstack overcloud deploy 명령을 실행하면 Ansible에서 OVERCLOUD_HOSTS 변수에 정의된 호스트를 Ceph 클라이언트로 설정합니다.

7.4.9. 사전 프로비저닝된 노드를 사용하여 오버클라우드 생성
링크 복사

오버클라우드 배포에서는 표준 CLI 방법을 사용합니다. 사전 프로비저닝된 노드의 경우 배포 명령에 코어 heat 템플릿 컬렉션의 일부 추가 옵션 및 환경 파일이 필요합니다.

  • --disable-validations - 사전 프로비저닝된 인프라에 사용되지 않는 서비스에 대한 기본 CLI 검증을 비활성화하려면 이 옵션을 사용합니다. 해당 검증을 비활성화하지 않으면 배포에 실패합니다.
  • environments/deployed-server-environment.yaml - 사전 프로비저닝된 인프라를 생성 및 구성하려면 이 환경 파일을 추가합니다. 이 환경 파일은 OS::Nova::Server 리소스를 OS::Heat::DeployedServer 리소스로 대체합니다.

다음은 사전 프로비저닝된 아키텍처와 관련된 환경 파일을 사용한 오버클라우드 배포 명령의 예입니다. 

$ source ~/stackrc
(undercloud)$ openstack overcloud deploy \
  --disable-validations \
  -e /usr/share/openstack-tripleo-heat-templates/environments/deployed-server-environment.yaml \
  -e /home/stack/templates/deployed-ports.yaml \
  -e /home/stack/templates/hostname-map.yaml \
  --overcloud-ssh-user stack \
  --overcloud-ssh-key ~/.ssh/id_rsa \
  <OTHER OPTIONS>

--overcloud-ssh-user 및 --overcloud-ssh-key 옵션은 구성 단계 중 각 오버클라우드 노드에 SSH 사용, 초기 tripleo-admin 사용자 생성 및 SSH 키를 /home/tripleo-admin/.ssh/authorized_keys에 삽입하는 데 사용됩니다. SSH 키를 삽입하려면 --overcloud-ssh-user 및 --overcloud-ssh-key(~/.ssh/id_rsa로 기본 설정됨)을 사용하여 초기 SSH 연결의 인증서를 지정합니다. --overcloud-ssh-key 옵션으로 지정하는 개인 키에 대한 노출을 제한하기 위해 director는 heat와 같은 API 서비스에 이 키를 전달하지 않으며 director openstack overcloud deploy 명령만 이 키를 사용하여 tripleo-admin 사용자의 액세스를 활성화합니다.

7.4.10. 오버클라우드 액세스
링크 복사

director는 언더클라우드에서 오버클라우드를 작동하는 데 필요한 인증 정보가 포함된 인증 정보 파일을 생성합니다. director는 이 overcloudrc 파일을 stack 사용자의 홈 디렉터리에 저장합니다.

프로세스

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

    (undercloud)$ source ~/overcloudrc

    명령 프롬프트가 변경되어 오버클라우드에 액세스 중임을 나타냅니다. 

    (overcloud)$

  2. 언더클라우드와 상호 작용으로 돌아가려면 stackrc 파일을 소싱합니다. 

    (overcloud)$ source ~/stackrc
(undercloud)$

    명령 프롬프트가 변경되어 언더클라우드에 액세스 중임을 나타냅니다. 

    (undercloud)$

7.4.11. 사전 프로비저닝된 오버클라우드 삭제
링크 복사

사전 프로비저닝된 노드를 사용하는 전체 오버클라우드를 삭제하려면 표준 오버클라우드 삭제 절차는 9.7절. “오버클라우드 스택 삭제” 에서 참조하십시오. 오버클라우드 삭제 후에 모든 노드의 전원을 끄고 기본 운영 체제 구성으로 다시 프로비저닝합니다.

참고

먼저 새로운 기본 운영 체제로 다시 프로비저닝하지 않고 오버클라우드에서 이전에 삭제된 노드를 재사용하지 마십시오. 삭제 프로세스는 오버클라우드 스택만 삭제하고 패키지를 제거하지는 않습니다.

Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

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

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2026 Red Hat맨 위로 이동