오픈 클라우드 컴퓨팅 인터페이스 번역(영어 원본)1. Introduction
This document includes all the Use Cases and requirements which were gathered in the working group.
This document is organized in to three sections: Use Cases, Requirements and a comparison matrix of current Cloud APIs. In this document, Use Cases are defined by name and a set of functional and non-functional requirements. All requirements are catagorized and formatted in tables. Each requirement is (whenever possible) mapped to a Use Case. Priorities have been assigned to all requirements. The Cloud API comparison matrix itemizes generalized and detail features of each API and indicates which API supports each feature.
2. OCCI Use Cases
The following section describes the Use Cases which were gathered during the requirements analyses for the OCCI working group. They are used to set up the requirements and later on to verify the OCCI specification.
2.1. SLA-aware cloud infrastructure using SLA@SOI
There is a need for a standard interface for dynamic infrastructure provisioning. While doing so it must be guaranteed and verified that the infrastructure provisioning uses ‘machinereadable’ SLAs. (SLA_SOI)
Functional Requirements
• VM Description: request format important – In this area is where there is least coherency amongst providers.
• VM Description: a means to add non-functional constraints on functional attributes.
• VM Management: all parameters in the request should be “monitor-able” and verifiable. Full control of resources (VMs) allocated required; at a minimum: start, stop, suspend, resume.
• VM Monitoring: Monitoring non-functional constraints declared in provisioning request
• Network Management: resources assignable by network tag – defaults of public and private further sub-categorisation could be allowed e.g. tag of web could be assigned to the public network group.
• Storage Management: simple mount points, reuse storage SaaS offerings Non-functional Requirements
• Security: Transport and user level (ACLs? oAuth?) security
• Quality of Service: Can be many – Part of service offering from the infrastructure provider e.g. Security, QoS, geo-location, isolation levels – NFPs are the basic building blocks of differentiating IaaS providers.
• Scheduling Information: When a particular resource is to be run. Also in which order should a collection of resources be ran in the case that one resource is dependent on another.
2.2. Service Manager to control the Life cycle of Services
This Use Case is based in the ‘Service Manager’ (SM) layer of the RESERVOIR project architecture. ‘Service Providers’ (SP) willing to deploy their service on the Cloud use this layer to control the service life cycle. The SM operates over the Cloud infrastructure automatically as the service demands. In a way, the SM maps the service configuration and needs to calls to the Cloud infrastructure, so many of the requirements imposed by the SM are due to the flexibility that the SM aims to provide to SPs. ( RV )
Functional Requirements
• Network Management: There should be methods for the Allocation of private networks, where VMs can be attached to. A special network (e.g. ‘Public Network’) should be available. When some network interface is attached to it, the infrastructure must assign a public IP address.
• Image Management: There should be methods to register, upload, update and download disk images.
• VM Description: It should be possible to describe all the VM hardware components and their attributes, along with any restriction regarding the VM location:
• Memory: Size
• CPU: Architecture, amount of CPU’s and speed.
• Disk: Size, Interface (SCSI, IDE, SATA…), RAID (yes/no, and RAID level), Disk image to mount, Automatic backup (yes/no, backups frequency…).
• Network: Interfaces, for each interface its bandwidth, and Network they are attached to.
• Geographical restrictions: Location(s) where the VM can/cannot be deployed (for example for legal purposes).
• Migration allowed (yes/no): If migration is supported by the infrastructure, this flag sets if it is allowed for the VM.
• VM Management: There should be methods to allow the SM to change the VM state (for example, from ACTIVE to SUSPENDED), if such transition is allowed by the infrastructure (i.e. is defined in the OCCI’s State Machine). The description of a VM can be changed when the machine is running (ACTIVE, SUSPENDED…). But it will not be taken into account until the machine is stopped and started again, unless it is a change regarding geographical or migration restrictions. Each disk backup will have an id, as the images defined by the SM. Methods to download any backup should be provided. As each backup is, after all, a disk image, it should be possible to mount it on any VM. For example, it should be possible to stop a VM, change its configuration so its disk mounts this backup image, and restart the VM.
• Monitoring: The status (We use the term ‘status’ when talking about monitoring, and try not to use the term ‘state’ to avoid confusion with the states of the OCCI State Machine.) representation of any element is given as a list of keys and their values. For example, the status of a memory component could be given by the amount of memory used and the cache memory. Then, the keys could be: ‘used’ and ‘cache’ with the values ‘142MB’ and ‘430MB’. Both the request and the reply use the corresponding element identifier. Two types of monitoring should be supported:
• Pull based: The SM can request the status of any element it has registered: VMs, networks… Also, the SM can request the status of components, for example, the status of certain disk of a certain VM.
• Publish/subscribe based: The SM can subscribe to be notified about events on the VMs and/or Networks. Some of the events to be notified are:
• Errors on some component of a VM.
• Changes on the state of a VM (e.g. from ACTIVE to SUSPENDED).
• Periodic notifications about some element state. The frequency of this notifications can be configured in the subscription message.
• Error messages: If a VM could not be created, or a image could not be uploaded, etc… the platform should return an error message carrying a detailed description of the reason.
• Identifications: Networks, VMs and images should have unique IDs, (UUIDs, URIs, or the like). It is to be determined whether components of VMs (disks, memory…) should have an unique ID too. IDs are assigned by the Cloud infrastructure when the corresponding element is created.
Non-functional Requirements
• Both for hardware configuration and monitoring values there should be a clear, standard way to set which magnitude the value represents. For example, when setting the memory size to ‘2’, it must be clear that we refer to GBs and not to MBs. An option would be setting the value to ‘2GB’, another would be allowing to set both the value and the magnitude: value ‘2’ and magnitude ‘GB’.
• Protocols: The transport, message format, and state representation should use open and standard protocols, each one which strong software support (i.e. libraries and frameworks available for several programming languages). |
오픈 클라우드 컴퓨팅 인터페이스 번역(한국어 번역본)1. 머리말
본 문서에는 실무그룹에서 취합한 모든 Use Cases와 요건이 수록되어 있다. 본 문서는 다음의 세 부문으로 구성되어 있다. 현행 클라우드 APIs Use Cases, 요건, 비교 매트릭스. 본 문서에서 usecases는 명칭과 기능 요건 그리고 기능 이외의 요건에 따라 규정된다. 모든 요건은 분류되고 표로 구성되어 있다. 각각의 요건은 (가능한 경우) Use Cases별로 맵핑되어 있다. 모든 요건마다 우선순위를 정하였다. 클라우드 API 비교 매트릭스는 각 API의 일반적이고 구체적인 특성을 항목별로 기술하고 어떤 API가 각각의 특성을 지원하는지를 나타낸다.
2. OCCI Use Cases
아래의 절들에는 OCCI 실무그룹이 요건을 분석하면서 취합한 Use Cases들이 설명되어 있다. 이는 요건을 수립하고 이후 요건에 따라 OCCI 규격을 검증하는데 이용된다.
2.1. SLA@SOI를 이용하는 SLA-인식 클라우드 인프라
동적 인프라 프로비저닝을 위한 표준 인터페이스가 필요하며, 반드시 인프라 프로비저닝 시 ‘기계 판독이 가능한’ SLAs (SLA_SOI)가 이용되도록 보장하고 확인하여야 한다.
기능 요건
• VM 디스크립션(description): 중요한 요청 형식 – 이 분야는 공급자들 간에 적어도 일관성이 있다.
• VM 디스크립션: 기능 속성에 기능 이외의 제약을 부가하는 수단
• VM 관리: 요청 시 모든 변수는 “모니터링 가능”하고 검증 가능해야 할 것이다. 할당된 자원에 대한 완벽한 제어 (VMs)에는 최소한 다음이 요구된다. 시작, 중단, 일시 중지, 재개 (start, stop, suspend, resume).
• VM 모니터링: 프로비저닝 요청 시 선언된 기능 이외의 제약 모니터링
• 네트워크 관리: 공용 및 사설로 세분화화여 하위 범주화한 네트워크 기본 태그로 자원을 할당할 수 있다. 예를 들어, 공용 네트워크 그룹에는 웹 태그가 할당될 수 있다.
• 저장 관리: 단순한 마운트 지점, 저장 SaaS 오퍼링 재사용
기능 이외의 요건
• 보안: 전송 및 사용자 수준 (ACLs? oAuth?) 보안
• 품질 관리: 다양할 수 있다. – 예를 들어, 보안, QoS, 위치 정보, 고립화 수준과 같은 인프라 공급자의 서비스 오퍼링 부분 – NFPs는 IaaS 공급자를 구별하는 기본 빌딩 블록이다.
• 일정 정보: 특정 자원이 구동되는 때. 또한 자원이 다른 자원에 의존해 있는 경우, 자원을 수집해야 하는 순서
2.2. 서비스 수명주기를 제어하기 위한 서비스 관리
본 usecases는 RESERVOIR 프로젝트 아키텍처의 ‘서비스 관리’ (SM) 층에 근거를 두고 있다. 클라우드에 자신들의 서비스를 배치하고자 하는 ‘서비스 공급자’ (SP)는 이 층을 이용해 수명주기를 관리한다. SM은 서비스 요청과 마찬가지로 클라우드 인프라 상에서 자동 운영된다. SM은 어느 정도 서비스 구성을 맵핑하고 클라우드 인프라에 요청을 해야 하므로 SM으로 인해 부과되는 다수의 요건들은 SM이 SPs에 제공하고자 하는 확장성에 기인한다. (RV)
기능 요건
• 네트워크 관리: VMs을 연결할 수 있는 사설 네트워크 할당 방법이 있어야 한다. 특수한 네트워크 (예를 들어, ‘공용 네트워크’)를 이용할 수 있어야 한다. 일부 네트워크 인터페이스를 연결하는 경우, 인프라는 반드시 공용 IP 주소를 할당해야 한다.
• 이미지 관리: 디스크 이미지를 등록, 업로드, 업데이트, 다운로드할 수 있는 방법이 있어야 한다.
• VM 디스크립션: VM 위치 제한에 따라 모든 VM 하드웨어 구성품과 이의 속성을 기술할 수 있어야 한다.
• 메모리: 크기
• CPU: 아키텍처, CPU 량과 속도
• 디스크: 크기, 인터페이스 (SCSI, IDE, SATA…), RAID (yes/no, and RAID level), 마운트하는 Disk 이미지, 자동 백업 (yes/no, 백업 횟수…).
• 네트워크: 인터페이스, 각 인터페이스의 대역, 인터페이스가 연결되는 네트워크
• 지리적 제약: VM이 배치될 수 있는 장소/배치될 수 없는 장소 (예를 들어, 법적 목적에 따라)
• 이주 허용 (yes/no): 인프라가 이주를 지원한다면, VM이 이를 허용하는 경우, 이러한 플래그(flag)를 설정한다.
• VM 관리: 인프라가 그러한 변경을 허용한다면 (즉, OCCI 상태 기계에서 정의된), SM이 VM 상태를 변경시킬 수 있는 방법이 있어야 한다 (예를 들어, ACTIVE에서 SUSPENDED로). VM 디스크립션은 기계가 구동될 때 변경될 수 있다 (ACTIV, SUSPENDED…). 그러나 지리적 또는 이주 제약과 관련된 변경이 아닌 한, 기계가 중단되고 다시 구동될 때까지 이는 고려되지 않을 것이다. 각각의 디스크 백업마다 SM에 의해 정의된 이미지와 마찬가지로 ID가 있을 것이다. 백업을 다운로드하는 방법을 제공해야 한다. 각각의 백업은 결국 디스크 이미지이므로, VM에 마운트할 수 있어야 한다. 예를 들어, VM을 중단시키고 이의 구성을 변경시켜 디스크가 이러한 백업 이미지를 마운트하고 VM을 재구동시킬 수 있어야 한다.
• 모니터링: 요소에 대한 현황 (모니터링에 관해 이야기할 때는 ‘현황 (status)’이라는 용어를 이용해 OCCI 상태 기계의 상태와 혼동하지 않도록 한다) 이는 키와 그 값의 리스트로 표시한다. 예를 들어, 메모리 컴포넌트의 현황은 이용된 메모리와 캐시 메모리의 양으로 나타낼 수 있다. 키는 다음과 같을 수 있다: ‘이용된’과‘ 142MB’와 ‘430MB’의 ‘캐시’값. 요청과 응답에는 모두 이에 상응하는 요소 식별자가 이용된다. 두 가지 유형의 모니터링이 지원되어야 한다.
• Pull based: SM은 VMs, 네트워크 등 등록된 요소의 현황을 요청할 수 있다. 또한 SM은 컴포넌트의 현황도 요청할 수 있다. 예를 들어, 특정 VM의 특정 디스크 현황.
• 발행/구독: SM은 VMs 및/또는 네트워크와 관련된 고지를 받기 위해 구독을 할 수 있다. 고지되어야 하는 이벤트는
• 일부 VM 컴포넌트의 오류
• VM 상태 변화 (예를 들어, ACTIVE에서 SUSPENDED로)
• 일부 요소 상태에 대한 정기적 고지. 이러한 고지의 횟수는 구독 메시지에서 설정할 수 있다.
• 오류 메시지: VM을 생성할 수 없거나 이미지를 업로드할 수 없는 등의 경우, 플랫폼은 이유를 상세하게 설명하는 오류 메시지를 반환해야 한다.
• 식별: 네트워크, VMs, 이미지에는 고유 ID (UUIDs, URIs 또는 유사한 것)가 있어야 한다. VMs의 컴포넌트에도 고유 ID가 있는지 확인해야 한다. IDs는 해당 요소가 생성될 때 클라우드 인프라에서 할당된다.
기능 이외의 요건
• 하드웨어 구성과 모니터링 값은 모두 명확한 표준방식으로 그 값이 나타내는 어떤 크기를 설정해야 한다. 예를 들어, 메모리 크기를 ‘2’로 설정하는 경우, 이는 반드시 MBs가 아니라 GBs를 의미하는 것임이 명백해야 한다. 어떤 옵션에서는 메모리 크기가 ‘2GB’로 설정될 것이며, 다른 옵션에서는 값 ‘2’와 ‘GB’로 값과 크기가 모두 설정될 것이다.
• 프로토콜: 전송, 메시지 포맷, 상태 표시에는 강력한 소프트웨어에 의해 지원되는 (즉, 몇몇 프로그래밍 언어에 사용할 수 있는 라이브러리와 프레임워크) 개방형 표준 프로토콜이 이용되어야 한다. |
