Known issues

目次

Known issues#

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

注釈

これらの問題の一部は、後のイノベーションリリースで解決されました。これらの問題の最新のステータスを知りたい場合、またはイノベーションリリースを使用している場合、 Known issues を参照してください。

マルチDC#

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

Tip

Known issues で解決されました。

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

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

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

Tip

Known issues で解決されました。

説明 マルチデータセンター環境では、利用可能な場所を取得する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 ...
  }
}

注釈

マルチ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コンソールに正しく表示されるはずです。

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

OpenShiftユーザーのクロスストリームアップグレードの問題#

説明 OpenShift Operator Lifecycle ManagerOLMが厳密なセマンティックバージョニングを適用しているため、日付ベースのバージョン2026.1 のようなは、標準バージョンの1.4 などよりも大幅に「高い」ものとして解釈されます。これにより、OLMがLTSバージョンへの移動をアップグレードとして認識しない場合があります。

回避策 この問題に使用可能な回避策はありません。これを解決するために、現在HMアプリケーションバージョンからOperatorバージョンを切り離しているところです。

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

Tip

HMバージョン1.3.1以降で解決されました。

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

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

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

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

Tip

HMバージョン1.3.1以降で解決されました。

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

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

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

Tip

HMバージョン1.3.1以降で解決されました。

説明 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データベース設定が複製されない#

Tip

HMバージョン1.3.1以降で解決されました。

説明 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クラスターに参加できません#

Tip

Known issues で解決されました。

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

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

自己管理クラスターのナレッジベースを照会できません#

説明 自己管理クラスターのナレッジベースを照会することはできません。

回避策 該当なし

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

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

Tip

HMバージョン1.3.1以降で解決されました。

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

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

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

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

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

ボリュームスナップショットクラスターはWALファイルを自動的にプルーニングしません#

Tip

HMバージョン1.3.4以降で解決されました。

説明 現在の制限のため、自動ログ先行書き込みWAL保持ポリシーはVolumSnapshotでは機能せず、barman-cloudバックアップ方法とのみ互換性があります。 VolumeSnapshotは、サポートされているすべての環境のデフォルトのバックアップ方法であるため、 VolumeSnapshotを使用して作成されたクラスターは、古いWALファイルを自動的にプルーニングせず、オブジェクトストレージにWALファイルが蓄積されます。

回避策 ストレージの蓄積を防止し、WALリテンションポリシーを呼び出すには、少なくとも1週間に1回、 VolumeSnapshotで作成したクラスターのオンデマンドBarmanバックアップを実行またはスケジュールする必要があります。

ボリュームスナップショットの復元は同じリージョンに制限されています#

説明: ハイブリッドマネージャーHMは、内部バックアップメカニズムを使用してレプリカクラスターのクロスリージョンデータの同期を自動的に処理しますが、ボリュームスナップショットからのクラスターの手動復元は、クロスリージョン操作をサポートしていません。ボリュームスナップショットを使用してクラスターを別のリージョンの場所に復元しようとすると、スナップショットは地理的にソースリージョンに制限されているため、操作は失敗します。

回避策 別のリージョンの場所にデータを復元するには、ボリュームスナップショットの代わりにBarmanバックアップを使用します。 Barmanバックアップは、リージョンを超えてアクセスできます。

transporter-db WALギャップのため、ディザスターリカバリーDRプロセスが失敗する場合がある#

説明: 内部transporter-db サービスのDRプロセスは、使用可能な最新のバックアップから復元するときに失敗する場合があります。これは、バックアップは完了したが、そのバックアップの直後に後続のログ先行書き込みWALファイルがアーカイブされなかった低アクティビティのシナリオで発生します。このギャップにより、復元プロセスは信頼性の高いポイントインタイムリカバリーを正常に完了できません。

回避策 復元を成功させるには、すぐに少なくとも1つのアーカイブされたWALファイルがある古いバックアップを選択して復元します。これにより、必要なトランザクションログをリカバリプロセスで利用できるようになります。

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

注釈

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モデルクラスターの展開が停止する#

Tip

Known issues で解決されました。

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

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

ナレッジベースの資格情報を編集するとエラーページが表示される#

説明: HMコンソールのパイプラインから作成されたナレッジベースKBを編集するときに、ユーザー名フィールドをスキップして、すぐにパスワードフィールドに移動すると、クライアントサイドのJavaScriptエラーnullのプロパティを読み取ることができません、 Unexpected Application Error! ページが発生します。

回避策 エラーページが表示されないようにするには、 Edit KB を選択した直後、パスワードを入力する前に Username フィールドを入力します。

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

Tip

HMバージョン1.3.1以降で解決されました。

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

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

アナリティクスと階層テーブル#

階層化パーティションテーブルの更新がPGAAエラーで失敗する#

説明 大規模な階層的パーティションテーブルでUPDATE ステートメントを実行しようとすると、操作はERROR: system columns are not supported by PGAA scan メッセージで失敗します。この問題は、更新のターゲットパーティションが標準のヒープアクセス方法を使用している場合でも、アクティブに階層化されたIcebergテーブルでなく、変更クエリー。

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

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

Tip

HMバージョン1.3.1以降で解決されました。

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

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

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

Tip

HMバージョン1.3.1以降で解決されました。

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

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

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

回避策 カスタムダッシュボードは、

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

エステートページにアクセスするときのHTTP 431 “Request Header Fields Too Large”エラー#

説明 多数のプロジェクト通常50以上にアクセスするユーザーは、HMコンソールの Estate ページに移動すると、HTTP 431エラーが発生する場合があります。このエラーは、要求に対して生成された承認ヘッダーが上流プロキシまたはロードバランサーのサイズ制限を超えているために発生します。この問題により、HMコンソールはエステート結果をロードできなくなり、マシンユーザーまたは/api/v1/estate エンドポイントを直接呼び出す自動スクリプトに影響を与える可能性があります。

回避策 このエラーの影響を受けるユーザーの場合、組織所有者は次のいずれかのアクションを実行して要求ヘッダーのサイズを削減する必要があります。

  • プロジェクトアクセスの取り消し アクティブに必要とされなくなったプロジェクトへの影響を受けるユーザーのアクセスを削除します。

  • 未使用のプロジェクトの削除 使用されなくなったプロジェクトを削除して、ユーザーのプロファイルに関連付けられている合計数を減らします。

マイグレーション#

HM移行ポータル、データ移行ワークフロー、およびスキーマ取り込みワークフローに関連する既知の問題は、 Migrating databases ドキュメント内の専用ページで維持されています。これにより、ドキュメントの関連セクション内で集中的なコミュニケーションが可能になります。完全なリストについては、 Known issues, limitations, and notes を参照してください。

目次