Es irrt der Mench, solange er strebt.

도커

컨테이너형? 가상화를 구현하기 위한 상주 어플리케이션, 이를 관리하는 명령형 도구로 구성.

어플리케이션 배포에 특화되어 있음.

도커 이전 컨테이너형 가상화 에는 LXC(Linux Containers)가 가장 유명 했으며 도커 초기에는 LXC를 런타임으로 사용 했음. 현재는 rucC를 사용.

* 컨테이너형 가상화 기술

컨테이너형 가상화를 사용하면 가상화 소프트웨어 없이도 운영 체제의 리소스를 격리해 가상 운영 체제로 만들 수 있음. 이 가상 운영 체제를 컨테이너라고 하며 컨테이너를 만들면서 발생하는 오버헤드는 다른 가상화 소프트웨어보다 더 적고 빠르게 시작 및 종료가 가능, 이에 들어가는 리소스도 작은 편임.

그림1

◈ 도커와 LXC 차이

- 호스트 운영 체제의 영향을 받지 않는 실행 환경

- DSL(Dockerfile)을 이용한 컨테이너 구성 및 어플리케이션 배포 정의:  Dockerfile  코드를 기반으로 복제 및 배포가 이루어지기 때문에 재현성이 높음. 만들어진 기존 컨테이너를 다른 환경에서 동작시키기 위한 매커니즘이 잘 만들어져 있음.

- 이미지 버전 관리

- 레이어 구조를 갖는 이미지 포맷

- 도커 레지스트리

- 프로그램 가능한 다양한 기능의 API

◈ 도커 사용?

- 코드를 통한 실행 환경 구축과 어플리케이션 구성

- 실행 환경과 어플리케이션 일체화로 이식성 향상

- 시스템을 구성하는 어플리케이션 및 미들웨어의 관리 용이성

- 코드로 관리하는 인프라와 불변 인프라의 두 개념을 낮은 비용으로 실현 가능

- 도커 컨테이너는 운영체제와 어플리케이션을 함께 담는 개념.

◈ 컨테이너와 VM 차이

컨테이너는 VM과 유사하나 VM은 아니다. OS가 필요하지 않음? 

Docker 이미지 파일은 엄처 작고 가벼우며 Library를 공유.

◈ 도커 컨테이너 오케스트레이션 

- 여러 컨테이너를 사용하는 어플리케이션을 쉽게 관리할 수 있도록 -> 도커 컴포즈

- Yaml 포맷으로 작성된 설정 파일로 컨테이너를 정의하거나 컨테이너 간의 의존 관계를 정의해 시작 순서를 제어할 수 있음.

- 도커 스웜(Docker Swarm): 여러 컨테이너를 관리하는 것만이 목적인 도커 컴포즈와 달리 컨테이너 증감, 노드의 리소스를 효율적으로 활용하기 위한 컨테이너 배치, 로드 밸런신 기능 등의 기능을 갖춤. 배포 시에 롤링 업데이트가 가능.

- 쿠버네티스: 구글의 오픈소스 소프트웨어, 사실상 컨테이너 오케스트레이션 표준. 도커 스웜보다 기능이 충실하며 확장성이 높음.

Persistence

- 어플리케이션이 사용 중인 세션을 같은 서버에 지속적으로 할당하는 기능.

- 하나의 서버에서 처리하고 있던 것을 처리 도중 다른 서버로 부하분산시키면 처리 자체에 정합성이 맞지 않음.

ex) 쇼핑몰 - '장바구니에 넣고 정산한다' 라는 일련의 동작을 하나의 세션, 하나의 처리로 간주하고 지속적으로 하나의 서버에만 할당하여 처리 정합성을 보장.

* Cookie Persistence 장비에 따라서 Persistence Record를 작성하지 않는 경우가 있음. Persistence Record를 만들지 않는 경우는 Cookie 정보만 보고 Persistence를 실행.

1.  출발지 IP Persistence

접속 클라이언트 IP주소를 사용해 동일한 서버에 지속적으로 할당하는  L3 Persistence. L3 계층으로 서비스를 거치지 않아 알기 쉬운 구성. 일정 시간 사용하지 않으면 해당 레코드를 삭제. 시간은 너무 짧으면 다른 서버에 할당, 너무 길면 장치나 서버에 부하가 걸릴 수 있음. NAPT환경이나 Proxy 서버를 경유하는 환경에서는 한 대의 서버에 수많은 접속이 할당되는 단점. 

2. 목적지 IP Persistence

서버의 IP 주소를 기준으로 같은 서버에 할당하는 L3 Persistence. 서버 부하분산 환경 보다 회선 부하분산 환경에서 많이 사용.

3. Cookie Persistence

HTTPS와 SSL 가속 환경의 HTTPS에서만 유효한 L7 Persistence. 쿠키가 가진 정보를 기준으로 일정 시간 세션을 지속. 클라이언트마다 유연하게 세션을 유지할 수 있어서 HTTP 부하분산 시 자주 사용.

4. HTTP Header Persistence

EX9214와 스토리지 간 데이터 통신 문제 발생

set interfaces xe-0/1/0 ether-options no-flow-control

1. Flow Control

End -to-End

flow control은 네트워크와 상관없이 순수하게 End 호스트의 TCP Rx Socket buffer의 overflow를 방지하는 매커니즘

즉, 송신측과 수신측의 데이터처리 속도 차이를 해결하기 위한 기법

- 수신측이 송신측보다 속도가 빠른 것은 문제되지 않음. 송신측이 수신측보다 속도가 빠르면 문제가 발생

- 수신측에서 수신된 데이터 처리를 위해 윗 계층으로 서비스하는 속도보다 송신측에서 보내는 데이터 속도가 더 빠르다면 수신측에서 제한된 큐를 초과하여 이후에 도착하는 데이터 손실을 가져올 수 있음

- 불필요하게 응답과 재저농의 데이터가 다시 송신측과 수신측 간에 빈번히 발생, 이러한 위험을 줄이기 위해 강제로 송신측의 데이터 전송을 줄임.

1) Stop & Wait 방식

매번 전송한 패킷에 대해 확인 응답을 받아야만 다음 패킷을 전송하는 방법

2) 슬라이딩 윈도우

수신측에서 설정한 윈도우 크기만큼 송신 측에서 확인 응답없이 세그먼트를 전송할 수 있게 하여 데이터 흐름을 동적으로 조절하여 제어하는 기법

송신 버퍼의 범위는 수신 측의 여유 버퍼 공간을 반영하여 동적으로 바뀜으로써 흐름제어를 수행

2. Congestion Control

네트워크 혼잡으로 패킷 loss가 발생할 때 congestion을 감소 시키기 위해 동작하는 알고리즘

송신측의 데이터 전달과 네트워크 처리 속도 차이를 해결하기 위한 기법

* 

클러스터 구성 요소

1. Nodes (Controller + Disk Shelf)

- 구성: Network ports / Expansion slots / Nonvolatile Memory(NVRAM, NVMEM)

          Disks

2. HA Pair

- 파트너 간 2개의 커넥선 노드

- 같은 Disk shelves 에 연결

- 파트너 디스크 fail 시 남은 노드에서 디스크 제어

- HA pair 연결 구성: HA interconnect / Multipath HA shelf connectivity / Cluster interconnect connectivity

3. Networks

- Cluster interconnect : 노드간 연결, private network

- Management network 

- Data network : one or more networks 필요, Ethernet / FC / converged network

4. Ports & Logical Interfaces

Data ONTAP 스토리지 아키텍처

- Physical Layer : RAID Groups of Disks > Aggregate

- Logical Layer : FlexVol Volumes > Files and LUNs

1. Physical Storage

1) Disk

- Disk ownership은 하나의 컨트롤러에 할당

- spare로 두거나 RAID 그룹에 추가

2) RAID Group

- disk collection 

- data is striped across the disks.

3) Aggregate

- 하나 이상의 RAID group 집합

- 하나의 컨트롤러가 ownership을 가짐.

2. Logical Storage

1) SVM(Storage Virtual Machine)

- data volumes 컨테이터

- 클라이언트 데이터는 LIF를 통해 

2) Volume

- file or LUNs의 논리 데이터 컨테이너

- 하나 이상의 FlexVol , 한 개의 확장 가능한 무한 볼륨?

3) LIF

- 포토와 연결된 네트워크 주소 대표.

- 클라이언트 데이터 엑세스

SVM with FlexVol Volumes

A200::>vserver setup

...

A200>vserver show

- SVM root volume = 1GB, root volumes는 공간이나 inode의 부족으로 인해 SVM root volume에 볼륨을 마운트 할 때 오류를 방지.

- SVM은 자동 시작 실행. 기본적으로 vsadmin 사용자 계정이 만들어 지고 잠긴 상태가 됨.

- FlexVol volume: NAS 환경에서 파일 시스템, SAN 환경에서의 LUN 컨테이너

- QTree: FlexVol의 더 작은 세그먼트 분할 / quotas(할당량), security, CIFS oplock 설정 관리

- LUN : SCSI disk의 Logical Unit

- Infinite Volume : 최대 20억 개 파링과 수십 petabytes의 데이터를 저장할 수 있는 확장 가능한 볼륨 1개

클러스터 설정

- 지원 클러스터 설정

Single-Node / Two-Node Switchless / Multinode Switched / MetroCluster

1) Single-node Cluster

1. VLAN으로 브로드캐스트 도메인 나누기

- VLAN이란 네트워크 상의 노드들을 물리적인 위치와 관계없이 세그먼트를 분리하는 방법

- 브로드캐스트 도메인을 나눔.

- 대표적인 브로드캐스트 프레임: ARP, NetBIOS name query, RIP 등

- 대규모 LAN 환경에서 브로드 캐스트 프레임은 네트워크 성능에 상당한 영향을 끼침.

- VLAN으로 세그먼트를 분리할 경우 브로드캐스트 도메인이 분리되어 네트워크 대역폭을 보다 효과적으로 사용.

2. VLAN의 동작

- VLAN을 구분하는 방법은 각 스위치 벤더마다 차이가 있음.

- 스위치 각 포트에 VLAN ID를 할당하여 프레임이 스위치 포트에 수신될 때 해당  VLAN ID로 포장하여 스위치 내부 백플레인으로 전달. 각 포트는 자신에게 할당된  VLAN ID와 같은 프레임만 수신.

- 스위치가 VLAN ID를 읽어 해당 VLAN에 소속된 포트로 프레임을 전달하면 해당 포트는 VLAN 태그를 제거하고, CRC 검사를 한 후 본래의 이더넷 프레임을 추출하여 목적지 포트로 전달.

3. VLAN 구성 방법

 1) End-to-End VLAN 구성

 - 사용자들의 물리적인 위치와 이동에 관계없이 사용자의 VLAN 멤버쉽을 같게 설정할 수 있음.

 - 단점은 관리자가 사용자가 접속된 포트를 알아야 함. 관리의 어려움

 2) 로컬 VLAN

 - 지리적으로 인접한 디바이스들을 하나의 멤버로 만드는 것.

1. 스토리지 성능에 영향을 미치는 요소들

 - 블록 크기(data block size)

 - 랜덤/순차성 (I/O mix of random or sequential access patterns)

 - 읽기/쓰기 비율 (balance of read and write operations)

 - 측정 도구 (tool)

 - 측정 시스템 구성 환경 (system configuration)

2. 스토리지 성능평가를 위한 블록크기

 1) OLTP, random 데이터용 스토리지

  - 블록크기: 4KB, 8KB (512B, 128KB)

  - 주요 응용: E-mail, web, OLTP, 전자결재

  - 중요성능지표: IOPS

  - 512B 일때 최고성능 값이므로 대부분 512B 채택하나 비현실적...?

 2) Stream, sequential 데이터용 스토리지

  - 블록크기: 256KB, 1024KB

  - 주요응용: VOD, batch, backup

  - 주요 성능 지표 : MB/s

  - 블록 크기가 클수록 최고 성능 값

3. Read/Write 비율

 1) R,W 비율 결정

  - Read only

  - Write only

  - Read : Write = 0.5 : 0.5

 2) 주요 근거

 - 벤더들은 최고 성능 획득에 주력하여 read only 일 경우가 많음

 - 다양한 read:write 비율 적용 필요