IBM Spectrum Symphony 커넥터 문제 해결

이 문서에서는 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.json
```
$HF_TOP 환경 변수는 source 명령어를 사용할 때 환경에 정의됩니다. 이 값은 IBM Spectrum Symphony 호스트 팩토리 서비스의 최상위 설치 디렉터리 경로입니다.
hostRequestors.json 파일을 열고 symAinst 항목을 찾습니다. 이 섹션에서 enabled 매개변수가 1 값으로 설정되어 있고 제공업체 목록에 구성된 Google Cloud 제공업체 인스턴스의 이름이 포함되어 있는지 확인합니다.
- Compute Engine 구성의 경우 공급자 목록에 Compute Engine 공급자 설치 중에 공급자 인스턴스 사용 설정에서 만든 Compute Engine 공급자의 이름이 표시되어야 합니다.
- GKE 구성의 경우 공급자 목록에 GKE 공급자 설치 중에 공급자 인스턴스 사용 설정에서 만든 GKE 공급자의 이름이 표시되어야 합니다.
symAinst 요청자가 사용 설정되어 있는지 확인한 후 소비자에 스케일 아웃이 필요한 대기 중인 워크로드가 있는지 확인합니다.

모든 소비자와 워크로드 상태 목록을 확인합니다.
```
egosh consumer list
```
출력에서 워크로드와 연결된 소비자를 찾아 워크로드가 대기 중인지 확인합니다. 요청자가 사용 설정되어 있고 워크로드가 대기 중이지만 호스트 팩토리 서비스가 스케일 아웃 요청을 시작하지 않으면 호스트 팩토리 서비스 로그에서 오류를 확인하세요.

호스트 팩토리 서비스가 시작되지 않음

호스트 팩토리 서비스가 실행되지 않으면 다음 단계에 따라 문제를 해결하세요.

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 변수에 의해 결정됩니다.

가상 머신 또는 포드가 프로비저닝되지 않음

이 문제는 호스트 팩토리 제공업체 로그에 requestMachines.sh 스크립트 호출이 표시되지만 리소스가 Google Cloud프로젝트에 표시되지 않는 경우에 발생할 수 있습니다.

이 문제를 해결하려면 다음 단계를 따르세요.

Google Cloud API의 오류 메시지가 있는지 제공업체 스크립트 로그 (hf-gce.log 또는 hf-gke.log)를 확인합니다. hf-gce.log 및 hf-gke.log 파일의 위치는 제공자 인스턴스 사용 설정의 제공자 구성 파일에 설정된 LOGFILE 변수에 의해 결정됩니다.
서비스 계정에 올바른 IAM 권한이 있는지 확인합니다.
1. 현재 액세스 권한 보기의 안내를 따릅니다.
2. 서비스 계정에 프로젝트에 대한 Compute 인스턴스 관리자(v1)(roles/compute.instanceAdmin.v1) IAM 역할이 있는지 확인합니다. 역할 부여 방법에 대한 자세한 내용은 프로젝트, 폴더, 조직에 대한 액세스 관리를 참고하세요.
호스트 템플릿의 Compute Engine 매개변수가 유효한지 확인하려면 다음을 확인해야 합니다.
1. 호스트 템플릿 매개변수는 Compute Engine 제공자 설치 중에 제공자 인스턴스를 설정할 때 만든 gcpgceinstprov_templates.json 파일에 있어야 합니다. 가장 일반적인 검증 매개변수는 gcp_zone 및 gcp_instance_group입니다.
2. gcp_instance_group 매개변수로 설정된 인스턴스 그룹이 있는지 확인합니다. 인스턴스 그룹을 확인하려면 템플릿 파일의 gcp_instance_group 이름과 gcp_zone 영역 값을 사용하여 MIG의 속성 보기의 안내를 따르세요.

GKE에서 포드가 `Pending` 또는 `Error` 상태로 멈춤

이 문제는 hf-gke 로그에 GCPSymphonyResource 리소스가 생성된 것으로 표시되지만 GKE 클러스터의 해당 포드가 Running 상태에 도달하지 않고 Pending, ImagePullBackOff 또는 CrashLoopBackOff와 같은 상태가 표시될 수 있습니다.

이 문제는 잘못된 컨테이너 이미지 이름, CPU 또는 메모리 리소스 부족, 잘못 구성된 볼륨 또는 네트워크 설정과 같은 Kubernetes 클러스터 내에 문제가 있는 경우 발생합니다.

이 문제를 해결하려면 kubectl describe를 사용하여 맞춤 리소스와 포드의 이벤트를 모두 검사하여 근본 원인을 파악하세요.

kubectl describe gcpsymphonyresource RESOURCE_NAME
kubectl describe pod POD_NAME

다음을 바꿉니다.

RESOURCE_NAME: 리소스 이름
POD_NAME: 포드의 이름입니다.

Kubernetes 운영자 문제 해결

Kubernetes 연산자는 Symphony 포드의 수명 주기를 관리합니다. 다음 섹션은 연산자 및 이러한 리소스와 관련하여 발생할 수 있는 일반적인 문제를 해결하는 데 도움이 됩니다.

리소스 상태 필드 문제 진단

Kubernetes 연산자는 다음 두 가지 기본 리소스 유형을 사용하여 GKE에서 Symphony 워크로드를 관리합니다.

GCPSymphonyResource (GCPSR) 리소스는 Symphony 워크로드의 컴퓨팅 포드 수명 주기를 관리합니다.
MachineReturnRequest (MRR) 리소스는 컴퓨팅 리소스의 반환 및 정리를 처리합니다.

다음 상태 필드를 사용하여 GCPSymphonyResource 리소스의 문제를 진단합니다.

phase: 리소스의 현재 수명 주기 단계입니다. 옵션은 Pending, Running, WaitingCleanup 또는 Completed입니다.
availableMachines: 준비된 컴퓨팅 포드 수입니다.
conditions: 타임스탬프가 포함된 자세한 상태 조건입니다.
returnedMachines: 반환된 포드 목록입니다.

다음 상태 필드를 사용하여 MachineReturnRequest 리소스의 문제를 진단합니다.

phase: 반품 요청의 현재 단계입니다. 옵션은 Pending, InProgress, Completed, Failed 또는 PartiallyCompleted입니다.
totalMachines: 반환할 총 머신 수입니다.
returnedMachines: 반환에 성공한 머신 수입니다.
failedMachines: 반환에 실패한 머신 수입니다.
machineEvents: 머신별 상태 세부정보입니다.

`GCPSymphonyResource` 리소스가 `Pending` 상태로 멈춤

이 문제는 GCPSymphonyResource 리소스가 Pending 상태로 유지되고 availableMachines 값이 증가하지 않는 경우 발생합니다.

이 문제는 다음 이유 중 하나로 발생할 수 있습니다.

클러스터의 노드 용량이 부족합니다.
컨테이너 이미지를 가져오는 데 문제가 있습니다.
리소스 할당량 제한입니다.

이 문제를 해결하려면 다음 안내를 따르세요.

포드 상태를 확인하여 이미지 가져오기 또는 리소스 할당 문제를 식별합니다.
```
kubectl describe pods -n gcp-symphony -l symphony.requestId=REQUEST_ID
```
REQUEST_ID를 요청 ID로 바꿉니다.
노드를 검사하여 용량이 충분한지 확인합니다.
```
kubectl get nodes -o wide
```
포드에 Pending 상태가 표시될 수 있습니다. 이 문제는 일반적으로 Kubernetes 클러스터를 확장해야 하는데 예상보다 오래 걸릴 때 발생합니다. 컨트롤 플레인이 확장될 수 있도록 노드를 모니터링합니다.

Pod가 반환되지 않음

이 문제는 MachineReturnRequest (MRR)를 만들었지만 returnedMachines 수가 증가하지 않는 경우 발생합니다.

이 문제는 다음과 같은 이유로 발생할 수 있습니다.

포드가 Terminating 상태로 멈춰 있습니다.
노드 연결 문제가 있습니다.

이 문제를 해결하려면 다음 안내를 따르세요.

Terminating 상태에서 멈춘 포드를 확인합니다.

kubectl get pods -n gcp-symphony --field-selector=status.phase=Terminating

반품 절차에 대한 세부정보를 확인하려면 MachineReturnRequest를 설명하세요.
```
kubectl describe mrr MRR_NAME -n gcp-symphony
```
MRR_NAME을 MachineReturnRequest의 이름으로 바꿉니다.
커스텀 리소스 객체를 수동으로 삭제합니다. 이 삭제는 최종 정리 로직을 활성화합니다.
```
kubectl delete gcpsymphonyresource RESOURCE_NAME
```
RESOURCE_NAME을 GCPSymphonyResource 리소스 이름으로 바꿉니다.

`MachineReturnRequest`에서 실패한 머신 수가 많음

이 문제는 MachineReturnRequest 상태의 failedMachines 개수가 0보다 큰 경우 발생합니다. 이 문제는 다음과 같은 이유로 발생할 수 있습니다.

포드 삭제 시간이 초과되었습니다.
노드를 사용할 수 없습니다.

이 문제를 해결하려면 다음 안내를 따르세요.

MachineReturnRequest 상태에서 machineEvents를 확인하여 특정 오류 메시지를 확인합니다.
```
kubectl describe mrr MRR_NAME -n gcp-symphony
```
노드 장애 이벤트 또는 컨트롤 플레인 성능 문제를 확인합니다.
1. 모든 노드의 상태를 가져옵니다.
```
kubectl get nodes -o wide
```
2. 특정 노드를 검사합니다.
```
kubectl describe node NODE_NAME
```

포드가 삭제되지 않음

이 문제는 삭제된 포드가 Terminating 또는 Error 상태로 멈춰 있을 때 발생합니다.

이 문제는 다음과 같은 이유로 발생할 수 있습니다.

컨트롤 플레인 또는 작업자가 과부하되어 시간 초과 또는 API 제한 이벤트가 발생할 수 있습니다.
상위 GCPSymphonyResource 리소스의 수동 삭제

이 문제를 해결하려면 다음 안내를 따르세요.

상위 GCPSymphonyResource 리소스가 여전히 사용 가능하고 WaitingCleanup 상태가 아닌지 확인합니다.
```
kubectl describe gcpsymphonyresource RESOURCE_NAME
```
상위 GCPSymphonyResource 리소스가 더 이상 시스템에 없으면 포드에서 파이널라이저를 수동으로 삭제합니다. 파이널라이저는 Kubernetes가 포드를 완전히 삭제하기 전에 Symphony 연산자가 정리 작업을 완료할 때까지 기다리도록 Kubernetes에 지시합니다. 먼저 YAML 구성을 검사하여 파이널라이저를 찾습니다.
```
kubectl get pods -n gcp-symphony -l symphony.requestId=REQUEST_ID -o yaml
```
REQUEST_ID를 포드와 연결된 요청 ID로 바꿉니다.
출력의 메타데이터 섹션에서 파이널라이저 필드를 확인합니다. 다음 스니펫과 비슷한 출력이 표시됩니다.
```
metadata:
...
finalizers:
-   symphony-operator/finalizer
```

포드에서 파이널라이저를 수동으로 삭제하려면 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를 포드와 연결된 요청 ID로 바꿉니다.

이전 Symphony 리소스가 GKE 클러스터에서 자동으로 삭제되지 않음

워크로드가 완료되고 GKE가 포드를 중지한 후 연결된 GCPSymphonyResource 및 MachineReturnRequest 객체가 예상되는 24시간 정리 기간보다 오래 GKE 클러스터에 남아 있습니다.

이 문제는 GCPSymphonyResource 객체에 필수 Completed status 조건이 없는 경우 발생합니다. 연산자의 자동 정리 프로세스는 이 상태에 따라 객체를 삭제합니다. 이 문제를 해결하려면 다음 단계를 완료하세요.

문제가 되는 GCPSymphonyResource 리소스의 세부정보를 검토합니다.
```
kubectl get gcpsr GCPSR_NAME -o yaml
```
GCPSR_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와 연결된 포드를 확인합니다.
```
kubectl get pods -l symphony.requestId=REQUEST_ID
```
REQUEST_ID를 요청 ID로 바꿉니다.
포드가 없는 경우 GCPSymphonyResource 리소스를 안전하게 삭제합니다.
```
kubectl delete gcpsr GCPSR_NAME
```
GCPSR_NAME을 GCPSymphonyResource의 이름으로 바꿉니다.
GCPSymphonyResource를 삭제하기 전에 포드가 있었다면 포드를 삭제해야 합니다. 포드가 여전히 있으면 포드가 삭제되지 않음 섹션의 단계를 따르세요.

포드가 Symphony 클러스터에 참여하지 않음

이 문제는 포드가 GKE에서 실행되지만 Symphony 클러스터에 유효한 호스트로 표시되지 않는 경우 발생합니다.

이 문제는 포드 내에서 실행되는 Symphony 소프트웨어가 Symphony 기본 호스트에 연결하고 등록할 수 없는 경우에 발생합니다. 이 문제는 컨테이너 내에서 네트워크 연결 문제 또는 Symphony 클라이언트의 잘못된 구성으로 인해 발생하는 경우가 많습니다.

이 문제를 해결하려면 포드 내에서 실행되는 Symphony 서비스의 로그를 확인하세요.

SSH 또는 exec를 사용하여 포드에 액세스하고 로그를 확인합니다.
```
kubectl exec -it POD_NAME -- /bin/bash
```
POD_NAME을 포드의 이름으로 바꿉니다.
포드 내에 sh가 있는 경우 EGO 및 LIM 데몬의 로그는 $EGO_TOP/kernel/log 디렉터리에 있습니다. $EGO_TOP 환경 변수는 IBM Spectrum Symphony 설치의 루트를 가리킵니다.
```
cd $EGO_TOP/kernel/log
```
$EGO_TOP 환경 변수의 값에 대한 자세한 내용은 Symphony 호스트 팩토리 서비스 문제를 참고하세요.
GKE 포드에서 온프레미스 Symphony 기본 포드로의 연결을 차단하는 구성 또는 네트워크 오류의 로그를 검사합니다.

기기 반품 요청이 실패함

이 문제는 MachineReturnRequest 커스텀 리소스를 만들 때 스케일 인 작업 중에 발생할 수 있지만 객체가 멈추고 작업자가 해당 Symphony 포드를 종료하지 않습니다.

작업자의 파이널라이저 로직에 오류가 있으면 포드와 연결된 커스텀 리소스가 완전히 삭제되지 않습니다. 이 문제로 인해 고아 리소스가 발생하고 불필요한 비용이 발생할 수 있습니다.

이 문제를 해결하려면 커스텀 리소스를 수동으로 삭제하여 연산자의 정리 로직을 활성화해야 합니다.

kubectl delete gcpsymphonyresource RESOURCE_NAME

RESOURCE_NAME을 리소스 이름으로 바꿉니다.

IBM Spectrum Symphony 커넥터 문제 해결 컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.

Symphony 호스트 팩토리 서비스 문제

클러스터에서 대기 중인 워크로드에 새 VM을 추가하지 않음

호스트 팩토리 서비스가 시작되지 않음

기타 오류 및 로깅

호스트 팩토리 제공업체 문제

가상 머신 또는 포드가 프로비저닝되지 않음

GKE에서 포드가 Pending 또는 Error 상태로 멈춤

Kubernetes 운영자 문제 해결

리소스 상태 필드 문제 진단

GCPSymphonyResource 리소스가 Pending 상태로 멈춤

Pod가 반환되지 않음

MachineReturnRequest에서 실패한 머신 수가 많음

포드가 삭제되지 않음

이전 Symphony 리소스가 GKE 클러스터에서 자동으로 삭제되지 않음

포드가 Symphony 클러스터에 참여하지 않음

기기 반품 요청이 실패함

IBM Spectrum Symphony 커넥터 문제 해결

GKE에서 포드가 `Pending` 또는 `Error` 상태로 멈춤

`GCPSymphonyResource` 리소스가 `Pending` 상태로 멈춤

`MachineReturnRequest`에서 실패한 머신 수가 많음