KR20240006299A

KR20240006299A - 자체 관리가 가능한 클라우드 데이터 센터 및 그것의 관리 제어 방법

Info

Publication number: KR20240006299A
Application number: KR1020220083178A
Authority: KR
Inventors: 권대경; 김지원; 한정수; 이정복; 이어형; 손준호; 조충희; 강문중; 권진철; 유태희; 박영운; 엄재철; 나랑토야 자르갈사이흥; 신준식; 안성원
Original assignee: 주식회사 카카오엔터프라이즈
Priority date: 2022-07-06
Filing date: 2022-07-06
Publication date: 2024-01-15

Abstract

본 발명은 자체 관리가 가능한 데이터 센터 관리 기술에 관한 것이다. 보다 구체적으로 본 발명은, 제네시스 노드를 구성하고, 자체 관리 노드(self-managed node)에 프로비저닝을 수행하며, 상기 프로비저닝을 수행한 후, 상기 제네시스 노드를 상기 자체 관리 노드에 복제하고, 상기 제네시스 노드를 제거하는 클라우드 데이터 센터를 관리하는 기술에 관한 것이다.

Description

자체 관리가 가능한 클라우드 데이터 센터 및 그것의 관리 제어 방법{SELF-MANAGED CLOUD DATA CENTER AND CONTROL METHOD THEREOF}

본 발명은 클라우드 네이티브 환경에서 데이터 센터를 관리하기 위한 기술에 관한 것으로, 보다 구체적으로는 데이터 센터 내에 포함되어 있는 다양한 종류의 IT 리소스를 선언적인 방법으로 관리할 수 있는 제어 방법에 관한 것이다.

클라우드 인프라를 관리하기 위한 측면에서 IT 리소스(컴퓨팅/네트워킹/스토리지)는 가상화되어 효율적으로 관리 될 수 있다. 그 예로, 컴퓨팅 리소스는 가상 머신(Virtual machine, VM)을 이용한 가상화를 주로 이용한다.

최근에는 대부분의 어플리케이션이 모놀로틱 구조에서 마이크로서비스 구조(Microservices Architecture)로 전환됨에 따라서 가상 머신을 활용하는 대신에 민첩한 컨테이너를 활용하는 방법이 대세로 자리잡고 있다.

컨테이너화는 운영 체제 수준의 가상화에 기반한 가상화 방식을 말한다. 컨테이너는 서로 간에 또는 호스트로부터 격리된 애플리케이션을 위한 가볍고 이식 가능한 실행 요소라는 특징이 존재한다.

이러한 추세에 맞춰, 컨테이너 오케스트레이션 산하에 모든 서비스의 요소들을 마이크로서비스화 하여 컨테이너로 관리하는 클라우드-네이티브 컴퓨팅이 부상하고 있다.

복잡한 IT 환경에서 단순하고 비용 효율적인 운영을 추구하기 위해서는 선언적으로 서비스를 관리하는 쿠버네티스(Kubernetes, k8s) 플랫폼이 컨테이너 오케스트레이션 서비스의 대표적인 예시이다.

컨테이너 오케스트레이션 아키텍처에서 클러스터(Cluster)란 컨테이너 형태의 애플리케이션을 호스팅하는 물리/가상 환경의 노드들로 이루어진 집합을 의미한다. 즉, 컨테이너 오케스트레이션에 기초한 데이터 센터 환경에서는, 호스트 환경에 구성된 자원들을 클러스터 단위로 추상화하여 관리한다. 하나의 클러스터 안에는 클러스터 내부 요소들을 제어하는 컨트롤 플레인(Control plane) 역할을 수행하는 마스터 노드(Master node)를 두고, 관리자는 이 마스터 노드를 통하여 클러스터 전체를 제어하는 구성을 따른다.

결국 이와 같은 클러스터의 관리는, 컨테이너 오케스트레이션 플랫폼에 의해서 관리되지만, 컨테이너 오케스트레이션 플랫폼 자체를 관리하기 위한 기술은 연구가 요구되는 실정이다.

본 발명이 해결하고자 하는 과제는 데이터 센터 내에 존재하는 다양한 종류의 IT 리소스를 선언적으로 관리하기 위한 제어 방법을 제공하는 것이다.

본 발명이 해결하고자 하는 다른 과제는 스스로를 관리할 수 있는 컨테이너 오케스트레이션 플랫폼을 제공하는 것이다.

본 발명에서 이루고자 하는 기술적 과제들은 이상에서 언급한 기술적 과제들로 제한되지 않으며, 언급하지 않은 또 다른 기술적 과제들은 아래의 기재로부터 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.

상기 또는 다른 과제를 해결하기 위해 본 발명의 일 측면에 따르면, 프로세서를 구성하는 제어 노드에 의해서 수행되는 클라우드 데이터 센터를 관리하는 제어 방법에 있어서, 제네시스 노드를 구성하는 단계; 자체 관리 노드(self-managed node)에 프로비저닝을 수행하는 단계; 상기 제네시스 노드를 상기 자체 관리 노드에 복제하는 단계; 및 상기 제네시스 노드를 제거하는 단계를 포함하는, 클라우드 데이터 센터를 관리하는 제어 방법을 제공한다.

상기 제네시스 노드를 구성하는 단계는, 상기 제네시스 노드에 OS(Operating system), 클러스터 관리 API 및 베어메탈 프로비저닝 컴포넌트 중 적어도 하나를 설치하는 단계를 포함할 수 있다.

상기 제네시스 노드가 자기 자신이 올라가기 위한 사용자 지정 리소스 정의를 생성하는 단계를 더 포함할 수 있다.

상기 프로비저닝을 수행하는 단계는, 상기 설치된 베어메탈 프로비저닝 컴포넌트가 상기 프로비저닝을 수행할 수 있다.

상기 자체 관리 노드 및 상기 제네시스 노드 중 적어도 하나는 마스터 노드일 수 있다.

상기 프로비저닝하는 단계는, 복수 개의 노드 중에서 프로비저닝 대상이 되는 상기 자체 관리 노드를 선정하는 단계를 포함할 수 있다.

상기 프로비저닝하는 단계는, 상기 선정된 노드에 대한 정보를 수집하는 단계를 더 포함하되, 상기 수집되는 정보는, 하드웨어 정보, 펌웨어 정보, 호스트명(hostname), 네트워크 카드(Network Interface Card, NIC) 정보, 스토리지 정보 및 시스템 벤더 정보 중 적어도 하나를 포함할 수 있다.

상기 프로비저닝하는 단계는, 상기 생성된 사용자 지정 리소스 정의에 기초하여 상기 선정된 자체 관리 노드에 프로비저닝하는 단계를 더 포함할 수 있다.

상기 또는 다른 과제를 해결하기 위해 본 발명의 다른 측면에 따르면, 복수 개의 노드 및 상기 복수 개의 노드를 제어하기 위한 프로세서를 구비하는 제어 노드를 포함하도록 구성되는 데이터 센터에 있어서, 상기 복수 개의 노드 중 제1노드에 설치되는 제네시스 노드를 포함하도록 구성되고, 상기 제네시스 노드는, 상기 복수 개의 노드 중 제2노드에 자체 관리 노드를 프로비저닝하고, 상기 프로비저닝을 수행한 후, 자신을 상기 자체 관리 노드에 복제하며, 상기 복제된 후 상기 제네시스 노드는 상기 제1노드에서 삭제되는, 데이터 센터를 제공한다.

상기 제네시스 노드의 설치는, 상기 제1노드에 OS(Operating system), 클러스터 관리 API 및 베어메탈 프로비저닝 컴포넌트 중 적어도 하나를 설치할 수 있다.

상기 제네시스 노드는, 자기 자신이 올라가기 위한 사용자 지정 리소스 정의를 생성할 수 있다.

자체 관리 노드의 프로비저닝은, 상기 제네시스 노드에 설치된 베어메탈 프로비저닝 컴포넌트에 의해서 수행될 수 있다.

상기 제네시스 노드가 상기 프로비저닝을 수행하는데 있어서, 상기 복수 개의 노드 중에서 제2노드를 자체 관리 노드를 프로비저닝하기 위한 대상 노드로 선정할 수 있다.

상기 제네시스 노드가 상기 프로비저닝을 수행하는데 있어서, 상기 대상 노드로 선정된 제2노드에 대한 정보를 수집하되, 상기 수집되는 정보는, 하드웨어 정보, 펌웨어 정보, 호스트명(hostname), 네트워크 카드 정보, 스토리지 정보 및 시스템 벤더 정보 중 적어도 하나를 포함할 수 있다.

상기 제네시스 노드가 상기 프로비저닝을 수행하는데 있어서, 상기 생성된 사용자 지정 리소스 정의에 기초하여 상기 선정된 자체 관리 노드에 프로비저닝할 수 있다.

본 발명에 따른 클라우드 데이터 센터 관리 제어 방법의 효과에 대해 설명하면 다음과 같다.

본 발명의 실시 예들 중 적어도 하나에 의하면, 데이터 센터 내에 존재하는 다양한 종류의 IT 리소스를 선언적으로 관리하기 위한 제어 방법을 제공할 수 있다는 장점이 있다.

또한, 본 발명의 실시 예들 중 적어도 하나에 의하면, 스스로를 관리가 가능한 클러스터를 제공할 수 있는 컨테이너 오케스트레이션 플랫폼을 제공할 수 있다는 장점이 있다.

본 발명의 적용 가능성의 추가적인 범위는 이하의 상세한 설명으로부터 명백해질 것이다. 그러나 본 발명의 사상 및 범위 내에서 다양한 변경 및 수정은 당업자에게 명확하게 이해될 수 있으므로, 상세한 설명 및 본 발명의 바람직한 실시 예와 같은 특정 실시 예는 단지 예시로 주어진 것으로 이해되어야 한다.

도 1은 본 발명의 일실시예에 따른 데이터 센터(10)의 구성을 나타내는 블록도를 도시한다.
도 2은 본 발명의 일실시예에 따른 복수 개의 노드 중 소정 노드(100)의 구성을 도시하는 도면이다.
도 3는 본 발명의 일실시예에 따른 관리 제어 방법의 순서도를 도시하는 도면이다.
도 4은 본 발명의 일실시예에 따라 구성된 제네시스 노드(300)의 개념도를 도시한다.
도 5는 본 발명의 일실시예에 따라, 복수 개의 노드 중에서 자체 관리 노드에 프로비저닝을 수행하기 위한 노드를 선정하고, 선정된 노드에 자체 관리 노드에 프로비저닝을 수행하는 개념도를 도시한다.
도 6는 본 발명의 일실시예에 따라, 자체 관리 노드(401)에 프로비저닝을 수행하고 자체 관리 노드(401)에 제네시스 노드(300)가 복제된 뒤, 기존 제네시스 노드(300)를 삭제하는 개념도를 도시한다.
도 7은 본 발명의 일실시예에 따라, 프로비저닝이 이루어진 자체 관리 노드(401)가 복수 개의 노드에 다른 클러스터를 생성 및 배포하는 개념도를 도시하는 도면이다.
도 8은 본 발명의 일실시예에 따른 자체 관리 노드(401)에 의해서 생성된 클러스터에 포함되어 클러스터를 구성하는 제1 내지 제3 노드(310-1 ~ 310-3)를 도시하는 도면이다.

이하, 첨부된 도면을 참조하여 본 명세서에 개시된 실시 예를 상세히 설명하되, 도면 부호에 관계없이 동일하거나 유사한 구성요소는 동일한 참조 번호를 부여하고 이에 대한 중복되는 설명은 생략하기로 한다. 이하의 설명에서 사용되는 구성요소에 대한 접미사 "모듈" 및 "부"는 명세서 작성의 용이함만이 고려되어 부여되거나 혼용되는 것으로서, 그 자체로 서로 구별되는 의미 또는 역할을 갖는 것은 아니다. 또한, 본 명세서에 개시된 실시 예를 설명함에 있어서 관련된 공지 기술에 대한 구체적인 설명이 본 명세서에 개시된 실시 예의 요지를 흐릴 수 있다고 판단되는 경우 그 상세한 설명을 생략한다. 또한, 첨부된 도면은 본 명세서에 개시된 실시 예를 쉽게 이해할 수 있도록 하기 위한 것일 뿐, 첨부된 도면에 의해 본 명세서에 개시된 기술적 사상이 제한되지 않으며, 본 발명의 사상 및 기술 범위에 포함되는 모든 변경, 균등물 내지 대체물을 포함하는 것으로 이해되어야 한다.

제1, 제2 등과 같이 서수를 포함하는 용어는 다양한 구성요소들을 설명하는데 사용될 수 있지만, 상기 구성요소들은 상기 용어들에 의해 한정되지는 않는다. 상기 용어들은 하나의 구성요소를 다른 구성요소로부터 구별하는 목적으로만 사용된다.

어떤 구성요소가 다른 구성요소에 "연결되어" 있다거나 "접속되어" 있다고 언급된 때에는, 그 다른 구성요소에 직접적으로 연결되어 있거나 또는 접속되어 있을 수도 있지만, 중간에 다른 구성요소가 존재할 수도 있다고 이해되어야 할 것이다. 반면에, 어떤 구성요소가 다른 구성요소에 "직접 연결되어" 있다거나 "직접 접속되어" 있다고 언급된 때에는, 중간에 다른 구성요소가 존재하지 않는 것으로 이해되어야 할 것이다.

단수의 표현은 문맥상 명백하게 다르게 뜻하지 않는 한, 복수의 표현을 포함한다.

본 출원에서, "포함한다" 또는 "가지다" 등의 용어는 명세서상에 기재된 특징, 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 것이 존재함을 지정하려는 것이지, 하나 또는 그 이상의 다른 특징들이나 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 것들의 존재 또는 부가 가능성을 미리 배제하지 않는 것으로 이해되어야 한다.

본 발명은 데이터 센터를 구성하는 다양한 IT 리소스들을 일괄적으로 컨테이너 오케스트레이션 플랫폼(Container Orchestration Platform)으로 관리하기 위한 제어 방법에 관한 것이다.

이하에서는, 컨테이너 오케스트레이션 플랫폼의 대표적인 예시로 쿠버네티스의 경우를 들고 있지만, 반드시 이에 한정되는 것은 아니고 다양한 종류의 컨테이너 오케스트레이션 플랫폼이 본 발명에 적용될 수 있을 것이다.

또한, 이하에서는 쿠버네티스에서 사용되어 널리 통용되는 용어들이 사용되지만, 이러한 용어의 사용으로 인하여 본 발명이 쿠버네티스라는 컨테이너 오케스트레이션 플랫폼에 한정되지는 않을 것이다.

IT 리소스란 하드웨어 소프트웨어 네트워킹 등 IT 서비스 및 솔루션을 제공하는데 이용되는 구성요소로, 그 종류가 매우 다양하다.

PM(Physical Machine), VM(Virtual Machine), DB(Database), network, k8s(Kubernetes), IaaS(Infrastructure as a service)나 PaaS(Platform as a service) 등의 다양한 IT 리소스를 같은 방법으로 일원화하여 관리할 수 있다면, 편의성은 상당히 높아질 것이다.

즉, 이러한 모든 IT 리소스들을 컨테이너화시키고, 컨테이너 오케스트레이션 플랫폼과 같이 컨테이너를 관리하기 위한 기술만 준비되면, 효과적으로 IT 리소스들을 관리할 수 있을 것이다.

컨테이너는 호스트 하드웨어 컴퓨팅 환경에 밀접하게 연결되어 있지 않기 때문에 애플리케이션을 컨테이너 이미지에 연결하고 기본 컨테이너 아키텍처를 지원하는 모든 호스트 또는 가상 호스트에서 단일 경량 패키지로 실행할 수 있다. 이러한 특징 때문에, 컨테이너는 서로 다른 컴퓨팅 환경에서 소프트웨어를 작동시킬 때 발생할 수 있는 여러가지 문제를 해결할 수 있다.

그리고 컨테이너는 운영 체제를 가상화한 환경임으로 가상 머신에 비해서 상대적으로 가볍기 때문에, 동일한 환경 내지 조건 하에서 기존의 가상 머신 보다 더 많은 컨테이너 인스턴스 지원이 가능할 뿐만 아니라 빠르게 생성 및 제거가 가능하다.

종종 수명이 짧은 컨테이너는 가상 머신 보다 더 효율적으로 생성 및 이동할 수 있다. 그리고 컨테이너는 논리적으로 관련된 요소들의 그룹으로 관리하는 것이 가능하다. 예를 들어서 쿠버네티스(Kubernetes)와 같은 일부 오케스트레이션 플랫폼의 경우, 이러한 요소들을 "파드(Pod)"라고 부르며, 이러한 파드를 제공하는 노드의 그룹을 "클러스터"라 한다.

이하 본 발명에서 파드 및 클러스터라는 용어를 사용하지만, 이는 요소 및 그것들의 그룹을 지칭하기 위한 용어일 뿐, 본 발명이 쿠버네티스 플랫폼에 한정되지는 않을 것이다.

컨테이너 오케스트레이션 아키텍처에서 클러스터(Cluster)란 컨테이너 형태의 애플리케이션을 호스팅하는 물리/가상 환경의 노드들로 이루어진 집합을 의미한다. 즉, 컨테이너 오케스트레이션에 기초한 데이터 센터 환경에서는, 호스트 환경에 구성된 자원들을 클러스터 단위로 추상화하여 관리한다.

하나의 클러스터 안에는 클러스터 내부 요소들을 제어하는 컨트롤 플레인(Control plane) 역할을 수행하는 마스터 노드(Master node)를 두고, 관리자는 이 마스터 노드를 통하여 클러스터 전체를 제어하는 구성을 따른다. 컨트롤 플레인 역할이란, 클러스터 전체의 워크로드 리소스 등 주요 구성 요소들을 배포하고 제어하는 것을 말한다.

클러스터는 용도에 따라 워커 노드(Worker Node)와 마스터 노드(Master Node)로 구분된다.

- 워커 노드: 각기 다른 목적과 기능으로 세분화된 컨테이너들이 실제 배치되는 노드를 의미한다.

워커 노드에 설치되는 파드들은 일반적으로 마스터 노드의 API 서버로부터 전달된 명령을 수행하는 Agent, 파드들간의 네트워크를 관리하는 proxy, 파드들을 실제로 실행시키는 런타임(Runtime) 등이 있다. 단, 워커 노드에 설치되는 파드들은 열거한 기능들에 한정되지는 않을 것이다.

- 마스터 노드: 대규모의 컨테이너를 운영하기 위하여 각 워커 노드들의 가용 리소스 현황을 고려하여 최적의 컨테이너 배치와 모니터링, 그리고 각 컨테이너에 대한 효율적인 추적 관리를 수행하는 노드를 마스터 노드라 칭한다.

마스터 노드에 설치되는 파드들은 일반적으로 클러스터의 기능들을 API 형태로 제공하는 API 서버, 클러스터의 데이터를 저장하는 데이터베이스, 파드들이 어떠한 노드에 할당될 것인지를 결정하는 스케쥴러(scheduler), 클러스터의 자원을 관리 및 할당하는 컨트롤러, 그리고 DNS(Domain Name System) 서버 등이 있을 수 있다. 단, 마스터 노드에 설치되는 파드들은 열거한 기능들에 한정되지는 않을 것이다.

쿠버네티스는 컨테이너화 된 애플리케이션의 대규모 배포, 스케일링 및 관리를 간편하게 만들어주는 대표적인 오픈 소스 기반 컨테이너 오케스트레이션(Container Orchestration) 플랫폼이다.

컨테이너 오케스트레이션(Container Orchestration)이란, "컨테이너화 된 애플리케이션에 대한 자동화된 설정, 관리 및 제어 체계"를 의미한다.

마이크로서비스 아키텍처(MSA; Microservice Architecture)에서는 프로젝트에 포함된 세부 기능들이 작은 서비스 단위로 분리되어 구축된다. 이 각각의 서비스를 구현할 때 컨테이너 기술이 흔하게 이용된다. 한정된 적은 양의 컨테이너는 개별 관리자가 손수 관리할 수도 있겠지만, 대규모의 상용 프로젝트 환경에서 수많은 컨테이너를 이런 식으로 제어하는 것은 불가능하다. 동시에 수백, 수천 개의 컨테이너를 배포하고 관리해야 하는 상황이라면 아래의 4가지 이슈를 고려해야 할 것이다.

1. 배포 관리 : 어떤 컨테이너를 어느 호스트에 배치하여 구동시킬 것인가? 각 호스트가 가진 한정된 리소스에 맞춰 어떻게 최적의 스케줄링을 구현할 것인가? 어떻게 하면 이러한 배포 상태를 최소한의 노력으로 유지 관리할 수 있을 것인가?

2. 제어 및 모니터링 : 구동 중인 각 컨테이너들의 상태를 어떻게 추적하고 관리할 것인가?

3. 스케일링 : 수시로 변화하는 운영 상황과 사용량 규모에 어떻게 대응할 것인가?

4. 네트워킹 : 이렇게 운영되는 인스턴스 및 컨테이너들을 어떻게 상호 연결할 것인가?

결국 컨테이너 오케스트레이션은, 위 4가지 이슈를 고려하여, 온라인 인프라 환경에서 대규모의 컨테이너들이 안정적으로 운영될 수 있도록 관리의 복잡성을 줄여주고 이를 자동화하는 것을 의미한다.

쿠버네티스는 선언적 방법론 기반의 배포 환경을 갖는다는 장점이 있다.

선언적(declarative) 방법론이란 원하는 상태(Desired state)와 현재의 상태(Current state)가 상호 일치하는지를 지속적으로 체크하고 업데이트하는 방식을 의미한다. 선언적 방법론과 반대되는 개념으로는 명령적(imperative) 방법론이 있다.

따라서 내게 필요한 요소에 대해 원하는 상태를 설정하는 것만으로도 호스트의 리소스 현황에 맞춰 최적의 배치로 배포되거나 변경된다. 만약 특정 요소에 문제가 생겼을 경우, 쿠버네티스는 해당 요소가 원하는 상태로 다시 복구될 수 있도록 필요한 조치를 자동으로 취한다.

또한 쿠버네티스는, 클러스터 단위 중앙 제어를 수행한다. 쿠버네티스에서는 전체 물리 리소스를 클러스터 단위로 추상화하여 관리한다. 클러스터 내부에는 클러스터의 구성 요소들에 대해 제어 권한을 가진 컨트롤 플레인(Control Plane) 역할의 마스터 노드(Master Node)를 두게 되며, 관리자는 이 마스터 노드를 이용하여 클러스터 전체를 제어한다.

상술한 바와 같이, 모든 IT 리소스(인프라)를 쿠버네티스 클러스터(k8s cluster)로 관리하게 되면 이러한 선언적 운영 방법을 적극적으로 도입하기가 쉽다. 따라서 본 발명의 일실시예에 따른 데이터 센터 관리 제어 방법에서는, 클라우드-네이티브 관련 도구들을 손쉽게 접목하고 선언적 운영을 수행하기 위해서는 아래와 같이 인프라를 구축하도록 제안한다.

- 모든 IT 리소스(인프라)는 쿠버네티스 클러스터 기반으로 구성한다.

- 용도에 따라 별도의 독립적인 쿠버네티스 클러스터들을 구성한다.

다시말해, 클라우드 내에 존재하는 복수 개의 노드들에 대해서 용도에 따라 구분되는 적어도 하나 이상의 클러스터로 구성하여 운영될 수 있다.

도 1은 본 발명의 일실시예에 따른 데이터 센터(10)의 구성을 나타내는 블록도를 도시한다.

도시된 도면을 참고하면, 본 발명의 일실시예에 따른 데이터 센터(10)는, 제어 노드(190) 및 복수 개의 노드(100)를 포함하도록 구성될 수 있다.

제어 노드(190) 및 복수 개의 노드(100) 각각은 데이터 센터(10) 내 또는 데이터 센터(10)의 외부에 구비되는 베어메탈 서버에 의해서 구성될 수 있다.

이하에서 설명되는 클러스터는 도시된 복수 개의 노드(100) 중에서 하나 이상의 노드에 설치될 수 있다.

제어 노드(190)는, 통상적으로 데이터 센터(10)의 전반적인 동작을 제어한다. 이하에서 후술되는 데이터 센터(10)에 의한 동작은, 제어 노드(190)에 의해서 수행되어질 수 있을 것이다.

제어 노드(190)는 적어도 하나의 프로세서(191)를 구비하고, 데이터 센터(10)에 의한 동작을 수행하는 주체를 의미하며, 데이터 센터(10) 내외에 존재하는 특정 베어메탈 서버에 한정되지 않을 것이다. 즉, 단일 베어메탈 서버에 의해서 구현될 수도 있으며, 복수 개의 베어메탈 서버의 조합으로 구현될 수도 있을 것이다.

또한, 상술한 복수 개의 노드(100) 중 하나가 제어 노드(190)로서 동작할 수도 있으며, 특히 이하에서 후술되는 제네시스 노드나 자체 관리 노드가 제어 노드(190)로서의 역할을 수행할 수도 있다.

도 1에 도시된 구성요소들은 데이터 센터(10)를 구현하는데 있어서 필수적인 것은 아니어서, 본 명세서 상에서 설명되는 데이터 센터(10)는 위에서 열거된 구성요소들 보다 많거나, 또는 적은 구성요소들을 가질 수 있다.

도 2은 본 발명의 일실시예에 따른 복수 개의 노드 중 소정 노드(100)의 구성을 도시하는 도면이다.

도 2에 도시된 구성요소들은 노드(100)를 구현하는데 있어서 필수적인 것은 아니어서, 본 명세서 상에서 설명되는 노드(100)는 위에서 열거된 구성요소들 보다 많거나, 또는 적은 구성요소들을 가질 수 있다.

본 발명의 일실시예에 따른 컨테이너 오케스트레이션 플랫폼 상에서 IT 리소스를 관리하기 위하여 활용되는 노드(100)의 구성으로는, 클러스터 관리 API(101), 적어도 하나의 프로바이더(102) 및 베어메탈 프로비저닝 컴포넌트(103)가 존재할 수 있다.

클러스터 관리 API(101, Cluster API)란, 클러스터를 배포 및 운영하기 위한 API를 의미한다. 예를 들어, 쿠버네티스 클러스터를 배포/운영하는 상위 레이어 API 컴포넌트로서, 'Cluster API'를 들 수 있다.

클러스터 관리 API(101)는, 클러스터에 대한 관리 제공하는 선언적(declarative) API이다. 클러스터에 대한 관리는 프로비져닝, 업그레이딩 내지 오퍼레이팅을 의미한다.

클러스터 관리 API(101)는, 클러스터를 구축 및 관리하기 위한 상위 레이어의 API를 제공한다. 그리고 하위 레이어로서 적어도 하나의 프로바이더(102, provider)를 설정할수 있다.

프로바이더(102)는, 클러스터 관리 API에 의해서 구축된 타겟 클러스터에 대한 프로바이더와 클러스터를 구축하는 프로바이더로 구분될 수 있다.

클러스터 관리 API(101)에 의해서 구축된 타겟 클러스터에 대한 프로바이더로서, 'metal3', 'docker', 'openstack', 'GCP', 'AWS' 내지 'Azure'를 예로 들 수 있다. 예를 들어 'openstack'이 프로바이더로 설정된 경우에는 클러스터 관리 API가 생성하는 클러스터는 'openstack'에 의해 만들어진 VM들을 마스터 노드와 워커 노드로 사용하게 될 수 있다.

클러스터를 구축하는 프로바이더로, 'kubeadm'을 예로 들 수 있다.

본 발명의 일실시예에 따른 프로바이더(102)는, 베어메탈 프로비저닝 API 컴포넌트를 포함하도록 제안한다. 베어메탈 프로비저닝 API 컴포넌트는, 베어메탈 호스트에 프로비저닝을 수행하기 위한 컴포넌트이다.

본 발명의 일실시예에 따른 프로비저닝(provisioning)이란 사용자의 요구에 맞게 시스템 자원을 할당, 배치, 배포해 두었다가 필요 시 시스템을 즉시 사용할 수 있는 상태로 미리 준비해 두는 것을 말한다. 특정 노드 또는 특정 베어메탈 호스트에 프로비저닝을 수행한다는 것은, 그 특정 노드나 특정 베어메탈 호스트를 준비하기 위하여 필요한 동작 내지 프로세스를 수행하는 것을 의미할 수 있다.

베어메탈 프로비저닝 API 컴포넌트는 예를 들어 베어메탈 서버들에 클러스터를 구축하기 위해서는 클러스터 관리 API(101)가 베어메탈 프로비저닝 API 컴포넌트를 프로바이더(102)로 설정하여 사용할 수 있다.

쿠버네티스의 경우를 예로 들면 "Cluster API"를 클러스터 관리 API(101)로 사용할때 베어메탈에 쿠버네티스 클러스터를 구성한다면 프로바이더(102)로 'metal3'를 사용할 수 있다.

이하에서 설명되는 본 발명의 일실시예에서는 자체 관리 클러스터(ring0 cluster, self-managed cluster)에서 다른 클러스터를 생성하기 위한 프로바이더(102)로 'metal3'가 활용될 수 있다. 'metal3'는 베어메탈 호스트를 쿠버네티스에서 "bmh(bare metal host)"라는 CRD(CRD(Custom Resource Definition)란 쿠버네티스 플랫폼 상에서 사용되는 사용자 지정 리소스 정의)로 관리한다.

본 발명의 일실시예에 따른 '사용자 지정 리소스'란, "컨테이너 오케스트레이션 플랫폼에서 기본적으로 제공되는 기능 외에 사용자의 설정에 의해서 확장될 수 있는 기능을 제공하는 구성"을 의미한다. 그리고 '사용자 지정 리소스 정의'란, 사용자 지정 리소스를 정의하기 위한 설정값을 의미한다.

실제 각 베어메탈 호스트에 대한 메타데이터는 쿠버네티스에서 bmh CR 형태로 메타데이터가 관리된다.

'metal3'의 bmo(baremetal operator)가 이러한 bmh들을 참고하여 프로비저닝에 대한 동작(action)을 수행한다.

단, 실제로 베어메탈 서버에 action을 취하는 역할은 아래에서 설명하는 베어메탈 프로비저닝 컴포넌트(103)가 수행한다.

베어메탈 프로비저닝 컴포넌트(103)는 베어메탈 호스트에 정보를 취득(이하, 인스펙션(inspection)이라 함)하고 OS를 프로비저닝(provisoining, 설치)하는 역할을 수행한다.

예를 들어 베어메탈 프로비저닝 컴포넌트(103)는 'openstack'에서 베어메탈을 프로비저닝하는 프로젝트인 'ironic'을 포함할 수 있다. 'metal3'의 bmo가 bmh를 참고하여 'ironic'를 통해 실제 베어메탈에 대하여 인스펙션(inspection) 및 프로비져닝(provisioning)을 수행 한다.

이하에서는, 본 발명의 일실시예에 따른 관리 제어 방법 및 이를 설명하기 위한 개념도를 함께 참고하여 설명한다.

도 3는 본 발명의 일실시예에 따른 관리 제어 방법의 순서도를 도시하는 도면이다.

도 4 내지 도 7은 본 발명의 일실시예에 따른 클러스터 배포 제어 방법의 개념도를 도시하는 도면이다.

도 3의 순서도와 함께 도 4 내지 도 7의 개념도를 함께 참조하여 설명한다.

도 4은 본 발명의 일실시예에 따라 구성된 제네시스 노드(300)의 개념도를 도시한다.

S201 단계에서 데이터 센터는 제네시스 노드(300)를 구성한다. 본 발명의 일실시예에 따른 제네시스 노드(300)란, 가장 최초에 배포를 위한 도구(클러스터 관리 API(101), 프로바이더나 베어메탈 프로비저닝 컴포넌트(103) 등)를 구비하고 있는 노드를 의미하며, 마스터 노드일 수 있다.

제네시스 노드(300)를 구성하기 위하여, 데이터 센터는 OS를 설치하고, 상술한 도구들을 설치(클러스터 관리 API(101), 베어메탈 프로비저닝 API 컴포넌트를 포함한 적어도 하나의 프로바이더나 베어메탈 프로비저닝 컴포넌트(103) 등)할 수 있다.

이렇게 생성된 제네시스 노드(300)는, 다른 클러스터들을 관리할 수는 있지만 자기 자신에 대한 관리는 수행할 수 없다. 왜냐하면 다른 노드들(베어메탈 서버들)에 대한 bmh는 CRD로 등록하여 배포 및 관리가 가능하지만, 자기 자신이 속한 노드는 관리자에 의해 수동으로 설정된 노드이기 때문에 자신의 bmh는 등록하고 있지 않기 때문이다.

본 발명의 일실시예에 따른 데이터 센터는 OS 설치와 함께 제네시스 노드(300)에 쿠버네티스를 설치할 수 있다. 쿠버네티스의 설치 시, 아래와 같은 스크립트를 이용하여 수행될 수 있다. 즉, 쿠버네티스를 사용하기 위하여 필요한 도구들을 세팅하는 절차이다.

- 스크립트

1) proxy: 외부 소스들을 접근하기 위한 설정

2) keepalived: k8s master들의 HA(High Availability)를 위한설정

3) k8s: 컨테이너 오케스트레이션

3) docker / containerd: 컨테이너 런타임

4) kubeadm: k8s를 설치하기위한 provisioning 도구

5) k8s의 etcd 설정

6) helm: k8s에서 어플리케이션 배포를 위한 도구

8) cilium: k8s의 cni(container network internface)

9) node untaint: 마스터 노드도 스케줄링이 가능하도록 설정

본 발명의 일실시예에 따른 제네시스 노드(300)의 베어메탈 프로비저닝 API 컴포넌트는 자기 자신이 올라가기 위한 타겟 노드에 대한 CRD를 생성할 수 있다. 자기 자신이 올라가기 위한 CRD란, 자기 자신이 복제된 노드(자체 관리 노드) 및 이를 구성하는 클러스터를 생성하기 위한 CRD를 의미한다.

본 발명의 일실시예에 따른 컨테이너 오케스트레이션 플랫폼이 쿠버네티스일 경우, 생성되는 CRD는 아래와 같다.

1) bmh

- ironic을 이용해서 베어메탈 호스트를 관리하는 리소스

- bmh 하나당 물리머신 하나가 매핑된다

- 기본적인 장비의 정보들을 포함한다 (hostname / 이더넷 MAC 주소 / ipmi(Intelligent Platform Management Interface) 주소 등)

2) cluster

- cluster cr에는 클러스터 네트워크를 정의한다.

- k8s master의 endpoint를 정의한다

- cluster api용 CR

3) Metal3Cluster(프로바이더)

- capm(cluster-api-provider-metal3)에서 정의하는 k8s cluster CR

- cluster api에서 사용하는 metal3 provider 정의

4) KubeadmControlPlane(master 노드 정의)

- k8s 마스터를 올리기위한 정보들을 포함하고 있다.

- bootstrap(kubeadm 사용중) 관련 정보를 포함 하고 있다.

- metal3 teamplates를 통하여 이미지 및 k8s version을 정의 할 수 있다.

5) machinedeployment(worker 노드 정의)

- k8s 워커를 올리기위한 정보들을 포함하고 있다.

- k8s bootstrap(kubeadm) 및 metal3machineteampltes(이미지) 정의

- k8s의 deployment 와 비슷한 개념

6) machines

- 실제 k8s node 와 1:1 매칭이 된다.

- kubeadmconfig, metal3machine 정보를 가지고 있다.

- bmh에서 OS를 설치한(provisioned)정보를 매칭하고 있다. 이 정보는 metal3machine에 매칭되어 있다.

7) metal3machines

- bmh와 1:1 매칭

- metal3machinetemplates 의 이미지 정보를 가지고 있다.

8) Metal3MachineTemplate

- bmh의 노드 라벨(label)을 구분할 수 있는 정보를 가지고 있다.

- 머신(machine)이 올라갈 OS 이미지가 참조되어 있다.

상술한 CRD 중, bmh는 다른 CRD의 생성 시점과 무관하게 노드(베어메탈 서버)가 데이터 센터에 투입된 시점에 추가될 수도 있을 것이다. 즉, 특정 노드가 데이터 센터 내에 가용 자산이 되는 시점에 bmh가 추가될 수 있을 것이다. bmh의 등록은, 각 노드 마다 개별적으로 수행될 수 있으며, 노드에 대한 정보(hostname / eth0_mac/ipmi)를 'secret'으로 저장하고, 해당 'secret'을 활용하여 생성될 수 있다.

데이터 센터 내에 구비되는 복수 개의 노드(310) 중에서 부팅이 완료된 노드에 프로비저닝을 수행하기 위한 준비 단계로 진행할 수 있다. 노드의 전원이 온(on)된 경우 베어메탈 프로비저닝 컴포넌트(103)는 해당 노드에 대한 인스펙션을 수행할 수 있다.

S202 단계에서 데이터 센터는 자체 관리 노드에 대한 프로비저닝을 수행한다. 본 발명의 일실시예에 따른 자체 관리 노드란, 스스로에 대한 관리가 가능한 노드를 의미하며, 마스터 노드일 수 있을 것이다. 자체 관리 노드는 자체 관리 클러스터에 존재하는 적어도 하나의 노드에 속한 노드이다. 즉, 자체 관리 클러스터에는 자체 관리 노드와 함께 다른 유형의 노드가 함께 존재할 수 있다.

도 5는 본 발명의 일실시예에 따라, 복수 개의 노드 중에서 자체 관리 노드를 프로비저닝하기 위한 노드를 선정하고, 선정된 노드에 자체 관리 노드에 프로비저닝을 수행하는 개념도를 도시한다.

이를 위해서 본 발명의 일실시예에 따른 데이터 센터는 도 5에서와 같이 먼저 복수 개의 노드(310) 중에서 자체 관리 노드에 프로비저닝을 수행하기 위한 적어도 하나의 노드를 선정(도 5의 제1노드를 자체 관리 노드로 선정)할 수 있을 것이다. 이렇게 프로비저닝된 자체 관리 노드가 속한 클러스터를 자체 관리 클러스터(ring0 cluster)라고 부르기로 한다. 자체 관리 노드는, 자체 관리 클러스터에 포함되어 있는 단일 노드에 프로비저닝 될 수 있을 뿐만 아니라, 자체 관리 클러스터에 포함되어 있는 복수 개의 노드에 걸쳐 프로비저닝 될 수도 있다.

이어서 제네시스 노드(300)는 S203 단계에서 프로비저닝된 자체 관리 노드에, 자기 자신을 복제한다. 본 발명의 일실시예에 따른 복제란, 제네시스 노드(300)를 구성하는 클러스터 관리 API(101), 적어도 하나의 프로바이더(102), 베어메탈 프로비저닝 컴포넌트(103) 및 제네시스 노드(300)에 정의된 CRD 중 적어도 하나를 그 상태 값들을 유지하여 자체 관리 노드(401)로 복제하는 것을 의미한다.

이때, 복제된 CRD에는 제네시스 노드(300)를 구성하는 베어메탈 서버에 대한 bmh는 포함되어 있지 않을 것이다. 본 발명의 일실시예에 따른 데이터 센터는, CRD가 자체 관리 노드(401)로 복제된 후, 제네시스 노드(300)를 구성하는(구성하던) 베어메탈 서버에 대한 bmh를 추가로 저장하도록 제안한다. 즉, 제네시스 노드(300)를 type c2로 가정하면, 제네시스 노드(300)가 삭제된 후 해당 베어메탈 서버(노드)를 워커 노드나 다른 클러스터의 마스터 노드로 활용할 수 있을 것이다.

이어서, 자체 관리 노드(401)에 ip 등 네트워크 설정값들은, 이전 제네시스 노드(300)의 값들과 동일하게 설정되어 있을 것이다. 왜냐하면 제네시스 노드(300)에 대해서 그대로 복제가 이루어졌기 때문이다. 본 발명의 일실시예에 따른 데이터 센터는 네트워크 설정값을 자체 관리 클러스터(401)에 맞게 수정하여, 자체 관리 노드(401)에 접근할 수 있도록 한다.

도 6는 본 발명의 일실시예에 따라, 자체 관리 노드(401)에 프로비저닝을 수행하고 자체 관리 노드(401)에 제네시스 노드(300)가 복제된 뒤, 기존 제네시스 노드(300)를 삭제하는 개념도를 도시한다.

이후, S205 단계에서 데이터 센터는, 제네시스 노드(300)를 삭제(도 6 참조)한다. 제네시스 노드(300)는 자체 관리 노드(401)를 생성(배포)하기 위하여 존재하던 노드로서, 자체 관리 노드(401)가 생성된 이후에는 필요가 없어 지기 때문이다. 자체 관리 노드(401)는, 제네시스 노드(300)가 삭제된 해당 베어메탈 서버의 bmh를 CRD에 추가로 저장하여, 해당 베어메탈 서버를 다시 활용(도 6에서와 같이 제4노드(310-4)로 활용)할 수 있음은 앞서 설명한 바와 동일하다.

한편, S205 단계의 수행은, S203 단계에서 복제가 완료된 후라면 어느 시점에 이루어지든 상관 없다. S206 단계 이후나 함께 수행될 수 있다.

도 7은 본 발명의 일실시예에 따라, 프로비저닝이 이루어진 자체 관리 노드(401)가 복수 개의 노드에 다른 클러스터를 생성 및 배포하는 개념도를 도시하는 도면이다.

S206 단계에서 데이터 센터는, 도 7에 도시된 바와 같이, 자체 관리 노드(401) 내지 자체 관리 클러스터로부터 자체 관리 클러스터에 속해 있는 또 다른 노드에 대하여 배포 및 관리 동작을 수행하거나, 다른 클러스터를 생성 및 배포한다. 이때 다른 클러스터라 함은, 자체 관리 노드(401)가 속해 있는 자체 관리 클러스터가 아닌 클러스터를 의미한다.

도 7을 참고하여 좀 더 상세히 설명하면, 자체 관리 노드(401)는 자체 관리 클러스터(801)에 포함되어 있는 다른 노드인 제2노드(310-2)에 배포 및 관리 프로세스를 수행할 수 있다.

또한, 자체 관리 노드(401)는, 다른 클러스터(자체 관리 클러스터 외의)인 제2 및 제3 클러스터(802, 803)에 속해 있는 제3노드(310-3)나 제5노드(301-5)에도 배포 및 관리 프로세스를 수행할 수 있다.

이러한 생성 및 배포는, 일반적인 클러스터의 생성 및 배포 동작과 동일할 것이다. 예를 들어 쿠버네티스의 'Cluster API'에 구성된 'metal3' 플러그인을 통하여, 다른 클러스터의 생성 및 배포를 수행할 수 있다. 클러스터에 속한 베어메탈 서버의 bmh를 로드하고, 생성하고자 하는 클러스터를 위한 CRD를 생성한다. 생성된 CRD에 기초하여, 다른 노드(310)들에 클러스터를 생성 및 배포할 수 있다. 이때, 다른 노드(310)에는 기존 제네시스 노드(300)가 존재하던 제4노드(310-4) 역시 존재할 수 있다.

도 8은 본 발명의 일실시예에 따른 자체 관리 노드(401)에 의해서 생성된 클러스터에 포함되어 클러스터를 구성하는 제1 내지 제3 노드(310-1 ~ 310-3)를 도시하는 도면이다.

도 8을 참고하면, 상술한 자체 관리 노드(401)에 의해서 제1 내지 제3 노드(310-1 ~ 310-3)에 OS가 프로비저닝되고, 하나의 클러스터를 구성되는 것을 확인할 수 있다.

이와 같은 방법으로 생성된 클러스터는, 자체 관리 노드(401)에 의해서 관리될 수 있을 것이다. 그 뿐만 아니라, 자체 관리 노드(401) 자신에 대한 관리 역시 스스로 수행할 수 있을 것이다.

이상으로 본 발명에 따른 클라우드 데이터 센터를 관리하는 제어 방법의 실시예를 설시하였으나 이는 적어도 하나의 실시예로서 설명되는 것이며, 이에 의하여 본 발명의 기술적 사상과 그 구성 및 작용이 제한되지는 아니하는 것으로, 본 발명의 기술적 사상의 범위가 도면 또는 도면을 참조한 설명에 의해 한정／제한되지는 아니하는 것이다. 또한 본 발명에서 제시된 발명의 개념과 실시예가 본 발명의 동일 목적을 수행하기 위하여 다른 구조로 수정하거나 설계하기 위한 기초로써 본 발명이 속하는 기술분야의 통상의 지식을 가진 자에 의해 사용되어질 수 있을 것인데, 본 발명이 속하는 기술분야의 통상의 지식을 가진 자에 의한 수정 또는 변경된 등가 구조는 청구범위에서 기술되는 본 발명의 기술적 범위에 구속되는 것으로서, 청구범위에서 기술한 발명의 사상이나 범위를 벗어나지 않는 한도 내에서 다양한 변화, 치환 및 변경이 가능한 것이다.

Claims

프로세서를 구성하는 제어 노드에 의해서 수행되는 클라우드 데이터 센터를 관리하는 제어 방법에 있어서,
제네시스 노드를 구성하는 단계;
자체 관리 노드(self-managed node)에 프로비저닝을 수행하는 단계;
상기 제네시스 노드를 상기 자체 관리 노드에 복제하는 단계; 및
상기 제네시스 노드를 제거하는 단계를 포함하는,
클라우드 데이터 센터를 관리하는 제어 방법.
제 1 항에 있어서, 상기 제네시스 노드를 구성하는 단계는,
상기 제네시스 노드에 OS(Operating system), 클러스터 관리 API 및 베어메탈 프로비저닝 컴포넌트 중 적어도 하나를 설치하는 단계를 포함하는,
클라우드 데이터 센터를 관리하는 제어 방법.
제 2 항에 있어서,
상기 제네시스 노드가 자기 자신이 올라가기 위한 타겟 노드에 대한 사용자 지정 리소스 정의를 생성하는 단계를 더 포함하는,
클라우드 데이터 센터를 관리하는 제어 방법.
제 3 항에 있어서, 상기 프로비저닝을 수행하는 단계는,
상기 설치된 베어메탈 프로비저닝 컴포넌트가 상기 프로비저닝을 수행하는,
클라우드 데이터 센터를 관리하는 제어 방법.
제 1 항에 있어서,
상기 자체 관리 노드 및 상기 제네시스 노드 중 적어도 하나는 마스터 노드인,
클라우드 데이터 센터를 관리하는 제어 방법.
제 3 항에 있어서, 상기 프로비저닝하는 단계는,
복수 개의 노드 중에서 프로비저닝 대상이 되는 상기 자체 관리 노드를 선정하는 단계를 포함하는,
클라우드 데이터 센터를 관리하는 제어 방법.
제 6 항에 있어서, 상기 프로비저닝하는 단계는,
상기 선정된 노드에 대한 정보를 수집하는 단계를 더 포함하되,
상기 수집되는 정보는, 하드웨어 정보, 펌웨어 정보, 호스트명(hostname), 네트워크 카드 정보, 스토리지 정보 및 시스템 벤더 정보 중 적어도 하나를 포함하는,
클라우드 데이터 센터를 관리하는 제어 방법.
제 7 항에 있어서, 상기 프로비저닝하는 단계는,
상기 생성된 사용자 지정 리소스 정의에 기초하여 상기 선정된 자체 관리 노드에 프로비저닝하는 단계를 더 포함하는,
클라우드 데이터 센터를 관리하는 제어 방법.
복수 개의 노드 및 상기 복수 개의 노드를 제어하기 위한 프로세서를 구비하는 제어 노드를 포함하도록 구성되는 데이터 센터에 있어서,
상기 복수 개의 노드 중 제1노드에 설치되는 제네시스 노드를 포함하도록 구성되고,
상기 제네시스 노드는,
상기 복수 개의 노드 중 제2노드에 자체 관리 노드를 프로비저닝하고,
상기 프로비저닝을 수행한 후, 자신을 상기 자체 관리 노드에 복제하며,
상기 복제된 후 상기 제네시스 노드는 상기 제1노드에서 삭제되는,
데이터 센터.
제 9 항에 있어서, 상기 제네시스 노드의 설치는,
상기 제1노드에 OS(Operating system), 클러스터 관리 API 및 베어메탈 프로비저닝 컴포넌트 중 적어도 하나를 설치하는,
데이터 센터.
제 10 항에 있어서, 상기 제네시스 노드는,
자기 자신이 올라가기 위한 타겟 노드에 대한 사용자 지정 리소스 정의를 생성하는,
데이터 센터.
제 11 항에 있어서, 자체 관리 노드의 프로비저닝은,
상기 제네시스 노드에 설치된 베어메탈 프로비저닝 컴포넌트에 의해서 수행되는,
데이터 센터.
제 9 항에 있어서,
상기 자체 관리 노드 및 상기 제네시스 노드 중 적어도 하나는 마스터 노드인,
데이터 센터.
제 11 항에 있어서, 상기 제네시스 노드가 상기 프로비저닝을 수행하는데 있어서,
상기 복수 개의 노드 중에서 제2노드를 자체 관리 노드를 프로비저닝하기 위한 대상 노드로 선정하는,
데이터 센터.
제 14 항에 있어서, 상기 제네시스 노드가 상기 프로비저닝을 수행하는데 있어서,
상기 대상 노드로 선정된 제2노드에 대한 정보를 수집하되,
상기 수집되는 정보는, 하드웨어 정보, 펌웨어 정보, 호스트명(hostname), 네트워크 카드 정보, 스토리지 정보 및 시스템 벤더 정보 중 적어도 하나를 포함하는,
데이터 센터.
제 9 항에 있어서, 상기 제네시스 노드가 상기 프로비저닝을 수행하는데 있어서,
상기 생성된 사용자 지정 리소스 정의에 기초하여 상기 선정된 자체 관리 노드에 프로비저닝하는,
데이터 센터.