[클라우드 인프라와 API의 구조] 6. 블록 스토리지 리소스를 제어하는 방법

1. 블록 스토리지 리소스의 제어를 위한 기본 API

1-1. 블록 스토리지 리소스

블록 스토리지 리소소는 크게 볼륨과 스냅샷 두 종류로 구분.

볼륨

• 실제로 서버에 연결되는 디스크를 의미
• 휘발되지 않고 영속적으로 보관되는 특징
• 반대로 이페머럴 디스크가 있음. (휘발성 디스크)

 

스냅샷

• 볼륨을 복제한 것
• 스냅샷 자체로는 서버에 직접 연결해서 쓰지 못함. (서버에 사용하려면 스냡샷을 다시 볼륨에 복원한 후, 서버에 연결해야 함.)
• 주로 백업이나 데이터를 이행할 때 사용됨.

 

1-2. 블록 스토리지와 API

과거의 물리적 인프라 환경에서는 스토리지를 증설하거나 설정하기까 상당히 까다로웠음.

반면 클라우드 환경에서는 API를 통해 제어.

 

1-3. 블록 스토리지를 제어하기 위한 API의 흐름

1. 인증
2. 생략
3. 볼륨 생성
   • 사용자는 오픈스택 내부의 실제 물리적인 스토리지 장치에 대해서 알 필요가 없음
   • API 실행시 주어진 옵션에 따라 적절한 볼륨이 생성된다.
   • 백엔드의 기능이 추상화되고 세부적인 처리는 숨겨지기 때문에 사용자 관점에서 API의 사용법만 익히면 인프라 구성을 어렵지 않게 할 수 있음.
   • 실행한 API는 POST를 사용한 리소스 제어이기 때문에 비동기로 처리됨.
4. 볼륨과 가상 서버의 연결
   • 볼륨이 만들어졌다면 볼륨을 가상 서버와 연결해야 하며, attach라고 한다.
   • POST 방식으로 API를 호출하면 이후 작업은 오픈스택 내부에서 가상 서버와 볼륨이 자동으로 연결되고 그 결과 가상 서버에서 볼륨 디스크를 사용할 수 있게 됨.

 

1-4. 볼륨 타입

• 블록 스토리지의 백엔드는 물리적 디스크이다. 따라서 디스크의 특성과 설정에 따라 I/O 특성도 달라진다.
• Amazon EBS를 사용하는 경우에는 물리적인 디스크의 사양 정보가 사용자에게 노출되지 않음.
• 그래서 AWS가 미리 정의해둔 디스크 타입에서 볼륨을 선택해야 한다.
• Magnetics 타입을 시작으로 범용적인 SSD(GP2), 혹은 IOPS를 지정할 수 있는 Provisioned IOPS까지 모두 세 종류의 블록 스토리지 중에서 원하는 것을 고를 수 있음.

 

1-5. 볼륨 사이즈

• 볼륨 사이즈는 볼륨을 생성할 때 결정.
• 블록 디바이스의 특성상 가상 서버의 OS에서 파일 시스템으로 인식되는 용량까지만 사용 가능.
• 리눅스의 ext4 파일 시스템이라면 resize2fs 명령으로 용량을 늘리거나 줄일 수 있음.

 

1-6. 스루풋, IOPS, SR-IOV

• 클라우드 환경에서는 가상 서버 리소스가 블록 스토리지로 접근하기 위해 네트워크를 통과해야 함.
• 따라서 백엔드 스토리지 자체의 성능도 중요하지만 가상 서버에서 블록 스토리지까지 연결되는 네트워크 성능 역시 중요.
• 이때 성능이 어느 정도인지 가늠하기 위한 지표로는 스루풋 (초당 전송 내역), IOPS (초당 input과 output 횟수)를 사용.
• 블록 스토리지는 네트워크를 경유해서 접근하기 때문에 시스템의 구성 방식이 원인이 되어 병목이 발생할 수 도 있음.
• 병목이 발생하거나 성능을 개선해야 한다면 IOPS나 스루풋을 튜닝하면 되지만 서버 측에서는 SR-IOV을 활용해야 할 때도 있음.
• SR-IOV는 가상화된 환경에서 여러 대의 가상머신이 하이퍼바이저를 통해 처리하던 것을 PCI 디바이스가 처리하도록 만들어 하이퍼바이저에서 발생할 수 있는 병목을 제거하는 기법.

 

1-7. 스냅샷, 백업, 클론

• 스냅샷은 특정 시점에 볼륨에 기록된 볼륨 단위의 데이터를 보존하는 것
• 저장 속도가 상당히 빠른 특징.
• 백업은 볼륨에 저장된 데이터를 내구성 높은 오브젝트 스토리지에 보존하는 것
• 클론은 볼륨을 직접 복제하는 것.
• Amazon EBS에서는 스냅샷을 만들기 위해 CreateSnapShot API를 실행하는데 내부적으로는 Amazon S3에 저장되어 사실상 백업을 하는 것과 같은 효과.
• Amazon EBS의 스냅샷은 블록 수준에서 만들어져서 같은 볼륨에 대해 두 번 이상 스냅샷을 만들면 앞에서 만든 블록에 대한 변경된 부분만 S3에 보내짐.
• 따라서 변경된 내용이 적을수록 백업 처리는 빨라지고 최종적으로 S3에 저장되는 형태는 처음 저장된 내용에서 바뀐 부분까지 병합하여 만들어짐.

 

1-8. 스냅샷과 이미지의 관계

• 이미지는 서버를 기동할 때 사용되는 반면, 스냅샷은 볼륨을 기동할 때 사용된다는 차이.

 

2. 블록 스토리지의 내부 구성

2-1. 블록 스토리지의 내부 구성

1. 가상 서버와 블록 스토리지의 연결
   • API를 통해 연결 요청이 접수되면 일단 메시지 큐에 요청 메시지를 넣게 되고, 이후 스케줄러가 하이퍼바이저를 선택하고 그 하이퍼바이저가 연결 처리를 하게 됨.
   • 좀 더 구체적으로, 하이퍼바이저 안에는 오픈스택 에이전트가 실행되고 있으며 이 에이전트 프로세스가 큐에 등록된 연결 요청 메시지를 꺼내간다.
   • 이때, 하나의 하이퍼바이저에서 끝낼 수 있는 작업이라면 에이전트가 그 하이퍼바이저에서 작업을 처리하게 한다. 하이퍼바이저 외에도 스토리지와 연결해야 하는 경우라면 블록 스토리지 리소스를 제어하는 엔드포인트를 통해 API를 호출하여 서버와 스토리지의 연결에 필요한 일종이 협상 과정을 시작함.

 

2-2. 서로 다른 인프라 리소스 간의 자동 협상

1. 볼륨 예약
   • 접속 요청을 받은 하이퍼바이저는 우선 스토리지의 API를 통해 사용할 볼륨을 예약함.
   • 이른바 락을 거는 것과 같은데 다른 연결 요청이 또 들어와 이중으로 연결되지 않도록 하기 위함.
2. 연결 준비
   • 하이퍼바이저 측의 정보를 스토리지 측에 전달하여 접속을 위한 준비를 함.
3. 실제 접속 처리
   • 가상 서버와 볼륨의 연결이 실제로 이루어짐.
4. 연결 성공 통보
   • 볼륨 연결이 성공하면 하이퍼바이저가 스토리지 측으로 연결 성공 사실을 통보
   • 이 API가 실행되면 볼륨 상태가 attaching → in-use로 변경되어 연결을 위한 처리 마무리