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.

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 sesekali di antarmuka pengguna (UI) hybrid Apigee, dan melalui Management API.

Pesan error

Tidak ada pesan error yang 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 tidak dijalankan secara berkala.
Masalah konektivitas jaringan	Mungkin ada masalah konektivitas jaringan antara pod Cassandra di pusat data 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 bisa melihat hasil yang berbeda ketika dipanggil beberapa kali.

   Pada command line, gunakan contoh berikut untuk mendapatkan gcloud kredensial autentikasi, menyetel 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 Key Value Maps (KVM):

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

   Mendapatkan 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 berbeda saat permintaan Management API di atas dijalankan, maka 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

Di deployment hybrid Apigee multi-region, jika semua pod Cassandra tidak terhubung ke Cincin Cassandra, data mungkin tidak dapat direplikasi oleh semua pod Cassandra. Oleh karena itu, tim Manajemen tidak akan menerima set data yang sama untuk kueri yang sama secara konsisten. Lakukan tindakan berikut langkah-langkah 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 cincin Cassandra dan dalam status Up dan 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 cincin Cassandra yang tidak responsif:

   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 ada di DL (Down dan Leaving) . Untuk informasi selengkapnya, lihat status nodetool.

   • Jika ada pod Cassandra dalam status DL (seperti yang terlihat pada contoh output di atas), maka itulah yang menjadi penyebab masalah ini.
   • Saat permintaan dibuat untuk mengambil informasi tentang entity apa pun melalui UI hibrida atau API Manajemen, jika permintaan menemukan salah satu pod Cassandra yang mati, maka Anda tidak akan mendapatkan data apa pun.

Resolusi

Lakukan langkah-langkah yang disediakan di bagian berikut dan pastikan bahwa pod Cassandra di pusat data yang bermasalah terhubung ke pusat data asli seperti yang dijelaskan di Deployment multi-region pada 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 tindakan berikut langkah-langkah untuk menganalisis skenario ini:

Diagnosis

1. Buat pod container klien Cassandra apigee-hybrid-cassandra-client untuk proses debug.
   
2. Tampilkan 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, buat daftar dan 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 key value map:

   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. Membandingkan jumlah kumpulan data yang diperoleh dari semua pod Cassandra.
9. Mengidentifikasi pod Cassandra yang memiliki data yang tidak konsisten.

Resolusi

1. Buat daftar 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 versi hybrid < 1.4.0:

   nodetool repair

   Pada Apigee versi hybrid >= 1.4.0:

   nodetool -u JMX_USERNAME -pw JMX-PASSWORD repair

3. Ikuti kembali bagian diagnosis dan periksa apakah data telah direplikasi ke semua Pod Cassandra secara konsisten.
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 cincin Cassandra. Lakukan langkah-langkah berikut untuk menganalisis skenario ini:

Diagnosis

1. Tampilkan daftar semua pod Cassandra:

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

2. Jalankan perintah curl dan telnet berikut 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 pembatasan {i>firewall<i} atau semacam masalah konektivitas jaringan.

Resolusi

1. Jika deployment hybrid Apigee ini berada di GKE, periksa apakah ada aturan firewall yang ditetapkan untuk memblokir lalu lintas dari satu pusat data ke pusat data yang lain dan menganalisis konektivitas jaringan masalah dengan merujuk ke Ringkasan aturan firewall VPC.
2. Jika deployment hybrid Apigee ini berada di GKE lokal, gunakan jaringan yang relevan tim dan menganalisis masalah konektivitas jaringan.

Harus mengumpulkan informasi diagnostik

Jika masalah berlanjut bahkan setelah mengikuti instruksi di atas, kumpulkan informasi diagnostik, lalu hubungi Google Cloud Customer Care:

1. ID Project 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 Multi-region Hybrid Apigee di GKE dan GKE lokal
• Dokumentasi Kubernetes
• Perintah status nodetool Cassandra