KR20140056371A - 하드웨어 소모 아키텍처 - Google Patents

하드웨어 소모 아키텍처 Download PDF

Info

Publication number
KR20140056371A
KR20140056371A KR1020147008287A KR20147008287A KR20140056371A KR 20140056371 A KR20140056371 A KR 20140056371A KR 1020147008287 A KR1020147008287 A KR 1020147008287A KR 20147008287 A KR20147008287 A KR 20147008287A KR 20140056371 A KR20140056371 A KR 20140056371A
Authority
KR
South Korea
Prior art keywords
hardware
component
module
components
agent
Prior art date
Application number
KR1020147008287A
Other languages
English (en)
Inventor
에릭 제이 바우어
랜디 에스 아담스
윌리엄 디 린츠
마크 엠 클로우어티
Original Assignee
알까뗄 루슨트
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 알까뗄 루슨트 filed Critical 알까뗄 루슨트
Publication of KR20140056371A publication Critical patent/KR20140056371A/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2041—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant with more than one idle spare processing component
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/008—Reliability or availability analysis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2035—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant without idle spare hardware
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3051—Monitoring arrangements for monitoring the configuration of the computing system or of the computing system component, e.g. monitoring the presence of processing resources, peripherals, I/O links, software programs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1479—Generic software techniques for error detection or fault masking
    • G06F11/1482—Generic software techniques for error detection or fault masking by means of middleware or OS functionality
    • G06F11/1484—Generic software techniques for error detection or fault masking by means of middleware or OS functionality involving virtual machines
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/1666—Error detection or correction of the data by redundancy in hardware where the redundant component is memory or memory area

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Debugging And Monitoring (AREA)
  • Hardware Redundancy (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

다양한 예시적 실시예들은 복수의 하드웨어 컴포넌트들 중의 고장난 컴포넌트의 하드웨어 고장을 식별하는 단계와, 현재 고장난 컴포넌트를 사용하도록 구성된 에이전트 디바이스들의 세트를 결정하는 단계와, 복수의 하드웨어 컴포넌트들 중의 작동 컴포넌트를 사용하도록 에이전트 디바이스를 재구성하는 단계 중의 하나 이상을 포함하는 방법 및 관련 네트워크 노드에 관한 것이다. 다양한 예시적 실시예들은 하드웨어 모듈에 대한 고장 날짜를 예측하는 단계와, 하드웨어 모듈에 대한 목표 교체 날짜에 기초하여 상기 예측된 고장 날짜가 허용 가능한지의 여부를 결정하는 단계와, 상기 예측된 고장 날짜가 허용 가능하지 않은 경우 하드웨어 컴포넌트에 대한 파라미터 조정을 선택하되, 상기 파라미터 조정은 상기 예측된 고장 날짜가 상기 목표 교체 날짜에 더 근접하게 이동시키도록 선택하고, 상기 파라미터 조정을 상기 하드웨어 컴포넌트에 적용하는 단계 중의 하나 이상을 대안적 또는 추가적으로 포함하는 방법 및 관련 네트워크 노드에 관한 것이다.

Description

하드웨어 소모 아키텍처{HARDWARE CONSUMPTION ARCHITECTURE}
관련 출원에 대한 교차-참조
본 출원은 Bauer 등에 의한 발명의 명칭이 "LIVE MODULE DIAGNOSTIC TESTING"이고 출원 일련 번호가 13/250,333(Attorney Docket Number ALC 3748)인 계류중의 출원을 교차 참조하며, 그것의 전체 내용은 참조에 의해 본 명세서에 통합된다.
기술분야
여기에 개시된 각종 예시적 실시예들은 일반적으로 시스템 신뢰성 및 가용성에 관한 것이다.
가상화 및 클라우드 컴퓨팅과 같은 기술의 발전은 종래에 전용 및 독립 하드웨어와 연관된 다양한 애플리케이션을 공유 하드웨어 리소스를 제공하는 머신상으로 이동하도록 촉진했다. 이러한 소위 "서버 통합(server consolidation)"은 사용 가능한 리소스의 더욱 완전한 활용을 가능하게 하며, 이에 따라 활용도가 낮은 리소스와 관련된 비용을 감소시켰다. 예를 들어, 에너지 소비, 플로어 공간(floor space), 및 기타 서버 비용은 이전에 적은 비중으로 이용되었던 서버들을 퇴역시킴으로써 감소될 수 있다.
서버 통합은 그러나, 여러 가지 원치 않는 결과들로 이어질 수 있다. 하드웨어 리소스의 활용도 증가는 하드웨어의 고장율을 증가시킬 수 있다. 이러한 고장은 하드웨어를 활용하는 애플리케이션에 영향을 줄 수 있다. 또한, 현재의 아키텍처 하에서, 블레이드(blade) 또는 랙 마운트 서버(rack mount server)와 같은 FRU(field replaceable unit)의 하드웨어 컴포넌트가 고장나면, 서버의 대부분의 하드웨어 컴포넌트가 계속 작동가능하더라도, 그 유닛은 교체 또는 수리되어야 하고, 애플리케이션 실행을 위해 사용가능한 리소스들의 풀(pool)로부터 자신과 관련된 리소스들을 제거하게 한다.
다양한 예시적 실시예들의 개요가 이하 제공된다. 다음의 개요에서는 일부 단순화 및 생략이 이루어질 수 있으며, 이것은 각종 예시적 실시예들의 몇몇 양태들을 강조하고 소개하는 것을 의도하며, 본 발명의 범위를 제한하는 것을 의도하지 않는다. 당업자가 본 발명의 개념을 제조하고 사용할 수 있도록 하기에 적절한 바람직한 예시적 실시예의 상세한 설명들이 아래의 섹션들에서 이어질 것이다.
다양한 예시적 실시예들은 하드웨어 시스템의 점진적 고장을 가능하게 하기 위하여 하드웨어 관리 디바이스에 의해 수행되는 방법에 관한 것이며, 상기 하드웨어 시스템은 복수의 하드웨어 컴포넌트들을 포함하고, 상기 방법은 상기 복수의 하드웨어 컴포넌트들 중의 고장난 컴포넌트의 하드웨어 고장을 식별하는 단계와, 현재 상기 고장난 컴포넌트를 사용하도록 구성된 에이전트 디바이스들의 세트를 결정하는 단계와, 상기 에이전트 디바이스들의 세트 중의 적어도 하나의 에이전트 디바이스에 대해, 상기 고장난 컴포넌트를 대신하여 상기 복수의 하드웨어 컴포넌트들 중의 작동 컴포넌트를 사용하도록 상기 에이전트 디바이스를 재구성하는 단계와, 상기 고장난 컴포넌트를 비활성화하는 단계－상기 복수의 하드웨어 컴포넌트들 중의 다른 하드웨어 컴포넌트들은 계속해서 작동함－중의 하나 이상을 포함한다.
다양한 예시적 실시예들은 점진적 하드웨어 고장이 가능한 하드웨어 시스템에 관한 것이며, 상기 하드웨어 시스템은 회로 기판과, 상기 회로 기판에 장착된 복수의 하드웨어 컴포넌트들과, 런 타임(run time) 동안, 상기 복수의 하드웨어 컴포넌트들 중의 적어도 하나의 하드웨어 컴포넌트를 비활성화시키는 한편 상기 복수의 하드웨어 컴포넌트들 중의 적어도 하나의 나머지 컴포넌트는 계속 작동하게 하는 관리 디바이스를 포함한다.
다양한 예시적 실시예들은 하드웨어 시스템의 점진적 고장을 가능하게 하기 위하여 하드웨어 관리 디바이스에 의해 실행되는 명령들로 인코딩된 유형의 비-일시적 머신 판독가능 스토리지 매체에 관한 것이며, 상기 하드웨어 시스템은 복수의 하드웨어 컴포넌트들을 포함하고, 상기 유형의 비-일시적 머신 판독가능 스토리지 매체는 상기 복수의 하드웨어 컴포넌트들 중의 고장난 컴포넌트의 하드웨어 고장을 식별하는 명령들과, 현재 상기 고장난 컴포넌트를 사용하도록 구성된 에이전트 디바이스들의 세트를 결정하는 명령들과, 상기 에이전트 디바이스들의 세트 중의 적어도 하나의 에이전트 디바이스에 대해, 상기 고장난 컴포넌트를 대신하여 상기 복수의 하드웨어 컴포넌트들 중의 작동중인 컴포넌트를 사용하도록 상기 에이전트 디바이스를 재구성하는 명령들과, 상기 고장난 컴포넌트를 비활성화하는 명령들－상기 복수의 하드웨어 컴포넌트들 중의 다른 하드웨어 컴포넌트들은 계속해서 작동함－ 중의 하나 이상을 포함한다.
다양한 예시적 실시예들은 상기 복수의 하드웨어 컴포넌트들 중의 적어도 하나의 다른 하드웨어 컴포넌트들에 지속적으로 전력을 제공하면서, 상기 고장난 컴포넌트의 전원을 차단하도록 상기 하드웨어 모듈을 재구성하는 것을 포함한다.
다양한 예시적 실시예들이 기술되어 있으며, 여기서 상기 하드웨어 시스템은 상기 복수의 하드웨어 컴포넌트들이 장착된 회로 기판을 포함하는 하드웨어 모듈이다.
다양한 예시적 실시예들이 기술되어 있으며, 여기서 상기 회로 기판에 장착된 모든 하드웨어 컴포넌트들은 단일 타입의 하드웨어 컴포넌트이다.
다양한 예시적 실시예들이 기술되어 있으며, 여기서 상기 하드웨어 관리 디바이스는 하이퍼바이저를 포함하고, 상기 하드웨어 관리 디바이스는 작동을 위하여 상기 복수의 하드웨어 컴포넌트들 중의 적어도 하나의 컴포넌트를 사용한다.
다양한 예시적 실시예들이 기술되어 있으며, 여기서 상기 하드웨어 관리 디바이스는 클라우드 컴퓨팅 게이트웨이 디바이스를 포함하며, 상기 클라우드 관리 디바이스는 복수의 하이퍼바이저들을 관리하고, 상기 복수의 하이퍼바이저들 중의 제 1 하이퍼바이저는 상기 복수의 하드웨어 컴포넌트들을 관리한다.
다양한 예시적 실시예들은 상기 에이전트 디바이스들의 세트 중의 적어도 하나의 에이전트 디바이스에 있어서, 상기 복수의 하이퍼바이저들 중의 제 2 하이퍼바이저에 의해 관리되도록 상기 에이전트 디바이스를 재구성하는 것을 더 포함한다.
다양한 예시적 실시예들은 하드웨어 모듈의 소모를 제어하기 위하여 하드웨어 관리 디바이스에 의해 수행되는 방법에 관한 것이며, 상기 하드웨어 모듈은 복수의 하드웨어 컴포넌트들을 포함하고, 상기 방법은 상기 하드웨어 모듈에 대한 고장 날짜를 예측하는 단계와, 상기 하드웨어 모듈에 대한 목표 교체 날짜에 기초하여 상기 예측된 고장 날짜가 허용 가능한지의 여부를 결정하는 단계와, 상기 예측된 고장 날짜가 허용 가능하지 않은 경우, 상기 복수의 하드웨어 컴포넌트들 중의 적어도 하나의 하드웨어 컴포넌트에 대한 적어도 하나의 파라미터 조정을 결정하는 단계－상기 적어도 하나의 파라미터 조정은 상기 예측된 고장 날짜를 상기 목표 교체 날짜에 더 근접하게 이동시키도록 선택됨－와, 상기 복수의 하드웨어 컴포넌트들 중의 상기 적어도 하나의 하드웨어 컴포넌트에 대해 상기 적어도 하나의 파라미터 조정을 적용하는 단계 중의 하나 이상을 포함한다.
다양한 예시적 실시예들은 하드웨어 모듈의 소모를 제어하는 하드웨어 관리 디바이스에 관한 것이며, 상기 하드웨어 모듈은 복수의 하드웨어 컴포넌트들을 포함하고, 상기 하드웨어 관리 디바이스는 상기 하드웨어 모듈에 대한 고장 날짜를 예측하고 상기 하드웨어 모듈에 대한 목표 교체 날짜에 기초하여 상기 예측된 고장 날짜가 허용 가능한지의 여부를 결정하도록 구성된 소모 정책 엔진과, 상기 예측된 고장 날짜가 허용 가능하지 않은 경우, 상기 복수의 하드웨어 컴포넌트들 중의 적어도 하나의 하드웨어 컴포넌트에 대한 적어도 하나의 파라미터 조정을 결정하되, 상기 적어도 하나의 파라미터 조정은 상기 예측된 고장 날짜가 상기 목표 교체 날짜에 더 근접하게 이동되도록 선택되고 상기 적어도 하나의 파라미터 조정을 상기 복수의 하드웨어 컴포넌트들 중의 상기 적어도 하나의 하드웨어 컴포넌트에 적용하도록 구성된 파라미터 조정기 중의 하나 이상을 포함한다.
다양한 예시적 실시예들은 하드웨어 모듈의 소모를 제어하기 위하여 하드웨어 관리 디바이스에 의해 실행되는 명령들로 인코딩된 유형의 비-일시적 머신 판독가능 스토리지 매체에 관한 것이며, 상기 하드웨어 모듈은 복수의 하드웨어 컴포넌트들을 포함하고, 상기 유형의 비-일시적 머신 판독가능 스토리지 매체는 상기 하드웨어 모듈에 대한 고장 날짜를 예측하는 명령들과, 상기 하드웨어 모듈에 대한 목표 교체 날짜에 기초하여 상기 예측된 고장 날짜가 허용 가능한지의 여부를 결정하는 명령들과, 상기 예측된 고장 날짜가 허용 가능하지 않은 경우, 상기 복수의 하드웨어 컴포넌트들 중의 적어도 하나의 하드웨어 컴포넌트에 대한 적어도 하나의 파라미터 조정을 결정하되, 상기 적어도 하나의 파라미터 조정은 상기 예측된 고장 날짜가 상기 목표 교체 날짜에 더 근접하게 이동되도록 선택되고 상기 적어도 하나의 파라미터 조정을 상기 복수의 하드웨어 컴포넌트들 중의 상기 적어도 하나의 하드웨어 컴포넌트에 적용하는 명령들 중 하나 이상을 포함한다.
다양한 예시적 실시예들이 기술되어 있으며, 여기서 상기 적어도 하나의 파라미터 조정은 상기 하드웨어 모듈이 상기 예측된 고장 날짜보다 더 일찍 고장나게 되도록 선택된다.
다양한 예시적 실시예들은 상기 복수의 하드웨어 컴포넌트들의 각각에 대한 고장율에 기초하여 상기 모듈에 대한 현재의 수명 단계(life phase)를 추정하는 것을 더 포함하며, 상기 하드웨어 모듈에 대한 고장 날짜를 예측하는 단계는 상기 모듈의 현재의 수명 단계에 기초하여 수행된다.
다양한 예시적 실시예들이 기술되어 있으며, 여기서 상기 하드웨어 관리 디바이스는 복수의 하드웨어 모듈들을 관리하고 각각의 하드웨어 모듈은 현재의 수명 단계와 관련되며, 에이전트 디바이스의 설정(establishment)에 대한 요청을 수신하는 단계와, 상기 요청과 관련된 수명 단계 허가를 결정하는 단계－상기 수명 단계 허가는 허가된 수명 단계를 가진 모듈이 상기 요청을 이행하도록 사용되어야 한다는 것을 나타냄－와, 상기 복수의 하드웨어 모듈 중에서 하드웨어 모듈을 선택하는 단계－상기 선택된 하드웨어 모듈은 상기 허가된 수명 단계와 관련됨－와, 상기 선택된 하드웨어 모듈을 사용하여 상기 요청을 이행하는 단계를 더 포함한다.
다양한 예시적 실시예들이 기술되어 있으며, 여기서 상기 하드웨어 모듈에 대한 고장 날짜를 예측하는 단계는 고장 상태가 충족되는 날짜를 예측하는 것을 포함하고, 상기 고장 상태는 구성된 개수 미만의 하드웨어 컴포넌트들이 계속해서 작동하는 경우에 충족된다.
다양한 예시적 실시예들은 상기 복수의 하드웨어 컴포넌트들 중의 적어도 하나의 고장율을 결정하는 단계를 더 포함하고, 상기 하드웨어 모듈에 대한 고장 날짜를 예측하는 단계는 상기 복수의 하드웨어 컴포넌트들 중의 적어도 하나의 고장율에 기초하여 수행된다.
다양한 예시적 실시예들이 기술되어 있으며, 상기 적어도 하나의 파라미터 조정은 쿨링 레이트(cooling rate), 전압, 클럭 빈도, 및 활성화 스케줄 중의 적어도 하나에 대한 조정을 포함한다.
각종 예시적 실시예들의 더욱 용이한 이해를 위하여, 다음의 첨부 도면들에 대한 참조가 이루어진다.
도 1a는 공유형 하드웨어 리소스들을 제공하는 예시적 시스템을 도시한다.
도 1b는 도 1a의 일부 컴포넌트들에 대한 다른 배열을 도시한다.
도 1c는 도 1a의 일부 컴포넌트들에 대한 또 다른 배열을 도시한다.
도 2는 소모성 하드웨어 리소스들을 제공하는 예시적 하드웨어 시스템을 도시한다.
도 3은 고장난 하드웨어 컴포넌트를 처리하기 위한 예시적 방법을 도시한다.
도 4는 시간에 따른 하드웨어 모듈의 고장율의 예시적 그래프를 도시한다.
도 5는 하드웨어 상태 정보를 저장한 예시적 데이터 배열을 도시한다.
도 6은 하드웨어 리소스들의 소모를 제어하는 예시적 방법을 도시한다.
도 7은 하드웨어 파라미터들을 조정하기 위한 예시적 방법을 도시한다.
이해를 용이하게 하기 위해, 동일한 참조 부호는 실질적으로 동일하거나 유사한 구조 및/또는 실질적으로 동일 또는 유사한 기능을 갖는 요소를 지정하도록 사용되었다.
전술의 관점에서, 사용가능한 전체 리소스들에 대한 고장난 하드웨어 리소스의 영향을 제한하는 하드웨어 아키텍처를 제공하는 것이 바람직하다. 특히, 이러한 아키텍처는 다른 모든 컴포넌트들이 완전하게 작동하는 상태를 유지하면서, 고장난 컴포넌트들을 비활성화시키는 것이 바람직하다. 이제 도면들을 참조하면, 각종 예시적 실시예들의 다양한 양태들이 개시되어 있다.
도 1a는 공유형 하드웨어 리소스들을 제공하는 예시적 시스템(100a)을 도시한다. 이러한 하드웨어 리소스들은 예를 들어, 클라이언트 유저들을 서비스하는 몇몇 네트워킹된 애플리케이션을 지원하도록 공유될 수 있다. 예시적 시스템은 복수의 클라이언트 디바이스들(110a-c), 네트워크(120), 클라우드 컴퓨팅 게이트웨이(130), 리소스 할당 디바이스들(140a-b), 및 복수의 에이전트 디바이스들(150a-d)을 포함할 수 있다. 리소스 할당 디바이스들(140a-b) 및 에이전트 디바이스들(150a-d)은 하나 이상의 클라우드 컴퓨팅 인프라스트럭처 사이에 상주할 수 있다.
클라이언트 디바이스들(110a-c) 각각은 네트워크(120)와 같은 네트워크와 통신가능한 임의의 디바이스를 포함할 수 있다. 여기서는 3개의 디바이스들이 도시되어 있지만, 예시적 시스템(100a)은 그 보다 적거나 많은 디바이스들을 포함할 수도 있다. 또한, 예시적 시스템(100a)에 참여하는 클라이언트 디바이스들의 개수는 작동 중에 변동될 수도 있다. 예를 들어, 클라이언트 디바이스(110a)가 예시적 시스템(100a)에 참여하는 것을 중단하고/하거나 다른 2개의 클라이언트 디바이스들(미도시)가 유사한 참여를 시작할 수 있다.
각각의 클라이언트 디바이스(110a-c)는 퍼스널 또는 랩탑 컴퓨터, 단말기, 서버, 태블릿, 무선 이메일 디바이스, 셀 폰, 스마트 폰, 텔레비전 셋탑 박스, 또는 네트워크(120)를 통해 다른 디바이스들과 통신 가능한 임의의 다른 디바이스일 수 있다. 각각의 클라이언트 디바이스(110a-c)는 각각 다른 이유들로 예시적 시스템(100a)에 참여할 수 있다. 예를 들어, 클라이언트 디바이스(110a)는 씬 클라이언트(thin client)일 수 있으며, 예시적 시스템(100a) 내의 다른 리소스들에 의존하여 클라이언트 디바이스(110a)의 정규 작동과 관련된 대부분의 또는 모든 처리를 수행할 수 있다. 다른 예로서, 클라이언트 디바이스(110b)는 대부분의 작업을 독립적으로 수행가능한 퍼스널 컴퓨터일 수 있으며, 예시적 시스템(100a) 내의 다른 리소스들에 의존하여 예를 들어 큰 음악이나 전자책 수집과 같은 데이터를 저장 및 검색할 수도 있다. 또 다른 예로서, 클라이언트 디바이스(110c)는 다른 디바이스들(미도시)로부터의 요청들을 수신 및 응답하는 서버일 수도 있다. 클라이언트 디바이스(110c)는 예시적 시스템(100a) 내의 다른 리소스들에 의존하여 상기 요청들 중의 일부를 처리함으로써, 상기 요청이 도달하는 비율이 클라이언트 디바이스(110c)에게 너무 과대한 경우에는 몇몇 측정된 효율성, 응답 시간, 또는 서버의 부하를 계측하는 다른 메트릭 내에서 처리하도록 할 수 있다.
네트워크(120)는 예시적 시스템(100a)의 다른 디바이스들 간의 통신을 제공하도록 구성된 디바이스 또는 디바이스들의 그룹일 수 있다. 따라서, 네트워크(120)는 패킷들을 적절한 목적지들로 전달하는 다수의 라우터들 및/또는 스위치들을 포함할 수도 있다. 각종 실시예들에서, 네트워크(120)는 하나 이상의 2G, 3G, 및/또는 4G 시스템들 및/또는 다른 무선 시스템들을 포함할 수 있다. 또한, 각종 실시예들에서, 네트워크(120)는 인터넷 및/또는 하나 이상의 로컬 에어리어 네트워크(LAN)들과 같은 유선 네트워크들을 포함할 수도 있다.
클라우드 컴퓨팅 게이트웨이(130)는 하드웨어 리소스들을 관리하도록 구성된 디바이스 또는 디바이스들의 그룹일 수 있다. 즉, 클라우드 컴퓨팅 게이트웨이는 에이전트 디바이스들(150a-d)과 같은 에이전트 디바이스들의 설정에 영향을 미치고, 클라이언트 디바이스들(110a-c)과 에이전트 디바이스들(150a-d) 간의 메시지들을 라우팅하고, 하드웨어 사용에 대해 유저에게 청구하고, 하드웨어 리소스들의 상태를 모니터링하고, 및/또는 하드웨어 리소스들의 소모를 제어할 수 있다. 이하에서는 도 2를 참조하여 클라우드 컴퓨팅 게이트웨이의 상세 동작을 보다 구체적으로 기술하도록 한다.
이하에서 더욱 상세히 기술되는 바와 같이, 클라우드 컴퓨팅 게이트웨이(130)에 의해 관리되는 하드웨어 리소스들은 다수의 하드웨어 모듈들을 포함할 수 있다. 각각의 하드웨어 모듈은 다수의 하드웨어 컴포넌트들을 포함하는 회로 기판일 수 있다. 그러므로, 하드웨어 컴포넌트들은 클라우드 컴퓨팅 게이트웨이(130)에 의해 관리되는 하드웨어 리소스들을 제공한다. 예를 들어, 일 하드웨어 모듈은 32개의 프로세서들이 장착된 회로 기판일 수 있다. 클라우드 컴퓨팅 게이트웨이(130)는, 적어도 부분적으로, 이 32개의 프로세서들의 처리 능력의 사용 및 소모를 관리하도록 작동할 수 있다. 하드웨어 모듈들의 다른 예들은 도 2를 참조하여 기술될 것이다. 도시된 예시적 시스템(100a)은 2개의 하드웨어 모듈들(160a, 170a)을 포함할 수 있다. 2개의 하드웨어 모듈들(160a, 170a)이 도시되어 있지만, 예시적 시스템(100a)은 그보다 적거나 많은 하드웨어 모듈들(미도시)을 포함할 수 있다는 것에 유의한다.
리소스 할당 디바이스들(140a-b) 각각은 하드웨어 모듈들(160a, 170a)과 같은 하드웨어 모듈의 하드웨어 리소스들을 사용하는 디바이스일 수 있다. 또한, 리소스 할당 디바이스들(140a-b)은 에이전트 디바이스들(150a-d)을 관리할 수도 있다. 예를 들어, 리소스 할당 디바이스(140a)가 에이전트 디바이스들(150a-b)을 관리할 수 있고, 리소스 할당 디바이스(140b)는 에이전트 디바이스들(150c-d)을 관리할 수 있다. 에이전트 디바이스들(150a-d)을 관리함에 있어서, 리소스 할당 디바이스들(140a-b)은 각 에이전트 디바이스(140a-d)에 대하여 하드웨어 모듈들(160a, 170a)의 공유형 하드웨어 리소스들을 할당 및/또는 실행시킬 수 있다. 예를 들어, 리소스 할당 디바이스(140a)는 에이전트 디바이스 1(150a)이 제 1 CPU의 처리 시간의 20%를 사용하고, 에이전트 디바이스 M(150b)은 동일 CPU의 처리 시간의 10%를 사용하는 것을 보장할 수 있다. 이에 따라, 각종 실시예들에서, 리소스 할당 디바이스들(140a-b) 각각은 하이퍼바이저(hypervisor)를 포함할 수 있다. 리소스 할당 디바이스들(140a-b)은 예를 들어 요청 및 응답 메시지 라우팅, 리소스 예약, 로드 밸런싱(load balancing), 사용량 측정, 및/또는 비용청구와 같은 다수의 추가 기능들을 수행할 수도 있다. 예시적 시스템(100a)이 2개의 리소스 할당 디바이스들(140a-b)을 포함하고 있지만, 각종 실시예들은 그보다 적거나 많은 리소스 할당 디바이스들(미도시)을 포함할 수도 있다는 것에 유의한다.
에이전트 디바이스들(150a-d) 각각은 클라이언트 디바이스들(110a-c) 중의 하나 이상과 함께 작동하도록 구성된 디바이스일 수 있다. 각 에이전트 디바이스(150a-d)는 하나 이상의 프로세서들, 메모리, 스토리지, 및/또는 네트워크 인터페이스들과 같은 하드웨어 리소스들을 포함할 수 있다. 각종 실시예들에서, 에이전트 디바이스들(150a-d)은 이러한 하드웨어 리소스들을 다른 에이전트 디바이스들(150a-d) 및/또는 리소스 할당 디바이스들(140a-b)과 공유할 수 있다. 예를 들어, 에이전트 디바이스 1(150a)는 리소스 할당 디바이스(140a) 및 에이전트 디바이스 M(150b)와 CPU를 공유할 수 있다. 이러한 하드웨어 리소스들은 하드웨어 모듈들(160a, 170a)과 같은 하나 이상의 물리적 하드웨어 모듈들 사이에 배치될 수 있다. 각종 실시예들에서, 에이전트 디바이스들(150a-d) 중의 하나 이상은 가상 머신을 포함할 수 있다.
몇몇 실시예들에 따르면, 리소스 할당 디바이스들(140a-b)은 그들이 관리하는 에이전트 디바이스들(150a-d)과 동일한 물리적 하드웨어 모듈들에서 함께 상주할 수 있다. 예를 들어, 리소스 할당 디바이스(140a) 및 에이전트 디바이스들(150a-b)는 단일의 물리적 하드웨어 모듈(160a)에서 함께 상주할 수 있다. 이러한 실시예들에서, 리소스 할당 디바이스(140a)가 하이퍼바이저를 포함할 수 있고, 에이전트 디바이스들(150a-b) 각각은 가상 디바이스를 포함할 수 있으며, 이들 모두는 동일한 하드웨어 모듈의 각종 하드웨어 컴포넌트들을 사용하여 실행될 수 있다. 마찬가지로, 리소스 할당 디바이스(140b) 및 에이전트 디바이스들(150c-d)은 다른 물리적 하드웨어 모듈(170a)에 함께 상주할 수 있다. 그러나, 여기에 기술된 방법들은 각종 다른 구성들에 대해서도 적용될 수 있다는 것이 명백하다. 예를 들어, 도 1b에 도시된 다른 구성(100b)은 리소스 할당 디바이스(140a)가 제 1 하드웨어 모듈(160b)에 상주할 수 있고, 에이전트 디바이스들(150a-b) 모두는 제 2 하드웨어 모듈(162b)에 상주할 수 있다는 것을 나타낸다. 다른 대안으로서, 도 1c에 도시된 다른 구성(100c)은 리소스 할당 디바이스(140a) 및 에이전트 디바이스들(150a-b) 각각이 독립적인 하드웨어 모듈(160c, 162c, 164c) 각각에 상주할 수 있다는 것을 나타낸다. 또한, 각 리소스 할당 디바이스(140a) 및 에이전트 디바이스들(150a-b)은 복수의 하드웨어 모듈들에 의해 제공되는 리소스들을 사용할 수도 있다. 각종 추가적인 배열들이 당업자에겐 명백할 수 있다.
도 1a로 돌아가면, 클라우드 컴퓨팅 게이트웨이(130) 및/또는 리소스 할당 디바이스들(140a-b)은 하드웨어 모듈의 하드웨어 컴포넌트들의 고장을 처리하도록 구성될 수 있다. 예를 들어, 하드웨어 모듈(160a)의 CPU가 고장나거나 그 밖의 사용될 수 없는 것으로 고려되는 경우, 클라우드 컴퓨팅 게이트웨이(130) 및/또는 리소스 할당 디바이스(140a)는 CPU의 소프트웨어 또는 하드웨어 구성들을 변경하거나 그 밖에 사용가능한 리소스 풀로부터 CPU를 제거함으로써 그 고장난 CPU를 비활성화할 수 있다. 클라우드 컴퓨팅 게이트웨이(130) 및/또는 리소스 할당 디바이스(140a)는 하드웨어 모듈(160a)을 재구성하여 그 고장난 CPU의 전원을 끔으로써 후속적으로 운영 비용을 저감시킬 수도 있다. 또한, 클라우드 컴퓨팅 게이트웨이(130) 및/또는 리소스 할당 디바이스(140a)는 기존에 그 고장난 CPU를 사용하고 있던 에이전트 디바이스들(150a-b)을 모듈(160a)의 상이한 CPU를 사용하거나 또는 모듈(170a)과 같은 다른 모듈의 CPU를 사용하도록 재구성할 수도 있다. 이러한 방식으로, 하드웨어 모듈들(160a, 170a)은 그들의 구성 컴포넌트들이 고장날 시에, 작동 상태를 계속 유지할 수 있다. 상기 모듈들은 그것들이 점차적으로 고장남에 따라, 그 성능이 감소되더라도, 계속적으로 기능을 발휘할 수 있게 된다. 모듈 성능이 작동 계속을 위한 비용-효율 지점 미만으로 떨어지는 경우, 상기 하드웨어 모듈은 폐기 및 대체될 수 있다. 이러한 방식으로, 본 아키텍처는 하드웨어 리소스들에 대한 소모를 제공한다.
또한, 클라우드 컴퓨팅 게이트웨이(130) 및/또는 리소스 할당 디바이스들(140a-b)은 하드웨어 모듈들(160a, 170a)의 소모를 관리하도록 적응될 수도 있다. 특히, 클라우드 컴퓨팅 게이트웨이(130) 및/또는 리소스 할당 디바이스들(140a-b)은 하드웨어 모듈들(160a, 170a)의 각종 작동 파라미터들, 또는 그 컴포넌트들을 조정함으로써, 하드웨어 모듈(160a, 170a)이 목표 교체 날짜에 또는 그것을 약간 넘어서는 시점에서 그들 사용 수명 종점이 도달하도록 하는 것을 보장할 수 있다. 예를 들어, 하드웨어 모듈(160a)이 그 목표 교체 날짜보다 일찍 비 경제적이게 될 것으로 예견되는 경우, 클라우드 컴퓨팅 게이트웨이(130) 및/또는 리소스 할당 디바이스(140a)는 작동 파라미터들을 조정함으로써, 예를 들어 작동 전압이나 클럭 비율(clock rate)을 낮춰 컴포넌트 스트레스를 감소시키는 것과 같이, 하드웨어 모듈의 수명을 연장시킬 수 있으며, 이에 의해 그것의 사용 서비스 수명을 연장시키게 된다. 반대로, 하드웨어 모듈(170a)이 그것의 목표 교체 날짜 이후의 시간동안 비용 효율적인 상태를 유지할 것으로 예견되는 경우, 클라우드 컴퓨팅 게이트웨이(130) 및/또는 리소스 할당 디바이스(140b)는 작동 파라미터들을 조정함으로써, 예를 들어 작업부하를 증대시키는 것에 의해 그것이 대체되는 시점까지 하드웨어 모듈의 최대 사용을 확보하도록 하드웨어 모듈의 수명을 줄어들게 하거나, 쿨링 비율(cooling rate)을 낮춤으로써 운영 비용을 감소시킬 수도 있다.
시스템 관리자들은 이상의 기능을 사용하여 모든 하드웨어 모듈의 주기적인 교체를 계획할 수 있다. 예를 들어, 시스템 관리자들은 매월 전체 하드웨어 모듈의 1/36이 교체될 수 있도록 상호교차적으로(staggered), 3년의 사용 수명을 가지도록 각 하드웨어 모듈을 구성할 수 있다. 여기에 기술된 방법들을 사용하는 시스템에서, 시스템 관리자는 스케줄링된 날짜에 하드웨어 모듈이 대체되는 경우, 그것이 충분히 활용되었으며, 진정으로 운영에 있어서 더 이상 비용 효율적이지 않다는 것을 확신하게 된다.
도 2는 소모성 하드웨어 리소스들을 제공하는 예시적 하드웨어 시스템(200)을 도시한다. 예시적 하드웨어 시스템(200)은 예시적 시스템(100a)의 일부에 대응할 수 있다. 예시적 하드웨어 시스템(200)은 네트워크(220), 클라우드 컴퓨팅 게이트웨이(230), 및 하드웨어 모듈들(260, 270, 280)을 포함할 수 있다.
네트워크(220)는 예시적 시스템(100a)의 다른 디바이스들 간의 통신을 제공하도록 구성된 디바이스 또는 디바이스들의 그룹일 수도 있다. 따라서, 네트워크(120)는 패킷들을 적절한 목적지들로 전달하는 다수의 라우터들 및/또는 스위치들을 포함할 수도 있다. 각종 실시예들에서, 네트워크(120)는 하나 이상의 2G, 3G, 및/또는 4G 시스템들 및/또는 다른 무선 시스템들을 포함할 수 있다. 또한, 각종 실시예들에서, 네트워크(120)는 인터넷 및/또는 하나 이상의 로컬 에어리어 네트워크(LAN)들과 같은 유선 네트워크들을 포함할 수도 있다. 각종 실시예들에서, 네트워크(220)는 예시적 시스템(100a)의 네트워크(120)에 대응할 수 있다.
클라우드 컴퓨팅 게이트웨이(230)는 하드웨어 리소스들을 관리하도록 구성된 디바이스 또는 디바이스들의 그룹일 수도 있다. 따라서, 클라우드 컴퓨팅 게이트웨이(230)는 예시적 시스템(100a)의 클라우드 컴퓨팅 게이트웨이(130)일 수도 있다. 클라우드 컴퓨팅 게이트웨이(230)는 요청 핸들러(232), 에이전트 디바이스 할당 스토리지(234), 모듈 인터페이스(236), 진단 엔진(238), 모듈 상태 스토리지(240), 고장 핸들러(242), 소모 정책 엔진(244), 소모 규칙 스토리지(246), 파라미터 조정기(248), 관리자 인터페이스(250), 비용청구 프로세서(252), 및 서비스 계획 스토리지(254)를 포함할 수 있다. 대안적으로 또는 추가적으로, 클라우드 컴퓨팅 게이트웨이(230)의 각종 컴포넌트들은 하나 이상의 하드웨어 모듈들(260, 270, 280)에 상주하는 하나 이상의 리소스 할당 디바이스들(미도시)에 위치될 수 있음에 유의해야 한다.
요청 핸들러(232)는 에이전트 디바이스들에 대한 요청들을 수신 및 처리하도록 구성된 머신 판독가능 스토리지 매체 상의 실행 가능 명령들 및/또는 하드웨어를 포함할 수 있다. 예를 들어, 요청 핸들러(232)는 네트워크(220)를 통해 클라이언트 디바이스(미도시)로부터 신규 에이전트 디바이스의 설정을 요청하는 요청을 수신할 수 있다. 후속적으로, 요청 핸들러는 신규 에이전트 디바이스를 호스팅하기에 적절한 모듈(260, 270, 280)을 결정할 수 있으며, 그 후에 그 모듈(260, 270, 280)에 상주하는 리소스 할당 디바이스(미도시)와 모듈 인터페이스(236)를 통해 통신함으로써 신규 에이전트 디바이스를 설정할 수 있다. 적절한 모듈(260, 270, 280)의 선택은 모듈 상태 스토리지(240)에 저장된 모듈(260, 270, 280)의 현재 상태, 서비스 계획 스토리지(254)에 저장된 요청 유저의 서비스 계획, 및/또는 애플리케이션이 그 신규 에이전트 디바이스를 실행하기 위한 신뢰성 요구사항에, 적어도 부분적으로, 기초할 수 있다. 신규 에이전트 디바이스를 설정함에 있어서, 또한 요청 핸들러(232)는 에이전트 디바이스 할당 스토리지의 콘텐츠를 업데이트함으로써 요청 클라이언트 디바이스, 에이전트 디바이스, 및 상기 에이전트 디바이스에 할당된 하드웨어 모듈(들) 간의 대응 관계를 반영할 수도 있다.
요청 핸들러(232)는 클라이언트 디바이스들(미도시)과 활성 에이전트 디바이스들(미도시) 간의 메시지들을 라우팅하는 것과 같은 추가 기능을 수행할 수도 있다. 이러한 기능을 행하기 위해, 요청 핸들러(232)는 에이전트 디바이스 할당 스토리지(234)에 저장된 데이터를 참조하여 어떤 리소스 할당 디바이스 및/또는 하드웨어 모듈들이 어떤 클라이언트 디바이스와 관련되어 있는지를 결정할 수 있다. 또한, 요청 핸들러(232)는 에이전트 디바이스들의 설정과 사용에 관한 데이터를 비용청구 프로세서로 전달함으로써, 각 클라이언트 디바이스(미도시)의 유저가 적절하게 비용 청구될 수 있도록 할 수 있다.
에이전트 디바이스 할당 스토리지(234)는 에이전트 디바이스들의 설명 정보를 저장 가능한 머신 판독가능 매체일 수 있다. 따라서, 에이전트 디바이스 할당 스토리지(234)는 ROM(read-only memory), RAM(random-access memory), 자기 디스크 스토리지 매체, 광 스토리지 매체, 플래시-메모리 디바이스들, 및/또는 유사 스토리지 매체와 같은 머신 판독가능 스토리지 매체를 포함할 수 있다. 각종 실시예들에서, 에이전트 디바이스 할당 스토리지(234)는 각 에이전트 디바이스 및 그것과 관련된 리소스 할당 디바이스 및/또는 하드웨어 모듈(들) 사이의 상관관계를 저장할 수 있다.
모듈 인터페이스(236)는 하나 이상의 하드웨어 모듈들(260, 270, 280)과 통신가능하도록 구성된 머신 판독가능 스토리지 매체에 인코딩된 실행 가능 명령들 및/또는 하드웨어를 포함하는 인터페이스일 수 있다. 각종 실시예들에서, 모듈 인터페이스(236)는 이더넷(Ethernet), PCI, SCSI, ATA, 및/또는 다른 하드웨어 인터페이스 기술들을 포함할 수 있다. 각종 실시예들에서, 모듈 인터페이스(236)는 블레이드 서버 백플레인을 포함할 수 있다.
진단 엔진(238)은 하드웨어 모듈들(260, 270, 280) 및 그것의 하드웨어 컴포넌트들(262, 272, 274, 286)에 대한 각종 진단을 수행하여 그 하드웨어 디바이스들의 현재 건강상태(health) 및/또는 고장율을 측정하도록 구성된 머신 판독가능 스토리지 매체 상의 실행 가능 명령들 및/또는 하드웨어를 포함할 수 있다. 각종 실시예들에서, 진단 엔진(238)은 각 하드웨어 컴포넌트(262, 272, 274, 286)에 대한 테스트를 주기적으로 개시하여 하드웨어 컴포넌트(262, 272, 274, 286)의 현재 및/또는 과거 고장율을 결정할 수 있다. 예를 들어, 진단 엔진은 적절한 하드웨어 모듈(260, 270, 280)에 상주하는 리소스 할당 디바이스와 통신하여 리소스 풀로부터 그 컴포넌트를 제거하고/하거나 하나 이상의 진단 테스트를 위한 신규 에이전트 디바이스를 설정할 수 있다. 그 후에, 진단 엔진(238)은 모듈 인터페이스(236)를 통해 테스트 결과를 수신할 수 있으며, 후속적으로 모듈 상태 스토리지(240)를 업데이트함으로써 그 테스트된 하드웨어 컴포넌트의 현재 상태를 반영할 수 있다. 하드웨어 컴포넌트가 고장나 있거나 그 밖의 사용 불가능한 상태임을 테스트가 나타내는 경우, 진단 엔진은 적절한 적응적 액션을 취하도록 하는 명령을 고장 핸들러(242)에게 송신할 수 있으며, 이러한 것들을 이하에 더 상세히 기술하도록 한다.
진단 엔진(238)은 개개의 하드웨어 컴포넌트들(262, 272, 274, 286)의 진단 결과와 본 기술분야에서 잘 알려진 각종 "가용 수명(useful life)" 기술들을 더 활용하여 전체적인 하드웨어 모듈(260, 270, 280)의 현재 수명 단계를 측정할 수 있다. 도 4와 관련하여 아래에서 더 상세히 기술되는 바와 같이, 하드웨어 컴포넌트들은 그들 가용 수명에 있어서 상이한 단계에 있는, 상이한 고장율들을 나타낼 것으로 예상될 수 있다. 이러한 현상은 종종 잘 알려져 있는 "배스터브 곡선(bathtub curve)"을 따르게 된다. 진단 엔진(238)은 단계적 서비스 계획 및 고장 예측의 목적으로, 각 모듈(260, 270, 280)에 대한 현재의 수명 단계를 결정하도록 적응될 수 있다.
모듈 상태 스토리지(240)는 하드웨어 모듈들 및 하드웨어 컴포넌트들과 관련된 상태 정보를 저장 가능한 임의의 머신 판독가능 매체일 수 있다. 따라서, 모듈 상태 스토리지(240)는 ROM(read-only memory), RAM(random-access memory), 자기 디스크 스토리지 매체, 광 스토리지 매체, 플래시-메모리 디바이스들, 및/또는 유사 스토리지 매체와 같은 머신 판독가능 스토리지 매체를 포함할 수 있다. 이하에서는, 모듈 상태 스토리지(240)의 예시적 콘텐츠가 도 5를 참조하여 보다 상세히 기술될 것이다. 각종 실시예들에서, 모듈 상태 스토리지(240)는 에이전트 디바이스 할당 스토리지(234)와 동일한 디바이스일 수 있다.
고장 핸들러(242)는 각종 하드웨어 컴포넌트들(262, 272, 274, 286)이 고장나거나 그 밖에 사용 불가능하게 된 것에 반응하도록 구성된 머신 판독가능 스토리지 매체 상의 실행 가능 명령들 및/또는 하드웨어를 포함할 수 있다. 고장 핸들러(242)는 이러한 고장 표시를, 대응 하드웨어 모듈(260, 270, 280)에서 작동하는 리소스 할당 디바이스(미도시)로부터 직접 및/또는 진단 엔진(238)으로부터 수신할 수 있다. 하드웨어 컴포넌트가 새롭게 사용 불가능하게 되었다는 표시에 반응하여, 고장 핸들러(242)는 에이전트 디바이스 할당 스토리지(234)를 참조하여 어떤 에이전트 디바이스들이 그 하드웨어 컴포넌트를 사용하고 있었는지를 결정할 수 있다. 또한, 고장 핸들러(234)는 해당 하드웨어 모듈의 감소된 성능이 현재 그것에 모듈이 할당되어 있는 모든 에이전트 디바이스들을 계속적으로 지원하는데 충분한지의 여부를 결정할 수 있다. 이러한 정보에 기초하여, 고장 핸들러(242)는 하나 이상의 에이전트 디바이스들을 다른 하드웨어 모듈들로 재분배할 수 있다. 예를 들어, 모듈 A 상의 프로세서(262)가 사용 불가능하게 된 경우, 고장 핸들러(242)는 모듈들(260, 270) 상의 리소스 할당 디바이스들과 통신하여 하나 이상의 에이전트 디바이스들이 모듈 B(270)로 이동하도록 함으로써, 모듈 A(260)를 사용하는 에이전트 디바이스들의 수행들이 상기 모듈의 현재 감소된 성능으로 인하여 악영향을 받지 않도록 하는 것을 보장할 수 있다. 또한, 고장 핸들러(242)는 에이전트 디바이스 할당 스토리지(234)의 콘텐츠를 업데이트하여 재분배된 에이전트 디바이스들을 반영할 수 있다.
소모 정책 엔진(244)은 예측되는 모듈의 잔존 수명에 따라 어떤 액션을 취할지를 결정하도록 구성된 머신 판독가능 스토리지 매체 상의 실행 가능 명령들 및/또는 하드웨어를 포함할 수 있다. 각종 실시예들에서, 모듈 상태 스토리지(240)에 저장된 상태 정보를 사용하는, 소모 정책 엔진(244)은 본 기술분야에서 알려진 각종 기술들을 이용하여 각 하드웨어 모듈(260, 270, 280)에 대한 추정 고장 날짜를 예측할 수 있다. 각종 실시예들에서는, 소모 규칙 스토리지는 각 모듈에 대한 전체 고장 날짜를 예측하는 것이 아니라, 하나 이상의 모듈들(260, 270, 280)에 대한 고장 상태를 저장할 수도 있다. 이 고장 상태는 그 모듈을 계속 운영하기에 더 이상 비용 효율적이지 않은 모듈 상태를 명시할 수도 있다. 예를 들어, 관리자는 적어도 8개의 프로세서들이 계속 기능하는 동안에만 모듈 A(260)를 계속 작동시키는 것이 비용 효율적이라는 것을 결정할 수 있다. 이에 따라, 소모 정책 엔진은 모듈 A(260)가 8개 미만의 기능 프로세서들을 가지는 것으로 예상되는 날짜를 예측할 수 있다.
그 후에, 소모 정책 엔진(244)은 예측된 고장 날짜를 모듈에 대한 목표 교체 날짜와 비교할 수 있다. 이러한 목표 교체 날짜는 소모 규칙 스토리지(246)에 저장될 수 있다. 예측된 고장 날짜가 목표 교체 날짜에 충분히 근접해 있지 않은 경우, 소모 정책 엔진(244)은 이 사실을 파라미터 조정기에 표시함으로써 모듈의 소모율(consumption rate)이 변경될 수 있도록 할 수 있다. 각종 실시예들에서, 소모 정책 엔진(244)은 예측된 고장 날짜가 목표 교체 날짜과 일치되도록 요구할 수 있으며, 다른 실시예들은 몇 일 또는 몇 달의 공차(tolerance)를 허용할 수도 있다. 이러한 다른 실시예들은 목표 교체 날짜 이후의 이러한 공차를 허용할 수 있으며, 목표 교체 날짜 이전의 공차는 허용할 수 없다.
소모 규칙 스토리지(246)는 각 하드웨어 모듈이 대체되어야할 및 대체될 시점과 관련된 상태 정보를 저장 가능한 임의의 머신 판독가능 매체일 수 있다. 따라서, 소모 규칙 스토리지(246)는 ROM(read-only memory), RAM(random-access memory), 자기 디스크 스토리지 매체, 광 스토리지 매체, 플래시-메모리 디바이스들, 및/또는 유사 스토리지 매체와 같은 머신 판독가능 스토리지 매체를 포함할 수 있다. 각종 실시예들에서, 소모 규칙 스토리지(246)는 각 모듈에 대한 고장 상태와 목표 교체 날짜을 저장할 수 있다. 각종 실시예들에서, 소모 규칙 스토리지(246)는 에이전트 디바이스 할당 스토리지(234) 및/또는 모듈 상태 스토리지(240)와 동일한 디바이스일 수 있다.
파라미터 조정기(248)는 하드웨어 컴포넌트들의 각종 작동 파라미터들을 조정하여 하드웨어 모듈들의 가용 수명을 줄어들게 하거나 연장하도록 구성되는 머신 판독가능 스토리지 매체 상의 실행 가능 명령들 및/또는 하드웨어를 포함할 수 있다. 소모 정책 엔진에 의해 보고되는, 모듈의 목표 교체 날짜 및 모듈의 예측된 고장 날짜에 기초하여, 파라미터 조정기는 하나 이상의 예측 모델들을 사용하여, 모듈의 예측된 고장 날짜를 목표 교체 날짜에 더 근접하게 이동시키도록 사용할 수 있는 하나 이상의 파라미터 조정들을 결정할 수 있다. 이러한 예측 모델들은 예를 들어, 하드웨어 컴포넌트들(262, 272, 274, 286) 및/또는 하드웨어 모듈들(260, 270, 280)의 하드웨어 제조업체들에 의해 제공될 수 있다. 예를 들어, 파라미터 조정기(260)가 모듈 A(260)는 10월에 교체될 것이라고 스케줄링된 표시를 수신하였지만, 11월까지 연장되는 예상 수명을 가진 경우, 파라미터 조정기(248)는 모듈 A의 가용 수명이 1달 짧아져야 한다는 것을 결정할 수 있다. 제조업체가 제공한 예측 모델들을 사용하여, 파라미터 조정기(248)는 추가의 200MHz 만큼 오버 클러킹된(overclocking) 프로세서들(262)가 약 1달만큼 모듈 A(260)의 가용 수명을 감소시키는 것으로 결정할 수 있다. 적절한 파라미터 조정을 결정한 이후에, 파라미터 조정기(248)는 모듈 인터페이스(236)를 통해 하드웨어 모듈(260, 270, 280)와 통신함으로써 하드웨어에 대한 파라미터 조정을 행하도록 더 적응될 수 있다.
관리자 인터페이스(250)는 관리자가 클라우드 컴퓨팅 게이트웨이(230)와 상호작용할 수 있도록 하는 디스플레이, 키보드, 및/또는 마우스와 같은 각종 디바이스들을 포함할 수 있다. 각종 실시예들에서, 모듈(260, 270, 280)이 고장났으며 가능하다면 목표 교체 날짜 이전에 교체되어야 하는 것으로 진단 엔진(238), 소모 정책 엔진(244), 또는 다른 컴포넌트가 결정한 경우, 관리자 인터페이스는 관리자에게 그 고장을 알릴 수 있다. 또한, 관리자 인터페이스(250)는 관리자로 하여금 소모 규칙 스토리지(246)의 콘텐츠를 변경하게 할 수도 있다. 예를 들어, 관리자는 관리자 인터페이스(250)를 사용하여 각종 모듈들(260, 270, 280)에 대한 고장 상태들 및 목표 교체 날짜들을 정의할 수 있다. 예를 들어, 관리자는 업데이트된 사업 의사결정의 관점에서 모듈 A의 고장 상태를 6개 미만의 작동 프로세서들에서 8개 미만의 작동 프로세서들로 변경할 수 있다. 당업자에게는 관리자 인터페이스(250)에 대한 각종 추가적인 사용들이 명백할 것이다.
비용청구 프로세서(252)는 예시적 하드웨어 시스템의 유저들을 변경하도록 구성되는 머신 판독가능 스토리지 매체 상의 실행 가능 명령들 및/또는 하드웨어를 포함할 수 있다. 비용청구 프로세서(252)는 요청 핸들러(232)로부터 활동(activity)의 표시들을 수신할 수 있으며, 후속적으로 그들의 서비스 계획에 따라 관련 사용자의 계정에 비용청구를 할 수 있다. 당업자에게는 각종 측정 방법 및 비용청구 방법이 명백할 것이다.
서비스 계획 스토리지(254)는 각종 예시적 하드웨어 시스템(200)의 유저들과 관련된 서비스 계획에 관한 정보를 저장 가능한 임의의 머신 판독가능 매체일 수 있다. 따라서, 서비스 계획 스토리지(254)는 ROM(read-only memory), RAM(random-access memory), 자기 디스크 스토리지 매체, 광 스토리지 매체, 플래시-메모리 디바이스들, 및/또는 유사 스토리지 매체와 같은 머신 판독가능 스토리지 매체를 포함할 수 있다. 각종 실시예들에서, 서비스 계획 스토리지(254)는 유저 식별 데이터, 빌링(billing) 정보, 서비스 계층 및 각종 유저들에 대한 권한과 비용청구 상세들을 정의함에 있어서 유용한 그 밖의 다른 정보를 저장할 수 있다. 각종 실시예들에서, 서비스 계획 스토리지(254)는 에이전트 디바이스 할당 스토리지(234), 모듈 상태 스토리지(240), 및/또는 소모 규칙 스토리지(246)와 동일한 디바이스일 수 있다.
하드웨어 모듈들(260, 270, 280) 각각은 예시적 하드웨어 시스템(200)에서의 사용을 위해 하드웨어 리소스들을 제공하는 하드웨어 모듈일 수 있다. 하드웨어 모듈들(260, 270, 280)은 하드웨어 모듈들의 3개의 상이한 가능 구성들을 도시한다. 3개의 가능 구성들이 도시되어 있지만, 각종 다른 구성들이 또한 존재할 수 있다는 것을 당업자는 이해할 것이다. 또한, 3개의 하드웨어 모듈들(260, 270, 280)이 나타나 있지만, 하드웨어 시스템(200)은 그보다 많거나 적은 하드웨어 모듈들을 포함할 수도 있다.
하드웨어 모듈 A(260)은 단일 타입 하드웨어 모듈일 수 있다. 즉, 모듈 A(260)는 단일 타입의 하드웨어 컴포넌트들을 포함할 수 있다. 도시된 예에서, 모듈 A(260)는 18개의 프로세서들(262)을 포함하며, 어떤 다른 하드웨어 컴포넌트들도 포함하지 않는다. 여기에서 사용되는 용어 "하드웨어 컴포넌트"는 리소스 할당 디바이스 또는 에이전트 디바이스의 일부로서 사용될 하드웨어 리소스들을 제공하거나, 그 밖에 외부 클라이언트 디바이스에 의한 사용을 위해 제공될 컴포넌트들을 지칭한다. 따라서, 모듈 A(260)이 예를 들어 파워 서플라이 및/또는 통신 인터페이스와 같은 추가 하드웨어를 포함하여 프로세서들(262)을 지원할 수도 있지만, 이러한 하드웨어는 하드웨어 컴포넌트들을 구성하지 않는다.
프로세서들(262) 중의 하나 이상은, 적어도 부분적으로, 리소스 할당 디바이스(미도시)에 속할 수 있다. 앞서 설명한 바와 같이, 리소스 할당 디바이스는 프로세서들(262) 중의 하나 이상을 또한 적어도 부분적으로 포함하는 복수의 에이전트 디바이스들(미도시)을 관리하는 것을 담당할 수 있다. 전술한 바와 같이, 모듈 A(260)는 단일 모듈일 수 있다. 즉, 프로세서들(262)을 사용하는 에이전트 디바이스들은 다른 하드웨어 모듈들(미도시)에 위치된 다른 하드웨어 컴포넌트들을 추가로 사용할 수도 있다. 예를 들어, 프로세서들(262) 중의 하나를 사용하는 에이전트 디바이스는 상이한 모듈(미도시)에 장착된 메인 메모리(미도시)의 일부를 사용할 수도 있다.
모듈 B(270)은 분리된 이기종(heterogeneous) 하드웨어 모듈을 도시한다. 도시된 바와 같이, 모듈 B(270)은 12개의 프로세서들(272) 및 3개의 메모리 뱅크들(274)을 포함한다. 모듈 A(260)와 같이, 모듈 B(270)는 리소스 할당 디바이스 및 복수의 에이전트 디바이스들을 지원할 수 있다. 그러나, 모듈 B(270)의 경우, 각각의 리소스 할당 디바이스 및 에이전트 디바이스는 동일한 물리적 모듈로부터 복수 타입의 하드웨어 리소스들을 찾아낼 수 있다. 임의의 프로세서(272)는 임의의 메모리 뱅크(274)를 사용할 수 있다. 즉, 2개의 리소스들은 분리되어 있다. 그러나, 효율적이고 효과적인 사용을 보장하기 위해, 리소스 할당 디바이스는 각각의 에이전트 디바이스에게 하나 이상의 프로세서들(272) 및 하나 이상의 메모리 뱅크들(274)의 특정 공유를 할당하는 것을 담당할 수 있다.
모듈 C(280)는 커플링되어 있는 이종의 하드웨어 모듈을 도시하고 있다. 도시된 바와 같이, 모듈 C(280)는 18개의 "연산 코어(compute cores)"(286)를 포함한다. 각 연산 코어(286)는 하나의 유닛으로 함께 작동하도록 설계된 복수의 하드웨어 디바이스들을 포함할 수 있다. 예를 들어, 각 연산 코어(286)는 프로세서 및 메모리 뱅크(미도시)를 포함할 수 있다. 즉, 각 연산 코어는 하드웨어 요소로 지칭될 수 있다. 다시, 리소스 할당 디바이스 및 복수의 에이전트 디바이스들은 연산 코어들(286)을 공유할 수 있다. 그러나, 각종 타입의 하드웨어 리소스들은 긴밀하게 커플링되어 있기 때문에, 리소스 할당 디바이스가 반드시 에이전트 디바이스들에 대한 많은 다른 유형의 타입의 리소스들을 관리할 필요는 없다. 대신에, 리소스 할당 디바이스는 간단하게 각각의 에이전트 디바이스에 하나 이상의 연산 코어들(286)의 공유를 할당할 수 있다.
도 3에 대하여 더욱 상세하게 기술되는 바와 같이, 각각의 모듈(260, 270, 280)은 임의의 단일 하드웨어 컴포넌트가 하드웨어 컴포넌트들의 연속적인 동작 상태로 유지하면서 비활성화될 수 있도록 설계될 수 있다. 즉, 각 모듈(260, 270, 280)은 각각의 실장된 하드웨어 컴포넌트에 대한 제어 신호에 의해 중단될 수 있는 전력 전달 회로를 포함할 수 있다. 이러한 제어 신호는 특정 하드웨어 컴포넌트가 고장이며 그렇지 않으면 더 이상 사용 불가능한 것으로 결정될 시에, 리소스 할당 디바이스, 클라우드 컴퓨팅 게이트웨이, 및/또는 하드웨어 모듈들의 건강상태를 관리하도록 구성된 별도의 디바이스(미도시)에 의해 어써팅(asserting)될 수 있다.
도 3은 고장난 하드웨어 컴포넌트를 처리하는 예시적 방법(300)을 도시하고 있다. 설명의 목적을 위하여, 방법(300)은 리소스 할당 디바이스에 의해 수행되는 것으로 가정될 것이다. 그러나, 추가적으로 또는 대안적으로, 예시적 방법(300)은 클라우드 컴퓨팅 게이트웨이(200)와 같은 클라우드 컴퓨팅 게이트웨이의 컴포넌트들에 의해 수행될 수도 있음을 이해할 것이다.
예시적 방법(300)은 스텝 305에서 시작될 수 있으며, 리소스 할당 디바이스가 하드웨어 컴포넌트 고장을 식별하는 스텝 310로 진행할 수 있다. 특히, 리소스 할당 디바이스는 하드웨어 컴포넌트가 고장났거나 가까운 장래에 고장날 가능성이 있는 것으로 결정할 수 있다. 각종 실시예들에서, 리소스 할당 디바이스는 하드웨어 컴포넌트가 사용 불가능한 것으로 달리 간주할 수도 있다. 이어서, 방법(300)은 현재 어떤 에이전트 디바이스들이 사용 불가능한 하드웨어 컴포넌트의 공유를 포함하고 있는지를 리소스 할당 디바이스가 결정하는 스텝 315으로 진행할 수 있다. 이어서, 스텝 320에서, 리소스 할당 디바이스는 그들 에이전트 디바이스들을 재할당하여 다른 하드웨어 컴포넌트들을 대신 사용하도록 할 수 있다. 이 스텝의 수행 후에, 그 고장난 컴포넌트는 임의의 디바이스들에게 하드웨어 리소스들을 제공하는데 더 이상 사용될 수 없다. 이 시점에서, 방법(300)은 선택적으로 종료될 수 있으며, 리소스 할당 디바이스는 향후에 상기 고장난 컴포넌트를 사용하는 것을 간단하게 회피할 수 있다.
각종 실시예들에서, 방법(300)은 고장난 하드웨어 컴포넌트에 대한 전원을 차단하도록 리소스 할당 디바이스가 하드웨어 모듈을 재구성할 수 있는 스텝 325로 진행할 수 있다. 이것은 전력 소모를 감소시키는 효과가 있을 수 있으며, 결과적으로, 모듈 전체의 지속적인 작동의 비용을 감소시키는 효과가 있을 수 있다. 이어서, 스텝 330에서, 리소스 할당 디바이스는 그 고장을 클라우드 컴퓨팅 게이트웨이로 보고할 수 있다. 이 보고를 이용하여, 클라우드 컴퓨팅 게이트웨이는 복수의 리소스 할당 디바이스들 사이에서, 더 높은 레벨에 있는 에이전트 디바이스들을 재분배하도록 진행할 수 있다. 클라우드 컴퓨팅 게이트웨이 자체로 방법(300)이 수행되는 실시예들에서는 스텝 330이 존재하지 않을 수 있다는 것은 명백하다. 이어서, 방법(300)은 스텝 335에서 종료되는 것으로 진행할 수 있다.
도 4는 시간에 따른 하드웨어 모듈의 고장율의 예시적 그래프(400)를 도시하고 있다. 라인 410은 일 하드웨어의 하드웨어 고장율이 시간에 따라 일반적으로 "배스터브 곡선" 모델을 따를 수 있음을 보여준다. 하드웨어 디바이스 수명의 시작 부근에서, 하드웨어 고장은 소위 "인펀트 모탈러티 레이트(infant mortality rate)"로 인하여 상대적으로 높을 수 있다. 다시 말해, 몇몇 하드웨어 디바이스들은 잠재적 결함들로 인하여 작동 직후에 고장나게 된다. 이 단계에서 생존한 이후에, 하드웨어는 가용 수명의 대부분을 에러 없는 상태로 향유한다. 이어서, 하드웨어가 노쇠함에 따라, "마모"로 인하여 하드웨어 고장 빈도가 증가하게 되며, 결국, 하드웨어는 완전히 사용 불가능하게 된다.
여기에 기술된 각종 양태의 시스템들에 따르면, 하드웨어 컴포넌트의 가용 수명은, 하드웨어 할당 및 비용청구 목적들에 관한 여러 가지 단계들로 분류될 수 있다. 도시된 바와 같이, 그래프(400)는 5개의 수명 단계들, 즉 브랜드 신규 단계(421), 주요 단계(422), 노쇠 단계(423), 마모 단계(424), 및 수명 종료 단계(425)로 분할될 수 있다. 여러 가지 다른 단계 배열들이 가능할 수 있음은 명백하다.
하드웨어 모듈이 현재 상태를 평가하는 일부로서, 클라우드 컴퓨팅 게이트웨이 및/또는 리소스 할당 디바이스는 현재 하드웨어 모듈이 작동하고 있는 수명 단계를 결정하도록 적응될 수 있다. 이 정보는 본 기술 분야에서 알려진 각종 가용 수명 기술들과 모듈의 구성 컴포넌트들의 이력 고장율들을 사용하여 결정될 수 있다. 그 후에, 이 정보는 모듈의 수명 단계에 기초하여 하드웨어 모듈들에게 신규 에이전트 디바이스들을 할당하는데 사용될 수 있다. 예를 들어, 프리미엄 사용자는 하드웨어 고장이 일어날 가능성이 없는 주요 단계(422)에서 현재 작동하고 있는 하드웨어의 사용에 대해 더 많은 비용을 지불할 수 있다. 다른 예로서, 상이한 애플리케이션들은 다른 고장 공차들을 가질 수 있다. 즉, 고위험 허용 애플리케이션에는 브랜드 신규 단계(421) 또는 마모 단계(424)에서 작동하는 하드웨어가 할당될 수 있다. 또한, 클라우드 컴퓨팅 게이트웨이 및/또는 리소스 할당 디바이스는 수명 종료 단계(425)에 있는 모듈들을 완전히 방지할 수 있다.
도 5는 하드웨어 상태 정보를 저장하는 예시적 데이터 배열(500)을 도시하고 있다. 예시적 데이터 배열(500)은 예시적 하드웨어 시스템(230)의 모듈 상태 스토리지(240)의 예시적 콘텐츠를 도시하고 있다. 데이터 배열은 예를 들어, 모듈 필드(510), 수명 단계 필드(520), 컴포넌트 필드(530), 및 고장율 필드(540)와 같은 다수의 필드들을 포함할 수 있다.
모듈 필드(510)는 특정 모듈 기록이 적용된 모듈을 식별할 수 있다. 수명 단계 필드(520)는 모듈에 대해 가장 최근에 추정된 수명 단계를 표시할 수 있다. 컴포넌트 필드(530)는 모듈에 실장된 하드웨어 컴포넌트를 식별할 수 있다. 고장율 필드(540)는 컴포넌트에 대해 가장 최근에 관측된 고장율을 나타낼 수 있다. 데이터 배열(500)은 모듈 기록들 내에 네스팅된(nested) 컴포넌트 기록들을 예시하고 있지만, 이것은 추상화를 구성할 수도 있음에 유의한다. 실제에 있어서 데이터 배열(500)은 다수의 상이한 방식들로 저장될 수 있다는 것을 당업자는 인식할 것이다. 예를 들어, 데이터 배열(500)은 각각의 하드웨어 모듈들 및 하드웨어 컴포넌트들에 독립적으로 전용인, 복수의 테이블들로 저장될 수 있다.
일 예로서, 모듈 기록(560)은 모듈 A가 현재 제 3 수명 단계, 또는 노쇠 단계(423)에 있는 것으로 추정됨을 나타낼 수 있다. 모듈 기록(560)은 다수의 컴포넌트 하위-기록들(562, 564, 566)을 포함할 수 있다. 컴포넌트 하위-기록(562)은 CPU1이 5% 고장율을 가지는 것으로 관측되었음을 표시할 수 있으며, 컴포넌트 하위-기록(564)은 CPU2가 50% 고장율을 가지는 것으로 관측되었음을 표시할 수 있다. 모듈 기록(560)은 다수의 추가 컴포넌트 하위-기록들(566)을 포함할 수 있다. 예시적 모듈 기록들(570, 580) 및 예시적 컴포넌트 하위-기록들(572, 573, 574, 576, 578, 582, 584, 586)은 유사한 정보를 나타내며, 이것의 의미하는 바는 전술한 설명의 관점에서 명백할 것이다.
도 6은 하드웨어 리소스들의 소모를 제어하는 예시적 방법(600)을 도시하고 있다. 설명의 목적을 위하여, 방법(600)은 클라우드 컴퓨팅 게이트웨이(200)와 같은 클라우드 컴퓨팅 게이트웨이의 컴포넌트에 의해 수행되는 것으로 가정될 것이다. 그러나, 예시적 방법(300)은 추가적 또는 대안적으로 리소스 할당 디바이스에 의해 수행될 수 있다는 것이 이해될 것이다.
방법(600)은 스텝 605에서 시작할 수 있으며, 클라우드 컴퓨팅 게이트웨이가 하드웨어 컴포넌트에 대한 진단 테스트를 수행할 수 있는 스텝 610으로 진행할 수 있다. 예를 들어, 클라우드 컴퓨팅 게이트웨이는 리소스 풀로부터 컴포넌트를 제거할 수 있으며/있거나 하나 이상의 테스트들을 수행하도록 컴포넌트에 대한 신규 에이전트 디바이스를 착수시킬 수 있다. 진단 테스트로부터 결과를 수신시에, 클라우드 컴퓨팅 게이트웨이는, 스텝 615에서, 그 테스트들이 컴포넌트는 더 이상 사용될 수 없다는 것을 나타내는지의 여부를 결정할 수 있다. 각종 실시예들에서, 클라우드 컴퓨팅 게이트웨이는 컴포넌트의 지속적인 작동이 더 이상 비용 효율적이지 않으며/않거나 충분히 낮은 고장 위험성을 가진 수용가능한 품질의 서비스를 제공할 수 있는 경우에는, 그 컴포넌트가 "더 이상 사용 불가능한" 것이며 이에 따라 "고장난" 것으로 결정할 수 있다. 따라서, 컴포넌트가 기술적으로는 계속 작동할 수 있더라도, 클라우드 컴퓨팅 게이트웨이는 각종 추가 인자들에 기초하여 그것을 고장난 컴포넌트로 간주할 수 있다.
컴포넌트가 고장난 경우, 스텝 620에서, 클라우드 컴퓨팅 게이트웨이는 하나 이상의 에이전트 디바이스들을 다른 하드웨어 모듈들로 이동시킬 수 있으며, 이에 따라 고장난 컴포넌트를 가진 모듈에 대한 부하를 저감시킬 수 있다. 컴포넌트가 아직 고장 나지 않은 경우이거나 또는 클라우드 컴퓨팅 게이트웨이가 에이전트 디바이스들을 이동시킨 이후에는, 방법(600)은 클라우드 컴퓨팅 게이트웨이가 테스트된 컴포넌트와 관련된 고장율 정보를 업데이트할 수 있는 스텝 625으로 진행할 수 있다.
스텝 630에서, 클라우드 컴퓨팅 게이트웨이는 추가 컴포넌트들을 테스트해야하는지의 여부를 결정할 수 있다. 예를 들어, 클라우드 컴퓨팅 게이트웨이는 모듈 상의 모든 컴포넌트들을 동시에 테스트할 수 있으며 또는 다수의 컴포넌트들이 특정 시간에 테스트하도록 스케줄링될 수도 있다. 추가 컴포넌트들이 계속 테스트되는 경우에는, 방법(600)은 스텝 610으로 루프백 할 수 있다. 테스트 될 모든 컴포넌트들이 테스트 완료된 경우에는, 방법(600)은 스텝 630 에서 스텝 635으로 진행할 수 있다.
스텝 635에서, 클라우드 컴퓨팅 게이트웨이는 하드웨어 모듈에 대한 현재의 수명 단계를 추정할 수 있다. 이 스텝은 당업자에게 알려져 있는 각종 "가용 수명" 기술들에 따라 수행될 수 있으며, 이것은 하드웨어 모듈의 구성 컴포넌트들의 고장율에 기반할 수 있다. 설명의 목적을 위하여, 방법(600)은 도 4에 관하여 상세히 설명한 방식으로 수명 단계들을 정의하는 것으로 가정될 것이다. 각종 다른 수명 단계 방식들이 또한 사용될 수도 있다는 것은 명백하다. 모듈의 수명 단계를 추정한 이후에, 클라우드 컴퓨팅 게이트웨이는 모듈 기록 및 방법(600)을 업데이트할 수 있다.
다음으로, 스텝 640에서, 클라우드 컴퓨팅 게이트웨이는 모듈이 수명 단계 5에서 현재 작동하고 있는 것으로 추정되는 지의 여부를 결정할 수 있다. 즉, 클라우드 컴퓨팅 게이트웨이는 모듈이 "수명 종료" 단계에 있는지의 여부를 결정할 수 있다. 그러한 경우, 스텝 645에서, 클라우드 컴퓨팅 게이트웨이는 그 모듈이 더 이상 사용 불가능하며 대체되어야 한다는 것을 관리자에게 통지할 수 있다. 그러나, 모듈이 다른 수명 단계에 있는 경우, 방법(600)은 스텝 650으로 진행할 수 있다. 각종 다른 실시예들에서, 클라우드 컴퓨팅 게이트웨이는 예를 들어 "마모 단계"와 같은 다른 수명 단계에서 모듈이 교체되어야 한다는 것을 관리자에게 통지하도록 적응될 수 있음에 유의해야 한다. 또한, 각종 실시예들에서, 스텝 645의 교체 통지를 야기하는 수명 단계는 시스템 전역 또는 전-모듈 기반에 기초하여 관리자에 의해 구성될 수 있다. 스텝 640에 대한 각종 추가 변형들이 당업자에게는 명백할 것이다.
스텝 650에서, 클라우드 컴퓨팅 게이트웨이는 모듈에 대한 고장 날짜를 예측할 수 있다. 이 스텝은 당업자에게 알려진 각종 방법들에 기초하여 수행될 수 있다. 예를 들어, 클라우드 컴퓨팅 게이트웨이는 하드웨어 제조업체에 의해 제공되는 예측 모델을 사용하여 하드웨어 모듈이 명시된 고장 조건을 충족하게 될 시기를 추정할 수 있다. 이 결정은 예를 들어, 모듈의 수명 단계 및/또는 그것의 구성 컴포넌트들의 고장율과 같은 각종 상태 정보를 기초하여 이루어질 수 있다.
스텝 655에서, 클라우드 컴퓨팅 게이트웨이는 예측된 고장 날짜가 목표 교체 날짜에 충분히 근접해 있는지의 여부를 결정하도록 진행할 수 있다. 각종 실시예들에서, 방법(600)은 두 날짜들이 일치하는 것을 필요로 할 수 있으며, 반면에 다른 실시예들에서는, 방법(600)은 두 날짜들에 있어서 미리 결정된 가변도(variance)를 허용할 수도 있다. 두 날짜들이 충분히 근접해 있는 경우, 모듈은 상기 교체 날짜에 소모될 트랙 상에 있는 것으로 간주되며, 방법(600)은 스텝 655에서 종료되는 것으로 진행할 수 있다.
그러나, 두 날짜들이 충분히 근접해 있지 않은 경우, 스텝 660에서, 클라우드 컴퓨팅 게이트웨이는 하드웨어의 각종 작동 파라미터들을 조정할 수 있다. 파라미터들을 조정하는 것에 의해, 클라우드 컴퓨팅 게이트웨이는 하드웨어 모듈의 고장을 재촉 또는 지연할 수 있으며, 이에 의해 이제 하드웨어 모듈은 목표 교체 날짜에 충분히 근접하게 고장이 생기는 것으로 예상될 수 있다. 이 기능을 달성하기 위한 예시적 프로세스를, 도 7에 관하여 이하 더욱 상세히 기술하도록 한다. 하드웨어 모듈을 재구성한 이후에, 방법(600)은 스텝 665에서 종료되는 것으로 진행할 수 있다.
도 7은 하드웨어 파라미터들을 조정하기 위한 예시적 방법(700)을 도시하고 있다. 설명의 목적을 위하여, 방법(700)은 클라우드 컴퓨팅 게이트웨이(200)와 같은 클라우드 컴퓨팅 게이트웨이의 컴포넌트들에 의해 수행되는 것으로 가정될 것이다. 그러나, 예시적 방법(700)은 추가적 또는 대안적으로 리소스 할당 디바이스에 의해 수행될 수 있음이 이해될 것이다. 방법(700)은 방법(600)의 스텝 660에 대응할 수 있다.
방법(700)은 스텝 705에서 시작할 수 있으며, 클라우드 컴퓨팅 게이트웨이가 조정 파라미터를 결정할 수 있는 스텝 710으로 진행할 수 있다. 예를 들어, 클라우드 컴퓨팅 게이트웨이는 그것이 클럭 빈도, 쿨링 레이트(cooling rate), 및/또는 인가 전압을 조정해야 하는 것으로 결정할 수 있다. 대안적 또는 추가적으로, 클라우드 컴퓨팅 게이트웨이는 활성 스케줄을 조정할 수 있으며, 이에 따라 하드웨어 모듈이 작동하고 있는 시간의 더 짧거나 더 긴 비율 동안 컴포넌트가 활성이 되도록 한다. 이 결정은 미리 결정된 파라미터 우선권, 콘텍스트 데이터(contextual data)에 기초하여 적절한 파라미터를 결정하는 규칙 세트, 또는 당업자에게 알려져 있는 다른 방법에 기초하여 이루어질 수 있다.
다음으로, 스텝 715에서, 클라우드 컴퓨팅 게이트웨이는 선택된 파라미터가 조정되어야 하는 방식을 결정할 수 있다. 예를 들어, 클라우드 컴퓨팅 게이트웨이는 선택된 파라미터와 관련된 예측 모델을 사용하여 그 파라미터에 대한 어떤 변경으로 인하여 모듈이 목표 교체 날짜를 충족하게 될 것인지를 결정할 수 있다. 예를 들어, 예측 모델은 모듈의 CPU들을 200MHz만큼 오버 클러킹하는 것, 10%만큼 쿨링을 저감하는 것, 각 CPU가 활성인 시간 비율을 10%만큼 증가시키는 것으로 인하여 모듈이 목표 교체 날짜에 근접하여 고장나게 될 것이라는 것을 나타낼 수 있다. 이어서, 스텝 725에서, 클라우드 컴퓨팅 게이트웨이는 파라미터 값이 허용될 수 있는지의 여부를 결정할 수 있다. 예를 들어, 파라미터 값이 불가능하거나 비현실적인 경우, 그것은 허용되지 않을 수 있다. 예를 들어, 모듈은 특정 레벨을 지나 안전하게 전압을 증가시킬 수 없을 수도 있다. 다른 예로서, CPU들의 현재 부하가 이미 낮은 경우에는, CPU를 오버 클러킹하는 것이 비현실적일 수 있다. 파라미터 값이 허용 불가능한 경우, 방법은 스텝 730으로 진행할 수도 있다.
스텝 730에서, 클라우드 컴퓨팅 게이트웨이는 다른 조정을 결정할 수도 있다. 예를 들어, 클라우드 컴퓨팅 게이트웨이는 현재의 값과 스텝 715에서 결정된 값 사이의 어느 파라미터 값을 선택할 수도 있다. 다르게는, 클라우드 컴퓨팅 게이트웨이는 파라미터가 전혀 조정될 필요가 없는 것으로 결정할 수도 있다. 다음으로, 스텝 735에서, 파라미터가 다른 값으로 조정되어야 할 경우, 클라우드 컴퓨팅 게이트웨이는 이러한 파라미터 조정을 행할 수도 있다. 그러나, 다른 조정이 사용되었기 때문에, 모듈은 아직 목표 교체 날짜를 충족하도록 구성될 수 없을 수도 있다. 따라서, 방법(700)은 스텝 710으로 루프백될 수 있고, 상이한 파라미터를 가진 프로세스를 반복할 수 있다. 이와 같이, 클라우드 컴퓨팅 게이트웨이는 복수의 파라미터들을 조정함으로써 모듈이 목표 교체 날짜 근방에서 소모되는 것을 보장할 수 있다.
스텝 725에서 모듈이 목표 교체 날짜를 충족시키기에 충분하게 될 허용가능한 파라미터 조정을 클라우드 컴퓨팅 게이트웨이가 식별하는 경우, 방법(700)은 스텝 740으로 진행할 수 있다. 스텝 740에서, 클라우드 컴퓨팅 게이트웨이가 파라미터 조정을 행할 수 있으며, 방법(700)은 스텝 745에서 종료되는 것으로 진행할 수 있다.
전술한 바에 따르면, 각종 실시예들은 사용가능한 전체 리소스들에 대한 고장난 하드웨어 리소스의 영향을 제한하는 하드웨어 아키텍처를 가능하게 한다. 특히, 고장난 하드웨어 컴포넌트들을 선택적으로 비활성화시키거나 폐기할 수 있는 하드웨어 모듈들을 제공하는 것에 의해, 일 유닛으로서 하드웨어 모듈들이 지속적으로 작동할 수 있다. 또한, 이러한 하드웨어 모듈들의 상태를 모니터링하고 그 하드웨어 컴포넌트들의 작동 파라미터들을 조정하는 것에 의해, 하드웨어 시스템은 하드웨어 모듈들이 목표 교체 날짜 근방에서 완전히 소모되는 것을 보장할 수 있다.
본 발명의 각종 예시적 실시예들은 하드웨어, 소프트웨어, 및/또는 펌웨어로 구현될 수 있음은 전술한 설명으로부터 명백하다. 또한, 각종 예시적 실시예들은 적어도 하나의 프로세서에 의해 본 명세서의 상세하게 기술된 동작들을 수행하도록 판독 및 실행될 수 있는, 머신 판독가능 스토리지 매체에 저장된 명령들로 구현될 수도 있다. 머신 판독가능 스토리지 매체는 퍼스널 또는 랩탑 컴퓨터, 서버, 또는 다른 컴퓨팅 디바이스와 같은 머신에 의해 판독가능한 형태로 정보를 저장하는 임의의 메커니즘을 포함할 수도 있다. 따라서, 유형의 비-일시적 머신 판독가능 스토리지 매체는 ROM(read-only memory), RAM(random-access memory), 자기 디스크 스토리지 매체, 광 스토리지 매체, 플래시-메모리 디바이스들, 및 유사 스토리지 매체를 포함할 수 있다.
본 명세서의 블록도는 본 발명의 원리를 구현하는 예시적 회로의 개념도들을 제공하는 것임이 당업자에게는 인식될 것이다. 마찬가지로, 임의의 플로 차트, 흐름도, 상태 변형도, 의사 코드 등은 컴퓨터 또는 프로세서가 명시적으로 도시되어 있는지의 여부와 관계없이, 머신 판독가능 매체에 실질적으로 제공되며 그러한 컴퓨터 또는 프로세서에 의해 실행될 수 있는 각종 프로세스들을 제공하는 것임이 인식될 것이다.
소정 예시적 양태들에 대한 특정한 참조에 의해 각종 예시적 실시예들을 기술하였지만, 본 발명은 다른 실시예들을 가질 수 있으며 그것의 상세들이 여러 가지 명백한 점들에서의 변형들을 가질 수 있음이 이해되어야 한다. 당업자에게는 용이하게 명백한 바와 같이, 본 발명의 사상 및 범위 내에 있으면서 변형 및 수정이 이루어질 수 있다. 따라서, 전술한 개시 내용, 설명, 및 도면들은 단지 예시의 목적을 위한 것이고, 어떤 방식으로도 본 발명을 제한하지 않으며, 본 발명은 청구항들에 의해서만 정의된다.

Claims (15)

  1. 하드웨어 시스템의 점진적 고장을 가능하게 하도록 하드웨어 관리 디바이스에 의해 수행되는 방법으로서,
    상기 하드웨어 시스템은 하드웨어 모듈을 포함하고, 상기 하드웨어 모듈은 복수의 하드웨어 컴포넌트들이 장착된 회로 기판을 포함하며, 상기 방법은,
    상기 복수의 하드웨어 컴포넌트들 중의 고장난 컴포넌트의 하드웨어 고장을 식별하는 단계(310)와,
    현재 상기 고장난 컴포넌트를 사용하도록 구성된 에이전트 디바이스들의 세트를 결정하는 단계(315)와,
    상기 에이전트 디바이스들의 세트 중의 적어도 하나의 에이전트 디바이스에 대해, 상기 고장난 컴포넌트를 대신하여 상기 복수의 하드웨어 컴포넌트들 중의 작동중인 컴포넌트를 사용하도록 상기 에이전트 디바이스를 재구성하는 단계(320)와,
    상기 고장난 컴포넌트를 비활성화하는 단계(325)－상기 복수의 하드웨어 컴포넌트들 중의 다른 하드웨어 컴포넌트들은 계속해서 작동함－를 포함하는
    방법.
  2. 제 1 항에 있어서,
    상기 복수의 하드웨어 컴포넌트들 중의 적어도 하나의 다른 하드웨어 컴포넌트들에 지속적으로 전력을 제공하면서, 상기 고장난 컴포넌트의 전원을 차단하도록 상기 하드웨어 모듈을 재구성하는 단계를 더 포함하는
    방법.
  3. 제 1 항 또는 제 2 항에 있어서,
    상기 회로 기판에 장착된 모든 하드웨어 컴포넌트들은 단일 타입의 하드웨어 컴포넌트인
    방법.
  4. 제 1 항 내지 제 3 항 중 어느 한 항에 있어서,
    상기 하드웨어 관리 디바이스는 하이퍼바이저(hypervisor)를 포함하며, 상기 하드웨어 관리 디바이스는 작동을 위하여 상기 복수의 하드웨어 컴포넌트들 중의 적어도 하나의 컴포넌트를 사용하는
    방법.
  5. 제 1 항 내지 제 4 항 중 어느 한 항에 있어서,
    상기 하드웨어 관리 디바이스는 클라우드 컴퓨팅 게이트웨이 디바이스를 포함하며,
    상기 하드웨어 관리 디바이스는 복수의 하이퍼바이저들을 관리하고,
    상기 복수의 하이퍼바이저들 중의 제 1 하이퍼바이저는 상기 복수의 하드웨어 컴포넌트들을 관리하는
    방법.
  6. 제 5 항에 있어서,
    상기 에이전트 디바이스들의 세트 중의 적어도 하나의 에이전트 디바이스에 대해, 상기 복수의 하이퍼바이저들 중의 제 2 하이퍼바이저에 의해 관리되도록 상기 에이전트 디바이스를 재구성하는 단계를 더 포함하는
    방법.
  7. 제 1 항 내지 제 6 항 중 어느 한 항에 있어서,
    상기 하드웨어 모듈에 대한 고장 날짜를 예측(projecting)하는 단계(650)와,
    상기 하드웨어 모듈에 대한 목표 교체 날짜에 기초하여 상기 예측된 고장 날짜가 허용 가능한지의 여부를 결정하는 단계(655)와,
    상기 예측된 고장 날짜가 허용 가능하지 않은 경우,
    상기 복수의 하드웨어 컴포넌트들 중의 적어도 하나의 하드웨어 컴포넌트에 대한 적어도 하나의 파라미터 조정을 결정하는 단계(710)－상기 적어도 하나의 파라미터 조정은 상기 예측된 고장 날짜를 상기 목표 교체 날짜에 더 근접하게 이동시키도록 선택됨－와,
    상기 복수의 하드웨어 컴포넌트들 중의 상기 적어도 하나의 하드웨어 컴포넌트에 대해 상기 적어도 하나의 파라미터 조정을 적용하는 단계(740)를 더 포함하는
    방법.
  8. 제 7 항에 있어서,
    상기 적어도 하나의 파라미터 조정은 상기 하드웨어 모듈이 상기 예측된 고장 날짜보다 더 일찍 고장나게 되도록 선택되는
    방법.
  9. 제 7 항 또는 제 8 항에 있어서,
    상기 하드웨어 관리 디바이스는 복수의 하드웨어 모듈들을 관리하고, 각각의 하드웨어 모듈은 현재의 수명 단계(life phase)와 관련되며, 상기 방법은,
    에이전트 디바이스의 설정(establishment)에 대한 요청을 수신하는 단계와,
    상기 요청과 관련된 수명 단계 허가를 결정하는 단계－상기 수명 단계 허가는 허가된 수명 단계를 가진 모듈이 상기 요청을 이행하도록 사용되어야 한다는 것을 나타냄－와,
    상기 복수의 하드웨어 모듈 중에서 하드웨어 모듈을 선택하는 단계－상기 선택된 하드웨어 모듈은 상기 허가된 수명 단계와 관련됨－와,
    상기 선택된 하드웨어 모듈을 사용하여 상기 요청을 이행하는 단계를 더 포함하는
    방법.
  10. 점진적 하드웨어 고장이 가능한 하드웨어 시스템으로서,
    회로 기판(260, 270, 280)과,
    상기 회로 기판에 장착된 복수의 하드웨어 컴포넌트들(262, 272, 274, 286)과,
    상기 복수의 하드웨어 컴포넌트들(262, 272, 274, 286) 중의 적어도 하나의 하드웨어 컴포넌트를 사용하도록 구성된 적어도 하나의 에이전트 디바이스와,
    런 타임(run time) 동안, 상기 복수의 하드웨어 컴포넌트들 중의 적어도 하나의 하드웨어 컴포넌트를 비활성화시키는 한편 상기 복수의 하드웨어 컴포넌트들 중의 적어도 하나의 나머지 컴포넌트는 계속 작동하게 하는 관리 디바이스(140a, 140b)를 포함하는
    하드웨어 시스템.
  11. 제 10 항에 있어서,
    상기 적어도 하나의 하드웨어 컴포넌트를 비활성화시킴에 있어서, 상기 관리 디바이스(140a, 140b)는 상기 적어도 하나의 컴포넌트의 전원을 차단하도록 상기 회로 기판(260, 270, 280)을 재구성하는
    하드웨어 시스템.
  12. 제 10 항 또는 제 11 항에 있어서,
    상기 관리 디바이스(140a, 140b)는 하이퍼바이저를 포함하며, 상기 관리 디바이스는 상기 복수의 하드웨어 컴포넌트들 중의 적어도 하나의 하드웨어 컴포넌트를 사용하는
    하드웨어 시스템.
  13. 제 10 항 내지 제 12 항 중의 어느 한 항에 있어서,
    상기 회로 기판에 장착된 모든 하드웨어 컴포넌트들은 동일 타입인
    하드웨어 시스템.
  14. 제 10 항 내지 제 13 항 중 어느 한 항에 있어서,
    상기 적어도 하나의 하드웨어 컴포넌트를 비활성화시킴에 있어서, 상기 관리 디바이스(140a, 140b)는,
    상기 적어도 하나의 하드웨어 컴포넌트를 사용하도록 구성된 에이전트 디바이스들의 세트를 식별하고,
    상기 적어도 하나의 하드웨어 컴포넌트 대신에 상기 적어도 하나의 나머지 컴포넌트를 사용하도록 상기 에이전트 디바이스들의 세트 중의 적어도 하나의 에이전트 디바이스를 재구성하는
    하드웨어 시스템.
  15. 제 10 항 내지 제 14 항 중 어느 한 항에 있어서,
    상기 관리 디바이스(140a, 140b)는 상기 복수의 하드웨어 컴포넌트들(262, 272, 274, 286) 중의 상기 적어도 하나의 하드웨어 컴포넌트가 고장났다는 결정에 응답하여 상기 적어도 하나의 하드웨어 컴포넌트를 비활성화시키는
    하드웨어 시스템.
KR1020147008287A 2011-09-30 2012-09-11 하드웨어 소모 아키텍처 KR20140056371A (ko)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US13/250,188 2011-09-30
US13/250,188 US9183102B2 (en) 2011-09-30 2011-09-30 Hardware consumption architecture
PCT/US2012/054606 WO2013048721A1 (en) 2011-09-30 2012-09-11 Hardware consumption architecture

Publications (1)

Publication Number Publication Date
KR20140056371A true KR20140056371A (ko) 2014-05-09

Family

ID=46981089

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020147008287A KR20140056371A (ko) 2011-09-30 2012-09-11 하드웨어 소모 아키텍처

Country Status (7)

Country Link
US (1) US9183102B2 (ko)
EP (1) EP2761458A1 (ko)
JP (1) JP2014531690A (ko)
KR (1) KR20140056371A (ko)
CN (1) CN103858108A (ko)
IN (1) IN2014DN02025A (ko)
WO (1) WO2013048721A1 (ko)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20150120915A (ko) * 2015-10-08 2015-10-28 (주)와치텍 효율적인 데이터 수집 관리를 위한 Active-Active-Active 방식의 시스템 분산 아키텍쳐
WO2017023310A1 (en) * 2015-08-05 2017-02-09 Hewlett Packard Enterprise Development Lp Selecting hardware combinations

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140096139A1 (en) * 2012-10-01 2014-04-03 International Business Machines Corporation Workload management considering hardware reliability
US8996932B2 (en) * 2013-01-09 2015-03-31 Microsoft Technology Licensing, Llc Cloud management using a component health model
US9571372B1 (en) * 2013-01-24 2017-02-14 Symantec Corporation Systems and methods for estimating ages of network devices
US10613954B1 (en) * 2013-07-01 2020-04-07 Amazon Technologies, Inc. Testing framework for host computing devices
US10157100B2 (en) * 2014-04-30 2018-12-18 Hewlett Packard Enterprise Development Lp Support action based self learning and analytics for datacenter device hardware/firmare fault management
CN104363119A (zh) * 2014-11-13 2015-02-18 浪潮(北京)电子信息产业有限公司 一种多单元刀片服务器管理方法及设备
US10171560B2 (en) * 2015-01-05 2019-01-01 International Business Machines Corporation Modular framework to integrate service management systems and cloud orchestrators in a hybrid cloud environment
US10142401B2 (en) 2015-04-12 2018-11-27 Nokia Of America Corporation Management of computing infrastructure under emergency peak capacity conditions
CN105007312A (zh) * 2015-07-03 2015-10-28 叶秀兰 一种云计算服务器自适应负载均衡控制方法及控制系统
US20220276905A1 (en) * 2021-02-26 2022-09-01 Microsoft Technology Licensing, Llc Managing computational bursting on server nodes
CN113515364B (zh) * 2021-09-14 2022-03-01 腾讯科技（深圳）有限公司 一种数据迁移的方法及装置、计算机设备和存储介质

Family Cites Families (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5121394A (en) * 1989-12-20 1992-06-09 Bull Hn Information Systems Inc. Method of organizing programmable logic array devices for board testability
US5530302A (en) * 1994-01-13 1996-06-25 Network Systems Corporation Circuit module with hot-swap control circuitry
US5740378A (en) * 1995-08-17 1998-04-14 Videoserver, Inc. Hot swap bus architecture
US5881251A (en) * 1996-10-10 1999-03-09 Bay Networks, Inc. Hot swap control circuit
US5953216A (en) * 1997-08-20 1999-09-14 Micron Technology Method and apparatus for replacing a defective integrated circuit device
US6487624B1 (en) * 1999-08-13 2002-11-26 Hewlett-Packard Company Method and apparatus for hot swapping and bus extension without data corruption
US7251746B2 (en) * 2004-01-21 2007-07-31 International Business Machines Corporation Autonomous fail-over to hot-spare processor using SMI
US7760719B2 (en) * 2004-06-30 2010-07-20 Conexant Systems, Inc. Combined pipelined classification and address search method and apparatus for switching environments
US7404105B2 (en) * 2004-08-16 2008-07-22 International Business Machines Corporation High availability multi-processor system
US7904546B1 (en) * 2004-09-27 2011-03-08 Alcatel-Lucent Usa Inc. Managing processes on a network device
US7423870B2 (en) * 2005-11-18 2008-09-09 International Business Machines Corporation Blade server assembly
DE112005003788T5 (de) * 2005-12-30 2008-09-25 Intel Corp., Santa Clara Dynamische Abschätzung der Lebensdauer einer Halbleitereinrichtung
US7669076B2 (en) * 2006-05-30 2010-02-23 Oracle International Corporation Estimating data availability on managed storage devices
US7493477B2 (en) 2006-06-30 2009-02-17 Intel Corporation Method and apparatus for disabling a processor core based on a number of executions of an application exceeding a threshold
US8291244B2 (en) * 2006-07-28 2012-10-16 Arm Limited Power management in a data processing device having masters and slaves
US7663889B2 (en) * 2006-10-23 2010-02-16 Sun Microsystems, Inc. Mechanism for facilitating hot swap capability
US8238255B2 (en) * 2006-11-22 2012-08-07 Foundry Networks, Llc Recovering from failures without impact on data traffic in a shared bus architecture
JP2008152594A (ja) 2006-12-19 2008-07-03 Hitachi Ltd マルチコアプロセッサ計算機の高信頼化方法
JP4995015B2 (ja) 2007-09-13 2012-08-08 株式会社日立製作所 仮想計算機の実行可否検査方法
US8214467B2 (en) * 2007-12-14 2012-07-03 International Business Machines Corporation Migrating port-specific operating parameters during blade server failover
US8266415B2 (en) * 2008-02-26 2012-09-11 Broadcom Corporation Electronic device board level security
US7966519B1 (en) * 2008-04-30 2011-06-21 Hewlett-Packard Development Company, L.P. Reconfiguration in a multi-core processor system with configurable isolation
TWI446153B (zh) * 2008-05-09 2014-07-21 Asustek Comp Inc 用以控制電子裝置關機之方法、元件以及電路板
KR20110050404A (ko) * 2008-05-16 2011-05-13 퓨전-아이오, 인크. 결함 있는 데이터 저장소를 검출하고 교체하는 장치, 시스템 및 프로그램 제품
EP2439641B1 (en) 2009-06-01 2016-10-12 Fujitsu Limited Server control program, control server, virtual server distribution method
JP2011128967A (ja) 2009-12-18 2011-06-30 Hitachi Ltd 仮想計算機の移動方法、仮想計算機システム及びプログラム
JP5487951B2 (ja) 2009-12-22 2014-05-14 富士通株式会社 運用管理プログラム、運用管理装置および運用管理方法
US8224957B2 (en) * 2010-05-20 2012-07-17 International Business Machines Corporation Migrating virtual machines among networked servers upon detection of degrading network link operation
US8788218B2 (en) * 2011-01-21 2014-07-22 The United States Of America As Represented By The Secretary Of The Navy Event detection system having multiple sensor systems in cooperation with an impact detection system

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017023310A1 (en) * 2015-08-05 2017-02-09 Hewlett Packard Enterprise Development Lp Selecting hardware combinations
KR20150120915A (ko) * 2015-10-08 2015-10-28 (주)와치텍 효율적인 데이터 수집 관리를 위한 Active-Active-Active 방식의 시스템 분산 아키텍쳐

Also Published As

Publication number Publication date
EP2761458A1 (en) 2014-08-06
WO2013048721A1 (en) 2013-04-04
IN2014DN02025A (ko) 2015-05-15
US20130086411A1 (en) 2013-04-04
CN103858108A (zh) 2014-06-11
US9183102B2 (en) 2015-11-10
JP2014531690A (ja) 2014-11-27

Similar Documents

Publication Publication Date Title
KR20140056371A (ko) 하드웨어 소모 아키텍처
CN110249310B (zh) 云计算系统中的用于虚拟机的资源管理
CN110249311B (zh) 云计算系统中针对虚拟机的资源管理
US9870159B2 (en) Solid-state disk (SSD) management
US20190319881A1 (en) Traffic management based on past traffic arrival patterns
US9720763B2 (en) Proactive cloud orchestration
JP2006079602A (ja) プロアクティブメンテナンスを有する高可用性クラスタ
JP2015522876A (ja) クラウドベースアプリケーションの単一障害点の排除のための、方法および装置
JP2004110791A (ja) ブレードアーキテクチャのための動的適応サーバプロビジョニング
KR20140008363A (ko) 비-간섭적 전력 관리
JP5659894B2 (ja) ソフトウェア更新装置、ソフトウェア更新方法、及びソフトウェア更新プログラム
JP2008532170A (ja) コンピュータｑｃモジュールテストモニタ
US10133330B2 (en) Cluster system, controller, method for controlling, and computer-readable recording medium having stored therein controlling program that operate node at the combination of the respective load setting values that satisfy required performance and lowers power consumption
US10565012B2 (en) System interventions based on expected impacts of system events on schedule work units
CN115427934A (zh) 管理用于虚拟机池的电力资源
WO2013048750A1 (en) Live module diagnostic testing
EP4080924B1 (en) Injecting analytics into network repository function (nrf) for automated management of 5g
US20170251433A1 (en) System power management and optimization in telecommunication systems
JP5257709B2 (ja) 仮想計算機の移動方法、仮想計算機システム及び管理サーバ
US20170208121A1 (en) Server pool management
JP6561766B2 (ja) 情報処理装置、クラスタシステム、クラスタリング方法、及びプログラム
US20160224378A1 (en) Method to control deployment of a program across a cluster of machines
US10877539B2 (en) System and method to prevent power supply failures based on data center environmental behavior
JP5699589B2 (ja) 処理割り当て装置、処理割り当てシステム、処理割り当て方法、処理割り当てプログラム
US20230401085A1 (en) Selection of hosts for virtual machines based on current virtual machine requirements and headroom availability

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E601 Decision to refuse application