지밍이 블로그

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으로 관리하자

# 테스트 항목

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 나임네트웍스 팀장님..

Riverbed Performance Platform

Steel Central

Steel App

Steel Head

Steel Fusion

Steel Store

[SteelCentral]

# 전형적인 IT팀의 딜레마... 공통된 툴이 필요

- 네트워크 팀 : 패킷단만 신경써

- 시스템or어플리케이션 팀 - WAS랑 CPU만 모니터링하고...

# 리버베드 SteelCentral

: 유일하게 NPM과 APM을 포괄적으로 모니터링이 가능

- network perfomence monitering : 양적인 부분을 모니터링 해줌. 얼마나 많은 양을 전송했는지

  패킷 캡처, 프로토콜 분석, net Flow 리포팅

- APM 영역은 성능데이터, 실제 피부로 느끼는 시간, 서버에서 걸린 시간, 랜더링하는데 걸리는 시간이 얼만지,DB 작업에 걸린 시간이 얼만지(엔드유저에대한 응답시간에대한 모니터링, 어플리캐이션 컴포넌트에 대한 보다 디테일한 모니터링, 트랜잭션/트레이싱

- 웹어플리케이션을 서비스하는데 connect 했던 url별로 모두 확인이 다 가능

: 어떤 웹 어플리케이션, 어떤 url에서 시간이 오래 걸렸는지에 분석이 가능해

# SteelCentral은 

즉, 성능관리 솔루션! NPM, APM을 둘다 지원

물리적인 환경, 가상화 클라우드 모두 가능

하드웨어 어플라이언스형태및 소프트웨어 형태 둘다 제공

IT 플래닝을 위한 근거자료도 가능

-> Data Center에서 어느 시스템을 줄이고 가상으로 해야하는건지, 어느 부분을 개선해야하는 지 파악하는데 도움을 줌

-> VDI, voice of iP 품질에 대해서도 적용할 수 있음

(대기업의 경우 화상회의도 많이하고, 특히 크리티컬한 경우는 임원들이 하는 화상회의 및 통화에대한 품질을 개선)

-> 자동학습을 통한 성능 감지 및 분석

: 알람. 대부분의 벤더들은 아직까지 매뉴얼하게 설정을 함. 

가령 응답시간의 경우 매일 다른데, 매뉴얼의 설정은 당연히 한계가 있음. 이런 판단을 기계가 알아서 해준다면?!

: 만약 그룹웨어라고하면 약 2주정도 분석을 하고.. 2주동안의 데이터를 집계하고 통계하여 표준편차를 적용해 자동으로 알람을 해줌

# 어플리케이션 성능 모니터링 및 구간분석

1. 응답시간 구간별 지연 분석이 굉장히 디테일

-> 서버응답시간, 세션연결시간, 실제 데이터 ㅈㄴ송시간, 재전송지연시간 등 다 포함해서 사용자가 느끼는 응답시간을 굉장히 디테일하게..

2. 데쉬보드

-> 데쉬보드 SW를 무료로 제공... 

- 각 팀에서 항상 띄워놓고 보고싶은 리포팅 화면이 각각 다른데, 이부분에 대해서 템플릿을 제공한다. 

-> SLA가 만족스러운지, 잘 딜리버리 되고있는지 (관리자측면)

-> 실제 실무자 측면

# RPM - reverbed perfomance monitering/management

(고객의 피드백에 의한..)

RPM도입의 가장 큰 효과

1. 빠른 문제 해결 85%

2. it조직간 소통향상

3. 리소스 효율적 조정

4. 조직의 생산성향상

5. 최종사용자의 성능향상

6. SLA 준수향상

다양한 부분에서 고객이 마족하고 피드백하고 있음

# IPTR 장애처리시간

[Steel App]

- ADC

- Virtual Application Data Flows are changing ADC Requirements

- 영국의 회사를 인수. 결국 가상화/클라우드를 따라 SW기반으로 가자!고 판단함

- Today's Architecture - location independent, 즉 SW !!

- Virtual ADC란?

: L2, L3 Switching and Routing - 네트워크 가상화 시작(SDN), Application 가상화 사이의 Application Delivery Layer(Service-Tier도 가상화가 필요)

: vm에다가 바로 올려서 서비스가 가능

: 통합제품. 가상화 기반의 l4/l7 로드발란싱 지원

물리적인 서버(리눅스)에서 어플라이언스형태 가능

가상화 형태로 vm에 올라가서 서비스 가능

# 라이센스정책

: 서비스 컨트롤러 SW 무상제공 - 인벤토리 관리(설치되는 steelapp관리), 빌링, 프로비저닝, 라이센스 관리 등 전반적인 관리

엔터프라이즈 고객을 위함

1. 셀프서비스 : 50G짜리 라이센스를 사면 서비스 컨트롤러 SW를 통해서 서비스별로 쪼개서 사용

  가령 ERP는 한 5G,그룹웨어는 한 10G. 남는건 가지고 있다가 다른 서비스에도 쓸 수 있고.. 기존에 할당한 부분도 남으면 회수애허 나중에 쓸수있게

2. managed 서비스 - 이 서비스들을 서비스 프로바이더 형태로 제공

# SteelApp ADCaaS

: 아마존, 랙스페이스 같이 클라우드 프로바이더들이 ADCaaS를 제공하는데, 이때 SteelApp제품을 많이 사용해 서비스하고있다.

- 글로벌 로드밸런싱

- 웹방화벽

- 웹가속

...

- Content Delivery Cloud(CDC)

: CDN서비스를 클라우드 프로바이더들이 함. 조이언트 같은 경우 해당 제품을 가지고 서비스가 되어지는 경우도 있음

- AutoScailing기능 포함

: 서버 상태를 모니터링 하다가 부하가 많이 걸리면 자동으로 이중화 서버를 올릴 수 있는 기능

: 인스턴스를 자동으로 생성 후 자동으로 로드밸런싱 pool에 등록하게 해줌

[Steel Head]

# Wan 가속기 이슈사항

- 딜레이에따른 애플리케이션 성능 저하 (거리이슈!!)

- 애플리케이션 레벨의  chatty에 의한 성능저하

- WAN 병목에 따른 애플리케이션 성능 저하(거의 드뭄)

아무리 밴드위스가 넓어도 결국 딜레이(거리)에 성능 저하가 발생하고

어플리케이션의 복잡도에 따라서도 성능저하가 발생한다.

(특히 MS의 앱들을 복잡하고 무거워서 성능저하가 더 많이 발생)

# Steel Head WAN 가속기

- 어플리케이션 가속

- 트래픽 절감

- 사용자 입장에서는 생산성 향상

- 회사 입장에서는 회산의 절감효과

- 모든 TCP기반의 어플리캐이션과 와 일부 UDP부분에서 빠른 속도를 지원 최대 100배(200배도 봄)

- 트래픽 절감율이 최대 98%

- 모든 기업들이 중복률이 많은데 이 중복트래픽을 제거해주면 엄청나게 빨리지게 됨

- QoS도 지원(Voice of IP나, 화상트래픽을 우선적으로 처리)

- MS application 가속 성능

- 스틸헤드는 모든곳에 적용이 가능하다?

: 본사와 지사 어플라이언스 타입

이동근무자들은 모바일 sw형태

나머지 클라우드 프로바이더들은 진짜 사용자 관점에서 빨라지는지 확인해야함

# 아카마이 & SaaS

[Steel Fusion]

# IT인프라의 Challenges

- 지점 요구사항 - 데이터와 어플리케이션에대한 빠른 성능을 요구

- IT입장에서는? 지점에 서버와 스토리지를 가져다 놓으면.... 관리 너무 힘들어 ㅠㅠ

-> 스틸퓨전의 존재이유

# SteelFusion - Branch Converged Infrastructure를 만들어주는제품

: 별도의 백업 솔루션 없이도 산재된 중요한 지점 데이터를 데이터센터로 통합(어싱크백업기능)

: 지점 사용자에게는 로컬 성능을 보장

: 지점 인프라를 통합 - 가속기 모델에 VM을 올리고 기존의 어플리케이션과 스토리지를 통합할 수 있음

(지점의 인프라를 좀 심플하게 만들자!)

# Steelhead EX : WAN Optimization + Computing on VM + Storage(자체 백업기능을 가지고있는 스토리지임)

(가속기능만 탑재된 버전은 CX)

# use cae

- 스토리지read/wirte이 많많은 어플들. CAD, SQL, Document Scan File(금융) GIS, VDI, 금융, ...

- 가장 큰 이슈? VDI에서 마우스 포인터가 움직이는데 2초..걸리고...

# 브랜치 통합의 동작원리

- 데이터센터에 vmware환경을 통해 지점과 지사에 필요한 데이터와 어플리케이션을 다 만들어 놓는다. (미리 인스턴트를 다 만들어놓기)

- 지점 단에 스틸퓨전이 들어가게 되면, vmware를 통해서 프로비저닝 시킴(데이터가 되었건, 어플리케이션이 되엇건) 

- 지점단에서 바로 부팅해서 사용

- 모든 저장된 데이터들은 스토리지에서 센터로 자동 백업됨(변경이 있을때마다 바로바로)

- 장애가 나서 새로운 백업장비가 들어오면 센터에서바로 다시 프로비저닝 해줌

=> IT담당자가 없어도 바로 백업

=> 리커버리 타임도 짧아짐

[Steel Store]

# 클라우드 백업의 장단점

- 백업을 로컬로 했다가, 예를들어 AWS와 계약을 해서 모든 백업데이터가 클라우드로 저장됨

- 문제는 퍼포먼스...!

- 데이터의 보호

- 프로세스의 변화 : 클라우드 프로바이더들이 제공하는 storage는 API통신. 기존읜 nfs등... 그 환경이 변화되는 것이야.....

- 비용은 절감되나 ,여러가지 불편한 사항이 많이 발생하게 된

=> Steel Store의 탄생 배경

# Steel Store ? 클라우드 백업 가속기

: 기존의 백업/아카이빙 구성변경 없이 적용

: 고객사의 백업서버단에 설치

: 회산도 별도의 전용회선 필요없이 일반 인터넷 회선 사용

: 최대 80%의 비용 절감이 가능

# 아키텍처

- Data Center... 백업서버, 스틸스토어쪽에선 기존의 환경과 같이 nfs같은 방식 사용

- 클라우드 프로바이더족과 통신은  API로 통신

- 스틸스토어의 역할은 중복제거, 압축, 암호화등 가속기 기능을 수행

 : 트래픽이 작아짐. 즉 아마존에 내는 비용도 줄어듬, 백업이나 복구에 로컬만큼은 아니지만 훨씬 빠르게 됨

 : 죽복제거률이 최대 30배 (즉 아마존에 30만큼의 비용을 내다가 1만큼의 비용만 내면 됨)

# 여러 백업벤더들과 호환 됨

# Private 용(OpensTack,,) , Public 용 (AWS..)

-> 반드시 API통신이되어야 함

# 고객 레퍼런스

- 24000 정도의 기업

- 글로벌기업의 96%정도가 미국에서 사용 중

# 정리!

- 어디든 사용이 가능한 Riverbed Performance Platform

- 5개의 제품을 통해 성능관리 및 진단과 성능 개선을 실현

- WAN Optimization 마켓 리더

- NPM + APM 마켓리더

- vADC 비저너리(virtual부분에서만 보면 마켓리더로 되어있음)

참고사이트 :
1. Openstack Document
http://docs.openstack.org/image-guide/content/windows-image.html
2. 위 문서대로 진행한 한국블로그
http://heavenkong.blogspot.kr/2014/04/create-windows7-virtual-machine-image.html
2. cloudbase init & windows7 & openstack
http://cloud-ninja.org/2014/05/14/running-windows-7-guests-on-openstack-icehouse/
3. cloud-init for Windows instances (www.cloudbase.it)
http://www.cloudbase.it/cloud-init-for-windows-instances/

[출처] http://heavenkong.blogspot.kr/2014/04/create-windows7-virtual-machine-image.html

Create Windows7 Virtual Machine Image for OpenStack

Reference:
http://docs.openstack.org/image-guide/content/

1.  virt-manager 
2.  VirtIO driver
3.  Sysprep
4.  Cloudbase.init 

Requirements: 

windows7 iso file: 
http://www.w7forums.com/threads/official-windows-7-sp1-iso-image-downloads.12325/
select version by language ~
virtIO iso file:
http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/
select iso file to download ~
cloudbase.init fle: 
http://www.cloudbase.it/cloud-init-for-windows-instances/
Here select https://www.cloudbase.it/downloads/CloudbaseInitSetup_Beta.msi file to download ~

1. Using virt-manager
yum install libvirt
yum install qemu-kvm
yum install virt-manager

service libvirtd start
virt-manager

New VM -> Name: vm_windows& -> Choose "Local install media(ISO image or CDROM)"

Use ISI image:

/root/openstack-images/X17-24329.iso

OS type:

Windows 7 

Memory 2048MB
CPUs 2

Select managed or other existing storage ( This is for adding virtual CD of installing VirtIO Driver)
New volume Name: vm_windows7.img
Format: qcow2
Max Capacity: 20000MB(20GB)
Allocation: 20000MB(20GB)

Forward
click customize configuration before install (This is for adding new hardware)
Finish
Add Hardware

select managed or other existing storage
Browse: /root/openstack-images/virtio-win-0.1-74.iso
Device type: IDE cdrom

Click Begin Installation

Click Next ~
2. Load driver as shown below ~

Begin to install ~

Restart ~
User: kisti
PW: ****
It will be shown as follow~

3. sysprep Run
In windows7, there is a tool called sysprep for use as a virtual machine image.
C:\Windows\System32\sysprep
execute sysprep.exe file
Click General (일반화)
OK(it needs to restart the windows7)

4. Install cloudbase.init

Install cloudbase.init

5. Other settings
Ethernet 컨트롤러 driver install
computer right click -> 관리-> 장치 관리자

load VirtIO driver and update ~ After updated as shown bellow~

shutdown Windows ~
6. Get image file
In the default directory /var/lib/libvirt/images, will find vm_windows7.img file ~
Run this command, virsh undefine vm_windows7

then you can use this image file to create virtual machine with windows7 in openstack ~

하다 보면 생성된 이미지가 블루 스크린(blue screen)이 뜨면서 설치 오류가 나는걸 볼수 있는데 해결 방법은 guest windows7에 microsoft .Net framework를 설치하면 된다. 

따로 설치할 필요없이 윈도우 오피스를 깔면 포함되어 설치가 된다. 

[출처]http://heavenkong.blogspot.kr/2014/04/create-windows7-virtual-machine-image.html


<www.cloudbase.it  서비스들>
- OpenStack Compute Installer
- Cloud-Init for WIndows instances
- Neutron Hyper-V plugins
- OpenStack Cinder-Volume on Windows Storage Server 2012
- OpenStack Windows Server 2012 R2 Evaluation
- OVS on Hyper-V
등등 많음

[OpenStack 정기세미나]

일시 : 2015.01.15 (목) 19:00~21:30
장소 : 토즈 강남2호점
내용 :
  Session 1. 다른 시각으로 본 SDN - 포티넷 코리아 이상훈님
  Session 2. 개발자분들을 대상으로 네트워크 엔지니어가 바라보는 오픈스택 네트워킹
                     - KrDAG 서종호님
  Session 3. OpenStack 네트워크와 SDN - KrDAG 최영락님



< Session 1. 다른 시각으로 본 SDN >

#1. SDN 삼국지
a. IBM, HP등의 회사들이 End-to-End로 IT를 점령하던 시기에서
b. IT 산업혁명을 거치며 소품종 대량생산 체계로 전환
    - OS-HW 분리
    - 전문 Chipset 회사
    - 분야별 SW 분리
e. 네트워크 업계에선 Cisco같은 벤더들이 승승장구
    - 전문 ASIC 자체 개발
    - 전용 network OS를 만들어 제품에 탑제
    - 전용 Protocol 개발
f. 이렇게 30년... 다품종 소량생산 체계로 전환
g.  더이상 네트워크 업계에서는 돈이 안되기 시작
h. 네트워크 벤더들이 서버쪽으로 접근하기 시작(예로 Cisco가 스토리지와 서버를 만듬)
i. SOA + 사용자(SNS)를 기반으로 SDN 등장
    - Cisco.. 무겁고 비싸고 Cisco가 배신해서 횡포라도 부리는 날엔..? OTL
      => SDN의 개념이 대두

#2. SDN의 개념
    - 실체의 갭
    - 바라보는 시작의 차이 (SDN은 네트워크계의 SOA ??)

#3. 각자의 시점
a. ISP 입장에서의 SDN
    - 관리의 자동화
    - 리소스 최적화
    - NFV와의 연계
b. 클라우드 사업자 입장
    - Multi Tenant (기존과는 비교할 수 없이 굉장이 많은 숫자의 테넌트를 나눌 수 있게 됨)
    - VPC (아마존서비스)
c. 그외
    - 범용 Chip 기반
    - 활성화
    - 자동화
    - 네트워크를 벗어난 비지니스와의 연계


< Session 2. 개발자분들을 대상으로 네트워크 엔지니어가 바라보는 오픈스택 네트워킹 >
#1. 네트워크 기본지식
a. IP
b. NAT
    - 1:1 NAT : DNAT
    - 1:N NAT : SNAT
c. VLAN
    - 같은 물리네크워크 환경에서 여러개의 가상 네트워크로 분리
d. 802. 1Q Trunk
    : 서로다른 VLAN 패킷을 태그를 달아서 패킷을 구분하기위해 사용
e. 단말 IP 할당
    - 수동
    - 자동 : DSCP, Dnsmasq(nova에서 DHCP를 위해 실행되는 프로세스)
f. LAN 확장
    - 아무생각없이 LAN 화장시 문제가 발생 할 수 있음
    - 대량의 백그라운드 트래픽 발생(broadcast등)
    - 보안상 문제 발상
g. VXLAN
 : L3환경을 넘어가는 두 네트워크 그룹을 같은 네트워크 환경으로 제공할 수 있게하는 기술

#2. nova network
a. flat : 1개 네트워크만 사용가능. 수동으로 instance ip를 할당
b. flat DHCP : flat에다가 DHCP 가능
c. VLAN : 테넌트간 동일 네트워크 설정이 불가능. 4096개라는 갯수 제약
            : 물리 케이블은 1개이지만 VLAN태그를 사용해 여러개의 테넌트로 나눌 수 있음
    - 내부 다수 VM이 SNAT을 통해 public ip로 변환되어 외부 통신
      (다수 단말이 하나의 공인 IP를 가지고 NAT 수행)
    - 외부에서 내부 VM의 floating ip로 들어올때는 DNAT을 사용해야 함.
d. single host & multi host
    - single host - 장비가 죽거나 부하가 걸리면 ..?
    - multi host - (compute노드 + network 노드), neutron에서의 DVR

#3. Neutron
a. namespace기능
    - over lapping ips 가능 : 테넌트 별 동일 네트워크를 쓸 수 있게 해줌
    - plugin <ml2> : 컴퓨팅 노드간 서비스 할 수 있고, 벤더의 기능을 plug 할 수 있음
b. network node와 compute node간의 네트워크는 VLAN, VXLAN, GRE등의 Host간 데이터를 전송
c. 네트워크 모델
    - provider router with private network
        : 테넌트가 분리되어 있으나 같은 라우터를 공유해 서로 통신이 됨
    - pertenent routers wih privae network
        : 테넌트 별 라우터가 분리되어있음
d. DVR 개념
    - single host
    - multi host : network node를 경유하지 않고 compute node끼리 통신이 가능하게 함
e. plugin
    - NSX
    - midekhura의 midonet
    - Arista + F5
    - Cisco, Juniper

# 4. 서비스
    - LBaaS
    - VPNaaS : vPC on AWS : Cisco CSR1KV
    - FWaaS : 라우터 단에서 제어


< Session 3. OpenStack 네트워크와 SDN  >
#1. nova network
a. Fixed IP
b. Float IP
c. 구성방안
    - Flat (곧 없어질 예정)
    - Flat DHCP
        : 수동으로 IP할당하기 힘드니가 linux의 오픈소스 DHCP서비스인 Dnsmasq 사용
    - VLAN DHCP
        : VLAN tagging을 사용하여 네트워크를 분리
    - VLAN + Flat + Flat DHCP
d. 네트워크 가상화
    - 서버가상화
    - 네트워크 가상화
    - Quathum의 등장 : 2008년 OpenFlow관련 눈물을 읽은 대학 교수들이 Openstack에 적용. Network서비스가 복잡해짐에따라 nova-network만으로 커버가 불가능
    - VLAN은 4096개 네트워크로 나눌 수 있음
       (GRE tunneling)
    - VxLAN
    - 2012년 나사에서 OpenStack이 분리되면서
       네트워크 벤더들이 OpenStack에 들어오기 시작
      (네트워크 시설 이중화를 위한 vendor하드웨어 사용)

#2. SDN 등장
a. 구조
    - app 부분 -> OpenStack 이용
    : Openstack의 OFConfig, OVSDB : NW 장비가 꺼졌냐 커졌냐 등 물리적인 관리를 전담하는 서비스도 OpenStack에 포함
    - Controller + 네트워크 장비 -> SDN
c. Ryu : 파이썬으로 작성된 오픈소스 SDN 컨트롤러
    => 프로그램을 통해 switch기능 구현 가능(로드밸런싱, 방화벽구현 등)

#3. SDN 초기시장에서의 Openstack 변화
a. Quamtum의 상표권 문제로 neutron으로 이름 변경
b. Neutron과 ML2
  : L2를 모듈화시켜서 사용을 유연하게 하고자 함.
  : 벤더 플러그인을 잘 쓰고 싶어서 ML2를 발표한 걸수도 있음.(실제로 cisco가 발표)
  : Ryu plugin -> ML2 with ofagent
c. 기존 neutron은 이중화에 대한 문제를 갖고있음.
d. 이중화를 위해 DVR 등장
    - nova-network, multihost 기능 활용
    - network node HA
    - East-west traffic 관리
e. 분산 라우터가 생기면 트ㅐ픽을 분리할 수 있음

#4. 상용시장에서 요구되는 네트워크 요구사항 (Juno의 DVR과 NFV)
a. juno에서 NFV를 언급하기 시작 - NFV에서 Openstack개념이 필요하게 됨.
b. 네트워크 유연성의 철학이 Openstack에 지속적으로 언급됨.
c. Openstack, 오픈소스




tip1. opendaylight는 잘 사용하지 않음..?
tip2. wireshark 최신버전에서 SDN 패킷 분석이 가능함

1. 인벤토리선택 > 구성 > 스토리지 > 데이터스토어에 마우스 우클릭 > 데이터 브라우저
2. 새폴더 만들어서 복사할 vm폴더의 아래의 3개 파일을 복사해 넣는다.
.vmdk --> 스냅샷 마지막버전 파일
.vmx
,xmxf
3. 복사가 완료되면, 복사된 .vmx파일 우클릭 > 인벤토리에 추가 (생성할 vm이름을 알맞게 수정)
4. 만들어진 vm을 실행
5. "복사함" 선택 후 확인

6. 끝