Saya ingin mengetahui konfigurasi / perangkat keras terbaik untuk memberikan 40Gbps dari satu server dalam pertanyaan ini.

Situasi

Kami memiliki server proxy berbagi video yang mengeluarkan puncak dari server penyimpanan lambat di belakangnya. Semua lalu lintas hanya HTTP. Server bertindak sebagai proksi terbalik (file yang tidak di-cache di server) dan server web (file yang disimpan di drive lokal).

Saat ini ada sesuatu seperti 100TB file dan tumbuh di server penyimpanan backend.

Mekanisme caching diimplementasikan secara independen dan pertanyaan ini bukan tentang caching itu sendiri karena berfungsi dengan sangat baik - saat ini memberikan 14Gbps, lolos ke server backend hanya 2Gbps. Jadi penggunaan cache bagus.

Tujuan

Mencapai 40Gbps atau bahkan lebih banyak throughput dari satu mesin.

Perangkat Keras 1

HW: Supermicro SC825, X11SSL-F, Xeon E3-1230v5 (4C/8T@3.4GHz), RAM DDR4 16GB, 2x Supermicro 10G STGN-i1S (LACP L3 + 4)

SSD: Samsung 1x 512GB, Samsung 2x500 GB, Intel 535 2x480GB, Intel S3500 1x 240GB

Sistem:

• irqbalancer berhenti
• set_irq_affinity untuk setiap antarmuka (melalui skrip di tarball driver ixgbe)
• ixgbe-4.3.15
• Batas waktu penjadwal I / O
• iptables kosong (modul tidak dimuat)
• Sistem File: XFS

Nginx:

• lepas sendfile
• utas aio
• directio 1 jt
• tcp_nopush aktif
• tcp_nodelay aktif

Seperti yang terlihat pada grafik, kami dapat mendorong 12,5Gbps. Sayangnya server tidak responsif.

Ada 2 hal yang menarik perhatian saya. Yang pertama adalah jumlah IRQ yang tinggi. Dalam hal ini saya sayangnya tidak memiliki grafik dari / proc / interupsi. Yang kedua adalah beban sistem yang tinggi, yang saya pikir disebabkan oleh kswapd0 mengalami masalah untuk bekerja dengan 16G RAM saja.

Perangkat keras 2

HW: Supermicro SC119TQ, X10DRW-i, 2x Xeon E5-2609v4 (8C/8T@1.70GHz), RAM DDR4 128GB, 2x Supermicro 10G STGN-i1S

SSD, Konfigurasi sistem sama dengan perangkat keras 1. Nginx diaktifkan sendfile (aio / sendfile dibandingkan lebih jauh).

Ini tampaknya lebih baik, jadi sekarang karena kita memiliki server, yang berfungsi dalam puncak, kita dapat mencoba beberapa optimasi.

Utas Sendfile vs aio

Saya mencoba untuk menonaktifkan sendfile dan menggunakan utas aio sebagai gantinya.

• lepas sendfile
• utas aio
• directio 1M (yang cocok dengan semua file yang kita miliki)

vs.

• sendfile aktif

Kemudian pada pukul 15:00 saya kembali ke sendfile dan memuat ulang nginx (jadi butuh beberapa saat untuk menyelesaikan koneksi yang ada). Sangat menyenangkan bahwa pemanfaatan drive (diukur dengan iostat) turun. Tidak ada yang berubah pada traffic (sayangnya zabbix memutuskan untuk tidak mengumpulkan data dari bond0).

on / off sendfile

Baru saja mencoba untuk mengaktifkan / menonaktifkan send. Tidak ada yang berubah kecuali menjadwal ulang interupsi.

irqbalancer sebagai server / cron / dinonaktifkan

Seperti yang disebutkan @ld saya mencoba mengatur irqbalancer untuk dieksekusi melalui cron:

*/5 * * * *   root    /usr/sbin/irqbalance --oneshot --debug 3 > /dev/null

Sayangnya itu tidak membantu dalam kasus saya. Salah satu kartu jaringan mulai berperilaku aneh:

Saya tidak dapat menemukan apa yang salah dalam grafik dan seperti yang terjadi pada hari berikutnya lagi, saya masuk ke server dan melihat bahwa satu inti berada pada 100% (penggunaan sistem).

Saya mencoba memulai irqbalance sebagai layanan, hasilnya masih sama.

Kemudian saya memutuskan untuk menggunakan skrip set_irq_affinity dan itu segera memperbaiki masalah dan server mendorong 17Gbps lagi.

Perangkat Keras 3

Kami melakukan peningkatan ke perangkat keras baru: 2U 24 (+2) drive chassis (6xSFF), 2x Xeon E5-2620v4, 64GB DDR4 RAM (modul 4x16GB), 13x SSD, kartu jaringan 2x Supermicro (dengan chip Intel). CPU baru banyak meningkatkan kinerjanya.

Pengaturan saat ini tetap - sendfile, dll. Satu-satunya perbedaan adalah kita membiarkan hanya satu CPU menangani kedua kartu jaringan (melalui skrip set_irq_affinity).

Batas 20Gbps telah tercapai.

Tujuan selanjutnya? 30Gbps.

Merasa bebas untuk menembak saya ide bagaimana meningkatkan kinerja. Saya akan dengan senang hati mengujinya secara langsung dan membagikan beberapa grafik berat di sini.

Ada ide bagaimana menangani sejumlah besar SoftIRQ pada cpu?

Ini bukan pertanyaan tentang perencanaan kapasitas - saya sudah memiliki perangkat keras dan lalu lintas. Saya selalu dapat membagi lalu lintas ke beberapa server (yang harus saya lakukan di masa depan pula) dan memperbaiki masalah dengan uang. Namun ini adalah pertanyaan tentang optimasi sistem dan penyempurnaan kinerja dalam skenario nyata.

Penafian : Saran yang sama berlaku untuk semua layanan yang mendorong lebih dari 10Gbps. Termasuk tetapi tidak terbatas pada load balancers, caching server, webservers (HAProxy, Varnish, nginx, tomcat, ...)

Apa yang ingin Anda lakukan itu salah, jangan lakukan itu

Gunakan CDN sebagai gantinya

CDN dimaksudkan untuk mengirimkan konten statis yang dapat ditutup. Gunakan alat yang tepat untuk pekerjaan itu (akamai, MaxCDN, cloudflare, cloudfront, ...)

Setiap CDN, bahkan yang gratis, akan melakukan lebih baik daripada apa pun yang dapat Anda capai sendiri.

Skala secara horizontal sebagai gantinya

Saya mengharapkan satu server untuk menangani 1-5Gbps di luar kotak tanpa banyak penyesuaian (catatan: hanya melayani file statis). 8-10Gbps biasanya dapat dijangkau dengan penyetelan lanjut.

Meskipun demikian ada banyak batasan keras untuk apa yang bisa diambil oleh satu kotak. Anda harus memilih skala secara horizontal.

Jalankan satu kotak, coba berbagai hal, ukur, patok, optimalkan ... sampai kotak itu dapat diandalkan dan dapat diandalkan dan kemampuannya ditentukan dengan baik, lalu letakkan lebih banyak kotak seperti itu dengan penyeimbang beban global di depan.

Ada beberapa opsi penyeimbangan beban global: sebagian besar CDN dapat melakukannya, DNS roundrobin, ELB / Google load balancers ...

Mari kita abaikan praktik baik dan tetap lakukan

Memahami pola lalu lintas

            WITHOUT REVERSE PROXY

[request ]  user ===(rx)==> backend application
[response]  user <==(tx)===     [processing...]

Ada dua hal yang perlu dipertimbangkan: bandwidth dan arah (emisi atau penerimaan).

File kecil berukuran 50/50 tx / rx karena header HTTP dan overhead TCP lebih besar daripada konten file.

File besar adalah 90/10 tx / rx karena ukuran permintaan dapat diabaikan dibandingkan dengan ukuran respons.

            WITH REVERSE PROXY

[request ]  user ===(rx)==> nginx ===(tx)==> backend application
[response]  user <==(tx)=== nginx <==(rx)===     [processing...]

Proksi terbalik membalikkan semua pesan di kedua arah. Beban selalu 50/50 dan total lalu lintas menjadi dua kali lipat.

Itu menjadi lebih kompleks dengan caching diaktifkan. Permintaan dapat dialihkan ke hard drive, yang datanya mungkin di-cache dalam memori.

Catatan : Saya akan mengabaikan aspek caching di posting ini. Kami akan fokus untuk mendapatkan 10-40 Gbps di jaringan. Mengetahui apakah data berasal dari cache dan mengoptimalkan cache itu adalah topik lain, itu didorong melalui kawat.

Batasan monocore

Load balancing adalah monocore (terutama TCP balancing). Menambahkan inti tidak membuatnya lebih cepat tetapi dapat membuatnya lebih lambat.

Sama untuk penyeimbangan HTTP dengan mode sederhana (mis. IP, URL, berbasis cookie. Proksi terbalik membaca tajuk dengan cepat, ia tidak menguraikan atau memproses permintaan HTTP dalam arti yang ketat).

Dalam mode HTTPS, dekripsi / enkripsi SSL lebih intensif daripada semua yang diperlukan untuk proxy. Lalu lintas SSL dapat dan harus dibagi menjadi beberapa core.

SSL

Mengingat bahwa Anda melakukan segalanya melalui SSL. Anda ingin mengoptimalkan bagian itu.

Mengenkripsi dan mendekripsi 40 Gbps dengan cepat merupakan suatu pencapaian.

Ambil prosesor generasi terbaru dengan instruksi AES-NI (digunakan untuk operasi SSL).

Tune algoritma yang digunakan oleh sertifikat. Ada banyak algoritma. Anda menginginkan yang paling efektif pada CPU Anda (melakukan benchmarking) SAAT didukung oleh klien DAN cukup aman (tidak perlu enkripsi berlebihan).

IRQ dan pinning inti

Kartu jaringan menghasilkan interupsi (IRQ) ketika ada data baru untuk dibaca dan CPU lebih dulu untuk segera menangani antrian. Ini adalah operasi yang berjalan di kernel dan / atau driver perangkat dan ini sepenuhnya monocore.

Ini bisa menjadi konsumen CPU terbesar dengan miliaran paket keluar ke segala arah.

Tetapkan kartu jaringan nomor IRQ unik dan tempelkan ke inti tertentu (lihat pengaturan linux atau BIOS).

Sematkan proxy terbalik ke core lain. Kami tidak ingin kedua hal ini mengganggu.

Adaptor Ethernet

Kartu jaringan melakukan banyak pengangkatan berat. Semua perangkat dan pabrikan tidak sama dalam hal kinerja.

Lupakan adaptor terintegrasi pada motherboard (tidak masalah jika server atau motherboard konsumen), mereka hanya payah.

TCP Offloading

TCP adalah protokol yang sangat intensif dalam hal pemrosesan (checksum, ACK, transmisi ulang, paket reassembling, ...) Kernel menangani sebagian besar pekerjaan tetapi beberapa operasi dapat diturunkan ke kartu jaringan jika mendukungnya.

Kami tidak ingin hanya kartu yang relatif cepat , kami ingin satu dengan semua lonceng dan peluit.

Lupakan Intel, Mellanox, Dell, HP, apa pun. Mereka tidak mendukung semua itu.

Hanya ada satu opsi di atas meja: SolarFlare - Senjata rahasia perusahaan HFT dan CDN.

Dunia terbagi dalam dua jenis orang: " Yang tahu SolarFlare " dan " yang tidak ". (set pertama benar-benar setara dengan " orang yang melakukan jaringan 10 Gbps dan peduli setiap bit "). Tapi saya ngelantur, mari fokus: D

Penalaan Kernel TCP

Ada opsi sysctl.confuntuk buffer jaringan kernel. Apa yang dilakukan atau tidak dilakukan pengaturan ini. Saya benar-benar tidak tahu.

net.core.wmem_max
net.core.rmem_max
net.core.wmem_default
net.core.rmem_default

net.ipv4.tcp_mem
net.ipv4.tcp_wmem
net.ipv4.tcp_rmem

Bermain dengan pengaturan ini adalah tanda pasti dari optimasi berlebihan (yaitu umumnya tidak berguna atau kontra produktif).

Khususnya, itu mungkin masuk akal mengingat persyaratan ekstrem.

(Catatan: 40Gbps pada satu kotak adalah optimasi berlebihan. Rute yang masuk akal adalah untuk menskalakan secara horizontal.)

Beberapa Batas Fisik

Bandwidth memori

Beberapa angka tentang bandwidth memori (kebanyakan dalam GB / s): http://www.tweaktown.com/articles/6619/crucial-ddr4-memory-performance-overview-early-look-vs-ddr2-ddr3/index.html

Katakanlah kisarannya adalah 150-300 Gbps untuk bandwidth memori (batas maksimum dalam kondisi ideal).

Semua paket harus ada dalam memori di beberapa titik. Hanya menelan data pada tingkat garis 40 Gbps adalah beban berat pada sistem.

Apakah akan ada kekuatan yang tersisa untuk memproses data? Yah, jangan terlalu berharap terlalu tinggi tentang itu. Hanya mengatakan ^^

Bus PCI-Express

PCIe 2.0 adalah 4 Gb / s per lane. PCIe 3.0 adalah 8 Gbps per lane (tidak semua tersedia untuk kartu PCI).

NIC 40 Gbps dengan port Ethernet tunggal menjanjikan lebih dari PCIe bus jika konektornya kurang dari 16x panjang pada spesifikasi v3.0.

Lain

Kita bisa melewati batas lain. Intinya adalah bahwa perangkat keras memiliki batasan keras yang melekat pada hukum fisika.

Perangkat lunak tidak dapat melakukan lebih baik daripada perangkat keras yang digunakan.

Tulang punggung jaringan

Semua paket ini harus pergi ke suatu tempat pada akhirnya, melintasi sakelar dan router. Sakelar dan router 10 Gbps [hampir] merupakan komoditas. 40 Gbps jelas tidak.

Juga, bandwidth harus end-to-end jadi apa jenis tautan yang Anda miliki kepada pengguna?

Terakhir kali saya memeriksa dengan datacenter guy saya untuk proyek sampingan pengguna 10 juta, dia cukup jelas bahwa hanya akan ada 2x 10 Gbits link ke internet paling banyak.

Hard drive

iostat -xtc 3

Metrik dibagi dengan membaca dan menulis. Periksa antrian (<1 baik), latensi (<1 ms baik) dan kecepatan transfer (semakin tinggi semakin baik).

Jika disk lambat, solusinya adalah menempatkan SSD lebih besar DAN lebih besar dalam serangan 10. (perhatikan bahwa bandwidth SSD meningkat secara linear dengan ukuran SSD).

Pilihan CPU

IRQ dan kemacetan lainnya hanya berjalan pada satu inti sehingga bertujuan untuk CPU dengan kinerja inti tunggal tertinggi (yaitu frekuensi tertinggi).

Enkripsi / dekripsi SSL memerlukan instruksi AES-NI sehingga bertujuan untuk revisi terbaru CPU saja.

SSL mendapat manfaat dari banyak core sehingga bertujuan untuk banyak core.

Singkat cerita: CPU yang ideal adalah yang terbaru dengan frekuensi tertinggi yang tersedia dan banyak core. Pilih saja yang paling mahal dan mungkin itu: D

sendfile ()

Kirimfile ON

Hanya kemajuan terbesar dari kernel modern untuk server web berkinerja tinggi.

Catatan Akhir

1 SolarFlare NIC 40 Gbps (pin IRQ and core)
2 SolarFlare NIC 40 Gbps (pin IRQ and core)
3 nginx master process
4 nginx worker
5 nginx worker
6 nginx worker
7 nginx worker
8 nginx worker
...

Satu hal ditekankan ke satu CPU. Itulah caranya.

Satu NIC mengarah ke dunia luar. Satu NIC mengarah ke jaringan internal. Membagi tanggung jawab selalu baik (meskipun NIC 40 Gbps ganda mungkin berlebihan).

Itu banyak hal yang perlu diperbaiki, beberapa di antaranya bisa menjadi subjek buku kecil. Bersenang-senang membandingkan semua itu. Kembali untuk mempublikasikan hasilnya.

Saya belum dapat berkomentar karena reputasi, jadi saya harus menambahkan jawaban ...

Dalam contoh pertama, Anda berkata:

Ada 2 hal yang menarik perhatian saya. Yang pertama adalah jumlah IRQ yang tinggi. Dalam hal ini saya sayangnya tidak memiliki grafik dari / proc / interupsi. Yang kedua adalah beban sistem yang tinggi, yang saya pikir disebabkan oleh kswapd0 mengalami masalah untuk bekerja dengan 16G RAM saja.

Sepenuhnya setuju bahwa ini adalah poin penting.

1. Coba gunakan agen collectd, yang dapat mengumpulkan IRQ dan simpan menggunakan RRD.

2. Apakah Anda memiliki bagan penggunaan memori?

   Sementara di permukaan, ini terlihat seperti masalah CPU, softirq% tinggi mungkin hanya mengarahkan jari ke memori, jika ada banyak kesalahan halaman keras atau lunak yang terjadi. Saya pikir pemberian itu adalah peningkatan mendadak di IRQ, dengan mengorbankan Sistem CPU sekitar pukul 19:00.

Dari apa yang saya lihat dari spesifikasi, semuanya terlihat sama kecuali:

• Ingatan
• model cpu - kecuali saya salah, tolok ukur akan menunjukkan bahwa mereka harus serupa, dan dalam kasus semacam ini saya lebih suka kotak dengan core lebih cepat lebih sedikit.