Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Cara kerja Elastic Load Balancing
Load Balancer menerima lalu lintas masuk dari klien dan merutekan permintaan untuk target yang telah terdaftar (seperti contoh EC2) dalam satu atau lebih 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.
Daftar Isi
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.
Cross-zone penyeimbangan beban
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 Cross-zone load balancing di Panduan Pengguna untuk Network Load Balancers.
Saat Anda membuat Classic Load Balancer, default untuk load balancing lintas zona tergantung pada cara Anda membuat Load Balancer. Dengan API atau CLI, load balancing lintas zona dinonaktifkan secara default. Dengan Konsol Manajemen AWS, 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.
Peralihan 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. ARC segera menciptakan pergeseran zona. 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).
Sebelum Anda menggunakan pergeseran zona, tinjau hal-hal berikut:
-
Pergeseran zona didukung saat Anda menggunakan Network Load Balancer dengan penyeimbang beban lintas zona diaktifkan atau dimatikan.
-
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 ketika 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.
Untuk panduan dan informasi selengkapnya, lihat Praktik terbaik untuk pergeseran zona di ARC di Panduan Pengembang Amazon Application Recovery Controller (ARC).
Meminta perutean
Sebelum klien mengirim permintaan ke Load Balancer Anda, nama domain Load Balancer diselesaikan menggunakan server Domain Name System (DNS). Entri DNS dikendalikan oleh Amazon, karena Load Balancer Anda berada di domain amazonaws.com. Amazon DNS server mengembalikan satu atau lebih alamat IP untuk 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.
Ketika lalu lintas ke aplikasi Anda berubah dari waktu ke waktu, Elastis Load Balancing mengukur beban Anda dan memperbarui entri DNS. Entri DNS juga menentukan waktu-untuk-hidup (TTL) 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 beban ELB di Panduan Pengembang Amazon Route 53.
Algoritma perutean
Dengan Application Load Balancer, simpul Load Balancer yang menerima permintaan menggunakan proses berikut:
-
Mengevaluasi aturan pendengar dalam rangka prioritas untuk menentukan aturan yang diterapkan.
-
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:
-
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 urut TCP
-
-
Rute=rute setiap koneksi TCP individu untuk satu target untuk kehidupan koneksi. Koneksi-koneksi TCP dari klien memiliki port sumber yang berbeda dan nomor urut, dan dapat diarahkan ke target yang berbeda.
Dengan Gateway Load Balancers, node penyeimbang beban yang menerima koneksi menggunakan algoritma hash aliran 5-tuple untuk memilih alat target. Setelah aliran terbentuk, semua paket untuk aliran yang sama secara konsisten diarahkan ke alat target yang sama. Penyeimbang beban dan peralatan target bertukar lalu lintas menggunakan protokol GENEVE pada port 6081.
Dengan Classic Load Balancer, node Load Balancer yang menerima permintaan memilih instans yang telah terdaftar sebagai berikut:
-
Menggunakan algoritma round robin routing untuk pendengar TCP
-
Menggunakan algoritma routing permintaan yang paling tidak beredar untuk HTTP dan HTTPS pendengar
Koneksi HTTP
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 keep-alive header HTTP dengan mengatur Connection: close header dalam respons HTTP Anda.
Application Load Balancer dan Balancers Beban Klasik mendukung HTTP pipelined pada koneksi front-end. Pipelined HTTP pada koneksi backend tidak terdukung.
Application Load Balancers mendukung metode permintaan HTTP berikut: GET, HEAD, POST, PUT, DELETE, OPTIONS, dan PATCH.
Application Load Balancers mendukung protokol berikut pada koneksi front-end:,,, dan. HTTP/0.9 HTTP/1.0 HTTP/1.1 HTTP/2 Anda HTTP/2 hanya dapat menggunakan dengan pendengar HTTPS, dan dapat mengirim hingga 128 permintaan secara paralel menggunakan satu HTTP/2 koneksi. Application Load Balancers juga mendukung peningkatan koneksi dari HTTP ke. WebSockets Namun, jika ada peningkatan koneksi, aturan dan AWS WAF integrasi perutean pendengar Application Load Balancer tidak lagi berlaku.
Aplikasi Load Balancer digunakan 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 HTTP/1.0 permintaan dari klien yang tidak memiliki header host, penyeimbang beban menghasilkan header host untuk HTTP/1.1 permintaan yang dikirim pada koneksi backend. Header host berisi nama DNS dari Load Balancer.
Classic Load Balancers mendukung protokol berikut pada koneksi front-end (client to load balancer):,, dan. HTTP/0.9 HTTP/1.0 HTTP/1.1 Mereka menggunakan HTTP/1.1 pada koneksi backend (penyeimbang beban ke target terdaftar). keep-aliveHeader didukung pada koneksi backend secara default. Untuk HTTP/1.0 permintaan dari klien yang tidak memiliki header host, penyeimbang beban menghasilkan header host untuk HTTP/1.1 permintaan yang dikirim pada koneksi backend. Header host berisi alamat IP dari node Load Balancer.
Header HTTP
Application Load Balancers dan Classic Load Balancers secara otomatis menambahkan X-Forwarded-For, X-Forwarded-Proto, dan X-Forwarded-Portheader ke permintaan.
Application Load Balancer mengkonversi nama host di header host HTTP menjadi huruf kecil sebelum mengirim mereka 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,,, Host X-Forwarded-Proto, X-Forwarded-Port, Upgrade X-Amzn-Trace-Id, 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.
Saat Application Load Balancers dan Classic Load Balancer menggunakan header HTTP/1.1 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.
Batas header HTTP 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. Nama DNS dari Load Balancer yang menghadap internet dapat dipecahkan secara publik ke alamat IP publik simpul tersebut. Oleh karena itu, Load Balancer yang menghadap internet dapat merutekan permintaan dari klien melalui internet.
Simpul penyeimbang beban internal hanya memiliki alamat IP privat. Nama DNS Load Balancer internal dapat dibuka secara publik ke alamat IP pribadi dari simpul. Oleh karena itu, Load Balancer internal hanya dapat merutekan permintaan dari klien dengan akses ke VPC untuk Load Balancer.
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.
Hanya IPv4 — Klien berkomunikasi menggunakan alamat IPv4 publik dan pribadi. Subnet yang Anda pilih untuk penyeimbang beban Anda harus memiliki rentang alamat IPv4.
Dualstack — Klien berkomunikasi menggunakan alamat IPv4 dan IPv6 publik dan pribadi. Subnet yang Anda pilih untuk penyeimbang beban Anda harus memiliki rentang alamat IPv4 dan IPv6.
Dualstack tanpa IPv4 publik — Klien berkomunikasi menggunakan alamat IPv6 publik dan pribadi dan alamat IPv4 pribadi. Subnet yang Anda pilih untuk penyeimbang beban Anda harus memiliki rentang alamat IPv4 dan IPv6. Opsi ini tidak didukung dengan skema penyeimbang
internalbeban.
Tabel berikut menjelaskan jenis alamat IP yang didukung untuk setiap jenis penyeimbang beban.
| Jenis penyeimbang beban | Hanya IPv4 | Tumpukan ganda | Dualstack tanpa IPv4 publik |
|---|---|---|---|
| Penyeimbang Beban Aplikasi | |||
| Penyeimbang Beban Jaringan | |||
| Penyeimbang Beban Gateway | |||
| Classic Load Balancer |
Jenis alamat IP yang Anda tentukan untuk grup target menentukan bagaimana penyeimbang beban dapat berkomunikasi dengan target.
Hanya IPv4 - Penyeimbang beban berkomunikasi menggunakan alamat IPv4 pribadi. Anda harus mendaftarkan target dengan alamat IPv4 dengan grup target IPv4.
Hanya IPv6 - Penyeimbang beban berkomunikasi menggunakan alamat IPv6. Anda harus mendaftarkan target dengan alamat IPv6 dengan grup target IPv6. Kelompok target harus digunakan dengan penyeimbang beban dualstack.
Tabel berikut menjelaskan jenis alamat IP yang didukung untuk setiap protokol grup target.
| Protokol grup target | Hanya IPv4 | Hanya IPv6 |
|---|---|---|
| HTTP dan HTTPS | ||
| TCP | ||
| TLS | ||
| UDP dan TCP_UDP | ||
| JENIUS | - | - |
MTU Jaringan untuk Load Balancer Anda
Unit transmisi maksimum (MTU) menentukan ukuran, dalam byte, untuk paket terbesar yang dapat dikirim melalui jaringan. Semakin besar MTU suatu koneksi, semakin banyak data yang dapat dilewatkan dalam satu paket tunggal. Paket Ethernet terdiri dari frame, atau data aktual yang Anda kirim, dan informasi overhead jaringan di sekitarnya. 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.
Ukuran MTU pada node penyeimbang beban tidak dapat dikonfigurasi. Jumbo frame (9001 MTU) adalah standar di seluruh node penyeimbang beban untuk Application Load Balancers, Network Load Balancers, dan Classic Load Balancer. Gateway Load Balancers mendukung 8500 MTU. Untuk informasi selengkapnya, lihat Unit transmisi maksimum (MTU) di Panduan Pengguna untuk Penyeimbang Beban Gateway.
MTU jalur adalah ukuran paket maksimum yang didukung oleh jalur antara host asal dan host penerima. Penemuan MTU Jalur (PMTUD) digunakan untuk menentukan jalur MTU antara dua perangkat. Penemuan MTU Jalur sangat penting jika klien atau target tidak mendukung frame jumbo.
Jika suatu host mengirimkan paket yang lebih besar daripada MTU host penerima atau yang lebih besar daripada MTU perangkat di sepanjang jalur, host atau perangkat penerima akan mengembalikan pesan ICMP berikut: 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 ukuran MTU klien atau target antarmuka terus diturunkan, ada kemungkinan Penemuan Jalur MTU (PMTUD) tidak akan berfungsi. Untuk menghindari hal ini, pastikan Penemuan MTU Jalur berfungsi dari ujung ke ujung, dan bahwa Anda telah mengaktifkan frame jumbo pada klien dan target Anda. Untuk informasi lebih lanjut tentang Penemuan MTU Jalur dan mengaktifkan frame jumbo, lihatPath MTU DiscoverydiPanduan Pengguna Amazon EC2.
