CentOSでCockpitを導入するとsubscription-managerに登録しろと指摘されるのを解消する

エラーではない

うちのCentOS 7 + oVirt4ではブラウザから様々な設定作業を行うためCockpitが導入されている。ovirt-engineをインストールすると依存関係で一括導入されるのだけれど、yum updateを実行すると

This system is not registered with an entitlement server. You can use subscription-manager to register.

Uploading Enabled Repositories Report
Cannot upload enabled repos report, is this client registered?

といった、何やらサブスクリプションマネージャーで登録しないといけないっぽいメッセージが表示される。これはエラーではなく情報なので気にしなくてもいい。だけれど、毎度毎度出てきてボクの心をざわつかせるので表示を消したいと思う。

手順は2つのファイルを編集してenable=0にするだけである。

# vi /etc/yum/pluginconf.d/subscription-manager.conf
[main]
enabled=0
# vi /etc/yum/pluginconf.d/enabled_repos_upload.conf
[main]
enabled=0
supress_debug=False
supress_errors=False

光あれ

Internet回線も10Gbps

nuro 光 10Gs というサービスが2019年3月にサービスインした(らしい)。上下10GbpsのInternet回線契約で自宅LANが10GBase-Tになっているボクんちには最適なサービスだ。今年の正月休みにWEBで契約して契約書がすぐに届いた。次工程は工事日程の決定、次々工程から回線工事になる。1.下見, 2.宅内配線, 3.屋外配線(NTT絡む)となり、開通まで2か月くらいかかるそうだ。まぁ3月開始だから5月?うーん、待ち遠しいね。

工事日程の連絡がこない

待ちきれなくてサービスインする前の2月にハイエンドサービス専用デスクというオタク歓喜するネーミングの窓口に聞いてみた。

工事日程の連絡こないんですけれど、まだですか?

サービスインする3月までお待ちください。

ところで今日は3月12日だが、まだ工事日程の連絡はない。WEBで申し込めないの?4月になっちゃうよ。

急いでいるのには理由がある

単に待ち遠しいだけなので理由などない。すいません。あえて理由をつけるなら、契約中ISPの固定IPと新規回線追加制限のオプションサービスが3月31日に終了してしまう。固定IPでなくなるならどこと契約しても同じと思って、移転先のISP探しをしている最中にnuro 光 10Gsがマッチングしたのだ。

ついでだけれど、端末10台程度で無線側がパンクするバッファローのローエンドWiFiアクセスポイントもこれを機に新調しようと思っていたが、今のままでは予定が組めない。Nuroが提供するルーターの機能次第で用意する機材も変わってくるが、情報が公式,SNSにでてこない。調べたところ3月下旬に延伸されていた・・・

誤自宅LAN事情

仕方ないので自宅の足回りを整理しておこう。

VLAN機器用途型名
10Gファイルサーバasrock 自作
仮想ホストCELSIUS 改造
ゲーム用PCASUS 自作
1GL3SWCatalyst 3750G
アクセスルーターRTX810
WiFi APWSR-1166DHP3
NASTS-459Pro
ゲーム用PC予備
WiFiスマートスピーカーGoogle home
スマートスピーカーGoogle home mini
スマートリモコンRemo
スマートリモコンRemo mini
サムターンロックSesame mini
ゲーム機Play Station
ゲーム機Steam Link
インターネットテレビChrome Cast
スマホandroid
スマホiPhone
電子ブックKindle
ポケットPCGPD Pocket

WiFi 機器増えたなぁ。10Gの8ポートL2SWは2台あるので1GのVLANをすべて10G化することは可能だし、WiFiとVLANを分ける必要ないのでL3SWも不要になるな。早く10G光こい。

oVirt のengine-backup script

backup-image

全バックアップのスクリプト

oVirt engineの databese とDWH の databaseを万が一のために毎日フルバックアップする。フルバックアップといってもデータ量はさほど大きくない。

#!/usr/bin/bash
#
# oVirt engine database & DWH database all backup
# /mnt/PublicはNAS上のnfs
#
/usr/bin/engine-backup --mode=backup --scope=all --file="/mnt/Public/ovirt/backups/engine-backup-$(hostname)-$(date +%F).tar.bz2" --log=/mnt/Public/ovirt/backups/ovirt-engine-backups.log

# 1週間以上前のバックアップファイルは削除する。ログは残す
find /mnt/Public/ovirt/backups/ -name "*.bz2" -mtime +7 -exec rm -rf -- {} \;

crontabに登録して毎日実行

スクリプトは毎日深夜に実行。うちのNASは夜1:00から別ファイルサーバーにrsyncしているのでその前に実施することとする。0:30くらいかな。

#crontab -e

# ovirt backup run daily at 0:30
30 0 * * * /root/tools/backupovirt.sh >/dev/null 2>&1

生成されると、バックアップファイルのアーカイブとログが残る。アーカイブはスクリプトによって1週間分のみ残る。ログは追記されるようだ。

-rw-r--r-- 1 root root 2151512 10月 27 13:39 engine-backup-green.team-boss.com-2018-10-27.tar.bz2
-rw-r--r-- 1 root root    3653 10月 27 13:39 ovirt-engine-backups.log

万が一に復元するときは

当然、バックアップしたのだから復元方法も記す。復元はDWHも復元するので少しパラメーターが増える。また、ドキュメントでは復元時にはDBの内容が入っていない状態でやるようにと記載されていた。ということはengine-setup前っていうことである。

# engine-backup --mode=restore --file=/mnt/Public/ovirt/backups/engine-backup-green.team-boss.com-2018-10-27.tar.bz2 --log=/mnt/Public/ovirt/backups/ovirt-engine-backups.log --provision-db --no-restore-permissions --provision-db --provision-dwh-db --provision-reports-db
Preparing to restore:
- Unpacking file '/mnt/Public/ovirt/backups/engine-backup-green.team-boss.com-2018-10-27.tar.bz2'
Restoring:
- Files
Provisioning PostgreSQL users/databases:
- user 'engine', database 'engine'
- user 'ovirt_engine_history', database 'ovirt_engine_history'
Restoring:
- Engine database 'engine'
  - Cleaning up temporary tables in engine database 'engine'
  - Updating DbJustRestored VdcOption in engine database
  - Resetting DwhCurrentlyRunning in dwh_history_timekeeping in engine database
  - Resetting HA VM status
------------------------------------------------------------------------------
Please note:

The engine database was backed up at 2018-10-27 00:30:03.000000000 +0900 .

Objects that were added, removed or changed after this date, such as virtual
machines, disks, etc., are missing in the engine, and will probably require
recovery or recreation.
------------------------------------------------------------------------------
- DWH database 'ovirt_engine_history'
You should now run engine-setup.
Done.

このバックアップはDBのみの退避であるため、DWHにあるドメインの各種イメージなどは退避されない。これは別の方法で実施することになる。

ovirt-engineとファイルが同じサーバーになるように構成して、なんらかの要因でストレージを飛ばしてしまったとき、イメージファイルも復元できないと何の効果もないので、くれぐれもバックアップは確実にとるように。

うちはファイルサーバーとovirt-engineが同じサーバーで構成されていて、イメージのあるLVを飛ばしてしまったときに泣いたよ。こんなときはDBを復元してもだめで、エクスポートドメインからのインポートでなんとか復活できた。

CentOS 7.5(1804)とoVirt 4.2の組み合わせで難儀する

oVirt 4.2ホストでCentOS 7.5アップグレード時にコンフリクト

CentOS 7.5(1804)が5/14にリリースされたので、各サーバーをyum upgradeしてみたところ、oVirt 4.2のホストでCockpit系パッケージとコンフリクト起こすようだ。

コンフリクトを起こすのはCockpitのNetworkManagerでoVirtの方が古いライブラリを必要としているのだが、CentOS7.5では新しいものに置き換わるのが理由らしい。コンフリクトを起こしたoVirtのパッケージを一時的にyum removeで削除したうえでyum upgradeを行い、続いて削除したパッケージをyum installしてあげれば解決する。

yum updateではうまく7.5にアップグレードできなかった。

#yum clean all
#yum upgrade
→cockpit-networkmanager-160でコンフリクト
#yum remove cockpit-networkmanager-160
#yum upgrade
#yum install cockpit-networkmanager
#yum install update   #念のため
#reboot

oVirt 4.2のVMとしてCentOS 7.5を新設時、guest-agentがインストールできない

VM動作している既設CentOS 7.4を7.5にupgradeする分には問題なかったが、CentOS 7.5をVMとして新規インストールし、ovirt-guest-agent-commonをインストールしようとしたところ、oVirtのミラーレポジトリで404のエラーが発生してインストールできない。該当するレポジトリファイルはCentOS-QEMU-EV.repoとCentOS-oVirt-4.2.repoで、baseurlを標準ミラーをコメントアウトし、たとえば日本のIIJのミラーに直接指定することで解消できた。

vi /etc/yum.repos.d/CentOS-QEMU-EV.repo

#baseurl=http://mirror.centos.org/$contentdir/$releasever/virt/$basearch/kvm-common/ コメントアウト
baseurl=http://ftp.iij.ad.jp/pub/linux/centos/$releasever/virt/$basearch/kvm-common/

上記同様にCentOS-oVirt-4.2.repoもbaseurlを書き換える。

最後のディレクトリが「kvm-common」ではなく「ovirt-4.2」に変わるだけだ。

どうも標準ミラーに$basearchに該当するx86_64ディレクトリがないのが原因らしい。oVirt 4.2は先月にリリースされたのでミラーされていないのは腑に落ちないのだが。日本サーバーにしておけばダウンロードも早いし問題ない。IIJだけでは不安というときはJAISTなども追加しておけばいい。

lvmcacheで低速大容量のHDD-RAIDをSSD並に高速化する

HDD-RAIDの欠点をSSDで補う

自宅ファイルサーバーはAdaptecのASR-71605を用いてSATA-HDD16本を接続しRAID6を構成している。このファイルサーバーはシーケンシャル性能は500~1000MB/sと非常に速いが、ランダムアクセス性能は10MB/s程度とHDD単体並に低い。

ランダムアクセスが改善すればVMの仮想ディスクやゲームPCのiSCSI に効果がでて、ボクのQOLが向上するはずだ。

その解決方法のひとつがlvmcache。それはSSDをHDDのキャッシュとして扱い、安価大容量の利点はそのままにディスクI/O性能をSSDの性能で底上げしようという試みだ。

現状の何が不満なのか

3DMarkを代表するゲーム系ベンチマークはCPUとビデオカードの性能をみるもので、それまでのローディングに掛かるHDDのアクセス時間は計測外なのが通常だ。一方で実際のARMA3などのゲームではテクスチャーやサウンドファイルといった細々としたものがアーカイブされた状態で格納され(たとえばpbo形式)、ゲーム中に必要なものだけを読み出しているのでランダムアクセスが多発する。

特にCQB(近接戦闘)で銃撃戦になると発砲音のシミュレートで両軍それぞれの兵科毎に違う小火器音源、破壊された建物のテクスチャーがガンガン読みだされている。MODを入れているとさらに増える。読み込みが間に合わないとフレームレートが下がり描画深度,ディティールを劣化させることになり、つまりは一番肝心なシーンの描画が最低レベルに下がるのでイライラするのだ。

効果はまずまず

連休前にいろいろと調べて試行錯誤して連休中に組み上げた。結果でいうとフロント側のSSD性能に律速するので直線番長だったRAIDアレイの性能は良くも悪くもスポイルされる。つまりシーケンシャルアクセスは若干下がり、ランダムアクセスは大幅に向上した。

今回用いたSSDはSATAのPX-256M6Vである。SATAではなくNVMeにするとすごいのかもしれない。ちなみにPX-256M6Vの公称値はSeq Read 535MB/s、Seq Write 335MB/s、Random Read 83000IOPS、Random Write 80000IOPSである。

lvmcache導入前のiSCSIの性能
(総じてランダムアクセス性能が低い)

lvmcache導入後のiSCSIの性能
(導入時にtarget側の容量も2TBから4TBに増量。lvmだと簡単だ)

4KIB Q8T8において、Random Read 78000IOPS、Random Write 64500IOPSでている。iSCSIのオーバーヘッドを考えればこのあたりが頭打ちだろう。

デメリット

使いはじめて3週間ほど経過したが、いいことばかりじゃない気がする。ネットであまり語られていないために、オマ環なのか判断できない点も含めてデメリットとしたい。

項目 内容
メンテナンス性 設定を変更したらLVがI/Oエラーで壊れた…バグ?
大量プロセス 整合にカーネル系の200プロセス前後が一斉に起動しiowaitが跳ね上がる。zabbix等で監視していると頻繁に警告される。
SSDの寿命 それはもう頻繁に書き込みが入っている模様
SSDのtrim fstrim -v -aでいいらしいが、そもそもキャッシュは容量100%使用を維持するのでプチフリ頻発していないか?
lvmのsnapshot lvmcacheを導入したLVはsnapshotができないとの報告
ファイル作成 理由は不明だがファイルの新規作成が非常に遅い。lvcacheはファイル単位ではないので別の原因かもしれない。
rsyncでビックリした。