Ubuntuのシリアルコンソール化とnetplan setコマンド

 すぐ忘れるのでメモしておこう。

Ubuntu 24.04以降かもしれないけど、シリアルコンソール対応の方法。

/etc/default/grub.d/serial.cfg などのファイル名で以下を作成

GRUB_TERMINAL="console serial"

GRUB_SERIAL_COMMAND="serial --speed=115200"

GRUB_CMDLINE_LINUX="console=tty1 console=ttyS0,115200"

そしたら、

sudo update-grub

を実行。

e1000eのハング

最近、急に e1000eがハングするようになった。

syslogに

e1000e 0000:00:1f.6 enp0s31f6: Detected Hardware Unit Hang:

というメッセージが出て、復旧する時もあれば復旧しないことも？

RDPセッションとかが切れるだけじゃなく、iSCSI接続も切れてしまうので、ちょっと不便。

ちょっと調べた限り、offloadエンジン関連らしい。

パッケージ/ドライバがかなり古かったので、一旦アップデートかけて様子見。(ドライバ更新で解消してるといいなぁ)

あと、まだ18.04なので、さっさと22.04までアップデートしないと。 

ぐぇ。まだ18.04だった…。

自宅のメインマシン2台、まだUbuntu18.04だった…。

近いうちに20.04に上げておこう…。

389 Directory Server が導入されている状態での 18.04 → 20.04 への do-release-upgrade(失敗)

自宅環境とは別の環境を使って、検証をしてたりもするんだけど、そこで発覚。
必要性があって、Ubuntu で 389 Directory Server を構築しようとしてるんだけど、どうにも難しい。
で、20.04 へバージョンアップしたらもう少し分かるかな？と思って、do-release-upgrade したらなんとエラー。
パッケージの構成がガラッと変わってるみたいで、まともにバージョンアップ出来なかった。
同じ症状に当たってる人がいるか探してみたけど見当たらず。389-dsを使ってる人少ないのかな？
Ubuntu はバージョンアップが簡単な方なんだけど、どうやら失敗することもあるようだ。
というわけで、389-dsを使用している人は、バージョンアップ気をつけてね。

Ubuntu 18.04 の 386-ds-base に付いてくる /usr/sbin/db2bak のバグ

ちょっと用事があって、386 directory server を調査してるんだけど…。
基本的なところで、バックアップ・リストアをしようと思って db2bak スクリプトを実行しようとしても、どうもうまく動かない。
「なんでだ？」と中身を見てみたら、簡単なシェルスクリプトだった。
バックアップを保存するディレクトリを指定するオプションが分からず、中身を見てみたら、どうやら -a っぽい。
でも、この -a オプションを処理する部分、明らかに間違ってる。
getopt で a を処理するところが、

a) $bakdir=$OPTARG;;

になってて…。おいおいイコールの左辺が $付きの変数じゃねぇかよ。
んじゃぁ bakdir って他にどこで使われているんだ？と思って探しても出てこない。
なんじゃそりゃ…。
で、更に読み進めてみると…

eval /usr/sbin/ns-slapd db2archive -D $CONFIG_DIR -a $bak_dir $args

という処理が。
おいおい…。bak_dir って変数名で処理してるじゃねーかよ…。
ってことはさっきの場所、

a) $bakdir=$OPTARG;;

じゃなくて

a) bak_dir=$OPTARG;;

が正解なんじゃねぇのか？

バグレポート送ってもいいけど、もう 20.10 も出てるぐらいだし、20.04 では直ってると信じよう。

Windows ゲストの CPU 使用率(その2)

以前、「Windows ゲストの CPU 使用率」という記事で、CPU使用率が高いので下げたい、みたいな記事を書いていた。
あれからだいぶ経って、ホストが Ubuntu 18.0.4 に、ゲストが Windows10 になっているが、未だに CPU 使用率が高いままだった。
ちょっと気になって調べてみたところ、ゲストの定義を以下のようにすることで対応できるようだ。

-----
  <clock offset='localtime'>
    <timer name='hpet' present='yes'/>
    <timer name='hypervclock' present='yes'/>
  </clock>
-----

clock offset の定義から timer name='rtc' と timer name='pit' の宣言を無くし、 timer name='hpet' を present='yes' に、timer name='hypervclock' を present='yes' に定義。
これで動かしてみたら、CPU使用率が大幅に下がった。
このまましばらく運用してみよう。

ディスク再整理と共にゲスト(Ubuntu)の削除

色々間が開いてしまったこともあって、ゲストOSをバッサリ綺麗にしてしまいたい。
とは言え、Windowsゲストは再構築すると面倒なので、それは残して Ubuntu の環境のみ削除して、必要に応じて作成することにする。

ただ、再作成する時に、仮想マシン定義やら仮想ディスク定義やらはあった方がラクなので、それらは残しておくことにする。

$ virsh dumpxml ゲスト名 > ゲスト名.xml
$ virsh vol-dumpxml ゲスト名.qcow2 default > ゲスト名.qcow2.xml

あと、Ubuntu 18.04 はネットワーク定義が netplan になっているので、そのファイルもscp 等を使ってコピっておくと良いかもね。

システムバックアップ領域(/media/backup)をsystemd自動マウントに

nasの領域をsystemdによる自動マウントにすることができた。
どうせなら、システムバックアップ領域もsystemdを使用した自動マウントにしようと思う。

やり方は、/etc/fstab の更新、バックアップスクリプトの修正、の2点だ。

/etc/fstab の更新
$ sudo vi /etc/fstab
--/media/backup のマウント行を以下のように書き換える
//(nasのIP)/(バックアップ取得共有名) cifs noauto,guest,sfu,vers=1.0,dir_mode=0777,file_mode=0777,_netdev,nofail,x-systemd.automount,x-systemd.idle-timeout=60,x-systemd.device-timeout=60 0 0
--

設定の再読み込み
$ sudo systemctl daemon-reload
$ sudo systemctl restart remote-fs.target
$ ls /media/backup

バックアップスクリプトの修正
修正、と言っても、マウントとアンマウントを無効化するだけだ。
$ sudo -i
# vi backup/bin/0000_backup
--以下2行を無効化(先頭に # を付与)する
${BINDIR}/0010_mount
${BINDIR}/0100_umount
--

終わったらバックアップを取っておこう。
# time backup/bin/0000_backup
# exit

/mnt/nas01/iso-osをautofsからsystemdへ

ココやココで、nasのcifs領域を /mnt/iso-os へ自動マウントする手順を書いている。
この時は autofs を使用していたが、今は systemd でほぼ同様のことができる。
(分かっている唯一の違いは、autofs はワイルドカード指定ができるが、systemd ではできない、という点)

で、systemd で出来るのなら、autofs 不要じゃん、ということで systemd 制御に移行する。
まずは autofs を停止し、自動起動を外す。
$ sudo systemctl stop autofs
$ sudo systemctl disable autofs

続いて、/etc/fstab に /mnt/nas01/iso-os のマウント情報を記載する
$ sudo vi /etc/fstab
--
//(NASのIP)/(共有名) /mnt/nas01/iso-os cifs noauto,guest,dir_mode=0777,file_mode=0777,_netdev,nofail,x-systemd.automount,x-systemd.idle-timeout=60,x-systemd.device-timeout=60 0 0
--

fstab を書き換えたので、設定を読み直す
$ sudo systemctl daemon-reload
$ sudo systemctl restart remote-fs.target

確認
$ df | grep /mnt/nas01
$ ls /mnt/nas01/iso-os
$ df | grep /mnt/nas01

autofs が不要になったので削除する
$ sudo apt-get remove autofs
$ sudo apt autoremove
$ dpkg -l | grep ^rc
$ sudo apt-get purge autofs
$ sudo rm /etc/autofs.conf
$ sudo rm -rf /etc/auto.master.d

こんな感じ。

iSCSI領域をローカルマウントする時の注意

前回、ディスク構成を変更すると書いたけど、そこでちょっと問題が発生した。
iSCSIでLUNを作成し、LVM構成を組んでファイルシステム作成、ローカルマウントする、という流れだけど、これが上手く行かなかった。

具体的には、LVM VGの自動アクティベートが成功しない、もっと細かく書くと、7つのLUNのうち、1つ目のLUNのみ認識されている状態でアクティベートしようとしてしまい、中途半端な状態のアクティベートになってしまう、というもの。

どうやらOS起動時の流れが、OS LVMアクティベート→ネットワーク有効化→iSCSI有効化→他のLVMアクティベート、という順番のようで、iSCSI有効化後、iSCSIディスクを認識する処理と、LVMアクティベートの処理が並行してしまうようだ。
それが原因で、iSCSI領域のLVMアクティベートが失敗してしまう。

自動アクティベーションの対象は、/etc/lvm/lvm.conf に記載されている。
このファイルの auto_activation_volume_list に定義されている VG は、PV を認識したら自動でアクティベートしてしまう。
今回、iSCSIディスク7つのLUNで1つのVGを構成しているが、1つ目を認識した時点でアクティベーションしようとしてしまうようだ。

auto_activation_volume_list は初期値は未設定。
未設定というのは、全てのVGを自動アクティベーションする、ということ。
そのため、iSCSI LUNの認識が中途半端な状態でアクティベーションが走ってしまっていた。

そのため、iSCSIで作っているVGを、この自動アクティベートから外し、LUN全部認識した後にアクティベートするように手を加えたい。

まずは /etc/lvm/lvm.conf の auto_activation_volume_list を以下のように書き換える。
auto_activation_volume_list = [ "vg-root", "kvmcluster" ]
1つ目のパラメータはOS用のvg名、2つ目のパラメータはaqauariusとの共有VG名。
一瞬、2つ目のパラメータは不要だと思えるが、ここに入れておかないとclvmdを起動したときにkvmclusterがアクティベートされない。
クラスタの方で、dlm→clvmd→マウント という流れでresourceを作成した場合、auto_activation_volume_listにkvmclusterを入れていないと、マウントのタイミングでkvmclusterがアクティベートされず、マウントに失敗する。
ocf:heartbeat:LVM もしくは ocf:heartbeat:LVM-activate というリソースエージェントを間に挟めば、vg/lv単位でのアクティベート・ディアクティベートをクラスタで制御できるみたいだが、現時点ではそれが入っていない。
そのため、一旦はauto_activation_volume_listに"kvmcluster"を入れておく。

また、先日気づいたんけど /etc/lvm/lvm.conf を書き換えた場合、どうやら initramfs を再構築しないと、OS起動時の処理には反映されないようだ。
そのため、initramfs を再構築する。
$ sudo update-initramfs -u
これで再起動すれば、iSCSI LUN で作成したローカル用の VG はアクティベートされないはずだ。

続いて、iSCSI LUN 認識後に、ローカル用の VG をアクティベートする処理を入れる。
systemd で実現するが、少しずつ systemd に慣れてきて、ようやくそれなりに処理できるようになってきた。
細かい説明は省くが、以下の3つのファイルを作成する。

/etc/systemd/system/iscsi-after.service
--ココから
[Unit]
Description=wait at iscsi
After=open-iscsi.service multipathd.service

[Service]
ExecStart=/bin/sleep 10
Type=oneshot

[Install]
WantedBy=multi-user.target
--ココまで

/etc/systemd/system/vg-before.service
--ココから
[Unit]
Description=before vgchange
After=iscsi-after.service
Requires=iscsi-after.service

[Service]
ExecStart=/bin/true
Type=oneshot
RemainAfterExit=yes
--ココまで

/etc/systemd/system/vgchange@.service
--ココから
[Unit]
Description=vgchange -a [yn] %I
After=vg-before.service
Requires=vg-before.service
Before=libvirtd.service

[Service]
ExecStart=/sbin/vgchange -a y %I
Type=oneshot

[Install]
WantedBy=multi-user.target
--ココまで

2つ有効にする(もしかしたら、iscsi-after.service の有効化は不要かもしれない)
$ sudo systemctl daemon-reload
$ sudo systemctl enable iscsi-after.service
$ sudo systemctl enable vgchange@kvmsagi.service
(アンダースコアの kvmsagi の部分は、iSCSI領域で作った VG 名だ。変な名前だが、 sagittarius 専用の kvm 領域という名前を付けている)

ちなみに、sagittarius 専用の iSCSI 領域は、以下の2つの LV で構成されている。

• /dev/kvmsagi/etc-libvirt
• 4MB
• ext4
• /dev/kvmsagi/var-lib-libvirt
• 数百GB
• ext4

続いて、fstab を修正する
$ sudo vi /etc/fstab
--/etc/libvirt と /var/lib/libvirt のマウントを、以下のように修正する
/dev/kvmsagi/etc-libvirt /etc/libvirt ext4 noauto,_netdev,nofail,x-systemd.automount,x-systemd.idle-timeout=60,x-systemd.device-timeout=60 0 0
/dev/kvmsagi/var-lib-libvirt /var/lib/libvirt ext4 noauto,_netdev,nofail,x-systemd.automount,x-systemd.idle-timeout=60,x-systemd.device-timeout=60 0 0
--

これで再起動すれば、sagittarius 専用の iSCSI 領域がアクティベートされ、/etc/libvirt と /var/lib/libvirt にマウントされるはずだ。

ちょっと今回は詳細まで踏み込んでおらず、中身の説明も全然足りていない。
興味があったら調べてみてほしい。

KVMクラスタとストレージ

色々あってかなり間が開いてしまった。
その間も色々調査していたんだけど、構成が根本的にマズいということが分かった。
クラスタを組んで、gfs2による共有ファイルシステムをマウントするのなら、その領域は/var/lib/libvirt以外にしておくべきだった。
/var/lib/libvirtはローカルディスクにしておいて、共有ファイルシステムは別の領域にマウントする。
ただし、sagittarius/aquarius共に内蔵ディスクは容量が少ないため、専用領域を確保する余裕がない。
そこで、iSCSIターゲットを今までのsagittarius/aquarius共用とは別に、sagittarius専用、aquarius専用の2つを作成、それぞれLUNをアサインする形にする。

図.1

細かな作業手順は今回省略するが、過去の手順を元に実施して欲しい。

ただし、ローカルマウントの領域は、fstabによる直接マウントでも、automountdによる自動マウントでもなく、systemdによる自動マウントにする。

その手順は別途記載することにする。

リソースが起動しない

16.04 から 18.04 へのバージョンアップは実施できたけど、pacemaker のリソースが起動しない。
stonith は起動しているようなんだけど、リソースが起動しなきゃクラスタにならないじゃん。

で、corosync.log を見てみると、どうも stonith(fence_scsi) でエラー出している様子。
pcs status だと起動しているように見えるので、問題無いかと思っていたんだけど、もともと 16.04 時代の設定も誤っていたんじゃないか？で、偶然上手く動いていた、と。

というわけで、stonith(fence_scsi) の設定を見直してみる。

そもそも、pcmk_host_list って必要なのか？

$ sudo pcs stonith update scsi-fence pcmk_host_list=
$ sudo pcs stonith show scsi-fence
$ sudo pcs status --full

ダメだ。

nodenameは？

$ sudo pcs stonith update scsi-fence nodename=
$ sudo pcs stonith show scsi-fence
$ sudo pcs status --full

上がってきた…。

どうやら、fence_scsi で全ノードを管理する場合は、pcmk_host_list も nodename も未設定で良かったらしい…。
オプションパラメータをきちんとチェックしないとアカンなぁ…。

この後分かったんだが、pcmk_host_list は設定していないとアカンらしい。
ん…？もしかして pcmk って pacemaker のことか？
というわけで再設定する。

$ sudo pcs stonith show scsi-fence
$ sudo pcs stonith update scsi-fence pcmk_host_list="sagittarius aquarius"
$ sudo pcs stonith show scsi-fence

あと、corosync.log を見ていたら、 Startup probes: disabled (dangerous) という記載があった。以前、enable-startup-probes を false に設定していたが、これも誤りのようだ。
元に戻しておこう。

$ sudo pcs property set enable-startup-probes=
$ sudo pcs property show --all | grep enable-startup-probes

stonith 関連の設定が問題だったので、幾つかテストしてみる。
まずは普通にクラスタの起動停止

$ sudo pcs cluster stop --all
$ sudo pcs cluster start --all
$ sudo pcs status --full

問題なしだ。

続いて、片方のノードのクラスタ停止起動

(sagittarius) $ sudo pcs cluster stop aquarius
(sagittarius) $ sudo pcs status --full
(sagittarius) $ sudo pcs cluster start aquarius
(sagittarius) $ sudo pcs status --full

問題なし。

(aquarius) $ sudo pcs cluster stop sagittarius
(aquarius) $ sudo pcs status --full
(aquarius) $ sudo pcs cluster start sagittarius
(aquarius) $ sudo pcs status --full

問題無いようだ。

今度は、ノード自体の再起動だ。
その前に、以前設定した tmpfiles の設定を削除してみよう。fence_scsi の設定が誤っていたことが原因なのかもしれないので。

$ cat /etc/tmpfiles.d/var-run.conf
$ sudo rm /etc/tmpfiles.d/var-run.conf
(aquarius) $ sudo systemctl reboot
(sagittarius) $ sudo pcs status --full

おっといけない。まだクラスタの自動起動を設定していないんだった。
手で起動する。

(aquarius) $ sudo pcs cluster start aquarius
(sagittarius) $ sudo pcs status --full

問題なさげだ。(tmpfiles の /var/run/cluster も自動生成されてる)

さて…次は鬼門。vm-leo が稼働したままの sagittarius を再起動させるパターンだ。

(sagittarius) $ sudo systemctl reboot
(aquarius) $ sudo pcs status --full

やっぱり、sagittarius の停止に詰まる症状が出る。
sagittarius のコンソールを見ている限り、vm-leo が停止し切る前にその他のリソースが停止しようとしてエラーとなり、それが原因で libvirt や iscsi-initiater の停止が上手く行かず、強制停止が完了するまでリブートしない、という状態のようだ。
この辺りは、リソース停止のタイムアウト値を設定したりすれば解決しそうだ。
ただ、これまではこの症状が起きると、aquarius 側の dlm もハングしてしまい、aquarius も再起動させないと復旧しなかった。
今回は、aquarius は正常稼働している。この辺りが、fence_scsi の設定を見直した結果か。

(sagittarius) $ sudo pcs cluster start sagittarius

う～ん。なんとか起動してきたな。
vm-leo が停止するのに必要なタイムアウト設定は別途調べることにしよう。
vm-leo はオンラインマイグレーションさせる方法も調べて実装しておきたいし。

続いて、フェンシングとアンフェンシングのテストをやってみる。
sagittarius から aquarius をフェンシング

(sagittarius) $ sudo pcs status --full
(sagittarius) $ sudo pcs stonith fence aquarius
(sagittarius) $ sudo pcs status --full

クラスタから aquarius が切り離され、aquarius 上の pacemaker プロセスがダウンした。ん？ corosync は起動しているぞ…？
この時点で気になるのは、stonith(scsi-fence) が sagittarius 上で動いていない、という点。aquarius をシャットダウンさせた時は、scsi-fence は sagittarius 上で動き出したのだが…。
一旦、aquarius 上の corosync を止めてみるか…。

(aquarius) $ sudo systemctl stop corosync
(sagittarius) $ sudo pcs status

あー、aquarius 上の corosync を停止させたら、scsi-fence が sagittarius 上で動き出した。そーゆーことか。
一旦この状態で、sagittarius を再起動させてみたい。一応、クラスタは正常終了させてからね。

(sagittarius) $ sudo pcs cluster stop sagittarius --force
(sagittarius) $ sudo systemctl reboot

リブートしてきたら、クラスタが( sgaittarius 単独で)起動するか確認だ。

(sagittarius) $ sudo pcs cluster start sagittarius
(sagittarius) $ sudo pcs status

sagittarius 上で起動してきたな。

fence された aquarius は、プロセスが中途半端の状態のはずなので、きっちり再起動させておこう。

(aquarius) $ sudo systemctl reboot

むぅ。停止処理に時間がかかってるな…。fence されたことで、プロセス状態が半端な状態になっているのが原因か。
いや、どうやら停止処理がハングしたようだ…。一旦強制的に(物理的に)電源Off/ONしよう。
pacemaker プロセスを systemctl で停止させたのが問題だったのかもしれない。
aquarius が起動してきたらクラスタを起動させ、もう一度同じことを実施してみる。

(aquarius) $ sudo pcs cluster start aquarius
$ sudo pcs status
(sagittarius) $ sudo pcs status --full
(sagittarius) $ sudo pcs stonith fence aquarius
(sagittarius) $ sudo pcs status --full

aquarius からクラスタの停止は…？

(aquarius) $ sudo pcs cluster stop aquarius

う～ん…。それっぽい動きはしたが、dlm プロセスが中途半端だ…。
クラスタ起動は…？

(aquarius) $ sudo pcs cluster start aquarius

ダメだな…。
イマイチ対応方法が良くわからない。リブートさせて復旧させるけど、--force のオプションをつけよう。

(aquarius) $ sudo systemctl reboot --force

かなり時間はかかるが起動してくるはずだ。
再びクラスタに組み入れておこう。

(aquarius) $ sudo pcs cluster start aquarius

fence されたノードは、再起動させないと復旧出来ないような記載を何処かで見かけたので、--force で再起動させるしかないか。オプションつけ忘れると、再起動がハングするという最悪の自体になるので、何か他に方法はありそうだが…。

よく考えてみたら、stonith の説明は主に UPS や IPMI による強制停止・強制再起動が中心だ。ってことは、fence 発生時は相手方は強制的に電源が落ちる(or再起動する)ことが前提になっていて、今回採用しているような fence_scsi はある意味例外なのかもしれない。
であれば、再起動に手間がかかるのは、例外として受け入れるしか無いのかな？

まぁ、当初の目的であった「リソースが起動しない」という問題は解決したから、これでヨシとするか。

16.04から18.04へバージョンアップ(sagittarius)

aquarius のバージョンアップも何とか終わり、続いて sagittarius のバージョンアップを行う。
流れは基本的に aquarius で実施した手順と同じだ。
バックアップまでは前回実施済みなので、クラスタ停止とクラスタの自動起動停止からだ。

$ sudo pcs cluster stop sagittarius --force
$ sudo pcs cluster disable sagittarius

そしたらバージョンアップ実施。これはコンソールから実施しよう。

$ sudo LANG=C do-relase-upgrade

出てくるメッセージや、設定ファイルの更新の情報は、aquarius の時と同じはずだ。
同じように対応しよう。

あれ？何故か Postfix Configuration の画面が出てきた。
選択肢としては

No configuration
Internet Site
Internet with smarthost
Satellite system
Local only

となっていて、デフォルトでは Internet Site にフォーカスが当たってる。
Postfix なんて設定したかな…？まぁ、No configuration にしておくか。必要なら別途セットアップすりゃいい。

バージョンアップと再起動が終わったら、設定の確認と反映だ。

$ sudo systemctl status
$ sudo systemctl --state=failed

/etc/lvm/lvm.conf は、直接編集するのではなく、コマンドで編集しよう。

$ grep -e locking_type -e use_lvmetad /etc/lvm/lvm.conf
$ sudo lvmconf --enable-cluster
$ grep -e locking_type -e use_lvmetad /etc/lvm/lvm.conf

/etc/ssh/sshd_config は直接編集する。

$ sudo vi /etc/ssh/sshd_config

-----
PasswordAuthentication が含まれている行(コメントになっているはずだ)を探し、その下に以下の行を追加する。
PasswordAuthentication no
最後に以下の行を追加する。
Match Address 192.168.55.0/24
        PasswordAuthentication yes
Match Address 127.0.0.0/8
        PasswordAuthentication yes
-----

/etc/default/libvirt-guests も直接編集だ。

$ sudo vi /etc/default/libvirt-guests

-----
ON_SHUTDOWN の行を探して、以下のように書き換える。(追加する)
ON_SHUTDOWN=shutdown
-----

systemd の unit 定義も。

$ sudo EDITOR=vi systemctl edit ovsdb-server.service

-----
以下のように作成
[Unit]
Before=networking.service
-----

$ sudo EDITOR=vi systemctl edit ovs-vswitchd.service

-----
以下のように作成
[Unit]
Before=networking.service
-----

再読込。

$ sudo systemctl daemon-reload
$ sudo systemctl list-dependencies --before ovsdb-server.service
$ sudo systemctl list-dependencies --before ovs-vswitchd.service

fstab も直しておこう。

$ sudo vi /etc/fstab

-----
バックアップボリュームをマウントする行のオプションに
vers=1.0
を追加する
-----

他にも、/etc/fstab エントリや、 /etc/auto.master.d/ とかで cifs マウント設定が入っているところがある。vers=1.0 を追加しておこう。

No longer supported になっているパッケージを削除して再起動だ。

$ sudo apt-get remove gcc-5-base gcc-6-base tcpd

う～む。postfix が起動に失敗するなぁ。そもそも、aquarius には導入していない。どこで導入されたんだろうか…？
使ってないから削除しておこう。必要ならまた入れればいいからね。

$ sudo apt-get --simulate remove postfix
$ sudo apt-get remove postfix
$ sudo apt autoremove

再起動して、systemd が正しく動いているようなら、バックアップ取っておしまい。

次回以降、クラスタ再設定を行う。

あぁそうそう、18.04 の標準のネットワークは netplan になっている。
今回は 16.04 からそのまま引き継いで ifupdown にしていて、netplan には切り替えていない。
OpenvSwitch が netplan には対応していないようなので、そのまま ifupdown にしている。
もし、18.04 を素でインストールしたのなら、 netplan を削除して ifupdown を導入しないと駄目なので要注意。

16.04から18.04へバージョンアップ(aquarius)

さて、色々検証が中途半端になってしまったが、いい加減18.04にバージョンアップしよう。

過去に一度、sagittarius をバージョンアップしたが、別の問題が出てリストアしている。
今回はそのリベンジだ。

まずは慎重に、両サーバのパッチ適用(16.04の最新版)を行う。
aquarius から実行する。

$ sudo pcs cluster stop aquarius
$ sudo pcs cluster disable aquarius
$ sudo apt-get update
$ sudo apt-get dist-upgrade
$ sudo apt autoremove
$ sudo systemctl reboot
$ sudo pcs cluster enable aquarius
$ sudo pcs cluster start aquarius
$ sudo fence_scsi -o on -n aquarius -d /dev/mapper/fence-device

続いて sagittarius から実行。

$ sudo pcs cluster stop sagittarius
$ sudo pcs cluster disable sagittarius
$ sudo apt-get update
$ sudo apt-get dist-upgrade
$ sudo apt autoremove
$ sudo systemctl reboot
$ sudo pcs cluster enable sagittarius
$ sudo pcs cluster start sagittarius
$ sudo fence_scsi -o on -n sagittarius -d /dev/mapper/fence-device

両方のノードをバックアップしておこう。
バックアップスクリプトは今まで使用していたもので OK だ。

バックアップが終わったら、いよいよバージョンアップだ。
バージョンアップはコンソールから実行しよう。
aquarius から。

$ sudo pcs cluster stop aquarius
$ sudo pcs cluster disable aquarius
$ LANG=C sudo do-release-upgrade

途中、No longer supported として gcc-5-base gcc-6-base tcpd の3つがリストアップされた。まぁ不要なので、あとで削除しておけばいいか。
設定ファイル類の反映で、幾つかが「カスタマイズされているけど、ディストリビューター版を入れるか？今使っているものをそのまま使うか？」という選択肢が出てくる。

/etc/default/libvirt-guests
過去に有効にした ON_SHUTDOWN=shutdown が無効になる。
こちらは、ディストリビューター版を採用して、後で書き換えよう。

/etc/ssh/sshd_config
差分が多いが、外からログインする時の設定以外はディストリビューター版で良さそうだ。
後から、

PasswordAuthentication no
Match Address 192.68.55.0/24
 PasswordAuthentication yes
Match Address 127.0.0.0/8
 PasswordAuthentication yes

を書き加えることにする。

/etc/apt/apt.conf.d/50unattended-upgrades
こちらは、カーネル類を自動アップデートしないように明示的に指定している。
これ、多分ディストリビューター版をそのまま採用して問題無いだろう。
ちなみに、Unattended-Upgrade::Package-Blacklist { } に

"linux-headers-generic";
"linux-signed-generic";
"linux-signed-image-generic";

を足し込んでいる。

/etc/lvm/lvm.conf
こちらは、クラスタlvmを使用するために

locking_type = 3
use_lvmetad = 0

を指定しているが、ディストリビューター版を導入し、後から修正することにする。

無事にアップグレードが済み、リブートされたら、検証と設定の戻しを行おう。

$ sudo systemctl status
$ sudo systemctl --state=failed

lvm2-pvscan が一部失敗しているが、多分これは /etc/lvm/lvm.conf を修正すれば正しくなるはず。
設定ファイルを修正するのは以下の3ファイル
/etc/default/libvirt-guests
/etc/ssh/sshd_config
/etc/lvm/lvm.conf

/etc/lvm/lvm.conf は、直接編集するのではなく、コマンドで編集しよう。

$ grep -e locking_type -e use_lvmetad /etc/lvm/lvm.conf
$ sudo lvmconf --enable-cluster
$ grep -e locking_type -e use_lvmetad /etc/lvm/lvm.conf

/etc/ssh/sshd_config は直接編集する。

$ sudo vi /etc/ssh/sshd_config

-----
PasswordAuthentication が含まれている行(コメントになっているはずだ)を探し、その下に以下の行を追加する。
PasswordAuthentication no
最後に以下の行を追加する。
Match Address 192.168.55.0/24
        PasswordAuthentication yes
Match Address 127.0.0.0/8
        PasswordAuthentication yes
-----

/etc/default/libvirt-guests も直接編集だ。

$ sudo vi /etc/default/libvirt-guests

-----
ON_SHUTDOWN の行を探して、以下のように書き換える。(追加する)
ON_SHUTDOWN=shutdown
-----

ここまで編集したら、再起動しよう。

$ sudo systemctl reboot

あれ？リブートしたら、ネットワークの起動が上手く行かなかった。

$ sudo ifdown extsw
$ sudo ifup extsw

通信はできるな…。もう一度再起動してみる。

$ sudo systemctl reboot

やっぱり駄目だ。

見てみると、networking.service 起動時に、/var/run/openvswitch/db.sock が無い、というエラーになっている。
どうやら、ifupdown で使用する interface 定義、OpenvSwitch 関連のところが誤っていたようだ。(誤っていたのか、仕様が変わったのかは良くわからないが…)

ちょっと原因が違ったので、ここから先は全面書き換え。

ココを見ると、systemd の unit 定義が間違っているようだ。
なので、それの対応を行う。

$ sudo EDITOR=vi systemctl edit ovsdb-server.service

-----
以下のように作成
[Unit]
Before=networking.service
-----

$ sudo EDITOR=vi systemctl edit ovs-vswitchd.service

-----
以下のように作成
[Unit]
Before=networking.service
-----

再読込。

$ sudo systemctl daemon-reload
$ sudo systemctl list-dependencies --before ovsdb-server.service
$ sudo systemctl list-dependencies --before ovs-vswitchd.service

全面書き換えココまで

これで再起動したら、問題なく上がってくるはずだ。

ここで、クラスタへの組み直しをやってみたいところだが、corosync のバージョンが異なる機器間でクラスタを組もうとすると、内部DB(cib) のフォーマットが違うためか、マトモに動かない。
それどころか、syslog や corosync.log に大量にログが吐き出され、 /var/log がパンクしてしまうという事象が発生する。
そのため、クラスタ組み直しは、sagittarius のバージョンアップが終わってからにしよう。

最後に、No longer supported になっている3つのパッケージを削除しておこう。

$ sudo apt-get remove gcc-5-base gcc-6-base tcpd

とりあえずこれで、18.04へのバージョンアップは完了かな？
おっと、せっかく18.04へのバージョンアップが出来たので、バックアップを取っておくのを忘れないように。
だけど、18.04 にしてから CIFS へのアクセスが異常に遅くなった。
バックアップするのもシャレにならないほどの遅さだ。どうやら、cifsのデフォルトが変わったことによるものらしい。
aquarius はバックアップボリュームのマウントを、fstab で指定しているので、それを修正しよう。

$ sudo vi /etc/fstab

-----
バックアップボリュームをマウントする行のオプションに
vers=1.0
を追加する
-----

これで大丈夫なはず。

ちょっと長くなってしまったので、sagittarius のバージョンアップは次回。

ノード再起動で dlm がハング(他にも問題発生、一旦停止)

さて、次はノード再起動で dlm がハングするという現象の調査だ。

状況としては、vm-leo が稼働しているノードの OS を再起動すると、dlm がエラーを吐いて再起動が止まる、という状態だ。
調査していく過程で、何度か電源 Off/On を行うことになるので、コンソール前で実施しよう。また、強制停止を行う関係で、OS が壊れる可能性がある。sagittarius / aquarius の両方ともバックアップを取っておくこと。

では再現テストからだ。
vm-leo は sagittarius で動いている前提で進めていく。

最初は、vm-leo が動いていない方、aquarius を再起動してみる。

(aquarius) $ sudo systemctl reboot

特に vm-leo の稼働、sagittarius の稼働に影響は無かったはずだ。

aquarius が起動したら、fence_scsi の登録はしておこう。

(aquarius) $ sudo fence_scsi -o on -n aquarius -d /dev/mapper/fence-device
$ sudo pcs stonith cleanup

今度は sagittarius を再起動させてみよう。
この段階でハングしてしまうはずだ。PC のコンソールを使って実行したほうがいいだろう。

(sagittarius) $ sudo systemctl reboot

停止処理でハングするはず。

で、sagittarius がハングしている状態で aquarius 側からクラスタの状態を確認してみる。

(aquarius) $ sudo pcs status --full

vm-leo や pool-default の停止に失敗しているだろう。
暫く放置していると、aquarius 側でも dlm が異常をきたす。
こうなるともう、2台とも強制再起動(物理的にリセットスイッチを押す)しかなくなる。
これじゃ、HAクラスタとしては意味が無い。

2台とも強制再起動させて、クラスタを正常稼働させておこう。

(sagittarius) $ sudo fence_scsi -o on -n sagittarius -d /dev/mapper/fence-device
(aquarius) $ sudo fence_scsi -o on -n aquarius -d /dev/mapper/fence-device
$ sudo pcs stonith cleanup
$ sudo pcs status --full

今回、この現象を調査していたら、それとは別の問題を発見した。
2ノードクラスタなのだが、片方(例えば aquarius )がダウンしている状態で、生き残っている方( sagittarius )のクラスタを停止、起動すると、クォーラムは得られているにも関わらず、リソースが何も起動してこない、という状態だ。
片方のノードが故障で停止していても、生き残っている方で稼働・メンテナンス等は有り得る話なので、シングルノード状態でリソースが起動しないのは致命的だ。

ここまでボロボロと問題が出てくるのは、もしかしたら自分の実装手順がおかしいのではなく、Ubuntu16.04 の pacemaker にまだまだバグが含まれているのではないか？とまで疑うようになってきた。
本当は、これらの問題を 16.04 上で解決してから、18.04 にバージョンアップしようと思っていたのだが、18.04 のバージョンで解消している可能性もある。

中途半端になってしまったが、一旦 pacemaker 化の検証は止めて、18.04 にバージョンアップしていくことにする。

fence_scsi がコケる

リソースの再起動問題は解決したと思ったんだけど、次の作業である「ノード再起動で dlm がハング」を調査しようとしたら…クラスタ起動時に fence_scsi(scsi-fenceデバイス)がコケる、という事象が発生した。

調べて行ったら、前回行った作業( sudo pcs property set enable-startup-probes=false )で、scsi-fence デバイスの.keyファイル等が自動作成されなくなった、というのが原因。

一度試してみると分かる。

$ sudo pcs status

vm-leo が aquarius で稼働していないことを確認。
続いて、aquarius のクラスタを再起動させる。

$ sudo pcs cluster stop aquarius
$ sudo pcs cluster start aquarius

この状態では、問題なく aquarius がクラスタ参加するはずだ。
では、aquarius を OSごと再起動させてみよう。

$ sudo pcs cluster stop aquarius
(aquarius) $ sudo systemctl reboot

リブート後…

$ sudo pcs status

scsi-fence デバイスが aquarius 上で起動失敗、sagittarius で起動しているはずだ。
これは、/var/run/cluster にあるはずの fence_scsi.dev と fence_scsi.key ファイルが再作成されていないことが原因。
今まではクラスタ起動時に自動的に作成されていたようだから、問題なかった。
とりあえずこのままではよろしく無いので、再作成しておこう。

(aquarius) $ sudo fence_scsi -n aquarius -d /dev/mapper/fence-device  -o on

これで、/var/run/cluster にファイルが作成されたはずだ。

ただ、クラスタ上は aquarius 上で scsi-fence の起動に失敗した、という情報が残っているので、それもクリアしておこう。

$ sudo pcs stonith cleanup scsi-fence

これで一旦復旧。

さて、原因と対策なんだけど…。
調べたけどさっぱり分からない。ただなんとなく、Ubuntu18.04にバージョンアップしたら解決してる気がする。
なので、この先18.04にバージョンアップしてから再確認しよう。
それまでは、上に記載した暫定対処で回避することにする。

リソースが勝手に再起動する

謎な挙動が2つ見つかっているが、そのうち1つが「vm-leo が稼働してない方のノードのクラスタを停止・起動すると、vm-leo が再起動してしまう」というものだ。

vm-leo が sagittarius で稼働している状態で、leo にログインしたセッションを作り、sagittairus/aquarius のいずれかで以下のコマンドを実行するとわかる。

$ sudo pcs cluster stop aquarius
$ sudo pcs cluster start aquarius

で、どのタイミングで vm-leo が再起動するのかを調べるために、以下のように設定した。

$ sudo pcs constraint location pool-default-clone prefers aquarius=-INFINITY
$ sudo pcs constraint location shared-pool-clone prefers aquarius=-INFINITY
$ sudo pcs constraint location clvmd-clone prefers aquarius=-INFINITY
$ sudo pcs constraint location dlm-clone prefers aquarius=-INFINITY

つまり、aquarius では、vm-leo 以外のすべてのリソースの自動起動を停止した。
(vm-leo 自体は、前提となる pool-default-clone が起動しないと起動しないし、そもそも sagittarius 上で起動しているので、aquarius が起動しても影響ないはずなのだが…)

その状態で、まず aquarius のクラスタの停止・起動を実行する。

$ sudo pcs cluster stop aquarius
$ sudo pcs cluster start aquarius

なんと、aquarius のクラスタ起動だけで、vm-leo が再起動してしまう。

ということは、クラスタパラメータが関係しているということだ。

$ sudo pcs property show --all

それっぽいパラメータは、enable-startup-probes か。
デフォルト値は true なので、 false に設定してみよう。

$ sudo pcs property set enable-startup-probes=false
$ sudo pcs property show --all

これで aquarius のクラスタ停止・起動を実行してみる。

$ sudo pcs cluster stop aquarius
$ sudo pcs cluster start aquarius

vm-leo は再起動しなかったと思う。

続いて、リソースを一つずつ許可してみよう。
まずは dlm-clone

$ sudo pcs constraint remove location-dlm-clone-aquarius--INFINITY

大丈夫のようだ。
次は clvmd-clone

$ sudo pcs constraint remove location-clvmd-clone-aquarius--INFINITY

ここで vm-leo が再起動してしまう。
更に先を確認するために、vm-leo が復帰したら、shared-pool-clone も確認しておこう。

$ sudo pcs constraint remove location-shared-pool-clone-aquarius--INFINITY

ここでも vm-leo が再起動してしまう。
最後に、pool-default-clone だ。vm-leo が復帰してから試してみよう。

$ sudo pcs constraint remove location-pool-default-clone-aquarius--INFINITY

ここでは vm-leo の再起動は発生しない。

vm-leo の基盤となるリソースのうち、clvmd-clone と shared-pool-clone のリソースが起動すると、vm-leo が再起動する。

corosync.log をチェックしてみたら、clvmd-clone が起動すると、なぜか pool-default-clone と vm-leo が restart していた。
clvmd-clone と pool-default-clone の間には、shared-pool-clone が入っているが、そちらは restart になっていない。
う～ん。ということは、clone リソースに何か違いが？
と調べてみたら、いくつか違いがあった。

• dlm-clone
• interleave=true
• ordered=true
• clvmd-clone
• interleave=true
• ordered=true
• shared-pool-clone
• interleave=true
• ordered=(未設定:false)
• pool-default-clone
• interleave=(未設定:false)
• ordered=(未設定:false)

コレ、clone リソース固有のパラメータのようだ。
っていうか、interleave パラメータが関係あるんじゃないか？
というわけで設定してみよう。

$ sudo pcs resource update pool-default-clone meta interleave=true
$ sudo pcs resource show pool-default-clone

そしてもう一度テスト。

$ sudo pcs constraint location pool-default-clone prefers aquarius=-INFINITY
$ sudo pcs constraint location shared-pool-clone prefers aquarius=-INFINITY
$ sudo pcs constraint location clvmd-clone prefers aquarius=-INFINITY
$ sudo pcs constraint location dlm-clone prefers aquarius=-INFINITY

$ sudo pcs constraint remove location-dlm-clone-aquarius--INFINITY
$ sudo pcs constraint remove location-clvmd-clone-aquarius--INFINITY

先程はここで vm-leo が再起動してしまったが、今回は大丈夫のようだ。

$ sudo pcs constraint remove location-shared-pool-clone-aquarius--INFINITY

今回、ここでも大丈夫のようだ。

$ sudo pcs constraint remove location-pool-default-clone-aquarius--INFINITY

こちらは問題なし。

というわけで、interleave=true の設定が必要だった。
振り返って過去の設定を見てみたら、ちゃんと interleave=true の設定を入れていた。
ちゃんと設定項目の意味を理解してれば、こんなに悩まなかったのに…。

リソースが勝手に再起動する問題はこれで解決かな？

仮想マシンのクラスタリソース化その2

とりあえず vm-leo が動くところまで行った。
今度はこのリソースを細かく設定する。

まず、リソースの実行順。
vm-leo 自体は、default プールを使用している。そのため、vm-leo の起動の前提条件として、 default プールの有効化、つまり pool-default-clone を前提にする必要がありそうだ。
それを設定する。

$ sudo pcs constraint order start shared-pool-clone then vm-leo

続いて、リソースの実行条件。
当然、shared-pool の起動に成功したノードと同じノードでないと、vm-leo を動かすわけにはいかない。
その制約をつける。

$ sudo pcs constraint colocation add vm-leo with shared-pool-clone

このままでもいいんだけど、何故かいつも aquarius から起動しようとしてしまう。
gemini/cancer でクラスタ組んで、簡単なリソーステストを行っていた時も、 gemini をプライマリノードにしたいのに、なぜか cancer から起動しようとしてた。
多分、ノード名のアルファベット順で若い方を優先してしまうのではないか？と思っている。
で、vm-leo は sagittarius をプライマリノード、aquarius をスレーブノードとして定義したい。
(sagittarius に問題が無ければ sagittarius で起動、問題がある場合は aquarius で起動、みたいな)
以下のように実行する。

$ sudo pcs resource cleanup vm-leo
$ sudo pcs constraint location vm-leo prefers sagittarius=100 aquarius=50
$ sudo pcs resource enable vm-leo
$ sudo pcs status

どうだろう？ vm-leo は sagittarius で起動してきたのではないだろうか？

今回は一旦ココまでにするが、まだ問題が2つ残っている。

1. vm-leo が稼働していない方のノードのクラスタを停止・起動すると、vm-leo が再起動してしまう
2. vm-leo が稼働しているノードを再起動しようとすると、dlm がハングしてしまう

の2点だ。
ちょっと調べたがまだ解決していない。
解決できるか分からないが、次回からちょっと調査をする。

仮想マシンのクラスタリソース化その1

これまでの作業で、 gfs2 を pacemaker で運用する方法が固まった。

で、 pacemaker を調べていく過程で、リソースエージェントに ocf:redhat:vm.sh と ocf:heartbeat:VirtualDomain の2つが存在することに気付いた。
これ、KVM等の仮想マシンをリソース化するものっぽい。
ってことは、pcs コマンドで仮想マシンを起動停止させたり、sagittarius から aquarius へのマイグレーションが出来たりするのかもしれない。

pacemaker化 の最後に、これを試してみたい。
リソースエージェントに redhat版と heartbeat版 があるのだが、これまでずっと heratbeat版 を使っていたので、今回も heartbeat版 で進めてみる。

まずは設定内容の確認

$ sudo pcs resource describe ocf:heartbeat:VirtualDomain

必須パラメータは config だけだけど、libvirt自体は様々なハイパーバイザに対応しているので、qemu/kvm用のハイパーバイザを指定する必要はある。
それ以外はとりあえずデフォルトのままで作ってみよう。仮想マシンは leo でいいかな？

$ sudo pcs resource create vm-leo \
 ocf:heartbeat:VirtualDomain \
 config="/etc/libvirt/qemu/leo.xml" \
 hypervisor="qemu:///system" \
 meta op start timeout="120s"
$ sudo pcs status

おっと！？いきなりコケてるぞ？いや、ちょっと待ってから再確認すると、vm-leo を aquarius で起動しようとして失敗し、sagittarius で起動成功、という流れのようだ。

いろいろ調査したんだけど、非常にツマらない理由だった。
今回の pacemaker化 の主旨とは全く異なるポイントだったんだけど、メモしておく。

この辺りは、各人の持っているPCのスペックに依るところが大きいので、あくまで参考程度に見てほしい。

それぞれのホストマシンで使っているCPUは以下の通り。

• sagittarius : Intel core i7-6700
• aquarius : Intel core i7-5557U

CPUの世代が1世代違うだけでなく、aquarius の方はノート用の省電力モデルだ。
で、5557UというCPU、Broadwell世代なんだけど、TSXという機能に対応していない。

で、仮想マシン leo の方の仮想CPU定義はと言うと… Broadwell にしている。
仮想マシンのCPU定義が Broadwell の場合、ホスト側のCPUにもTSXという機能が必要なので、5557U というCPU上で動かすことは出来ない。
仮想マシン側の CPU定義を Broadwell-noTSX か、それ以下のモデルにする必要があるようだ。
つまり、今までパワーのある sagtitarius 上で色々検証していたけど、実は aquarius では動かない検証をしていた、ということだ。ナンテコッタイ。

調べてみたら、多くの仮想マシンが仮想CPUを Broadwell と指定してて、ほとんど aquarius では動かせないことが判明。
とりあえず leo だけでも直しておこう。

まずは vm-leoリソースを停止。

$ sudo pcs resource disable vm-leo
$ sudo pcs status
(sagittarius) $ virsh list --all
(aquarius) $ virsh list --all

leoが止まっているのを確認しておく。

そしたら、leo の定義変更だ。

(aquarius) $ virsh edit leo
(sagittarius) $ virsh edit leo

---
cpuの <model> の部分を Broadwell から Broadwell-noTSX に書き換える。
---

変更出来たら、まずは各ノードで手作業で上げてみよう。

(aquairus) $ virsh start leo
(aquarius) $ virsh list --all

起動したら leo にログインして、シャットダウンしておこう。

(leo) $ sudo systemctl poweroff

sagittarius でも。

(sagittarius) $ virsh start leo
(sagittarius) $ virsh list --all

起動確認が出来たら leo をシャットダウンしておく。

(leo) $ sudo systemctl poweroff

ココまでが、各人の環境に応じて差が出る部分だ。

leo が両ノードで動かせるのが確認できたら、vm-leoリソースをクリーンナップして起動してみる。

$ sudo pcs resource cleanup vm-leo
$ sudo pcs resource enable vm-leo
$ sudo pcs status

今度は無事に aquarius で動き出した。
aquarius 側で virsh を使ってみると、動いていることがわかるはずだ。

(aquarius) $ virsh list --all

これで vm-leo が動かせるようになったが、まだ設定しておかなければならない項目がある。
起動条件、起動順と起動ノードの優先順、マイグレーション設定だ。
ちょっと長くなってしまったので、これは次回に回す。
っとその前に、vm-leo を停止させて、自動的に上がってこないように抑えておこう。

$ sudo pcs resource disable vm-leo
$ sudo pcs status

systemd設定見直し

随分前の話になるが、初めて dlm/clvmd/gfs2 と openvswitch を導入した時、OSの起動停止が上手く行かず、原因を systemd の起動順や起動速度だと思って、 systemd の各 unit ファイルをいじった。

ここまでの作業で、 corosync.conf の設定内容が pacemaker によって大幅に変更されたり、 dlm を systemd 起動ではなく pacemaker から起動するように変更された。
もしかしたら、これまで問題としていた内容は、これによって解消しているのでは？ということで、 systemd の設定を元に戻してみる。
これまで弄ってきたファイルは、 /etc/systemd/system と /lib/systemd/system の以下のファイルだと思う。

• corosync.service
• openvswitch-switch.service
• lvm2-cluster-activation.service
• lvm2-clvmd.service
• open-iscsi.service

この内、open-iscsi.service はアップデートの過程で元のファイルに戻っているので、バックアップファイルだけ削除すれば OK のはず。
他にも弄っているファイルがあるかもしれないので、各自対応しておこう。

っと、systemd を弄る前に、個別にクラスタを止めておいた方がいいな。

(aquarius) $ sudo pcs cluster stop aquarius
(aquarius) $ sudo systemctl stop corosync
(aquarius) $ sudo systemctl stop pacemaker
(aquarius) $ sudo systemctl stop pcsd
(aquarius) $ mkdir ~/systemd.unit
(aquarius) $ sudo mv /etc/systemd/system/corosync.service ~/systemd.unit/
(aquarius) $ sudo mv /etc/systemd/system/openvswitch-switch.service ~/systemd.unit/
(aquarius) $ sudo mv /lib/systemd/system/lvm2-cluster-activation.service ~/systemd.unit/
(aquarius) $ sudo mv /lib/systemd/system/lvm2-cluster-activation.service.orig /lib/systemd/system/lvm2-cluster-activation.service
(aquarius) $ sudo mv /lib/systemd/system/lvm2-clvmd.service ~/systemd.unit/
(aquarius) $ sudo mv /lib/systemd/system/lvm2-clvmd.service.orig /lib/systemd/system/lvm2-clvmd.service
(aquarius) $ sudo rm /lib/systemd/system/open-iscsi.service.orig

systemd の unit ファイルを再読込して、OS ごと再起動してみよう。

(aquarius) $ sudo systemctl daemon-reload
(aquarius) $ sudo systemctl reboot

う～ん。やっぱり corosync.service の起動に失敗する。
OpenvSwitch より後に起動させる必要があるみたいだな。

(aquarius) $ sudo EDITOR=vi systemctl edit corosync.service

---空のエディタが起動するので、以下のように作成

[Unit]
After=openvswitch-nonetwork.service
[Service]
ExecStartPre=/bin/sleep 5

---
これでいいのかな？

(aquarius) $ sudo systemctl daemon-reload
(aquarius) $ sudo systemctl reboot

どうやら上手くいったよう。
sagittarius にも同じ作業を適用しておこう。