これまでに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)に変身、現作業用サーバはお役御免でお疲れ様、となります。このあたりの入れ替えもまた大変な作業なのですが、まずはデータコピーが終わらないとどうしようもないですね。がんばります。