Nova 컴퓨트 스케줄러

1 개요

Compute schedulers

컴퓨트 스케줄러

• https://docs.openstack.org/nova/2024.1/admin/scheduling.html

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

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

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

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

호스트에서 인스턴스를 대피시킬 때, 스케줄러 서비스는 관리자에 의해 nova evacuate 명령어에서 정의된 대상 호스트를 존중합니다. 관리자가 대상을 정의하지 않은 경우, 스케줄러가 대상 호스트를 결정합니다. 인스턴스 대피에 대한 정보는 인스턴스 대피를 참조하십시오.

2 프리필터

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

2.1 컴퓨트 이미지 타입 지원

버전 20.0.0 (Train)에 새로 추가됨

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

2.2 컴퓨트 비활성화 상태 지원

버전 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 주기적 작업이 실행될 때 특성이 동기화됩니다.

2.3 격리된 집합체

버전 20.0.0(Train)에서 새로 추가됨

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

3 필터 스케줄러

버전 23.0.0 (Wallaby)에서 변경됨

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

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

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

필터링

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

[filter_scheduler]
available_filters = nova.scheduler.filters.all_filters
available_filters = myfilter.MyFilter

nova.conf의 filter_scheduler.enabled_filters 설정 옵션은 nova-scheduler 서비스에서 적용하는 필터 목록을 정의합니다.

4 필터

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

필터는 다음 설정 옵션을 사용하여 설정됩니다:

• filter_scheduler.available_filters - 스케줄러에서 사용가능한 필터 클래스를 정의합니다. 이 설정은 여러 번 사용할 수 있습니다.
• filter_scheduler.enabled_filters - 사용가능한 필터 중 스케줄러가 기본적으로 사용하는 필터를 정의합니다.

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

4.1 AggregateImagePropertiesIsolation

변경사항: 버전 12.0.0 (Liberty)

버전 12.0.0 Liberty 이전에는 이 필터에서 임의의 메타데이터를 지정하고 사용할 수 있었습니다. Liberty부터 nova는 표준 메타데이터만을 파싱합니다. 임의의 메타데이터를 사용하려면 AggregateInstanceExtraSpecsFilter 필터를 사용하는 것이 좋습니다.

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

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

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

$ 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                       |
+-------------------+----------------------------+

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

$ 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'                                  |
| ...

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

• filter_scheduler.aggregate_image_properties_isolation_namespace
• filter_scheduler.aggregate_image_properties_isolation_separator

Note

이 필터는 버그 1677217에 설명된대로 제한사항이 있으며, 이는 배치 필터링 호스트의 격리된 집합체 요청 필터로 해결됩니다.

자세한 내용은 호스트 집합체를 참조하십시오.

4.2 AggregateInstanceExtraSpecsFilter

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

자세한 내용은 호스트 집합체를 참조하십시오.

4.3 AggregateIoOpsFilter

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

자세한 내용은 '호스트 집합체 및 IoOpsFilter'를 참조하세요.

4.4 AggregateMultiTenancyIsolation

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

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

Note

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

4.5 AggregateNumInstancesFilter

호스트 집합체 내에서 인스턴스 수에 따라 호스트를 필터링하며, 집합체별 max_instances_per_host 값을 사용합니다. 만약 집합체별 값이 지정되지 않은 경우, filter_scheduler.max_instances_per_host 설정 옵션에 정의된 전역 설정 값으로 대체됩니다. 호스트가 둘 이상의 집합체에 속해 있고 따라서 둘 이상의 값이 발견되는 경우, 최솟값이 사용됩니다.

자세한 내용은 호스트 집합체와 NumInstancesFilter를 참조하십시오.

4.6 AggregateTypeAffinityFilter

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

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

Note

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

자세한 내용은 호스트 집합체를 참조하십시오.

4.7 AllHostsFilter

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

4.8 ComputeCapabilitiesFilter

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

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

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

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

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

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

일부 virt 드라이버는 CPU 특성을 Placement 서비스에 보고하는 기능을 지원합니다. 이 기능이 사용가능한 경우, ComputeCapabilitiesFilter 대신 flavor에서 특성을 사용하는 것을 고려해야 합니다. 특성은 일부 virt 드라이버에서 CPU 기능에 대해 일관된 네이밍을 제공하며, 특성 쿼리는 효율적입니다. 자세한 내용은 기능 지원 매트릭스, 필수 특성, 금지된 특성, CPU 기능을 Placement 서비스에 보고하기를 참조하십시오.

또한 특성으로서의 컴퓨트 능력(Compute capabilities as traits)도 참조하십시오.

5 ComputeFilter

운영 중이고 활성화된 모든 호스트를 통과시킵니다.

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

6 DifferentHostFilter

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

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

$ 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

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

{
    "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"
        ]
    }
}

6.1 ImagePropertiesFilter

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

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

$ openstack image set --architecture arm --property img_hv_type=qemu img-uuid

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

hw_architecture

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

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

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

img_hv_type

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

Note

qemu는 QEMU와 KVM 하이퍼바이저 유형 모두에 사용됩니다.

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

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

img_hv_requested_version

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

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

$ openstack image set --property hypervisor_type=qemu --property hypervisor_version_requires=">=6000" img-uuid

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

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

hw_vm_mode

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

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

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

6.2 IsolatedHostsFilter

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

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

관리자는 filter_scheduler.isolated_hosts와 filter_scheduler.isolated_images 설정 옵션을 사용하여 격리된 이미지 및 호스트 집합을 지정해야 합니다. 예를 들어:

[filter_scheduler]
isolated_hosts = server1, server2
isolated_images = 342b492c-128f-4a42-8d3a-c5088cf27d13, ebd267a6-ca86-4d6c-9a0e-bd132d6b7d09

격리된 호스트가 특정 격리된 이미지에서만 사용되도록 하려면 filter_scheduler.restrict_isolated_hosts_to_isolated_images 설정 옵션을 지정할 수도 있습니다.

6.3 IoOpsFilter

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

6.4 JsonFilter

Warning

이 필터는 기본적으로 활성화되지 않으며 종합적으로 테스트되지 않았으므로 명확하지 않은 방식으로 예상과 다르게 작동할 수 있습니다. 또한, 이 필터 변수는 릴리스마다 변경될 수 있는 HostState 클래스의 속성을 기반으로 하기 때문에 사용이 일반적으로 권장되지 않습니다. ImagePropertiesFilter 또는 특성 기반 스케줄링과 같은 다른 필터를 사용하는 것을 고려하십시오.

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

• =
• <
• in
• <=
• =
• not
• or
• and

대부분의 다른 필터와 달리 스케줄러 힌트를 통해 제공된 정보에 의존하지 않고 다음과 같은 HostState 클래스의 속성에 필터링합니다:

• $free_ram_mb
• $free_disk_mb
• $hypervisor_hostname
• $total_usable_ram_mb
• $vcpus_total
• $vcpus_used

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

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

API를 사용할 때는 os:scheduler_hints 키를 사용하십시오:

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

6.5 MetricsFilter

MetricsWeigher 가중치를 사용하는 경우 사용됩니다. metrics.weight_setting에 지정된 메트릭을 보고하지 않는 호스트를 필터링하여, 이러한 호스트로 인해 메트릭 가중치가 실패하지 않도록 보장합니다.

6.6 NUMATopologyFilter

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

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

Note

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

6.7 NumInstancesFilter

호스트에서 실행 중인 인스턴스 수를 기준으로 호스트를 필터링합니다. filter_scheduler.max_instances_per_host 설정 옵션에서 지정한 것보다 더 많은 인스턴스를 실행 중인 호스트는 필터링됩니다.

6.8 PciPassthroughFilter

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

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

6.9 SameHostFilter

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

예를 들어, openstack server create 명령어를 사용할 때 --hint 플래그를 사용합니다:

$ 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

API를 사용할 때는 os:scheduler_hints 키를 사용합니다:

{
    "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"
        ]
    }
}

6.10 ServerGroupAffinityFilter

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

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

$ openstack server group create --policy affinity group-1
$ openstack server create --image IMAGE_ID --flavor 1 \
    --hint group=SERVER_GROUP_UUID server-1

서버 그룹에 대한 자세한 내용은 서버 그룹을 참조하세요.

6.11 ServerGroupAntiAffinityFilter

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

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

$ openstack server group create --policy anti-affinity group-1
$ openstack server create --image IMAGE_ID --flavor 1 \
    --hint group=SERVER_GROUP_UUID server-1

서버 그룹에 대한 자세한 내용은 서버 그룹을 참조하세요.

6.12 SimpleCIDRAffinityFilter

Todo

이 필터가 여전히 Neutron과 함께 작동하나요?

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

build_near_host_ip

서브넷의 첫 번째 IP 주소 (예: 192.168.1.1)

cidr

서브넷에 해당하는 CIDR (예: /24)

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

$ 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

API를 사용할 때는 os:scheduler_hints 키를 사용합니다:

{
    "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"
    }
}

7 가중치

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

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

weight = w1_multiplier * norm(w1) + w2_multiplier * norm(w2) + ...

호스트는 다음 설정 옵션을 기반으로 가중치가 부여됩니다:

• filter_scheduler.host_subset_size
• filter_scheduler.weight_classes

7.1 RAMWeigher

호스트의 사용가능한 RAM을 기준으로 가중치를 계산합니다. 가장 큰 가중치가 우선하도록 정렬됩니다. filter_scheduler.ram_weight_multiplier가 음수인 경우, 사용가능한 RAM이 가장 적은 호스트가 우선하게 됩니다(호스트를 분산시키는 대신 쌓고 싶은 경우에 유용함).

스테인(Stein) 릴리스부터는, 키가 ram_weight_multiplier인 집합체당(per-aggregate) 값이 있으면, 값이 RAM 가중치 배수로 선택됩니다. 그렇지 않으면 filter_scheduler.ram_weight_multiplier로 대체됩니다. 호스트의 집합체 메타데이터에서 둘 이상의 값이 있으면 최소값이 사용됩니다.

7.2 CPUWeigher

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

스테인(Stein) 릴리스부터는, cpu_weight_multiplier 키를 가진 집합체당(per-aggregate) 값이 있으면, 그 값이 CPU 가중치 배수로 선택됩니다. 그렇지 않으면 filter_scheduler.cpu_weight_multiplier로 대체됩니다. 호스트의 집합체 메타데이터에서 둘 이상의 값이 있으면 최소값이 사용됩니다.

7.3 DiskWeigher

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

스테인(Stein) 릴리스부터, disk_weight_multiplier 키를 가진 집합체당(per-aggregate) 값이 있으면, 그 값이 디스크 가중치 배수로 선택됩니다. 그렇지 않으면 filter_scheduler.disk_weight_multiplier 값이 사용됩니다. 호스트의 집합체 메타데이터에서 둘 이상의 값이 있으면, 최소값이 사용됩니다.

7.4 MetricsWeigher

이 웨이어(weigher, 가중치 계산기)는 컴퓨트 노드 호스트의 다양한 메트릭을 기반으로 가중치를 계산할 수 있습니다. 가중치를 부여할 메트릭과 그 가중치 비율은 metrics.weight_setting 설정 옵션을 사용하여 지정합니다. 예를 들면 다음과 같습니다:

[metrics]
weight_setting = name1=1.0, name2=-1.0

필요한 메트릭과 사용하지 않으며 사용할 수 없는 메트릭의 가중치는 각각 metrics.required와 metrics.weight_of_unavailable 설정 옵션을 사용하여 지정할 수 있습니다.

Stein 릴리스부터는 metrics_weight_multiplier 키가 있는 집합체당(per-aggregate) 값이 있으면, 이 값이 메트릭 가중치 배수로 선택됩니다. 그렇지 않으면 metrics.weight_multiplier로 대체됩니다. 호스트의 집계 메타데이터에 둘 이상의 값이 있으면 최소값이 사용됩니다.

7.12 NumInstancesWeigher

버전 28.0.0 (Bobcat)에서 새로 추가됨

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

8 사용률 인식 스케줄링

Warning

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

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

[metrics]
weight_setting = "metric1=ratio1, metric2=ratio2"

9 할당 비율

할당 비율은 호스트 리소스의 오버커밋(overcommit)을 허용합니다. 이 오버커밋을 지원하기 위해 컴퓨트 노드마다 할당 비율을 제어하는 다음과 같은 설정 옵션이 있습니다:

• cpu_allocation_ratio: 컴퓨트 노드의 VCPU 인벤토리 할당 비율을 재정의할 수 있습니다.
• ram_allocation_ratio: 컴퓨트 노드의 MEMORY_MB 인벤토리 할당 비율을 재정의할 수 있습니다.
• disk_allocation_ratio: 컴퓨트 노드의 DISK_GB 인벤토리 할당 비율을 재정의할 수 있습니다.

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

19.0.0 Stein 릴리스부터는 컴퓨트 노드의 초기 할당 비율 값을 다음과 같은 설정 옵션으로 제어합니다:

• initial_cpu_allocation_ratio: 새 컴퓨트 노드 레코드의 초기 VCPU 인벤토리 할당 비율로, 기본값은 16.0입니다.
• initial_ram_allocation_ratio: 새 컴퓨트 노드 레코드의 초기 MEMORY_MB 인벤토리 할당 비율로, 기본값은 1.5입니다.
• initial_disk_allocation_ratio: 새 컴퓨트 노드 레코드의 초기 DISK_GB 인벤토리 할당 비율로, 기본값은 1.0입니다.

27.0.0 Antelope 릴리스부터는 컴퓨트 노드의 초기 할당 비율 값에 대해 다음 기본값이 사용됩니다:

• initial_cpu_allocation_ratio: 새 컴퓨트 노드 레코드의 초기 VCPU 인벤토리 할당 비율로, 기본값은 4.0입니다.
• initial_ram_allocation_ratio: 새 컴퓨트 노드 레코드의 초기 MEMORY_MB 인벤토리 할당 비율로, 기본값은 1.0입니다.
• initial_disk_allocation_ratio: 새 컴퓨트 노드 레코드의 초기 DISK_GB 인벤토리 할당 비율로, 기본값은 1.0입니다.

9.1 스케줄링 고려사항

할당 비율 설정은 컴퓨팅 노드 리소스 제공자 인벤토리를 배치 서비스에 보고할 때와 스케줄링 중에 모두 사용됩니다.

9.2 사용 시나리오

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

• 1. 배포자가 항상 컴퓨트 노드의 자원에 대해 오버라이드 값을 설정하고 싶을 때는, 배포자는 DEFAULT.cpu_allocation_ratio, DEFAULT.ram_allocation_ratio, DEFAULT.disk_allocation_ratio 설정 옵션을 None이 아닌 값으로 설정해야 합니다. 이렇게 하면 nova-compute 서비스가 placement REST API를 통해 설정된 외부 할당 비율 값을 덮어쓰게 됩니다.

• 2. 배포자가 컴퓨트 노드 할당 비율에 대해 초기 값을 설정하되, 이후에는 설정 파일을 변경하지 않고 관리자가 이를 조정할 수 있도록 하고 싶을 때는, 배포자는 DEFAULT.initial_cpu_allocation_ratio, DEFAULT.initial_ram_allocation_ratio, DEFAULT.initial_disk_allocation_ratio 설정 옵션을 설정한 다음 placement REST API(또는 osc-placement 명령줄 인터페이스)를 사용하여 할당 비율을 관리해야 합니다. 예를 들어:

$ openstack resource provider inventory set \
    --resource VCPU:allocation_ratio=1.0 \
    --amend 815a5634-86fb-4e1e-8824-8a631fee3e06

• 3. 배포자가 항상 placement API를 사용하여 할당 비율을 설정하고 싶을 때는, 배포자는 DEFAULT.cpu_allocation_ratio, DEFAULT.ram_allocation_ratio, DEFAULT.disk_allocation_ratio 설정 옵션을 None으로 설정하고, placement REST API(또는 osc-placement 명령줄 인터페이스)를 사용하여 할당 비율을 관리해야 합니다.

이 시나리오는 버그 1804125에 대한 워크어라운드입니다.

버전 19.0.0(Stein)에서 변경됨

DEFAULT.initial_cpu_allocation_ratio, DEFAULT.initial_ram_allocation_ratio, DEFAULT.initial_disk_allocation_ratio 설정 옵션은 스테인(Stein)에서 도입되었습니다. 이 릴리스 이전에는 DEFAULT.cpu_allocation_ratio, DEFAULT.ram_allocation_ratio, DEFAULT.disk_allocation_ratio 중 하나라도 null이 아닌 값으로 설정되면 사용자 설정 값이 항상 덮어쓰게 되어 있습니다.

9.3 하이퍼바이저 관련 고려사항

Nova는 인스턴스가 소비하지 않도록 일부 자원을 설정할 수 있는 세 가지 설정 옵션을 제공합니다. 이 옵션들은 리소스 오버커밋 여부에 상관없이 사용할 수 있습니다:

• reserved_host_cpus
• reserved_host_memory_mb
• reserved_host_disk_mb

일부 virt 드라이버는 이러한 옵션을 사용하여 하이퍼바이저 관련 오버헤드를 고려하는 데 도움이 될 수 있습니다.

10 셀 고려사항

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

10.1 명령줄 인터페이스

nova-manage 명령줄 클라이언트는 셀 비활성화 관련 명령어를 지원합니다. 셀을 활성화하거나 비활성화하려면 nova-manage cell_v2 update_cell을 사용하고, 사전 비활성화된 셀을 생성하려면 nova-manage cell_v2 create_cell을 사용하세요. 명령어 사용에 대한 자세한 내용은 Cells v2 명령어 매뉴얼 페이지를 참조하십시오.

11 특성으로서의 컴퓨트 능력

버전 19.0.0 (Stein)에 새로 추가됨

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

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

$ 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                        |
+---------------------------------------+

규칙

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

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

능력 및 특성에 대한 자세한 내용은 기술 레퍼런스 딥 다이브 섹션에서 확인할 수 있습니다.

12 필터 직접 작성하기

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

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

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

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

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

acmefilter/
    acmefilter/
        __init__.py
        validators.py
    setup.py

init.py에는 다음 내용이 포함됩니다:

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

validators.py에는 다음 내용이 포함됩니다:

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

setup.py에는 다음 내용이 포함됩니다:

from setuptools import setup

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

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

[filter_scheduler]
available_filters = nova.scheduler.filters.all_filters
available_filters = acmefilter.AcmeFilter
enabled_filters = ComputeFilter,AcmeFilter

Note

커스텀 필터를 추가하려면 filter_scheduler.available_filters 설정 옵션을 사용하여 사용가능한 필터 목록에 추가해야 하며, filter_scheduler.enabled_filters 설정 옵션을 통해 활성화해야 합니다. 전자는 기본적으로 nova와 함께 제공되는 필터만 포함하는 nova.scheduler.filters.all_filters 값을 가지고 있습니다.

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

13 웨이어 직접 작성하기

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