Data tidak konsisten/tidak ada yang diamati untuk entitas di UI campuran atau melalui Management API

Anda sedang melihat dokumentasi Apigee dan Apigee hybrid.
Lihat dokumentasi Apigee Edge.

Catatan: Dokumen ini hanya berlaku untuk pengguna Apigee hybrid.

Gejala

Pengguna mengamati data yang tidak konsisten atau tidak ada data untuk entitas seperti produk API, Aplikasi, Developer, Key Value Maps (KVM), dan Cache secara berkala di antarmuka pengguna (UI) campuran Apigee dan melalui Management API.

Pesan error

Tidak ada pesan error yang diketahui ditampilkan dalam skenario ini.

Kemungkinan penyebab

Penyebab	Deskripsi
Pod Cassandra tidak terhubung ke ring	Pod Cassandra dari semua pusat data mungkin tidak terhubung ke ring Cassandra umum.
Perbaikan nodetool tidak dijalankan	Perintah nodetool repair mungkin tidak dijalankan secara berkala.
Masalah konektivitas jaringan	Mungkin ada masalah konektivitas jaringan antara pod Cassandra di pusat data yang berbeda.

Langkah-langkah diagnosis umum

1. Ambil informasi tentang satu atau beberapa entitas yang mengalami masalah ini, seperti Produk API, Aplikasi, dan sebagainya, menggunakan Management API dan verifikasi apakah Anda dapat melihat hasil yang berbeda saat dipanggil beberapa kali.

   Di command line, gunakan contoh berikut untuk mendapatkan kredensial autentikasi gcloud, menetapkan variabel lingkungan, dan menjalankan perintah API:

   Mendapatkan produk API:

   TOKEN=$(gcloud auth print-access-token)
   ORG=ORGANIZATION_NAME
   
   curl -i -H "Authorization: Bearer $TOKEN" \
   "https://apigee.googleapis.com/v1/organizations/$ORG/apiproducts"

   Dapatkan Aplikasi:

   TOKEN=$(gcloud auth print-access-token)
   ORG=ORGANIZATION_NAME
   
   curl -i -H "Authorization: Bearer $TOKEN" \
   "https://apigee.googleapis.com/v1/organizations/$ORG/apps"

   Dapatkan Developer:

   TOKEN=$(gcloud auth print-access-token)
   ORG=ORGANIZATION_NAME
   
   curl -i -H "Authorization: Bearer $TOKEN" \
   "https://apigee.googleapis.com/v1/organizations/$ORG/developers"

   Mendapatkan Peta Nilai Kunci (KVM):

   TOKEN=$(gcloud auth print-access-token)
   ORG=ORGANIZATION_NAME
   
   curl -i -H "Authorization: Bearer $TOKEN" \
   "https://apigee.googleapis.com/v1/organizations/$ORG/keyvaluemaps"

   Get Caches:

   TOKEN=$(gcloud auth print-access-token)
   ORG=ORGANIZATION_NAME
   ENV=ENVIRONMENT_NAME
   
   curl -i -H "Authorization: Bearer $TOKEN" \
   "https://apigee.googleapis.com/v1/organizations/$ORG/environments/$ENV/caches"

2. Jika Anda tidak melihat data atau data yang berbeda saat permintaan Management API di atas dijalankan, hal ini menunjukkan bahwa Anda mengamati masalah yang sama seperti yang diamati di UI.

Penyebab: Pod Cassandra tidak terhubung ke pod Cassandra di semua pusat data

Dalam deployment campuran Apigee multi-region, jika semua pod Cassandra tidak terhubung ke ring Cassandra yang sama, data mungkin tidak direplikasi oleh semua pod Cassandra. Akibatnya, bidang manajemen tidak akan menerima set data yang sama untuk kueri yang sama secara konsisten. Lakukan langkah-langkah berikut untuk menganalisis skenario ini:

Diagnosis

1. Mencantumkan pod Cassandra:

# list cassandra pods
kubectl -n apigee get pods -l app=apigee-cassandra

2. Jalankan perintah berikut untuk memeriksa status semua pod Cassandra di setiap pusat data.

   Di Apigee hybrid versi < 1.4.0:

   # check cassandra cluster status
   kubectl -n apigee get pods \
   -l app=apigee-cassandra \
   --field-selector=status.phase=Running \
   -o custom-columns=name:metadata.name --no-headers \
   | xargs -I{} sh -c "echo {}; kubectl -n apigee exec {} -- nodetool status"

   Di Apigee hybrid versi >= 1.4.0:

   # check cassandra cluster status
   kubectl -n apigee get pods \
   -l app=apigee-cassandra \
   --field-selector=status.phase=Running \
   -o custom-columns=name:metadata.name --no-headers \
   | xargs -I{} sh -c "echo {}; kubectl -n apigee exec {} -- nodetool -u jmxuser -pw JMXUSER_PASSWORD status"

3. Periksa hasil perintah di atas dan pastikan apakah semua pod Cassandra di semua pusat data terhubung ke ring Cassandra dan dalam status Up and Normal (UN).

   Contoh output ring Cassandra yang sehat:

   kubectl -n apigee get pods \
   -l app=apigee-cassandra \
   --field-selector=status.phase=Running \
   -o custom-columns=name:metadata.name --no-headers \
   | xargs -I{} sh -c "echo {}; kubectl -n apigee exec {} -- nodetool -u jmxuser -pw iloveapis123 status"
   
   apigee-cassandra-default-0
   Datacenter: dc-1
   ================
   Status=Up/Down
   |/ State=Normal/Leaving/Joining/Moving
   --  Address    Load       Tokens       Owns (effective)  Host ID                               Rack
   UN  10.0.2.18  1.32 MiB   256          100.0%            2e6051fe-e3ed-4858-aed0-ac9be5270e97  ra-1
   UN  10.0.4.10  1.49 MiB   256          100.0%            2396e17f-94fd-4d7d-b55e-35f491a5c1cc  ra-1
   UN  10.0.3.14  1.38 MiB   256          100.0%            579cf76e-7d6d-46c8-8319-b7cd74ee87c8  ra-1
   Datacenter: dc-2
   ================
   Status=Up/Down
   |/ State=Normal/Leaving/Joining/Moving
   --  Address    Load       Tokens       Owns (effective)  Host ID                               Rack
   UN  10.8.1.12  1.31 MiB   256          100.0%            3e9f24bf-2c10-4cfd-8217-5be6245c2b9c  ra-1
   UN  10.8.2.19  1.24 MiB   256          100.0%            1d2e803d-aa31-487b-9503-1e18297efc04  ra-1
   UN  10.8.4.4   1.28 MiB   256          100.0%            d15ffeef-7929-42c2-a3b1-a3feb85a857b  ra-1
   
   apigee-cassandra-default-1
   Datacenter: dc-1
   ================
   Status=Up/Down
   |/ State=Normal/Leaving/Joining/Moving
   --  Address    Load       Tokens       Owns (effective)  Host ID                               Rack
   UN  10.0.2.18  1.32 MiB   256          100.0%            2e6051fe-e3ed-4858-aed0-ac9be5270e97  ra-1
   UN  10.0.4.10  1.49 MiB   256          100.0%            2396e17f-94fd-4d7d-b55e-35f491a5c1cc  ra-1
   UN  10.0.3.14  1.38 MiB   256          100.0%            579cf76e-7d6d-46c8-8319-b7cd74ee87c8  ra-1
   Datacenter: dc-2
   ================
   Status=Up/Down
   |/ State=Normal/Leaving/Joining/Moving
   --  Address    Load       Tokens       Owns (effective)  Host ID                               Rack
   UN  10.8.1.12  1.31 MiB   256          100.0%            3e9f24bf-2c10-4cfd-8217-5be6245c2b9c  ra-1
   UN  10.8.2.19  1.24 MiB   256          100.0%            1d2e803d-aa31-487b-9503-1e18297efc04  ra-1
   UN  10.8.4.4   1.28 MiB   256          100.0%            d15ffeef-7929-42c2-a3b1-a3feb85a857b  ra-1
   
   apigee-cassandra-default-2
   Datacenter: dc-1
   ================
   Status=Up/Down
   |/ State=Normal/Leaving/Joining/Moving
   --  Address    Load       Tokens       Owns (effective)  Host ID                               Rack
   UN  10.0.2.18  1.32 MiB   256          100.0%            2e6051fe-e3ed-4858-aed0-ac9be5270e97  ra-1
   UN  10.0.4.10  1.49 MiB   256          100.0%            2396e17f-94fd-4d7d-b55e-35f491a5c1cc  ra-1
   UN  10.0.3.14  1.38 MiB   256          100.0%            579cf76e-7d6d-46c8-8319-b7cd74ee87c8  ra-1
   Datacenter: dc-2
   ================
   Status=Up/Down
   |/ State=Normal/Leaving/Joining/Moving
   --  Address    Load       Tokens       Owns (effective)  Host ID                               Rack
   UN  10.8.1.12  1.31 MiB   256          100.0%            3e9f24bf-2c10-4cfd-8217-5be6245c2b9c  ra-1
   UN  10.8.2.19  1.24 MiB   256          100.0%            1d2e803d-aa31-487b-9503-1e18297efc04  ra-1
   UN  10.8.4.4   1.28 MiB   256          100.0%            d15ffeef-7929-42c2-a3b1-a3feb85a857b  ra-1

   Contoh output ring Cassandra yang tidak sehat:

   kubectl -n apigee get pods \
   -l app=apigee-cassandra \
   --field-selector=status.phase=Running \
   -o custom-columns=name:metadata.name --no-headers \
   | xargs -I{} sh -c "echo {}; kubectl -n apigee exec {} -- nodetool -u jmxuser -pw iloveapis123 status"
   
   apigee-cassandra-default-0
   Datacenter: dc-1
   ================
   Status=Up/Down
   |/ State=Normal/Leaving/Joining/Moving
   --  Address    Load       Tokens       Owns (effective)  Host ID                               Rack
   UN  10.0.2.18  1.32 MiB   256          100.0%            2e6051fe-e3ed-4858-aed0-ac9be5270e97  ra-1
   DL  10.0.4.10  1.49 MiB   256          100.0%            2396e17f-94fd-4d7d-b55e-35f491a5c1cc  ra-1
   DL  10.0.3.14  1.38 MiB   256          100.0%            579cf76e-7d6d-46c8-8319-b7cd74ee87c8  ra-1
   Datacenter: dc-2
   ================
   Status=Up/Down
   |/ State=Normal/Leaving/Joining/Moving
   --  Address    Load       Tokens       Owns (effective)  Host ID                               Rack
   UN  10.8.1.12  1.31 MiB   256          100.0%            3e9f24bf-2c10-4cfd-8217-5be6245c2b9c  ra-1
   UN  10.8.2.19  1.24 MiB   256          100.0%            1d2e803d-aa31-487b-9503-1e18297efc04  ra-1
   DL  10.8.4.4   1.28 MiB   256          100.0%            d15ffeef-7929-42c2-a3b1-a3feb85a857b  ra-1
   
   apigee-cassandra-default-1
   Datacenter: dc-1
   ================
   Status=Up/Down
   |/ State=Normal/Leaving/Joining/Moving
   --  Address    Load       Tokens       Owns (effective)  Host ID                               Rack
   UN  10.0.2.18  1.32 MiB   256          100.0%            2e6051fe-e3ed-4858-aed0-ac9be5270e97  ra-1
   UN  10.0.4.10  1.49 MiB   256          100.0%            2396e17f-94fd-4d7d-b55e-35f491a5c1cc  ra-1
   UN  10.0.3.14  1.38 MiB   256          100.0%            579cf76e-7d6d-46c8-8319-b7cd74ee87c8  ra-1
   Datacenter: dc-2
   ================
   Status=Up/Down
   |/ State=Normal/Leaving/Joining/Moving
   --  Address    Load       Tokens       Owns (effective)  Host ID                               Rack
   UN  10.8.1.12  1.31 MiB   256          100.0%            3e9f24bf-2c10-4cfd-8217-5be6245c2b9c  ra-1
   UN  10.8.2.19  1.24 MiB   256          100.0%            1d2e803d-aa31-487b-9503-1e18297efc04  ra-1
   UN  10.8.4.4   1.28 MiB   256          100.0%            d15ffeef-7929-42c2-a3b1-a3feb85a857b  ra-1
   
   apigee-cassandra-default-2
   Datacenter: dc-1
   ================
   Status=Up/Down
   |/ State=Normal/Leaving/Joining/Moving
   --  Address    Load       Tokens       Owns (effective)  Host ID                               Rack
   UN  10.0.2.18  1.32 MiB   256          100.0%            2e6051fe-e3ed-4858-aed0-ac9be5270e97  ra-1
   UN  10.0.4.10  1.49 MiB   256          100.0%            2396e17f-94fd-4d7d-b55e-35f491a5c1cc  ra-1
   UN  10.0.3.14  1.38 MiB   256          100.0%            579cf76e-7d6d-46c8-8319-b7cd74ee87c8  ra-1
   Datacenter: dc-2
   ================
   Status=Up/Down
   |/ State=Normal/Leaving/Joining/Moving
   --  Address    Load       Tokens       Owns (effective)  Host ID                               Rack
   UN  10.8.1.12  1.31 MiB   256          100.0%            3e9f24bf-2c10-4cfd-8217-5be6245c2b9c  ra-1
   UN  10.8.2.19  1.24 MiB   256          100.0%            1d2e803d-aa31-487b-9503-1e18297efc04  ra-1
   UN  10.8.4.4   1.28 MiB   256          100.0%            d15ffeef-7929-42c2-a3b1-a3feb85a857b  ra-1

   Perhatikan bahwa beberapa pod Cassandra dari output di atas berada dalam status DL (Down and Leaving). Untuk informasi selengkapnya, lihat status nodetool.

   • Jika Anda melihat pod Cassandra dalam status DL (seperti yang terlihat pada contoh output di atas), hal itu akan menjadi penyebab masalah ini.
   • Saat permintaan dibuat untuk mengambil informasi tentang entitas apa pun melalui UI campuran atau Management API, jika permintaan tersebut menabrak pod Cassandra yang tidak aktif, Anda tidak akan mendapatkan data apa pun.

Resolusi

Lakukan langkah-langkah yang diberikan di bagian berikut dan pastikan pod Cassandra di pusat data yang bermasalah terhubung ke pusat data asli seperti yang dijelaskan dalam Deployment multi-region di GKE dan GKE on-prem | Apigee.

Penyebab: Reparasi nodetool tidak dijalankan

Jika perintah nodetool repair tidak dijalankan secara berkala sebagai tugas pemeliharaan, ada kemungkinan data yang tidak konsisten di seluruh pod Cassandra. Lakukan langkah-langkah berikut untuk menganalisis skenario ini:

Diagnosis

1. Buat pod penampung klien Cassandra apigee-hybrid-cassandra-client untuk proses debug.
   
2. Cantumkan semua pod Cassandra:

   # list cassandra pods
   kubectl -n=apigee get pods -l app=apigee-cassandra

3. Hubungkan ke salah satu pod Cassandra menggunakan CQLSH:

   cqlsh apigee-cassandra-default-0.apigee-cassandra-default.apigee.svc.cluster.local -u ddl_user --ssl

4. Mencantumkan keyspaces:

   SELECT * from system_schema.keyspaces;

   Contoh output:

   ddl_user@cqlsh> SELECT keyspace_name from system_schema.keyspaces;
   
    keyspace_name
   -----------------------------
                    system_auth
    cache_PROJECT_ID_hybrid
                  system_schema
      kms_PROJECT_ID_hybrid
      kvm_PROJECT_ID_hybrid
      rtc_PROJECT_ID_hybrid
             system_distributed
                         system
                         perses
                  system_traces
    quota_PROJECT_ID_hybrid
   
   (11 rows)

5. Identifikasi keyspaces dari hasil di atas, buat daftar, dan buat kueri semua entity di setiap pusat data menggunakan CQLSH.

   Jika entity yang tidak konsisten adalah produk API:

   select * from KMS_KEYSPACE.api_product;

   Jika entity yang tidak konsisten adalah aplikasi (app):

   select * from KMS_KEYSPACE.app;

   Jika entity yang tidak konsisten adalah developer:

   select * from KMS_KEYSPACE.developer;

   Jika entity yang tidak konsisten adalah peta nilai kunci:

   select * from KVM_KEYSPACE.kvm_map_entry;

   Jika entity yang tidak konsisten adalah cache:

   select * from CACHE_KEYSPACE.cache_map_entry;

6. Catat jumlah kumpulan data dari output setiap kueri di atas.
7. Ulangi langkah-langkah di atas untuk setiap pod Cassandra di semua pusat data.
8. Bandingkan jumlah data yang diperoleh dari semua pod Cassandra.
9. Identifikasi pod Cassandra yang memiliki data yang tidak konsisten.

Resolusi

1. Cantumkan pod Cassandra dan hubungkan ke pod Cassandra tertentu yang memiliki data yang tidak konsisten:

   # list cassandra pods
   kubectl -n=apigee get pods -l app=apigee-cassandra
   
   # connect to one cassandra pod
   kubectl -n=apigee exec -it apigee-cassandra-default-0 bash

2. Jalankan perintah nodetool repair di setiap pod Cassandra di setiap pusat data:

   Di Apigee hybrid versi < 1.4.0:

   nodetool repair

   Di Apigee hybrid versi >= 1.4.0:

   nodetool -u JMX_USERNAME -pw JMX-PASSWORD repair

3. Ikuti kembali bagian diagnosis dan verifikasi apakah data telah direplikasi ke semua pod Cassandra secara konsisten atau tidak.
4. Ulangi langkah-langkah di atas untuk semua pod Cassandra yang memiliki data yang tidak konsisten.

Penyebab: Masalah konektivitas jaringan

Jika ada masalah konektivitas jaringan di antara pusat data, data Cassandra mungkin tidak direplikasi secara konsisten ke semua pod Cassandra dalam ring Cassandra. Lakukan langkah-langkah berikut untuk menganalisis skenario ini:

Diagnosis

1. Cantumkan semua pod Cassandra:

   # list cassandra pods
   kubectl -n=apigee get pods -l app=apigee-cassandra

2. Jalankan perintah curl berikut dan telnet ke pod Cassandra pertama di pusat data kedua (dc-2) dari pod Cassandra pertama di pusat data pertama (dc-1) menggunakan port 7001:

     kubectl -n apigee exec -it apigee-cassandra-default-0 bash -- curl -v telnet://DC_2_APIGEE_CASSANDRA_DEFAULT_0_POD_IP:7001

3. Jika telnet berhasil, output yang mirip dengan berikut akan ditampilkan:

   * Rebuilt URL to: telnet://10.0.4.10:7001/
   *   Trying 10.0.4.10...
   * TCP_NODELAY set
   * Connected to 10.0.4.10 (10.0.4.10) port 7001 (#0)

4. Jika tidak, error yang mirip dengan berikut akan ditampilkan:

   * Rebuilt URL to: telnet://10.0.4.10:7001/
   *   Trying 10.0.4.10...
   * TCP_NODELAY set
   * connect to 10.0.4.10 port 7001 failed: Connection refused
   * Failed to connect to 10.0.4.10 port 7001: Connection refused
   * Closing connection 0
   curl: (7) Failed to connect to 10.0.4.10 port 7001: Connection refused

   Kegagalan konektivitas dari pod Cassandra di satu pusat data ke pod Cassandra di pusat data lain menunjukkan bahwa harus ada batasan firewall atau semacam masalah konektivitas jaringan.

Resolusi

1. Jika deployment campuran Apigee ini berada di GKE, periksa apakah ada aturan firewall yang ditetapkan yang memblokir traffic dari satu pusat data ke pusat data lainnya dan analisis masalah konektivitas jaringan dengan melihat Ringkasan aturan firewall VPC.
2. Jika deployment hybrid Apigee ini berada di GKE on-prem, hubungi tim jaringan yang relevan dan analisis masalah konektivitas jaringan.

Harus mengumpulkan informasi diagnostik

Jika masalah berlanjut meskipun setelah mengikuti petunjuk di atas, kumpulkan informasi diagnostik berikut, lalu hubungi Layanan Pelanggan Google Cloud:

1. ID Project Google Cloud
2. Organisasi Apigee hybrid
3. File overrides.yaml, yang menyamarkan informasi sensitif apa pun
4. Status pod Kubernetes di semua namespace:

   kubectl get pods -A > kubectl-pod-status`date +%Y.%m.%d_%H.%M.%S`.txt

5. cluster-info dump kubernetes:

   # generate kubernetes cluster-info dump
   kubectl cluster-info dump -A --output-directory=/tmp/kubectl-cluster-info-dump
   
   # zip kubernetes cluster-info dump
   zip -r kubectl-cluster-info-dump`date +%Y.%m.%d_%H.%M.%S`.zip /tmp/kubectl-cluster-info-dump/*

Referensi

• Deployment Multi-region Apigee Hybrid di GKE dan GKE on-prem
• Dokumentasi Kubernetes
• Perintah status nodetool Cassandra