デプロイメントのプランニング

Red Hat OpenStack Services on OpenShift (RHOSO) IaaS サービスは、Red Hat OpenShift Container Platform (RHOCP) クラスター上で実行される一連の Operator として実装されます。これらの Operator は、RHOSO クラウドのコンピュート、ストレージ、ネットワーク、およびその他のサービスを管理します。

OpenStack Operator (openstack-operator) は、Services テーブルに詳細が記載されているすべてのサービス Operator をインストールします。また、それらの Operator を管理するために使用するインターフェイスです。OpenStack Operator は、次の Operator もインストールして管理します。

各サービスの機能の詳細は、Red Hat OpenStack Services on OpenShift 18.0 ドキュメントポータルのサービス別のドキュメントを参照してください。

Red Hat OpenStack Services on OpenShift (RHOSO) 環境の基本アーキテクチャーは、次の機能を備えています。

次のリストは、Red Hat OpenStack Services on OpenShift (RHOSO) の制限事項の詳細を示しています。既知の制限は、RHOSO でサポートされていない機能です。

Compute サービス (nova):

Image サービス (glance):

Block Storage サービス (cinder):

これらの機能のサポートが必要な場合は、Red Hat Customer Experience and Engagement チーム に問い合わせて、サポートの例外やその他の選択肢 (該当する場合) についてご相談ください。

Red Hat OpenStack Services on OpenShift (RHOSO) は、コンパクトコントロールプレーントポロジーと専用ノードコントロールプレーントポロジーをサポートしています。

コンパクトトポロジーでは、RHOSO コントロールプレーンと Red Hat OpenShift Container Platform (RHOCP) コントロールプレーンが、同じ物理ノードを共有します。

専用ノードトポロジーでは、RHOCP コントロールプレーンが 1 セットの物理ノード上で実行され、RHOSO コントロールプレーンが別のセットの物理ノード上で実行されます。

1.4.1. コンパクトトポロジー

コンパクト RHOSO トポロジーは、デフォルトのトポロジーであり、次のコンポーネントで構成されます。

OpenShift コンパクトクラスター

RHOSO と RHOCP の両方のコントロールプレーンをホストする Red Hat OpenShift クラスター。

RHOSO コントロールプレーンは、Compute サービス (nova)、Networking サービス (neutron) などのサービスで構成される OpenStack コントローラーサービス Pod で構成されます。

OpenShift コントロールプレーンは、RHOCP に必要なサービス (OpenShift サービス、Kubernetes サービス、ネットワークコンポーネント、Cluster Version Operator、および etcd) を実行する Pod をホストします。

詳細は、RHOCP アーキテクチャー ガイドの OpenShift Container Platform の紹介 を参照してください。

RHOSO データプレーン

RHOSO データプレーンは、OpenStack Compute ノードで構成されます。ストレージ専用のノードはオプションです。

図1.1 コンパクト RHOSO トポロジー

1.4.2. 専用ノードトポロジー

専用ノード RHOSO トポロジーは、RHOSO コントロールプレーン用のノードクラスターと OpenShift コントロールプレーン用のノードクラスターが分かれている点で、コンパクトトポロジーと異なります。

図1.2 専用ノード RHOSO トポロジー

RHOCP でホストされるコントロールプレーンを備えた RHOSO クラウドを作成するには、次のタスクを完了する必要があります。

コントロールプレーンのインストールタスクとすべてのデータプレーンの作成タスクは、RHOCP クラスターにアクセスできるワークステーションで実行します。

OpenStack Operator には、RHOSP リソースの作成と管理に使用できるカスタムリソース定義 (CRD) のセットが含まれています。

Red Hat OpenStack Services on OpenShift (RHOSO) コントロールプレーンをホストする Red Hat OpenShift Container Platform (RHOCP) クラスターの最小要件は次のとおりです。

データプレーンは、事前にプロビジョニングされたノード、またはプロビジョニングされていないベアメタルノードを使用して作成できます。データプレーンノードの最小要件は次のとおりです。

Compute ノードは、仮想マシンインスタンスの起動後にそれを実行する役割を担います。Compute ノードには、ハードウェアの仮想化をサポートするベアメタルシステムが必要です。また、ホストする仮想マシンインスタンスの要件をサポートするのに十分なメモリーとディスク容量も必要です。

Compute ノードメモリー設定の計画の詳細は、インスタンス作成のための Compute サービスの設定 を参照してください。

RHOCP クラスターのインストールに使用する方法によって、Cluster Baremetal Operator (CBO) の可用性とプロビジョニングネットワークを作成する機能が決まります。ネットワークブートにはプロビジョニングネットワークが必要です。

Red Hat OpenShift Container Platform (RHOCP) Cluster Baremetal Operator (CBO) では、データプレーン上のベアメタルノードのプロビジョニングがサポートされています。CBO は、Bare Metal Operator (BMO) や Ironic コンテナーを含め、RHOCP クラスター内でベアメタルノードをプロビジョニングするために必要なコンポーネントをデプロイします。

BMO はクラスターの利用可能なホストを管理し、次の操作を実行します。

Bare Metal Operator の詳細と BareMetalHost CR の設定方法については、RHOCP インストール後設定 ガイドの ベアメタルの設定 を参照してください。

通常、Red Hat OpenStack Services on OpenShift (RHOSO) デプロイメントでは、次の物理データセンターネットワークが実装されます。

詳細は、Red Hat OpenStack Services on OpenShift のデプロイ ガイドの デフォルトの Red Hat OpenStack Services on OpenShift ネットワーク を参照してください。

デプロイメントで特定の種類のネットワークトラフィックを分離してホストする方法を計画する必要があります。これには、IP 範囲、サブネット、仮想 IP の計画、および NIC レイアウトの設定が含まれます。

Red Hat OpenStack Services on OpenShift (RHOSO) コントロールプレーンサービスは、Red Hat OpenShift Container Platform (RHOCP) のワークロードとして実行されます。コントロールプレーンで NMState Operator を使用して、必要な分離ネットワークにワーカーノードを接続します。必要に応じて、各分離ネットワークに NetworkAttachmentDefinition (nad) カスタムリソース (CR) を作成し、分離ネットワークにサービス Pod を接続します。MetalLB Operator を使用して、分離ネットワーク上の内部サービスエンドポイントを公開します。デフォルトでは、パブリックサービスエンドポイントは RHOCP ルートとして公開されます。

また、仮想 IP の通知方法を定義する L2Advertisement リソースと、VIP として使用できる IP を設定する IpAddressPool リソースも作成する必要があります。レイヤー 2 モードでは、1 つのノードがローカルネットワークにサービスをアドバタイズする役割を担います。

詳細は、Red Hat OpenStack Services on OpenShift のデプロイ ガイドの RHOSO のネットワーク分離に向けた RHOCP の準備 を参照してください。

データプレーンネットワークを作成するには、NetConfig カスタムリソース (CR) を定義し、データプレーンネットワークのすべてのサブネットを指定します。データプレーン用に少なくとも 1 つのコントロールプレーンネットワークを定義する必要があります。また、VLAN ネットワークを定義して、InternalAPI、Storage、External などのコンポーザブルネットワークのネットワーク分離を作成することもできます。各ネットワーク定義には IP アドレスの割り当てを含める必要があります。

詳細は、Red Hat OpenStack Services on OpenShift のデプロイ ガイドの データプレーンネットワークの作成 を参照してください。

コンパクトな RHOSO デプロイメントでは、各 RHOSO コントロールプレーンワーカーノードに、少なくとも 2 つの NIC が必要です。

各ワーカーノード上の一方の NIC が、OpenShift にサービスを提供します。また、OpenShift クラスターネットワーク内の OpenShift コンポーネント間の接続を提供します。

もう一方の NIC は、OpenStack に使用されます。ワーカーノード上で実行されている OpenStack サービスを、RHOSO データプレーン上の分離ネットワークに接続します。

詳細は、このガイドの ストレージネットワーク を参照してください。

ネットワーク機能仮想化 (NFV) は、通信事業者 (CSP) が従来のプロプライエタリーハードウェアの範囲を超えて効率性と俊敏性を高め、運用コストを削減するのに役立つソフトウェアベースのソリューションです。

Red Hat OpenStack Services on OpenShift (RHOSO) 環境で NFV を使用すると、スイッチ、ルーター、ストレージなどのハードウェアデバイス上で実行されるネットワーク機能 (VNF) を標準の仮想化テクノロジーを使用して仮想化する仮想化インフラストラクチャーを実現して、IT とネットワークを融合することができます。NFV 環境では、Data Plane Development Kit (DPDK) と Single Root I/O Virtualization (SR-IOV) テクノロジーを活用して、パケット処理速度を向上させます。

NFV のデプロイを選択した場合は、デプロイガイドとして Red Hat OpenStack Services on OpenShift のデプロイ ではなく ネットワーク機能仮想化環境のデプロイ を使用する必要があります。

Red Hat OpenStack Services on OpenShift (RHOSO) コントロールプレーンをインストールする前に、iscsi.conf を変更して MD5 と SHA1 を削除する必要があります。コントロールプレーンの iSCSId 設定は、RHOSO Operator によって処理されません。そのため、この手順は Red Hat OpenShift Container Platform (RHOCP) クラスターで完了する必要があります。

RHOCP またはデプロイされたワーカーノードの FIPS ステータスを確認できます。

FIPS モードでの Red Hat OpenShift Cluster Platform のインストールの詳細は、RHOCP インストール ガイドの FIPS 暗号化のサポート を参照してください。

RHOSO は次のストレージおよびネットワーク機能をサポートしています。

RHOSO は次のストレージサービスをサポートしています。

プロジェクトによるシステムリソースの消費を管理するには、Block Storage サービス (cinder) と Shared File Systems サービス (manila) のクォータを設定できます。デフォルトのクォータをオーバーライドして、個々のプロジェクトに異なる消費制限を設定できます。

RHOSO は、デプロイメントにストレージソリューションを提供するために、個別にまたは連携して動作する多数のストレージテクノロジーをサポートしています。

RHOSO のインストール中に、ストレージネットワークとストレージ管理ネットワークという 2 つのデフォルトのストレージ関連ネットワークが設定されます。これらの分離されたネットワークは、ストレージコンポーネントとデプロイメント間のネットワーク接続に関するベストプラクティスに準拠しています。

ストレージネットワークは、データストレージへのアクセスと取得に使用されます。

ストレージ管理ネットワークは、管理コンソールへのアクセスを許可するストレージソリューション内の特定のインターフェイスにアクセスするために、RHOSO サービスによって使用されます。たとえば、Red Hat Ceph Storage はハイパーコンバージドインフラストラクチャー (HCI) 環境のストレージ管理ネットワークを cluster_network として使用し、データを複製します。

次の表に、デフォルトのストレージ関連ネットワークのプロパティーを示します。

ストレージソリューションによっては、追加のネットワーク設定が必要になる場合があります。これらのデフォルト値は、完全なデプロイメントを構築する基盤となるものです。

バックエンド (cinder-volume および cinder-backup) を持つすべての Block Storage サービスは、すべてのストレージネットワークへのアクセスを必要とします。バックエンドによっては、これにストレージ管理ネットワークが含まれない場合があります。バックエンドを持つ Block Storage サービスは、それぞれのストレージ管理ネットワークへのアクセスだけを必要とします。ほとんどのデプロイメントで管理ネットワークは 1 つだけです。ストレージ管理ネットワークが複数ある場合も、サービスとバックエンドの各ペアに必要なのは、それぞれの管理ネットワークへのアクセスだけです。

Block Storage サービスとファイバーチャネル (FC) バックエンドを使用するデプロイメントでは、すべての OCP ワーカーノードにホストバスアダプター (HBA) をインストールする必要があります。

apiVersion: core.openstack.org/v1beta1
kind: OpenStackControlPlane
metadata:
  name: openstack
spec:
  cinder:
    template:
      cinderVolumes:
        iscsi:
          networkAttachments:
          - storage
          - storageMgmt

一般に、クラスター化されたストレージソリューションでは、バックエンドのスケーラビリティーと回復力が向上します。たとえば、Red Hat Ceph Storage を Block Storage (cinder) バックエンドとして使用する場合、Ceph Object Storage Daemon (OSD) ノードを追加することで、ストレージの容量と冗長性を拡張できます。Block Storage、Object Storage (swift)、および Shared File Systems Storage (manila) サービスは、バックエンドとして Red Hat Ceph Storage をサポートしています。

Block Storage サービスは、個別のバックエンドとして複数のストレージソリューションを使用できます。バックエンドを追加することで、サービスレベルで容量を拡張できます。

デフォルトでは、Object Storage サービスは、OpenShift の基盤となるインフラストラクチャーに永続ボリュームを割り当てることによって領域を消費します。専用ストレージノード上のファイルシステムを使用するようにサービスを設定すると、そのサービスで領域を最大限に使用できます。Object Storage サービスは、XFS および ext4 ファイルシステムをサポートしています。両方のファイルシステムを拡張することで、基盤となるブロックストレージを最大限に消費できます。ストレージノードにストレージデバイスを追加することで、容量を拡張することもできます。

Shared File Systems サービスは、Red Hat Ceph Storage やその他のバックエンドストレージシステムによって管理される指定のストレージプールからファイル共有をプロビジョニングします。この共有ストレージは、サービスで使用可能なストレージプールのサイズまたは数を増やすか、バックエンドストレージシステムをデプロイメントに追加することで拡張できます。各バックエンドストレージシステムは、ストレージシステムと対話して管理する専用サービスと統合されています。

ボリュームはインスタンスを通じてのみ消費されます。ユーザーは、ボリュームの拡張、スナップショットの作成、スナップショットを使用したボリュームの複製、以前の状態へのボリューム復元を実行できます。

Block Storage サービス (cinder) を使用すると、ボリューム設定をまとめたボリュームタイプを作成できます。ボリュームタイプを QoS (Quality of Service) 仕様に関連付けることで、クラウドユーザーにさまざまなレベルのパフォーマンスを提供できます。クラウドユーザーは、新しいボリュームを作成するときに必要なボリュームタイプを指定できます。たとえば、より高いパフォーマンスの QoS 仕様を使用するボリュームは、より多くの IOPS をユーザーに提供できます。また、ユーザーは、リソースを節約するために、より低いパフォーマンスの QoS 仕様を使用するボリュームに軽いワークロードを割り当てることができます。共有は、1 つ以上のインスタンス、ベアメタルノード、またはコンテナーによって同時に消費される場合があります。Shared File Systems サービス (manila) は、共有のサイズ変更、スナップショット、クローン作成もサポートしています。管理者は設定をまとめた共有タイプを作成できます。

ユーザーは、Object Storage サービス (swift) の API を使用してコンテナー内のオブジェクトにアクセスできます。管理者は、クラウド内のインスタンスとサービスからオブジェクトにアクセス可能にできます。そのため、オブジェクトはサービスのリポジトリーとして最適です。たとえば、Image サービス (glance) のイメージを、Object Storage サービスによって管理されるコンテナーに保存できます。

Block Storage サービスは、Key Manager サービス (barbican) を通じてデータセキュリティーを提供します。Block Storage サービスは、Key Manager サービスによって管理される鍵を使用して、鍵とボリュームの 1 対 1 のマッピングを使用します。ボリュームタイプを設定するときに暗号化のタイプを定義します。

制御トラフィックやデータトラフィックを暗号化することで、バックエンドレベルでセキュリティーを向上させることもできます。たとえば、Red Hat Ceph Storage では、messengerv2 セキュアモードを有効にすることでこれを実現できます。このモードを有効にすると、Ceph サービス間および OpenStack Compute ノードからのネットワークトラフィックが暗号化されます。

オブジェクトとコンテナーのセキュリティーは、サービスおよびノードレベルで設定します。Object Storage サービス (swift) は、コンテナーおよびオブジェクトに対するネイティブの暗号化を提供しません。ただし、Key Manager サービスが有効になっていれば、Object Storage サービスが、保存されている (保存中の) オブジェクトを透過的に暗号化および復号化できます。保存時の暗号化は、オブジェクトがディスクに保存されている間に暗号化されるという点で、転送中の暗号化とは異なります。

Shared File Systems サービス (manila) では、インスタンスの IP アドレス、ユーザーもしくはグループ、または TLS 証明書別にアクセス制限することでファイル共有のセキュリティーを確保することができます。Shared File Systems サービスのデプロイメントによっては、個別の共有サーバーを用意して、共有ネットワークとファイル共有の関係を管理できます。共有サーバーによっては、追加のネットワークセキュリティーがサポートまたは要求されます。たとえば、CIFS ファイル共有サーバーでは LDAP、Active Directory または Kerberos 認証サービスのデプロイメントが必要です。

バックエンドによっては、データの保存時の暗号化もサポートされています。これにより、バックエンドディスク自体を暗号化してセキュリティーを強化し、消去されていないディスクの再利用や盗難など、物理的なセキュリティー上の脅威を防ぐことができます。

Block Storage サービス、Object Storage サービス、Shared File Systems サービスのセキュリティーオプションの設定について、詳細は セキュリティーサービスの設定 を参照してください。

オプションの Block Storage バックアップサービスをデプロイすると、Block Storage サービス (cinder) によって、ユーザーストレージの基本的な障害復旧に対応したボリュームのバックアップおよび復元機能が提供されます。バックアップを使用すると、ボリュームの内容を保護できます。Block Storage サービスはスナップショットもサポートしています。クローン作成に加えて、スナップショットを使用してボリュームを以前の状態に復元することもできます。

環境に複数のバックエンドが含まれている場合は、これらのバックエンド間でボリュームを移行することもできます。この機能は、メンテナンスでバックエンドをオフラインにする必要がある場合に役立ちます。バックアップは通常、データが保護できるように、ソースのボリュームとは別のストレージバックエンドに保存されます。スナップショットはソースのボリュームに依存するため、この方法を用いることはできません。

Block Storage サービスは、ボリュームをグループ化して同時にスナップショットを作成するために、整合性グループの作成もサポートしています。これにより、複数のボリューム間のデータの整合性レベルが向上します。

Object Storage (swift) サービスには、ビルトインのバックアップ機能はありません。すべてのバックアップを、ファイルシステムまたはノードレベルで実行する必要があります。一方で、Object Storage サービスは、堅牢な冗長性とフォールトトレランスを備えています。Object Storage サービスの最も基本的なデプロイメントでも、オブジェクトが複数回レプリケートされます。デバイスマッパーマルチパス (DM マルチパス) などのフェイルオーバー機能を使用して、冗長性を強化できます。

Shared File Systems サービス (manila) は、共有用の組み込みバックアップ機能を備えていませんが、クローン作成と復元用のスナップショットを作成できます。

RHOSO の設定は、RHOSO Dashboard (horizon) または RHOSO コマンドラインインターフェイス (CLI) を使用して管理できます。どちらの方法でもほとんどの手順を実行できます。ただし、一部の高度な手順を実行するには、CLI を使用する必要があります。

ストレージソリューションの設定は、ストレージベンダーが提供する専用の管理インターフェイスを使用して管理できます。

Image および Object Storage サービスは、Red Hat OpenShift の基盤ストレージに領域を確保するように設定できます。その場合、これらのサービスの予想使用量に基づいて Red Hat OpenShift ストレージのサイズを見積もる必要があります。

...
default:
  storage:
    external: true
...
...
extraMounts:
- extraVol:
  - extraVolType: NFS
    mounts:
    - mountPath: /var/lib/glance/os_glance_staging_store
      name: nfs
    volumes:
    - name: nfs
      nfs:
        path: <nfs_export_path>
        server: <nfs_ip_address>

...
default:
  replicas: 3
  storage:
    storageRequest: 10G
...