# NUMA

# CPU(x86) Ring Level 

CPU 권한레벨, privilege level (= protection rings)

- Ring 0 : 커널, Ring 3 : 유저

- guest OS : R1 or R2

- guest OS에서 H/W로의 명령을 VMM에서 Binary Translations 기술로 가로채고 에뮬레이션

    => Intel-VT, AMD-V에서 지원

##### 가상화

가상화 != 에뮬레이션

1. Application 가상화

~ JVM

2. H/W 가상화

~ Hypervisor

3. Desktop 가상화

~ VNC, X-Window, Remote Desktop, Virtua Box, VMware, ...

4. Network 가상화

~ VPN, VLAN, SDN, ...

- 가상 NIC, 고유한 MAC addres 제공(IEEE에 등록된 실제 MAC) 

- 가상 스위치와 Auto Negotiation으로 연결

- 가상 Switch(MAC기반의 L2 스위치)

- Port Group (가상머신용, 서비스콜용, VMKernel용)

5. Server 가상화

~ 하드웨어 에뮬레이션, 전가상화/반가상화/OS자체 가상화

- Full-Virtualization : Guest OS는 하이퍼바이저의 존재를 알지 못함. Binary Transration기법으로 가상화

- Para-Virtualization : 하이퍼바이저에서 인식이 가능한 시스템콜(hyper-call)을 사용해 가상화

but, Windows에서는 커널 내부에 hypercall을 처리하지 않으므로 Guest OS커널을 수정해야 할 필요가 있음

=> Intel-VT, AMD-V 등 하드웨어 지원기술이 생김

but, H/W바로위에서 작동이 안되는 문제가 있음

=> VMI (Virtual Machine Interface) 등장

< 메모리 가상화 >

- PTE, Page Table Entry

- MMU (Memory Management Unit)

- TLB(Translation Looaside Buffer)

=> VMware의 VMKernel은 이 세가지를 Shadow Page Table로 관리한다. 

이 기능이 추후 memory overcommit기술로 발전한다.

a. TPS (Transparent Page Sharing)

: VM들이 사용하는 파일 중 공유 가능한 것들(겹치는 것들)을 공유할 수 있도록 하는 기술

작동중인 VM 몇개를 뽑아서 게스트 물리메모리 기반으로 Hashing을 수행함.

이를 Host의 물리메모리와 비교하여 같은 경우에 매핑주소를 수정하여 공유하도록 함

b. Memory Ballooning

- VMware Tool 중에 vmmenctl(메모리 컨트롤러 드라이버)

VMKernel과 private 채널로 메모리 상황을 공유

-  Host의 물리 메모리 부족 시, VM 들에게 있는 각 vmmenctl 드라이버에게 메모리 팽창을 요구

- VM들은 영문은 모르지만 일체 swapping을 수행하여 물리메모리를 확보

c. 하이퍼바이저 스와핑

: 가상머신 생성시, 메모리와 동일한 크기의 스왑파일을 생성하여 물리메모리 부족시 스와핑 수행

6. 스토리지 가상화

 ~ VMFS, VMDK, 논리적인 스토리지 pool 사용

##### QEMU

- 고속의 동적바이너리 변환기법(Dynamic Binary Translation)을ㅠ 사용

- x86이 아닌 하드웨어에서 x86기반의 리눅스를 실행하려는 목적으로 개발

- x86, power PC, SPARC, ARM 등의 프로세서를 지원

* note) Binary Translation ?

하나의 명령어 세트를 다른 명령어 세트로 변환해주는 처리

- Static Binary Translation : 모든 실행파일의 코드를 대상 아키텍처에서 한번에 변환

- Dynamic Binary Translation : 기본 실행 블럭의 단위만큼만 읽어서 변환

- GNU GPL, LGPL, BSD or GNU GPL v2, ...

- Hosted 방식의 가상화를 지원 : 전체시스템 에뮬레이션 / 사용자 모드 에뮬레이션

<기능>

a. 에뮬레이터 기능 : 물리적인 H/W 아키텍쳐 번환 없이 OS나 Program을 다른 H/W에서 돌아가도록 중계 역할을 수행

=> 소프트웨어적인 변환작업이 필요하므로 무조건 한번은 성능저하(최악)

b. 하이퍼바이저 기능 : KQEMU(or QUM86)을 통해 게스트 OS의 코드를 Host System의 CPU에서 직접 실행

=> 높은 성능

커널 코드는 동적 바이너라 변환을 통해 실행시키고, 사용자 코드는 네이티브 모드에서 실행하는 가속 모드를 지원

c. Xen이나 KVM 가상화 서포트 수행(변형된 형태의 QEMU가 지원함)

<구성요소>

- CPU 에뮬레이터

- 디바이스 에뮬레이터

- 일반 디바이스 처리기

- 머신 기술자

- 사용자 인터페이스

### KQEMU

: Guest/Host OS 아키텍처가 동일한 경우, 

x86기반의 게스트 OS에 대해 하드웨어 지원을 받아 유저모드와 일부 커널모드를 호스트 머신의 CPU에서 직접 실행

=> I/O등은 Host에서 적용되어 게스트OS의 성능을 향상

### QEUM & KVM

: KVM에 최적화되어 qemu-kvm이라는 변형된 버전이 실행되며 x86 시스템에 대한 에뮬레이터 역할을 수행

### QEMU & Xen

: qemu-dm이라는 변형된 버전이 실행되며 XEN-HUM에서 디바이스 에뮬레이션과 일반 디바이스 간의 통신을 담당하여 I/O요청을 처리

### 네트워크 모드

: 에뮬레이션 된 NIC를 통해 VLAN을 생성할 수 있음(사용자 네트워킹, Tap 네트워킹, 소켓 네트워킹, VDC 네트워킹)

1. 사용자 네트워킹

: 기본적으로 생성되는 네트워크

- Host/Bridge 방식으로 가상의 인텔 E1000 PCI NIC 한개를 에뮬레이션

- 성능 낮음, ICMP 지원안됨, 외부에서 게스트로 직접접근 할 수 없음(포트포워딩이 필요함)

2. Tap 네트워킹

- 호스트 OS에서 먼저 생성한 뒤 게스트 OS에서 사용해야 함

- 성능 높음, root권한으로 QEMU를 실행해야 함

3. 소켓 네트워킹

- TCP/UDP 소켓을 이용해 게스트 OS사이에 VLAN을 생성

4. VDC 네트워킹

- 게스트 OS 사이에 virtual Distributed Ethernet 인프라를 사용

#####  KVM

: Kernal-based virual Machine

- 전가상화 방식을 사용하므로 하드웨어 지원이 필요함 (Intel-VT, AMD-V)

- x86 기반의 리눅스에서 구동

- 커널 모듈로 포함되어 있으며 Host에서는 하나의 프로세스로 간주되어 오버헤드가 적음

<구성>

- kvm.ko : 가상화 인프라스트럭쳐 코어를 위한 커널모듈

- kvm-intel.ko(kvm-amd.ko) : CPU 의존적 커널모듈

=> /proc/cpuinfo에서 vmx|svm같은 CPU와 커스터마이징 된 qemu-kvm이라고 하는 qemu 유틸리티가 지원되어야 함

* 명령어 : "egrep '(vmx|svm)' /proc/cpuinfo"

- 거의 모든 종류의 OS를 지원

- 다양한 저장장치를 지원

- 서버의 로컬저장소 : 게스트관리, 백업, 마이그레이션 쉬움, 성능은 점점 감소

- 물리디스크 : 비용이 많이 들지만 성능 좋음

- 로컬로 연결된 물리적 LUN : RAID에 사용

- LVM : 논리적 파티션

- iSCSI : IP-Over SCSI 프로토콜을 사용하여 TCP/IP 네트워크 상에서 SCSI를 사용해 

스토리지의 물리적인 위치에 상관없이 기존의 고성능, 고안정성 스토리지를 구축 가능

(IPSAN이라고 총칭하기도 함)

- Fiber Channel 기반의 LUN : SAN에서 사용되는 표준화 채널로 이루어진 LUN.

로컬 기반 SCSI뒤를 잇는 차세대 고속 인터페이스.

DC와 최대 8.6km 떨어진 곳에도 스토리지셋을 설치할 수 있음

성능, 안전, 비용모두 높음

- 등등 ...

<KVM 패키지 설치 시 설치되는 기본 패키지 들>

<KVM의 쉬운 운영을 위해 설치하는 패키지들>

# 가상화 시스템 관리

- 가상화 보안

- 마이그레이션

1. 가상화 보안

- 사용할 서비스만을 설치하자. 서비스 최소화!

- 방화벽

- Do not touch Dom0 (user사용자로부터의 접근 허용을 X)

- 저장장치 보안 : 파티셔닝이나 LUM을 지정해 호스트 boot을 수정하지 못하게 해야함

2. 마이그레이션

- Load Balancing

- H/W failover

- 에너지 절감

- 기역간 Data Center migration

- offline migration : 실행중인 guest 들을 종료시킨 후 복제를 통해 마이그레이션

- live migration : 실행중인 게스트의 메모리 페이지를 모니터링 하면서 이전될 호스트 이미지 파일을 전송해야함.

최종적으로 아주 잠깐 Host를 중지시켜 dirty data(변경되는 값)을 일괄전송 후 마무리

* Host A -> Host B

(1) B를 연결하고 헤더 정보 전송, 리소스 분배 및 설정

(2) 마이그레이션 시작

(3) 메모리 내용을 최대한 비슷하게 이전

(4) iteration을 실행하여 반복적으로 변경되는 메모리를 B로 전송. 최대한 비슷할 때까지 계속 전송

(5) 거의 다 전송하면 잠깐 정지한 후 더티데이터 및 상태값 등을 전송

(6) 메모리 페이지 내용이 같아지면 Host B를 실행

* 마이그레이션 요구사항

- online으로 연결된 최소 두대의 호스트상에 설치된 게스트 일 것

- NFS, GFS2, TSCSI, Fiber Channel등은 공유 네트워크 저장장치를 사용하는 곳

- 동일한 OS, 동일한 버전, 동일한 업데이트 상태

* 체크리스트

네트워크로 연결된 상태들

공유네트워크 저장장치 사용

동일한 OS/버전/업데이트 상태

막히지 않은 포트, 동일한 브릿지 및 네트워크 상태

마운트 위치 및 디렉토리

##### XEN

- x86을 비롯해 다양한 프로세서 지원

- 반가상화(상대적으로 좋은 성능) 및 전가상화 지원

- 가상게스트를 관리하는 장치 드라이버를 Domain-0이라는 관리 가상 게스트에 부여하여,

하이퍼바이저가 동작함에 있어 오버헤드는 감소시키고 성능은 증가시킴

(Network Backend Driver, Block Backend Driver)

- Xen Hypervisor

- Domain 0

- Domain U

1. Xen Hypervisor

:  실행중인 게스트들의 CPU스케쥴링과 메모리 분배를 담당.

(게스트->H/W)로 가는 명령어를 처리하여 자신이 HW인 것처럼 보이게 함

네트워크, 외부저장장치, 오디오, 컴퓨터 시스템에 있는 일반적인 I/O는 지원하지 않음

2. Domain 0

: 수정된 리눅스 커널로 다른 가상 게스트들(도메인 U의 PV, HVM 게스트)과 통신하며 물리적 I/O 리소스에 접근 가능한 특별한 권한을 가진 가상 게스트

(Special Privileged Guest라고 함)

- Domain U의 시작, 중지, I/O 요청등의 모든 작업을 처리

- 하이퍼바이저에게 접근

- Domain U가 요청하는네트워크와 로컬 디스크 작업을 처리하는 드라이버인 Network Backend Driver와 Block Backend Driver를 제공

Network Backend Driver : Domain U로부터오는 모든 가상게스트들의 요청을 처리하는 로컬 네트워크 드라이버. H/W와 직접 통신

Block Backend Driver : Domain U의 요청에 따라 드라이브에서 데이터를 읽고 쓸 수 있는 로컬 스토리지와 통신

- Domain 0은 게스트들 보다 먼저 실행되어 있어야 함

3. Domain U

: 일반적으로 생성하는 Guest들로 I/O resource에 접근 권한이 없음

a. Domain U PV Guest (PV : Paravirtualized)

: 하이퍼바이저에게 게스트 OS가 동작하도록 OS를 수정H/W로 직접 접근하지 않고 하이퍼바이저를 통하도록 수정)해서 실행한 반가상화 게스트

   * 네트워크와 디스크에 접근하기 위해 드라이버가 존재하며 Domain 0에 요청

b. Domain U HVM Guest (HVM : Hardware-assisted Virtualization)

: 전가상화 게스트, OS 수정 없이 가상화하며 이를 위해 하드웨어 지원이 필요(Intel-VT, AMD-V)

- 가상화 된 게스트상에 PV드라이브가 없음

- Domain 0에 QEMU 데몬인 "qemu-dm"이 HVM게스트마다 실행되어 네트워크와 디스크 접근을 처리

- Xen Virtual Firmware(BIOS)를 통해 시스템 시작 시 Domain U HVM Guest를 초기화 함

4. 도메인 관리 및 제어 

: Domain 0은 다양한 데몬을 사용해 도메인을 관리/제어

- Xen 데몬 : Xen 환경의 System Manager 역할을 하는 파이썬 application.

 데몬에 의해 생성된 모든 요청은 Xm이 만든 XML RPC 인터페이스를 통해 전달

- Xm : 유저의 입력을 받아 XML RPC를 통해 Xen 데몬에게 전달하는 명령행 도구

- Xen 제어 library : Domain 0을 통해 데몬이 Xen Hypervisor와 통신할 수 있게하는 C library 

- qemu-dm : QEUM의 변형된 데몬으로 HVM 게스트들은 각각 Qemu demon이 필요함

네트워크, 디스크 요청을 처리해 완전한 가상 머신을 만듬 (네트워크, I/O에 접근하기위해 하이퍼바이저 외부에 Domain 0이 존재)

##### Xen Server

: Xen을 기반으로하는 서버 가상화 플랫폼

- Xen Hypervisor

- 다양한 OS와 HW를 지원

- GUI

1. XenCenter 

:  XenServer를 관리하는 콘솔 프로그램으로 CLI도 제공

2. XenServer Host 

: 게스트가 실행될 물리적 장비. XenServer Host의 CPU 및 메모리 자원을 이용해 게스트가 설치

로컬 스토리지를 제공(LVM, ext3), 원격 공유스토리지 (NFS. iSCSI)

3. Resource Pool

: 다수의 XenServer Host를 묶어서 관리. Migration, HA 등 값을 사용할 수 있음

* 스토리지 : 추상화된 계층구조를 가짐

- VDI 저장공간인 Storage Repository(SR)이 있음

- 로컬 스토리지(IDE, SATA, SCSI, SAS), 원격 스토리지(NFS, iSCSI, SAS, Fiber Channel)가 자원

- XenServer Host와 SR의 연결을 위해 PBD(Physical Block Devcice)를 사용 => 커넥터 역할을 수행

- 스토리지 저장소와 게스트간에 가상블록 장치(VBD, Virtual Block Device)를 게스트를 위한 가상의 볼륨 디스크를 제공

##### libvirt

: 가상화 플랫폼을 관리하는 Open Source API

다양한 가상화 기술에 사용(KVM, Xen, VMware, ESX, Hyper-V, LXC, ...)

C로 작성되었으며 다양한 언어에 바인딩 가능(Perl, Ruby, Java, PHP, ...)

* 원격의 가상머신 관리를 위해 libvirt는 libvirtd를 제공

=> 관리도구에서 로컬 libvirt와 원격의 libvirtd가 서로 통신하여 원격의 가상 머신에 관리 명령을 전달

##### virsh

: libvirt API를 바탕으로 만든 "virtual shell"

- CLI

- libvirt 설치 시에 함께 설치됨

##### XML Format

: libvirt나 virsh에서 가상머신, 스토리지, 네트워크를 생성하기 위해 명세를 XML 데이터를 설정

가상머신 관련, 네트워크 설정, 필터링 설정, 스토리지, 스토리지 암호화, 드라이버 적용, 호스트 장비 스냅샷

##### virt-install

: 가상머신 생성도구

##### virt-clone

: libvirt API를 이용해 가상머신 복제 도구

##### virt-viewer 

: 가상머신에 대한 원격 디스크가 탑제됨

##### virt-manager

: 하이퍼바이저와 가상화를 관리하는 GUI도구, 가상머신 생성 및 관리

##### 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 생태계에 큰 중추가 되고있음.

'

# 설치환경

OS X Yosemite (ver. 10.10.5)

Intel core i5(2.7GHz)

8GB RAM

Ubuntu 14.04 (Virtual Box) 

DevStack (Kilo)

# 설치진행

* docker는 기본적으로 Host OS위에 새로운  OS를 생성하지 않고 Host OS의 자원을  system call을 사용하여 사용하기 때문에(cgroups, namespace) root 권한이 필요

1. Virtual Machine 생성

- Ubuntu 14.04

- 2 cpus

- 2GB ram

- network 

net 1 : NAT

net 2 : bridge network

2. 설치 후 기본설정

: 네트워크 ip, 패키지다운로드 및 파이썬 모듈을 사용하기 위한 패키지 설치 등등

$ apt-get update

$ sudo apt-get -y install git git-review python-pip python-dev

$ sudo apt-get -y upgrade

3. Docker 설치

> GPG Key 및 docker repo 추가

$ sudo apt-key adv --keyserver hkp://p80.pool.sks-keyservers.net:80 --recv-keys 58118E89F3A912897C070ADBF76221572C52609D

* 한번씩 서버가 죽는 거 같아 한번은 다른 서버찾아서 했는데.. 잘 모르겠음....

$ sudo vi /etc/apt/sources.list.d/docker.list

deb https://apt.dockerproject.org/repo ubuntu-trusty main    ; on Ubuntu Trusty 14.04 (LTS)

$ sudo apt-get update

> docker 설치 사전 확인 조치

$ sudo apt-get purge lxc-docker

$ apt-cache policy docker-engine

> 추가 권장

대상 : Ubuntu 14.04 Trusty (LTS), 15.04 Vivid, 15.10 Wily

내용 : "linux-image-extra" kernel package 설치

이유 : "aufs" storage driver 지원

*aufs 참고 url : http://www.joinc.co.kr/modules/moniwiki/wiki.php/man/12/docker/aufs

$ sudo apt-get install linux-image-extra-$(uname -r)

> docker 설치 진행

$ sudo apt-get install docker-engine

> 확인 

$ sudo service docker start

$ sudo docker run hello-world

$ sudo service docker restart

> 옵션 사항

$ sudo usermod -aG docker user

* docker daemon은 TCP port 대신에 UNIX socket에 바인드 함

UNIX Socket은 sudo 권한을 가져야 하기때문에 docker daemon은 항상 root 권한으로 실행되어야 함 

> docker 커맨드에서 sudo를 사용하지 않기 위해서 "docker"라는 Unix Group과 user를 등록.

docker daemon이 실행될 때, docker group에 Unix의 R/W 가능한 권한을 부여함

$ sudo vi /etc/default/grub

GRUB_CMDLINE_LINUX="cgroup_enale=memory swapaccount=1"

* WARNING: Your kernel does not support cgroup swap limit. WARNING: Your

kernel does not support swap limit capabilities. Limitation discarded.

# Ubuntu 컨테이너 기반의 인스턴스 생성

> search 명령어 사용

> ubuntu 이미지 pulling

* 버전 명시는 저런식으로 가능

> docker 이미지 저장 후 glance 이미지로 등록

> Dashboard 확인

> 인스턴스 생성

vnc 접속이 안되서 해당 옵션 주고 다시 시도...

devstack은 서비스가 아닌 screen기반이라고 함(정확히 뭔지는 모르겠지만)

nova.conf를 수정한 후 screen update를 수행해 적용할 수 있음

네트워크 설정해야함

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

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

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

맥북에서 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포트로 패킷을 송신