Rollback-Optionen

In der eigenständigen Umgebung wird ein Rollback nicht unterstützt.

Wird in einer Hochverfügbarkeitsumgebung ein Upgrade von der vSRX-Version durchgeführt, so wird ein Rollback nur nach dem erneuten Laden des Betriebssystems für den ersten Knoten und vor dem erneuten Laden des Betriebssystems für den zweiten Knoten unterstützt. Das Gateway befindet sich an diesem Punkt im Status "Upgrade aktiv". Zum Rollback des ersten Knotens auf die vorherige Version sollten die folgenden Schritte ausgeführt werden.

Beachten Sie, dass eine Unterbrechung des Datenverkehrs auftritt, während darauf gewartet wird, dass der sekundäre Knoten eingeschaltet wird und dass der Datenverkehr auf diesen Knoten übertragen wird.

1. SSH auf den Bare-Metal-Server, der den vSRX-Knoten hostet, der zurückgesetzt wird (der aktuelle primäre Knoten). Schalten Sie die vSRX auf dem Knoten aus und deaktivieren Sie den Autostart, um zu verhindern, dass die VM beim Neustart des Hosts gestartet wird.

   Dies würde zu einem "Split Brain Cluster" und höchstwahrscheinlich zu einem Ausfall führen.

   Verwenden Sie die folgenden Befehle:

   virsh shutdown vSRXvM3
   virsh autostart vSRXvM3 --disable
   

   Warten Sie, bis der Knoten vollständig ausgeschaltet ist, bevor Sie fortfahren.

2. SSH auf den Bare-Metal-Server, der den vSRX-Knoten hostet, der nicht zurückgesetzt wurde. Schalten Sie die vSRX ein. Dadurch wird der Primärknoten auf die ursprüngliche vSRX -Version zurückgesetzt. Verwenden Sie die folgenden Befehle:

   # Restore the original qcow2 file.
   cd /var/lib/libvirt/images/vSRXvM3
   cp vSRX_Image.qcow2.backup vSRX_Image.qcow2
   
   # Start the VM
   virsh start vSRXvM3
   
   # Enable autostart
   virsh autostart vSRXvM3
   

3. Führen Sie bei Bedarf die Überprüfung der Bereitschaft zum erneuten Laden des Betriebssystems durch und beheben Sie eventuelle Probleme.

4. Führen Sie einen Reload des Betriebssystems auf dem Host durch, den Sie zurücksetzen möchten, und kehren Sie zur ursprünglichen Version von vSRX zurück. Führen Sie kein OS-Reload auf dem aktuellen primären Knoten aus.

Wenn Sie die oben genannten Schritte befolgt haben, sollte der Knoten, der zurückgesetzt wird, über eine vSRX verfügen, die ausgeschaltet und nicht Teil des Clusters ist. Dies ist der Knoten, auf dem Sie OS Reload ausführen sollten. Dadurch können beide Knoten im Cluster auf derselben vSRX-Version ausgeführt werden, was für einen funktionierenden vSRX-Cluster erforderlich ist.

Sobald das OS Reload abgeschlossen ist, wird der Cluster mit seiner ursprünglichen Konfiguration ausgeführt.