KR20150008446A - 클라우드 기반 애플리케이션에 대한 단일 장애점 제거를 위한 방법 및 장치 - Google Patents

클라우드 기반 애플리케이션에 대한 단일 장애점 제거를 위한 방법 및 장치 Download PDF

Info

Publication number
KR20150008446A
KR20150008446A KR1020147034070A KR20147034070A KR20150008446A KR 20150008446 A KR20150008446 A KR 20150008446A KR 1020147034070 A KR1020147034070 A KR 1020147034070A KR 20147034070 A KR20147034070 A KR 20147034070A KR 20150008446 A KR20150008446 A KR 20150008446A
Authority
KR
South Korea
Prior art keywords
network
distribution
rules
component
resource
Prior art date
Application number
KR1020147034070A
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 KR20150008446A publication Critical patent/KR20150008446A/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/14—Error detection or correction of the data by redundancy in operation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3442—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for planning or managing the needed capacity
    • 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

Abstract

다양한 실시예는 신속한 탄력성, 예를 들어, 소프트웨어/펌웨어/하드웨어 업그레이드, 업데이트, 재조절 및 증가와 같은 인프라스트럭처 유지 보수, 및 예를 들어, 팬 필터 클리닝과 고장난 하드웨어 컴포넌트 교체와 같은 예방적인 유지 보수를 지원하는 룰을 제공하는 클라우드 기반 애플리케이션에 대한 SPOF 제거를 제공하는 방법 및 장치를 제공한다. 특히, 본 방법과 장치에 의해 제공되는 SPOF 제거는 호스트 인스턴스 매핑에 대한 VM에 추가하여 네트워크 아키텍처 및 영구 스토리지 고려사항에 기반한다.

Description

클라우드 기반 애플리케이션에 대한 단일 장애점 제거를 위한 방법 및 장치{METHOD AND APPARATUS FOR SINGLE POINT OF FAILURE ELIMINATION FOR CLOUD-BASED APPLICATIONS}
본 발명은 일반적으로 클라우드 기반 애플리케이션에 대한 단일 장애점(single point of failure) 제거를 제공하기 위한 방법 및 장치에 관한 것이다.
본 섹션은 본 발명의 더 나은 이해를 촉진하는 데 도움이 될 수 있는 양태를 소개한다. 따라서, 본 섹션의 설명은 이러한 관점에서 읽혀져야 하며, 어떠한 것이 종래 기술에 있는 것이며, 어떠한 것이 종래 기술에 있는 것이 아닌지에 대한 승인으로서 이해되어서는 안 된다.
일부 알려진 고가용성 시스템에서, 네트워크 아키텍처는, 예견된 네트워크 내에 어떠한 SPOF(single point of failure)도 존재하지 않는 것을 보장하기 위하여 충분한 리던던시를 포함하도록 분명하게 설계된다. 일부 알려진 클라우드 기반 시스템에서, 애플리케이션 VM(Virtual Machine) 인스턴스와 물리적 호스트 매핑 간에 "SPOF 없음"을 보장하기 위해 안티 어피니티(anti-affinity) 룰이 적용된다.
다양한 실시예는 신속한 탄력성 및 인프라스트럭처 증가를 지원하는 룰을 제공하는 클라우드 기반 애플리케이션에 대한 SPOF 제거를 제공하는 방법 및 장치를 제공한다. 특히, 본 방법 및 장치에 의해 제공되는 SPOF 제거는 호스트 인스턴스 매핑에 대한 VM에 추가하여 네트워크 아키텍처 및 영구 스토리지 고려사항에 기반한다.
일 실시예에서, 장치는 단일 장애점 제거를 제공하기 위해 제공된다. 장치는 데이터 스토리지 및 상기 데이터 스토리지에 통신가능하게 접속된 프로세서를 포함한다. 프로세서는, 하나 이상의 애플리케이션 리소스 요건을 결정하고; 리소스 풀 및 상기 리소스 풀과 연관된 네트워크 아키텍처를 결정하고; 하나 이상의 룰을 결정하고; 상기 하나 이상의 애플리케이션 리소스 요건, 상기 리소스 풀, 상기 네트워크 아키텍처 및 상기 하나 이상의 룰에 기초하여 하나 이상의 컴포넌트 인스턴스의 분배를 결정하도록 프로그램된다.
상술한 실시예 중 임의의 것에서, 상기 프로세서는, 하나 이상의 링크 및 노드의 네트워크 상태를 결정하고, 상기 하나 이상의 컴포넌트 인스턴스의 분배의 결정은 상기 네트워크 상태에 추가로 기초하도록 추가로 프로그램된다.
제 2 실시예에서, 단일 장애점 제거를 제공하기 위한 시스템이 제공된다. 시스템은 하나 이상의 데이터 센터를 포함하며, 하나 이상의 데이터 센터는 복수의 데이터 센터에 통신가능하게 접속된 리소스 풀 및 클라우드 관리자를 포함한다. 클라우드 관리자는, 하나 이상의 애플리케이션 리소스 요건을 결정하고; 리소스 풀 및 상기 리소스 풀과 연관된 네트워크 아키텍처를 결정하고; 하나 이상의 룰을 결정하고; 상기 하나 이상의 애플리케이션 리소스 요건, 상기 리소스 풀, 상기 네트워크 아키텍처 및 상기 하나 이상의 룰에 기초하여 하나 이상의 컴포넌트 인스턴스의 분배를 결정하도록 프로그램된다.
제 3 실시예에서, 단일 장애점 제거를 제공하기 위한 방법이 제공된다. 본 방법은, 분배 트리거가 발생했다는 것을 결정하는 단계; 하나 이상의 애플리케이션 리소스 요건을 결정하는 단계; 리소스 풀 및 상기 리소스 풀과 연관된 네트워크 아키텍처를 결정하는 단계; 하나 이상의 룰을 결정하는 단계; 상기 분배 트리거, 상기 하나 이상의 애플리케이션 리소스 요건, 상기 리소스 풀, 상기 네트워크 아키텍처 및 상기 하나 이상의 룰에 기초하여 하나 이상의 컴포넌트 인스턴스의 분배를 결정하는 단계를 포함한다.
상술한 실시예 중 임의의 것에서, 분배 트리거는 상기 리소스 풀 내의 하나 이상의 리소스로부터 상기 컴포넌트 인스턴스의 적어도 일부의 이주에 기초한다.
상술한 실시예 중 임의의 것에서, 상기 네트워크 아키텍처를 결정하는 단계는 네트워크 아키텍처 표현을 파싱하는 단계를 포함한다.
상술한 실시예 중 임의의 것에서, 상기 하나 이상의 룰은 하나 이상의 안티 어피니티 룰을 포함하고, 상기 하나 이상의 안티 어피니티 룰을 결정하는 단계는 안티 어피니티 룰 표현을 파싱하는 단계를 포함한다.
상술한 실시예 중 임의의 것에서, 상기 방법은, 하나 이상의 링크 또는 네트워크 노드의 네트워크 상태를 결정하는 단계를 추가로 포함하고, 상기 네트워크 아키텍처는 상기 하나 이상의 링크 또는 네트워크 노드를 포함하고; 상기 하나 이상의 컴포넌트 인스턴스의 분배를 결정하는 단계는 상기 네트워크 상태에 추가로 기초한다.
상술한 실시예 중 임의의 것에서, 상기 네트워크 아키텍처는 제 1 네트워크 디바이스를 포함하고; 상기 하나 이상의 컴포넌트 인스턴스의 분배를 결정하는 단계는, 상기 제 1 네트워크 디바이스의 장애가 하나 이상의 안티-어피니티 룰 중 적어도 하나를 위반할 것이라는 결정에 기초하여, 상기 하나 이상의 컴포넌트 인스턴스 중 제 1 컴포넌트 인스턴스가 상기 리소스 풀 내의 제 1 리소스와 연관되지 않을 수 있다고 결정하는 단계를 포함한다.
상술한 실시예 중 임의의 것에서, 상기 하나 이상의 컴포넌트 인스턴스의 분배를 결정하는 단계는 목적 함수를 사용하는 단계를 포함한다.
상술한 실시예 중 임의의 것에서, 상기 목적 함수는 애플리케이션 액세스 지연을 최소화한다.
상술한 실시예 중 임의의 것에서, 상기 네트워크 아키텍처는 링크 및 네트워크 노드를 포함한다.
상술한 실시예 중 임의의 것에서, 상기 하나 이상의 애플리케이션 리소스 요건은 상기 리소스 풀의 멤버인 하나 이상의 리소스의 현재 할당; 및 애플리케이션과 연관되는 하나 이상의 현재 애플리케이션 리소스 요건을 포함한다.
상술한 실시예 중 임의의 것에서, 상기 하나 이상의 애플리케이션 리소스 요건의 결정은 애플리케이션으로부터 수신된 애플리케이션 리소스 요구에 기초한다.
상술한 실시예 중 임의의 것에서, 상기 하나 이상의 애플리케이션 리소스 요건의 결정은 프로세서가 애플리케이션의 리소스 사용을 감시하도록 프로그램하는 것을 포함한다.
상술한 실시예 중 임의의 것에서, 상기 하나 이상의 룰은 하나 이상의 안티 어피니티 룰을 포함한다.
상술한 실시예 중 임의의 것에서, 상기 하나 이상의 룰은 하나 이상의 비지니스 룰을 추가로 포함한다.
상술한 실시예 중 임의의 것에서, 상기 하나 이상의 비지니스 룰은 유지 보수 액션을 위한 상기 리소스 풀 내의 리소스의 일부의 예약을 포함한다.
상술한 실시예 중 임의의 것에서, 상기 하나 이상의 컴포넌트 인스턴스의 분배의 결정은 장애점의 세트에 추가로 기초한다.
다양한 실시예가 첨부 도면에서 설명되며, 첨부 도면은 이하와 같다:
도 1은 클라우드 기반 애플리케이션에 대한 SPOF 제거 시스템(100)의 실시예를 포함하는 클라우드 네트워크를 나타낸다.
도 2는 도 1의 데이터 센터(150) 및 네트워크(140)의 일부 중 하나의 실시예인 데이터 센터(200A) 및 네트워크(200B)의 일부를 개략적으로 나타낸다.
도 3은 도 1의 SPOF 제거 시스템(100)에서 컴포넌트 인스턴스를 분배하는 클라우드 관리자(예를 들어, 도 1의 클라우드 관리자(130))에 대한 방법(300)의 실시예를 나타내는 흐름도를 도시한다.
도 4는 도 3의 스텝 340에서 나타낸 바와 같이 룰을 결정하기 위한, 클라우드 관리자(예를 들어, 도 1의 클라우드 관리자(130))에 대한 방법(400)의 실시예를 나타내는 흐름도를 도시한다.
도 5a는 컴포넌트 인스턴스 A1 - A2 및 B1 - B4를 필요로 하는 예시적인 애플리케이션의 신뢰도 블록도를 나타낸다.
도 5b는 컴포넌트 인스턴스 A1 - A2 및 B1 - B3의 초기 컴포넌트 인스턴스 할당을 나타낸다.
도 5c는 도 5a의 컴포넌트 인스턴스(500a)의 제 1 예시적인 분배에서의 컴포넌트 인스턴스 B4의 할당을 나타낸다.
도 5d는 도 5a의 컴포넌트 인스턴스(500a)의 제 2 예시적인 분배에서의 컴포넌트 인스턴스 B4의 할당을 나타낸다.
도 6은 도 1의 하나의 클라우드 관리자(130)와 같은 다양한 장치(600)의 실시예를 개략적으로 나타낸다.
이해를 촉진하기 위해, 동일한 참조 부호가 실질적으로 동일하거나 유사한 구조 또는 실질적으로 동일하거나 유사한 기능을 갖는 요소를 지시하는 데 사용되었다.
본 설명 및 도면은 단지 본 발명의 원리를 예시하는 것이다. 본 명세서에 명확하게 설명되거나 도시되지는 않았지만, 본 기술분야의 당업자는 본 발명의 원리를 구현하고 그 범주 내에 포함되는 다양한 구성을 고안할 수 있을 것이라는 것이 이해될 것이다. 본 명세서에서 인용된 모든 예들은 주로 독자가 기술을 넓히기 위해 본 발명자(들)에 의해 기여된 본 발명의 원리 및 개념을 이해하는 것을 돕기 위해 명확하게 교육적인 목적으로만 의도된 것이며, 이렇게 구체적으로 인용된 예 및 조건으로의 한정은 없는 것으로 해석되어야 한다. 또한, 달리 표기되지 않으면(예를 들어, "또는 다른" 또는 "또는 대안으로"), 비배타적 또는을 칭하는 것이다. 또한, 일부 실시예가 새로운 실시예를 형성하기 위해 하나 이상의 다른 실시예와 결합될 수 있으므로, 본 명세서에서 설명된 다양한 실시예는 반드시 상호 배타적인 것은 아니다.
다양한 실시예는 신속한 탄력성, 예를 들어, 소프트웨어/펌웨어/하드웨어 업그레이드, 업데이트, 재조절 및 증가와 같은 인프라스트럭처 유지 보수, 및 예를 들어, 팬 필터 클리닝과 고장난 하드웨어 컴포넌트 교체와 같은 예방적인 유지 보수를 지원하는 룰을 제공하는 클라우드 기반 애플리케이션에 대한 SPOF 제거를 제공하는 방법 및 장치를 제공한다. 특히, 본 방법과 장치에 의해 제공되는 SPOF 제거는 호스트 인스턴스 매핑에 대한 VM에 추가하여 네트워크 아키텍처 및 영구 스토리지 고려사항에 기반한다.
본 명세서에서 사용되는 "SPOF 없음" 및 "SPOF 제거"라는 용어는, 어떠한 단일 컴포넌트 장애도 수용불가능한 서비스 충격을 야기하지 않을 것이라는 것을 의미한다. 예를 들어, 전화 서비스 공급자는 단절된 콜을 수용할 수는 있지만, 연장된 서비스 두절을 수용할 수 없을 수도 있으며, 여기에서, 단절된 콜의 리다이얼은 프라이머리/액티브 서비스 컴포넌트뿐만 아니라 2차적/리던던트 서비스 컴포넌트 양쪽에 의해 영향을 받은 단일 장애 이벤트로 인해 완료될 수 없으므로, 어떠한 컴포넌트도 이용가능하지 않거나 정의된 임계 기간 내에서 사용자 요구를 서빙하기에 충분한 용량을 갖지 못한다. 자동 장애 검출 메커니즘 또는 자동 복구 메커니즘의 장애는 서비스 복구 메커니즘의 동작을 못하게 할 수 있으며, 연장된 서비스 장애로 귀결될 수 있고, "SPOF 없음" 요건의 범주 밖에 있다는 것이 이해되어야 한다.
도 1은 클라우드 기반 애플리케이션에 대한 SPOF 제거 시스템(100)의 실시예를 포함하는 클라우드 네트워크를 나타낸다. SPOF 제거 시스템(100)은 통신 경로를 통해 하나 이상의 데이터 센터(150-1 - 150-n)(총괄적으로, 데이터 센터(150))에 상주하는 하나 이상의 할당된 애플리케이션 인스턴스(명료성을 위해 미도시)에 액세스하는 하나 이상의 클라이언트(120-1 - 120-n)(총괄적으로, 클라이언트(120))를 포함한다. 통신 경로는 적절한 하나의 클라이언트 통신 채널(125-1 - 125-n)(총괄적으로, 클라이언트 통신 채널(125)), 네트워크(140), 및 하나의 데이터 센터 통신 채널(155-1 - 155-n)(총괄적으로, 데이터 센터 통신 채널(155))을 포함한다. 애플리케이션 인스턴스는 클라우드 관리자 통신 채널(135), 네트워크(140) 및 적절한 하나의 데이터 센터 통신 채널(155)을 통해 데이터 센터(150)와 통신하는 클라우드 관리자(130)에 의해 하나 이상의 데이터 센터(150)에 할당된다.
클라이언트(120)는 하나 이상의 클라이언트 통신 채널(125)을 경유하여 네트워크(140)를 통해 정보를 송신 또는 수신할 수 있는 임의의 유형의 통신 디바이스(들)를 포함할 수 있다. 예를 들어, 통신 디바이스는 신 클라이언트(thin client), 스마트 폰(예를 들어, 클라이언트(120-n)), 퍼스널 또는 랩톱 컴퓨터(예를 들어, 클라이언트(120-1)), 서버, 네트워크 디바이스, 태블릿, 텔레비전 세트톱 박스, 미디어 플레이어 등일 수 있다. 통신 디바이스는 프로세싱 또는 저장과 같은 작업의 일부를 수행하기 위해 예시적인 시스템 내의 다른 리소스에 의존할 수 있거나, 독립적으로 작업을 수행할 수 있다. 여기에 2개의 클라이언트를 나타내었지만, 시스템(100)은 더 적거나 더 많은 클라이언트를 포함할 수 있다는 것이 이해되어야 한다. 또한, 클라이언트가 동작 중에 다양한 시간에서 시스템에 추가될 수 있거나 제거될 수 있으므로, 임의의 일 시간에서의 클라이언트의 수는 동적일 수 있다.
통신 채널(125, 135, 155)은 무선 통신(예를 들어, LTE, GSM, CDMA, Bluetooth); WLAN 통신(예를 들어, WiFi); 패킷 네트워크 통신(예를 들어, IP); 브로드밴드 통신(예를 들어, DOCSIS 및 DSL); 스토리지 통신(예를 들어, Fibre Channel, iSCSI) 등과 같은 하나 이상의 통신 채널을 통한 통신을 지원한다. 단일 접속으로서 도시되었지만, 통신 채널(125, 135, 155)은 임의의 수의 통신 채널 또는 그 조합일 수 있다는 것이 이해되어야 한다.
클라우드 관리자(130)는 하나 이상의 애플리케이션 인스턴스에 데이터 센터(150) 내의 리소스를 할당 및 할당해제하는 임의의 장치일 수 있다. 특히, 데이터 센터(150) 내의 리소스의 일부는 컴포넌트 인스턴스를 통해 애플리케이션 인스턴스에 풀링 및 할당된다. 여기에서는 단지 하나의 클라우드 관리자가 나타내어졌지만, 시스템(100)은 더 많은 클라우드 관리자를 포함할 수 있다는 것이 이해되어야 한다.
여기에 사용되는 "컴포넌트 인스턴스"라는 용어는 특정 클라이언트 애플리케이션으로부터의 서비스 요구에 대해 예약된 하나 이상의 할당된 물리적 리소스의 속성을 의미한다. 예를 들어, 할당된 물리적 자원은 프로세싱/컴퓨트, 메모리, 네트워킹, 스토리지 등일 수 있다. 일부 실시예에서, 컴포넌트 인스턴스는 프로세싱/컴퓨트, 메모리 및 네트워킹 리소스를 포함하는 가상 머신일 수 있다. 일부 실시예에서, 컴포넌트 인스턴스는 가상화된 스토리지일 수 있다.
네트워크(140)는 임의의 수의 액세스 및 에지 노드와 네트워크 디바이스와 임의의 수 및 구성의 링크를 포함한다. 또한, 네트워크(140)는 LTE, GSM, CDMA, LAN(Local Area Network(s)), WLAN(Wireless Local Area Network(s)), WAN(Wide Area Network), MAN(Metropolitan Area Network) 등을 포함하는 임의의 수의 무선 또는 유선 네트워크와 임의의 조합을 포함할 수 있다는 것이 이해되어야 한다.
데이터 센터(150)는 지리적으로 분포될 수 있으며, 임의의 유형 또는 구성의 리소스를 포함할 수 있다. 리소스는 클라이언트(120)로부터의 애플리케이션 요구를 서비스하기 위하여 애플리케이션 인스턴스에 의해 이용되는 임의의 적절한 디바이스일 수 있다. 예를 들어, 리소스는 서버, 프로세서 코어, 메모리 디바이스, 스토리지 디바이스, 네트워킹 디바이스 등일 수 있다.
일부 실시예에서, 클라우드 관리자(130)는 계층적 구성의 클라우드 관리자일 수 있다.
도 2는 도 1의 하나의 데이터 센터(150)와 네트워크(140)의 일부의 실시예인 데이터 센터(200A) 및 네트워크(200B)의 일부를 개략적으로 나타낸다. 데이터 센터(200A)는 리소스(220-1-1-1 - 220-y-z-5)(총괄적으로, 리소스(220))를 포함한다. 리소스(220)는 "y" 행으로 배열되며, 각 행은 통신 경로를 통해 액세스되는 리소스의 랙(예를 들어, 랙(205))의 수(예를 들어, 예시적으로 "x" 또는 "y")를 포함한다. 통신 경로는 적절한 하나의 랙 스위치의 톱(210-1-1 - 210-y-z)(총괄적으로, TOR 스위치(210)), 적절한 하나의 행 스위치의 단부(240-1 - 240-n)(총괄적으로, EOR 스위치(240)), 적절한 하나의 레이어 2 집합 스위치(250-1 - 250-n)(총괄적으로, 집합 스위치(250)) 및 적절한 링크(230-1 - 230-2)(총괄적으로, 링크(230))(나머지 링크 라벨은 명료성을 위해 생략하였음)를 통해 리소스(220)와 네트워크(200B)를 통신가능하게 접속시킨다. 데이터 센터(200A)와 네트워크(200B) 사이의 통신은 하나의 집합 스위치(250), 적절한 하나의 라우터(260-1 - 260-3)(총괄적으로, 라우터(260)) 및 적절한 링크(230)를 통한다. 데이터 센터는 임의의 적절한 구성으로 구조화될 수 있으며, 데이터 센터(200A)는 예시적인 목적을 위해 사용되는 단지 하나의 예시적인 아키텍처라는 것이 이해되어야 한다. 예를 들어, 통신 경로는 리소스(220)와 네트워크(200B) 간 데이터를 스위칭하는 디바이스(예를 들어, 스위치, 라우터, 허브 등)의 임의의 적절한 구성을 포함할 수 있다.
TOR 스위치(210)는 연관된 랙 내의 리소스와 적절한 EOR 스위치 간 데이터를 스위칭한다. 예를 들어, TOR 스위치(210-1-1)는 적절한 EOR 스위치(예를 들어, EOR 스위치(240-1))를 통해 랙(205) 내의 리소스로부터 네트워크(200B)로 데이터를 스위칭한다.
리소스(220)는 여기에 설명된 바와 같은 임의의 적절한 디바이스일 수 있다. 5개의 리소스가 각 랙(예를 들어, 랙(205))에서 나타내어졌지만, 각 랙은 더 적거나 더 많은 리소스를 포함할 수 있고 각 랙은 상이한 유형 또는 수의 리소스를 포함할 수 있다는 것이 이해되어야 한다.
나타낸 바와 같이, 각 리소스(220)는 행-열-리소스 번호 명명법을 사용하여 라벨링된다. 예를 들어, 리소스 220-2-3-4는 두번째 행과 세번째 열에 상주하는 랙 내의 네번째 리소스일 것이다.
EOR 스위치(240)는 연관된 TOR 스위치와 적절한 집합 스위치 간 데이터를 스위칭한다. 예를 들어, EOR 스위치(240-1)는 적절한 집합 스위치(예를 들어, 집합 스위치(250-1 또는 250-2))를 통해 TOR 스위치(210-1-1 - 210-1-x)로부터 네트워크(200B)로 데이터를 스위칭한다.
집합 스위치(250)는 EOR 스위치(예를 들어, 랙(205))와 적절한 라우터 간 데이터를 스위칭한다. 예를 들어, TOR 스위치(210-1-1)는 적절한 EOR 스위치(예를 들어, EOR 스위치(240-1)) 및 적절한 집합 스위치(예를 들어, 집합 스위치(250-1 또는 250-2))를 통해 랙(205) 내의 리소스로부터 네트워크(200B)로 데이터를 스위칭한다.
라우터(260)는 적절한 집합 스위치를 통해 네트워크(200B)와 데이터 센터(200A) 간 데이터를 스위칭한다. 예를 들어, 라우터(260-1)는 집합 스위치(250-1)를 통해 네트워크(200B)로부터 데이터 센터(200A)로 데이터를 스위칭한다.
일부 실시예에서, TOR 스위치(220) 또는 EOR 스위치(240)는 Ethernet 스위치이다.
일부 실시예에서, TOR 스위치(220) 또는 EOR 스위치(240)는 리던던트가 되도록 배열될 수 있다. 예를 들어, 랙(205)은 2개 이상의 TOR 스위치(210)에 의해 서비스될 수 있다.
일부 실시예에서, 집합 스위치(250)는 레이어 2 Ethernet 스위치이다.
도 3은 도 1의 SPOF 제거 시스템(100)에서의 컴포넌트 인스턴스를 분배하는(예를 들어, 할당 또는 할당해제) 클라우드 관리자(예를 들어, 도 1의 클라우드 관리자(130))에 대한 방법(300)의 실시예를 나타내는 흐름도를 도시한다. 본 방법은, 분배 트리거가 발생했음을 결정할 시에(스텝 310), (ⅰ) 결정된 리소스 풀 및 풀의 연관된 네트워크 아키텍처(스텝 320); (ⅱ) 결정된 애플리케이션 리소스 요건(스텝 330); 및 (ⅲ) 결정된 룰의 세트(스텝 340)에 기초하여 컴포넌트 인스턴스의 분배가 수정되어야 하는지를 결정하는 것(스텝 350)을 포함한다. 그러면, 본 방법을 수행하는 본 장치는 컴포넌트 인스턴스의 분배가 수정되어야 하는지의 결정에 기초하여 리소스에 대한 컴포넌트 인스턴스의 분배를 결정하고 컴포넌트 인스턴스를 할당 또는 할당해제한다(스텝 360).
방법(300)에서, 스텝(310)은 분배 트리거가 발생했는지를 결정하는 것을 포함한다. 트리거 결정에 기초하여, 본 방법은 스텝 320, 330 및 340으로 진행하거나 복귀한다(스텝 395). 트리거는 컴포넌트 인스턴스의 분배가 수정되어야 한다는 것을 시그널링하는 임의의 적절한 이벤트일 수 있다. 예를 들어, 트리거 이벤트는 (a) 임계 간격에서 주기적으로 트리거링될 수 있고; (b) (예를 들어, 애플리케이션을 기동하기 위한) 초기 리소스 할당 요구; (c) 애플리케이션 용량을 증가시키기 위한 추가적인 리소스의 요구; (d) 애플리케이션 용량을 축소시키기 위한 리소스의 축소에 대한 요구; (e) 가상화된 디스크 구성을 통해 VM 로드 또는 스토리지 할당을 통합/밸런싱할 때와 같이, XaaS 동작 중 클라우드 리소스를 이주/재구성하는 때; (f) (예를 들어, 펌웨어, 하드웨어 또는 운영 체제를 업그레이드시키기 위해 서버(들)를 오프라인으로 하기 전에) 서버 또는 인프라스트럭처 상의 유지 보수 액션을 위한 준비; (g) 돈을 절약하기 위해 과잉 용량이 오프될 수 있도록 낮은 사용 기간(예를 들어, 한밤중)에서 더 적은 수의 서버로의 애플리케이션 통합과 같은 루틴 동작; (h) VM 스냅숏을 활성/재개하는 때; (i) 장애에 후속하는 가상 리소스(예를 들어, VM의 가상 리소스, 스토리지)를 재개/복구/재할당하는 때(예를 들어, 장애로 인해 멈춘 하나를 교체하기 위해 새로운 컴포넌트 인스턴스를 생성); (j) 기타일 수 있다. 복수의 트리거 이벤트가 동시에 발생할 수 있다는 것이 이해되어야 한다.
방법(300)에서, 스텝 320은 리소스 풀과 리소스 풀의 연관된 네트워크 아키텍처를 결정하는 것을 포함한다. 특히, 리소스 풀(예를 들어, 도 2의 리소스(200))과 풀의 연관된 네트워크 아키텍처(예를 들어, 도 2의 TOR 스위치(210), 링크(230), EOR 스위치(240), 집합 스위치(250) 및 라우터(260))가 결정된다.
방법(300)에서, 스텝 330은 애플리케이션의 리소스 요건을 결정하는 것을 포함한다. 특히, 본 방법을 수행하는 장치는 (ⅰ) 애플리케이션에 대한 리소스의 현재 할당; 및 (ⅱ) 애플리케이션의 현재 애플리케이션 리소스 요건을 결정한다. 일부 실시예에서, 리소스의 현재 할당의 결정은 컴포넌트 인스턴스의 현재 분배에 기초할 수 있다.
방법(300)에서, 스텝 340은 룰을 결정하는 것을 포함한다. 특히, 안티 어피니티 룰은 "SPOF 없음"을 충족시키기 위한 컴포넌트 인스턴스의 분배에 대한 제약 요건을 제공한다.
유리하게는, 2개의 애플리케이션 인스턴스가 독립적인 하드웨어 플랫폼에 설치될 때에도, 컴포넌트 인스턴스에 안티 어피니티 룰을 적용함으로써 본 방법을 수행하는 장치는 다양한 리소스(예를 들어, 영구 스토리지 디바이스)에 "SPOF 없음" 요건을 적용할 수 있다.
방법(300)에서, 스텝 350은 컴포넌트 인스턴스의 분배가 수정되어야 하는지, 그리고 수정되어야 한다면 컴포넌트 인스턴스의 "SPOF 없음" 준수 분배가 가능한지에 대해 결정하는 것을 포함한다. 특히, 이러한 결정은 (ⅰ) 스텝 320에서 결정된 리소스 풀 및 풀의 연관된 네트워크 아키텍처, (ⅱ) 스텝 330에서 결정된 애플리케이션 리소스 요건, (ⅲ) 스텝 340에서 결정된 룰에 기초한다.
본 방법을 수행하는 장치는 하나 이상의 리소스에 대한 할당 또는 할당해제된 컴포넌트 인스턴스의 복수의 분배를 분석할 수 있고, 이러한 리소스는 로컬 또는 원격의 임의의 수의 데이터 센터에 상주할 수 있다는 것이 이해되어야 한다.
방법(300)에서, 스텝 360은 리소스 풀의 리소스 중에서 컴포넌트 인스턴스의 분배를 결정하는 것을 포함한다. 분배는 예를 들어, 새롭게 생성된 컴포넌트 인스턴스(들)의 배치의 결정 또는 기존의 컴포넌트 인스턴스(들)의 배치의 재구성을 포함할 수 있다. 특히, 본 방법을 수행하는 장치는 (ⅰ) 결정된 리소스 풀 및 연관된 네트워크 아키텍처; (ⅱ) 결정된 애플리케이션 리소스 요건; 및 (ⅲ) 결정된 룰의 세트에 기초하여 리소스 풀 내의 리소스에 대한 컴포넌트 인스턴스(들)를 할당 또는 할당해제한다.
스텝 320의 일부 실시예에서, 네트워크 아키텍처는 머신 파싱가능 문법으로 표현된다. 유리하게는, 네트워크 아키텍처가 머신 파싱가능 문법으로 저장될 때, 네트워크 아키텍처에 대한 수정은 동적으로 수행될 수 있어, 네트워크 아키텍처의 동적인 증가 및 축소를 허용한다. 이러한 실시예 중 일부에서, 머신 파싱가능 문법은 그래프 또는 논리적 관계이다.
일부 실시예에서, 스텝 320은 네트워크 상태를 결정하는 것을 추가로 포함한다. 특히, 링크, 액세스 노드, 에지 노드, 네트워크 디바이스 등과 같은 네트워크 요소의 상태 또는 스테이트가 결정될 수 있다. 예를 들어, 본 방법을 수행하는 장치는 도 2의 링크(230)의 동작 스테이트 및 혼잡 레벨을 결정할 수 있다.
스텝 330의 일부 실시예에서, 현재 애플리케이션 리소스 요건은 애플리케이션 요구에 기초한다.
스텝 330의 일부 실시예에서, 현재 애플리케이션 리소스 요건은 사용 측정에 기초한다. 이러한 실시예 중 일부에서, 본 방법을 수행하는 장치는 애플리케이션에 의한 리소스 사용을 감시한다. 이러한 실시예에 추가하여, 감시된 리소스 파라미터(예를 들어, 프로세싱, 대역폭, 메모리 또는 스토리지 파라미터)가 임계를 넘어 증가 또는 축소되면, 트리거 이벤트가 발생할 수 있고, 감시된 리소스 사용에 기초한 새로운 애플리케이션 리소스 요건이 결정될 수 있다. 예를 들어, 애플리케이션이 현재 할당된 10G Byte의 스토리지를 갖고 감시된 스토리지 사용이 10% 여유 용량 임계를 넘어 증가하면, 미리 정해진 할당 정책에 기초하여 현재 스토리지 애플리케이션 리소스 요건이 11G Byte인 것으로 장치가 결정할 수 있다(예를 들어, 사용 임계가 초과될 때 1G Byte 증분으로 스토리지를 증가시킴).
스텝 340의 일부 실시예에서, 안티 어피니티 룰은 인스턴스 한계(들)로 표현된다(예를 들어, 이용가능한 컴포넌트 인스턴스(들)의 최소 수를 특정하는 "SPOF 없음"에 대한 요건). 이러한 실시예 중 일부에서, 인스턴스 한계는 n+k로서 표현된다. "n"은 "SPOF 없음" 요건을 충족시키는 데 요구되는 이용가능한 컴포넌트 인스턴스의 수이고, "k"는 "SPOF 없음" 요건을 충족시키기 위해 허용되어야 하는 장애점의 개수이다. 예를 들어, 유형 "A"의 컴포넌트 인스턴스는 웹 서버에 대한 프론트 엔드 프로세스를 서비스하는 가상 머신이고 유형 "A"의 각 컴포넌트 인스턴스는 분 당 30개 요구를 프로세싱하는 것으로 상정한다. 애플리케이션이 300개 요구가 분 당 프로세싱되는 것을 요구한다면, 애플리케이션은 유형 "A"의 n=10 이용가능한 컴포넌트 인스턴스를 요구할 수 있다. 또한, 애플리케이션이 k=2 장애를 허용해야 한다면, 본 방법을 수행하는 장치는 n=10인 컴포넌트 인스턴스 중 2개가 장애(들)에 의해 영향을 받는 이벤트에서 프론트 엔드 프로세스 요구를 서비스하기 위해 유형 "A"의 적어도 2개의 리던던트 컴포넌트 인스턴스를 분배하도록 요구될 수 있다. 단순화를 위해, 유형 "A"의 컴포넌트 인스턴스 중 어떠한 것도 동일 장애에 의해 영향을 받지 않는 것으로 상정한다.
스텝 340의 일부 실시예에서, 안티 어피니티 룰은 "SPOF 없음" 요건을 충족시키기 위하여 리소스 한계(예를 들어, 스토리지, 대역폭, 메모리 액세스 지연 또는 프로세싱 사이클의 최소 임계)와 요구되는 허용 장애(즉, "k")의 수로 표현된다. 예를 들어, 유형 "A"의 컴포넌트 인스턴스가 웹 서버에 대하여 프론트 엔드 프로세스를 서비스하는 가상 머신이고 애플리케이션이 300개 요구가 분 당 프로세싱되는 것을 요구하는 것으로 상정한다. 또한, 애플리케이션이 k=2 장애의 허용치를 요구하는 것으로 상정한다. 애플리케이션이 허용된 장애의 수를 특정하지 않을 수 있고, 디폴트 허용치(예를 들어, k=1)가 사용될 수 있다는 것이 이해되어야 한다. 이러한 예에서, 유형 "A"의 컴포넌트 인스턴스의 임의의 적절한 구성이 사용될 수 있으며, 2개 장애 후에 적어도 300 프론트 엔드 프로세싱 요구를 서비스하기 위해 유형 "A"의 충분한 이용가능 컴포넌트 인스턴스가 존재한다. 첫번째 예에서, 분 당 30개 요구를 프로세싱가능한 유형 "A"의 10개의 컴포넌트 인스턴스가 있을 수 있고, 분 당 15개 요구를 프로세싱가능한 유형 "A"의 4개의 컴포넌트 인스턴스가 있을 수 있다. 이러한 첫번째 예에서, 분 당 30개 요구를 서비스하는 유형 "A"의 2개 컴포넌트 인스턴스의 장애는 분 당 300개 요구를 서비스가능한 유형 "A"의 이용가능한 컴포넌트 인스턴스를 여전히 남길 것이다(즉, 8*30+4*15=300). 단순화를 위해서, 유형 "A"의 어떠한 컴포넌트 인스턴스도 동일 장애에 의해 영향을 받지 않는 것으로 상정한다.
스텝 340의 일부 실시예에서, 애플리케이션은 "SPOF 없음"을 달성하기 위해 안티 어피니티 룰을 특징화할 수 있다.
스텝 340의 일부 실시예에서, 안티 어피니티 룰은 머신 파싱가능 문법으로 표현된다. 예를 들어, 가상 머신(예를 들어, 프로세싱+메모리) 및 가상화된 스토리지의 안티 어피니티 룰을 특정하기 위한 문법이 정의될 수 있다.
스텝 350의 일부 실시예에서, 컴포넌트 인스턴스가 할당 또는 할당해제될 수 있는지에 대한 결정은 장애점의 세트와 그 연관된 영향을 받은 컴포넌트 인스턴스에 기초할 것이다. 장애점은 임의의 적절한 가상화된 서버, 리소스, 네트워크 요소, 냉각 또는 전원 컴포넌트 등이다. 예를 들어, 도 2를 참조하면, TOR 스위치(210-1-1)의 장애는 임의의 리소스(220-1-1-1 - 220-1-1-5) 상에 할당된 모든 컴포넌트 인스턴스와 예를 들어 임의의 리소스(220-1-1-1 - 220-1-1-5) 상에 할당된 컴포넌트 인스턴스를 갖는 임의의 가상화된 서버(명료화를 위해 미도시) 상에 할당된 임의의 컴포넌트 인스턴스에 영향을 줄 것이다.
스텝 350의 일부 실시예에서, 장애점은 리던던트 컴포넌트일 수 있다. 예를 들어, 도 2를 참조하면, 집합 스위치(250-1)가 장애이면, 집합 스위치(250-2)가 인계할 수 있다. 하지만, 리던던트 컴포넌트(예를 들어, 집합 스위치(250-2))가 안티 어피니티 룰을 충족시키기 위해 충분한 로드를 인계받기에 충분한 용량을 갖지 않으면, "SPOF 없음" 위반이 발생할 수 있다.
일부 실시예에서, 스텝 350은 초기 할당, 동적 할당 또는 할당해제, 이주, 복구, 또는 다른 서비스 관리 액션 동안 결정된 룰(스텝 340)의 적어도 일부를 시행하는 것을 포함한다.
스텝 350의 일부 실시예에서, 본 방법을 수행하는 장치가 (예를 들어, 애플리케이션이 특정 데이터 센터의 "SPOF 없음" 기능을 넘어 수평 증가를 시도하기 때문에) 애플리케이션의 안티 어피니티 룰을 위반하지 않고 컴포넌트 인스턴스를 할당할 수 없을 때, 스텝 350은 요구된 수평 증가가 금지되어서 애플리케이션이 증가에서 벗어나야 한다는 것을 나타내는 적절한 에러를 반환한다. 상이한 증가 시나리오는 상이한 "SPOF 없음" 한계를 가질 수 있다는 것이 이해되어야 한다. 예를 들어, 데이터 센터는 "SPOF 없음" 한계를 위반하지 않고 영구 스토리지 용량에서의 증가를 호스팅할 수 있지만, 한계를 위반하지 않고 서비스 용량을 증가(즉, 새로운 VM 인스턴스 할당)시킬 수 없다.
스텝 350 또는 360의 일부 실시예에서, 동일 유형의 하나 이상의 컴포넌트 인스턴스는 다른 스토리지, 대역폭, 액세스 지연 또는 프로세싱 사이클 파라미터와 같은 상이한 리소스 파라미터를 갖는다. 예를 들어, 가상화된 스토리지 유형의 2개의 컴포넌트 인스턴스는 다른 스토리지 사이즈 또는 액세스 지연을 특정할 수 있다.
스텝 360의 일부 실시예에서, 컴포넌트 인스턴스의 분배의 결정은 컴포넌트 인스턴스의 적어도 일부의 적어도 하나의 리소스 파라미터에 기초한다.
스텝 350 또는 360의 일부 실시예에서, 컴포넌트의 분배가 스텝 350에서 수정되어야 하는지에 대한 결정 또는 스텝 360에서의 컴포넌트 인스턴스의 분배의 결정은 추가적으로 스텝 320에서 결정된 네트워크 상태에 기초할 수 있다. 예를 들어, 본 방법을 수행하는 장치는 스텝 320에서 도 2의 링크(230)의 동작 스테이트 또는 혼잡 레벨을 결정할 수 있다.
이러한 네트워크 상태 실시예의 제 1 예에서, 본 방법을 수행하는 장치는, 도 2의 링크(230-1)의 혼잡 레벨이 리소스(220-1-1-1 - 220-1-1-5) 상에 상주하는 컴포넌트 인스턴스를 서비스하기에 충분한 용량을 허용하지 않을 수 있는 것으로 결정할 수 있다. 이러한 예에서, 스텝 350 또는 360에서의 결정의 실시예는 리소스(220-1-1-1 - 220-1-1-5) 상에 상주하는 하나 이상의 컴포넌트 인스턴스의 감소된 리소스 용량에 기초할 수 있으며, 하나 이상의 컴포넌트 인스턴스의 감소된 용량은 링크(230-1)에서의 혼잡에 기초한다.
이러한 네트워크 상태 실시예의 제 2 예에서, 본 방법을 수행하는 장치는 도 2의 링크(230-2)가 서비스 중이 아닌 것으로 결정할 수 있다. 이러한 제 2 예에서, 스텝 350 또는 360에서의 결정은 리던던트 집합 스위치(250-2)에 의해 더 이상 서빙되고 있지 않는 EOR 스위치(240-1)에 기초할 수 있다. 이와 같이, 집합 스위치(250-1)가 컴포넌트 인스턴스를 서비스하기에 충분한 용량을 제공할 수 없는 것으로 결정되면, 결정은 리소스(220-1-1-1 - 220-1-x-5) 상에 상주하는 하나 이상의 컴포넌트 인스턴스의 감소된 리소스 용량에 기초할 수 있다. 또한, 집합 스위치(250-2)의 가용성이 제거되었으므로, 결정은 리소스(220-1-1-1 - 220-1-x-5) 상에 상주하는 컴포넌트 인스턴스에 대한 단일 장애점인 집합 스위치(250-1)에 기초할 수 있다.
스텝 360의 일부 실시예에서, 하나 이상의 현재 컴포넌트 인스턴스가 (예를 들어, "SPOF 없음" 조건을 회피하기 위해) 다른 리소스로 삭제, 수정 또는 재구성될 수 있다. 이러한 실시예의 일부에서, 하나 이상의 컴포넌트 인스턴스의 리소스 용량은, 하나 이상의 컴포넌트 인스턴스(예를 들어, 상술한 바와 같이 링크(230-1) 상의 링크 혼잡)를 서비스하기에 충분한 용량이 이용가능하지 않다는 결정에 기초하여 감소(예를 들어, 수정)된다.
스텝 360의 일부 실시예에서, 본 방법을 수행하는 장치는 애플리케이션 리소스 요건을 충족시키기 위하여 2개 이상의 컴포넌트 인스턴스를 생성한다. 예를 들어, 3G Byte의 스토리지를 할당하는 요건은 3G Byte의 스토리지를 제공하는 하나의 컴포넌트 인스턴스, 또는 2G Byte의 스토리지를 제공하는 하나의 컴포넌트 인스턴스 및 1G Byte의 스토리지를 제공하는 하나의 컴포넌트 인스턴스에 의해 충족될 수 있다. 이러한 실시예의 일부에서, 하나 초과의 컴포넌트 인스턴스에 대한 할당은 안티 어피니티 룰에 기초한다. 이러한 실시예의 일부에서, 하나 초과의 컴포넌트 인스턴스에 대한 할당은 시스템 내의 리소스의 기능 또는 가용성에 기초한다.
스텝 360의 일부 실시예에서, 컴포넌트 인스턴스는 스텝 340에서 결정된 하나 이상의 룰을 위반하지 않는 새롭게 인스턴스화된 가상화된 서버 상에 분배될 수 있다.
스텝 360의 일부 실시예에서, 컴포넌트 인스턴스의 할당해제는 하나 이상의 현재 컴포넌트 인스턴스가 재구성될 것을 요구할 수 있다. 예를 들어, (예를 들어, 애플리케이션 리소스 축소 요구에 기초하여) 컴포넌트 인스턴스가 낮아진 애플리케이션 리소스 요건으로 인해 삭제되는 경우, 하나 이상의 나머지 컴포넌트 인스턴스가 "SPOF 없음" 요건을 충족시키기 위해 다른 리소스에 걸쳐 분할될 수 있다.
본 방법(300)의 일부 실시예에서, 스텝 320, 330 또는 340은 동시에 결정될 수 있거나, 스텝 320, 330 또는 340의 일부는 순차적으로 결정될 수 있다. 예를 들어, 스텝 330에서 결정된 여유 용량은 스텝 320에서 할당된 리소스의 결정과 동시에 결정될 수 있고, 스텝 360의 분배 결정은 스텝 350의 할당 또는 할당해제 결정과 동시에 수행될 수 있다.
도 4는 도 3의 스텝 340에서 나타낸 룰을 결정하기 위한 클라우드 관리자(예를 들어, 도 1의 클라우드 관리자(130))에 대한 방법(400)의 실시예를 나타내는 흐름도를 도시한다. 본 방법은 안티 어피니티 룰을 결정하는 것(스텝 420), 컴포넌트 할당 룰을 결정하는 것(스텝 440), 비지니스 룰을 결정하는 것(스텝 460), 동작 정책을 결정하는 것(스텝 480) 및 규제 룰을 결정하는 것(스텝 490)을 포함한다.
본 방법(400)에서, 스텝 420은 안티 어피니티 룰을 결정하는 것을 포함한다. 특히, 상술한 바와 같이, 안티 어피니티 룰은 "SPOF 없음" 요건을 충족시키기 위해 애플리케이션에 대하여 이용가능하게 요구되는 리소스의 최소량을 기술한다.
본 방법(400)은 선택적으로 스텝 440을 포함한다. 스텝 440은 컴포넌트 할당 룰을 결정하는 것을 포함한다. 특히 컴포넌트 할당 룰은 컴포넌트 인스턴스(들)의 리소스 파라미터를 기술한다. 예를 들어, 요구되는 컴포넌트 인스턴스의 유형(예를 들어, 프로세싱 코어, 가상 머신 또는 가상화된 스토리지) 또는 디바이스의 기능(예를 들어, 액세스 지연, 프로세싱 사이클 또는 스토리지 요건)이 있다.
본 방법(400)은 선택적으로 스텝 460을 포함한다. 스텝 460은 시스템 내의 컴포넌트 인스턴스의 분배에 영향을 줄 수 있는 비지니스 룰을 결정하는 것을 포함한다. 특히, 비지니스 룰은 "SPOF 없는" 시스템의 리소스 제약을 기술한다. 이러한 실시예의 일부에서, 비지니스 룰은 (1) 현재 또는 장래의 유지 보수 활동에서의 사용을 위해 식별된 리소스; (2) 장래 사용을 위해 예약된 리소스; (3) 하나 이상의 식별된 고객을 위해 예약된 리소스; 및 (4) 기타를 포함할 수 있다.
본 방법(400)은 선택적으로 스텝 480을 포함한다. 스텝 480은 컴포넌트 인스턴스의 분배에 영향을 주는 동작 정책 룰을 결정하는 것을 포함한다. 특히, 동작 정책 룰은 애플리케이션 특정 분배 요건을 기술한다. 이러한 실시예의 일부에서, 동작 정책 룰은 (1) 컴포넌트 인스턴스의 할당에 대한 제한(예를 들어, 특정 유형의 컴포넌트 인스턴스는 다른 데이터 센터에서 할당되지 않을 수 있음); (2) 동작 요건(다른 유형의 컴포넌트 인스턴스 사이의 최대 액세스 지연을 특정); (3) 소프트웨어 라이센싱 (또는 다른 상업적/재정적) 한계; 또는 (4) 기타를 포함할 수 있다.
본 방법(400)은 선택적으로 스텝 490을 포함한다. 스텝 490은 컴포넌트 인스턴스의 분배에 영향을 주는 규제 룰을 결정하는 것을 포함한다. 특히, 규제 룰은 "SPOF 없는" 시스템의 규제적인 리소스 제약을 기술한다. 이러한 실시예의 일부에서, 규제 룰은 컴포넌트 인스턴스의 지리적 배치에 대한 제한을 포함할 수 있다. 예를 들어, 프라이버시 법은 지리적 경계 외부에서의 개인 정보의 저장을 제한할 수 있거나 유출 제어 규제는 지리적 경계 외부의 기술적 데이터의 저장을 제한할 수 있다.
본 방법(400)의 일부 실시예에서, 스텝 420, 440, 460, 480 또는 490은 동시에 결정되거나 실행될 수 있다.
주로 특정 시퀀스로 도시되거나 설명되었지만, 방법(300, 400)에서 나타내어진 스텝은 임의의 적절한 시퀀스로 수행될 수 있다는 것이 이해되어야 한다. 또한, 하나의 스텝에 의해 식별되는 스텝들이 시퀀스 내의 하나 이상의 다른 스텝들에서 수행될 수도 있거나, 하나 초과의 스텝의 공통 액션이 1회만 수행될 수 있다.
다양한 상술한 방법의 스텝은 프로그램된 컴퓨터에 의해 수행될 수 있다는 것이 이해되어야 한다. 여기에서, 또한 일부 실시예는 예를 들어 데이터 스토리지 매체인 프로그램 스토리지 디바이스를 포괄하도록 의도된 것이며, 이는 머신 또는 컴퓨터 판독가능 및 인코드 머신 실행가능 또는 컴퓨터 실행가능 프로그램의 명령이며, 상기 명령은 상기 상술한 방법의 스텝의 일부 또는 전부를 수행한다. 프로그램 스토리지 디바이스는 예를 들어, 디지털 메모리, 자기 디스크 및 자기 테이프와 같은 자기 스토리지 매체, 하드 드라이브 또는 광학 판독가능 데이터 스토리지 매체일 수 있다. 또한, 실시예는 상술한 방법의 상기 스텝들을 수행하기 위해 프로그램된 컴퓨터를 포괄하도록 의도되었다.
도 3 및 5a 내지 5d를 참조하면, 도 1의 클라우드 관리자(130)에 의한, 도 1의 SPOF 제거 시스템(100) 내의 애플리케이션 컴포넌트 인스턴스의 분배의 예가 제공된다.
도 5a는 유형 "A" 및 유형 "B"의 컴포넌트 인스턴스를 요구하는 예시적인 2-계층화된 애플리케이션의 신뢰도 블록도를 나타낸다. 컴포넌트 인스턴스 A1-A2는 컴포넌트 유형 'A' 500A-10이고 컴포넌트 인스턴스 B1-B4는 컴포넌트 유형 'B' 500A-20(총괄적으로, 컴포넌트 인스턴스 500A)이다. 특히, 애플리케이션 프로세스 유입(510A) 및 애플리케이션 프로세스 유출(520A) 간의 프로세스 경로는 컴포넌트 인스턴스(500A)를 통해 제공된다. "SPOF 없음" 요건을 충족시키기 위해, 프로세스 경로는, 도 3의 스텝 340에서 결정되고 스텝 350 또는 360에서 적용된 룰에 기초하여 컴포넌트 인스턴스(500A)가 리소스에 분배되는 것을 요구한다. 예를 들어, 안티 어피니티 룰이 유형 "A"의 적어도 하나의 컴포넌트 인스턴스가 단일 장애 후에 가용인 것을 요구한다면, 컴포넌트 인스턴스 A1 및 A2는 동일 장애점에 의해 영향을 받지 않을 수 있다.
도 5b 내지 5d에 나타낸 예시의 목적으로, 유형 "A"의 컴포넌트 인스턴스는 분 당 100개 요구를 서빙가능한 프론트 엔드 프로세스(예를 들어, 가상 머신)이고, 유형 "B"의 컴포넌트 인스턴스는 분 당 30개 요구를 서빙가능한 백 엔드 프로세스(예를 들어, 가상 머신)이다.
도 5b를 참조하면, 가상화된 서버(S1 - S5)에 걸친 컴포넌트 인스턴스(A1 - A2, B1 - B3)의 초기 할당이 예시된다(예를 들어, 스텝 320에서의 현재 할당의 결정).
이 예에서, 사용자 서비스가 완전하게 이용가능하게 되는(즉, 수용가능한 서비스 품질을 갖는 제공된 로드를 서빙하기에 충분한 용량으로) 결정된 룰(스텝 340)은 이하와 같다:
(1) 시스템은 이용가능한 프론트 엔드 프로세싱이 분 당 60개 요구를 프로세싱하는 것을 요구한다;
(2) 시스템은 이용가능한 백 엔드 프로세싱이 분 당 60개 요구를 프로세싱하는 것을 요구한다; 그리고
(3) 시스템은 하나의 장애점에 대하여 "SPOF 없음"을 충족시킬 것이다.
도 5b에서 컴포넌트 인스턴스의 초기 분배는 결정된 룰을 충족시킨다는 것이 이해되어야 한다.
도 5c 및 5d는 애플리케이션 증가 요구에 응답하여 도 5a의 컴포넌트 인스턴스(500A)의 2개의 예시적인 분배에서 컴포넌트 인스턴스(B4)의 할당을 나타낸다. 이 예에서, 애플리케이션 증가 요구에 기초하여 사용자 서비스가 완전하게 이용가능하게 되는 업데이트되고 결정된 룰(예를 들어, 도 3의 스텝 340)은 이하와 같다:
(1) 시스템은 이용가능한 프론트 엔드 프로세싱이 분 당 90개 요구를 프로세싱하는 것을 요구한다;
(2) 시스템은 이용가능한 백 엔드 프로세싱이 분 당 90개 요구를 프로세싱하는 것을 요구한다; 그리고
(3) 시스템은 하나의 장애점에 대하여 "SPOF 없음"을 충족시킬 것이다.
도 5b의 컴포넌트 인스턴스의 초기 분배는 업데이트되고 결정된 룰을 충족하지 않으므로, "SPOF 없음" 요건이 컴포넌트 인스턴스의 현재 분배로 충족되지 않는다는 것이 이해되어야 한다. 예를 들어, 가상화된 서버(S1 - S3) 중 임의의 것에 장애가 발생하면, 유형 'B'의 이용가능한 컴포넌트 인스턴스가 단지 분 당 60개 요구를 서비스가능하므로, "(2) 시스템이 이용가능한 백 엔드 프로세싱이 분 당 90개 요구를 프로세싱하는 것을 요구한다"라는 요건이 충족되지 않는다.
도 5c의 분배 예를 참조하면, 가상화된 서버(S1 - S5)에 걸친 컴포넌트 인스턴스(500A)의 분배가 업데이트되고 결정된 룰을 충족시키므로, 분배는 "SPOF 없음" 요건을 충족시킨다. 예를 들어, 나타낸 바와 같이, 가상화된 서버(S1 - S5) 중 임의의 하나에 장애가 발생하면, 유형 'A'의 이용가능한 컴포넌트 인스턴스가 분 당 적어도 90개 요구를 서비스 가능하고(예를 들어, 또는 서버가 분 당 100개 요구를 서비스가능함), 유형 'B'의 이용가능한 컴포넌트 인스턴스가 분 당 적어도 90개 요구를 서비스가능하다(예를 들어, 장애 후에 적어도 3개의 컴포넌트 인스턴스가 분 당 90개 요구를 서비스가능함). 따라서, 본 방법은, 컴포넌트 인스턴스(B4)의 할당이 달성될 수 있고(스텝 350) 가상화된 서버(S4)에 컴포넌트 인스턴스(B4)를 할당할 수 있다는(스텝 360) 것을 결정할 수 있다.
반대로, 도 5d의 분배 예를 참조하면, 가상화된 서버(S1 - S5)에 걸친 컴포넌트 인스턴스(500A)의 분배는 업데이트되고 결정된 룰을 충족하지 않으므로, 분배는 SPOF 요건을 충족하지 않는다. 나타낸 바와 같이, B2 및 B3 양쪽이 가상 서버(S3) 상에서 호스팅되면 가상화된 서버(S3)의 장애가 요건을 위반하여, "(2) 시스템이 이용가능한 백 엔드 프로세싱이 분 당 90개 요구를 프로세싱하는 것을 요구한다"라는 요건이 충족되지 않는다.
방법(300)을 수행하는 장치가 시스템 "SPOF 없음" 요건을 위반하지 않는 다른 분배를 선택할 수 있거나(예를 들어, 도 5c의 분배), 본 방법을 수행하는 장치가, 컴포넌트 인스턴스(예를 들어, 컴포넌트 인스턴스(B4))의 할당이 임의의 분배를 사용하여 달성되지 못할 수 있고(스텝 450) 복귀할 수 있다(스텝 495)는 것을 결정할 수 있다는 것이 이해되어야 한다.
본 예에 추가하여, 방법(300)을 수행하는 장치는 네트워크 아키텍처를 결정할 수 있다(스텝 320). 예를 들어, 도 2를 참조하면, 도 5b 내지 5d의 가상화된 서버(S1 - S4)는 각각 리소스(220-1-1-1, 220-2-1-1, 220-y-1-1 및 220-y-2-1) 상에 상주할 수 있다. 도 2의 네트워크 아키텍처에서, 리소스(220-y-1-1, 220-y-2-1)는 공통 EOR 스위치(예를 들어, EOR 스위치(240-y))를 공유하므로 EOR 스위치(240-y)의 장애가 가상 서버(S3, S4) 상에 상주하는 컴포넌트 인스턴스에 영향을 줄 것이므로, 컴포넌트 인스턴스(B4)가 가상화된 서버(S4) 상에 배치되면 EOR 스위치(240-y)는 업데이트되고 결정된 룰을 위반하는 단일 장애점이 될 것이다. 실제로, 임의의 리소스(S1 - S4) 상의 컴포넌트 인스턴스(B4)의 분배는 안티 어피니티 룰, 따라서 "SPOF 없음" 요건을 위반할 것이다. 일부 실시예에서, 방법(300)을 수행하는 장치는 안티 어피니티 룰을 위반하지 않는 리소스(예를 들어, 리소스(220-3-1-1)) 상에 새로운 가상화된 서버(예를 들어, S5)를 생성할 수 있고, 컴포넌트 인스턴스(B4)를 새롭게 생성된 가상화된 서버에 분배할 수 있다. EOR 스위치(240-y)와 같은 네트워크 디바이스의 장애와 유사하게, 링크 장애(예를 들어, 도 2의 링크(230))가 하나 이상의 리소스에 영향을 줄 수 있다는 것이 이해되어야 한다(예를 들어, 링크(230)의 장애가 리소스(220-1-1-1 - 220-1-1-5)에 영향을 줌).
일부 실시예에서, 장애점이 집합 스위치(250-1)와 같은 리던던트 컴포넌트이면, 리던던트 디바이스(들)(예를 들어, 집합 스위치(250-2))의 용량은 업데이트되고 결정된 룰을 충족하기에 충분하게 되도록 요구될 것이다. 이러한 실시예의 일부에서, 도 3의 스텝 350 또는 360에서의 결정은 여기에 설명하는 바와 같이 네트워크 대역폭의 적절성에 기초한다.
도 3을 다시 참조하면, 일부 실시예에서, 스텝 350 또는 360은 컴포넌트 인스턴스가 분배될 수 있는지 여부와 그 위치를 결정하기 위해 통상적인 고전적 최적화 기술을 사용하는 것을 포함한다. 통상적인 고전적 최적화 기술은 원하는 목표 또는 목적을 가장 잘 달성하는 액션을 결정하는 것을 포함한다. 목표 또는 목적을 가장 잘 달성하는 액션은 목적 함수의 값을 최대화 또는 최소화함으로써 결정될 수 있다. 일부 실시예에서, 목표 또는 목적 함수의 계측은 비용을 최소화할 수 있는 것이거나 애플리케이션 액세스 지연을 최소화하는 것일 수 있다.
문제는 이하와 같이 표현될 수 있다:
최적화:
Figure pct00001
이하의 조건:
Figure pct00002
여기에서 식 E.1은 목적 함수이고, 식 E.2는 해답에 대해 부과된 제약 세트를 구성한다. xi 변수, x1, x2,...,xn은 결정 변수의 세트를 나타내고, y=f(x1, x2,..., xn)는 이러한 결정 변수의 관점으로 표현된 목적 함수이다. 목적 함수는 최대화되거나 최소화될 수 있다는 것이 이해되어야 한다.
도 5b 내지 5d를 다시 참조하면, 컴포넌트 인스턴스(B4)의 배치는 다른 컴포넌트 인스턴스로부터의 액세스 지연을 최소화하는 목적 함수를 사용하여 결정될 수 있다. 예를 들어, 컴포넌트 인스턴스 유형 B가 가상 스토리지이고 컴포넌트 인스턴스 유형 A가 가상 머신인 경우(프로세싱+메모리), 목적 함수는 ∀ 리소스 ∈ 리소스 풀(예를 들어, 도 2의 리소스(220))일 수 있으며, 유형 A의 컴포넌트 인스턴스와 새롭게 할당된 컴포넌트 인스턴스(B4) 사이의 평균 액세스 지연을 최소화하는 리소스로서 컴포넌트 인스턴스(B4)의 분배에 대한 리소스를 선택할 수 있다. 컴포넌트 인스턴스(B4)의 분배에 대한 몇몇 룰은 이하와 같을 수 있다:
(1) 리소스 유형 = 스토리지 디바이스;
(2) 여유 용량 ≥ 요구되는 할당 사이즈;
(3) 이용가능한 스토리지 용량 ≥ MinimumStorageSizeThreshold ∀ 장애점; 및
(4) 액세스 지연 ≤ MaximumAccessDelayThreshold ∀ 컴포넌트 인스턴스 유형 A
도 6은 도 1의 하나의 클라우드 관리자(130)와 같은 다양한 장치(600)의 실시예를 개략적으로 나타낸다. 장치(600)는 프로세서(610), 데이터 스토리지(611) 및 I/O 인터페이스(630)를 포함한다.
프로세서(610)는 장치(600)의 동작을 제어한다. 프로세서(610)는 데이터 스토리지(611)와 협업한다.
데이터 스토리지(611)는 안티 어피니티 룰, 컴포넌트 할당 룰, 비지니스 룰, 동작 정책 룰 등과 같은 적절한 프로그램 데이터를 저장할 수 있다. 또한, 데이터 스토리지(611)는 프로세서(610)에 의해 실행가능한 프로그램(620)을 저장한다.
프로세서 실행가능 프로그램(620)은 I/O 인터페이스 프로그램(621), 재구성 프로그램(623) 또는 룰 결정 프로그램(625)을 포함할 수 있다. 프로세서(610)는 프로세서 실행가능 프로그램(620)과 협업한다.
I/O 인터페이스(630)는 상술한 바와 같이 도 1의 통신 채널(135)을 통한 통신을 지원하기 위해 프로세서(610) 및 I/O 인터페이스 프로그램(621)과 협업한다.
재구성 프로그램(623)은 상술한 바와 같이 도 4의 방법(들)(400)의 스텝을 수행한다.
룰 결정 프로그램(625)은 상술한 바와 같이 도 5의 방법(500)의 스텝을 수행한다.
일부 실시예에서, 프로세서(610)는 프로세서/CPU 코어와 같은 리소스를 포함할 수 있으며, I/O 인터페이스(630)는 임의의 적절한 네트워크 인터페이스를 포함할 수 있거나, 데이터 스토리지(611)는 메모리 또는 스토리지 디바이스를 포함할 수 있다. 또한, 장치(600)는 하나 이상의 서버(들), 프로세서, 메모리, 네트워크 인터페이스 또는 스토리지 디바이스와 같은 컴포넌트로 이루어진 블레이드와 같은 임의의 적절한 물리적 하드웨어 구성일 수 있다. 이들 실시예의 일부에서, 장치(600)는 서로 떨어져 있는 클라우드 네트워크 리소스를 포함할 수 있다.
일부 실시예에서, 장치(600)는 가상 머신일 수 있다. 이러한 실시예의 일부에서, 가상 머신은 다른 머신으로부터의 컴포넌트를 포함할 수 있거나 지리적으로 분산되어 있을 수 있다. 예를 들어, 데이터 스토리지(611) 및 프로세서(610)는 2개의 다른 물리적 머신에 있을 수 있다.
프로세서 실행가능 프로그램(620)이 프로세서(610) 상에 구현되는 경우에, 프로그램 코드 세그먼트는 특정 로직 회로와 유사하게 동작하는 고유 디바이스를 제공하기 위하여 프로세서에 결합한다.
예를 들어, 프로그램 및 로직이 데이터 스토리지 내에 저장되고 메모리가 프로세서에 통신가능하게 접속되는 실시예에 대하여 여기에서 설명 및 도시하였지만, 이러한 정보는 임의의 다른 적절한 방식으로(예를 들어, 임의의 적절한 수의 메모리, 스토리지 또는 데이터베이스를 사용하여); 임의의 적절한 구성의 디바이스에 통신가능하게 접속된 임의의 적절한 구성의 메모리, 스토리지 또는 데이터베이스를 사용하여; 메모리(들), 스토리지(들) 또는 내부 또는 외부 데이터베이스(들)의 임의의 적절한 조합에 정보를 저장하여; 또는 임의의 적절한 수의 액세스가능 외부 메모리, 스토리지 또는 데이터베이스를 사용하여 저장될 수 있다는 것이 이해되어야 한다. 이와 같이, 여기에서 칭해지는 데이터 스토리지라는 용어는 메모리(들), 스토리지(들) 및 데이터베이스(들)의 모든 적절한 조합을 포함하려는 것이다.
설명 및 도면은 본 발명의 원리를 단지 예시한다. 따라서, 본 기술분야의 당업자가, 여기에 명확하게 설명하거나 도시하지는 않았지만, 본 발명의 원리를 구현하고 그 사상 및 범주 내에 포함되는 다양한 구성을 고안할 수 있을 것이라는 것이 이해될 것이다. 또한, 본 명세서에서 인용된 모든 예들은 주로 독자가 기술을 넓히기 위해 본 발명자(들)에 의해 기여된 본 발명의 원리 및 개념을 이해하는 것을 돕기 위해 명확하게 교육적인 목적으로만 의도된 것이며, 이렇게 구체적으로 인용된 예 및 조건으로의 한정은 없는 것으로 해석되어야 한다. 또한, 본 발명의 원리, 양태 및 실시예를 인용하는 본 명세서의 모든 설명뿐만 아니라 그 구체적 예들은 그 동등물을 포함하도록 의도된다.
"프로세서"로서 라벨링되는 임의의 기능 블록을 포함하여, 도면에 도시된 다양한 요소의 기능은 전용 하드웨어뿐만 아니라 적절한 소프트웨어와 연관하여 소프트웨어를 실행가능한 하드웨어의 사용을 통해 제공될 수 있다. 프로세서에 의해 제공되었을 때, 기능은 단일 전용 프로세서, 단일 공유 프로세서, 또는 복수의 개별 프로세서에 의해 제공될 수 있으며, 이들 중 일부는 공유될 수 있다. 또한, "프로세서" 또는 "컨트롤러"라는 용어의 명확한 사용은 소프트웨어를 실행가능한 하드웨어를 배타적으로 칭하는 것으로 해석되어서는 안되며, 한정 없이 DSP(digital signal processor) 하드웨어, 네트워크 프로세서, ASIC(application specific integrated circuit), FPGA(field programmable gate array), 소프트웨어를 저장하기 위한 ROM(read only memory), RAM(random access memory) 및 비휘발성 스토리지를 내재적으로 포함할 수 있다. 통상적인 또는 종래의 다른 하드웨어도 포함될 수 있다. 마찬가지로, 도면에 도시된 임의의 스위치는 단지 개념적인 것이다. 그 기능은 프로그램 로직의 동작을 통해, 전용 로직을 통해, 프로그램 제어와 전용 로직의 상호작용을 통해, 또는 수동으로도 수행될 수 있으며, 특정 기술은 컨텍스트로부터 더욱 구체적으로 이해되는 구현자에 의해 선택가능하다.
여기에서 임의의 블록도는 본 발명의 원리를 구현하는 예시적인 회로의 개념도를 나타낸다는 것이 이해되어야 한다. 마찬가지로, 임의의 흐름도, 흐름 다이어그램, 스테이트 천이도, 의사 코드 등은 컴퓨터 또는 프로세서가 명확하게 도시되었건 도시되지 않았건, 컴퓨터 판독가능 매체에서 실질적으로 표현될 수 있어 컴퓨터 또는 프로세서에 의해 실행될 수 있는 다양한 프로세스를 나타낸다는 것이 이해되어야 한다.

Claims (10)

  1. 단일 장애점(single point of failure) 제거를 제공하기 위한 장치로서,
    데이터 스토리지와,
    상기 데이터 스토리지에 통신가능하게 접속된 프로세서를 포함하되,
    상기 프로세서는,
    하나 이상의 애플리케이션 리소스 요건을 결정하고,
    리소스 풀 및 상기 리소스 풀과 연관된 네트워크 아키텍처를 결정하고,
    하나 이상의 룰을 결정하고,
    상기 하나 이상의 애플리케이션 리소스 요건, 상기 리소스 풀, 상기 네트워크 아키텍처 및 상기 하나 이상의 룰에 기초하여, 하나 이상의 컴포넌트 인스턴스(componet instances)의 분배를 결정하도록 구성되는
    장치.
  2. 제 1 항에 있어서,
    상기 네트워크 아키텍처는 링크 및 네트워크 노드를 포함하고,
    상기 프로세서는 또한 상기 링크 및 네트워크 노드 중 하나 이상의 네트워크 상태를 결정하도록 구성되고,
    상기 하나 이상의 컴포넌트 인스턴스의 분배의 결정은 또한 상기 네트워크 상태에 기초하는
    장치.
  3. 제 1 항에 있어서,
    상기 하나 이상의 애플리케이션 리소스 요건은, 상기 리소스 풀의 멤버인 하나 이상의 리소스의 현재 할당, 및 애플리케이션과 연관되는 하나 이상의 현재 애플리케이션 리소스 요건을 포함하는
    장치.
  4. 제 1 항에 있어서,
    상기 하나 이상의 룰은 하나 이상의 안티 어피니티(anti-affinity) 룰을 포함하는
    장치.
  5. 제 4 항에 있어서,
    상기 하나 이상의 룰은 하나 이상의 비지니스 룰을 더 포함하고,
    상기 하나 이상의 비지니스 룰은 유지 보수 액션(maintenance actions)을 위한 상기 리소스 풀 내의 리소스의 일부의 예약을 포함하는
    장치.
  6. 제 1 항에 있어서,
    상기 하나 이상의 컴포넌트 인스턴스의 분배의 결정은 또한 장애점 세트(a set of failure points)에 기초하는
    장치.
  7. 단일 장애점 제거를 제공하는 방법으로서,
    데이터 스토리지에 통신가능하게 접속된 프로세서에서, 분배 트리거가 발생했다는 것을 결정하는 단계와,
    상기 데이터 스토리지와 협업하는 상기 프로세서에 의해, 하나 이상의 애플리케이션 리소스 요건을 결정하는 단계와,
    상기 데이터 스토리지와 협업하는 상기 프로세서에 의해, 리소스 풀 및 상기 리소스 풀과 연관된 네트워크 아키텍처를 결정하는 단계와,
    상기 데이터 스토리지와 협업하는 상기 프로세서에 의해, 하나 이상의 룰을 결정하는 단계와,
    상기 데이터 스토리지와 협업하는 상기 프로세서에 의해, 상기 분배 트리거, 상기 하나 이상의 애플리케이션 리소스 요건, 상기 리소스 풀, 상기 네트워크 아키텍처 및 상기 하나 이상의 룰에 기초하여, 하나 이상의 컴포넌트 인스턴스의 분배를 결정하는 단계를 포함하는
    방법.
  8. 제 7 항에 있어서,
    상기 분배 트리거는 상기 리소스 풀 내의 하나 이상의 리소스로부터 상기 컴포넌트 인스턴스의 적어도 일부의 이주(migrating)에 기초하는
    방법.
  9. 제 7 항에 있어서,
    상기 방법은, 상기 데이터 스토리지와 협업하는 상기 프로세서에 의해, 하나 이상의 링크 또는 네트워크 노드의 네트워크 상태를 결정하는 단계를 더 포함하고,
    상기 네트워크 아키텍처는 상기 하나 이상의 링크 또는 네트워크 노드를 포함하고,
    상기 하나 이상의 컴포넌트 인스턴스의 분배를 결정하는 단계는 또한 상기 네트워크 상태에 기초하는
    방법.
  10. 제 7 항에 있어서,
    상기 네트워크 아키텍처는 제 1 네트워크 디바이스를 포함하고,
    상기 하나 이상의 컴포넌트 인스턴스의 분배를 결정하는 단계는,
    상기 제 1 네트워크 디바이스의 장애가 하나 이상의 안티-어피니티 룰 중 적어도 하나를 위반할 것이라는 결정에 기초하여, 상기 하나 이상의 컴포넌트 인스턴스 중 제 1 컴포넌트 인스턴스가 상기 리소스 풀 내의 제 1 리소스와 연관되지 않을 수 있다고 결정하는 단계를 포함하는
    방법.
KR1020147034070A 2012-06-04 2013-05-15 클라우드 기반 애플리케이션에 대한 단일 장애점 제거를 위한 방법 및 장치 KR20150008446A (ko)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US13/487,506 2012-06-04
US13/487,506 US20130326053A1 (en) 2012-06-04 2012-06-04 Method And Apparatus For Single Point Of Failure Elimination For Cloud-Based Applications
PCT/US2013/041042 WO2013184309A1 (en) 2012-06-04 2013-05-15 Method and apparatus for single point of failure elimination for cloud-based applications

Publications (1)

Publication Number Publication Date
KR20150008446A true KR20150008446A (ko) 2015-01-22

Family

ID=48614124

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020147034070A KR20150008446A (ko) 2012-06-04 2013-05-15 클라우드 기반 애플리케이션에 대한 단일 장애점 제거를 위한 방법 및 장치

Country Status (7)

Country Link
US (1) US20130326053A1 (ko)
EP (1) EP2856318B1 (ko)
JP (1) JP2015522876A (ko)
KR (1) KR20150008446A (ko)
CN (1) CN104335182A (ko)
IN (1) IN2014DN09592A (ko)
WO (1) WO2013184309A1 (ko)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102083666B1 (ko) 2019-12-04 2020-03-02 대한민국 클라우드 컴퓨팅 기반 서버 모니터링 시스템 및 방법

Families Citing this family (36)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8601473B1 (en) 2011-08-10 2013-12-03 Nutanix, Inc. Architecture for managing I/O and storage for a virtualization environment
US9009106B1 (en) 2011-08-10 2015-04-14 Nutanix, Inc. Method and system for implementing writable snapshots in a virtualized storage environment
US9772866B1 (en) 2012-07-17 2017-09-26 Nutanix, Inc. Architecture for implementing a virtualization environment and appliance
US20140032738A1 (en) * 2012-07-24 2014-01-30 Sudip S. Chahal Method, apparatus and system for estimating subscription headroom for a storage pool
US9608933B2 (en) * 2013-01-24 2017-03-28 Hitachi, Ltd. Method and system for managing cloud computing environment
US9306805B2 (en) 2013-11-07 2016-04-05 International Business Machines Corporation Dynamic conversion of hardware resources of a server system
US20150169353A1 (en) * 2013-12-18 2015-06-18 Alcatel-Lucent Usa Inc. System and method for managing data center services
US9798489B2 (en) 2014-07-02 2017-10-24 Hedvig, Inc. Cloning a virtual disk in a storage platform
US9558085B2 (en) 2014-07-02 2017-01-31 Hedvig, Inc. Creating and reverting to a snapshot of a virtual disk
US9864530B2 (en) 2014-07-02 2018-01-09 Hedvig, Inc. Method for writing data to virtual disk using a controller virtual machine and different storage and communication protocols on a single storage platform
US9424151B2 (en) * 2014-07-02 2016-08-23 Hedvig, Inc. Disk failure recovery for virtual disk with policies
US10067722B2 (en) 2014-07-02 2018-09-04 Hedvig, Inc Storage system for provisioning and storing data to a virtual disk
US9875063B2 (en) 2014-07-02 2018-01-23 Hedvig, Inc. Method for writing data to a virtual disk using a controller virtual machine and different storage and communication protocols
US9411534B2 (en) 2014-07-02 2016-08-09 Hedvig, Inc. Time stamp generation for virtual disks
US9483205B2 (en) 2014-07-02 2016-11-01 Hedvig, Inc. Writing to a storage platform including a plurality of storage clusters
US9690613B2 (en) 2015-04-12 2017-06-27 At&T Intellectual Property I, L.P. Using diversity to provide redundancy of virtual machines
US20180302497A1 (en) * 2015-10-19 2018-10-18 Zte (Usa) Inc. Method and system for automating network migration
EP3365778A1 (en) * 2015-10-23 2018-08-29 Telefonaktiebolaget LM Ericsson (PUBL) Allocating hosts for instances with anti affinity rule
US11070395B2 (en) 2015-12-09 2021-07-20 Nokia Of America Corporation Customer premises LAN expansion
WO2019028269A2 (en) 2017-08-02 2019-02-07 Strong Force Iot Portfolio 2016, Llc METHODS AND SYSTEMS FOR DETECTION IN AN INDUSTRIAL ENVIRONMENT OF COLLECTING INTERNET DATA FROM OBJECTS WITH LARGE DATA SETS
US11327475B2 (en) 2016-05-09 2022-05-10 Strong Force Iot Portfolio 2016, Llc Methods and systems for intelligent collection and analysis of vehicle data
US10983507B2 (en) 2016-05-09 2021-04-20 Strong Force Iot Portfolio 2016, Llc Method for data collection and frequency analysis with self-organization functionality
US11774944B2 (en) 2016-05-09 2023-10-03 Strong Force Iot Portfolio 2016, Llc Methods and systems for the industrial internet of things
US20180284758A1 (en) 2016-05-09 2018-10-04 StrongForce IoT Portfolio 2016, LLC Methods and systems for industrial internet of things data collection for equipment analysis in an upstream oil and gas environment
US10248174B2 (en) 2016-05-24 2019-04-02 Hedvig, Inc. Persistent reservations for virtual disk using multiple targets
US11237546B2 (en) 2016-06-15 2022-02-01 Strong Force loT Portfolio 2016, LLC Method and system of modifying a data collection trajectory for vehicles
CN107562510B (zh) * 2016-06-30 2021-09-21 华为技术有限公司 一种应用实例的管理方法及管理设备
US10999147B2 (en) * 2016-07-18 2021-05-04 Telefonaktiebolaget Lm Ericsson (Publ) Allocating VNFC instances with anti affinity rule to hosts
CN106648462B (zh) 2016-11-21 2019-10-25 华为技术有限公司 数据存储方法及装置
US10509682B2 (en) * 2017-05-24 2019-12-17 At&T Intellectual Property I, L.P. De-allocation elasticity application system
US11442445B2 (en) 2017-08-02 2022-09-13 Strong Force Iot Portfolio 2016, Llc Data collection systems and methods with alternate routing of input channels
US10848468B1 (en) 2018-03-05 2020-11-24 Commvault Systems, Inc. In-flight data encryption/decryption for a distributed storage platform
US10938631B2 (en) * 2018-07-18 2021-03-02 Google Llc Quantitative analysis of physical risk due to geospatial proximity of network infrastructure
US10531592B1 (en) * 2018-07-19 2020-01-07 Quanta Computer Inc. Smart rack architecture for diskless computer system
US11659029B2 (en) * 2020-05-29 2023-05-23 Vmware, Inc. Method and system for distributed multi-cloud diagnostics
US11599432B2 (en) 2021-06-10 2023-03-07 Kyndryl, Inc. Distributed application orchestration management in a heterogeneous distributed computing environment

Family Cites Families (37)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5093912A (en) * 1989-06-26 1992-03-03 International Business Machines Corporation Dynamic resource pool expansion and contraction in multiprocessing environments
US6970913B1 (en) * 1999-07-02 2005-11-29 Cisco Technology, Inc. Load balancing using distributed forwarding agents with application based feedback for different virtual machines
US7529822B2 (en) * 2002-05-31 2009-05-05 Symantec Operating Corporation Business continuation policy for server consolidation environment
US7624438B2 (en) * 2003-08-20 2009-11-24 Eric White System and method for providing a secure connection between networked computers
EP1816564A4 (en) * 2004-10-12 2009-03-18 Fujitsu Ltd RESOURCE EXCHANGE PROCESSING PROGRAM AND RESOURCE EXCHANGE PROCESSING METHOD
US7496667B2 (en) * 2006-01-31 2009-02-24 International Business Machines Corporation Decentralized application placement for web application middleware
US7979513B2 (en) * 2006-03-31 2011-07-12 International Business Machines Corporation Method and system for determining a management complexity factor for delivering services in an environment
US8554981B2 (en) * 2007-02-02 2013-10-08 Vmware, Inc. High availability virtual machine cluster
US7802128B2 (en) * 2007-03-26 2010-09-21 Oracle International Corporation Method to avoid continuous application failovers in a cluster
JP4939271B2 (ja) * 2007-03-29 2012-05-23 株式会社日立製作所 ストレージ保守・管理装置の冗長化方法、及びその方法を使用する装置
US20080301282A1 (en) * 2007-05-30 2008-12-04 Vernit Americas, Inc. Systems and Methods for Storing Interaction Data
US8060074B2 (en) * 2007-07-30 2011-11-15 Mobile Iron, Inc. Virtual instance architecture for mobile device management systems
US7962587B2 (en) * 2007-12-10 2011-06-14 Oracle America, Inc. Method and system for enforcing resource constraints for virtual machines across migration
US9237034B2 (en) * 2008-10-21 2016-01-12 Iii Holdings 1, Llc Methods and systems for providing network access redundancy
US8327186B2 (en) * 2009-03-10 2012-12-04 Netapp, Inc. Takeover of a failed node of a cluster storage system on a per aggregate basis
US20100293147A1 (en) * 2009-05-12 2010-11-18 Harvey Snow System and method for providing automated electronic information backup, storage and recovery
TW201042953A (en) * 2009-05-21 2010-12-01 Moxa Inc Processing method of redundancy check for chain network
US9497039B2 (en) * 2009-05-28 2016-11-15 Microsoft Technology Licensing, Llc Agile data center network architecture
US8289960B2 (en) * 2009-06-22 2012-10-16 Citrix Systems, Inc. Systems and methods for N-core tracing
US8429449B2 (en) * 2010-03-01 2013-04-23 International Business Machines Corporation Optimized placement of virtual machines in a network environment
JP5386745B2 (ja) * 2010-03-25 2014-01-15 株式会社日立製作所 ネットワーク監視サーバ及びネットワーク監視システム
US8572706B2 (en) * 2010-04-26 2013-10-29 Vmware, Inc. Policy engine for cloud platform
EP2572473B1 (en) * 2010-05-19 2014-02-26 Telefonaktiebolaget L M Ericsson (PUBL) Methods and apparatus for use in an openflow network
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
US9239765B2 (en) * 2010-08-31 2016-01-19 Avaya Inc. Application triggered state migration via hypervisor
EP2625603A2 (en) * 2010-10-05 2013-08-14 Unisys Corporation Automatic selection of secondary backend computing devices for virtual machine image replication
US9323572B2 (en) * 2011-06-02 2016-04-26 International Business Machines Corporation Autoconfiguration of a cloud instance based on contextual parameters
US8868859B2 (en) * 2011-06-03 2014-10-21 Apple Inc. Methods and apparatus for multi-source restore
US8874955B2 (en) * 2011-07-07 2014-10-28 International Business Machines Corporation Reducing impact of a switch failure in a switch fabric via switch cards
US8856585B2 (en) * 2011-08-01 2014-10-07 Alcatel Lucent Hardware failure mitigation
US8826074B2 (en) * 2011-09-30 2014-09-02 Alcatel Lucent Live module diagnostic testing
US9280409B2 (en) * 2011-10-28 2016-03-08 Hewlett Packard Enterprise Development Lp Method and system for single point of failure analysis and remediation
TWI436215B (zh) * 2011-10-31 2014-05-01 Delta Electronics Inc 分散式檔案系統及其使用的備份位置決策方法
US9626222B2 (en) * 2012-01-17 2017-04-18 Alcatel Lucent Method and apparatus for network and storage-aware virtual machine placement
US9270484B2 (en) * 2012-01-23 2016-02-23 Microsoft Technology Licensing, Llc Data center network using circuit switching
US9268590B2 (en) * 2012-02-29 2016-02-23 Vmware, Inc. Provisioning a cluster of distributed computing platform based on placement strategy
US20130254762A1 (en) * 2012-03-21 2013-09-26 Verizon Patent And Licensing Inc. Providing redundant virtual machines in a cloud computing environment

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102083666B1 (ko) 2019-12-04 2020-03-02 대한민국 클라우드 컴퓨팅 기반 서버 모니터링 시스템 및 방법

Also Published As

Publication number Publication date
EP2856318A1 (en) 2015-04-08
WO2013184309A1 (en) 2013-12-12
CN104335182A (zh) 2015-02-04
IN2014DN09592A (ko) 2015-07-31
JP2015522876A (ja) 2015-08-06
US20130326053A1 (en) 2013-12-05
EP2856318B1 (en) 2016-05-11

Similar Documents

Publication Publication Date Title
KR20150008446A (ko) 클라우드 기반 애플리케이션에 대한 단일 장애점 제거를 위한 방법 및 장치
US10895984B2 (en) Fabric attached storage
US9442763B2 (en) Resource allocation method and resource management platform
US10963285B2 (en) Resource management for virtual machines in cloud computing systems
US10104010B2 (en) Method and apparatus for allocating resources
US10999147B2 (en) Allocating VNFC instances with anti affinity rule to hosts
US9264375B2 (en) Software-defined networking interface between multiple platform managers
US8122289B2 (en) Load balancing and high availability of compute resources
US9298515B2 (en) Methods, systems, and computer readable media for providing a virtualized diameter network architecture and for routing traffic to dynamically instantiated diameter resource instances
US11561817B2 (en) High availability for virtual network functions
CN111399970B (zh) 一种预留资源管理方法、装置和存储介质
US10911529B2 (en) Independent groups of virtual network function components
US20180199239A1 (en) Management of resource allocation in a mobile telecommunication network
US11023128B2 (en) On-demand elastic storage infrastructure
US20190317824A1 (en) Deployment of services across clusters of nodes
JP2011521319A (ja) 管理システムのコンピューティングリソースを管理するための方法および装置
US10630600B2 (en) Adaptive network input-output control in virtual environments
US8706858B2 (en) Method and apparatus for controlling flow of management tasks to management system databases
US20130232504A1 (en) Method and apparatus for managing processing resources in a distributed processing system
US20210409343A1 (en) Network controller
CN115225642B (zh) 超融合系统的弹性负载均衡方法及系统
CN110493060A (zh) 一种虚拟ip分配方法及相关装置
CN108153484B (zh) 一种虚拟化环境下的共享式存储系统及其管理方法
WO2016188135A1 (zh) 集群路由器cpu资源的配置方法及集群路由器
Muraai et al. Application of server virtualization technology to communication services

Legal Events

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