Solaris OS용 Sun Cluster 3.2 릴리스 노트

업그레이드

루트 디스크가 캡슐화되면 vxlufinish 스크립트가 오류를 반환함(6448341)

문제점 요약: 이 문제는 원래의 디스크가 루트 캡슐화되고 Solaris 9 8/03 OS의 VxVM 3.5에서 Solaris 10 6/06 OS의 VxVM 5.0으로 라이브 업그레이드가 시도될 때 나타납니다. vxlufinish 스크립트는 다음 오류와 함께 실패합니다.


#./vslufinish -u 5.10

    VERITAS Volume Manager VxVM 5.0
    Live Upgrade finish on the Solairs release <5.10>

    Enter the name of the alternate root diskgroup: altrootdg
ld.so.1: vxparms: fatal: libvxscsi.so: open failed: No such file or directory
ld.so.1: vxparms: fatal: libvxscsi.so: open failed: No such file or directory
Killed
ld.so.1: ugettxt: fatal: libvxscsi.so: open failed: No such file or directory
ERROR:vxlufinish Failed: /altroot.5.10/usr/lib/vxvm/bin/vxencap -d -C 10176
-c -p 5555 -g
    -g altrootdg rootdisk=c0t1d0s2
    Please install, if 5.0 or higher version of VxVM is not installed
    on alternate bootdisk.

해결 방법: 대신, 표준 업그레이드 또는 이중 분할 업그레이드 방법을 사용하십시오.

나중에 VxVM 5.0용 Sun Cluster 3.2 Live Upgrade 지원을 사용할 수 있는지 여부를 알려면 Sun 지원 또는 Sun 담당자에게 문의하십시오.

Live Upgrade가 부트 디스크에서 전역 장치의 마운팅을 지원함(6433728)

문제점 요약: 라이브 업그레이드 중에 lucreateluupgrade 명령은 /global/.devices/node@N 항목에 해당하는 대체 부트 환경에서 DID 이름을 변경하는 데 실패합니다.

해결 방법: 라이브 업그레이드를 시작하기 전에 각 클러스터 노드에서 다음 단계를 수행합니다.

  1. 수퍼유저로 전환합니다.

  2. /etc/vfstab 파일을 백업합니다.


    # cp /etc/vfstab /etc/vfstab.old
    
  3. 편집할 /etc/vfstab 파일을 엽니다.

  4. /global/.device/node@N에 해당하는 행을 찾습니다.

  5. 전역 장치 항목을 편집합니다.

    • DID 이름을 물리적 이름으로 변경합니다.

      /dev/did/{r}dsk/dYsZ/dev/{r}dsk/cNtXdYs Z로 변경합니다.

    • 항목에서 global을 제거합니다.

    다음 예에서는 /global/.devices/node@s에 해당하는 DID 장치 d3s3의 이름이 해당 물리적 장치 이름으로 변경되고 global 항목이 제거된 것을 보여줍니다.


    기존 내용:
    /dev/did/dsk/d3s3    /dev/did/rdsk/d3s3    /global/.devices/node@2   ufs   2   no   global
    
    변경된 내용:
    dev/dsk/c0t0d0s3     /dev/rdsk/c0t0d0s3    /global/.devices/node@2   ufs   2   no   -
  6. 모든 클러스터 노드에서 /etc/vfstab 파일을 수정할 때, 클러스터의 라이브 업그레이드를 수행합니다. 그러나 업그레이드된 대체 부트 환경에서 재부트하기 전에 중지해야 합니다.

  7. 현재 업그레이드되지 않은 부트 환경의 각 노드에서 /etc/vfstab 파일을 복원합니다.


    # cp /etc/vstab.old /etc/vfstab
    
  8. 대체 부트 환경에서 편집할 /etc/vfstab 파일을 엽니다.

  9. /global/.devices/node@N에 해당하는 행을 찾아 항목 끝에 있는 대시(-)를 단어 global로 대체합니다.


    /dev/dsk/cNtXdYsZ    /dev/rdsk/cNtXdYsZ    /global/.devices/node@N   ufs   2   no   global
    
  10. 업그레이드된 대체 부트 환경에서 노드를 재부트합니다.

    DID 이름이 /etc/vfstab 파일에서 자동으로 대체됩니다.

라이브 업그레이드 동안 vxlustart 스크립트가 다른 부트 환경을 작성하지 못함(6445430)

문제점 요약: 이 문제는 Sun Cluster 라이브 업그레이드 동안 VxVM(VERITAS Volume Manager)을 업그레이드할 때 나타납니다. vxlustart 스크립트는 이전 버전에서 Solaris OS 및 VxVM을 업그레이드하는 데 사용됩니다. 스크립트는 다음과 같은 오류 메시지와 함께 실패합니다.


# ./vxlustart -u 5.10 -d c0t1d0 -s OSimage

   VERITAS Volume Manager VxVM 5.0.
   Live Upgrade is now upgrading from 5.9 to <5.10>
…
ERROR: Unable to copy file systems from boot environment &lt;sorce.8876> to BE &lt;dest.8876>.
ERROR: Unable to populate file systems on boot environment &lt;dest.8876>.
ERROR: Cannot make file systems for boot environment &lt;dest.8876>.
ERROR: vxlustart: Failed: lucreate -c sorce.8876 -C /dev/dsk/c0t0d0s2 
-m -:/dev/dsk/c0t1d0s1:swap -m /:/dev/dsk/c0t1d0s0:ufs 
-m /globaldevices:/dev/dsk/c0t1d0s3:ufs -m /mc_metadb:/dev/dsk/c0t1d0s7:ufs 
-m /space:/dev/dsk/c0t1d0s4:ufs -n dest.8876

해결 방법: 클러스터를 VxVM 5.0으로 업그레이드할 경우, 표준 업그레이드 또는 이중 분할 업그레이드 방법을 사용합니다.

나중에 VxVM 5.0용 Sun Cluster 3.2 Live Upgrade 지원을 사용할 수 있는지 여부를 알려면 Sun 지원 또는 Sun 담당자에게 문의하십시오.

루트 디스크가 캡슐화되는 경우, 해당 노드 전체에서 vxio 주 번호가 다름(6445917)

문제점 요약: VxVM(VERITAS Volume Manager)을 실행하는 클러스터의 경우, 루트 디스크가 캡슐화되면 다음 소프트웨어 중 하나인 표준 업그레이드 또는 이중 분할 업그레이드가 실패합니다.

업그레이드 후 클러스터 노드 패닉이 발생하고 부트에 실패합니다. 이는 업그레이드하는 동안 VxVM에 의해 만들어진 주 번호 또는 부 번호 때문입니다.

해결 방법: 업그레이드를 시작하기 전에 루트 디스크의 캡슐화를 해제합니다.


주의 – 주의 –

위의 절차를 제대로 따르지 않으면 업그레이드되고 있는 모든 노드에 예상치 못한 심각한 문제가 발생할 수 있습니다. 또한, 루트 디스크의 캡슐화 해제 및 캡슐화로 인해 업그레이드 동안 필요한 재부트의 수를 증가시키면서 (매번) 노드의 추가 재부트를 유발할 수 있습니다.


Solaris 9의 Sun Cluster 버전 3.1에서 Solaris 10의 버전 3.2로 Live Upgrade 후 영역을 사용할 수 없음(6509958)

문제점 요약: Solaris 9의 Sun Cluster 버전 3.1에서 Solaris 10의 버전 3.2로 라이브 업그레이드 후, 클러스터 소프트웨어에서 영역을 올바르게 사용할 수 없습니다. 문제는 Sun Cluster 패키지에 대해 pspool 데이터가 작성되지 않는다는 점입니다. 따라서 SUNWsczu와 같은 비전역 영역에 전파해야 하는 이들 패키지가 올바르게 전파되지 않습니다.

해결 방법: scinstall -R 명령을 사용하여 Sun Cluster 패키지가 업그레이드된 후, 클러스터가 클러스터 모드로 부트되기 전에 다음 스크립트를 두 번 실행합니다.

Procedure스크립트 사용에 대한 지침

시작하기 전에

다음 방법 중 하나로 이 스크립트를 준비하고 실행합니다.

  1. 수퍼유저로 전환합니다.

  2. 다음 내용으로 스크립트를 작성합니다.

    #!/bin/ksh
    
    typeset PLATFORM=${PLATFORM:-`uname -p`}
    typeset PATHNAME=${PATHNAME:-/cdrom/cdrom0/Solaris_${PLATFORM}/Product/sun_cluster/Solaris_10/Packages}
    typeset BASEDIR=${BASEDIR:-/}
    
    cd $PATHNAME
    for i in *
    do
    	if pkginfo -R ${BASEDIR} $i >/dev/null 2>&1
    	then
    		mkdir -p ${BASEDIR}/var/sadm/pkg/$i/save/pspool
    		pkgadd -d . -R ${BASEDIR} -s ${BASEDIR}/var/sadm/pkg/$i/save/pspool $i
    	fi
    done
  3. 변수 PLATFORM, PATHNAMEBASEDIR을 설정합니다.

    이들 변수를 환경 변수로 설정하거나 스크립트의 변수를 직접 수정합니다.

    PLATFORM

    플랫폼의 이름입니다. 예를 들면, sparc 또는 x86 등입니다. 기본적으로 uname -p 명령의 출력에 대해 PLATFORM 변수가 설정되어 있습니다.

    PATHNAME

    Sun Cluster 프레임워크 또는 데이터 서비스 패키지를 설치할 수 있는 장치에 대한 경로입니다. 이 값은 pkgadd 명령의 -d 옵션에 해당합니다.

    한 가지 예로 Sun Cluster 프레임워크 패키지의 경우, 이 값의 형식은 다음과 같습니다.


    /cdrom/cdrom0/Solaris_${PLATFORM}/Product/sun_cluster/Solaris_10/Packages

    데이터 서비스 패키지의 경우, 이 값의 형식은 다음과 같습니다.


    /cdrom/cdrom0/Solaris_${PLATFORM}/Product/sun_cluster_agents/Solaris_10/Packages
    BASEDIR

    루트 경로로 사용하고 pkgadd 명령의 -R 옵션에 해당하는 디렉토리의 전체 경로 이름입니다. 라이브 업그레이드의 경우, 이 값을 scinstall 명령의 -R 옵션으로 사용되는 루트 경로로 설정합니다. 기본적으로 BASEDIR 변수는 루트(/) 파일 시스템으로 설정되어 있습니다.

  4. Sun Cluster 프레임워크 패키지에 대해 한 번, 데이터 서비스 패키지에 대해 한 번 스크립트를 실행합니다.

    스크립트를 실행한 후, 각 패키지에 대한 명령 프롬프트에 다음 메시지가 표시됩니다.


    Transferring pkgname package instance

    주 –

    pspool 디렉토리가 각 패키지에 대해 이미 존재하거나 동일한 패키지 세트에 대해 스크립트를 두 번 실행한 경우, 다음 오류가 명령 프롬프트에 표시됩니다.


    Transferring pkgname package instance
    pkgadd: ERROR: unable to complete package transfer
        - identical version of pkgname already exists on destination device

    이는 무해한 메시지이며 무시해도 됩니다.


  5. 프레임워크 패키지와 데이터 서비스 패키지 모두에 대해 스크립트를 실행한 후, 노드를 클러스터 모드로 부트합니다.

노드에 Sun Cluster 3.2 핵심 패치를 추가하지 않고 기존 Sun Cluster 3.2로 패치된 클러스터에 노드를 추가할 수 없음(6554107)

문제점 요약: 노드에 기존 클러스터 노드와 동일한 패치가 있는지 확인하지 않고 새 클러스터 노드를 추가하면 클러스터 노드에 패닉이 발생할 수 있습니다.

해결 방법: 클러스터에 노드를 추가하기 전에 새 노드가 기존 클러스터 노드와 동일한 수준으로 패치되었는지 먼저 확인하십시오. 이를 수행하지 않으면 클러스터 노드에 패닉이 발생할 수 있습니다.