Zwei Serverracks verbinden

[f3nr!s]

Ich werde jetzt vermutlich doch auf Einzelverbindungen aus dem zweiten Schrank per Patchkabel zurückgreifen. Einfach weil ich das Budget nicht habe um jetzt mal für gebrauchte Hardware 3K€ raus zu hauen. Ich werde nicht oben herum gehen, sondern durch die Seiten und einen möglichst kurzen Weg.

Egal wie ich es drehe und wende, ob ich meinen jetzigen Core zum ToR mache und eine neuen Core anschaffe oder ob ich gleich ein neues ToR besorge... es würde ziemlich teuer werden. Die Optionen habe ich ja später immer noch.

Ich habe zwar viele Server zum Anbinden, aber wenig Traffic der über das Netzwerk geht. Da wäre jetzt ziemlich OP nochmal paar Switche mit 10Gbit-Anbindung anzuschaffen.

 

[gaym0r]

Ich meine das Szenario mit dem VRRP. VRRP ist Layer-3 und es ist immer ein Link im standby. Ganz simples Beispiel: VRRP war eigentlich mal nur für Router vorgesehen (deshalb Virtual Router Redundancy Protocol) und sollte im Fall das der Master abstürzt den Slave übernehmen lassen. CARP dasselbe, nur eben OpenSource.

Also VRRP kann auch active-active incl. Load-Balancing. Aber vermutlich nicht so wie du dir das vorstellst. Aber davon ab: Wüsste auch gerade nicht wo da ein Problem sein sollte, dass ein Link im Standby sein sollte.

So und nun? Was ist mit Layer-2? Das kann nur per STP realisiert sein, anders geht es nicht bei redundanter Verkabelung, sonst hast du eben kein echte Ausfallsicherheit. Bei zwei Links vom selben Switch ohne STP braucht man nur mal ein Loop erzeugen und schon liegt dein Netzwerk brach. Da gibt es eigentlich auch keine zwei Meinungen.

Darf ich fragen auf welchem Stand du dich befindest? Man kann natürlich einen Switch mit zwei Uplinks versehen, jeweils einer zu jedem Core-Switch - ohne STP. Stichwort MC-LAG, habe ich weiter oben schonmal angesprochen (allerdings als MLAG). Je nach Hersteller gibt es dafür unterschiedliche Bezeichnungen: MLAG, MCLAG, MEC, VPC etc.
https://en.wikipedia.org/wiki/MC-LAG
Auf dem Switch selbst konfiguriert man ein ganz normales LAG.

Womit man deinen nächsten Punkt verneinen kann:

Es gibt für redundante Netzwerke nur zwei Möglichkeiten wie man diese realisiert:

1. VRRP und STP über zwei Uplinks
2. Hardware-Stack

Um sich gegen Loops an Edge-Switchen zu schützen gibts verschiedene Möglichkeiten, je nach Hersteller. (Stichwort LBD)
Das hilft auch gegen (vom User installierte) Rogue-Switche, die kein STP sprechen, auf denen ein Loop gesteckt ist. Mit STP müsste man dann erst mit BPDUGuard hantieren.

Mehr gibt es nicht. Und das die großen Unternehmen davon weg wollen, wäre mir auch neu. Warum boomen dann nach wie vor die Portfolios großer Hersteller von solchen Stack-Lösungen (Cisco, Extreme Networks, Alcatel, Brocade/Ruckus) ? Eben weil die solche Sachen wie Hitless Failover beherrschen. Wenn diese unbeliebt sind, dann einzig aus dem Grund das die bei Ihren Stacking-Technologien keine Standards verwenden und ihre eigene Suppe kochen.

Natürlich werden Stacks immer noch eingesetzt. Aber:

• Hauptsächlich im Edge Bereich
• Wenn im Core-Bereich, dann selten als einzelner Stack. Man hat dann eher zwei Core-Switche, die jeweils ein Stack sind. Das macht man, wenn man entsprechend viele Ports braucht.

Zwei Stacks, bestehend aus jeweils zwei oder mehr Switchen. Ein ganzer Stack kann wegfallen, ohne dass es Auswirkungen auf das Netzwerk hat.

 

[f3nr!s]

Ok. Ich kenne das als MCT, mit MLAG konnte ich nichts anfangen. Tatsächlich bin ich da nicht ganz auf dem aktuellen Stand. Habe kein Problem das zuzugeben.

2013 kam das Thema zum ersten Mal bei Brocade auf und da wurde es zwar supported aber eher schlecht als recht. Priorität lag eher auf Stack. Das Problem was ich damals schon sah war: Hat zwar seine Vorteile, aber mit wachsender Anzahl von Routern/Switchen wird es in der Konfiguration sehr aufwendig und Komplex.

Stack ist da tatsächlich einfacher. Mit einer einzigen Kommandozeile kann ich bei Brocade/Ruckus zum Beispiel ein Stack erstellen und habe genau das was ich erreichen will: Hitless Failover und Core-Switch ist eine logische Einheit (Konfigurationsaufwand generell somit sehr gering).

Keine Frage, MCT hat entscheidende Vorteile in größeren Infrastrukturen um die Bandbreite/Durchsatz zu erhöhen. Geht eben bei Stack nicht. Wenn die Backplane maximal 80Gbits unterstützt, dann bleibt es auch beim hinzufügen eines weiteren Switches bei 80Gbits.

VRRP sehe ich persönlich kritisch. Simple wirtschaftliche Überlegung: Du kaufst ein Setup aus zwei Layer-3-Switchen und zahlst für teilweise ordentliche Modelle mal schnell 2k pro Stück. Dann hast du zwar im Fall der Fälle Ausfallsicherheit, aber ansonsten läuft der zweite quasi in Standby für 2k. Teures Standby. Bei zwei kleinen Routern, zum Beispiel mit pfSense oder OPNsense und dann mit CARP, kann ich das noch eher verstehen.

Habe mich mit VRRP und VRRP-E ansonsten auch nie weiter beschäftigt, mittlerweile gibt es da auch schon wieder neue Versionen. Fand Stacking immer besser und einfacher. Macht das was es soll. Zumal man bei Brocade/Ruckus für VRRP-E auch wieder eine extra Premium-Router-Lizenz benötigt die auch um die 600€ kostet.

Ich muss hier bisschen die Moneten zusammen halten.

Zum Thema "Kosten und Sinn": Man muss sich halt überlegen für was ich das brauchen sollte... ich kann hier nicht ein riesiges Setup aufbauen und zich tausend Euro versenken. Die Hochverfügbarkeit ist in dem Setup auch vielleicht das falsche Wort, geht eher um Ausfallsicherheit. Kann man eine Downtime von paar Stunden verkraften? Ja. Kann man einen Ausfall von mehreren Tagen in Kauf nehmen? Nein.

Also was bleibt um die Kosten und den Nutzen im Überblick zu behalten in meinem Fall? Hatte zwei Möglichkeiten, entweder einen Core-Switch anschaffen auf die Gefahr hin das eine der Flöten geht (mehrere Tage im schlechtesten Fall Downtime) oder einen Stack in einfacher Ausführung damit es wenigstens mit der Hälfte/Drittel weitergeht. Ich spreche hier von einem Unternehmen mit knapp 70 Mitarbeitern.

 

[gaym0r]

VRRP sehe ich persönlich kritisch. Simple wirtschaftliche Überlegung: Du kaufst ein Setup aus zwei Layer-3-Switchen und zahlst für teilweise ordentliche Modelle mal schnell 2k pro Stück. Dann hast du zwar im Fall der Fälle Ausfallsicherheit, aber ansonsten läuft der zweite quasi in Standby für 2k. Teures Standby.

Ausfallsicherheit kostet halt immer Geld. Du kannst dir auch redundante Uplinks für Switche sparen. Oder redundante Uplinks für Server. Zweites Netzteil für Server ist auch unnötig teuer. Genauso wie VM-Cluster. Zentrale Firewalls kann man auch eingleisig aufbauen, anstelle eines Active-Passives Clusters. Aber macht das Sinn? Muss man halt immer überlegen wie viel Ausfall man sich erlauben möchte/kann. Bei einer 4 Mann Bude mag das egal sein, wenn die mal für 2h kein Internet oder keinen Zugriff auf die Server haben. Wenn da 50 Mann hinter hängen ist das schon etwas anderes.
Du sprichst von 2k Euro pro Switch? So einer läuft mal eben 5 Jahre, da sprechen wir also von <40€ im Monat. Ziemlich günstig für Ausfallsicherheit.

Und wo ist der Unterschied zwischen:
Zwei Switche im Stack
und
Zwei einzelne Switche (mit VRRP)

Warum genau ist die erste Lösung in Ordnung, die andere aber zu teuer?

 

[f3nr!s]

Und wo ist der Unterschied zwischen:
Zwei Switche im Stack
und
Zwei einzelne Switche (mit VRRP)

Warum genau ist die erste Lösung in Ordnung, die andere aber zu teuer?

Nein, da hast du mich falsch verstanden. Zu teuer, wenn ich mir zusätzlich zu dem bereits bestehenden Stack nochmal zwei Switche mit meinetwegen MCT/MC-LAG kaufen würde. Wenn ich jetzt komplett neu machen müsste, dann hätte ich da entsprechend die Wahl und dann wären solche Sachen wie Komplexität und Konfigurationsaufwand entscheidend.

Der derzeitige Stack läuft jetzt auch schon 3 Jahre ohne Probleme und hat mich damals insgesamt knapp 3000€ gekostet. Die Anforderung, trotz der vielen Server, ist dennoch relativ niedrig. Die Verantwortlichen sagen halt selbst: Ausfallsicherheit so, dass man weiterarbeiten kann, aber keine Hochverfügbarkeit wie in einem Rechenzentrum und dann eben lieber die Kosten im Rahmen halten.

Die Philosophie ist da teilweise auch eher so, das Datensicherheit höchste Priorität hat, aber Verfügbarkeit untergeordnet ist.