Compute의 자동 확장


Red Hat OpenStack Platform 8

Red Hat OpenStack Platform에서 자동 확장 구성

OpenStack Documentation Team

초록

시스템 사용량에 대한 응답으로 Compute 인스턴스를 자동으로 확장합니다.

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 사용량이 높은 인스턴스 수를 자동으로 늘립니다. 필요한 규칙 및 후속 구성을 정의하기 위해 스택 템플릿과 환경 템플릿이 생성됩니다. 이 예제에서는 기존 리소스(예: 네트워크)를 사용하고 사용자 환경에서 다를 가능성이 있는 이름을 사용합니다.

  1. 인스턴스 플레이버, 네트워킹 구성 및 이미지 유형을 설명하는 환경 템플릿을 만듭니다. /etc/heat/templates/cirros.yaml 에 다음 값을 입력합니다.

    heat_template_version: 2014-10-16
    description: A base Cirros 0.3.4 server
    
    resources:
      server:
        type: OS::Nova::Server
        properties:
          block_device_mapping:
            - device_name: vda
              delete_on_termination: true
              volume_id: { get_resource: volume }
          flavor: m1.nano
          key_name: admin
          networks:
            - port: { get_resource: port }
    
      port:
        type: OS::Neutron::Port
        properties:
          network: private
          security_groups:
            - all
    
      floating_ip:
        type: OS::Neutron::FloatingIP
        properties:
          floating_network: public
    
      floating_ip_assoc:
        type: OS::Neutron::FloatingIPAssociation
        properties:
          floatingip_id: { get_resource: floating_ip }
          port_id: { get_resource: port }
    
      volume:
        type: OS::Cinder::Volume
        properties:
          image: 'Cirros 0.3.4'
          size: 1
    Copy to Clipboard Toggle word wrap
  2. /root/environment.yaml 에 오케스트레이션 리소스를 등록합니다.

    resource_registry:
    
        "OS::Nova::Server::Cirros": "file:///etc/heat/templates/cirros.yaml"
    Copy to Clipboard Toggle word wrap
  3. 조사할 CPU 임계값과 추가해야 하는 인스턴스 수를 설명하는 스택 템플릿을 생성합니다. 이 템플릿에 참여할 수 있는 최소 및 최대 인스턴스 수를 정의하는 인스턴스 그룹도 생성됩니다.

    /root/example.yaml 에 다음 값을 입력합니다.

    heat_template_version: 2014-10-16
    description: Example auto scale group, policy and alarm
    resources:
      scaleup_group:
        type: OS::Heat::AutoScalingGroup
        properties:
          cooldown: 60
          desired_capacity: 1
          max_size: 3
          min_size: 1
          resource:
            type: OS::Nova::Server::Cirros
    
      scaleup_policy:
        type: OS::Heat::ScalingPolicy
        properties:
          adjustment_type: change_in_capacity
          auto_scaling_group_id: { get_resource: scaleup_group }
          cooldown: 60
          scaling_adjustment: 1
    
      scaledown_policy:
        type: OS::Heat::ScalingPolicy
        properties:
          adjustment_type: change_in_capacity
          auto_scaling_group_id: { get_resource: scaleup_group }
          cooldown: 60
          scaling_adjustment: -1
    
      cpu_alarm_high:
        type: OS::Ceilometer::Alarm
        properties:
          meter_name: cpu_util
          statistic: avg
          period: 60
          evaluation_periods: 1
          threshold: 50
          alarm_actions:
            - {get_attr: [scaleup_policy, alarm_url]}
          comparison_operator: gt
    
      cpu_alarm_low:
        type: OS::Ceilometer::Alarm
        properties:
          meter_name: cpu_util
          statistic: avg
          period: 60
          evaluation_periods: 1
          threshold: 10
          alarm_actions:
            - {get_attr: [scaledown_policy, alarm_url]}
          comparison_operator: lt
    Copy to Clipboard Toggle word wrap
  4. Telemetry 컬렉션 간격을 업데이트합니다. 기본적으로 Telemetry는 CPU 데이터에 대해 10분마다 인스턴스를 폴링합니다. 이 예에서는 /etc/ceilometer/pipeline.yaml 에서 간격을 60초로 변경합니다.

    - name: cpu_source
    interval: 60
    meters:
    - "cpu"
    sinks:
    - cpu_sink
    Copy to Clipboard Toggle word wrap
    참고

    더 높은 폴링 간격으로 인해 컨트롤 플레인에 로드가 증가할 수 있으므로 프로덕션 환경에서는 폴링 간격이 60초인 폴링 기간을 권장하지 않습니다.

  5. 모든 OpenStack 서비스를 다시 시작하여 업데이트된 Telemetry 설정을 적용합니다.

    # openstack-service restart
    Copy to Clipboard Toggle word wrap
    참고

    이 단계에서는 OpenStack 배포에 대한 간단한 중단이 발생합니다.

  6. 오케스트레이션 스크립트를 실행하여 환경을 빌드하고 인스턴스를 배포합니다.

    # heat stack-create example -f /root/example.yaml -e /root/environment.yaml
    +--------------------------------------+------------+--------------------+----------------------+
    | id                                   | stack_name | stack_status       | creation_time        |
    +--------------------------------------+------------+--------------------+----------------------+
    | 6fca513c-25a1-4849-b7ab-909e37f52eca | example    | CREATE_IN_PROGRESS | 2015-08-31T16:18:02Z |
    +--------------------------------------+------------+--------------------+----------------------+
    Copy to Clipboard Toggle word wrap

    오케스트레이션에서는 scaleup_group 정의에 설정된 대로 스택을 생성하고 단일 cirros 인스턴스를 시작합니다. min_size:

    # nova list
    +--------------------------------------+-------------------------------------------------------+--------+------------+-------------+--------------------------------------+
    | ID                                   | Name                                                  | Status | Task State | Power State | Networks                             |
    +--------------------------------------+-------------------------------------------------------+--------+------------+-------------+--------------------------------------+
    | 3f627c84-06aa-4782-8c12-29409964cc73 | ex-qeki-3azno6me5gvm-pqmr5zd6kuhm-server-gieck7uoyrwc | ACTIVE | -          | Running     | private=10.10.1.156, 192.168.122.234 |
    +--------------------------------------+-------------------------------------------------------+--------+------------+-------------+--------------------------------------+
    Copy to Clipboard Toggle word wrap

    또한 오케스트레이션에서는 cpu_alarm_highcpu_alarm_low 에 정의된 대로 스케일링 또는 스케일 다운 이벤트를 트리거하는 데 사용되는 두 개의 cpu 알람을 생성합니다.

    # ceilometer alarm-list
    +--------------------------------------+-------------------------------------+-------------------+----------+---------+------------+--------------------------------+------------------+
    | Alarm ID                             | Name                                | State             | Severity | Enabled | Continuous | Alarm condition                | Time constraints |
    +--------------------------------------+-------------------------------------+-------------------+----------+---------+------------+--------------------------------+------------------+
    | 04b4f845-f5b6-4c5a-8af0-59e03c22e6fa | example-cpu_alarm_high-rd5kysmlahvx | ok                | low      | True    | True       | cpu_util > 50.0 during 1 x 60s | None             |
    | ac81cd81-20b3-45f9-bea4-e51f00499602 | example-cpu_alarm_low-6t65kswutupz  | ok                | low      | True    | True       | cpu_util < 10.0 during 1 x 60s | None             |
    +--------------------------------------+-------------------------------------+-------------------+----------+---------+------------+--------------------------------+------------------+
    Copy to Clipboard Toggle word wrap

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 &
Copy to Clipboard Toggle word wrap

dd 명령을 실행한 후 cirros 인스턴스에 100% CPU 사용률을 기대할 수 있습니다. 60초 후에 오케스트레이션에서 그룹을 두 개의 인스턴스로 자동 확장한 것을 확인할 수 있습니다.

# nova list
+--------------------------------------+-------------------------------------------------------+--------+------------+-------------+--------------------------------------+
| ID                                   | Name                                                  | Status | Task State | Power State | Networks                             |
+--------------------------------------+-------------------------------------------------------+--------+------------+-------------+--------------------------------------+
| 3f627c84-06aa-4782-8c12-29409964cc73 | ex-qeki-3azno6me5gvm-pqmr5zd6kuhm-server-gieck7uoyrwc | ACTIVE | -          | Running     | private=10.10.1.156, 192.168.122.234 |
| 0f69dfbe-4654-474f-9308-1b64de3f5c18 | ex-qeki-qmvor5rkptj7-krq7i66h6n7b-server-b4pk3dzjvbpi | ACTIVE | -          | Running     | private=10.10.1.157, 192.168.122.235 |
+--------------------------------------+-------------------------------------------------------+--------+------------+-------------+--------------------------------------+
Copy to Clipboard Toggle word wrap

60초 후에 오케스트레이션이 다시 세 개의 인스턴스로 자동 확장되었음을 확인합니다. 이 구성의 최대값이므로 scaleup_group 정의에 설정된 대로 max_size)를 확장하지 않습니다.

# nova list
+--------------------------------------+-------------------------------------------------------+--------+------------+-------------+--------------------------------------+
| ID                                   | Name                                                  | Status | Task State | Power State | Networks                             |
+--------------------------------------+-------------------------------------------------------+--------+------------+-------------+--------------------------------------+
| 3f627c84-06aa-4782-8c12-29409964cc73 | ex-qeki-3azno6me5gvm-pqmr5zd6kuhm-server-gieck7uoyrwc | ACTIVE | -          | Running     | private=10.10.1.156, 192.168.122.234 |
| 0e805e75-aa6f-4375-b057-2c173b68f172 | ex-qeki-gajdwmu2cgm2-vckf4g2gpwis-server-r3smbhtqij76 | ACTIVE | -          | Running     | private=10.10.1.158, 192.168.122.236 |
| 0f69dfbe-4654-474f-9308-1b64de3f5c18 | ex-qeki-qmvor5rkptj7-krq7i66h6n7b-server-b4pk3dzjvbpi | ACTIVE | -          | Running     | private=10.10.1.157, 192.168.122.235 |
+--------------------------------------+-------------------------------------------------------+--------+------------+-------------+--------------------------------------+
Copy to Clipboard Toggle word wrap

1.2.2. 인스턴스 자동 확장

오케스트레이션에서 cpu_alarm_low 임계값에 따라 인스턴스를 자동으로 축소합니다. 이 예에서는 CPU 사용률이 10% 미만이면 인스턴스가 축소됩니다. 실행 중인 dd 프로세스를 종료하고 오케스트레이션이 인스턴스를 다시 축소하기 시작하는 것을 관찰합니다.

dd 프로세스를 중지하면 cpu_alarm_low 이벤트가 트리거됩니다. 결과적으로 오케스트레이션은 자동으로 축소되고 인스턴스를 제거하기 시작합니다.

# ceilometer alarm-list
+--------------------------------------+-------------------------------------+-------+----------+---------+------------+--------------------------------+------------------+
| Alarm ID                             | Name                                | State | Severity | Enabled | Continuous | Alarm condition                | Time constraints |
+--------------------------------------+-------------------------------------+-------+----------+---------+------------+--------------------------------+------------------+
| 04b4f845-f5b6-4c5a-8af0-59e03c22e6fa | example-cpu_alarm_high-rd5kysmlahvx | ok    | low      | True    | True       | cpu_util > 50.0 during 1 x 60s | None             |
| ac81cd81-20b3-45f9-bea4-e51f00499602 | example-cpu_alarm_low-6t65kswutupz  | alarm | low      | True    | True       | cpu_util < 10.0 during 1 x 60s | None             |
+--------------------------------------+-------------------------------------+-------+----------+---------+------------+--------------------------------+------------------+
Copy to Clipboard Toggle word wrap

몇 분 후에 단일 인스턴스로 돌아가야 할 수 있습니다. scaleup_group 에서 허용되는 최소 인스턴스 수 :min_size: 1

1.3. 예: 자동 확장 애플리케이션

앞에서 설명한 기능을 사용하여 애플리케이션을 확장할 수도 있습니다. 예를 들어 한 번에 실행되는 여러 인스턴스 중 하나에서 제공하는 동적 웹 페이지입니다. 이 경우 인스턴스 간에 트래픽을 균등하게 분산하는 데 사용되는 Load Balancing-as-a-Service 를 제공하도록 neutron 을 구성할 수 있습니다.

다음 예에서 Orchestration은 Telemetry 데이터를 다시 검사하고 높은 CPU 사용량이 감지되면 인스턴스 수를 늘리거나 CPU 사용량이 설정된 값 아래에 반환되는 경우 인스턴스 수를 줄입니다.

  1. 로드 밸런서 환경의 속성을 설명하는 템플릿을 생성합니다. /etc/heat/templates/lb-env.yaml 에 다음 값을 입력합니다.

    heat_template_version: 2014-10-16
    description: A load-balancer server
    parameters:
      image:
        type: string
        description: Image used for servers
      key_name:
        type: string
        description: SSH key to connect to the servers
      flavor:
        type: string
        description: flavor used by the servers
      pool_id:
        type: string
        description: Pool to contact
      user_data:
        type: string
        description: Server user_data
      metadata:
        type: json
      network:
        type: string
        description: Network used by the server
    
    resources:
      server:
        type: OS::Nova::Server
        properties:
          flavor: {get_param: flavor}
          image: {get_param: image}
          key_name: {get_param: key_name}
          metadata: {get_param: metadata}
          user_data: {get_param: user_data}
          networks:
            - port: { get_resource: port }
    
      member:
        type: OS::Neutron::PoolMember
        properties:
          pool_id: {get_param: pool_id}
          address: {get_attr: [server, first_address]}
          protocol_port: 80
    
      port:
        type: OS::Neutron::Port
        properties:
          network: {get_param: network}
          security_groups:
            - base
    
    outputs:
      server_ip:
        description: IP Address of the load-balanced server.
        value: { get_attr: [server, first_address] }
      lb_member:
        description: LB member details.
        value: { get_attr: [member, show] }
    Copy to Clipboard Toggle word wrap
  2. 웹 애플리케이션을 실행할 인스턴스에 대한 다른 템플릿을 생성합니다. 다음 템플릿은 로드 밸런서를 생성하고 기존 네트워크를 사용합니다. 환경에 따라 매개변수를 바꾸고 템플릿을 /root/lb-webserver-rhel7.yaml 과 같은 파일에 저장하십시오.

    heat_template_version: 2014-10-16
    description: AutoScaling RHEL 7 Web Application
    parameters:
      image:
        type: string
        description: Image used for servers
        default: RHEL 7
      key_name:
        type: string
        description: SSH key to connect to the servers
        default: admin
      flavor:
        type: string
        description: flavor used by the web servers
        default: m2.tiny
      network:
        type: string
        description: Network used by the server
        default: private
      subnet_id:
        type: string
        description: subnet on which the load balancer will be located
        default: 9daa6b7d-e647-482a-b387-dd5f855b88ef
      external_network_id:
        type: string
        description: UUID of a Neutron external network
        default: db17c885-77fa-45e8-8647-dbb132517960
    
    resources:
      webserver:
        type: OS::Heat::AutoScalingGroup
        properties:
          min_size: 1
          max_size: 3
          cooldown: 60
          desired_capacity: 1
          resource:
            type: file:///etc/heat/templates/lb-env.yaml
            properties:
              flavor: {get_param: flavor}
              image: {get_param: image}
              key_name: {get_param: key_name}
              network: {get_param: network}
              pool_id: {get_resource: pool}
              metadata: {"metering.stack": {get_param: "OS::stack_id"}}
              user_data:
                str_replace:
                  template: |
                    #!/bin/bash -v
    
                    yum -y install httpd php
                    systemctl enable httpd
                    systemctl start httpd
                    cat <<EOF > /var/www/html/hostname.php
                    <?php echo "Hello, My name is " . php_uname('n'); ?>
                    EOF
                  params:
                    hostip: 192.168.122.70
                    fqdn: sat6.example.com
                    shortname: sat6
    
      web_server_scaleup_policy:
        type: OS::Heat::ScalingPolicy
        properties:
          adjustment_type: change_in_capacity
          auto_scaling_group_id: {get_resource: webserver}
          cooldown: 60
          scaling_adjustment: 1
    
      web_server_scaledown_policy:
        type: OS::Heat::ScalingPolicy
        properties:
          adjustment_type: change_in_capacity
          auto_scaling_group_id: {get_resource: webserver}
          cooldown: 60
          scaling_adjustment: -1
    
      cpu_alarm_high:
        type: OS::Ceilometer::Alarm
        properties:
          description: Scale-up if the average CPU > 95% for 1 minute
          meter_name: cpu_util
          statistic: avg
          period: 60
          evaluation_periods: 1
          threshold: 95
          alarm_actions:
            - {get_attr: [web_server_scaleup_policy, alarm_url]}
          matching_metadata: {'metadata.user_metadata.stack': {get_param: "OS::stack_id"}}
          comparison_operator: gt
    
      cpu_alarm_low:
        type: OS::Ceilometer::Alarm
        properties:
          description: Scale-down if the average CPU < 15% for 1 minute
          meter_name: cpu_util
          statistic: avg
          period: 60
          evaluation_periods: 1
          threshold: 15
          alarm_actions:
            - {get_attr: [web_server_scaledown_policy, alarm_url]}
          matching_metadata: {'metadata.user_metadata.stack': {get_param: "OS::stack_id"}}
          comparison_operator: lt
    
      monitor:
        type: OS::Neutron::HealthMonitor
        properties:
          type: TCP
          delay: 5
          max_retries: 5
          timeout: 5
    
      pool:
        type: OS::Neutron::Pool
        properties:
          protocol: HTTP
          monitors: [{get_resource: monitor}]
          subnet_id: {get_param: subnet_id}
          lb_method: ROUND_ROBIN
          vip:
            protocol_port: 80
    
      lb:
        type: OS::Neutron::LoadBalancer
        properties:
          protocol_port: 80
          pool_id: {get_resource: pool}
    
      lb_floating:
        type: OS::Neutron::FloatingIP
        properties:
          floating_network_id: {get_param: external_network_id}
          port_id: {get_attr: [pool, vip, port_id]}
    
    outputs:
      scale_up_url:
        description: >
          This URL is the webhook to scale up the autoscaling group.  You
          can invoke the scale-up operation by doing an HTTP POST to this
          URL; no body nor extra headers are needed.
        value: {get_attr: [web_server_scaleup_policy, alarm_url]}
      scale_dn_url:
        description: >
          This URL is the webhook to scale down the autoscaling group.
          You can invoke the scale-down operation by doing an HTTP POST to
          this URL; no body nor extra headers are needed.
        value: {get_attr: [web_server_scaledown_policy, alarm_url]}
      pool_ip_address:
        value: {get_attr: [pool, vip, address]}
        description: The IP address of the load balancing pool
      website_url:
        value:
          str_replace:
            template: http://serviceip/hostname.php
            params:
              serviceip: { get_attr: [lb_floating, floating_ip_address] }
        description: >
          This URL is the "external" URL that can be used to access the
          website.
      ceilometer_query:
        value:
          str_replace:
            template: >
              ceilometer statistics -m cpu_util
              -q metadata.user_metadata.stack=stackval -p 60 -a avg
            params:
              stackval: { get_param: "OS::stack_id" }
        description: >
          This is a Ceilometer query for statistics on the cpu_util meter
          Samples about OS::Nova::Server instances in this stack.  The -q
          parameter selects Samples according to the subject's metadata.
          When a VM's metadata includes an item of the form metering.X=Y,
          the corresponding Ceilometer resource has a metadata item of the
          form user_metadata.X=Y and samples about resources so tagged can
          be queried with a Ceilometer query term of the form
          metadata.user_metadata.X=Y.  In this case the nested stacks give
          their VMs metadata that is passed as a nested stack parameter,
          and this stack passes a metadata of the form metering.stack=Y,
          where Y is this stack's ID.
    Copy to Clipboard Toggle word wrap
  3. Telemetry 컬렉션 간격을 업데이트합니다. 기본적으로 Telemetry는 CPU 데이터에 대해 10분마다 인스턴스를 폴링합니다. 이 예에서는 /etc/ceilometer/pipeline.yaml 에서 간격을 60초로 변경합니다.

    - name: cpu_source
    interval: 60
    meters:
    - "cpu"
    sinks:
    - cpu_sink
    Copy to Clipboard Toggle word wrap
    참고

    더 높은 폴링 간격으로 인해 컨트롤 플레인에 로드가 증가할 수 있으므로 프로덕션 환경에서는 폴링 간격이 60초인 폴링 기간을 권장하지 않습니다.

  4. 모든 OpenStack 서비스를 다시 시작하여 업데이트된 Telemetry 설정을 적용합니다.

    # openstack-service restart
    Copy to Clipboard Toggle word wrap
    참고

    이 단계에서는 OpenStack 배포에 대한 간단한 중단이 발생합니다.

  5. 오케스트레이션 스크립트를 실행합니다. 그러면 환경이 빌드되고 템플릿을 사용하여 인스턴스를 배포합니다.

    # heat stack-create webfarm -f /root/lb-webserver-rhel7.yaml
    Copy to Clipboard Toggle word wrap

    /root/lb-webserver-rhel7.yaml 을 실제 경로 및 파일 이름으로 바꿉니다.

오케스트레이션 → 스택 → Webfarm 의 대시보드에서 스택 생성을 모니터링할 수 있습니다. 스택이 생성되면 다음과 같이 여러 유용한 정보를 제공합니다.

  • 수동 확장 또는 축소 이벤트를 트리거하는 데 사용할 수 있는 URL입니다.
  • 웹 사이트의 IP 주소인 유동 IP 주소입니다.
  • 전체 스택에 대한 CPU 로드를 표시하는 Telemetry 명령과 스케일링이 예상대로 작동하는지 확인하는 데 사용할 수 있습니다.

대시보드의 페이지 모양은 다음과 같습니다.

heat stack output

로드 밸런서를 보려면 네트워크 → 로드 밸런서를 엽니다.

load balancer

멤버 를 클릭합니다. 이 페이지에는 부하 분산 풀의 멤버가 표시됩니다. 이는 웹 사이트 트래픽을 배포할 수 있는 인스턴스입니다. 해당 인스턴스가 생성되고 Apache를 설치 및 구성할 때까지 멤버는 Active 상태가 아닙니다.

웹 서버가 시작되면 인스턴스가 로드 밸런서의 활성 멤버로 표시됩니다.

load balancer member active

이제 http://IP/hostname.php 에서 웹 애플리케이션에 액세스할 수 있습니다. 다음과 유사한 출력이 표시될 수 있습니다.

Hello, My name is we-zrwm-t4ezkpx34gxu-qbg5d7dqbc4j-server-mzdvigk2jugl
Copy to Clipboard Toggle word wrap

이제 대시보드의 스택 개요에서 Telemetry 명령을 실행하여 스택의 CPU 성능 데이터를 볼 수 있습니다. 명령은 다음과 같습니다.

# ceilometer statistics -m cpu_util -q metadata.user_metadata.stack=8f86c3d5-15cf-4a64-b9e8-70215498c046 -p 60 -a avg
Copy to Clipboard Toggle word wrap

1.3.1. 자동 확장 애플리케이션 테스트

애플리케이션 스케일링을 수동으로 트리거하려면 대시보드의 스택 개요에서 REST 확장 URL 을 사용하거나 처음 배포된 인스턴스에서 리소스를 많이 사용하는 명령을 실행하여 부하를 생성합니다.

  • REST API를 사용하려면 REST easily Firefox add on 또는 curl 과 같은 HTTP POST 요청을 수행할 수 있는 툴이 필요합니다. 스케일업 URL 을 복사하여 REST easy 양식에 붙여넣습니다.

    scale up

    또는 curl 명령줄에서 매개 변수로 사용합니다.

    $ curl -X POST "scale-up URL"
    Copy to Clipboard Toggle word wrap
  • 인위적으로 로드를 생성하려면 인스턴스에 유동 IP를 할당하고 SSH로 로그인하여 CPU를 계속 사용하는 명령을 실행합니다. 예를 들면 다음과 같습니다.

    $ dd if=/dev/zero of=/dev/null &
    Copy to Clipboard Toggle word wrap
    중요

    예를 들어 top 명령을 사용하여 CPU 사용량이 95%를 초과하는지 확인합니다. CPU 사용량이 충분히 높지 않은 경우 dd 명령을 병렬로 여러 번 실행하거나 다른 방법을 사용하여 CPU를 사용량 상태로 유지합니다.

다음에 Telemetry가 스택에서 CPU 데이터를 수집하면 스케일업 이벤트가 트리거되고 오케스트레이션 → 스택 → Webfarm → Events 에 표시됩니다. 새 웹 서버 인스턴스가 생성되어 로드 밸런서에 추가됩니다. 이 작업이 완료되면 인스턴스가 활성화되고 웹 사이트 URL이 로드 밸런서를 통해 스택의 두 인스턴스로 라우팅됩니다.

참고

인스턴스를 초기화하고, Apache를 설치 및 구성하고, 애플리케이션이 배포되므로 생성에 몇 분이 걸릴 수 있습니다. HAProxy에서 모니터링하므로 인스턴스에서 활성 상태로 표시되기 전에 웹 사이트를 사용할 수 있는지 확인합니다.

새 인스턴스가 생성되는 동안 로드 밸런싱 풀의 멤버 목록은 대시보드에서 다음과 같이 표시됩니다.

scale up load balancer

중요

추가 인스턴스가 생성될지 여부를 결정할 때 heat 스택의 평균 CPU 사용량이 고려됩니다. 두 번째 인스턴스에는 대부분 일반 CPU 사용량이 있으므로 첫 번째 인스턴스의 균형을 조정합니다. 그러나 두 번째 인스턴스도 사용량이 되고 첫 번째 및 두 번째 인스턴스의 평균 CPU 사용량이 95%를 초과하면 다른 인스턴스(세 번째) 인스턴스가 생성됩니다.

1.3.2. 애플리케이션 자동 확장

이는 스택의 평균 CPU 사용량이 사전 정의된 값 아래로 드롭될 때 스케일 다운 정책이 트리거된다는 점에서 1.2.2절. “인스턴스 자동 확장” 와 유사합니다. 이는 1.3.1절. “자동 확장 애플리케이션 테스트” 에 설명된 예제의 15%입니다. 또한 이러한 방식으로 스택에서 인스턴스를 제거하면 로드 밸런서에서 자동으로 제거됩니다. 그런 다음 웹 사이트 트래픽은 나머지 인스턴스에 자동으로 배포됩니다.

법적 공지

Copyright © 2015 Red Hat, Inc.
이 문서의 텍스트와 그림은 Creative Commons Attribution-Share Alike 3.0 Unported 라이센스("CC-BY-SA")에 따라 Red Hat에서 라이센스를 부여합니다. CC-BY-SA에 대한 설명은 http://creativecommons.org/licenses/by-sa/3.0/ 에서 확인할 수 있습니다. CC-BY-SA에 따라 이 문서 또는 문서의 수정본을 배포할 경우 원본의 URL을 제공해야 합니다.
Red Hat은 이 문서의 라이센스 제공자로서 관련 법률이 허용하는 한도 내에서 CC-BY-SA의 섹션 4d를 시행할 권리를 포기하며 이를 주장하지 않을 것에 동의합니다.
OpenStack 구성 참조에서 채택된 부분. 자세한 내용은 Red Hat OpenStack Platform 라이센스의 "구성 참조"를 참조하십시오.
Red Hat, Red Hat Enterprise Linux, Shadowman 로고, JBoss, MetaMatrix, Fedora, Infinity 로고 및 RHCE는 미국 및 기타 국가에 등록된 Red Hat, Inc.의 상표입니다.
Linux® 는 미국 및 기타 국가에서 Linus Torvalds의 등록 상표입니다.
Java® 는 Oracle 및/또는 그 계열사의 등록 상표입니다.
XFS® 는 미국 및/또는 기타 국가에 있는 Silicon Graphics International Corp. 또는 그 자회사의 상표입니다.
MySQL® 은 미국, 유럽 연합 및 기타 국가에 있는 MySQL AB의 등록 상표입니다.
Node.js® 는 Joyent의 공식 상표입니다. Red Hat Software Collections는 공식 Joyent Node.js 오픈 소스 또는 상용 프로젝트의 보증 대상이 아니며 공식적인 관계도 없습니다.
OpenStack® Word 마크 및 OpenStack 로고는 미국 및 기타 국가에서 OpenStack Foundation의 등록 상표/서비스 마크 또는 상표/서비스 마크이며 OpenStack Foundation의 권한과 함께 사용됩니다. 당사는 OpenStack Foundation 또는 OpenStack 커뮤니티와 제휴 관계가 아니며 보증 또는 후원을 받지 않습니다.
기타 모든 상표는 각각 해당 소유자의 자산입니다.
맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2025 Red Hat