베어 메탈 프로비저닝

Red Hat OpenStack Platform 16.1

베어 메탈 서비스(ironic) 설치, 구성 및 사용

초록

Red Hat OpenStack Platform 환경의 오버클라우드에서 베어 메탈 프로비저닝 서비스를 설치, 구성 및 사용합니다.

preface

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

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

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

문서 개선을 위한 의견을 보내 주십시오. Red Hat이 어떻게 이를 개선하는지 알려주십시오.

DDF(직접 문서 피드백) 기능 사용

특정 문장, 단락 또는 코드 블록에 대한 직접 주석은 피드백 추가 DDF 기능을 사용하십시오.

  1. 다중 페이지 HTML 형식으로 설명서를 봅니다.
  2. 문서 오른쪽 상단에 Feedback (피드백) 버튼이 표시되는지 확인합니다.
  3. 주석 처리하려는 텍스트 부분을 강조 표시합니다.
  4. 피드백 추가를 클릭합니다.
  5. 주석을 사용하여 Add Feedback (피드백 추가) 필드를 작성합니다.
  6. 선택 사항: 설명서 팀이 문제에 대한 자세한 내용을 문의할 수 있도록 이메일 주소를 추가하십시오.
  7. Submit(제출)을 클릭합니다.

1장. 베어 메탈 프로비저닝 서비스

베어 메탈 프로비저닝 서비스(ironic)는 최종 사용자의 물리적 시스템을 프로비저닝 및 관리하는 데 사용할 수 있는 구성 요소를 제공합니다. 오버클라우드의 베어 메탈 프로비저닝 서비스는 다음 OpenStack 서비스와 상호 작용합니다.

  • OpenStack Compute(nova)는 가상 시스템 인스턴스 관리를 위한 스케줄링, 테넌트 할당량, IP 할당 및 사용자 지원 API를 제공하는 반면, 베어 메탈 프로비저닝 서비스는 하드웨어 관리를 위한 관리 API를 제공합니다.
  • OpenStack Identity(keystone)는 요청 인증을 제공하고 베어 메탈 프로비저닝 서비스를 지원하여 다른 OpenStack 서비스를 찾습니다.
  • OpenStack Image 서비스(glance)는 이미지 및 이미지 메타데이터를 관리합니다.
  • OpenStack Networking(neutron)에서는 DHCP 및 네트워크 구성을 제공합니다.
  • OpenStack Object Storage(swift)는 일부 드라이버의 임시 이미지 URL을 노출합니다.

베어 메탈 프로비저닝 서비스는 iPXE를 사용하여 실제 시스템을 프로비저닝합니다. 다음 다이어그램에서는 기본 드라이버로 새 시스템을 시작할 때 배포 프로세스 중에 OpenStack 서비스가 상호 작용하는 방법을 간략하게 설명합니다.

The PXE Provisioning Process

최종 사용자의 물리적 시스템을 프로비저닝하고 관리하도록 오버클라우드에서 베어 메탈 프로비저닝 서비스(ironic)를 구성할 수 있습니다.

RHOSP(Red Hat OpenStack Platform) director는 또한 베어 메탈 프로비저닝 서비스 구성 요소를 언더클라우드의 일부로 사용하여 OpenStack 환경인 오버클라우드를 구성하는 베어 메탈 노드를 프로비저닝하고 관리합니다. director가 베어 메탈 프로비저닝 서비스를 사용하는 방법에 대한 자세한 내용은 Director 설치 및 사용 가이드를 참조하십시오.

2장. 베어 메탈 프로비저닝 사전 요구 사항

베어 메탈 프로비저닝을 시작하기 전에 환경에 필요한 설치, 하드웨어 및 네트워킹 구성이 포함되어 있는지 확인합니다.

2.1. 설치 요구 사항

  • 언더클라우드 노드에 director를 설치했습니다. director 설치에 대한 자세한 내용은 Undercloud 설치를 참조하십시오.
  • 나머지 오버클라우드와 함께 베어 메탈 프로비저닝 서비스를 설치할 준비가 되었습니다.
참고

베어 메탈 노드에 RHOSP(Red Hat OpenStack Platform) 설치의 컨트롤 플레인 네트워크에 직접 액세스할 수 있으므로 오버클라우드의 베어 메탈 프로비저닝 서비스는 신뢰할 수 있는 테넌트 환경을 위해 설계되었습니다. 사용자가 컨트롤 플레인에 액세스할 필요가 없도록 오버클라우드에서 Ironic 서비스에 대한 사용자 지정 구성 가능 네트워크를 구현할 수도 있습니다.

2.2. 하드웨어 요구 사항

오버클라우드 요구 사항

베어 메탈 프로비저닝 서비스가 있는 오버클라우드의 하드웨어 요구 사항은 표준 오버클라우드와 동일합니다. 자세한 내용은 Director 설치 및 사용 가이드의 Overcloud 요구 사항을 참조하십시오.

베어 메탈 머신 요구 사항

프로비저닝하려는 베어 메탈 시스템의 하드웨어 요구 사항은 설치하려는 운영 체제에 따라 다릅니다.

프로비저닝하려는 모든 베어 메탈 머신에는 다음이 필요합니다.

  • 베어 메탈 네트워크에 연결하는 NIC입니다.
  • ironic-conductor 서비스에서 연결할 수 있는 네트워크에 연결된 전원 관리 인터페이스(예: IPMI)입니다. 기본적으로 ironic-conductor 는 구성 가능 역할을 사용하고 ironic-conductor 를 다른 위치에서 실행하지 않는 한 모든 컨트롤러 노드에서 실행됩니다.
  • 베어 메탈 네트워크에서 PXE 부팅. 배포의 다른 모든 NIC에서 PXE 부팅을 비활성화합니다.

2.3. 네트워킹 요구사항

베어 메탈 네트워크:

이 네트워크는 베어 메탈 프로비저닝 서비스에서 다음 작업에 사용하는 사설 네트워크입니다.

  • 오버클라우드의 베어 메탈 머신 프로비저닝 및 관리.
  • 배포 전후에 베어 메탈 노드 정리.
  • 베어 메탈 노드에 대한 테넌트 액세스.

베어 메탈 네트워크는 베어 메탈 시스템을 검색할 수 있는 DHCP 및 PXE 부팅 기능을 제공합니다. 베어 메탈 프로비저닝 서비스에서 PXE 부팅 및 DHCP 요청을 제공할 수 있도록 트렁크된 인터페이스에서 기본 VLAN을 사용해야 합니다.

베어 메탈 네트워크는 다음 두 가지 방법으로 구성할 수 있습니다.

  • Ironic Conductor 서비스에 대해 플랫 베어 메탈 네트워크를 사용합니다. 이 네트워크는 컨트롤 플레인의 Ironic 서비스로 라우팅해야 합니다. 격리된 베어 메탈 네트워크를 정의하는 경우 베어 메탈 노드는 PXE 부팅할 수 없습니다.
  • 사용자 지정 구성 가능 네트워크를 사용하여 Overcloud에서 베어 메탈 프로비저닝 서비스를 구현합니다.
참고

베어 메탈 노드에 RHOSP(Red Hat OpenStack Platform) 설치의 컨트롤 플레인 네트워크에 직접 액세스할 수 있으므로 오버클라우드의 베어 메탈 프로비저닝 서비스는 신뢰할 수 있는 테넌트 환경을 위해 설계되었습니다. 사용자가 컨트롤 플레인에 액세스할 필요가 없도록 오버클라우드에서 Ironic 서비스에 대한 사용자 지정 구성 가능 네트워크를 구현할 수도 있습니다.

네트워크 태그:

  • 컨트롤 플레인 네트워크( director 프로비저닝 네트워크)는 항상 태그가 지정되지 않습니다.
  • 프로비저닝을 위해 베어 메탈 네트워크에 태그를 지정 해제해야 하며 Ironic API에 대한 액세스 권한이 있어야 합니다.
  • 다른 네트워크에는 태그를 지정할 수 있습니다.

Overcloud 컨트롤러:

베어 메탈 프로비저닝 서비스를 호스팅하는 컨트롤러 노드에서 베어 메탈 네트워크에 액세스할 수 있어야 합니다.

베어 메탈 노드:

베어 메탈 노드가 PXE 부팅으로 구성된 NIC는 베어 메탈 네트워크에 액세스할 수 있어야 합니다.

2.3.1. 기본 베어 메탈 네트워크

이 아키텍처에서 베어 메탈 네트워크는 컨트롤 플레인 네트워크와 분리됩니다. 베어 메탈 네트워크는 테넌트 네트워크 역할을 하는 플랫 네트워크입니다.

  • 베어 메탈 네트워크는 OpenStack 운영자가 생성합니다. 이 네트워크에는 director 프로비저닝 네트워크에 대한 경로가 필요합니다.
  • 베어 메탈 프로비저닝 서비스 사용자는 퍼블릭 OpenStack API 및 베어 메탈 네트워크에 액세스할 수 있습니다. 베어 메탈 네트워크는 director 프로비저닝 네트워크로 라우팅되므로 사용자는 컨트롤 플레인에 대한 간접 액세스도 갖습니다.
  • 베어 메탈 프로비저닝 서비스는 노드 정리에 베어 메탈 네트워크를 사용합니다.

기본 베어 메탈 네트워크 아키텍처 다이어그램

Default bare metal network architecture diagram

2.3.2. 사용자 정의 구성 가능 베어 메탈 네트워크

이 아키텍처에서 베어 메탈 네트워크는 컨트롤 플레인에 대한 액세스 권한이 없는 사용자 지정 구성 가능한 네트워크입니다. 컨트롤 플레인에 대한 액세스를 제한하려면 사용자 정의 구성 가능 네트워크를 생성할 수 있습니다.

  • 사용자 지정 구성 가능 베어 메탈 네트워크는 OpenStack 운영자가 생성합니다.
  • Ironic 사용자는 퍼블릭 OpenStack API 및 사용자 지정 구성 가능 베어 메탈 네트워크에 액세스할 수 있습니다.
  • Ironic에서는 노드 정리를 위해 사용자 지정 구성 가능 베어 메탈 네트워크를 사용합니다.

3장. 베어 메탈 프로비저닝 서비스를 사용하여 IPv4 오버클라우드 배포

참고

OVN을 사용하는 경우 베어 메탈 프로비저닝 서비스(ironic)는 ironic-overcloud.yaml 파일의 neutron DHCP 에이전트에서만 지원됩니다. OVN의 기본 제공 DHCP 서버는 현재 베어 메탈 노드를 프로비저닝하거나 프로비저닝 네트워크의 DHCP를 제공할 수 없습니다. chainbooting iPXE에는 OVN DHCP 서버에서 지원되지 않는 태그 지정(--dhcp 일치)이 필요합니다.

다음 절차에는 베어 메탈 프로비저닝 서비스(ironic)와 관련된 배포 단계가 포함되어 있습니다. director를 사용한 오버클라우드 배포에 대한 자세한 내용은 Director 설치 및 사용 가이드를 참조하십시오.

사전 요구 사항

3.1. 베어 메탈 템플릿 생성

환경 파일을 사용하여 베어 메탈 프로비저닝 서비스가 활성화된 Overcloud를 배포합니다. /usr/share/openstack-tripleo-heat-templates/environments/services/ironic-overcloud.yaml 의 director 노드에 있는 템플릿 예제를 사용할 수 있습니다.

사전 요구 사항

템플릿 완료

제공된 템플릿 또는 추가 yaml 파일에서 추가 구성을 지정할 수 있습니다(예: ~/templates/ironic.yaml ).

  • 베어 메탈 및 가상 인스턴스가 모두 포함된 하이브리드 배포의 경우 AggregateInstanceExtraSpecsFilterNovaSchedulerDefaultFilter 목록에 추가해야 합니다. NovaSchedulerDefaultFilters 를 어디에서나 설정하지 않은 경우 ironic.yaml 에서 이를 수행할 수 있습니다. 예를 들어 템플릿 예시 를 참조하십시오.

    참고

    SR-IOV를 사용하는 경우 NovaSchedulerDefaultFilters 는 이미 tripleo-heat-templates/environments/neutron-sriov.yaml 에 설정되어 있습니다. AggregateInstanceExtraSpecsFilter 를 이 목록에 추가합니다.

  • 배포 전후에 발생하는 정리 유형은 IronicingDiskErase 에 의해 설정됩니다. 기본적으로 deployment/ironic/ironic-conductor-container-puppet.yaml 에 의해 full 로 설정됩니다. 파티션 테이블만 정리하므로 이를 메타데이터 로 설정하여 프로세스 속도를 크게 높일 수 있습니다. 그러나 배포는 멀티 테넌트 환경에서 덜 안전하지 않으므로 신뢰할 수 있는 테넌트 환경에서만 이 작업을 완료합니다.
  • IronicEnabledHardwareTypes 매개 변수를 사용하여 드라이버를 추가할 수 있습니다. 기본적으로 ipmiredfish 는 활성화되어 있습니다.

구성 매개 변수의 전체 목록은 Overcloud Parameters 가이드의 베어 메탈 을 참조하십시오.

3.1.1. 템플릿 예

다음은 템플릿 파일의 예입니다. 이 파일은 환경의 요구 사항을 충족하지 못할 수 있습니다. 이 예제를 사용하기 전에 환경의 기존 구성을 방해하지 않는지 확인합니다. 이 예제에는 다음 구성이 포함되어 있습니다.

  • AggregateInstanceExtraSpecsFilter 는 하이브리드 배포를 위해 가상 및 베어 메탈 인스턴스를 모두 허용합니다.
  • 배포 전후에 수행되는 디스크 정리는 파티션 테이블(메타데이터)만 지웁니다.

~/templates/ironic.yaml

parameter_defaults:

    NovaSchedulerDefaultFilters:
        - AggregateInstanceExtraSpecsFilter
        - AvailabilityZoneFilter
        - ComputeFilter
        - ComputeCapabilitiesFilter
        - ImagePropertiesFilter

    IronicCleaningDiskErase: metadata

3.2. 네트워크 설정

기본 플랫 베어 메탈 네트워크를 사용하는 경우 사용할 Bare Metal Provisioning 서비스(ironic)에 대한 브리지 br-baremetal 을 생성해야 합니다. 추가 템플릿에서 이 브릿지를 지정할 수 있습니다.

~/templates/network-environment.yaml

parameter_defaults:
  NeutronBridgeMappings: datacentre:br-ex,baremetal:br-baremetal
  NeutronFlatNetworks: datacentre,baremetal

이 브리지를 컨트롤러의 프로비저닝 네트워크(컨트롤 플레인)에서 구성하여 이 네트워크를 베어 메탈 네트워크로 재사용하거나 전용 네트워크를 추가할 수 있습니다. 구성 요구 사항은 동일하지만 베어 메탈 네트워크는 프로비저닝에 사용되므로 VLAN 태그 지정을 수행할 수 없습니다.

~/templates/nic-configs/controller.yaml

network_config:
    -
      type: ovs_bridge
          name: br-baremetal
          use_dhcp: false
          members:
            -
              type: interface
              name: eth1
참고

베어 메탈 노드에 RHOSP(Red Hat OpenStack Platform) 설치의 컨트롤 플레인 네트워크에 직접 액세스할 수 있으므로 오버클라우드의 베어 메탈 프로비저닝 서비스는 신뢰할 수 있는 테넌트 환경을 위해 설계되었습니다.

3.2.1. 사용자 지정 IPv4 프로비저닝 네트워크 구성

테넌트가 Undercloud 네트워크를 방해할 수 있으므로 기본 플랫 프로비저닝 네트워크는 고객 환경에 보안 문제가 발생할 수 있습니다. 이러한 위험을 방지하기 위해 컨트롤 플레인에 액세스할 수 없는 ironic 서비스에 대해 사용자 정의 구성 가능 베어 메탈 프로비저닝 네트워크를 구성할 수 있습니다.

사전 요구 사항

절차

  1. ID 서비스(keystone)에 관리 사용자로 액세스하도록 쉘을 구성합니다.

    $ source ~/stackrc
  2. network_data.yaml 파일을 복사합니다.

    (undercloud) [stack@host01 ~]$ cp /usr/share/openstack-tripleo-heat-templates/network_data.yaml .
  3. network_data.yaml 파일을 편집하고 IPv4 오버클라우드 프로비저닝을 위한 새 네트워크를 추가합니다.

    # custom network for overcloud provisioning
    - name: OcProvisioning
    name_lower: oc_provisioning
    vip: true
    vlan: 205
    ip_subnet: '172.23.3.0/24'
    allocation_pools: [{'start': '172.23.3.10', 'end': '172.23.3.200'}]
  4. 네트워크를 사용하도록 network_environments.yamlnic-configs/controller.yaml 파일을 업데이트합니다.

    1. network_environments.yaml 파일에서 Ironic 네트워크를 다시 매핑합니다.

      ServiceNetMap:
         IronicApiNetwork: oc_provisioning
         IronicNetwork: oc_provisioning
    2. nic-configs/controller.yaml 파일에서 인터페이스 및 필요한 매개변수를 추가합니다.

      $network_config:
           - type: vlan
               vlan_id:
                 get_param: OcProvisioningNetworkVlanID
               addresses:
               - ip_netmask:
                   get_param: OcProvisioningIpSubnet
  5. roles_data.yaml 파일을 복사합니다.

    (undercloud) [stack@host01 ~]$ cp /usr/share/openstack-tripleo-heat-templates/roles_data.yaml .
  6. roles_data.yaml 을 편집하고 컨트롤러에 대한 새 네트워크를 추가합니다.

      networks:
       ...
        OcProvisioning:
          subnet: oc_provisioning_subnet
  7. deploy 명령에 새 network_data.yamlroles_data.yaml 파일을 포함합니다.

    -n /home/stack/network_data.yaml \
    -r /home/stack/roles_data.yaml \

3.3. 오버클라우드에서 베어 메탈 인트로스펙션 활성화

베어 메탈 인트로스펙션을 활성화하려면 배포 명령에 다음 파일을 모두 포함합니다.

OVN을 사용하는 배포의 경우
  • ironic-overcloud.yaml
  • ironic-inspector.yaml
참고

스파인-리프 경로 배포에는 ToR 라우터에 DHCP 릴레이 또는 각 서브넷의 DHCP 에이전트가 필요할 수 있습니다. 메타데이터 서비스에는 메타데이터 서버의 정적 경로가 있어야 합니다. OVN은 기본적으로 베어 메탈 노드에서 이 경로를 제공하지 않습니다.

OVS를 사용하는 배포의 경우
  • ironic.yaml
  • ironic-inspector.yaml

이러한 파일은 /usr/share/openstack-tripleo-heat-templates/environments/services 디렉터리에서 찾을 수 있습니다. 다음 예제를 사용하여 환경에 해당하는 ironic 검사기에 대한 구성 세부 정보를 포함합니다.

parameter_defaults:
  IronicInspectorSubnets:
    - ip_range: <ip_range>
  IPAImageURLs: '["http://<ip_address>:<port>/agent.kernel", "http://<ip_address>:<port>/agent.ramdisk"]'
  IronicInspectorInterface: 'br-baremetal'

IronicInspectorSubnets

이 매개변수는 여러 범위를 포함할 수 있으며 스파인 및 리프팅 모두 사용할 수 있습니다.

IPAImageURLs

이 매개 변수에는 IPA 커널 및 ramdisk에 대한 세부 정보가 포함되어 있습니다. 대부분의 경우 언더클라우드에서 사용하는 것과 동일한 이미지를 사용할 수 있습니다. 이 매개변수를 생략하면 각 컨트롤러에 대체 항목이 포함되어야 합니다.

IronicInspectorInterface

베어 메탈 네트워크 인터페이스를 지정하려면 이 매개변수를 사용합니다.

참고

구성 가능한 Ironic 또는 IronicConductor 역할을 사용하는 경우 역할 파일의 Ironic 역할에 IronicInspector 서비스를 포함해야 합니다.

ServicesDefault:
  OS::TripleO::Services::IronicInspector

3.4. 오버클라우드 배포

베어 메탈 프로비저닝 서비스를 활성화하려면 나머지 오버클라우드 구성과 함께 오버클라우드를 배포하거나 재배포할 때 -e 옵션을 사용하여 ironic 환경 파일을 포함합니다. 다음 예제를 가이드로 사용합니다.

$ 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 /usr/share/openstack-tripleo-heat-templates/environments/services/ironic-overcloud.yaml \
  -e ~/templates/ironic.yaml \

추가 리소스

3.5. 베어 메탈 프로비저닝 서비스 테스트

OpenStack Integration Test Suite를 사용하여 Red Hat OpenStack 배포를 검증할 수 있습니다. 자세한 내용은 OpenStack Integration Test Suite Guide를 참조하십시오.

베어 메탈 프로비저닝 서비스에 대한 추가 확인 방법은 다음과 같습니다.

  1. 관리 사용자로 Identity에 액세스하도록 쉘을 구성합니다.

    $ source ~/overcloudrc
  2. nova-compute 서비스가 컨트롤러 노드에서 실행 중인지 확인합니다.

    $ openstack compute service list -c Binary -c Host -c Status
  3. 기본 ironic 드라이버를 변경한 경우 필요한 드라이버가 활성화되어 있는지 확인합니다.

    $ openstack baremetal driver list
  4. ironic 끝점이 나열되어 있는지 확인합니다.

    $ openstack catalog list

4장. 베어 메탈 프로비저닝 서비스를 사용하여 IPv6 오버클라우드 배포

참고

OVN을 사용하는 경우 베어 메탈 프로비저닝 서비스(ironic)는 ironic-overcloud.yaml 파일의 neutron DHCP 에이전트에서만 지원됩니다. OVN의 기본 제공 DHCP 서버는 현재 베어 메탈 노드를 프로비저닝하거나 프로비저닝 네트워크의 DHCP를 제공할 수 없습니다. chainbooting iPXE에는 OVN DHCP 서버에서 지원되지 않는 태그 지정(--dhcp 일치)이 필요합니다.

다음 절차에는 베어 메탈 프로비저닝 서비스(ironic)와 관련된 배포 단계가 포함되어 있습니다. director를 사용한 오버클라우드 배포에 대한 자세한 내용은 Director 설치 및 사용 가이드를 참조하십시오.

사전 요구 사항

4.1. 베어 메탈 템플릿 생성

환경 파일을 사용하여 베어 메탈 프로비저닝 서비스가 활성화된 Overcloud를 배포합니다. /usr/share/openstack-tripleo-heat-templates/environments/services/ironic-overcloud.yaml 의 director 노드에 있는 템플릿 예제를 사용할 수 있습니다.

사전 요구 사항

템플릿 완료

제공된 템플릿 또는 추가 yaml 파일에서 추가 구성을 지정할 수 있습니다(예: ~/templates/ironic.yaml ).

  • 베어 메탈 및 가상 인스턴스가 모두 포함된 하이브리드 배포의 경우 AggregateInstanceExtraSpecsFilterNovaSchedulerDefaultFilter 목록에 추가해야 합니다. NovaSchedulerDefaultFilters 를 어디에서나 설정하지 않은 경우 ironic.yaml 에서 이를 수행할 수 있습니다. 예를 들어 템플릿 예시 를 참조하십시오.

    참고

    SR-IOV를 사용하는 경우 NovaSchedulerDefaultFilters 는 이미 tripleo-heat-templates/environments/neutron-sriov.yaml 에 설정되어 있습니다. AggregateInstanceExtraSpecsFilter 를 이 목록에 추가합니다.

  • 배포 전후에 발생하는 정리 유형은 IronicingDiskErase 에 의해 설정됩니다. 기본적으로 deployment/ironic/ironic-conductor-container-puppet.yaml 에 의해 full 로 설정됩니다. 파티션 테이블만 정리하므로 이를 메타데이터 로 설정하여 프로세스 속도를 크게 높일 수 있습니다. 그러나 배포는 멀티 테넌트 환경에서 덜 안전하지 않으므로 신뢰할 수 있는 테넌트 환경에서만 이 작업을 완료합니다.
  • IronicEnabledHardwareTypes 매개 변수를 사용하여 드라이버를 추가할 수 있습니다. 기본적으로 ipmiredfish 는 활성화되어 있습니다.

구성 매개 변수의 전체 목록은 Overcloud Parameters 가이드의 베어 메탈 을 참조하십시오.

4.1.1. 템플릿 예

다음은 템플릿 파일의 예입니다. 이 파일은 환경의 요구 사항을 충족하지 못할 수 있습니다. 이 예제를 사용하기 전에 환경의 기존 구성을 방해하지 않는지 확인합니다. 이 예제에는 다음 구성이 포함되어 있습니다.

  • AggregateInstanceExtraSpecsFilter 는 하이브리드 배포를 위해 가상 및 베어 메탈 인스턴스를 모두 허용합니다.
  • 배포 전후에 수행되는 디스크 정리는 파티션 테이블(메타데이터)만 지웁니다.

~/templates/ironic.yaml

parameter_defaults:

    NovaSchedulerDefaultFilters:
        - AggregateInstanceExtraSpecsFilter
        - AvailabilityZoneFilter
        - ComputeFilter
        - ComputeCapabilitiesFilter
        - ImagePropertiesFilter

    IronicCleaningDiskErase: metadata

4.2. IPv6을 통해 베어 메탈 프로비저닝의 언더클라우드 설정

IPv6 노드 및 인프라가 있는 경우, IPv4 대신 IPv6를 사용하도록 언더클라우드 및 프로비저닝 네트워크를 구성하여 director에서 Red Hat OpenStack Platform을 IPv6 노드에 프로비저닝하고 배포할 수 있습니다. 여기에는 몇 가지 고려 사항이 있습니다.

  • Dual stack IPv4/6을 사용할 수 없습니다.
  • Tempest 검증이 제대로 수행되지 않을 수 있습니다.
  • IPv4에서 IPv6으로 마이그레이션은 업그레이드중에는 사용할 수 없습니다.

undercloud.conf 파일을 수정하여 Red Hat OpenStack Platform에서 IPv6 프로비저닝을 활성화합니다.

사전 요구 사항

절차

  1. 샘플 undercloud.conf 파일을 복사하거나 기존 undercloud.conf 파일을 수정하십시오.
  2. undercloud.conf 파일에 다음 매개변수 값을 설정합니다.

    1. NIC에서 Red Hat OpenStack Platform과 stateful DHCPv6을 지원하는 경우 ipv6_address_modedhcpv6-stateless 또는 dhcpv6-stateful로 설정합니다.
    2. 언더클라우드가 프로비저닝 네트워크에서 라우터를 생성하지 않게 하려면 enable_routed_networkstrue로 설정합니다. 이 경우 데이터 센터 라우터에서 라우터 알림을 제공해야 합니다. 그렇지 않으면 이 값을 false로 설정합니다.
    3. local_ip를 언더클라우드의 IPv6 주소로 설정합니다.
    4. 언더클라우드 인터페이스 매개변수 undercloud_public_hostundercloud_admin_host로 IPv6 주소를 사용합니다.
    5. 상태 저장 주소 지정 모델을 사용하는 경우 펌웨어, 체인 로더 및 운영 체제는 서로 다른 알고리즘을 사용하여 DHCP 서버에서 추적하는 ID를 생성할 수 있습니다. DHCPv6에서는 MAC별 주소를 추적하지 않으며 요청자의 식별자 값이 변경되었지만 MAC 주소는 동일하게 유지됩니다. stateful DHCPv6을 사용하려면 ironic_enabled_network_interfaces 매개변수를 사용하여 neutron 인터페이스를 지정합니다. ironic_default_network_interface 매개변수를 사용하여 neutron 인터페이스를 베어 메탈 노드의 기본 네트워크 인터페이스로 설정할 수도 있습니다.

      • ironic_enabled_network_interfaces = neutron,flat
      • ironic_default_network_interface = neutron
    6. [ctlplane-subnet] 섹션에서 다음 매개변수의 IPv6 주소를 사용합니다.

      • cidr
      • dhcp_start
      • dhcp_end
      • gateway
      • inspection_iprange
    7. [ctlplane-subnet] 섹션에서 dns_nameservers 매개변수에 서브넷의 IPv6 네임 서버를 설정합니다.

      [DEFAULT]
      ipv6_address_mode = dhcpv6-stateless
      enable_routed_networks: false
      local_ip = <ipv6-address>
      ironic_enabled_network_interfaces = neutron,flat
      ironic_default_network_interface = neutron
      undercloud_admin_host = <ipv6-address>
      undercloud_public_host = <ipv6-address>
      
      [ctlplane-subnet]
      cidr = <ipv6-address>::<ipv6-mask>
      dhcp_start = <ipv6-address>
      dhcp_end = <ipv6-address>
      dns_nameservers = <ipv6-dns>
      gateway = <ipv6-address>
      inspection_iprange = <ipv6-address>,<ipv6-address>

4.3. 네트워크 설정

기본 플랫 베어 메탈 네트워크를 사용하는 경우 사용할 Bare Metal Provisioning 서비스(ironic)에 대한 브리지 br-baremetal 을 생성해야 합니다. 추가 템플릿에서 이 브릿지를 지정할 수 있습니다.

~/templates/network-environment.yaml

parameter_defaults:
  NeutronBridgeMappings: datacentre:br-ex,baremetal:br-baremetal
  NeutronFlatNetworks: datacentre,baremetal

이 브리지를 컨트롤러의 프로비저닝 네트워크(컨트롤 플레인)에서 구성하여 이 네트워크를 베어 메탈 네트워크로 재사용하거나 전용 네트워크를 추가할 수 있습니다. 구성 요구 사항은 동일하지만 베어 메탈 네트워크는 프로비저닝에 사용되므로 VLAN 태그 지정을 수행할 수 없습니다.

~/templates/nic-configs/controller.yaml

network_config:
    -
      type: ovs_bridge
          name: br-baremetal
          use_dhcp: false
          members:
            -
              type: interface
              name: eth1
참고

베어 메탈 노드에 RHOSP(Red Hat OpenStack Platform) 설치의 컨트롤 플레인 네트워크에 직접 액세스할 수 있으므로 오버클라우드의 베어 메탈 프로비저닝 서비스는 신뢰할 수 있는 테넌트 환경을 위해 설계되었습니다.

4.3.1. 사용자 지정 IPv6 프로비저닝 네트워크 구성

사용자 지정 IPv6 프로비저닝 네트워크를 생성하여 IPv6에서 Overcloud를 프로비저닝하고 배포합니다.

절차

  1. 관리 사용자로 Identity에 액세스하도록 쉘을 구성합니다.

    $ source ~/stackrc
  2. network_data.yaml 파일을 복사합니다.

    $ cp /usr/share/openstack-tripleo-heat-templates/network_data.yaml .
  3. network_data.yaml 파일을 편집하고 오버클라우드 프로비저닝을 위한 새 네트워크를 추가합니다.

    # custom network for IPv6 overcloud provisioning
    - name: OcProvisioningIPv6
    vip: true
    name_lower: oc_provisioning_ipv6
    vlan: 10
    ipv6: true
    ipv6_subnet: '$IPV6_SUBNET_ADDRESS/$IPV6_MASK'
    ipv6_allocation_pools: [{'start': '$IPV6_START_ADDRESS', 'end': '$IPV6_END_ADDRESS'}]
    gateway_ipv6: '$IPV6_GW_ADDRESS'
    • $IPV6_ADDRESS 를 IPv6 서브넷의 IPv6 주소로 바꿉니다.
    • $IPV6_MASK 를 IPv6 서브넷의 IPv6 네트워크 마스크로 바꿉니다.
    • $IPV6_START_ADDRESS$IPV6_END_ADDRESS 를 주소 할당에 사용하려는 IPv6 범위로 바꿉니다.
    • $IPV6_GW_ADDRESS 를 게이트웨이의 IPv6 주소로 바꿉니다.
  4. 새 파일 network-environment.yaml 을 생성하고 provisioning 네트워크의 IPv6 설정을 정의합니다.

    $ touch /home/stack/network-environment.yaml`
    1. 새로운 IPv6 프로비저닝 네트워크를 사용하도록 ironic 네트워크를 다시 매핑합니다.

      ServiceNetMap:
         IronicApiNetwork: oc_provisioning_ipv6
         IronicNetwork: oc_provisioning_ipv6
    2. IronicIpVersion 매개변수를 6 으로 설정합니다.

      parameter_defaults:
        IronicIpVersion: 6
    3. RabbitIPv6,MysqlIPv6RedisIPv6 매개변수를 True 로 설정합니다.

      parameter_defaults:
        RabbitIPv6: True
        MysqlIPv6: True
        RedisIPv6: True
  5. 인터페이스와 필요한 매개변수를 nic-configs/controller.yaml 파일에 추가합니다.

    $network_config:
         - type: vlan
             vlan_id:
               get_param: OcProvisioningIPv6NetworkVlanID
             addresses:
             - ip_netmask:
                 get_param: OcProvisioningIPv6IpSubnet
  6. roles_data.yaml 파일을 복사합니다.

    (undercloud) [stack@host01 ~]$ cp /usr/share/openstack-tripleo-heat-templates/roles_data.yaml .
  7. roles_data.yaml 을 편집하고 컨트롤러에 대한 새 네트워크를 추가합니다.

      networks:
       ...
        - OcProvisioningIPv6

오버클라우드를 배포할 때 -n 및 - r 옵션을 사용하여 배포 명령에 새 network _data.yaml 파일, - e 옵션을 사용하여 network-environment.yaml 파일을 포함합니다.

$ sudo openstack overcloud deploy --templates \
...
-n /home/stack/network_data.yaml \
-r /home/stack/roles_data.yaml \
-e /home/stack/network-environment.yaml
...

IPv6 네트워크 구성에 대한 자세한 내용은 IPv6 Networking for the Overcloud 가이드의 네트워크 구성을 참조하십시오.

4.4. 오버클라우드에서 베어 메탈 인트로스펙션 활성화

베어 메탈 인트로스펙션을 활성화하려면 배포 명령에 다음 파일을 모두 포함합니다.

OVN을 사용하는 배포의 경우
  • ironic-overcloud.yaml
  • ironic-inspector.yaml
참고

스파인-리프 경로 배포에는 ToR 라우터에 DHCP 릴레이 또는 각 서브넷의 DHCP 에이전트가 필요할 수 있습니다. 메타데이터 서비스에는 메타데이터 서버의 정적 경로가 있어야 합니다. OVN은 기본적으로 베어 메탈 노드에서 이 경로를 제공하지 않습니다.

OVS를 사용하는 배포의 경우
  • ironic.yaml
  • ironic-inspector.yaml

이러한 파일은 /usr/share/openstack-tripleo-heat-templates/environments/services 디렉터리에서 찾을 수 있습니다. 다음 예제를 사용하여 환경에 해당하는 ironic 검사기에 대한 구성 세부 정보를 포함합니다.

parameter_defaults:
  IronicInspectorSubnets:
    - ip_range: <ip_range>
  IPAImageURLs: '["http://<ip_address>:<port>/agent.kernel", "http://<ip_address>:<port>/agent.ramdisk"]'
  IronicInspectorInterface: 'br-baremetal'

IronicInspectorSubnets

이 매개변수는 여러 범위를 포함할 수 있으며 스파인 및 리프팅 모두 사용할 수 있습니다.

IPAImageURLs

이 매개 변수에는 IPA 커널 및 ramdisk에 대한 세부 정보가 포함되어 있습니다. 대부분의 경우 언더클라우드에서 사용하는 것과 동일한 이미지를 사용할 수 있습니다. 이 매개변수를 생략하면 각 컨트롤러에 대체 항목이 포함되어야 합니다.

IronicInspectorInterface

베어 메탈 네트워크 인터페이스를 지정하려면 이 매개변수를 사용합니다.

참고

구성 가능한 Ironic 또는 IronicConductor 역할을 사용하는 경우 역할 파일의 Ironic 역할에 IronicInspector 서비스를 포함해야 합니다.

ServicesDefault:
  OS::TripleO::Services::IronicInspector

4.5. 오버클라우드 배포

베어 메탈 프로비저닝 서비스를 활성화하려면 나머지 오버클라우드 구성과 함께 오버클라우드를 배포하거나 재배포할 때 -e 옵션을 사용하여 ironic 환경 파일을 포함합니다. 다음 예제를 가이드로 사용합니다.

$ 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 /usr/share/openstack-tripleo-heat-templates/environments/services/ironic-overcloud.yaml \
  -e ~/templates/ironic.yaml \

추가 리소스

4.6. 베어 메탈 프로비저닝 서비스 테스트

OpenStack Integration Test Suite를 사용하여 Red Hat OpenStack 배포를 검증할 수 있습니다. 자세한 내용은 OpenStack Integration Test Suite Guide를 참조하십시오.

베어 메탈 프로비저닝 서비스에 대한 추가 확인 방법은 다음과 같습니다.

  1. 관리 사용자로 Identity에 액세스하도록 쉘을 구성합니다.

    $ source ~/overcloudrc
  2. nova-compute 서비스가 컨트롤러 노드에서 실행 중인지 확인합니다.

    $ openstack compute service list -c Binary -c Host -c Status
  3. 기본 ironic 드라이버를 변경한 경우 필요한 드라이버가 활성화되어 있는지 확인합니다.

    $ openstack baremetal driver list
  4. ironic 끝점이 나열되어 있는지 확인합니다.

    $ openstack catalog list

5장. 배포 후 베어 메탈 프로비저닝 서비스 구성

베어 메탈 프로비저닝 서비스(ironic)를 사용하여 오버클라우드를 배포한 후 베어 메탈 워크로드에 맞게 환경을 준비하기 위해 몇 가지 추가 구성을 완료해야 할 수 있습니다.

  • 네트워킹을 설정합니다.
  • 노드 정리 구성.
  • 베어 메탈 노드의 베어 메탈 플레이버 및 이미지를 생성합니다.
  • 배포 인터페이스를 구성합니다.
  • 가상 미디어 부팅 구성.
  • 별도의 가상 및 물리적 시스템 배포.

사전 요구 사항

5.1. OpenStack 네트워킹 구성

DHCP, PXE 부팅 및 기타 요구 사항에 대한 베어 메탈 프로비저닝 서비스와 통신하도록 OpenStack 네트워킹을 구성합니다. 베어 메탈 네트워크는 다음 두 가지 방법으로 구성할 수 있습니다.

  • Ironic Conductor 서비스에 대해 플랫 베어 메탈 네트워크를 사용합니다. 이 네트워크는 컨트롤 플레인 네트워크의 Ironic 서비스로 라우팅해야 합니다.
  • 사용자 지정 구성 가능 네트워크를 사용하여 Overcloud에서 Ironic 서비스를 구현합니다.

이 섹션의 절차에 따라 베어 메탈에 프로비저닝할 단일 플랫 네트워크에 대해 OpenStack 네트워킹을 구성하거나 사용되지 않은 격리된 네트워크 또는 플랫 네트워크에 의존하지 않는 새로운 구성 가능 네트워크를 구성하십시오. 구성에서는 ML2 플러그인 및 Open vSwitch 에이전트를 사용합니다.

5.1.1. 플랫 베어 메탈 네트워크에서 베어 메탈 프로비저닝 서비스와 통신하도록 OpenStack 네트워킹 구성

다음 절차의 모든 단계를 OpenStack Networking 서비스를 호스팅하는 서버에서 root 사용자로 수행합니다.

사전 요구 사항

절차

  1. 관리 사용자로 Identity에 액세스하도록 쉘을 구성합니다.

    $ source ~/overcloudrc
  2. 베어 메탈 인스턴스를 프로비저닝할 flat 네트워크를 생성합니다.

    $ openstack network create \
      --provider-network-type flat \
      --provider-physical-network baremetal \
      --share NETWORK_NAME

    NETWORK_NAME 을 이 네트워크의 이름으로 바꿉니다. 가상 네트워크를 구현하는 실제 네트워크의 이름(이 경우 baremetal)은 ~/templates/network-environment.yaml 파일에서 이전에 NeutronBridgeMappings 매개변수를 사용하여 설정되었습니다.

  3. flat 네트워크에 서브넷을 생성합니다.

    $ openstack subnet create \
      --network NETWORK_NAME \
      --subnet-range NETWORK_CIDR \
      --ip-version 4 \
      --gateway GATEWAY_IP \
      --allocation-pool start=START_IP,end=END_IP \
      --dhcp SUBNET_NAME

    다음 값을 바꿉니다.

    • SUBNET_NAME 을 서브넷의 이름으로 바꿉니다.
    • NETWORK_NAME 을 이전 단계에서 생성한 프로비저닝 네트워크의 이름으로 교체합니다.
    • NETWORK_CIDR 을 서브넷에서 나타내는 IP 주소 블록의 CIDR(Classless Inter-Domain Routing) 표시로 바꿉니다. START_IP로 시작하고 END_IP 로 끝나는 범위로 지정하는 IP 주소 블록은 NETWORK_CIDR에 지정된 IP 주소 블록 내에 있어야 합니다.
    • GATEWAY_IP 를 새 서브넷의 게이트웨이 역할을 하는 라우터 인터페이스의 IP 주소 또는 호스트 이름으로 바꿉니다. 이 주소는 NETWORK_CIDR에서 지정한 IP 주소 블록 내에 있어야 하지만 START_ IP로 시작하고 END_IP 로 끝나는 범위로 지정된 IP 주소 블록 외부에 있어야 합니다.
    • 유동 IP 주소가 할당될 새 서브넷 내의 IP 주소 범위를 나타내는 START_IP 를 IP 주소로 바꿉니다.
    • END_IP 를 유동 IP 주소가 할당될 새 서브넷 내의 IP 주소 범위의 끝을 나타내는 IP 주소로 바꿉니다.
  4. 네트워크 및 서브넷의 라우터를 생성하여 OpenStack Networking 서비스가 메타데이터 요청을 제공하는지 확인합니다.

    $ openstack router create ROUTER_NAME

    ROUTER_NAME 을 라우터의 이름으로 바꿉니다.

  5. 새 라우터에 서브넷을 연결합니다.

    $ openstack router add subnet ROUTER_NAME BAREMETAL_SUBNET

    ROUTER_NAME 을 라우터 이름으로 바꾸고 ✓E METAL_SUBNET 을 이전에 만든 서브넷의 ID 또는 이름으로 바꿉니다. 이를 통해 cloud-init 의 메타데이터 요청과 구성된 노드를 제공할 수 있습니다.

5.1.2. 사용자 정의 구성 가능한 베어 메탈 네트워크에서 베어 메탈 프로비저닝 서비스와 통신하도록 OpenStack 네트워킹 구성

다음 절차의 모든 단계를 OpenStack Networking 서비스를 호스팅하는 서버에서 root 사용자로 수행합니다.

사전 요구 사항

절차

  1. 배포 중에 생성하는 OcProvisioning 네트워크와 일치하는 VlanID를 사용하여 vlan 네트워크를 만듭니다. 정리 네트워크의 기본 이름과 일치하도록 새 네트워크 프로비저닝 의 이름을 지정합니다.

    (overcloud) [stack@host01 ~]$ openstack network create \
      --share \
      --provider-network-type vlan \
      --provider-physical-network datacentre \
      --provider-segment 205 provisioning

    오버클라우드 네트워크의 이름이 프로비저닝 되지 않은 경우 컨트롤러에 로그인하고 다음 명령을 실행하여 네트워크 이름을 변경하고 다시 시작합니다.

    heat-admin@overcloud-controller-0 ~]$ sudo vi /var/lib/config-data/puppet-generated/ironic/etc/ironic/ironic.conf
    heat-admin@overcloud-controller-0 ~]$ sudo podman restart ironic_conductor

5.2. 노드 정리 구성

기본적으로 베어 메탈 프로비저닝 서비스는 노드 정리에 provisioning 이라는 네트워크를 사용합니다. 그러나 네트워크 이름은 OpenStack 네트워킹에서 고유하지 않으므로 테넌트에서 동일한 이름으로 네트워크를 만들 수 있으므로 베어 메탈 프로비저닝 서비스와 충돌할 수 있습니다. 충돌을 방지하려면 네트워크 UUID를 대신 사용합니다.

사전 요구 사항

절차

  1. 노드 정리를 구성하려면 베어 메탈 프로비저닝 서비스를 호스팅하는 컨트롤러에서 공급자 네트워크 UUID를 제공합니다.

    ~/templates/ironic.yaml

    parameter_defaults:
        IronicCleaningNetwork: <UUID>

    <UUID> 를 이전 단계에서 생성한 베어 메탈 네트워크의 UUID로 바꿉니다.

    openstack network show 명령을 사용하여 UUID를 찾을 수 있습니다.

    openstack network show NETWORK_NAME -f value -c id
    참고

    이전에 네트워크의 UUID를 사용할 수 없으므로 초기 오버클라우드 배포 후에는 이 구성을 수행해야 합니다.

  2. 변경 사항을 적용하려면 openstack overcloud deploy 를 사용하여 오버클라우드를 재배포합니다. 배포 명령에 대한 자세한 내용은 3.4절. “오버클라우드 배포” 을 참조하십시오.

5.2.1. 수동으로 노드 정리

노드 정리를 수동으로 시작하려면 노드가 manageable 상태여야 합니다.

노드 정리에는 두 가지 모드가 있습니다.

metadata만 정리 - 지정된 노드의 모든 디스크에서 파티션을 제거합니다. 이것은 더 빠른 정리 사이클이지만 파티션 테이블만 지우기 때문에 안전하지 않습니다. 이 모드는 신뢰할 수 있는 테넌트 환경에서만 사용합니다.

완전한 정리 - ATA 보안 지우기 또는 파쇄를 사용하여 모든 디스크에서 모든 데이터를 제거합니다. 이 작업을 완료하는 데 몇 시간이 걸릴 수 있습니다.

사전 요구 사항

절차

메타데이터 를 정리하려면 다음을 수행합니다.

$ openstack baremetal node clean _UUID_ \
    --clean-steps '[{"interface": "deploy", "step": "erase_devices_metadata"}]'

전체 정리를 시작하려면 다음을 수행합니다.

$ openstack baremetal node clean _UUID_ \
    --clean-steps '[{"interface": "deploy", "step": "erase_devices"}]'

UUID 를 정리할 노드의 UUID로 바꿉니다.

성공적으로 정리하면 노드 상태가 manageable 로 돌아갑니다. 상태가 clean인 경우 last_error 필드에서 실패 원인을 검사합니다.

5.3. 베어 메탈 플레이버 및 리소스 클래스 생성

특정 워크로드에 대한 베어 메탈 노드를 태그하는 데 사용할 플레이버 및 리소스 클래스를 생성해야 합니다.

절차

  1. 오버클라우드 인증 정보 파일을 소싱합니다.

    $ source ~/overcloudrc
  2. 베어 메탈 노드에 대한 새 인스턴스 플레이버를 생성합니다.

    (overcloud)$ openstack flavor create --id auto \
     --ram <ram_size_mb> --disk <disk_size_gb> \
     --vcpus <no_vcpus> baremetal
    • & lt;ram_size_mb >를 베어 메탈 노드의 RAM(MB)으로 바꿉니다.
    • & lt;disk_size_gb >을 베어 메탈 노드의 디스크 크기(GB)로 바꿉니다.
    • & lt;no_vcpus >를 베어 메탈 노드의 CPU 수로 바꿉니다.

      참고

      이러한 속성은 인스턴스 예약에 사용되지 않습니다. 그러나 계산 스케줄러는 디스크 크기를 사용하여 루트 파티션 크기를 결정합니다.

  3. 노드 목록을 검색하여 UUID를 확인합니다.

    (overcloud)$ openstack baremetal node list
  4. 사용자 지정 베어 메탈 리소스 클래스로 각 베어 메탈 노드에 태그를 지정합니다.

    (overcloud)$ openstack baremetal node set \
     --resource-class baremetal.<CUSTOM> <node>
    • & lt;CUSTOM >을 리소스 클래스의 용도를 식별하는 문자열로 바꿉니다. 예를 들어 GPU 로 설정하여 GPU 워크로드에 대해 지정할 베어 메탈 노드를 태그하는 데 사용할 사용자 지정 GPU 리소스 클래스를 생성합니다.
    • & lt;node& gt;를 베어 메탈 노드의 ID로 바꿉니다.
  5. 베어 메탈 노드의 새 인스턴스 플레이버를 사용자 정의 리소스 클래스에 연결합니다.

    (overcloud)$ openstack flavor set \
     --property resources:CUSTOM_BAREMETAL_<CUSTOM>=1 \
     baremetal

    베어 메탈 서비스 노드의 리소스 클래스에 해당하는 사용자 정의 리소스 클래스의 이름을 확인하려면 리소스 클래스를 대문자로 변환하고, 각 문장 부호를 밑줄로 교체하고 접두사를 CUSTOM_ 로 바꿉니다.

    참고

    플레이버는 베어 메탈 리소스 클래스의 하나의 인스턴스만 요청할 수 있습니다.

  6. Compute 스케줄러가 베어 메탈 플레이버 속성을 사용하여 인스턴스를 예약하지 못하도록 다음 플레이버 속성을 설정합니다.

    (overcloud)$ openstack flavor set \
     --property resources:VCPU=0 \
     --property resources:MEMORY_MB=0 \
     --property resources:DISK_GB=0 baremetal
  7. 새 플레이버에 올바른 값이 있는지 확인합니다.

    (overcloud)$ openstack flavor list

5.4. 베어 메탈 이미지 생성

베어 메탈 프로비저닝 서비스(ironic)를 포함하는 오버클라우드에는 두 개의 이미지 세트가 필요합니다. 배포하는 동안 베어 메탈 프로비저닝 서비스는 배포 이미지에서 베어 메탈 노드를 부팅하고 사용자 이미지를 노드에 복사합니다.

배포 이미지
베어 메탈 프로비저닝 서비스는 배포 이미지를 사용하여 베어 메탈 노드를 부팅하고 사용자 이미지를 베어 메탈 노드에 복사합니다. 배포 이미지는 커널 이미지와 ramdisk 이미지로 구성됩니다.
사용자 이미지

사용자 이미지는 베어 메탈 노드에 배포하는 이미지입니다. 사용자 이미지에는 커널 이미지와 ramdisk 이미지도 있지만, 추가적으로 사용자 이미지에 기본 이미지가 포함되어 있습니다 . 기본 이미지는 루트 파티션 또는 전체 디스크 이미지입니다.

  • 전체 디스크 이미지는 파티션 테이블과 부트 로더가 포함된 이미지입니다. 노드가 localboot를 지원하므로 전체 디스크 이미지와 함께 배포된 노드의 후속 재부팅을 제어하지 않습니다.
  • 루트 파티션 이미지 에는 운영 체제의 루트 파티션만 포함되어 있습니다. 루트 파티션을 사용하는 경우 배포 이미지가 이미지 서비스에 로드된 후 노드 속성에서 배포 이미지를 노드 부팅 이미지로 설정할 수 있습니다. 이후 노드를 재부팅하면 netboot를 사용하여 사용자 이미지를 제거합니다.

이 섹션의 예제에서는 루트 파티션 이미지를 사용하여 베어 메탈 노드를 프로비저닝합니다.

5.4.1. 배포 이미지 준비

Undercloud에서 Overcloud를 배포할 때 이미 생성되었기 때문에 배포 이미지를 생성할 필요는 없습니다. 배포 이미지는 커널 이미지와 ramdisk 이미지라는 두 개의 이미지로 구성됩니다.

/tftpboot/agent.kernel
/tftpboot/agent.ramdisk

이러한 이미지는 홈 디렉토리에 있거나 다른 위치에서 압축을 푼 경우가 많습니다. 홈 디렉토리에 있지 않고 rhosp-director-images-ipa 패키지가 설치되어 있는 경우 해당 이미지는 /usr/share/rhosp-director-images/ironic-python-agent*.tar 파일에 있습니다.

사전 요구 사항

절차

이미지를 추출하여 이미지 서비스에 업로드합니다.

$ openstack image create \
  --container-format aki \
  --disk-format aki \
  --public \
  --file ./tftpboot/agent.kernel bm-deploy-kernel
$ openstack image create \
  --container-format ari \
  --disk-format ari \
  --public \
  --file ./tftpboot/agent.ramdisk bm-deploy-ramdisk

5.4.2. 사용자 이미지 준비

필요한 최종 이미지는 베어 메탈 노드에 배포하는 사용자 이미지입니다. 사용자 이미지에는 기본 이미지와 함께 커널 및 ramdisk도 있습니다. 이러한 패키지를 다운로드하고 설치하려면 먼저 전체 디스크 이미지 환경 변수를 요구 사항에 맞게 구성해야 합니다.

5.4.2.1. 디스크 이미지 환경 변수

디스크 이미지 빌드 프로세스의 일환으로 director는 새 오버클라우드 이미지 패키지를 가져오기 위해 기본 이미지와 등록 세부 정보가 필요합니다. 다음 Linux 환경 변수를 사용하여 이러한 속성을 정의합니다.

참고

이미지 빌드 프로세스는 Red Hat 서브스크립션에서 이미지를 임시로 등록하고, 이미지 빌드 프로세스가 완료되면 시스템을 등록 취소합니다.

디스크 이미지를 빌드하려면 사용자의 환경과 요건에 맞는 Linux 환경 변수를 설정합니다.

DIB_LOCAL_IMAGE
전체 디스크 이미지의 기반으로 사용할 로컬 이미지를 설정합니다.
REG_ACTIVATION_KEY
로그인 정보 대신 활성화 키를 등록 프로세스의 일부로 사용합니다.
REG_AUTO_ATTACH
가장 호환되는 서브스크립션을 자동으로 연결할지 여부를 정의합니다.
REG_BASE_URL
이미지용 패키지가 포함된 콘텐츠 전달 서버의 기본 URL입니다. 기본 Customer Portal 서브스크립션 관리 프로세스는 https://cdn.redhat.com을 사용합니다. Red Hat Satellite 6 서버를 사용하는 경우 이 매개변수를 Satellite 서버의 기본 URL로 설정합니다.
REG_ENVIRONMENT
조직 내의 환경에 등록합니다.
REG_METHOD
등록 방법을 설정합니다. Red Hat 고객 포털에 시스템을 등록하려면 portal을 사용합니다. Red Hat Satellite 6에 시스템을 등록하려면 satellite를 사용합니다.
REG_ORG
이미지를 등록할 조직입니다.
REG_POOL_ID
제품 서브스크립션 정보의 풀 ID입니다.
REG_PASSWORD
이미지를 등록하는 사용자 계정의 암호를 설정합니다.
REG_RELEASE
Red Hat Enterprise Linux 마이너 릴리스 버전을 설정합니다. REG_AUTO_ATTACH 또는 POOL_ID 환경 변수와 함께 사용해야 합니다.
REG_REPOS
리포지토리 이름의 쉼표로 구분된 문자열입니다. 이 문자열의 각 리포지토리는 subscription-manager를 통해 활성화됩니다.
REG_SAT_URL
오버클라우드 노드를 등록할 Satellite 서버의 기본 URL입니다. Satellite HTTPS URL 대신 HTTP URL을 이 매개변수에 사용합니다. 예를 들어 https://satellite.example.com 대신 http://satellite.example.com을 사용합니다.
REG_SERVER_URL
사용할 서브스크립션 서비스의 호스트 이름을 설정합니다. Red Hat Customer Portal의 기본 호스트 이름은 subscription.rhn.redhat.com에 있습니다. Red Hat Satellite 6 서버를 사용하는 경우 이 매개변수를 Satellite 서버의 호스트 이름으로 설정하십시오.
REG_USER
이미지를 등록할 계정의 사용자 이름을 설정합니다.

5.4.3. 사용자 이미지 설치

사용자 이미지를 구성한 다음 이미지를 이미지 서비스(glance)에 업로드합니다.

사전 요구 사항

절차

  1. 고객 포털에서 Red Hat Enterprise Linux KVM 게스트 이미지를 다운로드합니다.
  2. 다운로드한 이미지로 DIB_LOCAL_IMAGE 를 정의합니다.

    $ export DIB_LOCAL_IMAGE=rhel-8.0-x86_64-kvm.qcow2
  3. 등록 정보를 설정합니다. Red Hat 고객 포털을 사용하는 경우 다음 정보를 구성해야 합니다.

    $ export REG_USER='USER_NAME'
    $ export REG_PASSWORD='PASSWORD'
    $ export REG_AUTO_ATTACH=true
    $ export REG_METHOD=portal
    $ export https_proxy='IP_address:port' (if applicable)
    $ export http_proxy='IP_address:port' (if applicable)

    Red Hat Satellite를 사용하는 경우 다음 정보를 구성해야 합니다.

    $ export REG_USER='USER_NAME'
    $ export REG_PASSWORD='PASSWORD'
    $ export REG_SAT_URL='<SATELLITE URL>'
    $ export REG_ORG='<SATELLITE ORG>'
    $ export REG_ENV='<SATELLITE ENV>'
    $ export REG_METHOD=<METHOD>

    오프라인 리포지토리가 있는 경우 DIB_YUM_REPO_CONF를 로컬 리포지토리 구성으로 정의할 수 있습니다.

    $ export DIB_YUM_REPO_CONF=<path-to-local-repository-config-file>
  4. diskimage-builder 도구를 사용하여 사용자 이미지를 생성합니다.

    $ disk-image-create rhel8 baremetal -o rhel-image

    이 명령은 커널을 rhel-image.vmlinuz 로 추출하고 초기 램디스크를 rhel-image.initrd 로 추출합니다.

  5. 이미지를 이미지 서비스에 업로드합니다.

    $ KERNEL_ID=$(openstack image create \
      --file rhel-image.vmlinuz --public \
      --container-format aki --disk-format aki \
      -f value -c id rhel-image.vmlinuz)
    $ RAMDISK_ID=$(openstack image create \
      --file rhel-image.initrd --public \
      --container-format ari --disk-format ari \
      -f value -c id rhel-image.initrd)
    $ openstack image create \
      --file rhel-image.qcow2   --public \
      --container-format bare \
      --disk-format qcow2 \
      --property kernel_id=$KERNEL_ID \
      --property ramdisk_id=$RAMDISK_ID \
      rhel-image

5.5. 배포 인터페이스 구성

베어 메탈 노드를 프로비저닝하면 오버클라우드의 Bare Metal Provisioning 서비스(ironic)가 베어 메탈 노드의 디스크에 기본 운영 체제 이미지를 씁니다. 기본적으로 배포 인터페이스는 iSCSI 마운트에 이미지를 마운트한 다음 각 노드의 디스크에 이미지를 복사합니다. 또는 HTTP 위치의 디스크 이미지를 베어 메탈 노드의 디스크에 직접 쓰는 직접 배포를 사용할 수 있습니다.

배포에는 프로비저닝 프로세스에서 중요한 역할이 있습니다. 인터페이스를 배포하면 배포를 오케스트레이션하고 이미지를 대상 디스크로 전송하는 메커니즘을 정의합니다.

사전 요구 사항

  • ironic-conductor 를 실행하는 베어 메탈 서비스 노드에 구성된 종속 패키지입니다.
  • 베어 메탈 서비스 엔드포인트를 사용하도록 OpenStack Compute(nova)를 구성합니다.
  • 사용 가능한 하드웨어에 대한 플레이버를 만들고 nova가 올바른 플레이버에서 새 노드를 부팅해야 합니다.
  • 이미지 서비스(glance)에서 이미지를 사용할 수 있어야 합니다.

    • bm-deploy-kernel
    • bm-deploy-ramdisk
    • user-image
    • user-image-vmlinuz
    • user-image-initrd
  • Ironic API 서비스에 등록할 하드웨어입니다.

워크플로

다음 예제 워크플로를 사용하여 표준 배포 프로세스를 이해합니다. 사용하는 ironic 드라이버 인터페이스에 따라 일부 단계는 다를 수 있습니다.

  1. Nova 스케줄러는 Nova API에서 부팅 인스턴스 요청을 수신합니다.
  2. Nova 스케줄러는 관련 하이퍼바이저를 식별하고 대상 물리 노드를 식별합니다.
  3. Nova 계산 관리자는 선택한 하이퍼바이저의 리소스를 클레임합니다.
  4. Nova 계산 관리자는 nova 부팅 요청이 지정하는 네트워크 인터페이스에 따라 네트워킹 서비스에 바인딩되지 않은 테넌트 가상 인터페이스(VIF)를 만듭니다.
  5. Nova compute는 Nova 컴퓨팅 virt 계층에서 driver.spawn 을 호출하여 필요한 모든 정보가 포함된 generate 작업을 생성합니다. 생성 프로세스 중에 virt 드라이버는 다음 단계를 완료합니다.

    1. 배포 이미지, 인스턴스 UUID, 요청된 기능 및 플레이버 속성에 대한 정보를 사용하여 대상 ironic 노드를 업데이트합니다.
    2. ironic API를 호출하여 대상 노드의 전원 및 인터페이스를 검증합니다.
    3. 노드에 VIF를 연결합니다. 각 neutron 포트를 ironic 포트 또는 그룹에 연결할 수 있습니다. 포트 그룹은 포트보다 우선 순위가 높습니다.
    4. 구성 드라이브를 생성합니다.
  6. Nova ironic virt 드라이버는 베어 메탈 노드를 서비스하는 Ironic 컨덕터에 배포 요청을 발행합니다.
  7. 가상 인터페이스는 에 연결되고 Neutron API는 DHCP를 업데이트하여 PXE/TFTP 옵션을 구성합니다.
  8. Ironic 노드 부팅 인터페이스는 (i)PXE 구성을 준비하고 배포 커널 및 ramdisk를 캐시합니다.
  9. Ironic 노드 관리 인터페이스는 노드의 네트워크 부팅을 활성화하는 명령을 실행합니다.
  10. ironic 노드는 필요한 경우 인스턴스 이미지, 커널 및 ramdisk를 캐시합니다.
  11. ironic 노드 전원 인터페이스는 노드의 전원을 켜도록 지시합니다.
  12. 노드는 배포 램디스크를 부팅합니다.
  13. iSCSI 배포를 사용하면 컨덕터(conductor)가 iSCSI를 통해 실제 노드에 이미지를 복사합니다. 배포 램디스크는 직접 배포를 통해 임시 URL에서 이미지를 다운로드합니다. 이 URL은 Swift API 호환 오브젝트 저장소 또는 HTTP URL이어야 합니다.
  14. 노드 부팅 인터페이스는 PXE 구성을 전환하여 인스턴스 이미지를 참조하고 ramdisk 에이전트에 노드의 전원을 소프트 끕니다. 소프트 전원 끄기에 실패하면 베어 메탈 노드의 전원이 IPMI/BMC로 꺼집니다.
  15. deploy 인터페이스는 네트워크 인터페이스에 프로비저닝 포트를 제거하고 테넌트 포트를 노드에 바인딩하며 노드의 전원을 켭니다.

새 베어 메탈 노드의 프로비저닝 상태가 이제 활성 상태입니다.

5.5.1. 오버클라우드에 직접 배포 인터페이스 구성

iSCSI 배포 인터페이스가 기본 배포 인터페이스입니다. 그러나 직접 배포 인터페이스를 사용하여 HTTP 위치에서 대상 디스크로 이미지를 다운로드할 수 있습니다.

참고

오버클라우드 노드 메모리 tmpfs에는 8GB 이상의 RAM이 있어야 합니다.

절차
  1. 사용자 지정 환경 파일 /home/stack/templates/direct_deploy.yaml 을 생성하거나 수정하고 IronicEnabledDeployInterfacesIronicDefaultDeployInterface 매개변수를 지정합니다.

    parameter_defaults:
      IronicEnabledDeployInterfaces: direct
      IronicDefaultDeployInterface: direct

    노드를 iscsi로 등록하는 경우 IronicEnabledDeployInterfaces 매개변수에 iscsi 값을 유지합니다.

    parameter_defaults:
      IronicEnabledDeployInterfaces: direct,iscsi
      IronicDefaultDeployInterface: direct
  2. 기본적으로 각 노드의 Bare Metal Provisioning 서비스(ironic) 에이전트는 HTTP 링크를 통해 Object Storage Service(swift)에 저장된 이미지를 가져옵니다. 또는 ironic은 ironic-conductor HTTP 서버를 통해 이 이미지를 노드로 직접 스트리밍할 수 있습니다. 이미지를 제공하는 서비스를 변경하려면 /home/stack/templates/direct_deploy.yaml 파일에서 IronicImageDownloadSourcehttp 로 설정합니다.

    parameter_defaults:
      IronicEnabledDeployInterfaces: direct
      IronicDefaultDeployInterface: direct
      IronicImageDownloadSource: http
  3. 오버클라우드 배포를 사용하여 사용자 지정 환경을 포함합니다.

    $ openstack overcloud deploy \
      --templates \
      ...
      -e /usr/share/openstack-tripleo-heat-templates/environments/services/ironic.yaml \
      -e /home/stack/templates/direct_deploy.yaml \
      ...

    배포가 완료될 때까지 기다립니다.

참고

IronicDefaultDeployInterface 를 지정하지 않았거나 다른 배포 인터페이스를 사용하려면 노드를 생성하거나 업데이트할 때 배포 인터페이스를 지정합니다.

$ openstack baremetal node create --driver ipmi --deploy-interface direct
$ openstack baremetal node set <NODE> --deploy-interface direct

5.6. 물리적 머신을 베어 메탈 노드로 추가

베어 메탈 노드를 등록하는 방법은 두 가지가 있습니다.

  1. 노드 세부 정보를 사용하여 인벤토리 파일을 준비하고 파일을 베어 메탈 프로비저닝 서비스로 가져오고 노드를 사용할 수 있도록 합니다.
  2. 물리적 시스템을 베어 메탈 노드로 등록한 다음 수동으로 하드웨어 세부 정보를 추가하고 각 이더넷 MAC 주소에 대한 포트를 만듭니다. overcloudrc 파일이 있는 모든 노드에서 다음 단계를 수행할 수 있습니다.

물리적 시스템을 등록한 후에는 Compute 리소스 추적기가 주기적으로 동기화되므로 계산에서 새 리소스에 즉시 알리지 않습니다. 다음 주기적 작업 실행 후 변경 사항을 볼 수 있습니다. /etc/nova/nova.conf 파일에서 scheduler_driver_task_period 를 사용하여 주기 작업 빈도를 업데이트할 수 있습니다. 기본 기간은 60초입니다.

5.6.1. 인벤토리 파일을 사용하여 베어 메탈 노드 등록

노드 세부 정보를 사용하여 인벤토리 파일을 준비하고, 파일을 Bare Metal Provisioning 서비스(ironic)로 가져오고 노드를 사용할 수 있도록 합니다.

사전 요구 사항

절차

  1. 노드 세부 정보가 포함된 인벤토리 파일 overcloud-nodes.yaml 을 생성합니다. 하나의 파일로 여러 노드를 등록할 수 있습니다.

    nodes:
        - name: node0
          driver: ipmi
          driver_info:
            ipmi_address: <ipmi_ip>
            ipmi_username: <user>
            ipmi_password: <password>
          properties:
            cpus: <cpu_count>
            cpu_arch: <cpu_arch>
            memory_mb: <memory>
            local_gb: <root_disk>
            root_device:
                serial: <serial>
          ports:
            - address: <mac_address>
    • & lt;ipmi_ip >를 베어 메탈 컨트롤러 주소로 교체합니다.
    • &lt ;user&gt;를 사용자 이름으로 바꿉니다.
    • &lt ;password&gt;를 암호로 바꿉니다.
    • & lt;cpu_count& gt;를 CPU 수로 바꿉니다.
    • & lt;cpu_arch >를 CPU의 아키텍처 유형으로 바꿉니다.
    • & lt;memory& gt;를 MiB의 메모리 양으로 바꿉니다.
    • & lt;root_disk >를 GiB의 루트 디스크 크기로 교체합니다. 시스템에 디스크가 여러 개인 경우에만 필요합니다.
    • & lt;serial >을 배포에 사용할 디스크의 일련 번호로 바꿉니다.
    • & lt;mac_address& gt;를 PXE 부팅에 사용되는 NIC의 MAC 주소로 바꿉니다.
  2. Identity를 관리 사용자로 사용하도록 쉘을 구성합니다.

    $ source ~/overcloudrc
  3. 인벤토리 파일을 베어 메탈 프로비저닝 서비스로 가져옵니다.

    $ openstack baremetal create overcloud-nodes.yaml

    노드가 이제 등록 상태에 있습니다.

  4. deploy kernel을 지정하고 각 노드에 ramdisk를 배포합니다.

    $ openstack baremetal node set <node> \
      --driver-info deploy_kernel=<kernel_file> \
      --driver-info deploy_ramdisk=<initramfs_file>

    다음 값을 바꿉니다.

    • & lt;node& gt;를 노드의 이름 또는 ID로 바꿉니다.
    • < kernel_file >을 .kernel 이미지의 경로로 바꿉니다(예: file:///var/lib/ironic/httpboot/agent.kernel ).
    • < initramfs_file >을 .initramfs 이미지 경로로 바꿉니다(예: file:///var/lib/ironic/httpboot/agent.ramdisk ).
  5. 선택 사항: 각 노드의 IPMI 암호화 제품군을 지정합니다.

    $ openstack baremetal node set <node> \
     --driver-info ipmi_cipher_suite=<version>
    • & lt;node& gt;를 노드의 이름 또는 ID로 바꿉니다.
    • & lt;version >을 노드에서 사용할 암호화 제품군 버전으로 바꿉니다. 다음 유효한 값 중 하나로 설정합니다.

      • 3 - 노드는 SHA1 암호화 제품군과 AES-128을 사용합니다.
      • 17 - 노드는 SHA256 암호화 제품군과 함께 AES-128을 사용합니다.
  6. 노드의 프로비저닝 상태를 available 로 설정합니다.

    $ openstack baremetal node manage <node>
    $ openstack baremetal node provide <node>

    노드 정리를 활성화한 경우 베어 메탈 프로비저닝 서비스는 노드를 정리합니다.

  7. 노드에 로컬 부트 옵션을 설정합니다.

    $ openstack baremetal node set <node> --property capabilities="boot_option:local"
  8. 노드가 등록되어 있는지 확인합니다.

    $ openstack baremetal node list

    노드 등록과 해당 상태 표시 사이에 지연이 있을 수 있습니다.

5.7. Redfish 가상 미디어 부팅 구성

중요

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

BMC(Baseboard Management Controller)에서 가상 드라이브 중 하나에 부팅 이미지를 삽입할 수 있도록 Redfish 가상 미디어 부팅을 사용하여 노드의 BMC에 부팅 이미지를 공급할 수 있습니다. 그 후 노드는 가상 드라이브에서 해당 이미지에 있는 운영 체제로 부팅할 수 있습니다.

Redfish 하드웨어 유형은 가상 미디어를 통한 배포, 복구 및 사용자 이미지 부팅을 지원합니다. Bare Metal Provisioning 서비스(ironic)는 노드와 연결된 커널 및 램디스크 이미지를 사용하여 노드 배포 시 UEFI 또는 BIOS 부팅 모드의 부팅 가능한 ISO 이미지를 빌드합니다. 가상 미디어 부팅의 주요 장점은 PXE의 TFTP 이미지 전송 단계를 제거하고 대신 HTTP GET 또는 기타 방법을 사용할 수 있다는 것입니다.

5.7.1. Redfish 가상 미디어 부팅을 사용하여 베어 메탈 서버 배포

중요

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

가상 미디어를 통해 redfish 하드웨어 유형으로 노드를 부팅하려면 부팅 인터페이스를 redfish-virtual-media로 설정하고 UEFI 노드의 경우 ESP(EFI 시스템 파티션) 이미지를 정의합니다. 다음으로 등록된 노드가 Redfish 가상 미디어 부팅을 사용하도록 설정합니다.

사전 요구 사항

  • undercloud.conf 파일의 enabled_hardware_types 매개변수로 활성화된 Redfish 드라이버
  • 등록된 베어 메탈 노드
  • Image 서비스(glance)의 IPA 및 인스턴스 이미지
  • UEFI 노드의 경우 Image 서비스(glance)에서 ESP(EFI 시스템 파티션) 이미지 사용 가능
  • 베어 메탈 플레이버
  • 정리 및 프로비저닝을 위한 네트워크
  • Sushy 라이브러리 설치

    $ sudo yum install sushy

절차

  1. Bare Metal 서비스(ironic) 부팅 인터페이스를 redfish-virtual-media로 설정합니다.

    $ openstack baremetal node set --boot-interface redfish-virtual-media $NODE_NAME

    $ NODE_NAME을 노드 이름으로 바꿉니다.

  2. UEFI 노드의 경우 부팅 모드를 uefi로 설정합니다.

    $ openstack baremetal node set --property capabilities="boot_mode:uefi" $NODE_NAME

    $ NODE_NAME을 노드 이름으로 바꿉니다.

    참고

    BIOS 노드의 경우 이 단계를 완료하지 마십시오.

  3. UEFI 노드의 경우 ESP(EFI 시스템 파티션) 이미지를 정의합니다.

    $ openstack baremetal node set --driver-info bootloader=$ESP $NODE_NAME

    $ESP를 glance 이미지 UUID 또는 ESP 이미지 URL로 바꾸고 $NODE_NAME을 노드 이름으로 바꿉니다.

    참고

    BIOS 노드의 경우 이 단계를 완료하지 마십시오.

  4. 베어 메탈 노드에서 포트를 생성하고 베어 메탈 노드에서 NIC의 MAC 주소와 포트를 연결합니다.

    $ openstack baremetal port create --pxe-enabled True --node $UUID $MAC_ADDRESS

    $UUID를 베어 메탈 노드의 UUID로 바꾸고 $MAC_ADDRESS를 베어 메탈 노드에 있는 NIC의 MAC 주소로 바꿉니다.

  5. 새 베어 메탈 서버를 생성합니다.

    $ openstack server create \
        --flavor baremetal \
        --image $IMAGE \
        --network $NETWORK \
        test_instance

    $IMAGE$NETWORK 를 사용하려는 이미지 및 네트워크 이름으로 교체합니다.

5.8. 호스트 집계를 사용하여 물리적 및 가상 시스템 프로비저닝 분리

OpenStack Compute에서는 호스트 집계를 사용하여 가용 영역을 분할하고 특정 공유 속성이 있는 노드를 그룹화합니다. 인스턴스가 배포되면 계산 스케줄러는 플레이버의 속성을 호스트 집계에 할당된 속성과 비교하고, 실제 시스템 또는 가상 시스템에 인스턴스를 올바른 집계 및 올바른 호스트에 프로비저닝합니다.

다음 작업을 수행하려면 이 섹션의 단계를 완료합니다.

  • baremetal 속성을 플레이버에 추가하고 true 또는 false로 설정합니다.
  • 일치하는 베어 메탈 속성을 사용하여 베어 메탈 호스트 및 계산 노드에 대해 별도의 호스트 집계를 생성합니다. 집계로 그룹화된 노드는 이 속성을 상속받습니다.

사전 요구 사항

절차

  1. baremetal 플레이버에서 baremetal 속성을 true 로 설정합니다.

    $ openstack flavor set baremetal --property baremetal=true
  2. 가상 인스턴스에서 사용하는 플레이버에서 baremetal 속성을 false로 설정합니다.

    $ openstack flavor set FLAVOR_NAME --property baremetal=false
  3. baremetal-hosts 라는 호스트 집계를 생성합니다.

    $ openstack aggregate create --property baremetal=true baremetal-hosts
  4. baremetal-hosts 집계에 각 컨트롤러 노드를 추가합니다.

    $ openstack aggregate add host baremetal-hosts HOSTNAME
    참고

    NovaIronic 서비스를 사용하여 구성 가능 역할을 생성한 경우 이 서비스의 모든 노드를 baremetal-hosts 집계에 추가합니다. 기본적으로 컨트롤러 노드에만 NovaIronic 서비스가 있습니다.

  5. virtual-hosts 라는 호스트 집계를 생성합니다.

    $ openstack aggregate create --property baremetal=false virtual-hosts
  6. 각 컴퓨팅 노드를 virtual-hosts 집계에 추가합니다.

    $ openstack aggregate add host virtual-hosts HOSTNAME
  7. 오버클라우드를 배포할 때 다음 Compute 필터 스케줄러를 추가하지 않은 경우 _/etc/nova/nova.conf _ 파일의 scheduler_default_filters 아래의 기존 목록에 지금 추가합니다.

    AggregateInstanceExtraSpecsFilter

6장. 베어 메탈 노드 관리

베어 메탈 프로비저닝 서비스(ironic)가 포함된 오버클라우드를 배포한 후 등록된 베어 메탈 노드에서 실제 시스템을 프로비저닝하고 오버클라우드에서 베어 메탈 인스턴스를 시작할 수 있습니다.

사전 요구 사항

6.1. 베어 메탈 인스턴스 시작

명령줄 또는 OpenStack 대시보드에서 인스턴스를 시작할 수 있습니다.

사전 요구 사항

6.1.1. 명령줄 인터페이스를 사용하여 인스턴스 시작

openstack 명령줄 인터페이스를 사용하여 베어 메탈 인스턴스를 배포합니다.

사전 요구 사항

절차

  1. ID 서비스(keystone)에 관리 사용자로 액세스하도록 쉘을 구성합니다.

    $ source ~/overcloudrc
  2. 인스턴스를 배포합니다.

    $ openstack server create \
      --nic net-id=NETWORK_UUID \
      --flavor baremetal \
      --image IMAGE_UUID \
      INSTANCE_NAME

    다음 값을 바꿉니다.

    • NETWORK_UUID 를 베어 메탈 프로비저닝 서비스와 함께 사용하도록 만든 네트워크의 고유 식별자로 바꿉니다.
    • IMAGE_UUID 를 이미지 서비스에 업로드된 디스크 이미지의 고유 식별자로 바꿉니다.
    • INSTANCE_NAME 을 베어 메탈 인스턴스의 이름으로 바꿉니다.

    인스턴스를 보안 그룹에 할당하려면 --security-group SECURITY_GROUP 을 포함하여 SECURITY_GROUP 을 보안 그룹의 이름으로 바꿉니다. 이 옵션을 반복하여 인스턴스를 여러 그룹에 추가합니다. 보안 그룹 관리에 대한 자세한 내용은 사용자 및 ID 관리 가이드를 참조하십시오.

  3. 인스턴스의 상태를 확인합니다.

    $ openstack server list --name INSTANCE_NAME

6.1.2. 대시보드로 인스턴스 시작

대시보드 그래픽 사용자 인터페이스를 사용하여 베어 메탈 인스턴스를 배포합니다.

사전 요구 사항

절차

  1. http[s]://DASHBOARD_IP/dashboard 에서 대시보드에 로그인합니다.
  2. Project > Compute > Instances를 클릭합니다.
  3. Launch Instance(인스턴스 시작)를 클릭합니다.

    • Details(세부 정보 ) 탭에서 Instance Name(인스턴스 이름) 을 지정하고 Count (카운트)로 1 을 선택합니다.
    • Source(소스 ) 탭에서 Select Boot Source (부팅 소스 선택)에서 Image (이미지)를 선택한 다음 + (더하기) 기호를 클릭하여 운영 체제 디스크 이미지를 선택합니다. 선택한 이미지는 Allocated 로 이동합니다.
    • Flavor(플레이버 ) 탭에서 baremetal 을 선택합니다.
    • Networks(네트워크 ) 탭에서 + (더하기) 및 - (minus) 버튼을 사용하여 필수 네트워크를 Available (사용 가능)에서 Allocated( 할당됨)로 이동합니다. 여기에서 베어 메탈 프로비저닝 서비스에 대해 만든 공유 네트워크가 선택되었는지 확인합니다.
    • 인스턴스를 보안 그룹에 할당하려면 Security Groups(보안 그룹 ) 탭에서 화살표를 사용하여 그룹을 Allocated 로 이동합니다.
  4. Launch Instance(인스턴스 시작)를 클릭합니다.

6.2. 베어 메탈 프로비저닝 서비스에서 포트 그룹 구성

참고

베어 메탈 노드의 포트 그룹 기능은 이번 릴리스에서 기술 프리뷰로 제공되므로 Red Hat에서 완전히 지원하지 않습니다. 테스트에만 사용해야 하며 프로덕션 환경에 배포해서는 안 됩니다. 기술 프리뷰 기능에 대한 자세한 내용은 적용 범위 상세 정보를 참조하십시오.

포트 그룹(bonds)은 여러 네트워크 인터페이스를 하나의 '결합' 인터페이스로 집계하는 방법을 제공합니다. 포트 그룹 구성은 항상 개별 포트 구성보다 우선합니다.

포트 그룹에 물리적 네트워크가 있는 경우 해당 포트 그룹의 모든 포트에는 물리적 네트워크가 동일해야 합니다. 베어 메탈 프로비저닝 서비스는 configdrive 를 사용하여 인스턴스에서 포트 그룹 구성을 지원합니다.

참고

베어 메탈 프로비저닝 서비스 API 버전 1.26은 포트 그룹 구성을 지원합니다. .사전 요구 사항

6.2.1. 스위치에서 수동으로 포트 그룹 구성

베어 메탈 배포에서 포트 그룹을 구성하려면 스위치에서 포트 그룹을 수동으로 구성해야 합니다. 이름 지정이 스위치에 따라 다를 수 있으므로 스위치의 모드와 속성이 베어 메탈 측면의 모드 및 속성에 해당하는지 확인해야 합니다.

참고

iPXE를 사용하여 배포를 부팅해야 하는 경우 프로비저닝 및 정리에 포트 그룹을 사용할 수 없습니다.

포트 그룹 폴백을 사용하면 포트 그룹의 모든 포트가 연결이 실패하면 개별 스위치 포트로 대체될 수 있습니다. 스위치가 포트 그룹 폴백을 지원하는지 여부에 따라 --support-standalone- ports 및 --unsupport-standalone -ports 옵션을 사용할 수 있습니다.

사전 요구 사항

6.2.2. 베어 메탈 프로비저닝 서비스에서 포트 그룹 구성

포트 그룹을 만들어 여러 네트워크 인터페이스를 하나의 본딩된 인터페이스로 집계합니다.

사전 요구 사항

절차

  1. 독립 실행형 포트로 대체를 지원하는지 여부, 이름, 주소, 모드, 속성이 속해 있는 노드를 지정하여 포트 그룹을 만듭니다.

    # openstack baremetal port group create --node NODE_UUID --name NAME --address MAC_ADDRESS --mode MODE  --property miimon=100 --property xmit_hash_policy="layer2+3" --support-standalone-ports

    openstack baremetal port group set 명령을 사용하여 포트 그룹을 업데이트할 수도 있습니다.

    주소를 지정하지 않으면 배포된 인스턴스 포트 그룹 주소가 OpenStack Networking 포트와 동일합니다. neutron 포트를 연결하지 않으면 포트 그룹 구성이 실패합니다.

    인터페이스 연결 중에 포트 그룹은 포트보다 우선 순위가 높으므로 먼저 사용됩니다. 현재는 포트 그룹 또는 포트가 인터페이스 연결 요청에 필요한지 여부를 지정할 수 없습니다. 포트가 없는 포트 그룹은 무시됩니다.

    참고

    이미지에서 또는 configdrive 를 생성하고 노드의 instance_info 에 추가하여 포트 그룹을 수동으로 구성해야 합니다. 포트 그룹 구성이 작동하려면 cloud-init 버전 0.2.7 이상이 있는지 확인합니다.

  2. 포트를 포트 그룹과 연결합니다.

    • 포트 생성 중:

      # openstack baremetal port create --node NODE_UUID --address MAC_ADDRESS --port-group test
    • 포트를 업데이트하는 동안:

      # openstack baremetal port set PORT_UUID --port-group PORT_GROUP_UUID
  3. cloud-init 가 있거나 본딩을 지원하는 이미지를 제공하여 인스턴스를 부팅합니다.

    포트 그룹이 올바르게 구성되었는지 확인하려면 다음 명령을 실행합니다.

    # cat /proc/net/bonding/bondX

    여기서 X 는 구성된 각 포트 그룹에 대해 cloud-init 가 자동으로 생성하는 숫자로, 구성된 각 포트 그룹에 대해 0 으로 시작하고 하나씩 증가시킵니다.

6.3. 호스트와 IP 주소 매핑 확인

다음 명령을 사용하여 어떤 IP 주소가 어떤 호스트와 베어 메탈 노드에 할당되었는지 확인합니다. 이러한 명령을 사용하면 호스트에 직접 액세스하지 않고도 언더클라우드에서 IP 매핑으로 호스트를 볼 수 있습니다.

사전 요구 사항

절차

  1. 다음 명령을 실행하여 각 호스트의 IP 주소를 표시합니다.

    (undercloud) [stack@host01 ~]$ openstack stack output show overcloud HostsEntry --max-width 80
    
    +--------------+---------------------------------------------------------------+
    | Field        | Value                                                         |
    +--------------+---------------------------------------------------------------+
    | description  | The content that should be appended to your /etc/hosts if you |
    |              | want to get                                                   |
    |              | hostname-based access to the deployed nodes (useful for       |
    |              | testing without                                               |
    |              | setting up a DNS).                                            |
    |              |                                                               |
    | output_key   | HostsEntry                                                    |
    | output_value | 172.17.0.10 overcloud-controller-0.localdomain overcloud-     |
    |              | controller-0                                                  |
    |              | 10.8.145.18 overcloud-controller-0.external.localdomain       |
    |              | overcloud-controller-0.external                               |
    |              | 172.17.0.10 overcloud-controller-0.internalapi.localdomain    |
    |              | overcloud-controller-0.internalapi                            |
    |              | 172.18.0.15 overcloud-controller-0.storage.localdomain        |
    |              | overcloud-controller-0.storage                                |
    |              | 172.21.2.12 overcloud-controller-0.storagemgmt.localdomain    |
    |              | overcloud-controller-0.storagemgmt                            |
    |              | 172.16.0.15 overcloud-controller-0.tenant.localdomain         |
    |              | overcloud-controller-0.tenant                                 |
    |              | 10.8.146.13 overcloud-controller-0.management.localdomain     |
    |              | overcloud-controller-0.management                             |
    |              | 10.8.146.13 overcloud-controller-0.ctlplane.localdomain       |
    |              | overcloud-controller-0.ctlplane                               |
    |              |                                                               |
    |              | 172.17.0.21 overcloud-compute-0.localdomain overcloud-        |
    |              | compute-0                                                     |
    |              | 10.8.146.12 overcloud-compute-0.external.localdomain          |
    |              | overcloud-compute-0.external                                  |
    |              | 172.17.0.21 overcloud-compute-0.internalapi.localdomain       |
    |              | overcloud-compute-0.internalapi                               |
    |              | 172.18.0.20 overcloud-compute-0.storage.localdomain           |
    |              | overcloud-compute-0.storage                                   |
    |              | 10.8.146.12 overcloud-compute-0.storagemgmt.localdomain       |
    |              | overcloud-compute-0.storagemgmt                               |
    |              | 172.16.0.16 overcloud-compute-0.tenant.localdomain overcloud- |
    |              | compute-0.tenant                                              |
    |              | 10.8.146.12 overcloud-compute-0.management.localdomain        |
    |              | overcloud-compute-0.management                                |
    |              | 10.8.146.12 overcloud-compute-0.ctlplane.localdomain          |
    |              | overcloud-compute-0.ctlplane                                  |
    |              |                                                               |
    |              |                                                               |
    |              |                                                               |
    |              |                                                               |
    |              | 10.8.145.16  overcloud.localdomain                            |
    |              | 10.8.146.7  overcloud.ctlplane.localdomain                    |
    |              | 172.17.0.19  overcloud.internalapi.localdomain                |
    |              | 172.18.0.19  overcloud.storage.localdomain                    |
    |              | 172.21.2.16  overcloud.storagemgmt.localdomain                |
    +--------------+---------------------------------------------------------------+
  2. 특정 호스트를 필터링하려면 다음 명령을 실행합니다.

    (undercloud) [stack@host01 ~]$ openstack stack output show overcloud HostsEntry -c output_value -f value | grep overcloud-controller-0
    
    172.17.0.12 overcloud-controller-0.localdomain overcloud-controller-0
    10.8.145.18 overcloud-controller-0.external.localdomain overcloud-controller-0.external
    172.17.0.12 overcloud-controller-0.internalapi.localdomain overcloud-controller-0.internalapi
    172.18.0.12 overcloud-controller-0.storage.localdomain overcloud-controller-0.storage
    172.21.2.13 overcloud-controller-0.storagemgmt.localdomain overcloud-controller-0.storagemgmt
    172.16.0.19 overcloud-controller-0.tenant.localdomain overcloud-controller-0.tenant
    10.8.146.13 overcloud-controller-0.management.localdomain overcloud-controller-0.management
    10.8.146.13 overcloud-controller-0.ctlplane.localdomain overcloud-controller-0.ctlplane
  3. 호스트를 베어 메탈 노드에 매핑하려면 다음 명령을 실행합니다.

    (undercloud) [stack@host01 ~]$ openstack baremetal node list --fields uuid name instance_info -f json
    [
      {
        "UUID": "c0d2568e-1825-4d34-96ec-f08bbf0ba7ae",
        "Instance Info": {
          "root_gb": "40",
          "display_name": "overcloud-compute-0",
          "image_source": "24a33990-e65a-4235-9620-9243bcff67a2",
          "capabilities": "{\"boot_option\": \"local\"}",
          "memory_mb": "4096",
          "vcpus": "1",
          "local_gb": "557",
          "configdrive": "******",
          "swap_mb": "0",
          "nova_host_id": "host01.lab.local"
        },
        "Name": "host2"
      },
      {
        "UUID": "8c3faec8-bc05-401c-8956-99c40cdea97d",
        "Instance Info": {
          "root_gb": "40",
          "display_name": "overcloud-controller-0",
          "image_source": "24a33990-e65a-4235-9620-9243bcff67a2",
          "capabilities": "{\"boot_option\": \"local\"}",
          "memory_mb": "4096",
          "vcpus": "1",
          "local_gb": "557",
          "configdrive": "******",
          "swap_mb": "0",
          "nova_host_id": "host01.lab.local"
        },
        "Name": "host3"
      }
    ]

6.4. 가상 네트워크 인터페이스 연결 및 연결 해제

베어 메탈 프로비저닝 서비스에는 가상 네트워크 인터페이스 간 매핑을 관리하는 데 사용할 수 있는 API가 있습니다. 예를 들어 OpenStack Networking 서비스 및 NIC(물리 인터페이스)의 인터페이스가 있습니다. 각 베어 메탈 프로비저닝 노드에 대해 이러한 인터페이스를 구성하여 VIF(가상 네트워크 인터페이스)를 PF(실제 네트워크 인터페이스) 매핑 논리로 설정할 수 있습니다. 인터페이스를 구성하려면 openstack baremetal node vif* 명령을 사용합니다.

사전 요구 사항

절차

  1. 현재 베어 메탈 노드에 연결된 VIF ID를 나열합니다.

    $ openstack baremetal node vif list baremetal-0
    +--------------------------------------+
    | ID                                   |
    +--------------------------------------+
    | 4475bc5a-6f6e-466d-bcb6-6c2dce0fba16 |
    +--------------------------------------+
  2. VIF가 연결되면 베어 메탈 프로비저닝 서비스는 OpenStack Networking 서비스의 가상 포트를 실제 포트의 실제 MAC 주소로 업데이트합니다. 이 포트 주소를 확인합니다.

    $ openstack port show 4475bc5a-6f6e-466d-bcb6-6c2dce0fba16 -c mac_address -c fixed_ips
    +-------------+-----------------------------------------------------------------------------+
    | Field       | Value                                                                       |
    +-------------+-----------------------------------------------------------------------------+
    | fixed_ips   | ip_address='192.168.24.9', subnet_id='1d11c677-5946-4733-87c3-23a9e06077aa' |
    | mac_address | 00:2d:28:2f:8d:95                                                           |
    +-------------+-----------------------------------------------------------------------------+
  3. baremetal-0 노드를 생성한 네트워크에 새 포트를 생성합니다.

    $ openstack port create --network baremetal --fixed-ip ip-address=192.168.24.24 baremetal-0-extra
  4. 인스턴스에서 포트를 제거합니다.

    $ openstack server remove port overcloud-baremetal-0 4475bc5a-6f6e-466d-bcb6-6c2dce0fba16
  5. IP 주소가 목록에 더 이상 존재하지 않는지 확인합니다.

    $ openstack server list
  6. 노드에 연결된 VIF가 있는지 확인합니다.

    $ openstack baremetal node vif list baremetal-0
    $ openstack port list
  7. 새로 생성된 포트를 추가합니다.

    $ openstack server add port overcloud-baremetal-0 baremetal-0-extra
  8. 새 IP 주소에 새 포트가 표시되는지 확인합니다.

    $ openstack server list
    +--------------------------------------+-------------------------+--------+------------------------+----------------+---------+
    | ID                                   | Name                    | Status | Networks               | Image          | Flavor  |
    +--------------------------------------+-------------------------+--------+------------------------+----------------+---------+
    | 53095a64-1646-4dd1-bbf3-b51cbcc38789 | overcloud-controller-2  | ACTIVE | ctlplane=192.168.24.7  | overcloud-full | control |
    | 3a1bc89c-5d0d-44c7-a569-f2a3b4c73d65 | overcloud-controller-0  | ACTIVE | ctlplane=192.168.24.8  | overcloud-full | control |
    | 6b01531a-f55d-40e9-b3a2-6d02be0b915b | overcloud-controller-1  | ACTIVE | ctlplane=192.168.24.16 | overcloud-full | control |
    | c61cc52b-cc48-4903-a971-073c60f53091 | overcloud-novacompute-0overcloud-baremetal-0 | ACTIVE | ctlplane=192.168.24.24 | overcloud-full | compute |
    +--------------------------------------+-------------------------+--------+------------------------+----------------+---------+
  9. VIF ID가 새 포트의 UUID인지 확인합니다.

    $ openstack baremetal node vif list baremetal-0
    +--------------------------------------+
    | ID                                   |
    +--------------------------------------+
    | 6181c089-7e33-4f1c-b8fe-2523ff431ffc |
    +--------------------------------------+
  10. OpenStack Networking 포트 MAC 주소가 업데이트되고 베어 메탈 프로비저닝 서비스 포트 중 하나와 일치하는지 확인합니다.

    $ openstack port show 6181c089-7e33-4f1c-b8fe-2523ff431ffc -c mac_address -c fixed_ips
    +-------------+------------------------------------------------------------------------------+
    | Field       | Value                                                                        |
    +-------------+------------------------------------------------------------------------------+
    | fixed_ips   | ip_address='192.168.24.24', subnet_id='1d11c677-5946-4733-87c3-23a9e06077aa' |
    | mac_address | 00:2d:28:2f:8d:95                                                            |
    +-------------+------------------------------------------------------------------------------+
  11. 새 IP 주소를 인식하도록 베어 메탈 노드를 재부팅합니다.

    $ openstack server reboot overcloud-baremetal-0

    인터페이스를 분리하거나 연결한 후 베어 메탈 OS는 변경된 네트워크 인터페이스를 제거, 추가 또는 수정합니다. 포트를 교체하면 DHCP 요청이 새 IP 주소를 가져오지만 이전 DHCP 리스가 여전히 유효하기 때문에 시간이 걸릴 수 있습니다. 이러한 변경 사항을 즉시 시작하려면 베어 메탈 호스트를 재부팅합니다.

6.5. 베어 메탈 프로비저닝 서비스에 대한 알림 구성

서비스 내에서 발생하는 다양한 이벤트에 대한 알림을 표시하도록 베어 메탈 프로비저닝 서비스(ironic)를 구성할 수 있습니다. 외부 서비스는 청구, 데이터 저장소 모니터링 및 기타 목적으로 이러한 알림을 사용할 수 있습니다. 베어 메탈 프로비저닝 서비스에 대한 알림을 활성화하려면 ironic.conf 구성 파일에서 다음 옵션을 설정해야 합니다.

사전 요구 사항

절차

  • [DEFAULT] 섹션의 notification_level 옵션은 알림을 전송하는 최소 우선 순위 수준을 결정합니다. 이 옵션의 값을 debug,info,warning,error 또는 critical 으로 설정할 수 있습니다. 옵션이 warning으로 설정되면 우선 순위 수준 warning ,error 또는 critical 이 있는 모든 알림이 전송되지만 우선 순위 수준 debug 또는 info 는 알림이 전송되지 않습니다. 이 옵션을 설정하지 않으면 알림이 전송되지 않습니다. 사용 가능한 각 알림의 우선 순위 수준은 아래에 설명되어 있습니다.
  • [oslo _messaging_notifications] 섹션의 transport_ url 옵션은 알림을 보낼 때 사용되는 메시지 버스를 결정합니다. 설정되지 않은 경우 RPC에 사용되는 기본 전송이 사용됩니다.

모든 알림은 메시지 버스의 ironic_versioned_notifications 주제에서 발송됩니다. 일반적으로 메시지 버스를 트래버스하는 각 메시지 유형은 메시지 내용을 설명하는 주제와 연결됩니다.

6.6. 자동 전원 오류 복구 구성

베어 메탈 프로비저닝 서비스(ironic)에는 노드의 전원, 정리 및 복구 중단 오류를 기록하는 문자열 필드 오류가 있습니다.

표 6.1. Ironic 노드 오류

오류설명

전원 실패

노드는 최대 재시도 횟수를 초과하는 전원 동기화 실패로 인해 유지보수 모드입니다.

오류 정리

노드는 정리 작업이 실패하여 유지보수 모드입니다.

복구 중단 실패

복구가 중단되는 동안 노드가 정리 작업이 실패하여 노드가 유지보수 모드에 있습니다.

none

결함이 없습니다.

Conductor는 이 필드의 값을 주기적으로 확인합니다. 컨덕터에서 전원 실패 상태를 감지하고 노드에 대한 전원을 복원할 수 있으면 노드가 유지 관리 모드에서 제거되고 작업으로 복원됩니다.

참고

Operator가 노드를 유지보수 모드로 수동으로 배치하면 컨덕터(conductor)가 유지보수 모드에서 노드를 자동으로 제거하지 않습니다.

기본 간격은 300초이지만 hieradata를 사용하여 director와 함께 이 간격을 구성할 수 있습니다.

사전 요구 사항

절차

  • 다음 hieradata를 포함하여 사용자 정의 복구 간격을 구성합니다.

    ironic::conductor::power_failure_recovery_interval

    자동 전원 폴트 복구를 비활성화하려면 값을 0 으로 설정합니다.

6.7. 오버클라우드 노드 세부 검사

오버클라우드 노드의 세부 검사를 수행하여 노드의 사양을 director에 식별하고 저장합니다.

절차

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

    $ source ~/overcloudrc
  3. 인트로스펙션 명령을 실행합니다.

    $ openstack baremetal introspection start [--wait] <NODENAME>

    <NODENAME>을 검사할 노드의 이름 또는 UUID로 바꿉니다.

  4. 인트로스펙션 상태를 확인합니다.

    $ openstack baremetal introspection status <NODENAME>

    <NODENAME>을 노드의 이름 또는 UUID로 바꿉니다.

다음 단계

  • 인트로스펙션 데이터를 추출합니다.

    $ openstack baremetal introspection data save <NODE-UUID>

    <NODENAME>을 노드의 이름 또는 UUID로 바꿉니다.

참고

Red Hat OpenStack Platform 16.1에서 ipmitool 2.0 사용. 일부 하드웨어에서는 다음 오류로 인해 인트로스펙션 또는 일반 전원 제어 작업이 실패할 수 있습니다.

Error in open session response message : no matching cipher suite
Error: Unable to establish IPMI v2 / RMCP+ session

이 경우 인트로스펙션을 실행하기 전에 IPMI 암호화 제품군을 버전 3으로 설정해야 합니다.

$ openstack baremetal node set <node-UUID> --driver-info ipmi_cipher_suite=3

7장. Cinder 볼륨에서 부팅

블록 스토리지 서비스(cinder)에서 볼륨을 생성하고 이러한 볼륨을 베어 메탈 프로비저닝 서비스(ironic)로 생성한 베어 메탈 인스턴스에 연결할 수 있습니다.

7.1. 베어 메탈 노드의 Cinder 볼륨 부팅

OpenStack 블록 스토리지(cinder)에 저장된 블록 스토리지 장치에서 베어 메탈 노드를 부팅할 수 있습니다. OpenStack Bare Metal(ironic)은 iSCSI 인터페이스를 통해 베어 메탈 노드를 볼륨에 연결합니다.

Ironic에서는 Overcloud를 배포하는 동안 이 기능을 활성화합니다. 그러나 오버클라우드를 배포하기 전에 다음 조건을 고려하십시오.

  • 오버클라우드를 사용하려면 cinder iSCSI 백엔드를 활성화해야 합니다. Overcloud 배포 중에 CinderEnableIscsiBackend heat 매개변수를 true로 설정합니다.
  • Red Hat Ceph Storage 백엔드에서는 cinder 볼륨 부팅 기능을 사용할 수 없습니다.
  • 부팅 디스크에 rd.iscsi.firmware=1 커널 매개 변수를 설정해야 합니다.

7.2. cinder 볼륨 부팅을 위한 노드 구성

cinder 볼륨에서 성공적으로 부팅하려면 각 베어 메탈 노드에 특정 옵션을 구성해야 합니다.

절차

  1. stack 사용자로 언더클라우드에 로그인합니다.
  2. 오버클라우드 자격 증명을 가져옵니다.

    $ source ~/overcloudrc
  3. 선택한 노드의 iscsi_boot 기능을 true 로, storage-interfacecinder 로 설정합니다.

    $ openstack baremetal node set --property capabilities=iscsi_boot:true --storage-interface cinder <NODEID>

    <NODEID> 를 선택한 노드의 ID로 바꿉니다.

  4. 노드의 iSCSI 커넥터를 생성합니다.

    $ openstack baremetal volume connector create --node <NODEID> --type iqn --connector-id iqn.2010-10.org.openstack.node<NUM>

    각 노드의 커넥터 ID는 고유해야 합니다. 이 예제에서 커넥터는 iqn.2010-10.org.openstack.node<NUM> 입니다. 여기서 <NUM> 은 각 노드의 증가된 번호입니다.

7.3. 부팅 디스크에서 iSCSI 커널 매개변수 구성

이미지의 커널에서 iSCSI 부팅을 활성화해야 합니다. 이를 수행하려면 QCOW2 이미지를 마운트하고 이미지에서 iSCSI 구성 요소를 활성화합니다.

사전 요구 사항

  1. Red Hat Enterprise Linux QCOW2 이미지를 다운로드하여 언더클라우드의 /home/stack/ 디렉터리에 복사합니다. 다음 페이지에서 QCOW2 형식으로 Red Hat Enterprise Linux KVM 이미지를 다운로드할 수 있습니다.

절차

  1. stack 사용자로 언더클라우드에 로그인합니다.
  2. QCOW2 이미지를 마운트하고 root 사용자로 액세스합니다.

    1. nbd 커널 모듈을 로드합니다.

      $ sudo modprobe nbd
    2. QCOW 이미지를 /dev/nbd0 으로 연결합니다.

      $ sudo qemu-nbd --connect=/dev/nbd0 <IMAGE>
    3. NBD의 파티션을 확인합니다.

      $ sudo fdisk /dev/nbd0 -l

      새로운 Red Hat Enterprise Linux QCOW2 이미지에는 하나의 파티션만 포함되어 있으며, 일반적으로 NBD에서 이름이 /dev/nbd0p1 입니다.

    4. 이미지의 마운트 지점을 생성합니다.

      mkdir /tmp/mountpoint
    5. 이미지를 마운트합니다.

      sudo mount /dev/nbd0p1 /tmp/mountpoint/
    6. 이미지가 호스트의 장치 정보에 액세스할 수 있도록 dev 디렉터리를 마운트합니다.

      sudo mount -o bind /dev /tmp/mountpoint/dev
    7. 루트 디렉터리를 마운트 지점으로 변경합니다.

      sudo chroot /tmp/mountpoint /bin/bash
  3. 이미지에서 iSCSI를 구성합니다.

    참고

    이 단계의 일부 명령은 다음 오류를 보고할 수 있습니다.

    lscpu: cannot open /proc/cpuinfo: No such file or directory

    이 오류는 중요하지 않으며 오류를 무시할 수 있습니다.

    1. resolv.conf 파일을 임시 위치로 이동합니다.

      # mv /etc/resolv.conf /etc/resolv.conf.bak
    2. 임시 resolv.conf 파일을 생성하여 Red Hat Content Delivery Network에 대한 DNS 요청을 해결합니다. 이 예제에서는 이름 서버에 8.8.8.8 을 사용합니다.

      # echo "nameserver 8.8.8.8" > /etc/resolv.conf
    3. 마운트된 이미지를 Red Hat Content Delivery Network에 등록합니다.

      # subscription-manager register

      명령에서 메시지를 표시하면 사용자 이름과 암호를 입력합니다.

    4. Red Hat Enterprise Linux가 포함된 서브스크립션을 연결합니다.

      # subscription-manager list --all --available
      # subscription-manager attach --pool <POOLID>

      <POOLID> 를 서브스크립션의 풀 ID로 바꿉니다.

    5. 기본 리포지토리를 비활성화합니다.

      # subscription-manager repos --disable "*"
    6. Red Hat Enterprise Linux 리포지토리를 활성화합니다.

      • Red Hat Enterprise Linux 7:

        # subscription-manager repos --enable "rhel-7-server-rpms"
      • Red Hat Enterprise Linux 8:

        # subscription-manager repos --enable "rhel-8-for-x86_64-baseos-eus-rpms"
    7. iscsi-initiator-utils 패키지를 설치합니다.

      # yum install -y iscsi-initiator-utils
    8. 마운트된 이미지를 등록 취소합니다.

      # subscription-manager unregister
    9. original resolv.conf 파일을 복원합니다.

      # mv /etc/resolv.conf.bak /etc/resolv.conf
    10. 마운트된 이미지의 커널 버전을 확인합니다.

      # rpm -qa kernel

      예를 들어 출력이 kernel-3.10.0-1062.el7.x86_64 인 경우 커널 버전은 3.10.0-1062.el7.x86_64 입니다. 다음 단계에서 이 커널 버전을 확인합니다.

      참고

      새 Red Hat Enterprise Linux QCOW2 이미지에는 하나의 커널 버전만 설치되어 있습니다. 둘 이상의 커널 버전이 설치되어 있으면 최신 버전을 사용합니다.

    11. networkiscsi dracut 모듈을 initramfs 이미지에 추가합니다.

      # dracut --force --add "network iscsi" /boot/initramfs-<KERNELVERSION>.img <KERNELVERSION>

      <KERNELVERSION>rpm -qa 커널에서 얻은 버전 번호로 바꿉니다. 다음 예제에서는 커널 버전으로 3.10.0-1062.el7.x86_64 를 사용합니다.

      # dracut --force --add "network iscsi" /boot/initramfs-3.10.0-1062.el7.x86_64.img 3.10.0-1062.el7.x86_64
    12. /etc/default/grub 구성 파일과 add rd.iscsi.firmware=1GRUB_CMDLINE_LINUX 매개변수에 편집합니다.

      # vi /etc/default/grub

      다음 예제에서는 added rd.iscsi.firmware=1 커널 인수가 있는 GRUB_CMDLINE_LINUX 매개변수를 보여줍니다.

      GRUB_CMDLINE_LINUX="console=tty0 crashkernel=auto console=ttyS0,115200n8 no_timer_check net.ifnames=0 rd.iscsi.firmware=1"

      이러한 변경 사항을 저장합니다.

      참고

      이 단계에서 grub 메뉴 구성을 다시 빌드하지 마십시오. 이 절차의 이후 단계에서는 임시 가상 시스템으로 grub 메뉴를 다시 빌드합니다.

    13. 마운트된 이미지를 호스트 운영 체제로 다시 종료합니다.

      # exit
  4. 이미지를 마운트 해제합니다.

    1. 임시 마운트 지점에서 dev 디렉터리를 마운트 해제합니다.

      $ sudo umount /tmp/mountpoint/dev
    2. 마운트 지점에서 이미지를 마운트 해제합니다.

      $ sudo umount /tmp/mountpoint
    3. /dev/nbd0/ 에서 QCOW2 이미지의 연결을 끊습니다.

      $ sudo qemu-nbd --disconnect /dev/nbd0
  5. 이미지에서 grub 메뉴 구성을 다시 빌드합니다.

    1. libguestfs-tools 패키지를 설치합니다.

      $ sudo yum -y install libguestfs-tools
      중요

      언더클라우드에 libguestfs-tools 패키지를 설치하는 경우 iscsid.socket 을 비활성화하여 언더클라우드의 tripleo_iscsid 서비스와 포트 충돌을 방지합니다.

      $ sudo systemctl disable --now iscsid.socket
    2. QEMU를 직접 사용하도록 libguestfs 백엔드를 설정합니다.

      $ export LIBGUESTFS_BACKEND=direct
    3. 이미지의 grub 구성을 업데이트합니다.

      $ guestfish -a <IMAGE> -m /dev/sda1 sh "/sbin/grub2-mkconfig -o /boot/grub2/grub.cfg"

7.4. cinder에서 부팅 볼륨 생성 및 사용

iSCSI 지원 이미지를 OpenStack Image Storage(glance)에 업로드하고 OpenStack 블록 스토리지(cinder)에서 부팅 볼륨을 생성해야 합니다.

절차

  1. stack 사용자로 언더클라우드에 로그인합니다.
  2. iSCSI 사용 이미지를 glance에 업로드합니다.

    $ openstack image create --disk-format qcow2 --container-format bare --file rhel-server-7.7-x86_64-kvm.qcow2 rhel-server-7.7-iscsi
  3. 이미지에서 볼륨을 생성합니다.

    $ openstack volume create --size 10 --image rhel-server-7.7-iscsi --bootable rhel-test-volume
  4. cinder에서 부팅 볼륨을 사용하는 베어 메탈 인스턴스를 생성합니다.

    $ openstack server create --flavor baremetal --volume rhel-test-volume --key default rhel-test

8장. ML2 networking-ansible

Networking 서비스(neutron)를 사용하여 오버클라우드에서 networking-ansible ML2 드라이버를 활성화 및 구성하고 베어 메탈 프로비저닝 서비스(ironic)와 통합할 수 있습니다.

8.1. ML2(Modular Layer 2) networking-ansible

OpenStack Networking(neutron)에는 networking-ansible 이 포함되어 있으며, 이는 Ansible Engine Networking을 사용하여 네트워크 스위치를 관리하는 ML2 드라이버입니다. 이 드라이버는 OpenStack Bare Metal(ironic)도 통합하여 베어 메탈 게스트의 스위치 포트에서 VLAN을 구성합니다. 즉, VLAN neutron 네트워크를 사용하는 베어 메탈 게스트로 인해 이 드라이버는 Ansible Engine Networking을 사용하여 물리적 스위치를 구성합니다.

현재 networking-ansible 드라이버에는 다음 기능이 포함됩니다.

  • RHOSP(Red Hat OpenStack Platform)에서 네트워크를 생성할 때 스위치에 VLAN을 정의합니다.
  • RHOSP에서 포트를 생성하거나 업데이트할 때 스위치의 액세스 포트에 VLAN을 할당합니다.
  • RHOSP에서 포트를 삭제할 때 스위치의 액세스 포트에서 VLAN 제거

8.2. networking-ansible 네트워킹 요구 사항

networking-ansible 기능을 활성화하려면 환경에 다음 네트워킹 구성이 포함되어야 합니다.

  • Ansible 네트워크 자동화 지원을 통한 네트워크 스위치:

    • Juniper Networks(junos)
    • pvc Extensible Operating System (eos)
중요

EUS (Extensible Operating System)지원은 이번 릴리스에서 기술 프리뷰로 제공되므로 Red Hat에서 완전히 지원하지 않습니다. 테스트 용도로만 사용해야 하며 프로덕션 환경에 배포해서는 안 됩니다. 기술 프리뷰 기능에 대한 자세한 내용은 적용 범위 상세 정보를 참조하십시오.

  • Ansible 네트워크 자동화가 장치와 상호 작용할 수 있도록 네트워크 스위치에는 SSH 사용자가 필요합니다. 이 사용자는 스위치에 대해 다음과 같은 권한이 필요합니다.

    • 액세스 모드
    • 포트에 VLAN 할당
    • VLAN 만들기

    보안을 위해 SSH 사용자에게 스위치에 대한 관리자 액세스 권한을 제공하지 마십시오.

  • 스위치를 사용할 VLAN을 준비합니다. VLAN을 준비하려면 스위치에서 각 VLAN을 만든 다음 각 VLAN을 삭제합니다.
  • 베어 메탈 게스트용으로 예약된 네트워크 스위치 포트는 처음에는 인트로스펙션을 위해 전용 네트워크에 연결하기 위한 구성이 필요합니다. 이 포트 외에도 이러한 포트에는 추가 구성이 필요하지 않습니다.

8.3. networking-anible에 대한 OpenStack Bare Metal(ironic) 요구 사항

networking-ansible 드라이버는 Openstack Bare Metal(ironic) 서비스와 통합됩니다. 성공적으로 통합을 수행하려면 다음 권장 사항에 따라 베어 메탈 프로비저닝 서비스(ironic)를 오버클라우드에 배포합니다.

  • 오버클라우드에는 프로비저닝 네트워크가 필요합니다. 다음 옵션 중 하나를 사용합니다.

    • ironic 서비스를 위한 브리지된 네트워크입니다.
    • ironic 서비스에 대한 사용자 지정 구성 가능 네트워크입니다.

    프로비저닝 네트워크 구성에 대한 자세한 내용은 3장. 베어 메탈 프로비저닝 서비스를 사용하여 IPv4 오버클라우드 배포 또는 4장. 베어 메탈 프로비저닝 서비스를 사용하여 IPv6 오버클라우드 배포 을 참조하십시오.

  • 오버클라우드에는 프로비저닝 프로세스 후에 베어 메탈 시스템이 사용할 테넌트 네트워크가 필요합니다. 이 가이드의 예제에서는 br-baremetal 브리지에 매핑된 기본 baremetal 네트워크를 사용합니다. 또한 이 네트워크에는 VLAN ID 범위가 필요합니다. 다음 heat 매개변수는 이 가이드의 예제에 맞게 이러한 값을 설정합니다.

    parameter_defaults:
      NeutronNetworkVLANRanges: baremetal:1200:1299
      NeutronFlatNetworks: datacentre,baremetal
      NeutronBridgeMappings: datacentre:br-ex,baremetal:br-baremetal
  • 오버클라우드는 인트로스펙션 서비스를 사용하여 특정 하드웨어 세부 정보를 자동으로 식별하고 사용할 다른 서비스에 매핑합니다. ironic 인트로스펙션 서비스를 활성화하여 networking-ansible 에서 사용할 인터페이스 간 세부 정보를 매핑하는 것이 좋습니다. 이 작업을 수동으로 수행할 수도 있습니다.

베어 메탈 프로비저닝 서비스(ironic) 배포에 대한 자세한 내용은 3장. 베어 메탈 프로비저닝 서비스를 사용하여 IPv4 오버클라우드 배포 또는 4장. 베어 메탈 프로비저닝 서비스를 사용하여 IPv6 오버클라우드 배포 을 참조하십시오.

8.4. networking-ansible ML2 기능 활성화

오버클라우드에서 networking-ansible ML2 드라이버를 활성화하려면 배포에 두 개의 환경 파일을 추가해야 합니다.

/usr/share/openstack-tripleo-heat-templates/environments/neutron-ml2-ansible.yaml
이 파일은 networking-ansible 드라이버를 활성화하고 네트워크 유형을 vlan 으로 설정합니다. 이 파일은 코어 heat 템플릿 컬렉션에 이미 존재합니다.
/home/stack/templates/ml2-ansible-hosts.yaml
스위치에 대한 세부 정보가 포함된 파일. 이 파일을 수동으로 생성합니다.

절차

  1. /home/stack/templates/ml2-ansible-hosts.yaml 을 생성하고 다음 초기 콘텐츠를 추가합니다.

    parameter_defaults:
      ML2HostConfigs:
  2. ML2HostConfigs 매개 변수에는 스위치에 대한 세부 정보가 있는 dict 값이 필요합니다. dict 의 각 초기 키는 스위치의 이름입니다. 이 값은 OpenStack Networking(neutron) ML2 구성의 특정 ansible:[switchname] 섹션을 정의합니다. 각 스위치 이름 키에는 실제 스위치 세부 정보가 포함된 자체 dict 가 필요합니다. 예를 들어 세 개의 스위치를 구성하려면 세 개의 스위치 키를 추가합니다.

    parameter_defaults:
      ML2HostConfigs:
        switch1:
          [SWITCH DETAILS]
        switch2:
          [SWITCH DETAILS]
        switch3:
          [SWITCH DETAILS]
  3. 각 스위치에는 dict 에 특정 키 값 쌍이 필요합니다.

    ansible_network_os

    (필수) 스위치의 운영 체제입니다. 옵션에는 junoseos 가 포함됩니다.

    중요

    EUS (Extensible Operating System)지원은 이번 릴리스에서 기술 프리뷰로 제공되므로 Red Hat에서 완전히 지원하지 않습니다. 테스트 용도로만 사용해야 하며 프로덕션 환경에 배포해서는 안 됩니다. 기술 프리뷰 기능에 대한 자세한 내용은 적용 범위 상세 정보를 참조하십시오.

    ansible_host
    (필수) 스위치의 IP 또는 호스트 이름입니다.
    ansible_user
    (필수) Ansible이 스위치에 액세스하는 데 사용하는 사용자입니다.
    ansible_ssh_pass
    (필수) Ansible이 스위치에 액세스하는 데 사용하는 SSH 암호입니다.
    mac
    네트워크 장치의 MAC ID 섀시입니다. LLDP(링크 계층 검색 프로토콜) MAC 주소 값을 ML2HostConfigs 구성에 정의된 스위치 이름에 매핑하는 데 사용됩니다. 이 값은 인트로스펙션을 사용하여 자동 포트 구성을 수행할 때 필수 값입니다.
    manage_vlans
    OpenStack Networking(neutron)이 실제 장치에서 VLAN의 생성 및 삭제를 제어하는지 여부를 정의하는 부울 변수입니다. 이 기능을 사용하면 스위치에서 Neutron 네트워크에 각각 ID가 있는 VLAN을 만들고 삭제합니다. 스위치에 이러한 VLAN을 사전 정의되어 있고, 스위치에서 VLAN을 생성하거나 삭제하는 데 Neutron이 필요하지 않은 경우 이 매개변수를 false로 설정합니다. 기본값은 true입니다.
  4. 다음 예제에서는 전체 ML2HostConfigs 매개변수에서 이러한 값을 해당 키에 매핑하는 방법을 보여줍니다.

    parameter_defaults:
      ML2HostConfigs:
        switch1:
          ansible_network_os: juno
          ansible_host: 10.0.0.1
          ansible_user: ansible
          ansible_ssh_pass: "p@55w0rd!"
          mac: 01:23:45:67:89:AB
          manage_vlans: false
  5. /home/stack/templates/ml2-ansible-hosts.yaml 파일을 저장합니다.
  6. 오버클라우드 배포 명령을 실행하는 경우 -e 옵션을 사용하여 /usr/share/openstack-tripleo-heat-templates/environments/neutron-ml2-ansible.yaml/home/stack/templates/ml2-ansible-hosts.yaml 파일을 포함합니다. 다음 예제에서는 이러한 파일을 포함하는 방법을 보여줍니다.

    $ openstack overcloud deploy --templates \
      ...
      -e /usr/share/openstack-tripleo-heat-templates/environments/neutron-ml2-ansible.yaml \
      -e /home/stack/templates/ml2-ansible-hosts.yaml \
      ...

director는 neutron_api 컨테이너에서 OpenStack Networking(neutron) API의 일부로 드라이버를 활성화합니다.

8.5. networking-ansible 네트워크 구성

베어 메탈 프로비저닝 및 networking-ansible 드라이버를 활성화하여 오버클라우드를 배포한 후 베어 메탈 노드에 대한 프로비저닝 및 테넌트 네트워크를 생성해야 합니다. 또한 요구 사항에 따라 액세스 모드 또는 트렁크 모드에서 베어 메탈 노드의 포트를 구성해야 합니다.

액세스 모드
액세스 모드에서 스위치 포트는 하나의 VLAN만 트래픽을 전송하고 단일 브로드캐스트 도메인에서 작동합니다. 액세스 포트에 도착하는 모든 트래픽은 포트에 할당된 VLAN에 속합니다.
트렁크 모드

트렁크 모드에서 스위치 포트는 둘 이상의 VLAN에 속할 수 있습니다. 트렁크 모드에서 스위치 포트를 사용하여 VLAN 그룹의 트래픽을 전송하거나 여러 스위치 간에 트래픽을 VLAN으로 교환하려는 경우 가능합니다.

중요

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

베어 메탈 서비스(ironic)는 networking-ansible 을 사용하여 프로비저닝 프로세스가 성공적으로 완료될 수 있도록 베어 메탈 게스트의 스위치 포트를 ironic 프로비저닝 네트워크에 할당합니다. 프로비저닝이 완료되면 ironic은 베어 메탈 게스트의 스위치 포트를 네트워킹 서비스(neutron)가 베어 메탈 게스트의 테넌트 네트워크에 할당하는 VLAN에 할당합니다.

8.5.1. networking-ansible 액세스 모드에서 네트워크 구성

베어 메탈 프로비저닝 및 networking-ansible 드라이버가 활성화된 오버클라우드를 배포한 후 베어 메탈 노드에 대해 다음 네트워크를 생성합니다.

프로비저닝 네트워크
베어 메탈 시스템은 이 네트워크를 사용하여 초기 생성을 수행합니다.
테넌트 네트워크
베어 메탈 시스템은 프로비저닝 후 이 네트워크로 전환하고 내부 통신에 이 네트워크를 사용합니다.

절차

  1. 프로비저닝 네트워크 및 서브넷을 만듭니다. 이는 사용 중인 프로비저닝 네트워크의 유형에 따라 다릅니다. 프로비저닝 네트워크 구성에 대한 자세한 내용은 5장. 배포 후 베어 메탈 프로비저닝 서비스 구성 을 참조하십시오.
  2. 테넌트 네트워크 및 서브넷을 만듭니다.

    $ openstack network create --provider-network-type vlan --provider-physical-network baremetal tenant-net
    $ openstack subnet create --network tenant-net --subnet-range 192.168.3.0/24 --allocation-pool start=192.168.3.10,end=192.168.3.20 tenant-subnet

    networking- ansible 기능을 위해 --provider-network-type 옵션을 vlan 으로 설정해야 합니다.

8.5.2. 액세스 모드에서 베어 메탈 게스트의 포트 구성

베어 메탈 게스트는 스위치에 연결하기 위해 포트 정보가 필요합니다. 이 작업을 수행하는 방법에는 다음 두 가지가 있습니다.

  • 자동: 노드 세부 검사. 자동 메서드를 사용하려면 각 스위치의 mac 값을 ML2HostConfigs 매개변수의 일부로 설정합니다.
  • 수동: OpenStack Networking(neutron) 포트 구성을 설정합니다. 오버클라우드에 베어 메탈 인트로스펙션 기능이 포함되지 않은 경우 이 방법을 사용합니다.

절차

  • 자동:

    1. 인트로스펙션 명령을 실행합니다.

      $ openstack baremetal introspection start [--wait] <NODENAME>

      베어 메탈 노드는 인트로스펙션 중에 스위치의 MAC 주소를 가져옵니다. networking-ansible ML2 드라이버는 이 MAC 주소를 사용하여 ML2HostConfigs 매개변수의 해당 스위치의 mac 매개 변수로 정의한 동일한 MAC 주소에 매핑합니다.

    2. 인트로스펙션이 완료될 때까지 기다립니다.
  • 수동:

    1. 베어 메탈 노드의 포트를 생성합니다. 다음 예제 명령을 기반으로 포트를 생성합니다.

      $ openstack baremetal port create [NODE NIC MAC] --node [NODE UUID] \
          --local-link-connection port_id=[SWICH PORT ID] \
          --local-link-connection switch_info=[SWITCH NAME] \
          --local-link-connection switch_id=[SWITCH MAC]

      대괄호로 다음 값을 환경 세부 사항으로 바꿉니다.

      [노드 NIC MAC]
      스위치에 연결된 NIC의 MAC 주소입니다.
      --node [NODE UUID]
      새 포트를 사용하는 노드의 UUID입니다.
      --local-link-connection port_id=[SWITCH 포트 ID]
      베어 메탈 노드에 연결하는 스위치의 포트 ID입니다.
      --local-link-connection switch_info=[SWITCH NAME]
      베어 메탈 노드에 연결하는 스위치의 이름입니다. 스위치 이름은 ML2HostConfigs 매개변수에 정의된 각 스위치 이름과 일치해야 합니다.
      --local-link-connection switch_id=[SWITCH MAC]
      스위치의 MAC 주소입니다. ML2HostConfigs 매개변수의 스위치 구성의 해당 mac 값과 일치해야 합니다. 이는 switch_info 를 사용하는 대체 옵션입니다.

8.5.3. trunk 모드에서 networking-ansible을 위한 네트워크 구성

중요

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

베어 메탈 프로비저닝 및 networking-ansible 드라이버가 활성화된 오버클라우드를 배포한 후 베어 메탈 노드에 대해 다음 네트워크를 생성합니다.

프로비저닝 네트워크
베어 메탈 시스템은 이 네트워크를 사용하여 초기 생성을 수행합니다.
테넌트 네트워크
베어 메탈 시스템은 프로비저닝 후 이 네트워크로 전환하고 내부 통신에 이 네트워크를 사용합니다.

절차

  1. 프로비저닝 네트워크 및 서브넷을 만듭니다. 이는 사용 중인 프로비저닝 네트워크의 유형에 따라 다릅니다. 프로비저닝 네트워크 구성에 대한 자세한 내용은 5장. 배포 후 베어 메탈 프로비저닝 서비스 구성 을 참조하십시오.
  2. 게스트가 연결된 물리적 네트워크를 사용하는 각 네트워크에 대한 기본 테넌트 VLAN 네트워크, 보조 테넌트 네트워크 및 서브넷을 생성합니다.

    $ openstack network create --provider-network-type vlan --provider-physical-network baremetal primary-tenant-net
    $ openstack network create --provider-network-type vlan --provider-physical-network baremetal secondary-tenant-net
    $ openstack subnet create --network primary-tenant-net --subnet-range 192.168.3.0/24 --allocation-pool start=192.168.3.10,end=192.168.3.20 primary-tenant-subnet
    $ openstack subnet create --network secondary-tenant-net --subnet-range 192.168.7.0/24 --allocation-pool start=192.168.7.10,end=192.168.7.20 secondary-tenant-subnet

    networking- ansible 기능을 위해 --provider-network-type 옵션을 vlan 으로 설정해야 합니다.

8.5.4. 트렁크 모드에서 베어 메탈 게스트의 포트 구성

중요

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

베어 메탈 게스트에는 단일 스위치 포트가 있는 여러 네트워크에 배포하기 위해 베어 메탈 프로비저닝 서비스(ironic)를 사용할 수 있도록 스위치에 연결하는 포트 정보가 필요합니다. 스위치 포트는 Networking 서비스(neutron)가 제공된 네트워크에서 할당하는 VLAN을 사용하여 트렁크 모드로 구성됩니다.

베어 메탈 게스트에 대한 트렁크 포트를 구성하려면 다음 단계를 완료합니다.

절차

  1. 포트와 트렁크를 생성하고 포트를 상위 포트로 트렁크에 할당합니다.

    $ port create --network primary-tenant-net primary-port
    $ network trunk create --parent-port primary-port my-trunk
  2. 보조 네트워크의 포트를 만들고 새 포트를 트렁크에 하위 포트로 추가합니다.

    $ port create --network secondary-tenant-net secondary-port
    $ network trunk set --subport port=secondary-port,segmentation-type=vlan,segmentation-id=1234 my-trunk

8.6. networking-ansible ML2 함수 테스트

베어 메탈 노드에 대한 networking-ansible 구성이 완료된 후 베어 메탈 워크로드를 생성하여 구성이 올바른지 확인합니다.

사전 요구 사항

  • OpenStack Baremetal(ironic) 서비스가 있는 Overcloud.
  • 활성화된 networking-ansible ML2 드라이버.
  • ML2HostConfigs 매개 변수에는 스위치 액세스 세부 정보가 포함되어 있습니다.
  • 등록된 베어 메탈 노드.
  • 스위치의 노드 연결에 사용되는 각 베어 메탈 포트 구성. 이 포트는 액세스 포트 또는 트렁크 포트일 수 있습니다.
  • 초기 프로비저닝을 위해 OpenStack Networking(neutron)에 정의된 VLAN 기반 프로비저닝 네트워크입니다.
  • 내부 통신을 위해 OpenStack Networking(neutron)에 정의된 VLAN 기반 테넌트 네트워크입니다.
  • Overcloud에서 사용 가능한 디스크 이미지 및 키 쌍.

절차

  1. 베어 메탈 시스템을 생성합니다.

    • 액세스 포트를 사용하는 베어 메탈 시스템을 생성하려면 다음 명령을 실행합니다.

      openstack server create --flavor baremetal --image overcloud-full --key default --network tenant-net test1
    • 트렁크 포트를 사용하는 베어 메탈 시스템을 생성하려면 다음 명령을 실행합니다.

      openstack server create --flavor baremetal --image overcloud-full --port {primary-port-uuid} --key default test1

오버클라우드는 처음에 provisioning 네트워크에 베어 메탈 시스템을 생성합니다. 생성이 완료되면 networking-ansible 드라이버가 스위치의 포트 구성을 변경하여 베어 메탈 시스템에서 테넌트 네트워크를 사용하도록 합니다.

9장. 베어 메탈 프로비저닝 서비스 문제 해결

베어 메탈 프로비저닝 서비스(ironic)가 포함된 환경의 문제를 진단합니다.

9.1. PXE 부팅 오류

다음 문제 해결 절차에 따라 PXE 부팅에 발생할 수 있는 문제를 평가하고 해결할 수 있습니다.

권한이 거부된 오류

베어 메탈 노드의 콘솔에서 Permission Denied 오류를 반환하는 경우 /httpboot 및 / tftpboot 디렉터리에 적절한 SELinux 컨텍스트를 적용했는지 확인하십시오.

# semanage fcontext -a -t httpd_sys_content_t "/httpboot(/.*)?"
# restorecon -r -v /httpboot
# semanage fcontext -a -t tftpdir_t "/tftpboot(/.*)?"
# restorecon -r -v /tftpboot

부팅 프로세스가 /pxelinux.cfg/XX-XX-XX-XX-XX-XX에서 중단됩니다.

노드의 콘솔에서 IP 주소를 수신하는 것처럼 보이지만 프로세스가 중지되면 ironic.conf 파일에서 잘못된 PXE 부팅 템플릿을 사용할 수 있습니다.

PXE Process Freezes During Boot

$ grep ^pxe_config_template ironic.conf
pxe_config_template=$pybasedir/drivers/modules/ipxe_config.template

기본 템플릿은 pxe_config.template 이므로 i를 생략하고 실수로 i pxe_config.template 을 대신 입력하기 쉽습니다.

9.2. 베어 메탈 노드가 부팅된 후 로그인 오류

구성 중에 설정한 루트 암호를 사용할 때 노드에 로그인하지 못하면 배포된 이미지로 부팅되지 않았음을 나타냅니다. deploy-kernel/deploy-ramdisk 이미지에 로그인하고 시스템에서 올바른 이미지를 아직 로드하지 않은 것일 수 있습니다.

이 문제를 해결하려면 Compute 또는 Bare Metal Provisioning 서비스 노드의 /httpboot/pxelinux.cfg/MAC_ADDRESS 에 있는 PXE 부팅 구성 파일을 확인하고 이 파일에 나열된 모든 IP 주소가 베어 메탈 네트워크의 IP 주소에 해당하는지 확인합니다.

참고

베어 메탈 프로비저닝 서비스 노드에서 사용하는 유일한 네트워크는 베어 메탈 네트워크입니다. 엔드포인트 중 하나가 네트워크에 없는 경우 엔드포인트는 부팅 프로세스의 일부로 베어 메탈 프로비저닝 서비스 노드에 연결할 수 없습니다.

예를 들어 파일의 kernel 행은 다음과 같습니다.

kernel http://192.168.200.2:8088/5a6cdbe3-2c90-4a90-b3c6-85b449b30512/deploy_kernel selinux=0 disk=cciss/c0d0,sda,hda,vda iscsi_target_iqn=iqn.2008-10.org.openstack:5a6cdbe3-2c90-4a90-b3c6-85b449b30512 deployment_id=5a6cdbe3-2c90-4a90-b3c6-85b449b30512 deployment_key=VWDYDVVEFCQJNOSTO9R67HKUXUGP77CK ironic_api_url=http://192.168.200.2:6385 troubleshoot=0 text nofb nomodeset vga=normal boot_option=netboot ip=${ip}:${next-server}:${gateway}:${netmask} BOOTIF=${mac}  ipa-api-url=http://192.168.200.2:6385 ipa-driver-name=ipmi boot_mode=bios initrd=deploy_ramdisk coreos.configdrive=0 || goto deploy
위의 예제 커널 행의 값해당 정보

http://192.168.200.2:8088

/etc/ironic/ironic.conf 파일의 매개 변수 http_url. 이 IP 주소는 베어 메탈 네트워크에 있어야 합니다.

5a6cdbe3-2c90-4a90-b3c6-85b449b30512

ironic node-list의 baremetal 노드 의 UUID입니다.

deploy_kernel

/httpboot/<NODE_UUID>/deploy_kernel 로 복사되는 이미지 서비스에 배포 커널 이미지입니다.

http://192.168.200.2:6385

/etc/ironic/ironic.conf 파일의 매개 변수 api_url. 이 IP 주소는 베어 메탈 네트워크에 있어야 합니다.

IPMI

이 노드의 베어 메탈 프로비저닝 서비스에서 사용하는 IPMI 드라이버입니다.

deploy_ramdisk

/httpboot/<NODE_UUID>/deploy_ramdisk 로 복사되는 이미지 서비스에 배포 램디스크 이미지입니다.

/httpboot/pxelinux.cfg/MAC_ADDRESS와 ironic. conf 파일 사이에 값이 일치하지 않는 경우:

  1. ironic.conf 파일의 값 업데이트
  2. 베어 메탈 프로비저닝 서비스 다시 시작
  3. 베어 메탈 인스턴스 다시 배포

9.3. 배포된 노드의 부팅 간 오류

특정 하드웨어에서는 배포의 일부로 연속 부팅 작업 중에 노드가 디스크에서 부팅되지 않는 배포된 노드에 문제가 발생할 수 있습니다. 이는 BMC가 노드에 요청하는 영구 부팅 설정을 수행하지 않기 때문에 일반적으로 발생합니다. 대신 노드는 PXE 대상에서 부팅됩니다.

이 경우 노드의 BIOS에서 부팅 순서를 업데이트해야 합니다. 노드가 기본적으로 디스크에서 부팅되지만 필요에 따라 인트로스펙션 또는 배포 중에 네트워크에서 부팅할 수 있도록 HDD를 첫 번째 부팅 장치로 설정한 다음 이후 옵션으로 PXE를 설정합니다.

참고

이 오류는 대부분 LegacyBIOS 펌웨어를 사용하는 노드에 적용됩니다.

9.4. 베어 메탈 프로비저닝 서비스에 올바른 호스트 이름이 수신되지 않습니다.

베어 메탈 프로비저닝 서비스에 올바른 호스트 이름이 수신되지 않으면 cloud-init 가 실패합니다. 이 문제를 해결하려면 Bare Metal 서브넷을 OpenStack Networking 서비스의 라우터에 연결합니다. 이 구성은 요청을 meta-data 에이전트에 올바르게 라우팅합니다.

9.5. 베어 메탈 프로비저닝 서비스 명령을 실행할 때 잘못된 OpenStack ID 서비스 인증 정보

ID 서비스에 인증할 수 없는 경우 ironic.conf 파일의 identity_uri 매개변수를 확인하고 keystone AdminURL에서 /v2.0 을 제거해야 합니다. 예를 들어 identity_uri 로 설정합니다.

9.6. 하드웨어 등록

잘못된 노드 등록 세부 정보로 인해 등록된 하드웨어에 문제가 발생할 수 있습니다. 속성 이름과 값을 올바르게 입력해야 합니다. 속성 이름을 잘못 입력하는 경우 시스템은 노드 세부 정보에 속성을 추가하지만 이를 무시합니다.

openstack baremetal node set 명령을 사용하여 노드 세부 정보를 업데이트합니다. 예를 들어 노드가 등록된 메모리 양을 2GB로 업데이트합니다.

$ openstack baremetal node set --property memory_mb=2048 NODE_UUID

9.7. iDRAC 문제 해결

Redfish 관리 인터페이스가 부팅 장치 설정에 실패했습니다

특정 iDRAC 펌웨어 버전과 함께 idrac-redfish 관리 인터페이스를 사용하고 UEFI 부팅과 함께 베어 메탈 서버에서 부팅 장치를 설정하려고 하면 iDRAC는 다음 오류를 반환합니다.

Unable to Process the request because the value entered for the
parameter Continuous is not supported by the implementation.

이 문제가 발생하면 노드의 driver-infoforce_persistent_boot_device 매개변수를 Never 로 설정합니다.

openstack baremetal node set --driver-info force_persistent_boot_device=Never ${node_uuid}
전원 끄기 시 시간 초과

일부 서버는 전원을 끌 때 너무 느리며 시간 초과할 수 있습니다. 기본 재시도 횟수는 6 으로, 30초의 시간 초과가 발생합니다. 시간 초과 기간을 90초로 늘리려면 언더클라우드 hieradata에서 ironic::agent::rpc_response_timeout 값을 18 으로 설정하고 openstack undercloud install 명령을 다시 실행합니다.

ironic::agent::rpc_response_timeout: 18
벤더 통과 타임아웃

iDRAC를 사용하여 벤더 패스스루 명령을 실행할 수 없는 경우 이러한 명령은 너무 오래 걸려서 시간이 초과됩니다.

openstack baremetal node passthru call --http-method GET \
aed58dca-1b25-409a-a32f-3a817d59e1e0 list_unfinished_jobs
Timed out waiting for a reply to message ID 547ce7995342418c99ef1ea4a0054572 (HTTP 500)

메시징의 시간 초과 기간을 늘리려면 언더클라우드 hieradata에서 ironic::default::rpc_response_timeout 매개변수 값을 늘리고 openstack undercloud install 명령을 다시 실행합니다.

ironic::default::rpc_response_timeout: 600

9.8. 서버 콘솔 구성

Overcloud 노드의 콘솔 출력이 항상 서버 콘솔로 전송되지는 않습니다. 서버 콘솔에서 이 출력을 보려면 하드웨어에 올바른 콘솔을 사용하도록 오버클라우드를 구성해야 합니다. 다음 방법 중 하나를 사용하여 이 구성을 수행합니다.

  • 각 오버클라우드 역할에 대해 KernelArgs heat 매개변수를 수정합니다.
  • director에서 Overcloud 노드를 프로비저닝하는 데 사용하는 overcloud-full.qcow2 이미지를 사용자 지정합니다.

사전 요구 사항

  • 성공적인 언더클라우드 설치 자세한 내용은 Director 설치 및 사용 가이드를 참조하십시오.
  • 배포할 준비가 된 오버클라우드 노드

배포 중 heat를 사용하여 KernelArgs 수정

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

    $ source stackrc
  3. 다음 내용으로 환경 파일 overcloud-console.yaml 을 생성합니다.

    parameter_defaults:
      <role>Parameters:
        KernelArgs: "console=<console-name>"

    <role> 을 설정하려는 오버클라우드 역할의 이름으로 바꾸고 <console-name> 을 사용하려는 콘솔의 ID로 바꿉니다. 예를 들어 다음 스니펫을 사용하여 tty0 을 사용하도록 기본 역할의 모든 오버클라우드 노드를 구성합니다.

    parameter_defaults:
      ControllerParameters:
        KernelArgs: "console=tty0"
      ComputeParameters:
        KernelArgs: "console=tty0"
      BlockStorageParameters:
        KernelArgs: "console=tty0"
      ObjectStorageParameters:
        KernelArgs: "console=tty0"
      CephStorageParameters:
        KernelArgs: "console=tty0"
  4. 배포 명령에 -e 옵션을 사용하여 overcloud-console-tty0.yaml 파일을 포함합니다.

overcloud-full.qcow2 이미지 수정

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

    $ source stackrc
  3. overcloud-full.qcow2 이미지의 커널 인수를 수정하여 하드웨어에 대한 올바른 콘솔을 설정합니다. 예를 들어 콘솔을 tty0 으로 설정합니다.

    $ virt-customize --selinux-relabel -a overcloud-full.qcow2 --run-command 'grubby --update-kernel=ALL --args="console=tty0"'
  4. 이미지를 director로 가져옵니다.

    $ openstack overcloud image upload --image-path overcloud-full.qcow2
  5. Overcloud를 배포합니다.

검증

  1. 언더클라우드에서 오버클라우드 노드에 로그인합니다.

    $ ssh heat-admin@<IP-address>

    <IP-address> 를 오버클라우드 노드의 IP 주소로 바꿉니다.

  2. /proc/cmdline 파일의 내용을 검사하고 console= 매개변수가 사용하려는 콘솔의 값으로 설정되어 있는지 확인합니다.

    [heat-admin@controller-0 ~]$ cat /proc/cmdline
    BOOT_IMAGE=(hd0,msdos2)/boot/vmlinuz-4.18.0-193.29.1.el8_2.x86_64 root=UUID=0ec3dea5-f293-4729-b676-5d38a611ce81 ro console=tty0 console=ttyS0,115200n81 no_timer_check crashkernel=auto rhgb quiet

10장. 베어 메탈 드라이버

베어 메탈 프로비저닝 서비스에서 활성화되는 드라이버 중 하나를 사용하도록 베어 메탈 노드를 구성할 수 있습니다. 각 드라이버에는 프로비저닝 방법과 전원 관리 유형이 포함됩니다. 일부 드라이버에는 추가 구성이 필요합니다. 이 섹션에 설명된 각 드라이버는 프로비저닝에 PXE를 사용합니다. 드라이버는 전원 관리 유형으로 나열됩니다.

ironic.yaml 파일에서 IronicEnabledHardwareTypes 매개변수를 구성하여 드라이버를 추가할 수 있습니다. 기본적으로 ipmiredfish 는 활성화되어 있습니다.

지원되는 플러그인 및 드라이버의 전체 목록은 Component, Plug-In 및 Driver Support in Red Hat OpenStack Platform 을 참조하십시오.

10.1. IPMI(Intelligent Platform Management Interface)

IPMI는 전원 관리 및 서버 모니터링을 포함하여 대역 외 원격 관리 기능을 제공하는 인터페이스입니다. 이 전원 관리 유형을 사용하려면 모든 베어 메탈 프로비저닝 서비스 노드에 공유 베어 메탈 네트워크에 연결된 IPMI가 필요합니다. ipmi 드라이버를 활성화하고 노드의 driver_info 에 다음 정보를 설정합니다.

  • ipmi_address - IPMI NIC의 IP 주소입니다.
  • ipmi_username - IPMI 사용자 이름입니다.
  • ipmi_password - IPMI 암호입니다.
참고

Red Hat OpenStack Platform 16.1에서 ipmitool 2.0 사용. 일부 하드웨어에서는 다음 오류로 인해 인트로스펙션 또는 일반 전원 제어 작업이 실패할 수 있습니다.

Error in open session response message : no matching cipher suite
Error: Unable to establish IPMI v2 / RMCP+ session

이 경우 인트로스펙션을 실행하기 전에 IPMI 암호화 제품군을 버전 3으로 설정해야 합니다.

$ openstack baremetal node set <node-UUID> --driver-info ipmi_cipher_suite=3

10.2. Redfish

DMTF(Distributed Management Task Force)에서 개발한 IT 인프라를 위한 표준 RESTful API

  • redfish_username - Redfish 사용자 이름.
  • redfish_password - Redfish 암호.
  • redfish_address - Redfish 컨트롤러의 IP 주소입니다.
  • redfish_system_id - 시스템 리소스의 정식 경로입니다. 이 경로는 루트 서비스, 버전 및 시스템의 경로/유일 ID를 포함해야 합니다. 예: /redfish/v1/Systems/CX34R87
  • redfish_verify_ca - 부울 값, CA_BUNDLE 파일의 경로 또는 신뢰할 수 있는 CA의 인증서가 있는 디렉터리입니다. 이 값을 True 로 설정하면 드라이버에서 호스트 인증서를 확인합니다. 이 값을 False 로 설정하면 드라이버에서 SSL 인증서 확인을 무시합니다. 이 값을 경로로 설정하면 드라이버는 지정된 인증서 또는 디렉터리의 인증서 중 하나를 사용합니다. 기본값은 True 입니다.

10.3. DRAC(Dell Remote Access Controller)

DRAC는 전원 관리 및 서버 모니터링을 포함하여 대역 외 원격 관리 기능을 제공하는 인터페이스입니다. 이 전원 관리 유형을 사용하려면 모든 베어 메탈 프로비저닝 서비스 노드에 공유 베어 메탈 네트워크에 연결된 DRAC가 필요합니다. idrac 드라이버를 활성화하고 노드의 driver_info 에 다음 정보를 설정합니다.

  • drac_address - DRAC NIC의 IP 주소입니다.
  • drac_username - DRAC 사용자 이름입니다.
  • drac_password - DRAC 암호입니다.

10.4. iRMC(Remote Management Controller)

Fujitsu의 iRMC는 전원 관리 및 서버 모니터링을 포함하여 대역 외 원격 관리 기능을 제공하는 인터페이스입니다. 베어 메탈 프로비저닝 서비스 노드에서 이 전원 관리 유형을 사용하려면 노드에 공유 베어 메탈 네트워크에 연결된 iRMC 인터페이스가 필요합니다. irmc 드라이버를 활성화하고 노드의 driver_info 에 다음 정보를 설정합니다.

  • irmc_address - iRMC 인터페이스 NIC의 IP 주소입니다.
  • irmc_username - iRMC 사용자 이름입니다.
  • irmc_password - iRMC 암호입니다.

IPMI를 사용하여 부팅 모드 또는 SCCI를 설정하여 센서 데이터를 가져오려면 다음 추가 단계를 완료해야 합니다.

  1. ironic.conf 파일에서 센서 메서드를 활성화합니다.

    $ openstack-config --set /etc/ironic/ironic.conf \
       irmc sensor_method METHOD

    METHODscci or ipmitool 로 바꿉니다.

  2. SCCI를 활성화한 경우 python-scciclient 패키지를 설치합니다.

    # dnf install python-scciclient
  3. 베어 메탈 컨덕터 서비스를 다시 시작합니다.

    # systemctl restart openstack-ironic-conductor.service
참고

iRMC 드라이버를 사용하려면 iRMC S4 이상이 필요합니다.

10.5. iLO(Integrated Lights-Out)

Hewlett-Packard의 iLO는 전원 관리 및 서버 모니터링을 포함하여 대역 외 원격 관리 기능을 제공하는 인터페이스입니다. 이 전원 관리 유형을 사용하려면 모든 베어 메탈 노드에 공유 베어 메탈 네트워크에 연결된 iLO 인터페이스가 필요합니다. ilo 드라이버를 활성화하고 노드의 driver_info 에 다음 정보를 설정합니다.

  • ilo_address - iLO 인터페이스 NIC의 IP 주소입니다.
  • ilo_username - iLO 사용자 이름입니다.
  • ilo_password - iLO 암호.

python-proliantutils 패키지를 설치하고 베어 메탈 컨덕터 서비스를 다시 시작해야 합니다.

# dnf install python-proliantutils
# systemctl restart openstack-ironic-conductor.service

10.6. 차세대 전원 관리 드라이버로 변환

Red Hat OpenStack Platform은 이제 기존 드라이버를 대체하는 하드웨어 유형 이라고도 하는 차세대 드라이버를 사용합니다.

다음 표에서는 이전 드라이버와 차세대 하드웨어 유형과 유사한 비교를 보여줍니다.

이전 드라이버새 하드웨어 유형

pxe_ipmitool

ipmi

pxe_drac

idrac

pxe_ilo

ilo

pxe_irmc

irmc

fake_pxe

fake-hardware

RHOSP(Red Hat OpenStack Platform) 15에서는 이러한 오래된 드라이버가 제거되어 더 이상 액세스할 수 없습니다. RHOSP 15로 업그레이드하기 전에 새 하드웨어 유형으로 변경해야 합니다.

절차

  1. 활성화된 하드웨어 유형의 현재 목록을 확인합니다.

    $ source ~/overcloud
    $ openstack baremetal driver list --type dynamic
  2. 활성화되지 않은 하드웨어 유형 드라이버를 사용하는 경우 환경 파일에서 IronicEnabledHardwareTypes 매개변수를 사용하여 드라이버를 활성화합니다.

    parameter_defaults:
      IronicEnabledHardwareTypes: ipmi,redfish,idrac
  3. 파일을 저장하고 오버클라우드 배포 명령을 실행합니다.

    $ openstack overcloud deploy -e [ENVIRONMENT_FILE] -r [ROLES_DATA] -n [NETWORK_DATA]

    오버클라우드와 관련된 모든 환경 및 데이터 파일을 포함해야 합니다.

  4. 다음 명령을 실행합니다. 전원 관리 유형을 위해 OLD DRIVER 및 NEWDRIVER 변수를 바꿉니다.

    $ source ~/overcloud
    $ OLDDRIVER="pxe_ipmitool"
    $ NEWDRIVER="ipmi"
    $ for NODE in $(openstack baremetal node list --driver $OLDDRIVER -c UUID -f value) ; do openstack baremetal node set $NODE --driver $NEWDRIVER; done