EnglishFrançaisDeutschEspañolItaliano日本語한국어NederlandsPortuguês (Brasil)中文 (简体)中文 (繁體, 台灣)
Skip to main content

2026 年 9 月 15 日

Omnissa Access Control Plane の展開の更新

このトピックでは、既存の Control Plane ベースの Omnissa Access 展開を更新するための推奨手順について説明します。オペレーティング システム パッケージ、Control Plane アセット バンドル、Access サービス、ブートストラップ仮想マシンの更新について説明します。

**重要：**これらの更新手順は、バージョン 2412 以前のアップグレードには適用されません。

前提条件

  • 特に指定がない限り、ブートストラップ仮想マシンからすべてのコマンドを実行します。
  • 既存の展開は健全である必要があります。wso healthcheck と wso access check-service-readiness を実行して、開始する前にシステムの健全性を確認します。
  • ターゲット リリースのオフライン アセット バンドルがダウンロードされ、ブートストラップ仮想マシンで使用できるようになっています。
  • OS セキュリティ RPM がダウンロードされ、ブートストラップ仮想マシンで使用できるようになっています（このアップデートに OS パッケージの更新が含まれている場合）。

更新ワークフロー

更新は、次のフェーズで構成されます。

  1. 更新フェーズ 1 - オペレーティング システムの更新用にローカル リポジトリをダウンロードして構成します（オペレーティング システム パッケージの更新が必要な場合のみ）。
  2. 更新フェーズ 2 - 新しい Control Plane アセット バンドルをダウンロードして構成します。
  3. 更新フェーズ 3 - Control Plane を更新します（オプションで OS パッケージの更新も含む）。
  4. 更新フェーズ 4 - Access サービスを更新し、サービスのステータスを検証します。
  5. 更新フェーズ 5 - 更新フェーズ 1 を実行した場合は、ブートストラップ仮想マシンのオペレーティング システムを更新します。

開始するフェーズに関係なく、最初に以下の「準備」セクションを完了します。

準備 - シェル変数のエクスポート

開始する前に、シェルで次の変数を設定します。以降のフェーズでは、更新フェーズ 1 をスキップした場合に直接開始できるフェーズを含め、これらの変数に依存します。

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>"

更新フェーズ 1 - OS 更新のためのローカル リポジトリの構成

**注：**この更新にオペレーティング システム パッケージの更新が含まれていない場合は、「更新フェーズ 2 - 新しいアセット バンドルの構成」に進みます。

手順：

  1. ダウンロードした OS セキュリティ RPM ファイルを解凍します。

    tar -zxvf <filename>
# Where <filename> is the name of the  OS security RPM file.

  2. ブートストラップ仮想マシンで DNF リポジトリ更新スクリプトを実行します。

    sh /usr/local/sbin/update-dnf-repo.sh /opt/wss/<filename>

  3. ブートストラップ仮想マシンでローカル リポジトリを有効にし、クラスタ ノードに配布するために CA 証明書をステージングします。

    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

  4. ローカル リポジトリ構成をクラスタ ノードにプッシュします。

    1. クラスタ ノードに証明書ディレクトリを作成します。

      wso control-plane ansible -- -b -m file \
  -a "path=/etc/nginx/localrepo-certs state=directory owner=root group=root mode=0755" \
  "${TARGETS}"

    2. ルート CA 証明書をクラスタ ノードにコピーします。

      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}"

    3. クラスタ ノードをブートストラップ HTTPS リポジトリにポイントさせます。

      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}"

    4. クラスタ ノードの DNF キャッシュを、ローカル リポジトリからのみ再構築します。リリースされたバージョンの上に複数の更新を適用する場合は、この手順を繰り返す必要があります。

      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}"

更新フェーズ 2 - 新しいアセット バンドルの構成

手順：

  1. 新しいアセット バンドルのディレクトリを作成し、ダウンロードします。

    mkdir -p ${ASSET_DIR}
cd ${ASSET_DIR}
# Copy the target release asset bundle to this location ${ASSET_DIR}

    **重要：**ターゲット リリースに対応するアセット バンドルをダウンロードします。古いリリースのバンドルを再利用しないでください。

  2. バンドルを抽出し、CLI を目的のパスに追加します。

    # 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

  3. 新しいバンドルを使用するように CLI を構成します。

    cd ${WORKDIR}
wso configure ${ASSET_DIR}

更新フェーズ 3 - Control Plane の更新

手順：

  1. 新しいアセット バンドルを使用して Control Plane を展開します。この更新によってクラスタ ノードの OS パッケージも更新される場合は、-u を含めます。

    #  To update without OS packages update
nohup wso cp deploy &
# To update with OS packages update
nohup wso cp deploy  -u &

    この手順は、完了までに時間がかかります。

  2. 展開を確認します。

    wso version
wso healthcheck

  3. -u を使用して展開した場合は、クラスタのシールを解除します。

    注：-u を使用せずに展開している場合は、この手順をスキップできます。

    wso cp unseal

    この手順は、完了までに時間がかかります。

更新フェーズ 4 - Access サービスの更新

手順：

  1. 更新のために Access 構成を調整します。

    cd ${WORKDIR}
wso access update-config set

  2. 以前のパッチまたは更新で作業ディレクトリに services ディレクトリが存在する場合は、以下のコマンドを実行して、展開で新しいバンドルのイメージが使用されるようにします。

    mv ${WORKDIR}/services to ${WORKDIR}/services.bk

  3. すべての Access サービスを展開します。

    nohup wso services deploy --type full &

  4. サービスの健全性を確認します。

    wso access check-service-readiness

  5. すべてのサービスが健全であると報告されたら、更新モードを終了します。

    wso access update-config reset

  6. 以前のリリースのアセットをクリーンアップします。

    wso cp reset-assets

更新フェーズ 5 - ブートストラップ仮想マシンのオペレーティング システムの更新

このフェーズは、クラスタの更新が正常に完了した後にのみ実行します。更新フェーズ 4 が完了したら、クラスタ操作を実行できます。

このフェーズでは、インプレース更新を実行するか、仮想マシンを置き換えるかを選択します。

インプレース更新

  1. パッケージを更新し、ブートストラップ仮想マシンを再起動します。

    dnf update -y
reboot

  2. ブートストラップ仮想マシンがオンラインに戻ったら、クラスタを検証します。

    wso healthcheck
wso access check-service-readiness

仮想マシンの置き換え

既存のブートストラップ仮想マシンにパッチを適用する代わりに、最新の Omnissa OVA から新しいブートストラップ仮想マシンを展開する場合は、このオプションを使用します。このアプローチは、OS のメジャー アップデートに推奨されます。

手順 1 - 既存のブートストラップ仮想マシンからの移行パッケージの作成

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

手順 2 - 移行パッケージの新しいブートストラップ仮想マシンへのコピー

scp /opt/wss/<cluster_name>-migration-*.tar.gz configuser@<new-bootstrap-machine>:/home/configuser/

手順 3 - 新しいブートストラップ仮想マシンでの構成のリストア

mkdir -p /opt/wss/<cluster_name>
cd /opt/wss/<cluster_name>

tar xzpvf /home/configuser/cp-cluster-migration-*.tar.gz

新しいブートストラップ仮想マシンに、以前のブートストラップ仮想マシンと同じ展開構成が含まれるようになりました。

手順 4 - アセット バンドルの構成

既存のブートストラップ仮想マシンで使用されるアセット バンドルを新しいブートストラップ仮想マシンにコピーし、次の手順を実行します。

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 ..

手順 5 - 新しいブートストラップ仮想マシンの検証

wso version
wso healthcheck
wso access check-service-readiness

CLI バージョン、Control Plane イメージ バージョン、CPS イメージ バージョン、クラスタの健全性、および Access サービスの準備がすべて正しいことを確認します。すべての Access サービスが、READY のステータスを報告する必要があります。

このページは役に立ちましたか?

このトピックについてフィードバックを送信

このトピックは役に立ちましたか?

個人情報や機密情報は入力しないでください。

リンクを生成しています…