Kami telah mengembangkan desain jaringan pusat data yang memungkinkan penerapan cluster komputasi yang lebih besar dari 100 ribu server dengan bandwidth pembagian puncak lebih dari satu petabyte per detik.
Dari laporan Dmitry Afanasyev Anda akan belajar tentang prinsip-prinsip dasar desain baru, penskalaan topologi, masalah yang muncul, opsi untuk menyelesaikannya, fitur perutean dan penskalaan fungsi bidang penerusan perangkat jaringan modern dalam “koneksi padat” topologi dengan sejumlah besar rute ECMP. Selain itu, Dima secara singkat berbicara tentang pengorganisasian konektivitas eksternal, lapisan fisik, sistem pengkabelan dan cara untuk lebih meningkatkan kapasitas.
- Selamat sore semuanya! Nama saya Dmitry Afanasyev, saya seorang arsitek jaringan di Yandex dan terutama merancang jaringan pusat data.
Cerita saya tentang jaringan pusat data Yandex yang diperbarui. Ini merupakan evolusi dari desain yang kami miliki, tetapi pada saat yang sama ada beberapa elemen baru. Ini adalah presentasi ikhtisar karena ada banyak informasi yang harus dikemas dalam waktu singkat. Kita akan mulai dengan memilih topologi logis. Kemudian akan ada ikhtisar bidang kendali dan masalah skalabilitas bidang data, pilihan apa yang akan terjadi pada tingkat fisik, dan kita akan melihat beberapa fitur perangkat. Mari kita bahas sedikit tentang apa yang terjadi di pusat data dengan MPLS, yang telah kita bicarakan beberapa waktu lalu.
Jadi, apa itu Yandex dalam hal muatan dan layanan? Yandex adalah tipikal hyperscaler. Jika kami melihat pengguna, kami terutama memproses permintaan pengguna. Juga berbagai layanan streaming dan transfer data, karena kami juga memiliki layanan penyimpanan. Jika lebih dekat ke backend, maka beban infrastruktur dan layanan akan muncul di sana, seperti penyimpanan objek terdistribusi, replikasi data, dan tentu saja antrian persisten. Salah satu jenis beban kerja utama adalah MapReduce dan sistem serupa, pemrosesan aliran, pembelajaran mesin, dll.
Bagaimana infrastruktur tempat semua ini terjadi? Sekali lagi, kita adalah hiperskaler yang cukup umum, meskipun kita mungkin sedikit lebih dekat ke sisi spektrum hiperskaler yang lebih kecil. Tapi kami memiliki semua atributnya. Kami menggunakan perangkat keras komoditas dan penskalaan horizontal jika memungkinkan. Kami memiliki pengumpulan sumber daya penuh: kami tidak bekerja dengan mesin individual, rak individual, tetapi menggabungkannya ke dalam kumpulan besar sumber daya yang dapat dipertukarkan dengan beberapa layanan tambahan yang berhubungan dengan perencanaan dan alokasi, dan bekerja dengan seluruh kumpulan ini.
Jadi kita memiliki level berikutnya - sistem operasi di level cluster komputasi. Sangat penting bagi kita untuk sepenuhnya mengontrol tumpukan teknologi yang kita gunakan. Kami mengontrol titik akhir (host), jaringan, dan tumpukan perangkat lunak.
Kami memiliki beberapa pusat data besar di Rusia dan luar negeri. Mereka dipersatukan oleh tulang punggung yang menggunakan teknologi MPLS. Infrastruktur internal kami hampir seluruhnya dibangun di atas IPv6, tetapi karena kami perlu melayani lalu lintas eksternal yang sebagian besar masih datang melalui IPv4, kami harus mengirimkan permintaan yang datang melalui IPv4 ke server frontend, dan sedikit lagi ke IPv4 eksternal - Internet - untuk misalnya untuk pengindeksan.
Beberapa iterasi terakhir dari desain jaringan pusat data telah menggunakan topologi Clos multi-layer dan hanya L3. Kami meninggalkan L2 beberapa waktu lalu dan menghela nafas lega. Terakhir, infrastruktur kami mencakup ratusan ribu instans komputasi (server). Ukuran cluster maksimal beberapa waktu lalu sekitar 10 ribu server. Hal ini sebagian besar disebabkan oleh cara kerja sistem operasi, penjadwal, alokasi sumber daya, dll. di tingkat cluster yang sama. Karena kemajuan telah terjadi di sisi perangkat lunak infrastruktur, ukuran target sekarang adalah sekitar 100 ribu server dalam satu cluster komputasi, dan Kami mempunyai tugas - untuk dapat membangun pabrik jaringan yang memungkinkan pengumpulan sumber daya yang efisien dalam cluster tersebut.
Apa yang kita inginkan dari jaringan pusat data? Pertama-tama, ada banyak bandwidth yang murah dan terdistribusi cukup merata. Karena jaringan adalah tulang punggung yang melaluinya kita dapat mengumpulkan sumber daya. Target ukuran barunya adalah sekitar 100 ribu server dalam satu cluster.
Tentu saja, kami juga menginginkan bidang kendali yang dapat diskalakan dan stabil, karena pada infrastruktur sebesar itu banyak masalah yang muncul bahkan hanya karena kejadian acak, dan kami tidak ingin bidang kendali tersebut juga membuat kami pusing. Pada saat yang sama, kami ingin meminimalkan keadaan di dalamnya. Semakin kecil kondisinya, semakin baik dan stabil segala sesuatunya bekerja, dan semakin mudah untuk didiagnosis.
Tentu saja, kita memerlukan otomatisasi, karena tidak mungkin mengelola infrastruktur seperti itu secara manual, dan hal ini sudah tidak mungkin dilakukan selama beberapa waktu. Kami memerlukan dukungan operasional semaksimal mungkin dan dukungan CI/CD semaksimal mungkin.
Dengan ukuran pusat data dan klaster sebesar itu, tugas untuk mendukung penerapan dan perluasan bertahap tanpa gangguan layanan menjadi sangat berat. Jika pada kelompok yang berukuran seribu mesin, mungkin hampir sepuluh ribu mesin, mesin tersebut masih dapat digunakan sebagai satu operasi - yaitu, kami merencanakan perluasan infrastruktur, dan beberapa ribu mesin ditambahkan sebagai satu operasi, maka cluster yang berjumlah ratusan ribu mesin tidak serta merta muncul seperti ini, ia dibangun dalam kurun waktu tertentu. Dan diharapkan selama ini apa yang sudah dipompa, infrastruktur yang sudah dikerahkan, harus tersedia.
Dan satu persyaratan yang kami miliki dan tinggalkan: dukungan untuk multitenancy, yaitu virtualisasi atau segmentasi jaringan. Sekarang kami tidak perlu melakukan ini di tingkat jaringan, karena sharding sudah sampai ke host, dan ini membuat penskalaan menjadi sangat mudah bagi kami. Berkat IPv6 dan ruang alamat yang besar, kami tidak perlu menggunakan alamat duplikat di infrastruktur internal; semua pengalamatan sudah unik. Dan berkat fakta bahwa kami telah melakukan pemfilteran dan segmentasi jaringan ke host, kami tidak perlu membuat entitas jaringan virtual apa pun di jaringan pusat data.
Hal yang sangat penting adalah apa yang tidak kita butuhkan. Jika beberapa fungsi dapat dihapus dari jaringan, hal ini membuat hidup lebih mudah, dan, biasanya, memperluas pilihan peralatan dan perangkat lunak yang tersedia, membuat diagnosis menjadi sangat sederhana.
Jadi, apa yang tidak kita perlukan, apa yang sudah bisa kita serahkan, tidak selalu dengan rasa senang saat hal itu terjadi, namun dengan rasa lega yang luar biasa saat prosesnya selesai?
Pertama-tama, meninggalkan L2. Kita tidak membutuhkan L2, baik yang nyata maupun yang ditiru. Tidak digunakan sebagian besar karena kami mengontrol tumpukan aplikasi. Aplikasi kami dapat diskalakan secara horizontal, mereka bekerja dengan pengalamatan L3, mereka tidak terlalu khawatir bahwa beberapa contoh individual telah keluar, mereka cukup meluncurkan yang baru, tidak perlu diluncurkan di alamat lama, karena ada a tingkat penemuan layanan terpisah dan pemantauan mesin yang terletak di cluster. Kami tidak mendelegasikan tugas ini ke jaringan. Tugas jaringan adalah mengirimkan paket dari titik A ke titik B.
Kami juga tidak memiliki situasi di mana alamat berpindah dalam jaringan, dan ini perlu dipantau. Dalam banyak desain, hal ini biasanya diperlukan untuk mendukung mobilitas VM. Kami tidak menggunakan mobilitas mesin virtual di infrastruktur internal Yandex yang besar, dan terlebih lagi, kami percaya bahwa meskipun hal ini dilakukan, hal ini tidak akan terjadi dengan dukungan jaringan. Jika Anda benar-benar perlu melakukan ini, Anda perlu melakukannya di tingkat host, dan mendorong alamat yang dapat bermigrasi ke overlay, agar tidak menyentuh atau membuat terlalu banyak perubahan dinamis pada sistem perutean dari underlay itu sendiri (jaringan transportasi) .
Teknologi lain yang tidak kami gunakan adalah multicast. Jika Anda mau, saya dapat memberi tahu Anda alasannya secara detail. Hal ini membuat hidup lebih mudah, karena jika seseorang telah menanganinya dan melihat seperti apa bidang kontrol multicast, kecuali dalam instalasi yang paling sederhana, ini adalah sakit kepala yang besar. Terlebih lagi, sulit untuk menemukan implementasi open source yang berfungsi dengan baik, misalnya.
Terakhir, kami merancang jaringan kami agar tidak banyak berubah. Kita dapat mengandalkan fakta bahwa aliran kejadian eksternal dalam sistem routing kecil.
Masalah apa yang muncul dan batasan apa yang harus diperhatikan ketika kita mengembangkan jaringan pusat data? Tentu saja biayanya. Skalabilitas, tingkat dimana kita ingin berkembang. Kebutuhan untuk memperluas tanpa menghentikan layanan. Bandwidth, ketersediaan. Visibilitas tentang apa yang terjadi di jaringan untuk sistem pemantauan, untuk tim operasional. Dukungan otomatisasi - sekali lagi, semaksimal mungkin, karena tugas yang berbeda dapat diselesaikan pada tingkat yang berbeda, termasuk pengenalan lapisan tambahan. Ya, tidak [mungkin] bergantung pada vendor. Meski dalam periode sejarah yang berbeda-beda, tergantung bagian mana yang dilihat, kemerdekaan ini lebih mudah atau lebih sulit dicapai. Jika kita mengambil penampang chip perangkat jaringan, maka hingga saat ini sangat bersyarat untuk membicarakan independensi dari vendor, jika kita juga menginginkan chip dengan throughput yang tinggi.
Topologi logis apa yang akan kita gunakan untuk membangun jaringan kita? Ini akan menjadi Clos multi-level. Faktanya, tidak ada alternatif nyata saat ini. Dan topologi Clos sudah cukup baik, bahkan jika dibandingkan dengan berbagai topologi tingkat lanjut yang lebih banyak diminati secara akademis sekarang, jika kita memiliki radix switch yang besar.
Bagaimana struktur jaringan Clos multi-level secara kasar dan apa saja sebutan elemen berbeda di dalamnya? Pertama-tama, angin bertiup, untuk mengorientasikan diri Anda di mana utara, di mana selatan, di mana timur, di mana barat. Jaringan jenis ini biasanya dibangun oleh mereka yang mempunyai trafik barat-timur yang sangat besar. Sedangkan untuk elemen lainnya, di bagian atas terdapat sakelar virtual yang dirangkai dari sakelar yang lebih kecil. Ini adalah ide utama konstruksi jaringan Clos secara rekursif. Kita mengambil elemen dengan beberapa jenis radix dan menghubungkannya sehingga yang kita peroleh dapat dianggap sebagai saklar dengan radix yang lebih besar. Jika Anda membutuhkan lebih banyak lagi, prosedur ini dapat diulangi.
Dalam kasus, misalnya, dengan Clos dua tingkat, ketika komponen vertikal dapat diidentifikasi dengan jelas dalam diagram saya, komponen tersebut biasanya disebut bidang. Jika kita membangun Clos dengan tiga tingkat saklar tulang belakang (yang semuanya bukan saklar batas atau ToR dan hanya digunakan untuk transit), maka bidangnya akan terlihat lebih kompleks; bidang dua tingkat terlihat persis seperti ini. Kami menyebut blok ToR atau saklar daun dan saklar tulang belakang tingkat pertama yang terkait dengannya sebagai Pod. Sakelar tulang belakang tingkat tulang belakang-1 di bagian atas Pod adalah bagian atas Pod, bagian atas Pod. Sakelar yang terletak di bagian atas seluruh pabrik adalah lapisan atas pabrik, Bagian atas kain.
Tentu saja timbul pertanyaan: Jaringan Clos telah dibangun selama beberapa waktu; idenya sendiri umumnya berasal dari zaman telepon klasik, jaringan TDM. Mungkin sesuatu yang lebih baik telah muncul, mungkin ada sesuatu yang bisa dilakukan dengan lebih baik? Iya dan tidak. Secara teori ya, dalam prakteknya dalam waktu dekat pasti tidak. Karena ada beberapa topologi yang menarik, bahkan ada yang digunakan dalam produksi, misalnya Dragonfly digunakan pada aplikasi HPC; Ada juga topologi menarik seperti Xpander, FatClique, Jellyfish. Jika Anda melihat laporan di konferensi seperti SIGCOMM atau NSDI baru-baru ini, Anda dapat menemukan sejumlah besar karya tentang topologi alternatif yang memiliki properti lebih baik (satu atau lainnya) daripada Clos.
Namun semua topologi ini memiliki satu sifat menarik. Hal ini menghalangi penerapannya di jaringan pusat data, yang kami coba bangun di atas perangkat keras komoditas dan memerlukan biaya yang cukup masuk akal. Dalam semua topologi alternatif ini, sayangnya sebagian besar bandwidth tidak dapat diakses melalui jalur terpendek. Oleh karena itu, kita segera kehilangan kesempatan untuk menggunakan bidang kendali tradisional.
Secara teori, solusi dari permasalahan tersebut sudah diketahui. Ini adalah, misalnya, modifikasi status tautan menggunakan jalur terpendek k, tetapi, sekali lagi, tidak ada protokol seperti itu yang akan diterapkan dalam produksi dan tersedia secara luas pada peralatan.
Selain itu, karena sebagian besar kapasitas tidak dapat diakses melalui jalur terpendek, kita perlu memodifikasi lebih dari sekadar bidang kendali untuk memilih semua jalur tersebut (dan omong-omong, ini adalah keadaan yang jauh lebih banyak di bidang kendali). Kita masih perlu memodifikasi bidang penerusan, dan, sebagai aturan, setidaknya diperlukan dua fitur tambahan. Ini adalah kemampuan untuk membuat semua keputusan tentang penerusan paket satu kali, misalnya pada host. Faktanya, ini adalah perutean sumber, terkadang dalam literatur tentang jaringan interkoneksi hal ini disebut keputusan penerusan sekaligus. Dan perutean adaptif adalah fungsi yang kita perlukan pada elemen jaringan, yang intinya, misalnya, pada fakta bahwa kita memilih hop berikutnya berdasarkan informasi tentang beban antrian paling sedikit. Sebagai contoh, opsi lain juga dimungkinkan.
Jadi, arahannya menarik, tapi sayangnya, kami tidak bisa menerapkannya saat ini.
Oke, kita memilih topologi logis Clos. Bagaimana kita mengukurnya? Mari kita lihat cara kerjanya dan apa yang bisa dilakukan.
Dalam jaringan Clos ada dua parameter utama yang dapat kita variasikan dan mendapatkan hasil tertentu: radix elemen dan jumlah level dalam jaringan. Saya memiliki diagram skema tentang bagaimana keduanya mempengaruhi ukuran. Idealnya, kita menggabungkan keduanya.
Dapat dilihat bahwa lebar akhir jaringan Clos adalah hasil kali seluruh tingkat saklar tulang belakang radix selatan, berapa banyak link yang kita miliki, bagaimana percabangannya. Inilah cara kami menskalakan ukuran jaringan.
Mengenai kapasitas, khususnya pada switch ToR, terdapat dua opsi penskalaan. Kita bisa, sambil mempertahankan topologi umum, menggunakan tautan yang lebih cepat, atau kita bisa menambahkan lebih banyak bidang.
Jika Anda melihat versi jaringan Clos yang diperluas (di sudut kanan bawah) dan kembali ke gambar ini dengan jaringan Clos di bawah...
... maka ini adalah topologi yang persis sama, tetapi pada slide ini topologi ini diciutkan lebih kompak dan bidang-bidang pabrik ditumpangkan satu sama lain. Sama.
Seperti apa penskalaan jaringan Clos dalam jumlah? Disini saya memberikan data berapa maksimal lebar jaringan yang bisa kita dapatkan, berapa maksimal jumlah rak, saklar ToR atau saklar daun, jika tidak ada di rak, kita bisa mendapatkannya tergantung pada radix saklar apa yang kita gunakan untuk tingkat tulang belakang, dan berapa level yang kita gunakan.
Berikut adalah jumlah rak yang dapat kita miliki, berapa banyak server, dan kira-kira berapa banyak yang dapat dikonsumsi berdasarkan 20 kW per rak. Sedikit sebelumnya saya sebutkan bahwa kami menargetkan ukuran cluster sekitar 100 ribu server.
Terlihat bahwa dalam keseluruhan desain ini, ada dua setengah pilihan yang menarik. Ada opsi dengan dua lapisan duri dan sakelar 64 port, yang agak kurang. Lalu ada opsi yang sangat cocok untuk sakelar tulang belakang 128-port (dengan radix 128) dengan dua tingkat, atau sakelar dengan radix 32 dengan tiga tingkat. Dan dalam semua kasus, jika terdapat lebih banyak radix dan lebih banyak lapisan, Anda dapat membuat jaringan yang sangat besar, namun jika Anda melihat konsumsi yang diharapkan, biasanya terdapat gigawatt. Pemasangan kabel bisa saja dilakukan, namun kemungkinan besar kita tidak akan mendapatkan listrik sebanyak itu di satu lokasi. Jika Anda melihat statistik dan data publik mengenai pusat data, Anda hanya akan menemukan sedikit sekali pusat data dengan perkiraan kapasitas lebih dari 150 MW. Yang lebih besar biasanya adalah kampus data center, beberapa data center besar letaknya cukup berdekatan satu sama lain.
Ada parameter penting lainnya. Jika Anda melihat kolom kiri, bandwidth yang dapat digunakan tercantum di sana. Sangat mudah untuk melihat bahwa dalam jaringan Clos sebagian besar port digunakan untuk menghubungkan switch satu sama lain. Bandwidth yang dapat digunakan, strip yang berguna, adalah sesuatu yang dapat diberikan ke luar, ke server. Tentu saja, saya berbicara tentang port bersyarat dan khususnya tentang band. Biasanya, tautan dalam jaringan lebih cepat daripada tautan ke server, namun per unit bandwidth, sebanyak yang dapat kami kirimkan ke peralatan server kami, masih ada sejumlah bandwidth di dalam jaringan itu sendiri. Dan semakin banyak level yang kita buat, semakin besar pula biaya spesifik untuk menyediakan garis ini ke luar.
Apalagi band tambahan ini pun tidak bisa dibilang sama persis. Meskipun bentangnya pendek, kita dapat menggunakan sesuatu seperti DAC (kabel tembaga pemasangan langsung, yaitu kabel twinax), atau optik multimode, yang harganya lebih atau kurang masuk akal. Segera setelah kita beralih ke rentang yang lebih panjang, biasanya ini adalah optik mode tunggal, dan biaya bandwidth tambahan ini meningkat secara signifikan.
Dan lagi, kembali ke slide sebelumnya, jika kita membuat jaringan Clos tanpa oversubscription, maka mudah untuk melihat diagram, melihat bagaimana jaringan dibangun - menambahkan setiap tingkat saklar tulang belakang, kita ulangi seluruh strip yang ada di dasar. Level plus - plus band yang sama, jumlah port yang sama pada sakelar seperti pada level sebelumnya, dan jumlah transceiver yang sama. Oleh karena itu, sangat diinginkan untuk meminimalkan jumlah level saklar tulang belakang.
Berdasarkan gambar ini, jelas bahwa kami benar-benar ingin membangun sesuatu seperti saklar dengan radix 128.
Di sini pada prinsipnya semuanya sama seperti yang baru saja saya katakan, ini slide untuk pertimbangan nanti.
Pilihan apa saja yang bisa kita pilih sebagai saklar tersebut? Merupakan kabar baik bagi kami bahwa sekarang jaringan seperti itu akhirnya dapat dibangun pada switch chip tunggal. Dan ini sangat keren, mereka memiliki banyak fitur bagus. Misalnya, mereka hampir tidak memiliki struktur internal. Ini berarti mereka lebih mudah patah. Mereka rusak dalam berbagai cara, tapi untungnya mereka rusak total. Pada perangkat modular terdapat banyak kesalahan (sangat tidak menyenangkan), ketika dari sudut pandang tetangga dan bidang kendali tampaknya berfungsi, tetapi, misalnya, sebagian kain telah hilang dan tidak berfungsi. pada kapasitas penuh. Dan lalu lintas ke sana seimbang berdasarkan fakta bahwa itu berfungsi penuh, dan kita bisa kelebihan beban.
Atau, misalnya, masalah muncul dengan backplane, karena di dalam perangkat modular juga terdapat SerDes berkecepatan tinggi - bagian dalamnya sangat rumit. Entah tanda-tanda antar elemen penerusan tersinkronisasi atau tidak. Secara umum, perangkat modular produktif apa pun yang terdiri dari sejumlah besar elemen, biasanya, berisi jaringan Clos yang sama di dalamnya, tetapi sangat sulit untuk didiagnosis. Seringkali sulit bahkan bagi vendor sendiri untuk mendiagnosis.
Dan ia memiliki sejumlah besar skenario kegagalan di mana perangkat mengalami penurunan, namun tidak sepenuhnya keluar dari topologi. Karena jaringan kami besar, penyeimbangan antara elemen-elemen yang identik digunakan secara aktif, jaringan ini sangat teratur, yaitu, satu jalur di mana segala sesuatunya beres tidak berbeda dengan jalur lainnya, lebih menguntungkan bagi kami jika kehilangan sebagian darinya. perangkat dari topologi daripada berakhir dalam situasi di mana beberapa di antaranya tampak berfungsi, namun beberapa di antaranya tidak.
Fitur bagus berikutnya dari perangkat chip tunggal adalah bahwa mereka berkembang lebih baik dan lebih cepat. Mereka juga cenderung memiliki kapasitas yang lebih baik. Jika kita mengambil struktur rakitan besar yang kita miliki dalam bentuk lingkaran, maka kapasitas per unit rak untuk port dengan kecepatan yang sama hampir dua kali lebih baik dibandingkan perangkat modular. Perangkat yang dibuat dengan satu chip jauh lebih murah dibandingkan perangkat modular dan mengonsumsi lebih sedikit energi.
Tapi, tentu saja, ini semua karena suatu alasan, ada juga kekurangannya. Pertama, radix hampir selalu lebih kecil dibandingkan perangkat modular. Jika kita bisa mendapatkan perangkat yang dibangun berdasarkan satu chip dengan 128 port, maka kita bisa mendapatkan perangkat modular dengan beberapa ratus port sekarang tanpa masalah.
Ini adalah ukuran tabel penerusan yang jauh lebih kecil dan, biasanya, segala sesuatu yang berhubungan dengan skalabilitas bidang data. Buffer dangkal. Dan, sebagai suatu peraturan, fungsinya agak terbatas. Namun ternyata jika Anda mengetahui batasan ini dan berhati-hati untuk melewatinya tepat waktu atau sekadar mempertimbangkannya, hal ini tidak terlalu menakutkan. Fakta bahwa radix lebih kecil tidak lagi menjadi masalah pada perangkat dengan radix 128 yang akhirnya muncul baru-baru ini; kita dapat membuat dua lapisan duri. Namun tetap tidak mungkin membuat sesuatu yang lebih kecil dari dua yang menarik bagi kami. Dengan satu level, diperoleh cluster yang sangat kecil. Bahkan desain dan persyaratan kami sebelumnya masih melebihi mereka.
Faktanya, jika solusinya tiba-tiba berada di ujung tanduk, masih ada cara untuk meningkatkannya. Karena tingkat terakhir (atau pertama), terendah di mana server terhubung adalah sakelar ToR atau sakelar daun, kita tidak perlu menghubungkan satu rak ke server tersebut. Oleh karena itu, jika solusinya gagal sekitar setengahnya, Anda dapat memikirkan untuk menggunakan sakelar dengan radix besar di tingkat bawah dan menghubungkan, misalnya, dua atau tiga rak menjadi satu sakelar. Ini juga merupakan pilihan, ada biayanya, tetapi berfungsi dengan baik dan dapat menjadi solusi yang baik ketika Anda perlu mencapai ukuran dua kali lipat.
Ringkasnya, kami membangun topologi dengan dua tingkat duri, dengan delapan lapisan pabrik.
Apa yang akan terjadi pada fisika? Perhitungan yang sangat sederhana. Jika kita mempunyai dua tingkat duri, maka kita hanya mempunyai tiga tingkat saklar, dan kita perkirakan akan ada tiga segmen kabel dalam jaringan: dari server ke saklar daun, ke tulang belakang 1, ke tulang belakang 2. Pilihan yang kita dapat gunakan adalah - ini adalah twinax, multimode, mode tunggal. Dan di sini kita perlu mempertimbangkan strip apa yang tersedia, berapa biayanya, apa dimensi fisiknya, rentang apa yang bisa kita cakup, dan bagaimana kita akan meningkatkannya.
Dari segi biaya, semuanya bisa diatur. Twinax secara signifikan lebih murah daripada optik aktif, lebih murah daripada transceiver multimode, jika Anda menggunakannya per penerbangan dari ujung, agak lebih murah daripada port switch 100 gigabit. Dan, harap dicatat, biayanya lebih murah daripada optik mode tunggal, karena pada penerbangan yang memerlukan mode tunggal, di pusat data karena sejumlah alasan masuk akal untuk menggunakan CWDM, sedangkan mode tunggal paralel (PSM) sangat tidak nyaman untuk digunakan. dengan, serat diperoleh dalam kemasan yang sangat besar, dan jika kita fokus pada teknologi ini, kita mendapatkan kira-kira hierarki harga berikut.
Satu catatan lagi: sayangnya, sangat tidak mungkin menggunakan port multimode 100 hingga 4x25 yang dibongkar. Karena fitur desain transceiver SFP28, harganya tidak jauh lebih murah daripada 28 Gbit QSFP100. Dan pembongkaran untuk multimode ini tidak berfungsi dengan baik.
Keterbatasan lainnya adalah karena ukuran cluster komputasi dan jumlah server, pusat data kami secara fisik menjadi besar. Artinya setidaknya satu penerbangan harus dilakukan dengan satu mod. Sekali lagi, karena ukuran fisik Pod, tidak mungkin menjalankan dua bentang twinax (kabel tembaga).
Hasilnya, jika kita mengoptimalkan harga dan mempertimbangkan geometri desain ini, kita mendapatkan satu rentang twinax, satu rentang multimode, dan satu rentang singlemode menggunakan CWDM. Ini memperhitungkan kemungkinan jalur peningkatan.
Ini adalah apa yang terlihat akhir-akhir ini, ke mana tujuan kita dan apa yang mungkin terjadi. Setidaknya sudah jelas bagaimana beralih ke SerDes 50 Gigabit untuk multimode dan singlemode. Terlebih lagi, jika Anda melihat apa yang ada di transceiver mode tunggal sekarang dan di masa depan untuk 400G, seringkali bahkan ketika SerDes 50G tiba dari sisi kelistrikan, 100 Gbps per jalur sudah bisa masuk ke optik. Oleh karena itu, besar kemungkinan alih-alih pindah ke 50, akan ada transisi ke 100 Gigabit SerDes dan 100 Gbps per jalur, karena sesuai janji banyak vendor, ketersediaannya diperkirakan akan segera tersedia. Periode ketika 50G SerDes menjadi yang tercepat, tampaknya, tidak akan terlalu lama, karena salinan pertama dari 100G SerDes akan diluncurkan hampir tahun depan. Dan setelah beberapa waktu setelah itu, mereka mungkin akan bernilai uang yang masuk akal.
Satu lagi nuansa tentang pilihan fisika. Prinsipnya kita sudah bisa menggunakan port 400 atau 200 Gigabit menggunakan 50G SerDes. Namun ternyata hal ini tidak terlalu masuk akal, karena seperti yang saya katakan sebelumnya, kita menginginkan radix yang cukup besar pada switch, tentu saja dengan alasan yang masuk akal. Kami ingin 128. Dan jika kami memiliki kapasitas chip yang terbatas dan kami meningkatkan kecepatan tautan, maka radix secara alami menurun, tidak ada keajaiban.
Dan total kapasitasnya bisa kita tingkatkan dengan menggunakan pesawat, dan tidak ada biaya khusus, kita bisa menambah jumlah pesawatnya. Dan jika kita kehilangan radix, kita harus memperkenalkan level tambahan, jadi dalam situasi saat ini, dengan kapasitas maksimum yang tersedia per chip saat ini, ternyata lebih efisien menggunakan port 100 gigabit, karena memungkinkan Anda untuk mendapatkan radix yang lebih besar.
Pertanyaan selanjutnya adalah bagaimana fisika diatur, tetapi dari sudut pandang infrastruktur kabel. Ternyata disusun dengan cara yang agak lucu. Pengkabelan antara saklar daun dan duri tingkat pertama - tidak banyak sambungan di sana, semuanya dibangun dengan relatif sederhana. Tapi kalau kita naik satu pesawat, yang terjadi di dalamnya adalah kita harus menghubungkan semua duri tingkat pertama dengan semua duri tingkat kedua.
Plus, sebagai aturan, ada beberapa keinginan tentang bagaimana tampilannya di dalam pusat data. Misalnya, kami benar-benar ingin menggabungkan kabel ke dalam satu bundel dan menariknya sehingga satu panel patch berdensitas tinggi seluruhnya menjadi satu panel patch, sehingga tidak ada kebun binatang dalam hal panjangnya. Kami berhasil menyelesaikan masalah ini. Jika Anda pertama kali melihat topologi logis, Anda dapat melihat bahwa bidang-bidang itu independen, setiap bidang dapat dibangun sendiri-sendiri. Namun ketika kita menambahkan bundling seperti itu dan ingin menyeret seluruh panel patch ke dalam panel patch, kita harus mencampur bidang yang berbeda di dalam satu bundel dan memperkenalkan struktur perantara dalam bentuk sambungan silang optik untuk mengemasnya kembali dari cara perakitannya. di satu segmen, bagaimana mereka akan dikumpulkan di segmen lain. Berkat ini, kami mendapatkan fitur bagus: seluruh peralihan rumit tidak melampaui rak. Ketika Anda perlu menjalin sesuatu dengan sangat kuat, “buka lipatannya”, seperti yang kadang-kadang disebut dalam jaringan Clos, semuanya terkonsentrasi di dalam satu rak. Kami tidak perlu terlalu membongkar, hingga ke tautan individual, beralih antar rak.
Ini adalah tampilannya dari sudut pandang organisasi logis dari infrastruktur kabel. Pada gambar di sebelah kiri, balok warna-warni menggambarkan balok saklar tulang belakang tingkat pertama, masing-masing delapan buah, dan empat ikat kabel yang berasal darinya, yang menuju dan berpotongan dengan bungkusan yang berasal dari balok saklar tulang belakang-2 .
Kotak kecil menunjukkan persimpangan. Di kiri atas adalah rincian dari setiap persimpangan tersebut, ini sebenarnya adalah modul sambungan silang port 512 x 512 yang mengemas ulang kabel sehingga semuanya menjadi satu rak, di mana hanya ada satu bidang tulang belakang-2. Dan di sebelah kanan, scan gambar ini sedikit lebih detail terkait dengan beberapa Pod di level spine-1, dan bagaimana dikemas dalam cross-connect, bagaimana sampai ke level spine-2.
Seperti inilah tampilannya. Stand spine-2 yang belum dirakit lengkap (di sebelah kiri) dan stand sambung silang. Sayangnya, tidak banyak yang bisa dilihat di sana. Seluruh struktur ini sedang diterapkan di salah satu pusat data besar kami yang sedang diperluas. Ini masih dalam proses, akan terlihat lebih bagus, akan terisi lebih baik.
Sebuah pertanyaan penting: kami memilih topologi logis dan membangun fisika. Apa yang akan terjadi pada bidang kendali? Hal ini cukup diketahui dari pengalaman pengoperasian, ada sejumlah laporan bahwa protokol link state bagus, senang bekerja dengannya, namun sayangnya, protokol tersebut tidak dapat diskalakan dengan baik pada topologi yang terhubung padat. Dan ada satu faktor utama yang mencegah hal ini - ini adalah cara kerja banjir dalam protokol link state. Jika Anda hanya mengambil algoritme banjir dan melihat struktur jaringan kami, Anda dapat melihat bahwa akan ada fanout yang sangat besar di setiap langkah, dan itu hanya akan membanjiri bidang kendali dengan pembaruan. Secara khusus, topologi seperti itu sangat buruk bercampur dengan algoritma banjir tradisional dalam protokol link state.
Pilihannya adalah menggunakan BGP. Cara mempersiapkannya dengan benar dijelaskan di RFC 7938 tentang penggunaan BGP di pusat data besar. Ide dasarnya sederhana: jumlah awalan minimum per host dan umumnya jumlah awalan minimum di jaringan, gunakan agregasi jika memungkinkan, dan hentikan perburuan jalur. Kami menginginkan distribusi pembaruan yang sangat hati-hati dan terkontrol, yang disebut lembah gratis. Kami ingin pembaruan diterapkan tepat satu kali saat melewati jaringan. Jika berasal dari bawah, maka akan naik dan berkembang tidak lebih dari satu kali. Seharusnya tidak ada zigzag. Zigzag sangat buruk.
Untuk melakukan hal ini, kami menggunakan desain yang cukup sederhana untuk menggunakan mekanisme BGP yang mendasarinya. Artinya, kami menggunakan eBGP yang berjalan pada link lokal, dan sistem otonom ditetapkan sebagai berikut: sistem otonom pada ToR, sistem otonom pada seluruh blok saklar spine-1 dari satu Pod, dan sistem otonom umum pada seluruh Top dari Kain. Tidak sulit untuk melihat dan melihat bahwa bahkan perilaku normal BGP memberi kita distribusi pembaruan yang kita inginkan.
Secara alami, pengalamatan dan agregasi alamat harus dirancang sedemikian rupa sehingga kompatibel dengan cara pembuatan rute, sehingga menjamin stabilitas bidang kendali. Pengalamatan L3 dalam transport terikat dengan topologi, karena tanpa ini tidak mungkin mencapai agregasi; tanpa ini, masing-masing alamat akan menyusup ke dalam sistem perutean. Dan satu hal lagi adalah agregasi, sayangnya, tidak tercampur dengan baik dengan multi-jalur, karena ketika kita memiliki multi-jalur dan kita memiliki agregasi, semuanya baik-baik saja, ketika seluruh jaringan sehat, tidak ada kegagalan di dalamnya. Sayangnya, segera setelah kegagalan muncul di jaringan dan simetri topologi hilang, kita dapat sampai pada titik di mana unit tersebut diumumkan, dari mana kita tidak dapat melangkah lebih jauh ke tempat yang kita tuju. Oleh karena itu, yang terbaik adalah menggabungkan jika tidak ada multi-jalur lebih lanjut, dalam kasus kami ini adalah sakelar ToR.
Sebenarnya bisa saja dilakukan agregat, namun hati-hati. Jika kita dapat melakukan disagregasi terkendali ketika terjadi kegagalan jaringan. Namun ini adalah tugas yang cukup sulit, kami bahkan bertanya-tanya apakah hal ini dapat dilakukan, apakah mungkin untuk menambahkan otomatisasi tambahan, dan mesin keadaan terbatas yang akan menjalankan BGP dengan benar untuk mendapatkan perilaku yang diinginkan. Sayangnya, pemrosesan kasus sudut sangat tidak jelas dan rumit, dan tugas ini tidak dapat diselesaikan dengan baik dengan melampirkan lampiran eksternal ke BGP.
Pekerjaan yang sangat menarik dalam hal ini telah dilakukan dalam kerangka protokol RIFT, yang akan dibahas dalam laporan berikutnya.
Hal penting lainnya adalah bagaimana bidang data menskalakan dalam topologi padat, di mana kita memiliki banyak jalur alternatif. Dalam hal ini, beberapa struktur data tambahan digunakan: Grup ECMP, yang selanjutnya menjelaskan grup Hop Berikutnya.
Dalam jaringan yang berfungsi normal, tanpa kegagalan, ketika kita naik topologi Clos, cukup menggunakan satu grup saja, karena segala sesuatu yang bukan lokal dijelaskan secara default, kita bisa naik. Jika kita bergerak dari atas ke bawah ke selatan, maka semua jalur bukanlah ECMP, melainkan jalur jalur tunggal. Semuanya baik-baik saja. Masalahnya, dan kekhasan topologi Clos klasik adalah jika kita melihat Bagian Atas kain, pada elemen mana pun, hanya ada satu jalur ke elemen mana pun di bawahnya. Jika kegagalan terjadi di sepanjang jalur ini, maka elemen khusus di bagian atas pabrik ini menjadi tidak valid justru untuk awalan yang terletak di belakang jalur yang rusak. Namun selebihnya valid, dan kita harus menguraikan kelompok ECMP dan memperkenalkan negara bagian baru.
Seperti apa skalabilitas bidang data pada perangkat modern? Jika kita melakukan LPM (pencocokan awalan terpanjang), semuanya cukup baik, lebih dari 100 ribu awalan. Kalau kita ngomongin grup Next Hop, maka semuanya lebih buruk, 2-4 ribu. Jika kita berbicara tentang tabel yang berisi deskripsi Hop Berikutnya (atau kedekatan), maka ini berkisar antara 16k hingga 64k. Dan ini bisa menjadi masalah. Dan di sini kita sampai pada penyimpangan yang menarik: apa yang terjadi dengan MPLS di pusat data? Pada prinsipnya, kami ingin melakukannya.
Ada dua hal yang terjadi. Kami melakukan segmentasi mikro pada host; kami tidak perlu lagi melakukannya di jaringan. Itu tidak terlalu bagus dengan dukungan dari vendor yang berbeda, dan terlebih lagi dengan implementasi terbuka pada kotak putih dengan MPLS. Dan MPLS, setidaknya implementasi tradisionalnya, sayangnya, memiliki kombinasi yang sangat buruk dengan ECMP. Dan itulah kenapa.
Seperti inilah struktur penerusan ECMP untuk IP. Sejumlah besar awalan dapat menggunakan grup yang sama dan blok Hops Berikutnya yang sama (atau kedekatan, ini mungkin disebut berbeda dalam dokumentasi berbeda untuk perangkat berbeda). Intinya ini digambarkan sebagai port keluar dan apa yang harus ditulis ulang alamat MAC untuk mendapatkan Hop Berikutnya yang benar. Untuk IP semuanya terlihat sederhana, Anda dapat menggunakan awalan dalam jumlah yang sangat besar untuk grup yang sama, blok Next Hops yang sama.
Arsitektur MPLS klasik menyiratkan bahwa, bergantung pada antarmuka keluar, label dapat ditulis ulang ke nilai yang berbeda. Oleh karena itu, kita perlu menyimpan grup dan blok Hop Berikutnya untuk setiap label masukan. Dan ini, sayangnya, tidak berskala.
Sangat mudah untuk melihat bahwa dalam desain kami, kami memerlukan sekitar 4000 sakelar ToR, lebar maksimumnya adalah 64 jalur ECMP, jika kami menjauh dari spine-1 menuju spine-2. Kita hampir tidak bisa masuk ke dalam satu tabel grup ECMP, jika hanya satu awalan dengan ToR yang hilang, dan kita tidak masuk ke tabel Hop Berikutnya sama sekali.
Bukan berarti tidak ada harapan, karena arsitektur seperti Perutean Segmen melibatkan label global. Secara formal, semua blok Next Hops ini bisa diruntuhkan lagi. Untuk melakukan ini, Anda memerlukan operasi tipe wild card: ambil label dan tulis ulang menjadi label yang sama tanpa nilai tertentu. Namun sayangnya, hal ini tidak banyak hadir dalam implementasi yang tersedia.
Dan terakhir, kita perlu membawa lalu lintas eksternal ke pusat data. Bagaimana cara melakukannya? Sebelumnya, lalu lintas dimasukkan ke jaringan Clos dari atas. Artinya, ada router tepi yang terhubung ke semua perangkat di bagian atas fabric. Solusi ini bekerja cukup baik pada ukuran kecil hingga menengah. Sayangnya, untuk mengirimkan trafik secara simetris ke seluruh jaringan dengan cara ini, kita perlu tiba secara bersamaan di semua elemen Top of fabric, dan bila jumlahnya lebih dari seratus, ternyata kita juga membutuhkan yang besar. radix di router tepi. Secara umum, ini membutuhkan biaya, karena router edge lebih fungsional, port di dalamnya akan lebih mahal, dan desainnya tidak terlalu indah.
Pilihan lainnya adalah memulai lalu lintas tersebut dari bawah. Sangat mudah untuk memverifikasi bahwa topologi Clos dibangun sedemikian rupa sehingga lalu lintas yang datang dari bawah, yaitu, dari sisi ToR, didistribusikan secara merata di antara level-level di seluruh Top of fabric dalam dua iterasi, memuat seluruh jaringan. Oleh karena itu, kami memperkenalkan jenis Pod khusus, Edge Pod, yang menyediakan konektivitas eksternal.
Ada satu pilihan lagi. Inilah yang dilakukan Facebook, misalnya. Mereka menyebutnya Fabric Aggregator atau HGRID. Tingkat tulang belakang tambahan sedang diperkenalkan untuk menghubungkan beberapa pusat data. Desain ini dimungkinkan jika kita tidak memiliki fungsi tambahan atau perubahan enkapsulasi pada antarmuka. Kalau itu titik sentuh tambahan, itu sulit. Biasanya, ada lebih banyak fungsi dan semacam membran yang memisahkan berbagai bagian pusat data. Tidak ada gunanya membuat membran seperti itu menjadi besar, tetapi jika itu benar-benar diperlukan karena alasan tertentu, maka masuk akal untuk mempertimbangkan kemungkinan untuk mengambilnya, membuatnya selebar mungkin dan mentransfernya ke inangnya. Hal ini dilakukan, misalnya, oleh banyak operator cloud. Mereka memiliki overlay, mereka mulai dari tuan rumah.
Peluang pengembangan apa yang kita lihat? Pertama-tama, meningkatkan dukungan untuk pipeline CI/CD. Kami ingin terbang dengan cara kami menguji dan menguji cara kami terbang. Hal ini tidak berjalan dengan baik, karena infrastrukturnya besar dan tidak mungkin untuk diduplikasi untuk pengujian. Anda perlu memahami cara memasukkan elemen pengujian ke dalam infrastruktur produksi tanpa menghilangkannya.
Instrumentasi yang lebih baik dan pemantauan yang lebih baik hampir tidak pernah berlebihan. Seluruh pertanyaannya adalah keseimbangan antara usaha dan pengembalian. Jika Anda dapat menambahkannya dengan usaha yang wajar, sangat bagus.
Sistem operasi terbuka untuk perangkat jaringan. Protokol yang lebih baik dan sistem perutean yang lebih baik, seperti RIFT. Penelitian juga diperlukan mengenai penggunaan skema pengendalian kemacetan yang lebih baik dan mungkin pengenalan, setidaknya di beberapa titik, dukungan RDMA dalam cluster.
Melihat lebih jauh ke masa depan, kita memerlukan topologi tingkat lanjut dan mungkin jaringan yang menggunakan lebih sedikit overhead. Dari hal-hal baru, baru-baru ini ada publikasi tentang teknologi fabric untuk HPC Cray Slingshot, yang didasarkan pada komoditas Ethernet, namun dengan opsi untuk menggunakan header yang jauh lebih pendek. Hasilnya, biaya overhead berkurang.
Semuanya harus dibuat sesederhana mungkin, tetapi tidak sederhana. Kompleksitas adalah musuh skalabilitas. Kesederhanaan dan struktur yang teratur adalah teman kami. Jika Anda dapat melakukan perluasan skala di suatu tempat, lakukanlah. Dan secara umum, sangat menyenangkan untuk terlibat dalam teknologi jaringan saat ini. Ada banyak hal menarik yang terjadi. Terima kasih.
Sumber: www.habr.com