##### Namespaces, Cgroups and Docker

### 0. System Design

1. Container

- Host provides Kernel

- Filesystem, network interface, etc are already there

- Guests starts from /sbin/init

2. Application Container

- Host provides Kernel

- User data, socket fd, etc are already there

- starts from application not init

### 1. Namespaces

: 하나의 system에서 시스템 자원을 가상화하여 namespace로 구분되는 각각의 독립된 공간을 만들어주는 기술

<linux에서 제공하는 namespaces>

* Linux namespace는 namespaces API를 사용하는데, 

"clone", "setns", "unshare"이라는 system call을 포함하며 flags를 사용하여 각각의 namespace를 구현

(linux man page 참고. http://linux.die.net/man/2/)

1. File System

a. read-only, mount RO /usr inside a container

b. shared - sharing data across containers via binds

c. slave

d. private - /tmp per service

=> docker에서는 aufs를 사용

2. Networking

a. Root namespace

- docker container 내부에 network interface가 172.17.0.1/24로 네트워크가 할당 됨을 확인할 수 있음

$ ifconfig 

eth0    ~

- Full access to the machine interfaces

fast, easy to get setup, Network looks normal to the container 

but, No separation of concerns, Container has full control .......-> MAC addresses

b. Bridging

- docker  외부에는  브릿지 네트워크로 가상 브릿지가 생성됨 

$ ifconfig 

/eth952NTB    ~

$ bridge show

docker0    veth952NTB

- More complex to get setup

- Network looks normal to the container

but, Less speed, NAT to the internet, iptables to expose public socket

c. Private namespace with socket activation

- No inerface 

- Sockets are passed via stdin (inetd)

- systemd style listen fd API

3. Process Namespace    

: PID I is something else outside the namespace

### 3. Cgroups

- Control Groups은 실행 프로세스가 사용하는 block I/O, CPU, memory 등의 자원을 제한하고 감시하고 계산하는 Linux Kernel의 기능

- 실행 프로세스들의 그룹을 만드는 역할을 수행하며 이런 그룹은 hirachy를 가지게 됨

- 시스템의 자원 할당, 우선순위 지정, 거부, 관리, 모니터링 등의 제어 기능을 수행하므로 자원의 효율성을 향상시킴

- 단순 그룹핑을 제공하므로 실제 자원 분배를 위해서는 각 자원마다 해당하는 subsystems가 필요함

: blkio, cpu, cpuacct, cpuset, devices, momory, net_cls, ns(namespace subsystem), ..

1. Block I/O

weighting system

iops serviced, waiting and queued

2. CPU

shares system

cpuacct.stats user and system

3. Memory

total RSS momory limit

swap, total rss, # page ins/outs

### 4. tools

1. docker

2. nspawn 

3. nsenter

4. /sys/fs/cgroup

5. systemd units

참고.

Modern Linux Servers with cgroups - Brandon Philips, CoreOS, YouTube

https://wiki.archlinux.org/index.php/Cgroups

http://man7.org/linux/man-pages/man7/namespaces.7.html

https://access.redhat.com/documentation/ko-KR/Red_Hat_Enterprise_Linux/6/html/Resource_Management_Guide/ch01.html

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

##### 

해당 포스팅이 시발점.

http://idchowto.com/?p=19919

### 위의 포스팅 내용 정리

Linux에서 보안과 성능의 향상을 위해 리소스의 사용을 제한하고 사용자와 분리하고자 함

Cgroups을 통해 보안을 강화하였고 자원의 할당량을 조절하였으나 가상화나 사용자 격리에 효율적이지 못 하였음.

namespace를 강화하기 시작함 (커널 2.6.x ~ 3.8, 오랫동안 공들임)

특히 네트워크 관점에서의 namespace에서,

트래픽을 network namespace로 분산한 만큼 방화벽 룰셋이 줄어들며, 결과적으로 지연시간도 줄어들게 됨

또한 network namespace에 해당하는 conntrack은 slab allocator를 통해 관리되는데, 

conntrack 또한 줄어들게 되므로 자원의 효율에 있어서 아주 효과적임. 

(하나의 룰셋을 찾기위해 검색해야할 conntrack의 범위를 한정 시켜주기 때문에)

또한 Docker는 lxc+aufs를 제공하기 위해 특화되었으며 이 결과 docker image reposigory가 활성화 됨

사용자 이미지의 저장 및 배포가 굉장히 단순화 되어 빠른 배포를 구현

이는 기존의 다른 가상화보다 docker가 인기있는 이유임

### 

# slab allocator

http://jiming.tistory.com/131

# conntrack

http://manpages.ubuntu.com/manpages/trusty/man8/conntrack.8.html

# VFS와 UnionFS

리눅스에서는 VFS을 통해서 다양한 파일시스템을 지원

* VFS  : http://jiming.tistory.com/127

- UnionFS은 몇개의 branch를 가지며 여러 타입의 파일시스템을 지원한다. 

- UnionFS 내에서 각각의  branch들은 precedence를 할당받고, higher precedence의 branch는 lower precedence의  branch를 override 한다.

- branch는 Directory에 동작한다.

: 2개의 directory에 걸쳐있는 하나의 branch가 있다면, 

UnionFS의 그 directory(high-level)의 내용과 속성은 두 directories(low-level)의 조합이다.

- UnionFS는 사용자가 알지 못하게 자동으로 중복된 directory entreies를 처리한다.

- 만약 두 branch에 하나의 파일이 존재한다면 

UnionFS file의 속성과 내용은 높은 우선순위의 branch의 파일에 따르며 낮은 우선순위의 내용은 무시된다. 

(http://www.slideshare.net/endhrk/introduction-to-docker-36472476)

# AUFS

: short for Advanced multi layered Unification File System

- Developed by Junjiro Okajima in 2006

- 이전의 UnionFS에서 완전히 새로쓰임

- 신뢰성과 성능 개선을 목적으로 like writable branch balancing같은 새로운 컨셉이 소개됨

- Linux File System의 Union Mount를 구현

- AUFS의 처음 full name은 "Another UnionFS" 이였으나, version 2부터 "Advanced multi layered Unification File System"로 바뀜

- aufs는 writable branch balancing 기능을 제공

몇개의 파티션을 writing 하는 동안 setup을 할 수 있음

=> 다른 여러개의 파일 시스템을 하나로 통합하여 사용할 수 있음

모든 새로운 파일이나 수정된 파일들끼리 여유 메모리 공간, 부모 directory의 존재, 랜덤하거나 그렇지 않은 것(??)들을 기반으로 분할 됨

=>이미지에 대한 변경사항을 메모리에 저장해 두고 새로 쓰거나 변경된 파일을 읽을 경우 메인메모리에서 저장한 파일을 로드함

이러한 데이터는 USB 메모리에도 저장이 가능하여 다양하게 활용될 수 있음

* Why to use AuFS instead of unionfs ? 

: http://www.unionfs.org/

(UnionFS, AUFS가 다른 점 좀 더 찾아보기)

# Docker와 AuFS

: Docker는 LxC와 AuFS의 제공을 위해 시작. 즉 file system으로 AuFS를 사용

- copy-on-write 제공

=> Docker에서 이미지 생성 시, base image에 포인터로 연결을 한 후 이미지를 생성하므로 디스크 write가 발생하지 않고 base image에서 파일시스템으로 분기할 때 해당 내용을 디스크에 기록

- stacking, 변경된 이미지로 커밋은 새로운 파일 시스템 레이어로 구현됨

(http://www.slideshare.net/colinsurprenant/docker-introduction-dev-ops-mtl)

가벼운 이미지의 구현은, Github와 같은 Docker Hub라는 docker만의 repository를 탄생시키게 되었고

 Docker 생태계에 큰 중추가 되고있음.

'

생각없이 설치하다가 문득 떠오른 말이 있다.

제대로 해야지 남는다는..

지금부터라도 기록을 습관화 하자!

맥북에서 VBox에 VM을 생성하고 NAT외에 Host-bridge를 추가하여 네트워크를 2개를 설정하였다. 

$ ifconfig eth1 up 

터미널에서 ssh 접속해서 사용 중 이었는데, 새로운 VM을 만들고 접속하려니 요런 에러가 발생했다. 

정확한 이유는 잘 모르지만 업데이트가 필요한 듯?

adminui-MacBook-Pro:~ Jennie$ ssh user@192.168.56.101

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

Someone could be eavesdropping on you right now (man-in-the-middle attack)!

It is also possible that a host key has just been changed.

The fingerprint for the RSA key sent by the remote host is

Please contact your system administrator.

Add correct host key in /Users/admin/.ssh/known_hosts to get rid of this message.

Offending RSA key in /Users/admin/.ssh/known_hosts:1

RSA host key for 192.168.56.101 has changed and you have requested strict checking.

Host key verification failed. 

adminui-MacBook-Pro:~ Jennie$ ssh-keygen -R 192.168.56.101

# Host 192.168.56.101 found: line 1 type RSA

/Users/admin/.ssh/known_hosts updated.

Original contents retained as /Users/admin/.ssh/known_hosts.old

$ ssh-keygen ?

위의 명령어로 옵션을 확인하니 저 알려진 호스트관련 파일을 삭제하는 것 같다.

-R hostname Remove host from known_hosts file.

암튼 그 후에 다시 ssh 접속을 시도해보니 잘되었다.

adminui-MacBook-Pro:~ Jennie$ ssh user@192.168.56.101

The authenticity of host '192.168.56.101 (192.168.56.101)' can't be established.

RSA key fingerprint is e9:53:f7:f8:ac:32:89:73:11:b4:dd:fb:ec:76:5f:47.

Are you sure you want to continue connecting (yes/no)? yes

...

user@192.168.56.101's password: 

Welcome to Ubuntu 14.04.3 LTS (GNU/Linux 3.19.0-25-generic x86_64)

docker에 대해 알아보던 중 docker를 이미지로 설치할 때 우분투 환경에서만 링크로 설정하여야 한다는 것을 보게되었다.

왜 그런지 알아보던 중 한 분이 해당 url을 알려주셨다. 

ubuntu 패키지에는 이미 그래픽환경을 위한 system tray로 docker라는 것이 존재한다. (새삼 깨달았다.. 그 이름이 docker라는 걸..)

이것과의 혼동을 피하기 위해 docker.io 형태로 지원을 한다. 이것을 사용하려면 링크를 걸어줘야 한다.

https://www.maketecheasier.com/running-docker-io-under-ubuntu-linux/

Running Docker.io Under Ubuntu Linux

우분투 리눅스에서 Docker.io 실행

As powerful hardware has become more and more of a commodity, the ability to run multiple virtual machines on a single piece of hardware has become an industry norm. From web hosting to cloud computing, many services are run on virtualized environments. As well as desktop virtualization solutions like VirtualBox, there are also quick provisioning solutions like Vagrant. The problem with a virtual machine is that it needs to emulate every aspect of the guest computer including all the system RAM which will be allocated exclusively to the virtual machine. As a result, virtualization can be resource hungry.

파워풀한 하드웨어가 상품화 되어지면서, 하나의 하드웨어에서 여러 virtual machines을 실행하는 능력은 업계의 표준이 되었다.

클라우드 컴퓨팅을 위한 웹 호스팅으로 부터, 많은 서비스들은 가상 환경에서 동작한다.

VirtualBox같은 가상화 솔루션을 더불어 Vagrant와 같은 빠른 프로비저닝 솔루션 또한 있다.

가상머신의 문제는 오직 가상머신을 위해 할당 될 모든 시스템 메모리를 포함하여 게스트 컴퓨터의 모든 측면을 에뮬레이트 해야할 필요가 있다는 것이다. 결과적으로 가상화는 자원부족이 될 수 있다.

At the other end of the spectrum is a “chroot” environment, which changes the underlying root directory for a process so that it runs in its own environment and has no access to other files on the host operating system. However, there is no virtualization at all, just a different directory tree.

극단적으로??, 프로세스를 위해 원래의 root directory를 바꾸며 자신의 환경에서 실행되고 호스트 OS상의 다른 파일에게 액세스하지 않는 "chroot" 환경이다. 하지만 이것은 가상환경이 아니며 단지 다른 device tree일 뿐이라는 것이다.

The mid-point between these two systems is a container. Containers offer many of the advantages of a virtualized machine but without the high resource overhead. Containers are more functional than chroot environments in that there is some virtualization. For example, processes that are created in a container are assigned IDs (PIDs) separately from those in the host OS. In technical terms, the container has its own PID namespace. In fact, containers have their own namespace for the networking subsystem and for InterProcess Communication (IPC). That means that a container can run network services, like a SSH server or a web server.

이 두 시스템 사이에서의 중간 포인트는 컨테이너이다. 컨테이너는 많은 자원의 오버헤드 없이 가상화된 머신에서 많은 어드밴티지를 제공한다. 컨테이너는 가상화 환경에서 chroot 환경보다 더 functional하다. 예를들어 컨테이너 기술로 생성된 프로세스들은 Host OS로부터 각각 PIDs를 가진다. 즉 컨테이너는 그들 자신의 PID namespace를 갖는다. 사실 컨테이너는 네트워킹 서브시스템과 IPC를 위해 스스로의 namespace를 갖고있다. 이 말은 컨테이너는 SSH 서비스나 web server 같은 네트워크 서비스를 수행할 수 있다는 의미이다.

From the outside, the container looks like a virtual machine with its own IP address and its own networking services, but on the inside the container uses much more of the host operating system than a virtual machine, more like a “chroot” environment. For example, you can use a CentOS container running on a Ubuntu host. The commands and files are all from CentOS, but if you ask the container which kernel it is running, it will report it is running the Ubuntu kernel, because the container is running on the kernel from the host OS.

외부로부터, 컨테이너는 자신만의 IP address와 자신만의 네트워크 서비스들을 갖는 가상머신처럼 보이지만 컨테이너 내부에서는 가상머신보다 "chroot"환경에 더 가까운 host OS를 사용한다. 예를들어 Ubuntu host 위에서 CentOS 컨테이너를 동작시킬 수 있다. 모든 명령과 파일들은 CentOS 기반으로 동작하지만 만약 컨테이너에게 실행중인 커널을 물어본다면 컨테이너는 Host OS의 커널에서 동작하므로 Ubuntu 커널에서 동작하고 있음을 알릴 것이다. 

Docker is a container based virtualization framework that allows you to create containers holding all the dependencies for an application. Each container is kept isolated from any other, and nothing gets shared.

Docker는 가상 framwork 기반의 컨테이너 기술로 application을 위한 모든 dependencies에 대해 홀딩상태의 컨테이너를 생성할 수 있다. 각각의 컨테이너는 독립을 유지하며 공유를 하지 않는다. 

To install Docker on a 64-bit Ubuntu 14.04 system, run the following commands:

Ubuntu 14.04 시스템 기반에서 Docker를 설치하기 위해서는 다음 명령어를 수행한다.

There is an existing Ubuntu package called docker, which is a system tray for KDE3/GNOME2. To avoid confusion, the container runtime is called docker.io. The last command creates a link from “/usr/local/bin/docker” to “/usr/bin/docker.io”, which enables the docker command from the command line rather than docker.io.

Ubuntu 패키지에는 "docker"라고 불리는 KDE3/GNOME2를 위한 시스템 트레이가 있다. 혼란을 피하기 위해 컨테이너 실행시간은 docker.io라고 불린다. 마지막 명령에서는 “/usr/local/bin/docker”로부터 “/usr/bin/docker.io”에게 링크를 생성하며, 이것은 docker.io 대신 커맨드라인으로 docker 명령의 수행을 가능하게 한다.

Note: Docker.io is also available for other distro. Here is the installation instructions if you are not using Ubuntu.

Docker.io는 다른 리눅스 배포판에서도 사용할 수 있다. 만약 Ubuntu를 사용하지 않는 다면 여기 설치 명령이 있다.

To execute a shell inside the container, run:

container에서 shell을 실행하기, "run" :

The “-i” flag makes the session interactive, and the “-t” flag tells docker to emulate a terminal session. The “ubuntu” parameter tells docker to run a container based on Ubuntu 14.04 and “/bin/bash” is the command that should be run once the container is up, i.e. run the Bash shell.

"-i" 플래그는 session 상호작용을 만들고, "-t" 플래그는 docker에게 terminal session을 에뮬레이트하라고 한다. "ubuntu"는  Ubuntu 14.04 기반으로 container를 수행하라는 파라미터이며, "/bin/bash"는 컨테이너가 뜰 때 수행할 필요가 있는 명령이다. 즉, Bash shell을 실행한다. 

When docker runs it checks if the desired base image file has been previously downloaded. If it hasn’t, it will download the image from index.docker.io, which is also the site to use to see which images are officially supported by docker.

docker가 run 할때, 만약 원했던 base image 파일이 이미 다운되어져 있다면 확인한다. 만약 다운되어있는 base image 파일이 없다면 docker로 부터 공식적으로 지원되는 이미지를 사용하고 볼 수 있는 사이트인 index.docker.io에서 이미지를 다운로드 할 것이다. 

To download other images without starting a container, use the “docker pull” command. For example, to download the CentOS base image use:

컨테이너의 사작없이 다른 이미지를 다운로드 하려면 "docker pull" 명령을 사용하면 된다. 예를들어, CentOS base image 다운로드는 다음과 같다.

You can also run single commands in a container and then let the container exit. Use the following command to run the “ps aux” command inside the CentOS container:

또한 컨테이너에서 하나의 명령을 실행한 다음 컨테이너를 종료할 수 있다. 실행을 위한 명령은 CentOS 컨테이너 내부의 "ps aux"를 사용한다. 

When a container shuts down, all changes are lost. The advantage of this approach is that when a container starts, it is in a known state. This is essential for test environments and for build services, etc. It is also important for running cloud services, as the container can be quickly reset and rebooted into a stable state.

컨테이너가 shutdown 될 때, 모든 변경사항은 지워진다. 이것의 장점은 컨테이너가 시작할 때의 알려진 상태에 있다는 것이다. 이것은 테스트환경과 서비스 빌드와 기타 등등에 필수적인 것이다. 또한 컨테이너가 안정된 상태의 빠른 reset과 reboot 을 할 수 있는 것과 같의 클라우드 서비스의 실행을 위해 중요하다. 

However, it also means that any configuration performed or any files created in the container will be lost. The solution is to create a new image with all your changes. Try the following commands:

하지만 이것은 컨테이너에서 설정한 구성과 생성된 파일들의 손실될 것을 의미한다. 해결방법은 모든 변경사항에 대해 새로운 이미지를 생성하는 것이다. 다음의 명령어이다. 

The first command will start a container and install nmap. The second command will list the latest (-l) created container, even if it isn’t running.

첫번째 명령은 컨테이너를 실행하고 nmap을 설치할 것이다.

두번째 명령은 명령이 실행되지 않더라도 최신의 생성된 컨테이너 순으로 리스트업 할 것이다.

You can now create a snapshot of that container and save it to a new image:

이제 새로운 이미지를 위해 컨테이너를 스냅샷을 생성하고 저장할 수 있다. 

“1b498c2d502c” is the ID of the container as listed by the “docker ps -l” command. Now if you start a shell for the ubuntu-with-nmap container, it will have the nmap command pre-installed.

“1b498c2d502c”는 "docker ps -l" 명령어에 의해 리스트업 될 컨테이너의 ID이다. 이제 ubuntu-with-nmap 컨테이너를 위해 shell을 시작하려면, 설치 전 nmap 명령을 수행해야 한다.

There is plenty of information about docker in docker.io’s documentation, and there are also several example setups explained, including how to perform common tasks like running a python web app and running a SSH service.

docker.io's documentation에 docker에 대한 많은 정보가 있으며 설치를 설명하는 몇가지 예제와 python web app과 SSH 서비스 실행과 같은 작업을 수행하는 방법이 나와있다.

If you have any questions about docker, there is a strong docker community which should be able to help. You can also ask questions in the comment section below and we will see if we can help.

만약 docker에 대해 질문이 있다면 docker community를 이용할 수 있다. 해당 글에대한 질문은 아래에  comment를 남겨주면 우리가 보고 도움을 주겠다.

# intel DPDkP의 해결책

# Linaro ODP

: LNG에서 플랫폼에 상관없는 네트워킹 데이터 평면에 API를 제공하기 위해 오픈소스로 공개

- 사용자단에서 한개의 프로세서로 동작, 최소한의 API를 호출

- ODP API : 커널의오버헤드를 야기하지 않고, 가용한 하드웨어의 특성을 사용하여 DPA를 실현하고자 함

  (= SDK API)

- 하드웨어 의존적인 SDK API 호출을 배제하지 않음, 플랫폼에 상관없는 소스레벨의 호환성을 제공해주지 못할 수 있음

- 데이터 플레인 응용을 지원하는 플랫폼

- 리눅스 API를 사용하는 리눅스 사용자 평면제어 또는 관리평면 기능을 구현한 응용프로그램과 병렬처리 가능

# Linaro ODP 추상화된 논리적 패킷처리 구조

SW - 소프트웨어 블록

HW - 대부분 하드웨어 블록에 의해 수행되는 부분으록 간주하지만, 소프트웨어에서 수행될수도 있음

빗금 - 낮은 액세스 지연을 가지는 펌웨어와 같은 하드웨어에서 아주 가까운 소프트웨어에 의해 수행되는 기능

1. Packet Input 블럭 - 물리적 입력단의 패킷 포트를 추상화

2. Pre-Processing - 물리 인터페이스와 동일한 속도로 처리, 버퍼 풀의 선택 및 첫번째레벨의 congestion 제어를 위한 패킷분류 수행

3. Input Classification - 구별된 트래픽 플로우 분석 및 분류, 큐에 배정, 분석결과 메타데이터를 추가

4. Ingress Queuing - 실제 페이로드에 대한 메타에이터(descriptor)들의 큐를 제공, 큐에대한 descriptor들은 HW장비 또는 SW에서 도착

5. Delivery/Scheduling - 동기화된 SW/HW 인터페이스, 동작 스케줄링과 한일 수신점에 대한 다수개의 프로세서 코어에 대한 로드밸런싱 수행

* 스케줄러큐 - 우선순위 설정, 큐의 상태, CPU상태를 참조

6. Accelerator - 비동기적 큐기반의 인터페이스에 대해 암호화 또는 압축등 특수 목적 처리를 수행

7. Co-processors - Accelerator과 유사, SW에 대한 동기화된 인터페이스를 가지고 빠른 동작을 수행

8. Egress Queueing - 출력 포트를 향해 동기화된 인터페이스를 제공

* 각각의 큐는 논리적으로 매핑, 설정된 QoS기능을 선택적으로 수행

9. Post Processing - 패ㅣㅅ을 출력포트를 위해 스케줄링, 패킷이 나가면 패킷 버퍼를 해제, 패킷 checksum등 inline가속 기능 제공

10. Packet Output - 물리 출력 포트에대한 인터페이스 제공

# 데이터 플레인 가속화

: 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포트로 패킷을 송신

# 가상화 + 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으로 관리하자

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

6. 끝