To co napisałem i narysowałem wcześniej nie do końca jest prawdą. Otóż LACP działa pomiędzy dwoma urządzeniami spiętymi bezpośrednio. Wyjątkiem są przełączniki, które można połączyć w logiczną całość, ale ja takowych nie posiadam. Wcześniej robiłem konfigurację tylko po stronie serwerów, ale to nie wystarczy (mimo, że działało jako tako). Trzeba po drugiej stronie też odpowiednio poustawiać.
Nie wiedzieć czemu jedne serwery raportują połączenie 2 Gbps (przy dwóch kartach), inne tylko 1 Gbps. Prawdopodobnie zależy to od sterownika. Te które mogą więcej to na pewno Intel PRO/1000 EB, te które nie mogą (lub po prostu ja nie wiem jak je zmusić do takiego działania) to:
- Intel PRO/1000 PM + Intel PRO/1000 PL (serwery Actina z płytami SuperMicro mają różne karty, więc może to być powodem; poza tym ta pierwsza nie wspiera Jumbo Frames),
- Broadcom BCM5708C NetXtreme II GigE.
Jeśli ktoś wykorzystuje obie karty do dwóch różnych sieci, też może korzystać z LACP. Zawsze w parze z tym idzie VLAN, więc pierw spinamy karty razem, a potem je dzielimy.
Logi z operacji spinania przełączników poniżej:
2009-04-16 14:50:53 generic information INFO - LACP: Trunk group 1 created with ports=25, aggregator id=1024, partner system=32767,00:22:57:45:D8:A0, actor oper key = 26436, partner oper key = 14881
2009-04-16 14:50:55 generic information INFO - LACP: Trunk group 1 updated with ports=1,25 for aggregator 1024
2009-04-16 14:50:49 generic information INFO - LACP: LACP is disabled on port 16
2009-04-16 14:50:49 generic information INFO - LACP: Trunk group 1 removed for aggregator 1039
2009-04-16 14:50:50 generic information INFO - LACP: Fixed group ID for port 16 set to -1
2009-04-16 14:50:50 generic information INFO - LACP: Fixed group ID for port 16 set to 0
2009-04-16 14:50:50 generic information INFO - LACP: Fixed group ID for port 39 set to 0
2009-04-16 14:50:50 generic information INFO - LACP: LACP is enabled on port 16
2009-04-16 14:50:50 generic information INFO - LACP: LACP is enabled on port 39
2009-04-16 14:50:53 generic information INFO - LACP: Trunk group 1 created with ports=39, aggregator id=1039, partner system=32767,00:22:57:45:D6:A0, actor oper key = 14881, partner oper key = 26436
2009-04-16 14:50:55 generic information INFO - LACP: Trunk group 1 updated with ports=16,39 for aggregator 1039
2009-04-16 14:50:56 generic information INFO - RSTP: Set Port Parameters: Admin Path Cost, Value: 0
2009-04-16 14:50:56 generic information INFO - RSTP: Set Port Parameters: Admin Path Cost, Value: 0
2009-04-16 14:50:56 generic information INFO - LACP: Trunk group 1 updated with ports=16 for aggregator 1039
2009-04-16 14:50:56 generic information INFO - LACP: Trunk group 1 updated with ports=16,39 for aggregator 1039
2009-04-16 14:50:56 generic information INFO - RSTP: Set Port Parameters: Admin Path Cost, Value: 0
2009-04-16 14:50:58 generic information INFO - RSTP: Set Port Parameters: Admin Path Cost, Value: 0
OK, skoro LACP to tylko połączenia bezpośrednie, w takim razie przełącznik nadal pozostaje single point of failure. Owszem, ale można rozwiązać to np. za pomocą (R)STP.
W mojej sieci RSTP wyniknęło samo z siebie. Bez żadnych planów osób przeciągających kable. Niektóre idą z poziomu 0 na 2 bezpośrednio, niektóre przez duże przełączniki na piętrach. Taka wolna amerykanka. Oczywiście nie ma tego złego, co by na dobre nie wyszło. Wykorzystałem bałagan dla zwiększenia niezawodności sieci :>
Ciągle mamy newralgiczne połączenia, ale staram się to eliminować.
Przykładowy log RSTP (prawdopodobnie restart jednego z przełączników):
2009-04-17 07:08:17 warning %LINK-W-Down: 19
2009-04-17 07:08:17 warning %LINK-W-Down: 13
2009-04-17 07:08:17 warning %LINK-W-Down: 12
2009-04-17 07:08:17 warning %LINK-W-Down: 20
2009-04-17 07:08:18 information %LINK-I-Up: 19
2009-04-17 07:08:19 information %LINK-I-Up: 12
2009-04-17 07:08:19 information %LINK-I-Up: 20
2009-04-17 07:08:19 information %LINK-I-Up: 13
2009-04-17 07:08:48 warning %STP-W-PORTSTATUS: 19: STP status Forwarding
2009-04-17 07:08:49 warning %STP-W-PORTSTATUS: 12: STP status Forwarding
2009-04-17 07:08:49 warning %STP-W-PORTSTATUS: 20: STP status Forwarding
2009-04-17 07:08:49 warning %STP-W-PORTSTATUS: 13: STP status Forwarding
Tak jak wszystko, warto takie rzeczy dobrze zaplanować od podstaw. Choć operacje na otwartym sercu mają swój urok ;-)
Swoją drogą chciałbym kiedyś trafić do takiej sieci bez dokumentacji w czasie awarii jednego z przełączników.
Tagi: IEEE 802.3ad, LACP, link aggregation, RSTP, STP
[...] świadomie zacząłem używać (R)STP zastanawiałem się na ile (nie)bezpieczne to może być. Skoro urządzenia same dogadują się [...]
heh, widzę że kolega walczył z tym samym, z czym ja teraz walczę, otóż próbuję switche połączyć ze sobą, by uzyskać pełne 2Gbps (co najmniej) między nimi.
I tak dzisiaj na stół poszły 2x 3Comy 2928-SFP połączone po 2 moduły fiber 1Gbps LX każdy ze sobą, a do każdego ze switchy po jednym z serwerów z dual-LAN card (Dell R610 vs Fujitsu RX330 S1).
No i lipa.. 1Gbps jak był tak jest… nawet nie liznęło 2 linków naraz ;/
Między przełącznikami masz 1 Gbps czy pomiędzy przełącznikiem, a serwerem? Skonfigurowałeś prawidłowo zarówno porty w przełączniku jak i karty serwera? Te 1 Gbps wychodzi z pomiarów czy system wyświetla takie informacje? Działa fail-over czy też nie?
To i ja dodam swoje doświadczenia. Scenariusz: serwer plików oraz serwer bazy. Plan max przepustowość. Sprzęt 2xBMC709C w każdym sprzęcie oraz GSD-800S. Użyłem LACP tworząc połączenia 2Gbps serwer to switch. Kopiowanie pomiędzy serwerami powala. W razie czego służę lepszymi danymi.
PS włączać jumbo ??
Zrobić testy wydajności, wyniki zapisać, włączyć jumbo, ponowić testy, opisać rezultat ;-)
W zasadzie to włączałem gdzie to było możliwe, ale nigdy nie robiłem pomiarów. Chętnie poznam argumenty za i przeciw poparte testami.