メモのページ - チラシの裏メモ 3枚目

気になった事を書き殴る

MirageOS UnikernelでWebサーバ

前回は、Ubuntu Linuxの最新バージョン20.04にMirageOSをインストール、Hello Worldアプリの実行を成功させた。
Hello Worldアプリは立ち上げてHello Worldを自動で出力させるだけ。これで満足するするような自分ではない。もっと本格的なツール、例えばFTPサーバやWebサーバ等は無いか探したところ、チュートリアル的なDNSサーバやHTTPサーバ等がmirage-skeltonディレクトリ配下やGithubに有る事に気が付いた。
4連休全て天気予報は雨との事で外出の予定無し。時間はたっぷり有る。
...という事で、今回は簡易なWebサーバ「static website tls」の導入を試みた。
※前回:https://debslink.hatenadiary.jp/entry/20200718/1595076105



当方の環境
ホストOS:Windows7 32bit版 / RAM: 4GB / CPU: Intel Core i3-2350M 2.30GHz
ゲストOS:Ubuntu Server 20.04 x86 64bit版
Virtualbox 5.2.32
MirageOS 3.8.0
OCaml 4.10.0
Ubuntu Desktopは既にデプロイ済みである事とする。
PCのCPU仮想化支援機構はBIOSにて既に有効設定済みである事とする。
Ubuntu Linuxカーネルやバージョンやインストール済みのツール等は、前回のHello Worldから変えていない。



MirageOSのインストール
MirageOSインストールの準備、opamの環境設定、MirageOSのインストールに関しては、以下のリンク先を参照。
https://debslink.hatenadiary.jp/entry/20200718/1595076105



下準備
前回ではopamおよびMirageOSのインストールの為に外部リポジトリの使用を試みたものの、Ubuntu 20.04用のディレクトリがまだ準備されていなかった為に、Ubuntuリポジトリを使用しインストールした。
ところが外部リポジトリの設定の事はすっかり忘れ、消さずにそのまま残していた為にapt-getで導入済みのツールのアップデートが出来なかった。
よって、今回は外部リポジトリの削除から始めた。

$ sudo apt-get update
Hit:1 http://jp.archive.ubuntu.com/ubuntu focal InRelease
Get:2 http://jp.archive.ubuntu.com/ubuntu focal-updates InRelease [111 kB]
Get:3 http://jp.archive.ubuntu.com/ubuntu focal-backports InRelease [98.3 kB]
Get:4 http://jp.archive.ubuntu.com/ubuntu focal-security InRelease [107 kB]
Ign:5 http://ppa.launchpad.net/avsm/ppa/ubuntu focal InRelease
Err:6 http://ppa.launchpad.net/avsm/ppa/ubuntu focal Release
  404  Not Found [IP: 91.189.95.83 80]
Reading package lists... Done
E: The repository 'http://ppa.launchpad.net/avsm/ppa/ubuntu focal Release' does not have a Release file.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.
$
$ sudo add-apt-repository --remove ppa:avsm/ppa
[sudo] password for hoge: 
 Latest stable versions of OCaml and OPAM.
 More info: https://launchpad.net/~avsm/+archive/ubuntu/ppa
Press [ENTER] to continue or Ctrl-c to cancel removing it.


apt-get updateおよびapt-get upgradeの次は、Ubuntu Linux側でtap0インタフェースの作成。Ubuntu LinuxとMirageOSとの間の通信にてtap0インタフェースが使用される為である。
Ubuntu Linux側では既に生成されているブリッジインタフェースvirbr0とWebサーバを同じネットワークに属させ、tap0インタフェース経由でWebサーバにアクセスさせる為。

$ sudo ip tuntap add tap0 mode tap
$ sudo ip link set dev tap0 up
$ sudo brctl addif virbr0 tap0


その後、Webサーバへのアクセス確認用として、テキストベースのWebブラウザLynxをインストール。

$ sudo apt-get install lynx
Reading package lists...
Done
libcrypt-dev is already the newest version (1:4.4.10-10ubuntu4).
libcrypt-dev set to manually installed.
The following additional packages will be installed:
  libzarith-ocaml lynx-common
The following NEW packages will be installed:
  libcryptokit-ocaml libssl-ocaml libzarith-ocaml lynx lynx-common
0 upgraded, 5 newly installed, 0 to remove and 23 not upgraded.
Need to get 1,842 kB of archives.
After this operation, 6,744 kB of additional disk space will be used.
Do you want to continue? [Y/n] Y


mirageコマンドが実行出来るよう、eval $(opam env)を実行し環境変数を設定。

$ 
$ eval $(opam env)
$


ちなみに、MirageOSおよびOCamlコンパイラのバージョンは以下のとおり。
前回のHello World完了後から変わらず、MirageOSのバージョンは3.8.0、OCamlコンパイラのバージョンは4.10.0。

$ mirage --version
v3.8.0
$ 
$ opam switch list
#  switch   compiler          description
→  4.10.0   ocaml-base-compiler.4.10.0  4.10.0
   default  ocaml-system.4.08.1 default
$ 


Webサーバ static_website_tlsのインストール
下準備を終えたところで、Webサーバプログラム「static website tls」のコンパイルとインストールに進む。
前回同様、OCamlでWebサーバプログラムを1から書くのではなく、MirageOSの公式githubからホームディレクトリに持ち出す。
clone完了後、lsコマンドを打つとstatic_website_tlsディレクトリが作成されている事が確認出来る。
このstatic_website_tlsディレクトリ配下にディスパッチファイル(dispatch.ml)と構成ファイル(config.ml)が有り、この2つのファイルが保存されているディレクトリ内でインストール作業をする為、cdコマンドで移動する。

$ cd mirage-skeleton/applications/static_website_tls/
$
$ ls
config.ml  dispatch.ml  htdocs  tls
$


自分の環境では、前もってmirage-crypto-rng-mirageをインストールする。
実は、Webサーバの導入は成功するまで何度も何度も失敗。いづれもWebサーバの動作確認の際に、Webブラウザ上でテスト用HTMLファイル(Hello MirageOS World!)を表示させる事が出来なかった。
その際に吐かれたログは以下のとおりだった。

2020-07-26 08:02:11 +00:00: WRN [tcpip-stack-socket] error The default generator is not yet initialized.
To initialize the RNG with a default generator, and set up entropy collection and periodic reseeding as a background task, do the following:
  If you are using MirageOS, use the random device in config.ml: `let main = Mirage.foreign "Unikernel.Main" (random @-> job)`, and `let () = register "my_unikernel" [main $ default_random]`.
  If you are using Lwt, execute `Mirage_crypto_rng_lwt.initialize ()` at the beginning of your event loop (`Lwt_main.run`) execution.
  If you're using neither MirageOS nor lwt, there is no periodic reseeding. For an initial seed from getrandom(), execute `Mirage_crypto_rng_unix.initialize ()`. 
You can use `Mirage_crypto_rng.accumulate` and `Mirage_crypto_rng.reseed` to reseed the RNG manually. in callback


config.mlファイルに`let main = Mirage.foreign "Unikernel.Main" (random @-> job)`と`let () = register "my_unikernel" [main $ default_random]`を書けみたいな事を言っている為、何度もconfig.mlファイルに追記・修正・挙げ句の果てに上記2行だけのconfig.ml作成等をするも、事象に変化無し。
config.mlやdispatch.mlは諦めて、次に怪しいと思っていた箇所 RNG(random number generator)に着手。error The default generator is not yet initialized.と言っている為、RNG関連のパッケージがインストールされていないのであればインストールしてみよう...と言う事で、opam search rngで関係が有りそうなツールの検索とインストールの有無の確認結果、mirage-crypto-rng-mirageがヒットした。
未インストールとの事だった為、opam install mirage-crypto-rng-mirageでインストール。

$ opam install mirage-crypto-rng-mirage
The following actions will be performed:
  ? install eqaf                     0.7   [required by mirage-crypto]
  ? install mtime                    1.2.0 [required by mirage-crypto-rng]
  ? install mirage-crypto            0.8.1 [required by mirage-crypto-rng]
  ? install mirage-crypto-rng        0.8.1 [required by mirage-crypto-rng-mirage]
  ? install mirage-crypto-rng-mirage 0.8.1
===== ? 5 =====
Do you want to continue? [Y/n] Y
:
省略
:
? installed eqaf.0.7
? installed mirage-crypto.0.8.1
? installed mtime.1.2.0
? installed mirage-crypto-rng.0.8.1
? installed mirage-crypto-rng-mirage.0.8.1
Done.
$


mirage-crypto-rng-mirageのインストールは正常完了。ツールの追加インストールは想定外だったが、作業続行。
Virtioオプションを付けてmirage configureコマンドを叩き、コンパイルに必要なファイルを生成。
上記で作成したtup0インタフェースにIPアドレス192.168.122.100/24をアサイン。
GWの192.168.122.1は元から有ったブリッジインタフェースvirbr0にアサインされていたIPアドレス
HTTPおよびHTTPSのポート番号はMirageOSのWebサーバのデフォルト値と同じにつき、ここで指定しなくとも正常に動作すると思われる。

引き続き、make dependコマンドを打ち、依存関係の有るopamツールおよびUbuntuのパッケージを自動でインストール。
Package mirage-unikernel-hello-virtio does not exist, create as a NEW package? [Y/n]
では yキーを叩いてopamツールのインストールを進める。

$  mirage configure -t virtio --ipv4=192.168.122.100/24 --ipv4-gateway=192.168.122.1 --http=8080 --https=4433
$
$ make depend
opam pin add -k path --no-action --yes mirage-unikernel-https-virtio . && opam depext --yes --update mirage-unikernel-https-virtio ; opam pin remove --no-action 

mirage-unikernel-https-virtio
Package mirage-unikernel-https-virtio does not exist, create as a NEW package? [Y/n] y
[mirage-unikernel-https-virtio.~dev] synchronised from file:///home/hechtia/mirage-skeleton/applications/static_website_tls
[WARNING] Failed checks on mirage-unikernel-https-virtio package definition from source at
          file:///home/hechtia/mirage-skeleton/applications/static_website_tls:
  warning 37: Missing field 'dev-repo'
  warning 49: The following URLs don't use version control but look like version control URLs:
              "https://github.com/mirage/mirage-skeleton.git#master"
mirage-unikernel-https-virtio is now pinned to file:///home/hechtia/mirage-skeleton/applications/static_website_tls (version ~dev)
# Detecting depexts using vars: arch=x86_64, os=linux, os-distribution=ubuntu, os-family=debian
:
省略
:
? installed mirage-crypto-pk.0.8.1
? installed x509.0.11.2
? installed tls.0.12.3
? installed tls-mirage.0.12.3
? installed conduit-mirage.2.2.1
? installed cohttp-mirage.2.5.3
Done.
$


最後にmakeコマンドを打ち、Hello Worldのアプリケーションバイナリファイルhttps.virtioを生成。staticファイルも生成される。
仮想マシンのバイナリファイルsolo5-virtio-runは前回のHello Worldの際に生成済みにつき、今回は生成されない。
完了後、lsコマンドの実行でhttps.virtioが当フォルダ内に有る事を確認。

$ make
mirage build
Generating static1.ml
Generating static1.mli
Generating static2.ml
Generating static2.mli
config.exe: [WARNING] pkg-config solo5-bindings-virtio --variable=ld returned nothing, using ld
$
$ ls
_build       dune         dune-project       https.virtio  Makefile                            static1.ml   static2.mli
config.ml    dune.build   htdocs             key_gen.ml    mirage-unikernel-https-virtio.opam  static1.mli  tls
dispatch.ml  dune.config  https_libvirt.xml  main.ml       myocamlbuild.ml                     static2.ml
$


今回のWebサーバ、static website tlsとMirageOSとSolo5の関係を簡単に表現すると、以下の図のような感じ。
当記事で触れている箇所を赤枠で示している。
OSの中にOSが有るのは変に見えるが、本来はXenなどHypervisor上で動作する。
MirageOSとWebサーバプログラムは1対1で動作する。よってDNSサーバプログラムや他のプログラムをMirageOS上で動作させたい場合は、プログラムを動作させる為のMirageOSが1つづつ必要となる。




Webサーバプログラムの実行
Webサーバプログラム、static website tlsの実行まで辿り着いた。Webサーバの起動後、LynxというテキストベースのWebブラウザで動作確認。
仮想マシンバイナリファイルsolo5-virtio-runでアプリケーションバイナリhttp.virtioを実行させる。
Webブラウザ上で「Hello Mirage World!」が表示されれば、Webブラウザプログラムの生成とHTTP/HTTPSアクセスは成功となる。

$ sudo /home/hechtia/.opam/4.10.0/bin/solo5-virtio-run -n tap0 https.virtio
+ exec qemu-system-x86_64 -cpu Westmere -m 128 -nodefaults -no-acpi -display none -serial stdio -device virtio-net,netdev=n0 -netdev 

tap,id=n0,ifname=tap0,script=no,downscript=no -device isa-debug-exit -kernel /home/hechtia/mirage-skeleton/applications/static_website_tls/https.virtio
            |      ___|
  __|  _ /  |  _ / __ /
/__ / (   | | (   |  ) |
____//___/ _|/___/____/
Solo5: Bindings version v0.6.5
Solo5: Memory map: 128 MB addressable:
Solo5:   reserved @ (0x0 - 0xfffff)
Solo5:       text @ (0x100000 - 0x419fff)
Solo5:     rodata @ (0x41a000 - 0x4a5fff)
Solo5:       data @ (0x4a6000 - 0x6d3fff)
Solo5:       heap >= 0x6d4000 < stack < 0x8000000
Solo5: Clock source: TSC, frequency estimate is 2296908200 Hz
Solo5: PCI:00:02: virtio-net device, base=0xc000, irq=10
Solo5: PCI:00:02: configured, mac=52:54:00:12:34:56, features=0x79bfffe7
Solo5: Application acquired 'service' as network device
2020-07-26 08:54:12 -00:00: INF [netif] Plugging into service with mac 52:54:00:12:34:56 mtu 1500
2020-07-26 08:54:12 -00:00: INF [ethernet] Connected Ethernet interface 52:54:00:12:34:56
2020-07-26 08:54:12 -00:00: INF [ARP] Sending gratuitous ARP for 192.168.122.100 (52:54:00:12:34:56)
2020-07-26 08:54:12 -00:00: INF [udp] UDP interface connected on 192.168.122.100
2020-07-26 08:54:12 -00:00: INF [tcpip-stack-direct] stack assembled: mac=52:54:00:12:34:56,ip=192.168.122.100
2020-07-26 08:54:12 -00:00: INF [https] listening on 4433/TCP
2020-07-26 08:54:12 -00:00: INF [http] listening on 8080/TCP


コマンドsudo /home/hechtia/.opam/4.10.0/bin/solo5-virtio-run -n tap0 https.virtioの実行後、Webサーバのログが出力される。
[https] listening on 4433/TCPと[http] listening on 8080/TCPで停止し、リスニングの状態になりWebブラウザからのアクセスを待つ。
出力内容から分かるとおり、このWebサーバではHTTPとHTTPSの両方が立ち上がっているが、外部からのアクセスはHTTPで受け、Webサーバ内部でHTTPSに渡されるという仕組みになっている。

ここでTera Termなどターミナルツールをもう1枚立ち上げMirageOSを立ち上げているVirtualboxゲストOS(ここではUbuntu Linux)にログインし、LynxWebブラウザにアクセスを試みると...

$
$ lynx http://192.168.122.100:8080

下の画像内に表示されているとおり、「Hello MirageOS World!」の表示に成功。
ここに辿り着くまで、長かった......



WebブラウザLynxでアクセスした際のログは、以下のとおり。
HTTPからHTTPSに渡される様子とSSLハンドシェイクの簡易なログが出力されている。

2020-07-26 08:54:34 -00:00: INF [https] [1] serving //192.168.122.100:8080/.
2020-07-26 08:54:34 -00:00: INF [http] [//192.168.122.100:8080/] -> [https://192.168.122.100:4433/]
2020-07-26 08:54:34 -00:00: INF [https] [1] closing
2020-07-26 08:54:36 -00:00: INF [handshake] cipher AES_128_GCM_SHA256
2020-07-26 08:54:36 -00:00: INF [handshake] group X25519
2020-07-26 08:54:47 -00:00: INF [https] [2] serving //192.168.122.100:4433/.
2020-07-26 08:54:47 -00:00: INF [https] [2] closing


今回の振り返り。VirtualboxのゲストOS内の話ではあるが、Tutorial用プログラムのWebサーバ「static_website_tls」の実行と、HTTP/HTTPSアクセスおよびWebブラウザLynxでHello MirageOS World!の表示に成功した。
外部からのアクセスも可能のようだが、その際は自己証明書ではなく信頼出来る認証局サーバ証明書が必要となる。
海外のブログにLet's Encryptでの事例が有り(https://www.davidudelson.com/blog/2017/06/13/aws-unikernel-guide/)、自分も試してみたものの今のところ成功していない。



リンク先
https://mirage.io/ Mirage OS
https://github.com/mirage Mirage OS (github)
https://ocaml.org/ OCaml
https://releases.ubuntu.com/20.04/ Ubuntu 20.04
https://github.com/Solo5/solo5 Solo5
https://lynx.invisible-island.net/lynx.html Lynx


MirageOCaml、他各ツールの最新バージョンは以下のリンク先で検索し確認可能。
画面右上の「Search Packages」の窓内にパッケージ名を入力し検索。
https://opam.ocaml.org/packages/


過去のMirageOSのエントリ
https://debslink.hatenadiary.jp/entry/20200718/1595076105 前回:Ubuntu 20.04でMirageOS Unikernel
https://debslink.hatenadiary.jp/entry/20200526/1590495778 前々回:MirageOS Unikernelで通信プログラムの実行
https://debslink.hatenadiary.jp/entry/20200516/1589616362 初回:MirageOSのインストールとHello Worldの実行


自分にとって、UnikernelsやMirageOSの始めの一歩となったサイト (MirageOS のインストールから Hello World までを試す)
https://qiita.com/t-imada/items/6ee299653ac063532b4f

Ubuntu 20.04でMirageOS Unikernel

2ヶ月前にMirageOS Unikernelに出会って以降、Virtualbox環境ではKemp LoadMasterを立ち上げてロードバランサの挙動の勉強を進める傍ら、時々Ubuntu 18.04.3を立ち上げてはMirageOSで遊んでいた。たまにMirageOS熱が再来する...といった感じだ。
前回はUbuntu 18.04環境にてMirageOSを動作させたが、今年の4月にリリースされた最新版の20.04でも正常に動作するか、OCamlMirageのバージョンを最新版にしても正常に動作するか気になった。
今回は、Ubuntu Linuxの最新バージョン20.04に、MirageOSおよびOCamlの最新版のインストールとHello Worldの実行を試みた。

※前回:https://debslink.hatenadiary.jp/entry/20200516/1589616362
※前々回:https://debslink.hatenadiary.jp/entry/20200526/1590495778



当方の環境
ホストOS:Windows7 32bit版 / RAM: 4GB / CPU: Intel Core i3-2350M 2.30GHz
ゲストOS:Ubuntu Server 20.04 x86 64bit版
Virtualbox 5.2.32
Ubuntu Serverは既にデプロイ済みである事とする
PCのCPU仮想化支援機構はBIOSにて既に有効設定済みである事とする



入れたいバージョン
mirage 3.8.0
ocaml-base-compiler 4.10.0
OCaml 4.12.0



MirageOSのインストール手順は、前回の記事(https://debslink.hatenadiary.jp/entry/20200516/1589616362)の内容に従った。
今回も、自分の環境ではhvtオプション下でのHello Worldが正常に実行出来なかった為、VirtioオプションでコンパイルHello World実行プログラムを生成させて実行した。
MirageOSとは何ぞや、OCamlとは何ぞや...に関しては、当記事下部のリンク先を参照。



CPU仮想化支援機構の有効無効の確認
前回のバージョン18.04.3ではCPU仮想化支援機構が有効であるか確認で使用するコマンドlscpuはデフォルトでインストールされていなかった為に、別途apt-getコマンドでインストールしたが、現バージョン20.04ではインストール済みにつき、パッケージリストの更新のみ実行した。

$ sudo apt-get update
$ sudo apt-get upgrade

lscpuコマンドを叩き、CPU仮想化支援機構が有効になっている事を確認。
自分の環境では、Virtualization typeがnone等ではなくVT-xやfull、Hypervisor vendorがKVMになっている。

$ lscpu
Architecture:                    x86_64
CPU op-mode(s):                  32-bit, 64-bit
Byte Order:                      Little Endian
:
:
Hypervisor vendor:   KVM
Virtualization type: full
:


以下のコマンドを打ち、KVMモジュールを読み込ませる。

$ sudo modprobe kvm

MirageOSインストールの準備
MirageOS上で実行するプログラムはOCamlという関数型プログラミング言語で記述される。MirageOSのインストール前に、OCamlおよびコンパイラocamlと管理ツールopam、それらを動作させる為に必要なツールをインストール。
前回同様に外部のリポジトリを利用する為、add-apt-repository ppa:avsm/ppaを最初に打ったが...

$ sudo add-apt-repository ppa:avsm/ppa
 Latest stable versions of OCaml and OPAM.
 More info: https://launchpad.net/~avsm/+archive/ubuntu/ppa
Press [ENTER] to continue or Ctrl-c to cancel adding it.

Hit:1 http://jp.archive.ubuntu.com/ubuntu focal InRelease
Hit:2 http://jp.archive.ubuntu.com/ubuntu focal-updates InRelease
Hit:3 http://jp.archive.ubuntu.com/ubuntu focal-backports InRelease
Hit:4 http://jp.archive.ubuntu.com/ubuntu focal-security InRelease
Ign:5 http://ppa.launchpad.net/avsm/ppa/ubuntu focal InRelease
Err:6 http://ppa.launchpad.net/avsm/ppa/ubuntu focal Release
  404  Not Found [IP: 2001:67c:1560:8008::15 80]

E: The repository 'http://ppa.launchpad.net/avsm/ppa/ubuntu focal Release' does not have a Release file.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.
$


何と、404 Not Foundときた。
「The repository 'http://ppa.launchpad.net/avsm/ppa/ubuntu focal Release' does not have a Release file.」と言っているではないか !
http://ppa.launchpad.net/avsm/ppa/ubuntuWebブラウザでアクセスすると、確かにfocalディレクトリが存在しない。focalとはUbuntu 20.04のコードネームFocal Fossaに由来する。
18.04や16.04など他のバージョンの場合、http://ppa.launchpad.net/avsm/ppa/ubuntu配下にコードネーム由来のディレクトリ名を当てられたディレクトリが有るのだが、20.04にはまだ存在しない。
Ubuntu 20.04環境への導入は時期早々か?
試しに、外部のリポジトリを使用せずに、行けるところまで行ってみよう。


...という事で、前回同様にOCamlやopam、必要なツールのインストールを進める。

$ sudo apt-get install opam ocaml gcc make bubblewrap m4 pkg-config qemu-kvm libvirt-bin bridge-utils virt-manager libseccomp-dev
:
Package libvirt-bin is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

E: Package 'libvirt-bin' has no installation candidate
E: Unable to locate package bridge-utills
$ 

エラーを吐いてapt-getが終了した。Googleで"Ubuntu 20.04 libvirt-bin"で検索したところ、libvirt-binは18.04で削除されたようだ。
代わりに、libvirt-daemon-systemとlibvirt-clients を入れる。
https://symfoware.blog.fc2.com/blog-entry-2446.html
https://askubuntu.com/questions/1089753/kvm-qemu-installation-issue-18-10

bridge-utillsはtypoだった。
bridge-utilsに修正し、libvirt-binの代わりに提示されたツールlibvirt-daemon-systemとlibvirt-clientsを指定し、再度実行。

$ sudo apt-get install opam ocaml gcc make bubblewrap m4 pkg-config qemu-kvm bridge-utils virt-manager libvirt-daemon-system libvirt-clients libseccomp-dev
:
:
Unpacking bridge-utils (1.6-2ubuntu1) ...
Setting up bridge-utils (1.6-2ubuntu1) ...
Processing triggers for man-db (2.9.1-1) ...
$ 

今度は正常に完了した。



opamの環境設定
ocamlおよびopamのインストール完了後、opamの環境設定に進む。
opam init実行中に2度質問される。
Do you want opam to modify ~/.profile? [N/y/f]
(default is 'no', use 'f' to choose a different file) では、Enterキーを叩いて先に進める。
A hook can be added to opam's init scripts to ensure that the shell remains in sync with the opam environment when theyare loaded. Set that up? [y/N]
では、Enterキーを叩いて先に進める。

$ opam init
[NOTE] Will configure from built-in defaults.
Checking for available remotes: rsync and local, git, mercurial, darcs. Perfect!

<><> Fetching repository information ><><><><><><><><><><><><><><><><><><><><><>
]Processing  1/1: [default: http][default] Initialised

<><> Required setup - please read <><><><><><><><><><><><><><><><><><><><><><><>
:
:
Do you want opam to modify ~/.profile? [N/y/f]
(default is 'no', use 'f' to choose a different file) 

A hook can be added to opam's init scripts to ensure that the shell remains in sync with the opam environment when they
are loaded. Set that up? [y/N]

<><> Processing actions <><><><><><><><><><><><><><><><><><><><><><><><><><><><>
? installed base-bigarray.base
? installed base-threads.base
? installed base-unix.base
? installed ocaml-system.4.08.1
? installed ocaml-config.1
? installed ocaml.4.08.1
Done.
# Run eval $(opam env) to update the current shell environment
$ 

「Run eval $(opam env) to update the current shell environment」と言っている為、eval $(opam env)を実行し環境変数を設定。

$ 
$ eval $(opam env)
$


ここで、インストールされたopamコンパイラのバージョンを確認。
前回はバージョン4.05.0だったが今回は4.08.1にバージョンが上がっていて、MirageOSの動作に必要とするバージョンを満たしているが、もっと新しいバージョンで動かしたい。
よって、バージョンを指定しopam switch createコマンドを実行。
今回は最新版の4.10.0を入れてみる。
自分の環境では、Processing 4/12: [ocaml-base-compiler: make world]で40分程待たされた。

$ opam switch list
#  switch   compiler             description
→  default  ocaml-system.4.08.1  default
$ 
$ 
$ opam switch create 4.10.0
<><> Gathering sources ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
Processing  5/6: [ocaml-base-compiler.4.10.0: dl]
Processing  6/6: [ocaml-base-compiler.4.10.0: dl]
[ocaml-base-compiler.4.10.0] downloaded from cache at https://opam.ocaml.org/cache
Processing  6/6:
<><> Processing actions <><><><><><><><><><><><><><><><><><><><><><><><><><><><>
Processing  4/12: [ocaml-base-compiler: ./configure]
Processing  4/12: [ocaml-base-compiler: make world]
Processing  4/12: [ocaml-base-compiler: make world.opt]
? installed base-bigarray.base
? installed base-threads.base
? installed base-unix.base
? installed ocaml-base-compiler.4.10.0
? installed ocaml-config.1
? installed ocaml.4.10.0
Done.
# Run eval $(opam env) to update the current shell environment
$ 

インストール後、opamのコンパイラのバージョンが4.10.0になっている事を確認。
しかし、上記のログを見るとOCamlのバージョンは4.10.0でインストールされた事が分かる。どうやらこちらでは指定出来ず、opamのバージョンと連動しているのだろう。

$ opam switch list
#  switch   compiler                    description
→  4.10.0   ocaml-base-compiler.4.10.0  4.10.0
   default  ocaml-system.4.08.1         default
$ 

MirageOSのインストール
次に、opam install mirageコマンドを打ち、MirageOSとMirageOSの実行に必要なツールをインストール。
自分の環境では、完了まで約30分程要した。

$ opam install mirage
The following actions will be performed:
  ? install dune              2.6.1  [required by mirage]
  ? install seq               base   [required by fmt]
  ? install cmdliner          1.0.4  [required by functoria]
  ? install conf-m4           1      [required by ocamlfind]
  ? install ocamlbuild        0.14.0 [required by astring, bos]
  ? install stdlib-shims      0.1.0  [required by mirage]
  ? install result            1.5    [required by rresult, fpath, ptime]
:
省略
:
  ? install mirage-runtime    3.8.0  [required by mirage]
  ? install bos               0.2.0  [required by mirage]
  ? install functoria         3.1.1  [required by mirage]
  ? install mirage            3.8.0
===== ? 31 =====
Do you want to continue? [Y/n] y
:
省略
:
? installed mirage-runtime.3.8.0
? installed ptime.0.8.5
? installed rresult.0.6.0
? installed bos.0.2.0
? installed functoria.3.1.1
? installed mirage.3.8.0
Done.
$ 

インストール完了後、opam listコマンドを実行。
これまでの流れでインストールされたMirageOSやOCamlやopam、関連するツールの一覧とバージョンが出力される。

$ opam list
# Packages matching: installed
# Name              # Installed # Synopsis
astring             0.8.4       Alternative String module for OCaml
base-bigarray       base
base-bytes          base        Bytes library distributed with the OCaml compiler
base-threads        base
base-unix           base
:
省略
:
mirage              3.8.0       The MirageOS library operating system
mirage-runtime      3.8.0       The base MirageOS runtime library, part of every MirageOS unikernel
mmap                1.1.0       File mapping functionality
ocaml               4.10.0      The OCaml compiler (virtual package)
ocaml-base-compiler 4.10.0      Official release 4.10.0
:
省略
:
seq                 base        Compatibility package for OCaml's standard iterator type starting from 4.07.
stdlib-shims        0.1.0       Backport some of the new stdlib features to older compiler
topkg               1.0.1       The transitory OCaml software packager
$ 

インストールされたMirageOSのバージョンを確認。

$ mirage --version
v3.8.0
$


Hello Worldプログラムのコンパイルとインストール
MirageOSやその周辺のツールのインストールは、ほぼ自分が希望するバージョンでインストール出来た。
次は、Hello Worldプログラムのコンパイルとインストールに進む。

前回同様、OCamlHello Worldプログラムを1から書くのではなく、MirageOSの公式githubからホームディレクトリに持ち出す。
clone完了後、lsコマンドを打つとmirage-skeletonディレクトリが作成されている事が確認出来る。
このmirage-skeletonディレクトリ配下にHello Worldのアプリケーションファイル(unikernel.ml)と構成ファイル(config.ml)が有る為、cdコマンドで移動する。

$ git clone https://github.com/mirage/mirage-skeleton.git
Cloning into 'mirage-skeleton'...
remote: Enumerating objects: 3321, done.
remote: Counting objects:   0% (1/3321)
remote: Counting objects:  1% (2/3321)
remote: Counting objects:   2% (3/3321)
:
省略
:
Resolving deltas:  99% (1639/1665)
Resolving deltas: 100% (1642/1665)
Resolving deltas: 100% (1665/1665), done.
$ 
$ ls
mirage-skeleton
$
$ cd mirage-skeleton/tutorial/hello
$
$ ls
config.ml  unikernel.ml
$


今回もVirtioオプションを付け、Hello Worldプログラムのコンパイルを実行。
コンパイル完了まで3つのコマンドを打つ必要が有る。
最初はVirtioオプションを付けてmirage configureコマンドを叩き、コンパイルに必要なファイルを生成させる。

$ mirage configure -t virtio
Scanned 0 directories          Done: 0/0 (jobs: 0)       hoge@hoge:~/mirage-skeleton/tutorial/hello$ 
$ 
$ ls
_build     dune        dune.config   hello_libvirt.xml  main.ml   mirage-unikernel-hello-virtio.opam  unikernel.ml
config.ml  dune.build  dune-project  key_gen.ml         Makefile  myocamlbuild.ml
$


次にmake dependコマンドを打ち、依存関係の有るopamツールおよびUbuntuのパッケージを自動でインストール。
make depend実行中に2度質問される。
Package mirage-unikernel-hello-virtio does not exist, create as a NEW package? [Y/n]
では yキーを叩いてopamツールのインストールを進める。
Opam plugin "depext" is not installed. Install it on the current switch? [Y/n]
では yキーを叩いてdepextのインストールを進める。

$ make depend
opam pin add -k path --no-action --yes mirage-unikernel-hello-virtio . && opam depext --yes --update mirage-unikernel-hello-virtio ; opam pin remove --no-action 

mirage-unikernel-hello-virtio
Package mirage-unikernel-hello-virtio does not exist, create as a NEW package? [Y/n] y
Processing: [mirage-unikernel-hello-virtio.~dev: rsync]
[mirage-unikernel-hello-virtio.~dev] synchronised from file:///home/hoge/mirage-skeleton/tutorial/hello
[WARNING] Failed checks on mirage-unikernel-hello-virtio package definition from source at
          file:///home/hoge/mirage-skeleton/tutorial/hello:
  warning 37: Missing field 'dev-repo'
  warning 49: The following URLs don't use version control but look like version control URLs:
              "https://github.com/mirage/mirage-skeleton.git#master"
mirage-unikernel-hello-virtio is now pinned to file:///home/hoge/mirage-skeleton/tutorial/hello (version ~dev)
Opam plugin "depext" is not installed. Install it on the current switch? [Y/n] y 
The following actions will be performed:
  ? install opam-depext 1.1.3

<><> Gathering sources ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
:
省略
:
? installed ocaml-freestanding.0.6.0
? installed mirage-solo5.0.6.2
? installed mirage-bootvar-solo5.0.6.0
Done.
$ 


最後にmakeコマンドを打ち、Hello Worldのアプリケーションバイナリファイルhello.virtioと、仮想マシンのバイナリファイルsolo5-virtio-runを生成。
完了後、lsコマンドの実行でhello.virtioが当フォルダ内に有る事を確認。
※ここで言うアプリケーションバイナリファイルとはMirageOS側、仮想マシンとはUbuntu側を指す。
※Solo5とはUnikernel向けのサンドボックス環境の事。Unikernelを動作させる為のセキュアな環境と、UnikernelとSolo5が接する箇所の共通的なAPを提供する。


Hello WorldとMirageOSとSolo5の関係を簡単に表現すると、以下の図のような感じ。
当記事で触れている箇所を赤枠で示した。
OSの中にOSが有るのは変に見えるが、本来はXenなどHypervisor上で動作する。
MirageOSとHello Worldプログラムは1対1で動作する。よってFTPプログラムやWebサーバプログラムを動作させたい場合は、FTPプログラムを動作させる為のMirageOS、Webブラウザを動作させる為のMirageOSが必要となる。


Linux環境でソースから./configure、make、make installでツールをインストールする時のmakeとは異なり、ほんの2~3秒程で終了する。
lsでhello.virtioファイルが生成されている事を確認すれば、長かったHello Worldコンパイルとインストール作業は完了。
今時のPCだったらもっともっと早く完了していただろうけど。

$ make
mirage build
Scanned 0 directories      Done: 0/0 (jobs: 0)      config.exe: [WARNING] pkg-config solo5-bindings-virtio --variable=ld returned nothing, using ld
$
$ ls
_build     dune        dune.config   hello_libvirt.xml  key_gen.ml  Makefile                            myocamlbuild.ml
config.ml  dune.build  dune-project  hello.virtio       main.ml     mirage-unikernel-hello-virtio.opam  unikernel.ml
$

Hello Worldプログラムの実行
ついにHello World実行まで漕ぎ着けた。

次は動作確認。
仮想マシンバイナリファイルsolo5-virtio-runでアプリケーションバイナリhello.virtioを実行させる。
アスキーアートのロゴの出力とhelloが4回出力されれば、MirageOSのインストールおよびHello Worldプログラムの生成は成功となる。

$ solo5-virtio-run hello.virtio
+ exec qemu-system-x86_64 -cpu Westmere -m 128 -nodefaults -no-acpi -display none -serial stdio -device isa-debug-exit -kernel /home/hoge/mirage-skeleton/tutorial/hello/hello.virtio

            |      ___|
  __|  _ /  |  _ / __ /
/__ / (   | | (   |  ) |
____//___/ _|/___/____/
Solo5: Bindings version v0.6.5
Solo5: Memory map: 128 MB addressable:
Solo5:   reserved @ (0x0 - 0xfffff)
Solo5:       text @ (0x100000 - 0x1d3fff)
Solo5:     rodata @ (0x1d4000 - 0x206fff)
Solo5:       data @ (0x207000 - 0x2a6fff)
Solo5:       heap >= 0x2a7000 < stack < 0x8000000
Solo5: Clock source: TSC, frequency estimate is 2308335130 Hz
2020-07-18 06:28:44 -00:00: INF [application] hello
2020-07-18 06:28:45 -00:00: INF [application] hello
2020-07-18 06:28:46 -00:00: INF [application] hello
2020-07-18 06:28:47 -00:00: INF [application] hello
Solo5: solo5_exit(0) called
$ 
$

Hello Worldの実行は成功、前回のMitageOS バージョン3.7.7との間で実行時間以外の出力内容は同じ。

今回の振り返り。外部リポジトリppa:avsm/ppaを使わなくても、OCamlやopamのインストールが出来た。
MirageOSのバージョンは指定しなくても最新版の3.8.0がインストールされた。
opamのコンパイラはこちらで指定可能(自動でインストールされた後、導入したいバージョンを後で指定しインストール)だったものの、 OCaml のバージョンはopamのコンパイラと同じバージョンのものが自動でインストールされた。
次回は簡単なFTPサーバもしくはWebサーバをMirage OSで立てたい。業務でUnikernelやMirageOSの案件にアサインされる事は無いだろうから、急がずゆっくりと...





リンク先
https://mirage.io/ Mirage OS
https://github.com/mirage Mirage OS (github)
https://ocaml.org/ OCaml
https://releases.ubuntu.com/20.04/ Ubuntu 20.04
https://github.com/Solo5/solo5 Solo5


MirageOCaml、他各ツールの最新バージョンは以下のリンク先で検索し確認可能。
画面右上の「Search Packages」の窓内にパッケージ名を入力し検索。
https://opam.ocaml.org/packages/


過去のMirageOSのエントリ
https://debslink.hatenadiary.jp/entry/20200726/1595768920 追記:MirageOS UnikernelでWebサーバ
https://debslink.hatenadiary.jp/entry/20200526/1590495778 前々回:MirageOS Unikernelで通信プログラムの実行
https://debslink.hatenadiary.jp/entry/20200516/1589616362 初回:MirageOSのインストールとHello Worldの実行


自分にとって、UnikernelsやMirageOSの始めの一歩となったサイト (MirageOS のインストールから Hello World までを試す)
https://qiita.com/t-imada/items/6ee299653ac063532b4f

OpenFlowは生きていた

OpenFlowという通信プロトコルに関する独り言。

自分のブログの過去の記事を読んでいたところ、Buffaloの家庭用ルータBHR-4GRVにOpen vSwitchをインストールした記事に出くわした。2014年~2015年の話。
自宅環境で再現するにあたり、srchack.orgの「おっさんの小遣いで実現したOpenFlowネットワーク」には大変お世話になった。そのサイトではOpenFlowの盛り上がりが最高潮だった2012年にOpenFlowの記事を載せていたと思うが、自分がOpenFlowに触れ始めたのが2014年で、OpenFlowが下火になってきた頃の事。その頃には多くの事例が揃っていた為すんなりと動作確認まで出来た記憶がある。
ここ数年、IT系、通信技術系のイベントやセミナーで取り上げられなくなって久しいOpenFlow、そして当時OpenFlowと同列に語られていたSDN。SDNはデータセンタのネットワークにて導入がぼちぼちと進められ、2010年代後半よりSDNはデータセンタの外にSDWAN(※1)として進出していったが、OpenFlowは大注目の通信プロトコルだったものの導入例は極めて少なく、次第に語られる事すら無くなり、SDNだのOpenFlowだの騒いでいた人達は次第にOpenFlowの夢から覚めていった。



...と当時を思い出していくうちにOpenFlowの現状を知りたくなった。
本当は自分が導入事例を知らなかっただけで実は色々な場所で動いているかも知れないし、逆に、コントローラを含め、開発は止まり公式サイトは数年間更新無し、または既に閉鎖されているかもしれない。気になった為、OpenFlowの現状を探るべくGoogle先生のお力を借りて調べたところ(※2)、まだしぶとく生きている事が判明。
しぶとく生きていたという表現は、末期のTurbo Linuxみたいな感じがするので不適切かも知れない。
それどころか、一部のコミュニティでは再び盛り上がりを見せつつあるように感じられた。



近年はFaucetプロジェクト(https://faucet.nz/)を中心に活動が活発になってきているように見えた。いや、そう見えるのは自分だけかも知れない。
Faucetは「いや、今まで普通に活動してましたけど」と言うだろう。他のOpenFlowコントローラのコミュニティもそう言うだろうが勢いを感じるのはFaucetの方だった。



まだ情報を掴み切れていないが、今のOpenFlow界隈はこんな感じに見える。
・2017年にFaucetConが開催されて以降、GoogleやArista社だけでなく様々な企業や団体がFaucetプロジェクトに参加している。
・いやいや参加企業や団体は少ないでしょうと思いきや、Cisco Systems、HPE、Allied Telesys等の大手の通信機器ベンダが参加している。
・Lagopusプロジェクト(NTT)も参加している。(※3)
IIJにてFaucetを活用したIXPオペレータの為の研究プロジェクトが立ち上がっている。
・OpenFlowの最新バージョンは1.5.1のようだ。(※4)
・他のOpenFlowコントローラ、MininetやOpenDaylightはまだ続いている模様。



しかし気になる点が1つ。
2018年に、ONFは "OpenFlow is the Past as ONF Announces Stratum Project to Redefine SDN" とOpenFlowは過去の物と言っている。
ONFのサイト内に有ったOpenFlowのページは、今は見えなくなっている。
FaucetはOpenFlowにとって最後の砦なのか? 
セミナーの開催やINTEROPでの展示等、かつてのような大盛り上がりはもう無いだろうが、オープンソースカンファレンス等でデモ展示が有ったら見に行きたい。



自宅環境でFaucetの環境を作る事が可能か、Faucetのドキュメントサイトを確認したところ、Faucet on Lagopusの項目を見つけた。
"FAUCET is supported as of Lagopus 0.2.11"の記載が有るが、おそらくLagopus RouterではなくLagopus Switchの方だろう。だったら自宅環境で動作実績が有る為、Faucetをかじってみる事は可能だ。
数年もの間開いていない参考書、マスタリングTCP/IP OpenFlow編が家の中のどこかに有る。OpenFlowのバージョン毎に仕様がコロコロ変わっていたと思うが、概要復習の為に探してみる。





※1 SDNイコールSDWANではない
※2 Googleで検索しただけ
※3 そう言えばLagopus SwitchってOpenFlowスイッチだったな...
※4 Faucetではバージョン1.3がサポート対象


https://www.opennetworking.org/ Open Networking Foundation
https://faucet.nz/ Faucet Open source SDN Controller
https://docs.faucet.nz/en/latest/vendors/lagopus/README_Lagopus.html Faucet on Lagopus
https://eng-blog.iij.ad.jp/archives/5022 FAUCET コントローラ: OpenFlowが生き残っている理由
https://www.opennetworking.org/wp-content/uploads/2014/10/openflow-switch-v1.5.1.pdf OpenFlow Switch Specification


https://sky.ap.teacup.com/debslink/1393.html Ryu SDN Frameworkの導入
https://sky.ap.teacup.com/debslink/1396.html BHR-4GRVをOpenFlowスイッチ化 ①
https://sky.ap.teacup.com/debslink/1398.html BHR-4GRVをOpenFlowスイッチ化 ②
https://sky.ap.teacup.com/debslink/1397.html BHR-4GRVをOpenFlowスイッチ化 ③
https://sky.ap.teacup.com/debslink/1400.html BHR-4GRVをOpenFlowスイッチ化 ④


http://www.srchack.org/orc12/ 当時お世話になったサイト「おっさんの小遣いで実現したOpenFlowネットワーク」
https://qiita.com/hakua-doublemoon/items/7122e43dbce4a3a70aa7 OpenFlow controller「Faucet」を触ってみた
https://qiita.com/ttsubo/items/9062addd7c24d5adfcf3 5分でわかる、これまでのSDN動向
http://shun3382.hatenadiary.jp/entry/2015/03/11/124637 書きかけ 自作OpenFlow Controller(OpenFlow 1.5について①)


https://www.opendaylight.org/ OpenDaylight
http://mininet.org/ Mininet

kemp LoadMasterによる負荷分散設定 - HTTPSサーバ編

飽きずに今回も、Kemp Technologies社のロードバランサ kemp LoadMasterの仮想アプライアンス版いじり。Webサーバ2台の負荷分散設定の後、クライアントからLB間のHTTPSのやりとり(SSLハンドシェイク)をWiresharkで覗いてみた。
4回連続のkemp LoadMasterネタ。
素朴な感じのGUIにはもう慣れた。
ここまで来たらもう「かじってみた」レベルではない熱の入れ様。スペック面で貧弱な自宅環境にてVirtualboxとKemp LoadMasterとWiresharkを同時稼動が可能か心配であったが、問題無く検証出来た。
今後も、みやたひろしさんの参考書(サーバ負荷分散入門、ソフトバンククリエイティブ刊)の内容を基にKemp LoadMasterをいじくり回し、勤務先などでF5 BIG-IP VEやA10 vThunder等と一緒にKemp LoadMasterを提案出来るくらいにまで理解するようにしたい。新人を対象とした教育環境への導入ならLoadMasterで充分な感じがする。予算に余裕が有ってF5 BIG-IP VEのラボライセンス買えるよと言われたら、そっちに流れるかも知れないが。



当方の環境
・ホストOS:Windows7 32bit
Virtualbox 5.2.32
・ゲストOS:Kemp LoadMaster 7.2.50.0.18765.RELEASE
・Web Server:IWS 07.00 (Android端末2台にインストール)
・WLANでホストOSとAndroid端末3台を接続
・LoadMaster側は既にホスト名とインタフェースの設定は終えている状態
・クライアント機: Windows10 64bit (嫁用)



設定方針
・負荷分散方式は、今回はラウンドロビン
・セッション維持方式は、今回は送信元IPアドレス
・細かな設定値は変更せずデフォルト値のまま
・クライアント~LB間はHTTPS、LB~WEBサーバ間はHTTP通信
HTTPSサーバと銘打っているが、実際はLBのバーチャルサーバがhttpsの受け口である




SSLの設定
最初にSSLアクセラレーション設定を有効にする。今回はクライアント~LB間はHTTPS通信をする。
SSL Acceleration Enabled:チェックを入れる
Supported Protocols:TSL1.0とTLS1.1とTLS1.2にチェックを入れる
Certificates:今のところオレオレ証明書を使うため、そのまま。※Self Signed Certificate in use.の表示有り
Cipher Set:そのまま
Client Certificates:No Client Certificates requiredのまま
Strict Transport Security Heade:Don't add Strict Transport Security Headerのまま



バーチャルサーバの設定
設定内容は前回とほぼ同じ。

[Basic Properties]
Service TypeをHTTP-HTTP/2-HTTPSに変更すると、[Advanced Properties]の表示内容がHTTP/HTTPSに特化した内容に変わる。
核設定項目から判断すると、F5 BIG-IPで言う「HTTP Profile」に相当するものと思われる。
Service Name:上記で設定したService Nameが表示されている
Alternate Address:空欄
Service Type:HTTP-HTTP/2-HTTPSを選択
Activate or Deactivate Service:チェックを入れる


[Standard Options]
Kemp LoadMasterでは、Persistence(セッション維持)とScheduling Method(負荷分散方式)が同じStandard Option内で設定される。
設定項目およびオプション値は最低限のように見えるが、Persistenceは種類が多い。


Transparency:チェック無し
Subnet Originating Requests:チェック無し
Extra Ports:空欄
Persistence Options Mode:Source IP ddressを選択
Persistence Options Timeout:6 Minutesのまま
Scheduling Methos:round robinを選択
Idle Connection Timeout:空欄
Quarity of Service:Normal-Service


[Advanced Properties]
Content Switching:Disabledのまま
HTTP Selection Rules:そのまま
HTTP Header Modifications:そのまま
Responce Body Modification:そのまま
Port Following:そのまま
Enable HTTP/2 Stack:チェック無し
Enable Caching:チェック無し
Enable Compression:チェック無し
Detect Malicious Requests:チェック無し
Enable Multiple Connect:チェック無し
Add Header to Request:空白
Copy Header in Request:空白
Add HTTP Headers:Legacy Operation(X-Forwarded-For)のまま
"Sorry" Server:http://192.168.3.254 Port 12345 を入力後、Set Server Adderessをクリック



物理サーバの設定
F5 BIG-IPと同様に、バーチャルサーバの次に物理サーバの設定をする。
トラフィックを受け取ったバーチャルサーバは、ラウンドロビンや最小コネクション数など設定された負荷分散方式により、物理サーバにトラフィックを割り振る。
今回の負荷分散設定はラウンドロビン、パーシステンス設定は送信元IPアドレスとした。

[Real Servers]
Add Newをクリック

Please Specify the Parameters for the Real Serverの画面にて
Allow Remote Addresses:チェック無し
Real Server Address:HTTPSサーバのIPアドレスを入力
Port:12345
Forwarding method:nat
Weight:1000のまま
Connection Limit:空欄
Add This Real Serverをクリックし設定を保存。
Backをクリック
負荷分散対象のFTPサーバの台数分、Real ServerをAdd Newから作成する
自分の環境では、2台(192.168.3.25と192.168.3.26)を作成


Real Serversの欄に戻り
Real Server Check Method:HTTP Protocolを選択
Checked Port:12345
URL:空白
Status Codes:空白
Use HTTP/1.1:チェック無し
HTTP Method:HEADのまま
Reply 200 Pattern:空白
Custom Header:空白
Enhanced Options:チェック無し

全て設定が終わったら Backをクリック



監視間隔の設定
[Rules & Checking]
今までに居た案件の値を参考に設定した。監視間隔5秒、リトライ3回、タイムアウト16秒。
前回のHTTP負荷分散の際に指摘したとおり、GUI画面ではリトライとタイムアウトの単語がテレコになっている。

Check Parameters - Service Check Parameters
Check Interval(sec):16
Connect Timeout(sec):5
Retry Count:3

当項目の設定保存は、Virtual ServicesやReal Servers等他の設定項目をクリックする事で実行される。
また、当項目で設定した値は、HTTP/HTTPS/FTP...負荷分散対象サーバ/サービス問わず共有されるようだ。



ステータスの確認
[Virtual Services]
View/Modify Servicesをクリックすると、バーチャルサーバおよび物理サーバのステータスを確認する事が出来る。
上記の設定が正常に完了出来たなら、各Real ServerのステータスはUpの状態(緑色の丸)になっている。
※赤丸のステータスはFTPサーバとHTTPサーバ用の設定。今回は未使用につき赤で問題無し。




HTTPSのやりとりの確認
この状態で、クライアントからHTTPSサーバ192.168.3.32:12345にアクセス。
Wiresharkを立ち上げパケットキャプチャ可能な状態にしてから、WebブラウザHTTPSサーバにアクセス。
Webブラウザ(Google Chrome)のURL窓左側の赤三角アイコンをクリックし証明書を選択すると、Kemp LoadMasterのオレオレ証明書自己署名証明書)を見る事が出来る。




その際のWiresharkを覗いてみると、クライアント~LB(Kemp LoadMasterに設定されたバーチャルサーバ)間のHTTPSのやりとり、SSLハンドシェイクの一連の流れを見る事が出来る。
サーバ負荷分散入門(みやたひろし著,ソフトバンククリエイティブ刊)のP164~167の記載内容と若干異なる部分が有るが、これは機器の違いによるものと推測。

下のWireSharkの画面内、No.121にてクライアントからLBにClientHelloを送信。
No.123にてLBからクライアントにServer Helloを送信。
No.124にてLBからクライアントにCertificate(Server Certificate)、Server Key Exchange、Server Hello Doneを送信。ここでサーバ証明書と鍵交換メッセージを送信している。
No.126にてクライアントからLBにClient Key Exchange、Change Cipher Spec、Encrypted Handshake Messageを送信。ここではクライアント証明書と無暗号通信の終了を示すエンドマークを送信している。ここから先は、クライアントからLBの通信は暗号化通信となる。
No.127にてクライアントからLBにApplication Dataを送信。
No.129にてLBからクライアントにChange Cipher Spec、Encrypted Handshake Messageを送信。ここから先は、LBからクライアントの通信は暗号化通信となる。
No.131と132にてLBからクライアントにApplication Dataを送信。

SSLハンドシェイクは正常に実行されているようだ。




https://debslink.hatenadiary.jp/entry/20200614/1592115319 前回:kemp LoadMasterによる負荷分散設定 - HTTPサーバ編
https://debslink.hatenadiary.jp/entry/20200613/1592014142 前々回:kemp LoadMasterによる負荷分散設定 - FTPサーバ編
https://debslink.hatenadiary.jp/entry/20200612/1591889920:kemp LoadMasterをかじってみた
https://freeloadbalancer.com/ Free LoadMaster Load Balancer
https://kemptechnologies.com/ Kemp Technologies
https://kemptechnologies.com/ja/ Kemp Technologies Inc.日本語サイト
https://support.kemptechnologies.com/hc/en-us/categories/200294835-Documentation ドキュメント

kemp LoadMasterによる負荷分散設定 - HTTPサーバ編

今回は、Kemp Technologies社のロードバランサ kemp LoadMasterの仮想アプライアンス版で、Webサーバ3台の負荷分散設定とSorryページの表示設定をやってみた。

3日連続のkemp LoadMasterネタ。しかしメンタル不調は継続中につき「かじってみた」レベルにまだ留めている認識だが、ここまで来てNeutrinoやZEVENETやPenに移る気力なんか無い。設定項目自体はF5 BIG-IPやA10 Thunderより少ないとは言え、ロードバランサとしての基本はしっかりと掴んでいるようには見える上、動作が軽快である為、学習環境としてこのまま使用し続けようかと思う。



当方の環境
・ホストOS:Windows7 32bit
Virtualbox 5.2.32
・ゲストOS:Kemp LoadMaster 7.2.50.0.18765.RELEASE
・Web Server:IWS 07.00 (Android端末3台にインストール)
・WLANでホストOSとAndroid端末3台を接続
・LoadMaster側は既にホスト名とインタフェースの設定は終えている状態



設定方針
・負荷分散方式はLeast Connection
・セッション維持方式はCookie
・細かな設定値は変更せずデフォルト値のまま
・3台のWebサーバがダウンしたら、外部からのアクセスはSorryサーバに渡され、クライアント側のWebブラウザでSorryを表示させる
・全断の時はホストOSで動作しているWebサーバに渡され、クライアント側のWebブラウザ上で503:Service Unavailableを表示させる




バーチャルサーバの設定
最初にバーチャルサーバを設定する。クライアント側から見て、トラフィックの受付先がバーチャルサーバとなる。
バーチャルサーバは関連付けされたリアルサーバに対しトラフィックを受け流す。
LoadMasterでは、F5 BIG-IPで言うPool MemberはReal Serversに置き換えて呼ぶ。Virtual Serverはそのまま。

Home画面にて、左側のVirtual Servicesをクリック
Virtual Services - Add New
Virtual Address: IPアドレス
Port: 8080
Service Name: Virtual Serverのホスト名
Protocol:tcp
Add this Virtual Serviceをクリック


[Basic Properties]
Service TypeをHTTP-HTTP/2-HTTPに変更すると、[Advanced Properties]の表示内容がHTTP/HTTPSに特化した内容に変わる。
核設定項目から判断すると、F5 BIG-IPで言う「HTTP Profile」に相当するものと思われる。
Service Name:上記で設定したService Nameが表示されている
Alternate Address:空欄
Service Type:HTTP-HTTP/2-HTTPSを選択
Activate or Deactivate Service:チェックを入れる


[Standard Options]
Persistence(セッション維持)とScheduling Method(負荷分散方式)が同じStandard Option内で設定される。
設定項目およびオプション値は最低限のように見えるが、Persistenceは種類が多い。
F5 BIG-IPで言うCookieパーシステンスに当たるセッション維持機能は「Active Cookie」が該当するようだ。
(https://support.kemptechnologies.com/hc/en-us/articles/202040875-Layer-7-persistence-methods の「Active Cookie Persistence」を参照)

Force L4:チェック無し
Transparency:チェック無し
Subnet Originating Requests:チェック無し
Extra Ports:空欄
Server Initiating Protocols:Other Server Initiatingを選択
Persistence Options Mode:Active Cookieを選択
Persistence Options Timeout:6 Minutesのまま
Persistence Options Cookie_name:Set_Meのまま
Scheduling Methos:least connectionを選択
Idle Connection Timeout:空欄
Quarity of Service:Normal-Service


[SSL Properties]
SSL Acceleration Enabled:チェック無し


[Advanced Properties]
Content Switching:Disabledのまま
HTTP Selection Rules:そのまま
HTTP Header Modifications:そのまま
Responce Body Modification:そのまま
Enable Caching:チェック無し
Enable Compression:チェック無し
Detect Malicious Requests:チェック無し
Enable Multiple Connect:チェック無し
Add Header to Request:空白
Copy Header in Request:空白
Add HTTP Headers:Legacy Operation(X-Forwarded-For)のまま
"Sorry" Server:192.168.3.19 Port 8080
Default Gateway:空白
Service Specific Access Control:そのまま



物理サーバの設定
F5 BIG-IPと同様に、バーチャルサーバの次に物理サーバの設定をする。
トラフィックを受け取ったバーチャルサーバは、ラウンドロビンや最小コネクション数など設定された負荷分散方式により、物理サーバにトラフィックを割り振る。

[Real Servers]
Add Newをクリック

Please Specify the Parameters for the Real Serverの画面にて
Allow Remote Addresses:チェック無し
Real Server Address:HTTPサーバのIPアドレスを入力
Port:8080
Forwarding method:nat
Weight:1000のまま
Connection Limit:空欄
Add This Real Serverをクリックし設定を保存。
Backをクリック
負荷分散対象のFTPサーバの台数分、Real ServerをAdd Newから作成する

Real Serversの欄に戻り
Real Server Check Method:HTTP Protocolを選択
Checked Port:8080
URL:空白
Status Codes:空白
Use HTTP/1.1:チェック無し
Reply 200 Pattern:空白
Custom Header:空白
Enhanced Options:チェック無し

全て設定が終わったら Backをクリック



監視間隔の設定
[Rules & Checking]
F5 BIG-IP LTMだけど、今までに居た案件の値を参考に設定した。監視間隔5秒、リトライ3回、タイムアウト16秒。
しかし、前回のFTP負荷分散の際に指摘したとおりリトライとタイムアウトの単語がテレコになっている。

Check Parameters - Service Check Parameters
Check Interval(sec):16
Connect Timeout(sec):5
Retry Count:3

当項目の設定保存は、Virtual ServicesやReal Servers等他の設定項目をクリックする事で実行される。
また、当項目で設定した値は、HTTP/HTTPS/FTP...負荷分散対象サーバ/サービス問わず共有されるようだ。



ステータスの確認
[Virtual Services]
View/Modify Servicesをクリックすると、バーチャルサーバおよび物理サーバのステータスを確認する事が出来る。
上記の設定が正常に完了出来たなら、各Real ServerのステータスはUpの状態(緑色の丸)になっている。
※赤丸のステータスはFTPサーバ用の設定。今回は未使用につき赤で問題無し。



3台のPC(自分Macbook、嫁PC、息子PC)からWebサーバにアクセスしファイルのGETを試みたところ、前回のFTPサーバと同様にラウンドロビンの如く3台のWebサーバに負荷分散された。
この状態でWebサーバを1台づつ落としてみたら、生き残っている他のWebサーバに振り分けられるまでに要する時間は、前回同様に5~10秒とばらつきが有った。5回試行したが結果は同じ。
3台のWebサーバ全てを落としたら、想定どおりSorryページに渡された。
その際のステータス表示は、オレンジ色の矢印に「Sorry」のステータス。



以下はSorryの表示。HTTPサーバアプリ「IWS」で指定したディレクトリに自作のindex.htmlを置いて、外部からアクセスしたPCのWebブラウザで表示させている。


更にSorryサーバを落とした状態で外部からWebサーバにアクセスを試みたら、503の表示。これはホストOSで動作している簡易HTTPサーバのアプリで指定したフォルダに自作のindex.htmlを置いて、外部からアクセスしたPCのWebブラウザで表示させている。少なくともA10 Thunderでは内部でSorryページを持てたと思うが、LoadMasterでの設定方法は不明。




https://debslink.hatenadiary.jp/entry/20200629/1593357476 追記:kemp LoadMasterによる負荷分散設定 - HTTPSサーバ編
https://debslink.hatenadiary.jp/entry/20200613/1592014142 前回:kemp LoadMasterによる負荷分散設定 - FTPサーバ編
https://debslink.hatenadiary.jp/entry/20200612/1591889920 前々回:kemp LoadMasterをかじってみた
https://freeloadbalancer.com/ Free LoadMaster Load Balancer
https://kemptechnologies.com/ Kemp Technologies
https://kemptechnologies.com/ja/ Kemp Technologies Inc.日本語サイト
https://support.kemptechnologies.com/hc/en-us/categories/200294835-Documentation ドキュメント

kemp LoadMasterによる負荷分散設定 - FTPサーバ編

Kemp Technologies社のロードバランサ、kemp LoadMasterの仮想アプライアンス版で、FTPサーバ3台の負荷分散設定をやってみた。
前回は、kemp LoadMasterの仮想アプライアンス版をPCで動作するVirtualboxにデプロイし、Freeライセンスを適用させた後、GUIで設定項目をポチポチいじりながらどんな設定が出来るのか軽く見てみた。
その結果、F5 BIG-IP LTMやA10 ThunderやCitrix NetScaler程ではないものの、ロードバランサとしては一通り遊べる事がわかった。
という事で、今回はLoadMaster事始めとして3台のFTPサーバに負荷分散する設定をしてみた。



当方の環境
・ホストOS:Windows7 32bit
Virtualbox 5.2.32
・ゲストOS:Kemp LoadMaster 7.2.50.0.18765.RELEASE
FTP Server:Ftp server 1.32 (Android端末3台にインストール)
・WLANでホストOSとAndroid端末3台を接続
・まだ「かじってみた」の域を脱していない為、基本的な設定以外はデフォルト値
・LoadMaster側は既にホスト名とインタフェースの設定は終えている状態



設定方針
・負荷分散方式はLeast Connection
・セッション維持方式は送信元IPアドレス
・細かな設定値は変更せずデフォルト値のまま




バーチャルサーバの設定
最初にバーチャルサーバを設定する。FTPクライアント側から見て、トラフィックの受付先がバーチャルサーバとなる。
バーチャルサーバは関連付けされたリアルサーバに対しトラフィックを受け流す。
LoadMasterでは、F5 BIG-IPで言うPool MemberはReal Serversに置き換えて呼ぶ。Virtual Serverはそのまま。

Home画面にて、左側のVirtual Servicesをクリック
Virtual Services - Add Newの順に移る
Virtual Address:IPアドレス
Port:2221
Service Name
Virtual Serverのホスト名
Protocol:tcp
Add this Virtual Serviceをクリック


[Basic Properties]
Service Name:上記で設定したService Nameが表示されている
Alternate Address:空欄
Service Type:Generic
Activate or Deactivate Service:チェックを入れる


[Standard Options]
Force L4:チェック無し
Transparency:チェック無し
Subnet Originating Requests:チェック無し
Extra Ports:空欄
Server Initiating Protocols:Other Server Initiatingを選択
Persistence Options Mode:Source IP Addressを選択
Scheduling Methos:least connectionを選択
Idle Connection Timeout:空欄
Quarity of Service:Normal-Service


[SSL Properties]
SSL Acceleration Enabled:チェック無し


[Advanced Properties]
Not Available ServerとPort:空欄(Sorry Serverの事)
Default Gateway:空欄
Service Specific Access Control:無視



サーバの設定
F5 BIG-IPと同様に、バーチャルサーバの次にリアルサーバの設定をする。
ここで言うサーバの設定とは、ロードバランサ側での設定を指す。最低でもFTPサーバのIPアドレスと使用するポート番号の情報が必要。
トラフィックを受け取ったバーチャルサーバは、ラウンドロビンや最小コネクション数など設定された負荷分散方式により、物理サーバにトラフィックを割り振るという設定にした。
FTPサーバの場合、データ転送量はサーバへの負荷に関係する為、負荷分散方式として適しているのはLeast Connectionになる。

[Real Servers]
Add Newをクリック

Please Specify the Parameters for the Real Serverの画面にて
Allow Remote Addresses:チェック無し
Real Server Address:FTPサーバのIPアドレスを入力
Port:2221
Forwarding method:nat
Weight:1000のまま
Connection Limit:空欄
Add This Real Serverをクリックし設定を保存。
Backをクリック
負荷分散対象のFTPサーバの台数分、Real ServerをAdd Newから作成する

Real Serversの欄に戻り
Real Server Check Method:File Transfer (FTP) Protocolを選択
Checked Port:空欄
Enhanced Options:空欄

全て設定が終わったら Backをクリック



監視間隔の設定
[Rules & Checking]
F5 BIG-IP LTMだけど、今までに居た案件の値を参考に設定した。監視間隔5秒、リトライ3回、タイムアウト16秒。
Check Parameters - Service Check Parameters
Check Interval(sec):16
Connect Timeout(sec):5
Retry Count:3

Connect Timeoutの値を変更すると、Check Intervalの値が自動で変更される。
Connect Timeout x Retry Count + 1 の値がCheck Intervalの最小値となるのだが、誤植だろうか、英単語として見るとCheck Intervalが「Check Timeout」でConnect Timeoutが「Check Interval」が適切と思う。F5 BIG-IPのGUIと見比べると分かりやすい。

当項目の設定保存は、Virtual ServicesやReal Servers等他の設定項目をクリックする事で実行される。
また、当項目で設定した値は、HTTP/HTTPS/FTP...負荷分散対象サーバ/サービス問わず共有されるようだ。



...ところで、LoadMasterのGUI設定画面には、F5 BIG-IPやA10 Thunderに有る「OK」ボタンや「Finished」ボタンが無い。
設定欄の横に「Set ほげほげ」のボタンがあったら値の入力ごとにクリック、一通り設定が終わったら「Back」ボタンをクリックする事で、設定内容が保存される。



ステータスの確認
[Virtual Services]
View/Modify Servicesをクリックすると、バーチャルサーバおよび物理サーバのステータスを確認する事が出来る。
上記の設定が正常に完了出来たなら、StatusはUpの状態、Real Serversにエントリされている各サーバもUpの状態(緑色の丸)になっている。



3台のPC(自分Macbook、嫁PC、息子PC)からFTPサーバにアクセスしファイルのGETを試みたところ、ラウンドロビンの如く3台のFTPサーバに負荷分散された。コネクション数が少ないサーバに振り分けられるのだから当然か。
この状態でFTPサーバを1台落とし再振り分けに要する時間を計測した事10回。6~10秒とばらつきが有った。スペック面で厳しいNexus7で動作するFTPサーバアプリを落とした際にばらつきが見られた。この件はロードバランサ側ではなくNexus7側の問題と思われる。


※LoadMaster側の設定が正しいにも関わらずFTP通信が全く出来ない場合は、ホストOS側のFW(自分の環境ではWindowsファイアウォール)を無効にしてから再度FTP通信を実施する。
※バーチャルサーバやリアルサーバにアサインするIPアドレスは、ホストOSのNICに設定されているIPアドレスを指定しないほうが良い。設定が反映されると同時にGUIのセッションが落とされる。



設定内容のバックアップ
F5 BIG-IP LTMやA10 Thunderと同様に、設定内容をファイルとしてPC等外部の端末に保存する事が出来る。

System Configuration - System Administration - Backup/Restore
Create & BackupにてCreate Backup Fileをクリック
ファイル名や保存先を指定する事無く、即座にバックアップファイルが作成されPCに保存される。
自分の環境では、Webブラウザのダウンロードファイル保存先に、LMBackups_jpmtkvmlb99_2020_06_11という名のファイルが生成された。



kemp LoadMasterのShutdown
kemp LoadMasterを落とす際は、
System Reboot - Shutdown で、Shutdownをクリックするとshutdown処理が走る。




https://debslink.hatenadiary.jp/entry/20200612/1591889920 前回:kemp LoadMasterをかじってみた
https://debslink.hatenadiary.jp/entry/20200614/1592115319 追記:kemp LoadMasterによる負荷分散設定 - HTTPサーバ編
https://debslink.hatenadiary.jp/entry/20200629/1593357476 追記:kemp LoadMasterによる負荷分散設定 - HTTPSサーバ編
https://freeloadbalancer.com/ Free LoadMaster Load Balancer
https://kemptechnologies.com/ Kemp Technologies Inc.
https://kemptechnologies.com/ja/ Kemp Technologies Inc.日本語サイト
https://support.kemptechnologies.com/hc/en-us/categories/200294835-Documentation ドキュメント

kemp LoadMasterをかじってみた

無節操な事に、かじってみたシリーズ第3弾となってしまった今回の対象は、kemp LoadMasterというロードバランサの仮想アプライアンスのコミュニティサポート版。
前回のHPE VSR1000はブログに載せた当日中にVyOSとの間でeBGPピアを張れたと同時に熱意が消失。今やVirtualbox仮想マシン一覧から消してしまっている。

以前より、無料で使用出来、且つ自分用PCのスペックで軽快に動作するロードバランサの仮想アプライアンスを探していたところ、kemp LoadMasterを発見。
F5 BIG-IP LET VEは過去に試用版ライセンス発行済み且つ試用期限切れ、A10 vThunderは試用版ライセンス発行済みであるもののデプロイ先のAzure VMにて毎月の課金が...という中、Googleでフリーのロードバランサを検索していたところ、GEEKFLAREというサイトの「10 Open Source Load Balancer for HA and Improved Performance」に辿り着き、そこでkemp Technologies社製ロードバランサ LoadMasterの存在を知った。
他にZEVENETやNeutrinoやSeesaw等も候補に挙がったが、自分の環境において導入のし易さややってみたい事が最も合致したのがLoadMasterだった。
業務でロードバランサいじっているし、復習や動作確認目的で自分PCに導入してみようか...の手始めに少し「かじってみた」。



まずはユーザ登録
・Free LoadMaster Load Balancer (https://freeloadbalancer.com/)にてユーザ登録。kemp Technologies本家サイト (https://kemptechnologies.com/)内の「30-Day Free Trial」ではない事に注意。
Downloadボタンをクリックするとユーザ登録画面に移る。
所属会社名やメールアドレスの登録が必須となっている事に注意。フリーエンジニア(Freelance)でも登録可能。
・ユーザ登録後、ダウンロードが可能になる。自分の場合、Virtualboxにデプロイする為にVirtualbox版をダウンロードした。



デプロイ
・ダウンロードしたFree-VLM-Oracle-VirtualBox.zipファイルを展開し、更にLoadMaster-VLM-7.2.50.0.18765.RELEASE-Oracle-VirtualBox-OVF-FREE.zipを展開。
中に有る.ovfファイルを右クリックからデプロイ開始。
・デプロイ完了後、GUIログイン。URLはVirtualboxの窓内に表示されている。
GUIの初回ログインの際、kemp IDとパスワードを入力しLicense Nowをクリック。
・License TypeはFreeの方をを選択し、Continueをクリック。
・Home画面に遷移したら、System Configuration > Network Setupの順に移り、インタフェースeth0とeth1の設定が可能になる。
eth0にVirtualboxのAdapter1、eth1にAdapter2がアサインされる。
・Local DNS Configuration > Hostname Configurationの順に移り、Set Hostnameにてホスト名の設定が可能になる。
CLIも提供されている。Virtualboxの窓からログインし、LoadMaster Configurationの画面にて 2 Service Management (CLI)を選択しEnterキーを叩くと、Virtualboxの窓の中にてコマンドを打てるようになる。コマンドに関しては、LoadMaster CLI Interface Descriptionというドキュメントを参照。
・デフォルトのusernameはbal である。rootやadminや社名ではなく何故balなのかは不明。



Free版について
ユーザ登録画面で登録したメールアドレスに、Kemp Technologiesからメールが来る。一番最初に来るメールにてコミュニティサポート版の機能期限に関して記載が有る。学習目的であれば問題無いレベルと思われる。
・HAの設定が出来ない。
・Configのバックアップが出来ない。
スループットが20Mbpsに制限されている。
・他の機能は商用版と同じ。
・試用期限は無い。GUIのトップ画面内「View License」をクリックすると、License Information欄内に「Licensed Until unlimited」の表示有り。
・2020/7/16追記:デプロイ後1ヶ月以上経過したが、設定~疎通確認~負荷分散確認まで問題無く使えている事を確認済み。



いじってみて思った事
・ホストOS側の必要スペック。F5 BIG-IP LTM VEやA10 vThunderがストレス無く動作する程のマシンスペックは必要としていない。
・起動ログを見ると、OSはLinuxベースである事が分かる。
GUIはA10 Thunderを更に簡素化したような感じ。
GUI設定はF5 BIG-IPやA10 Thunderより直感的。基本的な設定は、GUIの設定項目を上から順に Basic Properties ⇒ Standard Options ⇒ Advances Properties ⇒ Real Serversという流れで行う。勿論、後戻りして設定変更や設定追加する事は可能。
・一応、ロードバランサとして一通りの事は設定出来る印象。しかし細かな部分の設定には不満が有る。かゆい所に手が届かない、重箱の隅は突けないといった感じ。
・ロードバランサの動作を知る為の教材としては良いと思う。今となっては低スペックとなっているCore i3-2350M、4GB RAMなPCでも軽快に(?)動作する。
・日本に販売代理店が数社有る。GoogleでKemp LoadMasterで検索するとヒットする。当記事で扱っているコミュニティサポート版もサポート対象であるかどうかは不明。
・ドキュメントはkemp社のサイト内に一通り揃っている。
・日本語版のドキュメントは非常に少ない。英文ドキュメントの内容はO'REILLYやCisco Press等の洋書より文が短めである為、読み易い。しかしこれは裏を返せば情報が少ないという事。
・みやたひろしさんのサーバ負荷分散入門という参考書は、Pool MemberをReal Serverに、Load Balancing MethodをScheduling Methodに読み替える等でリファレンスとして使える。ロードバランサの基本的な動作に関してはF5 BIG-IPもKemp LoadMasterも同じである。
ovaファイル右クリックデプロイ後は改めてVirtualbox側で設定変更する必要は無い。2048MBの仮想RAM、2つの仮想CPUコア、2つの仮想NICが有れば充分。
・F5 BIG-IPのiRuleやA10 ThunderのaFlexのような、スクリプトを書いてトラフィック制御する機能は一応有る。Content Rulesがそれに当たる機能のようだが、スクリプトを1から書くものではなく、GUIでルールを設定する。
・F5 BIG-IPのRoute DomainやPartitionにあたる機能は、Kemp LoadMasterには無さそう。無さそうと言うのはKemp LoadMasterのサイトでは見た「ような気がする」のだが、自分が今使っているコミュニティサポート版ではその設定が見つからない。



今後どうする?
・暇潰し用として今後も使ってみようと思う、
CLIに関しては上記に挙げたLoadMaster CLI Interface Descriptionというドキュメントだけではどれだけの事が出来るか分からない。
少なくともA10 AEOSで出来る事は出来たらいいなと思っている。
・次回は複数のFTPサーバを繋いで遊んでみよう。今の超不安定なメンタルの下ではすぐに別の機器に心移りする可能性は充分に有り、kemp LoadMasterは今回きりかも知れないが。




https://freeloadbalancer.com/ Free LoadMaster Load Balancer
https://kemptechnologies.com/ Kemp Technologies ※30日間期限の試用版との違いは不明
https://geekflare.com/open-source-load-balancer/ 10 Open Source Load Balancer for HA and Improved Performance
https://debslink.hatenadiary.jp/entry/20200613/1592014142 追記:kemp LoadMasterによる負荷分散設定 - FTP
https://debslink.hatenadiary.jp/entry/20200614/1592115319 追記:kemp LoadMasterによる負荷分散設定 - HTTPサーバ編
https://debslink.hatenadiary.jp/entry/20200629/1593357476 追記:kemp LoadMasterによる負荷分散設定 - HTTPSサーバ編
https://www.amazon.co.jp/dp/4797377798/ サーバ負荷分散入門(みやたひろし著,2014年)