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 は、個別のサービスを特定の事前定義済みのネットワーク種別に設定することができます。このネットワークトラフィック種別には以下が含まれます。
| 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 に焦点を当てています。
| 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 インスタンスの通常の接続先となるポート 6640 と 6653 でリッスンするように設定されます。
OpenStack では通常、各サービスに独自の仮想 IP アドレス (VIP) があり、OpenDaylight も同様に動作します。HAProxy は 8081 ポートをパブリックに公開し、OpenStack にすでに存在するプレーンの仮想 IP を制御するように設定されます。仮想 IP とポートは、ML2 プラグインに提供され、neutron はそのポートを介してすべての通信を行います。OVS インスタンスは、OpenDaylight がサウスバウンド用に実行しているノードの物理 IP に直接接続します。
| サービス | プロトコル | デフォルトのポート | ネットワーク |
|---|---|---|---|
| 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 ガイドを参照してください。