'Computing' 카테고리의 다른 글
CPU 아키텍쳐를 알아보자 (0) | 2014.10.23 |
---|
CPU 아키텍쳐를 알아보자 (0) | 2014.10.23 |
---|
CPU 구조 - 32-bit vs 64-bit (0) | 2014.10.23 |
---|
단말기 SIM, Ki인증 (0) | 2014.10.02 |
---|---|
IMEI, IMSI, MSISDN 단말식별자 (0) | 2014.10.02 |
VoLTE overview #2 (0) | 2014.06.10 |
VoLTE 알카텔 루슨트 #1 (0) | 2014.06.10 |
VoLTE | EPS의 이해 (0) | 2014.06.10 |
단말기 AuC 인증 (0) | 2014.10.02 |
---|---|
IMEI, IMSI, MSISDN 단말식별자 (0) | 2014.10.02 |
VoLTE overview #2 (0) | 2014.06.10 |
VoLTE 알카텔 루슨트 #1 (0) | 2014.06.10 |
VoLTE | EPS의 이해 (0) | 2014.06.10 |
단말기 AuC 인증 (0) | 2014.10.02 |
---|---|
단말기 SIM, Ki인증 (0) | 2014.10.02 |
VoLTE overview #2 (0) | 2014.06.10 |
VoLTE 알카텔 루슨트 #1 (0) | 2014.06.10 |
VoLTE | EPS의 이해 (0) | 2014.06.10 |
Frame Relay의 이해 (0) | 2014.06.11 |
---|
데이터 센터네에서, 일반적인 랙 마운트 혹은 블레이드 서버들에 사용되는 x86 프로세스 들의 지속적인 성능에서 향상을 잘 이용하면서, VM밀집도가 빠르게 증기하고 있다. 동시에, VM에서 구동하는 어플리케이션들은 증가된 네트워크 밴드위스를 필요로 한다. 풍부한 미디어 어플리케이션들에서의 지속적인 증가로, 개별 VM들은 1Gbps 혹은 그 이상의 지속적인 네트워크 밴드위스를 필요로 할 수 있다.
최종 밴드위스의 도전은 트래픽 패턴에서 계속된 진화로부터 기인한다. 전통적인 client-서버 데이터 센터들에서, 네트워크 트래픽은 주로 “북-남” 이었다 : 인터넷으로 부터, 코어 스위치와 aggregation 층위, ToR 스위치, 그리고 서버 블레이드로 간다. 그러나, 멀티 테넌트 웹 2.0 데이터 센터에서는 VM 이동성과 VM 얼기설기 퍼짐 이 대부분의 트래픽이 “동-서” 이 되도록 야기시킨다. : 같은 가입자 이지만 다른 물리서버에 위치한 VM 간 간. 이런 동서 트래픽의 성장은 높은 밴드위스, 안전한 VM-to-VM 간 통신이 필수적이라는 것을 의미한다.
이런 밴드위스 요구사항은 표준 Open vSwitch 의 용량을 빠르게 앞지른다. 서버에 구동될 수 있는 VM의 숫자를 축소시키거나, 어플리케이션의 유저가 보는 성능에 제약을 가하면서.
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간 동-서 트래픽에 고성능을 가능하게 한다.
6wind gate 솔루션 (2) | 2014.07.10 |
---|---|
chef 개요와 구성요소 #2 (0) | 2014.06.30 |
chef 의 개요와 구성 요소 #1 (0) | 2014.06.30 |
OpenStack Icehouse 기사 해석 (0) | 2014.06.11 |
6wind Gate 솔루션 | Never Sacrifice Performance for Virtualization (0) | 2014.07.10 |
---|---|
chef 개요와 구성요소 #2 (0) | 2014.06.30 |
chef 의 개요와 구성 요소 #1 (0) | 2014.06.30 |
OpenStack Icehouse 기사 해석 (0) | 2014.06.11 |
워크스테이션은 chef-repo 와 동기화 하기 위해서, 그리고 단일 쉐프 서버와 통신하기 위해서, 나이프를 구동하기 위해서 설정되는 컴퓨터이다. 워크스테이션은 대부분의 유저들이 여기서 그들의 작업을 하게 될 것이다. 다음을 포함한다:
나이프는 chef-repo 와 쉐프 서버간에 인터페이스를 제공하는 커맨드 라인 툴이다. 나이프는 유저가 다음을 관리하도록 도와준다
RSA public 키 조합은 나이프가 쉐프 서버에 접속을 시도할 때마다, 나이프를 인증하기 위해서 사용된다. 이것이 각 나이프가 쉐프 서버에 잘 등록되는지를 확인하고,
trusted 유저만이 데이터를 바꿀수 있도록 한다.
수프 repo 는 다음의 데이터 오브젝트가 저장되는 위치이다.
쉐프-repo 는 워크스테이션에 위치하며, git 과 같은 version control 시스템과 동기화되어야 한다. 쉐프-repo 에 모든 데이터는 소스 코드처럼 다루어져야 한다.
나이프는 쉐프-repo 로부터 쉐프 서버로 데이터를 업로드 하기위해서 사용된다. 업로드가 되면, 그 데이터는 쉐프 클라이언트가 쉐프 서버로 등록된 모든 노드들을 관리하기 위해서 사용되며, 올바른 쿡북,환경, 롤, 그리고 다른 세팅들이 노드들에 잘 반영되었는지를 확인하기 위해 사용된다.
The Server
쉐프 서버는 설정 데이터에 대한 허브로써 동작한다. 쉐프 서버는 쿡북, 노드들에 적용될 정책, (쉐프 클라이언트에 의해서 관리되고 있는 각 각의 등록된 노드를 설명해주는) 메타데이터를 저장한다. 노드들은 레시피, 템플릿, 파일 배포 같은 설정에 대해 쉐프 서버에 질의하기 위해서 쉐프 클라이언트를 사용한다. 쉐프 클라이언트는 그러면 노드 자체에서 (쉐프 서버에서가 아니라) 가능한 많은 설정 작업을 수행한다. 이런 scalable한 접근이 조직을 통해서 설정의 노력을 배포한다.
6wind Gate 솔루션 | Never Sacrifice Performance for Virtualization (0) | 2014.07.10 |
---|---|
6wind gate 솔루션 (2) | 2014.07.10 |
chef 의 개요와 구성 요소 #1 (0) | 2014.06.30 |
OpenStack Icehouse 기사 해석 (0) | 2014.06.11 |