KR101201008B1 - 컴퓨터 시스템 및 분산 애플리케이션의 모델 기반 관리 - Google Patents

Abstract

모델 기반 애플리케이션 관리 아키텍쳐가 개시되어 있다. 개발자는 애플리케이션 또는 서비스를 그의 구성 컴포넌트에 관하여 기술할 수 있다. 요구되는 상태들이 기능, 구성, 보안 및 성능에 관하여 기술될 수 있다. 이러한 기술은 애플리케이션의 설치에서 관리 서비스를 구성하기 위해 이용되는데, 이 서비스는 구성 관리, 문제 검출, 진단 및 회복과 같은 자동 관리 동작을 통해 애플리케이션의 이용 가능성을 보장하는 것을 돕는다.

모델 기반 관리 시스템, 아키텍쳐, 프레임워크, 요구되는 상태, 애플리케이션

Description

컴퓨터 시스템 및 분산 애플리케이션의 모델 기반 관리{MODEL-BASED MANAGEMENT OF COMPUTER SYSTEMS AND DISTRIBUTED APPLICATIONS}

<관련 출원의 상호 참조>

본 출원은 함께 계류 중이고 본 명세서에 그 전체가 참조된 미국 특허 출원들, 즉 2003년 10월 23일자로 출원된 컴퓨터 시스템 및 분산 애플리케이션의 모델 기반 관리라는 제목의 일련 번호 10/692,216, 2003년 10월 24일자로 출원된 규칙 모니터링의 스케일 가능한 동기 및 비동기 처리라는 제목의 일련 번호 10/693,072, 2003년 10월 24일자로 출원된 규칙 정의 언어라는 제목의 일련 번호 10/692,660, 2003년 10월 24일자로 출원된 URI를 이용한 공통 스키마를 가진 다수의 인스턴스의 식별이라는 제목의 일련 번호 10/693,588, 및 2003년 10월 23일자로 출원된 관리 정보를 기술하기 위한 속성의 이용이라는 제목의 일련 번호 10/692,432(대리인 사건 번호 MSFTP522US)와 관련된다.

<기술 분야>

본 발명은 컴퓨터 시스템에 관한 것으로서, 보다 상세하게는 컴퓨터 시스템 및 애플리케이션의 관리에 관한 것이다.

종래의 시스템 관리는 매우 임시적이다. 애플리케이션 개발자들은 그들의 애플리케이션을 관리하고 높은 신뢰도를 달성하기 위한 구조화된 프레임워크를 갖고 있지 않다. 예측되는 애플리케이션의 거동은 대부분 역설계된다. 애플리케이션 개발자들은 그들의 애플리케이션을 관리하고 높은 신뢰도를 달성하는 것을 어떻게 고려할 것인지에 대한 구조화된 지침 및 프레임워크를 갖고 있지 않다. 더욱이, 운영 체제는 개발자들이 이용할 전체론적 시스템을 제공하지 못한다.

시스템의 복잡성은 너무 커져 오퍼레이터들이 이해할 수 없게 되었다. 종속성 및 잠재적 에러를 추적하는 것은 많은 시간을 소모한다. 계기(instrumentation)가 이용 가능하지 않은 경우, 오퍼레이터는 프로세스 덤프를 행해야 하는데, 그 이유는 이것이 어떤 요구가 실행되고 있는지와 현재 상태를 판정하는 유일한 방법이기 때문이다.

오늘날 시스템들은 사용자에게 잠재적이고 실제적인 문제들을 경고하는 빈약한 일을 한다. 사용자들은 어떤 애플리케이션이 설치되어 있는지를 쉽게 알 수 없으며, 시스템 및 애플리케이션이 올바른 파일 및 버젼을 갖고 있는지, 그들이 이용되는 방식을 위해 올바르게 구성되어 있는지, 환경에 대해 안전하게 구성되어 있는지, 그리고 그들이 최적으로 동작하고 있고 자원을 다 소모하고 있지 않은지를 알지 못한다. 더욱이, 애플리케이션은 다수의 기계들에서 쉽게 디버깅되지 못한다-공통 애플리케이션 및 트랜잭션 컨텍스트가 존재하지 않는다.

또한, 오퍼레이터들은 애플리케이션 종속성을, 파일, 컴포넌트, 구성 설정, 보안 설정인지 또는 기억 영역 네트워크 및 라우터와 같은 장치인지를 쉽게 파악할 수 없다. 시스템은 사용자에게 변화가 다른 애플리케이션을 파괴할 수 있다는 것 을 경고할 수도 없고, 이러한 정보를 이용하여 근본 원인을 찾는 것을 도울 수도 없다.

오늘날에는 경보가 문제의 원인이 아니라 고장이 있었다는 것을 사용자가 알게 하는 반응 모니터링이 매우 일반적이다. 진보된 스크립트 및 제공자는 더 많은 유익하고 효과적인 경보를 제공할 수 있지만, 근본 원인 분석을 수행하기 위한 기반 구조가 결여되어 있다. 고장 수리를 위한 추가적인 진단이 종종 필요하다. 그러나, 반응 모니터링이 갖는 하나의 문제점은 경보가 종종 너무 늦어 애플리케이션이 이미 사용자에게 이용 가능하지 않게 된다는 점이다. 모니터링은 페일오버(failover)를 트리거링하거나 로드 밸런싱 장치로 서버 오프라인을 취함으로써 도울 수 있다. 그러나, 시스템은 잠재적인 문제가 고장으로 되기 전에 애플리케이션에서 잠재적인 문제를 검출할 수 있도록 충분히 지능적이어야 한다.

다른 문제들은 다수의 기계 및 클라이언트 전체를 주시함으로써만 검출된다. 그 예로는 분산 침입 검출 및 애플리케이션 성능의 저하가 포함된다. 관리자들은 그들의 재량으로 예측 성능으로부터의 편이를 알 수 있는 능력을 갖고, 그들이 스냅샷을 캡쳐할 때 구성 변화의 근본 원인을 추적할 수 있으며, 사용자가 불평하기 전에 문제를 해결할 수 있지만, 많은 대용량 네트워크 성능 문제 및 중단 시간(downtime)은 피하지 못했다.

종래에, 분산 애플리케이션이 갖는 문제들은 사용자 시각에서 이력 데이터 또는 경향을 고찰함으로써만 해결된다. 관리자들은 종종 그들의 복제 백로그가 문제인지 아닌지를 알지 못하며, 먼저 서비스를 실행하고, 경고 및 임계치를 갖는 베 이스라인을 설정하기 위한 동작 메트릭을 로깅할 필요가 있다.

따라서, 관리 기반 구조를 위한 개량된 메카니즘이 필요하다.

<발명의 요약>

다음은 본 발명의 몇몇 양태의 기본적인 이해를 제공하기 위한 본 발명의 요약을 나타낸다. 이 요약은 본 발명의 광범위한 개요가 아니다. 본 발명의 주요/필수 요소들을 식별하거나 본 발명의 범위를 기술하려는 의도가 아니다. 그 유일한 목적은 후술되는 상세한 설명에 대한 서론으로서 본 발명의 소정의 개념들을 간단한 형태로 나타내고자 하는 것이다.

본 명세서에 개시되고 청구되는 본 발명은 그 일 양태로서 개발자가 애플리케이션 또는 서비스를 그의 컴포넌트에 관하여 기술할 수 있도록 하는 혁신적인 프레임워크를 제공하는 모델 기반 관리 시스템을 포함한다. 개발자는 애플리케이션 또는 서비스의 요구되는 상태들을 기능, 구성, 보안 및 성능에 관하여 기술할 수 있다. 이러한 기술 또는 모델은 애플리케이션을 제공 받으며, 관리 서비스를 구성하기 위하여 설치시에 시스템에 의해 사용된다. 컴퓨터 시스템은 관리 서비스를 구성하기 위하여 설치시에 개발자의 기술을 이용한다. 관리 서비스는 구성 관리, 문제 검출, 진단 및 회복과 같은 자동 관리 동작을 통해 애플리케이션의 이용 가능성을 보장하는 것을 돕는다. 모델은 또한 관리자가 수행할 수 있는 공동 작업을 기술한다.

모델 기반 관리 아키텍쳐는 애플리케이션을 구성하는 컴포넌트들, 예를 들어 건강 상태 및 회복, 구성 설정 및 관리 작업에 대한 모델; 모니터링을 위한 계기 및 논리를 표시하는 소스 코드 내의 속성(attribution); 애플리케이션을 싣고, 관리 시스템 서비스에 의한 사용을 위해 기계 판독 가능 형태로 모델로부터의 정보 및 소스 코드 속성을 포함하는 하나 이상의 목록; 애플리케이션 목록 내의 정보에 의해 구성되는 다수의 서비스로 구성되는 관리 시스템; 및 목록 내에 정의되는 애플리케이션에 대한 관리 작업을 포함한다.

모델 기반 관리 아키텍쳐의 시스템 컴포넌트는 애플리케이션의 이용성을 보장하는 데 필요한 서비스들로 구성된다. 시스템은 목록에 표현되고 관리자에 의해 수정되는 요구되는 상태들을 이용하여, 종속성을 검증하고 필요한 파일, 설정 및 보안만을 설치하는 설치; 이벤트에 가입하고 지정된 바와 같이 이벤트를 전송하는 이벤트 가입; 계기 및 카운터를 주기적으로 수집하는 폴링된 계기; 자동 관리 작업을 수행하는 스케쥴링된 작업; 프로그램 기능에 대한 액세스를 제한하는 역할 기반 액세스; 문제를 검출하고, 근본 원인을 진단하고, 교정 동작을 취하고, 시스템 관리자에게 언제 조정이 필요한지를 통지하는 모니터링 기능; 및 위에 대한 정책을 개별화(customizing)하여 많은 기계들에 적용하는 중심 구성을 수행한다.

다른 양태에서, 모델 기반 관리 시스템은 하드웨어 및 소프트웨어의 분산 네트워크에 적용된다. 로컬 및 원격 애플리케이션은 물론, 로컬 및 원격 기계 및 서비스의 컴포넌트들이 적절히 기술되고 관리된다.

전술한 목적 및 관련 목적을 달성하기 위한 본 발명의 소정의 예시적인 양태들이 본 명세서에 아래의 설명 및 첨부 도면들과 관련하여 설명된다. 그러나, 이 양태들은 본 발명의 원리가 이용될 수 있는 다양한 방법들 중 일부를 나타내는 것 이며, 본 발명은 그러한 모든 양태 및 그 균등물을 포함하는 것으로 의도된다. 본 발명의 다른 이점 및 신규한 특징들은 도면과 관련하여 고려될 때 아래의 발명의 상세한 설명으로부터 명백해질 수 있다.

도 1은 본 발명에 따라 애플리케이션의 모델 기반 관리를 용이하게 하는 아키텍쳐를 나타내는 도면.

도 2는 모델 기반 관리 아키텍쳐의 주요 컴포넌트를 기술하는 것과 관련된 드로잉 맵을 나타내는 도면.

도 3a는 본 발명의 모델 기반 관리 아키텍쳐의 모델 컴포넌트와 관련된 블록도.

도 3b는 본 발명의 모델 기반 관리 아키텍쳐의 목록 컴포넌트와 관련된 블록도.

도 3c는 본 발명의 모델 기반 관리 아키텍쳐에 따라 애플리케이션 또는 서비스를 관리하는 데 사용되는 시스템 컴포넌트의 코어 시스템 API의 블록도.

도 3d는 본 발명의 모델 기반 관리 아키텍쳐의 시스템 컴포넌트의 관리 관련 API의 블록도.

도 3e는 본 발명의 모델 기반 관리 아키텍쳐의 작업 컴포넌트의 서브 컴포넌트를 나타내는 도면.

도 4는 모델 기반 관리의 프로세스의 일반 흐름도.

도 5는 모델 기반 관리를 구현하는 프로세스의 보다 상세한 흐름도.

도 6은 모델 기반 관리의 요구되는 상태들을 구현하는 프로세스의 흐름도.

도 7은 개시된 아키텍쳐를 실행할 수 있는 컴퓨터의 블록도.

도 8은 본 발명에 따른 예시적인 컴퓨팅 환경의 블록도.

이제, 본 발명은 도면을 참조하여 설명되는데, 도면 전체에서 동일한 참조 부호는 동일한 요소를 참조하는 데 사용된다. 아래의 설명에서는 설명의 목적으로 본 발명의 철저한 이해를 제공하기 위하여 많은 특정 사항이 설명된다. 그러나, 본 발명이 이러한 특정 사항 없이 실시될 수 있다는 것은 자명하다. 여러 예에서는 본 발명의 설명을 용이하게 하기 위하여 공지된 구조 및 장치들이 블록도의 형태로 도시된다.

본 명세서에서 사용되는 바와 같이, "컴포넌트" 및 "시스템"이라는 용어는 하드웨어, 하드웨어 및 소프트웨어의 조합, 소프트웨어 또는 실행중인 소프트웨어와 같은 컴퓨터 관련 엔티티를 지칭한다. 예를 들어, 컴포넌트는 프로세서 상에서 실행되는 프로세스, 프로세서, 객체, 실행 가능물(excutable), 실행 스레드, 프로그램, 및/또는 컴퓨터일 수 있으나, 이에 한하지 않는다. 예를 들어, 서버 상에서 실행되는 애플리케이션 및 서버 양자는 컴포넌트일 수 있다. 하나 이상의 컴포넌트는 프로세스 및/또는 실행 스레드 안에 상주할 수 있으며, 하나의 컴포넌트가 하나의 컴퓨터 상에 로컬화될 수 있고, 그리고/또는 둘 이상의 컴퓨터 사이에 분산될 수 있다.

본 명세서에 사용되는 바와 같이, "추론"이라는 용어는 일반적으로 이벤트 및/또는 데이터를 통해 캡쳐된 일련의 관측으로부터 시스템, 환경 및/또는 사용자의 상태를 판단하거나 추론하는 프로세스를 지칭한다. 추론은 특정 컨텍스트 또는 동작을 식별하는 데 이용될 수 있으며, 예를 들어 상태들에 대한 확률 분포를 생성할 수 있다. 추론은 확률적, 즉 데이터 및 이벤트의 고려에 기초하여 관심있는 상태들에 대한 확률 분포의 계산일 수 있다. 또한 추론은 일련의 이벤트 및/또는 데이터로부터 보다 높은 레벨의 이벤트를 구성하는 데 이용되는 기술을 지칭할 수도 있다. 이러한 추론은 이벤트들이 시간적으로 밀접하게 상관되는지의 여부, 그리고 이벤트들 및 데이터가 하나 또는 여러 이벤트 및 데이터 소스로부터 나온 것인지에 관계 없이 일련의 관측된 이벤트들 및/또는 저장된 이벤트 데이터로부터 새로운 이벤트 또는 데이터를 구성한다.

이제, 도 1을 참조하면, 본 발명에 따라 애플리케이션 또는 서비스의 모델 기반 관리를 용이하게 하는 아키텍쳐(100)가 도시되어 있다. 모델 기반 관리 방식은 개발자가 애플리케이션 또는 서비스(102)를 그의 구성 컴포넌트들에 관하여, 그리고 요구되는 상태를 기능, 구성, 보안 및 성능에 관하여 기술하는 것을 가능하게 한다. 따라서, 애플리케이션 또는 서비스 기술(104)은 애플리케이션 또는 서비스(102)를 적어도 모델 컴포넌트(106), 목록 컴포넌트(108), 시스템 컴포넌트(110) 및 작업 컴포넌트(112)를 포함하는 하나 이상의 관리 가능 컴포넌트에 관하여 기술하는 것을 용이하게 한다. 모델 기반 관리 시스템(100)은 속성 컴포넌트(114)를 이용하여 모델 컴포넌트(106)에서 목록 컴포넌트(108)로의 소스 코드의 속성을 용이하게 한다.

컴퓨터 시스템(116)은 애플리케이션(102)의 설치시에 애플리케이션 또는 서비스 기술(104)을 이용하여 컴퓨터 운영 체제와 관련된 관리 서비스(118)를 구성한다. 이어서, 관리 서비스(118)는 구성 관리, 문제 검출, 진단 및 회복과 같은 자동 관리 동작을 통해 애플리케이션 또는 서비스(102)의 이용성을 보장하는 것을 돕는다. 또한, 모델(106)은 관리자가 수행할 수 있는 공동 작업들을 기술한다. 모델 기반 관리 아키텍쳐(100)는 보다 낮은 총 소유 비용을 용이하게 하며, 개발에서 전개, 동작 및 비지니스 분석에 이르기까지 애플리케이션의 수명 전반에 사용된다. 일반적으로, 개발자는 애플리케이션 또는 서비스에 대한 하나 이상의 모델을 애플리케이션이 동작하는 방식, 애플리케이션의 구성 컴포넌트, 개발자가 모니터링을 위해 정의하고 선택하는 요구되는 건강 상태, 적어도 애플리케이션이 설치되는 방식 및 애플리케이션 또는 서비스가 요구하는 설정에 관한 구성 양태, 및 관리 작업 및 그의 스케쥴링에 관하여 생성함으로써 시작한다. 이어서, 모델의 소스 코드는 목록화를 위해 특정 영역에 속성화(태그)된다.

모델은 계기 목록 내에 롤-업(roll-up)된다. 모델은 텍스트 문서, 스프레드시트 문서 등 기타 코드, 스크립트, 툴을 통하거나 수동으로 더 많은 XML 스키마들인 경향이 있는 목록으로 변환되고, 추가적으로 기계 처리되고, 기계 판독되는 구조화된 문서의 형태인 경향이 있다. 즉, 모델 문서는 보다 인간 판독 가능하며, 목록은 보다 기계 판독 가능하다. 이어서, 목록은 시스템 관리를 용이하게 하는 데 사용된다.

속성 서브 컴포넌트(114)는 소스 코드 속성과 관련된다. 속성은 관련된 코드와 함께 관리 정보를 표현하는 데 사용된다. 속성이 없다면, 코드의 2개의 개별 부분, 즉 정상 애플리케이션 처리를 위한 부분과 코드를 관리에 노출시키기 위한 부분이 작성될 필요가 있게 된다. 소스 코드 내의 속성은 언제 모니터링 규칙을 실행할 것인지를 지정하는 것은 물론 건강을 판정 및/또는 교정하기 위해 코드의 어느 부분(소위 프로브)이 사용되어야 하는지를 기술하는 데 사용된다. 프로브는 현재의 운영 체제 애플리케이션 프로그램 인터페이스(API)에 액세스하는 컴포넌트로부터 또는 실행되는 애플리케이션 또는 서비스 내에 로딩된 컴포넌트로부터 노출될 수 있다. 두 경우 모두에서, 개발자는 컴포넌트 내의 어떤 타입들의 서브세트가 노출되어야 하고 이들이 어떻게 식별되어야 하는지를 표시하기 위한 속성을 추가한다. 프로브는 관리자 네임스페이스 내의 균일 자원 식별자(URI)를 이용하여 식별된다. 실행 시간에, 하나의 프로브는 컴퓨터 상의 모든 프로브들의 카탈로그로부터 그 프로브를 식별하고 그 프로브에 대한 관련 정보를 추적함으로써 검색된다.

또한, 소스 코드 속성은 모니터링 서비스, 예를 들어 모니터링 규칙으로 사용되고 시동시에 로딩되어야 하고, 주기적으로 폴링되어야 하고, 이벤트에서 실행되어야 하는 등의 속성 함수들에 명령을 제공할 수 있다. 이러한 속성은 자동 처리되어 계기와 동일한 방법으로 목록에 넣어질 수 있다. 따라서, 속성은 계기만이 아니라 다른 관리 목적을 위한 것이기도 하다. 또한, 속성은 관리 작업 및/또는 교정 동작을 지원하는 데 사용될 수 있다.

이제 도 2를 참조하면, 모델 기반 관리 아키텍쳐(100)의 주요 컴포넌트를 기술하는 것과 관련된 드로잉 맵(200)이 도시되어 있다. 아키텍쳐는 도 3a와 관련하여 기술되는 모델 컴포넌트(106), 도 3b와 관련하여 기술되는 목록 컴포넌트(108), 도 3c 및 3d와 관련하여 기술되는 시스템 컴포넌트(110), 및 도 3e와 관련하여 기술되는 작업 컴포넌트(112)를 포함한다. 속성은 이미 기술되었으며, 명세서 전반에서 어드레스될 것이다.

이제 도 3a를 참조하면, 본 발명의 모델 기반 관리 아키텍쳐의 모델 컴포넌트(106)와 관련된 블록도가 도시되어 있다. 모델은 애플리케이션을 구성하는 컴포넌트들, 건강 상태 및 회복, 구성 설정 및 관리 작업들에 대해 개발된다.

그 지원에 있어서, 시스템의 임의의 컴포넌트 및 모든 컴포넌트(및 그와 관련된 관계, 종속성 및 서비스 역할)를 모델링하기 위한 컴포넌트 모델 서브 컴포넌트(300)가 존재한다. 컴포넌트 모델(300)은 파일, 구성, 애플리케이션이 설치될 수 있는 상이한 방법들 등을 기술한다.

다양한 고장 상태, 및 애플리케이션 또는 서비스가 실패할 수 있는 방법을 기술하기 위한 건강 모델 서브 컴포넌트(301)가 개발될 수 있다. 건강 모델(301)은 건강 기능을 자동화하기 위하여 취해져야 하는 단계들을 기술한다. 건강 모델(301)은 적어도 고장 상태, 상태 검출, 검증, 진단 및 시스템 상태의 해결을 나타낸다. 건강 상태는 완전히 건강한 것으로 간주하기 위하여, 완전히 고장난 것으로 간주하기 위하여, 그리고 예를 들어 성능이 저하되었다거나, 부분적으로 작동하는 임의의 중간 상태인 것으로 간주하기 위해 어떤 기준이 만족되어야 하는지에 관하여 기술될 수 있으며, 고객 기능의 일부는 작동하고 있고, 서비스의 기대 레벨을 전달하는 애플리케이션 또는 서비스이다. 또한 건강은 기능이 양호할 수 있는 것으로 간주하지만, 성능은 애플리케이션 또는 서비스가 건강하지 않다는 것을 나타내는 하위 표준이다.

구성 모델 서브 컴포넌트(302)가 시스템 구성의 모델링과 연관된다. 구성 모델(302)은 애플리케이션 설정, 사용자 제어, 디폴트 값, 다양한 제한 등을 기술하는 데 사용된다. 관리 작업 모델 서브 컴포넌트(303)가 관리 작업의 모델링과 연관되며, 시작, 중지, 사용자 추가, 데이터베이스 추가 및 건강 모델(301)로부터 호출될 수 있는 교정 동작과 같이 사용자가 시스템 상에서 취할 수 있는 동작들을 포함한다. 모델(302)은 애플리케이션 또는 서비스와 함께 행해질 수 있는 모두를 열거한다. 아키텍쳐 모델(304)은 예를 들어 동일하거나 유사한 하드웨어 및 소프트웨어 설정 및 구성을 가진 클라이언트들의 대형 네트워크, 및 분산 데이터베이스와 정상적으로 관련된 분산 환경 및 관련 전개를 기술하는 데 사용된다. 따라서, 로컬 애플리케이션은 원격 디스크 어레이에 종속할 수 있다. 전개에 있어서, 디스크 어레이는 목록과 함께, URI를 이용하여 전개 레벨에서 인스턴스화될 필요가 있다. URI는 기계에 독립적이므로, 분산 시스템은 또한 본 발명의 모델 기반 관리 시스템의 이익을 얻을 수 있다. 성능 모델(305)은 개발자가 애플리케이션 또는 서비스의 성능을 모니터링하기 위한 메트릭을 사용하기를 원하는 방법을 기술하기 위해 개발될 수 있다. 이것은 시스템의 건강과 밀접한 관련이 있다. 애플리케이션 또는 서비스와 관련된 보안 타입을 기술하는 보안 모델(306)이 생성될 수 있다.

개발자는 애플리케이션 또는 서비스의 다양한 양태를 관리하기 위한 많은 다른 모델을 제공할 수 있으므로, 여기에 제공되는 모델의 수는 총망라한 것이 아님에 유의한다.

본 발명은 본 발명의 다양한 양태를 실행하는 다양한 인공 지능 기반 스키마를 이용할 수 있다. 예를 들어, 모델과 관련하여, 주어진 인스턴스 또는 구현에 대해 어떤 모델이 이용될 수 있는지를 판정하는 프로세스가 자동 분류 시스템 및 프로세스를 통해 용이하게 될 수 있다. 더욱이, 이러한 분류기는 시스템 패턴을 검출하기를 시작하고 무엇이 좋은 상태, 나쁜 상태, 그리고 성공적이고 성공적이 아닌 트랜잭션인지를 학습하는 시스템의 동작 프로파일을 구축하는 데 사용될 수 있다. 이어서, 이러한 정보는 대응 모델로 피드백되어 후속 시스템에 대한 갱신 모델로서 사용될 수 있다. 이러한 분류는 사용자가 자동 수행되기를 원하는 동작을 예측하거나 추론하기 위하여 확률 및/또는 통계 기반 분석(예를 들어 분석 효용 및 비용으로의 분해)을 이용할 수 있다. 예를 들어, 지원 벡터 기계(SVM) 분류기가 사용될 수 있다. 다른 분류 방식들에는 베이시안 네트워크, 결정 트리가 포함되며, 상이한 독립성 패턴을 제공하는 확률 분류 모델이 사용될 수 있다. 본 명세서에서 사용되는 분류는 우선 순위 모델을 개발하는 데 사용되는 통계 회귀도 포함한다.

본 명세서에서 쉽게 알 수 있는 바와 같이, 본 발명은 소정의 기준에 따라 예를 들어 주어진 구현에 대해 어떤 초기 설정이 사용되어야 하는지와, 이어서 시스템이 완성되어 데이터, 설치 애플리케이션의 수 및 상호작용할 노드들의 수와 관련된 다양한 로딩 조건을 경험할 때 시간에 따라 설정을 조정하는 것을 자동 결정하는 데 사용될 수 있도록 암시적으로 트레이닝되는 것은 물론(예를 들어 사용자 거동을 관찰하고 외부 정보를 수신하는 것을 통해) 명시적으로 트레이닝되는(예를 들어 일반 트레이닝 데이터를 통해) 분류기를 사용할 수 있다. 예를 들어, 잘 알려진 SVM은 분류기 구축자 및 기능 선택 모듈 내에 학습 또는 트레이닝 단계를 통해 구성된다. 분류기는 입력 속성 벡터 x=(x1, x2, x3, x4, xn)을 입력이 클래스에 속한다는 신뢰에 맵핑하는 함수, 즉 f(x)=confidence(class)이다. 예를 들어, 관리 시스템의 경우, 속성은 요구되는 상태의 시스템 파라미터이며, 클래스는 관심 있는 카테고리 또는 영역(예를 들어 모든 드라이브, 모든 원시 프로세스)이다. 분류기는 또한 트랜잭션 로그를 캡쳐하고 분석하며, 패턴을 찾고, 성공적인, 성공적이지 않은 패턴들을 찾음으로써 시스템을 진단하는 데 사용될 수 있다.

구성 건강은 예를 들어 큐의 크기를 5에서 10으로 변경하는 것 및 이러한 변경이 애플리케이션, 서비스 또는 시스템 상에 어떠한 영향을 줄 수 있는지를 판정하는 것을 포함한다. 보안 및 성능에도 동일하게 적용되며, 분류기는 성능 카운터를 모니터링하고 성능을 최적화하기 위해 시스템을 적절히 변경하는 데 사용될 수 있다. 보안은 또한 패턴들에 대해 모니터링되고 분석될 수 있는데, 그 영향은 보안 정책을 제안하거나 변경하는 데 사용될 수 있다. 따라서, 건강은 시스템의 많은 영역에 적용될 수 있는 넓은 개념이라는 것을 이해해야 한다. 전 시스템 범위에서 성능은 양호할 수 있지만, 보안은 열악할 수 있다. 따라서, 본 발명에 의해 제공되는 바와 같이, 시스템의 많은 분야를 포괄하는 전체적인 관측이 이롭다.

관리자의 요구되는 상태는 목록 내에 표면화되어 모니터링 서비스에 의한 모니터링을 위해 전달되는 코드 내에 표현될 수 있다. 시스템은 목록 내의 명령들에 기초하여 애플리케이션 또는 서비스를 모니터링하고, 애플리케이션 또는 서비스가 성능을 만족시키지 못할 때 관리자를 변경하며, 명령들에 기초하여 교정 동작을 취할 수 있다. 예를 들어, 이메일에 대한 테스트 설정이 유지되지 않고, 소정 기간 동안 임계치 아래로 떨어지는 경우, 로드가 떨어질 때까지 또 하나의 기계가 추가될 수 있으며, 네트워크 트래픽이 주어진 로드를 처리하기 위한 자원의 수를 증가시키는 트리거로서 사용될 수도 있다. 목표는 수동 동작이 필요할 때만 관리자가 수반되도록 가능한 한 자동화하는 것이다.

본 발명의 모델 기반 관리 시스템은 구성 가능하다. 이 시스템은 대부분의 것을 포함하는 컴포넌트를 가진 컴포넌트 기반 시스템이다. 따라서, 시스템은 가장 작은 관리 가능한 부분으로 축소되고, 백업 구성될 수 있다. 예를 들어, 데이터베이스에는, 인스턴스, 데이터베이스, 테이블 및 저장된 프로시져를 가진 애플리케이션이 있으며, 단일 파일로서 작게 축소될 수 있다. 401k 애플리케이션을 고려한다. 401k 애플리케이션은 데이터베이스, 웹 서버 및 고객 자신의 비지니스 논리에 종속하여, 운영 체제에 종속하고 관련되는 데이터베이스로 축소될 수 있다. 본 발명의 신규한 양태들에 따르면, 다양한 레벨로 관리하고 보고하는 것이 바람직하다. 애플리케이션은 컴포넌트들 사이의 관계를 통해 기술된다. 이들 관계는 개별 애플리케이션이 결합되는 방식(예를 들어 SQL 서버는 서비스, 인스턴스 및 데이터베이스를 포함한다), 플랫폼 요건(예를 들어 운영 체제 및 다른 애플리케이션), 및 다른 컴포넌트들에 대한 통신(SQL 서버에 접속되는 웹 서버)을 표현할 수 있다. 단일 관리자가 데이터베이스 및 단일 기계에 대해 관심을 가질 수 있는 반면, 재정 관리자가 401k 애플리케이션에 대해 관심을 가질 수 있고, CIO가 애플리케이션 및 기계 모두에 대해 관심을 갖는다. 모델, 보고 및 요구되는 상태는 시스템이 예측되는 것을 행하고 있는지를 판정하기 위해 개별 매트릭이 참조될 수 있도록 모든 것을 처리해야 한다.

시스템을 네비게이션하는 표준 방법을 제공하고, 설치된 모든 컴포넌트를 열거하며, 컴포넌트에게 컴포넌트가 무엇을 제공하는지, 무엇이 건강한 것으로 간주되는지, 컴포넌트가 어떤 이벤트를 갖는지, 마지낙 말 또는 시간에 어떤 에러 이벤트가 발생했는지, 구성 설정이 포함되는지, 최종 시간에 어떤 변화가 발생했는지 등을 묻는 모든 모델이 URI 네임스페이스 안에 결합된다.

이제 도 3b를 참조하면, 본 발명의 모델 기반 관리 아키텍쳐의 목록 컴포넌트(108)와 관련된 예시적인 블록들이 도시되어 있다. 애플리케이션을 실은 목록은 관리 시스템 서비스에 의한 사용을 위해 기계 판독 가능 형태로 모델로부터의 정보 및 소스 코드 속성을 포함한다. 애플리케이션에 대한 관리 작업은 목록 내에 정의된다. 컴포넌트 종속성, 컴포넌트들 간의 관계 및 서비스 역할과 관련된 제1 목록 서브 컴포넌트(307); 이벤트, 프로브, 규칙 및 동작과 관련된 제2 목록 서브 컴포넌트(308); 설정 및 표명과 관련된 제3 목록 서브 컴포넌트(309); 명령(즉 cmdlets) 및 관리 역할과 관련된 제4 목록 서브 컴포넌트(310); 분산 환경과 관련된 제5 목록 서브 컴포넌트; 및 전개와 관련된 제6 목록 서브 컴포넌트를 포함하는 모델들에 대응하는 다수의 목록이 생성될 수 있다.

목록은 개발자와 조작 팀 및 관리자와의 "브리지"이며, 속성화된 코드에 대한 모델을 스위핑하는 툴에 의해 자동 생성된다. 컴포넌트 목록(307)은 셋업 엔진에 의해 애플리케이션 또는 서비스를 어떻게 설치할 것인지를 결정하는 데 사용된다. 이 목록은 논리 컴포넌트, 파일, 파일이 설치되어야 할 장소, 및 구성 설정(또는 임의의 설정)을 기술한다. 종속성은 설치 전에 정의될 필요가 있으며, 다양한 역할을 포함하여, 애플리케이션이 가변 보안 등급 및 상이한 동작 프로파일을 가진 여러 모드로 설치될 수 있게 한다. 컴포넌트 목록(307)은 사용자 및/도는 시스템이 수동으로, 그리고 자동으로 무엇을 해야할 지를 아는 것을 보다 쉽게 해준다. 목록 입도는 컴포넌트 당 하나의 목록으로 감소될 수 있다.

일반적으로, 실제로 필요한 것보다 많은 파일이 설치된다. 목록은 필요한 파일들만을 설치할 수 있게 해준다. 이것은 적어도 성능과 보안성을 향상시킨다. 소프트웨어 종속성은 목록(307)에 정의된다. 애플리케이션 레벨에서, 종속성은 단일 기계에 특정될 수 있으며, 컴포넌트 관계 및 하드웨어 자원을 정의할 수 있다. 컴퓨터는 목록에 의해 기술될 수 있는데, 예를 들어 애플리케이션은 특정 제조자의 이중 프로세서 기계 상에 전개되거나 4 프로세서 기계와 인터페이스해야 한다. 이 목록(307)은 프로세서, 메모리, 장치 등을 구현에 필요한 하드웨어 입도까지 기술한다. 따라서, 관리는 일반 시스템에서와 같이 보다 주도적이고 반응적일 수 있다. 하드 디스크 고장은 예를 들어 시스템 온도가 시간에 따라 모니터링되고, 전원 레일 전압이 모니터링되나, 충분한 것으로 발견된 경우 열적 고장에 의해 발생한 것으로 결정될 수 있다.

건강 모델(301)은 건강 목록(308)을 생성하는 데 사용된다. 건강 목록(308)은 속성 및 다른 툴을 이용하여 건강 모델(301)로부터 채워진다. 이벤트는 모델(301)에서 호출되지 않고 자원 파일에서 호출된다. 툴은 자원 파일 및 속성화된 소스 코드를 스위핑하여 건강 목록(308)을 채운다. 고장 상태는 소정의 이벤트 시퀀스를 감시하거나 성능 카운터 임계치를 모니터링함으로써 검출될 수 있다. 고장 상태들이 어떻게 어드레스될 수 있는지에 관한 명령들이 제공될 수 있다. 건강 모델은 규칙으로 변환된다. 건강 목록(308)은 이벤트1, 이벤트2, 시간3 등의 파라미터를 가진 규칙 타입 이벤트 시퀀스를 포함한다.

구성 모델(302)은 어떤 설정이 포함되는지를 기술하며, 설정 및 표명 목록(309)으로 변환되는데, 이 목록(309)은 설치될 때 설정을 생성하도록 시스템에 대해 명령 스키마를 제공한다.

관리 작업 모델(303)은 cmdlets 및 관리 역할 목록(310)을 통해 동작들로 변환된다. 예를 들어, 데이터 백업이 요구되는 경우, cmdlet는 백업 작업을 용이하게 하는 데 사용되는 실제 코드 또는 URI이다. 다수의 관리 작업이 수행될 필요가 있는 경우, 목록(310)은 명령들 및 아마도 코드에 URI 경로를 제공한다. cmdlet는 코드 상의 표명을 통해 처리되거나 외부 코드를 요구할 수 있다. 관리 역할은 예를 들어 애플리케이션 또는 서비스, 및 각자 행할 수 있는 제어 레벨을 관리하는 다수의 사용자 클래스를 지원하는 또 하나의 추상 개념이다. 이것은 역할 기반 액세스와 관련된다. 다양한 사용자의 역할과 그들의 허용 능력을 기술하는 메타데이터가 필요하다. 역할들은 시스템의 모든 양태-누가 설치하는 것이 허용되는지, 누가 모니터링을 변경할 수 있는지, 누가 건강을 관찰할 수 있는지, 누가 경보를 해결할 수 있는지, 누가 이러한 다양한 동작을 취할 수 있는지 등-를 포괄한다.

작업 모델(303)은 목록(310)에 표현되는 바와 같이, 그리고 조작 팀들에 의해 그 환경에 대해 개별화되는 바와 같이 관리자가 해야 하는 것으로 개발자가 생각하는 것을 정의한다. 이러한 개별화는 클래스 레벨 및 인스턴스 레벨에서 행해질 수 있다. 변경은 클래스 레벨에서, 인스턴스 레벨에서 목록 내에 만들어질 수 있으며, 변경은 실행 시간에 직접 만들어질 수 있다. 개시된 모델 기반 관리 아키텍쳐의 매우 강력한 특징은 클래스 레벨에서 먼저 성능이 기술될 수 있는 반면 실행 시간에 인스턴스 공간이 액세스된다는 점이다.

아키텍쳐 모델(304)은 분산 컴포넌트 목록(311) 및 전개 목록(312)을 표면화한다. 예를 들어, 기계들 간의 네트워크 접속, 하드웨어 요건은 여기서 커버된다. 전개 목록(312)은 웹 서버, 중간 결합 서버 및 데이터베이스 서버를 포함하는 애플리케이션을 적어도 지원하며, 프론트엔드/백엔드 애플리케이션, 2개의 애플리케이션 간의 네트워크 접속성을 포함하며, 개별 노드들 간의 관계를 기술한다. 전개 시간은 전체 아키텍쳐 모델(304)에 기술되는 것들의 인스턴스를 생성한다.

성능 및 보안 모델(305, 306)은 각각 관련 기능 및 동작을 기술하는 대응하는 목록들(도시되지 않음)을 지원한다.

기계 기반 학습의 이용으로 돌아가면, 분류기는 예를 들어 제1 전개 동안 요건에 기초하여 모델 코드의 선택 부분의 목록을 선택하고 동적으로 생성하는 데 사용될 수 있다. 디폴트 모델은 보다 많은 속성 또는 보다 적인 속성을 이용하여 자동 생성될 수 있다. 시간에 따라, 시스템 동작 정보가 이용 가능해질 때, 이러한 정보는 분석되어, 목록의 입도 레벨이 예를 들어 가장 최근의 데이터 트랜드 및 로그에 기초하여 특정 영역에서 시스템을 보다 밀접하게 모니터링할 수 있도록 조정될 수 있다. 이엇, 갱신된 목록은 애플리케이션 또는 서비스를 보다 밀접하게 모니터링하는 것이 필요할 때 재생성되어 사용된다.

목록이 디폴트 설치 또는 제조자로부터 추천되는 최상의 실시를 기술하는 경우, 관리자는 그것을 변경하기를 원할 수 있다. 예를 들어, 건강 규칙에 관하여, 관리자는 임계치를 30에서 50으로 변경하거나 컴포넌트를 설치하거나 보안 정책을 오버라이드하기를 원할 수 있다. 이것은 제조자에 의해 번들로 제공된 목록을 오버라이드하기 위해 개별화된 목록 버젼을 생성함으로써 이루어질 수 있다. 다른 버젼이 설치 동안 검출될 수 있으며, 사용자에게 디폴트 목록 또는 고객 목록을 선택할 수 있는 옵션을 허용한다. 대안으로, 오버라이드들을 리스트한, 시스템이 판독하는 개별 파일이 있을 수 있으며, 이 오버라이드들은 디폴트 목록에 적용될 수 있도록, 또는 설치 동안 사용자가 선택할 수 있게 표시되어, 디폴트 설정이 오버라이드될 수 있게 한다.

분산 애플리케이션들에 관하여, 관리자는 그가 그들 중 3개, 그 중 4개, 및 그들 중 6개, 이러한 구조에서 연결되는 모두를 원한다는 것을 보다 일반적으로 규정할 수 있다. 관리자는 주어진 환경에 따라 적절히 전개 목록(312)을 개별화할 수 있다.

이제 도 3c를 참조하면, 본 발명의 모델 기반 관리 아키텍쳐에 따라 애플리케이션 또는 서비스(314)를 관리하는 데 사용되는 시스템 컴포넌트(110)의 코어 시스템 API의 블록도가 도시되어 있다. 시스템 컴포넌트(110)는 본 발명에 따라 관련되는 애플리케이션 또는 서비스(314)를 포함한다. 시스템(110)은 모델 기반 관리를 용이하게 하기 위해 협동 통신하는 다수의 API를 포함한다. 시스템(110)은 애플리케이션 목록(도 3b와 관련하여 기술됨) 내의 정보에 의해 구성되는 다수의 서비스를 포함한다.

시스템(110)은 애플리케이션의 이용성을 보장하는 데 필요한 서비스들로 이루어지며, 목록 컴포넌트(108)에 의해 표현되고 관리자에 의해 수정되는 요구되는 상태들을 이용하여, 종속성을 검증하고 필요한 파일, 설정 및 보안만을 설치하기 위한 설치; 이벤트에 가입하고 지정된 바와 같이 전송하는 이벤트 가입; 계기 및 카운터를 주기적으로 수집하는 폴링된 계기; 및 종합 트랜잭션 또는 사용자 트랜잭션의 자극을 수행한다. 애플리케이션이 이용가능하고 예측된 대로(요구되는 상태) 수행하고 있는지를 결정하는 최상의 방법 중 하나는 모니터링 시스템이 사용자인 것처럼 애플리케이션을 사용하는 것이다. 이것은 능동적인 모니터링이다. 잠재적인 제2의 방법은 실제의 사용자 트랜잭션을 능동 모니터링하고 분석을 위해 수집된 데이터를 시스템에 보고하는 것이다. 이러한 단계들은 루프를 닫으며, 내부 애플리케이션 데이터가 충분하지 않다는 것을 나타낸다. 모델 기반 관리는 애플리케이션 외부에서도 동작한다.

시스템(110)은 목록 컴포넌트(108)에 표현된 요구되는 상태를 이용하여 자동 작업 관리를 위한 작업 스케쥴링; 프로그램 기능에 대한 액세스를 제한하는 역할 기반 액세스; 문제를 검출하고, 근본 원인을 진단하고 교정 동작을 취하고 시스템 관리자에게 언제 조정이 필요한지를 통지하기 위한 모니터링; 및 상기한 것들에 대한 정책을 개별화하여 많은 기계들에 적용하는 중심 구성을 또한 수행한다.

애플리케이션의 설치, 애플리케션의 갱신 및 패치를 용이하게 하기 위해 애플리케이션(314)과 통신하는 설치 API(316)가 제공된다. 설치 API(316)는 코드를 통해 목록 어셈블리를 취하고, 시스템이 이 기계에서 이 컴포넌트, 이 목록 및 이 버젼을 설치하도록 명령함으로써 어셈블리를 인스턴스화한다. 설치 API(316)는 프로토콜(318) 및 뷰어(320)와 연관되어 있다. 프로토콜(318)은 API 관련 데이터와 시스템(110)의 다른 컴포넌트의 통신을 용이하게 한다. 뷰어(320)는 설치 API(316)와 관련된 데이터를 표시한다. 설치 API(316)는 단일 기계 상의 설치를 용이하게 할 뿐만 아니라 하드웨어 공급 및 추상화는 물론 로컬 및 원격 시스템 양자를 포함한 분산 애플리케이션 또는 서비스에 대해서도 용이하게 한다. 분산 데이터 중심 환경에서는 하드웨어 시스템을 일반적으로, 보다 세밀한 입도로 특정 기계 추상화로 추상화할 수 있는 것이 중요하다. 여기서 API에 관해 고려되는 프로토콜은 API 관련 데이터의 전송 및 수신을 지배하는 규칙이다. 뷰어(320)는 본 명세서에서 이해되는 바와 같이 API, 여기서는 설치 API(316)와 관련된 데이터를 표시하는 프로그램이다. API 데이터는 예를 들어 사운드 파일, 비디오 파일, 및 다른 타입의 데이터 파일을 포함하지만 이에 한하지 않는다.

시스템(110)은 애플리케이션(314)의 구성을 용이하게 하기 위해 애플리케이션(314)와 통신하는 구성 API(322)를 포함한다. 구성 API(322)는 스키마(323), 프로토콜(324), 및 뷰어(326)와 연관되어 있다. 스키마(323)는 API(322)와 애플리케이션(314) 사이에 전달되는 데이터의 구조 및 내용을 정의한다. 프로토콜(324)은 API 관련 데이터와 시스템(110)의 다른 컴포넌트의 통신을 용이하게 한다. 뷰어(326)는 구성 API(322)와 관련된 데이터를 표시한다.

또한, 분산 환경에서의 다수 대 일(many-to-one) 관리를 용이하게 하는 관리 API(328)가 제공된다. API(328)는 관리되는 애플리케이션(314) 및 원격 시스템(도시되지 않음)과도 통신한다. API(328)는 연관된 프로토콜(330) 및 뷰어(332)를 갖는다.

시스템(110)은 애플리케이션(314)의 관리에 이용되는 카운터 변수의 추적을 용이하게 하기 위해 애플리케이션(314)과 통신하는 성능 카운터 API(334)를 포함한다. 카운터 API(334)는 프로토콜(336) 및 뷰어(338)와 연관되어 있다. 프로토콜(336)은 API 관련 데이터와 시스템(110)의 다른 컴포넌트의 통신을 용이하게 한다. 뷰어(338)는 카운터 API(334)와 관련된 데이터를 표시한다. 성능 카운터는 애플리케이션(314)에 의해 노출되고, 뷰어(338)를 통해 카운터를 공표한다.

계기의 구성 및 애플리케이션(314)으로의 계기 데이터의 전달을 용이하게 하기 위해 애플리케이션(314)과 통신하는 계기 API(340)가 제공된다. 계기 API(340)는 프로토콜(342) 및 계기가 노출되는 뷰어(344)와 연관되어 있다. 프로토콜(342)은 API 관련 데이터와 시스템(110)의 다른 컴포넌트의 통신을 용이하게 한다. 뷰어(344)는 계기 API(340)와 관련된 데이터를 표시한다. 계기 API(340)는 IPC(프로세스간 통신; 346)를 통해 관리되는 애플리케이션(314)과 통신한다. IPC는 동일 컴퓨터 내에서 또는 네트워크 상에서 하나의 프로그램과 다른 프로그램 사이의 데이터의 자동 교환이다. IPC 기능의 일례는 사용자가 클립보드를 이용하여 하나의 파일에서 다른 파일로 데이터를 수동으로 잘라 붙일 때 수행된다. 카운터는 항상 공유 메모리를 통해 공표되지만, 계기는 주문시에 전달된다. 또한 계기 API(340)는 이벤트 스키마와 유사한 방식으로 계기 클래스의 표면을 기술하는 스키마(348)를 포함한다. 또한 계기 로그(도시되지 않음)가 포함될 수 있지만, 많은 관리자는 이벤트 로그의 이용을 선호한다.

시스템(110)은 컴포넌트 및 모드 정보의 추적을 유지하고 이를 캐시하는 스토어인 카탈로그(347)를 포함한다. 모드 정보는 설치시 목록으로부터 나오며, 부분들은 동적이고 실행시에 갱신된다. 카탈로그(347)는 카탈로그 API를 포함하며, 그 안에 저장된 몇몇 타입의 데이터만을 들기 위해 이벤트, 카운터, 계기 및 구성 데이터에 대한 액세스를 제공한다. 카탈로그(347)에 대한 액세스는 프로토콜(351) 및 뷰어(353)에 의해 용이하게 된다. 중심 구성 데이터베이스는 다수의 관리되는 노드 전체에 카탈로그의 롤업 또는 집합 뷰를 포함한다.

시스템(110)은 애플리케이션(314)의 관리에 사용되는 이벤트의 구현 및 추적을 용이하게 하기 위해 애플리케이션 또는 서비스(314)와 통신하는 이벤트 API(350)를 포함한다. 이벤트 API(350)는 발생하는 모든 이벤트에 대한 스토어로서 기능하는 이벤트 로그(352)와 인터페이스한다. 이벤트 API(350)는 프로토콜(354) 및 뷰어(356)와 연관되어 있다. 프로토콜(354)은 API 관련 데이터와 시스템(110)의 다른 컴포넌트의 통신을 용이하게 한다. 뷰어(356)는 이벤트 API(350)와 관련된 데이터를 표시한다. 애플리케이션(314)와의 통신은 이들 사이에 전달되는 데이터의 구조 및 내용을 정의하는 이벤트 스키마(358)에 따른다. 이벤트는 기술되거나 발생할 때 공표된다. 스키마는 이벤트의 표면을 기술한다.

시스템(110)은 정상적으로 애플리케이션(314)과 상호작용하여 행해질 수 있는 프로시져의 자동화를 용이하게 하기 위해 애플리케이션(314)과 통신하는 자동화 API(360)를 포함한다. 자동화 API(360)는 프로토콜(362) 및 쉘(364)와 연관되어 있다. 프로토콜(362)은 API 관련 데이터와 시스템(110)의 다른 컴포넌트의 통신을 용이하게 한다. 쉘(364)은 자동화 프로세스와 관련된 데이터를 입력하고 표시하기 위한 사용자 상호작용 및 자동화 프로세스의 사용자 제어를 용이하게 하기 위해 자동화 API(360)에 사용자 인터페이스를 제공한다.

시스템(110)은 애플리케이션(314) 및 자동화 API(360) 양자와 통신하는 스케쥴링된 작업 API(366)를 더 포함한다. 스케쥴링 작업 API(366)는 적어도 자동화 API(360) 및 관리되는 애플리케이션(314)에 대한 작업 또는 프로그램의 스케쥴링을 용이하게 한다. 이것은 실행될 작업들의 리스트를 유지하고 자원을 적절히 할당한다. 스케쥴링 작업 API(366)는 프로토콜(368) 및 뷰어(370)와 연관되어 있다. 프로토콜(368)은 API 관련 데이터와 시스템(110)의 다른 컴포넌트의 통신을 용이하게 한다. 뷰어(370)는 스케쥴링 작업 API(366)와 관련된 데이터를 표시한다. 작업 스키마(372)가 작업 API와 다른 컴포넌트 사이에 전달되는 데이터의 구조 및 내용을 정의한다.

자동화 및 작업 데이터는 작업 및 cmdlets 모델로부터 수신된다. 이러한 기능은 로컬하게 또는 원격적으로 관리 쉘을 통해 자동화될 수 있다. 스케쥴링 시스템은 이들을, 예컨대 오전 3시에 백업을 실행할 수 있다.

도 3c에 도시된 컴포넌트들은 로컬 구현의 컴포넌트를 나타낼 수 있지만, 도 3d의 컴포넌트들은 많은 기계 및 소프트웨어 시스템 전체에서 분석이 발생하도록 하는 분산 구현과 연관된 컴포넌트를 나타낼 수 있다는 것을 이해해야 한다. 따라서, 분산 구현에 있어서, 도 3d의 컴포넌트들은 도 3c의 로컬 시스템들 중 적어도 하나와 통신하지만, 일반적으로 유선 및/또는 무선 체제에서는 복수의 로컬 구현과 통신한다. 로컬 구현에 있어서, 시스템(110)은 또한 로컬 모니터링 서비스 API(365)를 포함하는 도 3d의 컴포넌트들 중 어느 하나 또는 모두를 포함할 수 있다. 로컬 모니터링 서비스 API(365)는 또한 프로토콜(367), 뷰어(369), 및 스키마(371)를 포함하는데, 이들 각각은 다른 API의 대응 컴포넌트와 유사한 기능을 용이하게 한다. 분산 구현에 있어서, 로컬 모니터링 서비스(365)는 후술되는 분산 모니터링 서비스에 모니터링 정보를 전달한다.

이제 도 3d를 참조하면, 본 발명의 모델 기반 관리 아키텍쳐의 시스템 컴포넌트(110)의 관리 관련 API의 블록도가 도시되어 있다. 중심 구성 API(376)를 통해 액세스 및 제어가 제공되는 구성 데이터베이스 서브 컴포넌트(374)가 제공된다. 중심 구성 API(376)는 시스템(110)의 모든 서브 컴포넌트와 통신하며, 통신 및 상호작용을 위한 프로토콜(378) 및 뷰어(380), 및 표명 및 디폴트 값과 같은 구성 설정 및 속성의 형상을 기술하는 스키마 컴포넌트(382)와 연관되어 있다. 프로토콜(378)은 API 관련 데이터와 시스템(110)의 다른 컴포넌트의 통신을 용이하게 한다.

관리 시스템의 동작 관련 데이터, 예를 들어 보고, 현재 상태 및 이력 데이터에 대한 저장소로서 기능하는 동작 데이터베이스 서브 컴포넌트(383)가 또한 제공된다. 모니터링 API(384)는 동작 데이터베이스(383) 및 모델 기반 관리 시스템의 모든 서브 컴포넌트와 인터페이스하며, 프로토콜(385), 뷰어(386) 및 스키마(387)와 연관되어 있다. 프로토콜(385)은 API 관련 데이터와 시스템(110)의 다른 컴포넌트의 통신을 용이하게 한다. 뷰어(386)는 모니터링 API(384)와 관련된 데이터를 표시한다. 스키마(387)는 적어도 구조 내의 각각의 데이터 요소가 포함할 수 있는 내용의 구조 및 타입에 관하여 전체 동작 데이터베이스(383)에 대한 정의를 제공한다.

중심 구성은 API들 모두와 접촉할 수 있으며, 어떤 기계에 애플리케이션이 설치되어야 하는지 등과 같은 분산 애플리케이션 시나리오에 대한 세부 사항을 포함할 수 있는 구성 세부 사항을 설정하기 위해 관리자에 의해 사용된다. 구성은 또한 모니터링 구성을 포함한다. 예를 들어, 모든 기계는 5분 동안 80% 이상의 CPU 사용을 보여야 한다. 따라서, 모니터링 시스템은 구성 시스템을 이용한다. 모니터링은 관리자가 모델에 대해 거동하고 구성되고 설치되는 것을 관리자 시스템을 통해 보장하는 방법이다. 이것은 또한 예측된 기능, 원하는 양의 보안, 적절한 이행, 사용자에 대한 예측 데이터의 전달을 보장하는 것을 또한 포함한다. 따라서, 모니터링은 그러한 영역 모두를 포괄한다. 일반 프로세스는 주문에 따라 작업을 설치하고, 구성하고 실행하며, 이벤트를 소비하고, 계기, 구성을 제공하며, 데이터 및 결과를 저장하는 것이다. 건강 목록은 모니터링 시스템에 대한 명령인 규칙의 형태로 모니터링 시스템에 작업 명령을 제공한다. 일반적으로, 목록은 실행 시간 명령을 포함하며, 실행 시간은 요구되는 상태를 구현한다.

모니터링 서비스는 로컬 서비스는 물론 중심 또는 분산 메카니즘이다. 분산 구현에 있어서, 건강은 로컬 기계의 건강은 물론 로컬 및 원격 기계들 사이의 관계를 포함한다. 예를 들어, 기계 열대의 클러스터가 주어질 때, 6대가 적절히 기능하고 있는 한, 시스템은 건강한 것으로 간주된다. 그러나, 5대 이하의 기계가 동작하고 있다면, 시스템 건강 상태는 주의 상태로 저하된다. 4대 이하의 기계가 동작하고 있는 경우, 시스템 건강은 고장 상태로 간주될 수 있다. 하드웨어 추상화는 하나 이상의 클러스터 기계가 고장나거나 오프라인 상태가 되는 경우 하나 이상의 백업 시스템 또는 애플리케이션/서비스를 온라인 상태로 가져오는 것을 용이하게 한다. 따라서, 유휴 또는 공유 자원의 풀(pool)이 명령들에 기초하여 제어될 수 있다. 이러한 기능은 데이터베이스 중심 환경에서 특히 유용하다. 자동화된 동작들은 시스템이 최적 또는 적어도 최소 기능을 유지하는 것을 보장하도록 구현될 수 있다.

모델 기반 관리 아키텍쳐의 일 양태는 시스템이 건강한 것으로 간주되기 위해 만족되어야 하는 기준을 표현하는 다수의 규칙을 개발자가 만들 수 있게 해준다. 모니터링 API(384)는 규칙들의 암시적인 동시 프로세싱을 용이하게 하는 규칙 실행 시간 엔진을 포함한다. 규칙 엔진은 규칙들이 규칙 정의 언어(RDL)를 이용하여 표현되는 중간 형태로 규칙들을 표현하는 입력 명령을 수신한다. 규칙 엔진은 또한 규칙 코드를 인스턴스화하는 데 사용되는 구성 데이터를 구성 데이터베이스(374)로부터 수신한다. 번역기는 입력 명령을 판독하여 이들을 병렬 실행 형태로 변환한다. 실행 시간 엔진은 변환된 명령을 판독하고 병렬 실행을 용이하게 한다. 규칙 코드는 어떤 규칙을 실행할 것인지는 물론 규칙을 실행하는 데 필요한 파라미터를 지정하는 구성 데이터를 실행 시간 엔진에 로딩함으로써 인스턴스화된다. 규칙 파라미터는 문제가 검출된 경우에만 큰 시스템 영향을 갖는 규칙들을 인에이블시키는 등 실행시에 변경될 수 있다. 따라서, 규칙들은 동적인 것은 물론 적절히 변경될 수도 있는 임계치이다. 모니터링 API(384)는 시스템(110)의 모든 서브 컴포넌트에도 접속된다.

또한, 관리자에 의해 사용되는 목록 저장 및 편집 서비스(388)가 제공된다. 목록 서비스(388)는 목록 기능을 관리자에게 노출시키기 위한 프로토콜(389) 및 뷰어(390)와 연관되어 있다. 목록 서비스(388)는 프로토콜(389) 및 뷰어(390)를 통해 관리자에게 목록을 제공하여, 관리자가 설치 전에 목록을 보고 변경할 수 있게 한다. 목록 서비스(388)는 또한 갱신 및 개별화에 따라 목록의 버젼화를 용이하게 한다.

또한, 모델 기반 관리 시스템의 모든 서브 컴포넌트와 인터페이스하며 프로토콜(392) 및 뷰어(393)와 연관되어 있는 역할 기반 액세스 API(391)가 제공된다. 프로토콜(392)은 API 관련 데이터와 시스템(110)의 다른 컴포넌트의 통신을 용이하게 한다. 뷰어(393)는 역할 기반 API(391)에 관련된 데이터를 표시한다. API(391)는 모델 기반 관리 시스템의 다양한 컴포넌트 및 양태에 대한 액세스의 전반적인 관리를 제공하기 위하여 모니터링 및 구성 컴포넌트들 위의 레벨에 도시된다. 역할 기반 액세스 API(391)는 프로토콜(392) 및 뷰어(393)를 포함할 필요는 없는데, 그 이유는 이들 기능들이 시스템(110)의 다른 컴포넌트들에 의해 용이하게 될 수 있기 때문이다.

시스템은 또한 기계 기반 학습 및 제어를 위한 분류기(394)를 포함한다. 전술한 바와 같이, 분류기(394)는 몇가지만을 들기 위해 시스템 성능 및 건강을 향상시키기 위해 많은 방법들에 사용될 수 있다. 기계 기반 학습을 용이하게 하기 위하여, 분류기(394)는 시스템의 모든 컴포넌트들이 액세스되고 그 데이터가 사용될 수 있도록 중심 구성 서비스(376)와 인터페이스한다.

이제, 도 3e를 참조하면, 본 발명의 모델 기반 관리 아키텍쳐의 작업 컴포넌트(112)의 주요 서브 컴포넌트들이 도시되어 있다. 작업은 관리 작업 모델을 통해 기술된다. 작업은 3개의 서브 컴포넌트, 즉 모니터링 서브 컴포넌트(395), 고장 수리 컴포넌트(396) 및 관리 서브 컴포넌트(397)로 이루어진다.

모니터링 서브 컴포넌트(395)의 작업은 건강, 보안, 패치, 구성, 성능 및 애플리케이션 데이터의 감독을 포함한다. 고장 수리 컴포넌트(396)의 작업은 건강 상태의 진단, 경보의 처리, 및 이벤트, 계기 및 성능 로그의 갱신을 포함한다. 관리 서브 컴포넌트(397)의 작업은 중심 구성/정책, 스케쥴링 및 갱신 전개를 포함한다. 관리는 단일 시스템의 관리는 물론 예를 들어 많은 기계, 애플리케이션, 시스템, 정책, 백업 시간, 변경 및 갱신의 관리도 포함한다.

URI는 모델 기반 관리 아키텍쳐에서 추상 또는 물리 자원들 또는 자원들의 집합을 고유하게 식별하기 위해 사용된다. 자원에 대한 스키마가 자원에 대한 플레이스 홀더(placeholder)를 가진 URI에 의해 식별될 수 있다. 플레이스 홀더를 가진 URI는 URI 템플릿이라 한다. 시스템의 카탈로그는 특정 인스턴스의 참조 없이 계를 기술하기 위하여 URI 템플릿에 의존한다. URI 탬플릿은 프로브들이 식별되고 그들의 특징이 특정 인스턴스에 대한 프로브의 실제 검색 없이 이해될 수 있게 한다. 인스턴스들과 별개로 계기를 미리 정의하는 능력을 보호하는 것은 규칙들의 전개 및 저작을 보다 용이하게 하며, 관련 운영 체제를 관리 가능하게 만든다.

모델 기반 관리 프레임워크는 RDL을 이용하여 소프트웨어 및 하드웨어의 이용성을 모니터링하기 위한 규칙들의 정의를 가능하게 한다. RDL로 작성된 규칙들은 실행 시간 엔진에 의해 모니터링 서비스의 일부로서 실행된다. RDL의 목적은 표명을 테스트하고, 실행 시간 정보를 이용하여 제한을 실시하고, 추론을 행하고, 상관을 행하며 동적 테스트의 결과를 다른 컴포넌트에 전달하는 것이다. RDL은 규칙 타입(즉 클래스)을 정의하는 반면, 개별 XML(확장형 마크업 언어) 문서는 인스턴스화에 필요한 파라미터 값을 지정함으로써 규칙 타입의 인스턴스를 생성하는 데 사용된다. 시스템이 문제 검출, 진단, 해결, 검증 및 경고를 위해 취해야 하는 단계들의 시퀀스를 기술하기 위한 스키마가 존재한다. 이것은 모델에 기술되고, 목록에 표현되며, 모니터링 시스템에 의해 실행/관리되는 것이다.

모델 기반 관리 프레임워크는 전술한 바와 같이 이벤트를 이용하고, 서비스 및 테스트 또는 종합 트랜잭션의 건강 모델(또는 상태)을 표시하기 위해 성능 카운터의 값을 갱신한다. 건강 모델(301)은 서비스 또는 컴포넌트가 어떻게 실패할 수 있는지에 대한 그래픽 및/또는 텍스트 표현이며, 이는 관리자가 서비스의 다양한 이벤트 및 성능 카운터의 중요성을 이해하고 관측된 계기 데이터에 기초하여 어떤 동작을 취할 것인지를 효율적으로 결정하는 것을 돕는다. 개발자는 모델 및 소스 코드 속성으로부터 생성되는 대응 파일과 함께 건강 모델(301)을 구축한다.

건강 모델(301)은 종속성 외에 컴포넌트 관계의 기술을 포함한다. 검출된 문제의 상황에 따라, 시스템은 관계 트리를 돌아 보고 다른 컴포넌트들의 건강에 기초하여 근본 원인을 결정할 수 있다. 이러한 방법은 본 발명에 따라 사용되는 모델 및 목록에 의해 지원된다.

개시된 아키텍쳐는 서비스 정의 모델 시스템으로 애플리케이션을 찾는데, 이 시스템의 다양한 양태는 본 출원의 양수인의 특허 출원들, 즉 2003년 10월 일자로 출원된 "분산 컴퓨팅 시스템의 아키텍쳐 및 분산 애플리케이션의 자동 설계, 전개 및 관리"라는 제목의 미국 특허 출원 번호 제 호, 및 2003년 10월 일자에 출원된 "애플리케이션의 통합 설계, 전개 및 관리 단계"라는 제목의 미국 특허 제 호의 주제이다.

이제 도 4를 참조하면, 모델 기반 관리의 프로세스의 흐름도가 도시되어 있다. 설명의 간략화를 위해 예를 들어 흐름도의 형태로 본 명세서에 도시된 하나 이상의 방법이 일련의 동작으로서 도시되고 설명되지만, 본 발명에 따르면 소정의 동작들은 본 명세서에 도시되고 설명된 것과 다른 순서로 그리고/또는 다른 동작들과 동시에 이루어질 수 있으므로 본 발명은 동작들의 순서에 의해 한정되지 않는다는 것을 이해해야 한다. 예를 들어, 방법이 상태도에서와 같이 일련의 상호 관련된 상태들 또는 이벤트들로서 표현될 수도 있다는 것을 당업자는 이해할 것이다. 더욱이, 모두 도시되지 않은 동작들이 본 발명에 따른 방법을 구현하는 데 필요할 수 있다.

400에서, 설치될 애플리케이션 또는 서비스가 그 컴포넌트들에 관하여 기술된다. 402에서, 애플리케이션 또는 서비스는 기능, 구성, 보안 및 성능에 관하여 요구되는 상태에서 기술된다. 404에서, 기술은 설치 동안 애플리케이션 또는 서비스와 함께 제공되며, 이 기술은 시스템에 의해 시스템의 관리 서비스를 구성하는 데 사용된다. 이어서, 프로세스는 종료 블록에 이른다.

이제 도 5를 참조하면, 모델 기반 관리를 구현하기 위한 프로세스의 보다 상세한 흐름도가 도시되어 있다. 500에서, 애플리케이션 컴포넌트, 건강 상태 및 회복, 구성 설정 및 관리 작업에 대한 모델이 개발된다. 502에서, 사용자는 환경에 따라 시스템/규칙/모델을 개별화한다. 504에서, 모니터링을 위한 계기 및 논리를 표시하기 위해 소스 코드에 속성이 삽입된다. 506에서, 관리 시스템 서비스에 의해 사용되는 모델 정보 및 소스 코드 속성에 대한 목록이 제공된다. 목록은 관리 시스템 서비스가 사용할 수 있도록 기계 판독 가능 형태로 제공된다. 508에서, 관리 시스템 서비스들 중 하나 이상이 목록 정보에 기초하여 구성된다. 510에서, cmdlets를 시스템에 등록하고, 스케쥴을 셋업하는 등의 관리 작업이 목록 내의 애플리케이션에 대해 정의된다. 이어서, 프로세스는 종료 블록에 이른다.

이제 도 6을 참조하면, 모델 기반 관리의 요구되는 상태를 구현하는 프로세스의 흐름도가 도시되어 있다. 600에서, 요구되는 상태가 목록으로부터 액세스된다. 602에서, 종속성이 검증되고, 필요한 파일, 설정 및 보안 기능만이 설치된다. 604에서, 이벤트가 가입되고, 목록에서 지정된 대로 전송된다. 606에서, 계기 데이터 및 카운터 데이터가 주기적으로 수집되는 것은 물론 테스트 및 종합 트랜잭션이 수행된다. 608에서, 자동 관리 작업이 수행된다. 610에서, 프로그램 기능들에 대한 액세스가 제한된다. 그러나, 이것은 본 발명에 따라 모델 기반 관리를 용이하게 하기 위해 포함될 필요가 없다. 612에서, 문제가 검출되고, 근본 문제가 진단되며, 교정 동작이 취해지고, 시스템 관리자가 언제 조정할 것인지를 통지받는다. 614에서, 위의 모두에 대한 정책이 많은 다른 타입의 기계들 및 시스템으로의 애플리케이션에 대해 개별화된다. 이어서, 프로세스는 종료 블록에 이른다.

이제 도 7을 참조하면, 개시된 아키텍쳐를 실행하도록 동작할 수 있는 컴퓨터의 블록도가 도시되어 있다. 본 발명의 다양한 양태에 대한 추가적인 컨텍스트를 제공하기 위하여, 도 7 및 아래의 설명은 본 발명의 다양한 양태가 구현될 수 있는 적당한 컴퓨팅 환경(700)의 간략하고 일반적인 설명을 제공한다. 본 발명은 위에서 하나 이상의 컴퓨터 상에서 실행될 수 있는 컴퓨터 실행 가능 명령들의 일반적인 컨텍스트에서 설명되었지만, 본 발명은 다른 프로그램 모듈들의 조합으로, 그리고/또는 하드웨어 및 소프트웨어의 조합으로 구현될 수도 있다는 것을 당업자들은 이해할 것이다. 일반적으로, 프로그램 모듈은 특정 작업을 수행하거나 특정 추상 데이터 타입을 구현하는 루틴, 프로그램, 컴포넌트, 데이터 구조 등을 포함한다. 더욱이, 본 발명의 방법은 단일 프로세서 또는 다중 프로세서 컴퓨터 시스템, 미니 컴퓨터, 메인프레임 컴퓨터는 물론 개인용 컴퓨터, 핸드헬드 컴퓨팅 장치, 마이크로프로세서 기반 또는 프로그래머블 소비자 전자 장치 등(이들 각각은 하나 이상의 관련 장치들과 동작 결합될 수 있다)을 포함하는 다른 컴퓨터 시스템 구성에서 실시될 수 있다는 것을 당업자들은 이해할 것이다. 설명된 본 발명의 양태들은 통신 네트워크를 통해 연결되는 원격 프로세싱 장치들에 의해 소정의 작업들이 수행되는 분산 컴퓨팅 환경에서도 실시될 수 있다. 분산 컴퓨팅 환경에서, 프로그램 모듈들은 로컬 및 원격 메모리 저장 장치들 양자에 배치될 수 있다.

다시 도 7을 참조하면, 컴퓨터(702)를 포함하는 본 발명의 다양한 양태를 구현하기 위한 예시적인 환경이 도시되어 있는데, 컴퓨터(702)는 프로세싱 유닛(704), 시스템 메모리(706) 및 시스템 버스(708)를 포함한다. 시스템 버스(708)는 시스템 메모리(706)를 포함하지만 이에 한하지는 않는 시스템 컴포넌트들을 프로세싱 유닛(704)에 결합시킨다. 프로세싱 유닛(704)은 상업적으로 입수할 수 있는 다양한 프로세서 중 어느 하나일 수 있다. 이중 마이크로프로세서 및 다른 다중 프로세서 아키텍쳐도 프로세싱 유닛(704)으로 사용될 수 있다.

시스템 버스(708)는 메모리 버스(메모리 제어기를 구비하거나 구비하지 않음), 주변 버스, 및 상업적으로 이용 가능한 다양한 버스 아키텍쳐 중 어느 하나를 이용하는 로컬 버스에도 상호접속될 수 있는 여러 타입의 버스 구조 중 어느 하나일 수 있다. 시스템 메모리(706)는 판독 전용 메모리(ROM; 710) 및 랜덤 액세스 메모리(RAM; 712)를 포함한다. 기본 입출력 시스템(BIOS)은 ROM, EPROM, EEPROM 등과 같은 불휘발성 메모리(710)에 저장되는데, BIOS는 예를 들어 시동시에 컴퓨터(702) 내의 요소들 사이에 정보를 전송하는 것을 돕는 기본 루틴들을 포함하고 있다. RAM(712)은 또한 데이터를 캐싱하기 위한 정적 RAM과 같은 고속 RAM을 포함할 수 있다.

컴퓨터(702)는 하드 디스크 드라이브(714), 자기 디스크 드라이브(716)(예를 들어 분리식 디스크(718)에 대한 판독 및 기입을 행함), 및 광 디스크 드라이브(720)(예를 들어 CD-ROM 디스크(722)를 판독하거나, 디지탈 비디오 디스크(DVD)와 같은 다른 대용량 광학 매체에 대한 판독 및 기입을 행함)를 더 포함한다. 하드 디스크 드라이브(714), 자기 디스크 드라이브(716) 및 광 디스크 드라이브(720)는 각각 하드 디스크 드라이브 인터페이스(724), 자기 디스크 드라이브 인터페이스(726) 및 광 디스크 드라이브 인터페이스(728)를 통해 시스템 버스(708)에 접속될 수 있다. 드라이브들 및 관련 컴퓨터 판독 가능 매체는 데이터, 데이터 구조, 컴퓨터 실행 가능 명령 등의 불휘발성 저장을 제공한다. 컴퓨터(702)에서, 드라이브들 및 매체들은 적당한 디지탈 포맷으로 방송 프로그래밍을 저장한다. 위에서 컴퓨터 판독 가능 매체의 설명이 하드 디스크, 분리식 자기 디스크 및 CD를 지칭하고 있지만, 컴퓨터에 의해 판독될 수 있는 다른 타입의 매체들, 예를 들면 짚 드라이브, 자기 카세트, 플래시 메모리 카드, 디지탈 비디오 디스크 등도 예시적인 운영 환경에서 사용될 수 있고, 또한 임의의 그러한 매체들이 본 발명의 방법을 수행하기 위한 컴퓨터 실행 가능 명령들을 포함할 수 있다는 것을 당업자들은 이해해야 한다.

운영 체제(730), 하나 이상의 애플리케이션 프로그램(732), 다른 프로그램 모듈(734) 및 프로그램 데이터(736)를 포함하는 다수의 프로그램 모듈이 드라이브 및 RAM(712)에 저장될 수 있다. 운영 체제, 애플리케이션, 모듈 및/또는 데이터의 모두 또는 일부가 RAM(712)에 캐시될 수도 있다.

본 발명은 상업적으로 이용 가능한 다양한 운영 체제 또는 운영 체제들의 조합으로 구현될 수 있다는 것을 이해해야 한다.

사용자는 키보드(738), 및 마우스(740)와 같은 포인팅 장치를 통해 명령 및 정보를 컴퓨터(702)에 입력할 수 있다. 다른 입력 장치(도시되지 않음)는 마이크로폰, IR 원격 제어 장치, 조이스틱, 게임 패드, 위성 안테나, 스캐너 등을 포함한다. 이들 및 다른 입력 장치들은 종종, 시스템 버스(708)에 결합되는 직렬 포트 인터페이스(742)를 통해 프로세싱 유닛(704)에 접속되지만, 병렬 포트, 게임 포트, 유니버셜 직렬 버스(USB), IR 인터페이스 등과 같은 다른 인터페이스에 의해 접속될 수 있다. 모니터(744) 또는 다른 타입의 표시 장치도 비디오 어댑터(746)와 같은 인터페이스를 통해 시스템 버스(708)에 접속된다. 모니터(744) 외에도, 컴퓨터(702)는 일반적으로 스피커, 프린터 등과 같은 다른 주변 출력 장치(도시되지 않음)를 포함한다.

컴퓨터(702)는 유선 및/또는 무선 통신을 통한 원격 컴퓨터(748)와 같은 하나 이상의 원격 컴퓨터로의 논리적 접속을 이용하여 네트워크 환경에서 동작할 수 있다. 원격 컴퓨터(748)는 워크스테이션, 서버 컴퓨터, 라우터, 개인용 컴퓨터, 포터블 컴퓨터, 마이크로프로세서 기반 오락 기기, 피어 장치 또는 다른 공통 네트워크 노드일 수 있으며, 간략화를 위해 메모리 저장 장치(750)만이 도시되어 있지만, 일반적으로 컴퓨터(702)에 관련하여 설명된 요소들의 대부분 또는 전부를 포함한다. 도시된 논리 접속은 근거리 통신 네트워크(LAN; 752) 및 원거리 통신 네트워크(WAN; 754)를 포함한다. 이러한 네트워킹 환경은 사무실, 기업 컴퓨터 네트워크, 인트라넷 및 인터넷에서 일반적이다.

LAN 네트워킹 환경에서 사용될 때, 컴퓨터(702)는 유선 또는 무선 통신 네트워크 인터페이스 또는 어댑터(756)를 통해 근거리 네트워크(752)에 접속된다. 어댑터(756)는 무선 어댑터(756)와의 통신을 위해 배치된 무선 액세스 포인트를 포함할 수도 있는 LAN(752)으로의 유선 또는 무선 통신을 용이하게 할 수 있다. WAN 네트워크 환경에서 사용될 때, 컴퓨터(702)는 일반적으로 모뎀(758)을 포함하거나, LAN 상에서 통신 서버에 접속되거나, 인터넷과 같이 WAN(754)을 통해 통신을 설정하는 다른 수단을 구비한다. 내부 또는 외부의 유선 또는 무선 장치일 수 있는 모뎀(758)은 직렬 포트 인터페이스(742)를 통해 시스템 버스(708)에 접속된다. 네트워크 환경에서, 컴퓨터(702)와 관련하여 도시된 프로그램 모듈들 또는 그 일부는 원격 메모리 저장 장치(750)에 저장될 수 있다. 도시된 네트워크 접속은 예시적인 것이며, 컴퓨터들 사이에 통신 링크를 설정하는 다른 수단이 사용될 수 있다는 것을 이해할 것이다.

컴퓨터(702)는 임의의 무선 장치 또는 무선 통신에 동작적으로 배치된 엔티티들, 예를 들어 프린터, 스캐너, 데스크탑 및/또는 포터블 컴퓨터, 포터블 데이터 어시스턴트, 무선 검출 가능 태그(예를 들어, 키오스크, 뉴스 스탠드, 레스트룸)와 연관된 임의의 장비 또는 위치, 및 전화기와 통신할 수 있다. 이것은 적어도 Wi-Fi 및 블루투스 무선 기술을 포함한다. 따라서, 통신은 통상적인 네트워크 또는 단순히 적어도 2개의 장치 사이의 임시 통신과 같은 소정의 구조일 수 있다.

Wi-Fi 또는 무선 피델리티는 유선 없이 가정에서, 호텔 객실의 침대에서, 또는 회사의 회의실에서 코치로부터 인터넷으로의 접속을 허용한다. Wi-Fi는 예를 들어 컴퓨터와 같은 장치들이 실내외에서, 기지국의 범위 내의 어느 장소에서나 데이터를 송수신할 수 있게 하는 셀 폰과 같은 무선 기술이다. Wi-Fi 네트워크는 IEEE 802.11(a, b, g 등)이라고 하는 무선 기술을 이용하여 안전하고 신뢰성 있고 빠른 무선 접속을 제공한다. Wi-Fi 네트워크는 컴퓨터들을 서로, 인터넷에, 유선 네트워크(IEEE 802.3 또는 이더넷 이용)에 접속시키는 데 사용될 수 있다. Wi-Fi 네트워크는 허가되지 않은 2.4 및 5 GHz 무선 대역에서 11 Mbps(802.11b) 또는 54 Mbps(802.11a) 데이터 속도로, 또는 양 대역(이중 대역)을 포함하는 제품과 함께 동작하며, 따라서 네트워크는 많은 사무실에서 사용되는 기본 10BaseT 유선 이더넷 네트워크와 유사한 실사회 성능을 제공할 수 있다.

이제, 도 8을 참조하면, 본 발명에 따른 예시적인 컴퓨팅 환경(800)의 개략적인 블록도가 도시되어 있다. 시스템(800)은 하나 이상의 클라이언트(802)를 포함한다. 클라이언트(802)는 하드웨어 및/또는 소프트웨어(예를 들어 스레드, 프로세스, 컴퓨팅 장치)일 수 있다. 클라이언트(802)는 예를 들어 본 발명을 이용함으로써 쿠키 및/또는 관련 컨텍스트 정보를 하우징할 수 있다. 시스템(800)은 또한 하나 이상의 서버(804)를 포함한다. 서버(804)는 또한 하드웨어 및/또는 소프트웨어(예를 들어 스레드, 프로세스, 컴퓨팅 장치)일 수 있다. 서버(804)는 예를 들어 본 발명을 이용함으로써 변환을 수행하기 위해 스레드를 하우징할 수 있다. 클라이언트(802)와 서버(804) 사이에 가능한 하나의 통신은 둘 이상의 컴퓨터 프로세스 사이에 전송되기에 적합한 데이터 패킷의 형태일 수 있다. 데이터 패킷은 예를 들어 쿠키 및/또는 관련 컨텍스트 정보를 포함할 수 있다. 시스템(800)은 클라이언트(802)와 서버(804) 사이의 통신을 용이하게 하는 데 이용될 수 있는 통신 프레임워크(806)(예를 들어 인터넷과 같은 글로벌 통신 네트워크)를 포함한다.

통신은 유선(광섬유 포함) 및/또는 무선 기술을 통해 용이해질 수 있다. 클라이언트(802)는 클라이언트(802)에 로컬한 정보(예를 들어 쿠키 및/또는 관련 컨텍스트 정보)를 저장하는 데 사용될 수 있는 하나 이상의 클라이언트 데이터 스토어(808)에 동작 결합된다. 마찬가지로, 서버(804)는 서버(804)에 로컬한 정보를 저장하는 데 사용되는 하나 이상의 서버 데이터 스토어(810)에 동작 결합된다.

전술한 바와 같이, 개시된 모델 기반 관리 아키텍쳐는 기업형 시스템 관리에 응용된다. 예를 들어, 클라이언트(802) 중 하나는 로컬 애플리케이션 또는 서비스뿐만 아니라 원격 노드, 예를 들어 서버(804)의 애플리케이션 또는 서비스를 관리할 수 있다. 모든 양태는 로컬 클라이언트의 단일 인스턴스에서 다수의 네트워크 노드의 원격 시스템 및 애플리케이션 전체의 다수의 인스턴스까지의 건강 모니터링을 지원하는 데 이용된다. 기계 기반 학습은 로컬 레벨에서 기업 레벨에 이르기까지 그리고 그 이상으로, 시스템 성능 및 능력을 자동화하고 향상시키기 위해 이용될 수 있다.

위의 설명은 본 발명의 예들을 포함한다. 물론, 본 발명을 설명하기 위해 생각할 수 있는 모든 컴포넌트들 또는 방법들의 조합을 설명하는 것은 가능하지 않지만, 본 발명의 많은 추가적인 조합 및 대체가 가능하다는 것을 당업자는 인식할 수 있을 것이다. 따라서, 본 발명은 첨부된 청구범위의 사상 및 범위에 들어가는 모든 그러한 변경, 수정 및 변화를 포함하는 것으로 의도된다. 더욱이, 상세한 설명 또는 청구범위에 사용되는 "포함한다"라는 용어는 청구범위에서 전이어로서 사용되는 "포함한다"라는 용어와 유사한 방식으로 포괄적인 것으로 의도된다.

Claims (40)

1. 애플리케이션 또는 서비스를 관리하기 위한 모델 기반 관리 시스템으로서,

   상기 모델 기반 관리 시스템은 컴퓨터에 의해 구현되고 컴퓨터 실행가능 컴포넌트들을 포함하며, 상기 컴퓨터 실행가능 컴포넌트들은,

   소스코드를 이용함으로써, 애플리케이션 또는 서비스에서, 기능, 구성, 시스템 자원 이용성(system resource utilization), 보안성 및 성능 중 하나 이상에 의해 원하는 상태들을 기술하는 하나 이상의 모델을 생성하는 기술 컴포넌트(description component); 및

   상기 애플리케이션 또는 서비스를 설치하는 동안 상기 기술 컴포넌트에 적어도 기초하여 자신을 구성하는 관리 서비스 컴포넌트

   를 포함하는, 모델 기반 관리 시스템.
2. 제1항에 있어서, 상기 관리 서비스 컴포넌트는 구성 관리 문제 검출, 진단 및 회복 중 하나 이상을 포함하는 관리 동작(management action)을 통해 상기 애플리케이션의 이용 가능성을 보장하는, 모델 기반 관리 시스템.
3. 제1항에 있어서, 상기 기술 컴포넌트는 컴포넌트 모델, 건강 모델, 구성 모델, 관리 작업 모델, 아키텍처 모델, 성능 모델 및 보안 모델 중 하나 이상를 포함하는 모델 컴포넌트를 포함하는, 모델 기반 관리 시스템.
4. 제1항에 있어서, 상기 기술 컴포넌트는 모델 및 속성을 포함하는 목록을 기계 판독 가능한 형태로 생성하는 목록 컴포넌트(manifest component)를 포함하는, 모델 기반 관리 시스템.
5. 제1항에 있어서, 상기 기술 컴포넌트는 애플리케이션, 서비스 또는 시스템과 인터페이싱하는 하나 이상의 애플리케이션 프로그램 인터페이스(APIs)를 포함하는 관리 시스템 컴포넌트를 포함하는, 모델 기반 관리 시스템.
6. 모델 기반 관리 시스템으로서, 상기 모델 기반 관리 시스템은 컴퓨터에 의해 구현되고 컴퓨터 실행가능 컴포넌트들을 포함하며, 상기 컴퓨터 실행가능 컴포넌트들은,

   애플리케이션 또는 서비스에서, 소스코드를 이용함으로써, 기능, 구성, 시스템 자원 이용성, 보안성 및 성능 중 하나 이상에 의해 원하는 상태들을 기술하는 하나 이상의 모델을 생성하는 기술 컴포넌트; 및

   상기 애플리케이션 또는 서비스를 설치하는 동안 상기 기술 컴포넌트에 적어도 기초하여 자신을 구성하는 관리 서비스 컴포넌트

   를 포함하고,

   상기 기술 컴포넌트는

   컴포넌트 모델, 건강 모델, 구성 모델, 관리 작업 모델, 아키텍쳐 모델, 성능 모델, 및 보안 모델 중 하나 이상을 더 포함하는 모델 컴포넌트,

   상기 모델 컴포넌트 중 하나 이상으로부터 생성되고, 상기 모델 컴포넌트 중 하나의 소스 코드의 속성 및 기술 컴포넌트 정보를 포함하는 목록 컴포넌트,

   상기 애플리케이션 또는 서비스와 인터페이스하는 하나 이상의 애플리케이션 프로그램 인터페이스(API)를 포함하는 관리 시스템 컴포넌트 및

   작업 컴포넌트

   중 하나 이상을 포함하는, 모델 기반 관리 시스템.
7. 제6항에 있어서, 상기 작업 컴포넌트는 상기 모델 기반 관리 시스템의 성능에 대해 모니터링 작업들, 고장 수리 작업들 및 관리 작업들 중 하나 이상을 더 정의하는, 모델 기반 관리 시스템.
8. 애플리케이션을 관리하기 위한 모델 기반 관리 방법으로서, 상기 방법은 컴퓨터에 저장된 컴퓨터 실행가능 명령어가 컴퓨터에 의해 실행되는 경우 수행되며,

   소스 코드를 사용하여 애플리케이션의 컴포넌트에 대응하는 하나 이상의 모델을 개발하는 단계;

   상기 소스 코드의 속성을 수행하여 어떤 모델 또는 그의 일부가 모니터링되는지를 표시하는 단계;

   기계 판독 가능 형태로 상기 모델 및 상기 속성과 관련된 정보를 포함하는 목록 정보의 목록을 생성하는 단계;

   상기 목록 정보에 기초하여 복수의 상기 관리 시스템 서비스를 구성하는 단계; 및

   상기 목록에 원하는 상태들 및 교정 동작을 표시하는 단계

   를 포함하는, 모델 기반 관리 방법.
9. 제8항에 있어서,

   상기 목록에 원하는 상태들 및 교정 동작을 표시하는 단계 이후에, 애플리케이션 종속성을 검증하고, 상기 원하는 상태들 중 하나 이상에 기초하여 필요한 파일, 설정 및 보안 중 하나 이상만을 설치하는 단계를 더 포함하는, 모델 기반 관리 방법.
10. 제8항에 있어서,

    상기 목록에 원하는 상태들 및 교정 동작을 표시하는 단계 이후에, 이벤트에 가입하고, 상기 원하는 상태들 중 하나 이상에 기초하여 소정의 이벤트 사양에 따라 상기 이벤트를 전송하는 단계를 더 포함하는, 모델 기반 관리 방법.
11. 제8항에 있어서,

    상기 목록에 원하는 상태들 및 교정 동작을 표시하는 단계 이후에, 상기 원하는 상태들 중 하나 이상에 기초하여 계기 정보, 카운터 정보 및 테스트를 주기적으로 수집함으로써 계기를 폴링(polling)하는 단계를 더 포함하는, 모델 기반 관리 방법.
12. 제8항에 있어서,

    상기 목록에 원하는 상태들 및 교정 동작을 표시하는 단계 이후에, 서비스의 하나 이상의 건강 상태를 결정하는 단계, 상기 애플리케이션의 계기를 공표하는 단계, 상기 공표된 계기를 분석하는 단계, 및 상기 공표된 계기에 기초하여 상기 서비스의 건강 모델을 개발하는 단계 - 상기 건강 모델은 컴포넌트 간의 관계 정보를 포함함 - 를 더 포함하는, 모델 기반 관리 방법.
13. 애플리케이션 또는 서비스를 관리하기 위한, 컴퓨터에 의해 구현되는 모델 기반 관리 시스템으로서,

    소스코드를 이용함으로써, 애플리케이션 또는 서비스에서, 기능, 구성, 보안성 및 성능 중 하나 이상에 의해 원하는 상태들을 기술하는 하나 이상의 모델을 생성하기 위한 수단;

    상기 애플리케이션의 건강의 판정을 용이하게 하기 위해 상기 애플리케이션의 소스 코드와 함께 관리 정보를 표시하기 위한 수단;

    URI(Uniform Resource Identifier)를 이용하여 추상 또는 물리적 자원을 식별하기 위한 수단; 및

    관리 서비스 컴포넌트를 구성하기 위하여 상기 애플리케이션을 설치하는 동안 기술 컴포넌트들에 부분적으로 기초하여 관리 서비스 컴포넌트를 구성하기 위한 수단

    을 포함하는, 모델 기반 관리 시스템.
14. 애플리케이션 또는 서비스를 관리하는 방법을 실행시키기 위한 컴퓨터 실행가능 명령어들을 기록한 컴퓨터 판독가능 기록매체로서, 상기 방법은 컴퓨터에 저장된 컴퓨터 실행가능 명령어가 컴퓨터에 의해 실행되는 경우 수행되며,

    상기 방법은,

    소스 코드를 사용하여 애플리케이션의 컴포넌트에 대응하는 하나 이상의 모델을 개발하는 단계;

    상기 소스 코드의 속성을 수행하여 어떤 모델 또는 그의 일부가 모니터링되는지를 표시하는 단계;

    기계 판독 가능 형태로 상기 모델 및 상기 속성과 관련된 정보를 포함하는 목록 정보의 목록을 생성하는 단계;

    상기 목록 정보에 기초하여 복수의 상기 관리 시스템 서비스를 구성하는 단계; 및

    상기 목록에 원하는 상태들 및 교정 동작을 표시하는 단계

    를 포함하는, 컴퓨터 판독가능 기록 매체.
15. 애플리케이션 또는 서비스를 관리하는 모델 기반 관리 시스템을 구현하는 컴퓨터 실행가능 명령어들을 기록한 컴퓨터 판독가능 기록매체로서,

    상기 모델 기반 관리 시스템은,

    소스코드를 이용함으로써, 애플리케이션 또는 서비스에서, 기능, 구성, 시스템 자원 이용성, 보안성 및 성능 중 하나 이상에 의해 원하는 상태들을 기술하는 적어도 하나의 모델을 생성하는 기술 컴포넌트; 및

    상기 애플리케이션 또는 서비스를 설치하는 동안 상기 기술 컴포넌트를 이용하여 자신을 구성하는 관리 서비스 컴포넌트

    를 포함하는, 컴퓨터 판독가능 기록매체.
16. 삭제
17. 삭제
18. 삭제
19. 삭제
20. 삭제
21. 삭제
22. 삭제
23. 삭제
24. 삭제
25. 삭제
26. 삭제
27. 삭제
28. 삭제
29. 삭제
30. 삭제
31. 삭제
32. 삭제
33. 삭제
34. 삭제
35. 삭제
36. 삭제
37. 삭제
38. 삭제
39. 삭제
40. 삭제

Images