デプロイメントのプランニング
RHOCS 4.4 をデプロイする際の重要な考慮事項
概要
第1章 Red Hat OpenShift Container Storage の概要
Red Hat OpenShift Container Storage は、コンテナー環境向けに最適化されたソフトウェアで定義されるストレージです。これは Red Hat OpenShift Container Platform の Operator として実行され、コンテナーの統合され、単純化された永続ストレージの管理を可能にします。
Red Hat OpenShift Container Storage は、以下を含む各種のストレージタイプをサポートします。
- データベースのブロックストレージ
- 継続的な統合、メッセージングおよびデータ集約のための共有ファイルストレージ
- アーカイブ、バックアップおよびメディアストレージのオブジェクトストレージ
Red Hat OpenShift Container Storage バージョン 4.2 以降では以下を使用します。
- Red Hat Ceph Storage: 永続ボリュームをサポートするファイル、ブロック、オブジェクトストレージを提供します。
- Rook.io: 永続ボリュームおよび要求のプロビジョニングを管理し、オーケストレーションします。
- NooBaa: オブジェクトストレージを提供し、その Multicloud Object Gateway は複数のクラウド環境でデータのフェデレーションを有効にします。NooBaa のエンタープライズバージョンには、Red Hat Multicloud Object Gateway という名前が付けられています。
第2章 OpenShift Container Storage のアーキテクチャー
Red Hat OpenShift Container Storage は、OpenShift Container Platform をベースとして使用します。OpenShift Container Platform のアーキテクチャーおよびライフサイクルについての詳細は、『OpenShift Container Platform アーキテクチャー』を参照してください。
Red Hat OpenShift Container Storage アーキテクチャー
Red Hat OpenShift Container Storage は主に 3 つの Operator で構成されており、管理タスクとカスタムリソースをコード化し、タスクおよびリソースの特性をより簡単に自動化できるようにします。管理者はクラスターの必要な最終状態を定義し、各種 Operator は管理者の介入を最小限に抑えてクラスターをその状態にするか、またはその状態に近づけるように機能します。
- OpenShift Container Storage (OCS) Operator
- 他の Operator を特定のテストされた方法で利用してサポートされている Red Hat OpenShift Container Storage デプロイメントの推奨事項および要件を定め、実施するメタ Operator。この Operator は、Rook-Ceph および NooBaa Operator によって提供されるリソースをラップするストレージクラスターリソースを提供します。
- Rook-Ceph Operator
- この Operator は、永続ストレージのパッケージ化、デプロイメント、管理、アップグレードおよびスケーリングを自動化し、このように自動化される永続ストレージはコンテナーアプリケーション、および OpenShift Container Platform によって使用されるインフラストラクチャーサービスに提供されます。これは、Object Storage Daemon、モニター、Ceph ファイルシステムのメタデータサーバーなどのサービスをホストする Pod を管理する Ceph クラスターリソースを提供します。
- NooBaa Operator
- この Opearator は、複数のクラウド環境でのリソースアクセスを可能にする S3 と互換性のあるオブジェクトストアサービスである Multicloud Object Gateway を提供します。
2.1. サポートされるワークロードのタイプ
Red Hat OpenShift Container Storage は、数多くのワークロードタイプに適したストレージを提供します。
ブロックストレージ は、データベースや他の低レイテンシーのトランザクションワークロードに適しています。サポートされるワークロードの例には、Red Hat OpenShift Container Platform のロギングおよびモニタリング、および PostgreSQL などがあります。
オブジェクトストレージ は、ビデオおよび音声ファイル、圧縮データアーカイブ、および人工知能または機械学習プログラムに使用されるデータに適しています。さらに、オブジェクトストレージは、クラウドファーストアプローチで開発したすべてのアプリケーションに使用できます。
ファイルストレージ は、継続的な統合および配信、Web アプリケーションファイルストレージ、および人工知能または機械学習データの集約に適しています。サポートされるワークロードには、Red Hat OpenShift Container Platform レジストリーおよび JBoss AMQ を使用したメッセージングが含まれます。
第3章 サポートされるインフラストラクチャーおよびプラットフォーム
Red Hat OpenShift Container Storage は、インストーラーでプロビジョニングされるインフラストラクチャー (フルスタック自動化)、およびユーザーによってプロビジョニングされるインフラストラクチャー (既存インフラストラクチャー) でデプロイされる Red Hat OpenShift Container Platform へのデプロイメントをサポートします。
インストーラーでプロビジョニングされるインフラストラクチャー (IPI)
フルスタック自動化の場合、インストーラーが Red Hat OpenShift Container Platform の使用しやすい事前に設定されたデプロイにより、インフラストラクチャーのプロビジョニングを含むインストールのすべての領域を制御します。
ユーザーによってプロビジョニングされるインフラストラクチャー (UPI)
既存インフラストラクチャーのデプロイメントでは、管理者が独自のインフラストラクチャーを作成し、管理します。この場合、より多くのカスタマイズやより柔軟な運用が可能になります。
Red Hat OpenShift Container Storage は、以下のインフラストラクチャーでのデプロイメントをサポートします。
表3.1 最小インフラストラクチャー要件
| インフラストラクチャー | デプロイメントタイプ | 要件 |
|---|---|---|
| Amazon Web Services | IPI、UPI |
|
| VMware | UPI | VMware vSphere 6.7 Update 2 以降 (vSAN または VMFS データストアを含む) 詳細は、「VMware vSphere インフラストラクチャーの要件」を参照してください。 |
| ベアメタル | UPI | ストレージタイプは SSD (NVMe/SATA/SAS) である必要があります。 |
3.1. ノードの要件
このセクションで説明されている要件は、既存の Red Hat OpenShift Container Platform デプロイメントのみに適用され、Red Hat OpenShift Container Storage によってのみ使用されるために必要です。
デプロイメントには、少なくとも 3 つのスターターノードが必要です。スターターノードの最小要件は、サービスの基本セットとノードごとに単一のストレージデバイスをサポートします。追加のストレージデバイスは後で追加でき、Kubernetes はリソースの可用性に基づいて OCS Pod をスケジュールします。ストレージノードでその他のワークロードを実行する予定の場合には、追加のリソース (CPU/メモリー/領域) を追加する必要があります。
表3.2 スターターノードの最小要件
| コンポーネント | 要件 |
|---|---|
| CPU | 10* |
| メモリー | 40 GB* |
| ディスク |
|
| MON | すべてのストレージノードで MON あたり 10 GiB のストレージ。
注: 1 度に 3 つのノードのみがストレージ領域を必要とします。 |
*AWS EC2 の場合、最も近いインスタンスサイズは 16 CPU および 64 GB メモリー(M5.4xlarge)を提供します。M5.4xlarge インスタンスタイプがスターターノードに使用されると、それぞれ最大 4 つのストレージデバイスをサポートします。i3en.2xlarge インスタンスタイプ（8 CPU、64GB メモリー）の使用は現在 テクノロジープレビュー 機能としてご利用いただけます。
表3.3 ストレージデバイスの追加要件
| コンポーネント | 要件 |
|---|---|
| CPU | 2 |
| メモリー | 8 GB |
| 注記： ストレージデバイスは 3 セットでプロビジョニングする必要があります。 | |
CPU ユニット
本セクションでは、1 CPU ユニットは Kubernetes コンセプトの 1 CPU ユニットにマップされます。詳細は、「CPU units」を参照してください。
- CPU の 1 ユニットは、ハイパースレッディングされていない CPU の 1 コアに相当します。
- CPU の 2 ユニットは、ハイパースレッディングされている CPU の 1 コアに相当します。
OpenShift Container Storage コアベースのサブスクリプションは常にペア (2 コア) で提供されます。
例： 3 ノードクラスターの場合、最小の 3 x 10 = 30 ユニットの CPU が必要です。CPU の 30 ユニットは 15 コアに相当し、これは Red Hat OpenShift Container Storage（2 コア）の ~8 サブスクリプションに相当します。
3.2. プラットフォーム要件
Red Hat OpenShift Container Storage は、最新の Red Hat OpenShift Container Platform バージョンとのみ互換性があります。
Red Hat OpenShift Container Storage 4.4 では、デプロイメントの柔軟性を確保するために OCP 4.4 を使用することを推奨します。
Red Hat OpenShift Container Platform のアップグレード時に、ローカルストレージ Operator が Red Hat OpenShift Container Storage Storage と完全にサポートされるように、ローカルストレージ Operator のバージョンをアップグレードして Red Hat OpenShift Container Platform バージョンと一致させる必要があります。
詳細は、「Red Hat OpenShift Container Storage and Red Hat OpenShift Container Platform interoperability matrix」を参照してください。
Red Hat OpenShift Container Platform は、連邦情報処理標準 (FIPS) モードを有効にしてインストールしたり、実行したりすることはできません。
ストレージワークロードのみを実行するノードには、Red Hat OpenShift Container Storage のサブスクリプションが必要です。ストレージワークロードに加えて他のワークロードを実行するノードには、Red Hat OpenShift Container Storage および Red Hat OpenShift Container Platform サブスクリプションの両方が必要です。
第4章 サポートされる設定
Red Hat OpenShift Container Storage は、3 つのワーカーノードからなる最小クラスターとしてデプロイされます。ノードを 3 つの異なるアベイラビリティーゾーンに分散して、可用性を確保します。
4.1. 動的に作成されたストレージの使用
Red Hat OpenShift Container Storage では、ストレージが動的に作成される場合に 0.5 TiB、2 TiB、および 4 TiB の容量を持つ異なるストレージディスクサイズをサポートします。
4.1.1. ストレージクラスの要件
Red Hat OpenShift Container Storage では Red Hat OpenShift Container Platform のデフォルトストレージクラスを使用し、インフラストラクチャープロバイダーに応じて特定のデフォルトストレージクラスを想定します。
これらのクラスは Red Hat OpenShift Container Platform ノードで自動的に設定されますが、Red Hat OpenShift Container Platform ノードがデフォルトとして異なるストレージクラスを使用する場合には、デフォルトのストレージクラスをインフラストラクチャープロバイダーの適切なストレージクラスに戻す必要があります。
-
Amazon Web Services では、デフォルトのストレージクラスは
gp2である必要があります。 -
VMware vSphere では、デフォルトのストレージクラスは
thinである必要があります。
4.1.2. 動的ストレージのサイジングとスケーリング
3 つのノードの初期クラスターは、各ノードの最大 9 分の推奨で後で拡張できます。4 つ以上のワーカーノードがある場合、ディスクの分散方法は OpenShift のスケジュールと利用可能なリソースによって異なります。
3 ノードのセットでクラスターを拡張し、ストレージが複製され、少なくとも 3 つのアベイラビリティーゾーンを使用できることを確認します。
ストレージ容量は、インストール時に選択した容量の増分値でのみ拡張できます。
以下の表は、Red Hat OpenShift Container Storage のサポートされる設定を示しています。
表4.1 3 つのノードにおける初期設定
| ディスク | ノードごとのディスク | 合計容量 | 利用可能なストレージ容量 |
|---|---|---|---|
| 0.5 TiB | 1 | 1.5 TiB | 0.5 TiB |
| 2 TiB | 1 | 6 TiB | 2 TiB |
| 4 TiB | 1 | 12 TiB | 4 TiB |
表4.2 9 ノード(N)で拡張された設定の例
| ディスクサイズ(D) | ノードごとのディスク(M) | 合計容量 (D * M * N) | 使用可能なストレージ容量 (D*M*N/3) |
|---|---|---|---|
| 0.5 TiB | 3 | 13.5 TiB | 4.5 TiB |
| 2 TiB | 6 | 108 TiB | 36 TiB |
| 4 TiB | 9 | 324 TiB | 108 TiB |
常にストレージ容量が十分にあることを確認してください。
ストレージが完全に一杯になると、容量を追加したり、ストレージからコンテンツを削除したり、コンテンツを移動して領域を解放することはできません。一杯になったストレージを回復することは容易ではありません。
容量アラートは、クラスターストレージ容量が合計容量の 75％ (ほぼ一杯) および 85％ (一杯) になると発行されます。容量についての警告に常に迅速に対応し、ストレージを定期的に確認して、ストレージ領域が不足しないようにします。
ストレージ領域が不足する場合は、Red Hat カスタマーポータルにお問い合わせください。
Red Hat OpenShift Container Storage 4.4 の時点で、インストールは既存の Red Hat OpenShift Container Platform ノードでのみサポートされています。詳細は、『OpenShift Container Storage のデプロイ』を参照してください。
4.2. ローカルストレージデバイスの使用
ローカルデバイスを使用するには、Operator Hub を使用してローカルストレージ Operator をインストールする必要があります。ローカルストレージデバイスを使用した OpenShift Container Storage のインストールについて参照してください。
4.2.1. ローカルデバイス用のストレージのサイジングとスケーリング
ローカルストレージのデプロイメントの場合、4 TiB 以下のディスクサイズを使用でき、すべてのディスクが同じサイズおよび種類である必要があります。
3 つのノードの初期クラスターは、各ノードの最大 9 分の推奨で後で拡張できます。4 つ以上のワーカーノードがある場合、ディスクの分散方法は OpenShift のスケジュールと利用可能なリソースによって異なります。
常にストレージ容量が十分にあることを確認してください。
ストレージが完全に一杯になると、容量を追加したり、ストレージからコンテンツを削除したり、コンテンツを移動して領域を解放することはできません。一杯になったストレージを回復することは容易ではありません。
容量アラートは、クラスターストレージ容量が合計容量の 75％ (ほぼ一杯) および 85％ (一杯) になると発行されます。容量についての警告に常に迅速に対応し、ストレージを定期的に確認して、ストレージ領域が不足しないようにします。
ストレージ領域が不足する場合は、Red Hat カスタマーポータルにお問い合わせください。
第5章 次のステップ
『OpenShift Container Storage のデプロイ』を参照して、コンテナーストレージソリューションのデプロイを開始します。
