Red Hat Training

A Red Hat training course is available for Red Hat OpenStack Platform

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

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

이 장의 예에서는 모든 노드가 전원 관리에 IPMI를 사용하는 베어 메탈 시스템으로 되어 있습니다. 지원되는 전원 관리 유형 및 옵션에 대한 자세한 내용은 부록 B. 전원 관리 드라이버를 참조하십시오.

워크플로우

  1. 노드 정의 템플릿을 생성하고 director에서 빈 노드를 등록합니다.
  2. 모든 노드의 하드웨어를 검사합니다.
  3. 노드를 역할에 태그합니다.
  4. 추가 노드 속성을 정의합니다.

요구 사항

  • 4장. 언더클라우드 설치에서 생성한 director 노드
  • 노드에 사용하는 베어 메탈 머신 세트. 필요한 노드 수는 생성하려는 오버클라우드 유형에 따라 다릅니다(오버클라우드 역할에 대한 자세한 내용은 3.1절. “노드 배포 역할 플래닝” 참조). 이러한 머신은 각 노드 유형에 대해 설정된 요구 사항을 준수해야 합니다. 이러한 요구 사항은 2.4절. “오버클라우드 요구 사항”을 참조하십시오. 이러한 노드에는 운영 체제가 필요하지 않습니다. director에서 Red Hat Enterprise Linux 7 이미지를 각 노드에 복사합니다.
  • 기본 VLAN으로 구성된 프로비저닝 네트워크에 대한 한 개의 네트워크 연결이 필요합니다. 모든 노드는 이 네트워크에 연결해야 하며 2.3절. “네트워킹 요구 사항”에 설정된 요구 사항을 준수해야 합니다. 이 장의 예에서는 다음 IP 주소가 할당된 프로비저닝 서브넷으로 192.168.24.0/24를 사용합니다.

    표 6.1. 프로비저닝 네트워크 IP 할당

    노드 이름

    IP 주소

    MAC 주소

    IPMI IP 주소

    Director

    192.168.24.1

    aa:aa:aa:aa:aa:aa

    필요 없음

    Controller

    DHCP 정의됨

    bb:bb:bb:bb:bb:bb

    192.168.24.205

    Compute

    DHCP 정의됨

    cc:cc:cc:cc:cc:cc

    192.168.24.206

  • 다른 모든 네트워크 유형은 OpenStack 서비스에 프로비저닝 네트워크를 사용하지만 다른 네트워크 트래픽 유형에 대해 추가로 네트워크를 생성할 수 있습니다.
  • 컨테이너 이미지에 대한 소스가 필요합니다. 컨테이너 이미지 소스를 포함하는 환경 파일 생성 방법에 대한 지침은 5장. 컨테이너 이미지 소스 구성를 참조하십시오.

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

director에는 수동으로 만든 노드 정의 템플릿이 필요합니다. 이 파일(instackenv.json)은 JSON 포맷 파일을 사용하며, 노드의 하드웨어 및 전원 관리 정보가 포함되어 있습니다. 예를 들면 노드 두 개를 등록할 템플릿은 다음과 같이 표시될 수 있습니다.

{
    "nodes":[
        {
            "mac":[
                "bb:bb:bb:bb:bb:bb"
            ],
            "name":"node01",
            "cpu":"4",
            "memory":"6144",
            "disk":"40",
            "arch":"x86_64",
            "pm_type":"pxe_ipmitool",
            "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":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"p@55w0rd!",
            "pm_addr":"192.168.24.206"
        }
    ]
}

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

name
노드의 논리 이름입니다.
pm_type
사용할 전원 관리 드라이버입니다. 이 예에서는 IPMI 드라이버(pxe_ipmitool)를 사용합니다.
pm_user; pm_password
IPMI 사용자 이름 및 암호입니다.
pm_addr
IPMI 장치의 IP 주소입니다.
mac
(선택 사항) 노드에 있는 네트워크 인터페이스의 MAC 주소 목록입니다. 각 시스템의 프로비저닝 NIC에는 MAC 주소만 사용하십시오.
cpu
(선택 사항) 노드에 있는 CPU 수입니다.
memory
(선택 사항) 메모리 크기(MB)입니다.
disk
(선택 사항) 하드 디스크의 크기(GB)입니다.
arch
(선택 사항) 시스템 아키텍처입니다.
참고

지원되는 전원 관리 유형 및 해당 옵션에 대해서는 부록 B. 전원 관리 드라이버를 참조하십시오.

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

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

이렇게 하면 템플릿을 가져와서 템플릿의 각 노드가 director에 등록됩니다.

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

(undercloud) $ openstack baremetal node list

6.2. 노드의 하드웨어 검사

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

참고

정책 파일을 생성하여 introspection 이후 바로 프로필에 노드를 자동으로 태깅할 수 있습니다. 정책 파일 생성 및 introspection 프로세스에 정책 파일을 포함하는 작업에 대한 자세한 내용은 부록 E. 자동 프로필 태깅을 참조하십시오. 또는 6.4절. “프로필에 노드 태그”의 지침에 따라 프로파일에 노드를 수동으로 태그할 수 있습니다.

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

(undercloud) $ openstack overcloud node introspect --all-manageable --provide
  • --all-manageable 옵션은 관리되는 상태의 노드만 검사합니다. 이 예에서는 모든 노드가 해당됩니다.
  • --provide 옵션은 인트로스펙션 이후 모든 노드를 available 상태로 리셋합니다.

다른 터미널 창에서 다음 명령을 사용하여 introspection 진행 상황을 모니터링합니다.

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

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

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

개별적으로 노드 인트로스펙션 실행

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

하드웨어 인트로스펙션 상세 정보 검색

Bare Metal 서비스의 하드웨어 검사 추가 기능 (inspection_extras)는 기본적으로 활성화되어 하드웨어 상세 정보를 검색합니다. 이러한 하드웨어 상세 정보를 사용하여 오버클라우드를 구성할 수 있습니다. undercloud.conf 파일의 inspection_extras 매개 변수에 대한 상세 정보는 Director 구성을 참조하십시오.

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

  • RAM(KB)
  • 물리적 CPU 코어 및 시블링 스레드
  • NUMA 노드와 연결된 NIC

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
    }
  ]
}

6.3. 베어 메탈 노드 자동 검색

instackenv.json 파일을 먼저 생성하지 않고 auto-discovery를 사용하여 언더클라우드 노드를 등록하고 해당 메타데이터를 생성할 수 있습니다. 이러한 개선 사항은 초기 노드 정보를 수집하는 데 소요되는 시간을 줄이는 데 도움이 될 수 있습니다. 예를 들어 IPMI IP 주소를 분석하고 차후에 instackenv.json을 생성할 필요가 없습니다.

요구 사항

  • 모든 오버클라우드 노드는 IPMI를 통해 director에 액세스할 수 있도록 BMC를 구성해야 합니다.
  • 모든 클라우드 노드는 언더클라우드 컨트롤 플레인 네트워크에 연결된 NIC에서 PXE 부팅되도록 구성해야 합니다.

자동 검색 활성화

  1. 베어 메탈 자동 검색을 undercloud.conf에서 활성화합니다.

    enable_node_discovery = True
    discovery_default_driver = pxe_ipmitool
    • enable_node_discovery - 활성화되면 PXE를 사용하여 인트로스펙션 램디스크를 부팅하는 모든 노드가 ironic에 등록됩니다.
    • discovery_default_driver - 드라이버를 검색된 노드에서 사용할 수 있도록 설정합니다. 예: pxe_ipmitool
  2. IPMI 인증서를 ironic에 추가합니다:

    1. IPMI 인증서를 ipmi-credentials.json이라는 이름의 파일에 추가합니다. 이 예시에서 사용자 이름과 암호 값을 사용자 환경에 맞게 변경해야 합니다.

      [
          {
              "description": "Set default IPMI credentials",
              "conditions": [
                  {"op": "eq", "field": "data://auto_discovered", "value": true}
              ],
              "actions": [
                  {"action": "set-attribute", "path": "driver_info/ipmi_username",
                   "value": "SampleUsername"},
                  {"action": "set-attribute", "path": "driver_info/ipmi_password",
                   "value": "RedactedSecurePassword"},
                  {"action": "set-attribute", "path": "driver_info/ipmi_address",
                   "value": "{data[inventory][bmc_address]}"}
              ]
          }
      ]
  3. IPMI 인증서 파일을 ironic에 가져옵니다.

    $ openstack baremetal introspection rule import ipmi-credentials.json

자동 검색 테스트

  1. 필요한 노드의 전원을 켭니다.
  2. openstack baremetal node list를 실행하면 enrolled 상태에 새 노드가 표시되어야 합니다.

    $ openstack baremetal node list
    +--------------------------------------+------+---------------+-------------+--------------------+-------------+
    | UUID                                 | Name | Instance UUID | Power State | Provisioning State | Maintenance |
    +--------------------------------------+------+---------------+-------------+--------------------+-------------+
    | c6e63aec-e5ba-4d63-8d37-bd57628258e8 | None | None          | power off   | enroll             | False       |
    | 0362b7b2-5b9c-4113-92e1-0b34a2535d9b | None | None          | power off   | enroll             | False       |
    +--------------------------------------+------+---------------+-------------+--------------------+-------------+
  3. 각 노드에 리소스 클래스를 설정합니다.

    $ for NODE in `openstack baremetal node list -c UUID -f value` ; do openstack baremetal node set $NODE --resource-class baremetal ; done
  4. 각 노드에 커널 및 램디스크를 구성합니다.

    $ for NODE in `openstack baremetal node list -c UUID -f value` ; do openstack baremetal node manage $NODE ; done
    $ openstack overcloud node configure --all-manageable
  5. 모든 노드를 사용 가능한 상태로 설정합니다.

    $ for NODE in `openstack baremetal node list -c UUID -f value` ; do openstack baremetal node provide $NODE ; done

규칙을 사용하여 다른 벤더 하드웨어 검색 방법

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

  1. 다음 콘텐츠로 dell-drac-rules.json이라는 파일을 생성합니다. 이 예시에서 사용자 이름과 암호 값을 사용자 환경에 맞게 변경해야 합니다.

    [
        {
            "description": "Set default IPMI credentials",
            "conditions": [
                {"op": "eq", "field": "data://auto_discovered", "value": true},
                {"op": "ne", "field": "data://inventory.system_vendor.manufacturer",
                 "value": "Dell Inc."}
            ],
            "actions": [
                {"action": "set-attribute", "path": "driver_info/ipmi_username",
                 "value": "SampleUsername"},
                {"action": "set-attribute", "path": "driver_info/ipmi_password",
                 "value": "RedactedSecurePassword"},
                {"action": "set-attribute", "path": "driver_info/ipmi_address",
                 "value": "{data[inventory][bmc_address]}"}
            ]
        },
        {
            "description": "Set the vendor driver for Dell hardware",
            "conditions": [
                {"op": "eq", "field": "data://auto_discovered", "value": true},
                {"op": "eq", "field": "data://inventory.system_vendor.manufacturer",
                 "value": "Dell Inc."}
            ],
            "actions": [
                {"action": "set-attribute", "path": "driver", "value": "idrac"},
                {"action": "set-attribute", "path": "driver_info/drac_username",
                 "value": "SampleUsername"},
                {"action": "set-attribute", "path": "driver_info/drac_password",
                 "value": "RedactedSecurePassword"},
                {"action": "set-attribute", "path": "driver_info/drac_address",
                 "value": "{data[inventory][bmc_address]}"}
            ]
        }
    ]
  2. 규칙을 ironic에 가져옵니다.

    $ openstack baremetal introspection rule import dell-drac-rules.json

6.4. 프로필에 노드 태그

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

유형설명

역할

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

플레이버

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

프로파일

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

노드

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

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

참고

대부분의 노드는 프로파일 자동 태그를 사용합니다. 자세한 내용은 부록 E. 자동 프로필 태깅을 참조하십시오.

노드를 특정 프로파일에 태그하려면 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 매개 변수를 설정합니다. 하드웨어에 따라 노드가 기본 BIOS 모드 대신 UEFI를 사용하여 부팅되도록 하기 위해 boot_mode 매개 변수를 uefi에 추가해야 할 수도 있습니다. 자세한 내용은 D.2절. “UEFI 부팅 모드”를 참조하십시오.

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

(undercloud) $ openstack overcloud profiles list

사용자 정의 역할 프로파일

사용자 정의 역할을 사용하는 경우 이러한 새 역할을 적용할 추가 플레이버 및 프로파일을 생성해야 할 수도 있습니다. 예를 들어 Networker 역할의 새 플레이버를 생성하려면 다음 명령을 실행합니다.

(undercloud) $ openstack flavor create --id auto --ram 4096 --disk 40 --vcpus 1 networker
(undercloud) $ openstack flavor set --property "cpu_arch"="x86_64" --property "capabilities:boot_option"="local" --property "capabilities:profile"="networker" networker

이 새 프로파일에 노드를 할당합니다.

(undercloud) $ openstack baremetal node set --property capabilities='profile:networker,boot_option:local' dad05b82-0c74-40bf-9d12-193184bfc72d

6.5. 노드의 Root 디스크 정의

일부 노드에서는 여러 디스크를 사용할 수 있습니다. 이러한 경우 director에서 프로비저닝 중에 root 디스크에 사용할 디스크를 식별해야 합니다.

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 장치를 식별하는 디스크의 일련 번호를 사용하여 오버클라우드 이미지를 배포할 드라이브를 지정합니다.

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

(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"
  }
]

이 예에서는 root 장치를 일련 번호가 61866da04f380d001ea4e13c12e36ad6인 디스크 2로 설정합니다. 이를 위해 노드 정의에 root_device 매개 변수를 변경해야 합니다.

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

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

이를 통해 director가 root 디스크로 사용할 특정 디스크를 쉽게 식별할 수 있습니다. 오버클라우드 생성을 시작하면 director가 이 노드를 프로비저닝하고 오버클라우드 이미지를 이 디스크에 작성합니다.

6.6. 환경 파일을 통한 오버클라우드 사용자 지정

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

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

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

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

중요

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

6.7. CLI 툴로 오버클라우드 생성

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

주의

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

오버클라우드 매개 변수 설정

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

표 6.2. 배포 매개 변수

매개 변수설명

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

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

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

표 6.3. 더 이상 사용되지 않는 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의 이후 버전에서 삭제될 예정입니다.

참고

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

(undercloud) $ openstack help overcloud deploy

6.8. 오버클라우드 생성에 환경 파일 추가

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

  • 각 역할 및 해당 플레이버당 노드의 크기입니다. 오버클라우드 생성에 이 정보를 포함하는 것이 중요합니다.
  • 컨테이너화된 OpenStack 서비스의 컨테이너 이미지 위치입니다. 이는 5장. 컨테이너 이미지 소스 구성 옵션 중 하나에서 생성된 파일입니다.
  • 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 /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
  -e /home/stack/templates/network-environment.yaml \
  -e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml \
  -e /home/stack/templates/ceph-custom-config.yaml \
  --ntp-server pool.ntp.org \

이 명령에는 다음 추가 옵션이 포함되어 있습니다.

--templates
/usr/share/openstack-tripleo-heat-templates의 Heat 템플릿 컬렉션을 기반으로 하여 오버클라우드를 생성합니다.
-e /home/stack/templates/node-info.yaml

각 역할에 사용할 노드 수와 flavor를 정의할 환경 파일을 추가합니다. 예:

parameter_defaults:
  OvercloudControllerFlavor: control
  OvercloudComputeFlavor: compute
  OvercloudCephStorageFlavor: ceph-storage
  ControllerCount: 3
  ComputeCount: 3
  CephStorageCount: 3
-e /home/stack/templates/overcloud_images.yaml
컨테이너 이미지 소스가 포함된 환경 파일을 추가합니다. 자세한 내용은 5장. 컨테이너 이미지 소스 구성를 참조하십시오.
-e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml

오버클라우드 배포에서 네트워크 분리를 초기화할 환경 파일을 추가합니다.

참고

network-isolation.j2.yaml는 이 템플릿의 Jinja2 버전입니다. openstack overcloud deploy 명령은 Jinja2 템플릿을 일반 YAML 파일로 렌더링합니다. 즉, openstack overcloud deploy 명령을 실행할 때 렌더링된 결과 YAML 파일 이름(이 경우 network-isolation.yaml)을 포함해야 합니다.

-e /home/stack/templates/network-environment.yaml
환경 파일을 추가하여 네트워크 분리를 사용자 지정합니다.
-e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml
Ceph Storage 서비스를 활성화 할 환경 파일을 추가합니다.
-e /home/stack/templates/ceph-custom-config.yaml
Ceph Storage 구성을 사용자 지정할 환경 파일을 추가합니다.
--ntp-server pool.ntp.org
시간 동기화에 NTP 서버를 사용합니다. 컨트롤러 노드 클러스터를 동기화 상태로 유지하려는 경우 필요합니다.

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

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

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

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

환경 파일 디렉터리 추가

--environment-directory 옵션을 사용하여 환경 파일이 포함된 디렉터리 전체를 추가할 수 있습니다. 배포 명령은 이 디렉터리에 있는 환경 파일을 먼저 숫자 순으로 처리한 다음 알파벳 순으로 처리합니다. 이 방법을 사용하는 경우 파일 이름과 함께 숫자 접두어를 사용하여 처리 순서를 지정하는 것이 좋습니다. 예를 들면 다음과 같습니다.

(undercloud) $ ls -1 ~/templates
00-node-info.yaml
10-network-isolation.yaml
20-network-environment.yaml
30-storage-environment.yaml
40-rhel-registration.yaml

다음 배포 명령을 실행하여 디렉터리를 추가합니다.

(undercloud) $ openstack overcloud deploy --templates --environment-directory ~/templates

응답 파일 사용

응답 파일은 템플릿과 환경 파일을 간편하게 추가할 수 있도록 하는 YAML 형식의 파일입니다. 응답 파일은 다음 매개 변수를 사용합니다.

templates
사용할 코어 Heat 템플릿 컬렉션으로 --templates 명령줄 옵션을 대체하는 역할을 합니다.
environments
추가할 환경 파일 목록으로 --environment-file (-e) 명령줄 옵션을 대체하는 역할을 합니다.

예를 들면 응답 파일에 다음이 포함될 수 있습니다.

templates: /usr/share/openstack-tripleo-heat-templates/
environments:
  - ~/templates/00-node-info.yaml
  - ~/templates/10-network-isolation.yaml
  - ~/templates/20-network-environment.yaml
  - ~/templates/30-storage-environment.yaml
  - ~/templates/40-rhel-registration.yaml

다음 배포 명령을 실행하여 응답 파일을 추가합니다.

(undercloud) $ openstack overcloud deploy --answers-file ~/answers.yaml

6.9. 오버클라우드 플랜 관리

openstack overcloud deploy 명령을 사용하지 않고, director에서 가져온 플랜을 관리할 수도 있습니다.

새 플랜을 생성하려면 stack 사용자로 다음 명령을 실행합니다.

(undercloud) $ openstack overcloud plan create --templates /usr/share/openstack-tripleo-heat-templates my-overcloud

이 명령을 실행하면 코어 Heat 템플릿 컬렉션의 플랜이 /usr/share/openstack-tripleo-heat-templates에 생성됩니다. director는 입력된 내용을 기반으로 하여 플랜에 이름을 지정합니다. 이 예의 경우 my-overcloud입니다. director는 이 이름을 오브젝트 스토리지 컨테이너, 워크플로우 환경 및 오버클라우드 스택 이름에 대한 레이블로 사용합니다.

다음 명령을 사용하여 환경 파일의 매개 변수를 추가합니다.

(undercloud) $ openstack overcloud parameters set my-overcloud ~/templates/my-environment.yaml

다음 명령을 사용하여 플랜을 배포합니다.

(undercloud) $ openstack overcloud plan deploy my-overcloud

다음 명령을 사용하여 기존 플랜을 삭제합니다.

(undercloud) $ openstack overcloud plan delete my-overcloud
참고

openstack overcloud deploy 명령은 기본적으로 이러한 명령을 모두 사용하여 기존 플랜을 제거하고, 환경 파일과 함께 새 플랜을 업로드하고, 플랜을 배포합니다.

6.10. 오버클라우드 템플릿 및 플랜 검증

오버클라우드 생성 또는 스택 업데이트를 실행하기 전에 Heat 템플릿 및 환경 파일에서 오류를 확인합니다.

렌더링된 템플릿 생성

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

(undercloud) $ openstack overcloud plan create --templates /usr/share/openstack-tripleo-heat-templates overcloud-validation
(undercloud) $ mkdir ~/overcloud-validation
(undercloud) $ cd ~/overcloud-validation
(undercloud) $ swift download overcloud-validation

다음에 나오는 검증 테스트에 ~/overcloud-validation에 있는 렌더링된 템플릿을 사용하십시오.

템플릿 구문 확인

다음 명령을 사용하여 템플릿 구문을 확인합니다.

(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 옵션을 추가하여 중첩된 템플릿에서 매개 변수를 해결합니다.

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

6.11. 오버클라우드 생성 모니터링

오버클라우드 생성 절차가 시작되고 director에서 노드를 프로비저닝합니다. 이 프로세스는 완료하는 데 시간이 걸립니다. 오버클라우드 생성 상태를 보려면 별도의 터미널을 stack 사용자로 열고 다음을 실행합니다.

(undercloud) $ source ~/stackrc
(undercloud) $ openstack stack list --nested

openstack stack list --nested 명령을 실행하면 오버클라우드 생성의 현재 단계가 표시됩니다.

6.12. 오버클라우드 액세스

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.13. 오버클라우드 생성 완료

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