温度管理(lm-sensors)(sagittarius)

続いて、sagittarius で lm-sensors と xsensors を導入する。

やり方は全く一緒だ。
$ sudo apt-get --simulate install lm-sensors
$ sudo apt-get install lm-sensors

lm-sensors の設定を作成
$ sudo sensors-detect
# sensors-detect revision 6284 (2015-05-31 14:00:33 +0200)
# Board: ASUSTeK COMPUTER INC. Z170 PRO GAMING
# Kernel: 4.4.0-104-generic x86_64
# Processor: Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz (6/94/3)

This program will help you determine which kernel modules you need
to load to use lm_sensors most effectively. It is generally safe
and recommended to accept the default answers to all questions,
unless you know what you're doing.

Some south bridges, CPUs or memory controllers contain embedded sensors.
Do you want to scan for them? This is totally safe. (YES/no): (そのままエンター)
Module cpuid loaded successfully.
Silicon Integrated Systems SIS5595... No
VIA VT82C686 Integrated Sensors... No
VIA VT8231 Integrated Sensors... No
AMD K8 thermal sensors... No
AMD Family 10h thermal sensors... No
AMD Family 11h thermal sensors... No
AMD Family 12h and 14h thermal sensors... No
AMD Family 15h thermal sensors... No
AMD Family 16h thermal sensors... No
AMD Family 15h power sensors... No
AMD Family 16h power sensors... No
Intel digital thermal sensor... Success!
(driver `coretemp')
Intel AMB FB-DIMM thermal sensor... No
Intel 5500/5520/X58 thermal sensor... No
VIA C7 thermal sensor... No
VIA Nano thermal sensor... No

Some Super I/O chips contain embedded sensors. We have to write to
standard I/O ports to probe them. This is usually safe.
Do you want to scan for Super I/O sensors? (YES/no): (そのままエンター)
Probing for Super-I/O at 0x2e/0x2f
Trying family `National Semiconductor/ITE'... No
Trying family `SMSC'... No
Trying family `VIA/Winbond/Nuvoton/Fintek'... No
Trying family `ITE'... No
Probing for Super-I/O at 0x4e/0x4f
Trying family `National Semiconductor/ITE'... No
Trying family `SMSC'... No
Trying family `VIA/Winbond/Nuvoton/Fintek'... No
Trying family `ITE'... No

Some systems (mainly servers) implement IPMI, a set of common interfaces
through which system health data may be retrieved, amongst other things.
We first try to get the information from SMBIOS. If we don't find it
there, we have to read from arbitrary I/O ports to probe for such
interfaces. This is normally safe. Do you want to scan for IPMI
interfaces? (YES/no): (そのままエンター)
Probing for `IPMI BMC KCS' at 0xca0... No
Probing for `IPMI BMC SMIC' at 0xca8... No

Some hardware monitoring chips are accessible through the ISA I/O ports.
We have to write to arbitrary I/O ports to probe them. This is usually
safe though. Yes, you do have ISA I/O ports even if you do not have any
ISA slots! Do you want to scan the ISA I/O ports? (YES/no): (そのままエンター)
Probing for `National Semiconductor LM78' at 0x290... No
Probing for `National Semiconductor LM79' at 0x290... No
Probing for `Winbond W83781D' at 0x290... No
Probing for `Winbond W83782D' at 0x290... No

Lastly, we can probe the I2C/SMBus adapters for connected hardware
monitoring devices. This is the most risky part, and while it works
reasonably well on most systems, it has been reported to cause trouble
on some systems.
Do you want to probe the I2C/SMBus adapters now? (YES/no): (そのままエンター)
Found unknown SMBus adapter 8086:a123 at 0000:00:1f.4.
Sorry, no supported PCI bus adapters found.

Next adapter: i915 gmbus dpc (i2c-0)
Do you want to scan it? (yes/NO/selectively): (そのままエンター)

Next adapter: i915 gmbus dpb (i2c-1)
Do you want to scan it? (yes/NO/selectively): (そのままエンター)

Next adapter: i915 gmbus dpd (i2c-2)
Do you want to scan it? (yes/NO/selectively): (そのままエンター)

Next adapter: DPDDC-D (i2c-3)
Do you want to scan it? (yes/NO/selectively): (そのままエンター)

Next adapter: DPDDC-E (i2c-4)
Do you want to scan it? (yes/NO/selectively): (そのままエンター)


Now follows a summary of the probes I have just done.
Just press ENTER to continue: (そのままエンター)

Driver `coretemp':
* Chip `Intel digital thermal sensor' (confidence: 9)

To load everything that is needed, add this to /etc/modules:
#----cut here----
# Chip drivers
coretemp
#----cut here----
If you have some drivers built into your kernel, the list above will
contain too many modules. Skip the appropriate ones!

Do you want to add these lines automatically to /etc/modules? (yes/NO) (そのままエンター)

Unloading cpuid... OK

ありゃ…、coretemp 以外の対応ドライバーが見つからなかったっぽいな。
これでドコまで見られるのだろうか…。

実行してみよう。
$ sensors
acpitz-virtual-0
Adapter: Virtual device
temp1: +27.8°C (crit = +119.0°C)
temp2: +29.8°C (crit = +119.0°C)

coretemp-isa-0000
Adapter: ISA adapter
Physical id 0: +20.0°C (high = +84.0°C, crit = +100.0°C)
Core 0: +16.0°C (high = +84.0°C, crit = +100.0°C)
Core 1: +19.0°C (high = +84.0°C, crit = +100.0°C)
Core 2: +16.0°C (high = +84.0°C, crit = +100.0°C)
Core 3: +16.0°C (high = +84.0°C, crit = +100.0°C)

asus-isa-0000
Adapter: ISA adapter
cpu_fan: 0 RPM

う～ん。ちょっと温度表記数が少ないかな…。

ちょっと気になったので、先程の sensors-detect で「Do you want to scan it?」の質問のところを、全て yes で答えたが、結果は変わらずだった。
CPUの温度項目しか見られないのね。

続いて、 xsensors を導入。
$ sudo apt-get install xsensors

動かしてみる。
$ xsensors &

表示はされたけど、項目数は少ない。
まぁ、CPUの温度が分かるだけでもいいか…。

温度管理(lm-sensors)(aquarius)

ココで仮想マシン pegasus がクラッシュするのが、H/W障害か？と書いた。
メモリが壊れたかと思って、一応memtestしかけてみたんだけど、特に問題は見つからず。

となると、単に I/O 負荷が上がって CPU 無応答時間が発生→強制再起動、ということが想定される。
が、そこまでチェックする前に、そもそも熱が大丈夫か確認してみたい。

というわけで、温度を確認するツールを入れてみる。
まずは aquarius から。
$ sudo apt-get --simulate install lm-sensors
$ sudo apt-get install lm-sensors

次はどうやら構成ファイルを作成するようだ。
色々聞かれるから、基本的にはデフォルトでエンター。
$ sudo sensors-detect
# sensors-detect revision 6284 (2015-05-31 14:00:33 +0200)
# System:   []
# Board: Intel Corporation NUC5i7RYB
# Kernel: 4.4.0-104-generic x86_64
# Processor: Intel(R) Core(TM) i7-5557U CPU @ 3.10GHz (6/61/4)

This program will help you determine which kernel modules you need
to load to use lm_sensors most effectively. It is generally safe
and recommended to accept the default answers to all questions,
unless you know what you're doing.

Some south bridges, CPUs or memory controllers contain embedded sensors.
Do you want to scan for them? This is totally safe. (YES/no): (そのままエンター)
Module cpuid loaded successfully.
Silicon Integrated Systems SIS5595... No
VIA VT82C686 Integrated Sensors... No
VIA VT8231 Integrated Sensors... No
AMD K8 thermal sensors... No
AMD Family 10h thermal sensors... No
AMD Family 11h thermal sensors... No
AMD Family 12h and 14h thermal sensors... No
AMD Family 15h thermal sensors... No
AMD Family 16h thermal sensors... No
AMD Family 15h power sensors... No
AMD Family 16h power sensors... No
Intel digital thermal sensor... Success!
(driver `coretemp')
Intel AMB FB-DIMM thermal sensor... No
Intel 5500/5520/X58 thermal sensor... No
VIA C7 thermal sensor... No
VIA Nano thermal sensor... No

Some Super I/O chips contain embedded sensors. We have to write to
standard I/O ports to probe them. This is usually safe.
Do you want to scan for Super I/O sensors? (YES/no): (そのままエンター)
Probing for Super-I/O at 0x2e/0x2f
Trying family `National Semiconductor/ITE'... No
Trying family `SMSC'... No
Trying family `VIA/Winbond/Nuvoton/Fintek'... No
Trying family `ITE'... No
Probing for Super-I/O at 0x4e/0x4f
Trying family `National Semiconductor/ITE'... No
Trying family `SMSC'... No
Trying family `VIA/Winbond/Nuvoton/Fintek'... Yes
Found `Nuvoton NCT5573D/NCT5577D/NCT6776F Super IO Sensors' Success!
(address 0xa00, driver `nct6775')

Some systems (mainly servers) implement IPMI, a set of common interfaces
through which system health data may be retrieved, amongst other things.
We first try to get the information from SMBIOS. If we don't find it
there, we have to read from arbitrary I/O ports to probe for such
interfaces. This is normally safe. Do you want to scan for IPMI
interfaces? (YES/no): (そのままエンター)
Probing for `IPMI BMC KCS' at 0xca0... No
Probing for `IPMI BMC SMIC' at 0xca8... No

Some hardware monitoring chips are accessible through the ISA I/O ports.
We have to write to arbitrary I/O ports to probe them. This is usually
safe though. Yes, you do have ISA I/O ports even if you do not have any
ISA slots! Do you want to scan the ISA I/O ports? (yes/NO): (そのままエンター)

Lastly, we can probe the I2C/SMBus adapters for connected hardware
monitoring devices. This is the most risky part, and while it works
reasonably well on most systems, it has been reported to cause trouble
on some systems.
Do you want to probe the I2C/SMBus adapters now? (YES/no): (そのままエンター)
Found unknown SMBus adapter 8086:9ca2 at 0000:00:1f.3.
Sorry, no supported PCI bus adapters found.

Next adapter: i915 gmbus vga (i2c-0)
Do you want to scan it? (yes/NO/selectively): (そのままエンター)

Next adapter: i915 gmbus dpc (i2c-1)
Do you want to scan it? (yes/NO/selectively): (そのままエンター)

Next adapter: i915 gmbus dpb (i2c-2)
Do you want to scan it? (yes/NO/selectively): (そのままエンター)

Next adapter: i915 gmbus dpd (i2c-3)
Do you want to scan it? (yes/NO/selectively): (そのままエンター)

Next adapter: DPDDC-C (i2c-4)
Do you want to scan it? (yes/NO/selectively): (そのままエンター)

Now follows a summary of the probes I have just done.
Just press ENTER to continue: (そのままエンター)

Driver `nct6775':
* ISA bus, address 0xa00
Chip `Nuvoton NCT5573D/NCT5577D/NCT6776F Super IO Sensors' (confidence: 9)

Driver `coretemp':
* Chip `Intel digital thermal sensor' (confidence: 9)

To load everything that is needed, add this to /etc/modules:
#----cut here----
# Chip drivers
coretemp
nct6775
#----cut here----
If you have some drivers built into your kernel, the list above will
contain too many modules. Skip the appropriate ones!

Do you want to add these lines automatically to /etc/modules? (yes/NO) (そのままエンター)

Unloading cpuid... OK

これでいいのかな？何か、/etc/modules に「coretemp と nct6775 を入れろ」って言われてるけど…。

とりあえず動かしてみる。
$ sensors
acpitz-virtual-0
Adapter: Virtual device
temp1: +27.8°C (crit = +110.0°C)
temp2: +29.8°C (crit = +110.0°C)

coretemp-isa-0000
Adapter: ISA adapter
Physical id 0: +35.0°C (high = +105.0°C, crit = +105.0°C)
Core 0: +34.0°C (high = +105.0°C, crit = +105.0°C)
Core 1: +33.0°C (high = +105.0°C, crit = +105.0°C)

う～ん、これで良いのだろうか…？

lsmod を見てみると、 coretemp というカーネルモジュールは導入されているっぽいので、 nct6775 というカーネルモジュールを入れてみようかな…。
$ lsmod > lsmod.before
$ sudo modprobe nct6775
$ lsmod > lsmod.after
$ diff -c lsmod.before lsmod.after
*** lsmod.before 2017-12-22 15:36:48.274393335 +0900
--- lsmod.after 2017-12-22 15:37:00.374274890 +0900
***************
*** 1,4 ****
--- 1,6 ----
Module Size Used by
+ nct6775 57344 0
+ hwmon_vid 16384 1 nct6775
vhost_net 20480 0
vhost 32768 1 vhost_net
macvtap 20480 1 vhost_net

nct6775 を使うために、hwmon_vid というカーネルモジュールも一緒にロードされたな…。
sensors の出力結果に何か変化はあるか…？
$ sensors
acpitz-virtual-0
Adapter: Virtual device
temp1: +27.8°C (crit = +110.0°C)
temp2: +29.8°C (crit = +110.0°C)

coretemp-isa-0000
Adapter: ISA adapter
Physical id 0: +35.0°C (high = +105.0°C, crit = +105.0°C)
Core 0: +34.0°C (high = +105.0°C, crit = +105.0°C)
Core 1: +34.0°C (high = +105.0°C, crit = +105.0°C)

nct6776-isa-0a00
Adapter: ISA adapter
Vcore: +1.88 V (min = +0.00 V, max = +1.74 V) ALARM
in1: +1.36 V (min = +0.00 V, max = +0.00 V) ALARM
AVCC: +3.36 V (min = +0.00 V, max = +0.00 V) ALARM
+3.3V: +3.36 V (min = +0.00 V, max = +0.00 V) ALARM
in4: +1.02 V (min = +0.00 V, max = +0.00 V) ALARM
in5: +0.00 V (min = +0.00 V, max = +0.00 V)
in6: +0.26 V (min = +0.00 V, max = +0.00 V) ALARM
3VSB: +3.34 V (min = +0.00 V, max = +0.00 V) ALARM
Vbat: +3.20 V (min = +0.00 V, max = +0.00 V) ALARM
fan1: 0 RPM (min = 0 RPM)
fan2: 3435 RPM (min = 0 RPM)
SYSTIN: +65.0°C (high = +0.0°C, hyst = +0.0°C) ALARM sensor = thermistor
CPUTIN: +30.5°C (high = +80.0°C, hyst = +75.0°C) sensor = CPU diode
AUXTIN: +32.5°C (high = +80.0°C, hyst = +75.0°C) sensor = CPU diode
PCH_CHIP_CPU_MAX_TEMP: +34.0°C (high = +80.0°C, hyst = +75.0°C)
PECI Agent 0: +34.0°C (high = +80.0°C, hyst = +75.0°C)
(crit = +105.0°C)
PCH_CHIP_TEMP: +0.0°C
PCH_CPU_TEMP: +0.0°C
intrusion0: OK
intrusion1: OK
beep_enable: disabled

びっくりした！しっかり出てきたよ…。

これを X で見るためのツールも導入してみよう。
$ sudo apt-get install xsensors

動くかな…？
$ xsensors &
動いた！画面イメージは以下の通り。

acpitzから出力される温度

coretempから出力される温度

nct6776から出力される温度

普通に動いている。
とりあえず後は、nct6776 というカーネルモジュールが、OS起動時に自動的に取り込まれるか…だな…。

というわけで再起動して確認してみる。
$ sudo systemctl reboot

リブート後、カーネルモジュールを確認してみる。
$ lsmod | grep nct6775
ありゃ、ロードされてないや。
ってことは、意図的にロードするように設定を組み込まないとアカンのね。

sensors-detect コマンドの出力結果では、 /etc/modules に記載しろ、とのことだったので、それを書いてみよう。
$ ls /etc/modules
$ cat /etc/modules
コメント行のみで存在しているので追記しよう。
$ sudo vi /etc/modules
--以下の行を追加
# Chip drivers
nct6775
--ココまで

これで再起動して再確認だな。
$ sudo systemctl daemon-reload
$ sudo systemctl reboot

起動してきたら確認。
$ lsmod | grep nct6775

ロードされているので、温度見てみよう。
$ sensors

nct6775 の方の温度も表示されたなら、xsensors も見てみる。
$ xsensors &

問題なく見れた。

次回は、同じ作業を sagittarius に適用したい。
ただ、ハードウェア構成が違から、カーネルモジュールも違うはずなので、次回に同じように記載する。

故障かなぁ？

今の家の環境、2台のマシン(sagittarius / aquarius)を常時稼働させ、その上で仮想マシンを動かしてる。
仮想マシンの1つに Windows7 がいて、主に sagittairus 上で動かしている。
この仮装マシン、ちょくちょくリモートデスクトップ接続して操作している。
ところがどうもこの仮想マシン、不定期にパニックリブート起こしているようで。
もしかしたら、 sagittarius の H/W に問題抱えているかも、ということで、Windows7 を aquarius 側に移して動かしてみた。
今のところ問題は起きていない。

というわけで、近いうちに sagittarius 上で memtest86 を流して、メモリ障害が起きてないか調べておこう…。

メモリ故障起こしてたら、新しいメモリに買い直さないといかのか…金が…。

systemdの設定ファイルの場所

ココで、「編集したはずのopenvswitchの起動ファイルが元に戻っている」と書いたけど、原因は大したことなかった。

そもそも、 /lib/systemd/system/openvswitch-switch.service というファイルは openvswitch-switch というパッケージに含まれるファイルの1つだ。
裏で openvswitch-switch の自動アップデートが行われ、手作業で更新したファイルがアップデートによって上書きされたに過ぎない。
逆に言うと、どんなに頑張って /lib/systemd/system/openvswitch-switch.service をカスタマイズしても、アップデート一発で元に戻ってしまうわけだ。

となると、定義ファイルをカスタマイズしたい場合はどうすればいいんだろうか？
パッケージに付属しているファイルをカスタマイズするだけでなく、自分でローカルに作成した定義ファイルというのもありうる。
これらは、ユーザ用のディレクトリに置く必要があるわけで、通常ならそういったディレクトリがあるはずだ。

ちょっと調べてみる…。
どうやら、 systemd.unit の man ページにヒントがあるようだぞ。
$ man systemd.unit
システムモード(--system)とユーザモード(--user)ってのがあるようだけど、どうやら通常運用では気にする必要がない(システムモードを見ておけばいい)ようだ。(こちらは systemd の man より)
そして、システムモードでは以下の3つのディレクトリが意味があるようだ。
/etc/systemd/system/*
/run/systemd/system/*
/lib/systemd/system/*

3つ目の /lib/systemd/system/* はこれまでもチェックしていた通りで、パッケージのファイルが配置されるところ。
/run/systemd/system/* はマニュアル上は Runtime units と書かれている。
が、中身を見てみてもちょっと良くわからない。
今見てみたら、ssh でログインしたユーザのセッション毎にディレクトリが有り、その中に conf ファイルが存在している。
どうやら、ダイナミックに動くサービス関連がココに自動的に作成されるようだ。

そして /etc/systemd/system/* だ。
こちらが、ユーザカスタマイズした定義ファイルや、ユーザが独自に作成したサービスの起動定義ファイル等を配置するためのディレクトリのようだ。

そのため、今回のように「パッケージが用意している起動定義ファイルをちょこっとカスタマイズしたい」という場合は、パッケージが用意している /lib/systemd/system/* ファイルを /etc/systemd/system/ にコピーし、こちらをカスタマイズする、というのが正しい姿のようだ。

ちなみに、/lib/systemd/system/ と /etc/systemd/system/ の両方に同じファイル名の定義ファイルがあったら、/etc/systemd/system/ の方にあるファイルを優先して使うため、同一ファイル名で配置しても問題はない。

さっそく試してみよう。
ここまで、blogの通りに作っていた場合、aquarius / sagittarius ペアと、gemini / cancer ペアの合計4台で openvswitch の起動定義をカスタマイズしているはずだ。
それぞれのペア毎に実施して欲しい。
以下の例は、 aquarius で実施している想定で書いているが、他のマシンでも同じだ。

まずは openvswitch-switch のサービスが、どの .service ファイルから起動されているかを確認する。
$ systemctl --no-pager -l status openvswitch-switch
● openvswitch-switch.service - Open vSwitch
Loaded: loaded (/lib/systemd/system/openvswitch-switch.service; enabled; vendor preset: enabled)
Active: active (exited) since 金 2017-12-15 15:07:02 JST; 32min ago
Process: 1432 ExecStartPost=/bin/sleep 6 (code=exited, status=0/SUCCESS)
Process: 1377 ExecStart=/bin/true (code=exited, status=0/SUCCESS)
Main PID: 1377 (code=exited, status=0/SUCCESS)
Tasks: 0
Memory: 0B
CPU: 0
CGroup: /system.slice/openvswitch-switch.service

12月 15 15:06:56 cancer systemd[1]: Starting Open vSwitch...
12月 15 15:07:02 cancer systemd[1]: Started Open vSwitch.
/lib/system/system/openvswitch-switch.service ファイルを使用しているのが分かる。(下線部)

今使っているファイルを、/etc/systemd/system の下に移動しておく。
$ sudo mv -i /lib/systemd/system/openvswitch-switch.service \
/etc/systemd/system/openvswitch-switch.service

そしたら、過去にバックアップしておいたオリジナルファイルを、元の名前に戻しておく。
$ sudo mv -i /lib/systemd/system/openvswitch-switch.service.orig \
/lib/systemd/system/openvswitch-switch.service

オリジナルファイルと、ユーザカスタマイズファイルの存在を確認しておこう。
$ ls -l /lib/systemd/system/openvswitch-switch.service \
/etc/systemd/system/openvswitch-switch.service
(両方ともファイルが存在するはずだ)

オリジナルとユーザカスタマイズファイルの差分をチェックしておく。
$ diff -c /lib/systemd/system/openvswitch-switch.service \
/etc/systemd/system/openvswitch-switch.service
*** /lib/systemd/system/openvswitch-switch.service 2017-03-15 21:34:41.000000000 +0900
--- /etc/systemd/system/openvswitch-switch.service 2017-11-13 10:09:34.965702805 +0900
***************
*** 6,11 ****
--- 6,12 ----
[Service]
Type=oneshot
ExecStart=/bin/true
+ ExecStartPost=/bin/sleep 6
ExecStop=/bin/true
RemainAfterExit=yes
(ExecStartPost=/bin/sleep 6 の行が追加されているのが確認できる。)

設定を反映させて、/etc/systemd/system の方を使用するようになったか確認する。
$ sudo systemctl daemon-reload
$ systemctl --no-pager -l status openvswitch-switch
● openvswitch-switch.service - Open vSwitch
Loaded: loaded (/etc/systemd/system/openvswitch-switch.service; enabled; vendor preset: enabled)
Active: active (exited) since 金 2017-12-15 15:33:54 JST; 54min ago
Main PID: 1589 (code=exited, status=0/SUCCESS)
CGroup: /system.slice/openvswitch-switch.service
(無事に /etc/systemd/system/openvswitch-switch.service の方に切り替わったっぽい。)

これで再起動してみる。(仮想マシンが動いていたら、予め停止しておくこと。)
$ sudo systemctl reboot

もし、dlm / corosync の起動がトラブったら、相方のノード側(aquarius に対して sagittarius等)から fencing されてる状態だと思う。(自分はそうだった)
ので、相方のノードで fencing を解除しておこう。

[sagittariusから]
$ sudo dlm_tool status
cluster nodeid 1084766082 quorate 1 ring seq 516 516 daemon now 402223 fence_pid 0 node 1084766082 M add 22 rem 0 fail 0 fence 0 at 0 0 node 1084766083 X add 23 rem 0 fail 0 fence 0 at 0 0
自分自身(sagittarius)の node id が 1084766082 のようなので、aquarius の node id は 1084766083 だ。
aquarius の node id に対して fencing を解除しておく。

$ sudo dlm_tool fence_ack 1084766083

[aquariusに戻って]
再び再起動して、corosync / dlm が正常に起動してくるのを確認する。
$ sudo systemctl reboot
$ systemctl --no-pager -l status dlm
$ systemctl --no-pager -l status corosync

再起動が終わったら、もう一度確認しておこう。
$ systemctl --no-pager -l status openvswitch-switch
/etc/systemd/system/openvswitch-switch.service の方を利用しているようなら無事に完了だ。
同じ手順を他のマシン上で実行して、openvswitch-switch の起動処理を /etc/systemd/system/ の方に移しておこう。

他にカスタマイズしている部分もあった気がするので、後日確認することにする。

ダメだ…。

やっぱり、きちんと corosync / dlm の運用を把握しておかないと、片方のマシンを再起動させるだけで挙動が不安定になる…。
ちゃんと調べないとな…。

あれ？openvswitchの起動処理が…。

色々調べていったんだけど、openvswitch-switchの起動処理、sleepを入れておいたはずなのに消えている。なんで？どこかで消したか？

これが今回の原因かもしれない。
なので、openvswitch-switch の起動処理に sleep を入れてみることにする。
まずは aquarius から。
(aquarius) $ cd /lib/systemd/system
(aquarius) $ sudo vi openvswitch-switch.service
今回は、ExecStart ではなく、ExecStartPost で定義を足してみる。
--[Service]セクションに1行追記
ExecStartPost=/bin/sleep 6
--ここまで

この状態で再起動してみよう。
(aquarius) $ sudo systemctl daemon-reload
(aquairus) $ sudo systemctl reboot

再起動後に確認。
(aquarius) $ sudo systemctl status corosync
(aquarius) $ sudo systemctl status dlm
(aquarius) $ sudo systemctl status lvm2-cluster-activation
おっと、lvm2-cluster-activation は無効化してたんだった。
corosync と dlm は無事に起動しているっぽいな。

では、lvm2-cluster-activation も有効化してから再起動だ。
(aquarius) $ sudo systemctl is-enabled lvm2-cluster-activation.service
(aquarius) $ sudo systemctl enable lvm2-cluster-activation.service
(aquarius) $ sudo systemctl is-enabled lvm2-cluster-activation.service
(aquarius) $ sudo systemctl reboot

もう一度確認
(aquarius) $ sudo systemctl status corosync
(aquarius) $ sudo systemctl status dlm
(aquarius) $ sudo systemctl status lvm2-cluster-activation
どうやら無事に起動したみたいだ。

そしたら続いて、fstab の修正。
(aquarius) $ sudo vi /etc/fstab
/etc/libvirt のエントリと、 /var/lib/libvirt のエントリを有効化する。

一応、マウントテスト
(aquarius) $ sudo systemctl daemon-reload
(aquarius) $ df
(aquarius) $ sudo systemctl start /etc/libvirt
(aquarius) $ sudo systemctl start /var/lib/libvirt
(aquarius) $ df
マウントできた。

この状態でもう一度再起動して、無事にマウントされているか確認。
(aquarius) $ sudo systemctl reboot
(aquarius) $ sudo systemctl status corosync
(aquarius) $ sudo systemctl status dlm
(aquarius) $ sudo systemctl status lvm2-cluster-activation

(aquarius) $ df
良さそうだ。

sagittarius の方も同様に修正しておこう。

これでなんとか回復できたかな？

う～ん、まだ少し不安定だ。
障害で片方のノード(sagittarius か aquarius)が落ちてしまった時の復旧手順が特殊なんだろう。おそらく、落ちたノードを単純に再起動するだけじゃダメだ。
この辺りをきちんと検証しないといけないなぁ。

やっぱりcorosyncか

とりあえず、以下の手順で原因の絞込を実施した。

1. /etc/fstab で x-systemd.requires=lvm2-cluster-activation.service の制限が入っているエントリをコメントにして、自動マウントしないようにする。
2. sudo systemctl disable lvm2-cluster-activation.service で、lvm2-cluster-activation.service が自動起動しないようにする。
3. そして sudo systemctl reboot でリブート。

どうやら、やっぱり corosync が正しくスタートしないのが原因のようだ。
起動時に、192.168.x.x の方にバインディングせず、127.0.0.1 にバインディングしてしまう。この現象、以前も出てたよな…。

はてさて、どうしたものかな…。

壊れた…

しばらく忙しくてあまりメンテしてなかったら、KVMゲストのWindowsマシンのリモートデスクトップが不安定になってしまった。
ネットワークの方の問題かなぁ？と思ってたんだけど、ある時突然リモートデスクトップも接続できなくなった。
で、ホスト側を見てみたら、iSCSIへのアクセスが一部出来なくなっていて、corosync / dlm等が動かなくなってしまっていた。
上で動いている仮想マシンはiSCSIストレージを利用していたので、当然仮想マシンも動かず。
とりあえず、2台のホストマシン(sagittarius / aquarius)を強制再起動。
そしたら、corosync / dlm が正常稼働しなくなって、その後ろで動く Clusterd-LVM も動かない。
今はその原因追求と対策をしている最中…。
corosync / dlm は厳しいな…。

Pixelぇ…

Google Pixel2 / 2XL は日本で発売されないのか…。
「何もカスタマイズされていない、素のAndroid端末」が欲しいんだけどなぁ…。

忙しくて…

前回の投稿が8/23。既に一ヶ月半も過ぎてしまった。
ちょっと忙しいので、検証進んでないのよ…。
なんとか時間を作りたいのだが…。

KVM仮想マシンをHAクラスタ化

さて、意味があるのか無いのか、KVM仮想マシンごと、クラスタ制御にしてみようと思う。
ここでネックになる課題は、分かっている限り以下の2つ。

• そもそも実現出来るの？
• ライブマイグレーション機能との相性は？

この辺りを含めて検証していきたい。

まずは仮想マシンの用意。
既に gemini / cancer 上には、leo と virgo の2つの仮想マシンが用意してある。
過去の検証で作成したものだ。
今回は、leo を使ってみよう。
作業前に、leo を起動して、ライブマイグレーションが可能かをチェックしておこう。
対象の仮想マシンが壊れていたら、HAクラスタ検証で問題が起きても切り分けが出来ない。
(gemini) $ virsh start leo
(gemini) $ virsh list --all
(cancer) $ virsh list --all
(gemini) $ virsh \
migrate --live \
--domain leo \
--change-protection \
--desturi qemu+ssh://(cancerのIP)/system \
--migrateuri tcp://(cancerのIP)/ \
--verbose
(gemini) $ virsh list --all
(cancer) $ virsh list --all
(cancer) $ virsh \
migrate --live \
--domain leo \
--change-protection \
--desturi qemu+ssh://(geminiのIP)/system \
--migrateuri tcp://(geminiのIP)/ \
--verbose
(cancer) $ virsh list --all
(gemini) $ virsh list --all
(leo) $ sudo systemctl poweroff
(gemini) $ virsh list --all

続いて、leo を1つのリソースとして、pacemaker に登録する。
使うリソースエージェントだけど…、どうやら ocf:vm.sh ってのがある。これのようだ。
(gemini) $ crm ra list ocf
(gemini) $ crm ra info ocf:vm.sh

info で出てきたオプションを頼りに、実際に登録してみる。
(gemini) $ sudo crm configure primitive vm-leo \
ocf:vm.sh \
params \
name=leo \
domain="geminiのIP cancerのIP" \
use_virsh=1
う～む。どう考えてもオプション少ないよなぁ。もっと設定しないとアカンと思うんだけど…。
WARNING: vm-leo: default timeout 20s for start is smaller than the advised 300
WARNING: vm-leo: default timeout 20s for stop is smaller than the advised 120
おっと！？ワーニングが出た。
タイムアウト値をチューニングする必要があったか。
それは別途実施しよう。

さて、どうなったかな？
(gemini) $ sudo crm configure show
ちゃんと定義が入ってる。
(gemini) $ sudo crm resouce show vm-leo
おっと、cancer 側で起動してるみたいだ。
(gemini) $ virsh list --all
(cancer) $ virsh list --all
確かに、cancer 側の leo が起動している。

さて…リソースを落とすと、どういう動きになるのだろうか？
leo を virt-viewer で見ておこう。
(cancer) $ virt-viewer vm-leo &
この状態でリソースを落としてみる。
(gemini) $ sudo crm resource stop vm-leo
gemini からでも実行できた。
普通にシャットダウンのシグナルが飛んでるようだ。

今度は、leo の内側からシャットダウンしてみよう。
この場合、pacemaker が「リソースが落ちた」と判断してリソース起動をし始めるのか、「正常停止」と見なすのか？どっちだろうか？
明示的に leo を止めているので、本来なら後者の正常停止なのだが…。

というわけで実践。
(gemini) $ sudo crm resource show vm-leo
(gemini) $ sudo crm resource start vm-leo
(cancer) $ virsh list --all
leo が起動したのを確認。
(cancer) $ virt-viewer leo &
leo のコンソールにログインして、シャットダウンしよう。
(leo) $ sudo systemctl poweroff
結果、どうなったかな…？
(gemini) $ virsh list --all
(cancer) $ virsh list --all
仮想マシンは停止している…。
(gemini) $ sudo crm resource show vm-leo
んっ！？リソース vm-leo は相変わらず cancer 上で動いていることになってるぞ！？
これはモニター機能が働いてないってことか？違うかも。

とりあえず leo を起動させ、リソースから停止しておく。
(cancer) $ virsh start leo
(gemini) $ sudo crm resource stop vm-leo
(gemini) $ sudo crm resouce show vm-leo

OS側から正規に停止したのがダメだったのかもしれない。
というわけで、ホントに障害を想定して、仮想マシンleo のプロセスを殺してみよう。
まずは起動。
(gemini) $ sudo crm resource start vm-leo
(gemini) $ sudo crm resource show vm-leo
(cancer) $ virsh list --all

cancer で稼働している leo のプロセスを確認してみよう。
(cancer) $ ps -ef | grep leo | grep -v grep
今回はプロセスID 5639 だった。
これを殺してみる。
(cancer) $ sudo kill 5639
(cancer) $ ps -ef | grep 5639 | grep -v grep
落ちた。
リソースは…？
(gemini) $ sudo crm resource show vm-leo
(cancer) $ sudo crm resource show vm-leo
あれ？cancer で動いていることになってるぞ…？
(cancer) $ virsh list --all
仮想マシンは停止している…。何故だ？

う～ん。
cancer ごと落としてみるか…。
まずは leo を起動しておく。
(cancer) $ virsh start leo
(cancer) $ virsh list --all
leo が起動したのを確認したら、leo のホストマシンである cancer を強制停止してみる。
cancer は今、aquarius 上で稼働しているので、aquarius から落としてみよう。
(aquarius) $ virsh list --all
(aquarius) $ virsh destroy cancer
(aquarius) $ virsh list --all
停止したのを確認したら、gemini から vm-leo の状態を確認してみよう。
(gemini) $ sudo crm resource show vm-leo
む？リソース的には gemini で稼働したことになったぞ？
仮想マシンは？
(gemini) $ virsh list --all
こっちで稼働し始めたようだ。

ちなみに、リソース定義は…予想では「vm-leo は cancer では起動しないよ」という定義も追加されてない…はず…。
(gemini) $ sudo crm configure show
やっぱり追加されてない。
優先順位は付けてないから、この状態で cancer を復旧させたら…？
(aquarius) $ virsh start cancer
(aquarius) $ virsh list --all

(cancer) $ sudo crm resource show
Error signing on to the CIB service: Transport endpoint is not connected
あ、あれ？エラーになった…。
(cancer) $ systemctl status pacemaker
pacemaker が corosync と通信できずに落ちた…？
pacemaker 再起動してみよう。
(cancer) $ sudo systemctl restart pacemaker
(cancer) $ systemctl status pacemaker
これで大丈夫かな？
(cancer) $ sudo crm resource show
(cancer) $ sudo crm resource show vm-leo
ん？cancer で動き出した！？
(cancer) $ virsh list --all
(gemini) $ virsh list --all
やっぱり、cancer で動き出したぞ！？
どうやら、cancer の各種プロセスが正常起動してなかったようだ。

これは…「ノードダウン」と「リソースダウン」で挙動が違う。
整理しないと…。リソースダウンの挙動と設定がまだ掴めて無いから、もっと調査しないと…。
自動フェイルバックについても整理する必要がありそうだ。

う～ん。

作業用PC買い替え

先日、作業用のノートPCを買い替えた。
元々使っていたのは、acer Aspire One 752 というモデル。
これ、全然問題なく使えていて、バッテリーの持ちも悪くなかった。
だから、そのまま使い続けるツモリで、メモリも4GBへ増強し、HDD320GBからSSD240GBに換装してたんだ。
ホントに全然問題なかったんだけど、重さがカタログスペック上で1.38kgと少しヘビーだった。
なので、もう少し軽いのに買い換えようと思っていたら、安くて都合のいいのがあったので、それに買い替えたんだ。
新しく買ったのは、ASUS VivoBook E203NA。
これの Mem4GB / SSD64GB モデル。(色はピンクｗ)
カタログスペック上で、重量は900g。

買い換える前に店頭でチェックしてみたけど、キーボードも変態配列じゃなくて快適に入力出来るし、作業端末としては全然問題なさげ。
なんと値段は税込みで4万円弱。
こんなに安く手に入るのね…。

内蔵ストレージの容量が大幅減なんだけど、実際のところ、作業は全て自宅のタワーマシンとIntel NUCで処理していて、ノートPCはあくまでソレに繋ぐための端末。
だから、内蔵ストレージはそんなに必要無かった。
これに64GBのMicroSDを付けて、もう十分だった。
実際に導入したアプリケーションは…

• google Chrome
• google日本語入力
• teraterm
• putty
• VcXsrv
• Virt Viewer(32bit)
• UsbDk(64bit)
• 高機能テキストエディタ

ぐらいか。
で、Virt Viewer が64bit版ではなく32bit版なのは…。
暗号化ライブラリ関連だと思うんだけど、プリインストールされているアプリケーションと、Virt Viewer64bit版がバッティングするようで、Virt Viewerで仮想マシンのコンソールに接続しようとすると、Virt Viewerが落ちてしまう。
32bit版なら接続出来たので、とりあえず32bit版にしているところ。
UsbDkが64bit版なので、組み合わせ的に大丈夫か不明。

で、結構快適に使えている。
重量が300g以上削減できて、それでいてバッテリーの持ちは問題無さそう。
(WiFiグリグリ使い続けても、4時間以上稼働するっぽい)
で、強いて問題点を挙げるのなら…

• ケンジントンロックホールが無い
• 外部モニタ出力にD-Sub15pinが無い(HDMIのみ)
• 有線LAN(RJ45)が無い

と言ったトコロか…。
下2つはUSBで何とかなる(そもそも必要か？)。
ケンジントンロックホールに関しては、喫茶店や新幹線で作業中にトイレに行きたくなった時、結構重要。
まぁ軽いから、そのまま手に持ってトイレに行く、って形になりそうだ。

しかし、Aspire One 752 って、現時点で既に7年落ちだったのね…。全然問題なく使えてたから、そこまで古いモデルだとは思ってなかったよ…。

virt-viewer 6.0 がリリースされてたけど…

virt-viewer 6.0 がリリースされてた。
でも…
過去の接続リスト(Recent connections)が空になって、その後接続に成功してもリストに残らないという問題が…。
(だから、Recent connections がいつまで経っても空のままという…)
これがバグなのか、こちらのPCの問題なのかは不明だけど。

もしバグなら、virt-viewer 4.0 のリリースの時にもバグが含まれてた件に続いて2度目だ。
もう少しリリース管理きちんと出来ないかな…。

リソースの自動フェイルバック禁止設定

というわけで前回、リソースが稼働しているノード(gemini)を強制停止、リソースが対向ノード(cancer)へ自動フェイルオーバーすることを確認した。
その後、gemini を起動させたら、リソースが自動でフェイルバックしてしまった。
これはあまりよろしくない、ということで、自動フェイルバックはしないように設定してみたい。
これは、resouce-stickiness というパラメータで制御するようだ。
ただ、resource-agent(ra)固有のパラメータではなく、汎用パラメータのようで、crm ra info ocf:IPaddr2 では表示されない。
そのために探すのに時間がかかった。
他にも汎用パラメータはあるようだけど、とりあえずはコレだけ調べがついた。

取り急ぎ、設定を反映させる手順を。
手順としては2種類。

• 既に作成済みのリソース、iptest に対して設定を追加するやり方
• 一旦リソースを削除し、新たに作成するやり方

だ。
既に稼働中のシステムに対しては前者を使用することになるが、新たにリソースを作成するときには後者の知識があったほうが便利だ。
そのため、両方を試してみよう。

まずは前者、既に作成済みのリソースに対して設定を追加するやり方。
$ sudo crm configure show testip
$ sudo crm resource meta testip show resource-stickiness
そんなパラメータ無い！と怒られる。
$ sudo crm resource meta testip set resource-stickiness INFINITY
$ sudo crm configure show testip
$ sudo crm resource meta testip show resource-stickiness
設定できた。

果たしてこれでいいのだろうか？
前回と同じように試してみよう。

まずは手作業でフェイルオーバーだ。
$ sudo crm resource migrate testip
$ sudo crm resource show testip
$ sudo crm configure show
gemini で動いていた testip が cancer に移動した。

元に戻そう。
$ sudo crm resource unmigrate testip
$ sudo crm resource show testip
…あれ？戻らなかったぞ？
ちなみに
--
location cli-ban-testip-on-gemini testip role=Started -inf: gemini
--
のエントリは消えた。

ということは、もう一回 migrate したら…？
$ sudo crm resource migrate testip
$ sudo crm resource show testip
$ sudo crm configure show
ふぅむ。リソースは gemini に戻ってきたが、その代わりに
--
location cli-ban-testip-on-cancer testip role=Started -inf: cancer
--
というエントリが追加されたか…。

もう一度 unmigrate してみよう。
$ sudo crm resource unmigrate testip
$ sudo crm resource show testip
gemini で稼働している状態で変化なし。
$ sudo crm configure show
--
location cli-ban-testip-on-cancer testip role=Started -inf: cancer
--
このエントリは無くなった。

なるほど…。migrate コマンドは、「当該ノードでは動かさないよ」マークを付けるだけの仕様なのか…。
ちょっと試してみよう。
(migrate コマンドではなく、直接 location を入れてみる)
$ sudo crm configure show
$ sudo crm resouce show testip
gemini で動いていることを確認して…
$ sudo crm configure location cli-ban-testip-on-gemini testip role=Started -inf: gemini
$ sudo crm configure show
$ sudo crm resource show testip
ふむ。やっぱり予想通り、testip リソースが cancer に移った。

なるほどねぇ。じゃぁこの状態で unmigrate したら…？
$ sudo crm resource unmigrate testip
$ sudo crm configure show
追加した location エントリは消えた。
$ sudo crm resource show testip
でも cancer で稼働し続けている。

だんだん見えてきた。

それじゃぁ今度は、実際の障害テストだ。
testip リソースを gemini に戻すが、面倒なので停止→起動の手順を踏む。
$ sudo crm resource stop testip
$ sudo crm resource start testip
$ sudo crm resource show testip
$ sudo crm configure show
ヨシ。

障害テストだ。
前回と同様、gemini を載せているホストマシン sagittarius から、gemini を強制的に停止させる。
testip が cancer 側に移ってくるはずだ。
(sagittarius) $ virsh destroy gemini

やはり 10秒ほどで、cancer に移動したようだ。
(cancer) $ sudo crm resource show testip
(cancer) $ sudo crm configure show
っと、「gemini では動かしちゃダメだよ」ルールも追加されていない。
前回と同じ挙動だ。

ここで gemini を復旧させる。
前回は、testip リソースが勝手に gemini に戻ったが、今回は勝手に戻ることは無いはずだ。
(sagittarius) $ virsh start gemini
(gemini) $ sudo crm resource show testip
予想通り、cancer 側には戻ってきていない。
これが前回との差異か。

実際の障害→復旧の流れだと、この時点で gemini の H/W 及び OS の正常性確認を行った後、サービス(リソース)を gemini 側に移動させるのだけど、クラスタ製品によっては、「戻す」というオペレーションではなく、「サービスを停止→起動」というオペレーションになる。
pacemaker だとどうなんだろう？
migrate だと location 制約が出来てしまい、unmigrate だと移動まではしてくれない。
「障害からの復旧」だから、「サービス停止→起動」でいいんだろう。
$ sudo crm resource stop testip
$ sudo crm resource start testip
$ sudo crm resource show testip
$ sudo crm configure show
復旧オペレーションはこれでオシマイかな？

さて最後に「一旦リソースを削除し、新たに作成するやり方」方法を書いておく。
まずは当該リソースを停止
$ sudo crm resource stop testip
$ sudo crm resource show testip
$ sudo crm configure show

続いて、リソースを削除
$ sudo crm configure delete testip_loc
$ sudo crm configure delete testip
$ sudo crm configure show

自動フェイルバックを Off にしてリソースを作成
$ sudo crm configure primitive testip \
  ocf:heartbeat:IPaddr2 \
   params \
    ip="192.168.55.155" \
   meta \
    resource-stickiness="INFINITY"
$ sudo crm configure \
  location testip_loc testip \
    rule 100: \#uname eq gemini \
    rule  50: \#uname eq cancer

結果の確認
$ sudo crm resource show testip
(cancer で起動してしまったので、リソースを再起動)
$ sudo crm resource restart testip
$ sudo crm resource show testip
$ sudo crm configure show

出来た。
これでリソースの自動フェイルバック禁止はOKだ。

リソース定義は他にも色々細かい設定があるようだけど、IPリソースの定義はこのあたりにしておいて、次回は KVMゲストを HA クラスタのリソースとして定義してみようと思う。

リソースの稼働先(優先度)を指定

前回、testip というリソースを作成した。

この testip 、起動時には gemini / cancer のいずれのノードで稼働するかは不定だ。
(どうも、cancer で起動しようとするようだ…。)

これを、

• 通常時は gemini で稼働
• gemini が停止している時は cancer で稼働

という具合に固定化させてみたい。

やり方はそんなに難しくない。
リソースの稼働優先度を付ければいい。
(前回、stonith リソースの稼働先を指定したコマンドとほぼ同じだ。)

まずは testip の停止
$ sudo crm resource show testip
$ sudo crm resource stop testip
$ sudo crm resource show testip

testip のリソースに対して、 gemini:100 cancer:50 の優先度をつける
$ sudo crm configure show
$ sudo crm configure \
location testip_loc testip \
rule 100: \#uname eq gemini \
rule 50: \#uname eq cancer
$ sudo crm configure show
$ sudo crm configure show testip_loc

これで、gemini の方が優先度が高くなったため、gemini が稼働中であれば、testip は gemini で起動してくるはずだ。
試してみよう。
$ sudo crm resource show testip
$ sudo crm resource start testip
$ sudo crm resource show testip

start / stop を繰り返してみたり、cancer のコマンドラインから start を仕掛けてみて、毎回必ず gemini 側で起動することを確認しよう。

gemini 側で起動することが確認できたら、手作業でフェイルオーバー(厳密にはテイクオーバー)させてみよう。
自動的に、cancer 側で動き出すはずだ。
$ sudo crm resource migrate testip
$ sudo crm resource show testip
$ sudo crm configure show
フェイルオーバーさせたら、
location cli-ban-testip-on-gemini testip role=Started -inf: gemini
というルールが追加されたと思う。
前回の解説の通り、「このリソースは gemini では動かさないよ」というものだ。

この状態で、もう一度 migrate 仕掛けてみよう。
$ sudo crm resource migrate testip
$ sudo crm resource show testip
testip は停止している。
$ sudo crm configure show
location cli-ban-testip-on-cancer testip role=Started -inf: cancer
というルールも追加された。
gemini / cancer の2つしかノードが無いので、このルールによって、稼働可能なノードが無くなり、リソース停止になったわけだ。
＃イメージとしては、gemini がシステムダウンをし、cancer 側でサービスを継続していたが、gemini を復旧させる前に cancer もダウンしてしまった、という状態だ。

さて、では元に戻すにはどうすればいい？
単純に起動させてみると…
$ sudo crm resource start testip
$ sudo crm resource show testip
動いていない。

やはり unmigrate なのだろうか？
$ sudo crm resource unmigrate testip
$ sudo crm resource show testip
おっと！gemini で動き出した。
状態は…？
$ sudo crm configure show
追加された2つのルールは削除されている。これによって gemini で稼働し始めたか。

さて今度は、本当に障害を発生させてみよう。
gemini を載せているホストマシン sagittarius から、gemini を強制的に停止させてみる。
これで testip が cancer 側に移ってくれれば、期待した動きと言える。
(sagittarius) $ virsh destroy gemini

10秒ほどで、cancer に移動したようだ。
(cancer) $ sudo crm resource show testip
(cancer) $ sudo crm configure show
っと、例の「gemini では動かしちゃダメだよ」ルールが追加されていない。
crm migrate を実施した時と若干挙動が違うな…。そういうものなのか？

もしかして、gemini が復旧したら、リソースが自動的に gemini に戻る？
確認してみよう。
(sagittarius) $ virsh start gemini
(gemini) $ sudo crm resource show testip
なんと！？gemini 側に戻ってきている！

これはちょっとよろしく無いな…。
プライマリノードがダウンした場合、スレーブノード(待機系)で自動的にサービス再開する、というのはHAクラスタとしては理想の動き。
だけど、プライマリノードが復旧したら、サービスが自動的にプライマリノードに戻る、というのは良くない。
戻る時、スレーブノードでサービスが停止し、プライマリノードでサービスが起動する、という動きになるため、一時的にサービスが止まってしまう。
サービスが止まることが予め予想出来るのなら、業務影響の少ない夜間の特定時間帯に戻す、という要求が出て当然だ。
大抵の業務クラスタはそうなっている。
＃自動フェイルバック禁止、というような表現だ。

さて、その自動フェイルバックを禁止する方法だけど…。
これについては次回にして、今回はココまでにしよう。

とりあえずリソース作ってみる

pacemaker が起動したので、今度は リソース を作ってみる。

pacemaker ってのは、その上で動かす(クラスタ制御下に置く)サービス(例えばデータベースサービス)とかを、リソースと呼ばれる単位の集まりで制御している。
意味がわからんね。

HAクラスタを実現するためには、大きく3つの物を制御する必要がある。

1. サービス用IPアドレス
2. サービス用ディスク
3. サービスプロセス

例えばデータベースをクラスタ化する場合、

• クライアントからアクセスを受け付けるIPアドレス
  サービスを提供する方のノード(サーバ)に、このIPアドレスを付与する。
• データやプログラムが入っているディスク
  サービスを提供する方のノード(サーバ)で、このディスクをマウントする。
• データベースプロセスそのもの
  上の2つが整ったら、データベースを起動する

という感じだ。
(これら3要素のうち、幾つかを必要としないサービスも存在する)

で、pacemaker では、これらの要素1つ1つを「リソース」として登録し、リソースの組み合わせでサービスを提供する形になっている。

あくまでとりあえず、1つリソースを登録してみる。
IPアドレスが簡単かな？

登録は crm コマンドを使用する。
また、リソースは resource agent (ra)というキットに用意されているものを使用するのがラクだ。(自分で作ることも出来るけど、それはまた後日…)
というわけで、ra の確認だが…。
ra はクラスごとに分けられている。
まずは、クラスの一覧を確認してみよう。
(gemini) $ crm ra classes
lsb
ocf / .isolation heartbeat lvm2 pacemaker redhat
service
stonith
systemd
5個出てきた。
それぞれ、
lsb : linux standard base (/etc/init.d のスクリプトだ)
ocf : Open Cluster Framework 準拠のサービス
service : service コマンドで起動停止する対象のサービス
stonith : stonith 専用の処理
systemd : systemd のルールに則ったサービス
という意味だ。うん。さっぱり分からんね。

殆どは ocf クラスに定義されていると思っていい。
ただ、今まで /etc/init.d や systemd によって起動停止していたサービスを pacemaker によってクラスタ化する、というのであれば、lsb や systemd 等のクラスに定義されているはずだ。

IPアドレスは ocf に定義されているが、一応リストを見てみよう。
(gemini) $ crm ra list lsb
(gemini) $ crm ra list ocf
(gemini) $ crm ra list service
(gemini) $ crm ra list stonith
(gemini) $ crm ra list systemd

たくさん出てきたと思うが、ocf の中に IPaddr、IPaddr2、IPsrcaddr、IPv6addr というソレっぽいのが見つかったと思う。
答えから言ってしまうと IPaddr2 が今回使用する ra だが、これらの詳細を確認するコマンドも実行しておこう。
(gemini) $ crm ra info ocf:IPaddr
(gemini) $ crm ra info ocf:IPaddr2
(gemini) $ crm ra info ocf:IPsrcaddr
(gemini) $ crm ra info ocf:IPv6addr

ざっと見ても分かる通り、IPaddr2 が Linux 専用に用意された ra だ。
専用というぐらいだから、これを使うのがいいだろう。

パラメータは…
ip
nic
cidr_netmask
broadcast
iflabel
lvs_support
lvs_ipv6_addrlabel
lvs_ipv6_addrlabel_value
mac
clusterip_hash
unique_clone_address
arp_interval
arp_count
arp_bg
arp_mac
arp_sender
flush_routes
だ。(結構あるな…)
さらに、オペレーションデフォルト値として、
start timeout=20s
stop timeout=20s
status timeout=20s intervals=10s
monitor timeout=20s intervals=10s
とある。
まぁ、必須なのは最初の ip だけなので、これだけ指定して作ってみよう。

(gemini) $ sudo crm configure primitive testip \
ocf:heartbeat:IPaddr2 \
params \
ip="192.168.55.155"
おっと！
ERROR: error: unpack_resources: Resource start-up disabled since no STONITH resources have been defined
   error: unpack_resources:     Either configure some or disable STONITH with the stonith-enabled option
   error: unpack_resources:     NOTE: Clusters with shared data need STONITH to ensure data integrity
Errors found during check: config not valid
Do you still want to commit (y/n)?
というエラーが出た。
とりあえず、最後の質問には n と答えておく。

どうやら、stonith の設定を施すか、stonith 自体を無効化しておく必要があるようだ。

stonith ってのは、どうやら対向ノードが完全クラッシュではなく、中途半端に止まってしまった時に、強制的に再起動等を実施する仕組みのようだ。
今回、gemini / cancer でクラスタにしないサービスも稼働させるツモリなので、再起動はしないようにしておきたい。
なので、stonith を無効にする。
無効にするには、stonith として null を使用するか、stonith 自体を無効化するようだ。
null を使用するのはあくまでテスト目的のようだが、今回は敢えて null を使用してみたい。

まずは stonith の一覧確認。
(gemini) $ crm ra list stonith
たくさん出てくるが、null というのがあるか確認しておく。

stonith:null の詳細確認。
(gemini) $ crm ra info stonith:null

実際に設定してみる。
(ココでは、stonith2gemini というのが gemini 障害時に gemini を強制再起動させるリソース、stonith2cancer というのを cancer 障害時に cancer を強制再起動させるリソースとして想定している。null エージェントなので、実際には何も起きないはずだが。)
(gemini) $ sudo crm configure primitive stonith2gemini \
stonith:null \
params \
hostlist="gemini"
(gemini) $ sudo crm configure primitive stonith2cancer \
stonith:null \
params \
hostlist="cancer"
を？すんなり通った。

出来たのだろうか…？
(gemini) $ sudo crm status --verbose
(gemini) $ sudo crm_mon
動いているようだ。

ただこのままでは、stonith2gemini が gemini で、stonith2cancer が cancer で稼働してしまうかもしれない。
そのため、リソースが稼働するサーバ(ノード)を固定させる必要がある。

どうやら、 location という定義で指定できるようだ。
(gemini) $ sudo crm configure help location
ヘルプを見てみると、どうやら以下のような記述でリソース稼働を固定させることが出来るようだ。
location ＜識別子＞ ＜リソース名＞ \
rule 100: #uname eq ＜リソースを動かしたいノード名＞ \
rule -INFINITY: #uname eq ＜リソースを動かしたくないノード名＞
＃-INFINITY は -inf と書くことも出来るみたいだ。

これを実際に適用するコマンドは以下の通り。
(gemini) $ sudo crm configure \
location stonith2gemini_loc stonith2gemini \
rule 100: \#uname eq cancer \
rule -inf: \#uname eq gemini
(gemini) $ sudo crm configure \
location stonith2cancer_loc stonith2cancer \
rule 100: \#uname eq gemini \
rule -inf: \#uname eq cancer
＃コマンドラインから実行する場合、 #uname でシェルのコメントになってしまう。
＃そのため、 \ でコメントを無効化しよう。

出来上がったか確認。
(gemini) $ sudo crm_mon -A
(gemini) $ sudo crm configure show

設定は出来たっぽい。

さて、とりあえずこの2つ、起動停止してみたい。(単なるリソースだから、起動停止できるはず…)
(gemini) $ sudo crm resource stop stonith2gemini
(gemini) $ sudo crm resource stop stonith2cancer
(gemini) $ sudo crm status --verbose
(gemini) $ sudo crm_mon -A
止まったっぽい。
今度は起動。
(gemini) $ sudo crm resource start stonith2gemini
(gemini) $ sudo crm resource start stonith2cancer
(gemini) $ sudo crm status --verbose
(gemini) $ sudo crm_mon -A
ちゃんと起動したっぽい。

起動停止させると、それぞれの syslog にも記録される。
これ、強制的にノードを指定して起動させるコマンドは無いのだろうか？
(対向ノードでは起動しない設定(-inf)なので、ノード指定の起動はエラーになるはず…)

う～ん。調べてみても、リソースを起動する時に、ノードを指定する方法が見当たらない。起動しているリソースを、他のノードに移動させる、というコマンドなら用意されているようだ。
それが resource migrate コマンドのようだ。(crm help resource migrate で簡単なオプションが表示される)
試してみよう。
(gemini) $ sudo crm status --verbose
stonith2gemini が cancer 上で動いており、stonith2cancer が gemni 上で動いているのが分かる。

では、stonith2gemini を gemini 上に移動させてみよう。(移動出来ないのが正解のはずだ。)
(gemini) $ sudo crm resource migrate stonith2gemini gemini
…何もエラーは起きない。

どうなっただろうか。
(gemini) $ sudo crm status --verbose
おや？何も変化していないぞ？
いや、変化しないことが正解なんだけど…。何もメッセージが出ていないのはちょっと気持ち悪いな。

ただ、クラスタ定義に1つエントリが追加されているのに気付いた。
(gemini) $ sudo crm configure show
--
前略
location cli-prefer-stonith2gemini stonith2gemini role=Started inf: gemini
後略
--
だ。
これを見ると、stonith2gemini は gemini で動く、という定義に見えるが…。

この状態でリソースを停止→起動してみるとどうなるだろうか？
(gemini) $ sudo crm resource stop stonith2gemini
(gemini) $ sudo crm status --verbose
(gemini) $ sudo crm configure show
(gemini) $ sudo crm resource start stonith2gemini
(gemini) $ sudo crm status --verbose
(gemini) $ sudo crm configure show
やっぱりリソースは cancer で動いているし、謎の location エントリは消えていない。
これが正しい動作なのだろうか…。

とりあえず、謎の location エントリは削除しておこう。
migrate で現れたステータスなので、消すのは unmigrate だ。
(gemini) $ sudo crm resource unmigrate stonith2gemini
(gemini) $ sudo crm status --verbose
(gemini) $ sudo crm configure show
元に戻った。

とりあえず、ダミーの stonith リソースは出来た。
一旦仕切り直して、IPアドレスのリソースを作ってみよう。

最初の方で警告が出たコマンドを実行してみよう。
(gemini) $ sudo crm configure primitive testip \
ocf:heartbeat:IPaddr2 \
params \
ip="192.168.55.155"
今度はすんなり通った。

状態を確認してみる。
(gemini) $ sudo crm configure show
(gemini) $ sudo crm status --verbose
(gemini) $ sudo crm_mon -A
testip リソースは cancer で動き出したな。
(何故か、cancer で優先的に動く。この辺りは何か理由があるんだろうけど、location 定義で制御するのが正しいんだろうな。)

とりあえず、cancer で IPアドレス が付与されているはずなので確認してみよう。
(cancer) $ ip address show
cancer で 192.168.55.155 が付与されたのが確認できた。

gemini から疎通確認。
(gemini) $ ping -c 5 192.168.55.155
ちゃんと応答がある。

では、cancer で動き出したリソースを、他のノード(今回は gemini しかいないので gemini )へ移動させてみよう。
(gemini) $ sudo crm resource migrate testip
(gemini) $ sudo crm status show
(gemini) $ sudo ip address show
(cancer) $ sudo ip address show
192.168.55.155 の IPアドレス は、無事に gemini に移動した。

この状態で configure を見てみると…
(gemini) $ sudo crm configure show
--
location cli-ban-testip-on-cancer testip role=Started -inf: cancer
--
このエントリが追加されている。
これ、よく見てみると -inf: cancer となっていて、このリソースはもう cancer では動かせない、という定義だ。

pacemaker で primtive リソースとして定義されたリソースは、migrate させると、元のノード(先程の例では cancer )がダウンしたものとして、そのリソースは cancer には戻らないようになるようだ。
この辺り、クラスタ定義かリソース定義で変更出来ると思うけど、別途調査しないと分からない。

そのため、もう一回この testip リソースを migrate しようとすると、移動先のノードが無いため、リソース自身が停止してしまう。

もう少しこのリソースを元に調査をしたいが、今回はここまでにしよう。
(ちょっと長すぎたかな？)
一旦、リソースは元に戻しておく。
(gemini) $ sudo crm resource unmigrate testip

というわけで一旦終了。