Cara kerja Elastic Load Balancing

Penyeimbang beban menerima lalu lintas masuk dari klien dan merutekan permintaan ke target terdaftarnya (seperti EC2 instance) di satu atau beberapa Availability Zone. Load Balancer juga memantau kesehatan target yang terdaftar dan memastikan untuk mengarahkan lalu lintas hanya ke target yang sehat. Ketika Load Balancer mendeteksi target yang tidak sehat, maka routing lalu lintas ke target tersebut akan terhenti. Kemudian akan melanjutkan routing lalu lintas ke target ketika mendeteksi bahwa target sehat kembali.

Anda mengkonfigurasi load balncer Anda untuk menerima lalu lintas masuk dengan menentukan satu atau lebihpendengar. Seorang pendengar adalah proses yang memeriksa permintaan koneksi. Permintaan koneksi dikonfigurasi dengan protokol dan nomor port untuk koneksi dari klien ke Load Balancer. Demikian juga, dikonfigurasi dengan protokol dan nomor port untuk koneksi dari Load Balancer ke target.

Elastic Load Balancing mendukung jenis Load Balancer berikut:

• Application Load Balancer

• Network Load Balancers

• Gateway Load Balancer

• Classic Load Balancer

Ada perbedaan utama dalam bagaimana jenis Load Balancer dikonfigurasi. Dengan Application Load Balancer, Load Balancer Jaringan, dan Load Balancer Gateway, Anda daftarkan target-target dalam grup target, dan merutekan lalu lintas ke grup target. Dengan Classic Load Balancer, instans didaftarkan dengan Load Balancer.

Availability Zone dan node Load Balancer

Saat Anda mengaktifkan Availability Zone untuk Load Balancer, Elastic Load Balancing akan menciptakan node Load Balancer di Availability Zone. Jika Anda mendaftarkan target di Availability Zone tetapi tidak mengaktifkannya, target yang telah terdaftar ini tidak menerima lalu lintas. Load Balancer Anda paling efektif bila Anda memastikan bahwa setiap Availability Zone yang diaktifkan memiliki setidaknya satu target yang sudah terdaftar.

Disarankan untuk mengaktifkan beberapa Availability Zone untuk semua load balancer. Tapi, dengan Application Load Balancer, Anda harus mengaktifkan setidaknya dua atau lebih Availability Zone. Konfigurasi ini membantu memastikan bahwa Load Balancer dapat terus merutekan lalu lintas. Jika satu Availability Zone menjadi tidak tersedia atau tidak memiliki target yang sehat, Load Balancer dapat mengarahkan lalu lintas ke target sehat di Availability Zone lain.

Setelah Anda menonaktifkan Availability Zone, target di Availability Zone tetap terdaftar dengan Load Balancer. Namun, meskipun target-target tersebut tetap terdaftar, Load Balancer tidak mengarahkan lalu lintas ke target-target itu.

Penyeimbangan beban lintas-zona

Node untuk Load Balancer Anda mendistribusikan permintaan dari klien ke target yang telah terdaftar. Ketika load balancing lintas zona diaktifkan, setiap node Load Balancer mendistribusikan lalu lintas di seluruh target yang terdaftar di semua Availability Zone yang telah diaktifkan. Ketika load balancing lintas zona dinonaktifkan, setiap node Load Balancer mendistribusikan lalu lintas hanya di target yang telah terdaftar di Availability Zonenya.

Diagram berikut menunjukkan efek penyeimbangan beban lintas zona dengan round robin sebagai algoritma routing default. Ada dua Availability Zone yang diaktifkan, dengan dua target di Availability Zone A dan delapan target di Availability Zone B. Klien mengirim permintaan, dan Amazon Route 53 menanggapi setiap permintaan dengan alamat IP dari salah satu node Load Balancer. Berdasarkan algoritma routing round robin, lalu lintas didistribusikan sedemikian rupa sehingga setiap node penyeimbang beban menerima 50% lalu lintas dari klien. Setiap node Load Balancer mendistribusikan pangsa lalu lintas di target yang sudah terdaftar dalam ruang lingkupnya.

Jika load balancing lintas zona diaktifkan, masing-masing dari 10 target menerima 10% dari lalu lintas. Hal ini karena setiap node Load Balancer dapat merutekan 50% dari lalu lintas klien ke semua 10 target.

Jika load balancing lintas zona dinonaktifkan:

• Masing-masing dari dua target di Availability Zone A menerima 25% dari lalu lintas.

• Masing-masing dari delapan target di Availability Zone B menerima 6,25% dari lalu lintas.

Hal ini karena setiap node Load Balancer dapat merutekan 50% dari lalu lintas klien hanya untuk target di Availability Zonenya.

Dengan Application Load Balancers, penyeimbangan beban lintas zona selalu diaktifkan pada tingkat penyeimbang beban. Pada tingkat kelompok sasaran, penyeimbangan beban lintas zona dapat dinonaktifkan. Untuk informasi selengkapnya, lihat Menonaktifkan penyeimbangan beban lintas zona di Panduan Pengguna untuk Penyeimbang Beban Aplikasi.

Dengan Load Balancers Jaringan dan Load Balancers Gateway, load balancing lintas zona dinonaktifkan secara default. Setelah Anda membuat Load Balancer, Anda dapat mengaktifkan atau menonaktifkan load balancing lintas zona setiap saat. Untuk informasi selengkapnya, lihat Penyeimbangan beban lintas zona di Panduan Pengguna untuk Penyeimbang Beban Jaringan.

Saat Anda membuat Classic Load Balancer, default untuk load balancing lintas zona tergantung pada cara Anda membuat Load Balancer. Dengan API atauCLI, penyeimbangan beban lintas zona dinonaktifkan secara default. Dengan AWS Management Console, opsi untuk mengaktifkan penyeimbangan beban lintas zona dipilih secara default. Setelah membuat Classic Load Balancer, Anda dapat mengaktifkan atau menonaktifkan penyeimbangan beban lintas zona kapan saja. Untuk informasi selengkapnya, lihatAktifkan penyeimbangan beban lintas zonadiPanduan Pengguna untuk Classic Load Balancer.

Pergeseran zona

Zonal shift adalah kemampuan di Amazon Application Recovery Controller (ARC) (ARC). Dengan pergeseran zona, Anda dapat mengalihkan sumber daya penyeimbang beban dari Availability Zone yang terganggu dengan satu tindakan. Dengan cara ini, Anda dapat terus beroperasi dari Availability Zone sehat lainnya di file Wilayah AWS.

Saat Anda memulai pergeseran zona, penyeimbang beban Anda berhenti mengirimkan lalu lintas untuk sumber daya ke Availability Zone yang terpengaruh. ARCmenciptakan pergeseran zona segera. Namun, dibutuhkan waktu singkat, biasanya hingga beberapa menit, untuk menyelesaikan koneksi yang ada dan sedang berlangsung di Availability Zone yang terpengaruh. Untuk informasi selengkapnya, lihat Cara kerja pergeseran zona: pemeriksaan kesehatan dan alamat IP zonal di Panduan Pengembang Amazon Application Recovery Controller (ARC).

Pergeseran zona hanya didukung pada Application Load Balancers dan Network Load Balancer dengan penyeimbangan beban lintas zona dimatikan. Jika Anda mengaktifkan penyeimbangan beban lintas zona, Anda tidak dapat memulai pergeseran zona. Untuk informasi selengkapnya, lihat Sumber daya yang didukung untuk pergeseran zona di Panduan Pengembang Amazon Application Recovery Controller (ARC).

Sebelum Anda menggunakan pergeseran zona, tinjau hal-hal berikut:

• Penyeimbangan beban lintas zona tidak didukung dengan pergeseran zona. Anda harus mematikan penyeimbangan beban lintas zona untuk menggunakan kemampuan ini.

• Pergeseran zona tidak didukung saat Anda menggunakan Application Load Balancer sebagai titik akhir akselerator di. AWS Global Accelerator

• Anda dapat memulai pergeseran zona untuk penyeimbang beban tertentu hanya untuk satu Availability Zone. Anda tidak dapat memulai pergeseran zona untuk beberapa Availability Zone.

• AWS secara proaktif menghapus alamat IP penyeimbang beban zonal dari DNS saat beberapa masalah infrastruktur berdampak pada layanan. Selalu periksa kapasitas Availability Zone saat ini sebelum Anda memulai pergeseran zona. Jika penyeimbang beban Anda mematikan penyeimbang beban lintas zona dan Anda menggunakan pergeseran zona untuk menghapus alamat IP penyeimbang beban zonal, Availability Zone yang terpengaruh oleh pergeseran zona juga kehilangan kapasitas target.

• Ketika Application Load Balancer adalah target Network Load Balancer, selalu mulai pergeseran zona dari Network Load Balancer. Jika Anda memulai pergeseran zona dari Application Load Balancer, Network Load Balancer tidak mengenali shift dan terus mengirim lalu lintas ke Application Load Balancer.

Untuk panduan dan informasi selengkapnya, lihat Praktik terbaik dengan pergeseran ARC zona Route 53 di Panduan Pengembang Amazon Application Recovery Controller (ARC).

Meminta perutean

Sebelum klien mengirim permintaan ke penyeimbang beban Anda, klien menyelesaikan nama domain penyeimbang beban menggunakan server Domain Name System (). DNS DNSEntri dikendalikan oleh Amazon, karena penyeimbang beban Anda ada di domain. amazonaws.com DNSServer Amazon mengembalikan satu atau lebih alamat IP ke klien. Ini adalah alamat IP dari node Load Balancer untuk Load Balancer Anda. Dengan Network Load Balancers, Elastic Load Balancing menciptakan antarmuka jaringan untuk setiap Availability Zone yang Anda aktifkan, dan menggunakannya untuk mendapatkan alamat IP statis. Anda dapat secara opsional mengaitkan satu alamat IP Elastis dengan setiap antarmuka jaringan saat Anda membuat Network Load Balancer.

Karena lalu lintas ke aplikasi Anda berubah seiring waktu, Elastic Load Balancing menskalakan penyeimbang beban Anda dan memperbarui entri. DNS DNSEntri ini juga menentukan time-to-live (TTL) dari 60 detik. Hal ini membantu memastikan bahwa alamat IP dapat dipetakan kembali dengan cepat dalam menanggapi perubahan lalu lintas.

Klien menentukan alamat IP mana yang akan digunakan untuk mengirim permintaan ke Load Balancer. Simpul Load Balancer yang menerima permintaan memilih target sehat yang telah terdaftar dan mengirimkan permintaan ke target menggunakan alamat IP pribadi.

Untuk informasi selengkapnya, lihat Merutekan lalu lintas ke penyeimbang ELB beban di Panduan Pengembang Amazon Route 53.

Algoritma perutean

Dengan Application Load Balancer, simpul Load Balancer yang menerima permintaan menggunakan proses berikut:

1. Mengevaluasi aturan pendengar dalam rangka prioritas untuk menentukan aturan yang diterapkan.

2. Memilih target dari grup target untuk tindakan aturan, menggunakan algoritma routing yang dikonfigurasi untuk grup target. Algoritma routing default adalah round robin. Routing dilakukan secara mandiri untuk setiap grup target, bahkan ketika target telah terdaftar dengan beberapa kelompok target.

Dengan Load Balancer Jaringan, simpul Load Balancer yang menerima sambungan menggunakan proses berikut:

1. Memilih target dari kelompok target untuk aturan default menggunakan algoritma aliran hash. Ini mendasarkan algoritma pada:

   • Protokol

   • Alamat IP sumber dan port sumber

   • Alamat IP tujuan dan port tujuan

   • Nomor TCP urut

2. Rutekan setiap TCP koneksi individu ke satu target untuk masa pakai koneksi. TCPKoneksi dari klien memiliki port sumber dan nomor urut yang berbeda, dan dapat dialihkan ke target yang berbeda.

Dengan Classic Load Balancer, node Load Balancer yang menerima permintaan memilih instans yang telah terdaftar sebagai berikut:

• Menggunakan algoritma routing round robin untuk pendengar TCP

• Menggunakan algoritma perutean permintaan yang paling tidak menonjol untuk HTTP dan HTTPS pendengar

HTTPkoneksi

Classic Load Balancer menggunakan koneksi-koneksi pra-terbuka, tetapi Balancers Load Aplikasi tidak menggunakan koneksi-koneksi tersebut. Baik Classic Load Balancers dan Application Load Balancer menggunakan koneksi multiplexing. Ini berarti bahwa permintaan dari beberapa klien pada beberapa koneksi-koneksi front-end dapat dirutekan ke target yang diberikan melalui koneksi backend tunggal. Koneksi multiplexing meningkatkan latensi dan mengurangi beban pada aplikasi Anda. Untuk mencegah multiplexing koneksi, nonaktifkan HTTP keep-alive header dengan mengatur Connection: close header dalam tanggapan Anda. HTTP

Application Load Balancers dan Classic Load Balancers mendukung HTTP pipelined pada koneksi front-end. Mereka tidak mendukung pipelined HTTP pada koneksi backend.

Application Load Balancers mendukung metode HTTP permintaan berikut:GET,,HEAD,POST,PUT, DELETEOPTIONS, dan. PATCH

Application Load Balancers mendukung protokol berikut pada koneksi front-end: HTTP /0.9, /1.0, /1.1, dan /2. HTTP HTTP HTTP Anda dapat menggunakan HTTP /2 hanya dengan HTTPS pendengar, dan dapat mengirim hingga 128 permintaan secara paralel menggunakan satu HTTP koneksi /2. Application Load Balancers juga mendukung peningkatan koneksi dari ke. HTTP WebSockets Namun, jika ada peningkatan koneksi, aturan dan AWS WAF integrasi perutean pendengar Application Load Balancer tidak lagi berlaku.

Application Load Balancers menggunakan HTTP /1.1 pada koneksi backend (penyeimbang beban ke target terdaftar) secara default. Namun, Anda dapat menggunakan versi protokol untuk mengirim permintaan ke target menggunakan HTTP /2 atau gRPC. Untuk informasi selengkapnya, lihat Versi protokol. keep-aliveHeader didukung pada koneksi backend secara default. Untuk permintaan HTTP /1.0 dari klien yang tidak memiliki header host, penyeimbang beban menghasilkan header host untuk permintaan HTTP /1.1 yang dikirim pada koneksi backend. Header host berisi DNS nama penyeimbang beban.

Classic Load Balancer mendukung protokol berikut pada koneksi front-end (client to load balancer): /0.9, /1.0, dan /1.1. HTTP HTTP HTTP Mereka menggunakan HTTP /1.1 pada koneksi backend (penyeimbang beban ke target terdaftar). keep-aliveHeader didukung pada koneksi backend secara default. Untuk permintaan HTTP /1.0 dari klien yang tidak memiliki header host, penyeimbang beban menghasilkan header host untuk permintaan HTTP /1.1 yang dikirim pada koneksi backend. Header host berisi alamat IP dari node Load Balancer.

HTTPheader

Application Load Balancer dan Load Balancers Klasik secara otomatis ditambahkanX-Forwarded-For,X-Forwarded-Proto, danX–Forwarded-PortHeader untuk permintaan.

Application Load Balancers mengonversi nama host di header HTTP host menjadi huruf kecil sebelum mengirimnya ke target.

Untuk koneksi front-end yang menggunakan HTTP /2, nama header dalam huruf kecil. Sebelum permintaan dikirim ke target menggunakan HTTP /1.1, nama header berikut dikonversi ke kasus campuran: X-Forwarded-For, X-Forwarded-Proto, X-Forwarded-Port, Host, X-Amzn-Trace-Id, Upgrade, dan Connection. Semua nama header lainnya dalam huruf kecil.

Application Load Balancer dan Classic Load Balancer menerima header koneksi dari permintaan klien yang masuk setelah proxy respon kembali ke klien.

Ketika Application Load Balancers dan Classic Load Balancers menggunakan HTTP /1.1 menerima header Expect: 100-Continue, mereka segera merespons dengan HTTP/1.1 100 Continue tanpa menguji header panjang konten. Header permintaan Expect: 100-Continue tidak diteruskan ke targetnya.

Saat menggunakan HTTP /2, Application Load Balancers tidak mendukung header Expect: 100-Continue dari permintaan klien. Application Load Balancer tidak akan merespons dengan HTTP/2 100 Lanjutkan atau meneruskan header ini ke targetnya.

HTTPbatas header

Batas ukuran berikut untuk Application Load Balancer adalah batas keras yang tidak dapat diubah:

• Baris permintaan: 16 K

• Header tunggal: 16 K

• Seluruh header respons: 32 K

• Seluruh header permintaan: 64 K

Skema Load Balancer

Bila Anda membuat Load Balancer, Anda harus memilih apakah akan menjadikannya internal atau menghadap-internet.

Simpul Load Balancer menghadap-internet memiliki alamat IP publik. DNSNama penyeimbang beban yang menghadap ke internet dapat diselesaikan secara publik ke alamat IP publik node. Oleh karena itu, Load Balancer yang menghadap internet dapat merutekan permintaan dari klien melalui internet.

Simpul penyeimbang beban internal hanya memiliki alamat IP privat. DNSNama penyeimbang beban internal dapat diselesaikan secara publik ke alamat IP pribadi node. Oleh karena itu, penyeimbang beban internal hanya dapat merutekan permintaan dari klien dengan akses ke VPC penyeimbang beban.

Baik Load Balancer yang menghadap-internet maupun internal merutekan permintaan ke target Anda menggunakan alamat IP pribadi. Oleh karena itu, target Anda tidak perlu alamat IP publik untuk menerima permintaan dari Load Balancer internal atau yang menghadap internet.

Jika aplikasi Anda memiliki beberapa tingkatan, Anda dapat merancang arsitektur yang menggunakan Load Balancer internal dan menghadap-internet. Misalnya, langkah ini berlaku jika aplikasi Anda menggunakan server web yang harus terhubung ke internet, dan server aplikasi yang hanya terhubung ke server web. Buat Load Balancer yang menghadap internet dan daftarkan server web dengannya. Buat Load Balancer internal dan daftarkan server aplikasi dengannya. Server web menerima permintaan dari Load Balancer menghadap internet dan mengirim permintaan untuk server aplikasi ke Load Balancer internal. Server aplikasi menerima permintaan dari Load Balancer internal.

Jenis alamat IP

Jenis alamat IP yang Anda tentukan untuk penyeimbang beban menentukan bagaimana klien dapat berkomunikasi dengan penyeimbang beban.

• IPv4Hanya — Klien berkomunikasi menggunakan IPv4 alamat publik dan pribadi. Subnet yang Anda pilih untuk penyeimbang beban Anda harus memiliki rentang IPv4 alamat.

• Dualstack — Klien berkomunikasi menggunakan publik dan pribadi IPv4 dan IPv6 alamat. Subnet yang Anda pilih untuk penyeimbang beban Anda harus memiliki IPv4 dan rentang IPv6 alamat.

• Dualstack tanpa publik IPv4 — Klien berkomunikasi menggunakan alamat publik dan pribadi dan IPv6 alamat pribadiIPv4. Subnet yang Anda pilih untuk penyeimbang beban Anda harus memiliki IPv4 dan rentang IPv6 alamat. Opsi ini tidak didukung dengan skema penyeimbang internal beban.

Tabel berikut menjelaskan jenis alamat IP yang didukung untuk setiap jenis penyeimbang beban.

Tipe penyeimbang beban	IPv4hanya	Tumpukan ganda	Dualstack tanpa publik IPv4
Penyeimbang Beban Aplikasi	Ya	Ya	Ya
Penyeimbang Beban Jaringan	Ya	Ya	Tidak
Penyeimbang Beban Gateway	Ya	Ya	Tidak
Classic Load Balancer	Ya	Tidak	Tidak

Jenis alamat IP yang Anda tentukan untuk grup target menentukan bagaimana penyeimbang beban dapat berkomunikasi dengan target.

• IPv4hanya — Penyeimbang beban berkomunikasi menggunakan alamat pribadiIPv4. Anda harus mendaftarkan target dengan IPv4 alamat dengan grup IPv4 target.

• IPv6hanya — Penyeimbang beban berkomunikasi menggunakan IPv6 alamat. Anda harus mendaftarkan target dengan IPv6 alamat dengan grup IPv6 target. Kelompok target harus digunakan dengan penyeimbang beban dualstack.

Tabel berikut menjelaskan jenis alamat IP yang didukung untuk setiap protokol grup target.

Protokol grup target	IPv4hanya	IPv6hanya
HTTPdan HTTPS	Ya	Ya
TCP	Ya	Ya
TLS	Ya	Ya
UDPdan TCP _ UDP	Ya	Tidak
GENEVE	-	-

Jaringan MTU untuk penyeimbang beban Anda

Unit transmisi maksimum (MTU) menentukan ukuran, dalam byte, untuk paket terbesar yang dapat dikirim melalui jaringan. Semakin MTU besar koneksi, semakin banyak data yang dapat dilewatkan dalam satu paket. Frame Ethernet terdiri dari paket, atau data aktual yang Anda kirim, dan informasi informasi overhead jaringan yang mengelilinginya. Lalu lintas yang dikirim melalui gateway internet memiliki MTU 1500. Ini berarti bahwa jika sebuah paket lebih dari 1500 byte, itu terfragmentasi untuk dikirim menggunakan beberapa frame, atau dijatuhkan jika Don't Fragment diatur dalam header IP.

MTUUkuran pada node penyeimbang beban tidak dapat dikonfigurasi. Jumbo frame (9001MTU) adalah standar di seluruh node penyeimbang beban untuk Application Load Balancers, Network Load Balancers, dan Classic Load Balancers. Gateway Load Balancers mendukung 8500. MTU Untuk informasi selengkapnya, lihat Unit transmisi maksimum (MTU) di Panduan Pengguna untuk Penyeimbang Beban Gateway.

Path MTU adalah ukuran paket maksimum yang didukung pada jalur antara host asal dan host penerima. Path MTU Discovery (PMTUD) digunakan untuk menentukan jalur MTU antara dua perangkat. Path MTU Discovery sangat penting jika klien atau target tidak mendukung jumbo frame.

Ketika host mengirim paket yang lebih besar dari host penerima atau lebih besar dari perangkat di sepanjang jalur, host penerima atau perangkat menjatuhkan paket, dan kemudian mengembalikan ICMP pesan berikut: MTU MTU Destination Unreachable: Fragmentation Needed and Don't Fragment was Set (Type 3, Code 4) Pesan ini menginstruksikan host pemancar untuk membagi muatan menjadi beberapa paket yang lebih kecil, dan mengirimkan ulang muatan tersebut.

Jika paket yang lebih besar dari MTU ukuran klien atau antarmuka target terus dijatuhkan, kemungkinan Path MTU Discovery (PMTUD) tidak berfungsi. Untuk menghindari hal ini, pastikan Path MTU Discovery bekerja dari ujung ke ujung, dan Anda telah mengaktifkan bingkai jumbo pada klien dan target Anda. Untuk informasi selengkapnya tentang Path MTU Discovery dan mengaktifkan jumbo frame, lihat Path MTU Discovery di EC2Panduan Pengguna Amazon.