Pusat data modern duwe atusan piranti aktif sing dilindhungi dening macem-macem jinis pemantauan. Nanging sanajan insinyur sing sampurna kanthi pemantauan sing sampurna bakal bisa nanggapi kegagalan jaringan kanthi bener sajrone sawetara menit. Ing laporan ing konferensi Next Hop 2020, aku nampilake metodologi desain jaringan pusat data sing nduweni fitur unik - pusat data nambani dhewe ing milidetik. Luwih tepate, insinyur kanthi tenang ngatasi masalah kasebut, dene layanan kasebut ora nggatekake.
Kanggo akeh insinyur jaringan, jaringan pusat data diwiwiti, mesthi, karo ToR, kanthi saklar ing rak. ToR biasane duwe rong jinis pranala. Sing cilik pindhah menyang server, liyane - ana N kaping luwih - pindhah menyang spines tingkat pisanan, yaiku, menyang uplinks. Uplinks biasane dianggep padha, lan lalu lintas antarane uplinks imbang adhedhasar 5-tuple hash, kang kalebu proto, src_ip, dst_ip, src_port, dst_port. Ora ana kejutan ing kene.
Sabanjure, kaya apa arsitektur pesawat kasebut? Duri saka tingkat pisanan ora disambungake, nanging disambungake kanthi superspins. Huruf X bakal tanggung jawab kanggo superspins, iku meh kaya salib-sambungan.
Lan cetha yen, ing tangan liyane, tori disambungake menyang kabeh spines saka tingkat pisanan. Apa sing penting ing gambar iki? Yen kita duwe interaksi nang rak, banjur interaksi, mesthi, liwat ToR. Yen interaksi dadi nang modul, banjur interaksi liwat spines saka tingkat pisanan. Yen interaksi intermodular - kaya ing kene, ToR 1 lan ToR 2 - banjur interaksi kasebut bakal ngliwati spines saka tingkat pisanan lan kaloro.
Secara teoritis, arsitektur kasebut gampang diukur. Yen kita duwe kapasitas port, cadangan papan ing pusat data lan serat sing wis dilebokake, mula jumlah pesawat bisa terus ditambah, saengga bisa nambah kapasitas sistem sakabèhé. Ing kertas, iki gampang banget ditindakake. Iku bakal kaya ing urip nyata. Nanging crita dina iki ora bab iku.
Aku pengin kesimpulan sing bener. Kita duwe akeh dalan ing tengah data. Padha kondisional independen. Salah siji cara ing tengah data mung bisa ditindakake ing ToR. Ing modul, kita duwe nomer dalan sing padha karo jumlah pesawat. Jumlah jalur antarane modul padha karo produk saka jumlah pesawat lan nomer superspins ing saben bidang. Kanggo nggawe luwih jelas, kanggo ngrasakake skala, aku bakal menehi nomer sing bener kanggo salah sawijining pusat data Yandex.
Ana wolung pesawat, saben pesawat duwe 32 superspins. Akibaté, ternyata ana wolung dalan ing njero modul, lan kanthi interaksi antar modul wis ana 256.
Yaiku, yen kita ngembangake Cookbook, nyoba sinau babagan carane mbangun pusat data toleransi kesalahan sing bisa nambani awake dhewe, mula arsitektur planar minangka pilihan sing tepat. Iki ngidini sampeyan ngatasi masalah skala, lan kanthi teoritis gampang. Ana akeh dalan independen. Pitakonan tetep: kepiye arsitektur kasebut bisa tahan gagal? Ana macem-macem kacilakan. Lan kita bakal ngrembug iki saiki.
Ayo salah siji saka superspin kita lara. Ing kene aku bali menyang arsitektur rong pesawat. Kita bakal tetep dadi conto amarga bakal luwih gampang ndeleng apa sing kedadeyan ing kene kanthi bagean sing luwih sithik. Ayo X11 lara. Kepiye carane bakal mengaruhi layanan sing manggon ing pusat data? A akèh gumantung carane Gagal bener katon.
Yen Gagal apik, iku kejiret ing tingkat automation saka BFD padha, automation seneng nempatno joints masalah lan isolasi masalah, banjur kabeh iku nggoleki. Kita duwe akeh dalan, lalu lintas langsung dialihake menyang rute alternatif, lan layanan kasebut ora bakal weruh apa-apa. Iki minangka skenario sing apik.
Skenario sing ala yaiku yen kita ngalami kerugian sing terus-terusan, lan otomatisasi ora ngerteni masalah kasebut. Kanggo ngerti carane iki mengaruhi aplikasi, kita kudu nglampahi sawetara wektu kanggo ngrembug carane protokol TCP bisa.
Muga-muga aku ora gawe kaget sapa wae kanthi informasi iki: TCP minangka protokol jabat tangan. Sing, ing kasus sing paling gampang, pangirim ngirim rong paket, lan nampa ack kumulatif: "Aku nampa rong paket."
Sawise iku, dheweke bakal ngirim rong paket maneh, lan kahanan bakal mbaleni. Aku njaluk ngapura sadurunge kanggo sawetara simplified. Skenario iki bener yen jendhela (jumlah paket ing pesawat) ana loro. Mesthine, iki ora mesthi kedadeyan ing umum. Nanging konteks penerusan paket ora kena pengaruh ukuran jendhela.
Apa sing kedadeyan yen kita kelangan paket 3? Ing kasus iki, panampa bakal nampa paket 1, 2 lan 4. Lan dheweke bakal ngandhani pangirim kanthi jelas nggunakake pilihan SACK: "Sampeyan ngerti, telu teka, nanging tengah ilang." Dheweke ngomong "Ack 2, SACK 4".
Pangirim saiki mbaleni persis paket sing ilang tanpa masalah.
Nanging yen paket pungkasan ing jendhela ilang, kahanan bakal katon beda banget.
Panampa nampa telung paket pisanan lan pisanan wiwit ngenteni. Thanks kanggo sawetara optimizations ing tumpukan TCP kernel Linux, bakal ngenteni paket dipasangake, kajaba ana pratondo eksplisit ing panji sing iki paket pungkasan utawa kaya. Bakal ngenteni nganti wektu tundha ACK kadaluwarsa banjur ngirim pangakuan kanggo telung paket pisanan. Nanging saiki pangirim bakal ngenteni. Dheweke ora ngerti yen paket kaping papat wis ilang utawa bakal teka. Lan supaya ora kakehan jaringan, iku bakal nyoba kanggo ngenteni pratondo eksplisit sing paket ilang, utawa kadaluwarsa wektu entek RTO.
Apa wektu entek RTO? Iki maksimum saka RTT diwilang dening tumpukan TCP lan sawetara pancet. Apa pancet iki, saiki kita bakal ngrembug.
Nanging sing penting yen kita apes maneh lan paket papat ilang maneh, banjur RTO pindho. Tegese, saben upaya sing ora kasil minangka tikel kaping pindho wektu entek.
Saiki ayo kang ndeleng apa basis iki padha. Kanthi gawan, RTO minimal yaiku 200ms. Iki minangka RTO minimal kanggo paket data. Kanggo paket SYN, beda, 1 detik. Nalika sampeyan bisa ndeleng, malah nyoba pisanan ngirim maneh paket bakal njupuk 100 kaping luwih saka RTT ing pusat data.
Saiki bali menyang skenario kita. Apa sing kedadeyan karo layanan kasebut? Layanan wiwit ilang paket. Ayo layanan pisanan begja lan ilang soko ing tengah jendhela, banjur nampa SACK a, resends paket ilang.
Nanging yen nasib ala mbaleni, kita duwe RTO. Apa sing penting ing kene? Ya, kita duwe akeh dalan ing jaringan. Nanging lalu lintas TCP saka siji sambungan TCP tartamtu bakal terus liwat tumpukan rusak padha. Mundhut paket, yen X11 sihir kita ora metu dhewe, ora nyebabake lalu lintas menyang wilayah sing ora ana masalah. Kita nyoba ngirim paket liwat tumpukan rusak sing padha. Iki ndadékaké kanggo Gagal runtun: pusat data pesawat saka aplikasi sesambungan, lan sawetara saka sambungan TCP kabeh aplikasi iki wiwit degrade - amarga superspin mengaruhi kabeh aplikasi sing nang DC. Kaya ing paribasan: yen ora sepatu jaran, jaran limps; jaran limped - laporan ora dikirim; pesen iki ora dikirim - padha ilang perang. Mung ing kene count dadi sawetara detik wiwit masalah kasebut kedadeyan nganti tahap degradasi sing dirasakake layanan. Iki tegese pangguna bisa uga ora nampa soko nang endi wae.
Ana rong solusi klasik sing nglengkapi saben liyane. Sing pertama yaiku layanan sing nyoba nyelehake jerami lan ngrampungake masalah kaya iki: "Ayo ngapiki soko ing tumpukan TCP. Lan ayo nggawe wektu entek tingkat aplikasi utawa sesi TCP sing umure dawa kanthi mriksa kesehatan internal. Masalahe yaiku solusi kasebut: a) ora ukurane; b) diuji banget. Yaiku, sanajan layanan kasebut ora sengaja ngatur tumpukan TCP supaya dadi luwih apik, sepisanan, iki ora bisa ditrapake kanggo kabeh aplikasi lan kabeh pusat data, lan nomer loro, paling kamungkinan, ora bakal ngerti apa sing ditindakake kanthi bener lan apa ora. Yaiku, kerjane, nanging kerjane ora apik lan ora skala. Lan yen ana masalah jaringan, sapa sing kudu disalahake? Mesthi NOC. Apa sing ditindakake NOC?
Akeh layanan sing percaya yen ing NOC, kerja kaya iki. Nanging jujur, ora mung.
NOC ing skema klasik melu pangembangan akeh pemantauan. Iki minangka pemantauan kothak ireng lan pemantauan kothak putih. Babagan conto kothak ireng-ngawasi spines Alexander Klimenko ing kepungkur Next Hop. Miturut cara, pemantauan iki bisa digunakake. Nanging malah ngawasi sampurna bakal duwe wektu tundha. Biasane sawetara menit. Sawise kerjane, insinyur sing tugas butuh wektu kanggo mriksa maneh operasi, lokalisasi masalah, lan banjur mateni wilayah masalah. Sing, ing kasus sing paling apik, perawatan saka masalah njupuk 5 menit, paling awon 20 menit, yen ora langsung ketok ngendi losses dumadi. Cetha yen kabeh wektu iki - 5 utawa 20 menit - layanan kita bakal terus lara, sing mbokmenawa ora apik.
Apa sampeyan pengin nampa? Kita duwe akeh dalan. Lan masalah muncul amarga aliran TCP sing ora beruntung terus nggunakake rute sing padha. Kita butuh soko sing ngidini kita nggunakake macem-macem rute ing siji sambungan TCP. Iku bakal katon yen kita duwe solusi. Ana TCP, sing diarani TCP multipath, yaiku, TCP kanggo akeh dalan. Bener, iki dikembangake kanggo tugas sing beda - kanggo smartphone sing duwe sawetara piranti jaringan. Kanggo nggedhekake transfer utawa nggawe mode utami / serep, mekanisme dikembangake sing transparan nggawe sawetara utas (sesi) kanggo aplikasi kasebut lan ngidini sampeyan ngalih ing antarane yen gagal. Utawa, kaya sing dakkandhakake, maksimalake bandwidth.
Nanging ana nuansa ing kene. Kanggo ngerti apa iku, kita kudu ndeleng carane stream diatur.
Utas disetel kanthi urutan. Stream pisanan diinstal pisanan. Alur sakteruse banjur disetel nggunakake cookie sing wis disepakati ing thread kasebut. Lan ing kene masalahe.
Masalahe yaiku yen utas pisanan ora dipasang, utas kapindho lan katelu ora bakal muncul. Sing, multipath TCP ora ngatasi mundhut saka paket SYN ing stream pisanan. Lan yen SYN ilang, multipath TCP dadi TCP normal. Dadi, ing lingkungan pusat data, ora bakal mbantu ngatasi masalah kerugian ing pabrik lan sinau carane nggunakake macem-macem dalan yen gagal.
Apa sing bisa mbantu kita? Sawetara sampeyan wis ngira saka jeneng yen kolom header label aliran IPv6 bakal dadi lapangan penting ing crita kita. Pancen, iki lapangan sing katon ing v6, iku ora ing v4, iku njupuk 20 bit, lan ana kontrovèrsi babagan nggunakake kanggo dangu. Iki menarik banget - ana perselisihan, ana sing didandani ing kerangka RFC, lan ing wektu sing padha, implementasine muncul ing kernel Linux sing ora tau didokumentasikake ing ngendi wae.
Aku saranake sampeyan melu aku ing investigasi sethitik. Ayo goleki apa sing kedadeyan ing kernel Linux sajrone sawetara taun kepungkur.
taun 2014. Insinyur saka perusahaan gedhe lan biso dipercoyo nambahake fungsi kernel Linux gumantung saka nilai label aliran ing hash soket. Apa sing padha nyoba kanggo ndandani kene? Iki ana hubungane karo RFC 6438 sing ngrembug masalah ing ngisor iki. Ing tengah data, IPv4 asring encapsulated ing paket IPv6, amarga pabrik dhewe IPv6, nanging IPv4 kudu piye wae diwenehi metu. Kanggo dangu ana masalah karo ngalih sing ora bisa katon ing rong header IP kanggo njaluk menyang TCP utawa UDP lan golek src_ports, dst_ports ana. Ternyata hash kasebut, yen sampeyan ndeleng rong header IP pisanan, dadi meh tetep. Kanggo ngindhari iki, supaya imbangan lalu lintas encapsulated iki bisa digunakake kanthi bener, diusulake kanggo nambah hash saka paket encapsulated 5-tuple kanggo nilai kolom label aliran. Kira-kira padha rampung kanggo rencana enkapsulasi liyane, kanggo UDP, kanggo GRE, ing lapangan GRE Key digunakake. Siji cara utawa liyane, gol ing kene wis jelas. Lan paling ora ing wektu iku padha migunani.
Ing 2015, tembelan anyar teka saka insinyur sing dihormati sing padha. Dheweke menarik banget. Iku ngandika ing ngisor iki - kita bakal randomize hash ing cilik saka acara nuntun negatif. Apa acara routing negatif? Iki RTO sing kita rembugan sadurunge, yaiku, mundhut buntut jendhela minangka acara sing pancen negatif. Bener, iku relatif angel kanggo guess apa iku.
2016, perusahaan liyane sing dihormati, uga gedhe. Iku parses crutches pungkasan lan nggawe supaya hash sing sadurunge digawe acak saiki diganti ing saben SYN retransmit lan sawise saben RTO wektu entek. Lan ing layang iki, kanggo pisanan lan pungkasan, goal pokok muni - kanggo mesthekake yen lalu lintas ing acara mundhut utawa kakehan saluran duwe kamungkinan saka rerouting alus, nggunakake sawetara dalan. Mesthine, sawise ana akeh publikasi, sampeyan bisa nemokake kanthi gampang.
Sanajan ora, sampeyan ora bisa, amarga durung ana publikasi siji ing topik iki. Nanging kita ngerti!
Lan yen sampeyan ora ngerti apa sing wis rampung, aku bakal ngandhani sampeyan saiki.
Apa sing wis rampung, fungsi apa sing wis ditambahake menyang kernel Linux? txhash owah-owahan menyang Nilai acak sawise saben acara RTO. Iki minangka asil nuntun negatif sing padha. Hash gumantung ing txhash iki lan label aliran gumantung ing hash skb. Ana sawetara petungan ing fungsi kene, kabeh rincian ora bisa diselehake ing siji geser. Yen ana sing kepengin weruh, sampeyan bisa mbukak kode kernel lan mriksa.
Apa sing penting ing kene? Nilai kolom label aliran diganti nomer acak sawise saben RTO. Kepiye carane iki mengaruhi aliran TCP sing ora beruntung?
Ing kasus SACK, ora ana sing diganti amarga kita nyoba ngirim maneh paket sing ilang. Nganti saiki apik.
Nanging ing kasus RTO, kasedhiya yen kita wis nambah label aliran kanggo fungsi hash ing ToR, lalu lintas bisa njupuk rute beda. Lan luwih akeh pesawat, luwih akeh nemokake dalan sing ora kena kacilakan ing piranti tartamtu.
Siji masalah tetep - RTO. Rute liyane, mesthi, ditemokake, nanging akeh wektu sing ditindakake. 200ms iku akeh. Kapindho umume wildness. Sadurunge, aku ngomong babagan wektu entek sing ngatur layanan. Dadi, detik minangka wektu entek sing biasane nyiyapake layanan ing tingkat aplikasi, lan ing layanan iki malah bakal bener. Menapa malih, Aku mbaleni, RTT nyata nang pusat data modern watara 1 millisecond.
Apa sing bisa ditindakake babagan wektu entek RTO? Wektu entek sing tanggung jawab kanggo RTO ing kasus mundhut paket data bisa relatif gampang diatur saka papan pangguna: ana sarana IP, lan salah siji saka paramèter ngandhut rto_min padha. Ngelingi, mesthine, sampeyan kudu ngowahi RTO ora sacara global, nanging kanggo prefiks sing diwenehake, mekanisme kasebut katon apik.
Bener, karo SYN_RTO kabeh luwih elek. Iku alami dipaku mudhun. Nilai tetep ing inti - 1 detik, lan sing. Sampeyan ora bisa nggayuh saka papan pangguna. Mung ana siji cara.
eBPF teka kanggo ngluwari. Kanggo nggawe prasaja, iki program C cilik. Padha bisa dilebokake menyang pancingan ing macem-macem panggonan ing eksekusi tumpukan kernel lan tumpukan TCP, karo kang sampeyan bisa ngganti nomer akeh banget setelan. Umumé, eBPF minangka tren jangka panjang. Tinimbang sawing Welasan paramèter sysctl anyar lan ngembangaken sarana IP, gerakan ing arah eBPF lan ngembangaken fungsi. Kanthi eBPF, sampeyan bisa ngganti kontrol kemacetan lan macem-macem setelan TCP liyane.
Nanging penting kanggo kita yen kanthi bantuan sampeyan bisa ngowahi nilai SYN_RTO. Lan ana conto sing dikirim umum: . Apa sing ditindakake ing kene? Conto iku bisa digunakake, nanging ing dhewe banget kasar. Dianggep ing kene yen ing tengah data kita mbandhingake 44 bit pisanan, yen padha cocog, mula kita temokake ing DC. Lan ing kasus iki, kita ngganti nilai wektu entek SYN_RTO dadi 4ms. Tugas sing padha bisa ditindakake kanthi luwih apik. Nanging conto prasaja iki nuduhake apa a) bisa; b) relatif gampang.
Apa kita wis ngerti? Yen arsitektur planar ngidini skala, ternyata migunani banget kanggo kita nalika nguripake label aliran ing ToR lan entuk kesempatan kanggo mili ing wilayah masalah. Cara paling apik kanggo ngedhunake nilai RTO lan SYN-RTO yaiku nggunakake program eBPF. Pitakonan tetep: apa aman nggunakake label aliran kanggo imbangan? Lan ana nuansa ing kene.
Upaminipun sampeyan duwe layanan ing jaringan sing manggon ing anycast. Sayange, aku ora duwe wektu kanggo njlentrehake babagan anycast, nanging iki minangka layanan sing disebarake ing ngendi server fisik beda kasedhiya ing alamat IP sing padha. Lan ing kene ana masalah: acara RTO bisa kedadeyan ora mung nalika lalu lintas liwat pabrik. Uga bisa kedadeyan ing tingkat buffer ToR: nalika ana acara incast, bisa uga kedadeyan ing host nalika tuan rumah mbuwang soko. Nalika kedadeyan RTO lan ngganti label aliran. Ing kasus iki, lalu lintas bisa pindhah menyang conto anycast liyane. Upaminipun punika anycast stateful, ngandhut negara sambungan - bisa dadi L3 Balancer utawa sawetara layanan liyane. Banjur ana masalah, amarga sawise RTO, sambungan TCP teka ing server, sing ora ngerti apa-apa babagan sambungan TCP iki. Lan yen kita ora duwe enggo bareng negara ing antarane server anycast, lalu lintas kasebut bakal mandheg lan sambungan TCP bakal rusak.
Apa sing bisa ditindakake ing kene? Ing lingkungan sing dikontrol, ing ngendi sampeyan ngaktifake keseimbangan label aliran, sampeyan kudu ndandani nilai label aliran nalika ngakses server anycast. Cara paling gampang yaiku liwat program eBPF sing padha. Nanging iki minangka titik sing penting banget - apa sing kudu ditindakake yen sampeyan ora ngoperasikake jaringan pusat data, nanging minangka operator telekomunikasi? Iki masalah sampeyan uga: miwiti karo versi tartamtu saka Juniper lan Arista, padha kalebu label aliran ing fungsi hash minangka standar - jujur, kanggo alesan aku ora ngerti. Iki bisa nyebabake sampeyan ngeculake sambungan TCP saka pangguna liwat jaringan sampeyan. Mulane, aku banget nyaranake mriksa setelan router ing lokasi iki.
Salah siji cara utawa liyane, misale jek kula wis siyap kanggo nerusake kanggo nyobi.
Nalika kita nguripake label aliran ing ToR, disiapake eBPF agen, kang saiki manggon ing sarwa dumadi, kita mutusaké ora kanggo ngenteni Gagal amba sabanjuré, nanging kanggo nindakake bledosan kontrol. We njupuk ToR, kang wis papat uplinks, lan digawe irungnya ing salah siji saka wong-wong mau. Dheweke nggawe aturan, ujare - saiki sampeyan kelangan kabeh paket. Kaya sing sampeyan ngerteni ing sisih kiwa, ana pemantauan saben paket, sing dicelupake nganti 75%, yaiku 25% paket ilang. Ing sisih tengen ana grafik layanan sing manggon ing mburi ToR iki. Nyatane, iki minangka grafik lalu lintas sambungan karo server ing rak. Nalika sampeyan bisa ndeleng, padha klelep malah ngisor. Yagene padha klelep luwih murah - ora 25%, nanging ing sawetara kasus kaping 3-4? Yen sambungan TCP apes, terus nyoba kanggo nggayuh liwat antarmuka rusak. Iki diperparah dening prilaku khas layanan ing DC - kanggo siji panjalukan pangguna, N panjalukan kanggo layanan internal kui, lan respon bakal pindhah menyang pangguna, salah siji nalika kabeh sumber data nanggapi, utawa nalika wektu entek micu ing. tingkat aplikasi, sing isih kudu dikonfigurasi. Sing, kabeh iku banget, banget ala.
Saiki eksperimen sing padha, nanging kanthi label aliran diaktifake. Kaya sing sampeyan ngerteni, ing sisih kiwa, pemantauan batch kita mudhun kanthi 25%. Iki pancen bener, amarga ora ngerti apa-apa babagan retransmits, ngirim paket lan mung ngitung rasio jumlah paket sing dikirim lan ilang.
Lan ing sisih tengen ana jadwal layanan. Sampeyan ora bakal nemokake efek saka gabungan masalah ing kene. Lalu lintas ing milidetik sing padha mili saka area masalah menyang telung uplink sing isih ana sing ora kena pengaruh masalah kasebut. Kita entuk jaringan sing nambani dhewe.
Iki slide pungkasan, wektu kanggo njupuk saham. Saiki, muga-muga sampeyan ngerti carane mbangun jaringan pusat data marasake awak dhewe. Sampeyan ora perlu mbukak arsip kernel Linux lan goleki patch khusus ing kana, sampeyan ngerti manawa label Flow ngatasi masalah kasebut, nanging sampeyan kudu nyedhaki mekanisme iki kanthi teliti. Lan aku nandheske maneh yen sampeyan dadi operator, sampeyan ora kudu nggunakake label aliran minangka fungsi hash, yen ora, sampeyan bakal ngrusak sesi pangguna.
Kanggo insinyur jaringan, owah-owahan konseptual kudu ditindakake: jaringan ora diwiwiti karo ToR, ora karo piranti jaringan, nanging karo host. Conto sing cukup nyenengake yaiku carane nggunakake eBPF kanggo ngganti RTO lan ndandani label aliran menyang layanan anycast.
Mekanik label aliran mesthi cocog kanggo panggunaan liyane ing bagean administratif sing dikontrol. Iki bisa dadi lalu lintas antarane pusat data, utawa sampeyan bisa nggunakake mekanika kasebut kanthi cara khusus kanggo ngontrol lalu lintas metu. Nanging aku bakal ngomong babagan iki, muga-muga, sabanjure. Maturnuwun sanget atas perhatiannya.
Source: www.habr.com