Halo, kuring Sergey Elantsev, kuring ngembangkeun dina Yandex.Cloud. Saméméhna, kuring mingpin ngembangkeun balancer L7 pikeun portal Yandex - kolega guyonan yén euweuh urusan naon atuh, tétéla janten balancer a. Kuring bakal nyarioskeun ka pamiarsa Habr kumaha ngatur beban dina platform awan, naon anu urang tingali salaku alat idéal pikeun ngahontal tujuan ieu, sareng kumaha urang nuju ngawangun alat ieu.
Kahiji, hayu urang ngenalkeun sababaraha istilah:
- VIP (Virtual IP) - alamat IP balancer
- Server, backend, conto - mesin virtual sareng aplikasi anu ngajalankeun
- RIP (Real IP) - alamat IP server
- Healthcheck - mariksa kesiapan server
- Zona Kasadiaan, AZ - infrastruktur terasing dina pusat data
- Wewengkon - a union of AZs béda
Penyeimbang beban ngarengsekeun tilu pancén utama: aranjeunna ngalaksanakeun kasaimbangan sorangan, ningkatkeun kasabaran kasalahan jasa, sareng nyederhanakeun skala na. Kasabaran sesar dipastikeun ngaliwatan manajemén lalu lintas otomatis: panyimbang ngawas kaayaan aplikasi sareng ngaluarkeun instansi tina kasaimbangan anu henteu lulus cek liveness. Skala dipastikeun ku ngadistribusikaeun beban anu merata ka sadaya instansi, kitu ogé ngamutahirkeun daptar instansi dina laleur. Upami balancingna henteu cekap seragam, sababaraha instansi bakal nampi beban anu ngaleuwihan wates kapasitasna, sareng jasana bakal kirang dipercaya.
A balancer beban mindeng digolongkeun ku lapisan protokol ti model OSI on mana eta dijalankeun. Cloud Balancer beroperasi dina tingkat TCP, nu pakait jeung lapisan kaopat, L4.
Hayu urang ngaléngkah ka tinjauan ngeunaan arsitektur Cloud balancer. Urang laun-laun bakal ningkatkeun tingkat detil. Urang ngabagi komponén balancer kana tilu kelas. Kelas pesawat config tanggung jawab interaksi pamaké sarta nyimpen kaayaan sasaran sistem. Pesawat kontrol nyimpen kaayaan sistem ayeuna sareng ngatur sistem tina kelas pesawat data, anu tanggung jawab langsung pikeun ngirimkeun lalu lintas ti klien ka instansi anjeun.
pesawat data
Lalu lintas ditungtungan dina alat anu mahal anu disebut router wates. Pikeun ningkatkeun kasabaran kasalahan, sababaraha alat sapertos beroperasi sakaligus dina hiji pusat data. Salajengna, lalulintas nuju ka balancers, anu ngumumkeun alamat IP anycast ka sadaya AZs via BGP pikeun klien.
Lalu lintas dikirimkeun ngaliwatan ECMP - ieu mangrupikeun strategi routing numutkeun yén tiasa aya sababaraha rute anu sami sareng udagan (dina hal urang, udagan bakal alamat IP tujuan) sareng pakét tiasa dikirim sapanjang salah sahijina. Urang ogé ngarojong gawé di sababaraha zona kasadiaan nurutkeun skéma handap: urang Ngaiklan hiji alamat di unggal zone, lalulintas mana anu pangcaketna sarta henteu ngaleuwihan wates na. Engké di pos urang bakal kasampak di leuwih jéntré naon kajadian ka lalulintas.
pesawat config
Komponén konci pesawat config nyaeta API, ngaliwatan nu operasi dasar kalawan balancers dipigawé: nyieun, mupus, ngarobah komposisi instansi, meunangkeun hasil healthchecks, jsb Di hiji sisi, ieu mangrupa REST API, sarta dina lain, urang di Awan sering pisan ngagunakeun kerangka gRPC, ku kituna urang "narjamahkeun" REST ka gRPC lajeng nganggo ukur gRPC. Sakur pamundut ngakibatkeun kreasi runtuyan tugas idempotent Asynchronous nu dieksekusi dina pool umum pagawe Yandex.Cloud. Tugas ditulis dina cara nu bisa ditunda iraha wae lajeng restarted. Ieu ensures scalability, repeatability na logging operasi.
Hasilna, tugas ti API bakal nyieun pamundut ka controller jasa balancer, nu ditulis dina Go. Éta tiasa nambihan sareng ngahapus kasaimbangan, ngarobih komposisi backend sareng setélan.
Ladenan nyimpen kaayaan na di Yandex Database, database anu dikelola anu disebarkeun anu bakal tiasa dianggo engké. Dina Yandex.Cloud, sakumaha urang geus , konsép dahareun anjing lumaku: lamun urang sorangan ngagunakeun jasa kami, teras klien kami ogé bakal senang ngagunakeun éta. Yandex Database mangrupikeun conto palaksanaan konsép sapertos kitu. Urang nyimpen sakabeh data urang di YDB, sarta kami teu kudu mikir ngeunaan ngajaga tur skala database: masalah ieu direngsekeun pikeun urang, urang ngagunakeun database salaku layanan a.
Hayu urang balik deui ka controller balancer. Tugasna nyaéta pikeun ngahemat inpormasi ngeunaan kasaimbangan sareng ngirim tugas pikeun mariksa kesiapan mesin virtual ka pangontrol healthcheck.
Kontrol kaséhatan
Éta nampi pamundut pikeun ngarobih aturan cek, simpen dina YDB, nyebarkeun tugas diantara titik-titik healtcheck sareng ngumpulkeun hasil, anu teras disimpen kana pangkalan data sareng dikirim ka pengendali loadbalancer. Ieu, kahareupna ngirimkeun pamundut pikeun ngarobah komposisi klaster dina pesawat data ka loadbalancer-titik, nu kuring bakal ngabahas handap.
Hayu urang ngobrol langkung seueur ngeunaan pamariksaan kaséhatan. Éta bisa dibagi kana sababaraha kelas. Audits gaduh kriteria kasuksésan anu béda. Cék TCP kedah suksés ngadamel sambungan dina waktos anu tetep. Cék HTTP butuh sambungan anu suksés sareng réspon kalayan kode status 200.
Ogé, cék béda dina kelas tindakan - aranjeunna aktip sareng pasip. Cék pasip ngan saukur ngawas naon anu lumangsung sareng lalu lintas tanpa ngalakukeun tindakan khusus. Ieu henteu dianggo saé pisan dina L4 sabab gumantung kana logika protokol tingkat luhur: dina L4 henteu aya inpormasi ngeunaan sabaraha lami operasina atanapi naha parantosan sambungan saé atanapi goréng. cék aktip merlukeun balancer pikeun ngirim requests ka unggal conto server.
Kaseueuran penyeimbang beban ngalaksanakeun cek liveness sorangan. Di Cloud, kami mutuskeun pikeun misahkeun bagian-bagian sistem ieu pikeun ningkatkeun skalabilitas. Pendekatan ieu bakal ngamungkinkeun urang ningkatkeun jumlah pangimbang bari ngajaga jumlah pamenta pamariksaan kaséhatan pikeun jasa éta. Pamariksaan dilaksanakeun ku titik-titik pamariksaan kaséhatan anu kapisah, dimana target pamariksaan dirobih sareng direplikasi. Anjeun teu bisa ngalakukeun cék ti hiji host, sabab bisa gagal. Lajeng urang moal meunang kaayaan instansi anjeunna dipariksa. Urang ngalakukeun cék on salah sahiji instansi ti sahanteuna tilu titik healthcheck. Urang beling tujuan cék antara titik ngagunakeun algoritma hashing konsisten.
Pamisahan balancing sareng pamariksaan kaséhatan tiasa nyababkeun masalah. Lamun titik healthcheck nyieun requests ka conto, bypassing balancer (anu ayeuna teu ngalayanan lalulintas), lajeng kaayaan aneh timbul: sumberdaya sigana hirup, tapi lalulintas moal ngahontal eta. Kami ngabéréskeun masalah ieu ku cara kieu: kami dijamin bakal ngamimitian lalu lintas pamariksaan kaséhatan ngaliwatan pangimbang. Dina basa sejen, skéma pikeun mindahkeun pakét kalayan lalulintas ti klien tur ti healthchecks béda minimally: dina duanana kasus, pakét bakal ngahontal balancers, nu bakal nganteurkeun aranjeunna ka sumber daya.
Bédana nyaéta yén para klien naroskeun ka VIP, sedengkeun pamariksaan kaséhatan ngadamel pamundut ka unggal RIP individu. Masalah anu pikaresepeun timbul di dieu: kami masihan pangguna kasempetan pikeun nyiptakeun sumber daya dina jaringan IP abu. Hayu urang ngabayangkeun yén aya dua pamilik awan béda anu nyumputkeun jasa maranéhanana balik balancers. Masing-masing gaduh sumber daya dina subnet 10.0.0.1/24, sareng alamat anu sami. Anjeun kedah tiasa kumaha waé ngabédakeunana, sareng di dieu anjeun kedah teuleum kana struktur jaringan virtual Yandex.Cloud. Éta leuwih alus pikeun manggihan leuwih rinci dina , Kadé pikeun urang kiwari yén jaringan téh multi-layered sarta boga torowongan nu bisa dibédakeun ku subnet id.
Healthcheck titik kontak balancers ngagunakeun disebut alamat quasi-IPv6. Alamat kuasi mangrupikeun alamat IPv6 kalayan alamat IPv4 sareng id subnet pangguna anu dipasang di jerona. Lalu lintas ngahontal balancer, nu extracts alamat sumberdaya IPv4 ti dinya, ngaganti IPv6 kalawan IPv4 sarta ngirimkeun pakét ka jaringan pamaké.
Lalu lintas sabalikna jalanna sami: pangimbang ningali yén tujuanna nyaéta jaringan abu-abu ti panyeker kaséhatan, sareng ngarobih IPv4 kana IPv6.
VPP - jantung pesawat data
Balancer dilaksanakeun nganggo téknologi Vector Packet Processing (VPP), kerangka ti Cisco pikeun ngolah angkatan lalu lintas jaringan. Dina kasus urang, kerangka dianggo dina luhureun perpustakaan manajemén alat jaringan-pamaké - Data Plane Development Kit (DPDK). Ieu ensures kinerja processing pakét luhur: leuwih saeutik interrupts lumangsung dina kernel, sarta teu aya switch konteks antara spasi kernel jeung spasi pamaké.
VPP langkung jauh sareng nyepetkeun kinerja anu langkung seueur tina sistem ku cara ngahijikeun bungkusan kana bets. Keuntungan kinerja asalna tina pamakéan agrésif cache dina prosesor modern. Duanana cache data dipaké (pakét diprosés dina "vektor", data deukeut ka silih) jeung caches instruksi: dina VPP, processing pakét nuturkeun grafik, titik nu ngandung fungsi nu ngalakukeun tugas anu sarua.
Contona, ngolah pakét IP dina VPP lumangsung dina urutan handap: kahiji, headers pakét anu parsed dina titik parsing, lajeng aranjeunna dikirim ka titik, nu diteruskeun pakét salajengna nurutkeun tabel routing.
A hardcore saeutik. Panulis VPP henteu toleran kompromi dina panggunaan cache prosesor, janten kode khas pikeun ngolah vektor pakét ngandung vektorisasi manual: aya loop pamrosésan dimana kaayaan sapertos "urang gaduh opat pakét dina antrian" diolah, lajeng sami pikeun dua, lajeng - pikeun hiji. Parentah prefetch sering dianggo pikeun ngamuat data kana cache pikeun nyepetkeun aksés ka aranjeunna dina iterasi salajengna.
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);
}Janten, Healthchecks nyarioskeun IPv6 ka VPP, anu janten IPv4. Hal ieu dilakukeun ku titik dina grafik, nu urang sebut algorithmic NAT. Pikeun lalulintas sabalikna (jeung konversi ti IPv6 ka IPv4) aya algoritma NAT titik sarua.
Lalu lintas langsung ti klien pangimbang ngalangkungan titik-titik grafik, anu ngalaksanakeun kasaimbangan sorangan.
Titik kahiji nyaéta sési caket. Ieu nyimpen hash tina pikeun sesi ngadegkeun. 5-tuple ngawengku alamat na port of klien ti mana informasi dikirimkeun, alamat jeung palabuhan sumberdaya sadia pikeun lalulintas narima, kitu ogé protokol jaringan.
Hash 5-tuple ngabantosan urang ngalakukeun komputasi anu kirang dina node hashing anu konsisten salajengna, sareng ogé parobahan daptar sumberdaya anu langkung saé di tukangeun kasaimbangan. Nalika pakét anu henteu aya sési dugi ka pangimbang, éta dikirim ka titik hashing anu konsisten. Ieu dimana balancing lumangsung ngagunakeun hashing konsisten: urang milih sumberdaya tina daptar sadia "live" sumberdaya. Salajengna, pakét dikirim ka titik NAT, anu saleresna ngagentos alamat tujuan sareng ngitung deui checksum. Sakumaha anjeun tiasa tingali, urang nuturkeun aturan VPP - resep resep, ngagolongkeun itungan sarupa pikeun ngaronjatkeun efisiensi tina caches processor.
Hashing konsisten
Naha urang milih éta sareng naon éta? Kahiji, hayu urang nganggap tugas saméméhna - milih sumberdaya tina daptar.
Kalawan hashing inconsistent, Hash tina pakét asup diitung, sarta sumberdaya dipilih tina daptar ku sésana ngabagi hash ieu ku jumlah sumberdaya. Salami daptar tetep unchanged, skéma ieu jalan ogé: urang salawasna ngirim pakét jeung 5-tuple sarua ka conto sarua. Upami, contona, sababaraha sumber lirén ngaréspon kana pamariksaan kaséhatan, maka pikeun bagian anu penting tina hashes pilihanna bakal robih. Sambungan TCP klien bakal pegat: pakét nu saméméhna ngahontal conto A bisa mimiti ngahontal conto B, nu teu wawuh jeung sési pikeun pakét ieu.
Hashing konsisten ngarengsekeun masalah anu dijelaskeun. Cara panggampangna pikeun ngajelaskeun konsép ieu nyaéta kieu: bayangkeun yén anjeun gaduh cingcin anu anjeun ngadistribusikaeun sumber ku Hash (contona, ku IP: port). Milih sumberdaya a ngarobah kabayang ku hiji sudut, nu ditangtukeun ku hash pakét.
Ieu ngaminimalkeun redistribusi lalulintas nalika komposisi sumberdaya robah. Mupus sumberdaya ngan bakal mangaruhan bagian tina cingcin hashing konsisten dimana sumberdaya ieu lokasina. Nambahkeun sumberdaya a ogé ngarobah distribusi, tapi urang boga titik sesi caket, nu ngidinan urang teu pindah sesi geus ngadegkeun keur sumberdaya anyar.
Urang nempo naon kajadian langsung lalulintas antara balancer jeung sumberdaya. Ayeuna hayu urang nempo lalulintas balik. Éta nuturkeun pola anu sami sareng lalu lintas cek - ngalangkungan NAT algorithmic, nyaéta, ngalangkungan sabalikna NAT 44 pikeun lalu lintas klien sareng ngalangkungan NAT 46 pikeun lalu lintas pamariksaan kaséhatan. Kami taat kana skéma urang sorangan: urang ngahijikeun lalu lintas pamariksaan kaséhatan sareng lalu lintas pangguna nyata.
Loadbalancer-titik sareng komponén dirakit
Komposisi kasaimbangan sareng sumber daya di VPP dilaporkeun ku jasa lokal - loadbalancer-node. Ieu ngalanggan aliran acara ti loadbalancer-controller sarta sanggup plot béda antara kaayaan VPP ayeuna jeung kaayaan target narima ti controller. Simkuring meunang sistem katutup: acara ti API datang ka controller balancer, nu napelkeun tugas ka controller healthcheck mariksa "liveness" sumberdaya. Éta, kahareupna napelkeun tugas ka healthcheck-titik na aggregates hasilna, nu satutasna eta dikirimkeun deui ka controller balancer. Loadbalancer-titik ngalanggan acara ti controller sarta ngarobah kaayaan VPP. Dina sistem sapertos kitu, unggal jasa ngan ukur terang naon anu diperyogikeun ngeunaan jasa tatangga. Jumlah sambungan diwatesan sarta kami boga kamampuh pikeun beroperasi sarta skala bagéan béda sacara mandiri.
Masalah naon anu dihindari?
Sadaya jasa kami dina pesawat kontrol ditulis dina Go sareng gaduh ciri skala sareng reliabilitas anu saé. Go gaduh seueur perpustakaan open source pikeun ngawangun sistem anu disebarkeun. Kami aktip nganggo GRPC, sadaya komponén ngandung palaksanaan open source pikeun penemuan jasa - jasa kami ngawas kinerja masing-masing, tiasa ngarobih komposisina sacara dinamis, sareng kami ngaitkeun ieu sareng kasaimbangan GRPC. Pikeun métrik, kami ogé nganggo solusi open source. Dina pesawat data, urang ngagaduhan kinerja santun sarta cagar sumberdaya badag: tétéla hésé pisan ngumpul stand nu urang bisa ngandelkeun kinerja hiji VPP, tinimbang hiji kartu jaringan beusi.
Masalah jeung Solusi
Naon anu henteu dianggo saé? Go gaduh manajemén mémori otomatis, tapi bocor mémori tetep kajantenan. Cara panggampangna pikeun nungkulan aranjeunna nyaéta ngajalankeun goroutine sareng émut pikeun ngeureunkeunana. Takeaway: Lalajo konsumsi memori program Go anjeun. Mindeng indikator alus nyaeta jumlah goroutines. Aya tambah dina carita ieu: di Go éta gampang pikeun meunangkeun data runtime - konsumsi memori, jumlah goroutines ngajalankeun, sarta loba parameter séjén.
Ogé, Go tiasa janten pilihan anu pangsaéna pikeun tés fungsional. Aranjeunna rada verbose, sarta pendekatan baku "ngajalankeun sagalana di CI dina bets a" teu cocog pisan pikeun aranjeunna. Kanyataanna nyaéta tés fungsional langkung nungtut sumber daya sareng nyababkeun waktosna nyata. Kusabab ieu, tés tiasa gagal sabab CPU sibuk sareng tés unit. Kacindekan: Upami mungkin, laksanakeun tés "beurat" misah ti tés unit.
arsitéktur acara Microservice leuwih kompleks tinimbang monolith a: ngumpulkeun log on puluhan mesin béda teu pisan merenah. Kacindekan: lamun nyieun microservices, geuwat pikir ngeunaan tracing.
rencana urang
Urang bakal ngajalankeun hiji balancer internal, hiji balancer IPv6, nambahkeun rojongan pikeun Aksara Kubernetes, neruskeun beling jasa kami (ayeuna ngan healthcheck-node jeung healthcheck-ctrl nu sharded), nambahkeun healthchecks anyar, sarta ogé nerapkeun smart aggregation tina cék. Kami nganggap kamungkinan ngajantenkeun jasa kami langkung mandiri - supados aranjeunna henteu komunikasi langsung, tapi nganggo antrian pesen. Ladenan anu cocog sareng SQS nembe muncul dina Cloud .
Anyar-anyar ieu, sékrési umum Yandex Load Balancer lumangsung. Ngajalajah kana jasa, ngatur balancers dina cara merenah pikeun anjeun sarta ngaronjatkeun kasabaran sesar proyek Anjeun!
sumber: www.habr.com