Üdv,
Pár napja panaszkodnak egy kis hálózatban (5 gép), hogy a szerveren (CentOS8) az adatbázis elérése mintha lelassult volna. 4db kártya van a gépben:
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
3: eno2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
4: ens3f0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1460 qdisc mq state DOWN mode DEFAULT group default qlen 1000
5: ens3f1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DEFAULT group default qlen 1000A NO-CARRIER furcsa, de pingelni lehet.
sudo ethtool ens3f1
Settings for ens3f1:
Supported ports: [ ]
Supported link modes: 40000baseCR4/Full
40000baseSR4/Full
40000baseLR4/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 40000baseCR4/Full
40000baseSR4/Full
40000baseLR4/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Speed: Unknown!
Duplex: Unknown! (255)
Auto-negotiation: off
Port: Other
PHYAD: 0
Transceiver: internal
Supports Wake-on: d
Wake-on: d
Current message level: 0x00000007 (7)
drv probe link
Link detected: no
sudo ethtool ens3f0
Settings for ens3f0:
Supported ports: [ ]
Supported link modes: 40000baseCR4/Full
40000baseSR4/Full
40000baseLR4/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 40000baseCR4/Full
40000baseSR4/Full
40000baseLR4/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Speed: Unknown!
Duplex: Unknown! (255)
Auto-negotiation: off
Port: Other
PHYAD: 0
Transceiver: internal
Supports Wake-on: d
Wake-on: d
Current message level: 0x00000007 (7)
drv probe link
Link detected: no
sudo ethtool eno1
Settings for eno1:
Supported ports: [ TP ]
Supported link modes: 1000baseT/Full
10000baseT/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 1000baseT/Full
10000baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Speed: 10000Mb/s
Duplex: Full
Auto-negotiation: on
Port: Twisted Pair
PHYAD: 0
Transceiver: internal
MDI-X: Unknown
Supports Wake-on: g
Wake-on: g
Current message level: 0x00000007 (7)
drv probe link
Link detected: yes
sudo ethtool eno2
Settings for eno2:
Supported ports: [ TP ]
Supported link modes: 1000baseT/Full
10000baseT/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 1000baseT/Full
10000baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Speed: 10000Mb/s
Duplex: Full
Auto-negotiation: on
Port: Twisted Pair
PHYAD: 0
Transceiver: internal
MDI-X: Unknown
Supports Wake-on: g
Wake-on: g
Current message level: 0x00000007 (7)
drv probe link
Link detected: yes
A két optikai kártya érdekes: "Speed: unknown" és "Link detected: no".
Távolról látom én is a gépet.
- 528 megtekintés
Hozzászólások
ens3f0 és ens3f1: NO CARRIER és DOWN, azaz nincs kapcsolat/nincs bedugva semmi vagy csak nem lett beállítva.
a 2 db 1Gb-s kártya ugyannannak a hálózatnak a tagja?
A bonding miatt kérdezem, illetve hogy ha van akkor a switch is tud róla?
- A hozzászóláshoz be kell jelentkezni
egy hálózatban vannak. 192.168.1.*
Az egyik optikainak nincs IP címe valamiért. A másik pingelhető.
A eno1, eno2 rendben van.
- A hozzászóláshoz be kell jelentkezni
Gyanús hogy nem megy az ens3f0
ens3f0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1460 qdisc mq state DOWN group default qlen 1000
és a pingre a másik kártyán válaszol vissza mert tudja hogy az az IP is nála van.
Más kérdés mennyire jó megoldás x db kártya ugyanabba a hálózatba konfigurálasa bonding, teaming helyett.
- A hozzászóláshoz be kell jelentkezni
> Más kérdés mennyire jó megoldás x db kártya ugyanabba a hálózatba konfigurálasa bonding, teaming helyett.
semennyire. rakd ossze bridge-be vagy valami.
- A hozzászóláshoz be kell jelentkezni
Az egyik optikainak nincs IP címe valamiért.
Mert linkje sincs... ami kábel/switch problémára utal.
- A hozzászóláshoz be kell jelentkezni
Szerintem valami spanning tree baszta ki a switchen
- A hozzászóláshoz be kell jelentkezni
ha nincsenek bridge-ben az if-ek akkor a stp nem veszi eszre
masreszt stp nem veszi el a linket, csak blockolja a forgalmat
- A hozzászóláshoz be kell jelentkezni
ha nincsenek bridge-ben az if-ek akkor a stp nem veszi eszre
Szerintem pont simán feltűnet, ha keresztbe kasul szemetel a ost stack,de rég kellett már ezen a szinten bmit cseszni.
masreszt stp nem veszi el a linket, csak blockolja a forgalmat
Láttam én már olyat, ami leverte a linket is. Lehet, hogy vmi extra featue volt már mondjuk
- A hozzászóláshoz be kell jelentkezni
bpdu guard / root guard fícsör ha engedélyezve van STP-n belül, ha jól rémlik le fogja nyomni shutdown-ba a portot
- A hozzászóláshoz be kell jelentkezni
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
altname enp25s0f0
altname ens2f0
inet 192.168.1.12/24 brd 192.168.1.255 scope global noprefixroute eno1
valid_lft forever preferred_lft forever
inet6 fe80::b8b4:48f1:6f3d:2fed/64 scope link noprefixroute
valid_lft forever preferred_lft forever
3: eno2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
altname enp25s0f1
altname ens2f1
inet 192.168.1.13/24 brd 192.168.1.255 scope global noprefixroute eno2
valid_lft forever preferred_lft forever
inet6 fe80::3eec:efff:fe5d:459/64 scope link
valid_lft forever preferred_lft forever
4: ens3f0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1460 qdisc mq state DOWN group default qlen 1000
altname enp179s0f0
inet 192.168.1.14/24 brd 192.168.1.255 scope global noprefixroute ens3f0
valid_lft forever preferred_lft forever
5: ens3f1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
altname enp179s0f1
Az ens3f1 nem veszi fel az IP címet, látom.
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.1.1 0.0.0.0 UG 100 0 0 eno1
0.0.0.0 192.168.1.1 0.0.0.0 UG 101 0 0 eno2
0.0.0.0 192.168.1.1 0.0.0.0 UG 102 0 0 ens3f0
192.168.1.0 0.0.0.0 255.255.255.0 U 100 0 0 eno1
192.168.1.0 0.0.0.0 255.255.255.0 U 101 0 0 eno2
192.168.1.0 0.0.0.0 255.255.255.0 U 102 0 0 ens3f0
Ettől még mennie kell. Helyi hálózatban az adatbázis szerver minden interfészen figyel:
tcp 0 0 0.0.0.0:3050 0.0.0.0:* LISTEN -
- A hozzászóláshoz be kell jelentkezni
az megvan, hogy ez egy rosszul konfigurált network? ugyanaz a subnet minden if-en?
- A hozzászóláshoz be kell jelentkezni
több probléma is van ezzel:
- 4 hálókártya külön IP-kkel ugyan abban a hálózatban?? - ahogy már többen említették ez eleve rossz megközelítés.
De ha ettől eltekintünk, minden válasz csomag a legkisebb metric gateway-on fog menni, ami 1 Gb-re korlátoz mindent. Hiába van (jelenleg ugye épp nincs) 2x10 (vagy 40?)Gb kapcsolatod.
Ha valóban rendelkezésre áll a 2x40Gbit Fibre, akkor ezeket kellene EGY bond interface-ként felhúzni (ha valóban szükséges adhatsz neki több IP-t is) és a sima 1Gb interface-ket meg ignorálni, mert az csak valami vicc lehet a 2x40 mellett
Ez így káosz, routing rémálom és önszop*tás. - tankönyvbe illő példa, hogy hogyan NE csináljuk.
- A hozzászóláshoz be kell jelentkezni
mindenesetre eddig elvileg ment az elmondása szerint :D
- A hozzászóláshoz be kell jelentkezni
Persze, menni fog, ha szerencséje van akkor azon an interfészen válaszol vissza amin a kérés jött.
Most hogy az üveg lement "zen" állapotba, most nem azon válaszol hanem az 1 gigabites kártyán, ezért panaszkodnak a sebességproblémára azok akik az üveg IP címét használják.
Da attól hogy megy, meg jóvanazúgy, van olyan megoldás is ahol a x db kártya nem x db IP címmel van a hálózaton.
- A hozzászóláshoz be kell jelentkezni
ez a 40gbites milyen kartya? valami intel Xl7xx ? azokhoz felejtos a kernelbe levo driver, inteltol kell tolteni.
- A hozzászóláshoz be kell jelentkezni
Intel XL710-QDA2 (2x40GBitps), igen azzal ment is eddig.
- A hozzászóláshoz be kell jelentkezni
Igen, nem a legjobb a fenti megoldás. Nem saját ötlet. Rendbe kell tenni.
Kiderült, hogy nincs igazából sebesség probléma. (a kábel ki lett húzva és nem került vissza)
- A hozzászóláshoz be kell jelentkezni
"nem a legjobb a fenti megoldás" - Én nem fogalmaznék ilyen finoman: ez így egy ocsmány, minden hozzáértést nélkülöző gányolás.
- A hozzászóláshoz be kell jelentkezni
Egyik nap rendbe lesz rakva.l Alaplapi kiiktatva, optikai beizzit.
- A hozzászóláshoz be kell jelentkezni
Nomostan ha jól értem, öt kliensről ("öt gépes hálózat") van szó, amik szinte biztos, hogy egy szál gigabiten lógnak, azaz ha full kitömnék a saját sávszélességüket, akkor is összesen 5gigabitet kéne a másik oldalon kiszolgálni. Ott, ahol van 2 darab 10 gigás meg 2 darab 40 gigás interfész...
Itt semmi más nem kell, mint a 2 10G-s madzagot két stackelt, de külön fizikai switchbe bedugni, a switch oldalon _is_ meg a szerver oldalon _is_ bonding/LACP trunk összerak, lehet akár failover-re is konfigurálni, mert az öt klienst "fél lábon állva" :-) is kiszolgálja egy darab 10G-s interfész is - de persze ettől függetlenül elpazarolhatod :-) ilyen célra a 40-es lábakat is... (Ezek jellemzően iSCSI/FCoE/NFS alá hasznosak - ha képes ezt a sávszélességet a kapcsolódó storage kitömni...)
- A hozzászóláshoz be kell jelentkezni
hát igen, a segitséghez jobb volna ismerni a teljes infrastruktúrát - de a fentiek alapján nem akarjuk megismerni :-)
- A hozzászóláshoz be kell jelentkezni
Na ja... Mindez egy Firebird-del súlyosbítva... (3050/tcp)
- A hozzászóláshoz be kell jelentkezni
akár még vmi közbeszerzéses történetet is el tudok képzelni. Bele speccelték a Tbps-es LAN kártyát, amihez utána adtak egy 10-100as szviccset, és csak azzal szabad használni.. . csoda h. ha utána ilyen öszvér hekkelés jön ki?
Tanárok kaptak egyik iskolában laptopot, h. tudjanak otthonról tanítani. Panaszkodott nekem ismerős, h. nagyon lassú a gép, bármit próbál csinálni, szószerint 10 percekig homokórázik a gép. Ránéztem kíváncsiságból. Valami régi 6-8 éves laptop, külsőre nem tűnt leharcoltnak, tehát valószínűleg ez is szekrénybe zárva töltötte élete nagy részét. Processzorból a legócskább celeron került bele. Valamint hdd volt benne, talán 300 gigás. Került rá win10, talán 19H1, de igazából a pontos fajta teljesen lènyegtelen. Az óriási hiba ebben a gépben, hogy 2 (igen kettő) GB ram van benne. Nem csoda, hogy megállás nélkül kerreg a hdd benne, és valóban bármire percek alatt reagál. Csodás példája h. jó pénzért vki elsózta az iskoláknak ezt a gépet, amit utána valójában semmire nem lehet ilyen ócska alkatrèszekkel használni. Ha vesz bele vki saját zsebből egy legolcsóbb ssd-t, meg sodimm ddr3 memóriából min. 8GB-t, máris a gép mai értékének felét ráköltötte. Mivel iskola tulajdona, tanárok biztos nem fognak nekiállni saját zsebből upgrédelgetni.
- A hozzászóláshoz be kell jelentkezni
> Bele speccelték a Tbps-es LAN kártyát, amihez utána adtak egy 10-100as szviccset
lattam ilyet, ahol 100Gbps portos blade szervert vettek, es ra akartak kotni az 1Gbps portos cisco switchre. DA kabellel. nem sikerult. marmint osszedugtak, mert miert ne, csak nem linkelt :)
> Csodás példája h. jó pénzért vki elsózta az iskoláknak
hja a kozbesz vilagaban ez regota hagyomany, hogy a raktaron megrohadt, reg elavult vackokat jopenzert (de minimum az eredeti megjeleneskori araert) elsozzak valakinek. csak a beszerzesert felelos 1-2 embert kell megajandekozni hozza. lattam en mar igy "uj" szerver beszerzest is, ami mar reg EOL volt, valami 8 eves szutyok amit ujkoraban se vettem volna meg.
- A hozzászóláshoz be kell jelentkezni