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

2026년 8월 18일

Omnissa Access Control Plane 배포 업데이트

이 항목에서는 기존 제어부 기반 Omnissa Access 배포를 업데이트하기 위한 권장되는 절차에 대해 설명합니다. 운영 체제 패키지, 제어부 자산 번들, Access 서비스 및 부트스트랩 VM의 업데이트가 포함됩니다.

중요: 이러한 업데이트 지침은 버전 2412 이하를 업그레이드하는 데는 적용되지 않습니다.

사전 요구 사항

  • 달리 지정하지 않는 한 부트스트랩 VM에서 모든 명령을 실행합니다.
  • 기존 배포는 정상 상태여야 합니다. wso healthcheck 및 wso access check-service-readiness를 실행하여 시작하기 전에 시스템 상태를 확인합니다.
  • 대상 릴리스에 대한 오프라인 자산 번들이 다운로드되고 부트스트랩 VM에서 사용할 수 있습니다.
  • 이 업데이트에 OS 패키지 업데이트가 포함된 경우 OS 보안 RPM이 다운로드되고 부트스트랩 VM에서 사용할 수 있습니다.

업데이트 워크플로

업데이트는 다음 단계로 구성됩니다.

  1. 1단계 - 운영 체제 업데이트를 위해 로컬 저장소를 구성합니다(운영 체제 패키지 업데이트가 필요한 경우에만 해당).
  2. 2단계 - 새 제어부 자산 번들을 다운로드하고 구성합니다.
  3. 3단계 - 필요한 경우 OS 패키지 업데이트를 포함하여 제어부를 업데이트합니다.
  4. 4단계 - Access 서비스를 업데이트하고 서비스 상태를 검증합니다.
  5. 5단계 - 1단계를 적용할 수 있는 경우 부트스트랩 VM 운영 체제를 업데이트합니다.

1단계 - OS 업데이트를 위한 로컬 저장소 구성

참고:

  • 이 업데이트에 운영 체제 패키지 업데이트가 포함되지 않은 경우 2단계 - 새 자산 번들 구성으로 건너뜁니다.

  • 고유한 AlmaLinux 9.6을 배포하는 경우에는 1단계를 적용할 수 없습니다. 2단계 - 새 자산 번들 구성으로 건너뜁니다.

절차:

  1. 부트스트랩 VM에서 DNF 저장소 업데이트 스크립트를 실행합니다.

    sh /usr/local/sbin/update-dnf-repo.sh /root/security-rpms.tar.gz

  2. 나머지 단계에서 사용할 셸에 다음 변수를 설정합니다.

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

  3. 부트스트랩 VM에서 로컬 저장소를 사용하도록 설정하고 클러스터 노드에 배포하기 위해 해당 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단계 - 제어부 업데이트

절차:

  1. 새 자산 번들을 사용하여 제어부를 배포합니다. 이 업데이트가 클러스터 노드의 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 구성 조정:

    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단계 - 부트스트랩 VM 운영 체제 업데이트

클러스터 업데이트가 성공적으로 완료된 후에만 이 단계를 수행합니다. 이 단계에서는 클러스터의 다운타임이 필요하지 않습니다. 4단계를 완료하면 클러스터 작업을 수행할 수 있습니다.

이 단계에서는 인플레이스 업데이트를 수행하거나 VM을 교체하도록 선택합니다.

인플레이스 업데이트

  1. 패키지 업데이트 및 부트스트랩 VM 재부팅:

    dnf update -y
reboot

  2. 부트스트랩 VM이 다시 온라인 상태가 되면 클러스터 유효성 검사:

    wso healthcheck
wso access check-service-readiness

VM 교체

기존 부트스트랩 VM을 인플레이스 패치하는 대신 최신 Omnissa OVA에서 새 부트스트랩 VM을 배포하려는 경우 이 옵션을 사용합니다. 이 방법은 주요 OS 업데이트에 권장됩니다.

1단계 - 기존 부트스트랩 VM에서 마이그레이션 패키지 생성

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단계 - 새 부트스트랩 VM에 마이그레이션 패키지 복사

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

3단계 - 새 부트스트랩 VM에서 구성 복원

mkdir -p /root/<cluster_name>
cd /root/<cluster_name>

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

이제 새 부트스트랩 VM에 이전 부트스트랩 VM과 동일한 배포 구성이 포함됩니다.

4단계 - 자산 번들 구성

기존 부트스트랩 VM과 함께 사용되는 자산 번들을 새 부트스트랩 VM에 복사한 후 다음 단계를 실행합니다.

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단계 - 새 부트스트랩 VM의 유효성 검사

wso version
wso healthcheck
wso access check-service-readiness

CLI 버전, 제어부 이미지 버전, CPS 이미지 버전, 클러스터 상태 및 Access 서비스 준비 상태가 모두 올바른지 확인합니다. 모든 Access 서비스는 READY의 상태를 보고해야 합니다.

이 페이지가 도움이 되었나요?

이 항목에 대한 피드백 보내기

이 항목이 도움이 되었나요?

개인정보나 기밀정보는 입력하지 마세요.

링크를 생성하는 중…