chef 개요와 구성요소 #2

2014. 6. 30. 19:08 from Cloud

Workstations

워크스테이션은 chef-repo 와 동기화 하기 위해서, 그리고 단일 쉐프 서버와 통신하기 위해서, 나이프를 구동하기 위해서 설정되는 컴퓨터이다. 워크스테이션은 대부분의 유저들이 여기서 그들의 작업을 하게 될 것이다. 다음을 포함한다:

     쿡북과 레시피의 개발
     버젼 소스 콘트롤을 가지고 chef-repo  를 유지한다
     쉐프 서버에 chef-repo로 부터 아이템들을 업로드 하기 위해서 나이프를 사용
     정책을 설정, 롤과 환경에 대한 정의를 포함하며, 중요 데이터가 데이터 백에 저장되는지를 확인한다.
     bootstrap 작업 같은, 필요하면, 노드와 상호 작용한다

나이프는 chef-repo 쉐프 서버간에 인터페이스를 제공하는 커맨드 라인 툴이다. 나이프는 유저가 다음을 관리하도록 도와준다


RSA public 조합은 나이프가 쉐프 서버에 접속을 시도할 때마다, 나이프를 인증하기 위해서 사용된다. 이것이 나이프가 쉐프 서버에 등록되는지를 확인하고,

trusted 유저만이 데이터를 바꿀수 있도록 한다.


수프 repo 다음의 데이터 오브젝트가 저장되는 위치이다

  • Cookbooks (including recipes, versions, cookbook attributes, resources, providers, libraries, and templates)
  • Roles
  • Data bags
  • Environments
  • Configuration files (for clients, workstations, and servers)

쉐프-repo 워크스테이션에 위치하며, git 같은 version control 시스템과 동기화되어야 한다. 쉐프-repo 모든 데이터는 소스 코드처럼 다루어져야 한다.


나이프는 쉐프-repo 로부터 쉐프 서버로 데이터를 업로드 하기위해서 사용된다. 업로드가 되면, 데이터는 쉐프 클라이언트가 쉐프 서버로 등록된 모든 노드들을 관리하기 위해서 사용되며, 올바른 쿡북,환경, , 그리고 다른 세팅들이 노드들에 반영되었는지를 확인하기 위해 사용된다


The Server

쉐프 서버는 설정 데이터에 대한 허브로써 동작한다. 쉐프 서버는 쿡북, 노드들에 적용될 정책, (쉐프 클라이언트에 의해서 관리되고 있는 각의 등록된 노드를 설명해주는) 메타데이터를 저장한다. 노드들은 레시피, 템플릿, 파일 배포 같은 설정에 대해 쉐프 서버에 질의하기 위해서 쉐프 클라이언트를 사용한다. 쉐프 클라이언트는 그러면 노드 자체에서 (쉐프 서버에서가 아니라) 가능한 많은 설정 작업을 수행한다. 이런 scalable 접근이 조직을 통해서 설정의 노력을 배포한다



Posted by FindZone :

chef 의 개요와 구성 요소 #1

2014. 6. 30. 17:26 from Cloud

출처:

http://docs.opscode.com/chef_overview.html


Welcome to Chef!

쉐프는 당신의 서버들과 서비스들을 삶으로 가져오면서, 복잡한 인프라를 코드로 변환하는 강력한 자동화 플랫폼이다. 당신은 클라우드에서,  사내에 혹은 하이브리드 에서 동작하던 간에, 쉐프는 당신의 네트웍 사이즈가 어떻던 간에, 어플리케이션들이 어떻게 설정되고, 도입되고, 관리되는지를 자동화 한다. 

쉐프는 단순환 컨셉으로 만들어진다. :  빌딩 블록으로써 제공하는 IT인프라와 자원 원시성의 중앙화된 모델링, 원하는 상태를 얻는다. 이들의 매우 단순한 컨셉은 쉐프가 지구상에서 가장 어려운 인프라의 난제를 다룰 수 있도록 해준다. 

쉐프 클라이언트에서 동작할 수 있는 어떤것이든 쉐프에 의해서 관리될 수 있다. 가령, 당신은 물리적인 장비, 가상 머신, 컨테이너, 혹은 클라우드 기반의 인스턴스를 관리할 수 있다. 쉐프 클라이언트는 노드에서 동작할 수 있는 agent 이며, 그것을 설정할 수 있는 실제의 동작을 수행한다. 쉐프 서버는 모든 설정 데이터에 대한 중앙의 저장소이다. 쉐프 클라이언트와 쉐프 서버는 서로 통신할 수 있다. 보안 통신을 위해서, 그들은 쉐프 클라이언트가 요청하면 서버가 응답을 확인해주는 공용의/ 사설의 키 조합을 사용한다. 


Chef Components

다음의 그림은 노드들, 서버들, 그리고 워크스테이션들을 포함하는 쉐프의 다양한 요소들 사이의 관계를 보여준다. 쉐프 클라이언트에 필요한 정보와 지시를 제공하고 그들의 작업을 할 수 있도록 하기 위해서,  이들 요소들은 함께 동작한다. 



Chef comprises three main elements: a server, one (or more) nodes, and at least one workstation.

  • 쉐프 서버는 구성내에 모든 노드들에 이용 가능한 허브로써 동작한다. 이것은 올바른 쿡북이 이용가능한지, 적당한 정책이 적용되고 있는지, 이전에 쉐프 클라이언트의 동작하는 동안 사용되었던 노드의 오브젝트가 현재의 쉐프 클라이언트 동작에 이용가능한지, 그리고 쉐프 클라이언트의 의해서 관리될 모든 노드들이 쉐프 서버에 등록되고 알려졌는지를 확인한다.  

  • 워크스테이션은 쿡북(과 레시피)가 쓰여지는 위치이다. (롤과 환경, 데이터 백과 같은) 정책 데이터가 정의되고, 데이터는 쉐프-레포 와 싱크가 된다. 그리고 데이터는 쉐프 서버로 업로드 된다. 

  • 각각의 노드는 각 노드가 필요로 하는 다양한 인프라의 자동화 업무를 수행하는 쉐프-클라이언트를 포함한다. 

쿡북들은 또한 매우 중요한 요소이며, 분리된 요소(서버, 노드, 워크스테이션과 함께) 로써 다루어질 수 있다. 일반적으로 쿡북들은 워크스트에션에서 쓰여지고, 관리되고, 쉐프 서버로 옮겨진다. 그리고 각 쉐프 클라이언트가 동작하는 동안, 쉐프 클라이언트에 의해서 노드들로 당겨진다. 


Nodes

하나의 노드는 쉐프 클라이언트에 의해서 관리될 수 있도록 설정되는 물리적, 가상의, 혹은 클라우드 장비이다.  다음의 노드 종류가 관리될 수 있다. 


하나의 클라우드 노드는 아마존 virtual private 클라우드, 오픈스택, 랙스페이스, 구글 컴퓨트엔진, Linode, MS Azure 같은 외부의 클라우드 기반 서비스에서 주관(제공)된다. 외부의 클라우드 기반의 서비스들에 대한 지원을 제공하는 나이프에 대해서, 플러그 인을 사용 할 수 있다. 클라우드 기반의 서비스들에서 인스턴스를 생성하기 위해서, 나이프가 이들 플러그 인을 사용할 수 있다. (인스턴스가) 생성되면, 쉐프 클라이언트가 이들 인스턴스들을 도입, 설정, 관리하기 위해서 사용될 수 있다. 


물리적 : 물리 노드는 보통 서버이거나 가상 머신이다. 그러나, 그것은 통신 채널로 정보를 받고, 보내고, 전송할 수 있는 네트워크에 붙어있는 어떤 액티브 장비가 될 수 있다. 다른말로, 하나의 물리 노드는 (쉐프 클라이언트가 동작할 수 있는, 그리고 쉐프 서버가 쉐프 클라이언트와 통신하도록 해주는 네트워크에 붙어있는) 어떤 액티브 장비이다. 


가상, 가상은 소프트웨어 구현으로 만 동작하는 장비이다. 그러나, 동작은 물리적 장비와 같다. 


네트워크 : 네트웍 노드는 네트워킹 장비이다. - 스위치, 라우터, vlan -쉐프 클라이언트에 의해서 관리되는.


노드에서 중요한 요소는 다음을 포함한다 

  • chef-client 쉐프 서버에서 등록된 모든 노드에서 로컬에서 동작하는 agent 이다

  • 쉐프 서버로 node 등록하고 인증한다

  • 노드 오브젝트를 생성한다

  • 쿡북을 동기화한다

  • 레시피, attribute, 모든 다른 종속성을 포함하는 각각 필요한 쿡북을 로딩하므로써 자원 모음을 compile한다

  • 노드를 설정하기 위한 적당한 필요한 행동을 취한다

  • 예외와 알림을 찾는다

 RSA public 페어는 chef-client 쉐프 서버에 저장된 데이터에 매번 접속할 필요가 있을때 인증하기 위해서 사용된다. 이것은 접속해서는 안되는 어떤 노드를 차단하고, 쉐프 서버에 관리될 노드를 확인한다 


*Ohai
ohai 는 노드에서 attribute 를 찾기 위해 사용되는 틀이며, chef client 기동 시 마다 client 에 이들 attribute를 제공한다. ohai 는 쉐프 클라이언트에 필요하며, 노드에 존재한다. (ohai는 쉐프 클라이언트 설치 과정 중에, 노드에 설치된다.) 

The types of attributes Ohai collects include (but are not limited to):
ohai가 수집하는 attribute종류는 다음을 포함한다. 
  • Platform details
  • Network usage
  • Memory usage
  • Processor usage
  • Kernel data
  • Host names
  • Fully qualified domain names
  • Other configuration details
ohai 에 의해서 수집되는 속성은 자동 속성이다. 이들 속성들은 쉐프 클라이언트의 노드 설정 작업이 끝난 후에, 쉐프 클라이언트가 이들 속성이 바뀌지 않고 남아있는지를 확인한다.


'Cloud' 카테고리의 다른 글

6wind Gate 솔루션 | Never Sacrifice Performance for Virtualization  (0) 2014.07.10
6wind gate 솔루션  (2) 2014.07.10
chef 개요와 구성요소 #2  (0) 2014.06.30
OpenStack Icehouse 기사 해석  (0) 2014.06.11
Posted by FindZone :

가상화 " Bare metal 이란 "

2014. 6. 27. 14:15 from 가상화

가상화 " Bare metal 이란 "


출처

http://searchservervirtualization.techtarget.com/definition/bare-metal-environment


A bare metal environment is a computer system or network in which a virtual machine is installed directly on hardware rather than within the host operating system (OS). The term "bare metal" refers to a hard disk, the usual medium on which a computer's OS is installed.


bare metal 환경이란 가상머신이 host OS 내에 설치된 다기 보다, 하드웨어에 직접 설치되는 컴퓨터 시스템 이나 네트워크를 말한다. “bare metal” 이라는 용어는 컴퓨터의 OS 설치되는 보통의 매체인, 하드디스크를 말한다




The term virtualization refers to the creation of a virtual (rather than actual) version of something, such as an OS, a server or a network resource. A virtual machine is a multi-user shared-resource OS that gives each user the impression of having sole control of all computer or network resources.

 

가상화라는 용어는 OS, 서버 혹은 네트워크 자원 같은 실제라기 보다 가상의 어떤 것의 생성을 말한다. 가상 머신은 유저에게 모든 컴퓨터나 네트워크 자원들의 유일한 제어를 가지도록 해주는 멀티-유저의 자원을 공유하는 OS 이다


https://wiki.openstack.org/wiki/Baremetal


Overview
The baremetal driver is a hypervisor driver for Openstack Nova Compute. Within the Openstack framework, it has the same role as the drivers for other hypervisors (libvirt, xen, etc), and yet it is presently unique in that the hardware is not virtualized - there is no hypervisor between the tenants and the physical hardware. 


baremetal  드라이버는 오픈스택 nova compute 대한 hypervisor 드라이버이다. 오픈스택 프레임웍 내에서, 그것은 다른 하이퍼바이저들에 대한 드라이버들과 동일한 역할을 가진다그러나 그것은 가상화되지 않은 하드웨어에 현재 특화된다- 테넌트들과 물리적 하드웨어 사이에는 하이퍼바이저가 없다


It exposes hardware via Openstack's API, using pluggable sub-drivers to deliver machine imaging (PXE) and power control (IPMI). With this, provisioning and management of physical hardware is accomplished using common cloud APIs and tools, such as Heat or salt-cloud. 


그것은 Openstack API 통해서 하드웨어를 노출시킨다. 플러그 가능한 서브 드라이버들을 사용하여. 이를 통해, 물리적 하드웨어의 프로비젼과 관리가 Heat salt-cloud 같은 공통의 클라우드 API 툴들을 사용하여 이루어진다


However, due to this unique situation, using the baremetal driver requires some additional preparation of its environment.

This driver was added to the Grizzly release, but it should be considered somewhat experimental at this point. See theBugs section for information and links to the Launchpad bug listings.


그러나, 이런 특별환 환경 때문에, baremetal 드라이버를 사용하는 것은 어떤 추가적인 환경의 준비를 요구한다. 드라이버는 Grizzly 릴리즈에 추가되었다. 하지만, 다소 지점에서 실험적이라고 간주되어야 한다. 정보에 대한 버그 부분, 그리고 launchpad 버그 리스트와 링크.


Terminology

There is also some terminology which baremetal introduces.


•Baremetal host and compute host are often used interchangeably to refer to the machine which runs the nova-compute and nova-baremetal-deploy-helper services (and possibly other services as well). This functions like a hypervisor, providing power management and imaging services.


baremetal 호스트와 컴퓨트 호스트는 종종 서로 교환 가능하게 사용된다. nova-compute nova-baremetal-deploy-helper service들을 구동하는 장비로 일컬어진다.   이것은 전원 관리와 image 서비스 제공하면서, 하이퍼바이저 처럼 기능한다.  


•Node and baremetal node refer to the physical machines which are controlled by the compute host. When a user requests that Nova start a baremetal instance, it is created on a baremetal node.


node baremetal node compute host 의해서 제어되는 물리적 장비를 말한다. nova baremetal instance 시작하라고 사용자가 요청할 , 그것은 baremetal node 생성된다.   


•A baremetal instance is a Nova instance created directly on a physical machine without any virtualization layer running underneath it. Nova retains both power control (via IPMI) and, in some situations, may retain network control (via Neutron and OpenFlow).


baremetal instance 아래에서 동작하는 어떤 가상화 층위 없이, 물리적인 장비에 직접 생성되는 nova instance 이다


•Deploy image is pair of specialized kernel and ramdisk images which are used by the compute host to write the user-specified image onto the baremetal node.


배포 이미지는 유저 특화된 이미지를 baremetal node 쓰기 위해서, compute node 의해서 사용되는 전문화된/특정 커널과 ramdisk 이미지의 짝이다


•Hardware is enrolled in the baremetal driver by adding its MAC addresses, physical characteristics (# CPUs, RAM, and disk space), and the IPMI credentials into the baremetal database. Without this information, the compute host has no knowledge of the baremetal node.


하드웨어는 주소, 물리적인 특성(CPU, RAM, disk 공간) , 그리고 IPMI 인증 정보를  baremetal database 추가하므로써, baremetal 드라이버에 등록된다. 이런 정보없이는, compute host baremetal node 대한 지식을 가지지 못한다


Use-cases

Here are a few ideas we have about potential use-cases for the baremetal driver. This isn't an exhaustive list -- there are doubtless many more interesting things which it can do!


•High-performance computing clusters.

•Computing tasks that require access to hardware devices which can't be virtualized.

     가상화 없는 하드웨어 디바이스에 대한 접근을 필요로 하는 컴퓨팅 작업


•Database hosting (some databases run poorly in a hypervisor).

     데이터베이스 호스딩 (어떤 것은 하이퍼바이저에서 형편없이 돈다)


•Or, rapidly deploying a cloud infrastructure ....

We (the  team) have a vision that Openstack can be used to deploy Openstack at a massive scale. We think the story of getting "from here to there" goes like this:

     빠르게 도입하는 클라우드 인프라


•First, do simple hardware provisioning with a base image that contains configuration-management software (chef/puppet/salt/etc). The CMS checks in with a central server to determine what packages to install, then installs and configures your applications. All this happens automatically after first-boot of any baremetal node.

      먼저, chef/puppet/salt 설정 관리 소프트웨어를 포함하는 base 이미지를 가지고 단순한 하드웨어 프로비젼을 한다. 중앙서버에서 CMS 체크인하여 설치할 패키지를 결정하고, 어플리케이션들을 설치/설정한다. 이런 일들은 어떤 baremetal node 처음 부팅 후에 모두 자동으로 일어난다.


•Then, accelerate provisioning by pre-installing your application software into the cloud image, but let a CMS still do all configuration.

      다음에, 클라우드 이미지로 이미 인스톨된 어플리케이션에 의해서 프로비젼을 빠르게 한다. 하지만, CMS 여전히 설정을 한다.


•Pre-install KVM and nova-compute into an image, and scale out your compute cluster by using baremetal driver to deploy nova-compute images. Do the same thing for Swift, proxy nodes, software load balancers, and so on.

     KVM nova-compute 이미지로 사전 설치하고, compute cluster baremetal 드라이브를 사용하여 nova compute 이미지를 배포하도록 스케일 시킨다.

      swift, proxy노드, 로드밸런서, 등등에 대해서도 같은 식으로 한다.


•Use Heat to orchestrate the deployment of an entire cloud.

     전체 클라우드의 배포를 하기위해서 Heat 쓴다


•Finally, run a mixture of baremetal nova-compute and KVM nova-compute in the same cloud (shared keystone and glance, but different tenants). Continuously deploy the cloud from the cloud using a common API.

    마지막으로, 같은 클라우드 내에서 baremetal nova-compute KVM nova-compute 섞어서 구동한다 (keystone glance 공유, 하지만 다른 테넌트)

     공통의 API 사용하여 클라우드로부터 클라우드를 계속해서 배포한다.


'가상화' 카테고리의 다른 글

vmware vSphere  (0) 2014.06.10
Posted by FindZone :