Überwachen von Knoten in einem Chassis-Cluster
Um den Cluster überwachen zu können, müssen Sie die Redundanzgruppen ermitteln. Wenn Sie ein Gerät im Chassis-Cluster-Modus initialisieren, erstellt das System eine Redundanzgruppe, die in diesem Thema als Redundanzgruppe 0 bezeichnet wird. Redundanzgruppe 0 verwaltet den Vorrang und das Failover zwischen den Routingmodulen auf den einzelnen Knoten des Clusters. Wie bei allen Redundanzgruppen kann die Redundanzgruppe 0 jeweils nur auf einem Knoten primär sein. Der Knoten, auf dem die Redundanzgruppe 0 primär ist, bestimmt, welche Routing-Engine im Cluster aktiv ist. Ein Knoten gilt als primärer Knoten des Clusters, wenn seine Routing-Engine die aktive ist. Sie können eine oder mehrere Redundanzgruppen mit den Nummern 1 bis 128 konfigurieren, die in diesem Abschnitt als Redundanzgruppe x bezeichnet werden. Die maximale Anzahl der Redundanzgruppen entspricht der Anzahl der redundanten Ethernet-Schnittstellen +1, die Sie konfigurieren. Jede Redundanzgruppe x fungiert als unabhängige Failovereinheit und ist jeweils nur auf einem Knoten primär. Es sind keine MIBS verfügbar, um diese Informationen abzurufen.
Verwenden des Junos OS XML Management Protocol oder des NETCONF XML Management Protocol
Verwenden Sie den get-configuration Remote Procedure Call (RPC), um die Redundanzkonfiguration und die auf dem Gerät vorhandenen Redundanzgruppen abzurufen. Dadurch werden die konfigurierten Redundanzgruppen bereitgestellt.
XML-RPC für den Konfigurationsabruf
<rpc> <get-configuration inherit="inherit" database="committed"> <configuration> <chassis> <cluster> </cluster> </chassis> </configuration> </get-configuration> </rpc>
Antwort:
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:junos="http://xml.juniper.net/junos/10.4I0/junos"> <configuration xmlns="http://xml.juniper.net/xnm/1.1/xnm" junos:commit-seconds="1277806450" junos:commit-localtime="2010-06-29 03:14:10 PDT" junos:commit-user="regress"> <chassis> <cluster> <reth-count>10</reth-count> <control-ports> <fpc>4</fpc> <port>0</port> </control-ports> <control-ports> <fpc>10</fpc> <port>0</port> </control-ports> <redundancy-group> <name>0</name> <node> <name>0</name> <priority>254</priority> </node> <node> <name>1</name> <priority>1</priority> </node> </redundancy-group> <redundancy-group> <name>1</name> <node> <name>0</name> <priority>100</priority> </node> <node> <name>1</name> <priority>1</priority> </node> </redundancy-group> </cluster> </chassis> </configuration> </rpc-reply> ]]>]]>
Redundante Ethernet-Schnittstellen für Chassis-Cluster
Eine redundante Ethernet-Schnittstelle ist eine Pseudoschnittstelle, die mindestens eine physische Schnittstelle von jedem Knoten des Clusters enthält. Eine redundante Ethernet-Schnittstelle wird in Konfigurationsbefehlen als Reth bezeichnet. Die folgende Beispielausgabe zeigt zwei Redundanzgruppen, die vorhanden und konfiguriert sind.
- Verwenden des Junos OS XML Management Protocol oder des NETCONF XML Management Protocol
- Verwenden von SNMP
Verwenden des Junos OS XML Management Protocol oder des NETCONF XML Management Protocol
Verwenden Sie den
get-chassis-cluster-interfacesRemote Procedure Call (RPC), um die Details der reth-Schnittstelle abzurufen. Die folgende Beispielausgabe zeigt vier konfigurierte reth-Schnittstellen:XML-RPC für Chassis-Cluster-Schnittstellen
user@host>
show chassis cluster interfaces |display xml<rpc-reply xmlns:junos="http://xml.juniper.net/junos/11.4R5/junos"> <chassis-cluster-interface-statistics> <control-interface-status>Up</control-interface-status> <control-link-interfaces> <control-information> <control-link-interface-index>0</control-link-interface-index> <control-link-interface-name>em0</control-link-interface-name> <control-link-interface-status>Up</control-link-interface-status> </control-information> <control-information> <control-link-interface-index>1</control-link-interface-index> <control-link-interface-name>em1</control-link-interface-name> <control-link-interface-status>Down</control-link-interface-status> </control-information> </control-link-interfaces> <dataplane-interface-status>Up</dataplane-interface-status> <dataplane-interfaces> <fabric-information> <fabric-interface-index>0</fabric-interface-index> <fabric-child-interface-name>ge-6/0/15</fabric-child-interface-name> <fabric-child-interface-status>Up</fabric-child-interface-status> <fabric-interface-index>0</fabric-interface-index> </fabric-information> <fabric-information> <fabric-interface-index>1</fabric-interface-index> <fabric-child-interface-name>ge-19/0/15</fabric-child-interface-name> <fabric-child-interface-status>Up</fabric-child-interface-status> <fabric-interface-index>1</fabric-interface-index> </fabric-information> </dataplane-interfaces> <reth> <reth-name>reth0</reth-name> <reth-status>Down</reth-status> <redundancy-group-id-for-reth>1</redundancy-group-id-for-reth> <reth-name>reth1</reth-name> <reth-status>Down</reth-status> <redundancy-group-id-for-reth>Not configured</redundancy-group-id-for-reth> <reth-name>reth2</reth-name> <reth-status>Down</reth-status> <redundancy-group-id-for-reth>1</redundancy-group-id-for-reth> <reth-name>reth3</reth-name> <reth-status>Down</reth-status> <redundancy-group-id-for-reth>Not configured</redundancy-group-id-for-reth> <reth-name>reth4</reth-name> <reth-status>Down</reth-status> <redundancy-group-id-for-reth>1</redundancy-group-id-for-reth> <reth-name>reth5</reth-name> <reth-status>Down</reth-status> <redundancy-group-id-for-reth>1</redundancy-group-id-for-reth> <reth-name>reth6</reth-name> <reth-status>Down</reth-status> <redundancy-group-id-for-reth>1</redundancy-group-id-for-reth> <reth-name>reth7</reth-name> <reth-status>Down</reth-status> <redundancy-group-id-for-reth>1</redundancy-group-id-for-reth> <reth-name>reth8</reth-name> <reth-status>Down</reth-status> <redundancy-group-id-for-reth>1</redundancy-group-id-for-reth> <reth-name>reth9</reth-name> <reth-status>Down</reth-status> <redundancy-group-id-for-reth>1</redundancy-group-id-for-reth> <reth-name>reth10</reth-name> <reth-status>Up</reth-status> <redundancy-group-id-for-reth>1</redundancy-group-id-for-reth> <reth-name>reth11</reth-name> <reth-status>Down</reth-status> <redundancy-group-id-for-reth>1</redundancy-group-id-for-reth> <reth-name>reth12</reth-name> <reth-status>Down</reth-status> <redundancy-group-id-for-reth>Not configured</redundancy-group-id-for-reth> <reth-name>reth13</reth-name> <reth-status>Up</reth-status> <redundancy-group-id-for-reth>1</redundancy-group-id-for-reth> <reth-name>reth14</reth-name> <reth-status>Up</reth-status> <redundancy-group-id-for-reth>1</redundancy-group-id-for-reth> <reth-name>reth15</reth-name> <reth-status>Up</reth-status> <redundancy-group-id-for-reth>1</redundancy-group-id-for-reth> <reth-name>reth16</reth-name> <reth-status>Up</reth-status> <redundancy-group-id-for-reth>1</redundancy-group-id-for-reth> </reth> <interface-monitoring> </interface-monitoring> </chassis-cluster-interface-statistics> <cli> <banner>{secondary:node0}</banner> </cli> </rpc-reply> user@host>show chassis cluster interfacesControl link status: Up Control interfaces: Index Interface Status 0 em0 Up 1 em1 Down Fabric link status: Up Fabric interfaces: Name Child-interface Status fab0 ge-6/0/15 Up fab0 fab1 ge-19/0/15 Up fab1 Redundant-ethernet Information: Name Status Redundancy-group reth0 Down 1 reth1 Down Not configured reth2 Down 1 reth3 Down Not configured reth4 Down 1 reth5 Down 1 reth6 Down 1 reth7 Down 1 reth8 Down 1 reth9 Down 1 reth10 Up 1 reth11 Down 1 reth12 Down Not configured reth13 Up 1 reth14 Up 1 reth15 Up 1 reth16 Up 1 {secondary:node0}Verwenden Sie den
get-interface-informationRemote Procedure Call (RPC), um Details zur reth-Schnittstelle anzuzeigen und die reth-Schnittstellen auf dem Gerät zu identifizieren. Dieser RPC zeigt auch, welche Gigabit-Ethernet- oder Fast-Ethernet-Schnittstellen zu welcher reth-Schnittstelle gehören, wie in der folgenden Beispielausgabe gezeigt:XML-RPC für Schnittstelleninformationen
<rpc> <get-interface-information> <terse/> <interface-name>reth0</interface-name> </get-interface-information> </rpc><rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:junos="http://xml.juniper.net/junos/10.4I0/junos"> <interface-information xmlns="http://xml.juniper.net/junos/10.4I0/junos-interface" junos:style="terse"> <physical-interface> <name> reth0 </name> <admin-status> up </admin-status> <oper-status> up </oper-status> <logical-interface> <name> reth0.0 </name> <admin-status> up </admin-status> <oper-status> up </oper-status> <filter-information> </filter-information> <address-family> <address-family-name> inet </address-family-name> <interface-address> <ifa-local junos:emit="emit"> 192.168.29.2/24 </ifa-local> </interface-address> </address-family> <address-family> <address-family-name> multiservice </address-family-name> </address-family> </logical-interface> </physical-interface> </interface-information> Now, the interface that belongs to this. Extracting only the relevant information <rpc> <get-interface-information> <terse/> </get-interface-information> </rpc><rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:junos="http://xml.juniper.net/junos/10.4I0/junos"> <interface-information xmlns="http://xml.juniper.net/junos/10.4I0/junos-interface" junos:style="terse"> <physical-interface> <name> ge-5/1/1 </name> <admin-status> up </admin-status> <oper-status> up </oper-status> <logical-interface> <name> ge-5/1/1.0 </name> <admin-status> up </admin-status> <oper-status> up </oper-status> <filter-information> </filter-information> <address-family> <address-family-name> aenet </address-family-name> <ae-bundle-name> reth0.0 </ae-bundle-name> </address-family> </logical-interface> </physical-interface> </interface-information>
In der Beispielausgabe identifiziert das
ae-bundle-nameTag die reth-Schnittstelle, zu der es gehört.
Verwenden von SNMP
Die ifTable MIB-Tabelle meldet alle reth-Schnittstellen.
Verwenden Sie die ifStackStatus-MIB-Tabelle, um die reth-Schnittstelle den zugrunde liegenden Schnittstellen auf dem primären und sekundären Knoten zuzuordnen. Die reth-Schnittstelle ist die obere Schicht, und die einzelnen Schnittstellen beider Knoten werden als Indizes der unteren Ebene angezeigt.
Beispiel-SNMP-Daten für die Details der Reth-Schnittstelle
Im folgenden Beispiel gehören ge-5/1/1 und ge-11/1/1 zu reth0:
{primary:node0} user@host>show interfaces terse | grep reth0ge-5/1/1.0 up up aenet --> reth0.0 ge-11/1/1.0 up up aenet --> reth0.0 reth0 up up reth0.0 up up inet 192.168.29.2/24Den Index aller Schnittstellen finden Sie in der ifTable. Die folgenden Informationen zeigen Indizes von Schnittstellen, die in diesem Beispiel erforderlich sind:
{primary:node0} user@host>show snmp mib walk ifDescr | grep reth0ifDescr.503 = reth0.0 ifDescr.528 = reth0Suchen Sie nun in der Tabelle ifStackStatus nach dem Index für reth0. In der folgenden Beispielausgabe ist der reth0-Index 503 der Index der höheren Ebene, und die Indizes 522 und 552 sind die Indizes der niedrigeren Ebene. Die Indizes 522 und 552 repräsentieren die Schnittstellen ge-5/1/1.0 bzw. ge-11/1/1.0.
{primary:node0} user@host>show snmp mib walk ifStackStatus | grep 503ifStackStatus.0.503 = 1 ifStackStatus.503.522 = 1 ifStackStatus.503.552 = 1 {primary:node0} user@host>show snmp mib walk ifDescr | grep 522ifDescr.522 = ge-5/1/1.0 {primary:node0} user@host>show snmp mib walk ifDescr | grep 552ifDescr.552 = ge-11/1/1.0
Verwenden der Steuerungsebene
Die Steuerungsebenensoftware, die im Aktiv-/Backup-Modus arbeitet, ist ein integraler Bestandteil von Junos OS, der auf dem primären Knoten eines Clusters aktiv ist. Es erreicht Redundanz, indem es Status, Konfiguration und andere Informationen an die inaktive Routing-Engine auf dem sekundären Knoten übermittelt. Wenn die primäre Routing-Engine ausfällt, ist die sekundäre bereit, die Kontrolle zu übernehmen. Die folgenden Methoden können verwendet werden, um Steuerportinformationen zu ermitteln.
Verwenden des Junos OS XML Management Protocol oder des NETCONF XML Management Protocol
Verwenden Sie den get-configuration Remote Procedure Call (RPC), um die Konfiguration des Steuerports abzurufen, wie in der folgenden Beispielausgabe gezeigt.
XML-RPC für redundante Gruppenkonfiguration
<rpc> <get-configuration inherit="inherit" database="committed"> <configuration> <chassis> <cluster> </cluster> </chassis> </configuration> </get-configuration> </rpc>
Verwenden der Data Plane
Die Data Plane-Software, die im Aktiv/Aktiv-Modus arbeitet, verwaltet die Datenflussverarbeitung und Sitzungsstatusredundanz und verarbeitet den Transitdatenverkehr. Alle Pakete, die zu einer bestimmten Sitzung gehören, werden auf demselben Knoten verarbeitet, um sicherzustellen, dass die gleiche Sicherheitsbehandlung auf sie angewendet wird. Das System identifiziert den Knoten, auf dem eine Sitzung aktiv ist, und leitet seine Pakete zur Verarbeitung an diesen Knoten weiter. Die Datenverknüpfung wird als Fabric-Schnittstelle bezeichnet. Es wird von den Packet Forwarding Engines des Clusters verwendet, um Transitverkehr zu übertragen und den dynamischen Laufzeitstatus der Data Plane-Software zu synchronisieren. Wenn das System die Fabric-Schnittstelle erstellt, weist die Software ihr eine intern abgeleitete IP-Adresse zu, die für die Paketübertragung verwendet wird. Die Fabric ist eine physische Verbindung zwischen zwei Knoten eines Clusters und wird durch die Verbindung eines Paares von Ethernet-Schnittstellen (eine von jedem Knoten) gebildet. Die folgenden Methoden können verwendet werden, um die Schnittstellen der Datenebene zu bestimmen.
- Verwenden des Junos OS XML Management Protocol oder des NETCONF XML Management Protocol
- Verwenden von SNMP
Verwenden des Junos OS XML Management Protocol oder des NETCONF XML Management Protocol
Verwenden Sie den get-chassis-cluster-data-plane-interfaces Remote Procedure Call (RPC), um die Data Plane-Schnittstellen abzurufen, wie in der folgenden Beispielausgabe gezeigt.
XML-RPC für Cluster-Datenebenenschnittstelle – Details
<rpc> <get-chassis-cluster-data-plane-interfaces> </get-chassis-cluster-data-plane-interfaces> </rpc><rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:junos="http://xml.juniper.net/junos/10.4I0/junos"> <chassis-cluster-dataplane-interfaces> <fabric-interface-index>0</fabric-interface-index> <fabric-information> <child-interface-name>xe-5/0/0</child-interface-name> <child-interface-status>up</child-interface-status> </fabric-information> <fabric-interface-index>1</fabric-interface-index> <fabric-information> <child-interface-name>xe-11/0/0</child-interface-name> <child-interface-status>up</child-interface-status> </fabric-information> </chassis-cluster-dataplane-interfaces>
Verwenden von SNMP
Die ifTable MIB-Tabelle meldet Fabric-Schnittstellen (Fab-Schnittstellen) und die Link-Schnittstellen. Die Beziehung zwischen den zugrunde liegenden Schnittstellen und den Fabric-Schnittstellen kann jedoch nicht mithilfe von SNMP bestimmt werden.
Bereitstellen von Chassis-Clusterknoten
Verwenden Sie das XML-Verwaltungsprotokoll NETCONF für die Konfiguration und Bereitstellung von Geräten der SRX-Serie und Junos OS-Geräten im Allgemeinen. Wir empfehlen die Verwendung von Gruppen zur Konfiguration von Chassis-Clustern der SRX-Serie. Verwenden Sie globale Gruppen für alle Konfigurationen, die zwischen den Knoten gemeinsam sind.
Junos OS-Commit-Skripte können verwendet werden, um die Konfiguration nach Belieben anzupassen.
Junos OS-Commit-Skripte sind:
Zur Commit-Zeit ausführen
Überprüfen der eingehenden Konfiguration
Führen Sie unter anderem folgende Aktionen aus:
Scheitern des Commits (Selbstverteidigung)
Ändern der Konfiguration (selbstkorrigierend)
Commit-Skripte können:
Generieren von benutzerdefinierten Fehler-/Warnungs-/Syslog-Meldungen
Vornehmen von Änderungen oder Korrekturen an der Konfiguration
Commit-Skripte geben Ihnen eine bessere Kontrolle darüber, wie Ihre Geräte konfiguriert sind, um Folgendes durchzusetzen:
Ihre Designregeln
Details zur Implementierung
100 Prozent Ihres Designanspruchs