Pusat data modern memiliki ratusan perangkat aktif yang terpasang, yang tercakup dalam berbagai jenis pemantauan. Tetapi bahkan seorang insinyur ideal yang memiliki pemantauan sempurna akan mampu merespons kegagalan jaringan dengan benar hanya dalam beberapa menit. Dalam laporan di konferensi Next Hop 2020, saya mempresentasikan metodologi desain jaringan DC, yang memiliki fitur unik - pusat data menyembuhkan dirinya sendiri dalam milidetik. Lebih tepatnya, insinyur dengan tenang memperbaiki masalah, sementara layanan tidak menyadarinya.
Bagi banyak insinyur jaringan, jaringan pusat data tentu saja dimulai dengan ToR, dengan saklar di rak. ToR biasanya memiliki dua jenis tautan. Yang kecil pergi ke server, yang lain - jumlahnya N kali lebih banyak - menuju tulang punggung tingkat pertama, yaitu ke uplink-nya. Uplink biasanya dianggap sama, dan lalu lintas antar uplink diseimbangkan berdasarkan hash dari 5 tupel, yang mencakup proto, src_ip, dst_ip, src_port, dst_port. Tidak ada kejutan di sini.
Selanjutnya, seperti apa arsitektur denahnya? Duri tingkat pertama tidak terhubung satu sama lain, tetapi dihubungkan melalui superspine. Huruf X akan bertanggung jawab atas superspine; hampir seperti sambungan silang.
Dan jelas bahwa, sebaliknya, tori terhubung ke semua duri tingkat pertama. Apa yang penting dalam gambar ini? Jika kita melakukan interaksi di dalam rak, maka interaksi tersebut tentu saja melalui ToR. Jika interaksi terjadi di dalam modul, maka interaksi terjadi melalui duri tingkat pertama. Jika interaksinya bersifat intermodular - seperti di sini, ToR 1 dan ToR 2 - maka interaksi tersebut akan melalui tahap pertama dan kedua.
Secara teori, arsitektur seperti itu mudah diskalakan. Jika kita memiliki kapasitas pelabuhan, ruang kosong di pusat data, dan fiber optik yang sudah dipasang sebelumnya, maka jumlah jalur selalu dapat ditingkatkan, sehingga meningkatkan kapasitas sistem secara keseluruhan. Ini sangat mudah dilakukan di atas kertas. Akan seperti ini dalam hidup. Tapi cerita hari ini bukan tentang itu.
Saya ingin kesimpulan yang tepat dapat diambil. Kami memiliki banyak jalur di dalam pusat data. Mereka independen secara kondisional. Satu jalur di dalam pusat data hanya dimungkinkan di dalam ToR. Di dalam modul, kita mempunyai jumlah jalur yang sama dengan jumlah jalur. Jumlah jalur antar modul sama dengan hasil kali jumlah bidang dan jumlah superspine di setiap bidang. Agar lebih jelas, untuk mengetahui skalanya, saya akan memberikan angka yang valid untuk salah satu pusat data Yandex.
Ada delapan bidang, masing-masing bidang memiliki 32 superspine. Hasilnya, ternyata ada delapan jalur di dalam modul, dan dengan interaksi antarmodul sudah ada 256 jalur.
Artinya, jika kita mengembangkan Cookbook, mencoba mempelajari cara membangun pusat data yang toleran terhadap kesalahan dan dapat menyembuhkan dirinya sendiri, maka arsitektur planar adalah pilihan yang tepat. Ini memecahkan masalah penskalaan, dan secara teori itu mudah. Ada banyak jalur independen. Pertanyaannya tetap: bagaimana arsitektur seperti itu bisa bertahan dari kegagalan? Ada berbagai kegagalan. Dan kita akan membahasnya sekarang.
Biarkan salah satu superspine kita βsakitβ. Di sini saya kembali ke arsitektur dua bidang. Kami akan tetap menggunakan ini sebagai contoh karena akan lebih mudah untuk melihat apa yang terjadi dengan lebih sedikit bagian yang bergerak. Biarkan X11 sakit. Bagaimana pengaruh hal ini terhadap layanan yang ada di dalam pusat data? Banyak hal bergantung pada seperti apa kegagalan sebenarnya.
Jika kegagalannya bagus, ditangkap pada tingkat otomatisasi BFD yang sama, otomatisasi dengan senang hati menempatkan sambungan yang bermasalah dan mengisolasi masalahnya, maka semuanya baik-baik saja. Kami memiliki banyak jalur, lalu lintas langsung dialihkan ke rute alternatif, dan layanan tidak akan memperhatikan apa pun. Ini naskah yang bagus.
Skenario buruknya adalah jika kita mengalami kerugian terus-menerus, dan otomatisasi tidak menyadari masalahnya. Untuk memahami bagaimana hal ini mempengaruhi aplikasi, kita harus meluangkan sedikit waktu untuk membahas cara kerja TCP.
Saya harap saya tidak mengejutkan siapa pun dengan informasi ini: TCP adalah protokol konfirmasi transmisi. Artinya, dalam kasus paling sederhana, pengirim mengirim dua paket dan menerima konfirmasi kumulatif: βSaya menerima dua paket.β
Setelah itu, dia akan mengirimkan dua paket lagi, dan situasinya akan terulang kembali. Saya mohon maaf sebelumnya atas beberapa penyederhanaan. Skenario ini benar jika window (jumlah paket dalam penerbangan) adalah dua. Tentu saja, dalam kasus umum hal ini belum tentu terjadi. Namun ukuran jendela tidak mempengaruhi konteks penerusan paket.
Apa yang terjadi jika kita kehilangan paket 3? Dalam hal ini, penerima akan menerima paket 1, 2 dan 4. Dan dia akan secara eksplisit memberi tahu pengirim menggunakan opsi SACK: βTahukah Anda, tiga sudah tiba, tetapi yang tengah hilang.β Dia berkata, "Ack 2, SACK 4."
Pada saat ini, pengirim tanpa masalah mengulangi paket yang hilang dengan tepat.
Namun jika paket terakhir di jendela hilang, situasinya akan terlihat sangat berbeda.
Penerima menerima tiga paket pertama dan pertama-tama mulai menunggu. Berkat beberapa optimasi pada tumpukan TCP kernel Linux, paket tersebut akan menunggu paket berpasangan kecuali jika flag secara eksplisit menunjukkan bahwa itu adalah paket terakhir atau yang serupa. Ini akan menunggu sampai batas waktu ACK Tertunda berakhir dan kemudian mengirimkan pengakuan pada tiga paket pertama. Tapi sekarang pengirimnya akan menunggu. Dia tidak tahu apakah paket keempat sudah hilang atau akan tiba. Dan agar tidak membebani jaringan, ia akan mencoba menunggu indikasi eksplisit bahwa paket tersebut hilang, atau batas waktu RTO berakhir.
Apa itu batas waktu RTO? Ini adalah RTT maksimum yang dihitung oleh tumpukan TCP dan beberapa konstanta. Konstanta macam apa ini, sekarang kita akan membahasnya.
Tapi yang penting kalau kita lagi sial dan paket keempat hilang lagi, maka RTOnya berlipat ganda. Artinya, setiap upaya yang gagal berarti menggandakan batas waktu.
Sekarang mari kita lihat apa yang dimaksud dengan basis ini. Secara default, RTO minimum adalah 200 ms. Ini adalah RTO minimum untuk paket data. Untuk paket SYN berbeda, 1 detik. Seperti yang Anda lihat, bahkan upaya pertama untuk mengirim ulang paket akan memakan waktu 100 kali lebih lama dibandingkan RTT di dalam pusat data.
Sekarang mari kita kembali ke skenario kita. Apa yang terjadi dengan layanan ini? Layanan mulai kehilangan paket. Biarkan layanan beruntung secara kondisional pada awalnya dan kehilangan sesuatu di tengah jendela, kemudian menerima SACK dan mengirim ulang paket yang hilang.
Tetapi jika nasib buruk terulang kembali, maka kita memiliki RTO. Apa yang penting di sini? Ya, kami memiliki banyak jalur di jaringan kami. Namun lalu lintas TCP dari satu koneksi TCP tertentu akan terus melewati tumpukan rusak yang sama. Paket yang hilang asalkan X11 ajaib milik kita ini tidak padam dengan sendirinya, tidak menyebabkan trafik mengalir ke area yang tidak bermasalah. Kami mencoba mengirimkan paket melalui tumpukan rusak yang sama. Hal ini menyebabkan kegagalan berjenjang: pusat data adalah sekumpulan aplikasi yang berinteraksi, dan beberapa koneksi TCP dari semua aplikasi ini mulai menurun - karena superspine memengaruhi semua aplikasi yang ada di dalam pusat data. Seperti kata pepatah: jika Anda tidak memakai sepatu pada kuda, kuda itu akan menjadi lumpuh; kudanya menjadi lumpuh - laporan tidak terkirim; laporan tidak terkirim - kami kalah perang. Hanya di sini hitungannya hanya dalam hitungan detik sejak masalah muncul hingga tahap degradasi yang mulai dirasakan oleh pelayanan. Ini berarti bahwa pengguna mungkin melewatkan sesuatu di suatu tempat.
Ada dua solusi klasik yang saling melengkapi. Yang pertama adalah layanan yang mencoba memberikan solusi dan menyelesaikan masalah seperti ini: βMari kita ubah sesuatu di tumpukan TCP. Mari kita buat batas waktu pada tingkat aplikasi atau sesi TCP yang berumur panjang dengan pemeriksaan kondisi internal.β Masalahnya adalah solusi-solusi tersebut: a) tidak berskala sama sekali; b) diperiksa dengan sangat buruk. Artinya, meskipun layanan secara tidak sengaja mengonfigurasi tumpukan TCP dengan cara yang membuatnya lebih baik, pertama, layanan tersebut kemungkinan tidak dapat diterapkan untuk semua aplikasi dan semua pusat data, dan kedua, kemungkinan besar, layanan tersebut tidak akan memahami bahwa layanan tersebut telah selesai. benar, dan apa yang tidak. Artinya, ini berfungsi, tetapi berfungsi dengan buruk dan tidak berskala. Dan jika ada masalah jaringan, siapa yang harus disalahkan? Tentu saja NOC. Apa yang dilakukan NOC?
Banyak layanan percaya bahwa pekerjaan di NOC terjadi seperti ini. Tapi sejujurnya, tidak hanya itu.
NOC dalam skema klasik terlibat dalam pengembangan banyak sistem pemantauan. Ini adalah pemantauan kotak hitam dan kotak putih. Tentang contoh pemantauan tulang belakang kotak hitam Alexander Klimenko di Next Hop terakhir. Omong-omong, pemantauan ini berhasil. Namun pemantauan yang ideal sekalipun akan mempunyai jeda waktu. Biasanya ini beberapa menit. Setelah meledak, para insinyur yang bertugas memerlukan waktu untuk memeriksa ulang pengoperasiannya, melokalisasi masalahnya, dan kemudian memadamkan area masalahnya. Artinya, dalam kasus terbaik, penanganan masalah memerlukan waktu 5 menit, dalam kasus terburuk, 20 menit, jika tidak segera terlihat jelas di mana kerugian tersebut terjadi. Jelas bahwa selama ini - 5 atau 20 menit - layanan kami akan terus mengalami penurunan, yang mungkin tidak baik.
Apa yang sebenarnya ingin Anda terima? Kami punya banyak cara. Dan masalah muncul justru karena aliran TCP yang kurang beruntung terus menggunakan rute yang sama. Kita memerlukan sesuatu yang memungkinkan kita menggunakan banyak rute dalam satu koneksi TCP. Tampaknya kita punya solusinya. Ada TCP, yang disebut TCP multipath, yaitu TCP untuk banyak jalur. Benar, ini dikembangkan untuk tugas yang sama sekali berbeda - untuk ponsel cerdas yang memiliki beberapa perangkat jaringan. Untuk memaksimalkan transfer atau menjadikan mode utama/cadangan, mekanisme dikembangkan yang membuat beberapa thread (sesi) secara transparan ke aplikasi dan memungkinkan Anda untuk beralih di antara thread tersebut jika terjadi kegagalan. Atau, seperti yang saya katakan, maksimalkan pukulannya.
Namun ada nuansa di sini. Untuk memahami apa itu, kita harus melihat bagaimana thread dibuat.
Utas dipasang secara berurutan. Thread pertama dipasang terlebih dahulu. Thread berikutnya kemudian diatur menggunakan cookie yang telah disepakati dalam thread tersebut. Dan inilah masalahnya.
Masalahnya kalau thread pertama tidak terbentuk sendiri maka thread kedua dan ketiga tidak akan pernah muncul. Artinya, TCP multipath tidak menyelesaikan hilangnya paket SYN pada aliran pertama. Dan jika SYN hilang, TCP multipath berubah menjadi TCP biasa. Artinya, dalam lingkungan pusat data, hal ini tidak akan membantu kita menyelesaikan masalah kerugian di pabrik dan belajar menggunakan banyak jalur jika terjadi kegagalan.
Apa yang bisa membantu kita? Beberapa dari Anda sudah menebak dari judulnya bahwa bidang penting dalam cerita kita selanjutnya adalah bidang header label aliran IPv6. Memang ini adalah bidang yang muncul di v6, bukan di v4, menempati 20 bit, dan sudah lama ada kontroversi mengenai penggunaannya. Ini sangat menarik - ada perselisihan, ada sesuatu yang diperbaiki dalam RFC, dan pada saat yang sama sebuah implementasi muncul di kernel Linux, yang tidak didokumentasikan di mana pun.
Saya mengundang Anda untuk pergi bersama saya dalam penyelidikan kecil. Mari kita lihat apa yang terjadi di kernel Linux selama beberapa tahun terakhir.
tahun 2014. Seorang insinyur dari satu perusahaan besar dan dihormati menambah fungsionalitas kernel Linux ketergantungan nilai label aliran pada hash soket. Apa yang mereka coba perbaiki di sini? Hal ini terkait dengan RFC 6438 yang membahas masalah berikut. Di dalam pusat data, IPv4 sering dienkapsulasi dalam paket IPv6, karena pabriknya sendiri adalah IPv6, tetapi IPv4 entah bagaimana harus diberikan di luar. Untuk waktu yang lama ada masalah dengan sakelar yang tidak dapat mencari di bawah dua header IP untuk mengakses TCP atau UDP dan menemukan src_ports, dst_ports di sana. Ternyata hashnya, jika melihat dua header IP pertama, ternyata hampir diperbaiki. Untuk menghindari hal ini, agar penyeimbangan lalu lintas yang dienkapsulasi ini berfungsi dengan benar, diusulkan untuk menambahkan hash dari paket yang dienkapsulasi 5-tuple ke nilai bidang label aliran. Kira-kira hal yang sama dilakukan untuk skema enkapsulasi lainnya, untuk UDP, untuk GRE, yang terakhir menggunakan bidang GRE Key. Dengan satu atau lain cara, tujuannya jelas di sini. Dan setidaknya pada saat itu mereka berguna.
Pada tahun 2015, patch baru datang dari insinyur terhormat yang sama. Dia sangat menarik. Dikatakan sebagai berikut - kami akan mengacak hash jika terjadi peristiwa perutean negatif. Apa yang dimaksud dengan peristiwa perutean negatif? Inilah RTO yang telah kita bahas sebelumnya, yaitu hilangnya tail of the window merupakan peristiwa yang benar-benar negatif. Benar, relatif sulit untuk menebak bahwa inilah saatnya.
2016, perusahaan terkemuka lainnya, juga besar. Ini membongkar kruk terakhir dan membuatnya sehingga hash, yang sebelumnya kita buat secara acak, sekarang berubah untuk setiap transmisi ulang SYN dan setelah setiap batas waktu RTO. Dan dalam surat ini, untuk pertama dan terakhir kalinya, tujuan akhir dinyatakan - untuk memastikan bahwa lalu lintas jika terjadi kerugian atau kemacetan saluran memiliki kemampuan untuk dialihkan secara lembut dan menggunakan banyak jalur. Tentunya setelah ini banyak sekali publikasinya, Anda bisa dengan mudah menemukannya.
Meskipun tidak, Anda tidak bisa, karena belum ada satu pun publikasi tentang topik ini. Tapi kami tahu!
Dan jika Anda tidak sepenuhnya memahami apa yang telah dilakukan, saya akan memberi tahu Anda sekarang.
Apa yang telah dilakukan, fungsionalitas apa yang ditambahkan ke kernel Linux? txhash berubah menjadi nilai acak setelah setiap peristiwa RTO. Ini adalah akibat yang sangat negatif dari routing. Hashnya bergantung pada txhash ini, dan label aliran bergantung pada hash skb. Ada beberapa perhitungan fungsi di sini, semua detail tidak bisa ditempatkan dalam satu slide. Jika ada yang penasaran, Anda dapat melihat kode kernel dan memeriksanya.
Apa yang penting di sini? Nilai bidang label aliran berubah menjadi angka acak setelah setiap RTO. Bagaimana pengaruhnya terhadap aliran TCP kita yang malang?
Jika terjadi SACK, tidak ada perubahan karena kami mencoba mengirim ulang paket yang diketahui hilang. Sejauh ini bagus.
Namun dalam kasus RTO, asalkan kita telah menambahkan label aliran ke fungsi hash pada ToR, lalu lintas mungkin mengambil rute yang berbeda. Dan semakin banyak jalur, semakin besar kemungkinan menemukan jalur yang tidak terpengaruh oleh kegagalan pada perangkat tertentu.
Masih ada satu masalah - RTO. Tentu saja, ada rute lain, tetapi banyak waktu yang terbuang untuk itu. 200 ms itu banyak. Sedetik sungguh liar. Sebelumnya, saya berbicara tentang batas waktu layanan yang dikonfigurasi. Jadi, yang kedua adalah batas waktu, yang biasanya dikonfigurasi oleh layanan di tingkat aplikasi, dan dalam hal ini layanan akan relatif tepat. Selain itu, saya ulangi, RTT sebenarnya di dalam pusat data modern adalah sekitar 1 milidetik.
Apa yang dapat Anda lakukan dengan batas waktu RTO? Batas waktu, yang bertanggung jawab atas RTO jika paket data hilang, dapat dikonfigurasi dengan relatif mudah dari ruang pengguna: ada utilitas IP, dan salah satu parameternya berisi rto_min yang sama. Mengingat RTO tentu saja perlu disesuaikan tidak secara global, tetapi untuk awalan tertentu, mekanisme seperti itu tampaknya cukup bisa diterapkan.
Benar, dengan SYN_RTO semuanya menjadi lebih buruk. Secara alami sudah dipastikan. Kernel memiliki nilai tetap 1 detik, dan itu saja. Anda tidak dapat mencapainya dari ruang pengguna. Hanya ada satu cara.
eBPF datang untuk menyelamatkan. Sederhananya, ini adalah program kecil C. Mereka dapat dimasukkan ke dalam kait di tempat berbeda dalam eksekusi tumpukan kernel dan tumpukan TCP, yang dengannya Anda dapat mengubah sejumlah besar pengaturan. Secara umum, eBPF merupakan tren jangka panjang. Alih-alih memotong lusinan parameter sysctl baru dan memperluas utilitas IP, gerakan ini beralih ke eBPF dan memperluas fungsinya. Dengan menggunakan eBPF, Anda dapat mengubah kontrol kemacetan dan berbagai pengaturan TCP lainnya secara dinamis.
Namun penting bagi kami bahwa ini dapat digunakan untuk mengubah nilai SYN_RTO. Selain itu, ada contoh yang diposting secara publik: . Apa yang telah dilakukan di sini? Contohnya berhasil, namun sangat kasar. Di sini diasumsikan bahwa di dalam pusat data kita membandingkan 44 bit pertama; jika cocok, maka kita berada di dalam pusat data. Dan dalam hal ini kita mengubah nilai timeout SYN_RTO menjadi 4ms. Tugas yang sama dapat dilakukan dengan lebih elegan. Namun contoh sederhana ini menunjukkan bahwa hal ini a) mungkin; b) relatif sederhana.
Apa yang sudah kita ketahui? Fakta bahwa arsitektur bidang memungkinkan penskalaan ternyata sangat berguna bagi kita ketika kita mengaktifkan label aliran pada ToR dan mendapatkan kemampuan untuk mengalir di sekitar area masalah. Cara terbaik untuk mengurangi nilai RTO dan SYN-RTO adalah dengan menggunakan program eBPF. Pertanyaannya tetap: apakah aman menggunakan label aliran untuk penyeimbangan? Dan ada nuansa di sini.
Misalkan Anda memiliki layanan di jaringan Anda yang ada di anycast. Sayangnya, saya tidak punya waktu untuk menjelaskan secara detail tentang apa itu anycast, tetapi ini adalah layanan terdistribusi dengan server fisik berbeda yang dapat diakses melalui alamat IP yang sama. Dan inilah kemungkinan masalahnya: peristiwa RTO dapat terjadi tidak hanya ketika lalu lintas melewati fabric. Hal ini juga dapat terjadi pada tingkat buffer ToR: ketika peristiwa incast terjadi, bahkan dapat terjadi pada host ketika host menumpahkan sesuatu. Ketika peristiwa RTO terjadi dan mengubah label aliran. Dalam hal ini, lalu lintas dapat menuju ke instance anycast lainnya. Mari kita asumsikan ini adalah siaran stateful, ini berisi status koneksi - bisa berupa L3 Balancer atau layanan lainnya. Kemudian muncul masalah, karena setelah RTO koneksi TCP tiba di server, yang tidak mengetahui apa pun tentang koneksi TCP ini. Dan jika kita tidak memiliki pembagian status antar server anycast, lalu lintas tersebut akan terputus dan koneksi TCP akan terputus.
Apa yang bisa kamu lakukan di sini? Dalam lingkungan terkendali Anda, tempat Anda mengaktifkan penyeimbangan label aliran, Anda perlu mencatat nilai label aliran saat mengakses server anycast. Cara termudah adalah melakukannya melalui program eBPF yang sama. Namun di sini ada poin yang sangat penting - apa yang harus dilakukan jika Anda tidak mengoperasikan jaringan pusat data, tetapi Anda adalah operator telekomunikasi? Ini juga masalah Anda: dimulai dengan versi Juniper dan Arista tertentu, mereka menyertakan label aliran dalam fungsi hashnya secara default - sejujurnya, untuk alasan yang tidak jelas bagi saya. Hal ini dapat menyebabkan Anda memutuskan koneksi TCP dari pengguna yang melewati jaringan Anda. Jadi saya sangat menyarankan untuk memeriksa pengaturan router Anda di sini.
Dengan satu atau lain cara, menurut saya kita siap untuk melanjutkan ke eksperimen.
Ketika kami mengaktifkan label aliran pada ToR, menyiapkan agen eBPF, yang sekarang ada di host, kami memutuskan untuk tidak menunggu kegagalan besar berikutnya, tetapi melakukan ledakan terkendali. Kami mengambil ToR, yang memiliki empat uplink, dan menyiapkan drop pada salah satunya. Mereka membuat aturan dan berkata - sekarang Anda kehilangan semua paket. Seperti yang Anda lihat di sebelah kiri, kami memiliki pemantauan per paket, yang turun menjadi 75%, yaitu 25% paket hilang. Di sebelah kanan adalah grafik layanan yang berada di balik ToR ini. Pada dasarnya, ini adalah grafik lalu lintas antarmuka dengan server di dalam rak. Seperti yang Anda lihat, mereka tenggelam lebih rendah lagi. Mengapa angkanya turun lebih rendah - bukan sebesar 25%, tetapi dalam beberapa kasus sebanyak 3-4 kali lipat? Jika koneksi TCP kurang beruntung, ia terus mencoba menjangkau melalui persimpangan yang rusak. Hal ini diperburuk oleh perilaku khas layanan di dalam DC - untuk satu permintaan pengguna, N permintaan ke layanan internal dihasilkan, dan respons akan diberikan kepada pengguna baik ketika semua sumber data merespons, atau ketika waktu tunggu aplikasi habis. level, yang masih perlu dikonfigurasi. Artinya, semuanya sangat, sangat buruk.
Sekarang eksperimen yang sama, tetapi dengan nilai label aliran diaktifkan. Seperti yang Anda lihat, di sebelah kiri, pemantauan batch kami turun sebesar 25%. Ini sepenuhnya benar, karena ia tidak mengetahui apa pun tentang transmisi ulang, ia mengirimkan paket dan hanya menghitung rasio jumlah paket yang terkirim dan hilang.
Dan sebelah kanan adalah jadwal pelayanan. Anda tidak akan menemukan efek sendi yang bermasalah di sini. Dalam milidetik yang sama, lalu lintas mengalir dari area masalah ke tiga uplink tersisa yang tidak terpengaruh oleh masalah tersebut. Kami memiliki jaringan yang dapat menyembuhkan dirinya sendiri.
Ini slide terakhir saya, waktunya merangkum. Sekarang, saya harap Anda mengetahui cara membangun jaringan pusat data yang dapat memulihkan diri. Anda tidak perlu membuka arsip kernel Linux dan mencari tambalan khusus di sana; Anda tahu bahwa label Flow dalam hal ini memecahkan masalah, tetapi Anda perlu mendekati mekanisme ini dengan hati-hati. Dan saya tekankan sekali lagi bahwa jika Anda adalah operator telekomunikasi, Anda tidak boleh menggunakan label aliran sebagai fungsi hash, jika tidak, Anda akan mengganggu sesi pengguna Anda.
Insinyur jaringan harus mengalami perubahan konseptual: jaringan dimulai bukan dengan ToR, bukan dengan perangkat jaringan, tetapi dengan host. Contoh yang cukup mencolok adalah bagaimana kami menggunakan eBPF untuk mengubah RTO dan memperbaiki label aliran terhadap layanan siaran apa pun.
Mekanisme label aliran tentu saja cocok untuk aplikasi lain dalam segmen administratif terkendali. Ini bisa berupa lalu lintas antar pusat data, atau Anda dapat menggunakan mekanisme tersebut dengan cara khusus untuk mengatur lalu lintas keluar. Tapi saya akan menceritakan hal ini kepada Anda, saya harap, lain kali. Terima kasih banyak atas perhatiannya.
Sumber: www.habr.com