OpenStack의 로드 밸런싱

대규모 클라우드 시스템에서는 컴퓨팅 리소스에 대한 로드의 자동 균형 조정 또는 평준화 문제가 특히 심각합니다. Tionix(Rostelecom 그룹 기업의 일부인 클라우드 서비스 개발자 및 운영업체)도 이 문제를 해결했습니다.

그리고 우리의 주요 개발 플랫폼은 OpenStack이고 우리 모두가 마찬가지로 게으르기 때문에 플랫폼에 이미 포함되어 있는 기성 모듈을 선택하기로 결정했습니다. 우리의 선택은 Watcher에 있었고 우리는 필요에 따라 이를 사용하기로 결정했습니다.

먼저 용어와 정의를 살펴보겠습니다.

용어 및 정의

골 달성해야 하는 사람이 읽을 수 있고, 관찰할 수 있고, 측정할 수 있는 최종 결과입니다. 각 목표를 달성하기 위한 하나 이상의 전략이 있습니다. 전략은 주어진 목표에 대한 해결책을 찾을 수 있는 알고리즘을 구현하는 것입니다.

행동 OpenStack 클러스터의 대상 관리 리소스의 현재 상태를 변경하는 기본 작업입니다. 예: 가상 머신 마이그레이션(migration), 노드의 전원 상태 변경(change_node_power_state), nova 서비스 상태 변경(change_nova_service_state) ), 플레이버 변경(크기 조정), NOP 메시지 등록(nop), 특정 시간 동안 작업 부족 - 일시 중지(sleep), 디스크 전송(volume_ migration).

행동 계획 - 특정 목표를 달성하기 위해 특정 순서에 따라 수행되는 특정 작업 흐름입니다. 실행 계획에는 일련의 성과 지표와 함께 측정된 글로벌 성과도 포함되어 있습니다. 감사가 성공적으로 완료되면 Watcher가 실행 계획을 생성하며, 그 결과 사용된 전략이 목표 달성을 위한 솔루션을 찾습니다. 실행 계획은 순차적 실행 목록으로 구성됩니다.

심사 클러스터 최적화 요청입니다. 주어진 클러스터에서 하나의 목표를 달성하기 위해 최적화가 수행됩니다. 감사가 성공할 때마다 Watcher는 실행 계획을 생성합니다.

감사 범위 감사가 수행되는 리소스 세트입니다(가용성 영역, 노드 집계자, 개별 컴퓨팅 노드 또는 스토리지 노드 등). 감사 범위는 각 템플릿에 정의됩니다. 감사 범위를 지정하지 않으면 전체 클러스터가 감사됩니다.

감사 템플릿 — 감사 시작을 위해 저장된 설정 세트입니다. 동일한 설정으로 감사를 여러 번 실행하려면 템플릿이 필요합니다. 템플릿에는 반드시 감사 목적이 포함되어야 하며, 전략이 지정되지 않은 경우 가장 적합한 기존 전략이 선택됩니다.

무리 컴퓨팅, 스토리지 및 네트워킹 리소스를 제공하고 동일한 OpenStack 관리 노드에 의해 관리되는 물리적 시스템의 모음입니다.

클러스터 데이터 모델(CDM) 클러스터에서 관리하는 리소스의 현재 상태와 토폴로지를 논리적으로 표현한 것입니다.

효율성 지표 - 이 전략을 사용하여 생성된 솔루션이 어떻게 수행되는지 나타내는 지표입니다. 성과 지표는 특정 목표에 특정하며 일반적으로 결과 실행 계획의 글로벌 효과를 계산하는 데 사용됩니다.

효능규격 해당 목표를 달성하기 위한 전략이 솔루션에서 달성해야 하는 다양한 성과 지표를 정의하는 각 목표와 관련된 특정 기능 세트입니다. 실제로 전략에 의해 제안된 각 솔루션은 글로벌 효율성을 계산하기 전에 사양과 비교하여 확인됩니다.

채점 엔진 잘 정의된 입력과 잘 정의된 출력이 있고 순전히 수학적 작업을 수행하는 실행 파일입니다. 이렇게 하면 계산이 수행되는 환경에 관계없이 계산이 수행되므로 어디에서나 동일한 결과가 제공됩니다.

감시자 플래너 - Watcher 의사 결정 엔진의 일부입니다. 이 모듈은 전략에 의해 생성된 일련의 작업을 수행하고 이러한 다양한 작업을 적시에 예약하는 방법과 각 작업에 대한 전제 조건을 지정하는 워크플로 계획을 생성합니다.

감시자 목표 및 전략

골
전략

더미 목표
더미 전략 

샘플 채점 엔진을 사용한 더미 전략

크기 조정이 포함된 더미 전략

에너지 절약
에너지 절약 전략

서버 통합
기본 오프라인 서버 통합

VM 워크로드 통합 전략

워크로드 밸런싱
워크로드 균형 마이그레이션 전략

스토리지 용량 균형 전략

워크로드 안정화

시끄러운 이웃
시끄러운 이웃

열 최적화
출구 온도 기반 전략

기류 최적화
균일한 공기 흐름 마이그레이션 전략

하드웨어 유지 관리
영역 마이그레이션

분류되지 않음
작동시키는 것

더미 목표 — 테스트 목적으로 사용되는 예약된 목표입니다.

관련 전략: 더미 전략, 샘플 채점 엔진을 사용하는 더미 전략, 크기 조정이 포함된 더미 전략. 더미 전략은 Tempest를 통한 통합 테스트에 사용되는 더미 전략입니다. 이 전략은 유용한 최적화를 제공하지 않으며 유일한 목적은 Tempest 테스트를 사용하는 것입니다.

샘플 채점 엔진을 사용하는 더미 전략 - 전략은 이전 전략과 유사하며, 유일한 차이점은 기계 학습 방법을 사용하여 계산을 수행하는 샘플 "점수 엔진"을 사용한다는 것입니다.

크기 조정이 포함된 더미 전략 - 전략은 이전 전략과 유사하며 유일한 차이점은 플레이버 변경(마이그레이션 및 크기 조정)을 사용한다는 것입니다.

프로덕션에는 사용되지 않습니다.

에너지 절약 — 에너지 소비를 최소화합니다. 이 목표의 에너지 절약 전략은 VM 워크로드 통합 전략(서버 통합)과 함께 리소스 활용도가 낮은 기간에도 워크로드를 동적으로 통합하여 에너지를 절약하는 동적 전원 관리(DPM) 기능을 제공합니다. 가상 머신은 더 적은 수의 노드로 이동됩니다. , 불필요한 노드는 비활성화됩니다. 통합 후 전략은 지정된 매개변수에 따라 노드를 켜거나 끄는 결정을 제공합니다. "min_free_hosts_num" - 로드를 기다리는 무료로 활성화된 노드 수 및 "free_used_percent" - 무료로 활성화된 호스트의 비율 머신이 차지하는 노드 수. 전략이 작동하려면 다음이 있어야 합니다. 노드의 전원 순환을 처리하도록 Ironic을 활성화하고 구성했습니다.

전략 매개변수

매개변수
тип
기본적으로
описание

free_used_percent
번호
10.0
가상 머신이 있는 컴퓨팅 노드 수에 대한 사용 가능한 컴퓨팅 노드 수의 비율

min_free_hosts_num
INT
1
최소 사용 가능한 컴퓨팅 노드 수

클라우드에는 노드가 XNUMX개 이상 있어야 합니다. 사용되는 방법은 노드의 전원 상태를 변경하는 것입니다(change_node_power_state). 이 전략에는 측정항목 수집이 필요하지 않습니다.

서버 통합 - 컴퓨팅 노드 수를 최소화합니다(통합). 여기에는 기본 오프라인 서버 통합 전략과 VM 워크로드 통합 전략이라는 두 가지 전략이 있습니다.

기본 오프라인 서버 통합 전략은 사용되는 총 서버 수와 ​​마이그레이션 횟수를 최소화합니다.

기본 전략에는 다음 측정항목이 필요합니다.

측정항목
서비스
플러그인
논평

계산.노드.cpu.퍼센트
운고계
없음
 

CPU_util
운고계
없음
 

전략 매개변수: migration_attempts - 잠재적인 종료 후보를 검색하기 위한 조합 수(기본값, 0, 제한 없음), 기간 - 메트릭 데이터 소스에서 정적 집계를 얻기 위한 시간 간격(기본값, 700).

사용된 방법: 마이그레이션, nova 서비스 상태 변경(change_nova_service_state).

VM 워크로드 통합 전략은 측정된 CPU 로드에 초점을 맞추고 리소스 용량 제약 조건에 따라 로드가 너무 많거나 적은 노드를 최소화하려고 시도하는 최초의 경험적 방법을 기반으로 합니다. 이 전략은 다음 네 단계를 사용하여 클러스터 리소스를 보다 효율적으로 사용하는 솔루션을 제공합니다.

1. 언로드 단계 - 과도하게 사용된 리소스 처리
2. 통합 단계 - 활용도가 낮은 리소스 처리
3. 솔루션 최적화 - 마이그레이션 수 감소
4. 사용하지 않는 컴퓨팅 노드를 비활성화합니다.

전략에는 다음 측정항목이 필요합니다.

측정항목
서비스
플러그인
논평

기억
운고계
없음
 

디스크.루트.크기
운고계
없음
 

다음 지표는 선택 사항이지만 가능한 경우 전략 정확성을 향상시킵니다.

측정항목
서비스
플러그인
논평

메모리.레지던트
운고계
없음
 

CPU_util
운고계
없음
 

전략 매개변수: period — 지표 데이터 소스에서 정적 집계를 가져오는 시간 간격(초)(기본값: 3600)

이전 전략과 동일한 방법을 사용합니다. 자세한 내용은 여기에.

워크로드 밸런싱 — 컴퓨팅 노드 간의 작업 부하 균형을 조정합니다. 목표에는 워크로드 균형 마이그레이션 전략, 워크로드 안정화, 스토리지 용량 균형 전략의 세 가지 전략이 있습니다.

워크로드 균형 마이그레이션 전략은 호스트 가상 머신 워크로드를 기반으로 가상 머신 마이그레이션을 실행합니다. 노드의 CPU 또는 RAM 사용률(%)이 지정된 임계값을 초과할 때마다 마이그레이션 결정이 내려집니다. 이 경우 이동된 가상 머신은 노드를 모든 노드의 평균 워크로드에 더 가깝게 가져와야 합니다.

요구 사항

• 물리적 프로세서 사용
• 최소 XNUMX개의 물리적 컴퓨팅 노드
• 각 컴퓨팅 노드에서 실행되는 Ceilometer 구성 요소인 ceilometer-agent-compute와 Ceilometer API를 설치 및 구성하고 다음 측정항목을 수집했습니다.

측정항목
서비스
플러그인
논평

CPU_util
운고계
없음
 

메모리.레지던트
운고계
없음
 

전략 매개변수:

매개변수
тип
기본적으로
описание

통계
끈
'cpu_util'
기본 측정항목은 'cpu_util', 'memory.resident'입니다.

임계값
번호
25.0
마이그레이션을 위한 워크로드 임계값입니다.

기간
번호
300
누적 기간 Ceilometer.

사용된 방법은 마이그레이션입니다.

워크로드 안정화는 라이브 마이그레이션을 사용하여 워크로드를 안정화하는 것을 목표로 하는 전략입니다. 이 전략은 표준편차 알고리즘을 기반으로 하며 클러스터에 정체가 있는지 여부를 판단하고 이에 대응하여 머신 마이그레이션을 트리거하여 클러스터를 안정화합니다.

요구 사항

• 물리적 프로세서 사용
• 최소 XNUMX개의 물리적 컴퓨팅 노드
• 각 컴퓨팅 노드에서 실행되는 Ceilometer 구성 요소인 ceilometer-agent-compute와 Ceilometer API를 설치 및 구성하고 다음 측정항목을 수집했습니다.

측정항목
서비스
플러그인
논평

CPU_util
운고계
없음
 

메모리.레지던트
운고계
없음
 

스토리지 용량 균형 전략(Queens부터 구현된 전략) - 이 전략은 Cinder 풀의 로드에 따라 디스크를 전송합니다. 풀 활용률이 지정된 임계값을 초과할 때마다 전송 결정이 내려집니다. 이동 중인 디스크는 풀을 모든 Cinder 풀의 평균 로드에 더 가깝게 가져와야 합니다.

요구 사항 및 제한 사항

• 최소 XNUMX개의 Cinder 풀;
• 디스크 마이그레이션 가능성.
• 클러스터 데이터 모델 - Cinder 클러스터 데이터 모델 수집기입니다.

전략 매개변수:

매개변수
тип
기본적으로
описание

볼륨_임계값
번호
80.0
볼륨 균형을 조정하기 위한 디스크의 임계값입니다.

사용되는 방법은 디스크 마이그레이션(volume_ migration)입니다.

시끄러운 이웃 - 마지막 수준 캐시를 과도하게 사용하여 IPC 측면에서 우선 순위가 높은 가상 머신의 성능에 부정적인 영향을 미치는 우선 순위가 낮은 가상 머신인 "시끄러운 이웃"을 식별하고 마이그레이션합니다. 자체 전략: Noisy Neighbor(사용된 전략 매개변수는 캐시_임계값(기본값은 35)), 성능이 지정된 값으로 떨어지면 마이그레이션이 시작됩니다. 전략이 작동하려면 활성화됩니다. LLC(마지막 레벨 캐시) 메트릭, CMT를 지원하는 최신 Intel 서버, 다음 측정항목을 수집합니다.

측정항목
서비스
플러그인
논평

CPU_l3_cache
운고계
없음
인텔 필요 CMT.

클러스터 데이터 모델(기본값): Nova 클러스터 데이터 모델 수집기입니다. 사용된 방법은 마이그레이션입니다.

대시보드를 통한 이 목표 작업은 Queens에서 완전히 구현되지 않았습니다.

열 최적화 - 온도 체계를 최적화합니다. 출구(배기) 온도는 서버의 열/작업 부하 상태를 측정하는 중요한 열 원격 측정 시스템 중 하나입니다. 대상에는 소스 호스트의 배출구 온도가 구성 가능한 임계값에 도달할 때 열적으로 유리한 호스트(최저 배출구 온도)로 워크로드를 마이그레이션하기로 결정하는 배출구 온도 기반 전략이라는 하나의 전략이 있습니다.

전략이 작동하려면 Intel Power Node Manager가 설치 및 구성된 서버가 필요합니다. 3.0 이상, 다음 측정항목을 수집합니다.

측정항목
서비스
플러그인
논평

hardware.ipmi.node.outlet_temp
운고계
IPMI
 

전략 매개변수:

매개변수
тип
기본적으로
описание

임계값
번호
35.0
마이그레이션을 위한 온도 임계값입니다.

기간
번호
30
지표 데이터 소스에서 통계 집계를 가져오는 시간 간격(초)입니다.

사용된 방법은 마이그레이션입니다.

기류 최적화 — 환기 모드를 최적화합니다. 자체 전략 - Live Migration을 이용한 균일한 Airflow. 이 전략은 서버 팬의 공기 흐름이 지정된 임계값을 초과할 때마다 가상 머신 마이그레이션을 트리거합니다.

전략이 작동하려면 다음이 필요합니다.

• 하드웨어: 컴퓨팅 노드 < NodeManager 3.0 지원;
• 최소 XNUMX개의 컴퓨팅 노드;
• 각 컴퓨팅 노드에 설치 및 구성된 ceilometer-agent-compute 및 Ceilometer API 구성 요소는 공기 흐름, 시스템 전력, 입구 온도와 같은 측정항목을 성공적으로 보고할 수 있습니다.

측정항목
서비스
플러그인
논평

hardware.ipmi.node.airflow
운고계
IPMI
 

하드웨어.ipmi.node.온도
운고계
IPMI
 

하드웨어.ipmi.node.power
운고계
IPMI
 

전략이 작동하려면 Intel Power Node Manager 3.0 이상이 설치 및 구성된 서버가 필요합니다.

제한 사항: 이 개념은 생산용이 아닙니다.

반복당 하나의 가상 머신만 마이그레이션할 계획이므로 지속적인 감사와 함께 이 알고리즘을 사용하는 것이 좋습니다.

실시간 마이그레이션이 가능합니다.

전략 매개변수:

매개변수
тип
기본적으로
описание

임계값_기류
번호
400.0
마이그레이션을 위한 기류 임계값 단위는 0.1CFM입니다.

임계값_입구_t
번호
28.0
마이그레이션 결정을 위한 입구 온도 임계값

임계값_전력
번호
350.0
마이그레이션 결정을 위한 시스템 전력 임계값

기간
번호
30
지표 데이터 소스에서 통계 집계를 가져오는 시간 간격(초)입니다.

사용된 방법은 마이그레이션입니다.

하드웨어 유지 보수 — 하드웨어 유지 관리. 이 목표와 관련된 전략은 영역 마이그레이션입니다. 이 전략은 하드웨어 유지 관리가 필요한 경우 가상 머신과 디스크를 효과적으로 자동으로 최소화하기 위한 도구입니다. 전략은 가중치에 따라 행동 계획을 수립합니다. 즉, 가중치가 더 높은 일련의 행동이 다른 행동보다 먼저 계획됩니다. action_weights와 병렬화라는 두 가지 구성 옵션이 있습니다.

제한 사항: 작업 가중치 및 병렬화를 구성해야 합니다.

전략 매개변수:

매개변수
тип
기본적으로
описание

계산 노드
정렬
없음
마이그레이션을 위한 컴퓨팅 노드.

스토리지 풀
정렬
없음
마이그레이션용 스토리지 노드.

평행_총
정수
6
병렬로 실행해야 하는 총 활동 수입니다.

병렬_노드당
정수
2
각 컴퓨팅 노드에 대해 병렬로 수행되는 작업 수입니다.

병렬_당_풀
정수
2
각 스토리지 풀에 대해 병렬로 수행되는 작업 수입니다.

우선
대상
없음
가상 머신 및 디스크의 우선순위 목록입니다.

with_attached_volume
부울
거짓
False - 모든 디스크가 마이그레이션된 후 가상 머신이 마이그레이션됩니다. True - 연결된 모든 디스크가 마이그레이션된 후에 가상 머신이 마이그레이션됩니다.

컴퓨팅 노드 배열의 요소:

매개변수
тип
기본적으로
описание

src_node
현
없음
가상 머신이 마이그레이션되는 컴퓨팅 노드입니다(필수).

dst_node
현
없음
가상 머신이 마이그레이션되는 노드를 계산합니다.

스토리지 노드 배열 요소:

매개변수
тип
기본적으로
описание

src_pool
현
없음
디스크가 마이그레이션되는 스토리지 풀입니다(필수).

dst_pool
현
없음
디스크가 마이그레이션되는 스토리지 풀입니다.

src_type
현
없음
원래 디스크 유형(필수)

dst_type
현
없음
결과 디스크 유형(필수)

객체 우선순위 요소:

매개변수
тип
기본적으로
описание

프로젝트
정렬
없음
프로젝트 이름.

계산 노드
정렬
없음
노드 이름을 계산합니다.

스토리지_풀
정렬
없음
스토리지 풀 이름.

계산
열거 형
없음
가상 머신 매개변수["vcpu_num", "mem_size", "disk_size", "created_at"].

저장
열거 형
없음
디스크 매개변수[“size”, “created_at”].

사용되는 방법은 가상 머신 마이그레이션, 디스크 마이그레이션입니다.

분류되지 않음 - 전략 개발 프로세스를 촉진하는 데 사용되는 보조 목표입니다. 사양이 포함되어 있지 않으며 전략이 아직 기존 목표와 연결되지 않은 경우 언제든지 사용할 수 있습니다. 이 목표는 전환점으로 사용될 수도 있습니다. 이 목표와 관련된 전략은 Actuator입니다.   

새 목표 만들기

감시자 결정 엔진 전략을 사용하여 달성할 수 있는 외부 목표를 통합할 수 있는 "외부 목표" 플러그인 인터페이스가 있습니다.

새 목표를 만들기 전에 기존 목표가 귀하의 요구 사항을 충족하지 않는지 확인해야 합니다.

새 플러그인 만들기

새 대상을 만들려면 다음을 수행해야 합니다. 대상 클래스를 확장하고 클래스 메서드를 구현합니다. get_name() 생성하려는 새 대상의 고유 ID를 반환합니다. 이 고유 식별자는 나중에 선언하는 진입점 이름과 일치해야 합니다.

다음으로 클래스 메소드를 구현해야 합니다. get_display_name() 생성하려는 대상의 번역된 표시 이름을 반환합니다(번역 도구에서 자동으로 수집할 수 있도록 번역된 문자열을 반환하는 변수를 사용하지 마세요).

클래스 메소드 구현 get_translatable_display_name()새 대상의 번역 키(실제로는 영어 표시 이름)를 반환합니다. 반환 값은 get_display_name()으로 변환된 문자열과 일치해야 합니다.

그의 방법을 구현 get_efficacy_사양()목표에 대한 효율성 사양을 반환합니다. get_efficacy_specation() 메서드는 Watcher에서 제공하는 Unclassified() 인스턴스를 반환합니다. 이 성능 사양은 빈 사양에 해당하므로 목표를 개발하는 과정에서 유용합니다.

→ 자세한 내용은 여기를 참조하십시오.

감시자 아키텍처(자세한 내용) 여기에).

구성 요소

감시자 API - Watcher에서 제공하는 REST API를 구현한 컴포넌트입니다. 상호 작용 메커니즘: CLI, Horizon 플러그인, Python SDK.

감시자 DB — 감시자 데이터베이스.

감시자 적용자 — Watcher Decision Engine 구성 요소에 의해 생성된 작업 계획의 실행을 구현하는 구성 요소입니다.

감시자 결정 엔진 - 감사 목표를 달성하기 위해 잠재적인 최적화 조치 세트를 계산하는 역할을 담당하는 구성 요소입니다. 전략이 지정되지 않은 경우 구성 요소는 가장 적절한 전략을 독립적으로 선택합니다.

감시자 메트릭 게시자 - 일부 지표나 이벤트를 수집 및 계산하고 이를 CEP 엔드포인트에 게시하는 구성 요소입니다. 구성 요소의 기능은 Ceilometer 게시자를 통해 제공될 수도 있습니다.

복합 이벤트 처리(CEP) 엔진 — 복잡한 이벤트 처리를 위한 엔진. 성능상의 이유로 동시에 실행되는 여러 CEP 엔진 인스턴스가 있을 수 있으며, 각 인스턴스는 특정 유형의 지표/이벤트를 처리합니다. Watcher 시스템에서 CEP는 두 가지 유형의 작업을 트리거합니다. - 시계열 데이터베이스에 해당 이벤트/메트릭을 기록합니다. - Openstack 클러스터는 정적 시스템이 아니기 때문에 이 이벤트가 현재 최적화 전략의 결과에 영향을 미칠 수 있는 경우 Watcher 결정 엔진에 적절한 이벤트를 보냅니다.

구성 요소는 AMQP 프로토콜을 사용하여 상호 작용합니다.

→ 감시자 구성

Watcher와의 상호 작용 방식

감시자 테스트 결과

1. 최적화 - 실행 계획 500 페이지(순수 Queens 및 Tionix 모듈이 있는 스탠드 모두)에서는 감사가 시작되고 실행 계획이 생성된 후에만 나타나며, 비어 있는 페이지는 정상적으로 열립니다.
2. 작업 세부 정보 탭에 오류가 있어 감사 목표와 전략을 얻을 수 없습니다(순수 Queens 및 Tionix 모듈이 있는 스탠드 모두에서).
3. Dummy(테스트) 목적의 감사가 정상적으로 생성 및 실행되며, 실행 계획이 생성됩니다.
4. 미분류 목표에 대한 감사는 목표가 작동하지 않고 새 전략을 생성할 때 중간 구성을 위한 것이기 때문에 생성되지 않습니다.
5. Workload Balancing(스토리지 용량 균형 전략)을 위한 감사가 성공적으로 생성되었지만 작업 계획이 생성되지 않았습니다. 스토리지 풀 최적화가 필요하지 않습니다.
6. Workload Balancing 목표(Workload Balance 마이그레이션 전략)에 대한 감사가 성공적으로 생성되었지만 작업 계획이 생성되지 않았습니다.
7. Workload Balancing(Workload Stabilization Strategy)에 대한 감사가 실패합니다.
8. Noisy Neighbor 대상에 대한 감사가 성공적으로 생성되었지만 작업 계획이 생성되지 않았습니다.
9. 하드웨어 유지 관리를 위한 감사가 성공적으로 생성되었지만 작업 계획이 완전히 생성되지 않았습니다(성과 지표는 생성되었지만 작업 목록 자체는 생성되지 않음).
10. 컴퓨팅 및 제어 노드의 nova.conf 구성(기본 섹션인 Compute_monitors = cpu.virt_driver)을 편집해도 오류가 수정되지 않습니다.
11. 서버 통합(기본 전략)을 대상으로 하는 감사도 실패합니다.
12. 서버 통합(VM 워크로드 통합 전략)을 위한 감사가 오류로 인해 실패합니다. 로그에 소스 데이터를 가져오는 중 오류가 있습니다. 특히 오류에 대한 논의 여기에.
    구성 파일에 Watcher를 지정하려고 했습니다(도움이 되지 않았습니다. 모든 최적화 페이지의 오류로 인해 구성 파일의 원래 내용으로 돌아가도 상황이 수정되지 않습니다).
    [watcher_strategies.basic] 데이터 소스 = ceilometer, gnocchi
13. 에너지 절약 감사에 실패했습니다. 로그에 따르면 여전히 Ironic이 없다는 문제가 있으며 베어메탈 서비스 없이는 작동하지 않습니다.
14. 열 최적화 감사에 실패했습니다. 역추적은 Server Consolidation(VM 워크로드 통합 전략)과 동일합니다(소스 데이터 오류).
15. Airflow Optimization 목적의 감사가 오류로 인해 실패합니다.

다음 감사 완료 오류도 발생합니다. Decision-engine.log 로그의 역추적(클러스터 상태가 정의되지 않음)

→ 오류에 대한 논의 여기에

결론

XNUMX개월 간의 연구 결과, 제대로 작동하는 로드 밸런싱 시스템을 얻기 위해서는 이 부분에서 Openstack 플랫폼용 도구를 개선하는 데 긴밀히 협력해야 한다는 분명한 결론이 나왔습니다.

Watcher는 엄청난 잠재력을 지닌 심각하고 빠르게 발전하는 제품임이 입증되었으며, 이를 완전히 사용하려면 많은 진지한 작업이 필요합니다.

그러나 이에 대한 자세한 내용은 시리즈의 다음 기사에서 다루겠습니다.

출처 : habr.com