Ubuntu の 18.04 が、4月末にリリースされる。
今使っている16.04は既に2年程経っているから、18.04が出たらバージョンアップをしたいと思っている。
が、いきなり18.04にバージョンアップしようとしても大きく変更が入っているはずなので、色々トラブるはず。
そこで、まずは単純に、16.04→18.04のバージョンアップ検証をしてみたいと思う。
まずは、仮想環境にUbuntu16.04を導入し、openvswitch 導入と固定IP化、最新16.04へupgradeしておく。
その後、本来ならバックアップを取得しておくべきだが、今回は仮想環境を使用した検証なので、スナップショットを作っておくことにする。
新しいバージョンにアップグレードするコマンドは do-release-upgrade だが、まだ正式リリース版ではなく開発版のため、-d のオプションが必要になる。
sshでログインしての実行は、N/Wダウンなどのリスクがある。出来ればコンソールから実施しよう。(仮想マシンなら、virt-viewer 等を使用する。)
特に、今回の構成は ssh でログインするポートが openvswitch を経由する。openvswitch のアップデート等で ssh が切断される可能性もあるため、コンソールから作業しよう。
$ sudo apt-get update
$ sudo do-release-upgrade -d -c
$ LANG=C sudo do-release-upgrade -d
＃ssh でログインして実行している場合、安全のために追加で ssh を起動する、という確認が入る。そのまま y で継続して構わない。
パッケージ更新の確認で、いくつのパッケージが削除されるか？等の確認が入る。こちらもそのまま y で継続しよう。
途中で、/etc/default/grub の差分について確認の画面が入ることもある。そのままエンターでも、一つ上の「パッケージメンテナのバージョンをインストール(install the package maintainer's version)」でも構わない。
この後、暫く時間がかかる。数十分～数時間。ボーッとモニタを眺めていよう。
アップグレード後、不要なパッケージ(18.04では削除もしくは置き換えられたパッケージ)の削除をするか？と聞いてくる。HDDが無駄になるだけなので、削除してもいいだろう。
というか、どうせ後から削除するので、このタイミングで削除してしまおう。
作業が終わったら、再起動するか聞いてくる。再起動して反映させよう。
開発中のバージョンにアップデートしたため、まだ不具合が残っているかもしれない。
とりあえず、サービスだけは確認しておこう。
$ systemctl status
問題無ければ、念のために最新版にアップデートしておく。
(最新版を入れたはずなので、この数十分の間にパッケージが更新されて無ければ、何も更新は無いはずだ。)
$ sudo apt-get update
$ sudo apt-get --simulate upgrade
$ sudo apt-get upgrade
今回知ったのだが、パッケージ更新時にパッケージに含まれる設定ファイルのファイル名が変わる場合、古い(削除された)設定ファイルは残ってしまうようだ。
例えば、/etc/init/openvswitch-switch.conf。
このファイル、新しい openvswitch-switch パッケージには含まれていないが、16.04時代の openvswitch-switch パッケージには含まれている。
アップグレードすると、このファイルは削除されず、残ってしまう。
但し、「パッケージに含まれるファイル」という扱いではあるので、openvswitch-switch パッケージを削除する時には、一緒に削除してくれる。
つまり、素で18.04をインストールした時と、16.04から18.04にアップグレードした時とで、同じパッケージ構成にしていても、微妙にファイル数が異なる、ということだ。
害は無いが、ちょっと気にはなる。
まぁ対処しなくていいだろう。
さて、無事にアップデート出来たら、ちょっと手を出しておきたいところがある。
16.04の時、ネットワーク設定は ifupdown によって行われていた。
(/etc/network/interfaces 等を使用していた。)
どうやら、17.04か17.10から、ネットワーク設定はnetplan方式に変わったようだ。
(/etc/netplan ディレクトリが設定用ディレクトリ。)
アップグレード後でも、ifupdown 方式は使えるが、デフォルトが netplan 方式に変わったし、ifupdown 方式がいつ使えなくなるか(削除されるか)分からないので、今のうちにnetplan 方式に切り替えておこう。
＃他にも、デフォルトが変わったものがあるかもしれないが、今の所ネットワーク関連だけ分かっている。
ちなみにこの netplan、systemd に組み込まれているようで、systemd-networkd というサービスによって起動されるようだ。
というわけで、今までの ifupdown 方式から、 netplan 方式に切り替える。
切り替える前にもう一度バックアップ取っておこう。(仮想環境なので、スナップショットを取っておく。停止してからスナップショットを取るのが安全だ。)
netplan の設定ファイルは、/etc/netplan/*.yaml というファイルで、中身は yaml 形式とか。manをよく読んで作ってみる。
$ sudo vi /etc/netplan/extsw.yaml
--以下のように作成--
--ens3の部分は、物理I/Fのデバイス名だ--
--とりあえず、暫定仮想マシンで作っているのでens3になっている--
--IPアドレスも含めて、各自の環境に合わせてみて欲しい--
network:
version: 2
renderer: networkd
ethernets:
ens3:
match: {name: "ens3"}
bridges:
extsw:
interfaces: [ens3]
dhcp4: false
addresses:
- 192.168.55.143/24
gateway4: 192.168.55.1
nameservers:
addresses: [192.168.55.1]
--ココまで--
出来たらチェックしてみる。
$ sudo netplan --debug generate
特にエラーっぽいメッセージが出て無ければ、反映させてみよう。
ネットワークを一時的に止めるので、コンソールから実施すること。
まずは、今までの networking を止める。
$ sudo systemctl disable networking
$ sudo systemctl stop networking
$ sudo systemctl status networking
$ ip address show
そしたら、systemd-networkd からnetplanを起動してみる。
$ sudo systemctl status systemd-networkd
$ sudo systemctl start systemd-networkd
$ sudo systemctl enable systemd-networkd
$ sudo systemctl status systemd-networkd
$ ip address show
これでネットワークにつながったはずだ。
念のために、古い方の設定で起動しないように、古いファイルは退避しておこう。
$ sudo mkdir /etc/network/interfaces.d.bk
$ sudo mv -i /etc/network/interfaces.d/* /etc/network/interfaces.d.bk
再起動して確認してみる。
$ sudo systemctl reboot
$ ip address show
上手く行っているようだが…
$ systemctl status
$ systemctl --state=failed
どうやら、resolvconf-pull-resolved.serviceというサービスが起動に失敗しているようだ。
$ systemctl status resolvconf-pull-resolved.service
調べてみると、resolvconf関連はこのサービスの他にsystemd-resolved.serviceというのがある。
このサービスは、systemdパッケージに含まれているようだ。
どうやら、16.04にも含まれていて、他のサービスとの兼ね合いで無効化されていたっぽい。
networkingを無効にし、systemd-networkd を有効にしたことで、systemd-resolvedが有効化され、今までしようしていたresolvconf-pull-resolvedとバッティングしているようだ。
というわけで、resolvconf-pull-resolvedを無効化して再起動してみる。
$ sudo systemctl stop resolvconf-pull-resolved
っと、どうやらこのサービスは、resolvconf-pull-resolved.pathを止める必要があるようだ。
$ systemctl status resolvconf-pull-resolved.path
$ sudo systemctl stop resolvconf-pull-resolved.path
$ sudo systemctl disable resolvconf-pull-resolved.path
$ systemctl status resolvconf-pull-resolved.path
$ sudo systemctl reboot
$ systemctl status
一応、問題無さそうだ。
ところがこの状態では、名前解決に失敗する。
$ host www.yahoo.co.jp
/etc/hosts に記載されていない名前解決には、/etc/resolv.conf に記載されているネームサーバが使用される。
Debian / Ubuntu は、この /etc/resolv.conf は自動作成されるようになっている(厳密には、別のファイルが出来て、/etc/resolv.conf はそのファイルに対するシンボリックリンクだ)が、resolvconf-pull-resolvdを停止させたことで、/etc/resolv.conf の中身が空っぽになってしまった。
$ cat /etc/resolv.conf
$ ls -l /etc/resolv.conf
$ cat /run/resolvconf/resolv.conf
新しく稼働したsystemd-resolvedは、どうやら/run/systemd/resolveの下に、resolv.conf と stub-resolv.conf という2つのファイルを生成するようだ。
そして、/etc/resolv.conf は /run/systemd/resolve/stub-resolv.conf を指すようにすればいいらしい。
バージョンアップではなく、ダイレクトに18.04をインストールした環境を見たら、そのようになっていた。
(現在、18.04はまだ開発中で、インストール自体がうまくいかない可能性もある。この場合は、ちょっと古いインストールイメージを使用すると良い。)
このことから、/etc/resolv.conf を作り直してみる。
$ sudo rm /etc/resolv.conf
$ sudo ln -s ../run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
$ ls -l /etc/resolv.conf
$ cat /etc/resolv.conf
ネームサーバとして、127.0.0.53 を指していると思う。
この辺り、ちょっと特殊な作りになっていて、ローカルでネームサーバが起動、127.0.0.53で待受しているようだ。
そして、各クライアントアプリ(リゾルバ)は、ローカルのネームサーバに対して問い合わせを行う仕組みのようだ。
とりあえず、名前解決が出来るか確認してみよう。
$ host www.yahoo.co.jp
無事に名前解決出来たと思う。
再起動しても問題ないか、確認しておこう。
$ sudo systemctl reboot
$ systemctl status
$ host www.yahoo.co.jp
問題ないはずだ。
あと、networking.service と resolvconf-pull-resolvd は不要になったはずだ。
削除しておこう。
それぞれ、どのパッケージに入っているか再確認。
$ systemctl status networking.service
サービス定義ファイルが /lib/systemd/system/networking.service だということが確認できる。
$ dpkg -S /lib/systemd/system/networking.service
ifupdown に所属しているファイルだということが分かる。
一応、パッケージに所属しているファイルを一応見ておこう。
$ dpkg -L ifupdown
resolvconf-pull-resolvedについても同様に確認。
$ systemctl status resolvconf-pull-resolved
$ dpkg -S /lib/systemd/system/resolvconf-pull-resolved.service
$ dpkg -L resolvconf
削除してみよう。
削除に不安があるのなら、一度バックアップを取得しておけばいいだろう。(仮想環境なのでスナップショットをとっておく。)
では削除してみる。
$ sudo apt-get --simulate remove ifupdown resolvconf
一緒に ifenslave というパッケージも削除されるようだ。(パッケージの導入状態によっては、他にも削除されるものがあるかもしれない。)
bonding関連のようだが、netplanではteamingにて実現しているので、必要ないということだろう。
サクッと削除してみる。
$ sudo apt-get remove ifupdown resolvconf
再起動を促す画面が出てきた。
一応、再起動してからもう一度名前解決を確認しておく。
$ sudo systemctl reboot
$ systemctl status
$ host www.yahoo.co.jp
問題無ければ、不要となった設定情報も削除しておく。
$ sudo apt-get purge ifupdown resolvconf ifenslave
今回、16.04から18.04へのバージョンアップで、ネットワーク周りの変更が入っていたため、その変更を取り込む手順を確認した。
他にも変更が入っているかもしれないが、分かり次第取り込むことにしよう。
2018年3月30日金曜日
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/ の方に移しておこう。
他にカスタマイズしている部分もあった気がするので、後日確認することにする。
そもそも、 /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年5月26日金曜日
sagittarius の整理
これでようやく sagittarius の仮想マシンがゼロになった。
sagittarius の整理をしよう。
とは言っても、大きく「ログファイルの移動」と「専用ディスクの排除」「共有ボリュームのマウント」の3点だろう。
ログファイルの移動は、既にココの後半部で aquarius にて実施済み。
その手順をなぞればいい。
専用ディスクの排除は、今まで kvm 仮想マシンが載っていたディスク領域を排除することだが、まずはアンマウント状態にしておいて、後日削除、でいいだろう。
共有ボリュームのマウントと合わせて、やはりココの後半部で実施済みだ。
そのため、ざっとコマンドだけ並べておくことにする。
まずはログファイルの移動
(sagittarius) $ cd /var/log
(sagittarius) $ sudo tar cvf libvirt.tar libvirt
(sagittarius) $ sudo systemctl stop /var/log/libvirt
(sagittarius) $ sudo chmod 755 /var/log/libvirt
(sagittarius) $ sudo chown root:root /var/log/libvirt
(sagittarius) $ sudo tar xvf libvirt.tar
(sagittarius) $ sudo rmdir libvirt/lost+found
(sagittarius) $ ls libvirt
(sagittarius) $ sudo rm libvirt.tar
(sagittarius) $ cd
続いて、専用ディスクの取り外しと共有ディスクのマウント(/etc/fstab も書き換え)
(sagittarius) $ sudo systemctl stop /etc/libvirt
(sagittarius) $ sudo systemctl stop /var/lib/libvirt
(sagittarius) $ sudo vi /etc/fstab
--ココから
/dev/mapper/vg--kvm-lv--etc--libvirt /etc/libvirt ext4 _netdev,x-systemd.requires=openvswitch-switch.service 0 0
/dev/mapper/vg--kvm-lv--var--lib--libvirt /var/lib/libvirt ext4 _netdev,x-systemd.requires=openvswitch-switch.service 0 0
/dev/mapper/vg--kvm-lv--var--log--libvirt /var/log/libvirt ext4 _netdev,x-systemd.requires=openvswitch-switch.service 0 0
↓
/dev/mapper/kvmcluster-etc--libvirt /etc/libvirt gfs2 _netdev,x-systemd.requires=dlm.service 0 0
/dev/mapper/kvmcluster-var--lib--libvirt /var/lib/libvirt gfs2 _netdev,x-systemd.requires=dlm.service 0 0
#/dev/mapper/vg--kvm-lv--var--log--libvirt /var/log/libvirt ext4 _netdev,x-systemd.requires=openvswitch-switch.service 0 0
--ココまで
(sagittarius) $ sudo systemctl daemon-reload
(sagittarius) $ sudo systemctl start /etc/libvirt
(sagittarius) $ grep /etc/libvirt /etc/mtab
(sagittarius) $ sudo systemctl start /var/lib/libvirt
(sagittarius) $ grep /var/lib/libvirt /etc/mtab
(sagittarius) $ ls /etc/libvirt
(sagittarius) $ ls /var/lib/libvirt
多分この状態では、まだ共有仮想マシンが認識できていないと思う。
libvirt-bin を再起動することで認識させることが可能だ。
(sagittarius) $ virsh list --all
(sagittarius) $ sudo systemctl restart libvirt-bin.service
(sagittarius) $ virsh list --all
必要に応じて、sagittarius を再起動して、共有領域が正しく認識・マウントされるか確認しておこう。
sagittarius の整理をしよう。
とは言っても、大きく「ログファイルの移動」と「専用ディスクの排除」「共有ボリュームのマウント」の3点だろう。
ログファイルの移動は、既にココの後半部で aquarius にて実施済み。
その手順をなぞればいい。
専用ディスクの排除は、今まで kvm 仮想マシンが載っていたディスク領域を排除することだが、まずはアンマウント状態にしておいて、後日削除、でいいだろう。
共有ボリュームのマウントと合わせて、やはりココの後半部で実施済みだ。
そのため、ざっとコマンドだけ並べておくことにする。
まずはログファイルの移動
(sagittarius) $ cd /var/log
(sagittarius) $ sudo tar cvf libvirt.tar libvirt
(sagittarius) $ sudo systemctl stop /var/log/libvirt
(sagittarius) $ sudo chmod 755 /var/log/libvirt
(sagittarius) $ sudo chown root:root /var/log/libvirt
(sagittarius) $ sudo tar xvf libvirt.tar
(sagittarius) $ sudo rmdir libvirt/lost+found
(sagittarius) $ ls libvirt
(sagittarius) $ sudo rm libvirt.tar
(sagittarius) $ cd
続いて、専用ディスクの取り外しと共有ディスクのマウント(/etc/fstab も書き換え)
(sagittarius) $ sudo systemctl stop /etc/libvirt
(sagittarius) $ sudo systemctl stop /var/lib/libvirt
(sagittarius) $ sudo vi /etc/fstab
--ココから
/dev/mapper/vg--kvm-lv--etc--libvirt /etc/libvirt ext4 _netdev,x-systemd.requires=openvswitch-switch.service 0 0
/dev/mapper/vg--kvm-lv--var--lib--libvirt /var/lib/libvirt ext4 _netdev,x-systemd.requires=openvswitch-switch.service 0 0
/dev/mapper/vg--kvm-lv--var--log--libvirt /var/log/libvirt ext4 _netdev,x-systemd.requires=openvswitch-switch.service 0 0
↓
/dev/mapper/kvmcluster-etc--libvirt /etc/libvirt gfs2 _netdev,x-systemd.requires=dlm.service 0 0
/dev/mapper/kvmcluster-var--lib--libvirt /var/lib/libvirt gfs2 _netdev,x-systemd.requires=dlm.service 0 0
#/dev/mapper/vg--kvm-lv--var--log--libvirt /var/log/libvirt ext4 _netdev,x-systemd.requires=openvswitch-switch.service 0 0
--ココまで
(sagittarius) $ sudo systemctl daemon-reload
(sagittarius) $ sudo systemctl start /etc/libvirt
(sagittarius) $ grep /etc/libvirt /etc/mtab
(sagittarius) $ sudo systemctl start /var/lib/libvirt
(sagittarius) $ grep /var/lib/libvirt /etc/mtab
(sagittarius) $ ls /etc/libvirt
(sagittarius) $ ls /var/lib/libvirt
多分この状態では、まだ共有仮想マシンが認識できていないと思う。
libvirt-bin を再起動することで認識させることが可能だ。
(sagittarius) $ virsh list --all
(sagittarius) $ sudo systemctl restart libvirt-bin.service
(sagittarius) $ virsh list --all
必要に応じて、sagittarius を再起動して、共有領域が正しく認識・マウントされるか確認しておこう。
2017年5月16日火曜日
networking.service の設定変更
さて、今度は sagittarius / aquarius の networking.service の設定変更だ。
構築中に色々いじっていて、2台の間で設定が合っていないかもしれないけど、とりあえずは networking.service が無効化されている前提で書く。
sagittarius / aquarius のどちらも同じ作業なので、合わせて書く。
再起動が入るので、仮想マシンは停止しておく。
$ virsh list --all
起動している仮想マシンがあったら停止しておく。
自動起動ネットワークの一部無効化。
$ sudo vi /etc/default/networking
--ココから
#EXCLUDE_INTERFACES=
↓
EXCLUDE_INTERFACES=extsw
--ココまで
$ sudo systemctl daemon-reload
$ sudo systemctl is-enabled networking.service
$ sudo systemctl enable networking.service
$ sudo systemctl is-enabled networking.service
$ sudo systemctl reboot
これで終了。
次は、シャットダウン時に刺さる問題(OpenvSwitch と open-iscsi の起動停止順の制御)だ。
構築中に色々いじっていて、2台の間で設定が合っていないかもしれないけど、とりあえずは networking.service が無効化されている前提で書く。
sagittarius / aquarius のどちらも同じ作業なので、合わせて書く。
再起動が入るので、仮想マシンは停止しておく。
$ virsh list --all
起動している仮想マシンがあったら停止しておく。
自動起動ネットワークの一部無効化。
$ sudo vi /etc/default/networking
--ココから
#EXCLUDE_INTERFACES=
↓
EXCLUDE_INTERFACES=extsw
--ココまで
$ sudo systemctl daemon-reload
$ sudo systemctl is-enabled networking.service
$ sudo systemctl enable networking.service
$ sudo systemctl is-enabled networking.service
$ sudo systemctl reboot
これで終了。
次は、シャットダウン時に刺さる問題(OpenvSwitch と open-iscsi の起動停止順の制御)だ。
2017年3月14日火曜日
iSCSIボリュームのLVMが有効化されるまで(その2)
--2017/04/20追記ココから--
ここで出ている問題は、前回分に追記した内容で解消したっぽい。
なので、無駄な記事になってしまった。
--2017/04/20追記ココまで--
未だ解決出来ていないのだが、前回からの再起動後、systemdの状態をよく見てみたら、corosync.serviceの起動にも失敗している。
はて？cancerの方はどうだ？
(cancer) $ sudo shutdown -r now
(cancer) $ systemctl status corosync.service
問題なく起動している。
なんとまぁ…geminiに対する変更処理で、corosyncにまで影響が出てしまった。
これは要調査だな…。
ってどうやら、dlm.serviceも正常起動しなくなってるぞ。
これは大ダメージだ。
とりあえず状態の整理。
(gemini) $ cat /lib/systemd/system/corosync.service
要件として、network-online.targetが入っている。
ステータスは…
(gemini) $ systemctl status network-online.target
activeだ。
条件は…
(gemini) $ cat /lib/systemd/system/network-online.target
前提条件としてnetwork.targetが入っている。
ステータスは当然…
(gemini) $ systemctl status network.target
activeだ。
う～ん。corosync.serviceが起動していないのは何故だろう？
試しに起動してみる。
(gemini) $ sudo systemctl start corosync.service
(gemini) $ systemctl status corosync.service
む？activeになったぞ…？
もう一度再起動して、再現確認だ。
(gemini) $ sudo shutdown -r now
(gemini) $ systemctl status corosync.service
あれ？今度は
………色々調べてたら、どうやらOpenvSwitchの設定がおかしいようだ………
ヘルプに書かれている設定方法じゃダメっぽい………
整理して書き直す…。
ここで出ている問題は、前回分に追記した内容で解消したっぽい。
なので、無駄な記事になってしまった。
--2017/04/20追記ココまで--
未だ解決出来ていないのだが、前回からの再起動後、systemdの状態をよく見てみたら、corosync.serviceの起動にも失敗している。
はて？cancerの方はどうだ？
(cancer) $ sudo shutdown -r now
(cancer) $ systemctl status corosync.service
問題なく起動している。
なんとまぁ…geminiに対する変更処理で、corosyncにまで影響が出てしまった。
これは要調査だな…。
ってどうやら、dlm.serviceも正常起動しなくなってるぞ。
これは大ダメージだ。
とりあえず状態の整理。
- /etc/libvirt等のKVM用ファイルシステムは未マウント
- NAS領域も未マウント
- vg確認・操作系オペレーションはハング(vgs)
- iSCSIターゲットへのログインは成功(iscsadm -m session)
- ブロックデバイスは認識済み(lsblk)
- corosync.serviceはfailed
- dlm.serviceはinactive
- clvm.serviceはinactive(これはcancerも)
- multipathは認識済み
(gemini) $ cat /lib/systemd/system/corosync.service
要件として、network-online.targetが入っている。
ステータスは…
(gemini) $ systemctl status network-online.target
activeだ。
条件は…
(gemini) $ cat /lib/systemd/system/network-online.target
前提条件としてnetwork.targetが入っている。
ステータスは当然…
(gemini) $ systemctl status network.target
activeだ。
う～ん。corosync.serviceが起動していないのは何故だろう？
試しに起動してみる。
(gemini) $ sudo systemctl start corosync.service
(gemini) $ systemctl status corosync.service
む？activeになったぞ…？
もう一度再起動して、再現確認だ。
(gemini) $ sudo shutdown -r now
(gemini) $ systemctl status corosync.service
あれ？今度は
- iSCSIターゲットへのログインは、片方失敗(gemini単独用ターゲットへのログイン失敗)
- corosync.serviceは起動状態
- dlm.serviceも起動状態
- clvmはinactive
………色々調べてたら、どうやらOpenvSwitchの設定がおかしいようだ………
ヘルプに書かれている設定方法じゃダメっぽい………
整理して書き直す…。
2017年3月11日土曜日
iSCSIボリュームのLVMが有効化されるまで(その1)
--2017/04/20追記ココから--
ここで出ている問題は、前回分に追記した内容で解消したっぽい。
なので、無駄な記事になってしまった。
--2017/04/20追記ココまで--
前回の調査で、どうやらOS起動時のファイルシステム(iSCSIボリュームで作成したLVM領域のファイルシステム)マウント、OS停止時のファイルシステムアンマウントの流れがおかしいのでは？というのが予想出来た。
そもそもこの領域、iSCSI領域であり、OpenvSwitch上の仮想スイッチを経由してiSCSIターゲットへ接続している。
(サーバとして使うのなら、iSCSIターゲットへの接続は独立したネットワークを用い、OpenvSwitchを経由しない構成にするべきだと思うのだが、自宅PCレベルでは複数NICや複数N/Wを使いまわすのは面倒だ…)
そのため、OS起動からファイルシステムマウントまでは、以下の流れにならないといけないと思う。(CIFSマウントのタイミングもついでに書いておいた。)
停止はこの逆になるはず。
根本的なところで、OpenvSwitchが起動した後に、iSCSIのLVM関連が動き出さないといけないのだが、どうやら起動処理ではこの順番が守られていないように見える。
また、停止時もこの逆になっていないように見える。
これを追いかけてみよう。
まずは再起動をして、サービス起動が上手く行っていないものを探す。
(gemini) $ sudo shutdown -r now
(gemini) $ systemctl -a status
今のgeminiは、以下のような状態になっている。
● gemini
State: starting
Jobs: 3 queued
Failed: 1 units
(略)
● dev-mapper-vg\x2d\x2dkvm\x2dlv\x2d\x2detc\x2d\x2dlibvirt.device
Loaded: loaded
Active: inactive (dead)
(略)
● dev-mapper-vg\x2d\x2dkvm\x2dlv\x2d\x2dvar\x2d\x2dlib\x2d\x2dlibvirt.device
Loaded: loaded
Active: inactive (dead)
(以降省略)
みたいな感じだ。
なんか、表示が上手く行っていないが、
dev-mapper-vg--kvm-lv--etc--libvirt.device
とかのようだ。
末尾が.deviceとなっているunitは、deviceタイプと呼ばれる代物。
実体は何処にあるかと言うと…無い…。
どういうことだろ…。deviceタイプはチェックしなくていいのかな？
一応、確認はしてみる。
(gemini) $ systemctl status dev-mapper-vg\\x2d\\x2dkvm\\x2dlv\\x2d\\x2detc\\x2d\\xwdlibvirt.device
Timed out waiting for device dev-mapper-vg…
う～ん。どうやら、デバイス(vg)へのアクセスがタイムアウトを起こした、ということらしいな。
ということは、vg構成情報が読み取れる状態になるところ(iSCSIログイン？)に問題があるのか？
systemdのユニットは、service/deviceの他に、mount/target等があるようだ。
ということで、一応mountも確認してみるか。
mount関連はココにも書いた通り、/run/systemd/generaterの下に自動生成される。
試しに、etc-libvirt.mountとmnt-iso\x2dos.mountを見てみると、以下のようなエントリが見える。
Before=remote-fs.target
これは、自分自身(etc-libvirt.mountとかmnt-iso\x2dos.mountとか)よりも後に、remote-fs.targetを起動する、という設定。
前提条件を書いているのではなく、後続条件を書いていることになる。
ちなみに、remote-fs.targetは、今の自分の環境には2つ存在してる。
/etc/systemd/system/multi-user.target.wants/remote-fs.target
/lib/systemd/system/remote-fs.target
が、実体は後者で、前者はシンボリックリンクだ。
前者はSysV init方式で言うところのrunlevelを制御するところの関係なので、今回はちょっと無視する。
後者を確認しよう(前者はシンボリックリンクなので、どちらを確認しても同じなのだが…)。
以下の3行が気になる。
After=remote-fs-pre.target
DefaultDependencies=no
Conflicts=shutdown.target
これを見ると、remote-fs.targetは、remote-fs-pre.targetの処理が終わってからでないと起動しないらしい。
また、shutdown.targetとConflictsになっているため、shutdown.targetと同時起動はしない。
DefaultDependenciesは…ちょっと良くわからない。標準的な依存関係を暗黙的に有効にするかどうか？で、noに設定されているので、幾つかの標準的な依存関係は無視される？
remote-fs-pre.targetも同じディレクトリにあるので、こちらもついでに確認する。
特に何かが書いてあるわけではない。
RefuseManualStart=yes
ってのがあるが…これがyesなので、ユーザの手作業による起動・停止は出来ないようだ。
これらをまとめてみると、以下のフローになるのかな？
さて、ココを調べてもしょうがない。
もっと上位で問題が起きていて、ファイルシステムマウントまで辿り着いていない、というのが現実だ。
とは言え、etc-libvirt.mountを見ても前提条件が書かれていない。
ステータスを見てみると…
(gemini) $ systemctl status etc-libvirt.mount
Dependency failed for /etc/libvirt.
となっていて、Dependency(依存)の失敗が原因となっている。
一体どういうことなんだろう…。
やはり、iSCSIログインに問題があるのだろうか？
と思って、NAS装置の管理画面からiSCSIターゲットを見てみたら、一応ログインされているようだ。
iSCSIログインに関するsystemd unitは何だろうな…
(gemini) $ systemctl | grep -i iscsi
iscsid.serviceのようだ。ステータスはrunningだから問題無い。
(gemini) $ systemctl status iscsid.service
cannot make a connection to....
あれ？なんかエラーっぽいメッセージが出てるな…大丈夫か？
一応、iscsid.serviceを再起動してみるか…。
(gemini) $ sudo systemctl restart iscsid.service
(gemini) $ systemctl status iscsid.service
おや？先程のエラーっぽいメッセージは出なくなった。
でも、vg情報は取得されてないぞ…。
む？もう1つ、open-iscsi.serviceってあるけど…これ…は？
(gemini) $ systemctl status open-iscsi.service
正常に動いているっぽいけど、一応再起動してみる…。
(gemini) $ sudo systemctl restart open-iscsi.service
ログイン済みのiSCSI targetからログアウト→再度ログイン、という流れになるはずなんだけど、syslogを見てみたらログアウトに1分30秒かかってタイムアウトした。
その後、再ログインしてデバイス認識はスムーズに行っている。
もしかして、これでvg認識されたかな？
(gemini) $ sudo pvdisplay /dev/sda1
ダメだ。ハングする。
他にも問題を抱えているのか…。
iSCSIイニシエータのエラーっぽいメッセージが消えたから、今度はLVM関連のサービスを確認してみるか。
(gemini) $ systemctl status | grep lvm2
lvm2-activation-net.serviceというのがあるな。
これの内容は…おや？これも自動生成関係っぽいな。
(gemini) $ man lvm2-activation-generator
lvm.confでlvmetadが無効化されている場合に、このlvm2-activation-generatorによってユニットが生成され、LVMボリュームがアクティベートされる、と。
gemini/cancerは、CLVMを使用する関係で、lvmetadを無効化している。
となると、今のaquarius/sagittariusとは条件が違うか…。まぁaquarius/sagittariusも将来的にはlvmetadを停止することになりそうだから、調べておくか。
どうやら、/run/systemd/generatorに、
lvm2-activation-early.service
lvm2-activation-net.service
lvm2-activation.service
という3つのユニットが作成されているっぽい。
これが関係あるかもしれない。
1つずつ確認してみよう。
まず3つのユニットのExecStartだけど、全て同じで
ExecStart=/sbin/lvm vgchange -aay --ignoreskippedcluster
になっている。
つまり、lvm.confのauto_activation_volume_listに記載されているlvolのうち、Clusterマークが付いているボリュームを無視して、残り全てをアクティベーションさせるということか。
これだと、既にPVが認識できていることが前提条件になりそうだな…。
3つのユニットの依存関係を見てみると…。
lvm2-activation-early.service
After=systemd-udev-settle.service
Before=cryptsetup.target
Before=local-fs-pre.target shutdown.target
Wants=systemd-udev-settle.service
lvm2-activation-net.service
After=lvm2-activation.service iscsi.service fcoe.service
Before=remote-fs-pre.target shutdown.target
lvm2-activation.service
After= lvm2-activation-early.service cryptsetup.target
Before=local-fs-pre.target shutdown.target
Wants=systemd-udev-settle.service
After/Before/Wantsが定義されている。
これらの依存関係を整理すると…
こんな感じだろうか…。
これ、1つずつ実行してみる。(最後のshutdown.targetは実行しちゃダメだよ)
(gemini) $ sudo systemctl restart systemd-udev-settle.service
(gemini) $ sudo systemctl restart lvm2-activation-early.service
あれ…？ココでハングした…？
--以下は想定していたコマンド。上でハングしたので実施せず。
(gemini) $ sudo systemctl restart cryptsetup.target
(gemini) $ sudo systemctl restart lvm2-activation.service
(gemini) $ sudo systemctl restart iscsi.service
(gemini) $ sudo systemctl restart lvm2-activation-net.service
--ココまで
う～ん。なんだろう…？
ちょっと調査を続けていたら、ココで設定したgemini/cancer共用のiSCSIターゲットへの自動ログインがOffになってた。(geminiだけ。)
たんなる作業ミスなのか、一連の作業の中で自動的に解除されたのかは不明。
とりあえず、「iSCSIを利用しようその1」等に従って、自動ログインを実施するように設定。
この状態で一度再起動をしてみるが、まだ解決できず。
とりあえず、調査は継続するけど、今回はここまで。
ここで出ている問題は、前回分に追記した内容で解消したっぽい。
なので、無駄な記事になってしまった。
--2017/04/20追記ココまで--
前回の調査で、どうやらOS起動時のファイルシステム(iSCSIボリュームで作成したLVM領域のファイルシステム)マウント、OS停止時のファイルシステムアンマウントの流れがおかしいのでは？というのが予想出来た。
そもそもこの領域、iSCSI領域であり、OpenvSwitch上の仮想スイッチを経由してiSCSIターゲットへ接続している。
(サーバとして使うのなら、iSCSIターゲットへの接続は独立したネットワークを用い、OpenvSwitchを経由しない構成にするべきだと思うのだが、自宅PCレベルでは複数NICや複数N/Wを使いまわすのは面倒だ…)
そのため、OS起動からファイルシステムマウントまでは、以下の流れにならないといけないと思う。(CIFSマウントのタイミングもついでに書いておいた。)
停止はこの逆になるはず。
根本的なところで、OpenvSwitchが起動した後に、iSCSIのLVM関連が動き出さないといけないのだが、どうやら起動処理ではこの順番が守られていないように見える。
また、停止時もこの逆になっていないように見える。
これを追いかけてみよう。
まずは再起動をして、サービス起動が上手く行っていないものを探す。
(gemini) $ sudo shutdown -r now
(gemini) $ systemctl -a status
今のgeminiは、以下のような状態になっている。
● gemini
State: starting
Jobs: 3 queued
Failed: 1 units
(略)
● dev-mapper-vg\x2d\x2dkvm\x2dlv\x2d\x2detc\x2d\x2dlibvirt.device
Loaded: loaded
Active: inactive (dead)
(略)
● dev-mapper-vg\x2d\x2dkvm\x2dlv\x2d\x2dvar\x2d\x2dlib\x2d\x2dlibvirt.device
Loaded: loaded
Active: inactive (dead)
(以降省略)
みたいな感じだ。
なんか、表示が上手く行っていないが、
dev-mapper-vg--kvm-lv--etc--libvirt.device
とかのようだ。
末尾が.deviceとなっているunitは、deviceタイプと呼ばれる代物。
実体は何処にあるかと言うと…無い…。
どういうことだろ…。deviceタイプはチェックしなくていいのかな？
一応、確認はしてみる。
(gemini) $ systemctl status dev-mapper-vg\\x2d\\x2dkvm\\x2dlv\\x2d\\x2detc\\x2d\\xwdlibvirt.device
Timed out waiting for device dev-mapper-vg…
う～ん。どうやら、デバイス(vg)へのアクセスがタイムアウトを起こした、ということらしいな。
ということは、vg構成情報が読み取れる状態になるところ(iSCSIログイン？)に問題があるのか？
systemdのユニットは、service/deviceの他に、mount/target等があるようだ。
ということで、一応mountも確認してみるか。
mount関連はココにも書いた通り、/run/systemd/generaterの下に自動生成される。
試しに、etc-libvirt.mountとmnt-iso\x2dos.mountを見てみると、以下のようなエントリが見える。
Before=remote-fs.target
これは、自分自身(etc-libvirt.mountとかmnt-iso\x2dos.mountとか)よりも後に、remote-fs.targetを起動する、という設定。
前提条件を書いているのではなく、後続条件を書いていることになる。
ちなみに、remote-fs.targetは、今の自分の環境には2つ存在してる。
/etc/systemd/system/multi-user.target.wants/remote-fs.target
/lib/systemd/system/remote-fs.target
が、実体は後者で、前者はシンボリックリンクだ。
前者はSysV init方式で言うところのrunlevelを制御するところの関係なので、今回はちょっと無視する。
後者を確認しよう(前者はシンボリックリンクなので、どちらを確認しても同じなのだが…)。
以下の3行が気になる。
After=remote-fs-pre.target
DefaultDependencies=no
Conflicts=shutdown.target
これを見ると、remote-fs.targetは、remote-fs-pre.targetの処理が終わってからでないと起動しないらしい。
また、shutdown.targetとConflictsになっているため、shutdown.targetと同時起動はしない。
DefaultDependenciesは…ちょっと良くわからない。標準的な依存関係を暗黙的に有効にするかどうか？で、noに設定されているので、幾つかの標準的な依存関係は無視される？
remote-fs-pre.targetも同じディレクトリにあるので、こちらもついでに確認する。
特に何かが書いてあるわけではない。
RefuseManualStart=yes
ってのがあるが…これがyesなので、ユーザの手作業による起動・停止は出来ないようだ。
これらをまとめてみると、以下のフローになるのかな？
さて、ココを調べてもしょうがない。
もっと上位で問題が起きていて、ファイルシステムマウントまで辿り着いていない、というのが現実だ。
とは言え、etc-libvirt.mountを見ても前提条件が書かれていない。
ステータスを見てみると…
(gemini) $ systemctl status etc-libvirt.mount
Dependency failed for /etc/libvirt.
となっていて、Dependency(依存)の失敗が原因となっている。
一体どういうことなんだろう…。
やはり、iSCSIログインに問題があるのだろうか？
と思って、NAS装置の管理画面からiSCSIターゲットを見てみたら、一応ログインされているようだ。
iSCSIログインに関するsystemd unitは何だろうな…
(gemini) $ systemctl | grep -i iscsi
iscsid.serviceのようだ。ステータスはrunningだから問題無い。
(gemini) $ systemctl status iscsid.service
cannot make a connection to....
あれ？なんかエラーっぽいメッセージが出てるな…大丈夫か？
一応、iscsid.serviceを再起動してみるか…。
(gemini) $ sudo systemctl restart iscsid.service
(gemini) $ systemctl status iscsid.service
おや？先程のエラーっぽいメッセージは出なくなった。
でも、vg情報は取得されてないぞ…。
む？もう1つ、open-iscsi.serviceってあるけど…これ…は？
(gemini) $ systemctl status open-iscsi.service
正常に動いているっぽいけど、一応再起動してみる…。
(gemini) $ sudo systemctl restart open-iscsi.service
ログイン済みのiSCSI targetからログアウト→再度ログイン、という流れになるはずなんだけど、syslogを見てみたらログアウトに1分30秒かかってタイムアウトした。
その後、再ログインしてデバイス認識はスムーズに行っている。
もしかして、これでvg認識されたかな？
(gemini) $ sudo pvdisplay /dev/sda1
ダメだ。ハングする。
他にも問題を抱えているのか…。
iSCSIイニシエータのエラーっぽいメッセージが消えたから、今度はLVM関連のサービスを確認してみるか。
(gemini) $ systemctl status | grep lvm2
lvm2-activation-net.serviceというのがあるな。
これの内容は…おや？これも自動生成関係っぽいな。
(gemini) $ man lvm2-activation-generator
lvm.confでlvmetadが無効化されている場合に、このlvm2-activation-generatorによってユニットが生成され、LVMボリュームがアクティベートされる、と。
gemini/cancerは、CLVMを使用する関係で、lvmetadを無効化している。
となると、今のaquarius/sagittariusとは条件が違うか…。まぁaquarius/sagittariusも将来的にはlvmetadを停止することになりそうだから、調べておくか。
どうやら、/run/systemd/generatorに、
lvm2-activation-early.service
lvm2-activation-net.service
lvm2-activation.service
という3つのユニットが作成されているっぽい。
これが関係あるかもしれない。
1つずつ確認してみよう。
まず3つのユニットのExecStartだけど、全て同じで
ExecStart=/sbin/lvm vgchange -aay --ignoreskippedcluster
になっている。
つまり、lvm.confのauto_activation_volume_listに記載されているlvolのうち、Clusterマークが付いているボリュームを無視して、残り全てをアクティベーションさせるということか。
これだと、既にPVが認識できていることが前提条件になりそうだな…。
3つのユニットの依存関係を見てみると…。
lvm2-activation-early.service
After=systemd-udev-settle.service
Before=cryptsetup.target
Before=local-fs-pre.target shutdown.target
Wants=systemd-udev-settle.service
lvm2-activation-net.service
After=lvm2-activation.service iscsi.service fcoe.service
Before=remote-fs-pre.target shutdown.target
lvm2-activation.service
After= lvm2-activation-early.service cryptsetup.target
Before=local-fs-pre.target shutdown.target
Wants=systemd-udev-settle.service
After/Before/Wantsが定義されている。
これらの依存関係を整理すると…
こんな感じだろうか…。
これ、1つずつ実行してみる。(最後のshutdown.targetは実行しちゃダメだよ)
(gemini) $ sudo systemctl restart systemd-udev-settle.service
(gemini) $ sudo systemctl restart lvm2-activation-early.service
あれ…？ココでハングした…？
--以下は想定していたコマンド。上でハングしたので実施せず。
(gemini) $ sudo systemctl restart cryptsetup.target
(gemini) $ sudo systemctl restart lvm2-activation.service
(gemini) $ sudo systemctl restart iscsi.service
(gemini) $ sudo systemctl restart lvm2-activation-net.service
--ココまで
う～ん。なんだろう…？
ちょっと調査を続けていたら、ココで設定したgemini/cancer共用のiSCSIターゲットへの自動ログインがOffになってた。(geminiだけ。)
たんなる作業ミスなのか、一連の作業の中で自動的に解除されたのかは不明。
とりあえず、「iSCSIを利用しようその1」等に従って、自動ログインを実施するように設定。
この状態で一度再起動をしてみるが、まだ解決できず。
とりあえず、調査は継続するけど、今回はここまで。
2017年2月10日金曜日
ファイルシステムマウント変更(/etc/fstab変更)
前回までで、gfs2をマウントする流れが理解できて設定方法も分かった。
はずなんだけど、1つ漏れていた。
/etc/fstabを書き換えた後、OS再起動させずに反映させるにはどうすれば？だ。
/etc/fstabを書き換えてOS再起動させると、/run/systemd/generatorに反映される。
これをOS再起動させずに反映させる方法だ。
で、調べてみたら、systemd.generatorのマニュアルエントリ(man systemd.generator)に書いてあった。
ちゃんと読めよ…。
/etc/fstabを書き換えたら
$ sudo systemctl daemon-reload
だ。
これで/run/systemd/generatorに反映される。
ついでに、ファイルシステムのマウントも、
$ sudo systemctl start /mnt/gfs2
という具合に、マウントポイントを指定すればマウントしてくれる。
(アンマウントは systemctl stop だ)
なんだ、すげー簡単じゃん…。
ちなみに今回のocfs2/gfs2に対応する/etc/fstabエントリは以下だ。
--ココから
/dev/mapper/vg--ocfs2-lv--ocfs /mnt/ocfs2 ocfs2 _netdev,x-systemd.requires=o2cb.service 0 0
/dev/mapper/vg--gfs2-lv--gfs /mnt/gfs2 gfs2 _netdev,x-systemd.requires=dlm.service 0 0
--ココまで
この2行を/etc/fstabに追記した後、
(gemini) $ sudo systemctl daemon-reload
を実行
(gemini) $ ls -l /run/systemd/generator
でエントリが出来ている(mnt-gfs2.mount と mnt-ocfs2.mount)のを確認して
(gemini) $ sudo systemctl start /mnt/ocfs2
(gemini) $ sudo systemctl start /mnt/gfs2
でマウント、
(gemini) $ grep -e /mnt/ocfs2 -e /mnt/gfs2 /etc/mtab
でマウントされているのを確認。
これでOKだ。
(OS再起動後は自動でマウントされるはずだぞ。)
ファイルシステム関連はこれにてオシマイ。
次こそCLVMの調査だ。
--2017/04/14追記
fstabのエントリはnoautoを付与しておくようにした。
自動マウントされると、ちょっと不便だった。(ボリュームアクティベートが失敗しているのにマウントしようとしたり…)
--2017/04/14追記終了
はずなんだけど、1つ漏れていた。
/etc/fstabを書き換えた後、OS再起動させずに反映させるにはどうすれば？だ。
/etc/fstabを書き換えてOS再起動させると、/run/systemd/generatorに反映される。
これをOS再起動させずに反映させる方法だ。
で、調べてみたら、systemd.generatorのマニュアルエントリ(man systemd.generator)に書いてあった。
ちゃんと読めよ…。
/etc/fstabを書き換えたら
$ sudo systemctl daemon-reload
だ。
これで/run/systemd/generatorに反映される。
ついでに、ファイルシステムのマウントも、
$ sudo systemctl start /mnt/gfs2
という具合に、マウントポイントを指定すればマウントしてくれる。
(アンマウントは systemctl stop だ)
なんだ、すげー簡単じゃん…。
ちなみに今回のocfs2/gfs2に対応する/etc/fstabエントリは以下だ。
--ココから
/dev/mapper/vg--ocfs2-lv--ocfs /mnt/ocfs2 ocfs2 _netdev,x-systemd.requires=o2cb.service 0 0
/dev/mapper/vg--gfs2-lv--gfs /mnt/gfs2 gfs2 _netdev,x-systemd.requires=dlm.service 0 0
--ココまで
この2行を/etc/fstabに追記した後、
(gemini) $ sudo systemctl daemon-reload
を実行
(gemini) $ ls -l /run/systemd/generator
でエントリが出来ている(mnt-gfs2.mount と mnt-ocfs2.mount)のを確認して
(gemini) $ sudo systemctl start /mnt/ocfs2
(gemini) $ sudo systemctl start /mnt/gfs2
でマウント、
(gemini) $ grep -e /mnt/ocfs2 -e /mnt/gfs2 /etc/mtab
でマウントされているのを確認。
これでOKだ。
(OS再起動後は自動でマウントされるはずだぞ。)
ファイルシステム関連はこれにてオシマイ。
次こそCLVMの調査だ。
--2017/04/14追記
fstabのエントリはnoautoを付与しておくようにした。
自動マウントされると、ちょっと不便だった。(ボリュームアクティベートが失敗しているのにマウントしようとしたり…)
--2017/04/14追記終了
登録:
投稿 (Atom)