Gunakan kasing atau yang tidak dimiliki penyeimbang muatan

Beberapa tahun yang lalu, saya menyelesaikan proyek migrasi di jaringan salah satu klien kami, tugasnya adalah mengubah platform, yang mendistribusikan beban antar server. Skema penyediaan layanan klien ini telah berkembang selama hampir 10 tahun, bersama dengan perkembangan baru dalam industri pusat data, sehingga "pilih-pilih", dalam arti yang baik, klien mengharapkan solusi yang akan memuaskan tidak hanya persyaratan toleransi kesalahan peralatan jaringan, penyeimbang beban dan server , tetapi juga akan memiliki sifat-sifat seperti skalabilitas, fleksibilitas, mobilitas dan kesederhanaan. Pada artikel ini saya akan mencoba secara konsisten, dari yang sederhana hingga yang rumit, menguraikan contoh-contoh utama penggunaan penyeimbang beban tanpa merujuk pada pabrikan, fitur-fiturnya dan metode pemasangan dengan jaringan pengiriman data.

Load balancers sekarang semakin disebut sebagai Application Delivery Controllers (ADCs). Tetapi jika aplikasi sedang berjalan di server, mengapa harus dikirim ke suatu tempat? Untuk alasan toleransi kesalahan atau penskalaan, aplikasi dapat dijalankan di lebih dari satu server, dalam hal ini Anda memerlukan jenis server proxy terbalik yang menyembunyikan kompleksitas internal dari konsumen, memilih server yang diinginkan, mengirimkan permintaan ke sana dan memastikan bahwa server mengembalikan yang benar , dari sudut pandang protokol, hasilnya, jika tidak, ia akan memilih server lain dan mengirim permintaan di sana. Untuk mengimplementasikan fungsi-fungsi ini, ADC harus memahami semantik protokol lapisan aplikasi yang digunakannya, ini memungkinkan Anda untuk mengkonfigurasi aturan khusus aplikasi untuk pengiriman lalu lintas, analisis hasil, dan memeriksa status server. Misalnya, pemahaman tentang semantik HTTP memungkinkan konfigurasi ketika permintaan HTTP

GET /docs/index.html HTTP/1.1 Host: www.company.com Accept-Language: en-us Accept-Encoding: gzip, deflate 

dikirim ke satu grup server dengan kompresi hasil dan caching, serta permintaan berikutnya

 POST /api/object-put HTTP/1.1 HOST: b2b.company.com X-Auth: 76GDjgtgdfsugs893Hhdjfpsj Content-Type: application/json 

diproses sesuai dengan aturan yang sama sekali berbeda.

Memahami semantik protokol memungkinkan Anda untuk mengatur sesi di tingkat objek protokol aplikasi, misalnya, menggunakan HTTP Header, RDP Cookie, atau permintaan multipleks untuk mengisi satu sesi transportasi dengan banyak permintaan pengguna jika tingkat aplikasi protokol memungkinkan ini.
Ruang lingkup aplikasi ADC kadang-kadang dibayangkan tanpa alasan hanya dengan melayani lalu lintas HTTP, pada kenyataannya, daftar protokol yang didukung untuk sebagian besar produsen jauh lebih luas. Bahkan bekerja tanpa memahami semantik protokol lapisan aplikasi, ADC dapat berguna untuk menyelesaikan berbagai tugas, misalnya, saya mengambil bagian dalam membangun kebun virtual mandiri server SMTP, selama serangan spam, jumlah instance meningkat menggunakan kontrol umpan balik di sepanjang antrian pesan untuk memberikan waktu yang memuaskan untuk memeriksa pesan dengan algoritma sumber daya intensif. Selama aktivasi, server terdaftar dengan ADC dan menerima bagiannya dari sesi TCP baru. Dalam kasus SMTP, skema operasi seperti itu dibenarkan karena tingginya entropi koneksi di tingkat jaringan dan transportasi, untuk distribusi beban yang seragam selama serangan spam ADC, hanya dukungan TCP yang diperlukan. Skema yang sama dapat digunakan untuk membangun tambak dari server database, DNS, DHCP, AAA, atau cluster server akses jarak jauh yang banyak ketika server dapat dianggap setara dalam domain dan ketika karakteristik kinerjanya tidak terlalu berbeda satu sama lain. Saya tidak akan masuk lebih jauh ke topik fitur protokol, aspek ini terlalu luas untuk dinyatakan dalam pendahuluan, jika sesuatu tampak menarik - tulis, mungkin ini adalah kesempatan untuk artikel dengan presentasi yang lebih dalam dari beberapa aplikasi, dan sekarang mari kita langsung ke intinya.

Paling sering, ADC menutup lapisan transport, sehingga sesi TCP end-to-end antara konsumen dan server menjadi komposit, konsumen membuat sesi dengan ADC, dan ADC dengan salah satu server.


Fig. 1

Konfigurasi jaringan dan pengaturan pengalamatan harus menyediakan peningkatan lalu lintas sehingga dua bagian sesi TCP melewati ADC. Opsi termudah untuk membuat lalu lintas bagian pertama yang datang ke ADC adalah dengan menetapkan alamat layanan ke salah satu alamat antarmuka ADC, dengan bagian kedua opsi berikut dimungkinkan:

1. ADC sebagai gateway default untuk jaringan server;
2. Siaran ke alamat konsumen ADC di salah satu alamat antarmuka.

Bahkan, tampilan yang sedikit lebih realistis dari skema aplikasi pertama terlihat seperti ini, ini adalah dasar dari mana kita akan mulai:


Gbr.2

Kelompok server kedua dapat berupa basis data, aplikasi back-end, penyimpanan jaringan atau front-end untuk set layanan lain dalam hal penguraian aplikasi klasik menjadi layanan mikro. Kelompok server ini dapat berupa domain perutean yang terpisah, dengan kebijakannya sendiri, yang terletak di pusat data lain atau sepenuhnya diisolasi untuk alasan keamanan. Server jarang terletak di satu segmen, lebih sering mereka ditempatkan di segmen untuk tujuan yang dimaksudkan dengan kebijakan akses yang diatur dengan jelas, angka menunjukkan ini sebagai firewall.

Studi menunjukkan bahwa aplikasi multi-tier modern menghasilkan lebih banyak lalu lintas Barat-Timur, dan Anda tidak mungkin ingin semua lalu lintas intra-kode / antar-segmen melewati ADC. Switch pada Gambar 2 belum tentu fisik - domain routing dapat diimplementasikan menggunakan entitas virtual, yang disebut virtual-router, vrf, vr, vpn-instance atau tabel routing virtual untuk produsen yang berbeda.

Omong-omong, ada varian pairing dengan jaringan, tanpa memerlukan simetri arus lalu lintas dari konsumen ke ADC dan dari ADC ke server, permintaan dalam kasus sesi berumur panjang, di mana sejumlah besar lalu lintas ditransmisikan dalam satu arah, misalnya streaming atau menyiarkan konten video. Dalam hal ini, ADC hanya melihat aliran dari klien ke server, aliran ini dikirim ke alamat antarmuka ADC dan setelah pemrosesan sederhana, yang terdiri dari penggantian alamat MAC dengan antarmuka MAC dari salah satu server, permintaan dikirim ke server di mana alamat layanan ditugaskan ke salah satu antarmuka logis. Lalu lintas terbalik dari server ke konsumen melewati ADC sesuai dengan tabel routing server. Mendukung satu domain siaran untuk semua front-end bisa sangat sulit, apalagi, kemampuan ADC untuk menganalisis tanggapan dan dukungan sesi dalam hal ini sangat terbatas, pada kenyataannya itu hanya sebuah saklar, sehingga opsi ini tidak dipertimbangkan lebih lanjut, meskipun beberapa sempit tugas dapat digunakan.


Gbr.3

Jadi, kita memiliki satu basis-data center, ditunjukkan pada Gambar 2, mari kita pikirkan masalah apa yang dapat mendorong basis-data center ke evolusi, saya melihat dua topik untuk analisis:

1. Misalkan subsistem switching sepenuhnya dicadangkan, jangan berpikir tentang bagaimana atau mengapa, topiknya terlalu luas. Aplikasi berjalan di beberapa server dan didukung menggunakan ADC, tetapi bagaimana cara memesan ADC itu sendiri?
2. Jika analisis menunjukkan bahwa beban puncak musiman berikutnya dapat melebihi kemampuan ADC, Anda tentu saja memikirkan skalabilitas.

Tugas-tugas ini serupa dalam hal itu, dalam proses penyelesaiannya, jumlah instance ADC pasti akan meningkat. Pada saat yang sama, toleransi kesalahan dapat diatur sesuai dengan skema Active / Backup dan Active / Active, dan penskalaan hanya dapat dilakukan sesuai dengan skema Active / Active. Mari kita coba selesaikan secara individual dan lihat properti apa yang dimiliki berbagai solusi.

Banyak ADC produsen dapat dianggap sebagai elemen infrastruktur jaringan, RIP, OSPF, BGP - semua ini ada di sana, yang berarti Anda dapat membangun skema cadangan Active / Backup yang sepele. ADC aktif meneruskan awalan layanan ke router hulu, dan menerima rute default untuk mengisi tabelnya dan untuk mentransfer ke pusat data ke tabel routing virtual yang sesuai. ADC cadangan melakukan hal yang sama, tetapi, dengan menggunakan semantik dari protokol routing yang dipilih, menghasilkan pengumuman yang kurang menarik. Dengan pendekatan ini, server dapat melihat alamat IP nyata dari konsumen, karena tidak ada alasan untuk menggunakan terjemahan alamat. Skema ini juga berfungsi dengan baik jika ada lebih dari satu router hulu, tetapi untuk menghindari situasi ketika ADC aktif kehilangan default dan konektivitas dengan router, sementara masih menerima default dari ADC cadangan dan terus mengumumkannya ke pusat data, cobalah untuk menghindari kedekatan antara ADC dan penggunaan rute statis.


Fig. 4

Jika server tidak harus beroperasi dengan alamat IP konsumen nyata, atau protokol lapisan aplikasi memungkinkan Anda untuk menanamkannya dalam header, seperti HTTP, skema berubah menjadi Aktif / Aktif dengan ketergantungan kinerja yang hampir linier pada jumlah ADC. Dalam hal lebih dari satu router hulu, harus diperhatikan untuk memastikan bahwa lalu lintas masuk tiba dalam porsi yang kurang lebih seragam. Tugas ini dapat dengan mudah diselesaikan jika dalam domain routing ECMP transfer mulai ke router ini, jika sulit atau jika domain routing tidak dilayani oleh Anda - Anda dapat menggunakan koneksi full-mesh antara ADX dan router sehingga transfer ECMP mulai langsung ke mereka.


Gbr.5

Pada awal bagian ini, saya menulis bahwa toleransi kesalahan dan penskalaan adalah dua perbedaan besar. Solusi untuk masalah ini memiliki tingkat pemanfaatan sumber daya yang berbeda, jika Anda merancang skema Aktif / Siaga, Anda perlu menerima kenyataan bahwa setengah dari sumber daya akan menganggur. Dan jika itu terjadi sehingga Anda perlu mengambil langkah kuantitatif berikutnya, bersiaplah untuk melipatgandakan sumber daya yang diperlukan dengan dua lagi di masa depan.

Manfaat Aktif / Aktif mulai muncul ketika Anda beroperasi dengan lebih dari dua perangkat. Misalkan Anda perlu memastikan kinerja 8 unit sewenang-wenang (8 ribu koneksi per detik, atau 8 juta sesi simultan) dan menyediakan skenario kegagalan perangkat tunggal, dalam versi Aktif / Aktif, Anda hanya perlu tiga instance ADC dengan kapasitas 4, dalam kasus Aktif / Siaga - dua oleh 8. Jika Anda menerjemahkan angka-angka ini ke sumber daya yang tidak digunakan, Anda mendapatkan sepertiga hingga setengah. Prinsip perhitungan yang sama dapat digunakan untuk memperkirakan proporsi koneksi terputus selama periode kegagalan parsial. Dengan peningkatan jumlah instance Aktif / Aktif, matematika menjadi lebih menyenangkan, dan sistem mendapat kesempatan untuk secara bertahap meningkatkan produktivitas alih-alih bertahap Aktif / Siaga.

Akan benar untuk menyebutkan cara lain dari skema kerja Aktif / Aktif atau Aktif / Siaga - pengelompokan. Tetapi tidak akan terlalu tepat untuk mencurahkan banyak waktu untuk ini, karena saya mencoba untuk menulis tentang pendekatan, dan bukan tentang fitur produsen. Saat memilih solusi ini, Anda perlu memahami hal-hal berikut:

1. Arsitektur cluster kadang-kadang memaksakan pembatasan pada fungsi ini atau itu, dalam beberapa proyek ini adalah fundamental, dalam beberapa hal itu mungkin menjadi penting di masa depan, semua yang ada di sini sangat tergantung pada pabrikan dan setiap solusi perlu dikerjakan secara individual;
2. Cluster sering satu domain kesalahan, akan ada kesalahan dalam perangkat lunak.
3. Cluster mudah dirakit, tetapi sangat sulit dibongkar. Teknologi memiliki mobilitas yang lebih rendah - Anda tidak dapat mengontrol bagian sistem.
4. Anda jatuh ke dalam pelukan kuat produsen Anda.

Meskipun demikian, ada hal-hal positif:

1. Cluster ini mudah dipasang dan mudah dioperasikan.
2. Terkadang Anda dapat mengharapkan pemanfaatan sumber daya yang hampir optimal.

Jadi, pusat data kami dari Gambar 5 terus bertambah, tugas yang mungkin harus Anda selesaikan adalah menambah jumlah server. Tidak selalu mungkin untuk melakukan ini di pusat data yang ada, jadi anggaplah bahwa lokasi baru yang luas dengan server tambahan telah muncul.


Gbr.6

Situs baru mungkin tidak terlalu jauh, maka Anda akan berhasil menyelesaikan masalah dengan memperbarui domain perutean. Kasus yang lebih umum, yang tidak mengecualikan penampilan situs di kota lain atau di negara lain, akan menimbulkan tantangan baru untuk pusat data:

1. Pemanfaatan saluran antar situs;
2. Perbedaan waktu pemrosesan untuk permintaan yang dikirim ADC untuk diproses ke server terdekat dan jauh.

Mempertahankan saluran yang luas antar situs dapat menjadi pekerjaan yang sangat mahal, dan memilih lokasi tidak akan lagi menjadi tugas sepele - situs yang kelebihan beban dengan waktu respons yang singkat atau gratis dengan yang besar. Memikirkan hal ini akan mendorong Anda untuk membangun konfigurasi pusat data yang terdistribusi secara geografis. Konfigurasi ini, di satu sisi, ramah bagi konsumen, karena memungkinkan Anda untuk menerima layanan pada titik yang dekat dengan Anda, di sisi lain, ini dapat secara signifikan mengurangi persyaratan untuk band saluran antara situs.

Untuk kasus ketika alamat IP asli tidak harus dapat diakses ke server, atau ketika protokol lapisan aplikasi memungkinkan mereka untuk ditransmisikan dalam header, perangkat pusat data yang didistribusikan secara geografis tidak jauh berbeda dari apa yang saya sebut sebagai pusat data dasar. ADC di situs mana pun dapat mengirim permintaan pemrosesan ke server lokal atau mengirimnya untuk diproses ke yang tetangga, menyiarkan alamat konsumen memungkinkan hal ini. Beberapa perhatian harus diberikan untuk memantau volume lalu lintas yang masuk untuk mempertahankan jumlah ADC di dalam situs yang memadai dengan proporsi lalu lintas yang diterima situs. Terjemahan alamat konsumen memungkinkan Anda untuk menambah / mengurangi jumlah ADC atau bahkan memindahkan instance antar situs sesuai dengan perubahan dalam matriks lalu lintas yang masuk, atau selama migrasi / peluncuran. Terlepas dari kesederhanaannya, skema ini cukup fleksibel, memiliki karakteristik pengoperasian yang menyenangkan dan mudah direplikasi untuk lebih dari dua lokasi.


Gbr. 7

Jika Anda bekerja dengan protokol yang memungkinkan penerusan permintaan, seperti dalam kasus HTTP Redirect, fitur ini dapat digunakan sebagai tuas tambahan untuk mengontrol beban saluran antar situs, sebagai mekanisme untuk melakukan pemeliharaan rutin pada server atau sebagai metode membangun tambak server Active / Backup di berbagai situs. Pada titik waktu yang ditentukan, secara otomatis atau setelah beberapa peristiwa pemicu, ADC dapat menghapus lalu lintas dari server lokal dan memindahkan konsumen ke situs tetangga. Penting untuk memperhatikan pengembangan algoritma ini sehingga pekerjaan terkoordinasi ADC mengecualikan kemungkinan permintaan atau resonansi timbal balik.

Yang menarik adalah kasus ketika server membutuhkan alamat IP nyata dari konsumen, dan protokol lapisan aplikasi tidak memiliki kemampuan untuk mengirimkan header tambahan, atau ketika ADC bekerja tanpa memahami semantik protokol lapisan aplikasi. Dalam hal ini, tidak mungkin untuk menyediakan koneksi yang konsisten antara segmen sesi TCP dengan hanya menyatakan rute dalam ADC default. Jika Anda melakukan ini, server situs pertama akan mulai menggunakan ADC lokal sebagai gateway default untuk sesi yang berasal dari situs kedua, sesi TCP tidak akan dibuat dalam kasus ini karena ADC situs pertama akan melihat hanya satu bahu sesi.


Gbr. 8

Ada trik kecil yang masih memungkinkan Anda untuk menjalankan ADC Aktif / Aktif dikombinasikan dengan Farm server Aktif / Aktif di situs yang berbeda (Saya tidak mempertimbangkan kasus Aktif / Cadangan di dua situs, pembacaan yang cermat di atas akan memungkinkan Anda untuk menyelesaikan masalah ini tanpa diskusi lebih lanjut). Caranya adalah dengan menggunakan ADC situs kedua bukan alamat antarmuka server, tetapi alamat ADC logis, yang sesuai dengan server pertanian di situs pertama. Pada saat yang sama, server menerima lalu lintas seolah-olah berasal dari ADC lokal dan menggunakan gateway default lokal. Untuk mempertahankan mode operasi ini pada ADC, Anda harus mengaktifkan fungsi memori antarmuka dari mana paket pertama untuk mengatur sesi TCP datang. Pabrikan yang berbeda menyebut fungsi ini secara berbeda, tetapi intinya sama - ingat antarmuka dalam tabel status sesi dan gunakan untuk lalu lintas respons tanpa memperhatikan tabel perutean. Skema ini berfungsi penuh dan memungkinkan Anda untuk mendistribusikan beban secara fleksibel di semua server yang tersedia di mana pun mereka berada. Dalam kasus dua atau lebih situs, kegagalan satu ADC tidak mempengaruhi ketersediaan layanan secara keseluruhan, tetapi sepenuhnya mengecualikan kemungkinan memproses lalu lintas di server situs dengan ADC yang gagal, ini harus diingat ketika memprediksi perilaku dan memuat selama kegagalan parsial.


Gambar 9

Layanan klien kami berfungsi kira-kira dengan cara yang sama ketika saya mulai mengerjakan proyek migrasi ke platform ADC baru. Tidak sulit untuk hanya menciptakan kembali perilaku perangkat dari platform lama pada yang baru dalam kerangka skema yang terbukti dan ramah pelanggan, ini adalah apa yang mereka harapkan dari kami.

Tetapi lihat kembali Gambar 9, apakah Anda melihat apa yang dapat dioptimalkan di sana?
Kerugian utama bekerja dengan rantai ADC adalah bahwa ia menghabiskan sumber daya dari dua ADC untuk memproses beberapa bagian dari sesi. Dalam kasus klien ini, pilihannya benar-benar sadar, itu karena spesifik aplikasi dan kebutuhan untuk dapat dengan sangat cepat (dari 20 hingga 50 detik) mendistribusikan kembali beban antara server dari situs yang berbeda. Pada periode waktu yang berbeda, pemrosesan ganda mengambil rata-rata 15 hingga 30 persen sumber daya ADC, yang cukup untuk memikirkan optimasi. Setelah membahas hal ini dengan para insinyur klien, kami mengusulkan untuk mengganti dukungan untuk tabel sesi ADC dengan pengikatan antarmuka dengan perutean sumber pada server menggunakan PBR pada tumpukan IP Linux. Sebagai kunci, kami mempertimbangkan opsi seperti:

1. alamat IP tambahan pada server pada antarmuka umum untuk setiap ADC;
2. antarmuka alamat IP pada server pada 802.1q terpisah untuk setiap ADC;
3. Pisahkan jaringan terowongan overlay pada server untuk setiap ADC.

Opsi pertama dan kedua akan memengaruhi jaringan secara keseluruhan. Di antara efek samping opsi satu, tampaknya tidak dapat diterima bagi kami bahwa peningkatan yang merupakan kelipatan dari jumlah ADC, tabel ARP pada sakelar, dan opsi kedua akan membutuhkan peningkatan jumlah domain siaran end-to-end antara situs atau contoh individual tabel routing virtual. Sifat lokal dari opsi ketiga tampak sangat menarik bagi kami, dan kami mulai bekerja, yang menghasilkan pengontrol sederhana yang mengotomatiskan konfigurasi terowongan pada server dan ADC, serta konfigurasi PBR pada tumpukan IP server Linux.


Gbr. 10

Ketika saya menulis, migrasi selesai, klien mendapatkan apa yang diinginkannya - platform baru, kesederhanaan, fleksibilitas, skalabilitas, dan, sebagai akibat beralih ke overlay, menyederhanakan konfigurasi peralatan jaringan sebagai bagian dari servis layanan ini - alih-alih beberapa salinan tabel virtual dan domain siaran besar, ternyata - IP .

, ADC, . , , . -, ADC , , « ».

Selain itu, beberapa pelanggan mungkin merasa nyaman untuk beralih dari model interaksi PULL dengan server ke model PUSH. Kemampuan aplikasi pada server sangat luas, sehingga kadang-kadang lebih mudah untuk mengatur verifikasi aplikasi spesifik yang serius dari layanan pada agen itu sendiri. Jika cek memberikan hasil positif, agen mentransmisikan informasi, misalnya, dalam bentuk yang mirip dengan Komunitas Biaya BGP, untuk digunakan dalam algoritma perhitungan tertimbang.
Seringkali, berbagai departemen organisasi melakukan pemeliharaan server dan ADC, beralih ke model interaksi PUSH mungkin menarik karena model ini menghilangkan kebutuhan untuk koordinasi antar departemen pada antarmuka manusia-ke-manusia. Layanan di mana server berpartisipasi dapat ditransfer langsung dari agen ke ADC dalam bentuk yang mirip dengan BGP Flow-Spec canggih.

. … , , . - , , , . . , , , SDN . , , .