Dilema SDN: Rangkaian kernel Linux vs pintasan kernel

Sujal Das adalah ketua strategi dan pegawai pemasaran di Netronome, penyedia penyelesaian pemprosesan bersama x86 berprestasi tinggi untuk rangkaian, keselamatan, pengimbangan beban, virtualisasi, dan SDN.

Sekiranya kita telah mempelajari apa-apa dalam perniagaan teknologi dalam 25 tahun kebelakangan ini, kita tidak boleh memandang rendah kernel Linux. Oleh itu, mengapa begitu banyak syarikat rangkaian begitu bersemangat untuk memintas kernel Linux - atau lebih khusus lagi, tumpukan rangkaian kernel Linux? Apa yang mungkin salah dengan arteri paket rangkaian di kernel Linux yang mendorong begitu banyak daripada kita untuk memintasnya?

Terdapat dua sebab utama. Pertama, timbunan rangkaian kernel terlalu perlahan - dan masalahnya hanya bertambah buruk dengan penggunaan rangkaian berkelajuan tinggi dalam pelayan dan suis (10GbE, 25GbE, dan 40GbE hari ini, dan meningkat menjadi 50GbE dan 100GbE dalam masa terdekat) . Kedua, pengendalian rangkaian di luar kernel memungkinkan untuk memasukkan teknologi baru tanpa perlu mengubah kod inti Linux inti.

Atas dua sebab tersebut, dan dengan kelebihan tambahan bahawa banyak teknologi pintasan kernel adalah sumber terbuka dan / atau ditentukan oleh badan standard, penyokong penyelesaian pintasan terus mendorong operator pusat data untuk menggunakannya.

Penyelesaian pintasan kernel

Kami telah melihat banyak penyelesaian pintasan kernel pada masa lalu, terutama RDMA (Remote Direct Memory Access), TOE (TCP Offload Engine), dan OpenOnload. Baru-baru ini, DPDK (Data Plane Development Kit) telah digunakan dalam beberapa aplikasi untuk memotong kernel, dan kemudian ada inisiatif baru yang muncul seperti FD.io (Fast Data Input Output) berdasarkan VPP (Vector Packet Processing). Lebih banyak kemungkinan akan muncul pada masa akan datang.

Teknologi seperti RDMA dan TOE membuat timbunan selari di kernel dan menyelesaikan masalah pertama (iaitu, "kernel terlalu lambat") sementara OpenOnload, DPDK dan FD.io (berdasarkan VPP) memindahkan rangkaian ke ruang pengguna Linux untuk menangani kedua-duanya keperluan pemantauan kelajuan dan teknologi. Ketika teknologi dibangun di ruang pengguna Linux, kebutuhan untuk perubahan kernel dihindari, menghilangkan upaya ekstra yang diperlukan untuk meyakinkan masyarakat kernel Linux tentang kegunaan teknologi bypass dan penggunaannya melalui hulu ke kernel Linux.

Netronome

Cabaran pintasan kernel

Tantangan yang berkaitan dengan penggunaan tumpukan paralel di luar tumpukan rangkaian kernel jelas bagi pengendali pusat data yang ditantang dengan meningkatkan infrastruktur mereka ke sebilangan besar pelayan. Dengan timbunan rangkaian selari terdapat senarai keselamatan, pengurusan, kekukuhan, penguncian vendor perkakasan, dan masalah keserasian protokol yang nampaknya tidak berkesudahan.

Sebagai contoh, terdapat implementasi Open vSwitch dan OpenContrail yang menggunakan DPDK sebagai pendekatan bypass kernel. Pelaksanaan DPDK dibatasi dalam dua cara. Pertama, sukar dan kadang-kadang mustahil untuk berkembang dengan cepat dan sesuai dengan inovasi perisian sumber terbuka berasaskan kernel. Kedua, walaupun tingkat kinerja dan keamanan yang diperlukan oleh VM dan aplikasi dapat disampaikan, ia memerlukan sejumlah besar core CPU x86, yang mengurangkan keseluruhan kecekapan infrastruktur pusat data.

Walaupun begitu, sebilangan pengendali pusat data yang mungkin mempunyai beberapa ratus pelayan untuk dikendalikan dan menjalankan satu aplikasi, seperti kluster High Performance Computing atau High Frequency Trading, mungkin praktikal untuk menggunakan tumpukan pintasan kernel selari seperti itu. Perkara yang sama berlaku untuk kelompok penyimpanan khusus.

Tetapi dapatkah penyumbatan tumpukan jaringan kernel dapat diperbaiki tanpa menggunakan tumpukan pintasan selari? Ya ia boleh. Cara yang tepat untuk menyelesaikan dua masalah di atas adalah dengan mencari cara untuk mempercepat prestasi susunan rangkaian kernel secara telus, menggunakan perkakasan rangkaian pintar, dan tanpa ada penguncian vendor.

SmartNIC berusaha menyelesaikan masalah ini tanpa memotong kernel. SmartNIC adalah NICS (kad antara muka rangkaian) yang dapat diprogramkan, yang memungkinkan vendor yang menyediakan produk tersebut untuk menginovasikan perkakasan rangkaian pelayan pada kelajuan perisian - keperluan praktikal dalam infrastruktur pusat data yang didefinisikan oleh perisian moden dan NFV.

Masukkan SmartNICS

Netronome SmartNIC menyediakan ciri asas atau tradisional NIC dan ciri canggih yang diperlukan oleh pusat data awan dan penyedia perkhidmatan telco. Ciri-ciri canggih ini meliputi kemampuan untuk memuatkan fungsi rangkaian yang kaya, seperti yang disediakan oleh suis maya dan penghala maya yang digunakan dalam lingkungan rangkaian yang ditentukan oleh perisian dan pelayan komputer yang dioptimumkan NFV. Keupayaan untuk memuat fungsi rangkaian intensif komputasi ini ke SmartNIC membawa tahap prestasi dan keselamatan yang lebih tinggi kepada VM, meningkatkan jumlah aplikasi yang dapat disampaikan per pelayan, dan memberikan peningkatan keseluruhan dalam efisiensi pusat data. Ciri-ciri SmartNIC dapat berkembang pesat dengan inovasi rangkaian sumber terbuka, seperti dengan Open vSwitch, OpenStack, OpenContrail, dan eBPF projek IO Visor (Extended Berkeley Packet Filter).

Keuntungan menggunakan SmartNIC tidak terhad kepada peningkatan prestasi dan set ciri yang lebih kaya. Terdapat juga penjimatan TCO yang ketara, kerana SmartNIC dapat menggantikan NIC tradisional yang digunakan dalam pelayan. SmartNIC dihargai secara kompetitif kepada NIC tradisional dan memberikan penjimatan yang besar dengan membebaskan sumber CPU pelayan yang berharga untuk VM dan aplikasi, meningkatkan kecekapan pelayan. Memandangkan pelayan menggunakan sebanyak 60 peratus daripada jumlah kos infrastruktur pusat data, kemampuan untuk menyokong beban kerja yang lebih besar bagi setiap pelayan menggunakan SmartNIC menjanjikan penjimatan yang besar.

Penyokong pintasan Kernel ingin berpendapat bahawa prestasi rangkaian pelayan yang diperlukan dalam aplikasi SDN dan NFV dapat dicapai dengan menggunakan teras CPU x86 berprestasi tinggi, dan oleh itu NIC tradisional adalah semua yang diperlukan. Tetapi dalam penanda aras praktikal dan dalam kehidupan nyata, mekanisme pintasan kernel mungkin memerlukan sebanyak 24 teras CPU untuk mendapatkan prestasi rangkaian yang diperlukan. Itu praktikal memakan seluruh pelayan untuk rangkaian sahaja.

Vendor SmartNIC setuju sepenuhnya bahawa prestasi rangkaian kernel adalah masalah sebenar yang hanya akan bertambah buruk apabila pengendali membina pusat data untuk memenuhi permintaan bilangan peranti mudah alih dan IoT yang semakin meningkat. Tetapi mereka tidak percaya bahawa memintas kernel sistem operasi menyelesaikan masalahnya. Sebaliknya, tugas pemprosesan rangkaian yang intensif dalam timbunan rangkaian kernel Linux perlu diturunkan ke SmartNIC dengan cara agnostik vendor, dan bukannya menggunakan implementasi yang menghasilkan tumpukan rangkaian yang berlebihan secara selari.

SmartNIC menangani cabaran ini, memuat implementasi jalur data rangkaian berasaskan kernel yang tersedia hari ini dan berkembang pesat dalam komuniti sumber terbuka Linux yang lebih luas. Teknologi stack kernel Linux seperti eBPF dan Traffic Classifier menepati janji untuk membenarkan vendor SmartNIC seperti Netronome berpegang pada stack rangkaian kernel Linux dan membolehkan pengendali pusat data membuat skala dengan cekap.

Saranan yang sangat baik dari komuniti Linux adalah untuk mengelakkan pintasan kernel. Seperti semua idea asas dan sederhana, idea ini telah berlaku pada masa lalu, berlaku hingga kini, dan akan tetap berlaku di masa hadapan.

Forum Teknologi Baru menyediakan tempat untuk meneroka dan membincangkan teknologi perusahaan yang baru muncul dalam kedalaman dan luas yang belum pernah terjadi sebelumnya. Pemilihannya bersifat subjektif, berdasarkan pilihan teknologi yang kami percayai penting dan menarik minat pembaca. tidak menerima jaminan pemasaran untuk penerbitan dan berhak untuk mengedit semua kandungan yang disumbangkan. Hantarkan semua pertanyaan ke [email protected]