Performa rendah baik iSCSI dan AoE

Kami mencari penyimpanan kecepatan resonable. Karena anggaran yang rendah, kami memutuskan untuk menggunakan perangkat lunak iSCSI atau target AoE. Sebelum kami mengubah infrastruktur produksi kami, kami melakukan beberapa tes untuk memilih teknologi terbaik.

Untuk pengujian kami menggunakan:

• Fujitsu Siemens RX200 S4 sebagai target
• Fujitsu Siemens RX200 S4 sebagai inisiator
• NetGear mengelola sakelar 1GBit
• NIC onboard (Broadcom dg TOE), NIC EdiMax, Broadcom NIC dg TOE - semua 1GBit
• server target menggunakan pengontrol QLogic dengan 6 drive 2TB WD Blue SATA.
• sistem operasi target dan inisiator adalah Ubuntu 16.04 LTS dengan semua pembaruan. Switch didedikasikan untuk tujuan penyimpanan. Kami menguji obligasi dan multipathing.

Masalah kami adalah kecepatan baca yang rendah. Untuk pengujian kami menggunakan dddan file 40-100GB.

• baca dan tulis lokal pada server target lebih dari 300MB / s.
• menulis ke server oleh iSCSI atau AoE lebih dari 200MB / s yang memuaskan kami.
• membaca dari server selalu 95-99MB / s.

Kami telah mencoba ietd, aoetools, LIO. Kami telah menggunakan obligasi 2 NIC: balance-rr dan LACP, multipathing dengan rr. Digunakan frame normal dan jumbo. Akhirnya kami bahkan melakukan koneksi ethernet langsung antara target dan host (tidak ada saklar).

Semua tes memberikan hasil yang kurang lebih sama (tentu saja menggunakan NIC umum tanpa TOE dan iSCSI memberi hasil 20-30% lebih buruk).

Jaringan pengujian dengan iperf menunjukkan transfer sekitar 200MB / s (2GBit). Menonton penggunaan NIC pada target dengan bmon menunjukkan pemanfaatan yang sama dari kedua perangkat (masing-masing sekitar 50MB / s untuk membaca, sekitar 100MB / s untuk menulis).

Karena kami tidak beruntung, kami memutuskan untuk menggunakan NIC ketiga (kedua sisi tentu saja). Hasilnya aneh:

• 2 NIC - masing-masing 50MB / s
• 3 NIC - masing-masing 33MB / s

Apakah ada batasan pada perangkat lunak target yang menonaktifkan output lebih tinggi dari 1GBit / s?

Apa yang kita lakukan salah?

Untuk menekan kinerja maksimum dari penyimpanan terhubung iSCSI Anda harus menggunakan Jumbo Frames dan MPIO (bukan LACP). RDMA / iSER direkomendasikan jika Anda dapat melakukannya.

AOE (ATA over Ethernet) sudah tua dan tidak berguna. Kami sudah menyingkirkan Coraid bertahun-tahun yang lalu. Kami menggunakan StarWind https://www.starwindsoftware.com/ sebagai target iSCSI sudah cukup lama dan StarWind meminta kami untuk bermigrasi dari Coraid ke penyimpanan apa pun yang dapat kami lakukan.

Jadi saat ini, kami sangat baik dengan iSCSI yang disediakan oleh StarWind dan menggunakan Windows, ESX dan SCST http://scst.sourceforge.net/ di Linux sebagai inisiator. Dengan RDMA / iSER, ia dapat mencapai 10 Gbit, sangat senang sejauh ini.

Harapan Anda tentang cara kerja agregasi tautan Ethernet tidak benar.

Semua metode agregasi selain balance-rr (yaitu: semua metode yang modenya> 0) tidak memberi Anda throughput koneksi tunggal yang lebih besar; melainkan, mereka meningkatkan total bandwidth yang tersedia ketika beberapa koneksi dibuat dari / ke host yang terpengaruh. Dengan kata lain, LAG / LACP tidak akan memberi Anda manfaat apa pun untuk skenario satu koneksi ini.

Satu-satunya metode agregasi yang dapat memberi Anda throughput satu sesi lebih besar dari apa yang biasanya Anda miliki pada satu antarmuka adalah balance-rr , yang mendistribusikan paket-paket dengan cara round-robin. Anda harus mengatur keseimbangan-rr di kedua inisiator dan target. Namun tangkapan besar adalah bahwa ini sebagian besar bergantung pada saklar.

Pokoknya, jika Anda menetapkan target dan inisiator ke balance-rr, menghubungkan kedua mesin secara langsung akan memberi Anda peningkatan kinerja. Jika tidak, dapatkah Anda memposting iperfdengan balance-rr dan kedua mesin terhubung langsung (tanpa sakelar)? Juga, silakan kirim ddperintah tepat yang Anda gunakan untuk pembandingan.

Catatan: Saya hanya berbicara tentang iSCSI di sini. Saya tidak punya pengalaman dengan AoE selain membacanya, dan saya tidak akan mengimplementasikannya dalam infrastruktur baru apa pun (itu cukup banyak mati).

Jangan gunakan balance-rr untuk apa pun selain beberapa protokol point-to-point yang sangat spesifik. Ini memiliki kinerja yang mengerikan ketika di bawah hampir semua jenis beban dunia nyata, dan menyebabkan banyak masalah jaringan (seperti BANYAK jitter). Pasti tidak menggunakannya dengan sakelar.

Gunakan MPIO tanpa ikatan di sisi inisiator untuk mencapai keseimbangan beban dan toleransi kesalahan. Untuk memastikan bahwa jalur Anda tidak "tercampur aduk" dengan mengirimkan semua lalu lintas Anda ke satu jalur, letakkan masing-masing jalur (NIC gigabit antara target dan penggagas, dalam kasus Anda) pada subnet yang terpisah.

Jangan ragu untuk mengikat sisi target dengan LACP per jalur (seperti pada dua ikatan untuk dua jalur dengan total empat NIC, sebagai contoh konfigurasi port target). Ini berfungsi dengan baik, dan dapat menyeimbangkan beberapa koneksi penggagas yang menggunakan jalur yang sama. Juga gunakan frame jumbo dan iSER jika memungkinkan. Menggunakan LACP pada target akan menyeimbangkan koneksi ke setiap jalur di antara beberapa NIC.

Menggunakan LACP pada inisiator hanya akan efektif jika membuat banyak koneksi portal target dengan penggunaan simultan (tidak umum untuk hampir semua beban kerja). Bahkan jika Anda menerapkan LACP per jalur secara efektif pada inisiator, dengan cepat akan menjadi mimpi buruk pemasangan kabel untuk menggunakan (misalnya) empat kain tambahan untuk setiap kotak. Jika Anda membutuhkan lebih dari ~ 2Gib / s throughput ke satu inisiator, pertimbangkan 10GiB / s ethernet.

Sebagian besar tanggapan pada AoE benar-benar salah, kontrafaktual, dan menunjukkan kurangnya pengetahuan dan pengalaman AoE. Pertama, itu tidak mati. CORAID adalah vendor di belakang AoE dan mereka memulai kembali sebagai "SouthSuite" sambil mempertahankan merek dagang CORAID. Mereka adalah pengembang yang sama juga. Mereka membuat produk baru dan mendukung sebagian besar produk lama. Mereka mendorong pengembangan AoE ke depan juga, seperti yang ditunjukkan oleh milis teknis terbuka. Periksa situs webnya, semuanya terbaru dan ceritakan seluruh kisahnya di halaman sejarah mereka.

Seseorang mengatakan AoE tidak akan mendapat manfaat dari frame jumbo dan juga salah datar. Itu didukung setelah versi 13 dari 'vbladed' dirilis. Anda perlu menyetel MTU Anda untuk mendukung ukuran bingkai baru, tetapi jika tidak, berfungsi dengan baik.

iSCSI berjalan pada layer-5 dari model OSI. Transport yang biasa digunakan adalah TCP. Itu memberi Anda beberapa koreksi kesalahan (karena checksum dalam TCP) dan memungkinkan Anda untuk merutekan lalu lintas melalui IP pada layer-3. Di situlah keunggulan iSCSI berhenti. Kinerja dunia nyata benar-benar mengerikan ketika Anda benar-benar membandingkannya dengan sesuatu seperti FCP, AoE, atau FCoE. Saya akan mengundang Anda ke google "perbandingan kinerja iscsi" untuk acara horor.

Masalah kecepatan baca Anda mungkin disebabkan oleh kesalahan konfigurasi jaringan, matikan kontrol aliran dan pastikan Anda menggunakan buffer soket yang cukup besar. Anda juga tidak menyebutkan apakah sistem file yang mendasarinya telah disetel untuk read-prefetching atau tidak. Berdasarkan skenario Anda, itu bisa banyak membantu Anda, tetapi berhati-hatilah untuk tidak menggunakannya dengan database tertentu yang meminta caching dinonaktifkan.

Agregasi 802.3ad tidak akan terlalu meningkatkan throughput aliran tunggal Anda, bahkan dalam skenario round-robin. Ini juga akan memperumit konfigurasi jaringan Anda dan memberi Anda beberapa peluang baru untuk menembak diri sendiri dengan mencocokkan interval PDU atau salah mengkonfigurasi tautan Cisco VPC Anda untuk mendukung status aktif-aktif. Jangan gunakan LACP dengan AoE, biarkan itu menangani multipathing dan multiplexing itu sendiri. Versi AoE yang lebih baru menangani hal ini dengan indah, dan dalam banyak kasus lebih anggun daripada FCP karena semuanya otomatis. Port Ethernet tambahan memberi Anda lebih banyak bandwidth dan ketahanan lebih. Jika Anda menyebarkan port host & inisiator Ethernet melalui beberapa switch, hal itu dapat memberikan redundansi lebih banyak lagi. Tidak perlu mengkonfigurasi mode ikatan. Juga, jangan jalankan IP pada antarmuka yang sama yang Anda gunakan untuk AoE.

Singkatnya, jangan mendengarkan penentang AoE, mereka terdengar mereka tidak memiliki banyak pengalaman dan hanya mengendarai gelombang otak trendi. Jauhi kawanan. Pergi konfigurasikan toko dukungan dengan prefetch yang disetel dengan tangan dan Anda mungkin akan melihat throughput baca Anda naik. Jatuhkan penggunaan protokol agregasi dan jalankan screaming dari iSCSI. Satu hal lagi, berhenti menggunakan 'dd' itu bukan tes yang bagus dan terkena efek caching yang buruk. Gunakan alat benchmark nyata seperti 'fio', 'iozone', atau 'dbench'. Itu memberikan hasil yang jauh lebih andal.

Saya tahu LACP untuk beberapa koneksi. Mengujinya adalah tindakan putus asa :)

Semua tes dilakukan dengan keseimbangan-rr dan dua NIC.

Menulis ke target iSCSI:
dd if = / dev / zero of = / mnt / zero.bin bs = 1M hitung = 2000
2000 + 0 przeczytanych recordów
2000 + 0 zapisanych recordów
2097152000 byte (2,1 GB, 2,0 GiB) disalin , 10,1093 s, 207 MB / s

Membaca dari target iSCSI:
dd if = / mnt / zero.bin dari = / dev / null bs = 1M
2000 + 0 przeczytanych recordów
2000 + 0 zapisanych recordów
2097152000 bytes (2,1 GB , 2,0 GiB) disalin, 16,1684 s, 130 MB / s

Kecepatan jaringan:
iperf -c 172.16.10.80
------------------------ ------------------------------------
Klien terhubung ke 172.16.10.80, TCP port 5001
ukuran jendela TCP: 325 KByte (default)
--------------------------------------------- ---------------
[3] port lokal 172.16.10.70 37024 terhubung dengan port 172.16.10.80 5001
[ID] Interval Transfer Bandwidth
[3] 0.0-10.0 dtk 2.30 GBytes 1.98 Gbits / dt.

Menguji dengan iperf dan jumbo frames memberikan hasil yang sama.

Saya telah mendapatkan beberapa kecepatan membaca dengan menjalankan inisiator:
hdparm -a 2048 / dev / dm-1
Sebelumnya adalah 256 dan kecepatan membaca 96MB / s
Tujuan saya adalah mencapai kecepatan membaca sekitar 200MB / s.

EDIT:
1. Kami tidak menggunakan LACP - itu adalah tes satu kali.
2. Pengujian dengan balance-rr dan MPIO memberikan hasil yang persis sama. Multipathing diuji dengan NIC di subnet yang berbeda.
3. Menambahkan lebih banyak NIC tidak meningkatkan kecepatan membaca, tetapi hanya mengurangi pemanfaatan setiap NIC.
4. Kami pikir masalahnya adalah beberapa batasan (driver, modul?) Yang tidak memungkinkan untuk membaca lebih cepat. Tetapi saya tidak yakin, apakah itu target atau pihak inisiator.


EDIT 2: Baru saja melakukan beberapa tes tambahan: mengkonfigurasi host yang sama sebagai target dan penggagas untuk menyingkirkan masalah perangkat keras jaringan. Saya terkejut: kecepatan membaca persis sama! 130 MB / s! Menulis adalah 227 MB / s.

bagaimana Anda telah mengkonfigurasi nic Anda adalah semua buffer diatur dengan benar, sudahkah Anda mengalokasikan ram yang cukup untuk buffer jaringan. juga tidak menggunakan ikatan di sini Anda dapat menggunakan 2 saluran iscsi dan mengalikannya di inisiator, sama dengan ATAoE inisiator multipath melalui rak dan lun ID di jalur apa pun.