Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Commit-Konfiguration

Mit dem Konfigurationsmodusbefehl können Sie die Änderungen an der Gerätekonfiguration in der Konfigurationsdatenbank speichern und die Konfiguration auf dem commit Gerät aktivieren.

Das Commit-Modell für Konfigurationen

Die Gerätekonfiguration wird mithilfe eines Commit-Modells gespeichert. Eine Kandidatenkonfiguration wird wie gewünscht geändert und dann auf das System übertragen. Wenn eine Konfiguration festgelegt wurde, überprüft das Gerät die Konfiguration auf Syntaxfehler. Wenn keine Fehler gefunden wurden, wird die Konfiguration als juniper.conf.gz aktiviert gespeichert und aktiviert. Die zuvor aktive Konfigurationsdatei wird als erste Rollback-Konfigurationsdatei ( ) gespeichert, und alle anderen Rollback-Konfigurationsdateien werden juniper.conf.1.gz um 1 erhöht. Beispielsweise wird juniper.conf.1.gz sie zur zweiten juniper.conf.2.gz Rollback-Konfigurationsdatei. Auf dem Gerät können maximal 49 Rollback-Konfigurationen (mit der Nummer 1 bis 49) gespeichert sein.

Auf dem Gerät befinden sich die aktuelle Konfigurationsdatei und die ersten drei Rollbackdateien ( juniper.conf.gz.1, juniper.conf.gz.2, juniper.conf.gz.3 ) im /config Verzeichnis. (Die übrigen Rollback-Dateien(4 bis 49) befinden sich in /var/db/config .)

Wenn eine Konfigurationsdatei zur Wiederherstellung vorhanden ist, befindet sich diese Datei rescue.conf.gz auch im /config Verzeichnis. Die Standarddateien der Werkseinstellungen befinden sich im /etc/config Verzeichnis.

Es gibt zwei Mechanismen zur Weiterleitung der Konfigurationen zwischen Routing-Engines innerhalb eines Geräts:

  • Synchronisierung: Propagiert eine Konfiguration von einer Routing-Engine in eine Routing-Engine innerhalb desselben Gerätegehäuses.

    Verwenden Sie den Befehlszeilenbefehl "CLI, um commit synchronize Konfigurationen zu synchronisieren. Wenn eines der Routing-Engines ausgesperrt ist, schlägt die Synchronisierung fehl. Wenn die Synchronisierung aufgrund einer abgeriegelten Konfigurationsdatei ausfällt, können Sie den Befehl commit synchronize force verwenden. Dieser Befehl setzt die Schleuse außer Kraft und synchronisiert die Konfigurationsdateien.

  • Verteilung: Verteilt eine Konfiguration über die Routingebene auf einem Gerät mit mehrerenAssis. Die Verteilung erfolgt automatisch. Es ist kein Benutzerbefehl zur Steuerung des Verteilungsprozesses verfügbar. Wird eine Konfiguration bei der Verteilung einer Konfiguration abgeriegelt, erhält die abgeriegelte Konfiguration nicht die verteilte Konfigurationsdatei, sodass die Synchronisierung fehlschlägt. Sie müssen die Schleuse vor der Konfiguration löschen und die Routingebenen neusynchronisieren.

    Anmerkung:

    Wenn Sie den befehl CLI einer Multi-Assis-Plattform verwenden, wirkt sich die erzwungene Synchronisierung der Konfigurationsdateien nicht auf die Verteilung der Konfigurationsdatei auf der commit synchronize force Routingebene aus. Wenn eine Konfigurationsdatei auf einem Gerät abgesperrt wird, auf dem der Befehl ausgegeben wurde, schlägt die Synchronisierung auf dem Remote-Gerät fehl. Sie müssen die Sperrung löschen und den Befehl erneut synchronization ausführen.

Commit einer Gerätekonfiguration

Verwenden Sie den Konfigurationsmodusbefehl, um Änderungen an der Gerätekonfiguration in der Konfigurationsdatenbank zu speichern und die Konfiguration auf dem commit Gerät zu aktivieren. Sie können den Befehl commit von einer beliebigen Hierarchieebene aus ausführen:

Wenn Sie den Befehl eingeben, wird die Konfiguration commit zuerst auf Syntaxfehler geprüft ( commit check ). Wenn dann die Syntax korrekt ist, wird die Konfiguration aktiviert und zur aktuellen Konfiguration der Betriebsgeräte wird.

Anmerkung:

Wir empfehlen kein Commit-Ausführen eines Commit-Vorgangs auf dem Routing-Engine wenn Graceful Routing-Engine Switchover auf dem Router aktiviert ist.

Ein Konfigurations-Commit kann aus einem der folgenden Gründe ausfallen:

  • In der Konfiguration wird eine falsche Syntax verwendet. Dies führt dazu, dass die Commit-Prüfung nicht besteht.

  • Die Kandidatenkonfiguration, die Sie festlegen möchten, ist größer als 700 MB.

  • Die Konfiguration wird von einem Benutzer abgeriegelt, der den Befehl configure exclusive eingegeben hat.

Wenn die Konfiguration Syntaxfehler enthält, gibt eine Nachricht den Standort des Fehlers an, und die Konfiguration wird nicht aktiviert. Die Fehlermeldung hat das folgende Format:

Zum Beispiel:

Sie müssen den Fehler beheben, bevor Sie die Konfiguration erneut verwenden. Um schnell in die Hierarchieebene zurückzukehren, auf der sich der Fehler befindet, kopieren Sie den Pfad von der ersten Fehlerzeile, und fügen Sie ihn in den Konfigurationsmodus ein, der auf der [edit] Hierarchieebene angezeigt wird.

Die nicht stillgelegte Kandidatenkonfigurationsdatei ist /var/rundb/juniper.db . Sie ist auf 700 MB begrenzt. Wenn das Commit mit einer Nachricht ausfällt, können Sie die Dateigröße im configuration database size limit exceeded Konfigurationsmodus anzeigen, indem Sie den Befehl run file list /var/rundb detail eingeben. Sie können die Konfiguration vereinfachen und die Dateigröße reduzieren, indem Sie Konfigurationsgruppen mit Wildcards erstellen oder weniger spezifische Übereinstimmungsrichtlinien in Ihren Firewall-Filtern definieren.

Anmerkung:

CLI commit-time-Warnungen, die für Konfigurationsänderungen auf Hierarchieebene angezeigt werden, werden entfernt und [edit interfaces] als Systemprotokollmeldungen protokolliert.

Dies gilt auch für die VRRP-Konfiguration auf den folgenden Hierarchieebenen:

  • [edit interfaces interface-name unit logical-unit-number family (inet | inet6) address address]

  • [edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number family (inet | inet6) address address]

Wenn Sie eine Konfiguration festlegen, commiten Sie die gesamte Konfiguration in der aktuellen Form.

Anmerkung:
  • Wir empfehlen keine Commit-Ausführung auf dem Backup-Gerät Routing-Engine wenn Graceful Routing-Engine Switchover auf dem Gerät aktiviert ist.

  • Wenn Sie dieselbe IP-Adresse für eine Verwaltungsschnittstelle oder interne Schnittstelle wie beispielsweise eine externe physische Schnittstelle konfigurieren, wenn fxp0ge-0/0/1 Graceful Routing-Engine Switchover (GRES) aktiviert ist, zeigt der CLI eine entsprechende Commit-Fehlermeldung an, die identische Adressen an privaten und öffentlichen Schnittstellen gefunden haben. In solchen Fällen müssen Sie den beiden Schnittstellen, die adressenvielfältig sind, eindeutige IP-Adressen zuweisen.

Commit-Vorgang, wenn mehrere Benutzer die Software konfigurieren

Bis zu 32 Benutzer können sich im Konfigurationsmodus gleichzeitig mit Änderungen an der Konfiguration befinden. Alle Änderungen, die von allen Benutzern vorgenommen werden, sind für alle sichtbar, die die Konfiguration bearbeiten. Die Änderungen werden sichtbar, sobald der Benutzer die Eingabetaste am Ende eines Befehls betritt, der die Konfiguration ändert (z. B. setedit oder delete .

Wenn einer der Benutzer einen Befehl bearbeitet, werden CLI Änderungen von commit allen Benutzern geprüft und aktiviert.

Wenn Sie den Konfigurationsmodus mit dem Befehl eingeben, verfügt jeder Benutzer über eine private Kandidatenkonfiguration, die in gewissem Weise unabhängig configure private von anderen Benutzern bearbeitet werden kann. Wenn Sie die Konfiguration festlegen, werden CLI nur Ihre eigenen Änderungen commits. Um Ihre Kopie der Konfiguration zu synchronisieren, nachdem andere Benutzer Änderungen vorgenommen haben, können Sie den Befehl im update Konfigurationsmodus ausführen. Ein Commit-Vorgang aktualisiert auch alle privaten Kandidatenkonfigurationen. Beispiel: Nutzer X und Benutzer Y befinden sich im Modus, und configure private Benutzer X commits für eine Konfigurationsänderung. Wenn Benutzer Y einen nachfolgenden Commit-Vorgang vorträgt und dann die neue Konfiguration sieht, enthält die neue Konfiguration von Benutzer Y die von Benutzer X vorgenommenen Änderungen.

Wenn Sie den Konfigurationsmodus mit dem Befehl eingeben, sperren Sie die Kandidatenkonfiguration so lange, configure exclusive wie Sie im Konfigurationsmodus bleiben. Das ermöglicht es Ihnen, Änderungen ohne Interferenzen durch andere Benutzer vorzunehmen. Andere Benutzer können den Konfigurationsmodus ein- oder beenden, aber sie können die Konfiguration nicht commit ausführen. Dies gilt auch, wenn die anderen Benutzer den Konfigurationsmodus eingeben, bevor Sie den Befehl configure exclusive eingeben. Beispiel: Benutzer X ist bereits im configure private Modus oder im configure Modus Dann kommt Nutzer Y in den configure exclusive Modus. Benutzer X kann keine Änderungen an der Konfiguration vornehmen, auch wenn Benutzer X diese Änderungen eingegeben hat, bevor sich Benutzer Y angemeldet hat. Wenn Benutzer Y den Modus verlässt, kann Benutzer X dann die im Modus configure exclusive vorgenommenen Änderungen configure privateconfigure commiten.

Übersicht über die Commit-Vorbereitung und -Aktivierung

Sie können den Commit-Vorgang in zwei Schritten abschließen. Mit der Commit-Funktion in zwei Schritte können Sie mehrere Geräte konfigurieren und gleichzeitig die Konfigurationen aktivieren. Mit einem commit in zwei Schritte können Sie ein bestimmtes Zeitfenster für die Umsetzung eines Commits auf das System festlegen. Sie können den Commit-Modus eingeben, nachdem das Commit vorbereitet ist. Sie erhalten jedoch eine Nachricht, dass die Aktivierung des Commits ansteht.

Im ersten Schritt, der Vorbereitungsphase, wird das Commit validiert und eine neue Datenbank mit den erforderlichen Dateien generiert. Wenn die Konfiguration Syntaxfehler enthält, wird eine entsprechende Fehlermeldung angezeigt und die Konfiguration wird nicht vorbereitet. Wenn in der Vorbereitungsphase ein Fehler auftritt, wird die Fehlermeldung commit check-out failed angezeigt.

Im zweiten Schritt, der Aktivierungsphase, wird die zuvor vorbereitete Konfiguration aktiviert. Wenn Sie die vorbereitete Konfiguration löschen müssen, können Sie dies mithilfe von clear system commit prepared Befehlen tun. Nach der erfolgreichen Clearing des ausstehenden Commit wird eine Protokollnachricht generiert.

Anmerkung:

Zwischen den Vorbereitungs- und Aktivierungsphasen können Keine Commit-Vorgänge ausführen.

Der zweistufige Commit-Prozess ist dem einzelstufigen Prozess für zeitkritische Commits überlegen. In einem Schritt kann die Vorbereitungszeit je nach konfiguration auf dem Gerät variieren. In diesem zweistufigen Prozess werden die komplexen Vorbereitungsarbeiten effizienter gehandhabt.

Es werden Konfigurationsbefehle bereitgestellt, mit denen Sie den Konfigurations-Cache vorbereiten und die Konfiguration aktivieren können. Sie können die Geräte mit neuen Konfigurationen vorbereiten und sie zum genauen Zeitpunkt aktivieren, den Sie möchten.

Der commit prepare Befehl überprüft die Konfigurationen und der Befehl aktiviert die commit activate Konfigurationen. Die Befehle haben folgende Konfigurationsoptionen:

  • and-quit

  • no-synchronize

  • peers-synchronize

  • synchronize

Die commit prepare Befehle und die Befehle sind nur für commit activate private, exklusive und gemeinsam genutzte Commits verfügbar. Die Befehle sind für den dynamischen und kurzlebigen Modus nicht einsetzbar. Diese Funktion ist für Multi-Chassis-Geräte einsetzbar, sie ist jedoch nicht für Batch-Commits anwendbar.

Zur Unterstützung dieser Funktionen mithilfe des Network Configuration Protocol (NETCONF) werden die folgenden neuen Remote-Prozeduraufrufe (RPCs) bereitgestellt:

  • <commit-configuration>< prepare/></commit-configuration>

  • <commit-configuration><activate/></commit-configuration>

  • <clear-system-commit><prepared/></clear-system-commit>

Anmerkung:
  • In einer Konfiguration Virtual Chassis MX-Serie gilt Folgendes: Wenn die Switchover-Routing-Engine eine weitere Option ausgegeben Routing-Engine, wird der commit prepare Switchover-Befehl neu gestartet. Daher wird der vorbereitete Cache in diesem Cache Routing-Engine.

  • In einer Konfiguration Virtual Chassis MX-Serie ist es empfehlenswert, Befehle nur bei VC clear system commit prepared auszuführen.

Commit-Gerätekonfigurationen in zwei Schritten: Vorbereitung und Aktivierung

Sie können den Commit-Vorgang in zwei Schritten abschließen. So können Sie mehrere Geräte konfigurieren und die Konfigurationen können gleichzeitig aktiviert werden. Im ersten Schritt, der als Vorbereitungsphase bekannt ist, wird das Commit validiert und eine neue Datenbank zusammen mit den erforderlichen Dateien generiert. Wenn die Konfiguration Syntaxfehler enthält, wird eine entsprechende Fehlermeldung angezeigt und die Konfiguration wird nicht vorbereitet. Im zweiten Schritt, die als Aktivierungsphase bezeichnet wird, wird die zuvor vorbereitete Konfiguration aktiviert und wird zur aktuellen Konfiguration des Betriebsgeräts.

Zur Vorbereitung der Konfiguration:

  1. Nehmen Sie [edit] auf Hierarchieebene im Konfigurationsmodus die erforderlichen Änderungen an der Konfiguration vor.

    Geben Sie zum Beispiel den folgenden Befehl aus, um die Systemskripte zu konfigurieren:

    Zum Beispiel:

  2. Geben Sie den commit prepare Befehl aus.

    Die Nachricht commit prepare successful wird angezeigt.

    Wenn die Vorbereitungsphase ausfällt, wird die commit check-out failed Fehlermeldung angezeigt.

  3. Verwenden Sie folgenden Befehl, um die Ausgabe des Befehls nach der Ausgabe show system commitcommit prepare zu überprüfen:

So aktivieren Sie die vorbereitete Konfiguration:

  1. Verwenden Sie den commit activate Befehl

    Die Nachricht commit complete wird angezeigt.

  2. Verwenden Sie folgenden Befehl, um die aktivierte Systemkonfiguration zu überprüfen:

Geben Sie die folgenden Befehle an, um die Ausgabe der Befehle und deren Ausgabe show system commitshow system commit revision detail zu commit activate überprüfen.

Gerätekonfiguration mit Bestätigung aktivieren

Wenn Sie die aktuelle Kandidatenkonfiguration festlegen, können Sie eine explizite Bestätigung für die Dauer des Commits erhalten. Dies ist hilfreich, wenn Sie sicherstellen möchten, dass eine Konfigurationsänderung korrekt funktioniert und den Zugriff auf das Gerät nicht verhindert. Wenn die Änderung den Zugriff verhindert oder andere Fehler verursacht, kehrt das Gerät automatisch zur vorherigen Konfiguration zurück und stellt den Zugriff nach den Zeiten der Rollback-Bestätigung wieder zurück. Diese Funktion wird als automatisches Rollback bezeichnet.

Verwenden Sie den Konfigurationsmodus-Befehl, um die aktuelle Kandidatenkonfiguration commit zu machen, benötigen Sie jedoch eine explizite Bestätigung, damit das Commit permanent commit confirmed werden kann:

Sobald Sie überprüft haben, dass die Änderung richtig funktioniert, können Sie die neue Konfiguration aktiv halten, indem Sie innerhalb von 10 Minuten nach dem Befehl einen Befehl commitcommit checkcommit confirmed eingeben. Zum Beispiel:

Wenn das Commit innerhalb einer bestimmten Zeit (standardmäßig 10 Minuten) nicht bestätigt wird, setzt das Betriebssystem automatisch eine Rollback zur vorherigen Konfiguration durch, und eine Broadcast-Nachricht wird an alle angemeldeten Benutzer gesendet.

Geben Sie den Befehl ein, um zu zeigen, wann ein Rollback nach einem commit confirmed Befehl geplant show system commit ist. Zum Beispiel:

Genau wie commit der Befehl überprüft der Befehl die commit confirmed Konfigurationssyntax und meldet Fehler. Wenn keine Fehler auftreten, wird die Konfiguration vorübergehend (standardmäßig 10 Minuten) aktiviert und wird auf dem Gerät ausgeführt.

Abbildung 1: Konfiguration bestätigen Konfiguration bestätigen

Um die Zeit zu ändern, bevor Sie die neue Konfiguration bestätigen müssen, geben Sie die Anzahl der Minuten an, in denen Sie den Befehl angeben:

Sie können den Befehl auch commit confirmed im [edit private] Konfigurationsmodus verwenden.

Commit-Vorgang planen

Sie können planen, wann die Konfiguration Ihres Kandidaten aktiv werden soll. Verwenden Sie den Konfigurationsmodusbefehl (bzw. eine zukünftige Zeit auf der commit at [ ] reboot Hierarchieebene, um Änderungen der Gerätekonfiguration zu speichern und die Konfiguration auf dem Gerät zu einem zukünftigen Zeitpunkt oder beim Neustart zu edit aktivieren:

string ist reboot oder der zukünftige Zeitpunkt ist, die Konfigurationsänderungen zu aktivieren. Sie können die Zeit in zwei Formaten angeben:

  • Ein Zeitwert im Formular [ ] (Stunden, Minuten und optionale Sekunden) – Commit die Konfiguration zum angegebenen Zeitpunkt. Dies muss in der Zukunft, jedoch vor hh:mm:ss 23:59:59 Uhr am Tag der Eingabe des Konfigurationsmodusbefehls, ausgeführt commit at werden. Verwenden Sie die 24-Stunden-Zeit für den Wert; z. B. um 4:30 Uhr und um hh04:30:00 20:00 8:00 Uhr. Die Zeit wird im Hinblick auf die Zeit- und Zeitzoneneinstellungen auf dem Router interpretiert.

  • Datum und Uhrzeit im Formular yyyy-mm-dd hh:mm [ :ss ] (Jahr, Monat, Datum, Stunden, Minuten und optionale Sekunden) – Commit der Konfiguration an dem angegebenen Tag und der Uhrzeit, die nach der Befehlserkennung erforderlich commit at ist. Verwenden Sie für den Wert 24 hh Stunden Zeit. Das ist 2018-08-2112:30:00 beispielsweise am 21. August 2018 um 12:30 Uhr  Die Zeit wird im Hinblick auf die Zeit- und Zeitzoneneinstellungen auf dem Router interpretiert.

Schließen Sie string den Wert in Anführungszeichen ein (" "). Das sind zum commit at "18:00:00" Beispiel Geben Sie für Datum und Uhrzeit beide Werte in den gleichen Anführungszeichen an. Zum Beispiel commit at "2018-03-10 14:00:00".

Bei Ausgabe des Konfigurationsmodusbefehls wird sofort eine commit at Commit-Prüfung durchgeführt. Wenn die Prüfung als Ergebnis erfolgreich ist, wird der aktuelle Benutzer im Konfigurationsmodus abgemeldet, und die Konfigurationsdaten bleiben in einem schreibgeschützten Status. Bis zum Abschluss der geplanten Commits können keine weiteren Commits durchgeführt werden.

Anmerkung:

Wenn die Gerätesoftware ausfällt, bevor die Konfigurationsänderungen aktiv werden, gehen alle Konfigurationsänderungen verloren.

Sie können den Konfigurationsbefehl commit at nicht eingeben, nachdem Sie den Befehl request system reboot angegeben haben.

Sie können den Befehl nicht request system reboot eingeben, sobald Sie einen Commit-Vorgang für eine bestimmte Zeit in der Zukunft planen.

Sie können keine Commit-Konfiguration festlegen, wenn ein geplantes Commit ansteht. Informationen zum Stornieren einer geplanten Konfiguration mit hilfe des Befehls finden Sie im clearCLI Explorer.

Anmerkung:

Wir empfehlen keine Commit-Ausführung auf dem Backup-Gerät Routing-Engine wenn Graceful Routing-Engine Switchover auf dem Gerät aktiviert ist.

Commit-Prozess überwachen

Verwenden Sie für die Überwachung des Commit-Vorgangs in der Gerätekonfiguration den Befehl display detail nach der Pipe mit dem commit Befehl:

Zum Beispiel:

Kommentar hinzufügen, um die zugesagte Konfiguration zu beschreiben

Sie können einen Kommentar hinzufügen, in dem Änderungen an der zugesagten Konfiguration beschrieben werden. Fügen Sie dazu die Erklärung commit comment bei. Der Kommentar kann bis zu 512 Bytes umfassen und nur in einer Zeile eingeben.

comment-string ist der Text des Kommentars.

Anmerkung:

Sie können keinen Kommentar mit dem Befehl commit check hinzufügen.

Um einen Kommentar zum Befehl commit hinzuzufügen, fügen Sie die comment Anweisung nach dem Befehl commit hinzu:

Um einen Kommentar zum Befehl commit confirmed hinzuzufügen, fügen Sie die comment Anweisung nach dem Befehl commit confirmed hinzu:

Geben Sie den Betriebsmodusbefehl aus, um diese Commit-Kommentare show system commit einsingen zu können.

Anmerkung:

Sie können den Befehl auch commit confirmed im [edit private] Konfigurationsmodus verwenden.

Überblick über Batch-Commits

Batch-Commit aggregiert oder vereint mehrfache Konfigurationsbearbeitungen von verschiedenen Sitzungen CLI Benutzern und fügt sie in eine Batch-Commit-Warteschlange hinzu. Ein auf dem Gerät ausgeführter Batch-Commit-Server nimmt mindestens einen Vorgang aus der Commit-Warteschlange in der Batch-Warteschlange in betrieb, wendet die Konfigurationsänderungen auf die gemeinsam genutzte Konfigurationsdatenbank an und übernimmt anschließend die Konfigurationsänderungen in einem commit-Vorgang.

Batches werden vom Commit-Server priorisiert, basierend auf der Priorität des vom Benutzer angegebenen Batches oder der Zeit, in der die Batch-Aufgabe hinzugefügt wird. Nach Abschluss eines Batch-Commits werden die nächsten Konfigurationsänderungen aggregiert und für die nächste Sitzung des Batch-Commit-Betriebs in die Batch-Warteschlange geladen. Es werden Batches erstellt, bis keine Commit-Einträge im Warteschlangenverzeichnis vorhanden sind.

Im Vergleich zu dem regelmäßigen Commit-Vorgang, bei dem alle Commits unabhängig und sequenziell gebunden sind, sparen Batch-Commits Zeit- und Systemressourcen, indem mehrere kleine Konfigurationsbearbeitungen in einem einzigen Commit-Vorgang durchgeführt werden.

Im Konfigurationsmodus werden Batch-Commits [edit batch] ausgeführt. Die Commit-Servereigenschaften können auf der Hierarchieebene [edit system commit server] konfiguriert werden.

Aggregation und Fehlerbehandlung

Wenn in einer der aggregierten Aufträge ein Lastzeitfehler auftritt, wird der Commit-Job, der auf den Fehler tritt, verworfen und die verbleibenden Aufträge werden aggregiert und zugesagt.

Wenn beispielsweise fünf Commit-Aufträge ( , , und ) aggregiert werden und beim Laden ein Fehler auftritt, wird verwerfen und , und sie werden aggregiert und commit-1commit-2commit-3commit-4commit-5commit-3commit-3commit-1commit-2commit-4commit-5 zugesagt.

Wenn beim Commit-Vorgang ein Fehler auftritt, wenn zwei oder mehr Aufgaben aggregiert und zugesagt werden, wird die Aggregation verworfen und jede dieser Aufgaben wird einzeln wie ein regelmäßiger Commit-Vorgang durchgeführt.

Wenn beispielsweise fünf Commit-Aufträge ( , , und ) aggregiert sind und ein Commit-Fehler verursacht wurde, wird die Aggregation verworfen, , und einzeln zugesagt, und der CLI gibt einen commit-1commit-2 Commit-Fehler commit-3 für commit-4commit-5commit-3commit-1commit-2commit-3commit-4commit-5commit-3 an.

Beispiel: Konfigurieren von Batch-Commit-Servereigenschaften

In diesem Beispiel wird die Konfiguration von Batch-Commit-Servereigenschaften zur Verwaltung von Batch-Commit-Vorgängen veranschaulicht.

Anforderungen

In diesem Beispiel werden die folgenden Hardware- und Softwarekomponenten verwendet:

  • Universelle 5G-Routing-Plattform der MX-Serie

Überblick

Sie können steuern, wie die Commit-Commit-Warteschlange vom Commit-Server gehandhabt wird, indem Sie die Servereigenschaften auf der [edit system commit server] Hierarchieebene konfigurieren. Auf diese Weise können Sie steuern, wie viele Commit-Aufgaben aggregiert oder zu einem einzelnen Batch-Commit zusammengeführt werden, die maximale Anzahl an Aufgaben, die der Warteschlange hinzugefügt werden können, Tage für die Commit-Fehlerprotokolle der Batches, das Intervall zwischen zwei Batch-Commits und Ablaufverfolgungsvorgänge für Batch-Commit-Vorgänge.

Konfiguration

CLI-Konfiguration

Um diesen Abschnitt des Beispiels schnell zu konfigurieren, kopieren Sie die folgenden Befehle, fügen Sie sie in eine Textdatei ein, entfernen Sie alle Zeilenbrüche, ändern Sie alle details, die für Ihre Netzwerkkonfiguration erforderlich sind, und kopieren Sie die Befehle, und fügen Sie die Befehle dann in die CLI-Hierarchieebene [edit] ein. Sie können die Commit-Servereigenschaften sowohl im normalen Modus als auch [edit] im Modus [edit batch] konfigurieren.

Gerät R0

Konfigurieren der Commit-Servereigenschaften

Schritt-für-Schritt-Verfahren
  1. (optional) Konfigurieren Sie die Anzahl der Commit-Transaktionen, um in einem Commit-Vorgang zu aggregieren oder zu verbinden.

    Der Standardwert ist maximum-aggregate-pool5 .

    Anmerkung:

    Festlegen maximum-aggregate-pool von 1 Commits für jede der Aufträge einzeln.

    In diesem Beispiel wird die Anzahl der Commit-Transaktionen angegeben, die angibt, dass vier verschiedene Commit-Aufgaben zu einem einzelnen Commit aggregiert werden, bevor der 4 Commit-Vorgang eingeleitet wird.

  2. (optional) Konfigurieren Sie die maximale Anzahl von Aufgaben, die in einem Batch zulässig ist.

    Auf diese Art wird die Anzahl der Commits-Aufträge begrenzt, die der Warteschlange hinzugefügt werden.

    Anmerkung:

    Wenn Sie dies festlegen, kann der Commit-Server nicht mehr als einen Job der Warteschlange hinzufügen, und der CLI wird eine entsprechende Nachricht angezeigt, wenn Sie versuchen, mehr als einen Job maximum-entries1 zu engagieren.

  3. (optional) Konfigurieren Sie die Zeit (in Sekunden), um vor dem nächsten Commit-Vorgang zu warten.

  4. (optional) Konfigurieren Sie die Anzahl von Tagen, um Fehlerprotokolle zu behalten.

    Der Standardwert ist 30 Tage.

  5. (optional) Konfigurieren Sie Ablaufverfolgungsvorgänge zum Protokollieren von Commit-Ereignissen.

    In diesem Beispiel wird der Dateiname für die Protokollierung von Commit-Ereignissen angegeben commitd_nov und alle Traceoption-Flags werden festgelegt.

Ergebnisse

Bestätigen Sie Ihre Konfiguration im Konfigurationsmodus, indem Sie den Befehl show system commit server eingeben. Wenn in der Ausgabe nicht die beabsichtigte Konfiguration angezeigt wird, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.

Konfigurieren im Batch-Konfigurationsmodus

Schritt-für-Schritt-Verfahren

Führen Sie eine der folgenden Aufgaben aus, um die Konfiguration [edit batch] im Modus commiten:

  • Melden Sie sich am Gerät an, und geben Sie commit ein.

  • Wenn Sie einem Batch-Commit-Job eine höhere Priorität zuweisen, geben Sie den commit Befehl mit der Option priority aus.

  • Wenn Sie eine Konfiguration festlegen möchten, ohne die Konfigurationsänderungen mit anderen Commit-Aufgaben in der Warteschlange zu aggregieren, geben Sie den Befehl mit commit der Option atomic aus.

  • Wenn Sie eine Konfiguration festlegen möchten, ohne die Konfigurationsänderungen mit anderen Commit-Aufgaben in der Warteschlange zu aggregieren, und einer Commit-Aufgabe eine höhere Priorität zuweisen, geben Sie den Befehl mit der commit Option atomic priority aus.

Überprüfung

Stellen Sie sicher, dass die Konfiguration ordnungsgemäß funktioniert.

Prüfen des Batch-Commit-Serverstatus

Zweck

Prüfen Sie den Status des Batch-Commit-Servers.

Aktion

Standardmäßig ist der Status des Commit-Servers Not running . Der Commit-Server läuft erst dann, wenn eine Commit-Aufgabe zur Warteschlange hinzugefügt wird.

Wenn eine Commit-Aufgabe einer Batch-Aufgabe zur Warteschlange hinzugefügt wird, wird der Status des Commit-Servers Running geändert.

Bedeutung

Im Jobs in process Feld werden die Commit-IDs von Aufträgen, die in Bearbeitung sind, aufgeführt.

Prüfen des Batch-Commit-Status

Zweck

Prüfen Sie die Commit-Serverwarteschlange auf den Status der Batch-Commits.

Aktion
Bedeutung

Pending commits zeigt Commit-Aufträge an, die der Commit-Warteschlange hinzugefügt, aber noch nicht zugesagt wurden. Completed commits zeigt die Liste der erfolgreichen Commit-Aufgaben an. Error commits commits sind, die aufgrund eines Fehlers fehlgeschlagen sind.

Patchdateien werden in einem Batch-Commit-Job angezeigt

Zweck

Zeigen Sie die Zeitstempel, Patch-Dateien und den Status jeder Commit-Aufgaben an. Patch-Dateien zeigen die Konfigurationsänderungen, die bei jedem Commit-Vorgang auftreten, der der Batch-Commit-Warteschlange hinzugefügt wird.

Aktion
  1. Verwenden Sie show system commit server queue patch den Befehl, um die Patches für alle Commit-Vorgänge zu anzeigen.

    Die Ausgabe zeigt die Änderungen in der Konfiguration für jede Commit-Auftrags-ID.

  2. Geben Sie den Befehl aus, um den Patch für eine bestimmte Commit-Arbeitsauftrags-ID show system commit server queue patch id <id-number> anzeigen zu können.

Bedeutung

Die Ausgabe zeigt den für einen Commit-Job erstellten Patch. Das +- bzw. das Schild gibt die Änderungen in der Konfiguration für einen bestimmten Commit-Job an.

Anzeigen der Trace-Dateien für Batch-Commit-Vorgänge

Zweck

Zeigen Sie die Trace-Dateien für Batch-Commit-Vorgänge an. Sie können die Trace-Dateien für die Fehlerbehebung verwenden.

Aktion
  • Verwenden Sie file show /var/log/<filename> den Befehl, um alle Einträge in der Protokolldatei anzeigen zu können.

    Die Ausgabe zeigt commit-Server-Ereignisprotokolle und andere Protokolle für Batch-Commits.

  • Wenn Sie Protokolleinträge nur für erfolgreiche Batch-Commit-Vorgänge anzeigen wollen, geben Sie den file show /var/log/<filename> Befehl mit der | match committed Pipe-Option aus.

    Die Ausgabe zeigt die Commit-Commit-Auftrags-IDs für den erfolgreichen Commit-Betrieb.

  • Wenn Sie Protokolleinträge nur für fehlgeschlagene Batch-Commit-Vorgänge anzeigen wollen, geben Sie den file show /var/log/<filename> Befehl mit der | match “Error while” Pipe-Option aus.

    Die Ausgabe zeigt Commit-Auftrags-IDs für fehlgeschlagene Commit-Vorgänge.

  • Wenn Sie Protokolleinträge nur für Commit-Serverereignisse anzeigen möchten, geben Sie den file show /var/log/<filename> Befehl mit der | match “commit server” Pipe-Option aus.

    Die Ausgabe zeigt commit-Server-Ereignisprotokolle.

Sichern der zugesagten Konfiguration auf dem Alternatives Boot-Laufwerk

Nachdem Sie die Konfiguration abgeschlossen und zufrieden darüber sind, dass sie erfolgreich ausgeführt wird, sollten Sie den Befehl zum Sichern der neuen Software request system snapshot im Dateisystem /altconfig ausführen. Wenn sie den Befehl nicht aus dem Befehl ausführen, wird die Konfiguration auf dem anderen Boot-Laufwerk nicht mit der Konfiguration des request system snapshot primären Boot-Laufwerks synchronisiert.

Der request system snapshot Befehl backs backs the Root File System zu /altroot und /config/altconfig zu. Root- und Dateisysteme befinden sich auf dem Flash-Laufwerk des Routers, und die Dateisysteme befinden sich auf der Routerfestplatte /config/altroot/altconfig (falls vorhanden).

Nach Ausgabe des Befehls können Sie nicht zur vorherigen Version der Software zurückkehren, da die ausgeführten und die Sicherungskopien der request system snapshot Software identisch sind.