誤自宅ICT・酔いどれ・そしてゲーム
lvmでpvを作ろうとしたところ、Mounted filesystem?と排他利用されているぞと怒られた。犯人はmpathだった。
犯人はオマエだ！といいたいなら
#fuser -m -v /dev/デバイス名 で判る。
lsblk でも判るだろう。
排他利用から手をひかせるためにはlsblkで表示されたデバイス名を控えておき
#dmsetup remove eui.xxxx (今回はこのようなデバイス名)で削除できた。
改めてpvcreate しましょう。
PHP 5.6のEOLは2019年なので残り僅かだが、CentOS 7.6では5.4が標準である。セキュリティ問題はバックポートされているので心配ないが、バージョン番号だけをみてインストール可否をしているパッケージがあるので（たとえばWordpress)、とりあえず5.6にあげておきたい。最新はPHP 7.1ですかね。epelのレポジトリをインストールされていること前提で手順を進めます。
レポジトリをインストール
# rpm -Uvh http://rpms.famillecollet.com/enterprise/remi-release-7.rpm
ポイント：remiのレポジトリはデフォルトでdisableになっているので利用時は enablerepoする。
PHP5.6がレポジトリにあるか確認
# yum list --enablerepo=remi --enablerepo=remi-php56 | grep php
ずらっとでてくればOK
ではインストール
ポイント:"epelもenablerepoにしている" 依存するライブラリがepelにあるのだ（libmcrypt）
# yum install --enablerepo=epel --enablerepo=remi --enablerepo=remi-php56 php php-opcache php-devel php-mbstring php-mcrypt php-mysqlnd php-phpunit-PHPUnit php-pecl-xdebug php-pecl-xhprof
バージョンアップされていることを確認
# php --version
PHP 5.6.40 (cli) (built: Apr 30 2019 11:35:35)
Copyright (c) 1997-2016 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2016 Zend Technologies
with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2016, by Zend Technologies
with Xdebug v2.5.5, Copyright (c) 2002-2017, by Derick Rethans
うちの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?といった、何やらサブスクリプションマネージャーで登録しないといけないっぽいメッセージが表示される。これはエラーではなく情報なので気にしなくてもいい。だけれど、毎度毎度出てきてボクの心をざわつかせるので表示を消したいと思う。
手順は２つのファイルを編集して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
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
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なども追加しておけばいい。
自宅ファイルサーバーは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だと簡単だ)
４KIB 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でビックリした。 |