스케줄러 힌트 vs 플레이버 부가 스펙

1 개요

Scheduler hints versus flavor extra specs

스케줄러 힌트 vs 플레이버 부가 스펙

https://docs.openstack.org/nova/2024.1/reference/scheduler-hints-vs-flavor-extra-specs.html

---

Nova를 배포하고 작업하는 사람들은 종종 플레이버 부가 스펙과 스케줄러 힌트가 스케줄링 결정에 어떤 역할을 하는지, 그리고 클라우드의 최종 사용자에게 기능을 노출하기 위해 어떤 것이 더 나은 선택인지에 대한 의문을 갖습니다. 여러 가지를 고려해야 하며 복잡해질 수 있습니다. 이 문서는 플레이버 부가 스펙과 스케줄러 힌트의 주요 차이점과 단점에 대해 높은 수준에서 설명하려고 합니다.

2 부가 스펙

일반적으로 플레이버의 부가 스펙은 클라우드의 구성 및 기능과 관련되어 있으며, 최종 사용자로부터 추상화되어야 합니다. 부가 스펙은 호스트 집합체와 연관되어 있으며, VM의 감시기 동작(watchdog action)과 같은 하이퍼바이저에서 게스트가 생성되는 방식도 정의합니다. 부가 스펙은 VM 동작에 관해서는 이미지 속성과 상호교환가능한 경우가 많습니다. 사용자에게는 플레이버의 이름이나 특정 배포에 대한 문서, 예를 들어 베어메탈 인스턴스를 설정하는 방법을 설명하는 지침을 통해 이러한 내용이 전달됩니다.

3 스케줄러 힌트

스케줄러 힌트는 단순히 “힌트”라고도 하며, 서버 생성 시 스케줄러에 의해 서버의 배치를 조정하기 위해 지정할 수 있습니다. 이는 활성화된 스케줄러 필터에 따라 달라집니다. 예를 들어, ServerGroupAntiAffinityFilter 스케줄러 필터는 group 스케줄러 힌트와 함께 사용되어, 생성 중인 서버가 지정된 반-친화성 그룹의 구성원이어야 하며, 해당 필터는 그 서버를 그룹의 다른 모든 현재 구성원과 다른 컴퓨트 호스트에 배치해야 함을 나타냅니다.

힌트는 플레이버 부가 스펙보다 더 “동적”이지 않습니다. 최종 사용자는 서버를 생성할 때 플레이버를 지정하고 선택적으로 힌트를 지정할 수 있지만, 궁극적으로 지정할 수 있는 것은 배포에 의해 정해진 고정적인 것입니다.

4 유사점

• 스케줄러 힌트와 플레이버 부가 스펙은 모두 스케줄러 필터에서 사용할 수 있습니다.
• 둘 다 완전히 커스터마이징가능하며, Nova에는 이미지 속성과 달리 허용가능한 힌트나 부가 스펙에 대한 화이트리스트가 없습니다.
• 최종 사용자는 배포자의 동의 없이 새로운 동작을 실현할 수 없습니다. 예를 들어, 최종 사용자가 group 힌트를 지정하더라도, 배포자가 ServerGroupAntiAffinityFilter를 구성하지 않았다면 최종 사용자는 안티 어피니티(anti-affinity) 동작을 사용할 수 없습니다.

5 차이점

• 서버의 호스트 위치 및/또는 동작은 다른 부가 스펙을 가진 플레이버로 크기를 조정할 때 변경될 수 있습니다. 스케줄러 힌트는 서버 생성 시에만 지정할 수 있으며, 크기조정이나 다른 "이동" 작업 중에는 지정할 수 없습니다. 그러나 원래의 힌트는 이동 작업 중에도 여전히 적용됩니다.
• 서버를 생성하거나 크기조정할 때 사용된 플레이버의 부가 스펙은 2.47 마이크로버전의 컴퓨트 API를 통해 조회할 수 있습니다. 19.0.0 Stein 릴리스 기준으로, 컴퓨트 API를 통해 서버 생성 시 사용된 스케줄러 힌트를 조회할 수 있는 방법은 현재 없습니다.

Note

서버 생성 시 사용된 힌트를 노출하는 기능이 제안되었습니다. 이 기능이 없을 경우, 서버 메타데이터에 스케줄러 힌트를 포함시켜 나중에 메타데이터를 통해 조회하는 등의 방법으로 이 제한을 우회할 수 있습니다.

• 힌트의 경우 최종 사용자가 힌트를 포함하지 않기로 결정할 수 있습니다. 반면, 최종 사용자는 새로운 플레이버를 생성할 수 없으므로(기본 정책에 따라) 부가 스펙이 포함된 플레이버를 전달하지 않도록 할 수 없습니다. 플레이버는 배포자가 제어합니다.

6 발견가능성

발견가능성 측면에서, 기본적으로 os_compute_api:os-flavor-extra-specs:index 정책 규칙에 따라, 플레이버의 부가 스펙은 사용자가 목록을 확인할 수 있기 때문에 최종 사용자에게 더 "발견가능"합니다. 그러나 평균적인 사용자가 다양한 부가 스펙의 의미를 이해할 것이라고 기대하기는 어렵습니다. 이들은 단지 키/값 쌍일 뿐입니다. 일부 "표준" 부가 스펙에 대한 문서가 존재하기는 하지만, 이는 포괄적인 목록이 아니며, 예를 들어 베어메탈 인스턴스를 위해 플레이버를 생성할 때 플레이버를 호스트 집합체 집합에 연결하는 것과 같은 다양한 배포에서 정의하는 사항이나 선택한 하이퍼바이저 드라이버가 지원하는 플레이버 부가 스펙을 포함하지 않습니다.

스케줄러 힌트는 부가 스펙보다 최종 사용자 관점에서 발견하기가 더 어렵습니다. API 요청 스키마에 정의된 몇 가지 표준 힌트가 있기는 합니다. 그러나:

• 1. 이러한 힌트는 스케줄러 필터와 연결되어 있으며, 스케줄러 필터는 배포마다 설정할 수 있습니다. 예를 들어 JsonFilter는 기본적으로 활성화되어 있지 않기 때문에 query 힌트가 아무런 작동을 하지 않을 수 있습니다.
• 2. 스케줄러 힌트는 스키마의 additionalProperties: True 항목 때문에 업스트림 노바 코드의 API 요청 스키마에 있는 것에만 국한되지 않습니다. 이는 배포가 업스트림 노바 코드에 포함되지 않은 자체 커스텀 스케줄러 필터에 대한 힌트를 정의할 수 있도록 합니다.

7 상호운용성

최종 사용자가 스케줄러 힌트를 실제로 사용할 수 있는 유일한 방법은 특정 클라우드 배포가 해당 설정에 대해 제공하는 문서(또는 GUI/SDK)에 기반하는 것입니다. 예를 들어, CloudA가 커스텀 스케줄러 필터 X와 해당 필터에 대한 힌트를 문서화하면, 최종 사용자 애플리케이션은 해당 클라우드에서 그 힌트를 사용하여 문서에 설명된 대로 작동할 수 있습니다. 그러나 사용자가 애플리케이션을 CloudB로 이동하면, 거기에는 해당 스케줄러 필터나 힌트가 없기 때문에 다른 동작을 하게 됩니다.

따라서 플레이버 추가 스펙과 스케줄러 힌트 모두 상호운용성이 없습니다.

8 어느 것을 쓸 것인가?

커스텀 스케줄러 필터를 정의할 때 힌트나 부가 스펙을 사용할 수 있습니다. 만약 하이퍼바이저에서 게스트를 생성할 때 어떤 동작을 위해 플레이버 부가 스펙이 필요하거나 나중에 게스트를 생성할 때 사용한 원래의 플레이버 부가 스펙을 검색해야 하는 경우라면, 부가 스펙을 사용하는 것이 좋습니다. 그런 필요가 없다면, 스케줄러 힌트를 사용하는 것이 명백한 선택일 수 있습니다. 특히 특정 스케줄링 동작을 노출하기 위해 최종 사용자 관점에서 스케줄러 힌트를 사용하는 것이 더 쉬울 수 있습니다. 하지만 힌트는 잘 문서화되어야 하며, 최종 사용자는 해당 힌트가 다른 클라우드에서는 제공되지 않을 수 있다는 점을 인식해야 합니다. 또한, 다른 클라우드에서 해당 힌트가 제공되는지 여부를 쉽게 알 수 있는 방법이 없습니다. 장기적으로 보면, 플레이버 부가 스펙이 힌트보다 더 표준화될 가능성이 높기 때문에 궁극적으로는 부가 스펙을 사용하는 것이 권장됩니다.

10 같이 보기

• 플레이버 부가 스펙과 이미지 속성