클라우드 리소스와 제어 방법(1)
참고 자료
오픈 스택을 처음 공부하는 사람이라면, 아래 책을 꼭 읽어봤음 좋겠다!
→ 많은 도표로 쉽게 잘 설명되어 있다!! 강력 추천~
위에 자료들을 보고 공부하며 정리한 내용입니다. 혹시 수정이 필요한 내용이 있으면, 댓글 달아주시면 감사하겠습니다 😊
🤔 이 글은 다음 질문으로 시작되었습니다
[ 가상화된 온-프레미스 환경 → 클라우드 리소스와 API 를 사용한 서버 ]
이런 형태의 인프라 전환이 이루어지고 있는 이유는 무엇일까 ?
목차
[IT 인프라의 변화]
- 물리적 환경
- 서버 가상화 환경
- 클라우드 환경[IT 인프라 리소스]
* 구성요소
* API의 역할
* API 동작원리
1. 서버 리소스
2. 블록 스토리지
3. 네트워크 리소스+ 더 알아보기: 분산시스템 기초
IT 인프라의 변화
물리적 환경
- 성능, 가격, 확장성 등의 요구사항을 따져 사양을 선택함
- 랙(rack) 에 장비 탑재
(빈 공간, 네트워크 스위치의 포트, 케이블 배선, 전원 용량 허용 범위, IP 주소) - OS 와 어플리케이션 설치, 환경 설정 작업
(App 개발 팀이 요청한 설정 내용에 따라 작업 계획서 작성) - 설계대로 잘 구축 되었는지 테스트
→ 필요한 계정이나 권한 정보 App 개발팀에 전달
→ 새로 도입한 서버에 대한 정보를 자산 관리 대장에 갱신
서버 가상화 환경 [ 물리적인 작업 자동화 ]
- 가상 서버를 실제로 배치할 물리적인 호스트의 사양을 선택
- 가상 네트워크의 구성 정보를 확인하면서 사용가능한 IP 주소를 할당
→ 애플리케이션 개발 팀이 요청한 설계에 따라 작업 계획서 작성 - 기존 템플릿 에서 가상 서버를 복제하여 구동
- 작업 계획서에 따라 각종 SW 설치 및 설정 작업을 하고 최종 확인 테스트
→ 물리적인 작업이 없어짐: 서버 설치 및 랙 작업, 케이블 배선 작업
→ 서버 가상화로 고려 사항이 바뀜: 가상 서버에 할당할 리소스를 선택
→ 가상 서버를 물리서버에 할당하는 방식: 가상 서버가 필요로 하는 사양에 따라 달라짐 (소프트웨어적인 요구사항을 고려하여 작업하는 방식)
→ 서버 가상화로 작업 방식이 달라짐: OS 설치 DVD 를 넣고 설치와 환경 설정 작업 (기존 물리 환경) → 필요한 소프트웨어가 미 설치되고 기본적인 설정까지 완료돤 템플릿을 복제
- 서버 가상화를 위한 기반 인프라를 한번 구축해두면, 향후 발생할 물리적인 작업량이 전체적으로 줄어든다.
- 물리적인 작업잉 소프트웨어 작업으로 대체되는 부분을 제외하면, 그 이전에 필요한 준비 작업의 양은 줄어들지 않음
클라우드 환경 [ 사람의 판단과 수작업 자동화 ]
- 인스턴스 유형 [Flavor] 선택
→ Flavor : CPU 의 개수나 메모리, 가상 디스크의 용량 등 미리 설정한 것
(서버 사양의 템플릿)
→ 사양을 정하기 위한 의사결정 속도가 빨라진다. [서버 리소스 단가와 의사결정 인건비의 Trade-Offs]
→ 가상 서버가 자동으로 배치[배치할 호스트를 정할 필요 없음]
→ 동적 DNS와 같은 메커니즘으로 IP 주소를 추상화. 동적으로 IP 주소가 할당되더라도 도메인을 통해 연결이 가능. [IP 주소 할당과 회수의 자동화] - 설정 스크립트: 최초 기동시에 일괄 처리
→ 스크립트가 또 다른 구성 관리 툴을 실행하거나 설정 내용에 문제가 없는지 테스트하는 툴을 실행하기도 함
→ 반복해서 재현 가능 및 실수 없이 작업(자동화된 검증 툴) - 가상 서버를 생성하는 명령 실행
→ 클라우드 API 의 본질: 사람의 판단과 수작업을 대체 (자동화, 효율화)
1. 서버 리소스
구성 요소
- 타입: 크기나 속성을 몇가지 유형으로 정리한 것
(오픈스택 Nova — Flavor, Azure, AWS: 인스턴스 유형) - 이미지: 서버의 기동 이미지
(오픈스택 Glance, AWS AMI)
API 의 역할
- 오픈 스택에서 모든 관리 대상 객체에 고유한 UUID 가 부여
- 인증
[ POST ] 사용자 정보 → Token, Endpoint 에 대한 정보 - 템플릿 이미지의 유효성 검증
[ GET ] Nova 의 접속 정보, tenant_id, image_id → 사전검증 - 가상 서버의 생성
[ POST ] 생성할 가상 서버의 조건 정보 → UUID
(API 로 생성 요청을 접수하는 처리와 요청에 따라 실제로 가상 서버를 생성하는 처리가 비동기적으로 분리되어 실행) - 생성된 가상 서버의 상태 확인
[ GET ] UUID → 가상 서버에 대한 상세 정보
- 가상 서버 환경 설정에 필요한 데이터
→ 메타 데이터: 서버 관리 정보, 사용자가 임의로 정한 데이터
(서버 별로 따로 만들어짐. 자동화 스크립트, 구성 관리 정보)
→ 사용자 데이터: 가상 서버에 액션을 실행해야 할 때 사용
(ex. 쉘 스크립트, Cloud-init 으로 Rule 기반으로 정의) - 이미지
→ 디스크 포맷이나 디바이스 매핑과 같은 구성 정보
→ 공개 여부 속성
API 동작 원리
- 오픈스택 내부에서 모든 처리가 메시지 큐를 통해 비동기로 이루어짐
[ AMQP(Advanced Message Queue Protocol) ]
- 가상 서버 생성 요청 메시지를 [메시지 큐]에 넣은 후, 구성관리DB 에 현재 상태를 기록 (status: ‘BUILDING’)
- [스케줄러]에 요청 전달: 큐에서 요청메시지 꺼냄, 가상 서버 생성 준비
→ 호스트들이 상태를 확인하고 가상 서버를 생성할 곳을 결정
[상태관리DB ← 주기적으로 호스트 리소스의 사용 현황을 통보]
( → 스케줄러 프로세스를 다중화하여 처리하여 가용성을 높임) - 가상 서버를 기동할 호스트 결정 및 서버 기동 지시
1) 서버를 생성할 호스트를 지정하고 가상 서버 생성 요청 메시지를 큐에 넣음 [스케줄러 → 메시지큐]
2) 가상 서버를 만들기로 한 호스트가 큐에서 요청 메시지를 꺼내고 가상서버 기동 [메시지큐 → 호스트(하이퍼바이저)] - 메시지 수신과 가상 서버의 생성
→ 다양한 작업: 기동할 템플릿 이미지를 가져오고 가상 서버에 할당할 IP 주소를 확보, 지정한 네트워크에 접속하기 위한 준비 등 - 구성관리 DB 갱신(status: ‘ACTIVE’)
2. 블록 스토리지
- 과거 물리적 스토리지를 설계할 때는 디스크 영역을 확보하기 위해 LUN(Logical Unit Number이 필요) → RAID 구성이나 LUN 을 매핑하는 과정이 필요, 장비마다 제조사의 독자적인 기능이나 설정을 사용하기 위해 사람의 판단과 수작업이 필요
- 클라우드를 사용할 때는 볼륨 용량과 접속할 가상 서버를 지정하기만 하면 된다. 볼륨을 제공할 물리적인 스토리지 장비의 선택부터 볼륨을 생성하고 가상 서버와 연결하기까지의 모든 작업이 자동화 되어 있기 때문
- 과거
서버) 볼륨과의 연결 방식, OS에서의 인식 방식
볼륨) 볼륨의 생성 방법, 할당할 LUN(Logical Unit Number), 매핑할 WWN(World Wide Name)
구성 요소
- 볼륨: 실제로 서버에 연결되는 디스크
→ 휘발되지 않고 영속적으로 보관.
→ 휘발성 디스크(ephemeral disk)도 있음
→ cf. ephemeral disk: 서버 리소스 안에 기본적으로 포함되어 있고, 가상 머신 이미지에 용량이 정의되어 있다. - 스냅샷: 볼륨을 복제한 것
→ 서버에 사용하려면 일단 스냅샷을 다시 볼륨으로 복제한 후, 연결
구성요소
- 볼륨 타입: 디스크의 특성과 설정 & I/O 특성
- 볼륨 사이즈: GB, OS 에서 파일시스템으로 인식되는 용량까지 사용 가능
→ 볼륨은 디바이스 단위로 연결되기 때문에 OS에서 여러 디바이스를 사용한 소프트웨어 RAID를 구성할 수 있다.
API 의 역할
[ 볼륨 ]
- Cinder Scheduler: 백엔드 스토리지를 결정 → 필터(타입으로 필터링) & 백엔드 스토리지의 남은 용량에 가중치를 적용한 값을 사용
- 볼륨의 생성[ Cinder ]
[ POST ] 볼륨 용량 및 다양한 옵션 → 생성된 볼륨의 UUID 정보 - 볼륨과 가상 서버의 연결(attach)
[ POST ] Nova의 접속 정보, 가상 서버 ID, 볼륨의 UUID → 비동기 처리
- 가상 서버에서 블록 스토리지까지 연결되는 네트워크 성능도 중요
→ Throughput(초당 전송 대역), IOPS(초당 Input과 Output의 횟수)
→ 백엔드 스토리지의 성능이나 네트워크의 물리적인 사양이 뒷받침 - 보통 SSD 타입에서 IOPS를 올리고 싶다면, 용량을 많이 할당하여 IOPS를 높이는 방법을 씀
→ 3TB를 넘어서면, IOPS가 상한에 이르러 더 이상 늘어나지 않음
→ 이미 3TB 까지 늘린 상태라면 볼륨을 분할하는 것이 IOPS면에서 유리 - SR-IOV(Single Root I/O Virtualization): 하이퍼바이저에서 발생할 수 있는 병목을 제거 → PCI(Peripheral Component Interconnect)디바이스 처리 (NIC에서 오는 명령을 PCI 가 하드웨어 수준에서 병렬 처리)
[ 스냅샷, 백업, 클론 ]
- 스냅샷: 특정 시점에 볼륨에 기록된 블록 단위의 데이터를 보존하는 것
(저장 속도가 상당히 빠름) - 백업: 볼륨에 저장된 데이터를 내구성이 높은 오브젝트 스토리지에 보존
- 클론: 볼륨을 직접 복제하는 것
API 동작 원리(가상 서버와 볼륨 연결)
스토리지를 제어하는 에이전트가 메시지 큐에서 요청 메시지를 꺼낸 후, 작업
- 가상 서버와 블록 스토리지의 연결 요청
[ 가상 서버 API → 메시지큐(스케줄러) → 하이퍼 바이저(오픈스택 에이전트)] - 블록 스토리지와의 연결 준비
[ 블록 스토리지 API → 메시지큐(스케줄러) → 블록 스토리지(오픈스택 에이전트)]
→ 협상 과정이 필요
1) 볼륨 예약: 락(Lock)을 거는 것과 같음(이중으로 연결 막기)
→ 볼륨 상태: ‘available’ → ‘attaching’
2) 볼륨의 연결 준비를 요청
3) 실제 접속 처리
4) 연결 성공 통보 → 볼륨 상태 ‘attaching’ → ‘in-use’ - 실제 연결 처리
주의사항
- 블록 스토리지 API 장점: 특정 스토리지 제품의 하드웨어나 소프트웨어의 차별성에 신경 쓰지 않아도 됨(추상화)
- 블록 스토리지 API 단점: 특정 스토리지 제품만이 가진 고유의 기능 무시
- 최근에는, 스토리지의 고도의 기능들은 OS 의 파일 시스템이나 논리 볼륨 기능으로 대체가 가능
- API를 어떤 기능과 연계하면 더 안전하고 효율적인 시스템을 만들지,
어떻게 자동화를 할 수 있는지 고민하고 설계해보는 노하우가 필요
3. 네트워크 리소스
- 클라우드 환경에서도 네트워크는 기본적으로 TCP/IP 기반
- L2 네트워크: 같은 네트워크에 속한 장비끼리 연결
- L3 네트워크: L2네트워크 연결(클라우드의 내부와 외부를 연결하는 기능)
- IP 주소 관리 기능 (ex. IP주소 할당 → DHCP 를 통해 할당)
[ 서브넷을 식별할 수 있는 네트워크 부 + 서브넷 안에서 개별 통신 장비를 식별할 수 있는 호스트 부 ]
(서브넷 마스크: 네트워크 주소의 비트 길이를 표시한 것)
(CIDR: 고정 길이의 서브넷 마스크 결정 방식 대신 가변길이 결정 방식)
(Classless Inter Domain Routing) - 기능 매핑: L2 서브넷 기능(가상 스위치) + 서브넷 연결하기 위한 라우팅 기능(가상 라우터) + 서버를 네트워크에 연결하는 논리포트 기능
- AWS, Azure 는 한 테넌트에 가상 네트워크를 여러개 가능(논리적 구성)
구성요소
- 스위치와 서브넷
가상 스위치: L3 네트워크에서 사용하는 IP 주소 범위를 ‘서브넷’이라는 이름으로 할당
서브넷: 서브넷에 연결된 서버는 DHCP를 통해 IP 주소를 할당받고, 그 IP주소로 통신하게 된다. [ 고정 IP(할당된 IP 주소에만 통신 허용) ] - 라우터
1) 내부(클라우드) → 내부
테넌트 내부 or VPC 내의 네트워크
다른 테넌트의 네트워크와 통신: Peering, Neutron의 네트워크 공유 기능
2) 내부 → 외부
IP 마스커레이드(사설 IP 주소 → 공인 IP 주소)
3) 외부 →내부
플로팅 IP: 해당 IP를 자유롭게 할당하고 회수 할 수 있음
(공인 IP를 address pool에 확보한 다음, 서버의 논리 포트에 할당)
(NAT: network address translation → 공인IP의 주소 풀은 리전별로 관리) - 포트
Neutron 논리포트: 가상저인 스위치의 접점
AWS Elastic Network Interface: 네트워크 연결을 위한 인터페이스 접점
→ 생성될 때, 자신이 소속된 가상 서브넷으로부터 IP 주소를 할당
→ 가상네트워크&가상라우터를 연결하기도 함(가상 서브넷 게이트웨이) - 시큐리티 그룹
가상 서버에 들어가고 나가는 트래픽(패킷)을 필터링
→ Stateful, 암묵적 접근 금지 - 네트워크 액세스 컨트롤 리스트(NACL)
명시적으로 패킷 필터링을 하거나 권한을 분리
→ Stateless, 암묵적 접근 허가
API 의 역할
[ 네트워크 구성 ]
- [POST] 가상 네트워크 생성
- [POST] 서브넷 생성
- [POST] 논리 포트 생성 (미리 IP 주소 할당)
- [POST] 가상 라우터 생성
- [PUT] 가상 라우터와 서브넷을 연결
- [PUT] 가상 라우터와 외부 네트워크의 연결
[ 네트워크 안에 서버 할당 ]
- [POST] 하나의 가상 네트워크를 지정하고 가상 서버를 구동
- [GET] 가상 서버 생성 준비
- [POST] 논리 포트 생성 요청(IP주소 할당)
→ 가상 서버 준비
→ 가상 서버 연결 준비(IP 스푸핑 대책 설정, 시큐리티 그룹 설정) - [POST] 논리포트 연결 준비 완료 통보(다른 리소스와의 연계처리)
- 가상 서버 구동
API 동작 원리: 클라우드 환경에서 네트워크 제어 방법
- 가상 네트워크를 제어하는 프로세스
사용자는 컨트롤러 노드에 가상 서버나 가상 네트워크에 대한 제어 요청을 보내고, 컨트롤러 노드에서는 접수한 요청에 대해 nova-api, neutron-server, 다른 오픈스택 프로세스들과 연계하면서 컴퓨트 노드를 제어 - 네트워크 식별
가상 서버에서 전송되는 패킷은 연결된 가상 인터페이스를 보고, 자신이 어떤 네트워크에 속해 있는지 알 수 있습니다.
→ VLAN ID를 패킷에 할당
→ OVS의 브릿지: br-init(리눅스의 가상 인터페이스로 연결), br-tun(노드 사이에서 패킷을 전송하는 역할: 패킷을 보낼 때 VXLAN 이 사용(L3 네트워크 상에 논리적인 L2 네트워크 구성하는 터널링 프로토콜))
주의점
- 물리적 인프라 환경과 클라우드 환경간의 변화 폭이 큼
- 대역이나 MTU(패킷 사이즈) 등을 고려한 설계나 트러블 슈팅도 고려할 필요가 있음
SDN(Software Defined Networking)
- 구성요소: 네트워크 컨트롤러, 네트워크 오케스트레이터, 네트워크 장비
- 제어 담당인 컨트롤러와 전송을 담당하는 데이터 플랜을 서로 분리하여 API를 통해 이들을 제어
- 네트워크 장비: 외부에서 장비를 제어할 수 있도록 드라이버에서 API 제공
- 네트워크 오케스트레이터: 네트워크 장치를 통합적으로 제어해서 가상화
- 네트워크 컨트롤러
1) 사용자에게 일관된 API 모델 제공
2) 가상 네트워크를 동작시키기 위해 태스크 컨트롤러
→ 컴퓨트 등의 다른 크라우드 리소스와의 연계
→ 테넌트의 권한 관리
- Image와 Snapshot: 직접적인 관계가 없는 것처럼 보이지만, 속성으로 연결
→ Image를 사용해서 서버 기동: 서버를 기동할 때 사용 ( 여러개의 스냅샷을 함께 다루며, 블록 디바이스와의 매핑 관계도 정의할 수 있다 )
→ Snapshot을 사용해서 서버 기동: 볼륨을 기동할 때 사용 - NFS 서비스: 여러 대의 서버가 하나의 볼륨을 공유하는 형태
→ 다른 Region의 스토리지는 연결할 수 없다
→ NFS 프로토콜로 마운트 하는 방식: 접속 인터페이스, managed share storage 제공
더 알아보기
클라우드는 분산 환경에서 이루어집니다. 따라서, 분산환경에 대한 기본적인 것들을 다루는 다음 시리즈 글을 추천합니다!
