Hardware pro GW (10 Gbit)

Problematika MikroTik RouterBoard hardware
Uživatelský avatar
hapi
Příspěvky: 10601
Registrován: 10 years ago
Kontaktovat uživatele:

Re: Hardware pro GW (10 Gbit)

Příspěvekod hapi » 1 year ago

konečně jeden člověk kterej ví o čem mluví.

k tý E5ce bych asi dodal toto:
jakej byl důvod dávat dvě pomalí cpu? ano, 2.5GHz je pomalí. Kdyby si osadil dejme tomu jednu E5 kde se prodává 6core s 3.5-3.6GHz základní takt tak to má větší výkon než dva 4core na menším taktu. Frekvence vítězí. Větší frekvence = větší výkon na queue. V tvém případě bych raději osadil 2x4core na 3.5GHz než 2x6core na 2.5GHz. Obě řešení mají své pro a proti.

Ale i tak si nemyslim že to je CPUčkem, co tam máš za ethernety?

Dál bych se zeptal jaký typy front používáš v queue. Asi bych použil klasickou fifo a zvětšil jí velikost. Jestli máš 100Mbit queue tak ty data se prostě do malí/krátký queue tak rychle nenasoukaji/neubrzdí a dropuje to. Pak letí rychlost dolu a vzníká to co píšeš.

A v neposlední řadě jestli máš aktivní symetrický multi channel to jest jestli máš stejný ramky na více než jednom paměťovém řadiči. Jo ano, intel moc dobře ví proč E5ky mají 4 kanálový řadiče protože to cpu je prostě potřebuje. Jak chceš nakrmit rychlostně 8 jader? nebo dokonce jak píšeš 12 jader? no, jeden kanál na ramky bude mít docela dost práce. Celkem tedy 8 kanálů na dvou procesorovou mašinu a jak je zvykem, lidi osazjí jeden ram modul :-D . ( 1 ram modul krmí 12 jader, super průser :-) )

Jo jasně, mikrotik je uměle omezenej na 2GB ramky ale to nijak neovlivňuje využití víc kanálů na jednou. I DDR4 má svoje limity a i když má větší frekvenci, časování stojí za houby proti DDR3 tak jako každá sudá DDR :-D

a na závěr bych se podíval jestli nemáš zapnutý RPS a rozhodil ručně IRQ na jádra což souvisí s otázkou co tam máš za ethernety. Router neni tak že ho zapneš a je vyřešeno.
0 x

D.Ryba
Příspěvky: 42
Registrován: 9 years ago

Příspěvekod D.Ryba » 1 year ago

Dalibor Toman píše:1) aby melo smysl se bavit o vykonnejsim virtualizovanem zeleze a 10gbps kartama, mel bys IMHO zajistit, ze sitovky budou pro ten virtual dedikovane (PCI passthrough) at se k latenci zpracovani packetu jeste nepridava virtualizacni vrstva. Mozna by to pomohla resit take nejake hw akcelerace na karte (jak je na tom ROS v tomhle smeru netusim). Virtual bude mit vzdy potrebovat vice cyklu CPU na zpracovani packetu nez fyzicke zelezo (pridelovani CPU, IRQ atd)

2) nejak si nedovedu predstavit to nasobeni vykonu routingu spojene s virtualizaci. Jestli mas predstavu, ze Ti ten ROS pak pobezi na virtualnim stroji tvorenem z vice HW serveru tak to je IMHO nesmysl.


1200 zakazniku na jednom serveru se shapingem accountingem apod neni na jednom serveru zadna vysoka zatez. Na Linuxu s optimalizovanym HTB s tim neni problem.


1) Říkal jsem si, že by to mohlo být optimalizováno v nové verzi routeros právě pro virtuální stroje, mezi nimi by měla být i verze pro vmware, ale nevím to ani nevím jak to zjistit
2) takovou jsem skutečně měl představu, protože se mi líbila myšlenka mít na serveru s routeros i linux s DNS, SMTP web atd. když to není dobrý nápad tak to tak dělat nebudu :)
0 x

D.Ryba
Příspěvky: 42
Registrován: 9 years ago

Příspěvekod D.Ryba » 1 year ago

hapi píše:konečně jeden člověk kterej ví o čem mluví.

k tý E5ce bych asi dodal toto:
jakej byl důvod dávat dvě pomalí cpu? ano, 2.5GHz je pomalí. Kdyby si osadil dejme tomu jednu E5 kde se prodává 6core s 3.5-3.6GHz základní takt tak to má větší výkon než dva 4core na menším taktu. Frekvence vítězí. Větší frekvence = větší výkon na queue. V tvém případě bych raději osadil 2x4core na 3.5GHz než 2x6core na 2.5GHz. Obě řešení mají své pro a proti.

Ale i tak si nemyslim že to je CPUčkem, co tam máš za ethernety?

Dál bych se zeptal jaký typy front používáš v queue. Asi bych použil klasickou fifo a zvětšil jí velikost. Jestli máš 100Mbit queue tak ty data se prostě do malí/krátký queue tak rychle nenasoukaji/neubrzdí a dropuje to. Pak letí rychlost dolu a vzníká to co píšeš.

A v neposlední řadě jestli máš aktivní symetrický multi channel to jest jestli máš stejný ramky na více než jednom paměťovém řadiči. Jo ano, intel moc dobře ví proč E5ky mají 4 kanálový řadiče protože to cpu je prostě potřebuje. Jak chceš nakrmit rychlostně 8 jader? nebo dokonce jak píšeš 12 jader? no, jeden kanál na ramky bude mít docela dost práce. Celkem tedy 8 kanálů na dvou procesorovou mašinu a jak je zvykem, lidi osazjí jeden ram modul :-D . ( 1 ram modul krmí 12 jader, super průser :-) )

Jo jasně, mikrotik je uměle omezenej na 2GB ramky ale to nijak neovlivňuje využití víc kanálů na jednou. I DDR4 má svoje limity a i když má větší frekvenci, časování stojí za houby proti DDR3 tak jako každá sudá DDR :-D

a na závěr bych se podíval jestli nemáš zapnutý RPS a rozhodil ručně IRQ na jádra což souvisí s otázkou co tam máš za ethernety. Router neni tak že ho zapneš a je vyřešeno.


Důvod E5 na 2,5GHz byla cena, nevěděl jsem, že ze zásadní rychlost. Síťovka je Intel server adapter 1Gb po dvou portech do PCI-e, ale přesný typ už nevím, před 3 lety stála 5000Kč.
Fronty používáme queue tree, teď je tam 3000 řádků typ je tu nastaven sfq, na tom samém routeru shapujeme i 2Mbps, to nevím jestli není problém pro fifo
V současném serveru mám jen jednu 2GB RAMku,ke každému procesoru, taky věc co jsem netušil
RPS mám zapnuté, jak se dá IRQ rozhodit?
0 x

Uživatelský avatar
hapi
Příspěvky: 10601
Registrován: 10 years ago
Kontaktovat uživatele:

Příspěvekod hapi » 1 year ago

Obrázek

tady vidíš, že jeden ethernet má víc IRQ. To je základ, bez toho můžeš mít procesory jaký chceš. Ne každá intel eth to má. Intel server adapter má označení každá :-D i ty debilní :-/ typicky i82574 je naprosto nevhodná. Jak je tam vidět, mám IRQ rozesetý tučně.

Dál je tam vidět i RPS který je vypnutý protože to za nás dělají IRQčka ethernetů a nestará se CPU. Další důležitá vlastnost po těch IRQ. Pokud nemáš ethernety s více IRQ tak to nevypínej.

Dej vědět kolik irq tam máš.

K typu queue... třeba ccrko nemá rádo krátkou frontu a řeže dřív na větších rychlostech. Setkal sem se s tím, že nebylo možný dosahnout max rychlosti v queue a po chvilce laborování sem právě přišel na to, že zvětšením délky fronty se to vyřešilo. Bylo jedno jestli bfifo nebo pfifo. Prostě zvětšit ten buffer. Už třeba jenom pro to, že window size u tcp u velkých rychlostí se do toho bufferu nevejde takže drop a následný zmenšení window size a spadnutí rychlosti a to je čistě v teoretický rovině jednoho spojení. Pokud jich je víc, buffer bude stropovat častěji. Což se dostáváme k tomu, že máš konekt na gigu takže data přicházeji v gigových vlnách i když samotnej konekt nemusí mít gigo ale spojovací rychlost na gigu je. Častá chyba: to že mám nakoupeno 200Mbit neznamená že data ke mě neletí rychlostí 1Gbit, někde se sice oříznou na 200Mbit ale přenosový medium (ethernet) je 1Gbit takže prakticky krátký 1Gbit peaky. Ethernet přece nemá variabilní rychlost :-) data tam tečou furt rychlostí 1Gbit akorát tam jsou větší mezery mezi daty kdy se nic nepřenáší :-) typickej problém i u profy pojítek kdy třeba i alcoma/ceragon atd.. dropujou ačkoliv datovej tok je třeba na půlce z maxima. Paradoxně queue s větší rychlostí budou bitý nejvíc protože se můžou víc rozject a přijímat větší objemy dat a malej buffer to nepobere když to musí srazi třeba 10x tu rychlost. Chceš větší rychlosti? zvětši buffery u front. U queue s malou rychlostí je to jedno, nepozoroval sem problém když měla pomalá queue velkej buffer.

Jo zase sem se rozkecal ale je třeba chápat ty vzájemný průsery který třeba lidi s 200Mbit konektem neřeší nebo o nich neví ale pak zvednou konekt na 300Mbit a začnou si všímat že maji problém z toho konektu tu rychlost vytřískat a pak zjistěji že jim jejich vlastní 1Gbit infrastruktura u konektu neni schopná protlačit 300mbit protože tam už na tom je 500 lidí a každej chce to svoje spojení a svojí část v bufferu třeba páteřního switche atd. atd.. a pak jsou otázky typu: jak je možný, že dopoledne těch 300Mbit vytahnu a paradoxně na večer když je tam víc požadavků už ne? btest přece s větším počtem spojení ukazuje větší rychost? :-D
0 x

ikk
Příspěvky: 151
Registrován: 9 years ago
Kontaktovat uživatele:

Příspěvekod ikk » 1 year ago

Ahoj Hapi, můžu mít na tebe dotaz ohledně tvé konfigurace?
hapi píše:K typu queue... třeba ccrko nemá rádo krátkou frontu a řeže dřív na větších rychlostech. Setkal sem se s tím, že nebylo možný dosahnout max rychlosti v queue a po chvilce laborování sem právě přišel na to, že zvětšením délky fronty se to vyřešilo.


Jak moc tu frontu zvětšit? o násobky o řády???
0 x
Síť není jen internet ...

Uživatelský avatar
hapi
Příspěvky: 10601
Registrován: 10 years ago
Kontaktovat uživatele:

Příspěvekod hapi » 1 year ago

defaultní queue type má buffer 50 paketů. Pozor, qt vytvořená bez definování queue type se definuje jako default-small což je buffer o velikosti 10 paketů!!! vůbec bych se nebál to přepnout na bfifo a nastavit tam třeba 64kB.
0 x

Jenya
Příspěvky: 395
Registrován: 10 years ago

Příspěvekod Jenya » 1 year ago

Kdyz uz se to tu rozebira, vzdy me zajimalo, jak to presne funguje: Na zalozce Interface Queues je pouzita nejaka Queue Type, avsak kdyz definuju queue na zalozce Queue Tree, nebo Simple Queue, zase pouziju nejakou Queue Type. Jak spolu ty queue funguji, tomu bych chtel rozumet.
0 x

pepulis
Příspěvky: 1211
Registrován: 12 years ago
Kontaktovat uživatele:

Příspěvekod pepulis » 1 year ago

hapi píše:defaultní queue type má buffer 50 paketů. Pozor, qt vytvořená bez definování queue type se definuje jako default-small což je buffer o velikosti 10 paketů!!! vůbec bych se nebál to přepnout na bfifo a nastavit tam třeba 64kB.


Tím prosím myslíš hlavní parent a nebo podparenty?
0 x

Uživatelský avatar
hapi
Příspěvky: 10601
Registrován: 10 years ago
Kontaktovat uživatele:

Příspěvekod hapi » 1 year ago

Jenya píše:Kdyz uz se to tu rozebira, vzdy me zajimalo, jak to presne funguje: Na zalozce Interface Queues je pouzita nejaka Queue Type, avsak kdyz definuju queue na zalozce Queue Tree, nebo Simple Queue, zase pouziju nejakou Queue Type. Jak spolu ty queue funguji, tomu bych chtel rozumet.


queue type jsou jenom přednastavený typy pro jednoduší správu. To, že pak je stejná u tisíců pravidel neznamená, že se sdílí, vždy se vytváří nová pro konkrétní sq, qt, interface atd..
Naposledy upravil(a) hapi dne 28 Jul 2016 16:01, celkem upraveno 1 x.
0 x

Uživatelský avatar
hapi
Příspěvky: 10601
Registrován: 10 years ago
Kontaktovat uživatele:

Příspěvekod hapi » 1 year ago

pepulis píše:
hapi píše:defaultní queue type má buffer 50 paketů. Pozor, qt vytvořená bez definování queue type se definuje jako default-small což je buffer o velikosti 10 paketů!!! vůbec bych se nebál to přepnout na bfifo a nastavit tam třeba 64kB.


Tím prosím myslíš hlavní parent a nebo podparenty?


ty typy bufferů (queue type) se uplatňují pouze na queue která je na konci stromu resp. pouze tam kam vstupují pakety což je queue která má nastavenej packet mark. u ostatních queue se buffery neuplatňují.
0 x

dagus
Příspěvky: 626
Registrován: 6 years ago

Příspěvekod dagus » 1 year ago

Koukal jsem na GW kde máme Supermicra SG-I2, které mají také více front. Máme tam Xeon e3 4x3,4GHz s HT, když vypnu RPS na GW kde jsou dvě síťovky aktivní, tak dvě jádra jsou na nule a obsluhujou pouze ether1/1 a 0/1, kde ty máš auto a tam se flákají. Když chci v IRQ připnout frontu síťovky na jádro, tak mě to ale nenechá je tam jen auto. Mám tam verzi 6.32.4, nevíš kde by mohl být zakopaný pes?

Ještě bych se chtěl zeptat jestli vzít na 10Gbit uplink (Routing NAT základní FW) CCR, nebo raději stavět nějaký router na x86 s 10Gbit síťovkama, 10Gbit konekt bude rozdělen do třech routerů a nechce se mi to bondovat po 1Gbit. Potřebuji aby to mělo alespoň 2xSFP+ a alespoň 4xGbit metaliku. Shaping bude rozdělen na víc shaperů podle lokalit. Trochu se bojím jak by se chovalo ccr, ačkoliv 1036 8g+2s+ jsou lákavé v jednoduchosti a snad by to i stíhalo, když tam nebude shaping. Ale nechce se mi to testovat za 24000Kč. Někdo nějaké zkušenosti jak rozporcovat 10Gbit a nezbláznit se z toho?
0 x

Uživatelský avatar
hapi
Příspěvky: 10601
Registrován: 10 years ago
Kontaktovat uživatele:

Příspěvekod hapi » 1 year ago

u IRQ kde je nastaveno auto ručně přepiš na číslo od 0 do (počet jader mínus jedna).

máme s ccrky špatnou zkušenost. Jsou super na čistej routing ale jakmile po nich něco chcem tak se chovají nepředvídatelně v závisloti na provozu. Větší počet QT to nedává a rychlý SQ taky moc ne. Co jsem viděl tak je problém s kvalitou kdy třeba ccrko prostě zcela nečekaně přestane fungovat a nefunguje už ani přes netinstall. Na jiným ccrku odešly eth porty ve smyslu že přestali mít správný kontakt a stačil dotyk a ethernet se odpojil.
0 x

dagus
Příspěvky: 626
Registrován: 6 years ago

Příspěvekod dagus » 1 year ago

Něco chceme? tím myšleno i NAT? Shapery budou jinde, s tou "kvalitou" mám také trochu problém, ono co si budeme ten hw na 26tkč nemá to nejlepší osazení kondíků a zdroje. Je nějaké supermicro co se dá postavit do 1u až 2u skříně s dost pci-e linkama pro uživení 2*10G v jedné kartě a třeba 2*sg-i2? Nenašel jsme na 1U skří'n za zarumný peníz :-)
0 x

Uživatelský avatar
hapi
Příspěvky: 10601
Registrován: 10 years ago
Kontaktovat uživatele:

Příspěvekod hapi » 1 year ago

nat to celkem zvládá pokud se na síti neukáže prasátko.

supermicro má řešení do 1U, cena se ti líbit nebude. Nebo nebude, je lehce pod cenou za CCR1072 který se tím dá nahradit. Existuje 1U kam se dá osadit libovolný Xeon E5v3/v4 + 3 pcie sloty. Dá se tedy nahradit CCR1072 který má 8x SFP+ pomocí dvou karet s 4 porty s SFP+ případně do slotů osadit libovolný karty od 6x1Gbit na kartě až po 6x10Gbit SFP+ a navíc to i na desce má dva vhodné výkonné ethernety pro mikrotik takže hw využitý na plno. Jako bonus to má dokonce i dva zdroje a pochopitelně i IPMI dohled nad hardwarem. Pro někoho kdo chce něco co na sobě má 10Gbit porty by ale taková cena neměla být problém si myslím. Takže jak píšeš, 2 eth porty to má na desce a do slotu strčíš duálku s SFP+ porty. Vše kompatibilní s mikrotikem.
0 x

RAket
Příspěvky: 255
Registrován: 10 years ago

Příspěvekod RAket » 1 year ago

dagus píše:Ještě bych se chtěl zeptat jestli vzít na 10Gbit uplink (Routing NAT základní FW) CCR, nebo raději stavět nějaký router na x86 s 10Gbit síťovkama, 10Gbit konekt bude rozdělen do třech routerů a nechce se mi to bondovat po 1Gbit. Potřebuji aby to mělo alespoň 2xSFP+ a alespoň 4xGbit metaliku. Shaping bude rozdělen na víc shaperů podle lokalit. Trochu se bojím jak by se chovalo ccr, ačkoliv 1036 8g+2s+ jsou lákavé v jednoduchosti a snad by to i stíhalo, když tam nebude shaping. Ale nechce se mi to testovat za 24000Kč. Někdo nějaké zkušenosti jak rozporcovat 10Gbit a nezbláznit se z toho?

CCR1036-8G-2S je na to co popisujete úplně v pohodě. NAT a jednoduchý FW bude dávat odhadem 5-6Gbit trafficu.

U x86 je dle mého názoru u Mikrotiku problém v podpoře a vývoji k platformě. O čemž svědčí poměrně "stará" verze kernelu. Nepodpora 3 a více let starého hw (síťovky), staré drivery k síťovkám a nemožnost si nastavit driver dle vlastního uvážení.

Je třeba být si vědom limitu(ů) každé platformy a technologie. Máme nyní 2ks CCR a "zatím" nebyl žádný větší problém. DDOS to samozřejmě složí, ale to složí i x86.
Přes jedno CCR jede +-1Gbit, NATuje, lehký FW, a shaping PCQ v HTB vytížení cca. 20-26%, určitou dobu jsem na tom měl i cca. 2tisíce SQ pro shaping kliošů s WIFI a vytížení bylo někde kolem 30-35%.

U x86 se může pokazit spousta věcí. To riziko lze snížit výběrem dobrého HW, ale nikdy to nebude 100%. Různých failů, za ty roky bylo.
Důležité je mít topologii bez SPOF.
Nicméně shapery mám na x86 s Linuxem. Do budoucna uvažuju nad využitím SDN, resp. switche s openflow a controleru na x86.
0 x


Zpět na „Hardware“

Kdo je online

Uživatelé prohlížející si toto fórum: Bing [Bot] a 3 hosti