Compute の自動スケーリング
Red Hat OpenStack Platform での自動スケーリングの設定
概要
第1章 Compute の自動スケーリングの設定
本ガイドでは、高いシステムの使用状況に応じてコンピュートインスタンスを自動的にスケールアウトする方法について説明します。CPU やメモリー使用量などの要素を考慮する事前定義のルールを使用することで、必要に応じて追加のインスタンスを自動的に追加/削除するように Orchestration (heat)を設定できます。
1.1. アーキテクチャーの概要
1.1.1. Orchestration
自動スケーリングの背後にあるコアコンポーネントは Orchestration (heat)です。Orchestration を使用すると、人間が判読できる YAML テンプレートを使用してルールを定義できます。これらのルールは、追加のインスタンスを追加することを決定する前に Telemetry データを評価することができます。その後、アクティビティーがサブサイドになると、Orchestration は不要なインスタンスを自動的に削除できます。
1.1.2. テレメトリー
Telemetry は OpenStack 環境のパフォーマンス監視を行い、インスタンスおよび物理ホストの CPU、ストレージ、およびメモリー使用率に関するデータを収集します。オーケストレーションテンプレートは、事前に定義されたアクションを実行するかどうかを決定する際に Telemetry データを検証します。
1.1.3. 主要な用語
- スタック: スタックは、アプリケーションの操作に必要なすべてのリソースで設定されます。1 つのインスタンスとそのリソースではシンプルで、複数階層アプリケーションを設定する複数のインスタンスとすべてのリソースの依存関係の場合は複雑になります。
テンプレート: Heat が実行する一連のタスクを定義する YAML スクリプト。たとえば、特定の機能に個別のテンプレートを使用することが推奨されます。
- スタックテンプレート: Telemetry が応答するしきい値を定義し、自動スケーリンググループを定義します。
- 環境テンプレート - 環境のビルド情報(使用するフレーバーおよびイメージ、仮想ネットワークの設定方法、インストールするソフトウェア)を定義します。
1.2. 例:CPU 使用率に基づく自動スケーリング
この例では、オーケストレーションは Telemetry データを検査し、CPU の高い使用率に対応してインスタンスの数を自動的に増やします。必要なルールとその後の設定を定義するために、スタックテンプレートと環境テンプレートが作成されます。この例では、既存のリソース(ネットワークなど)を使用し、独自の環境で異なる可能性の高い名前を使用します。
インスタンスのフレーバー、ネットワーク設定、およびイメージ種別を記述する環境テンプレートを作成します。
/etc/heat/templates/cirros.yaml
に以下の値を入力します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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
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
/root/environment.yaml
に Orchestration リソースを登録します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow resource_registry: "OS::Nova::Server::Cirros": "file:///etc/heat/templates/cirros.yaml"
resource_registry: "OS::Nova::Server::Cirros": "file:///etc/heat/templates/cirros.yaml"
スタックテンプレートを作成し、監視する CPU しきい値と追加するインスタンスの数を記述します。インスタンスグループも作成し、このテンプレートに参加できるインスタンスの最小数および最大数を定義します。
/root/example.yaml
に以下の値を入力します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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
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
Telemetry コレクションの間隔を更新します。デフォルトでは、Telemetry は CPU データに対して 10 分ごとにインスタンスをポーリングします。この例では、
/etc/ceilometer/pipeline.yaml
で間隔を 60 秒に変更します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - name: cpu_source interval: 60 meters: - "cpu" sinks: - cpu_sink
- name: cpu_source interval: 60 meters: - "cpu" sinks: - cpu_sink
注記実稼働環境では、ポーリング期間が 60 秒ほど推奨しません。ポーリング間隔が長くなると、コントロールプレーンの負荷が増加する可能性があるためです。
すべての OpenStack サービスを再起動して、更新された Telemetry 設定を適用します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow openstack-service restart
# openstack-service restart
注記このステップにより、OpenStack デプロイメントの停止が短くなります。
オーケストレーションスクリプトを実行して、環境を構築し、インスタンスをデプロイします。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow heat stack-create example -f /root/example.yaml -e /root/environment.yaml
# 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 | +--------------------------------------+------------+--------------------+----------------------+
Orchestration は、
scaleup_group
定義(min_size
)に設定されるように、スタックを作成し、単一の cirros インスタンスを起動します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow nova list
# 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 | +--------------------------------------+-------------------------------------------------------+--------+------------+-------------+--------------------------------------+
オーケストレーションは、
cpu_alarm_high
およびcpu_alarm_low
で定義されているように、スケールアップまたはスケールダウンイベントをトリガーするために使用される 2 つの CPU アラームも作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ceilometer alarm-list
# 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 | +--------------------------------------+-------------------------------------+-------------------+----------+---------+------------+--------------------------------+------------------+
1.2.1. 自動スケーリングインスタンスのテスト
オーケストレーションは、cpu_alarm_high
しきい値に基づいてインスタンスを自動的にスケーリングします。CPU 使用率が 50% を超えると、cpu_alarm_high
定義に設定されるように 50% インスタンスがスケールアップされます: threshold: 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 秒後、Orchestration がグループを 2 つのインスタンスに自動スケーリングしたことがわかります。
nova list
# 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 |
+--------------------------------------+-------------------------------------------------------+--------+------------+-------------+--------------------------------------+
60 秒を超えると、Orchestration が 3 つのインスタンスに再度自動的にスケーリングされたことを確認します。この設定の最大値は 3 つであるため、( scaleup_group
定義で設定された)スケーリングは max_size
しません。
nova list
# 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 |
+--------------------------------------+-------------------------------------------------------+--------+------------+-------------+--------------------------------------+
1.2.2. インスタンスの自動スケールダウン
オーケストレーションは、cpu_alarm_low
しきい値に基づいてインスタンスを自動的にスケールダウンします。この例では、CPU 使用率が 10% を下回ると、インスタンスはスケールダウンされます。実行中の dd
プロセスを終了し、オーケストレーションがインスタンスのスケールダウンを開始することを確認します。
dd
プロセスを停止すると、cpu_alarm_low event
がトリガーされます。その結果、オーケストレーションは自動的にスケールダウンを開始し、インスタンスを削除します。
ceilometer alarm-list
# 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 |
+--------------------------------------+-------------------------------------+-------+----------+---------+------------+--------------------------------+------------------+
数分後、scaleup_group
で許容される最小インスタンス数:min_size: 1
1.3. 例:アプリケーションの自動スケーリング
前述の機能も、アプリケーションのスケールアップにも使用できます。たとえば、一度に実行される複数のインスタンスの 1 つによって提供される動的な Web ページなどです。この場合、neutron は Load Balancing-as-a-Service を提供するように設定できます。これは、インスタンス間でトラフィックを均等に分散するのに均等に機能します。
以下の例では、Orchestration は Telemetry データを再度検査し、CPU 使用率が高いとインスタンスの数を増やすか、CPU 使用率がセット値を下回った場合にはインスタンスの数を減らします。
ロードバランサー 環境のプロパティーを記述するテンプレートを作成します。
/etc/heat/templates/lb-env.yaml
に以下の値を入力します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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] }
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] }
Web アプリケーションを実行するインスタンス用に別のテンプレートを作成します。以下のテンプレートはロードバランサーを作成し、既存のネットワークを使用します。お使いの環境に応じてパラメーターを置き換え、テンプレートを
/root/lb-webserver-rhel7.yaml
などのファイルに保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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.
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.
Telemetry コレクションの間隔を更新します。デフォルトでは、Telemetry は CPU データに対して 10 分ごとにインスタンスをポーリングします。この例では、
/etc/ceilometer/pipeline.yaml
で間隔を 60 秒に変更します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - name: cpu_source interval: 60 meters: - "cpu" sinks: - cpu_sink
- name: cpu_source interval: 60 meters: - "cpu" sinks: - cpu_sink
注記実稼働環境では、ポーリング期間が 60 秒ほど推奨しません。ポーリング間隔が長くなると、コントロールプレーンの負荷が増加する可能性があるためです。
すべての OpenStack サービスを再起動して、更新された Telemetry 設定を適用します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow openstack-service restart
# openstack-service restart
注記このステップにより、OpenStack デプロイメントの停止が短くなります。
オーケストレーションスクリプトを実行します。これにより、環境がビルドされ、テンプレートを使用してインスタンスをデプロイします。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow heat stack-create webfarm -f /root/lb-webserver-rhel7.yaml
# heat stack-create webfarm -f /root/lb-webserver-rhel7.yaml
/root/lb-webserver-rhel7.yaml
を実際のパスおよびファイル名に置き換えます。
Orchestration → Stacks → Webfarm で、Dashboard でスタックの作成をモニターできます。スタックが作成されると、以下のような、有用な情報が複数表示されます。
- 手動スケールアップまたはスケールダウンイベントをトリガーするために使用できる URL。
- Web サイトの IP アドレスである Floating IP アドレス。
- スタックの CPU 負荷を表示する Telemetry コマンド。スケーリングが予想通りに機能しているかどうかを確認することができます。
ダッシュボードでページは次のようになります。
Network → Load Balancers を開いて、ロードバランサーを表示します。
Members をクリックします。このページには、負荷分散プールのメンバーが表示されます。これらは、Web サイトのトラフィックを分散できるインスタンスです。対応するインスタンスが作成され、Apache がインストールおよび設定されるまで、メンバーは Active ステータスにならないことに注意してください。
Web サーバーを起動すると、インスタンスはロードバランサーのアクティブなメンバーとして表示されます。
これで、http:
//IP
/hostname.php
で Web アプリケーションにアクセスできるようになりました。以下のような出力が表示されるはずです。
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. 自動スケーリングアプリケーションのテスト
アプリケーションのスケーリングを手動でトリガーするには、Dashboard のスタック概要から REST スケールアップ URL を使用するか、最初にデプロイされたインスタンスでリソース集約型コマンドを実行して負荷を生成します。
REST API を使用するには、
HTTP POST
リクエストを実行できるツールが必要です。たとえば、REST Easy Firefox add on やcurl
などです。スケールアップ URL をコピーし、REST Easy の形式で貼り付けます。または、
curl
コマンドラインでパラメーターとして使用します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow curl -X POST "scale-up URL"
$ curl -X POST "scale-up URL"
負荷を人為的に生成するには、インスタンスに Floating IP を確保し、SSH でログインし、CPU がビジー状態になるコマンドを実行します。以下に例を示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow dd if=/dev/zero of=/dev/null &
$ dd if=/dev/zero of=/dev/null &
重要たとえば
top
コマンドを使用して、CPU 使用率が 95% を超えるかどうかを確認します。CPU 使用率が十分に高くない場合は、dd
コマンドを並行して実行するか、別の方法を使用して CPU をビジー状態に維持します。
次回 Telemetry がスタックから CPU データを収集すると、スケールアップイベントがトリガーされ、Orchestration → Stacks → Webfarm → Events に表示されます。新しい Web サーバーインスタンスが作成され、ロードバランサーに追加されます。これが完了すると、インスタンスはアクティブになり、Web サイト URL がロードバランサー経由でスタックの両方のインスタンスにルーティングされることがわかります。
インスタンスの起動には数分かかることがあります。なぜなら、インスタンスの初期化、Apache のインストールと設定、およびアプリケーションをデプロイする必要があるためです。これは HAProxy によってモニターされます。これにより、Web サイトがアクティブとしてマークされる前にインスタンスで利用可能になります。
新規インスタンスの作成中の Dashboard で、負荷分散プールのメンバーのリストは次のようになります。
追加のインスタンスを作成するかどうかを決定する際には、heat スタックのインスタンスの平均 CPU 使用率が考慮されます。2 番目のインスタンスは通常の CPU 使用率を持つ可能性が最も高いため、最初のインスタンスのバランスを取り除きます。ただし、2 番目のインスタンスもビジーになり、最初のインスタンスと 2 番目のインスタンスの平均 CPU 使用率が 95% を超えると、別のインスタンス(3 番目の)インスタンスが作成されます。
1.3.2. アプリケーションの自動スケーリング
これは、スタックの CPU 使用率が事前定義の値を下回ると、スケールダウンポリシーが実行される点で 「自動スケーリングアプリケーションのテスト」 と似ています。これは、「自動スケーリングアプリケーションのテスト」 で説明されている例の 15% です。さらに、インスタンスがスタックから削除されると、ロードバランサーからも自動的に削除されます。Web サイトのトラフィックは、残りのインスタンスに自動的に分散されます。