GitHub

https://github.com/call518/OpenStack-on-Kubernetes


Greetings

Hi! all, Welcome to my project. I hope this will be useful thing. :)

p.s. And I hope that some guy help me. If you are interested in this, please contact me. thank you.

Intro

  • OaaS is "OpenStack as a Service".

  • MAINTAINER: Jung-In.Jung (call518@gmail.com)

  • 2018-06-20 ~ Now

Goals

  • Auto-Provisioning OpenStack, Based on Kubernetes(k8s).
  • Scalaing for LB/HA.
  • Supoort Provisioning Almost OpenStack Releases. (Newton/Ocata/Pike/Queens/...)
  • Simple and Dynamic Configuration.
  • Auto Failover/Failback.

Components Diagram

Diagram

Networking Diagram

OaaS Netowkring

Progress

  • Ocata
    • memcached (Completed)
    • rabbitmq (Completed)
    • mongodb (Completed)
    • etcd (Completed)
    • galera (Completed)
    • haproxy (Completed)
    • keystone (Completed)
    • glance (Completed)
    • nova (Completed)
    • neutron (Completed)
    • cinder (Completed)
    • heat (Completed)
    • ceilometer-central (Completed)
    • aodh (Completed)
    • horizon (Completed)
  • Integration of OpenStack Releases.
    • (TODO: Planning...)

Tutorial

System Env. & Arch.

Requirements.

  • General Kubernetes Cluster.
  • All k8s Worker nodes have to sync Time (e.g. chrony, ntp)
  • k8s worker nodes for neutron-server/nova-compute need to load openvswitch/ebtables/ip_vs kernel module.
    • Run contents of host_kernel_modules_for_oaas.sh on compute/network role(label) woker nodes.
  • Quorum PODs (Replica is have to 2n+1)
    • galera-etcd
    • galera
    • rabbitmq

Env.

(Note) We have tested this tutorial with 6 VMs on VirtualBox Env. If u want, any env is possible. (eg. physical machines)

(Note) We use NFS for cinder backend storage for simple tutorial, but soon we will change to ceph back-end storage.

Spec. of Physical Host

  • Processor: Intel Core i5-6500 (3.2GHz)
  • Memory: 32GB
  • Storage: SSD (2TB)
  • NIC: Intel(R) Ethernet Connection (5) I219-LM

Spec. of each VM

(Note) Maybe, you need big RAM. if not, reduce number of replicas.

  • CentOS-7 x86_64
  • 2 EA vCPUs
  • vRAM: 2GB ~ 6GB
  • 100 GB vDisk
  • 1 EA NIC

Spec. of k8s

This is versions of packages that i have tested.

  • docker-ce-18.06.0.ce-3.el7.x86_64
  • kubernetes-cni-0.6.0-0.x86_64
  • kubectl-1.11.1-0.x86_64
  • kubelet-1.11.1-0.x86_64
  • kubeadm-1.11.1-0.x86_64

VM OS Env.

/etc/hosts
# cat /etc/hosts

192.168.0.150 k8s-master
192.168.0.151 k8s-node01
192.168.0.152 k8s-node02
192.168.0.153 k8s-node03
192.168.0.154 k8s-node04
192.168.0.155 k8s-node05

Deploy Tutorial

Node Labels (Role)

(!) Network(neutron-sever) worker nodes must be separated/dedicated. (network=true)

[k8s-master]# kubectl get node --show-labels

NAME         STATUS    ROLES     AGE       VERSION   LABELS
k8s-master   Ready     master    8d        v1.11.1   node-role.kubernetes.io/master=
k8s-node01   Ready     <none>    8d        v1.11.1   controller=true,compute=true,nfs-server=true
k8s-node02   Ready     <none>    8d        v1.11.1   controller=true,compute=true
k8s-node03   Ready     <none>    8d        v1.11.1   controller=true,compute=true
k8s-node04   Ready     <none>    8d        v1.11.1   network=true
k8s-node05   Ready     <none>    8d        v1.11.1   network=true

default configs (eg. password)

check main env file, src-ocata/configMap-env-common.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: env-common
data:
  K8S_OPENSTACK_RELEASE: "ocata"
  MYSQL_ROOT_PASSWORD: "passw0rd"
  DISCOVERY_SERVICE: "etcd-client:2379"
  XTRABACKUP_PASSWORD: "passw0rd"
  CLUSTER_NAME: "mariadb_galera_ss"
  #MYSQL_DATABASE: "mydatabase"
  #MYSQL_USER: "myuser"
  MYSQL_PASSWORD: "passw0rd"
  K8S_MONGO_USER: "admin"
  K8S_MONGO_PASS: "passw0rd"
  K8S_KEYSTONE_DB_PASS: "passw0rd"
  K8S_GLANCE_DB_PASS: "passw0rd"
  K8S_CINDER_DB_PASS: "passw0rd"
  K8S_NEUTRON_DB_PASS: "passw0rd"
  K8S_NOVA_DB_PASS: "passw0rd"
  K8S_GNOCCHI_DB_PASS: "passw0rd"
  K8S_AODH_DB_PASS: "passw0rd"
  K8S_HEAT_DB_PASS: "passw0rd"
  K8S_KEYSTONE_USER_ADMIN_PASS: "passw0rd"
  K8S_KEYSTONE_USER_DEMO_PASS: "demo"
  K8S_KEYSTONE_USER_GLANCE_PASS: "passw0rd"
  K8S_KEYSTONE_USER_CINDER_PASS: "passw0rd"
  K8S_KEYSTONE_USER_NEUTRON_PASS: "passw0rd"
  K8S_KEYSTONE_USER_NOVA_PASS: "passw0rd"
  K8S_KEYSTONE_USER_PLACEMENT_PASS: "passw0rd"
  K8S_KEYSTONE_USER_GNOCCHI_PASS: "passw0rd"
  K8S_KEYSTONE_USER_CEILOMETER_PASS: "passw0rd"
  K8S_KEYSTONE_USER_AODH_PASS: "passw0rd"
  K8S_KEYSTONE_USER_HEAT_PASS: "passw0rd"
  K8S_HAPROXY_STATS_USERNAME: "admin"
  K8S_HAPROXY_STATS_PASSWORD: "passw0rd"
  K8S_RABBITMQ_ADMIN_USER: "admin"
  K8S_RABBITMQ_ADMIN_PASS: "passw0rd"
  K8S_RABBITMQ_OPENSTACK_USER: "openstack"
  K8S_RABBITMQ_OPENSTACK_PASS: "passw0rd"
  K8S_METADATA_PROXY_SHARED_SECRET: "QU6muuXhU4oAeLzDas6obGsDtoFNZTHq"
  K8S_NFS_SERVER_IP_ETC_KEY: "k8s-oaas-nfs-server-ip-address"
  K8S_EXT_SUBNET_CIDR: "192.168.100.0/24"
  K8S_EXT_SUBNET_POOL_START: "192.168.100.101"
  K8S_EXT_SUBNET_POOL_END: "192.168.100.200"
  K8S_EXT_SUBNET_GW: "192.168.100.1"
  K8S_DEMO_SUBNET_CIDR: "172.16.0.0/24"
  K8S_DEMO_SUBNET_GW: "172.16.0.1"
  K8S_DEMO_SUBNET_DNS: "8.8.8.8"

Required Docker Images.

  • call518/oaas-init-container
  • call518/oaas-nfs-server
  • call518/oaas-etcd
  • call518/oaas-galera
  • call518/oaas-memcached
  • call518/oaas-rabbitmq
  • call518/oaas-mongodb
  • call518/oaas-haproxy
  • call518/oaas-zookeeper
  • call518/oaas-ocata

Initiate Deploying OpenStack

[k8s-master]# git clone [here]

[k8s-master]# cd OpenStack-on-Kubernetes/src-ocata

[k8s-master]# ./start-oaas.sh

Result Deploying

[k8s-master]# kubectl get all -o wide

NAME                           READY     STATUS    RESTARTS   AGE       IP             NODE
pod/cinder-0                   1/1       Running   0          38m       10.244.3.130   k8s-node03
pod/cinder-1                   1/1       Running   0          6m        10.244.1.143   k8s-node01
pod/etcd0                      1/1       Running   0          38m       10.244.2.112   k8s-node02
pod/etcd1                      1/1       Running   0          38m       10.244.3.127   k8s-node03
pod/etcd2                      1/1       Running   0          38m       10.244.1.137   k8s-node01
pod/galera-0                   1/1       Running   1          38m       10.244.2.117   k8s-node02
pod/galera-1                   1/1       Running   0          17m       10.244.3.133   k8s-node03
pod/galera-2                   1/1       Running   1          33m       10.244.1.142   k8s-node01
pod/glance-0                   1/1       Running   0          38m       10.244.1.140   k8s-node01
pod/glance-1                   1/1       Running   0          10m       10.244.3.135   k8s-node03
pod/haproxy-7b567f67d8-mxm7v   1/1       Running   3          38m       10.244.3.128   k8s-node03
pod/horizon-6965547f56-kgc44   1/1       Running   0          38m       10.244.2.116   k8s-node02
pod/keystone-0                 1/1       Running   0          38m       10.244.2.114   k8s-node02
pod/keystone-1                 1/1       Running   0          13m       10.244.3.134   k8s-node03
pod/memcached-0                1/1       Running   0          38m       10.244.2.113   k8s-node02
pod/memcached-1                1/1       Running   0          38m       10.244.3.129   k8s-node03
pod/memcached-2                1/1       Running   0          38m       10.244.1.138   k8s-node01
pod/neutron-server-0           1/1       Running   0          38m       10.244.1.139   k8s-node01
pod/neutron-server-1           1/1       Running   0          5m        10.244.3.136   k8s-node03
pod/nfs-server                 1/1       Running   0          38m       10.244.1.136   k8s-node01
pod/nova-compute-0             1/1       Running   0          38m       10.244.4.24    k8s-node04
pod/nova-compute-1             1/1       Running   0          38m       10.244.5.24    k8s-node05
pod/nova-server-0              1/1       Running   0          38m       10.244.2.115   k8s-node02
pod/nova-server-1              1/1       Running   0          4m        10.244.1.144   k8s-node01
pod/rabbitmq-0                 1/1       Running   0          38m       10.244.3.131   k8s-node03
pod/rabbitmq-1                 1/1       Running   0          35m       10.244.1.141   k8s-node01
pod/rabbitmq-2                 1/1       Running   0          35m       10.244.2.118   k8s-node02

NAME                          TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)                                                       AGE       SELECTOR
service/cinder                ClusterIP   None             <none>        8776/TCP                                                      38m       app=cinder
service/etcd-client           ClusterIP   10.109.90.101    <none>        2379/TCP                                                      38m       app=etcd
service/etcd0                 ClusterIP   10.110.11.231    <none>        2379/TCP,2380/TCP                                             38m       etcd_node=etcd0
service/etcd1                 ClusterIP   10.98.35.253     <none>        2379/TCP,2380/TCP                                             38m       etcd_node=etcd1
service/etcd2                 ClusterIP   10.110.157.230   <none>        2379/TCP,2380/TCP                                             38m       etcd_node=etcd2
service/galera                ClusterIP   None             <none>        3306/TCP                                                      38m       app=galera
service/glance                ClusterIP   None             <none>        9292/TCP,9191/TCP                                             38m       app=glance
service/haproxy-galera        ClusterIP   None             <none>        3306/TCP                                                      38m       app=haproxy
service/haproxy-stats         NodePort    10.103.245.255   <none>        9000:30090/TCP                                                38m       app=haproxy
service/horizon               NodePort    10.103.67.208    <none>        80:30080/TCP                                                  38m       app=horizon
service/keystone              ClusterIP   None             <none>        5000/TCP,35357/TCP                                            38m       app=keystone
service/kubernetes            ClusterIP   10.96.0.1        <none>        443/TCP                                                       2d        <none>
service/memcached             ClusterIP   None             <none>        11211/TCP                                                     38m       app=memcached
service/neutron-server        ClusterIP   None             <none>        9696/TCP                                                      38m       app=neutron-server
service/nova-compute          ClusterIP   None             <none>        8774/TCP,8775/TCP,6080/TCP                                    38m       app=nova-compute
service/nova-server           NodePort    10.111.84.90     <none>        8774:30177/TCP,8778:30246/TCP,8775:31964/TCP,6080:30068/TCP   38m       app=nova-server
service/rabbitmq              ClusterIP   None             <none>        5672/TCP,4369/TCP,25672/TCP                                   38m       app=rabbitmq
service/rabbitmq-management   ClusterIP   None             <none>        15672/TCP                                                     38m       app=rabbitmq

NAME                      DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE       CONTAINERS   IMAGES                 SELECTOR
deployment.apps/haproxy   1         1         1            1           38m       haproxy      call518/oaas-haproxy   app=haproxy
deployment.apps/horizon   1         1         1            1           38m       horizon      call518/oaas-ocata     app=horizon

NAME                                 DESIRED   CURRENT   READY     AGE       CONTAINERS   IMAGES                 SELECTOR
replicaset.apps/haproxy-7b567f67d8   1         1         1         38m       haproxy      call518/oaas-haproxy   app=haproxy,pod-template-hash=3612392384
replicaset.apps/horizon-6965547f56   1         1         1         38m       horizon      call518/oaas-ocata     app=horizon,pod-template-hash=2521103912

NAME                              DESIRED   CURRENT   AGE       CONTAINERS       IMAGES
statefulset.apps/cinder           2         2         38m       cinder           call518/oaas-ocata
statefulset.apps/galera           3         3         38m       galera           call518/oaas-galera
statefulset.apps/glance           2         2         38m       glance           call518/oaas-ocata
statefulset.apps/keystone         2         2         38m       keystone         call518/oaas-ocata
statefulset.apps/memcached        3         3         38m       memcached        call518/oaas-memcached
statefulset.apps/neutron-server   2         2         38m       neutron-server   call518/oaas-ocata
statefulset.apps/nova-compute     2         2         38m       nova-compute     call518/oaas-ocata
statefulset.apps/nova-server      2         2         38m       nova-server      call518/oaas-ocata
statefulset.apps/rabbitmq         3         3         38m       rabbitmq         call518/oaas-rabbitmq

Open Horizon Dashboard

In browser, http://[One_of_worker_nodes]:30080

Scaling

(Note) Maybe, needed more worker nodes...

<Examples>

[k8s-master]# kubectl scale --replicas=4 statefulset.apps/cinder
[k8s-master]# kubectl scale --replicas=5 statefulset.apps/galera (must 2n+1)

ScreenShots

Login

Horizon Login

Overview

Horizon Overview

Instances

Horizon Instances

Network Topology

Horizon Network Topology

Instance Web Console

Horizon VM Console

TODO

  • Re-Configuration Flat-IP Ranbe for EXT-NET.
  • (Done) Simplify initContainer Check-Processing.
  • Integration of All of Provision Source. /w Template and ETc...

Appendix

Repositories

Active Repository (GitHub)

https://github.com/call518/OpenStack-on-Kubernetes

Mirrored Repository (GitLab)

https://gitlab.com/call518/OpenStack-on-Kubernetes

References


'Cloud' 카테고리의 다른 글

Concept of IaaS, PaaS, SaaS  (0) 2017.09.20
Orchestration Docker on Mesos/Marathon  (0) 2015.03.14
SDN Test Suite /w Vagrant  (0) 2014.12.23
OpenStack - How To Install DevStack with Vagrant/VirtualBox  (0) 2014.03.12
[Open] EYWA - Detailed Information  (0) 2014.03.03
Posted by 사랑줍는거지
,

'Cloud' 카테고리의 다른 글

OpenStack on Kubernetes (GitHub)  (0) 2018.08.16
Concept of IaaS, PaaS, SaaS  (0) 2017.09.20
SDN Test Suite /w Vagrant  (0) 2014.12.23
OpenStack - How To Install DevStack with Vagrant/VirtualBox  (0) 2014.03.12
[Open] EYWA - Detailed Information  (0) 2014.03.03
Posted by 사랑줍는거지
,
Posted by 사랑줍는거지
,

OpsWorks는 기존의 AWS Cloud Formation의 대안격으로 보인다. 현재는 Beta서비스 중이지만, 개념이 Cloud Formation보다 훨씬 직관적인 것 같다. 물론 Chef에 대해 어느정도 배경지식이 있어야 하겠다.

(이런게 진짜, "as-a-Service" 아니겠나~ "I"냐 "P"냐 "S"냐는 경계가 모호해진지 오래라 의미 없고..)


이번 스레드에서는 OpsWorks상에서 Custom Cookbook(getting-started)를 적용하는 흐름을 간단히 정리해 두는 것이 목적이다.


먼저 OpsWorks 특징에 대해 파악된 부분만 우선 정리 하자면,


  • 단일 인스턴스가 최종 Goal이 아닌, 하나의 Stack(다 계층 구조의 시스템 전체)를 쉽게 배포/설정을 지원.
  • 하나의 Stack은 다수의 Layer로, 또 각 Layer는 다수의 Instance로, 또 각 Instance는 다수의 App으로 구성 된다.
  • 주요 도구는 이름에서도 드러나듯이, OpsCode사의 Chef가 주요 역할을 담당한다.
  • 일반적으로 통용되는 Stack구조(MySQL, PHP, node.js, 등)는 별도의 Cookbook이 필요 없이 기본 제공이 된다. 
  • Cookbook 적용시, 사용자 입력값이나, 개개의 Private한 값은 Data Bag이 아니라 JSON 형식으로 전달한다.
  • 사용자 정의 값을 기술한 JSON 내용은, Static하게 또는, 매번 실행시마다 1회성(Dynamic)으로 전달 할 수도 있다. 단, Static과 Dynamic에 동일 값이 있으면, Dynamic값이 Static값에 Override되어 우선순위가 높은 것으로 판단된다. (확인 필요)
  • (기타 특징들은 파악 되는대로 계속 업데이트 예정...)

[본론] OpsWorks에서 Chef의 기본 에제인 "getting-started" cookbook을 적용하는 예제 실습

가정
  • Stack이나 Layer에 대한 실습이 아니므로, 단일 레이어에 PHP템플릿 인스턴스 하나에 getting-started적용 진행.
  • "getting-started" 소스는 SSH Key기반의 GitHub에 등록되어 있다.
  • GitHub에 준비해둔 "getting-started"에 수정한 내역은 아래와 같다.
    (cookbooks/getting-started/templates/default/chef-getting-started.txt.erb)
    (붉은 색 부분을 추가 하였으며, 해당 값은 JSON으로 전달 한다.)
  • Welcome to Chef!


    This is Chef version <%= node[:chef_packages][:chef][:version] %>.

    Running on <%= node[:platform] %>.

    Version <%= node[:platform_version] %>.

    Custom <%= node['deploy']['test_string'] %>

  • Stack, Layer, Instance 등을 생성하는 방법은 아래 문서를 참조한다. 너무 쉽기도 하고 설명도 잘되어 있다.
    http://awsdocs.s3.amazonaws.com/opsworks/latest/opsworks-ug.pdf

실습 내용 요약
  • "getting-started" Cookbook을 PHP가 설치될 Instance에 추가로 적용시키고, "getting-started" 내용 일부를 수정/추가 하여, JSON으로 전달된 값들이 정상적으로 반영되는지까지 확인한다.

[실습 과정]
  1. "test"라는 이름으로 Stack 생성
    (최초 Stack을 생성하면 녹색 원에 숫자가 "0"일 것이다. 이 캡쳐는 테스트 후에 작성한 것이라, "1"로 표시된 것일 뿐..)

  2. Layer 생성 (Custom Cookbook 적용이 목적이므로, 어느 것이든 관계 없다. 본 실습에서는 App Server에서 PHP로 하였다.

  3. "getting-started" Cookbook을 실제로 적용시킬 Instance 하나를 생성.

  4. 과정(2)에서 생성한 Layer의 편집 모드로 진입하여, "getting-started" Cookbook의 위치, SSH-Key 정보, 사용자 정의 Value를 포함하는 JSON 정보등을 설정.

  5. 설정을 마쳤으니, 실제로 "getting-started" Cookbook을 대상 Instance에 적용해 본다.

    (Custom Chef JSON에서 Override로 값을 재정의 할 수 있다.)


  6. 수행 Log 학인

    (/tmp/ 디렉토리에 "getting-started"의 default 레시피대로 파일이 에러 없이 작성되었다.)


  7. 생성 파일 내용 확인
    (과정상 "Custom call518"로 표시되어야 하나, 캡쳐 그림은 여러가지로 테스트 한 결과임)
[END]
아주 기초적인 흐름만 테스트 해보았다. 서두에 링크해둔 PDF(User Guide)를 참고해서, 사용자 Cookbook이 수행되는 타이밍(전체 Stack을 구성하다 보면 Cookbook간의 순서가 중요하다.)도 조절해 보고, Stack, Layer, Instance에서 App목록까지 Custom Cookbook으로 전달해야 할 일이 많을 텐데, 그러한 부분까지 테스트 해볼 예정이다. 그러기 위해서 가장 기초적인 내용을 정리 해둔 것.... 


Posted by 사랑줍는거지
,

VM Template 이미지를 어떻게 만들고 운영해야 유리할까~???


최근, Chef로 서비스 구성(Configuration) 자동화 파트를 다시 하게 되었다. 여기저기 타 부처 수행 인력과 협업도 해야 하는 상황이라, 가상화 인프라부터 논의를 통해 결정을 지어야 할 일이 많다... 서비스 구성에는 Hadoop Cluster, MySQL & Replication, Cassandra, MongoDB, HAProxy LB, Apache/Tomcat, 등등 여러가지 서비스들이 버튼 한번의 클릭으로, 동적 구성 및 동작이 되어야 한단다. (쉽게 이야기들 한다...쿨럭...) 이러한 일련의 자동화 구성/배포 전략 수립단계에서 여러사람들끼리 혼선도 있고, 의견 충돌이 있는 것은 당연하다. 왜? 정답이 없는 거니까~ ㅡ.ㅡㅋ 사실 이 섹션의 고민은 Cloud라는 단어가 국내에서 화자 되기전, RIS라는 OS 원격 설치 서비스를 구축 할 때에도 심각하게 고민됐었다... "과연 어느 선까지 사전에 설치 해두는 것이, 유연성과 편의성 두마리 토끼를 다 잡을 수 있을까?"...라는.... 결국 그 당시에는 지금의 Chef나 Puppet만큼 완성도 있는 도구가 없다는 핑계를 대며 일정에 쫓겨 최대한 밀어넣기(?)로 쫑친 기억이....


아무튼 그 중, 가장 어정쩡하게 결론이 난 것이 어떤 방식의 Template를 사용하냐~였다. 이참에 그 사항에 대해 정리를 나름대로 해두고 싶어 일단 펜을...아니 키보드를 두드려 둔다. 물론 서두는 없다. 생각 나는대로.. 우선...


PaaS, SaaS... 당연히 밑바탕이 IaaS라 불리는 가상화 서버스가 "반드시" 필요 한 것은 아니다. 그러나 즉시성, 그리고, 자원의 효율적 활용(이 부분도 아직 갈길이 멀기만 하지만...), 유연한 인프라 관리 체계(이 말도 참 귀에 걸면 귀걸이인 마케팅용...)라는 진부한 이야기들 외에 본 글에서는 오로지 Physical 인프라와 비교해 상대적으로 설치/구축이 쉬운 점을 감안하여 "필수적"이라는 가정하에 이야기를 풀어 볼 생각이다... (물론 이 말에는, 가상화를 위한 Physical 인프라는 이미, 그리고 부족함 없이 구축되어 있다는 대전제가 깔려 있어야....쿨럭..ㅡ.ㅡ;;)


여기서 논점의 주제는 뭐냐.....


1) Pre-Installed Template 방식

; 가상머신 이미지(VDI :: Virtual-Machine Disk Image)에 원하는 서비스와 설정들을 사전에 설치 해두는 것이 유리하냐?


아니면,


2) OS-Only Template 방식

; 가상머신 이미지는 순수 OS만 설치된 이미지를 그대로 사용하고 나머지는 그때 그때, 필요한 서비스들을 동적으로 배포/설치/설정 해주는 것이 유리하냐?


뭐가 좀 더 좋은 선택이냐~ 하는 것....


음.. 경험상 개인마다, 또 환경마다 호불호가 갈렸던 것 같다. 

이후 말하고자 하는 것은... 일반적 또는 보편적으로 봤을때에는 "2) OS-Only Image" 방식을 사용하는 것이 유리하다...라는 것에 대해 이유를 정리 해볼려고 한다... 물론 전혀 현실성 없는 이야기로 보일 수도, 틀린 이야기일 수 도 있는 사견일뿐....



참 Template에 대한 용어 정리 부터 하자...


* 본 글에서 언급되는 "Template"이라 함은, Virtual Machine 생성에 공통적으로 복제/사용되는 Disk 이미지를 말한다. 통상적으로, RedHat/Ubuntu/CentOS/Windows 등과 같은 범용적으로 사용되는 OS레벨까지만 설치되어 있는 Disk Image 파일을 말한다. 


자 그럼, 1)번의 경우, Hadoop이든, Cassandra든 뭐가 됐던, 모든 S/W, 관련 패키지, 라이브러리, 데이타 모두 사전에 각각에 대해 Template이미지를 미리 만들어 두어야 한다. 잘 이해가 안된다고? 아래 [그림1]을 보라.



[그림1]


(그림 설명)

- 가운데 점선은 Template으로부터 사용자에게 배포되는 경계를 나타냄. 일반적으로 Chef/Puppet가 담당.


지원하는 OS는 3종류로 가정한다. SuSe/RedHat/Ubuntu...

그리고, 지원하는 서비스로는 Hadoop/MySQL/Cassandra/Tomcat/HAProxy/Apache/GlusterFS 이정도로 7가지가 서비스할 계획이라고 치자...

 

  • OS플랫폼 : 3가지
  • 서비스 종류: 7가지


따라서, 3*7=21 가지로서, 21개의 Template이미지를 사전에 확보/관리 되고 있어야 한다.

물론 생성 이후에 적용된 고유정보나, 설정은 Chef나 Puppet와 같은 Auto-Configuration 툴을 사용한다는 것을 전제로 한다.


Pre-Installed Template 방식의 장점은 아래와 같다.

(본 글과 연관이 있는 항목 위주)

  • 설치/설정 작업에 필요한 소요시간 제거/단축.
  • 요소 패키지의 버전 Upgrade등으로 인한 설치/설정 중 발생 가능한 오류 제거.
  • 설치/설정 과정을 거친, 즉 작동이 검증된 이미지임을 보장.

위와 같은 이점을 누릴 수 있다. 이중에서도 1)번 방식을 주장하는 사람들이 가장 강하게 내세우는 점은 첫 번째 서비스 배포에 소모되는 "시간단축"이었다.


자, Pre-Installed Template이미지가 가지는 단점이 있겠으나, 아래 내용은 2)번 방식인 "OS-Only Template"방식을 살펴보고 비교해보는 것으로 충분할 것이다.


2번) 방식을 도식화한 [그림2]을 보자.


[그림2]

그림 2는?

Virtual VMs 영역은 "Pre-Installed Template"방식과 다를게 없다. 그러나, 아래 쪽 Template영역은 아주 딸랑 3개로 심플하다.


OS-Only Template 방식의 장점을 정리하면,

  • 확보/관리 되어야할 Template이미지 대상 수가 현저히 적다.
  • Template 이미지에 대한 Version Upgreae, Patch 이슈가 현저히 적다.


오직, 3개만, 그것도 순수 OS레벨까지만 구축되어 있는 Template를 확보하면 된다. 그럼 각각의 서비스들에 대한 설치/설정과 관련된 일들은 어디로 가버린거냐? 당연히 파란점선 부분에 존재하는 Chef/Puppet가 담당하게 된다.


그럼, 단점은?
  • 모든 서비스가 VM생성 요청마다, 설치/설정 작업이 수반되어야 한다.
  • Chef/Puppet의 역할이 매우 중요해진다.
  • 설치/설정이 생성 요청때마다 발생하므로, 당연히 배포완료까지 소요되는 시간이 증가한다.

자, Pre-Installed Template 방식과, OS-Only Template방식을 간략히 살펴 보면 이와 같이 "일장일단"이 있다.


나름 가상화라는 파트를 접하면서 겪어오고 싸우기도 한 이 문제...

결국 논쟁의 핵심은(단, 국내 가상화 일선 현장에서이다.) 아래의 것들 이었다.

  • 배포 소요 시간
  • 관리의 복잡성
  • 배포 실패 가능성


이러한 이유로 인해, 99%는 1)번 Pre-Installed Template 방식을 도입/적용 하는 것으로 가닥이 잡힌다. 설령 그것의 단점을 인지하고 있더라도...(최근에야 Chef나 Puppet의 비중을 높이려는 시도가 많이 보이나 쉽지는 않은듯 하고...)


아무튼, 이것은 단기적으로 봤을때는 충분히 설득력이 있고, 또 실제로 효과도 만점이다.

서비스 로직과 Web-UI연동, 빌링, 요구사항에 부합하는 서비스가 정상적으로 사용가능한지가 단기적인 프로젝트상 Output으로서 중요하지, Provisioning과정에서 생기는 시행착오나, 오류로 시간을 허비할 수는 없는 환경도 한 몫을 하고 있는 것 같다.


그러나 장기적으로 봤을 때, 덮어 두었던 문제들이 일순간 터져버리는 지뢰밭을 키우는 꼴이 될 확률이 대단이 높다.


왜?~~


1) 배포 소요 시간. 이것 부터 살펴 보자...

실제로 Hadoop, Apache, Cassandra 등등이 미리 설치 했을 때에 비해, 그때 그때 Instant하게 설치가 된다면 분명히 시간은 더 걸리겠으나, 과연 얼마나 더 소모될까? 10분? 아니면 1시간?.... 별의 별 S/W를 다 동적 Provisoning해봤지만, 어지간 해서는 3분을 넘기는 Provisioning을 필요로 하는 서비스는 굉장히 드물다....

(여담이지만, 이미지 복사하는데 훨씬 시간이 많이 걸린다... 왜? "Backing-File" 방식을 사용하지 않고, 10GB짜리를 그대로 10GB 통으로 복사를 하니..... 차라리 이런 시간을 줄이는게 훨씬 비용효율적일 것이다.) 


2) 버전 관리의 복잡성

음... 이 문제는 기술적 의견차가 큰것도 있지만, 커뮤니케이션 부족이 한 몫을 한 것 같다.

이 부분을 지적한 사람들이 주로 주장하는 내용이, "apt-get이나, yum등의 버전이 수시로 바뀌고, 관련 conf 패턴도 바뀌어 문제가 많이 발생하더라. 설치 과정도 어렵고 하니 한번만 고생해서 만들어 두면 편하지 않느냐..." 이었다. 음... 틀린 말은 아니다. 그러나 미안한 말이지만, 이 부분은 전적으로 "관리 능력"의 부재로 인한 핑계일 뿐이다.

이유는, 이 이슈를 Pre-Installed Template방식에서는 더 Critical하게 접하게 될 이슈이기 때문인다. 무슨 말인지 이해가 잘 안된다고? 어느 서비스도 마찬가지겠지만, Cloud라는 이름이 붙은 서비스에서 특정 Version으로 Static하게 패키징된 Template으로 1~2년 서비스를 할 수는 있다고 치자. 패치/업그레이드가 다반사로 일어나는 Cloud관련 솔루션들인데, 그렇게 버텼다고 치자. 훗날 업그레이드는 어떻게 수행할 것인가? 안할 것인가? 한다면, 전체 다 할 것인가? 아니면 기존 이미지 27개(앞선 예를 기준)템플릿은 별개로 운영하고, 신버전의 동일 서비스의 Template이미지들을 또 추가하여 54개의 Template으로 운영할 것인가? 그러면 언제부터 사용한 서비스냐에 따라 기술지원 방식이나 메뉴얼, 대응팀 운영을 개별적으로 가져갈 것인가? 문제는 시간이 가면 갈수록 걷잡을 수 없는 악순환에 빠지고 만다.

결국 핵심 이야기는 이것이다. "현재 작은 문제로 인해 발생한 상황을 해결 하지 못하는데, 그 문제들이 누적되고 쌓인 미래의 상황은 해결이 가능할 것인가?" 하는 것이다.


아래 [그림3]을 보면서 이 항목에 대해서는 마무리 하자.

개발에서도 통용되는 오래된 그림이고 이야기이다. 버그나, 이슈에 대한 패치의 양과 주기에 대한 비교 그림이다.

왼쪽그림은 패치 주기가 길고, 한번에 패치하는 버그/이슈의 양이 많다.

반면에, 오른쪽은 패치 주기가 짧고, 버그/이슈의 양도 적다. 그만큼 한번의 패치 작업 때 변경되는 코드 양이 작고, 만에 하나 발생할 잠재위험(Risk)도 작다.

어느 것이 유리한가? 답은 굳이 말하지 않아도 자명할 것이다.


      

[그림3]


3) 배포 실패 가능성.

음.. 이부분은 2)번 "관리의 복잡성"의 내용과 중복되는 부분이 많다.

실제 Pre-Installed Template방식에 비해, OS-Only Template 방식이 가지는 핸디캡이기도 하다. 다시말해 Chef나 Puppet와 같은 Auto-Configuration 툴의 역할과 비중이 증대되어 미션크리티컬한 시스템 수준으로 올라가게 된다. 모든 것을 배포하고, 설정하고, 조율하고, 심지어 모니터링/관제 까지.. 그만큼 Auto-Configuration 시스템의 운영/관리가 철저히 되어야 하고, 만에 하나 장애나 오동작시, 전체 시스템에 어떠한 피해가 올지 모를 양날의 검과 같은 존재다. "잘 쓰면 이롭지만, 잘 못 쓰면 해가 되는..."

이러한 툴들이 수행되는 과정에서 발생 가능한 오류는 S/W버전의 상이함, 배포 로직상의 오류, 툴 자체적인 SPOF구조, 등이 대다수다. 심지어 일부 Network구간 단절로 Configuration 시스템은 멀쩡함에도 배포 실패가 발생할 수 있다. 그러나 이러한 Risk는 Pre-Installed Template방식도 동일하게 내포하고 있는 문제이다. 단지, OS-Only Template방식에 비해, 수행 과정이 적다 보니, 발생 가능성이 상대적으로 낮을 뿐이지... 따라서 이 이슈는 어떤 방식이든 "관리/운영 능력의 문제"일 뿐이다. 고민은 하되 호불호를 따질 필요는 없을 것이다.



정리~


좀더 적합한 것은 존재 하난 정답은 아직인 것 같다. 적어도 국내 일선 현장에서는...

다만, 지극히 개인적으로~ "OS-Only Template"이 보편적인 방식으로 자리 잡기를 희망할 뿐...


장기 이식 의학 분야로 이야기를 빗대어 보자면,


Pre-Installed Template 방식은 간이식, 콩팥이식, 심장이식, 안구이식 등과 같이 특정 장기(Pre-Installed)를 확보하여 이식(배포)하는 방법이라면,


OS-Only Template 방식은, 줄기세포(단순 OS플랫폼)만 있으면, 어떠한 장기나 신체부위도 재생해낼 수 있는 방식이라고 생각하면 쉬울 것 같다. 단, 중간에서 재생(배포)에 필요한 미세하고 정교한 작업을 수행하는 의사(Chef/Puppet류의 툴들)의 뛰어난 역량이 수반되어야 할 것 같다.


"선택은 자유다............."


(여담) 그런데 이이야기를 깡그리 무너뜨릴 수 있는 것은, "왜? 여러 OS플랫폼에 똑같은 서비스를 사용해요? 하나만 정해서 서비스 해요~!!" 라고 하면....ㅡ.ㅡ;;


이상,,, 할 일 없는 일요일 저녁... 머리속에서만 맴돌고 정리가 안되던, 그래서 더욱 주관적인 이야기.... 글로 끄적여도 여전히 만족할만큼 정리는 되지 않았으나, 대충 어렴풋했던 그림도 서너장 나왔고, 앞으로 계속 다음어 나가야 할 글임을 다시금 되뇌이며 오늘은 이만....




(별첨) Chef/Puppet ?????


이러한 Auto-Configuratio툴의... (철학까지는 아니라도) 컨셉에 대해 내 의견과 다른(누가 맞는 건지는 아직 모르니...) 이들이 많아 내 생각도 이참에 간략히 메모해 두고, 경험이 쌓이고 생각이 조금씩 늘어나면 이 것도 수정 보완 해야 할 것 같다.


Chef/Puppet류의 툴들이 말하는 Configuration.......

과거,, 또는 최근 얼마전까지의 Configuration은 아닐 것이다. 다시 말해, "설정"이라는 좁은 의미로 사용된 것이 아닌, "구성"이라는 넓은 의미로 봐야 하는 것이 적절 할 것이다.

"구성"... 특정 머신이나 특정 S/W를 구성하는 것만이 아닌, "Service"에 대한 모든 제반 사항을 "구성"한다고 봐야 한다. 그 목표하는 시스템이 비록 1대일지라도, 혹은 수천대 일지라도.. 둘다 동등한 "구성"이다.. 적어도 Cloud라는 아직까지는 실체가 무엇인지도 명확치 않는 트렌트하에서 Chef/Puppet에서는.... 


Posted by 사랑줍는거지
,

CloudStack + SDN

Cloud 2012. 5. 1. 16:43


  • 특징
    • VLAN의 제한을 벗어남 (예: VLAN 개수가 4k 이상 운영 불가 등등)
    • GRE 터널링을 활용해서, L3위에서 L2에 대한 Overlay 네트워크 실현 (IDC간에서도 Network 통합)
      • 기존의 임기응변 격이었던 VPN을 통한 L2 Overlay 네트워크 흉내내던 것에 대한 대안...
    • VLAN개수 제한 대신 테넌트키(Tanant-Key)라는 것을 통해 계정별 트래픽 격리
      • Tanant-Key가 기존의 VLAN에서 VLAN-Tag(ID) 속성에 매칭되는 듯...
  • 걱정거리...
    • GRE 터널링에서 Tanant-Key활용은 분명 기존의 VPN에 비해 복잡성을 많이 제거 했으나, 터널링이라는 것에 의한 속도 문제는....
    • SDN과는 별개의 이야기지만, RouteVM이라는 병목 구간에 대한 개선점은 잘 보이지 않음....


이상, 간략히 훌터본 바로는 이상과 같다... 자세한 것은 실제로 테스트 정도는 해봐야 윤곽이 나올듯...

Posted by 사랑줍는거지
,
1. 메모리에서(in-memory) 처리하기 어렵다.
2. 디스크가 매우 느리다.
3. 분산이 쉽지 않다. 
Posted by 사랑줍는거지
,
  우선 금번 포스팅은 지극히 개인적인 생각이다. 나만의 시각일 뿐임... 특히 MR같은 특수한 기능 측면 보다는 기존 RDB에 비춰 NoSQL의 일반적 특성이 뭘까 고민 해본 정도??

  작년엔 IaaS로 후끈~ 달아 오르더니 딱 1년 지나니... 조용.......... 뭔가 모든걸 해결해 줄듯~ 기세등등한 "Oral-Clouder"들의 천국(전부가 다 그렇단 이야긴 아니니 오해 없길...)이었던 것 같다... 한 1년 겪어보니 이게 장난이 아니구나~ 싶었던걸까...... 그러던 "IT깡국 대한민국"이... 올해는NoSQL, Big-Data로 난리도 아닐것 같다... 뭐가 됐든, 붐이 이는건 좋다... 다만, 걱정되는건 작년 IaaS 처럼... 반짝~ 하고 말게 되지나 않을까 하는거.....

  NoSQL의 개념이나, 등장 하게된 배경...등은 위키피디아를 참고 하시고... 여기서 하고 싶은 이야기는 그것의 본질적 목적이 무엇인가~에 대한 것이다...

 
  같은 값이면 다홍치마~ 라고 했던가? NoSQL이면서, RDB의 기능을 커버할 수 있다면 오죽 좋으련만... 세상에 겁나 싸면서, 기름 열라 작게 먹고, 그런데 승차감은 죽이는데, 속도는 마하급.. 그리고 실내는 버스만큼 넓은~ 그런차는... 몰라 훗날엔 존재할지도 모르겠지만, 당장은 절대로 없다... 무슨 말이냐... RDB의 특징을 유지하면서는, 대용량(기존의 전통적 시스템으로 커버 불가능한 용량) 서비스가 불가능 하기에, 일정 부분 불편함이나, 기능 포기를 감수하고서라도 그러한 대용량 서비스에 대해 탄력적으로 대응이 가능하고 원활한 서비스가 가능케 할 수 있는 방법이 뭘까~ 고민, 고민 하다 나온게(어쩌면 울며 겨자먹기식 차선책일지도 모른다) NoSQL 아닐까.. 싶다.

급조된(?) 아래 그림을 보자...


  가로축은 서비스 이용자 규모다.... 가운데 즈음의 회색 점선을 기준으로 과거 RDB가 커버 가능한 사용자 규모와, 불가능한 규모를 가정하여 잘라둔것...
  세로축은 성능이다... 단, 이 "성능"이라는 말에는 퍼포먼스 뿐만이 아니라, 기능, 그외 사용자가 느끼는 모든 것들을 포괄한 넓은 개념의 그 무엇이라고 보면된다... 그게 일관성이든, 트랜잭션이든, 응답성이든, 기능이든 뭐든...

   다음으로, 파란선은 기존의 RDB를 가정하여 그린 곡선이다. 과거의 전통적인 시스템에서는 하이엔드급 단일 시스템 또는 역할이 분리된 서버군으로 처리가 가능하였다.. 그러나 사용자수가 일정규모를 넘어서는 시점(요즘 말하는 대용량..)부터는 성능이 급감하게 된다... 소위 동적 수평 확장이 어려워 증가하는 사용자 규모에 대해 탄력적 대응이 어렵다..

  반면 빨간선 그래프는 요즘 뜨고 있는 NoSQL이라 생각하고 그려 본 것이다.. 딱 보면, 성능이 사용자 규모의 증가에 적절히 대처 하고 있을 것이라 예상되어 저렇게 그렸던 것이다... 왜? 동적 수평 확장이 가능하기에... 뭐 어디까지나 이론적이지만,,, 아쉽게도 수백대의 NoSQL로 그러한 규모의 사용자에 대한 서비스 처리를 직접 경험해본 적은 없다... 

  여기까진 개략적인 설명이고, 이 그림에서 주목할 부분은 왼쪽의 그래프 시작부분의 빨간선과 파란선의 초기 "성능"값이 다르다는 것이다. 즉, RDB가 NoSQL에 비해, 성능(사용자가 느끼는 모든 부분의...)에서는 월등하다.. 그게 편리함이건, 퍼포먼스건 뭐건... 이 부분에서 사람들이 착각하기 쉬운게 아닐까? 그런 손해를 감수 하고서라도, 그래프의 오른쪽의 대규모 사용자 영역에서 빛을 발하도록 고안된게 NoSQL일 것이다.

  그런 NoSQL을 왼쪽, 다시 말해 전통적인 규모에서 RDB의 기능들을 어설프게 따라 가려 하다가는, 진짜 자기 영역인 오른쪽 영역에서 RDB만도 못한 기대치를 보여줄 가능성이 매우 높을 것이라는 것이다...

  앞서도 언급했지만, "같은 값이면 다홍치마"면 얼마나 좋으려나~ 그러나 절대로 RDB와 NoSQL이 같은 "값"이 아니다.. 그 목적하는 바와 규모, 용도가 전혀 다르다...적어도 현재는... 수년이 지나면 RDB가 NoSQL의 장점을 일부 흡수하게되고(지금도 그런 움직임이 오라클이나, MySQL쪽에서 일고 있다..), NoSQL도 허용가능한 범위에서 RDB의 편리한 점은 흡수하려 할것이다.. 그러나 태생적으로 그 둘 모두의 장점을 결합한 그 무엇은 단기간 내에 보기는 힘들 것이다...

  저 그래프가 시간이 지났을 때를 예측한다면, RDB 입장에선 성능이 급감하는 시점(사용자 규모)을 더 오른쪽으로 최대한 옮길려고 할테고, 그에 대항해 NoSQL은 전체적인 성능을 올리는, 즉 그래프를 조금씩이라도 위쪽으로 옮기려 할 것이다... 뭐 NoSQL이나 Big-Data보다는 Virtualization에 훨씬 관심이 많지만, 이 분야도 앞으로 어떻게 전개될지 흥미는 있을것 같다...


Posted by 사랑줍는거지
,
정말 궁금하다... AWS가 클라우드의 표준일까?? SKT클라우드 기사 검색하면서 다시 느낀게... "S3 100%호환 스토리지~ 어쩌고~ 블라블라~~"..... AWS는 충분히 훌륭한 레퍼런스이고 독보적임은 분명하다. 그러나 호환은 옵셔널 한 것일뿐이다. 단지 그게 전부고 그기에 의존적이라는 건....... 최근의 DynamoDB의 출현만 봐도 그렇다. 결과론적이지만, SimpleDB는 DynamoDB의 전신? 테스트베드? 그정도가 된게 아닌가? 이런 상황에서의 오버헤드는 어떻게 할 것인지... 휘둘릴 수 밖에 없지 않나... 대한민국IT의 창의성이 부족한건 아닌거 같다...어떤 민족인데... 단지, 당장에 뭐라도 안하면 뒤쳐지는 것만 같아 조급해하고 있는 것 같다.... SKT클라우드 기사 내용도 참~... 지금으로선 딱히 내세울게 없었던지... 10g광케이블, 냉각시스템, 센터 평수, 전기요금.. 뭐 그런 식상한 내용들이 9할... 아무리 시작단계지만.. 중요한 먼가가 퍽~ 하고 빠져 있다는 느낌?? 뭐 마침 기사 검색하다 본내용이라 SKT가 언급했지만... 다른곳도 50보100보 같다... 비관은 아니다... 현재를 좀 냉정히 볼필요는 있을것 같다... 물론 틀린 판단일 수도 있다... 뭣도 모르는 놈이라~ 이런 저런 공상을 해보는 것일뿐...

SKT 기사 링크 : 
http://www.kbench.com/digital/?no=106196&sc=1 
[케이벤치-SK텔레콤, 국내 최고 수준 B2B 클라우드 서비스 개시] 
Posted by 사랑줍는거지
,
http://www.datanet.co.kr/news/articleView.html?idxno=58809
"웹하드·ASP 발달한 국내, 퍼블릭 클라우드 성공할까"

이 기사에 대한 개인적인 소감은... "역시,,, 그닥 희망적이진 않군~" 이다. 그래도 국내에서 가장 화끈하게(?) 추진한 KT도 요즘은 별 진전이 없는지 조용~하고... 로컬 클라우드?? 헐... 이건 또 몬 말장난인지... 중요한건 규모... 이전의 방식으론 커버가 안되는 규모다... Amazon이나 Google의 가장큰 무기는 실전에서만 얻을 수 있는 '시행착오'와 '경험치'다.... 책상위에서, 회의실에서 어떻게 가능한 것이 아니다... 흉내만 낼려고 하지 말고 부딧히고, 깨지고, 망가져 봤을 때에만 얻을 수 있는게 있는데... 그러면서 점점 키워 나가야... 클라우드... 'Beta'는 없는것 같다.. 아니 끝까지 'Beta'여야 하지 않을까 싶다... 뭐 지금의 막강한(?) SI구조에서는 꿈같은 이야기겠지만....

Posted by 사랑줍는거지
,