Halaman ini diterjemahkan oleh Cloud Translation API.

Ringkasan migrasi

Halaman ini memberi Anda ringkasan tentang 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 menyoroti 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 yang signifikan pada 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 pemisah '`,`' di antara IP (tanpa spasi setelah koma)
Pemeliharaan 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 koma, seperti yang 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` berulang (tetapi sama) dalam permintaan	Diizinkan (untuk HTTP/1.1)	Menampilkan HTTP 502 (untuk HTTP/1.1)
(Khusus HTTP/1.1) Beberapa host dalam header	Jika 2 host atau lebih ditambahkan, dan host pertama valid, header akan diterima	Jika 2 host atau lebih ditambahkan, dan salah satunya tidak valid, load balancer akan menampilkan HTTP 502
Header `Connection: Keep-Alive` (khusus HTTP/1.1)	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 diubah	Mengonversi ke garis miring
Menggabungkan garis miring duplikat dalam permintaan	Tanda garis miring tidak digabungkan	Menggabungkan garis miring
`#` di jalur permintaan	Diizinkan	Menampilkan HTTP 400
(Khusus HTTP/1.1) Karakter ilegal dalam jalur permintaan (misalnya, `\\x7f\\x7f`)	Diizinkan (untuk HTTP/1.1)	Menampilkan HTTP 502 (untuk HTTP/1.1)
Distribusi traffic (konfigurasi peta URL)
Permintaan klien menyertakan nomor port	Nomor port diabaikan meskipun Anda telah mengonfigurasi host dengan port di 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.

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 harus 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-bagian 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).

Pada 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 lainnya 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 dilampirkan ke aturan penerusan telah dimigrasikan.

Status migrasi

Anda memigrasikan resource dengan menetapkannya ke status yang berbeda sebelum mengubah skema load balancing-nya menjadi EXTERNAL_MANAGED.

PREPARE: menetapkan 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: menetapkan resource ke status ini untuk mengirim semua traffic jaringan ke resource melalui infrastruktur Load Balancer Aplikasi eksternal global, 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 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 monitor log resource. Jika layanan backend berperilaku seperti yang diharapkan, tingkatkan persentase secara bertahap menjadi 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 Application Load Balancer klasik ke layanan backend yang 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 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.
Memigrasikan bucket backend load balancer. Anda melakukannya di tingkat aturan pengalihan 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 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. Bucket backend memerlukan beberapa waktu (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, lalu tunggu beberapa saat (sekitar enam menit). Setelah skema load balancing aturan penerusan berubah menjadi EXTERNAL_MANAGED, Anda dapat menggunakan fitur lanjutan infrastruktur Load Balancer Aplikasi eksternal global.

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

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

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 Application Load Balancer klasik, ubah skema load balancing-nya dalam waktu 90 hari setelah migrasi. 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. Fitur ini juga mengalihkan semua traffic dengan cookie sesi ke fleet load balancer yang menghasilkan cookie.
Menetapkan nilai untuk 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 dihasilkan oleh fleet Load Balancer Aplikasi klasik. Hal ini memungkinkan Anda melakukan rollback traffic jika ada masalah dengan aplikasi Anda yang menggunakan Load Balancer Aplikasi eksternal global. Misalnya, jika klien menampilkan cookie dari fleet Load Balancer Aplikasi klasik, tetapi skema layanan backend-nya adalah EXTERNAL_MANAGED, cookie klien tidak akan dihormati. Load Balancer Aplikasi eksternal global mengabaikan cookie dan membuat cookie baru.

Me-roll back resource yang dimigrasikan

Setelah memigrasikan resource, jika 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.

Untuk mengembalikan layanan backend ke skema EXTERNAL, Anda harus mengembalikan aturan penerusan. Mengembalikan aturan penerusan ke skema EXTERNAL tidak memerlukan pengembalian layanan backend.

Untuk melakukan rollback resource, ikuti langkah-langkah berikut:

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

Ubah skema load balancing aturan penerusan dari EXTERNAL_MANAGED ke EXTERNAL.
Kembalikan 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. Kembalikan bucket backend ke status pra-migrasi.
Kembalikan layanan backend.
1. Tetapkan 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. Kembalikan layanan backend ke status sebelum migrasi.

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

Melacak proses migrasi

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 monitoring 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 headernya adalah EXTERNAL, permintaan akan diarahkan ke infrastruktur Load Balancer Aplikasi klasik. Jika nilainya EXTERNAL_MANAGED, nilai tersebut akan merutekan permintaan 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 Application Load Balancer klasik, nilainya adalah EXTERNAL. Jika permintaan dirutekan melalui infrastruktur Load Balancer Aplikasi eksternal global, nilainya adalah EXTERNAL_MANAGED.