Memecahkan masalah konektor IBM Spectrum Symphony

Dokumen ini membantu Anda menyelesaikan masalah umum terkait integrasi IBM Spectrum Symphony untuk Google Cloud. Secara khusus, dokumen ini memberikan panduan pemecahan masalah untuk layanan host factory IBM Spectrum Symphony, konektor untuk penyedia Compute Engine dan GKE, serta Symphony Operator untuk Kubernetes.

Masalah layanan pabrik host Symphony

Masalah ini terkait dengan layanan factory host Symphony pusat. Anda dapat menemukan file log utama untuk layanan ini di lokasi berikut di Linux:

$EGO_TOP/hostfactory/log/hostfactory.hostname.log

Anda menetapkan variabel lingkungan $EGO_TOP saat memuat variabel lingkungan factory host. Di IBM Spectrum Symphony, $EGO_TOP mengarah ke root penginstalan Enterprise Grid Orchestrator (EGO), yang merupakan pengelola resource inti untuk cluster. Jalur penginstalan default untuk $EGO_TOP di Linux biasanya adalah /opt/ibm/spectrumcomputing.

Cluster tidak menambahkan VM baru untuk workload yang tertunda

Masalah ini terjadi saat antrean Symphony berisi tugas, tetapi host factory gagal menyediakan virtual machine (VM) baru untuk mengelola beban. File log host factory tidak berisi pesan SCALE-OUT.

Masalah ini biasanya terjadi jika pemohon Symphony tidak dikonfigurasi atau diaktifkan dengan benar. Untuk mengatasi masalah ini, periksa status pemohon yang dikonfigurasi untuk memverifikasi bahwa pemohon tersebut diaktifkan dan ada beban kerja yang tertunda.

  1. Cari file konfigurasi pemohon. File biasanya terletak di:

    $HF_TOP/conf/requestors/hostRequestors.json

    Variabel lingkungan $HF_TOP ditentukan di lingkungan Anda saat Anda menggunakan perintah source. Nilai ini adalah jalur ke direktori penginstalan tingkat teratas untuk layanan factory host IBM Spectrum Symphony.

  2. Buka file hostRequestors.json dan temukan entri symAinst. Di bagian tersebut, verifikasi bahwa parameter enabled ditetapkan ke nilai 1 dan daftar penyedia mencakup nama instance penyedia Google Cloud yang dikonfigurasi.

    • Untuk konfigurasi Compute Engine, daftar penyedia harus menampilkan nama penyedia Compute Engine yang Anda buat di Aktifkan instance penyedia selama penginstalan penyedia Compute Engine.
    • Untuk konfigurasi GKE, daftar penyedia harus menampilkan nama penyedia GKE yang Anda buat di Aktifkan instance penyedia selama penginstalan penyedia GKE.

  3. Setelah Anda mengonfirmasi bahwa pemohon symAinst diaktifkan, periksa apakah konsumen memiliki workload tertunda yang memerlukan penskalaan horizontal.

    Melihat daftar semua konsumen dan status beban kerjanya:

    egosh consumer list

  4. Dalam output, cari konsumen yang terkait dengan workload Anda dan verifikasi bahwa workload sedang menunggu. Jika pemohon diaktifkan dan beban kerja tertunda, tetapi layanan factory host tidak memulai permintaan penskalaan, periksa log layanan HostFactory untuk mengetahui error.

Layanan reset ke setelan pabrik host tidak dimulai

Jika layanan pabrik host tidak berjalan, ikuti langkah-langkah berikut untuk menyelesaikan masalah:

  1. Periksa status layanan HostFactory:

    egosh service list

    Pada output, temukan layanan HostFactory dan periksa apakah kolom STATE menampilkan status STARTED.

  2. Jika layanan HostFactory tidak dimulai, mulai ulang:

    egosh service stop HostFactory
egosh service start HostFactory

Error dan logging lainnya

Jika Anda mengalami error lain dengan layanan host factory, tingkatkan detail log untuk mendapatkan log yang lebih mendetail. Caranya, selesaikan langkah-langkah berikut:

  1. Buka file hostfactoryconf.json untuk mengedit. File biasanya berada di:

    $EGO_TOP/hostfactory/conf/

    Untuk mengetahui informasi selengkapnya tentang nilai variabel lingkungan $EGO_TOP, lihat Masalah layanan factory host Symphony.

  2. Perbarui nilai HF_LOGLEVEL dari LOG_INFO menjadi LOG_DEBUG:

    {
  ...
  "HF_LOGLEVEL": "LOG_DEBUG",
  ...
}

  3. Simpan file setelah Anda melakukan perubahan.

  4. Agar perubahan diterapkan, mulai ulang layanan HostFactory:

    egosh service stop HostFactory
egosh service start HostFactory

Setelah Anda memulai ulang, layanan HostFactory akan membuat log yang lebih mendetail, yang dapat Anda gunakan untuk memecahkan masalah yang kompleks. Anda dapat melihat log ini di file log utama factory host, yang terletak di $EGO_TOP/hostfactory/log/hostfactory.hostname.log di Linux.

Masalah penyedia pabrik host

Masalah berikut terjadi dalam skrip penyedia factory host untuk Compute Engine atau Google Kubernetes Engine.

Periksa log penyedia (hf-gce.log atau hf-gke.log) untuk mengetahui pesan error yang mendetail. Lokasi file hf-gce.log dan hf-gke.log ditentukan oleh variabel LOGFILE yang ditetapkan dalam file konfigurasi penyedia di Aktifkan instance penyedia.

Mesin virtual atau pod tidak disediakan

Masalah ini dapat terjadi setelah log penyedia pabrik host menunjukkan panggilan ke skrip requestMachines.sh, tetapi resource tidak muncul di project Google Cloud Anda.

Untuk menyelesaikan masalah ini, ikuti langkah berikut:

  1. Periksa log skrip penyedia (hf-gce.log atau hf-gke.log) untuk melihat pesan error dari Google Cloud API. Lokasi file hf-gce.log dan hf-gke.log ditentukan oleh variabel LOGFILE yang ditetapkan dalam file konfigurasi penyedia di Aktifkan instance penyedia.

  2. Pastikan akun layanan memiliki izin IAM yang benar:

    1. Ikuti petunjuk di Melihat akses saat ini.
    2. Verifikasi bahwa akun layanan memiliki peran IAM Compute Instance Admin (v1) (roles/compute.instanceAdmin.v1) di project. Untuk mengetahui informasi selengkapnya tentang cara memberikan peran, lihat Mengelola akses ke project, folder, dan organisasi.

  3. Untuk memastikan bahwa parameter Compute Engine dalam template host Anda valid, Anda harus memverifikasi hal berikut:

    1. Parameter template host harus ada dalam file gcpgceinstprov_templates.json yang Anda buat saat menyiapkan instance penyedia selama penginstalan penyedia Compute Engine. Parameter yang paling umum untuk divalidasi adalah gcp_zone dan gcp_instance_group.

    2. Pastikan grup instance yang ditetapkan oleh parameter gcp_instance_group ada. Untuk mengonfirmasi grup instance, ikuti petunjuk di Melihat properti MIG, dengan menggunakan nilai nama gcp_instance_group dan zona gcp_zone dari file template.

Pod macet dalam status Pending atau Error di GKE

Masalah ini dapat terjadi setelah log hf-gke menunjukkan bahwa resource GCPSymphonyResource telah dibuat, tetapi pod yang sesuai di cluster GKE tidak pernah mencapai status Running dan mungkin menampilkan status seperti Pending, ImagePullBackOff, atau CrashLoopBackOff.

Masalah ini terjadi jika ada masalah dalam cluster Kubernetes, seperti nama image container yang tidak valid, resource CPU atau memori yang tidak memadai, atau volume atau setelan jaringan yang salah dikonfigurasi.

Untuk mengatasi masalah ini, gunakan kubectl describe untuk memeriksa peristiwa resource kustom dan pod guna mengidentifikasi penyebab utamanya:

kubectl describe gcpsymphonyresource RESOURCE_NAME
kubectl describe pod POD_NAME

Ganti kode berikut:

  • RESOURCE_NAME: nama resource.
  • POD_NAME: nama pod.

Memecahkan masalah operator Kubernetes

Operator Kubernetes mengelola siklus proses pod Symphony. Bagian berikut dapat membantu Anda memecahkan masalah umum yang mungkin Anda alami dengan operator dan resource ini.

Mendiagnosis masalah pada kolom status resource

Operator Kubernetes mengelola workload Symphony di GKE dengan dua jenis resource utama:

  • Resource GCPSymphonyResource (GCPSR) mengelola siklus proses pod komputasi untuk beban kerja Symphony.
  • Resource MachineReturnRequest (MRR) menangani pengembalian dan pembersihan resource komputasi.

Gunakan kolom status ini untuk mendiagnosis masalah pada GCPSymphonyResource resource:

  • phase: Fase siklus proses resource saat ini. Opsinya adalah Pending, Running, WaitingCleanup, atau Completed.
  • availableMachines: Jumlah pod komputasi yang siap.
  • conditions: Kondisi status mendetail dengan stempel waktu.
  • returnedMachines: Daftar pod yang ditampilkan.

Gunakan kolom status ini untuk mendiagnosis masalah pada MachineReturnRequest resource:

  • phase: Tahap permintaan pengembalian saat ini. Opsinya adalah Pending, InProgress, Completed, Failed, atau PartiallyCompleted.
  • totalMachines: Jumlah total mesin yang akan ditampilkan.
  • returnedMachines: Jumlah mesin yang berhasil dikembalikan.
  • failedMachines: Jumlah mesin yang gagal dikembalikan.
  • machineEvents: Detail status per mesin.

Resource GCPSymphonyResource macet dalam status Pending

Masalah ini terjadi saat resource GCPSymphonyResource tetap dalam status Pending dan nilai availableMachines tidak bertambah.

Masalah ini mungkin terjadi karena salah satu alasan berikut:

  • Kapasitas node tidak mencukupi di cluster Anda.
  • Masalah saat menarik image container.
  • Batasan kuota resource.

Untuk menyelesaikan masalah ini:

  1. Periksa status pod untuk mengidentifikasi masalah apa pun terkait penarikan image atau alokasi resource:

    kubectl describe pods -n gcp-symphony -l symphony.requestId=REQUEST_ID

    Ganti REQUEST_ID dengan ID permintaan Anda.

  2. Periksa node untuk memastikan kapasitas yang cukup:

    kubectl get nodes -o wide

  3. Pod mungkin menampilkan status Pending. Masalah ini biasanya terjadi saat cluster Kubernetes perlu di-scale up dan memerlukan waktu lebih lama dari yang diharapkan. Pantau node untuk memastikan bidang kontrol dapat di-scale out.

Pod tidak dikembalikan

Masalah ini terjadi saat Anda membuat MachineReturnRequest (MRR), tetapi jumlah returnedMachines tidak bertambah.

Masalah ini dapat terjadi karena alasan berikut:

  • Pod macet dalam status Terminating.
  • Ada masalah konektivitas node.

Untuk menyelesaikan masalah ini:

  1. Periksa pod yang macet dalam status Terminating:

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

  2. Jelaskan MachineReturnRequest untuk mendapatkan detail tentang proses pengembalian:

    kubectl describe mrr MRR_NAME -n gcp-symphony

    Ganti MRR_NAME dengan nama MachineReturnRequest Anda.

  3. Hapus objek resource kustom secara manual. Penghapusan ini mengaktifkan logika pembersihan akhir:

    kubectl delete gcpsymphonyresource RESOURCE_NAME

    Ganti RESOURCE_NAME dengan nama resource GCPSymphonyResource.

Jumlah mesin yang gagal dalam MachineReturnRequest yang tinggi

Masalah ini terjadi jika jumlah failedMachines dalam MachineReturnRequeststatus lebih besar daripada 0. Masalah ini dapat terjadi karena alasan berikut:

  • Waktu penghapusan pod telah habis.
  • Node tidak tersedia.

Untuk menyelesaikan masalah ini:

  1. Periksa machineEvents di status MachineReturnRequest untuk melihat pesan error tertentu:

    kubectl describe mrr MRR_NAME -n gcp-symphony

  2. Cari peristiwa kegagalan node atau masalah performa bidang kontrol:

    1. Dapatkan status semua node:

      kubectl get nodes -o wide

    2. Memeriksa node tertentu:

      kubectl describe node NODE_NAME

Pod tidak dihapus

Masalah ini terjadi saat pod yang dihapus macet dalam status Terminating atau Error.

Masalah ini dapat terjadi karena alasan berikut:

  • Bidang kontrol atau operator yang kelebihan beban, yang dapat menyebabkan waktu tunggu habis atau peristiwa pembatasan API.
  • Penghapusan manual resource GCPSymphonyResource induk.

Untuk menyelesaikan masalah ini:

  1. Periksa apakah resource GCPSymphonyResource induk masih tersedia dan tidak dalam status WaitingCleanup:

    kubectl describe gcpsymphonyresource RESOURCE_NAME

  2. Jika resource induk GCPSymphonyResource tidak lagi ada di sistem, hapus secara manual finalizer dari pod atau pod. Finalizer memberi tahu Kubernetes untuk menunggu operator Symphony menyelesaikan tugas pembersihannya sebelum Kubernetes menghapus pod sepenuhnya. Pertama, periksa konfigurasi YAML untuk menemukan finalizer:

    kubectl get pods -n gcp-symphony -l symphony.requestId=REQUEST_ID -o yaml

    Ganti REQUEST_ID dengan ID permintaan yang terkait dengan pod.

  3. Pada output, cari kolom finalizer dalam bagian metadata. Anda akan melihat output yang mirip dengan cuplikan ini:

    metadata:
...
finalizers:
-   symphony-operator/finalizer

  4. Untuk menghapus finalizer secara manual dari pod, gunakan perintah 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"}]'

    Ganti REQUEST_ID dengan ID permintaan yang terkait dengan pod.

Resource Symphony lama tidak otomatis dihapus dari cluster GKE

Setelah workload selesai dan GKE menghentikan pod-nya, objek GCPSymphonyResource dan MachineReturnRequest terkait tetap berada di cluster GKE Anda lebih lama dari periode pembersihan 24 jam yang diharapkan.

Masalah ini terjadi saat objek GCPSymphonyResource tidak memiliki kondisi Completed status yang diperlukan. Proses pembersihan otomatis operator bergantung pada status ini untuk menghapus objek. Untuk mengatasi masalah ini, selesaikan langkah-langkah berikut:

  1. Tinjau detail resource GCPSymphonyResource yang dimaksud:

    kubectl get gcpsr GCPSR_NAME -o yaml

    Ganti GCPSR_NAME dengan nama resource GCPSymphonyResource yang mengalami masalah ini.

  2. Tinjau kondisi untuk salah satu jenis Completed dengan status True:

    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"

    Jika kondisi ini tidak terlihat di detail GCPSymphonyResource, tetapi phase: WaitingCleanup ditampilkan, peristiwa Completed telah hilang.

  3. Periksa pod yang terkait dengan GCPSymphonyResource:

    kubectl get pods -l symphony.requestId=REQUEST_ID

    Ganti REQUEST_ID dengan ID permintaan.

  4. Jika tidak ada pod, hapus resource GCPSymphonyResource dengan aman:

    kubectl delete gcpsr GCPSR_NAME

    Ganti GCPSR_NAME dengan nama GCPSymphonyResource Anda.

  5. Jika pod ada sebelum Anda menghapus GCPSymphonyResource, Anda harus menghapusnya. Jika pod masih ada, ikuti langkah-langkah di bagian Pod tidak dihapus.

Pod tidak bergabung dengan cluster Symphony

Masalah ini terjadi saat pod berjalan di GKE, tetapi tidak muncul sebagai host yang valid di cluster Symphony.

Masalah ini terjadi jika software Symphony yang berjalan di dalam pod tidak dapat terhubung dan mendaftar ke host utama Symphony. Masalah ini sering kali disebabkan oleh masalah konektivitas jaringan atau kesalahan konfigurasi klien Symphony dalam penampung.

Untuk mengatasi masalah ini, periksa log layanan Symphony yang berjalan di dalam pod.

  1. Gunakan SSH atau exec untuk mengakses pod dan melihat log:

    kubectl exec -it POD_NAME -- /bin/bash

    Ganti POD_NAME dengan nama pod.

  2. Jika Anda memiliki sh di dalam pod, log untuk daemon EGO dan LIM berada di direktori $EGO_TOP/kernel/log. Variabel lingkungan $EGO_TOP menunjuk ke root penginstalan IBM Spectrum Symphony:

    cd $EGO_TOP/kernel/log

    Untuk mengetahui informasi selengkapnya tentang nilai variabel lingkungan $EGO_TOP, lihat Masalah layanan factory host Symphony.

  3. Periksa log untuk mengetahui error konfigurasi atau jaringan yang memblokir koneksi dari pod GKE ke pod utama Symphony lokal.

Permintaan pengembalian mesin gagal

Masalah ini dapat terjadi selama operasi pengecilan saat Anda membuat resource kustom MachineReturnRequest, tetapi objek macet, dan operator tidak menghentikan pod Symphony yang sesuai.

Kegagalan dalam logika finalizer operator mencegah penghapusan pod dan resource kustom terkaitnya secara bersih. Masalah ini dapat menyebabkan resource yang tidak terkait dan biaya yang tidak perlu.

Untuk mengatasi masalah ini, hapus resource kustom secara manual, yang akan mengaktifkan logika pembersihan operator:

kubectl delete gcpsymphonyresource RESOURCE_NAME

Ganti RESOURCE_NAME dengan nama resource.