Nova 컴퓨트 스케줄러 편집하기

==개요==
[[분류: 미완성]]
[[분류: Nova]]
;Compute schedulers
;컴퓨트 스케줄러
* https://docs.openstack.org/nova/2024.1/admin/scheduling.html

Compute는 <code>nova-scheduler</code> 서비스를 사용하여 컴퓨팅 요청을 처리할 호스트나 노드를 결정합니다. 예를 들어, <code>nova-scheduler</code> 서비스는 VM이 실행될 호스트나 노드를 결정합니다. 스케줄러는 다양한 옵션으로 설정할 수 있습니다.

기본 설정에서는 스케줄러가 다음 기준을 모두 충족하는 호스트를 고려합니다:

* 요청된 [https://docs.openstack.org/nova/2024.1/reference/glossary.html#term-Availability-Zone 가용성 영역](map_az_to_placement_aggregate)에 배치(placement) 프리필터에 있음
* 요청을 처리할 수 있으며, 타겟 노드를 처리하는 nova-compute 서비스가 사용 가능하고 비활성화되지 않음 (ComputeFilter)
* 인스턴스 유형과 관련된 추가 사양 충족 (ComputeCapabilitiesFilter)
* 인스턴스 이미지 속성에 지정된 아키텍처, 하이퍼바이저 유형 또는 가상머신 모드 속성 충족 (ImagePropertiesFilter)
* (요청된 경우) 그룹의 다른 인스턴스와 다른 호스트에 있음 (ServerGroupAntiAffinityFilter)
* (요청된 경우) 그룹 호스트 세트에 있음 (ServerGroupAffinityFilter)

인스턴스가 마이그레이션, 크기조정, 대피, 쉘브 오프로딩 후 다시 언쉘브되는 경우 스케줄러는 새로운 호스트를 선택합니다.

호스트에서 인스턴스를 대피시킬 때, 스케줄러 서비스는 관리자에 의해 '''nova evacuate''' 명령어에서 정의된 대상 호스트를 존중합니다. 관리자가 대상을 정의하지 않은 경우, 스케줄러가 대상 호스트를 결정합니다. 인스턴스 대피에 대한 정보는 [https://docs.openstack.org/nova/2024.1/admin/node-down.html#node-down-evacuate-instances 인스턴스 대피]를 참조하십시오.

==프리필터==
Rocky 릴리스부터 스케줄링 프로세스에는 프리필터 단계가 추가되어 후속 단계의 효율성이 향상되었습니다. 이러한 프리필터는 대부분 선택사항이며, 배치에 전송되는 요청을 보완하여 배치가 미리 답변할 수 있는 속성을 기반으로 후보 컴퓨트 호스트의 집합를 줄이는 데 도움이 됩니다. 여기 나열된 프리필터 외에도 [https://docs.openstack.org/nova/2024.1/admin/aggregates.html#tenant-isolation-with-placement 배치를 사용한 테넌트 격리] 및 [https://docs.openstack.org/nova/2024.1/admin/availability-zones.html#availability-zones-with-placement 배치를 사용한 가용성 영역]도 참조하십시오.

===컴퓨트 이미지 타입 지원===
''버전 20.0.0 (Train)에서 새로 추가됨''

Train 릴리스부터 부팅 요청에 사용된 이미지의 디스크 포맷을 지원하지 않는 컴퓨트 노드를 제외하는 프리필터가 제공됩니다. 이 동작은 scheduler.query_placement_for_image_type_support를 True로 설정하여 활성화할 수 있습니다. 예를 들어, ceph를 일시적 백엔드로 사용하는 libvirt 드라이버는 qcow2 이미지를 지원하지 않습니다(비용이 많이 드는 변환 단계를 거치지 않는 한). 이 경우(특히 ceph와 비-ceph 기반 컴퓨트가 혼합된 경우), 이 기능을 활성화하면 스케줄러가 qcow2 이미지를 부팅하기 위한 요청을 ceph 기반 컴퓨트에 보내지 않도록 할 수 있습니다.

===컴퓨트 비활성화 상태 지원===
''버전 20.0.0 (Train)에서 새로 추가됨''

Train 릴리스부터 비활성화된 컴퓨트 노드를 제외하는 필수 프리필터가 추가되었습니다. 이는 ComputeFilter와 유사하지만 완전히 대체하지는 않습니다. COMPUTE_STATUS_DISABLED 특성이 있는 컴퓨트 노드 리소스 제공자는 스케줄링 후보에서 제외됩니다. 이 특성은 nova-compute 서비스에 의해 관리되며 os-services API의 관련 컴퓨트 서비스 레코드에서 비활성화된 상태를 반영해야 합니다. 예를 들어, 컴퓨트 서비스의 상태가 비활성화된 경우 해당 서비스에 대한 관련 컴퓨트 노드 리소스 제공자는 COMPUTE_STATUS_DISABLED 특성을 가져야 합니다. 서비스 상태가 활성화되면 COMPUTE_STATUS_DISABLED 특성이 제거됩니다.

상태가 변경될 때 컴퓨트 서비스가 다운되어 있는 경우, 컴퓨트 서비스가 재시작될 때 특성이 동기화됩니다. 마찬가지로, 특정 리소스 제공자에서 특성을 추가하거나 제거하는 동안 오류가 발생하면 update_resources_interval 설정 옵션에 의해 제어되는 update_available_resource 주기적 작업이 실행될 때 특성이 동기화됩니다.

===격리된 집합체===
''버전 20.0.0 (Train)에서 새로 추가됨''

Train 릴리스부터 선택적 배치 사전 요청 필터가 추가되었습니다. 격리된 집합체를 통해 호스트 필터링을 수행합니다. 활성화된 경우, 서버의 플레이버 및 이미지에서 요구하는 특성은 해당 집합체 메타데이터에서 요구하는 특성 이상이어야 서버가 해당 집합체의 호스트에서 부팅될 수 있습니다.

==필터 스케줄러==
''버전 23.0.0 (Wallaby)에서 변경됨''

''커스텀 스케줄러 드라이버에 대한 지원이 제거되었습니다. 이제 nova는 필터 스케줄러만 지원합니다.''

Nova의 스케줄러, 즉 필터 스케줄러는 필터링과 가중치를 통해 새로운 인스턴스를 생성할 위치에 대한 정보를 기반으로 결정을 내릴 수 있습니다.

스케줄러가 리소스 요청을 수신하면 먼저 필터를 적용하여 리소스를 배치할 때 고려할 수 있는 호스트를 결정합니다. 필터는 이진 필터로, 호스트가 필터에 의해 수락되거나 거부됩니다. 필터에 의해 수락된 호스트는 요청에 사용할 호스트를 결정하는 다른 알고리즘에 의해 처리되며, 이는 가중치 섹션에서 설명됩니다.

;필터링
[[파일:filtering-workflow-1.png]]

<code>[https://docs.openstack.org/nova/2024.1/configuration/config.html#filter_scheduler.available_filters filter_scheduler.available_filters]</code> 설정 옵션은 스케줄러가 사용할 수 있는 필터 목록을 컴퓨팅 서비스에 제공합니다. 기본 설정은 컴퓨팅 서비스에 포함된 모든 필터를 지정합니다. 이 설정 옵션은 여러 번 지정할 수 있습니다. 예를 들어, Python으로 만든 커스텀 필터인 <code>myfilter.MyFilter</code>를 구현하고 빌트인 필터와 커스텀 필터를 모두 사용하려면 <code>nova.conf</code> 파일에 다음과 같이 입력합니다:

<syntaxhighlight lang='ini'>
[filter_scheduler]
available_filters = nova.scheduler.filters.all_filters
available_filters = myfilter.MyFilter
</syntaxhighlight>

<code>nova.conf</code>의 <code>[https://docs.openstack.org/nova/2024.1/configuration/config.html#filter_scheduler.enabled_filters filter_scheduler.enabled_filters]</code> 설정 옵션은 <code>nova-scheduler</code> 서비스에서 적용하는 필터 목록을 정의합니다.

==필터==
다음 섹션에서는 사용가능한 컴퓨트 필터들에 대해 설명합니다.

필터는 다음 설정 옵션을 사용하여 설정됩니다:
* <code>[https://docs.openstack.org/nova/2024.1/configuration/config.html#filter_scheduler.available_filters filter_scheduler.available_filters]</code> - 스케줄러에서 사용가능한 필터 클래스를 정의합니다. 이 설정은 여러 번 사용할 수 있습니다.
* <code>[https://docs.openstack.org/nova/2024.1/configuration/config.html#filter_scheduler.enabled_filters filter_scheduler.enabled_filters]</code> - 사용가능한 필터 중 스케줄러가 기본적으로 사용하는 필터를 정의합니다.

각 필터는 호스트를 선택하는 방식이 다르며, 비용도 다릅니다. <code>[https://docs.openstack.org/nova/2024.1/configuration/config.html#filter_scheduler.enabled_filters filter_scheduler.enabled_filters]</code>의 순서는 스케줄링 성능에 영향을 미칩니다. 일반적인 제안으로는, 불필요한 비용을 피하기 위해 가능한 한 빨리 유효하지 않은 호스트를 필터링하는 것입니다. 우리는 <code>[https://docs.openstack.org/nova/2024.1/configuration/config.html#filter_scheduler.enabled_filters filter_scheduler.enabled_filters]</code> 항목을 비용에 따라 역순으로 정렬할 수 있습니다. 예를 들어, <code>ComputeFilter</code>는 <code>NUMATopologyFilter</code>와 같은 리소스 계산 필터보다 앞에 있는 것이 좋습니다.

===<code>AggregateImagePropertiesIsolation</code>===
''버전 12.0.0 (Liberty)에서 변경됨''

''버전 12.0.0 Liberty 이전에는 이 필터에서 임의의 메타데이터를 지정하고 사용할 수 있었습니다. Liberty부터 nova는 [https://docs.openstack.org/glance/2024.1/admin/useful-image-properties.html 표준 메타데이터]만을 파싱합니다. 임의의 메타데이터를 사용하려면 [https://docs.openstack.org/nova/2024.1/admin/scheduling.html#aggregateinstanceextraspecsfilter AggregateInstanceExtraSpecsFilter] 필터를 사용하는 것이 좋습니다.''

이미지의 메타데이터에 정의된 속성을 집합체와 비교하여 호스트 매치를 결정합니다:

* 호스트가 집합체에 속하고 집합체가 이미지의 속성과 일치하는 하나 이상의 메타데이터를 정의하면, 그 호스트는 해당 이미지를 부팅할 후보가 됩니다.
* 호스트가 어떤 집합체에도 속하지 않으면, 모든 이미지로부터 인스턴스를 부팅할 수 있습니다.

예를 들어, 다음과 같은 <code>myWinAgg</code> 집합체는 Windows 운영체제를 메타데이터로 가지고 있습니다(이름은 'windows'):

<syntaxhighlight lang='console'>
$ openstack aggregate show myWinAgg
+-------------------+----------------------------+
| Field             | Value                      |
+-------------------+----------------------------+
| availability_zone | zone1                      |
| created_at        | 2017-01-01T15:36:44.000000 |
| deleted           | False                      |
| deleted_at        | None                       |
| hosts             | ['sf-devel']               |
| id                | 1                          |
| name              | myWinAgg                   |
| properties        | os_distro='windows'        |
| updated_at        | None                       |
+-------------------+----------------------------+
</syntaxhighlight>

이 예시에서, 다음과 같은 Win-2012 이미지는 <code>windows</code> 속성을 가지므로 <code>sf-devel</code> 호스트에서 부팅됩니다(다른 모든 필터가 동일한 경우):

<syntaxhighlight lang='console'>
$ openstack image show Win-2012
+------------------+------------------------------------------------------+
| Field            | Value                                                |
+------------------+------------------------------------------------------+
| checksum         | ee1eca47dc88f4879d8a229cc70a07c6                     |
| container_format | bare                                                 |
| created_at       | 2016-12-13T09:30:30Z                                 |
| disk_format      | qcow2                                                |
| ...                                                                     |
| name             | Win-2012                                             |
| ...                                                                     |
| properties       | os_distro='windows'                                  |
| ...                                           
</syntaxhighlight>

다음 옵션을 <code>nova.conf</code> 파일에 사용하여 <code>AggregateImagePropertiesIsolation</code> 필터를 설정할 수 있습니다:

* [https://docs.openstack.org/nova/2024.1/configuration/config.html#filter_scheduler.aggregate_image_properties_isolation_namespace filter_scheduler.aggregate_image_properties_isolation_namespace]
* [https://docs.openstack.org/nova/2024.1/configuration/config.html#filter_scheduler.aggregate_image_properties_isolation_separator filter_scheduler.aggregate_image_properties_isolation_separator]

{{NOTE}}
이 필터는 [https://bugs.launchpad.net/nova/+bug/1677217 버그 1677217]에 설명된대로 제한사항이 있으며, 이는 배치 필터링 호스트의 격리된 집합체 요청 필터로 해결됩니다.
{{/NOTE}}

자세한 내용은 [https://docs.openstack.org/nova/2024.1/admin/aggregates.html 호스트 집합체]를 참조하십시오.

===<code>AggregateInstanceExtraSpecsFilter</code>===
인스턴스 유형의 추가 사양에 정의된 속성을 호스트 애그리게이트의 관리자 정의 속성과 비교합니다. <code>aggregate_instance_extra_specs</code>로 스코프가 지정된 사양과 함께 작동합니다. 여러 값은 쉼표로 구분된 목록으로 제공될 수 있습니다. 하위호환성을 위해, 스코프가 지정되지 않은 사양과도 작동하지만, 이 작업은 [https://docs.openstack.org/nova/2024.1/admin/scheduling.html#computecapabilitiesfilter ComputeCapabilitiesFilter] 필터를 둘 다 활성화할 경우 충돌하기 때문에 강력히 권장되지 않습니다.

자세한 내용은 [https://docs.openstack.org/nova/2024.1/admin/aggregates.html 호스트 집합체]를 참조하십시오.

===<code>AggregateIoOpsFilter</code>===
각 집합체의 최대 IO 작업 수(<code>max_io_ops_per_host</code>) 값을 사용하여 호스트를 디스크 할당으로 필터링합니다. 각 집합체의 값이 발견되지 않으면  :oslo.config:option:`filter_scheduler.max_io_ops_per_host 설정 옵션에 정의된 전역 설정 값으로 대체됩니다. 호스트가 둘 이상의 집합체에 속해 있고 둘 이상의 값이 발견되면, 최소 값이 사용됩니다.

자세한 내용은 '[https://docs.openstack.org/nova/2024.1/admin/aggregates.html 호스트 집합체] 및 [https://docs.openstack.org/nova/2024.1/admin/scheduling.html#ioopsfilter IoOpsFilter]'를 참조하세요.

===<code>AggregateMultiTenancyIsolation</code>===
호스트 집합체에서 특정 테넌트 집합체에만 사용할 수 있도록 호스트를 테넌트로 격리합니다. 만약 호스트가 <code>filter_tenant_id</code> 메타데이터 키를 가진 집합체에 속해 있다면, 해당 호스트는 그 테넌트 또는 쉼표로 구분된 여러 테넌트에서만 인스턴스를 생성할 수 있습니다. 호스트는 서로 다른 집합체에 속할 수 있습니다. 만약 호스트가 메타데이터 키를 가진 집합체에 속하지 않는다면, 모든 테넌트에서 인스턴스를 생성할 수 있습니다. 이는 테넌트가 테넌트 격리 집합체 외부의 호스트에서 서버를 생성하는 것을 제한하지 않습니다.

예를 들어, 스케줄링에 사용가능한 호스트가 HostA와 HostB 두 개가 있다고 가정해봅시다. HostB는 테넌트 X에 격리된 집합체에 속해 있습니다. 테넌트 X에서 서버 생성 요청을 하면 스케줄링 시 HostA 또는 HostB가 후보가 됩니다. 다른 테넌트 Y에서 서버 생성 요청을 하면 HostA만 테넌트 격리 집합체에 속하지 않기 때문에 스케줄링 후보가 됩니다.

{{NOTE}}
이 필터를 사용하여 각 집합체마다 격리할 수 있는 테넌트 수에는 알려진 제한이 있습니다. 그러나 이 제한은 18.0.0 Rocky 릴리스에서 추가된 Placement 필터링 기능을 사용한 테넌트 격리에는 적용되지 않습니다.
{{/NOTE}}

===<code>AggregateNumInstancesFilter</code>===
호스트 집합체 내에서 인스턴스 수에 따라 호스트를 필터링하며, 집합체별 <code>max_instances_per_host</code> 값을 사용합니다. 만약 집합체별 값이 지정되지 않은 경우, <code>[https://docs.openstack.org/nova/2024.1/configuration/config.html#filter_scheduler.max_instances_per_host filter_scheduler.max_instances_per_host]</code> 설정 옵션에 정의된 전역 설정 값으로 대체됩니다. 호스트가 둘 이상의 집합체에 속해 있고 따라서 둘 이상의 값이 발견되는 경우, 최솟값이 사용됩니다.

자세한 내용은 [https://docs.openstack.org/nova/2024.1/admin/aggregates.html 호스트 집합체]와 [https://docs.openstack.org/nova/2024.1/admin/scheduling.html#numinstancesfilter NumInstancesFilter]를 참조하십시오.

===<code>AggregateTypeAffinityFilter</code>===
호스트 집합의 메타데이터에 설정된 <code>instance_type</code> 키의 이름이 인스턴스의 flavor 이름과 일치하거나 <code>instance_type</code> 키가 설정되지 않은 경우 해당 집합의 호스트를 필터링합니다.

<code>instance_type</code> 메타데이터 항목의 값은 단일 <code>instance_type</code> 이름 또는 <code>m1.nano</code>나 <code>m1.nano,m1.small</code>과 같이 쉼표로 구분된 <code>instance_type</code> 이름 목록일 수 있는 문자열입니다.

{{NOTE}}
인스턴스 타입(Instance type)은 플레이버(flavor)의 옛 이름입니다.
{{/NOTE}}

자세한 내용은 [https://docs.openstack.org/nova/2024.1/admin/aggregates.html 호스트 집합체]를 참조하십시오.

===<code>AllHostsFilter</code>===
이것은 아무런 작업도 하지 않는 필터입니다. 사용가능한 호스트를 제거하지 않습니다.

===<code>ComputeCapabilitiesFilter</code>===
호스트를 필터링하여 flavor의 엑스트라 스펙에 정의된 속성을 컴퓨팅 기능과 매칭합니다. 엑스트라 스펙 키에 콜론(:)이 포함된 경우, 콜론 앞의 모든 내용은 네임스페이스로 간주되고 콜론 뒤의 모든 내용은 매칭할 키로 간주됩니다. 네임스페이스가 존재하고 <code>capabilities</code>가 아닌 경우, 필터는 네임스페이스를 무시합니다. 예를 들어, <code>capabilities:cpu_info:features</code>는 유효한 스코프 형식입니다. 하위호환성을 위해, 필터는 네임스페이스가 없는 경우에도 엑스트라 스펙 키를 매칭할 키로 간주합니다. 그러나 이 방법은 [https://docs.openstack.org/nova/2024.1/admin/scheduling.html#aggregateinstanceextraspecsfilter AggregateInstanceExtraSpecsFilter] 필터를 활성화한 경우 충돌을 일으킬 수 있으므로 권장되지 않습니다.

엑스트라 스펙은 키/값 쌍의 값 문자열 앞에 연산자를 가질 수 있습니다. 연산자가 지정되지 않은 경우 기본 연산자는 <code>s==</code>입니다. 유효한 연산자는 다음과 같습니다:

* <code>=</code> (숫자로서 같거나 큰 값; vcpus 경우와 동일)
* <code>==</code> (숫자로서 같은 값)
* <code>!=</code> (숫자로서 다른 값)
* <code>=</code> (숫자로서 같거나 큰 값)
* <code><=</code> (숫자로서 같거나 작은 값)
* <code>s==</code> (문자열로서 같은 값)
* <code>s!=</code> (문자열로서 다른 값)
* <code>s>=</code> (문자열로서 같거나 큰 값)
* <code>s></code> (문자열로서 큰 값)
* <code>s<=</code> (문자열로서 같거나 작은 값)
* <code>s<</code> (문자열로서 작은 값)
* <code><in></code> (부분 문자열)
* <code><all-in></code> (컬렉션에 포함된 모든 요소)
* <code><or></code> (이 중 하나를 찾기)

예시: <code>>= 5</code>, <code>s== 2.1.0</code>, <code><in> gcc</code>, <code><all-in> aes mmx</code>, <code><or> fpu <or> gpu</code>

사용할 수 있는 유용한 키와 그 값의 예시는 다음과 같습니다:

* <code>free_ram_mb</code> (숫자로 비교, 예: <code>>= 4096</code>)
* <code>free_disk_mb</code> (숫자로 비교, 예: <code>>= 10240</code>)
* <code>host</code> (문자열로 비교, 예: <code><in> compute</code>, <code>s== compute_01</code>)
* <code>hypervisor_type</code> (문자열로 비교, 예: <code>s== QEMU</code>, <code>s== ironic</code>)
* <code>hypervisor_version</code> (숫자로 비교, 예: <code>>= 1005003</code>, <code>== 2000000</code>)
* <code>num_instances</code> (숫자로 비교, 예: <code><= 10</code>)
* <code>num_io_ops</code> (숫자로 비교, 예: <code><= 5</code>)
* <code>vcpus_total</code> (숫자로 비교, 예: <code>= 48</code>, <code>>=24</code>)
* <code>vcpus_used</code> (숫자로 비교, 예: <code>= 0</code>, <code><= 10</code>)

일부 virt 드라이버는 CPU 특성을 Placement 서비스에 보고하는 기능을 지원합니다. 이 기능이 사용가능한 경우, <code>ComputeCapabilitiesFilter</code> 대신 flavor에서 특성을 사용하는 것을 고려해야 합니다. 특성은 일부 virt 드라이버에서 CPU 기능에 대해 일관된 네이밍을 제공하며, 특성 쿼리는 효율적입니다. 자세한 내용은 [https://docs.openstack.org/nova/2024.1/user/support-matrix.html 기능 지원 매트릭스], [https://docs.openstack.org/nova/2024.1/user/flavors.html#extra-specs-required-traits 필수 특성], [https://docs.openstack.org/nova/2024.1/user/flavors.html#extra-specs-forbidden-traits 금지된 특성], [https://specs.openstack.org/openstack/nova-specs/specs/rocky/approved/report-cpu-features-as-traits.html CPU 기능을 Placement 서비스에 보고하기]를 참조하십시오.

또한 [https://docs.openstack.org/nova/2024.1/admin/scheduling.html#id19 특성으로서의 컴퓨트 능력(Compute capabilities as traits)]도 참조하십시오.

==<code>ComputeFilter</code>==
운영 중이고 활성화된 모든 호스트를 통과시킵니다.

일반적으로, 이 필터는 항상 활성화해야 합니다.

==<code>DifferentHostFilter</code>==
인스턴스를 일련의 인스턴스와 다른 호스트에 배치합니다. 이 필터를 사용하려면 요청자가 <code>different_host</code>를 키로 사용하고 인스턴스 UUID의 리스트를 값으로 사용하는 스케줄러 힌트를 전달해야 합니다. 이 필터는 <code>SameHostFilter</code>의 반대입니다.

예를 들어, '''openstack server create''' 명령을 사용할 때, --hint 플래그를 사용하세요:

<syntaxhighlight lang='console'>
$ openstack server create \
  --image cedef40a-ed67-4d10-800e-17455edce175 --flavor 1 \
  --hint different_host=a0cf03a5-d921-4877-bb5c-86d26cf818e1 \
  --hint different_host=8c19174f-4220-44f0-824a-cd1eeef10287 \
  server-1
</syntaxhighlight>

API를 사용할 때는 <code>os:scheduler_hints</code> 키를 사용하세요. 예를 들어:

<syntaxhighlight lang='json'>
{
    "server": {
        "name": "server-1",
        "imageRef": "cedef40a-ed67-4d10-800e-17455edce175",
        "flavorRef": "1"
    },
    "os:scheduler_hints": {
        "different_host": [
            "a0cf03a5-d921-4877-bb5c-86d26cf818e1",
            "8c19174f-4220-44f0-824a-cd1eeef10287"
        ]
    }
}
</syntaxhighlight>

===<code>ImagePropertiesFilter</code>===
인스턴스 이미지에 정의된 속성을 기반으로 호스트를 필터링합니다. 인스턴스에 포함된 특정 이미지 속성을 지원할 수 있는 호스트를 통과시킵니다. 속성에는 아키텍처, 하이퍼바이저 유형, 하이퍼바이저 버전, 가상머신 모드가 포함됩니다.

예를 들어, 인스턴스가 ARM 기반 프로세서와 QEMU 하이퍼바이저를 실행하는 호스트가 필요할 수 있습니다. 다음 명령어를 사용하여 이미지를 이들 속성으로 꾸밀 수 있습니다:

<syntaxhighlight lang='console'>
$ openstack image set --architecture arm --property img_hv_type=qemu img-uuid
</syntaxhighlight>

필터가 확인하는 이미지 속성은 다음과 같습니다:

;hw_architecture
이미지가 요구하는 머신 아키텍처를 설명합니다. 예시로는 <code>i686</code>, <code>x86_64</code>, <code>arm</code>, <code>ppc64</code> 등이 있습니다.

''버전 12.0.0 (Liberty)에서 변경됨''

''이전에는 <code>architecture</code>라고 불렸습니다.''

;img_hv_type
이미지가 요구하는 하이퍼바이저를 설명합니다. 예시로는 <code>qemu</code>가 있습니다.

{{NOTE}}
<code>qemu</code>는 QEMU와 KVM 하이퍼바이저 유형 모두에 사용됩니다.
{{/NOTE}}

''버전 12.0.0 (Liberty)에서 변경됨''

''이전에는 hypervisor_type이라고 불렸습니다.''

;img_hv_requested_version
이미지가 요구하는 하이퍼바이저 버전을 설명합니다. 이 속성은 HyperV 하이퍼바이저 유형에만 지원됩니다. 여러 하이퍼바이저 버전에 대한 지원을 가능하게 하고, 최신 HyperV 도구가 있는 인스턴스가 이전 버전의 하이퍼바이저에서 프로비저닝되는 것을 방지하기 위해 사용할 수 있습니다. 사용가능한 경우, 속성 값은 컴퓨팅 호스트의 하이퍼바이저 버전과 비교됩니다.

하이퍼바이저 버전으로 호스트를 필터링하려면, 이미지 메타데이터에 <code>img_hv_requested_version</code> 속성을 추가하고 연산자와 필요한 하이퍼바이저 버전을 값으로 전달합니다:

<syntaxhighlight lang='console'>
$ openstack image set --property hypervisor_type=qemu --property hypervisor_version_requires=">=6000" img-uuid
</syntaxhighlight>

''버전 12.0.0 (Liberty)에서 변경됨''

''이전에는 <code>hypervisor_version_requires</code>라고 불렸습니다.''

;hw_vm_mode
이미지가 요구하는 하이퍼바이저 애플리케이션 바이너리 인터페이스(ABI)를 설명합니다. 예시로는 Xen 3.0 파라버추얼 ABI를 위한 <code>xen</code>, 네이티브 ABI를 위한 <code>hvm</code>, 컨테이너 virt 실행 가능 ABI를 위한 <code>exe</code> 등이 있습니다.

''버전 12.0.0 (Liberty)에서 변경됨''

''이전에는 <code>vm_mode</code>라고 불렸습니다.''

===<code>IsolatedHostsFilter</code>===
관리자가 특별한 (격리된) 이미지 집합과 특별한 (격리된) 호스트 집합을 정의할 수 있도록 하며, 격리된 이미지는 격리된 호스트에서만 실행될 수 있고, 격리된 호스트는 격리된 이미지에서만 실행될 수 있습니다. <code>restrict_isolated_hosts_to_isolated_images</code> 플래그를 사용하여 격리된 호스트가 격리된 이미지에서만 실행되도록 강제할 수 있습니다.

필터 내 로직은 <code>restrict_isolated_hosts_to_isolated_images</code> 설정 옵션에 따라 달라지며, 기본값은 True입니다. True일 때는 볼륨 기반 인스턴스가 격리된 호스트에 배치되지 않습니다. False일 때는 볼륨 기반 인스턴스가 격리된 호스트와 상관없이 모든 호스트에 배치될 수 있습니다.

관리자는 <code>[https://docs.openstack.org/nova/2024.1/configuration/config.html#filter_scheduler.isolated_hosts filter_scheduler.isolated_hosts]</code>와 <code>[https://docs.openstack.org/nova/2024.1/configuration/config.html#filter_scheduler.isolated_images filter_scheduler.isolated_images]</code> 설정 옵션을 사용하여 격리된 이미지 및 호스트 집합을 지정해야 합니다. 예를 들어:

<syntaxhighlight lang='ini'>
[filter_scheduler]
isolated_hosts = server1, server2
isolated_images = 342b492c-128f-4a42-8d3a-c5088cf27d13, ebd267a6-ca86-4d6c-9a0e-bd132d6b7d09
</syntaxhighlight>

격리된 호스트가 특정 격리된 이미지에서만 사용되도록 하려면 <code>[https://docs.openstack.org/nova/2024.1/configuration/config.html#filter_scheduler.restrict_isolated_hosts_to_isolated_images filter_scheduler.restrict_isolated_hosts_to_isolated_images]</code> 설정 옵션을 지정할 수도 있습니다.

===<code>IoOpsFilter</code>===
호스트의 동시 I/O 작업 수에 따라 호스트를 필터링합니다. 동시 I/O 작업이 너무 많은 호스트는 필터링됩니다. <code>[https://docs.openstack.org/nova/2024.1/configuration/config.html#filter_scheduler.max_io_ops_per_host filter_scheduler.max_io_ops_per_host]</code> 옵션은 호스트에서 실행할 수 있는 I/O 집약적 인스턴스의 최대 수를 지정합니다. 빌드, 크기조정, 스냅샷, 마이그레이션, 복구 또는 언셸브 작업 상태에서 <code>[https://docs.openstack.org/nova/2024.1/configuration/config.html#filter_scheduler.max_io_ops_per_host filter_scheduler.max_io_ops_per_host]</code> 인스턴스보다 많은 인스턴스가 실행 중인 경우 스케줄러는 해당 호스트를 무시합니다.

===<code>JsonFilter</code>===
{{WARNING}}
이 필터는 기본적으로 활성화되지 않으며 종합적으로 테스트되지 않았으므로 명확하지 않은 방식으로 예상과 다르게 작동할 수 있습니다. 또한, 이 필터 변수는 릴리스마다 변경될 수 있는 [https://opendev.org/openstack/nova/src/branch/master/nova/scheduler/host_manager.py HostState] 클래스의 속성을 기반으로 하기 때문에 사용이 일반적으로 권장되지 않습니다. [https://docs.openstack.org/nova/2024.1/admin/scheduling.html#imagepropertiesfilter ImagePropertiesFilter] 또는 [https://docs.openstack.org/nova/2024.1/user/flavors.html#extra-specs-required-traits 특성 기반 스케줄링]과 같은 다른 필터를 사용하는 것을 고려하십시오.
{{/WARNING}}

사용자가 JSON 형식으로 스케줄러 힌트를 전달하여 커스텀 필터를 구성할 수 있도록 합니다. 다음 연산자를 지원합니다:

* <code>=</code>
* <code><</code>
* <code>in</code>
* <code><=</code>
* <code>=</code>
* <code>not</code>
* <code>or</code>
* <code>and</code>

대부분의 다른 필터와 달리 스케줄러 힌트를 통해 제공된 정보에 의존하지 않고 다음과 같은 [https://opendev.org/openstack/nova/src/branch/master/nova/scheduler/host_manager.py HostState] 클래스의 속성에 필터링합니다:

* <code>$free_ram_mb</code>
* <code>$free_disk_mb</code>
* <code>$hypervisor_hostname</code>
* <code>$total_usable_ram_mb</code>
* <code>$vcpus_total</code>
* <code>$vcpus_used</code>

'''openstack server create''' 명령어를 사용할 때 <code>--hint</code> 플래그를 사용하십시오:

<syntaxhighlight lang='console'>
$ openstack server create --image 827d564a-e636-4fc4-a376-d36f7ebe1747 \
  --flavor 1 --hint query='[">=","$free_ram_mb",1024]' server1
</syntaxhighlight>

API를 사용할 때는 <code>os:scheduler_hints</code> 키를 사용하십시오:

<syntaxhighlight lang='json'>
{
    "server": {
        "name": "server-1",
        "imageRef": "cedef40a-ed67-4d10-800e-17455edce175",
        "flavorRef": "1"
    },
    "os:scheduler_hints": {
        "query": "[\">=\",\"$free_ram_mb\",1024]"
    }
}
</syntaxhighlight>

===<code>MetricsFilter</code>===
<code>MetricsWeigher</code> 가중치를 사용하는 경우 사용됩니다. <code>[https://docs.openstack.org/nova/2024.1/configuration/config.html#metrics.weight_setting metrics.weight_setting]</code>에 지정된 메트릭을 보고하지 않는 호스트를 필터링하여, 이러한 호스트로 인해 메트릭 가중치가 실패하지 않도록 보장합니다.

===<code>NUMATopologyFilter</code>===
인스턴스에 대해 NUMA 토폴로지가 지정된 경우, 플레이버 <code>extra_specs</code>와 이미지 속성을 사용하여 호스트를 필터링합니다. 이는 [https://docs.openstack.org/nova/2024.1/admin/cpu-topologies.html CPU 토폴로지]에 자세히 설명되어 있습니다. 필터는 인스턴스와 호스트의 NUMA 셀과 정확히 일치시키려고 시도합니다. 각 호스트 NUMA 셀에 대한 표준 오버서브스크립션 한계를 고려하여 컴퓨팅 호스트에 적절한 한계를 제공합니다.

이 필터는 NUMA 토폴로지 인스턴스나 CPU 핀닝과 같은 기능을 사용하는 인스턴스에 필수적입니다.

{{NOTE}}
인스턴스에 토폴로지가 정의되지 않은 경우, 모든 호스트가 고려됩니다. 인스턴스에 토폴로지가 정의된 경우, NUMA를 지원하는 호스트만 고려됩니다.
{{/NOTE}}

===<code>NumInstancesFilter</code>===
호스트에서 실행 중인 인스턴스 수를 기준으로 호스트를 필터링합니다. <code>[https://docs.openstack.org/nova/2024.1/configuration/config.html#filter_scheduler.max_instances_per_host filter_scheduler.max_instances_per_host]</code> 설정 옵션에서 지정한 것보다 더 많은 인스턴스를 실행 중인 호스트는 필터링됩니다.

===<code>PciPassthroughFilter</code>===
이 필터는 인스턴스를 호스트에 스케줄링할 때, 해당 호스트가 플레이버의 <code>extra_specs</code> 속성에 있는 장치 요청을 충족하는 장치를 가지고 있는 경우에만 인스턴스를 배치합니다.

이 필터는 PCI 장치 요청이 있는 인스턴스나 SR-IOV 기반 네트워킹이 호스트에서 사용되는 경우에 필수적입니다.

===<code>SameHostFilter</code>===
인스턴스 집합의 모든 다른 인스턴스와 동일한 호스트에 인스턴스를 스케줄링합니다. 이 필터를 사용하려면 요청자가 <code>same_host</code>를 키로 사용하고 인스턴스 UUID 목록을 값으로 사용하는 스케줄러 힌트를 전달해야 합니다. 이 필터는 <code>DifferentHostFilter</code>의 반대입니다.

예를 들어, '''[[openstack server create]]''' 명령어를 사용할 때 <code>--hint</code> 플래그를 사용합니다:

<syntaxhighlight lang='console'>
$ openstack server create \
  --image cedef40a-ed67-4d10-800e-17455edce175 --flavor 1 \
  --hint same_host=a0cf03a5-d921-4877-bb5c-86d26cf818e1 \
  --hint same_host=8c19174f-4220-44f0-824a-cd1eeef10287 \
  server-1
</syntaxhighlight>

API를 사용할 때는 <code>os:scheduler_hints</code> 키를 사용합니다:

<syntaxhighlight lang='json'>
{
    "server": {
        "name": "server-1",
        "imageRef": "cedef40a-ed67-4d10-800e-17455edce175",
        "flavorRef": "1"
    },
    "os:scheduler_hints": {
        "same_host": [
            "a0cf03a5-d921-4877-bb5c-86d26cf818e1",
            "8c19174f-4220-44f0-824a-cd1eeef10287"
        ]
    }
}
</syntaxhighlight>

===<code>ServerGroupAffinityFilter</code>===
서버 그룹에 속하는 인스턴스를 동일한 호스트(들)로 제한합니다. 이 필터를 활용하려면 요청자가 <code>affinity</code> 정책을 사용하는 서버 그룹을 생성하고, <code>group</code>을 키로, 서버 그룹 UUID를 값으로 하는 스케줄러 힌트를 전달해야 합니다.

예를 들어, '''[[openstack server create]]''' 명령어를 사용할 때 다음과 같이 <code>--hint</code> 플래그를 사용하세요:

<syntaxhighlight lang='console'>
$ openstack server group create --policy affinity group-1
$ openstack server create --image IMAGE_ID --flavor 1 \
    --hint group=SERVER_GROUP_UUID server-1
</syntaxhighlight>

서버 그룹에 대한 자세한 내용은 [https://docs.openstack.org/nova/2024.1/user/server-groups.html 서버 그룹]을 참조하세요.

===<code>ServerGroupAntiAffinityFilter</code>===
서버 그룹에 속하는 인스턴스를 개별 호스트로 제한합니다. 이 필터를 활용하려면 요청자가 <code>anti-affinity</code> 정책을 사용하는 서버 그룹을 생성하고, <code>group</code>을 키로, 서버 그룹 UUID를 값으로 하는 스케줄러 힌트를 전달해야 합니다.

예를 들어, '''[[openstack server create]]''' 명령어를 사용할 때 다음과 같이 <code>--hint</code> 플래그를 사용하세요:

<syntaxhighlight lang='console'>
$ openstack server group create --policy anti-affinity group-1
$ openstack server create --image IMAGE_ID --flavor 1 \
    --hint group=SERVER_GROUP_UUID server-1
</syntaxhighlight>

서버 그룹에 대한 자세한 내용은 [https://docs.openstack.org/nova/2024.1/user/server-groups.html 서버 그룹]을 참조하세요.

===<code>SimpleCIDRAffinityFilter</code>===
{{TODO}}
이 필터가 여전히 Neutron과 함께 작동하나요?
{{/TODO}}

호스트 IP 서브넷 범위에 따라 인스턴스를 스케줄링합니다. 이 필터를 사용하려면 요청자가 두 가지 스케줄러 힌트를 통해 CIDR 형식의 유효한 IP 주소 범위를 지정해야 합니다:

'''build_near_host_ip'''
:서브넷의 첫 번째 IP 주소 (예: <code>192.168.1.1</code>)

'''cidr'''
:서브넷에 해당하는 CIDR (예: <code>/24</code>)

'''[[openstack server create]]''' 명령어를 사용할 때, <code>--hint</code> 플래그를 사용하세요. 예를 들어, IP 서브넷 <code>192.168.1.1/24</code>를 지정하려면 다음과 같이 입력합니다:

<syntaxhighlight lang='console'>
$ openstack server create \
  --image cedef40a-ed67-4d10-800e-17455edce175 --flavor 1 \
  --hint build_near_host_ip=192.168.1.1 --hint cidr=/24 \
  server-1
</syntaxhighlight>

API를 사용할 때는 <code>os:scheduler_hints</code> 키를 사용합니다:

<syntaxhighlight lang='json'>
{
    "server": {
        "name": "server-1",
        "imageRef": "cedef40a-ed67-4d10-800e-17455edce175",
        "flavorRef": "1"
    },
    "os:scheduler_hints": {
        "build_near_host_ip": "192.168.1.1",
        "cidr": "24"
    }
}
</syntaxhighlight>

==가중치==

[[파일:nova-weighting-hosts.png]]

인스턴스에 자원을 할당할 때, 필터 스케줄러는 수용가능한 호스트 목록에서 각 호스트를 필터링하고 가중치를 계산합니다. 스케줄러가 호스트를 선택할 때마다 해당 호스트의 자원을 가상으로 소비하고, 이후 선택에서는 이에 따라 조정됩니다. 이는 고객이 동일한 대량의 인스턴스를 요청할 때 유용합니다. 각 요청된 인스턴스에 대해 가중치가 계산되기 때문입니다.

특정 가중치를 우선시하기 위해서는 모든 웨이어가 가중치를 계산하기 전에 적용할 배수를 정의해야 합니다. 모든 가중치는 사전에 정규화되어 배수를 쉽게 적용할 수 있습니다. 그렇게 해서 객체에 대한 최종 가중치는 다음과 같이 됩니다:

<syntaxhighlight lang='text'>
weight = w1_multiplier * norm(w1) + w2_multiplier * norm(w2) + ...
</syntaxhighlight>

호스트는 다음 설정 옵션을 기반으로 가중치가 부여됩니다:
* <code>[https://docs.openstack.org/nova/2024.1/configuration/config.html#filter_scheduler.host_subset_size filter_scheduler.host_subset_size]</code>
* <code>[https://docs.openstack.org/nova/2024.1/configuration/config.html#filter_scheduler.weight_classes filter_scheduler.weight_classes]</code>

===<code>RAMWeigher</code>===
호스트의 사용가능한 RAM을 기준으로 가중치를 계산합니다. 가장 큰 가중치가 우선하도록 정렬됩니다. <code>[https://docs.openstack.org/nova/2024.1/configuration/config.html#filter_scheduler.ram_weight_multiplier filter_scheduler.ram_weight_multiplier]</code>가 음수인 경우, 사용가능한 RAM이 가장 적은 호스트가 우선하게 됩니다(호스트를 분산시키는 대신 쌓고 싶은 경우에 유용함).

Stein 릴리스부터는, 키가 <code>ram_weight_multiplier</code>인 집합체당(per-aggregate) 값이 있으면,  값이 RAM 가중치 배수로 선택됩니다. 그렇지 않으면 <code>[https://docs.openstack.org/nova/2024.1/configuration/config.html#filter_scheduler.ram_weight_multiplier filter_scheduler.ram_weight_multiplier]</code>로 대체됩니다. 호스트의 집합체 메타데이터에 둘 이상의 값이 있으면 최소값이 사용됩니다.

===<code>CPUWeigher</code>===
컴퓨트 노드에서 사용가능한 vCPU를 기반으로 가중치를 계산합니다. 가장 큰 가중치가 우선하도록 정렬됩니다. <code>filter_scheduler.cpu_weight_multiplier</code> 가중치 배수가 음수인 경우, 사용가능한 CPU가 가장 적은 호스트가 우선하게 됩니다(호스트를 분산시키는 대신 쌓고 싶은 경우에 유용함).

Stein 릴리스부터는, <code>cpu_weight_multiplier</code> 키를 가진 집합체당(per-aggregate) 값이 있으면, 그 값이 CPU 가중치 배수로 선택됩니다. 그렇지 않으면 <code>[https://docs.openstack.org/nova/2024.1/configuration/config.html#filter_scheduler.cpu_weight_multiplier filter_scheduler.cpu_weight_multiplier]</code>로 대체됩니다. 호스트의 집합체 메타데이터에 둘 이상의 값이 있으면 최소값이 사용됩니다.

===<code>DiskWeigher</code>===
호스트의 사용가능한 디스크 공간에 따라 가중치가 부여되고, 가장 큰 가중치를 가진 호스트가 우선하도록 정렬됩니다. 배수가 음수인 경우, 사용가능한 디스크 공간이 적은 호스트가 우선하게 됩니다(호스트를 분산시키는 대신 쌓고 싶은 경우에 유용함).

Stein 릴리스부터, <code>disk_weight_multiplier</code> 키를 가진 집합체당(per-aggregate) 값이 있으면, 그 값이 디스크 가중치 배수로 선택됩니다. 그렇지 않으면 <code>[https://docs.openstack.org/nova/2024.1/configuration/config.html#filter_scheduler.disk_weight_multiplier filter_scheduler.disk_weight_multiplier]</code> 값이 사용됩니다. 호스트의 집합체 메타데이터에 둘 이상의 값이 있으면 최소값이 사용됩니다.

===<code>MetricsWeigher</code>===
이 웨이어(weigher, 가중치 계산기)는 컴퓨트 노드 호스트의 다양한 메트릭을 기반으로 가중치를 계산할 수 있습니다. 가중치를 부여할 메트릭과 그 가중치 비율은 <code>[https://docs.openstack.org/nova/2024.1/configuration/config.html#metrics.weight_setting metrics.weight_setting]</code> 설정 옵션을 사용하여 지정합니다. 예를 들면 다음과 같습니다:

<syntaxhighlight lang='ini'>
[metrics]
weight_setting = name1=1.0, name2=-1.0
</syntaxhighlight>

필요한 메트릭과 사용하지 않으며 사용할 수 없는 메트릭의 가중치는 각각 <code>[https://docs.openstack.org/nova/2024.1/configuration/config.html#metrics.required metrics.required]</code>와 <code>[https://docs.openstack.org/nova/2024.1/configuration/config.html#metrics.weight_of_unavailable metrics.weight_of_unavailable]</code> 설정 옵션을 사용하여 지정할 수 있습니다.

Stein 릴리스부터는 metrics_weight_multiplier 키가 있는 집합체당(per-aggregate) 값이 있으면, 이 값이 메트릭 가중치 배수로 선택됩니다. 그렇지 않으면 <code>[https://docs.openstack.org/nova/2024.1/configuration/config.html#metrics.weight_multiplier metrics.weight_multiplier]</code>로 대체됩니다. 호스트의 집계 메타데이터에 둘 이상의 값이 있으면 최소값이 사용됩니다.

===<code>IoOpsWeigher</code>===
===<code>PCIWeigher</code>===
===<code>ServerGroupSoftAffinityWeigher</code>===
===<code>ServerGroupSoftAntiAffinityWeigher</code>===
===<code>BuildFailureWeigher</code>===
===<code>CrossCellWeigher</code>===
''버전 21.0.0 (Ussuri)에서 새로 추가됨''

호스트가 속한 셀에 따라 호스트의 가중치를 산정합니다. 인스턴스를 이동할 때는 "로컬" 셀이 우선됩니다.

cross_cell_move_weight_multiplier라는 키를 가진 집합체당(per-aggregate) 값이 있으면, 이 값이 cross-cell 이동 가중치 배수로 선택됩니다. 그렇지 않으면 <code>[https://docs.openstack.org/nova/2024.1/configuration/config.html#filter_scheduler.cross_cell_move_weight_multiplier filter_scheduler.cross_cell_move_weight_multiplier]</code>로 대체됩니다. 호스트의 집합체 메타데이터에 둘 이상의 값이 있으면 최소값이 사용됩니다.

===<code>HypervisorVersionWeigher</code>===
''버전 28.0.0 (Bobcat)에서 새로 추가됨''

하이퍼바이저 드라이버가 보고한 하이퍼바이저 버전을 기준으로 호스트의 가중치를 설정합니다.

모든 하이퍼바이저 드라이버의 hypervisor_version 필드는 int 형식이지만, 각 nova 하이퍼바이저 드라이버는 하이퍼바이저별 버전 시퀀스를 int로 변환하는 알고리즘이 다릅니다. 따라서 다른 하이퍼바이저를 사용하는 호스트 간의 값은 직접적으로 비교할 수 없습니다.

예를 들어, ironic 하이퍼바이저 드라이버는 해당 노드에 대한 하이퍼바이저 버전으로 ironic API 마이크로 버전을 사용합니다. libvirt 드라이버는 libvirt 버전을 사용하며, 예를 들어 Libvirt 7.1.123은 700100123이 되고, Ironic 1.82는 1이 됩니다.

ironic과 non-ironic 혼합 하이퍼바이저 드라이버 배포의 경우 특별한 조치가 필요하지 않습니다. ironic 노드는 사용자 정의 리소스 클래스를 사용하여 스케줄링되므로 ironic 플레이버는 non-ironic 컴퓨트 노드와 일치하지 않습니다.

여러 non-ironic 하이퍼바이저 드라이버를 포함하는 배포의 경우, 하이퍼바이저 드라이버별로 호스트를 그룹화하기 위해 집합체를 사용하는 것이 좋습니다. 이는 반드시 필요한 것은 아니지만, 특정 하이퍼바이저 드라이버에 대한 편향을 피하기 위해 바람직합니다. 자세한 내용은 [[집합체로 격리하여 호스트 필터링]]과 [[#AggregateImagePropertiesIsolation|AggregateImagePropertiesIsolation]]을 참조하십시오.

HypervisorVersionWeigher의 기본 동작은 최신 호스트를 선택하는 것입니다. 기본 동작을 반대로 설정하려면 <code>[https://docs.openstack.org/nova/2024.1/configuration/config.html#filter_scheduler.hypervisor_version_weight_multiplier filter_scheduler.hypervisor_version_weight_multiplier]</code> 옵션을 음수로 설정하면 기본 동작과 반대의 효과가 나타납니다.

===<code>NumInstancesWeigher</code>===
''버전 28.0.0 (Bobcat)에서 새로 추가됨''

이 웨이어는 호스트를 비교하고 각 호스트의 인스턴스 수에 따라 정렬합니다. 기본적으로 이 웨이어는 아무 작업도 하지 않지만, <code>filter_scheduler.num_instances_weight_multiplier</code> 값을 수정하여 동작을 변경할 수 있습니다. 양의 값을 설정하면 인스턴스 수가 많은 호스트를 선호하는 전략(쌓기 전략)이 되며, 음의 값을 설정하면 인스턴스 수가 적은 호스트를 선호하는 전략(분배 전략)이 됩니다.

==사용률 인식 스케줄링==
{{WARNING}}
이 기능은 충분히 테스트되지 않았으며 예상대로 작동하지 않을 수 있습니다. 향후 릴리스에서 제거될 수 있습니다. 사용 시 주의하시기 바랍니다.
{{/WARNING}}

고급 스케줄링 결정을 사용하여 인스턴스를 스케줄링하는 것이 가능합니다. 이러한 결정은 메모리 캐시 이용률, 메모리 대역폭 이용률, 네트워크 대역폭 이용률과 같은 향상된 사용 통계를 기반으로 합니다. 이 기능은 기본적으로 비활성화되어 있습니다. 관리자는 설정 파일에서 <code>metrics.weight_setting</code> 설정 옵션을 사용하여 메트릭의 가중치를 설정할 수 있습니다. 예를 들어, <code>metric1</code>을 <code>ratio1</code>로, <code>metric2</code>를 <code>ratio2</code>로 설정하려면 다음과 같이 설정합니다:

<syntaxhighlight lang='ini'>
[metrics]
weight_setting = "metric1=ratio1, metric2=ratio2"
</syntaxhighlight>

==할당 비율==
할당 비율은 호스트 리소스의 오버커밋(overcommit)을 허용합니다. 이 오버커밋을 지원하기 위해 컴퓨트 노드마다 할당 비율을 제어하는 다음과 같은 설정 옵션이 있습니다:
* <code>[https://docs.openstack.org/nova/2024.1/configuration/config.html#DEFAULT.cpu_allocation_ratio cpu_allocation_ratio]</code>: 컴퓨트 노드의 VCPU 인벤토리 할당 비율을 재정의할 수 있습니다.
* <code>[https://docs.openstack.org/nova/2024.1/configuration/config.html#DEFAULT.ram_allocation_ratio ram_allocation_ratio]</code>: 컴퓨트 노드의 MEMORY_MB 인벤토리 할당 비율을 재정의할 수 있습니다.
* <code>[https://docs.openstack.org/nova/2024.1/configuration/config.html#DEFAULT.disk_allocation_ratio disk_allocation_ratio]</code>: 컴퓨트 노드의 DISK_GB 인벤토리 할당 비율을 재정의할 수 있습니다.

19.0.0 Stein 릴리스 이전에는 설정하지 않을 경우, <code>cpu_allocation_ratio</code>는 기본값으로 16.0, <code>ram_allocation_ratio</code>는 기본값으로 1.5, <code>disk_allocation_ratio</code>는 기본값으로 1.0이 사용되었습니다.

19.0.0 Stein 릴리스부터는 컴퓨트 노드의 초기 할당 비율 값을 다음과 같은 설정 옵션으로 제어합니다:
* <code>[https://docs.openstack.org/nova/2024.1/configuration/config.html#DEFAULT.initial_cpu_allocation_ratio initial_cpu_allocation_ratio]</code>: 새 컴퓨트 노드 레코드의 초기 VCPU 인벤토리 할당 비율로, 기본값은 16.0입니다.
* <code>[https://docs.openstack.org/nova/2024.1/configuration/config.html#DEFAULT.initial_ram_allocation_ratio initial_ram_allocation_ratio]</code>: 새 컴퓨트 노드 레코드의 초기 MEMORY_MB 인벤토리 할당 비율로, 기본값은 1.5입니다.
* <code>[https://docs.openstack.org/nova/2024.1/configuration/config.html#DEFAULT.initial_disk_allocation_ratio initial_disk_allocation_ratio]</code>: 새 컴퓨트 노드 레코드의 초기 DISK_GB 인벤토리 할당 비율로, 기본값은 1.0입니다.

27.0.0 Antelope 릴리스부터는 컴퓨트 노드의 초기 할당 비율 값에 대해 다음 기본값이 사용됩니다:
* <code>[https://docs.openstack.org/nova/2024.1/configuration/config.html#DEFAULT.initial_cpu_allocation_ratio initial_cpu_allocation_ratio]</code>: 새 컴퓨트 노드 레코드의 초기 VCPU 인벤토리 할당 비율로, 기본값은 4.0입니다.
* <code>[https://docs.openstack.org/nova/2024.1/configuration/config.html#DEFAULT.initial_ram_allocation_ratio initial_ram_allocation_ratio]</code>: 새 컴퓨트 노드 레코드의 초기 MEMORY_MB 인벤토리 할당 비율로, 기본값은 1.0입니다.
* <code>[https://docs.openstack.org/nova/2024.1/configuration/config.html#DEFAULT.initial_disk_allocation_ratio initial_disk_allocation_ratio]</code>: 새 컴퓨트 노드 레코드의 초기 DISK_GB 인벤토리 할당 비율로, 기본값은 1.0입니다.

===스케줄링 고려사항===
할당 비율 설정은 컴퓨팅 노드 [https://docs.openstack.org/api-ref/placement/?expanded=#resource-provider-inventories 리소스 제공자 인벤토리]를 배치 서비스에 보고할 때와 스케줄링 중에 모두 사용됩니다.

===사용 시나리오===
할당 비율은 nova 구성과 placement API를 통해 설정할 수 있기 때문에 어떤 방법을 사용해야 할지 혼란스러울 수 있습니다. 이는 사용자의 시나리오에 따라 다릅니다. 여기 몇 가지 일반적인 시나리오를 설명합니다.

* 1. 배포자가 '''항상''' 컴퓨트 노드의 자원에 대해 오버라이드 값을 설정하고 싶을 때는, 배포자는 <code>[https://docs.openstack.org/nova/2024.1/configuration/config.html#DEFAULT.cpu_allocation_ratio DEFAULT.cpu_allocation_ratio]</code>, <code>[https://docs.openstack.org/nova/2024.1/configuration/config.html#DEFAULT.ram_allocation_ratio DEFAULT.ram_allocation_ratio]</code>, <code>[https://docs.openstack.org/nova/2024.1/configuration/config.html#DEFAULT.disk_allocation_ratio DEFAULT.disk_allocation_ratio]</code> 설정 옵션을 None이 아닌 값으로 설정해야 합니다. 이렇게 하면 <code>nova-compute</code> 서비스가 placement REST API를 통해 설정된 외부 할당 비율 값을 덮어쓰게 됩니다.

* 2. 배포자가 컴퓨트 노드 할당 비율에 대해 '''초기''' 값을 설정하되, 이후에는 설정 파일을 변경하지 않고 관리자가 이를 조정할 수 있도록 하고 싶을 때는, 배포자는 <code>[https://docs.openstack.org/nova/2024.1/configuration/config.html#DEFAULT.initial_cpu_allocation_ratio DEFAULT.initial_cpu_allocation_ratio]</code>, <code>[https://docs.openstack.org/nova/2024.1/configuration/config.html#DEFAULT.initial_ram_allocation_ratio DEFAULT.initial_ram_allocation_ratio]</code>,  <code>[https://docs.openstack.org/nova/2024.1/configuration/config.html#DEFAULT.initial_disk_allocation_ratio DEFAULT.initial_disk_allocation_ratio]</code> 설정 옵션을 설정한 다음 placement REST API(또는 osc-placement 명령줄 인터페이스)를 사용하여 할당 비율을 관리해야 합니다. 예를 들어:
:<syntaxhighlight lang='console'>
$ openstack resource provider inventory set \
    --resource VCPU:allocation_ratio=1.0 \
    --amend 815a5634-86fb-4e1e-8824-8a631fee3e06
</syntaxhighlight>

* 3. 배포자가 '''항상''' placement API를 사용하여 할당 비율을 설정하고 싶을 때는, 배포자는 <code>[https://docs.openstack.org/nova/2024.1/configuration/config.html#DEFAULT.cpu_allocation_ratio DEFAULT.cpu_allocation_ratio]</code>, <code>[https://docs.openstack.org/nova/2024.1/configuration/config.html#DEFAULT.ram_allocation_ratio DEFAULT.ram_allocation_ratio]</code>, <code>[https://docs.openstack.org/nova/2024.1/configuration/config.html#DEFAULT.disk_allocation_ratio DEFAULT.disk_allocation_ratio]</code> 설정 옵션을 None으로 설정하고, placement REST API(또는 osc-placement 명령줄 인터페이스)를 사용하여 할당 비율을 관리해야 합니다.
:이 시나리오는 [https://bugs.launchpad.net/nova/+bug/1804125 버그 1804125]에 대한 워크어라운드입니다.

''버전 19.0.0 (Stein)에서 변경됨''

<code>[https://docs.openstack.org/nova/2024.1/configuration/config.html#DEFAULT.initial_cpu_allocation_ratio DEFAULT.initial_cpu_allocation_ratio]</code>, <code>[https://docs.openstack.org/nova/2024.1/configuration/config.html#DEFAULT.initial_ram_allocation_ratio DEFAULT.initial_ram_allocation_ratio]</code>,  <code>[https://docs.openstack.org/nova/2024.1/configuration/config.html#DEFAULT.initial_disk_allocation_ratio DEFAULT.initial_disk_allocation_ratio]</code> 설정 옵션은 Stein에서 도입되었습니다. 이 릴리스 이전에는 <code>[https://docs.openstack.org/nova/2024.1/configuration/config.html#DEFAULT.cpu_allocation_ratio DEFAULT.cpu_allocation_ratio]</code>, <code>[https://docs.openstack.org/nova/2024.1/configuration/config.html#DEFAULT.ram_allocation_ratio DEFAULT.ram_allocation_ratio]</code>, <code>[https://docs.openstack.org/nova/2024.1/configuration/config.html#DEFAULT.disk_allocation_ratio DEFAULT.disk_allocation_ratio]</code> 중 하나라도 null이 아닌 값으로 설정되면 사용자 설정 값이 항상 덮어쓰게 되어 있습니다.

===하이퍼바이저 관련 고려사항===
Nova는 인스턴스가 소비하지 않도록 일부 자원을 설정할 수 있는 세 가지 설정 옵션을 제공합니다. 이 옵션들은 리소스 오버커밋 여부에 상관없이 사용할 수 있습니다:
* <code>[https://docs.openstack.org/nova/2024.1/configuration/config.html#DEFAULT.reserved_host_cpus reserved_host_cpus]</code>
* <code>[https://docs.openstack.org/nova/2024.1/configuration/config.html#DEFAULT.reserved_host_memory_mb reserved_host_memory_mb]</code>
* <code>[https://docs.openstack.org/nova/2024.1/configuration/config.html#DEFAULT.reserved_host_disk_mb reserved_host_disk_mb]</code>
일부 virt 드라이버는 이러한 옵션을 사용하여 하이퍼바이저 관련 오버헤드를 고려하는 데 도움이 될 수 있습니다.

==셀 고려사항==
기본적으로 셀은 새 인스턴스를 스케줄링할 수 있도록 활성화되어 있지만, 비활성화할 수 있습니다(새로운 스케줄이 해당 셀에 할당되지 않음). 이는 셀 유지보수, 장애 또는 기타 개입 시 유용할 수 있습니다. 사전 비활성화된 셀을 생성하거나 기존 셀을 활성화/비활성화하려면 변경사항이 적용되도록 nova-scheduler 서비스를 재시작하거나 SIGHUP 신호를 보내야 한다는 점을 유의해야 합니다.

===명령줄 인터페이스===
'''nova-manage''' 명령줄 클라이언트는 셀 비활성화 관련 명령어를 지원합니다. 셀을 활성화하거나 비활성화하려면 '''nova-manage cell_v2 update_cell'''을 사용하고, 사전 비활성화된 셀을 생성하려면 '''nova-manage cell_v2 create_cell'''을 사용하세요. 명령어 사용에 대한 자세한 내용은 [https://docs.openstack.org/nova/2024.1/cli/nova-manage.html#man-page-cells-v2 Cells v2 명령어] 매뉴얼 페이지를 참조하십시오.

==특성으로서의 컴퓨트 능력==
''버전 19.0.0 (Stein)에 새로 추가됨''

<code>nova-compute</code> 서비스는 자체 컴퓨팅 드라이버 기능을 기반으로 특정 <code>COMPUTE_*</code> 특성을 placement 서비스에 보고합니다. 이러한 특성은 해당 컴퓨팅 서비스의 리소스 제공자와 연관됩니다. 이러한 특성은 [https://docs.openstack.org/nova/2024.1/user/flavors.html#extra-specs-required-traits 필수 특성(Required traits)] 또는 [https://docs.openstack.org/nova/2024.1/user/flavors.html#extra-specs-forbidden-traits 금지된 특성(Forbidden traits)]으로 flavor를 구성하여 스케줄링 중에 사용할 수 있습니다. 예를 들어, multi-attach 볼륨을 지원하는 일련의 컴퓨트 노드가 있는 호스트 집합체가 있는 경우, flavor에 <code>trait:COMPUTE_VOLUME_MULTI_ATTACH=required</code>엑스트라 스펙을 추가하고, [https://docs.openstack.org/nova/2024.1/admin/aggregates.html#config-sch-for-aggs 일반적인 방식]으로 flavor를 집합체에 제한할 수 있습니다.

다음은 특정 CPU 기능을 특성으로, 드라이버 기능을 특성으로, 그리고 <code>CUSTOM_</code> 접두어가 붙은 커스텀 특성을 노출하는 libvirt 컴퓨트 노드 리소스 제공자 예제입니다:

<syntaxhighlight lang='console'>
$ openstack --os-placement-api-version 1.6 resource provider trait list \
> d9b3dbc4-50e2-42dd-be98-522f6edaab3f --sort-column name
+---------------------------------------+
| name                                  |
+---------------------------------------+
| COMPUTE_DEVICE_TAGGING                |
| COMPUTE_NET_ATTACH_INTERFACE          |
| COMPUTE_NET_ATTACH_INTERFACE_WITH_TAG |
| COMPUTE_TRUSTED_CERTS                 |
| COMPUTE_VOLUME_ATTACH_WITH_TAG        |
| COMPUTE_VOLUME_EXTEND                 |
| COMPUTE_VOLUME_MULTI_ATTACH           |
| CUSTOM_IMAGE_TYPE_RBD                 |
| HW_CPU_X86_MMX                        |
| HW_CPU_X86_SSE                        |
| HW_CPU_X86_SSE2                       |
| HW_CPU_X86_SVM                        |
+---------------------------------------+
</syntaxhighlight>

;규칙
능력 정의 특성과 관련된 몇 가지 규칙이 있습니다.

* 1. 컴퓨트 서비스는 이러한 특성을 “소유”하며, <code>nova-compute</code> 서비스가 시작할 때 및 <code>update_available_resource</code> 주기적 작업이 실행될 때 추가/제거됩니다. 실행 간격은 설정 옵션 <code>[https://docs.openstack.org/nova/2024.1/configuration/config.html#DEFAULT.update_resources_interval update_resources_interval]</code>에 의해 제어됩니다.
* 2. 컴퓨트 서비스는 외부에서 리소스 제공자에 설정된 커스텀 특성(예: 위의 예제에서 <code>CUSTOM_IMAGE_TYPE_RBD</code> 특성)을 제거하지 않습니다.
* 3. 컴퓨트 소유 특성이 외부에서 리소스 제공자에서 제거된 경우(예: <code>openstack resource provider trait delete <rp_uuid></code> 명령어 실행으로 인해), 컴퓨트 서비스는 재시작 또는 SIGHUP 시 다시 특성을 추가합니다.
* 4. 드라이버가 지원하지 않는 특성(예: 드라이버가 해당 기능을 지원하지 않는 경우 <code>COMPUTE_VOLUME_EXTEND</code> 특성)이 외부에서 리소스 제공자에 설정된 경우, 컴퓨트 서비스는 재시작 또는 SIGHUP 시 자동으로 지원되지 않는 특성을 제거합니다.
* 5. 컴퓨팅 능력 특성은 [https://opendev.org/openstack/os-traits/src/branch/master/os_traits/compute os-traits] 라이브러리에서 정의된 표준 특성입니다.

능력 및 특성에 대한 자세한 내용은 [https://docs.openstack.org/nova/2024.1/reference/index.html 기술 레퍼런스 딥 다이브 섹션]에서 확인할 수 있습니다.

==필터 직접 작성하기==
필터를 직접 작성하려면 <code>BaseHostFilter</code>를 상속하고 하나의 메소드, <code>host_passes</code>를 구현해야 합니다. 이 메소드는 호스트가 필터를 통과하면 <code>True</code>를, 그렇지 않으면 <code>False</code>를 반환해야 합니다. 메소드는 두 개의 파라미터를 받습니다:

* <code>HostState</code> 객체: 호스트의 속성을 얻을 수 있습니다.
* <code>RequestSpec</code> 객체: 사용자 요청을 설명하며, flavor, 이미지 및 스케줄러 힌트를 포함합니다.

이 객체와 해당 속성에 대한 자세한 내용은 코드베이스(다른 필터 코드를 살펴보는 정도로도 충분합니다)를 참조하거나 <code>#openstack-nova</code> IRC 채널에서 도움을 요청하세요.

추가로, 직접 작성한 커스텀 필터가 비표준 extra specs을 사용하는 경우, 이러한 extra specs에 대한 검증기를 등록해야 합니다. 검증기의 예는 <code>nova.api.validation.extra_specs</code> 모듈에서 찾을 수 있습니다. 이들은 <code>nova.api.extra_spec_validator</code> 엔트리포인트를 통해 등록해야 합니다.

커스텀 필터가 포함된 모듈은 nova 컨트롤러, 특히 <code>nova-scheduler</code> 및 <code>nova-api</code> 서비스가 사용가능한 환경에서 패키징되고 제공되어야 합니다. 다음은 표준 setuptools 기반 Python 패키지의 최소 구조를 보여주는 샘플 패키지입니다:

<syntaxhighlight lang='console'>
acmefilter/
    acmefilter/
        __init__.py
        validators.py
    setup.py
</syntaxhighlight>

<code>init.py</code>에는 다음 내용이 포함됩니다:

<syntaxhighlight lang='python'>
from oslo_log import log as logging
from nova.scheduler import filters

LOG = logging.getLogger(__name__)

class AcmeFilter(filters.BaseHostFilter):

    def host_passes(self, host_state, spec_obj):
        extra_spec = spec_obj.flavor.extra_specs.get('acme:foo')
        LOG.info("Extra spec value was '%s'", extra_spec)

        # 여기서 의미 있는 작업을 수행합니다...

        return True
</syntaxhighlight>

<code>validators.py</code>에는 다음 내용이 포함됩니다:

<syntaxhighlight lang='python'>
from nova.api.validation.extra_specs import base

def register():
    validators = [
        base.ExtraSpecValidator(
            name='acme:foo',
            description='나만의 사용자 지정 extra spec입니다.'
            value={
                'type': str,
                'enum': [
                    'bar',
                    'baz',
                ],
            },
        ),
    ]

    return validators
</syntaxhighlight>

<code>setup.py</code>에는 다음 내용이 포함됩니다:

<syntaxhighlight lang='python'>
from setuptools import setup

setup(
    name='acmefilter',
    version='0.1',
    description='나만의 사용자 지정 필터',
    packages=[
        'acmefilter'
    ],
    entry_points={
        'nova.api.extra_spec_validators': [
            'acme = acmefilter.validators',
        ],
    },
)
</syntaxhighlight>

이를 활성화하려면 <code>nova.conf</code>에서 다음을 설정합니다:

<syntaxhighlight lang='ini'>
[filter_scheduler]
available_filters = nova.scheduler.filters.all_filters
available_filters = acmefilter.AcmeFilter
enabled_filters = ComputeFilter,AcmeFilter
</syntaxhighlight>

{{NOTE}}
커스텀 필터를 추가하려면 <code>[https://docs.openstack.org/nova/2024.1/configuration/config.html#filter_scheduler.available_filters filter_scheduler.available_filters]</code> 설정 옵션을 사용하여 사용가능한 필터 목록에 추가해야 하며, </code>[https://docs.openstack.org/nova/2024.1/configuration/config.html#filter_scheduler.enabled_filters filter_scheduler.enabled_filters]</code> 설정 옵션을 통해 활성화해야 합니다. 전자는 기본적으로 nova와 함께 제공되는 필터만 포함하는 <code>nova.scheduler.filters.all_filters</code> 값을 가지고 있습니다.
{{/NOTE}}

이 설정을 통해 모든 표준 nova 필터와 커스텀 <code>AcmeFilter</code> 필터가 스케줄러에서 사용가능하지만, 각 요청에서는 <code>ComputeFilter</code>와 <code>AcmeFilter</code>만 사용됩니다.

==웨이어 직접 작성하기==
웨이어를 직접 작성하려면 <code>BaseHostFilter</code>를 상속해야 합니다. 웨이어는 <code>weight_multiplier</code>와 <code>_weight_object</code> 메소드를 모두 구현하거나 <code>weight_objects</code> 메소드만 구현할 수 있습니다. <code>weight_objects</code> 메소드는 모든 객체에 접근해야 하는 경우에만 재정의하며, 단순히 가중치 목록을 반환할 뿐 객체의 가중치를 직접 수정하지 않습니다. 최종 가중치는 <code>weight.BaseWeightHandler</code>에 의해 정규화되어 계산됩니다.