6장. CLI 툴로 기본 오버클라우드 설정

이 장에서는 CLI 툴을 사용하는 OpenStack Platform 환경의 기본적인 설정 단계를 설명합니다. 기본 설정을 사용하는 오버클라우드에는 사용자 지정 기능이 포함되어 있지 않지만 고급 구성 옵션을 이 기본 오버클라우드에 추가하고 Advanced Overcloud Customization 가이드의 지침을 사용하여 사양에 맞게 사용자 지정할 수 있습니다.

6.1. 오버클라우드에 노드 등록

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

절차

  1. 노드를 나열하는 템플릿을 작성합니다. 예를 들어 JSON 포맷으로 된 템플릿은 다음과 같습니다.

    {
        "nodes":[
            {
                "mac":[
                    "bb:bb:bb:bb:bb:bb"
                ],
                "name":"node01",
                "cpu":"4",
                "memory":"6144",
                "disk":"40",
                "arch":"x86_64",
                "pm_type":"ipmi",
                "pm_user":"admin",
                "pm_password":"p@55w0rd!",
                "pm_addr":"192.168.24.205"
            },
            {
                "mac":[
                    "cc:cc:cc:cc:cc:cc"
                ],
                "name":"node02",
                "cpu":"4",
                "memory":"6144",
                "disk":"40",
                "arch":"x86_64",
                "pm_type":"ipmi",
                "pm_user":"admin",
                "pm_password":"p@55w0rd!",
                "pm_addr":"192.168.24.206"
            }
        ]
    }

    YAML로 된 유사한 노드 템플릿의 예는 다음과 같습니다.

    nodes:
      - mac:
          - "bb:bb:bb:bb:bb:bb"
        name: "node01"
        cpu: 4
        memory: 6144
        disk: 40
        arch: "x86_64"
        pm_type: "ipmi"
        pm_user: "admin"
        pm_password: "p@55w0rd!"
        pm_addr: "192.168.24.205"
      - mac:
          - cc:cc:cc:cc:cc:cc
        name: "node02"
        cpu: 4
        memory: 6144
        disk: 40
        arch: "x86_64"
        pm_type: "ipmi"
        pm_user: "admin"
        pm_password: "p@55w0rd!"
        pm_addr: "192.168.24.206"

    이 템플릿은 다음 속성을 사용합니다.

    name
    노드의 논리 이름입니다.
    pm_type

    사용할 전원 관리 드라이버입니다. 이 예에서는 전원 관리의 기본 드라이버인 IPMI 드라이버(ipmi)를 사용합니다.

    참고

    IPMI는 지원되는 기본 전원 관리 드라이버입니다. 지원되는 추가 전원 관리 유형 및 옵션은 부록 B. 전원 관리 드라이버를 참조하십시오. 이러한 전원 관리 드라이버가 예상대로 작동하지 않는 경우 전원 관리에 IPMI를 사용하십시오.

    pm_user; pm_password
    IPMI 사용자 이름 및 암호입니다.
    pm_addr
    IPMI 장치의 IP 주소입니다.
    mac
    (선택 사항) 노드에 있는 네트워크 인터페이스의 MAC 주소 목록입니다. 각 시스템의 프로비저닝 NIC에는 MAC 주소만 사용합니다.
    cpu
    (선택 사항) 노드에 있는 CPU 수입니다.
    memory
    (선택 사항) 메모리 크기(MB)입니다.
    disk
    (선택 사항) 하드 디스크의 크기(GB)입니다.
    arch

    (선택 사항) 시스템 아키텍처입니다.

    중요

    다중 아키텍처 클라우드를 빌드하는 경우 x86_64ppc64le 아키텍처를 사용하여 노드를 구분하려면 arch 키가 필요합니다.

  2. 템플릿을 생성한 후 파일을 stack 사용자의 홈 디렉터리(/home/stack/nodes.json)에 저장하고 다음 명령을 사용하여 director로 가져옵니다.

    $ source ~/stackrc
    (undercloud) $ openstack overcloud node import ~/nodes.json

    이 명령으로 템플릿을 가져와서 템플릿의 각 노드가 director에 등록됩니다.

  3. 노드 등록 및 설정이 완료되면 CLI에서 이러한 노드 목록을 확인합니다.

    (undercloud) $ openstack baremetal node list

6.2. 노드의 하드웨어 검사

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

절차

  1. 다음 명령을 실행하여 각 노드의 하드웨어 속성을 확인합니다.

    (undercloud) $ openstack overcloud node introspect --all-manageable --provide
    • --all-manageable 옵션은 관리되는 상태의 노드만 인트로스펙션합니다. 이 예에서는 모든 노드가 해당됩니다.
    • --provide 옵션은 인트로스펙션 이후 모든 노드를 available 상태로 리셋합니다.
  2. 다른 터미널 창에서 다음 명령을 사용하여 인트로스펙션 진행 상황을 모니터링합니다.

    (undercloud) $ sudo journalctl -l -u openstack-ironic-inspector -u openstack-ironic-inspector-dnsmasq -u openstack-ironic-conductor -f
    중요

    이 프로세스가 완료되었는지 확인합니다. 베어 메탈 노드의 경우 이 프로세스는 일반적으로 15분 정도 걸립니다.

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

6.3. 프로필에 노드 태그

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

유형설명

역할

Controller 역할은 컨트롤러 노드 설정 방법을 정의합니다.

플레이버

control 플레이버는 노드에서 컨트롤러로 사용할 하드웨어 프로파일을 정의합니다. director에서 사용할 노드를 결정할 수 있도록 이 플레이버를 Controller 역할에 할당합니다.

프로파일

control 프로파일은 control 플레이버에 적용하는 태그입니다. 이 프로파일은 플레이버에 속한 노드를 정의합니다.

노드

또한 control 프로파일 태그를 개별 노드에 적용하면 control 플레이버에 그룹화되며, 결과적으로 director에서는 Controller 역할을 사용하여 이러한 개별 노드를 설정합니다.

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

절차

  1. 노드를 특정 프로파일에 태그하려면 profile 옵션을 각 노드의 properties/capabilities 매개 변수에 추가합니다. 예를 들어 노드를 Controller 및 Compute 프로파일에 각각 태그하려면 다음 명령을 사용합니다.

    (undercloud) $ openstack baremetal node set --property capabilities='profile:compute,boot_option:local' 58c3d07e-24f2-48a7-bbb6-6843f0e8ee13
    (undercloud) $ openstack baremetal node set --property capabilities='profile:control,boot_option:local' 1a4e30da-b6dc-499d-ba87-0bd8a3819bc0

    profile:computeprofile:control 옵션을 추가하면 두 개의 노드가 각각 해당하는 프로파일에 태그됩니다.

    이러한 명령은 각 노드를 부팅하는 방법을 정의하는 boot_option:local 매개 변수도 설정합니다.

  2. 노드 태그를 완료한 후 할당된 프로파일 또는 가능한 프로파일을 확인합니다.

    (undercloud) $ openstack overcloud profiles list

6.4. UEFI 부팅 모드 설정

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

절차

  1. undercloud.conf 파일에 다음 매개 변수를 설정합니다.

    ipxe_enabled = True
    inspection_enable_uefi = True
  2. 이 파일을 저장하고 언더클라우드 설치를 실행합니다.

    $ openstack undercloud install

    설치 스크립트가 완료될 때까지 기다리십시오.

  3. 등록된 각 노드의 부팅 모드를 uefi로 설정합니다. 예를 들어 capabilities 속성에서 기존 boot_mode 매개 변수를 추가 또는 교체하려면 다음 명령을 실행합니다.

    $ NODE=<NODE NAME OR ID> ; openstack baremetal node set --property capabilities="boot_mode:uefi,$(openstack baremetal node show $NODE -f json -c properties | jq -r .properties.capabilities | sed "s/boot_mode:[^,]*,//g")" $NODE
    참고

    profileboot_option 기능이 유지되고 있는지 확인합니다.

    +

    $ openstack baremetal node show r530-12 -f json -c properties | jq -r .properties.capabilities
  4. 각 플레이버의 부팅 모드를 uefi로 설정합니다.

    $ openstack flavor set --property capabilities:boot_mode='uefi' control

6.5. 노드의 root 디스크 정의

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

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

  • model(문자열): 장치 식별자
  • vendor(문자열): 장치 벤더
  • serial(문자열): 디스크 일련 번호
  • hctl(문자열): Host:Channel:Target:Lun (SCSI 용)
  • size(정수): 장치의 크기(GB 단위)
  • wwn(문자열): 고유한 스토리지 식별자
  • wwn_with_extension(문자열): 벤더 확장이 첨부된 고유한 스토리지 식별자
  • wwn_vendor_extension(문자열): 고유한 벤더 스토리지 식별자
  • rotational(부울): 회전 장치인 경우(HDD) True, 그렇지 않은 경우 false(SSD)
  • name(문자열): 장치의 이름(예: /dev/sdb1)
중요

name은 영구적인 이름이 있는 장치에만 사용합니다. 노드가 부팅될 때 값이 변경될 수 있으므로 name을 사용하여 다른 장치에 대해 root 디스크를 설정하지 마십시오.

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

절차

  1. 각 노드의 하드웨어 인트로스펙션에서 디스크 정보를 확인합니다. 다음 명령은 노드의 디스크 정보를 표시합니다.

    (undercloud) $ openstack baremetal introspection data save 1a4e30da-b6dc-499d-ba87-0bd8a3819bc0 | jq ".inventory.disks"

    예를 들면 하나의 노드의 데이터에서 세 개의 디스크가 표시될 수 있습니다.

    [
      {
        "size": 299439751168,
        "rotational": true,
        "vendor": "DELL",
        "name": "/dev/sda",
        "wwn_vendor_extension": "0x1ea4dcc412a9632b",
        "wwn_with_extension": "0x61866da04f3807001ea4dcc412a9632b",
        "model": "PERC H330 Mini",
        "wwn": "0x61866da04f380700",
        "serial": "61866da04f3807001ea4dcc412a9632b"
      }
      {
        "size": 299439751168,
        "rotational": true,
        "vendor": "DELL",
        "name": "/dev/sdb",
        "wwn_vendor_extension": "0x1ea4e13c12e36ad6",
        "wwn_with_extension": "0x61866da04f380d001ea4e13c12e36ad6",
        "model": "PERC H330 Mini",
        "wwn": "0x61866da04f380d00",
        "serial": "61866da04f380d001ea4e13c12e36ad6"
      }
      {
        "size": 299439751168,
        "rotational": true,
        "vendor": "DELL",
        "name": "/dev/sdc",
        "wwn_vendor_extension": "0x1ea4e31e121cfb45",
        "wwn_with_extension": "0x61866da04f37fc001ea4e31e121cfb45",
        "model": "PERC H330 Mini",
        "wwn": "0x61866da04f37fc00",
        "serial": "61866da04f37fc001ea4e31e121cfb45"
      }
    ]
  2. 이 예에서는 root 디바이스를 일련 번호가 61866da04f380d001ea4e13c12e36ad6인 disk 2로 설정하는 방법을 보여줍니다. 이를 위해 노드 정의에서 root_device 매개 변수를 변경해야 합니다.

    (undercloud) $ openstack baremetal node set --property root_device='{"serial": "61866da04f380d001ea4e13c12e36ad6"}' 1a4e30da-b6dc-499d-ba87-0bd8a3819bc0
    참고

    선택한 root 디스크에서 부팅을 포함하도록 각 노드의 BIOS를 설정합니다. 권장 부팅 순서는 네트워크 부팅, root 디스크 부팅 순입니다.

6.6. 아키텍처별 역할 생성

다중 아키텍처 클라우드를 빌드하는 경우 모든 아키텍처별 역할을 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

6.7. 환경 파일

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

  • 각 역할 및 해당 플레이버당 노드의 크기입니다. 오버클라우드 생성에 이 정보를 포함하는 것이 중요합니다.
  • 컨테이너화된 OpenStack 서비스의 컨테이너 이미지 위치입니다.
  • heat 템플릿 컬렉션의 초기화 파일(environments/network-isolation.yaml) 부터 시작하여 네트워크 분리 파일, 사용자 정의 NIC 설정 파일, 마지막으로 추가 네트워크 설정 순입니다.
  • 모든 외부 로드 밸런싱 환경 파일
  • Ceph Storage, NFS, iSCSI 등과 같은 스토리지 환경 파일
  • Red Hat CDN 또는 Satellite 등록의 환경 파일
  • 기타 사용자 정의 환경 파일

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

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

중요

기본 오버클라우드는 블록 스토리지에 지원되지 않는 구성인 로컬 LVM 스토리지를 사용합니다. 블록 스토리지에 Red Hat Ceph Storage와 같은 외부 스토리지 솔루션을 사용하는 것이 좋습니다.

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

6.8. 노드 수 및 플레이버를 정의하는 환경 만들기

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

절차

  1. /home/stack/templates/ 디렉터리에 node-info.yaml 파일을 생성합니다.

    (undercloud) $ touch /home/stack/templates/node-info.yaml
  2. 필요한 노드 수 및 플레이버를 포함하도록 파일을 편집합니다. 이 예에서는 컨트롤러 노드 3개, 컴퓨팅 노드 3개, Ceph Storage 노드 3개를 배포합니다.

    parameter_defaults:
      OvercloudControllerFlavor: control
      OvercloudComputeFlavor: compute
      ControllerCount: 3
      ComputeCount: 3

6.9. 언더클라우드 CA를 신뢰하는 환경 파일 생성

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

참고

이 접근법이 작동하려면 오버클라우드 노드에 언더클라우드의 공개 끝점에 대한 네트워크 경로가 있어야 합니다. 스파인-리프형 네트워킹을 사용하는 배포에는 이러한 설정을 적용해야 합니다.

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

  • 사용자 제공 인증서 - 이 정의는 사용자가 자체 인증서를 제공 한 경우 적용됩니다. 자신의 CA에서 가져온 것이거나 자체 서명된 것일 수 있습니다. undercloud_service_certificate 옵션을 사용하여 전달되며, 이 경우 배포에 따라 자체 서명 인증서 또는 CA를 신뢰해야 합니다.
  • 자동 생성 인증서 - 이 정의는 certmonger를 사용하여 자체 로컬 CA를 사용하여 인증서를 생성할 때 적용됩니다. 이는 generate_service_certificate 옵션을 사용하여 활성화됩니다. 이 예에서는 CA 인증서(/etc/pki/ca-trust/source/anchors/cm-local-ca.pem)가 있고, 언더클라우드의 HAProxy 인스턴스가 사용하는 서버 인증서가 있습니다. 이 인증서를 OpenStack에 제공하려면 inject-trust-anchor-hiera.yaml 파일에 CA 인증서를 추가해야 합니다.

절차

이 예에서는 /home/stack/ca.crt.pem에 있는 자체 서명 인증서를 사용합니다. 자동 생성 인증서를 사용하는 경우 대신 /etc/pki/ca-trust/source/anchors/cm-local-ca.pem을 사용하십시오.

  1. 인증서 파일을 열고 인증서 부분만 복사합니다. 키를 포함하지 마십시오.

    $ vi /home/stack/ca.crt.pem

    필요한 인증서 부분은 다음의 단축된 예와 비슷합니다.

    -----BEGIN CERTIFICATE-----
    MIIDlTCCAn2gAwIBAgIJAOnPtx2hHEhrMA0GCSqGSIb3DQEBCwUAMGExCzAJBgNV
    BAYTAlVTMQswCQYDVQQIDAJOQzEQMA4GA1UEBwwHUmFsZWlnaDEQMA4GA1UECgwH
    UmVkIEhhdDELMAkGA1UECwwCUUUxFDASBgNVBAMMCzE5Mi4xNjguMC4yMB4XDTE3
    -----END CERTIFICATE-----
  2. 다음 내용으로 /home/stack/inject-trust-anchor-hiera.yaml이라는 새 YAML 파일을 만들고, PEM 파일에서 복사한 인증서를 추가합니다.

    parameter_defaults:
      CAMap:
        ...
        undercloud-ca:
          content: |
            -----BEGIN CERTIFICATE-----
            MIIDlTCCAn2gAwIBAgIJAOnPtx2hHEhrMA0GCSqGSIb3DQEBCwUAMGExCzAJBgNV
            BAYTAlVTMQswCQYDVQQIDAJOQzEQMA4GA1UEBwwHUmFsZWlnaDEQMA4GA1UECgwH
            UmVkIEhhdDELMAkGA1UECwwCUUUxFDASBgNVBAMMCzE5Mi4xNjguMC4yMB4XDTE3
            -----END CERTIFICATE-----
    참고

    인증서 문자열이 PEM 형식을 따라야 합니다.

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

6.10. 배포 명령

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

주의

openstack overcloud deploy를 백그라운드 프로세스로 실행하지 마십시오. 백그라운드 프로세스로 시작한 경우 오버클라우드 생성이 배포 도중 중단될 수 있습니다.

6.11. 배포 명령 옵션

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

표 6.1. 배포 명령 옵션

매개 변수설명

--templates [TEMPLATES]

배포할 Heat 템플릿이 포함된 디렉터리. 비어 있을 경우 이 명령은 /usr/share/openstack-tripleo-heat-templates/를 기본 템플릿 위치로 사용합니다.

--stack STACK

생성하거나 업데이트할 스택의 이름

-t [TIMEOUT], --timeout [TIMEOUT]

배포 제한 시간(분)

--libvirt-type [LIBVIRT_TYPE]

하이퍼바이저에 사용할 가상화 유형

--ntp-server [NTP_SERVER]

시간 동기화에 사용할 NTP(Network Time Protocol) 서버. 콤마로 구분된 목록에 여러 개의 NTP 서버를 지정할 수도 있습니다(예: --ntp-server 0.centos.pool.org,1.centos.pool.org). 고가용성 클러스터 배포를 위해서는 컨트롤러가 동일한 시간 소스를 일관되게 참조해야 합니다. 일반적인 환경에는 기존의 사례대로 이미 지정된 NTP 시간 소스가 있을 수 있습니다.

--no-proxy [NO_PROXY]

환경 변수 no_proxy의 사용자 정의 값을 정의합니다. 이 변수는 프록시 통신에서 특정 호스트 이름을 제외합니다.

--overcloud-ssh-user OVERCLOUD_SSH_USER

오버클라우드 노드에 액세스할 SSH 사용자를 정의합니다. 일반적으로 SSH 액세스는 heat-admin 사용자를 통해 실행됩니다.

-e [EXTRA HEAT TEMPLATE], --extra-template [EXTRA HEAT TEMPLATE]

오버클라우드 배포에 전달할 추가 환경 파일입니다. 두 번 이상 지정할 수 있습니다. openstack overcloud deploy 명령에 전달되는 환경 파일 순서가 중요합니다. 예를 들어 순차적으로 전달되는 각 환경 파일의 매개 변수는 이전 환경 파일의 동일한 매개 변수를 덮어씁니다.

--environment-directory

배포에 포함할 환경 파일이 들어 있는 디렉터리. 이 명령은 이러한 환경 파일을 먼저 숫자 순으로 처리한 다음 알파벳 순으로 처리합니다.

--validation-errors-nonfatal

오버클라우드 생성 프로세스에서는 일련의 사전 배포 검사를 수행합니다. 이 옵션은 사전 배포 검사에서 치명적이지 않은 오류가 발생할 경우에만 종료됩니다. 오류가 있으면 배포에 실패할 수 있으므로 이 옵션을 사용하는 것이 좋습니다.

--validation-warnings-fatal

오버클라우드 생성 프로세스는 일련의 사전 배포 검사를 수행합니다. 이 옵션은 사전 배포 검사에서 심각하지 않은 경고가 발생할 경우에만 종료됩니다.

--dry-run

오버클라우드에서 검증 확인을 수행하지만, 오버클라우드를 실제로 생성하지는 않습니다.

--skip-postconfig

오버클라우드 배포 후 설정을 건너뜁니다.

--force-postconfig

오버클라우드 배포 후 설정을 강제 적용합니다.

--skip-deploy-identifier

DeployIdentifier 매개 변수에 대한 고유 식별자 생성을 건너뛰십시오. 소프트웨어 구성 배포 단계는 구성이 실제로 변경되는 경우에만 트리거됩니다. 특정 역할 확장과 같은 소프트웨어 구성을 실행할 필요가 없다는 확신이 있을 때만 이 옵션을 주의 깊게 사용하십시오.

--answers-file ANSWERS_FILE

인수 및 매개 변수를 사용한 YAML 파일의 경로입니다.

--rhel-reg

오버클라우드 노드를 고객 포털 또는 Satellite 6에 등록합니다.

--reg-method

오버클라우드 노드에 사용할 등록 방법입니다. Red Hat Satellite 6 또는 Red Hat Satellite 5에는 satellite를 고객 포털에는 portal을 사용합니다.

--reg-org [REG_ORG]

등록에 사용할 조직입니다.

--reg-force

시스템이 이미 등록되어 있어도 등록합니다.

--reg-sat-url [REG_SAT_URL]

오버클라우드 노드를 등록할 Satellite 서버의 기본 URL입니다. Satellite의 HTTPS URL 대신 HTTP URL을 이 매개 변수에 사용합니다. 예를 들어 https://satellite.example.com 대신 http://satellite.example.com을 사용합니다. 오버클라우드 생성 프로세스에서는 이 URL을 사용하여 서버가 Red Hat Satellite 5 서버인지 아니면 Red Hat Satellite 6 서버인지 확인합니다. Red Hat Satellite 6 서버인 경우 오버클라우드는 katello-ca-consumer-latest.noarch.rpm 파일을 가져오고, subscription-manager에 등록하고, katello-agent를 설치합니다. Red Hat Satellite 5 서버인 경우 오버클라우드는 RHN-ORG-TRUSTED-SSL-CERT 파일을 가져오고, rhnreg_ks에 등록합니다.

--reg-activation-key [REG_ACTIVATION_KEY]

등록에 사용할 활성화 키입니다.

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

(undercloud) $ openstack help overcloud deploy

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

표 6.2. 더 이상 사용되지 않는 CLI 매개 변수와 상응하는 Heat 템플릿 매개 변수의 매핑

매개 변수설명 Heat 템플릿 매개 변수

--control-scale

확장할 Controller 노드 수

ControllerCount

--compute-scale

확장할 Compute 노드 수

ComputeCount

--ceph-storage-scale

확장할 Ceph Storage 노드 수

CephStorageCount

--block-storage-scale

확장할 Cinder 노드 수

BlockStorageCount

--swift-storage-scale

확장할 Swift 노드 수

ObjectStorageCount

--control-flavor

Controller 노드에 사용할 플레이버

OvercloudControllerFlavor

--compute-flavor

Compute 노드에 사용할 플레이버

OvercloudComputeFlavor

--ceph-storage-flavor

Ceph Storage 노드에 사용할 플레이버

OvercloudCephStorageFlavor

--block-storage-flavor

Cinder 노드에 사용할 플레이버

OvercloudBlockStorageFlavor

--swift-storage-flavor

Swift Storage 노드에 사용할 플레이버

OvercloudSwiftStorageFlavor

--neutron-flat-networks

neutron 플러그인에 설정할 플랫 네트워크를 정의합니다. 외부 네트워크 생성을 허용하도록 기본적으로 "datacentre"로 설정됩니다.

NeutronFlatNetworks

--neutron-physical-bridge

각 하이퍼바이저에 생성할 Open vSwitch 브리지. 기본값은 "br-ex"입니다. 일반적으로 이 값은 변경할 필요가 없습니다.

HypervisorNeutronPhysicalBridge

--neutron-bridge-mappings

사용할 논리적 브리지와 물리적 브리지의 매핑. 기본적으로 호스트(br-ex)의 외부 브리지가 물리적 이름(datacentre)에 매핑됩니다. 기본 유동 네트워크에 이 기본값을 사용합니다.

NeutronBridgeMappings

--neutron-public-interface

네트워크 노드의 br-ex에 브리지에 인터페이스를 정의합니다.

NeutronPublicInterface

--neutron-network-type

Neutron의 테넌트 네트워크 유형

NeutronNetworkType

--neutron-tunnel-types

Neutron 테넌트 네트워크의 터널 유형. 여러 값을 지정하려면 콤마로 구분된 문자열을 사용합니다.

NeutronTunnelTypes

--neutron-tunnel-id-ranges

테넌트 네트워크 할당에 사용할 수 있는 GRE 터널 ID 범위

NeutronTunnelIdRanges

--neutron-vni-ranges

테넌트 네트워크 할당에 사용할 수 있는 VXLAN VNI ID 범위

NeutronVniRanges

--neutron-network-vlan-ranges

지원할 Neutron ML2 및 Open vSwitch VLAN 매핑 범위. 기본적으로 datacentre 물리적 네트워크에서 VLAN을 허용하도록 설정되어 있습니다.

NeutronNetworkVLANRanges

--neutron-mechanism-drivers

neutron 테넌트 네트워크의 매커니즘 드라이버. 기본값은 "openvswitch"입니다. 여러 값을 지정하려면 콤마로 구분된 문자열을 사용합니다.

NeutronMechanismDrivers

--neutron-disable-tunneling

VLAN 세그먼트화된 네트워크 또는 플랫 네트워크를 Neutron과 함께 사용하려는 경우 터널링을 비활성화합니다.

매개 변수 매핑 없음

--validation-errors-fatal

오버클라우드 생성 프로세스는 일련의 사전 배포 검사를 수행합니다. 이 옵션은 사전 배포 확인에서 치명적인 오류가 발생할 경우에만 종료됩니다. 오류가 발생하면 배포에 실패할 수 있으므로 이 옵션을 사용하는 것이 좋습니다.

매개 변수 매핑 없음

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

6.12. 오버클라우드 배포에 환경 파일 포함

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

  • 각 역할 및 해당 플레이버당 노드의 크기입니다. 오버클라우드 생성에 이 정보를 포함하는 것이 중요합니다.
  • 컨테이너화된 OpenStack 서비스의 컨테이너 이미지 위치입니다.
  • heat 템플릿 컬렉션의 초기화 파일(environments/network-isolation.yaml) 부터 시작하여 네트워크 분리 파일, 사용자 정의 NIC 설정 파일, 마지막으로 추가 네트워크 설정 순입니다.
  • 모든 외부 로드 밸런싱 환경 파일
  • Ceph Storage, NFS, iSCSI 등과 같은 스토리지 환경 파일
  • Red Hat CDN 또는 Satellite 등록의 환경 파일
  • 기타 사용자 정의 환경 파일

-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 \

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

--templates
/usr/share/openstack-tripleo-heat-templates의 Heat 템플릿 컬렉션을 기반으로 하여 오버클라우드를 생성합니다.
-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
(옵션) 사용자 지정 역할 또는 다중 아키텍처 클라우드를 사용하는 경우 생성된 역할 데이터입니다. 자세한 내용은 6.6절. “아키텍처별 역할 생성”을 참조하십시오.

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

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

  1. 사용자 정의 환경 파일 및 Heat 템플릿에서 매개 변수 수정
  2. 같은 환경 파일을 지정하고 openstack overcloud deploy 명령을 다시 실행

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

6.13. 배포 작업 전 오버클라우드 설정 확인

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

절차

  1. 오버클라우드의 코어 Heat 템플릿은 Jinja2 포맷으로 되어 있습니다. 템플릿을 확인하려면 다음 명령을 사용하여 Jinja2 포맷을 사용하지 않고 버전을 렌더링합니다.

    $ cd /usr/share/openstack-tripleo-heat-templates
    $ ./tools/process-templates.py -o ~/overcloud-validation
  2. 다음 명령을 사용하여 템플릿 구문을 확인합니다.

    (undercloud) $ openstack orchestration template validate --show-nested \
      --template ~/overcloud-validation/overcloud.yaml
      -e ~/overcloud-validation/overcloud-resource-registry-puppet.yaml \
      -e [ENVIRONMENT FILE] \
      -e [ENVIRONMENT FILE]

    검증을 수행하려면 오버클라우드 특정 리소스를 포함할 overcloud-resource-registry-puppet.yaml 환경 파일이 필요합니다. -e 옵션을 사용하여 이 명령에 환경 파일을 추가하십시오. 또한 --show-nested 옵션을 추가하여 중첩된 템플릿에서 매개 변수를 해결합니다.

  3. 이 명령은 템플릿에서 구문 오류를 식별합니다. 템플릿 구문의 검증이 성공적으로 수행되면 출력에 결과 오버클라우드 템플릿의 프리뷰가 표시됩니다.

6.14. 오버클라우드 배포 출력

오버클라우드 생성이 완료되면 오버클라우드를 설정하기 위해 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

6.15. 오버클라우드 액세스

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

6.16. 다음 단계

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


Red Hat의 최신 제품 문서 번역을 신속하게 제공하기 위해 이 페이지에는 영어 원본을 한국어로 자동 번역한 내용이 포함되어 있을 수 있습니다. [자세한 내용보기]