Halo, aku Sergey Elantsev, aku berkembang ing Yandex.Cloud. Sadurunge, aku mimpin pangembangan penyeimbang L7 kanggo portal Yandex - kanca-kanca guyon manawa ora ketompo apa sing ditindakake, ternyata dadi penyeimbang. Aku bakal ngandhani para pamaca Habr babagan cara ngatur beban ing platform maya, apa sing kita deleng minangka alat sing cocog kanggo nggayuh tujuan iki, lan kepiye carane nggawe alat iki.
Pisanan, ayo ngenalake sawetara istilah:
- VIP (Virtual IP) - alamat IP balancer
- Server, backend, contone - mesin virtual sing mbukak aplikasi
- RIP (Real IP) - alamat IP server
- Healthcheck - mriksa kesiapan server
- Availability Zone, AZ - infrastruktur terisolasi ing pusat data
- Wilayah - gabungan saka macem-macem AZ
Load balancers ngrampungake telung tugas utama: nindakake imbangan dhewe, nambah toleransi kesalahan layanan, lan nyederhanakake skala. Toleransi kesalahan dijamin liwat manajemen lalu lintas otomatis: balancer ngawasi kahanan aplikasi lan ora kalebu conto saka imbangan sing ora ngliwati cek liveness. Scaling wis mesthekake dening roto-roto nyebarke mbukak antarane kedadean, uga nganyari dhaptar kedadean ing fly. Yen imbangan ora cukup seragam, sawetara kasus bakal nampa beban sing ngluwihi watesan kapasitas, lan layanan bakal dadi kurang dipercaya.
A load balancer asring diklasifikasikake dening lapisan protokol saka model OSI sing digunakake. Cloud Balancer beroperasi ing tingkat TCP, sing cocog karo lapisan kaping papat, L4.
Ayo pindhah menyang ringkesan arsitektur Cloud balancer. Kita bakal nambah tingkat rinci kanthi bertahap. Kita dibagi komponen balancer dadi telung kelas. Kelas pesawat config tanggung jawab kanggo interaksi pangguna lan nyimpen negara target sistem. Pesawat kontrol nyimpen kahanan sistem saiki lan ngatur sistem saka kelas pesawat data, sing tanggung jawab langsung kanggo ngirim lalu lintas saka klien menyang instans sampeyan.
Pesawat data
Lalu lintas rampung ing piranti larang sing diarani router tapel wates. Kanggo nambah toleransi fault, sawetara piranti kuwi operate bebarengan ing siji pusat data. Sabanjure, lalu lintas menyang balancers, sing ngumumake alamat IP anycast menyang kabeh AZ liwat BGP kanggo klien.
Lalu lintas ditularake liwat ECMP - iki minangka strategi rute sing bisa uga ana sawetara rute sing padha apik menyang target (ing kasus kita, target bakal dadi alamat IP tujuan) lan paket bisa dikirim bebarengan karo salah sawijining. Kita uga ndhukung karya ing sawetara zona kasedhiyan miturut skema ing ngisor iki: kita ngiklanake alamat ing saben zona, lalu lintas menyang sing paling cedhak lan ora ngluwihi watesan. Mengko ing kirim kita bakal katon ing liyane rinci ing apa mengkono kanggo lalu lintas.
pesawat konfigurasi
Komponen utama pesawat konfigurasi yaiku API, ing ngendi operasi dhasar karo penyeimbang ditindakake: nggawe, mbusak, ngganti komposisi instan, entuk asil pemeriksaan kesehatan, lsp. Ing tangan siji, iki minangka REST API, lan ing liyane, kita ing Cloud kerep banget nggunakake framework gRPC, supaya kita "nerjemahake" REST menyang gRPC banjur mung nggunakake gRPC. Sembarang panjalukan ndadékaké kanggo nggawe seri tugas idempoten bedo sing dileksanakake ing blumbang umum saka Yandex.Cloud buruh. Tugas ditulis kanthi cara sing bisa ditundha kapan wae banjur diwiwiti maneh. Iki njamin skalabilitas, pengulangan lan logging operasi.
Akibaté, tugas saka API bakal nggawe panjalukan menyang pengontrol layanan balancer, sing ditulis ing Go. Bisa nambah lan mbusak balancers, ngganti komposisi backends lan setelan.
Layanan nyimpen negara ing Yandex Database, basis data sing dikelola sing disebarake sing bakal sampeyan gunakake. Ing Yandex.Cloud, kita wis , konsep panganan asu ditrapake: yen kita dhewe nggunakake layanan kita, banjur klien kita uga bakal seneng nggunakake. Yandex Database minangka conto implementasi konsep kasebut. Kita nyimpen kabeh data ing YDB, lan kita ora kudu mikir babagan njaga lan skala database: masalah iki ditanggulangi kanggo kita, kita nggunakake database minangka layanan.
Ayo bali menyang controller balancer. Tugase kanggo nyimpen informasi babagan balancer lan ngirim tugas kanggo mriksa kesiapan mesin virtual menyang pengontrol healthcheck.
Kontrol kesehatan
Nampa panjalukan kanggo ngganti aturan mriksa, nyimpen ing YDB, distributes tugas antarane simpul healtcheck lan aggregates asil, kang banjur disimpen ing database lan dikirim menyang loadbalancer controller. Iku, ing siji, ngirim panjalukan kanggo ngganti komposisi saka kluster ing bidang data kanggo loadbalancer-simpul, kang bakal ngrembug ing ngisor iki.
Ayo ngobrol luwih akeh babagan pemeriksaan kesehatan. Padha bisa dipérang dadi sawetara kelas. Audit duwe kritéria sukses sing beda. Priksa TCP kudu sukses nggawe sambungan ing wektu sing tetep. Priksa HTTP mbutuhake sambungan sing sukses lan respon kanthi kode status 200.
Uga, mriksa beda-beda ing kelas tumindak - padha aktif lan pasif. Pemeriksa pasif mung ngawasi apa sing kedadeyan karo lalu lintas tanpa njupuk tindakan khusus. Iki ora bisa digunakake kanthi apik ing L4 amarga gumantung marang logika protokol tingkat sing luwih dhuwur: ing L4 ora ana informasi babagan suwene operasi kasebut utawa apa sambungan rampung apik utawa ala. Pemeriksaa aktif mbutuhake balancer ngirim panjalukan menyang saben conto server.
Umume penyeimbang beban nindakake mriksa liveness dhewe. Ing Cloud, kita mutusake kanggo misahake bagean sistem kasebut kanggo nambah skalabilitas. Pendekatan iki bakal ngidini kita nambah jumlah penyeimbang nalika njaga jumlah panjalukan pemeriksaan kesehatan menyang layanan kasebut. Pemeriksaa ditindakake kanthi simpul pemeriksa kesehatan sing kapisah, ing endi target pamriksa dipecah lan ditiru. Sampeyan ora bisa nindakake mriksa saka siji host, amarga bisa uga gagal. Banjur kita ora bakal entuk status kedadeyan sing dicenthang. Kita nindakake mriksa ing salah siji saka kedadean saka paling telung simpul healthcheck. We shard tujuan mriksa antarane kelenjar nggunakake algoritma hashing konsisten.
Pamisahan keseimbangan lan pemeriksaan kesehatan bisa nyebabake masalah. Yen simpul healthcheck nggawe panjalukan kanggo conto kasebut, ngliwati balancer (sing saiki ora ngladeni lalu lintas), banjur ana kahanan aneh: sumber kasebut katon urip, nanging lalu lintas ora bakal tekan. Kita ngrampungake masalah iki kanthi cara iki: kita dijamin miwiti lalu lintas pemeriksaan kesehatan liwat penyeimbang. Ing tembung liya, skema kanggo mindhah paket kanthi lalu lintas saka klien lan saka pemeriksaan kesehatan beda-beda minimal: ing kasus kasebut, paket kasebut bakal tekan penyeimbang, sing bakal dikirim menyang sumber daya target.
Bentenipun punika klien nggawe panjalukan kanggo VIP, nalika healthchecks nggawe panjalukan kanggo saben RIP individu. Masalah menarik muncul ing kene: kita menehi pangguna kesempatan kanggo nggawe sumber daya ing jaringan IP abu-abu. Bayangake manawa ana rong pamilik maya sing ndhelikake layanan ing mburi keseimbangan. Saben wong duwe sumber daya ing subnet 10.0.0.1/24, kanthi alamat sing padha. Sampeyan kudu bisa mbedakake, lan ing kene sampeyan kudu nyilem menyang struktur jaringan virtual Yandex.Cloud. Iku luwih apik kanggo mangerteni rincian liyane ing , iku penting kanggo kita saiki sing jaringan multi-lapisan lan wis trowongan sing bisa dibedakake dening subnet id.
Healthcheck node ngubungi balancers nggunakake alamat quasi-IPv6 sing diarani. Alamat kuasi yaiku alamat IPv6 kanthi alamat IPv4 lan id subnet pangguna sing dipasang ing njero. Lalu lintas tekan balancer, sing ngekstrak alamat sumber daya IPv4, ngganti IPv6 karo IPv4 lan ngirim paket menyang jaringan pangguna.
Lalu lintas mbalikke mlaku kanthi cara sing padha: penyeimbang ndeleng manawa tujuan kasebut minangka jaringan abu-abu saka pemeriksa kesehatan, lan ngowahi IPv4 dadi IPv6.
VPP - jantung bidang data
Balancer dileksanakake nggunakake teknologi Vector Packet Processing (VPP), framework saka Cisco kanggo Processing kumpulan lalu lintas jaringan. Ing kasus kita, kerangka kerja ing ndhuwur perpustakaan manajemen piranti jaringan ruang pangguna - Data Plane Development Kit (DPDK). Iki njamin kinerja pangolahan paket sing dhuwur: interrupts luwih sithik ing kernel, lan ora ana switch konteks ing antarane ruang kernel lan ruang pangguna.
VPP dadi luwih lan squeezes kinerja malah luwih metu saka sistem dening nggabungke paket menyang kumpulan. Hasil kinerja teka saka nggunakake agresif cache ing prosesor modern. Loro-lorone cache data digunakake (paket diproses ing "vektor", data cedhak saben liyane) lan cache instruksi: ing VPP, pangolahan paket nderek grafik, simpul sing ngemot fungsi sing nindakake tugas sing padha.
Contone, pangolahan paket IP ing VPP dumadi ing urutan ing ngisor iki: pisanan, header paket diurai ing simpul parsing, banjur dikirim menyang simpul, sing nerusake paket kasebut miturut tabel rute.
A hardcore sethitik. Penulis VPP ora ngidinke kompromi ing panggunaan cache prosesor, supaya kode khas kanggo ngolah vektor paket ngemot vektorisasi manual: ana loop pangolahan ing ngendi kahanan kaya "kita duwe patang paket ing antrian" diproses, banjur padha kanggo loro, banjur - kanggo siji. Pandhuan prefetch asring digunakake kanggo mbukak data menyang cache kanggo nyepetake akses menyang data kasebut ing iterasi sabanjure.
n_left_from = frame->n_vectors;
while (n_left_from > 0)
{
vlib_get_next_frame (vm, node, next_index, to_next, n_left_to_next);
// ...
while (n_left_from >= 4 && n_left_to_next >= 2)
{
// processing multiple packets at once
u32 next0 = SAMPLE_NEXT_INTERFACE_OUTPUT;
u32 next1 = SAMPLE_NEXT_INTERFACE_OUTPUT;
// ...
/* Prefetch next iteration. */
{
vlib_buffer_t *p2, *p3;
p2 = vlib_get_buffer (vm, from[2]);
p3 = vlib_get_buffer (vm, from[3]);
vlib_prefetch_buffer_header (p2, LOAD);
vlib_prefetch_buffer_header (p3, LOAD);
CLIB_PREFETCH (p2->data, CLIB_CACHE_LINE_BYTES, STORE);
CLIB_PREFETCH (p3->data, CLIB_CACHE_LINE_BYTES, STORE);
}
// actually process data
/* verify speculative enqueues, maybe switch current next frame */
vlib_validate_buffer_enqueue_x2 (vm, node, next_index,
to_next, n_left_to_next,
bi0, bi1, next0, next1);
}
while (n_left_from > 0 && n_left_to_next > 0)
{
// processing packets by one
}
// processed batch
vlib_put_next_frame (vm, node, next_index, n_left_to_next);
}Dadi, Healthchecks ngomongake IPv6 menyang VPP, sing dadi IPv4. Iki ditindakake kanthi simpul ing grafik, sing diarani NAT algoritma. Kanggo lalu lintas mbalikke (lan konversi saka IPv6 menyang IPv4) ana simpul NAT algoritma sing padha.
Lalu lintas langsung saka klien balancer ngliwati simpul grafik, sing nindakake imbangan dhewe.
Simpul pisanan yaiku sesi lengket. Iku nyimpen hash saka kanggo sesi mapan. 5-tuple kalebu alamat lan port klien saka ngendi informasi ditularaké, alamat lan bandar sumber daya kasedhiya kanggo nampa lalu lintas, uga protokol jaringan.
Hash 5-tuple mbantu kita nindakake komputasi sing kurang ing simpul hashing sing terus-terusan, uga pangowahan dhaptar sumber daya sing luwih apik ing mburi keseimbangan. Nalika paket sing ora ana sesi teka ing balancer, dikirim menyang simpul hashing sing konsisten. Iki ngendi balancing dumadi nggunakake hashing konsisten: kita milih sumber daya saka dhaftar kasedhiya "urip" sumber daya. Sabanjure, paket dikirim menyang simpul NAT, sing bener-bener ngganti alamat tujuan lan ngitung maneh checksum. Nalika sampeyan bisa ndeleng, kita tindakake aturan saka VPP - kaya seneng, klompok petungan padha kanggo nambah efficiency saka caches prosesor.
Hashing sing konsisten
Napa kita milih lan apa iku malah? Pisanan, ayo nimbang tugas sadurunge - milih sumber daya saka dhaptar.
Kanthi hashing sing ora konsisten, hash saka paket sing mlebu diwilang, lan sumber daya dipilih saka dhaptar kanthi mbagi hash iki kanthi jumlah sumber daya. Anggere dhaftar tetep panggah, skema iki bisa uga: kita tansah ngirim paket karo 5-tuple padha kanggo Kayata padha. Yen, contone, sawetara sumber mandheg nanggapi pemeriksaan kesehatan, banjur kanggo bagean penting saka hash pilihan bakal diganti. Sambungan TCP klien bakal rusak: paket sing sadurunge tekan instance A bisa wiwit tekan instance B, sing ora ngerti sesi kanggo paket iki.
Hashing sing konsisten ngatasi masalah sing diterangake. Cara sing paling gampang kanggo nerangake konsep iki yaiku: mbayangno yen sampeyan duwe dering sing sampeyan nyebarake sumber daya kanthi hash (contone, IP: port). Milih sumber daya ngowahi setir dening amba, kang ditemtokake dening hash saka paket.
Iki nyilikake redistribusi lalu lintas nalika komposisi sumber diganti. Mbusak sumber daya mung bakal mengaruhi bagean ring hashing konsisten ing ngendi sumber kasebut dumunung. Nambahake sumber daya uga ngganti distribusi, nanging kita duwe simpul sesi lengket, sing ngidini kita ora ngalih sesi sing wis diadegake menyang sumber daya anyar.
Kita ndeleng apa sing kedadeyan kanggo ngarahake lalu lintas antarane penyeimbang lan sumber daya. Saiki ayo goleki lalu lintas bali. Pola kasebut padha karo lalu lintas mriksa - liwat NAT algoritma, yaiku, liwat NAT 44 kanggo lalu lintas klien lan liwat NAT 46 kanggo lalu lintas pemeriksaan kesehatan. Kita netepi skema dhewe: kita nyawiji lalu lintas pemeriksaan kesehatan lan lalu lintas pangguna nyata.
Loadbalancer-simpul lan nglumpuk komponen
Komposisi keseimbangan lan sumber daya ing VPP dilaporake dening layanan lokal - loadbalancer-node. Iku langganan stream acara saka loadbalancer-controller lan bisa kanggo plot prabédan antarane negara VPP saiki lan negara target ditampa saka controller. We njaluk sistem tertutup: acara saka API teka menyang controller balancer, kang menehi tugas kanggo kontrol healthcheck kanggo mriksa "liveness" sumber. Sing, ing siji, nemtokaken tugas kanggo healthcheck-simpul lan aggregates asil, sawise kang ngirim bali menyang controller balancer. Loadbalancer-simpul langganan acara saka controller lan ngganti negara VPP. Ing sistem kasebut, saben layanan mung ngerti apa sing dibutuhake babagan layanan tetanggan. Jumlah sambungan diwatesi lan kita duwe kemampuan kanggo operate lan skala segmen beda kanthi mandiri.
Masalah apa sing dihindari?
Kabeh layanan kita ing bidang kontrol ditulis ing Go lan nduweni skala lan ciri linuwih sing apik. Go nduweni akeh perpustakaan open source kanggo mbangun sistem sing disebarake. Kita aktif nggunakake GRPC, kabeh komponen ngemot implementasine open source saka panemuan layanan - layanan kita ngawasi kinerja saben liyane, bisa ngganti komposisi mbosenke, lan kita nggandhengake iki karo GRPC balancing. Kanggo metrik, kita uga nggunakake solusi open source. Ing bidang data, kita entuk kinerja sing apik lan cadangan sumber daya sing akeh: dadi angel banget kanggo ngumpulake stand sing bisa ngandelake kinerja VPP, tinimbang kertu jaringan wesi.
Masalah lan Solusi
Apa ora bisa dadi apik? Go nduweni manajemen memori otomatis, nanging bocor memori isih kedadeyan. Cara sing paling gampang kanggo ngatasi yaiku mbukak goroutine lan elinga kanggo mungkasi. Takeaway: Nonton konsumsi memori program Go. Asring indikator sing apik yaiku jumlah goroutine. Ana plus ing crita iki: ing Go iku gampang kanggo njaluk data runtime - konsumsi memori, jumlah goroutine mlaku, lan akeh paramèter liyane.
Uga, Go bisa uga ora dadi pilihan sing paling apik kanggo tes fungsional. Padha cukup verbose, lan pendekatan standar "mlaku kabeh ing CI ing kumpulan" ora cocok banget kanggo wong-wong mau. Kasunyatane yaiku tes fungsional luwih mbutuhake sumber daya lan nyebabake wektu entek nyata. Amarga iki, tes bisa gagal amarga CPU sibuk karo tes unit. Kesimpulan: Yen bisa, nindakake tes "abot" kanthi kapisah saka tes unit.
Arsitektur acara Microservice luwih rumit tinimbang monolit: ngumpulake log ing puluhan mesin sing beda-beda ora trep banget. Kesimpulan: yen sampeyan nggawe layanan mikro, langsung mikir babagan tracing.
rencana kita
Kita bakal ngluncurake imbangan internal, penyeimbang IPv6, nambah dhukungan kanggo skrip Kubernetes, terus ngrusak layanan kita (saiki mung healthcheck-node lan healthcheck-ctrl sing sharded), nambah pemeriksaan kesehatan anyar, lan uga ngleksanakake agregasi cek sing cerdas. We are considering kamungkinan kanggo nggawe layanan kita malah luwih independen - supaya padha komunikasi ora langsung karo saben liyane, nanging nggunakake antrian pesen. Layanan sing kompatibel karo SQS bubar muncul ing Cloud .
Bubar, rilis umum Yandex Load Balancer dumadi. Jelajahi menyang layanan, ngatur balancers ing cara trep kanggo sampeyan lan nambah toleransi fault proyek!
Source: www.habr.com