Distributed Trunking (Trunk über zwei unterschiedliche HP Switche)

[heuchler 17]

Hallo zusammen,

ich hätte eine Frage die mir HP anscheinend noch nicht beantworten kann (oder möchte?)

 

Szenario:

3x Hyper-V Hosts
1x NetApp
1x HP E5406zl (je 2x Module ich glaube 20+4 SFP)
1x HP Switch 2800 Serie zum Beispiel (das plane ich gerade).

Bisher ist es so, wenn der CoreSwitch E5406zl ausfällt (ein Controller), dann steht alles.
Einen zweite CoreSwitch kann man sich derzeit nicht leisten.

Mir kam die Idee die Wege aufzuteilen. Nicht mehr auf das Modul A und B der Core Switches, sondern die Trunks auf zwei physikalisch unterschiedlichen Switches zu legen.
Sozusagen eine Linie auf den E5406zl (ModulA), die andere Linie dann auf den "Kleinen".

Idee:Läuft alles wie gewollt, 2/4 GBit Anbindung.
Fällt ein Switch aus, 1/2GBit Anbindung, reicht zum weiterarbeiten.

 

ALternativ dazu die Frage ob dies mit zwei E5406zl ginge.

Achso, bei der Anbindung kommen nur Kupfer zum Einsatz. Die SFPs werden zur Anbindung der Etagen/Hallen verwendet.

Da fiel mir HPs DT ein. Aber ich habe wirklich keine Ahnung ob dies schon bei den "kleinen" HPs aktiviert werden kann.
Eine Anfrage bei HP blieb bisher unbeantwortet.

 

Vielleicht könnt ihr mir helfen :)

Viele Grüße und Danke euch!

Daniel
 

[DocData 85]

Die 5400zl können Distributed Trunking. Du solltest nur darauf achten, das Routing im gleichen Zug hochverfügbar zu machen (Stichwort VRRP).

[heuchler 17]

Super, danke.
Und die anderen kleinen Switche (2620 zum Beispiel) nicht? Das wäre nämlich der finanzielle Vorteil dieser Mix-Umgebung bei vielleicht etwas geringerem Durchsatz (Overhead?).
Zum VRRP: zwischen den beiden CoreSwitchen?

Alle Geräte hängen in einem Schrank in einem Raum. Keine räumliche Trennung.
Nur die Backups liegen in einem ganz anderen Komplex.

Mein Ziel: zu relativ geringen kosten eine durchaus gesteigerte Ausfallsicherheit (auch wenn diese einem typischen RZ nichtmal ansatzweise nahe kommt). Aber für den Zweck ausreichend, vorallem weil dann ein 4000M als Core wegfällt ;-)

Und wenn es brennt kommt halt die Feuerwehr... :rolleyes:

[DocData 85]

Nein, die 2620 können das nicht.

 

Ja, VRRP zwischen den Core Switches (die hoffentlich das Routing machen).

[magheinz 110]

Gibts da von HP nicht sowas wie die validated designs bei cisco?

Zwei switche+dtrunk+netapp+Server ist bei cisco ein flexpod express. Schau dir das dort mal an. Anderer Hersteller aber gleiche Logik...

[DocData 85]

Bei HPE wird man sicher lustige Whitepapers finden. Ansonsten, Stichwort Flexpods als Beispiel für Interoperabilität, brauchen die sowas eher nicht. CI haben die im Portfolio und die Converged Systemes bestehen komplett aus HPE Produkten. Aber konkrete Antwort auf die Frage: Habe ich bei HPE nicht gesehen.

 

Was das Design angeht: Der Trend geht zu Virtual Chassis. Da braucht man so Krücken wie HPE DT oder Meshing nicht mehr.

bearbeitet 11. Juli 2016 von DocData

[heuchler 17]

Hm, danke euch schonmal bis hierhin. Es soll vermieden werden einen weiteren "teuren" Switch anzuschaffen. Ich würde behaupten dass die gleiche Funktionalität auch in den "Kleineren" vorzufinden wäre, aber womit sollen sich die großen dann noch abheben?
Mal schauen was daraus wird.

Virtual Chassis liest sich nach dem Überfliegen nach Stacking. Oder steckt dort was anderes hinter?
 

[DocData 85]

"Teure Switches"? Äh....

[lefg 276]

Ich schließe mich der Bemerkung DocDatas an, stelle die Frage, was ist einem Unternehmen die grundlegende Infrastruktur wert, als wie wichtig wird die angeshen? Wird noch anderwo das Geldausgben vermiden? Gebäudeausausrüstung, Elektroinstallation, Klimatisierung, Brandschutz und sonstige Sicherheit?

 

Warum wird bei der IT gespart und nicht in der Vorstandsetage?

bearbeitet 12. Juli 2016 von lefg

[magheinz 110]

Im Prinzip ist das Stacking.

Mittlerweile haben die Geräte vorne schnelle ports(10-100GB) womit der extra Stackingport wegfällt und damit ein Stack über weitere Strecken gebaut werden kann.

 

Es ist schon eine interessante Idee die core-Switche so gut wie aller Gebäude + die etagenswitche in EINEN stack packen zu können.

[DocData 85]

Es ist schon eine interessante Idee die core-Switche so gut wie aller Gebäude + die etagenswitche in EINEN stack packen zu können.

Das geht meistens nicht. Die meisten VCs sind bei 4 Mitgliedern begrenzt (Ausnahmen bestätigen die Regel). Aber: Ein VC im Core und ein VC in allen Unterverteilern ermöglicht hochredundante Topologien. Ganz großes Kino!

[heuchler 17]

Ach lefg...

Immer diese Diskussion über die vernachlässigte IT ohne Hintergründe der finanziellen Lage eines Unternehmens zu kennen... irgendwie nervig.
Wenn halt keine Kohle da ist, dann ist halt keine Kohle da. Wenn man keinen Kredit bekommt, bekommt man halt keinen Kredit. Wenn man nichts leasen kann, dann kann man halt nichts leasen! Soll ich das jetzt weiter ausführen?
Greif nem armen Mann in die Tasche. Versuche deine Kohle nach Insolvenz zu erhalten... und und und... ich habe bereits in zwei Unternehmen gearbeitet die diese Fall (teils mehrfach) durch hatten.
Irgendjemand muss dort die IT schmeißen und ich beglückwünsche jeden der jährlich ein gewisses Budget zur Verfügung hat um damit immer weiter, immer schneller und immer dick... nee warte.
Eigentlich könnte man auch Mitarbeiter entlassen die eh jeden Tag die restlichen Tage bis zur Rente zählen. Die sind m.E. überbezahlt da sie weder Lust noch den Kopf dazu haben irgendwas "neues" anzufassen.

 

@magheinz:
Eigentlich sind nur die CoreSwitche in einem Raum, zusammen mit dem Storage und lediglich einem Etagenverteiler.
Der Rest (Switche, Storage, Backup etc) liegt natürlich verteilt im Unternehmen, teils über Cu, als auch über LWL (und LWL Verteiler) angebunden.

Wie gesagt, wenn es brennt in der derzeitigen Situation dann kommt die Feuerwehr. Über den Rest mag ich garnicht spekulieren.

 

[magheinz 110]

Das geht meistens nicht. Die meisten VCs sind bei 4 Mitgliedern begrenzt (Ausnahmen bestätigen die Regel). Aber: Ein VC im Core und ein VC in allen Unterverteilern ermöglicht hochredundante Topologien. Ganz großes Kino!

Bei den 3560er Catalysten sinds 8 Geräte.

Ich schätze das wird für neuere, größere Varianten noch mehr.

VSS dagegen ist auf zwei Switche beschränkt.

 

Aber du hast recht: Man muss wegen der Verfügbarkeit eh mehr beachten. Ich hatte jetzt den Punkt "singel Point of Management" im Blick. Aber in ein paar Jahren ist das eh alles controllergestützt...

 

Ich würde schauen ob ich Netapp+Server nicht auf zwei extra-Switche hängen kann und diese dann an den Core anbinden. Deswegen mein Hinweis auf die Flexpods. Das technische Konzept an sich kann man ja mit jedem Hersteller umsetzen. Diese beiden Switche müssen ja nicht viel können: eine Handvoll 10G-Ports + Layer2.

[DocData 85]

Bei den 3560er Catalysten sinds 8 Geräte.

Ich schätze das wird für neuere, größere Varianten noch mehr.

VSS dagegen ist auf zwei Switche beschränkt.

Jap, bei einigen Modellen geht mehr. Selbst beim gleichen Hersteller hast du Modelle wo bei zwei im VC Schluss ist und ein Firmwareupdate später gehen 4 oder 8.

 

Aber du hast recht: Man muss wegen der Verfügbarkeit eh mehr beachten. Ich hatte jetzt den Punkt "singel Point of Management" im Blick. Aber in ein paar Jahren ist das eh alles controllergestützt...

Wäre froh wenn jeder Kunde ein ordentliches Out-of-Band Management für Netzwerkkomponenten hätte. Ich säge mir ungerne den Ast ab...

 

Ich würde schauen ob ich Netapp+Server nicht auf zwei extra-Switche hängen kann und diese dann an den Core anbinden. Deswegen mein Hinweis auf die Flexpods. Das technische Konzept an sich kann man ja mit jedem Hersteller umsetzen. Diese beiden Switche müssen ja nicht viel können: eine Handvoll 10G-Ports + Layer2.

Ja? Gerade im Hinblick auf FCoE kann man das gut auf zentralen Switches konsolidieren. Dediziertes Equipment für Storage wird immer seltener. Und mal ehrlich: Oft ist die Trennung doch nur Kosmetik. Aus Gründen der Performance macht das doch keiner mehr. Die meisten Switches (ich setze mal ordentliche Switches voraus...) haben eh genug Leistung. Ich sehe da eher den Vorteil weniger Komponenten verwalten zu müssen. Aber klar: Am Ende sind es die Anforderungen die entscheiden.

Immer diese Diskussion über die vernachlässigte IT ohne Hintergründe der finanziellen Lage eines Unternehmens zu kennen... irgendwie nervig.

Wenn halt keine Kohle da ist, dann ist halt keine Kohle da. Wenn man keinen Kredit bekommt, bekommt man halt keinen Kredit. Wenn man nichts leasen kann, dann kann man halt nichts leasen! Soll ich das jetzt weiter ausführen?

Das Geschäftsmodell ist murks und das Unternehmen ist nicht profitabel. Mach es zu.

bearbeitet 12. Juli 2016 von DocData

[magheinz 110]

Ja? Gerade im Hinblick auf FCoE kann man das gut auf zentralen Switches konsolidieren. Dediziertes Equipment für Storage wird immer seltener. Und mal ehrlich: Oft ist die Trennung doch nur Kosmetik. Aus Gründen der Performance macht das doch keiner mehr. Die meisten Switches (ich setze mal ordentliche Switches voraus...) haben eh genug Leistung. Ich sehe da eher den Vorteil weniger Komponenten verwalten zu müssen. Aber klar: Am Ende sind es die Anforderungen die entscheiden.

Das stimmt. es geht dabei nicht um Performance.

Es kann aber durchaus gewünscht sein manche Datenströme z.b. zwischen SAN und Servern abzutrennen.

 

Wie gesagt, der Trend geht eh Richtung Controllerbased Infrastruktur. Alles wird virtuell.

Das mit dem immer selteneren dedizierten Storageequipment hlte ich immer noch für nicht allgemeingülltig. Dann könnte man auch sagen der Trend geht eh weg von eigener Infrastruktur: Ein paar Accesspoints, Notebooks und der Rest ab in die Wolke...