OpenStack (오픈스택)
- 클라우드 환경에서 컴퓨팅 자원과 스토리지 인프라를 셋업하고 구동하기 위해 사용하는 오픈소스 소프트웨어 프로젝트의 집합
- OpenStack은 Public 클라우드와 Private 클라우드 구축을 가능하게 하는 오픈 소스 SW
- OpenStack은 서버, 스토리지, 네트워크들과 같은 자원들을 모두 모아, 이들을 제어하고 운영하기 위한 클라우드 OS
- OpenStack은 오픈 소스를 기반으로 클라우드를 구축하고 운용하고자 하는 오픈 소스 개발자, 회사, 사용자들이 주축이 되어 발전하는 커뮤니티
- IaaS 형태의 클라우드 컴퓨팅 오픈 소스 프로젝트로 컴퓨팅, 스토리지, 네트워킹 자원을 관리하는 여러 개의 하위 프로젝트들로 이루어짐
OpenStack 두가지 주요 툴
DevStack
- 복잡한 오픈스택 시스템을 자동으로 설치하여 어떻게 동작하는 알기 위한 프로젝트
- 오픈스택을 처음 접하는 유저에게 추천
- 오픈스택 프로젝트의 All-in-One 설치를 제공, 어떤 구성요소들이 있는지 확인할 수 있음
PackStack
- 복잡한 오픈스택 시스템을 자동으로 설치할 수 있도록 도와주는 프로젝트
• DevStack과 비슷 - 하지만, 실제 서비스 운영도 가능 (작은 규모의 환경)
• DevStack은 스크립트 형태로 구동
OpenStack 구성 요소
- Nova → VM
- Swift → obj. stroage
- Glance → image
- Keystone → 사용자 인증 및 권한
- Horizon → 오픈스택 서비스들을 웹 기반으로 관리할 수 있는 대시보드(console)
- Cinder → block stroage
- Neutron → network
- Heat → 오픈스택 리소스의 오케스트레이션 및 자동화 서비스
- Ceilometer → 오픈스택 리소스의 모니터링과 메트릭 수집 서비스
우리가 쓰는 클라우드들은 이런 컴포넌트들을 가지고있다. AWS로 예를들자면 EC2,S3 등등
Horizon
- 오픈스택의 대시보드 서비스
- 웹 UI로 인스턴스 생성, 삭제, 관리 등을 쉽고 빠르게 처리할 수 있게 지원
- 아파치 웹 서버를 사용
- 대시보드는 Python과 Django 프레임워크로 구현
KeyStone
- 오픈스택의 인증 서비스
- 인증 토큰을 비롯해 테넌트 및 사용자 관리, 서비스의 엔드포인트 URL 등을 관리하는 아주 중요한 기본 서비스
- 도메인, 프로젝트, 그룹, 사용자, 롤의 관계
- API 요청
• 사용자가 Horizon UI를 통하거나 직접 요청을 보낼 때
• 일부 컴포넌트가 다른 컴포넌트에게 요청을 보낼 때
- API에 요청을 보내기 전 항상 인증 필요
• 사용자/컴포넌트는 API 요청 전 KeyStone으로 부터 API 동작에 대한 '토큰' 요청
Glance
- 이미지 서비스
- Nova에서 생성하는 인스턴스의 운영체제에 해당하는 이미지를 관리
Qcow2 디스크 이미지
- Qcow2 → 가상 머신을 위해 설계된 디스크 이미지 형식 (QEMU Copy on Write version2)
- 동적 블록 할당
• 실제 (물리적) 파일 크기는 논리 이미지 크기보다 작음
• 데이터가 추가될 때 파일이 커짐 (논리적 크기를 확장하는 것도 가능) - 오버레이 메커니즘
• 백업 이미지의 상단에 오버레이 파일을 추가
• 백업 이미지에서 추가 변경 사항만 보관 - 여러 스냅샷
• 이미지의 스냅샷을 생성하여, 이미지의 이전 내용을 재현하거나 스냅샷으로 부터 새로운 이미지 생성 가능
Cinder
- 블록 스토리지 서비스
- Nova에서 생성된 인스턴스에 확장해서 사용할 수 있는
저장 공간을 생성, 삭제하고 인스턴스에 연결할 수 있는 기능을 제공 - 기본적으로 iSCSI 기반 LVM 드라이버 사용
• 물리 볼륨 (Physical Volumes)
• 볼륨 그룹 (Volume Groups)
Nova
- Compute 서비스의 핵심
- 하이퍼바이저, 메시지 큐, 인스턴스에 접속하는 콘솔 등 다양한 기능이 유기적으로 연결되어 가상 서버를 생성할 수 있는 시스템을 구성
노바는 compute하는 엔진인데 compute하기위해 이미지도 필요하고 볼륨도 필요하고 네트워크도 필요하고 등등 다양한것들을 해야한다. 그러한 엔진들이 Queue를 둘러싸서 존재를 하고 최종적으로 레디가 되면 하이버바이저에 의해서 설정이 끝나게 되는
- 오픈스택에서의 기본 하이퍼바이저는 KVM과 QEMU
- 추가적으로 Hyper-V, VMware ESXi, Bare metal, Docker, LXC 등 지원 가능
Nova with 블록 볼륨
1) 사용자 또는 시스템이 새로운 볼륨을 생성한다. 이 볼륨은 저장 공간에서 독립된 블록 단위로 사용될 수 있다.
2) 생성된 볼륨은 가상 머신(OS)에 연결되어, 사용자 데이터를 저장하는 데 사용된다. 여기서 볼륨이 가상 머신에 어떻게 연결되는지가 중요하다.
3) 사용 중인 볼륨의 상태를 스냅샷으로 저장하여, 이후 언제든지 해당 상태로 볼륨을 복원할 수 있다. 스냅샷은 데이터의 백업 및 복구 프로세스에서 중요한 역할을 한다.
4) 기존 스냅샷에서 새로운 볼륨을 생성할 수 있으며, 이 볼륨을 다른 인스턴스에서 사용하거나 추가적인 백업으로 활용할 수 있다.
Neutron
- 네트워크 서비스
- 기존의 네트워크 서비스는 nova-network가 담당
- SDN 개념이 들어오면서 별도의 네트워크로 프로젝트 분리
- Fixed IP
• 인스턴스가 생성된 이후 종료될 때까지 변하지 않는 IP - Floating IP
• 서비스를 위해 필요에 따라 인스턴스에 연결/해제하는 IP
스케일이 커질수록 direct로 연결하는 것이 없어지고 Queue를 통해 연결된다.
- 각 테넌트는 가상 라우터를 소유
• 테넌트 사용자들은 라우터 아랫단에 가상 스위치들을 추가하고 사설 서브넷 주소를 할당 (서브넷은 다른 테넌트와 중복 사용 가능) - 인스턴스를 시작할 때 사용자는 연결할 가상 스위치를 선택
• 인스턴스의 가상 NIC들의 수는 연결할 스위치의 수에 해당
Neutron – Provider Network
Provider 모델의 경우 IP 대역 공용으로 VM을 만들면 실제 물리 네트워크에 속한 IP(ex 학교IP)를 직접 할당받는다. 그렇다는 얘기는 다이렉트로 서비스를 할 수 있고 속도가 빨라지고 대규모 클라우드 환경에서 효율적인 리소스 관리가 가능하다.
Neutron – Self-Service Network
각각의 개인 사용자들마다 별도의 IP 대역을 가지고 독립적으로 네트워크를 관리한다. 중간에 납세를 해서 보내는 일반적인 구조이다. 네트워크를 격리하는 과정에서 VXLAN을 활용할 때 여러 문제들이 발생할 수 있다. (ex hop으로 인한 지연시간 증가, 확장성 문제 등) 즉, 느려진다.
Neutron
- 가상 네트워크 생성의 실제 작업은 플러그인 Agent가 수행
• 벤더들의 상용 제품을 포함해서 Neutron을 위한 다양한 플러그인 제공
• 표준/참조 구현으로 'LinuxBridge 플러그인'과 'Open vSwitch 플러그인' 제공
Neutron - Internals
- 일반적인 네트워크 구성
• 네트워크 노드의 L3 Agent는 사설 및 공용 네트워크를 연결하는 가상 라우터 기능을 제공
기본적으로 피지컬 네트워크 인터페이스는 트래픽 분리, 성능 향상을 위해 두개 이상을 사용한다. (ex eth0은 관리 트래픽용, eth1은 공개 인터넷 트래픽용, eth2 내부 네트워크 트래픽용)
Neutron - Open vSwitch
qvoXXX, qvoYYY, qvoZZZ, qvoWWW: 가상 인터페이
br-int (Integration Bridge): 모든 내부 VM 트래픽이 통과하는 중앙 가상 스위치.
int-br-priv (Private Bridge Interface): 개인 네트워크를 위한 내부 브리지 인터페이스.
phy-br-priv (Physical Bridge Interface): 물리 네트워크를 위한 외부 브리지 인터페이스.
br-priv (Private Bridge): 실제 네트워크 연결을 처리하는 최종 브리지.
가상 머신(VM)과 물리적 네트워크 간의 네트워크 연결을 관리하는 방법을 보여준다. 여기서 Open vSwitch를 사용하여 네트워크 트래픽을 분류하고, 다양한 VLAN 태그를 사용하여 트래픽을 격리한다.
VM의 IP부분에서 Provider or Self 에 따라 IP가 달라진다.
Open vSwitch는 이러한 복잡한 네트워크 연결과 관리를 가능하게 하는 강력한 도구
VM1, VM2 같은경우에 외부와 통신하려면 그과정이 너무멀다. 하지만 그렇다고 모든 노드에 external을 붙이게되면 관리가 어려워진다. (ex 방화벽관리, 사용자 접근권한관리 등등)
실제로 서비스를 운영한다 했을 때 Compute를 위한 노드와 네트워크를 위한 노드를 분리하여 성능 최적화를 한다.즉, 컴퓨트 노드는 CPU와 메모리 자원을 주로 사용하는 가상 머신의 처리와 실행을 담당하고 네트워크 노드는 네트워크 트래픽의 라우팅, IP 주소 할당, NAT 설정 등 네트워크 관련 작업을 처리
Neutron - VRRP
- VRRP (Virtual Router Redundancy Protocol)
• LAN에서 정적으로 설정된 기본 라우터를 사용할 때, 하나 이상의 백업 라우터를 사용하는 방법을 제공하는 인터넷 프로토콜 - DVR (Distributed Virtual Router) → 분산 라우팅 + HA 로드밸런싱
Swift
• 오브젝트 스토리지 서비스
Optional Services (그외 서비스들)
- 오픈스택은 관리와 운영에 도움을 주는 많은 서비스를 제공
- 기본적으로 KeyStone, Horizon, Nova, Glance, Neutron 만으로도 구축 가능
• 추가로 Cinder, Swift와 같은 스토리지 서비스 포함 가능 - 추가 서비스를 제대로 사용하면, 효율적인 클라우드 관리 및 운영 가능
• 텔레미터, 오케스트레이션, 데이터베이스 등
Ceilometer
- 클라우드에서 배포된 자원의 사용량과 성능을 측정해 사용자가 자원 상태를 모니터링할 수 있는
기능을 제공 - 분산된 클라우드 시스템의 자원 상태를 모니터링해 가시성과 통찰력을 제공하고 자원 통계를
확인할 수 있음
Heat
- 자원 관리, 배치, 정렬을 자동화하는 오케스트레이션 서비스
- 클라우드 컴퓨팅 서비스에서 인스턴스 하나를 생성하려면?
• 인증 키를 발듭받아야 하고, 네트워크가 생성되었는지 확인해야 하며,
• 보안 롤(Role)도 미리 생성해야 하는 등 일련의 과정이 끝나야 생성 가능 - 오케스트레이션은 이런 일련의 과정을 자동화해서 인프라를 쉽게 배포할 수 있도록 지원하는 템플릿 기반 엔진
• 템플릿 언어를 통해 인프라는 물론 서비스와 응용 프로그램 전체 프로비저닝(Provisioning)을 자동화하고 컴퓨팅, 스토리지, 네트워킹 구성 뿐만 아니라 배포 후 작업도 지정 가능 - 텔레미터 서비스와 통합해서 특정 인프라 요소의 자동 스케일링 가능
Trove
- 오픈스택의 데이터베이스 서비스 (관계형 데이터베이스)
- 클라우드 사용자와 데이터베이스 관리자는 필요에 따라 Trove를 이용해 데이터베이스 인스턴스를 제공, 관리할 수 있음
Sahara
• 오픈스택 위에 빅데이터 App인 Hadoop이나 Spark를 쉽게 제공할 수 있게 도와주는 서비스
Magnum
- 오픈스택 컨테이너 팀에서 개발한 오픈스택 API 서비스
• Docker Swarm, Kubernetes, Apache Mesos 같은 컨테이너 플랫폼 연동 - Docker 및 Kubernetes가 포함된 OS 이미지를 생성하려고 Heat를 사용
오픈스택 활용 사례: ToastCloud
- 2014년, 게임 회사를 주요 고객으로 하는 클라우드 서비스로 시작
오픈스택 활용 사례: Kakao Cloud
- Krane
• Crane [krein] : 기중기, 크레인 (Kakao + Crane)
• 오픈스택 기반의 카카오 Private Cloud
'CS > 클라우드 컴퓨팅' 카테고리의 다른 글
[클라우드] 10. Public Cloud (AWS, Azure, GCP) (0) | 2024.05.26 |
---|---|
[클라우드] 9. MSA (MicroService Architecture) (1) | 2024.05.16 |
[클라우드] 8. 스토리지 가상화 (Storage Virtualization) (0) | 2024.05.10 |
[클라우드] 7. 현대 네트워크 가상화 (Modern Network Virtualization) (1) | 2024.05.01 |
[클라우드] 6. Kubernetes (쿠버네티스) (0) | 2024.04.17 |
댓글