interplanetary detour

참조 사이트 (Official)

kubernetes.io

subicura.com/k8s/guide

Container Orchestration

Container Orchestration이란 복잡한 컨테이너 환경을 효과적으로 관리하는 것이라고 정의할 수 있고, 그것을 위해 여러가지의 툴이 만들어졌으나 그 중 거의 표준으로 쓰이고 있는 도구(Framework)가 바로 쿠버네티스이다.

아래에서 대표적인 기능 6가지를 알아본다.

1. Cluster

위와 같이 사양이 제각각인 여러 개의 노드(On-premise: 실제 서버, Cloud: VM Instance)가 있을 때 이를 논리적으로 하나인 것처럼 Clustering하여 관리하는 것이 Cluster이다. 이 역할을 수행하는 것이 Master(Control Plane)이고, 하나의 Cluster(Data Plane)로 묶이는 각 Node들은 Worker Node라고 한다.

그렇게 만들어진 Cluster는 Master가 지속적으로 Auto Scaling을 하며 관리한다.

2. State

replicas 값의 변화를 자동적으로 감지하고 그에 맞춰 Pod를 증감시킨다.

과거에 SLB(Server Load Balancer)가 수행하던 일이라고 한다.

위와 같이 3이 되었을 경우 Pod 하나가 생성될 것이고, Pod에 문제가 생겨 동작을 하고 있지 않다면 그 또한 조절한다.

3. Scheduling

하나의 클러스터로 묶여 있는 3개의 Node가 있고, 그 위에 이렇게 애플리케이션이 작동하고 있을 때, 새로운 애플리케이션 인스턴스가 추가되어야 한다면 자동적으로 리소스 낭비가 가장 적도록 할당하는 것이다.

위와 같은 경우 2번째 Node에 추가될 것이고, 같은 규모의 애플리케이션이 또 추가되어야 한다면 Node를 새로 생성하여 그 위에 올린다.

4. ROLLOUT / ROLLBACK

이미지의 배포 버전이 업, 다운됨에 따라 ROLLOUT, ROLLBACK을 자동적 그리고 일괄적으로 처리하여 버전 관리를 수행할 수 있다. 위 상황과 같이 버전이 업그레이드 되면 일괄적 ROLLOUT을, 만약 새 버전에 문제가 발생해서 복구해야 한다면 이전 버전으로 ROLLBACK한다.

5. SERVICE DISCOVERY

Service Discovery는 컨테이너 내부에서 실행되는 서비스(ex: Web Server)의 생성을 자동으로 감지하고 등록하여 프로세스를 재시작하게 하는 기능이다. 이를 통해 관리자가 별도로 설정을 해 줄 필요 없이 외부에서 바로 서비스에 접근할 수 있게 된다.

6. VOLUME

NFS(File Storage), EBS(Block Storage), PD(Block Storage) 등을 Node에 할당하고 연결시켜서 볼륨 스토리지 관리를 할 수 있게 한다.

먼저 Ubuntu Server의 iso 이미지를 다운로드 받아서 Oracle VirtualBox에 가상 머신을 만들었다.

설치 방법 및 기본 설정은 이전 게시글에 있으니 링크를 걸어둔다. 하지만 이번 실습에선 아래 글과 같이 하나하나 설정하지 않고 대부분 기본 설정으로 빠르게 만들었다. 또한 네트워크 인터페이스 카드도 NAT 하나만 설정했다.

https://yoonhoji.tistory.com/3?category=1042734 

Configure Ubuntu Server

먼저 인터넷 연결을 확인한다.

sudo apt update

NetworkManager를 설치한다.

sudo apt install -y network-manager

sudo systemctl status network-manager

포트 포워딩 적용을 위해 위에 첨부한 글을 참고해 설정해준다.

포트포워딩 & NAT Network 설정

시스템 설정 파일인 yaml 파일을 백업해둔다.

cd /etc/netplan

sudo cp 00-installer-config.yaml 00-installer-config.yaml.bak

sudo nano 00-installer-config.yaml

두 칸씩 들여쓰기에 주의하며 yaml 파일에 고정 IP 주소를 할당한다. 수정을 완료했다면 Ctrl+O로 덮어쓰고, Ctrl+X로 nano editor를 빠져나가면 된다.

sudo netplan try

(Enter)

sudo netplan apply

sudo systemctl stop network-manager

sudo systemctl start network-manager

sudo systemctl stop network-manager

sudo systemctl start network-manager

NetworkManager를 몇 번 재부팅 해 주고 난 뒤 인터넷 연결을 확인하기 위해 업데이트를 해본다.

sudo apt update

만약 여기서 인터넷 연결이 안 되었다고 나온다면 게이트웨이로 핑을 쳐 봐야 한다.

ping 10.0.2.1

ping 10.0.2.2

ping 10.0.2.3

이 정도로 확인해보면 첫 번째는 연결이 안 될 것이고 2번이나 3번에 핑이 닿는다면 아까 정적으로 IP 주소를 할당해 주었던 단계로 돌아가서 gateway4 부분을 수정해주고 이후의 과정을 수행하고 난 뒤 다시 업데이트를 해 본다.

sudo apt update

인터넷 연결이 정상적으로 되었다면 hostname을 수정한다.

cd $HOME

sudo nano /etc/hostname

위와 같이 설정하고 저장한다.

sudo nano /etc/hosts

위와 같이 두 번째 줄의 hostname을 변경하고 저장한다.

그리고 핑을 쳐서 호스트 네임이 정상적으로 인식되고 있는지 확인한다.

Client Tool로 접속하기 위해 SSH를 설치한다.

sudo apt install -y openssh-server

HOST를 잡아준다.

export HOST=docker-ubuntu

Firewall 설정은 생략했다.

그리고 클라이언트 툴(XShell, putty, SecureCRT 등)으로 접속한다.

127.0.0.1:105

Install Docker Engine

우분투 서버 환경 구성은 완료됐고 이제부터 Docker Engine을 설치한다.

Install Docker Engine on Ubuntu | Docker Documentation

아래 정리한 명령어들은 위의 문서에서 그대로 가져온 것이다.

복사, 붙여넣기로 진행하는 것을 추천.

sudo apt-get update 

sudo apt-get install ca-certificates curl gnupg lsb-release

echo \ "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu \ $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt install docker-ce docker-ce-cli containerd.io

sudo systemctl status docker

sudo docker version

sudo docker run hello-world

Lab 1 - Ubuntu, Git in Docker Container

아래 이미지와 같이 Base Image로 Ubuntu Server를 Pull & Run하고 그 Ubuntu 위에 Git을 Install 한다.

sudo docker pull ubuntu

sudo docker image ls

Run 명령어로 Pull 까지 한 번에 한다.

sudo docker run -it --name git ubuntu:latest bash

(i : Interactive, t : Tty)

apt update

apt install -y git

git --version

exit (도커 프로세스 종료)

sudo docker ps -a

sudo docker commit git ubuntu:git

sudo docker images

sudo docker run -it --name git2 ubuntu:git bash

git --version

exit

sudo docker rm git2

sudo docker rm git

sudo docker rm 7e1 (CONTAINER ID의 앞 3자리)

Lab 2 - Nginx Web Server in Docker Container

(관리자 로그인)

su -

docker search nginx

docker pull nginx

이미지 레이어 확인하기

cd /var/lib/docker/overlay2

ls -l

Nginx는 총 6개의 레이어로 이루어져 있음을 알 수 있다 (l은 디폴트).

Nginx를 Run해서 메모리에 프로세스로 올려 Container로 만든다.

docker run -d --name webserver -p 80:80 nginx:latest

이제 실제 OS인 Windows에서 브라우저를 열고 192.168.56.100:80으로 접속하면 Nginx 웹 서버가 나온다.

Summary

Intelligent Storage System은 최적화된 I/O 처리 능력을 제공하는 다양한 기능을 갖춘 RAID array이다.

• 많은 양의 Cache와 여러 개의 I/O Path를 갖고 있으며, 고도화된 알고리즘을 사용해 성능이 중요한 애플리케이션의 요구 조건을 충족시킨다.
• 가상 스토리지 프로비저닝과 자동 스토리지 티어링 같은 최신 기술과 플래시 메모리를 지원함으로써 스토리지 시스템의 성능과 확장성, 가용성의 한계를 한 단계 높였다.

Advantages of Intelligent Storage System

• Increased capacity
• Improved performance
• Easier data management
• Improved data availability and protection
• Enhanced business continuity support
• Improved security and access control

Data Request/Response Process

Intelligent Storage System은 기본적으로 위와 같은 구성을 가져 간다. Host가 스토리지로부터 데이터를 요청해서 받아 오는 것을 예시로 그 과정을 살펴보면

Request

Host에서 FC SAN(Fibre Channel Storage Area Network)을 통해 Front End의 Controller에 있는 Port(일반적으로 Controller 당 2개씩 있다.)에 연결되고 Cache에서 Back End로, 그리고 Back End에서 물리적 디스크들(스토리지)로 접근하여 요청받은 데이터를 확인한다.

Response

그 데이터를 Back End를 통해서 Cache로 보내고, 그 데이터가 Cache를 거쳐 갈 때 Cache에 저장되면서 Front End, Host까지 도달하게 된다.

이렇게 Cache에 저장된 데이터는 나중에 같은 데이터의 요청을 받았을 경우 매우 빠른 속도로 불러올 수 있다. 그냥 보기엔 요청을 받아서 스토리지까지 가는 과정에서 Cache는 그냥 통로 역할만 하는 것 같지만 실제로는 Cache 위에 요청받은 데이터가 올라와 있는지 확인을 하고 있다면(Hit) 바로 응답, 없다면(Miss) 물리 디스크로부터 받아와서 응답을 하는 것이다.

Cache Data Protection

Cache는 휘발성 메모리이기 때문에 전력이 끊기거나 어떤 장애가 발생하면 디스크에 커밋(캐시의 데이터를 물리 디스크에 저장)하지 않은 데이터를 잃게 된다. 그러한 위험을 줄이기 위한 방법이 바로 Cache Mirroring과 Cache Vaulting이다.

• Cache Mirroring
  • 캐시 기록을 독립적인 2개의 메모리 주소에 저장한다.
  • 캐시 장애가 발생하더라도 쓰기 데이터는 미러에 보존되어 있어 디스크에 커밋할 수 있다.
  • 쓰기만 미러링하기 때문에 이 방법은 사용 가능한 캐시의 활용도를 높일 수 있다.
• Cache Vaulting
  • 정전으로부터 데이터를 보호한다.
  • AC 전력이 복구될 때까지 배터리를 사용해 메모리에 전원을 공급하거나 캐시 컨텐츠를 디스크에 기록할 수 있다.
  • 지능형 스토리지 시스템에서는 많은 양의 데이터를 여러 디스크에 기록해야 하기 때문에 배터리의 전력만으로는 부족하다.
    • 그래서 정전이 발생하면 커밋되지 않은 데이터는 볼트 드라이브라는 전용 드라이브 세트에 덤프된다.

Seoul

en
!
configure table
!
!
!--Phase 1
!
crypto isakmp policy 1
  authentication pre-share
  hash sha 512
  encryption aes 256
  group 5
  exit
!
crypto isakmp key P@ssw0rd address 172.16.23.2 255.255.255.252
!
!
!--Phase 2
!
crypto ipsec transform-set seoul_01 esp-aes 256 esp-sha512-hmac
  exit
!
access-list 101 permit ip 192.168.10.0 0.0.0.255 192.168.30.0 0.0.0.255
!
crypto map VPN_to_Busan 10 ipsec-isakmp
  set peer 172.16.23.2
  match address 101
  set transform-set seoul_01
  exit
!
!
!--Apply on Interface
!
interface e0/0
  ip address 172.16.12.2 255.255.255.252
  crypto map VPN_to_Busan
  exit
!
ip route 192.168.30.0 255.255.255.0 172.16.23.2

Busan

en
!
configure table
!
!
!--Phase 1
!
crypto isakmp policy 1
  authentication pre-share
  hash sha 512
  encryption aes 256
  group 5
  exit
!
crypto isakmp key P@ssw0rd address 172.16.12.2 255.255.255.252
!
!
!--Phase 2
!
crypto ipsec transform-set busan_01 esp-aes 256 esp-sha512-hmac
  exit
!
access-list 101 permit ip 192.168.30.0 0.0.0.255 192.168.10.0 0.0.0.255
!
crypto map VPN_to_Seoul 10 ipsec-isakmp
  set peer 172.16.12.2
  match address 101
  set transform-set busan_01
  exit
!
!
!--Apply on Interface
!
interface e0/0
  ip address 172.16.12.2 255.255.255.252
  crypto map VPN_to_Busan
  exit
!
ip route 192.168.30.0 255.255.255.0 172.16.23.2

EVE-NG 웹 클라이언트에서 Node를 통해 Capture를 실행할 때 Wireshark에서 "end of file on pipe magic during open"라고 오류가 뜨는 경우가 있다. 이 문제는 두 단계로 간단히 해결할 수 있다.

먼저 C:\Program Files\EVE-NG\wireshark_wrapper.bat 파일을 메모장(관리자 권한)으로 연다.

그리고 아래와 같이 PASSWORD 부분을 본인이 EVE-NG 가상 머신에 설정했던 값으로 바꿔 준다.

이것만으로 해결이 되는 경우도 있고, 만약 안 된다면 cmd를 열고 putty.exe (본인의 EVE-NG VM Username)@(본인의 EVE-NG IP 주소)를 입력한다. 그러면 putty가 실행되며 키 값을 저장하겠냐는 팝업이 뜨는데 확인을 하고 putty 상에서 EVE-NG 로그인을 한 번 한 뒤에 putty를 닫으면 끝이다. 다른 툴을 사용해도 상관없지만 putty가 무료로 배포되고 설치도 간편하기에 사용했다.

RAID 개요

RAID란 간단히 정리하면 여러 개의 디스크 드라이브를 모아서 하나의 호스트에 연결해 사용할 수 있게 하는 디스크 관리 솔루션이다.

RAID가 처음 등장하게 된 배경은 1980년대 후반에 비즈니스 환경에서의 컴퓨터 사용이 늘어나고 새로운 애플리케이션과 데이터베이스가 대거 등장하면서 스토리지 용량과 성능에 대한 수요가 빠르게 증가함에 따라 낮은 비용으로 고성능의 스토리지를 이용하기 위해서였다.

때문에 RAID의 논문이 처음 발표되었을 당시엔 Independent(독립적인)가 아닌 Inexpensive(저렴한)이었지만 스토리지 기술이 점차 발전하면서 RAID 기술의 목적이 변화하고 실질적 비용도 저렴하다고 할 수 없게 되어서 변경되었다.

RAID의 구현 방법

RAID를 구현하는 방법으로는 Software RAID와 Hardware RAID가 있는데, 소프트웨어 방식은 CPU와 메모리 자원을 부가적으로 사용하기 때문에 전체 시스템 성능에 영향을 끼치고 운영 체제에 따라 호환성의 문제가 있을 수 있어 잘 사용되지 않는다. 하드웨어 방식의 경우는 호스트나 어레이에 전용 하드웨어 컨트롤러를 사용하게 되며, 주로 이(하드웨어) 방식으로 RAID를 구현한다.

RAID의 레벨 (표준 : 0~6)

RAID 0 : Striped array with no fault tolerance(내결함성)

RAID 1 : Disk Mirroring

Nested RAID (1+0, 0+1, etc.)

RAID 3 : 전용 Parity Disk가 있는 Parallel access array

RAID 4 : 전용 독립 디스크 액세스를 사용하는 Parity Disk가 있는 Striped array

RAID 5 : 분산 독립 디스크 액세스를 사용하는 Parity가 있는 Striped array

RAID 6 : Dual 독립 디스크 액세스를 사용하는 분산 Parity가 있는 Striped array

• Even-Odd(짝수 오드) 또는 Reed-Solomon 알고리즘을 통해 패리티를 계산한다.

RAID 7 : 향상된 데이터 I/O 작업 및 데이터 캐싱을 위한 실시간 임베디드 운영 체제 및 프로세서를 포함한다.

RAID의 기본적인 기술 3가지 : Striping, Mirroring, Parity

Striping : RAID 0

Striping은 Host에서 입력된 데이터를 RAID Controller에서 디스크 드라이브 갯수만큼 쪼개고(Strip) 각 디스크에 그 데이터의 조각(Stripe)들을 저장해 두는 기술이다. 여러 개의 디스크를 통해 병렬적으로 I/O가 가능하기 때문에 성능적 측면에서 유리하지만, 디스크 중 하나가 사용할 수 없게 되면 원래 데이터의 일부를 그대로 유실하는 것이기 때문에 내결함성 측면에서의 단점을 가지고 있다.

Mirroring : RAID 1

Mirroring은 Host에서 입력된 데이터를 RAID Controller에서 복제 과정을 거쳐 두 개의 디스크 드라이브에 각각 저장하게 된다.

하나의 디스크에서 데이터의 변경이 일어나면 다른 쪽의 디스크에서도 똑같이 데이터가 변하기 때문에 정적인 상태를 저장해두는 백업의 개념과는 다르다. 미러링은 원래 운용하던 디스크가 고장났을 경우 다른 하나로 계속 운용할 수 있게 한다는 내결함성을 보장하기 위한 장치라고 볼 수 있다.

Striping과는 달리 내결함성을 충족하지만 복제 과정에서 시간이 소요되기 때문에 쓰기(Input)의 속도가 떨어진다.

Parity : RAID 3

Parity는 Host에서 입력된 데이터를 RAID Controller에서 Parity값을 구하는 계산을 수행한 후 Parity값만을 저장할 Parity Disk에 구한 Parity값을 입력하고, 나머지 디스크에 Striping과 같이 데이터들을 쪼개서 저장한다.

이 Parity값을 통해 고장난 다른 디스크의 정보를 복구할 수 있지만 2개 이상이 동시에 고장나거나 Parity Disk 자신이 고장난 경우에는 복구가 불가능하다는 특징이 있다.

Nested RAID & RAID 5

Nested RAID (1+0)

Nested RAID는 일종의 하이브리드 RAID 방식으로 주로 RAID 0 + RAID 1이나 RAID 1 + RAID 0 조합을 사용한다. 0+1의 경우는 스트라이핑이 미러링보다 앞서 이루어지기 때문에 디스크 손상 시 복구하는 과정이 1+0 대비 복잡하고 특별한 이점이 없어 잘 사용되지 않는다.

1+0의 경우는 위의 그림과 같이 미러링이 먼저 이루어진 후 스트라이핑을 통해 데이터를 분산 저장하는 방식인데, I/O 처리 속도와 가용성 두 가지를 전부 챙길 수 있기 때문에 효율적이다.

RAID 5

RAID 5는 패리티 비트 활용 방식인 RAID 3의 확장형이라고 할 수 있다. RAID 3의 단점은 2개 이상의 디스크가 고장나거나 Parity Disk가 고장나게 되면 복구가 불가능하다는 것이었는데, RAID 5에서는 계산된 패리티 비트를 2개의 디스크에 나누어 저장함으로써 RAID 3보다 뛰어난 가용성을 가지게 되었다.

애플리케이션 IOPS 계산

애플리케이션의 RAID 레벨 결정

RAID 1+0

• 소규모, 랜덤 및 쓰기 작업이 많은(일반적으로 30% 이상 쓰기) I/O 프로파일을 사용하는 애플리케이션에 적합
• ex) OLTP, RDBMS

RAID 3

• 대규모 환경에서 순차적으로 읽고 쓰기 작업이 많은 환경
• ex) data backup, Multimedia streaming

RAID 5 / 6

• 소규모, 랜덤 워크로드(일반적으로 30% 미만 쓰기)
• ex) email, RDBMS

RAID Comparison

아래 표를 통해 각 RAID 별 필요한 최소 디스크 개수, 스토리지 효율 등의 정보를 확인하고 비교할 수 있다.

Hot Spare

핫 스페어는 고장난 디스크를 잠시 대신하기 위한, RAID 어레이에 있는 여분의 드라이브를 말한다.

• 패리티 RAID를 사용하는 경우 : RAID 집합의 살아 있는 디스크 드라이브의 데이터와 패리티로부터 데이터를 복구해 핫 스페어에 저장한다.
• 미러링 RAID를 사용하는 경우 : 미러의 데이터를 핫 스페어에 복사한다.

새 디스크 드라이브를 시스템에 추가하면 핫 스페어의 데이터를 새 드라이브에 복사한다. 데이터의 복사가 완료되면 핫 스페어는 다시 대기 상태로 돌아가고 다음 고장 드라이브를 대처할 준비를 한다.

위 그림으로 3가지 형태의 스토리지 사용 방식을 확인할 수 있다.

DAS (Direct-Attached Storage) : Block-level Access

DAS는 스토리지가 직접 호스트에 연결된 구성이다. 호스트의 내부 디스크 드라이브와 직접 연결된 외부 스토리지 어레이가 DAS의 예이다.

Internal DAS

• 스토리지 디바이스가 직렬 또는 병렬 버스로 호스트에 연결된다.

External DAS

• 호스트는 외부 스토리지 디바이스에 직접 연결되고 데이터는 블록 레벨로 액세스된다.
• 호스트와 스토리지 디바이스 간의 통신은 주로 SCSI나 FC 프로토콜을 사용한다.

Internal DAS와 비교해 External DAS는 디바이스 거리와 개수의 한계를 극복하며 스토리지 디바이스를 중앙 집중적으로 관리할 수 있게 해준다. 

DAS의 특징으로는 기본적으로 간단한 구성을 가지고 있으며 초기 투자 비용이 낮다는 점과, 저장 용량을 모두 사용했을 경우 확장이 어려워 서비스 가용성에 문제가 생길 수 있다는 점, 사용하지 않는 리소스를 재할당할 수 없기 때문에 많이 사용되는 Storage Pool과 적게 사용되는 Storage Pool이 나뉜다는 점이 있다.

SAN (Storage Area Network) : Block-level Access

SAN은 스토리지가 네트워크를 통해 호스트에 연결된 구성이다. 호스트에서 파일 시스템을 구동하고 있기 때문에 파일 ↔ 블록 변환은 호스트 측에서 수행하고, 네트워크 상에서 데이터는 블록 레벨로 교환이 이루어진다.

DAS와 비교했을 때 가장 큰 차이점으로는 역시 네트워크가 중간에서 중개 역할을 해주고 있다는 것이다. 때문에 DAS에선 스토리지의 포트 하나 당 호스트 하나만 연결이 가능하지만 SAN, NAS에서는 네트워크를 통해 수많은 호스트에게 연결될 수 있다.

SAN의 예로는 금융권 등 대규모 인프라 등이 있다.

NAS (Network-Attached Storage) : File-level Access

NAS 또한 SAN과 같이 스토리지가 네트워크를 통해 호스트에 연결된 형태이다.

하지만 NAS의 경우는 파일 시스템이 호스트 단이 아닌 스토리지 시스템 단에서 돌아가고 있기 때문에 호스트 측에선 파일 단위로 데이터를 송수신할 수 있으며, 스토리지 시스템 측에서 파일 ↔ 블록 데이터 변환을 수행해서 스토리지에 블록 형태로 저장한다. 때문에 호스트는 운영 체제에 구애받지 않고 스토리지를 이용할 수 있다.

이에 관한 내용은 다른 포스트에서 추가적으로 정리할 계획이다.

Application

• 애플리케이션은 컴퓨팅 연산의 로직을 제공하는 컴퓨터 프로그램이다.
• 데이터 센터를 이용하여 서비스되는 일반적인 애플리케이션 
  • Business Applications : email, enterprise resource planning(ERP), decision support system(DSS)
  • Management Applications : 리소스 관리, 성능 튜닝, 가상화
  • Data Protection Applicstions : backup(데이터를 보관하기 위함), replication(가용성을 위해서, 미리 복제해 준비해 둔 서버를 통해 문제가 생겨도 서비스가 중지되지 않게 함)
  • Security Applications : authentication, antivirus
• 애플리케이션의 주요 I/O 특성
  • Read intensive vs. Write intensive
  • Sequential vs. Random
  • I/O size

Application Virtualization

Isolated(독립된, 고립된) 환경에서 필요한 Application을 사용하도록 제공한다.

• 운영 체제와 리소스를 애플리케이션 가상화 컨테이너로 결합하여 제공한다.
• 가상화 애플리케이션은 독립 환경에서 실행되기 때문에 OS나 기타 애플리케이션은 잠재적인 위험으로부터 보호된다.
• 다른 응용 프로그램 또는 동일한 응용 프로그램의 서로 다른 버전 간의 충돌을 방지한다.

Logical Components (가상 애플리케이션 환경의 시스템 구조)

Traditional : 전통적인 방식으로는 하드웨어부터 Device Drivers, Volume Manager, File System, OS, Application 순으로 순차적으로 올라가는 방식으로 구성되며, OS가 직접 물리적인 엘리먼트들로부터 리소스를 가져와서 애플리케이션에게 제공한다.

Virtual Machines : VMware 등의 가상화 프로그램에서 애플리케이션을 구동하는 경우인데, 물리적 서버 윗단에 Hypervisor라고 하는 OS의 역할을 하는 소프트웨어가 자리 잡고 있으며 이 Hypervisor가 각 가상 머신의 GuestOS에게 물리적 서버에서 가져온 리소스를 전달하는 방식으로 제공한다. Hypervisor가 일괄적인 처리를 맡으며 실제 OS의 역할이 줄어들었기에 Traditional에 비해 OS가 가벼워지고 그에 따른 퍼포먼스 측면에서의 이점이 있다.

Containers : Docker 등의 컨테이너에서 애플리케이션을 구동하는 경우이다. Virtual Machines에서 한 단계 더 진화해 아예 GuestOS 조차 없애고 애플리케이션이 필요로 하는 리소스를 Docker Engine이 HostOS로부터 받아와 각 컨테이너에 할당해준다.

Device Driver → OS → Application

Device Driver는 OS로 하여금 물리적인 엘리먼트들을 인식하게 하는 소프트웨어이다. Device Driver를 통해 장치를 인식한 OS는 그 리소스들을 Application의 요청에 맞게 할당한다.

Memory Virtualization

메모리 가상화는 호스트의 물리적 메모리(RAM)를 가상화해주는 운영 체제의 기능이다.

가상 메모리 관리자(Virtual Memory Manager : VMM)가 디스크 스토리지에 있는 공간 중 일부를 사용해 스왑 공간(Swap space)으로 만들고 RAM에서 당장 실행 중이 아닌 프로세스들을 실제 메모리에서 스왑 공간으로 이동시킨다.

이로 인해 물리적 메모리의 효율적인 사용이 가능하고 디스크 스토리지의 놀고 있던 공간도 활용할 수 있게 된다. 만약 스왑 파일의 데이터 액세스 속도가 느려지게 되면 플래시 드라이브를 사용한다.

LVM(Local Volume Manager)

LVM은 파일 시스템과 물리 디스크의 중간에 있는 레이어로, Physical Volumes, Volume Groups, Logical Volumes로 구성되어 있다. 일반적으로 운영 체제의 일부 또는 타사 호스트 소프트웨어로 제공되며, 파일 시스템 용량을 동적으로 확장할 수 있고 효율적인 스토리지 관리를 할 수 있다는 특징이 있다.

Volume Groups

볼륨 그룹은 1개 이상의 물리 볼륨을 그룹화해서 만든다(고유 물리적 볼륨 아이디 할당). 이 볼륨 그룹으로 논리적 볼륨을 생성할 수 있으며 여기서 볼륨 그룹은 디스크, 논리적 볼륨은 디스크 파티션이라고 생각할 수 있다.

정리하자면 LVM에서 물리적 볼륨들을 모아 하나의 큰 pool을 만들고 그 pool을 구성하는 작은 block들로 논리적인 볼륨을 생성하고 애플리케이션에 할당하는 것이다. 또한 이렇게 만들어진 논리적 볼륨은 데이터 가용성을 높이기 위해 복제될 수 있다.

LVM을 통해 물리적인 볼륨을 Partitioning 또는 Concatenating해서 하나의 물리적 볼륨을 여러 개의 논리적 볼륨으로 분할하거나 여러 개의 물리적 볼륨을 하나의 논리적 볼륨으로 합치는 등의 작업을 할 수 있다.

File System

• 파일은 관련 레코드의 집합, 또는 이름을 가진 단위로 저장된 데이터를 말한다.
• 파일 시스템은 파일의 계층 구조를 말한다.
• 파일 시스템은 디렉토리를 이용해서 데이터를 계층 구조로 관리한다.
• 디렉토리는 여러 파일에 대한 포인터를 저장하는 컨테이너이다.
• 파일 시스템은 디스크 드라이브나 디스크 파티션, 논리적 볼륨에 저장된 데이터 파일에 액세스할 수 있게 한다.
• 파일 시스템은 논리적 구조와 파일 액세스를 조정하는 소프트웨어 루틴으로 구성한다.
• 파일 시스템 종류 : FAT 32, NTFS, UNIX FS, EXT 2/3

Compute Virtualization

컴퓨팅 가상화는 운영 체제로부터 물리적 하드웨어를 감추는 기술이다. 단일 또는 클러스터 머신에서 여러 운영 체제를 동시에 운영할 수 있다.

• 각 VM은 고립된 방식으로 운영 체제와 애플리케이션을 실행한다.
  • VM은 실제 컴퓨터처럼 보이고 행동하는 논리적 엔티티.
• 하드웨어와 가상 머신 사이의 가상화 레이어를 이용해 컴퓨팅 가상화를 실현한다. 이 레이어는 Hypervisor라고 불린다.
• Hypervisor는 CPU와 메모리, 네트워크 같은 하드웨어 리소스를 가상 머신에 제공한다. 물리적인 서버의 하드웨어 사양에 따라 한 서버 안에 많은 가상 머신을 만들 수 있다.
• Hypervisor의 관점에서 가상 머신은 VM 설정 파일과 데이터 파일 등의 독립적인 파일의 집합입니다.

Desktop Virtualization

데스크탑 가상화는 하드웨어와 OS, 애플리케이션, 사용자 프로파일, 설정 간의 의존성을 없애 준다.

조직이 데스크탑을 호스팅하고 중앙집중적으로 관리할 수 있다.

• 조직은 데이터 센터 안에서 가상 머신으로 데스크탑이 운영되기 때문에 유출이나 도난의 위험을 줄여준다.

데스크탑 가상화의 장점

• thin clients의 활성화 → 유연한 액세스
• 향상된 데이터 보안
• 간소화된 데이터 백업 및 PC 유지 관리

Connectivity

Connectivity란 호스트 간 또는 호스트와 프린터, 스토리지 디바이스 등의 주변기기와의 연결을 말한다.

연결은 다음과 같이 이루어진다.

Host Interface Card(Network Interface Card : NIC) ↔ Port ↔ Cable ↔ Port ↔ Disk

아래에서 대표적인 프로토콜 몇 가지를 알아보겠다.

IDE/ATA & Serial ATA(SATA)

• Integrated Device Electronics(IDE) / Advanced Technology Attachment(ATA)
  • IDE/ATA는 디스크 드라이브와 CD-ROM 드라이브 같은 스토리지 드라이브를 연결하는 데에 사용하는 인터페이스 프로토콜 표준이다.
  • 가격 대비 성능이 좋다.
  • 저렴한 비용으로 스토리지를 연결할 때 사용한다.
  • Internal Connectivity에 사용한다.
  • ATA의 Ultra DMA/133 버전은 초당 133MB의 전송량을 지원한다.
• Serial Advanced Technology Attachment(SATA)
  • IDE/ATA 직렬(serial) 버전은 단일 비트 직렬 전송을 지원한다.
  • SATA는 성능이 좋고 가격이 낮기 때문에 IDE/ATA를 대체하고 있다.
  • SATA 리비전 3.0은6Gb/s의 전송 속도를 제공한다. 
  • Hot-pluggable(장치를 제거하려면 PC를 종료해야 함)이다.

SCSI & Serial SCSI(SAS)

• Parallel SCSI(Small Computer System Interface)
  • 일반적으로 host와 peripheral device를 연결하기 위한 표준 방식이다.
  • IDE/ATA에 비해 가격이 높다. 개인용 데스크탑에서는 잘 사용되지 않는다.
  • SCSI는 하이엔드 컴퓨터에서 선호되는 연결 프로토콜이다.
  • SCSI는 1개의 버스에 최대 16개의 디바이스를 지원하고 데이터 전송 속도는 640MB/s (Ultra-640)이다.
• Serial Attached SCSI(SAS)
  • SAS는 포인트 간 직렬 프로토콜로, 병렬 SCSI의 대안이 되고 있다.
  • 새로운 버전의 직렬 SCSI(SAS 2.0)은 6Gb/s의 데이터 전송 속도를 지원한다.

Fibre Channel & IP

• Fibre Channel(FC)
  • 파이버 채널은 스토리지 디바이스에 대한 초고속 통신을 지원하는 프로토콜이다.
  • 동선과 광섬유를 통한 직렬 데이터 전송을 지원한다.
  • 파이버 채널 최신 버전의 표준에서는 속도가 최대 128Gb/s로 향상되었다.
    • 8, 16, 32Gb/s 버전도 사용 중
• Internet Protocol(IP)
  • 전통적으로 IP는 호스트 간 통신에 사용하는 네트워크 프로토콜이다.
  • 새로운 기술의 등장으로 IP 네트워크를 호스트와 스토리지 간의 통신에 사용할 수 있게 됐다.
  • IP는 비용과 기술의 성숙도 면에서 큰 장점을 지니고 있으며, 조직이 갖고 있는 IP 기반 네트워크를 사용할 수 있다는 장점이 있다.
    • iSCSI와 FCIP 프로토콜