このトピックでは、既存の Control Plane ベースの Omnissa Access 展開を更新するための推奨手順について説明します。オペレーティング システム パッケージ、Control Plane アセット バンドル、Access サービス、ブートストラップ仮想マシンの更新について説明します。
**重要:**これらの更新手順は、バージョン 2412 以前のアップグレードには適用されません。
前提条件
- 特に指定がない限り、ブートストラップ仮想マシンからすべてのコマンドを実行します。
- 既存の展開は健全である必要があります。
wso healthcheckとwso access check-service-readinessを実行して、開始する前にシステムの健全性を確認します。 - ターゲット リリースのオフライン アセット バンドルがダウンロードされ、ブートストラップ仮想マシンで使用できるようになっています。
- OS セキュリティ RPM がダウンロードされ、ブートストラップ仮想マシンで使用できるようになっています(このアップデートに OS パッケージの更新が含まれている場合)。
更新ワークフロー
更新は、次のフェーズで構成されます。
- フェーズ 1 - オペレーティング システムの更新用にローカル リポジトリを構成します(オペレーティング システム パッケージの更新が必要な場合のみ)。
- フェーズ 2 - 新しい Control Plane アセット バンドルをダウンロードして構成します。
- フェーズ 3 - Control Plane を更新します(オプションで OS パッケージの更新も含む)。
- フェーズ 4 - Access サービスを更新し、サービスのステータスを検証します。
- フェーズ 5 - フェーズ 1 が該当する場合は、ブートストラップ仮想マシンのオペレーティング システムを更新します。
フェーズ 1 - OS 更新のためのローカル リポジトリの構成
注:
-
この更新にオペレーティング システム パッケージの更新が含まれていない場合は、「フェーズ 2 - 新しいアセット バンドルの構成」に進みます。
-
独自の AlmaLinux 9.6 を展開する場合、フェーズ 1 は適用されません。「フェーズ 2 - 新しいアセット バンドルの構成」に進みます。
手順:
-
ブートストラップ仮想マシンで DNF リポジトリ更新スクリプトを実行します。
sh /usr/local/sbin/update-dnf-repo.sh /root/security-rpms.tar.gz -
シェルで次の変数を設定し、残りの手順で使用します。
export WORKDIR="/root/<cluster_name>" export BOOTSTRAP_IP="<bootstrap-node-ip>" export TARGETS="general_compute_linux:general_compute_access_linux" export ASSET_DIR="${WORKDIR}/assets-<version>" -
ブートストラップ仮想マシンでローカル リポジトリを有効にし、クラスタ ノードに配布するために 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 -
ローカル リポジトリ構成をクラスタ ノードにプッシュします。
-
クラスタ ノードに証明書ディレクトリを作成します。
wso control-plane ansible -- -b -m file \ -a "path=/etc/nginx/localrepo-certs state=directory owner=root group=root mode=0755" \ "${TARGETS}" -
ルート 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}" -
クラスタ ノードをブートストラップ 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}" -
クラスタ ノードの 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 - 新しいアセット バンドルの構成
手順:
-
新しいアセット バンドルのディレクトリを作成し、ダウンロードします。
mkdir -p ${ASSET_DIR} cd ${ASSET_DIR} # Copy the target release asset bundle to this location ${ASSET_DIR}**重要:**ターゲット リリースに対応するアセット バンドルをダウンロードします。古いリリースのバンドルを再利用しないでください。
-
バンドルを抽出し、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 -
新しいバンドルを使用するように CLI を構成します。
cd ${WORKDIR} wso configure ${ASSET_DIR}
フェーズ 3 - Control Plane の更新
手順:
-
新しいアセット バンドルを使用して 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 & -
展開を確認します。
wso version wso healthcheck -
-uを使用して展開した場合は、クラスタのシールを解除します。注:
-uを使用せずに展開している場合は、この手順をスキップできます。wso cp unseal
フェーズ 4 - Access サービスの更新
手順:
-
更新のために Access 構成を調整します。
wso access update-config set -
以前の手動オーバーライドによって、作業ディレクトリに
servicesディレクトリが存在する場合は、展開で新しいバンドルのイメージが使用されるようにするために移動します。mv ${WORKDIR}/services to ${WORKDIR}/services.bk -
すべての Access サービスを展開します。
nohup wso services deploy --type full & -
サービスの健全性を確認します。
wso access check-service-readiness -
すべてのサービスが健全であると報告されたら、更新モードを終了します。
wso access update-config reset -
以前のリリースのアセットをクリーンアップします。
wso cp reset-assets
フェーズ 5 - ブートストラップ仮想マシンのオペレーティング システムの更新
このフェーズは、クラスタの更新が正常に完了した後にのみ実行します。このフェーズでは、クラスタのダウンタイムは必要ありません。フェーズ 4 が完了したら、クラスタ操作を実行できます。
このフェーズでは、インプレース更新を実行するか、仮想マシンを置き換えるかを選択します。
インプレース更新
-
パッケージを更新し、ブートストラップ仮想マシンを再起動します。
dnf update -y reboot -
ブートストラップ仮想マシンがオンラインに戻ったら、クラスタを検証します。
wso healthcheck wso access check-service-readiness
仮想マシンの置き換え
既存のブートストラップ仮想マシンにパッチを適用する代わりに、最新の Omnissa OVA から新しいブートストラップ仮想マシンを展開する場合は、このオプションを使用します。このアプローチは、OS のメジャー アップデートに推奨されます。
手順 1 - 既存のブートストラップ仮想マシンからの移行パッケージの作成
cd /root/<cluster_name>
tar czpvf /root/<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 /root/<cluster_name>-migration-*.tar.gz configuser@<new-bootstrap-machine>:/home/configuser/
手順 3 - 新しいブートストラップ仮想マシンでの構成のリストア
mkdir -p /root/<cluster_name>
cd /root/<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 /root/<cluster_name>/assets/
cd ..
手順 5 - 新しいブートストラップ仮想マシンの検証
wso version
wso healthcheck
wso access check-service-readiness
CLI バージョン、Control Plane イメージ バージョン、CPS イメージ バージョン、クラスタの健全性、および Access サービスの準備がすべて正しいことを確認します。すべての Access サービスが、READY のステータスを報告する必要があります。
このページは役に立ちましたか?