KR100992209B1

KR100992209B1 - 데이터 처리 시스템 상에서 소프트웨어 제품의 사용량을 측정하는 방법

Info

Publication number: KR100992209B1
Application number: KR1020087014076A
Authority: KR
Inventors: 스코트 맥클렐란; 안토니오 페론; 로베르토 뮬라티
Original assignee: 인터내셔널 비지네스 머신즈 코포레이션
Priority date: 2005-12-16
Filing date: 2006-10-25
Publication date: 2010-11-04
Also published as: EP1960886A1; CN101331460B; US20100218170A1; JP2009519520A; CN101331460A; US8799870B2; JP5284791B2; WO2007068524A1; KR20080075870A

Abstract

데이터 처리 시스템 상에서 소프트웨어 제품의 사용량을 측정하는 해결책(300)이 제안된다. 이러한 문맥에서, (예를 들어, 상이한 요금 청구 단가에 근거하여 라이센싱 어카운팅(acounting)을 가능하게 하도록) 범용 소프트웨어 제품이 실행한 각각의 컴퓨터의 처리 능력을 아는 것이 필수적이다. 제안된 해결책에서, 처리 능력은 직접 컴퓨터 상에서 동적으로 추정된다. 이를 위해, 저 레벨 언어로 기입된 (단일 스레디드(single-threaded)) 벤치마크 프로그램이 가령 개시 시에 또는 주기적으로 실행된다(308-322). 이러한 방식으로, 벤치마크 프로그램의 측정된 실행 시간을 그 알려진 인스트럭션의 수로 나눔으로써(324), 컴퓨터의 단일 마이크로프로세서의 실행 레이트를 결정하는 것이 가능하다. 이 실행 레이트와 이용 가능한 마이크로프로세서의 검출된(306-322) 수를 승산한(326) 값은 컴퓨터의 처리 능력의 정확한 추정치를 제공한다. 컴퓨터의 물리적 세부 사상에 대한 임의의 지식을 필요로 하지 않고 원하는 결과가 성취되며, 이는 컴퓨터가 물리적 호스트 머신 상에서 구현된 논리적 게스트 머신으로 구성되는 경우에 특히 유용하다.

Description

데이터 처리 시스템 상에서 소프트웨어 제품의 사용량을 측정하는 방법{METHOD, SYSTEM AND COMPUTER PROGRAM FOR METERING USAGE OF SOFTWARE PRODUCTS BASED ON REAL-TIME BENCHMARKING OF PROCESSING POWER}

본 발명은 정보 기술 분야에 관한 것으로, 보다 구체적으로, 데이터 처리 시스템 상에서 소프트웨어 제품의 사용량을 측정(metering)하는 것에 관한 것이다.

데이터 처리 시스템에서 소프트웨어 제품의 사용량을 측정하는 것은 몇몇 관리 애플리케이션에서 매우 중요하다. 전형적인 예는 라이센스 관리 인프라스트럭쳐(license management infrastructure)로 구성되며, 이는 시스템 상에서 알려진 소프트웨어 제품의 실행(running)을 제어하는데 사용되며, 시장에서 입수 가능한 상업적인 라이센스 관리 인프라스트럭쳐의 예는 IBM사에 의한 "ITLM(IBM Tivoli License Manager)" 애플리케이션에 근거한다.

소프트웨어 제품의 사용량에 관해 이와 같이 획득된 정보는 일반적으로 (대응하는 사용 조건에 따라) 차지 백 어카운팅(charge-back acounting)에 대해 활용된다. 이러한 문맥에서, 라이센스 전략의 최근 경향은 이들이 실행되는 시스템의 하드웨어 구성에 따라 소프트웨어 제품의 요금 청구 단가를 가변시키는, 예를 들어, 이용가능한 (마이크로)프로세서의 수와 함께 요금 청구 단가를 증가시키는 것이다. 그러나, 이러한 모델의 제한은 (로우 엔드(low-end) 및 하이 엔드(high-end) 시스템 상에서 소프트웨어 제품의 사용 간에 차이가 존재하지 않도록) 모든 마이크로프로세서가 가격의 관점으로부터 동등한 것으로 가정한다. 이러한 전략은 하이 엔드 시스템 상에서 요금 청구 미달을 초래하거나, 혹은 그 반대를 초래하며, 이는 (요금 청구 초과가 있을 것으로 인식되는) 로우 엔드 시스템 상에서 동일한 소프트웨어 제품의 사용을 금지한다.

상술한 문제점을 해결하기 위해, 그 처리 능력에 따라 마이크로프로세서를 분류하는 것이 제안되어 왔으며, 이러한 방식으로, (대응하는 요금 청구 단가를 적용하도록, 전형적으로는 처리 능력과 함께 증가하도록) 상이한 시스템 상에서 소프트웨어 제품의 사용을 구분하는 것이 가능하다.

그러나, 상술한 메커니즘의 구현은 명백히 간단한 것이 아니다. 그 대신에, (정확한 요금 청구 단가를 연관시키는 것을 가능하게 하도록) 우선 마이크로프로세서를 가중화하는 표준적인 벤치마크를 확립하는 것이 필요하다. 또한, (자신의 가중치를 갖는) 모든 현재의 마이크로프로세서 유형의 카탈로그는 라이센스 애플리케이션에 대해 이용 가능해야 하며, 이는 카탈로그를 최신으로 일정하게 유지하는 부담을 또한 부과한다.

임의의 경우에, 시스템이 실제의 컴퓨터로 구성되지 않을 때마다 기술적인 문제점에 봉착하게 된다. 예를 들어, 시스템은 (물리적) 호스트 머신의 논리적 구획에 의해 구현될 수 있으며, 이들 해결책은 (상이한 실제의 컴퓨터의 확산을 필요로 하지 않고) 유지하기에 매우 용이한 다수의 (논리적) 게스트 머신의 시뮬레이팅을 가능하게 하므로, 점점 더 대중화되어 가고 있다. 그러나, 이러한 조건에서 시스템은 통상 라이센스 애플리케이션에 의해 요구되는 구성 정보(예를 들어, 마이크로프로세서의 개수 및 유형)를 집합화할 수는 없다. 실제로, 이러한 정보는 정교한 설계 선택 또는 환경의 본질적인 제한으로 인해, 게스트 머신에 은닉될 수 있다.

발명의 개요

본 발명은 독립 청구항에 기재된 바와 같은 해결책을 제공한다. 본 발명의 유용한 실시예는 종속항에 기술되어 있다.

원리적으로, 본 발명은 시스템의 처리 능력을 동적으로 측정하는 개념에 근거한다.

특히, 본 발명의 측면은 데이터 처리 시스템 상에서 소프트웨어 제품의 사용량을 측정하는 방법을 제안한다. 본 방법은 시스템 상에서 사전 정의된 소프트웨어 제품 세트의 각각의 제품의 실행(running)을 표시하는 (자신의 실행 주기와 같은) 실행 인덱스를 측정하는 단계에 의해 개시된다. 그 다음에 각각의 소프트웨어 제품의 사용량은 대응하는 실행 인덱스 및 시스템의 처리 능력에 따라 결정된다. 이를 위해, 시스템 상에서 벤치마크 프로그램이 실행되며, 벤치마크 프로그램은 사전 결정된 수의 인스트럭션을 수행한다. 본 방법은 벤치마크 프로그램의 실행 시간의 표시를 결정함으로써 계속된다. 처리 능력은 실행 시간 및 인스트럭션의 수에 따라 계산될 수 있다.

본 발명의 실시예에서, (인터럽트 불가능한) 벤치마크 프로그램의 실행 시간은 그 개시 시간 및 종료 시간을 기록하고, 그 다음에 그 차이를 계산함으로써 결정된다.

다른 실시예에서, (운영 체제로부터와 같은) 대응하는 프로세스에 대해 시스템의 프로세서에 의해 전용된 시간을 검색함으로써 동일한 결과가 성취된다.

전형적으로, 벤치마크 프로그램은 저 레벨 언어(예를 들어, 어셈블러)로 기입된다.

제안된 선택은 시스템이 개시될 때 벤치마크 프로그램의 실행을 개시하는 것이다.

제안된 해결책이 멀티프로세서 시스템 상에서 구현되는 경우, (단일 스레디드(single-threaded)) 벤치마크 프로그램에 의해 결정된 처리 능력은 프로세서의 수만큼 승산된다.

이러한 문맥으로, 해결책을 더 향상시키는 방식은 프로세서의 수의 변화가 검출될 때에만 처리 능력을 재계산하는 것이다.

유용하게, 제안된 해결책은 다수의 (논리적) 게스트 머신을 구현하는 (물리적) 호스트 머신 상에서 적용된다(여기서 모든 연산은 단일 게스트 머신 상에서 수행됨).

본 발명의 다른 측면은 본 방법을 수행하는 컴퓨터 프로그램을 제안한다.

본 발명의 또 다른 측면은 대응하는 시스템을 제안한다.

도면의 간단한 설명

본 발명은 다른 특징 및 장점과 함께, 제한하지 않은 표시로서 순수하게 제시되며, 첨부 도면과 함께 읽혀지는 후술하는 상세한 설명을 참조하여 가장 잘 이해될 것이다.

도 1a는 본 발명의 실시예에 따른 해결책이 적용 가능한 데이터 처리 시스템의 개략적인 블록도이고,

도 1b는 시스템의 예시적인 컴퓨터의 기능적인 블록도이며,

도 2는 본 발명의 실시예에 따른 해결책을 실시하는데 사용될 수 있는 주요 소프트웨어 구성요소를 도시하는 도면이고,

도 3a 내지 도 3b는 본 발명의 실시예에 따른 해결책의 구현에 관한 작동의 흐름을 도시하는 도면이다.

특히 도 1a를 참조하면, 분배된 아키텍처를 갖는 데이터 처리 시스템(100)이 도시되어 있다. 시스템(100)은 (애플리케이션 프로그램과 같은) 선택된 소프트웨어 제품의 사용량을 측정하는 것을 가능하게 하는 라이센스 관리 인프라스트럭쳐를 (예를 들어, 상술한 ITLM에 근거하여) 구현한다. 시스템(100)은 서로 간에 완전히 분리되고 구별되어 있는 하나 이상의 독립적인 조직(도면에는 돤지 하나로 도시됨)을 포함하며, 그 조직 내에서, 하나 이상의 분할이 정의된다.

각각의 분할은 대응하는 실행 서버(또는 노드)(110) 세트 상에서 할당된 소프트웨어 제품의 사용량을 직접 제어하는 런타임 서버(105)에 의해 형성된다. 실행 서버(110)는 물리적 호스트 머신(115) 상에서 구현되는 논리적 게스트 머신으로 구성될 수 있으며, (IBM사에 의한 "zSeries", "AS/400" 또는 "Power5" 유형과 같은) 각각의 호스트 머신(115)은 (예를 들어, 대응하는 논리적 구획에 의해) 하나 이상의 실행 서버(110)를 지원한다. 런타임 서버(105) 및 분할의 모든 실행 서버(110)는 네트워크(120)(예를 들어, LAN)를 통해 통신한다.

상이한 런타임 서버(105)는 전체 조직의 재고 목록, 조달 및 어카운팅 정보에 대한 중앙 제어 포인트를 구현하는 단일의 관리 서버(125)에 대해 보고하며, 런타임 서버(105) 및 관리 서버(125)는 상이한 네트워크(130)(예를 들어, 가상 사설망(virtual private network : VPN) 또는 인터넷 기반의 VPN)에 접속되어 있다.

이제 도 1b를 참조하면, 상술한 시스템의 범용 컴퓨터(런타임 서버, 실행 서버를 위한 호스트 머신, 또는 관리 서버)는 (150)으로 도시되어 있다. 컴퓨터(150)는 (시스템 내의 컴퓨터(150)의 실제 기능에 따라 적절하게 스케일링되는 구조를 갖는) 시스템 버스(153)에 병렬로 접속되는 몇몇 유닛에 의해 형성된다. 상세하게는, 하나 이상의 (마이크로) 프로세서(μP)(156)는 컴퓨터(150)의 연산을 제어하고, RAM(159)은 마이크로프로세서(156)에 의해 작업 메모리로서 직접 사용되며, ROM(162)은 컴퓨터(150)의 부트스트랩을 위한 기본 코드를 저장한다. 몇몇 주변 유닛은 (제각기 인터페이스에 의해) 로컬 버스(165) 근처에 클러스터링된다(clustered). 특히, 대형 저장 장치는 하나 이상의 하드 디스크(168) 및 CD-ROM(174)을 판독하는 드라이브(171)로 구성된다. 또한, 컴퓨터(150)는 입력 유닛(177)(예를 들어, 키보드 및 마우스) 및 출력 유닛(180)(예를 들어, 모니터 및 프린터)을 포함한다. 어댑터(183)는 컴퓨터(150)를 시스템에 플러깅하는데 사용된다. 브리지 유닛(186)은 시스템 버스(153)를 로컬 버스(165)와 인터페이스한다. 각각의 마이크로프로세서(156) 및 브리지 유닛(186)은 정보를 전송하는 시스템 버스(153)에 대한 액세스를 요구하는 마스터 에이전트로서 동작할 수 있다. 중재기(189)는 상호 배제에 의한 액세스의 승인을 시스템 버스(153)에 허여한다.

도 2로 이동하면, 상술한 시스템 상에서 실행되는 주요 소프트웨어 구성요소는 참조부호(200)로서 전체적으로 도시되어 있다. 정보(프로그램 및 데이터)는 프로그램이 실행되는 경우 하드 디스크 상에 전형적으로 저장되며 각각의 컴퓨터의 작동 메모리로 (적어도 부분적으로) 로드된다. 프로그램은 초기에, 예를 들어, CD-ROM으로부터 하드 디스크 상에 인스톨된다.

특히 범용 호스트 머신(115)을 고려하면, 관리자(205)는 그 하드웨어 구성을 제어하며, 이를 위해, 하드웨어 관리자(205)는 그 추가, 제거, 셋업 등을 핸들링하도록 이용 가능한 (마이크로프로세서, 작업, 메모리, 대량 저장 장치, 주변 유닛과 같은) 하드웨어 리소스를 정의하는데 사용되는 사용자 인터페이스를 제공한다. 일반적으로, 호스트 머신(115)의 하드웨어 구성의 임의의 변경은 그 재개(콜드 체인지(cold changes))를 필요로 한다. 그러나, 호스트 머신(115)은 웜 체인지(warm changes)를 또한 지원할 수 있으며, 여기서 하드웨어 구성은 그 연산을 중지하지 않고 업데이트된다. 예를 들어, 이것은 호스트 머신(115)이 주문형 용량(Capacity on Demand : CoD) 옵션으로 판매되어 왔다. 이 경우, 호스트 머신(115)은 그 표준 사용량에 대해 요구되는 것보다 많은 하드웨어 리소스(및 특히 마이크로프로세서)를 포함하며, 마이크로프로세서의 서브세트는 영구적으로 이용 가능한 반면, 나머지 잉여 마이크로프로세서는 (작업 부하 피크에 응답하는 몇 시간 동안과 같은) 실제로 필요로 할 때에만 주문형으로 인에이블된다. CoD 옵션을 지원하는 상업적인 제품은 IBM사에 의한 "zSeries", "AS/400" 및 "Power5" 컴퓨터이다.

가상화 층(210)은 호스트 머신(115) 상에서 실행되는 상이한 실행 서버(110)를 구현하는 다수의 게스트 머신을 시뮬레이팅한다. 특히, 가상화 층(210)은 호스트 머신(115)을 다수의 논리적 구획(LPAR)으로 분할한다. 각각의 논리적 구획은 개별적인 컴퓨터로서 독립적으로 동작하는 호스트 머신(115)의 하드웨어 리소스의 서브세트로 구성된다. 전형적으로, 호스트 머신(115)이 CoD 옵션을 구현하는 경우, 하드웨어 관리자(205)는 각각의 논리적 구획에 대해, 사전 정의된 최대 개수 한도까지, 마이크로프로세서를 동적으로 할당하며, 예를 들어, 호스트 머신(115)이 8개의 마이크로프로세서 및 4개의 논리적 구획을 포함하며, 각각의 논리적 구획에 대해 최대 2개의 마이크로프로세서를 할당하는 것이 가능하다(물론, 총 8개의 개수 가 도달될 때까지임). 논리적 구획을 지원하는 상업적인 제품의 예는 IBM사에 의한 "zSeries" 및 "AS/400" 컴퓨터이다.

호스트 머신(115) 상에서 정의된 범용 실행 서버(110)를 참조하면, (IBM사에 의한 "zOS" 또는 "리눅스(Linux)"와 같은) 게스트 운영 체제(215)는 실행될 수 있는 임의의 다른 프로그램 상에서, 그 소프트웨어 플랫폼을 정의한다. 앞서 지적한 바와 같이, 운영 체제(215)는 (가상화 층(210)에 의해 시뮬레이팅되는 바와 같이) 마치 실제의 컴퓨터 상에 인스톨되는 것과 같이 작동한다.

실행 서버(110) 상에서 하나 이상의 소프트웨어 제품(220)이 인스톨된다. 라이센스 에이전트(225)는 실행 서버(110) 상에서 실행되는 소프트웨어 제품(320)을 검출한다. 이를 위해, 라이센스 에이전트(225)는 런타임 서버(105)로부터 (예를 들어, 주기적으로 또는 임의의 변경으로) 다운로드되는 소프트웨어 카탈로그(230c)의 국소적 복사본을 액세스한다. 소프트웨어 카탈로그(230c)는 조직 내에서 측정되는 알려진 소프트웨어 제품을 지정한다. 각각의 소프트웨어 제품은 실행될 때 소프트웨어 제품의 사용량을 표시하는 하나 이상의 실행 가능한 모듈에 의해 정의된 서명(signature)에 의해 식별되며, 전형적으로, 각각의 실행 가능한 모듈은 (그 명칭, 크기 및 체크섬과 같은) 다수의 속성에 의해 소프트웨어 카탈로그(230c) 내에 지정된다.

라이센스 에이전트(225)는 실행 서버(210) 상에서 현재 실행되는 소프트웨어 제품(220)의 리스트(인식된 임의의 알려지지 않은 소프트웨어 제품에 관한 이용 가능한 정보를 포함함)를 소프트웨어 모니터(235)에 공급한다. 소프트웨어 모니터(235)는 실행 서버(115) 상에서 사용하기 위한 소프트웨어 제품(220)의 스냅샷(snapshot)을 제공하는 런타임 테이블(240)을 액세스한다. 이러한 방식으로, 소프트웨어 모니터(235)는 (연산의 최종 반복 이후에) 개시되거나 중지되는 소프트웨어 제품(220)을 결정할 수 있다. (대응하는 타임 스탬프와 함께) 이와 같이 획득된 정보는 소프트웨어 로그(245)에 추가되며, 따라서, 동일한 시점에서, 루틴 테이블(240)이 업데이트된다.

본 발명의 실시예에 따른 해결책에서, 벤치마크 프로그램(250)은 실행 서버(110)의 처리 능력을 동적으로 측정한다. 이하에서 상세하게 기술되는 바와 같이, 이를 위해, 벤치마크 프로그램(250)이 실행되고 그 실행 시간이 측정된다. 벤치마크 프로그램(250)은 사전 결정된 수의 인스트럭션을 수행하며, 예를 들어, 이러한 결과는 (루프와 같은) 고정된 회수 동안 기본 인스트럭션(예를 들어, 산술 연산)을 반복함으로써 달성된다. 따라서, 벤치마크 프로그램(250)의 측정된 실행 시간을 알려진 인스트럭션의 수로 나누어 계산되는 그 연산 레이트에 따라 실행 서버(100)의 처리 능력을 추정하는 것이 가능하다.

제안된 해결책은 실행 서버(110)의 처리 능력의 결정을 매우 용이하게 한다. 특히, 임의의 카탈로그를 유지할 필요 없이 실시간으로 원하는 결과가 성취되지만, 요구된 정보는 실행 서버(110)의 처리 능력의 정확한 픽쳐(picture)를 항상 제공하도록 동적으로 집합화된다.

임의의 경우에, 고안된 해결책은 그 물리적 세부 사항으로부터 실행 서버(110)의 처리 능력의 측정을 용이하게 한다. 보다 구체적으로, 이러한 기법은 실행 서버(110)의 실제의 구조에 대한 임의의 지식을 필요로 하지 않는다. 따라서, 실행 서버(110)의 하드웨어 구성에 관한 정보(그 마이크로프로세서의 유형과 같은)를 검색할 필요가 없다. 이러한 장점은 실행 서버(110)가 실제의 컴퓨터로 구성되지 않을 때 더욱 명백하며, 그 경우에 그 하드웨어 구성에 관한 정보를 집합화하는 것이 (불가능한 것은 아니더라도) 매우 어려울 수 있다. 따라서, 제안된 해결책은 실행 서버(110)의 구현과는 독립적으로 일반적인 적용이 가능하다.

바람직하게, 벤치마크 프로그램(250)은 (어셈블러 또는 기계어와 같은) 저 레벨 언어로 기입된다. 저 레벨 언어는 컴퓨터의 마이크로프로세서에 의해 실행될 수 있는 연산에 대응하는 기본 인스트럭션 세트만을 지원한다. 기계어에 있어서, 인스트럭션은 마이크로프로세서의 연산을 직접 제어하는데 사용될 수 있는 비트의 패턴(머신 코드)으로 구성된다. 한편, 어셈블러 언어에 있어서 동일한 인스트럭션은 (어셈블러에 의해 대응하는 머신 코드로 변환되는) 판독 및 기입이 보다 용이한 니모닉 심볼로 나타내어진다. 저 레벨 언어는 인간 포맷의 보다 풍부한 인스트럭션 세트를 지원하는 고 레벨 언어와 상이하다. 그 실행을 위해, 이들 인스트럭션은 (예를 들어, 컴파일러에 의해 정적으로, 또는 인터프리터에 의해 동적으로) 대응하는 머신 코드의 스트림으로 변환되어야 하며, 컴퍼일러 또는 인터프리터는 실제 컴퓨터에 대해 또는 그 실제 구현을 은닉하는 가상 머신에 대해 (자바 런(Java Run) 시간 환경에 이해 지원된 바이트코드와 같은) 머신 코드를 생성할 수 있다. 벤치마크 프로그램(250)을 저 레벨 언어로 기입하는 선택은 컴퍼일러 또는 인터프리터에 의해 도입될 수 있는 임의의 차이를 방지하므로, 이질적인 실행 서버(110) 상에 획득되는 양호한 결과의 균일성을 보장한다.

또한, 상술한 멀티프로세서 환경에서(여기서 실행 서버(110)는 2개 이상의 마이크로프로세서를 포함할 수 있음), 벤치마크 프로그램(250)은 단일 스레디드이어야 하며, 따라서, 벤치마크 프로그램(250)은 그 연산 레이트의 정확한 추정을 제공하기 위해, 단일 마이크로프로세서 상에서 항상 실행된다. 이러한 경우에, 실행 서버(110)의 총 처리 능력은 이와 같이 획득된 결과를 그의 (동일한) 마이크로프로세서의 수와 승산함으로써 획득된다.

이를 위해, 벤치마크 프로그램(250)은 특정의 API(Application Program Interfaces)를 통해 운영 체제(215)와 인터페이스한다. 벤치마크 프로그램(250)은 (대응하는 타임 스탬프와 함께) 실행 서버(110)의 추정된 처리 능력을 하드웨어 로그(255)에 부가한다.

라이센스 에이전트(235)는 소프트웨어 로그(245) 및 하드웨어 로그(255)를 액세스한다. 라이센스 에이전트(235)는 소프트웨어 로그(245)로부터 상술한 소프트웨어 실행 정보(즉, 임의의 소프트웨어 제품(220)의 개시 시간 및/또는 종료 시간)를 추출하고 하드웨어 로그(255)부터 상술한 하드웨어 성능 정보(즉, 처리 능력)를 추출하며, 이러한 정보는 (실행 서버(110)의 식별자와 함께) 런타임 서버(105)에 전송된다.

이제 런타임 서버(105)를 고려하면, 라이센스 관리자(260)는 실행 서버(110)마다의 소프트웨어 실행 정보 및 하드웨어 용량 정보를 분할하여 수신한다. 라이센스 관리자(260)는 정보의 각종 단편을 (전역적) 분할 로그(265)에 저장하고 관리 서버(도면에 도시되지 않음) 상으로 이를 업로드한다. 또한, 라이센스 관리자(260)는 (예를 들어, 주기적으로 또는 임의의 변경으로) 동일한 행성 서버로부터 소프트웨어 카탈로그((230m)으로 도시된)의 주요 복사본을 또한 다운로드한다.

전형적으로, 관리 서버는 수신된 정보를 사용 리포트(usage report)로 집합화한다. 사용 리포트는 사전 정의된 구간으로 실행 서버(110) 상에서 실행되는 소프트웨어 제품을 리스트하며, 각각의 소프트웨어 제품에 대해, 사용 리포트는 상이한 처리 능력으로 실행 서버(110) 상에서(즉, 시간 경과에 따른 상이한 하드웨어 구성으로 상이한 실행 서버(110) 상에서 및/또는 동일한 실행 서버(110) 상에서) 임의의 실행 주기를 지정하며, 예를 들어, 사용 리포트는 실행 서버(110) 상에서 1개의 로우 엔드 마이크로프로세서로 2 시간 동안, 실행 서버(110) 상에서 1개의 하이 엔드 마이크로프로세서로 1 시간 동안, 동일한 실행 서버(110) 상에서 2개의 하이 엔드 마이크로프로세서로 다른 3 시간 동안, 특정의 소프트웨어 제품이 실행되는 것을 표시할 수 있다. 일반적으로, 사용 리포트는 (알려지지 않은 소프트웨어 제품의 사용량과 같은) 조직의 실행 서버(110) 상에 발생된 임의의 변칙 이벤트를 또한 지정한다.

이러한 정보는 (그 사용 조건에 의해 지정되는 바와 같이, 상이한 처리 능력에 대한 사전 정의된 레이트에 따라) 알려진 소프트웨어 제품의 임의의 사용량에 대한 사전 규정된 라이센스 요금을 청구하는데 사용될 수 있으며, 예를 들어, 상술한 상황에서, 1개의 로우 엔드 마이크로프로세서로 실행 서버(110) 상에서 소프트웨어 제품의 사용의 각 시간 동안 낮은 양이 청구될 것이고, 1개의 하이 엔드 마이크로프로세서로 실행 서버(110) 상에서 소프트웨어 제품의 사용의 각 시간 동안 높은 양이 청구될 것이며, 2개의 하이 엔드 마이크로프로세서로 실행 서버(110) 상에서 소프트웨어 제품의 사용의 각 시간 동안 더욱 높은 양이 청구될 것이다.

이제 도 3a 및 도 3b를 참조하면, (원하는 소프트웨어 제품의 사용량을 측정하기 위해) 상술한 시스템에서 구현될 수 있는 예시적인 프로세스의 논리 흐름은 방법(300)으로 나타내어진다. 방법(300)은 범용 실행 서버의 스윔 레인(swim-lane)의 흑색 개시 원(302)에서 개시된다. 실행 서버가 턴 온되자 마자 프로세스는 블록(304)으로 내려간다(진행한다). 이 단계에서, 라이센스 에이전트는 실행 서버의 처리 능력을 추정하도록 호출된다. 이를 위해, 블록(306)에서 라이센스 에이전트는 (운영 체제의 대응하는 API에 의해) 실행 서버에 대해 이용 가능한 마이크로프로세서의 수를 검출한다.

그 다음에 라이센스 에이전트는 벤치마크 프로그램을 실행하고 그 실행 시간을 결정한다. 이러한 결과는 동기화 바(308)에서 대안적인 브랜치로 포크(fork)하는 작동 흐름에 의해 나타내어지는 2개의 상이한 방식으로 달성될 수 있다. 특히, 구현예는 블록(310-316)에 의해 형성된 브랜치의 실행을 수반하는 반면, 다른 구현예는 블록(318-320)에 의해 형성된 브랜치의 실행을 수반하며, 2개의 브랜치는 다른 동기화 바(322)에서 결합한다.

이제 블록(310)을 고려하면, 시스템 클록이 (운영 체제의 대응하는 API에 의해) 샘플링되어 기록된다. 그 다음에 벤치마크 프로그램은 블록(312)에서 개시된다. 벤치마크 프로그램의 실행이 종료되자마자(블록(314)), 시스템 클록이 재차 샘플링되어 기록된다. 블록(316)으로 통과하면, 벤치마크 프로그램의 실행 시간은 (그 종료 시간을 표시하는) 제 2 시스템 클록으로부터 (그 개시 시간을 표시하는) 제 1 시스템 클록을 감산함으로써 계산된다. 브랜치는 동기화 바(322)에서 종료된 다. 이러한 경우에, 벤치마크 프로그램은 인터럽트 불가능하여야 하며, 즉, (할당된) 마이크로프로세서 상에서 그 실행은 상이한 요구를 제공하도록 보류될 수 없으며, 따라서, 벤치마크 프로그램은 임의의 다른 소프트웨어 프로그램과 경쟁하지 않고 마이크로프로세서의 배타적인 사용을 갖는다. 또한, 벤치마크 프로그램은 상대적으로 많은 수(예를 들어, 적어도 몇 백 및 바람직하게는 몇 천)의 인스트럭션을 실행해야 하며, 따라서, 그 개시 시간 및 종료 시간을 기록하는데 소모된 시간은 (그 결정의 정확도에 악 영향을 미치지 않도록) 벤치마크 프로그램의 실행 시간에 대해 무시할 정도이다. 상술한 구현예는 매우 간단하며 일반적으로 적용 가능하다.

대안적으로, 벤치마크 프로그램은 통상과 같이 블록(318)에서 개시되며, 이러한 경우에, 벤치마크 프로그램은 (실행 서버의 마이크로프로세서의 사용을 위해 벤치마크 프로그램과 경쟁하는) 임의의 다른 소프트웨어 프로그램으로서 실행한다. 방법(300)은 벤치마크 프로그램의 실행이 종료하자 마다 블록(320)으로 계속된다. 이 단계에서, 라이센스 에이전트는 (운영 체제에 이해 기록된) 벤치마크 프로그램을 실행하는데 사용되는 프로세스의 프로세서 시간을 검색하고, 예를 들어, 이러한 결과는 운영 체제의 대응하는 API를 호출함으로써, 또는 ("z/OS" 상에서의 SMP와 같은) 전용 로그를 액세스함으로써 성취된다. 프로세서 시간은 마이크로프로세서가 다른 프로세스를 또한 일반적으로 제공하는 동안 대응하는 경과 시간과 구분되는 바와 같이, 관련 마이크로프로세서에 의해 프로세스에 대해 실질적으로 전용된 시간을 표시한다는 것에 주목해야 한다. 브랜치는 동기화 바(322)에서 마찬가지로 종료된다. 이러한 경우에, 실행 시간의 매우 정확한 계산이 가능하다.

두 가지 경우에서, 프로세스는 이제 블록(324)으로 계속된다. 이 단계에서, 벤치마크 프로그램의 측정된 실행 시간(전형적으로 초로 표현됨)은 그 인스트럭션의 수(프라이어리(a priori)로 알려짐)로 나누어지며, 이것은 실행 서버의 범용 마이크로프로세서의 (추정된) 연산 레이트(초 당 인스트럭션으로 표현됨)를 제공한다. 블록(326)으로 진행하면, 실행 서버의 총 처리 능력은 이와 같이 획득된 연산 레이트를 그 마이크로프로세서의 수로 승산함으로써 계산된다. 라이센스 에이전트는 블록(328)에서 (대응하는 타임 스탬프와 함께) 이러한 정보를 하드웨어 로그에 추가한다.

실행 서버의 개시 시에 벤치마크 프로그램을 실행하는 선택은 실질적인 사업적 작업 부하가 활성화되기 전에 완료되는 것을 보장하며, 이것은 (특히 벤치마크 프로그램이 인터럽트 불가능하며 전체 마이크로프로세서의 배타적인 사용을 취할 때) 실행 서버의 성능에 대한 연산의 영향을 최소화한다.

추가적으로 또는 대안적으로, 사전 정의된 타임아웃이 만료하자마자(예를 들어, 10-60분마다), 프로세스는 블록(330)으로부터 블록(332)로 진행하며, 이 경우에, 라이센스 에이전트는 실행 서버의 마이크로프로세서의 수를 재차 검출한다. 이제 블록(334)에서 (연산의 최종 반복 이후에) 마이크로프로세서의 수가 변경되었는지 여부를 판정하는 테스트가 행해진다. 변경되었으면, 작동의 흐름은 블록(326)으로 계속되어, (새로운 마이크로프로세서의 수 및 그 알려진 연산 레이트에 따라) 실행 서버의 처리 능력을 재계산한다. 이러한 피쳐(feature)는 대응하는 하드웨어 구성이 그 연산을 중지하지 않고 업데이트될 수 있다 하더라도 실행 서버의 처리 능력을 추적하는 것을 가능하게 하나, 임의의 변경의 검출에만 응답하여 연산을 수행하는 선택은 실행 서버의 성능에 대한 영향을 수용 가능한 것으로 유지한다.

임의의 경우에, 일단 연산이 종단되면, 방법(300)은 블록(328)으로부터 블록(336)으로 진행하고, 마이크로프로세서의 수가 변경되지 않을 때 블록(334)으로부터 직접 동일한 포인트가 또한 도달된다. 다른 타임아웃이 만료하자마자(예를 들어, 1-10분마다), 블록(338)에서 라이센스 에이전트는 (운영 체제의 대응하는 API에 의해) 실행 서버 상에서 활성인 프로세스의 리스트를 검색한다. 그 다음에 (제 1 단계로부터 개시하는) 각각의 프로세스에 대해 루프가 수행되고, 루프는 블록(340)에서 개시되며, 여기서 라이센스 에이전트는 (운영 체제로부터 리턴된(returned) 명칭에 의해 식별된) 대응하는 실행 모듈을 액세스하여 그의 다른 속성(즉, 언급한 예에서의 크기 및 체크섬)을 검색한다. 블록(342)으로 계속 진행하면, 라이센스 에이전트는 (필요하다면) 실행 가능함 모듈의 크기 및 체크섬을 그 명칭에 대한 소프트웨어 카탈로그에 지정된 것과 비교한다. 실행 가능함 모듈의 속성이 소프트웨어 카탈로그의 엔트리에 정합하는 경우(결정 블록(344)), 블록(346)에서 대응하는 소프트웨어 제품이 식별된다. 반대로, 소프트웨어 제품은 (실행 가능함 모듈의 명칭과 같은 임의의 이용 가능한 정보를 저장하는) 블록(348)에서 미지의 것으로서 세팅된다. 두 가지 경우에, 블록(350)에서 이와 같이 획득된 정보는 실행 서버 상에서 현재 실행 중인 소프트웨어 제품의 리스트에 추가된다. 블록(352)에서 모든 프로세스가 분석되었는지 여부를 판정하는 테스트가 행해진다. 분석되지 않은 경우, 방법은 블록(340)으로 복귀하여 다음 프로세스를 위한 동일한 연산을 반복한다. 반대로, 루프는 블록(354)으로 내려가서 탈출하며, 이 경우에, 소프트웨어 모니터는 (라이센스 에이전트로부터 수신된) 실행 소프트웨어 제품의 리스트를 런타임 테이블의 콘텐츠와 비교하여, (연산의 최종 반복 이후에) 개시되거나 중지되는 소프트웨어 제품을 검출한다. 블록(356)으로 계속 진행하면, 이와 같이 획득된 정보는 (대응하는 타임 스탬프와 함께) 소프트웨어 로그에 추가되고, 따라서 런타임 테이블이 업데이트된다.

블록(358)에서 다른 타임아웃이 만료하자마자(예를 들어, 6-24시간마다), 프로세스는 블록(360)으로 진입하며, 이 단계에서, 라이센스 관리자는 (소프트웨어 로그로부터) 소프트웨어 실행 정보를 추출하고 (하드웨어 로그로부터) 용량 정보를 추출하며, 그 다음에 이러한 정보는 (실행 서버의 식별자와 함께) 런타임 서버에 전송된다. 이에 응답하여, 블록(362)에서 런타임 서버는 수신된 정보를 분할 로그에 저장한다.

블록(364)에서 상이한 타임아웃의 만료(예를 들어, 매일마다의 종료 시에)에 응답하여, 블록(366)에서 라이센스 관리자는 분할 로그에서 이용 가능한 정보를 관리 서버 상에 업로드한다. 관리 서버의 스윔 레인으로 이동하면, 블록(368)에서 수신된 정보를 집합화함으로써 새로운 사용 리포트가 생성될 수 있다. 블록(370)에서 이와 같이 획득된 사용 리포트가 (예를 들어, 적용 가능한 라이센스 요금을 청구하도록) 분석된다. 그 다음에 방법은 중앙 백색/흑색 중지 원(372)에서 종료된다.

본질적으로, 국소적이고 특정의 요건을 충족하기 위해, 당 분야에서 통상의 지식을 가진 자라면 상술한 해결책에 다수의 수정 및 변형을 적용할 수 있다. 특히, 본 발명은 그 바람직한 실시예(들)를 특히 참조하여 특정의 정도로 기술되었으나, 다른 실시예 뿐만 아니라 형태 및 세부 사항에 있어 각종 생략, 대체 및 변경이 가능하다는 것이 이해될 것이며, 또한, 본 발명의 임의의 개시된 실시예와 결합하여 기술된 특정의 요소 및/또는 방법의 단계는 임의의 다른 실시예에서 일반적인 설계 선택의 문제로서 내포될 수 있음을 명확하게 의도하고 있다.

예를 들어, 시스템이 상이한 아키텍처를 갖거나 균등한 유닛을 포함하더라도 마찬가지의 고려 사항이 적용된다. 또한, 각각의 컴퓨터는 다른 구조를 가질 수 있거나 또는 (실행 동안 메인 메모리에 대한 액세스를 저감하기 위해 프로그램 또는 그 일부분을 임시적으로 저장하는 캐쉬 메모리와 같은) 유사한 요소를 포함할 수 있으며, 임의의 경우에, 컴퓨터를 (PDA, 모바일 폰 등과 같은) 임의의 코드 실행 엔티티로 대체하는 것이 가능하다.

본 발명의 구현예는 실행 서버 상에서 실행되는 소프트웨어 제품을 식별하는 임의의 특정한 라이센스 애플리케이션 및/또는 기법에 제한되지 않는다는 것이 용이하게 명백할 것이며, 예를 들어, 대응하는 프로세스의 개시를 차단함으로써 임의의 새로운 소프트웨어 제품(또는 전자 북과 같은 임의의 균등한 디지털적으로 인코딩된 제품)의 호출을 (예를 들어, 커넬 후킹(kernel hooking) 기법을 이용하여) 검출하는 것이 가능하다. 마찬가지로, (대응하는 실행 주기의 길이 대신에) 소프트웨어 제품의 호출의 수, 또는 그 실행을 표시하는 보다 일반적인 임의의 다른 인덱스를 측정하는 것이 가능하다. 또한, 적용 가능한 사용 조건과의 순응성을 검증하기 위해, 또는 보다 일반적인 관리를 위해 입수 가능한 정보가 간단히 사용될 수 있다.

벤치마크 프로그램의 실행 시간(및 처리 능력)을 결정하는 제안된 알고리즘은 단지 예시적이다. 예를 들어, 어느 것도 벤치마크 프로그램에 의해 직접적으로 모든 연산의 구현을 방지하지 못하며, 대안적으로, 처리 능력을 추정하여 이를 런타임 서버에 독립적으로 전송하는 별도의 에이전트를 갖는 것이 가능하다.

본 발명의 원리로부터 벗어나지 않고, 벤치마크 프로그램은 (상이한 언어로 기입되더라도) 임의의 다른 인스트럭션을 실행할 수 있다.

대안적으로, (예를 들어, 웜 체인지가 가능하지 않을 때) 실행 서버의 개시 시에만 벤치마크 프로그램을 개시하는 것이 가능하고, 그 반대인 경우도 적용 가능하며, 그 하드웨어 구성이 연속적으로 모니터링될 때 실행 서버의 개시 시에 벤치마크 프로그램의 개시가 방지될 수 있다. 임의의 경우에, (예를 들어, 단순히 주기적으로) 벤치마크 프로그램의 실행을 위한 상이한 스케줄링 폴리시(scheduling policies)는 본 발명의 범위 내에 있다.

제안된 해결책이 다수의 논리적 구획으로 분할되는 멀티프로세서 컴퓨터 상에서 사용하기 위해 구체적으로 설계되었으나, 이것은 제한하는 방식으로 해석되어서는 안 된다. 예를 들어, 어느 것도 단일 마이크로프로세서를 갖는 컴퓨터 상에서 동일한 해결책의 적용을 방지하지 못한다. 또한, 본 발명에 따른 해결책은 가 상 머신 상에서, 또는 물리적 호스트 머신 상에서 구현된 임의의 다른 논리적 게스트 머신 상에서 보다 일반적으로 사용되도록 제공한다. 임의의 경우에, 동일한 기법은 임의의 가상화 층 없이 실제의 컴퓨터 상에서 동등한 애플리케이션을 찾아낸다.

(본 발명의 각각의 실시예를 구현하는데 사용될 수 있는) 프로그램이 상이한 방식으로 구조화되거나, 또는 추가적인 모듈 또는 기능이 제공되더라도 마찬가지의 고려 사항이 적용되며, 마찬가지로, 메모리 구조는 다른 유형으로 이루어질 수 있고, 또는 균등한 엔티티로 대체될 수 있다(반드시 물리적 저장 매체로 구성되지 않음). 또한, 제안된 해결책은 (상이한 순서이더라도, 유사하거나 또는 추가적인 단계를 갖는) 동등한 방법으로 구현되도록 제공한다. 임의의 경우에, 프로그램은 외부 또는 상주 소프트웨어, 펌웨어, 또는 마이크로코드(객체 코드 도는 소스 코드의)와 같이, 임의의 데이터 처리 시스템에 의해 또는 데이터 처리 시스템과 결합하여 사용되는데 적합한 임의의 형태를 취할 수 있다. 또한, 프로그램은 임의의 컴퓨터 사용 가능한 매체 상에 제공될 수 있으며, 매체는 프로그램을 포함하고, 저장하며, 통신하고, 전파하거나 또는 전달하는데 적합한 임의의 요소일 수 있다. 이러한 매체의 예는 고정된 디스크(프로그램이 사전 로딩될 수 있음), 제거 가능한 디스크, 테이프, 카드, 와이어, 파이버, 무선 접속, 네트워크, 방송파 등이며, 예를 들어, 매체는 전자적, 자기적, 광학적, 전자기적, 적외선, 또는 반도체 유형으로 이루어질 수 있다.

임의의 경우에, 본 발며에 따른 해결책은 (예를 들어, 반도체 재료의 칩으로 집적된) 하드웨어 구조로, 또는 소프트웨어 및 하드웨어의 결합으로 수행되도록 제공한다.

Claims

데이터 처리 시스템 상에서 소프트웨어 제품의 사용량을 측정하는 방법(300)으로서,

상기 데이터 처리 시스템 상에서 사전 정의된 소프트웨어 제품 세트의 각각의 제품의 실행(running)을 표시하는 실행 인덱스(running index)를 측정하는 단계(336-356)와,

대응하는 실행 인덱스 및 상기 시스템의 처리 능력에 따라 각각의 소프트웨어 제품의 사용량을 결정하는 단계(358-370)와,

사전 결정된 수의 인스트럭션을 수행하는 벤치마크 프로그램(benchmark program)을 상기 시스템 상에서 실행하는 단계(312; 318)와,

상기 시스템 상에서 동시 실행되는 임의의 다른 프로세스와의 간섭을 방지하면서 상기 벤치마크 프로그램의 실행 시간의 표시를 결정하는 단계(310, 314-316; 320)와,

상기 실행 시간 및 상기 인스트럭션의 수에 따라 상기 처리 능력을 계산하는 단계(324)를 포함하는

소프트웨어 제품의 사용량 측정 방법.
제 1 항에 있어서,

상기 벤치마크 프로그램은 인터럽트 불가능하며,

상기 벤치마크 프로그램의 실행 시간의 표시를 결정하는 단계(310, 314-316)는,

상기 벤치마크 프로그램의 개시 시간을 기록하는 단계(310)와,

상기 벤치마크 프로그램의 종료 시간을 기록하는 단계(314)와,

상기 종료 시간 및 상기 개시 시간 간의 차이에 따라 상기 실행 시간을 계산하는 단계(316)를 포함하는

소프트웨어 제품의 사용량 측정 방법.
제 1 항에 있어서,

상기 시스템 상에서 완료된 각각의 프로세스에 대해 상기 시스템의 프로세서에 의해 전용되는 프로세서 시간이 기록되며,

상기 실행 시간의 표시를 결정하는 단계(320)는,

상기 벤치마크 프로그램을 실행하는데 사용된 벤치마크 프로세스의 상기 프로세서 시간에 따라 상기 실행 시간을 설정하는 단계(320)를 포함하는

소프트웨어 제품의 사용량 측정 방법.
제 1 항에 있어서,

상기 벤치마크 프로그램은 저 레벨 언어의 인스트럭션 세트로 구성되는

소프트웨어 제품의 사용량 측정 방법.
제 1 항에 있어서,

상기 시스템의 스타트업(startup)에 응답하여 상기 벤치마크 프로그램의 실행을 개시하는 단계(304)를 포함하는

소프트웨어 제품의 사용량 측정 방법.
제 1 항에 있어서,

상기 시스템은 하나보다 많은 수의 프로세서를 포함하고,

상기 벤치마크 프로그램은 상기 프로세서 중 하나의 프로세서에서 실행되며,

상기 방법은,

상기 프로세서의 수를 결정하는 단계(306, 322)와,

상기 프로세서의 수에 근거하여 다수의 인자에 따라 상기 처리 능력을 업데이트하는 단계(326)를 포함하는

소프트웨어 제품의 사용량 측정 방법.
제 6 항에 있어서,

상기 프로세서의 수의 변화를 검출하는 단계(330-332)와,

상기 변화의 검출에 응답하여 상기 처리 능력의 상기 업데이트를 수행하는 단계(334)를 더 포함하는

소프트웨어 제품의 사용량 측정 방법.
제 1 항에 있어서,

상기 시스템은 다수의 논리적 게스트 머신을 구현하는 물리적 호스트 머신으로 구성되며,

상기 벤치마크 프로그램을 실행하는 단계(312; 318), 상기 실행 시간의 표시를 결정하는 단계(310, 314-316; 320), 및 상기 처리 능력을 계산하는 단계(324)는 상기 다수의 논리적 게스트 머신 중 선택된 하나의 게스트 머신 상에서 수행되는

소프트웨어 제품의 사용량 측정 방법.
제 1 항 내지 제 8 항 중 어느 한 항에 따른 방법(300)의 각 단계를 수행하는 프로그램 인스트럭션을 포함하는 컴퓨터 프로그램(200)을 저장한

컴퓨터 판독 가능한 저장 매체.
제 1 항 내지 제 8 항 중 어느 한 항에 따른 방법(300)의 각각의 단계를 수행하는 각각의 수단을 포함하는 시스템(100).