Red Hat OpenStack Platform 上の OpenShift
Red Hat OpenStack Platform は、セキュアで信頼性の高いプライベート OpenStack クラウドの構築、導入、拡張を行うための統合基盤を提供します。
OSP は、コンピューティング、ストレージ、ネットワークリソースを管理する一連の制御サービスによって実装される IaaS (インフラサービス)クラウドです。この環境の管理には Web ベースのインターフェイスを使用します。このインターフェイスを使用すると、管理者とユーザは OpenStack リソースの制御、プロビジョニング、自動化を行うことができます。さらに、 OpenStack インフラは、広範なコマンドラインインターフェイスと API を通じて管理者とエンドユーザにフルオートメーション機能を提供します。
OpenStack プロジェクトは、短期間で開発されたコミュニティプロジェクトで、 6 カ月ごとに更新リリースを提供します。最初の Red Hat OpenStack Platform は、すべてのアップストリームリリースに加えて新しいリリースを公開することで、このリリースサイクルのペースを維持していました。また、 3 回目のリリースごとに長期的なサポートを提供します。最近、 OpenStack Train をベースとした OSP リリース 16.0 ではリリース番号に対応しないことが選択されましたが、新しい機能はサブリリースにバックポートされています。最新のリリースは Red Hat OpenStack Platform 16.1 です。これには、アップストリームの Usuri および Victoria リリースからバックポートされた高度な機能が含まれています。
OSP の詳細については、を参照してください "Red Hat OpenStack Platform の Web サイト"。
OpenStack サービス
OpenStack Platform サービスはコンテナとして導入されます。コンテナはサービスを分離するため、アップグレードも簡単です。OpenStack Platform は、 Kolla によって構築、管理された一連のコンテナを使用します。サービスの導入は、 Red Hat Custom Portal からコンテナイメージを取得することによって行われます。これらのサービスコンテナは、 Podman コマンドを使用して管理され、 Red Hat OpenStack Director で導入、設定、および管理されます。
サービス | プロジェクト名 | 説明 |
---|---|---|
ダッシュボード |
地平線 |
OpenStack サービスの管理に使用する Web ブラウザベースのダッシュボード。 |
ID |
Keystone |
OpenStack サービスの認証と許可、およびユーザ、プロジェクト、ロールの管理を一元化するサービスです。 |
OpenStack ネットワーク |
中性子 |
OpenStack サービスのインターフェイス間の接続を提供します。 |
ブロックストレージ |
Cinder の場合 |
仮想マシン( VM )の永続的なブロックストレージボリュームを管理します。 |
コンピューティング |
ノバ |
コンピューティングノードで実行されている VM を管理およびプロビジョニングします。 |
イメージ( Image ) |
Glance |
VM イメージやボリューム Snapshot などのリソースを格納するためのレジストリサービス。 |
オブジェクトストレージ |
Swift |
ユーザにファイルおよび任意のデータの格納および取得を許可します。 |
テレメータ |
Ceilometer |
クラウドリソースの使用状況を測定できます。 |
オーケストレーション |
熱 |
リソーススタックの自動作成をサポートする、テンプレートベースのオーケストレーションエンジン。 |
ネットワーク設計
NetApp 解決策を使用した Red Hat OpenShift では、 2 つのデータスイッチを使用して 25Gbps でプライマリデータ接続を提供します。また、ストレージノードのインバンド管理用に 1Gbps で接続を提供する管理スイッチをさらに 2 台使用し、 IPMI 機能のアウトオブバンド管理も行います。
Red Hat OpenStack Director では、皮肉なベアメタルプロビジョニングサービスを使用して Red Hat OpenStack Platform を導入するために、 IPMI 機能が必要です。
VLAN の要件
ネットアップとともに Red Hat OpenShift を実装することで、仮想ローカルエリアネットワーク( VLAN )を使用してネットワークトラフィックを論理的に分離するように設計されています。この構成は、お客様のニーズに合わせて拡張することも、特定のネットワークサービスをさらに分離することもできます。次の表に、ネットアップで解決策を検証する際に解決策を実装するために必要な VLAN を示します。
VLAN | 目的 | VLAN ID |
---|---|---|
アウトオブバンド管理ネットワーク |
物理ノードの管理に使用するネットワークと、皮肉なことに IPMI サービス。 |
16 |
ストレージインフラ |
Swift などのインフラサービスをサポートするためにボリュームを直接マッピングするためのコントローラノードのネットワーク。 |
201 |
ストレージ Cinder |
環境に導入された仮想インスタンスにブロックボリュームを直接マッピングして接続するためのネットワーク。 |
202. |
内部 API |
API 通信、 RPC メッセージ、データベース通信を使用する OpenStack サービス間の通信に使用するネットワーク。 |
301 |
テナント |
Neutron は、 VXLAN を介したトンネリングによって、各テナントに独自のネットワークを提供します。ネットワークトラフィックは、各テナントネットワーク内で分離されます。各テナントネットワークには IP サブネットが関連付けられており、ネットワークネームスペースとは、複数のテナントネットワークで同じアドレス範囲を使用しても競合が発生することを意味します |
302 |
ストレージ管理 |
OpenStack Object Storage ( Swift )は、このネットワークを使用して、対象のレプリカノード間でデータオブジェクトを同期します。プロキシサービスは、ユーザ要求と基盤となるストレージレイヤの中間インターフェイスとして機能します。プロキシは受信要求を受信し、要求されたデータを取得するために必要なレプリカを検索します。 |
303 |
PXE |
OpenStack Director は、 OSP Overcloud のインストールをオーケストレーションするための、皮肉なベアメタルプロビジョニングサービスの一部として PXE ブートを提供します。 |
3484 |
外部 |
OpenStack Dashboard ( Horizon )をグラフィカルに管理するためにホストする、公開されているネットワーク。 OpenStack サービスを管理するためのパブリック API 呼び出しが可能です。 |
3485 |
インバンド管理ネットワーク |
SSH アクセス、 DNS トラフィック、ネットワークタイムプロトコル( NTP )トラフィックなど、システム管理機能へのアクセスを提供します。このネットワークは、コントローラ以外のノードのゲートウェイとしても機能します。 |
3486 |
ネットワークインフラストラクチャサポートリソース
OpenShift Container Platform を導入する前に、次のインフラを用意する必要があります。
-
ホスト名の完全な解決を可能にする DNS サーバが少なくとも 1 つ必要です。
-
解決策内のサーバの時刻を同期できる NTP サーバが 3 台以上ある。
-
(オプション) OpenShift 環境でのアウトバウンドのインターネット接続。
本番環境の導入に関するベストプラクティス
このセクションでは、この解決策を本番環境に導入する前に考慮する必要があるベストプラクティスをいくつか紹介します。
少なくとも 3 つのコンピューティングノードで構成された OSP プライベートクラウドに OpenShift を導入します。
このドキュメントで説明する検証済みのアーキテクチャでは、 3 つの OSP コントローラノードと 2 つの OSP コンピューティングノードを導入して、 HA 運用に適した最小限のハードウェアを導入します。このアーキテクチャにより、耐障害性を備えた構成が実現し、両方のコンピューティングノードで仮想インスタンスを起動し、導入した VM を 2 つのハイパーバイザー間で移行できます。
Red Hat OpenShift 原因では最初に 3 つのマスターノードを導入するため、 2 ノード構成では少なくとも 2 つのマスターが同じノードを占有する可能性があり、その特定のノードが使用できなくなった場合には OpenShift が停止する可能性があります。そのため、 Red Hat では、少なくとも 3 つの OSP コンピューティングノードを導入して、 OpenShift マスターを均等に分散させ、解決策にフォールトトレランスを強化することをベストプラクティスとして推奨します。
仮想マシンとホストのアフィニティを設定します
仮想マシンとホストのアフィニティを有効にすると、複数のハイパーバイザーノードに OpenShift マスターを分散できます。
アフィニティとは、 VM やホストのセットに対してルールを定義する方法で、グループ内の同じホストで複数の VM が実行されるか、別々のホストで実行されるかを決定します。VM とホストで構成されるアフィニティグループを作成することで、 VM に適用されます。このアフィニティグループには同じパラメータと条件が設定されます。アフィニティグループ内の VM がグループ内の同じホストで実行されているのか、または別々のホストで実行されているのかに応じて、アフィニティグループのパラメータでは正のアフィニティまたは負のアフィニティを定義できます。Red Hat OpenStack Platform では、サーバグループを作成し、 Nova で導入されたインスタンスが異なるコンピューティングノードに導入されるようにフィルタを設定することで、ホストアフィニティルールと非アフィニティルールを作成して適用することができます。
サーバグループには、配置を管理できる最大 10 個の仮想インスタンスがデフォルトで存在します。Nova のデフォルトクォータを更新することで変更できます。
OSP サーバグループには、特定のハードアフィニティや非アフィニティの制限があります。ノードを共有するために十分なリソースが別々のノードに導入できない場合や、リソースが不足している場合は、 VM をブートできません。 |
アフィニティグループを設定するには、を参照してください "OpenStack インスタンス用にアフィニティおよび非アフィニティを設定するにはどうすればよいですか?"。
OpenShift 環境にカスタムインストールファイルを使用します
IPI を使用すると、このドキュメントで前述した対話型ウィザードを使用して、 OpenShift クラスタを簡単に導入できます。ただし、クラスタ導入の一環として、一部のデフォルト値の変更が必要になる場合があります。
このような場合は、クラスタをすぐに導入せずにウィザードを実行してタスクを実行できます。代わりに、あとでクラスタを導入できる構成ファイルを作成します。これは、 IPI のデフォルト値を変更する必要がある場合や、マルチテナンシーなどの他の用途のために環境内に同一のクラスタを複数導入する必要がある場合に非常に便利です。OpenShift 用にカスタマイズされたインストール構成の作成の詳細については、を参照してください "Red Hat OpenShift カスタマイズを使用した OpenStack へのクラスタのインストール"。