1 개요[ | ]
- Host aggregates
- 호스트 집합체, 호스트 애그리게이트
https://docs.openstack.org/nova/2024.1/admin/aggregates
호스트 집합체는 OpenStack 클라우드, 또는 OpenStack 클라우드의 리전에서 호스트를 임의의 특성에 따라 분할하는 메커니즘입니다. 관리자들이 이러한 작업을 수행하는 예시로는 특정 호스트 그룹이 추가적인 하드웨어나 성능 특성을 가지고 있는 경우가 있습니다.
호스트 집합체는 처음에 Xen 하이퍼바이저 리소스 풀을 사용하기 위한 방법으로 시작되었지만, 이제는 관리자가 키-값 쌍을 호스트 그룹에 할당할 수 있는 메커니즘으로 일반화되었습니다. 각 노드는 여러 개의 집합체를 가질 수 있으며, 각 집합체는 여러 개의 키-값 쌍을 가질 수 있고, 동일한 키-값 쌍이 여러 집합체에 할당될 수 있습니다. 이 정보는 스케줄러에서 고급 스케줄링을 가능하게 하거나 Xen 하이퍼바이저 리소스 풀을 설정하거나 마이그레이션을 위한 논리적 그룹을 정의하는 데 사용할 수 있습니다.
호스트 집합체는 사용자에게 명시적으로 노출되지 않습니다. 대신 관리자는 호스트 집합체에 메타데이터를 설정하고, 이를 플레이버 부가 스펙과 매치시켜 호스트 집합체와 플레이버를 매핑합니다. 그런 다음 스케줄러는 주어진 플레이버의 인스턴스 요청을 해당 메타데이터에 동일한 키-값 쌍이 있는 호스트 집합체와 매치시키려고 합니다. 컴퓨트 노드는 여러 호스트 집합체에 속할 수 있습니다. 가중치 배수는 원하는 xxx_weight_multiplier 집합체 메타데이터를 설정하여 집합체별로 제어할 수 있습니다.
관리자는 호스트 집합체를 가용성 영역으로 선택적으로 노출할 수 있습니다. 가용성 영역은 호스트 집합체와 달리 사용자에게 명시적으로 노출되며, 호스트는 하나의 가용성 영역에만 속할 수 있습니다. 관리자는 사용자가 가용성 영역을 지정하지 않았을 때 인스턴스가 스케줄될 기본 가용성 영역을 설정할 수 있습니다. 이에 대한 자세한 내용은 가용성 영역에 관한 문서를 참조하십시오.
Note
가용성 영역 간에 인스턴스를 이동하는 것은 허용되지 않습니다. 호스트를 애그리게이트에 추가하거나 애그리게이트에서 호스트를 제거하는 작업이 인스턴스를 가용성 영역 간에 이동시키는 결과를 초래할 경우, 기본 AZ에서의 이동을 포함하여 이 작업은 거부됩니다. 관리자는 먼저 호스트에서 인스턴스를 비우고 나서 호스트를 이동시킬 수 있습니다.
2 호스트 집합체 지원하도록 스케줄러 설정[ | ]
호스트 집합체의 일반적인 사용사례 중 하나는 특정 기능을 가진 컴퓨트 호스트의 하위집합에 인스턴스를 스케줄링하는 경우입니다. 예를 들어, 사용자가 더 빠른 디스크 I/O에 접근하기 위해 SSD 드라이브를 가진 컴퓨트 호스트를 요청하거나 GPU 가속 코드를 활용하기 위해 GPU 카드를 가진 컴퓨트 호스트에 접근할 수 있도록 하려는 경우입니다.
스케줄러가 호스트 집합체를 지원하도록 구성하려면 filter_scheduler.enabled_filters 설정 옵션에 스케줄러가 사용하는 다른 필터와 함께 AggregateInstanceExtraSpecsFilter가 포함되어야 합니다. 호스트 집합체 필터링과 일반적으로 사용되는 다른 필터를 활성화하기 위해 nova-scheduler 서비스가 실행되는 호스트의 nova.conf 파일에 다음 줄을 추가하십시오:
[filter_scheduler]
enabled_filters=...,AggregateInstanceExtraSpecsFilter
2.1 예시: SSD가 장착된 컴퓨트 호스트 지정[ | ]
이 예제에서는 Compute 서비스가 사용자가 솔리드 스테이트 드라이브(SSD)가 있는 노드를 요청할 수 있도록 설정하는 방법을 설명합니다. nova 가용성 영역에 fast-io 호스트 집합을 생성하고 집합에 ssd=true 키-값 쌍을 추가합니다. 그런 다음, node1과 node2 컴퓨팅 노드를 추가합니다.
$ openstack aggregate create --zone nova fast-io
+-------------------+----------------------------+
| Field | Value |
+-------------------+----------------------------+
| availability_zone | nova |
| created_at | 2016-12-22T07:31:13.013466 |
| deleted | False |
| deleted_at | None |
| id | 1 |
| name | fast-io |
| updated_at | None |
+-------------------+----------------------------+
$ openstack aggregate set --property ssd=true 1
+-------------------+----------------------------+
| Field | Value |
+-------------------+----------------------------+
| availability_zone | nova |
| created_at | 2016-12-22T07:31:13.000000 |
| deleted | False |
| deleted_at | None |
| hosts | [] |
| id | 1 |
| name | fast-io |
| properties | ssd='true' |
| updated_at | None |
+-------------------+----------------------------+
$ openstack aggregate add host 1 node1
+-------------------+--------------------------------------------------+
| Field | Value |
+-------------------+--------------------------------------------------+
| availability_zone | nova |
| created_at | 2016-12-22T07:31:13.000000 |
| deleted | False |
| deleted_at | None |
| hosts | [u'node1'] |
| id | 1 |
| metadata | {u'ssd': u'true', u'availability_zone': u'nova'} |
| name | fast-io |
| updated_at | None |
+-------------------+--------------------------------------------------+
$ openstack aggregate add host 1 node2
+-------------------+--------------------------------------------------+
| Field | Value |
+-------------------+--------------------------------------------------+
| availability_zone | nova |
| created_at | 2016-12-22T07:31:13.000000 |
| deleted | False |
| deleted_at | None |
| hosts | [u'node1', u'node2'] |
| id | 1 |
| metadata | {u'ssd': u'true', u'availability_zone': u'nova'} |
| name | fast-io |
| updated_at | None |
+-------------------+--------------------------------------------------+
openstack flavor create 명령어를 사용하여 ID가 6이고, 8GB RAM, 80GB 루트 디스크, 4개의 vCPU를 갖는 ssd.large 플레이버를 생성하십시오.
$ openstack flavor create --id 6 --ram 8192 --disk 80 --vcpus 4 ssd.large
+----------------------------+-----------+
| Field | Value |
+----------------------------+-----------+
| OS-FLV-DISABLED:disabled | False |
| OS-FLV-EXT-DATA:ephemeral | 0 |
| disk | 80 |
| id | 6 |
| name | ssd.large |
| os-flavor-access:is_public | True |
| ram | 8192 |
| rxtx_factor | 1.0 |
| swap | |
| vcpus | 4 |
+----------------------------+-----------+
플레이버가 생성된 후, 호스트 집합체의 aggregate_instance_extra_specs 스코프에 있는 키-값 쌍과 일치하는 하나 이상의 키-값 쌍을 지정하십시오. 이 경우에는, aggregate_instance_extra_specs:ssd=true 키-값 쌍이 해당됩니다. 플레이버에 키-값 쌍을 설정하는 것은 openstack flavor set 명령을 사용하여 수행합니다.
$ openstack flavor set \
--property aggregate_instance_extra_specs:ssd=true ssd.large
세팅이 되면, ssd.large 플레이버의 extra_specs 속성이 ssd 키와 해당 값 true로 채워진 것을 볼 수 있습니다.
openstack flavor show ssd.large
+----------------------------+-------------------------------------------+
| Field | Value |
+----------------------------+-------------------------------------------+
| OS-FLV-DISABLED:disabled | False |
| OS-FLV-EXT-DATA:ephemeral | 0 |
| disk | 80 |
| id | 6 |
| name | ssd.large |
| os-flavor-access:is_public | True |
| properties | aggregate_instance_extra_specs:ssd='true' |
| ram | 8192 |
| rxtx_factor | 1.0 |
| swap | |
| vcpus | 4 |
+----------------------------+-------------------------------------------+
이제 사용자가 ssd.large 플레이버를 사용하여 인스턴스를 요청할 때, 스케줄러는 ssd=true 키-값 쌍이 있는 호스트만 고려합니다. 이 예제에서는 node1과 node2입니다.
3 Placement에서의 집합체[ | ]
플레이스먼트 내에도 집합체가 존재하며, 이는 nova의 호스트 집합체와는 다릅니다. 이러한 집합체는 관련된 리소스 제공자의 그룹으로 정의됩니다. nova의 컴퓨트 노드는 플레이스먼트에서 리소스 제공자로 표현되기 때문에, 이를 플레이스먼트 집합체에 추가할 수 있습니다. 예를 들어, openstack hypervisor list 명령어를 사용하여 컴퓨트 노드의 UUID를 얻고, openstack resource provider aggregate set 명령어를 사용하여 이를 플레이스먼트 집합체에 추가할 수 있습니다.
다음은 해당 명령어의 예시입니다:
$ openstack --os-compute-api-version=2.53 hypervisor list
+--------------------------------------+---------------------+-----------------+-----------------+-------+
| ID | Hypervisor Hostname | Hypervisor Type | Host IP | State |
+--------------------------------------+---------------------+-----------------+-----------------+-------+
| 815a5634-86fb-4e1e-8824-8a631fee3e06 | node1 | QEMU | 192.168.1.123 | up |
+--------------------------------------+---------------------+-----------------+-----------------+-------+
$ openstack --os-placement-api-version=1.2 resource provider aggregate set \
--aggregate df4c74f3-d2c4-4991-b461-f1a678e1d161 \
815a5634-86fb-4e1e-8824-8a631fee3e06
일부 스케줄링 필터 작업은 속도와 효율성을 높이기 위해 플레이스먼트에서 수행될 수 있습니다.
Note
nova-api 서비스는 nova 18.0.0 버전부터 관리자가 nova 호스트 어그리게이트에 호스트를 추가하거나 제거할 때, 컴퓨트 호스트와 어그리게이트의 연관성을 자동으로 미러링하려고 시도합니다. 이는
openstack resource provider aggregate setCLI 명령어를 사용하여 플레이스먼트 API에서 수동으로 이러한 연관 기록을 생성할 필요를 줄여줍니다.
4 Placement를 통한 테넌트 격리[ | ]
테넌트 격리를 위해 플레이스먼트를 사용하려면 격리에 사용할 노바 호스트 집합의 구성원과 UUID가 일치하는 플레이스먼트 집합체가 있어야 합니다. AggregateMultiTenancyIsolation필터에서 사용하는 것과 동일한 키 패턴이 이 기능을 제어하며, 이를 활성화하려면 scheduler.limit_tenants_to_placement_aggregate를 True로 설정해야 합니다.
$ openstack --os-compute-api-version=2.53 aggregate create myagg
+-------------------+--------------------------------------+
| Field | Value |
+-------------------+--------------------------------------+
| availability_zone | None |
| created_at | 2018-03-29T16:22:23.175884 |
| deleted | False |
| deleted_at | None |
| id | 4 |
| name | myagg |
| updated_at | None |
| uuid | 019e2189-31b3-49e1-aff2-b220ebd91c24 |
+-------------------+--------------------------------------+
$ openstack --os-compute-api-version=2.53 aggregate add host myagg node1
+-------------------+--------------------------------------+
| Field | Value |
+-------------------+--------------------------------------+
| availability_zone | None |
| created_at | 2018-03-29T16:22:23.175884 |
| deleted | False |
| deleted_at | None |
| hosts | [u'node1'] |
| id | 4 |
| name | myagg |
| updated_at | None |
| uuid | 019e2189-31b3-49e1-aff2-b220ebd91c24 |
+-------------------+--------------------------------------+
$ openstack project list -f value | grep 'demo'
9691591f913949818a514f95286a6b90 demo
$ openstack aggregate set \
--property filter_tenant_id=9691591f913949818a514f95286a6b90 myagg
$ openstack --os-placement-api-version=1.2 resource provider aggregate set \
--aggregate 019e2189-31b3-49e1-aff2-b220ebd91c24 \
815a5634-86fb-4e1e-8824-8a631fee3e06
filter_tenant_id 메타데이터 키는 선택적으로 문자열을 추가하여 여러 테넌트를 구분할 수 있습니다. 예를 들어, filter_tenant_id3=$tenantid와 같이 사용할 수 있습니다.
5 사용법[ | ]
호스트 집합체의 구성은 대부분 API나 명령줄 클라이언트를 통해 이루어집니다. 예를 들어, openstack 클라이언트를 사용하여 새 집합체를 만들고 호스트를 추가하려면 다음 명령어를 실행합니다:
$ openstack aggregate create my-aggregate
$ openstack aggregate add host my-aggregate my-host
모든 집합체를 나열하고 특정 집합체에 대한 정보를 표시하려면 다음 명령어를 실행합니다:
$ openstack aggregate list
$ openstack aggregate show my-aggregate
집합체에 속성을 설정하거나 해제하려면 다음 명령어를 실행합니다:
$ openstack aggregate set --property pinned=true my-aggregate
$ openstack aggregate unset --property pinned my-aggregate
집합체의 이름을 변경하려면 다음 명령어를 실행합니다:
$ openstack aggregate set --name my-awesome-aggregate my-aggregate
집합체에서 호스트를 제거하고 집합체를 삭제하려면 다음 명령을 실행합니다:
$ openstack aggregate remove host my-aggregate my-host
$ openstack aggregate delete my-aggregate
더 많은 정보는 OpenStack 클라이언트 문서를 참조하십시오.
6 설정[ | ]
API와 클라이언트에서 사용가능한 CRUD 작업 외에도, 호스트 집합체와 관련 가용성 영역 기능이 내부적으로 작동하는 방식을 설정하는 데 사용할 수 있는 다음 설정 옵션이 있습니다:
마지막으로, 앞서 논의한 바와 같이 여러 호스트 집합별 스케줄러 필터가 있습니다. 이 필터들은 다음과 같습니다:
- AggregateImagePropertiesIsolation
- AggregateInstanceExtraSpecsFilter
- AggregateIoOpsFilter
- AggregateMultiTenancyIsolation
- AggregateNumInstancesFilter
- AggregateTypeAffinityFilter
다음 설정 옵션은 스케줄러 설정에 적용됩니다:
- cpu_allocation_ratio
- ram_allocation_ratio
- filter_scheduler.max_instances_per_host
- filter_scheduler.aggregate_image_properties_isolation_separator
- filter_scheduler.aggregate_image_properties_isolation_namespace
7 이미지 캐싱[ | ]
집합체는 여러 컴퓨트 노드에 대해 타겟팅할 수 있는 방법으로 사용되어 이미지가 성능 향상을 위해 미리 캐싱되도록 요청할 수 있습니다.
Note
일부 virt 드라이버는 이미지 캐싱 지원을 제공하며, 이는 동일 이미지의 두 번째 및 이후 부팅 성능을 향상시킵니다. 이는 기본 이미지를 온디스크 캐시에 보관하여 Glance에서 이미지를 다시 다운로드할 필요가 없도록 하여 네트워크 사용량과 부팅 지연 시간을 줄입니다. 이미지 프리캐싱은 캐시를 사전에 이미지로 채워 첫 부팅 성능을 향상시키는 작업입니다.
두 개의 이미지가 프리캐싱되어야 하는 my-aggregate라는 집합체를 가정하고, 다음 명령어를 실행하면 요청이 시작됩니다:
nova aggregate-cache-images my-aggregate image1 image2
이미지 프리캐싱은 비동기식으로 최선의 노력 방식으로 이루어집니다. 명령어가 실행될 때 서버는 제공된 이미지와 집합체를 확인하지만, 프로세스가 실행될 때까지 컴퓨트 노드가 이미지 캐싱을 지원하는지 확인하지 않습니다. 진행상황과 결과는 각 컴퓨트에 의해 로그에 기록되며, 프로세스는 외부에서 작업을 모니터링하는 데 유용할 수 있는 aggregate.cache_images.start, aggregate.cache_images.progress, aggregate.cache_images.end 알림을 보냅니다.
8 참고자료[ | ]
9 같이 보기[ | ]
-
{{comment.page_title}} ―{{comment.name}}