Yasuhiro ABE, The University of Aizu. | [keepalived] APU/APU2を利用したkeepalivedクラスターの構築

1. 作業の概要

このチュートリアルはkeepalivedを利用し、ロードバランサー と 高可用性(HA, High Availability) の2つの機能を体験する内容になっています。

高可用性(HA)ロードバランサーともいいます。あるいは単純にロードバランサーと呼ぶ時には、高可用性(HA)であることが期待されている場合もあります。

高可用性を実現するための技術要素に VRRP があります。 VRRPを利用することによって、複数台で1つのIPアドレスを共有し、1台が停止しても他のマシンがIPアドレスを引き継ぎ処理を継続します。

また、ロードバランサーとしての技術要素にはパケットの転送があります。KeepalivedはDRとNATの2つの方法でパケットを転送する役割も担います。

今回は 192.168.102.0/24 という実験用のネットワークを構築し、このネットワークに配置されたWebサーバーにアクセスするサービスを構築します。

次にARPテーブルについても作業の中で参照していきます。

ARPテーブルを確認する時にはip neighコマンドを利用します。

ip neigh

ARPテーブルの内容を全て削除するにはip neigh fluash allコマンドを利用します。

sudo ip neigh flush all

Wikipedia - Address Resolution Protocol

作業ではThinkPad上と、sshでリモートログインしたAPU/APU2上での作業が発生します。

どちらのホストにログインしているか混乱しないように、端末を分けるなど注意してください。

1.1. 全体図

1.2. 構築済みのサーバー

今回は以下のサーバーを利用します。

リンクをクリックしても192.168.100.0/24ネットワーク内部の端末(ThinkPad等)からはアクセスできません。

Webサーバー
- http://192.168.102.150/
- http://192.168.102.151/

比較のために特別な設定をしていないロードバランサーに対応していない通常のWebサーバーも準備しています。

Webサーバー (比較用)
- http://192.168.102.117/
- http://192.168.102.118/

1.3. ファイルの編集について

APU/APU2にはUbuntu Server Minimumを導入しています。

最低限の機能しかないため、emacsやcodeといったエディターは導入されていません。

ファイルの編集を行うためには、nanoコマンドを利用してください。

emacsコマンドを追加で導入することもできますが、GUI版を実行する場合にはssh -X ubuntu@192.168.100.210といったコマンドを利用する必要があります。

2. APU/APU2によるKeepalivedの実行

APU/APU2はPC Engines社製のx86系CPUを搭載した小型サーバーです。

ディスプレイを接続することはできません。操作はネットワーク越しにSSHなどでリモートログインするか、シリアル通信(RS-232-C)によって操作を行います。

https://wiki.archlinux.jp/index.php/PC_Engines

SSHで操作する際のID/パスワードは、各機器に貼付されている付箋を確認してください。初期化されているAPU/APU2の初期パスワードは次のようになっているはずです。

ID: ubuntu
パスワード: secret

APU(例:192.168.100.210)にリモートログインする場合の例

ssh ubuntu@192.168.100.210

2.1. 特権ユーザーでの操作

ubuntuユーザーはsudoコマンドの実行が許可されています。

パッケージの導入や必要なシステムの変更にはsudoコマンドを利用してください。

sudo id

2.2. APU/APU2のIPアドレス等の設定値

APU/APU2のeth0(enp1s0)、eth1(enp2s0)にはDHCPサーバー経由で自動的に固定IPが割り当てられるよう設定しています。

それぞれのネットワークにイーサネット・ケーブルを使用し、正しく接続してください。

一般的にAPU/APU2をUSBシリアルケーブルで接続したLinux端末には次のコマンドでアクセスできます。

$ sudo screen /dev/ttyUSB0 115200

各APUのIPアドレスと設定に必要な情報は以下のとおりです。

ホスト名	IPアドレス enp1s0側	VRRP:virtual_router_id1 (XXX1)	VRRP:virtual_router_id2 (XXX2)	VRRP:virtual_ip_address	VRRP:virtual_server (末尾ZZZ)	VPP:priority (WW)	Type
u109lb10	192.168.100.210	100		192.168.100.220/24 dev enp1s0	220	10	Master
u109lb10	192.168.102.210		200	192.168.102.220/24 dev enp2s0	220	10	Master
u109lb11	192.168.100.211	110		192.168.100.221/24 dev enp1s0	221	10	Master
u109lb11	192.168.102.211		210	192.168.102.221/24 dev enp2s0	221	10	Master
u109lb12	192.168.100.212	110		192.168.100.221/24 dev enp1s0	221	20	Backup
u109lb12	192.168.102.212		210	192.168.102.221/24 dev enp2s0	221	20	Backup
u109lb13	192.168.100.213	120		192.168.100.223/24 dev enp1s0	223	10	Master
u109lb13	192.168.102.213		220	192.168.102.223/24 dev enp2s0	223	10	Master
u109lb14	192.168.100.214	120		192.168.100.223/24 dev enp1s0	223	20	Backup
u109lb14	192.168.100.214		220	192.168.102.223/24 dev enp2s0	223	20	Backup
u109lb15	192.168.100.215	130		192.168.100.225/24 dev enp1s0	225	10	Master
u109lb15	192.168.100.215		230	192.168.102.225/24 dev enp2s0	225	10	Master
u109lb16	192.168.100.216	130		192.168.100.225/24 dev enp1s0	225	20	Backup
u109lb16	192.168.100.216		230	192.168.102.225/24 dev enp2s0	225	20	Backup

これらの情報は後で利用します。

2.3. 動作を観察する上で必要な情報

正常に稼動すると、3つの仮想IPによってサービスが開始され、それぞれ参加ホスト、稼動確認用URLは次のようになります。

仮想IPアドレス (FQDN)	参加ホスト	直接接続用URL	稼動確認用URL(GW経由)	稼動確認用URL(inovtst9経由)
192.168.100.220 (u109lb20.fcsjst.u-aizu.ac.jp)	u109lb10 u109lb16	http://192.168.102.220/	http://192.168.100.200/192.168.102.220/	https://inovtst9.u-aizu.ac.jp/192.168.100.200/192.168.102.220/
192.168.100.221 (u109lb21.fcsjst.u-aizu.ac.jp)	u109lb11 u109lb12	http://192.168.102.221/	http://192.168.100.200/192.168.102.221/	https://inovtst9.u-aizu.ac.jp/192.168.100.200/192.168.102.221/
192.168.100.223 (u109lb23.fcsjst.u-aizu.ac.jp)	u109lb13 u109lb14	http://192.168.102.223/	http://192.168.100.200/192.168.102.223/	https://inovtst9.u-aizu.ac.jp/192.168.100.200/192.168.102.223/
192.168.100.225 (u109lb25.fcsjst.u-aizu.ac.jp)	u109lb15	http://192.168.102.225/	http://192.168.100.200/192.168.102.225/	https://inovtst9.u-aizu.ac.jp/192.168.100.200/192.168.102.225/

仮想IPアドレス (FQDN)

参加ホスト

直接接続用URL

稼動確認用URL(GW経由)

稼動確認用URL(inovtst9経由)

192.168.100.220 (u109lb20.fcsjst.u-aizu.ac.jp)

u109lb10 u109lb16

http://192.168.102.220/

http://192.168.100.200/192.168.102.220/

https://inovtst9.u-aizu.ac.jp/192.168.100.200/192.168.102.220/

192.168.100.221 (u109lb21.fcsjst.u-aizu.ac.jp)

u109lb11 u109lb12

http://192.168.102.221/

http://192.168.100.200/192.168.102.221/

https://inovtst9.u-aizu.ac.jp/192.168.100.200/192.168.102.221/

192.168.100.223 (u109lb23.fcsjst.u-aizu.ac.jp)

u109lb13 u109lb14

http://192.168.102.223/

http://192.168.100.200/192.168.102.223/

https://inovtst9.u-aizu.ac.jp/192.168.100.200/192.168.102.223/

192.168.100.225 (u109lb25.fcsjst.u-aizu.ac.jp)

u109lb15

http://192.168.102.225/

http://192.168.100.200/192.168.102.225/

https://inovtst9.u-aizu.ac.jp/192.168.100.200/192.168.102.225/

またMACアドレスはそれぞれ次のようになっています。

ホスト	IPアドレス	MACアドレス
inovtst9	192.168.100.1	02:fe:da:20:48:b2
192.168.100.4	b0:b0:00:00:00:00
u109lb10	192.168.100.210	00:0d:b9:41:e5:40
192.168.102.210	00:0d:b9:41:e5:41
u109lb11	192.168.100.211	00:0d:b9:41:e0:7c
192.168.102.211	00:0d:b9:41:e0:7d
u109lb12	192.168.100.212	00:0d:b9:33:12:a4
192.168.102.212	00:0d:b9:33:12:a5
u109lb13	192.168.100.213	00:0d:b9:33:12:90
192.168.102.213	00:0d:b9:33:12:91
u109lb14	192.168.100.214	00:0d:b9:4a:7c:40
192.168.102.214	00:0d:b9:4a:7c:41
u109lb15	192.168.100.215	00:0d:b9:34:42:64
192.168.102.215	00:0d:b9:34:42:65
u109lb16	192.168.100.216	00:0d:b9:4a:7b:1c
192.168.102.216	00:0d:b9:4a:7b:1d
u109lbgw	192.168.100.200	00:0d:b9:61:63:11
192.168.102.200	00:0d:b9:61:63:12
-	192.168.102.150	b8:27:eb:b3:bb:e1
-	192.168.102.151	b8:27:eb:92:a5:e2
-	192.168.102.117	b8:27:eb:76:41:31
-	192.168.102.118	b8:27:eb:79:a0:35

ホスト

IPアドレス

MACアドレス

inovtst9

192.168.100.1

02:fe:da:20:48:b2

192.168.100.4

b0:b0:00:00:00:00

u109lb10

192.168.100.210

00:0d:b9:41:e5:40

192.168.102.210

00:0d:b9:41:e5:41

u109lb11

192.168.100.211

00:0d:b9:41:e0:7c

192.168.102.211

00:0d:b9:41:e0:7d

u109lb12

192.168.100.212

00:0d:b9:33:12:a4

192.168.102.212

00:0d:b9:33:12:a5

u109lb13

192.168.100.213

00:0d:b9:33:12:90

192.168.102.213

00:0d:b9:33:12:91

u109lb14

192.168.100.214

00:0d:b9:4a:7c:40

192.168.102.214

00:0d:b9:4a:7c:41

u109lb15

192.168.100.215

00:0d:b9:34:42:64

192.168.102.215

00:0d:b9:34:42:65

u109lb16

192.168.100.216

00:0d:b9:4a:7b:1c

192.168.102.216

00:0d:b9:4a:7b:1d

u109lbgw

192.168.100.200

00:0d:b9:61:63:11

192.168.102.200

00:0d:b9:61:63:12

192.168.102.150

b8:27:eb:b3:bb:e1

192.168.102.151

b8:27:eb:92:a5:e2

192.168.102.117

b8:27:eb:76:41:31

192.168.102.118

b8:27:eb:79:a0:35

2.4. APU/APU2上の /etc/netplan/00-installer-config.yaml ファイルの構成

前述のMACアドレスの表を確認しながら、各自のAPU/APU2の設定ファイル/etc/netplan/00-installer-config.yamlが正しく構成されているか確認してください。

# This is the network config written by 'subiquity'
network:
  ethernets:
    enp1s0:
      dhcp4: true
      dhcp6: false
    enp2s0:
      dhcp4: true
      dhcp6: false
  version: 2

特権ユーザーのみ編集できますので、必要に応じてsudoコマンドを利用してください。

sudo cat /etc/netplan/00-installer-config.yaml

編集にはemacs-noxパッケージを別途インストールするか、GNU nanoを利用してください。

sudo nano /etc/netplan/00-installer-config.yaml

netplanの変更を反映するには次のコマンドを実行します。

sudo netplan apply

2.5. APU/APU2へのkeepalivedの導入と設定

まずAPU/APU2にリモートログインした状態であることを確認し、次の操作を行います。

2.5.1. パッケージのインストール

keepalivedパッケージをインストールします。

sudo apt update

sudo apt dist-upgrade -y

sudo apt install -y keepalived

2.5.1.1. Ansibleを利用している場合の設定方法

もしansibleが利用可能であれば、次のようなコマンドでも可能です。

ansible all -m apt -b -a 'update_cache=yes upgrade=dist'   ## ansibleが利用できる場合

ansible all -m apt -b -a 'name=keepalived state=present'   ## ansibleが利用できる場合

ansibleコマンドはThinkPadなどのクライアント端末に設定しているはずなので、実行するホストに注意してください。

2.5.2. 設定ファイルの配置と変更

次に設定ファイル(keepalived.conf)を次のリンクからダウンロードしてください。

Type: Master用 keepalived.conf.master
Type: Backup用 keepalived.conf.backup

これを /etc/keepalived/keepalived.conf ファイルとして配置します。

ファイル中で XXX1、XXX2、WW、ZZZ と書かれている部分は、前述の表などを確認し書き換えてください。 (4箇所)

未編集の箇所がないかgrepコマンドなどで確認してください。何も表示されなければ変更を忘れている場所はありません。

grep XXX keepalived.conf

grep ZZZ keepalived.conf

grep WW keepalived.conf

なおリモートホスト上にファイルを作成する場合には、次のような方法が考えられます。

リモートホスト上で、wgetコマンドなどを使いダウンロードを行う
teeコマンドやcatコマンドを利用し、ファイルの内容をコピーする
ローカル(ThinkPad)にダウンロードしたファイルを、scpコマンドなどで転送する

コマンドの実行例は次のようになります。

wget https://web-int.u-aizu.ac.jp/~yasu-abe/ja/sccp/manual/tutorial-apu-keepalived/keepalived.conf.master

sed -i -e 's/WW/10/' keepalived.conf.master

sudo cp keepalived.conf.master /etc/keepalived/keepalived.conf

2.5.2.1. Ansibleを利用している場合の設定方法

もしansibleが利用可能であれば、次の手順でも配置が可能です。

keepalived.confをダウンロード(~/Downloads/keepalivd.conf)する
ansible.cfgファイル, venv/ディレクトリのある作業用ディレクトリにkeepalived.confファイルをコピーする
次のようなコマンドラインでファイルを転送する

ansible all -m copy -b -a 'src=./keepalived.conf dest=/etc/keepalived/keepalived.conf owner=root group=root mode=0644'

参考までにu109lb10(192.168.100.210)で利用しているkeepalived.confは次のリンク先からダウンロードできます。

keepalived.conf.eg192.168.100.200

2.5.3. keepalivedサービスの起動

まず設定ファイルが存在するか、変更を忘れた箇所がないか確認してください。

sudo cat /etc/keepalived/keepalived.conf

全ての箇所を変更した後は、次のコマンドで設定を反映させ、keepalivedプロセスを再起動します。

sudo systemctl restart keepalived.service

2.5.3.1. Ansibleを利用している場合の設定方法

もしansibleが利用できれば、次のようなコマンドでも同様の操作が可能です。

ansible all -m systemd_service -b -a 'name=keepalived.service state=restarted enabled=true'

これによってkeepalivedデーモン(daemon)が起動しているはずです。

2.5.4. 稼動確認

前述の表から稼動確認用URL (例: http://192.168.100.200/192.168.102.220/ )を確認し、自分に割り当てられた仮想IPにWebブラウザや、curlコマンドからアクセスし、応答することを確認してください。

2台で構成されているHA構成の場合には、**priority**の高い方(IPアドレスの末尾が偶数のノード)が、仮想IPをサービスします。

2.5.5. APU/APU2を再起動してみる

Webブラウザなどで、稼動確認用のURLをリロードしながら、APU/APU2を再起動します。

処理が引き継がれている様子を確認してください。

2.5.6. Webサーバーのネットワークケーブルを外してみる

Webサーバーにつながっているネットワークケーブルを、スイッチの側から外して動作が変化することを確認してください。

2.5.7. ip neigh コマンドによる確認

ThinkPadを192.168.102.0/24ネットワークに接続した場合には、必要に応じてARPテーブルを初期化します。

まずホストのARPテーブルの内容を確認するために次のコマンドを実行します。

ip neigh

上記のコマンドを実行し、仮想IP に対応するMACアドレスを確認すること
(1.)で確認したMACアドレスを持つ他のIPアドレスを探すこと
下記のコマンドからARPテーブルを削除した後、再度(1.), (2.)を実施すること
Webブラウザなどで、仮想IP と Webサーバーにアクセスした後に、再度(1.), (2.)を実施すること

sudo ip neigh flush all

3. WiresharkでHAロードバランサーの動きを確認する

サービス用の仮想IPアドレスが2つのノード間で、どのように引き継がれるのか観察します。

以下の作業はThinkPad上で実施してください。

3.1. tcpdumpコマンドを利用したパケットの観察

Wiresharkが利用できない環境下ではtcpdumpを利用することができます。

3.1.1. 基本操作

例えば、VRRPプロトコルに関係するパケットを観察するには次のようなコマンドを実行します。

sudo tcpdump -i any -n vrrp

デフォルトの操作は、MACアドレスが含まれていないので、どちらのAPU/APU2から通信が行われたか分かりません。

03:34:36.650572 IP 192.168.100.210 > 224.0.0.18: VRRPv2, Advertisement, vrid 100, prio 100, authtype simple, intvl 1s, length 20
03:34:36.949668 IP 192.168.100.211 > 224.0.0.18: VRRPv2, Advertisement, vrid 110, prio 100, authtype simple, intvl 1s, length 20

C-cでtcpdumpプロセスを終了します。

3.1.2. パケット情報を保存する

先ほどまで次のようなtcpdumpを実行していたshellで、次のように任意のファイルを指定して画面ではなくファイルに通信内容を保存することができます。

例えば、data.pcapngに通信内容を保存する場合には次のようにします。

sudo tcpdump -i any -n vrrp -w data.pcapng

可能であれば any ではなく、具体的なインタフェース名(enp3s0f0、等)を指定してください。
Layer-2のパケット構造が壊れてしまい、正しい状況を確認できない場合があります。

このようにして作成したファイル(例の場合はdata.pcapng)をThinkPadや自身の端末にコピーして、次のように開くことができます。

wireshark data.pcapng

あらかじめdata.pcapngをsftpコマンドなどで転送してから実行してください。

wiresharkにpcapngファイルを指定して実行すると、内容が表示されます。

tcpdumpを利用することでWiresharkを実行するホストが直接接続していないネットワークの状況を観察することができます。

3.2. Wiresharkの基本操作

Wiresharkの基本的な操作についてはチュートリアル - WiresharkでTLS通信をモニターするを参照してください。

3.2.1. VRRPの動作確認

グループでパケットをモニターするためには、一般的なスイッチングハブは適さないため、ポートミラー、フラディングモード、などの機能を備えた特殊なハブを準備する必要があります。

いずれにしても全体の帯域がポート1つ分に制限されるため、大量のデータ送信が行われるとパケットがドロップされてしまう可能性がある点にも注意が必要です。

ここではWiresharkによるパケットのモニターが終ったものとして説明を行います。

次のリンク先から説明用のpcapngファイルをダウンロードできます。

20260723.1610.pcapng.gz

pcapngファイルは次のようにgzip圧縮されたまま、wiresharkの引数に指定することができます。

$ wireshark 20230126_sccp_02.pcapng.gz

192.168.102.0/24ネットワークにWiresharkが稼動する端末を接続し、パケットをキャプチャしながら稼動確認用URLにWebブラウザから接続してデータを収集してください。

これ以降のセクションでは、このデータを元に説明していきます。

3.2.2. VRRPパケットの確認のポイント

起動したらフィルターに vrrp を指定します。全て小文字である必要があるので気をつけてください。もし間違った入力をすると背景が赤色になるため、気がつくと思います。

通常はIPアドレスでフィルターしますが、MACアドレスを利用したい場合には次のようにeth.addrを利用することができます。

MACアドレスのフィルタリング

3.3. VRRPのマスターノードを確認する (L2レベル)

まず2台でkeepalivedが稼動すると、自分がマスターノードであるかどうか確認するために2つのノードからパケットがLAN内に送出されます。

そしてしばらくすると通信が安定し、片側のノードだけから定期的にマルチキャストパケットが送信され続けています。

フィルターにはいくつかのVRRPノードが存在するため、特定のグループの通信をみるために、次のように特定のIPアドレスからの通信を表示します。

vrrp and ( ip.addr == 192.168.102.215 or ip.addr == 192.168.102.216 )

途中で、パケットの送信元が 192.168.102.216 から 192.168.100.215 に変化したところが分かると思います。

この例では、約4秒ほどの時間が経過したタイミングで 192.168.102.215 からパケットが送信され、その後、仮想IPが引き継がれています。

3.3.1. VRRPの基本動作

VRRPはマスターノードが指定された間隔で、VRRPと呼ばれるパケットをネットワークに放出します。

その際に利用される相手先のIPアドレスはマルチキャスト・アドレス (224.0.0.18)と呼ばれる特殊なアドレスを指定します。

この時に使用されるMACアドレスは奇数番(01)から始まる特殊なMACアドレスを使用します。

VRRPはシンプルですが、ノード間での個別の通信を必要としない点において強力といえます。

マスター側のノードからイーサネットケーブルを抜き、スタンバイ側に切り替わる瞬間、マスター側が復帰したタイミングでのVRRPパケットの状況を確認してください。

3.4. ロードバランサー機能を確認する (L7レベル)

フィルターに次のように仮想IPを指定します。

ip.addr == 192.168.102.225

ここではGET / HTTP/1.0の通信に注目していきます。(次の図ではNo.743に注目しています)

このNo.743の通信は成立せずに、すぐにTCP Retransmissionとして同じ内容のパケットが再送(No.744)されています。

No.744のIPアドレスは変更されていませんが、MACアドレスに注目すると送信元、送信先が両方とも変更されています。

このパケットの宛先はHTTPサーバーであるRaspberry Piのノード(192.168.102.150)のMACアドレスが指定されています。

3.4.1. 再送されるパケットを確認する

最初のSYNパケットからWiresharkには関係のないデータを除き、特定の通信のみを抽出する TCP Stream 機能があるので、これを利用します。

No.743を右クリックし、コンテキストメニューから"Flow" → "TCP Stream"を選択します。

次の図では、抽出された通信の様子を示しています。

3.4.2. 再送された通信の様子をMACアドレスに注目して観察する

再送が発生する理由はロードバランサーがType: DRで構成されているからです。

DRモードではMACアドレスを書き換えてパケットを再送することで、ロードバランサーの機能を実現しています。

3.5. Webサーバーが停止した場合のロードバランサーの挙動を確認する

前のセクションではロードバランサーの本質的な機能を観察しました。

この他にもロードバランサは定期的に各Webサーバーの稼動状況を確認しています。

Wiresharkを利用して定期的にKeepalivedがWebサーバー(192.168.102.150, 192.168.102.151)の死活監視を行っている様子をみてみましょう。

ここではGET /index.htmlの通信に注目していきます。

3.5.1. Wiresharkによるパケットの観察

保存している、あるいは新規に取得したパケット群から次のようなパケットをみてみましょう。

http and ip.addr == 192.168.102.150

TCP Stream機能を利用するなど工夫してください。

この通信から、192.168.102.216(APU/APU2)から192.168.102.150(Raspberry Pi, Webサーバー)に向けて通信が発生しています。

この時のUser-AgentはKeepAliveClientとなっていて、定期的にKeepalivedは仮想IPに紐つく実サーバーと通信を行っています。

設定ファイルを確認します。

virtual_server 192.168.100.225 80 {
  delay_loop 1
  lb_algo rr
  lb_kind DR
  protocol TCP
  real_server 192.168.102.150 80 {
    weight 1
    inhibit_on_failure
    HTTP_GET {
      url {
        path /index.html
        status_code 200
      }
      connect_timeout 1
      nb_get_retry 1
      delay_before_retry 1
    }
  }
  real_server 192.168.102.151 80 {
    ...
  }
}

delay_loop 1により1秒間隔で、real_serverへ稼動状況を確認しています。

3.5.2. 片側のWebサーバーが停止した場合

192.168.102.150のイーサネットケーブルを抜いた時の挙動を確認しましょう。

wiresharkのフィルターを次のように設定します。

ip.addr == 192.168.102.151

http.request.uri == "/"

イーサネットケーブルを抜くと、通信が一方通行になり、発信元(Source)を192.168.102.151とする返信がまったくなくなります。

この例ではNo.2293からNo.3740まで、192.168.100.151の返信が確認できていません。

3.6. Webサーバー復帰後の通信回復処理

指定された時間間隔でKeepalivedはreal_serverに通信が可能か確認し続けています。

イーサネットケーブルを抜いている状態でWiresharkを起動しておき、イーサネットケーブルを元のようにスイッチと接続した後、通信がどれくらいの間隔で回復するか確認してください。

3.7. HAと仮想MACアドレスについて

LinuxではMACアドレスを変更すること自体は可能ですが、1つのNICに複数の仮想MACアドレスを与えることはできません。

仮想MACアドレスについては、商用OSでは可能な場合が多いと思います。

仮想MACアドレスを使用している場合には、物理的に接続しているスイッチのみがサービスノードの停止を把握し、LAN上の他の機器はHAの稼動状況によって影響を受けることはありません。

仮想MACアドレスが使用できない環境下では、LAN上の全ての機器が仮想IPアドレスに対応するMACアドレスを把握する必要があり、サービスノードの切り替えにより仮想IPアドレスに対応するMACアドレスが変更された事を知らせるARPメッセージを受信しなければなりません。

4. 参考情報

4.1. バックエンドWebサーバー側の設定項目

以下の設定は、あらかじめバックエンドのWebサーバー側で実施した内容を説明しています。

APU/APU2側では実施する必要がないので注意すること。

Oracleのドキュメントに詳細な説明があります。

https://docs.oracle.com/cd/E39368_01/admin/section_wkd_ys2_4r.html

4.1.1. 仮想IPアドレスの設定

/etc/network/interfacesファイルに次のような設定を加え、仮想IPアドレスがWebサーバー自身のIPだと認識しています。

192.168.100.150側の設定のみ掲載します。192.168.100.151側も同様の設定を行っています。

## /etc/network/interfaces.d/eth0.conf
auto eth0
iface eth0 inet static
  address 192.168.100.150
  netmask 255.255.255.0

## /etc/network/interfaces.d/eth0:1.conf
auto eth0:1
iface eth0:1 inet static
  address 192.168.100.220
  netmask 255.255.255.0

## /etc/network/interfaces.d/eth0:2.conf
auto eth0:2
iface eth0:2 inet static
  address 192.168.100.221
  netmask 255.255.255.0

## /etc/network/interfaces.d/eth0:3.conf
auto eth0:3
iface eth0:3 inet static
  address 192.168.100.223
  netmask 255.255.255.0

これらの設定を行った後、ip addrコマンドの出力は次のようになっています。

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether b8:27:eb:b3:bb:e1 brd ff:ff:ff:ff:ff:ff
    inet 192.168.100.150/24 brd 192.168.100.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet 192.168.100.220/24 brd 192.168.100.255 scope global secondary eth0:1
       valid_lft forever preferred_lft forever
    inet 192.168.100.221/24 brd 192.168.100.255 scope global secondary eth0:2
       valid_lft forever preferred_lft forever
    inet 192.168.100.223/24 brd 192.168.100.255 scope global secondary eth0:3
       valid_lft forever preferred_lft forever

設定の方法によってはイーサネット・ケーブルを抜き差しによって仮想アドレスが復旧しない可能性があります。これらの方法は安定して動作すると思うので参考にしてください。

4.1.2. ARPに仮想IPを返信しないよう設定を変更

仮想IPを所持しているのはAPU/APU2であると、他のシステムに認識してもらう必要があります。 Webサーバーが仮想IPに関する問い合わせを無視するように設定を変更します。

/etc/sysctl.confファイルで、次の設定を書き加えます。

net.ipv4.conf.eth0.arp_ignore=1
net.ipv4.conf.eth0.arp_announce=2

4.2. https://inovtst9.u-aizu.ac.jp/192.168.100.220/ などの設定状況

稼動確認用URLとして次の3つのリダイレクトを設定しています。

ゼミ室のネットワーク境界にある inovtst9.u-aizu.ac.jp 上の nginx に次のような設定を行っています。

    location /192.168.100.220/ {
        proxy_pass    http://192.168.100.220/;
    }
    location /192.168.100.221/ {
        proxy_pass    http://192.168.100.221/;
    }
    location /192.168.100.223/ {
        proxy_pass    http://192.168.100.223/;
    }

4.3. Ansible Playbook

LB(APU/APU2)とWebサーバー(Raspberry Pi1)の設定手順については、ansible playbookにまとめてGitHub上で公開しています。

https://github.com/YasuhiroABE/sccp-lbs