EWLM을 사용하여 파티션 관리하기, Part 2: 파티션 관리 (한글)

문서 옵션 JavaScript가 필요한 문서 옵션은 디스플레이되지 않습니다.  제안 및 의견 피드백

난이도 : 중급

CheKim Chhuor, System Verification Tester, IBM

2006 년 11 월 29 일

IBM System p5 서버의 AIX®와 Linux® 파티션들에 지능적 관리를 수행하여, IBM® Enterprise Workload Manager를 통해 모은 퍼포먼스 데이터들을 활용해 봅시다. 이 테스트 환경의 토폴로지와 사용되는 워크로드를 조사하고, 도메인 정책에 대해 알아봅니다. 워크로드를 실행하고 EWLM의 파티션 관리 액션을 관찰합니다.

EWLM을 사용하여 파티션 관리하기 (한글) Part 1에서는, EWLM을 사용하기 위해 필요한 하드웨어 및 소프트웨어에 대해 알아보았다. HMC에 파티션을 설정하는 방법(프로세싱 모드, 프로세싱 단위, 가상 프로세서, 공유 모드 설정), 워크로드 그룹을 파티션 하는 방법, 공유 프로세서 풀 권한을 할당하는 방법을 설명했고, 파티션 관리의 흐름, 글로벌/로컬 퍼포먼스 인덱스, 도움 요청, 평가 방법 등을 통해 EWLM 파티션 관리 알고리즘을 분석했다.

규칙과 이론에 대해서는 설명했으니, 이제는 실제 워크로드에 EWLM 파티션 관리가 어떤 결과를 나타내는지를 설명하겠다. 파티셔닝 환경에 사용할 수 있는 AIX와 리눅스용 툴도 소개할 것이다.

파티션 관리

먼저, 내 테스트 환경의 토폴로지와 워크로드를 설명하겠다. 그런 다음, 도메인 정책에 대해 설명하고, 워크로드를 실행하여, EWLM이 파티션 관리를 어떻게 수행하는지 관찰할 것이다.

토폴로지

내 테스트 환경은 p570 서버이다. 여기에 여덟 개의 프로세서가 있고, Hardware Management Console (HMC)에서 관리된다. 총 여덟 개의 파티션이 있고, 이 중에서 네 개를 데모용으로 사용한다. 나머지는 다른 작업을 실행할 때 사용된다. 미들웨어 설정은, 같은 노드에서 실행되는 IBM HTTP Server (IHS)와 WebSphere® Application Server (Application Server) 서버를 가진 단순한 3-티어 토폴로지이며, 모두 uncapped 파티션인 일반 데이터베이스 서버를 가리키고 있다. 같은 네트워크 세그먼트에 있는 외부 PC는 로드 생성에 JMeter를 실행하는데 사용된다. (그림 1)

실제 실행 환경은 내 테스트 환경 보다 더 많은 노드가 있을 것이지만, “너무나 많은” 머신들에서 발생하는 작업들을 따라잡기란 쉬운 일이 아니다. 따라서, 테스트 환경을 작고 단순하게 유지하려고 한다.

워크로드

평상시처럼, 워크로드로서 IBM Trade Performance Benchmark 애플리케이션을 사용할 것이다. (참고자료) 이 애플리케이션은 많은 내부/외부 벤치마크에 사용될 수 있는 애플리케이션이다. 사용자들이 주식을 매매하고 포트폴리오를 쿼리 할 수 있는 웹 인터페이스를 갖고 있다. 이 데모를 위해, 다음 세 개의 서블릿을 사용할 것이다. 이것은 세 개의 트랜잭션 클래스로 매핑되고, 세 개의 서비스 클래스로 매핑된다.

이러한 서블릿을 사용하는 것이, 실제 사용자의 인터랙션을 시뮬레이션 하는 스크립트를 기록하는 것 보다 간단하다. 이 경우, 세 개의 개별 서버들로 보낼 세 개의 작업 클래스가 필요하다. 첫 번째 서블릿은 경량이고, 두 번째 서블릿은 Application Server 노드에 소량의 부하량을 주며, 세 번째 서블릿은 Application Server 노드와 DB2® 노드에 매우 무거운 부하량을 준다.

도메인 정책 정의하기

이 워크로드에 대한 도메인 정책을 만드는 것 역시 쉽다. 정책 에디터 위자드를 사용하여 세 개의 서비스 클래스를 만들면서 퍼포먼스 목표를 설정했다. 그런 다음, 애플리케이션을 정책에 추가했고, 이는 이 트랜잭션의 엔트리 애플리케이션이 된다. (이 경우, IBM Webserving Plugin). 다음에는, 세 개의 트랜잭션 클래스를 만들었는데, 각각의 서비스 클래스에 속해있다. 규칙을 적용하는 하는 트랜잭션 클래스는 아주 간단하다:

EWLM:URI == "/trade/servlet/PingJDBCRead"
EWLM:URI == "/trade/servlet/PingServlet2Session2Entity"
EWLM:URI == "/trade/scenario"

마지막으로, 정책을 저장한 다음, 이를 전개하여 실행했다. 그림 2는 Service classes 패널에 나타난 모습이다.

여러분의 하드웨어와 소프트웨어는 어쩌면 나와는 다른 응답 시간을 나타냈을 것이다. 따라서, 퍼포먼스 목표는 각자의 환경에 따라 다르다. 여러분의 정책에서 서비스 클래스의 퍼포먼스 목표를 수정하고 싶을 경우, Service classes 단계에서 이를 편집할 수 없다. 대신, 정책 에디터 위자드에서 Service policies 단계를 사용하라.

워크로드 실행하기

워크로드를 시작하기 전에, 나의 파티션 워크로드 그룹의 초기 상태를 보자. (그림 3) 그림 1에 나타난 설정을 반영하고 있다. 다음 과정을 통해 볼 수 있다:

1. Partitions 패널을 검색한다.
2. 파티션 그룹을 선택한다.
3. 드롭-다운 리스트에서 Details를 선택한다.
4. Go를 클릭한다.

Processor utilization 칼럼은 이 파티션에서 사용되는 전체 공유 프로세서 풀의 백분율이다.

처음에는 200개의 동시 JMeter 쓰레드(500ms 슬립(sleep) 사이클)를 가진 bronze워크로드로 시작하여, 400개 쓰레드의 silver 워크로드, 마지막에는 75 쓰레드(1sec 슬립 사이클)를 가진 gold 워크로드를 시작했다. Domain Settings > EWLM management 패널에서 EWLM 파티션 관리를 실행 불가로 한다. 이것이 어떻게 작동하는지, 그리고 EWLM이 워크로드의 퍼포먼스를 높이는데 얼마만큼의 기여를 하는지도 알게 될 것이다.

이제, 그림 4의 가장 중요한 워크로드의 퍼포먼스 모니터를 보자. 퍼포먼스 목표에 약간 못 미쳤다. 평균 응답 시간은 약 250ms인데, 목표는 200ms로 설정되었다. (노란색 점) 그렇게 나쁜 결과는 아니다.

그림 5는 모든 서비스 클래스들의 실제 응답 시간이다. 모두, 기대했던 응답 시간 보다 약간 느리게 실행되고 있지만, 그렇게 큰 차이는 없다.

환경이 안정화 될 때까지, 수 분을 기다린 후에, EWLM 파티션 관리를 실행한다. EWLM이 통계에 기반하여, 모든 파티션들에 여러 가지 조정을 마치기까지 (내 경우) 5분이 소요된다. 그림 6은 가장 중요한 워크로드의 퍼포먼스 모습이다. 퍼포먼스 목표치에 미치지 못하지만, 매우 좋은 편이다.

다른 서비스 클래스는 어떤지 보자. 그림 7에서, EWLM이 Silver 서비스 클래스는 아주 잘 관리했지만, Bronze 서비스 클래스는 결과가 매우 좋지 않다.

실제 파티션 워크로드 그룹 상세들을 보면서, 각 파티션 기능에 EWLM이 어떤 작용을 했는지를 보자. (그림 8)

EWLM은 hcp122와 hci246의 용량을 두 개의 다른 파티션들로 분산한다. hcp122 파티션은 너무 작아서, 어떤 트랜잭션도 처리할 수 없다. hci246의 uncapped 가중치는 현재 할당 용량에 비례하여 조정되었다.

교훈

이것은 고도로 튜닝 된 데모라는 점을 알아야 한다. 모든 시나리오에서 이와 같은 긍정적이고 명확한 결과를 얻을 수 있는 것은 아니다. 사실, 파티션 관리를 계속 실행 상태로 했다면, EWLM이 실제로 얼마나 기여를 했는지 정확히 알 수 없었을 것이다. 막후에서, 지속적으로 작동하여 문제가 있는 서비스 클래스를 도왔을 것이기 때문이다. 여러분도 이와 똑같이 해보면서(실행 불가로 한 다음 실행하기), 이 기능을 익히고, EWLM의 기여도를 판단할 수 있다.

다음은 반드시 기억해야 할 제약 조건들이다:

1. EWLM으로 애플리케이션을 더욱 빠르게 실행시킬 수는 없다. 단지, 다른 파티션들을 희생하여, 한 파티션에 더 많은 프로세서 용량을 주는 것이다.
2. 모든 서비스 클래스들이 동시에 활성화 상태에 있을 경우, 더 중요한 서비스 클래스를 향상시키면, 덜 중요한 서비스 클래스가 강등된다.
3. I/O 병목 현상, 메모리 제약, 네트워크 레이턴시, 비효율적인 코드 경로, 너무 많은 예외 등으로 느려진 애플리케이션들은 EWLM 파티션 관리로도 어쩔 수 없다.

EWLM 파티션 관리를 실행 또는 실행시키지 않고 일반적인 워크로드를 테스트 하고, 이 기능을 실행시킬 만한 가치가 있는지를 스스로 판단하라. 모든 애플리케이션들이 동적인 프로세서 변화를 지원할 수 있는 것은 아니라는 사실도 명심하라.

예를 들어, 단 하나의 가상 프로세서가 있는 동안 애플리케이션이 시작되면, 이것은 프로그래밍 기술이나 라이센싱 요구 사항 때문에 그 프로세스에 연결되고, 나중에 용량이 증가하고 더 많은 가상 프로세서들이 추가될 때, 이 애플리케이션이 여기에 대해 반응을 하지 않으면, 여분의 용량을 많이 사용하지 못할 것이다.

반대의 경우도 가능하다. 일부 애플리케이션들이 가상 프로세서를 잠그고, 애플리케이션이 종료할 때까지 잠금을 해제하지 않는 경우에, 파티션은 가상 프로세서의 수를 줄일 수 없다. 이 경우는 이전 것 보다는 덜 드라마틱하지만, 재할당 리소스는 전체 시스템에 영향을 미치기 때문에, 이롭다고 판단되는 경우에만 수행하도록 한다.

중요 권고

모든 IT 환경 마다 특색이 있겠지만, 소프트웨어를 테스트 하면서, 그리고 알고리즘 디자이너를 통해 유효성 검사를 하면서 배운 몇 가지 원리들을 알려주고 싶다:

1. 같은 가상 그룹에 파티션이 많을수록 더 좋다.
2. 파티션 믹스의 경우 이종의 워크로드가 동종의 워크로드 보다 낫다. 모든 파티션들이 정확히 같은 일을 수행한다면, EWLM은 어떤 파티션에 프레퍼런스를 줘야 할지 모른다. 최상의 분배는 모든 파티션들이 같은 용량을 갖고 있을 경우이다. EWLM 파티션 관리가 필요 없다.
3. 생산성을 최대로 높이기 위해서, 애플리케이션과 파티션들이 동시에 모두 비지(busy) 상태가 되지 않도록 믹스&매치한다. 이 경우, EWLM은 더 중요한 애플리케이션에 우선권을 준다.

예를 들어, 세 개의 웹 애플리케이션들이 한 쌍의 IHS 서버와 한 쌍의 DB2 서버를 가진 세 개의 Application Server 노드들의 클러스터에서 실행되고, 이 모두가 같은 p5 박스의 파티션에서 실행된다. 세 개의 WebSphere Application Server 노드에 같은 용량을 설정하고, IHS 서버에서 오는 인커밍 요청들을 유사성을 기준으로 Round-Robin 방식으로 모든 노드들에 전달한다.

Application 1은 가장 중요한 서비스 클래스이고, Application Server 노드의 프로세서 병목 현상 때문에 퍼포먼스 목표를 달성하지 못하고 있다. 한편, Application 2와 Application 3는 같은 노드에서 완전한 비율로 실행된다. 당연히, EWLM은 Application 1의 응답 시간을 향상시키려고 할 것이다. 이 세 개의 모든 Application Server 노드들에서 똑 같은 양의 서비스 클래스를 실행하고 있기 때문에, EWLM은 이들을 건드릴 수 없다. 따라서, IHS와 DB2 파티션에 요청하여 사용되지 않는 리소스들을 표시해줄 것을 요청하게 된다. 하지만, IHS와 DB2 파티션들 모두 같은 서비스 클래스를 실행하고 있기 때문에, 자신들의 용량을 줄이는 것은 서비스 클래스에 마찬가지로 부정적인 영향을 미친다. 그 사이, IHS가 Application Server에 중요도를 무시하고 요청을 보내기 때문에, 덜 중요한 서비스 클래스는 같은 파티션 상에 로딩된다. 따라서, 다른 많은 파티션들에 사용되지 않는 용량이 별로 없다면, EWLM이 이 상황을 해결하기가 어렵다.

실제로, 여러분이 할 수 있는 일은 각 서비스 클래스가 특정 파티션으로 매핑하여, EWLM이 이들을 구분할 수 있도록 인프라스트럭처를 설정하는 것이다. (그림 9)

이 예제에서, WebSphere 플러그인 설정 파일(plugin-cfg.xml)에서 각 Application Server 클러스터 멤버에 다른 정적 웨이트(weight)를 설정하여, Application 1의 인커밍 요청들이 주로 WAS_1 파티션으로 보내지도록 하고, 작은 부분은 다른 노드들(10 대 1 비율)로 가도록 할 수 있다. Application 2의 인커밍 요청들은 주로 WAS_2로 보내지고, 작은 부분은 또 다른 부분들로 가게 된다.

이 같은 설정으로, Application 1이 퍼포먼스 목표를 달성하지 못하고, Application 2와 Application 3가 완전한 비율로 실행된다면, EWLM은 중요도가 더 낮은 다른 Application Server 파티션에 약간의 용량을 WAS_1에 양도할 것을 요청한다. 이로써, WAS_1에는 더 많은 프로세싱 용량이 생기고, 동시에, WAS_2와 WAS_3의 쓰루풋이 줄어들며, DB2 측에서 Application 2와 Application 3와 관련된 작업들도 줄어들게 된다. 결국, DB2는 Application 1에서 온 더 많은 작업들을 처리할 수 있다. 이 작은 차이로 EWLM은 이 같은 상황에서 훨씬 더 많은 도움이 된다.

이 설정으로, EWLM은 각 파티션의 중요도를 명확히 구분할 수 있다. 어떤 파티션이 요청을 처리할 수 없다면, 다른 파티션들은 자동으로 모든 작업들을 상속받고 EWLM은 문제가 있는 파티션에서 리소스를 가져와서 나머지에 분산한다. 어떤 개입 없이도, 인커밍 요청들을 처리하는데 같은 전체 프로세싱 용량을 다시 얻게 된다.

주의해야 할 점도 있다. 문제가 있는 파티션이 완전히 죽었거나, MS가 실행을 멈추면, 그 파티션은 가상 그룹에서 제거되어 총 그룹 용량이 감소되기 때문에, EWLM은 문제가 있는 파티션의 사용되지 않는 용량으로는 어떤 것도 할 수 없다. 사용되지 않는 용량은 공유 프로세서 풀로 리턴된다. Uncapped 모드에 있는 Application Server와 DB2 파티션이 공유 풀의 사용되지 않는 용량을 사용하도록 설정하는 것은 좋은 생각이 아니기 때문이다.

다시 한번 말하지만, 이것은 예제일 뿐이다. 여러분의 환경은 이것 보다 훨씬 복잡하다. 용도도 다양하다. 어떤 독자들은 WebSphere Extended Deployment로 문제를 해결할 수 있다고 말할지도 모르겠다. 좋은 소식은 이 문제를 해결할 수 있는 많은 툴들이 있다는 것이다. 나쁜 소식은 여러분이 직접 선택해야 한다는 것이다. 검토하고, 테스트 하고, 평가한 다음 결정하라.

운영 체계 툴과 로깅

Control Center나 HMC로 가지 않고 파티션 내에서 파티션 설정을 볼 수 있게 해주는 툴에 대해 알아보자. DLPAR 액티비티 로깅을 확인하는 방법도 설명하겠다. 이들은 테스트 동안 문제 해결에 사용했던 툴과 기술이다.

더 진행하기 전에, 간단한 팁 하나를 제시하겠다. 파티션의 용량 설정이 EWLM의 파티션 관리에 의해 “엉망이 되었고” HMC를 사용하여 각 파티션의 설정을 변경하는 대신, 초기 상태로 롤백 하려고 한다면, EWLM 파티션 관리를 실행 불가로 만든다. 이렇게 하면, 모든 파티션들은 EWLM이 관리를 맡기 전의 초기 상태로 돌아간다. 그런 다음, 실행 불가 상태로 두거나 재실행 할 수 있다.

AIX 툴

첫 번째 툴은 lparstat이다. 이것은 vmstat 처럼 라인 별로 파티션 정보를 디스플레이 하거나 더 상세하게 디스플레이 할 수 있다. lparstat 5는 vmstat 5 처럼 5초 마다 한 라인씩 프린트 할 것이다. 첫 번째 라인은 파티션 설정 요약을 보여준다. 다섯 번째와 여섯 번째 칼럼은 파티션에 의해 사용된 실제 용량을 각각 프로세서 단위와 할당 비율로 보여준다. Capped 파티션의 경우, %entc 칼럼은 100 퍼센트를 넘지 않지만, Uncapped 파티션은 그 이상을 소비할 수 있다.

# lparstat 5
System configuration: type=Shared mode=Capped smt=On lcpu=6 mem=2048 psize=8 ent=1.00
%user  %sys  %wait  %idle physc %entc  lbusy   app  vcsw phint
-----  ----  -----  ----- ----- ----- ------   ---  ---- -----
  0.5   0.4    0.0   99.1  0.01   1.4    0.0  6.88   526     1
  1.0   0.7    0.3   98.0  0.02   2.4    0.0  6.65   530     0
  0.9   0.5    0.0   98.6  0.02   2.0    0.3  6.68   525     4
  0.5   0.4    0.0   99.1  0.01   1.4    0.2  6.92   651     1

Listing 2에서, lparstat은 더 자세하게 디스플레이 하고 있다. 파티션 설정에 대해 알아야 할 모든 것이 나타나 있다.

# lparstat -i
Node Name                                  : hci245
Partition Name                             : hci245
Partition Number                           : 3
Type                                       : Shared-SMT
Mode                                       : Capped
Entitled Capacity                          : 1.00
Partition Group-ID                         : 111
Shared Pool ID                             : 0
Online Virtual CPUs                        : 3
Maximum Virtual CPUs                       : 32
Minimum Virtual CPUs                       : 1
Online Memory                              : 2048 MB
Maximum Memory                             : 4096 MB
Minimum Memory                             : 2048 MB
Variable Capacity Weight                   : 0
Minimum Capacity                           : 0.50
Maximum Capacity                           : 4.00
Capacity Increment                         : 0.01
Maximum Physical CPUs in system            : 16
Active Physical CPUs in system             : 8
Active CPUs in Pool                        : 8
Unallocated Capacity                       : 0.00
Physical CPU Percentage                    : 33.33%
Unallocated Weight                         : 0

lparstat 외에, vmstat 툴도 강화되어 공유 프로세서 모드 파티션에서 실행할 때 추가 정보를 보여준다. 오른쪽에 두 개의 새로운 칼럼들이 추가되어 소비된 프로세서(pc)와 할당 용량(ec)의 비율을 보여준다. 이는 lparstat의 다섯 번째와 여섯 번째 칼럼에 있는 데이터에 상응하는 것이다. 더욱이, 파티션 설정에 변화가 생길 때 마다, 일반 라인 순서를 인터럽트 하여 새로운 값을 보여준다.

# vmstat 5
System configuration: lcpu=6 mem=2048MB ent=1.00
kthr    memory              page              faults              cpu
----- ----------- ------------------------ ------------ -----------------------
 r  b   avm   fre  re  pi  po  fr   sr  cy  in   sy  cs us sy id wa    pc    ec 
 2  0 299335 185028   0   0   0   0    0   0   9  760 402  4  1 95  0  0.06  5.9
 4  0 299851 184512   0   0   0   0    0   0  15 1966 421  1  5 94  0  0.07  7.5
 5  0 299853 184510   0   0   0   0    0   0  16  501 424  1  1 99  0  0.02  1.8
System configuration changed. The current iteration values may be inaccurate.
 6  0 300030 184331   0   0   0   0    0   0  10 1852 396  1  1 98  0  0.02  2.6
System configuration: lcpu=6 mem=2048MB ent=0.95
kthr    memory              page              faults              cpu
----- ----------- ------------------------ ------------ -----------------------
 r  b   avm   fre  re  pi  po  fr   sr  cy  in   sy  cs us sy id wa    pc     ec
 5  0 299853 184508   0   0   0   0    0   0   7 1135 402  1  1 99  0  0.02  1.9
 4  0 299853 184508   0   0   0   0    0   0   6  252 395  0  0 99  0  0.01  1.5
 5  0 299853 184508   0   0   0   0    0   0  32  298 406  1  1 98  1  0.02  1.9

vmstatvmstat의 아웃풋에서 나온 데이터를 추출하는 스크립트가 있을 경우 조심하라. -- 여러분이 기대하는 것만큼 정상적이지 않다.

마지막 툴은 topas이다. 이것 역시 공유 프로세서 파티션에서 실행될 때 vmstat 처럼 추가 정보를 보여준다.

리눅스 툴

불행히도, 리눅스 툴은, AIX 툴만큼 향상되지는 않았지만, 어쨌든 얻을 것은 있다. cat /proc/ppc64/lparcfg 명령어는 lparstat -i와 같은 정보를 디스플레이 한다. 이 정보는 엉성해 보이지만, 모든 것이 들어있다. 괄호 한에 강조한 것은 가장 유용한 부분이고, 나머지들도 유용하다.

# vmstat 5
System configuration: lcpu=6 mem=2048MB ent=1.00
kthr    memory              page              faults              cpu
----- ----------- ------------------------ ------------ -----------------------
 r  b   avm   fre  re  pi  po  fr   sr  cy  in   sy  cs us sy id wa    pc    ec 
 2  0 299335 185028   0   0   0   0    0   0   9  760 402  4  1 95  0  0.06  5.9
 4  0 299851 184512   0   0   0   0    0   0  15 1966 421  1  5 94  0  0.07  7.5
 5  0 299853 184510   0   0   0   0    0   0  16  501 424  1  1 99  0  0.02  1.8
System configuration changed. The current iteration values may be inaccurate.
 6  0 300030 184331   0   0   0   0    0   0  10 1852 396  1  1 98  0  0.02  2.6
System configuration: lcpu=6 mem=2048MB ent=0.95
kthr    memory              page              faults              cpu
----- ----------- ------------------------ ------------ -----------------------
 r  b   avm   fre  re  pi  po  fr   sr  cy  in   sy  cs us sy id wa    pc     ec
 5  0 299853 184508   0   0   0   0    0   0   7 1135 402  1  1 99  0  0.02  1.9
 4  0 299853 184508   0   0   0   0    0   0   6  252 395  0  0 99  0  0.01  1.5
 5  0 299853 184508   0   0   0   0    0   0  32  298 406  1  1 98  1  0.02  1.9

리눅스에서는 파티션 정보를 보는 것이 최상의, 아마도 유일한 방법이다. 여러분에게 소개하고 싶은 툴은 drmgr인데 Linux on POWER의 Service and productivity 툴의 일부인 rpa-dlpar 패키지에 포함되었다. 이 툴을 사용하여 파티션 안에서 파티션 설정을 변경할 수 있다. HMC로 갈 필요가 없다. 몇 가지 예를 보도록 하자.

가상 프로세서 1을 추가 또는 제거하기:

drmgr -a -c cpu -q 1
drmgr -r -c cpu -q 1

파티션에 0.02 프로세서 단위를 추가 또는 제거하기

drmgr -a -c cpu -p ent_capacity -q 2
drmgr -r -c cpu -p ent_capacity -q 2

파티션의 웨이트에 5 단위 추가 또는 제거하기

drmgr -a -c cpu -p variable_weight -q 5
drmgr -r -c cpu -p variable_weight -q 5

AIX에도 drmgr라는 이름을 가진 툴이 있다. 하지만 이것은 다른 용도로 사용된다. AIX의 drmgr은 DLPAR 연산 전후에 스크립트를 등록하는데 사용된다. 리눅스와 혼돈하지 말기 바란다.

AIX에 DLPAR 로깅 실행하기

EWLM MS가 파티션 설정을 변경하지 못하는데 그 이유도 알 수 없는 경우가 있다. 이 경우, DLPAR 연산의 로깅을 실행시켜야 한다. /etc/syslog.conf 파일을 편집하고 다음 라인을 추가한다:

*.debug /var/log/messages rotate size 100k files 4

원한다면 다른 경로와 파일 이름을 선택할 수 있고 파일의 크기와 수도 여러분이 선택할 수 있다. Listing 5는 변경이 일어날 때 로그 파일에 작성되는 것들이다.

Jun 7 17:56:18 hci245 local1:info DRMGR: ==== Start: SPLPAR addition operation ====
Jun 7 17:56:18 hci245 local1:info DRMGR: Starting CHECK phase for capacity Add operation.
Jun 7 17:56:18 hci245 local1:info DRMGR: Phase CHECK started for scripts,kernel extensions
                                         and applications.
Jun 7 17:56:18 hci245 local1:info DRMGR: Starting CHECK phase for Scripts.
Jun 7 17:56:18 hci245 local1:info DRMGR: Completed the phase for Scripts.
Jun 7 17:56:18 hci245 local1:info DRMGR: Starting the phase for kernel extensions.
Jun 7 17:56:18 hci245 local1:info DRMGR: Completed the phase for kernel extensions.
Jun 7 17:56:18 hci245 local1:info DRMGR: Starting the phase for application signal 
                                         handlers.
Jun 7 17:56:18 hci245 local1:info DRMGR: Completed the phase for kernel extensions.
Jun 7 17:56:18 hci245 local1:info DRMGR: Starting PRE phase.
Jun 7 17:56:18 hci245 local1:info DRMGR: Phase PRE started for scripts,kernel extensions 
                                         and applications.
Jun 7 17:56:18 hci245 local1:info DRMGR: Starting PRE phase for scripts.
Jun 7 17:56:18 hci245 local1:info DRMGR: Completed the phase for Scripts.
Jun 7 17:56:18 hci245 local1:info DRMGR: Starting the phase for application signal 
                                         handlers.
Jun 7 17:56:18 hci245 local1:info DRMGR: Completed the phase for kernel extensions.
Jun 7 17:56:18 hci245 local1:info DRMGR: Starting POST phase.
Jun 7 17:56:18 hci245 local1:info DRMGR: Phase POST started for scripts,kernel extensions 
                                         and applications.
Jun 7 17:56:18 hci245 local1:info DRMGR: Starting the phase for application signal 
                                         handlers.
Jun 7 17:56:18 hci245 local1:info DRMGR: Completed the phase for kernel extensions.
Jun 7 17:56:18 hci245 local1:info DRMGR: Starting POST phase for scripts.
Jun 7 17:56:18 hci245 local1:info DRMGR: Completed the phase for Scripts.
Jun 7 17:56:18 hci245 local1:info DRMGR:  ~~~~ End: SPLPAR addition operation ~~~~

실제로, DLPAR 연산 동안, 특정 단계를 완수했는지의 여부를 알려준다. 예를 들어, PRE 단계에 일부 리소스를 릴리즈 하는 스크립트를 등록했는데, 그 리소스가 릴리즈 될 수 없다면, 스크립트는 실패하고 DLPAR 연산은 취소되어 수행되었던 것이 롤백 될 것이다. 이 로그가 바로 이러한 유형의 정보이다.

리눅스에 DLPAR 로깅 실행하기

리눅스에서도 DLPAR 로깅을 실행할 수 있지만 AIX에서 처럼 단계 개념이 없다. 따라서, /etc/syslog.conf 파일을 편집하고 다음 라인을 추가해야 한다:

local0.*                         -/var/log/drmgr.log

Listing 6은 변경 사항이 생길 때, 이 파일에 기록된 것들이다:

Jun 7 11:39:25 hei035 drmgr: drmgr starting ....
Jun 7 11:39:25 hei035 drmgr: main: argv[0]=drmgr
Jun 7 11:39:25 hei035 drmgr: main: argv[1]=-c
Jun 7 11:39:25 hei035 drmgr: main: argv[2]=cpu
Jun 7 11:39:25 hei035 drmgr: main: argv[3]=-a
Jun 7 11:39:25 hei035 drmgr: main: argv[4]=-p
Jun 7 11:39:25 hei035 drmgr: main: argv[5]=ent_capacity
Jun 7 11:39:25 hei035 drmgr: main: argv[6]=-q
Jun 7 11:39:25 hei035 drmgr: main: argv[7]=0
Jun 7 11:39:25 hei035 drmgr: drmgr starting ....
Jun 7 11:39:25 hei035 drmgr: main: argv[0]=drmgr
Jun 7 11:39:25 hei035 drmgr: main: argv[1]=-c
Jun 7 11:39:25 hei035 drmgr: main: argv[2]=cpu
Jun 7 11:39:25 hei035 drmgr: main: argv[3]=-a
Jun 7 11:39:25 hei035 drmgr: main: argv[4]=-p
Jun 7 11:39:25 hei035 drmgr: main: argv[5]=variable_weight
Jun 7 11:39:25 hei035 drmgr: main: argv[6]=-q
Jun 7 11:39:25 hei035 drmgr: main: argv[7]=0
Jun 7 11:39:25 hei035 drmgr: drmgr starting ....
Jun 7 11:39:25 hei035 drmgr: main: argv[0]=drmgr
Jun 7 11:39:25 hei035 drmgr: main: argv[1]=-c
Jun 7 11:39:25 hei035 drmgr: main: argv[2]=cpu
Jun 7 11:39:25 hei035 drmgr: main: argv[3]=-a
Jun 7 11:39:25 hei035 drmgr: main: argv[4]=-q
Jun 7 11:39:25 hei035 drmgr: main: argv[5]=2

이것이 drmgr의 매개변수이다. 이것에 대한 man 페이지를 찾을 수 없었기 때문에, 이러한 방식으로 명령어 신택스를 배웠다.

맺음말

두 편의 기술자료 시리즈를 통해서, 테스트 환경의 토폴로지와 워크로드를 분석했다. 또한, 도메인 정책을 조명하고, 데모를 실행하여 EWLM에 의한 파티션 관리 모습도 보았다.

IBM System p5 서버에서 실행되는 AIX와 리눅스 파티션에 지능형 파티션 관리를 실행하여, IBM Enterprise Workload Manager를 통해 퍼포먼스 데이터를 활용하는 방법을 설명했다. 워크로드 우선 순위와 관련하여, EWLM이 자동으로 파티션들에 프로세싱 용량의 밸런스를 자동으로 맞추는 방법도 설명했다.

EWLM을 사용한다고 해서 여러분이 할 일이 전부 다 해결되는 것은 아니다. 여러분의 IT 환경이 용량을 재할당하여, 순간적인 피크(peak)를 핸들 할 정도로 충분히 지능적인지를 확인해야 한다. 그리고, 여러분보다 더 빠르게 대응할 수 있어야 한다.

또한, 신중한 플래닝을 한다면, 하루에 단지 몇 분 정도만 생기는 가장 높은 피크를 핸들하기 위해 모든 애플리케이션의 프로세싱 용량을 과도하게 할당하지 않아도 되므로, 어느 정도 비용을 절감할 수 있다.

지금 당장, EWLM은 훌륭한 파티션 관리와 로드 밸런싱을 경험해 보기 바란다. 향후 버전에서는, 더 많은 영역에 대한 컨트롤을 제공할 것으로 기대된다.

이 글을 검토해 주고, 소중한 피드백을 준 Yuksel Gunal에게 감사의 말을 전한다.

기사의 원문보기

• Partition management with EWLM, Part 2: Partition management in action

위로

다운로드 하십시오

	다운로드 방식에 대한 정보			Get Adobe® Reader®

참고자료

• "Enterprise Workload Manager를 이용한 퍼포먼스 모니터링" (developerWorks, 2006년 3월): Enterprise Workload Manager(EWLM) 도메인에서 엔드투엔드 퍼포먼스 모니터링을 구현하고 문제 해결도 해봅시다.
  
  
• IBM EWLM Information Center
  
  
• Reliable Scalable Cluster Technology
  
  
• "Advanced POWER Virtualization on IBM System p5" (IBM Redbooks, December 2005)
  
  
• "Autonomic load balancing with EWLM" (developerWorks, April 2006)
  
  
• Specified operating environments
  
  
• ARM
  
  

• Service and productivity tools
  
  
• Fixpack 30
  
  
• IBM Trade Performance Benchmark
  
  

• developerWorks blogs
  
  
• Dave Bartlett's blog
  
  
• Autonomic Computing: An insider's perspective

필자소개

		CheKim Chhuor는 현재 System Verification Test 팀에서 일하고 있다. 웹 인프라 컨설팅 분야에서 오랜 경력을 쌓았으며 IBM WebSphere®, DB2®, e-business 인증을 보유하고 있다. 현재 자율 컴퓨팅과 그리드에 관심을 갖고 있다. chhuor@us.ibm.com.

기사에 대한 평가

보다 나은 서비스를 제공하기 위함이오니 잠시 짬을 내어 이 양식을 제출하여 주십시오. 귀하께서 원하시는 정보를 얻었습니까? 예 아니오 잘 모르겠음   이 페이지 개선을 위한 의견을 주십시오:   이 정보가 얼마나 유용했습니까? (1 = 전혀 도움이 되지 않음, 5 = 매우 유용함) 1 2 3 4 5

위로