Dotaz: 10Gbit síť pro domácí pracovnu

[Michal]

Zdravím. Aktuálně mám následující setup

Workstation

Datové uložiště

ESXi s hromadou virtuálů bez lokálního úložiště (ESXi neumí snapshoty, které nutně potřebuji proto to řeším externě)

To vše je propojeno 1Gbit switchem, který neumí teaming.

Tento setup mi vyhovuje ale celé to zabíjí velmi pomalá síť (propustnost při sekvenčních operacích je cca 110MB/s tedy asi tolik, kolik by se dalo od 1Gbit čekat přičemž úložiště "dá" asi pětinásobek).

V síťařině se nevyznám proto bych se chtěl zeptat, zda bude fungovat následující kombinace

1x XS708E + 3x X540-T1

Případně zda koupit 3x X540-T2 a zapojit to do takového kruhu (teoreticky když intenzivně síťuje server s DÚ a asoučasně WS s DÚ, tak by to mohlo být i lepší a cenový rozdíl je zanedbatelný).

Nebo extrémní varianta - koupit X540-T2 i s tím switchem a zprovoznit teaming?

Ještě je otázka kabeláže. Vyplatí se připlatit za cat 6a i když je vše v jedné místnosti?

Předem díky za rady.

Odpovědi

[PanZvedavy]

Pokud je "uloziste" PC s diskama, tak nejlevnejsi a nejjednodusi bude koupit 10GbE sitovky(SFP, ne 10Gbase-T) na ebay a propojit to naprimo. 10GbE switche jsou porad relativne drahe a spotreba neni zanedbatelna. Pokud je vse v jedne mistnosti, tak neni co resit.

[Michal]

Napřímo? Mám 3 počítače takže mám koupit 3 sady třeba něčeho takového http://www.ebay.com/itm/HP-Mellanox-10GbE-SET-2x-Connext-2-1Port-10GbE-inkl-3M-SFP-Kabel-671798-001-/371847305798?hash=item5693d39a46:g:rmAAAOSw44BYhxBY ?

[PanZvedavy]

Do datoveho uloziste, o ktere tu evidentne jde, se da dvouportova vartianta karty a do esx a ws se da jednoportova. Prostredky uloziste se pak zpristupni klientum tak, ze pujde veskera komunikace (NFS?, ceph?, iscsi? cokoliv) pres 10GbE a standartni protokoly jako je ssh,www,rdp cokoliv pujdou jako doposud, aby byli dostupne pres sit i mimo 10GbE.

[Michal]

To zni dobře. Ještě se zeptám, jaká je výhoda/nevýhoda oproti stejnému řešení založenému na 10Gbase-T ? Nové X540-T2 z číny se dají pořídit také za cca 2900,- za kus.

[PanZvedavy]

Spotřeba, teplo

[Michal]

Bude mi s

MNPH29D-XTR MELLANOX 10Gbe ETHERNET DUAL PORT CONNECTX-2 SFP+ 5.0GT/S fungovat 5m Genuine Cisco SFP-H10GB-CU5M 10G SFP+ Direct Attach Copper Twinax Cable

? Jsem z tech SFP nějaký zmatený Případně nějaký odkaz, kde je vysvětleno jaký druh kabelu se používá kdy a s čím je kompatibilní.

[PanZvedavy]

Podle popisu ano. Odkazu je na netu plno ... http://www.fiber-optic-equipment.com/sfp-direct-attach-copper-cable-wiki.html .

[Max]

DA (Direct Attach) je pasivní propojení mezi dvěma optickými SFP+ porty (jedná se o all-in-one tlustý kabel, který má na obou stranách pasivní SFP+ moduly). Klasické SFP+ moduly jsou aktivní. Rozdíl je v tom takový, že pasivní propojení je vhodné na pár metrů (v rámci serverovny, racků apod.). DA kabel je hodně tlustý a je tak odolný vůči fyzickému poškození. Obyčejný optický patch kabel bývá tenký a nebývá problém ho neopatrnou manipulací poškodit (omylem zlomit apod.).
Použitím SFP+ modulů pak můžeš dosáhnout vzdálenosti třeba 10km.
A teď pozor, některé síťové karty, co se prodávají, jsou určené jen pro DA, aktivní SFP+ modul v nich nepojede. Dále některé karty mají sw lock pro určitého výrobce SFP+ modulů. Naposledy jsem tak řešil Intel. Donedávna měl parametr při zavádění modulu, který povoloval OEM SFP+ moduly. To pak později myslím úplně odstranily.
Je to jen příklad. Prostě varování, aby jsi si před koupí takové věci zjistil (aneb jen switche nemívají sw lock, ale i síťové karty do pc).
Zdar Max
PS: my jedeme v jobu OEM moduly, vyrábějí se s upraveným čipem pro konkrétní výrobce, cena je většinou desetina toho, co je origo, takže se to silně vyplatí. Jinak DA origo kabel vyjde většinou jen o fous dráž, jak kdyby jsi kupoval 2x aktivní OEM SFP+ moduly a k tomu optických patch kabel na propojení. Pokud řešíš propojení v rámci místnosti, použij DA karty (jsou o fous levnější jak ty, co podporují aktivní SFP+ moduly) a k tomu DA kabely.

[hw]

Omezení na konkrétní SFP+ mají skutečně karty Intel (a pravděpodobně Intel prodávaný jako HP, Lenovo, apod.). Modul ixgbe v Linuxu ale má stále parametr allow_unsupported_sfp, který umožní zavedení ovladače i s "nepodporovaným" SFP+ transceiverem. Ve Windows má zákazník smůlu a karty fungují pouze s moduly Intel. Bezproblémové jsou třeba karty Myricom, které fungují se všemi SFP+ moduly a výkonově se Intelu vyrovnají. Teď jsem zrovna dokončil nějaký HW, který sype po dvou agregovaných 10Gbps linkách plných 20Gbps do PC a NIC Myricom to zvládají stejně dobře jako Intel.

Alternativou by mohly být karty NBASE-T (IEEE 802.3bz), které jsou i na 10Gbps spotřebou už dost jinde oproti 10GBASE-T. Není problém používat levnější kabely Cat.5e, Cat.6 a ne pouze Cat.6a a výše. Maximální rychlost i spotřeba (a teplo) pak závisí na kategorii kabelu a jeho délce. Problém je, že zatím toho na trhu ještě moc není. Používám třeba karty Tehuti, které fungují dobře na 1/2.5/5Gbps, ale na 10Gbps ve výkonu začínají oproti Intelu ztrácet. Při konstantním datovém toku končí někde kolem 8-9Gbps.

[Max]

Z origo driverů to Intel odstranil někdy kolem roku 2012, pak vznikl patch pro kernel. Navíc já to řešil u FreeNAS (FreeBSD). A tam to by default v kernelu není, resp. dle threadu z roku 2013, možná to v aktuálním bude. Nakonec jsem to vyřešil jinak, takže jsem se o to dál nezajímal.
Zdar Max

[Michal Kubeček]

a výkonově se Intelu vyrovnají

Ne že bych si myslel, že Intel je pupek světa a nic jiného se mu nemůže vyrovnat, ale tohle může být trochu zrádné. Uživatel zkusí pustit netperf, ukáže mu to něco jako 9400, tak je spokojen a už se neptá

• jaká při tom byla zátěž procesoru
• jak se to bude chovat, když tam bude posílat data víc paralelních spojení
• jestli rozumných čísel dosáhne i v případě, že tam bude něco navíc (VLAN, nested VLAN, VXLAN, GRE, …)
• atd.

Samozřejmě že pokud spolehlivě víte, že nic z toho nepotřebujete (a ani nikdy nebudete), může vám to být jedno. Ale už jsem párkrát viděl, jak se zákazník najednou moc divil, proč má s 10G kartami propustnost jen 1.5 Gb/s.

[frr]

Před skoro 10 lety mi tu a tam prošla rukama nějaká 10GbE síťovka od Myricomu. Tehdy platívalo, že intel patří co do průchodnosti k tomu horšímu, Myricom byl docela dobrý, progresivní značka co určovala trendy, lepší průchodnost měly jenom super-drahé měřící karty které dávaly drobné pakety plnou rychlostí (wire speed). Pravda je, že Q-in-Q od síťovek Myricom tuším naši zákazníci nechtěli, ale nějakých "více toků zároveň" je snad základ, co by síťovka měla umět zcela transparentně Ani nevím, jestli má/měl Myricom nějaký TCP offload engine...

[Michal Kubeček]

ale nějakých "více toků zároveň" je snad základ, co by síťovka měla umět zcela transparentně

V dnešní době víceprocesorových systémů hraje dost velkou roli, jak funguje RSS a podle čeho to umí rozhazovat.

Ani nevím, jestli má/měl Myricom nějaký TCP offload engine...

Intel karty např. typicky umějí generický checksum offloading (NETIF_F_HW_CSUM), takže není potřeba, aby karta řešila každý protokol nebo kombinaci protokolů zvlášť.

[Vantomas]

Na allow_unsupported_sfp pozor. Měl jsem pasivní SFP+ kabely vyhrabané ze šuplíku, nějaký OEM, naprosto nevím jakého výrobce, ani pro jakého se to mělo jako tvářit. Byl přímý propoj mezi switchem a serverem a po pár hodinách provozu při cca 2gbit/s kernel panic způsobený ixgbe. Na mailing listech jsem se dozvěděl, že nepodporované moduly opravdu můžou něco takového způsobit, ale řešilo se to ve vztahu k aktivním modulům. I přes to jsem se rozhodl koupit pasivní kabely od Intelu a od té doby to běží rok v kuse.

[frr]

Tenhle nápad cucám z prstu: DA kabely se historicky používaly taky na FibreChannel, ovšem do SFP slotů (za mých časů 1/2/4 Gbps). Netuším, jestli jde SFP DA kabel zasunout do SFP+ slotu - nezkoušel jsem, možná nejde. Pokud by šel, možná jste si naběhl na toto Typ transceiveru je kódovaný v SPD EEPROM, ale SFP+ a SFP mají zřejmě shodný kód...

[frr]

Mmchdm... kernel panic způsobený vadným pasivním kabelem? To je taky žůžo Čekal bych, že bitwise chybovost se projeví maximálně na počítadlech CRC chyb v ifconfigu, ale hardware síťovky si z toho na záda nelehne. MAC čip síťovky by teoreticky mohl blinkat třeba z tepla, kdyby ten noname kabel měl neoptimální VF impedanci nebo mizerné PSV (teda spíš skoro zkrat) takže by SERDES transceivery v MAC čipu byly tepelně přetížené. Ještě mi vrtalo hlavou, jestli by se nemohlo jednat o bordel na interním rozhraní na způsob MII, které by třeba mohlo mít dodatečné nároky na konzistenci dat - ale asi nemohlo, protože SFP+ používá zřejmě výhradně SFI (single-lane SERDES), XGMII/XAUI/XFI jsou minulost (používaly to starší a proprietární formáty transceiverů).

Nebo si dovedu představit, že čínský optický transceiver bude topit jako kráva a přehřívat hostitelskou kartu. Taky nám jeden výrobce switchů (který údajně "nekóduje" transceivery, ale reálně je na ně vybíravý, asi má seznam) tvrdil, že některé noname transceivery mají natolik nesprávně zapojené piny v SFP konektoru (reserved? napájecí? nevím) že jde napájení do zkratu. To pak nehrozí kernel panic, to pak hrozí požár

[Petr Tomášek]

Kernel panic jako marketingový tah .

BTW, ty povídačky o požáru budou asi ze stejné kategorie..

[frr]

Ohledně požáru: jojo, asi tak... na druhou stranu, ono v extrémním případě opravdu může záležet, jaký humus kdo kde koupí za pár korun (DX, E-bay) a nebojí se ho strčit do značkového switche. Ještě dobrá varianta je, že koupíte noname moduly na lokálním trhu a jsou na ně už nějaké dobré reference, firma co je prodává nejsou úplné lamy.

Při té debatě o SFPčkách došlo i na obsah SPD EEPROMek a zejména noname číňani zřejmě na normu moc nehledí... a značkoví výrobci (Cisco?) zase obsah SPD EEPROM důsledně nekontrolují, když přijmou jako "fajnové kódované" čínské pajcy, které mají prázdné Vendor ID a nesmyslný "typ transceiveru" (kde je jasně řečeno že 0x03 == SFP/SFP+). Hlavně že sedí proprietární checksum kdesi na konci

Ohledně "reserved" pinů třeba i napříč generacemi nějaké normy jsem vycvičený z PCI a PCI104. Zažil jsem situace, kdy "reserved" pin byl na mothereboardu uzemněný a na kartě přitažený natvrdo na +Vcc (přestože novější varianty normy připouštěly "pull-up odpor na log.1"). Nebo na kartě VIO (napájení pro IO budiče) spojeno natvrdo třeba s +5V, kdežto motherboard měl možnost nastavit VIO na 3.3... Pinout SFP má naštěstí relativně malý počet pinů, ale čínskou vynalézavost a zlepšováky bych nepodceňoval

[Tomáš Bžatek]

Daji se ty Tehuti nebo obecne Aquantia karty sehnat za rozumnejsi penize, nez nejakych 200E? (porovnavam s Intel X540-T1, kde ty ceny docela klesaji...)

[hw]

Bohužel neporadím. Pro mě je PC NIC jenom prostředek pro vývoj a ladění hardwaru na druhé straně, takže cena mě nezajímá.

Jenom bych přidal takovou obecnou poznámku k NBASE-T PHY. Produkty Aquantia stojí dost za prd a je lepší se jim vyhnout. Z toho důvodu bych se pro nějaké masové nasazení snažil vyhnout i finálním produktům založeným na čipech Aquantia, především jejich první generaci. Marvell nebo Broadcom je kvalitativně i funkčně někde jinde. Bohužel Marvel teď teprve najíždí na masovou výrobu a Broadcom je pořád ještě na úrovni vzorků pro vývojáře.

Předpokládám, že NBASE-T produkty za normálnější ceny se začnou objevovat během letošního roku. Spíše asi až ke konci.

[frr]

S těmi tlustými kabely je to dvojsečné. Zaberete víc nebo zakopnete, a vylomíte konektor na kartě. Ještě že mají SFPčka tak "hluboký kořen". Taky je fajn, že v těch DA kabelech bude možná jenom pár tam a pár zpátky, tzn. dva twinax páry. Docela tlusté, kvůli šířce pásma, ale jenom dva páry. SCSI kabely bývaly taky tlusté, ale párů tam bylo moooc, a o vakly nebyla nouze. BTW starší CX4 metalická kabeláž pro 10GbE měla tuším 8 párů twinaxu (konektor jako Infiniband), ale to už je myslím dávno pryč.

Tenký ohebný optický patchcord se mnohem snáz skládá do lišt než tlusté metalické bago.

[frr]

Ještě mě napadá, metalický Base-T ethernet i optika mají galvanickou izolaci. Nevadí vandrování zemních potenciálů mezi "sousedy na kabelu". Jakpak je to u DA kabelů? Signálové páry jdou beztrestně oddělit kapacitně (a patrně oddělené budou), ale ono to bude mít dost důkladné stínění... aby nevznikaly problémy taky třeba zde, a možná ani ne tak rušením do přenosu (vzhledem k taktu), jako spíš "příčnými proudy" někudy skrz vnitřní země v počítačích Jako že se karta poblinká, když potečou zeměmi nějaké vyrovnávací proudy

[Michal]

Díky všem za pomoc. První fázi (propojení pracovní stanice s datovým úložištěm) mám dokončenou. Netperf jsem nezkoušel ale velké soubory sviští rychlosti 520 MB/s. Víc nedají disky ani na jedné straně takže úzké hrdlo bude v nich.

Na dvojportovou kartu a další SFP+ kabel teprve čekám tak zatím studuji jak pak nastavit routy aby ten prostřední bod (dvojportová síťovka IP 192.168.1.4 a .1.5) pochopíl, že má sloužit zároveň jako router mezi krajními body (.1.2 a .1.3). Zatím nemám tucha, jak na to.

Celková cena se vejde do 5000 což je o dost méně, než s čím jsem počítal.

[Michal Kubeček]

jak pak nastavit routy aby ten prostřední bod (dvojportová síťovka IP 192.168.1.4 a .1.5) pochopíl, že má sloužit zároveň jako router mezi krajními body (.1.2 a .1.3).

Pokud nemáte nějaký zásadní důvod, proč ty adresy nastavit zrovna takhle, doporučoval bych nekomplikovat si zbytečně život a spíš použít něco jako 192.168.1.2/24 na jedné straně, 192.168.2.3/24 na druhé a na té dvouportové 192.168.1.1/24 a 192.168.2.1/24.

Pak na tom prostředním nepotřebujete nastavit nic zvláštního, stačí povolit forwarding. Routy potřebujete nastavit na těch zbylých dvou, aby věděli, kam posílat pakety pro sebe navzájem.

[frr]

Pokud byste to chtěl všecko v jednom IP subnetu, tak soft-bridge. V Linuxu brctl.

[Michal]

Něco takového zabere?

brctl addbr mybridge

brctl addif mybridge p2p1
brctl addif mybridge p2p2

ifconfig p2p1 0.0.0.0
ifconfig p2p2 0.0.0.0

ifconfig mybridge 192.168.1.2 netmask 255.255.255.0 up

[Michal Kubeček]

Přeloženo z archaického jazyka:

  ip link add mybridge type bride
  ip link set p2p1 up
  ip link set p2p1 master mybridge
  ip link set p2p2 up
  ip link set p2p2 master mybridge
  ip addr add 192.168.1.2/24 brd + dev mybridge
  ip link set mybridge up

Otázka ale je, proč si s tím komplikovat život.

[Michal]

Aby konfigurace na krajních bodech mohla být co nejsnazší. Úložiště žije dlouhé roky bez zásahu ale pracovní stanice i virtualizační server se mění relativně často.

[frr]

Jojo... Postaru bych na ty L2-only rozhraní v bridgi provedl jenom

ifconfig eth0 up

ifconfig eth1 up

Off topic: dají se s tím soft-bridgem dělat všelijaké kejkle. Třeba když potřebujete "odposlechovou sondu" na sniffování, klidně mezi nestejně rychlými L2 porty - zakážete STP a zkrátíte "délku pamatování naučených MAC adres" na nulu, a získal jste něco jako hloupý hub... Já vím, normální lidi k témuž používají port mirroring na switchi

[frr]

Máte nakonfigurovanou jumbo frame size? A těch 520 MBps dostanete až do user space? Kdysi jsem se musel hodně snažit, abych tu linku vystropoval, mezi dvěma linuxovými kompy, z nichž jeden měl RAID schopný asi 1200 MBps a pár GB RAMky. Zkoušel jsem to i proti té RAMce. Tuším jsem na tom "storage" stroji musel rozjet in-kernel iSCSI target (SCST) abych minimalizoval kopírování user space / kernel space, a ještě se tam dalo volit, jestli má jet "direct" nebufferovaně proti fyzickému blokovému zařízení (forwardovat SCSI requesty) nebo jestli má jet skrz systémový buffer blokové vrstvy (VM). Podle charakteru provozu byla ta či ona možnost rychlejší. Úzkým hrdlem nebyl Myricom HW, ale režie těch několika softwarových vrstev.

[Michal Kubeček]

Máte nakonfigurovanou jumbo frame size?

S funkčním GSO/GRO na tom moc nezáleží. Zrovna tenhle týden jsem dělal nějaké testy a ani při defaultní MTU 1500 nebyl problém nasytit přímý 10Gb/s spoj při nezajímavé zátěži procesoru. Nakonec jsem si tam musel dát tisícovku netfiltrových pravidel, abych vůbec měl co měřit.

[Michal]

Díky za nakopnutí, nastavil jsem MTU na 9000 a vypadá to, že to zrychlilo u přenosů z cache.

[Michal Kubeček]

Jestli jde o TCP a to zrychlení je výraznější než jednotky procent, tipoval bych, že máte aspoň na jedné straně něco špatně (nebo aspoň neoptimálně) nakonfigurováno. Doporučoval bych začít s "ethtool -k".

[Michal]

Features for p2p1:
rx-checksumming: on
tx-checksumming: on
        tx-checksum-ipv4: on
        tx-checksum-ip-generic: off [fixed]
        tx-checksum-ipv6: on
        tx-checksum-fcoe-crc: off [fixed]
        tx-checksum-sctp: off [fixed]
scatter-gather: on
        tx-scatter-gather: on
        tx-scatter-gather-fraglist: off [fixed]
tcp-segmentation-offload: on
        tx-tcp-segmentation: on
        tx-tcp-ecn-segmentation: off [fixed]
        tx-tcp6-segmentation: on
udp-fragmentation-offload: off [fixed]
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off [fixed]
rx-vlan-offload: on
tx-vlan-offload: on
ntuple-filters: off [fixed]
receive-hashing: on
highdma: on [fixed]
rx-vlan-filter: on [fixed]
vlan-challenged: off [fixed]
tx-lockless: off [fixed]
netns-local: off [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: off [fixed]
tx-gre-segmentation: off [fixed]
tx-ipip-segmentation: off [fixed]
tx-sit-segmentation: off [fixed]
tx-udp_tnl-segmentation: off [fixed]
tx-mpls-segmentation: off [fixed]
fcoe-mtu: off [fixed]
tx-nocache-copy: on
loopback: off
rx-fcs: off [fixed]
rx-all: off [fixed]
tx-vlan-stag-hw-insert: off [fixed]
rx-vlan-stag-hw-parse: off [fixed]
rx-vlan-stag-filter: off [fixed]
l2-fwd-offload: off [fixed]

[Michal Kubeček]

Tohle vypadá dobře, jestli to tak vypadá i na druhé straně, bylo by dost překvapivé, že by MTU 1500 vs. 9000 znamenalo nějaký výraznější rozdíl.