워크로드 관리 |
BeenThere 샘플 구성 및 실행 |
시작하기 |
Application Server 노드 추가 |
웹 컨테이너 클러스터 작성 |
EJB 컨테이너 클러스터 작성 |
가상 호스트 갱신 |
WebSphere 구성 서비스 사용 |
BeenThere.ear 파일 설치 |
보안 구성(선택적) |
서버 시작 |
샘플 실행 |
샘플 구성 검증 |
이 섹션은 그림 1에 나타낸 대로 환경을 구성하고 BeenThere 샘플을 설치 및 실행하기 위한 단계를 설명합니다. 이는 다음 소프트웨어가 이미 설치되었다고 가정합니다.
시스템 이름 | 설치되는 소프트웨어 |
web |
IBM HTTP Server IBM HTTP Server 플러그인 |
app1 | IBM WebSphere Application Server |
app2 | IBM WebSphere Application Server |
dm | IBM WebSphere Application Server Deployment Manager |
참고:다음 지시사항은 웹 서버와 웹 서버의 관리 서버가 실행 중이며 웹 서버 정의가 plugin-cfg.xml 파일을 자동으로 전달하도록 Deployment Manager에 작성되었다고 가정합니다.
셀에 Application Server 노드를 추가하려면 다음 단계를 완료하십시오.
addNode <deploymgr host>
addNode.sh <deploymgr host>
install_root/bin/addNode <deploymgr host> <deploymgr port> -profileName <profileName> -startingport <portblock>
이제 Application Server는 셀에 통합되었습니다.
MyWebCluster 클러스터는 Servlet에 대한 실패복구 및 워크로드 밸런싱을 제공합니다.
MyWebCluster 클러스터를 작성하려면 다음 단계를 완료하십시오.
이제 MyWebCluster 클러스터가 작성되었습니다.
MyEJBCluster 클러스터는 엔터프라이즈 Bean에 대한 실패복구 및 워크로드 밸런싱을 제공합니다.
MyEJBCluster 클러스터를 작성하려면 다음 단계를 완료하십시오.
참고:분산 플랫폼에서는 선호 로컬 옵션을 선택하면 사용 가능한 경우, 요청이 로컬 노드에서 실행 중인 엔터프라이즈 Bean에 라우트되었는지를 표시합니다. 선호 로컬 옵션은 EJB 요청의 워크로드 관리를 보여주는 샘플 구성에서 사용 불가능합니다.
이제 MyEJBCluster 클러스터가 작성되었습니다.
MyWebCluster 클러스터 작성 중에, 고유 HTTP 포트 생성 옵션이 새로운 각 클러스터 구성원에 대해 선택됩니다. 이 옵션을 선택하면 작성된 새로운 각 Application Server에 대해 고유한 포트 값을 작성하여 HTTP 포트 충돌을 피할 수 있습니다.
동적으로 작성되는 각 HTTP 포트 값이 default_host 가상 호스트에 구성된 연관 호스트 별명 항목을 가지고 있는지 확인하십시오.
이제 가상 호스트가 갱신되었습니다.
WebSphere 구성 서비스는 기본적으로 Application Server에 사용 가능하지 않습니다. 환경 정보를 얻기 위해 WebSphere Application Server 구성 파일을 프로그래밍 방식으로 읽는 이 서비스가 샘플에 필요합니다.
WebSphere 구성 서비스를 사용 가능하게 하려면 다음 단계를 완료하십시오.
이제 WebSphere 구성 서비스가 사용 가능합니다.
BeenThere.ear 파일을 설치하려면 다음 단계를 완료하십시오.
BeenThere를 보안과 함께 사용하지 않으려면 이 섹션을 생략하십시오. BeenThere를 보안과 함께 사용하려면, 여기를 클릭하여 보안 구성에 대한 지시사항을 참조하십시오.
서버를 시작하려면 다음 단계를 완료하십시오.
이제 서버가 시작되었습니다.
샘플을 실행하려면, 브라우저에서 BeenThere 웹 주소(http://<host_name>/wlm/BeenThere)를 여십시오. 여기서, <host_name>은 IBM HTTP Server가 실행 중인 IP 주소 또는 호스트 이름입니다.
WebSphere 버전 6 이상에는 전체 환경의 처리량을 최대화하도록 설계된 새 기능이 존재합니다. 이는 궁극적으로 이러한 서버에서 BeenThere 샘플 테스트 시 워크로드 관리 컴포넌트는 요청을 정확한 가중치 값으로 엄격하게 라우트하지 않을 수 있음을 의미합니다. 가중치는 런타임 시 수정될 수 있으므로 아래의 확인 메소드가 잘못될 수 있습니다. 이러한 시나리오에서 WLM 기능을 확인하는 최적의 메소드는 라우팅이 가중치에 따라 엄격하게 수행되는지 여부와 관계없이 요청이 모든 클러스터 구성원으로 라우트되고 있는지 확인하는 것입니다. 이러한 피드백 메커니즘을 사용 불가능으로 설정하는 메소드도 있습니다. 이 메소드가 필요할 경우 IBM 지원 센터에 문의하여 자세한 내용을 확인하십시오.
웹 컨테이너 워크로드 관리가 구성한 대로 제대로 작동 중인지 검증하려면 다음 단계를 완료하십시오.
브라우저에서 BeenThere 웹 주소(http://<host_name>/wlm/BeenThere)를 여십시오. 여기서, <host_name>은 IBM HTTP Server가 실행 중인 IP 주소 또는 호스트 이름입니다.
다음 예에서 설명한 대로 Servlet의 값이 요약 변경을 실행합니다.
이제 Servlet 노드는 app1 대신 app2입니다. 결과는 IBM HTTP Server가 MyWebCluster 클러스터의 다른 구성원에게 HTTP 요청을 디스패치한 것을 표시합니다(즉, app2에 있는 WebServer2). Servlet의 반복되는 실행은 MyWebCluster 클러스터의 클러스터 구성원을 위해 구성된 가중치 값을 기반으로 하는 HTTP 요청의 워크로드 관리 작동을 나타냅니다.
이제 웹 컨테이너 워크로드 관리 구성이 검증되었습니다.
EJB 컨테이너 워크로드 관리가 구성한 대로 제대로 작동 중인지 검증하려면 다음 단계를 완료하십시오.
분산 플랫폼의 경우, Bean 실행 요약의 값은 다음 예와 유사해야 합니다.
이 예에서, 워크로드 관리는 MyEJBCluster 클러스터의 클러스터 구성원을 위해 구성된 가중치 값을 기반으로 하는 엔터프라이즈 Bean의 작동을 실행합니다. 모든 단일 호출의 app2에서 실행되는 엔터프라이즈 Bean의 세 가지 호출은 app1에서 실행됩니다.
z/OS 플랫폼의 경우, 가중치 값은 HTTP 요청을 조절하는 데 사용되지만 IIOP(Internet Inter-ORB Protocol) 요청을 조절하는 데 사용되지는 않습니다.
이제 EJB 컨테이너 워크로드 관리 구성이 검증되었습니다.
Bean 클러스터의 구성원 가중치가 구성한 대로 제대로 설정되었는지 검증하려면 다음 단계를 완료하십시오.
결과를 다음 예와 비교하십시오.
결과는 MyEJBCluster 클러스터의 모든 구성원에 대한 가중치 값을 표시합니다. EJBServer1은 1의 가중치를 가지고, EJBServer2는 3의 가중치를 가지고 있습니다.
이제 Bean 클러스터 구성원 가중치가 검증되었습니다.
축하합니다. 이제 조치에 워크로드 관리가 나타나며 BeenThere 샘플이 구성한 대로 제대로 작동 중인지 검증되었습니다!