Red Hat OpenStack プラットフォーム上の OpenShift
変更を提案
PDF
Red Hat OpenStack Platform は、安全で信頼性の高いプライベート OpenStack クラウドを作成、展開、拡張するための統合基盤を提供します。
OSP は、コンピューティング、ストレージ、およびネットワーク リソースを管理する制御サービスのコレクションによって実装される、サービスとしてのインフラストラクチャ (IaaS) クラウドです。環境は、管理者とユーザーが OpenStack リソースを制御、プロビジョニング、自動化できる Web ベースのインターフェースを使用して管理されます。さらに、OpenStack インフラストラクチャは、広範なコマンド ライン インターフェイスと API を通じて実現され、管理者とエンド ユーザー向けの完全な自動化機能を実現します。
OpenStack プロジェクトは、6 か月ごとに更新リリースを提供する、急速に開発が進むコミュニティ プロジェクトです。当初、Red Hat OpenStack Platform は、アップストリーム リリースごとに新しいリリースを公開し、3 回目のリリースごとに長期サポートを提供することで、このリリース サイクルに対応していました。最近、OSP 16.0 リリース (OpenStack Train ベース) では、Red Hat はリリース番号に追従せず、代わりに新しい機能をサブリリースにバックポートすることを選択しました。最新リリースは Red Hat OpenStack Platform 16.1 で、アップストリームの Ussuri および Victoria リリースからバックポートされた高度な機能が含まれています。
OSPの詳細については、"Red Hat OpenStack Platform ウェブサイト" 。
OpenStackサービス
OpenStack Platform サービスはコンテナとしてデプロイされ、サービスが相互に分離され、簡単にアップグレードできるようになります。 OpenStack プラットフォームは、Kolla で構築および管理されるコンテナのセットを使用します。サービスのデプロイメントは、Red Hat カスタムポータルからコンテナイメージをプルすることによって実行されます。これらのサービス コンテナは Podman コマンドを使用して管理され、Red Hat OpenStack Director を使用してデプロイ、構成、および保守されます。
| サービス | プロジェクト名 | 説明 |
|---|---|---|
ダッシュボード |
地平線 |
OpenStack サービスを管理するために使用する Web ブラウザベースのダッシュボード。 |
身元 |
Keystone |
OpenStack サービスの認証と承認、およびユーザー、プロジェクト、ロールの管理のための集中型サービス。 |
OpenStackネットワーク |
中性子 |
OpenStack サービスのインターフェース間の接続を提供します。 |
ブロックストレージ |
Cinder |
仮想マシン (VM) の永続ブロック ストレージ ボリュームを管理します。 |
コンピューティング |
ノヴァ |
コンピューティング ノードで実行されている VM を管理およびプロビジョニングします。 |
イメージ |
一目 |
VM イメージやボリューム スナップショットなどのリソースを保存するために使用されるレジストリ サービス。 |
オブジェクト ストレージ |
迅速 |
ユーザーがファイルや任意のデータを保存および取得できるようにします。 |
テレメトリー |
天井計 |
クラウド リソースの使用量の測定を提供します。 |
オーケストレーション |
熱 |
リソース スタックの自動作成をサポートするテンプレート ベースのオーケストレーション エンジン。 |
ネットワーク設計
Red Hat OpenShift with NetAppソリューションは、2 つのデータ スイッチを使用して 25 Gbps でプライマリ データ接続を提供します。また、ストレージ ノードのインバンド管理と IPMI 機能のアウトオブバンド管理のために 1 Gbps の接続を提供する 2 つの追加管理スイッチも使用します。
Ironic ベアメタル プロビジョニング サービスを使用して Red Hat OpenStack Platform をデプロイするには、Red Hat OpenStack Director に IPMI 機能が必要です。
VLANの要件
NetAppを搭載した Red Hat OpenShift は、仮想ローカル エリア ネットワーク (VLAN) を使用して、さまざまな目的に合わせてネットワーク トラフィックを論理的に分離するように設計されています。この構成は、顧客の要求を満たすために、または特定のネットワーク サービスをさらに分離するために拡張できます。次の表は、 NetAppでソリューションを検証する際にソリューションを実装するために必要な VLAN を示しています。
| VLAN | 目的 | VLAN ID |
|---|---|---|
帯域外管理ネットワーク |
Ironic の物理ノードと IPMI サービスの管理に使用されるネットワーク。 |
16 |
ストレージインフラストラクチャ |
コントローラー ノードがボリュームを直接マップして Swift などのインフラストラクチャ サービスをサポートするために使用されるネットワーク。 |
201 |
貯蔵用灰 |
環境にデプロイされた仮想インスタンスにブロック ボリュームを直接マップおよび接続するために使用されるネットワーク。 |
202 |
内部API |
API 通信、RPC メッセージ、およびデータベース通信を使用した OpenStack サービス間の通信に使用されるネットワーク。 |
301 |
テナント |
Neutron は、VXLAN を介したトンネリングを通じて各テナントに独自のネットワークを提供します。ネットワーク トラフィックは各テナント ネットワーク内で分離されます。各テナント ネットワークには IP サブネットが関連付けられており、ネットワーク名前空間により、複数のテナント ネットワークが競合を起こすことなく同じアドレス範囲を使用できます。 |
302 |
ストレージ管理 |
OpenStack Object Storage (Swift) は、このネットワークを使用して、参加しているレプリカ ノード間でデータ オブジェクトを同期します。プロキシ サービスは、ユーザー要求と基盤となるストレージ層間の中間インターフェイスとして機能します。プロキシは着信要求を受け取り、要求されたデータを取得するために必要なレプリカを見つけます。 |
303 |
PXE |
OpenStack Director は、OSP オーバークラウドのインストールを調整するために、Ironic ベアメタル プロビジョニング サービスの一部として PXE ブートを提供します。 |
3484 |
外部 |
グラフィカル管理用の OpenStack ダッシュボード (Horizon) をホストし、OpenStack サービスを管理するためのパブリック API 呼び出しを許可する、パブリックに利用可能なネットワーク。 |
3485 |
インバンド管理ネットワーク |
SSH アクセス、DNS トラフィック、ネットワーク タイム プロトコル (NTP) トラフィックなどのシステム管理機能へのアクセスを提供します。このネットワークは、コントローラー以外のノードのゲートウェイとしても機能します。 |
3486 |
ネットワークインフラストラクチャサポートリソース
OpenShift Container Platform をデプロイする前に、次のインフラストラクチャを準備しておく必要があります。
-
完全なホスト名解決を提供する少なくとも 1 つの DNS サーバー。
-
ソリューション内のサーバーの時間を同期できる NTP サーバーが少なくとも 3 台。
-
(オプション) OpenShift 環境の送信インターネット接続。
本番環境への導入に関するベストプラクティス
このセクションでは、このソリューションを本番環境に導入する前に組織が考慮する必要があるベスト プラクティスをいくつか示します。
少なくとも3つのコンピューティングノードを持つOSPプライベートクラウドにOpenShiftをデプロイする
このドキュメントで説明する検証済みのアーキテクチャは、3 つの OSP コントローラ ノードと 2 つの OSP コンピューティング ノードを展開することにより、HA 操作に適した最小限のハードウェア展開を示します。このアーキテクチャにより、両方のコンピューティング ノードが仮想インスタンスを起動でき、展開された VM が 2 つのハイパーバイザー間で移行できるフォールト トレラント構成が保証されます。
Red Hat OpenShift は最初に 3 つのマスターノードでデプロイされるため、2 ノード構成では少なくとも 2 つのマスターが同じノードを占有することになり、その特定のノードが使用できなくなった場合に OpenShift が停止する可能性があります。したがって、OpenShift マスターを均等に分散し、ソリューションのフォールト トレランスをさらに高めることができるように、少なくとも 3 つの OSP コンピューティング ノードをデプロイすることが Red Hat のベスト プラクティスです。
仮想マシン/ホストアフィニティを構成する
VM/ホスト アフィニティを有効にすると、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 へのクラスターのインストール" 。