IRF Übersicht

IRF (Intelligent Resilient Framework) ist eine Cluster bzw. Virtualisierungstechnologie, die ursprünglich schon vor etwa 20 Jahren von 3COM (unter dem Namen „XRN“) entwickelt wurde. Diese Technik wurde von H3C adaptiert, um für die selbstentwickelten Netzwerkkomponenten Redundanz auf Chassisebene zu schaffen. Über die Comware Switches ist IRF seit etwa zehn Jahren ein Feature in der HPE Netzwerk-Welt. Der Kerngedanke dieser Technologie ist eine logische Integration zwischen zwei oder mehr (in der Praxis bis zu neun) physikalischen Switches. Diese stellen „nach außen“ einen einzigen logischen Switch dar. Das bedeutet:

• Vereinheitlichung der Management- und Control Planes, insbesondere gemeinsame Running Config
• Gemeinsame, virtuelle System-MAC- und IP-Adressen
• Möglichkeit von LACP Aggregaten auf mehrere physikalische Chassis (sog. Multichassis Link Aggregation)

Die Kopplung der physikalischen Switches erfolgt dabei über die Standard Ethernet Ports. Dedizierte Module und Kabel, wie sie bei anderen Clustertechnologien zum Einsatz kommen, sind nicht notwendig. IRF ist eine der wichtigsten Technologien für die Comware Switches von HPE und in den meisten lokalen Netzen anzutreffen, die mit diesen Switches aufgebaut werden. Dies gilt besonders für den Kernbereich (Core), der aufgrund seiner Redundanzanforderungen für ein solches Feature prädestiniert ist. In einer Reihe von Blogbeiträgen werden wir uns daher mit IRF beschäftigen und die zugehörigen Techniken beschreiben. In diesem ersten Teil geht es um die Themen Netzwerkdesign mit IRF, Voraussetzungen, Grundbegriffe und logischer Aufbau.

IRF im Netzwerkdesign

2-Tier Netzwerk ohne IRF

Die folgende Abbildung zeigt ein klassisches, zweistufiges Design mit redundanten, aber nicht virtualisierten Core Switches. Access Switches werden jeweils an beide Core Switches angebunden, um Redundanz gegenüber dem Ausfall eines der Core Switches oder eines Uplinks zu schaffen.

In diesem Design muss STP (Spanning Tree Protocol) eingeschaltet werden, um die Redundanzen zu kontrollieren. Wird MSTP oder ein Per-VLAN Spanning Tree Protokoll verwendet, so können bei sinnvoller Konfiguration auch alle Uplinks prinzipiell produktiv genutzt werden bzw. werden nicht vollständig geblockt. Bei einer einfacheren Variante wie RSTP ist dies jedoch nicht der Fall. Ferner werden typischerweise die Gateway-IP-Adressen über ein weiteres Redundanzprotokoll wie etwa VRRP virtualisiert werden, um auch auf dieser Ebene hochverfügbar zu arbeiten. Alle Switches müssen darüber hinaus separat konfiguriert und verwaltet werden. Die Server können ohne Clusterprotokoll nur auf Ebene der Links redundant angebunden werden, d.h. nur an ein einziges Switch Chassis. Fällt der Switch aus, sind die Server nicht mehr verfügbar (Single Point of Failure).

2-Tier Netzwerk mit IRF

Betrachten wir nun als Vergleich dasselbe Netzwerk mit IRF.

In diesem Design wurden die Core- sowie die Server Access Switches mit IRF virtualisiert. STP kann hier theoretisch netzwerkweit abgeschaltet werden, da das Netzwerk physikalisch zwar Kreise besitzt, sich logisch jedoch sternförmig darstellt. Ob STP auch tatsächlich ausgeschaltet werden sollte ist eine Frage, die an anderer Stelle (in einem separaten Blogbeitrag) diskutiert wird, denn es verbleibt natürlich die Gefahr fahrlässig oder mutwillig hergestellter Schleifen mit den entsprechenden Problemen für die Verfügbarkeit des Netzes. VRRP oder ähnliche Protokolle können entfallen, denn jede IP-Adresse, die auf dem IRF konfiguriert wird, ist naturgemäß virtuell. Das bedeutet, fällt ein Switch Chassis vollständig aus, ist die Adresse noch über eins der übrigen Chassis verfügbar. Es gibt keinen „Schwenk“ der IP-Adressen zwischen Switches wie bei VRRP oder HSRP. Darüber hinaus wird auch der Verwaltungsaufwand reduziert, da es nicht mehr eine Config pro Switch, sondern nur noch pro Cluster gibt. Gleichwohl ist anzumerken, dass die Größe der Konfigurationen anwächst, da es natürlich insbesondere mehr Switchports je logischem Switch gibt. Die Handlichkeit der Configs ist also etwas reduziert, besonders bei größeren IRFs. Dies fällt normalerweise aber nicht ins Gewicht.

Voraussetzungen

Verfügbarkeit

IRF ist grundsätzlich auf allen Switches der Comware Serie bei HPE verfügbar, also auch auf Client Access Switches wie etwa den 5130. Die Switches, die in einen Cluster überführt werden sollen, müssen derselben Serie angehören. Es muss nicht zwingend dasselbe Modell sein. So ist es z.B. möglich einen 48-Port Switch mit einem 24-Port Switch derselben Switchfamilie zu clustern. Streng genommen ist die Voraussetzung dieselbe Software. Da die Software plattform- aber nicht modellabhängig ist ergibt sich daraus die o.g. Möglichkeit. In der Praxis wird man jedoch meist dasselbe Switchmodell im Cluster betreiben.

Planung

Neben den über alle Plattformen gültigen Voraussetzungen und Einschränkungen wird dringend empfohlen, bereits vor der Planung und dem Kauf von Switches, die im IRF eingesetzt werden sollen, die jeweiligen Datasheets und Configuration Guides zu beachten. Hier finden sich oftmals wichtige Informationen, z.B. welche Ports als phys. IRF Ports gewählt werden können oder wie viele Switches der Plattform überhaupt im Cluster möglich sind.

Clusterverbindung

Von großer Bedeutung für die Planung ist die Frage, welche Ports für die Clusterverbindung genutzt werden sollen. Denn typischerweise müssen dies Ports hoher Bandbreite (z.B. mindestens 10GBit/s) sein. Bei vielen Switchmodellen erfüllen nur die Uplinkports diese Bedingung. Diese sind aber nur in begrenzter Anzahl (meist vier) verfügbar. Fallen also von den Uplinks Ports zwei oder vier für das IRF weg, so ist zu überlegen, wie der Cluster noch möglichst redundant mit dem Rest des Netzes verbunden werden kann. Die tatsächlich gültigen Regeln sind wie oben erwähnt plattformabhängig und in der Doku nachzulesen.

Grundbegriffe

In der offiziellen Terminologie wird der durch IRF gebildete Switchverbund nicht als Cluster bezeichnet, sondern als Fabric oder Domain. Switches innerhalb einer IRF Domain heißen Member Switches oder kurz Member. Die maximale Anzahl Member in einer Domain ist plattformabhängig. Sie liegt zwischen zwei und neun. Jeder Member hat eine von zwei Rollen: Master oder Standby. Standby Switches werden in der Dokumentation auch Subordinate genannt. Je Domain gibt es genau einen Master, die übrigen Switches sind Subordinates. Jeder Subordinate kann die Rolle des Masters übernehmen, wenn der Master ausfällt oder die Verbindung zum Master getrennt wird. Der Master ist der aktive Member, d.h. auf ihm laufen die Management- und Control-Plane Protokolle. Die Standby Switches sind dagegen eher als eine Art Port Extender zu betrachten. Es spielt in der Praxis keine Rolle, welcher Switch in der Fabric die Masterrolle ausführt, da aufgrund der Voraussetzungen alle Member in etwa gleich performant sind. Jeder Member wird ferner durch eine eindeutige Member ID identifiziert, die zwischen 0 und 10 liegt. Default für diese ID ist die 1. Die Member ID wird beim Eintritt in das IRF durch ein Kommando gesetzt. Sie dient anschliessend zur Adressierung der Switches z.B. bei einem Software Update, sowie zur Unterscheidung der Interfaces der Member Switches, da sie die erste Stelle der Interfacebezeichner darstellt. Der erste Access Port eines Switches mit der Member ID 2 hat beispielsweise die ID 2/1/1.

Schließlich wird jeder IRF Member mit einer Priorität 1…32 (Default: 1) konfiguriert, die bei einer Master Election bestimmt, welcher Member der Master wird.

Aufbau der IRF Fabric

Für den Aufbau einer IRF Fabric ist neben der Anzahl der Switches auch die Topologie zu planen. Die Verbindungen zwischen den Switches laufen dabei über die IRF Ports.

IRF Ports

Es ist wichtig zu verstehen, dass ein IRF Port ein LOGISCHER Port ist, dem dann ein oder mehrere physikalische Switchports zugeordnet werden können. Jeder IRF-fähige Switch besitzt per Definition genau zwei IRF Ports, von denen mindestens einer verwendet werden muss. Ein IRF Port ist im Prinzip nichts anderes als ein Link Aggregat. Demzufolge können – wie bei LACP basierten Aggregaten üblich – maximal acht physikalische Ports einem IRF Port zugeordnet werden (wobei es plattformabhängige Restriktionen bzgl. der Ports zu beachten gilt). In der Praxis werden dies typischerweise deutlich weniger sein; ein bis vier Switchports je IRF Port sind üblich um Redundanz auf dieser wichtigen Verbindung herzustellen.

Topologien

Mit Hilfe der IRF Ports kann die Topologie der Fabric hergestellt werden, also die Switches mit ihren Verbindungen. Es gibt genau zwei grundsätzliche Topologien für eine IRF Fabric, die (Daisy) Chain und den Ring (siehe hierzu auch die folgende Abbildung).

Eine Chain ist eine einfache Verkettung der Switches über einen IRF Port je Switch. Da ein IRF Port ein logischer Port ist, kann auch eine Chain redundant aufgebaut werden, indem wir mit zwei oder oder mehr physikalischen Switchports je IRF Port arbeiten. So ist auch in diesem, einfachen Szenario Ausfallsicherheit auf Portebene gegeben. Ein Ring hingegen besitzt inhärente Redundanz über die logischen IRF Ports. Hier besteht kein Bedarf einer Zuordnung von mehr als einem physikalischen Port, freilich ist dies dennoch möglich.

„1 an 2“ Regel für IRF Ports

Die Abbildung oben zeigt auch die Nummerierung für die beiden IRF Ports der Switches und die Verbindungen untereinander. Die beiden IRF Ports eines Switches haben die Nummern n/1 und n/2, mit n = Member ID des Switches. So hat beispielsweise ein Switch mit der Member ID 3 die beiden IRF Ports 3/1 und 3/2. Für die Verbindung der Switches gilt nun die Regel, dass immer der lokale IRF Port mit der Endnummer 1 mit einem remote IRF Port mit der Endnummer 2 verbunden sein muss, wie es in der Abbildung oben zu erkennen ist. Also immer n/1 an m/2. Der Grund hierfür ist einfach: Über den Port n/1 wird die interne Kommunikation für einen Member gesendet, der Port n/2 ist demgegenüber ein Empfänger. Verbindet man zwei Sender oder zwei Empfänger ist das Ergebnis ein Timeout und der Cluster kommt nicht oder nur unvollständig zustande. Dies ist einer der häufigsten Fehler beim Aufbau eines IRF. Im folgenden zweiten Teil des Blogs stellen wir die Konfiguration der IRF Fabric anhand eines einfachen Beispiels vor.