Redundanzprotokolle für Ethernet

Redundanzprotokolle für Ethernet Institute of Embedded Systems (InES) der ZHAW Prof. Hans Weibel 2008 ZHAW

Begriffe und Definitionen Redundanz redundare (lat.) bedeutet im Überfluss vorhanden sein In technischen Systemen allgemein: Es sind mehr Ressourcen vorhanden, als für den störungsfreien Normalbetrieb benötigt werden. Bei einer Störung können diese Ressourcen mobilisiert werden, um das System funktionstüchtig zu erhalten. In Netzwerken: Redundanzprotokolle haben die Aufgabe, Störungen zu erkennen und automatisch darauf zu reagieren. Das ist eine verbreitete Massnahme, die Verfügbarkeit des Netzwerkes zu steigern. Ermöglichen Umbau und Erweiterung von Netzwerken sowie Austausch von Geräten im Betrieb. ZHAW / H. Weibel, 2. Sept. 2008, Folie 2

Begriffe und Definitionen Verfügbarkeit Betrachtungseinheit: kann eine Baugruppe, ein Gerät, ein Kabel, ein (Sub)System, aber auch eine abstrakte Einheit sein wie etwa eine Verbindung oder ein Service Ausfallrate (5): Wahrscheinlichkeit, dass eine Betrachtungseinheit während der Betriebszeit ausfällt Mean Time To Failure (MTTF): mittlere ausfallfreie Arbeitszeit einer Betrachtungseinheit. Es gilt = 1 / MTTF Verfügbarkeit (Availability): das Verhältnis der mittleren Ist- Betriebsdauer zur Soll-Betriebsdauer der Betrachtungseinheit Mean Time To Repair (MTTR) oder auch Mean Down Time (MDT): die mittlere Reparaturzeit einer Betrachtungseinheit ZHAW / H. Weibel, 2. Sept. 2008, Folie 3

Begriffe und Definitionen Zusammenhänge Failure Failure up down up down up MTTR MTTF MTBF Availability A = MTTF / MTBF = MTTF / (MTTF + MTTR) Failure Rate = 1 / MTTF MTTF: Mean Time To Failure MTTR: Mean Time To Repair MTBF: Mean Time Between Failure ZHAW / H. Weibel, 2. Sept. 2008, Folie 4

Begriffe und Definitionen Zusammenhänge Die geschilderten Zusammenhänge gelten nur unter bestimmten Annahmen, die nicht immer erfüllt sind: die Ausfälle sind unabhängig und zufällig verteilt bezieht sich auf eine sinnvolle Nutzungsdauer (d.h. Frühausfälle sind überwunden und es gibt noch keine Alterungserscheinungen) Boden der Badewannenkurve Ausgangspunkt ist der fehlerfreie Zustand der Betrachtungseinheit, der mit der Reparatur wieder hergestellt wird Festzuhalten ist noch: Es geht nur um Wahrscheinlichkeiten und Mittelwerte. Daraus lassen sich keine Aussagen über den Einzelfall ableiten. ZHAW / H. Weibel, 2. Sept. 2008, Folie 5

Begriffe und Definitionen Erkenntnisse Die Verfügbarkeit hängt von der Ausfallrate und der Reparaturzeit ab Die Verfügbarkeit lässt sich verbessern durch eine Reduktion der Ausfallrate, also durch Auswahl der Bauteile Entwicklung, Konstruktion Fertigung und Prüfung Betrieb, Umgebungsbedingungen eine Reduktion der Reparaturzeit, also durch Reaktionsfähigkeit und Ausbildungsstand des Personals schnelle Detektion und Lokalisierung eines Ausfalles (Alarm- und Diagnosemittel) Verfügbarkeit von Ersatzmaterial ein redundant ausgelegtes Netzwerk einzelne Ausfälle werden verkraftet ZHAW / H. Weibel, 2. Sept. 2008, Folie 6

Begriffe und Definitionen Redundanz Beispiel: Die Betrachtungseinheit toleriere einen Fehler. Zum Ausfall kommt es nur, falls ein zweiter Fehler auftritt, bevor die Reparatur des ersten erfolgt ist. up Fault critical Reparatur, System läuft ohne Redundanz up Fault critical Failure down Reparatur ZHAW / H. Weibel, 2. Sept. 2008, Folie 7

Abhängigkeiten zwischen Subsystemen Allgemein Produkt der Verfügbarkeit A A 1 A 2 A tot = A 1 * A 2 A 1 Produkt der Nichtverfügbarkeit 1-A A 2 A tot = 1- (1 - A 1 )*(1- A 2 ) ZHAW / H. Weibel, 2. Sept. 2008, Folie 8

Abhängigkeiten zwischen Subsystemen Beispiel 1 2 9 10 10 Switches keine Kabelausfälle MTTF = 50 Jahre MTTR = 10 h A Linie = (438 000/438 010) 10 = 99.98% ca. 2 h Ausfall pro Jahr wie zwei redundante Linien A Ring = 1 (1 - A Linie ) 2 = 99.999994% ca. 1.9 s Ausfall pro Jahr Diese Zahlen sind natürlich nicht realistisch: Die Beiträge der Verkabelung, Stromversorgung, Fehlbedienung, etc. werden das Bild relativieren! Hinzu kommt die Umschaltdauer, die in dieser Betrachtung vernachlässigt ist. ZHAW / H. Weibel, 2. Sept. 2008, Folie 9

(Rapid) Spanning Tree Protocol Zweck beliebig vermaschtes Ethernet (physische Topologie) ZHAW / H. Weibel, 2. Sept. 2008, Folie 10

(Rapid) Spanning Tree Protocol Zweck beliebig vermaschtes Ethernet (physische Topologie) Baum (aktive Topologie) ZHAW / H. Weibel, 2. Sept. 2008, Folie 11

(Rapid) Spanning Tree Protocol Systematische Vermaschung mit hierarchischer Struktur ZHAW / H. Weibel, 2. Sept. 2008, Folie 12

(Rapid) Spanning Tree Protocol Ringe und Hierarchien von Ringen ZHAW / H. Weibel, 2. Sept. 2008, Folie 13

(Rapid) Spanning Tree Protocol Prinzipielle Arbeitsweise Ziel: Die aktive Topologie hat zu jedem Ziel nur einen Pfad ( Ethernet verlangt eine schleifenfreie Topologie) Switches tauschen Meldungen mit ihren Nachbarn aus, so genannte Bridge Protocol Data Units (BPDUs) mit allgemein bekannter Multicast Adresse. Ein Switch wird als Root gewählt. Die Wahl wird durch konfigurierbare Prioritäten gesteuert. Pfade werden gemäss konfigurierbaren Pfadkosten und Abstand zur Root gewählt. Durch Blockieren von Ports werden Links deaktiviert. Blockierte Ports übertragen aber weiterhin BPDUs (und evtl. andere Protokolle wie LLDP oder PTP). ZHAW / H. Weibel, 2. Sept. 2008, Folie 14

(Rapid) Spanning Tree Protocol Algorhyme von Radia Perlman I think that I shall never see a graph more lovely than a tree. A tree whose crucial property is loop-free connectivity. A tree that must be sure to span so packet can reach every LAN. First, the root must be selected. By ID, it is elected. Least-cost paths from root are traced. In the tree, these paths are placed. A mesh is made by folks like me, then bridges find a spanning tree. ZHAW / H. Weibel, 2. Sept. 2008, Folie 15

(Rapid) Spanning Tree Protocol Varianten STP, RSTP und MSTP In der Urform STP wird zeitgesteuert kommuniziert (alle 2 Sekunden ein Hello-Paket) Die Recovery ist entsprechend lang (bis einige 10 Sekunden). Kaum mehr verwendet und aus der aktuellsten Spec IEEE 802.1D entfernt. Rapid STP (RSTP) ist eine verbesserte Form von STP Detektiert ein Switch Link up oder Link down, dann erfolgt eine eventgesteuerte Kommunikation. Recovery im Bereich einer Sekunde. Multiple STP (MSTP) erweitert RSTP so, dass VLAN-spezifische Bäume gebildet werden können ZHAW / H. Weibel, 2. Sept. 2008, Folie 16

(Rapid) Spanning Tree Protocol Umschaltung und Nebeneffekte Meldungen des Redundanzprotokolls verlangen hohe Priorität Die BPDUs sollten durch anderen Traffic möglichst nicht gebremst werden. Switching Chips haben teilweise eine separate Queue für BPDUs Die verteilte Neuberechnung der aktiven Topologie hat Nebenwirkungen Nicht alle Knoten sind gleichzeitig auf dem neuen Stand. Das bewirkt (in seltenen Fällen): Duplizierung von Frames Reihenfolge von Frames bleibt unter Umständen nicht erhalten. Während der Umschaltung gehen natürlich Frames verloren. ZHAW / H. Weibel, 2. Sept. 2008, Folie 17

(Rapid) Spanning Tree Protocol Umschaltzeit Eine Umschaltung umfasst Detektion des Problems verteilte Neuberechnung der aktiven Topologie Aktivierung/Deaktivierung gewisser Ports Löschen der Adresstabellen Die Detektion kann erfolgen durch den Transceiver (PHY), der Link up und Link down erkennt ist in gewissen Fällen nicht möglich, z.b. bei Verwendung von Medienkonvertern durch wiederholten Verlust von Meldungen des Redundanzprotokolls kann erheblichen Anteil der Umschaltzeit ausmachen (Tuning durch geeignete Konfiguration der Timer) ZHAW / H. Weibel, 2. Sept. 2008, Folie 18

(Rapid) Spanning Tree Protocol Was ist geschützt? Endgerät nur Core geschützt, nicht aber der Access ZHAW / H. Weibel, 2. Sept. 2008, Folie 19

(Rapid) Spanning Tree Protocol Was ist geschützt? Dual-homed Endgeräte mit teilweiser RSTP- Funktionalität schützen auch den Access ZHAW / H. Weibel, 2. Sept. 2008, Folie 20

Die IEC Redundanzprotokolle Netzwerke für industrielle Anwendungen stellen besondere Anforderungen RSTP ist in vielen Fällen ausreichend Es gibt Anwendungen, die nur sehr kurze Umschaltzeiten zulassen IEC 62439 Industrial communication networks: high availability automation networks spezifiziert entsprechende Redundanzprotokolle: das Media Redundancy Protocol (MRP) ermöglicht schnelle Umschaltungen in Ringen das Parallel Redundancy Protocol (PRP) bietet umschaltungsfreie Redundanz IEC 62439 wurde im April 2008 verabschiedet ZHAW/InES bietet zu beiden Protokollen Referenzimplementationen ZHAW / H. Weibel, 2. Sept. 2008, Folie 21

Media Redundancy Protocol Prinzipielle Arbeitsweise Zweck: Schnelle Umschaltung in einem Ring Ein ausgewählter Knoten, der Media Redundancy Manager (MRM), trennt den Ring auf, indem er ein Port blockiert. Der MRM sendet Test-Frames, um den Ring laufend zu überprüfen. Das blockierte Port muss dazu Test-Frames übertragen können. Auftrennung des Ringes wird erkannt, durch Ausbleiben der Test-Frames und eventuell durch Knoten, die den Ausfall erkennen. Diesen senden sponten eine entsprechende Event-Medung Wird der Ring infolge eines Ausfalls getrennt, wird die Blockierung im MRM aufgehoben. ZHAW / H. Weibel, 2. Sept. 2008, Folie 22

Media Redundancy Protocol Prinzipielle Arbeitsweise MRM MRM x ZHAW / H. Weibel, 2. Sept. 2008, Folie 23

Media Redundancy Protocol Spezielle Eigenschaften Die Recovery wird durch den MRM koordiniert. Es können keine Verdoppelungen oder Veränderungen der Reihenfolge auftreten. Die Umschaltzeit ist praktisch unabhängig von der Anzahl Knoten kann aufgrund der Konfigurationsparameter garantiert werden liegt im Bereich einige bis einige hundert Millisekunden ZHAW / H. Weibel, 2. Sept. 2008, Folie 24

Parallel Redundancy Protocol Warum eine weitere Redundanzlösung? Unterbrechungsfreie und umschaltfreie Bewältigung von Ausfällen (bumpless Redundancy) Es gibt Anwendungen, die nur 10 ms Unterbrechung zulassen. Eine Überschreitung führt dazu, dass das System in den Sicheren Zustand fährt, was mit hohen Kosten verbunden sein kann. Zwei parallele Netzwerke überleben vielfältige Ausfallsszenarien Es können herkömmliche Netzwerkkomponenten verwendet werden, inklusive Redundanzmechanismen wie RSTP oder MRP Statische Redundanz Ausfallsicherheit gegenüber Netzwerkunterbruch oder Ausfall einer Netzwerkkomponente (Switch, Netzwerkkarte ) Redundanzmechanismus ist im Endgerät gelöst, nicht im Netzwerk ZHAW / H. Weibel, 2. Sept. 2008, Folie 25

Parallel Redundancy Protocol Grundkonzepte und Möglichkeiten Zwei unabhängige Netzwerke werden parallel betrieben: LAN_A und LAN_B Keine Verbindung zwischen LAN_A und LAN_B Hochverfügbare Knoten besitzen zwei Netzwerkanschlüsse, wobei je einer zu je einem Netz verbunden wird. Es wird immer auf beide Netzwerke gesendet Keine Lastteilung doppelter Traffic Empfangene Duplikate werden abhängig von der Methode akzeptiert oder verworfen Duplicate Accept: Die Anwendung behandelt die Duplikate. Die meisten höheren Protokolle verkraften Duplikate, können aber viel Leistung einbüssen. Duplicate Discard: Das Netzwerk-Interface eliminiert die Duplikate. ZHAW / H. Weibel, 2. Sept. 2008, Folie 26

Parallel Redundancy Protocol Link Redundancy Entity Implementierungsoptionen: Im Netzwerktreiber, im Transport Layer oder in der Hardware sending node receiving node upper layers upper layers link redundancy entity link redundancy entity Tx Rx Tx Rx Tx Rx Tx Rx port A port B port A port B LAN_A LAN_B ZHAW / H. Weibel, 2. Sept. 2008, Folie 27

Parallel Redundancy Protocol Typen von Knoten DAN Dual Attached Node SAN Single Attached Node RedBox Redundancy Box VDAN Virtual DAN ZHAW / H. Weibel, 2. Sept. 2008, Folie 28

Parallel Redundancy Protocol Duplikaterkennung mittels Redundancy Control Trailer dest_addr src_addr type LSDU sequence LAN size FCS 0 6 12 14 RCT dest_addr src_addr type LSDU padding sequence LAN size FCS 0 6 12 14 RCT dest_addr src_addr type LSDU padding sequence LAN size padding FCS 0 6 12 14 RCT ZHAW / H. Weibel, 2. Sept. 2008, Folie 29

Parallel Redundancy Protocol Supervision Frames und Management Ein DAN versendet alle 2000 ms auf beide Interfaces ein Supervision Frame. So werden Ausfälle von Knoten bzw. Netzwerken schnell detektieret. Supervision Frames gehen an eine Multicast MAC (an alle Knoten in der gleichen Broadcast Domain). Jeder DAN führt eine Node Table, die alle sichtbaren Knoten und deren Typ enthält. DANs können von SANs unterschieden werden, weil SANs keine Supervision Frames versenden. Die RedBox versendet Supervision Frames für alle angeschlossenen VDANs. Ein VDAN wird also von den anderen Knoten wie ein DAN wahrgenommen. Der Supervision Mechanismus erzeugt bei einer grossen Anzahl Knoten eine erhebliche Last. ZHAW / H. Weibel, 2. Sept. 2008, Folie 30

Parallel Redundancy Protocol ZHAW/InES Implementationen RedBox: System on Chip mit Duplikaterkennung in Hardware und Supervision-Funktionen auf Softcore CPU. Arbeitet bei 100 Base-TX mit WireSpeed. Duo Driver für Linux: PRP Stack in Software zur Anbindung eines Endsystems über zwei herkömmliche Netzwerkinterfaces. ZHAW / H. Weibel, 2. Sept. 2008, Folie 31

Parallel Redundancy Protocol light Vorerst mal nur eine Idee Strategie der Verdoppelung im Stil PRP, jedoch in einem einzelnen Ring je ein Duplikat nach Westen und eines nach Osten Empfänger behandelt Duplikate im Stil PRP Multicast und Broadcast Frames werden vom sendenden Knoten wieder vom Ring genommen Im Vergleich zu MRP hat eine solche Lösung folgende Eigenschaften Bumpless (keine Umschaltung) doppelte Last Aufwand der Duplikatbehandlung ZHAW / H. Weibel, 2. Sept. 2008, Folie 32

Fazit Es gibt keine one size fits all Lösung! Die Ziele müssen klar sein! Vor welchen Ereignissen will man sich schützen? Was soll geschützt werden? Redundanz macht nur Sinn, wenn das Netz überwacht wird. Auswahlkriterien sind Grad der Fehlertoleranz Umschaltverhalten Verbreitung und Komplexität Verträglichkeit mit anderen Protokollen Kosten ZHAW / H. Weibel, 2. Sept. 2008, Folie 33

Literatur MRP International Standard IEC 62439: Industrial communication networks: high availability automation networks, April 2008, clause 5. PRP International Standard IEC 62439: Industrial communication networks: high availability automation networks, April 2008, clause 6. STP, RSTP IEEE 802.1D-2004, Standard for Local and Metropolitan Area Networks: Media Access Control (MAC) Bridges, June 2004, clause 17 http://ines.zhaw.ch/ High Availability ZHAW / H. Weibel, 2. Sept. 2008, Folie 34