Dieser Abschnitt enthält Informationen zu den verfügbaren Optionen zum Überwachen, Sichern und Aktualisieren von lokalen Enterprise-Bereitstellungen in einem zweitägigen Betriebsszenario.

Übersicht

Auch wenn das lokale Enterprise-Modell einige einzigartige Vorteile und Funktionen bietet, gibt es Überlegungen, die der Dienstanbieter oder der Kunde, der die Lösung verwaltet, kennen muss. Zu diesen Überlegungen gehören unter anderem:
  • Isolierung der Lösung: Das VMware Cloud Operations-Team hat keine Zugriffsrechte für die Anwendung von Hotfixes und Upgrades.
  • Einschränkungen beim Änderungsmanagement begrenzen die Häufigkeit von Patches und Upgrades.
  • Unangebrachte oder unzureichende Lösungsüberwachung: Diese Situation kann bei Personalmangel für die Verwaltung der Infrastruktur eintreten, was zu funktionellen Problemen, einer langsameren Problemlösung und unzufriedenen Kunden führt.

Dieser Ansatz erfordert immer erheblichen Personal- und Zeitaufwand für sachgemäße Verwaltung, Betrieb und Fehlerbehebung. In der folgenden Tabelle sind einige der Elemente aufgeführt, die bei der lokalen Verwaltung eines Systems berücksichtigt werden müssen.

Tabelle 1. Bei VMware gehostete Zuständigkeit vs. lokale Zuständigkeit
System Beschreibung Bei VMware gehostete Zuständigkeit Lokale Zuständigkeit
SD-WAN-Orchestrierung QoS von Anwendungen und Link-Steuerungsrichtlinie Ja Ja
Sicherheitsrichtlinie für Anwendungen und SD-WAN-Appliances Ja Ja
Bereitstellung und Fehlerbehebung bei SD-WAN-Appliances Ja Ja
Verarbeitung von SD-WAN-Alarmen und -Ereignissen Ja Ja
Link-Leistung und Kapazitätsüberwachung Ja Ja
Hypervisor Überwachung/Alarme Nein Ja
Bereitstellung von Rechen- und Speicherressourcen Nein Ja
Virtuelle Netzwerke und Speicher Nein Ja
Sicherung Nein Ja
Replizierung Nein Ja
Infrastruktur CPU, Arbeitsspeicher, Rechner Nein Ja
Switching und Routing Nein Ja
Überwachungs-und Verwaltungssysteme Nein Ja
Kapazitätsplanung Nein Ja
Softwareaktualisierungen/Anwendung von Patches Nein Ja
Fehlerbehebung bei Anwendungs-/Infrastrukturproblemen Nein Ja
Sicherung und DR für Infrastruktur Sicherungsinfrastruktur Nein Ja
Regelmäßiges Testen des Sicherungssystems Nein Ja
DR-Infrastruktur Nein Ja
DR-Tests Nein Ja

Zweitägige Betriebsszenarien für lokale Unternehmensbereitstellungen werden in den beiden folgenden Abschnitten erläutert (Prozesse am Tag 1 und Prozesse am Tag 2).

Prozesse am Tag 1

Abonnieren der Sicherheitshinweise

In VMware-Sicherheitshinweisen wird die Behebung von Sicherheitslücken dokumentiert, die in VMware-Produkten gemeldet wurden. Bitte abonnieren Sie den nachfolgenden Link, um einen Alarm zu erhalten, wenn eine Maßnahme an einer lokalen Komponente erforderlich ist.

https://www.vmware.com/security/advisories.html

Deaktivieren von cloud-init auf dem SASE Orchestrator

Die Datenquelle enthält zwei Abschnitte: Metadaten und Benutzerdaten. Metadaten enthalten die Instanz-ID und sollten sich während der Lebensdauer der Instanz nicht ändern, während Benutzerdaten eine Konfiguration sind, die beim ersten Booten angewendet wird (für die Instanz-ID in Metadaten).

Nach dem ersten Booten empfiehlt es sich, die cloud-init-Datei zu deaktivieren, um die Bootsequenz von SASE Orchestrator zu beschleunigen. Führen Sie zum Deaktivieren von cloud-init den folgenden Befehl aus:

./opt/vc/bin/cloud_init_ctl -d

Es wird nicht empfohlen, die cloud-init-Datei mit dem Befehl „apt purge cloud-init“ zu „bereinigen“ (dieses Verfahren verursacht keine Probleme im VMware SD-WAN Controller). Beim Bereinigen der cloud-init-Datei werden auch einige wichtige SASE Orchestrator-Tools und -Skripte gelöscht (zum Beispiel die Upgrade- und Sicherungsskripts). Falls der Befehl „purge“ verwendet wurde, können Sie die Dateien mit den folgenden Befehlen wiederherstellen:

  • Wechseln Sie zum Ordner „/opt/vcrepo/pool/main/v/vco-tools“.
  • Installieren Sie das SASE Orchestrator-Toolpaket aus dem Ordner „sudo dpkg -i vco-tools_3.4.1-R341-20200423-GA-69c0f688bf.deb“. Der Paketname für vco-tools kann sich je nach Version ändern. Überprüfen Sie den korrekten Dateinamen mit dem Befehl „ls vco-tools“.

NTP-Zeitzone

Als Zeitzone für SASE Orchestrator und Gateway muss „Etc/UTC“ festgelegt sein. 

vcadmin@vco1-example:~$ cat /etc/timezone 
Etc/UTC 
vcadmin@vco1-example:~$
Wenn die Zeitzone falsch ist, kann sie durch Ausführen der folgenden Befehle korrigiert werden: 
echo "Etc/UTC" | sudo tee /etc/timezone 
sudo dpkg-reconfigure --frontend noninteractive tzdata

NTP-Versatz

Es wird erwartet, dass der NTP-Versatz <= 15 Millisekunden ist. 

vcadmin@vco1-example:~$ sudo ntpq -p 
     remote           refid      st t when poll reach   delay   offset  
jitter 
============================================================================== 
*ntp1-us1.prod.v 74.120.81.219    3 u  474 1024  377   10.171   -1.183   1.033 
ntp1-eu1-old.pr .INIT.          16 u    - 1024    0    0.000    0.000   0.000 
vcadmin@vco1-example:~$
Wenn der Versatz falsch ist, kann er durch Ausführen der folgenden Befehle korrigiert werden: 
sudo service ntp stop 
sudo ntpdate <server> 
sudo service ntp start

SASE Orchestrator-Speicher

Bei der anfänglichen Bereitstellung von SASE Orchestrator werden drei Partitionen erstellt: /, /store, /store2., /store3 (Version 4.0 und höher). Die Partitionen werden mit Standardgrößen erstellt. Bitte befolgen Sie die Anleitung im Abschnitt „Erhöhen des Speicherplatzes im SASE Orchestrator“. Darin erfahren Sie, wie Sie die Standardgrößen dem Design entsprechend ändern können.

Zusätzliche Aufgaben

Der SASE Orchestrator erfordert nach seiner Implementierung eine weitere Konfiguration über die folgenden Schritte:
  1. Konfigurieren von Systemeinstellungen.
  2. Einrichten des anfänglichen Operator-Profils.
  3. Einrichten von Operator-Konten.
  4. Erstellen von SD-WAN Gateways.
  5. Einrichten von SASE Orchestrator.
  6. Erstellen des Kundenkontos/Partnerkontos.

Die Konfigurationen in der obigen Liste liegen außerhalb des Rahmens dieses Dokuments. Sie finden sie in den Bereitstellungshandbüchern in der VMware-Dokumentation. Eine detaillierte Anleitung finden Sie im Handbuch zur Bereitstellung und Überwachung von VMware SASE Orchestrator im Abschnitt „Installieren von SASE Orchestrator“.

Prozesse am Tag 2

SASE Orchestrator-Sicherung

Dieser Abschnitt enthält die verfügbaren Mechanismen, um die SASE Orchestrator-Datenbank regelmäßig zu sichern, damit die Wiederherstellung nach Operatorfehlern oder schwerwiegenden Fehlern der aktiven und der Standby-Orchestrator-Instanz ermöglicht wird.

Beachten Sie, dass die Notfallwiederherstellungsfunktion (Disaster Recovery, DR) die bevorzugte Wiederherstellungsmethode ist. Sie ermöglicht Recovery Point Objective (RPO) von nahezu null, da alle Konfigurationen der aktiven Orchestrato-Instanz sofort repliziert werden. Weitere Informationen zur Notfallwiederherstellungsfunktion finden Sie im nächsten Abschnitt.

Sicherung mit dem eingebetteten Skript

Die Konfiguration von SASE Orchestrator enthält einen integrierten Sicherungsmechanismus. Dieser sorgt für die regelmäßige Sicherung der Konfiguration, um die Wiederherstellung nach Operatorfehlern oder schwerwiegenden Fehlern der aktiven und der Standby-Orchestrator-Instanz zu ermöglichen. Der Mechanismus ist skriptgesteuert und befindet sich in „/opt/vc/scripts/db_backup.sh“.

Das Skript nimmt im Wesentlichen einen Datenbank-Dump der Konfigurationsdaten und -ereignisse vor, schließt jedoch einige der großen Überwachungstabellen während des Datenbank-Dump-Prozesses aus. Sobald das Skript ausgeführt wird, werden Sicherungsdateien in dem lokalen Verzeichnispfad erstellt, der als Eingabe für das obige Skript bereitgestellt wird.

Die Sicherung besteht aus zwei .gzs-Dateien, von denen eine die Datenbankschema-Definition und die andere die eigentlichen Daten ohne Definition enthält. Der Administrator sollte sicherstellen, dass der Speicherort des Sicherungsverzeichnisses über ausreichend Festplattenspeicher für die Sicherung verfügt.

Best Practices

  • Mounten Sie einen Remote-Speicherort und konfigurieren Sie dort das Sicherungsskript. Der Remote-Speicherort sollte über den gleichen Speicherplatz wie /store verfügen, wenn die Flows ebenfalls gesichert werden.
  • Überprüfen Sie vor der Verwendung des Sicherungsskripts den Replizierungsstatus der Notfallwiederherstellung auf der SASE Orchestrator-Replizierungsseite. Sie müssen synchron sein, und es dürfen keine Fehler vorhanden sein.
  • Führen Sie zusätzlich eine MySQL-Abfrage aus und überprüfen Sie die Replizierungsverzögerung.
    • SHOW SLAVE STATUS \G
    • Betrachten Sie in der obigen Abfrage das Feld „seconds_behind_master“. Es sollte idealerweise null sein, doch ein Wert unter 10 ist ebenfalls ausreichend.
    • Für die großen SASE Orchestrator-Instanzen empfiehlt es sich, für die Ausführung des Sicherungsskripts die Standby-Instanz zu verwenden. Zwischen den von den beiden SASE Orchestrator-Instanzen generierten Sicherungen besteht kein Unterschied.
    Zu beachten
    • Das Skript nimmt nur eine Sicherung der Konfiguration vor; Flow-Statistiken oder Ereignisse werden nicht einbezogen.
    • Die Wiederherstellung der Konfiguration erfordert Unterstützung durch das Support-/Engineering-Team.
Häufig gestellte Fragen
  1. Wie lange dauert die Ausführung des Skripts?

    Die Dauer der Sicherung hängt von der Größe der tatsächlichen Kundenkonfiguration ab. Die Überwachungstabellen sind vom Sicherungsvorgang ausgeschlossen. Daher wird erwartet, dass die Sicherung der Konfiguration schnell abgeschlossen wird. Für eine große SASE Orchestrator-Instanz mit Tausenden von SD-WAN Edge und zahlreichen historischen Ereignissen kann es bis zu einer Stunde dauern, während eine kleinere SASE Orchestrator-Instanz innerhalb weniger Minuten fertiggestellt werden sollte.

  2. Wie häufig sollte das Sicherungsskript ausgeführt werden?

    Das Sicherungsintervall richtet sich nach Größe und Dauer der anfänglichen Sicherung. Der Backup-Vorgang sollte während der Nebenzeiten geplant werden, um die Auswirkungen auf SASE Orchestrator-Ressourcen möglichst gering zu halten.

  3. Was geschieht, wenn das Root-Dateisystem nicht genügend Speicherplatz für die Sicherung hat?

    Es wird empfohlen, zum Speichern der Sicherung andere gemountete Volumes zu verwenden. Beachten Sie, dass es keine bewährte Methode ist, das Root-Dateisystem für die Sicherung zu verwenden.

  4. Wie wird überprüft, ob der Sicherungsvorgang erfolgreich abgeschlossen wurde?

    Die Skripte „stdout“ und „stderr“ sollten ausreichend sein, um zu ermitteln, ob der Sicherungsvorgang erfolgreich war oder nicht. Wenn der Skriptaufruf automatisiert wird, kann der Beendigungscode ermitteln, ob der Sicherungsvorgang erfolgreich war oder nicht.

  5. Wie wird die Konfiguration wiederhergestellt?

    Derzeit erfordert VMware, dass der Kunde mit dem VMware Support zusammenarbeitet, um die Konfigurationsdaten wiederherzustellen. Der VMware Support hilft bei der Wiederherstellung der Konfiguration des Kunden. Kunden sollten keine zusätzlichen Konfigurationsänderungen vornehmen, bis die Konfiguration wiederhergestellt ist.

  6. Welche Auswirkungen hat die Ausführung dieses Skripts genau?

    Auch wenn eine Sicherung der Konfiguration nur geringen Einfluss auf die Leistung haben sollte, ist der MySQL-Prozess mit einer erhöhten Ressourcennutzung verbunden. Es wird empfohlen, die Datensicherung außerhalb der Stoßzeiten durchzuführen.

  7. Sind Konfigurationsänderungen während der Ausführung des Sicherungsvorgangs zulässig?

    Konfigurationsänderungen können sicher vorgenommen werden, während der Sicherungsvorgang ausgeführt wird. Um jedoch aktuelle Sicherungen zu gewährleisten, wird empfohlen, dass während der Ausführung einer Sicherung keine Konfigurationsvorgänge durchgeführt werden.

  8. Kann die Konfiguration auf der ursprünglichen SASE Orchestrator-Instanz wiederhergestellt werden oder erfordert sie eine neue SASE Orchestrator-Instanz?

    Ja, die Konfiguration kann und sollte idealerweise auf derselben SASE Orchestrator-Instanz wiederhergestellt werden, wenn sie verfügbar ist. Dadurch wird sichergestellt, dass die Überwachungsdaten verwendet werden, nachdem der Wiederherstellungsvorgang abgeschlossen ist. Wenn die ursprüngliche SASE Orchestrator-Instanz nicht wiederhergestellt werden kann und die Standby-Orchestrator-Instanz ausgefallen ist, kann die Konfiguration in einer neuen SASE Orchestrator-Instanz wiederhergestellt werden. In dieser Instanz gehen die Überwachungsdaten verloren.

  9. Welche Aktionen müssen ausgeführt werden, wenn die Konfiguration auf einer neuen SASE Orchestrator-Instanz wiederhergestellt werden muss?

    Wenden Sie sich an den VMware Support, um die empfohlenen Maßnahmen für die neue SASE Orchestrator-Instanz zu erfahren, da die genaue Vorgehensweise je nach Bereitstellung variiert.

  10. Müssen SD-WAN Edges-Instanzen sich auf dem neu wiederhergestellten SASE Orchestrator erneut registrieren?

    Nein, SD-WAN Edges müssen auf der neuen SASE Orchestrator-Instanz nicht registriert werden, da alle erforderlichen Informationen im Rahmen der Sicherung erhalten bleiben.

SASE Orchestrator-Disaster Recovery

Die Notfallwiederherstellungsfunktion (Disaster Recovery, DR) von SASE Orchestrator verhindert den Verlust gespeicherter Daten und nimmt die SASE Orchestrator-Dienste im Falle eines System- oder Netzwerkausfalls wieder auf. SASE Orchestrator-DR umfasst die Einrichtung eines SASE Orchestrator-Paares im aktiven bzw. Standby-Modus mit Datenreplikation und einem manuell ausgelösten Failover-Mechanismus.
Hinweis: DR ist obligatorisch. Auskünfte über Lizenzen und Preise erhalten Sie beim VMware SD-WAN-Vertriebsteam, das Ihnen gerne weiterhilft.

Status

In der Ansicht eines Operators und der SD-WAN Edges und SD-WAN Gateways verfügt eine SASE Orchestrator-Instanz über einen von vier DR-Zuständen:
  • Eigenständig (Standalone): kein DR konfiguriert
  • Aktiv (DR wurde konfiguriert und fungiert als primärer SASE Orchestrator-Server)
  • Standby (DR wurde konfiguriert und fungiert als inaktiver SASE Orchestrator-Replikatserver)
  • Zombie: DR war früher konfiguriert und aktiv, fungiert aber nicht mehr als aktive oder Standby-Instanz
Tabelle 2. Tabelle 2: Mindestanforderungen für die lokale SASE Orchestrator-Instanz
Phasen SASE Orchestrator A-Rolle SASE Orchestrator B-Rolle
Anfang Eigenständig (Standalone) Eigenständig (Standalone)
Paarbildung Aktiv Standby
Failover Zombie Eigenständig (Standalone)

Best Practices
  • Suchen Sie die SASE Orchestrator-DR-Funktion in einem geografisch getrennten Datencenter.
  • Vergewissern Sie sich vor dem Heraufstufen einer Standby-Orchestrator-Instanz in den aktiven Status, dass der DR-Replizierungsstatus synchronisiert ist. Die zuvor aktive Orchestrator-Instanz kann die Bestandsliste und die Konfiguration nicht mehr verwalten.

  • Wenn die Standby-Instanz mit der ehemals aktiven Orchestrator-Instanz kommunizieren kann, versetzt sie Orchestrator in einen Zombie-Zustand. Im Zombie-Status kommuniziert der SASE Orchestrator an seine Clients (SD-WAN Edges, SD-WAN Gateways, Benutzeroberfläche/API), dass er nicht mehr aktiv ist und dass sie mit der neu heraufgestuften SASE Orchestrator-Instanz kommunizieren müssen.
  • Wenn die heraufgestufte Standby-Instanz nicht mit der ehemals aktiven Orchestrator-Instanz kommunizieren kann, sollte der Operator die ehemals aktive Orchestrator-Instanz nach Möglichkeit manuell herabstufen.
  • Eine detaillierte Anleitung finden Sie in der offiziellen Dokumentation zu SASE Orchestrator auf docs.vmware.com unter „Konfigurieren der Notfallwiederherstellung für SASE Orchestrator (Configure SD-WAN Orchestrator Disaster Recovery)“.

Upgrade-Vorgang für den SASE Orchestrator

Wenden Sie sich für lokale Unternehmensbereitstellungen an das VMware Support-Team, um die nachfolgend beschriebenen Vorbereitungen für das Upgrade von SASE Orchestrator durchzuführen:
  1. Der VMware Support unterstützt Sie beim Upgrade. Tragen Sie die folgenden Informationen zusammen, bevor Sie den VMware Support kontaktieren.
    • Geben Sie die aktuelle Version und die Zielversion von SASE Orchestrator an, z. B.: aktuelle Version (d. h. 3.4.2), Zielversion (3.4.3).
      Hinweis: Die aktuelle Version finden Sie in der oberen rechten Ecke von SASE Orchestrator, indem Sie auf den Link „Hilfe (Help)“ klicken und „Über (About)“ auswählen.
    • Erstellen Sie einen Screenshot vom Replizierungsdashboard des SASE Orchestrator (siehe Abbildung unten).

    • Hypervisortyp und -version (d. h. vSphere 6.7)
    • Befehle vom SASE Orchestrator (Befehle müssen als Root-Befehle ausgeführt werden, z. B. „sudo <Befehl>“ oder „sudo -i“).
      • LVM-Layout
        • pvdisplay -v
        • vgdisplay -v
        • lvdisplay -v
        • df -h
        • cat /etc/fstab
      • Arbeitsspeicherinformationen
        • free -m
        • cat /proc/meminfo
        • ps -ef
        • top -b -n 2
      • CPU-Informationen
        • cat /proc/cpuinfo
      • Kopie von /var/log
        • tar -czf /store/log-`date +%Y%M%S`.tar.gz --newer-mtime="36 hours ago" /var/log
      • Im Standby-Orchestrator:
        • sudo mysql --defaults-extra-file=/etc/mysql/velocloud.cnf velocloud -e 'SHOW SLAVE STATUS \G'
      • Im Aktiven Orchestrator:
        • sudo mysql --defaults-extra-file=/etc/mysql/velocloud.cnf velocloud -e 'SHOW MASTER STATUS \G'
  2. Wenden Sie sich an den VMware SD-WAN-Support unter https://kb.vmware.com/s/article/53907 und geben Sie die oben genannten Informationen an, damit der Support Ihnen beim Upgrade von SASE Orchestrator helfen kann.
  3. Richtlinien für ESXi-Snapshots sind im nächsten Abschnitt angegeben, falls der Kunde nach einem Upgrade eine schnelle Rollback-Lösung wünscht.

ESXi-Snapshot

Die ESXi-Snapshotfunktion kann vor dem Upgrade von SASE Orchestrator verwendet werden, um einen schnellen Rollback auf die vorherige Version von SASE Orchestrator durchzuführen.

Best Practices für ESXi-Snapshots

Bevor Sie den schrittweisen Prozess überprüfen, überprüfen Sie die folgenden Best Practices und Richtlinien bezüglich der Funktion:
  • Standby- und aktive Orchestrator-Instanz müssen vor dem Ausführen oder Wiederherstellen aus dem Snapshot ausgeschaltet werden, um Datenbankinkonsistenzen zu verhindern.
  • Alle Snapshot-bezogenen Aufgaben müssen in der Standby- und aktiven Orchestrator-Instanz ausgeführt werden, um Datenbankinkonsistenzen zu verhindern.
  • Es ist unerlässlich, den Snapshot zu konsolidieren, wenn der Upgrade-Prozess erfolgreich war. Die Snapshot-Datei wächst weiter, wenn sie für einen längeren Zeitraum aufbewahrt wird. Dies kann dazu führen, dass der Speicherplatz am Speicherort des Snapshots knapp und die Systemleistung beeinträchtigt wird.
  • Deaktivieren Sie Alarme in SASE Orchestrator, während Sie Snapshots erstellen, um Fehlalarme zu vermeiden.
  • Verwenden Sie einen einzelnen Snapshot nicht länger als 72 Stunden.
  • Die Verwendung von Snapshots als Sicherungen wird nicht empfohlen.
  • Die Funktionsvalidierung erfolgte mit ESXi 6.7 und der SASE Orchestrator-Version 3.4.4.

Best Practices für VMware-Snapshots finden Sie in folgendem Knowledgebase-Artikel: https://kb.vmware.com/s/article/1025279

Erstellen eines ESXi-Snapshots

Führen Sie die folgenden Anweisungen aus, um einen ESXi-Snapshot zu erstellen.
  1. Deaktivieren Sie die Systemeigenschaften für Alarme, Benachrichtigungen und Überwachung auf der aktiven Orchestrator-Instanz. Die Dauer beträgt etwa 10 Minuten.
    1. Klicken Sie im Operator-Portal auf Systemeigenschaften (System Properties). Ändern Sie die folgenden Systemeigenschaften in „false“.
      • vco.alert.enable
      • vco.notification.enable
      • vco.monitor.enable

  2. Deaktivieren Sie die Systemeigenschaft für Alarme, Benachrichtigungen und Überwachung auf der Standby-Orchestrator-Instanz.
    1. Ändern Sie die folgenden Systemeigenschaften in „false“.
      • vco.alert.enable
      • vco.notification.enable
      • vco.monitor.enable
  3. Schalten Sie die aktive Orchestrator-Instanz aus.

    Gehen Sie zu ESXi/vCenter → Orchestrator VM → Aktionen (Actions) → Einschalten (Power) → Ausschalten (Power Off).

  4. Schalten Sie die Standby Orchestrator-Instanz aus.

    Gehen Sie zu ESXi/vCenter → Orchestrator VM → Aktionen (Actions) → Einschalten (Power) → Ausschalten (Power Off)

  5. Erstellen Sie einen Snapshot der aktiven Orchestrator-Instanz. Vergewissern Sie sich, dass die VM ausgeschaltet ist, bevor Sie diesen Schritt durchführen.

    Gehen Sie zu ESXi → Orchestrator VM → Aktionen (Actions) → Einschalten (Power) → Snapshots → Snapshot erstellen (Take Snapshot).

  6. Erstellen Sie einen Snapshot der Standby-Orchestrator-Instanz. Vergewissern Sie sich, dass die VM ausgeschaltet ist, bevor Sie diesen Schritt durchführen.

    Gehen Sie zu ESXi → Orchestrator VM → Aktionen (Actions) → Einschalten (Power) → Snapshots → Snapshot erstellen (Take Snapshot).

Konsolidierung des ESXi-Snapshots

Verwenden Sie die folgenden Anweisungen, wenn Sie ein erfolgreiches Upgrade haben. Während des Konsolidierungsprozesses wird mit einer um etwa 5 Prozent erhöhten CPU-Nutzung gerechnet. Die Dauer beträgt etwa 10 Minuten.
  1. Nach der Bestätigung eines erfolgreichen Upgrades auf der aktiven und der Standby-Instanz von Orchestrator können Sie die Snapshots konsolidieren. Beginnen Sie dabei mit der aktiven Orchestrator-Instanz.

    Gehen Sie zu ESXi → Orchestrator VM → Aktionen (Actions) → Snapshots → Snapshot-Manager (Snapshot Manager) → Alle löschen (Delete All).

  2. Konsolidieren Sie den Snapshot in der Standby-Orchestrator-Instanz.

    Gehen Sie zu ESXi → Orchestrator VM → Aktionen (Actions) → Snapshots → Snapshot-Manager (Snapshot Manager) → Alle löschen (Delete All).

  3. Aktivieren Sie erneut die Systemeigenschaften für Alarme, Benachrichtigungen und Überwachung auf der aktiven Orchestrator-Instanz und der Standby-Orchestrator-Instanz.
    Klicken Sie im Operator-Portal auf Systemeigenschaften (System Properties). Ändern Sie die folgenden Systemeigenschaften in „true“.
    • vco.alert.enable
    • vco.notification.enable
    • vco.monitor.enable

  4. Wenn die Funktion „Alle Snapshots löschen (Delete All Snapshots)“ bei vSphere 6.x/7.x nicht funktioniert, können Sie stattdessen die Funktion „Snapshots konsolidieren (Consolidate Snapshots)“ versuchen. Weitere Informationen finden Sie in der Produktdokumentation zu vSphere im Abschnitt „Konsolidieren von Snapshots“.

Wiederherstellen aus dem ESXi Snapshot

Führen Sie die folgenden Anweisungen aus, wenn Sie einen Rollback auf die vorherige Version von SASE Orchestrator durchführen möchten. Die Dauer beträgt etwa 10 Minuten.
  1. Schalten Sie die aktive Orchestrator-Instanz aus.

    Gehen Sie zu ESXi/vCenter → Orchestrator VM → Aktionen (Actions) → Einschalten (Power) → Ausschalten (Power Off).

  2. Schalten Sie die Standby Orchestrator-Instanz aus.

    Gehen Sie zu ESXi/vCenter → Orchestrator VM → Aktionen (Actions) → Einschalten (Power) → Ausschalten (Power Off).

  3. Stellen Sie den Snapshot der aktiven Orchestrator-Instanz wieder her.

    Gehen Sie zu ESXi → Orchestrator VM → Aktionen (Actions) → Einschalten (Power) → Snapshots → Snapshots verwalten (Manage Snapshots).

    Wählen Sie den Snapshot aus, auf den Sie die VM wiederherstellen möchten → Wiederherstellen (Revert to), siehe Abbildung unten.

  4. Stellen Sie den Snapshot der Standby-Orchestrator-Instanz wieder her.

    Gehen Sie zu ESXi → Orchestrator VM → Aktionen (Actions) → Einschalten (Power) → Snapshots → Snapshots verwalten (Manage Snapshots).

    Wählen Sie den Snapshot aus, auf den Sie die VM wiederherstellen möchten → Wiederherstellen (Revert to).

  5. Aktivieren Sie erneut die Systemeigenschaften für Alarme, Benachrichtigungen und Überwachung auf der aktiven Orchestrator-Instanz und der Standby-Orchestrator-Instanz. Klicken Sie im Operator-Portal auf Systemeigenschaften (System Properties). Ändern Sie die folgenden Systemeigenschaften in „true“.
    • vco.alert.enable
    • vco.notification.enable
    • vco.monitor.enable

Kleineres Upgrade der Controller-Software (Beispiel: von 3.3.2 P3 auf 3.4.4)

Die Datei für das Software-Upgrade enthält Gateway- und Systemupdates. Führen Sie „apt-get update && apt-get –y upgrade“ NICHT aus.

Bevor Sie mit dem Upgrade des VMware SD-WAN Controllers fortfahren, stellen Sie sicher, dass der SASE Orchestrator zuvor mindestens auf die gleiche Version aktualisiert wurde.

So führen Sie ein Upgrade für einen SD-WAN Controller durch:
  1. Laden Sie das Update-Paket für den SD-WAN Controller herunter.
  2. Laden Sie das Image in den Speicher des SD-WAN Controllers hoch (z. B. mit dem SCP-Befehl). Kopieren Sie das Image in den folgenden Speicherort im System: /var/lib/velocloud/software_update/vcg_update.tar.
  3. Stellen Sie eine Verbindung zur SD-WAN Controller-Konsole her und führen Sie den folgenden Befehl aus:

    sudo /opt/vc/bin/vcg_software_update

Beispiel: 
root@VCG:/var/lib/velocloud/software_update# wget -O 'vcg_update.tar' <image location> 
Resolving ftpsite.vmware.com (ftpsite.vmware.com)...  
Connecting to ftpsite.vmware.com (ftpsite.vmware.com)| <ip address>|:443... connected. 
HTTP request sent, awaiting response... 200 OK 
Length: unspecified [application/octet-stream] 
Saving to: 'vcg_update.tar' 
    [                                  <=>  ] 325,939,200 3.81MB/s   in 82s 
2020-05-23 21:59:27 (3.79 MB/s) - ‘vcg_update.tar’ saved [325939200] 
root@VCG:/var/lib/velocloud/software_update# sudo /opt/vc/bin/vcg_software_update 
=========== VCG upgrade: Sat May 23 22:08:15 UTC 2020 
Upgrading gateway version 3.4.0-106-R340-20200218-GA-c57f8316dd to 3.4.1-39-R341-20200428-GA-44354-44451-596496a88a 
Ign file: trusty InRelease 
Ign file: trusty Release.gpg 
Get: 1 file: trusty Release [2,668 B] 
Ign file: trusty/main Translation-en_US 
Ign file: trusty/main Translation-en 
(...) 
Writing extended state information... 
Reading package lists... 
Building dependency tree... 
Reading state information... 
Reading extended state information... 
Initializing package states... 
update-initramfs: Generating /boot/initrd.img-3.13.0-176-generic 
Reboot is required. Reboot? (y/n) [y]:

Größeres Upgrade der Controller-Software (z. B. von 3.3.2 oder 3.4 auf 4.0)

In Version 4.0 sind mehrere Änderungen enthalten:
  • Ein neues Systemfestplattenlayout, das auf LVM basiert, um mehr Flexibilität bei der Volume-Verwaltung zu ermöglichen
  • Eine neue Kernel-Version
  • Neue und aktualisierte Basis-Betriebssystempakete
  • Verbesserte Sicherheitshärtung basierend auf Benchmarks des Center for Internet Security

Aufgrund dieser Änderungen funktioniert das standardmäßige Upgrade-Verfahren, das das Upgrade-Skript verwendet, nicht. Ein bestimmtes Upgrade-Verfahren ist erforderlich. Informationen dazu finden Sie im Produkthandbuch unten. Bei diesem Verfahren wird die Gateway-VM der Version 3.3.2 oder 3.4 durch die neue Gateway-VM der Version 4.0 ersetzt. Weitere Informationen finden Sie im folgenden Dokument: Upgrade und Migration des VMware SD-WAN-Partner-Gateways von Version 3.3.2 oder 3.4 auf 4.0.

Dieses Upgrade-Verfahren erfordert die Konfiguration der Systemeigenschaften von SASE Orchestrator, die nur von SASE Orchestrator-Operator-Konten ausgeführt werden können. Erstellen Sie ein Supportticket beim VMware Support-Team, um die Änderung der Systemeigenschaften anzufordern.

Überwachung

Zu den Aufgaben des Kunden bei lokalen Bereitstellungen im Unternehmen gehört die Überwachung der Lösung. Durch die Überwachung gewinnt der Kunde die nötige Transparenz, um möglichen Problemen einen Schritt voraus zu sein.
  • Überwachung des SD-WAN Controllers

    Sie können die Status- und Nutzungsdaten von Controllern überwachen. Diese sind im Operator-Portal verfügbar.

    Die Vorgehensweise ist wie folgt:

  1. Klicken Sie im Operator-Portal auf Gateways.
  2. Auf der Seite Gateways wird die Liste der verfügbaren Controller angezeigt.
  3. Klicken Sie auf den Link zu einem Gateway. Die Details des ausgewählten Controllers werden angezeigt.
  4. Klicken Sie auf die Registerkarte „Überwachen (Monitor)“, um die Nutzungsdaten des ausgewählten Controllers anzuzeigen.

Auf der Registerkarte „Überwachen (Monitor)“ des ausgewählten Controllers werden die folgenden Details angezeigt (siehe Abbildung unten).

Sie können einen bestimmten Zeitraum auswählen, um die Details des Controllers für den ausgewählten Zeitraum oben auf der Seite anzuzeigen.

Die Seite enthält eine grafische Darstellung der Nutzungsdaten der folgenden Parameter für den ausgewählten Zeitraum zusammen mit den Mindest-, Höchst- und Durchschnittswerten.

Tabelle 3. Nutzungsdetails
Nutzung Beschreibung
CPU-Prozentsatz (CPU Percentage) Nutzung der CPU in Prozent
Arbeitsspeichernutzung (Memory Usage) Nutzung des Arbeitsspeichers in Prozent
Flow-Anzahl (Flow Counts) Anzahl des Datenverkehrsflusses
Handoff Queue Drops (Handoff Queue Drops) Anzahl der Pakete, die aufgrund der in die Warteschlange gestellten Übergabe verworfen werden.
Tunnelanzahl (Tunnel Count ) Anzahl der Tunnelsitzungen
  • Zu überwachende Werte für den SD-WAN Gateway-Controller

    Die folgende Liste enthält die zu überwachenden Werte und deren Schwellenwerte. Die nachstehende Liste dient lediglich als Ausgangspunkt und erhebt keinen Anspruch auf Vollständigkeit. Einige Bereitstellungen können die Bewertung zusätzlicher Komponenten wie Flows, Paketverlust usw. erfordern.

    Wenn ein Warnschwellenwert erreicht wird, empfiehlt es sich, die aktuelle Geräteskalenkonfiguration zu überprüfen und bei Bedarf weitere Ressourcen hinzuzufügen. Wenn ein kritischer Alarm ausgelöst wird, ist es von entscheidender Bedeutung, den VMware Support zu kontaktieren. Der Support hilft Ihnen dann bei der Überprüfung der Lösung und bietet weiteren Rat.

    Tabelle 4. Empfohlene Werte zur Überwachung
    Servicekontrolle Beschreibung der Servicekontrolle Warnschwelle Kritischer Schwellenwert
    CPU-Last Überprüfen Sie die Systemlast. 60 80
    Arbeitsspeicher Prüft den Arbeitsspeicherauslastungspuffer, den Cache und den verwendeten Arbeitsspeicher. 70 80
    Tunnel Anzahl der Tunnel von verbundenen SD-WAN Edges. 60 % der maximalen Skalierung 80 % der maximalen Skalierung

    Hinweis: Ein plötzlicher Verlust aller Tunnel oder eine abnormal geringe Menge sollten ebenfalls Anlass zur Sorge geben.

    Löschung bei Übergabe Da der Datenverkehr durch ein Gateway sehr rege ist, ist gelegentlich damit zu rechnen, dass Pakete gelöscht werden. Das stetige Löschen von Paketen in bestimmten Warteschlangen deutet jedoch auf ein Kapazitätsproblem hin.
    Festplattenspeicher Aktuelle Festplattennutzung 40 % frei 20 % frei
    Controller-NTP Prüfung auf Zeitversatz Versatz von 5 Sekunden Versatz von 10 Sekunden
  • SASE Orchestrator-Integration mit Überwachungsstacks

SASE Orchestrator wird mit einem integrierten Stack für die Überwachung von Systemmetriken geliefert. Dieser kann an einen externen Metrik-Collector und eine Zeitreihendatenbank angehängt werden. Mit dem Überwachungsstack können Sie schnell den Zustand und die Systemlast für den SASE Orchestrator überprüfen.

Richten Sie vor dem ersten Start eine zeitbasierte Datenbank und ein Dashboard bzw. einen Alarmagent ein. Anschließend können Sie Telegraf im SASE Orchestrator aktivieren.
    • Führen Sie den folgenden Befehl auf dem Orchestrator aus, um den Überwachungsstack zu aktivieren:

      sudo /opt/vc/scripts/vco_observability_manager.sh enable

    • Führen Sie den folgenden Befehl aus, um den Status des Überwachungsstacks zu überprüfen:

      sudo /opt/vc/scripts/vco_observability_manager.sh status

    • Führen Sie den folgenden Befehl aus, um den Überwachungsstack zu deaktivieren: 
      sudo /opt/vc/scripts/vco_observability_manager.sh disable

  • Der Metrik-Collector
    Als Collector für Systemmetriken von SASE Orchestrator wird Telegraf verwendet. Dieser enthält zahlreiche Plug-Ins zum Erfassen diverser Systemmetriken. Die folgenden Metriken sind standardmäßig aktiviert.
    Tabelle 5. Metrik-Collector
    Name der Metrik Beschreibung Unterstützt in Version
    inputs.cpu Metriken zur CPU-Nutzung. 3.4/4.0
    inputs.mem Metriken zur Arbeitsspeichernutzung. 3.4/4.0
    inputs.net Metriken zu Netzwerkschnittstellen. 4.0
    inputs.system Metriken zur Systemlast und Betriebszeit. 4.0
    inputs.processes Anzahl der Prozesse, nach Status gruppiert. 4.0
    inputs.disk Metriken zur Festplattennutzung. 4.0
    inputs.diskio Metriken zu Festplatten-E/As nach Gerät. 4.0
    inputs.procstat CPU und Arbeitsspeichernutzung für spezifische Prozesse. 4.0
    inputs.nginx Die grundlegenden Statusinformationen von Nginx (ngx_http_stub_status_module). 4.0
    inputs.mysql Statistikdaten vom MySQL-Server. 3.4/4.0
    inputs.redis Metriken von einem oder mehreren redis-Servern. 3.4/4.0
    inputs.statds API- und Systemmetriken. 3.4/4.0 (zusätzliche Metriken sind in 4.0 enthalten)
    inputs.filecount Die Menge und die Gesamtgröße der Dateien in den angegebenen Verzeichnissen. 4.0
    inputs.ntpq Standardmäßige NTP-Abfragemetriken (erfordert die ausführbare Datei ntpq.exe). 4.0
    Inputs.x509_cert Metriken aus einem SSL-Zertifikat. 4.0

    Um weitere Metriken zu aktivieren oder einige aktivierte Metriken zu deaktivieren, bearbeiten Sie die Telegraf-Konfigurationsdatei im SASE Orchestrator wie folgt:

    sudo vi /etc/telegraf/telegraf.d/system_metrics_input.conf

    sudo systemctl restart telegraf

  • Die Datenbank der Zeitreihen

    Eine Zeitreihendatenbank kann zum Speichern der von Telegraf erfassten Systemmetriken dienen. Eine Zeitreihendatenbank (TSDB) ist eine Datenbank, die für Zeitreihendaten optimiert ist.

  • Dashboard und Alarmagent

    Mit dem Dashboard und dem Alarmagent können Sie die in der TSDB gespeicherten Daten abfragen, visualisieren, untersuchen und Alarme damit ausgeben. Das Image ist ein Beispiel für ein Dashboard mit Telegraf (einer TSDB und einer Dashboard-Engine), das zur Überwachung der Lösung erstellt werden kann.

  • Einrichtung der Zeitreihendatenbank

    Befolgen Sie die Anweisungen unten, um die Zeitreihendatenbank einzurichten.

  1. Fügen Sie den Eintrag „iptables“ hinzu, um externen Überwachungssystemen den Zugriff auf den Telegraf-Port zu ermöglichen. Die Quell-IP-Adresse muss aus Sicherheitsgründen angegeben werden.
    1. Beispiel: Die IP-Adresse des externen Überwachungssystems lautet 191.168.0.200. Fügen Sie „-A INPUT -p tcp -m tcp --source 191.168.0.200 --dport 9273 -m comment --comment "allow telegraf port" -j ACCEPT“ zu „/etc/iptables/rules.v4“ hinzu.

    2. Starten Sie iptables neu.

      sudo service iptables-persistent restart (Orchestrator 3.4.x)

      sudo systemctl restart netfilter-persistent (Orchestrator 4.x)

    3. Stellen Sie sicher, dass der Eintrag „iptables“ hinzugefügt wird.
  2. Fügen Sie der Telegraf-Konfiguration die Details der Zeitreihendatenbank hinzu. Erstellen Sie eine Ausgabekonfigurationsdatei. Beispiel für Prometheus:

    /etc/telegraf/telegraf.d/prometheus_out.conf

  • Zu überwachende Werte für den SASE Orchestrator

    Die folgende Liste enthält die zu überwachenden Werte und deren Schwellenwerte. Die nachstehende Liste dient lediglich als Ausgangspunkt und erhebt keinen Anspruch auf Vollständigkeit. Einige Bereitstellungen können die Bewertung zusätzlicher Komponenten wie Datenbanktransaktionen, automatischer Sicherungen usw. erfordern.

    Wenn ein Warnschwellenwert erreicht wird, empfiehlt es sich, die aktuelle Geräteskalenkonfiguration zu überprüfen und bei Bedarf weitere Ressourcen hinzuzufügen. Wenn ein kritischer Alarm ausgelöst wird, ist es von entscheidender Bedeutung, den VMware Support zu kontaktieren. Der Support hilft Ihnen dann bei der Überprüfung der Lösung und bietet weiteren Rat.
    Tabelle 6. Überwachen von Werten und Schwellenwerten
    Servicekontrolle Beschreibung der Servicekontrolle Warnschwelle Kritischer Schwellenwert
    CPU-Last Überprüfen der Systemlast – Telegraf-Eingabe-Plug-In: inputs.cpu. 60 70
    Arbeitsspeicher Prüft den Puffer für die Arbeitsspeicherauslastung, den Cache und den verwendeten Arbeitsspeicher – Telegraf-Eingabe-Plug-In: inputs.memory. 70 80
    Festplattennutzung Festplattennutzung in den verschiedenen Orchestrator-Partitionen, /, /store, /store2 und /store3 (ab Version 4.0) – Telegraf-Eingabe-Plug-In: inputs.disk (ab Version 4.0). 40 % frei 20 % frei
    MySQL Server Überprüft MySQL-Verbindungen –Telegraf-Eingabe-Plug-In: inputs.mysql. Über 80 % der in mysql.conf (/etc/mysql/my.cnf) definierten maximalen Verbindungen
    SASE Orchestrator-Zeit Überprüft auf Zeitversatz –Telegraf-Eingabe-Plug-In: inputs.ntpq (ab Version 4.0). Versatz von 5 Sekunden Versatz von 10 Sekunden
    SASE Orchestrator-SSL-Zertifikat Überprüft den Ablauf des Zertifikats – Telegraf-Eingabe-Plug-In: inputs.x509_cert (ab Version 4.0). 60 Tage 30 Tage
    SASE Orchestrator-Internet (nicht anwendbar für reine MPLS-Topologien) Überprüft auf Internetzugriff. Antwortzeit > 5 Sekunden Antwortzeit > 10 Sekunden
    SASE Orchestrator-HTTP Vergewissern Sie sich, dass HTTP auf dem localhost antwortet. Der localhost antwortet nicht.
    Gesamtzahl der SASE Orchestrator-Zertifikate Prüfsumme – Beispiel mysql-Abfrage:

    SELECT count(id) FROM VELOCLOUD_EDGE_CERTIFICATE WHERE validFrom <= NOW() AND validTo >=NOW()', 'SELECT count(id) FROM VELOCLOUD_GATEWAY_CERTIFICATE WHERE validFrom <= NOW() AND validTo >=NOW()

    		CRL Wenn die Summe der Zertifikate 5000 überschreitet
    DR-Replizierungsstatus Stellen Sie sicher, dass die Standby-Orchestrator-Instanz auf dem neuesten Stand ist. Überprüfen Sie, dass die DR-Instanz von SASE Orchestrator nicht mehr als 1000 Sekunden hinter der aktiven Orchestrator-Instanz liegt.

    Seconds_Behind_Master: aus mysql-Befehl: show slave STATUS\G;

    Delta für DR-Replizierung von SD-WAN Edge-Gateway Stellen Sie sicher, dass SD-WAN Edges und SD-WAN Gateways mit der DR-Instanz von SASE Orchestrator kommunizieren können.

    Wenn die Werte der aktiven und der Standby-Instanz von Orchestrator nicht übereinstimmen, kann dies an unterschiedlichen Zeitzonen von SD-WAN Edges und SD-WAN Gateways liegen.

    		 Die gleiche Anzahl von SD-WAN Edges, die mit der aktiven Orchestrator-Instanz kommunizieren, sollte auch die Standby-Orchestrator-Instanz erreichen können. Dieser Wert kann auf der Registerkarte „Replizierung (Replication)“ oder über die API geprüft werden.

Best Practices für API

Der SASE Orchestrator unterstützt die Verwaltungsebene (Management Plane) in der VMware SD-WAN-Lösung. Er bietet zahlreiche Konfigurations-, Überwachungs- und Fehlerbehebungsfunktionen für Dienstanbieter und Unternehmen. Der Haupt-Webdienst, mit dem Benutzer zur Ausführung dieser Funktionen interagieren, wird als SASE Orchestrator-Portal bezeichnet.
  • Das SASE Orchestrator-Portal

    Das SASE Orchestrator-Portal ermöglicht Netzwerkadministratoren (oder Skripts und Anwendungen, die in deren Namen handeln), die Netzwerk- und Gerätekonfiguration zu verwalten und den aktuellen oder historischen Netzwerk- und Gerätestatus abzufragen. API-Clients können über eine JSON-RPC-Schnittstelle oder eine REST-ähnliche Schnittstelle mit dem Portal interagieren. Es besteht die Möglichkeit, alle in diesem Dokument beschriebenen Methoden über beide Schnittstellen aufzurufen. Es gibt keine Portal-Funktionalität, für die der Zugriff ausschließlich auf JSON-RPC-Clients oder REST-ähnliche Clients beschränkt ist.

    Beide Schnittstellen akzeptieren ausschließlich HTTP POST-Anfragen. Beide erwarten auch, dass Anforderungstexte, wenn vorhanden, JSON-formatiert sind – im Einklang mit RFC 2616 werden Clients außerdem wahrscheinlich formell bestätigen, wo dies der Fall ist, indem sie den Abfrage-Header „Content Type“ verwenden, z. B. Content-Type: application/json.

    Weitere Informationen zur VMware SD-WAN-API finden Sie hier:

    https://code.vmware.com/apis/1000/velocloud-sdwan-vco-api

  • Best Practices für Unternehmen und Dienstanbieter bei Verwendung von APIs
    Einige der Best Practices bei der Verwendung von APIs sind:
    • Wo immer möglich, sollten aggregierte API-Aufrufe unternehmensspezifischen vorgezogen werden. Beispielsweise kann ein einzelner Aufruf von monitoring/getAggregateEdgeLinkMetrics verwendet werden, um Transportstatistiken über alle SD-WAN Edges gleichzeitig abzurufen.
    • VMware verlangt, dass Clients die Anzahl der API-Aufrufe während der Ausführung zu einem bestimmten Zeitpunkt auf eine geringe Anzahl (d. h. <2–4) begrenzen. Wenn ein Benutzer der Ansicht ist, dass es einen zwingenden Grund für die parallele Ausführung von API-Aufrufen gibt, verlangt VMware, dass mit dem VMware Support alternative Lösungen besprochen werden.
    • Wir raten normalerweise davon ab, die API häufiger als alle 10 Minuten nach Statistikdaten abzufragen. Alle 5 Minuten kommen neue Statistikdaten im SASE Orchestrator an. Aufgrund von Jitter in den Berichten/der Verarbeitung können Clients, die alle 5 Minuten abfragen, „falsch-positive“ Fälle beobachten, in denen die Statistiken nicht den Ergebnissen von API-Aufrufen entsprechen. Optimale Ergebnisse können Benutzer tendenziell bei Abfrageintervallen von mindestens 10 Minuten erzielen.
    • Fragen Sie dieselben Informationen nicht zweimal ab.
    • Verwenden Sie den Ruhezustand zwischen APIs.
    • Führen Sie für komplexe Softwareautomatisierungen Ihre Skripte aus und bewerten Sie die Auswirkungen auf die CPU/den Arbeitsspeicher. Passen Sie sie dann je nach Bedarf an.

SASE Orchestrator-Syslog-Konfiguration

Die Syslog-Funktion von VMware SASE Orchestrator kann unabhängig für die folgenden Orchestrator-Prozesse konfiguriert werden: Portal, Upload und Backend.

Eine kurze Beschreibung der einzelnen Prozesse ist unten aufgeführt:
  • Portal: Der Portal-Prozess läuft als interner HTTP-Server im Anschluss an NGINX. Der Portal-Dienst verarbeitet eingehende API-Anfragen, entweder von der SASE Orchestrator-Webschnittstelle oder von einem HTTP/SDK-Client, hauptsächlich synchron. Mit diesen Anforderungen können authentifizierte Benutzer die verschiedenen vom SASE Orchestrator bereitgestellten Dienste konfigurieren, überwachen und verwalten.

    Dieses Protokoll ist sehr nützlich für AAA-Aktivitäten, da es alle Aktionen von Benutzern im SASE Orchestrator enthält.

    Protokolldateien: /var/log/portal/velocloud.log (protokolliert alle Info-, Warn- und Fehlerprotokolle)

  • Upload: Der Upload-Prozess läuft als interner HTTP-Server im Anschluss an NGINX. Der Upload-Dienst verarbeitet eingehende Anfragen von SD-WAN Edges und SD-WAN Gateways entweder synchron oder asynchron. Diese Anforderungen bestehen in erster Linie aus Aktivierungen, Taktsignalen, Flow-Statistiken, Link-Statistiken und Routing-Informationen, die von SD-WAN Edges und SD-WAN Gateways gesendet werden.

    Protokolldateien: /var/log/upload/velocloud.log (protokolliert alle Info-, Warn- und Fehlerprotokolle)

  • Backend: JobRunner, der hauptsächlich geplante oder in die Warteschlange gestellte Aufträge ausführt. Geplante Aufträge umfassen Bereinigungs-, Rollup- oder Statusaktivitäten. In die Warteschlange gestellte Aufträge umfassen die Verarbeitung von Link- und Flow-Statistiken.

    Protokolldateien: /var/log/backend/velocloud.log (protokolliert alle Info-, Warn- und Fehlerprotokolle)

Konfiguration von Orchestrator-Syslog
  1. Navigieren Sie im SASE Orchestrator zu „Systemeigenschaften (System Properties)“, log.syslog.<server> (z. B. log.syslog.portal). Gehen Sie in der Suchleiste zu SASE Orchestrator → Systemeigenschaften (System Properties) → geben Sie „log.syslog“ ein.
  2. Ändern Sie den Wert „enable:false” für mindestens einen der Server in „true“. Ändern Sie Host-IP und Port entsprechend Ihrer Implementierung.

Erhöhen des Speichers im SASE Orchestrator

Detaillierte Anweisungen zur Erhöhung des Speicherplatzes im SASE Orchestrator finden Sie in der Dokumentation zu SASE Orchestrator

auf https://docs.vmware.com/ unter „Installieren von SASE Orchestrator“ und „Erweitern der Festplattengröße (VMware)“.

  • Best Practices:
    • Stellen Sie sicher, dass dieselbe LVM-Verteilung auf den Standby-Orchestrator angewendet wird.
    • Es wird davon abgeraten, die Größe von Volumes zu reduzieren, nachdem sie vergrößert wurden. Verwenden Sie stattdessen Thin Provisioning.
    • In 3.4 kann bei der Vergrößerung der Festplattengröße die folgende Prozent-/Wertverteilung verwendet werden:
      • Volume „/“: Dieses Volume wird für das Betriebssystem verwendet. Orchestrator-Instanzen für die Produktion sind in der Regel auf 140 GB eingestellt und haben eine Nutzung von 40 % bis 60 %.
      • /store und /store2: Der Anteil der Orchestrator-Instanzen für die Produktion liegt bei fast 85 % für /store und 15 % für /store2.
    • Die folgenden Richtwerte in der Tabelle unten sollten ab Version 4.x verwendet werden.
      Instanzgröße /store /store2 /store3 /var/log
      Klein (5000 SD-WAN Edges) 2 TB 500GB 8TB 15GB
      Mittel (10000 SD-WAN Edges) 2 TB 500GB 12TB 20GB
      Groß (15000 SD-WAN Edges) 2 TB 500GB 16 TB 25 GB

Verwalten von Zertifikaten im SASE Orchestrator

SASE Orchestrator verwendet einen integrierten Zertifikatserver, um den gesamten PKI-Lebenszyklus aller SD-WAN Edges und SD-WAN Controller zu verwalten. X.509-Zertifikate werden an die Geräte im Netzwerk ausgestellt.

Ausführliche Anweisungen zur Konfiguration der Zertifizierungsstelle finden Sie in der offiziellen Dokumentation zu VMware SD-WAN Operator auf https://docs.vmware.com/de/VMware-SD-WAN/index.html unter „Installieren von SASE Orchestrator“ und „Installieren eines SSL-Zertifikats“.

Von der Zertifizierungsstelle ausgestellte Zertifikate werden nur für die folgenden Authentifizierungen verwendet:
  • TLS 1.2-Tunnel der Management Plane zwischen SASE Orchestrator und SD-WAN Edge/SD-WAN Controller.
  • IKEv2/IPsec-Tunnel der Steuerungsebene (Control Plane) und der Datenebene (Data Plane) zwischen SD-WAN Edges und zwischen SD-WAN Edge und SD-WAN Controller.

Liste widerrufener Zertifikate

Auf Controllern mit aktiviertem PKI werden die widerrufenen Zertifikate in einer Zertifikatswiderrufsliste (Certificate Revocation List, CRL) gespeichert. Wenn diese Liste zu lang wird (in der Regel aufgrund eines Problems mit der Zertifizierungsstelle des Orchestrators), wird die Leistung des Controllers beeinträchtigt. Die CRL sollte weniger als 4.000 Einträge umfassen. 
vcadmin@vcg1-example:~$ openssl crl -in /etc/vc-public/vco-ca-crl.pem -text | grep 'Serial Number' | wc -l  
14 
vcadmin@vcg1-example:~

Interaktion mit dem Support

Unsere Kundensupport-Organisation bietet VMware SD-WAN-Kunden rund um die Uhr technischen Support von Weltrang und personalisierte Beratung.

Dieser Abschnitt enthält einige Richtlinien für die Interaktion mit dem VMware Support-Team.
  • Diagnosepakete

    Bei der Untersuchung eines Vorfalls kann ein Diagnosepaket aus SASE Orchestrator und SD-WAN Controller erstellt werden. Die resultierende Datei hilft dem VMware Support-Team bei der weiteren Analyse der Ereignisse rund um ein Problem.

  • Teilen des Zugriffs mit dem Support

    Gelegentlich kann es vorkommen, dass Sie Unterstützung durch die VMware Support-Mitarbeiter für SASE Orchestrator und SD-WAN Controller benötigen.

    Gängige Möglichkeiten zum Gewähren des Zugriffs sind:
    • Remote-Sitzungen mit Support: Der Kunde würde entweder dem SSH-Jump-Server eine Fernsteuerung gewähren oder die Anweisungen des Support-Mitarbeiters befolgen.
    • Erstellen eines Kontos für das Support-Team im SASE Orchestrator. Dies hilft dem Support-Team, Protokolle ohne Kundeninteraktion zu erfassen.
    • Über den Bastionhost: SSH-Berechtigungen und ‑Schlüssel können so konfiguriert werden, dass die Support-Techniker über einen Bastionhost auf den lokalen SASE Orchestrator und SD-WAN Controller zugreifen können.

    Wenn Sie den VMware SD-WAN-Support kontaktieren, um die Behebung eines Problems zu unterstützen, geben Sie die in der Tabelle unten beschriebenen Daten mit an.

    Weitere Informationen finden Sie unter dem folgenden Link: https://kb.vmware.com/s/article/53907

Erforderlich Vorgeschlagen
Fallnummer des Partners Beginn/Ende des Problems
E-Mail/Telefonnummer für Rückantwort an Partner SRC/DST-IP des betroffenen Flow
SASE Orchestrator-URL SRC/DST-Port des betroffenen Flow
Kundenname in SASE Orchestrator Flow-Pfad (E2E, E2GW, Direkt)
Auswirkung auf den Kunden (Hoch/Mittel/Niedrig) Name(n) des/der SD-WAN Gateway(s)
SD-WAN Edge-Name(n) Link zu PCAP in SASE Orchestrator
Link zum Diagnosepaket in SASE Orchestrator
Kurze Problembeschreibung
Analyse und angeforderte Unterstützung