Menu Close

Red Hat Training

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

第2章 アーキテクチャー

director には、OpenStack 環境自体の設定、デプロイ、管理にネイティブの OpenStack API を使用することを推奨します。つまり、director を使用した統合には、それらのネイティブ OpenStack API および補助コンポーネントとの統合が必要となることになります。このような API を使用する主な利点は、十分に文書化されていること、アップストリームで統合テストが幅広く行われていること、成熟していること、また OpenStack 基本知識を持つユーザーであればより簡単に director の機能の仕組みを理解できることなどです。また、OpenStack API を使用すると、director が自動的に OpenStack のコア機能拡張、セキュリティー修正プログラム、バグの修正を自動的に継承することになります。

Red Hat OpenStack Platform director は、完全な OpenStack 環境のインストールおよび管理を行うためのツールセットです。director は、主に OpenStack プロジェクト TripleO (「OpenStack-On-OpenStack」の略語) をベースとしてます。このプロジェクトは、OpenStack のコンポーネントを活用して、完全に機能する OpenStack 環境をインストールします。これには、OpenStack ノードとして使用するベアメタルシステムをプロビジョニング、制御する新しい OpenStack のコンポーネントが含まれます。

Red Hat OpenStack Platform director は、アンダークラウドとオーバークラウドという 2 つの主要な概念を使用します。この director 自体は、アンダークラウドとして知られている単一システムの OpenStack 環境を形成する OpenStack コンポーネントのサブセットで構成されています。アンダークラウドは、ワークロードを実行できるように実稼動レベルのクラウドを構築できる管理システムとして機能します。オーバークラウドとアンダークラウドに関する情報は、『director のインストールと使用方法』 ガイドを参照してください。

Diagram 001 Topology

director には、オーバークラウド構成を構築するためのツール、ユーティリティー、テンプレートのサンプルが同梱されています。director は、設定データ、パラメーター、ネットワークトポロジーの情報を取得し、Ironic、Heat、Puppet などのコンポーネントとともにその情報を使用して、オーバークラウドのインストール環境をオーケストレーションします。

パートナーにはさまざまな異なる要件があります。director のアーキテクチャーを理解すると、統合の際にどのコンポーネントが重要となるかを理解するのに役立ちます。

2.1. コアコンポーネント

本セクションでは、Red Hat OpenStack Platform director のコアコンポーネントをいくつか考察して、それらのコンポーネントがオーバークラウドの作成にどのように貢献するのかを説明します。

2.1.1. Ironic

Ironic は、セルフサービスのプロビジョニングを使用してエンドユーザーに専用のベアメタルを提供します。director は、Ironic を使用してオーバークラウドのベアメタルハードウェアのライフサイクルを管理します。Ironic には、ベアメタルノードを定義するネイティブの API があります。director で OpenStack 環境をプロビジョニングする管理者は、特定のドライバーを使用して、Ironic にノードを登録する必要があります。ハードウェアの多くで Intelligent Platform Management Interface (IPMI) 電源管理機能がサポートされているため、IPMI が主要なサポートドライバーとなっていますが、Ironic には HP iLO、Cisco UCS または Dell DRAC などのベンダー固有のドライバーも含まれています。Ironic は、ノードの電源管理を制御し、イントロスペクションメカニズムを使用して、ハードウェアの情報や ファクト を収集します。director は、イントロスペクションプロセスから取得した情報を使用して、コントローラーノード、コンピュートノード、ストレージノードなど、さまざまな OpenStack 環境のロールとノードを照合します。たとえば、ディスクが 10 個あるノードが検出された場合は、ストレージノードとしてプロビジョニングされる可能性が高いです。

OpenStack Ironic Deployment 392410 0216 JCS

director でのハードウェアサポートを希望するパートナーは、Ironic のドライバーに対応している必要があります。

2.1.2. Heat

Heat は、アプリケーションスタックのオーケストレーションエンジンとして機能します。これにより、組織では、クラウドにデプロイする前に特定のアプリケーションの要素を定義することができます。このプロセスでは、複数のインフラストラクチャーリソース (例: インスタンス、ネットワーク、ストレージボリューム、Elastic IP アドレスなど) や設定用のパラメーターセットなどが含まれるスタックテンプレートを作成します。Heat は、指定の依存関係チェーンをもとにこれらのリソースを作成して、リソースの可用性を監視し、必要に応じてスケーリングします。これらのテンプレートにより、アプリケーションスタックは移植可能となり、繰り返し実行して想定通りの結果を得られるようになります。

RHEL OSP arch 347192 1015 JCS 03 Interface Orchestra

director は、ネイティブの OpenStack Heat API を使用して、オーバークラウドのデプロイに関連するリソースのプロビジョニングおよび管理を行います。これには、1 ノードロールあたりのプロビジョニングするノードの数、各ノードに設定するソフトウェアコンポーネント、それらのコンポーネントとノードの種別を director が設定する順序の定義などの詳細情報が含まれます。また director は、デプロイメントのトラブルシューティングやデプロイメント後の変更を容易に行うためにも Heat を使用します。

以下の例は、コントローラーノードのパラメーターを定義する Heat テンプレートのスニペットです。

NeutronExternalNetworkBridge:
    description: Name of bridge used for external network traffic.
    type: string
    default: 'br-ex'
NeutronBridgeMappings:
    description: >
      The OVS logical->physical bridge mappings to use. See the Neutron
      documentation for details. Defaults to mapping br-ex - the external
      bridge on hosts - to a physical name 'datacentre' which can be used
      to create provider networks (and we use this for the default floating
      network) - if changing this either use different post-install network
      scripts or be sure to keep 'datacentre' as a mapping network name.
    type: string
    default: "datacentre:br-ex"

Heat は、director に含まれるテンプレートで Ironic を呼び出してノードの電源を入れるなど、オーバークラウドの作成を簡素化します。標準の Heat ツールを使用して作成中のオーバークラウドのリソース (およびステータス) を表示することができます。たとえば、Heat ツールを使用して、ネスト化されたアプリケーションスタックとしてオーバークラウドを表示することができます。

Heat には、実稼動の OpenStack クラウドを宣言および作成するための幅広く強力な構文がありますが、事前にパートナーのソリューションとの統合に関する知識とスキルが必要です。パートナーのテクノロジーを統合するユースケースにはすべて、Heat のテンプレートが必要です。

2.1.3. Puppet

Puppet は、設定管理および実行ツールで、このツールはマシンの最終的な状態を記述して、その状態を保持するメカニズムとして使用します。この最終的な状態は、Puppet マニフェストで定義します。Puppet では 2 つのモードをサポートします。

  • マニフェスト形式の手順がローカルで実行されるスタンドアロンモード
  • Puppet マスターと呼ばれる中央サーバーからマニフェストを取得するサーバーモード

管理者は、ノードに新しいマニフェストをアップロードしてローカルで実行するか、クライアント/サーバーモードで Puppet マスターで変更するかの 2 つの方法で変更を加えます。

Puppet は director のさまざまな場所で使用されています。

  • アンダークラウドホストで Puppet をローカルで使用して、undercloud.conf に記述された設定に従ってパッケージのインストールや設定を行います。
  • ベースのオーバークラウドイメージに openstack-puppet-modules パッケージを注入します。これらの Puppet モジュールは、デプロイメント後の設定に使用できます。デフォルトでは、すべての OpenStack サービスが含まれたイメージを作成して、各ノードに使用します。
  • Heat 経由で追加の Puppet マニフェストとパラメーターをノードに渡して、オーバークラウドのデプロイメントの後にその設定を適用します。これには、ノードの種別に依存するサービスの有効化や起動、OpenStack の設定の適用などが含まれます。
  • ノードに Puppet hieradata を渡します。Puppet モジュールやマニフェストには、マニフェストの一貫性を確保するためのサイトやノード固有のパラメーターはありません。hieradata はパラメーター値の形式で機能し、Puppet モジュールをプッシュして、他のエリアで参照することができます。たとえば、マニフェスト内の MySQL パスワードを参照するには、この情報を hieradata として保存して、マニフェスト内でこの hieradata を参照します。

    hieradata を表示します。

    [root@localhost ~]# grep mysql_root_password hieradata.yaml # View the data in the hieradata file
    openstack::controller::mysql_root_password: ‘redhat123'

    Puppet マニフェストで hieradata を参照します。

    [root@localhost ~]# grep mysql_root_password example.pp # Now referenced in the Puppet manifest
    mysql_root_password  => hiera(‘openstack::controller::mysql_root_password')

パートナーが統合するサービスで、パッケージをインストールしたり、サービスを有効化したりする必要がある場合には、その要件を満たすための Puppet モジュールを作成することを検討してください。たとえば、現在の OpenStack Puppet モジュールを取得する方法に関する情報は、「OpenStack Puppet モジュールの取得」を参照してください。

2.1.4. TripleO および TripleO Heat テンプレート

前述したように、director はアップストリームの TripleO プロジェクトをベースにしています。このプロジェクトは、以下の作業を行う OpenStack サービスセットを統合します。

  • オーバークラウドイメージの保存 (Glance)
  • オーバークラウドのオーケストレーション (Heat)
  • ベアメタルマシンのプロビジョニング (Ironic)

TripleO には、Red Hat がサポートするオーバークラウド環境を定義する Heat テンプレートコレクションが含まれます。director は、Heat を使用してこのテンプレートコレクションを読み込み、オーバークラウドスタックをオーケストレーションします。また、Heat はこのようなコアの Heat テンプレートに含まれる特定のリソースに対してソフトウェア設定を起動します。このソフトウェア設定は通常、Bash スクリプトか Puppet マニフェストのいずれかです。

通常のソフトウェア設定は、主に 2 つの Heat リソースに依存します。

  • 設定を定義するリソース (OS::Heat::SoftwareConfig)
  • ノードで設定を実装するリソース (OS::Heat::SoftwareDeployment)

たとえば、Heat テンプレートコレクションでは、コンピュートノードのデプロイメント後のテンプレート (puppet/compute-post.yaml) に以下のセクションが含まれます。

resources:

  ComputePuppetConfig:
    type: OS::Heat::SoftwareConfig
    properties:
      group: puppet
      options:
        enable_debug: {get_param: ConfigDebug}
      outputs:
      - name: result
      config:
        get_file: manifests/overcloud_compute.pp

  ComputePuppetDeployment:
    type: OS::Heat::StructuredDeployments
    properties:
      servers:  {get_param: servers}
      config: {get_resource: ComputePuppetConfig}
      input_values:
        update_identifier: {get_param: NodeConfigIdentifiers}

ComputePuppetConfig リソースは、コンピュートノードの設定が含まれる Puppet マニフェスト (puppet/manifests/overcloud_compute.pp) を読み込みます。ComputePuppetDeployment リソースは、サービス一覧 (servers: {get_param: servers}) に ComputePuppetConfig からの設定を適用します。これは Heat の親テンプレートではコンピュートノードとして定義されます。Puppet が正常にマニフェストをすべて適用したかどうかにより、ノードは ComputePuppetDeployment の成功/失敗の報告を返します。

このソフトウェアの設定データフローは、director を使用してサードパーティーのソリューションを統合する方法を理解するのに重要です。本ガイドは、このデータフローを使用して、中核となる設定の前後に、オーバークラウドでカスタムの設定を追加する方法を説明します。カスタム設定の実装に使用するソフトウェアの設定データフローの例は、以下を参照してください。