Pengoptimalan load balancing lanjutan

Pratinjau

Produk atau fitur ini tunduk pada "Persyaratan Penawaran Pra-GA" di bagian Persyaratan Layanan Umum di Persyaratan Khusus Layanan. Produk dan fitur pra-GA tersedia "sebagaimana adanya" dan mungkin memiliki dukungan terbatas. Untuk mengetahui informasi selengkapnya, lihat deskripsi tahap peluncuran.

Catatan: Saat ini, kebijakan load balancing layanan dipengaruhi oleh masalah umum, yang menyebabkan traffic mungkin tidak diarahkan secara merata ke semua instance virtual machine (VM) di zona tertentu. Anda dapat mengisi formulir ini agar diizinkan untuk memperbaiki masalah ini lebih awal. Anda masih dapat mencoba kebijakan load balancing layanan, baik Anda masuk dalam daftar yang diizinkan maupun tidak.

Halaman ini menjelaskan cara menggunakan kebijakan load balancing layanan untuk mendukung pengoptimalan biaya, latensi, dan ketahanan lanjutan untuk load balance berikut:

• Load Balancer Aplikasi eksternal global
• Load Balancer Aplikasi internal lintas region
• Load Balancer Jaringan proxy eksternal global
• Load Balancer Jaringan proxy internal lintas region

Traffic Director juga mendukung pengoptimalan load balancing lanjutan. Untuk mengetahui detailnya, lihat Ringkasan load balancing lanjutan dalam dokumentasi Traffic Director.

Kebijakan load balancing layanan (serviceLbPolicy) adalah resource yang terkait dengan layanan backend load balancer. Kebijakan load balancing layanan memungkinkan Anda menyesuaikan parameter yang memengaruhi cara traffic didistribusikan dalam backend yang terkait dengan layanan backend:

• Sesuaikan algoritma load balancing yang digunakan untuk menentukan cara traffic didistribusikan dalam region atau zona tertentu.
• Aktifkan pengosongan kapasitas otomatis sehingga load balancer dapat dengan cepat menguras traffic dari backend yang tidak responsif.
• Tetapkan batas failover untuk menentukan kapan backend dianggap tidak responsif. Hal ini memungkinkan traffic menggagalkan traffic ke backend yang berbeda untuk menghindari backend yang tidak responsif.

Selain itu, Anda dapat menetapkan backend tertentu sebagai backend pilihan. Backend ini harus digunakan untuk kapasitas sebelum permintaan dikirim ke backend yang tersisa.

Diagram berikut menunjukkan cara Cloud Load Balancing mengevaluasi perutean, load balancing, dan distribusi traffic.

Cara Cloud Load Balancing membuat keputusan distribusi traffic dan perutean.

Sebelum memulai

Sebelum meninjau konten halaman ini, tinjau dengan cermat Proses distribusi permintaan yang dijelaskan di halaman ringkasan Load Balancer Aplikasi Eksternal. Untuk load balancer yang selalu Paket Premium, semua algoritma load balancing yang dijelaskan di halaman ini mendukung berpindah antar-region jika region pilihan pertama sudah penuh.

Backend yang didukung

Kebijakan load balancing layanan dan backend pilihan hanya dapat dikonfigurasi di load balancer yang menggunakan backend yang didukung, seperti yang ditunjukkan dalam tabel berikut.

Backend	Didukung?
Grup instance Tidak dikelola Dikelola menurut zona
MIG Regional
NEG Zona (GCE_VM_IP_PORT endpoint)
NEG campuran (NON_GCP_PRIVATE_IP_PORT endpoint)
NEG Serverless
NEG Internet
NEG Private Service Connect

Algoritma load balancing

Bagian ini menjelaskan algoritma load balancing yang dapat Anda konfigurasi dalam kebijakan load balancing layanan. Jika Anda tidak mengonfigurasi algoritme, atau tidak mengonfigurasi kebijakan load balancing layanan sama sekali, load balancer akan menggunakan WATERFALL_BY_REGION secara default.

Waterfall menurut wilayah

WATERFALL_BY_REGION adalah algoritma load balancing default. Dengan algoritma ini, secara agregat, semua Google Front End (GFE) di suatu region mencoba mengisi backend secara proporsional dengan kapasitas target yang dikonfigurasi (dimodifikasi oleh scaler kapasitasnya).

Setiap GFE lapisan kedua memilih untuk memilih backend atau endpoint di zona yang sedekat mungkin (ditentukan oleh waktu round-trip jaringan) dengan GFE lapisan kedua. Karena WATERFALL_BY_REGION meminimalkan latensi antar-zona, dengan kecepatan permintaan yang rendah, setiap GFE lapisan kedua dapat secara eksklusif mengirim permintaan ke backend di zona pilihan GFE lapisan kedua.

Semprotkan ke wilayah

Algoritma SPRAY_TO_REGION mengubah perilaku individu setiap GFE lapisan kedua apabila setiap GFE lapisan kedua tidak memiliki preferensi untuk memilih backend atau endpoint yang berada dalam zona sedekat mungkin dengan GFE lapisan kedua. Dengan SPRAY_TO_REGION, setiap GFE lapisan kedua mengirimkan permintaan ke semua instance atau endpoint backend, di semua zona region, tanpa preferensi untuk waktu round-trip yang lebih singkat antara GFE lapisan kedua dan instance atau endpoint backend.

Seperti WATERFALL_BY_REGION, secara gabungan, semua GFE lapisan kedua di region mengisi backend sesuai dengan kapasitas target yang dikonfigurasi (dimodifikasi oleh scaler kapasitasnya).

Meskipun SPRAY_TO_REGION menyediakan distribusi yang lebih seragam di antara backend di semua zona region, terutama dengan rasio permintaan yang rendah, distribusi seragam ini memiliki pertimbangan berikut:

• Saat backend berhenti berfungsi (tetapi terus lulus health check-nya), lebih banyak GFE lapisan kedua yang terpengaruh, meskipun dampak individu tidak terlalu serius.
• Karena setiap GFE lapisan kedua tidak memiliki preferensi untuk satu zona di atas zona lain, GFE lapisan kedua membuat lebih banyak traffic lintas zona. Bergantung pada jumlah permintaan yang diproses, setiap GFE lapisan kedua mungkin juga membuat lebih banyak koneksi TCP ke backend.

Waterfall berdasarkan zona

Algoritma WATERFALL_BY_ZONE mengubah perilaku individu setiap GFE lapisan kedua sejauh setiap GFE lapisan kedua memiliki preferensi yang sangat kuat untuk memilih endpoint atau endpoint backend yang berada di zona yang paling dekat dengan GFE lapisan kedua. Dengan WATERFALL_BY_ZONE, setiap GFE lapisan kedua hanya mengirimkan permintaan ke instance backend atau endpoint di zona lain dalam region tersebut saat GFE lapisan kedua telah mengisi endpoint atau endpoint backend di zona yang paling disukainya.

Seperti WATERFALL_BY_REGION, secara gabungan, semua GFE lapisan kedua di region mengisi backend sesuai dengan kapasitas target yang dikonfigurasi (dimodifikasi oleh scaler kapasitasnya).

Algoritma WATERFALL_BY_ZONE meminimalkan latensi dengan pertimbangan berikut:

• WATERFALL_BY_ZONE tidak secara inheren meminimalkan koneksi lintas zona. Algoritma diarahkan hanya oleh latensi.
• WATERFALL_BY_ZONE tidak menjamin bahwa setiap GFE lapisan kedua selalu mengisi zona yang paling disukainya sebelum mengisi zona lainnya. Peristiwa pemeliharaan dapat menyebabkan semua traffic dari GFE lapisan kedua dikirim ke instance backend atau endpoint di zona lain untuk sementara.
• WATERFALL_BY_ZONE dapat menyebabkan distribusi permintaan yang kurang seragam di antara semua endpoint atau endpoint backend dalam region secara keseluruhan. Misalnya, instance backend atau endpoint di zona yang paling disukai GFE lapisan kedua mungkin diisi sesuai kapasitas, sedangkan backend di zona lain tidak diisi hingga kapasitas.

Membandingkan algoritma load balancing

Tabel berikut membandingkan berbagai algoritma load balancing.

Perilaku	Waterfall menurut wilayah	Semprotkan ke wilayah	Waterfall berdasarkan zona
Penggunaan kapasitas yang seragam dalam satu region	Ya	Ya	Tidak
Penggunaan kapasitas yang seragam di beberapa region	Tidak	Tidak	Tidak
Pemisahan traffic yang seragam dari load balancer	Tidak	Ya	Tidak
Distribusi traffic lintas zona	Ya. Traffic didistribusikan secara merata di seluruh zona dalam suatu region sambil mengoptimalkan latensi jaringan. Traffic mungkin dikirim lintas zona jika diperlukan.	Ya	Ya. Lalu lintas akan terlebih dahulu masuk ke zona terdekat sampai sesuai kapasitasnya. Kemudian, diteruskan ke zona terdekat berikutnya.
Sensitivitas terhadap lonjakan traffic di zona lokal	Rata-rata; bergantung pada jumlah traffic yang telah dialihkan untuk menyeimbangkan lintas zona.	Lebih rendah; lonjakan zona tunggal tersebar di semua zona di region tersebut.	Lebih tinggi; lonjakan zona tunggal kemungkinan akan disalurkan sepenuhnya oleh zona yang sama hingga load balancer dapat bereaksi.

Pengosongan kapasitas otomatis

Jika backend tidak responsif, Anda biasanya ingin mengecualikannya dari keputusan load balancing secepat mungkin. Mengecualikan backend yang tidak responsif akan mengoptimalkan latensi keseluruhan dengan mengirimkan traffic hanya ke backend yang responsif.

Saat Anda mengaktifkan fitur pengosongan kapasitas otomatis, load balancer akan otomatis menskalakan kapasitas backend ke nol jika kurang dari 25 persen instance atau endpoint backend lulus health check. Tindakan ini akan menghapus backend yang tidak responsif dari kumpulan load balancing global. Tindakan ini secara fungsional setara dengan menetapkan backendService.capacityScaler ke 0 untuk backend saat Anda ingin menghindari perutean traffic ke backend tersebut.

Jika 35 persen (10 persen di atas nilai minimum) dari instance atau endpoint backend yang sebelumnya dikuras secara otomatis lulus health check selama 60 detik, backend secara otomatis tidak akan digabungkan dan ditambahkan kembali ke kumpulan load balancing. Hal ini memastikan bahwa backend benar-benar responsif dan tidak terbalik antara status terkuras dan tidak tertahan.

Meskipun dengan pengosongan kapasitas otomatis diaktifkan, load balancer tidak menghabiskan lebih dari 50 persen backend yang terpasang ke layanan backend, terlepas dari status respons backend. Dengan memastikan 50 persen backend terpasang akan mengurangi risiko membebani backend yang responsif.

Salah satu kasus penggunaan pengosongan kapasitas otomatis adalah menggunakannya untuk meminimalkan risiko overload backend pilihan Anda. Misalnya, jika backend ditandai sebagai disukai, tetapi sebagian besar instance atau endpoint-nya tidak responsif, pengosongan kapasitas otomatis akan menghapus backend dari kumpulan load balancing. Alih-alih membebani instance atau endpoint responsif yang tersisa di backend pilihan, pengosongan kapasitas otomatis mengalihkan traffic ke backend lain.

Anda dapat mengaktifkan pengosongan kapasitas otomatis sebagai bagian dari kebijakan load balancing layanan. Untuk mengetahui detailnya, lihat Mengonfigurasi kebijakan load balancing layanan.

Kapasitas otomatis tidak didukung dengan backend yang tidak menggunakan mode penyeimbangan. Hal ini mencakup backend seperti NEG internet, NEG serverless, dan NEG PSC.

Ambang failover

Load balancer menentukan distribusi traffic di antara backend secara multi-level. Dalam keadaan stabil, sistem akan mengirimkan traffic ke backend yang dipilih berdasarkan salah satu algoritma load balancing yang telah dijelaskan sebelumnya. Backend ini, yang disebut backend primer, dianggap optimal dalam hal latensi dan kapasitas.

Load balancer juga melacak backend lain yang dapat digunakan jika backend utama menjadi tidak responsif dan tidak dapat menangani traffic. Backend ini disebut backend failover. Backend ini biasanya merupakan backend terdekat dengan kapasitas yang tersisa.

Jika instance atau endpoint di backend utama menjadi tidak responsif, load balancer tidak akan langsung mengalihkan traffic ke backend lain. Sebagai gantinya, load balancer mengalihkan traffic ke instance atau endpoint lain yang responsif terlebih dahulu di backend yang sama untuk membantu menstabilkan beban traffic. Jika terlalu banyak endpoint di backend utama yang tidak responsif, dan endpoint yang tersisa di backend yang sama tidak dapat menangani traffic tambahan, load balancer akan menggunakan nilai minimum failover untuk menentukan kapan harus mulai mengirim traffic ke backend failover. Load balancer ini menoleransi kondisi tidak responsif di backend utama hingga batas failover. Setelah itu, traffic dialihkan dari backend utama.

Ambang batas failover adalah nilai antara 1 dan 99, yang dinyatakan sebagai persentase endpoint di backend yang harus responsif. Jika persentase endpoint yang responsif berada di bawah nilai minimum failover, load balancer akan mencoba mengirim traffic ke backend failover. Secara default, nilai minimum failover adalah 70.

Jika nilai minimum failover ditetapkan terlalu tinggi, tumpahan traffic yang tidak perlu dapat terjadi karena perubahan kondisi sementara. Jika nilai minimum failover ditetapkan terlalu rendah, load balancer terus mengirim traffic ke backend utama meskipun ada banyak endpoint yang tidak responsif.

Keputusan failover dilokalkan. Setiap Google Front End (GFE) lokal berperilaku secara terpisah. Anda bertanggung jawab untuk memastikan bahwa backend failover Anda dapat menangani traffic tambahan.

Traffic failover dapat menyebabkan backend kelebihan beban. Meskipun backend tidak responsif, load balancer mungkin masih mengirimkan traffic ke sana. Untuk mengecualikan backend yang tidak responsif dari kumpulan backend yang tersedia, aktifkan fitur pengosongan kapasitas otomatis.

Backend pilihan

Backend pilihan adalah backend yang kapasitasnya ingin Anda gunakan sepenuhnya sebelum menumpahkan traffic ke backend lain. Setiap traffic yang melebihi kapasitas backend pilihan yang dikonfigurasi akan dirutekan ke backend lain yang tidak diinginkan. Selanjutnya, algoritme load balancing mendistribusikan traffic antara backend yang tidak diinginkan pada layanan backend.

Anda dapat mengonfigurasi load balancer untuk memilih dan sepenuhnya menggunakan satu atau beberapa backend yang terpasang ke layanan backend sebelum mengarahkan permintaan berikutnya ke backend yang tersisa.

Pertimbangkan batasan berikut saat Anda menggunakan backend pilihan:

• Backend yang dikonfigurasi sebagai backend pilihan mungkin berada lebih jauh dari klien dan menghasilkan latensi rata-rata yang lebih tinggi untuk permintaan klien. Hal ini terjadi meskipun ada backend lain yang lebih dekat yang mungkin telah melayani klien dengan latensi yang lebih rendah.
• Algoritma load balancing tertentu (WATERFALL_BY_REGION, SPRAY_TO_REGION, dan WATERFALL_BY_ZONE) tidak berlaku untuk backend yang dikonfigurasi sebagai backend pilihan.

Untuk mempelajari cara menetapkan backend pilihan, lihat Menetapkan backend pilihan.

Mengonfigurasi kebijakan load balancing layanan

Catatan: Bagian ini mengasumsikan Anda telah memiliki pengetahuan tingkat menengah hingga lanjutan tentang Cloud Load Balancing. Langkah-langkah ini tidak menjelaskan pembuatan layanan backend atau konfigurasi load balancer dasar lainnya. Untuk menyiapkan penyiapan dasar terlebih dahulu, lihat dokumentasi load balancer masing-masing.

Resource kebijakan load balancing layanan memungkinkan Anda mengonfigurasi kolom berikut:

• Algoritma load balancing
• Pengosongan kapasitas otomatis
• Ambang failover

Untuk menetapkan backend pilihan, lihat Menetapkan backend pilihan.

Buat kebijakan

Untuk membuat dan mengonfigurasi kebijakan load balancing layanan, selesaikan langkah-langkah berikut:

1. Buat resource kebijakan load balancing layanan. Anda dapat melakukannya dengan menggunakan file YAML atau secara langsung menggunakan parameter gcloud.

   • Dengan file YAML. Anda menentukan kebijakan load balancing layanan dalam file YAML. Berikut ini contoh file YAML yang menunjukkan cara mengonfigurasi algoritma load balancing, mengaktifkan pengosongan kapasitas otomatis, dan menetapkan batas failover kustom:

     name: projects/PROJECT_ID/locations/global/serviceLbPolicies/SERVICE_LB_POLICY_NAME
     - autoCapacityDrain:
         enable: True
     - loadBalancingAlgorithm: LOAD_BALANCING_ALGORITHM
     - failoverConfig:
         failoverHealthThreshold: FAILOVER_THRESHOLD_VALUE
     

     Ganti kode berikut:

     • PROJECT_ID: project ID.
     • SERVICE_LB_POLICY_NAME: nama kebijakan load balancing layanan.
     • LOAD_BALANCING_ALGORITHM: algoritma load balancing yang akan digunakan. Ini dapat berupa SPRAY_TO_REGION, WATERFALL_BY_REGION, atau WATERFALL_BY_ZONE.
     • FAILOVER_THRESHOLD_VALUE: nilai batas failover. Ini harus berupa angka antara 1 dan 99.

     Setelah Anda membuat file YAML, impor file tersebut ke kebijakan load balancing layanan yang baru.

     gcloud beta network-services service-lb-policies import SERVICE_LB_POLICY_NAME \
      --source=PATH_TO_POLICY_FILE \
      --location=global
     

   • Tanpa file YAML. Atau, Anda dapat mengonfigurasi fitur kebijakan load balancing layanan tanpa menggunakan file YAML.

     Untuk menyetel algoritma load balancing dan mengaktifkan pengosongan otomatis, gunakan parameter berikut:

     gcloud beta network-services service-lb-policies create SERVICE_LB_POLICY_NAME \
      --load-balancing-algorithm=LOAD_BALANCING_ALGORITHM \
      --auto-capacity-drain \
      --failover-health-threshold=FAILOVER_THRESHOLD_VALUE \
      --location=global
     

     Ganti kode berikut:

     • SERVICE_LB_POLICY_NAME: nama kebijakan load balancing layanan.
     • LOAD_BALANCING_ALGORITHM: algoritma load balancing yang akan digunakan. Ini dapat berupa SPRAY_TO_REGION, WATERFALL_BY_REGION, atau WATERFALL_BY_ZONE.
     • FAILOVER_THRESHOLD_VALUE: nilai batas failover. Ini harus berupa angka antara 1 dan 99.

2. Update layanan backend agar kolom --service-lb-policy-nya merujuk ke resource kebijakan load balancing layanan yang baru dibuat. Layanan backend hanya dapat dikaitkan dengan satu resource kebijakan load balancing layanan.

   gcloud beta compute backend-services update BACKEND_SERVICE_NAME \
     --service-lb-policy=SERVICE_LB_POLICY_NAME \
     --global
   

   Anda dapat mengaitkan kebijakan load balancing layanan dengan layanan backend saat membuat layanan backend.

   gcloud beta compute backend-services create BACKEND_SERVICE_NAME \
       --protocol=PROTOCOL \
       --port-name=NAMED_PORT_NAME \
       --health-checks=HEALTH_CHECK_NAME \
       --load-balancing-scheme=LOAD_BALANCING_SCHEME \
       --service-lb-policy=SERVICE_LB_POLICY_NAME \
       --global
   

Menghapus kebijakan

Untuk menghapus kebijakan load balancing layanan dari layanan backend, gunakan perintah berikut:

gcloud beta compute backend-services update BACKEND_SERVICE_NAME \
    --no-service-lb-policy \
    --global

Menetapkan backend pilihan

Anda dapat mengonfigurasi backend pilihan menggunakan Google Cloud CLI atau API.

gcloud

Tambahkan backend pilihan

Untuk menetapkan backend pilihan, gunakan perintah gcloud beta compute backend-services add-backend untuk menetapkan tanda --preference saat Anda menambahkan backend ke layanan backend.

gcloud beta compute backend-services add-backend BACKEND_SERVICE_NAME \
    ...
    --preference=PREFERENCE \
    --global

Ganti PREFERENCE dengan tingkat preferensi yang ingin Anda tetapkan ke backend. Ini dapat berupa PREFERRED atau DEFAULT.

Perintah lainnya bergantung pada jenis backend yang Anda gunakan (grup instance atau NEG). Untuk semua parameter yang diperlukan, lihat perintah gcloud beta compute backend-services add-backend.

Memperbarui preferensi backend

Untuk memperbarui parameter --preference backend, gunakan perintah gcloud beta compute backend-services update-backend.

gcloud beta compute backend-services update-backend BACKEND_SERVICE_NAME \
    ...
    --preference=PREFERENCE \
    --global

Perintah lainnya bergantung pada jenis backend yang Anda gunakan (grup instance atau NEG). Perintah contoh berikut memperbarui preferensi grup instance backend dan menyetelnya ke PREFERRED:

gcloud beta compute backend-services update-backend BACKEND_SERVICE_NAME \
    --instance-group=INSTANCE_GROUP_NAME \
    --instance-group-zone=INSTANCE_GROUP_ZONE \
    --preference=PREFERRED \
    --global

API

Untuk menetapkan backend pilihan, tetapkan tanda preference di setiap backend dengan menggunakan resource backendServices global.

Berikut adalah contoh yang menunjukkan cara mengonfigurasi preferensi backend:

  name: projects/PROJECT_ID/locations/global/backendServices/BACKEND_SERVICE_NAME
  ...
  - backends
      name: BACKEND_1_NAME
      preference: PREFERRED
      ...
  - backends
      name: BACKEND_2_NAME
      preference: DEFAULT
      ...

Ganti kode berikut:

• PROJECT_ID: the project ID
• BACKEND_SERVICE_NAME: nama layanan backend
• BACKEND_1_NAME: nama backend yang disukai
• BACKEND_2_NAME: nama backend default

Pemecahan masalah

Pola distribusi traffic dapat berubah saat Anda menambahkan kebijakan load balancing layanan yang baru ke layanan backend.

Untuk men-debug masalah traffic, gunakan Cloud Monitoring untuk melihat alur traffic antara load balancer dan backend. Log dan metrik Cloud Load Balancing juga dapat membantu Anda memahami perilaku load balancing.

Bagian ini merangkum beberapa skenario umum yang mungkin Anda lihat dalam konfigurasi yang baru ditampilkan.

Traffic dari satu sumber dikirim ke terlalu banyak backend yang berbeda

Ini adalah perilaku yang diinginkan dari algoritma SPRAY_TO_REGION. Namun, Anda mungkin mengalami masalah yang disebabkan oleh distribusi traffic yang lebih luas. Misalnya, rasio cache ditemukan dapat menurun karena backend melihat traffic dari pilihan klien yang lebih luas. Dalam hal ini, pertimbangkan untuk menggunakan algoritma lain seperti WATERFALL_BY_REGION.

Traffic tidak dikirim ke backend yang memiliki banyak endpoint yang tidak responsif

Ini adalah perilaku yang dimaksudkan jika autoCapacityDrain diaktifkan. Backend dengan banyak endpoint yang tidak responsif akan dikosongkan dan dihapus dari kumpulan load balancing. Jika tidak menginginkan perilaku ini, Anda dapat menonaktifkan pengosongan kapasitas otomatis. Namun, ini berarti traffic dapat dikirim ke backend yang memiliki banyak endpoint yang tidak responsif dan permintaan dapat gagal.

Traffic dikirim ke backend yang lebih jauh sebelum backend yang lebih dekat

Ini adalah perilaku yang dimaksudkan jika backend pilihan Anda lebih jauh dari backend default Anda. Jika Anda tidak menginginkan perilaku ini, perbarui setelan preferensi untuk setiap backend.

Traffic tidak dikirim ke beberapa backend saat menggunakan backend pilihan

Ini adalah perilaku yang dimaksudkan jika backend pilihan Anda belum mencapai kapasitas. Backend pilihan akan ditetapkan terlebih dahulu berdasarkan latensi waktu bolak-balik ke backend ini.

Jika ingin traffic dikirim ke backend lain, Anda dapat melakukan salah satu langkah berikut:

• Perbarui setelan preferensi untuk backend lain.
• Tetapkan setelan kapasitas target yang lebih rendah untuk backend pilihan Anda. Kapasitas target dikonfigurasi menggunakan kolom max-rate atau max-utilization, bergantung pada mode keseimbangan layanan backend.

Traffic dikirim ke backend jarak jauh selama perubahan kondisi sementara

Ini adalah perilaku yang dimaksudkan saat nilai minimum failover ditetapkan ke nilai tinggi. Jika Anda ingin traffic tetap berjalan ke backend utama saat terjadi perubahan kondisi sementara, tetapkan kolom ini ke nilai yang lebih rendah.

Endpoint yang responsif kelebihan beban saat endpoint lainnya tidak responsif

Ini adalah perilaku yang dimaksudkan saat nilai minimum failover ditetapkan ke nilai yang rendah. Jika endpoint tidak responsif, traffic yang ditujukan untuk endpoint yang tidak responsif tersebut akan tersebar di antara endpoint yang tersisa pada backend yang sama. Jika Anda ingin perilaku failover dipicu lebih cepat, tetapkan kolom ini ke nilai yang lebih tinggi.

Batasan

• Setiap layanan backend hanya dapat dikaitkan dengan satu resource kebijakan load balancing layanan.