10G PC NAT + QOS + router
Napsal: 07 May 2016 08:30
Tak asi posté otevřu toto nesmrtelné téma. Tentokrát ovšem poměrně konkrétně.
MB: Supermicro X9SRH-7F/7TF/X9SRH-7F/7TF (aktuální bios)
CPU: Xeon E5-1620 v2
RAM: 16GB ECC
Dva SSD v HW raidu.
Síťovky integrované X540 myslím a v PCIe X520 dvojitá SFP+. Všechny mají stejný čip i82599
Systém archlinux, jádro 4.4. Ovladač ixgbe aktualizovaný na 4.3.15
Mám dva za sebou, takže jsem mohl experimentovat. Z jedné strany zbytek sítě (Brocade FCX stack) a z druhé BGP routery (Brocade CER2000 + ICX jako stack). Tedy je tam bonding (původně LACP - 802.3ad, nyní jen active-backup). Mezi sebou jsou pak jednoduše UTP kabelem ... To celé routuje pomocí OSPF, defaultu šíří ty brocady.
Na jednom serveru je v podstatě jen firewall, iptables+ipset. Na druhém NAT a HTB QOS.
Vše jede v pořádku. V podstatě měsíce v kuse. Můžu si generovat provoz jaký chci, vše v pořádku. Dokonce i na internetu jsem to měl, neboť jsem si mohl dovolit vyčlenit jeden segment veřejných IP (zajímavé, 300kbps provozu "samo od sebe"). Tedy routuji, přenáším data, měním si konfiguraci, hraju si, vše v pořádku.
Tak si vyberu noc, kdy přehodím i lidi a staré segmenty. A v tu chvilku to přijde. Většinou do několika vteřin server padne. Kdyby alespoň do panicu - ale ON SE PROSTĚ SEKNE. Nestihne nic vypsat, ani v iptrafu se nestihne objevit nějaký významnější nárůst. Obrazovka zůstane vidět. Podle teploty procesoru to vypadá na nějaký deadlock, minimálně jedno jádro jelo asi naplno.
Zkusil jsem si měnit nějaké parametry síťovek, nic nepomohlo (ani ten upgrade driveru). LRO samozřejmě vypnuté (ixgbe 4.2.1 to má už defaultně). Prostě odentruji distribuci default route a je to na prkně. A to je noc, provoz do sto megabit (dle dlouhodobých statistik).
Pak přijde hodinka, kdy to začalo fungovat. Kdo ví přesně proč ... Jelo to šest hodin. I 6 gbit se nám povedlo vygenerovat. Krása.
Jenže po dvou hodinách mého spánku se to opět seklo. Tentokrát oba servery.
Po dvou týdnech ležení v google se mi nepovedlo zjistit v podstatě naprosto vůbec nic. Jen jednu malou zmínku ohledně bondingu u Synology, která by teoreticky mohla být minimálně obdobná mému problému. Na základě toho jsem změnil typ bondingu na active-backup. Co když se v tom 802.3ad nějak podivně občas pomíchají pakety?
Takže dnes to zkouším naposledy. Ani vypínání offload funkcí nepomáhá.
VYPNUL JSEM multiqueue (parametr MQ modulu). Od té doby to funguje. Bohužel místo 4 jader vytěžuji jen dvě a mám z toho takový podivný pocit, že mi to bude k ničemu ... ALE FUNGUJE TO.
Takže teď bábo raď. Čím to?
Začínám si myslet, že je něco shnilého v království Supermicro. Mám totiž jeden server asi dva roky starý. Kdysi jsem pokusoval, jak se připravit na 10G (stávající HW stejně odcházel). Chovalo se to obdobně ... byť si již nepamatuji přesně jak. Ale hardwarově to bylo skoro to samé, také X9 a SFP+ síťová karta.
A v produkčním nasazení máme jiné malé supermicro a to už se za těch pár let také dvakrát seklo. U jiných výrobců (s linuxem! mikrotik nepočítám) na to nejsem zvyklý.
Kdybych tušil tyhle problémy, tak budu investovat do něčeho jiného (byť ... do čeho pro NAT?).
MB: Supermicro X9SRH-7F/7TF/X9SRH-7F/7TF (aktuální bios)
CPU: Xeon E5-1620 v2
RAM: 16GB ECC
Dva SSD v HW raidu.
Síťovky integrované X540 myslím a v PCIe X520 dvojitá SFP+. Všechny mají stejný čip i82599
Systém archlinux, jádro 4.4. Ovladač ixgbe aktualizovaný na 4.3.15
Mám dva za sebou, takže jsem mohl experimentovat. Z jedné strany zbytek sítě (Brocade FCX stack) a z druhé BGP routery (Brocade CER2000 + ICX jako stack). Tedy je tam bonding (původně LACP - 802.3ad, nyní jen active-backup). Mezi sebou jsou pak jednoduše UTP kabelem ... To celé routuje pomocí OSPF, defaultu šíří ty brocady.
Na jednom serveru je v podstatě jen firewall, iptables+ipset. Na druhém NAT a HTB QOS.
Vše jede v pořádku. V podstatě měsíce v kuse. Můžu si generovat provoz jaký chci, vše v pořádku. Dokonce i na internetu jsem to měl, neboť jsem si mohl dovolit vyčlenit jeden segment veřejných IP (zajímavé, 300kbps provozu "samo od sebe"). Tedy routuji, přenáším data, měním si konfiguraci, hraju si, vše v pořádku.
Tak si vyberu noc, kdy přehodím i lidi a staré segmenty. A v tu chvilku to přijde. Většinou do několika vteřin server padne. Kdyby alespoň do panicu - ale ON SE PROSTĚ SEKNE. Nestihne nic vypsat, ani v iptrafu se nestihne objevit nějaký významnější nárůst. Obrazovka zůstane vidět. Podle teploty procesoru to vypadá na nějaký deadlock, minimálně jedno jádro jelo asi naplno.
Zkusil jsem si měnit nějaké parametry síťovek, nic nepomohlo (ani ten upgrade driveru). LRO samozřejmě vypnuté (ixgbe 4.2.1 to má už defaultně). Prostě odentruji distribuci default route a je to na prkně. A to je noc, provoz do sto megabit (dle dlouhodobých statistik).
Pak přijde hodinka, kdy to začalo fungovat. Kdo ví přesně proč ... Jelo to šest hodin. I 6 gbit se nám povedlo vygenerovat. Krása.
Jenže po dvou hodinách mého spánku se to opět seklo. Tentokrát oba servery.
Po dvou týdnech ležení v google se mi nepovedlo zjistit v podstatě naprosto vůbec nic. Jen jednu malou zmínku ohledně bondingu u Synology, která by teoreticky mohla být minimálně obdobná mému problému. Na základě toho jsem změnil typ bondingu na active-backup. Co když se v tom 802.3ad nějak podivně občas pomíchají pakety?
Takže dnes to zkouším naposledy. Ani vypínání offload funkcí nepomáhá.
VYPNUL JSEM multiqueue (parametr MQ modulu). Od té doby to funguje. Bohužel místo 4 jader vytěžuji jen dvě a mám z toho takový podivný pocit, že mi to bude k ničemu ... ALE FUNGUJE TO.
Takže teď bábo raď. Čím to?
Začínám si myslet, že je něco shnilého v království Supermicro. Mám totiž jeden server asi dva roky starý. Kdysi jsem pokusoval, jak se připravit na 10G (stávající HW stejně odcházel). Chovalo se to obdobně ... byť si již nepamatuji přesně jak. Ale hardwarově to bylo skoro to samé, také X9 a SFP+ síťová karta.
A v produkčním nasazení máme jiné malé supermicro a to už se za těch pár let také dvakrát seklo. U jiných výrobců (s linuxem! mikrotik nepočítám) na to nejsem zvyklý.
Kdybych tušil tyhle problémy, tak budu investovat do něčeho jiného (byť ... do čeho pro NAT?).