第1章 Compute のオートスケールの設定
本ガイドは、システム使用率が過度に高くなった場合に Compute インスタンスを自動的にスケールアウトする方法について説明します。CPU やメモリーの使用率を考慮した事前定義済みのルールを使用することにより、Orchestration (heat) が必要に応じて自動的にインスタンスの追加/削除をするように設定することが可能です。
1.1. アーキテクチャーの概要 リンクのコピーリンクがクリップボードにコピーされました!
1.1.1. Orchestration リンクのコピーリンクがクリップボードにコピーされました!
オートスケール機能を提供するコアコンポーネントは Orchestration (heat) です。Orchestration では、人間が判読できる YAML テンプレートを使用してルールを定義することができます。これらのルールは、Telemetry のデータに基づいてシステムの負荷を評価し、スタックにインスタンスを追加する必要があるかどうかを確認するのに適用されます。負荷が低減した後には、Orchestration は使用されていないインスタンスを自動的に削除することができます。
1.1.2. Telemetry リンクのコピーリンクがクリップボードにコピーされました!
Telemetry は、インスタンスおよび物理ホストの CPU、ストレージ、メモリーの使用率に関するデータを収集して、OpenStack 環境のパフォーマンスを監視します。Orchestration テンプレートは、Telemetry データを検証して、事前定義されたアクションを開始するかどうかを評価します。
1.1.3. 主要な用語 リンクのコピーリンクがクリップボードにコピーされました!
- スタック: スタックとは、1 つのアプリケーションを稼働させるのに必要な全リソースを意味します。1 つのインスタンスとそのリソースから成る単純なスタックもあれば、複数階層のアプリケーションを構成するリソースの依存関係を伴う複数のインスタンスから成る複雑なスタックもあります。
テンプレート: Heat が実行する一式のタスクを定義する YAML スクリプト。たとえば、機能別に異なるテンプレートを使用するのが望ましいです。
- テンプレートファイル: このファイルには、Telemetry が対応する必要のある閾値やオートスケールグループを定義します。
- 環境ファイル: 使用するフレーバーやイメージ、仮想ネットワークの設定方法、インストールするソフトウェアなどの環境のビルド情報を定義します。
1.2. 例: CPU 使用率に基づいたオートスケール リンクのコピーリンクがクリップボードにコピーされました!
以下の例では、Orchestration が Telemetry データを検証し、CPU 使用率の増加に対応して、インスタンスの数を自動的に増やします。必要なルールとその後の設定を定義するためにスタックテンプレートと環境テンプレートが作成されます。この例では、既存のリソース (ネットワークなど) を使用しており、実際にお使いの環境のリソース名とは異なる可能性があります。
インスタンスのフレーバー、ネットワーク設定、イメージ種別を記述した環境テンプレートを作成して、
/home/<user>/stacks/example1/cirros.yamlのテンプレートファイルに保存します。<user>の変数は実際のユーザー名に置き換えてください。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ~/stacks/example1/environment.yamlに Orchestration のリソースを登録します。resource_registry: "OS::Nova::Server::Cirros": ~/stacks/example1/cirros.yamlresource_registry: "OS::Nova::Server::Cirros": ~/stacks/example1/cirros.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 監視する CPU の閾値と追加すべきインスタンス数を記述するスタックテンプレートを作成します。また、インスタンスグループも作成して、このテンプレートに参加することが可能なインスタンス数の最小値および最大値を定義します。
注記granularityパラメーターは、gnocchicpu_utilメトリックの粒度に応じて設定する必要があります。詳しくは、ソリューションの記事 を参照してください。~/stacks/example1/template.yamlに以下の値を保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下の OpenStack コマンドを実行して環境を構築し、インスタンスをデプロイします。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Orchestration は、スタックを作成して、
scaleup_group定義のmin_sizeパラメーターで指定されている最小数の cirros インスタンスを起動します。インスタンスが正常に作成されたことを確認します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow Orchestration は、
cpu_alarm_highおよびcpu_alarm_lowの定義に従って、スケールアップまたはスケールダウンのイベントをトリガーするのに使用する 2 つの CPU アラームも作成します。トリガーが存在することを確認します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
1.2.1. インスタンスの自動スケーリングアップのテスト リンクのコピーリンクがクリップボードにコピーされました!
Orchestration は、cpu_alarm_high 閾値の定義に基づいて、インスタンスを自動的にスケーリングすることができます。CPU の使用率が threshold パラメーターで定義されている値に達すると、負荷のバランスを取るために別のインスタンスが起動します。上記の template.yaml ファイルでは、threshold 値は 80% に設定されています。
インスタンスにログインして
ddコマンドを数回実行し、負荷を生成します。ssh -i ~/mykey.pem cirros@192.168.122.8 sudo dd if=/dev/zero of=/dev/null & sudo dd if=/dev/zero of=/dev/null & sudo dd if=/dev/zero of=/dev/null &
$ ssh -i ~/mykey.pem cirros@192.168.122.8 $ sudo dd if=/dev/zero of=/dev/null & $ sudo dd if=/dev/zero of=/dev/null & $ sudo dd if=/dev/zero of=/dev/null &Copy to Clipboard Copied! Toggle word wrap Toggle overflow ddコマンドを実行すると、cirros インスタンスの CPU 使用率が 100% となることが予想できます。アラームがトリガーされていることを確認します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow しばらく経つと (約 60 秒)、Orchestration は別のインスタンスを起動して、グループに追加します。これは、
nova listコマンドで確認することができます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow さらに短時間が経過すると、Orchestration がインスタンスを再度オートスケールして 3 つになったことを確認することができます。設定では最大 3 つに指定されているので、その値を上回る数にはスケーリングされません (
scaleup_group定義のmax_sizeパラメーター)。この場合も、上記のコマンドで確認することができます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
1.2.2. インスタンスの自動スケールダウン リンクのコピーリンクがクリップボードにコピーされました!
Orchestration は、cpu_alarm_low の閾値に基づいて、インスタンスを自動的にスケールダウンすることも可能です。以下の例では、CPU の使用率が 5% を下回ると、インスタンスがスケールダウンされます。
実行中の
ddプロセスを終了すると、Orchestration がインスタンスのスケールダウンを開始するのを確認することができます。killall dd
$ killall ddCopy to Clipboard Copied! Toggle word wrap Toggle overflow ddプロセスを停止すると、cpu_alarm_low eventがトリガーされます。その結果、Orchestration が自動的にスケールダウンを開始して、インスタンスを削除します。対応するアラームがトリガーされていることを確認します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 数分後には、Orchestration はインスタンス数が
scaleup_group定義のmin_sizeパラメーターで指定されている最小値になるまでスケールダウンを続けます。min_sizeパラメーターは1に設定されています。
1.2.3. セットアップのトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
環境が適切に機能していない場合には、ログファイルと履歴の記録でエラーを確認することができます。
状態の遷移を確認するには、スタックのイベント記録を一覧表示することができます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow アラームの履歴ログを確認するには以下のコマンドを実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 既存のスタックを対象に Heat が収集するスケールアウトおよびスケールダウンの操作の記録を確認するには、
awkを使用してheat-engine.logを解析することができます。awk '/Stack UPDATE started/,/Stack CREATE completed successfully/ {print $0}' /var/log/heat/heat-engine.log$ awk '/Stack UPDATE started/,/Stack CREATE completed successfully/ {print $0}' /var/log/heat/heat-engine.logCopy to Clipboard Copied! Toggle word wrap Toggle overflow aodhに関連した情報を確認するは、evaluator.logを検証します。grep -i alarm /var/log/aodh/evaluator.log | grep -i transition
$ grep -i alarm /var/log/aodh/evaluator.log | grep -i transitionCopy to Clipboard Copied! Toggle word wrap Toggle overflow
1.3. 例: アプリケーションのオートスケール リンクのコピーリンクがクリップボードにコピーされました!
前述した機能をアプリケーションのスケールアップにも使用することができます。たとえば、同時に実行されている複数のインスタンスの 1 つでサービスを提供する動的な Web ページなどがあります。このような場合には、neutron で Load Balancing-as-a-Service を提供するように設定して、インスタンス間でトラフィックが均等に分散されるようにすることができます。
以下の例では、Orchestration が再び Telemetry データを検証して、高い CPU 使用率が検出されるとインスタンス数を増やし、指定した値よりも低い値の CPU 使用率が返されるとインスタンス数を減らします。
load-balancer 環境のプロパティーを記述したテンプレートを作成します。
~/stacks/example2/lb-env.yamlに以下の値を入力します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow Web アプリケーションを実行するインスタンス用に別のテンプレートを作成します。以下のテンプレートは、ロードバランサーを作成して、既存のネットワークを使用します。パラメーターは環境に応じて必ず変更し、
~/stacks/example2/lb-webserver-rhel7.yamlのようなファイルにテンプレートを保存してください。Copy to Clipboard Copied! Toggle word wrap Toggle overflow Telemetry のデータ収集の間隔を更新します。デフォルトでは、Telemetry はインスタンスを 10 分ごとにポーリングして、CPU のデータを取得します。以下の例では、
/etc/ceilometer/pipeline.yamlで、この間隔を 60 秒に変更します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記ポーリングの頻度を高くすると、コントロールプレーンに対する負荷が高くなるため、実稼働環境では、60 秒に設定することは、お勧めできません。
OpenStack ceilometer の全サービスを再起動して、更新された Telemetry の設定を適用します。
systemctl restart openstack-ceilometer*
# systemctl restart openstack-ceilometer*Copy to Clipboard Copied! Toggle word wrap Toggle overflow Orchestration のスクリプトを実行します。このスクリプトにより、環境が構築され、テンプレートを使用してインスタンスがデプロイされます。
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の箇所は、実際のパスとファイル名に変更してください。
Dashboard の オーケストレーション
- 手動のスケールアップまたはスケールダウンイベントをトリガーするのに使用することができる URL
- Floating IP アドレス。Web サイトの IP アドレスです。
- スタック全体の CPU 負荷を表示するための Telemetry コマンド。スケーリングが想定通りに機能しているかどうかを確認するのに使用することができます。
Dashboard のページは以下のように表示されます。
ネットワーク
メンバー をクリックします。このページには、ロードバランシングプールのメンバーが表示されます。これらのインスタンスに対して、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 コマンドを実行して、Dashboard のスタックの概要ページに 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 scale-up URL を使用するか、始めにデプロイしたインスタンス上で resource-intensive コマンドを実行して負荷を生成します。
REST API を使用するには、REST Easy という Firefox アドオン や
curlなど、HTTP POST要求を実行できるツールが必要です。REST Easy を使用する場合には、scale-up URL をコピーしてフォームにペーストします。
curlを使用する場合には、コマンドラインで URL をパラメーターとして渡します。curl -X POST "scale-up URL"
$ curl -X POST "scale-up URL"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 負荷を人為的に生成するには、Floating IP をインスタンスに割り当てて、SSH でログインし、CPU の使用率を高くするコマンドを実行して、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 データをスタックから収集すると、スケールアップイベントがトリガーされ、オーケストレーション
インスタンスを初期化し、Apache をインストール/設定してからアプリケーションをデプロイする必要があるため、作成には数分かかる場合があります。この操作は、HAProxy によってモニタリングされ、ステータスが Active に切り替わる前に、Web サイトがインスタンス上で使用可能であることが確認されます。
新規インスタンスの作成中に、Dashboard では、ロードバランシングプールのメンバーが以下のように表示されます。
追加のインスタンスを作成するかどうかを決定する際には、heat スタック内のインスタンスの CPU 使用率の平均が考慮されます。2 番目のインスタンスは通常の CPU 使用率である可能性が最も高いので、1 番目のインスタンスの負荷が相殺されますが、2 番目のインスタンスもビジー状態となり、1 番目と 2 番目のインスタンスの CPU 使用率が 95% を超えると、もう 1 つ (3 番目) のインスタンスが作成されます。
1.3.2. アプリケーションの自動スケールダウン リンクのコピーリンクがクリップボードにコピーされました!
この手順は、「インスタンスの自動スケールダウン」と同様に、スタック CPU 使用率の平均が、事前定義された値 (「アプリケーションのオートスケールのテスト」に記載の例では、15%) を下回ると、スケールダウンポリシーがトリガーされます。また、インスタンスがこの方法でスタックから削除された場合には、ロードバランサーからも自動的に削除され、Web サイトのトラフィックは、残りのインスタンス間で分散されます。