Jak przekonujesz kierownictwo, że 3560/3750 to zły pomysł w twoim DC?

Modele 3560/3750 mają małe bufory i dobrze się sprawdzają przełączniki szaf. Jednak bardzo często widzę te przełączniki w DC. Wielu ludzi korzysta z nich, ponieważ są na ogół zdolne do 1 Gb i L3.

Czy istnieje sposób, aby udowodnić, jak źle są we wdrożeniach DC? Dość często słyszę, jak ludzie mówią, że usunęli swoje 3750 tak szybko, jak to możliwe, ale nie słyszałem jeszcze scenariusza awarii, który mógłby zostać wykorzystany do poinformowania kierownictwa o ich usunięciu.

FWIW Miałem doświadczenie z 3750 (3750G, a później 3750E / 3560E) w skali w konfiguracji TOR; początkowo z portowymi kanałami L2 / GLBP (warianty 2x1G i 2x2G oraz rzadkie 2x4G dla stojaków db), a następnie z L3 do TOR (poszedł z tym dla 3750E / 3560E i 10G do rdzenia). Mówię o nich tysiące. Widzieliśmy tylko problemy z buforami dla najbardziej wymagających usług, w tym momencie i tak patrzyliśmy na 10G do hosta (i gęste pudełka do pizzy z 24-48 SFP +).

To, czy będziesz w stanie udowodnić coś zarządowi, będzie naprawdę zależeć od aplikacji i odrabiania lekcji na podstawie wymagań projektu i aplikacji oraz od dokładnej znajomości specyfikacji aplikacji. , a także jego przewidywaną prędkość wzrostu. Skonfiguruj przegląd projektu z łańcuchem zarządzania, a także głównymi właścicielami / klientami sieci.

Kierownictwo chce zobaczyć dane , a jeśli nie masz zasobów, aby w pełni przetestować urządzenie (opracuj plan testowy, podłącz go do jakiegoś sprzętu do generowania ruchu, w pełni określ zakres i przetestuj w warunkach skrajnych zgodnie ze specyfikacją projektową, itp.) będzie to trudne. Nie będą pod wrażeniem anegdotycznych dowodów, a znalezienie tego rodzaju twardych danych może okazać się trudne, ponieważ jestem pewien, że ludzie publikujący tego rodzaju treści naruszyliby wszystkie rodzaje NDA.

Wszyscy inni, którzy odpowiedzieli na to pytanie, całkiem ładnie opisali „obszary problemowe” platformy 3750: stosy i związane z nimi dziwne tryby awarii, rozmiary buforów itp. Istnieje również pytanie, które opisuje problemy ze zbieraniem statystyk SNMP dotyczących spadków kolejek wyjściowych - bufory są współużytkowane przez ASIC, więc wszelkie statystyki, które otrzymujesz za pośrednictwem SNMP, będą takie same dla określonych zakresów portów (może to być jeden punkt zaczepienia, który możesz przywołać w swoim łańcuchu zarządzania).

Podsumowując, powiedziałbym, że 3750/3560 byłby „w porządku” dla większości wdrożeń, nawet w dość dużych skalach. Unikaj układania ich w stosy, jeśli możesz, ale powiedziałbym, że nie jest to zbyt okropne, aby robić to w bardzo małych i łatwych do opanowania ilościach.

To naprawdę zależy od scenariusza wdrażania. 3560/3750 to świetne przełączniki, mają przyzwoite bufory i zwykle działają dobrze w większości aplikacji. Jeśli twoje centrum danych widzi przepływy ruchu wymagające większych buforów, powinieneś być w stanie pobrać statystyki z przełączników, takie jak użycie bufora i spadki pakietów. Przekonanie kierownictwa do upuszczenia przełączników upuszczających pakiety nie powinno stanowić większego wyzwania. Myślę.

We wczesnych dniach 3750, szczególnie w technologii stosowej, która została wydana tuż przed mniej więcej 2010 rokiem, było wiele problemów z awariami przełączników powodujących awarię stosu w niezbyt wdzięczny sposób. Łącząc to z faktem, że aktualizacja stosu nie była najbardziej intuicyjnym procesem (od tego czasu jest ulepszana), 3750 naprawdę ma złą reputację, która utknęła do tej pory.

W małych centrach danych stos 3750 stanowi stosunkowo niedrogą opcję uzyskania gęstości portów bez kosztów przełącznika opartego na obudowie. Ja sam zainstalowałem dla mniejszego klienta rozwiązanie dla centrum danych z kilkoma serwerami Cisco UCS C220 M3 z Netapp FAS2240, i użyłem stosu 3750s, aby zapewnić redundancję wielokanałowego kanału Ethernet dla każdego nowego urządzenia, jak również dla wszystkich starych serwerów podczas przejścia. Działa naprawdę bardzo dobrze.

Więc - czy 3750 ma problemy? Prawdopodobnie taki sam, jak każdy inny przełącznik, który jest dostępny od tak dawna. 6500 miał problemy na wczesnym etapie swojego cyklu życia, a teraz, kiedy był na rynku przez wiele lat, nie jest tak źle. Zalecam przyjrzenie się temu, co zamierzasz na to rzucić, a jeśli wskaźniki wydajności utrzymają się, upewnij się, że monitorujesz ich skuteczność z czujnością.

Szczerze mówiąc, najczęstszym sposobem, w jaki widziałem 3750 uderzenie w krawężnik, było, gdy przełączniki rdzenia zostały uaktualnione do Nexusa 7k. Zwykle (ale nie zawsze) częścią tego odświeżenia jest przeniesienie TOR na Nexus 2000 FEX lub Nexus 5000.

Mimo że 3750 nie mają największych buforów, w opinii większości ludzi działają „wystarczająco dobrze” w większości środowisk DC dla przedsiębiorstw.

O ile nie potrafisz wycenić wartości dolara na problemy spowodowane 3560/3750 w DC, wątpię, czy byłbyś w stanie przekonać kierownictwo do zastąpienia ich poza regularnym cyklem odświeżania produktu.

@mellowd ma z pewnością rację, te przełączniki nie są zbyt użytecznymi przełącznikami DC, z powodu bardzo ograniczonych buforów będą one mikrowstrząsać i upuszczać ruch.

Rozważ, że masz wejście 2 * 1GE i wyjście 1 * 1GE. Najgorszym scenariuszem jest to, że port wyjściowy zaczyna opadać po tym, jak porty wejściowe wysłały w tym samym czasie przez 2 ms. Najlepszy scenariusz to, że możesz poradzić sobie z serią 8ms.

Masz 2 MB bufora wyjściowego na 4 porty, więc 2 MB / (1 Gbps / 8) = maksymalnie 16 ms i 16/4 = minimum 4 ms. Podziel tę liczbę przez liczbę portów wejściowych, które chcesz wysłać, a otrzymasz liczbę, jak długo możesz to obsłużyć. Oznacza to, że im więcej portów wejściowych (serwerów) dodasz, tym mniej mikroprzepływów możesz obsłużyć.

Jeśli musisz korzystać z 3750/3560, powinieneś przeczytać ten dokument, aby zmaksymalizować wykorzystanie bufora. A jeśli nadal spadasz, użyj LACP na wyjściu, mimo że twoje wykresy pokazują, że średnie zapotrzebowanie na wyjście jest bardzo niskie.

Aby udowodnić swoim menedżerom, że bufory są niewystarczające monitor / dotknij / rozpiętość, twoje obecne sieci przełączają wszystkie łącza pobierające, wtedy będziesz mieć znaczniki czasu i rozmiary pakietów wychodzące i możesz obliczyć, o ile ponad 1 Gb / s twoje chwilowe zapotrzebowanie i ile bufor musisz go obsłużyć.

Wydajność jest z pewnością ważną kwestią i została dobrze omówiona powyżej, ale istnieje również wiele różnic w zależności od funkcji i zestawów funkcji:

1. Potrzeba zewnętrznych jednostek RPS jest ogromnym problemem w wielu instalacjach - przełącznik 1U staje się droższy pod względem kosztów początkowych, utraconej przestrzeni i ciągłego zarządzania. Nadmiarową moc należy uważać za absolutną konieczność we wszystkich środowiskach z wyjątkiem najmniejszych centrów danych.

2. Działa mnóstwo niepotrzebnego kodu do łączności z użytkownikiem końcowym - większa szansa na usterki, problemy z bezpieczeństwem i przestoje.

3. Funkcje DC (ISSU, DCB, pamięć masowa, niektóre elementy skryptowe na pudełku) nie są - i nie będą - na urządzeniach skoncentrowanych na kampusie. Mechanizmy do zarządzania i skalowania rozszerzenia L2 również w rozsądny sposób (tj. FabricPath / TRILL, OTV, VXLAN itp.) Również często brakuje w obecnym stanie i mapach drogowych poza produktami DC. Lista będzie się powiększać - wirtualizacja na pudełku, obsługa mechanizmów wspomagających sprzęt, itp.

4. Skalowalność - w jaki sposób rozwijasz infrastrukturę? Mnóstwo przełączników (kosztownych w zarządzaniu)? Układanie (trudne operacyjnie, główne problemy z okablowaniem) to bałagan. Dodatkowo elastyczność typów interfejsów (na przykład światłowód vs miedź) przy gęstości może być trudna.

Zasadniczo rosną różnice między przełączaniem prądu stałego a przełączaniem szaf. W świecie Cisco istnieją odrębne systemy operacyjne (NXOS vs IOS) z bardzo dobrych powodów - bardzo różne wymagania dają rozbieżne rozwiązania. Szybkość funkcji mechanizmów uwierzytelniania użytkownika (802.1x) lub fantazyjna integracja AV nie są potrzebne w centrum danych, podczas gdy zdolność do zakończenia ton 10GE nie jest potrzebna w szafie na okablowanie. Różne narzędzia do różnych zadań. Pudełko Nexusa łączące komputery stacjonarne również byłoby planem mniej niż idealnym.

Chciałbym również wskazać na różne przewodniki projektowe (CVD itp.), Które przedstawiają uzasadnienie dla typów przełączników używanych w różnych punktach sieci. Jest coś do powiedzenia na temat rozwiązań, które na ogół przypominają najlepszą powszechną praktykę w branży, a wspomniane przełączniki na ogół nie mają miejsca w DC - poza sieciami zarządzania lub szczególnymi przypadkami lokalnych połączeń.

Mam klienta, który wdrożył je jako stos przełączników SAN (przy użyciu 3750X) z siecią SAN podłączoną przy 10 Gbit, a następnie ich hosty ESX podłączone przy Gbit (lub wiele Gbit przy użyciu LAG), a wielkość spadków wyjściowych jest astronomiczna bez względu na wszystko jak próbujesz dostroić bufory.

Ten sam klient ma dwa inne stosy 3750 w tym samym DC dla innych sieci i wszystkie są czyste.

TL; DR: To naprawdę zależy od rodzaju ruchu, który zamierzasz wprowadzić przez stos i gdzie są twoje wąskie gardła.

Zasilaczy / wentylatorów w zakresie 3560/3750 nie można wymieniać podczas pracy na gorąco / po zamontowaniu przełącznika i wystąpieniu nieuniknionej awarii tych urządzeń, wszystkie serwery muszą zostać odłączone od 3560/3750, gdy jest on odmontowany i zastąpiony RMA.

Również kierunek wentylatora w modelach 3560s / 3750s staje się problemem w przypadku gorącego korytarza / zimnego korytarza i innych ustawień chłodzenia. Zamontowanie przełączników w miejscu, w którym porty przełącznika są zwrócone w kierunku tyłu serwerów, powoduje, że wentylatory przełączników dmuchają w złym kierunku. Spowoduje to przegrzanie przełącznika, co zwiększa prawdopodobieństwo awarii / konieczności wymiany.