前回のおさらい
前回は、Exastro OASE についての調査と1台のサーバ上にインストールをしました。
Exastro OASE について(再掲)
もっと見る
1. Exastro OASE って何よ？
「[Exastro OASE][公式ページ] はシステム運用の自立化・効率化・省力化を支援するためのOSSです。」
とのことで、平たくいえば、システムの運用を楽チンにしてくれるOSSってことみたいです。
OASE の読み方は「オアゼ」です。
2. Exastro OASE って誰得なの？
障害発生時には、以下のような対応フローが多いと思います。
- 監視システムによるアラート検知
- インシデント・イベント起票
- 一次切り分け
- 暫定復旧作業
- SEによる調査
- 恒久対応
- クローズ
問題が起こったときに、いかに迅速かつ確実に復旧できるかがポイントとなります。
OASE でできるのは、この「3. 一次切り分け」と「4. 暫定復旧作業」といった初期対応の部分です。
「3. 一次切り分け」と「4. 暫定復旧作業」を OASE により自動化することで、サービス復旧までの時間を短縮できます。
また、未知のインシデントが発生した場合は1次切り分けルールと暫定復旧のアクションを増やしていくことで、次第に運用者の対応が減っていくので運用コストを抑える効果も期待できます。
3. Exastro OASE の機能をざっくり見てみよう
もう少し OASE の機能について見てみます。
外部連携機能
OASE は単体では機能しません。
監視機能を持ちませんし、障害発生時のアクションを実行する機能も持っていません。
代わりに、OASE は他のシステムと連携することで監視からアクションまでの一連の処理を実施します。
OASE の構成としては、主に
- 監視システムからのアラートを受け取る__監視アダプタ__
- 受け取ったアラートをルールに従って推論する__ディシジョンテーブル__
- 推論の結果を元にアクションをキックするための__ドライバ__
によって構成されています。
Ver. 1.2 までは監視ソフトウェアには ZABBIX、アクション部分の処理には Exastro IT Automation (ITA) と連携できたようですが、Ver. 1.3 からは Prometheus と連携できるようになったようです。今後この辺の連携機能も更に拡充されていくようです。
テスト実行
障害が発生する度にルールを追加すると記載しましたが、本番環境にテストもせずにアクションを導入することは通常ありえません。
必ず検証環境などで事前にテストを行ってから導入すると思います。
OASE では、検証環境を内部に持っており、アラート検知からアクション実行までのテストを本番に影響を与えることなく実施可能です。
これにより、安心して継続的なルールの管理を行うことが可能となります。
はじめに
本検証は、自らサーバに負荷を与える(着火する)ことでアラートを発生させ、OASE を使って暫定対応(消火)させるという、まさにマッチポンプ的検証なのである。笑
何をどう自動化するかを考える
シナリオ
花輪さんは、本業の片手間に会社の メディアサイトのシステム運用 を任されています。
運用範囲は、Web サーバ1台 における OS・ミドルウェアの障害発生時の対応です。
運用と言っても、何もなければ特にすることはなく、何か問題が有ったときだけ対応を求められる仕事です。
普段は何事もないのですが、投稿された記事が SNS サイトなどで話題になると、アクセスが急増し、Web アプリ が高負荷な状態となり、最終的には OS がハングアップ してしまいます。
こうなってしまうと、SSH ログインすらまともにできないような状況になるため、社内の基盤担当に依頼 をして、OS の再起動 をしてもらう必要があります。
しかし、OS を再起動しても、アクセスが落ち着くまでは何度もハングアップが発生し、都度その対応が必要 な状況です。
根本原因は メモリ不足 であることはわかっており、スケールアウトや リソースの増強 も検討していますが、技術的にも予算的にも 基盤側の対応は厳しい状況 です。
また、運用メンバーは花輪さん一人 のため、本業ですぐに対応できない状況もしばしばあります。
方針を考える
まずは、状況を整理してみよう
上のシナリオをまとめてみます。
| 項目 | 内容 |
|---|---|
| サービス内容 | 一般公開型のメディアサイト |
| 問題点 | 高アクセスがあると OS がハングアップ |
| 暫定対策 | OSの再起動 |
| 根本原因 | メモリ不足 |
| 恒久対策 | リソース増強 |
他にも、花輪さん個人の悩みとしては、本業があるのに、バズり対応のために ちょくちょく手が止まってしまう といった問題があります。
また、基盤担当も何度も OS を再起動する必要がありますね。
そこで Exastro OASE さんの出番ですよ！
OASE を使ってどう解決していくかを考えていきましょう。
OASE は、ルールエンジンを内包していおり、ディシジョンテーブルにより管理されたルールを元に運用を自動化します。
ディシジョンテーブルとは、条件(入力) とそれに対する アクション(出力) からなる ルール を網羅的にまとめたテーブルです。
今回の例における運用ルールは、
- OS がハングアップした場合(条件)、OS を再起動する(アクション)
のようになると思います。
ディシジョンテーブルを作成すると、下記のようになります。
| 条件 | アクション | |
|---|---|---|
| Rules | OS がハングアップした場合 | |
| Rule1 | Y | 再起動を実行する |
| Rule1 | N | 何もしない |
あー、これアカンわ...
OS がハングアップした状態では、SSH でログイン出来ないので、OS コマンドを使った「OSの再起動」は不可ですね。
(OS の外からの再起動であればできますが、花輪さんにはそういった OS 外の作業権限がありません)
ということで、ハングアップする前になんとかしちゃおうという方針に切り替えます。
修正後の運用ルールは、
- アクセス数が多い場合(条件1)、Sorry ページに切り替える(アクション)
- アクセス数が少ない場合(条件2)、元のページに切り替える(アクション)
といったところでしょうか。
処理の重い動的なページを、Sorry ページ のような軽量な静的ページに切り替えることで、サーバのハングアップを回避しようというねらいです。
そして、修正版のディシジョンテーブルはコレ！
| 条件1 | 条件2 | アクション | |
|---|---|---|---|
| Rules | アクセス数が多い場合 | アクセス数が低い場合 | |
| Rule1 | N | N | 何もしない |
| Rule2 | Y | N | Sorry ページ に切り替える |
| Rule3 | N | Y | 元のページに切り替える |
| Rule4 | Y | Y | Sorry ページ に切り替える |
悩ましいのは、Rule4 の条件に対する処理です。
矛盾した条件ですが、Zabbix の監視上タイミングによってはどちらの状態も取り得る可能性があります。
この場合は、フェイルセーフの考えに基づき、「Sorry ページ に切り替える」ようにしました。
環境構築
システム構成
方針も決まったところで、今回のシステム構成を見ていきましょう。
登場人物の紹介
| サーバ | ホスト名 | 説明 |
|---|---|---|
| Webサーバ | target-web | メディアサイトを公開するサーバ |
| 監視サーバ | zabbix | Web サーバの監視を行う |
| OASEサーバ | exastro-oase | 今回の主役。運用を自動化 |
| ITAサーバ | exastro-ita | OASE からの API コールをトリガーにオペレーションを実行 |
作業の流れ
- 周辺環境構築
- 監視対象の Web サーバ構築
- Zabbix 環境構築
- Exastro IT Automation (ITA) 環境を構築
- ディシジョンテーブルの作成
- Zabbix 監視アダプタの設定
- Exastro IT Automation (ITA) ドライバの設定
- ディシジョンテーブルのルール登録
- 動作確認
本稿では、1. 周辺環境構築 を取り扱います。
2. Zabbix 監視アダプタの設定 以降については、次回扱います。
本編スタート
前置きが長くなりましたが、ここから本検証の周辺環境を整えていきます。
1. 周辺環境構築
OASE サーバについては前回やったので、省略します。
OASE サーバ以外の Web サーバ、監視サーバ、ITA サーバの構築を行っていきましょう。
Exastro Suite は、IT Automation (ITA) も OASE も RHEL 系の OS がシステム要件なので、今回は、全台 CentOS 8 で構築していきます。
| 項目 | Webサーバ | Zabbixサーバ | ITAサーバ |
|---|---|---|---|
| ホスト名 | target-web | zabbix | exastro-ita |
| CPU(Cores) | 1 | 1 | 1 |
| メモリ | 2GB | 2GB | 2GB |
| ディスク | 20GB | 40GB | 40GB |
| OS | CentOS 8 | CentOS 8 | CentOS 8 |
| アプリケーション | Apache, php-fpm | Zabbix 5.2 | Exastro IT Automation 1.7.1 |
1.1. 監視対象の Web サーバ構築
監視対象となる Web サーバを構築していきます。
コンテンツの内容自体はどーでもいいですが、ページの表示に関して制御をしたいので、Apache + PHP で動的ページを作ります。
構築手順
PHP 関連パッケージインストール
PHP の Web アプリケーションを実行するためにパッケージのインストールを行います。
# PHP 関連のパッケージのインストール
dnf install -y php php-mbstring php-xml php-xmlrpc php-gd php-pdo php-mysqlnd php-json
テストページを配置
表示までに非常に時間が掛かるページ を想定したテストページを配置します。
GET パラメータに time で指定した秒数分だけ表示を遅らせるプログラムとなります。
このプログラムにアクセスした分だけ処理を滞留させようというのがねらいです。
# テストページの配置
cat << '_EOF_' > /var/www/html/wait.php
<html>
<head>
<title>PHP Test</title>
</head>
<body>
<?php
$WAIT_TIME = $_GET["time"];
sleep($WAIT_TIME);
echo "<p>Hello World</p>";
?>
</body>
</html>
_EOF_
# テストページのパーミッションを変更
chown apache: /var/www/html/wait.php
Zabbix モニタリング用の設定
ステータス画面が表示できるように設定を入れます。
これは、Zabbix がリアルタイムに接続数を取得するためのものです。
# Apache の統計情報を表示させるアクセス数監視用の設定を投入
cat << _EOF_ > /etc/httpd/conf.d/status.conf
ExtendedStatus On
<Location /server-status>
SetHandler server-status
# ↓必要に応じてアクセス制御を入れる
# Require ip 127.0.0.1
</Location>
_EOF_
Zabbix エージェントの導入
# Zabbix リポジトリのインストール
rpm -Uvh https://repo.zabbix.com/zabbix/5.2/rhel/8/x86_64/zabbix-release-5.2-1.el8.noarch.rpm
# リポジトリのキャッシュを初期化
dnf clean all
# Zabbix エージェントのインストール
dnf -y install zabbix-agent
# Zabbix エージェント上のホスト名の変更
sed -i.org -e "s/^Hostname=.*$/Hostname=target-web/" /etc/zabbix/zabbix_agentd.conf
# Zabbix サーバのIPアドレスを設定
ZABBIX_IP=[ZabbixサーバのIPアドレス]
sed -i -e "s/^Server=.*$/Server=${ZABBIX_IP}/" /etc/zabbix/zabbix_agentd.conf
sed -i -e "s/^ServerActive=.*$/ServerActive=${ZABBIX_IP}/" /etc/zabbix/zabbix_agentd.conf
タイムアウト値のチューニング
デフォルトの設定では、1分程度でセッションが切断されるので、タイムアウト値を600秒(10分)まで伸ばします。
# Apache のタイムアウト値の変更
cp -pi /etc/httpd/conf/httpd.conf{,.org}
echo "Timeout 600" >> /etc/httpd/conf/httpd.conf
# PHP のタイムアウト値の変更
sed -i.org -e "s/^max_execution_time.*$/max_execution_time = 600/" /etc/php.ini
サービスの(再)起動
サービスの自動起動設定と起動を行います。
# 各サービスの自動起動設定
systemctl enable httpd php-fpm zabbix-agent
# 各サービスの(再)起動
systemctl restart httpd php-fpm zabbix-agent
動作確認
以下の確認は全てブラウザで行います。
Apache ステータス画面
Apache のステータス画面を確認してみましょう。
http://[target-webのIPアドレス]/server-status
1 requests currently being processed, 99 idle workers
と表示されています。
これは、このステータス画面にアクセスした分のリクエストが表示されているということです。
テストページ
テストページにパラメータ指定せずにアクセスしてみましょう。
http://[target-webのIPアドレス]/wait.php
すぐに「Hello World」が表示されたはずです。
次に、パラメータに time=30 を設定してもう一度テストページにアクセスします。
http://[target-webのIPアドレス]/wait.php?time=30
今度は、30秒後に「Hello World」が表示されたと思います。
リクエストの滞留確認
パラメータに time=30 でアクセスした後に F5 キーを9回連打します。
http://[target-webのIPアドレス]/wait.php?time=30
このときに急いで Apache のステータス画面を見てみましょう。
http://[target-webのIPアドレス]/server-status
すると、下記のようにリクエスト数が 11件 と表示されたと思います。
11 requests currently being processed, 89 idle workers
これは、wait.php の応答待ちのリクエスト 10 件 + server-status へのアクセス 1 件分です。
これで Web サーバ側の下準備は完了しました。
1.2. Zabbix 環境構築
監視サーバとして Zabbix を構築していきます。
公式のマニュアルを参考にインストールします。
構築手順
SELinux の無効化
石川サンゴメンナサイ
# 一時的に Permissive モードに変更
setenforce 0
# 恒久的に無効化
sed -i.org 's/^SELINUX=.*/SELINUX=disabled/' /etc/selinux/config
Zabbix リポジトリの登録とパッケージのインストール
Zabbix 公式リポジトリのインストールと Zabbix 関連パッケージをインストールします。
# Zabbix リポジトリのインストール
rpm -Uvh https://repo.zabbix.com/zabbix/5.2/rhel/8/x86_64/zabbix-release-5.2-1.el8.noarch.rpm
# リポジトリのキャッシュを初期化
dnf clean all
# Zabbix 関連パッケージのインストール
dnf -y install zabbix-server-mysql zabbix-web-mysql zabbix-apache-conf zabbix-agent
MySQL(MariaDB) のセットアップ
MySQL(MariaDB) 関連のパッケージのインストールとサービス起動をします。
# MySQL サーバのインストール
dnf -y install mariadb-server
# MySQL の自動起動を有効にしつつ即座に起動
systemctl enable --now mariadb
MySQL の初期設定をします。
mysql_secure_installation
基本はデフォルト値ですが、MySQL の root パスワードのみ password に設定します。
Enter current password for root (enter for none): (入力なしでエンター)
Set root password? [Y/n]: (入力なしでエンター)
New password: password
Re-enter new password: password
Remove anonymous users? [Y/n]: (入力なしでエンター)
Disallow root login remotely? [Y/n]: (入力なしでエンター)
Remove test database and access to it? [Y/n]: (入力なしでエンター)
Reload privilege tables now? [Y/n]: (入力なしでエンター)
Zabbix 用のデータベースとユーザを作成します。
| 項目 | 値 |
|---|---|
| DB名 | zabbix |
| ユーザ名 | zabbix |
| パスワード | zabbix |
# データベースの作成
mysql -uroot -p'password' -e "create database zabbix character set utf8 collate utf8_bin;"
# Zabbix ユーザのパスワードを設定
mysql -uroot -p'password' -e "grant all privileges on zabbix.* to zabbix@localhost identified by 'zabbix';"
データベーススキーマのインポートをします。
# データベーススキーマのインポート
zcat /usr/share/doc/zabbix-server-mysql*/create.sql.gz | mysql -uzabbix -p'zabbix' zabbix
Zabbix サーバの設定
Zabbix サーバの設定ファイルに DB のパスワードを設定します。
# Zabbix サーバの設定ファイルに DB のパスワードを設定
echo 'DBPassword=zabbix' >> /etc/zabbix/zabbix_server.conf
Zabbix サーバとエージェントの起動
Zabbix サーバとエージェントを(再)起動し、自動起動を有効にします。
# 各サービスの再起動
systemctl restart zabbix-server zabbix-agent httpd php-fpm
# 各サービスの自動起動を有効化
systemctl enable zabbix-server zabbix-agent httpd php-fpm
Zabbix の基本セットアップ
まずは、下記の URL から Zabbix にログインします。
http://[ZabbixサーバのIPアドレス]/zabbix
ようこそ
言語設定は、英語 English (en_GB) を選択します。
日本語に設定したい場合は、フォントをインストールする必要があります。
(フォントがない場合は入力内容が豆腐□になってしまいます。)
前提条件のチェック
オール OK であることを確認します。
データベース接続設定
データベース構築時に設定した値で設定します。
| 項目 | 設定値 |
|---|---|
| データベースタイプ | MySQL |
| データベースホスト | localhost |
| データベースポート | 0 |
| データベース名 | zabbix |
| 資格情報保存先 | Plane text(プレーンテキスト) |
| ユーザ | zabbix |
| パスワード | zabbix |
Zabbix サーバの詳細
デフォルトでいいです。
| 項目 | 設定値 |
|---|---|
| ホスト | localhost |
| ポート | 10051 |
| Name | zabbix server |
GUI設定
タイムゾーンはもちろん日本なので、Asia/Tokyo に、デフォルトのテーマは、今の気分に合わせて Blue にしました。笑
インストール事前準備概要
内容を確認して問題なければ次に進みます。
インストール
これでインストール完了です。
Finish ボタンを押して終了します。
ログイン
早速 Zabbix にログインしましょう。
デフォルトの認証情報は下記のとおりです。
| ユーザ名 | パスワード |
|---|---|
| Admin | zabbix |
ホストの追加
監視対象の Web サーバを追加します。
左メニューから Configuration > Hosts をクリックします。
画面右上の Create host ボタンを押下します。
ホスト情報の入力
下記の項目を設定します。それ以外はデフォルトです。
| 項目 | 設定値 |
|---|---|
| Host name | target-web |
| Groups | Linux servers |
| Interface - Type | Agent |
| Interface - IP address | Web サーバの IP アドレス |
| Interface - DNS name | target-web |
| Interface - Connect to | IP |
| Interface - Port | 10050 |
テンプレートの設定
上メニューから Templates をクリックします。
下記のテンプレートをリンクします。
| ホストグループ | テンプレート名 |
|---|---|
| Templates/Applications | Apache by HTTP |
| Templates/Operating systems | Linux by Zabbix agent |
画面を見る
ホストの追加を実行
画面下の Add ボタンを押下します。
コネクション数更新間隔の変更(1m => 5s)
ページの切り替わりを早くするために、監視の間隔を変更します。
| 初期値 | 変更後 |
|---|---|
| 1m | 5s |
左メニューから Configuration > Hosts をクリックします。
ホスト一覧から target-web を選択します。
上メニューの Items を選択します。
最後に Subfilter の一覧から Apache を選択します。
Apahce: Get status をクリックします。
Update interval の値を 5s に設定し、5秒ごとに値を取得するように変更します。
その後、ページ下部の Update ボタンを押下します。
閾値(トリガー)の設定
次に、監視対象の Web サーバに対する監視ルールを入れていきます。
| メトリックス | 閾値 |
|---|---|
| コネクション数 | 20を超えた場合 |
| コネクション数 | 11を下回った場合 |
コネクション数閾値超え設定
上メニューの Triggers を選択します。
画面右上の Create trigger ボタンを押下します。
下記の項目を設定します。それ以外はデフォルトです。
| 項目 | 設定値 |
|---|---|
| Name | More than 20 connections |
| Severity | Warning |
| Expression | {target-web:apache.workers_total.busy.last(#1)}>20 |
コネクション数閾値下回り設定
画面右上の Create trigger ボタンを押下します。
下記の項目を設定します。それ以外はデフォルトです。
| 項目 | 設定値 |
|---|---|
| Name | Less than 11 connections |
| Severity | Information |
| Expression | {target-web:apache.workers_total.busy.last(#1)}<11 |
ダッシュボードの設定(オプション)
ダッシュボードの追加手順の詳細は記載しませんが、ダッシュボードにグラフを表示しています。
HTTP Connection count のグラフでは、前述の wait.php ページに対して 20 回を超えるアクセスで More than 20 connections トリガーが引かれ、11回を下回る箇所で Less than 11 connections のトリガーが引かれていることが確認できます。
1.3. Exastro IT Automation (ITA) 環境を構築
本項では、高負荷が発生した場合に動的ページを静的な Sorry ページ に切り替えるアクションを構築していきます。
インストール
Exastro IT Automation (ITA) のインストール手順については、この辺を参考にしてください。
ログイン
まずは、ITA の画面にログインします。
初期のログイン情報は下記となります。
| ユーザ名 | パスワード |
|---|---|
| administrator | password |
新パスワードを登録します。
作業対象ホストの登録
メインメニュー を開き、メニューグループ 画面から 基本コンソール を選択します。
左メニューの 機器一覧 をクリックします。
登録 アコーディオンメニューを開き、 登録開始 ボタンを押下します。
下記のように項目を設定します。(設定する項目のみ記載)
| 項目 | 設定値 |
|---|---|
| HW機器種別 | SV |
| ホスト名 | target-web |
| IPアドレス | (WebサーバのIPアドレス) |
| ログインユーザID | root |
| ログインパスワード - 管理 | ● |
| ログインパスワード - ログインパスワード | (rootユーザのパスワード) |
| Ansible利用情報 - Legacy/Role利用情報 - 認証方式 | パスワード認証 |
※本検証では、Webサーバに対して、パスワード認証で root ログイン可能な状況を想定しておりますが、鍵認証を使った操作も可能です。
入力が完了したら、登録 ボタンを押下します。
オペレーションの登録
左メニューの オペレーション一覧 をクリックします。
登録 アコーディオンメニューを開き、 登録開始 ボタンを押下します。
下記のように項目を設定します。(設定する項目のみ記載)
| # | オペレーション名 | 実施予定日 |
|---|---|---|
| 1 | Sorryページ切り替え | 適当な日付 |
| 2 | Sorryページ戻し | 適当な日付 |
入力が完了したら、登録 ボタンを押下します。
コンテンツファイルのアップロード
コンテンツファイルの作成
事前に、下記のファイルを作成しておきます。
▼通常ページ
<html>
<head>
<title>PHP Test</title>
</head>
<body>
<?php
$WAIT_TIME = $_GET["time"];
sleep($WAIT_TIME);
echo "<p>Hello World</p>";
?>
</body>
</html>
▼Sorryページ
<html>
<head>
<title>PHP Test</title>
</head>
<body>
Sorry. Please try again later.
</body>
</html>
ファイル素材の登録
メインメニュー を開き、メニューグループ 画面から Ansible共通 を選択します。
左メニューの ファイル管理 をクリックします。
登録 アコーディオンメニューを開き、 登録開始 ボタンを押下します。
下記のように項目を設定します。(設定する項目のみ記載)
ファイルは上記で作成したものをアップロードします。
| # | ファイル埋込変数名 | ファイル素材 |
|---|---|---|
| 1 | CPF_wait_php_normal | wait.php.normal |
| 2 | CPF_wait_php_sorry | wait.php.sorry |
入力が完了したら、登録 ボタンを押下します。
Movement の登録
メインメニュー を開き、メニューグループ 画面から Ansible-Legacy を選択します。
左メニューの Movement一覧 をクリックします。
登録 アコーディオンメニューを開き、 登録開始 ボタンを押下します。
| # | Movement名 | Ansible利用情報 - ホスト指定形式 |
|---|---|---|
| 1 | Sorryページ切り替え | IP |
| 2 | Sorryページ戻し | IP |
入力が完了したら、登録 ボタンを押下します。
Playbook 素材のアップロード
Playbook の作成
事前に、下記のファイルを作成しておきます。
▼通常ページに差し替え
- name: Replace NORMAL wait.php
copy:
src: "{{ CPF_wait_php_normal }}"
dest: /var/www/html/wait.php
owner: apache
group: apache
mode: 0644
backup: yes
▼Sorryページに差し替え
- name: Replace SORRY wait.php
copy:
src: "{{ CPF_wait_php_sorry }}"
dest: /var/www/html/wait.php
owner: apache
group: apache
mode: 0644
backup: yes
Playbook 素材の登録
左メニューの Playbook素材集 をクリックします。
登録 アコーディオンメニューを開き、 登録開始 ボタンを押下します。
下記のように項目を設定します。(設定する項目のみ記載)
ファイルは上記で作成したものをアップロードします。
| # | Playbook素材名 | Playbook素材 |
|---|---|---|
| 1 | replace_content_to_normal | replace_content_to_normal.yml |
| 2 | replace_content_to_sorry | replace_content_to_sorry.yml |
入力が完了したら、登録 ボタンを押下します。
Movement と Playbook の紐付け
左メニューの Movement-Playbook紐付 をクリックします。
登録 アコーディオンメニューを開き、 登録開始 ボタンを押下します。
下記のように項目を設定します。(設定する項目のみ記載)
| # | Movement | Playbook素材 | インクルード順序 |
|---|---|---|---|
| 1 | Sorryページ切り替え | replace_content_to_sorry | 1 |
| 2 | Sorryページ戻し | replace_content_to_normal | 1 |
入力が完了したら、登録 ボタンを押下します。
作業対象ホストの設定
左メニューの 作業対象ホスト をクリックします。
登録 アコーディオンメニューを開き、 登録開始 ボタンを押下します。
下記のように項目を設定します。(設定する項目のみ記載)
| # | オペレーション | Movement | ホスト |
|---|---|---|---|
| 1 | Sorryページ切り替え | Sorryページ切り替え | target-web |
| 2 | Sorryページ戻し | Sorryページ戻し | target-web |
入力が完了したら、登録 ボタンを押下します。
Conductor の登録
メインメニュー を開き、メニューグループ 画面から Conductor を選択します。
左メニューの Conductorクラス編集 をクリックします。
下記の画像のように、Conductor クラスを作成します。
▼ Webサーバ高負荷対応
▼ Webサーバ高負荷戻し対応
作成が完了したら、登録 ボタンを押下します。
作業実行
事前確認
事前に wait.php にアクセスし、変更前の状態を確認しておきます。
この時、ページには「Hello World」と表示されているはずです。
Sorry ページヘの切り替え実行
Conductor に、「Webサーバ高負荷対応」を選択し、オペレーションに 「Sorryページ切り替え」を選択します。
ITA のページに戻り、ページ下部の 実行 ボタンを押下します。
画像のように、実行が正常に完了すると DONE と表示されているはずです。
ページ切り替えの確認
再度 wait.php にアクセスします。
この時、ページの内容が「Sorry. Please try again later.」に切り替わっていれば成功です。
元のページに切り戻し実行
同様にして、ページの戻し作業を実施してみましょう。
実行が正常に完了し、wait.php の内容が「Hello World」に戻っていれば成功です。
まとめ
Exastro OASE を使うための想定シナリオを考えた。
また、そのシナリオに沿った検証を行うための下準備として、監視対象の Web サーバと Zabbix サーバの構築を行った。
さらに、コンテンツを切り替える仕組みとして Exastro IT Automation (ITA) に Conductor を設定し、コンテンツの切り替えができることを確認した。
周辺環境整えるだけでしたが一苦労でした。。。
次回はついに OASE 開封の儀じゃよ！！
じゃぁの！ヽ(*・ω・)ノ
次回、Exastro OASE でマッチポンプした話(活用編)に続く！