システム要件
Bob のオンプレミスインストール前に、サポートされているプラットフォーム、アーキテクチャ、コンピュート、ストレージ、およびネットワーク要件をお客様の環境が満たしていることを確認してください。
Z Understand アドオン構成の暫定サイジング値が公開されました。これらの値は進行中のベンチマークテストに基づいており、テストの完了に伴い更新される可能性があります。
このセクションの要件は、OpenShift 環境の計画とサイジングに役立ちます。
サポートされているバージョン
以下の表は Bob オンプレミスバージョンと互換性のあるクライアントコンポーネントバージョンを示しています。
| Bob オンプレミスバージョン | Bob IDE バージョン | Bob Shell バージョン |
|---|---|---|
| 2.0.0 | 2.2.0 | 2.0.5 |
プレミアムパッケージアドオンのバージョン互換性については、エンタイトルメントの管理を参照してください。
クラスターアーキテクチャ
OpenShift Container Platform (OCP) 上での Bob のオンプレミスインストールは、現在以下のクラスターアーキテクチャをサポートしています。
amd64(x86_64)
ノードセレクターまたはテイントを使用して Bob ワークロードを amd64 ノードに制限することで、混合アーキテクチャクラスターがサポートされます。Bob はこれらのスケジューリング制約を自動的に適用しません。
サポートされている OCP バージョン
以下の表はサポートされている OCP バージョンを示しています。
| OCP バージョン | ステータス | 注意事項 |
|---|---|---|
| 4.20 | テスト済みおよびサポート対象 | サポートされる最低バージョン |
| 4.21 | テスト済みおよびサポート対象 | |
| 4.22 | テスト済みおよびサポート対象 |
クラスターサイジング
Bob はお客様管理の OpenShift クラスター上のテナントワークロードとして実行されます。リソース要件はデプロイされた Bob スタックによって異なります。すべてのインストールに Bob コアコンポーネントが含まれ、オプションの Premium Package アドオンを有効にすると、必要な CPU、メモリ、ストレージ容量が増加します。
アドオンはインストール時にクラスター管理者が有効にします。アドオンを有効にすると、クラスターリソース要件が増加するだけでなく、対応するプレミアムパッケージエンタイトルメントをユーザーに割り当てられるかどうかも決まります。詳細については、エンタイトルメントの管理を参照してください。
このセクションのサイジング値は、Bob ワークロードに必要な集計リソースを表しています。これらはテナントのフットプリントの見積もりに役立てるために提供されており、クラスター全体のアーキテクチャを定義することを目的としていません。高可用性、他のテナントワークロード、予想される成長、プラットフォームサービスオーバーヘッドなど、運用要件に基づいて基盤となるクラスターをサイジングする必要があります。
コントロールプレーンノード数、インフラストラクチャノード数、ワーカーノード数、高可用性要件、成長計画などのクラスターサイジングの決定はお客様の責任です。
サポートされているスタック構成
Bob は複数のデプロイメント構成をサポートしています。総リソースフットプリントは有効なアドオンによって異なります。
| スタック構成 | CPU (raw) | メモリ (raw) | ストレージ (PV) | ステータス |
|---|---|---|---|---|
| Bob Core | 38.1 vCPU | 42.1 GiB | ~50 GiB | ベースライン利用可能 |
| Bob Core + RAG | 38.1 vCPU | 69.1 GiB | ~62 GiB | ベースライン利用可能 |
| Bob Core + Z Understand | 30.1 vCPU | 79.1 GiB | ~2288 GiB | ベンチマーク中 |
| Bob Core + RAG + Z Understand | 46.1 vCPU | 113.1 GiB | ~2320 GiB | ベンチマーク中 |
Bob Core はサポートされる最小デプロイメント構成を表しています。リソース値は Bob テナント要件の集計を表し、プラットフォームインフラストラクチャのオーバーヘッドを除外しています。アドオンのリソース要件はパフォーマンステスト完了後に公開されます。
Bob リソースフットプリント
以下の参照フットプリントは、オプションのアドオンが有効になっていない Bob Core デプロイメントに適用されます。
| デプロイメントプロファイル | CPU | メモリ | ストレージ (PV) |
|---|---|---|---|
| 評価 (raw) | 16.8 vCPU | 20.8 GiB | ~9 GiB |
| 評価 (+25〜30% ヘッドルーム) | ~21 vCPU | ~26 GiB | ~9 GiB |
| 本番 (raw) | 28.1 vCPU | 41.1 GiB | ~50 GiB |
| 本番 (+25〜30% ヘッドルーム) | ~36.5 vCPU | ~53.4 GiB | ~50 GiB |
推奨値には、プラットフォームオーバーヘッド、ワークロードの変動、アップグレード、および将来の成長に対応するスケジューリングヘッドルームが含まれています。ワーカーノードの容量をサイジングする際はヘッドルーム調整済みの値を使用してください。
シングルノード OpenShift (SNO) クラスター
シングルノード OpenShift は、コントロールプレーンとワーカーワークロードを単一ホストに統合します。SNO デプロイメントは、高可用性が不要な概念実証、開発、テスト、エッジ環境に適しています。
参照サイジング
| レイヤー | CPU | メモリ | ストレージ |
|---|---|---|---|
| OpenShift プラットフォーム最小要件 | 8 vCPU | 16 GiB | 120 GiB |
| Bob 評価ワークロード (ヘッドルーム込み) | ~21 vCPU | ~26 GiB | ~9 GiB |
| ノード合計の参照値 | ~29 vCPU | ~42 GiB | ~130 GiB |
- シングルノード OpenShift はノードの冗長性を提供しません。
- コントロールプレーンとアプリケーションワークロードが同じホストを共有します。
- ノード障害が発生するとサービスが完全に利用不能になります。
- SNO は可用性やディザスターリカバリー機能を必要とする本番環境には推奨されません。
インストールガイダンスについては、シングルノード OpenShift をベアメタルにインストールする方法 (最小 8 vCPU / 16 GiB RAM / 120 GiB ストレージ) およびシングルノードへのインストールの準備、OCP 4.20 を参照してください。
マルチノード OpenShift クラスター
以下のアーキテクチャは、専用クラスターで Bob を実行するための最小参照デプロイメントを表しています。
最小参照構成
| ノードロール | 数 | CPU/ノード | メモリ/ノード | 集計リソース |
|---|---|---|---|---|
| コントロールプレーン | 3 | 4 vCPU | 16 GiB | 12 vCPU / 48 GiB |
| インフラストラクチャ | 3 | ~4 vCPU | ~16 GiB | 12 vCPU / 48 GiB |
| ワーカー | 3 | 20 vCPU | 24 GiB | 60 vCPU / 72 GiB / 600 GiB ストレージ |
| クラスター合計 | 9 | - | - | ~84 vCPU / ~168 GiB / 600 GiB |
OpenShift オーバーヘッドを差し引いた後、ワーカーノードプールは概ね以下を提供します。
- 57 vCPU の割り当て可能容量
- 63 GiB の割り当て可能メモリ
この容量は、推奨スケジューリングヘッドルームを含む Bob Core 本番フットプリントをサポートするのに十分です。
| 要件 | CPU | メモリ |
|---|---|---|
| Bob Core 本番要件 | ~36.5 vCPU | ~53.4 GiB |
| ワーカープール割り当て可能容量 | ~57 vCPU | ~63 GiB |
参考として、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 の各コンポーネントは異なるストレージアクセスモードを必要とします。
| コンポーネント | 必要なアクセスモード | 注意事項 |
|---|---|---|
| PostgreSQL | RWO (ReadWriteOnce) | ブロックストレージが必要です。SSD バックストレージを強く推奨します。 |
| OpenSearch | RWO (ReadWriteOnce) | 高パフォーマンスのブロックストレージを推奨します。 |
| Redis | RWO (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 証明書を検証できること。