Menu Close

Red Hat Training

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

第2章 director のアーキテクチャー

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

director は、完全な RHOSP 環境のインストールと管理に使用するツールセットです。director は、主に OpenStack プロジェクト TripleO (「OpenStack-On-OpenStack」の略語) をベースとしてます。このプロジェクトは、RHOSP のコンポーネントを使用して、完全に機能する RHOSP 環境をインストールします。これには、OpenStack ノードとして使用するベアメタルシステムのプロビジョニングや制御を行う新たな OpenStack のコンポーネントが含まれます。director により、効率的で堅牢性の高い、完全な RHOSP 環境を簡単にインストールできます。

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

図2.1 アンダークラウドおよびオーバークラウドのアーキテクチャー

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

2.1. コアコンポーネントとオーバークラウド

オーバークラウドの作成に貢献する Red Hat OpenStack Platform director のコアコンポーネントを以下に示します。

  • OpenStack Bare Metal Provisioning サービス (ironic)
  • OpenStack Orchestration サービス (heat)
  • Puppet
  • TripleO および TripleO heat テンプレート
  • コンポーザブルサービス
  • コンテナー化されたサービスおよび Kolla
  • Ansible

2.1.1. OpenStack Bare Metal Provisioning サービス (ironic)

Bare Metal Provisioning サービスは、セルフサービスのプロビジョニングを使用してエンドユーザーに専用のベアメタルホストを提供します。director は、Bare Metal Provisioning を使用してオーバークラウドのベアメタルハードウェアのライフサイクルを管理します。Bare Metal Provisioning は、自己の API を使用してベアメタルノードを定義します。

director で OpenStack 環境をプロビジョニングするには、特定のドライバーを使用して、Bare Metal Provisioning にノードを登録する必要があります。ハードウェアの多くで Intelligent Platform Management Interface (IPMI) 電源管理機能がサポートされているため、IPMI が主要なサポートドライバーとなっています。しかし、Bare Metal Provisioning には HP iLO、Cisco UCS または Dell DRAC などのベンダー固有のドライバーも含まれています。

Bare Metal Provisioning は、ノードの電源管理を制御し、イントロスペクションメカニズムを使用して、ハードウェアの情報やファクトを収集します。director は、イントロスペクションプロセスからの情報を使用して、コントローラーノード、コンピュートノード、ストレージノードなど、さまざまな OpenStack 環境のロールとノードを照合します。たとえば、ディスクが 10 個あるノードが検出された場合は、通常ストレージノードとしてプロビジョニングされます。

図2.2 Bare Metal Provisioning サービスを使用したノードの電源管理の制御

ハードウェアで director サポートを必要とする場合は、Bare Metal Provisioning サービスでドライバーカバレッジを設定する必要があります。

2.1.2. heat

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

図2.3 heat サービスを使用した、クラウドにデプロイする前のアプリケーション要素の定義

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 を呼び出してノードの電源を入れるなど、オーバークラウドの作成を簡素化します。標準の tools ツールを使用して、進行中のオーバークラウドのリソースとステータスを表示できます。たとえば、heat ツールを使用して、入れ子状のアプリケーションスタックとしてオーバークラウドを表示することができます。実稼働向けの OpenStack クラウドを宣言および作成するには、heat テンプレートの構文を使用します。すべてのパートナーインテグレーションのユースケースには heat テンプレートが必要であるため、パートナーインテグレーションのための事前の理解と習熟が必要です。

2.1.3. Puppet

Puppet は、マシンの終了状態を記述および維持するために使用できる構成管理および適用ツールです。この最終的な状態は、Puppet マニフェストで定義します。Puppet では、以下の 2 つのモードがサポートされています。

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

次の 2 つの方法で変更を行うことができます。

  • 新しいマニフェストをノードにアップロードし、ローカルで実行する。
  • Puppet マスターのクライアント/サーバーモデルで変更を加える。

directorでは、次の領域でパペットが使用されます。

  • アンダークラウドホスト上で、undercloud .conf ファイルの設定に応じてローカルにパッケージをインストールおよび設定します。
  • openstack-puppet-modules パッケージをベースのオーバークラウドイメージに挿入することで、Puppet モジュールはデプロイメント後の設定の準備が整います。デフォルトでは、ノードごとにすべての OpenStack サービスが含まれたイメージを作成します。
  • 追加の Puppet マニフェストと heat パラメーターをノードに渡して、オーバークラウドのデプロイメントの後にその設定を適用します。これには、ノード種別に応じて設定を有効化および開始するサービスが含まれます。
  • ノードに 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 サービスセットを統合します。

  • Image サービス (glance) を使用したオーバークラウドイメージの保存
  • Orchestration サービス (heat) を使用してオーバークラウドのオーケストレーション
  • Bare Metal Provisioning (ironic) および Compute (nova) サービスを使用したベアメタルマシンのプロビジョニング

TripleO には、Red Hat がサポートするオーバークラウド環境を定義する heat テンプレートコレクションが含まれます。director は、heat を使用してこのテンプレートコレクションを読み込み、オーバークラウドスタックをオーケストレーションします。

2.1.5. コンポーザブルサービス

Red Hat OpenStack Platform の各機能側面は、コンポーザブルサービスに細分化されます。つまり、異なるサービスの組み合わせを使用するさまざまなロールを定義できるということです。たとえば、ネットワークエージェントをデフォルトのコントローラーノードからスタンドアロンのネットワーカーノードに移すことができます。

コンポーザブルサービスのアーキテクチャーに関する詳しい情報は、「6章コンポーザブルサービス」を参照してください。

2.1.6. コンテナー化されたサービスおよび Kolla

Red Hat OpenStack Platform (RHOSP) の各主要サービスは、コンテナー内で実行されます。このことにより、それぞれのサービスが、ホストから独立した専用の分離名前空間内に維持されます。これには次の効果があります。

  • デプロイ中、RHOSP は Red Hat カスタマーポータルからコンテナーイメージをプルして実行する。
  • podman コマンドは、サービスの起動や停止などの管理機能を操作します。
  • コンテナーをアップグレードするには、新しいコンテナーイメージをプルし、既存のコンテナーを新しいバージョンのコンテナーに置き換える必要がある。

Red Hat OpenStack Platform は、K olla ツールセットによりビルド/管理されるコンテナーセットを使用します。

2.1.7. Ansible

Red Hat OpenStack Platform では、Ansible を使用してコンポーザブルサービスのアップグレードに関する特定の機能がアクティブ化されます。この機能には、サービスの起動/停止やデータベースアップグレードの実施が含まれます。これらのアップグレードタスクは、コンポーザブルサービスのテンプレートで定義されます。