Known issues

目次

Known issues#

これらは、Hybrid Manager 1.3リリースで特定された現在既知の問題と制限です。必要に応じて、これらの問題の影響を軽減するために役立つ回避策を含めました。これらの問題は積極的に追跡され、将来のリリースで解決される予定です。

マルチDC#

アップグレード後のマルチDC構成の損失#

説明 マルチDCセットアップスクリプトクラスター間通信用に適用された構成は、ハイブリッドマネージャープラットフォームのアップグレードまたはオペレーターの調整後、持続しません。

回避策 ハイブリッドマネージャーをアップグレードまたはコンポーネントをバージョンアップするたびに、マルチDCセットアップスクリプトを再度実行して、必要な構成を再適用する必要があります。

マルチDCセットアップの場所ドロップダウンリストが空です#

説明 マルチデータセンター環境では、利用可能な場所を取得するAPI呼び出しがgRPCメッセージサイズエラー429 / 4.3MB制限を超過して失敗します。これは、API応答に大量の画像セット情報が含まれるため、コンソールに空のロケーションリストが発生するためです。

回避策 この高度な回避策には、APIから返されるイメージセット情報の量を制限するクラスター管理者権限が必要です。これには、upm-image-library およびupm-beacon ConfigMapのイメージ検出タグルールの変更と、それに続く関連ポッドの再起動が含まれます。

回避策の詳細

回避策は、画像ライブラリとビーコンコンポーネントが使用する正規表現タグルールを変更して、インデックス付けされる画像タグの数を一時的に制限します。これにより、API応答サイズが削減され、ロケーションをロードできるようになります。

  1. upm-image-library ConfigMapを見つけます。

kubectl get configmaps -n upm-image-library | grep upm-image-library
# Example Output: upm-image-library-ttkt29fmf7 1 5d3h

  1. 前の手順で見つけたConfigMapを編集し、各イメージ検出ルールedb-postgres-advanced 、edb-postgres-extended 、postgresql の下のtags ルールを変更します。既存の正規表現を制限的な正規表現に置き換えます。

# Snippet of the YAML you will edit in the ConfigMap
"imageDiscovery": {
  "rules": {
    "(^|.*/)edb-postgres-advanced$": {
      "readme": "EDB postgres advanced server",
      "tags": [
        "^(?P<major>\d+)\.(?P<minor>\d+)-2509(?P<day>\d{2})(?P<hour>\d{2})(?P<minute>\d{2})    (?:-(?P<pgdFlavor>pgdx|pgds))?(?:-(?P<suffix>full))?$"
      ]
    },
    # ... repeat for edb-postgres-extended and postgresql ...
  }
}

!!!note マルチDCセットアップを実行している場合、この手順はプライマリハイブリッドマネージャークラスターで実行する必要があります。

  1. イメージライブラリーポッドを再起動します。

kubectl rollout restart deployment upm-image-library -n upm-image-library

  1. upm-beacon ConfigMapを取得して、エージェント構成を変更します。

kubectl get configmaps -n upm-beacon beacon-agent-k8s-config

  1. ConfigMap beacon-agent-k8s-config を編集し、各postgres_repositories エントリー edb-postgres-advanced 、edb-postgres-extended 、postgresql の下のtag_regex ルールを変更します。

# Snippet of the YAML you will edit in the ConfigMap
postgres_repositories:
  - name: edb-postgres-advanced
    description: EDB postgres advanced server
    tag_regex: "^(?P<major>\d+)\.(?P<minor>\d+)-2509(?P<day>\d{2})(?P<hour>\d{2})(?    P<minute>\d{2})(?:-(?P<pgdFlavor>pgdx|pgds))?(?:-(?P<suffix>full))?$"
  # ... repeat for edb-postgres-extended and postgresql ...

  1. エージェントポッドを再起動します。

kubectl rollout restart deployment -n upm-beacon upm-beacon-agent-k8s

これらの手順を完了すると、画像データサイズが削減されたため、ロケーションAPI呼び出しが成功し、ロケーションがHybrid Managerコンソールに正しく表示されるはずです。

コアプラットフォームとリソース#

upm-beacon-agent 複雑な環境ではメモリ制限が不十分です#

説明 多くのデータベースとバックアップがある環境では、upm-beacon-agent ポッドのデフォルトの1GBメモリ割り当てでは不十分であり、頻繁なOOMKillまたはクラッシュループの問題が発生する可能性があります。このリソース制限は、現在標準のHelm値またはHybridControlPlane CRを介して構成できません。

回避策 ユーザーはKubernetes展開に手動でパッチを適用して、upm-beacon-agent ポッドのメモリリソース制限を増やす必要があります。

データベースクラスターエンジン#

EDB Postgres分散PGDクラスターに表示される誤ったデータベース名#

説明 Hybrid Managerコンソールの Connect タブと接続文字列は、PGDクラスターのデフォルトのデータベース名がedb_adminと誤って表示されます。 PGDクラスターには、 bdrdbデータベースへの接続が必要です。

回避策 PGDクラスター接続情報には、次の信頼できるソースのいずれかを使用します。.PGPASS BLOB 、.PG_SERVICE.CONF ファイル、またはクラスターの詳細ページの完全な接続文字列。

PGD-Xクラスターの作成が「PGD - アプリケーションユーザーの調整」フェーズでスタックする#

説明 PGD-Xクラスターの作成、特に監視専用リージョンが関係する場合、-グローバルRAFTリーダーシップが予期せず監視専用ノードによって保持されている、または-サブグループのenable_routing が無効になっていることが原因でストールする場合があります。

RAFTリーダーシップ問題の回避策 データグループ内のノードへのグローバルRAFTリードの転送を手動でトリガーします。 PGDクラスターのbdrdbに接続し、実行します。

bdr.raft_leadership_transfer(node_name:=<target node>, wait_for_completion:=true, node_group_name:=world);

enable_routing問題の回避策 サブグループのルーティングを手動で有効にします。 bdrdbに接続して実行します。

SELECT bdr.alter_node_group_option(<subgroup name>,enable_routing,true);

max_connections がデフォルト以外の場合、3ノードPGDクラスターの作成に失敗する#

説明 初期クラスタープロビジョニング中に構成パラメーターmax_connections がデフォルト以外の値に設定されている場合、3データノードEDB Postgres分散PGDクラスターの作成は失敗します。

回避策 デフォルトのmax_connections 値を使用してPGD 3データノードクラスターを作成し、クラスターが正常にプロビジョニングされた後に値を更新します。

2番目のデータグループを作成または複製するときにPGDデータベース設定が複製されない#

説明 PGDクラスターで2番目のデータグループを作成または複製する場合、Postgres設定 max_connections 、max_worker_processes など は最初のデータグループから自動的にコピーされません。レプリカグループ設定はプライマリグループより低くすることはできないため、これにより、一貫性のない設定とクラスターの状態の問題が発生する可能性があります。

回避策 2番目のPGDグループの構成を手動で編集して、プロビジョニングの前にデータベース設定が最初のデータグループと同じであることを確認します。

AHA Witnessノードのリソースがオーバープロビジョニングされています#

説明 監視ノードを使用するAdvanced High AvailabilityAHAクラスターの場合、監視ノードは大規模なデータノードのCPU、メモリ、およびディスク構成を誤って継承し、不必要なリソースのオーバープロビジョニングが発生します。

回避策 pgdgroup YAML構成を手動で更新して、監視ノードに必要な最小限のリソースを指定および構成します。

HAクラスターは、ストリーミングレプリケーション証明書の認証にverify-full の代わりにverify-ca を使用します#

説明 レプリカクラスターは、ストリーミングレプリケーション認証に、推奨される最も安全なverify-full の代わりに、それほど厳密ではないverify-ca 設定を使用します。基になるCloudNativePGCNPクラスターが、特定の環境GKEロードバランサーなどでverify-full に必要なIPサブジェクト代替名IP SANをサポートしていないため、これは現在必要です。

回避策 なし。修正は、IP SANをサポートする基になるCNPコンポーネントに依存しています。

2番目のノードが遅すぎるため、大規模なHAクラスターに参加できません#

説明 大規模なクラスターの場合、2番目のノードスタンバイがHAクラスターに参加するために使用するpg_basebackup プロセスが遅すぎます。これにより、スタンバイノードの参加に失敗する可能性があり、単一ノードをHAにスケーリングできず、クラスターをHA構成に直接復元するときに問題が発生します。

回避策 単一のノードにデータをロードしてHAにスケーリングするベストプラクティスを避けます。代わりに、最初からHAクラスターにデータを直接ロードします。大規模なクラスターをHA構成に復元するための回避策はありません。

バックアップ リカバリー#

リージョンをまたがってボリュームスナップショットリカバリーを使用する場合、レプリカクラスターの作成が失敗する#

説明 ボリュームスナップショットリカバリーはクロスリージョンの復元をサポートしていないため、別のリージョンにある2番目の場所でのレプリカクラスターの作成はInvalidSnapshot.NotFound エラーで失敗します。

回避策 最初にプライマリクラスターからBarmanバックアップを手動でトリガーし、次にそのBarmanバックアップをボリュームスナップショットの代わりに使用して、クロスリージョンレプリカクラスターをプロビジョニングします。

デフォルトの並列構成が原因でWALアーカイブが遅い#

説明 wal.maxParallel のデフォルト設定は制限が多すぎるため、大量のデータのロード中にWALアーカイブが遅くなります。これにより、アーカイブの準備ができたWALファイルのバックログが発生し、ディスクがフル状態になる可能性があります。このパラメーターは、HMコンソールからはまだ設定できません。

回避策 特定のバックアップオブジェクトストアのobjectstores.barmancloud.cnpg.io Kubernetesリソースを手動で編集し、wal.maxParallel 値を20などに増やして、アーカイブを高速化します。

AIファクトリーとモデル管理#

プロファイルキャッシュを使用したnim-nvidia-nvclip モデルの展開の失敗#

説明 展開プロセス中にプロファイルキャッシュが利用されると、AIファクトリー内でnim-nvidia-nvclip モデルのモデル作成は失敗します。

回避策 回避策では、管理者がNVIDIAレジストリからローカルマシンに必要なモデルプロファイルを手動でダウンロードする必要があります。次に、プロファイルファイルをハイブリッドマネージャーのオブジェクトストレージパスに直接アップロードし、最後に、特定の環境変数を使用してKubernetes InferenceService YAMLにパッチを適用して、失敗したネットワークダウンロードを試行する代わりに事前キャッシュされたファイルを使用するように強制することにより、モデルを展開する必要があります。 。

回避策の詳細

  1. NGC APIキーを使用して、NVIDIA Container Registry nvcr.ioにログインします。

docker login nvcr.io -u $oauthtoken -p $NGC_API_KEY

  1. Dockerイメージをローカルマシンにプルします。

docker pull nvcr.io/nim/nvidia/nvclip:latest

  1. ダウンロードしたプロファイル用のローカルディレクトリを準備します。

mkdir -p ./model-cache
chmod -R a+w ./model-cache

  1. ターゲットGPUのプロファイルを選択します。

例、A100 GPUプロファイル 9367a7048d21c405768203724f863e116d9aeb71d4847fca004930b9b9584bb6

  1. コンテナを実行してプロファイルをダウンロードします。コンテナはCPU専用モードNIM\_CPU\_ONLY=1 で実行され、ダウンロードマシンでのGPU固有の初期化問題が発生します。

export NIM_MANIFEST_PROFILE=9367a7048d21c405768203724f863e116d9aeb71d4847fca004930b9b9584bb6
export NIM_CPU_ONLY=1

docker run -v ./model-cache:/opt/nim/.cache -u $(id -u) -e NGC_API_KEY -e NIM_CPU_ONLY -e NIM_MANIFEST_PROFILE --rm nvcr.io/nim/nvidia/nvclip:latest

このコンテナは終了しません。ログに「Health Method denied」という行が表示されたら、実行を手動で停止する必要があります Ctrl+C 。これは、プロファイルのダウンロードが完了したことを確認します。

  1. ローカルマシンからハイブリッドマネージャー展開で使用されるオブジェクトストレージバケットにプロファイルをアップロードします。

gcloud storage cp -r ./model-cache gs://uat-gke-edb-object-storage/model-cache/nim-nvidia-nvclip

!!!note gs:// パスを調整して、展開の構成済みオブジェクト保存場所と一致します。

  1. HMコンソールを使用してモデルnim-nvidia-nvclip を作成し、Model Profiles Pathフィールドを以前の場所/model-cache/nim-nvidia-nvclip などとして指定します。展開は、最初は失敗するか、スタックします。

  2. Hybrid Manager KubernetesクラスターからInferenceService YAMLをエクスポートします。

  3. 必要な環境変数NIM_IGNORE_MODEL_DOWNLOAD_FAIL を、エクスポートしたYAMLのspec.predictor.model ブロックのenvセクションに追加します。このフラグは、ローカルで利用可能なキャッシュアップロードしたファイルを使用し、ネットワークダウンロードの失敗を無視するようにNIMコンテナに指示します。

# --- Snippet of the modified InferenceService YAML ---
spec:
  predictor:
    minReplicas: 1
    model:
      modelFormat:
        name: nim-nvidia-nvclip
      name: ""
      env:
      - name: NIM_IGNORE_MODEL_DOWNLOAD_FAIL  # <-- ADD THIS LINE
        value: "1"                         # <-- ADD THIS LINE
      resources:
        # ... resource requests/limits ...
      runtime: nim-nvidia-nvclip
      storageUri: gs://uat-gke-edb-object-storage/model-cache/nim-nvidia-nvclip
# ---------------------------------------------------

  1. kubectlを使用して変更したYAMLを適用して、事前ダウンロードされたプロファイルを使用するように展開を強制します。

kubectl apply -f <modified-inference-service-file.yaml> -n <model-cluster-namespace>

これで、ポッドは、オブジェクトストレージを介して手動で提供したモデルプロファイルを使用して、正常に起動するようになりました。

モデルプロファイルのオブジェクトストレージパスが空の場合、AIモデルクラスターの展開が停止する#

説明 AIモデルクラスターを作成し、[モデルプロファイルパスフィールド]でオブジェクトストレージパスを指定すると、指定されたパスにコンテンツが含まれていない場合、つまりモデルプロファイルにまだ存在します）。

回避策 モデルクラスター展開を開始する前に、[モデルプロファイルパスフィールド]で指定されたオブジェクトストレージパスに、正しい有効なプロファイルが含まれていることを確認します。

モデル名が間違っていると、LLMをリモートで呼び出すときに404エラーが発生します#

説明 APIエンドポイントを介して展開されたNVIDIA NIMモデルを呼び出すと、モデルカードに表示されるモデル名がAPIで必要とされる正しい名前ではない場合があります。これにより、「404 Not Found error」が発生します。

回避策 API呼び出しに必要な正確なモデル名nvidia/llama-3.3-nemotron-super-49b-v1 などを見つけるには、最初に/v1/models APIエンドポイントを照会します。

HMコンソールと可観測性#

アクティブなモデルクラスターのタグはモデルの詳細画面に表示されません#

説明 [ モデルクラスターの詳細 ]画面に特定のモデルを利用するアクティブなモデルクラスターを表示するテーブルで、 タグ フィールドは空です。

回避策 モデルクラスタータグは、専用の モデルクラスターの詳細 ページで引き続き正しく表示できます。

チャットモデルクラスターメトリックがGrafanaモデル概要ダッシュボードにありません#

説明 展開されたチャットモデルクラスターのメトリックはGrafanaモデル概要ダッシュボードに表示されず、これらの特定のAIコンポーネントの可観測性に影響します。

ユーザー作成のGrafanaダッシュボードは、プラットフォームの再展開/アップグレード後に持続しない#

説明 ユーザーがGrafanaアプリケーション内で直接作成したダッシュボードは、永続ストレージに保存されません。これらは、 Grafanaポッドが更新、再展開、または再起動されると消えますたとえば、 EKSの自動更新またはハイブリッドマネージャーのアップグレード中。

回避策 カスタムダッシュボードは、 exporting the dashboard as JSON によって外部でバックアップする必要があります。アップグレードの後、それらはGrafanaに手動でインポートして戻す必要があります。

目次