[AIX Solaris HP-UX Linux Windows][z/OS]

에디션에 대한 롤아웃 수행

에디션에 롤아웃을 수행할 때 활성 에디션을 새 에디션으로 대체합니다. 새 에디션은 애플리케이션을 간단하게 수정하거나 상당한 변경사항을 포함할 수 있습니다. 새 에디션이 이전 버전과 호환되는 경우 기존 클라이언트에 영향을 주지 않고 활성 에디션을 대체하기 위해 롤아웃을 수행할 수 있습니다. 새 에디션에 대한 롤아웃을 수행하려면 먼저 새 에디션 정보로 애플리케이션 에디션을 설치해야 합니다.

시작하기 전에

설치되고 시작된 애플리케이션 에디션이 있어야 하며 롤아웃을 수행하기 위한 구성자 또는 관리자 권한이 있어야 합니다.
  • 두 관리 콘솔의 두 사용자 ID가 프로세스를 동시에 완료하려고 시도하면 롤아웃 수행에 실패합니다.
  • SOAP 커넥터 특성을 튜닝하여 배치 관리자에 대한 요청 제한시간 값을 시스템에서 롤아웃을 수행하는 데 필요한 총 시간보다 크게 설정하고 배치 관리자를 다시 시작하십시오. 특성을 설정하지 않으면 requestTimeout 값이 만기될 때 롤아웃 프로세스가 실패할 수 있습니다. 설정할 값을 예측하는 공식은 number-of-groups-to-rollout * (drainage-interval + internal-quiesce-timeouts-approximately-5minutes + application-or-server-restart-times-approximately-10minutes)입니다. 또는 값을 0으로 설정하여 제한시간을 사용 안함으로 설정할 수 있습니다.
    • wsadmin 도구를 사용하여 롤아웃을 수행하는 경우 배치 관리자 프로파일의 soap.client.props에서 com.ibm.SOAP.requestTimeout 특성을 설정하여 요청 제한시간 값을 조정하십시오. 기본값은 180초이며 적절하게 늘려야 합니다.
    • 관리 콘솔을 사용하여 롤아웃을 수행하는 경우 시스템 관리 > 배치 관리자 > 관리 서비스 > JMX 커넥터 > SOAPConnector > 사용자 정의 특성 > requestTimeout을 클릭하여 요청 제한시간 값을 조정하십시오. 기본값은 600초이며 값을 적절하게 늘려야 합니다.

      자세한 정보는 Java™ Management Extensions 커넥터 특성에 대해 읽어 보십시오.

  • 관리 콘솔 내에서 롤아웃을 수행하는 경우 관리 콘솔에 대한 세션 만기를 전체 롤아웃 프로세스를 종료하는 데 필요한 시간보다 큰 값으로 설정하십시오. 요청 제한시간 값에 롤아웃 중에 처리된 그룹 수를 곱하십시오. 관리 콘솔의 세션 만기에 대한 자세한 정보는 콘솔 세션 만기 변경에 대해 읽어 보십시오.
  • 롤아웃을 수행하려면 설치하는 각 새 에디션에 다중 클러스터 라우팅 정책을 정의해야 합니다. 새 에디션의 다중 클러스터 라우팅 정책을 추가하려면 관리 태스크를 사용하십시오. 멀티 클러스터 라우팅 정책에 대한 자세한 정보는 ODR 라우팅 정책 관리 태스크의 규칙에 대해 읽어 보십시오.

이 태스크 정보

롤아웃을 수행하여 애플리케이션을 일괄처리하려는 경우에도 애플리케이션 에디션 관리자를 사용할 수 있습니다. 이는 일괄처리 프로그래밍 모델 중 하나를 준수하는 (Java EE 5(Java Enterprise Edition 5) 애플리케이션입니다.

프로시저

  1. 새 에디션을 설치하십시오. 애플리케이션 에디션 설치에서 설명하는 것과 동일한 단계를 사용하되 새 에디션 정보를 지정하십시오. 예를 들어, 애플리케이션 에디션 필드에는 2.0을 입력하고 애플리케이션 설명 필드에는 Second edition을 입력하십시오. 현재 에디션에 사용되는 대상과 동일한 배치 대상을 선택하십시오.
  2. 노드를 저장한 후 동기화하십시오.
  3. 롤아웃 설정을 지정하십시오. 애플리케이션 > 에디션 제어 센터 > application_name을 클릭하십시오. 새 에디션(예: 2.0)을 선택하고 롤아웃을 클릭하십시오.

    엔터프라이즈 또는 기타 미들웨어 애플리케이션에 대해 다음 설정을 지정하십시오.

    1. 원자 또는 그룹 롤아웃 유형을 선택하십시오.

      한 그룹의 대상 클러스터 멤버에 있는 에디션을 바꾸려면 그룹 롤아웃을 사용하십시오. 그룹 롤아웃을 가장 일반적으로 선택하며 클러스터 멤버가 네 개 이상인 경우 유용합니다. 또는 스크립트를 사용하여 지정된 그룹 크기로 그룹 롤아웃을 수행할 수 있습니다. 그룹 롤아웃에 대한 자세한 정보는 애플리케이션 에디션 관리 관리 태스크에 대해 읽어 보십시오. 그룹 롤아웃 중에 새 에디션을 사용할 수 있게 되면 모든 요청이 새 에디션으로 지정됩니다.

      클러스터의 절반에서 동시에 하나의 에디션을 다른 에디션으로 바꾸려면 원자 롤아웃을 사용하십시오. 이 롤아웃 유형은 애플리케이션의 일관적인 에디션을 사용하여 모든 사용자 요청을 처리합니다. 모든 사용자 요청은 일관적인 에디션으로 처리되므로 클러스터는 절반의 용량으로 실행됩니다. 클러스터 멤버가 네 개 이상인 경우 그룹 롤아웃을 수행하여 클러스터를 소규모 그룹으로 분할할 수 있습니다. 원자 모드는 단일 서버 배치 대상에도 사용됩니다. 단일 서버 배치 대상에서는 클러스터의 나머지 1/2에 대해 수행되는 조치가 생략됩니다. 원자 롤아웃을 시작하기 전에 배치 대상을 중지하는 경우 선택한 재설정 전략에 관계 없이 새 에디션이 활성 에디션을 대체하면 배치 대상이 시작됩니다. 이 프로시저는 롤아웃 기간에 제공되는 요청에 대해 보다 향상된 가용성을 제공합니다.

      참고: 원자 롤아웃을 수행하기 전에 대상 서버 클러스터의 로드 기능을 판별하십시오. 원자 롤아웃을 수행하면 먼저 클러스터의 1/2에서 새 에디션이 활성화된 다음 클러스터의 나머지 1/2에서 에디션이 활성화됩니다. 클러스터의 처음 1/2이 오프라인 상태가 되고 업데이트되는 동안에는 애플리케이션 요청이 클러스터의 나머지 1/2/로 라우팅됩니다. 롤아웃 기간 중에 클러스터의 1/2이 전체 로드를 처리할 수 있는지 확인하십시오.
    2. 재설정 전략을 선택하십시오. 재설정 전략은 각 배치 대상이 새 에디션을 서버 런타임에 로드하는 방식을 애플리케이션 에디션 관리자에게 지시합니다.

      다음 에디션이 해당 서버에서 이전 에디션을 대체할 때 클러스터의 각 서버에서 애플리케이션을 중지하거나 다시 시작하여 애플리케이션을 재설정하려면 소프트 재설정 전략을 사용하십시오. 소프트 재설정은 결과적으로 실행 중인 애플리케이션 서버에서 애플리케이션을 재활용하여 새 에디션을 로드하게 되므로 가장 일반적인 선택사항임과 동시에 가장 최적화된 성능의 애플리케이션 재설정입니다. 서버는 이 프로세스가 진행되는 동안 켜진 상태로 있습니다. 소프트 재설정을 사용하면 기본 라이브러리는 메모리에서 로드 해제되지 않습니다. 소프트 재설정은 일반적으로 기본 라이브러리를 사용하지 않는 애플리케이션에 대해 안전합니다. 소프트 재설정을 프로덕션 환경에서 사용하는 경우 애플리케이션 서버 프로세스를 모니터하여 가상 메모리가 충분한지 확인하십시오.

      하드 재설정 전략은 다음 에디션이 서버에서 이전 에디션을 대체할 때 클러스터의 전체 애플리케이션 서버를 재활용하여 애플리케이션이 사용하는 기본 라이브러리와 프로세스 메모리를 모두 새로 고칩니다. 이 전략은 가상 스토리지 고갈을 방지하며 새 버전의 기본 라이브러리를 로드할 수 있도록 허용합니다. 새 버전의 기본 라이브러리에 의존하거나 전체 애플리케이션 서버를 재활용하는 경우에만 새로 고쳐지는 다른 종속성을 갖는 에디션에 롤아웃을 수행하는 경우 또는 JIT(Just-In-Time) 컴파일을 위해 많은 메모리를 이용하는 대형 애플리케이션이 있는 경우 재설정 전략으로 하드 재설정을 선택하십시오.

    3. 드레인 간격(초)을 설정하십시오. 드레인 간격은 HTTP 세션에 애플리케이션 또는 서버를 재설정하기 전에 완료할 시간을 제공합니다. 드레인 간격은 재설정 전략이 시작되기 전에 애플리케이션 에디션 관리자가 대기하는 시간을 지정합니다.

      트랜잭션, 활동, 보상 범위 등의 선호도와 지능형 관리 에 알려져 있지 않은 활동은 효과적인 드레인 간격을 연장시킵니다. 이는 해당 작업 단위가 완료될 때까지 서버가 중지되지 않기 때문입니다. 지능형 관리 에 알려지지 않은 활동을 포함하는 애플리케이션은 AppEditionManager MBean 작업 거부 초기화 알림을 트리거로 사용하여 종료 처리를 시작하고 종료를 완료하는 시간 기간으로 드레인 간격을 사용합니다. 이 프로세스는 지속적 세션(예를 들어, 데이터베이스에 저장되거나 VMware DRS(Distributed Resource Scheduler)를 통해 복제되는 세션)에는 필요하지 않지만 임시(메모리 내) 세션에는 중요합니다.

      드레인 간격의 목적은 선호도 요청과 인플라이트 요청을 완료할 수 있도록 허용하는 것입니다. 임시 세션을 잃지 않으려면 드레인 간격을 애플리케이션 세션 제한시간 간격보다 길게 설정합니다. 롤아웃이 시작된 후 각 서버가 업데이트됨에 따라 서버는 새 세션을 시작하기에 부적합하다고 표시됩니다. 모든 인플라이트 요청에 대해 세션이 완료될 때까지 대기하려면 이 값을 0으로 설정하십시오. 모든 인플라이트 요청에 대해 드레인 간격 또는 세션이 완료될 때까지 대기하려면 드레인 간격을 0보다 큰 값으로 설정하십시오.

      애플리케이션 에디션 작업 거부 관리자는 전체 드레인 간격을 대기하지 않을 수 있습니다. 작업 대기 관리자가 서버의 모든 활성 요청 작업이 거부되었는지 여부를 판별하기 위해 PMI(Performance Monitoring Infrastructure) 통계를 사용할 수 있습니다. 드레인 간격 이전에 모든 요청 작업이 거부되면 애플리케이션 에디션 작업 거부 관리자가 전체 드레인 간격을 대기하지 않아도 됩니다. 전체 드레인 간격을 대기하도록 소프트 재설정을 강제 실행하려면 배치 관리자에서 appedition.rollout.softreset.fulldrainageinterval 시스템 특성을 true로 설정하면 됩니다.

      드레인 간격은 기존 세션을 완료할 수 있도록 허용합니다. 그러나 드레인 간격 끝에는 인플라이트 요청이 계속 도달할 수 있는 기간이 존재합니다. 이러한 경우 ODR(On-Demand Router)은 작업 거부 조작을 완료하는 제한시간 값 60초를 제공합니다. 요청이 60초 이내에 종료되거나 60초가 만료되면 애플리케이션 또는 서버(하드 재설정 전략의 경우)가 중지됩니다. 다음으로 인플라이트 요청이 아직 종료되지 않은 경우에는 WebSphere® Application Server Network Deployment가 애플리케이션 또는 서버 인스턴스를 중지하기 전에 60초의 작업 거부 시간을 제공합니다. 하드 재설정 전략의 경우 WebSphere Application Server Network Deployment는 서버 인스턴스를 중지하기 전에 180초의 작업 거부 시간을 제공합니다. com.ibm.ws.webcontainer.ServletDestroyWaitTime 사용자 정의 특성을 사용하여 웹 컨테이너가 요청이 완료될 때까지 대기하는 시간을 정의할 수 있습니다. 자세한 정보는 웹 컨테이너 사용자 정의 특성에 대해 읽어 보십시오.

      com.ibm.ejs.sm.server.quiesceTimeout 사용자 정의 특성을 사용하여 종료를 시작하기 전에 서버 인스턴스가 요청을 완료하기 위해 대기하는 시간을 정의할 수 있습니다. 제한시간 특성에 대한 자세한 정보는 JVM(Java Virtual Machine) 사용자 정의 특성에 대해 읽어 보십시오. 애플리케이션 에디션이 배치되는 서버 인스턴스 각각에 com.ibm.ws.webcontainer.ServletDestroyWaitTime 사용자 정의 특성과 com.ibm.ejs.sm.server.quiesceTimeout 사용자 정의 특성을 모두 설정해야 합니다.

    SIP(Session Initiation Protocol) 애플리케이션의 다음 설정을 지정하십시오.
    1. 작업 거부 전략을 선택하십시오. 작업 거부 전략은 현재 에디션을 호스팅하는 서버 또는 클러스터 멤버 중에서 얼마나 오래된 멤버를 제거할지를 지정합니다. 이 설정은 롤아웃 중인 새 에디션에는 영향을 주지 않습니다.
      모든 활성 세션 또는 대화 상자가 완료된 후 서버 또는 클러스터 멤버 작업을 거부합니다.
      서버 또는 클러스터 멤버의 모든 활성 세션과 대화 상자가 완료될 때 서버 또는 클러스터 멤버를 제거합니다.
      지정된 간격 후 서버 또는 클러스터 멤버 작업 거부:
      지정된 기간 후에 서버 또는 클러스터 멤버를 제거합니다. 초, 분 또는 시 단위로 시간을 지정하십시오.
      주의: 정적 클러스터에서 변환된 동적 클러스터에 배치되는 SIP 애플리케이션에는 롤아웃 수행이 지원되지 않습니다.
  4. 롤아웃을 시작하십시오. 확인을 클릭하십시오. 이 조치는 이전 에디션에서 새 에디션으로의 중단 없는 대체를 시작합니다.

결과

유효성 검증 모드가 아닌 에디션의 경우 롤아웃이 완료되면 현재 에디션이 새 에디션으로 바뀝니다. 원래 배치 대상 및 복제 환경에서 유효성 검증 롤아웃 모드인 에디션은 삭제됩니다. 라우팅 규칙은 새 에디션으로의 라우팅을 시작하도록 업데이트됩니다.

애플리케이션 롤아웃 프로세스에서는 첫 번째 대상 그룹에서 발생하는 오류가 이후 그룹에서 발생하는 오류와 다르게 처리됩니다. 원자 롤아웃의 경우에는 새 에디션이 활성화되는 대상의 처음 1/2이 첫 번째 그룹이 됩니다. 그룹 롤아웃의 경우 첫 번째 그룹은 새 에디션이 활성화되는 대상의 첫 번째 그룹을 나타냅니다. 첫 번째 대상 그룹에 대한 롤아웃에서 오류가 발생하는 경우(예를 들어, 애플리케이션 또는 서버를 시작할 수 없는 경우) 롤아웃 프로세스가 실패합니다. 현재 애플리케이션 에디션은 활성 상태를 유지합니다. 첫 번째 대상 그룹에 대한 롤아웃 이후 오류가 발생하면 롤아웃 프로세스가 성공적으로 완료됩니다. 새 애플리케이션 에디션은 현재 활성 상태입니다. 이전 애플리케이션 에디션은 비활성 상태로 이동합니다.

다음에 수행할 작업

결과 유효성을 검증하려면 애플리케이션 > 에디션 제어 센터 > application_name을 클릭하십시오. 새 에디션은 배치 대상의 활성 에디션입니다. 새 에디션은 실행 에디션을 대체하므로 자동으로 시작됩니다.

에디션에 대한 롤아웃을 유효성 검증 모드에서 수행하는 경우 바인딩 이름이 다시 원래 값으로 변경됩니다. 예를 들어, /clusters/cluster1-validation/jdbc/CustomerData는 다시 /clusters/cluster1/jdbc/CustomerData로 변경됩니다.


주제 유형을 표시하는 아이콘 태스크 주제



시간소인 아이콘 마지막 업데이트 날짜: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=twve_appedroll
파일 이름:twve_appedroll.html