Memigrasikan pemilihan rute ke arah utara ke Private Service Connect

Halaman ini berlaku untuk Apigee, tetapi tidak untuk Apigee hybrid.

Lihat Dokumentasi Apigee Edge.

Penting: Topik ini hanya berlaku untuk organisasi yang dibuat dengan peering VPC yang diaktifkan. Lihat juga Opsi jaringan Apigee.

Dokumen ini menjelaskan cara memigrasikan konfigurasi perutean klien-ke-Apigee (juga disebut sebagai "arah utara") dari konfigurasi grup instance terkelola (MIG) ke Private Service Connect (PSC) berbasis konfigurasi Anda.

Ringkasan

Jika saat ini Anda menggunakan grup instance terkelola (MIG) berbasis domain menggunakan Load Balancer HTTPS eksternal (Klasik) untuk mengarahkan traffic eksternal ke Apigee, Anda dapat memilih untuk memigrasikan rute "arah utara" ini lalu lintas untuk menggunakan konfigurasi berbasis PSC.

Penting: Karena load balancer HTTPS eksternal global klasik tidak mendukung backend NEG PSC, Anda harus membuat load balancer HTTPS eksternal global baru dan mengalihkan traffic masuk melalui DNS.

Langkah-langkah migrasi

Catatan: Untuk memastikan load balancer beroperasi seperti yang diharapkan, Anda harus memindahkan konfigurasi atau fitur add-on load balancer HTTPS klasik ke load balancer global.

1. Konfigurasi perutean menuju utara ke endpoint Apigee. Untuk tugas ini, ikuti langkah-langkah di tab External routing (PSC) di bagian Configure routing di Apigee CLI provisioning dokumen.
2. Jika Anda memiliki beberapa instance Apigee (kasus penggunaan multi-region), buat NEG yang sesuai untuk setiap region Apigee dan melampirkannya ke layanan backend load balancer. Lihat Memperluas Apigee ke beberapa region.
3. Uji endpoint load balancer global yang baru.
4. Setelah pengujian selesai, alihkan semua entri DNS yang ada agar mengarah ke entri DNS baru endpoint load balancer. Perhatikan hal berikut:
   Catatan:

   • Penyedia DNS yang berbeda mendukung jenis kebijakan {i>routing<i} yang berbeda. Contoh: Cloud DNS mendukung kebijakan pemilihan rute round robin (WRR) berbobot, yang memastikan traffic didistribusikan sesuai dengan bobot yang dikonfigurasi. Kebijakan pemilihan rute tersebut dapat dimanfaatkan untuk mengalihkan traffic di antara 2 endpoint load balancer.
   • Endpoint global eksternal load balancer (GXLB) baru dapat ditambahkan ke endpoint DNS pelanggan dengan bobot yang cukup untuk menyediakan 5% atau 10% lalu lintas mereka. Area ini dapat ditingkatkan secara perlahan untuk mengizinkan 100% traffic di titik akhir GXLB baru dan 0% di GXLB (Klasik) lama endpoint.
   • Menghapus endpoint GXLB (Klasik) lama dari DNS, dan menghapus GXLB (Klasik) lama beserta backend MIG.