Category Archives: おぼえがき

ZFS on Linux のバージョンアップ手順

ZFS on Linuxのバージョンアップが失敗したので試行錯誤した手順メモ。
ZoL公式のupgrade手順やってもうまくいかなかった。
ちなみに環境はCentOS7.3

RHEL/CentOS 7.3 kmod package upgrade
Systemd Update

以上の手順を踏んだ後に

# dkms status
Error! Could not locate dkms.conf file.
File: does not exist.

とか

# dkms status
spl, 0.7.1, 3.10.0-514.26.2.el7.x86_64, x86_64: installed
zfs, 0.7.1, 3.10.0-514.26.2.el7.x86_64, x86_64: installed (WARNING! Diff between built and installed module!) (WARNING! Diff between built and installed module!) (WARNING! Diff between built and installed module!) (WARNING! Diff between built and installed module!)

みたいな結果になって、うまくZFSのモジュールが読み込めない。zpoolがマウントできない。
どうもupgradeの手順だけだと、dkms関連のファイルが残るっぽい。
以下の手順でいけた。古いカーネルの削除はお好みで。

# yum remove zfs zfs-kmod spl spl-kmod libzfs2 libnvpair1 libuutil1 libzpool2 zfs-release kernel-devel
# rpm -qa | grep kernel
# yum remove {アクティブでないカーネル}
# rm -rf /usr/module/{アクティブでないカーネル}
# rm -rf /var/lib/dkms

これで根こそぎ削除されるはず。
次にインストール

# yum install https://download.zfsonlinux.org/epel/zfs-release.el7_3.noarch.rpm
# yum install kernel-devel zfs
# modprobe zfs
# zpool import -a
# zpool status

modprobe zfsで以下のようにうまくいかない場合は、こうする。

# zpool import -a
The ZFS modules are not loaded.
Try running '/sbin/modprobe zfs' as root to load them.

# modprobe zfs
modprobe: ERROR: could not insert 'zfs': Unknown symbol in module, or unknown parameter (see dmesg)

# dkms remove -m zfs -v 0.7.1 --all
# dkms remove -m spl -v 0.7.1 --all
# dkms --force install -m spl -v 0.7.1
# dkms --force install -m zfs -v 0.7.1
# dkms status
spl, 0.7.1, 3.10.0-514.26.2.el7.x86_64, x86_64: installed
zfs, 0.7.1, 3.10.0-514.26.2.el7.x86_64, x86_64: installed

あとはプールのupgradeをしておしまい。

# zpool upgrade neo
# zpool upgrade morpheus
# zpool upgrade trinity
# zpool upgrade architect

smartmontools self-testのスケジュール設定 (smartd.conf)

smartmontoolsのsmartd.confのself-testスケジュール設定、
デフォのコンフィグには曜日と時間の設定例しかなかったのでメモ。

man – SMARTD.CONF

-s REGEXP
Run Self-Tests or Offline Immediate Tests, at scheduled times. A Self- or Offline Immediate Test will be run at the end of periodic device polling, if all 12 characters of the string T/MM/DD/d/HH match the extended regular expression REGEXP.

T/MM/DD/d/HH

T: テスト種別
  S:Short self-test: 低精度短時間(定期検査に向く)
  L:Long self-test: 高精度長時間
  C:Conveyance self-test: 運搬過程で障害が発生しやすいセクタの検査
  O:Offline immediate-test:オフライン緊急テスト???

MM: 月(01-12)

DD: 日(01-31)

d: 曜日(0-7) 月(1)~日(0,7)

HH: 時間(00-23)

例: Shorttestを毎日00時、Longtestを毎月1,15日00時に実施

DEVICESCAN -a -o on -S on -s (S/../.././00|L/../(01|15)/./00)

テスト種別がS,Lの他にもあるの初めて知った。
HDD買ったら、まずは種別C→Lの順で検査してから運用に回した方がいいかもね。

Seagate Archive HDD ST8000AS0002のLoad Cycle Count

ST8000AS0002

Seagate Archive HDDシリーズの8TBHDD ST8000AS0002を2台購入。
HP ProLiant Microserver(CentOS)上の単一ディスクとして稼働してるんだけど、
Load Cycle Countがどんどん上昇しているのでちょっと気になってきた。

mi0_193_daymi1_193_day

このグラフでいうbay1~3がWD60EFRXとWD60EZRX混在、bay4がST8000AS0002。同じ構成で2台。
bay1~3はidle3-toolsでアイドルタイマーを無効にしているので、横線まっすぐ。
問題のbay4は徐々に上昇している。大体1時間に3~4カウント。
仕様では30万カウントまで対応しているようなので、このまま約8年くらいは耐えられる計算。
…しかしこんなにガンガン上昇するものなの?Seagateはこういう仕様のファームなのかな。
3万時間稼働してるHGSTのHDDなんて1000位しかカウントしてないのに…

このままカウントが上昇していくのは気分的によろしくないので、
カウントを抑制する対策をいろいろ調べて試してみた。

1. idle3ctl –force …NG
2. hdparm -S 0 -Z -B 255 …NG
3. 定期的にDisk I/Oを発生させる …LCC上昇抑制という意味ではOK

1.はWD製HDD以外のHDDでもアイドルタイマーを設定する強制オプション
これはエラーが出て設定NG

# idle3ctl --force -d /dev/sdd
sg16(VSC_ENABLE) failed: Input/output error

2.は-Sがスタンバイ設定、-BはAPM設定、-ZはSeagate用の省電力機能を無効
Sオプションは反映されたけど、カウント上昇は止まらず、ZとBはio errorで設定NG

# hdparm -S 0 -Z -B 255 /dev/sdd

/dev/sdd:
setting Advanced Power Management level to disabled
HDIO_DRIVE_CMD failed: Input/output error
setting standby to 0 (off)
disabling Seagate auto powersaving mode
HDIO_DRIVE_CMD(seagatepwrsave) failed: Input/output error
APM_level = not supported

最後に思いついた3は、ddとcronを使ってディスクIOを繰り返させる。
ディスクにアイドルタイマーがあるとしたら、こいつを発動させないように、
定期的にddとか使ってダミーファイルをディスクに書き込ませてやる。

# vi io.sh
#!/bin/bash
DISK=/mnt/bay4
dd if=/dev/zero of=$DISK/iotest bs=1k count=1
rm -f $DISK/iotest

1KByteのダミーファイルを作っては削除を繰り返させる。
簡単だけどこんなスクリプトを10分間隔で回してみると、LCCが上昇しなくなった。
やった~と思ったんだけど、今後は別の問題が発生。

mi0_193_weekmi1_193_week
mi0_192_weekmi1_192_week

LCCは上昇しなくなったけど、cronで回し始めて1日経ったくらいで、
今度はPower-Off Retract Countがカウントアップする事態に…。
その後はほぼ24時間に1回カウントアップしており、明らかにスクリプトで影響が出てる。
このディスクは積極的にヘッドを休める仕様なのかもしれないね。

現在はPower-Off Retract CountとLoad Cycle Countが上昇しない最適なディスクIOの間隔をテスト中。

RAID6(md)アレイを別のLinuxマシンにマウントする(4/4)

前回の記事の続き、追加検証

検証の流れ

  1. VM0で構成したRAID6アレイに1MBのダミーファイルを100個生成、MD5とファイルサイズを記録。
  2. VM0を停止しVirtualBoxのマネージャからRAID6のVMディスクx4をVM0から解放し、VM1に追加。
  3. VM1を起動し、RAID構成確認、簡易読み書きテスト、および工程1.とのファイル差分チェック。
  4. (追加検証1) 2.の工程で、VM1に対してVMディスクx4のうち2台のみ追加した時の動作確認と、縮退モードでのアレイ立ち上げ。

VMディスクにリードエラーとか障害を起こして検証したかったけど、やり方知らないので、VM0のRAID6アレイのVMディスクが2台死んで、加えてVM0のシステムディスクも故障したので、VM1にRAID6アレイの最低稼働台数である2台のVMディスクを追加して、起動してみようっていう検証。

早速VM1のディスク(disk2,3)を解放、
スペアディスクとして新規ディスク(disk2_spare,disk3_spare)を追加。

raidtest08_1

VM1を起動する。
しかし、シングルユーザーモードになってしまい、正常に起動しない。
/etc/fstabにmd127のマウント設定を書いていたせいかもしれない。

シングルユーザーモードから

# mdadm --detail /dev/md127
mdadm: md device /dev/md127 does not appear to be active.

アクティブではないと書いてあるが、存在はしているようなので、一旦md127を停止してみる

# mdadm --stop /dev/md127
mdadm: stopped /dev/md127

既に構成済みのRAIDアレイを再度認識させるには-A(Assemble)を使う。
-R(Run)はディスク数が必要数に満たなくてもアレイを立ち上げる事ができる。
OSが認識しているディスクを確認する方法は工程1を参照。

# mdadm -AR /dev/md127 /dev/sdb1 /dev/sde1
mdadm: /dev/md127 has been started with 2 drives (out of 4).

# mdadm --detail /dev/md127
/dev/md127:
Version : 1.2
Creation Time : Wed Feb 25 09:42:40 2015
Raid Level : raid6
Array Size : 16765952 (15.99 GiB 17.17 GB)
Used Dev Size : 8382976 (7.99 GiB 8.58 GB)
Raid Devices : 4
Total Devices : 2
Persistence : Superblock is persistent

Update Time : Wed Feb 25 12:06:53 2015
State : clean, degraded
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0

Layout : left-symmetric
Chunk Size : 512K

Name : raid-test0:0
UUID : 5631fad3:0ec41ac1:b6234c79:ab094b44
Events : 70

Number Major Minor RaidDevice State
0 8 17 0 active sync /dev/sdb1
1 0 0 1 removed
2 0 0 2 removed
4 8 65 3 active sync /dev/sde1

無事縮退モードで立ち上げる事が出来た。
この状態で/mnt/md127にマウント可能で、データの読み書きも出来た。
あとは、で新しいディスクをmd127に追加させれば、自動的にRAIDアレイに組み込まれる。
追加させる際は、パーティションの設定をお忘れなく。

# mdadm --add /dev/md127 /dev/sdc1 /dev/sdd1
mdadm: added /dev/sdc1
mdadm: added /dev/sdd1

# mdadm --detail /dev/md127
/dev/md127:
Version : 1.2
Creation Time : Wed Feb 25 09:42:40 2015
Raid Level : raid6
Array Size : 16765952 (15.99 GiB 17.17 GB)
Used Dev Size : 8382976 (7.99 GiB 8.58 GB)
Raid Devices : 4
Total Devices : 4
Persistence : Superblock is persistent

Update Time : Wed Feb 25 12:23:15 2015
State : clean, degraded, recovering
Active Devices : 2
Working Devices : 4
Failed Devices : 0
Spare Devices : 2

Layout : left-symmetric
Chunk Size : 512K

Rebuild Status : 19% complete

Name : raid-test0:0
UUID : 5631fad3:0ec41ac1:b6234c79:ab094b44
Events : 84

Number Major Minor RaidDevice State
0 8 17 0 active sync /dev/sdb1
6 8 49 1 spare rebuilding /dev/sdd1
5 8 33 2 spare rebuilding /dev/sdc1
4 8 65 3 active sync /dev/sde1

# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md127 : active raid6 sdd1[6] sdc1[5] sdb1[0] sde1[4]
16765952 blocks super 1.2 level 6, 512k chunk, algorithm 2 [4/2] [U__U]
[===================>.] recovery = 96.8% (8122812/8382976) finish=0.0min speed=88808K/sec

# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md127 : active raid6 sdd1[6] sdc1[5] sdb1[0] sde1[4]
16765952 blocks super 1.2 level 6, 512k chunk, algorithm 2 [4/4] [UUUU]

以上。

RAID6(md)アレイを別のLinuxマシンにマウントする(3/4)

前回の記事の続き、検証3
VM0からVM1にまるごと移行したRAIDアレイの状態確認。

検証の流れ

  1. VM0で構成したRAID6アレイに1MBのダミーファイルを100個生成、MD5とファイルサイズを記録。
  2. VM0を停止しVirtualBoxのマネージャからRAID6のVMディスクx4をVM0から解放し、VM1に追加。
  3. VM1を起動し、RAID構成確認、簡易読み書きテスト、および工程1.とのファイル差分チェック。
  4. (追加検証1) 2.の工程で、VM1に対してVMディスクx4のうち2台のみ追加した時の動作確認と、縮退モードでのアレイ立ち上げ。

VM1を起動、すんなり起動した。
VM0で構成したRAIDアレイは、VM1を起動した段階で既に認識。
ただし、VM0ではmd0として構成したアレイだったが、md127として認識されていて、
State:の項目がactiveからclean
Name:の項目がVM0と同名(これは当然か)、あと(local to host raid-test0)という表記が消えた。

# mdadm --detail /dev/md127
/dev/md127:
Version : 1.2
Creation Time : Wed Feb 25 09:42:40 2015
Raid Level : raid6
Array Size : 16765952 (15.99 GiB 17.17 GB)
Used Dev Size : 8382976 (7.99 GiB 8.58 GB)
Raid Devices : 4
Total Devices : 4
Persistence : Superblock is persistent

Update Time : Wed Feb 25 09:59:14 2015
State : clean
Active Devices : 4
Working Devices : 4
Failed Devices : 0
Spare Devices : 0

Layout : left-symmetric
Chunk Size : 512K

Name : raid-test0:0
UUID : 5631fad3:0ec41ac1:b6234c79:ab094b44
Events : 19

Number Major Minor RaidDevice State
0 8 17 0 active sync /dev/sdb1
1 8 33 1 active sync /dev/sdc1
2 8 49 2 active sync /dev/sdd1
3 8 65 3 active sync /dev/sde1

cleanの表示が気になったが、mdstatではactiveとなっているため、このままマウントを続行することにした。

# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md127 : active raid6 sdb1[0] sde1[3] sdc1[1] sdd1[2]
16765952 blocks super 1.2 level 6, 512k chunk, algorithm 2 [4/4] [UUUU]

/mnt/md127にマウントしてみる。

# mount -t ext4 /dev/md127 /mnt/md127
#
# df -h
ファイルシス サイズ 使用 残り 使用% マウント位置
/dev/mapper/centos_raid--test1-root 8.5G 1.2G 7.4G 14% /
devtmpfs 492M 0 492M 0% /dev
tmpfs 498M 0 498M 0% /dev/shm
tmpfs 498M 6.6M 491M 2% /run
tmpfs 498M 0 498M 0% /sys/fs/cgroup
/dev/sda1 497M 96M 402M 20% /boot
/dev/md127 16G 1.1G 14G 7% /mnt/md127

無事にマウント出来たので、工程1で取得したファイル差分をチェック。

# ll/ /mnt/md127/
合計 1024016
-rw-r--r--. 1 root root 10485760 2月 25 09:52 file1
-rw-r--r--. 1 root root 10485760 2月 25 09:52 file10
-rw-r--r--. 1 root root 10485760 2月 25 09:52 file100
.....
.....

タイムスタンプ変化無し、ファイル数も100あった。

# find /mnt/md127/ -type f | wc -l
100

MD5値、ファイルサイズも変化無し。

# md5sum /mnt/md127/file*
f1c9645dbc14efddc7d8a322685f26eb /mnt/md127/file1
f1c9645dbc14efddc7d8a322685f26eb /mnt/md127/file100

# du /mnt/md127 -b
16384 /mnt/md0/lost+found
1048596480 /mnt/md127

最後にファイルの読み書きテスト、まず適当にmessagesファイル書き込み

# cp -vp /var/log/messages /mnt/md127/
`/var/log/messages' -> `/mnt/md127/messages'

元ファイルとの差分チェック

# diff /var/log/messages /mnt/md127/messages
#

差分なし、catで表示させてみる。

# cat /mnt/md127/messages
cat /var/log/messages
Feb 25 10:13:16 raid-test1 rsyslogd: [origin software="rsyslogd" swVersion="7.4.7" x-pid="560" x-info="https://www.rsyslog.com"] start
Feb 25 10:13:06 raid-test1 journal: Runtime journal is using 6.2M (max 49.7M, leaving 74.5M of free 490.9M, current limit 49.7M).
.....
.....

以上で、RAIDアレイ移行の検証は終わり、無事別のLinuxマシンでマウント出来ました。
ただmd127のState:がcleanとなっていて気持ち悪いので、activeへの戻し方をご存知の方がいれば教えてください。
次回の記事は、RAID6アレイを低下モードの状態でマウントする事をやってみます。

RAID6(md)アレイを別のLinuxマシンにマウントする(2/4)

前回の記事の続き、検証2
検証というより下準備。

検証の流れ

  1. VM0で構成したRAID6アレイに1MBのダミーファイルを100個生成、MD5とファイルサイズを記録。
  2. VM0を停止しVirtualBoxのマネージャからRAID6のVMディスクx4をVM0から解放し、VM1に追加。
  3. VM1を起動し、RAID構成確認、簡易読み書きテスト、および工程1.とのファイル差分チェック。
  4. (追加検証1) 2.の工程で、VM1に対してVMディスクx4のうち2台のみ追加した時の動作確認と、縮退モードでのアレイ立ち上げ。

VM0をシャットダウンし、VM0のVMディスクx4を解放する。

raidtest01_1

disk0-3 がRAID6を構成したVMディスク、これをVM0から解放する。

raidtest02_1

今度はVM1の設定から、解放したVMディスクx4を追加する。

raidtest04_1

以上で2工程目終了。
肝となる3工程目は次の記事で。

RAID6(md)アレイを別のLinuxマシンにマウントする(1/4)

CentOS7のソフトウェアRAID(md)で構成したRAID6のストレージアレイを、
そのまま別のLinuxOS(CentOS7)でマウントできるか検証してみた。

QNAPやLinkStationなど、mdを利用したNASの筐体/電源故障時、有効かと思われる。
物理的に検証したい所だけど、パーツがないので仮想マシン(VirtualBox)で検証した。

検証VM構成

  1. raid-test0 …以降「VM0」と呼ぶ
  2. HDD0(10GB) : LVM(単一ディスク:システム用)
    HDD1-4(8GBx4): RAID6(ソフトウェアRAID:データ用)
    OS: CentOS7

  3. raid-test1 …以降「VM1」と呼ぶ
  4. HDD0(10GB) : LVM(単一ディスク:システム用)
    OS: CentOS7

検証の流れ

  1. VM0で構成したRAID6アレイに1MBのダミーファイルを100個生成、MD5とファイルサイズを記録。
  2. VM0を停止しVirtualBoxのマネージャからRAID6のVMディスクx4をVM0から解放し、VM1に追加。
  3. VM1を起動し、RAID構成確認、簡易読み書きテスト、および工程1.とのファイル差分チェック。
  4. (追加検証1) 2.の工程で、VM1に対してVMディスクx4のうち2台のみ追加した時の動作確認と、縮退モードでのアレイ立ち上げ。

検証1
VM0で構成したRAID6アレイに1MBのダミーファイルを100個生成、MD5とファイルサイズを記録。

Continue reading

php opcache.enableの有効化

紙の問題集で勉強するよりも、スマホとかPCのブラウザでポチポチ問題解きながら勉強するのが好きなので、moodle使って勉強したりする。

ただmoodle導入の時に、環境設定でopcache.enableだけステータスがcheckになってた。

opcache.disabled

これまで放置して使ってたけど、気持ちが悪いので調べてみると、

yumでインストールしたPHP 5.5.XでOPcacheを有効にする方法
https://www.shirakobato-ss.com/columns/ict-columns/open-source/998/

この方法を試してみたらいけた。
ソースからインストールしてる人は上の記事にも書いてあるけど、
コンパイルの時に
# ./configure --enable-opcache ってやればいいみたい。

CentOS7の/var/log/messagesに大量のStarting Sessionがあってログが見難い

Feb 20 19:30:01 mi0 systemd: Started Session 1051 of user root.
Feb 20 19:35:01 mi0 systemd: Starting Session 1052 of user root.
Feb 20 19:35:01 mi0 systemd: Started Session 1052 of user root.
Feb 20 19:40:01 mi0 systemd: Starting Session 1053 of user root.
Feb 20 19:40:01 mi0 systemd: Started Session 1053 of user root.
Feb 20 19:45:01 mi0 systemd: Starting Session 1054 of user root.
Feb 20 19:45:01 mi0 systemd: Started Session 1054 of user root.
Feb 20 19:45:23 mi0 systemd: Starting Session 1055 of user root.
Feb 20 19:45:23 mi0 systemd: Started Session 1055 of user root.

こんな感じで大量に出力されてた

# vi /etc/systemd/system.conf

#LogLevel=info

LogLevel=notice
に変更して再起動したら出力されなくなった。
デフォルトがinfoなのね。

Amazon.co.jp限定 2+1年保証のWD Greenについて

Amazon.co.jp商品情報

WD公式サイトでタイトル製品の保証期限を確認すると「3年」のはずが「2年」になっていたので、対応覚書。

【やること】
・WDポータルに該当のHDDを登録して、そこからサポートに問い合わせる
 (問合せフォームにファイルアップローダーが付いているので、領収書をアップロードする)
 → 3年に修正してもらえる

【今回の対応フロー】
WDC公式サイトで保証期限を確認 → 3年保証のはずなのに2年しかない
② ①についてAmazonに問い合わせる → 保証についてはWDに直接確認するようにと
WDポータルに登録、該当HDDを追加してポータルからサポートフォームで①について確認
④ WDよりメールで領収書を送付するよう依頼される
⑤ Amazonの領収書をスキャナーでデータにしてWDに送付
⑥ WDよりメールで領収書の受領確認と、調査開始の連絡
⑥ ⑤から約5日後、WDより保証期限を3年に修正したとの連絡
⑦ 再度①を実施 → 保証期限が3年となっている事を確認

メールのやりとりはすべて日本語で、担当の方も親切な対応で好感がもてた。

WDのRMAを使う場合はシンガポールまで送る必要があるので(2000円くらい掛かる)、かなり面倒。
いずれ必ず壊れるであろうHDDは、
少々高くてもTSUKUMOとか小売店がやってる延長保証を、使うのが賢いと思った。

追記:よくよく調べてみると、TSUKUMOの5年保証の内容が微妙だった…おとなしくRMAしましょ。