언더클라우드는 오버클라우드라는 최종 OpenStack Platform 환경의 구성, 설치, 관리를 제어하는 노드입니다. 언더클라우드 자체는 OpenStack Platform 구성 요소를 컨테이너 형태로 사용하여 Red Hat에서 OpenStack Platform director라는 툴셋을 만듭니다. 즉, 언더클라우드는 레지스트리 소스에서 컨테이너 이미지 세트를 가져와서 컨테이너 설정을 생성하고 각 OpenStack Platform 서비스를 컨테이너로 실행합니다. 결과적으로 언더클라우드에서는 오버클라우드를 만들고 관리하는 데 필요한 툴셋 역할을 하는 컨테이너화된 서비스 세트를 제공합니다.

언더클라우드와 오버클라우드 모두 컨테이너를 사용하므로, 동일한 아키텍처를 사용하여 컨테이너를 가져와서 설정 및 실행합니다. 이 아키텍처에서는 노드 프로비저닝에는 Heat라고도 하는 OpenStack Orchestration 서비스를, 서비스 및 컨테이너 구성에는 Ansible을 기반으로 합니다. 오류 발생시 문제 해결에 도움이 되므로 Heat 및 Ansible에 대한 내용을 어느 정도 숙지하고 있는 것이 좋습니다.

언더클라우드에서는 다음 두 개의 주요 네트워크에 액세스해야 합니다.

따라서 언더클라우드에 1Gbps 네트워크 인터페이스 카드가 2개 이상 있어야 합니다. 그러나 특히 오버클라우드 환경에서 다수의 노드를 프로비저닝하는 경우에는 프로비저닝 네트워크 트래픽에 대비해 10Gbps 인터페이스를 사용하는 것이 좋습니다.

다음 사항에 유의하십시오.

언더클라우드를 설치하기 전에 환경 규모를 결정하는 것이 좋습니다. 다음과 같은 요소를 계획해야 합니다.

언더클라우드에 필요한 최소 CPU 및 메모리 요구 사항은 다음과 같습니다.

다수의 작업자를 사용하려면 언더클라우드에 추가 vCPU 및 메모리가 필요합니다. 다음 권장 사항을 따르십시오.

언더클라우드 최소 권장 사양은 root 디스크의 사용 가능 디스크 공간 100GB입니다. 여기에는 다음이 포함됩니다.

언더클라우드를 설치 및 구성하려면 다음과 같은 리포지토리가 필요합니다.

Director를 설치하려면 다음이 필요합니다.

언더클라우드 설정에는 이미지를 가져올 위치와 저장 방법을 정의하기 위해 몇 가지 초기 레지스트리 구성이 필요합니다. 다음 프로세스에서는 컨테이너 이미지 준비를 위해 환경 파일을 생성하고 사용자 지정하는 방법을 보여줍니다.

컨테이너를 준비하는 데 필요한 기본 파일(containers-prepare-parameter.yaml)에는 ContainerImagePrepare Heat 매개 변수가 포함되어 있습니다. 이 매개 변수는 이미지 세트를 준비하기 위한 다양한 설정을 정의합니다.

parameter_defaults:
  ContainerImagePrepare:
  - (strategy one)
  - (strategy two)
  - (strategy three)
  ...

각각의 설정은 하위 매개 변수 집합에서 사용할 이미지와 해당 이미지의 사용 방법을 정의할 수 있습니다. 다음 표에는 각 ContainerImagePrepare 설정에 사용할 하위 매개 변수가 나열되어 있습니다.

set 매개 변수는 여러 key: value 정의를 설정할 수 있습니다. 다음 표에는 이러한 키가 나열되어 있습니다.

ContainerImagePrepare의 값은 YAML 목록입니다. 즉, 여러 항목을 지정할 수 있습니다. 다음 예에서는 두 개의 항목을 지정하는 경우를 설명합니다. 이 경우 director는 14.0-44로 태그가 지정된 버전을 사용하는 nova-api 이미지를 제외하고 모든 이미지의 최신 버전을 사용합니다.

ContainerImagePrepare:
- tag_from_label: "{version}-{release}"
  push_destination: true
  excludes:
  - nova-api
  set:
    namespace: registry.access.redhat.com/rhosp14
    name_prefix: openstack-
    name_suffix: ''
    tag: latest
- push_destination: true
  includes:
  - nova-api
  set:
    namespace: registry.access.redhat.com/rhosp14
    tag: 14.0-44

includes 및 excludes 항목은 각 항목에 대한 이미지를 필터링하는 방법을 제어합니다. includes 설정과 일치하는 이미지는 excludes 일치하는 이미지 항목보다 우선합니다. 일치하는 것으로 간주되기 위해서는 이미지 이름에 설정 값이 포함되어 있어야 합니다.

준비 과정에서 필요한 변경을 수행하기 위해 이미지를 수정한 다음 해당 변경 사항을 즉시 배포할 수 있습니다. 이미지 수정 사용 사례는 다음과 같습니다.

수정이 필요한 각 이미지에 대해 Ansible 역할을 호출하면 수정이 완료됩니다. 역할은 소스 이미지를 사용하고 요청된 변경을 수행한 다음 그 결과를 태그합니다. 그러면 준비 작업 시 이미지를 푸시하고 수정된 이미지를 참조하도록 Heat 매개 변수를 설정할 수 있습니다.

Ansible 역할 tripleo-modify-image는 요청된 역할 인터페이스를 준수하고, 수정 사용 사례에 필요한 작업을 수행합니다. 수정은 ContainerImagePrepare 매개 변수의 수정 관련 키를 통해 제어됩니다.

역할 tripleo-modify-image가 처리하는 다양한 사용 사례를 선택하려면 tasks_from 변수를 해당 역할에 필요한 파일에 설정합니다.

이미지를 수정하는 ContainerImagePrepare 항목을 개발하고 테스트하는 동안 자체적으로 준비를 실행하여 이미지가 예상대로 수정되는지 확인하는 것이 좋습니다.

sudo openstack tripleo container image prepare \
  -e ~/containers-prepare-parameter.yaml

다음 항목을 통해 이미지의 모든 패키지가 업데이트되지만 언더클라우드 호스트의 yum 리포지토리 설정을 사용하게 됩니다.

ContainerImagePrepare:
- push_destination: true
  ...
  modify_role: tripleo-modify-image
  modify_append_tag: "-updated"
  modify_vars:
    tasks_from: yum_update.yml
    compare_host_packages: true
    yum_repos_dir_path: /etc/yum.repos.d
  ...

핫픽스, 로컬 패키지 빌드 또는 패키지 리포지토리를 통해 사용할 수 없는 패키지를 설치하는 데 유용한 RPM 파일 디렉터리를 설치할 수 있습니다. 예를 들어 다음은 centos-binary-nova-compute 이미지에만 일부 핫픽스 패키지를 설치합니다.

ContainerImagePrepare:
- push_destination: true
  ...
  includes:
  - nova-compute
  modify_role: tripleo-modify-image
  modify_append_tag: "-hotfix"
  modify_vars:
    tasks_from: rpm_install.yml
    rpms_path: /home/stack/nova-hotfix-pkgs
  ...

유연성을 극대화하기 위해 Dockerfile이 포함된 디렉터리를 지정하여 필요한 변경을 수행할 수 있습니다. 역할을 호출하면 FROM 지시문을 변경하고 LABEL 지시문을 추가하는 Dockerfile.modified가 생성됩니다. 다음 예에서는 centos-binary-nova-compute 이미지에서 사용자 지정 Dockerfile을 실행합니다.

ContainerImagePrepare:
- push_destination: true
  ...
  includes:
  - nova-compute
  modify_role: tripleo-modify-image
  modify_append_tag: "-hotfix"
  modify_vars:
    tasks_from: modify_image.yml
    modify_dir_path: /home/stack/nova-custom
  ...

예를 들면 /home/stack/nova-custom/Dockerfile입니다. USER root 지시문을 실행한 후에는 원본 이미지의 기본 사용자로 다시 전환해야 합니다.

FROM docker.io/tripleomaster/centos-binary-nova-compute:latest

USER root

COPY customize.sh /tmp/
RUN /tmp/customize.sh

USER "nova"

Red Hat Satellite 6는 레지스트리 동기화 기능을 제공합니다. 이를 통해 여러 이미지를 Satellite 서버로 가져와 애플리케이션 라이프사이클의 일부로 관리할 수 있습니다. Satellite는 다른 컨테이너 활성화 시스템이 사용할 레지스트리 역할을 합니다. 컨테이너 이미지 관리에 대한 상세 정보는 Red Hat Satellite 6 콘텐츠 관리 가이드에서 "컨테이너 이미지 관리"를 참조하십시오.

이 절차의 예시에서 Red Hat Satellite 6 및 ACME라고 하는 예시 조직은 hammer 명령행 툴을 사용합니다. 이 조직을 실제로 사용하는 Satellite 6 조직으로 대체하십시오.

다음은 Satellite별 매개 변수가 포함된 환경 파일의 예입니다.

parameter_defaults:
  ContainerImagePrepare:
  - push_destination: true
    set:
      ceph_image: acme-production-myosp14-osp14_containers-rhceph-3-rhel7
      ceph_namespace: satellite.example.com:5000
      ceph_tag: latest
      name_prefix: acme-production-myosp14-osp14_containers-
      name_suffix: ''
      namespace: satellite.example.com:5000
      neutron_driver: null
      tag: latest
      ...
    tag_from_label: '{version}-{release}'

언더클라우드 및 오버클라우드를 모두 생성하는 경우 이 환경 파일을 사용하십시오.

director 설치 프로세스에는 네트워크 구성을 결정하는 특정 설정이 필요합니다. 이 설정은 stack 사용자의 홈 디렉터리에 있는 템플릿에 undercloud.conf로 저장되어 있습니다. 다음 절차에서는 기본 템플릿을 기반으로 사용하는 방법을 설정하는 방법에 대해 설명합니다.

undercloud.conf 파일을 구성하기 위한 매개 변수 목록은 다음과 같습니다.

[ctlplane-subnet]
cidr = 192.168.24.0/24
dhcp_start = 192.168.24.5
dhcp_end = 192.168.24.24
inspection_iprange = 192.168.24.100,192.168.24.120
gateway = 192.168.24.1
masquerade = true

환경에 따라 필요한 만큼의 프로비저닝 네트워크를 지정할 수 있습니다.

구성에 맞게 매개 변수에 대한 값을 변경합니다. 완료되면 파일을 저장하십시오.

다음 절차에 따라 director를 설치하고 몇 가지 기본적인 설치 후 작업을 수행합니다.

director 설치가 완료되었습니다. 이제 director의 명령행 툴을 사용할 수 있습니다.

director에는 오버클라우드 노드를 프로비저닝할 다음과 같은 여러 디스크 이미지가 필요합니다.

다음 절차는 오버클라우드 노드의 이미지를 확보 및 설치하는 방법에 대해 설명합니다.

오버클라우드에서 cdn.redhat.com과 같은 외부 호스트 이름을 확인하도록 하려면 오버클라우드 노드에 네임서버를 설정하는 것이 좋습니다. 네트워크를 분리하지 않은 표준 오버클라우드의 경우 언더클라우드의 컨트롤 플레인 서브넷을 사용하여 네임서버가 정의됩니다. 다음 절차에 따라 환경에 대한 네임서버를 정의하십시오.

이렇게 하면 director 구성 및 설치가 완료됩니다. 다음 장에서는 노드 등록, 검사 및 여러 노드 역할 태그 지정을 비롯하여 오버클라우드의 기본적인 구성에 대해 설명합니다.

director는 오버클라우드 빌드에 대한 여러 기본 노드 유형을 제공합니다. 이러한 노드 유형은 다음과 같습니다.

다음 표에서는 다른 오버클라우드 구성 예와 각 시나리오에 사용되는 노드 유형을 정의합니다.

또한 개별 서비스를 사용자 지정 역할로 나눌 것인지 검토하십시오. 구성 가능한 역할 아키텍처에 대한 자세한 내용은 Advanced Overcloud Customization 가이드에서 "Composable Services and Custom Roles"를 참조하십시오.

역할 및 서비스를 적절하게 매핑하여 서로 올바르게 통신할 수 있도록 해당 환경의 네트워킹 토폴로지와 서브넷을 계획하는 것이 중요합니다. Red Hat OpenStack Platform은 자율적으로 작동하고 소프트웨어 기반 네트워크, 정적 및 유동 IP 주소, DHCP를 관리하는 Openstack Networking(neutron) 서비스를 사용합니다.

기본적으로 director는 연결에 프로비저닝/컨트롤 플레인을 사용하도록 노드를 구성합니다. 그러나 사용자 지정하여 서비스를 할당할 수 있는 일련의 구성 가능한 네트워크로 네트워크 트래픽을 분리할 수 있습니다.

일반적인 Red Hat OpenStack Platform 설치에서는 종종 네트워크 유형의 수가 물리적 네트워크 연결 수를 초과합니다. 모든 네트워크를 적절한 호스트에 연결하기 위해 오버클라우드에서는 VLAN 태그를 사용하여 인터페이스마다 두 개 이상의 네트워크를 제공합니다. 대부분의 네트워크는 서브넷이 분리되어 있지만, 일부는 인터넷 액세스 또는 인프라 네트워크 연결에 라우팅을 제공할 레이어 3 게이트웨이가 필요합니다. VLAN을 사용하여 네트워크 트래픽 유형을 분리하는 경우 802.1Q 표준을 지원하는 스위치를 사용하여 태그가 지정된 VLAN을 제공하십시오.

또한 director는 분리된 구성 가능 네트워크를 사용하여 NIC를 구성하는 데 필요한 템플릿 집합을 제공합니다. 기본 구성은 다음과 같습니다.

고유의 템플릿을 작성하여 특정 NIC구성을 매핑할 수도 있습니다.

네트워크 구성을 검토하는 경우 다음과 같은 세부사항을 고려하는 것도 중요합니다.

director는 오버클라우드 환경에 여러 스토리지 옵션을 제공합니다. 이러한 옵션은 다음과 같습니다.

OpenStack Platform 구현의 보안은 네트워크 환경의 보안에 따라 좌우됩니다. 네트워킹 환경에서 적합한 보안 원칙에 따라 네트워크 액세스가 적절히 제어되는지 확인하십시오. 예를 들면 다음과 같습니다.

시스템 보안에 대한 자세한 내용은 다음 문서를 참조하십시오.

고가용성 오버클라우드를 배포하기 위해 director는 여러 개의 컨트롤러 노드, 컴퓨팅 노드, 스토리지 노드가 단일 클러스터로 작동하도록 설정합니다. 노드 오류가 발생하는 경우 해당 노드의 유형에 따라 자동 펜싱 및 다시 시작 프로세스가 트리거됩니다. 오버클라우드 고가용성 아키텍처 및 서비스에 대한 내용은 Understanding Red Hat OpenStack Platform High Availability를 참조하십시오.

director(인스턴스 HA)를 사용하여 컴퓨팅 인스턴스의 고가용성을 구성할 수도 있습니다. 이 메커니즘은 노드에 문제가 발생하는 경우 컴퓨팅 노드의 인스턴스를 자동으로 비우기 및 다시 시작합니다. 인스턴스 HA에 대한 요구 사항은 일반 오버클라우드 요구 사항과 동일하지만 몇 가지 추가 단계를 수행하여 배포를 위해 환경을 준비해야 합니다. 인스턴스 HA가 작동하는 방법 및 설치 지침에 대한 자세한 내용은 High Availability for Compute Instances 가이드를 참조하십시오.

컨트롤러 노드는 Red Hat OpenStack Platform 환경에서 Horizon 대시보드, 백엔드 데이터베이스 서버, Keystone 인증, 고가용성 서비스와 같은 핵심 서비스를 호스팅합니다.

Compute 노드는 가상 머신 인스턴스가 시작된 후 이를 실행하는 역할을 합니다. Compute 노드는 하드웨어 가상화를 지원해야 합니다. 또한 호스팅하는 가상 머신 인스턴스의 요구 사항을 지원하기에 충분한 메모리 및 디스크 공간이 있어야 합니다.

Ceph Storage 노드는 Red Hat OpenStack Platform 환경에 스토리지 오브젝트를 제공합니다.

Ceph Storage 클러스터를 통한 오버클라우드 설치에 대한 자세한 내용은 Deploying an Overcloud with Containerized Red Hat Ceph 가이드를 참조하십시오.

Object Storage 노드는 오버클라우드에 오브젝트 스토리지 계층을 제공합니다. Object Storage 프록시는 Controller 노드에 설치됩니다. 스토리지 계층에는 노드마다 여러 개의 디스크가 있는 베어 메탈 노드가 필요합니다.

언더클라우드를 설치 및 구성하려면 다음과 같은 리포지토리가 필요합니다.

director에는 수동으로 만든 노드 정의 템플릿이 있어야 합니다. 이 파일은 JSON 포맷 및 YAML 포맷을 사용하고, 노드의 하드웨어 및 전원 관리 세부 정보가 포함되어 있습니다.

director는 각 노드에서 인트로스펙션 프로세스를 실행할 수 있습니다. 이 프로세스를 실행하면 각 노드가 PXE를 통해 인트로스펙션 에이전트가 부팅됩니다. 이 에이전트는 노드에서 하드웨어 데이터를 수집하여 director에 다시 보냅니다. 그러면 director에서 이 인트로스펙션 데이터를 director에서 실행되는 OpenStack Object Storage(swift) 서비스에 저장합니다. director는 프로필 태그, 벤치마킹 및 root 디스크 수동 할당과 같은 여러 목적에 하드웨어 정보를 사용합니다.

각 노드의 하드웨어 등록 및 검사 후 특정 프로필에 노드를 태그합니다. 이러한 프로파일 태그는 노드가 플레이버에 일치된 다음 해당 플레이버가 배포 역할에 할당됩니다. 다음 예는 Controller 노드에 대한 역할, 플레이버, 프로파일 및 노드 사이의 관계를 보여줍니다.

기본 프로파일 플레이버 compute, control, swift-storage, ceph-storage, block-storage는 언더클라우드 설치 중에 생성되며, 대부분의 환경에서 변경 없이 사용할 수 있습니다.

기본 부팅 모드는 기존 BIOS 모드입니다. 최신 시스템에는 기존 BIOS 모드 대신 UEFI 부팅 모드가 필요할 수 있습니다. 다음 단계를 사용하여 UEFI 모드로 변경합니다.

일부 노드에서는 여러 디스크를 사용할 수 있습니다. 이러한 경우 director에서 프로비저닝 중에 root 디스크에 사용할 디스크를 확인해야 합니다. director가 프로비저닝 프로세스 중 root 디스크에 QCOW2 overcloud-full 이미지를 작성합니다.

director가 root 디스크를 쉽게 식별할 수 있도록 다음과 같은 속성을 사용할 수 있습니다.

이 예에서는 일련 번호를 사용하여 root 디바이스를 지정하는 방법을 보여줍니다.

다중 아키텍처 클라우드를 빌드하는 경우 모든 아키텍처별 역할을 roles_data.yaml에 추가해야 합니다. 다음 예에서는 기본 역할과 함께 ComputePPC64LE 역할을 포함합니다. 역할에 대한 내용은 Creating a Custom Role File 섹션을 참조하십시오.

openstack overcloud roles generate \
    --roles-path /usr/share/openstack-tripleo-heat-templates/roles -o ~/templates/roles_data.yaml \
    Controller Compute ComputePPC64LE BlockStorage ObjectStorage CephStorage

언더클라우드에는 오버클라우드 생성 플랜 기능을 하는 Heat 템플릿 세트가 포함되어 있습니다. 코어 Heat 템플릿 컬렉션의 매개 변수와 리소스를 덮어쓰는 YAML 포맷의 파일인 환경 파일을 사용하여 오버클라우드의 특정 부분을 사용자 지정할 수 있습니다. 필요한 만큼 많은 환경 파일을 추가할 수 있지만, 차후에 실행되는 환경 파일에 정의된 매개 변수와 리소스가 우선순위를 갖기 때문에 환경 파일의 순서가 중요합니다. 다음 목록을 환경 파일 순서의 예로 사용하십시오.

사용자 지정 환경 파일을 templates 디렉터리와 같은 별도의 디렉터리에 구성하는 것이 좋습니다.

Advanced Overcloud Customization 가이드를 사용하여 오버클라우드의 고급 기능을 사용자 지정할 수 있습니다.

다음의 몇 섹션에서는 오버클라우드에 필요한 환경을 만드는 방법에 대해 설명합니다.

기본적으로 director는 baremetal플레이버를 사용하여 컨트롤러 노드와 계산 노드 각 1개를 배포합니다. 그러나 이는 개념 검증을 위한 배포에만 적합합니다. 노드와 플레이버 수를 다르게 지정하여 기본 구성을 덮어쓸 수 있습니다. 소규모 프로덕션 환경의 경우 3개 이상의 컨트롤러 노드와 계산 노드 3개를 보유하고 특정 플레이버를 할당하여 노드를 적절한 리소스 사양으로 만들어야 하는 경우가 있을 수 있습니다. 다음 절차에서는 노드 수와 플레이버 할당을 저장하는 node-info.yaml이라는 환경 파일을 만드는 방법을 보여줍니다.

언더클라우드에서 TLS를 사용하고 CA가 공개적으로 신뢰되지 않는 경우 다음 절차를 따라야 합니다. 언더클라우드는 SSL 끝점 암호화에 대해 고유의 인증 기관(CA)을 운영합니다. 언더클라우드 끝점에서 나머지 배포에 액세스할 수 있도록 하려면 오버클라우드 노드가 언더클라우드 CA를 신뢰하도록 구성하십시오.

다음은 언더클라우드에서 사용할 수 있는 두 가지 유형의 사용자 지정 인증서입니다.

오버클라우드를 배포하는 동안 CA 인증서가 각 오버클라우드 노드에 복사되어 언더클라우드의 SSL 끝점에서 제공하는 암호화를 신뢰하게 됩니다. 환경 파일을 포함하는 방법에 대한 자세한 내용은 6.12절. “오버클라우드 배포에 환경 파일 포함”을 참조하십시오.

OpenStack 환경 생성의 최종 단계는 openstack overcloud deploy 명령을 실행하여 이 환경을 생성하는 것입니다. 이 명령을 실행하기 전에 주요 옵션 및 사용자 지정 환경 파일을 포함하는 방법을 숙지하고 있어야 합니다.

다음 표에는 openstack overcloud deploy 명령을 사용할 때의 추가 매개 변수가 나열되어 있습니다.

전체 옵션 목록을 표시하려면 다음 명령을 실행하십시오.

(undercloud) $ openstack help overcloud deploy

일부 명령행 매개 변수는 오래되거나 더 이상 사용되지 않으며, 대신 환경 파일의 parameter_defaults 섹션에 포함하는 Heat 템플릿 매개 변수가 사용됩니다. 다음 테이블에는 더 이상 사용되지 않는 매개 변수가 그에 상응하는 Heat 템플릿 매개 변수에 매핑되어 있습니다.

이러한 매개 변수는 Red Hat OpenStack Platform의 이후 버전에서 삭제될 예정입니다.

-e에 오버클라우드를 사용자 정의할 환경 파일이 포함되어 있습니다. 필요에 따라 환경 파일을 추가할 수 있지만, 나중에 실행되는 환경 파일에 정의된 매개 변수와 리소스가 우선 순위를 갖기 때문에 환경 파일의 순서가 중요합니다. 다음 목록은 환경 파일 순서의 예입니다.

-e 옵션을 사용하여 오버클라우드에 추가된 환경 파일은 오버클라우드 스택 정의의 일부가 됩니다.

다음 명령은 이 시나리오의 앞부분에서 정의한 환경 파일을 사용하여 오버클라우드 생성을 시작하는 방법에 대한 예입니다.

(undercloud) $ openstack overcloud deploy --templates \
  -e /home/stack/templates/node-info.yaml\
  -e /home/stack/templates/overcloud_images.yaml \
  -e /home/stack/inject-trust-anchor-hiera.yaml
  -r /home/stack/templates/roles_data.yaml \

이 명령에는 다음과 같은 추가 옵션을 사용할 수 있습니다.

director를 사용하려면 9장. 오버클라우드 생성 후 작업 수행에 재배포 및 배포 후 기능에 대한 이러한 환경 파일이 필요합니다. 이러한 파일이 포함되지 않은 경우 오버클라우드가 손상될 수 있습니다.

오버클라우드 설정을 나중에 수정하려는 경우 다음을 수행해야 합니다.

오버클라우드 설정을 직접 편집하지 마십시오. 오버클라우드 스택을 director로 업데이트할 때 수동 설정을 director의 설정이 덮어쓰기하므로 설정을 직접 편집하지 마십시오.

오버클라우드 배포 작업을 실행하기 전에 Heat 템플릿 및 환경 파일에서 오류를 확인합니다.

오버클라우드 생성이 완료되면 오버클라우드를 설정하기 위해 Ansible 플레이 개요가 director에서 제공됩니다.

PLAY RECAP *************************************************************
overcloud-compute-0     : ok=160  changed=67   unreachable=0    failed=0
overcloud-controller-0  : ok=210  changed=93   unreachable=0    failed=0
undercloud              : ok=10   changed=7    unreachable=0    failed=0

Tuesday 15 October 2018  18:30:57 +1000 (0:00:00.107) 1:06:37.514 ******
========================================================================

director는 또한 오버클라우드 액세스에 필요한 세부 정보도 제공합니다.

Ansible passed.
Overcloud configuration completed.
Overcloud Endpoint: http://192.168.24.113:5000
Overcloud Horizon Dashboard URL: http://192.168.24.113:80/dashboard
Overcloud rc file: /home/stack/overcloudrc
Overcloud Deployed

director에서는 director 호스트에서 오버클라우드와 상호 작용을 설정하고 인증을 지원하는 스크립트를 생성합니다. director는 overcloudrc 파일을 stack 사용자의 홈 director에 저장합니다. 이 파일을 사용하려면 다음 명령을 실행합니다.

(undercloud) $ source ~/overcloudrc

이 명령을 실행하면 director 호스트의 CLI에서 오버클라우드와 상호 작용하는 데 필요한 환경 변수가 로드됩니다. 명령 프롬프트에서 다음을 표시하도록 변경합니다.

(overcloud) $

director 호스트와의 상호 작용으로 돌아가려면 다음 명령을 실행합니다.

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

오버클라우드의 각 노드에는 heat-admin이라고 하는 사용자가 포함되어 있습니다. stack 사용자는 각 노드에 있는 이 사용자에 대해 SSH 액세스 권한을 갖습니다. SSH로 노드에 액세스하려면 원하는 노드의 IP 주소를 확인합니다.

(undercloud) $ openstack server list

다음으로 heat-admin 사용자와 노드의 IP 주소를 사용하여 노드에 연결합니다.

(undercloud) $ ssh heat-admin@192.168.24.23

이제 명령줄 툴을 사용한 오버클라우드 생성이 완료되었습니다. 생성 이후 기능에 대해서는 9장. 오버클라우드 생성 후 작업 수행을 참조하십시오.

사용자는 undercloud.conf 파일의 undercloud_public_host 매개 변수에 설정된 IP 주소를 SSL을 통해 director 웹 UI에 액세스할 수 있습니다. 예를 들어, 언더클라우드의 공용 IP 주소가 192.168.24.2인 경우 https://192.168.24.2에서 UI에 액세스할 수 있습니다.

웹 UI는 다음과 같은 필드가 있는 로그인 화면을 표시합니다.

UI에 로그인하면 UI에서 OpenStack Identity Public API에 액세스하고 다른 공용 API 서비스의 엔드포인트를 가져옵니다. 이러한 서비스에는 다음이 포함됩니다.

UI는 다음 세 가지 섹션으로 구성되어 있습니다.

검증 작업은 배포 시 특정 시점에서 자동으로 실행되지만 수동으로 실행할 수도 있습니다. 실행하려는 검증 작업의 재생 버튼을 클릭합니다. 각 검증 작업의 제목을 클릭하여 검증하거나 검증 제목을 클릭하여 자세한 정보를 표시합니다.

director UI에는 오버클라우드 구성 전 플랜(Plan)이 필요합니다. 이 Plan은 일반적으로 /usr/share/openstack-tripleo-heat-templates의 언더클라우드에 있는 것과 같은 Heat 템플릿 컬렉션입니다. 또한 하드웨어 및 환경 요구 사항에 맞게 플랜을 사용자 지정할 수 있습니다. 오버클라우드 사용자 지정에 대한 자세한 내용은 Advanced Overcloud Customization 가이드를 참조하십시오.

플랜에는 오버클라우드 설정에 대한 네 가지 주요 단계가 표시됩니다.

언더클라우드를 설치하고 구성하면 플랜이 자동으로 업로드됩니다. 여러 플랜을 웹 UI에 가져올 수도 있습니다. 플랜 화면에서 모든 플랜 breadcrumb를 클릭하면 현재 Plan 목록이 표시됩니다. 카드를 클릭하여 여러 플랜 간에 변경할 수 있습니다.

플랜 가져오기를 클릭하면 다음 정보를 묻는 창이 표시됩니다.

director의 Heat 템플릿 컬렉션을 클라이언트 머신에 복사해야 하는 경우 파일을 압축하여 복사합니다.

$ cd /usr/share/openstack-tripleo-heat-templates/
$ tar -cf ~/overcloud.tar *
$ scp ~/overcloud.tar user@10.0.0.55:~/.

한번 director UI가 플랜을 업로드하면 플랜이 플랜 목록에 표시되어 구성할 수 있습니다. 선택한 플랜 카드를 클릭합니다.

오버클라우드 구성의 첫 단계는 노드를 등록하는 것입니다. 다음을 통해 노드 등록 프로세스를 시작합니다.

이렇게 하면 노드 등록 창이 표시됩니다.

director에는 등록할 노드 목록이 필요하며 다음 두 가지 방법 중 하나를 사용하여 제공할 수 있습니다.

수동 등록을 위해 제공해야 하는 세부 사항은 다음과 같습니다.

노드 정보를 입력한 후 창 하단에 있는 노드 등록을 클릭합니다.

director가 노드를 등록합니다. 완료되면 UI를 사용하여 노드에서 인트로스펙션을 수행할 수 있습니다.

director UI에서 각 노드의 인트로스펙션 프로세스를 실행할 수도 있습니다. 이 프로세스를 실행하면 각 노드가 PXE로 인트로스펙션 에이전트를 부팅합니다. 이 에이전트는 노드에서 하드웨어 데이터를 수집하고 director에 다시 보냅니다. 그러면 director가 이 인트로스펙션 데이터를 director에서 실행 중인 OpenStack Object Storage(swift) 서비스에 저장합니다. director는 프로필 태그, 벤치마킹, 수동 루트 디스크 할당과 같은 다양한 목적으로 하드웨어 정보를 사용합니다.

인트로스펙션 프로세스를 시작하려면 다음 단계를 수행합니다:

인트로스펙션 프로세스가 완료되면 프로비저닝 상태가 manageable로 설정된 노드를 모두 선택한 다음 노드 제공 버튼을 클릭합니다. 프로비저닝 상태가available로 변경될 때까지 기다립니다.

이제 노드를 태그하고 프로비저닝할 준비가 되었습니다.

각 노드에 프로필 세트를 할당할 수 있습니다. 각 프로필은 해당 종류 및 역할에 해당합니다(자세한 내용은 6.3절. “프로필에 노드 태그” 참조).

Nodes 화면에는 노드 태그와 같은 추가 노드 관리 작업을 제공하는 토글 메뉴가 있습니다.

노드 세트 태그 방법:

플랜 화면에서는 업로드된 플랜을 사용자 지정할 수 있습니다. 2 배포 구성 지정에서 구성 편집 링크를 클릭하여 기본 오버클라우드 구성을 변경합니다.

다음 두 개의 기본 탭이 있는 창이 표시됩니다.

3 역할 설정 및 노드 할당 섹션의 오른쪽 하단에 역할 관리 아이콘이 있습니다.

이 아이콘을 클릭하면 환경에 추가할 수 있는 역할을 나타내는 카드가 표시됩니다. 역할을 추가하려면 역할의 오른쪽 상단에 있는 확인란을 선택하십시오.

역할을 선택한 후 변경사항 저장을 클릭합니다.

각 노드의 하드웨어 등록 및 검사 후 플랜의 역할에 할당합니다.

노드를 역할에 할당하려면 Plan 화면에서 3 역할 구성 및 노드 할당 섹션으로 스크롤합니다. 각 역할은 스피너 위젯을 사용하여 노드 개수를 역할에 할당합니다. 역할당 사용 가능한 노드는 7.6절. “웹 UI에서 프로필에 노드 태그”에서 태그된 노드를 기준으로 합니다.

각 역할에 대해 *Count 매개 변수가 변경됩니다. 예를 들어 컨트롤러 역할의 노드 개수를 3으로 변경하는 경우 ControllerCount 매개 변수를 3으로 설정합니다. 또한 배포 구성의 매개 변수 탭에서 개수 값을 보고 편집할 수도 있습니다. 자세한 정보는 7.7절. “웹 UI에서 오버클라우드 플랜 매개 변수 편집”를 참조하십시오.

각 노드 역할은 역할별 매개 변수를 구성하는 방식을 제공합니다. 플랜 화면에서 3 역할 구성 및 노드 할당 역할로 스크롤합니다. 역할 이름 옆에 있는 역할 매개 변수 편집 아이콘을 클릭합니다.

다음 두 가지 기본 탭이 표시된 창이 나타납니다.

다음 단계를 사용하여 오버클라우드 용 컨테이너 이미지를 준비하십시오.

오버클라우드 플랜이 설정되면 오버클라우드 배포를 시작할 수 있습니다. 이를 위해서는 6 배포 섹션으로 스크롤하여 검증 및 배포를 클릭합니다.

언더클라우드에 대한 모든 검증을 실행하지 않았거나 통과하지 않은 경우 경고 메시지가 표시됩니다. 배포를 실행하기 전에 언더클라우드 호스트가 요구 사항을 충족하는지 확인하십시오.

배포할 준비가 되었으면 배포를 클릭합니다.

UI에서는 오버클라우드의 생성 진행률을 정기적으로 모니터링하고 현재 진행률을 나타내는 진행률 표시줄을 표시합니다. 자세한 정보 보기 링크는 오버클라우드의 현재 OpenStack Orchestration 스택 로그를 표시합니다.

오버클라우드 배포가 완료될 때까지 기다립니다.

오버클라우드 생성 프로세스가 완료되면 4 배포 섹션에 현재 오버클라우드 상태 및 다음 세부 사항이 표시됩니다.

이 정보를 사용하여 오버클라우드에 액세스합니다.

이렇게 하면 director의 UI를 통한 오버클라우드 생성이 완료됩니다. 생성 후 기능에 대한 자세한 내용은 9장. 오버클라우드 생성 후 작업 수행을 참조하십시오.

이 프로세스의 후반 단계에서 director는 오버클라우드 노드에 stack 사용자로 SSH 액세스가 가능해야 합니다.

각 노드는 Red Hat 서브스크립션에 액세스할 수 있어야 합니다. 다음 절차는 각 노드를 Red Hat Content Delivery Network에 등록하는 방법을 보여줍니다. 각 노드에서 다음 단계를 수행하십시오.

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

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

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

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

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

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

예측 가능한 IP 주소 할당 방법의 예는 다음 IP가 할당된 환경 파일을 사용합니다(ctlplane-assignments.yaml).

resource_registry:
  OS::TripleO::DeployedServer::ControlPlanePort: /usr/share/openstack-tripleo-heat-templates/deployed-server/deployed-neutron-port.yaml

parameter_defaults:
  DeployedServerPortMap:
    controller-ctlplane:
      fixed_ips:
        - ip_address: 192.168.24.2
      subnets:
        - cidr: 24
    compute-ctlplane:
      fixed_ips:
        - ip_address: 192.168.24.3
      subnets:
        - cidr: 24

이 예에서 OS::TripleO::DeployedServer::ControlPlanePort 리소스는 매개변수 집합을 director에 전달하고, 사전 프로비저닝된 노드의 IP 할당을 정의합니다. DeployedServerPortMap 매개 변수는 각 오버클라우드 노드에 해당하는 IP 주소와 서브넷 CIDR을 정의합니다. 매핑은 다음을 정의합니다.

이 장의 후반 단계에서는 결과 환경 파일(ctlplane-assignments.yaml)을 openstack overcloud deploy 명령의 일부로 사용합니다.

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

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

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

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

resource_registry:
  OS::TripleO::DeployedServer::ControlPlanePort: /usr/share/openstack-tripleo-heat-templates/deployed-server/deployed-neutron-port.yaml
  OS::TripleO::Network::Ports::ControlPlaneVipPort: /usr/share/openstack-tripleo-heat-templates/deployed-server/deployed-neutron-port.yaml
  OS::TripleO::Network::Ports::RedisVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/noop.yaml 1

parameter_defaults:
  NeutronPublicInterface: eth1
  EC2MetadataIp: 192.168.100.1 2
  ControlPlaneDefaultRoute: 192.168.100.1
  DeployedServerPortMap:
    control_virtual_ip:
      fixed_ips:
        - ip_address: 192.168.100.1
      subnets:
        - cidr: 24
    controller0-ctlplane:
      fixed_ips:
        - ip_address: 192.168.100.2
      subnets:
        - cidr: 24
    compute0-ctlplane:
      fixed_ips:
        - ip_address: 192.168.100.3
      subnets:
        - cidr: 24

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

오버클라우드 배포에는 6.10절. “배포 명령”의 표준 CLI 메서드를 사용합니다. 사전 프로비저닝된 노드의 경우 배포 명령에 핵심 Heat 템플릿 컬렉션의 일부 추가 옵션 및 환경 파일이 필요합니다.

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

$ source ~/stackrc
(undercloud) $ openstack overcloud deploy \
  [other arguments] \
  --disable-validations \
  -e /usr/share/openstack-tripleo-heat-templates/environments/deployed-server-environment.yaml \
  -e /usr/share/openstack-tripleo-heat-templates/environments/deployed-server-bootstrap-environment-rhel.yaml \
  -e /usr/share/openstack-tripleo-heat-templates/environments/deployed-server-pacemaker-environment.yaml \
  -e /home/stack/templates/hostname-map.yaml /
  -r /usr/share/openstack-tripleo-heat-templates/deployed-server/deployed-server-roles-data.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 또는 Mistral과 같은 모든 API 서비스에 이 키를 전달하지 않으며 director의 openstack overcloud deploy 명령만 이 키를 사용하여 tripleo-admin 사용자에 대한 액세스를 활성화합니다.

오버클라우드 생성이 완료되면 오버클라우드를 설정하기 위해 Ansible 플레이 개요가 director에서 제공됩니다.

PLAY RECAP *************************************************************
overcloud-compute-0     : ok=160  changed=67   unreachable=0    failed=0
overcloud-controller-0  : ok=210  changed=93   unreachable=0    failed=0
undercloud              : ok=10   changed=7    unreachable=0    failed=0

Tuesday 15 October 2018  18:30:57 +1000 (0:00:00.107) 1:06:37.514 ******
========================================================================

director는 또한 오버클라우드 액세스에 필요한 세부 정보도 제공합니다.

Ansible passed.
Overcloud configuration completed.
Overcloud Endpoint: http://192.168.24.113:5000
Overcloud Horizon Dashboard URL: http://192.168.24.113:80/dashboard
Overcloud rc file: /home/stack/overcloudrc
Overcloud Deployed

director에서는 director 호스트에서 오버클라우드와 상호 작용을 설정하고 인증을 지원하는 스크립트를 생성합니다. director는 overcloudrc 파일을 stack 사용자의 홈 director에 저장합니다. 이 파일을 사용하려면 다음 명령을 실행합니다.

(undercloud) $ source ~/overcloudrc

이 명령을 실행하면 director 호스트의 CLI에서 오버클라우드와 상호 작용하는 데 필요한 환경 변수가 로드됩니다. 명령 프롬프트에서 다음을 표시하도록 변경합니다.

(overcloud) $

director 호스트와의 상호 작용으로 돌아가려면 다음 명령을 실행합니다.

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

사전 프로비저닝된 노드를 확장하는 프로세스는 11장. 오버클라우드 노드 확장의 표준 확장 절차와 비슷합니다. 하지만 사전 프로비저닝된 노드가 OpenStack Bare Metal(ironic) 및 OpenStack Compute(nova)의 표준 등록 및 관리 프로세스를 사용하지 않으므로 사전 프로비저닝된 새 노드를 추가하는 프로세스는 다릅니다.

사전 프로비저닝된 노드를 확장하는 일반 프로세스는 다음과 같습니다.

대부분의 확장 작업에서 노드의 UUID 값을 가져와 openstack overcloud node delete에 전달해야 합니다. 해당 UUID를 가져오기 위해 특정 역할에 대한 리소스를 나열합니다.

$ openstack stack resource list overcloud -c physical_resource_id -c stack_name -n5 --filter type=OS::TripleO::<RoleName>Server

위 명령에서 <RoleName>을 축소할 역할의 실제 이름으로 바꿉니다. 예를 들어 ComputeDeployedServer의 경우 다음과 같습니다.

$ openstack stack resource list overcloud -c physical_resource_id -c stack_name -n5 --filter type=OS::TripleO::ComputeDeployedServerServer

명령 출력에 있는 stack_name 열은 각 노드와 연결된 UUID를 확인하는 데 사용됩니다. 다음의 예제 출력에서와 같이 stack_name에는 Heat 리소스 그룹에 있는 노드의 인덱스 정수 값이 포함됩니다.

+------------------------------------+----------------------------------+
| physical_resource_id               | stack_name                       |
+------------------------------------+----------------------------------+
| 294d4e4d-66a6-4e4e-9a8b-           | overcloud-ComputeDeployedServer- |
| 03ec80beda41                       | no7yfgnh3z7e-1-ytfqdeclwvcg      |
| d8de016d-                          | overcloud-ComputeDeployedServer- |
| 8ff9-4f29-bc63-21884619abe5        | no7yfgnh3z7e-0-p4vb3meacxwn      |
| 8c59f7b1-2675-42a9-ae2c-           | overcloud-ComputeDeployedServer- |
| 2de4a066f2a9                       | no7yfgnh3z7e-2-mmmaayxqnf3o      |
+------------------------------------+----------------------------------+

stack_name 열의 인덱스 0, 1 또는 2는 Heat 리소스 그룹의 노드 순서에 해당합니다. physical_resource_id 열의 해당 UUID 값을 openstack overcloud node delete 명령에 전달하십시오.

스택에서 오버클라우드 노드를 제거한 경우 이러한 노드의 전원을 끕니다. 표준 배포의 director에 있는 베어 메탈 서비스에서 이 기능을 제어합니다. 하지만 프로비저닝된 노드를 사용하는 경우 이러한 노드를 수동으로 종료하거나 각 물리적 시스템에 대해 전원 관리 컨트롤을 사용해야 합니다. 스택에서 노드를 제거한 후 노드의 전원을 끄지 않으면 작동 상태로 남아 있어 오버클라우드 환경의 일부로 재연결될 수 있습니다.

제거된 노드의 전원을 끈 후 기본 운영 체제 구성으로 다시 프로비저닝하면 이후에 오버클라우드에 연결되지 않을 수 있습니다.

사전 프로비저닝된 노드를 사용하는 전체 오버클라우드를 제거하면 표준 오버클라우드와 같은 절차를 사용합니다. 자세한 내용은 9.14절. “오버클라우드 제거”를 참조하십시오.

오버클라우드 제거 후 모든 노드의 전원을 끄고 기본 운영 체제 구성으로 다시 프로비저닝합니다.

이렇게 하면 사전 프로비저닝된 노드를 사용한 오버클라우드 생성이 완료됩니다. 생성 이후 기능에 대해서는 9장. 오버클라우드 생성 후 작업 수행을 참조하십시오.

오버클라우드 배포 상태를 확인하려면 openstack overcloud status 명령을 사용합니다. 이 명령의 출력에는 모든 배포 단계의 결과가 표시됩니다.

OpenStack Platform은 언더클라우드 및 오버클라우드 노드의 컨테이너에서 서비스를 실행합니다. 특정 상황의 경우 호스트에서 개별 서비스를 제어해야 할 수 있습니다. 이 섹션에서는 노드에서 실행하여 컨테이너화된 서비스를 관리할 수 있는 몇 가지 일반적인 docker 명령을 제공합니다. 컨테이너를 관리할 수 있는 docker 사용에 대한 더 종합적인 정보는 컨테이너 시작하기 가이드에서 "Docker 포맷된 컨테이너 사용하기"를 참조하십시오.

$ sudo docker ps

중단되거나 실패한 컨테이너를 나열하려면 --all 옵션을 추가합니다.

$ sudo docker ps --all

컨테이너 이미지를 나열하려면 다음 명령을 실행합니다:

$ sudo docker images

$ sudo docker inspect keystone

$ sudo docker restart keystone

컨테이너화된 서비스를 중단하려면 docker restart 명령을 사용합니다. 예를 들어 keystone 컨테이너를 중단하는 방법은 다음과 같습니다.

$ sudo docker stop keystone

정지된 컨테이너화된 서비스를 시작하려면 docker restart 명령을 사용합니다. 예를 들어 keystone 컨테이너를 시작하는 방법은 다음과 같습니다.

$ sudo docker start keystone

$ sudo docker logs keystone

$ sudo docker exec -it keystone /bin/bash

root 사용자로 keystone 컨테이너 쉘에 들어가려면 다음 명령을 실행합니다.

$ sudo docker exec --user 0 -it <NAME OR ID> /bin/bash

컨테이너를 종료하려면 다음 명령을 실행합니다.

# exit

docker exec -ti -u swift swift_object_server swift-ring-builder /etc/swift/object.builder

해당 명령이 필요한 경우 다음 패키지를 언더클라우드에 stack 사용자로 설치하거나 오버클라우드에 heat-admin 사용자로 설치하십시오.

sudo yum install -y python-swift
sudo yum install -y python2-swiftclient

OpenStack Platform의 컨테이너화된 서비스 문제 해결에 대한 자세한 방법은 16.7.3절. “컨테이너화된 서비스 오류”를 참조하십시오.

오버클라우드에는 인스턴스에 대한 테넌트 네트워크가 필요합니다. overcloud를 소싱하고 Neutron에 초기 테넌트 네트워크를 생성합니다. 예를 들면 다음과 같습니다.

$ source ~/overcloudrc
(overcloud) $ openstack network create default
(overcloud) $ openstack subnet create default --network default --gateway 172.20.1.1 --subnet-range 172.20.0.0/16

이렇게 하면 default라고 하는 기본 Neutron 네트워크가 생성됩니다. 오버클라우드에서 내부 DHCP 메커니즘을 사용하여 이 네트워크에서 IP 주소를 자동으로 할당합니다.

생성된 네트워크를 확인합니다.

(overcloud) $ openstack network list
+-----------------------+-------------+--------------------------------------+
| id                    | name        | subnets                              |
+-----------------------+-------------+--------------------------------------+
| 95fadaa1-5dda-4777... | default     | 7e060813-35c5-462c-a56a-1c6f8f4f332f |
+-----------------------+-------------+--------------------------------------+

유동 IP 주소를 인스턴스에 할당할 수 있도록 오버클라우드에서 외부 네트워크를 생성해야 합니다.

overcloud를 소싱하여 Neutron에 외부 네트워크를 만듭니다. 예를 들면 다음과 같습니다.

$ source ~/overcloudrc
(overcloud) $ openstack network create public --external --provider-network-type flat --provider-physical-network datacentre
(overcloud) $ openstack subnet create public --network public --dhcp --allocation-pool start=10.1.1.51,end=10.1.1.250 --gateway 10.1.1.1 --subnet-range 10.1.1.0/24

이 예에서 public이라는 이름으로 네트워크를 생성합니다. 오버클라우드에는 기본 유동 IP 풀에 대해 이러한 특정 이름이 필요합니다. 이는 9.8절. “오버클라우드 검증”의 검증 테스트에서도 중요합니다.

또한 이 명령은 네트워크를 datacentre 물리적 네트워크에 매핑합니다. 기본적으로 datacentre는 br-ex 브리지에 매핑됩니다. 오버클라우드 생성 중에 사용자 정의 neutron 설정을 사용하지 않은 경우 이 옵션을 기본값으로 둡니다.

$ source ~/overcloudrc
(overcloud) $ openstack network create public --external --provider-network-type vlan --provider-physical-network datacentre --provider-segment 104
(overcloud) $ openstack subnet create public --network public --dhcp --allocation-pool start=10.1.1.51,end=10.1.1.250 --gateway 10.1.1.1 --subnet-range 10.1.1.0/24

provider:segmentation_id 값은 사용할 VLAN을 정의합니다. 이 경우 104를 사용할 수 있습니다.

생성된 네트워크를 확인합니다.

(overcloud) $ openstack network list
+-----------------------+-------------+--------------------------------------+
| id                    | name        | subnets                              |
+-----------------------+-------------+--------------------------------------+
| d474fe1f-222d-4e32... | public      | 01c5f621-1e0f-4b9d-9c30-7dc59592a52f |
+-----------------------+-------------+--------------------------------------+

다음 조건을 충족하면 유동 IP 네트워크에서 br-ex가 아닌 모든 브리지를 사용할 수 있습니다.

오버클라우드 생성 후 유동 IP 네트워크를 생성합니다.

$ source ~/overcloudrc
(overcloud) $ openstack network create ext-net --external --provider-physical-network floating --provider-network-type vlan --provider-segment 105
(overcloud) $ openstack subnet create ext-subnet --network ext-net --dhcp --allocation-pool start=10.1.2.51,end=10.1.2.250 --gateway 10.1.2.1 --subnet-range 10.1.2.0/24

공급자 네트워크는 배포된 오버클라우드 외부에 있는 네트워크에 물리적으로 연결된 네트워크입니다. 이 네트워크는 기존 인프라 네트워크이거나 유동 IP 대신 라우팅을 통해 인스턴스에 직접 외부 액세스를 제공하는 네트워크입니다.

공급자 네트워크를 생성할 때 브리지 매핑을 사용하는 물리적 네트워크와 연결합니다. 이는 유동 IP 네트워크 생성과 비슷합니다. Compute 노드가 VM 가상 네트워크 인터페이스를 연결된 네트워크 인터페이스에 직접 연결하므로, 공급자 네트워크를 Controller와 Compute 노드에 모두 추가합니다.

예를 들어 원하는 공급자 네트워크가 br-ex 브리지의 VLAN이면 다음 명령을 사용하여 VLAN 201의 공급자 네트워크를 추가합니다.

$ source ~/overcloudrc
(overcloud) $ openstack network create provider_network --provider-physical-network datacentre --provider-network-type vlan --provider-segment 201 --share

이 명령은 공유된 네트워크를 생성합니다. 또한 --share를 지정하지 않고 테넌트를 지정할 수 있습니다. 이 네트워크는 지정된 테넌트에서만 사용할 수 있습니다. 공급자 네트워크를 외부로 표시하는 경우 운영자만 해당 네트워크에 포트를 생성할 수 있습니다.

neutron에서 DHCP 서비스를 테넌트 인스턴스에 제공하도록 하려면 공급자 네트워크에 서브넷을 추가합니다.

(overcloud) $ openstack subnet create provider-subnet --network  provider_network --dhcp --allocation-pool start=10.9.101.50,end=10.9.101.100 --gateway 10.9.101.254 --subnet-range 10.9.101.0/24

다른 네트워크에서 공급자 네트워크를 통해 외부적으로 액세스해야 할 수 있습니다. 이 경우 다른 네트워크에서 공급자 네트워크를 통해 트래픽을 라우팅할 수 있도록 새 라우터를 생성합니다.

(overcloud) $ openstack router create external
(overcloud) $ openstack router set --external-gateway provider_network external

다른 네트워크를 이 라우터에 연결합니다. 예를 들어 subnet1이라는 서브넷이 있는 경우 다음 명령을 사용하여 해당 서브넷을 라우터에 연결할 수 있습니다.

(overcloud) $ openstack router add subnet external subnet1

이렇게 하면 subnet1이 라우팅 테이블에 추가되고, subnet1을 사용하는 트래픽이 공급자 네트워크로 라우팅됩니다.

이 가이드의 검증(Validation) 단계에서는 설치에 플레이버가 포함된 것으로 간주합니다. 플레이버를 하나 이상 생성하지 않은 경우, 다음 명령을 사용하여 다양한 스토리지 및 처리 기능이 있는 기본 플레이버 집합을 만드십시오.

$ openstack flavor create m1.tiny --ram 512 --disk 0 --vcpus 1
$ openstack flavor create m1.smaller --ram 1024 --disk 0 --vcpus 1
$ openstack flavor create m1.small --ram 2048 --disk 10 --vcpus 1
$ openstack flavor create m1.medium --ram 3072 --disk 10 --vcpus 2
$ openstack flavor create m1.large --ram 8192 --disk 10 --vcpus 4
$ openstack flavor create m1.xlarge --ram 8192 --disk 10 --vcpus 8

$ openstack flavor create --help는 openstack flavor create 명령 세부사항을 알아보는 데 사용됩니다.

오버클라우드는 일련의 통합 테스트를 수행할 OpenStack Integration Test Suite(tempest) 툴 설정을 사용합니다. 이 섹션에서는 통합 테스트 실행 준비에 대한 정보를 제공합니다. OpenStack Integration Test Suite 사용에 대한 전체 지침은 OpenStack Integration Test Suite 가이드를 참조하십시오.

$ source ~/stackrc
(undercloud) $ sudo ovs-vsctl add-port br-ctlplane vlan201 tag=201 -- set interface vlan201 type=internal
(undercloud) $ sudo ip l set dev vlan201 up; sudo ip addr add 172.16.0.201/24 dev vlan201

OpenStack Integration Test Suite를 실행하기 전에 오버클라우드에 heat_stack_owner 역할이 있는지 확인합니다.

$ source ~/overcloudrc
(overcloud) $ openstack role list
+----------------------------------+------------------+
| ID                               | Name             |
+----------------------------------+------------------+
| 6226a517204846d1a26d15aae1af208f | swiftoperator    |
| 7c7eb03955e545dd86bbfeb73692738b | heat_stack_owner |
+----------------------------------+------------------+

역할이 없는 경우 역할을 생성합니다.

(overcloud) $ openstack role create heat_stack_owner

$ source ~/stackrc
(undercloud) $ sudo ovs-vsctl del-port vlan201

다른 기능을 추가하도록 오버클라우드를 수정하거나 작동 방식을 변경할 수 있습니다. 오버클라우드를 수정하려면 사용자 정의 환경 파일 및 Heat 템플릿을 수정한 다음, 초기 오버클라우드 생성 시의 openstack overcloud deploy 명령을 다시 실행합니다. 예를 들어 6.10절. “배포 명령”을 사용하여 오버클라우드를 생성한 경우 다음 명령을 다시 실행합니다.

$ source ~/stackrc
(undercloud) $ openstack overcloud deploy --templates \
  -e ~/templates/node-info.yaml \
  -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
  -e ~/templates/network-environment.yaml \
  -e ~/templates/storage-environment.yaml \
  --ntp-server pool.ntp.org

director는 heat에서 overcloud 스택을 확인한 다음, 스택의 각 항목을 환경 파일 및 heat 템플릿으로 업데이트합니다. 그러면 오버클라우드가 다시 생성되지는 않지만, 기존 오버클라우드가 변경됩니다.

새 환경 파일을 포함하려면 해당 파일을 -e 옵션과 함께 openstack overcloud deploy 명령에 추가합니다. 예를 들면 다음과 같습니다.

$ source ~/stackrc
(undercloud) $ openstack overcloud deploy --templates \
  -e ~/templates/new-environment.yaml \
  -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
  -e ~/templates/network-environment.yaml \
  -e ~/templates/storage-environment.yaml \
  -e ~/templates/node-info.yaml \
  --ntp-server pool.ntp.org

이렇게 하면 환경 파일의 새 매개 변수와 리소스가 스택에 포함됩니다.

director에서는 OpenStack Platform 환경에서 Ansible 기반 자동화를 실행하는 기능을 제공합니다. director는 tripleo-ansible-inventory 명령을 사용하여 환경에 노드의 동적 인벤토리를 생성합니다.

기존 OpenStack 환경이 있으며 해당 가상 머신을 Red Hat OpenStack Platform 환경으로 마이그레이션하려는 경우 다음 절차를 사용하십시오.

실행 중인 서버의 스냅샷을 저장하여 새 이미지를 생성하고 해당 이미지를 다운로드합니다.

$ source ~/overcloudrc
(overcloud) $ openstack server image create instance_name --name image_name
(overcloud) $ openstack image save image_name --file exported_vm.qcow2

오버클라우드로 내보낸 이미지를 업로드하고 새 인스턴스를 실행합니다.

(overcloud) $ openstack image create imported_image --file exported_vm.qcow2 --disk-format qcow2 --container-format bare
(overcloud) $ openstack server create  imported_instance --key-name default --flavor m1.demo --image imported_image --nic net-id=net_id

상황에 따라 오버클라우드 Compute 노드에서 유지보수를 수행해야 할 수 있습니다. 다운 타임을 방지하려면 Compute 노드에서 VM을 오버클라우드의 다른 Compute 노드로 마이그레이션합니다.

director는 안전한 마이그레이션을 제공하기 위해 모든 계산 노드를 구성합니다. 모든 계산 노드에는 마이그레이션 프로세스 중 다른 계산 노드에 대한 액세스 권한을 각 호스트의 nova 사용자에게 제공하기 위해 공유 SSH 키가 있어야 합니다. director는 OS::TripleO::Services::NovaCompute 구성 가능한 서비스를 사용하여 이 키를 생성합니다. 구성 가능한 이 서비스는 기본적으로 모든 Compute 역할에 포함된 기본 서비스 중 하나입니다(Advanced Overcloud Customization의 "Composable Services and Custom Roles" 참조).

이렇게 하면 Compute 노드의 모든 인스턴스가 마이그레이션됩니다. 이제 인스턴스 중단 없이 노드에서 유지보수를 수행할 수 있습니다. Compute 노드를 활성화된 상태로 되돌리려면 다음 명령을 실행합니다.

$ source ~/overcloudrc
(overcloud) $ openstack compute service set [hostname] nova-compute --enable

heat stack-delete overcloud 명령 사용으로 오버클라우드가 실수로 제거되지 않도록 하기 위해 Heat에 특정 작업을 제한할 일련의 정책이 포함되어 있습니다. /etc/heat/policy.json을 편집하고 다음 매개 변수를 검색합니다.

"stacks:delete": "rule:deny_stack_user"

다음과 같이 변경합니다.

"stacks:delete": "rule:deny_everybody"

파일을 저장합니다.

이렇게 하면 오버클라우드가 heat 클라이언트와 함께 제거되지 않습니다. 오버클라우드 제거를 허용하려면 정책을 원래 값으로 되돌립니다.

원하는 경우 전체 오버클라우드를 제거할 수 있습니다.

기존 오버클라우드를 삭제합니다.

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

오버클라우드 삭제를 확인합니다.

(undercloud) $ openstack stack list

삭제에는 몇 분 정도 시간이 걸립니다.

제거가 완료되면 배포 시나리오의 표준 단계에 따라 오버클라우드를 다시 생성합니다.

Identity 서비스(keystone)는 다른 OpenStack 서비스에 대한 액세스 제어에 토큰 기반 시스템을 사용합니다. 일정한 기간이 지나면 데이터베이스에는 많은 양의 사용하지 않은 토큰이 누적됩니다. 기본 cron 작업은 매일 토큰 테이블을 플러시합니다. 환경을 모니터링하고 토큰 플러시 간격을 필요에 따라 조정하는 것이 좋습니다.

오버클라우드의 경우 KeystoneCronToken 값을 사용하여 간격을 조정할 수 있습니다. 자세한 내용은 Overcloud Parameters 가이드를 참조하십시오.

config-download 기능은 director가 오버클라우드를 구성하는 방식입니다. director는 OpenStack Orchestration(heat) 및 OpenStack Workflow 서비스(mistral)와 함께 config-download를 사용하여 소프트웨어 설정을 생성하고, 이를 각 오버클라우드 노드에 적용합니다. Heat도 SoftwareDeployment 리소스의 모든 배포 데이터를 작성하여 오버클라우드 설치 및 구성을 수행하지만, 해당 설정을 적용하지는 않습니다. Heat는 고유의 API를 통해서만 구성 데이터를 제공합니다. director가 스택을 생성하면 Mistral 워크플로우는 Heat API를 조회하여 설정 데이터를 가져오고 Ansible 플레이북 세트를 생성하여 이 Ansible 플레이북을 오버클라우드에 적용합니다.

결과적으로 openstack overcloud deploy 명령을 실행하면 다음 프로세스가 수행됩니다.

director는 config-download 프로세스를 위해 일련의 Ansible 플레이북을 생성합니다. 이러한 플레이북은 /var/lib/mistral/에 있는 작업 디렉터리에 저장됩니다. 이 디렉터리는 오버클라우드 이름을 따라 이름이 지정되며, 기본적으로 overcloud입니다.

작업 디렉터리에는 각 오버클라우드 역할의 이름이 붙은 여러개의 하위 디렉터리가 존재합니다. 이러한 하위 디렉터리에는 오버클라우드 역할의 노드 설정과 관련된 모든 작업이 포함됩니다. 또한 하위 디렉터리에는 각 특정 노드의 이름이 붙은 하위 디렉터리가 존재합니다. 해당 하위 디렉터리에는 오버클라우드 역할 작업에 적용할 노드별 변수가 포함됩니다. 그 결과 작업 디렉터리 내 오버클라우드 역할은 다음과 같이 구성됩니다.

─ /var/lib/mistral/overcloud
  |
  ├── Controller
  │   ├── overcloud-controller-0
  |   ├── overcloud-controller-1
  │   └── overcloud-controller-2
  ├── Compute
  │   ├── overcloud-compute-0
  |   ├── overcloud-compute-1
  │   └── overcloud-compute-2
  ...

각각의 작업 디렉터리는 배포 작업이 끝날 때마다 변경 사항을 기록하는 로컬 Git 리포지토리 역할도 수행합니다. 이를 통해 각 배포 간 설정 변경 사항을 추적할 수 있습니다.

OpenStack Workflow 서비스(mistral) 컨테이너의 mistral 사용자는 /var/lib/mistral/ 작업 디렉터리의 모든 파일을 소유합니다. 언더클라우드의 stack 사용자에게 이 디렉터리의 모든 파일에 대한 액세스 권한을 부여할 수 있습니다. 이 설정은 해당 디렉터리 내에서 특정 작업을 수행하는 데 유용합니다.

config-download 동안 Ansible에서 config-download 작업 디렉터리에 언더클라우드에 대한 로그 파일을 생성합니다.

/var/lib/mistral/overcloud의 작업 디렉터리에는 ansible-playbook과 직접 상호 작용하는 데 필요한 플레이북과 스크립트가 있습니다. 다음 절차는 이러한 파일과 상호 작용하는 방법에 대해 설명합니다.

config-download 작업 디렉터리는 로컬 Git 리포지토리 역할을 합니다. 배포 작업이 실행될 때마다 director는 관련 변경 사항이 있는 작업 디렉터리에 Git 커밋을 추가합니다. 그러면 Git 작업을 수행하여 여러 단계에서 배포 설정을 보고, 해당 설정을 다른 배포와 비교할 수 있습니다.

작업 디렉터리에는 제한 사항이 있습니다. 예를 들어 Git을 사용하여 config-download 작업 디렉터리를 이전 버전으로 되돌리면 해당 작업 디렉터리의 설정에만 영향을 미치고 다음 항목에는 영향을 미치지 않습니다.

다음 절차는 Git을 사용하여 config-download 작업 디렉터리의 다양한 커밋을 비교하는 방법을 설명합니다.

특정 환경에서는 표준 워크플로우 외부에서 자신의 config-download 파일을 생성해야 할 수 있습니다. 예를 들어 구성을 별도로 적용할 수 있도록 openstack overcloud deploy 명령에 --stack-only 옵션을 사용하여 오버클라우드 Heat 스택을 생성해야 할 수 있습니다. 다음 절차에서는 직접 자신의 config-download 파일을 만드는 방법을 보여줍니다.

그러면 수동으로 생성한 config-download 파일을 사용하여 설정을 수행하는 데 필요한 파일이 제공됩니다. 배포용 플레이북을 실행하려면 ansible-playbook 명령을 실행합니다.

$ ansible-playbook \
  -i inventory.yaml \
  --private-key ~/.ssh/id_rsa \
  --become \
  ~/config-download/deploy_steps_playbook.yaml

이 설정에서 overcloudrc 파일을 수동으로 생성하려면 다음 명령을 실행합니다.

$ openstack action execution run \
  --save-result \
  --run-sync \
  tripleo.deployment.overcloudrc \
  '{"container":"overcloud"}' \
  | jq -r '.["result"]["overcloudrc.v3"]' > overcloudrc.v3

다음은 config-download 작업 디렉터리에 있는 중요 최상위 파일입니다.

플레이북은 태그 작업을 사용하여 오버클라우드에 적용되는 작업을 제어합니다. 실행되는 작업을 제어하려면 태그를 ansible-playbook CLI 인수 --tags 또는 --skip-tags와 함께 사용하십시오. 사용 가능한 태그는 다음과 같습니다.

deploy_steps_playbook.yaml 플레이북은 오버클라우드를 설정하는 데 사용됩니다. 오버클라우드 배포 Plan에 따라 전체 오버클라우드를 배포하는 데 필요한 모든 소프트웨어 설정에 적용됩니다.

이 섹션에는 이 플레이북 내에서 사용되는 다양한 Ansible 재생의 개요에 대해 설명합니다. 이 섹션에 있는 재생 이름은 플레이북에서 사용되고 ansible-playbook 출력에 표시되는 이름과 같습니다. 다음과 같이 각 재생에 설정된 Ansible 태그도 아래에 표시됩니다.

이제 정기적인 오버클라우드 작업을 계속할 수 있습니다.

다음 단계를 완료하여 director 노드 풀에 노드를 추가합니다.

Compute 노드와 같은 특정 역할의 오버클라우드 노드를 확장하려면 다음 단계를 수행합니다.

오버클라우드에서 Compute 노드를 제거해야 하는 경우가 있을 수 있습니다. 예를 들면 문제가 있는 Compute 노드를 교체해야 할 수 있습니다.

이제 오버클라우드에서 노드를 제거하여 다른 용도로 노드를 다시 프로비저닝할 수 있습니다.

director를 사용하여 director에서 생성한 클러스터에 있는 Ceph Storage 노드를 교체할 수 있습니다. 해당 지침은 Deploying an Overcloud with Containerized Red Hat Ceph 가이드를 참조하십시오.

이 섹션에서는 클러스터를 원래 상태로 유지하면서 Object Storage 노드를 교체하는 방법에 대해 설명합니다. 다음 예에서는 두 개의 노드로 된 Object Storage 클러스터에서 overcloud-objectstorage-1 노드를 교체해야 합니다. 이 절차의 목표는 한 개의 노드를 추가한 다음 overcloud-objectstorage-1을 제거하여 노드를 효과적으로 교체하는 것입니다.

director가 오버클라우드에서 Object Storage 노드를 삭제하고 노드 제거를 적용하도록 오버클라우드에서 나머지 노드를 업데이트합니다.

업데이트된 배포를 수신하지 못하도록 오버클라우드 노드를 제외할 수 있습니다. 이는 코어 Heat 템플릿 컬렉션에서 업데이트된 매개 변수 및 리소스 세트를 수신하지 못하도록 기존 노드를 제외한 상태에서 새 노드를 확장하려는 시나리오에서 유용합니다. 즉, 블랙리스트로 지정된 노드는 stack 작업의 영향을 받지 않습니다.

환경 파일에서 DeploymentServerBlacklist 매개 변수를 사용하여 블랙리스트를 생성할 수 있습니다.

parameter_defaults:
  DeploymentServerBlacklist:
    - overcloud-compute-0
    - overcloud-compute-1
    - overcloud-compute-2

openstack overcloud deploy 명령을 사용하여 이 환경 파일을 추가합니다.

$ source ~/stackrc
(undercloud) $ openstack overcloud deploy --templates \
  -e server-blacklist.yaml \
  [OTHER OPTIONS]

Heats는 목록에서 업데이트된 Heat 배포를 수신하는 모든 서버를 블랙 리스트로 지정합니다. stack 작업이 완료되면 블랙리스트로 지정된 서버는 변경되지 않고 이전 상태로 유지됩니다. 또한 작업 중에 os-collect-config 에이전트의 전원을 끄거나 중단할 수 있습니다.

parameter_defaults:
  DeploymentServerBlacklist: []

오버클라우드 Controller 노드를 교체하기 전에 Red Hat OpenStack Platform 환경의 현재 상태를 확인하는 것이 중요합니다. 현재 상태를 확인하면 Controller 교체 프로세스 중에 복잡한 문제가 발생하는 것을 방지할 수 있습니다. 다음 사전 점검 목록을 사용하여 Controller 노드 교체를 수행하는 것이 안전한지 확인합니다. 언더클라우드에서 검사 명령을 모두 실행합니다.

스토리지 클러스터에서 ceph-mon 데몬을 제거하려면 이 절차를 따르십시오. 컨트롤러 노드가 Ceph monitor 서비스를 실행하는 경우 다음 단계를 따라 ceph-mon 데몬을 제거합니다. 이 절차에서는 컨트롤러에 도달할 수 있다고 가정합니다.

기존 노드를 교체하기 전에 Pacemaker가 더 이상 실행되지 않는지 확인한 후 Pacemaker 클러스터에서 해당 노드를 제거해야 합니다.

컨트롤러 노드를 교체하려면, 교체할 노드의 인덱스를 확인하십시오.

다음 명령을 수행하여 overcloud-controller-1 노드를 overcloud-controller-3 노드로 교체합니다. overcloud-controller-3 노드의 ID는 75b25e9a-948d-424a-9b3b-f0ef70a6eacf입니다.

컨트롤러 노드를 제거하고 새 컨트롤러 노드로 교체하려면 다음 단계를 수행합니다.

노드 교체를 완료한 후에는 다음 단계를 수행하여 컨트롤러 클러스터를 종료합니다.

다음 절차에 따라 언더클라우드 노드를 재부팅합니다.

다음 절차는 구성 가능한 역할을 기준으로 컨트롤러 노드 및 독립 실행형 노드를 재부팅합니다. 이렇게 하면 Compute 노드와 Ceph Storage 노드가 제외됩니다.

다음 절차에 따라 Ceph Storage(OSD) 노드 클러스터를 재부팅합니다.

다음 절차에 따라 compute 노드를 재부팅합니다. OpenStack Platform 환경에서 인스턴스 다운타임을 최소화할 수 있도록 이 절차에는 선택한 compute 노드에서 인스턴스를 마이그레이션하는 방법에 대한 지침도 포함되어 있습니다. 다음 워크플로우에 따라 실행합니다.

available 노드에서 하나의 인트로스펙션을 수행하려면 노드를 관리 모드로 설정하고 인트로스펙션을 실행합니다.

(undercloud) $ openstack baremetal node manage [NODE UUID]
(undercloud) $ openstack overcloud node introspect [NODE UUID] --provide

인트로스펙션이 완료되면 노드가 available 상태로 변경됩니다.

초기 인트로스펙션 이후 모든 노드는 --provide 옵션으로 인해 available 상태를 입력해야 합니다. 초기 인트로스펙션 이후 모든 노드에서 인트로스펙션을 수행하려면 모든 노드를 manageable 상태로 설정하고 일괄적으로 인트로스펙션 명령을 실행합니다.

(undercloud) $ for node in $(openstack baremetal node list --fields uuid -f value) ; do openstack baremetal node manage $node ; done
(undercloud) $ openstack overcloud node introspect --all-manageable --provide

인트로스펙션이 완료되면 모든 노드가 available 상태로 변경됩니다.

네트워크 인트로스펙션은 네트워크 스위치에서 LLDP(link layer discovery protocol) 데이터를 검색합니다. 다음 명령은 노드의 모든 인터페이스에 대한 LLDP 정보 서브셋이나 특정 노드 및 인터페이스에 대한 전체 정보를 표시합니다. 이는 문제 해결에 유용할 수 있습니다. 디렉터는 기본적으로 LLDP 데이터 수집을 활성화합니다.

노드에서 인터페이스 목록을 가져오려면 다음 명령을 실행합니다:

(undercloud) $ openstack baremetal introspection interface list [NODE UUID]

예:

(undercloud) $ openstack baremetal introspection interface list c89397b7-a326-41a0-907d-79f8b86c7cd9
+-----------+-------------------+------------------------+-------------------+----------------+
| Interface | MAC Address       | Switch Port VLAN IDs   | Switch Chassis ID | Switch Port ID |
+-----------+-------------------+------------------------+-------------------+----------------+
| p2p2      | 00:0a:f7:79:93:19 | [103, 102, 18, 20, 42] | 64:64:9b:31:12:00 | 510            |
| p2p1      | 00:0a:f7:79:93:18 | [101]                  | 64:64:9b:31:12:00 | 507            |
| em1       | c8:1f:66:c7:e8:2f | [162]                  | 08:81:f4:a6:b3:80 | 515            |
| em2       | c8:1f:66:c7:e8:30 | [182, 183]             | 08:81:f4:a6:b3:80 | 559            |
+-----------+-------------------+------------------------+-------------------+----------------+

인터페이스 데이터 및 스위치 포트 정보를 확인하려면 다음 명령을 실행합니다:

(undercloud) $ openstack baremetal introspection interface show [NODE UUID] [INTERFACE]

예:

(undercloud) $ openstack baremetal introspection interface show c89397b7-a326-41a0-907d-79f8b86c7cd9 p2p1
+--------------------------------------+------------------------------------------------------------------------------------------------------------------------+
| Field                                | Value                                                                                                                  |
+--------------------------------------+------------------------------------------------------------------------------------------------------------------------+
| interface                            | p2p1                                                                                                                   |
| mac                                  | 00:0a:f7:79:93:18                                                                                                      |
| node_ident                           | c89397b7-a326-41a0-907d-79f8b86c7cd9                                                                                   |
| switch_capabilities_enabled          | [u'Bridge', u'Router']                                                                                                 |
| switch_capabilities_support          | [u'Bridge', u'Router']                                                                                                 |
| switch_chassis_id                    | 64:64:9b:31:12:00                                                                                                      |
| switch_port_autonegotiation_enabled  | True                                                                                                                   |
| switch_port_autonegotiation_support  | True                                                                                                                   |
| switch_port_description              | ge-0/0/2.0                                                                                                             |
| switch_port_id                       | 507                                                                                                                    |
| switch_port_link_aggregation_enabled | False                                                                                                                  |
| switch_port_link_aggregation_id      | 0                                                                                                                      |
| switch_port_link_aggregation_support | True                                                                                                                   |
| switch_port_management_vlan_id       | None                                                                                                                   |
| switch_port_mau_type                 | Unknown                                                                                                                |
| switch_port_mtu                      | 1514                                                                                                                   |
| switch_port_physical_capabilities    | [u'1000BASE-T fdx', u'100BASE-TX fdx', u'100BASE-TX hdx', u'10BASE-T fdx', u'10BASE-T hdx', u'Asym and Sym PAUSE fdx'] |
| switch_port_protocol_vlan_enabled    | None                                                                                                                   |
| switch_port_protocol_vlan_ids        | None                                                                                                                   |
| switch_port_protocol_vlan_support    | None                                                                                                                   |
| switch_port_untagged_vlan_id         | 101                                                                                                                    |
| switch_port_vlan_ids                 | [101]                                                                                                                  |
| switch_port_vlans                    | [{u'name': u'RHOS13-PXE', u'id': 101}]                                                                                 |
| switch_protocol_identities           | None                                                                                                                   |
| switch_system_name                   | rhos-compute-node-sw1                                                                                                  |
+--------------------------------------+------------------------------------------------------------------------------------------------------------------------+

예를 들어 numa_topology 수집기는 이러한 하드웨어 검사의 추가 기능의 일부이며 각 NUMA 노드에 대해 다음 정보를 포함합니다.

openstack baremetal introspection data save _UUID_ | jq .numa_topology 명령을 사용하여 베어 메탈 노드의 UUID와 함께 이 정보를 검색합니다.

다음 예시는 베어 메탈 노드에 대해 검색된 NUMA 정보를 보여줍니다.

{
  "cpus": [
    {
      "cpu": 1,
      "thread_siblings": [
        1,
        17
      ],
      "numa_node": 0
    },
    {
      "cpu": 2,
      "thread_siblings": [
        10,
        26
      ],
      "numa_node": 1
    },
    {
      "cpu": 0,
      "thread_siblings": [
        0,
        16
      ],
      "numa_node": 0
    },
    {
      "cpu": 5,
      "thread_siblings": [
        13,
        29
      ],
      "numa_node": 1
    },
    {
      "cpu": 7,
      "thread_siblings": [
        15,
        31
      ],
      "numa_node": 1
    },
    {
      "cpu": 7,
      "thread_siblings": [
        7,
        23
      ],
      "numa_node": 0
    },
    {
      "cpu": 1,
      "thread_siblings": [
        9,
        25
      ],
      "numa_node": 1
    },
    {
      "cpu": 6,
      "thread_siblings": [
        6,
        22
      ],
      "numa_node": 0
    },
    {
      "cpu": 3,
      "thread_siblings": [
        11,
        27
      ],
      "numa_node": 1
    },
    {
      "cpu": 5,
      "thread_siblings": [
        5,
        21
      ],
      "numa_node": 0
    },
    {
      "cpu": 4,
      "thread_siblings": [
        12,
        28
      ],
      "numa_node": 1
    },
    {
      "cpu": 4,
      "thread_siblings": [
        4,
        20
      ],
      "numa_node": 0
    },
    {
      "cpu": 0,
      "thread_siblings": [
        8,
        24
      ],
      "numa_node": 1
    },
    {
      "cpu": 6,
      "thread_siblings": [
        14,
        30
      ],
      "numa_node": 1
    },
    {
      "cpu": 3,
      "thread_siblings": [
        3,
        19
      ],
      "numa_node": 0
    },
    {
      "cpu": 2,
      "thread_siblings": [
        2,
        18
      ],
      "numa_node": 0
    }
  ],
  "ram": [
    {
      "size_kb": 66980172,
      "numa_node": 0
    },
    {
      "size_kb": 67108864,
      "numa_node": 1
    }
  ],
  "nics": [
    {
      "name": "ens3f1",
      "numa_node": 1
    },
    {
      "name": "ens3f0",
      "numa_node": 1
    },
    {
      "name": "ens2f0",
      "numa_node": 0
    },
    {
      "name": "ens2f1",
      "numa_node": 0
    },
    {
      "name": "ens1f1",
      "numa_node": 0
    },
    {
      "name": "ens1f0",
      "numa_node": 0
    },
    {
      "name": "eno4",
      "numa_node": 0
    },
    {
      "name": "eno1",
      "numa_node": 0
    },
    {
      "name": "eno3",
      "numa_node": 0
    },
    {
      "name": "eno2",
      "numa_node": 0
    }
  ]
}

여러 가지가 혼합된 하드웨어 환경의 경우 인트로스펙션 규정을 사용하여 인증서 및 원격 관리 인증서를 할당할 수 있습니다. 예를 들어 별도의 검색 규칙으로 DRAC를 사용하는 Dell 노드를 처리할 수 있습니다.

노드 등록 문제는 일반적으로 잘못된 노드 세부 사항 문제로 인해 발생합니다. 이 경우 ironic을 사용하여 등록된 노드 데이터 문제를 해결합니다. 다음은 몇 가지 예입니다.

할당된 포트 UUID를 확인합니다:

$ source ~/stackrc
(undercloud) $ openstack baremetal port list --node [NODE UUID]

MAC 주소를 업데이트합니다:

(undercloud) $ openstack baremetal port set --address=[NEW MAC] [PORT UUID]

다음 명령을 실행합니다:

(undercloud) $ openstack baremetal node set --driver-info ipmi_address=[NEW IPMI ADDRESS] [NODE UUID]

인트로스펙션 프로세스 실행은 끝까지 완료되어야 합니다. 하지만 검색 램디스크가 응답하지 않을 경우 ironic의 검색 데몬(ironic-inspector)이 1시간(기본값) 후에 시간 초과됩니다. 경우에 따라 이는 검색 램디스크의 버그가 원인이 되는 경우도 있지만, 일반적으로는 BIOS 부팅 설정 등 잘못된 환경 구성으로 인해 설정 오류가 발생합니다.

다음은 잘못된 환경 구성이 발생하는 몇 가지 일반적인 시나리오 및 진단/해결 방법에 대한 설명입니다.

$ source ~/stackrc
(undercloud) $ openstack baremetal node manage [NODE UUID]

그런 다음 검색이 완료되면 프로비저닝 전에 다시 AVAILABLE로 변경합니다.

(undercloud) $ openstack baremetal node provide [NODE UUID]

$ source ~/stackrc
(undercloud) $ openstack baremetal introspection abort [NODE UUID]

프로세스가 시간 초과될 때까지 기다릴 수 있습니다. 필요한 경우 timeout 설정을 /etc/ironic-inspector/inspector.conf에서 다른 기간(분)으로 변경합니다.

$ sudo systemctl list-units openstack-swift*

OpenStack Workflow(mistral) 서비스는 여러 OpenStack 작업을 워크플로우에 그룹화합니다. Red Hat OpenStack Platform은 이러한 워크플로우 집합을 사용하여 CLI 및 웹 UI에 일반적인 기능을 수행합니다. 여기에는 베어 메탈 노드 제어, 검증 및 플랜 관리 및 오버클라우드 배포가 포함됩니다.

예를 들어 openstack overcloud deploy 명령을 실행할 때 OpenStack Workflow 서비스는 두 개의 워크플로우를 실행합니다. 첫 번째는 배포 플랜을 업로드합니다.

Removing the current plan files
Uploading new plan files
Started Mistral Workflow. Execution ID: aef1e8c6-a862-42de-8bce-073744ed5e6b
Plan updated

두 번째는 오버클라우드 배포를 시작합니다.

Deploying templates in the directory /tmp/tripleoclient-LhRlHX/tripleo-heat-templates
Started Mistral Workflow. Execution ID: 97b64abe-d8fc-414a-837a-1380631c764d
2016-11-28 06:29:26Z [overcloud]: CREATE_IN_PROGRESS  Stack CREATE started
2016-11-28 06:29:26Z [overcloud.Networks]: CREATE_IN_PROGRESS  state changed
2016-11-28 06:29:26Z [overcloud.HeatAuthEncryptionKey]: CREATE_IN_PROGRESS  state changed
2016-11-28 06:29:26Z [overcloud.ServiceNetMap]: CREATE_IN_PROGRESS  state changed
...

$ source ~/stackrc
(undercloud) $ openstack workflow execution list | grep "ERROR"

실패한 워크플로우 실행의 UUID를 가져와서(예: dffa96b0-f679-4cd2-a490-4769a3825262) 실행 및 해당 출력을 확인합니다.

(undercloud) $ openstack workflow execution show dffa96b0-f679-4cd2-a490-4769a3825262
(undercloud) $ openstack workflow execution output show dffa96b0-f679-4cd2-a490-4769a3825262

이는 실행에서 실패한 작업에 대한 정보를 제공합니다. 또한 openstack workflow execution show는 실행에 사용된 워크플로우를 표시합니다(예: tripleo.plan_management.v1.publish_ui_logs_to_swift). 다음 명령을 사용하면 전체 워크플로우 정의를 볼 수 있습니다.

(undercloud) $ openstack workflow definition show tripleo.plan_management.v1.publish_ui_logs_to_swift

이 명령은 워크플로우에서 특정 작업이 발생한 위치를 식별하는 데 유용합니다.

비슷한 명령 구문을 사용하여 작업 실행 및 해당 결과를 볼 수도 있습니다.

(undercloud) $ openstack action execution list
(undercloud) $ openstack action execution show 8a68eba3-0fec-4b2a-adc9-5561b007e886
(undercloud) $ openstack action execution output show 8a68eba3-0fec-4b2a-adc9-5561b007e886

이는 문제의 원인이 되는 특정 작업을 식별하는 데 유용합니다.

배포가 실패할 수 있는 세 가지 계층이 있습니다.

오버클라우드 배포가 이러한 수준에서 실패한 경우 OpenStack 클라이언트 및 서비스 로그 파일을 사용하여 실패한 배포를 진단합니다.

$ source ~/stackrc
(undercloud) $ openstack stack list --nested --property status=FAILED
+-----------------------+------------+--------------------+----------------------+
| id                    | stack_name | stack_status       | creation_time        |
+-----------------------+------------+--------------------+----------------------+
| 7e88af95-535c-4a55... | overcloud  | CREATE_FAILED      | 2015-04-06T17:57:16Z |
+-----------------------+------------+--------------------+----------------------+

$ source ~/stackrc
(undercloud) $ openstack baremetal node list

+----------+------+---------------+-------------+-----------------+-------------+
| UUID     | Name | Instance UUID | Power State | Provision State | Maintenance |
+----------+------+---------------+-------------+-----------------+-------------+
| f1e261...| None | None          | power off   | available       | False       |
| f0b8c1...| None | None          | power off   | available       | False       |
+----------+------+---------------+-------------+-----------------+-------------+

대상 호스트가 이미 사용 중인 할당된 IP 주소이면 검색 및 배포 작업이 실패합니다. 이 문제가 발생하지 않도록 하려면 프로비저닝 네트워크의 포트 스캔을 수행하여 검색 IP 범위 및 호스트 IP 범위를 사용할 수 있는지 확인합니다.

언더클라우드 호스트에서 다음 단계를 수행합니다.

nmap을 설치합니다.

$ sudo yum install nmap

nmap을 사용하여 활성 주소에 대한 IP 주소 범위를 스캔합니다. 이 예에서는 192.168.24.0/24 범위를 스캔하고, 이 범위를 프로비저닝 네트워크의 IP 서브넷으로 교체합니다(CIDR 비트마스크 표기 사용).

$ sudo nmap -sn 192.168.24.0/24

nmap 스캔 출력을 검토합니다.

예를 들어 언더클라우드의 IP 주소 및 서브넷에 있는 다른 호스트가 표시됩니다. 활성 IP 주소가 undercloud.conf의 IP 범위와 충돌하는 경우 IP 주소 범위를 변경하거나 IP 주소가 사용 가능하도록 설정한 후에 오버클라우드 노드를 인트로스펙션을 실행하거나 배포해야 합니다.

$ sudo nmap -sn 192.168.24.0/24

Starting Nmap 6.40 ( http://nmap.org ) at 2015-10-02 15:14 EDT
Nmap scan report for 192.168.24.1
Host is up (0.00057s latency).
Nmap scan report for 192.168.24.2
Host is up (0.00048s latency).
Nmap scan report for 192.168.24.3
Host is up (0.00045s latency).
Nmap scan report for 192.168.24.5
Host is up (0.00040s latency).
Nmap scan report for 192.168.24.9
Host is up (0.00019s latency).
Nmap done: 256 IP addresses (5 hosts up) scanned in 2.45 seconds

/var/log/nova/nova-conductor.log에 다음 오류가 포함되는 경우가 있습니다.

NoValidHost: No valid host was found. There are not enough hosts available.

이는 nova 스케줄러가 새 인스턴스 부팅에 적합한 베어 메탈 노드를 찾을 수 없음을 의미하며, 결국은 nova에서 찾아야 하는 리소스와 ironic에서 nova에 통지한 리소스가 일치하지 않음을 의미합니다. 이런 경우 다음을 확인하십시오.

오버클라우드 생성 후 나중에 특정 오버클라우드 작업을 수행할 수 있습니다. 예를 들어 사용 가능한 노드를 확장하거나 문제가 발생한 노드를 교체할 수 있습니다. 이러한 작업을 수행할 때 특정 문제가 발생할 수 있습니다. 이 섹션에서는 생성 후 작업 실패 문제를 진단하고 해결하는 몇 가지 방법을 설명합니다.

$ sudo docker logs keystone

$ sudo docker inspect keystone

$ sudo docker inspect keystone | jq .[0].Mounts

$ sudo docker inspect --format='{{range .Config.Env}} -e "{{.}}" {{end}} {{range .Mounts}} -v {{.Source}}:{{.Destination}}{{if .Mode}}:{{.Mode}}{{end}}{{end}} -ti {{.Config.Image}}' keystone

$ OPTIONS=$( sudo docker inspect --format='{{range .Config.Env}} -e "{{.}}" {{end}} {{range .Mounts}} -v {{.Source}}:{{.Destination}}{{if .Mode}}:{{.Mode}}{{end}}{{end}} -ti {{.Config.Image}}' keystone )
$ sudo docker run --rm $OPTIONS /bin/bash

$ sudo docker exec -ti keystone <COMMAND>

$ sudo docker exec -ti keystone /openstack/healthcheck

$ sudo docker exec -ti keystone /bin/bash

$ sudo docker export keystone -o keystone.tar

이 섹션의 지침은 언더클라우드의 성능 향상을 지원하기 위한 것입니다. 필요에 따라 권장사항을 구현하십시오.

OpenStack Platform에 대해 Red Hat에 지원을 문의하는 경우 sosreport를 생성해야 합니다. sosreport 생성 방법에 대한 자세한 정보는 아래 지식 베이스 문서를 참조하십시오.

문제를 해결할 때 다음 로그를 사용하여 언더클라우드 및 오버클라우드에 대한 정보를 찾습니다.