워크로드 관리 컴포넌트 문제점 해결 팁

워크로드 관리 컴포넌트가 다중 노드 구성의 서버 간에 워크로드를 적절하게 분배하지 않는 경우에는 다음 옵션을 사용하여 문제점을 분리하십시오.

참고: 이 주제는 하나 이상의 애플리케이션 서버 로그 파일을 참조합니다. 권장되는 대안은 분배 및 IBM® i 시스템에서 SystemOut.log, SystemErr.log, trace.logactivity.log 파일을 사용하는 대신 HPEL(High Performance Extensible Logging) 로그를 사용하고 인프라를 추적하도록 서버를 구성하는 것입니다. 원시 z/OS® 로깅 기능과 연계하여 HPEL을 사용할 수도 있습니다. HPEL을 사용하는 경우 서버 프로파일 바이너리 디렉토리의 LogViewer 명령행 도구를 사용하여 모든 로그에 액세스하고 정보를 추적할 수 있습니다. HPEL 사용에 대한 자세한 정보는 HPEL을 사용한 애플리케이션 문제점 해결 정보를 참조하십시오.

환경 또는 구성 문제 제거

서버가 사용으로 설정된 애플리케이션에 대해 작동하는지 판별하십시오. 문제점이 있는 클러스터를 식별하십시오.
  • 클러스터 또는 관리 서버의 멤버(예: 배치 관리자 또는 노드 에이전트)에 네트워크 연결 문제점이 있습니까?
    • 문제점이 있는 경우에는 ping을 실행하여 네트워크에 적절하게 연결되었는지 확인하십시오.
  • 서버가 설치된 시스템에서, 요청을 처리하는 서버 기능에 영향을 주는 다른 활동이 있습니까? 예를 들면, 태스크 관리자, 프로세서 ID 또는 기타 외부 도구에 의해 측정된 프로세서 사용량을 검사하여 다음 사항을 확인하십시오.
    • 예상한 수치와 다르거나, 일정하지 않고 심하게 변동합니다.
    • 새로 추가되거나 설치 또는 업그레이드된 클러스터 멤버가 사용되고 있지 않음을 표시합니다.
  • 각 노드에서 시작한 모든 애플리케이션 서버가 실행 중입니까? 아니면 일부가 중지되었습니까?
  • 애플리케이션이 설치되어 작동하고 있습니까?
  • 문제점이 CMP(Container-Managed Persistence) 또는 BMP(Bean-Managed Persistence) 엔터프라이즈 Bean 간의 워크로드 분배와 관련된 경우, 각 서버에 지원 JDBC 제공자 및 JDBC 데이터 소스를 구성하였습니까?

클러스터의 일부 멤버가 HTTP 요청을 처리하지 않는 등과 같은 HTTP 요청과 관련된 워크로드 관리 문제점이 발생한 경우, HTTP 플러그인은 선호도가 설정되지 않으면 PrimaryServers 목록에 정의된 모든 서버 간에 로드 밸런싱을 수행한다는 점을 참고하십시오. 정의된 PrimaryServers 목록이 없는 경우 플러그인은 선호도가 설정되지 않으면 클러스터에 정의된 모든 서버 간에 로드 밸런싱을 수행합니다. 선호도가 설정된 경우 플러그인은 모든 요청에 대해 바로 해당 서버와 연결되어 처리를 수행합니다.

클러스터의 일부 멤버가 엔터프라이즈 Bean 요청을 처리하지 않는 등과 같은 엔터프라이즈 Bean 요청과 관련된 워크로드 관리 문제점이 발생하는 경우에는 다음 항목을 확인하십시오.
  • 가중치가 허용된 값으로 설정되어 있습니까?
    • 문제가 되는 클러스터에 대해, 관리 콘솔에 로그온하여 다음 작업을 수행하십시오.
      1. 서버 > 클러스터 > WebSphere 애플리케이션 서버 클러스터를 선택하십시오.
      2. 목록에서 클러스터를 선택하십시오.
      3. 클러스터 멤버를 선택하십시오.
      4. 클러스터의 각 서버에 대해 server_name을 클릭하고 서버의 지정된 가중치를 살펴보십시오.
    • 가중치가 유효 범위인 0 - 20 내에 있는지 확인하십시오. 서버의 가중치가 0인 경우에는 요청이 이 서버로 라우팅되지 않습니다. 20보다 큰 가중치는 0으로 취급됩니다.

이 문서의 나머지 내용에서는 엔터프라이즈 Bean 워크로드 밸런싱만을 다룹니다. 웹(HTTP) 요청 분배의 문제점을 진단하는 데 대한 추가 도움말을 보려면 "웹 서버 플러그인 문제점 해결 팁""웹 자원이 표시되지 않음" 주제를 보십시오.

[IBM i][AIX Solaris HP-UX Linux Windows]

WLM 오류 및 CORBA 부 코드에 대한 로그 파일 찾아보기

여전히 엔터프라이즈 Bean 워크로드 관리에 문제점이 발생하는 경우, 다음 단계는 다음 항목을 나타내는 활동 로그를 확인하는 것입니다.
  • 두 번 이상 사용 불가능으로 표시되었으며 사용 불가능 상태로 남아 있는 서버.
  • 클러스터의 모든 서버가 잘못됨 상태로 표시되고 사용 불가능 상태로 남아있습니다.
  • [z/OS]위치 서비스 디먼(LSD)이 두 번 이상 사용 불가능으로 표시되었으며 사용 불가능 상태로 남아있습니다.

[IBM i][AIX Solaris HP-UX Linux Windows]이를 수행하려면 로그 및 추적 분석기를 사용하여 영향을 받은 서버의 서비스 로그(activity.log)를 열고 다음 항목을 찾아보십시오.

[z/OS]이를 수행하려면 영향을 받은 서버의 서비스 로그를 열고 다음 항목을 찾아보십시오.

  • WWLM0061W: 클러스터 멤버 member에 요청을 전송하는 중 오류가 발생했으며 해당 멤버가 클러스터 cluster에 대한 이후 요청에 대해 사용 불가능으로 표시되었습니다.
    참고: 서버가 사용 불가능으로 표시되는 것은 흔치 않습니다. 이 서버는 클라이언트의 로드가 서버에 남아있는 상태에서 중지 후 시작이 실행되는 것과 같은 정상 작동 이유로 사용 불가능으로 태그 지정되었을 수 있습니다. 하나의 멤버에 대해 거의 동시에 다수의 WWLM0061W 경고 메시지를 받는 것도 정상입니다. 일반적으로 다수의 스레드에 처리 중인 요청이 있으며, 멤버가 사용 불가능으로 표시되면 해당 멤버를 대상으로 하는 스레드가 그러한 경고 메시지를 받을 가능성이 있습니다.
  • WWLM0062W: 클러스터 멤버 member에 요청을 전송하는 중 오류가 발생했으며 해당 멤버가 클러스터 cluster에 대한 이후 요청에 대해 두 번 이상 사용 불가능으로 표시되었습니다.
  • WWLM0063W: LSD LSD_name을(를) 사용하여 클러스터 cluster의 오브젝트 참조를 분석하는 중 오류가 발생했으며 해당 클러스터에 대한 이후 요청에 대해 사용 불가능으로 표시되었습니다.
  • WWLM0064W: 클러스터 cluster의 모든 멤버에 요청을 전송하는 중 오류가 발생되고 모든 멤버가 해당 클러스터에 대한 이후 요청에 대해 사용 불가능으로 표시되었습니다.
  • WWLM0065W: 배치 관리자에서 클러스터 cluster에 있는 클러스터 멤버 server에 접근할 수 없어 이를 업데이트하는 중에 오류가 발생했습니다.
  • WWLM0067W: 클라이언트가 요청을 재시도하라는 신호를 받았습니다. 예외 {0}(으)로 인해 WLM이 서버 요청을 투명하게 재시도할 수 없습니다.

    요청을 서비스하려는 중에 WLM에서 요청을 투명하게 다시 제출할 수 없도록 하는 상태가 발생했습니다. 근본적인 예외가 발견되었으며 부 코드인 0x49421042(SERVER_SIGNAL_RETRY)와 함께 새 CORBA.TRANSIENT가 클라이언트로 전송되었습니다.

이러한 경고가 발생한 경우에는 로그에 지정된 사용자 응답을 따르십시오. 사용자 응답을 따른 후에도 경고가 지속되면 영향을 받은 서버의 로그 및 추적 분석기에서 기타 오류 및 경고를 살펴 다음 항목을 찾으십시오.
  • 구성 설정 변경과 같은 가능한 사용자 응답.
  • 제품 결함을 나타낼 가능성이 있는 기본 클래스 예외.

WLM은 프로세스 간 통신을 위해 CORBA(Common Object Request Broker Architecture)를 사용하므로 예외 이름의 부분에 "CORBA"가 있는 예외를 볼 수 있습니다. 예외 스택에서 "부 코드"를 지정하는 명령문을 찾으십시오. 이러한 코드는 CORBA 호출 또는 응답을 완료하지 못한 특정 이유를 나타냅니다. WLM 부 코드는 0x4921040 - 0x492104F 범위에 속합니다. WLM과 관련된 부 코드에 대한 설명은 패키지 및 클래스 com.ibm.websphere.wlm.WsCorbaMinorCodes에 대한 주제 "참조: 생성된 API 문서"를 참조하십시오.

[IBM i][AIX Solaris HP-UX Linux Windows]

PMI 데이터 분석

PMI 데이터를 분석하는 목적은 클러스터의 각 멤버에 도착하는 워크로드를 파악하기 위한 것입니다. 클러스터의 한 멤버에 대한 데이터는 클러스터의 모든 멤버에 대한 데이터의 컨텍스트 내에서만 유용합니다.

Tivoli® Performance Viewer를 사용하여, 각 서버가 클러스터 멤버에 지정된 가중치(안정 상태 가중치)에 따라 올바른 비율로 요청을 받고 있는지 확인하십시오.

Tivoli Performance Viewer를 사용하여 PMI 매트릭을 캡처하려면 Tivoli Performance Viewer 제품 탐색에서 다음 조치를 완료하십시오.
  1. 트리 보기에서 데이터 콜렉션을 선택하십시오. PMI가 사용으로 설정되지 않은 않은 서버는 회색으로 표시됩니다.
  2. 데이터를 수집할 각 서버에 대해 지정...을 클릭하십시오.
  3. 이제 매트릭을 사용으로 설정할 수 있습니다. 성능 모니터링 설정 패널에서 모니터링 레벨을 낮음으로 설정하십시오.
  4. 확인을 클릭하십시오.
  5. 변경사항을 저장하려면 적용을 눌러야 합니다.

WLM PMI 메트릭스는 서버에서 서버별로 볼 수 있습니다. Tivoli Performance Viewer에서 노드 > 서버 > 워크로드 관리 > 서버/클라이언트를 선택하십시오. 기본적으로 데이터는 10초마다 수집되어 집계 숫자로서 표에 원시 양식으로 표시됩니다. 또한 데이터를 델타 또는 비율로서 보거나, 열을 추가 또는 제거하거나, 버퍼를 지우거나, 메트릭을 0으로 재설정하거나, 콜렉션 비율 및 버퍼 크기를 변경할 수 있습니다.

PMI 데이터를 얻은 후에는 모든 클러스터 멤버의 numIncomingRequests 총계에 대한 클러스터 각 멤버의 numIncomingRequests 백분율을 계산해야 합니다. 이 백분율 값과 클러스터의 각 멤버에 지정된 가중치의 백분율을 비교하면 클러스터의 각 멤버에 분배된 워크로드의 밸런싱 상태를 알 수 있습니다.

numIncomingRequests 외에도 두 개의 다른 매트릭(numincomingStrongAffinityRequests 및 numIncomingNonWLMObjectRequests)이 클러스터 멤버 간의 작업 밸런싱 상태를 표시합니다. 이 두 매트릭스는 클러스터의 특정 멤버만이 서비스할 수 있는, 해당 멤버에 분배된 요청 수를 표시합니다.

예를 들면, 서버가 세 개인 클러스터가 있습니다. 이 세 서버 각각에 다음 가중치가 지정되었습니다.
  • Server1 = 5
  • Server2 = 3
  • Server3 = 2
서버 클러스터가 요청에 대한 서비스를 시작하도록 하고, 시스템이 안정 상태(클러스터의 수신 요청 수가 서버의 응답 수와 같은 상태)에 도달할 때까지 기다리십시오. 이와 같은 상황에서 각 서버에 라우팅된 요청의 백분율은 다음과 같이 예상됩니다.
  • Server1로 라우팅되는 % = weight1 / (weight1 + weight2 + weight3) = 5/10 또는 50%
  • Server2로 라우팅되는 % = weight2 / (weight1 + weight2 + weight3) = 3/10 또는 30%
  • Server3으로 라우팅되는 % = weight3 / (weight1 + weight2 + weight3) = 2/10 또는 20%

이제 비 WLM 오브젝트 요청도 없고 선호도도 강력하지 않은, 수신 요청이 없는 경우를 생각해 보십시오.

이 시나리오에서, 수집된 PMI 매트릭이 각 서버의 수신 요청 수를 다음과 같이 나타내고 있다고 가정합니다.
  • numIncomingRequestsServer1 = 390
  • numIncomingRequestsServer2 = 237
  • numIncomingRequestsServer3 = 157

따라서, 클러스터에 수신된 요청의 총 수: numIncomingRequestsCluster = numIncomingRequestsServer1 + numIncomingRequestsServer2 + numIncomingRequestsServer3 = 784

numincomingStrongAffinityRequests = 0

numIncomingNonWLMObjectRequests = 0

이 데이터를 기반으로 WLM이 클러스터 내의 서버 간에 수신 요청의 적절한 밸런싱을 수행하고 있다고 판단할 수 있습니까? 선호도가 강력한 요청이 없으므로 여기서 응답해야 하는 질문은 '지정된 가중치에 따라 예상한 비율로 요청이 분배되었는가?'입니다. 이 질문에 응답하기 위한 계산 결과는 분명합니다.
  • Server1에 라우팅된 실제 % = 390 / 784 = 49.8%
  • Server2에 라우팅된 실제 % = 237 / 784 = 30.2%
  • Server3에 라우팅된 실제 % = 157 / 784 = 20.0%
데이터가 서버에 지정된 가중치에 따라 예상한 바와 완전히 일치하므로, WLM은 설계대로 작동하고 있습니다.
이제 서버가 세 개인 다른 클러스터를 가정해 보십시오. 이 세 서버 각각에 다음 가중치가 지정되었습니다.
  • Server1 = 5
  • Server2 = 3
  • Server3 = 2
이 서버 클러스터가 요청에 대한 서비스를 시작하도록 하고, 시스템이 안정 상태(클러스터의 수신 요청 수가 서버의 응답 수와 같은 상태)에 도달할 때까지 기다리십시오. 이와 같은 상황에서 Server1 - 3에 라우팅되는 요청의 백분율은 다음과 같이 예상됩니다.
  • Server1로 라우팅되는 % = weight1 / (weight1 + weight2 + weight3) = 요청의 5/15 또는 1/3.
  • Server2로 라우팅되는 % = weight2 / (weight1 + weight2 + weight3) = 요청의 5/15 또는 1/3.
  • Server3으로 라우팅되는 % = weight3 / (weight1 + weight2 + weight3) = 요청의 5/15 또는 1/3.
이 시나리오에서, 수집된 PMI 매트릭이 각 서버의 수신 요청 수를 다음과 같이 나타내고 있다고 가정합니다.
  • numIncomingRequestsServer1 = 1236
  • numIncomingRequestsServer2 = 1225
  • numIncomingRequestsServer3 = 1230
따라서 클러스터에 들어오는 요청 수의 총계는 다음과 같습니다.
  • numIncomingRequestsCluster = numIncomingRequestsServer1 + numIncomingRequestsServer2 + numIncomingRequestsServer3 = 3691
  • numincomingStrongAffinityRequests = 445이고 445개의 모든 요청은 Server1을 목표로 합니다.
  • numIncomingNonWLMObjectRequests = 0.
이 경우 요청의 수가 예상대로 세 개의 서버에 균일하게 분배되지 않는 것을 알 수 있습니다. 대신 다음과 같이 분배됩니다.
  • Server1에 라우팅된 실제 % = 1236 / 3691= 33.49%
  • Server2에 라우팅된 실제 % = 1225 / 3691= 33.19%
  • Server3에 라우팅된 실제 % = 1230 / 3691 = 33.32%

그러나 Server1에 수백 개의 강력한 선호도 요청이 있으므로, 이 데이터에 대한 올바른 해석은 요청이 완벽하게 밸런싱되고 있지 않다는 것입니다. WLM은 트랜잭션에 참여하고 있는 서버를 보정하기 위해 트랜잭션 선호도에 참여하고 있지 않은 서버에 새 수신 요청을 우선 분배함으로써, 하나 이상의 서버에 지정된 강력한 선호도 요청을 보정하려 합니다. 강력한 선호도 및 비 WLM 오브젝트 요청이 있는 수신 요청의 경우에는 분석 값이 이 경우와 유사합니다.

PMI 데이터를 분석하고 트랜잭션 선호도 및 비WLM 오브젝트 요청을 고려했으나 클러스터 내의 서버에 대한 실제 수신 요청의 백분율이 지정된 가중치를 반영하지 않는 경우, 이는 요청이 적절하게 밸런싱되고 있지 않음을 나타냅니다. 이런 경우 환경과 구성 문제를 제거하고 처리하기 전에 로그 파일을 찾아보는 단계를 반복하는 것이 좋습니다.

문제점 해결 또는 IBM 지원 센터에 문의

[IBM i][AIX Solaris HP-UX Linux Windows]PMI 데이터 또는 클라이언트 로그에서 WLM에 오류가 있음을 나타내는 경우에는 다음 정보를 수집하여 IBM 지원 샌터에 문의하십시오.

클라이언트 로그에서 WLM에 오류가 있음을 나타내는 경우에는 다음 정보를 수집하여 IBM 지원 샌터에 문의하십시오.

  • 환경에 대한 자세한 설명
  • 증상에 대한 설명
  • [IBM i][AIX Solaris HP-UX Linux Windows]클러스터의 모든 서버에 대한 SystemOut.logs 및 SystemErr.logs 파일
  • [z/OS]클러스터의 모든 서버에 대한 서버 로그 파일
  • [IBM i][AIX Solaris HP-UX Linux Windows]activity.log 파일
  • [IBM i][AIX Solaris HP-UX Linux Windows]첫 번째 장애 데이터 캡처 로그 파일
  • [IBM i][AIX Solaris HP-UX Linux Windows]PMI 매트릭
  • 클라이언트가 수행하려고 하는 작업과 해당 클라이언트에 대한 설명(예: 단일 스레드, 다중 스레드, 서블릿, J2EE 클라이언트 등)

이러한 단계를 모두 수행해도 문제점을 해결할 수 없는 경우에는 "문제점 진단 및 수정: 학습 자원" 주제에 있는 링크를 사용하여 이 문제점이 식별되어 문서화되었는지 확인하십시오. 사용자의 경우와 유사한 문제점이 없거나 제공된 정보로 문제점이 해결되지 않는 경우에는 IBM 지원 센터에 문의하여 추가 도움을 요청하십시오.

[AIX Solaris HP-UX Linux Windows][z/OS]그곳에 사용자의 문제점이 나열되어 있지 않은 경우에는 IBM 지원 센터에 문의하십시오.

[AIX Solaris HP-UX Linux Windows]알려진 문제점 및 해결 방법에 대해 IBM 지원 센터에서 현재 사용 가능한 정보는 IBM 지원 센터 페이지를 참조하십시오. 또한 이 페이지에는 문제점 해결에 필요한 정보를 수집하는 시간을 줄일 수 있는 문서가 포함되어 있으므로 PMR을 작성하기 전에도 이 페이지를 참조해야 합니다.

[IBM i]알려진 문제점 및 해결 방법에 대해 IBM 지원 센터에서 현재 사용 가능한 정보는 IBM i 소프트웨어 페이지를 참조하십시오. 또한 이 페이지에는 문제점에 대해 도움을 받기 위해 수집하여 IBM에 보내야 하는 문서에 대한 정보가 포함되어 있으므로 PMR을 작성하기 전에도 이 페이지를 참조해야 합니다.


주제 유형을 표시하는 아이콘 참조 주제



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