Halaman ini diterjemahkan oleh Cloud Translation API.

Error Layanan Peering VPC 503 Tidak Tersedia dengan TARGET_CONNECT_TIMEOUT

Anda sedang melihat dokumentasi Apigee dan Apigee Hybrid.
Tidak ada dokumentasi Apigee Edge yang setara untuk topik ini.

Gejala

Masalah ini muncul sebagai error "503 - Service Tidak Tersedia" di API Monitoring, Debug, atau alat lainnya. Alasan "TARGET_CONNECT_TIMEOUT" menunjukkan waktu tunggu koneksi habis antara instance Apigee dan target saat menggunakan Peering VPC.

Error tidak boleh sama dengan error waktu tunggu lain, seperti 504 Gateway Timeout.

Pesan Kesalahan

Ini adalah error umum dalam sesi Debug atau payload respons. Harap perhatikan alasannya: TARGET_CONNECT_TIMEOUT.

{"fault":{"faultstring":"The Service is temporarily unavailable",
"detail":{"errorcode":"messaging.adaptors.http.flow.ServiceUnavailable",
"reason":"TARGET_CONNECT_TIMEOUT"}}}

Kemungkinan Penyebab

Perhatikan bahwa penyebab ini khusus untuk penyiapan Apigee dengan Peering VPC. Lihat Opsi jaringan Apigee. Jika targetnya adalah PSC (Lampiran Endpoint), lihat playbook PSC.

Penyebab	Deskripsi
Kesalahan konfigurasi rute	Rute target tidak diekspor ke peering dengan instance Apigee.
Masalah konektivitas pada target	Target tidak selalu dapat menerima koneksi TCP.
Pemberian izin IP pada target dengan beberapa atau semua IP NAT Apigee tidak ditambahkan	Tidak semua IP NAT Apigee diizinkan pada target.
Kehabisan port IP NAT	Port NAT yang diakomodasi tidak cukup untuk lalu lintas data.
Nilai connect.timeout.millis ditetapkan terlalu rendah	Setelan waktu tunggu koneksi terlalu rendah di sisi Apigee.

Langkah Diagnosis Umum

Debug adalah alat penting untuk menangkap dan mengevaluasi detail masalah berikut:

Total durasi permintaan. Biasanya perlu waktu tiga detik (default connect.timeout.millis) hingga waktu tunggu koneksi terjadi. Jika Anda melihat durasi yang lebih rendah, periksa konfigurasi Endpoint Target.
Nama host dan alamat IP target. Alamat IP yang salah muncul mungkin menunjukkan masalah terkait DNS. Anda mungkin juga melihat korelasi antara IP target yang berbeda dan masalahnya.
Frekuensi. Pendekatan yang berbeda diperlukan, bergantung pada apakah masalah tersebut sesekali atau terus-menerus.

Penyebab: Kesalahan konfigurasi rute

Diagnosis

Jika masalah berlanjut, meskipun dimulai baru-baru ini, masalah tersebut mungkin disebabkan oleh kesalahan konfigurasi rute.

Hal ini dapat memengaruhi target internal (dirutekan dalam VPC yang di-peering) dan eksternal (internet).

Pertama, identifikasi alamat IP target yang di-resolve dari instance Apigee. Salah satu metodenya adalah menggunakan sesi Debug. Di Debug, buka AnalyticsPublisher (atau AX di Debug Klasik):

Cari nilai target.ip di sisi kanan layar.

Dalam contoh ini, IP-nya adalah 10.2.0.1. Karena rentang ini bersifat pribadi, diperlukan tindakan perutean tertentu untuk memastikan Apigee dapat mencapai target.

Perlu diperhatikan bahwa jika target berada di internet, Anda harus mengikuti langkah ini jika Kontrol Layanan VPC diaktifkan untuk Apigee. Hal ini akan mencegah konektivitas internet.
Perhatikan region tempat instance Apigee yang terpengaruh di-deploy. Di UI Apigee di Konsol Cloud, klik Instances. Di kolom Lokasi, Anda dapat menemukan region yang tepat dari instance.
Pada project yang di-peering dengan Apigee, buka bagian Jaringan VPC -> peering jaringan VPC di UI. Perhatikan bahwa jika Anda menggunakan VPC Bersama, langkah-langkah tersebut harus dilakukan di project host, bukan project Apigee.
Klik servicenetworking-googleapis-com, pilih tab RUTE YANG DIEKSPOR, lalu filter menurut region yang diperoleh di Langkah 2.

Contoh ini menunjukkan rute 10.2.0.0/24 sebagai rute yang diekspor dan menyertakan IP target contoh 10.2.0.1. Jika Anda tidak melihat rute yang sesuai dengan target, itulah penyebab masalah.
Catatan: Jika targetnya bersifat eksternal, rute biasanya tidak ada di Rute yang Diekspor dan permintaan Apigee akan dirutekan langsung ke internet. Hal ini mungkin tidak selalu terjadi, jadi pastikan Anda mengklarifikasi topologi jaringan yang diinginkan. Misalnya, jika Kontrol Layanan VPC diaktifkan, Anda juga perlu mengekspor rute default atau lainnya agar dapat mencapai target eksternal.

Resolusi

Tinjau arsitektur jaringan Anda, dan pastikan rute diekspor ke peering VPC dengan Apigee. Kemungkinan besar rute yang tidak ada adalah statis atau dinamis. Kurangnya rute dinamis yang diperlukan menunjukkan masalah pada fitur terkait, misalnya, Cloud Interconnect.

Perhatikan bahwa peering transitif tidak didukung. Dengan kata lain, jika jaringan VPC N1 di-peering dengan N2 dan N3, tetapi N2 dan N3 tidak terhubung langsung, jaringan VPC N2 tidak dapat berkomunikasi dengan jaringan VPC N3 melalui Peering Jaringan VPC.

Anda dapat membaca Pola jaringan Selatan untuk mengetahui informasi selengkapnya.

Penyebab: Masalah konektivitas pada target

Diagnosis

Target mungkin tidak dapat dijangkau dari VPC atau tidak dapat menerima koneksi. Tersedia dua opsi untuk mendiagnosis masalah tersebut.

Uji Konektivitas (alamat IP Target Pribadi)

Jika target berada di jaringan pribadi, Anda dapat menggunakan fitur Uji Konektivitas untuk mendiagnosis penyebab umum.

Identifikasi alamat IP target yang di-resolve dari instance Apigee. Salah satu metodenya adalah menggunakan sesi Debug.

Di Debug, buka AnalyticsPublisher (atau AX di Debug Klasik). Cari nilai target.ip di sisi kanan layar.

Dalam contoh ini, IP-nya adalah 10.2.0.1. Ini adalah alamat IP pribadi, artinya kita dapat menggunakan Uji Konektivitas.
Perhatikan alamat IP instance Apigee yang tidak dapat terhubung ke target. Pada Instances di Apigee Console, temukan Alamat IP instance Apigee di kolom IP Address.
Buka Pengujian Konektivitas, lalu klik Buat uji konektivitas. Berikan detail berikut:
1. Alamat IP Sumber: Gunakan IP instance Apigee yang diperoleh pada Langkah 2 di atas. Perlu diperhatikan, ini bukanlah IP sumber persis yang digunakan oleh Apigee untuk mengirim permintaan ke target, tetapi cukup untuk pengujian, karena berada di subnet yang sama.
2. Ini adalah alamat IP yang digunakan di Google Cloud: Biarkan tidak dicentang kecuali jika alamat tersebut ada di project Google Cloud Anda. Jika memeriksa nilai ini, berikan juga project dan jaringan.
3. Masukkan alamat target (Langkah 1) dan port sebagai Destination IP Address dan Destination Port.
Klik Create dan tunggu hingga pengujian selesai dijalankan untuk pertama kalinya.
Dalam daftar uji konektivitas, klik View untuk melihat hasil eksekusi.
Jika hasilnya "Unreachable", berarti Anda mengalami masalah dengan konfigurasi. Alat ini akan mengarahkan Anda ke dokumentasi Status Uji Konektivitas untuk melanjutkan. Jika statusnya "Dapat dijangkau", hal tersebut mengecualikan banyak masalah konfigurasi. Namun, hal ini tidak menjamin bahwa target dapat dijangkau. Belum ada upaya nyata untuk membuat koneksi TCP dengan target. Hanya diagnosis berikutnya di bawah ini yang akan membantu mengujinya.

Pengujian konektivitas VM (semua target)

Di VPC yang sama yang di-peering dengan Apigee, buat Instance VM di Linux.
Lakukan uji konektivitas dari VM, sebaiknya pada saat masalah dapat direproduksi dari Apigee. Anda dapat menggunakan telnet, curl, dan utilitas lainnya untuk membuat koneksi. Contoh curl ini berjalan dalam loop dengan waktu tunggu tiga detik. Jika curl tidak dapat terhubung ke TCP dalam waktu tiga detik, curl akan gagal.
```
for i in {1..100}; do curl -m 3 -v -i https://[TARGET_HOSTNAME] ; sleep 0.5 ; done
```
Periksa output lengkap dan cari error ini:
```
* Closing connection 0
 curl: (28) Connection timed out after 3005 milliseconds
```
Munculnya error ini mengonfirmasi bahwa masalah tersebut dapat direproduksi di luar Apigee.

Harap diperhatikan, jika Anda melihat error lain, seperti error terkait TLS, kode status buruk, dll., tidak mengkonfirmasi waktu tunggu koneksi dan tidak terkait dengan masalah ini.
Jika target memerlukan listingan IP yang diizinkan, Anda mungkin tidak dapat mengujinya dari VM, kecuali jika Anda juga memasukkan IP sumber instance VM yang diizinkan.

Resolusi

Jika Anda mengidentifikasi masalah berdasarkan Uji Konektivitas, lanjutkan dengan langkah-langkah penyelesaian yang didokumentasikan.

Jika waktu tunggu direproduksi dari VM, tidak ada panduan pasti tentang cara menyelesaikan masalah di sisi target. Setelah waktu tunggu koneksi dapat direproduksi di luar Apigee, lanjutkan masalah ini lebih lanjut dari VPC. Coba uji konektivitas sedekat mungkin dengan target.

Jika target berada di balik koneksi VPN, Anda mungkin juga dapat mengujinya dari jaringan lokal.

Jika target berada di internet, Anda dapat mencoba mereproduksi masalah di luar Konsol Google Cloud.

Jika masalah terjadi pada jam sibuk, target mungkin kewalahan dengan koneksi internet.

Jika perlu mengajukan kasus dukungan Google Cloud pada tahap tersebut, Anda tidak perlu lagi memilih komponen Apigee, karena masalah tersebut kini dapat direproduksi langsung dari VPC.

Penyebab: Pemberian izin IP pada target dengan beberapa atau semua IP NAT Apigee tidak ditambahkan

Diagnosis

Hal ini berkaitan dengan target eksternal (internet) yang mengaktifkan listingan IP yang diizinkan. Pastikan semua IP NAT Apigee ditambahkan di sisi target yang terpengaruh. Jika tidak ada listingan yang diizinkan pada target, Anda dapat melewati bagian ini.

Masalah ini lebih mudah dikenali jika error terjadi sesekali, karena dalam hal ini Anda mungkin dapat menemukan korelasi antara IP NAT tertentu dan error tersebut.

Jika masalah berlanjut (semua panggilan gagal), pastikan IP NAT diaktifkan di Apigee dan ambil dengan langkah-langkah berikut:

Cantumkan IP NAT untuk instance:

curl -H "Authorization: Bearer $TOKEN" \
"https://apigee.googleapis.com/v1/organizations/$ORG_ID/instances/$INSTANCE_NAME/natAddresses"

Contoh respons:

{
  "natAddresses": [
    {
      "name": "nat-1",
      "ipAddress": "35.203.160.18",
      "state": "ACTIVE"
    },
    {
      "name": "nat-2",
      "ipAddress": "35.230.14.174",
      "state": "RESERVED"
    }
  ]
}

Jika Anda tidak menerima alamat di output, maka IP NAT tidak ditambahkan di sisi Apigee. Jika Anda mendapatkan alamat tetapi tidak ada satu pun alamat yang AKTIF, berarti tidak ada alamat yang digunakan yang mengizinkan akses ke internet, dan hal ini juga menjadi masalah.

Jika Anda memiliki setidaknya satu alamat AKTIF, alamat tersebut dapat diizinkan di daftar target, sehingga tidak ada kesalahan konfigurasi di sisi Apigee. Dalam hal ini, alamat mungkin tidak ada di daftar yang diizinkan pada target.

Jika masalahnya hanya sesekali, hal ini mungkin menunjukkan bahwa hanya sebagian IP NAT yang diizinkan di target. Untuk mengidentifikasi bahwa:

Buat Reverse proxy baru tempat target yang terpengaruh ditentukan di TargetEndpoint. Anda juga dapat menggunakan kembali proxy yang ada dan melanjutkan ke langkah berikutnya:
Menambahkan kebijakan ServiceCallout ke dalam PreFlow Permintaan. ServiceCallout harus memanggil "https://icanhazip.com", "https://mocktarget.apigee.net/ip", atau endpoint publik lainnya yang menampilkan alamat IP pemanggil dalam respons. Simpan respons dalam variabel "response" sehingga konten terlihat di Debug. Ini adalah contoh konfigurasi kebijakan ServiceCallout:
```
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ServiceCallout continueOnError="false" enabled="true" name="Service-Callout-1">
    <DisplayName>Service Callout-1</DisplayName>
    <Properties/>
    <Request clearPayload="true" variable="myRequest">
        <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
    </Request>
    <Response>response</Response>
    <HTTPTargetConnection>
        <Properties/>
        <URL>https://icanhazip.com</URL>
    </HTTPTargetConnection>
</ServiceCallout>
```
Anda juga dapat menyimpan respons dalam variabel kustom, tetapi Anda harus membaca ".content" variabel tersebut dengan kebijakan TetapkanMessage untuk menampilkannya di alat Debug.

Pastikan target dikonfigurasi dengan cara yang sama persis seperti pada proxy yang terpengaruh.

Catatan: Permintaan ServiceCallout dan permintaan Target harus terjadi dalam satu transaksi. Hal ini untuk memastikan bahwa server yang sama memproses permintaan sehingga IP NAT dari permintaan yang terpengaruh cocok dengan IP NAT yang diperoleh dari ServiceCallout.
Jalankan sesi Debug dan klik langkah ServiceCallout:
Di pojok kanan bawah, Anda akan melihat bagian Response content yang berisi NAT IP (dalam Body) dari instance Apigee yang membuat permintaan. Atau, jika Anda menyimpan respons ServiceCallout di tempat lain, Anda akan melihatnya di sana.

Perhatikan bahwa nantinya dalam alur, proxy akan memanggil target dan Konten respons akan ditimpa dengan error atau respons dari target.
Cobalah untuk menghubungkan IP NAT dengan masalah tersebut. Jika Anda melihat bahwa hanya IP tertentu yang gagal, ini adalah tanda bahwa sebagian (tetapi tidak semua IP) diizinkan di target.
Jika Anda tidak melihat korelasi antara IP NAT dan error, misalnya, jika IP yang sama gagal dalam satu permintaan, tetapi tidak di permintaan lain, maka kemungkinan besar ini bukan masalah daftar yang diizinkan. Ini mungkin kelelahan NAT. Lihat Penyebab: Kehabisan port IP NAT.

Resolusi

Pastikan Anda memiliki IP NAT yang disediakan dan diaktifkan dan pastikan semua IP tersebut ditambahkan di sisi target.

Penyebab: Kehabisan port NAT IP

Diagnosis

Jika masalah hanya dapat direproduksi dari Apigee dan NAT IP disediakan untuk organisasi Anda, dan Anda melihatnya terjadi untuk target yang berbeda secara bersamaan, Anda mungkin kehabisan port sumber NAT:

Perhatikan jangka waktu terjadinya masalah. Misalnya: setiap hari antara pukul 17.58 - 18.08.
Konfirmasi apakah target lain terpengaruh oleh masalah ini dalam jangka waktu yang sama. Target lainnya tersebut harus dapat diakses melalui internet dan tidak boleh dihosting di lokasi yang sama dengan target asli yang terpengaruh.
Menetapkan jika error hanya terjadi di atas volume traffic tertentu dalam TPS. Untuk melakukannya, catat jangka waktu masalah, lalu buka dasbor Proxy Performance.
Coba hubungkan periode waktu error dengan peningkatan Transaksi rata-rata per detik (tps).

Dalam contoh ini, tps meningkat menjadi 1000 pada pukul 17:58. Dengan asumsi bahwa dalam contoh ini, pukul 17.58 tepat saat masalah terjadi, dan masalah tersebut memengaruhi dua atau beberapa target yang tidak terkait, maka hal tersebut merupakan sinyal adanya masalah dengan kehabisan NAT.

Resolusi

Hitung ulang persyaratan IP NAT Anda menggunakan petunjuk dalam Menghitung persyaratan IP NAT statis.

Anda juga dapat menambahkan lebih banyak IP NAT dan melihat apakah langkah tersebut menyelesaikan masalah. Perhatikan bahwa, menambahkan lebih banyak IP mungkin memerlukan pendaftaran yang diizinkan di semua target terlebih dahulu.

Penyebab: nilai connect.timeout.millis disetel terlalu rendah

Diagnosis

Nilai waktu tunggu di proxy mungkin dikonfigurasi dengan tidak benar.

Untuk memeriksanya, buka proxy yang terpengaruh dan periksa TargetEndpoint yang dimaksud. Catat properti "connect.timeout.millis" dan nilainya. Dalam contoh di sini, nilainya adalah 50, yaitu 50 milidetik dan biasanya terlalu rendah untuk menjamin pembuatan koneksi TCP. Jika Anda melihat nilai di bawah 1.000, mungkin itulah penyebab masalahnya. Jika Anda tidak melihat properti "connect.timeout.millis", berarti nilai default telah ditetapkan dan penyebabnya tidak dikonfirmasi.

Proxy dengan waktu tunggu

Resolusi

Perbaiki nilai connect.timeout.millis, pastikan untuk memperhatikan bahwa unit waktu dalam milidetik. Nilai defaultnya adalah 3.000, atau 3.000 milidetik. Untuk mengetahui informasi selengkapnya, lihat Referensi properti endpoint.

Hubungi Dukungan untuk bantuan lebih lanjut

Jika masalah terus berlanjut setelah mengikuti petunjuk di atas, kumpulkan informasi diagnostik berikut untuk Dukungan Google Cloud:

Project ID dan nama organisasi Apigee
Nama proxy dan lingkungannya
Jangka waktu masalah
Frekuensi masalah
Nama host target
Sesi debug dengan masalah
Hasil pemeriksaan yang dilakukan untuk kemungkinan penyebab di atas. Misalnya, output perintah curl dari VM