Pusat data moden mempunyai beratus-ratus peranti aktif yang dipasang, dilindungi oleh pelbagai jenis pemantauan. Tetapi seorang jurutera yang ideal dengan pemantauan yang sempurna di tangan akan dapat bertindak balas dengan betul kepada kegagalan rangkaian hanya dalam beberapa minit. Dalam laporan pada persidangan Next Hop 2020, saya membentangkan metodologi reka bentuk rangkaian DC, yang mempunyai ciri unik - pusat data menyembuhkan dirinya sendiri dalam milisaat. Lebih tepat lagi, jurutera menyelesaikan masalah dengan tenang, sementara perkhidmatan tidak menyedarinya.
Bagi kebanyakan jurutera rangkaian, rangkaian pusat data bermula, sudah tentu, dengan ToR, dengan suis dalam rak. ToR biasanya mempunyai dua jenis pautan. Yang kecil pergi ke pelayan, yang lain - terdapat N kali lebih banyak daripada mereka - pergi ke arah tulang belakang tahap pertama, iaitu, ke pautan atasnya. Pautan naik biasanya dianggap sama dan trafik antara pautan naik adalah seimbang berdasarkan cincang daripada 5-tuple, yang merangkumi proto, src_ip, dst_ip, src_port, dst_port. Tiada kejutan di sini.
Seterusnya, apakah rupa seni bina rancangan itu? Duri tahap pertama tidak bersambung antara satu sama lain, tetapi disambungkan melalui superspines. Huruf X akan bertanggungjawab untuk superspines; ia hampir seperti sambung silang.
Dan jelas bahawa, sebaliknya, tori disambungkan ke semua tulang belakang peringkat pertama. Apa yang penting dalam gambar ini? Jika kita mempunyai interaksi di dalam rak, maka interaksi itu, sudah tentu, melalui ToR. Jika interaksi berlaku di dalam modul, maka interaksi berlaku melalui duri peringkat pertama. Jika interaksi adalah intermodular - seperti di sini, ToR 1 dan ToR 2 - maka interaksi akan melalui tulang belakang kedua-dua tahap pertama dan kedua.
Secara teorinya, seni bina sedemikian mudah berskala. Jika kita mempunyai kapasiti port, ruang ganti di pusat data dan gentian pra-letak, maka bilangan lorong sentiasa boleh ditingkatkan, dengan itu meningkatkan kapasiti keseluruhan sistem. Ini sangat mudah dilakukan di atas kertas. Ia akan menjadi seperti ini dalam hidup. Tetapi cerita hari ini bukan tentang itu.
Saya mahu kesimpulan yang betul dibuat. Kami mempunyai banyak laluan di dalam pusat data. Mereka bebas bersyarat. Satu laluan di dalam pusat data hanya boleh dilakukan di dalam ToR. Di dalam modul, kami mempunyai bilangan laluan yang sama dengan bilangan lorong. Bilangan laluan antara modul adalah sama dengan hasil darab bilangan satah dan bilangan superspines dalam setiap satah. Untuk menjadikannya lebih jelas, untuk memahami skala, saya akan memberikan nombor yang sah untuk salah satu pusat data Yandex.
Terdapat lapan pesawat, setiap pesawat mempunyai 32 superspines. Akibatnya, ternyata terdapat lapan laluan di dalam modul, dan dengan interaksi antara modul sudah ada 256 daripadanya.
Iaitu, jika kita sedang membangunkan Buku Masakan, cuba mempelajari cara membina pusat data toleran kesalahan yang menyembuhkan diri mereka sendiri, maka seni bina satah adalah pilihan yang tepat. Ia menyelesaikan masalah penskalaan, dan secara teori ia mudah. Terdapat banyak laluan bebas. Persoalannya tetap: bagaimana seni bina sedemikian bertahan dari kegagalan? Terdapat pelbagai kegagalan. Dan kita akan membincangkan ini sekarang.
Biarkan salah seorang superspines kami "sakit". Di sini saya kembali kepada seni bina dua satah. Kami akan menggunakan ini sebagai contoh kerana lebih mudah untuk melihat apa yang berlaku dengan bahagian yang lebih sedikit bergerak. Biarkan X11 jatuh sakit. Bagaimanakah ini akan menjejaskan perkhidmatan yang tinggal di dalam pusat data? Banyak bergantung pada bagaimana kegagalan sebenarnya kelihatan.
Sekiranya kegagalan itu baik, ia ditangkap pada tahap automasi BFD yang sama, automasi dengan senang hati meletakkan sendi yang bermasalah dan mengasingkan masalah, maka semuanya baik-baik saja. Kami mempunyai banyak laluan, lalu lintas dihalakan semula dengan serta-merta ke laluan alternatif, dan perkhidmatan tidak akan melihat apa-apa. Ini skrip yang bagus.
Senario buruk adalah jika kita mengalami kerugian berterusan, dan automasi tidak menyedari masalahnya. Untuk memahami cara ini mempengaruhi aplikasi, kita perlu meluangkan sedikit masa membincangkan cara TCP berfungsi.
Saya harap saya tidak mengejutkan sesiapa pun dengan maklumat ini: TCP ialah protokol pengesahan penghantaran. Iaitu, dalam kes paling mudah, pengirim menghantar dua paket dan menerima ack terkumpul pada mereka: "Saya menerima dua paket."
Selepas itu, dia akan menghantar dua paket lagi, dan keadaan akan berulang. Saya memohon maaf terlebih dahulu untuk sedikit permudahkan. Senario ini betul jika tetingkap (bilangan paket dalam penerbangan) adalah dua. Sudah tentu, dalam kes umum ini tidak semestinya berlaku. Tetapi saiz tetingkap tidak menjejaskan konteks pemajuan paket.
Apa yang berlaku jika kita kehilangan paket 3? Dalam kes ini, penerima akan menerima paket 1, 2 dan 4. Dan dia akan memberitahu pengirim dengan jelas menggunakan pilihan SACK: "Anda tahu, tiga tiba, tetapi bahagian tengah telah hilang." Dia berkata, "Ack 2, SACK 4."
Pada masa ini, pengirim tanpa sebarang masalah mengulangi paket yang telah hilang.
Tetapi jika paket terakhir dalam tetingkap hilang, keadaan akan kelihatan berbeza sama sekali.
Penerima menerima tiga paket pertama dan pertama sekali mula menunggu. Terima kasih kepada beberapa pengoptimuman dalam tindanan TCP kernel Linux, ia akan menunggu paket berpasangan melainkan bendera secara jelas menunjukkan bahawa ia adalah paket terakhir atau sesuatu yang serupa. Ia akan menunggu sehingga tamat masa ACK Tertunda tamat dan kemudian menghantar pengakuan pada tiga paket pertama. Tetapi sekarang pengirim akan menunggu. Dia tidak tahu sama ada bungkusan keempat telah hilang atau hampir tiba. Dan untuk tidak membebankan rangkaian, ia akan cuba menunggu petunjuk jelas bahawa paket itu hilang, atau tamat masa RTO tamat tempoh.
Apakah tamat masa RTO? Ini ialah maksimum RTT yang dikira oleh timbunan TCP dan beberapa pemalar. Apakah jenis pemalar ini, sekarang kita akan membincangkan.
Tetapi yang penting ialah jika kita tidak bernasib baik lagi dan paket keempat hilang lagi, maka RTO berganda. Iaitu, setiap percubaan yang tidak berjaya bermakna menggandakan masa tamat.
Sekarang mari kita lihat apakah asas ini bersamaan. Secara lalai, RTO minimum ialah 200 ms. Ini ialah RTO minimum untuk pakej data. Untuk paket SYN ia berbeza, 1 saat. Seperti yang anda lihat, walaupun percubaan pertama untuk menghantar semula paket akan mengambil masa 100 kali lebih lama daripada RTT di dalam pusat data.
Sekarang mari kita kembali kepada senario kita. Apa yang berlaku dengan perkhidmatan itu? Perkhidmatan mula kehilangan paket. Biarkan perkhidmatan bernasib baik pada mulanya dan kehilangan sesuatu di tengah tetingkap, kemudian ia menerima KASUNG dan menghantar semula paket yang hilang.
Tetapi jika nasib buruk berulang, maka kami mempunyai RTO. Apa yang penting di sini? Ya, kami mempunyai banyak laluan dalam rangkaian kami. Tetapi trafik TCP bagi satu sambungan TCP tertentu akan terus melalui timbunan rosak yang sama. Kehilangan paket, dengan syarat X11 ajaib kami ini tidak padam sendiri, tidak membawa kepada lalu lintas yang mengalir ke kawasan yang tidak bermasalah. Kami cuba menghantar paket melalui timbunan patah yang sama. Ini membawa kepada kegagalan melata: pusat data ialah satu set aplikasi yang berinteraksi, dan beberapa sambungan TCP bagi semua aplikasi ini mula merosot - kerana superspine mempengaruhi semua aplikasi yang wujud di dalam pusat data. Seperti kata pepatah: jika anda tidak kasut kuda, kuda itu menjadi pincang; kuda itu menjadi pincang - laporan itu tidak dihantar; laporan tidak dihantar - kami kalah dalam perang. Hanya di sini kiraan dalam beberapa saat dari saat masalah timbul hingga ke peringkat kemerosotan yang perkhidmatan mula dirasai. Ini bermakna pengguna mungkin kehilangan sesuatu di suatu tempat.
Terdapat dua penyelesaian klasik yang saling melengkapi. Yang pertama ialah perkhidmatan yang cuba memasukkan penyedut minuman dan menyelesaikan masalah seperti ini: "Mari kita tweak sesuatu dalam timbunan TCP. Mari kita tamatkan masa pada peringkat aplikasi atau sesi TCP jangka panjang dengan pemeriksaan kesihatan dalaman." Masalahnya ialah penyelesaian sedemikian: a) tidak berskala sama sekali; b) diperiksa dengan sangat buruk. Iaitu, walaupun perkhidmatan secara tidak sengaja mengkonfigurasi timbunan TCP dengan cara yang menjadikannya lebih baik, pertama, ia tidak mungkin terpakai untuk semua aplikasi dan semua pusat data, dan kedua, kemungkinan besar, ia tidak akan memahami bahawa ia telah dilakukan. dengan betul, dan apa yang tidak. Iaitu, ia berfungsi, tetapi ia berfungsi dengan buruk dan tidak berskala. Dan jika terdapat masalah rangkaian, siapa yang harus dipersalahkan? Sudah tentu, NOC. Apa yang NOC lakukan?
Banyak perkhidmatan percaya bahawa dalam kerja NOC berlaku sesuatu seperti ini. Tetapi sejujurnya, bukan itu sahaja.
NOC dalam skim klasik terlibat dalam pembangunan banyak sistem pemantauan. Ini adalah pemantauan kotak hitam dan kotak putih. Mengenai contoh pemantauan tulang belakang kotak hitam Alexander Klimenko pada Next Hop yang lalu. Dengan cara ini, pemantauan ini berfungsi. Tetapi pemantauan yang ideal pun akan mempunyai selang masa. Biasanya ini adalah beberapa minit. Selepas ia padam, jurutera yang bertugas memerlukan masa untuk menyemak semula operasinya, menyetempatkan masalah dan kemudian memadamkan kawasan masalah. Iaitu, dalam kes terbaik, merawat masalah itu mengambil masa 5 minit, dalam kes yang paling teruk, 20 minit, jika tidak segera jelas di mana kerugian berlaku. Sudah jelas bahawa selama ini - 5 atau 20 minit - perkhidmatan kami akan terus terjejas, yang mungkin tidak baik.
Apakah yang anda ingin terima sebenarnya? Kami mempunyai begitu banyak cara. Dan masalah timbul dengan tepat kerana aliran TCP yang tidak bernasib baik terus menggunakan laluan yang sama. Kami memerlukan sesuatu yang membolehkan kami menggunakan berbilang laluan dalam satu sambungan TCP. Nampaknya kita ada penyelesaiannya. Terdapat TCP, yang dipanggil TCP berbilang laluan, iaitu, TCP untuk berbilang laluan. Benar, ia dibangunkan untuk tugas yang sama sekali berbeza - untuk telefon pintar yang mempunyai beberapa peranti rangkaian. Untuk memaksimumkan pemindahan atau membuat mod utama/sandaran, mekanisme telah dibangunkan yang mencipta berbilang utas (sesi) secara telus kepada aplikasi dan membolehkan anda bertukar antara mereka sekiranya berlaku kegagalan. Atau, seperti yang saya katakan, maksimumkan coretan.
Tetapi ada nuansa di sini. Untuk memahami apa itu, kita perlu melihat bagaimana benang ditubuhkan.
Benang dipasang secara berurutan. Benang pertama dipasang terlebih dahulu. Urutan berikutnya kemudian ditetapkan menggunakan kuki yang telah dipersetujui dalam rangkaian itu. Dan inilah masalahnya.
Masalahnya ialah jika benang pertama tidak wujud, benang kedua dan ketiga tidak akan timbul. Iaitu, TCP berbilang laluan tidak menyelesaikan kehilangan paket SYN dalam aliran pertama. Dan jika SYN hilang, TCP berbilang laluan bertukar menjadi TCP biasa. Ini bermakna dalam persekitaran pusat data ia tidak akan membantu kami menyelesaikan masalah kerugian di kilang dan belajar menggunakan berbilang laluan sekiranya berlaku kegagalan.
Apa yang boleh membantu kita? Sesetengah daripada anda telah meneka dari tajuk bahawa medan penting dalam cerita kami selanjutnya ialah medan pengepala label aliran IPv6. Sesungguhnya, ini adalah medan yang muncul dalam v6, ia bukan dalam v4, ia menduduki 20 bit, dan terdapat kontroversi mengenai penggunaannya untuk masa yang lama. Ini sangat menarik - terdapat pertikaian, sesuatu telah diperbaiki dalam RFC, dan pada masa yang sama pelaksanaan muncul dalam kernel Linux, yang tidak didokumenkan di mana-mana.
Saya menjemput anda untuk pergi bersama saya dalam siasatan kecil. Mari kita lihat apa yang berlaku dalam kernel Linux sejak beberapa tahun lalu.
tahun 2014. Seorang jurutera dari sebuah syarikat besar dan dihormati menambah kefungsian kernel Linux pergantungan nilai label aliran pada cincang soket. Apa yang mereka cuba betulkan di sini? Ini berkaitan dengan RFC 6438, yang membincangkan isu berikut. Di dalam pusat data, IPv4 sering terkandung dalam paket IPv6, kerana kilang itu sendiri adalah IPv6, tetapi IPv4 mesti diberikan di luar. Untuk masa yang lama terdapat masalah dengan suis yang tidak dapat melihat di bawah dua pengepala IP untuk pergi ke TCP atau UDP dan mencari src_ports, dst_ports di sana. Ternyata hash, jika anda melihat pada dua tajuk IP pertama, ternyata hampir diperbaiki. Untuk mengelakkan ini, supaya pengimbangan trafik terkapsul ini berfungsi dengan betul, adalah dicadangkan untuk menambah cincang paket berkapsul 5 tuple kepada nilai medan label aliran. Kira-kira perkara yang sama telah dilakukan untuk skim enkapsulasi lain, untuk UDP, untuk GRE, yang terakhir menggunakan medan GRE Key. Satu cara atau yang lain, matlamat di sini adalah jelas. Dan sekurang-kurangnya pada masa itu mereka berguna.
Pada tahun 2015, tampung baharu datang daripada jurutera yang dihormati yang sama. Dia sangat menarik. Ia menyatakan perkara berikut - kami akan merawak cincang sekiranya berlaku peristiwa penghalaan negatif. Apakah peristiwa penghalaan negatif? Inilah RTO yang kita bincangkan tadi, iaitu kehilangan ekor tingkap adalah peristiwa yang benar-benar negatif. Benar, agak sukar untuk meneka bahawa ini dia.
2016, sebuah lagi syarikat terkemuka, juga besar. Ia membuka tongkat terakhir dan menjadikannya supaya cincang, yang kami buat secara rawak sebelum ini, kini berubah untuk setiap penghantaran semula SYN dan selepas setiap tamat masa RTO. Dan dalam surat ini, untuk kali pertama dan terakhir, matlamat utama dinyatakan - untuk memastikan trafik sekiranya berlaku kerugian atau kesesakan saluran mempunyai keupayaan untuk dihalakan semula dengan lembut dan menggunakan berbilang laluan. Sudah tentu, selepas ini terdapat banyak penerbitan, anda boleh mencarinya dengan mudah.
Walaupun tidak, anda tidak boleh, kerana belum ada satu pun penerbitan mengenai topik ini. Tetapi kami tahu!
Dan jika anda tidak memahami sepenuhnya apa yang telah dilakukan, saya akan memberitahu anda sekarang.
Apa yang telah dilakukan, apakah fungsi yang telah ditambahkan pada kernel Linux? txhash berubah kepada nilai rawak selepas setiap acara RTO. Ini adalah hasil yang sangat negatif daripada penghalaan. Cincang bergantung pada txhash ini, dan label aliran bergantung pada cincang skb. Terdapat beberapa pengiraan pada fungsi di sini; semua butiran tidak boleh diletakkan pada satu slaid. Jika ada yang ingin tahu, anda boleh pergi melalui kod kernel dan semak.
Apa yang penting di sini? Nilai medan label aliran berubah kepada nombor rawak selepas setiap RTO. Bagaimanakah ini mempengaruhi aliran TCP kami yang malang?
Jika SACK berlaku, tiada apa-apa perubahan kerana kami cuba menghantar semula paket hilang yang diketahui. Setakat ini baik.
Tetapi dalam kes RTO, dengan syarat kami telah menambahkan label aliran pada fungsi cincang pada ToR, trafik mungkin mengambil laluan yang berbeza. Dan lebih banyak lorong, lebih besar kemungkinan ia akan menemui laluan yang tidak terjejas oleh kegagalan pada peranti tertentu.
Satu masalah kekal - RTO. Sudah tentu, terdapat laluan lain, tetapi banyak masa terbuang untuk ini. 200 ms adalah banyak. Sesaat benar-benar liar. Sebelum ini, saya bercakap tentang tamat masa yang perkhidmatan dikonfigurasikan. Jadi, satu saat ialah tamat masa, yang biasanya dikonfigurasikan oleh perkhidmatan di peringkat aplikasi, dan dalam hal ini perkhidmatan itu akan menjadi agak betul. Selain itu, saya ulangi, RTT sebenar di dalam pusat data moden adalah sekitar 1 milisaat.
Apakah yang boleh anda lakukan dengan tamat masa RTO? Tamat masa, yang bertanggungjawab untuk RTO sekiranya kehilangan paket data, boleh dikonfigurasikan dengan agak mudah dari ruang pengguna: terdapat utiliti IP, dan salah satu parameternya mengandungi rto_min yang sama. Memandangkan RTO, sudah tentu, perlu diselaraskan bukan secara global, tetapi untuk awalan yang diberikan, mekanisme sedemikian kelihatan agak boleh dilaksanakan.
Benar, dengan SYN_RTO semuanya lebih teruk. Ia secara semula jadi dipaku. Kernel mempunyai nilai tetap 1 saat, dan itu sahaja. Anda tidak boleh sampai ke sana dari ruang pengguna. Hanya ada satu cara.
eBPF datang untuk menyelamatkan. Ringkasnya, ini adalah program C kecil. Ia boleh dimasukkan ke dalam cangkuk di tempat yang berbeza dalam pelaksanaan tindanan kernel dan tindanan TCP, yang dengannya anda boleh menukar sebilangan besar tetapan. Secara umum, eBPF ialah trend jangka panjang. Daripada memotong berpuluh-puluh parameter sysctl baharu dan mengembangkan utiliti IP, pergerakan itu bergerak ke arah eBPF dan mengembangkan fungsinya. Menggunakan eBPF, anda boleh menukar kawalan kesesakan dan pelbagai tetapan TCP lain secara dinamik.
Tetapi penting bagi kami bahawa ia boleh digunakan untuk menukar nilai SYN_RTO. Selain itu, terdapat contoh yang disiarkan secara terbuka: . Apa yang telah dilakukan di sini? Contohnya berfungsi, tetapi dengan sendirinya sangat kasar. Di sini diandaikan bahawa di dalam pusat data kita membandingkan 44 bit pertama; jika ia sepadan, maka kita berada di dalam pusat data. Dan dalam kes ini kita menukar nilai tamat masa SYN_RTO kepada 4ms. Tugas yang sama boleh dilakukan dengan lebih elegan. Tetapi contoh mudah ini menunjukkan bahawa ini adalah a) mungkin; b) agak mudah.
Apa yang kita sudah tahu? Hakikat bahawa seni bina satah membolehkan penskalaan, ternyata sangat berguna untuk kami apabila kami mendayakan label aliran pada ToR dan mendapat keupayaan untuk mengalir di sekitar kawasan masalah. Cara terbaik untuk mengurangkan nilai RTO dan SYN-RTO ialah menggunakan program eBPF. Persoalannya tetap: adakah selamat menggunakan label aliran untuk mengimbangi? Dan ada nuansa di sini.
Katakan anda mempunyai perkhidmatan pada rangkaian anda yang tinggal di anycast. Malangnya, saya tidak mempunyai masa untuk menerangkan secara terperinci tentang apa itu anycast, tetapi ia adalah perkhidmatan yang diedarkan dengan pelayan fizikal berbeza yang boleh diakses melalui alamat IP yang sama. Dan inilah masalah yang mungkin: peristiwa RTO boleh berlaku bukan sahaja apabila trafik melalui fabrik. Ia juga boleh berlaku pada tahap penimbal ToR: apabila peristiwa incast berlaku, ia juga boleh berlaku pada hos apabila hos menumpahkan sesuatu. Apabila peristiwa RTO berlaku dan ia menukar label aliran. Dalam kes ini, trafik boleh pergi ke contoh anycast lain. Mari kita anggap ini adalah anycast stateful, ia mengandungi keadaan sambungan - ia boleh menjadi Pengimbang L3 atau beberapa perkhidmatan lain. Kemudian masalah timbul, kerana selepas RTO sambungan TCP tiba di pelayan, yang tidak tahu apa-apa tentang sambungan TCP ini. Dan jika kami tidak mempunyai perkongsian negeri antara pelayan anycast, maka trafik tersebut akan digugurkan dan sambungan TCP akan terputus.
Apa yang boleh anda lakukan di sini? Dalam persekitaran terkawal anda, di mana anda mendayakan pengimbangan label aliran, anda perlu merekodkan nilai label aliran apabila mengakses pelayan anycast. Cara paling mudah ialah melakukan ini melalui program eBPF yang sama. Tetapi inilah perkara yang sangat penting - apa yang perlu dilakukan jika anda tidak mengendalikan rangkaian pusat data, tetapi merupakan pengendali telekomunikasi? Ini adalah masalah anda juga: bermula dengan versi Juniper dan Arista tertentu, mereka menyertakan label aliran dalam fungsi cincang mereka secara lalai - terus terang, atas sebab yang tidak jelas kepada saya. Ini boleh menyebabkan anda menggugurkan sambungan TCP daripada pengguna yang melalui rangkaian anda. Jadi saya amat mengesyorkan anda menyemak tetapan penghala anda di sini.
Satu cara atau yang lain, nampaknya saya sudah bersedia untuk beralih kepada eksperimen.
Apabila kami mendayakan label aliran pada ToR, menyediakan ejen eBPF, yang kini hidup pada hos, kami memutuskan untuk tidak menunggu kegagalan besar seterusnya, tetapi untuk melakukan letupan terkawal. Kami mengambil ToR, yang mempunyai empat pautan atas, dan menyediakan titisan pada salah satu daripadanya. Mereka membuat peraturan dan berkata - kini anda kehilangan semua paket. Seperti yang anda lihat di sebelah kiri, kami mempunyai pemantauan setiap paket, yang telah menurun kepada 75%, iaitu, 25% daripada paket hilang. Di sebelah kanan ialah graf perkhidmatan yang tinggal di belakang ToR ini. Pada asasnya, ini adalah graf trafik antara muka dengan pelayan di dalam rak. Seperti yang anda lihat, mereka tenggelam lebih rendah. Mengapa mereka turun lebih rendah - bukan sebanyak 25%, tetapi dalam beberapa kes sebanyak 3-4 kali? Jika sambungan TCP tidak bernasib baik, ia terus cuba mencapai melalui persimpangan yang rosak. Ini diburukkan lagi oleh kelakuan tipikal perkhidmatan di dalam DC - untuk satu permintaan pengguna, N permintaan kepada perkhidmatan dalaman dijana, dan respons akan dihantar kepada pengguna sama ada apabila semua sumber data bertindak balas atau apabila tamat masa berlaku pada aplikasi tahap, yang masih perlu dikonfigurasikan. Iaitu, semuanya sangat-sangat teruk.
Kini percubaan yang sama, tetapi dengan nilai label aliran didayakan. Seperti yang anda lihat, di sebelah kiri pemantauan kelompok kami menurun sebanyak 25%. Ini betul-betul betul, kerana ia tidak tahu apa-apa tentang penghantaran semula, ia menghantar paket dan hanya mengira nisbah bilangan paket yang dihantar dan hilang.
Dan di sebelah kanan adalah jadual perkhidmatan. Anda tidak akan menemui kesan sendi yang bermasalah di sini. Dalam milisaat yang sama, trafik mengalir dari kawasan masalah ke tiga pautan atas yang tinggal yang tidak terjejas oleh masalah itu. Kami mempunyai rangkaian yang menyembuhkan dirinya sendiri.
Ini adalah slaid terakhir saya, masa untuk meringkaskan. Sekarang, saya harap anda tahu cara membina rangkaian pusat data penyembuhan diri. Anda tidak perlu melalui arkib kernel Linux dan mencari tampung khas di sana; anda tahu bahawa label Aliran dalam kes ini menyelesaikan masalah, tetapi anda perlu mendekati mekanisme ini dengan berhati-hati. Dan saya menekankan sekali lagi bahawa jika anda seorang operator telekomunikasi, anda tidak seharusnya menggunakan label aliran sebagai fungsi cincang, jika tidak, anda akan mengganggu sesi pengguna anda.
Jurutera rangkaian mesti menjalani anjakan konsep: rangkaian bermula bukan dengan ToR, bukan dengan peranti rangkaian, tetapi dengan hos. Contoh yang agak menarik ialah cara kami menggunakan eBPF untuk menukar RTO dan untuk membetulkan label aliran ke arah perkhidmatan anycast.
Mekanik label aliran pastinya sesuai untuk aplikasi lain dalam segmen pentadbiran terkawal. Ini boleh menjadi trafik antara pusat data, atau anda boleh menggunakan mekanik sedemikian dengan cara yang istimewa untuk mengurus trafik keluar. Tetapi saya akan memberitahu anda tentang ini, saya harap, lain kali. Terima kasih banyak atas perhatian anda.
Sumber: www.habr.com