Bu soruda tek bir sunucudan 40Gbps sunmak için mümkün olan en iyi yapılandırmayı / donanımı bulmak istiyorum.

Durum

Arkasındaki yavaş depolama sunucularından zirveleri boşaltan bir video paylaşım proxy sunucumuz var. Tüm trafik yalnızca HTTP'dir. Sunucu, ters proxy (sunucuda önbelleğe alınmamış dosyalar) ve bir web sunucusu (yerel sürücülerde depolanan dosyalar) gibi davranır.

Şu anda 100TB dosya ve arka uç depolama sunucularında büyüyen bir şey var.

Önbellek mekanizması bağımsız olarak uygulanır ve bu soru çok iyi çalıştığı için kendini önbelleğe almakla ilgili değildir - şu anda 14Gbps sağlar, arka uç sunucularına sadece 2Gbps geçer. Bu yüzden önbellek kullanımı iyidir.

Hedef

Tek bir makineden 40Gbps veya daha fazla verim elde edin.

Donanım 1

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

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

Sistem:

• irqbalancer durdu
• Her arabirim için set_irq_affinity (ixgbe sürücüsü tarball'ında komut dosyası aracılığıyla)
• ixgbe-4.3.15
• G / Ç zamanlayıcı son tarihi
• iptables boş (yüksüz modüller)
• Dosya sistemi: XFS

nginx:

• dosya gönderme
• aio konuları
• directio 1M
• tcp_nopush açık
• tcp_nodelay açık

Grafiklerde görüldüğü gibi, 12.5Gbps itebildik. Ne yazık ki sunucu yanıt vermiyordu.

Dikkatimi çeken 2 şey var. Birincisi yüksek miktarda IRQ. Bu durumda maalesef / proc / interrupts dizininden grafiklerim yok. İkinci şey, kswapd0'ın sadece 16G RAM ile çalışmak için problemleri olduğunu düşündüğüm yüksek sistem yüküydü.

Donanım 2

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

SSD, Sistem yapılandırması donanım 1 ile aynıdır. Nginx sendfile açık (aio / sendfile daha fazladır).

Bu daha iyi görünüyor, bu yüzden şimdi zirvelerde çalışan bir sunucumuz olduğu için bazı optimizasyonları deneyebiliriz.

Sendfile vs aio konuları

Sendfile devre dışı bırakmak ve bunun yerine aio konularını kullanmayı denedim.

• dosya gönderme
• aio konuları
• directio 1M (sahip olduğumuz tüm dosyalarla eşleşir)

vs

• göndermek

Sonra 15: 00'de sendfile'a geri döndüm ve nginx'i yeniden yükledim (bu nedenle mevcut bağlantıları bitirmek biraz zaman aldı). Sürücü kullanımının (iostat ile ölçülen) azalması güzel. Trafikte hiçbir şey değişmedi (maalesef zabbix bond0'dan veri toplamamaya karar verdi).

gönderme dosyası açık / kapalı

Sadece göndermeyi açmayı / kapatmayı denedi. Yeniden zamanlama kesintileri dışında hiçbir şey değişmedi.

irqbalancer sunucu / cron / devre dışı

@ Lsd belirtildiği gibi ben irqbalancer cron üzerinden yürütülmesini ayarlamaya çalıştı:

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

Ne yazık ki benim durumumda yardımcı olmadı. Ağ kartlarından biri garip davranmaya başladı:

Grafiklerde neyin yanlış olduğunu bulamadım ve ertesi gün tekrar olduğu gibi, sunucuya giriş yaptım ve bir çekirdeğin% 100 (sistem kullanımı) olduğunu gördüm.

İrqbalance'ı bir hizmet olarak başlatmaya çalıştım, sonuç hala aynıydı.

Sonra set_irq_affinity komut dosyasını kullanmaya karar verdim ve sorunu hemen düzeltti ve sunucu 17Gbps'yi tekrar itti.

Donanım 3

Yeni donanıma yükseltme yaptık: 2U 24 (+2) sürücü kasası (6xSFF), 2x Xeon E5-2620v4, 64GB DDR4 RAM (4x16GB modüller), 13x SSD, 2x Supermicro (Intel yongalı) ağ kartları. Yeni CPU'lar performansı çok artırdı.

Geçerli kurulum kalır - sendfile, vb. Tek fark, yalnızca tek bir CPU'nun her iki ağ kartını da işlemesine izin vermemizdir (set_irq_affinity komut dosyası aracılığıyla).

20Gbps sınırına ulaşıldı.

Sıradaki hedef? 30Gbps.

Performansı nasıl artıracağına dair fikirleri bana çekinmekten çekinmeyin. Canlı olarak test etmekten ve burada ağır grafikler paylaşmaktan mutluluk duyacağım.

CPU'da büyük miktarda SoftIRQ'larla nasıl başa çıkacağınız hakkında bir fikriniz var mı?

Bu kapasite planlamasıyla ilgili bir soru değil - Donanım ve trafiğe zaten sahibim. Ben her zaman (ki ben yine de gelecekte yapmak zorunda kalacak) çeşitli sunuculara trafik bölmek ve para ile sorunu giderebilirsiniz. Ancak bu, gerçek bir canlı senaryoda sistem optimizasyonu ve performans düzeltme ile ilgili bir sorudur.

Feragatname : Aynı tavsiye 10Gbps'den fazla olan tüm hizmetler için geçerlidir. Yük dengeleyicileri, önbellek sunucuları, web sunucuları (HAProxy, Varnish, nginx, tomcat, ...) dahil ancak bunlarla sınırlı değildir

Yapmak istediğin şey yanlış, yapma

Bunun yerine bir CDN kullanın

CDN, önlenebilir statik içerik sunmak içindir. İş için doğru aracı kullanın (akamai, MaxCDN, cloudflare, cloudfront, ...)

Herhangi bir CDN, hatta ücretsiz bir CD, kendi başınıza başarabileceğinizden daha iyisini yapacaktır.

Bunun yerine yatay olarak ölçeklendir

Tek bir sunucunun çok fazla tweaking olmadan 1-5Gbps kutudan çıkmasını bekliyorum (not: yalnızca statik dosyaları sunma). 8-10Gbps genellikle gelişmiş ayar ile erişilebilir durumdadır.

Bununla birlikte, tek bir kutunun alabileceği birçok zor sınır vardır. Yatay olarak ölçeklendirmeyi tercih etmelisiniz.

Tek bir kutu çalıştırın, bir şeyler deneyin, ölçün, kıyaslama yapın, optimize edin ... bu kutu güvenilir ve güvenilir olana ve yetenekleri iyi belirlenene kadar, önde küresel bir yük dengeleyici ile bunun gibi daha fazla kutu koyun.

Birkaç küresel yük dengeleme seçeneği vardır: çoğu CDN bunu yapabilir, DNS roundrobin, ELB / Google yük dengeleyicileri ...

İyi uygulamaları görmezden gelelim ve yine de yapalım

Trafik düzenini anlama

            WITHOUT REVERSE PROXY

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

Dikkate alınması gereken iki şey vardır: bant genişliği ve yönü (emisyon veya alım).

HTTP üstbilgileri ve TCP ek yükü dosya içeriğinden daha büyük olduğu için küçük dosyalar 50/50 tx / rx'dir.

Büyük dosyalar 90/10 tx / rx'dir, çünkü istek boyutu yanıt boyutuna kıyasla önemsizdir.

            WITH REVERSE PROXY

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

Ters proxy, tüm iletileri her iki yönde de iletiyor. Yük her zaman 50/50'dir ve toplam trafik iki katına çıkar.

Önbellekleme etkinleştirildiğinde daha karmaşık hale gelir. İstekler, verileri bellekte önbelleğe alınabilen sabit sürücüye yönlendirilebilir.

Not : Bu yayındaki önbellekleme özelliğini yok sayacağım. Ağa 10-40 Gbps ulaşmaya odaklanacağız. Verilerin önbellekten gelip gelmediğini bilmek ve bu önbelleği optimize etmek başka bir konudur, her iki şekilde de telin üzerinden itilir.

Monocore sınırlamaları

Yük dengeleme monocore'dur (özellikle TCP dengeleme). Çekirdek eklemek onu hızlandırmaz, ancak yavaşlatabilir.

Basit modlarla HTTP dengelemesi için aynıdır (örneğin IP, URL, çerez tabanlı. Ters proxy, başlıkları anında okur, HTTP isteklerini kesin anlamda ayrıştırmaz veya işlemez).

HTTPS modunda, SSL şifre çözme / şifreleme, proxy için gereken diğer her şeyden daha yoğundur. SSL trafiği birden çok çekirdeğe bölünebilir ve bölünmelidir.

SSL

SSL üzerinden her şeyi yaptığınız göz önüne alındığında. Bu kısmı optimize etmek isteyeceksiniz.

Anında 40 Gb / s şifreleme ve şifre çözme oldukça başarılıdır.

AES-NI talimatları (SSL işlemleri için kullanılır) ile en yeni nesil işlemciyi alın.

Sertifikalar tarafından kullanılan algoritmayı ayarlayın. Birçok algoritma var. İstemciler tarafından desteklenirken ve yeterince güvenli olduğunda (gerekli aşırı şifreleme gerekmez) CPU'nuzda en etkili olanı (kıyaslama yapın) istiyorsunuz.

IRQ ve çekirdek sabitleme

Okunacak yeni veriler olduğunda ve CPU kuyruğu hemen işlemek için önceden boşaltıldığında ağ kartı kesintiler (IRQ) oluşturur. Çekirdek ve / veya aygıt sürücülerinde çalışan bir işlemdir ve kesinlikle monocore'dur.

Her yöne milyarlarca paketin çıktığı en büyük CPU tüketicisi olabilir.

Ağ kartına benzersiz bir IRQ numarası atayın ve belirli bir çekirdeğe sabitleyin (bkz. Linux veya BIOS ayarları).

Ters proxy'yi diğer çekirdeklere sabitleyin. Bu iki şeyin karışmasını istemiyoruz.

Ethernet Adaptörü

Ağ kartı ağır kaldırma işlemlerinin çoğunu yapıyor. Performanslar söz konusu olduğunda tüm cihazlar ve üreticiler eşit değildir.

Anakartlardaki entegre adaptörü unutun (sunucu veya tüketici anakartının önemi yoktur), sadece emerler.

TCP Boşaltma

TCP, işlem açısından çok yoğun bir protokoldür (sağlama toplamları, ACK, yeniden iletim, paketleri yeniden birleştirme, ...) Çekirdek işin çoğunu idare eder, ancak bazı işlemler destekliyorsa ağ kartına yüklenebilir.

Biz istemiyoruz , sadece nispeten hızlı kart , biz çan ve ıslık tüm çekilmek istiyorum.

Intel, Mellanox, Dell, HP, ne olursa olsun unutun. Bunların hepsini desteklemiyorlar.

Masada sadece bir seçenek var: SolarFlare - HFT firmalarının ve CDN'nin gizli silahı.

Dünya iki çeşit insana ayrılmıştır: " SolarFlare'yi bilenler " ve " bilmeyenler ". (ilk set kesinlikle " 10 Gb / sn ağ ve her bit önemseyen insanlar " ile eşdeğerdir ). Ama konuya giriyorum, odaklanalım: D

Çekirdek TCP ayarı

sysctl.confÇekirdek ağ arabellekleri için seçenekler vardır . Bu ayarların ne yaptığı veya ne yapmadığı. Gerçekten bilmiyorum.

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

Bu ayarlarla oynamak, aşırı optimizasyonun (yani genellikle işe yaramaz veya karşı üretken) kesin işaretidir.

İstisnai olarak, aşırı gereksinimler göz önüne alındığında bu mantıklı olabilir.

(Not: Tek bir kutuda 40Gbps aşırı optimizasyon. Makul yol yatay olarak ölçeklendirilmektir.)

Bazı Fiziksel Sınırlar

Bellek bant genişliği

Bellek bant genişliği hakkında bazı rakamlar (çoğunlukla GB / sn cinsinden): http://www.tweaktown.com/articles/6619/crucial-ddr4-memory-performance-overview-early-look-vs-ddr2-ddr3/index.html

Diyelim ki bellek bant genişliği için aralık 150-300 Gbps (ideal koşullarda maksimum sınır).

Tüm paketlerin bir noktada hafızada olması gerekir. Sadece 40 Gbps hat hızında veri almak sistem üzerinde ağır bir yüktür.

Verileri işlemek için herhangi bir güç kalacak mı? Peki, beklentilerimizi bu kadar yüksek tutmayalım. Sadece ^^ demek

PCI-Express veri yolu

PCIe 2.0 şerit başına 4 Gb / s'dir. PCIe 3.0, şerit başına 8 Gbps'dir (PCI kartı için tümü mevcut değildir).

Konektör v3.0 teknik özelliklerinde 16x'den daha kısa bir uzunluktaysa, tek bir Ethernet bağlantı noktasına sahip 40 Gbps NIC, PCIe veri yolundan daha fazlasını vaat ediyor.

Diğer

Diğer sınırları aşabiliriz. Mesele, donanımın fizik yasalarına özgü zor sınırlamaları olmasıdır.

Yazılım, üzerinde çalıştığı donanımdan daha iyisini yapamaz.

Ağ omurgası

Tüm bu paketler nihayetinde bir yere gitmeli, anahtarları ve yönlendiricileri geçmelidir. 10 Gbps anahtarlar ve yönlendirici [neredeyse] bir maldır. 40 Gbps kesinlikle değil.

Ayrıca, bant genişliği uçtan uca olmalıdır, bu yüzden kullanıcıya ne tür bağlantılarınız var?

En son 10M kullanıcı tarafı projesi için veri merkezimdeki adamla kontrol ettiğimde, en fazla internete sadece 2x 10 Gbits bağlantı olacağı oldukça açıktı.

Sabit diskler

iostat -xtc 3

Metrikler okuma ve yazma ile ayrılır. Sırayı (<1 iyi), gecikmeyi (<1 ms iyi) ve aktarım hızını (ne kadar yüksekse o kadar iyi) kontrol edin.

Disk yavaşsa çözüm, baskın 10'a daha fazla VE daha büyük SSD koymaktır (SSD bant genişliğinin SSD boyutuyla doğrusal olarak arttığına dikkat edin).

CPU seçimi

IRQ ve diğer darboğazlar yalnızca bir çekirdek üzerinde çalışır, bu nedenle en yüksek tek çekirdekli performanslara (yani en yüksek frekans) sahip CPU'yu hedefleyin.

SSL şifreleme / şifre çözme işlemi için AES-NI talimatları gerekir, bu nedenle yalnızca en son CPU revizyonunu hedefleyin.

SSL birden fazla çekirdekten yararlanır, bu nedenle birçok çekirdeği hedefleyin.

Uzun lafın kısası: İdeal CPU, mevcut en yüksek frekansa ve birçok çekirdeğe sahip en yeni CPU'dur. Sadece en pahalı olanı seç ve muhtemelen bu: D

dosya Gönder()

Sendfile AÇIK

Yüksek performanslı web sunucuları için modern çekirdeklerin en büyük ilerlemesi.

Son Not

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
...

Bir şey bir CPU'ya sabitlendi. Gidilecek yol bu.

Dış dünyaya giden bir NIC. Dahili ağa giden bir NIC. Bölünme sorumlulukları her zaman iyidir (çift 40 Gb / sn NIC aşırıya kaçabilir).

Bu, bazıları küçük bir kitabın konusu olabilecek ince ayarlanmış birçok şey. Tüm bunları kıyaslarken eğlenin. Sonuçları yayınlamak için tekrar gelin.

Ben itibar nedeniyle henüz yorum yapamam, bunun yerine bir cevap eklemek zorunda ...

İlk örnekte şunları söylediniz:

Dikkatimi çeken 2 şey var. Birincisi yüksek miktarda IRQ. Bu durumda maalesef / proc / interrupts dizininden grafiklerim yok. İkinci şey, kswapd0'ın sadece 16G RAM ile çalışmak için problemleri olduğunu düşündüğüm yüksek sistem yüküydü.

Bunların önemli noktalar olduğuna kesinlikle katılıyorum.

1. IRQ'ları toplayabilen ve RRD kullanarak depolayabilen toplama ajanını kullanmayı deneyin.

2. Bellek kullanımı grafiğiniz var mı?

   Yüzeyde iken, bu bir CPU sorununa benziyor, yüksek sertlik yüzdesi, çok fazla sert veya yumuşak sayfa hatası varsa, parmağınızı hafızaya doğru yönlendirebilir. Sanırım geri verme, IRQ'larda, saat 19: 00'da Sistem CPU pahasına ani yükselme olduğunu düşünüyorum.

Teknik özelliklerden görebildiğim kadarıyla, her şey aynı görünüyor:

• hafıza
• cpu modelleri - yanılmıyorsam, kıyaslamalar benzer olmaları gerektiğini gösterir ve bu tür durumlarda kutuyu daha az hızlı çekirdekli tercih ederim.