In diesem Thema wird die empfohlene Vorgehensweise zur Aktualisierung einer bestehenden, auf der Steuerungsebene basierenden Omnissa Access-Bereitstellung beschrieben. Es behandelt die Aktualisierung von Betriebssystempaketen, des Asset-Pakets der Steuerungsebene, der Access-Dienste und der Bootstrap-VM.
Wichtig: Diese Anweisungen zur Aktualisierung gelten nicht für das Upgrade von Version 2412 oder früheren Versionen.
Voraussetzungen
- Führen Sie alle Befehle von der Bootstrap-VM aus, sofern nicht anders angegeben.
- Die vorhandene Bereitstellung muss fehlerfrei sein. Führen Sie
wso healthcheckundwso access check-service-readinessaus, um den Systemzustand zu überprüfen, bevor Sie beginnen. - Das Offline-Asset-Paket für die Zielversion wurde heruntergeladen und ist in der Bootstrap-VM verfügbar.
- Das RPM für die Betriebssystemsicherheit wurde heruntergeladen und steht in der Bootstrap-VM zur Verfügung, sofern dieses Update Betriebssystempaket-Updates enthält.
Update-Workflow
Ein Update besteht aus den folgenden Phasen:
- Update-Phase 1 – Herunterladen und Konfigurieren des lokalen Repositorys für Betriebssystem-Updates (nur wenn Updates für Betriebssystempakete erforderlich sind).
- Update-Phase 2: Herunterladen und Konfigurieren des neuen Asset-Pakets für die Steuerungsebene.
- Update-Phase 3: Aktualisieren der Steuerungsebene, optional einschließlich Betriebssystempaket-Updates.
- Update-Phase 4: Aktualisieren der Access-Dienste und Validieren des Dienststatus.
- Update-Phase 5: Falls Update-Phase 1 zutraf, das Betriebssystem der Bootstrap-VM aktualisieren.
Unabhängig davon, mit welcher Phase Sie beginnen, vervollständigen Sie zuerst den Abschnitt Vorbereiten.
Vorbereiten – Shell-Variablen exportieren
Legen Sie die folgenden Variablen in Ihrer Shell fest, bevor Sie beginnen. Die nachfolgenden Phasen hängen davon ab, einschließlich der Phasen, mit denen Sie direkt beginnen können, wenn Sie die Update-Phase 1 überspringen.
export WORKDIR="/opt/wss/<cluster_name>"
export BOOTSTRAP_IP="<bootstrap-node-ip>"
export TARGETS="general_compute_linux:general_compute_access_linux"
export ASSET_DIR="${WORKDIR}/assets-<version>"
Update-Phase 1: Konfigurieren des lokalen Repositorys für Betriebssystem-Updates
Hinweis: Wenn dieses Update keine Betriebssystempaket-Updates enthält, fahren Sie mit Update-Phase 2 – Konfigurieren des neuen Asset-Pakets fort.
Vorgehensweise:
-
Entpacken Sie die RPM-Datei für das Betriebssystem-Sicherheitsupdate, die Sie heruntergeladen haben.
tar -zxvf <filename> # Where <filename> is the name of the OS security RPM file. -
Führen Sie das Aktualisierungsskript für das DNF-Repository auf der Bootstrap-VM aus:
sh /usr/local/sbin/update-dnf-repo.sh /opt/wss/<filename> -
Aktivieren Sie das lokale Repository auf der Bootstrap-VM und stellen Sie das CA-Zertifikat für die Verteilung an die Clusterknoten bereit:
sed -i 's/enabled=0/enabled=1/' /etc/yum.repos.d/localrepo.repo mkdir -p ${WORKDIR}/access/localrepo_ca_path cp -f /etc/nginx/localrepo-certs/root-ca.crt \ ${WORKDIR}/access/localrepo_ca_path/root-ca.crt -
Übertragen Sie die Konfiguration des lokalen Repositorys an die Clusterknoten:
-
Erstellen Sie das Zertifikatsverzeichnis auf den Clusterknoten:
wso control-plane ansible -- -b -m file \ -a "path=/etc/nginx/localrepo-certs state=directory owner=root group=root mode=0755" \ "${TARGETS}" -
Kopieren Sie das Stamm-CA-Zertifikat auf die Clusterknoten:
wso control-plane ansible -- -b -m copy \ -a "src=/workdir/access/localrepo_ca_path/root-ca.crt dest=/etc/nginx/localrepo-certs/root-ca.crt owner=root group=root mode=0644 force=yes" \ "${TARGETS}" -
Verweisen Sie die Clusterknoten auf das Bootstrap-HTTPS-Repository:
wso control-plane ansible -- -b -m ini_file \ -a "path=/etc/yum.repos.d/localrepo.repo section=localrepo option=baseurl value=https://${BOOTSTRAP_IP}/" \ "${TARGETS}" wso control-plane ansible -- -b -m ini_file \ -a "path=/etc/yum.repos.d/localrepo.repo section=localrepo option=sslverify value=1" \ "${TARGETS}" wso control-plane ansible -- -b -m ini_file \ -a "path=/etc/yum.repos.d/localrepo.repo section=localrepo option=sslcacert value=/etc/nginx/localrepo-certs/root-ca.crt" \ "${TARGETS}" wso control-plane ansible -- -b -m ini_file \ -a "path=/etc/yum.repos.d/localrepo.repo section=localrepo option=enabled value=1" \ "${TARGETS}" -
Erstellen Sie den DNF-Cache auf den Clusterknoten nur aus dem lokalen Repository neu. Dieser Schritt muss wiederholt werden, wenn Sie mehrere Updates zusätzlich zur veröffentlichten Version installieren.
wso control-plane ansible -- -b -m shell \ -a "dnf clean all && rm -rf /var/cache/dnf/* && dnf --refresh makecache --disablerepo='*' --enablerepo=localrepo && dnf --refresh --disablerepo='*' --enablerepo=localrepo list available" \ "${TARGETS}"
-
Update-Phase 2: Konfigurieren des neuen Asset-Pakets
Vorgehensweise:
-
Erstellen Sie ein Verzeichnis für das neue Asset-Paket und laden Sie es herunter:
mkdir -p ${ASSET_DIR} cd ${ASSET_DIR} # Copy the target release asset bundle to this location ${ASSET_DIR}Wichtig: Laden Sie das Asset-Paket herunter, das Ihrer Zielversion entspricht. Verwenden Sie kein Paket aus einer älteren Version erneut.
-
Extrahieren Sie das Paket und fügen Sie die CLI zu Ihrem Pfad hinzu:
# Ensure that you are in ${ASSET_DIR} before you unzip the asset bundle unzip asset-bundle.zip cp cli-distribution/linux/wso /usr/bin/ cp: overwrite '/usr/bin/wso'? y # It will prompt for overwrite wso eula Do you agree to these terms ? [y/n]: y -
Konfigurieren Sie die CLI für die Verwendung des neuen Pakets:
cd ${WORKDIR} wso configure ${ASSET_DIR}
Update-Phase 3: Aktualisieren der Steuerungsebene
Vorgehensweise:
-
Stellen Sie die Steuerungsebene mit dem neuen Asset-Paket bereit. Fügen Sie
-uhinzu, wenn dieses Update auch Betriebssystempakete auf den Clusterknoten aktualisiert:# To update without OS packages update nohup wso cp deploy & # To update with OS packages update nohup wso cp deploy -u &Dieser Schritt kann einige Zeit in Anspruch nehmen.
-
Überprüfen Sie die Bereitstellung.
wso version wso healthcheck -
Wenn Sie die Bereitstellung mit
-udurchgeführt haben, heben Sie die Sperre des Clusters auf:Hinweis: Sie können diesen Schritt überspringen, wenn Sie die Bereitstellung ohne
-udurchgeführt habenwso cp unsealDieser Schritt kann einige Zeit in Anspruch nehmen.
Update-Phase 4: Aktualisieren der Access-Dienste
Vorgehensweise:
-
Passen Sie die Access-Konfiguration für das Update an:
cd ${WORKDIR} wso access update-config set -
Falls im Arbeitsverzeichnis ein Verzeichnis
servicesaus einem früheren Patch oder Update vorhanden ist, verwenden Sie den folgenden Befehl, damit die Bereitstellung stattdessen die Images aus dem neuen Paket verwendet:mv ${WORKDIR}/services to ${WORKDIR}/services.bk -
Stellen Sie alle Access-Dienste bereit:
nohup wso services deploy --type full & -
Überprüfen Sie die Integrität der Dienste:
wso access check-service-readiness -
Nachdem alle Dienste den fehlerfreien Zustand gemeldet haben, beenden Sie den Update-Modus:
wso access update-config reset -
Beseitigen Sie Assets aus der vorherigen Version:
wso cp reset-assets
Update-Phase 5: Aktualisieren des Bootstrap-VM-Betriebssystems
Führen Sie diese Phase erst aus, nachdem das Cluster-Update erfolgreich abgeschlossen wurde. Sie können Ihre Clustervorgänge durchführen, nachdem Sie Update-Phase 4 abgeschlossen haben.
Wählen Sie für diese Phase aus, ob ein direktes Update durchgeführt oder die VM ersetzt werden soll.
Direktes Update
-
Aktualisieren Sie die Pakete und starten Sie die Bootstrap-VM neu:
dnf update -y reboot -
Nachdem die Bootstrap-VM wieder online geschaltet wurde, validieren Sie den Cluster:
wso healthcheck wso access check-service-readiness
Ersetzen der VM
Verwenden Sie diese Option, wenn Sie eine neue Bootstrap-VM aus der neuesten Omnissa-OVA bereitstellen möchten, anstatt die vorhandene Bootstrap-VM vor Ort zu patchen. Dieser Ansatz wird für größere Betriebssystem-Updates empfohlen.
Schritt 1: Erstellen eines Migrationspakets aus der vorhandenen Bootstrap-VM
cd /opt/wss/<cluster_name>
tar czpvf /opt/wss/<cluster_name>-migration-$(date +%Y%m%d).tar.gz \
profile.yml \
logging \
telegraf_plugin \
ansible_extra_vars.yml \
access \
cp-cluster \
additional_env_vars.env \
deploy_services.log \
deployment-config.yml
Schritt 2: Kopieren des Migrationspakets auf die neue Bootstrap-VM
scp /opt/wss/<cluster_name>-migration-*.tar.gz configuser@<new-bootstrap-machine>:/home/configuser/
Schritt 3: Wiederherstellen der Konfiguration auf der neuen Bootstrap-VM
mkdir -p /opt/wss/<cluster_name>
cd /opt/wss/<cluster_name>
tar xzpvf /home/configuser/cp-cluster-migration-*.tar.gz
Die neue Bootstrap-VM enthält jetzt dieselbe Bereitstellungskonfiguration wie die vorherige Bootstrap-VM.
Schritt 4: Konfigurieren des Asset-Pakets
Kopieren Sie das mit der vorhandenen Bootstrap-VM verwendete Asset-Paket auf die neue Bootstrap-VM und führen Sie dann die folgenden Schritte aus.
mkdir -p assets
cd assets
# COPY asset bundle at this path.
unzip asset-bundle.zip
cp cli-distribution/linux/wso /usr/bin/
wso eula
wso configure /opt/wss/<cluster_name>/assets/
cd ..
Schritt 5: Validieren der neuen Bootstrap-VM
wso version
wso healthcheck
wso access check-service-readiness
Stellen Sie sicher, dass die CLI-Version, die Image-Version der Steuerungsebene, die CPS-Image-Version, der Zustand des Clusters und die Betriebsbereitschaft des Access-Diensts korrekt sind. Alle Access-Dienste sollten den Status READY melden.
War diese Seite hilfreich?