Van két HP Proliant ML350 G6 vasam. A két gép között kellene valahogy gazdaságos módon a mostani gigabitesnél gyorsabb(*) hálózati kapcsolatot megvalósítani. (több gigabites port LACP-vel trönkölése nyilván nem játszik, mert akkor egy szál max. 1Gbittel tud forgalmazni, kivéve ha mindkét végén Linux van, round-robin módban, jól sejtem?)
A legegyszerűbb 10GbE kártya, amit találtam, az Intel AT2 (i82598EB) ami kb. 135.000 Ft+ÁFA/darab. Egyetlen link kedvéért tehát legalább 270.000 Ft+ÁFA-t kell leszurkolnom, ami erősen elgondolkodtat, hogy egyáltalán akarom-e? (Van ennél jobb ötlete valakinek?)
A következő kérdés pedig előbb-utóbb az lesz, hogy mi a legolcsóbb, legalább 2 darab 10GbE portot tartalmazó switch...
(*) nyilván nem akarok 1-1 géppel 10Gb-et plafonig kitömni, már a 2Gb is egy nagyszerű előrelépés volna.
Hozzászólások
Amennyiben <10m-en belül van a két gép, akkor a legolcsóbb ethernet megoldás két 10g ethernet kártya, aminek SFP+ portja van, és egy Twinax kábel.
(Szerintem LACP-t a legtöbb oprendszer támogat, de nincs ezzel közvetlen tapasztalatom.)
Az általam említett rezes megoldás (10GBase-T) nem olcsóbb az SFP-nél?
Meg kellene nézni, hogy melyik az olcsóbb. A Twinax (más néven direct attach) megoldás azért jó, mert nem kellenek SFP+ modulok, a kábel közvetlenül az SFP+ slotba csatlakozik. 10GBase-T-nél sokkal stabilabb kapcsolatot jelent, de távolság erősen korlátozott.
A távolság a két vas között van vagy 30 centi :)
A kábelt sok esetben nem fogod tudni 30 centire betolni, különösen ha fullos kábel rendezővel van beszerelve. Az rögtön +1-1 méter, hogy egy minimális ráhagyásról ne beszéljünk. Tehát érdemes a kábelhosszokra figyelni, még ha itt nem is lényeges. :) A 2x1Gbittel sokkal olcsóbban megúszod a dolgot és a LACP-nál csak a megfelelő LACP módot kell beállítani oszt szaladni fog. Minden esetre, ha csak időbe kerül a tesztje akkor próbáld ki.
Ha a "sima" gbites portjaid intel kártyákból jönnek akkor 16384-es MTU-t (egyébként 9k) is be tudsz állítani valamint egy kis TCP tuninggal feljebb lehet picit tornázni a kraftot. Ez a 2x1G-s összefogásra is igaz, de ha a 10G-be belevágsz akkor ott főleg.
> A kábelt sok esetben nem fogod tudni 30 centire betolni, különösen ha fullos
> kábel rendezővel van beszerelve. Az rögtön +1-1 méter, hogy egy minimális
> ráhagyásról ne beszéljünk.
Ha akár a réz, akár az üveg nem visz át akkora távolságot, ami két, közvetlenül egymás mellett elhelyezett gép között van, akkor azt ne nevezzük hálózati közegnek :)
(Márpedig a 10GBase-T szabvány elvileg nem csak papíron, illetőleg laboratóriumi körülmények között működik)
Jelen esetben nyilván nem probléma a 2-3 méter, csak az ilyen "óhát csak 30 centi, 50 centi, 1 méter" kezdetű dolgokkal én már inkább óvatós vagyok. :)
És mi fogja kitölteni az a 10G-t?
> És mi fogja kitölteni az a 10G-t?
Semmi. Olvassál! :)
"nyilván nem akarok 1-1 géppel 10Gb-et plafonig kitömni, már a 2Gb is egy nagyszerű előrelépés volna."
Közönséges fájltranszfer megy, némiképpen nagyobb fájlokkal. A jelenleg elérhető kb. 110MByte/sec pillanatnyilag a palacknyak. (A RAID röhögve kiszolgálja ennek a két-háromszorosát)
Esetleg két gigás hálókártya bondingolva?
Te is olvassál :)
(Etherchannel még IP hash-sel is csak 1x wirespeedet tud 1 IP/port esetén. Márpedig a fájltranszferem alapból ugye nem többszálú...)
Akkor mar viszont felmerul bennem egy erdekes kerdes: mivel viszed a fileokat? Nem lehetne ezt tobbszalusitani? Nem tudom, mennyire kell gazdasagosnak lenni, de onnantol mar tengernyi megoldas van a feladatra, akar mindenfele routingos varazslas is jatszhat.
ettercsannel mukodhet lin es win kozott is... csak intel kartya kell a win oldalra, mert abba van biztos teaming.
--
no de ettercsannel két gép között (1 darab TCP adatfolyamban) az max. 1x wirespeedet tud, nemdebár?
Linux oldalon bondingrol beszelunk, szal elvben nem. ugyan valoban felvaltva kuld a ket kabelen, azonban annyira gyorsan valtogat koztuk, hogy a sebesseg dupla (de legalabb masfelszeres) lesz.
--
Hö? Ha egy TCP adatfolyamról beszélünk, akkor SZVSZ egy dekányi váltogatás sem lesz még xmit_hash_policy=layer3+4 módban sem. (vagy én értek félre valamit?)
Egyébként pedig nem feltétlenül Linuxról beszélünk.
ne haragudj, hrgy, de latszik, hogy nem volt meg a kezeid kozott tobb darab komolyabb szero, amiken bondinggal/LACP-vel/etchechanellen kiserleteztel...
nem fog egy kapcsolat, pl. egy fajlmasolas wirespeednel tobbet tudni.
hmmm....
emlékszel még? réges régen volt ISDN64 meg volt ISDN128 is. Vagy van pl. 4 db SHDSL vonalunk van összefogva, egyenként 5Mbit/s de ki tudom hajtani a 19Mbit/s-et.
Ha a 4x1Gbit trönköd két végére odateszel két loadbalancer eszközt, ami képes arra, hogy a trönk komponensei között per-packet alapon elossza a forgalmat, akkor egy felette lévő OSI layeren ki fogod tudni forgalmazi a 4Gbitet.
Az LACP/etherchannel/bonding/mittudomén viszont alapból Layer2-ben, per-MAC alapon működik, és két MAC között by default sosem fogsz wirespeed fölé menni. Néhány eszköz támogat IP hash alapú mókát, amikor per-IP illetőleg per-port alapon tudja neked szétdobálni a forgalmat, de egy TCP stream akkor is max. wirespeed marad.
A Linux bonding megoldásában van propietary load balancer, így két, "szembefordított" Linux között tudsz 4Gbitet forgalmazni.
ISDN esetében multilink PPP-t csinálsz, így az abba enkapszulált IP protokollod már ki tudja tömni a dupla sávszélt. Tessék nézelődni az OSI layerek terén :)
De szép is volt ez így...
Aztán melyik _használatos_ stack valósítja meg az ISO/OSI 7 rétegét leírás szerint passzentosan?
nem válaszoltad meg a saját kérdésedet?
Az MS technet szerint a windows tud multilink PPP-t,
két független etherneten nincs annyira jó, mint két független ISDN?
távol áll tőlem a ppp, azt se tudom, hogy merre mi van, csak te írtad.
tcp/ip kapcsolat nem point-to-point kapcsolat. PPPoE kéne ahhoz, hogy ethernet fölé ppp-t csinálj.
Szerintem kellene neki, bar nyilvan nem vagyok halozatos... de ez a valtogatas joval a TCP/IP szint alatt megy, mindket gep szamara az etterchannel 1 darab interfeszkent latszik. Nyilvan mindket oldalra bondingot kell konfiguralni a kabelekre, meghozza pont ugyanugy beallitottat, de ez annyira sztem nem bonyi. Mindenesetre szerintem a TCP nem is fogja tudni, hogy hany kabelen ment at, mert a tuloldalon egyben, egymas utan jonnek ki a packetek a bonding/teaming interfeszbol. Talan, ha L2-ben lehetnek problemak, de L3 es felette semmikepp.
--
elvileg én is igy gondoltam, aztán a gyakorlat mást mutatott, nálam sokkal nagyobb tudású szakemberek meg felvilágosítottak, hogy az elméletem hibás, s a gyakorlat nem fog változni emiatt, egy-egy szálon nem fogok tudni 1Gbit-nél nagyobb sávszélen forgalmazni.
Én 4db 1Gbit-es interfacet fogtam össze, iperf mutatott rá 960-970Mbit-et, viszont ezt négy gép felé tudta.... De olyan sohasem volt, hogy egybe lett volna 4Gbit sebesség...
kicsit guglizz es informalodj a postjaid elott, mert az elmult hetekben annyi zoldseget olvasok toled, hogy kezd fajni. plz.
Mindenesetre szerintem a TCP nem is fogja tudni, hogy hany kabelen ment at, mert a tuloldalon egyben, egymas utan jonnek ki a packetek a bonding/teaming interfeszbol
De sajnos tudja, mert eppenhogy nem garantalja semmi, hogy sorrendhelyesen jonnek ki a bonding intefacebol. Default parameterekkel a TCP nem viseli igazan jol, ha a csomagok sorrendje megvaltozik. Eleg sokat kell jatszogatni a beallitasokkal, hogy legalabb valamennyire ki tudjad hasznalni a tobb link egyuttes ateresztokepesseget.
Amit irtam az a round robin uzemmodra igaz (es ez afaik nem szabvanyos, a Linuxos bonding driver tudja, de hogy mas is tudja-e az kerdeses). A tobbi uzemmodban (pl 802.3ad) egy stream csomagjai egyaltalan nincsenek szetosztva a ket interfesz kozott, vagyis egy kapcsolat nem tud egyszeres link sebesseg felett menni, cserebe viszont nincs gond a csomagok sorrendjevel.
---
Internet Memetikai Tanszék
Ha esetleg használt cuccokban is gondolkodsz: http://www.ebay.com/itm/Chelsio-S310E-CXA-Single-Port-10GBASE-CX4-S310-…
Többet mondjuk nem találtam, de idővel biztos lesz.
http://www.youtube.com/watch?feature=player_detailpage&v=FuQl8raXrD8
____________________________
www.szerverplex.hu
Add el a két szervert, vegyél egy nagyobbat, virtualizálj, és virtuális hálókártyán menni fog a 10 GB :) Nem ismerem a helyzeted, de még akár magát a másolást is teljesen megúszhatod így.
--
joco voltam szevasz
:)
Sőt, ha sikerül megoldanom, hogy a házamba beköltözzön a youtube, google, hup, (stb.) akkor végsősoron még Internet-kapcsolatra sem lesz szükségem :)
Eleg, ha csak az Amazon koltozik be hozzad. :) Az internet tekintelyes hanyada mar rajtuk fut.
---
Internet Memetikai Tanszék
Sok hasznos tippet olvastam itt, köszi! (mondjuk, h subscribe)
Csak egy felvetés a tapasztaltabbakhoz: Ilyen kis távolságokra (max. 2m) nem létezik valami, ami - akár sok-sok éren, mint pl. a SCSI régen - kvázi alapi bus sebességen összeköthet 2 gépet?
iSCSI-ra gondolsz?
Nem írta mondjuk a kolléga, hogy hogy is megy át az adat, de mondjuk iSCSI és multipath még akár jó is lehet neki. Talán.
Nem iSCSI, a SCSI-t (a régi klasszikust) csak azért említettem, hogy régen nem próbálták 1 érpárba vagy 1 optikai szálba beletuszkolni/-modulálni az adatforgalmat, hanem kikábelezték a 8/16/32 bites adatbuszt az eszközök között. 1 racken belül 1-2m-en megoldható lenne akár 64 biten is - 100m-eken persze nem.
Egy kis problémát vet fel, hogy ekkora sebességnél már nehéz garantálni, hogy a párhuzamos adatok egyszerre érkezzenek, ne csússzon széjjel a kommunikáció. Külön szinkronizációt kéne bevezetni a szálak közt, az meg nagyobb overhead-del járna...
Értsd: sebesség szempontjából jobban megéri a soros kommunikáció mint a párhuzamos.
Ebből is tanultam valamit. Azért a "hülye" felvetéseknek is van haszna :)
Szerintem amúgy tök logikus a felvetés, annyira nem triviális a válasz, eddigi tapasztalataim szerint viszonylag kevés embernek ugrik be a szinkron problémája elsőre.
+1 a felvetés teljesen jó volt, sőt, vannak optimális megoldások is a szinkronizálásra (csak az ilyen eszközök horror árban vannak).
Annyi történik, hogy egyrészt olyan minőségü kábelt használnak, hogy a szálak közötti különbségek ne legyenek annyira nagyok, másrészt x időközönként szinkronizálnak (mérik a szálak késleltetését) és szálanként használnak egy buffer-t. A megfelelő eltolásokkal a legnagyobb latency-vel rendelkező szállal fognak közlekedni az adatok, a két oldalt meg megfelelően potyognak ki a bufferből.
Szóval az elved teljesen jó, csak tényleg horror árban vannak ezek a dolgok. Én is egyszer láttam ilyen eszközt és kissebb fajta szent tehénként kezelték, a maga majd 30 milles árával (azt hiszem szálanként 4 Gbit, 32 szállal, max ~1m). Arra már nem emlékszem, hogy ez hogy kapcsolódott a géphez, mivel ekkora adatmennyiséget azért fogadni is teljesítmény;)
Bár a gépről nincsenek információim, de ezekszerint valami custom cucc lehet. Az egészet mérés adatgyűjtésre használták
Ha mérés adatgyűjtés, akkor nem lehet, hogy az adatok nagy részét maga a kártya feldolgozta és úgy adta át a gép felé?
Mert ha jól nézem (kövezzetek meg, de most googliztam csak utána), egy PCI-X buszos kártya tulajdonképpen ki sem tud tölteni egy 10G-s hálózatot, de PCI-E-ből is min 2x kell hozzá?
A kártya a mérési adatgyűjtőhöz csatlakozott, ami egy nagyobbacska rack szekrény méretet öltött (ennek az aggregált adatait továbbította a gép felé).
http://en.wikipedia.org/wiki/List_of_device_bit_rates
jó link. ahogy nézegettem, beugrott egy olyan h IPoverSATA(3) - ilyen nincsen még? anno volt IPoverSCSI, annak a mintájára esetleg...
a SATA3-as portok kb ingyen vannak és mindenhova integrálva - rövidtávú pont-pont összeköttetésekre tökjó lehetne (pl az épített storage és a kiszolgált gépek közé) és a 600mbyte/s sokkal több mint a 125mbyte/s (gigE)
Gondoltam rá már én is, de szerintem PCI Express alapú direkt pont-pont összeköttetés még jobb. Azzal a 10 Gbit simán megoldható. Lásd Thunderbolt...
nem kizárt, de a SATA3 kártyák igencsak olcsók és kb minden busztípusra vannak. PCI,PCI-X,PCI-E - van 1-2-4 ill. több portos
A refurbished Infiniband sem túl drága, ellenben a Thunderbolt-ra nem vennék mérget, hogy már megértek az applikációk...
ezen a "sok eren" dolgon most felrohogtem, nem kicsit. WTF?
Örülök, h örömet okozhattam! :)
mi ilyen vicces a parhuzamos adatkuldesben? nem hallottal meg rola? WTF?
Háát veszel régi 2Gbites fibre channel kártyákát, mondhatni már bagóért kaphatóak. Lehet vele próbálkozni.
Fedora 16, Thinkpad x61s
És hogy fog rajta FTP-zni?
Létezik olyan FC HBA ami tud Ethernetet is, bár nem hiszem, hogy gyakoriak lennének az ilyen kártyák az Ebay-en (pláne nem bagóért).
Miért kellene Ethernet az FC fölé? Mintha lovaskocsival szállítanák az autókat.
Nem fölé, hanem helyette. Éltem a feltételezéssel, hogy a "gigabitesnél gyorsabb hálózati kapcsolat" alatt Ethernetet ért a kérdező. Ezt erősíti a "közönséges fájltranszfer" megfogalmazás is, tehát FTP, NFS, CIFS vagy hasonló protokollon kell adatot átadni a szerverek között.
Így már értelek.
FC megnevezést 2 értelemben is használatos: egyrészt maga a protokoll, illetve a közeg(üvegszál). Ethernet protokollt használni az erőteljes hiányosságai miatt nem célszerű, ha lehetséges az elkerülése.
IP over FC már régóta létezik.
Ennek utánanézek, még jól jöhet.
IBM, illetve Qlogic kártyákkal építettem/tesztelgettem ilyet. Érdekes volt.
EoFC
Az ötlet értelmes, van is ilyen, és nem is túl drága.
az egyik az infiniband, a másik a pci-e. Mindkettő alaplapi csatlakozószabványnak indult, és mindkettő képes 'kilógni a gépből'.
Az infiniband az gyakorlatilag csak gépek közötti összeköttetésre van használva, ámbár alaplapi (kártyafogadó) csatlakozásra is alkalmas.
A pci-e pont fordítva, szinte csak alaplapi csatlakoztatásra használják, nem igazán mászik ki a gépből.
Egy 16 Gbit infiniband kártya ára alatta van a 10G eth kártya árának.
A probléma ezzel az, hogy mindenki IP -re fejleszt, nem infinibandre.
Így ez a busz-összeköttetésen van valami IP felület, és így mindenestűl már egy picit alá esik a 10G eth sebességének.
Az IPoIB létező dolog. (subs)
Végigolvastam a hozzászólásokat. Ezért én a helyedben FC-ben(2, 4 Gb-es kártyák olcsók) vagy iSCSI-ban gondolkodnék. iSCSI-nál megfelelő multipath beállítással elérheted a kívánt működést. Persze számolj nagy overheaddel is.
Tudtommal 10GE-nél kötelező a switch(direkt link nem működik) réz átviteli közeg esetében, így nem úsznád meg olcsón. Javítson ki valaki, ha tévedek.
Akkor ha van 2 gbit port mindkét szerverben, adni kell mindkettőre más más ip-t, és egyszerre pl 2 ftp/2 nfs stb vel mehet a több mint 1 gibt.
Fedora 16, Thinkpad x61s
Na, hát ennél még az LACP is fényévekkel jobb megoldás...
igen, de az lacp nem megy gép-gép között ahol csak 1-1 mac ed van, illetve megy csak 1Gbit lesz.
Fedora 16, Thinkpad x61s
szerk. felreertve:)
Helló
Ez itt talán megfelelő lehet
szombathelyi cég, rendes kiszolgálás futáros megoldással is szállítanak, precízek, szépen becsomagolva, sérülésmentesen szoktak megjönni tőlük a motyók.
http://www.interbolt.eu/category/h%C3%ADrlev%C3%A9l/interbolteu-h%C3%AD…
datasheet:
http://www.sandirect.com/documents/qlogic_QLE2464_datasheet.pdf
elméletileg ez tudja azt ami neked kell...
IP (FC-IP)
üdv
Balooo
------------------------
Nincs a világon se jó, se rossz. A gondolkodás teszi azzá... (W. Shakespeare)
Nem Sz.helyi, hanem Pápai, de a lényeg szempontjából lényegtelen :)
Kicsit szerintem "zizis" a srác, de ettől függetlenül jó minőségű, megbízható használt cuccokat árul számlásan.
2 linux direktben összekötve 2x1 gigabiten, round-robin bonding:
iperf -c 10.x.x.y
------------------------------------------------------------
Client connecting to 10.x.x.y, TCP port 5001
TCP window size: 64.0 KByte (default)
------------------------------------------------------------
[ 3] local 10.x.x.x port 28867 connected with 10.x.x.y port 5001
[ 3] 0.0-10.0 sec 1.78 GBytes 1.53 Gbits/sec
+ az egyéb forgalom, amit most nem tudtam kikapcsolni ezen a linken. Mivel direktben vannak összekötve, ezért out of order sem jelentkezik a csomagoknál.
Egyszer meg az egytemen egy kollegammal kiserleteztunk vele es nekunk is 1,4 Gbit/s korul jott ki. Ha raszanjuk az idot TCP tuningra talan tudtunk valamelyest javitani rajta, de ezek szerint nagyjabol ez a realis ami ebbol a megoldasbol kihozhato.
Mi is ket crossover kabeles osszekotessel csinaltuk. A tanszeken nem talaltunk egyetlen olyan switchet sem, aminel a ket porton round-robinban bejovo forgalom ne csak egy porton ment volna ki a masik node iranyaba. Pedig managelheto switch volt mind megfeleloen felkonfiguralt port bondinggal, igaz nagyjabol a 100eFt koruli es az alatti artartomanyban.
---
Internet Memetikai Tanszék
linux round-robin bondinghoz ket olcso, buta, egyszeru switch kell (abszolult szimetrikus konfigban).
Az en mereseim meg rosszabbak, olyan +10% -ot sikerult merni, merhetoen es jol lathatoan gyorsabb, mint az 1 Gbit, de nem sokkal.
iSCSI-t mertem, diszk terhelo programokkal. Olyan helyen, ahol a diszk 400MByte/s felett tudodtt irni, es 600MByte/s felett olvasni, es mertem cca 125MByte/s iscsi atvitelt, (1 etherneten 110MB/sec) a cpu nem volt agyonterhelve, a diszk sem, megsem ment feljebb. A meres orakig tartott.
iscsi-n nekem is ez volt.
De nekem rr se volt jobb, de jobban belegondolva az rr is csak 1Gbit csak gyorsan vált, mivel hol az egyik hol a másik karin küldi az adatot.
Fedora 16, Thinkpad x61s
Azt hiszem az 1.4 Gbit/s mar bekapcsolt jumbo frame-ekkel es valami tcp window parameter allitgatas utan jott ki. Nyilvan ezen lehetett volna meg tovabb optimalizalni, de mar nem sokat. Mi csak siman netcat-tal mertuk, bar vegul nalunk is iSCSI volt a cel. Aztan maradt alb uzemmodban, hogy legalabb tobb initiator kozott ertelmesen szorja szet a forgalmat.
---
Internet Memetikai Tanszék
Ha így használod, akkor az active-backup módnak több értelme lenne. Így olyan packet reordering lehet a buta switch-ek miatt, hogy az viszi el a sávszélt.
azt is mertuk. Reordering, resend, error nem volt.
hol merted? Nem tudom de lehet, hogy az ilyesmik offloadolva vannak egy normalisabb nic-ben bar nem ertek annyira hozza.
messzire vezet ez a kérdés-sor.
A rr bondding kontra iSCSI tesztbe belefektettünk cca 5 munkanapot. Ha nem is minden igényt, de legalább az összes saját kérdés megválaszolását szerettem volna, akkor az mintegy 150 munkanap.
Setup, test, mért nem megy ez jobban? nyomoz-nyomoz-nyomoz, lejárt az idő.
Sajnálom.
Abban a felállásban, amikor még nem szolgált ki aktívan a gép, akkor simán meg volt a 2 gigabit/s körüli érték. De ahogy írtam is, a round-robint csak akkor érdemes használni, ha direktben kötöd össze a gépeket, vagy max 1 aktív eszköz van a kettő között (ebben az esetben már lassabb).
Ezt ismered ? ;)
http://www.youtube.com/watch?v=lG5cEik2ABY&feature=related
Ez jó! :-)
"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."