このドキュメントでは、 Google Cloudの IBM Spectrum Symphony 統合に関する一般的な問題を解決する方法について説明します。具体的には、IBM Spectrum Symphony ホスト ファクトリー サービス、Compute Engine と GKE プロバイダのコネクタ、Kubernetes 用 Symphony オペレータのトラブルシューティング ガイダンスについて説明します。
Symphony ホスト ファクトリー サービスの問題
これらの問題は、中央の Symphony ホスト ファクトリー サービスに関連しています。このサービスのメイン ログファイルは、Linux の次の場所にあります。
$EGO_TOP/hostfactory/log/hostfactory.hostname.log
ホスト ファクトリの環境変数を読み込むときに、$EGO_TOP 環境変数を設定します。IBM Spectrum Symphony では、$EGO_TOP は Enterprise Grid Orchestrator（EGO）のインストール ルートを指します。これは、クラスタのコア リソース マネージャーです。Linux での $EGO_TOP のデフォルトのインストール パスは通常 /opt/ibm/spectrumcomputing です。
クラスタが保留中のワークロード用に新しい VM を追加しない
この問題は、Symphony キューにジョブが含まれているにもかかわらず、ホスト ファクトリーが負荷を管理するための新しい仮想マシン（VM）をプロビジョニングできない場合に発生します。ホスト ファクトリ ログファイルに SCALE-OUT メッセージが含まれていません。
この問題は通常、Symphony リクエスターが正しく構成または有効化されていない場合に発生します。この問題を解決するには、構成されたリクエスタのステータスを確認して、リクエスタが有効になっており、保留中のワークロードがあることを確認します。
リクエスタ構成ファイルを見つけます。通常、このファイルは次の場所にあります。
$HF_TOP/conf/requestors/hostRequestors.jsonsource コマンドを使用すると、環境に
$HF_TOP環境変数が定義されます。値は、IBM Spectrum Symphony ホスト ファクトリー サービスの最上位のインストール ディレクトリのパスです。hostRequestors.jsonファイルを開き、symAinstエントリを見つけます。このセクションで、enabledパラメータが1の値に設定され、プロバイダ リストに構成済みの Google Cloud プロバイダ インスタンスの名前が含まれていることを確認します。- Compute Engine 構成の場合、プロバイダ リストには、Compute Engine プロバイダのインストール時に プロバイダ インスタンスを有効にするで作成した Compute Engine プロバイダの名前が表示されている必要があります。
- GKE 構成の場合、プロバイダ リストには、GKE プロバイダのインストール時に プロバイダ インスタンスを有効にするで作成した GKE プロバイダの名前が表示されている必要があります。
symAinst リクエスト元が有効になっていることを確認したら、スケールアウトが必要な保留中のワークロードがコンシューマーにあるかどうかを確認します。
すべてのコンシューマーとそのワークロードのステータスのリストを表示します。
egosh consumer list出力で、ワークロードに関連付けられているコンシューマーを探し、ワークロードが保留中であることを確認します。リクエスタが有効で、ワークロードが保留中であるにもかかわらず、ホスト ファクトリー サービスがスケールアウト リクエストを開始しない場合は、HostFactory サービスログでエラーを確認します。
ホストのファクトリー サービスが起動しない
ホスト ファクトリー サービスが実行されていない場合は、次の手順で問題を解決します。
HostFactoryサービスのステータスを確認します。egosh service list出力で
HostFactoryサービスを見つけ、STATEフィールドにSTARTEDのステータスが表示されていることを確認します。HostFactoryサービスが開始されていない場合は、再起動します。egosh service stop HostFactory egosh service start HostFactory
その他のエラーとロギング
ホスト ファクトリー サービスで他のエラーが発生した場合は、ログの詳細度を上げて、より詳細なログを取得します。手順は次のとおりです。
編集する
hostfactoryconf.jsonファイルを開きます。通常、このファイルは次の場所にあります。$EGO_TOP/hostfactory/conf/$EGO_TOP環境変数の値の詳細については、Symphony ホスト ファクトリー サービスの問題をご覧ください。HF_LOGLEVELの値をLOG_INFOからLOG_DEBUGに更新します。{ ... "HF_LOGLEVEL": "LOG_DEBUG", ... }変更が完了したら、ファイルを保存します。
変更を有効にするには、
HostFactoryサービスを再起動します。egosh service stop HostFactory egosh service start HostFactory
再起動後、HostFactory サービスはより詳細なログを生成します。このログを使用して、複雑な問題のトラブルシューティングを行うことができます。これらのログは、Linux の $EGO_TOP/hostfactory/log/hostfactory.hostname.log にあるメインのホスト ファクトリ ログファイルで確認できます。
ホスト ファクトリー プロバイダの問題
次の問題は、Compute Engine または Google Kubernetes Engine のホスト ファクトリー プロバイダ スクリプト内で発生します。
詳細なエラー メッセージについては、プロバイダのログ（hf-gce.log または hf-gke.log）を確認してください。hf-gce.log ファイルと hf-gke.log ファイルの場所は、プロバイダ インスタンスを有効にするのプロバイダの構成ファイルで設定された LOGFILE 変数によって決まります。
仮想マシンまたは Pod がプロビジョニングされていない
この問題は、ホスト ファクトリー プロバイダのログに requestMachines.sh スクリプトの呼び出しが表示されているにもかかわらず、 Google Cloudプロジェクトにリソースが表示されない場合に発生することがあります。
この問題を解決する方法は次のとおりです。
プロバイダ スクリプトのログ（
hf-gce.logまたはhf-gke.log）で、 Google Cloud API からのエラー メッセージを確認します。hf-gce.logファイルとhf-gke.logファイルの場所は、プロバイダ インスタンスを有効にするでプロバイダの構成ファイルに設定されたLOGFILE変数によって決まります。サービス アカウントに正しい IAM 権限が付与されていることを確認します。
- 現在のアクセス権を表示するの手順に沿って操作します。
- サービス アカウントに、プロジェクトに対する Compute インスタンス管理者（v1）（roles/compute.instanceAdmin.v1）の IAM ロールがあることを確認します。ロールの付与方法については、プロジェクト、フォルダ、組織に対するアクセス権の管理をご覧ください。
ホスト テンプレートの Compute Engine パラメータが有効であることを確認するには、次のことを確認する必要があります。
ホスト テンプレート パラメータは、Compute Engine プロバイダのインストール時にプロバイダ インスタンスを設定したときに作成した
gcpgceinstprov_templates.jsonファイルに存在する必要があります。検証する最も一般的なパラメータはgcp_zoneとgcp_instance_groupです。gcp_instance_groupパラメータで設定されたインスタンス グループが存在することを確認します。インスタンス グループを確認するには、テンプレート ファイルのgcp_instance_group名とgcp_zoneゾーンの値を使用して、MIG のプロパティを表示するの手順に沿って操作します。
GKE で Pod が Pending または Error 状態で停止する
この問題は、hf-gke ログに GCPSymphonyResource リソースの作成が示された後、GKE クラスタ内の対応する Pod が Running 状態に到達せず、Pending、ImagePullBackOff、CrashLoopBackOff などのステータスが表示される場合に発生することがあります。
この問題は、無効なコンテナ イメージ名、CPU またはメモリリソースの不足、ボリュームまたはネットワーク設定の誤りなど、Kubernetes クラスタ内で問題が発生した場合に発生します。
この問題を解決するには、kubectl describe を使用してカスタム リソースと Pod の両方のイベントを調べ、根本原因を特定します。
kubectl describe gcpsymphonyresource RESOURCE_NAME
kubectl describe pod POD_NAME
次のように置き換えます。
RESOURCE_NAME: リソースの名前。POD_NAME: Pod の名前。
Kubernetes オペレーターの問題のトラブルシューティング
Kubernetes オペレータは、Symphony Pod のライフサイクルを管理します。以降のセクションでは、オペレーターとこれらのリソースで発生する可能性のある一般的な問題のトラブルシューティングについて説明します。
リソース ステータス フィールドに関する問題を診断する
Kubernetes オペレータは、次の 2 つの主要なリソースタイプを使用して GKE の Symphony ワークロードを管理します。
GCPSymphonyResource（GCPSR）リソースは、Symphony ワークロードのコンピューティング Pod のライフサイクルを管理します。MachineReturnRequest（MRR）リソースは、コンピューティング リソースの返却とクリーンアップを処理します。
次のステータス フィールドを使用して、GCPSymphonyResource リソースの問題を診断します。
phase: リソースの現在のライフサイクル フェーズ。選択肢はPending、Running、WaitingCleanup、Completedです。availableMachines: 使用可能な状態のコンピューティング Pod の数。conditions: タイムスタンプを含む詳細なステータス条件。returnedMachines: 返された Pod のリスト。
次のステータス フィールドを使用して、MachineReturnRequest リソースの問題を診断します。
phase: 返品リクエストの現在のフェーズ。オプションはPending、InProgress、Completed、Failed、PartiallyCompletedです。totalMachines: 返されるマシンの合計数。returnedMachines: 正常に返されたマシンの数。failedMachines: 戻り値に失敗したマシンの数。machineEvents: マシンごとのステータスの詳細。
GCPSymphonyResource リソースが Pending 状態のままになる
この問題は、GCPSymphonyResource リソースが Pending 状態のままで、availableMachines の値が増加しない場合に発生します。
この問題は、以下のいずれかの理由で発生する可能性があります。
- クラスタ内のノード容量が不足している。
- コンテナ イメージの pull に関する問題。
- リソース割り当ての制限。
この問題を解決するには:
Pod のステータスを確認して、イメージの pull またはリソース割り当てに関する問題を特定します。
kubectl describe pods -n gcp-symphony -l symphony.requestId=REQUEST_IDREQUEST_IDは、リクエスト ID に置き換えます。ノードを検査して、十分な容量があることを確認します。
kubectl get nodes -o widePod に
Pendingステータスが表示されることがあります。この問題は通常、Kubernetes クラスタのスケールアップに想定よりも時間がかかる場合に発生します。ノードをモニタリングして、コントロール プレーンがスケールアウトできることを確認します。
Pod は返却されません
この問題は、MachineReturnRequest（MRR）を作成しても、returnedMachines の数が増加しない場合に発生します。
この問題は、次の理由で発生する可能性があります。
- Pod が
Terminating状態で停止する。 - ノードの接続に関する問題がある。
この問題を解決するには:
Terminating状態のまま停止している Pod を確認します。kubectl get pods -n gcp-symphony --field-selector=status.phase=Terminating返品手続きの詳細については、
MachineReturnRequestを説明します。kubectl describe mrr MRR_NAME -n gcp-symphonyMRR_NAMEは、MachineReturnRequestの名前で置き換えます。カスタム リソース オブジェクトを手動で削除します。この削除により、最終的なクリーンアップ ロジックが有効になります。
kubectl delete gcpsymphonyresource RESOURCE_NAMERESOURCE_NAMEは、GCPSymphonyResourceリソースの名前に置き換えます。
MachineReturnRequest で失敗したマシンの数が多い
この問題は、MachineReturnRequest ステータスの failedMachines カウントが 0 より大きい場合に発生します。この問題は、次の理由で発生する可能性があります。
- Pod の削除がタイムアウトしました。
- ノードが使用できない。
この問題を解決するには:
特定のメッセージについては、
MachineReturnRequestステータスのmachineEventsを確認します。kubectl describe mrr MRR_NAME -n gcp-symphonyノード障害イベントまたはコントロール プレーンのパフォーマンスの問題を探します。
すべてのノードのステータスを取得します。
kubectl get nodes -o wide特定のノードを検査します。
kubectl describe node NODE_NAME
Pod が削除されない
この問題は、削除された Pod が Terminating 状態または Error 状態で停止した場合に発生します。
この問題は、次の理由で発生する可能性があります。
- コントロール プレーンまたはオペレーターの過負荷。タイムアウトや API スロットリング イベントが発生する可能性があります。
- 親
GCPSymphonyResourceリソースの手動削除。
この問題を解決するには:
親
GCPSymphonyResourceリソースが引き続き使用可能で、WaitingCleanup状態になっていないことを確認します。kubectl describe gcpsymphonyresource RESOURCE_NAME親
GCPSymphonyResourceリソースがシステムに存在しなくなった場合は、Pod からファイナライザーを手動で削除します。ファイナライザは、Kubernetes が Pod を完全に削除する前に、Symphony オペレーターがクリーンアップ タスクを完了するまで待機するように Kubernetes に指示します。まず、YAML 構成を調べてファイナライザーを見つけます。kubectl get pods -n gcp-symphony -l symphony.requestId=REQUEST_ID -o yamlREQUEST_IDは、Pod に関連付けられたリクエスト ID に置き換えます。出力で、メタデータ セクション内のファイナライザー フィールドを探します。次のような出力が表示されます。
metadata: ... finalizers: - symphony-operator/finalizerPod からファイナライザを手動で削除するには、
kubectl patchコマンドを使用します。kubectl patch pod -n gcp-symphony -l symphony.requestId=REQUEST_ID --type json -p '[{"op": "remove", "path": "/metadata/finalizers", "value": "symphony-operator/finalizer"}]'REQUEST_IDは、Pod に関連付けられたリクエスト ID に置き換えます。
古い Symphony リソースが GKE クラスタから自動的に削除されない
ワークロードが完了して GKE が Pod を停止した後、関連する GCPSymphonyResource オブジェクトと MachineReturnRequest オブジェクトが、想定される 24 時間のクリーンアップ期間よりも長く GKE クラスタに残ります。
この問題は、GCPSymphonyResource オブジェクトに必要な Completed status 条件がない場合に発生します。オペレーターの自動クリーンアップ プロセスは、このステータスに基づいてオブジェクトを削除します。この問題を解決するには、次の手順に沿って操作してください。
問題の
GCPSymphonyResourceリソースの詳細を確認します。kubectl get gcpsr GCPSR_NAME -o yamlGCPSR_NAMEは、この問題が発生しているGCPSymphonyResourceリソースの名前に置き換えます。ステータスが
TrueのタイプCompletedの条件を確認します。status: availableMachines: 0 conditions: - lastTransitionTime: "2025-04-14T14:22:40.855099+00:00" message: GCPSymphonyResource g555dc430-f1a3-46bb-8b69-5c4c481abc25-2pzvc has no pods. reason: NoPods status: "True" # This condition will ensure this type: Completed # custom resource is cleaned up by the operator phase: WaitingCleanup returnedMachines: - name: g555dc430-f1a3-46bb-8b69-5c4c481abc25-2pzvc-pod-0 returnRequestId: 7fd6805f-9a00-41f9-afe9-c38aa35002db returnTime: "2025-04-14T14:22:39.373216+00:00"この条件が
GCPSymphonyResourceの詳細に表示されず、代わりにphase: WaitingCleanupが表示されている場合、Completedイベントは失われています。GCPSymphonyResourceに関連付けられた Pod を確認します。kubectl get pods -l symphony.requestId=REQUEST_IDREQUEST_IDは、リクエスト ID に置き換えます。Pod が存在しない場合は、
GCPSymphonyResourceリソースを安全に削除します。kubectl delete gcpsr GCPSR_NAMEGCPSR_NAMEは、GCPSymphonyResourceの名前で置き換えます。GCPSymphonyResourceを削除する前に Pod が存在していた場合は、Pod を削除する必要があります。Pod がまだ存在する場合は、Pod が削除されないセクションの手順に沿って操作します。
Pod が Symphony クラスタに参加しない
この問題は、Pod が GKE で実行されているにもかかわらず、Symphony クラスタで有効なホストとして表示されない場合に発生します。
この問題は、Pod 内で実行されている Symphony ソフトウェアが Symphony プライマリ ホストに接続して登録できない場合に発生します。この問題は、ネットワーク接続の問題や、コンテナ内の Symphony クライアントの構成ミスが原因で発生することがよくあります。
この問題を解決するには、Pod 内で実行されている Symphony サービスのログを確認します。
SSH または exec を使用して Pod にアクセスし、ログを表示します。
kubectl exec -it POD_NAME -- /bin/bashPOD_NAMEは、Pod の名前に置き換えます。Pod 内に sh がある場合、EGO デーモンと LIM デーモンのログは
$EGO_TOP/kernel/log ディレクトリにあります。$EGO_TOP環境変数は、IBM Spectrum Symphony インストールのルートを参照します。cd $EGO_TOP/kernel/log$EGO_TOP環境変数の値の詳細については、Symphony ホスト ファクトリ サービスの問題をご覧ください。GKE Pod からオンプレミスの Symphony プライマリ Pod への接続をブロックする構成エラーまたはネットワーク エラーのログを確認します。
マシンの返品リクエストが失敗する
この問題は、MachineReturnRequest カスタム リソースを作成したときにスケールイン オペレーション中に発生する可能性がありますが、オブジェクトがスタックし、オペレーターが対応する Symphony Pod を終了しません。
オペレーターのファイナライザー ロジックの障害により、Pod とそれに関連付けられたカスタム リソースをクリーンに削除できません。この問題により、孤立したリソースや不要な費用が発生する可能性があります。
この問題を解決するには、カスタム リソースを手動で削除します。これにより、オペレーターのクリーンアップ ロジックが有効になります。
kubectl delete gcpsymphonyresource RESOURCE_NAME
RESOURCE_NAME は、リソースの名前に置き換えます。