 |
|
난이도 : 중급 CheKim Chhuor, System Verification Tester, IBM
2006 년 10 월 24 일 이전 기술자료인 “Enterprise Workload Manager를 이용한 퍼포먼스 모니터링”에서 IBM® Enterprise Workload Manager (EWLM)를 사용하여 퍼포먼스 데이터를 얻었습니다. 지금은 이 데이터를 활용하여 IBM System p5 서버에서 실행되는 AIX®와 Linux® 파티션들에 대해 지능적인 파티션 관리를 수행할 때입니다. 이 글에서, 논리적 파티셔닝을 소개합니다. EWLM 파티션 관리를 위한 환경 설정 단계를 설명하고, 파티션들을 설정하는 방법도 설명합니다.
논리적 파티셔닝(LPAR)은 쉬운 관리와 비용 절감을 위해 머신에서 컴퓨팅 리소스들을 통합하는 편리한 방식인 동시에, 리소스 할당에 있어서도 고립과 뛰어난 유연성을 선사하기 때문에, 리소스가 지속적으로 변하는 비즈니스 요구에 대해서도 빠르게 대처할 수 있다. 하지만 지금까지는 p5 서버에서의 리소스 할당을 지금까지는 직접 수행했다. 이 프로세스는 동적으로 수행될 수 있음에도 불구하고, 여전히 시스템 관리자들이 자신의 판단을 기준으로 리소스를 할당하고 있다.
그러나 몇몇 사용자들은 Advanced POWER™ Virtualization 오퍼링에서 제공하는 Partition Load Manager (PLM)과 AIX의 Workload Manager (WLM)를 사용하여 리소스 사용 임계치에 기반하여 리소스 할당을 자동화하고 있다. 이러한 방식은 대개 시행착오(trial-and-error) 수준이고, 비즈니스 요구 사항을 정확히 반영하지는 못하였다.
EWLM의 파티션 관리 기능으로, 여러분의 비즈니스 사용자 요구에 맞춰 퍼포먼스 목표를 정의할 수 있다. EWLM에게 각 애플리케이션의 중요도를 알려주면 EWLM은 지속적으로파티션들간 리소스의 균형을 맞춰서 각 애플리케이션의 우선순위에 따라 퍼포먼스 목표를 달성한다. 더욱이 애플리케이션이 퍼포먼스 목표 달성에 실패하기 전에 액션을 취하기 때문에 가장 중요한 애플리케이션들은 서비스 레벨 계약을 언제나 준수하게 된다. 여러분이 개입할 필요가 없다.
이 글에서, AIX와 리눅스 플랫폼에서, EWLM을 이용한 파티션 관리 환경을 설정하는 과정을 설명하겠다. 하드웨어와 소프트웨어 요구 사항을 이해한 다음, Hardware Management Console (HMC)에서 파티션들이 설정되는 방법을 설명할 것이다. 본 시리즈의 두 번째 기술자료에서는, 도메인 정책을 구현하고, 워크로드를 시작하여, 워크로드가 퍼포먼스 목표에 이르기 위해 분투하는 동안 그 결과를 관찰하는 등 실질적인 파티션 관리 방법을 설명할 것이다. 마지막으로, 몇 가지 툴을 소개하고, 문제 해결 팁도 설명하겠다.
ARM instrumentation, MS, DM, Control Center 같은 EWLM의 일반적인 개념과 용어에 익숙해져야 한다. 이 모든 것이 생소하다면 이전 기술자료인 “Enterprise Workload Manager를 이용한 퍼포먼스 모니터링”을 참조하기 바란다. (참고자료).
이 글에서 설명하는 모든 개념과 절차들은, 운영 체제 i5/OS®를 구동하는 IBM System i5™ 서버에도 적용된다. p5와 i5 서버들도 여러 가지 유형의 리소스들(프로세서, 메모리, 네트워크, I/O 디바이스)의 동적 할당을 지원하지만, 현재 EWLM 버전은 프로세서 리소스만 다룬다. 따라서 프로세서 경쟁으로 생긴 애플리케이션 병목현상만 관리한다. 메모리 지연이나 I/O 지연의 문제를 겪는 애플리케이션은 EWLM에서 어떤 해결책도 찾을 수 없다.
파티션이란 무엇인가? 이 글에서 사용되는 파티션이란 용어는 POWER5™ 플랫폼과 관련이 있다. 하지만 다른 EWLM은 가상 서버(Virtual Server)라는 용어를 사용하고 있다. 이 용어는 보다 일반적이며, 다른 가상화 환경에 적용할 수 있다. 어떤 사람들은 메인프레임에서 사용되는 것처럼 논리적 파티션(logical partition) 또는 LPAR라는 용어를 사용한다. 하지만 이 글에서는 간단히 파티션과 파티션 관리로 칭하겠다.
InfoCenter (참고자료)에 자세히 문서화 되어 있는 EWLM의 기본적인 요구 사항들 외에도, 파티션 관리를 하기 위해 필요한 추가 조건들도 있다. 예를 들어, DLPAR 연산을 지원하는 하드웨어와 소프트웨어가 있어야 하고, 기본적인 플랫폼 제약 조건들을 거스르지 않고 EWLM에 의해서 재조정 될 수 있는 방식으로 파티션들이 정의되어야 한다. 나머지 섹션에서는 하드웨어와 소프트웨어 요구 사항을 설명하도록 하겠다.
서버
Micro-Partitioning 기능을 갖춘 IBM POWER5 프로세서에 기반한 서버라면 지원이 가능하다. 여기에는 기존 pSeries®와 iSeries™ 서버는 물론, 새로운 IBM System p5와 i5 서버들도 포함된다. Micro-Partitioning은 Advanced POWER Virtualization 오퍼링의 기능으로서, 프로세서 당 최대 10개의 파티션을 호스팅 할 수 있고, 프로세서의 1/100th의 세분성으로 용량 할당이 이루어지기 때문에 보다 유연한 리소스 공유와 차원 높은 활용도를 보인다. EWLM은 프로세서 용량만 관리하기 때문에 파티션이 물리적 어댑터를 사용하든 Virtual I/O Server를 사용하든지 상관하지 않는다.
시스템 펌웨어는 SF235 버전 또는 그 이상이어야 한다. AIX 5.3 플랫폼에서, lsmcode 명령어를 사용하여 현재 시스템 펌웨어 버전을 확인할 수 있다. Service라고 하는 IBM 패키지와 툴을 Linux on POWER에 설치했다면 SUSE Linux Enterprise Server 9 (SLES 9)에서도 사용할 수 있다. (참고자료).
Hardware Management Console
서버에 파티션을 만들기 위해서는 반드시 HMC가 필요하다. 본문에 있는 스크린샷은 HMC 코드 버전 5.20 build 20060210.1에 기반하고 있다. 약간 더 오래된 버전도 사용할 수 있지만 GUI 패널이 약간 다르다.
HMC를 사용하지 않고 Integrated Virtualization Manager (IVM)를 사용한다면(p550 이하의 작은 서버나 BladeCenter® JS21에서 EWLM을 사용한다면), 이론상으로는 EWLM은 그곳에서도 파티션을 관리할 수 있어야 한다. 하지만, 실행 환경에서는 HMC 연결 서버를 사용할 것을 적극 권장한다. 이것은 개발하는 동안 테스트했던 설정이다. 아직까지는 IVM-관리 서버에는 테스트가 수행되지 않았다. 따라서 여기에서는 굳이 공들여 설명하지 않겠다.
운영 체계
AIX 5.3 플랫폼에서는, Maintenance Level 3 또는 그 이상이어야 한다. SLES 9의 경우, Service Pack 3를 설치해야 한다. 하지만, SP3에서 적용할 수 없었던 버그 픽스가 있었기 때문에 SUSE 관리 웹 사이트에서 최근 커널 구현(2.6.5-7.244 또는 그 이상)을 사용해야 한다.
Resource Monitoring and Control (RMC) 서브시스템(subsystem)이 설치되어 실행되어야 한다. 이 서브시스템은 Reliable Scalable Cluster Technology (RSCT; 참고자료)의 일부이다. AIX에서는 이미 설치되어 모든 HMC 관리 파티션에 대해 설정도 되어있다. SLES 9에서는 Service와 Linux on POWER 패키지용 툴을 설치하여 DLPAR 연산을 가능케 한다.
AIX와 SLES 9에서 이 서브시스템이 실행중인지를 확인하려면 다음 명령어를 입력한다:
# lssrc -s ctrmc
Subsystem Group PID Status
ctrmc rsct 209002 active
|
“활성(active)” 상태로 되어 있어야 한다. 이것이 올바르게 설정되었는지를 보려면 다음 명령어를 입력한다:
# /usr/sbin/rsct/bin/rmcdomainstatus -s ctrmc
Management Domain Status: Management Control Points
I A 0x870d96b9185bb416 0001 10.1.1.120
|
결과 IP 주소는 HMC IP 주소와 일치해야 하며, 이 경우 10.1.1.120이다. 이것은 EWLM이 작동하는데 특별히 필요한 것은 아니지만(실제로, EWLM은 RMC 데몬 실행 없이도 파티션 관리를 수행하고 용량을 조정할 수 있다.), 파티션이 HMC와 인터랙팅 하기 위해서 필요하다. 그렇지 않을 경우, HMC에서 DLPAR을 변경할 수 없으며 파티션에서 로컬로 수행된 변경 사항들은 HMC에 반영되지 않는다. 기능적인 환경을 위해서는, RMC 데몬을 언제나 실행해야 한다. RMC 데몬이 몇 가지 이유로 인해 임시적으로 사용할 수 없더라도, EWLM 파티션 관리는 문제 없이 지속된다.
EWLM
AIX의 경우, 파티션 관리에 일반적으로 사용되는 EWLM V2R1 버전을 사용할 수 있다. SLES 9의 경우, fixpack 20을 설치해야 한다. 하지만 나는 두 가지 경우 모두, fixpack 30을 설치하도록 권장하고 싶다. 여기에서 사용하는 AIX 파티션들은 fixpack 30의 Pre-release 버전을 Managed Server (MS) 측과 Domain Manager (DM) 측에 적용한다. fixpack 30은 EWLM 파티션 관리 기능 향상과 여러 버그 픽스을 포함하고 있다.
게다가 애플리케이션이 실행되는 미들웨어는 지능형 관리 알고리즘을 활용하기 위해서는 ARM이 장착되어야 한다. 이것이 가능하지 않다면, 벤더 패키지나 일괄 작업들을 다루어야 할 경우, 도메인 정책에 파티션 클래스를 정의하여 EWLM의 파티션 관리를 이용할 수 있고, EWLM은 퍼포먼스 목표에 맞춰 서비스 클래스로서 각 파티션을 관리할 것이다. EWLM은 다만 노드간 트랜잭션 흐름의 세분성과, 전체 응답 시간 중 각 홉(HOP)에서 소비된 시간은 알 수 없다.
바로 이러한 이유 때문에 ARM이 장착된 미들웨어가 더 많은 통계를 제공하고 -- 이로서 EWLM이 더 나은 관리 결정을 내릴 수 있는 것이다.
만약 여러분이 이러한 요구 사항 리스트를 다 준수할 수 있다면(솔직히, 내 생각엔 약간 길다.), 계속 읽어가기 바란다. 이 모든 요구 사항들을 다 수행할 수 있을지 확신이 서지 않는다면 체크 리스트를 작성하고(또는 다운로드에서 제공한 체크 리스트를 사용해도 된다.), 또는 시스템 관리자에게 각 아이템을 확인 받는 것도 좋은 생각이다.
HMC에서의 파티션 설정
EWLM 파티션 관리를 위해서 파티션들이 어떻게 설정되는지를 보자. HMC 콘솔로 가거나, Web-based System Manager 툴(WebSM)을 사용하여 HMC에 원격으로 연결한다. (지금 나도 그렇게 하고 있다.):
- 서버에서 파티션 리스트를 확장한다.
- 활성 파티션 프로파일을 오른쪽 클릭하고 Properties를 선택한다.
-
Processors 탭을 클릭한다.
그림 1과 같은 창이 보인다.
그림 1. 파티션 프로파일에서의 프로세서 설정
프로세싱 모드
Processors 탭 윈도우에 네 개의 설정 그룹들이 있다; 이 모두가 매우 중요하다. 첫 번째는 프로세싱 모드인데, “Shared” 모드로 설정되어야 한다. 파티션이 공유 프로세서 풀에서 프로세서 리소스를 사용한다는 것을 의미한다. EWLM은 "Dedicated" 프로세싱 모드에서는 어떤 파티션도 관리하지 않는다.
프로세싱 단위
다음 설정은 파티션으로 할당될 프로세싱 단위의 양을 설정하는 것이다. 가장 중요한 설정이다. 이 파티션이 일반적으로 수행할 작업에 대해 원하는 프로세싱 단위를 할당하는 것으로 시작하여, 파티션의 최대 용량과 최소 용량을 설정한다. EWLM은 최소와 최대 범위에 따라 참여 파티션들의 용량을 관리하고, 이 범위는 변할 수 없다. 파티션을 내리고 다시 활성화 하여 변경 사항을 적용해야 한다.
다른 파티션이 여분의 용량을 받을 수 있도록 각 파티션이 용량을 기부할 수 있도록 약간의 여유를 주어야 한다. EWLM의 관리 범위는 그룹 레벨인데 나중에 자세히 설명하겠다. 모든 파티션들의 총 할당 용량을 관리하고, 그 그룹에서 용량을 추가하거나 제거하지 않는다. 그룹 내에서 한 개 이상의 파티션을 취해서 같은 그룹의 파티션들에게 준다. 어떤 것도 기부하지 않으려 한다면 절대로 받을 수 없다. 기여자는 최소 용량 이하로 갈 수 없고, 수혜 파티션들은 최대 용량 이상으로 갈 수 없다. 서비스 클래스의 상태는 상관이 없다.
할당된 용량은 파티션 프로파일에 설정된 희망 프로세스 단위와 일치한다. 다만, 파티션 활성화 동안 공유 프로세서 풀에 충분한 여유 용량이 없어서 그 파티션에 할당을 할 수 없다는 점을 제외하고는 말이다. 이것은 여전히 활성화 될 수 있지만 원하는 용량 설정만큼 할당될 수 없다.
예를 들어, 내 파티션 hci245가 원하는 용량은 1.0 processing unit (PU)이다. 활성화 동안 이 풀에서 단 0.7 PU만 사용할 수 있다면, 할당 용량은 1.0이 아닌 0.7이 될 것이다.
할당 용량과 희망 용량 간 차이를 이해해야 한다. EWLM은 희망 용량과 관계 없이, MS가 DM에 참여할 때 할당 용량을 사용한다. 분명한 것은 실제 할당 용량은 최소 값 이하나 최대 값 이상으로 가지 않는다. 이는 POWER Hypervisor가 관리한다.
가상 프로세서
다음 설정은 가상 프로세서(VP)의 수를 설정하는 것이다. 실제로, 할당된 프로세싱 단위들은 이해하기 쉽지만, POWER5 서버상의 가상 프로세서의 개념은 설명하기가 어렵다. 더 복잡하기 때문이다. IBM Redbook, "Introduction to Advanced POWER Virtualization on IBM p5 Servers" (참고자료)를 읽어보기 바란다. Section 3.3에서 이 개념을 자세히 설명하고 있다.
여기서 문제가 되는 것은 최소 VP의 수가 앞서 설정된 최소 PU의 근사치여야 한다. VP의 원하는 값은 PU의 원하는 수 보다 커야 하고 최대 VP는 최대 PU 보다 커야 한다. 최소 및 최대 값은 동적으로 변할 수 없다.
원하는 값은 파티션 활성화 동안 사용되지만 EWLM MS가 시작되자 마자 VP 값을 현재 할당 용량에 기반하여 최적 값으로 조정한다. 예를 들어, 현재 할당 용량이 1.0이면, MS는 VP 값을 3으로 조정할 것이다. 용량이 0.4로 떨어지면 VP 값을 1로 변경한다. 용량이 3으로 올라가면 VP를 5로 변경한다.
이로써 파티션이 공유 프로세서 풀에서 사용되지 않는 용량을 활용할 수 있다. 하지만 MS는 최소 값 보다 낮거나, 최대 VP 값 보다 높아지지는 않는다. 사실, VP 설정을 사용하여 Uncapped 파티션에 브레이크를 두어 공유 풀에서 가능한 모든 것을 소비할 수 있다.
공유 모드
이 패널의 마지막 설정은 공유 모드인데, “Capped” 또는 “Uncapped”가 될 수 있다. 공유 모드를 잘 모르겠다면 IBM Redbook을 참조하기 바란다.
여기서 중요한 것은 Capped 모드 파티션으로는 Hypervisor가 원하는 PU 보다 많은 프로세싱 리소스를 자동으로 할당하지 않는다. 따라서, EWLM은 그 파티션에서 실행되는 서비스 클래스가 퍼포먼스 목표를 달성하지 않는다면, 프로세서 용량을 조정할 때 EWLM이 적극적으로 개입한다.
Uncapped 모드 파티션에서는 공유 풀에 사용되지 않는 용량이 있을 경우 Hypervisor가 더 많은 용량을 자동으로 제공한다. 따라서 EWLM이 많이 개입될 필요가 없다. 여러 Uncapped 파티션들이 프로세싱 사이클 동안 경쟁할 경우에만 개입하여 할당된 용량과 Uncapped 값을 조정하여 더 중요한 작업을 가진 파티션이 진행되도록 하거나 다른 것들 보다 심각하게 목표에 못 미치는 작업을 진행시킨다.
Capped 또는 Uncapped 모드의 사용 결정은 파티션들 간 전체적인 워크로드에 기반한다. 몇 가지 워크로드 결합은 공유에 알맞고, 다른 것은 고립에 더 잘 맞는다. EWLM 파티션 관리를 테스트 한다면, Capped 파티션으로 시작하여 EWLM의 관리 효과를 쉽게 볼 수 있다. 이를 충분히 활용한 후에, 정말로 원할 경우 Uncapped 모드로 전환할 수 있다.
공유 모드와 관계 없이, 소프트웨어 라이센스가 프로세서 당 부과된다면 이에 주의하라. 몇몇 소프트웨어는 프로세서 수에 고정된 한계를 정하고, 등록된 수 이상의 프로세스를 사용하지 않는다. 운영 체계에서 보여지는 실제 논리적 프로세서의 수가 물리적 프로세서의 수 보다 크기 때문에, 더 많은 용량을 추가해도 쓰루풋이 늘지 않거나 응답 시간이 줄지 않는지가 궁금할 것이다. 게다가 합법적이기 원한다. 가상화된 환경에서 소프트웨어 라이센싱은 미지수이다. 산업 표준 관례에 순응하려면 시간이 필요하다.
파티션 워크로드 그룹
이제, 같은 윈도우에 있는 Settings 탭으로 가보자. 그림 2처럼 파티션 워크로드 그룹에 대한 값을 설정해야 한다.
그림 2. 파티션 프로파일에서 파티션 워크로드 그룹 설정하기
여기에서 16비트 정수 값을 사용할 수 있지만(최대32768), 특별한 목표를 위해 더 높은 범위가 정해지기 때문에 최저부터 시작하라. 여러 워크로드 그룹이 있다면 숫자는 연속적이어서는 안된다.
워크로드 그룹 넘버의 유틸리티에 대해 알아야 할 두 가지 사항이 있다:
- 첫째, 파티션이 그룹에 속해있을 때에만 MS가 파티션 관리에 참여한다. 다시 말해서, 워크로드 그룹 수가 할당되어야 한다.
- 둘째, EWLM은 같은 그룹의 파티션들간 용량 교환만 관리한다.
파티션 상에서 EWLM에 의한 파티션 관리를 원하지 않는다면 워크로드 그룹을 “None”으로 설정하면 된다.
이제, fixpack 30의 향상된 부분을 설명할 차례이다. 이 fixpack 전에, 파티션의 그룹 멤버쉽을 변경했다면, 파티션이 실제로 그 변경 사항을 받아들일지라도 이를 적용하려면 MS를 재시작 해야 한다. fixpack 30을 사용하여, MS는 그룹 멤버쉽 변경 사항들을 동적으로 탐지하고, 재시작 하지 않고도 여기에 반응한다. 예를 들어, 파티션이 그룹의 일부가 아닌데도 그룹 멤버를 할당한다면 MS는 몇 초 내에 이를 탐지하고 파티션 관리 기능을 실행한다. 파티션이 그룹에 속해있는데 그룹을 “None”으로 설정한다면 MS는 DM에게 이것이 그룹을 떠나서 더 이상 EWLM의 관리를 받는 파티션이 아니라는 것을 알려준다.
그림 3처럼, 파티션을 오른쪽 클릭하고 Properties를 선택하고 Other 탭으로 가서 값을 입력하거나 드롭다운 리스트에서 “None”을 선택하여 HMC에서 동적으로 파티션 워크로드 그룹을 변경할 수 있다.
그림 3. 파티션 속성 패널에서 파티션 워크로드 그룹 변경하기
공유 프로세서 풀 권한
마지막으로 HMC를 사용할 차례이다. 각 파티션이 공유 프로세서 풀을 사용하도록 한다:
- 각 파티션을 오른쪽 클릭하고 Properties를 선택한다.
-
Hardware 탭의 Processors and Memory로 간다.
-
그림 4 처럼, "Allow shared processor pool utilization authority" 박스를 체크한다.
그림 4. Partition Properties의 공유 풀 권한 설정
파티션 설정이 끝났다. 프로세스가 긴 것 같지만 실제로 해보면 간단하다. 이 절차는 AIX, Linux, i5/OS를 실행하는 p5와 i5 파티션에 적용된다.
EWLM 파티션 관리 알고리즘
본 시리즈의 두 번째 글에서는 데모를 실행할 것이다. 실제 파티션 관리 방법을 보여줄 것이다. 막후에서 어떤 일이 발생하는지를 이해할 수 있도록 이들이 어떻게 작동하도록 설계되었는지를 설명하겠다.
이러한 관리를 수행하기 위해 다른 컴포넌트들이 인터랙팅 하는 방법을 비롯하여, 관리 결정을 내리는 동안 알고리즘 엔진이 고려해야 하는 여러 요소들을 설명하겠다. 하지만 걱정하지 말라. 세부적인 부분이나 실제 알고리즘은 설명하지 않을 것이다. 이것은 나도 원치 않는다.
파티션 관리의 목표는 서비스 클래스가 각 정책에 설정되었던 퍼포먼스 목표를 달성할 수 있도록 돕는 것이다. 구체적으로는, 이 목표는 특정 기간 안에 트랜잭션이 완료되도록 하는 것이며, 이는 평균 응답 시간 (모든 트랜잭션들이 평균 100ms 내에 완료된다.)과 반응 시간 백분율 (95 퍼센트의 트랜잭션이 200ms 내에 완성되었다.)로 나타날 수 있다.
EWLM은 퍼포먼스 목표를 채우지 못하거나 목표 달성이 불가능해 보이는 서비스 클래스를 돕는다. 트랜잭션은 여러 노드와 플랫폼으로 확대될 수 있다. EWLM은 그러한 각 노드에 대해 트랜잭션(또는 하위 트랜잭션)이 실제로 수행되는 방법에 대한 상세한 통계치를 갖고 있다. 프로세서 병목현상으로 고통을 받고 있는 노드를 도우려고 하지만, 이러한 트랜잭션을 더 빠르게 실행시킬 수는 없다. 왜냐하면 이것은 환경 설정을 최적화 하거나 코드를 재작성 해야지만 가능한 일이기 때문이다.
따라서, EWLM이 기여를 하는 방식은 EWLM이 관리하고 있는 시스템들에서 전체 워크로드에 대해 우선 순위를 정하는 것이다. 다시 말해서, 유휴 상태에 있거나 덜 중요한 작업을 하는 곳에서 리소스를 가져와서 이러한 목표를 달성한다. EWLM은 어떤 파티션에서 프로세서 용량을 가져와서 이를 목표 달성에 어려움을 겪고 있는 파티션에게 주는 것이다.
EWLM의 또 다른 기여 방식은 로드 밸런싱 장치가 인커밍 작업을 관리 서버로 파견하는 방식에 영향을 주어서 기대한 응답 시간 내에서 이들을 가장 잘 처리할 수 있다고 판단되는 서버로 요청들이 보내질 수 있도록 하는 것이다. 그러나 이 문제는 이 글의 주제는 아니다.
관리 루프
파티션 관리 흐름은 이렇다. MS 프로세스가 시작되면 이 프로세스에서 실행되는 플랫폼이 파티션 관리를 할 수 있는지를 검사한다. 만약 관리가 가능하다면 MS는 플랫폼 정보를 DM에게 보내고, 모든 가상 그룹과 멤버를 추적한다.
가상 그룹은 특정 머신 상에서 같은 워크로드 그룹(HMC에서의 설정)의 일부인 파티션을 나타낸다. 같은 머신 상의 여러 가상 그룹이 있겠지만 가상 그룹은 머신 영역들간 확장될 수 없다. 가상 그룹의 실제 구현은 9117-570107CCEE-111처럼, 머신 모델, 시리얼 넘버, 워크로드 그룹 넘버가 연속적으로 되어있다. 따라서, 두 개의 다른 머신 상에 같은 워크로드 그룹 넘버를 설정한다면 결과 가상 그룹 ID는 각각 다르다. 따라서 EWLM은 그룹들 간 파티션 교환 기능을 할 수 없도록 한다. 사실, 다른 머신 상에서 파티션들간 용량 교환은 불가능하다.
또 다른 파티셔닝 후보 MS가 DM에 합류하면 기존 가상 그룹에 추가되거나 새로운 그룹이 시작된다. DM은 그룹의 총 용량이 용량 변화 동안 일정하게 유지되도록 보장한다. 그룹 용량은 멤버가 참여하거나 떠날 경우에만 변한다.
여러 가상 그룹들을 만들더라도 현재 구현에는 각 머신 상에 단 하나의 공유 프로세서 풀만 있다. 다시 말해서, Hypervisor는 프로세싱 사이클을 파티션에 파견할 때 워크로드 그룹 설정에 대해서는 관여하지 않는다. 결국, 서버에 여러 Uncapped 파티션이 있다면 워크로드 그룹과 관계 없이 같은 공유 프로세서 풀에서 리소스를 가져온다.
그림 5의 다이어그램에 모든 것이 요약되어 있다.
그림 5. Virtual Group과 Virtualization Agent 관계
글로벌 PI와 로컬 PI
글로벌 퍼포먼스 지수(PI)와 로컬 퍼포먼스 지수의 개념을 소개해야겠다. PI는 퍼포먼스 목표에 대해 서비스 클래스가 어떻게 작동하고 있는지를 숫자로 나타낸 것이다. 소수점 자리의 PI(PI < 1.0)는 서비스 클래스가 기대한 것 이상으로 잘 작동하고 있음을 의미하고, 1.0 (PI > 1.0) 보다 큰 PI는 서비스 클래스가 목표 달성을 하지 못하고 있다는 것을 나타낸다.
글로벌 PI는 일정 기간 동안 엔드투엔드, 서비스 클래스에서의 모든 트랜잭션에 대한 전체 점수이다. 이 트랜잭션들은 매번 여러 노드들을 트래버스 하고 많은 클러스터들로 분산된다. 몇몇 트랜잭션들은 다른 것들보다 빨리 완료된다. 실제 작업의 본질상 그럴 수도 있고 아니면 이를 처리하는 노드의 조건 때문일 수 있다. 몇몇 노드들은 더 강력하고 보다 여유가 있다. 어떤 것은 덜 강력하고 다른 작업을 하느라 바쁘다.
따라서 각 노드의 MS는 로컬 PI를 관리하여 퍼포먼스 목표에 따라서 얼마나 잘 수행하는지를 나타내고, 심지어 (DB2 홉처럼) 작업의 일부를 수행할 때도 나타낸다. 한 파티션에서 로컬 PI가 형편없다면, 글로벌 PI가 잘 수행되더라도 MS는 도움을 요청 할 것이다. 다섯 개 노드의 클러스터가 있고, 이 중 네 개는 잘 수행되고(로컬 PI+0.2), 나머지 하나가 심각하게 나쁘면(로컬 PI = 2.0), 이 경우 글로벌 PI는 0.56이 될 것이고, 이는 이 그룹에서 굼벵이 엘리먼트임에도 불구하고, 여전히 매우 좋은 상태(0.2 * 4 + 2.0 = 2.8 / 5 = 0.56)인 것이다. 로컬 PI는 EWLM이 그룹들 간 가장 나쁜 퍼포먼스를 보이는 것을 구분하도록 하고, 전체 점수가 좋아 보이더라도 도움을 요청한다.
도움 요청과 평가
이제 재미있는 부분만 남았다. 서비스 클래스가 퍼포먼스 목표를 달성하지 못한다면 어떻게 될까? 많은 경우 다음과 같을 것이다. MS는 더 많은 프로세싱 파워를 얻으면 상황이 호전될 것인지를 판단한다. 원인이 프로세서 병목현상이 아니라면 MS는 아무것도 하지 않는다. 만약 병목현상 때문이라면, MS는 도움 요청(plea for help)을 DM에게 보낸다. DM은 잠재적 후보 리스트를 검사하는데, 여기에는 같은 가상 그룹에 있는 모든 관리 파티션이 포함되어 있고, 각자에게 기존 워크로드에서 어느 정도의 리소스를 포기할 경우의 영향력을 평가해줄 것을 요청한다. 각 MS는 평가 요청에 대해, 어느 정도의 리소스를 포기할 수 있는지를 알려준다. 중요도가 높거나 리소스를 기여하는 것이 너무나 부정적인 영향을 일으킨다면 어떤 것도 포기할 수 없다.
모든 응답을 받은 후에 DM은 향상이 가능한지의 여부를 평가한다. 가능하다면, 기여자에게 할당된 용량을 줄일 것을 명령하고, 결국 모든 기여자들은 그렇게 한다. 수혜자에게는 기여 받은 것의 합계로 할당 용량을 늘릴 것을 명령한다. 워크로드가 예상한 대로 스케일링 되면, 용량이 증가하고, 모든 사람들이 행복해진다.
하지만 현실은 그렇게 단순하지가 않다. 그렇게 순조롭게 진행되는 경우는 별로 없다. 예를 들어, 형편없이 작동하는 서비스 클래스를 가진 MS는 이미 최대 할당 용량 상태에 있고, 도움을 줄 수도 없다. 잠재적 기여자가 이미 최소 용량 상태에 있기 때문에 어떤 것도 기부할 수 없다. 이러한 시나리오 외에도 DM은 동시에 여러 요청들을 받게 된다. 이 경우 가장 높은 우선 순위만 채택하고 나머지는 무시한다.
EWLM이 무엇을 해야 하는지를 몰라서 어떤 것도 수행하지 않는 상황도 있다. 예를 들어, 서비스 클래스의 PI가 너무 크면(PI > 100), MS가 서비스 클래스를 만족시키기 위해 용량을 많이 늘리게 되고, 이는 공유 프로세서 풀에 있는 것 보다 더 많은 것을 요청하는 상황이 되어 MS가 최대 할당을 넘기게 된다. 이와 같은 경우 어떤 것도 발생하지 않는다. 이러한 상황은 형편없이 정의된 퍼포먼스 목표나 결함이 많은 시스템이 워크로드를 다루려고 할 때 발생한다. PI가 높으면 퍼포먼스 목표가 잘못 정의되었는지, 아니면 시스템이 요청을 제공하는데 문제(교착 상태, 메모리 부족, 시스템 에러)가 있는지 여부를 알려줄 쉬운 방법이 없다. 오직 시스템 관리자만이 이를 파악할 수 있다.
맺음말
게임의 규칙은 다음과 같다:
- 필요한 하드웨어와 소프트웨어 리스트를 면밀히 파악했다.
- HMC에 파티션을 설정하는 방법을 상세히 설명했다:
- 네 가지 중요한 설정: 프로세싱 노드, 프로세싱 단위, 가상 프로세서, 공유 모드
- 워크로드 그룹의 파티셔닝 방법
- 공유 프로세서 풀 우선순위를 할당하는 방법
- EWLM 파티션 관리 알고리즘을 설명했다:
- 파티션 관리의 흐름
- 글로벌 퍼포먼스 지수와 로컬 퍼포먼스 지수를 분석
- 도움 요청들을 발견하고 이들을 평가하는 방법
다음 글에서는, 테스트 환경의 토폴로지와 사용된 워크로드부터 설명하겠다. 도메인 정책에 대해서도 알아보고, 워크로드를 실행하고, EWLM의 파티션 관리 액션들을 설명하겠다.
기사의 원문보기
다운로드 하십시오 | 설명 | 이름 | 크기 | 다운로드 방식 |
|---|
| Requirement and configuration checklist | ac-ewlm-lpar1source.zip | 3KB | HTTP |
|---|
참고자료 교육
제품 및 기술 얻기
토론
필자소개 | 
| | CheKim Chhuor는 현재 System Verification Test 팀에서 일하고 있다. 웹 인프라 컨설팅 분야에서 오랜 경력을 쌓았으며 IBM WebSphere®, DB2®, e-business 인증을 보유하고 있다. 현재 자율 컴퓨팅과 그리드에 관심을 갖고 있다. chhuor@us.ibm.com. |
기사에 대한 평가
| 
