第3章 オーバークラウドのプランニング

以下の項で、Red Hat OpenStack Platform 環境のさまざまな要素をプランニングする際のガイドラインを説明します。これには、ノードロールの定義、ネットワークトポロジーのプランニング、ストレージなどが含まれます。

3.1. ノードのデプロイメントロールのプランニング

director はオーバークラウドの構築に、デフォルトで複数のノード種別を提供します。これらのノード種別は以下のとおりです。

コントローラー

環境を制御するための主要なサービスを提供します。これには、Dashboard (horizon)、認証 (keystone)、イメージストレージ (glance)、ネットワーク (neutron)、オーケストレーション (heat)、高可用性サービスが含まれます。高可用性の環境の場合は、Red Hat OpenStack Platform 環境にコントローラーノードが 3 台必要です。

注記

1 台のノードで構成される環境は、テスト目的に使用することができます。2 台のノードまたは 4 台以上のノードで構成される環境はサポートされません。

コンピュート
ハイパーバイザーとして機能し、環境内で仮想マシンを実行するのに必要な処理能力を提供する物理サーバー。基本的な Red Hat OpenStack Platform 環境には少なくとも 1 つのコンピュートノードが必要です。
Ceph Storage
Red Hat Ceph Storage を提供するホスト。Ceph Storage ホストはクラスターに追加され、クラスターをスケーリングします。このデプロイメントロールはオプションです。
Swift Storage
OpenStack の Swift サービスに外部オブジェクトストレージを提供するホスト。このデプロイメントロールはオプションです。

以下の表には、オーバークラウドの構成例と各シナリオで使用するノード種別の定義をまとめています。

表3.1 各種シナリオに使用するノードデプロイメントロール

 

コントローラー

コンピュート

Ceph Storage

Swift Storage

合計

小規模のオーバークラウド

3

1

-

-

4

中規模のオーバークラウド

3

3

-

-

6

追加のオブジェクトストレージがある中規模のオーバークラウド

3

3

-

3

9

Ceph Storage クラスターがある中規模のオーバークラウド

3

3

3

-

9

さらに、個別のサービスをカスタムのロールに分割するかどうかを検討します。コンポーザブルロールのアーキテクチャーに関する詳しい情報は、『オーバークラウドの高度なカスタマイズ』「コンポーザブルサービスとカスタムロール」を参照してください。

3.2. ネットワークのプランニング

ロールとサービスを適切にマッピングして相互に正しく通信できるように、環境のネットワークトポロジーおよびサブネットのプランニングを行うことが重要です。Red Hat OpenStack Platform では、自律的に動作してソフトウェアベースのネットワーク、静的/Floating IP アドレス、DHCP を管理する Neutron ネットワークサービスを使用します。director は、オーバークラウド環境の各コントローラーノードに、このサービスをデプロイします。

Red Hat OpenStack Platform は、さまざまなサービスをマッピングして、お使いの環境の各種サブネットに割り当てられたネットワークトラフィックの種別を分類します。このネットワークトラフィック種別には以下が含まれます。

表3.2 ネットワーク種別の割り当て

ネットワーク種別

説明

そのネットワーク種別を使用するノード

IPMI

ノードの電源管理に使用するネットワーク。このネットワークは、アンダークラウドのインストール前に事前定義されます。

全ノード

プロビジョニング

director は、このネットワークトラフィック種別を使用して、PXE ブートで新規ノードをデプロイし、オーバークラウドベアメタルサーバーに OpenStack Platform のインストールをオーケストレーションします。 このネットワークは、アンダークラウドのインストール前に事前定義されます。

全ノード

内部 API

内部 API ネットワークは、API 通信、RPC メッセージ、データベース通信経由で OpenStack のサービス間の通信を行う際に使用します。

コントローラー、コンピュート、Cinder Storage、Swift Storage

テナント

Neutron は、VLAN 分離 (各テナントネットワークがネットワーク VLAN) または VXLAN か GRE 経由のトンネリングを使用した独自のネットワークを各テナントに提供します。ネットワークトラフィックは、テナントのネットワークごとに分割されます。テナントネットワークにはそれぞれ IP サブネットが割り当てられています。また、ネットワーク名前空間が複数あると、複数のテナントネットワークが同じアドレスを使用できるので、競合は発生しません。

コントローラー、コンピュート

ストレージ

Block Storage、NFS、iSCSI など。理想的には、これはパフォーマンス上の理由から、完全に別のスイッチファブリックに分離した方がよいでしょう。

全ノード

ストレージ管理

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

コントローラー、Ceph Storage、Cinder Storage、Swift Storage

外部

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

コントローラーとアンダークラウド

Floating IP

受信トラフィックが Floating IP アドレスとテナントネットワーク内のインスタンスに実際に割り当てられた IP アドレスとの間の 1 対 1 の IP アドレスマッピングを使用してインスタンスに到達できるようにします。外部ネットワークからは分離した VLAN 上で Floating IP をホストする場合には、Floating IP VLAN をコントローラーノードにトランキングして、オーバークラウドの作成後に Neutron を介して VLAN を追加します。これにより、複数のブリッジに接続された複数の Floating IP ネットワークを作成する手段が提供されます。VLAN は、トランキングされますが、インターフェースとしては設定されません。その代わりに、Neutron は各 Floating IP ネットワークに選択したブリッジ上の VLAN セグメンテーション ID を使用して、OVS ポートを作成します。

コントローラー

管理

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

全ノード

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

注記

デプロイ時に neutron VLAN モード (トンネリングは無効) を使用する場合でも、プロジェクトネットワーク (GRE または VXLAN でトンネリング) をデプロイすることを推奨します。これには、デプロイ時にマイナーなカスタマイズを行う必要があり、将来ユーティリティーネットワークまたは仮想化ネットワークとしてトンネルネットワークを使用するためのオプションが利用可能な状態になります。VLAN を使用してテナントネットワークを作成することは変わりませんが、テナントの VLAN を消費せずに特別な用途のネットワーク用に VXLAN トンネルを作成することも可能です。また、テナント VLAN を使用するデプロイメントに VXLAN 機能を追加することは可能ですが、サービスを中断せずにテナント VLAN を既存のオーバークラウドに追加することはできません。

director は、トラフィック種別の中から 6 つを特定のサブネットまたは VLAN にマッピングする方法を提供します。このようなトラフィック種別には、以下が含まれます。

  • 内部 API
  • Storage
  • ストレージ管理
  • テナントネットワーク
  • 外部
  • 管理 (オプション)

未割り当てのネットワークは、プロビジョニングネットワークと同じサブネットに自動的に割り当てられます。

下図では、ネットワークが個別の VLAN に分離されたネットワークトポロジーの例を紹介しています。各オーバークラウドノードは、ボンディングで 2 つ (nic2 および nic3) のインターフェースを使用して、対象の VLAN 経由でこれらのネットワークを提供します。また、各オーバークラウドのノードは、ネイティブの VLAN (nic1) を使用するプロビジョニングネットワークでアンダークラウドと通信します。

Example VLAN Topology using Bonded Interfaces

以下の表は、異なるネットワークのレイアウトをマッピングするネットワークトラフィック例が記載されています。

表3.3 ネットワークマッピング

 

マッピング

インターフェースの総数

VLAN の総数

外部アクセスのあるフラットネットワーク

ネットワーク 1: プロビジョニング、内部 API、ストレージ、ストレージ管理、テナントネットワーク

ネットワーク 2: 外部、Floating IP (オーバークラウドの作成後にマッピング)

2

2

分離ネットワーク

ネットワーク 1: プロビジョニング

ネットワーク 2: 内部 API

ネットワーク 3: テナントネットワーク

ネットワーク 4: ストレージ

ネットワーク 5: ストレージ管理

ネットワーク 6: 管理 (オプション)

ネットワーク 7: 外部、Floating IP (オーバークラウドの作成後にマッピング)

3 (ボンディングインターフェース 2 つを含む)

7

3.3. ストレージのプランニング

注記

任意のドライバーまたはバックエンド種別のバックエンド cinder ボリュームを使用するゲストインスタンスで LVM を使用すると、パフォーマンス、ボリュームの可視性/可用性、およびデータ破損の問題が生じます。このような問題は、LVM フィルターを使用すると緩和することができます。詳しくは、『ストレージガイド』「バックエンド」および KCS アーティクル「Using LVM on a cinder volume exposes the data to the host」を参照してください。

director は、オーバークラウド環境にさまざまなストレージオプションを提供します。オプションは以下のとおりです。

Ceph Storage ノード

director は、Red Hat Ceph Storage を使用して拡張可能なストレージノードセットを作成します。オーバークラウドは、各種ノードを以下の目的で使用します。

  • イメージ: glance は仮想マシンのイメージを管理します。イメージを変更することはできません。OpenStack はイメージバイナリーブロブとして処理し、それに応じてイメージをダウンロードします。glance を使用して、Ceph ブロックデバイスにイメージを保管することができます。
  • ボリューム: cinder ボリュームはブロックデバイスです。OpenStack では、ボリュームを使用して仮想マシンをブートしたり、ボリュームを実行中の仮想マシンにアタッチしたりします。OpenStack は Cinder サービスを使用してボリュームを管理します。イメージの CoW (Copy-on-Write) クローンを使用して、Cinder により仮想マシンをブートすることができます。
  • ゲストディスク: ゲストディスクは、ゲストオペレーティングシステムのディスクです。デフォルトでは、Nova で仮想マシンをブートすると、ディスクは、ハイパーバイザーのファイルシステム上のファイルとして表示されます (通常 /var/lib/nova/instances/<uuid>/ の配下)。Ceph 内にあるすべての仮想マシンを cinder を使用せずに直接ブートすることができます。これにより、ライブマイグレーションのプロセスを使用して、簡単にメンテナンス操作を実行することができるので便利です。また、ハイパーバイザーが停止した場合には、nova evacuate をトリガーして、ほぼシームレスに仮想マシンを別の場所で実行することもできるので便利です。

    重要

    Ceph 内で仮想マシンをブートする場合は (一時バックエンドまたはボリュームからのブート)、glance イメージの形式を RAW 形式にする必要があります。Ceph では、仮想マシンディスクをホストするのに、QCOW2 または VMDK 等の他のイメージ形式はサポートされません。

その他の情報については、『Red Hat Ceph Storage Architecture Guide』を参照してください。

Swift Storage ノード
director は、外部オブジェクトストレージノードを作成します。これは、オーバークラウド環境でコントローラーノードをスケーリングまたは置き換える必要があるが、高可用性クラスター外にオブジェクトストレージを保持する必要がある場合に便利です。