지밍이 블로그

# 기존의 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부분에서만 보면 마켓리더로 되어있음)

2015. 04. 21 김영욱 에반젤리스트 한국마이크로소프트

[Windows 10 preview]

# 라즈베리2지원

# 1년동안 윈7이상인 경우 무상 업뎃가능(개인용만)

# windows 10

- Operating System보다는 platform!

- One Architecture : 바이너리단의 통합

- multi platform 지원

- 반응형 중시

- 유니버셜 지향

.... 졸았다...

# new API

# new Control

1. map

- 지도를 불러올 수 있음

- 업데이트 됨

2. Relative Panel

- 철저하게 상대좌표로 사용할 수 있음

3. App Services? 

: 두개의 앱이 통신하려면 백그라운드에서 서비스를 호출해서 앱사이를 연결하는 무언가가 생김

클라우드 단이 아닌 윈도 내부적으로 생김 

엔터프라이즈에서 사용할 만한 기능

"Think 'Web Services on device'"

- 시나리오 : 바코드를 스캔한다. 바코드 컨트롤이 데이터를 읽고 백그라운드에서 바코드를 디코딩하는 앱서비스를 만들어 동작하고 앱은 가볍게 동작!

- 엔터프라이즈 시나리오 : ERP솔루션의 경우 하나의 프로그램안에 모든기능이 많아,, 굉장히 무거워. 
        필요한 기능을 하나씩 떼어놓는게 필요. 이 과정중에 중복된 기능들이 많이 생기게됨. 이때 앱서비스로 만들고 앱서비스를 호출하여 사용하도록             구조를 바꾸어 사용한다.

- 앱서비스를 디버깅시에는 프로젝트 속성에서 반드시 해당내용과 관련된 체크박스를 확인해야한다!

# Ap Service Lifetime

: 지속적으로 늘어나는 앱서비스를 관리하기위해 lifetime 개념을 도입

: 평소에는 올라오지 않고 대기모드로 suspend되어있다가, 호출할 때만 올라옴.

   계속안쓰면 terminate됨

# Protocol

: Rest 기반의 웹기반 프로토콜을 사용

# Action Center & Quick actions

: 유니버셜앱이기때문데 어디서나 동일한 방법으로 앱을 사용할 수 있도록 지원

: 액션센터경우, 최장7일 앱당 20개의 notifications.

# XAML Transform3d

: 2d인데 3d처럼 보여준다. UX, UI 적용 가능함

좌표계가 (x,y,z)가 있어서 마치 3d인것처럼 계산한다.

이럴 때, 연산이 굉장히 많이 생기므로 내부적으로 gpu를 사용하도록 되어있다.

depth(z좌표)이용, 6번그림

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

[브라우저]

# 기존의 브라우저에서는 많은 기능들이 들어있었다.

# 스파르탄은 다 빼서 엄청 가볍다.

# 유니버셜 앱. 어느 기기에서든 다 돌아간다. 기존앱에서의 호환성에대한 고민은?

사용자입장이 아닌 개발자입장에서의 스파르탄이 의미?

- 최신브라우저로의 업데이트에 포인트가 맞춰지고, 표준화를 지향한다.

# new feature

# Hosted Web Apps

- 하이브리드웹

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

차주를 더 기대해주세요.

4/29~5/1 www.buildwindows.com에서 라이브이벤트