Kita wis ngembangake desain jaringan pusat data sing ngidini panyebaran kluster komputasi luwih gedhe tinimbang 100 ewu server kanthi bandwidth bisection puncak luwih saka siji petabyte per detik.
Saka laporan Dmitry Afanasyev, sampeyan bakal sinau babagan prinsip dhasar desain anyar, topologi skala, masalah sing muncul, pilihan kanggo ngrampungake, fitur rute lan skala fungsi pesawat maju piranti jaringan modern ing "sambungan padhet" topologi karo nomer akeh rute ECMP. Kajaba iku, Dima sedhela ngandika bab organisasi panyambungan external, lapisan fisik, sistem kabel lan cara kanggo nambah kapasitas.
- Sugeng sonten sedaya! Jenengku Dmitry Afanasyev, aku dadi arsitek jaringan ing Yandex lan utamane ngrancang jaringan pusat data.
Kisahku bakal babagan jaringan pusat data Yandex sing dianyari. Iku banget évolusi saka desain kita wis, nanging ing wektu sing padha ana sawetara unsur anyar. Iki minangka presentasi ringkesan amarga ana akeh informasi sing kudu dikemas ing wektu sing sithik. Kita bakal miwiti kanthi milih topologi logis. Banjur bakal ana ringkesan pesawat kontrol lan masalah karo skalabilitas bidang data, pilihan saka apa sing bakal kelakon ing tingkat fisik, lan kita bakal katon ing sawetara fitur saka piranti. Ayo ndemek sethithik babagan apa sing kedadeyan ing pusat data karo MPLS, sing wis dirembug sawetara wektu kepungkur.
Dadi, apa Yandex babagan muatan lan layanan? Yandex minangka hyperscaler khas. Yen kita ndeleng pangguna, kita utamane ngolah panjaluk pangguna. Uga macem-macem layanan streaming lan transfer data, amarga kita uga duwe layanan panyimpenan. Yen luwih cedhak karo backend, banjur prasarana lan layanan katon ing kono, kayata panyimpenan obyek sing disebarake, replikasi data lan, mesthi, antrian sing terus-terusan. Salah sawijining jinis beban kerja utama yaiku MapReduce lan sistem sing padha, pamrosesan stream, sinau mesin, lsp.
Kepiye infrastruktur ing ndhuwur sing kabeh iki kedadeyan? Maneh, kita minangka hyperscaler sing khas, sanajan kita bisa uga luwih cedhak karo sisih hyperscaler sing luwih cilik saka spektrum. Nanging kita duwe kabeh atribut. Kita nggunakake hardware komoditas lan skala horisontal yen bisa. We kudu pooling sumber lengkap: kita ora bisa karo mesin individu, rak individu, nanging gabungke menyang blumbang gedhe sumber daya diijolke karo sawetara layanan tambahan sing menehi hasil karo planning lan alokasi, lan bisa karo kabeh blumbang iki.
Dadi kita duwe tingkat sabanjure - sistem operasi ing tingkat kluster komputasi. Penting banget kanggo ngontrol tumpukan teknologi sing digunakake. Kita ngontrol titik pungkasan (host), jaringan lan tumpukan piranti lunak.
Kita duwe sawetara pusat data gedhe ing Rusia lan luar negeri. Padha digabungake dening backbone sing nggunakake teknologi MPLS. Infrastruktur internal kita meh kabeh dibangun ing IPv6, nanging amarga kita kudu ngladeni lalu lintas eksternal sing isih ana utamane liwat IPv4, kita kudu ngirim panjaluk liwat IPv4 menyang server frontend, lan luwih sithik menyang IPv4 eksternal - Internet - kanggo contone, kanggo indeksasi.
Sawetara iterasi pungkasan saka desain jaringan pusat data wis nggunakake topologi Clos multi-lapisan lan mung L3. Kita ninggalake L2 sawetara wektu kepungkur lan ambegan lega. Pungkasan, infrastruktur kita kalebu atusan ewu conto komputasi (server). Ukuran kluster maksimal sawetara wektu kepungkur kira-kira 10 ewu server. Iki umume amarga kepiye sistem operasi tingkat kluster sing padha, penjadwal, alokasi sumber daya, lan liya-liyane. Kita duwe tugas - bisa mbangun pabrik jaringan sing ngidini pooling sumber daya efisien ing kluster kuwi.
Apa sing dikarepake saka jaringan pusat data? Kaping pisanan, ana akeh bandwidth sing murah lan disebarake kanthi seragam. Amarga jaringan minangka tulang punggung sing bisa kita kumpulake sumber daya. Ukuran target anyar kira-kira 100 ewu server ing siji kluster.
Kita uga, mesthi, pengin pesawat kontrol keukur lan stabil, amarga ing infrastruktur gedhe kuwi akeh ngelu njedhul malah saka acara mung acak, lan kita ora pengin pesawat kontrol kanggo nggawa kita ngelu uga. Ing wektu sing padha, kita pengin nyilikake negara kasebut. Kondhisi sing luwih cilik, luwih apik lan luwih stabil kabeh bisa digunakake, lan luwih gampang diagnosa.
Mesthi wae, kita butuh otomatisasi, amarga ora bisa ngatur infrastruktur kasebut kanthi manual, lan ora mungkin kanggo sawetara wektu. Kita butuh dhukungan operasional sabisa-bisa lan dhukungan CI / CD nganti bisa diwenehake.
Kanthi ukuran pusat data lan kluster kasebut, tugas ndhukung penyebaran lan ekspansi tambahan tanpa gangguan layanan wis dadi akut. Yen ing kluster ukuran sewu mesin, bisa uga meh sepuluh ewu mesin, isih bisa diluncurake minangka siji operasi - yaiku, kita ngrancang ekspansi infrastruktur, lan sawetara ewu mesin ditambahake minangka siji operasi. banjur kluster ukuran satus ewu mesin ora langsung muncul kaya iki, dibangun liwat sawetara wektu. Lan sing dikarepake kabeh wektu iki sing wis dipompa, infrastruktur sing wis dipasang, kudu kasedhiya.
Lan siji syarat sing kita duwe lan ninggalake: dhukungan kanggo multitenancy, yaiku, virtualisasi utawa segmentasi jaringan. Saiki kita ora perlu nindakake iki ing tingkat kain jaringan, amarga sharding wis musna kanggo sarwa dumadi, lan iki wis digawe njongko gampang banget kanggo kita. Thanks kanggo IPv6 lan papan alamat sing gedhe, kita ora perlu nggunakake alamat duplikat ing infrastruktur internal; kabeh alamat wis unik. Lan thanks kanggo kasunyatan sing wis njupuk nyaring lan segmentasi jaringan kanggo sarwa dumadi, kita ora perlu nggawe entitas jaringan virtual ing jaringan pusat data.
Sing penting banget yaiku apa sing ora kita butuhake. Yen sawetara fungsi bisa dibusak saka jaringan, iki ndadekake urip luwih gampang, lan, minangka aturan, ngembangaken pilihan saka peralatan lan piranti lunak sing kasedhiya, nggawe diagnostik banget prasaja.
Dadi, apa sing ora kita butuhake, apa sing bisa kita pasrahake, ora tansah kanthi bungah nalika kedadeyan kasebut, nanging kanthi rasa lega nalika proses rampung?
Kaping pisanan, ninggalake L2. Kita ora butuh L2, ora nyata utawa ditiru. Ora digunakake umume amarga kita ngontrol tumpukan aplikasi. Aplikasi kita bisa diukur kanthi horisontal, bisa digunakake karo alamat L3, ora kuwatir yen sawetara conto individu wis metu, mung muter sing anyar, ora perlu diluncurake ing alamat lawas, amarga ana tingkat kapisah saka panemuan layanan lan ngawasi mesin dumunung ing kluster. Kita ora utusan tugas iki menyang jaringan. Tugas jaringan yaiku ngirim paket saka titik A menyang titik B.
Kita uga ora duwe kahanan ing ngendi alamat pindhah ing jaringan, lan iki kudu dipantau. Ing akeh desain iki biasane dibutuhake kanggo ndhukung mobilitas VM. Kita ora nggunakake mobilitas mesin virtual ing infrastruktur internal Yandex gedhe, lan, luwih-luwih, kita percaya yen sanajan iki wis rampung, mesthine ora kedadeyan kanthi dhukungan jaringan. Yen pancene kudu rampung, iku kudu rampung ing tingkat inang, lan push alamat sing bisa migrasi menyang overlays, supaya ora ndemek utawa nggawe akeh banget owah-owahan dinamis kanggo sistem nuntun saka underlay dhewe (jaringan transportasi). .
Teknologi liyane sing ora digunakake yaiku multicast. Yen sampeyan pengin, aku bisa ngomong kanthi rinci apa sebabe. Iki nggawe urip luwih gampang, amarga yen ana wong sing wis ditangani lan ndeleng persis kaya apa pesawat kontrol multicast, ing kabeh instalasi sing paling gampang, iki mumet. Lan apa maneh, angel golek implementasine open source sing apik, contone.
Pungkasan, kita ngrancang jaringan supaya ora owah banget. Kita bisa Count ing kasunyatan sing aliran acara external ing sistem nuntun cilik.
Masalah apa sing muncul lan watesan apa sing kudu digatekake nalika ngembangake jaringan pusat data? Biaya, mesthi. Skalabilitas, tingkat sing kita pengin tuwuh. Perlu nggedhekake tanpa mandheg layanan. Bandwidth, kasedhiyan. Visibilitas apa sing kedadeyan ing jaringan kanggo sistem ngawasi, kanggo tim operasional. Dhukungan otomatisasi - maneh, sabisa, amarga tugas sing beda bisa ditanggulangi ing tingkat sing beda, kalebu introduksi lapisan tambahan. Ya, ora [mungkin] gumantung marang vendor. Senajan ing periode sajarah beda, gumantung ing bagean sing katon ing, kamardikan iki luwih gampang utawa luwih angel kanggo entuk. Yen kita njupuk salib-bagean saka Kripik piranti jaringan, banjur nganti bubar iku banget kondisional kanggo pirembagan bab kamardikan saka vendor, yen kita uga wanted Kripik karo throughput dhuwur.
Apa topologi logis sing bakal digunakake kanggo mbangun jaringan? Iki bakal dadi Clos multi-level. Nyatane, ora ana alternatif nyata saiki. Lan topologi Clos cukup apik, sanajan dibandhingake karo macem-macem topologi canggih sing luwih akeh ing area kapentingan akademik saiki, yen kita duwe switch radix gedhe.
Kepiye carane jaringan Clos multi-level kira-kira terstruktur lan apa unsur sing beda-beda diarani? Kaping pisanan, angin munggah, kanggo ngarahake dhewe menyang ngendi lor, ngendi sisih kidul, ngendi wetan, ngendi kulon. Jaringan jinis iki biasane dibangun dening wong-wong sing duwe lalu lintas kulon-wétan sing gedhé banget. Kanggo unsur sing isih ana, ing sisih ndhuwur ana saklar virtual sing dipasang saka saklar sing luwih cilik. Iki minangka ide utama konstruksi rekursif jaringan Clos. We njupuk unsur karo sawetara jenis radix lan nyambungake supaya apa kita njaluk bisa dianggep minangka saklar karo radix luwih gedhe. Yen sampeyan mbutuhake luwih akeh, prosedur kasebut bisa diulang maneh.
Ing kasus, contone, karo Clos loro-tingkat, nalika iku bisa kanggo cetha ngenali komponen sing vertikal ing diagram sandi, padha biasane disebut pesawat. Yen kita arep mbangun Clos kanthi telung tingkat spine switch (kabeh ora wates utawa switch ToR lan mung digunakake kanggo transit), banjur pesawat bakal katon luwih rumit; loro-tingkat katon persis kaya iki. Kita nyebat blok ToR utawa saklar rwaning lan saklar spine tingkat pertama sing ana gandhengane karo Pod. Spine switch tingkat spine-1 ing ndhuwur Pod yaiku ndhuwur Pod, ndhuwur Pod. Saklar sing ana ing ndhuwur kabeh pabrik yaiku lapisan ndhuwur pabrik, Ndhuwur kain.
Mesthi wae, pitakonan muncul: Jaringan Clos wis dibangun kanggo sawetara wektu; ide kasebut umume asale saka jaman telephony klasik, jaringan TDM. Mungkin ana sing luwih apik wis muncul, bisa uga ana sing luwih apik? Ya lan ora. Secara teoritis, ing praktik ing mangsa ngarep mesthi ora. Amarga ana sawetara topologi menarik, sawetara wong malah digunakake ing produksi, contone, Dragonfly digunakake ing aplikasi HPC; Ana uga topologi sing menarik kayata Xpander, FatClique, Jellyfish. Yen sampeyan ndeleng laporan ing konferensi kaya SIGCOMM utawa NSDI bubar, sampeyan bisa nemokake akeh karya ing topologi alternatif sing nduweni sifat sing luwih apik (siji utawa liyane) tinimbang Clos.
Nanging kabeh topologi kasebut duwe siji properti sing menarik. Iku ngalangi implementasine ing jaringan pusat data, kang kita nyoba kanggo mbangun ing hardware komoditas lan biaya dhuwit cukup cukup. Ing kabeh topologi alternatif iki, akeh bandwidth sayangé ora bisa diakses liwat jalur paling cendhak. Mulane, kita langsung kelangan kesempatan kanggo nggunakake pesawat kontrol tradisional.
Secara teoritis, solusi kanggo masalah kasebut dikenal. Iki, contone, modifikasi link negara nggunakake k-path paling cendhek, nanging, maneh, ora ana protokol kuwi sing bakal dipun ginakaken ing produksi lan kasedhiya ing peralatan.
Menapa malih, wiwit paling saka kapasitas ora bisa diakses liwat dalan paling cendhak, kita kudu ngowahi luwih saka mung bidang kontrol kanggo milih kabeh dalan sing (lan dening cara, iki Ngartekno luwih negara ing bidang kontrol). Kita isih kudu ngowahi bidang sing diterusake, lan, minangka aturan, paling ora rong fitur tambahan dibutuhake. Iki minangka kemampuan kanggo nggawe kabeh keputusan babagan ngirim paket siji-wektu, contone, ing host. Nyatane, iki minangka rute sumber, kadhangkala ing literatur babagan jaringan interkoneksi iki diarani kaputusan maju kabeh. Lan nuntun adaptif punika fungsi sing kita kudu ing unsur jaringan, kang boils mudhun, contone, kanggo kasunyatan sing kita pilih hop sabanjuré adhedhasar informasi bab mbukak paling ing antrian. Minangka conto, opsi liyane bisa.
Mangkono, arah kasebut menarik, nanging, sayang, kita ora bisa ngetrapake saiki.
Oke, kita mutusake babagan topologi logika Clos. Kepiye carane kita bakal ngukur? Ayo ndeleng cara kerjane lan apa sing bisa ditindakake.
Ing jaringan Clos ana rong paramèter utama sing bisa beda-beda lan entuk asil tartamtu: radix unsur lan jumlah level ing jaringan. Aku duwe diagram skematis carane loro mengaruhi ukuran. Saenipun, kita gabungke loro.
Sampeyan bisa ndeleng sing jembaré final saka jaringan Clos produk kabeh tingkat saka spine ngalih saka radix kidul, carane akeh pranala kita kudu mudhun, carane cabang. Iki carane kita ngukur ukuran jaringan.
Babagan kapasitas, utamane ing switch ToR, ana rong pilihan skala. Salah siji kita bisa, nalika njaga topologi umum, nggunakake pranala luwih cepet, utawa kita bisa nambah pesawat liyane.
Yen sampeyan ndeleng versi jaringan Clos sing ditambahi (ing pojok tengen ngisor) lan bali menyang gambar iki nganggo jaringan Clos ing ngisor iki ...
... banjur iki topologi persis padha, nanging ing slide iki ambruk luwih kompak lan pesawat saka pabrik sing superimposed ing saben liyane. Iku padha.
Apa tampilan jaringan Clos ing angka? Kene aku nyedhiyani data apa jembaré maksimum jaringan bisa dipikolehi, apa jumlah maksimum rak, ngalih ToR utawa ngalih rwaning, yen lagi ora ing rak, kita bisa njaluk gumantung apa radix saka ngalih digunakake kanggo utomo -levels, lan carane akeh tingkat kita nggunakake.
Punika carane akeh rak kita bisa duwe, carane akeh server lan kira-kira pinten kabeh iki bisa nganggo adhedhasar 20 kW saben rak. A little sadurungé aku sebutno sing kita ngarahake ukuran kluster babagan 100 ewu server.
Bisa dideleng manawa ing kabeh desain iki, rong lan setengah opsi dadi kapentingan. Ana pilihan karo rong lapisan saka spines lan 64-port ngalih, kang tiba sethitik cendhak. Banjur ana pilihan sampurna pas kanggo 128-port (karo radix 128) spine ngalih karo loro tingkat, utawa ngalih karo radix 32 karo telung tingkat. Lan ing kabeh kasus, ngendi ana liyane radixes lan lapisan liyane, sampeyan bisa nggawe jaringan gedhe banget, nanging yen katon ing konsumsi samesthine, biasane ana gigawatts. Sampeyan bisa kanggo lay kabel, nanging kita ora kamungkinan kanggo njaluk sing akeh listrik ing siji situs. Yen sampeyan ndeleng statistik lan data umum ing pusat data, sampeyan bisa nemokake sawetara pusat data kanthi kira-kira kapasitas luwih saka 150 MW. Sing luwih gedhe biasane kampus pusat data, sawetara pusat data gedhe sing dumunung cukup cedhak.
Ana parameter penting liyane. Yen sampeyan ndeleng kolom kiwa, bandwidth sing bisa digunakake ana ing kana. Iku gampang kanggo ndeleng sing ing jaringan Clos bagean pinunjul saka bandar digunakake kanggo nyambung ngalih kanggo saben liyane. Bandwidth sing bisa digunakake, jalur sing migunani, yaiku sing bisa diwenehake ing njaba, menyang server. Alamiah, aku ngomong babagan port kondisional lan khusus babagan band. Minangka aturan, pranala ing jaringan luwih cepet tinimbang pranala menyang server, nanging saben unit bandwidth, kaya sing bisa dikirim menyang peralatan server, isih ana sawetara bandwidth ing jaringan kasebut. Lan luwih akeh tingkat sing ditindakake, luwih akeh biaya khusus kanggo nyedhiyakake belang iki ing njaba.
Menapa malih, malah band tambahan iki ora persis padha. Nalika span cendhak, kita bisa nggunakake kaya DAC (langsung masang tembaga, yaiku, kabel twinax), utawa optik multimode, sing biaya dhuwit luwih utawa kurang cukup. Sanalika kita pindhah menyang jengkal maneh - minangka aturan, iki optik mode siji, lan biaya bandwidth tambahan iki mundhak noticeably.
Lan maneh, bali menyang geser sadurunge, yen kita nggawe jaringan Clos tanpa oversubscription, iku gampang kanggo ndeleng diagram, ndeleng carane jaringan dibangun - nambah saben tingkat saka spine switch, kita mbaleni kabeh Strip sing ana ing ngisor. Plus tingkat - plus band padha, padha nomer bandar ing ngalih minangka ana ing tingkat sadurungé, lan nomer padha transceiver. Mulane, iku Highly seng di pengeni kanggo nyilikake jumlah tingkat saka spine ngalih.
Adhedhasar gambar iki, jelas yen kita pancene pengin mbangun kaya switch kanthi radix 128.
Ing kene, ing prinsip, kabeh padha karo sing dakkandhakake; iki minangka slide kanggo dipikirake mengko.
Apa pilihan sing bisa kita pilih minangka switch kasebut? Kabar sing nyenengake kanggo kita saiki jaringan kasebut pungkasane bisa dibangun ing saklar siji-chip. Lan iki apik banget, dheweke duwe akeh fitur sing apik. Contone, meh ora ana struktur internal. Iki tegese padha break luwih gampang. Padha break ing kabeh limo cara, nanging begja padha break rampung. Ing piranti modular ana akeh kesalahan (banget ora nyenengake), nalika saka sudut pandang tetangga lan pesawat kontrol katon bisa digunakake, nanging, contone, bagean saka kain wis ilang lan ora bisa digunakake. ing kapasitas lengkap. Lan lalu lintas menyang iku imbang adhedhasar kasunyatan sing kebak fungsi, lan kita bisa njaluk overloaded.
Utawa, umpamane, ana masalah karo backplane, amarga ing piranti modular uga ana SerDes kanthi kacepetan dhuwur - pancen kompleks ing njero. Salah siji pratandha ing antarane unsur sing diterusake diselarasake utawa ora disinkronake. Umumé, piranti modular sing produktif sing dumadi saka pirang-pirang unsur, minangka aturan, ngemot jaringan Clos sing padha ing njero, nanging angel banget kanggo diagnosa. Asring angel malah vendor dhewe kanggo diagnosa.
Lan wis nomer akeh skenario Gagal kang piranti degrades, nanging ora tiba metu saka topologi rampung. Amarga jaringan kita gedhe, imbangan antarane unsur sing padha digunakake kanthi aktif, jaringan kasebut reguler banget, yaiku, siji dalan sing kabeh ana ing urutan ora beda karo dalan liyane, luwih nguntungake yen kita mung ilang sawetara piranti saka topologi saka kanggo mungkasi munggah ing kahanan sing sawetara wong koyone bisa, nanging sawetara wong ora.
Fitur apik sabanjure piranti siji-chip yaiku berkembang luwih apik lan luwih cepet. Dheweke uga cenderung duwe kapasitas sing luwih apik. Yen kita njupuk struktur nglumpuk gedhe sing kita duwe ing bunder, kapasitas saben unit rak kanggo bandar kacepetan padha meh kaping pindho minangka apik saka piranti modul. Piranti sing dibangun ing saubengé chip siji luwih murah tinimbang sing modular lan kurang energi.
Nanging, mesthine, kabeh iki ana alesan, uga ana kekurangan. Kaping pisanan, radix meh luwih cilik tinimbang piranti modular. Yen kita bisa njaluk piranti dibangun watara siji chip karo 128 bandar, banjur kita bisa njaluk siji modular karo sawetara atus bandar saiki tanpa masalah.
Iki minangka ukuran tabel sing luwih cilik lan, minangka aturan, kabeh sing ana gandhengane karo skalabilitas bidang data. Buffer cethek. Lan, minangka aturan, fungsi sing rada winates. Nanging ternyata yen sampeyan ngerti watesan kasebut lan ngati-ati ing wektu kanggo nyingkirake utawa mung nganggep, mula iki ora medeni. Kasunyatan manawa radix luwih cilik ora dadi masalah ing piranti kanthi radix 128 sing pungkasane muncul; kita bisa mbangun rong lapisan spines. Nanging isih ora bisa mbangun apa wae sing luwih cilik tinimbang loro sing menarik kanggo kita. Kanthi tingkat siji, kluster cilik banget dipikolehi. Malah desain lan syarat sadurunge isih ngluwihi.
Nyatane, yen dumadakan solusi kasebut ana ing pinggir, isih ana cara kanggo skala. Wiwit pungkasan (utawa pisanan), tingkat paling ing ngendi server disambungake iku ToR ngalih utawa rwaning ngalih, kita ora perlu kanggo nyambungake siji rak kanggo wong-wong mau. Mulane, yen solusi kurang setengah, sampeyan bisa mikir mung nggunakake saklar karo radix gedhe ing tingkat ngisor lan nyambungake, contone, loro utawa telung rak menyang siji ngalih. Iki uga pilihan, wis biaya, nanging kerjane cukup apik lan bisa dadi solusi apik nalika sampeyan kudu tekan kaping pindho ukuran.
Kanggo ngringkes, kita mbangun topologi kanthi rong tingkat spines, kanthi wolung lapisan pabrik.
Apa sing bakal kelakon ing fisika? petungan banget prasaja. Yen kita duwe rong tingkat spines, kita mung duwe telung tingkat switch, lan kita ngarepake bakal ana telung segmen kabel ing jaringan: saka server menyang switch rwaning, spine 1, spine 2. Opsi sing bisa ditindakake. nggunakake are - iki twinax, multimode, single mode. Lan kene kita kudu nimbang apa Strip kasedhiya, pinten biaya, apa dimensi fisik, apa jengkal kita bisa nutupi, lan carane kita bakal nganyarke.
Ing babagan biaya, kabeh bisa diatur. Twinaxes Ngartekno luwih murah tinimbang optik aktif, luwih murah tinimbang transceiver multimode, yen sampeyan njupuk saben pesawat saka mburi, Luwih murah tinimbang port switch 100 gigabit. Lan, elinga, biaya kurang saka optik mode siji, amarga ing penerbangan ing ngendi mode siji dibutuhake, ing pusat data kanggo sawetara alasan iku ndadekake pangertèn kanggo nggunakake CWDM, nalika mode siji paralel (PSM) ora trep banget kanggo bisa. karo, ngemas gedhe banget dijupuk serat, lan yen kita fokus ing teknologi iki, kita njaluk kira-kira hirarki rega ing ngisor iki.
Cathetan liyane: sayangé, ora bisa nggunakake port multimode 100 nganti 4x25 sing disassembled. Amarga fitur desain transceiver SFP28, ora luwih murah tinimbang 28 Gbit QSFP100. Lan disassembly iki kanggo multimode ora bisa digunakake banget.
Watesan liyane yaiku amarga ukuran kluster komputasi lan jumlah server, pusat data kita dadi gedhe. Iki tegese paling ora siji pesawat kudu rampung karo singlemod a. Maneh, amarga ukuran fisik Pods, ora bisa mbukak rong rentang twinax (kabel tembaga).
Akibaté, yen kita ngoptimalake rega lan njupuk menyang akun geometri desain iki, kita njaluk siji span twinax, siji span multimode lan siji span singlemode nggunakake CWDM. Iki njupuk menyang akun bisa upgrade path.
Iki katon kaya saiki, ing ngendi kita arep lan apa sing bisa ditindakake. Cetha, paling ora, carane pindhah menyang 50-Gigabit SerDes kanggo multimode lan singlemode. Kajaba iku, yen sampeyan ndeleng apa sing ana ing transceiver mode siji saiki lan ing mangsa ngarep kanggo 400G, asring sanajan 50G SerDes teka saka sisih listrik, 100 Gbps saben jalur wis bisa menyang optik. Mulane, bisa uga yen tinimbang pindhah menyang 50, bakal ana transisi menyang 100 Gigabit SerDes lan 100 Gbps saben jalur, amarga miturut janjine akeh vendor, kasedhiyan bakal cukup cepet. Periode nalika 50G SerDes minangka sing paling cepet, misale jek, ora bakal suwe banget, amarga salinan pisanan 100G SerDes diluncurake meh taun ngarep. Lan sawise sawetara wektu sawise sing padha mbokmenawa bakal worth dhuwit cukup.
Siji nuansa liyane babagan pilihan fisika. Ing asas, kita wis bisa nggunakake 400 utawa 200 bandar Gigabit nggunakake 50G SerDes. Nanging dadi metu sing iki ora nggawe akeh pangertèn, amarga, kaya aku ngandika sadurungé, kita pengin radix cukup gedhe ing ngalih, ing alesan, mesthi. Kita pengin 128. Lan yen kita duwe kapasitas chip winates lan kita nambah kacepetan link, banjur radix alamiah sudo, ora ana kaelokan.
Lan kita bisa nambah kapasitas total nggunakake pesawat, lan ora ana biaya khusus, kita bisa nambah nomer pesawat. Lan yen kita kelangan radix, kita kudu ngenalake level tambahan, supaya ing kahanan saiki, kanthi kapasitas maksimum sing kasedhiya saben chip, dadi luwih efisien nggunakake port 100-gigabit, amarga ngidini sampeyan kanggo entuk radix sing luwih gedhe.
Pitakonan sabanjure yaiku carane fisika diatur, nanging saka sudut pandang infrastruktur kabel. Pranyata diatur kanthi cara sing rada lucu. Kabel antarane saklar rwaning lan spines tingkat pertama - ora ana akeh tautan ing kana, kabeh dibangun kanthi gampang. Nanging yen kita njupuk pesawat siji, apa mengkono nang iku kita kudu nyambungake kabeh spines saka tingkat pisanan karo kabeh spines saka tingkat kapindho.
Kajaba iku, minangka aturan, ana sawetara kepinginan babagan carane kudu katon ing tengah data. Contone, kita pancene wanted kanggo gabungke kabel menyang mbendel lan narik wong-wong mau supaya siji panel patch kapadhetan dhuwur dadi tanggung menyang siji panel patch, supaya ora ana kebon binatang ing syarat-syarat dawa. Kita bisa ngatasi masalah iki. Yen pisanan katon ing topologi logis, sampeyan bisa ndeleng manawa pesawat iku sawijining, saben pesawat bisa dibangun ing dhewe. Nanging nalika kita nambah bundling kuwi lan pengin nyeret kabeh panel tembelan menyang panel tembelan, kita kudu nyampur pesawat beda ing siji mbendel lan introduce struktur penengah ing wangun sambungan silang optik kanggo repack saka carane padha nglumpuk. ing bagean siji, babagan carane bakal diklumpukake ing bagean liyane. Thanks kanggo iki, kita entuk fitur sing apik: kabeh saklar kompleks ora ngluwihi rak. Nalika sampeyan kudu intertwine soko banget kuwat, "mbukak pesawat,"Kadhangkala disebut ing jaringan Clos, iku kabeh klempakan nang siji rak. Kita ora duwe Highly disassembled, mudhun kanggo pranala individu, ngoper antarane rak.
Iki minangka tampilan saka sudut pandang organisasi logis saka infrastruktur kabel. Ing gambar ing sisih kiwa, pamblokiran multi-werna nggambarake pamblokiran saklar spine tingkat pertama, saben wolung lembar, lan patang bundel kabel sing teka saka wong-wong mau, sing pindhah lan intersect karo bundel sing teka saka blok spine-2. .
Kothak cilik nuduhake prapatan. Ing sisih kiwa ndhuwur iku risak saben prapatan kuwi, iki bener 512 dening 512 port modul salib-sambungan sing repacks kabel supaya padha teka rampung menyang siji rak, ngendi ana mung siji utomo-2 bidang. Lan ing sisih tengen, scan gambar iki sethitik liyane rinci ing hubungan kanggo sawetara Pods ing utomo-1 tingkat, lan carane wis rangkep ing salib-connect, carane nerangake utomo-2 tingkat.
Iki kaya apa. Dudukan spine-2 sing durung dirakit kanthi lengkap (ing sisih kiwa) lan stand cross-connect. Sayange, ora akeh sing bisa dideleng ing kana. Kabeh struktur iki lagi disebarake saiki ing salah sawijining pusat data gedhe sing lagi ditambahi. Iki minangka karya sing ditindakake, bakal katon luwih apik, bakal diisi luwih apik.
Pitakonan penting: kita milih topologi logis lan mbangun fisika. Apa sing bakal kelakon ing bidang kontrol? Iku cukup dikenal saka pengalaman operasi, ana sawetara laporan sing link protokol negara apik, iku kesenengan kanggo bisa karo wong-wong mau, nanging sayangé, padha ora ukuran apik ing topologi padhet disambungake. Lan ana siji faktor utama sing nyegah iki - iki cara kerjane banjir ing protokol link negara. Yen sampeyan mung njupuk algoritma banjir lan ndeleng carane jaringan kita wis kabentuk, sampeyan bisa ndeleng sing bakal ana fanout gedhe banget ing saben langkah, lan mung bakal banjir pesawat kontrol karo nganyari. Secara khusus, topologi kasebut ora cocog karo algoritma banjir tradisional ing protokol link state.
Pilihan kanggo nggunakake BGP. Cara nyiyapake kanthi bener diterangake ing RFC 7938 babagan panggunaan BGP ing pusat data gedhe. Gagasan dhasar iku prasaja: jumlah minimal awalan saben host lan umume jumlah minimal awalan ing jaringan, nggunakake agregasi yen bisa, lan nyuda path hunting. Kita pengin distribusi nganyari sing ati-ati banget, sing diarani gratis lembah. Kita pengin nganyari bakal disebarake persis sapisan nalika liwat jaringan. Yen asale saka ngisor, dheweke munggah, ora luwih saka sepisan. Mesthine ora ana zigzag. Zigzags ala banget.
Kanggo nindakake iki, kita nggunakake desain sing cukup prasaja kanggo nggunakake mekanisme BGP ndasari. Yaiku, kita nggunakake eBGP sing mlaku ing link lokal, lan sistem otonom ditugasake kaya ing ngisor iki: sistem otonom ing ToR, sistem otonom ing kabeh blok spine-1 saka siji Pod, lan sistem otonom umum ing kabeh Top. saka Kain. Ora angel kanggo ndeleng lan ndeleng manawa prilaku normal BGP menehi distribusi nganyari sing dikarepake.
Alamiah, alamat lan agregasi alamat kudu dirancang supaya kompatibel karo cara routing dibangun, supaya njamin stabilitas bidang kontrol. Alamat L3 ing transportasi disambungake menyang topologi, amarga tanpa iki ora mungkin kanggo entuk agregasi; tanpa iki, alamat individu bakal nyusup menyang sistem routing. Lan siji liyane yaiku agregasi, sayangé, ora nyampur banget karo multi-path, amarga nalika kita duwe multi-path lan kita duwe aggregation, kabeh apik, nalika kabeh jaringan sehat, ora ana sing gagal. Sayange, sanalika kegagalan katon ing jaringan lan simetri topologi ilang, kita bisa teka menyang titik saka ngendi unit kasebut diumumake, saka ngendi kita ora bisa pindhah menyang ngendi kita kudu pindhah. Mulane, paling apik kanggo nglumpukake ing ngendi ora ana multi-path, ing kasus iki, iki minangka switch ToR.
Nyatane, bisa dikumpulake, nanging kanthi ati-ati. Yen kita bisa nindakake disaggregation kontrol nalika gagal jaringan dumadi. Nanging iki cukup tugas angel, kita malah kepingin weruh apa iku bakal bisa kanggo nindakake iki, apa iku bisa kanggo nambah automation tambahan, lan mesin negara winates sing bener kick BGP kanggo njaluk prilaku dikarepake. Sayange, Processing kasus sudhut banget non-jelas lan Komplek, lan tugas iki ora uga ditanggulangi dening masang lampiran external kanggo BGP.
Karya sing menarik banget babagan iki wis ditindakake ing kerangka protokol RIFT, sing bakal dibahas ing laporan sabanjure.
Liyane sing penting yaiku kepiye skala data ing topologi sing padhet, ing ngendi kita duwe akeh jalur alternatif. Ing kasus iki, sawetara struktur data tambahan digunakake: grup ECMP, kang siji njlèntrèhaké grup Next Hop.
Ing jaringan sing biasane digunakake, tanpa gagal, nalika kita munggah topologi Clos, cukup nggunakake mung siji klompok, amarga kabeh sing ora lokal diterangake kanthi standar, kita bisa munggah. Nalika kita pindhah saka ndhuwur menyang ngisor ing sisih kidul, banjur kabeh path ora ECMP, iku path path siji. Kabeh apik. Masalahe, lan keanehan topologi Clos klasik yaiku yen kita ndeleng Top kain, ing unsur apa wae, mung ana siji dalan menyang unsur ing ngisor iki. Yen gagal ana ing dalan iki, unsur tartamtu ing ndhuwur pabrik dadi ora bener kanggo prefiks sing ana ing mburi dalan sing rusak. Nanging kanggo liyane iku bener, lan kita kudu parse kelompok ECMP lan introduce negara anyar.
Kepiye skalabilitas bidang data katon ing piranti modern? Yen kita nindakake LPM (pertandhingan awalan paling dawa), kabeh cukup apik, luwih saka 100k awalan. Yen kita ngomong babagan grup Next Hop, kabeh luwih elek, 2-4 ewu. Yen kita ngomong babagan tabel sing ngemot katrangan saka Next Hops (utawa adjacencies), mula iki ana ing endi wae saka 16k nganti 64k. Lan iki bisa dadi masalah. Lan ing kene kita teka ing digression sing menarik: apa sing kedadeyan karo MPLS ing pusat data? Ing asas, kita wanted kanggo nindakake.
Ana rong prakara. Kita nindakake mikro-segmentasi ing host; kita ora perlu maneh ing jaringan. Iku ora apik banget karo dhukungan saka vendor beda, lan malah luwih karo mbukak implementasine ing kothak putih karo MPLS. Lan MPLS, paling ora implementasine tradisional, sayangé, digabungake banget karo ECMP. Lan mulane.
Iki kaya struktur penerusan ECMP kanggo IP. A nomer akeh ater-ater bisa nggunakake grup padha lan pemblokiran Next Hops padha (utawa adjacencies, iki bisa uga disebut beda ing dokumentasi beda kanggo piranti beda). Intine iki diterangake minangka port metu lan apa sing kudu ditulis maneh alamat MAC supaya bisa menyang Hop Sabanjure sing bener. Kanggo IP kabeh katon prasaja, sampeyan bisa nggunakake nomer ater-ater sing akeh banget kanggo grup sing padha, blok Next Hops sing padha.
Arsitèktur MPLS klasik nuduhake manawa, gumantung saka antarmuka sing metu, label kasebut bisa ditulis maneh menyang nilai sing beda. Mulane, kita kudu njaga grup lan blok Next Hops kanggo saben label input. Lan iki, sayangé, ora ukuran.
Iku gampang kanggo ndeleng manawa ing desain kita mbutuhake udakara 4000 switch ToR, jembar maksimal yaiku 64 jalur ECMP, yen kita pindhah saka spine-1 menyang spine-2. Kita lagi wae njaluk menyang siji tabel grup ECMP, yen mung siji ater-ater karo ToR ilang, lan kita ora njaluk menyang Tabel Sabanjure Hops ing kabeh.
Ora kabeh ora duwe pengarep-arep, amarga arsitektur kaya Segment Routing kalebu label global. Secara resmi, bisa uga ambruk kabeh blok Next Hops iki maneh. Kanggo nindakake iki, sampeyan kudu operasi jinis kertu alam bébas: njupuk label lan nulis maneh menyang siji tanpa nilai tartamtu. Nanging sayangé, iki ora ana ing implementasine sing kasedhiya.
Lan pungkasane, kita kudu nggawa lalu lintas eksternal menyang pusat data. Carane nindakake? Sadurunge, lalu lintas dikenalake menyang jaringan Clos saka ndhuwur. Yaiku, ana router pinggiran sing disambungake menyang kabeh piranti ing Ndhuwur kain. Solusi iki bisa digunakake kanthi apik ing ukuran cilik nganti medium. Sayange, kanggo ngirim lalu lintas simetris menyang kabeh jaringan kanthi cara iki, kita kudu teka bebarengan ing kabeh unsur saka Top saka kain, lan nalika ana luwih saka satus wong, ternyata kita uga kudu gedhe. radix ing router pinggiran. Umumé, iki mbutuhake dhuwit, amarga router pinggiran luwih fungsional, port kasebut bakal luwih larang, lan desaine ora apik banget.
Pilihan liyane yaiku miwiti lalu lintas kasebut saka ngisor. Gampang kanggo verifikasi manawa topologi Clos dibangun kanthi cara sing lalu lintas saka ngisor, yaiku, saka sisih ToR, disebarake kanthi rata ing antarane level ing kabeh Top kain ing rong iterasi, ngemot kabeh jaringan. Mulane, kita ngenalake jinis Pod khusus, Edge Pod, sing nyedhiyakake konektivitas eksternal.
Ana siji opsi liyane. Iki sing ditindakake Facebook, umpamane. Padha nyebataken Kain Aggregator utawa HGRID. Tingkat spine tambahan dienalake kanggo nyambungake sawetara pusat data. Desain iki bisa ditindakake yen kita ora duwe fungsi tambahan utawa owah-owahan enkapsulasi ing antarmuka. Yen lagi titik tutul tambahan, iku angel. Biasane, ana luwih akeh fungsi lan jinis membran sing misahake macem-macem bagean saka pusat data. Ora ana gunane kanggo nggawe membran kasebut gedhe, nanging yen pancen perlu kanggo sawetara alasan, mula kudu dipikirake manawa bisa njupuk, dadi amba lan ditransfer menyang host. Iki ditindakake, contone, dening akeh operator awan. Padha duwe overlays, padha miwiti saka sarwa dumadi.
Apa kesempatan pembangunan sing kita deleng? Kaping pisanan, ningkatake dhukungan kanggo pipa CI / CD. Kita pengin mabur kanthi cara nyoba lan nyoba cara mabur. Iki ora bisa ditindakake kanthi apik, amarga infrastruktur gedhe lan ora bisa diduplikasi kanggo tes. Sampeyan kudu ngerti carane ngenalake unsur tes menyang infrastruktur produksi tanpa ngeculake.
Instrumentasi sing luwih apik lan ngawasi sing luwih apik meh ora perlu. Pitakonan kabèh iku imbangan saka gaweyan lan bali. Yen sampeyan bisa nambah kanthi gaweyan sing cukup, apik banget.
Bukak sistem operasi kanggo piranti jaringan. Protokol sing luwih apik lan sistem rute sing luwih apik, kayata RIFT. Riset uga dibutuhake kanggo nggunakake skema kontrol kemacetan sing luwih apik lan bisa uga introduksi, paling ora ing sawetara titik, dhukungan RDMA ing kluster kasebut.
Nggoleki mangsa ngarep, kita butuh topologi canggih lan bisa uga jaringan sing kurang nggunakake overhead. Saka prekara-prekara sing anyar, ana publikasi babagan teknologi kain kanggo HPC Cray Slingshot, sing adhedhasar Ethernet komoditas, nanging kanthi pilihan nggunakake header sing luwih cendhek. Akibaté, overhead wis suda.
Kabeh kudu katahan minangka prasaja sabisa, nanging ora prasaja. Kompleksitas minangka mungsuh skalabilitas. Kesederhanaan lan struktur reguler minangka kanca kita. Yen sampeyan bisa nggawe ukuran ing endi wae, lakoni. Lan ing umum, iku apik kanggo melu ing teknologi jaringan saiki. Ana akeh perkara sing menarik. matur nuwun.
Source: www.habr.com