Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Grundlegendes zur kurzlebigen Konfigurationsdatenbank

Bei der flüchtigen Datenbank handelt es sich um eine alternative Konfigurationsdatenbank, die eine schnelle programmgesteuerte Schnittstelle zum Ausführen von Konfigurationsupdates auf Geräten mit Junos OS und Junos OS Evolved bereitstellt. Die kurzlebige Datenbank ermöglicht es JET-Anwendungen (Juniper Extension Toolkit) und Client-Anwendungen des NETCONF- und Junos-XML-Managementprotokolls, Konfigurationsänderungen gleichzeitig auf ein Gerät zu laden und zu übertragen, und das mit einem deutlich höheren Durchsatz als bei der Übertragung von Daten in die Kandidatenkonfigurationsdatenbank.

In den folgenden Abschnitten werden die verschiedenen Aspekte der kurzlebigen Konfigurationsdatenbank erläutert.

Vorteile der kurzlebigen Konfigurationsdatenbank

  • Ermöglicht mehreren Clientanwendungen die gleichzeitige Konfiguration eines Geräts, indem Daten geladen und an separate Instanzen der kurzlebigen Datenbank übergeben werden
  • Ermöglicht schnelle Bereitstellung und schnelle Konfigurationsänderungen in dynamischen Umgebungen, die schnelle Commit-Zeiten erfordern

Übersicht über die Ephemeral Configuration Database

Bei der Verwaltung von Junos-Geräten besteht die empfohlene und gebräuchlichste Methode zur Konfiguration des Geräts darin, die Kandidatenkonfiguration zu ändern und zu bestätigen, die einer persistenten (statischen) Konfigurationsdatenbank entspricht. Der standardmäßige Commit-Vorgang verarbeitet Konfigurationsgruppen, Makros und Commit-Skripts. führt Commit-Prüfungen durch, um die Syntax und Semantik der Konfiguration zu validieren; und speichert Kopien der festgeschriebenen Konfigurationen. Das standardmäßige Commit-Modell ist robust, da es Konfigurationsfehler verhindert und es Ihnen ermöglicht, zu einer zuvor festgeschriebenen Konfiguration zurückzukehren. In einigen Fällen kann der Commit-Vorgang jedoch eine beträchtliche Menge an Zeit und Geräteressourcen in Anspruch nehmen.

JET-Anwendungen sowie NETCONF- und Junos-XML-Protokoll-Clientanwendungen können die kurzlebige Datenbank ebenfalls konfigurieren. Bei der kurzlebigen Datenbank handelt es sich um eine alternative Konfigurationsdatenbank, die eine Konfigurationsschicht bereitstellt, die sowohl von der Kandidatenkonfigurationsdatenbank als auch von den Konfigurationsebenen anderer Clientanwendungen getrennt ist. Das kurzlebige Commit-Modell ermöglicht es Junos-Geräten, Änderungen von mehreren Clients zu committen und zusammenzuführen und die Commits mit deutlich höherem Durchsatz auszuführen als bei der Übertragung von Daten in die Kandidatenkonfigurationsdatenbank. Daher ist die kurzlebige Datenbank in dynamischen Umgebungen von Vorteil, in denen eine schnelle Bereitstellung und schnelle Konfigurationsänderungen erforderlich sind, wie z. B. in großen Datencentern.

Ein Commitvorgang für die kurzlebige Datenbank erfordert weniger Zeit als derselbe Vorgang für die statische Datenbank, da die kurzlebige Datenbank nicht der gleichen Validierung unterzogen wird, die für die statische Datenbank erforderlich ist. Daher bietet das kurzlebige Commitmodell eine bessere Leistung als das standardmäßige Commitmodell, jedoch auf Kosten einiger der robusteren Features des Standardmodells. Für das kurzlebige Commit-Modell gelten die folgenden Einschränkungen:

  • Die Konfigurationsdatensyntax wird überprüft, die Semantik der Konfigurationsdaten jedoch nicht.

  • Bestimmte Konfigurationsanweisungen werden nicht unterstützt, wie unter Nicht unterstützte Konfigurationsanweisungen in der Ephemeral Configuration Database beschrieben.

  • Konfigurationsgruppen und Schnittstellenbereiche werden nicht verarbeitet.

  • Makros, Commit-Skripte und Übersetzungsskripte werden nicht verarbeitet.

  • Frühere Versionen der flüchtigen Konfiguration werden nicht archiviert.

  • Kurzlebige Konfigurationsdaten werden in der normalen Konfiguration mit Standard-show-Befehlen nicht angezeigt.

  • Kurzlebige Konfigurationsdaten bleiben nicht erhalten, wenn Sie:

    • Installieren Sie ein Paket, für das das Junos-Schema neu erstellt werden muss, z. B. ein OpenConfig- oder YANG-Paket.

    • Führen Sie ein Software-Upgrade oder ein Unified In-Service Software Upgrade (ISSU) durch.

    • Starten Sie das Gerät neu oder schalten Sie es aus und wieder ein.

VORSICHT:

Es wird dringend empfohlen, bei der Verwendung der flüchtigen Konfigurationsdatenbank Vorsicht walten zu lassen, da durch die Übertragung ungültiger Konfigurationsdaten die kurzlebige Datenbank beschädigt werden kann, was zu einem Neustart oder sogar zum Absturz von Junos-Prozessen führen und zu einer Unterbrechung des Systems oder Netzwerks führen kann.

Junos-Geräte validieren die Syntax, nicht aber die Semantik oder Einschränkungen der Konfigurationsdaten, die an die flüchtige Datenbank übergeben wurden. Wenn die Konfiguration z. B. auf eine nicht definierte Routing-Richtlinie verweist, ist die Konfiguration zwar syntaktisch korrekt, aber semantisch falsch. Das standardmäßige Commit-Modell generiert in diesem Fall einen Commit-Fehler, das kurzlebige Commit-Modell jedoch nicht. Daher ist es zwingend erforderlich, alle Konfigurationsdaten zu validieren, bevor sie in die kurzlebige Datenbank übernommen werden. Wenn Sie Konfigurationsdaten bestätigen, die ungültig sind oder zu einer unerwünschten Netzwerkunterbrechung führen, müssen Sie die problematischen Daten aus der Datenbank löschen oder das Gerät ggf. neu starten, wodurch alle kurzlebigen Konfigurationsdaten gelöscht werden.

Anmerkung:

In der flüchtigen Konfigurationsdatenbank werden neben den Konfigurationsdaten auch interne Versionsinformationen gespeichert. Daher ist die Größe der flüchtigen Konfigurationsdatenbank für dieselben Konfigurationsdaten immer größer als die der statischen Konfigurationsdatenbank, und die meisten Vorgänge in der kurzlebigen Datenbank, ob Hinzufügungen, Änderungen oder Löschungen, erhöhen die Größe der Datenbank.

Anmerkung:

Wenn Sie die kurzlebige Konfigurationsdatenbank verwenden, können Commitvorgänge für die statische Konfigurationsdatenbank länger dauern, da zusätzliche Vorgänge ausgeführt werden müssen, um die statischen und kurzlebigen Konfigurationsdaten zusammenzuführen.

Kurzlebige Datenbankinstanzen

Junos-Geräte bieten standardmäßig eine kurzlebige Standard-Datenbankinstanz, die automatisch aktiviert wird, sowie die Möglichkeit, benutzerdefinierte Instanzen der kurzlebigen Konfigurationsdatenbank zu aktivieren. JET-Anwendungen und NETCONF- und Junos-XML-Protokoll-Clientanwendungen können gleichzeitig Daten in separate Instanzen der kurzlebigen Datenbank laden und festschreiben. Die aktive Gerätekonfiguration ist eine zusammengeführte Ansicht der statischen und kurzlebigen Konfigurationsdatenbanken.

Anmerkung:

Ab Junos OS Version 18.2R1 unterstützt Junos OS die Konfiguration von bis zu sieben benutzerdefinierten Instanzen der kurzlebigen Konfigurationsdatenbank. In früheren Versionen konnten Sie bis zu acht benutzerdefinierte Instanzen konfigurieren. Junos OS Evolved unterstützt die Konfiguration von acht benutzerdefinierten Instanzen.

Kurzlebige Datenbankinstanzen sind nützlich in Szenarien, in denen mehrere Clientanwendungen gleichzeitig eine Gerätekonfiguration aktualisieren müssen, z. B. wenn zwei oder mehr SDN-Controller gleichzeitig Konfigurationsdaten an dasselbe Gerät übertragen. Im Standard-Commit-Modell kann ein Controller eine exklusive Sperre für die Kandidatenkonfiguration haben, wodurch der andere Controller daran gehindert wird, sie zu ändern. Durch die Verwendung separater kurzlebiger Instanzen können die Controller die Änderungen gleichzeitig bereitstellen.

Anmerkung:

Anwendungen können zusätzlich zur statischen Konfigurationsdatenbank gleichzeitig Daten in verschiedene kurzlebige Datenbankinstanzen laden und festschreiben. Das Gerät verarbeitet die Commits jedoch sequenziell. Daher kann sich der Commit für eine bestimmte Datenbank je nach Verarbeitungsreihenfolge verzögern.

Die Junos-Prozesse lesen die Konfigurationsdaten sowohl aus der statischen Konfigurationsdatenbank als auch aus der kurzlebigen Konfigurationsdatenbank. Wenn eine oder mehrere flüchtige Datenbankinstanzen verwendet werden und widersprüchliche Daten vorhanden sind, überschreiben Anweisungen in einer Datenbank mit höherer Priorität die Anweisungen in einer Datenbank mit niedrigerer Priorität. Die Datenbankpriorität, von der höchsten zur niedrigsten, lautet wie folgt:

  1. Anweisungen in einer benutzerdefinierten Instanz der kurzlebigen Konfigurationsdatenbank.

    Wenn mehrere benutzerdefinierte kurzlebige Instanzen vorhanden sind, wird die Priorität durch die Reihenfolge bestimmt, in der die Instanzen auf der [edit system configuration-database ephemeral] Hierarchieebene konfiguriert werden, und zwar von der höchsten zur niedrigsten Priorität.

  2. Anweisungen in der standardmäßigen kurzlebigen Datenbankinstanz.

  3. Anweisungen in der statischen Konfigurationsdatenbank.

Betrachten Sie die folgende Konfiguration:

Abbildung 1 veranschaulicht die Prioritätsreihenfolge der flüchtigen Datenbankinstanzen und der statischen (festgeschriebenen) Konfigurationsdatenbank. In diesem Beispiel hat die flüchtige Datenbankinstanz 1 die höchste Priorität, gefolgt von der kurzlebigen Datenbankinstanz 2, dann der standardmäßigen kurzlebigen Datenbankinstanz und schließlich der statischen Konfigurationsdatenbank.

Abbildung 1: Kurzlebige Datenbankinstanzen Ephemeral Database Instances

Vergängliches allgemeines Commit-Modell für Datenbanken

JET-Anwendungen und NETCONF- und Junos-XML-Protokoll-Clientanwendungen können die kurzlebige Konfigurationsdatenbank ändern. JET-Anwendungen müssen Konfigurationsanforderungen als Paare von Lade- und Commit-Vorgängen senden. NETCONF- und Junos XML-Protokoll-Clientanwendungen können mehrere Ladevorgänge ausführen, bevor sie einen Commit-Vorgang ausführen.

VORSICHT:

Sie müssen alle Konfigurationsdaten validieren, bevor Sie sie in die flüchtige Datenbank laden und auf dem Gerät übertragen, da die Übertragung ungültiger Konfigurationsdaten dazu führen kann, dass Junos-Prozesse neu gestartet werden oder sogar abstürzen und zu einer Unterbrechung des Systems oder Netzwerks führen.

Clientanwendungen können gleichzeitig Daten in verschiedene Instanzen der kurzlebigen Datenbank laden und festschreiben. Commits, die gleichzeitig für verschiedene kurzlebige Instanzen ausgegeben werden, werden vom Gerät in die Warteschlange gestellt und seriell verarbeitet. Wenn ein Client die Verbindung zu einer Sitzung trennt, verwirft das Gerät alle nicht festgeschriebenen Konfigurationsänderungen in der kurzlebigen Instanz, aber Konfigurationsdaten, die bereits von diesem Client an die kurzlebige Instanz festgeschrieben wurden, sind davon nicht betroffen.

Wenn Sie einen Commit für eine kurzlebige Instanz ausführen, überprüft das System die Syntax, nicht aber die Semantik der kurzlebigen Konfigurationsdaten. Wenn der Commit abgeschlossen ist, benachrichtigt das Gerät die betroffenen Systemprozesse. Die Prozesse lesen die aktualisierte Konfiguration und führen die flüchtigen Daten in der aktiven Konfiguration zusammen, gemäß den Regeln der Priorisierung, die unter Kurzlebige Datenbankinstanzen beschrieben sind. Die aktive Gerätekonfiguration ist eine zusammengeführte Ansicht der statischen und kurzlebigen Konfigurationsdatenbanken.

Anmerkung:

Aufgrund der architektonischen Unterschiede zwischen den beiden Betriebssystemen ist die Commit-Zeit der kurzlebigen Datenbank auf Geräten mit Junos OS Evolved etwas länger als auf Geräten mit Junos OS.

Ausführliche Informationen zum Commit und Synchronisieren von Instanzen der kurzlebigen Konfigurationsdatenbank finden Sie unter Commit und Synchronisierung von flüchtigen Konfigurationsdaten mithilfe des NETCONF- oder Junos XML-Protokolls.

Verwenden der kurzlebigen Datenbank auf Geräten, die Hochverfügbarkeitsfunktionen verwenden

Hochverfügbarkeit bezieht sich auf die Hardware- und Softwarekomponenten, die Redundanz und Zuverlässigkeit für die Netzwerkkommunikation bieten. Es gibt bestimmte Verhaltensweisen und Vorbehalte, die berücksichtigt werden sollten, bevor die kurzlebige Datenbank auf Systemen verwendet wird, die Hochverfügbarkeitsfunktionen verwenden, einschließlich redundanter Routing-Engines, Graceful Routing Engine Switchover (GRES), Nonstop Active Routing (NSR) und Interchassis-Redundanz für Router der MX-Serie oder Switches der EX-Serie mit Virtual Chassis. In den folgenden Abschnitten werden diese Verhaltensweisen beschrieben und beschrieben, wie sich die verschiedenen kurzlebigen Modelle für die Synchronisierung von Datenbankcommit auf dieses Verhalten auswirken können.

Grundlegendes zu kurzlebigen Datenbank-Commit-Synchronisierungsmodellen

Die kurzlebige Konfigurationsdatenbank verfügt über zwei Modelle zum Synchronisieren flüchtiger Konfigurationsdaten über Routing-Engines oder Virtual Chassis-Mitglieder hinweg während eines Commit-Synchronisierungsvorgangs:

  • Asynchron (Standard)

  • Synchron

Im Gegensatz zum standardmäßigen Commit-Modell führt das standardmäßige kurzlebige Commit-Modell Commit-Synchronisierungsvorgänge asynchron aus. Die anfordernde Routing-Engine führt einen Commit für die kurzlebige Konfiguration aus und gibt eine Benachrichtigung über den Abschluss des Commits aus, ohne darauf zu warten, dass die andere Routing-Engine die Konfiguration zuerst synchronisiert und festlegt. Geräte, die Hochverfügbarkeitsfunktionen verwenden, erfordern, dass die primäre Routing-Engine und die Backup-Routing-Engine im Falle eines Failovers synchronisiert werden. Es kann jedoch Situationen geben, in denen ein asynchroner Commit-Synchronisierungsvorgang unterbrochen werden kann und die kurzlebige Konfiguration nicht mit der anderen Routing-Engine synchronisiert werden kann.

Auf Geräten mit Junos OS Version 21.1R1 oder höher und Geräten mit Junos OS Evolved können Sie die kurzlebige Datenbank so konfigurieren, dass ein synchrones Commit-Modell für Commit-Synchronisierungsvorgänge verwendet wird, ähnlich dem Modell, das von der statischen Konfigurationsdatenbank verwendet wird.

In einer Dual-Routing-Engine- oder Virtual Chassis-Umgebung der MX-Serie funktioniert das synchrone Commit-Modell wie folgt:

  1. Die primäre Routing-Engine startet ihren ersten Commit-Vorgang für die kurzlebige Instanz.
  2. Zu einem bestimmten Zeitpunkt während des Commit-Vorgangs initiiert die primäre Routing-Engine einen Commit für die Backup-Routing-Engine.
  3. Wenn die Backup-Routing-Engine die Konfiguration erfolgreich festschreibt, setzt die primäre Routing-Engine ihren Commit-Vorgang fort. Wenn der Commit in der Backup-Routing-Engine fehlschlägt, schlägt auch die primäre Routing-Engine den Commit fehl.
Anmerkung:

Wenn ein Virtual Chassis der EX-Serie das synchrone Commit-Modell verwendet, initiiert der Member-Switch in der primären Routing-Engine-Rolle zunächst den Commit-Vorgang für die anderen Member gleichzeitig. Da ein Virtual Chassis der EX-Serie viele Mitglieder haben kann, fährt der primäre Switch mit dem Commit-Vorgang fort, auch wenn der Commit bei einem anderen Member fehlschlägt.

Synchrone Commit-Vorgänge sind langsamer als asynchrone Commit-Vorgänge, bieten jedoch eine bessere Sicherheit, dass die flüchtige Konfiguration zwischen Routing-Engines und Virtual Chassis-Mitgliedern synchronisiert wird. Das synchrone Commitmodell ermöglicht es Ihnen daher, die kurzlebige Datenbank mit größerer Zuverlässigkeit auf Geräten zu verwenden, die auch Hochverfügbarkeitsfunktionen verwenden.

Anmerkung:

Wie bei der statischen Konfigurationsdatenbank kann es auch beim synchronen Commit-Synchronisierungsmodell in seltenen Fällen vorkommen, dass das Gerät eine aktualisierte, kurzlebige Konfiguration auf der Backup-Routing-Engine festschreibt, die Commit jedoch nicht in der primären Routing-Engine abschließt, was dazu führt, dass die Konfigurationen nicht synchronisiert sind.

Um das synchrone Commit-Synchronisierungsmodell für die kurzlebige Konfigurationsdatenbank zu aktivieren, konfigurieren Sie die commit-synchronize-model synchronous Anweisung auf Hierarchieebene [edit system configuration-database ephemeral] in der statischen Konfigurationsdatenbank.

Geräte mit Junos OS Version 20.2R1 oder höher und Geräte mit Junos OS Evolved unterstützen auch die Synchronisierung der Failoverkonfiguration für die kurzlebige Datenbank. Wenn Sie die Failoversynchronisierung konfigurieren und das Backup-Routingmodul mit dem primären Routingmodul synchronisiert wird, z. B. wenn es neu eingefügt oder wieder online geschaltet wird oder während einer Rollenänderung, synchronisiert es sowohl seine statische als auch seine kurzlebige Konfigurationsdatenbank. In früheren Junos OS-Versionen synchronisiert die Backup-Routing-Engine nur ihre statische Konfigurationsdatenbank. Um die Failoversynchronisierung zu aktivieren, konfigurieren Sie die commit synchronize Anweisung auf Hierarchieebene [edit system] in der statischen Konfigurationsdatenbank.

Anmerkung:

Bei der Failover-Synchronisierung synchronisiert die Backup-Routing-Engine oder das MX Virtual Chassis-Backup-Gerät die kurzlebige Konfigurationsdatenbank nur dann mit dem primären Gerät, wenn sowohl auf dem Backup-Gerät als auch auf dem primären Gerät dieselbe Softwareversion ausgeführt wird.

Auf Geräten, auf denen Junos OS Version 21.1R1 oder höher ausgeführt wird, und Geräten, auf denen Junos OS Evolved ausgeführt wird, synchronisieren sowohl Commit-Synchronisierungsvorgänge als auch Failover-Synchronisierungsvorgänge die kurzlebigen Konfigurationsdaten mit der anderen Routing-Engine, indem ein Lastaktualisierungsvorgang anstelle eines Lastüberschreibungsvorgangs verwendet wird. Bei Verwendung eines Ladeaktualisierungsvorgangs muss das Gerät nur die Junos-Prozesse benachrichtigen, die während des Updates geänderten Anweisungen entsprechen, wodurch mögliche Netzwerkunterbrechungen minimiert werden.

Redundante Routing-Engines

Dual-Routing-Engine-Systeme unterstützen die Konfiguration der kurzlebigen Datenbank. Das kurzlebige Commit-Modell synchronisiert jedoch während eines Commit-Vorgangs nicht automatisch flüchtige Konfigurationsdaten mit der Backup-Routing-Engine. Clientanwendungen können die Daten in einer kurzlebigen Instanz pro Commit oder pro Sitzung synchronisieren, oder sie können eine kurzlebige Instanz so konfigurieren, dass ihre Daten bei jedem Commit der Instanz automatisch synchronisiert werden. Weitere Informationen finden Sie unter Commit und Synchronisierung flüchtiger Konfigurationsdaten mithilfe des NETCONF- oder Junos XML-Protokolls.

Anmerkung:

Umgebungen mit mehreren Chassis unterstützen die Synchronisierung der flüchtigen Konfigurationsdatenbank mit den anderen Routing-Engines nicht.

Wenn eine Clientanwendung Daten in einer kurzlebigen Instanz festschreibt und mit der Backup-Routing-Engine synchronisiert, führt die kurzlebige Datenbank den Commit-Synchronisierungsvorgang standardmäßig asynchron aus. Sie können die kurzlebige Datenbank so konfigurieren, dass ein synchrones Commit-Modell für Commit-Synchronisierungsvorgänge verwendet wird. Darüber hinaus unterstützen duale Routing-Engine-Geräte ab Junos OS Version 20.2R1 auch die Synchronisierung der Failover-Konfiguration für die kurzlebige Datenbank. Weitere Informationen finden Sie unter Grundlegendes zu kurzlebigen Datenbank-Commit-Synchronisierungsmodellen.

Graceful Routing Engine Switchover (GRES)

Die ordnungsgemäße Umschaltung der Routing-Engine ermöglicht es einem Gerät mit redundanten Routing-Engines, weiterhin Pakete weiterzuleiten, selbst wenn eine Routing-Engine ausfällt. GRES erfordert, dass die primäre Routing-Engine und die Backup-Routing-Engine die Konfiguration und bestimmte Statusinformationen synchronisieren, bevor ein Switchover stattfindet.

Standardmäßig führt die kurzlebige Datenbank Commit-Synchronisierungsvorgänge asynchron aus. Auf unterstützten Geräten, auf denen Junos OS Version 21.1R1 oder höher ausgeführt wird, und Geräten, auf denen Junos OS Evolved ausgeführt wird, können Sie die kurzlebige Datenbank so konfigurieren, dass Commit-Synchronisierungsvorgänge mithilfe eines synchronen Commit-Modells ausgeführt werden, wie unter Grundlegendes zu Modellen zur Commit-Synchronisierung von kurzlebigen Datenbanken beschrieben. Es wird empfohlen, das synchrone Commit-Modell auf Geräten zu verwenden, auf denen GRES aktiviert ist, wenn das Gerät keine strengen Anforderungen an die Commit-Zeiten hat. Synchrone Commit-Vorgänge sind langsamer als asynchrone Commit-Vorgänge, bieten jedoch eine bessere Gewissheit, dass die flüchtige Konfiguration zwischen Routing-Engines synchronisiert wird. Daher können Sie mit diesem Commitmodell die kurzlebige Datenbank mit größerer Zuverlässigkeit auf Geräten verwenden, auf denen GRES aktiviert ist.

Anmerkung:

Geräte mit dualer Routing-Engine, auf denen Junos OS Evolved ausgeführt wird, aktivieren GRES standardmäßig.

Es wird nicht empfohlen, die kurzlebige Datenbank mit dem asynchronen Commit-Synchronisierungsmodell auf Geräten zu verwenden, auf denen GRES aktiviert ist, da die kurzlebige Datenbank unter bestimmten Umständen möglicherweise nicht zwischen dem primären Routingmodul und dem Backup-Routingmodul synchronisiert wird, wenn ein Switchover stattfindet. Beispielsweise synchronisieren das Sicherungsmodul und das primäre Routingmodul die kurzlebige Datenbank möglicherweise nicht, wenn der Commit-Synchronisierungsvorgang durch einen plötzlichen Stromausfall unterbrochen wird. Darüber hinaus wird auf Geräten mit Junos OS Version 20.1 und früher die Konfiguration der Backup-Routing-Engine nicht mit der kurzlebigen Konfigurationsdatenbank synchronisiert, wenn die Backup-Routing-Engine ihre Konfiguration mit der primären Routing-Engine synchronisiert. Wenn also z. B. das Backup-Routingmodul neu gestartet wird, werden die kurzlebigen Konfigurationsdaten gelöscht, die bei Neustarts nicht beibehalten werden, und die Datenbank wird nicht automatisch erneut synchronisiert, wenn sie online geschaltet wird. Dies kann dazu führen, dass die kurzlebige Datenbank bei einem Switchover möglicherweise nicht zwischen dem Sicherungsmodul und dem primären Routingmodul synchronisiert wird.

Wenn GRES aktiviert ist und die kurzlebige Datenbank das asynchrone Commit-Modell (Standardeinstellung) verwendet, müssen Sie das Gerät explizit so konfigurieren, dass flüchtige Konfigurationsdaten mit der Backup-Routing-Engine synchronisiert werden. Um die Synchronisierung zu aktivieren, konfigurieren Sie die allow-commit-synchronize-with-gres Anweisung auf Hierarchieebene [edit system configuration-database ephemeral] in der statischen Konfigurationsdatenbank. Wenn GRES aktiviert ist und Sie die allow-commit-synchronize-with-gres Anweisung nicht konfigurieren, synchronisieren Geräte, die das asynchrone Commit-Modell verwenden, die kurzlebige Instanz nicht mit der Backup-Routing-Engine, wenn Sie einen Commit-Synchronisierungsvorgang für diese Instance anfordern.

Nonstop Active Routing (NSR)

Standardmäßig führt die kurzlebige Datenbank Commit-Synchronisierungsvorgänge asynchron aus. Auf unterstützten Geräten, auf denen Junos OS Version 21.1R1 oder höher ausgeführt wird, und Geräten, auf denen Junos OS Evolved ausgeführt wird, können Sie die kurzlebige Datenbank so konfigurieren, dass Commit-Synchronisierungsvorgänge mithilfe eines synchronen Commit-Modells ausgeführt werden, wie unter Grundlegendes zu Modellen zur Commit-Synchronisierung von kurzlebigen Datenbanken beschrieben. Es wird empfohlen, das synchrone Commit-Modell auf Geräten zu verwenden, auf denen Nonstop Active Routing (NSR) aktiviert ist. Synchrone Commit-Vorgänge sind langsamer als asynchrone Commit-Vorgänge, bieten jedoch eine bessere Gewissheit, dass die flüchtige Konfiguration zwischen Routing-Engines synchronisiert wird. Daher können Sie mit diesem Commit-Modell die kurzlebige Datenbank mit größerer Zuverlässigkeit auf Geräten verwenden, auf denen NSR aktiviert ist.

Es wird nicht empfohlen, die kurzlebige Datenbank mit dem asynchronen Commit-Synchronisierungsmodell auf Geräten zu verwenden, auf denen NSR aktiviert ist, da dies mit bestimmten Einschränkungen verbunden ist. In einer Bereitstellung mit zwei Routing-Engines führt ein Commit-Synchronisierungsvorgang für eine kurzlebige Instanz auf der primären Routing-Engine zu einem asynchronen Commit auf der Backup-Routing-Engine. Wenn das Gerät den Routing-Protokollprozess (RPD) benachrichtigt, während die Konfiguration aktualisiert wird, kann dies aufgrund der asynchronen Natur des Commits auf der Backup-Routing-Engine zu einem unerwünschten Verhalten des Systems führen.

Die Prozesse, die benachrichtigt werden, wenn eine kurzlebige Instanz mit der Backup-Routing-Engine synchronisiert wird, hängen von der Junos OS-Version ab. Wenn Sie in Junos OS Version 20.4 und früher eine kurzlebige Instanz auf der primären Routing-Engine aktualisieren, überschreibt die Änderung an der Backup-Routing-Engine die vollständige Konfiguration für die kurzlebige Instanz und ersetzt sie durch die neueste. Wenn in Junos OS Version 20.1 und früher die neue Konfiguration auf die Backup-Routing-Engine angewendet wird, benachrichtigt Junos OS alle Systemprozesse, die über Anweisungen in dieser kurzlebigen Instanz verfügen. Ab Junos OS Version 20.2R1 wurde das Verhalten der kurzlebigen Datenbank verbessert. Wenn die kurzlebige Instanz bereits zwischen der primären Routing-Engine und der Backup-Routing-Engine synchronisiert ist und Sie die kurzlebige Instanz auf der primären Routing-Engine aktualisieren, benachrichtigt Junos OS nur die Prozesse, die den geänderten Teilen der kurzlebigen Instance-Konfiguration entsprechen, wenn die Änderungen an der Backup-Routing-Engine übernommen werden. Ab Junos OS Version 21.1R1 synchronisiert das Gerät die kurzlebige Instanz mit der Backup-Routing-Engine, indem es einen Ladeaktualisierungsvorgang anstelle eines Lastüberschreibungsvorgangs verwendet, sodass nur Prozesse benachrichtigt werden, die geänderten Anweisungen entsprechen.

Anmerkung:

Anwendungen, die die kurzlebige Datenbank verwenden, sind von dieser NSR-Situation nur betroffen, wenn sie mit dem Routing-Protokollprozess interagieren. Beispielsweise wäre der SmartWall Threat Defense Director (SmartWall TDD) in diesem Fall nicht betroffen, da er nur über die flüchtige Datenbank mit dem Firewall-Prozess (dfwd) interagiert.

Virtuelles Chassis der MX-Serie

Ab Junos OS Version 20.2R1 unterstützen Virtual Chassis der MX-Serie die Konfiguration der kurzlebigen Datenbank. Sie können eine kurzlebige Instanz nur auf der primären Routing-Engine des primären Virtual Chassis-Geräts konfigurieren und festschreiben.

Ein Virtual Chassis der MX-Serie synchronisiert während eines Commit-Vorgangs nicht automatisch flüchtige Konfigurationsdaten. Wie bei dualen Routing-Engine-Systemen können Sie die Daten in einer kurzlebigen Instanz pro Commit oder pro Sitzung synchronisieren, oder Sie können eine kurzlebige Instanz so konfigurieren, dass ihre Daten bei jedem Commit der Instanz automatisch synchronisiert werden. Die flüchtigen Daten werden nur von der primären Routing-Engine auf dem primären Gerät mit der primären Routing-Engine auf dem Backup-Gerät synchronisiert.

Anmerkung:

Virtual Chassis der MX-Serie synchronisieren unter keinen Umständen flüchtige Konfigurationsdaten von der primären Routing-Engine mit der Backup-Routing-Engine auf dem jeweiligen Virtual Chassis-Mitglied.

Für das Virtual Chassis der MX-Serie muss GRES konfiguriert sein. Wenn Sie die kurzlebige Datenbank für die Verwendung des synchronen Commit-Synchronisierungsmodells konfigurieren, synchronisiert das Gerät die kurzlebige Instanz mit der anderen Routing-Engine, wenn Sie einen Commit-Synchronisierungsvorgang anfordern. Wenn die kurzlebige Datenbank jedoch das asynchrone Commit-Synchronisierungsmodell (Standardeinstellung) verwendet, müssen Sie die Anweisung explizit in der statischen Konfigurationsdatenbank konfigurieren, um die allow-commit-synchronize-with-gres Synchronisierung zu aktivieren. Weitere Informationen zu den kurzlebigen Datenbank-Commit-Modellen finden Sie unter Grundlegendes zu Modellen zur Synchronisierung von kurzlebigen Datenbank-Commits .

Wenn Sie eine kurzlebige Instanz auf einem Virtual Chassis der MX-Serie, das das asynchrone Commit-Synchronisierungsmodell verwendet, festschreiben und synchronisieren:

  1. Das primäre Virtual Chassis-Gerät validiert die Konfigurationssyntax und führt einen Commit für die kurzlebige Instanz auf seiner primären Routing-Engine aus.

  2. Wenn der Commit erfolgreich ist, benachrichtigt das primäre Gerät das Backup-Gerät, um die kurzlebige Instanz zu synchronisieren.

  3. Das Backup-Gerät führt einen Commit für die kurzlebige Instanz nur auf seiner primären Routing-Engine durch. Wenn der Commit-Vorgang fehlschlägt, protokolliert das Sicherungsmedium eine Meldung in der Systemprotokolldatei, benachrichtigt jedoch nicht das primäre Gerät.

Wenn Sie eine kurzlebige Instanz auf einem Virtual Chassis der MX-Serie, das für die Verwendung des synchronen Commit-Synchronisierungsmodells konfiguriert ist, festschreiben und synchronisieren:

  1. Das primäre Virtual Chassis-Gerät beginnt mit dem Commit der kurzlebigen Instanz auf seiner primären Routing-Engine.

  2. An einem bestimmten Punkt des Commit-Vorgangs initiiert das primäre Gerät einen Commit auf der primären Routing-Engine des Backup-Geräts.

  3. Wenn das Sicherungsgerät die Konfiguration erfolgreich festschreibt, fährt das primäre Gerät mit dem Commit-Vorgang fort. Wenn das Sicherungsgerät die Konfiguration nicht festschreiben kann, schlägt auch das primäre Gerät den Commit fehl.

Wenn Sie das asynchrone Commit-Synchronisierungsmodell für die kurzlebige Datenbank verwenden, kann der Commit auf dem primären Gerät erfolgreich sein, auf dem Sicherungsgerät jedoch fehlschlagen. Wenn Sie das synchrone Commit-Synchronisierungsmodell verwenden, ist der Commit für beide primären Routing-Engines entweder erfolgreich oder schlägt fehl, außer in seltenen Fällen.

Virtual Chassis der MX-Serie unterstützen die Synchronisierung der Failover-Konfiguration für die flüchtige Datenbank. Wenn Sie die commit synchronize Anweisung auf Hierarchieebene [edit system] in der statischen Konfigurationsdatenbank konfigurieren und die primäre Routing-Engine auf der Virtual Chassis-Sicherungseinheit mit der primären Routing-Engine auf der primären Virtual Chassis-Einheit synchronisiert wird, z. B. nach einem Neustart, werden sowohl die statische als auch die flüchtige Konfigurationsdatenbank synchronisiert.

Anmerkung:

Bei der Failover-Synchronisierung synchronisiert das MX Virtual Chassis-Backup-Gerät die kurzlebige Konfigurationsdatenbank nur dann mit dem primären Gerät, wenn auf beiden Geräten dieselbe Softwareversion ausgeführt wird.

Virtual Chassis der EX-Serie

Virtual Chassis der EX-Serie unterstützen die kurzlebige Konfigurationsdatenbank. Sie können eine kurzlebige Instanz nur auf dem Mitglieds-Switch in der primären Routing-Engine-Rolle konfigurieren und festschreiben. Ab Junos OS Version 23.4R1 können Sie die kurzlebige Datenbank über Virtual Chassis-Mitglieder der EX-Serie hinweg synchronisieren.

Ein Virtual Chassis der EX-Serie synchronisiert während eines Commit-Vorgangs nicht automatisch flüchtige Konfigurationsdaten. Sie können die Daten in einer kurzlebigen Instanz pro Commit oder pro Sitzung synchronisieren, oder Sie können eine kurzlebige Instanz so konfigurieren, dass ihre Daten bei jedem Commit der Instanz automatisch synchronisiert werden.

Sie können GRES auf einem virtuellen Chassis der EX-Serie konfigurieren, damit das virtuelle Chassis weiterhin Pakete weiterleiten kann, wenn die primäre Routing-Engine ausfällt. Wenn Sie die kurzlebige Datenbank für die Verwendung des synchronen Commit-Synchronisierungsmodells konfigurieren, synchronisiert das Gerät die kurzlebige Instanz mit den anderen Membern, wenn Sie einen Commit-Synchronisierungsvorgang anfordern. Wenn die kurzlebige Datenbank jedoch das asynchrone Commit-Synchronisierungsmodell (Standard) verwendet und GRES konfiguriert ist, müssen Sie die allow-commit-synchronize-with-gres Anweisung in der statischen Konfigurationsdatenbank explizit konfigurieren, um die Synchronisierung zu aktivieren.

Wenn Sie eine kurzlebige Instanz auf einem virtuellen Chassis der EX-Serie, das das asynchrone Commit-Synchronisierungsmodell verwendet, festschreiben und synchronisieren:

  1. Der Mitgliedsswitch in der primären Routing-Engine-Rolle überprüft die Konfigurationssyntax und führt einen Commit für die kurzlebige Instanz aus.

  2. Wenn der Commit erfolgreich ist, benachrichtigt das primäre Gerät den commit-syncd Prozess, der den Commit wiederum auf jedem Member-Switch initiiert.

  3. Jeder Mitgliedsschalter führt einen Commit für die kurzlebige Instanz aus. Wenn der Commitvorgang für einen Member fehlschlägt, wirkt sich dies nicht auf den Commitvorgang für die anderen Member aus.

Wenn Sie eine kurzlebige Instanz auf einem virtuellen Chassis der EX-Serie, das für die Verwendung des synchronen Commit-Synchronisierungsmodells konfiguriert ist, festschreiben und synchronisieren:

  1. Der Mitglieds-Switch in der primären Routing-Engine-Rolle initiiert den Commit auf allen Mitglieds-Switches gleichzeitig.

  2. Jeder Mitgliedsswitch führt einen Commit für die kurzlebige Instanz aus und benachrichtigt den primären Switch. Wenn der Commitvorgang für einen Member fehlschlägt, wirkt sich dies nicht auf den Commitvorgang für die anderen Member aus.

  3. Nachdem der primäre Switch Antworten von allen Mitglieds-Switches erhalten hat, führt er einen Commit für die kurzlebige Instanz aus.

Wie beschrieben, verlässt sich der primäre Switch im asynchronen Modell darauf, dass der commit-syncd Prozess die Commits für jeden Mitgliedsswitch nacheinander initiiert. Wenn der commit-syncd Prozess aus irgendeinem Grund fehlschlägt, werden einige Commits möglicherweise nicht initiiert. Beim synchronen Commit-Modell initiiert der primäre Switch den Commit auf allen Member-Switches direkt und parallel. Daher ist das synchrone Commitmodell im Allgemeinen zuverlässiger als das asynchrone Commitmodell. Wenn der Commit für ein Member fehlschlägt, wirkt sich dies in beiden Fällen nicht auf den Commit auf die anderen Member aus oder verhindert ihn.

Darüber hinaus zeigt der primäre Switch im synchronen Commit-Modell den Commit-Fortschritt für jedes Mitglied an, während der Commit erfolgt. Im asynchronen Modell finden die Commits im Hintergrund statt, sodass in diesem Fall nur das primäre Gerät die Commit-Ergebnisse protokolliert.

Best Practices für kurzlebige Datenbanken

Die kurzlebige Konfigurationsdatenbank ermöglicht es mehreren Anwendungen, schnelle Konfigurationsänderungen gleichzeitig vorzunehmen. Da für die kurzlebige Konfigurationsdatenbank nicht die gleichen Sicherheitsvorkehrungen wie für die statische Konfigurationsdatenbank gelten, sollten Sie sorgfältig überlegen, wie Sie die kurzlebige Datenbank verwenden. Es wird empfohlen, die folgenden bewährten Methoden zu befolgen, um die Leistung zu optimieren und potenzielle Probleme bei der Verwendung der kurzlebigen Konfigurationsdatenbank zu vermeiden.

Regulieren Sie die Commit-Frequenz

Die kurzlebige Datenbank ist für schnellere Commits ausgelegt. Ein zu häufiges Commit kann jedoch zu Problemen führen, wenn die Anwendungen, die die Konfiguration nutzen, nicht mit der Rate der Commit-Vorgänge Schritt halten können. Daher wird empfohlen, den nächsten Satz von Änderungen erst dann zu übernehmen, wenn der Betriebszustand des Geräts die Änderungen aus dem vorherigen Commit widerspiegelt.

Wenn Sie beispielsweise häufige, schnelle Commits ausführen, kann das Gerät bestimmte Konfigurationsdaten überschreiben, die es in externen Dateien speichert, bevor ein Junos-Prozess das vorherige Update liest. Wenn ein Junos-Prozess ein wichtiges Update verpasst, kann das Gerät oder Netzwerk ein unvorhersehbares Verhalten zeigen.

Datenintegrität sicherstellen

Junos-Geräte validieren die Semantik von Konfigurationsdaten nicht, wenn Sie Daten in eine kurzlebige Datenbank übergeben. Daher müssen Sie vor dem Laden und Bestätigen der Konfiguration zusätzliche Schritte ausführen, um die Datenintegrität sicherzustellen. Wir empfehlen Ihnen immer:

  • Validieren Sie Konfigurationsdaten, bevor Sie sie in die Datenbank laden

  • Zusammengehörige Konfigurationsanweisungen in einer einzigen Datenbank konsolidieren

Sie sollten alle Konfigurationsdaten überprüfen, bevor Sie sie in eine kurzlebige Datenbank laden. Es wird empfohlen, die Konfigurationsdaten mithilfe einer statischen Datenbank vorab zu validieren, die sowohl die Syntax als auch die Semantik validiert.

Darüber hinaus sollten Sie zugehörige Konfigurationsdaten immer in eine einzelne Datenbank laden. Durch das Hinzufügen verwandter oder abhängiger Konfigurationsdaten in derselben Datenbank wird sichergestellt, dass das Gerät verwandte Anweisungen während eines Commit-Vorgangs erkennen und verarbeiten kann. Wenn Sie z. B. einen Firewallfilter in der statischen Konfigurationsdatenbank oder in einer kurzlebigen Konfigurationsdatenbank definieren, sollten Sie die Anwendung des Filters auf eine Schnittstelle in derselben Konfigurationsdatenbank konfigurieren.

Angenommen, Sie konfigurieren einige Anweisungen in der statischen Datenbank, aber Sie konfigurieren verwandte oder abhängige Anweisungen in einer kurzlebigen Datenbank. Wenn Sie einen Commit für die statische Datenbank ausführen, validiert das System die Daten nur innerhalb dieser Datenbank. Das System erkennt die abhängige Konfiguration in der kurzlebigen Datenbank möglicherweise nicht, was dazu führen kann, dass die Validierung und damit der Commit fehlschlägt.

Konsolidierung skalierter Konfigurationen

Es wird empfohlen, skalierte Konfigurationen in eine einzelne kurzlebige Datenbankinstanz zu laden, anstatt sie auf mehrere Datenbanken zu verteilen. Eine skalierte Konfiguration kann z. B. große Listen mit folgenden Elementen umfassen:

  • Richtlinienoptionen

  • Präfix-Listen

  • VLANs

  • Firewall-Filter

Wenn Sie eine Konfigurationshierarchie der obersten Ebene auf eine einzelne Datenbank beschränken, ermöglichen interne Optimierungen den Junos-Prozessen, die Konfiguration effizienter zu nutzen. Wenn Sie die Konfiguration auf mehrere Datenbanken verteilen, müssen Junos-Prozesse alternativ eine zusammengeführte Ansicht der Konfiguration analysieren, was in der Regel mehr Ressourcen und Verarbeitungszeit erfordert.

Tabelle "Änderungshistorie"

Die Funktionsunterstützung hängt von der Plattform und der Version ab, die Sie verwenden. Verwenden Sie den Feature-Explorer , um festzustellen, ob ein Feature auf Ihrer Plattform unterstützt wird.

Loslassen
Beschreibung
20.2R1
Wenn Sie die commit synchronize Anweisung auf Hierarchieebene [edit system] in der statischen Konfigurationsdatenbank konfigurieren und das Backup-Routingmodul mit dem primären Routingmodul synchronisiert wird, z. B. wenn es neu eingefügt oder wieder online geschaltet wird oder während eines Rollenwechsels, synchronisiert es sowohl die statische als auch die kurzlebige Konfigurationsdatenbank.
18.2R1
Ab Junos OS Version 18.2R1 unterstützen Geräte mit Junos OS die Konfiguration von bis zu sieben benutzerdefinierten Instanzen der kurzlebigen Konfigurationsdatenbank. In früheren Versionen konnten Sie bis zu acht benutzerdefinierte Instanzen konfigurieren.