g cube openstack solution

This information is confidential and was prepared by G-Cube solely for the use of our client and investor; it is not to be relied on by any 3rd party without G-Cube's prior written consent

G-Cube OpenStack Solution

G-Cube Inc.

2This information is confidential and was prepared by G-Cube solely for the use of our client and investor; it is not to be relied on by any 3rd party without G-Cube's prior written consent 141028-IR-Business proposal v05SEO

G-Cube OpenStack Solution

• Data Defined Storage (DDS)

-Integrated data-centric management architecture

-Storing, retaining, and accessing data based on content, meaning, and value.

-Core technology

Media Independent Data Storage

Data Security & Identity Management

Distributed Metadata Repository

http://en.wikipedia.org/wiki/Data_Defined_Storage


Software Defined Storage vs Data Defined Storage

Software Defined Storage

• Storage-centric

management

• User manages storage.

• SDS decribes storage.

• Human (should) know

-Storage features

Data Defined Storage

• Data-centric management

• User describes data

• DDS manages storage

• DDS (should) know

-Data description


In Storage Centric Management

Architecture

Deliver package 1 until tomorrow, package 2 until this weekend, package 3 until this month…

what they do

Who deliver? by human (admin) high-cost , low-efficient.


In Storage Centric Management

Architecture


what they do

Who deliver?• automated by existing

solutions unsatify


In Data Centric Management

Architecture


what they do

package 1 via airli

ne, package 2 by t

ruck…

what we(will) do

Data description

Who deliver?automated & unified management low-cost & high-efficient satisfy users!


Data Defined Storage의 필요성

• 서비스뿐만아니라스토리지도더이상 flat 하지않다.

-Multi-Tenant Service

New service frameworks: Cloud, VDI, Big-data.

Traditional services: DB, WAS, Multimedia...

-Multi-Aspect Storage

예전: 시스템메모리 + 하드디스크 (Enterprise or Personal)

지금: 메모리 + SSD + HDD + cloud storage

- 비휘발성메모리소자(DRAM, NAND Flash, MRAM, FeRAM) 인터페이스/프로토콜 (SATA/SAS, PCI-E NVME), 하드웨어 (SLC/MLC/TLC, rpm,

redundancy-level), 위치인접성 (Local DAS, SAN, WAN)

• Media Independent Data Storage 솔루션이필요.

-관리자및사용자가복잡한 storage 특성을이해하여효율적으로 data를 mapping하는것이불가능.

• Data I/O는무조건고성능이아니라, 사용자가원하는수준에가장맞는데이터입출력서비스를제공.

-최소의비용으로전체적으로 최적의 service quality를보장.


G-Cube OpenStack Solution의 시장 예상

• 적용이가능/비교적용이한시장

-Private cloud provider

Game publishers, 중소기업규모의가상머신/VDI 환경, 포털사, 대학/기관/기업의전산센터.

서비스사용자와제공자가동일하거나 tightly-coupled 되어있어서비용절감이나서비스품질개선을통해서 TOC 감소가중요한시장.

다양한특성의데이터 (게임데이터, 블로그/홈페이지, 미디어, 이미지, 사용자/고객계정등) 가통합관리되고있는환경.

-Big data infra, SNS service provider

방대한양의데이터가존재하고해당데이터의유지및관리비용이높음.

데이터의양과사용자수가폭발적으로증가함에따라전체서비스질저하/용량부족에따른장비의추가및확장이빈번함.

-TCO나성능에대한요구사항, 그리고 scale-out을위해서도입할장비및솔루션의구매 license 비용이새로운 OpenStack solution 도입을위한개발소요비용에비해서상당히높은시장.

관련내부개발인력을보유한경우시장진입이보다유리.


G-Cube OpenStack Solution의 시장 예상

• 적용이 (당장) 힘든시장

-Public cloud infra provider

Amazon Web Service, Google Cloud Service, Microsoft Cloud Service…

궁극적인시장경쟁자.

서비스사용자와제공자가 loosely-coupled 또는분리된 scale-out data storage

service 환경을 economics of scale에의해비용효율적으로 제공. (e.g., 대용량배송서비스)

기업형 cloud 분야에서 QoS에따른 node/storage 구성을달성. (e.g., 특급배송서비스)

-Enterprise storage market

Oracle, SAP.

ACID와같은높은데이터신뢰도가중요.

오랜기간동안검증된서비스및제품에대한안정성 references가보장되어야진입이용이.


G-Cube OpenStack Layers

block device driver nvme driver

osd device : container

osd virtualization- cluster : Portal

cluster/cloud frame works, applications

-다수의 device를 묶어제공. -정해진 data 속성에따라 device 활용-하부 device의 속성, 상태 및 data 속성에따른 동작등을 query, set

- network을 통해다수의 osd device를 통합제공- local osd device와일관된 interface를 통해속성,상태등 의 query, set을 제공(storage 이외의 network등의정보 추가)- local osd device의정의 범위에따라서는단순한 mapping 만 수행하는 layer로 축소될 수 있음

-key - value system-big data analysis-global file systemetc.

local resource mgmt : repository

memory, cpu 등 storage뿐 아니라 node resource를 통합하여, 관리하며해당 resource를 이용한service 제공 ( caching 등)

storage hardware (memory, SSD, HDD)

single node boundary

cluster boundary

virtual storage boundary

physical storage boundary


Layers & their key roles

portal (dock)

repository

container

device

coordination cluster-level namespace (object – node) network distributed functions scheduler

local resource management node-level local functions namespace (object – container) scheduler

local storage management device-level namespace (object - LBNs)

representing a block device file which can representhdd/ssd/ramdisk , array, networked device, logical volume, partition, and so on.

talk to container with a feature set


Service data description & parameter flow

streaming avi

portal

cache가빨라야하고. multi user access 를고려하면 network도..

repository

sequential, multi read, large!

난 cache도커서 sequential multi read는 I/O 별로안해도되니, 용량만큰데로넣으면되겠네

container

large!!

크기만신경쓰면되네.. 그럼싼 HDD로..


Operating Scenario - Terms

container boundary

Node boundary

status

from the point of not only performance such as responsiveness, throughput, but also functionality like reliability, continuity, and functionality

Container is a virtual storage device which can be represented as one dimensional array as follows- a single device (SSD, HDD,

Ramdisk)- a bunch of disks (e.g. disk array)- hybrid storage (DRAM, SSD, HDD)- and their networking storage

Tenant is an agent (module) who has one or more data I/O streams as follows- Application (mobile, PC)- Server (WAS, DB) and its I/O

agents (WAS cgi-bin module, DB storage engine, logging module)

- VM Hypervisor I/O module- server-side I/O agent in NAS

and SAN- Filesystem server I/O agent- …


DATA IN/OUT Requirement (기존방식)

status

data data data data

data in/out(rw)

tenant(user,server)

mapper가보는 node containers의 위상 :=

flat

스토지와 data 매핑 기준 : falut-resilience & load-balance & size



status

data data data datadata in/out(rw)

tenant(user,server)

cluster container의위상 (e.g., In multi-

apects, read responsiveness )

mapping considerations: falut-resilience & load-balance & ?(mapping takes no advantage of status per container even if it is known)

e.g. HDD

e.g. SSD

e.g. Ramdisk



status


tenant(user,server)

mapping considerations: falut-resilience & load-balance & ?(mapping takes no advantage of status per container even if it is known)

tenants가 요구하는read responsivenss

의 위상over-statisfied

unstatisfied unstatisfied

statisfiedover-statisfied


DATA IN/OUT Requirement (G-Cube approach)

status


tenant(user,server)

mapping considerations: falut-resilience & load-balance & in/out requirement from tenants (schedule)

tenants가 요구하는read responsivenss

의 위상

All-statisfied


G-Cube OpenStack Interfaces

portal

repository

container

device

Local interfaces Remote interfaces

block others openstack block others openstack

block interfaces

POSIX file interfaces,

RESTful API,key-value,Swift…

dynamic field interfaces (like

stub)

ioctl (network)

block interfaces POSIX file interfaces,

RESTful API,key-value,Swift…

dynamic field interfaces (like stub)

ioctl (network)

block openstack block openstack

block interfaces dynamic field interfaces (like stub)

ioctl

block interfaces(SAN)


ioctl

block openstack block openstack

block device file(bio interface)

SAN


ioctl

block device file dynamic field interfaces (like stub)

ioctl

block osd block osd

block device file(bio interface)

ioctl N/A N/A


G-Cube OpenStack Data Description

• Service level에서의 data description-Sequentiality vs Randomness in IO system

Service level의 data에서는 sequential, random 의접근이단순히 I/O 뿐만아니라processing의의미도들어감.

Sequential : streaming , image (single), contents body 와같이전체 data를 처음부터읽어서 service하는종류들

Random : VOD (player의 메뉴상 tracker를마우스등으로찍어서움직이는것들.

youtube 등), image set

-Concurrency: 단일 data에대한 sequential 접근뿐아니라, 동일 key 혹은type에대한접근방식또한정의를필요로함.e.g., Prefetching.

-BLOB: Data 접근의특이성이없거나파악이힘든경우 (e.g, 가상머신 guest

OS image) large-size의 binary object로보고, 요구사항에맞게데이터를처리.

-No archive data : service level에서의 data의경우, archive data는거의존재하지않음.archive 의경우는별도의 process를통해 backup등을수행함



• G-Cube OpenStack interface 요구사항 : object type에대한정의를하면서해당 type data에대한 description을할수있어야함-e.g. contents title, writer, image thumbnail 등

• Classification: 일반적인 data type에대해서는미리세부 parameter를정의하여, 단순화된 interface로사용할수있도록제공.

• Service 운용수준에서보면, 크게 on-line data를위한 sequential /

random I/O & processing 에대한정의와 off-line data를위한정의정도로볼수있음.-세부적인사항은개별 service 별특징으로처리해야하며, 일반화불가능함.



• Considerations -data (object) 에대한것과 data relation (object type) 에대한것이필요함

• Application (web?) service data attributes dimensions-process isolation in single data (or relative data) : portal layer와 관련.

-number of concurrent access : portal, repository, (container)

-I/O randomness : portal, repository, container

-size of data (or relative data) : portal, repository, container

• Application service data 의경우 storage 에서자주언급하는, read/write pattern

은불필요.-On-line service 되는 data의거의대부분이 write once, read many의 성격을가짐.

-Write-intensive 한형태의 data는특정 workload type (logging, transactional DB)으로구분할수있음.


G-Cube OpenStack Device Features

• 기본적인요구사항-초기단계에서는구체적으로저장장치및노드의정보를공유.

• Online parameter extraction

-기본적으로운용중인저장장치에대해서성능을 online으로알아내는것은힘듬 (위험성및내구성의문제유발).

-Offline parameter extraction approach: storage device의 modeling parameters를 offline으로추출하고 model name에따른추출값을저장. Vendor별 storage device model이많지않으므로가능한접근방법임.

• Storage device features

-Disk model name

-Type (SSD, Enterprise HDD, )

-Interfaces & protocol (SATA, SAS, PCI-E NVME)

-Performance factors

Sequential/Random Read/Write, Mixed (70:30).

Latency/Throughput

-Reliability factors

N-device fault tolerant. abstraction of redundancy level.

SMART features.

-Capability


G-Cube OpenStack Functionality

• Data Functionality (우선순위별정렬은아님)

-Replication.

-High availability.

-Cache & tiering.

-Compression.

-Security.

-…

• Data functionality는 plug-in으로구성하여 data 요구사항에맞게적용가능한형태로개발.

-e.g., Data set A 또는 volume 구성후, 해당 set이나 volume에 compression/replication

기능을제공하도록 구성.


G-Cube OpenStack 확장성

• Online Migration.

-장비의추가/장애, 노드의추가/장애등을고려한설계및개발

-Scale-up/scale-out 고려.

• Scale-out

-Network bandwidth을고려하였을때, OpenStack solutions의 scale-out을위한가장큰특징은 no central metadata node client level에서 key로부터 determinstic하게addressing (hashing)이가능.

-Multi-dimensional feature set을고려했을때, metadata node 없이 scale-out 한storage 구성을위한 data mapping algorithms 설계및구현.

g cube openstack solution

Software

storage data mapping

data dds

storage flat

storage featuresdata

gcube openstack solution

data io

multiaspect storage

sds decribes storage