Halaman ini diterjemahkan oleh Cloud Translation API.

Ringkasan migrasi

Halaman ini memberi Anda ringkasan perbedaan antara Load Balancer Aplikasi eksternal global dan Load Balancer Aplikasi klasik, serta ringkasan mendetail tentang cara memigrasikan resource Load Balancer Aplikasi klasik yang ada ke Load Balancer Aplikasi eksternal global.

Untuk memanfaatkan fitur pengelolaan traffic lanjutan dari Load Balancer Aplikasi eksternal global, sebaiknya migrasikan resource Load Balancer Aplikasi klasik ke infrastruktur Load Balancer Aplikasi eksternal global.

Membandingkan Load Balancer Aplikasi klasik dan Load Balancer Aplikasi eksternal global

Sebelum memigrasikan resource, pahami perbedaan antara Load Balancer Aplikasi klasik dan Load Balancer Aplikasi eksternal global.

Perbedaan fitur

Fitur berikut tidak didukung dengan Load Balancer Aplikasi eksternal global. Fitur ini hanya tersedia dengan Load Balancer Aplikasi klasik:

Tingkat Jaringan Standar
Pengontrol GKE Ingress

Untuk men-deploy Load Balancer Aplikasi eksternal global untuk cluster GKE, gunakan pengontrol GKE Gateway. Untuk petunjuk penyiapan, lihat Men-deploy Gateway.

Perbedaan bidang data

Tabel berikut menunjukkan perbedaan pada bidang data antara Load Balancer Aplikasi klasik dan Load Balancer Aplikasi eksternal global. Perbedaan ini memengaruhi cara load balancer merespons beberapa peristiwa umum.

Acara	Respons Load Balancer Aplikasi Klasik	Respons Load Balancer Aplikasi eksternal global
Kode status/error
Semua backend tidak responsif	Menampilkan HTTP 502	Menampilkan HTTP 503
Permintaan menggunakan cipher SSL yang dilarang	Menampilkan HTTP 502	Menampilkan HTTP 503
Koneksi upstream awal direset oleh backend	Menampilkan HTTP 502	Menampilkan HTTP 503
Upgrade koneksi gagal (misalnya, saat mengupgrade ke Websocket)	Menampilkan HTTP 400	Menampilkan HTTP 403
Header terlalu besar	Menampilkan HTTP 413	Menampilkan HTTP 431
Kuota dan batas
Konfigurasi peta URL	Ada perbedaan signifikan dalam batas konfigurasi peta URL antara kedua load balancer. Untuk mengetahui detailnya, lihat dokumentasi Kuota: Peta URL.
Penanganan header
Permintaan menggunakan metode HTTP kustom tanpa isi	Menambahkan header `Transfer Encoding: Chunked` ke permintaan yang dikirim ke backend	Menambahkan header `Content-Length: 0` ke permintaan yang dikirim ke backend
Format header `X-Forwarded-For` yang ditambahkan ke permintaan yang dikirim ke backend	Menggunakan pembatas '`,` ' di antara IP	Menggunakan pembatas '`,`' di antara IP (tanpa spasi setelah koma)
Mempertahankan kapitalisasi header	Kapitalisasi header dipertahankan	Semua kunci header diubah menjadi huruf kecil
Header berulang dengan nama yang sama	Diizinkan	Header berulang dapat digabungkan menjadi satu header, dengan nilai ditambahkan secara berurutan dan dipisahkan dengan koma, sebagaimana diizinkan oleh RFC 7230.
(Khusus HTTP/1.1) Nama header tidak valid (misalnya, karakter yang tidak didukung dalam header)	Diizinkan (untuk HTTP/1.1)	Menampilkan HTTP 502 (untuk HTTP/1.1)
(Khusus HTTP/1.1) Header `Content-Length` yang berulang (tetapi sama) dalam permintaan	Diizinkan (untuk HTTP/1.1)	Menampilkan HTTP 502 (untuk HTTP/1.1)
(Khusus HTTP/1.1) Beberapa host di header	Jika 2 host atau lebih ditambahkan, dan host pertama valid, header akan diterima	Jika 2 host atau lebih ditambahkan, dan ada yang tidak valid, load balancer akan menampilkan HTTP 502
(Khusus HTTP/1.1) header `Connection: Keep-Alive`	Menambahkan `Keep-Alive header` dalam permintaan yang dikirim ke backend secara default	Tidak menambahkan header ini secara default
Meminta penanganan
Garis miring terbalik dalam permintaan	URL tidak berubah	Mengonversi ke garis miring
Menggabungkan garis miring duplikat dalam permintaan	Irisan daun belum digabungkan	Menggabungkan garis miring
`#` di jalur permintaan	Diizinkan	Menampilkan HTTP 400
(Khusus HTTP/1.1) Karakter ilegal di jalur permintaan (misalnya, `\\x7f\\x7f`)	Diizinkan (untuk HTTP/1.1)	Menampilkan HTTP 502 (untuk HTTP/1.1)
Distribusi traffic (konfigurasi peta URL)
Permintaan klien mencakup nomor port	Nomor port diabaikan meskipun Anda telah mengonfigurasi host dengan port dalam peta URL. Hanya nama host yang dipertimbangkan. Misalnya, permintaan untuk `example.com:5000` dicocokkan dengan layanan backend untuk `example.com`.	Nama host dan nomor port dipertimbangkan. Misalnya, permintaan untuk `example.com:5000` dicocokkan dengan layanan backend untuk `example.com:5000`. Jika tidak ada kecocokan, layanan backend default akan digunakan.

Karena perbedaan arsitektur, saat bermigrasi ke Load Balancer Aplikasi eksternal global, Anda mungkin melihat peningkatan jumlah koneksi ke backend, terutama saat menggunakan protokol HTTP/1.1. Hal ini dapat menyebabkan peningkatan konsumsi memori pada instance backend. Pantau penggunaan resource backend Anda selama dan setelah migrasi.

Untuk mempelajari lebih lanjut perbedaan dan fitur yang didukung, lihat Perbandingan fitur load balancer dan Ringkasan Load Balancer Aplikasi.

Bermigrasi dari Load Balancer Aplikasi eksternal klasik ke global

Untuk bermigrasi ke Load Balancer Aplikasi eksternal global, Anda mengubah skema load balancing resource load balancing, khususnya layanan backend dan aturan penerusan, dari EXTERNAL menjadi EXTERNAL_MANAGED. Untuk melakukannya, Anda melakukan serangkaian langkah migrasi tempat Anda dapat menguji bagian dari traffic jaringan dengan skema load balancing baru sebelum benar-benar menyelesaikan migrasi. Selama migrasi resource, Anda mengontrol persentase permintaan yang dikirim ke infrastruktur Load Balancer Aplikasi klasik atau infrastruktur Load Balancer Aplikasi eksternal global.

Diagram berikut menunjukkan skema load balancing resource load balancing Anda sebelum dan setelah migrasi.

Proses migrasi untuk resource Load Balancer Aplikasi klasik. — Proses migrasi untuk resource Load Balancer Aplikasi klasik (klik untuk memperbesar).

Dalam diagram sebelumnya, perhatikan hal-hal berikut:

Sebelum resource dimigrasikan, semua permintaan menggunakan infrastruktur Load Balancer Aplikasi klasik.
Saat resource dimigrasikan, beberapa permintaan dikirim ke infrastruktur Load Balancer Aplikasi eksternal global dan permintaan yang tersisa dikirim ke infrastruktur Load Balancer Aplikasi klasik.
Setelah resource dimigrasikan, semua permintaan akan menggunakan infrastruktur Load Balancer Aplikasi eksternal global.

Untuk membantu memastikan transisi yang lancar, migrasikan resource Load Balancer Aplikasi klasik berikut dalam urutan yang ditentukan:

Migrasikan semua layanan backend yang terpasang ke aturan penerusan load balancer.
Migrasikan semua bucket backend yang terpasang ke aturan penerusan load balancer. Anda melakukannya di tingkat aturan penerusan karena bucket backend tidak memiliki skema load balancing.
Migrasikan aturan penerusan load balancer.

Anda hanya dapat memigrasikan aturan penerusan setelah semua layanan backend dan bucket backend yang terpasang ke aturan penerusan telah dimigrasikan.

Status migrasi

Anda memigrasikan resource dengan menyetelnya ke status yang berbeda sebelum mengubah skema penyeimbangan bebannya menjadi EXTERNAL_MANAGED.

PREPARE: setel resource ke status ini untuk mempersiapkannya untuk migrasi.
TEST_BY_PERCENTAGE: untuk menguji resource yang disiapkan, tetapkan resource ke status ini untuk mengirim persentase traffic jaringan. Tahap ini bersifat opsional.
TEST_ALL_TRAFFIC: tetapkan resource ke status ini untuk mengirim semua traffic jaringan ke resource melalui infrastruktur Load Balancer Aplikasi eksternal global dan bukan infrastruktur Load Balancer Aplikasi klasik.

Proses migrasi

Untuk membantu memastikan tidak ada periode nonaktif, Anda memigrasikan resource dalam urutan tertentu dari infrastruktur Load Balancer Aplikasi klasik ke infrastruktur Load Balancer Aplikasi eksternal global, lalu mengubah skema load balancing dari EXTERNAL menjadi EXTERNAL_MANAGED untuk menyelesaikan migrasi.

Migrasikan layanan backend load balancer.

Ulangi langkah-langkah berikut untuk setiap layanan backend.
1. Siapkan layanan backend untuk migrasi.
  
  Sebelum traffic dapat dikirim melalui infrastruktur Load Balancer Aplikasi eksternal global, tetapkan status layanan backend ke PREPARE. Tindakan ini menyiapkan layanan backend untuk menangani traffic jaringan infrastruktur Load Balancer Aplikasi eksternal global. Layanan backend memerlukan waktu beberapa saat (sekitar enam menit) agar siap mengirim traffic melalui infrastruktur Load Balancer Aplikasi eksternal global.
2. Opsional: Uji layanan backend yang sudah disiapkan.
  
  Setelah layanan backend berada dalam status PREPARE, tetapkan statusnya ke TEST_BY_PERCENTAGE dan tetapkan persentase traffic jaringan Load Balancer Aplikasi klasik ke infrastruktur Load Balancer Aplikasi eksternal global.
  
  Meskipun tahap ini bersifat opsional, sebaiknya Anda menguji traffic sebelum memigrasikan layanan backend. Mulai dengan nilai persentase kecil dan pantau log resource. Jika layanan backend berperilaku seperti yang diharapkan, tingkatkan persentase secara bertahap hingga 100%.
  
  Dalam status TEST_BY_PERCENTAGE, Anda tidak dapat menggunakan kemampuan tambahan infrastruktur Load Balancer Aplikasi eksternal global.
3. Kirim semua traffic jaringan Load Balancer Aplikasi klasik ke layanan backend yang telah disiapkan.
  
  Setelah pengujian layanan backend berhasil, tetapkan statusnya ke TEST_ALL_TRAFFIC dan kirim semua traffic jaringan Load Balancer Aplikasi klasik ke layanan backend yang telah disiapkan. Layanan backend memerlukan waktu beberapa saat (sekitar enam menit) agar siap menangani traffic jaringan.
  
  Dalam status TEST_ALL_TRAFFIC, Anda tidak dapat menggunakan kemampuan tambahan infrastruktur Load Balancer Aplikasi eksternal global.
4. Ubah skema load balancing layanan backend yang dimigrasikan menjadi EXTERNAL_MANAGED.
  
  Setelah menguji layanan backend yang telah disiapkan di infrastruktur Load Balancer Aplikasi eksternal global, ubah skema load balancing-nya menjadi EXTERNAL_MANAGED. Layanan backend memerlukan waktu beberapa saat (sekitar enam menit) untuk dimigrasikan sepenuhnya. Setelah skema load balancing layanan backend berubah menjadi EXTERNAL_MANAGED, Anda dapat menggunakan fitur lanjutan infrastruktur Load Balancer Aplikasi eksternal global.
Migrasikan bucket backend load balancer. Anda melakukannya di tingkat aturan penerusan karena bucket backend tidak memiliki skema load balancing.

Ulangi langkah-langkah berikut untuk setiap bucket.
1. Siapkan bucket backend untuk migrasi.
  
  Sebelum traffic dapat dikirim melalui infrastruktur Load Balancer Aplikasi eksternal global, tetapkan status bucket backend ke PREPARE, dan tunggu beberapa saat (sekitar enam menit).
2. Opsional: Uji layanan backend yang sudah disiapkan.
  
  Setelah bucket backend berada dalam status PREPARE, tetapkan statusnya ke TEST_BY_PERCENTAGE dan tetapkan persentase traffic jaringan Load Balancer Aplikasi klasik ke infrastruktur Load Balancer Aplikasi eksternal global.
3. Kirim semua traffic jaringan Load Balancer Aplikasi klasik ke bucket backend yang telah disiapkan.
  
  Tetapkan status bucket backend ke TEST_ALL_TRAFFIC dan kirim semua traffic jaringan Load Balancer Aplikasi klasik ke bucket tersebut. Backend bucket memerlukan waktu beberapa saat (sekitar enam menit) agar siap menangani traffic jaringan.
  
  Dalam status TEST_ALL_TRAFFIC, Anda tidak dapat menggunakan kemampuan tambahan infrastruktur Load Balancer Aplikasi eksternal global.
Migrasikan aturan penerusan.

Untuk setiap aturan penerusan, ubah skema load balancing aturan penerusan menjadi EXTERNAL_MANAGED, dan tunggu beberapa saat (sekitar enam menit). Setelah skema load balancing aturan penerusan berubah menjadi EXTERNAL_MANAGED, Anda dapat menggunakan fitur lanjutan dari infrastruktur Load Balancer Aplikasi eksternal global.

Untuk mengetahui proses langkah demi langkah yang mendetail, lihat Memigrasikan resource dari Load Balancer Aplikasi klasik.

Diagram berikut menunjukkan resource Load Balancer Aplikasi klasik dalam status migrasi yang berbeda.

Status migrasi resource Load Balancer Aplikasi klasik. — Status migrasi resource Load Balancer Aplikasi klasik (klik untuk memperbesar).

Setelah memigrasikan resource, jika Anda ingin mengembalikannya ke Load Balancer Aplikasi klasik, ubah skema load balancing-nya dalam waktu 90 hari setelah migrasinya. Anda tidak dapat me-roll back resource setelah periode 90 hari berlalu.

Menggunakan afinitas sesi

Pertimbangkan peringatan berikut saat memigrasikan layanan backend Load Balancer Aplikasi klasik dengan afinitas sesi:

Menetapkan nilai untuk TEST_BY_PERCENTAGE akan mengalihkan beberapa traffic yang menargetkan Load Balancer Aplikasi klasik ke Load Balancer Aplikasi eksternal global. Hal ini akan merusak afinitas IP klien. Mengubah persentase migrasi (misalnya, meningkatkannya sebesar 10%) akan merusak afinitas sesi untuk persentase alamat IP klien yang sama (10% dalam contoh ini), hingga afinitas dibuat ulang pada permintaan berikutnya.
Menetapkan nilai untuk TEST_BY_PERCENTAGE akan mengalihkan persentase traffic tersebut tanpa cookie sesi ke Load Balancer Aplikasi eksternal global. Load balancer ini juga mengalihkan semua traffic dengan cookie sesi ke fleet load balancer yang menghasilkan cookie tersebut.
Menetapkan nilai TEST_BY_PERCENTAGE ke 0%, atau membiarkannya tidak ditetapkan, atau menetapkan layanan backend ke status PREPARE, akan membatalkan semua cookie yang ada yang diarahkan ke Load Balancer Aplikasi eksternal global.
Mengubah skema load balancing layanan backend menjadi EXTERNAL_MANAGED akan membatalkan semua cookie yang dibuat oleh fleet Load Balancer Aplikasi klasik. Hal ini memungkinkan Anda mengembalikan traffic jika ada masalah dengan aplikasi Anda menggunakan Load Balancer Aplikasi eksternal global. Misalnya, jika klien menyajikan cookie dari fleet Load Balancer Aplikasi klasik, tetapi skema layanan backend adalah EXTERNAL_MANAGED, cookie klien tidak akan dipertimbangkan. Load Balancer Aplikasi eksternal global mengabaikan cookie dan membuat cookie baru.

Mengembalikan resource yang dimigrasikan

Setelah memigrasikan resource, jika Anda ingin mengembalikannya dari infrastruktur Load Balancer Aplikasi eksternal global ke infrastruktur Load Balancer Aplikasi klasik, Anda dapat melakukannya dalam waktu 90 hari setelah mengubah skema load balancing-nya.

Mengembalikan layanan backend ke skema EXTERNAL memerlukan pengembalian aturan penerusan. Mengembalikan aturan penerusan ke skema EXTERNAL tidak memerlukan pengembalian layanan backend.

Untuk mengembalikan resource, ikuti langkah-langkah berikut:

Hapus semua fitur pengelolaan traffic lanjutan baru dari Load Balancer Aplikasi eksternal global yang dikonfigurasi di resource.
Roll back aturan penerusan.

Ubah skema load balancing aturan penerusan dari EXTERNAL_MANAGED menjadi EXTERNAL.
Roll back bucket backend.
1. Tetapkan status migrasi bucket backend ke TEST_ALL_TRAFFIC, dan tunggu beberapa saat (sekitar enam menit).
2. Opsional: Untuk mengurangi traffic, tetapkan status migrasi bucket backend ke TEST_BY_PERCENTAGE dan tetapkan persentase traffic.
3. Tetapkan status migrasi bucket backend ke PREPARE.
4. Mengembalikan bucket backend ke status sebelum migrasi.
Lakukan rollback layanan backend.
1. Setel status migrasi layanan backend ke TEST_ALL_TRAFFIC, dan tunggu beberapa saat (sekitar enam menit).
2. Opsional: Untuk mengurangi traffic, tetapkan status migrasi layanan backend ke TEST_BY_PERCENTAGE dan tetapkan persentase traffic.
3. Tetapkan status migrasi layanan backend ke PREPARE.
4. Mengembalikan layanan backend ke status sebelum migrasi.

Untuk mengetahui proses langkah demi langkah yang mendetail, lihat Mengembalikan resource yang dimigrasikan ke Load Balancer Aplikasi klasik.

Melacak proses migrasi Anda

Saat memigrasikan resource, Anda dapat memeriksa skema load balancing-nya dengan melihat hal berikut:

Dasbor logging dan pemantauan Load Balancer Aplikasi eksternal global. Untuk mengetahui informasi selengkapnya, lihat Logging dan pemantauan Load Balancer Aplikasi eksternal global.
Nilai header permintaan dan respons HTTP berikut:
- X-External-Managed-Migration-Scheme-Override: header permintaan ini mengarahkan permintaan berdasarkan nilainya. Jika nilai header adalah EXTERNAL, permintaan akan diarahkan ke infrastruktur Load Balancer Aplikasi klasik. Jika nilainya adalah EXTERNAL_MANAGED, permintaan akan dirutekan melalui infrastruktur Load Balancer Aplikasi eksternal global.
  
  Gunakan header ini untuk mengarahkan permintaan ke fleet load balancer tertentu.
- X-External-Managed-Migration-Selected-Scheme: header permintaan dan respons ini memberi tahu backend dan klien tentang skema load balancing yang digunakan untuk merutekan permintaan. Header ditampilkan ke klien dan diteruskan ke backend pelanggan.
  
  Jika permintaan dirutekan melalui infrastruktur Load Balancer Aplikasi klasik, nilainya adalah EXTERNAL. Jika permintaan dirutekan melalui infrastruktur Load Balancer Aplikasi eksternal global, nilainya adalah EXTERNAL_MANAGED.