Agregasi tautan FreeBSD tidak lebih cepat dari tautan tunggal

Kami menempatkan 4 port Intel I340-T4 NIC di FreeBSD 9.3 Server ¹ dan dikonfigurasi untuk agregasi link di modus LACP dalam upaya untuk mengurangi waktu yang dibutuhkan untuk cermin 8 sampai 16 TiB data dari file server master untuk 2- 4 klon secara paralel. Kami mengharapkan untuk mendapatkan bandwidth agregat hingga 4 Gbit / detik, tetapi apa pun yang kami coba, bandwidth tidak pernah keluar lebih cepat dari agregat 1 Gbit / detik. ²

Kami menggunakan iperf3untuk menguji ini pada LAN yang diam. ³ Contoh pertama hampir mencapai satu gigabit, seperti yang diharapkan, tetapi ketika kita memulai yang kedua secara paralel, kedua klien menurun kecepatannya menjadi kira-kira ½ Gbit / detik. Menambahkan klien ketiga menurunkan kecepatan ketiga klien ke ~ ⅓ Gbit / detik, dan seterusnya.

Kami telah berhati-hati dalam menyiapkan iperf3pengujian yang lalu lintas dari keempat klien pengujian masuk ke sakelar sentral pada port yang berbeda:

Kami telah memverifikasi bahwa setiap mesin uji memiliki jalur independen kembali ke sakelar rak dan bahwa server file, NIC-nya, dan sakelar semuanya memiliki bandwidth untuk melakukan hal ini dengan memecah lagg0grup dan menetapkan alamat IP terpisah untuk masing-masing dari empat antarmuka pada kartu jaringan Intel ini. Dalam konfigurasi itu, kami mencapai ~ 4 Gbit / detik bandwidth agregat.

Ketika kami mulai menyusuri jalan ini, kami melakukan ini dengan saklar dikelola SMC8024L2 tua . (Lembar data PDF, 1,3 MB.) Itu bukan saklar kelas atas pada zamannya, tetapi itu seharusnya dapat melakukan ini. Kami pikir peralihan mungkin salah, karena usianya, tetapi memutakhirkan ke HP 2530-24G yang jauh lebih mampu tidak mengubah gejalanya.

Saklar HP 2530-24G mengklaim keempat port yang dimaksud memang dikonfigurasikan sebagai batang LACP dinamis:

# show trunks
Load Balancing Method:  L3-based (default)

  Port | Name                             Type      | Group Type    
  ---- + -------------------------------- --------- + ----- --------
  1    | Bart trunk 1                     100/1000T | Dyn1  LACP    
  3    | Bart trunk 2                     100/1000T | Dyn1  LACP    
  5    | Bart trunk 3                     100/1000T | Dyn1  LACP    
  7    | Bart trunk 4                     100/1000T | Dyn1  LACP    

Kami telah mencoba LACP pasif dan aktif.

Kami telah memverifikasi bahwa keempat port NIC mendapatkan lalu lintas di sisi FreeBSD dengan:

$ sudo tshark -n -i igb$n

Anehnya, tsharkmenunjukkan bahwa dalam kasus hanya satu klien, saklar membagi aliran 1 Gbit / detik melalui dua port, tampaknya melakukan ping-pong di antara mereka. (Sakelar SMC dan HP menunjukkan perilaku ini.)

Karena bandwidth agregat klien hanya berkumpul di satu tempat - pada switch di rak server - hanya switch yang dikonfigurasi untuk LACP.

Tidak masalah klien mana yang kita mulai pertama, atau urutan yang kita mulai.

ifconfig lagg0 di sisi FreeBSD mengatakan:

lagg0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=401bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,VLAN_HWTSO>
    ether 90:e2:ba:7b:0b:38
    inet 10.0.0.2 netmask 0xffffff00 broadcast 10.0.0.255
    inet6 fe80::92e2:baff:fe7b:b38%lagg0 prefixlen 64 scopeid 0xa 
    nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
    media: Ethernet autoselect
    status: active
    laggproto lacp lagghash l2,l3,l4
    laggport: igb3 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING>
    laggport: igb2 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING>
    laggport: igb1 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING>
    laggport: igb0 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING>

Kami telah menerapkan sebanyak mungkin saran dalam panduan penyetelan jaringan FreeBSD yang masuk akal untuk situasi kami. (Sebagian besar tidak relevan, seperti hal-hal tentang peningkatan FD maks.)

Kami telah mencoba mematikan pemuatan segmentasi TCP , tanpa perubahan hasil.

Kami tidak memiliki NIC server 4-port kedua untuk menyiapkan tes kedua. Karena pengujian yang sukses dengan 4 antarmuka yang terpisah, kita akan asumsi bahwa tidak ada perangkat keras yang rusak. ³

Kami melihat jalur ini ke depan, tidak ada yang menarik:

1. Beli switch yang lebih besar, lebih buruk, berharap bahwa implementasi LACP SMC hanya menyebalkan, dan bahwa switch baru akan lebih baik. (Melakukan upgrade ke HP 2530-24G tidak membantu.)

2. Menatap laggkonfigurasi FreeBSD lagi, berharap kami melewatkan sesuatu. ⁴

3. Lupakan agregasi tautan dan gunakan DNS round-robin untuk melakukan penyeimbangan beban.

4. Ganti NIC server dan ganti lagi, kali ini dengan 10 GigE stuff, sekitar 4 × biaya perangkat keras dari percobaan LACP ini.

Catatan kaki

1. Mengapa tidak pindah ke FreeBSD 10, Anda bertanya? Karena FreeBSD 10.0-RELEASE masih menggunakan ZFS pool versi 28, dan server ini telah ditingkatkan ke ZFS pool 5000, fitur baru di FreeBSD 9.3. Garis 10. x tidak akan mendapatkan itu sampai FreeBSD 10.1 dikirimkan sekitar sebulan karenanya . Dan tidak, membangun kembali dari sumber untuk mendapatkan sisi pendarahan 10.0-STABLE bukan pilihan, karena ini adalah server produksi.

2. Tolong jangan langsung menyimpulkan. Hasil pengujian kami nanti dalam pertanyaan memberi tahu Anda mengapa ini bukan duplikat dari pertanyaan ini .

3. iperf3adalah tes jaringan murni. Sementara tujuan akhirnya adalah untuk mencoba dan mengisi pipa agregat 4 Gbit / detik dari disk, kami belum melibatkan subsistem disk.

4. Buggy atau dirancang dengan buruk, mungkin, tetapi tidak lebih rusak daripada ketika meninggalkan pabrik.

5. Saya sudah juling melakukan itu.

Apa algoritma penyeimbangan beban yang digunakan pada sistem dan sakelar?

Semua pengalaman saya dengan ini adalah di Linux dan Cisco, bukan FreeBSD dan SMC, tetapi teori yang sama masih berlaku.

Mode load balancing default pada mode LACP driver ikatan Linux, dan pada switch Cisco yang lebih lama seperti 2950, ​​adalah untuk menyeimbangkan berdasarkan alamat MAC saja.

Ini berarti jika semua traffic Anda berpindah dari satu sistem (file server) ke satu MAC lainnya (baik gateway default atau Switched Virtual Interface pada switch) maka MAC sumber dan tujuan akan sama, sehingga hanya satu budak yang akan pernah digunakan.

Dari diagram Anda, sepertinya Anda tidak mengirimkan lalu lintas ke gateway default, tetapi saya tidak yakin apakah server uji berada di 10.0.0.0/24, atau jika sistem pengujian berada di subnet lain dan dialihkan melalui antarmuka Layer 3 pada sakelar.

Jika Anda merutekan sakelar, ada jawaban Anda.

Solusi untuk ini adalah dengan menggunakan algoritma load balancing yang berbeda.

Sekali lagi saya tidak punya pengalaman dengan BSD atau SMC, tetapi Linux dan Cisco dapat menyeimbangkan berdasarkan informasi L3 (alamat IP) atau informasi L4 (nomor port).

Karena setiap sistem pengujian Anda harus memiliki IP yang berbeda, cobalah menyeimbangkan berdasarkan informasi L3. Jika itu masih tidak berhasil, ubah beberapa IP di sekitar dan lihat apakah Anda mengubah pola penyeimbangan beban.