Nova
-
Nova는 Swift와 함께 OpenStack의 두 가지 Original 프로젝트 중 하나로, OpenStack의 컴퓨트 서비스를 제공
-
Nova는 인스턴스 수명 주기를 관리하며, 가상 머신의 생성, 크기 조정, 종료 등의 작업을 수행
-
Openstack은 일반적으로 Standard HW 위에서 빌드되고 수평적으로 확장가능하게 설계됨
- Nova도 이와 마찬가지의 개념을 공유
- 만약 Scale Up하고 싶다면, Nova를 다른 서버에 설치하고 Openstack Cluster의 일부로 만들면 됨
-
Nova는 그 자체로 Hypoervisor는 아니지만 이러한 Hypervisor들을 지원하고 manage
- 하지만 Hypervisor와 API를 통해 통신하거나, Hypervisor 위에 설치되어야 하는 agent를 지니고 있음
- agent를 활용하면 Nova는 hypervisor들과 Integrate될 수 있음
-
Nova는 여러개의 Hypervisor들을 활용해 Cloud를 Orchestrate할 수 있음
- 멀티 하이퍼바이저 환경에서도 통일된 API를 통해 일관된 관리 인터페이스를 제공
- 클라우드 인프라의 리소스를 논리적으로 나누고 구성하기 위한 단위로
Zone을 사용
Supported Hypervisors
-
Nova는 KVM, Xen, VMware, Hyper-V 등 다양한 하이퍼바이저를 지원하여 높은 유연성과 적응성을 제공
-
KVM (Kernel-based Virtual Machine)
- KVM은 리눅스 커널에 통합된 오픈소스 하이퍼바이저로, 가상화 기술을 제공함
- x86 하드웨어에서 가상화를 지원하며, QEMU와 함께 사용하여 고성능의 가상 머신 환경을 구현함
-
QEMU (Quick Emulator)
- QEMU는 하드웨어 가상화를 지원하는 오픈소스 에뮬레이터 및 가상화 솔루션임
- KVM과 결합하여 가상 머신 성능을 최적화하며, 독립 실행 모드에서는 하드웨어 가속 없이도 동작 가능함
-
UML (User Mode Linux)
- UML은 사용자 모드에서 실행되는 리눅스 커널을 사용하여 리눅스 인스턴스를 가상화하는 솔루션임
- 기존 리눅스 커널을 수정하지 않고도 실행 가능한 환경을 제공하며, 테스트 및 개발 환경에 적합함
-
VMware
- VMware는 상용 하이퍼바이저로, 안정적인 가상화 환경을 제공함
- 높은 성능과 신뢰성을 바탕으로 기업 환경에서 널리 사용됨
-
Xen
- Xen은 오픈소스 하이퍼바이저로, 효율적인 하드웨어 가상화를 제공함
- 커널을 수정하지 않고도 작동 가능하며, 다양한 운영체제를 지원함
-
LXC (Linux Containers)
- LXC는 리눅스 커널의 컨테이너 기능을 활용하여 경량화된 가상화 환경을 제공함
- 리소스 오버헤드가 적으며, 빠른 배포와 관리를 지원함
-
Bare Metal
- Bare Metal은 하이퍼바이저를 사용하지 않고 물리 서버에서 직접 실행되는 환경임
- 높은 성능과 하드웨어 리소스의 완전한 활용을 보장함
Key Pairs
Key Pair는 비밀번호 없이 공개 키-개인 키 암호화를 통해 안전한 인증 수단을 제공함Key Pair는 Cloud-Init 프로세스를 통해 인스턴스 이미지에 주입되어, 인스턴스 생성 시 자동으로 설정이 이루어짐- Key Pair는 OpenStack 대시보드 또는 CLI를 통해 생성, 삭제, 가져오기(import)가 가능하여 관리의 유연성을 제공함
- Key Pair는 OpenStack에만 국한되지 않으며, 다양한 클라우드 환경 및 가상화 시스템에서도 사용 가능함
Nova Architecture
Nova는 분산된 컴포넌트 기반 아키텍처로 설계되어, 각각의 서비스가 독립적으로 동작하면서 상호 통신을 통해 클라우드 환경을 효율적으로 관리할 수 있음
RabbitMQ 또는 AMQP와 같은 메시지 버스를 사용하여 컴포넌트 간의 데이터 흐름을 조율하며, 대규모 클라우드 환경에서도 확장 가능하도록 설계
-
REST API:
- Nova의 REST API는 TCP 포트 8774에서 작동하며, 클라이언트와 OpenStack 간의 통신을 처리함
- 사용자가 API 요청을 통해 인스턴스 생성, 삭제, 상태 확인 등의 작업을 수행 가능
- Instance 구동이나 Quota Check 등 Orchestration Activities를 처리
-
RabbitMQ 또는 AMQP Message Bus:
- Nova의 내부 컴포넌트 간의 RPC(Remote Procedure Call) 통신을 관리하기 위해 RabbitMQ 또는 AMQP 메시지 버스를 사용
- 메시지 큐는 요청 및 응답을 비동기적으로 처리하며, 컴포넌트 간 연결을 효율적으로 지원
-
nova-compute:
- Nova의 컴퓨트 서비스는 하이퍼바이저와 직접 인터페이스하여 가상 머신의 생성, 삭제, 상태 업데이트 등을 처리함
- 지원되는 하이퍼바이저에는 KVM, Xen, VMware 등이 포함됨
- VM 인스턴스들을 생성하고 중지시키는 Worker Demon
- Queue로부터 Action을 받고 인스턴스를 launch하는 시스템 커맨드들을 구현하고 DB에 State 업데이트
-
nova-scheduler:
- nova-scheduler는 클라우드 리소스 내에서 인스턴스를 실행하기 위한 최적의 하이퍼바이저를 선택하는 역할을 수행
- CPU, 메모리, 디스크 사용률 및 기타 정책을 고려하여 리소스를 배정함
-
nova-console: 인스턴스에 원격 접속을 위한 콘솔 서비스 제공
-
nova-database: Nova의 메타데이터와 상태 정보를 저장
-
nova-conductor: nova-compute와 데이터베이스 간의 요청을 중재하여 보안을 강화
- 모든 Compute Node가 DB 정보를 가지고 있을 필요가 없기에,
nova-conductor를 통해 DB와 통신
- 모든 Compute Node가 DB 정보를 가지고 있을 필요가 없기에,
-
nova-consoleauth: 콘솔 인증 요청을 관리
-
Legacy Nova Networking:
- 과거 OpenStack에서 사용되던 네트워크 관리 방식으로,
nova-network를 사용하여 네트워크를 관리함 - 현재는 더 향상된 기능과 확장성을 가진 Neutron으로 대체됨
- 과거 OpenStack에서 사용되던 네트워크 관리 방식으로,
-
L2 Agent:
- Neutron이 L2(Link Layer) 네트워크를 관리하기 위해 사용하는 에이전트
- Neutron-openvswitch-agent: Open vSwitch를 기반으로 네트워크 브리징과 가상 네트워크 인터페이스(VIF)를 관리
- neutron-linuxbridge-agent: Linux Bridge를 사용하여 네트워크 트래픽을 브리징하는 역할을 수행
-
Metadata Service:
- nova-metadata-api를 통해 인스턴스에 메타데이터를 제공
- ex. SSH Key, user-data 등을 인스턴스 부팅 시 전달
-
Ceilometer Agent:
- OpenStack의 Ceilometer 서비스에서
openstack-ceilometer-compute에이전트를 사용하여 인스턴스의 메트릭과 사용량 데이터를 수집 - 클라우드 모니터링과 비용 관리를 지원
- OpenStack의 Ceilometer 서비스에서
-
EC2 API:
nova-ec2를 통해 OpenStack에서 Amazon EC2 호환 API를 제공- EC2와 유사한 인터페이스로 OpenStack 인프라를 관리할 수 있음
-
Console Auth and Proxies:
- 콘솔 접근 인증과 프록시 서비스
- noVNC: 브라우저 기반 VNC 콘솔 접속을 지원
- SPICE: 고성능 원격 데스크톱 접속을 지원하는 프로토콜
Launching an Instance
Prerequisites
- Minimum Requirements:
- An Image:
- 운영체제 또는 애플리케이션을 포함하는 가상 머신 이미지가 필요함
- A Network:
- 가상 머신이 통신을 수행할 수 있도록 네트워크가 필요함
- Neutron을 통해 가상 네트워크를 생성하거나 기존 네트워크를 연결 가능
- A Flavor:
- 가상 머신의 리소스 스펙을 정의하는 프로파일
- Resources:
- RAM: 가상 머신에 할당될 메모리 크기
- vCPU: 가상 CPU의 개수
- Storage: 가상 머신의 디스크 용량
- An Image:
Flavours
$ openstack flavor list
+----+-----------+-------+------+-----------+-------+-----------+
| ID | Name | RAM | Disk | Ephemeral | VCPUs | Is Public |
+----+-----------+-------+------+-----------+-------+-----------+
| 1 | m1.tiny | 512 | 1 | 0 | 1 | True |
| 2 | m1.small | 2048 | 20 | 0 | 1 | True |
| 20 | newflavor | 768 | 1 | 0 | 1 | True |
| 3 | m1.medium | 4096 | 40 | 0 | 2 | True |
| 4 | m1.large | 8192 | 80 | 0 | 4 | True |
| 5 | m1.xlarge | 16384 | 160 | 0 | 8 | True |
+----+-----------+-------+------+-----------+-------+-----------+위와 같이 Openstack이 설치되면서 기본적으로 생성된 Flavor를 확인할 수 있다.
Server Create CMD with min arguments
openstaack server create --image <image> \
--flavor <flavor> \
--network <network> \
<instance name>Flavor가 인스턴스의 size를 결정Nwtwork는 인스턴스가 어디에 attach될지 결정Image는 인스턴스를 부팅한 OS Image 결정
$ openstack image list
+--------------------------------------+---------+--------+
| ID | Name | Status |
+--------------------------------------+---------+--------+
| 9b7625df-f764-49a8-9373-6a8727530c7c | cirros3 | active |
| be315e95-ca18-46b4-8ca2-afb6738c7129 | cirros6 | active |
+--------------------------------------+---------+--------+openstack image show cirros6
+------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Field | Value |
+------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| checksum | c8fc807773e5354afe61636071771906 |
| container_format | bare |
| created_at | 2025-01-14T12:00:17Z |
| disk_format | qcow2 |
| file | /v2/images/be315e95-ca18-46b4-8ca2-afb6738c7129/file |
| id | be315e95-ca18-46b4-8ca2-afb6738c7129 |
| min_disk | 0 |
| min_ram | 0 |
| name | cirros6 |
| owner | 8dc84595f82b4e6dac4a18f990b05c6d |
| properties | os_hash_algo='sha512', os_hash_value='1103b92ce8ad966e41235a4de260deb791ff571670c0342666c8582fbb9caefe6af07ebb11d34f44f8414b609b29c1bdf1d72ffa6faa39c88e8721d09847952b', os_hidden='False', owner_specified.openstack.md5='', owner_specified.openstack.object='images/cirros6', owner_specified.openstack.sha256='', stores='file' |
| protected | False |
| schema | /v2/schemas/image |
| size | 21430272 |
| status | active |
| tags | |
| updated_at | 2025-01-14T12:00:17Z |
| virtual_size | 117440512 |
| visibility | public |
+------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+이미지를 선택할 때 가장 중요한 것은 min_disk, min_len이다.
Flavor Selection
- Flavor는 인스턴스를 물리적 호스트에 배치하는 과정을 단순화함
- 사전 정의된 리소스 설정을 통해 인스턴스 배치를 효율적으로 처리 가능
- 일반적으로 각 Flavor는 이전 단계보다 CPU, 디스크, RAM 크기가 두 배씩 증가
- Flavor는 administrator가 필요에 따라 커스터마이징할 수 있음
Network Selection
$ openstack network list
+--------------------------------------+------------------+--------------------------------------+
| ID | Name | Subnets |
+--------------------------------------+------------------+--------------------------------------+
| 61af13ca-6eb4-4916-9fe7-2e28d401e2bd | external_network | 5a7d4bd3-011c-4c42-9f77-15c1fa9d8b83 |
| 7b34e663-7d34-4c5c-b037-a7d5b47187d2 | intnet | 204c4ca0-3cba-4668-8b55-2ab7e1a132a2 |
+--------------------------------------+------------------+--------------------------------------+Instance Request Flow
0. Instance Creation Request
$ openstack server create --flavor 1 --image cirros6 --network intnet instance01
+-------------------------------------+------------------------------------------------+
| Field | Value |
+-------------------------------------+------------------------------------------------+
| OS-DCF:diskConfig | MANUAL |
| OS-EXT-AZ:availability_zone | |
| OS-EXT-SRV-ATTR:host | None |
| OS-EXT-SRV-ATTR:hypervisor_hostname | None |
| OS-EXT-SRV-ATTR:instance_name | |
| OS-EXT-STS:power_state | NOSTATE |
| OS-EXT-STS:task_state | scheduling |
| OS-EXT-STS:vm_state | building |
| OS-SRV-USG:launched_at | None |
| OS-SRV-USG:terminated_at | None |
| accessIPv4 | |
| accessIPv6 | |
| addresses | |
| adminPass | NsVLGSj8k6oL |
| config_drive | |
| created | 2025-01-15T05:03:57Z |
| flavor | m1.tiny (1) |
| hostId | |
| id | 4950a73f-064e-44d7-8040-074760bc577e |
| image | cirros6 (be315e95-ca18-46b4-8ca2-afb6738c7129) |
| key_name | None |
| name | instance01 |
| progress | 0 |
| project_id | 8dc84595f82b4e6dac4a18f990b05c6d |
| properties | |
| security_groups | name='default' |
| status | BUILD |
| updated | 2025-01-15T05:03:58Z |
| user_id | 40f117859e3c40178c2cef243e535777 |
| volumes_attached | |
+-------------------------------------+------------------------------------------------+인스턴스 생성 요청을 위와 같이 보내면 위와 같은 상태임을 확인할 수 있다.
-
Scheduling:- 인스턴스를 배포하기 위해 Nova가 가장 적합한 호스트를 선택하는 단계
- nova-scheduler가 현재 클라우드 환경 내의 리소스 사용량, 하이퍼바이저 상태, 가용성 등을 기반으로 최적의 물리 호스트를 결정
- 이 단계에서 아직 호스트가 할당되지 않았으며, OS-EXT-SRV-ATTR:host와 hypervisor_hostname 필드가
None으로 표시됨
-
Building:- 인스턴스가 Nova의 선택된 호스트에서 실제로 생성되고 있는 단계
- Nova가 이미지 배포, 네트워크 설정, 리소스 할당 등 가상 머신 생성에 필요한 작업을 진행
- VM의 상태가 초기화 중이며, 아직 사용자 요청을 처리할 준비가 되지 않음
- OS-EXT-STS:vm_state가
building으로 표시됨
1. nova-api
-
1-1. 요청 파라미터 추출 및 검증
- nova-api는 사용자가 요청한 매개변수를 추출하고 기본적인 유효성 검사를 수행함
- ex. 이미지 ID, 네트워크, Flavor 등의 입력값 확인
-
1-2. Flavor 참조 조회
- 사용자가 선택한 Flavor(인스턴스의 CPU, RAM, 디스크 스펙 등)의 정보를 조회함
- Flavor가 존재하지 않거나 올바르지 않으면 에러를 반환함
-
1-3. 부팅 이미지 참조 조회
- 인스턴스를 부팅하기 위해 선택된 이미지(boot media)의 정보를 가져옴
- 이미지가 올바르지 않거나 접근 불가능할 경우 에러를 반환함
-
1-4. 초기 상태를 데이터베이스에 저장
- 요청된 인스턴스의 초기 상태를 데이터베이스에 저장하여 작업 진행 시 참조되도록 함
-
1-5. 메시지 버스를 통해 Conductor로 요청 전달
- Conductor에게 메시지를 보내 인스턴스 생성을 위한 작업을 시작하도록 요청
- RabbitMQ와 같은 메시지 큐를 사용하여 비동기적으로 통신
-
1-6. 초기 상태 반환
- nova-api는 인스턴스의 상태를
BUILD, task 상태를SCHEDULING으로 설정하여 반환 - 이는 스케줄링 프로세스가 진행 중임을 의미함
- nova-api는 인스턴스의 상태를
2. Instance Scheduling
-
2-1. Conductor에서 스케줄러에 요청
- Conductor는 인스턴스를 어디에 생성할지 결정하기 위해 스케줄러에 요청을 보냄
- 요청은 메시지 버스를 통해 전달되며, 스케줄러는 해당 요청을 처리함
-
2-2. 필터 스케줄러 활성화
- 스케줄러는 설정에 따라 필터와 가중치를 적용하여 최적의 호스트를 선택함
-
2-3. Filter 적용
- Filter를 통해 적합한 컴퓨트 노드를 선별함
- Filter 예시:
- 컴퓨트 노드가 켜져 있는지 확인
- 사용 가능한 vCPU, vRAM, 디스크 공간이 충분한지 확인
-
2-4. Weight 적용
- 가중치 설정에 따라 선별된 호스트 중 우선순위를 지정함
- Weight 예시:
- 더 많은 여유 RAM이 있는 호스트를 우선 선택
- 더 적은 여유 RAM이 있는 호스트를 우선 선택 (특정 정책에 따라 다름)
-
2-5. 최적의 호스트 선택
- Filter와 Weight 적용 결과에 따라 가장 적합한 호스트가 선택됨
- 선택된 호스트에서 인스턴스 생성 작업이 진행됨
No Valid Host Scenario
- 가용한 컴퓨트 노드에 요청된 Flavor에 맞는 리소스가 부족한 경우
- 스케줄러가 필터를 적용한 결과, 조건에 맞는 호스트를 찾을 수 없는 경우
-
2-6. 데이터베이스 업데이트
- Nova는 선택된 호스트와 인스턴스 상태 정보를 Nova 데이터베이스에 업데이트함
- 업데이트된 정보는 상태 추적 및 장애 처리에 활용됨
-
2-7. Conductor에서 nova-compute로 메시지 전달
- Conductor는 선택된 호스트의 nova-compute 에이전트로 메시지를 큐를 통해 전달함
- nova-compute는 메시지를 수신하여 인스턴스 생성 작업을 수행함
3. Compute Agent
-
3-1. 부팅 미디어 정보 조회
- Compute Agent는 Glance를 호출하여 인스턴스 부팅에 필요한 이미지 정보를 가져옴
-
3-2. 네트워크 연결 요청
- Compute Agent는 Neutron을 호출하여 인스턴스를 네트워크에 연결
- 추가적으로 Security Group 또한 할당
-
3-3. 볼륨 연결 요청
- 필요 시 Cinder를 호출하여 영구 볼륨을 인스턴스에 연결
-
3-4. 구성 드라이브 설정
- 요청된 경우, configuration drive를 설정하여 사용자 데이터를 인스턴스에 전달
-
3-5. 하이퍼바이저와 통신
- 하이퍼바이저와 통신하여 가상 머신을 생성
-
3-6. 인스턴스 상태 업데이트
- Conductor를 통해 Nova 데이터베이스의 인스턴스 상태를 업데이트
- Compute Agent는 보안상의 문제로 DB에 직접적으로 도달할 수 없음
Grouping Compute Nodes
Segregation of Compute Resources
-
Logical Group 제공
- 컴퓨트 리소스를 논리적으로 그룹화하여 관리 효율성을 높임
- ex, 데이터 센터, 지리적 위치, 전원 공급원, 랙, 네트워크 리소스
-
컴퓨트 노드의 하드웨어 구분
- 특정 하드웨어를 기반으로 컴퓨트 노드를 구분하여 작업 부하를 분산하거나 최적화 가능
- ex. GPU 카드, 고속 NIC, 스토리지 장치, SSD
https://www.slideshare.net/slideshow/divide-and-conquer2/34638106
1. Regions
-
독립적인 OpenStack 배포
- Region은 자체 API 엔드포인트, 컴퓨트, 스토리지, 네트워크 등의 리소스를 구현함
- 각 Region은 독립적으로 작동하며, 지역별 데이터 센터 배포에 적합함
-
서비스 공유
- 필요한 만큼의 서비스를 여러 Region 간에 공유 가능
- 특정 서비스는 중앙화하여 관리하거나 분산하여 운영 가능
-
기본 설정
- 기본적으로 모든 서비스는 단일 Region에 배포됨
- 다중 Region을 사용할 경우, 설정에서 타겟 Region을 지정해야 함
-
타겟 Region 지정 필요
- 작업 실행 시 명확한 Region을 지정해야 올바른 리소스에 접근 가능
- ex. 인스턴스 생성, 네트워크 구성 등 특정 Region 내에서 실행됨
2. Host Aggregates
-
컴퓨트 노드의 논리적 그룹화
- 메타데이터를 기반으로 컴퓨트 노드를 논리적으로 그룹화하여 관리 효율성을 높임
- Scheduler는 해당 정보를 활용해서 의사결정
-
메타데이터로 노드의 기능 설명
- 노드의 하드웨어 및 네트워크 기능을 메타데이터로 정의
- ex. SSD 하드디스크, 40G NIC, GPU 카드
-
다중 호스트 어그리게이트 포함 가능
- 하나의 컴퓨트 노드는 여러 호스트 어그리게이트에 속할 수 있음
- ex. 듀얼 40G NIC와 SSD 스토리지를 가진 호스트
User에게는 Host Aggregation이 보여지지 않지만, Implicitly Targetable(명시적 사용자 타겟팅)함
- Admin이 메타데이터와 Flavor를 사용하여 호스트 어그리게이트를 정의
openstack aggregate create nodes-with-SSD
openstack aggregate set --property SSD=true nodes_with_ssd
openstack aggregate add host nodes_with_ssd host1
openstack flavor set --property SSD=true m1.large- 사용자가 인스턴스 요청 시 Flavor를 선택
- 선택한 Flavor의 메타데이터와 일치하는 호스트를 스케줄러가 선택
- Flavor의 추가 사양(extra specs)이 호스트 어그리게이트 메타데이터와 매칭됨
3. Availability Zones
-
AWS의 운영 방식에서 영감을 받음
-
Host Aggregates과 유사한 개념
-
호스트를 논리적으로 그룹화
- 지역(Location), 데이터 센터, 네트워크 구성, 전원 공급원과 같은 요소를 기반으로 호스트를 그룹화하여 가용성을 보장
-
주요 요소
- 지리적 위치: 국가, 도시, 데이터 센터, 랙 등
- 네트워크 구성: 네트워크 토폴로지에 따른 분리
- 전원 공급원: 전원 장애 발생 시 영향을 줄이기 위한 분리
-
명시적 사용자 타겟팅 가능
- 사용자는 특정 가용성 영역을 지정하여 인스턴스를 생성 가능
$ openstack server create --availability-zone AppServers1 ...
- 사용자는 특정 가용성 영역을 지정하여 인스턴스를 생성 가능
-
Host Aggregate를 Availability Zone으로 정의하여 명시적으로 타겟팅 가능
- 호스트 어그리게이트 생성 및 AZ 설정:
$ openstack aggregate create --zone myzone myaggregate rack-row-1은 Aggregate 이름이며,DC1-rack-row-1은 AZ 이름
- 호스트 어그리게이트 생성 및 AZ 설정:
-
Host Aggregation과 다르게 Host는 Multiple AZ에 속할 수 없음
-
default하게 Host는 Default AZ의 일부임
Nova CLI
$ openstack compute service list
+--------------------------------------+----------------+-----------------------+----------+---------+-------+----------------------------+
| ID | Binary | Host | Zone | Status | State | Updated At |
+--------------------------------------+----------------+-----------------------+----------+---------+-------+----------------------------+
| d5fc9f18-4d2a-4723-9139-de85ca14dbfc | nova-conductor | localhost.localdomain | internal | enabled | down | 2025-01-12T07:49:38.000000 |
| c37ce1ad-abdb-4a95-96ec-3b5a1c9c634b | nova-scheduler | localhost.localdomain | internal | enabled | down | 2025-01-12T07:49:35.000000 |
| f0ccd8eb-5715-4e26-807b-d26777e0e264 | nova-compute | localhost.localdomain | nova | enabled | down | 2025-01-12T07:49:35.000000 |
| 254e705f-967f-4f39-8445-df7a9d72ad86 | nova-conductor | localhost | internal | enabled | up | 2025-01-15T06:12:09.000000 |
| 42db026e-b332-4163-8459-cfa2f8be34b8 | nova-scheduler | localhost | internal | enabled | up | 2025-01-15T06:12:01.000000 |
| 6deb28a3-1d51-4d4f-ac4c-d2c53604743a | nova-compute | localhost | nova | enabled | up | 2025-01-15T06:12:05.000000 |
+--------------------------------------+----------------+-----------------------+----------+---------+-------+----------------------------+우선 위와 같이 compute service들의 list를 확인한다
nova compute 노드의 경우 SIngle Openstack Cloud에 여러개 존재할 수 있다
$ openstack flavor create --id 10 --ram 256 --disk 2 --public m1.tinier
+----------------------------+-----------+
| Field | Value |
+----------------------------+-----------+
| OS-FLV-DISABLED:disabled | False |
| OS-FLV-EXT-DATA:ephemeral | 0 |
| description | None |
| disk | 2 |
| id | 10 |
| name | m1.tinier |
| os-flavor-access:is_public | True |
| properties | |
| ram | 256 |
| rxtx_factor | 1.0 |
| swap | |
| vcpus | 1 |
+----------------------------+-----------+우선 위와 같이 flavor을 먼저 생성한다
$ openstack keypair create mykeypair >> mykeypair.keykeypair을 생성한 이후
$ openstack server create --image cirros6 --key-name mykeypair --flavor 10 --nic net-id=7b34e663-7d34-4c5c-b037-a7d5b47187d2 instance01
$ openstack server show instance01
+-------------------------------------+----------------------------------------------------------+
| Field | Value |
+-------------------------------------+----------------------------------------------------------+
| OS-DCF:diskConfig | MANUAL |
| OS-EXT-AZ:availability_zone | nova |
| OS-EXT-SRV-ATTR:host | localhost |
| OS-EXT-SRV-ATTR:hypervisor_hostname | localhost |
| OS-EXT-SRV-ATTR:instance_name | instance-0000000d |
| OS-EXT-STS:power_state | Running |
| OS-EXT-STS:task_state | None |
| OS-EXT-STS:vm_state | active |
| OS-SRV-USG:launched_at | 2025-01-15T06:24:03.000000 |
| OS-SRV-USG:terminated_at | None |
| accessIPv4 | |
| accessIPv6 | |
| addresses | intnet=10.5.5.29 |
| config_drive | |
| created | 2025-01-15T06:23:54Z |
| flavor | m1.tinier (10) |
| hostId | b4a90f32f5cb554a830f6618f15712a7e9834971293a230d69121ada |
| id | dfbe6675-32cf-468e-b21c-24e596a76d01 |
| image | cirros6 (be315e95-ca18-46b4-8ca2-afb6738c7129) |
| key_name | mykeypait |
| name | instance01 |
| progress | 0 |
| project_id | 8dc84595f82b4e6dac4a18f990b05c6d |
| properties | |
| security_groups | name='default' |
| status | ACTIVE |
| updated | 2025-01-15T06:24:03Z |
| user_id | 40f117859e3c40178c2cef243e535777 |
| volumes_attached | |
+-------------------------------------+----------------------------------------------------------+이후 위와 같이 인스턴스를 생성허고 active 상태가 된 인스턴스의 정보를 확인할 수 있었다.
만약 여러개의 compute node가 존재한다면 nova-scheduler는 Filter와 Weight, 정책을 기반으로 가장 적합한 Compute Host를 선택한다
$ cat /etc/nova/nova.conf | grep filter
# not filtered. An empty string means that all levels are filtered (string
[filter_scheduler]
#available_filters=nova.scheduler.filters.all_filters
available_filters=nova.scheduler.filters.all_filters
#enabled_filters=ComputeFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,ServerGroupAntiAffinityFilter,ServerGroupAffinityFilter
# The default architecture to be used when using the image properties filter.
# Enable filter traces that contain error/exception to a separated place. For
#filter_error_trace=false
# Enable the scheduler to filter compute hosts affined to routed network segment
# Since the introduction of placement pre-filters in 18.0.0 (Rocky), we have
# legacy ``AvailabilityZoneFilter`` scheduler filter. In 24.0.0 (Xena), the
# filter-based approach has been deprecated for removal in favor of the
# deprecated and will be removed when the ``AvailabilityZoneFilter`` filter is
#enable_isolated_aggregate_filtering=false
# Use placement to filter hosts based on image metadata. For more information,
#image_metadata_prefilter=false/etc/nova/nova.conf애서 현재 사용 가능한 available_filters를 볼 수 있다.
- ComputeFilter: Compute Host가 활성화되어 있고 실행 가능한 상태인지 확인
- ComputeCapabilitiesFilter: Compute Host의 하드웨어 및 소프트웨어 기능이 인스턴스 요구사항을 충족하는지 확인
- ImagePropertiesFilter: 이미지 메타데이터의 요구사항을 Compute Host가 충족하는지 확인
- ServerGroupAntiAffinityFilter: 동일 Server Group의 인스턴스가 다른 호스트에서 실행되도록 보장
- ServerGroupAffinityFilter: 동일 Server Group의 인스턴스가 같은 호스트에서 실행되도록 보장
또한 위와 같은 Filter가 만족스럽지 않다면 Custom Filter를 생성할 수도 있다.
$ openstack server image create --name snap1 instance01
+------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Field | Value |
+------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| created_at | 2025-01-15T07:00:47Z |
| file | /v2/images/bc09e31c-2a05-45c1-b33b-6d102cbb6efe/file |
| id | bc09e31c-2a05-45c1-b33b-6d102cbb6efe |
| min_disk | 2 |
| min_ram | 0 |
| name | snap1 |
| owner | 8dc84595f82b4e6dac4a18f990b05c6d |
| properties | base_image_ref='be315e95-ca18-46b4-8ca2-afb6738c7129', boot_roles='reader,admin,member', hw_cdrom_bus='ide', hw_disk_bus='virtio', hw_input_bus='usb', hw_machine_type='pc', hw_pointer_model='usbtablet', hw_video_model='virtio', hw_vif_model='virtio', image_type='snapshot', instance_uuid='dfbe6675-32cf-468e-b21c-24e596a76d01', os_hidden='False', owner_project_name='admin', owner_specified.openstack.md5='', owner_specified.openstack.object='images/cirros6', owner_specified.openstack.sha256='', owner_user_name='admin', user_id='40f117859e3c40178c2cef243e535777' |
| protected | False |
| schema | /v2/schemas/image |
| status | queued |
| tags | |
| updated_at | 2025-01-15T07:00:47Z |
| visibility | private |
+------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
$ openstack image list
+--------------------------------------+---------+--------+
| ID | Name | Status |
+--------------------------------------+---------+--------+
| 9b7625df-f764-49a8-9373-6a8727530c7c | cirros3 | active |
| be315e95-ca18-46b4-8ca2-afb6738c7129 | cirros6 | active |
| bc09e31c-2a05-45c1-b33b-6d102cbb6efe | snap1 | active |
+--------------------------------------+---------+--------+이후 위와 같이 추후 이미지에 문제가 생겼을 때 복구할 수 있는 Snapshot을 생성하고 Glance Image List에서 확인할 수 있다.
$ openstack aggregate create --property SSD=true agg1
+-------------------+----------------------------+
| Field | Value |
+-------------------+----------------------------+
| availability_zone | None |
| created_at | 2025-01-15T07:02:32.000000 |
| deleted_at | None |
| hosts | |
| id | 1 |
| is_deleted | False |
| name | agg1 |
| properties | SSD='true' |
| updated_at | 2025-01-15T07:02:33.319967 |
| uuid | None |
+-------------------+----------------------------+이후 SSD를 지닌 인스턴스에 대한 Host Aggregate를 생성한다.
Aggregate는 Host가 가진 properties를 기준으로 이들을 묶는다.
$ openstack console url show --novnc instance01
+----------+------------------------------------------------------------------------------------------+
| Field | Value |
+----------+------------------------------------------------------------------------------------------+
| protocol | vnc |
| type | novnc |
| url | http://10.0.2.15:6080/vnc_auto.html?path=%3Ftoken%3Dfdab3881-28db-4687-b8c7-22b871a5f4fa |
+----------+------------------------------------------------------------------------------------------+
또한 위 명령어로 브라우저에서 접근 가능한 해당 인스턴스 console의 엔드포인트를 알 수 있다.
$ openstack console log show instance01위 명령어로 인스턴스에 대한 로그 또한 확인할 수 있다.
- aggregate: 호스트 어그리게이트를 생성, 삭제, 목록 조회, 메타데이터 설정 및 해제, 호스트 추가 및 제거
- compute agent: Compute Agent를 생성, 삭제, 목록 조회, 설정 변경
- compute service: Compute 서비스를 삭제, 목록 조회, 설정 변경
- console: 서버 콘솔 로그 조회 및 URL 표시
- flavor: Flavor를 생성, 삭제, 목록 조회, 설정 및 해제
- host: 호스트 목록 조회, 설정 변경, 세부 정보 확인
- hypervisor: 하이퍼바이저 목록 조회, 세부 정보 확인, 통계 확인
- keypair: SSH 키페어를 생성, 삭제, 목록 조회, 세부 정보 확인
- server: 서버를 생성, 삭제, 백업, 이벤트 조회, 리부팅, 크기 조정, 네트워크 및 볼륨 추가 및 제거, 상태 관리
- server group: 서버 그룹 생성, 삭제, 목록 조회, 세부 정보 확인
- server migration: 서버 마이그레이션 관리(확인, 되돌리기, 강제 완료 등)
- usage: 클라우드 리소스 사용량 조회
Cinder (Block Storage)
Storage Types
| 유형 | Ephemeral Storage | Block Storage | Object Storage | Shared File System Storage |
|---|---|---|---|---|
| 사용 목적 | 운영 체제 실행 및 임시 저장 공간 | 가상 머신에 추가적인 영구 스토리지 제공 | 데이터/파일 저장 (VM 이미지 포함) | 가상 머신에서 공유 가능한 추가 영구 스토리지 제공 |
| 접근 방식 | 파일 시스템을 통해 접근 | 파티션, 포맷, 마운트 가능한 블록 장치 (예: dev/vdc) | REST API를 통해 접근 | 파티션, 포맷, 마운트 가능한 공유 파일 시스템 서비스 |
| 접근 가능한 위치 | 가상 머신 내에서만 접근 가능 | 가상 머신 내에서만 접근 가능 | 어디서나 접근 가능 | 가상 머신 내에서만 접근 가능 |
| 지속 시간 | VM이 종료될 때까지 유지 | 사용자가 삭제할 때까지 유지 | 사용자가 삭제할 때까지 유지 | 사용자가 삭제할 때까지 유지 |
| 관리 주체 | OpenStack Compute | OpenStack Block Storage | OpenStack Object Storage | OpenStack Shared File System Service |
| 일반적인 사용 예 | 10GB 첫 디스크, 30GB 두 번째 디스크 | 1TB 디스크 | 수십 TB의 데이터셋 저장 공간 | 1TB 공유 디스크 |
Cinder Block Storage
-
영구적인 블록 수준 스토리지 제공
- 가상 머신(Compute Instance)에서 사용하기 위한 블록 스토리지를 제공
- 기존에 생성한 Persistent Block Storage를 다른 VM에 attach할 수 있음
-
블록 장치 생명 주기 관리
- 블록 스토리지의 생성, 사용, 삭제 등 전체 생명 주기를 관리
-
1:1 관계
- 각 인스턴스와 블록 스토리지 장치는 1:1 관계로 연결
- 마치
USB 드라이브처럼 생각하면 쉽다
-
스냅샷 관리
- 데이터 백업 및 복구를 위해 스냅샷을 생성하고 관리
- Snapshot은 Instance 뿐 아니라 Volume으로도 생성될 수 있음
-
볼륨 유형 관리
- 다양한 스토리지 요구사항에 따라 볼륨 유형(ex. SSD, HDD)을 관리
-
Nova 및 Horizon과 통합
- Nova 및 Horizon과 완전히 통합되어 사용자 셀프 서비스 기능 제공
- iSCSI, FC(Fibre Channel) 프로토콜을 통해 데이터 전송 지원
Volumes
-
영구적인 읽기/쓰기 블록 스토리지 제공
- 가상 머신에 필요한 데이터를 저장하고 관리
-
인스턴스의 보조 스토리지로 연결 가능
- 인스턴스의 추가 디스크로 사용
-
부팅 볼륨으로 사용 가능
- 루트 볼륨으로 설정하여 인스턴스를 부팅하는 데 사용
-
볼륨 생명 주기 관리
- 볼륨의 생성, 삭제, 확장 등을 관리
- 볼륨의 연결(attach) 및 분리(detach) 가능
-
볼륨 관리
- 다양한 용량과 유형의 볼륨을 관리하고 배포
Snapshot
- Volume에 대한
read-onlycopy
Backup
-
관리자 작업으로 수행
- 백업 작업은 관리자 권한으로만 수행 가능
-
Swift에 백업 저장
- 백업 데이터는 OpenStack의 Object Storage(Swift)에 저장
- 컨테이너가 필요
-
백업 생성 및 복원
- 데이터 보존을 위해 백업 생성 및 복원 가능
$ cinder backup-create "volume id"
- 데이터 보존을 위해 백업 생성 및 복원 가능
Quotas
-
운영 한계 설정 가능 : 프로젝트별로 자원 사용 한도를 제한하여 과도한 사용 방지
-
프로젝트 단위로 적용
- 볼륨의 수 제한
- 저장 공간 용량 제한 (GB 단위)
- 스냅샷의 수 제한
Cinder Architecture
-
Cinder Client
- 사용자 또는 서비스가 REST API를 통해 Cinder와 상호작용
- 볼륨 생성, 삭제, 스냅샷 작업 등을 요청
-
Cinder API
- 클라이언트 요청을 받아 내부 컴포넌트로 전달
- SQL 데이터베이스와 통신하여 요청 상태 및 메타데이터 저장
-
SQL Database
- 볼륨 정보, 스냅샷, 백업 데이터를 저장 및 관리
-
Cinder Scheduler
- 적절한 Cinder Volume 노드를 선택하여 작업 할당
- AMQP 메시지 큐를 통해 다른 서비스와 통신
-
Cinder Volume
- 실제 볼륨 작업(생성, 삭제, 연결)을 처리
- 백엔드 스토리지와 통신하여 데이터 관리
-
Cinder Backup
- 볼륨 데이터를 백업 및 복원
- AMQP 메시지 큐를 통해 다른 서비스와 통신
Example Data, Control Traffic Scenario
Control Traffic
1 요청 생성
- 사용자가 CLI, Dashboard(Horizon), 또는 REST API를 통해 요청을 보냄
- ex.
nova명령어로 인스턴스 생성 요청
2 API 컴포넌트로 전달
- Nova, Cinder, Neutron 등의 API 컴포넌트가 요청을 수신
- ex. Nova API가 인스턴스 생성 요청을 수신
3 스케줄링 및 자원 할당
- Nova Scheduler 또는 Cinder Scheduler가 적절한 호스트 또는 볼륨을 선택
- 메시지 큐(AMQP)를 통해 Control Traffic을 컴퓨트 또는 스토리지 노드에 전달
4 명령 처리
- Compute 노드(Nova Compute) 또는 Storage 노드(Cinder Volume)가 요청을 처리
- 작업 완료 후 상태 업데이트가 다시 API로 전달되어 사용자에게 보고
Data Traffic
1 데이터 전송 요청
- Control Traffic에서 생성된 설정에 따라 데이터 통신 채널이 열림
- ex. VM과 Cinder Volume 간 데이터 트래픽 연결
2 iSCSI 또는 NFS를 통한 데이터 연결
- VM은 iSCSI Initiator 또는 NFS를 사용하여 Cinder에서 제공하는 볼륨에 연결
- 실제 데이터는 해당 프로토콜을 통해 전송
3 데이터 경로
- VM 내에서 디스크는
/dev/vda와 같은 경로로 마운트됨 - 스토리지 노드에서 물리적 또는 가상 디스크(
/dev/hda)로 데이터가 저장
4 사용자 데이터 송수신
- 사용자가 애플리케이션 또는 서비스를 통해 데이터를 업로드하거나 다운로드
- 네트워크 대역폭과 설정에 따라 트래픽이 처리됨
Cinder CLI
$ cinder service-list
+------------------+---------------------------+------+---------+-------+----------------------------+---------+-----------------+---------------+
| Binary | Host | Zone | Status | State | Updated_at | Cluster | Disabled Reason | Backend State |
+------------------+---------------------------+------+---------+-------+----------------------------+---------+-----------------+---------------+
| cinder-backup | localhost | nova | enabled | up | 2025-01-15T08:09:47.000000 | - | - | |
| cinder-backup | localhost.localdomain | nova | enabled | down | 2025-01-12T07:49:35.000000 | - | - | |
| cinder-scheduler | localhost | nova | enabled | up | 2025-01-15T08:09:42.000000 | - | - | |
| cinder-scheduler | localhost.localdomain | nova | enabled | down | 2025-01-12T07:49:35.000000 | - | - | |
| cinder-volume | localhost.localdomain@lvm | nova | enabled | down | 2025-01-12T07:49:29.000000 | - | - | - |
| cinder-volume | localhost@lvm | nova | enabled | up | 2025-01-15T08:09:46.000000 | - | - | up |
+------------------+---------------------------+------+---------+-------+----------------------------+---------+-----------------+---------------+우선 위와 같이 cinder 서비스가 구동되고 있는 것을 확인한다.
$ openstack volume create --size 1 vol1
+---------------------+--------------------------------------+
| Field | Value |
+---------------------+--------------------------------------+
| attachments | [] |
| availability_zone | nova |
| bootable | false |
| consistencygroup_id | None |
| created_at | 2025-01-15T08:10:54.821577 |
| description | None |
| encrypted | False |
| id | 86627753-e648-4175-acca-9d27b3458c69 |
| migration_status | None |
| multiattach | False |
| name | vol1 |
| properties | |
| replication_status | None |
| size | 1 |
| snapshot_id | None |
| source_volid | None |
| status | creating |
| type | iscsi |
| updated_at | None |
| user_id | 40f117859e3c40178c2cef243e535777 |
+---------------------+--------------------------------------+
$ openstack volume list
+--------------------------------------+------+-----------+------+-------------+
| ID | Name | Status | Size | Attached to |
+--------------------------------------+------+-----------+------+-------------+
| 86627753-e648-4175-acca-9d27b3458c69 | vol1 | available | 1 | |
+--------------------------------------+------+-----------+------+-------------+이후 위와 같이 새로운 Volume을 생성하고 확인한다.
$ ip netns exec qrouter-4358fd19-62ea-42d3-be7d-0ef3140dc249 ssh cirros@10.5.5.29
$ ls /dev/
bus loop1 random tty18 tty33 tty49 tty7 ttyS21 ttyS9
console loop2 rfkill tty19 tty34 tty5 tty8 ttyS22 ttyprintk
cpu_dma_latency loop3 root tty2 tty35 tty50 tty9 ttyS23 udmabuf
dma_heap loop4 rtc0 tty20 tty36 tty51 ttyS0 ttyS24 uinput
dri loop5 shm tty21 tty37 tty52 ttyS1 ttyS25 urandom
ecryptfs loop6 snapshot tty22 tty38 tty53 ttyS10 ttyS26 vcs
fb0 loop7 tty tty23 tty39 tty54 ttyS11 ttyS27 vcs1
full mapper tty0 tty24 tty4 tty55 ttyS12 ttyS28 vcsa
fuse mcelog tty1 tty25 tty40 tty56 ttyS13 ttyS29 vcsa1
hidraw0 mem tty10 tty26 tty41 tty57 ttyS14 ttyS3 vcsu
hpet net tty11 tty27 tty42 tty58 ttyS15 ttyS30 vcsu1
hwrng null tty12 tty28 tty43 tty59 ttyS16 ttyS31 vda
input port tty13 tty29 tty44 tty6 ttyS17 ttyS4 vda1
kmsg ppp tty14 tty3 tty45 tty60 ttyS18 ttyS5 vda15
log psaux tty15 tty30 tty46 tty61 ttyS19 ttyS6 vfio
loop-control ptmx tty16 tty31 tty47 tty62 ttyS2 ttyS7 vga_arbiter
loop0 pts tty17 tty32 tty48 tty63 ttyS20 ttyS8 zero
이후 SSH를 통해 인스턴스에 접근하여 vda이외에 디스크가 존재하지 않는 것을 볼 수 있다.
$ openstack server add volume instance01 vol1
+-----------------------+--------------------------------------+
| Field | Value |
+-----------------------+--------------------------------------+
| ID | 86627753-e648-4175-acca-9d27b3458c69 |
| Server ID | dfbe6675-32cf-468e-b21c-24e596a76d01 |
| Volume ID | 86627753-e648-4175-acca-9d27b3458c69 |
| Device | /dev/vdb |
| Tag | None |
| Delete On Termination | False |
+-----------------------+--------------------------------------+
$ ls /dev | grep vd
vda
vda1
vda15
vdb이후 Volume을 attach하고 SSH를 통해 접근하여 /dev 디렉터리를 확인하면 vdb가 attach된 것을 확인할 수 있다.
sudo mkfs.ext3 /dev/vdb
sudo mkdir /mydisk
sudo mount /dev/vdb /mydisk하지만 vdb 디스크는 현재 특정 format이 정해지지 않았기 때문에 ext 파일 시스템을 통해 이를 포맷한다.
이후 새로운 dir를 성하고 이를 Volume에 마운트하여준다.
$ openstack volume backup create --name backup1 --force vol1
+-------+--------------------------------------+
| Field | Value |
+-------+--------------------------------------+
| id | 0bd3f476-2169-4f9b-a5b7-c431fcb74516 |
| name | backup1 |
+-------+--------------------------------------+
$ openstack volume backup show backup1
+-----------------------+--------------------------------------+
| Field | Value |
+-----------------------+--------------------------------------+
| availability_zone | None |
| container | volumebackups |
| created_at | 2025-01-15T08:22:03.000000 |
| data_timestamp | 2025-01-15T08:22:03.000000 |
| description | None |
| fail_reason | None |
| has_dependent_backups | False |
| id | 0bd3f476-2169-4f9b-a5b7-c431fcb74516 |
| is_incremental | False |
| name | backup1 |
| object_count | 21 |
| size | 1 |
| snapshot_id | None |
| status | available |
| updated_at | 2025-01-15T08:22:54.000000 |
| volume_id | 86627753-e648-4175-acca-9d27b3458c69 |
+-----------------------+--------------------------------------+이후 새로운 Backup을 생성하고 이를 확인한다.
Backup은 파일이기 때문에 Object Storage인 Swift를 통해 저장된다.
openstack volume snapshot create --volume vol1 --force snap1
+-------------+--------------------------------------+
| Field | Value |
+-------------+--------------------------------------+
| created_at | 2025-01-15T08:26:05.027417 |
| description | None |
| id | 6d6753ef-19df-41d3-a310-4c31fd98214c |
| name | snap1 |
| properties | |
| size | 1 |
| status | creating |
| updated_at | None |
| volume_id | 86627753-e648-4175-acca-9d27b3458c69 |
+-------------+--------------------------------------+또한 위 명령어를 통해 snapshot을 생성할 수 있다
openstack command list | grep openstack.volume -A 100- Block Storage Cluster : 블록 스토리지 클러스터와 관련된 명령어로, 클러스터의 목록 조회, 설정, 세부 정보 확인 등을 수행
- Block Storage Resource Filter : 블록 스토리지 리소스 필터의 목록 조회 및 세부 정보 확인
- Consistency Group : 컨시스턴시 그룹과 관련된 명령어로, 그룹 생성, 삭제, 설정, 볼륨 추가/제거, 스냅샷 생성/삭제 등을 관리
- Volume Attachment : 볼륨을 인스턴스에 연결하거나 분리하는 작업을 처리하며, 상태 확인과 설정도 포함
- Volume Backup : 볼륨 백업 생성, 삭제, 복원, 기록 내보내기/가져오기, 설정 및 상태 확인 작업을 수행
- Volume : 볼륨 생성, 삭제, 목록 조회, 마이그레이션, 설정 및 상태 확인 등을 포함
- Volume Group : 볼륨 그룹 생성, 삭제, 설정, 스냅샷 관리 등을 수행하며 그룹 단위로 볼륨을 관리
- Volume QoS (Quality of Service) : 볼륨의 품질 관리를 위한 QoS 정책 생성, 삭제, 설정 및 적용/해제 작업을 수행
- Volume Service : 볼륨 서비스 목록 조회 및 설정 관련 작업을 처리
- Volume Snapshot : 볼륨 스냅샷 생성, 삭제, 설정, 상태 확인 및 목록 조회 작업을 수행
- Volume Transfer : 볼륨 전송 요청 생성, 삭제, 승인, 상태 확인 및 목록 조회 작업을 수행
- Volume Type : 볼륨 타입 생성, 삭제, 설정 및 상태 확인 작업을 수행
Swift (Object Storage)
-
Scalable, Distributed, and Replicated Object Storage
- 데이터를 여러 위치에 분산 저장하고 복제하여 안정성과 확장성을 제공
-
Simple and Powerful RESTful API
- 데이터 접근 및 관리를 용이하게 하는 강력한 API 제공
-
High Concurrency Support
- 다수의 사용자를 동시에 지원하며 동시 액세스 성능이 우수함
-
Pooled Storage Capacity
- 풀링된 리소스를 통해 효율적으로 스토리지 용량 관리
-
Object = File + Metadata
Need for Object Store
Traditional File-Based Storage
- Storage Mechanism
- 계층적 디렉터리 구조에 데이터를 저장
- Use Cases
- 파일 공유, 소규모 데이터 관리
- Limitations
- 확장성 부족 및 대규모 데이터 처리가 어려움
Block Store
- Storage Mechanism
- 디스크 블록 단위로 데이터를 저장하며, 데이터는 서버에 직접 연결된 디스크에 위치
- Use Cases
- 데이터베이스, 고성능 애플리케이션
- Limitations
- 스토리지 관리의 복잡성 및 서버 간 데이터 공유 어려움
Object Storage (HTTP Namespace)
- Storage Mechanism
- HTTP를 통해 접근 가능한 네임스페이스 기반 데이터 저장
- 데이터를 객체로 저장하며, 각 객체는 고유한 ID를 가짐
- Use Cases
- 대규모 데이터 저장, 백업 및 아카이빙, 클라우드 애플리케이션
- Advantages
- 높은 확장성, 저비용 구조, 데이터 메타데이터 관리 용이
- SaaS, API 형태로 접근 가능
Data Consistency
Strict Consistency
- 모든 복제본(replica)이 모든 지역과 영역에서 작성 완료될 때까지 쓰기 작업이 성공으로 간주됨
- 하나의 복제본 작성 실패 또는 parity 실패 시 트랜잭션이 실패로 처리됨
Eventual Consistency
- 모든 복제본이 동시에 작성되지만, 대부분의 복제본이 성공하면 성공으로 선언
- 실패한 복제본은 별도로 처리됨
| Consistency | Benefits | Limitations |
|---|---|---|
| Strict | Provide write guarantee | Poor performance at scale |
| Eventual | Excellent performance at scale | Can't be used for object locking or synchronizing |
Durability with Replicas
- 데이터를 여러 복제본으로 저장하여 안정성과 내구성을 보장
- 기본 Replica 개수는 3개로 설정되어 내구성과 비용 효율성 간 균형을 제공
- Replica 개수는 사용자 요구에 따라 조정 가능
- 데이터 무결성을 위해 각 객체에 MD5 Cheksum을 저장하며, 이를 헤더를 통해 클라이언트가 확인 가능
- Cheksum과 Replica 구조를 통해 파일 시스템 오류 발생 시에도 데이터 무결성과 복구를 보장
Data Placement in Swift
-
Geographic Region
데이터를 여러 Geographic Region에 복제하여 지역 전체 장애에도 데이터를 보호함 -
Availability Zone
각 Geographic Region은 여러 Availability Zone으로 구성되며 한 영역의 장애가 다른 영역에 영향을 주지 않도록 설계됨 -
Server 분리
데이터를 각 Availability Zone 내의 여러 Server에 분산 저장하여 개별 서버 장애에 대비함 -
Disk 분산
각 Server 내에서는 데이터를 여러 Disk에 분산하여 동일 Disk에 복제본이 저장되지 않도록 보장함 -
복제 배치와 부하 분산
Consistent Hashing을 사용해 데이터를 효율적으로 분배하고 자원의 병목현상을 줄이며 부하를 고르게 분산함 -
내구성과 접근성 제공
여러 수준에서 데이터 복제를 수행하여 Disk, Server, Zone 장애가 발생하더라도 데이터 접근성을 유지함
Swift essentials
-
계층적 구조
- Swift는 계정(Account), 컨테이너(Container), 객체(Object)라는 3단계 계층 구조를 통해 데이터를 관리하며, 각 계층에서 메타데이터와 접근 제어 정책을 적용함
-
RESTful API 기반
- HTTP를 통해 데이터를 업로드, 다운로드, 삭제할 수 있으며, RESTful API를 사용하여 간단하고 유연한 데이터 접근 제공
https://storage.example.conm/<API Version>/<account>/<container>/<object>-
API Version
Swift API의 버전을 나타냄
일반적으로v1또는v2와 같은 형태로, 사용 가능한 API의 기능과 호환성을 정의함 -
Account
Swift 스토리지에서 데이터를 관리하는 계정
각 계정은 할당된 스토리지와 관련된 인증 정보를 포함하며, 계정 기반으로 데이터 액세스와 사용량이 관리됨 -
Container
계정 내에서 데이터를 조직화하는 논리적 그룹
파일 시스템의 디렉토리에 해당하며, 컨테이너는 객체의 그룹으로 관리되고 특정 접근 정책을 가질 수 있음 -
Object
저장되는 개별 데이터 단위로, 파일 또는 데이터 블록을 의미함
Swift의 핵심 구성 요소로, 이름과 메타데이터를 기반으로 저장되고 관리됨
Swift Architecture
Swift API
- REST API를 기반으로 작동
- Write
PUT /v1/account/container/object - Read
GET /v1/account/container/object
- Write
- REST API 기반이기에 Swift는 브라우저에서 직접적으로 사용 가능함
ex. Hot Content에 대한 브라우저 캐싱
SwiftStack Controller
- Browser-based Operator Dashboard
웹 브라우저를 통해 관리자 대시보드에 액세스하여 전체 시스템을 제어하고 관리할 수 있도록 제공함 - Storage Configuration and Data Placement Management
저장소 설정과 데이터 배치 관리를 위한 도구를 제공하며, 데이터를 효과적으로 분산 저장하도록 설계함 - Alert, Report, Visualize
시스템 상태에 대한 경고를 제공하고, 보고서를 생성하며 데이터를 시각화하여 관리 효율성을 높임 - System Stats
시스템의 상태와 성능 통계를 실시간으로 모니터링함
SwiftStack Nodes
- Drag and Drop Web Interface
사용자 친화적인 드래그 앤 드롭 방식의 인터페이스를 제공하여 시스템 설정을 간편화함 - SwiftStack Runtime
- Authentication: 데이터 접근을 제어하기 위해 인증을 처리함
- Load Balancing: 데이터 요청을 효율적으로 분산 처리하여 시스템 성능을 최적화함
- Monitoring Agents: 각 노드의 상태를 지속적으로 모니터링하여 시스템 안정성을 보장함
- OpenStack Swift: Swift 오브젝트 스토리지 서비스의 핵심 기능을 실행함
- Standard Linux Distribution: 일반적인 리눅스 배포판을 기반으로 Swift 서비스를 운영함
- Monitoring Agents: 개별 노드의 모니터링 데이터를 수집 및 처리함
-
HTTP
- 클라이언트가 HTTP 프로토콜을 사용하여 Swift에 요청을 보냄
- 데이터 업로드, 다운로드, 삭제 등의 요청이 포함됨
-
Proxy
- 클라이언트의 요청을 수신하고 적절한 서비스로 라우팅하는 역할 수행
- 인증, 데이터 요청 처리, 로드 밸런싱 등의 기능 제공
-
Ring
- 데이터를 저장할 위치를 결정하는 로직을 포함
- 계정(account), 컨테이너(container), 오브젝트(object) 데이터를 각 서비스로 연결
- 데이터 위치를 빠르게 검색할 수 있도록 설계됨
-
Account Service
- 계정 관련 데이터를 관리
- 사용자 계정 정보와 관련된 메타데이터를 처리
-
Container Service
- 컨테이너 관련 데이터를 관리
- 데이터 오브젝트가 포함된 컨테이너의 메타데이터를 처리
-
Object Service
- 실제 데이터 오브젝트를 저장 및 관리
- 데이터의 읽기/쓰기/삭제 요청을 처리하며, 스토리지 디스크에 직접 접근
Data Flow
- 클라이언트가 HTTP를 통해 데이터를 요청하거나 업로드함
- Proxy 서버가 요청을 수신하고 Ring을 참조하여 데이터를 저장하거나 검색할 위치를 결정함
- Ring이 데이터를 계정, 컨테이너, 오브젝트 서비스 중 적합한 서비스로 라우팅함
- 각 서비스는 해당 데이터를 처리하고 응답을 반환함
Swift CLI
-
Account Commands
object store account set: 계정 관련 속성을 설정object store account show: 계정 정보를 조회object store account unset: 계정 관련 속성을 해제
-
Container Commands
container create: 새로운 컨테이너를 생성container delete: 기존 컨테이너를 삭제container list: 모든 컨테이너 목록을 조회container save: 컨테이너 데이터를 저장container set: 컨테이너 속성을 설정container show: 컨테이너 상세 정보를 조회container unset: 설정된 컨테이너 속성을 해제
-
Object Commands
object create: 새로운 객체를 생성하여 저장object delete: 기존 객체를 삭제object list: 객체 목록을 조회object save: 객체 데이터를 저장object set: 객체 속성을 설정object show: 객체 상세 정보를 조회object unset: 설정된 객체 속성을 해제
