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による自動マウントにする。

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