しま★りん.blog @ayurina

そこはかとない日常を綴るブログ

自宅サーバーHDD増設、12TBへ。パーツ相性で久しぶりに苦労した話。

time 2014/09/28

ディスクが足りない、って状況はしばらく前から発生していたんですが、どうやって解決するか、かれこれ数ヶ月悩んで、結局、SATA IFボード(SATA3RI4-PCIE)&HDD(WD20EZRX)追加導入となりました。やっと動き出したんですが、今回はなんだか大変だった。という、お話。

sponsored link

我が家のサーバー環境

まずは起きていたこと。地デジサーバーのHDDが壊れて、もういやになって3TB×2のRAID構成で信頼性と容量を確保したのが、先月の話。そもそもなんでこんな事態を招いたかといえば、原因は母艦となっているファイルサーバーの容量不足です。

我が家の母艦サーバーは仮想化環境で、システムボリュームSSDで64GB、データ領域として、2TB HDD×7×RAID6で10TBの容量になっています。このデータ領域のうちの2TBは汎用エリア(TimeCapsuleとか、仮想マシンのシステムボリュームとか、いろいろ検証データとか)で使っており、残りの8TB、実質的には2TB×4で運用しているのが、地デジバックアップ領域です。この地デジバックアップ領域がいっぱいなのが、根本的な原因です。

そこで、HDDの増設を検討したのですが、SATAポートが無い。M/BのSATAポートは6本。これに拡張ボードのSATAポート2本で、8本しかないので、単純にHDDを追加するという対応は無理でした。

どうやってHDDを増やすか。

HDDを増やす方法にはいくつかあります。

案1。マシンそのものを作り直す。そもそも現状、SSD/HDD×8台という環境は耐障害性という意味でもあまりよい状態ではないです(パーツ数が増えれば故障点が増えます)。大容量のHDDに買い換える。ついでにM/BやCPUも替える、というのが、ベストだとは思ったのですが、いかんせんこれにはお金がかかる。

案2。HDDだけでも買い直す。HDDを4TB等の大きな容量のものに置換するという案があったのですが、これはそうそうに却下されました。過去、HDDの増設に合わせて、RAID構成を変更して、内部でデータを移行して・・・というマイグレーションを実施した経験はあるのですが、今回はSATAの空きがそもそも無いこと、2TB×7でRAID/LVが組まれており、この容量を減らしていくというオペレーションが結構危険であること、など、正直現実的ではないということで、この案は却下です。

案3。M/B、CPUを買い直す。ここから現実案です。SATAポートを増やす方法その1です。既に使っているCPU、M/Bが結構古いので、この機会に買い換えよう、という案です。それに合わせて、M/BにSATAポートが大量に付いているものを選べないか、と。比較的現実的な案だったのですが、このSATAポートを大量に持っているM/Bというのが、なかなかに高い。また、M/Bによって、eSATAと共用で、結局使えるポートがいくつになるのか、良く分からないものもあり、ちょっと踏ん切りが付かない感じでした。最後の最後まで悩みましたが、M/B置換には至らず。

案4。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とは物理的に互換性が無いため、ちょっと盲点でしたら、これを使って拡張することにしました。

結論。案4。まだケースには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。

th_2014-09-23 14.52.44

WD20EZRXは専用パッケージということで、ダンボールによる簡易包装になっています。ユピテルの専用モデルと同じような感じですが、こちらは単に包装だけで、中身は普通のバルクHDDです。

th_2014-09-23 14.55.32

ついでにケーブルも買っておきました。意外にあとで実は足りなかった、って、あるんで・・・

th_2014-09-23 14.55.45

早速取り付けます。取り付け前のサーバーの状態。

th_2014-09-23 15.15.30

拡張ポートはPCIE x16 ×1が中央青色で空いている分、その下2個がPCIe x1の2個、一番下に普通のPCIもありますが、ここにはメーカーは忘れましたが、tulipのFastEthernetカードが挿してあります。仮想OSの主IFはこっちにしてあって、GbEの2本は仮想環境にすべて当てています(ま、結構真面目にプライベートクラウドにしているつもりです)。

ボードを挿すとこんな感じになります。4ポートのIFがすべて横に出てくるため、保守性は良さそうです。ちなみに、冷静に考えると、4×SATA 6Gbって、PCIe x2では帯域足りないんじゃない?と気づいたんですが・・・

th_2014-09-23 15.35.45

HDDも加えた全体図はこちらです。

th_2014-09-24 00.44.47

ちなみに、最終的にはこの写真の構成にはなっていません。拡張ボードのポート接続構成をいろいろ変更しています。理由は、後述。

ここまで組んだ時点で、動作確認をします。とにかくHDDが見えなければ初期不良もあるわけで、さて、ここから、長い戦いが始まりました・・・

SATA3RI4-PCIE(88SE9230)はLinuxでは不安定?拡張ボードとの戦い

そういえばSATA3RI4-PCIEというかMarvel 88SE9230について、嫌なレビューがAmazonのページにありましたっけ。事象としては、

  • 高負荷状態でSMARTコマンドを投げるとHDDとの接続が切れる
  • Linuxで発生する。

まぁ投稿時期が2013年なので、最近のカーネルでは対処してるかなーという、甘い考えがあったのですが、結論からいうと、CentOS 6で、この事象、発現しました。

まず、1日目。上の写真を撮った時点です。

拡張ボード2枚には、HDDが2台とシステムボリューム用SSDが繋がっています。まずは何も考えず、今回拡張したHDDを今回追加した拡張ボードに繋いで起動しました。いきなりですが、拡張したHDDがOSから見えない(dmesg、/proc/partitionsに出てこない)事案発生。

電源OFF、ONを繰り返したりすると、なんとHDDが見えたり、見えなかったりする始末。これもしかして、拡張ボードの問題?とか、Marvelチップの拡張ボード2枚使ってるのが悪い?とか、いろいろ悩んで調べてみました。

この時の原因:HDD側のSATAケーブルのルーズコネクト。いや、あり得ないと思いつつ、実は結構コネクタが深くて、爪がかかってなかったという。よーく押し込んで、爪がカチッとはまる状態にしたら、HDD認識問題は解決しました。教訓:やっぱり物理接続の確認は基本です・・・。

2日目。HDDが見えるようになったのは良いんですが、拡張ボード側の2台のHDDが、見えたり、見えなかったりする。今度はソフトウエア問題だよなぁ、と思いつつ、まずは2枚のMarverlボードが嫌われている可能性があったため、SATA3RI4-PCIEの4ポートに、SSDとHDD×2、すべてのデバイスを繋げる構成にしました。こうすることで、BIOSのprobeも1回になり、全デバイスが安定的に見えるようになりました。

この状態で、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×2を、旧来のSATA拡張ボードに移し、SATA3RI4-PCIE側に負荷がかかるのを避ける。SATA3RI4-PCIE側にはシステムボリュームのSSDのみを残す。

この構成にして、再度ボリュームを組み直し、今度はRAIDの再構成のみを実施(既にreshapeは完了しているため)。実質、HDD2台のリカバリ処理が走り、今度は無事、完了しました。SATA3RI4-PCIE側の残りの3ポートが使えるかどうかは、とりあえずあとで考えるとして(苦笑)、まずは増設優先。何度か再起動したりして安定を見ていますが、この構成でなんとか動いています。

さて。嵐の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からの追加を行いました。

スクリーンショット 2014-09-27 15.56.39

スクリーンショット 2014-09-27 15.57.09

こんな感じで追加すると、仮想ドライブについては、仮想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は減らします。1ファイル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拡張は完了です。

遺恨の残る拡張作業・・・だったけど、拡張できて良かった。

というわけで、なんだかんだ1週間くらいかかってしまいましたが、ディスク容量の12TB化が完了しました。

久しぶりにパーツ相性を踏んで苦労しました。やっぱりこういうのは無くなりませんね。汎用製品組み合わせの難しいところです。今回、ちょっと感じたのは、こういったパーツ相性的な情報がググっても少なくなってきたなぁというところ。自作PCでサーバーとか、あまり流行ってないのかなぁと感じました。ニーズが無いので、検索スコアも落ちているような。

また、今回の対応って、結局一時しのぎにしかなっていなんですよね。8台まで増えてしまった2TB HDDは故障リスクにしかなっていない。台数を減らして容量を増やすというのが本質的解法なんですが、4TB以上のHDDのバイト単価が落ちきっていない状況は、若干、HDD製品の端境期を感じます。もう1サイズ、容量の大きなHDDが発売されれば、もう1段階、バイト単価が落ちる、という構図が期待されます。

今回の作業でも、やはりLinuxのソフトウエアRAID、LVMの優秀さをまざまざと体感する結果になっています。CentOS 7等、よりエンタープライズ用途にも耐えられうようなディストリビューションも増えていますが、ベースになっているLinuxの基本機能も確実に安定性を増している辺りは、素晴らしいと思います。

以上、疲れた。

sponsored link

down

コメントする






sponsored link

アーカイブ