Puseur data modéren ngagaduhan ratusan alat aktip anu dipasang, ditutupan ku sababaraha jinis monitoring. Tapi sanajan insinyur idéal kalayan ngawaskeun sampurna dina leungeun bakal tiasa leres ngabales kagagalan jaringan dina ukur sababaraha menit. Dina laporan dina konperénsi Next Hop 2020, kuring nampilkeun metodologi desain jaringan DC, anu gaduh fitur unik - pusat data nyageurkeun sorangan dina milidetik. Leuwih tepat, insinyur kalem ngalereskeun masalah, sedengkeun jasa ngan teu aya bewara eta.
Pikeun seueur insinyur jaringan, jaringan pusat data dimimitian, tangtosna, nganggo ToR, kalayan saklar dina rak. ToR biasana ngagaduhan dua jinis tautan. Anu leutik nuju ka server, anu sanés - aya N kali langkung seueur - nuju ka tulang tonggong tingkat kahiji, nyaéta, kana uplink na. Uplinks biasana dianggap sarua, sarta lalulintas antara uplinks saimbang dumasar kana Hash ti 5-tuple, nu ngawengku proto, src_ip, dst_ip, src_port, dst_port. Taya kejutan di dieu.
Salajengna, kumaha rupa arsitéktur rencana? Spines tingkat kahiji teu disambungkeun ka silih, tapi disambungkeun ngaliwatan superspines. Huruf X bakal tanggung jawab pikeun superspines; éta ampir sapertos sambungan silang.
Sareng jelas yén, di sisi anu sanés, tori dihubungkeun ka sadaya tulang tonggong tingkat kahiji. Naon anu penting dina gambar ieu? Upami urang gaduh interaksi di jero rak, maka interaksi, tangtosna, ngalangkungan ToR. Lamun interaksi lumangsung di jero modul, lajeng interaksi lumangsung ngaliwatan spines tingkat kahiji. Upami interaksina intermodular - sapertos di dieu, ToR 1 sareng ToR 2 - maka interaksi bakal ngalangkungan tulang tonggong tingkat kahiji sareng kadua.
Sacara tiori, arsitéktur sapertos kitu gampang skala. Lamun urang boga kapasitas port, spasi cadang di puseur data jeung serat pre-diteundeun, teras jumlah jalur bisa salawasna ngaronjat, kukituna ngaronjatkeun kapasitas sakabéh sistem. Ieu gampang pisan dilakukeun dina kertas. Éta bakal sapertos kieu dina kahirupan. Tapi carita dinten ieu teu ngeunaan éta.
Abdi hoyong kasimpulan anu leres. Kami ngagaduhan seueur jalur di jero pusat data. Aranjeunna conditionally bebas. Hiji jalur di jero pusat data ngan ukur tiasa di jero ToR. Di jero modul, urang gaduh jumlah jalur anu sami sareng jumlah jalur. Jumlah jalur antara modul sarua jeung produk tina jumlah pesawat jeung jumlah superspines dina unggal pesawat. Sangkan leuwih jelas, pikeun meunangkeun rasa skala, abdi bakal masihan nomer anu valid pikeun salah sahiji puseur data Yandex.
Aya dalapan pesawat, unggal pesawat gaduh 32 superspines. Hasilna, tétéla aya dalapan jalur di jero modul, sarta kalawan interaksi intermodule geus aya 256 di antarana.
Nyaéta, upami urang nuju ngembangkeun Cookbook, nyobian diajar kumaha ngawangun pusat data toleran-lepat anu nyageurkeun sorangan, maka arsitéktur planar mangrupikeun pilihan anu pas. Éta ngarengsekeun masalah skala, sareng dina téori éta gampang. Aya seueur jalur mandiri. Patarosan tetep: kumaha arsitéktur sapertos salamet gagal? Aya rupa-rupa kagagalan. Sarta kami bakal ngabahas ieu ayeuna.
Hayu salah sahiji superspines urang "geuring". Di dieu kuring balik ka arsitektur dua-pesawat. Urang bakal lengket kalayan ieu salaku conto sabab ngan saukur bakal leuwih gampang pikeun nempo naon anu lumangsung kalawan saeutik bagian pindah. Hayu X11 gering. Kumaha ieu bakal mangaruhan jasa anu cicing di jero pusat data? Loba gumantung kana naon sabenerna kagagalan kasampak kawas.
Upami kagagalanna saé, éta kawengku dina tingkat otomatisasi BFD anu sami, otomatisasi happily nempatkeun sendi masalah sareng ngasingkeun masalah, teras sadayana henteu kunanaon. Kami ngagaduhan seueur jalur, lalu lintas langsung dialihkeun deui ka rute alternatif, sareng jasa moal aya bewara nanaon. Ieu naskah alus.
Skenario anu goréng nyaéta upami urang gaduh karugian konstan, sareng otomatisasi henteu perhatikeun masalahna. Pikeun ngartos kumaha ieu mangaruhan aplikasi, urang kedah nyéépkeun waktos sakedik ngabahas kumaha TCP jalanna.
Kuring miharep kuring teu shock saha jeung informasi ieu: TCP mangrupakeun protokol konfirmasi transmisi. Nyaéta, dina kasus pangbasajanna, pangirim ngirim dua pakét sareng nampi ack kumulatif: "Kuring nampi dua pakét."
Saatos éta, anjeunna bakal ngirim dua pakét deui, sareng kaayaan bakal diulang deui. Hapunten sateuacanna pikeun sababaraha nyederhanakeun. Skenario ieu leres upami jandela (jumlah pakét dina hiber) dua. Tangtu, dina kasus umum ieu teu merta kasus. Tapi ukuran jandela henteu mangaruhan kontéks diteruskeun pakét.
Naon kajadian lamun urang leungit pakét 3? Dina hal ieu, panarima bakal nampa pakét 1, 2 jeung 4. Sarta anjeunna eksplisit ngabejaan pangirim ngagunakeun pilihan karung: "Anjeun nyaho, tilu anjog, tapi tengahna leungit." Anjeunna nyarios, "Ack 2, SACK 4."
Dina momen ieu, pangirim tanpa masalah ngulang persis pakét anu leungit.
Tapi lamun pakét panungtungan dina jandela leungit, kaayaan bakal béda lengkep.
Panarima nampi tilu pakét anu munggaran sareng mimitina ngantosan. Hatur nuhun kana sababaraha optimasi dina tumpukan TCP kernel Linux, éta bakal ngadagoan pakét anu dipasangkeun iwal bandéra sacara eksplisit nunjukkeun yén éta mangrupikeun pakét anu terakhir atanapi anu sami. Bakal ngadagoan nepi ka tunda ACK seep kadaluwarsa lajeng ngirim hiji pangakuan dina tilu pakét munggaran. Tapi ayeuna pangirim bakal ngantosan. Anjeunna henteu terang naha bungkusan kaopat parantos leungit atanapi badé sumping. Sarta dina urutan teu overload jaringan, éta bakal nyobian ngadagoan hiji indikasi eksplisit yén pakét leungit, atawa pikeun RTO timeout kadaluwarsa.
Naon waktosna RTO? Ieu maksimum RTT diitung ku TCP tumpukan jeung sababaraha konstanta. Naon jenis konstanta ieu, ayeuna urang bakal ngabahas.
Tapi hal anu penting nyaéta lamun urang sial deui jeung pakét kaopat leungit deui, teras RTO ganda. Hartina, unggal usaha anu gagal hartosna ngagandakeun waktosna.
Ayeuna hayu urang tingali naon dasar ieu sarua. Sacara standar, RTO minimum nyaéta 200 mdet. Ieu mangrupikeun RTO minimum pikeun pakét data. Pikeun pakét SYN béda, 1 detik. Sakumaha anjeun tiasa tingali, sanajan usaha munggaran pikeun ngirim ulang pakét bakal nyandak 100 kali leuwih panjang batan RTT jero puseur data.
Ayeuna hayu urang balik deui ka skenario urang. Naon anu lumangsung dina jasa? Jasa mimiti kaleungitan pakét. Hayu jasa jadi conditionally untung mimiti na leungit hiji hal di tengah jandela, lajeng eta narima karung sarta resends pakét anu leungit.
Tapi lamun nasib goréng repeats sorangan, lajeng urang boga RTO. Naon anu penting di dieu? Leres, urang gaduh seueur jalur dina jaringan urang. Tapi lalulintas TCP tina hiji sambungan TCP tangtu bakal neruskeun ngaliwatan tumpukan rusak sarua. Karugian pakét, upami X11 gaib ieu milik urang henteu kaluar nyalira, henteu ngakibatkeun lalu lintas anu ngalir ka daérah anu henteu masalah. Kami nyobian nganteurkeun pakét ngaliwatan tumpukan rusak anu sami. Ieu ngakibatkeun kagagalan cascading: puseur data nyaéta sakumpulan aplikasi interacting, sarta sababaraha sambungan TCP sadaya aplikasi ieu mimiti ngadegradasi - sabab superspine mangaruhan sakabeh aplikasi nu aya di jero puseur data. Salaku nyebutkeun nyebutkeun: lamun teu sapatu kuda, kuda indit lame; kuda indit lame - laporan teu dikirimkeun; laporan teu dikirimkeun - urang leungit perang. Ngan di dieu cacah dina detik ti momen timbul masalah nepi ka tahap degradasi nu jasa mimiti ngarasa. Ieu ngandung harti yén pamaké bisa leungit kaluar dina hiji tempat.
Aya dua solusi klasik anu saling ngalengkepan. Anu kahiji nyaéta jasa anu nyobian nempatkeun jarami sareng ngabéréskeun masalah sapertos kieu: "Hayu urang tweak hiji hal dina tumpukan TCP. Hayu urang ngadamel waktos waktos di tingkat aplikasi atanapi sési TCP umur panjang kalayan pamariksaan kaséhatan internal. Masalahna nyaéta yén solusi sapertos: a) henteu skala pisan; b) pisan kirang dipariksa. Nyaéta, sanaos jasa ngahaja ngonpigurasi tumpukan TCP ku cara anu ngajantenkeun langkung saé, mimitina, sigana henteu tiasa dianggo pikeun sadaya aplikasi sareng sadaya pusat data, sareng kadua, paling dipikaresep, éta moal ngartos yén éta dilakukeun. leres, sareng naon henteu. Nyaéta, éta tiasa dianggo, tapi jalanna kirang sareng henteu skala. Sareng upami aya masalah jaringan, saha anu kedah disalahkeun? Tangtu, NOC. Naon anu dilakukeun ku NOC?
Seueur jasa anu yakin yén dina NOC damel aya kajadian sapertos kieu. Tapi mun jujur, teu ngan éta.
NOC dina skéma klasik kalibet dina ngembangkeun loba sistem monitoring. Ieu duanana kotak hideung ngawaskeun kotak bodas. Ngeunaan conto ngawaskeun tulang tonggong kotak hideung Alexander Klimenko dina panungtungan Next Hop. Ku jalan kitu, ngawaskeun ieu jalan. Tapi sanajan ngawaskeun idéal bakal gaduh waktos lag. Biasana ieu sababaraha menit. Saatos éta pareum, insinyur anu ditugaskeun peryogi waktos pikeun pariksa deui operasina, ngalokalkeun masalah teras mareuman daérah masalah. Hartina, dina kasus pangalusna, ngubaran masalah nyokot 5 menit, dina kasus awon, 20 menit, lamun teu langsung atra dimana karugian lumangsung. Éta jelas yén sadaya waktos ieu - 5 atanapi 20 menit - jasa kami bakal terus sangsara, anu sigana henteu saé.
Naon anu anjeun hoyong nampi? Urang gaduh seueur cara. Sareng masalah timbul persis kusabab aliran TCP anu sial terus nganggo jalur anu sami. Urang peryogi hal anu ngamungkinkeun urang ngagunakeun sababaraha rute dina hiji sambungan TCP. Sigana urang gaduh solusi. Aya TCP, nu disebut multipath TCP, nyaeta, TCP pikeun sababaraha jalur. Leres, éta dikembangkeun pikeun tugas anu béda-béda - pikeun smartphone anu ngagaduhan sababaraha alat jaringan. Pikeun maksimalkeun transfer atanapi ngadamel modeu primér / cadangan, mékanisme dikembangkeun anu nyiptakeun sababaraha utas (sesi) sacara transparan kana aplikasi sareng ngamungkinkeun anjeun ngalih antara aranjeunna upami aya kagagalan. Atawa, sakumaha ceuk kuring, maksimalkeun streak.
Tapi aya nuansa di dieu. Pikeun ngartos naon éta, urang kedah ningali kumaha benang didamel.
Threads dipasang sequentially. Thread munggaran dipasang heula. Utas saterasna teras disetél nganggo cookie anu parantos disatujuan dina benang éta. Sareng ieu masalahna.
Masalahna nyaeta lamun thread kahiji teu ngadegkeun sorangan, thread kadua jeung katilu moal timbul. Hartina, multipath TCP teu ngajawab leungitna pakét SYN dina aliran munggaran. Sareng upami SYN leungit, TCP multipath janten TCP biasa. Ieu ngandung harti yén dina lingkungan puseur data eta moal mantuan kami ngajawab masalah karugian di pabrik jeung diajar ngagunakeun sababaraha jalur dina acara gagal.
Naon anu tiasa ngabantosan urang? Sababaraha anjeun parantos nebak tina judulna yén widang anu penting dina carita salajengna urang bakal janten lapangan lulugu labél aliran IPv6. Mémang, ieu mangrupikeun lapangan anu muncul dina v6, henteu aya dina v4, nempatan 20 bit, sareng parantos aya kontroversi ngeunaan panggunaanana pikeun lami. Ieu pisan metot - aya sengketa, hal ieu dibereskeun dina RFC, sarta dina waktos anu sareng palaksanaan mucunghul dina kernel Linux Ubuntu, nu teu documented mana.
Kuring ngajak anjeun angkat sareng kuring dina panalungtikan sakedik. Hayu urang tingali naon anu lumangsung dina kernel Linux dina sababaraha taun katukang.
taun 2014. Insinyur ti hiji perusahaan ageung sareng terhormat nambihan kana pungsionalitas kernel Linux gumantungna nilai labél aliran dina hash stop kontak. Naon anu aranjeunna nyobian ngalereskeun di dieu? Ieu aya hubunganana sareng RFC 6438, anu ngabahas masalah ieu di handap. Di jero puseur data, IPv4 mindeng encapsulated dina pakét IPv6, sabab pabrik sorangan IPv6, tapi IPv4 kudu kumaha bae dibikeun ka luar. Pikeun lila aya masalah sareng switch nu teu bisa kasampak dina dua headers IP pikeun meunang ka TCP atanapi UDP sarta manggihan src_ports, dst_ports aya. Tétéla yén hash, upami anjeun ningali dua header IP anu munggaran, tétéla ampir dibenerkeun. Pikeun ngahindarkeun ieu, ku kituna balancing lalulintas encapsulated ieu jalan leres, ieu diusulkeun pikeun nambahkeun hash tina 5-tuple encapsulated pakét kana nilai widang labél aliran. Kira-kira hal anu sarua dipigawé pikeun skéma encapsulation séjén, pikeun UDP, pikeun GRE, dimungkinkeun dipaké widang GRE Key. Hiji cara atanapi anu sanés, tujuan di dieu jelas. Sareng sahenteuna dina waktos éta aranjeunna mangpaat.
Taun 2015, patch énggal asalna ti insinyur anu dihormati anu sami. Anjeunna pisan metot. Ieu nyebutkeun handap - urang bakal randomize Hash bisi tina acara routing négatip. Naon acara routing négatip? Ieu RTO nu urang bahas saméméhna, nyaeta, leungitna buntut tina jandéla mangrupa acara anu sabenerna négatip. Leres, rélatif hese nebak yén éta téh.
2016, parusahaan reputable sejen, ogé badag. Ieu disassembles nu crutches panungtungan sarta ngajadikeun eta supados Hash, nu urang saméméhna dijieun acak, ayeuna robah pikeun tiap retransmission SYN sarta sanggeus unggal RTO timeout. Sarta dina surat ieu, pikeun kahiji jeung panungtungan waktu, tujuan pamungkas dinyatakeun - pikeun mastikeun yén lalulintas dina acara karugian atawa kamacetan channel mibanda kamampuhan pikeun jadi lemes ulang routed sarta ngagunakeun sababaraha jalur. Tangtu, sanggeus ieu aya loba publikasi, anjeun bisa kalayan gampang manggihan aranjeunna.
Sanaos henteu, anjeun henteu tiasa, sabab teu acan aya publikasi tunggal ngeunaan topik ieu. Tapi urang terang!
Sareng upami anjeun henteu ngartos naon anu dilakukeun, kuring bakal nyarioskeun ka anjeun ayeuna.
Naon anu dilakukeun, fungsionalitas naon anu ditambahkeun kana kernel Linux? txhash robah jadi nilai acak sanggeus unggal acara RTO. Ieu hasil pisan négatip tina routing. Hash gumantung kana txhash ieu, sareng labél aliran gumantung kana hash skb. Aya sababaraha itungan dina fungsi di dieu; sadaya detil teu tiasa disimpen dina hiji slide. Upami aya anu panasaran, anjeun tiasa ngaliwat kode kernel sareng pariksa.
Naon anu penting di dieu? Nilai widang labél aliran robah jadi angka acak sanggeus unggal RTO. Kumaha ieu mangaruhan aliran TCP kami?
Mun karung a lumangsung, nanaon robah sabab urang nyoba resend a dipikawanoh pakét leungit. Dugi ayeuna mah saé.
Tapi dina kasus RTO, disadiakeun yén kami geus ditambahkeun labél aliran kana fungsi Hash on ToR, lalulintas bisa nyandak jalur béda. Sareng langkung seueur jalur, langkung ageung kasempetan éta bakal mendakan jalur anu henteu kapangaruhan ku gagal dina alat khusus.
Hiji masalah tetep - RTO. Tangtosna, aya rute anu sanés, tapi seueur waktos anu dibuang dina ieu. 200 ms pisan. Sadetik kacida liar. Saméméhna, kuring ngobrol ngeunaan timeouts yén jasa anu ngonpigurasi. Janten, sadetik mangrupikeun waktosna, anu biasana dikonpigurasi ku jasa dina tingkat aplikasi, sareng dina hal ieu jasa éta bakal leres-leres. Sumawona, kuring ngulang, RTT nyata di jero pusat data modern sakitar 1 milidetik.
Naon anu anjeun tiasa laksanakeun sareng waktosna RTO? The timeout, nu jawab RTO bisi leungitna pakét data, bisa ngonpigurasi rélatif gampang ti spasi pamaké: aya hiji utiliti IP, sarta salah sahiji parameter na ngandung rto_min sarua. Nganggap yén RTO, tangtosna, kedah disaluyukeun henteu sacara global, tapi pikeun awalan anu dipasihkeun, mékanisme sapertos kitu sigana tiasa dianggo.
Leres, sareng SYN_RTO sadayana langkung parah. Éta sacara alami dipaku. Kernel gaduh nilai tetep 1 detik, sareng éta. Anjeun moal tiasa ngahontal éta tina rohangan pangguna. Aya ngan hiji jalan.
eBPF datang ka nyalametkeun teh. Pikeun nempatkeun éta basajan, ieu program leutik C. Éta bisa diselapkeun kana hook di tempat béda dina palaksanaan tumpukan kernel jeung tumpukan TCP, kalawan nu bisa ngarobah angka nu gede ngarupakeun setelan. Sacara umum, eBPF mangrupikeun tren jangka panjang. Gantina motong puluhan parameter sysctl anyar sareng ngalegaan utilitas IP, gerakan éta nuju ka eBPF sareng ngalegaan fungsionalitasna. Ngagunakeun eBPF, anjeun bisa dinamis ngarobah kadali kamacetan sarta sagala rupa setelan TCP lianna.
Tapi hal anu penting pikeun urang nu bisa dipaké pikeun ngarobah nilai SYN_RTO. Salaku tambahan, aya conto anu dipasang sacara umum: . Naon anu geus dipigawé di dieu? Conto éta jalan, tapi dina dirina kasar pisan. Di dieu dianggap yén di jero pusat data urang ngabandingkeun 44 bit munggaran; upami aranjeunna cocog, maka urang aya di jero pusat data. Sareng dina hal ieu urang ngarobih nilai seep SYN_RTO ka 4ms. Tugas anu sami tiasa dilakukeun langkung elegan. Tapi conto basajan ieu nunjukeun yen ieu a) mungkin; b) rélatif basajan.
Naon anu urang geus nyaho? Kanyataan yén arsitéktur pesawat ngamungkinkeun pikeun skala, tétéla mangpaat pisan pikeun urang nalika urang ngaktifkeun labél aliran dina ToR sareng kéngingkeun kamampuan pikeun ngalir di daérah masalah. Cara anu pangsaéna pikeun ngirangan nilai RTO sareng SYN-RTO nyaéta ngagunakeun program eBPF. Patarosan tetep: éta aman ngagunakeun labél aliran pikeun balancing? Sareng aya nuansa di dieu.
Anggap anjeun gaduh jasa dina jaringan anjeun anu hirup di anycast. Hanjakalna, kuring henteu gaduh waktos pikeun detil ngeunaan naon éta anycast, tapi éta mangrupikeun jasa anu disebarkeun sareng server fisik anu béda-béda tiasa diaksés liwat alamat IP anu sami. Sareng ieu mangrupikeun masalah anu mungkin: acara RTO tiasa lumangsung henteu ngan ukur nalika lalu lintas ngalangkungan lawon. Ogé bisa lumangsung dina tingkat panyangga ToR: lamun hiji acara incast lumangsung, malah bisa lumangsung dina host nalika host spills hal. Nalika hiji acara RTO lumangsung sarta robah labél aliran. Dina hal ieu, lalu lintas tiasa angkat ka conto anycast anu sanés. Hayu urang nganggap ieu téh anycast stateful, ngandung kaayaan sambungan - bisa jadi hiji L3 Balancer atawa sababaraha layanan lianna. Lajeng masalah timbul, sabab sanggeus RTO sambungan TCP datang ka server, nu nyaho nanaon tentang sambungan TCP ieu. Tur upami urang teu boga babagi kaayaan antara server anycast, lajeng lalulintas misalna bakal turun sarta sambungan TCP bakal pegat.
Naon anu anjeun tiasa laksanakeun di dieu? Dina lingkungan anu dikontrol anjeun, dimana anjeun ngaktifkeun kasaimbangan labél aliran, anjeun kedah ngarékam nilai labél aliran nalika ngaksés server anycast. Cara panggampangna nyaéta ngalakukeun ieu ngaliwatan program eBPF anu sami. Tapi ieu mangrupikeun titik anu penting pisan - naon anu kudu dilakukeun upami anjeun henteu ngajalankeun jaringan pusat data, tapi mangrupikeun operator telekomunikasi? Ieu masalah anjeun teuing: dimimitian ku versi tangtu Juniper na Arista, aranjeunna ngawengku labél aliran dina fungsi Hash maranéhanana sacara standar - terus terang, pikeun alesan anu teu jelas keur kuring. Ieu tiasa nyababkeun anjeun leupaskeun sambungan TCP ti pangguna anu ngalangkungan jaringan anjeun. Janten kuring nyarankeun pisan pariksa setélan router anjeun di dieu.
Salah sahiji cara atanapi anu sanés, sigana kuring siap ngaléngkah ka percobaan.
Nalika kami diaktipkeun labél aliran on ToR, disiapkeun agén eBPF, nu ayeuna hirup dina sarwa, urang mutuskeun teu ngadagoan gagalna badag salajengna, tapi pikeun ngalakonan ngabeledugna dikawasa. Simkuring nyandak ToR, nu boga opat uplinks, tur nyetel tetes on salah sahijina. Aranjeunna ngagambar aturan sareng nyarios - ayeuna anjeun kaleungitan sadaya pakét. Sakumaha anjeun tiasa tingali di kénca, urang gaduh monitoring per-pakét, nu geus turun ka 75%, nyaeta, 25% tina pakét leungit. Di beulah katuhu aya grafik jasa anu tinggal di tukangeun ToR ieu. Intina, ieu mangrupikeun grafik lalu lintas tina antarmuka sareng server di jero rak. Sakumaha anjeun tiasa tingali, aranjeunna sank malah handap. Naha aranjeunna turun langkung handap - henteu ku 25%, tapi dina sababaraha kasus ku 3-4 kali? Lamun sambungan TCP téh sial, eta terus nyoba ngahontal ngaliwatan simpang rusak. Ieu diperparah ku paripolah khas tina jasa di jero DC - pikeun hiji pamundut pangguna, N pamundut ka jasa internal dibangkitkeun, sareng résponna bakal angkat ka pangguna nalika sadaya sumber data ngaréspon, atanapi nalika aya waktos waktos dina aplikasi. tingkat, nu masih perlu ngonpigurasi. Maksudna, sagalana pisan, pisan goréng.
Ayeuna percobaan anu sami, tapi kalayan nilai labél aliran diaktipkeun. Sakumaha anjeun tiasa tingali, di kénca ngawaskeun bets kami turun ku 25%. Ieu leres pisan, sabab teu nyaho nanaon tentang retransmits, eta ngirimkeun pakét tur saukur ngitung babandingan jumlah dikirimkeun na leungit pakét.
Sareng di sisi katuhu nyaéta jadwal palayanan. Anjeun moal mendakan pangaruh gabungan anu bermasalah di dieu. Dina eta milliseconds sarua, lalulintas ngalir ti wewengkon masalah ka tilu uplinks sésana nu teu kapangaruhan ku masalah. Simkuring boga jaringan nu heals sorangan.
Ieu mangrupikeun slide terakhir kuring, waktos kanggo nyimpulkeun. Ayeuna, kuring ngarepkeun anjeun terang kumaha ngawangun jaringan pusat data nyageurkeun diri. Anjeun teu kedah ngaliwat arsip kernel Linux sareng milarian patch khusus di dinya; anjeun terang yén labél Flow dina hal ieu ngarengsekeun masalah, tapi anjeun kedah ngadeukeutan mékanisme ieu sacara saksama. Sareng kuring negeskeun sakali deui yén upami anjeun operator telekomunikasi, anjeun henteu kedah nganggo labél aliran salaku fungsi hash, upami henteu anjeun bakal ngaganggu sesi pangguna anjeun.
Insinyur jaringan kedah ngalaman pergeseran konseptual: jaringan henteu dimimitian ku ToR, sanés sareng alat jaringan, tapi sareng host. Conto anu cukup pikaresepeun nyaéta kumaha kami nganggo eBPF pikeun ngarobih RTO sareng ngalereskeun labél aliran nuju jasa anycast.
Mékanika labél aliran pasti cocog pikeun aplikasi sanés dina bagéan administrasi anu dikontrol. Ieu tiasa patalimarga antara pusat data, atanapi anjeun tiasa nganggo mékanika sapertos ku cara khusus pikeun ngatur lalu lintas kaluar. Tapi kuring bakal nyarioskeun ka anjeun ngeunaan ieu, kuring ngarepkeun, waktos salajengna. Hatur nuhun pisan kana perhatosanana.
sumber: www.habr.com