MultiPath TCP 상용화

RFC 6824에 정의한 MultiPath TCP를 KT와 SS에서 상용화 했습니다. 

MultiPath TCP란?

• 스마트 폰과 같은 네트워크 클라이언트에서 인터넷 네트워크에 접속할 때 TCP/IP를 사용합니다. 
• 물리적인 네트워크는 3G, LTE, 그리고 Wifi 등이 있습니다.
• 무선 네트워크를 통한 인터넷 접속
  • 1) 스마트폰: TCP -> 3G/LTE 망 -> 인터넷
  • 2) 스마트폰: TCP -> Wifi -> 인터넷 
• MuiltiPath TCP는 LTE와 Wifi를 함께 사용해서 TCP를 전달하는 방법입니다. 
  • 위에서 1)&2)를 묶어 놓은 것이지요. 

MultiPath TCP (MPTCP) 동작 과정

LTE/3G와 Wifi를 통한 연결을 할 수 있는 스마트 폰으로 MPTCP의 동작과정을 살펴보겠습니다. 

1. 다음 두 개의 연결을 설정합니다.
   • Wi-Fi를 통한 기본 TCP 연결
   • LTE/3G를 통한 백업 연결
2. Wi-Fi를 사용할 수 없거나 Wi-Fi가 반응하지 않게 되면 OS는 LTE/3G 데이터 연결을 사용합니다.
3. MPTCP는 IANA에서 전용으로 할당한 TCP 옵션 필드 30을 사용합니다.
4. 스마트 폰과 서비스 서버 사이의 라우터 또는 스위치와 같은 장비가 MPTCP를 지원하지 않으면 
   • OS는 일반적인 TCP 연결을 사용합니다.
5. Neuromance에 접속을 할때 
   • Wi-Fi를 통해 MPTCP 연결을 시도합니다.
   • 성공하면 OS는 LTE/3G로 데이터를 주고 받을 수 있는 2차 백업 네트워크 연결을 만듭니다. 
   • Wi-Fi를 사용할 수 없거나 Wi-Fi가 불안정해지면 
6. OS의 MPTCP는 바로 2차 백업 네트워크인 셀룰러 데이터로 통신을 전환합니다.

MultiPath TCP의 장점

• 길이 하나 더 늘어나서 : LTE와 Wifi를 동시 이용하기 때문에 대용량 전송이 가능해 지고,
• 길이 하나 더 있으므로: Wifi가 끊겨도 LTE로 지속적인 서비스가 가능합니다. 
• 길을 복수로 이용하기 때문에 늘어난 만큼 에너지 소비는 피할수 없겠구요. 

MultiPath TCP의 구현

• 리눅스 커널이나 iOS7.x이후 부터 이 기능이 구현되있습니다. 
• 사용자 단말 뿐만 아니라 사업자 망에서도 이기능을 구현해야 하는데, 이번에 KT 에서 SS와 함께 이것을 상용화 한것이지요. 

요약정리

• Multipath TCP란?
  • MPTCP는 TCP(전송 제어 프로토콜) 사양의 확장 세트입니다.
  • 사용자 단말(클라이언트)가 여러 네트워크 어댑터를 통해 동일한 대상 호스트에 연결할 수 있구요
  • 기존 네트워킹 인프라와의 호환은 유지하면서 호스트 간에 효과적이고 복원되는 데이터 연결이 가능합니다.

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]