システム要件

Bob のオンプレミスインストール前に、サポートされているプラットフォーム、アーキテクチャ、コンピュート、ストレージ、およびネットワーク要件をお客様の環境が満たしていることを確認してください。

このセクションの要件は、OpenShift 環境の計画とサイジングに役立ちます。

サポートされているバージョン

以下の表は、この Bob オンプレミスリリースでサポートされている検証済みコンポーネントバージョンを示しています。互換性を維持し、完全な製品サポートを受けるために、Bob IDE、Bob Shell、Premium Package、および OpenShift Container Platform (OCP) のサポートされているバージョンを使用してください。

Bob オンプレミスバージョンBob IDE バージョンBob Shell バージョンPremium Package バージョン
2.0.02.2.02.0.5IBM Bob Premium Package for Z 3.1.0

クラスターアーキテクチャ

Bob オンプレミスバックエンドには amd64 (x86_64) OCP クラスターが必要です。Bob ワークロードをスケジュールするすべてのワーカーノードは、amd64 ハードウェア上で動作する必要があります。

アーキテクチャバックエンドクラスターのサポート
amd64 (x86_64)サポート対象
注意:

ノードセレクターまたはテイントを使用して Bob ワークロードを amd64 ノードに制限することで、混合アーキテクチャクラスターがサポートされます。Bob はこれらのスケジューリング制約を自動的に適用しません。

サポートされている OCP バージョン

以下の表はサポートされている OCP バージョンを示しています。

OCP バージョンステータス
4.20サポート対象
4.21サポート対象
4.22サポート対象

デプロイメントフットプリントとサイジング

Bob オンプレミスは、お客様管理の OpenShift Container Platform (OCP) クラスター上のテナントワークロードとしてデプロイされます。リソース要件はデプロイする Bob コンポーネントによって異なり、すべてのインストールで固定されているわけではありません。

すべてのデプロイメントには、基盤となるプラットフォームサービスを提供する Bob Core が含まれます。Z Context ツール、Z Proxy、Z Understand などのオプションコンポーネントには追加のコンピュート、メモリ、ストレージリソースが必要であり、クラスターのサイジング時に考慮する必要があります。

アドオンはインストール時にクラスター管理者が有効にします。アドオンを有効にすると、クラスターリソース要件が増加するだけでなく、対応するプレミアムパッケージエンタイトルメントをユーザーに割り当てられるかどうかも決まります。詳細については、エンタイトルメントの管理を参照してください。

このセクションのサイジング値は、Bob ワークロードに必要な集計リソースを表しています。これらはテナントのフットプリントの見積もりに役立てるために提供されており、クラスター全体のアーキテクチャを定義することを目的としていません。高可用性、他のテナントワークロード、予想される成長、プラットフォームサービスオーバーヘッドなど、運用要件に基づいて基盤となるクラスターをサイジングする必要があります。

重要:

これらの値は、指定されたレプリカ数ですべての Bob コンポーネントにわたって設定されたポッドリソースリクエストの合計を表しています。これは Kubernetes スケジューラーがクラスターノードに予約する CPU とメモリの量です。

これらの値は容量計画とサイジングのみを目的としています。観測されたランタイムリソース使用量を表すものではなく、負荷下での保証されたリソース消費として解釈するべきではありません。

コントロールプレーンノード数、インフラストラクチャノード数、ワーカーノード数、高可用性要件、成長計画などのクラスターサイジングの決定はお客様の責任です。

注意:

モデルサービング (推論) は含まれていません。このセクションのリソース見積もりには、AI モデルのホストおよび提供に必要な GPU ノード、モデルサービングインフラ、またはその他のリソースは含まれていません。Red Hat OpenShift AI または別のモデルサービングプラットフォームを使用してモデル推論を実行する場合は、Bob デプロイメントとは独立してそれらの環境を計画・サイジングしてください。

サポートされているスタック構成

クラスターをサイジングする際は、計画しているデプロイメントに最も近い構成を確認してください。

スタック構成CPU (raw)メモリ (raw)ストレージ (PV)
Bob Core10.8 vCPU10.8 GiB~24 GiB
Bob Core + Z Context ツール27.8 vCPU45.8 GiB~55 GiB
Bob Core + Z Understand18.8 vCPU49.8 GiB~24 GiB
Bob Core + Z Context ツール + Z Understand35.8 vCPU84.8 GiB~55 GiB

Bob Core はサポートされる最小デプロイメント構成を表しています。リソース値は Bob テナント要件の集計を表し、プラットフォームインフラストラクチャのオーバーヘッドを除外しています。

Bob リソースフットプリント

以下の参照フットプリントは、オプションのアドオンが有効になっていない Bob Core デプロイメントに適用されます。

ワーカーノードをサイジングする際は、+25% スケジューリングヘッドルーム 行の値を使用してください。これらの値は、設定されたポッドリソースリクエストを超えた追加の容量を提供し、Kubernetes スケジューリング要件とノードレベルのオーバーヘッドに対応します。

デプロイメントプロファイルCPUメモリストレージ (PV)
本番 (要求リソース)10.8 vCPU10.8 GiB~24 GiB
本番 (25% スケジューリングヘッドルーム含む)~13.5 vCPU~13.5 GiB~24 GiB

ストレージ消費はワークロード量、保持データ、および有効なサービスによって異なります。表示されている値は Bob Core デプロイメントのベースラインフットプリントを表しています。

OpenShift クラスタートポロジー

以下の表は、Bob Core デプロイメントを実行する 9 ノード OpenShift クラスターの最小本番対応参照構成を示しています。追加の Bob コンポーネントをデプロイする場合は、追加のワーカーノード容量をプロビジョニングする必要があります。

最小参照構成

ノードロール数CPU/ノードメモリ/ノード集計容量
コントロールプレーン34 vCPU (最小)16 GiB (最小)12 vCPU / 48 GiB
インフラストラクチャノード3~4 vCPU~16 GiB12 vCPU / 48 GiB
ワーカーノード38 vCPU16 GiB24 vCPU / 48 GiB / 600 GiB ストレージ
クラスター合計9--~48 vCPU / ~144 GiB / 600 GiB ストレージ

OpenShift クラスターオーバーヘッドとシステム予約リソースを差し引いた後、3 ワーカーノード構成は Bob Core 本番デプロイメントをサポートするのに十分な割り当て可能 CPU とメモリ容量を提供します。

参考として、OpenShift コントロールプレーンサイジングガイドライン、コントロールプレーンノードのサイジング (HA およびアップグレードヘッドルームのため利用率を 60% 以下に維持)、および推奨ホストプラクティス、スケーラビリティとパフォーマンス (インフラノード 3 台推奨) を参照してください。

ストレージ要件

Bob はデータベース、検索サービス、キャッシュコンポーネント、設定、証明書、およびバックアップデータのために永続ストレージに依存します。適切なストレージクラスを選択することはパフォーマンスと信頼性にとって重要です。

参照構成では、ワーカーノードあたり 200 GiB のストレージを割り当て、ワーカープール全体で合計 600 GiB となります。これは Bob 永続ボリューム要件 (~50 GiB)、イメージレジストリ、モニタリング、ロギングなどの OpenShift 内部サービス、および将来のワークロード成長の余地に対応しています。

サポートされているストレージクラス

ストレージクラスタイプサポートされるアクセスモード
マネージド NFSネットワークファイルシステム (NFS) プロビジョナーRWO, RWX
OpenShift Data Foundation (ODF)Ceph バックストレージ (RBD および CephFS)RWO, RWX

ストレージアクセスモード要件

Bob の各コンポーネントは異なるストレージアクセスモードを必要とします。

コンポーネント必要なアクセスモード注意事項
PostgreSQLRWO (ReadWriteOnce)ブロックストレージが必要です。SSD バックストレージを強く推奨します。
OpenSearchRWO (ReadWriteOnce)高パフォーマンスのブロックストレージを推奨します。
RedisRWO (ReadWriteOnce)永続データには専用の読み書きアクセスが必要です。
共有設定および証明書RWX (ReadWriteMany)複数の pod が同じボリュームを同時にマウントする必要がある場合に必要です。
警告:

ストレージのパフォーマンスは Bob オンプレミスの応答性と安定性に大きな影響を与えます。

特に PostgreSQL ワークロードにおけるストレージスループットまたは I/O パフォーマンスの不足は、応答時間の増加、インデックス操作の遅延、およびシステム全体のパフォーマンス低下を引き起こす可能性があります。データベースワークロード用のストレージを選択する際は以下に注意してください。

  • 可能な限り SSD バックのブロックストレージを使用してください。
  • 高レイテンシーまたは IOPS が制限されたストレージプラットフォームは避けてください。
  • 予想されるワークロード成長に対して十分な容量を確保してください。
  • 本番ワークロードをデプロイする前にストレージのパフォーマンスを検証してください。

最適なパフォーマンスのために、PostgreSQL および OpenSearch データボリュームを環境内で最速の利用可能なブロックストレージにデプロイしてください。

バックアップストレージ

Bob はバックアップおよびリストア操作に別のストレージターゲットが必要です。バックアップストレージの場所は以下を格納するのに十分な容量を提供する必要があります。

  • アプリケーションバックアップ
  • データベースバックアップ
  • インデックススナップショット
  • 組織のポリシーで必要な保持コピー

バックアップストレージは以下のようなサポートされている外部ストレージシステムで提供できます。

  • ネットワークファイルシステム (NFS) 共有
  • エンタープライズバックアップリポジトリ
  • オブジェクトストレージサービス (バックアップソリューションでサポートされている場合)

ネットワーク要件

Bob コンポーネントは OpenShift クラスター内部で通信するとともに、モデルエンドポイント、コンテナレジストリ、LDAP プロバイダー、およびクライアントワークステーションと外部通信します。インストール前に、必要なネットワーク接続性と DNS 設定が利用可能であることを確認してください。

最低限、以下を確認してください。

  • OpenShift ノードが相互に通信できること。
  • ワークステーションが OpenShift API にアクセスできること。
  • Bob が設定済みの LLM エンドポイントに到達できること。
  • Bob が LDAP または Active Directory サーバーに到達できること (使用する場合)。
  • クライアントワークステーションが Bob ingress エンドポイントにアクセスできること。
  • Bob アプリケーションエンドポイントに DNS レコードが設定されていること。
  • クライアントワークステーションから TLS 証明書を検証できること。
このトピックはいかがですか?