Data yang tidak konsisten/tidak ada yang diamati untuk entity dalam UI hybrid atau melalui Management API

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

Catatan: Dokumen ini hanya berlaku untuk pengguna hybrid Apigee.

Gejala

Pengguna mengamati data yang tidak konsisten atau tidak ada data untuk entity seperti produk API, Aplikasi, Developer, Key Value Maps (KVM), dan Cache secara bergantian di antarmuka pengguna (UI) Apigee Hybrid 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 cincin	Pod Cassandra dari semua pusat data mungkin tidak terhubung ke cincin Cassandra yang umum.
Perbaikan nodetool tidak dijalankan	Perintah nodetool repair mungkin belum dieksekusi secara berkala.
Masalah konektivitas jaringan	Kemungkinan ada masalah konektivitas jaringan antara pod Cassandra di pusat data yang berbeda.

Langkah-langkah diagnosis umum

1. Ambil informasi tentang satu atau beberapa entity 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.

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

   Dapatkan 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"
   

   Dapatkan 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"
   

   Dapatkan Cache:

   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 hybrid Apigee multi-region, jika semua pod Cassandra tidak terhubung ke ring Cassandra yang sama, data mungkin tidak akan direplikasi oleh semua pod Cassandra. Akibatnya, bidang Management 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 versi hybrid < 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"
   

   Pada Apigee versi hybrid >= 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 dari perintah di atas dan verifikasi apakah semua pod Cassandra di semua pusat data terhubung ke ring Cassandra dan dalam status Up and Normal (UN).

   Contoh output cincin 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 dari cincin 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
   

   Perlu diperhatikan bahwa beberapa pod Cassandra dari output di atas memiliki status DL (Down and Leaving). Untuk mengetahui informasi selengkapnya, lihat status nodetool.

   • Jika Anda melihat pod Cassandra dalam status DL (seperti yang terlihat pada contoh output di atas), maka itulah penyebab masalah ini.
   • Saat permintaan dibuat untuk mengambil informasi tentang entity apa pun, baik melalui UI campuran maupun Management API, jika permintaan tersebut mencapai salah satu pod Cassandra yang sedang 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 lokal | Apigee.

Penyebab: Perbaikan nodetool tidak dijalankan

Jika perintah nodetool repair tidak dijalankan secara berkala sebagai tugas pemeliharaan, maka 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. Menampilkan daftar 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. Daftar 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, cantumkan dan buat kueri semua entitas di setiap pusat data menggunakan CQLSH.

   Jika entitas yang tidak konsisten adalah produk API:

   select * from KMS_KEYSPACE.api_product;

   Jika entitas yang tidak konsisten adalah aplikasi (app):

   select * from KMS_KEYSPACE.app;

   Jika entitas 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 entitas 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 kumpulan data yang diperoleh dari semua pod Cassandra.
9. Identifikasi pod Cassandra yang memiliki data yang tidak konsisten.

Resolusi

1. Mencantumkan pod Cassandra dan menghubungkan 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 versi hybrid < 1.4.0:

   nodetool repair

   Pada Apigee versi hybrid >= 1.4.0:

   nodetool -u JMX_USERNAME -pw JMX-PASSWORD repair

3. Ikuti lagi 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 antar-pusat data, data Cassandra mungkin tidak direplikasi secara konsisten ke semua pod Cassandra di lingkaran Cassandra. Lakukan langkah-langkah berikut untuk menganalisis skenario ini:

Diagnosis

1. Menampilkan daftar 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 lainnya menunjukkan bahwa pasti ada pembatasan firewall atau masalah konektivitas jaringan.

Resolusi

1. Jika deployment hybrid Apigee ini berada di GKE, periksa apakah ada aturan firewall yang ditetapkan untuk 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 lokal, bekerjasamalah dengan tim jaringan yang relevan dan analisis masalah konektivitas jaringan.

Harus mengumpulkan informasi diagnostik

Jika masalah terus berlanjut bahkan setelah mengikuti petunjuk di atas, kumpulkan informasi diagnostik berikut, lalu hubungi Dukungan Apigee:

1. Project ID Google Cloud
2. Organisasi hybrid Apigee
3. File overrides.yaml, yang menyamarkan informasi sensitif
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 Apigee Hybrid Multi-region di GKE dan GKE secara lokal
• Dokumentasi Kubernetes
• Perintah status nodetool Cassandra