![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[z/OS]](../images/ngzos.gif)
Intelligent Management: 애플리케이션 배치 자주 질문되는 내용(FAQ)
때때로, 예상치 않은 애플리케이션 배치 동작이 발생할 수 있습니다. 이 주제에서는 애플리케이션 배치가 예상대로 작동하지 않을 때 찾으려는 일부 일반적으로 질문되는 내용에 대해 설명합니다.
애플리케이션 배치 제어기가 실행되는 위치는?
애플리케이션 배치 제어기가 실행 중인 위치를 찾기 위해 관리 콘솔 또는 스크립팅을 사용할 수 있습니다. 관리 콘솔에서 위치를 확인하려면 checkPlacementLocation.jacl 스크립트를 실행합니다.
를 클릭하십시오. 애플리케이션 배치 제어기가 실행 중인 서버를 표시하기 위해애플리케이션 배치 제어기가 서버를 시작하는 시기는 언제입니까?
- 동적 클러스터에 정의되는 애플리케이션 인스턴스의 최소 수를 충족하기 위해.
- 비활성화된 동적 클러스터에 대한 On Demand Router를 통해 요청이 라우팅될 때.
- 추가 용량으로부터 동적 클러스터가 혜택을 얻을 수 있을 때. 자동 요청 플로우 관리자는 동적 클러스터가 추가 용량을 가지고 있고 추가 인스턴스가 동적 클러스터에 대해 시작되는 것에 대한 유익성의 정도를 표시하는 신호를 전송합니다.
언제 애플리케이션 배치 제어기가 서버를 중지합니까?
애플리케이션 배치 제어기는 다음의 이유로 서버를 중지합니다.
- 노드의 메모리 제한조건이 존재합니다. 애플리케이션 배치 제어기는 동적 클러스터에 대한 최소값 또는 해당 동적 클러스터 및 시스템의 프로세서 제한조건과 메모리 제한조건에 필요한 용량에 대해 이해합니다. 사용 가능한 메모리가 노드에서 낮게 되면 애플리케이션 배치 제어기는 노드가 스와핑되는 것을 계속 방지하도록 하기 위해 인스턴스를 중지하려고 시도합니다.
- 동적 클러스터가 애플리케이션 지연 시작을 위해 구성되고 선조치 유휴가 중지되면 동적 클러스터에 대한 요구가 존재하지 않습니다. 동적 클러스터에 요구가 없으면 애플리케이션 배치 제어기는 비활성 동적 클러스터의 자원 이용을 제거하기 위해 해당 클러스터의 인스턴스를 중지하려고 시도합니다.
애플리케이션 배치 제어기가 서버를 시작하지 못하는 이유는 무엇입니까?
애플리케이션 배치 제어기는 서버가 다음 이유 중 하나를 위해 시작된다는 것을 표시하지 않습니다.
- 구성은 동적 애플리케이션 배치를 사용으로 설정하지 않습니다.
- 배치 제어기가 사용되는지 확인하십시오. 관리 콘솔에서 를 클릭하십시오.
- 주제 클러스터 또는 클러스터가 동적 클러스터인지 확인하십시오. 애플리케이션 배치 제어기는 동적 클러스터에서만 작동합니다. 관리 콘솔에서 운영 모드 필드가 자동인지 검사하십시오. 그렇지 않다면, 동적 클러스터를 선택하고 자동을 클릭하십시오. 동적 클러스터에 대해 자동화를 선택한 후 설정 모드를 클릭하십시오. 를 클릭하십시오. 각각의 주제 클러스터에 대한
- 배치 변경 매개변수 사이에 구성된 최소 시간이 너무 높게 설정되지 않는다는 것을 확인하십시오. 관리 콘솔에서 배치 변경사항 사이의 최소 시간 필드의 값을 적당한 값으로 설정하십시오. 허용 가능한 값의 범위는 1분에서 24시간까지 입니다. 를 클릭하십시오.
- 서버 조작 제한시간 값이 너무 낮게 설정됩니다.
가끔 서버 운영의 제한시간이 초과되므로 애플리케이션 배치 제어기가 서버를 시작하지 않습니다. 제한시간이 관리 콘솔에서 발생하기 전에 시간의 양을 구성할 수 있습니다. 서버 운영 제한시간 필드를 편집하십시오. 셀이 크고, 사용자 시스템이 느리거나 시스템이 높은 워크로드 아래에 있다면 이 필드를 더 높은 값으로 설정하십시오. 이 값은 시작하려는 각 서버에 대한 시간의 양을 표시하지만, 제한시간이 셀에서 서버의 수를 기반으로 발생합니다. 예를 들어, 다섯 개의 서버가 있고 값을 10분으로 설정하면 50분 후 제한시간 초과가 발생합니다.
를 클릭하십시오. - 메모리 부족이 사용 가능합니다.
- SystemOut.log 파일에서 실패한 시작을 검토하여 메모리 부족이 사용 가능하게 될 때를 진단할 수 있습니다.
- 애플리케이션 배치 제어기는 동적 클러스터 멤버의 메모리 이용을 계산하기 위해 다음 식을 사용합니다.
- 어떤 다른 동적 클러스터 인스턴스가 실행 중인 경우(콜드 시작):
Server memory consumption = 1.2*maxHeapSize + 64 MB
- 기타 동적 클러스터 인스턴스가 실행되면 애플리케이션 배치 제어기 메모리 프로파일은 다음 식을 사용합니다.
Server memory consumption = .667*resident memory size + .333*virtual memory size
- 어떤 다른 동적 클러스터 인스턴스가 실행 중인 경우(콜드 시작):
- 메모리 프로파일은 애플리케이션 배치 제어기가 다시 시작될 때 지속되지 않습니다.
- PlacementControllerProcs.jacl 스크립트를 사용하여
실패한 서버 조작을 조회하십시오. 다음 명령을 실행하십시오.
./wsadmin.sh -profile PlacementControllerProcs.jacl -c "anyFailedServerOperations"
- wsadmin 도구에서 명령을 사용하여 실패한 시작을 표시하십시오. 예를 들어, 다음 명령을 실행할 수도 있습니다.
서버가 사용 가능하게 될 때, 시작 실패 플래그가 제거됩니다. 다음 wsadmin 도구 명령을 사용하여 시작 실패 플래그가 사용된 서버를 나열합니다.wsadmin>apc = AdminControl.queryNames('WebSphere:type=PlacementControllerMBean,process=dmgr,*') wsadmin>print AdminControl.invoke(apc,'anyFailedServerOperations')
wsadmin>print AdminControl.invoke(apc,'anyFailedServerOperations') OpsManTestCell/xdblade09b09/DC1_xdblade09b09
- SystemOut.log 파일에서 실패한 시작을 보십시오.
애플리케이션 배치 제어기가 예상했던 것보다 더 많은 서버를 시작한 이유는 무엇입니까?
네트워크 또는 통신 문제가 애플리케이션 배치 제어기가 서버가 시작되었다는 확인을 수신하지 못하게 할 때 예상보다 더 많은 서버가 시작될 수 있습니다. 애플리케이션 배치 제어기가 확인을 수신하지 않을 때 이는 추가 서버를 시작할 수 있습니다.
애플리케이션 배치 제어기가 동일한 서버를 시작하기 위해 여러 태스크를 제출하는 이유는 무엇입니까?
이 작동에 대한 이유는 애플리케이션 배치 제어기가 여러 서버에서 실행된다는 사실일 수 있습니다. 이 시나리오는 종종 혼합된 토폴로지에서 발생합니다. 여기서, WebSphere® Application Server 버전 8.5 셀에는 WebSphere Virtual Enterprise 버전 6.1.x 노드도 포함됩니다. 애플리케이션 배치 제어기는 WebSphere Application Server 버전 8.5 노드 및 WebSphere Virtual Enterprise 버전 6.1.x 노드 모두에서 실행됩니다. WebSphere Application Server 버전 8.5 및 WebSphere Virtual Enterprise 버전 6.1.x 노드는 기본적으로 다른 고가용성 솔루션을 사용합니다. 따라서, 여러 애플리케이션 배치 제어기가 실행 중입니다. 문제점을 수정하려면 배치 관리자에서 useBBSON.py 스크립트를 실행하고 셀을 다시 시작하십시오. 스크립트는 동일한 고가용성 솔루션이 셀 전반에 걸쳐 사용된다는 것과 단지 하나의 애플리케이션 배치 제어기가 시작되는지 확인하기 위해 셀 사용자 정의 특성을 설정합니다.
애플리케이션 배치 제어기가 완료된 시기 또는 조치를 완료할 시기를 아는 방법은 무엇입니까?
런타임 태스크로 애플리케이션 배치 제어기의 조치를 확인할 수 있습니다. 런타임 태스크를 보려면
를 클릭하십시오. 런타임 태스크의 목록에는 애플리케이션 배치 제어기가 완료 중인 태스크 및 변경사항이 작성된다는 확인이 포함됩니다. 각 런타임 태스크에 성공, 실패 또는 알 수 없는 상태가 있습니다. 알 수 없는 상태는 태스크의 성공 여부를 어떤 방법으로든 확인되지 않는 다는 것을 의미합니다.애플리케이션 배치 제어기가 VMware에 대해 작업하는 방법은 무엇입니까? 어느 하드웨어 가상화 환경이 지원됩니까?
애플리케이션 배치 제어기가 VMware 및 기타 하드웨어 가상화 환경에 대해 작업하는 방법에 대한 자세한 정보는 가상화와 지능형 관리 및 지원되는 서버 가상화 환경에 대해 읽으십시오.
어떻게 애플리케이션 배치 제어기를 방해하지 않고 서버를 시작하거나 중지할 수 있습니까?
동적 클러스터가 자동화 모드에 있는 동안 서버를 시작하거나 중지하면 애플리케이션 배치 제어기가 조치를 변경하기로 결정할 수도 있습니다. 서버를 시작하거나 중지할 때 애플리케이션 배치 제어기를 방해하는 것을 피하려면 동적 클러스터를 서버를 시작하거나 중지하기 전에 수동 모드에 두십시오.
이기종 시스템(혼합된 하드웨어 또는 운영 체제)에서 애플리케이션 배치 제어기가 서버를 시작할 위치를 선택하는 방법은 무엇입니까?
동적 클러스터에 대한 멤버십 정책은 서버가 시작될 수 있는 적합한 노드를 정의합니다. 노드의 이 설정에서, 애플리케이션 배치 제어기는 사용 가능한 프로세서 및 메모리 용량과 같은 시스템 제한조건을 고려하여 서버를 시작할 노드를 선택합니다. 애플리케이션 배치 제어기는 운영 체제를 기반으로 서버 배치를 판별하지 않습니다.
애플리케이션 배치 제어기가 다른 서버를 시작하는 시기와 동적 클러스터가 로드에 있는 시기는 언제입니까?
애플리케이션 배치 제어기는 서버를 시작할 시기를 편별하기 위해 ARFM(autonomic request flow manager) 및 정의된 서비스 정책에 대해 작업합니다. 서비스 정책은 애플리케이션을 위한 성능과 우선순위 최대를 설정했고, 자율적 제어기에게 트래픽 분산과 용량 프로비저닝 의사결정을 지도합니다. 서비스 정책 목적은 애플리케이션 배치 제어기에 의해 수행된 조치에 간접적으로 영향을 미칩니다. 애플리케이션 배치 제어기는 ARFM 큐에 의해 서비스되는 동시 요청 수에 필요한 용량에 대해 ARFM에서 정보를 기반으로 추가 서버를 프로비저닝합니다. 이 수는 서비스될 때 각 요청이 사용하는 용량 및 ARFM이 판별하는 적절한 동시 요청 수를 기반으로 판별됩니다. 동시 요청 수는 애플리케이션 우선순위, 목적 등을 기반으로 합니다.
서비스 정책에 의해 정의되는 성능 목적은 보증되지 않습니다. 지능형 관리 은 사용자 애플리케이션 응답을 해당 한계보다 더 빠르게 할 수 없습니다. 또한, 서비스 정책 목적이 위반된다고 해도 요구를 충족시키기 위해 충분한 용량이 이미 프로비저닝된 경우 추가 용량이 프로비저닝되지 않습니다. 지능형 관리 은 비현실적인 서비스 정책 목적이 불안정성을 환경에 소개하지 못하게 할 수 있습니다.
애플리케이션 배치 제어기가 서버의 최대 힙 크기를 판별하는 방법은 무엇입니까?
동적 클러스터 템플리트에서 서버의 힙 크기를 변경할 수 있습니다. 추가 정보는 JVM 힙 크기 수정에 대해 읽으십시오.
동적 클러스터 멤버가 템플리트에서 특성을 상속하지 않는 이유는 무엇입니까?
서버 템플리트를 변경하기 전에 마스터 저장소에 동적 클러스터를 저장해야 합니다. 템플리트에서 우선순위를 상속하지 않는 동적 클러스터 멤버가 있는 경우, 서버 템플리트는 저장되지 않은 작업공간에서 변경사항을 초래할 수 있습니다. 이 문제를 수정하려면 동적 클러스터를 삭제하고 이를 재작성하십시오.
변경사항을 마스터 저장소에 저장하십시오. 변경사항이 메시지 창에서 저장을 클릭하여 완료를 클릭한 이후 마스터 저장소에 저장되는 것을 확인할 수 있습니다. 마스터 monfiguration에 저장 창에서 저장을 다시 클릭하십시오. 노드로 변경사항 동기화를 클릭하십시오.
동적 클러스터에 활성 서버가 적은 이유는 무엇입니까?
- 노드 그룹의 노드가 많이 이용되지 않을 때, 서비스 정책이 충족되는지 확인하십시오. 가끔, 사용자의 예상은 아닐지라도 시스템이 예상을 충족시킬 수 있다고 해도 정책이 명확하게 정의되지 않을 수도 있습니다. 관리 콘솔에서 서비스 정책을 확인하거나 변경하려면 을 클릭하십시오. 목표 유형, 목표 값 및 정책의 중요성을 검사하고 필요한 변경도 수행하십시오.
- 노드 그룹의 노드가 많이 활용될 때, 이 클러스터의 서비스 정책 목표를 기타 활성 클러스터의 서비스 정책 목표와 비교하십시오. 이 클러스터에 속하는 트래픽에 기타 클러스터와 관련해 더 적은 중요성 또는 더 적은 대상 서비스 목표가 있는 경우, 시스템이 이 클러스터를 위한 더 적은 서버를 인스턴스화하는 것이 가능합니다. 관리 콘솔에서 서비스 정책을 확인하거나 변경하려면 을 클릭하십시오.
- 노드 그룹이 일부 추가 용량을 가지는 것처럼 보이지만 서비스 정책을 충족시키지 못할 때, 동적 클러스터에서 구성 설정을 확인하십시오. maxInstances 정책 설정의 결과로 작성된 동적 클러스터의 적은 인스턴스가 있을 수 있습니다.
동적 클러스터 환경에서 애플리케이션 배치 제어기가 노드를 통해 사용 가능한 서버를 분배하는 데 실패한 이유는 무엇입니까?
동적 애플리케이션 배치는 로드 분배, 서비스 정책 및 사용 가능한 자원을 기반으로 합니다. 동적 클러스터에서 애플리케이션 인스턴스의 최대 수를 감소시킬 때, 애플리케이션 배치 제어기는 서버 수가 설정 최대 값으로 감소될 때까지 가장 높은 작업 로드로 노드에서 서버를 중지합니다. 모든 노드가 사용 가능하면 애플리케이션 배치 제어기는 목록에서 첫 번째 노드를 선택하고 최대 수가 충족될 때까지 목록에서 다음 노드를 계속합니다.