ラベル OpenvSwitch の投稿を表示しています。 すべての投稿を表示
ラベル OpenvSwitch の投稿を表示しています。 すべての投稿を表示

2019年7月7日日曜日

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 のバージョンアップは次回。

2017年12月20日水曜日

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/ の方に移しておこう。

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

2017年10月21日土曜日

あれ?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)が落ちてしまった時の復旧手順が特殊なんだろう。おそらく、落ちたノードを単純に再起動するだけじゃダメだ。
この辺りをきちんと検証しないといけないなぁ。

2017年6月13日火曜日

OpenvSwitch による VLAN 検証(その4)

さて続けて…。
今度はこちらの記事の6枚目~9枚目(最後)の画像部分に挑戦。

現在、leo / virgo ともに起動していると思う。
leo 側の設定を変更したいので、leo を停止するが、virgo から leo に向けて ping を打ち続けよう。
(virgo) $ ping 192.168.57.138

virgo → leo の ping を打ち続けたまま、leo を停止させる。
(leo) $ sudo systemctl poweroff
leo が停止されたら、virgo → leo の ping も通信出来なくなるはず。ping はそのまま置いておく。

vlan10 に接続していた leo を、vlan20 に接続し直す。
(gemini) $ virsh edit leo
--ココから
<interface type='network'>~</interface> の間の1行を修正。
<source network='vlan10'/>

<source network='vlan20'/>
--ココまで

更新が出来たら、leo を起動させよう。
(gemini) $ virsh start leo

leo が起動するまでの間、ping を打ち続けている virgo の方をチェック。
通信が回復しないはずだ。
異なる vlanスイッチなので、通信が回復しなくて当然、のはず。

今度は virgo を vlan20 のスイッチに繋ぎ替える。
leo から virgo へ ping を打ち続けよう。
(leo) $ ping 192.168.57.139
当然、通信は出来ていないはず。

このまま ping を放置して、virgo の接続先スイッチを切り替える。
virgo の停止
(virgo) $ sudo systemctl poweroff

virgo の接続先の切り替え
(cancer) $ virsh edit virgo
--ココから
<interface type='network'>~</interface> の間の1行を修正。
<source network='vlan10'/>

<source network='vlan20'/>
--ココまで

そしたら virgo を起動。
(cancer) $ virsh start virgo

起動中、virgo に ping を打ち続けている leo の画面をチェックしよう。
期待した通りなら、通信が復旧するはずだ。

う~む。今回は全て、期待した通りの動きになった。
おかげで検証もスムーズに進んだ。
VLAN は恐らく、OpenStack 等を使う時に意識しておく必要があると思うから、検証がスムーズに出来てよかった。

さて、OpenvSwitch を使った VLAN の構築検証はココまでにして、次は何に着手しようかな?

OpenvSwitch による VLAN 検証(その3)

やっと前回、vlan10 と vlan20 のスイッチが作られた。

今度は仮想マシン leo / virgo を vlan10 のスイッチに繋いでテストだ。
こちらの4枚目と5枚目の画像の作業になる。

まずは leo / virgo に追加した2枚目の NIC を、vlan10 のスイッチに繋ぎ替える。
virt-manager でもいいが、今回は virsh edit を使うことにする。
(gemini) $ virsh edit leo
(gemini) $ virsh edit virgo
--ココから
<interface type='network'>~</interface> が2セットある。この内の2つ目の方のセットを修正する。
<source network='ovsbridge'/>

<source network='vlan10'/>
--ココまで

gemini 側で修正したら、 cancer 側にも反映させる。
(cancer) $ virsh dumpxml leo
(cancer) $ virsh dumpxml virgo
(cancer) $ sudo systemctl reload libvirt-bin.service
(cancer) $ virsh dumpxml leo
(cancer) $ virsh dumpxml virgo

反映されたことが確認できたら、それぞれ仮想マシンを起動しよう。
(gemini) $ virsh start leo
(cancer) $ virsh start virgo

起動したらそれぞれにログイン。
さて、ping による疎通が出来るのだろうか…?
(leo) $ ip address show ens10
(virgo) $ ip address show ens10

(leo) $ ping 192.168.57.139
(virgo) $ ping 192.168.57.138

どうやら通信できるようだ。
でも、通信出来るから OK というわけではなく、コチラの残りの部分(画像6枚目以降)も出来ることが確認できて、始めて VLAN が作動していることになるわけで。
まだ楽観視出来ないな…。

OpenvSwitch による VLAN 検証(その2)

続いて、VLAN-ID を持った仮想スイッチってやつを作ってみたい。
このページの4枚目の図だ。

作成するのは gemini / cancer 上。
まずは、それぞれのネットワーク設定からだ。
(gemini) $ sudo vi /etc/network/interfaces.d/0020.vlan10
--ココから
auto vlan10
allow-extsw
iface vlan10 inet manual
ovs_bridge extsw
ovs_type OVSIntPort
ovs_options tag=10
--ココまで

(gemini) $ sudo vi /etc/network/interfaces.d/0030.vlan20
--ココから
auto vlan20
allow-extsw
iface vlan20 inet manual
ovs_bridge extsw
ovs_type OVSIntPort
ovs_options tag=20
--ココまで

(gemini) $ sudo vi /etc/network/interfaces.d/0010.extsw
--ovs_ports ens3 の下に2行追加
ovs_ports vlan10
ovs_ports vlan20
--ココまで

(gemini) $ sudo vi /etc/default/networking
--1行修正
EXCLUDE_INTERFACES=extsw

EXCLUDE_INTERFACES="extsw vlan10 vlan20"
--

cancer でも同じ設定を。
(cancer) $ sudo vi /etc/network/interfaces.d/0020.vlan10
--ココから
auto vlan10
allow-extsw
iface vlan10 inet manual
ovs_bridge extsw
ovs_type OVSIntPort
ovs_options tag=10
--ココまで

(cancer) $ sudo vi /etc/network/interfaces.d/0030.vlan20
--ココから
auto vlan20
allow-extsw
iface vlan20 inet manual
ovs_bridge extsw
ovs_type OVSIntPort
ovs_options tag=20
--ココまで

(cancer) $ sudo vi /etc/network/interfaces.d/0010.extsw
--ovs_ports ens3 の下に2行追加
ovs_ports vlan10
ovs_ports vlan20
--ココまで

(cancer) $ sudo vi /etc/default/networking
--1行修正
EXCLUDE_INTERFACES=extsw

EXCLUDE_INTERFACES="extsw vlan10 vlan20"
--

続いて、bridge の作成
(gemini) $ sudo ovs-vsctl show
(gemini) $ sudo ovs-vsctl add-br vlan10 extsw 10
(gemini) $ sudo ovs-vsctl add-br vlan20 extsw 20
(gemini) $ sudo ovs-vsctl show

(cancer) $ sudo ovs-vsctl show
(cancer) $ sudo ovs-vsctl add-br vlan10 extsw 10
(cancer) $ sudo ovs-vsctl add-br vlan20 extsw 20
(cancer) $ sudo ovs-vsctl show

これでいいのかな…?
leo / virgo を停止させ、gemini / cancer を再起動、反映されているか確認。
(leo) $ sudo systemctl poweroff
(virgo) $ sudo systemctl poweroff
(gemini) $ sudo systemctl reboot
(cancer) $ sudo systemctl reboot
(gemini) $ sudo ovs-vsctl show
(cancer) $ sudo ovs-vsctl show

これで、VLANタグ付きのスイッチが出来た…はず…。

作った VLANタグスイッチを、 libvirt に登録しよう。
(gemini) $ vi vlan10.xml
--ココから
<network>
<name>vlan10</name>
<forward mode='bridge'/>
<bridge name='vlan10'/>
<virtualport type='openvswitch'/>
</network>
--ココまで

(gemini) $ vi vlan20.xml
--ココから
<network>
<name>vlan20</name>
<forward mode='bridge'/>
<bridge name='vlan20'/>
<virtualport type='openvswitch'/>
</network>
--ココまで

(gemini) $ virsh net-list --all
(gemini) $ virsh net-define vlan10.xml
(gemini) $ virsh net-define vlan20.xml
(gemini) $ virsh net-list --all

(gemini) $ virsh net-autostart vlan10
(gemini) $ virsh net-autostart vlan20
(gemini) $ virsh net-start vlan10
(gemini) $ virsh net-start vlan20
(gemini) $ virsh net-list --all

cancer 側で取り込む。(libvirt 関連の情報は共有ディスク上にあるはずなので、cancer 側は再読込でOKのはず。)
(cancer) $ virsh net-list --all
(cancer) $ sudo systemctl reload libvirt-bin.service
(cancer) $ virsh net-list --all

これで VLAN付きスイッチの libvirt への登録も完了だ。
次は leo / virgo のネットワーク設定を変更して起動する流れだが、これは次回に。

OpenvSwitch による VLAN 検証(その1)

とりあえず、前述の図の3枚目までを実施してみる。

まずは leo / virgo を停止させよう。
(leo) $ sudo systemctl poweroff
(virgo) $ sudo systemctl poweroff

停止の確認が出来たら、gemini で virt-manager を起動し、leo / virgo に NIC を追加させる。
(gemini) $ virt-manager
NICを追加し、今まで使用していたものと
同じスイッチに繋ぐ

NIC追加したら、一度構成を見直してみよう。
(gemini) $ virsh edit leo
(gemini) $ virsh edit virgo
<interface type='network'>タグが2つあると思う。
2つ目の<interface ...>タグの<address ...>タグ、slot='0xNN'を見てみて欲しい。
0x0a になっていると思うけど、異なる値になっているかもしれない。
ココは leo / virgo で値を合わせておこう。(ここの値を 0x0a にした場合、ゲストOS leo / virgo の追加NICのデバイス名は ens10 になる)

仮想マシンの設定変更が完了したら、cancer 側にも反映させよう。
(cancer) $ sudo systemctl reload libvirt-bin.service
(cancer) $ virsh dumpxml leo
(cancer) $ virsh dumpxml virgo
(もし反映されてなかったら、 sudo systemctl restart libvirt-bin.service で再起動だ。)

設定反映が確認できたら、gemini 上で leo を、cancer 上で virgo をそれぞれ起動しよう。
(gemini) $ virsh start leo
(cancer) $ virsh start virgo

起動が完了したら、ネットワークインターフェースを確認。
(leo) $ ip link show
(virgo) $ ip link show
ens10 というネットワークインターフェース(NIC)が出来ているのが確認できるはずだ。

この NIC に IP アドレスを付与しよう。
今回は
leo : 192.168.57.138/24
virgo : 192.168.57.139/24
を充てる。
(普段使っている ens3 には、192.168.55.x/24 のIPアドレスが付与されている。ens10 には ens3 とは異なるネットワークアドレスを充てるように。)
(leo) $ sudo vi /etc/network/interfaces.d/ens10
--ココから
auto ens10
iface ens10 inet static
address 192.168.57.138
network 192.168.57.0
netmask 255.255.255.0
broadcast 192.168.57.255
--ココまで

(virgo) $ sudo vi /etc/network/interfaces.d/ens10
--ココから
auto ens10
iface ens10 inet static
address 192.168.57.139
network 192.168.57.0
netmask 255.255.255.0
broadcast 192.168.57.255
--ココまで

IPアドレスが付与されるか確認。(leo / virgo ともに同じ操作だ)
(leo) $ ip address show ens10
(leo) $ sudo ifup ens10
(leo) $ ip address show ens10

(virgo) $ ip address show ens10
(virgo) $ sudo ifup ens10
(virgo) $ ip address show ens10

OS 再起動して確認しよう。
(leo) $ sudo systemctl reboot
(virgo) $ sudo systemctl reboot
(leo) $ ip address show ens10
(virgo) $ ip address show ens10

IP アドレスの付与が出来たら、相互に ping を打って、疎通が取れることも確認しておく。
(leo) $ ping 192.168.57.139
(virgo) $ ping 192.168.57.138

今回はココまで。
次回は gemini / cancer に VLAN-ID 付きの仮想スイッチを作ってみる。

2017年6月12日月曜日

OpenvSwitch による VLAN 検証(概要)

さて、leo / virgo という仮想マシンが出来上がったところで、OpenvSwitch を用いた VLAN の検証をしてみたい。
と言っても、OpenvSwitch の癖がまだ掴めていないし、そもそも出来るのかどうかも不明。
イメージとしては、以下の図のように実装出来ると考えている。
スタート時の状態
(NIC は1つずつ)

仮想マシンに NIC を追加し、IPを付与。
これまで使っていた仮想スイッチにそのまま繋ぐ。

新しいIPアドレスで、仮想マシン同士の通信が可能

VLAN10 / VLAN20 のスイッチを作成し、既存スイッチへ接続
仮想マシンを VLAN10 経由に繋ぎ替える

同じ VLAN 同士なので通信できるはず

leo を VLAN10 から VLAN20 へ繋ぎ替える

異なる VLAN なので通信できないはず

virgo を VLAN20 へ繋ぎ替える

同じVLANになったので、また通信可能になる
はず

実は既に、最初の3枚分は実施している。
そんなに難しいことはやっていないので、次回から順番に書いていくことにする。

2017年6月6日火曜日

cancer の IP固定化&OpenvSwtich

続いて、cancer の IP を固定化する。
これ、ついでに OpenvSwitch も設定してしまう予定だ。
過去に何度か実施しているので、その辺りを探してみればいいけど、一応コマンド入れておく。

(cancer) $ ip link show
(cancer) $ sudo ovs-vsctl show
(cancer) $ sudo ovs-vsctl add-br extsw
(cancer) $ sudo ovs-vsctl show

(cancer) $ sudo vi /etc/default/networking
--ココから
1行編集
#EXCLUDE_INTERFACES=

EXCLUDE_INTERFACES=extsw
--ココまで

(cancer) $ sudo vi /etc/network/interfaces.d/0110.ens3
--ココから
auto ens3
allow-extsw
iface ens3 inet manual
ovs_bridge extsw
ovs_type OVSPort
--ココまで

(cancer) $ sudo vi /etc/network/interfaces.d/0010.extsw
--ココから
auto extsw
allow-ovs extsw
iface extsw inet static
address 192.168.55.137
network 192.168.55.0
netmask 255.255.255.0
broadcast 192.168.55.255
gateway 192.168.55.1
ovs_type OVSBridge
ovs_ports ens3

dns-nameservers 192.168.55.1
--ココまで

(cancer) $ sudo ifdown ens3
(cancer) $ sudo vi /etc/network/interfaces
--ココから
2行コメント化
auto ens3
iface ens3 inet dhcp

#auto ens3
#iface ens3 inet dhcp
--ココまで

(cancer) $ sudo ovs-vsctl add-port extsw ens3
(cancer) $ sudo ovs-vsctl show
(cancer) $ sudo ifup ens3
(cancer) $ sudo ifup extsw
(cancer) $ ip address show
(cancer) $ sudo systemctl daemon-reload
(cancer) $ sudo systemctl reboot
(cancer) $ ip address show

これで IP アドレスは元通りになったけど、ssh ホスト鍵が異なるので、ssh クライアントから接続する時にエラーになると思う。
クライアント側の known_hosts をいじることになるので、各クライアント毎に対処しよう。

あ、忘れてた。
合わせて、ssh鍵認証出来るように設定しておこう。
gemini の ~/.ssh/authorized_keys と同じ内容のファイルを、cancer 側の同じパスに作っておくだけでいいぞ。

2017年5月26日金曜日

シャットダウン時に刺さる現象再び!

シャットダウン・リブート時にハングする現象、ココで暫定対策を施しておいたんだけど、また再発した。
遠隔からリブート仕掛けたらハングしてしまったので、何が起きたのかは分からず。
帰宅後にコンソールを見てみてもよく分からなかった。

ただ、どうも dlm 絡みのような気がしてならない。
問題が起きたから dlm がトラブったのか、dlm がトラブったから問題が発生したのか、どちらが主要因かは分からない。

何せ、再現性に乏しいのが辛いところ。

とりあえず、lvm2-cluster-activation.service の停止処理の sleep 10 と、openvswitch-switch.service の起動処理の sleep 10 を、sleep 20 に伸ばしてみた。
直接の原因が分からないので、これが効果あるのかどうかも分からない。

取り急ぎ、これで逃げておくことにする。

2017年5月16日火曜日

OpenvSwitch と open-iscsi の起動停止順

今度は、主題の通りの件だ。
gemini / cancer のペアの時に、ココで実施した内容の前半部分になる。
こちらも、sagittarius / aquarius で同時に実施する。
#例によって、仮想マシンは停止しておいてくれ。

$ cd /lib/systemd/system
$ sudo cp -pi open-iscsi.service open-iscsi.service.orig
$ sudo vi open-iscsi.service
--ココから
Wants=network-online.target remote-fs-pre.target iscsid.service
After=network-online.target iscsid.service
↓(前提条件に openvswitch-switch.service を追加)
Wants=network-online.target remote-fs-pre.target iscsid.service openvswitch-switch.serivce
After=network-online.target iscsid.service openvswitch-switch.service
--ココまで

$ sudo systemctl daemon-reload

この状態で再起動して、刺さる現象が消えたかどうか…。
$ df
(iscsi領域がマウントされていること)
$ sudo systemctl reboot

とりあえずOK。
次は multipathd の導入かな?

2017年5月15日月曜日

aquarius の仮想スイッチ名称変更(br-external→extsw)

続いて、同じ作業を aquarius に施す。
デバイス名、IPアドレスが異なるだけで、作業内容はまったく一緒だ。

ネットワーク設定ファイルの準備
(aquarius) $ sudo -i
(aquarius) # cd /etc/network/interfaces.d
(aquarius) # cp -pi 0010.br-external /root/0010.extsw
(aquarius) # vi /root/0010.extsw
--一部書き換え
auto br-external
allow-ovs br-external
iface br-external inet static
address 192.168.55.131
network 192.168.55.0
netmask 255.255.255.0
broadcast 192.168.55.255
gateway 192.168.55.1
ovs_type OVSBridge
ovs_ports enp0s25

dns-nameservers 192.168.55.1

auto extsw
allow-ovs extsw
iface extsw inet static
address 192.168.55.131
network 192.168.55.0
netmask 255.255.255.0
broadcast 192.168.55.255
gateway 192.168.55.1
ovs_type OVSBridge
ovs_ports enp0s25

dns-nameservers 192.168.55.1
--ココまで

(aquarius) # cp -pi 0110.enp0s25 /root/0110.enp0s25.new
(aquarius) # vi /root/0110.enp0s25.new
--一部書き換え
auto enp0s25
allow-br-external enp0s25
iface enp0s25 inet manual
ovs_bridge br-external
ovs_type OVSPort

#auto enp0s25
allow-extsw enp0s25
iface enp0s25 inet manual
ovs_bridge extsw
ovs_type OVSPort
--ココまで

(aquarius) # exit

続いて、OpenvSwitch の設定変更用のコマンドを作っておく。
(aquarius) $ vi 0001_ovs-vsctl_show
--ココから
sudo ovs-vsctl show
--ココまで

(aquarius) $ vi 0002_ovs-vsctl_add-br_extsw
--ココから
sudo ovs-vsctl add-br extsw
--ココまで

(aquarius) $ ln -s 0001_ovs-vsctl_show 0003_ovs-vsctl_show
(aquarius) $ vi 0004_ovs-vsctl_del-port_br-external_enp0s25
--ココから
sudo ovs-vsctl del-port br-external enp0s25
--ココまで

(aquarius) $ ln -s 0001_ovs-vsctl_show 0005_ovs-vsctl_show
(aquarius) $ vi 0006_ovs-vsctl_add-port_extsw_enp0s25
--ココから
sudo ovs-vsctl add-port extsw enp0s25
--ココまで

(aquarius) $ ln -s 0001_ovs-vsctl_show 0007_ovs-vsctl_show

ネットワークの切断が発生するため、ゲストOSは全て停止しておこう。
(aquarius) $ virsh list --all
稼働しているゲストOSは片っ端から停止だ。

同様に、ネットワーク経由のファイルシステム等は全て切断だ。
(aquarius) $ sudo systemctl stop /etc/libvirt
(aquarius) $ sudo systemctl stop /var/lib/libvirt
(aquarius) $ sudo systemctl stop /var/log/libvirt
(aquarius) $ sudo systemctl stop /mnt/iso-os

(aquarius) $ sudo vgchange -a n vg-kvm

(aquarius) $ iscsiadm -m session
(aquarius) $ sudo systemctl stop open-iscsi.service
(aquarius) $ iscsiadm -m session

ここまで準備が整ったら、直接コンソールで作業だ。
(aquarius) $ ip address show
(aquarius) $ sudo mv /etc/network/interfaces.d/0010.br-external /root/
(aquarius) $ sudo mv /etc/network/interfaces.d/0110.enp0s25 /root/
(aquarius) $ sudo mv /root/0010.extsw \
/etc/network/interfaces.d/0010.extsw
(aquarius) $ sudo mv /root/0110.enp0s25.new \
/etc/network/interfaces.d/0110.enp0s25

(aquarius) $ bash 0001_ovs-vsctl_show
(aquarius) $ bash 0002_ovs-vsctl_add-br_extsw
(aquarius) $ bash 0003_ovs-vsctl_show
(aquarius) $ bash 0004_ovs-vsctl_del-port_br-external_enp0s25
(aquarius) $ bash 0005_ovs-vsctl_show
(aquarius) $ bash 0006_ovs-vsctl_add-port_extsw_enp0s25
(aquarius) $ bash 0007_ovs-vsctl_show

(aquarius) $ sudo systemctl daemon-reload
(aquarius) $ sudo systemctl reboot
--コンソール作業ココまで

これでまた、ssh でログイン出来るだ。
(aquarius) $ ip address show

ネットワーク経由のファイルシステム等の確認。
(aquarius) $ iscsiadm -m session
(aquarius) $ df

KVM仮想スイッチの定義を、今までの br-external から、新しい extsw に変更。
(aquarius) $ virsh net-list --all
(aquarius) $ virsh net-edit ovsbridge
--以下のように修正
<bridge name='br-external'/>

<bridge name='extsw'/>
--ココまで

以前まで使っていた br-external は削除しよう。
(aquarius) $ sudo ovs-vsctl show
(aquarius) $ sudo ovs-vsctl del-br br-external
(aquarius) $ sudo ovs-vsctl show

これでいいはずだ。
念のためにもう一度 OS 再起動して確認しておこう。
(aquarius) $ sudo systemctl reboot
(aquarius) $ ip address show
(aquarius) $ systemctl status

必要に応じて、仮想マシンの起動停止も確認しておくこと。

これで aquarius での作業は完了。
次は、networking.service の修正だ。

sagittarius の仮想スイッチ名称変更(br-external→extsw)

というわけで最初の作業だ。
この作業は、既にココで記載しているのとほぼ同じやり方になるが、ちょっとやり方を変えることにする。

ネットワーク設定ファイルの準備
(sagittarius) $ sudo -i
(sagittarius) # cd /etc/network/interfaces.d
(sagittarius) # cp -pi 0010.br-external /root/0010.extsw
(sagittarius) # vi /root/0010.extsw
--一部書き換え
auto br-external
allow-ovs br-external
iface br-external inet static
address 192.168.55.130
network 192.168.55.0
netmask 255.255.255.0
broadcast 192.168.55.255
gateway 192.168.55.1
ovs_type OVSBridge
ovs_ports enp0s31f6

dns-nameservers 192.168.55.1

auto extsw
allow-ovs extsw
iface extsw inet static
address 192.168.55.130
network 192.168.55.0
netmask 255.255.255.0
broadcast 192.168.55.255
gateway 192.168.55.1
ovs_type OVSBridge
ovs_ports enp0s31f6

dns-nameservers 192.168.55.1
--ココまで

(sagittarius) # cp -pi 0110.enp0s31f6 /root/0110.enp0s31f6.new
(sagittarius) # vi /root/0110.enp0s31f6.new
--一部書き換え
auto enp0s31f6
allow-br-external enp0s31f6
iface enp0s31f6 inet manual
ovs_bridge br-external
ovs_type OVSPort

#auto enp0s31f6
allow-extsw enp0s31f6
iface enp0s31f6 inet manual
ovs_bridge extsw
ovs_type OVSPort
--ココまで

(sagittarius) # exit

続いて、OpenvSwitch の設定変更用のコマンドを作っておこう。
(sagittarius) $ vi 0001_ovs-vsctl_show
--ココから
sudo ovs-vsctl show
--ココまで

(sagittarius) $ vi 0002_ovs-vsctl_add-br_extsw
--ココから
sudo ovs-vsctl add-br extsw
--ココまで

(sagittarius) $ ln -s 0001_ovs-vsctl_show 0003_ovs-vsctl_show
(sagittarius) $ vi 0004_ovs-vsctl_del-port_br-external_enp0s31f6
--ココから
sudo ovs-vsctl del-port br-external enp0s31f6
--ココまで

(sagittarius) $ ln -s 0001_ovs-vsctl_show 0005_ovs-vsctl_show
(sagittarius) $ vi 0006_ovs-vsctl_add-port_extsw_enp0s31f6
--ココから
sudo ovs-vsctl add-port extsw enp0s31f6
--ココまで

(sagittarius) $ ln -s 0001_ovs-vsctl_show 0007_ovs-vsctl_show

ネットワークの切断が発生するため、ゲストOSは全て停止しておこう。
(sagittarius) $ virsh list --all
稼働しているゲストOSは片っ端から停止だ。

同様に、ネットワーク経由のファイルシステム等は全て切断だ。
(sagittarius) $ sudo systemctl stop /etc/libvirt
(sagittarius) $ sudo systemctl stop /var/lib/libvirt
(sagittarius) $ sudo systemctl stop /var/log/libvirt
(sagittarius) $ sudo systemctl stop /mnt/iso-os

(sagittarius) $ sudo vgchange -a n vg-kvm

(sagittarius) $ iscsiadm -m session
(sagittarius) $ sudo systemctl stop open-iscsi.service
(sagittarius) $ iscsiadm -m session

ここまで準備が整ったら、直接コンソールで作業だ。
(sagittarius) $ ip address show
(sagittarius) $ sudo mv /etc/network/interfaces.d/0010.br-external /root/
(sagittarius) $ sudo mv /etc/network/interfaces.d/0110.enp0s31f6 /root/
(sgaittarius) $ sudo mv /root/0010.extsw \
/etc/network/interfaces.d/0010.extsw
(sagittarius) $ sudo mv /root/0110.enp0s31f6.new \
/etc/network/interfaces.d/0110.enp0s31f6

(sagittarius) $ bash 0001_ovs-vsctl_show
(sagittarius) $ bash 0002_ovs-vsctl_add-br_extsw
(sagittarius) $ bash 0003_ovs-vsctl_show
(sagittarius) $ bash 0004_ovs-vsctl_del-port_br-external_enp0s31f6
(sagittarius) $ bash 0005_ovs-vsctl_show
(sagittarius) $ bash 0006_ovs-vsctl_add-port_extsw_enp0s31f6
(sagittarius) $ bash 0007_ovs-vsctl_show

(sagittarius) $ sudo systemctl daemon-reload
(sagittarius) $ sudo systemctl reboot
--コンソール作業ココまで

これでまた、ssh でログイン出来るはずだ。
(sagittarius) $ ip address show

ネットワーク経由のファイルシステム等の確認。
(sagittarius) $ iscsiadm -m session
(sagittarius) $ df

KVM仮想スイッチの定義を、今までの br-external から、新しい extsw に変更しよう。
(sagittarius) $ virsh net-list --all
(sagittarius) $ virsh net-edit ovsbridge
--以下のように修正
<bridge name='br-external'/>

<bridge name='extsw'/>
--ココまで

以前まで使っていた br-external は削除しよう。
(sagittarius) $ sudo ovs-vsctl show
(sagittarius) $ sudo ovs-vsctl del-br br-external
(sagittarius) $ sudo ovs-vsctl show

これでいいはずだ。
念のためにもう一度 OS 再起動して確認しておこう。
(sagittarius) $ sudo systemctl reboot
(sagittarius) $ ip address show
(sagittarius) $ systemctl status

必要に応じて、仮想マシンの起動停止も確認しておくといいぞ。

これで sagittarius での作業は完了。
ちょっと長くなったので、aquarius は次回実施だ。

これまでを踏まえて、aquarius / sagittarius の手入れを

gemini / cancer を用いて、かなりの検証が出来た。
で、その内容はホストである aquarius / sagittarius に反映させておきたい。

一体いくつの変更/修正点があるのだろうか…
  1. openvswitch の仮想スイッチ名の変更(br-external→extsw)
  2. 自動起動ネットワークの手直し(/etc/default/networking)
  3. OpenvSwitch と open-iscsi の起動停止順の制御
  4. multipathd の導入
  5. corosync / dlm / gfs2 の導入とセットアップ
  6. CLVM の導入とセットアップ
  7. 仮想マシン領域の gfs2 化
え?コレだけ?結構色々検証したと思ったけど、まとめてみるとこの程度か…。
結構時間がかかったんだな…。

というわけで、次回から上記に従って進めていくことにする。

2017年5月3日水曜日

とりあえず、対策を gemini にも

前回までで、(全てではないにしても)問題がある程度解消出来た。
cancer に対して実施していたので、gemini にも同様の対処を施すことにする。

(gemini) $ cd /lib/systemd/system
(gemini) $ sudo cp -pi open-iscsi.service open-iscsi.service.orig
(gemini) $ sudo vi open-iscsi.service
--ココから
Wants=network-online.target remote-fs-pre.target iscsid.service
After=network-online.target iscsid.service
↓(前提条件に openvswitch-switch.service を追加)
Wants=network-online.target remote-fs-pre.target iscsid.service openvswitch-switch.serivce
After=network-online.target iscsid.service openvswitch-switch.service
--ココまで
(gemini) $ cd

(gemini) $ sudo systemctl daemon-reload
(gemini) $ sudo vgchange -asy vg-gfs2
(gemini) $ sudo systemctl start /mnt/gfs2

(gemini) $ cd /lib/systemd/system
(gemini) $ sudo vi lvm2-cluster-activation.service
--ココから
[Service]セクションに1行追加
ExecStopPost=/bin/sleep 10
--ココまで
(gemini) $ sudo systemctl daemon-reload

(gemini) $ sudo vi openvswitch-switch.service
--ココから
ExecStart=/bin/sleep 6

ExecStart=/bin/sleep 10
--ココまで
(gemini) $ sudo systemctl daemon-reload

再起動して確認
(gemini) $ sudo systemctl reboot

おしまい。

o2cb.serviceの起動失敗

o2cb.service の起動が上手くいかない件に関して、以下のように調査をしたんだけど、結局上手く行かず。
原因が良くわからない。(以下の手順を実施すると、OpenvSwitch / networking の起動がダメになる。)
この件は保留にして、ocfs2 関連はステの方向で進めることにしよう。gfs2 が使えるからね。
ちなみに、設定は元に戻してある。
--------------------------------------------------------------------------------
さて、続いて o2cb.service の起動が上手くいかない問題だ。
正直言って、あまり対処する必要が無い気がするが…。

とりあえず、OS 起動後に o2cb.service をリスタートすることで正常起動することは分かっている。
であれば、起動処理を少し後ろにずらせばいいのではないだろうか?

ただしコイツ、systemd の起動スクリプトが無く、/etc/init.d の下のものを systemd-generetor によって自動的に作っている代物。
このままだと、起動処理の制御は難しい。

だったら、自動生成されたものをベースに、/lib/systemd/system の下に作ってしまったらどうだろうか?

というわけでやってみる。
ocfs2.service も同時に処理しておく。

(cancer) $ sudo systemctl stop o2cb
(cancer) $ sudo systemctl disable o2cb.service
(cancer) $ sudo systemctl stop ocfs2
(cancer) $ sudo systemctl disable ocfs2.service

(cancer) $ sudo cp -pi /run/systemd/generator.late/o2cb.service \
/lib/systemd/system/
(cancer) $ ls -l /lib/systemd/system/o2cb.service
(cancer) $ sudo vi /lib/systemd/system/o2cb.service
--ココから
先頭付近の SourcePath 宣言をコメントアウトする
SourcePath=/etc/init.d/o2cb

#SourcePath=/etc/init.d/o2cb

After宣言に、openvswitch-switch.service を追加する。
After=network-online.target

After=network-online.target openvswitch-switch.service

Wants宣言にも。
Wants=network-online.target

Wants=network-online.target openvswitch-switch.service

末尾に[Install]セクションとインストール先を追加する。
[Install]
WantedBy=multi-user.target
--ココまで

(cancer) $ sudo systemctl daemon-reload

(cancer) $ sudo cp -pi /run/systemd/generator.late/ocfs2.service \
/lib/systemd/system/
(cancer) $ ls -l /lib/systemd/system/ocfs2.service
(cancer) $ sudo vi /lib/systemd/system/ocfs2.service
--ココから
先頭付近の SourcePath 宣言をコメントアウトする
SourcePath=/etc/init.d/o2cb

#SourcePath=/etc/init.d/o2cb

末尾に[Install]セクションとインストール先を追加する。
[Install]
WantedBy=multi-user.target
--ココまで

(cancer) $ sudo systemctl daemon-reload

(cancer) $ sudo systemctl enable o2cb.service
(cancer) $ sudo systemctl enable ocfs2.service
(cancer) $ sudo systemctl status o2cb
(cancer) $ sudo systemctl status ocfs2

(cancer) $ sudo systemctl start o2cb.service
(cancer) $ sudo systemctl start ocfs2.service
(cancer) $ sudo systemctl status o2cb
(cancer) $ sudo systemctl status ocfs2

再起動して確認
(cancer) $ sudo systemctl reboot
(cancer) $ systemctl status
(cancer) $ systemctl status o2cb
(cancer) $ sudo vgchange -asy vg-ocfs2
(cancer) $ sudo systemctl start /mnt/ocfs2

2017年5月2日火曜日

シャットダウン時に刺さる現象(その2)

調べてみると、iSCSIターゲットにログインする処理は、open-iscsi.service というサービスが担っているようだ。
(cancer) $ systemctl --no-pager -l status open-iscsi.service

更に、このサービスの停止処理を追いかけていくと、どうやら iSCSI領域のファイルシステムアンマウントも実行している模様。
実際に、iSCSI領域をマウントしている状態で、このサービスの停止を仕掛けてみると、ファイルシステムのアンマウントやiSCSIターゲットからのログアウトも自動的にやってくれている。

ということは、このサービスの前提に、openvswitch-switch.service を付けてやればいいんじゃないか?
というわけで試してみる。
(cancer) $ cd /lib/systemd/system
(cancer) $ sudo cp -pi open-iscsi.service open-iscsi.service.orig
(cancer) $ sudo vi open-iscsi.service
--ココから
Wants=network-online.target remote-fs-pre.target iscsid.service
After=network-online.target iscsid.service
↓(前提条件に openvswitch-switch.service を追加)
Wants=network-online.target remote-fs-pre.target iscsid.service openvswitch-switch.serivce
After=network-online.target iscsid.service openvswitch-switch.service
--ココまで
(cancer) $ cd

設定を読み込み
(cancer) $ sudo systemctl daemon-reload

ディスク類をマウントしてしまおう。
(まだ、o2cbの問題は解決していないので、o2cbの再起動も実施)
(cancer) $ sudo systemctl restart o2cb.service
(cancer) $ sudo vgchange -asy vg-ocfs2
(cancer) $ sudo vgchange -asy vg-gfs2
(cancer) $ sudo systemctl start /mnt/ocfs2
(cancer) $ sudo systemctl start /mnt/gfs2

ここで再起動を実施するんだけど、刺さったかどうかはコンソールを見ておく必要がある。
virt-viewerを使って、コンソールから再起動させよう。
(cancer) $ sudo systemctl reboot

あれ?刺さった。
--------------------------------------------------------------------------------
どうやら、刺さる要因は2つあったようだ。

1つは「iSCSIターゲットからログアウトする前に、OpenvSwitchが停止してしまう」という現象。
こちらは、上で対処済み。

もう1つは ocfs2 絡みのようだ。
どうも絞り込んでいくと、ocfs2 ファイルシステムがマウントされている時に刺さる現象が起きているようだ。
ocfs2 ファイルシステムのアンマウントに時間がかかっていることが原因じゃないだろうか?
どうする?gfs2 が使えるので、ocfs2 は使わないようにすればいいのだが…。一応、もう少し調べてみよう。(o2cbサービスが正常起動出来ない点も含めて)

ちなみに、今KVMホストとして使っている aquarius/sagittarius は、ocfs2 関連の環境は一切作っていないため、刺さる現象は OpenvSwitch + iSCSI によるモノだ。

色々試してみたが、以下の組み合わせの時に発生するようだ。
  • OpenvSwitch を使用
  • OpenvSwitch の仮想スイッチを経由した iSCSI LUN
  • その LUN を multipathd でデバイスマッピング
  • そのデバイスマッピングで ocfs2 ファイルシステムを使用
  • そのファイルシステムをマウント
これらの条件が1つでも外れていると、再発しない様子。

どうも、iSCSIターゲットからログアウトする前に、OpenvSwitch が停止しているように見える。
もしそうだとしたら、gfs2 でも同じ事象が起きそうなものだが、gfs2 では同じ事象は発生しない。
これは、gfs2 / ocfs2 のアンマウントにかかる時間が違うからのようだ。
gfs2 は一瞬でアンマウントされるが、 ocfs2 はアンマウントに時間がかかる。
どうもそれが原因のようだ。

さてどうしよう。選択肢は2つ。
  • もっと原因と対策を追求する
  • ocfs2 を捨てる
出来れば、原因と対策を見つけ出した上で、ocfs2 を捨てて gfs2 オンリーにする、という形にしたい。今はまだ gfs2 では現象発生していないけど、gfs2 で発生する可能性もあるからだ。

というわけで、もう少し調査…。

色々調べていった結果、 lvm2-cluster-activation.service の停止処理に sleep を入れることで、再発率が大幅に下がることが分かった。
20秒の sleep で再現せず、5秒の sleep では時々再発。10秒の sleep で再現性がほぼ無くなったようだ。
ちょっと原因は分からないが、とりあえずこれで逃げることにしよう。

(cancer) $ cd /lib/systemd/system
(cancer) $ sudo vi lvm2-cluster-activation.service
--ココから
[Service]セクションに1行追加
ExecStopPost=/bin/sleep 10
--ココまで
(cancer) $ sudo systemctl daemon-reload

これでヨサゲ。

ついでに、 openvswitch-switch.service の起動時の処理に6秒の sleep を入れていたが、これも 10秒程度に延ばしておいた方が良さそうだ。
どうも、ウチの NAS の性能が良くなく、 iSCSI ログイン/ログアウトに(少し)時間がかかるのが直接の原因じゃないか?という疑い。
合わせて修正しておこう。

(cancer) $ sudo vi openvswitch-switch.service
--ココから
ExecStart=/bin/sleep 6

ExecStart=/bin/sleep 10
--ココまで
(cancer) $ sudo systemctl daemon-reload

これでとりあえず大丈夫だろう。
詳細がつかめたら、合わせて本対処するが、原因不明のため、このまま行くことにする。

2017年4月25日火曜日

シャットダウン時に刺さる現象(その1)

ココで、「シャットダウン・リブート中に刺さったような現象が」って書いた。

コレ、どうやら iSCSIターゲットにログインしている状態(iSCSIディスクのLVMアクティベートは関係なく)でシャットダウンやリブートを行うと発生するようだ。
iSCSIターゲットからログアウトした状態でリブートした場合は発生しない。

ということは、ネットワーク切断後にiSCSIログアウトを行おうとしているんだろう。

今回の構成は、OpenvSwitchで作った仮想スイッチの先に iSCSIターゲットがあるが、普通に設計する場合は、iSCSI用に専用の物理ネットワークポートを用意(大抵は冗長化のため、複数ポート)する。
この場合、iSCSI専用NICには、OpenvSwitchのような仮想スイッチを挟むことはしないはずだ。

自宅で作っているような小さな環境の場合、データ用とiSCSI用でネットワークも分離せず、全て1系統のみで賄ってしまうような形になるだろう。
つまるところ、ウチの構成が、iSCSIターゲットを使う理想の構成からは外れている、ということだ。

恐らく、OpenvSwitchによる仮想スイッチの停止処理と、iSCSIターゲットからのログアウト処理の順序性の問題だと思われる。

となると、どうすればいいのだろうか?
そのあたりを中心に、ちょっと調査を継続しよう。

2017年4月21日金曜日

cancerをgeminiと同格までセットアップ

ずっと gemini でセットアップを行っていたので、今は gemini と cancer のセットアップ情報に差異がある。
gemini である程度問題解決が出来たので、cancer を gemini と同程度になるようにセットアップすることにする。

ダダっと書いていく。
(cancer) $ sudo apt-get update
(cancer) $ sudo apt-get install qemu-kvm
(cancer) $ sudo systemctl reboot

(cancer) $ grep kvm /etc/group
(cancer) $ id
(cancer) $ sudo adduser (自分のユーザ名) kvm
(cancer) $ grep kvm /etc/group
(一旦exitで抜けて、再度ログイン)
(cancer) $ id

(cancer) $ lsmod | grep kvm
(cancer) $ sudo apt-get install virtinst libosinfo-bin virt-manager fonts-ipafont
(cancer) $ sudo systemctl reboot

再ログイン
(cancer) $ virsh list --all

(cancer) $ sudo apt-get install openvswitch-switch
(cancer) $ sudo ovs-vsctl show
(cancer) $ sudo ovs-vsctl list-br
(cancer) $ sudo ovs-vsctl add-br extsw
(cancer) $ sudo ovs-vsctl show
(cancer) $ sudo ovs-vsctl list-br

(cancer) $ cd /lib/systemd/system
(cancer) $ sudo cp -pi corosync.service corosync.service.orig
(cancer) $ sudo cp -pi openvswitch-switch.service openvswitch-switch.service.orig

(cancer) $ sudo vi corosync.service
--ココから
Requires=network-online.target
After=network-online.target
↓(前提条件に openvswitch-switch.service を追加する)
Requires=network-online.target openvswitch-switch.service
After=network-online.target openvswitch-switch.service
--ココまで

(cancer) $ sudo vi openvswitch-switch.service
--ココから
ExecStart=/bin/true
↓(何も実行しない処理を、6秒待機に変更する)
ExecStart=/bin/sleep 6
--ココまで

(cancer) $ cd
(cancer) $ sudo vi /etc/network/interfaces.d/0110.ens3
ファイルの新規作成
--ココから--
auto ens3
allow-extsw
iface ens3 inet manual
ovs_bridge extsw
ovs_type OVSPort
--ココまで--

(cancer) $ sudo vi /etc/network/interfaces.d/0010.extsw
ファイルの新規作成
--ココから--
auto extsw
allow-ovs extsw
iface extsw inet static
address 192.168.55.137
network 192.168.55.0
netmask 255.255.255.0
broadcast 192.168.55.255
gateway 192.168.55.1
ovs_type OVSBridge
ovs_ports ens3

dns-nameservers 192.168.55.1
--ココまで--

ネットワークセッションが切れてしまうので、コンソールで作業しよう。
(cancer) $ sudo ifdown ens3
(cancer) $ sudo rm /etc/network/interfaces.d/ens3
(cancer) $ sudo ovs-vsctl add-port extsw ens3
(cancer) $ sudo ovs-vsctl show
(cancer) $ sudo ifup ens3
(cancer) $ sudo ifup extsw

変更内容を取り込む。
(cancer) $ sudo systemctl daemon-reload
(cancer) $ sudo systemctl reboot
コンソール作業はココまで

(cancer) $ ip address show
(cancer) $ dig www.blogger.com
(cancer) $ sudo ovs-vsctl show

(cancer) $ virsh net-list --all
(cancer) $ vi ovsbridge.xml
ファイルの新規作成
--ここから
<network>
<name>ovsbridge</name>
<forward mode='bridge'/>
<bridge name='extsw'/>
<virtualport type='openvswitch'/>
</network>
--ここまで
(cancer) $ virsh net-define ovsbridge.xml
(cancer) $ virsh net-list --all

(cancer) $ virsh net-autostart ovsbridge
(cancer) $ virsh net-start ovsbridge
(cancer) $ virsh net-list --all

(cancer) $ sudo apt-get install ovmf

gemini はココで gemini 専用の iSCSIターゲット、LUN を作って作業を行ったが、cancer に対しては実施しないでおく。

(cancer) $ sudo apt-get install cifs-utils
(cancer) $ sudo mkdir /mnt/iso-os

fstabに追記する。
(cancer) $ sudo vi /etc/fstab
以下の行を追記
--ココから
//(cifsのIPアドレス)/(cifsのディレクトリ) /mnt/iso-os cifs guest,_netdev 0 0
--ココまで

マウント確認
(cancer) $ sudo mount /mnt/iso-os
(cancer) $ df /mnt/iso-os
(cancer) $ sudo umount /mnt/iso-os

再起動してマウント状態の確認
(cancer) $ sudo systemctl reboot
(cancer) $ df

(cancer) $ sudo cp -pi /etc/default/networking /etc/default/netwoking.orig
(cancer) $ sudo vi /etc/default/networking
--ココから
8行目付近
#EXCLUDE_INTERFACES=
↓(extswを指定)
EXCLUDE_INTERFACES=extsw
--ココまで

(cancer) $ systemctl is-enabled clvm
(cancer) $ sudo systemctl disable clvm
(cancer) $ systemctl is-enabled clvm

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

こんなところかな?