RHOCP 4 ノードは Red Hat Enterprise Linux CoreOS (RHCOS) で実行します。RHCOS は Red Hat Enterprise Linux (RHEL) カーネルで OTA (over-the-air) 更新を提供し、セキュアで簡単に管理されるコンテナーホストを提供します。インストーラーによってプロビジョニングされたインフラストラクチャーのデプロイメントでは、この参照アーキテクチャーでは、RHCOS がすべての RHOCP ノードでサポートされているオペレーティングシステムであり、worker ノードと master ノードでデフォルトで使用されます。また、master ノードが RHCOS を実行する RHOCP 要件でもあります。

Red Hat OpenStack Platform (RHOSP) および RHOCP の両方のインストールプログラムは、インターネットへの直接アクセスと Red Hat 製品への有効なサブスクリプションを活用することができます。インストールプロセスは自己完結していないため、以下のようなコアアセットを取得するために外部ソースへのアクセスが必要になります。

したがって、アクティブな動作中の DNS 解決が必要です。

RHOCP インストーラーによってプロビジョニングされたインフラストラクチャーデプロイメントでは、構成ファイルを使用してインストール時に、またはクラスター全体の出力プロキシーを使用してインストール時に、HTTP または HTTPS クラスター全体のプロキシーの実装をサポートします。クラスター全体のプロキシーの設定方法は、『OpenShift Container Platform ネットワーク』ガイドの「クラスター全体のプロキシーの設定」を参照してください。

RHOSP 13 の RHOCP 4 はネットワークが制限されたデプロイメントを完全にサポートしますが、追加の手順およびこの参照アーキテクチャーでテストされていないコンポーネントが必要です。この参照アーキテクチャーをネットワークが制限された環境で実装する前に、『OpenShift Container Platform インストール』ガイドの「ネットワークが制限された環境でのインストール用のミラーレジストリーの作成」を参照してください。

RHOSP director は、OpenStack TripleO プロジェクトをベースとした管理およびインストールツールです。TripleO は「OpenStack on OpenStack」を表します。 この参照アーキテクチャーでは、director を使用して RHOSP をインストールします。

Director の背後にある基本的な概念は、2 つのクラウドがあるということです。アンダークラウドと呼ばれる最初のクラウドは、スタンドアロンの RHOSP デプロイメントです。アンダークラウドは、1 つの物理サーバーまたは仮想マシンにデプロイできます。管理者は、アンダークラウドの RHOSP サービスを使用して実稼働用の RHOSP クラウドを定義し、デプロイします。Director は、ソフトウェアの更新の適用や RHOSP バージョン間のアップグレードなど、2 つの管理操作にも使用されます。

2 つ目のクラウド (オーバークラウド) は、アンダークラウドによってデプロイされるフル機能の実稼働環境です。オーバークラウドは、さまざまなロールを持つ物理サーバーで構成されます。

RHOCP は、オーバークラウドのプロジェクト (またはテナント) 内で実行します。各テナントの RHOCP クラスターは、他のテナントクラスターから分離されます。

Director は、すべての実稼働 RHOSP デプロイメントに必要です。Red Hat エンジニアリングによりテストおよび検証される構成設定は、director が提供するデプロイメントツールに組み込まれています。

管理者は、director を使用して RHOSP クラウドのみをプロビジョニングし、管理する必要があります。カスタマイズは director を使用してのみ実行し、手動で追加しないでください。

RHOCP 4 インストールプログラムは、インストーラーでプロビジョニングされるインフラストラクチャーと、ユーザーによってプロビジョニングされるインフラストラクチャーの 2 つの方法でのデプロイメントをサポートします。

RHOCP 4 インストールプログラムは、主にインフラストラクチャーを設定するための簡単なパスを確保することを検討しています。Day 2 操作は RHOCP 設定の大部分を処理します。インフラストラクチャーを設定するには、インストールプログラムは最小限の RHOCP クラスターを作成します。

RHOSP director により実施されるデフォルトの HA レベルは 3 つの Controller ノードをデプロイします。複数の RHOSP サービスおよび API は、3 つすべてのコントローラーノードで同時に実行されます。

HAProxy はコントローラー API エンドポイント全体の接続を負荷分散し、サービスの可用性を確保します。Controller ノードは、RHOSP 状態のデータベースおよびメッセージバスも実行します。Galera クラスターは状態データベースを保護します。RabbitMQ キューは、メッセージバスを保護するためにすべてのノードで複製されます。

RHOCP も HA 用にデプロイされます。コントロールプレーンは RHOCP クラスターを管理します。この参照アーキテクチャーは、マスターノード全体で etcd 状態のデータベースを配置します。etcd には HA に最低 3 つのノードが必要であるため、3 つの master ノードをデプロイする必要があります。

RHOCP は、HA 用 3 つの master ノードで重要なコントロールプレーンコンポーネントをホストします。RHOCP 4.x では、ルーター Pod、コンテナーイメージレジストリー、メトリックスとモニタリングサービス、クラスター集約ログなどのさまざまなインフラストラクチャーサービスは、デフォルトでは個別のインフラストラクチャーノードで実行されなくなりました。代わりに、インフラストラクチャーサービスは worker ノードで実行されるようになりました。インフラストラクチャーサービスをデプロイして、Day 2 のインフラストラクチャーノードを分離することができます。詳細は、「インフラストラクチャー MachineSet の作成」を参照してください。

worker ノードは、実際のアプリケーションワークロードが実行される場所です。master は worker ノードを管理します。過剰な負荷とインフラストラクチャーの損失による障害を処理するのに十分な worker ノードがあることを確認する必要があります。

Red Hat Ceph Storage を使用する RHOCP および RHOSP サービスは、Red Hat Ceph Storage の組み込み HA 機能を活用することができます。デフォルトでは、Red Hat Ceph Storage と共に RHOSP をデプロイすると、Compute サービス、Image サービス、および Block Storage サービスの統合ストレージになります。

Ceph OSD を追加して、パフォーマンスと可用性を向上させることができます。Red Hat Ceph Storage クラスターのサイジングとカスタマイズには特別な注意が必要ですが、この参照アーキテクチャーの対象外となっています。Red Hat Ceph Storage のカスタマイズに関する情報は、以下の参考資料を参照してください。

Red Hat Ceph Storage のカスタマイズを実装する方法については、Red Hat サポートを参照してください。

ハードウェアレイヤーで単一障害点を排除する必要があります。ハードウェアフォールトトレランスには、以下が含まれる場合があります。

ハードウェアのフォールトトレランスの設定方法に関する詳細は、本書では扱いません。

この参照アーキテクチャーでは、Red Hat Ceph Storage を使用します。Red Hat Ceph Storage はスケーラブルなブロック、オブジェクト、およびファイルストレージを提供し、Red Hat クラウドソフトウェアスタックと密接に統合されています。

Red Hat Ceph Storage は、優れたパフォーマンス、信頼性、スケーリングを提供するように設計された、分散型のデータオブジェクトストレージです。Red Hat Ceph Storage のデプロイメントはすべて、2 種類のデーモンで構成される Ceph Storage Cluster です。

RHOSP director は ceph-ansible.yaml 環境ファイルを使用して Red Hat Ceph Storage をデプロイします。この環境ファイルは、OpenStack Compute (nova) の一時ディスク、OpenStack Block Storage (cinder) ボリューム、OpenStack Image サービス (glance)、および OpenStack Telemetry (ceilometer) のバッキングストアとして、Red Hat Ceph Storage を自動的に設定します。

使用する Red Hat Ceph Storage のバージョンにより、使用するストレージバックエンドが決まります。

最高のパフォーマンスを得るため、すべての新規デプロイメントには BlueStore を使用する必要があります。RHOSP 13 は Red Hat Ceph Storage 3.3 と統合されており、director は BlueStore を使用した OSD の作成をサポートしています。RHOSP 16.0 は Red Hat Ceph Storage 4 を実装し、デフォルトでは BlueStore をバックエンドとして使用します。RHOSP 16.0 では、FileStore バックエンドのサポートが廃止されます。OSD ノードをデプロイしている Director はすべて専用の物理サーバーで実行する必要があります。

詳細は、以下の参考資料を参照してください。

Kubernetes 永続ボリューム (PV) フレームワークを使用すると、RHOCP ユーザーは、基盤となるストレージの知識がなくてもブロックストレージボリュームをリクエストできます。

RHOCP は、この機能のプロバイダーとして OpenStack Block Storage サービス (cinder) をサポートします。RHOCP ユーザーは、PersistentVolume オブジェクト定義を使用して RHOSP の OpenStack Block Storage ボリュームにアクセスできます。

RHOCP インストールプログラムは、kubernetes.io/cinder ドライバーを使用して動的永続ボリューム作成用の OpenStack Block Storage ストレージクラスの作成を自動化します。

$ oc get storageclass
NAME                 PROVISIONER            RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
standard (default)   kubernetes.io/cinder   Delete          WaitForFirstConsumer   true                   3d20h

詳細は「Cinder を使用した永続ストレージ」を参照してください。

director は RHOSP のインストール時にオブジェクトストレージを考慮しません。デフォルトでは、director は OpenStack Object Storage (swift) をコントローラーノードにインストールし、OpenStack Image サービス (glance) 用の使いやすい高可用性オブジェクトストレージバックエンドを提供します。これは、テナントが使用する場合には推奨されるオブジェクトストレージソリューションではなく、クラウド管理者がアクセスを明示的に付与する必要があります。

この参照アーキテクチャーでは、デフォルトの OpenStack Object Storage を Red Hat Ceph Object Gateway (RGW または radosgw) に置き換え、Amazon S3 および OpenStack Object Storage RESTful API と互換性のある高可用性オブジェクトストレージバックエンドを提供することができます。

director を使用して Red Hat Ceph Storage をデプロイする場合、OpenStack Image Service (glance) のデフォルトのインストールは、Red Hat Ceph Block Devices (RBD) によってサポートされます。RHOCP インストールプログラムは、以下の 2 つの目的で OpenStack Image サービスを使用します。

OpenStack Networking (neutron) サービスは、さまざまなバックエンドネットワークプラグインに共通の抽象化層を提供します。RHOSP 13 および 16.0 では、以下のバックエンドネットワークプラグインがサポートされます。

プロバイダーネットワークは、外部からアクセス可能な Floating IP アドレスの範囲をテナントインスタンスにブリッジします。リモートクライアントは Floating IP アドレスを使用して、公開された RHOCP サービス、OpenShift API エンドポイント、および Web コンソールにアクセスします。

OpenStack ネットワークサービスに関する詳しい説明は、本書の対象外となります。詳細は、以下の参考資料を参照してください。

Red Hat OpenShift Container Platform (RHOCP) のネットワークは複雑なトピックで、詳細なレビューは本書の範囲外です。詳細は「ネットワーク」を参照してください。

RHOSP デプロイメントの RHOCP には、インストール前およびインストール後に、以下の DNS 要件があります。

platform:
  openstack:
    cloud: openstack
    computeFlavor: m1.large
    externalNetwork: public
    lbFloatingIP: 192.168.122.152
    octaviaSupport: "1"
    region: ""
    trunkSupport: "1"

デフォルトで、RHOSP アイデンティティーサービスはユーザーの認証情報を状態データベースに保存するか、LDAP 準拠のディレクトリーサーバーを使用することができます。同様に、RHOSP の認証および認可は別のサービスに委譲できます。

RHOCP master ノードはトークンを発行し、API でユーザー要求を認証します。RHOCP は、HTPassword や LDAP を含むさまざまなアイデンティティープロバイダーをサポートします。

RHOCP 4.x 以降、RHOCP および RHOSP アイデンティティープロバイダーが統合されています。管理者は、OpenStack Identity (keystone) サービスを使用して RHOCP keystone アイデンティティープロバイダーを設定することができます。この設定により、ユーザーは OpenStack Identity (keystone) の認証情報を使用して RHOCP にログインすることができます。詳細は、「Keystone アイデンティティープロバイダーの設定」を参照してください。

コントロールプレーンの仮想マシンは etcd のキーと値ストアを実行するため、既知のリソース要件を満たす必要があります。高速ディスクは、etcd の安定性とパフォーマンスにとって最も重要です。etcd はディスク書き込みレイテンシーの影響を受けます。

etcd ディスク要件についての詳細は、「Hardware recommendations - Disks」を参照してください。

この参照アーキテクチャーでは、安定性と保証のサポート性を確保するために、すべてのマスターが高速なディスク (SSD 以上) にアクセスする必要があります。ディスクのパフォーマンスに関するニーズについては、Red Hat アカウントチームにお問い合わせください。

クラスターにストレージを提供するすべてのオプションは本書の範囲外です。以下のセクションでは、最も一般的なオプションを簡単に分析する方法を説明します。

$ openstack volume type list
+---------------------------------------+---------+-------------------+
 | ID                                   | Name    | Is Public         |
+---------------------------------------+---------+-------------------+
 | 37c2ed76-c9f7-4b0d-9a35-ab02ca6bcbb2 | tripleo | True              |
+---------------------------------------+---------+-------------------+

controlPlane:
  hyperthreading: Enabled
  name: master
  platform:
    openstack:
      type: m1.large
      rootVolume:
        size: 25
        type: tripleo
  replicas: 1

$ openstack volume list
---------------------------------------------------------------------------------------------------------------------------
| ID                                   | Name                  | Status | Size | Attached to                                    |
---------------------------------------------------------------------------------------------------------------------------
| b555cc99-3317-4334-aa19-1184a78ee3f8 | ostest-8vt7s-master-0 | in-use |   25 | Attached to ostest-8vt7s-master-0 on /dev/vda  |
---------------------------------------------------------------------------+-------------------------------------------------

[core@ostest-8vt7s-master-0 ~]$ df -h
Filesystem                            Size  Used Avail Use% Mounted on
devtmpfs                              7.8G     0  7.8G   0% /dev
tmpfs                                 7.9G   84K  7.9G   1% /dev/shm
tmpfs                                 7.9G   18M  7.9G   1% /run
tmpfs                                 7.9G     0  7.9G   0% /sys/fs/cgroup
/dev/mapper/coreos-luks-root-nocrypt   25G   19G  6.2G  75% /sysroot
none                                  2.0G  435M  1.6G  22% /var/lib/etcd
/dev/vda1                             364M   84M  257M  25% /boot
/dev/vda2                             127M  3.0M  124M   3% /boot/efi
tmpfs                                 1.6G  4.0K  1.6G   1% /run/user/1000

compute:
- hyperthreading: Enabled
  name: worker
  platform:
    openstack:
      type: m1.large
      rootVolume:
        size: 25
        type: tripleo-ssd
  replicas: 3
controlPlane:
  hyperthreading: Enabled
  name: master
  platform:
    openstack:
      type: m1.large
      rootVolume:
        size: 25
        type: tripleo-nvme
  replicas: 3

この参照アーキテクチャーは、以下の手順で説明する手順でテストされていません。

RHOSP で RHOCP でこの機能を使用する場合は、Red Hat サポートにお問い合わせください。

RHOCP を RHOSP にデプロイする場合は、ReadWriteMany (RWX) PersistentVolume のサポートがありません。RWX ボリュームは、数多くのノードで読み取り/書き込みとしてマウントできるボリュームです。詳細は、「永続ストレージについて」を参照してください。

RHOCP には多くの PersistentVolume プラグインがありますが、現在 RHOSP で RHOCP 用にテストされているのは Red Hat OpenStack Block Storage (cinder) です。OpenStack Block Storage は、さまざまなストレージプロバイダーに便利なフロントエンドを提供します。OpenStack Block Storage を使用すると、他のすべてのクラウドリソースと同様に、基礎となるストレージ要求は OpenStack API を使用して管理されます。これにより、オンデマンドインフラストラクチャーのすべての要素にわたってインフラストラクチャー管理者に一貫した管理が提供され、リソース割り当ての管理と追跡が容易になります。

OpenStack Block Storage は RWX をサポートしないため、RHOSP デプロイメントでの RHOCP 4.4 では RWX PersistentVolume を提供することができません。RWX 永続ボリュームのサポートは、OpenStack Shared-Filesystems-as-a-Service (manila) CSI プラグインにより RHOSP 上の RHOCP の今後のリリースで提供されます。

Red Hat OpenShift Container Storage は永続的なソフトウェア定義のストレージで、RHOCP 向けに統合され、最適化されます。OpenShift Container Storage は、RHOCP 内で直接実行されるコンテナー化されたソリューションを使用して、RHOCP インストールへのストレージを提供します。

RHOCP の場合、OpenShift Container Storage は、基盤のストレージを使用して RHOCP で実行される一意の Red Hat Ceph Storage クラスターを作成することにより、完全に独立したコンテナー化された Red Hat Ceph Storage デプロイメントを提供します。OpenShift Container Storage はアップストリームの Rook-Ceph Operator を使用してこれを行います。

この記事の執筆時点では、RHOSP 環境の RHOSP で OpenShift Container Storage を使用することはサポートされていません。このシナリオのサポートは、OpenShift Container Storage の今後のリリースで予定されています。

オーバークラウドのデプロイメントは、次のもので構成されています。

次のドキュメントで説明されているように、エンドポイントは、SSL/TLS を介してオーバークラウドにアクセスするのに DNS ホスト名を使用しません。

RHOCP インストールプログラムでは、IP ベースのエンドポイントの前にあるこれらの証明書を、SAN (Subject Alternative Name) の一部にする必要があります。

参照アーキテクチャーでは、以下の参考資料に従って、director ホストのローカル CA 信頼に ca.crt.pem ファイルも追加します。

これにより、アンダークラウドはオーバークラウドエンドポイントの自己署名証明書と通信でき、RHOCP インストールプログラムが、インストール時に RHOCP に必要なコンポーネントとプライベート CA を共有できるようにします。

この参照アーキテクチャーでは、完全に SSD でサポートされた 3 つの専用ストレージノードに Red Hat Ceph Storage をデプロイします。これは、この参照アーキテクチャーの RHOCP ノードで提供されるストレージが、追加の設定要件なしにも高速になるようにするために使用されます。上記のように、ストレージのセットアップは異なる場合があるため、個々の要件と一意のハードウェアに基づいて考慮する必要があります。

この参照アーキテクチャーでは、OSD バックエンドとして BlueStore を使用して Red Hat Ceph Storage がデプロイされます。Red Hat は、Red Hat Ceph Storage 3.3 以降を使用する RHOSP 13 のすべての新規デプロイメントの OSD バックエンドとして BlueStore を使用する Red Hat Ceph Storage を使用することを推奨します。OSD バックエンドとして BlueStore を使用する Red Hat Ceph Storage は、Ceph 4.x を使用する RHOSP 16.0 のデフォルトであるため、特定のアクションは必要ありません。

/usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-rgw.yaml

このテンプレートを使用すると、Controller ノードへのデフォルトの OpenStack Object Storage (swift) のインストールが自動的に無効になります。

RHOSP クラウド管理者は、Object Storage へのアクセスを明示的に許可する必要があります。RGW へのアクセスを許可するには、管理者はテナントに「Member」ロールを付与します。

Director はデフォルトの Open vSwitch/OVS プラグインバックエンドをデプロイします。

外部ネットワークは、DNS に追加でき、クライアント Web ブラウザーからアクセス可能なさまざまなルーティング可能なアドレスを提供するプロバイダーネットワークです。

この参照アーキテクチャーは、HostnameMap を使用し、設定ファイル ips-from-pool-all.yaml を使用してすべてのノード種別に IP を事前割り当てます。

ただし、これは QCOW2 形式のイメージの使用も推奨されないことを意味します。詳細は「RAW 形式へのイメージの変換」を参照してください。代わりに、一時バックエンドまたはボリュームから仮想マシンを起動する場合、イメージの形式は RAW にする必要があります。

RHOCP インストールプログラムは、公開されている QCOW2 形式イメージを自動的にダウンロードして使用します。clusterOSImage インストール変数を外部の RAW 形式のイメージの URL、またはOpenStack Image Service にすでに格納されている既存の事前デプロイされた RAW 形式のイメージの名前に設定することで、これを変更できます。

clusterOSImage 変数は、ガイド付きインストールからは利用できません。これを install-config.yaml ファイルに手動で追加する必要があります。

オーバークラウドのデプロイ後に環境を準備するために、以下の操作を実施しました。

$ openstack network create public --external --provider-network-type flat --provider-physical-network datacentre
$ openstack subnet create --dhcp --gateway 192.168.122.1 --network public --subnet-range 192.168.122.0/24 --allocation-pool start=192.168.122.151,end=192.168.122.200 public

$ openstack flavor create --ram 16384 --disk 25 --vcpu 4 --public m1.large

$ openstack project create shiftstack
$ openstack user create --password 'redhat' shiftstack_user

$ openstack role add --user shiftstack_user --project shiftstack _member_

$ openstack role add --user shiftstack_user --project shiftstack Member

$ openstack quota set --cores 28 --ram 120000 shiftstack

RHOCP で実行しているアプリケーションが使用する Ingress Floating IP は、インストールの一部として 192.168.122.167 に割り当てられ、DNS にエントリーがあります。

RHOCP Ingress アクセスを使用可能にするには、クラスターが作成されたら、「Floating IP アドレスを使用したアプリケーションアクセスの設定」のガイダンスに従って、Ingress フローティング IP を手動で入力 Ingress ポートに接続する必要があります。

以下のコマンドを実行して Ingress ポート ID を確認します。

$ openstack port list | grep ingress
| 28282230-f90e-4b63-a5c3-a6e2faddbd15 | ocpra-6blbm-ingress-port  | fa:16:3e:4e:b8:bc | ip_address='10.0.0.7', subnet_id='cb3dbf4a-8fb3-4b2e-bc2d-ad12606d849a'  | DOWN   |

以下のコマンドを実行して、ポートを IP アドレスに割り当てます。

$ openstack floating ip set --port 28282230-f90e-4b63-a5c3-a6e2faddbd15 192.168.122.167

RHOCP インストールプログラムには、RHOSP の非アフィニティールールまたはアベイラビリティーゾーンのサポートが含まれません。したがって、インストール後に各 master ノードを独自の Complete ノードに移行する必要があります。この参照アーキテクチャーはライブマイグレーションを使用して、Compute ノード 1 つにつき 1 つのマスターを確保します。詳細は、以下の参考資料を参照してください。

今後のリリースでは、RHOSP の非アフィニティールールおよびアベイラビリティーゾーンがサポートされる予定です。

この参照アーキテクチャーは、「クラスターのステータスの確認」で説明されている手順に従って、クラスターが正常に実行されていることを確認します。

DNS に関連付けられた URL を使用して RHOCP コンソールにアクセスできます。この参照アーキテクチャーでは、コンソールは https://console-openshift-console.apps.ocpra.example.com/ にデプロイされます。