Creating an Red Hat OpenShift cluster for use with Hybrid Manager#

installed your system が完了したら、Hybrid ManagerHMで使用するRed Hat OpenShiftRHOSクラスターを作成する準備が整います。

HMインストールのためのOpenShiftクラスターの準備#

Red Hat OpenShiftRHOSオンプレミスクラスターにHMを正常にインストールするには、特定の前提条件と構成を満たしている必要があります。

事前構成のクラスター要件#

HMは現在サポートしています
- OpenShift 4.17 with Kubernetes 1.30

or:

OpenShift 4.18 with Kubernetes 1.31

ステップ1ネットワークを構成する#

ネットワークポリシーを定義します。 Kubernetesコントロールプレーン、ワーカーノード、外部システム間のトラフィックを管理するために、適切なネットワークポリシーが設定されていることを確認します。
イングレス/エグレスルールを定義します。
クラスターコンポーネントとHMスタック間の通信が安全であることを確認します。 - 入力/出力ネットワークポリシーを検証して、不要な外部アクセスを制限しながら、クラスターコンポーネントが通信できるようにします。
ロードバランサーのセットアップ外部ロードバランサーを使用する場合、OpenShift APIトラフィックとワーカーノード通信を処理するように構成します。
DNSの構成 HMの内部サービス検出を含む、クラスターにDNSレコードが設定されていることを確認します。
クラスターにワーカーノード用の適切なプライベートネットワーク分離があることを確認します。 OpenShiftは通常、ソフトウェア定義のネットワークSDN構成を介してこれを処理します。

ステップ2ノードサイズとリソースを構成する#

HMとその関連コンポーネントをサポートするには、OpenShiftクラスター内のノードがリソース要件を満たしている必要があります。

ノードのサイジング#

マスターノード OpenShiftコントロールプレーンノードは、リソース割り当ての標準要件CPU、メモリ、ディスクサイズなどを満たしている必要があります。
- 一般的な推奨事項
  - 3つのマスターノードそれぞれに次のものが含まれます。
    - CPU
      - 最小値4つのvCPU最大10のワーカーノードの場合
      - 推奨中規模のクラスター10〜50のワーカーノード用の8 vCPU
      - 50ワーカーノードの場合 16+ vCP Us
    - メモリ
      - 最小 32 GB RAM最大10の場合ワーカーノード)
      - 推奨大規模なワークロード10〜50ワーカーノードの場合は64 GB RAM以上
      - 50ワーカーノードの場合 64+ GB RAM
    - Disk
      - 最小100 GB SSD
      - 推奨大規模なワークロードの場合は200 GB SSDs
      - 50ワーカーの場合ノード >200 GB SSD
ワーカーノード HM制御コンポーネントとPostgresクラスターを処理するために十分なリソースをワーカーノードに割り当てます。小規模なワークロードには、HM制御コンポーネント用に3つのワーカーノードとPostgresワークロード用の3つのワーカーノードをお勧めします。5〜20のPostgresクラスター)。ここからPostgresワークロードをスケールアップすると、Postgresワークロード用により多くのワーカーノードが必要になり、最終的にはPostgresワークロードワーカーノードの数の増加をサポートするためにさらに多くの制御ワーカーノードが必要になる場合があります。
- 一般的な推奨事項
- 6つのワーカーノードそれぞれ:
  - CPU :
    - 最小4 vCPUこれは、ワークロードの種類によっては高くなる場合があります
  - メモリ
    - 最小ノードごとに32 GBのRAM
  - ディスク
    - 最小ノードごとに100 GBの永続ストレージデータベースとロギングの要件に基づいて調整します)。最適なパフォーマンスを得るには、高速ディスクSSDを使用します。

HM制御ノードとPostgresワークロードをホストするHM Postgresデータノードに異なるタイプのノードをオプションで使用するには、RHOSに追加のマシンセットが必要です。

制御ノードマシンセット

spec:
    replicas: 3
    template:
    spec:
        metadata:
        labels:
            edbaiplatform.io/control-plane: "true"
    taints:
    - key: edbplatform.io/control-plane
        value: "true
        effect: NoSchedule

Postgresワークロードマシンセットをホスティングするデータノード

spec:
    replicas: 3
    template:
    spec:
        metadata:
        labels:
            edbaiplatform.io/control-plane: “true”
        taints:
        - key: edbplatform.io/control-plane
            value: "true"
            effect: NoSchedule

リソース予約#

HMワークロードとの競合を防ぐには、システムコンポーネント用にCPUとメモリを予約します。
HMモニタリングおよび可観測性ツールたとえば、Grafana、Loki、およびPrometheusに追加リソースを割り当てます。
ノードプール構成
- 必要に応じて、テイントと寛容を使用して、特定のノードでHMワークロードを分離します。
- 特定のタスクたとえば、「モニタリング」、「データベース」のノードにラベルを付けて、リソース割り当てを最適化します。
スケーリング
自動スケーリングを設定して、クラスターが需要の増加を動的に処理できるようにします。 OpenShiftのホリゾンタルポッドオートスケーラーHPAを使用して、必要に応じてポッドをスケーリングできます。

ネットワーキング帯域幅#

各ノードに、HM通信と外部データ転送S3バックアップなどを処理するための十分なネットワーク容量があることを確認します。

ベースラインの推奨事項

Component	Recommended bandwidth	Justification
K8s control plane nodes	1 Gbps+ per node	Handles internal Kubernetes traffic, API server requests, logs/metrics, and orchestration tasks.
Worker nodes (HM)	1 Gbps+ per node	For HM control components, PostgreSQL replication, internode communication, and metrics/logs.
External bandwidth	1-20 Gbps (aggregated)	S3 backups and inter-cluster replication may require high throughput.

ステップ3必要なCSIドライバーをインストールする#

HMは、CSIドライバーに依存するストレージおよびスナップショット機能を使用します。次のドライバーがOpenShiftクラスターにインストールされ、適切に構成されていることを確認します。

永続的ストレージドライバーストレージバックエンドたとえば、OpenShift Container Storage、Ceph、またはその他のオンプレミスソリューションなどと互換性のあるストレージクラスドライバーをインストールします。
スナップショットコントローラボリュームスナップショット管理用にCSIスナップショットコントローラを構成します。

ステップ4ストレージクラスを構成する#

デフォルトのストレージクラス HMワークロードに最適化されたデフォルトのストレージクラスを設定します。

カスタムストレージクラス 特定のワークロードでカスタム構成が必要な場合、追加のストレージクラスを作成します。

ローカルストレージオプショナル 共有外部ストレージが不足しているオンプレミスクラスターの場合、LVM Storage Operatorを使用してローカルストレージを管理します。この方法は、ワーカーノード上のローカルディスクから直接、高性能、低レイテンシーの永続ボリュームをプロビジョニングします。詳細については、 LVM storage installation を参照してください。

ステップ5名前空間とシークレットを準備する#

HMの名前空間 HMコンポーネントの専用の名前空間を作成して、分離と管理性を保証します。

oc create ns edbpgai-bootstrap

シークレット オブジェクトストレージ資格情報、データベースアクセストークン、またはその他の機密情報など、必要な資格情報のKubernetesシークレットを作成します。以下は、HM固有のシークレットと構成です。最初のImagePullSecretは、HMが適切に機能するために必要です。カタログのグリップテープとDeltaLakeオブジェクトストレージとシークレットは、GenAI Builderまたはカタログのどちら用にクラスターを設定するかによって異なるため、オプショナル。

ImagePullSecretと名前空間の構成 HMに必要

環境変数を設定します。

OC Registryにもっと簡単にログインできるように、設定するコンテナレジストリ変数がいくつかあります。

export CONTAINER_REGISTRY_URI=<local-registry-uri>
export CONTAINER_REGISTRY_USERNAME=<container-registry-username>
export CONTAINER_REGISTRY_PASSWORD=<container-registry-password>

プルシークレットファイルを準備します。

イメージプルシークレットのディレクトリを準備します。

tmpdir=$(mktemp -d /tmp/hm-pull-secret)
chmod 0700 "${tmpdir}"

レジストリにログインし、シークレットを更新します。

OCレジストリにログインします。

oc registry login \
--registry="${CONTAINER_REGISTRY_URI}" \
--auth-basic="${CONTAINER_REGISTRY_USERNAME}:${CONTAINER_REGISTRY_PASSWORD}" \
--to="$tmpdir/pull-secret"

次に、シークレットを更新します。

oc set data secret/pull-secret -n openshift-config \
    --from-file=.dockerconfigjson="$tmpdir/pull-secret"

クリーンアップ。

シークレット用に作成した一時ディレクトリをクリーンアップします。

rm -rf $tmpdir

Create a secret for Griptape and configure DeltaLake object storage GenAI Builderのオプショナル**

Create a secret for Catalog カタログを使用する場合のオプショナル**

Create custom secrets for Migration Portal Migration Portalとの内部通信を保護するオプション**

ステップ6認証キーとセキュリティキーを構成する#

HMとその基になるコンポーネントには、コンポーネント間の適切な通信を保証し、機密データを保護するために、安全な認証メカニズムが必要です。

AES-256暗号化キーを生成します。

HMは、AES-256暗号化を使用して、通信中または保存中の機密データたとえば、データベース資格情報、トークンなどを保護します。ランダムなAES-256暗号化キーを生成するには

export AES_256_KEY=$(openssl rand -base64 32)

キーをKubernetesに保存します。

HMおよび関連サービスがキーにアクセスできるようにするには、適切な名前空間にKubernetesシークレットを作成します。

次のコマンドを実行してシークレットを作成します。

kubectl create secret generic hm-auth-key \
    --namespace <hm-namespace> \
    --from-literal=aes-256-key=$AES_256_KEY

シークレットを確認します。

kubectl get secret hm-auth-key --namespace <hm-namespace>

ステップ7オブジェクトストレージを構成する#

オブジェクトストレージバックエンド HMバックアップをサポートするには、クラスターを専用のオブジェクトストレージソリューションたとえば、MinIO、Ceph Object Gateway、またはAWS S3互換ストレージに接続します。

特に、ハイブリッドマネージャーはこのバケットを使用して以下を保存します。

管理対象ストレージの場所
Postgres WAL + バックアップ
ログPostgresと内部サービスの両方
メトリックPostgresと内部サービスの両方

バケットを作成する#

MinIO または Ceph bucket を作成します。

バケットユーザーを作成する#

プロバイダーでハイブリッドマネージャー用の専用バケットを作成した後、バケットへの完全なアクセスを持つIDユーザーと、IDユーザーのAWS静的資格情報を作成して、バケットへのハイブリッドマネージャーにアクセスを付与します。

MinIO Client をダウンロードします。

MinIO展開名を取得し、ユーザー名とパスワードを作成します。

export MINIO_DEPLOYMENT_NAME=<minio_deployment_name> # deployment name to minio
export BUCKET_NAME=<minio_bucket_name> # bucket name
export AWS_ACCESS_KEY_ID=<minio_user_name> # user name
export AWS_SECRET_ACCESS_KEY=<minio_user_password> # password to the user
export MINIO_POLICY_NAME=<minio_policy_name> # policy to minio

新しいユーザーを作成します。

mc admin user add ${MINIO_DEPLOYMENT_NAME} ${AWS_ACCESS_KEY_ID} ${AWS_SECRET_ACCESS_KEY}

MinIOポリシーを1つ作成します。

cat << EOF > policy.json
{
    "Version" : "2012-10-17",
    "Statement": [
        {
            "Effect" : "Allow",
            "Action" : [
                "s3:*"
            ],
            "Resource" : [
                "arn:aws:s3:::${BUCKET_NAME}",
                "arn:aws:s3:::${BUCKET_NAME}/*"
            ]
        }
    ]
}
EOF

ポリシーを適用します。

mc admin policy create ${MINIO_DEPLOYMENT_NAME} ${MINIO_POLICY_NAME} ./policy.json

ポリシーをユーザーにアタッチします。

mc admin policy attach ${MINIO_DEPLOYMENT_NAME} ${MINIO_POLICY_NAME} --user ${AWS_ACCESS_KEY_ID}

Cephのコマンドラインインターフェイス Radosgw-admin utility をダウンロードします。

バケットといくつかの環境変数を取得します。

export BUCKET_NAME=<bucket_name> # bucket name
export USER_NAME=<user_name> # user name

ユーザーを作成します。

radosgw-admin user create --uid ${USER_NAME} --display-name= ${USER_NAME} > user.json

export AWS_ACCESS_KEY_ID=$(cat user.json | jq -r .keys[0].access_key)
export AWS_SECRET_ACCESS_KEY=$(cat user.json | jq -r .keys[0].secret_key)

ユーザーにバケットへのアクセスを付与します。

radosgw-admin bucket link --bucket ${BUCKET_NAME} --uid ${USER_NAME}

バケットアクセスのシークレットを作成する#

バケットへのHMアクセスのための専用ユーザーを準備した後、作成したユーザーをハイブリッドマネージャーに関連付けるシークレットを作成して、オブジェクトストレージへのアクセスを提供します。

apiVersion: v1
kind: Secret
metadata:
  name: edb-object-storage # name cannot be changed
  namespace: default # namespace cannot be changed
stringData:
    auth_type: credentials

    # Optional: Used only when the object storage servers certificate is not issued by a well-known CA
    #
    # Base64 string of the CA bundle for the certificate used by the object storage server
    aws_ca_bundle_base64: xxx

    # Required: Endpoint URL to the object storage
    aws_endpoint_url_s3: xxx

    # Required: AWS Static Credentials - AWS_ACCESS_KEY_ID
    aws_access_key_id: xxx

    # Required: AWS Static Credentials - AWS_SECRET_ACCESS_KEY
    aws_secret_access_key: xxx

    # Required: Bucket name
    bucket_name: xxx

    # Required: Region of the bucket
    aws_region: xxx

    # Optional: true or false
    #
    # When server-side encryption is disabled, set this to true. By default, its value is false, indicating that server-side encryption is enabled.
    server_side_encryption_disabled: bool

ステップ8ネットワークセキュリティを検証する#

ファイアウォールルール OpenShiftクラスター、外部オブジェクトストレージ、およびHMの外部依存関係の間で必要な通信がファイアウォールルールで許可されていることを確認します。
上り/下りルール必要なエンドポイントとIP範囲のみにアクセスを制限して、露出を最小限に抑えます。

ステップ9クラスター構成を調整する#

一部のデフォルトのOpenShift構成は調整が必要になる場合があります。

ノードプールの調整リソースの割り当て、テイント/トレランスを含む、HMワークロードのノード構成を最適化します。
ストレージクラスの調整必要に応じて、デフォルトのストレージクラスを置き換えまたは変更します。
ネットワークポリシーネットワーク構成を調整して、HM要件との互換性を保証します。

ステップ10必要なアドオンをインストールする#

必要なOpenShiftオペレーターまたはアドオンのインストールと構成
- サービスメッシュ HMはistioサービスに依存しています Mesh.
- モニタリングとロギング OpenShiftモニタリングおよびロギングソリューションを設定して、HM可観測性コンポーネントと統合します。

必要な環境変数の設定に進みます。#

クラスターが構成されたら、プレインストールの次のフェーズ setting the necessary environmental variables for installation に進みます。

Creating an Red Hat OpenShift cluster for use with Hybrid Manager

目次