2020年12月31日木曜日

QNAPとOpenVPNを使って自宅にVPN接続する方法

インターネット経由で自宅のネットワークにアクセスできると何かと便利ではあるが、外からRDPやSSHで接続できるようポートを開けてしまうと、外部からの攻撃や乗っ取りのリスクが高まるため望ましくない。実際に身近でも、外からRDPで接続できるようポートを開けていたら、PCが乗っ取られてしまったというケースを聞いたことがある。

というわけで外部から自宅内ネットワークに安全にアクセスするために、VPNによるアクセスを実施することにした。具体的には、QNAPのNASをVPNサーバーとして設定し、WindowsやAndroidからVPNでリモート接続できるようにしてみた

QNAPのOpenVPNサーバの設定

本記事で掲載する画面キャプチャは、QTSバージョン:4.5.1のものとなるが、他バージョンでも、ほぼ同様の画面となっているはずだ。

1. QVPN Serviceのインストール

まず、QNAPのWeb管理画面にログインしたのちApp Centerを開き、「QVPN Service」をインストールする。

2. OpenVPNの設定

インストール後、QVPN Serviceを開く。VPNの方式として、「QBelt」、「PPTP」、「L2TP/IPsec (PSK)」、「OpenVPN」の4種類が選択可能だが、今回は「OpenVPN」を有効化するため、左メニューより「OpenVPN」を選択し、「OpenVPNサーバーを有効にする」にチェックを入れる。

その他の設定はデフォルトのままで問題ないため、「適用」ボタンを押して設定反映を行う。

3. OpenVPNのプロファイルファイルをダウンロード

次に、「設定ファイルのダウンロード (for QVPN v1.1 or newer)」ボタンをクリックし、<QNAPのホスト名>.ovpnというファイル名のファイルをダウンロードする。このファイルはOpenVPNの接続情報が記載されたテキストファイル (プロファイルファイル) となっており、接続に必要な証明書情報も含まれている。

ダウンロードしたプロファイルファイルをテキストエディタで開くと接続先情報がIPアドレス表記になっているので、DDNSなどで自宅のグローバルIPアドレスを名前解決できる場合は、FQDNの表記に修正しておく。これによって、プロバイダから割り当てられるIPアドレスが変更となった場合にも接続することができる。

remote 100.10.20.30 1194
   ↓
remote example.myqnapcloud.com 1194

4. OpenVPN接続ユーザの設定

左メニュー→「権限設定」にて、接続可能とするVPN接続ユーザを追加し、OpenVPNの項目にチェックを付ける。

ブロードバンドルータの設定

OpenVPNはUDPの1194ポートを使うため、ブロードバンドルータでポート開放を行う必要がある。設定方法は各社のルーターのマニュアルを確認すること。通常は「ポートマッピング」といった呼ばれ方の設定項目があるはずで、外部からの特定ポートのアクセスをLAN側の特定のサーバに転送する設定を行えばよい。

OpenVPNは1194/UDPで接続を行うため、以下のようなマッピング設定を行う。

  • LAN側ホスト:QNAPのIPアドレスを設定
  • LAN側ポート番号:1194/UDP
  • WAN側ポート番号:1194/UDP

Windows OSからの接続

1. OpenVPNクライアントをダウンロード

Windows OSの場合、まずは以下URLからOpenVPNクライアントをダウンロードする。自身の使っているWindows OSに合わせて、「Windowsインストーラ」の64bitまたは32bitのどちらかをダウンロードすればよい。

※なお、ダウンロードURLの注意書きに「vpnux Clientがお勧めです」との記載もあるので、そちらを利用してもよい。私はvpnux Clientは使ったことがないので、今回はOpenVPNを使って接続する。

2. OpenVPNクライアントをインストール

インストーラーを実行して、「Install Now」を押すだけでインストールは完了する。なお、途中でデバイスのインストールの警告が表示される場合は、「OK」を押してインストールを継続すればよい。

インストール後、「No readable connection profiles (config files) found.」という内容のポップアップが表示されるが、プロファイルファイルを配置していないことによるものであり、ファイル配置前となることから問題がないメッセージとなるため、「OK」を選択しておく。

3. プロファイルファイルの配置

インストール後、先ほどQNAPからダウロードした<QNAPのホスト名>.ovpnを以下パスに配置する。

C:\Program Files\OpenVPN\config

4. OpenVPNで接続

タスクトレイの「OpenVPN GUI」のアイコンを右クリック→「接続」を選択する。
※タスクトレイに表示されていない場合は、デスクトップの「OpenVPN GUI」のショートカットをダブルクリックし起動すること。

リモート接続を許可しているユーザとパスワードを入力することでOpenVPNによるVPN接続ができる。

なお、接続時に赤字で以下のような警告メッセージが表示されるが、これはAES-128-CBCが非推奨 (DEPRECATED) である旨のメッセージとなる。現時点のQNAPは残念ながら、AES-128-CBCまたはAES-256-CBCの2種類しか設定できないため、この警告は無視して接続するしか対処方法はない状況となる。

Thu Dec 31 08:04:10 2020 WARNING: Compression for receiving enabled. Compression has been used in the past to break encryption. Sent packets are not compressed unless "allow-compression yes" is also set.
Thu Dec 31 08:04:10 2020 DEPRECATED OPTION: --cipher set to 'AES-128-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM). Future OpenVPN version will ignore --cipher for cipher negotiations. Add 'AES-128-CBC' to --data-ciphers or change --cipher 'AES-128-CBC' to --data-ciphers-fallback 'AES-128-CBC' to silence this warning.
Thu Dec 31 08:04:10 2020 OpenVPN 2.5.0 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Oct 28 2020
Thu Dec 31 08:04:10 2020 Windows version 10.0 (Windows 10 or greater) 64bit
Thu Dec 31 08:04:10 2020 library versions: OpenSSL 1.1.1h  22 Sep 2020, LZO 2.10

Androidからの接続

1. OpenVPNクライアントをインストール

Androidの場合は、Google Play Storeから「OpenVPN Connect」を検索して、インストールをする。

2. プロファイルファイルのインポート

OpenVPN Connectを起動すると「Import Profile」画面が表示されるので、「File」タブ→QNAPからダウロードした<QNAPのホスト名>.ovpnを指定→「Import」ボタンを選択する。

リモート接続を許可しているユーザとパスワードを入力し、右上の「ADD」を選択する。

3. OpenVPNで接続

作成したプロファイルの選択し有効化することで接続が開始される。

「Connection request」のポップアップが表示された場合は「OK」を選択する。

「Select Certificate」が表示される場合は、「CONTINUE」と「SELECT CERTIFICATE」どちらを選択しても接続は成功するが、毎回接続時に確認されるのが面倒な場合は、「SELECT CERTIFICATE」を選択してデフォルトの証明書を選択しておけばよい。

正常に接続されれば、以下の通り「CONNECTED」と表示される。

まとめ

以上で、QNAPをVPNサーバーとして、外部からVPNすることに成功した。外出先から自宅環境のファイルを見たり、検証サーバーにアクセスしたり、非常に便利になった。

更新履歴

  • 2017/08/01 新規作成
  • 2020/12/31 最新の情報に合わせて、全体的に内容を更新
2020年12月26日土曜日

商用OSのEOSを調べてみた!2020年末版

 昨年以下記事でまとめた主要な商用OSのEOSについて、今年も調べてアップデートしてみた。結論を先に言うと、2021年中に完全にサポート終了となる製品はなかった。2021年はバージョンアップ対応をすることなく、比較的平和に過ごすことができそうだ。


・商用OSのEOSを調べてみた!2018年末版
https://tech-mmmm.blogspot.com/2018/12/oseos2018.html

・商用OSのEOSを調べてみた!2019年末版
https://tech-mmmm.blogspot.com/2019/12/oseos2019.html

2021年にサポート期限を迎える製品については、赤字で強調表示した。

なお、本記事で「EOS」と表現する場合は、製品として完全にすべてのサポートが終了する期限を指すことにする。例えば、通常サポートが終了しても延長サポートが存在するような場合は、EOSとは表現しない。

Windows (PC用)

2020年1月でWindows 7のサポートも終了したため、現時点でサポートが残っているWindows OSは、Windows 8.1とWindows 10の2つのみとなる。

・製品およびサービスのライフサイクル情報の検索
https://docs.microsoft.com/ja-jp/lifecycle/products/

・Windows 8.1
延長サポート:2023/01/10

・Windows 10
Windows 10は、今までのWindows OSとサポートポリシーが異なり、モダンライフサイクルポリシーが適用される。なお、今までの単純なメインストリームサポートと延長サポートの構成を「固定ライフサイクルポリシー」と呼ぶ。

・ライフサイクルに関する FAQ - Windows
https://docs.microsoft.com/ja-jp/lifecycle/faq/windows

モダンライフサイクルポリシーについて簡単に説明すると、Windows 10では3月と9月の年2回、機能更新プログラムのリリースが予定されており、この機能更新プログラムのリリースから18ヶ月(EnterpriseとEducationのみ9月更新は30ヶ月)が、その機能更新プログラムを適用したWindows 10のサポート期間となる。

機能更新プログラムは2020年4月まではYYMMの形式で表現されていたが、最新の2020年10月のアップデートからは20H2という名称になっている。2021年は21H1、21H2といった名称でリリースされることになる。

以下に現時点におけるサポート中のバージョンを以下に記載する。

・Windows 10, version 1909 サポート終了:2021/05/11
・Windows 10, version 2004 サポート終了:2021/12/14
・Windows 10, version 20H2 サポート終了:2022/05/10

Windows Server

Windows Serverは現時点で、Windows Server 2012、2012 R2、2016、2019の4つのバージョンがサポート中の状況となっている。2023年までサポート終了はないため、しばらくは平和に過ごすことができそうだ。

・製品およびサービスのライフサイクル情報の検索
https://docs.microsoft.com/ja-jp/lifecycle/products/

・Windows Server 2012 / Windows Server 2012 R2
延長サポート:2023/10/10

・Windows Server 2016
メインストリームサポート:2022/01/11
延長サポート:2027/01/11

・Windows Server 2019
メインストリームサポート:2024/01/09
延長サポート:2029/01/09

VMware vSphere

今年は新しいvSphereのバージョンはリリースされることなく過ぎてしまった。今回確認したところ、ESXi 6.7 / vCenter Server 6.7のGENERAL SUPPORTが1年後ろ倒しになっていた。また、2020年はvSphere 7がリリースされた年となった。

・Product Lifecycle Matrix
https://lifecycle.vmware.com/#/

・ESXi 6.0 / vCenter Server 6.0
END OF TECHNICAL GUIDANCE:2022/03/12

・ESXi 6.5 / vCenter Server 6.5
END OF GENERAL SUPPORT:2021/11/15
END OF TECHNICAL GUIDANCE:2023/11/15

・ESXi 6.7 / vCenter Server 6.7
END OF GENERAL SUPPORT:2021/11/15 → 2022/10/15
END OF TECHNICAL GUIDANCE:2023/11/15

・ESXi 7.0 / vCenter Server 7.0
END OF GENERAL SUPPORT:2025/04/02
END OF TECHNICAL GUIDANCE:2027/04/02

Red Hat Enterprise Linux

現在、RHEL 6は延長サポートフェーズのみとなっている。RHEL 7及び8の延長サポートフェーズ期限は現時点でも未発表となっていた。

・Red Hat Enterprise Linux Life Cycle
https://access.redhat.com/support/policy/updates/errata

・Red Hat Enterprise Linux 6
End of Extended Life-cycle Support:2024/06/30

・Red Hat Enterprise Linux 7
End of Maintenance Support:2024/06/30
End of Extended Life-cycle Support:未発表

・Red Hat Enterprise Linux 8
End of Maintenance Support:2029/05/31
End of Extended Life-cycle Support:未発表

AIX

AIXはTL (Technology Level)毎にサポート期限が異なる。本記事では各メジャーバージョンの最新TLのEOSを記載する。なお、2020年11月にAIX 7.2 TL5がリリースされており、結果的にサポート期限が1年延長している。

・AIX support lifecycle information
https://www.ibm.com/support/pages/node/670775

・AIX 7.1 TL5
End of Service Pack Support :2023/04/30 (予想)

・AIX 7.2 TL5
End of Service Pack Support :2023/11/30 (予想)

HP-UX

HP-UXはあまり頻繁なバージョンアップはなく、2007年4月に発表されたHP-UX 11i v3が未だに最新という状況となっている。HP-UX 11i v2のサポート期限が1年延長したようだ。

・HP-UXのサポートポリシー | HPE 日本
https://www.hpe.com/jp/ja/servers/hp-ux/support-policy.html

・HP-UX 11i v2
延長サポート(開発元支援なし) 終了:2021/12月 → 2022/12月

・HP-UX 11i v3
標準サポート終了:未発表

参考

・End Of Support (EOS) の調べ方
https://tech-mmmm.blogspot.jp/2015/04/end-of-support-eos.html
2020年12月22日火曜日

ESXiの仮想ネットワークアダプタ「E1000e」は、1Gbps以上の速度が出る

ESXi 6.7の仮想環境において、主に使用される仮想ネットワークアダプタ (以下、仮想NIC) は以下となっている。
※()内は、各NICのリンクスピードを示す。

  • E1000e (1Gbps)
  • VMXNET 3 (10Gbps)

近年の仮想環境では、10Gbps以上の物理ネットワーク接続が主流になっているので、仮想マシンのおいても1Gbps以上の通信を必要とする場合は、リンクスピードが10GbpsとなっているVMXNET 3を利用する必要があると思っていた。

しかし、実際にはそうではなく、E1000eのような1Gbpsの仮想NICであっても、それ以上の通信速度が出る。今回、それを確かめるため、速度測定を実施してみた。

測定環境

測定環境は①VMXNET 3と②E1000eの2種類のNICを持つNFSサーバを用意し、それぞれのNICに対してNFSマウントを行った際のファイル転送速度を計測する。

ファイル転送はNFSクライアント側にてddコマンドにて5GBのファイル作成を行う。NFSサーバ側では、dstatコマンドにて受信時の転送速度を計測する。

測定結果

① VMXNET 3の場合

まずはVMXNET 3の測定を行う。ethtoolコマンドでNICのリンクスピードを確認すると、10000Mb/s = 10Gbpsのリンクスピードとなっている。

# ethtool ens256 | grep Speed
        Speed: 10000Mb/s

VMXNET 3のNICに付与されているIPアドレスに対してNFSマウントを行い、ddコマンドで5GBのファイルを作成した際の転送速度を計測する。

まず、ファイル送信側のddコマンドの結果は、1.0 GB/sとなった。

# dd bs=100M count=50 if=/dev/zero of=/nfs/testfile
50+0 レコード入力
50+0 レコード出力
5242880000 バイト (5.2 GB) コピーされました、 5.21289 秒、 1.0 GB/秒

受信側となるNFSサーバでdstatにて計測した結果も以下の通り、ネットワーク受信速度を表す「recv」の値が約1GB/sとなっている。これはVMXNET 3が10Gbpsの仮想NICであるため、なんら不思議なことではない。

usr sys idl wai hiq siq| read  writ| recv  send|  in   out | int   csw
  0  45  44   6   0   4|   0   785M| 793M 1010k|   0     0 |  20k   11k
  0  46  42   7   0   5|   0   899M|1010M 1282k|   0     0 |  19k   21k
  0  43  46   8   0   3|   0   952M| 875M 1071k|   0     0 |  15k   16k
  0  53  39   4   0   5|   0   983M|1040M 1298k|   0     0 |  16k   14k
  0  40  48   8   0   5|   0   863M| 822M  986k|   0     0 |  15k   18k
  0  26  68   4   0   2|   0   518M| 470M  581k|   0     0 |8190  7893

② E1000eの場合

次に、E1000eの測定を行う。NICのリンクスピードを確認すると、1000Mb/s = 1Gbpsとなっていることがわかる。

# ethtool ens224 | grep Speed
        Speed: 1000Mb/s

E1000eのNICに付与されているIPアドレスに対してNFSマウントを行い、ddコマンドで5GBのファイルを作成した際の転送速度を計測する。

まず、ファイル送信側のddコマンドの結果は、1.0 GB/sとなった。

# dd bs=100M count=50 if=/dev/zero of=/nfs/testfile
50+0 レコード入力
50+0 レコード出力
5242880000 バイト (5.2 GB) コピーされました、 5.22793 秒、 1.0 GB/秒

受信側となるNFSサーバでdstatにて計測した結果も、recvの値が約1GB/sとなっている。

usr sys idl wai hiq siq| read  writ| recv  send|  in   out | int   csw
  0  43  48   5   0   4|   0   897M| 929M 1195k|   0     0 |  22k   15k
  0  32  56   9   0   4|   0   825M| 833M 1060k|   0     0 |  19k   22k
  0  40  46  11   0   4|   0   968M| 947M 1198k|   0     0 |  22k   33k
  0  39  49  10   0   3|   0   918M| 912M 1148k|   0     0 |  18k   30k
  0  45  43   7   0   4|   0  1059M|1061M 1369k|   0     0 |  22k   29k
  0  14  82   4   0   1|   0   333M| 327M  437k|   0     0 |6957    11k

結果、リンクスピードが1GbpsとなっているE1000eを選択したとしても、VMXNET 3と同様に1Gbps以上で通信できることが確認できた

まとめ

以上より、ESXiの仮想環境の仮想NICは、リンクスピードが通信速度の上限となるわけではなく、それ以上の通信速度が出せることがわかった。

ESXiでは仮想マシン作成時に、選択したOSに合わせて適切な仮想NICがデフォルトで選ばれるようになっているので、特に理由がなければ変更せずに使っても問題なく動作する。しかし、一般的にはE1000eよりもVMXNET 3を選択する方がパフォーマンスが向上すると言われているため、ネットワークのパフォーマンスがシビアな環境ではVMXNET 3に変えることも考慮した方がよいだろう。

参考

2020年12月20日日曜日

Zabbix Agent2を使ってDockerコンテナを監視する

Zabbix 5.0以降から正式サポートされるようになったZabbix Agent2では、DockerホストにインストールすることでDockerコンテナを監視することができる。本記事では、その手順を記載する。

手順

1. DockerホストにZabbix Agent2をインストール

Zabbix Agent2は、zabbix-releaseのrpmパッケージをインストールしたのち、dnfを使うことでインストールできる。

# rpm -Uvh https://repo.zabbix.com/zabbix/5.0/rhel/8/x86_64/zabbix-release-5.0-1.el8.noarch.rpm
# dnf install zabbix-agent2 -y

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

設定ファイルは「/etc/zabbix/zabbix_agent2.conf」となる。以下3行を環境に合わせて修正する。

# vi /etc/zabbix/zabbix_agent2.conf
Server=<Zabbix ServerのIPアドレス>
ServerActive=<Zabbix ServerのIPアドレス>
Hostname=<ホスト名>

sedで修正する場合は、以下のように実行する。

# sed -i.org \
-e 's/^\(Server.*=\).*$/\1<Zabbix ServerのIPアドレス>/g' \
-e 's/^\(Hostname=\).*$/\1<ホスト名>/g' \
/etc/zabbix/zabbix_agent2.conf

3. dockerグループにzabbixユーザを追加

Zabbix Agent2はDockerコンテナの情報を取得する際に、「/var/run/docker.sock」にアクセスする。このファイルは以下の通りrootまたはdockerグループに所属するユーザでなければアクセスすることができない

# ls -l /var/run/docker.sock
srw-rw----. 1 root docker 0 12月  6 15:53 /var/run/docker.sock

Zabbix Agent2はzabbixユーザ権限で実行されるため、そのままでは「/var/run/docker.sock」のアクセスに失敗する。そこで、zabbixユーザをdockerグループに所属させることで対処する。

# usermod -aG docker zabbix
# cat /etc/group | grep docker
docker:x:990:zabbix

上記設定を実施しなかった場合、「Cannot fetch data.」というエラーがZabbix上に表示される。トラブルシュート時の参考情報を後述しているので、必要であれば確認いただきたい。

4. Zabbix Agent2のサービスを起動

設定ファイルを修正後、Zabbix Agent2を起動させる。

# systemctl start zabbix-agent2
# systemctl enable zabbix-agent2
Created symlink /etc/systemd/system/multi-user.target.wants/zabbix-agent2.service → /usr/lib/systemd/system/zabbix-agent2.service.

5. Dockerホストに「Template App Docker」のテンプレートを適用

Zabbix 5.0に「Template App Docker」というテンプレートが存在するので、Dockerホストとなるホストにテンプレートを適用する。

6. コンテナの情報がディスカバリされるのを待つ

ディスカバリは15分間隔で実行されるので待機する。

15分経過したのち「監視データ」→「最新のデータ」にてDockerホストのデータを確認し、コンテナの情報が取得できていれば問題ない。

以下の図では、「centos-squid」という名前のコンテナのCPUやメモリ使用率が取得できていることが確認できる。

【参考1】「Cannot fetch data.」のエラーでコンテナの情報取得に失敗する

zabbixユーザの権限不足によりDockerコンテナの情報取得に失敗した場合、以下のエラーがZabbixのGUI上に表示される。

Cannot fetch data.

zabbix_getコマンドを使うことで、接続確認をすることができるが、同様に「Cannot fetch data.」のエラーで失敗する。

# zabbix_get -s 192.168.33.28 -k docker.info
ZBX_NOTSUPPORTED: Cannot fetch data.

手順に記載した通り、zabbixユーザをdockerグループに所属させることで解消できる。ただし、権限の設定を行ってもzabbix_getコマンドの結果は同じエラーとなり改善しなかったので、権限設定後に必ずZabbix Agent2のサービス再起動をすること

# usermod -aG docker zabbix
# cat /etc/group | grep docker
docker:x:990:zabbix
# systemctl restart zabbix-agent2

再度、zabbix_getコマンドで確認すると、以下の通り情報取得ができるようになったことが確認できた。

# zabbix_get -s 192.168.33.28 -k docker.info | jq
{
  "Id": "TYHR:QZBY:IUDW:3SAK:MXV3:FXPW:A3U3:CS5M:WKUC:5NMO:CAJ3:6ZVV",
  "Containers": 3,
  "ContainersRunning": 3,

~(中略)~

  "InitBinary": "docker-init",
  "SecurityOptions": [
    "name=seccomp,profile=default"
  ],
  "Warnings": null
}

【参考2】Zabbix 5.0より前のバージョンにおけるDockerコンテナの監視方法

Zabbix 5.0より前のバージョンでは、「Zabbix Docker Monitoring」と呼ばれるコンテナ監視用のコンテナを起動させて監視するという方法で実現していたようだ。こちらの手法については、以下URLを参照いただきたい。

参考

2020年12月19日土曜日

TrueNAS CORE 12.0にopen-vm-toolsをインストールする

2020年12月現在、FreeNASは11.3が最新バージョンとなるが、次期バージョンからはTrueNASに統合されることが発表されている。

TrueNASはFreeNASとインストール手順や操作手順はほぼ同一となるよう構成されているので、FreeNASを使っていればTrueNASの構築は特に苦労することなく実施できるだろう。

ただし、ひとつ違いがあり、FreeNASにはデフォルトでインストールされていたopen-vm-toolsが、TrueNASには導入されていない。ESXi上の仮想マシンとしてTrueNASをインストールする場合は不便なので、手動でインストールする手順を確認してみた。

環境

  • ESXi 6.7
  • TrueNAS 12.0

手順

1. pkgのリポジトリ設定を修正

TrueNASはFreeBSDベースのストレージOSとなる。FreeBSDではyumでもaptでもなくpkgによるパッケージ管理を行う。

しかし、TrueNASではpkgの外部リポジトリの設定がデフォルトで無効化されているため、pkgコマンドを実行してもエラーになる。そこで、外部リポジトリの設定を有効化させるため、「/usr/local/etc/pkg/repos/」配下の以下2つの設定ファイルをsedにて修正する

# sed -ie 's/enabled: yes/enabled: no/g' /usr/local/etc/pkg/repos/local.conf
# sed -ie 's/enabled: no/enabled: yes/g' /usr/local/etc/pkg/repos/FreeBSD.conf

念のため、修正後のファイルを確認しておく。「FreeBSD.conf」の設定がenabled: yesになっていることを確認する。

# cat /usr/local/etc/pkg/repos/local.conf
local: {
    url: "file:///usr/ports/packages",
    enabled: no
}
# cat /usr/local/etc/pkg/repos/FreeBSD.conf
FreeBSD: {
    enabled: yes
}

2. pkgにてopen-vm-toolsをインストール

pkg updateを実行し、リポジトリへアクセスできることを確認しておく。

# pkg update
Updating FreeBSD repository catalogue...
Fetching meta.conf: 100%    163 B   0.2kB/s    00:01
Fetching packagesite.txz: 100%    6 MiB   6.7MB/s    00:01
Processing entries: 100%
FreeBSD repository update completed. 31973 packages processed.
All repositories are up to date.

問題なければ、pkg install open-vm-tools-nox11でインストールを行う。

# pkg install open-vm-tools-nox11
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
New version of pkg detected; it needs to be installed first.
The following 1 package(s) will be affected (of 0 checked):

Installed packages to be UPGRADED:
        pkg: 1.14.6 -> 1.15.10 [FreeBSD]

Number of packages to be upgraded: 1

The operation will free 31 MiB.
7 MiB to be downloaded.

Proceed with this action? [y/N]: y ←★yを入力
[1/1] Fetching pkg-1.15.10.txz: 100%    7 MiB   6.9MB/s    00:01
Checking integrity... done (0 conflicting)
[1/1] Upgrading pkg from 1.14.6 to 1.15.10...
[1/1] Extracting pkg-1.15.10: 100%
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
The following 1 package(s) will be affected (of 0 checked):

Installed packages to be UPGRADED:
        open-vm-tools-nox11: 11.0.1_3,2 -> 11.1.5,2 [FreeBSD]

Number of packages to be upgraded: 1

The process will require 2 MiB more space.
1 MiB to be downloaded.

Proceed with this action? [y/N]: y ←★yを入力
[1/1] Fetching open-vm-tools-nox11-11.1.5,2.txz: 100%    1 MiB   1.3MB/s    00:01
Checking integrity... done (0 conflicting)
[1/1] Upgrading open-vm-tools-nox11 from 11.0.1_3,2 to 11.1.5,2...
[1/1] Extracting open-vm-tools-nox11-11.1.5,2: 100%

3. TrueNASを再起動

最後にTrueNASを再起動して完了となる。

# reboot

4. ESXiでVMware Toolsの動作を確認

最後にTrueNASをインストールしたESXiにて仮想マシンの情報を確認し、VMware Toolsとしてopen-vm-toolsを認識していればOKとなる。


参考

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経由で監視することができる。

参考

unboundでIPv6の名前解決を無効化する

随分と以前の話になるがunboundでDNSサーバを構築して利用しているが、いまさらながら気づいてしまったのだが、名前解決の問い合わせを行った際に、IPv4だけでなくIPv6のアドレスの回答をしていることがわかった。
c:\>nslookup account.myqnapcloud.com
サーバー:  UnKnown
Address:  192.168.33.23

権限のない回答:
名前:    qcloud-pr-frontend-1025300009.us-east-1.elb.amazonaws.com
Addresses:  2600:1f18:2a9:a903:10b5:2064:b47:8b1f
          2600:1f18:2a9:a900:bd08:38b3:b8e3:799c
          2600:1f18:2a9:a988:9731:a088:80fe:e041
          2600:1f18:2a9:a904:21ba:a95d:1eec:2321
          2600:1f18:2a9:a901:8740:8c0e:f6b2:5099
          2600:1f18:2a9:a902:eac3:af38:6b91:6e89
          107.21.203.67
          54.175.45.228
          34.195.68.203
          34.192.70.234
          34.192.15.39
          100.24.165.157
Aliases:  account.myqnapcloud.com
これ自体は正常な動作となるのだが、以下の通り実際はIPv6のアドレスによる接続は失敗している。
[root@localhost ~]# curl -v https://www.myqnapcloud.com/
* About to connect() to www.myqnapcloud.com port 443 (#0)
*   Trying 2600:1f18:2a9:a903:10b5:2064:b47:8b1f...
* 接続を拒否されました
*   Trying 2600:1f18:2a9:a900:bd08:38b3:b8e3:799c...
* 接続を拒否されました
*   Trying 2600:1f18:2a9:a901:8740:8c0e:f6b2:5099...
* 接続を拒否されました
*   Trying 2600:1f18:2a9:a904:21ba:a95d:1eec:2321...
* 接続を拒否されました
*   Trying 2600:1f18:2a9:a988:9731:a088:80fe:e041...
* 接続を拒否されました
*   Trying 2600:1f18:2a9:a902:eac3:af38:6b91:6e89...
* 接続を拒否されました
*   Trying 34.195.68.203...
* Connected to www.myqnapcloud.com (34.195.68.203) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* SSL connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate:
*       subject: CN=myqnapcloud.com
*       start date: 12月 03 00:00:00 2019 GMT
*       expire date:  1月 03 12:00:00 2021 GMT
*       common name: myqnapcloud.com
*       issuer: CN=Amazon,OU=Server CA 1B,O=Amazon,C=US
> GET / HTTP/1.1
> User-Agent: curl/7.29.0
> Host: www.myqnapcloud.com
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Fri, 03 Jan 2020 12:55:10 GMT
上記の通りIPv6のアドレスでは接続が拒否されており、IPv6のアドレスを名前解決できても何もうれしくないため、回答からIPv6のアドレスを削除し無効化することにした。

IPv6名前解決無効化手順

unboundの場合は、unbound.confにprivate-address: ::/0を追記することで対処することができる。
# vi /etc/unbound/unbound.conf
private-address: ::/0   ←★追記
private-addressの設定の詳細は、以下のURLのマニュアルを参照してほしい。本設定を行うと、IPv6のすべてのアドレス(::/0)がプライベートアドレスと認識されることから、unboundにおける名前解決の対象外となる。そのため、DNS名前解決時にIPv6の回答があったとしてもIPv6の回答は削除され、結果的にIPv4のみが回答として残ることになる。
IPv4やIPv6のアドレスかクラスレスのサブネットを与えます。これらはあなたのプライベートネットワークのアドレスであり、パブリックなインターネットの名前を返すことを許可しません。そのようアドレスがあればDNSの回答から削除されます。

無効化後の名前解決状況

nslookupで確認すると、以下の通りIPv4のアドレスのみ回答として表示される。
c:\>nslookup account.myqnapcloud.com
サーバー:  UnKnown
Address:  192.168.33.23

権限のない回答:
名前:    qcloud-pr-frontend-1025300009.us-east-1.elb.amazonaws.com
Addresses:  34.192.70.234
          34.192.15.39
          34.195.68.203
          100.24.165.157
          54.175.45.228
          107.21.203.67
Aliases:  account.myqnapcloud.com
先ほどはIPv6のアドレスでは接続が拒否されていたが、当然IPv4のアドレスのみとなったことから、一発で接続できるようになった。
[root@localhost ~]# curl -v https://www.myqnapcloud.com/
* About to connect() to www.myqnapcloud.com port 443 (#0)
*   Trying 107.21.203.67...
* Connected to www.myqnapcloud.com (107.21.203.67) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* SSL connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate:
*       subject: CN=myqnapcloud.com
*       start date: 12月 03 00:00:00 2019 GMT
*       expire date:  1月 03 12:00:00 2021 GMT
*       common name: myqnapcloud.com
*       issuer: CN=Amazon,OU=Server CA 1B,O=Amazon,C=US
> GET / HTTP/1.1
> User-Agent: curl/7.29.0
> Host: www.myqnapcloud.com
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Fri, 03 Jan 2020 12:56:22 GMT
以上でunboundにおけるIPv6の名前解決を無効化することができた。
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などを使って実装することもできるだろう。

参考

Tera TermでLinux操作中にキー入力を受け付けなくなった場合は「Ctrl + Q」を押してみよう

まれにTera Termを使ってLinuxを操作していると、キー操作を受け付けなくなって操作ができなくなることがある。泣く泣くTera Termを×ボタンで閉じて接続しなおして対処していたが、これには原因と解決策があったという小ネタとなる。

## 原因
「Ctrl + S」を押したこと。

## 解決策
「Ctrl + Q」を押す。

以上となる。どうやら、Tera Termの仕様ではなく、Linuxの仕様として「Ctrl + S」を押すと画面出力を停止してしまうらしい。
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からは実施できない
  • スタティックルートが設定できない

参考

人気の投稿