KR101606613B1

KR101606613B1 - 자원관리방법과 컴퓨터 프로그램제품 및 시스템

Info

Publication number: KR101606613B1
Application number: KR1020117022955A
Authority: KR
Inventors: 롭 파이크
Original assignee: 마이크로소프트 테크놀로지 라이센싱, 엘엘씨
Priority date: 2009-03-31
Filing date: 2010-03-26
Publication date: 2016-03-25
Also published as: WO2010117691A2; US20100251253A1; CA2753714C; EP2414934B1; CN102378962A; KR20120017411A; US8595740B2; EP2414934A4; CA2753714A1; WO2010117691A3; JP2012522320A; US9274844B2; EP2414934A2; JP5680619B2; US20140157281A1

Abstract

컴퓨터 시스템 자원을 관리하기 위한 시스템, 방법 및 컴퓨터 프로그램제품을 여기에 개시한다. 다수의 모듈(예를 들면 가상 머신 또는 다른 애플리케이션)은 다수의 컴퓨터 시스템 자원(예를 들면 프로세서, 서버 등)에 걸쳐 할당될 수 있다. 각 모듈은 우선순위 레벨을 배정받는다. 또한 컴퓨터 시스템의 각 자원은 지정된 이용 레벨을 배정받는다. 각 자원은 하나 이상의 모듈을 지원하고, 대응하는 배정된 우선순위 레벨에 따라서 지원 모듈의 동작을 우선순위화한다. 더욱이 각 자원은 지정된 이용 레벨에서 지원 모듈의 동작을 유지한다.

Description

자원관리방법과 컴퓨터 프로그램제품 및 시스템{PRIORITY-BASED MANAGEMENT OF SYSTEM LOAD LEVEL}

본 발명은 일반적으로 시스템 부하 레벨(system load level)의 관리에 관한 것이다.

기업 데이터센터와 같은 컴퓨터 시스템은 종종 실행하는 애플리케이션을 가진 다수의 서버를 포함한다. 서버는 통상적으로 비교적 저 효율로 동작한다. 예를 들면 일부 서버는 10-30%의 부하를 가질 수 있다. 가상화는 서버에게 가상 머신을 할당함으로써 효율성을 개선하는데 사용될 수 있지만, 각 서버는 할당된 가상 머신(들)이 사용중이 아닌 경우에 여전히 10-30% 부하를 가질 것이다. 또한 애플리케이션 요구는 시간에 걸쳐 변할 수 있어, 서버의 부하 변동을 일으킨다.

흔히 비교적 높은 효율성으로 서버를 동작시키는 것이 바람직할 지라도, 잠재적인 애플리케이션 요구 증가를 수용하기 위해 비교적 보다 낮은 효율성으로 서버를 운영하는 것이 이로울 수 있다. 서버의 효율성을 너무 높게 설정하면, 서버는 증가된 애플리케이션 요구를 수용할 수 없을 수도 있다. 예를 들어 서버가 증가된 요구를 수용하는데 실패하면 애플리케이션에 의한 일부 요청에 응답할 수 없게 될 수도 있다. 반면에, 서버의 효율성을 너무 낮게 설정하면, 서버는 증가된 애플리케이션의 요구를 수용해기 위해 필요 효율보다 더 비효율적으로 동작할 수 있다.

서버의 부하 레벨을 관리하기 위해 제안되는 일 기법은 요구가 전송되어 오는 서버의 부하를 감소시키기 위해 다른 서버로 애플리케이션의 요구를 전송하는 것이다. 그러나 제안된 이 기법은 상당한 시간과 노력을 필요로 할 수 있다. 예를 들어 애플리케이션의 요구를 수용하는데 사용가능한 충분한 자원을 가진 서버를 찾는데 검색을 필요로 할 수 있다. 일단 이러한 서버를 발견하면, 요구를 전송하기 위해 프로세스를 사용하는 식으로 진행된다.

컴퓨터 시스템 자원을 관리하기 위한 시스템, 방법 및 컴퓨터 프로그램 제품을 여기에 기술한다. 다수의 모듈(예를 들어 가상 머신, SQL 서버 인스턴스(SQL server instances), 또는 다른 애플리케이션)이 다수의 컴퓨터 시스템 자원(예를 들어 프로세서, 서버 등)에 걸쳐 할당될 수 있다. 각 모듈은 우선순위 레벨(priority level)을 배정받는다. 또한 지정된 이용 레벨(utilization level)이 컴퓨터 시스템의 각 자원으로 배정된다. 각 자원은 하나 이상의 모듈을 지원하고, 대응하는 배정된 우선순위 레벨에 따라서 지원 모듈의 동작을 우선순위화한다. 또한 각 자원은 지정된 이용 레벨에서 지원 모듈의 전체 동작을 관리한다.

방법 예에서, 이용 표시기(utilization indicator)를 수신한다. 이용 표시기는 처리 시스템의 자원과 관련된 기준 이용 레벨을 나타낸다. 각 자원은 부하 레벨이 기준 이용 레벨과 실질적으로 동일하게 되도록 유지시키기 위해 관리된다. 각 자원의 처리 용량(processing capacity)은 애플리케이션 모듈과 관련된 기준 이용 레벨과 우선순위 레벨을 기반으로 자원상에서 실행되는 애플리케이션 모듈들 간에 할당된다.

다른 방법 예에서, 처리 시스템 자원이 기준 이용 레벨을 수신한다. 애플리케이션 모듈은 자원에 대하여 실행한다. 자원의 처리 용량은 자원의 부하 레벨이 기준 이용 레벨과 사실상 동일하게 되도록 애플리케이션 모듈과 관련된 우선순위 레벨을 기반으로 애플리케이션 모듈들 간에 할당된다.

또한 컴퓨터 프로그램 제품을 기술한다. 컴퓨터 프로그램 제품은 프로세서기반 시스템이 자원을 관리할 수 있도록 하는 컴퓨터 프로그램 논리가 기록된 컴퓨터 판독가능 매체를 포함한다. 컴퓨터 프로그램 제품은 제 1 및 제 2 프로그램 논리 모듈을 포함한다. 제 1 프로그램 논리 모듈은 프로세서기반 시스템이 자원에 대해 애플리케이션 모듈을 실행할 수 있도록 하기 위한 것이다. 자원의 부하 레벨이 기준 이용 레벨과 사실상 동일하게 되도록, 제 2 프로그램 논리 모듈은 프로세서기반 시스템이 애플리케이션 모듈과 관련된 우선순위 레벨을 기반으로 애플리케이션 모듈들 간에 자원의 처리 용량을 할당할 수 있도록 해준다.

이 요약은 상세한 설명에서 더 후술되는 개념 선택을 간단한 형태로 소개하기 위해 제공된다. 이 요약은 청구 주제의 주요 특징 또는 핵심적 특징을 확인하려는 것이 아니며, 또한 청구 주제의 범주를 제한하는데 사용하려는 것도 아니다. 또한 본 발명은 이 문서의 상세한 설명 및/또는 다른 섹션에 기술된 특정 실시예로 제한되지 않는다는 데에 주목한다. 이러한 실시예는 단지 설명을 위해 여기에 제공된다. 추가 실시예는 여기에 포함된 설명을 기반으로 당업자에게 명백할 것이다.

도 1은 본 발명의 실시예에 따른 처리 시스템의 예의 블록도.
도 2는 본 발명의 실시예에 따른 처리 시스템을 관리하기 위한 방법의 흐름도.
도 3은 본 발명의 실시예에 따라서, 도 1에 도시된 부하 레벨 관리 시스템의 구현 예의 블록도.
도 4는 본 발명의 실시예에 따라서 자원을 관리하기 위한 방법의 흐름도.
도 5는 본 발명의 실시예에 따라서 도 1에 도시된 자원의 구현 예의 블록도.
도 6은 본 발명의 실시예에 따라서 관리되는 부하 레벨을 가진 다수의 자원을 도시하는 도면.
도 7은 본 발명의 실시예를 구현할 수 있는 대표적인 컴퓨터의 구현을 도시하는 도면.

여기에 병합되어 명세서의 일부를 형성하는 첨부 도면은 본 발명을 도시하고, 구체적인 내용과 함께 더 나아가 본 발명의 원리를 설명하고, 당업자가 본 발명을 만들고 사용할 수 있도록 하는 역할을 한다.

본 발명의 특징 및 이점은 도면과 함께 취할 시에 후술되는 상세한 설명으로부터 보다 명백해질 것이며, 여기서 동일한 참조 문자는 도면에 걸쳐 대응한 요소를 지칭한다. 도면에서, 동일한 참조번호는 일반적으로 동일하고 기능적으로 유사하며, 및/또는 구조적으로 유사한 요소를 가리킨다. 요소가 제일 먼저 나타나는 도면은 대응한 참조번호의 최좌측 숫자(들)에 의해 표시된다.

1. 도입

다음의 상세한 설명은 본 발명의 대표적인 실시예를 도시하는 첨부도면을 참조한다. 그러나 본 발명의 범주는 이들 실시예로 제한되지 않고, 대신에 첨부된 청구범위에 의해 정의된다. 따라서 도시된 실시예의 변경 버전과 같이 첨부도면에 도시된 바를 넘어선 실시예는 그럼에도 불구하고 본 발명에 포함될 수 있다.

명세서에서 "일 실시예", "실시예", "예인 실시예" 등에 대한 참조는 기술된 실시예가 특정한 특징, 구조 또는 특성을 포함할 수 있지만, 모든 실시예가 특정한 특징, 구조 또는 특성을 반드시 포함할 필요는 없을 수도 있다는 것을 나타낸다. 또한 이러한 구절은 동일한 실시예를 반드시 참조할 필요가 없다. 더욱이 특정한 특징, 구조 도는 특성이 실시예와 관련하여 기술될 때, 이는 명확히 기술되었든지 간에 다른 실시예와 관련하여 이러한 특징, 구조 또는 특성을 구현하기 위해 당업자의 지식내에 있다고 본다.

2. 시스템 부하 레벨의 우선순위기반 관리를 위한 실시예

본 발명의 실시예는 컴퓨터 시스템 자원을 관리할 수 있다. 모듈(예를 들면 가상 머신, SQL 인스턴스, 또는 다른 애플리케이션)은 다수의 컴퓨터 시스템 자원(예를 들면 프로세서, 서버 등)에 걸쳐 할당된다. 각 모듈은 다른 모듈에 대한 그 모듈의 우선순위의 표시인 우선순위 레벨을 배정받는다. 더욱이 지정된 이용 레벨은 컴퓨터 시스템의 각 자원에 배정된다. 각 자원은 하나 이상의 모듈을 지원하고, 대응한 배정된 우선순위 레벨에 따라서 지원 모듈의 동작을 우선순위화한다. 더욱이 각 자원은 지정된 이용 레벨에서 지원 모듈의 동작을 유지한다. 이 방식에서, 자원의 보다 효율적인 이용을 성취할 수 있다.

도 1은 실시예에 따른 처리 시스템(100) 예의 블록도이다. 처리 시스템(100)은 부하 레벨 관리 시스템(102), 다수의 자원(110a-110r) 및 행정(admin) 시스템(112)을 포함한다. 각 자원(110)은 하나 이상의 애플리케이션을 지원한다. 예를 들면 제 1 자원(110a)은 애플리케이션 모듈(104a-104m)을 지원하고, 제 2 자원(110b)은 애플리케이션 모듈(106a-106n)을 지원하는 등으로 된다.

행정 시스템(112)은 부하 레벨 관리 시스템(102)에 이용 표시기(114)를 제공하도록 구성된다. 이용 표시기(114)는 처리 시스템(100)의 자원(110)을 위한 기준 이용 표시이다. 예를 들면 부하 레벨 관리 시스템(102)은 처리 시스템(100)의 자원(110)과 관련된 기준 이용 레벨을 결정하기 위해 이용 표시기를 사용할 수 있다. 기준 이용 레벨은 예를 들면 각 자원(110)의 목표 부하 레벨에 대응할 수 있다.

행정 시스템(112)은 부하 레벨 관리 시스템(102)에 하나 이상의 우선순위 표시기를 제공하도록 더 구성될 수 있거나, 또는 우선순위 표시기(들)는 다른 방식으로 제공될 수 있다. 우선순위 표시기는 다른 모듈에 대한 특정 애플리케이션 모듈의 우선순위를 가리키는, 애플리케이션 모듈(104a-104m, 106a-106n 등) 중의 하나에 대한 우선순위 표시이다. 예를 들어 행정 시스템(112)은 웹 브라우저(116), 또는 행정 시스템(112)에서 다른 사용자 인터페이스를 통해 각 이용 레벨 및/또는 우선순위 레벨을 선택하는 행정 시스템(112)의 사용자에 응답하여 이용 표시기(114) 및/또는 우선순위 표시기를 제공할 수 있다. 부하 레벨 관리 시스템(102)은 그 이상의 처리를 위해 하나 이상의 자원(110)으로 우선순위 표시기를 전송할 수 있다.

부하 레벨 관리 시스템(102)은 자원(110)을 관리하도록 구성됨으로써, 각 자원의 부하 레벨은 기준 이용 레벨과 실질적으로 동일하다. 예를 들어 부하 레벨 관리 시스템(102)은 각 자원(110)으로부터 수신한 부하 레벨 표시기를 기반으로 각 자원(110)의 평균 또는 순간 부하 레벨을 결정하도록 구성될 수 있다. 부하 레벨 관리 시스템(102)은 자원(110)의 부하 레벨이 증가 또는 감소될 것인지의 여부를 결정하기 위해 자원(110)의 순간 또는 평균 부하 레벨과 기준 이용 레벨을 비교할 수 있어, 자원(110)의 부하 레벨은 기준 이용 레벨과 실질적으로 동일하다. 다른 실시예에서, 부하 레벨 관리 시스템(102)은 각 자원(110)으로 기준 이용 레벨을 제공하고, 각 자원(110)은 기준 이용 레벨과 실질적으로 동일한 그의 부하 레벨을 유지하도록 구성된다.

애플리케이션 모듈(104a-104m, 106a-106n 등)은 이들 애플리케이션 모듈이 관련된 각 자원(110a-110r)의 처리 용량을 소비하는 동작을 수행하도록 구성된다. 예를 들어 애플리케이션 모듈(104a-104m)은 제 1 자원(110a)의 처리 용량을 소비하고, 애플리케이션 모듈(106a-106n)은 제 2 자원(110b)의 처리 용량을 소비하는 등으로 된다. 애플리케이션 모듈(104)의 예는 소프트웨어 애플리케이션, 가상 머신, SQL 서버 인스턴스 등을 포함하지만 이로 제한되지는 않는다.

자원(110a-110r)은 각 애플리케이션 모듈(104a-104m)에 의해 수행되는 동작을 용이하게 하기 위한 처리 용량을 제공하도록 구성된다. 예인 자원(110)은 서버, 프로세서, 다수의 프로세서 등을 포함하지만 이로 제한되지 않는다.

제 1 실시예에서, 애플리케이션 모듈(104a-104m, 106a-106n 등)은 가상 머신으로 구현되고, 자원(110a-110r)은 프로세서로서 구현된다. 예를 들어 프로세서는 프로세서의 부하 레벨이 이 프로세서와 관련된 기준 이용 레벨과 실질적으로 동일하게 되도록 각 가상 머신의 우선순위를 기반으로 가상 머신들 간에 그들의 처리 용량을 할당할 수 있다.

제 2 실시예에서, 애플리케이션 모듈(104a-104m, 106a-106n 등)은 SQL 서버 인스턴스로서 구현되고, 자원(110a-110r)은 서버로서 구현된다. 예를 들어 서버는 서버의 부하 레벨이 이 서버와 관련된 기준 이용 레벨과 실질적으로 동일하게 되도록 각 SQL 서버 인스턴스의 우선순위를 기반으로 SQL 서버 인스턴스들 간에 그들의 처리 용량을 할당할 수 있다.

이들 예인 실시예는 설명을 위해 제공되며 제한하려는 것이 아니다. 당업자는 애플리케이션 모듈(104a-104m, 106a-106n 등)이 임의의 적당한 유형의 모듈로서 구현될 수 있다는 것을 알 것이다. 자원(110a-110r)은 각 애플리케이션 모듈(104a-104m, 106a-106n 등)에 의해 수행되는 동작을 용이하게 하기 위한 처리 용량을 제공할 수 있다는 임의의 적당한 유형의 자원일 수 있다는 것을 더 알 것이다.

도 2는 실시예에 따라서 처리 시스템을 관리하기 위한 방법의 흐름도(200)를 도시한다. 흐름도(200)는 예를 들어 도 1에 도시된 부하 레벨 관리 시스템(102)에 의해 수행될 수 있다. 설명을 위하여, 흐름도(200)는 실시예에 따라서 부하 레벨 관리 시스템(102)의 예인 도 3에 도시된 부하 레벨 관리 시스템(102')에 대하여 기술한다. 도 3에 도시된 바와 같이, 부하 레벨 관리 시스템(102')은 인터페이스 모듈(302)과 관리 모듈(304)을 포함한다. 보다 구조적이며 동작적인 실시예는 흐름도(200)에 관해 거론한 바를 기반으로 당업자에게 명백할 것이다. 흐름도(200)는 후술하는 바와 같다.

도 2에 도시된 바와 같이, 흐름도(200)의 방법은 단계(202)에서 시작한다. 단계(202)에서, 처리 시스템의 다수의 자원과 관련된 기준 이용 레벨을 나타내는 이용 표시기를 수신한다. 예를 들면 인터페이스 모듈(302)은 이용 표시기를 수신할 수 있다. 실시예에서, 행정 시스템(112)은 기준 이용 레벨의 선택을 가능하게 하기 위해 사용자 인터페이스 요소를 제공하도록 구성된다. 인터페이스 모듈(302)은 사용자 인터페이스 요소를 통해 기준 이용 레벨을 선택하는 사용자에 응답하여 이용 표시기(114)를 수신할 수 있다.

실시예에 따라서, 행정 시스템(112)은 애플리케이션 모듈(104a-104m, 106a-106n 등)과 관련된 하나 이상의 우선순위 레벨의 선택을 가능하게 하기 위해 사용자 인터페이스 요소를 제공하도록 구성될 수 있다. 인터페이스 모듈(302)은 사용자 인터페이스 요소를 통해 우선순위 레벨을 선택하는 사용자에 응답하여 각 우선순위 레벨에 대응한 우선순위 표시기를 수신할 수 있다. 전술한 사용자 인터페이스 요소의 각각은 텍스트 기반 인터페이스, 그래픽 인터페이스 요소(예를 들면 팝업, 드롭다운(drop-down) 또는 이와 동등한 메뉴), 또는 다른 사용자 인터페이스 요소일 수 있다.

단계(204)에서, 기준 이용 레벨과 각 자원의 부하 레벨을 사실상 동일하도록 유지시키기 위해 처리 시스템의 자원을 관리한다. 예를 들어 관리 모듈(304)은 처리 시스템의 자원을 관리할 수 있다. 이 예에 따라서, 관리 모듈(304)은 처리 시스템(100)의 각 자원(110a-110r)으로 유지보수 표시기(maintenance indicator)(306a-306r)를 제공할 수 있다. 유지보수 표시기(306a-306r)는 자원(110)에 대한 부하 레벨 유지보수 표시기이다. 예를 들어 각 자원(110)은 각 유지보수 표시기(306)를 사용함으로써, 자원(110)의 부하 레벨을 기준 이용 레벨과 실질적으로 동일하게 유지시키기 위해 그 자원(110)의 부하 레벨을 증가 또는 감소시킬 것인 지의 여부를 결정할 수 있다. 예를 들면 각 자원(110)은 기준 이용 레벨에 의해 표시되는 부하 레벨과 현재 부하 레벨을 비교하도록, 그리고 현재 부하 레벨과 기준 이용 레벨 사이에 파악된 어떠한 차이에 따라서도 부하 레벨을 조정하도록 구성될 수 있다.

구현 예에서, 처리 시스템의 자원은 각 자원의 평균 부하 레벨이 기준 이용 레벨과 실질적으로 동일하게 되도록 유지보수시키기 위해 관리될 수 있다. 예를 들어 부하 레벨은 몇 분의 일 초, 수 초, 수 분, 수 시간 등에 걸쳐서 평균화될 수 있다.

각 자원의 처리 용량은 애플리케이션 모듈과 관련된 기준 이용 레벨과 우선순위 레벨을 기반으로 그 자원상에 실행되는 다수의 애플리케이션 모듈들 간에 할당된다. 예를 들어 제 1 자원의 처리 용량은 제 1 자원상에서 실행되는 제 1 다수의 애플리케이션 모듈들 간에 할당될 수 있다. 제 2 자원의 처리 용량은 제 2 자원상에서 실행되는 제 2 다수의 애플리케이션 모듈들 간에 할당될 수 있는 등으로 된다. 예를 들면 비교적 높은 우선순위를 가진 애플리케이션 모듈은 비교적 낮은 우선순위를 가진 애플리케이션 모듈보다 자원의 더 많은 처리 용량을 할당받을 수 있다. 다른 예에서, 비교적 낮은 우선순위를 가진 애플리케이션 모듈은 비교적 높은 우선순위를 가진 애플리케이션 모듈보다 더 적은 처리 용량을 할당받을 수 있다.

도 4는 실시예에 따라서 자원을 관리하기 위한 방법의 흐름도(400)를 도시한다. 흐름도(400)는 예를 들어 도 1에 도시된 임의의 자원(110a-110r)에 의해 수행될 수 있다. 설명을 위하여, 흐름도(400)는 실시예에 따라서 자원(110)의 예인 도 5에 도시된 자원(110')에 대하여 기술한다. 도 5에 도시된 바와 같이, 자원(110')은 수신 모듈(502), 실행 모듈(504) 그리고 할당 모듈(506)을 포함한다. 보다 구조적이고 동작적인 실시예는 흐름도(400)에 관해 거론한 바를 기반으로 당업자에게 명백할 것이다. 흐름도(400)는 다음과 같이 기술된다.

도 4에 도시된 바와 같이, 흐름도(400)의 방법은 단계(402)에서 시작한다. 단계(402)에서, 기준 이용 레벨을 수신한다. 예를 들어 수신 모듈(502)은 유지보수 표시기(306) 또는 다른 표시기를 통해 이용 레벨을 수신할 수 있다.

단계(404)에서, 처리 시스템의 자원상에서 다수의 동작 모듈이 실행된다. 예를 들어 실행 모듈(504)은 자원상에서 다수의 애플리케이션 모듈을 실행할 수 있다. 자원은 예를 들어 자원(110')일 수 있다.

단계(406)에서, 자원의 부하 레벨이 기준 이용 레벨과 실질적으로 동일하게 되도록, 다수의 애플리케이션 모듈과 관련된 다수의 우선순위 레벨을 기반으로 다수의 애플리케이션 모듈들 간에 자원의 처리 용량이 할당된다. 예를 들면 할당 모듈(506)은 다수의 애플리케이션 모듈들 간에 자원의 처리 용량을 할당할 수 있다. 할당 모듈(506)은 수신 모듈(502)로부터 유지보수 표시기(306)를 수신할 수 있다. 예를 들어 할당 모듈(506)은 자원의 부하 레벨이 기준 이용 레벨과 실질적으로 동일하게 되도록 다수의 애플리케이션 모듈들 간에 할당할 자원의 총 처리 용량의 양을 결정하는데 유지보수 표시기(306)를 사용할 수 있다.

할당 모듈(506)은 각 애플리케이션 모듈에 할당할 총 처리 용량의 결정된 양의 부분을 결정하기 위해 다수의 우선순위 레벨을 사용할 수 있다. 예를 들어 할당 모듈(506)은 제 1 애플리케이션 모듈과 관련된 제 1 우선순위 레벨을 기반으로 결정된 양의 제 1 부분을 제 1 애플리케이션 모듈에 할당할 수 있다. 할당 모듈(506)은 제 2 애플리케이션 모듈과 관련된 제 2 우선순위 레벨을 기반으로 결정된 양의 제 2 부분을 제 2 애플리케이션 모듈로 할당할 수 있는 등으로 된다.

실시예에서, 수신 모듈(502)은 자원에서 실행하는 모듈의 우선순위 레벨을 나타내는 우선순위 표시기를 수신할 수 있다. 우선순위 표시기는 예를 들어 부하 레벨 관리 시스템(102)으로부터 수신한 유지보수 표시기(306)에 표시될 수 있다. 수신 모듈(502)은 추가 처리를 위해 우선순위 표시기에 의해 표시된 우선순위 표시기 또는 우선순위 레벨을 할당 모듈(506)로 전송할 수 있다. 이 대신에, 각 모듈(502)은 각 우선순위 레벨을 이미 배정받았을 수도 있다.

할당 모듈(506)은 제 2 애플리케이션 모듈을 위해 자원(110')의 처리 용량의 가용성을 용이하게 하기 위해 제 1 우선순위 레벨을 가진 제 1 애플리케이션 모듈로부터 제 1 우선순위 레벨보다 큰 제 2 우선순위 레벨을 가진 제 2 애플리케이션 모듈로 자원(110')의 처리 용량을 전송할 수 있다. 구현 예에서, 할당 모듈(506)은 제 1 우선순위 레벨이 제 2 우선순위 레벨을 초과하는 것을 기반으로 제 2 애플리케이션 모듈로부터 요청(508)을 수신시에 제 1 애플리케이션 모듈로부터의 처리 용량을 제 2 애플리케이션 모듈로 자동적으로 전송하도록 구성될 수 있다. 예를 들어 할당 모듈(506)은 처리 용량의 가용성을 용이하게 하기 위하여 제 1 애플리케이션의 부하 레벨을 실질적으로 0으로 설정할 수 있다.

각 애플리케이션 모듈의 우선순위와 기준 이용 레벨은 언제라도 변경될 수 있다. 예를 들어 도 3을 참조하면, 부하 레벨 관리 시스템(102')의 인터페이스 모듈(302)은 적어도 하나의 애플리케이션 모듈 각각에서의 적어도 하나의 개정된(revised) 우선순위 레벨을 나타내는 개정된 우선순위 표시기를 수신할 수 있다. 부하 레벨 관리 시스템(102')의 관리 모듈(304)은 유지보수 표시기(306)를 통해 자원(110')의 수신 모듈(502)로 적어도 하나의 개정된 우선순위 레벨의 표시를 제공할 수 있다. 자원(110')의 할당 모듈(506)은 적어도 하나의 개정된 우선순위 레벨을 기반으로 다수의 애플리케이션 모듈들 간에 자원의 처리 용량을 재할당할 수 있다.

다른 예에서, 부하 레벨 관리 시스템(102')의 인터페이스 모듈(302)은 자원(110')과 관련된 개정된 기준 이용 레벨을 나타내는 개정된 이용 표시기를 수신할 수 있다. 부하 레벨 관리 시스템(102')의 관리 모듈(304)은 유지보수 표시기(306)를 통해 자원(110')의 수신 모듈(502)로 개정된 이용 레벨 표시를 제공할 수 있다. 자원(110')의 할당 모듈(506)은 개정된 기준 이용 레벨을 기반으로 다수의 애플리케이션 모듈들 간에 자원의 처리 용량을 재할당할 수 있다. 각 애플리케이션 모듈로 할당된 자원의 일부는 변경된 우선순위 레벨(들) 및/또는 변경된 이용 레벨에 응답하여 비례적으로 조정될 수 있다.

일 양상에서, 개정된 이용 표시기는 예를 들어 사용자 인터페이스 요소를 통해 사용자가 즉석으로 기준 이용 레벨을 개정하는 것에 대한 응답으로 수신될 수 있다. 다른 양상에서, 개정된 기준 이용 레벨은 사전결정된 스케줄에 따라서 수신될 수 있다. 예를 들면 기준 이용 레벨은 하루 동안에 첫번째는 비교적 낮은 이용 레벨을 표시하도록 설정될 수 있다. 기준 이용 레벨은 그 하루 동안에 두번째는 비교적 보다 높은 이용 레벨을 표시하도록 개정될 수 있다. 따라서 할당 모듈(506)은 첫번째와 두번째 사이의 기간 동안에 자원(110')의 부하 레벨을 비교적 낮은 이용 레벨로 실질적으로 동일하게 되도록 하기 위해 다수의 애플리케이션들 간에 자원(110')의 처리 용량을 할당할 수 있다. 할당 모듈(506)은 두번째 이후의 기간 동안에 자원(110')의 부하 레벨이 비교적 보다 높은 이용 레벨과 실질적으로 동일하게 되도록, 다수의 애플리케이션 모듈들 간에 자원(110')의 처리 용량을 재할당할 수 있다.

도 6은 실시예에 따라서 관리되는 부하 레벨을 가진 다수의 자원(602)을 도시한다. 자원(602)은 설명을 위해 CPU(central processing units)로 도시되지만 이로 제한하려는 것은 아니다. 예를 들어 여기에 기술된 실시예의 범주가 이 양상으로 제한되지 않지만, 자원(602a-602d)은 공통 소켓에서 각 프로세서 코어를 나타낼 수 있다. 자원은 프로세서, 서버 등일 수 있다는 것을 알 것이다. 도 6에 도시된 바와 같이, 각 자원(602)은 설명을 위해 65%로 도시된 기준 이용 레벨(608)과 실질적으로 동일한 부하 레벨을 가지도록 관리된다. 기준 이용 레벨(608)은 0% 내지 100%의 범위에서 임의의 적당한 레벨로 설정될 수 있다.

자원(602)은 설명을 위해 가상 머신인 것으로 도시된 애플리케이션 모듈(604)을 실행한다. 당업자는 애플리케이션 모듈(604)이 가상 머신, SQL 서버 인스턴스 등일 수 있다는 것을 알 것이다. 도 6에 도시된 바와 같이, 애플리케이션 모듈(604a, 604b)은 자원(602a)상에서 실행된다. 애플리케이션 모듈(604c, 604d)은 자원(602b)상에서 실행된다. 애플리케이션 모듈(604e, 604f, 604g)은 자원(602c)상에서 실행된다. 애플리케이션 모듈(604h)은 자원(602d)상에서 실행된다. 각 자원(602)은 임의의 수의 애플리케이션 모듈(604)을 실행할 수 있다. 예를 들어 자원(602)은 수 백 또는 수 천개의 모듈을 실행할 수 있다.

각 애플리케이션 모듈(604)은 다른 모듈에 대한 그 모듈의 우선순위 표시인 우선순위 레벨(610)을 배정받는다. 우선순위 레벨(610)은 임의의 적당한 스케일을 기반으로 할 수 있다는 것을 알겠지만, 우선순위 레벨(610)은 설명을 위해 수치 값으로 도 6에 도시된다. 예를 들어 우선순위 레벨(610)은 1로부터 지정된 수(예를 들면 10, 50, 10,000 등)까지의 범위의 수일 수 있다. 다른 예에서, 우선순위 레벨(610)은 "상(high)", "중(medium)", 또는 "하(low)"의 값을 가질 수 있다. 비교적 높은 우선순위 레벨(610)을 가진 애플리케이션 모듈(604)은 비교적 보다 높은 업무 영향(business impact)을 가지는 것으로 간주될 수 있고, 반면에 비교적 낮은 우선순위 레벨(610)을 가진 애플리케이션 모듈(604)은 비교적 보다 낮은 업무 영향을 가지는 것으로 간주될 수 있다. 예를 들어 업무를 위한 중요하거나 또는 시간에 민감한 동작을 하는 애플리케이션 모듈(604)은 비교적 보다 높은 우선순위 레벨(610)을 배정받을 수 있다. 다른 예에서, 중요하지도 시간에 민감하지도 않은 동작을 하는 애플리케이션 모듈(604)은 비교적 보다 낮은 우선순위 레벨(610)을 배정받을 수 있다.

예를 들어 기업을 위한 수입을 창출하는 온라인 광고를 제공하는 광고 서버 또는 전단 웹 서버는 비교적 보다 높은 우선순위 레벨(610)과 관련될 수 있다. 로그 쉬핑(log shipping), 검색 크롤링(search crawling), 또는 인터넷상에서 정보 검색과 같은 후단 서비스를 수행하는 애플리케이션 모듈(604)은 비교적 낮은 우선순위 레벨(610)과 관련될 수 있다. 예를 들면 이러한 후단 서비스를 수행하기 위해 그 하루가 끝날 때까지 또는 그 시간 동안을 기다리는 일은 업무에 큰 영향을 주지 않을 수도 있다.

각 자원(602)은 대응하는 배정된 우선순위 레벨(610)에 따라서 자원(602)상에서 실행되는 애플리케이션 모듈(604)의 동작을 우선순위화한다. 예를 들어 자원(602a)은 우선순위 레벨(610a)에 따라서 애플리케이션 모듈(604a)의 동작을 우선순위화한다. 자원(602a)은 우선순위 레벨(610b)에 따라서 애플리케이션 모듈(604b)의 동작을 우선순위화하는 등으로 된다. 높은 우선순위 모듈(들)(604)로부터의 처리 용량에 대한 요청이 줄어들 때(wind-down), 보다 낮은 우선순위 모듈(604)은 그의 동작을 수행하기 위해 동적으로 즉시 "깨어날 수(wake up)" 있어, 모듈(604)이 관련된 자원(602)의 처리 용량을 이용한다. 일 양상에서, 자원(602)은 보다 높은 우선순위 모듈(들)(604)로부터의 처리 용량에 대한 요청이 줄어든다고 결정하는 것에 대한 응답으로, 자원(602)은 그 모듈(604)을 깨우기 위해 보다 낮은 우선순위 모듈(604)로 인스트럭션을 제공할 수 있다. 자원(602)은 보다 높은 우선순위 모듈(604)로부터의 처리 용량에 대한 요청을 수신시에 자원(602)의 처리 용량을 보다 높은 우선순위 모듈(604)로도 전송할 수 있다. 사실상, 자원(602)은 요청된 처리 용량을 보다 높은 우선순위 모듈(604)에 사용가능하게 만드는 것을 용이하게 하기 위하여 보다 낮은 우선순위 모듈(604)을 오프라인 상태로 만들 수 있다(즉 0%의 처리 용량 할당까지).

각 자원(602)의 부하 레벨이 기준 이용 레벨(608)과 실질적으로 동일하게 되도록, 애플리케이션 모듈(604)들 간에 처리 용량 할당을 수행한다. 할당 표시(612)는 각 애플리케이션 모듈(604)에 할당된 자원의 처리 용량 부분을 나타낸다. 예를 들어 할당 표시(612a)는 자원(602a)이 자원(602a)의 처리 용량의 10%를 애플리케이션 모듈(604a)로 할당한다는 것을 나타낸다. 자원(602a)는 애플리케이션 모듈(604a)에 배정된 우선순위 레벨(610a)을 기반으로 애플리케이션 모듈(604a)로 이 처리 용량을 할당한다. 할당 표시(612b)는 자원(602a)이 자원(602a)의 처리 용량의 55%를 애플리케이션 모듈(604b)에 할당한다는 것을 가리킨다. 자원(602a)은 애플리케이션 모듈(604b)에 배정된 우선순위 레벨(610b)를 기반으로 이 처리 용량을 애플리케이션 모듈(604b)에 할당한다. 애플리케이션 모듈들(604a, 604b)간에 할당된 자원(602a)의 처리 용량은 10% + 55% = 65%이고, 이는 기준 이용 레벨(608)과 동일하다.

비교적 높은 우선순위 레벨(610)을 가진 애플리케이션 모듈(604)은 애플리케이션 모듈(604)이 실행되는 자원(602)의 처리 용량의 비교적 높은 비율을 반드시 소비할 필요는 없을 수도 있다. 예를 들어, 애플리케이션 모듈(604d, 604g)의 각각이 비교적 높은 우선순위 레벨(610d, 610g)과 관련 있지만, 이들 애플리케이션 모듈은 각 자원(602b, 602c)의 처리 용량의 비교적 작은 양을 소비하는 것으로 도시된다. 예를 들면 애플리케이션 모듈(604d)은 7,950의 우선순위 레벨(610d), 그리고 자원(602d)의 처리 용량의 20%의 할당을 가진다. 다른 예에서, 애플리케이션 모듈(604g)은 8,300의 우선순위 레벨(610g), 그리고 자원(602c)의 처리 용량의 25%의 할당을 가진다.

자원(602)은 보다 높은 우선순위 모듈(604)이 처리 용량을 요청시에 보다 낮은 우선순위 모듈(604)로부터 보다 높은 우선순위 모듈(604)로 처리 용량을 전송하도록 구성될 수 있다는 데에 주목해야 한다. 예를 들면 자원(602)은 여기에 기술한 실시예에 따라서 애플리케이션 모듈(604d)이 처리 용량을 요청시에 애플리케이션 모듈(604c)로부터 애플리케이션 모듈(604d)로 처리 용량을 전송할 수 있다. 다른 예에서, 자원(602)은 여기에 기술한 실시예에 따라서 애플리케이션 모듈(604g)이 처리 용량을 요청시에 적어도 하나의 애플리케이션 모듈(604e, 604f)로부터의 애플리케이션 모듈(604g)로 처리 용량을 전송할 수 있다.

도 7은 실시예를 구현할 수 있는 컴퓨터(700)의 대표적인 구현을 도시한다. 도 1에 도시된 부하 레벨 관리 시스템(102), 자원(104), 행정 시스템(112), 또는 도 6에 도시된 자원(602) 중의 임의의 하나 이상은 컴퓨터(700)의 하나 이상의 특징 및/또는 다른 특징을 포함하여 컴퓨터(700)와 유사하게 구현될 수 있다. 컴퓨터(700)는 예를 들어 통상적인 퍼스널 컴퓨터, 모바일 컴퓨터, 또는 워크스테이션의 형태인 범용 컴퓨팅 장치일 수 있거나, 또는 컴퓨터(700)는 특수목적 컴퓨팅 장치일 수 있다. 여기에 제공된 컴퓨터(700)에 대한 서술은 설명을 위해 제공되며 제한하려는 것이 아니다. 실시예는 당업자에게 알려져 있는 바와 같이 컴퓨터 시스템의 다른 유형으로 구현될 수 있다.

도 7에 도시된 바와 같이, 컴퓨터(700)는 처리 유닛(702), 시스템 메모리(704), 그리고 시스템 메모리(704)를 포함한 다양한 시스템 구성요소를 처리 유닛(702)으로 연결하는 버스(706)를 포함한다. 버스(706)는 메모리 버스 또는 메모리 제어기, 주변 버스, 가속화 그래픽 포트, 그리고 다양한 버스 구조중의 임의의 버스 구조를 사용하는 프로세서 또는 로컬 버스를 포함한, 임의의 몇몇 유형중의 하나 이상의 버스 구조를 나타낸다. 시스템 메모리(704)는 ROM(read only memory)(708)과 RAM(random access memory)(710)을 포함한다. BIOS(basic input/output system)(712)는 ROM(708)에 저장된다.

또한 컴퓨터(700)는 다음의 드라이브중의 하나 이상을 가진다: 하드 디스크로부터 판독 및 이로 기록하기 위한 하드 디스크 드라이브(714), 분리식 자기 디스크(718)로부터 판독 또는 이로 기록하기 위한 자기 디스크 드라이브(716), 그리고 CD ROM, DVD ROM 또는 다른 광 매체와 같은 분리식 광 디스크(722)로부터 판독 또는 이로 기록하기 위한 광 디스크 드라이브(720). 하드 디스크 드라이브(714), 자기 디스크 드라이브(716) 및 광 디스크 드라이브(720)는 각각 하드 디스크 드라이브 인터페이스(724), 자기 디스크 드라이브 인터페이스(726), 그리고 광 드라이브 인터페이스(728)에 의해 버스(706)로 연결된다. 드라이브와 그들의 관련된 컴퓨터-판독가능 매체는 컴퓨터 판독가능 인스트럭션, 데이터 구조, 프로그램 모듈, 그리고 컴퓨터를 위한 다른 데이터의 비휘발성 저장소를 제공한다. 하드 디스크, 분리식 자기 디스크 및 분리식 광 디스크를 기술하였지만, 플래시 메모리 카드, 디지털 비디오 디스크, RAM, ROM의 다른 유형의 컴퓨터 판독가능 매체를 사용하여 데이터를 저장할 수 있다.

다수의 프로그램 모듈은 하드 디스크, 자기 디스크, 광 디스크, ROM 또는 RAM에 저장될 수 있다. 이들 프로그램은 운영체제(730), 하나 이상의 애플리케이션 프로그램(732), 다른 프로그램 모듈(734), 그리고 프로그램 데이터(736)를 포함한다. 여기에 기술한 바와 같이, 애플리케이션 프로그램(732) 또는 프로그램 모듈(734)은 예를 들어 부하 레벨 관리 시스템(102)을 구현하기 위한 컴퓨터 프로그램 논리부, 애플리케이션 모듈(104, 106, 108 등), 행정 시스템(112), 인터페이스 모듈(302), 관리 모듈(304), 수신 모듈(502), 실행 모듈(504), 할당 모듈(506), 애플리케이션 모듈(604), (흐름도 200의 임의의 단계를 포함한) 흐름도(200), 그리고/또는 (흐름도 400의 임의의 단계를 포함한) 흐름도(400)를 포함할 수 있다.

사용자는 키보드(738)와 포인팅 장치(740)와 같은 입력 장치를 통해 컴퓨터(700)로 커맨드와 정보를 입력할 수 있다. (도시되지 않은) 다른 입력 장치는 마이크로폰, 조이스틱, 게임 패드, 위성방송 수신 안테나, 스캐너 등을 포함할 수 있다. 이들 및 다른 입력 장치는 흔히 버스(706)에 연결된 직렬 포트 인터페이스(742)를 통해 처리 유닛(702)에 연결되지만, 병렬 포트, 게임 포트 또는 USB(universal serial bus)와 같은 다른 인터페이스에 의해 연결될 수 있다.

모니터(744) 또는 다른 유형의 디스플레이 장치는 비디오 어댑터(746)와 같은 인터페이스를 통해 버스(706)로 연결된다. 컴퓨터(700)는 모니터 외에도 스피커 및 프린터와 같은 (도시되지 않은) 다른 주변 출력 장치를 포함할 수 있다.

컴퓨터(700)는 네트워크 인터페이스 또는 어댑터(750), 모뎀(752), 또는 네트워크를 통한 통신을 설정하기 위한 다른 수단을 통해 네트워크(748)(예를 들어, 인터넷)에 연결된다. 내장형 또는 외장형 모뎀(752)은 직렬 포트 인터페이스(742)를 통해 버스(706)로 연결된다.

여기에 사용되는 바와 같이, 용어 "컴퓨터 프로그램 매체"와 "컴퓨터 판독가능 매체"는 일반적으로 하드 디스크 드라이브(714)와 관련된 하드 디스크, 분리식 자기 디스크(718), 분리식 광 디스크(722)와 같은 매체뿐만 아니라 플래시 메모리 카드, 디지털 비디오 디스크, RAM, ROM 등과 같은 다른 매체를 언급하는데 사용된다.

전술한 바와 같이, (애플리케이션 프로그램(732)과 다른 프로그램 모듈(734)을 포함한) 컴퓨터 프로그램 및 모듈은 하드 디스크, 자기 디스크, 광 디스크, ROM 또는 RAM에 저장될 수 있다. 또한 이러한 컴퓨터 프로그램은 네트워크 인터페이스(750) 또는 직렬 포트 인터페이스(742)를 통해 수신될 수 있다. 이러한 컴퓨터 프로그램은 실행되거나 또는 애플리케이션에 의해 로딩될 때에 컴퓨터(700)로 하여금 여기에 거론된 본 발명의 실시예의 특징을 구현하게 할 수 있다. 따라서 이러한 컴퓨터 프로그램은 컴퓨터(700)의 제어기를 나타낸다.

또한 실시예는 임의의 컴퓨터 사용가능 매체에 저장된 소프트웨어를 구비한 컴퓨터 프로그램 제품에 관한 것이다. 이러한 소프트웨어는 하나 이상의 데이터 처리장치에서 실행될 때에 데이터 처리 장치(들)로 하여금 여기에 기술된 바와 같이 동작하게 한다. 본 발명의 실시예는 현재 및 장래에 알려진 임의의 컴퓨터 사용가능 또는 컴퓨터 판독가능 매체를 사용한다. 컴퓨터 판독가능 매체의 예는 RAM, 하드 드라이브, 플로피 디스크, CD ROM, DVD ROM, 집(zip) 디스크, 테이프, 자기 저장장치, 광 저장장치, MEM, 나노기술기반 저장장치 등을 포함하며, 단 이로 제한되지는 않는다.

여기에 기술된 실시예는 종래의 부하 레벨 관리 기법에 비하여 다양한 이점을 가진다. 예를 들어 실시예는 시스템에 대한 지정된 부하 레벨을 성취하기 위해 모듈과 관련된 우선순위를 기반으로 자원상에 실행하는 애플리케이션 모듈들(예를 들면 가상 머신, SQL 서버 인스턴스 또는 다른 애플리케이션) 간에 자원(예를 들면 프로세서, 서버 등)의 처리 용량을 유리하게 할당할 수 있다. 예를 들어 실시예는 자원의 부하 레벨을 기준 이용 레벨과 실질적으로 동일하게 되도록 처리 용량을 할당할 수 있다. 각 자원의 부하 레벨은 공통 기준 이용 레벨 또는 상이한 각 기준 이용 레벨을 기반으로 관리될 수 있다.

소정 실시예에 따라서, 애플리케이션 모듈은 애플리케이션 모듈의 부하 레벨 변경을 수용하기 위해 일 자원으로부터 다른 자원으로 이동할 필요가 없다. 오히려, 자원의 처리 용량은 각 자원의 부하 레벨이 기준 이용 레벨과 실질적으로 동일하게 되도록 애플리케이션 모듈과 관련된 우선순위를 기반으로 자원상에 실행되는 애플리케이션 모듈들 간에 할당될 수 있다.

여기에 기술된 실시예는 설명을 위한 것으로 제한하려는 것이 아닌 처리 시스템의 자원상에서 실행되는 애플리케이션 모듈과 관련하여 거론된다. 당업자는 여기에 기술된 부하 레벨 관리 기법이 다양한 다른 환경에 적용될 수 있다는 것을 알 것이다. 예를 들어, 이 기법은 각 비휘발성 저장장치의 부하 레벨이 기준 이용 레벨과 실질적으로 동일하게 되도록 장치와 관련된 우선순위 레벨을 기반으로 다수의 소프트웨어 및/또는 하드웨어 장치 간에 하나 이상의 비휘발성 저장장치(예를 들면 하드 드라이브 또는 이의 부분, 메모리 장치 등)의 입력/출력(I/O) 용량을 할당하는 데 사용될 수 있다. 다른 예에서, 이 기법은 다수의 호스트(예를 들어 컴퓨터)와 통신하는 자원의 부하 레벨을 관리하는데 사용될 수 있다. 자원의 처리 용량은 여기에 배정된 우선순위에 따라서 다수의 호스트들 간에 할당될 수 있어, 자원의 부하 레벨은 기준 이용 레벨과 실질적으로 동일하다.

결론

본 발명의 다양한 실시예를 전술하였지만, 그들은 제한이 아닌 예로써 제공하였다는 것을 알아야 한다. 당업자는 본 발명의 사상 및 범주를 벗어나지 않고서도 형태 및 상세사항에서 다양한 변경을 할 수 있다는 것을 명백히 알 것이다. 따라서 본 발명의 폭과 범주는 전술한 대표적 실시예의 임의의 예에 의해 제한되어서는 안되며 다음의 청구범위 및 그들의 등가물에 따라서만 정의되어야 한다.

Claims

처리 시스템을 관리하는 방법으로서,
상기 처리 시스템의 복수의 자원과 연관된 기준 이용 레벨(reference utilization level)을 나타내는 이용 표시기(utilization indicator)를 수신하는 단계와,
상기 처리 시스템의 각각의 자원의 부하 레벨(load level)이 상기 기준 이용 레벨과 동일하게 되도록 상기 처리 시스템의 상기 자원을 관리하는 단계와,
상기 기준 이용 레벨 및 상기 자원 상에서 실행되는 복수의 애플리케이션 모듈과 연관된 우선순위 레벨에 기초하여 상기 복수의 애플리케이션 모듈 간에 각각의 상기 자원의 처리 용량(processing capacity)을 할당하는 단계 - 각각의 상기 자원은 상기 자원에서 실행되는 상기 애플리케이션 모듈과 연관된 상기 우선순위 레벨에 기초하여, 상기 자원에서 실행되는 상기 복수의 애플리케이션 모듈 각각의 동작의 우선순위를 상기 자원에서 실행되는 상기 복수의 애플리케이션 모듈 중 다른 애플리케이션 모듈에 대해 정함 -
를 포함하되,
각각의 상기 자원은
상기 자원의 상기 처리 용량을 더 많이 요구하는 요청을 제 2 애플리케이션 모듈로부터 수신하는 것에 응답하여, 상기 자원의 처리 용량 모두를 제 1 우선순위를 가진 제 1 애플리케이션 모듈로부터 상기 제 1 우선순위보다 높은 제 2 우선순위를 가진 상기 제 2 애플리케이션 모듈로 전달하여 상기 제 1 애플리케이션이 오프라인이 되게 하고,
상기 자원의 처리 용량에 대한 요청이 상기 제 2 애플리케이션 모듈로부터 수신되는 레이트가 감소하고 있는지 여부를 판정하고,
상기 자원의 처리 용량에 대한 상기 요청이 상기 제 2 애플리케이션 모듈로부터 수신되는 레이트가 감소하고 있다는 판정에 응답하여 상기 제 1 애플리케이션 모듈에게 실행을 재개하라고 명령하는 지시(instruction)를 상기 제 1 애플리케이션 모듈로 제공
하도록 구성되는
처리 시스템 관리 방법.
제 1 항에 있어서,
상기 이용 표시기를 수신하는 단계는, 상기 처리 시스템의 복수의 프로세서와 연관된 상기 기준 이용 레벨을 나타내는 상기 이용 표시기를 수신하는 단계를 포함하고,
상기 자원을 관리하는 단계는, 상기 프로세서 각각의 부하 레벨을 상기 기준 이용 레벨과 동일하게 유지하도록 상기 처리 시스템의 자원을 관리하는 단계를 포함하는
처리 시스템 관리 방법.
제 1 항에 있어서,
상기 이용 표시기를 수신하는 단계는, 상기 처리 시스템의 복수의 서버와 연관된 상기 기준 이용 레벨을 나타내는 상기 이용 표시기를 수신하는 단계를 포함하고,
상기 자원을 관리하는 단계는 상기 서버 각각의 부하 레벨을 상기 기준 이용 레벨과 동일하게 유지하도록 상기 처리 시스템의 자원을 관리하는 단계를 포함하는
처리 시스템 관리 방법.
제 1 항에 있어서,
상기 각각의 자원의 처리 용량은, 상기 기준 이용 레벨 및 복수의 가상 머신과 연관된 우선순위 레벨에 기초하여 상기 자원 상에서 실행되는 상기 복수의 가상 머신 간에 할당되는
처리 시스템 관리 방법.
제 1 항에 있어서,
상기 각각의 자원의 처리 용량은, 상기 기준 이용 레벨 및 복수의 SQL 서버 인스턴스와 연관된 우선순위 레벨에 기초하여 상기 자원 상에서 실행되는 상기 복수의 SQL 서버 인스턴스 간에 할당되는
처리 시스템 관리 방법.
제 1 항에 있어서,
상기 복수의 우선순위 레벨의 선택을 가능하게 하는 사용자 인터페이스 요소를 제공하는 단계
를 더 포함하는 처리 시스템 관리 방법.
제 1 항에 있어서,
상기 기준 이용 레벨의 선택을 가능하게 하는 사용자 인터페이스 요소를 제공하는 단계
를 더 포함하는 처리 시스템 관리 방법.
제 1 항에 있어서,
상기 자원을 관리하는 단계는, 상기 각각의 자원의 평균 부하 레벨이 상기 기준 이용 레벨과 동일하게 유지되도록 상기 처리 시스템의 상기 자원을 관리하는 단계를 포함하는
처리 시스템 관리 방법.
자원을 관리하는 방법으로서,
기준 이용 레벨(reference utilization level)을 수신하는 단계와,
처리 시스템의 자원 상에서 복수의 애플리케이션 모듈(application modules)을 실행하는 단계와,
상기 복수의 애플리케이션 모듈과 연관된 복수의 우선순위 레벨에 기초하여, 상기 자원의 부하 레벨이 상기 기준 이용 레벨과 동일하게 되도록 상기 복수의 애플리케이션 모듈 간에 상기 자원의 처리 용량(processing capacity)을 할당하는 단계 - 상기 자원은 상기 복수의 우선순위 레벨에 기초하여, 상기 복수의 애플리케이션 모듈 각각의 동작의 우선순위를 상기 복수의 애플리케이션 모듈 중 다른 애플리케이션 모듈에 대해 정함 - 와,
상기 자원의 상기 처리 용량을 더 많이 요구하는 요청을 상기 복수의 애플리케이션 모듈 중 제 1 애플리케이션 모듈로부터 수신하는 단계와,
상기 제 1 애플리케이션 모듈과 연관된 제 1 우선순위 레벨에 기초하여 상기 자원의 상기 처리 용량의 일부를 상기 복수의 애플리케이션 모듈 중 제 2 애플리케이션 모듈로부터 상기 제 1 애플리케이션 모듈로 전달하는 단계 - 상기 제 1 애플리케이션 모듈과 연관된 상기 제 1 우선순위 레벨은 상기 제 2 애플리케이션 모듈과 연관된 제 2 우선순위 레벨보다 높음 -
를 포함하되,
상기 전달하는 단계는
상기 자원의 처리 용량 모두를 상기 복수의 애플리케이션 모듈의 상기 제 2 애플리케이션 모듈로부터 상기 제 1 애플리케이션 모듈로 전달하여 상기 제 2 애플리케이션 모듈이 오프라인이 되게 하는 단계와,
상기 자원의 처리 용량에 대한 요청이 상기 제 1 애플리케이션 모듈로부터 수신되는 레이트가 감소하고 있는지 여부를 판정하고,
상기 자원의 처리 용량에 대한 상기 요청이 상기 제 1 애플리케이션 모듈로부터 수신되는 레이트가 감소하고 있다는 판정에 응답하여 상기 제 2 애플리케이션 모듈에게 실행을 재개하라고 명령하는 지시를 상기 제 2 애플리케이션 모듈로 제공하는 단계
를 포함하는
자원 관리 방법.
제 9 항에 있어서,
상기 수신하는 단계는, 상기 자원을 포함하는 복수의 자원과 연관된 상기 기준 이용 레벨을 수신하는 단계를 포함하는
자원 관리 방법.
제 9 항에 있어서,
상기 처리 용량을 할당하는 단계는, 상기 복수의 애플리케이션 모듈 중 제 1 애플리케이션 모듈과 연관된 제 1 우선순위 레벨에 기초하여 상기 자원의 상기 처리 용량을 상기 제 1 애플리케이션 모듈에 할당하지 않는 단계를 포함하는
자원 관리 방법.
제 9 항에 있어서,
상기 처리 용량을 할당하는 단계는, 상기 복수의 애플리케이션 모듈 중 제 1 애플리케이션 모듈과 연관된 제 1 우선순위 레벨에 기초하여 상기 자원의 처리 용량 모두를 상기 제 1 애플리케이션 모듈에 할당하는 단계를 포함하는
자원 관리 방법.
제 9 항에 있어서,
상기 복수의 애플리케이션 모듈 중의 적어도 하나의 애플리케이션 모듈과 연관된 개정된(revised) 우선순위 레벨을 수신하는 단계와,
상기 개정된 우선순위 레벨에 기초하여, 상기 자원의 부하 레벨이 상기 기준 이용 레벨과 동일하게 되도록 상기 복수의 애플리케이션 모듈 간에 상기 자원의 처리 용량을 재할당하는 단계
를 더 포함하는 자원 관리 방법.
제 9 항에 있어서,
개정된 기준 이용 레벨을 수신하는 단계와,
상기 복수의 애플리케이션 모듈과 연관된 상기 복수의 우선순위 레벨에 기초하여, 상기 자원의 부하 레벨이 상기 개정된 기준 이용 레벨과 동일하게 되도록 상기 복수의 애플리케이션 모듈 간에 상기 자원의 처리 용량을 재할당하는 단계
를 더 포함하는 자원 관리 방법.
제 14 항에 있어서,
상기 개정된 기준 이용 레벨을 수신하는 단계는, 사전결정된 스케줄에 따라서 수행되는
자원 관리 방법.
제 9 항에 있어서,
상기 처리 용량을 할당하는 단계는, 상기 복수의 애플리케이션 모듈과 연관된 상기 복수의 우선순위 레벨에 기초하여, 상기 자원의 평균 부하 레벨이 상기 기준 이용 레벨과 동일하게 되도록 상기 복수의 애플리케이션 모듈 간에 상기 자원의 처리 용량을 할당하는 단계를 포함하는
자원 관리 방법.
프로세서 기반 시스템이 자원을 관리하는 것을 가능하게 하는 컴퓨터 프로그램 로직이 저장된 컴퓨터 판독가능 매체로서,
상기 프로세서 기반 시스템이 상기 자원 상에서 복수의 애플리케이션 모듈을 실행할 수 있게 하는 제 1 프로그램 로직 모듈과,
상기 프로세서 기반 시스템이 상기 복수의 애플리케이션 모듈과 연관된 복수의 우선순위 레벨에 기초하여, 상기 자원의 부하 레벨이 기준 이용 레벨과 동일하게 되도록 상기 복수의 애플리케이션 모듈 간에 상기 자원의 처리 용량을 할당할 수 있게 하는 제 2 프로그램 로직 모듈과,
상기 프로세서 기반 시스템이 상기 복수의 우선순위 레벨에 기초하여 상기 복수의 애플리케이션 모듈 각각의 동작의 우선순위를 상기 복수의 애플리케이션 모듈 중 다른 애플리케이션 모듈에 대해 정할 수 있게 하는 제 3 프로그램 로직 모듈과,
상기 프로세서 기반 시스템이 상기 복수의 애플리케이션 모듈 중 제 1 애플리케이션 모듈과 연관된 제 1 우선순위 레벨보다 높은 제 2 애플리케이션과 연관된 제 2 우선순위 레벨에 기초하여, 상기 자원의 처리 용량을 더 많이 요구하는 요청을 상기 제 2 애플리케이션 모듈로부터 수신하는 것에 응답하여 상기 자원의 상기 처리 용량의 일부를 상기 제 1 애플리케이션 모듈로부터 상기 제 2 애플리케이션 모듈로 전달할 수 있게 하는 제 4 프로그램 로직 모듈
을 포함하되,
상기 제 4 프로그램 로직 모듈은,
상기 프로세서 기반 시스템이 상기 자원의 처리 용량을 더 많이 요구하는 요청을 상기 제 2 애플리케이션 모듈로부터 수신하는 것에 응답하여, 상기 자원의 처리 용량 모두를 상기 제 1 애플리케이션 모듈로부터 상기 제 2 애플리케이션 모듈로 전달하여 상기 제 1 애플리케이션이 오프라인이 될 수 있게 하는 로직과,
상기 프로세서 기반 시스템이 상기 자원의 처리 용량에 대한 요청이 상기 제 2 애플리케이션 모듈로부터 수신되는 레이트가 감소하고 있는지 여부를 판정할 수 있게 하는 로직과,
상기 프로세서 기반 시스템이 상기 자원의 처리 용량에 대한 상기 요청이 상기 제 2 애플리케이션 모듈로부터 수신되는 레이트가 감소하고 있다는 판정에 응답하여 상기 제 1 애플리케이션 모듈에게 실행을 재개하라고 명령하는 지시(instruction)를 상기 제 1 애플리케이션 모듈에게 제공할 수 있게 하는 로직
을 포함하는
컴퓨터 판독가능 매체.
제 17 항에 있어서,
상기 프로세서 기반 시스템이 상기 복수의 애플리케이션 모듈과 연관된 복수의 우선순위 레벨에 기초하여, 상기 자원의 부하 레벨이 개정된 기준 이용 레벨과 동일하게 되도록 상기 복수의 애플리케이션 모듈 간에 상기 자원의 처리 용량을 재할당할 수 있게 하는 제 5 프로그램 로직 모듈
을 더 포함하는 컴퓨터 판독가능 매체.
제 17 항에 있어서,
상기 프로세서 기반 시스템이, 상기 복수의 우선순위 레벨의 선택을 가능하게 하는 사용자 인터페이스 요소를 제공할 수 있게 하는 제 5 프로그램 로직 모듈
을 더 포함하는 컴퓨터 판독가능 매체.
제 17 항에 있어서,
상기 프로세서 기반 시스템이, 상기 기준 이용 레벨의 선택을 가능하게 하는 사용자 인터페이스 요소를 제공할 수 있게 하는 제 5 프로그램 로직 모듈
을 더 포함하는 컴퓨터 판독가능 매체.