このブログをDockerのコンテナ(Centos7)に移設して2日くらい経って、
Dockerのホストサーバ(CentOS7)のCPU使用率が高くなっている事に気付いた。

top - 18:28:32 up 2 days, 47 min, 5 users, load average: 0.99, 1.02, 1.08
%Cpu(s): 12.0 us, 38.5 sy, 0.0 ni, 49.5 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 32818248 total, 11518944 free, 17437140 used, 3862164 buff/cache
KiB Swap: 511676 total, 511676 free, 0 used. 13301472 avail Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
5822 root 20 0 8028 836 716 R 100.0 0.0 2925:31 agetty

ホストサーバからtopコマンドで確認したら、agettyのCPU使用率が異様に高くなっていた。
調べるとdockerのバグ？の模様。

Bug 1046469 – docker privileged mode with cmd /sbin/init – agetty & high cpu

docker runで–privileged, /sbin/initしてると発生するみたい。
解決方法としては、対象のコンテナにログインして、
agetty.targetとsystemd-udevd.serviceを停止,自動起動無効にする。
これで暴走しなくなった。

コンテナにログイン
# docker exec -it [container name] /bin/bash

agettyの状態確認、停止、自動起動無効化
# systemctl status agetty.target
# systemctl stop agetty.target
# systemctl disable agetty.target
# systemctl status agetty.target

systemd-udevdの状態確認、停止、自動起動無効化
# systemctl status systemd-udevd.service
# systemctl stop systemd-udevd.service
# systemctl disable systemd-udevd.service
# systemctl status systemd-udevd.service

で最後にコンテナの停止/開始

# docker stop [container name]
# docker start [container name]

MicroserverでNAS作ったり、QNAPとかSynologyのNAS買ったりしてもいいんだけど、
前者はHDDがあまり積めないのと、後者は高い割に最大でも1つの筐体で10台くらいしかHDD積めないので、
自作NASを作ってHDD積みまくることにした。

【自作NAS要件】
①　既成品よりHDDを多く積める (今回はSATA 22ポート)
②　NASの基本サービス(Samba, DLNA, NFS, iSCSI)が利用できる
③　ファイルシステムにZFSが利用できる
④　③を安定的(精神的な部分も含め)に運用できるようECCメモリを実装できる
⑤　NICを束ねる事(bonding)ができる (1Gbps x2)

以上の要件を踏まえて材料集め。

【材料】
CASE:　Antec Nine Hundred AB (家にあったケース、確か3.5インチベイは6つ)
CPU:　Intel Pentium G3258 (3.2GHz Dual-Core, ECC対応)
M/B:　ASUS P9D WS (Unbuffered ECC対応, SATA3 x6ポート)
MEM:　Kingston KVR1333D3E9SK2/16G x2 (Unbuffered ECC)
PWR:　Corsair RM1000 (1kW)
HBA:　LSI SAS 9211-8i x2 (PCIe[x8] SATA3 8ポートx2)
SSD:　CSSD-S6T128NHG6Q x2
HDD (新規購入の他にQNAPで使っていたHDDも流用)
WDC:　WD30EFRX x6, WD40EFRX x3, WD60EFRX x4, WD60EZRX x2
Seagate:　ST8000AS0002 x4
HGST:　0S03361(ALE640) x1

今回検討するにあたりPentiumがECC対応していることに驚いた。
Xeon入れなきゃダメかなとおもっていたけど、安く上がった。
ただ一般のマザーボードはECC対応していないので、割高のワークステーション用マザーを購入。
これでもRegisteredなメモリはダメで、Unbufferedのみ対応。仕方ないね。
ワークステーション用だからか、オンボードNICが2つ付いてる。

メモリはUnbuffered ECCなものを32GB、ZFSはメモリをたくさん使うのでそこそこ積んだ。

電源は1000W、たくさんのHDDが一斉にスピンアップすると考えると、これくらいあると安心かな。

そして今回HDDを多く積むために購入したのが、SASホストバスアダプター。
SATA3対応のものはヤフオクで1枚1万～2万くらいで手に入る。
miniSAS端子2つから8つのSATA端子に枝分かれできるので、2枚積めばSATA 16ポート。
マザーの6ポートと合わせて22台確保できるので、これでガンガン積める。
マザーのPCIe x8以上のスロットはまだ2つ余っているので、もっと積もうと思ったら積める。
SASエキスパンダーカードを使うという手もある。

SSDはシステム用、2台でミラー構成にするため用意。
HDDは最初WDでまとめようと思ったけど、Seagateの8TBにそそられて導入。
合計で総容量は102TBだけど、SSDと同じくミラー構成にするので最大で50TBより少ないくらい。

この材料だとドライブ22台認識させる事はできるけど、
PCケースには6台、5台積めるHDDエンクロージャーをケースに3台積んでも15台までしか内蔵できない。
そうなるとHDDは外に出して、ケースなりに入れて設置することになるわけだ。
調べてもらうとわかるけど、外付けのエンクロージャーは高いし、SASのアダプタやケーブルも高い。
もう1個PCケースを買って、その中に積むのも検討したけど、結局こうなった。

長めのminiSAS-SATAファンアウトケーブルと電源ケーブルでPCケース外に伸ばし、
スチールラックの上に裸族のビキニでHDD4台積み上げて、12cmファンの扇風機で冷却。
HBAの16ポート分はこれで設置して、残りの6台はPCケースに内蔵。
埃をHDDに吹き付ける状態になるので、ファン扇風機の吸気側にフィルタを付けた。
次に材料コスト。

【材料コスト(HDD除く) 2015/08/28現在】
Antec Nine Hundred AB　:　\5,000 (中古でこれくらい？)
Intel Pentium G3258　:　\8,278
ASUS P9D WS　:　\33,550
Kingston KVR1333D3E9SK2/16G x2　:　\39,080
Corsair RM1000　:　\20,968
LSI SAS 9211-8i x2　:　\32,000
CSSD-S6T128NHG6Q x2　:　\16,718
miniSAS → SATA ファンアウトケーブルラッチ付 x4　:　\5,920
ミヨシ MCO 電源変換ケーブル 15PIN-大4P/4分岐 41cm JDH-SD4/41　:　\2,156
変換名人 ペリフェラル(大4ピン) → SATA(15ピン)電源変換4分岐ケーブル IDEP-SPR/4 x4　:　\537
センチュリー 裸族のビキニ HDD用スタンドキット CRBK2 x8　:　\5,080
USBどこでもでか扇風機 ブラック UMF02BK　:　\6,400 (黒はもう売ってない？)

合計:　\170,687

もう1枚HBAカードとケーブル類買っても20万超えない。
ECCメモリとかシステムドライブ冗長に拘らなければあと3,4万くらい安くなりそう。

【既成品NAS/サーバとコスト比較】
[4bay] HP Microserver N54L　\12,980 (最安価格NTT-X売り切れ)
[8bay] ASUSTOR AS5008T　\107,200
[8bay] QNAP TS-851　\139,798
[8bay] Synology DS1815+　\155,660
[10bay] ASUSTOR AS5010T　\124,800
[12bay] QNAP TS-1253U-RP　\329,486
[16bay] TS-1279U-RP Turbo NAS　\411,354
[22bay] 自作NAS　\170,687

積む台数が少ないならNASとかMicroserverでいいんじゃないかな。
安く多く積むなら自作ですな。

ソフト編は次回。

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

検証の流れ

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)を追加。

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]

以上。

前回の記事の続き、検証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アレイを低下モードの状態でマウントする事をやってみます。

前回の記事の続き、検証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を解放する。

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

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

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

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

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

検証VM構成

1. raid-test0 …以降「VM0」と呼ぶ

HDD0(10GB) : LVM(単一ディスク:システム用)
HDD1-4(8GBx4): RAID6(ソフトウェアRAID:データ用)
OS: CentOS7

2. raid-test1 …以降「VM1」と呼ぶ

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 →

QNAP TS-869L(3TBx8 RAID5)を使ってるんだけど、容量が足りなくなってきたので、NAS増設を検討。
QNAPかSynologyの8ベイNASを増設しようかとも考えたんだけど、
筐体故障時のリスクと、HDD抜きで1台15万くらいするコストを考えると、NAS増設案は微妙になってきた。
そこでHP ProLiant MicroServer(N54L) 2台でNFSサーバを作り、
既存のQNAP NASでNFSをマウントさせて、ストレージを増強した。

Microserver(N54L) はこんなやつ。

ドライブキャパは3.5inchx4 + 5inchx1
メモリ4GB、HDD500GB、2コアAMDCPUで\12,980、ものすごくコスパ高い。

QNAP増設用NFSサーバの構成は

NFS ACT (CentOS7)
system: MB0500EBNCR 500GB
bay1: WD60EFRX 6TB
bay2: WD60EFRX 6TB
bay3: WD60EFRX 6TB
bay4: WD40EFRX 4TB

NFS SBY (CentOS7)
system: MB0500EBNCR 500GB
bay1: WD60EZRX 6TB
bay2: WD60EFRX 6TB
bay3: WD60EZRX 6TB
bay4: WD40EFRX 4TB

拡張容量は22TB、6TBHDDx6は新規購入、4TBHDDx2は外付けデバイスとして使用していたもの。
RAIDは組まず単体のHDD構成(ext4)、2日に1回SBYはACTとデータを同期(Rsync)。
RsyncとSMARTのLongtest時以外、SBYは電源OFF。

ACTの筐体が故障した場合でもSBYで稼働できるし、
ACTのbayXのHDDが故障した場合でも、そのHDDをアンマウントしてSBYのBayXと挿し換えれば、元通り。
24時間365日の高可用性は必要ないから、最も単純な構成にした。

ACTとSBYのデータ同期が2日に1回なので、ACTが死亡した時に一部データを失う可能性もあるが、
基本はQNAP NASに保存していたデータをNFSに退避する使い方で、
15日間はQNAP NASの@Recycleにデータが退避されるよう設定してあるので、
データを完全消失する心配はない。

この構成で稼働させて1ヶ月くらい経ったので、やったことを書いていこうかな。