ディスクが足りない、って状況はしばらく前から発生していたんですが、どうやって解決するか、かれこれ数ヶ月悩んで、結局、SATA IFボード（SATA3RI4-PCIE）＆HDD（WD20EZRX）追加導入となりました。やっと動き出したんですが、今回はなんだか大変だった。という、お話。
我が家のサーバー環境
まずは起きていたこと。地デジサーバーのHDDが壊れて、もういやになって3TB×2のRAID構成で信頼性と容量を確保したのが、先月の話。そもそもなんでこんな事態を招いたかといえば、原因は母艦となっているファイルサーバーの容量不足です。
我が家の母艦サーバーは仮想化環境で、システムボリュームSSDで64GB、データ領域として、2TB HDD×7×RAID6で10TBの容量になっています。このデータ領域のうちの2TBは汎用エリア（TimeCapsuleとか、仮想マシンのシステムボリュームとか、いろいろ検証データとか）で使っており、残りの8TB、実質的には2TB×4で運用しているのが、地デジバックアップ領域です。この地デジバックアップ領域がいっぱいなのが、根本的な原因です。
そこで、HDDの増設を検討したのですが、SATAポートが無い。M/BのSATAポートは６本。これに拡張ボードのSATAポート2本で、8本しかないので、単純にHDDを追加するという対応は無理でした。
どうやってHDDを増やすか。
HDDを増やす方法にはいくつかあります。
案１。マシンそのものを作り直す。そもそも現状、SSD/HDD×8台という環境は耐障害性という意味でもあまりよい状態ではないです（パーツ数が増えれば故障点が増えます）。大容量のHDDに買い換える。ついでにM/BやCPUも替える、というのが、ベストだとは思ったのですが、いかんせんこれにはお金がかかる。
案２。HDDだけでも買い直す。HDDを4TB等の大きな容量のものに置換するという案があったのですが、これはそうそうに却下されました。過去、HDDの増設に合わせて、RAID構成を変更して、内部でデータを移行して・・・というマイグレーションを実施した経験はあるのですが、今回はSATAの空きがそもそも無いこと、2TB×7でRAID/LVが組まれており、この容量を減らしていくというオペレーションが結構危険であること、など、正直現実的ではないということで、この案は却下です。
案３。M/B、CPUを買い直す。ここから現実案です。SATAポートを増やす方法その１です。既に使っているCPU、M/Bが結構古いので、この機会に買い換えよう、という案です。それに合わせて、M/BにSATAポートが大量に付いているものを選べないか、と。比較的現実的な案だったのですが、このSATAポートを大量に持っているM/Bというのが、なかなかに高い。また、M/Bによって、eSATAと共用で、結局使えるポートがいくつになるのか、良く分からないものもあり、ちょっと踏ん切りが付かない感じでした。最後の最後まで悩みましたが、M/B置換には至らず。
案４。SATAポート増設。まぁ成功法。なんですが、ここにも問題があり。既にPCIe X1 I/Fが無い。M/BがMicro ATAということもあり、PCIe x1は2個しかない。1個はGbE（2本目）で利用中。STP等の検証を行う上で、GbE×2本構成はやめられない。もう1個はSATA拡張。困った。そこで目をつけたのが、PCIe X16ポートです。どうせサーバー用途なので、グラボなんて挿す予定もないです。また、x16ポートは下位互換性があるためx2/x4/x8等の拡張カードは挿せそうです。x1とは物理的に互換性が無いため、ちょっと盲点でしたら、これを使って拡張することにしました。
結論。案４。まだケースにはHDD増設の余裕はありそう（ドライブ10個まで行けそう・・・って、これも限界近いですが）。いずれにせよHDD台数を減らすなどの対応は次には必要になると思っています。ただ、今回の決定打、実は「4TB HDDのバイト単価が思ったほど安くなってなかったこと」なんです。現状、HDDバイト単価のベストは3TB程度。これでは、今の2TBによる構成から、容量1.5倍にしかならない計算で、実はあまり嬉しくないのです。もうちょっと、バイト単価がシフトしてくれると嬉しい、というのが、本音です。
さて、次は、何を、どこで、買うか、です。
拡張ボードとHDDの選択、そしてAmazonでパーツを買う
私の生活圏でPCパーツを買うとなると、ヨドバシ、PCデポ等の量販店か、秋葉まで遠征、ということになります。HDD増設方法の検討の中でも、何度か店頭に足を運んで、M/Bのポート構成を見たり、拡張ボードを見たり、HDDを見たり、していたのですが、購入に至っていません。従来、増設HDDはPCデポで買っています。なぜなら、十分近く、十分安いからです。
今回は、PCIe x2以上のSATA3拡張ポートという、結構レアな要件のパーツのため、これは秋葉かなぁと思いつつ、いろいろ調べていたわけですが、意外にAmazonのPCパーツラインナップが悪くないことに気づきました。正直、秋葉まで行って歩きまわる手間暇を考えると、通販は悪くない選択肢です（まぁ、秋葉ってところは、この手間暇というか、フラフラと歩きまわって何かを見つける、っていうのを楽しめるなら、良い場所だと思います）。
そこで、Amazonで買ってみることにしました。
拡張カードの選択肢は以下の2択になりました。
- エアリア TTH QUATTRO PCI Express x4接続 SATA 4ポート eSATA 2ポート 排他仕様 RAID機能搭載 SD-PE4SA3ES4L
- エアリア TTH LIMOUSINE PCI Express x4接続 SATA 4ポート mSATA 2スロット 排他仕様 RAID機能搭載 SD-PE4SA3mSAL
- 玄人志向 インターフェースボード SATAポート増設 PCI-Express x2 SATA3RI4-PCIE
機能的にはベストはTTH LIMOUSINEなんですが、ちょっと機能盛りすぎなところが気になりました。また、TTHの2枚のカードは、4ポートのSATAのうち2ポートが、ボード面に垂直に立っているため、ケーブルの抜き差しに制約がありそう。結局どのボードも搭載しているチップは88SE9230ということで機能的な差は無さそうです。今使っている拡張SATAボードが玄人志向だったということもあり、結局拡張ボードはSATA3RI4-PCIEにしました。
この選択が、後に様々な問題を引き起こすのですが・・・。
HDDはWD20EZRX一択です。Amazonでも結構安く出ていますし、毎度おなじみ、Amazon限定パッケージになっているということで、まぁ興味もあり、これを選択。
注文は9/20、到着は9/22、受け取れず、9/23祝日に受け取りました（ついでにfripSideのアルバムも買いました！）。
パーツが届いてから物理的拡張作業まで
そんなわけで届きました。SATA3RI4-PCIE。
WD20EZRXは専用パッケージということで、ダンボールによる簡易包装になっています。ユピテルの専用モデルと同じような感じですが、こちらは単に包装だけで、中身は普通のバルクHDDです。
ついでにケーブルも買っておきました。意外にあとで実は足りなかった、って、あるんで・・・
早速取り付けます。取り付け前のサーバーの状態。
拡張ポートはPCIE x16 ×１が中央青色で空いている分、その下２個がPCIe x1の２個、一番下に普通のPCIもありますが、ここにはメーカーは忘れましたが、tulipのFastEthernetカードが挿してあります。仮想OSの主IFはこっちにしてあって、GbEの２本は仮想環境にすべて当てています（ま、結構真面目にプライベートクラウドにしているつもりです）。
ボードを挿すとこんな感じになります。４ポートのIFがすべて横に出てくるため、保守性は良さそうです。ちなみに、冷静に考えると、4×SATA 6Gbって、PCIe x2では帯域足りないんじゃない？と気づいたんですが・・・
HDDも加えた全体図はこちらです。
ちなみに、最終的にはこの写真の構成にはなっていません。拡張ボードのポート接続構成をいろいろ変更しています。理由は、後述。
ここまで組んだ時点で、動作確認をします。とにかくHDDが見えなければ初期不良もあるわけで、さて、ここから、長い戦いが始まりました・・・
SATA3RI4-PCIE（88SE9230）はLinuxでは不安定？拡張ボードとの戦い
そういえばSATA3RI4-PCIEというかMarvel 88SE9230について、嫌なレビューがAmazonのページにありましたっけ。事象としては、
- 高負荷状態でSMARTコマンドを投げるとHDDとの接続が切れる
- Linuxで発生する。
まぁ投稿時期が2013年なので、最近のカーネルでは対処してるかなーという、甘い考えがあったのですが、結論からいうと、CentOS 6で、この事象、発現しました。
まず、１日目。上の写真を撮った時点です。
拡張ボード２枚には、HDDが２台とシステムボリューム用SSDが繋がっています。まずは何も考えず、今回拡張したHDDを今回追加した拡張ボードに繋いで起動しました。いきなりですが、拡張したHDDがOSから見えない（dmesg、/proc/partitionsに出てこない）事案発生。
電源OFF、ONを繰り返したりすると、なんとHDDが見えたり、見えなかったりする始末。これもしかして、拡張ボードの問題？とか、Marvelチップの拡張ボード２枚使ってるのが悪い？とか、いろいろ悩んで調べてみました。
この時の原因：HDD側のSATAケーブルのルーズコネクト。いや、あり得ないと思いつつ、実は結構コネクタが深くて、爪がかかってなかったという。よーく押し込んで、爪がカチッとはまる状態にしたら、HDD認識問題は解決しました。教訓：やっぱり物理接続の確認は基本です・・・。
２日目。HDDが見えるようになったのは良いんですが、拡張ボード側の２台のHDDが、見えたり、見えなかったりする。今度はソフトウエア問題だよなぁ、と思いつつ、まずは２枚のMarverlボードが嫌われている可能性があったため、SATA3RI4-PCIEの４ポートに、SSDとHDD×２、すべてのデバイスを繋げる構成にしました。こうすることで、BIOSのprobeも１回になり、全デバイスが安定的に見えるようになりました。
この状態で、RAID領域の拡張を実施しました。後で考えれば、もうちょっとエージングすべきだったと思いますが・・・
md128 : active raid6 sdf2[2] sdb2[6] sdd2[0] sdc2[5] sda2[7] sdi2[8] sde2[1]
9766256320 blocks super 1.0 level 6, 64k chunk, algorithm 2 [7/7] [UUUUUUU]
作業前、 7台構成のRAIDです。
[root@ikaros ~]# cat /proc/partitions |grep sd 8 16 1953514584 sdb 8 17 262144 sdb1 8 18 1953251416 sdb2 8 32 1953514584 sdc 8 33 262144 sdc1 8 34 1953251416 sdc2 8 48 1953514584 sdd 8 49 262144 sdd1 8 50 1953251416 sdd2 8 80 1953514584 sdf 8 81 262144 sdf1 8 82 1953251416 sdf2 8 64 1953514584 sde 8 65 262144 sde1 8 66 1953251416 sde2 8 112 62522712 sdh 8 113 512000 sdh1 8 114 62009344 sdh2 8 96 1953514584 sdg 8 128 1953514584 sdi 8 129 262144 sdi1 8 130 1953251416 sdi2 8 0 1953514584 sda 8 1 262144 sda1 8 2 1953251416 sda2
新しいHDDはパーティションの無い状態で、sdgに見えていますので、RAIDパーティションを作って、組み込みます。partedで他のパーティションに合わせてパーティションを設定。ちなみに、sdx1パーティションは、使ってないけど、いざというときbootできるようにあえて作っているパーティションです。raidフラグを忘れない。
番号 開始 終了 サイズ タイプ ファイルシステム フラグ 1 2048s 526335s 524288s primary 2 526336s 3907029167s 3906502832s primary raid
まずはこのパーティションをraidに組み込みます。スペアで組み込まれます。
[root@ikaros ~]# mdadm --manage /dev/md128 --add /dev/sdg2
mdadm: added /dev/sdg2
[root@ikaros ~]# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md128 : active raid6 sdg2[9](S) sdf2[2] sdb2[6] sdd2[0] sdc2[5] sda2[7] sdi2[8] sde2[1]
9766256320 blocks super 1.0 level 6, 64k chunk, algorithm 2 [7/7] [UUUUUUU]
ここから、戻れない作業に進みます。現在、7本でRAID6で、10TBとなっているところを、8本でRAID6で、12TBという構成に変更していきます。grow発行。ここからが怖いです・・・
[root@ikaros ~]# mdadm --grow /dev/md128 --raid-disks=8 mdadm: Need to backup 1920K of critical section..
そうすると、reshapeが発行されます。reshape前。
[root@ikaros ~]# mdadm --misc --detail /dev/md128
/dev/md128:
Version : 1.0
Creation Time : Sun Sep 16 18:36:52 2012
Raid Level : raid6
Array Size : 9766256320 (9313.83 GiB 10000.65 GB)
Used Dev Size : 1953251264 (1862.77 GiB 2000.13 GB)
Raid Devices : 7
Total Devices : 8
Persistence : Superblock is persistent
Update Time : Tue Sep 23 18:05:45 2014
State : clean
Active Devices : 7
Working Devices : 8
Failed Devices : 0
Spare Devices : 1
Layout : left-symmetric
Chunk Size : 64K
Name : ikaros:128 (local to host ikaros)
UUID : 00c4b681:e64041ac:43fabc3b:a31de304
Events : 82531
Number Major Minor RaidDevice State
0 8 50 0 active sync /dev/sdd2
1 8 66 1 active sync /dev/sde2
2 8 82 2 active sync /dev/sdf2
8 8 130 3 active sync /dev/sdi2
5 8 34 4 active sync /dev/sdc2
7 8 2 5 active sync /dev/sda2
6 8 18 6 active sync /dev/sdb2
9 8 98 - spare /dev/sdg2
reshape発行後。
[root@ikaros ~]# mdadm --misc --detail /dev/md128
/dev/md128:
Version : 1.0
Creation Time : Sun Sep 16 18:36:52 2012
Raid Level : raid6
Array Size : 9766256320 (9313.83 GiB 10000.65 GB)
Used Dev Size : 1953251264 (1862.77 GiB 2000.13 GB)
Raid Devices : 8
Total Devices : 8
Persistence : Superblock is persistent
Update Time : Tue Sep 23 18:07:49 2014
State : active, reshaping
Active Devices : 8
Working Devices : 8
Failed Devices : 0
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 64K
Reshape Status : 0% complete
Delta Devices : 1, (7->8)
Name : ikaros:128 (local to host ikaros)
UUID : 00c4b681:e64041ac:43fabc3b:a31de304
Events : 82601
Number Major Minor RaidDevice State
0 8 50 0 active sync /dev/sdd2
1 8 66 1 active sync /dev/sde2
2 8 82 2 active sync /dev/sdf2
8 8 130 3 active sync /dev/sdi2
5 8 34 4 active sync /dev/sdc2
7 8 2 5 active sync /dev/sda2
6 8 18 6 active sync /dev/sdb2
9 8 98 7 active sync /dev/sdg2
[root@ikaros ~]# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md128 : active raid6 sdg2[9] sdf2[2] sdb2[6] sdd2[0] sdc2[5] sda2[7] sdi2[8] sde2[1]
9766256320 blocks super 1.0 level 6, 64k chunk, algorithm 2 [8/8] [UUUUUUUU]
[>....................] reshape = 0.0% (715264/1953251264) finish=1752.9min speed=18563K/sec
果報は寝て待て、ということで、この状態でしばらく置いておいたのですが・・・・
気が付くと大災害になっていました。コマンドラインとか取っていないので、テキストで書きます。
結局、「高負荷で88SE9230以下に繋がっているHDDが切断される事件」が発生してました。どうなったかといいますと、
- SSD（システムディスク）が読めなくなって、いくつかのコマンドでbus errorが出る状態になっていた。
- RAIDボリュームのうちの、拡張ボードに繋いだ2本がFailステータスになって、切り離されていた。8本構成のRAID6なので、データ冗長でかろうじて、データは保持された（超危なかった）
これ、おそらく、Linuxのmdが相当優秀な動作をしています。HDDがfailになったタイミングで、reshapeのポリシーを変更して、データが保持できる構成にしたらしい（システムの負荷統計で、failになった瞬間から負荷傾向が変わっている）。ディスク構成上、データが保持できるサイズは持っているので、とりあえず冗長無し状態で、12TBのraid6に作り変えたという。過去、HDD増設マイグレーションでも、このパターンの操作（一部HDDが足りない状態で、冗長ボリュームを作ってデータを移していく）はやったことがありましたが、growの最中でもこの動きをしてくれるところは、流石といったところです。
・・・って、感心している場合じゃない。やっぱ動かないじゃん、と、露頭に迷った3日目。
動かないなら、動かせばいい。以下のとおり対策を実施。
- SATA3RI4-PCIE/88SE9230のファームウエアアップデート。USBイメージ作って、ファーム書き換えを実施。2.2.0.xっていう最新版に上げてみる。
- RAID再構成で負荷のかかるHDD×２を、旧来のSATA拡張ボードに移し、SATA3RI4-PCIE側に負荷がかかるのを避ける。SATA3RI4-PCIE側にはシステムボリュームのSSDのみを残す。
この構成にして、再度ボリュームを組み直し、今度はRAIDの再構成のみを実施（既にreshapeは完了しているため）。実質、HDD２台のリカバリ処理が走り、今度は無事、完了しました。SATA3RI4-PCIE側の残りの３ポートが使えるかどうかは、とりあえずあとで考えるとして（苦笑）、まずは増設優先。何度か再起動したりして安定を見ていますが、この構成でなんとか動いています。
さて。嵐のSATA3RI4-PCIEとの戦いを制し、次へ進む。
Personalities : [raid6] [raid5] [raid4]
md128 : active raid6 sdh2[9] sdi2[8] sdd2[0] sdf2[2] sde2[1] sdc2[5] sda2[7] sdb2[6]
11719507584 blocks super 1.0 level 6, 64k chunk, algorithm 2 [8/8] [UUUUUUUU]
無事、物理領域は8台で12TBになったので、LVMの構成を変更していきます。結局これも、PVだけ認識させれば、VGは自動で拡張されて、使える状態になりました。マジLVM優秀。
作業前の状態。概ね10TBです。
[root@ikaros ~]# pvdisplay --- Physical volume --- PV Name /dev/md128 VG Name vg0 PV Size 9.10 TiB / not usable 15.50 MiB Allocatable yes PE Size 32.00 MiB Total PE 298042 Free PE 1945 Allocated PE 296097 PV UUID Vz7aws-0M3d-yPsE-1EFT-1pn9-1EGK-QtkOwL
物理デバイスmd128は拡張されているので、これを認識させます。
[root@ikaros ~]# pvresize /dev/md128 Physical volume "/dev/md128" changed 1 physical volume(s) resized / 0 physical volume(s) not resized
無事拡張されたようですので、確認してみます。
[root@ikaros ~]# pvdisplay --- Physical volume --- PV Name /dev/md128 VG Name vg0 PV Size 10.91 TiB / not usable 31.44 MiB Allocatable yes PE Size 32.00 MiB Total PE 357650 Free PE 61553 Allocated PE 296097 PV UUID Vz7aws-0M3d-yPsE-1EFT-1pn9-1EGK-QtkOwL
VGも操作が要るかと思っていたのですが、配下のPVが拡張されたことで自動的に容量は追加されてました。
[root@ikaros ~]# vgdisplay --- Volume group --- VG Name vg0 System ID Format lvm2 Metadata Areas 1 Metadata Sequence No 67 VG Access read/write VG Status resizable MAX LV 0 Cur LV 30 Open LV 10 Max PV 0 Cur PV 1 Act PV 1 VG Size 10.91 TiB PE Size 32.00 MiB Total PE 357650 Alloc PE / Size 296097 / 9.04 TiB Free PE / Size 61553 / 1.88 TiB VG UUID swA2Oy-LOcJ-0Uup-iCot-2NEZ-xaPw-112gD5
つまり、もうLVとしては切り出せる状態ということです。早速切り出します。目標は2TBなんですが、今回は1TB切り出し。また足りなくなったら拡張するのは容易ですので。
[root@ikaros ~]# lvcreate -L1000G -n klein.xvdv vg0 Logical volume "klein.xvdv" created
これをファイルサーバーとなっている仮想OSに認識させます。追加にはいろんな方法がありますが、最も簡単なvirt-managerからの追加を行いました。
こんな感じで追加すると、仮想ドライブについては、仮想OSを再起動しなくても、オンラインでディスクが見えるようになります。これがオンラインでできるかどうかは、仮想OS側の実装にもよるので、なんでも行けるとは限りませんが、準仮想化ドライバに対応したkernelのLinux（たいていのディストリビューションはイマドキ対応しています）が仮想環境で動いていれば、まず問題なく見えるようになります。
参考までに、私がMacでvirt-managerを使うときの手順。
- 仮想サーバーにはgdmとデスクトップ環境を入れておく
- init 5でgdmを動かす
- Macのコマンドラインから、X -query <servername>として、xdmセッションを開始する
- 作業が終わったら「ログアウト」して、サーバー側でinit 3にしてgdmは落としておく。
文字入力等でたまに困ることがあるので、そのときはtigervncを使います。その場合は「vnc://server」に接続、で行けますね。
戻ります。仮想環境でHDDを使えるようにします。仮想OS側から、パーティションを作ります。
klein ~ # parted /dev/vdi GNU Parted 3.1 Using /dev/vdi Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) mklabel gpt (parted) mkpart pri ext4 2048s -1s Warning: You requested a partition from 1049kB to 1074GB (sectors 2048..2097151999). The closest location we can manage is 1049kB to 1074GB (sectors 2048..2097151966). Is this still acceptable to you? Yes/No? Y (parted) p Model: Virtio Block Device (virtblk) Disk /dev/vdi: 1074GB Sector size (logical/physical): 512B/512B Partition Table: gpt Disk Flags: Number Start End Size File system Name Flags 1 1049kB 1074GB 1074GB pri
続いて、ファイルシステムを作りますが、このボリュームは地デジ録画データの保存領域ですので、極限までinodeは減らします。１ファイル3GB程度が想定ファイルサイズなんですが、そこまでは指定できないので、以下のような感じにします。
klein ~ # mkfs.ext4 -j -m 0 -i 8192000 /dev/vdi1 klein ~ # tune2fs -c 0 -i 0 /dev/vdi1
あとは、/etc/fstabに追記して、マウントすれば良い（個人的にすべてUUIDで指定しています）。
そして完成です。とりあえず2TB増設分から1TBの割り当てが完了した状態。
klein ~ # df Filesystem 1K-blocks Used Available Use% Mounted on /dev/vda3 18188044 12582944 4658156 73% / devtmpfs 4052972 0 4052972 0% /dev tmpfs 4096612 0 4096612 0% /dev/shm tmpfs 4096612 684 4095928 1% /run cgroup_root 10240 0 10240 0% /sys/fs/cgroup /dev/vda1 253871 192076 48688 80% /boot /dev/vdb1 8124856 5927980 1761116 78% /var /dev/vdc1 426397160 333968580 92412196 79% /raid0 /dev/vde1 2096753804 2069904448 26832972 99% /raid1 /dev/vdg1 2096753804 2056858052 39879368 99% /raid2 /dev/vdf1 2096753804 2064521676 32215744 99% /raid3 /dev/vdh1 2096753804 2058735184 38002236 99% /raid4 /dev/vdi1 1048311020 73064 1048221572 1% /raid5
いやー、大変だった・・・これにてHDD拡張は完了です。
遺恨の残る拡張作業・・・だったけど、拡張できて良かった。
というわけで、なんだかんだ１週間くらいかかってしまいましたが、ディスク容量の12TB化が完了しました。
久しぶりにパーツ相性を踏んで苦労しました。やっぱりこういうのは無くなりませんね。汎用製品組み合わせの難しいところです。今回、ちょっと感じたのは、こういったパーツ相性的な情報がググっても少なくなってきたなぁというところ。自作PCでサーバーとか、あまり流行ってないのかなぁと感じました。ニーズが無いので、検索スコアも落ちているような。
また、今回の対応って、結局一時しのぎにしかなっていなんですよね。8台まで増えてしまった2TB HDDは故障リスクにしかなっていない。台数を減らして容量を増やすというのが本質的解法なんですが、4TB以上のHDDのバイト単価が落ちきっていない状況は、若干、HDD製品の端境期を感じます。もう1サイズ、容量の大きなHDDが発売されれば、もう1段階、バイト単価が落ちる、という構図が期待されます。
今回の作業でも、やはりLinuxのソフトウエアRAID、LVMの優秀さをまざまざと体感する結果になっています。CentOS 7等、よりエンタープライズ用途にも耐えられうようなディストリビューションも増えていますが、ベースになっているLinuxの基本機能も確実に安定性を増している辺りは、素晴らしいと思います。
以上、疲れた。
コメント