3장 자원 유형 업그레이드

이 장에서는 자원 유형을 업그레이드하고 자원을 이전하기 위해 알아 두어야 할 문제점에 대해 설명합니다.

• 개요

• 자원 유형 등록 파일

• 자원 Type_version 등록 정보

• 다른 버전으로 자원 이전

• 자원 유형 업그레이드 및 다운그레이드

• 기본 등록 정보 값

• 자원 유형 개발자 설명서

• 자원 유형 이름 및 자원 유형 모니터 구현

• 응용 프로그램 업그레이드

• 자원 유형 업그레이드 예

• 자원 유형 패키지의 설치 요구 사항

개요

시스템 관리자에게는 기존 자원 유형의 새 버전을 설치 및 등록하고, 지정된 자원 유형의 여러 버전을 등록하고, 자원을 삭제하거나 다시 만들지 않고도 기존 자원을 새 버전의 자원 유형으로 이전할 수 있는 기능이 필요합니다. 자원 개발자는 자원 유형 업그레이드 및 자원 이전을 위한 모든 요구 사항을 알고 있어야 합니다.

업그레이드를 염두에 두고 개발한 자원 유형을 업그레이드 인식이라고 합니다.

자원 유형의 새로운 버전은 다음과 같은 여러 면에서 이전 버전과 다를 수 있습니다.

• 자원 유형 등록 정보의 속성이 변경될 수 있습니다.

• 표준 및 확장 등록 정보를 포함하여 선언된 자원 등록 정보 집합이 변경될 수 있습니다.

• default , min, max, arraymin, arraymax와 같은 자원 등록 정보 속성이나 조정 기능이 변경될 수 있습니다.

• 선언된 메소드 집합이 다를 수 있습니다.

• 메소드나 모니터의 구현이 변경될 수 있습니다.

자원 유형 개발자는 다음 조정 기능 옵션에서 기존 자원을 새 버전으로 이전할 수 있는 시기를 결정합니다. 가장 제한이 적은 옵션부터 가장 제한적인 옵션 순으로 옵션이 나열됩니다.

• 언제든지(ANYTIME)

• 자원이 모니터링 해제될 때(WHEN_UNMONITORED)

• 자원이 오프라인일 때(WHEN_OFFLINE)

• 자원이 사용 불가능할 때(WHEN_DISABLED)

• 자원 그룹이 관리 해제될 때(WHEN_UNMANAGED)

• 만들 때(AT_CREATION)

이 장에서는 업그레이드 수행 방법을 설명할 때 scrgadm 명령을 사용합니다. 관리자는 scrgadm 명령만 사용하도록 제한되지 않으며 GUI 또는 scsetup 명령을 사용하여 업그레이드를 수행할 수도 있습니다.

자원 유형 등록 파일

자원 유형 이름

Vendor_id, Resource_type, RT_version 등 파일에 지정된 세 가지 등록 정보가 자원 유형 이름을 구성합니다. scrgadm 명령은 다음과 같이 점과 콜론 분리자를 삽입하여 자원 유형의 이름을 만듭니다.

vendor_id.resource_type:rt_version

Vendor_id 접두어는 서로 다른 공급업체에서 제공하는 동일한 이름의 등록 파일 두 개를 구분하는 역할을 합니다. RT_version은 동일한 기본 자원 유형의 등록된 여러 버전(업그레이드)을 구분합니다. Vendor_id를 고유하게 만들려면 자원 유형을 만드는 회사의 주식 기호를 사용하는 것이 좋습니다.

RT_version 문자열이 공백, 탭, 슬래시( /), 백슬래시(\), 별표(*), 물음표(?), 쉼표(,), 세미콜론(;), 왼쪽 각괄호([) 또는 오른쪽 각괄호(]) 문자를 포함하고 있는 경우 자원 유형의 등록에 실패합니다.

Sun Cluster 3.0에서 선택적인 RT_Version 등록 정보는 Sun Cluster 3.1부터 필수입니다.

정규화된 이름은 다음 명령에서 반환한 이름입니다.

scha_resource_get -O Type -R resource_name -G resource_group_name

Sun Cluster 3.1 이전에 등록된 자원 유형 이름의 형식은 다음과 같습니다.

vendor_id.resource_type

지시어

자원 유형이 업그레이드를 인식하게 하려면 RTR 파일에 #$upgrade 지시어가 포함되어야 하며, 그 뒤에 다음과 같은 형식의 지시어가 0개 이상 올 수 있습니다.

#$upgrade_from version tunability

upgrade_from 지시어는 자원에 대한 문자열 #$upgrade_from, RT_Version, 조정 기능 제약 조건으로 구성됩니다. 업그레이드가 수행될 자원 유형에 버전이 없을 경우 RT_Version은 아래의 마지막 예에 표시된 것과 같이 빈 문자열로 지정됩니다.

#$upgrade_from   "1.1"   when_offline 
#$upgrade_from   "1.2"   when_offline
#$upgrade_from   "1.3"   when_offline
#$upgrade_from   "2.0"   when_unmonitored
#$upgrade_from   "2.1"   anytime
#$upgrade_from   ""      when_unmanaged

시스템 관리자가 Type_version 자원을 변경하려 할 경우 RGM은 자원에 다음 제약 조건을 적용합니다. 현재 버전의 자원 유형이 목록에 나타나지 않을 경우 RGM은 WHEN_UNMANAGED의 조정 기능을 부과합니다.

이 지시어는 RTR 파일의 자원 유형 등록 정보 선언 섹션과 자원 선언 섹션 사이에 표시되어야 합니다. rt_reg(4)를 참조하십시오.

RTR 파일에서 RT_Version 변경

RTR 파일의 내용이 바뀔 때마다 RTR 파일의 RT_Version 문자열을 변경합니다. 이 등록 정보 값은 자원 유형의 새 버전과 이전 버전을 명확하게 구분해야 합니다. RTR 파일을 변경하지 않은 경우 RT_Version 문자열을 변경하지 않아도 됩니다.

이전 버전 Sun Cluster의 자원 유형 이름

Sun Cluster 3.0의 자원 유형 이름에는 버전 접미어가 포함되지 않았습니다.

vendor_id.resource_name

처음 Sun Cluster 3.0에 등록한 자원 유형은 클러스터링 소프트웨어를 Sun Cluster 3.1 이후 릴리스로 업그레이드한 후에도 이 양식의 이름을 갖습니다. 마찬가지로 Sun Cluster 3.1 이후 소프트웨어를 실행하는 클러스터에 RTR 파일을 등록한 경우 RTR 파일의 #$upgrade 지시어가 누락된 자원 유형에는 버전 접미어 없이 Sun Cluster 3.0 형식 이름이 제공됩니다.

RTR 파일을 Sun Cluster 3.0의 #$upgrade 또는 #$upgrade_from 지시어로 등록할 수 있지만, 기존 자원을 Sun Cluster 3.0의 새 자원 유형으로 이전하는 것은 지원되지 않습니다.

자원 Type_version 등록 정보

표준 자원 등록 정보 Type_version에는 자원 유형의 RT_Version 등록 정보가 저장됩니다. 이 등록 정보는 RTR 파일에 나타나지 않습니다. 시스템 관리자는 다음 명령을 사용하여 이 등록 정보 값을 편집합니다.

scrgadm -c -j resource -y Type_version=new_version

이 등록 정보의 조정 기능은 다음에서 파생됩니다.

• 자원 유형의 현재 버전

• RTR 파일의 #$upgrade_from 지시어

#$upgrade_from 지시어에 다음 조정 기능 값을 사용합니다.

ANYTIME

자원을 업그레이드할 수 있는 시기에 대한 아무런 제한이 없는 경우. 자원은 완전히 온라인이 될 수 있습니다.

WHEN_UNMONITORED

새 자원 유형 버전의 Update, Stop, Monitor_check 및 Postnet_stop 메소드가 이전 자원 유형 버전의 시작 메소드(Prenet_stop 및 Start)와 호환되는 경우, 그리고 새 자원 유형 버전의 Fini 메소드가 이전 버전의 Init 메소드와 호환되는 것으로 알려진 경우. 이 시나리오에서는 업그레이드 전 자원 모니터 프로그램 중지만을 요구합니다.

WHEN_OFFLINE

새 자원 유형 버전의 Update, Stop, Monitor_check 또는 Postnet_stop 메소드가 이전 자원 유형 버전의 시작 메소드(Prenet_stop 및 Start)와 호환되지 않는 것으로 알려져 있지만 이전 버전의 Init 메소드와 호환될 경우, 자원 업그레이드를 적용할 때 자원은 오프라인이어야 합니다.

WHEN_DISABLED

WHEN_OFFLINE과 유사합니다. 그러나 이 조정 기능 값은 자원을 사용 불가능하게 하는 보다 강력한 조건을 부과합니다.

WHEN_UNMANAGED

새 자원 유형 버전의 Fini 메소드가 이전 버전의 Init 메소드와 호환되지 않을 경우. 이 조정 기능 값에서는 기존 자원 그룹을 관리 해제 상태로 전환해야 자원을 업그레이드할 수 있습니다.

AT_CREATION

자원을 새 자원 유형 버전으로 업그레이드할 수 없을 경우. 새 버전의 새 자원만 만들 수 있습니다.

AT_CREATION의 조정 기능은 자원 유형 개발자가 기존 자원을 새 유형으로 이전하는 것을 금지할 수 있음을 의미합니다. 이 경우 시스템 관리자는 자원을 삭제하고 다시 만들어야 합니다. 이것은 작성 시에만 자원 버전을 설정할 수 있다고 선언하는 것과 같습니다.

다른 버전으로 자원 이전

시스템 관리자가 자원의 Type_version 등록 정보를 편집할 경우 기존 자원은 새 자원 유형 버전으로 이전합니다. 이 경우 현재 버전 대신 새 자원 유형 버전에서 파생되거나 가져올 일부 정보를 제외하고 다른 자원 등록 정보를 편집하기 위해 사용하는 동일한 규칙을 따릅니다.

• min, max, arraymin, arraymax, 기본값 및 조정 가능 같은 모든 등록 정보에 대한 자원 등록 정보 속성은 새 자원 유형 버전에서 가져옵니다.

• Type_version 등록 정보에 적용되는 조정 기능은 RTR 파일의 #$upgrade_from 지시어와 기존 자원의 자원 유형의 RT_version 등록 정보에서 가져옵니다. 이 조정 기능은 property_attributes(5)에서 설명한 조정 기능과는 다릅니다.

• 새 자원 유형 버전에 대한 Validate 메소드가 적용됩니다. 그러면 등록 정보 속성이 새 자원 유형에 유효하게 됩니다. 기존 자원 등록 정보 속성이 새 자원 유형 버전의 검증 조건을 충족시키지 못할 경우 시스템 관리자는 scrgadm 명령줄에서 해당 등록 정보에 대한 유효한 값을 제공해야 합니다. 새 자원 유형 버전에서 이전 버전에서 선언하지 않고 기본값을 갖고 있지 않는 등록 정보를 사용하기 시작할 경우에 이런 일이 발생할 수 있습니다. 기존 자원에 새 자원 유형 버전에 유효하지 않은 값이 지정된 등록 정보가 있을 경우에도 이런 일이 발생할 수 있습니다.

• 이전 버전의 자원 유형에서 선언한 자원 등록 정보는 새 버전에서 선언 해제할 수 있습니다. 자원을 새 버전으로 이전한 경우 자원에서 등록 정보가 삭제됩니다.

Validate 메소드는 Validate 명령줄에서 전달된 새로운 Type_version뿐만 아니라 scha_resource_get을 사용하여 자원의 현재 Type_version을 쿼리할 수 있습니다. 따라서 Validate에서는 지원되지 않는 버전에서의 업그레이드를 제어할 수 있습니다.

자원 유형 업그레이드 및 다운그레이드

Sun Cluster 3.1 Data Service Planning and Administration Guide for Solaris OS의 “Upgrading a Resource Type” 절에는 자원 유형의 업그레이드 또는 이전에 대한 추가 정보가 들어 있습니다.

자원 유형 업그레이드 방법

1. 새 자원 유형의 업그레이드 설명서를 읽고 자원 유형 변경 사항과 자원 조정 기능 제약 조건을 확인합니다.

2. 모든 클러스터 노드에 자원 유형 업그레이드 패키지를 설치합니다.

   새로운 자원 유형 패키지 설치에는 롤링 업그레이드 방식이 권장됩니다. 즉, 비클러스터 모드에서 노드를 부트하는 동안 pkgadd가 발생합니다.

   클러스터 모드에는 노드에 새로운 자원 유형 패키지를 설치할 수 있는 시나리오가 있습니다.

   • 자원 유형 패키지 설치로 메소드 코드가 변경되지 않고 모니터만 업데이트할 경우 설치 중에 해당 유형의 모든 자원에서 모니터링을 중지해야 합니다.

   • 자원 유형 패키지 설치에서 메소드와 모니터 코드를 모두 변경하지 않는 경우 설치 중에 자원에 대한 모니터링을 중지해야 합니다. 설치 시 디스크에 새 RTR 파일만 배치합니다.

3. scrgadm 또는 그에 상응하는 명령을 사용하고 업그레이드 RTR 파일을 참조하여 새 자원 유형 버전을 등록합니다.

   RGM에서는 다음과 같은 이름 형식으로 새 자원 유형을 만듭니다.

   vendor_id.resource_type:version

4. 노드의 서브 세트에만 자원 유형 업그레이드를 설치한 경우 새 자원 유형의 Installed_nodes 등록 정보를 실제 설치된 노드로 설정해야 합니다.

   새로 만들거나 업데이트하여 자원이 새 유형을 갖게 된 경우 RGM에서는 자원 그룹 nodelist가 Installed_nodes 자원 유형 목록의 서브 세트여야 합니다.

   scrgadm -c -t resource_type -h installed_node_list

5. 업그레이드된 유형으로 이전할 사전 업그레이드된 각 자원 유형의 경우 scswitch를 호출하여 자원이나 자원 그룹의 상태를 업그레이드 설명서에서 지시한 적절한 상태로 변경합니다.

6. 업그레이드된 유형으로 이전할 사전 업그레이드된 각 자원 유형의 경우 자원을 편집하여 Type_version 등록 정보를 새 버전으로 변경합니다.

   scrgadm -c -j resource -y Type_version=new_version

   필요한 경우 동일한 자원의 다른 등록 정보를 동일한 명령의 적절한 값으로 편집합니다.

7. 단계 5에서 호출한 명령을 취소하여 자원이나 자원 그룹의 이전 상태를 복원합니다.

자원을 이전 버전 자원 유형으로 다운그레이드하는 방법

자원을 이전 버전 자원 유형으로 다운그레이드할 수 있습니다. 자원을 이전 버전 자원 유형으로 다운그레이드할 수 있는 조건은 새 버전의 자원 유형으로 업그레이드할 때보다 더 제한적입니다. 먼저 자원 그룹을 관리 해제해야 합니다. 또한 자원을 업그레이드 가능한 버전의 자원 유형으로만 다운그레이드할 수 있습니다. scrgadm -p 명령을 사용하여 업그레이드 가능한 버전을 식별할 수 있습니다. 출력에서 업그레이드 가능한 버전에는 :version 접미어가 포함되어 있습니다.

1. 오프라인으로 다운그레이드할 자원이 포함된 자원 그룹을 전환합니다.

   scswitch -F -g resource_group

2. 다운그레이드할 자원과 자원 그룹의 모든 자원을 비활성화합니다.

   scswitch -n -j resource_to_downgrade scswitch -n -j resource1 scswitch -n -j resource2 scswitch -n -j resource3 ...

   ---

   주 –

   가장 종속적인 응용 프로그램 자원에서 시작하여 가장 종속성이 적은 네트워크 주소 자원으로 끝나는 종속성 순서로 자원을 비활성화합니다.

   ---

3. 자원 그룹을 관리 해제합니다.

   scswitch -u -g resource_group

4. 다운그레이드할 이전 버전의 자원 유형이 아직도 클러스터에 등록되어 있습니까?

   • 원한다면 다음 단계로 넘어가십시오.

   • 등록되어 있지 않으면 원하는 이전 버전을 다시 등록하십시오.

     scrgadm -a -t resource_type_name

5. Type_version에 대해 원하는 이전 버전을 지정하여 자원을 다운그레이드합니다.

   scrgadm -c -j resource_to_downgrade -y Type_version=old_version

   필요한 경우 동일한 자원의 다른 등록 정보를 동일한 명령의 적절한 값으로 편집합니다.

6. 관리 상태로 다운그레이드한 자원을 포함하는 자원 그룹을 가져오고, 모든 자원을 활성화한 다음, 그룹을 온라인으로 전환합니다.

   scswitch -Z -g resource_group

기본 등록 정보 값

RGM은 시스템 관리자가 명시적으로 설정하지 않고 자원 항목에 저장되지 않은 기본값의 등록 정보 같은 모든 자원을 CCR(Cluster Configuration Repository)에 저장합니다. 자원을 CCR에서 읽어올 경우 RGM은 자원 유형에서 누락된 자원 등록 정보의 기본값을 가져오거나, 정의되지 않은 경우 시스템 정의 기본값을 사용하여 가져옵니다. 새 등록 정보를 정의하거나 기존 등록 정보에 대한 새 기본값을 정의하기 위해 업그레이드된 자원 유형을 허용하는 것이 바로 등록 정보를 저장하는 방법입니다.

자원 등록 정보를 편집할 경우 RGM은 편집 명령에서 지정한 등록 정보를 CCR에 저장합니다.

업그레이드된 버전의 자원 유형에서 기본 설정된 등록 정보의 새로운 기본값 을 선언할 경우 등록 정보가 AT_CREATION 또는 WHEN_DISABLED에만 조정 가능한 것으로 선언되더라도 기존 자원에서 새로운 기본값이 상속됩니다. 새로운 기본값의 응용 프로그램으로 인해 Stop, Postnet_stop 또는 Fini 메소드가 실패할 경우 자원 유형 구현자는 업그레이드 당시에 자원 상태를 적절하게 제한해야 합니다. 이는 Type_version 등록 정보의 조정 기능 제한을 통해 할 수 있습니다.

새로운 자원 유형 버전 Validate 메소드에서 기존 등록 정보 속성이 적절한지 확인할 수 있습니다. 적절하지 않으면 시스템 관리자가 자원을 새 자원 유형 버전으로 업그레이드하기 위해 Type_version 등록 정보를 편집하는 동일한 명령으로 기존 자원의 등록 정보를 적절한 값으로 편집할 수 있습니다.

Sun Cluster 3.0에 만들어진 자원은 기본 등록 정보가 CCR에 저장되기 때문에 이후 버전으로 이전할 경우 자원 유형에 새로운 기본 등록 정보 속성을 상속하지 않습니다.

자원 유형 개발자 설명서

자원 유형 개발자는 다음 정보를 제공하는 새 자원에 대한 설명서를 제공해야 합니다.

• 모든 등록 정보 추가, 변경 또는 삭제를 설명합니다.

• 등록 정보를 새 요구 사항에 맞추는 방법을 설명합니다.

• 자원에 대한 조정 기능 제약 조건을 설명합니다.

• 새 기본 등록 정보 속성을 설명합니다.

• 시스템 관리자에게 자원을 새로운 자원 유형 버전으로 업그레이드하기 위해 Type_version 등록 정보를 편집하는 데 사용하는 동일한 명령을 사용하여 기존 자원 등록 정보를 적절한 값으로 편집할 수 있음을 알립니다.

자원 유형 이름 및 자원 유형 모니터 구현

Sun Cluster 3.0에서 업그레이드 인식 자원 유형을 등록할 수 있지만 해당 자원 유형 이름은 버전 접미어 없이 CCR에 기록됩니다. Sun Cluster 3.0 및 Sun Cluster 3.1 이후 릴리스에서 모두 제대로 실행하려면 이 자원 유형의 모니터에서 다음 두 가지 이름 지정 규칙을 처리할 수 있어야 합니다.

vendor_id.resource_name:version
vendor_id.resource_name

모니터 코드에서 다음을 실행하여 사용할 적절한 이름을 결정할 수 있습니다.

scha_resourcetype_get -O RT_VERSION -T VEND.myrt
scha_resourcetype_get -O RT_VERSION -T VEND.myrt:vers

그런 다음 출력 값을 vers와 비교하십시오. 이 명령 중 하나만 vers의 특정 값에 대해 성공합니다. 이는 동일한 버전의 자원 유형을 서로 다른 두 가지 이름으로 두 번 등록할 수 없기 때문입니다.

응용 프로그램 업그레이드

응용 프로그램 코드 업그레이드는 일부 문제점은 유사하지만 에이전트 코드를 업그레이드하는 것과는 다릅니다. 응용 프로그램 업그레이드에 자원 유형 업그레이드가 수반될 수도 있고 수반되지 않을 수도 있습니다.

자원 유형 업그레이드 예

다음 예에서는 서로 다른 일부 자원 유형 설치 및 업그레이드 시나리오에 대해 설명합니다. 자원 유형 구현의 변경 사항 유형에 따라 조정 기능 및 패키지화 정보가 선택됩니다. 자원을 새로운 자원 유형으로 이전하는 데 조정 기능이 적용됩니다.

모든 예에서는 다음을 가정합니다.

• Solaris 패키지로 자원 유형이 제공됩니다. pkgadd(1M) 및 pkgrm(1M)을 참조하십시오.

• 이전 버전의 자원 유형이 하나만 있기 때문에 새 RTR 파일에는 하나의 #$upgrade_from 지시어가 있습니다.

• 메소드가 디스크에서 제거되는 동안 RGM에서 해당 메소드를 호출할 수 있는 경우 설치 절차에서 메소드를 제거하거나 덮어쓰지 않습니다.

• 달리 지정하지 않는 한 새로운 메소드는 이전 메소드와 호환됩니다.

• 올바른 scswitch(1M) 명령이나 이에 상응하는 명령을 사용하여 설치 또는 이전하기 전에 자원 및 자원 그룹은 필수 상태로 이동합니다. 다음 예에서는 자원 그룹을 관리 해제 상태로 이동하는 방법을 보여줍니다.

  scswitch -M -n -j resource scswitch -n -j resource scswitch -F -g resource_group scswitch -u -g resource_group

• 다음 명령을 자용하여 자원 유형을 등록합니다.

  scrgadm -a -t resource_type -f path_to_RTR_file

• 다음 명령을 사용하여 자원을 이전합니다.

  scrgadm -c -j resource -y Type_version=version \ -y property=value \ -x property=value ...

• 적절한 scswitch(1M) 명령이나 이에 상응하는 명령을 사용하여 이전한 후 자원 및 자원 그룹은 이전 상태로 복원됩니다.

  scswitch -M -e -j resource scswitch -e -j resource scswitch -o -g resource_group scswitch -Z -g resource_group

자원 유형 개발자가 이 예에서 사용한 값보다 더 제한적인 조정 기능 값을 지정해야 할 수도 있습니다. 조정 기능 값은 자원 유형 구현에 대한 변경 사항에 따라 달라집니다. 자원 유형 개발자가 이 예에서 사용한 Solaris 패키지화 대신 다른 패키지화 체계를 사용하도록 선택할 수도 있습니다.

자원 유형 패키지의 설치 요구 사항

새 자원 유형 패키지의 설치와 관련된 두 가지 요구 사항이 있습니다.

• 새 자원 유형을 등록할 경우 RTR 파일을 디스크에서 액세스할 수 있어야 합니다.

• 새로운 유형의 자원을 만들 경우 선언된 모든 메소드 경로 이름과 새로운 유형의 모니터 프로그램은 디스크와 실행 가능 파일에 있어야 합니다. 자원을 사용하는 한 이전 메소드와 모니터 프로그램은 제자리에 있어야 합니다.

  가장 적절한 패키지를 결정하려면 자원 유형 구현자는 다음을 고려해야 합니다.

  • RTR 파일이 변경됩니까?

  • 등록 정보의 기본값이나 조정 기능이 변경됩니까?

  • 등록 정보의 min 또는 max 값이 변경됩니까?

  • 업그레이드에서 등록 정보를 추가 또는 삭제합니까?

  • 메소드 코드가 변경됩니까?

  • 모니터 코드가 변경됩니까?

  • 새 메소드나 메소드 코드가 이전 버전과 호환됩니까?

RTR 파일 변경 전에 알아 두어야 할 정보

일부 자원 유형 업그레이드에 새 메소드나 모니터 코드가 포함되지 않습니다. 예를 들어, 자원 유형 업그레이드에서는 자원 등록 정보의 기본값이나 조정 기능만 변경할 수 있습니다. 메소드 코드는 변경되지 않기 때문에 업그레이드를 설치하기 위한 유일한 요구 사항은 읽을 수 있는 RTR 파일에 대한 유효한 경로 이름을 갖는 것입니다.

이전 자원 유형을 다시 등록할 필요가 없을 경우 새 RTR 파일에서 이전 버전을 덮어쓸 수 있습니다. 그렇지 않으면 새 RTR 파일이 새 경로 이름에 배치될 수 있습니다.

업그레이드에서 등록 정보의 기본값이나 조정 기능을 변경할 경우 새 버전의 Validate 메소드에서 이전 시 기존 등록 정보 속성이 새 자원 유형에 유효한지 확인할 수 있습니다. 업그레이드에서 등록 정보의 min, max 또는 type 속성을 변경할 경우 scrgadm 명령에서 이전 시 이 제약 조건을 자동으로 확인합니다.

업그레이드 설명서에서 새 기본 등록 정보 속성을 설명해야 합니다. 설명서에서는 시스템 관리자에게 업그레이드할 Type_version 등록 정보를 새 자원 유형 버전으로 편집하는 동일한 명령을 사용하여 기존 자원 등록 정보를 적절한 값으로 편집할 수 있음을 알려야 합니다.

업그레이드에서 등록 정보를 추가 또는 삭제할 경우 일부 콜백 메소드나 모니터 코드도 변경해야 할 수 있습니다.

모니터 코드 변경

업데이트된 자원 유형에서 유일하게 모니터 코드만 변경된 경우 패키지 설치에서 모니터 이진을 덮어쓸 수 있습니다. 설명서에서 시스템 관리자에게 새 패키지를 설치하기 전에 모니터링을 일시 중지하도록 지시해야 합니다.

메소드 코드 변경

업데이트된 자원 유형에서 유일하게 메소드 코드만 변경된 경우 새 메소드 코드가 이전 버전과 호환되는지 확인해야 합니다. 그러면 새 메소드 코드를 새로운 경로 이름에 저장해야 할지 또는 이전 메소드를 겹쳐쓸 수 있는지 확인할 수 있습니다.

새로운 Stop, Postnet_stop 및 Fini 메소드(선언된 경우)를 Start , Prenet_stop 또는 Init 메소드의 이전 버전에서 초기화되거나 시작된 자원에 적용할 수 있는 경우 이전 메소드를 새로운 메소드로 덮어쓸 수 있습니다.

새로운 메소드 코드가 이전 버전과 호환되지 않을 경우 업그레이드된 자원 유형으로 이전하려면 이전 버전의 메소드를 사용하여 자원을 중지하거나 구성 해제해야 합니다. 새 메소드에서 이전 메소드를 덮어쓸 경우 자원 유형 업그레이드를 수행하기 전에 유형의 모든 자원을 종료하고 관리 해제해야 할 수 있습니다. 새 메소드를 이전 메소드와는 별도로 저장하고 한 번에 두 개 모두를 액세스할 수 있는 경우 역호환성이 없더라도 새 자원 유형 버전을 설치하고 한 번에 하나씩 자원을 업그레이드할 수 있습니다.

새 메소드가 역호환되더라도 다른 자원에서 계속 이전 메소드를 사용하는 경우 새 메소드를 사용하려면 한 번에 하나씩 자원을 업그레이드해야 할 수 있습니다. 또한 이전 메소드를 덮어쓰는 대신 새 메소드를 별도의 디렉토리에 저장해야 합니다.

자원 유형 버전의 메소드를 별도의 디렉토리에 저장하는 것의 이점은 새 버전에 문제가 생길 경우 자원을 이전 자원 유형 버전으로 쉽게 다시 전환할 수 있다는 것입니다.

패키지화 방법 중 하나는 패키지에서 지원되는 이전 버전을 모두 포함시키는 것입니다. 그러면 이전 메소드 경로를 덮어쓰거나 삭제하지 않고도 새 패키지 버전이 이전 버전을 대체할 수 있습니다. 지원 가능 이전 버전 수를 결정하는 것은 자원 유형 개발자에게 달려있습니다.

현재 클러스터에 있는 노드에서 메소드나 pkgrm/ pkgadd 메소드를 덮어쓰지 않는 것이 좋습니다. 메소드를 디스크에서 액세스할 수 없는 경우 RGM에서 메소드를 호출하면 예기치 않은 결과가 발생할 수 있습니다. 실행 중인 메소드의 이진을 제거하거나 대체해도 예기치 않은 결과가 발생할 수 있습니다.