ラベル ZEVENET の投稿を表示しています。 すべての投稿を表示
ラベル ZEVENET の投稿を表示しています。 すべての投稿を表示
2021年8月28日土曜日

Zabbixのディスカバリルールを作成する

Zabbixにはディスカバリルールと呼ばれる、監視対象からの情報取得結果に応じて、自動的に監視するアイテムやトリガーを生成する機能がある。

WindowsやLinuxの標準テンプレートでは、ディスカバリルールが実装されており、例えばネットワークインターフェースが複数ある場合も自動認識がされるため、それぞれのネットワークで個別で監視設定を行うことなく、必要な監視設定が実施される。

今回、OSSのロードバランサーであるZEVENETを例に、実際にディスカバリルールを作成してみたので、その手順を記載する。先に伝えると、なかなかうまくいかずに難航したので、その内容も含め記載をさせていただく。

環境

Zabbixは5.0を使用し、ディスカバリルールによる監視対象として、OSSのロードバランサーであるZEVENETを使用する。ZEVENETに登録した負荷分散対象に状態変化があった際に、トリガーにて検知できるようディスカバリルールを作成する

  • Zabbix 5.0.10
  • ZEVENET 5.11.0

ディスカバリルール作成手順

1. ディスカバリ用のデータ取得コマンドを検証

ディスカバリ時には、監視対象より必要な情報をJSON形式で取得する必要がある。以下にフォーマットを記載する。変数名を"{#変数名}の形式で定義し値を取得すると、取得した値の数だけアイテムやトリガーを自動で生成させることができる。

{
   "data": [
      {
         "{#変数名1}": "値1"
      },
      {
         "{#変数名2}": "値2"
      },

      ~(繰り返し)~

      {
         "{#変数名X}": "値X"
      }
   ]
}

ZEVENETの場合は、コマンドラインツールであるzcliを使うことで、JSON形式のデータを取得することができる。ただし、細かい箇所で記載が異なることから、sedを使って置換を行うことで対処する。

以下が、実際にZEVENETにて取得したデータとなる。変数名は{#FARMNAME}としており、それぞれに負荷分散対象グループの名前が入っている。

# /usr/bin/zcli -nc farm list -filter farmname | sed -e 's/params/data/g' -e 's/farmname/{#FARMNAME}/g'
	{
	   "data": [
	      {
	         "{#FARMNAME}": "farm-chrony"
	      },
	      {
	         "{#FARMNAME}": "farm-postfix"
	      },
	      {
	         "{#FARMNAME}": "farm-squid"
	      },
	      {
	         "{#FARMNAME}": "farm-unbound"
	      }
	   ]
	}

2. テンプレートを作成

ディスカバリルールを作成する前に、テンプレートを作成する。
先ほど作成したJSON形式の情報取得コマンドは、監視対象に対してSSHによる実行を行うことから、マクロにてあらかじめSSHログイン用のパスワードを設定しておく。

3. ディスカバリルールを作成

作成したテンプレートの「ディスカバリルール」を選択し、ディスカバリルールを以下の通り作成する。

設定項目 設定値 説明
名前 ZEVENET Farm discovery 任意で設定。
タイプ SSHエージェント zcliによるコマンド実行が必要となるため、SSHエージェントを選択する。
キー ssh.run[zcli] 任意で設定。
認証方式 パスワード SSH接続時にパスワードによる認証を利用する。
ユーザー名 root
パスワード {$ZEVENET_PASS} マクロで設定したパスワードを指定。
実行するスクリプト /usr/bin/zcli -nc farm list -filter farmname | sed -e 's/params/data/g' -e 's/farmname/{#FARMNAME}/g' 事前に作成したJSON形式のデータを取得するコマンドを指定。
監視間隔 1h 今回は1時間間隔で設定したが、要件に応じた間隔に設定する。頻繁に変更される内容ではない場合は、監視間隔を長くしても問題ないと想定。
存在しなくなったリソースの保持期間 3d 一度ディスカバリした情報が削除された場合に

4. ディスカバリのテスト

「ディスカバリルール」作成画面の「テスト」ボタンを押すことで、ディスカバリのテストを行うことができる。

取得対象のホストのIPアドレス、マクロで設定しているSSH接続用のパスワードを入力し、「値の取得とテスト」ボタンを押す。問題なく成功する場合は、結果欄にJSON形式のデータが表示される。

ただし、いくつか失敗するパターンも経験したので補足する。

Cannot read data from SSH serverのエラーで失敗する

テストをする際に以下のようにCannot read data from SSH serverのエラーが表示され、SSHの接続に失敗してしまう。この事象は毎回必ず発生するものではなく、数回に1回ランダムで発生する事象となる。

調査したところ、以下URLに原因が書いてあった。libsshのバグであり、バージョン0.9.0を使用している場合に発生するようだ。

libsshのバージョンが0.9.5以降であれば確実に直っているようだが、私の環境では0.9.4にバージョンアップすることで事象が解消した
※不要と思ったが、バージョンアップ後念のため再起動を実施した。

# rpm -qa | grep libssh
libssh-config-0.9.0-4.el8.noarch
libssh-0.9.0-4.el8.x86_64

# dnf update libssh.x86_64 -y
# reboot

# rpm -qa | grep libssh
libssh-config-0.9.4-2.el8.noarch
libssh-0.9.4-2.el8.x86_64

Invalid discovery rule valueのエラーで失敗する

Invalid discovery rule valueは、JSON形式のデータが正しく取得できていないことを表すエラーとなる。Zabbix上のエラーメッセージを見ると、確かに[38;5;188mといったおかしな情報が混入している。

Invalid discovery rule value: cannot parse as a valid JSON object: invalid object name at: '"data": [
{
"{#FARMNAME}": "farm-chrony"

しかし、実際にZEVENET上で直接コマンドを実行し取得した値は問題がないように見えるため、原因特定が難航した。

色々調べた結果、これは「ANSIエスケープシーケンス」呼ばれる制御文字列であり、ZEVENETが結果出力に色付けする際に利用しているものが、そのままZabbixに情報として連携されてしまうことが原因だった。

ちなみに、ANSIエスケープシーケンスでは[38;5;NmNで指定した番号のカラーコードで色付けされ、[0mで設定がリセットされる。

ZEVENETの場合はzcliのオプションで-ncを付けることで、結果出力に色付けをしなくなる。このオプションを付けることで事象を解消することができた。

4. アイテムのプロトタイプを作成

ディスカバリされた情報をもとに作成されるアイテムのプロトタイプを作成さる。JSON形式で受け取るデータの変数名(今回の場合は{#FARMNAME})を名前やキーに使うことで、検出した対象ごとにアイテムを作成することができる。

「ディスカバリルール」→「アイテムのプロトタイプ」にて、以下の通りアイテムのプロトタイプを作成する。

設定項目 設定値 説明
名前 ZEVENET Farm "{#FARMNAME}" Status ディスカバリされたアイテム名が重複しないよう、変数{#FARMNAME}を名前に入れるようにする。
タイプ Zabbixエージェント(アクティブ) 今回はログ監視となるため、左記のタイプを選択する。
キー log[/var/log/messages,"farmguardian.*{#FARMNAME}",,,skip] logを使用し、変数{#FARMNAME}の文字列が含まれるログの取得を行う。
データ型 ログ ログの取得のため、左記の設定を行う。
監視間隔 1m 任意で設定。

5. トリガーのプロトタイプを作成

ディスカバリされた情報をもとに作成されるトリガーのプロトタイプを作成さる。アイテムと同様に、JSON形式で受け取るデータの変数名(今回の場合は{#FARMNAME})を名前やキーに使うことで、検出した対象ごとにアイテムを作成することができる。

「ディスカバリルール」→「トリガーのプロトタイプ」にて、以下の通りトリガーのプロトタイプを作成する。

設定項目 設定値 説明
名前 ZEVENET Farm "{#FARMNAME}" Status Down from {HOST.NAME} ディスカバリされたトリガー名が重複しないよう、変数{#FARMNAME}を名前に入れるようにする。
深刻度 軽度の障害 任意の深刻度で設定。
障害の条件式 {Template Net Zevenet:log[/var/log/messages,"farmguardian.*{#FARMNAME}",,,skip].regexp(down)}=1 負荷分散対象のサーバーがダウンしたことを検知させるため、downの文字列があった場合に検知させる。
正常イベントの生成 復旧条件式 今回は復旧条件式を設定。
復旧条件式 {Template Net Zevenet:log[/var/log/messages,"farmguardian.*{#FARMNAME}",,,skip].regexp(resurrect)}=1 負荷分散対象のサーバーが復旧したことを検知させるため、resurrectの文字列があった場合に検知させる。

6. 動作確認

作成したテンプレートを実際にZEVENETのホストに割り当てを行い動作確認を行う。

ディスカバリルールで設定した監視間隔を過ぎると、負荷分散対象ごとにアイテムとトリガーが作成されていることが確認できた。


参考

2021年7月6日火曜日

OSSのロードバランサ「ZEVENET Community Edition」にてTCP half-openのカスタムモニターを実装する

OSSのロードバランサである「ZEVENET」では、カスタムモニター (Farmguardian) を作成することができる。この作成方法は以下記事にした通りで、Linuxのncコマンドやnmapコマンドなどを利用したスクリプトを作成することで実装できる。

今回は、ZEVENETにてTCP half-openチェックと呼ばれる方法で負荷分散対象のサーバを監視するカスタムモニターを作成したので、実装方法を記載する。

環境

  • ESXi 6.7 Update 3
  • ZEVENET Community Edition 5.11

TCP half-openチェックとは

そもそも、TCP half-openチェックどのような監視手法かについて説明しよう。

ロードバランサで頻繁に使用されるモニターとして「TCP チェック」がある。TCPチェックでは、以下のTCPの3ウェイ・ハンドシェイクのステップを負荷分散対象のサーバに対して行い、問題なくコネクションの確立ができたのちに、FINパケットを送信してコネクションを切断する。

  1. 送信元→送信先へSYNパケット送信
  2. 送信先→送信元へSYN+ACKパケットを送信
  3. 送信元→送信先へACKパケット送信

しかし、TCPチェックには問題があり、TCPのコネクションを確立した後に切断処理をすることから、サーバ側のログにアクセス記録やエラーログが残ってしまう場合がある。

例えば、以下はPostfixにて構築したメールサーバに対するTCPチェックのログの例となる。ロードバランサ (IPアドレス : 192.168.33.25) からのconnectされたメッセージとdisconnectされたメッセージが確認できる。

Feb 18 06:34:50 64362e23f9d3 postfix/smtpd[158]: connect from unknown[192.168.33.25]
Feb 18 06:34:50 64362e23f9d3 postfix/smtpd[158]: lost connection after CONNECT from unknown[192.168.33.25]
Feb 18 06:34:50 64362e23f9d3 postfix/smtpd[158]: disconnect from unknown[192.168.33.25] commands=0/0
Feb 18 06:35:05 64362e23f9d3 postfix/smtpd[158]: connect from unknown[192.168.33.25]
Feb 18 06:35:05 64362e23f9d3 postfix/smtpd[158]: lost connection after CONNECT from unknown[192.168.33.25]
Feb 18 06:35:05 64362e23f9d3 postfix/smtpd[158]: disconnect from unknown[192.168.33.25] commands=0/0

上記ログは、無視すれば問題ないものであるが、不要なログが出力されることにより、ログの可読性の低下や、容量増加といった問題が発生する。

そこで、サーバ側にログを残さずTCPチェックを実現する方法として、「TCP half-openチェック」のカスタムモニターを実装することにした。TCP half-openチェックの動作について、再度3ウェイ・ハンドシェイクのステップを見ながら説明する。

  1. 送信元→送信先へSYNパケット送信
  2. 送信先→送信元へSYN+ACKパケットを送信
  3. 送信元→送信先へACKパケット送信

TCP half-openチェックでは、上記の2番目ステップのSYN+ACKパケットを受け取った時点でサーバのポートに問題がないものと判断する。3番目のステップでは、ACKパケットを送信するのではなくRSTパケットを送信することで、3ウェイ・ハンドシェイクを中断させ、コネクション確立前に通信を終了させる。

上記のように、送信元からSYN+ACKを受け取った状態 (half-open) で通信を終了させることで、サーバ側に不要なログが残ることを抑止できる。

ZENEVETでTCP half-openのカスタムモニターを作成する

1. カスタムモニター用のスクリプトを作成

TCP half-openチェックはnmap -sSを使うことで簡単に実行できる。以下はRHEL 7でnmapを実行した例となる。正常に接続できればSTATEopenで表示される。

▼接続成功例
# nmap -sS -p 25 192.168.33.23

Starting Nmap 6.40 ( http://nmap.org ) at 2021-02-20 10:28 JST
Nmap scan report for t3023cent.intrat.local (192.168.33.23)
Host is up (0.00036s latency).
PORT   STATE SERVICE
25/tcp open  smtp

接続に失敗する場合は、STATEclosedであったりfilteredになる。

▼接続失敗例
# nmap -sS -p 123 192.168.33.23

Starting Nmap 6.40 ( http://nmap.org ) at 2021-02-20 10:29 JST
Nmap scan report for t3023cent.intrat.local (192.168.33.23)
Host is up (0.00035s latency).
PORT    STATE  SERVICE
123/tcp closed ntp

Nmap done: 1 IP address (1 host up) scanned in 0.07 seconds

ZEVENETにおいてもnmapコマンドは使用できるのだが、単独ポートでスキャンを実行するとfilteredになるという不具合が存在する。

# nmap -sS -p 25 192.168.33.23
Starting Nmap 7.70 ( https://nmap.org ) at 2021-02-20 10:34 JST
mass_dns: warning: Unable to determine any DNS servers. Reverse DNS is disabled. Try using --system-dns or specify valid servers with --dns-servers
Nmap scan report for 192.168.33.23
Host is up (-0.20s latency).

PORT   STATE    SERVICE
25/tcp filtered smtp
MAC Address: 00:0C:29:1F:E0:DE (VMware)

Nmap done: 1 IP address (1 host up) scanned in 0.44 seconds

スキャン対象のポートを単独ではなく、範囲指定を行うとなぜか成功し、openステータスとなる。

# nmap -sS -p 25-26 192.168.33.23
Starting Nmap 7.70 ( https://nmap.org ) at 2021-02-20 10:34 JST
mass_dns: warning: Unable to determine any DNS servers. Reverse DNS is disabled. Try using --system-dns or specify valid servers with --dns-servers
Nmap scan report for 192.168.33.23
Host is up (-0.15s latency).

PORT   STATE  SERVICE
25/tcp open   smtp
26/tcp closed rsftp
MAC Address: 00:0C:29:1F:E0:DE (VMware)

Nmap done: 1 IP address (1 host up) scanned in 0.44 seconds

上記をふまえ、あまり綺麗な回避策とはいえないが、nmapを監視対象と監視対象ポート+1のポート範囲を指定して実行するようカスタムモニタースクリプトを作成することにする。

結果、カスタムモニタースクリプトcheck_tcp_half_openは以下内容となった。本スクリプトは/usr/lib/nagios/pluginsのディレクトリに配置しておく。

# cat /usr/lib/nagios/plugins/check_tcp_half_open
------------------------------
#!/bin/bash

HOST=$1
PORT=$2
NextPORT=$((${PORT}+1))

nmap -n -sS -p ${PORT}-${NextPORT} ${HOST} | grep open | grep ${PORT}
------------------------------

最後にスクリプトに実行権限を付けておく。

# chmod +x /usr/lib/nagios/plugins/check_tcp_half_open

2. モニター (Farmguardians) を作成

管理GUIにログインし、「Monitoring」→「Farmguardians」にて「CREATE FARMGUARDIAN」を選択する。

Farmguardianの設定は以下の通りとする。Commandの「HOST」はチェック対象のホストのIPアドレス (またはホスト名)、「PORT」はチェック対象のポート番号を示す変数となる。Intervalは負荷分散対象にチェックを行う間隔となるので、要件に応じて設定すればよい。

設定項目 設定値 (TCP half-openチェック)
Name check_tcp_half_open
Command check_tcp_half_open HOST PORT
Interval 15 seconds

3. Farmの設定を修正

「LSLB」→「Farms」で修正対象のFarmの「Edit」ボタンを選択する。

「Health Checks for backend」を先ほど作成したモニターに設定変更する。なお、ZEVENETではなぜか本設定を変更すると「Submit」ボタンを押すことなく即座に設定反映されてしまうので、設定時は注意が必要となる (反映された旨が、自動的に右下にメッセージとして表示される)。

4. 動作確認

設定変更後、「Monitoring」→「Farm Stats」を確認し、負荷分散対象がUpステータスになっていることを確認する。

また、負荷分散対象のサーバのログを確認し、負荷分散装置からのモニターによるアクセスログが出力されていないことを確認する。

▼Postfixのログの例

15秒間隔で出力された接続・切断のログが表示されなくなった。

Feb 21 06:44:05 64362e23f9d3 postfix/smtpd[203]: connect from unknown[192.168.33.25]
Feb 21 06:44:05 64362e23f9d3 postfix/smtpd[203]: lost connection after CONNECT from unknown[192.168.33.25]
Feb 21 06:44:05 64362e23f9d3 postfix/smtpd[203]: disconnect from unknown[192.168.33.25] commands=0/0
Feb 21 06:44:20 64362e23f9d3 postfix/smtpd[203]: connect from unknown[192.168.33.25]
Feb 21 06:44:20 64362e23f9d3 postfix/smtpd[203]: lost connection after CONNECT from unknown[192.168.33.25]
Feb 21 06:44:20 64362e23f9d3 postfix/smtpd[203]: disconnect from unknown[192.168.33.25] commands=0/0

▼Squidのログの例

15秒間隔で出力されたerror:transaction-end-before-headersのログが表示されなくなった。

1613857802.748      0 192.168.33.25 NONE/000 0 NONE error:transaction-end-before-headers - HIER_NONE/- -
1613857817.752      0 192.168.33.25 NONE/000 0 NONE error:transaction-end-before-headers - HIER_NONE/- -
1613857832.756      0 192.168.33.25 NONE/000 0 NONE error:transaction-end-before-headers - HIER_NONE/- -

参考

2020年12月12日土曜日

OSSのロードバランサ「ZEVENET Community Edition」をZabbixで監視する方法

OSSのロードバランサである「ZEVENET Community Edition」を先日から自宅に導入して使用しており、クラスタ化したりカスタムモニターを作ったりして、いろいろ使い方を試している。

★過去の記事はこちら。

ZEVENETはネットワーク機器であるため、SNMPによるポーリングを行い情報取得を行うことで監視することもできるのだが、ZEVENETはDebianベースのLinuxで構成されていることから、Zabbix Agentを導入して監視することができる

今回はZEVENETをZabbixで監視する方法について記載する。

環境

  • ESXi 6.7 Update 3
  • ZEVENET Community Edition 5.11

手順

1. aptにてZabbix Agentをインストール

ZEVENETはデフォルトでaptによるパッケージのインストールができる。まず、zabbix-agentがリポジトリに存在することを確認しておく。

# apt search zabbix-agent
ソート中... 完了
全文検索... 完了
pcp-export-zabbix-agent/stable 4.3.2+really4.3.1-0.1 amd64
  Module for exporting PCP metrics to Zabbix agent

zabbix-agent/stable 1:4.0.4+dfsg-1 amd64
  network monitoring solution - agent

問題なく存在するようなので、インストールを行う。

# apt install zabbix-agent -y

2. Zabbix Agentの設定ファイルを修正

以下3行の設定修正を行う。

# cp /etc/zabbix/zabbix_agentd.conf{,.org}
# vi /etc/zabbix/zabbix_agentd.conf
Server=<ZabbixサーバのIPアドレス>
ServerActive=<ZabbixサーバのIPアドレス>
Hostname=<ZEVENETのホスト名>

3. Zabbix Agentを起動

最後にZabbix Agentを再起動させ、OS起動時に自動起動するようにしておく。これでZEVENET側の設定は完了となる。

# systemctl restart zabbix-agent
# systemctl enable zabbix-agent

4. Zabbixサーバにてホスト登録

Zabbixサーバ側にて、エージェントをインストールしたZEVENETの登録を行う。これは、通常のZabbixにおける手順と同様に「設定」→「ホスト」にてホストを登録すればよい。この際に、テンプレートは、「Template OS Linux by Zabbix agent」を選択すれば、ZEVENETをZabbix Agent経由で監視することができる。

参考

2020年12月5日土曜日

OSSのロードバランサ「ZEVENET Community Edition」にてカスタムモニター (Farmguardian) を作成する

先日から、OSSのロードバランサ「ZEVENET」を自宅環境に導入しており、半月ほど使用しているが、特に不具合も発生せず問題なく動作している。

★過去の記事はこちら。

今回はZEVENETでカスタムモニター (Farmguardian) の作成する手順について記載する。

カスタムモニターとは

一般的に、ロードバランサでは、負荷分散対象のサーバに対して通信ができるかどうかを一定間隔で監視する機能が備わっており、「モニター」であるとか「ヘルスチェック」などと呼ぶことが多い。ZEVENETでは、このモニターの設定を「Farmguardian」と呼ぶが、分かりづらいので本記事では「モニター」と呼ぶことにする。

ZEVENETでは、プロキシ、メール、DNS、NTPの通信を2台のサーバに負荷分散させる用途で使用しており、プロキシとメールに関してはTCPの通信となるため、「check_tcp」と呼ばれるモニターにてTCPのポート開放を定期的にチェックすることで、サーバの監視を行うことができる。

DNSとNTPはUDPの通信であり、ZEVENETにはデフォルトで「check_udp」と呼ばれるモニターが用意されているのだが、この「check_udp」は正常に動作しないことに気づいた。以下が実際にDNSに対してcheck_udpのモニターを設定した結果となるが、正常に監視が行われずにDownステータスになってしまっている。

今回上記を解消する手順を確認したので記載する。この手順を応用すれば、ZEVENETのOSコマンドでチェックできる機能であれば、自由にカスタムモニターを作ることができる。今回は、「UDP」と「DNS」のチェック方法を例に設定方法を記載する。

環境

  • ESXi 6.7 Update 3
  • ZEVENET Community Edition 5.11

手順

1. 「/usr/lib/nagios/plugins」にモニター用のスクリプトを確認

マニュアルには明確に記載されていないが、ZEVENETでモニターを作成する際は、必ず「/usr/lib/nagios/plugins」にモニター用のスクリプトを作成する必要がある。このディレクトリ以外に配置されているOSコマンドやスクリプトでは正常に動作しないので注意すること。

なお、デフォルトでも多数のスクリプトが配置されている。

# cd /usr/lib/nagios/plugins
# ls -l
合計 2552
-rwxr-xr-x 1 root root  55952  5月 13  2018 check_apt
-rwxr-xr-x 1 root root   2315  5月 13  2018 check_breeze
-rwxr-xr-x 1 root root  60432  5月 13  2018 check_by_ssh
lrwxrwxrwx 1 root root      9  5月 13  2018 check_clamd -> check_tcp
-rwxr-xr-x 1 root root  43504  5月 13  2018 check_cluster
-rwxr-xr-x 1 root root  64208  5月 13  2018 check_dbi

~(以下略)~

これらのヘルプを確認して使えそうなスクリプトがあれば当然使用できる。ヘルプは./<スクリプト名> -hで確認することができる。

# ./check_dns -h
check_dns v2.2 (monitoring-plugins 2.2)
Copyright (c) 1999 Ethan Galstad <nagios@nagios.org>
Copyright (c) 2000-2008 Monitoring Plugins Development Team
        <devel@monitoring-plugins.org>

This plugin uses the nslookup program to obtain the IP address for the given host/domain query.
An optional DNS server to use may be specified.
If no DNS server is specified, the default server(s) specified in /etc/resolv.conf will be used.


Usage:
check_dns -H host [-s server] [-a expected-address] [-A] [-t timeout] [-w warn] [-c crit]

Options:
 -h, --help
    Print detailed help screen
 -V, --version

~(以下略)~

2. カスタムモニター用のスクリプトを作成

今回はあえてカスタムモニター用のスクリプトを作成し、ZEVENETに登録することにする。

UDPチェック用のスクリプトを「check_udp2」、DNSチェック用のスクリプトを「check_dns2」として以下の通り作成した。それぞれ第1引数にチェック対象のホストのIPアドレス (またはホスト名)、第2引数にチェック対象のポート番号を指定して実行する作りとする。

UDPチェックはncコマンドでポート開放をチェックする。

# cat /usr/lib/nagios/plugins/check_udp2
------------------------------
#!/bin/bash

HOST=$1
PORT=$2

nc -unvz ${HOST} ${PORT}
------------------------------

DNSチェックはdigコマンドを使い、example.comの名前解決をできるかどうかでDNSのサービスの状態をチェックする。

# cat /usr/lib/nagios/plugins/check_dns2
------------------------------
#!/bin/bash

HOST=$1
PORT=$2

dig @${HOST} example.com -p ${PORT} +short +time=3 +tries=3
------------------------------

最後にスクリプトに実行権限を付けておく。

# chmod +x /usr/lib/nagios/plugins/check_udp2
# chmod +x /usr/lib/nagios/plugins/check_dns2

3. モニター (Farmguardians) を作成

管理GUIにログインし、「Monitoring」→「Farmguardians」にて「CREATE FARMGUARDIAN」を選択する。

Farmguardianの設定は以下の通りとする。Commandの「HOST」はチェック対象のホストのIPアドレス (またはホスト名)、「PORT」はチェック対象のポート番号を示す変数となる。Intervalは負荷分散対象にチェックを行う間隔となるので、要件に応じて設定すればよい。

設定項目 設定値 (UDPチェック) 設定値 (DNSチェック)
Name check_udp2 check_dns
Command check_udp2 HOST PORT check_dns2 HOST PORT
Interval 15 seconds 15 seconds

4. Farmの設定を修正

「LSLB」→「Farms」で修正対象のFarmの「Edit」ボタンを選択する。

「Health Checks for backend」を先ほど作成したモニターに設定変更する。なお、ZEVENETではなぜか本設定を変更すると「Submit」ボタンを押すことなく即座に設定反映されてしまうので、設定時は注意が必要となる (反映された旨が、自動的に右下にメッセージとして表示される)。

5. 動作確認

設定変更後、「Monitoring」→「Farm Stats」を確認し、負荷分散対象がUpステータスになっていることを確認する。

まとめ

ZEVENETのカスタムモニターは、「/usr/lib/nagios/plugins」にモニター用のスクリプトを配置するということに注意すれば、OSコマンドを利用することで簡単にカスタマイズすることができる。

応用すれば、例えばOracle DBなどを監視させる場合もsqlplusなどを使って実装することもできるだろう。

参考

2020年11月28日土曜日

OSSのロードバランサ「ZEVENET Community Edition」をクラスタ化し冗長構成にする

先日、OSSのロードバランサである「ZEVENET Community Edition」の導入手順を記事にした。

ZEVENET Community Editionでは、Enterprise Editionと比較すると機能が必要最低限に制限されているため、GUIからはクラスタ化による冗長構成を設定することができない。しかし、SSHにてログインしCLIから操作することで、クラスタ化の設定が可能となっている。クラスタ化することで、2台のZEVENET間で以下が実装される。

  • VRRPによるVIP冗長化
  • コンフィグ同期

クラスタ化の手順はZEVENET公式の手順はにまとめられているものの、実際はその手順だけでは不足していた。そこで、本記事では不足していた手順を含め、ZEVENETのクラスタ化手順をまとめることにする。

環境

  • ESXi 6.7 Update 3
  • ZEVENET Community Edition 5.11

「zevenet-ce-cluster」パッケージのインストール

1. 公開鍵証明書方式にてSSHログインを許可

ZEVENETはクラスタ化するとコンフィグ同期がされるようになる。コンフィグ同期の仕組みはいたってシンプルで、設定ファイルが保存されている「/usr/local/zevenet/config」のフォルダをrsyncにて同期するというものになっている。

rsysncで正常にコンフィグ同期がされるように、公開鍵認証方式にてパスワードなしでログインできるようにしておく。公開鍵認証方式は、ssh-keygenにてキーペアを作成し、ssh-copy-idにて対向ノードに公開鍵をコピーするだけでよい。

## node1で実行

# ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): ←★空白でエンター
Created directory '/root/.ssh'.
Enter passphrase (empty for no passphrase): ←★空白でエンター
Enter same passphrase again: ←★空白でエンター
~(以下略)~

# ssh-copy-id root@<node2のIPアドレス>
~(中略)~
Are you sure you want to continue connecting (yes/no)? yes ←★yesを入力
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
root@<node2のIPアドレス>'s password: ←★node2のrootパスワードを入力
~(以下略)~
## node2で実行

# ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): ←★空白でエンター
Enter passphrase (empty for no passphrase): ←★空白でエンター
Enter same passphrase again: ←★空白でエンター
~(以下略)~

# ssh-copy-id root@<node1のIPアドレス>
~(中略)~
Are you sure you want to continue connecting (yes/no)? yes ←★yesを入力
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
root@<node1のIPアドレス>'s password: ←★node1のrootパスワードを入力
~(以下略)~

2. Zevenet CE Clusterのパッケージをインストール

ZEVENET Community Editionをクラスタ化するためのパッケージである「Zevenet CE Cluster」のパッケージをインストールする。インストールはapt-getで行う。

## node1/node2両方で実行

# apt-get update
# apt-get install zevenet-ce-cluster -y
パッケージリストを読み込んでいます... 完了
依存関係ツリーを作成しています
状態情報を読み取っています... 完了

~(中略)~

systemd (240-2) のトリガを処理しています ...
zevenet-ce-cluster (1.3) を設定しています ...
Completing the Zevenet CE Cluster installation...

3. Zevenet CE Clusterの設定ファイルを修正

Zevenet CE Clusterの設定ファイルの以下個所を修正する。$cluster_ipでクラスタのVIPを設定しているので、一見するとVIPが自動作成されるように見えるが、実際には作成されることはない。VIP自体はGUIで作成すること。

## node1/node2両方で実行

# cp /usr/local/zevenet/app/ucarp/etc/zevenet-cluster.conf{,.org}
# vi /usr/local/zevenet/app/ucarp/etc/zevenet-cluster.conf
#local IP to be monitored, i e 192.168.0.101
$local_ip="<自ノードのIPアドレス>";

#remote IP to be monitored, i e 192.168.0.102
$remote_ip="<対向ノードのIPアドレス>";

#used password for vrrp protocol communication
$password="<VRRPで使用する共通パスワード>";

#unique value for vrrp cluster in the network
$cluster_id="<任意のVRRP ID>";

#used virtual IP in the cluster, this ip will run always in the master node
$cluster_ip="<クラスタで使用するVIP>";

4. サービス起動ファイルの設定修正

ここが公式のマニュアルでは言及がされていない手順となる。

この状態でzevenet-ce-clusterサービスを起動させようとすると、以下の通り「Cluster is disabled」エラーとなり起動に失敗する。

# /etc/init.d/zevenet-ce-cluster start
Cluster is disabled, enable cluster in /etc/init.d/zevenet-ce-clusterUsage: /etc/init.d/zevenet ( stop | start )

起動スクリプトである「/etc/init.d/zevenet-ce-cluster」内に$enable_cluster変数があるが、デフォルトではfalseに設定されておりクラスタが起動できないことが原因となる。この変数をtrueに修正する。

## node1/node2両方で実行

# vi /etc/init.d/zevenet-ce-cluster
#!/usr/bin/perl
$action = $ARGV[0];

$enable_cluster="true"; # false = disable cluster, true = enable cluster
↑★trueに変更

~(以下略)~

5. zevenet-ce-clusterサービスを起動

zevenet-ce-clusterサービスを起動させる。先に起動した側がMasterになることから、Master側を先に起動させるようにすること。Master/Backupどちらで起動しているかは「/etc/zevenet-ce-cluster.status」ファイルに記録される。また、このファイルの内容はシェルのプロンプトにも表示されるようになる。

## node1で実行

# /etc/init.d/zevenet-ce-cluster start
Starting Zevenet CE Cluster...
[master] # cat /etc/zevenet-ce-cluster.status
master

次にBackup側を起動させる。

## node2で実行

# /etc/init.d/zevenet-ce-cluster start
Starting Zevenet CE Cluster...
[backup] # cat /etc/zevenet-ce-cluster.status
backup

動作確認

管理GUIにログインしてみると、Masterとなっているnode1側では、Virtual Interface及びFarmがUp (緑色) となっており、正常に動作していることがわかる。


一方、Backupとなっているnode2側では、Virtual Interface及びFarmがDown (赤色) となっており、Backup中はVirtual Interface及びFarmが無効化されていることがわかる。


MasterとBackupを切り替えるためには、Master側にSSHでログインし、zevenet-ce-clusterサービスを停止→数秒待機→起動すればよい。サービス再起動だと、Master側のZEVENETが再度Masterで復帰してしまうので注意。

[master] # systemctl stop zevenet-ce-cluster
[] #
[] # systemctl start zevenet-ce-cluster
[backup] #

あるいは、ZEVENET自体を再起動ことでも、MasterとBackup切り替えることができる。

まとめ

以上で、ZEVENET Community Editionをクラスタ化し冗長構成にすることができた。GUIで設定できないことは少し不便ではあるものの、設定後は問題なく切り替わりやコンフィグ同期も動作しており、これによってより一層使えるロードバランサになった。

参考

2020年11月22日日曜日

OSSのロードバランサ「ZEVENET Community Edition」をESXi上にインストールしてみた

自宅検証環境ではPacmekaerで冗長化したプロキシサーバ (兼DNS/メール/NTPサーバ) を構築している。このサーバは、PacmekaerでActive-Standby構成としていたが、ロードバランサを導入してActive-Active構成に変更したいと考えていた。

そんなことを計画しながら、OSSで使えそうなロードバランサを探していると、スペインに本社を置くZEVENET社の「ZEVENET」という製品を見つけることができた。

ZEVENET Enterprise EditionとZEVENET Community Editionの2つが用意されており、Community Editionであれば無償利用が可能となる。各エディションの差異は、以下公式サイトに情報がある。ちなみに、以下URLではクラスタ構成はEnterprise Editionのみ可能と読めるが、Community Editionであってもクラスタ構成は可能となる。

ZEVENETは残念ながら日本では人気がないらしく、ググっても日本語の情報はほとんどヒットしなかったが、マニュアル自体は充実しておりインストールと設定には困らなそうなので、自宅のESXi環境に、「ZEVENET Community Edition」を導入してみることにした

以後、ZEVENET Community Editionの表記について、特に断りがない限りは単に「ZEVENET」として記載をすることにする。

環境

  • ESXi 6.7 Update 3
  • ZEVENET Community Edition 5.11

ダウンロード

1. ZEVENETのISOイメージをダウンロード

ダウンロードは以下サイトから実施する。ZEVENETは、ソースコード、ISOイメージ、Dockerイメージの3種類がダウンロードできる。今回は、ESXi上の仮想マシンとして構築することから「DOWNLOAD ISO IMAGE」を選択して、ISOイメージをダウンロードする。

2. 仮想マシンの作成

ZEVENETをインストールするための仮想マシンを作成する。以下構成で仮想マシンを作成する。インストール後にuname -aで確認すると「Debian 4.19.67-2 (2019-08-28) x86_64」と表示されるので、OS自体はどう見てもDebian 10ベースのようなだが、ゲストOSのバージョンは「その他のLinux」を選択する必要があるので注意。

設定項目 設定値
ゲストOSのバージョン その他の Linux 4.x 以降 (64 ビット)
CPU 1コア
メモリ 1GB
ディスク 8GB
NIC 1枚 ※VMXNET 3でOK
CD/DVDドライブ ZEVENETのISOイメージを指定

設定で来たら、仮想マシンをパワーオンし「Install」を選択してインストールを開始する。

インストール

1. 言語設定

「Select a Language」の画面では「日本語」を選択しておく。

2. ネットワーク設定

ZEVENETに割り当てるIPアドレス等を以下の通り指定する。

設定項目 設定値
IPアドレス ZEVENETに設定するIPアドレス。x.x.x.x/xの形式で記載する。x.x.x.xの形式で記載した場合は、次の画面でサブネットマスクの設定画面が表示される
ゲートウェイ ZEVENETに設定するデフォルトゲートウェイ。なお、ZEVENET Community Editionではスタティックルートの設定はできないので注意
ネームサーバアドレス 空白でOK
ホスト名 ZEVENETに設定するホスト名
ドメイン名 空白でOK

3. rootパスワード設定

rootパスワードの設定を聞かれるので、任意のパスワードを設定する。なお、ZEVENET Community Editionでは、rootユーザのみ設定が可能で、その他のユーザ作成を行うことはできない。

4. ディスクのパーティション設定

ディスクのパーティション設定は、以下の通りディスク全体を使う設定をすれば問題ない。

設定項目 設定値
パーティショニングの方法 ガイド - ディスク全体を使う
パーティション設定の確認 パーティショニングの終了とディスクへの変更の書き込み
ディスクに変更を書き込みますか? はい

5. GRUBの設定

GRUB設定は以下の通り設定しておく。

設定項目 設定値
GRUBをインストールするデバイス /dev/sdaと/dev/sda1を選択
ブートローダをインストールするデバイス /dev/sdaを選択

6. 管理GUIにログイン

以上でインストールは完了となる。再起動後、以下URLにアクセスするとログイン画面が表示されるはずだ。rootユーザと設定したパスワードを使ってログインしてみよう。

https://<ZEVENETのIPアドレス>:444

open-vm-toolsのインストール

ZEVENETは標準ではopen-vm-toolsがインストールされていないので、SSHでログインしたのち、手動でインストールを行う。いきなりインストールを試みると失敗するようなので、apt updateを1回実行してからインストールすること。

# apt update
# apt install open-vm-tools -y

ロードバランサ設定

1. Virtual Interfaceを設定

「Network」→「Virtual Interfaces」にてサービス提供用の仮想インタフェースを設定する。シングル構成で動作させる場合は設定しなくても動作させることはできるが、クラスタ構成として冗長化する場合も考慮して、仮想インタフェースの設定は実施することをお勧めする。

2. Farmを設定

ZEVENETでは負荷分散の設定を「Farm」という名前で設定する。Farmの設定には以下が含まれる。

  • 使用する仮想インタフェースと待ち受けるポート番号
  • 振り分け先サーバとポート番号
  • 振り分け先サーバの監視方式 (PingチェックやTCPチェック等)
  • 振り分けのアルゴリズム (Round Robin等)
  • パーシステント方式 (送信元IPに応じて振り分け先を決定等)

設定方法は、「LSLB」→「Farms」で行う。「CREATE FARM」ボタンでFarmを作成したのち、鉛筆マークの「Edit」ボタンを押して、詳細な負荷分散の設定を行う。このあたりの設定の詳細は割愛するが、たとえば、メールサーバに対する振り分け設定は以下の通りとなる。

設定項目 設定値
Load balancer Algorithm Round Robin
Persistence No persistence
Health Checks for backend check_tcp
Backend メールサーバ2台を25番ポートで登録。PriorityとWeightはデフォルトの1を設定

まとめ

最後にまとめとして、ZEVENETのメリット・デメリットを以下に記載する。

メリット

  • OSイメージが約570MBと軽量
  • 軽量なため、少ないリソースでも十分に動作する
  • 軽量なため、OSの起動がすごく早い
  • Debianベースとなっているため、OSコマンドである程度対処ができる (aptによるパッケージ管理やsystemdによるサービス管理など)
  • ZEVENET公式のマニュアルが比較的充実
  • 良くも悪くもCommunity Editionでは設定項目が必要最低限に絞られているので、マニュアル見なくてもあまり迷うことなく直感的に設定できる
  • Community Editionでもクラスタ構成が組める

デメリット

  • UIを日本語に変更できるが、翻訳が直訳で雑 (Farmが農場と翻訳されていたりする)
  • 公式サイトも日本語サイトがあるが、機械翻訳によるものとなっており、あやしさが漂う
  • おそらく日本国内の人気は低く、日本語で記載されたブログ等の情報は皆無
  • Community Editionであってもクラスタによる冗長化が組めるが、GUIからは実施できない
  • スタティックルートが設定できない

参考

人気の投稿