Allgemeine Hinweise zu Upgrades

Bevor Sie ein vSRX-Upgrade durchführen, beachten Sie die folgenden Hinweise:

Beim Aktualisieren Ihrer Version von „ vSRX “ kann es zu Netzwerkstörungen kommen. Zur Vermeidung solcher Fehler führen Sie das Upgrade während eines Wartungsfensters durch, das potenzielle Netzausfallzeiten unterstützt. Die Funktionsübernahme ist erst nach Abschluss des Upgrades wieder verfügbar; dies kann mehrere Stunden in Anspruch nehmen. Bei Hochverfügbarkeits-(HA-) Umgebungen werden die Einstellungen Ihrer vSRX-Konfiguration migriert. Es wird jedoch empfohlen, diese Einstellungen vor dem Upgrade zu exportieren.
Bei einer eigenständigen Umgebung wird die vorherige Konfiguration nicht wiederhergestellt, daher sollten Sie Ihre Konfiguration exportieren und importieren. Weitere Informationen finden Sie in vSRX-Konfiguration importieren und exportieren.
Für ein erfolgreiches erneutes Laden in einer HA-Umgebung mit vSRX muss das Rootkennwort für das bereitgestellte vSRX-Gateway mit dem im vSRX-Portal definierten Rootkennwort übereinstimmen. Darüber hinaus müssen Sie die Root-SSH-Anmeldung bei der privaten vSRX-IP-Adresse aktivieren.

Sie haben das Kennwort in dem Portal definiert, als Sie Ihr Gateway bereitgestellt haben. Möglicherweise stimmt es nicht mit dem aktuellen Gateway-Kennwort überein. Wenn das Kennwort nach der Bereitstellung geändert wurde, stellen Sie mit SSH eine Verbindung zum vSRX-Gateway her und ändern Sie das Rootkennwort so, dass es mit dem Rootkennwort übereinstimmt. Bei einer Kennwortabweichung schlägt die Bereitschaftsprüfung fehl.
Ändern Sie die vSRX-Konfiguration nicht während eines erneuten Ladens des Betriebssystems. Im Upgradeprozess wird zu Beginn des Prozesses ein Snapshot der aktuellen Konfiguration des vSRX-Clusters erfasst. Aus diesem Grund kann das Ändern der vSRX-Konfiguration während des Upgradeprozesses zu einem Fehlschlagen oder zu unvorhersehbaren Ergebnissen führen. Beispiele hierfür sind automatisierte Softwareagenten, die versuchen, einen oder beide vSRX-Knoten zu ändern. Konfigurationsänderungen können den Prozess zum erneuten Laden des Betriebssystems beeinträchtigen. Zudem werden solche Konfigurationsänderungen nicht beibehalten, wenn ein Rollback eingeleitet wird.

Führen Sie vor dem Durchführen eines Upgrades mit erneutem Laden des Betriebssystems den Befehl show chassis cluster status aus. Die Knoten sollten in einem Cluster zusammengefasst werden, wobei ein Knoten als primärer und der andere als sekundärer Knoten ausgewiesen wird. Stellen Sie sicher, dass keine monitor failures aufgetreten sind. Wenn der Cluster vor dem Upgrade nicht in einem einwandfreien Zustand ist, kann das Upgrade fehlschlagen, was zu einem längeren Ausfall des Datenverkehrs führen kann.

Beispiel für einen Cluster in einwandfreiem Zustand:

 root@asloma-19-10g-ha1-vsrx-vSRX-Node0> show chassis cluster status
 Monitor Failure codes:
   CS  Cold Sync monitoring        FL  Fabric Connection monitoring
   GR  GRES monitoring             HW  Hardware monitoring
   IF  Interface monitoring        IP  IP monitoring
   LB  Loopback monitoring         MB  Mbuf monitoring
   NH  Nexthop monitoring          NP  NPC monitoring
   SP  SPU monitoring              SM  Schedule monitoring
   CF  Config Sync monitoring      RE  Relinquish monitoring
   IS  IRQ storm

 Cluster ID: 2
 Node   Priority Status               Preempt Manual   Monitor-failures

 Redundancy group: 0 , Failover count: 1
 node0  100      primary              no      no       None
 node1  1        secondary            no      no       None

 Redundancy group: 1 , Failover count: 1
 node0  100      primary              no      no       None
 node1  1        secondary            no      no       None

 {primary:node0}

Beispiel für einen Cluster in nicht einwandfreiem Zustand mit Überwachungsfehlern:

  root@asloma-tc11-15-10g-pubpriv-ha1-vsrx-vSRX-Node1> show chassis cluster status
  Monitor Failure codes:
    CS  Cold Sync monitoring        FL  Fabric Connection monitoring
    GR  GRES monitoring             HW  Hardware monitoring
    IF  Interface monitoring        IP  IP monitoring
    LB  Loopback monitoring         MB  Mbuf monitoring
    NH  Nexthop monitoring          NP  NPC monitoring
    SP  SPU monitoring              SM  Schedule monitoring
    CF  Config Sync monitoring
  Cluster ID: 3
  Node   Priority Status         Preempt Manual   Monitor-failures

  Redundancy group: 0 , Failover count: 1
  node0  0        lost           n/a     n/a      n/a
  node1  1        primary        no      no       None

  Redundancy group: 1 , Failover count: 1
  node0  0        lost           n/a     n/a      n/a
  node1  0        primary        no      no       CS

  {primary:node1}

Wenn Ihr IBM Cloud-Konto über mehrere vSRX-Gateway-Instanzen im selben Pod verfügt, müssen Sie sicherstellen, dass jeweils nur ein Gateway zur Zeit aktualisiert wird. Die gleichzeitige Durchführung von Upgrades für mehrere vSRX-Komponenten kann zu IP-Kollisionen führen, den Upgradeprozess unterbrechen und möglicherweise zu Fehlern führen.
Wenn Sie Ihren HA-Cluster für die Verwendung von Intrusion Detection Policies (IDP) und einer Signaturdatenbank konfigurieren, wird empfohlen, die Signaturdatenbank nach Abschluss des Upgrades zu aktualisieren. Dies liegt daran, dass die Datenbank möglicherweise nicht auf dem neuesten Stand ist. Informationen zu Online- und Offline-Datenbankaktualisierungen finden Sie unter „Intrusion Detection and Prevention“ unter IBM Cloud
Im Rahmen des Upgrade-Vorgangs werden keine Zertifikate von „ vSRX “, die lokal auf der zu aktualisierenden virtuellen Maschine gespeichert sind ( VM ), gesichert oder wiederhergestellt. Beim Upgrade-Vorgang wird die vorhandene Datei „ VM “ gelöscht und eine neue erstellt, die das Dateisystem „ JunOS “ ersetzt. Beispielsweise muss ein lokales Zertifikat wie IKE_POLICY_CERT vor dem Upgrade gesichert und nach Abschluss des Upgrades manuell wiederhergestellt werden.

set security ike policy MY_VPN_IKE_POLICY certificate local-certificate IKE_POLICY_CERT

Ubuntu Überlegungen zum Hypervisor-Upgrade

Die „ vSRX “ läuft als „ VM “ auf einem „ Ubuntu “-Hypervisor. In der Regel wird dieses Hypervisor-Betriebssystem im Rahmen eines „ vSRX “-Updates neu geladen. Es gibt jedoch Fälle, in denen lediglich der Hypervisor von „ Ubuntu “ gewartet werden muss, beispielsweise durch die Installation von Kernel-Updates, Sicherheitspatches oder Korrekturen für Sicherheitslücken, ohne dass die virtuelle Maschine von „ vSRX “ selbst aktualisiert wird.

In diesen Fällen reicht der Standardbefehl apt update in der Regel aus, wobei jedoch einige wichtige Einschränkungen zu beachten sind, die Sie kennen müssen. Ein Upgrade nur des „ Ubuntu “-Hypervisors gilt allgemein als sicherer Wartungsvorgang und kann in der Regel mit minimalen Beeinträchtigungen für die laufenden „ vSRX “-VMs durchgeführt werden. Die meisten Paketaktualisierungen, einschließlich der Standardbibliotheken und -Dienstprogramme im Benutzerbereich, erfordern keine Unterbrechung des Betriebs der Gast VM.

Systemadministratoren müssen jedoch die in einem Upgrade enthaltenen Pakete sorgfältig prüfen, bevor sie fortfahren. Bestimmte Updates können die Stabilität oder die Konnektivität laufender virtueller Maschinen beeinträchtigen, bis der Hypervisor neu gestartet wird.

Die folgenden Arten von Aktualisierungen erfordern besondere Aufmerksamkeit:

Kernel-Pakete
systemd sowie Neuigkeiten zu „ udev “
libvirt Pakete
Netzwerkbezogene Pakete wie „ nftables “, „Bridges“ oder andere Virtualisierungs-Netzwerkkomponenten
qemu sowie Aktualisierungen der Pakete „ kvm “

In einigen Fällen kann die Aktualisierung von Virtualisierungs- oder Netzwerkpaketen bei aktiv laufenden VMs zu einer Beeinträchtigung der Netzwerk VM, blockierten Schnittstellen oder einem inkonsistenten Status von „ libvirt “ führen, bis der Hypervisor-Knoten neu gestartet wird. Ein Neustart des Hypervisors „ Ubuntu “ stellt in der Regel den normalen Betrieb wieder her.

Beachten Sie bei der Durchführung eines „ apt upgrade “ auf dem Hypervisor die folgenden Empfehlungen:

Überprüfen Sie die ausstehenden Pakete, bevor Sie die Updates installieren.
Planen Sie ein Wartungsfenster ein, wenn der Kernel, der Dienst „ libvirt “ oder Netzwerkkomponenten aktualisiert werden.
Planen Sie bei Bedarf einen Neustart des Hypervisors ein.
Vermeiden Sie nach Möglichkeit, Wartungsarbeiten an mehreren HA-Knoten gleichzeitig durchzuführen.

Beispiel:

apt update
apt list --upgradable
apt upgrade