OpenStack의 로드 밸런싱(2부)

В 마지막 기사 Watcher를 사용하려는 시도에 대해 이야기하고 테스트 보고서를 제공했습니다. 우리는 대기업 또는 운영자 클라우드의 균형 및 기타 중요한 기능에 대한 테스트를 주기적으로 수행합니다.

해결되는 문제의 복잡성이 높기 때문에 프로젝트를 설명하기 위해 여러 기사가 필요할 수 있습니다. 오늘 우리는 클라우드에서 가상 머신의 균형을 맞추는 것에 관한 시리즈의 두 번째 기사를 게시합니다.

약간의 용어

VmWare 회사는 자신들이 개발하고 제공하는 가상화 환경의 로드 밸런싱을 위해 DRS(Distributed Resource Scheduler) 유틸리티를 도입했습니다.

그가 쓴대로 searchvmware.techtarget.com/definition/VMware-DRS
“VMware DRS(Distributed Resource Scheduler)는 가상 환경에서 컴퓨팅 부하와 사용 가능한 리소스의 균형을 맞추는 유틸리티입니다. 이 유틸리티는 VMware 인프라라는 가상화 제품군의 일부입니다.

VMware DRS를 사용하면 사용자는 가상 머신(VM) 간에 물리적 리소스를 배포하기 위한 규칙을 정의할 수 있습니다. 유틸리티는 수동 또는 자동 제어로 구성될 수 있습니다. VMware 리소스 풀은 쉽게 추가, 제거 또는 재구성될 수 있습니다. 원하는 경우 리소스 풀을 여러 사업부 간에 격리할 수 있습니다. 하나 이상의 가상 머신의 워크로드가 급격하게 변경되면 VMware DRS는 가상 머신을 물리적 서버 전체에 재분배합니다. 전체 작업 부하가 감소하면 일부 물리적 서버가 일시적으로 오프라인 상태가 되어 작업 부하가 통합될 수 있습니다."

왜 균형이 필요한가요?

우리의 의견으로는 DRS는 필수 클라우드 기능이지만 이것이 DRS를 항상 어디서나 사용해야 한다는 의미는 아닙니다. 클라우드의 목적과 요구 사항에 따라 DRS 및 균형 조정 방법에 대한 요구 사항이 다를 수 있습니다. 균형이 전혀 필요하지 않은 상황이 있을 수 있습니다. 아니면 해로울 수도 있습니다.

어디에서 어떤 클라이언트에게 DRS가 필요한지 더 잘 이해하기 위해 클라이언트의 목표와 목표를 고려해 보겠습니다. 클라우드는 퍼블릭 클라우드와 프라이빗 클라우드로 나눌 수 있습니다. 이러한 클라우드와 고객 목표 간의 주요 차이점은 다음과 같습니다.

프라이빗 클라우드/대기업 고객
퍼블릭 클라우드 / 중소기업, 개인

운영자의 주요 기준 및 목표
신뢰할 수 있는 서비스나 제품을 제공하는 것
경쟁이 치열한 시장에서 서비스 비용 절감

서비스 요구 사항
모든 수준과 모든 시스템 요소에서의 신뢰성

성능 보장

여러 범주로 가상 머신의 우선순위 지정 

정보 및 물리적 데이터 보안

SLA 및 연중무휴 지원
서비스 받기의 편의성 극대화

비교적 간단한 서비스

데이터에 대한 책임은 고객에게 있습니다.

VM 우선순위가 필요하지 않습니다.

표준 서비스 수준의 정보보안, 고객의 책임

결함이 있을 수 있습니다.

SLA 없음, 품질 보장되지 않음

이메일 지원

백업이 필요하지 않습니다

클라이언트 기능
적용 범위가 매우 넓습니다.

회사에서 상속된 레거시 애플리케이션.

각 클라이언트에 대한 복잡한 맞춤형 아키텍처.

선호도 규칙.

소프트웨어는 7x24 모드에서 멈추지 않고 작동합니다. 

즉각적인 백업 도구.

예측 가능한 주기적 고객 로드.
일반적인 애플리케이션 - 네트워크 밸런싱, Apache, WEB, VPN, SQL

잠시 동안 앱이 중단될 수 있습니다.

클라우드에서 VM의 임의 배포를 허용합니다.

클라이언트 백업

다수의 클라이언트에서 통계적으로 평균 로드를 예측할 수 있습니다.

아키텍처에 대한 시사점
지오클러스터링

중앙 집중식 또는 분산형 스토리지

예약된 IBS
컴퓨팅 노드의 로컬 데이터 스토리지

균형 목표
균일한 부하 분산

최대 애플리케이션 응답성 

밸런싱을 위한 최소 지연 시간

분명히 필요한 경우에만 균형 조정

예방적 유지보수를 위해 일부 장비 반출
서비스 비용 및 운영자 비용 절감 

부하가 낮은 경우 일부 리소스 비활성화

에너지 절약

인건비 절감

우리는 스스로 다음과 같은 결론을 내립니다.

프라이빗 클라우드의 경우대기업 고객에게 제공되는 DRS는 다음과 같은 제한 사항에 따라 사용할 수 있습니다.

• 정보 보안 및 균형을 맞출 때 선호도 규칙을 고려합니다.
• 사고 발생 시 충분한 예비 자원의 가용성;
• 가상 머신 데이터는 중앙 집중식 또는 분산형 스토리지 시스템에 있습니다.
• 시간이 지남에 따라 관리, 백업 및 균형 조정 절차가 엇갈리게 됩니다.
• 클라이언트 호스트 집합 내에서만 균형을 유지합니다.
• 불균형이 심한 경우에만 균형을 유지하는 것이 가장 효과적이고 안전한 VM 마이그레이션입니다(결국 마이그레이션이 실패할 수 있음).
• 상대적으로 "조용한" 가상 머신의 균형을 유지합니다("시끄러운" 가상 머신을 마이그레이션하는 데는 매우 오랜 시간이 걸릴 수 있음).
• "비용"을 고려한 균형 조정 - 스토리지 시스템 및 네트워크의 로드(대규모 클라이언트를 위한 맞춤형 아키텍처 포함)
• 각 VM의 개별 동작 특성을 고려하여 균형을 유지합니다.
• 밸런싱은 업무 외 시간(야간, 주말, 공휴일)에 수행하는 것이 좋습니다.

퍼블릭 클라우드의 경우소규모 고객에게 서비스를 제공하는 DRS는 다음과 같은 고급 기능을 통해 훨씬 더 자주 사용될 수 있습니다.

• 정보 보안 제한 및 선호도 규칙이 없습니다.
• 클라우드 내에서 균형을 유지합니다.
• 합리적인 시간에 균형을 유지합니다.
• 모든 VM의 균형을 유지합니다.
• "시끄러운" 가상 머신의 균형을 유지합니다(다른 사람을 방해하지 않도록).
• 가상 머신 데이터는 로컬 디스크에 있는 경우가 많습니다.
• 스토리지 시스템 및 네트워크의 평균 성능을 고려합니다(클라우드 아키텍처가 통합됨).
• 일반 규칙 및 사용 가능한 데이터 센터 동작 통계에 따라 균형을 조정합니다.

문제의 복잡성

균형 조정의 어려움은 DRS가 수많은 불확실한 요인을 다루어야 한다는 것입니다.

• 각 고객의 정보 시스템 사용자 행동;
• 정보 시스템 서버 운영을 위한 알고리즘;
• DBMS 서버의 동작;
• 컴퓨팅 리소스, 스토리지 시스템, 네트워크에 대한 부하;
• 클라우드 리소스를 확보하기 위해 서버가 서로 상호 작용합니다.

클라우드 리소스에 대한 수많은 가상 애플리케이션 서버 및 데이터베이스의 로드는 시간이 지남에 따라 발생하며, 그 결과는 예측할 수 없는 시간에 걸쳐 예측할 수 없는 효과로 나타나고 서로 겹칠 수 있습니다. 비교적 간단한 프로세스(예: 엔진 제어, 가정의 온수 시스템 제어)를 제어하기 위해서도 자동 제어 시스템은 복잡한 기술을 사용해야 합니다. 비례-적분-미분 피드백이 있는 알고리즘.

우리의 작업은 훨씬 더 복잡하며, 사용자의 외부 영향이 없더라도 시스템이 합리적인 시간 내에 설정된 값에 대한 로드 균형을 맞추지 못할 위험이 있습니다.

우리의 발전 역사

이 문제를 해결하기 위해 우리는 처음부터 시작하지 않고 기존 경험을 바탕으로 이 분야에 경험이 있는 전문가들과 교류하기 시작했습니다. 다행스럽게도 문제에 대한 우리의 이해는 완전히 일치했습니다.

단계 1

우리는 신경망 기술을 기반으로 한 시스템을 사용하고 이를 기반으로 자원을 최적화하려고 노력했습니다.

이 단계의 관심은 새로운 기술을 테스트하는 것이었고, 그 중요성은 다른 조건이 동일하다면 표준 접근 방식이 사실상 소진된 문제를 해결하기 위해 비표준 접근 방식을 적용하는 데 있었습니다.

우리는 시스템을 출시했고 실제로 균형을 맞추기 시작했습니다. 클라우드의 규모로 인해 개발자가 언급한 낙관적인 결과를 얻을 수는 없었지만 균형이 작동하고 있다는 것은 분명했습니다.

동시에 우리에게는 매우 심각한 한계가 있었습니다.

• 신경망을 훈련시키려면 가상 머신이 몇 주 또는 몇 달 동안 큰 변화 없이 실행되어야 합니다.
• 알고리즘은 이전의 "과거" 데이터 분석을 기반으로 최적화를 위해 설계되었습니다.
• 신경망을 훈련하려면 상당히 많은 양의 데이터와 컴퓨팅 리소스가 필요합니다.
• 최적화와 밸런싱은 상대적으로 드물게 수행될 수 있습니다. 몇 시간에 한 번만 수행하면 충분하지 않습니다.

단계 2

현재 상황이 만족스럽지 못하여 시스템을 수정하기로 결정하였고, 이를 위해 주요 질문 – 우리는 누구를 위해 그것을 만들고 있습니까?

첫째 - 기업 고객을 위한 것입니다. 이는 구현을 단순화하는 기업 제한 사항과 함께 빠르게 작동하는 시스템이 필요하다는 것을 의미합니다.

두 번째 질문 – “신속하게”라는 말은 무슨 뜻인가요? 짧은 토론의 결과, 우리는 단기적인 서지가 시스템에 공명을 일으키지 않도록 5~10분의 응답 시간으로 시작할 수 있다고 결정했습니다.

세번째 질문 – 선택할 균형 잡힌 서버 수의 크기는 얼마입니까?
이 문제는 저절로 해결되었습니다. 일반적으로 클라이언트는 서버 집합을 매우 크게 만들지 않으며 이는 집합을 30-40개의 서버로 제한하라는 기사의 권장 사항과 일치합니다.

또한 서버 풀을 분할하여 밸런싱 알고리즘 작업을 단순화합니다.

네 번째 질문 – 긴 학습 과정과 드문 균형을 갖춘 신경망이 우리에게 얼마나 적합한가요? 우리는 몇 초 안에 결과를 얻기 위해 더 간단한 운영 알고리즘을 선호하여 이를 포기하기로 결정했습니다.

이러한 알고리즘을 사용하는 시스템에 대한 설명과 그 단점을 찾을 수 있습니다. 여기에

우리는 이 시스템을 구현 및 출시했으며 고무적인 결과를 얻었습니다. 이제 이 시스템은 정기적으로 클라우드 로드를 분석하고 가상 머신 이동에 대한 권장 사항을 제공하는데 이는 대체로 정확합니다. 지금도 기존 가상 머신의 작업 품질을 향상시키면서 새로운 가상 머신에 대한 리소스를 10~15% 릴리스할 수 있다는 것은 분명합니다.

RAM 또는 CPU의 불균형이 감지되면 시스템은 Tionix 스케줄러에 명령을 내려 필요한 가상 머신의 실시간 마이그레이션을 수행합니다. 모니터링 시스템에서 볼 수 있듯이 가상 머신은 하나(상위) 호스트에서 다른(하위) 호스트로 이동하고 상위 호스트(노란색 원으로 강조 표시)에서 메모리를 확보했으며 각각 하위 호스트(흰색으로 강조 표시)에서 이를 점유했습니다. 서클).

이제 우리는 현재 알고리즘의 효율성을 보다 정확하게 평가하고 알고리즘에서 발생할 수 있는 오류를 찾으려고 노력하고 있습니다.

단계 3

이에 대해 진정하고 입증된 효과를 기다렸다가 주제를 닫을 수 있는 것 같습니다.
그러나 우리는 다음과 같은 명백한 최적화 기회에 의해 새로운 단계를 수행하도록 압력을 받습니다.

1. 예를 들어 통계는 다음과 같습니다. 여기에 и 여기에 XNUMX개 및 XNUMX개 프로세서 시스템은 단일 프로세서 시스템보다 성능이 훨씬 낮다는 것을 보여줍니다. 이는 모든 사용자가 단일 프로세서 시스템에 비해 다중 프로세서 시스템에서 구입한 CPU, RAM, SSD, LAN, FC로부터 훨씬 적은 출력을 받는다는 것을 의미합니다.
2. 리소스 스케줄러 자체에 심각한 오류가 있을 수 있습니다. 여기 기사 중 하나가 있어요 이 주제에.
3. RAM 및 캐시 모니터링을 위해 Intel과 AMD가 제공하는 기술을 사용하면 가상 머신의 동작을 연구하고 "시끄러운" 이웃이 "조용한" 가상 머신을 방해하지 않는 방식으로 배치할 수 있습니다.
4. 매개변수 세트 확장(네트워크, 스토리지 시스템, 가상 머신 우선순위, 마이그레이션 비용, 마이그레이션 준비 상태)

전체로

균형 조정 알고리즘을 개선하기 위한 작업의 결과는 최신 알고리즘을 사용하면 데이터 센터 리소스를 크게 최적화(25-30%)하는 동시에 고객 서비스 품질을 향상시킬 수 있다는 명확한 결론을 얻었습니다.

신경망 기반 알고리즘은 확실히 흥미로운 솔루션이지만 추가 개발이 필요하고 기존 제한으로 인해 프라이빗 클라우드에 일반적인 볼륨에서 이러한 종류의 문제를 해결하는 데 적합하지 않습니다. 동시에, 알고리즘은 상당한 규모의 퍼블릭 클라우드에서 좋은 결과를 보여주었습니다.

다음 문서에서는 프로세서, 스케줄러 및 높은 수준의 균형 조정 기능에 대해 자세히 설명합니다.

출처 : habr.com