OpenStack Yoga 클라우드 구성

 Openstack 25번째  Y 릴리즈 Yoga 버전의 클라우드 구성입니다.

각 프로젝트 이름과 어떤 일을 하는 것인지 정리했습니다. 

## OpenStack 기능별 구성요소

서비스	프로젝트 코드	설명
Identity Service	Keystone	사용자 인증
Compute Service	Nova	가상머신 관리
Image Service	Glance	커널 이미지나 디스크이미지와 같은 가상 이미지를 관리
Dashboard	Horizon	Web브라우저를 통한 GUI 콘솔
Object Storage	Swift	클라우드 스토리지 AWS S3와 API 호환
Block Storage	Cinder	가상머신이 사용하는 블록스토리지를 관리
Network Service	Neutron	가상 네트워크를 관리
Load Balancing Service	Octavia	부하분산기능을 제고
Orchestration Service	Heat	가상머신 오케스트레이션을 기능
Metering Service	Ceilometer	과금용 사용량 계측기능을 제공
Database Service	Trove	데이터베이스 자원을 관리
Container Service	Magnum	콘테이너 관리
Data Processing Service	Sahara	데이터 프로세싱 서비스
Bare Metal Provisioning	Ironic	베어메탈 프로비져닝
Shared File System	Manila	화일 공유 기능
DNS Service	Designate	DNS 서버 기능
Key Manager Service	Barbican	각종 인증키 관리 기능

네트워크 어플리케이션 고속화(NFV)

네트워크 어플리케이션 고속화

• Multicore Networking Stack 이란 NFV환경에서 네트워크 어플리케이션의 성능(퍼포먼스)를 향상 시키기 위한 기술이다.
• Intel DPDK는멀리코어 프로세서에서 네트워크 패킷을 가속화시킨다.
• DPDK를 이용하는 이유
  • 기존의 네트워크 패킷을 처리할 때는 Linux에서 네트워크 스택을 이용한다.
  • Linux는 시스템 자원을 이용할때 커널 공간과 사용자 공간을 전환하면서 이루어진다.
  • 이것은 네트워크 스택의 지연(Bottle Neck)으로 작용된다.
  • DPDK는 네트워크 지연을 회피하는 방법을 제공한다.

DPDK의 주요 특징

• 1코어당 10Mpbs이상의 데이터플레인 처리한다.
• 이것은 Linux 네트워크 스택보다 10배이상 빠르다.
• 약 30us이하 지연시간을 가진다.
• 멀티 코어 CPU의 자원을 효율적으로 사용한다.
• DPI에서 보다 효과적으로 처리할 수 있다.

OpenStack Juno 정리

OpenStack Juno 릴리즈 정리

• OpenStack은 매해 두번씩 새로운 버전이 릴리즈합니다.(4월, 10월)
• 최신 안정판: 2014.2 (Juno)
• 다음 안정판: 2015.1 (Kilo)

Juno (2014.2)

• Juno는 미국 조지아주 아틀란타시 근교에 지명

• 개발기간: 2014/5 ~ 2014/10
• 개발항목: 340개소 이상
• 버그수정: 약 3200개이상
• 스택수 : 11개
  • Data Processing (Sahara) 추가
• 5대 기여사 (Contribution Company)
• 1. 20% HP
• 2. 18% RedHat
• 3. 13% Mirantis
• 4. 10% Rackspace
• 5.   8% IBM

OpenStack 정식 스텍 리스트

• Swift : Object Storage 클라우드 스토리지
• Nova : Compute 클라우드 컴퓨팅
• Glance : Image Service 가상머신 템플릿 관리
• Keystone : Identity 종합 사용자/테넌트등 인증
• Horizon : Dashboard 사용자 서비스 포털
• Neutron : Networking 클라우드 네트워크 가상화 관리
• Cinder : Block Storage 볼륨 스토리지
• Ceilometer: Telemetry 자원 모니터링, 운영 감시
• Heat : Orchestration 클라우드 오케스트레이션
• Trove : Database 클라우드 데이터베이스 DBaaS
• Sahara : Data Processing 빅데이터 처리

OpenStack 육성 프로젝트

• Ironic : Baremetal 물리머신 관리
• Zaqar : Queue service (MQaaS)
• Barbican : Key management 키 데이터 관리
• Desinate : DNS service (DNSaaS)
• Oslo : Common Libraries 각 프로젝트 공통 코드
• TripleO : Deployment
• Devstack : 개발자용 OpenStack 설치

Juno에서 추가된 새로운 기능들

• Nova
  • RBAC
  • Evacuate Host
  • Console 개선
  • Flavor 추가 속성
  • Host metering
• Glance
  • Image meta data 대응,
  • tag 대응
• Neutron
  • RBAC
  • DVR/L3-HA
  • IPv6서브넷 대응
  • 프로바이더 네트워크 대응
• Heat
  • RBAC
  • 스택 페이징
• Cinder
  • 볼륨 형식 변경
  • 볼륨 확장 속성
  • 볼륨 QoS 속성
• Keystone
  • RBAC 대응 사용자 환경
  • 사용자/도메인간 룰 추가
• Trove
  • 증분 백업
• Sahara
  • 전용 사용자 환경 추가 (Horizon)
  • 프로세스가 실행되는 대상에 대한 링크 추가

OPNFV Initial Distribution

OPNFV Distribution

• OPNFV Support mulitple distributions
  • Ubuntu
  • Redhat (CentOS)
  • Fedora
• Initial kick start distribution
• LTM (Long Term Evolution)

Initial Distribution selection

• Several Project
  • OpenStack
  • ODL (Open Daylight)
  • Infra Set up language support (Puppet, Juju)
  • Plugins Availability
  • Virtual Enviroment
  • Bare metal platform support

Criteria	RHEL	CentOS	Ubuntu	Fedora	Devstack
Release	7	7	14.10	21	Latest
Installer	Packstack	Packstack	JuJu, Fuel	Packstack (RDO), DevStack	Devstack
Support	Yes	Community	Yes	Community	No
Resident Developer
Openstack Release	Juno (RDO), Icehouse (RHEL OSP)	Juno (RDO)	Juno	Icehouse (packaged), Juno (RDO)	Kilo
ODL Release				Hydrogen, Helium (not in repositories)
Installer Languages	Puppet	Puppet	Puppet	Puppet (RDO), bash (Devstack)
Plugins Availability
Ease of Development			Yes
Virtual Environment			Vagrant, Kvm, Docker, LXC etc	Qemu/kvm, Docker, lxc etc
Zero Touch including PXE Boot			Yes (JuJu/MaaS/Cobbler)
Troubleshooting Ease
Long Term Evolution			14.04
Automated Testing Framework Integration			OSTF
Kernel Version	3.10	3.10	3.14 (Realtime Patch)	3.17
Qemu version	2.0	2.0	2.0	2.1

Cloud Network Structure (OpenStack + OpenDaylight + Open vSwitch)

OpenStack + OpenDaylight

• OpenStack과OpenDaylight, SDN, 그리고 NFV와의 관계를 알아보자.

OpenStack 네트워크 관련 스택

• Metering (Ceilometer)
  • 계측기능
  • 경고(알람) 기능
• Orchestration (Heat)
  • 오케스트레이션 기능
  • Ceilometer와 연동하여 자동 Scale in/out 서비스를 제공
  • VPNaaS, FWaas, LBaaS, ..., etc
• Networking (Neutron)
  • 네트워크 관리 기능

OpenStack Orchestration (Heat)

• 주된 사용 용도
  • 다수의 인스턴스의 연동이 필요하거나,
  • 단일 서비스 인스턴스를 확장할 때 사용
  • 인스턴스의 오케스트레이션 기능을 제공하며,
  • 어플리케이션의 디플로이를 쉽게 해 줌
• TOSCA
  • Topology and
  • Orchestration
  • Specification for
  • Cloud
  • Application

OpenStack Networking (Neutron)

• 클라우드에 네트워크를 관리
• 다수의 써드파티 플러그 인 형태로 선택해서 사용
  • Cisco
  • Juniper
  • Midokura
  • NEC
  • Mellannox
• 모듈형 레이어 2 (ML2) 플러그 인
  • OpenStack Havana 릴리즈 이후부터 플러그인 형태로 제공되었으며,
  • OSI Layer2기술을 제공하는 플러그인.

ML2 PlugIn (Midonet)

• 엣지오버레이형 네트워크 플러그인 (midonet)
  • IaaS 클라우드 를 위해서 개발
  • 제어 콘트ㄹ러 기능을 분산함
  • 데이터 베이스가 네트워크 토폴로지 정보를 가짐

ML2 PlugIn (Cisco Nexus)

• Cisco Open Cloud
  • USS, Nexus, Cisco One 기술을 사용해서 OpenStack관 연동
  • Cisco SDN 기반
  • Nexus 1000v
  • onePK
  • ONE Controller
• Cisco Open Cloud Solution
  • OpenStack기반
  • Video Scalable Object Storage
  • Scalable Message Bus
  • App Metering
  • 가상화 기반의 네트워크 어플리케이션 서비스을 제공이 목적

모듈형 Layer2 Plugin

• Neutron Server에서 ML2 Plugin형태로 서비스 제공
• ML2 TypeDriver
  • Local
  • Flat
  • GRE
  • VLAN
  • VXLAN
• Mechanism Manager
  • Arista
  • Cisco Nexus
  • Hyper-V
  • L2 Population
  • Linux bridge
  • Open vSwitch
  • Tail-F NCS

ML2를 사용한 클라우드 동작 과정

• Host1, Host2, 그리고 Cisco Nexus Switch가 있다고 가정
• Host1 에서 동작
  • Nova API에 의해서 Nova Compute생성
  • Neutron Server에 의해서 Neutron OVS Agent 생성
  • Neutron DHCP에 의해서 Neutron L3 Agent 생성
  • 네트워크 구성
  • VM1 -> br-int -> br-eth2 - eth2
• Host2 에서 동작
  • Nova API에 의해서 Nova Compute생성
  • Neutron Server에 의해서 Neutron OVS Agent 생성
  • Neutron DHCP에 의해서 Neutron L3 Agent 생성
  • 네트워크 구성
  • VM2 -> br-int -> br-eth2 - eth2
• Host1에서 OVS Agent 동작
  • ML2 OVS Mechanism Driver에 의해서
  • VM1용 br-eth2 포트에
  • 가상 NIC IF에 VLAN 추가
• Host2에서 OVS Agent 동작
  • ML2 OVS Mechanism Driver에 의해서
  • VM2용 br-eth2 포트에
  • 가상 NIC IF에 VLAN 추가
• OpenStack 자동 설정 후 VM1-VM2간 ping으로 상호 통신 테스트 실시
• VM1에서 발생한 패킷의 이동 경로
  • Host1
  • VM1 -> Br-int -> Br-eth2 -> eth2
  • Host1 -> Cisco Neus Switch -> Host2
  • eth2/1 에서 Host1의 패킷 수신
    • ML2 Cisco Nexus Mechanism Driver에서
    • eth2/1에 VLAN 트렁크 설정
  • eth2/2 에서 Host2로 패킷 전달
    • ML2 Cisco Nexus Mechanism Driver에서
    • eth2/2에 VLAN 트렁크 설정
  • Host2
  • eth2 -> Br-eht2 -> Br-int -> VM2

OpenDaylight에서 OpenStack Neutron용 ML2 PlugIn

• SDN Controller인 OpenDaylight에서 OpenStack용 서비스 NBI 공개
  • Neutron API
  • OpenDaylihgt 내 다수의 Neutron network을 실장
• OpenStack과 OpenDaylight의 Structure
  • OpenStack Neutron
    • Neutron plugin
  • OpenDaylight APIs (REST)
  • Netutron service
    • VTN Provider
    • DOVE Provider
    • Other Provider
• 최초 릴리즈 OpenDaylight에서는 L4~L7 서비스는 제공하지 않았음.
• Open vSwitch와의 연동

PMD와 가상 환경에서 DPDK

• Intel DPDK란?
• Linux 커널로 네트워크를 처리하려면 오버헤드가 발생한다.
• 오버헤드를 줄이고 더 간단하고 빠른 네트워크 처리 방식을 위한 도구이다.

Linux 커널의 네트워크 처리 (오버헤드 분석)

• 왜 Linux 커널의 네트워크 처리에 오버 헤드가 일어날까?
• 예를 들면
  • Linux 커널은 네트워크 패킷을 "인터럽트'로 구현한다.
  • 네트워크 뿐만아니라 다양한 프로세스를 처리하지만
  • 외부에서 NIC으로 네트워크 패킷이 도착하면 NIC는 커널로 인터럽트를 건다.
  • 커널은 지금 실행하는 처리를 중단하고
  • NIC의 장치 드라이버로 처리를 할당하며
  • 인터럽트가 발생한 네트워크 NIC에서 늘어온 패킷을 처리한다.
  • 따라서 커널이 네트워크 패킷에 대한 인터럽트 처리와 함께
  • 실제 패킷 처리 프로세스로 바뀔때까지 지연이 발생한다.
  • 이런 오버 헤드는 커널의 기존 프로세스였지만,
  • 네트워크를 소프트웨어로 구현하는데는 다소 큰 오버헤드가 된다.

DPDK의 기본 동작

• DPDK의 동작
  • DPDK는 PMD (Poll Mode Driver)라는 특별한 장치 드라이버를 사용한다.
  • 이 장치 드라이버는 특정 CPU 코어에 상주하며,
  • 외부에서 패킷이 도달하는 지 항상 감시합니다.
  • 네트워크 장치(NIC)에 패킷이 도착하면,
  • 바로 패킷을 처리합니다.
  • 즉 인터럽트의 오버헤드를 줄이는 것이지요.

DPDK의 실행 방식 (2가지)

• Run-to-Completion
  • PMD를 실행하는 CPU 코어가 네트워크 패킷까지 한꺼번에 실시하는 방식.
• Pile-line
  • PMD를 실행하는 CPU 코어가 있고 실제 패킷의 처리는 다른 CPU 코어에서 하는 방식.

DPDK의 패킷 처리

• DPDK를 사용하면
• Linux 커널이 제공하는 패킷 처리 방식을 무시하고
• DPDK를 사용하는 사용자 응용 프로그램이 직접 패킷을 처리한다는 것이다.
• 다시말하면 DPDK의 어플리케이션은 네트워크 패킷의 헤더를 보고
• TCP / IP 등의 프로토콜을 판별부터 시작해서 자신이 하려는 기능까지
• 사용자 응용 프로그램에서 전부 구현해야 하는 것을 의미합니다.
• 즉 DPDK를 사용한다고 해서 네트워크 성능이 향상되는 것만은 아니고.
• DPDK를 얼마나 잘 이용해서 네트워크 기능을 구현하는지가 중요하게 된다.

DPDK를 사용한 성능 평가

• 기존의 네트워크 평가처럼
• NIC과 NIC에 패킷 전달만 가지고
• DPDK의 성능을 평가하기는 부족하다.
• RSS (Receive-Side Scaling) 기능을 지원하는 최신 NIC이라면
  • NIC이 수신한 패킷을 여러 그룹으로 나누어
  • 각 그룹별로 CPU 코어를 병렬로 해서 처리할 수 있다.
• 10Gbps 이상의 고속 NIC을 사용할 경우
  • PMD가 점유된 단일 코어로는 성능이 떨어지므로,
  • 여러 CPU 코어에서 PMD를 실행하여
  • 단일 CPU 코어 성능 병목이되는 것을 방지한다.

가상 환경에서 DPDK

• Linux KVM 가상 환경에서 두 종류의 커널이 있다.
  • 호스트 Linux 커널
  • 게스트 OS의 커널
• DPDK 응용 프로그램은 커널을 기반으로 패킷을 처리하기 때문에
  • 호스트 커널이 DPDK를 사용할지.
  • 게스트와 호스트 커널 모두 DPDK를 사용할지.
  • 아니면 어느 커널은 아무것도 안하지만 다른 커널에서 처리할지를 함께 고려해야한다.
• DPDK는 패킷 처리를 응용 프로그램에서 처리하기 위한 도구이기 때문에
• 가상 머신 환경에서 어떻게 DPDK를 사용할지는 사용자의 자유이며,
• 현재 다양한 레이어를 어떻게 구현할지 다양한 구현방법을 제안/검증하는 단계이다.
• 예시 1 (사용자 어플리케이션이 직접 가상 NIC에 접근)
  • 물리적 장치에 의존하는 환경으로 만든 DPDK 지원 응용 프로그램이라면
  • 게스트 OS의 커널을 생략하고,
  • 사용자 응용 프로그램에서 직접 가상 NIC에 액세스한다.
  • 가상 NIC와 물리 NIC 사이의 패킷 처리는
  • 기존처럼 하이퍼 바이저가 제공하는 가상 스위치를 사용하므로
  • 오버 헤드는 기존과 크게 다르지 않다.
• 예시 2 (사용자 어플리케이션이 가상 OS의 DPDK를 거쳐 가상 NIC에 접근)
  • 게스트 OS의 DPDK 지원 응용 프로그램에서
  • 물리적 NIC를 직접 조작하는 방법
  • 하이퍼 바이저의 기능은 특정 물리적 NIC를 가상 머신까지 통과시킨다.
  • 하이퍼 바이저가 제공하는 가상 스위치의 기능은 사용할 수 없고,
  • 여러 가상 시스템에서 물리적 NIC를 공유하려 한다면,
  • SR-IOV를 지원하는 특별한 물리적 NIC이 필요하다.
  • SR-IOV란 하나의 물리적 NIC를 가상으로 여러 NIC으로 보여주는 기능을 NIC 하드웨어로 제공한 것이다.
• 예시 3 (호스트의 가상 NIC을 DPDK가 사용)
  • 다른 가상 머신의 네트워크 기능은 종래대로 게스트 OS의 커널에 맡겨두고,
  • 호스트 Linux 측의 가상 NIC를 DPDK 가 사용하는 방법
  • Linux에서 가상 스위치 기능을 제공하는 오픈 소스 Open vSwitch에 DPDK를 사용하여
  • Open vSwitch와 물리적 NIC 사이의 패킷 처리 속도를 향상시키는 방법입니다.
• 예시 4
  • 하이퍼 바이저의 가상 스위치 기능 및
  • 게스트 OS 내부의 패킷 처리를 다시 새롭게 구현하여
  • 호스트와 게스트의 네트워크 처리를 터널이 아니어도
  • 빠르게할 수 있는 방법
• 예시 5 (NetVM)
  • 하이퍼 바이저와 가상 머신이 메모리를 공유하여
  • 메모리 간의 데이터 복사없이 패킷을 교환하는 방식
  • 공유 메모리와 물리적 NIC 사이의 데이터 교환은 DPDK를 사용
  • DPDK는 물리 NIC에서 공유 메모리에 패킷 데이터가 로드 된 후
  • 여러 가상 머신이 협력하여
  • 패킷에 필요한 처리를 해갑니다.
• 예시 5의 좀더 구체적인 예시 (방화벽 기능이 있는 라우터를 구현)
  • 라우팅 기능을 담당하는 가상 머신과
  • 방화벽 기능을 담당하는 가상 머신으로 역할 분담
  • 이런 두가지 가상 머신 간 패킷 정보를 공유 메모리의 큐를 통해서 전달

요약

• NFV의 목적은 "기존의 네트워크 장비를 가상 머신에서 실행한다"하는 것이므로
• "1 가상 머신 = 1 네트워크 장비"라고 가정합니다.
• DPDK는 PMD가 상주하며, 전달된 패킷 처리에 따라 Run-to-completion과 Pipe-line으로 나뉩니다.
• 가상머신에서 호스트와 게스트 커널 중에서 어느쪽에서 DPDK를 사용할지 다양항 방식이 이야기 되며.
• NFV의 목적처럼 여러 가상 시스템을 연계하여 새로운 네트워크 장비를 제공할 수 있습니다.

참조

• [NetVM: High Performance and Flexible Networking Using Virtualization on Commodity Platforms]