1.3. Red Hat OpenStack Platform director およびその設計について


Red Hat OpenStack Platform director は、完全な OpenStack 環境のインストールおよび管理を行うためのツールセットです。これは、主に OpenStack の TripleO (OpenStack-On-OpenStack) プロジェクトをベースとしています。

このプロジェクトは OpenStack コンポーネントを使用して、完全に機能する OpenStack 環境をインストールします。また、OpenStack ノードとして稼働するベアメタルシステムのプロビジョニングと制御を行う新たな OpenStack コンポーネントも含まれています。この方法で、リーンで、かつ堅牢性の高い、完全な Red Hat OpenStack Platform 環境をインストールすることができます。

Red Hat OpenStack Platform director では、アンダークラウドオーバークラウド の 2 つの主要な概念を採用しています。アンダークラウドがオーバークラウドのインストールおよび設定を行います。Red Hat OpenStack Platform director のアーキテクチャーに関する詳細は、director のインストールと使用方法 を参照してください。

図1.1 Red Hat OpenStack Platform director: アンダークラウドとオーバークラウド

1.3.1. Red Hat OpenStack Platform director と OpenDaylight

Red Hat OpenStack Platform director では、コンポーザブルサービスとカスタムロールの概念が導入されています。コンポーザブルサービスにより、必要な場合にロールごとに追加/有効化することができる孤立したリソースが形成されます。カスタムロールにより、ユーザーはデフォルトのコントローラーロールとコンピュートロールに依存しない、独自のロールを作成することができます。ユーザーは、デプロイする OpenStack サービスと、それらのサービスをホストするノードを選択できます。

OpenDaylight を director に統合するために、2 つのサービスが追加されました。

  • OpenDaylight SDN コントローラーを実行するための OpenDaylightApi サービス
  • 各ノードで OVS を設定して OpenDaylight と適切に通信するための OpenDaylightOvs サービス

デフォルトでは、OpenDaylightApi サービスは、コントローラーロール上で実行され、OpenDaylightOvs サービスはコントローラーロールとコンピュートロールで実行されます。OpenDaylight は、OpenDaylightApi サービスのインスタンス数をスケーリングすることによって、高可用性 (HA) を提供します。デフォルトでは、コントローラーを 3 つ以上にスケーリングすると、HA が自動的に有効化されます。OpenDaylight の HA アーキテクチャーに関する詳しい情報は、OpenDaylight での高可用性とクラスターリング を参照してください。

図1.2 OpenDaylight および OpenStack: ベースアーキテクチャー

1.3.2. Red Hat OpenStack Platform director でのネットワーク分離

Red Hat OpenStack Platform director は、個別のサービスを特定の事前定義済みのネットワーク種別に設定することができます。このネットワークトラフィック種別には以下が含まれます。

Expand

IPMI

ノードの電源管理ネットワーク。アンダークラウドをインストールする前に、このネットワークを設定する必要があります。

Provisioning (ctlplane)

director はこのネットワークトラフィック種別を使用して、DHCP および PXE ブートで新規ノードをデプロイし、オーバークラウドのベアメタルサーバー上で OpenStack Platform のインストールをオーケストレーションします。ネットワークは、アンダークラウドのインストール前に設定する必要があります。または、ironic でオペレーティングシステムのイメージを直接デプロイすることができます。その場合には、PXE ブートは必要ありません。

Internal API (internal_api)

Internal API ネットワークは、API 通信を使用した OpenStack サービス間の通信、RPC メッセージ、データベース通信やロードバランサーの背後の内部通信に使用されます。

Tenant (tenant)

neutron は VLAN (各テナントネットワークがネットワーク VLAN) またはオーバーレイトンネルを使用して、各テナントに独自のネットワークを提供します。ネットワークトラフィックは、テナントのネットワークごとに分離されます。トンネリングを使用する場合には、競合は発生することなく、複数のテナントネットワークで同じ IP アドレス範囲を使用することができます。

注記

Generic Routing Encapsulation (GRE) および Virtual eXtensible Local Area Network (VXLAN) は両方ともコードベースで利用可能ですが、OpenDaylight で推奨されるトンネリングプロトコルは VXLAN です。VXLAN の定義は RFC 7348 に記載されています。本ガイドではこれ以降、トンネリングが使用される場合にはいずれも VXLAN に焦点を当てています。

Expand

Storage (storage)

Block Storage、NFS、iSCSI など。パフォーマンスを最適化するには、完全に別のスイッチファブリックに分離するのが理想的でしょう。

Storage Management (storage_mgmt)

OpenStack Object Storage (swift) は、このネットワークを使用して、参加するレプリカノード間でデータオブジェクトを同期します。プロキシーサービスは、ユーザー要求と下層にあるストレージ層の間の仲介インターフェイスとして機能します。プロキシーは、受信要求を受け取り、必要なレプリカの位置を特定して要求データを取得します。Ceph バックエンドを使用するサービスは、Cephと直接対話せずにフロントエンドのサービスを使用するため、Storage Management Network 経由で接続を確立します。RBD ドライバーは例外で、このトラフィックは直接 Ceph に接続する点に注意してください。

External/Public API

この API は、グラフィカルシステム管理用の OpenStack Dashboard (Horizon)、OpenStack サービス用の Public API をホストして、インスタンスへの受信トラフィック向けに SNAT を実行します。外部ネットワークがプライベート IP アドレスを使用する場合には (RFC-1918 に準拠)、インターネットからのトラフィックに対して、さらに NAT を実行する必要があります。

Floating IP

テナントネットワーク内のインスタンスに割り当てられた Floating IP アドレスと Fixed IP アドレスとの間の 1 対 1 の IPv4 アドレスマッピングを使用して、受信トラフィックがインスタンスに到達できるようにします。外部と Floating IP ネットワークは、別々に維持管理するのではなく、組み合わせるのが一般的な設定です。

Management

SSH アクセス、DNS トラフィック、NTP トラフィックなどのシステム管理機能を提供します。このネットワークは、コントローラー以外のノード用のゲートウェイとしても機能します。

一般的な Red Hat OpenStack Platform のシステム環境では通常、ネットワーク種別の数は物理ネットワークのリンク数を超えます。全ネットワークを正しいホストに接続するには、オーバークラウドは 802.1q VLAN タグ付けを使用して、1 つのインターフェイスに複数のネットワークを提供します。ネットワークの多くは、サブネットが分離されていますが、インターネットアクセスまたはインフラストラクチャーにネットワーク接続ができるようにルーティングを提供する レイヤー 3 のゲートウェイが必要です。

OpenDaylight では、関連するネットワークには Internal API および Tenant サービスが含まれ、ServiceNetMap 内の各ネットワークにマッピングされます。デフォルトでは、ServiceNetMap は、OpenDaylightApi ネットワークを Internal API ネットワークにマッピングします。この設定は、neutron へのノースバウンドトラフィックと、OVS へのサウスバウンドトラフィックが Internal API ネットワークに分離されることを意味します。

OpenDaylight は分散ルーティングアーキテクチャーを使用するので、各コンピュートノードが Floating IP ネットワークに接続されている必要があります。デフォルトでは、Red Hat OpenStack Platform director は External ネットワークが OVS ブリッジ br-ex にマッピングされた neutron の物理ネットワーク datacentre で実行されることを想定します。そのため、コンピュートノードの NIC テンプレートでは、デフォルトの設定に br-ex を含める必要があります。

図1.3 OpenDaylight と OpenStack: ネットワーク分離の例

1.3.3. ネットワークとファイアウォールの設定

ファイアウォールが厳しく制約されている場合など、一部のデプロイメントでは、OpenStack と OpenDaylight サービスのトラフィックを有効にするためにファイアウォールを手動で設定する必要のある場合があります。

デフォルトでは、OpenDaylight のノースバウンドは 8080 ポートを使用します。同じく 8080 ポートを使用する swift サービスと競合しないようにするために、Red Hat OpenStack Platform director でインストールする場合には、OpenDaylight のポートは 8081 に設定されています。Red Hat OpenDaylight のソリューションにおけるサウスバンドは、OVS インスタンスの通常の接続先となるポート 66406653 でリッスンするように設定されます。

OpenStack では通常、各サービスに独自の仮想 IP アドレス (VIP) があり、OpenDaylight も同様に動作します。HAProxy8081 ポートをパブリックに公開し、OpenStack にすでに存在するプレーンの仮想 IP を制御するように設定されます。仮想 IP とポートは、ML2 プラグインに提供され、neutron はそのポートを介してすべての通信を行います。OVS インスタンスは、OpenDaylight がサウスバウンド用に実行しているノードの物理 IP に直接接続します。

Expand
サービスプロトコルデフォルトのポートネットワーク

OpenStack Neutron API

TCP

9696

Internal API

OpenStack Neutron API (SSL)

TCP

13696

Internal API

OpenDaylight ノースバウンド

TCP

8081

Internal API

OpenDaylight サウスバウンド: OVSDB

TCP

6640

Internal API

OpenDaylight サウスバウンド: OpenFlow

TCP

6653

Internal API

OpenDaylight 高可用性

TCP

2550

Internal API

VXLAN

UDP

4789

Tenant

表 1: ネットワークとファイアウォールの設定

注記

本項では、OpenDaylight の統合に関連したサービスとプロトコルを中心とする情報を記載していますが、すべては網羅していません。Red Hat OpenStack で実行するサービスに必要なネットワークポートの全一覧は、Firewall Rules for Red Hat OpenStack Platform ガイドを参照してください。

Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2026 Red Hat
トップに戻る