Compute의 자동 확장
Red Hat OpenStack Platform에서 자동 확장 구성
초록
1장. Compute의 자동 스케일링 구성 링크 복사링크가 클립보드에 복사되었습니다!
이 가이드에서는 많은 시스템 사용량에 대응하여 컴퓨팅 인스턴스를 자동으로 확장하는 방법을 설명합니다. CPU 또는 메모리 사용과 같은 요소를 고려하는 사전 정의된 규칙을 사용하면 필요에 따라 자동으로 추가 인스턴스를 추가하고 제거하도록 오케스트레이션(heat)을 구성할 수 있습니다.
1.1. 아키텍처 개요 링크 복사링크가 클립보드에 복사되었습니다!
1.1.1. 오케스트레이션 링크 복사링크가 클립보드에 복사되었습니다!
자동 확장의 핵심 구성 요소는 Orchestration(heat)입니다. 오케스트레이션을 사용하면 사람이 읽을 수 있는 YAML 템플릿을 사용하여 규칙을 정의할 수 있습니다. 이러한 규칙은 추가 인스턴스 추가를 결정하기 전에 Telemetry 데이터를 평가할 수 있습니다. 그런 다음 활동이 종속되면 오케스트레이션에서 불필요한 인스턴스를 자동으로 제거할 수 있습니다.
1.1.2. telemetry 링크 복사링크가 클립보드에 복사되었습니다!
Telemetry는 인스턴스 및 물리적 호스트의 CPU, 스토리지 및 메모리 사용률에 대한 데이터를 수집하여 OpenStack 환경의 성능 모니터링을 수행합니다. 오케스트레이션 템플릿은 사전 정의된 작업을 수행할지 여부를 평가할 때 Telemetry 데이터를 검사합니다.
1.1.3. 주요 용어 링크 복사링크가 클립보드에 복사되었습니다!
- 스택 - 스택은 애플리케이션을 운영하는 데 필요한 모든 리소스를 포함합니다. 단일 인스턴스 및 해당 리소스만큼 단순하거나 다중 계층 애플리케이션을 구성하는 모든 리소스 종속 항목이 있는 여러 인스턴스만큼 복잡할 수 있습니다.
템플릿 - Heat가 실행할 일련의 작업을 정의하는 YAML 스크립트입니다. 예를 들어 특정 기능에 대해 별도의 템플릿을 사용하는 것이 좋습니다.
- 스택 템플릿 - Telemetry가 응답해야 하는 임계값을 정의하고 자동 확장 그룹을 정의하는 위치입니다.
- 환경 템플릿 - 사용할 플레이버 및 이미지, 가상 네트워크를 구성하는 방법, 설치해야 하는 소프트웨어 등 환경에 대한 빌드 정보를 정의합니다.
1.2. 예: CPU 사용량에 따라 자동 확장 링크 복사링크가 클립보드에 복사되었습니다!
이 예제에서 Orchestration은 Telemetry 데이터를 검사하고 CPU 사용량이 높은 인스턴스 수를 자동으로 늘립니다. 필요한 규칙 및 후속 구성을 정의하기 위해 스택 템플릿과 환경 템플릿이 생성됩니다. 이 예제에서는 기존 리소스(예: 네트워크)를 사용하고 사용자 환경에서 다를 가능성이 있는 이름을 사용합니다.
인스턴스 플레이버, 네트워킹 구성 및 이미지 유형을 설명하는 환경 템플릿을 만듭니다.
/etc/heat/templates/cirros.yaml에 다음 값을 입력합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow /root/environment.yaml에 오케스트레이션 리소스를 등록합니다.resource_registry: "OS::Nova::Server::Cirros": "file:///etc/heat/templates/cirros.yaml"resource_registry: "OS::Nova::Server::Cirros": "file:///etc/heat/templates/cirros.yaml"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 조사할 CPU 임계값과 추가해야 하는 인스턴스 수를 설명하는 스택 템플릿을 생성합니다. 이 템플릿에 참여할 수 있는 최소 및 최대 인스턴스 수를 정의하는 인스턴스 그룹도 생성됩니다.
/root/example.yaml에 다음 값을 입력합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow Telemetry 컬렉션 간격을 업데이트합니다. 기본적으로 Telemetry는 CPU 데이터에 대해 10분마다 인스턴스를 폴링합니다. 이 예에서는
/etc/ceilometer/pipeline.yaml에서 간격을 60초로 변경합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고더 높은 폴링 간격으로 인해 컨트롤 플레인에 로드가 증가할 수 있으므로 프로덕션 환경에서는 폴링 간격이 60초인 폴링 기간을 권장하지 않습니다.
모든 OpenStack 서비스를 다시 시작하여 업데이트된 Telemetry 설정을 적용합니다.
openstack-service restart
# openstack-service restartCopy to Clipboard Copied! Toggle word wrap Toggle overflow 참고이 단계에서는 OpenStack 배포에 대한 간단한 중단이 발생합니다.
오케스트레이션 스크립트를 실행하여 환경을 빌드하고 인스턴스를 배포합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 오케스트레이션에서는
scaleup_group정의에 설정된 대로 스택을 생성하고 단일 cirros 인스턴스를 시작합니다.min_size:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 또한 오케스트레이션에서는
cpu_alarm_high및cpu_alarm_low에 정의된 대로 스케일링 또는 스케일 다운 이벤트를 트리거하는 데 사용되는 두 개의 cpu 알람을 생성합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
1.2.1. 자동 확장 인스턴스 테스트 링크 복사링크가 클립보드에 복사되었습니다!
오케스트레이션은 cpu_alarm_high 임계값을 기반으로 인스턴스를 자동으로 확장합니다. cpu_alarm_high 정의에 설정된 대로 CPU 사용률이 50%를 초과하면 임계값: 50개
CPU 로드를 생성하려면 인스턴스에 로그인하고 dd 명령을 실행합니다.
ssh -i admin.pem cirros@192.168.122.232 dd if=/dev/zero of=/dev/null & dd if=/dev/zero of=/dev/null & dd if=/dev/zero of=/dev/null &
$ ssh -i admin.pem cirros@192.168.122.232
$ dd if=/dev/zero of=/dev/null &
$ dd if=/dev/zero of=/dev/null &
$ dd if=/dev/zero of=/dev/null &
dd 명령을 실행한 후 cirros 인스턴스에 100% CPU 사용률을 기대할 수 있습니다. 60초 후에 오케스트레이션에서 그룹을 두 개의 인스턴스로 자동 확장한 것을 확인할 수 있습니다.
60초 후에 오케스트레이션이 다시 세 개의 인스턴스로 자동 확장되었음을 확인합니다. 이 구성의 최대값이므로 scaleup_group 정의에 설정된 대로 max_size)를 확장하지 않습니다.
1.2.2. 인스턴스 자동 확장 링크 복사링크가 클립보드에 복사되었습니다!
오케스트레이션에서 cpu_alarm_low 임계값에 따라 인스턴스를 자동으로 축소합니다. 이 예에서는 CPU 사용률이 10% 미만이면 인스턴스가 축소됩니다. 실행 중인 dd 프로세스를 종료하고 오케스트레이션이 인스턴스를 다시 축소하기 시작하는 것을 관찰합니다.
dd 프로세스를 중지하면 cpu_alarm_low 이벤트가 트리거됩니다. 결과적으로 오케스트레이션은 자동으로 축소되고 인스턴스를 제거하기 시작합니다.
몇 분 후에 단일 인스턴스로 돌아가야 할 수 있습니다. scaleup_group 에서 허용되는 최소 인스턴스 수 :min_size: 1
1.3. 예: 자동 확장 애플리케이션 링크 복사링크가 클립보드에 복사되었습니다!
앞에서 설명한 기능을 사용하여 애플리케이션을 확장할 수도 있습니다. 예를 들어 한 번에 실행되는 여러 인스턴스 중 하나에서 제공하는 동적 웹 페이지입니다. 이 경우 인스턴스 간에 트래픽을 균등하게 분산하는 데 사용되는 Load Balancing-as-a-Service 를 제공하도록 neutron 을 구성할 수 있습니다.
다음 예에서 Orchestration은 Telemetry 데이터를 다시 검사하고 높은 CPU 사용량이 감지되면 인스턴스 수를 늘리거나 CPU 사용량이 설정된 값 아래에 반환되는 경우 인스턴스 수를 줄입니다.
로드 밸런서 환경의 속성을 설명하는 템플릿을 생성합니다.
/etc/heat/templates/lb-env.yaml에 다음 값을 입력합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 웹 애플리케이션을 실행할 인스턴스에 대한 다른 템플릿을 생성합니다. 다음 템플릿은 로드 밸런서를 생성하고 기존 네트워크를 사용합니다. 환경에 따라 매개변수를 바꾸고 템플릿을
/root/lb-webserver-rhel7.yaml과 같은 파일에 저장하십시오.Copy to Clipboard Copied! Toggle word wrap Toggle overflow Telemetry 컬렉션 간격을 업데이트합니다. 기본적으로 Telemetry는 CPU 데이터에 대해 10분마다 인스턴스를 폴링합니다. 이 예에서는
/etc/ceilometer/pipeline.yaml에서 간격을 60초로 변경합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고더 높은 폴링 간격으로 인해 컨트롤 플레인에 로드가 증가할 수 있으므로 프로덕션 환경에서는 폴링 간격이 60초인 폴링 기간을 권장하지 않습니다.
모든 OpenStack 서비스를 다시 시작하여 업데이트된 Telemetry 설정을 적용합니다.
openstack-service restart
# openstack-service restartCopy to Clipboard Copied! Toggle word wrap Toggle overflow 참고이 단계에서는 OpenStack 배포에 대한 간단한 중단이 발생합니다.
오케스트레이션 스크립트를 실행합니다. 그러면 환경이 빌드되고 템플릿을 사용하여 인스턴스를 배포합니다.
heat stack-create webfarm -f /root/lb-webserver-rhel7.yaml
# heat stack-create webfarm -f /root/lb-webserver-rhel7.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow /root/lb-webserver-rhel7.yaml을 실제 경로 및 파일 이름으로 바꿉니다.
오케스트레이션 → 스택 → Webfarm 의 대시보드에서 스택 생성을 모니터링할 수 있습니다. 스택이 생성되면 다음과 같이 여러 유용한 정보를 제공합니다.
- 수동 확장 또는 축소 이벤트를 트리거하는 데 사용할 수 있는 URL입니다.
- 웹 사이트의 IP 주소인 유동 IP 주소입니다.
- 전체 스택에 대한 CPU 로드를 표시하는 Telemetry 명령과 스케일링이 예상대로 작동하는지 확인하는 데 사용할 수 있습니다.
대시보드의 페이지 모양은 다음과 같습니다.
로드 밸런서를 보려면 네트워크 → 로드 밸런서를 엽니다.
멤버 를 클릭합니다. 이 페이지에는 부하 분산 풀의 멤버가 표시됩니다. 이는 웹 사이트 트래픽을 배포할 수 있는 인스턴스입니다. 해당 인스턴스가 생성되고 Apache를 설치 및 구성할 때까지 멤버는 Active 상태가 아닙니다.
웹 서버가 시작되면 인스턴스가 로드 밸런서의 활성 멤버로 표시됩니다.
이제 http://IP/hostname.php 에서 웹 애플리케이션에 액세스할 수 있습니다. 다음과 유사한 출력이 표시될 수 있습니다.
Hello, My name is we-zrwm-t4ezkpx34gxu-qbg5d7dqbc4j-server-mzdvigk2jugl
Hello, My name is we-zrwm-t4ezkpx34gxu-qbg5d7dqbc4j-server-mzdvigk2jugl
이제 대시보드의 스택 개요에서 Telemetry 명령을 실행하여 스택의 CPU 성능 데이터를 볼 수 있습니다. 명령은 다음과 같습니다.
ceilometer statistics -m cpu_util -q metadata.user_metadata.stack=8f86c3d5-15cf-4a64-b9e8-70215498c046 -p 60 -a avg
# ceilometer statistics -m cpu_util -q metadata.user_metadata.stack=8f86c3d5-15cf-4a64-b9e8-70215498c046 -p 60 -a avg
1.3.1. 자동 확장 애플리케이션 테스트 링크 복사링크가 클립보드에 복사되었습니다!
애플리케이션 스케일링을 수동으로 트리거하려면 대시보드의 스택 개요에서 REST 확장 URL 을 사용하거나 처음 배포된 인스턴스에서 리소스를 많이 사용하는 명령을 실행하여 부하를 생성합니다.
REST API를 사용하려면 REST easily Firefox add on 또는
curl과 같은HTTP POST요청을 수행할 수 있는 툴이 필요합니다. 스케일업 URL 을 복사하여 REST easy 양식에 붙여넣습니다.
또는
curl명령줄에서 매개 변수로 사용합니다.curl -X POST "scale-up URL"
$ curl -X POST "scale-up URL"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 인위적으로 로드를 생성하려면 인스턴스에 유동 IP를 할당하고 SSH로 로그인하여 CPU를 계속 사용하는 명령을 실행합니다. 예를 들면 다음과 같습니다.
dd if=/dev/zero of=/dev/null &
$ dd if=/dev/zero of=/dev/null &Copy to Clipboard Copied! Toggle word wrap Toggle overflow 중요예를 들어
top명령을 사용하여 CPU 사용량이 95%를 초과하는지 확인합니다. CPU 사용량이 충분히 높지 않은 경우dd명령을 병렬로 여러 번 실행하거나 다른 방법을 사용하여 CPU를 사용량 상태로 유지합니다.
다음에 Telemetry가 스택에서 CPU 데이터를 수집하면 스케일업 이벤트가 트리거되고 오케스트레이션 → 스택 → Webfarm → Events 에 표시됩니다. 새 웹 서버 인스턴스가 생성되어 로드 밸런서에 추가됩니다. 이 작업이 완료되면 인스턴스가 활성화되고 웹 사이트 URL이 로드 밸런서를 통해 스택의 두 인스턴스로 라우팅됩니다.
인스턴스를 초기화하고, Apache를 설치 및 구성하고, 애플리케이션이 배포되므로 생성에 몇 분이 걸릴 수 있습니다. HAProxy에서 모니터링하므로 인스턴스에서 활성 상태로 표시되기 전에 웹 사이트를 사용할 수 있는지 확인합니다.
새 인스턴스가 생성되는 동안 로드 밸런싱 풀의 멤버 목록은 대시보드에서 다음과 같이 표시됩니다.
추가 인스턴스가 생성될지 여부를 결정할 때 heat 스택의 평균 CPU 사용량이 고려됩니다. 두 번째 인스턴스에는 대부분 일반 CPU 사용량이 있으므로 첫 번째 인스턴스의 균형을 조정합니다. 그러나 두 번째 인스턴스도 사용량이 되고 첫 번째 및 두 번째 인스턴스의 평균 CPU 사용량이 95%를 초과하면 다른 인스턴스(세 번째) 인스턴스가 생성됩니다.
1.3.2. 애플리케이션 자동 확장 링크 복사링크가 클립보드에 복사되었습니다!
이는 스택의 평균 CPU 사용량이 사전 정의된 값 아래로 드롭될 때 스케일 다운 정책이 트리거된다는 점에서 1.2.2절. “인스턴스 자동 확장” 와 유사합니다. 이는 1.3.1절. “자동 확장 애플리케이션 테스트” 에 설명된 예제의 15%입니다. 또한 이러한 방식으로 스택에서 인스턴스를 제거하면 로드 밸런서에서 자동으로 제거됩니다. 그런 다음 웹 사이트 트래픽은 나머지 인스턴스에 자동으로 배포됩니다.