지밍이 블로그

# 데이터 플레인 가속화

: DPA, Data Plane Acceleration, 

: 고속 네트워크 패킷 처리를 위한 데이터 플레인 가속화

# 네트워크 패킷처리 소프트웨어

> 기존, 네트워크 패킷처리 구조를 분리

- 사용자단의 응용프로그램은 패킷전송을 위해 소켓을 생성하여 패킷 송신

- 커널단에서 프로토콜처리(TCP/UDP/IP)를 진행 후 사용자단으로 소켓을 통해 전달

> 현재, DPA 기술

- 기존서버의 고속 네트워크 패킷처리에 대한 문제를 해결하기 위함

- OpenOnLoad, Netmap, PF_RING, DPDK, ODP,..

- 네트워크 패킷을 커널영역을 통과하여 사용자단에서 직접 처리

- DpenOnLoad : NIC에서 응용네트워크 패킷의 헤더에 포함된 플로우 정보를 기반으로 사용자단으로 패킷을 직접 전달

- Netmap : 패킷 자원 사전할당, 다중패킷 처리기술, 커널과 사용자단 사이의 패킷에 대한 메타데이터 및 메모리 버퍼 공유 

- PF-RING : 고속 네트워크 패킷 캡처, 필터링 및 분석, DNA(Direct Nic Access)를 통한 고속네트워크패킷 처리

# Intel DPDK

: Data Plane Development Kit

- 사용자단의 (인텔 DPDK 라이버러리 API + EAL(Environment Abstraction Layer) ), 커널을 통과하여 NIC에 직접 액세스

- 최적화된 NIC 드라이버 제공

- Run-to-completion 모델(멀티프로세서 수와 데이터 플레인 성능 비례)

*주요기능

1. Memory Manager

: 메모리에서 객체들의 풀 할당

: huge 페이지 메모리 공간에 생성, ring 사용(사용가능 객체저장), DRAM채널에 균등 저장 

2. Buffer Manager

: 메모리 풀에 저장되는 고정 길이의 버퍼들을 사전 할당하여 관리 (액세스 시간 절약)

3. Queue Manager

: 기존의 spinlock대신 lockless 큐를 구현하여 사용

: 패킷을 병렬처리할 때 불필요한 대기시간을 절약

4. Flow Manager

: 인텔 스트리밍 SIMD 확장기술 이용, 네트워크 패킷 헤더에 대한 hash정보를 생성, 네트워크 패킷들이 동일 플로우에 할당

: 고속처리 가능

5. Poll Mode Driver

: 기존의 비동기식 인터럽트대신 최적화된 동기식 폴 모드 인터럽트 처리루틴 사용

# 인텔 DPDK 패킷처리 구조

1. Packet I/O Rx - NIC에서 전달된 패킷이 처리, NIC에 대한 폴 모드 드라이버를 포함

2. Packet Parser - 수신된 패킷에 대한 프로토콜 스택 식별, 유효성 검사

3. Packet Classification - 패킷을 트래픽 플로우 중 하나에 매핑, hash함수로 exact match테이블 lookup 수행, 

충돌방지를 위해 bucket로직을 사용하는 기능을 수행 

4. Policer - srTCM/trTCM 알고리즘사용, 패킷에대한 통계정보 수집

5. Load Balancer - 수신된 패킷을 응용프로그램에 분배, 각 응용 worker에 대한 트래픽 플로우의 친화도 유지, 플로우 내의 패킷순서 유지

6. Worker - 응용 프로그램 수행

7. Dropper - RED(Random Early Detection) 알고리즘 / Weighted RED 알고리즘 사용, congestion 관리 수행

현재 스케줄러의 큐로드 레벨, 패킷의 우선순위에 따라 패킷을 drop하는 기능 수행

8. Hierarchical Scheduler - 수천개의 leaf노드(큐)로 구성된 5개의 레벨에 대한 계층적 스케줄러 포함

a. 출력포트

b. 서브포트 - 트래픽 shapping

c. 파이프 - 트래픽 shapping

d. 트래픽 클래스 - 우선순위 적용

e. 각각의 파이프트래픽 클래스 내의 큐 - WRR(Weighted round Robin)알고리즘 적용

9. Packet I/O Tx - 다수의 NIC포트로 패킷을 송신

http://www.nextree.co.kr/p2010/

# 웹 서비스 시나리오

- UDDI : 웹 서비스 관련 정보의 공개와 탐색을 위한 표준

- 공공데이터 포털

- 서비스제공자 

- 서비스요청자 

# 웹서비스 3가지 기술요소

- WSDL : Web Service Description Language, 웹서비스를 표현 및 기술, XML

- SOAP : Simple Object Access Protocol, 메시지프로토콜

- UDDI : 기술의 탐색, 등록 ----> 국내에선 없음

*Jax-WS - java 메시지와 Soap메시지를 매칭,바인딩 해주는 객체

# 웹 서비스 아키텍처 모델

- framework ? 반 자동화 되어있는, 스스로 동장할 수 없음, 프로그램으로 동작 시켜줘야함

- Server ? 서비스를 제공할 수 있음, 자동화 되어있는,

> 웹서비스 핵심 기술 표준

- XML

- XML 스키마

- SOAP

- WSDL

- UDDI

> 웹 서비스 확장기술 표준 (wS-*) 

- 보안처리 WS-Security, WS-Trust, WS-SecureConversation

- 트랜잭션처리 WS-Coordination, WS=Transaction

- 신뢰성있는 메시지 WS-ReliableMessaging, WS-Addressing

- 기타(BPM-업무프로세스, RM-자원관리)

=> 실무에서 이런 확장기술을 적용하는 분위기는 아니지 ㅎㅎ

# XML[Extensible Markup Language]

- W3C에서 다른 특수 목적의 마크업 언어를 정의하기 위한 마크업 언어

- XML 활용도 높다면 데이터처리에 사용, 보통 요즘엔 환경설정에 사용

- XML은 문서로 구조화 할때, 많이 사용

- HTML의 단점이, 표현과 구현을 섞어놓아 디자이너와 개발자의 협업이 어려웠음

- XML은 HTML에서 데이터만 끄집어내자하여 떨어져 나옴

- Transformation, XSLT

- CSV

- X-Path, XML의 path를 처리하는 기술

- XHTML, HTML5

- RDF, ROA, 시맨틱 웹의 토대

- 라이센스 제약이 없고, 플랫폼이 독립적, 많은 지원이 있음

> XML의 구조

- 버전표기

- root 엘리먼트 1개만 반드시 포함

> XML의 특징

- 문서의 내용과 스타일을 분리하여 사용

- 표준 규약,ft 

- 문서(microso, 전송자료(ACORD, OFX, IFX...)

> Well-Formed 

> Valied

> Namespace

: 논리적 이름 구분을 위함

> XML스키마의 목적

- DTD와 같이 XML문서를 구조화하기 위해 W3C에서 표준화하여 제공

> XML스키마의 특성

- XML문법, XML 네임스페이스 지원, 루트요소를 반드시 가져야함, 

- <schema>, 다양한 데이터타입, 문서화 메커니즘 제공

> DTD와 XML스키마의 특징 비교

> XML 스키마 네임스페이스

- 스키마 네임스페이스를 지정하지 ㅇ낳으면 파서는 XML 스키마로 인식할 수 없음

- xs, xsd와 같은 접두사를 많이 사용

> 대상 네임스페이스(targetNamespace)

- 새로운걸 만들어서 참조를 하려면 그대로~ 붙여야함

- targetNamespace를 안붙이면 안되. namespace중복이 되버려. 선언은 할 수 있음

> elementFormDefault, attributeFormDefault

- "qualified", "unqualified"

- XML파서가 알아서 처리를 해줌

- full package를 주는게 좋음.. 결국 언젠간 확장하다보면 충돌 날 수 있으므로

# SOAP

: 개방형 프로토콜을 사용하여, XML기반의 SOAP 메시지를 네트워크 상에서 교환하는 프로토콜(HTTP, HTTPS, SMTP를 기저로 깔고)

: 구조, 전송, 상호 중립성의 개념을 도입

: 태생 자체가 상호독립/호환을 위해서 만들어짐

- SOAP 1.2 version

> 특징 (장점)

- SOAP을 기본적으로 HTTP기반 위에서 동작,

- HTTP와 같이 프록시와 박화벽에 구애받지 않고 쉽게 통신이 가능,

- 플랫폼 및 프로그래밍 언어에 독립적

- 간단하고 확장가능, 멀티파트 MIME구조를 사용, 첨부를 통합하는 SOAP XMl 메시지를 지원

- 페이로드

> 특징 (단점)

- 성능이슈, (실제 stress test시, 응답속도가 예전에 비하여, 몇배이상 빨랐음) 

   ==> 상대적으로 늦는다는 이야기지, 이제는 더이상 단순히 느리다라고 할 수 없음

# SOAP 메시지 구조

1.1 버전

1.2 버전

# WSDL

: 웹서비스가 어디에 존재하는지, 웹서비스로 무엇을 할 수 있는지, 또 어떻게 하는지, XML형식으로 기술하여 제공

: SOAP메시지에서 주곱다아야하는 데이터가 WSDL에 있음

> WSDL 네임스페이스 목록

> 문서구조

> 웹서비스 스택

# 웹스비스 프레임워크

- Aegis Databinding

- Spring

- JAX-WS지원

- 비동기방식의 호출 지원

- 바이너리와 기존 프로토콜 지원

- 기타.. (책참고)

> Apache CXF 도구

> Apache CXF 아키텍처

- CXF-API : Bus,

> SOAP 메시지 구조

누가 추천해주신 wsgi(Web Server Gateway Interface)를 만들어보려구,

함께 추천해주신 파이썬책도 겸사겸사 주문했는데 아직두 발송전인듯..

인터파크는 평균 5일은 걸리는 것 같다는 ㅜㅜ

그래서 암튼 그전까지 퇴근 후 5일짜리 교육 신청함... 

주제 : 웹서비스 - WSDL & SOAP

목차 : 

1. 웹 서비스 개요

2. 웹 서비스 기반기술

3. 웹 서비스 프레임워크

4. 웹 서비스 구현

5. 웹 서비스 클라이언트 구현

6. 오픈 API와 매시업

포카칩뜯으면서 주저리 주저리 정리하고 자야지... 

------------------------------------------------------------------------------

1일차 - 웹 서비스 개요

# 웹서비스의 정의

> 웹서비스의 의미는 굉장히 다양함

> 전체 구성도

> Back-end, Front-end, Middle-ware(모바일환경에서의 push server, MQ ...)

> 정의

- 이종 시스템을 통합하고 HTTP를 통해 재사용 가능한 비즈니스 기능 공개 방법을 제공 - 서비스디자인패턴, 로버트다이뇨(2013)

- 네트워크 상에서 서로 다른 종류의 컴퓨터들 간에 상호작용을 하기 위한 소프트웨어 시스템 - 위키

- 기계 대 기계 상호작용을 지원하기 위해 설계된 소프트웨어 시스템 - W3C

=> 다 통합... 왠지 클라우드서비스가 생각난다..

> SOA vs ROA

- Service oriendted vs Resource Oriented

- OSGi, Open Service Gateway initiative

> SOAP/WSDL 기반에서 웹 서비스

- 클라이언트, 서비스 / 요청자, 제공자 / 서비스 컨슈머, 서비스 제공자

> 웹서비스 연관 용어

- 웹 2.0 

- Semantic Web, 웹 3.0

- Open API

- Mash-up

> 웹서비스의 등장배경

- 비지니스 관점 : 기업 내, 기업 간, 기업과 고객 간 통합된 서비스 증대 및 Time to Market

- 기술적 관점 : POP -> OOP -> COP: CBD -> SOP: SOA

                 절차지향 객체지향 컴포넌트지향 서비스지향

- 분산프로토콜 등장 : RMI(rmic.exe), RPC

> 웹서비스 사용 목적

- 웹서비스 레이어드 아키텍처

> 웹서비스 고려사항과 대안

- 마샬링, 언마샬링시 바이트스트림으로 직렬화하여 전송

- 네트워크 통신의 부분적 실패에 대비(여기서는 네트워크 통신의 장애를 말함)

- 웹서비스의 본질적인 위험요소 고려

> 웹서비스 API 스타일

- 엔터프라이즈 애플리케이션 아키텍처 패턴

- MVC Architexture

- 퍼사드(Facades[GoF]) 패턴

- RPC API(JAX-RPC) / 메세지 API(JAX-WS) / 리소스 API(JAX-RS)

> 웹서비스 API 설계 시 고려사항

- 캡슐화

- 서비스 계약 : 클라이언트와 서비스가 어떻게 상호작용 할 수 있는지 명시한 협약서

- 자율성 : 상호 결합성이 낮아야 함

- 지연시간

- 부분실패, RPC-API(proxy)

- 텍스트 기반 데이터의 바이너리 메시지 인코딩

> 테스트 개발환경 설정

- IDE 설치 및 Subversive, AnyEdit 플러그인 설치

- 빋드환경 배포, Maven

- WAS, Tomcat

- 개발 표준 설정 : 명명규칙, 소스코드 포맷, 파일 포맷 등

세미나 동영상 ....

VPN

보안성이 없는 네트워크를 보안 통신을 하는 기술

- Authenticity 상대방이 정말 상대방인지

- Integrity 데티터가 중간에 변경되지는 않았는지

- Confidentiality 누가 중간에 데이터를 훔쳐보지는 않았는지

- Remote-access

- LAN to LAN

- 전통적 양방향

- EasyVPN^TM (VPN Client가 붙고, VPN 허브 장비가 서비스를 push)

# VPN protocol, 보안

1. 암호화 알고리즘 Confidentiality 

- 대칭형(Symetric Encryption), 데이터 암호화, 3DES, AES

- 비대칭형(Asymmetric Encryption), 상대방인증, RSA

2. Hash 알고리즘 Integrity 

- 데이터에 특정 함수를 돌려서 정해진 길이의 고유 값을 생설

- Hash에서 고유값은 중복되지 않음

- hash 자체에는 보안기능이 없음

=> HMAC(Hash Message Authentication Code)

: 공유키를 넣어 Hash, MD5, SHA-1

3. DH(Diffie-Hellman) 알고리즘

: 보안이 안된 통신 채널을 통하는데도 결과적으로 둘만 알고있는 비밀 공유키를 생성하는 신기한 알고리즘

: 인터넷을 공유하는 떨어진 두 호스트 사이에, 같은 Hash key값을 가질 수 있을까? Shared Key!

4. Split Tuneling

- 말 그대로 터널 나누기

- 내부망 이외의 목적지로 접속 시 VPN Head-end를 통하지 않고 직접 통신을 허용 함

5. IKE/IPSec

- IPSec 

- IKE는 두 단계로 구성

: 데이터를 암호화 통신을 하기위해 통신을 해야하는데, 그 데이터(IKE Phase 1)도 암호화 하고 싶을때, 

 이 암호화단계를 위해 주고받는 또하나의 데이터 사용하는 방식(IKE Phase 2)

(1) IKE Phase1 : IKE Phase 2를 준비하는 단계, 상대방을 검증하는 작업을 수행, 

(2) IKE Phase 2 :  상대방을 검증하는 작업을 수행하지 않음

- Tunnel == SA (Security Assosation), 양 끝의 호스트들이 각각 SA를 생성

<염두해야 할 것?>

- 넌 누구니? 

- key는?

- 어떻게 할까?(SA)

 (2-1) IKE Main Mode

 -------phase 1 작업 시작-----------

  a. 어떻게 할까? Transform Set, 어떤 암호화 방식을 쓸까? 어떤 해쉬방식을 쓸까?

  b. key는 어떻게 할까? DH사용

  c. 넌 누구니? 실제 암호화!

 -------phase 1 작업 끝, phase 작업 2t 시작-------------

  d. phase 1 작업이 끝나면 터널이 생성됨. phase1 tunnel == IKE tunnel 

  e. 넌 누구니? phase1에서 했으므로 여기선 안해도됨

  f. key는? 사용자에 선택에 따라, 할수도 있고, 

      (PFS(Perfect forward security) : phase 1과 2에서 다른 keyr값을 사용하는 방식)

   PFS는 default로 켜져있기때문에 phase2에서는 보통 Key교환이 새로 이루어 짐

  g. How? IPSec은 어떻게해서 데이터를 전송할까?

  h. 이때 생기는 터널이 IPSec 터널

 -------phase 2 작업끝------------------------------------

  (2-2) Aggressive

  - 넌 누구니, key는, 어떻게 할까를 하나로 때려박아용 (기존에 key부분을 노출시키지 않던 방식에서 해당 부분은 한번에 묶어서 노출함)

- 실제 추가적인 사용자 인증이나 IP 할당은? IKE Extensions기능을 사용

  a. Extened Authentication (Xauth) - 사용자인증

  b. Mode Config - IP 자동할당

  c. Dead Peer Detection(DPD) - 상대방의 생사여부를 확인

- IKE Extention은 IKE phase 1.5에 해당 

#  SSL VPN ?

- 넷스케이프에서 개발한 보안 통신 프로토콜

- 웹서버와 브라우저 간에 보안 터널생성

- 인증 암호화 무결성 지원

- 대부분의 브라우저 및 SSL VPN 클라이언트에서 구현

- 포트 443을 통해 Https:// 통신 (TCP 443)

1. 구현방법

- Clientless : 클라이언트 없이

- Thin Client : 클라이언트를 쪼~끄만걸 빠는 방식 (쪼그만 클라우드)

- Client-Based : Full 클라이언트를 방식(뭐든 다 써야할때..)

2. 고려사항

- 접속 전 : 레지스트리검사, 파일유무 검사, OS 버전 검사

- 접속 후 : Cookie, URL 히스토리, Cache, 다운로드 파일은?

.. 가상키보드,,,VDI 등 제공...

# Remote-Access VPN 디자인 가이드 

:  인입장비(방화벽, VPN)를 가지고 제어

- 과거 : FW, VPN을 수평적으로 배치하여 서로의 단점이 발생

- 개선된 디자인 : VPN, 방화벽 역할 분리, IPSec, SSL을 분리하여 운영

- 최근 추세 :  목표가 하나이므로 VPN, IPSec, SSL을 하나로 통합

# 유클리디안 거리점수

: 그럼  제곱 제곱 제곱이 되는뎅.....

 말이 안되는 알고리즘인뎅...? 2^ ==> 제곱으로 속도가 떨어지는거지???? 

... 유사도 계산 시 나타낼  수 있는 범위를 0~1로 잡고(정규화), 실수로 표현한다.

하.. 이게 왜. 효육적이지? 실수로 가면 속도가..........................................

제곱은 알고리즘에서..for로 처리하니깐.. ~~~

# 피어슨 상관점수

: 1, 0, -1

- 0이라는 기준을 잡는 조건은?

- 평균? 상관계수? 

- 전체적인 상관관계를 나타낼 수 있찌만 두 객체간의 유사도는 측정할 수가 없다는 단점이 있다.

- 궂이 이 이론을 사용하는 이유는 ? 두 객체간 상관관계의 판별로만 사용한다. 

# 유사도 계산을 할때는 

 1. 피어슨이 1위

 2. 유클리디안이 2위

 3. 3위는 기타 많은 것들이 있당...?

# 예를들어

 1 : 객체간의 양의 상관관계가 나오면 함께 파는게 낫다.

 0 : 객체간에 0의 상관관계가 나오면 

 -1: 객체간의 -1의 상관관계가 나오면 함께팔지않는게 낫다.

OpenStack 소스레벨 접근하기

[inatall script]

[API 사용하기]

# dev Doc

# SDK

- jcloud : 클라우드 관련하여 거의 모든 소스를 커버하고있음

  > github에 올라간 잘 짜여진 예제 소스들 참고하자!

- pkgcloud 

[contribute]

- openstack.org에서 회원으로 가입 한 후 개발자커뮤니티와 연동하여 개발

- 슬쉐에 공유된 부대표님 ppt보고 해보자

[writings]

- 개발자가 알아야할 가상화 정보를 많이... 가이드? 해주고있다..

-----------------------------------------------------------------------------------------

1. keystone

 $ keystone user-list

=>임베디드 어쩌고저쩌고?

* 웹에서 쓰레드가 필요한 이유...? 웹서비스들을 스레드로 돌려야 가벼움(자원을 공유하므로)

* admin_workers / public_workers를 구분하여 

server로 ㄱㄱ

root@ubjuno-contnet:~# vi /usr/lib/python2.7/dist-packages/keystone/openstack/common/service.py

# 가상화 + OpenStack + SDN 

#OpenStack?

- 클라우드 Infrastructure를 setup, run을 잘 할수있도록 관리하는 플랫폼

- not Hypervisor

- management Hypervisor

- 클라우드 운영체제

# 서버가상화와 네트워크 가상화 & OpenStack

- nova : 서버가상화, Infrastructure를 관리하기 위함

- neutron : 자연스럽게 네트워크 가상화를 지원하기 위해 quamtum이라는 이름으로 하나의 프로젝트로 제안이되어 공식적으로 릴리즈됨

- 오케스트레이션(heat), 미터링(씰로미터)

- 서버관점? 네트워크 관점? 두 부분으로 나눠져서 생각할 수 있겠다.....

#OVS plugin

- OpenFlow를 준수하는 vSwitch

# SDN

- 기존에는 MDM쪽으로 많은 연구가 이루어졌었다.

- 프로토콜 계층에서 IP layer가 가장 많은 바틀넥이 발생한다. (모든것이 IP 기반으로 동작하기 떄문..)

- SDN에서는 프로그래머블하도록 지원하며 네트웍에대해 원하는대로 지원할 수 있도록 함

- SDN에서는 중앙에서 네트웍변화에 대한 기록을 관리

- Controll layer

# OpenStack과 SDN

- OpenStack의 서버가상화(nova)나 네트워크가상화(neutron) 환경에서 플러그인 형태로 SDN 컨트롤러들이 연동이 가능

- OpenFlow 프로토콜을 통해서 통신

- 컨트롤러에서 네트웍을 중앙관리함

- 즉 완벽한 독립적으로 개발과 관리가 가능하며, 네트웍의 중앙관리화로 네트웍 통제를 효율적으로 가능

- 컴퓨팅 자원을 관리한다, 네트웍전체를 관리한다가 아닌 네트웍을 관리할때 중앙에서 사람의 두뇌처럼 관리를 할 수 있도록 실현하는게 SDN

- 왜 두뇌를 줘야하지?

: 오케스트레이션을 지원, 중앙화된 네트워크 관리가 쉽게 이루어 질 수 있음

# SDN + DPI (security)

- 보안장비 짱비싸..

- 모든 트래픽이 보안장비를 거쳐가 보안을 강화할 수 있음.

- 엣지 단의 VM들이 보안을 위해서 멀리~ 거쳐야 함.... 

- 분산화된 환경에서 DPI를 배포를 할 수있으면 좋지않을까?

  : 원할 떄 분산화된 DPI의 확장/축소가 가능

  : 오토스케일링이 가능

  : 자원을 나누어 효율적으로 사용할 수 있고

  : 트래픽을 서비스체이닝해서 효율적으로 사용할 수 있음

- DPI를 잘 관리하면 좋지않을까?

- DPI를 SDN으로 관리하자

(참고 http://www.turby.net/42)

모니터링

1. CPU

2. Memory

3. Disk I/O

4. Network

# top

: CPU 점유 프로세스들을 실시간으로 조회

(1) 첫번쨰 줄 : 시스템의 전반적 상태. 가동시간, 평균사용량 등

(2) 두번째 줄 : 프로세스들의 상황

(3) 세번째 줄 : CPU 상황

(4) 네번째 줄 : Memory 상황

(5) 다섯번째 줄 : swap 메모리 상황

(6) ~ : 

: 옵션

# htop

: top보다 사용자 위주의 모니터링 도구

$ apt-get -y install htop

$ htop

# vmstat 

: 시스템 작업, 하드웨어 및 시스템 정보. 시스템의 리소스 상황(cpu, I/O, memory) 모니터링

$ vmstat

$ vmstat 3 

$ vmstat 3 2

$ vmstat -m

$ vmstat -a

# iostat

: 평균 CPU 부하 및 디스크 활동

$ apt-get install -y sysstat

$ iostat

# free

# w -

: 시스템에 로그인한 사용자와 프로세스 출력

# ps

# 테스트 항목

1. Windows 7 professional 64bit

2. WIndows Server 2012 

3. Ubuntu 12.04 Cloud용 

4. Centos 

# 테스트 목적

1. 실제 클라우드 리소스가 어느정도로 퍼포먼스를 내는지 확인하기 위함..

# 차후 목표

1. 그냥 간단히 막쓰는 private cloud를 제공하는 서버를 만들고

2. HA나 Proxy, DB, Web서버 구축

3. 아두이노 센서 데이터를 받아서 분석....

# 사전에..

> 리눅스에서 자원사용 확인하기 http://jiming.tistory.com/admin/entry/post/?id=63

# 기존의 3-tier구조에서 ---> 2-tier ---> 1-tier

  : 1-tier 구조로 모든 port가 서로 연결되는 형태

  : flat한 네트워크, 패트릭, fast switching, 단순화가 지향됨

# 벤더들이 내놓는 기술

: 디바이스 풀링 가상화 - 두대의 장비를 하나의 장비처럼 이야기함

Cisco VSS(Virtual Switching System, 여러대의 코어 스위치를 한대처럼 사용. 코어 스위치 이중화)

Cisco vPC(Virtual Port Channel, 가상 포트 채널 기존 스위치의 STP Block포트를 제거하여 스위치 완전 이중화가 가능)

Juniper VC(Virtual Chassis, 스위치를 상호연결하여 하나의 장비처럼 쓰게해줌)

HP IRF(Intelligent Resilient Fablic,하나의 논리적 장비로 여러 스위치를 관리)

 STP를 사용하지 않아도, 디바이스들을 폴링하여 굉장히 빠른 스위칭이가능. 

(http://blog.daum.net/sunwookim77/105)

datacenter가 굉장히 동적으로 변해지고 있고, 성능도 2배이상 되어지고 있지만 이게 끝이 아님!

# network virtualization

: not vm기술, not overlay

- 오버레이 : 인프라스트럭쳐를 거쳐가지 못하게되니까 태깅을 달아서 L2 of L3라고하는 것일 뿐, 진정한네트워크가상화가 아님

- 진정한 네트워크 가상화란, 어떤 기술이던 상관없이 기존의 물리적 인프라를 전혀 건드리지 않는 상태에서 원하는 시점에 새로운 서비스들을 구현할 수 있어야 하고 동적인 환경이 제공되어야 한다. 

다시말하면,

- 기존의 네트워크 가상화는, 물리적 인프라스트럭처가 있는 그대로 있는 상태에서 하이퍼바이저 내부에 소프트웨어가 네트워크 오버레이를 통해 네트워크를 생성한다는 개념

- 진정한 의미의 가상화는, 물리적 자원이 되었건, 하이퍼바이저안의 자원이 되었건 하나의 독립된 vm으로 생성되어 동작하여야 한다.

# 현재의 DataCenter Network 구조

: 2-tier구조로 넘어가는 중이고 다음과 같은 그림으로 표현된다고 했을때, 

하이퍼바이저의 vm들이 다른 네트웍을 가진다면, L3단까지 넘어갔다가 내려와야 함. 

East-West트래픽이 쭉 깔리고 많은 트래픽이 발생되고.. (broadcast/multicast) 

: 이런 상황에서는 vMotion을 시켰어도 어느곳으로 정확히 보내야하는지도 모르게 됨

=> 가상라우터가 이슈가 되고있음 (ex. Vyatta)

: vm들은 서로 다른 서브넷을 가지고있는 장비를 넘어 바깥으로 나갔다가 들어오는 것이아니고, 가상 라우터를 통하여 내부에서 그냥 통신이 가능

# vMotion을 한, 아니면 여러이유로 다른 호스트(다른 하이퍼바이저)에 생성되어있는 vm들은 어떻게 통신하지?

1. 가상라우터 설치

2. 디폴트 게이트웨이를 가져가기 위해 VRRP 구현

3. VM들을 vMotion해서 옆으로 옮김

* VRRP(Virtual Router Redundancy Protocal) - LAN에서 백업 라우터 장애 복구 프로토콜

4. 네트웍을 타고 디폴트 게이트웨이를 거쳐서 다시 다른 서브넷으로 넘어가는 구조... 즉 스파게티 네트웍이 구현되는 기술..

5. 결국 스파게티 네트워크를 없애기 위해 vRouter를 쓰지 않으면, 결국 다시 원점..?

6. 벤더들에게 문의함. 하지만 벤더들에게서는 어떠한 해결방안도 찾지 못함.

=> 진정한 해결방안은?!

# SDN을 통한 가상네트워크 구현

: SDN Controller를 통해 Routing이 이루어진다면?!!!!!!!!!

- ip fabric은, ip fabrics안에서 SDN이나 openflow를 구현하거나,

- overlay기술을 통해 넘기거나, 

- physical network virtualization 시킨형태로 가고 트래픽을 스스로 제어를 할 수 있는 형태로 하여, 

- 바로바로 즉시적으로 어디로 보내야하는지 컨트롤로가 알기때문에 넘기는 기술들이 구현

# SDN/Network Virtualization 영역에서는

- SDN Controller가 호스트들과 VM 등의 모든 위치를 알고 있음. 

- SDN 컨트롤러가 gateway정보를 가지고서 그자리에서 맥어드레스 변환을 하여 최적의 경로를 바로바로 찍어준다. 

- 라우팅모듈이 어떻게 짜여지던지 상관없이, 내가 원하는 위치에 가상네트웍을 생성하고 그위치에 맞게끔 계속해서 트래픽을 보낼 수 있음

- 결국 컨트롤러에 의해 모든것들이 제어됨

- SDN은 네트웍의 가상화와 지능화를 위해 사용하는 기반 기술. 독단적인 기술은 절대 아님

- 벤더들이 제시하는 많은 기능들은 네트웍을 오히려 지저분하게하고 제약사항이 많다. 

- firewall... 을 포함하여 가장 많은 기술의 가상화를 지원

- NSX - Hypervisow안에서 바로 다이렉트로 넘기게끔 하는 기술

- 누아지 

# vSwitch 

: 단순히 ovs, one K등을 쓰면되지... 라고 생각하면 안됨, 왜??

: vSwitch기술은 벤더들에서 가상 획득하려는 기술이다. 

: Software Defied Network, Network Virtualization은 중앙에서의 컨트롤러들이 모든 host들의 위치를 정확히 안다는 전제하에 기술들이 이뤄짐.

- 인스턴스나 vm들이 이동을 하는 경우나 새로운 ip address로 변경이 되거나 하는 상황에는 위치를 정확히 알 수 없기때문에 지금 나와있는 기술들로는 정확한 위치에 detection할수가 없다.

- 그래서 현재 나오고있는 기술들에서는 vSwitch를 통해서 즉각적인 변화에 대한 정보를 얻게됨.( vSwitch가 이런 정보를 Controller에게 바로바로 줌)

=> 암튼 vSwitch는 굉장히 중요함

# 주요 벤더의 접근 전략

- VMWare - NSX : 터널링 기술을 이용 

- 각각의 호스트들과 안에있는 vm의 위치를 실시간으로 컨트롤러가 주고받음

- ovs에서 그 정보들을 extention 기능들로 계속 뽑아내서 사용, 여기에 overlay기술을 태워서 넘기게됨

- overlay기술을 사용하는 이유, 즉 vxLan을 사용하는 가장 큰 이유는 physical 스위치를 건들지 않기 위해서임

  (physical switch를 건들게되면 기존에 있던 인프라스트럭쳐 망을 다 건드려야 하므로 부담이 됨)

  (실제로 VMware에 Nicira가 인수되기 전에는, physical switch를 개발하는 로드맵이 있었음, 인수 후에 그 전략을 폐기를 하고 

  하드웨어 vTech 기술이라고 하여, 아리스타나 HP나 브로케이드와 함께 alliance 형태로 가고,

  여기서 vxlan을 하드웨어로 구현하는 NSX파트너쉽으로 개발하면서 하드웨어적인 물리적 자원을 건드리지 않는 형태로 진행됨)

1. VMware & Nicira 

- Nicira : DN을 가장먼저 이야기했던곳, OVS를 만든곳, OpenFlow의 총 기술들을 가지고있는 곳

- but Not SDN, software defined nothing

- 현재, 하드웨어 벤더들이 SDN을 한다면서 지능적으로 네트웍망을 구현하는 거에 초점을 두지 않고, 모니터링 기술들로 발전시키고 있다.

network virtualization은 시장적으로 차별화를 두기위해 했던 말일 뿐이다.

- NSX기술을 보면 실제로 물리적 자원들을 건들지 않고 하이퍼바이저안의 스위치와 자원을 가지고 중앙의 컨트롤러가 vm들의 위치를 디텍션하여 

그걸 쉽게 네트웍을 구현할 수 있게 함

2. CISCO

1. fabric path기술을 이용한 DFA

: 중앙에 컨트롤러 없음. 각 호스트나 클라이언트는 멀티캐스트나 브로드캐스트를 통해서 위치를 디텍션

2. ACI

: fabric path와 똑같지만 중앙의 컨트롤러가 이 모든것을 제어

: 시스코 왈 : 우리는 SDN이 아니라 HDN이다~~ > Hardware Defined Networking

: 근데 위의 NSX와 ACI기술을 보면 똑같음

: vxlan사용, 하드웨어 장비들이 network virtualizaion을 시키기 위해 기반요소들을 제공한다

# 결론

- SDN이니 HDN이니 이런 이야기들은 마켓팅적 용어로 이해하는게 좋다. 즉, network 가상화가 시장에서 핫한 이유는 마켓팅적인 느낌이 강하다.

- 이 기반요소들은 그냥 인프라스트럭쳐가 깔려있는 상태에서 내 네트웍을 얼마나 최적화시키고, 중앙에 가상화를 시킬수 있느냐에 초점을 맞추고 있는데, 벤더들은 서로의 경쟁심리를 이용하여 교묘하게 꼬고있는 것 같은 느낌이 강하다.

# 현재 시장에서는?

- 궁극적으로 현재 시장에서는 overlay기술이 사용해질 수 밖에 없고, 현재 오버레이 기술과 내 내트웍을 어떻게 잘 구현할건지 고민해야하고

자원간의 로드맵을 생각 해야 할 것이다.

by 나임네트웍스 팀장님..