PC」カテゴリーアーカイブ

真面目に48TBファイルサーバを構築してみる(6) サーバ設定編

ここからはどちらかというと余談になります。いろいろと作業をしていくなかであった発見や「なるほど!」と思った現象について少し書いてみたいと思います。

 

ZFSの圧縮の効果がこんなところに

とりあえずすべてデータを転送してみたのですが、気になることが一つ。それはmdadmで確保されたRAID領域(ファイルシステム依存の領域)からZFSにコピーしたのですが、使用容量が8%ほど下がりました。おそらくZFSによる圧縮の効果だと思うのですが、アルゴリズムは速度優先でlz4を指定しているためそれほど圧縮されないはずですし、大抵のファイルが一度圧縮を行っているファイルのはずなので、圧縮はあまりかからないはずだったのですが…。圧縮をかけられるデータやファイル名などのメタデータが圧縮を受けるとどれだけ容量が削減できるかがよくわかりました。速度に問題がなければほかの領域でもかけたくなりますね。

 

QEMUの設定をRedHat系からDebian系に移すのはかなり難しい

こちらは苦労した点。設定ファイルを直接持って行ってどうにかなるのか?というと「基本的にはうまくいかない」が回答のようです。仮想マシンの実行ファイルはRedHat系とDebian系で名前が異なっているため変更が必要、VirtIOがうまく動作せず起動させるとブルースクリーン行きになる、設定ファイルをインポートするとコマンドライン指示の部分(ポート開放処理を記述)は削除される、などがありました。結局一時的に別のUbuntuServer機を用意してそちらにGNOMEとQEMUをインストールして「グラフィカルな環境で設定を行い動作したもの」+「そのときの設定ファイル」を再度コピーする、という手順でなんとかする羽目になりました。VirtIOはドライバのバージョンが古すぎたのかな…とも考えています。

 

mdadmによるソフトウェアRAIDは別PCにストレージだけをつけ直しても検知はされる

これは今回チェックできた中でよかったこと。ちゃんとSuperblockに設定が残っているらしく、OSが入れ替わったとしてもちゃんとmdstatに状態が表示され、mountをかけると普通にファイルが見えました。これでmdadmで構築した場合にインタフェースが故障してもある程度大丈夫ということがわかりました。ただし、mdadmからアレイを削除すると普通に見えなくなりますし、検知された段階で詳細をファイルに保存する(mdadm –detail –scan > /etc/mdadm.conf)ことを忘れるとその後見えなくなったときに二度と構築できなかったりとしますので注意は必要ですね。(元の計画では、HDDとインタフェースカードのみ追加して一時的にHDDを付け替えてコピーする、という算段をしていたが、これがうまくできるのかどうかわからなかったので諦めてPCを一台組んだ、という経緯がある)

 

SELinuxが動いている環境で設定ファイルを/etcにコピーする、というやり方は失敗する可能性がある

再度のFedora環境の移行時に起こった出来事。どうせ同じサービス環境を復元するので移行前の/etcを取り出しておいて移行先で必要なファイルだけ展開してコピーすればいいや、と思って作業をやるとこういう出来事に引っかかるのですよね…。今回引っかかったのはhttpdの秘密鍵と公開鍵の部分。移行前のサーバと同じものを使うためにコピーしてhttpdを起動させるとうまく起動しない。起動しない原因が(日本語に訳すと)「公開鍵ファイルが読み込めないため実行できない」というもの。ファイルのパーミッションは間違いがないのでおかしいな?と思っていたらこのことを思い出して設定を調べてみて判明。特に「/etcに元から存在しないファイルを外からコピーすると/etcのファイルに設定されるべきコンテキストが設定されないため読み込めない」という事態になることが判明。近くにあるファイルのコンテキストをls -dZで確認してchconで設定する、という作業が必要になります。

 

I219V(e1000e)はLinuxと相性が悪い?

どうもそのようです。e1000eに関するいろいろな記事が出ていますが、移行前および移行先のサーバともNICはI219Vを使用しており、移行後のサーバにネットワーク負荷をかけたところかなりの頻度で通信が切断される、という現象が起こったためいろいろと調べてみた結果の結論です。この症状が出るとログに頻繁に「Detected Hardware Unit Hang」が報告されれ、NICのリセットが行われる、というシーケンスが発生します。なお、私の場合はこれが発生しすぎたためかネットワーク経由でサーバにアクセスすることができず強制的に電源断を行わざるを得なくなりました。

原因としてはTSO(TCP Segmentation Offload)が有効になっているとNICへの負荷が高くなって切断される、というもののようで、セグメント分割の処理をCPU側に戻すとよいようです。方法としてはNICをeth0だとすると

# ethtool -K eth0 rx off tx off tso off gso off

のようにして関連する処理をすべてoffにすればOKです。面倒なのがこれを基本的には「起動時に」行う必要がある点。これについてはFedora32やUbuntu 20.04 LTSでは互換性維持のためrc.localによる記述が有効(ただし、Fedora系は/etc/rc.d/rc.local、Debian系は/etc/rc.local)であることを利用して

#!/bin/sh
ethtool -K eth0 rx off tx off tso off gso off

のような感じのrc.localを用意して実行権限を付与すればOKです。

ちなみに、JumboFrameを有効にするとCPUのC-Stateによる省電力が一部使えなくなるようですが、サーバ用途なので気にしなくても大丈夫だと思います。BIOSの設定でC-stateを無効にしても表示されていたのでどうしようもないかも。

ついでに見つかったのが/etc/resolv.confのシンボリックリンクがなぜかstub-resolv.confを指していて、NICリセット時に一時的に127.0.0.53をDNSサーバと勘違いしていた点。修正しましたが、こちらもなぜこんな設定だったのかは不明。

 

とりあえず安定状態に持って行くことができた

今回はファイルのコピーにとんでもない時間がかかってしまったのでサーバの設定時間の方がよほどやることがあって進んでいた印象があるのが今回の移行作業でした。また、今回はUSBメモリによるLinuxインストールを何回も行うことになりrufus(USBメモリに起動可能なデータを設定する)が大活躍しました。まあ、これだけOSを切り替えながらやる計画性のないやり方は今回限りにしたいですね。

 

真面目に48TBファイルサーバを構築してみる(5) サーバ構築編

これまでにPCの組上げやパーツの特性のチェックなどが終わりましたのでやっとサーバの構築に入ることができます。なお、この構築でも本来の予定と異なったことをやっている場面がありますので、そちらも紹介していきたいと思います。

 

サーバのOSは…Ubuntu?

いままでNASサーバは安定性重視でCentOSを使ってきました。サポート期間も長く、今までRedHat系をよく使っていたためなれているという部分もあったためです。そのため、はじめはCentOS8をインストールして設定、と思っていたのですが、インストール時にいくつか問題点が発生していろいろとOSを試しているうちになぜかUbuntu 20.04 LTSになりました。先に原因を書いておくと、今回の場合は

  • CentOS8をインストールするときになぜかNICが正常に応答せず、通信ができなかった
  • インストールパーティションの設定でソフトウェアRAID(mdadm)を設定するときの使い勝手がUbuntuに比べて悪い。RAID1による保護をかけるための設定で、パーティションごとにRAID1を設定されるなど非効率な場面を作ってしまった。
  • ZFSをCentOS系で使うときの手順がかなり複雑である(と聞いている)。dkmsなどの機構が必要になる可能性が高いらしいので安定性が下がるかも。

というものでした。一番はじめのやつが致命傷でした…。

 

FakeRAID(Intel RST)はLinux系OSのインストール時に使用できないと思った方がよい

これもサーバOSを入れるまでに時間がかかった原因です。今回メインHDDはRAID1を組んで障害に耐える構成にする予定でしたので、これをLinux側でやると故障時の対応がややっこしそうだったため、Intel RST側でRAID1を組んで…と思っていたのですが…。RST側でRAIDを組むとLinuxのインストーラがRAIDのHDDを発見できない、という悲劇が発生します。解決するための方法はあるにはあるようなのですが、「インストーラ起動時のオプション設定でdmraidを有効に…」などと書いてあり、やってみても全くうまくいかず、CSMの影響か、とも思いM/BでCSMを設定すると今度はUEFIが見えなくなるという悲劇を数回行い、そのたびにCMOSリセットをせざるを得なくなる羽目に。

改めて書いておきますが、FakeRAIDはLinuxでは相性がかなり悪いので普通にmdadm経由でRAIDを設定するのが正しいようです。そのため、HDDはAHCIで接続させ、Linux側でSoftwareRAIDを設定しましょう。

 

同じ容量のHDDを指定すればインストーラ側がちゃんとRAIDの領域を作ってくれるらしい

心配になっていたのがこの部分。データ領域はRAID1による保護を行うのですが、領域を切り出したときに「それぞれのHDDに同じ容量のパーティションを作成してRAIDを設定する」が果たして守られるのか?ということだったのですが、これは問題はないようです。しかも今回はブート領域にRAIDを設定することができない関係でHDDまるごとRAID1にはできないことを逆用してswap領域をRAID0、データ領域をRAID1で設定するというちょっとだけ速度を向上させる設定にしてみました。swap領域は一時領域なので故障を気にせず速度寄りに、もしHDDが故障した場合はもう片方にバックアップ用のブート領域およびRAID1の保護領域があるので、ブート領域のコピーおよびRAID1の回復作業を行うことで復旧が可能になっています。

 

swap領域があるならswapファイルは無効化してしまおう

Ubuntuの場合はswapファイルが自動的に作成されswap領域が割り当てられます。swap用のパーティションがあるのであればswapファイルは削除するとよいです。swapファイルの停止は以下の手順で行います。面倒なので以下sudoの代わりにroot権限でコマンドを発行しているものとします。

 # swapoff /swap.img
 # rm /swap.img

この後/etc/fstabよりswap.imgのマウント指示を削除して完了になります。

 

Firewallは有効化しておこう

Ubuntuの場合はインストール完了直後はFirewallが入っていないようなので、OpenSSHなどをインストールした後でFirewallを動かしましょう。RedHat系ならばfirewall-cmdを使いますが、Debian系はufwというものらしいです。

 # ufw enable 

 

ファイルサーバなのでSambaは必須

これがないとWindowsからファイル共有ができません。導入してみます。

 # apt install samba
 # ufw allow samba
 # pdbedit -a [user]

pdbeditでログインするユーザのパスワードを設定します。あと、Firewallの許可はサービス名で登録できる場合とポートを直接指定するタイプがあります。今回の場合はサービス名が使えるタイプ。firewall-cmdより簡単ですね。もちろん、 /etc/samba/smb.confの編集をしてsystemctlで再起動が必要です。

 

人によってはtelnetを使いたくなることがあるかも

通常はSSHですが、内部LANに限って簡単にアクセスするのであればtelnetもありかもしれません。Ubuntuの場合telnetはxinetd経由で起動させる方法を使います。つまり、このようにします。内部ネットワークが192.168.0系統ならば…

 # apt install telnetd xinetd
 # vi /etc/xinetd.d/telnet
 # systemctl restart xinetd
 # ufw allow from 192.168.0.0/24 to any port 23

/etc/xinetd.d/telnetはこんな感じ。

service telnet
{
    disable         = no
    flags           = REUSE
    socket_type     = stream
    wait            = no
    user            = root
    server          = /usr/sbin/in.telnetd
    log_on_failure  += USERID
}

ほかのxinetdの設定サイトでもよく見るあれです。しかし、Firewallの設定が非常に楽に見えるのは気のせいでしょうか。

 

今回の本命であるZFSの設定

これが設定できなければ意味がありません。というわけでZFSの設定です。まずはインストールから。

 # apt install zfsutils-linux

これで必要なコマンド類がインストールされます。次はZFSを設定するHDDへのパーティション設定です。通常はHDD全体をZFSに設定するのでpartedからmklabel gptで設定するだけで終わりなのですが、今回はZFS用のパーティションを作成し、そちらをZFSで設定します。

 # parted
 - select /dev/sd[c-j]
 - mklabel gpt
 - mkpart zfs[1-8] zfs 2048s -1s

今回の構成ではメインHDDがsdaとsdbに当たるのでそれ以降のsdcからsdjに対してこれを行います。前回の記事でポート番号がどれになるか確認するのはsdcがどのHDDになるかをしっかりと確認するためになります。Linux上ではこれは認識順(つまりBIOSの順番)となるのでそれほど迷うことはないと思います。ちなみに今回の場合USBメモリからインストールしようとしたためSATAカードとUSBメモリの認識が同時に行われてこの順番に割り込まれることがあったのですが…。

あとはZFSのプールを作成していくつか設定をすれば完了です。作成時にmkpartでラベルを設定しているのでそちらから設定します。

 # zpool create -f tank raidz2 zfs1 zfs2 zfs3 zfs4 zfs5 zfs6 zfs7 zfs8
 # zfs set atime=off tank
 # zfs set compression=lz4 tank
 # zfs set recordsize=1M tank

特にZFSの特性である圧縮機構を有効にするのはやっておくと容量の節約になります。単にonにするだけでもいいですが、必要であれば圧縮アルゴリズムを指定しまってもよいと思います。あとは最終アクセス時刻は基本的に使わないので書き換えをしないようにして無駄な書き込みを防ぎます。

ちなみに、今回RAIDZ(RAID5相当)とRAIDZ2(RAID6相当)を作ってベンチマークを取ってみましたが、こんな感じでした。必要であれば前回の記事の速度と比較してみてください。

RAIDZ 1GBファイル RAIDZ 4GBファイル RAIDZ2 4GBファイル
Seq-Read 4993.22
Seq-Write 2020.38
Rand-Read-512K 5729.92
Rand-Write-512K 737.395
Rand-Read-4K 258.524
Rand-Write-4K 54.959
Rand-Read-4K-QD32 67.978
Rand-Write-4K-QD32 57.255
Seq-Read 309.542
Seq-Write 593.169
Rand-Read-512K 44.064
Rand-Write-512K 585.633
Rand-Read-4K 0.707
Rand-Write-4K 17.824
Rand-Read-4K-QD32 0.729
Rand-Write-4K-QD32 17.046
Seq-Read 366.538
Seq-Write 565.193
Rand-Read-512K 20.784
Rand-Write-512K 368.535
Rand-Read-4K 0.159
Rand-Write-4K 8.108
Rand-Read-4K-QD32 0.224
Rand-Write-4K-QD32 7.591

初期設定だと1GBファイルしか作っていなかったので、どうもZFSのキャッシュ機構に引っかかってとんでもない速さでアクセスした状態になったようです。そのため、キャッシュを無効にするためにファイルサイズを4GBまで上げて再度速度測定をしています。見る限りではさすがにRAIDZ2になるとランダムアクセスが大分遅くなるようです。シーケンシャルアクセスはインタフェースカードの限界の問題もあると思うのでこんなものかな、という感じです。

ちなみに注意点としてはZFSの予備領域などの関係でいままで「48TBファイルサーバ」と書いていましたが、実際に使用可能な容量は「43TB(40TiB)」となり、予定より容量が少なくなってしまうことです。それでも今までの32TB(29TiB)よりは大分拡張されているのでまあいいか、というところでしょうか。

 

さすがに同期作業が大変…

ある程度安定動作ができるようになったのでここから旧NASサーバから新NASサーバへのデータコピーを行います。LAN経由しかないので

 $ rsync -av [旧サーバ]:[コピー元フォルダ名] [コピー先フォルダ名] 

などとしてSSH経由で引っ張り上げる位ですがなにせ32TBのサーバに入っていたデータを引き上げるので時間がかかることかかること…。

ちなみに注意点として圧縮をかけた

 $ rsync -avz [旧サーバ]:[コピー元フォルダ名] [コピー先フォルダ名] 

とする方法もあるのですが、これは「ネットワークが遅い場合」「転送元のサーバスペックが高い場合」に限られます。特にネットワークに十分な速度がある場合(両方がGbEのハブでつながっている状態など)は転送元のrsyncでCPU使用率が100%に張り付いてしまい、十分な速度が出ません。実際に私の環境では-zオプションありで30MB/sほど、-zオプションなしで60MB/s~80MB/sと2倍以上開きがありました。これを知らずにはじめに-zをつけて転送をしていたために大分時間がかかってしまいました…。

 

さて、あと何日かかるかな~

これが終わったら旧NASサーバはHDD部分を解体して新作業用サーバ(Fedora)に変身、現作業用サーバはお役御免でお疲れ様、となります。このあたりの入れ替えもまた大変な作業なのですが、まずはデータコピーが終わらないとどうしようもないですね。がんばります。

 

真面目に48TBファイルサーバを構築してみる(4) SATA3I10-PCIE(SATA10ポート)の実力は?

今回の48TBファイルサーバを構築するときに最重要となるパーツであるSATAインタフェイスカードです。何回も紹介しますが、こちらです。

玄人志向 キワモノシリーズ SATA3 10ポート増設インターフェースボード SATA3I10-PCIE

キワモノシリーズと書いてあるとおり、かなり使い方が難しいパーツだと思います。私も今回のような用途でもない限り使わないようなものですし、使ってみた感想もその設定についてもあまり書かれていないので今回調べてみてわかったことも書いていきたいと思います。

 

SATA3I10-PCIEの簡単な仕様紹介

10PortのSATAカードです。もちろん、キワモノシリーズだけあって取り出し方が特殊で、SATA2PortのASM1062からSATAを取り出し、各ポートをポートマルチプライヤのチップであるJMB575で5Portずつ分割することで10Port確保しています。ネットワークで例えるならルータが外部1Port内部2Portで内部ポートをハブで10Portに分割しているようなものです。そのため、内部の接続方法によっては速度を全く確保できない状態となります。接続はPCI Express x2なので、そのくらいの速度と思ってください。

ちなみに2014年の発売ですが、今でも使えます。8TBのHDDでも扱えるようですので、複数台のHDDを扱うにはかなりよい製品のようです。ほかの製品だと2Portばっかりでマザーボード上のSATA端子数を気にしたりするか、かなり値が張るポート数が多いものを探す必要があったりしますので。

ただし、あまりに新しいマザーボードだとUEFIの関係か、このボードに接続しているHDDなどからOSが起動できない(というか認識の画面が出てこない)になっています。さらに、今回のような用途で使うにはちょっと困った特性があるようで。

 

SATAのポート番号について

この特性から考えると、複数台のHDDを接続する場合はできる限り同じ数のHDDがJMB575の下につながるように構成しなければ速度が大幅に低下することに注意します。そして、RAIDなどを組む場合はどのHDDが何番に当たっているか確実にわかるようにして故障時にどのHDDが交換対象かを素早く判定できなければなりません。今回問題になったのは後者について。

なんとこのカード。ポートがPCの内部的に認識する順番について、その番号がコネクタの配置順になっていない、というなかなか困ったカードなのです。組み立てる前に接続テストをして8TBが扱えるかどうかを調べていたときにわかりました。しかもその説明が説明書(1枚の紙です)に書いてあるような書いてないような、まさにキワモノシリーズらしい物体でした。

説明書に書いてあるのは「BIOS Boot Sequence」という項目で書いてあり、「On BIOS」と「On PCB」で示されている、というでした。どういう意味かというと、

  • On BIOS:BIOS上の認識番号のこと。これがポート番号扱いになる。AとBが入っているが、16進数だと思えばOK。マザーボード上にATA端子がある場合はその端子番号の後から来る。
  • On PCB:基板の実装順番のこと。基板の手前(PCIのブラケットに近い側)の上側(基板から離れている側)が0、下側が1、…のような順番になる。
  • 例えば「On BIOSが4、On PCBが0」ならば、基板の手前上側の端子はBIOS上ではPort4という状態

となります。実装順番とBIOS上の番号がずれており、PC上でのHDDの順番と配線上でのHDDの順番が異なるため、ちゃんとタグをつけて管理する必要が出てきます。さらに言うならBIOS上の認識番号の順番はポートマルチプライヤの状態とは関係がない部分が1箇所あるため、転送試験などをするときに注意がいります。基板の配線を見た上で上記の指示を確認すると「Port0とPort1の2つは基板の実装順番通りではなく、さらにはそれぞれを別のチップが担当している」がそれになります。それ以外であれば私の持っているカードでは順番通りなのですが…

 

転送速度について

一応ファイルサーバを組み立てている途中で一度転送試験をやって速度をチェックしています。調べるとこんな感じでした。なお、ベンチマークについてはLinuxでもCrystalDiskMarkぽいディスクベンチマークしたいを参考にさせていただきました。この場を借りて御礼申し上げます。

単独転送(1台) 異なるポートマルチプライヤチップへのアクセス(同時に1台ずつ) 同じポートマルチプライヤチップへのアクセス(同時に1台ずつ)
Seq-Read 194.216
Seq-Write 186.679
Rand-Read-512K 58.859
Rand-Write-512K 107.249
Rand-Read-4K 0.61
Rand-Write-4K 1.333
Rand-Read-4K-QD32 1.898
Rand-Write-4K-QD32 1.411
(1台目)
Seq-Read 198.068
Seq-Write 191.171
Rand-Read-512K 59.054
Rand-Write-512K 106.098
Rand-Read-4K 0.609
Rand-Write-4K 1.39
Rand-Read-4K-QD32 1.891
Rand-Write-4K-QD32 1.406
 
(2台目)
Seq-Read 194.324
Seq-Write 180.571
Rand-Read-512K 57.667
Rand-Write-512K 105.916
Rand-Read-4K 0.586
Rand-Write-4K 1.279
Rand-Read-4K-QD32 1.829
Rand-Write-4K-QD32 1.314
(1台目)
Seq-Read 116.702
Seq-Write 166.018
Rand-Read-512K 30.742
Rand-Write-512K 97.135
Rand-Read-4K 0.3
Rand-Write-4K 1.235
Rand-Read-4K-QD32 0.607
Rand-Write-4K-QD32 1.261
 
(2台目)
Seq-Read 183.992
Seq-Write 165.782
Rand-Read-512K 30.927
Rand-Write-512K 97.279
Rand-Read-4K 0.302
Rand-Write-4K 1.246
Rand-Read-4K-QD32 0.574
Rand-Write-4K-QD32 1.247

1GBでのベンチマークとなります。なお、「同時に」と書いてあるのは別々のターミナルから入ってベンチマークを実行する、という意味です。

上の表から素の性能では「同じポートマルチプライヤチップへのアクセスを行うと明らかに速度が低下する」という現象が見て取れまるとおもいます。まあ、2台程度では影響は少ないかもしれませんが、台数が増えてくると無視できなくなるでしょう。あと、ここでは「インタフェースについているHDD間での転送試験」はやっていません。今回のNASサーバでそのような動作はほとんどしないので検証対象にはしませんでした。

転送速度に絡む問題としては「PCI Express x2」の転送限界による速度の制限があります。こちらも測定はしていますので紹介。ZFSを使って8台でRAID0を組むという速度の限界に挑戦してみた試験だとこうなりました。

単独転送(1台、再掲) ZFSによるRAID0での転送
Seq-Read 194.216
Seq-Write 186.679
Rand-Read-512K 58.859
Rand-Write-512K 107.249
Rand-Read-4K 0.61
Rand-Write-4K 1.333
Rand-Read-4K-QD32 1.898
Rand-Write-4K-QD32 1.411
Seq-Read 309.542
Seq-Write 593.169
Rand-Read-512K 44.064
Rand-Write-512K 585.633
Rand-Read-4K 0.707
Rand-Write-4K 17.824
Rand-Read-4K-QD32 0.729
Rand-Write-4K-QD32 17.046

なおZFSは転送時にメモリキャッシュを使うように設定されているため、あまりに小さいサイズで転送するとメモリキャッシュの転送速度が見られる、という現象が表れますので注意します。私も結果を見てびっくりしました。そのため、検証では4GBのファイルにて転送試験をやっています。

で、見た感じだとだいたい600MB/sのレベルでの転送が上限で、PCI Express x2 は片方向で500MB/sが限界らしいので、メモリキャッシュなども含めて考えると妥当なラインかな、という感想でした。このあたりは気になってみたからテストをやってみてこういう結果だった、というものですので参考にする程度にしてください。

 

結論、なかなか面白いカード

自作PCレベルで10Portを使う人がどのくらいいるのか気にならなくはないです。私のようにNASを大量のHDDで組み立てる以外に使い道があまりなさそうですし。その用途であれば「設定や使い方を誤らなければ強い味方になってくれそう」というところですね。

 

次回はサーバ構築編

いよいよサーバを構築していきます。いつも安定したサーバのOSはCentOS、テスト用にFedoraを使うのですが、今回はとある理由から別のディストリビューションを使うことになりました。ちょっと使い勝手が違いますが、頑張って設定していきます。

 

真面目に48TBファイルサーバを構築してみる(3) 組み立て編

いよいよ3回目です。今回はPCを組み立ててみたいと思います。この記事ですが、はじめは組み立て動画を撮ってYoutubeにUpした上で「これを見てください」で終わらせようとしたのですが、撮影機材がスマートフォンしかなく、三脚などカメラを固定できる機材もなかったので写真のみです。このあたりの動画を作っている人がそれのためだけにどれだけ初期投資したかがよくわかりました。…転職の状態によってはしばらくYoutuberというのもありかもしれません。

 

買ってきているちょっと特殊なものを紹介

前回の記事で必要なパーツ類を紹介したのですが、その中でも特殊なものを紹介しておきます。まずはNAS用のHDDから。ちゃんと8個購入しています。するとこんな感じになりました。

HDD(x8)

ピラミッド状に置いて上から撮影していますが…。なかなかの迫力です。全部開封するのが大変そうな気もします。

 

あとはSATAや電源ケーブル類。どれだけ買っているか、というと…。

ケーブル類(8袋)

これだけ。8袋もあります。レジ袋が有料化したので印が張ってあるやつがありますが…。ちなみにこのケーブルはすべて使われる上にこれでもSATAケーブルの本数は1本足りていません。そちらは過去に組み立てたNASサーバのケーブルを流用することでどうにかしています。

 

組み立て手順の紹介…?

手順紹介をするつもりではないのですが、組み立て中の写真を連続させるとそう見えるわけですね。

マザーボードにCPUやメモリを装着

ちなみにCPUの切り欠きを合わせる必要はあるのですが、今回は文字がそのまま読める方向でOKだったようです。

バックパネルとスペーサーの取り付け

今回のケースの場合、中央のスペーサーはすでにマザーボードのネジ穴に引っかけるタイプのものがはまっているので、残りの必要な部分にスペーサーを取り付けるだけでOK。ケースにスペーサーを回すための専用の器具がついているのでそれも使うとやりやすいかも。左上の穴がとても固かったです。

電源の取り付け&配線

電源は下置きタイプで、電源ファンが上方向でも下方向でもつけられるタイプのケースです。一応ファンが下方向に向くように取り付けてあります。裏面配線が使えるケースなので電源ケーブルなどはそちらを通すと空気の流れなどもよくなります。最後に結束バンドでまとめて完成。

HDDの取り付け

メインのHDDは5inchベイの変換マウンタで取り付け可能に。NASのHDDは3.5inchベイがスロットタイプなので固定して差し込んでいきます。

HDDが2+8個ですべてのベイを使い切っていますので、取り付けるとかなり壮観な見た目になります。

HDDの配線(SATA&電源)

SATAの配線が大変であることとSATAカードの端子の特性がやっかいだったのでタグをつけて管理していきます。電源ケーブルも分岐ケーブルを大量に使っていますので整えるのが大変でした。

 

組み立て作業も一苦労

この作業で3時間~4時間ほどかかりました。黙々と8個のHDDについて開封とネジ固定作業をやっていると「私はなぜこんな作業をしているのだろうか…?」と疑問に襲われる状態でした。HDDの数や作業のためにこれだけ時間がかかるのであって、一般的な自作PCでこれほど時間がかかるわけではありませんのであしからず。

 

次回はSATAカードの特性についてちょっと紹介

先に今回使ったインタフェースカードのSATA3I10-PCIEについて特性を紹介しておきたいと思います。組み立てる前に別のPCでポートの特性を見てみたり、組み立て後に転送速度に関する試験などを行っています。これだけで記事が作れるほど変わった特性をしていますので先に紹介をしておきたいと思います。それが終わればサーバ構築編を書きたいと思います。

 

真面目に48TBファイルサーバを構築してみる(2) 購入編

前回は構想編ということで、どんなパーツをそろえればよいか?を考えてみました。で、組み立てるために実際に買いそろえてみました。

CPU、マザーボード、メモリ

CPUはやっぱりこれ。

INTEL CPU BX8070110100 Core i3-10100 LGA 1200 6MB 3.60GHz 【BOX】 日本正規流通品

2020年7月現在で最新のCore i3の一番スペックが低いものになります。これでも数世代前のCore i7並の性能というのがびっくりなくらいですね。どうせRAIDよりSATAのインタフェースカード側で性能が頭打ちになるのでそれほど気にする必要はないですが、ZFSのRAIDZ系統やmdadmでのRAID6などSoftwareRAIDはCPUを使って演算を行うため、ある程度の速度がないとRAIDのパリティ計算でもたつくことになり転送速度を落としてしまう可能性が大きいです。時間があればチェックをしてみたいとは思いますが…。

メモリは適当なブランドで16GB(8GBx2)にしました。NAS用途ですが、それ以外で使うことがあまりないため、メモリスペックを要求することが少ないような気がします。しかも使っているHDDはNAS用ではないため、常時起動はしたくないですし。

マザーボードはこれになりました。

ASRock Intel 第10世代CPU(LGA1200)対応 B460チップセット搭載 Micro ATXマザーボード 【国内正規代理店品】 B460M Pro4

結局は金額の差ですね。H470は金額が高いので安くあげることが重要で、サーバ用途なのでB460系列が使いやすい、という判断でこうなりました。実はこれを使おうとしたときにあるとんでもない苦労を強いられる羽目になったのですが…。それは初期設定編にて書くことにします。

 

ストレージ部分は結局こうなった

特にメイン部分が大分変わりました。結局NAS用のものではなくて…

Western Digital HDD 4TB WD Blue PC 3.5インチ 内蔵HDD WD40EZRZ-RT2 【国内正規代理店品】

WesternDigital製のデスクトップ用を2つ使うことにしました。NAS用にしなかったのは前の記事にも書いたとおり値段差がひどすぎたからとRAIDで保護するのでこれでも信頼性はある程度保たれるだろう、という判断です。問題はなぜWesternDigitalのWD Blueを選んだか?という問題。これにはちゃんと理由があります。

理由はHDDの磁気記録方式の問題。このモデル(特にEZRZ系統)はCMRという方式なのですが、SeagateのBarraCuda系統はSMRという方式で記録容量を稼いでいます。SMRは記録容量を稼ぐには良い方式なのですが、OSの起動など細かいファイルを大量に読み書きする場合に速度が大幅に低下する傾向があります。一応キャッシュメモリなどで防いではいるのですが…。そのため、できればOSの領域はCMRのHDDを使いたい、ということで「4TBかつCMR」という条件に該当したのがこれになります。なお、NAS用だからCMRというわけでもなく、しかもWD Blueは型番によりCMRとSMRが混在している(EZAZはSMR方式)上にWD RedでもSMRが入っているので選択はかなり気を付けないといけません。

 

一応再度貼り付けておくと、NASストレージ部分とインタフェースはこれ。

Seagate BarraCuda 3.5″ 8TB 内蔵ハードディスク HDD 2年保証 6Gb/s 256MB 5400rpm 正規代理店品 ST8000DM004

玄人志向 キワモノシリーズ SATA3 10ポート増設インターフェースボード SATA3I10-PCIE

ちなみにBarraCuda系統なのでSMR形式ですが、今回のNASは容量を稼ぐのが目的で、「ファイルサイズが大きい(数百MBレベル以上)上に書き込みをほとんどしない」というのが条件なのでこれでよかったりします。以前のNASサーバもSMR形式のHDDですので私の用途としては問題なし。

 

電源とケースは?

玄人志向 電源 KRPW-BKシリーズ 80PLUS Bronze 650W ATX電源 KRPW-BK650W/85+

650W電源を選んでいますが、これより多少下がっても問題はないと思います。問題なのはSATA電源の本数。これが少ないと分岐ケーブルが大量に必要になってきますし、電源コネクタの間隔によってはうまく配線できないことがあると思います。

Fractal Design Define R5 Black Pearl PCケース CS4987 FD-CA-DEF-R5-BK

Note804が初期の予定だったのですが、いろいろと考えた結果こうなりました。NAS用のHDDはすべて3.5inchベイに格納して、OS用のHDDはマウンタを使い5inchベイの部分に配置することでカバーします。

 

合計金額は…

なんとか税込みで20万円を下回りました。NAS用のHDDを一つも使わなかったことが大きいです。あとは特価品をタイミングよく手に入れることができたので、その部分でうまく節約できたようです。ちなみにSATAのケーブルや電源の分岐ケーブルも含まれての値段ですので、実際にこの構成で組み立てたい人がいる場合はちゃんと分岐ケーブルやSATAのケーブルを必要な本数(SATAケーブルは8本、電源分岐ケーブルは三叉x2+二叉x1が目安)を買っておく必要がありますので気をつけましょう。

 

次回は組み立て編

といってもYoutubeなどを探せば組み立て動画くらいはあると思いますので今回はこのケース&HDDがいっぱいあるパターンの取り回しを少し見せるだけになると思います。