Never Sacrifice Performance for Virtualization

네트웍 병목현상과 요구사항이 가상화로 인해 증가한다. 무겁게 가상화된 환경에서의 cloud와 contents provider 새로운 네트워크 성능의 필요를 다루고/대비하고 있다. 서버들과 같은 전통적인 워크로드는 점점 높은 밴드위스 연결을 관리해야 한다. cloud 와 content 제공자는 또한 더 많은 밴드위스를 필요로 하는 서비스들 혹은 고성능의 동-서 간 통신에 의존적인 네트워킹 기능을 가상화하는 서비스들을 도입하기를 원한다. 




6WINDGate 패킷 프로세싱 소프트웨어는 cloud contents providers 대한  (그들의 데이터센터의 전문기술을 이용하고 증가된 서비스들과 상품들을 제공하귀 위해서 증가된 요건을 만족시킨다

- 한 서버 내에서 10 밀집한/집합한 밴드위스를 제공하면서 VM 밀도를 증가시킨다
- 고 성능 HTTP기반 워크로드
- 비용 효율적인 네트워크 기능들(라우터, 방화벽, 로드 밸런서 )
- 새로운 value added 서비스들(DDos 보호, object 스토리지 )




출처:http://www.6wind.com/solutions/cloud-and-content-providers/data-center-virtualization/


High Performance Virtual Networking Enables New Services

cloud
contents provider 대한 6WINDGate 소프트웨어 솔루션은 표준 intel 서버들과 DPDK 위에서 개방형, 고성능 software 스위치 중심으로 설계되었다.  6WINDGate  높은 네트워크 밴드위스와 고성능 동-서간 통신에 의존하는 새로운 서비스의 도입인 ,  서버에 VM  높은 밀도를 가능하게 하기 위해서 투명하게 네트워킹 성능의 병목 현상을 해결한다







SDN기반의 데이터 센터의 구조내에서 (Open vSwitch 같은) virtual 스위치 소프트웨어의 성능은 전체적인 VM밀도를 결정하는데 있어서 중대한 요소이다. Open vSwitch 는 3개의 주요 기능을 수행한다. :  그것은 서버에 예시되는 가입자의 VM 에서 돌고있는 어플리케이션으로 트래픽의 흐름을 관리한다. (그리고 전형적인 멀티-테넌트 데이터 센터에서 각 서버는 한 가입자 이상에 속해있는 VM 들을 구동시킨다. 그것은 인터넷과 VM들 사이에 “북-남” 트래픽의 흐름을 관리한다. (aggregation 층위에서 데이터 센터의 코어 스위치와 네트워크 applicance들을 통해서). 그것은 동일한 가입자에 속한, 그러나 다른 서버들에 위치한 VM들 사이에서 “동-서” 트래픽의 흐름을 관리한다. (그리고, 종종 다른 랙에서) 





데이터 센터네에서,  일반적인 랙 마운트 혹은 블레이드 서버들에 사용되는 x86 프로세스 들의 지속적인 성능에서 향상을 잘 이용하면서, VM밀집도가 빠르게 증기하고 있다. 동시에, VM에서 구동하는 어플리케이션들은  증가된 네트워크 밴드위스를 필요로 한다. 풍부한 미디어 어플리케이션들에서의 지속적인 증가로, 개별 VM들은 1Gbps 혹은 그 이상의 지속적인 네트워크 밴드위스를 필요로 할 수 있다. 

최종 밴드위스의 도전은 트래픽 패턴에서 계속된 진화로부터 기인한다. 전통적인 client-서버 데이터 센터들에서, 네트워크 트래픽은  주로 “북-남” 이었다 : 인터넷으로 부터, 코어 스위치와 aggregation 층위, ToR 스위치, 그리고 서버 블레이드로 간다. 그러나, 멀티 테넌트 웹 2.0 데이터 센터에서는 VM 이동성과 VM 얼기설기 퍼짐 이 대부분의 트래픽이 “동-서” 이 되도록 야기시킨다. : 같은 가입자 이지만 다른 물리서버에 위치한 VM 간  간. 이런 동서 트래픽의 성장은 높은 밴드위스, 안전한 VM-to-VM 간 통신이 필수적이라는 것을 의미한다. 

이런 밴드위스 요구사항은 표준 Open vSwitch 의 용량을 빠르게
앞지른다. 서버에 구동될 수 있는 VM의 숫자를 축소시키거나, 어플리케이션의 유저가 보는 성능에 제약을 가하면서.

6WINDGate Maximizes vSwitch Performance and VM Density 

Open vSwitch 데이터센터에 적용 되었을 , 6WINDGate  네트워킹 소프트웨어는 기본 L2 스위치 기능에서 5 에서 10배의 가속을 이루어 낸다이것은 OVS 코드 자체에 변화없이, 혹은 VM 동작하는 소프트웨어에 변화없이 이루어진다

OVS 내에서, 6WINDGate 데이터 평면은 6WINDGate fast path 내에서  OVS 제어 평면으로부터 그 자신의 데이터 평면으로 (전달되는) 설정메시지를 감시하고
적당한 패킷들을 가로채고, 처리 한다. 그것에 의하여  5배-10배의 속도 향상을 이루어낸다.


이러한 L2 스위칭 성능의 향상 덕분에, 데이터 센터 운용자는 서버 프로세스의 성능에 지속적인 향상에 의해서 가능해진 VM 밀도의 증가를 얻어낼 수 있다. 또한 높은 네트워크 밴드위스를 개별 VM에 제공할 수 있다. 유저가 돌리는 스트리밍 미디어 어플리케이션들이나 다른 밴드위스-배고픈 워크로드의 성능의 필요를 해결한다.


동시에 6WINDGate  는 IPsec, GRE, NVGRE, VLAN, XVLAN 같은 안전한 터널링 프로토콜에 고성능을 제공한다, VM간 동-서 트래픽에 고성능을 가능하게 한다. 





'Cloud' 카테고리의 다른 글

6wind gate 솔루션  (2) 2014.07.10
chef 개요와 구성요소 #2  (0) 2014.06.30
chef 의 개요와 구성 요소 #1  (0) 2014.06.30
OpenStack Icehouse 기사 해석  (0) 2014.06.11
Posted by FindZone :

6wind gate 솔루션

2014. 7. 10. 15:21 from Cloud
혁신적인 소프트웨어 아키텍쳐를 통해서, 6WINDGate  네트워킹 소프트웨어는 일반적으로 데이터 평면의 프로세싱 성능을 linux 네트워킹 스택에 비교해서 10배 가량 향상 시킨다. 시스템 레벨에서 최고의 네트워크 성능을 얻는 것이다.

산업을 이끄는 성능을 제공하면서, 6WINDGate  는 표준 application API 와 완벽한 호환성을 제공한다. 소프트웨어 재사용을 최대화 하고, 개발기간에 대한 리스크를 최소화 한다. 6WINDGate 는 OpenStack 같은 표준 클라우드 orchestrator, 그리고 레이어 2, 3 콘트롤러 소프트웨어 (OpenFlow 같은) 와 끊김없이 통합한다. 


6WINDGate 는 네트워킹 장비에 대한 완전한 데이터 평면 솔루션을 대표하는/상징하는, 고성능 2-4 계층 프로토콜의 종합적인 제품을 포함한다. 이것은 전체적인 시장 도입까지의 시간을 빠르게 해주면서, 여러 공급업체로부터의 프로토콜 통합의 필요성을 피하도록 해준다. 


출처:

http://www.6wind.com/wp-content/uploads/2014/06/6WINDGate-Solution-Brief-Letter-Size-Jun-15.pdf
 
6WIND 는 네트워크 어플리케이션 개발자들에 대한 성능 문제를 해결해준다. “past path” 아키텍쳐를 가지고 경쟁(제품)을
능가하게 해준다.  6WINDGateTM 패킷 프로세싱 소프트웨어는 다양한 네트워킹과 보안 프로토콜과 기능을 제공하기 위해서, 멀티 코어 프로세스를 사용하는 일반적인 하드웨어에 대해 최적화를 해준다. 6WINDGate 는 SDN, NFV 로의 이전을 가능하게 해주면서, 비용 효율적인 가치 제안을 제공한다. 



최대 데이터 평면의 성능을 제공하기 위해서, 6WINDGate 는 Linux O/S에서 분리된, fast path 라고 불리는 전용 core 들에서 동작하는 패킷 프로세싱 엔진을 구현한다. 같은 소스 코드가  Broadcom, Cavium, Intel and Tilera 등의 혼성의/이기종의 멀티코어 프로세스 하드웨어를 지원한다. 6WINDGate 는 프로세스 SDK 를 이용하여, linux networking stack 에 관여하지 않고도 past path 에서 직접 패킷을 처리한다. 

가령, Intel 플랫폼에서는 DPDK 를 이용한다. fast path 아키텍쳐는 linux 에 투명하다. 기존의 어플리케이션들이 수정될 필요없도록. past path 는 Open vSwitch 가속과 Fast vNIC 드라이버들 뿐 아니라, 주요한 네트워크 프로토콜들( VLAN,  IPsec, NAT, TCP/UDP Termination and more) 을 지원한다. 

 






Posted by FindZone :

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 :

OpenStack Icehouse 기사 해석

2014. 6. 11. 14:26 from Cloud

출처

OpenStack's Icehouse release has arrived, bearing stress-busting gifts for hollow-eyed cloud administrators.
푹꺼진 눈의 cloud 관리자를 위해서 stress를 푸는 선물을 견디면서 , icehouse 가 release되었다. 

The distribution was released on Thursday, and – finally – gives admins some upgrading features for shifting OpenStack's "Nova" compute component to the new version without having to pull the plug on their entire install.
새 버젼이 마침내 배포되었다. nova compute 요소를 새로운 버젼으로 updade하는 기능을 제공한다 (전체 버젼의 plug를 빼지 않고 할 수 있는)

"Limited live upgrades are now supported," the release notes say. "This enables deployers to upgrade controller infrastructure first, and subsequently upgrade individual compute nodes without requiring downtime of the entire cloud to complete.”
“제한된 live upgrade가 이제 지원된다” 고 release note에 나온다.  controller 를 먼저 업그레이드하고, 다음 개별 compute node를 할 수 있다. (전체 cloud 의 downtime 없이도 된다는 것)

Icehouse marks the ninth release of the open source data center management software, which was created in mid-2010 when NASA and Rackspace open sourced some of the software with which they had built their IT.

Since then, major companies including HP and Red Hat have made significant commercial bets on the software, and it has become an area of unusual collaboration within the tech industry. Even proprietary giant Oracle is using it in some capacity and has poured money into the OpenStack Foundation (though has not contributed code back – yet).

That doesn't mean the software lacks problems, though – OpenStack suffers from immaturity in a few areas due to both its youth and the expansive nature of the project.
문제가 적다는 걸 의미하지는 않는다.  Openstack은 프로젝트의 젊음과 확장하는 특성 때문에 몇 개의 area에서 미숙함으로 고생하고 있다.

Icehouse comes with 2,902 bug fixes and 350 new features. Its contributor list has grown as well to over 1,200 individuals – a 32 per cent increase over the previous Havana release.
icehouse는 2902 개의 버그를 픽스했고, 350개의 새로운 기능을 가진다. 기여자 목록은 1200 명 까지 늘었다. (이전 havana버젼에서 32% 증가한)

Besides live upgrades, OpenStack's "Neutron" networking module has been given closer integration with "Nova" compute for better provisioning. It has also been given support via drivers and plugins for OpenDaylight, OneConvergence, Nuage, and IBM SDN-VE.

Storage has been upgraded as well, with the "Swift" object store gaining discoverability features that let admins query more information via an API call, and the "Cinder" block store has been given greater capabilities for migrating data within tiered storage installs. Other services such as orchestration telemetry and dashboards have been given upgrades as well.

 Cinder 블록 store 는 연결된 스토리지 설치 내에서 data 마이그레이션을 위한 더 낳은 성능 을 가진다. 
orchestration telemetry와 대쉬보드 등의 다른 서비스 또한 upgrade 되었다. 

The "Keystone" identity service has been given a major series of upgrades to make it easier to use a single credential across hybrid OpenSack environments, along with self-service capabilities as well.
“Keystone” 은 major 업그레이드 되었다. hybrid openstack 환경에서 single credential 을 더 사용하기 쉽도록 했다. 

As OpenStack is such an expansive project at this stage in its life, we'd direct interested readers to the release notes for more information.

With Icehouse, Red Hat's belief that there will be major money in OpenStack environments by the end of 2015 seems a safe bet.

"The evolving maturation and refinement that we see in Icehouse make it possible for OpenStack users to support application developers with the services they need to develop, deploy and iterate on apps at the speeds they need to remain competitive," said Jonathan Bryce, executive director of the OpenStack Foundation, in a canned press release. ®  

'Cloud' 카테고리의 다른 글

6wind Gate 솔루션 | Never Sacrifice Performance for Virtualization  (0) 2014.07.10
6wind gate 솔루션  (2) 2014.07.10
chef 개요와 구성요소 #2  (0) 2014.06.30
chef 의 개요와 구성 요소 #1  (0) 2014.06.30
Posted by FindZone :