Wie können Sie das Management davon überzeugen, dass 3560/3750 in Ihrem DC eine schlechte Idee ist?

3560 / 3750s haben kleine Puffer und sind gute Schalter für Kabelschränke. Allerdings sehe ich diese Schalter sehr oft in DCs. Viele Leute neigen dazu, sie zu verwenden, da sie im Allgemeinen 1 GB und L3-fähig sind.

Gibt es eine Möglichkeit zu beweisen, wie schlecht sie in DC-Bereitstellungen sind? Ich höre ziemlich oft Leute sagen, sie hätten ihre 3750s entfernt, sobald sie konnten, aber ich habe noch kein tatsächliches Fehlerszenario gehört, das verwendet werden könnte, um das Management wissen zu lassen, dass es sie rausholt.

FWIW Ich habe Erfahrung mit 3750 (3750G und später 3750E / 3560E) im Maßstab in einem TOR-Setup; anfangs mit L2 port-channels / GLBP (varianten von 2x1G und 2x2G und die seltenen 2x4G für db-racks) und dann mit L3 zum TOR (ging dabei für 3750E / 3560E und 10G zum core). Ich spreche von Tausenden. Wir sahen nur Probleme mit Puffern für die meisten Bandbreite intensiven Dienstleistungen, und zu diesem Zeitpunkt waren wir betrachten 10G an den Host sowieso (und dichte Pizzakartons mit 24-48 SFP + 's).

Ob Sie dem Management irgendetwas beweisen können oder nicht, hängt wirklich von der Anwendung ab, und Sie machen Ihre Hausaufgaben damit, wie die Anforderungen Ihres Designs und der Anwendung aussehen und wie genau die Spezifikationen der Anwendung lauten sowie die erwartete Wachstumsgeschwindigkeit davon. Richten Sie eine Entwurfsprüfung mit Ihrer Managementkette sowie den primären Eigentümern / Kunden des Netzwerks ein.

Das Management möchte Daten sehen , und wenn Sie nicht über die Ressourcen verfügen, um die Box vollständig zu testen (erstellen Sie einen Testplan, schließen Sie ihn an eine Hardware für die Verkehrserzeugung an, erweitern Sie ihn vollständig und testen Sie ihn anhand der Entwurfsspezifikation.) etc) das wird schwer zu machen sein. Sie werden nicht von anekdotischen Beweisen beeindruckt sein, und es könnte sich als schwierig erweisen, diese Art von harten Daten zu finden, da ich mir sicher bin, dass Leute, die solche Dinge veröffentlichen, alle Arten von NDAs verletzen würden.

Alle anderen, die eine Antwort auf diese Frage veröffentlicht haben , haben die "Problembereiche" der 3750-Plattform sehr gut umrissen: die damit verbundenen Stapel- und seltsamen Fehlermodi, die Puffergrößen usw. Außerdem werden in dieser Frage die Probleme beim Sammeln von SNMP-Statistiken zu Ausgabewarteschlangen- Ausfällen umrissen - Die Puffer werden von den ASICs gemeinsam genutzt, sodass alle Statistiken, die Sie über SNMP erhalten, für bestimmte Portbereiche gleich sind (dies könnte ein Knackpunkt sein, den Sie mit Ihrer Verwaltungskette ansprechen können).

Zusammenfassend würde ich sagen, dass der 3750/3560 für die meisten Bereitstellungen "in Ordnung" ist, selbst bei größeren Ausmaßen. Vermeiden Sie es, sie zu stapeln, wenn Sie können, aber ich würde sagen, dass es nicht zu schrecklich ist, dies in sehr kleinen und überschaubaren Mengen zu tun.

Es hängt wirklich von Ihrem Bereitstellungsszenario ab. 3560/3750-Switches sind großartige Switches mit anständigen Puffern und funktionieren in der Regel für die meisten Anwendungen. Wenn in Ihrem Rechenzentrum Datenströme auftreten, die größere Puffer erfordern, sollten Sie in der Lage sein, Statistiken von den Switches abzurufen, z. B. die Puffernutzung und Paketverluste. Das Management davon zu überzeugen, die Switches, die ihre Pakete fallen lassen, fallen zu lassen, sollte keine allzu große Herausforderung sein. Meiner Ansicht nach.

In den Anfängen des 3750, insbesondere der Stapeltechnologie, die kurz vor 2010 herauskam, gab es eine Menge Probleme mit Switch-Fehlern, die dazu führten, dass der Stapel nicht so elegant ausfiel. Kombinieren Sie dies mit der Tatsache, dass das Upgrade eines Stacks nicht der intuitivste Prozess war (es wurde seitdem verbessert). Das 3750 hat einen schlechten Ruf, der seitdem nicht mehr aufrechterhalten werden kann.

In kleinen Rechenzentren stellt der 3750-Stack eine relativ kostengünstige Option dar, um die Portdichte ohne die Kosten eines Chassis-basierten Switches zu erhalten. Ich selbst habe gerade für einen kleineren Kunden eine Rechenzentrumslösung mit einigen Cisco UCS C220 M3-Servern mit Netapp FAS2240 installiert und einen Stapel von 3750-Servern verwendet, um jedem neuen Gerät sowie allen alten Servern eine Etherchannel-Redundanz mit mehreren Gehäusen bereitzustellen während des Übergangs. Es hat sehr, sehr gut funktioniert.

Also - hat der 3750 Probleme? Wahrscheinlich derselbe wie jeder andere Schalter, der schon so lange existiert. Der 6500 hatte seine Probleme zu Beginn seines Lebenszyklus und jetzt, da er seit Jahren nicht mehr verfügbar ist, ist es nicht mehr so ​​schlimm. Ich empfehle Ihnen, sich anzuschauen, was Sie damit anfangen werden, und wenn die Leistungsmetriken stimmen, stellen Sie sicher, dass Sie deren Leistung mit Wachsamkeit überwachen.

Ehrlich gesagt war die häufigste Art, wie ich gesehen habe, wie die 3750er am Randstein landeten, als die Core-Switches auf Nexus 7k aufgerüstet wurden. Normalerweise (aber nicht immer) besteht ein Teil dieser Aktualisierung darin, TOR auf Nexus 2000 FEXs oder Nexus 5000s zu verschieben.

Obwohl die 3750 nicht über die größten Puffer verfügen, funktionieren sie in den meisten DC-Unternehmensumgebungen "gut genug".

Ich bezweifle, dass Sie das Management davon überzeugen können, sie außerhalb eines regelmäßigen Produktaktualisierungszyklus zu ersetzen, es sei denn, Sie können einen Dollar für die Probleme ausgeben, die durch 3560er / 3750er in einem DC verursacht werden.

@mellowd hat sicherlich recht, diese Switches sind keine besonders brauchbaren DC-Switches, da sie aufgrund ihrer sehr begrenzten Pufferspeicher einen Mikroburst verursachen und den Datenverkehr beeinträchtigen.

Angenommen, Sie haben einen 2 * 1GE-Eingang und einen 1 * 1GE-Ausgang. Das schlimmste Szenario ist, dass der Ausgangsport abfällt, nachdem die Eingangsports 2 ms lang gleichzeitig gesendet haben. Das beste Szenario ist, dass Sie mit 8ms Burst umgehen können.

Sie haben 2 MB Ausgangspuffer pro 4 Ports, also 2 MB / (1 Gbit / s / 8) = 16 ms Maximum und 16/4 = 4 ms Minimum. Teilen Sie diese Anzahl durch die Anzahl der Eingangsports, die gesendet werden sollen, und Sie erhalten die Anzahl, wie lange Sie damit umgehen können. Das heißt, je mehr Ingress-Ports (Server) Sie hinzufügen, desto weniger Microbursting können Sie verarbeiten.

Wenn Sie mit 3750/3560 leben müssen, sollten Sie dieses Dokument lesen , um die Puffernutzung zu maximieren. Und wenn Sie die Verwendung von LACP noch immer einstellen, obwohl Ihre Grafiken zeigen, dass die durchschnittliche Ausgangsnachfrage sehr niedrig ist.

Um Ihren Managern zu beweisen, dass die Puffer nicht ausreichen, überwachen / tippen / überspannen Sie Ihre aktuellen Netzwerke, wechseln Sie alle Downlinks. Dann werden Zeitstempel und Paketgrößen ausgegeben, und Sie können berechnen, wie viel über 1 Gbit / s Ihr momentaner Bedarf beträgt und wie viel Puffer, den Sie brauchen, um damit umzugehen.

Leistung ist sicherlich ein wichtiges Thema und wird oben gut angesprochen, aber es gibt auch eine Menge Differenzierung basierend auf Funktionen und Funktionssätzen:

1. Der Bedarf an externen RPS-Einheiten ist in vielen Installationen ein großes Problem - ein 1U-Switch wird im Hinblick auf die Anfangskosten, den Platzverlust und die laufende Verwaltung teurer. Redundante Stromversorgung ist in allen Umgebungen mit Ausnahme der kleinsten Rechenzentren ein absolutes Muss.

2. Viele, viele unnötige Codes für die Endbenutzerkonnektivität werden ausgeführt - mehr Möglichkeiten für Fehler, Sicherheitsprobleme und Ausfallzeiten.

3. DC-Funktionen (ISSU, DCB, Speicher, bestimmte On-Box-Scripting-Elemente) sind und sind auf den Geräten mit Campus-Fokus nicht verfügbar. Mechanismen zur Verwaltung und Skalierung der L2-Erweiterung auf eine vernünftige Weise (z. B. FabricPath / TRILL, OTV, VXLAN usw.) fehlen in der Regel auch im aktuellen Status und auf Roadmaps außerhalb von DC-Produkten. Die Liste hier wird nur noch wachsen - Virtualisierung on-Box, Unterstützung von HW-Assist-Mechanismen usw.

4. Skalierbarkeit - Wie wächst die Infrastruktur? Viele, viele Schalter (teuer in der Verwaltung)? Das Stapeln (betriebsbedingt schwierig, große Verkabelungsprobleme) ist ein Chaos. Darüber hinaus kann die Flexibilität der Schnittstellentypen (z. B. Glasfaser gegenüber Kupfer) bei der Dichte eine Herausforderung darstellen.

Generell nehmen die Unterschiede zwischen DC und Closet Switching zu. In der Welt von Cisco gibt es aus sehr guten Gründen unterschiedliche Betriebssysteme (NXOS vs IOS) - sehr unterschiedliche Anforderungen führen zu unterschiedlichen Lösungen. Die Funktionsgeschwindigkeit für Benutzerauthentifizierungsmechanismen (802.1x) oder ausgefallene AV-Integration wird im Rechenzentrum nicht benötigt, während die Möglichkeit, Tonnen von 10GE zu terminieren, im Schaltschrank nicht benötigt wird. Unterschiedliche Werkzeuge für unterschiedliche Aufgaben. Eine Nexus-Box, die Desktops miteinander verbindet, ist ebenfalls kein idealer Plan.

Ich verweise Sie auch auf die verschiedenen Design-Anleitungen (CVDs usw.), in denen die Gründe für die Arten von Switches aufgeführt sind, die an verschiedenen Punkten im Netzwerk verwendet werden. Es gibt etwas zu sagen für Lösungen, die im Allgemeinen den branchenüblichen Best Practices entsprechen, und die Switches, die Sie erwähnen, haben im DC im Allgemeinen keinen Platz - abgesehen von Verwaltungsnetzwerken oder bestimmten lokalen Konnektivitätssituationen in Sonderfällen.

Ich habe einen Kunden, der sie als SAN-Switch-Stack (mit 3750X) bereitgestellt hat, wobei das SAN mit 10 Gbit verbunden ist und dann die ESX-Hosts mit Gbit verbunden sind (oder mehrere Gbit mit LAG) wie Sie versuchen, die Puffer abzustimmen.

Derselbe Kunde verfügt über zwei weitere 3750-Stacks in demselben DC für andere Netzwerke, und diese sind alle sauber.

TL; DR: Es hängt wirklich von der Art des Datenverkehrs ab, den Sie durch den Stapel leiten werden, und wo sich Ihre Engpässe befinden.

Die Netzteile / Lüfter in 3560/3750 sind nicht Hot-Swap-fähig / Sobald der Switch montiert ist und der unvermeidliche Ausfall dieser Geräte auftritt, müssen alle Server vom 3560/3750 getrennt werden, während er nicht montiert ist und durch den RMA ersetzt wird.

Auch die Lüfterrichtung des 3560s / 3750s wird bei Warm- / Kaltgängen und anderen Kühlsystemen zu einem Problem. Die Montage der Switches an der Stelle, an der die Switch-Ports zur Rückseite der Server zeigen, führt dazu, dass die Switch-Lüfter in die falsche Richtung blasen. Dadurch wird der Switch überhitzt, wodurch es wahrscheinlicher ist, dass er ausfällt oder ausgetauscht werden muss.