製品に本来搭載されていたマザーボード（下部の「以前の内容」に記載）が故障したため、PCケース以外の中身の入れ替えを行っております。

マザーボード

・ASRock D1521D4I サーバー／ワークステーション用

CPU内蔵 Intel Xeon D1521(4コア8スレッド 2.4 GHz)

メモリ

・PC4-17000P(DDR4-2133P) ECC Registered 16GBx4枚

Samsung M393A2G40DB0-CPB0Q

ストレージ

・SATA SSD 128 GB（OS用）

Transcend TS128GSSD452K2

・SATA SSD 120GB（バックアップOS用）※１

Intel SSD 510 

・SATA SSD 120GB（OSバックアップ 一時データ用）※１

Transcend TS120GSSD220S

※１　現在は２台だが１台にまとめる予定。余ってるSSDを使っているので2台になっている。

・Team M.2 2280 NVMe SSD 2TB PCIe Gen3x4 MP33シリーズ（データディスク）

速度はまずまず。低発熱との評判があるため単体で導入。

RAIDは使用しないが、週１回のバックアップで別のNASへ全量データを退避を実施することで、最悪の危機は免れるであろうという方針。

・HDDx2(RAID1) 2TB + SSD Cache の追加

mdadmでRAID1を構築、LVMに登録。LVMにSSD Cacheを追加。

電源

・600W 80 PLUS Gold

Cooler Master G600 GOLD ‎MPW-6001-ACAAG-JP

マザーボード変更したことにより、

・SATA2.0　→　SATA3.0へ。

・SATA 4ポート　→　6ポートへ。

・メモリ DDR3 16GB　→　DDR4 64GBへ。

CPUの熱がそれなりに発生するので、8cmファンを1つ追加。

HDDを取り外したため、電源は過剰スペックかもしれない。

普通に小型のサーバー向けPCなので、自作NASとして運用していきます。

以降は個人的な備忘録のようなものです。

選定OS：Fedora 39

使い慣れたRedHat系OSの最新にしました。

CentOS 8だとビルド＋インストールが出来なかったため、仕方なくFedoraへ。

半年くらいでバージョンが上がって、数年でサポート切れる（更新が無くなる）ので、定期的にバージョンアップが必要なことがデメリット。

頻繁にバージョンアップするせいか、Node.jsの更新が追い付かないというか、Node.jsの更新頻度が遅い。

カーネルバージョンがどんどん上がるので、ハードウェアのドライバがまだリリースされていなかったり、打ち切られてドライバが使えなくなるケースも発生する。

カーネルバージョンのマイナーアップデートくらいは問題ないが、メジャーアップデートの際はOSバージョンアップを控えた方がよさそうだ。

バリバリUI操作を使うなら Ubuntu 系統に切り替えてもいいのだけれど、現状はその予定はない。

ストレージ構成：

HDDの運用をやめてSSDのNASに切り替えることにした。

今まではソフトウェアRAIDだったが、解除して運用したところ各段にレスポンスが良くなったように感じた。

HDD3台を取り除いたおかげで発熱量も減るし商品電力も多少落ちたと思わえる。24時間稼働だしね。地味に大きいでしょう。

起動用：SATA SSD x 1（120GBくらい）

起動用SSDのデータをバックアップするための別OS：SATA SSD x 1（120GBくらい）※そのうち SSD を 1TB ～ 2TB に変更して、少し容量拡張を考えている。

データ保管用ストレージ：SSD x 1 (2TB)

データは、よく使用するものだけを置いている。

使用頻度が低いファイルはSubNASの方に置いているが、上記稼働はさせない。

主に、こちらのメインNASの全体バックアップのため週１回程度起動させて全体バックアップの差分バックアップを実行している。

ネットワーク構成：

LANポートが2系統あるので使用用途で通信を分ける。

・インターネットに通じる外向け（1GbE）

・データ通信用の内向け（2.5GbE）

◆NAS（OS：Fedora 39）

ソフトウェア構成(VNCユーザー１：root)：

　動画エンコード　FFmpeg（x264、x265）

　ファイル共有ソフト　NFS

　ファイル共有ソフト　Samba

　仮想環境サーバー　KVM ( Kernel-based Virtual Machine ) + QEMU

　Kodi（DLNA/UPnP配信サーバーソフト）負荷が高いし、普段使わないから常駐を停止

　VNC（Xリモート操作）

　Clam AntiVirus （アンチウイルスソフト）

　Resilio Sync（別端末間のファイル同期）

イメージ図

ソフトウェア構成(VNCユーザー２：一般ユーザー)：

　Minecraftサーバー最近やらなくなったので停止中

　Google Chrome

　Selenium(ブラウザー自動化)

イメージ図

◆KVM仮想環境１(ゲストOS：Fedora 39)

ソフトウェア構成：

　NAS領域のsambaマウント

　広告アド除外用DNS（ dnsmasq ）ネットワーク変更により見直しが必要だが未着手のため非稼働

　メールサーバー( imaps(SSL/TLS), smtps(SSL/TLS) )

　Webサーバー( apache (https) ) # 保存領域はNAS上

　DBサーバー( MariaDB ) # OracleCloud上に移動して負荷を軽減出来たが、ネットワークトラフィックが少し増えた

　Clam AntiVirus （アンチウイルスソフト）

　OracleCloudに接続するための、OpenVPNクライアント

 構築が面倒なものは仮想環境を使用して運用する感じ。

NASのデータバックアップについて

ここでいうバックアップとはスナップショットではなくフルバックアップのことです。

自作NASにおいて、下記のバックアップを想定しておく必要があります。

・システムのバックアップ

・保持データのバックアップ

システムのバックアップは別OSを別のディスクで起動させて、NASの主OSのあるディスクをフルバックアップします。

保持データのバックアップはディスク容量の空きががあれば、フルバックアップの複数世代を保持します。

どちらのバックアップも最終的に別のNASか外部記憶媒体に保持するのがよいです。

うちの環境では最終的に別のNASに保持し、同時に下記の外部記憶媒体へ保存しています。

別のNAS

外部記憶媒体の装置

外部記憶媒体

外部記憶媒体はBD-Rでもよいですが、保存データ容量が大きくなればなるほど焼く枚数が増えるので、焼く作業もリストアする作業もどちらも大変になってきます。

装置がお高いですが、LTOドライブはとてもおすすめです。

長期間保存であれば、企業でもやっているテープ媒体が安心だと思えます。

★2020/08/17追記

外出先からのNASデータへのアクセスについて

基本的にNASで管理しているデータ全てインターネットへの公開はしない。

ルーター機能のVPN(L2TP/IPSec)の接続にて内部ネットワークにアクセスしてからNASへアクセスする。

例外として、どうしても外出先からアクセスした場合、下記を経由してアクセスさせることにする。

これは指定したフォルダ配下のファイルのみを公開するもの。

クラウド系ドライブ（oneDrive、Dropbox等）に近い感じ。

スマートフォンアプリの場合、全てのファイルを同期するわけではなく、指定したファイルのみ取得が可能となっている。

WindowsやMacで指定したファイルのみを取得したい場合、有償ライセンスが必要になる。

それを使用するくらいならVPN接続してアクセスした方が断然よい。

★2022/06/16追記

マザーボードが故障したため、システムの復旧を行った。

【ハードウェア変更】

・マザーボード変更

・メモリ変更　DDR3 16GB　→　DDR4 32GB

・システムOSで使用しているSSD変更　Intel　→　Transcend

・電源変更　250W　→　600W

【復旧について】

システムOSが入っていた Intel SSD(120GB) の内容を別のPCでバックアップ。

Linux の dd を使用して SSD 内容をイメージファイルへ出力。

上記で出力したものを dd で Transcend SSD(128GB) へクローンを作成した。

8GBほど空きが増えることになるが、今後も同様にクローンを作ることもあるのでこのままとする。

LVM+RAID5についてはソフトウェア(OS)による実装であるため、ハードウェア変更されても動作すると踏んでいたので、とくに焦りはしなかった。

気をつけたのはマザーボードのBIOSでHDDを認識させる順番。

この順番が異なると sdb と認識されていたものが sdc や sdd などになったりする。

マザーボード変更後にOS起動させたが、特にストレージに関わる問題はなく認識した。

RAIDの欠損も特にないようだった。

マザーボード変更によりネットワークデバイス名が変更となったようだった。

ブリッジ動作で設定していたが、デバイス名が変更になり対象から外れてしまったみたい。

その影響でKVM内の仮想マシンのネットワークがうまく動作しなかった。

ブリッジネットワークに変更になったデバイス名を入れてあげることで正常に動作するようになった。

ネットワーク設定にかかわるところは設定中に接続が切れてしまうため、BMCによる遠隔操作は非常に便利だった。

しかし、BMCが古いため、IE＋Java8の環境でないと動作しなかった。

特にEdgeでのIEモードを使用しないと動作しない。

少なくとも Windows PC が必須で、これは少し不便かなと感じた。

CPUスレッド数が 4 から 8 に増えたが、クロック数が 3.3 GHz → 2.4 GHz に落ちた。

OSとしての負荷率(load average)は下がったような感覚はあるが、単一の処理速度は落ちた感じはある。

負荷率が下がったおかげか、Teratermによる接続時の応答速度が向上したように感じる。

★2023/08/02追記

・2022/12頃にHDD NASから SSD NASへ切り替えた。

・2023/02頃に 2.5GbpsLAN を追加した。

・2023/02頃に Fedora 35 から 39 へアップグレードした。

本当は38までやる予定が手違いで開発中の39へアップグレードしてしまった。

そのせいで dnf パッケージが38と39と混ざる感じで依存関係がかなり壊れた。

結局dnfパッケージ全般を削除。rpmから39版のdnfを入れなおすことでなんとか解決した。

gnomeを使っていたが依存したものはすべて削除された。VNC環境で動作していたGUIはなぜかMate Desktopになっていた。Gnomeパッケージを入れなおしたら治った。

・HDDx2(RAID1) 2TB + SSD Cache の追加

・Kernelパラメータを変更

日記の通り。

キャッシュにヒットすればRAID1のHDDでもこのくらいは出る。

2.5 Gbps NICの最大帯域くらいかな。

実際にはキャッシュにヒットしないことが多いので 100MB/s くらいの標準HDD並みの速度がデフォルトかも。

履歴：

・2023/08/02追記

2022/12頃にHDD NASから SSD NASへ切り替え

2023/02頃に 2.5GbpsLAN を追加した

2023/02頃に Fedora 35 から 39 へアップグレード

HDDx2(RAID1) 2TB + SSD Cache の追加

Kernelパラメータを変更

・2023/02/14改定

現在の構成情報の反映。

以前の古い構成情報レビューを「以前の内容」項目に移動。

履歴を見やすくするために最新の変更点を下部から上部になるようソートした。

・2022/08/08追記

メモリ２枚３２ＧＢ増強。６４ＧＢになった。

・2022/06/16追記

ハードウェア構成を変更

過去文章の取り消し文を削除

ハードウェア変更に伴いシステム復旧

・2021/12/29追記

Fedora 33 から 35 へアップグレード。

・2021/05/26追記

Fedora 32 から 33 へアップグレード。

VMware Workstation から KVM＋QEMU へ変更。

・2020/08/22追記

NASのシステムバックアップについて追記

・2020/08/17追記

外出先からのNASデータへのアクセスについて追記

・2020/08/09追記

今更ながらCrystalDiskMarkのベンチマーク結果を登録

メモリ、ネットワークの現状状態を修正

VNCイメージ図を追加

NASのデータバックアップについて追加

・2020/05/26追記

仮想環境をVMwareからKVM+QEMUへ変更のため、ソフトウェア構成を変更

・2020/01/04追記

ディスク構築時のイメージを追加。

ディスクリカバリーの操作を追加。

・2020/12/26追記

現状の状態にあわせて修正。

・2020/05/03追記

HDD交換コマンドの確認で、実際にディスク交換してみた。

データ同期するのに1TBあたり2～3時間かかるようだ。

・2020/05/01追記

データ保管用ストレージ用キャッシュの SSD(USB 3.0)が熱暴走によりデバイス消失しました。

結果、LVMのボリュームがオフライン状態に。

USBを外してから少々冷やして再度接続したら再認識したけど、リカバリーに6時間費やす。

別のSSDに交換してみたけどUSB接続だと同じ事象が発生。

不具合が発生すると復旧が面倒なのでキャッシュストレージは外すことにした。

◆ハードウェア

以下、旧構成（製品本来搭載していたもの）

マザーボード

・ASUS P9D-I サーバー／ワークステーション用

基本スペック

CPU:Socket LGA1150

→Xeon E3-1226 v3 3.3Ghzを装備

メモリ：ECC DDR3 1600/1333 UDIMM Max16GB(8GBx2)

→ECC DDR3 1600 16GB(8GBx2)を装備

拡張スロット：PCI-E x16 (Gen3 X16 Link)

→Low-ProfileのPCI-Eを1スロット分装着可能

フォームファクター：Mini-ITX

ストレージ：SATA3 6Gb/s x 2 ポート、SATA2 3Gb/s x 2 ポート

→SSDを使用する場合、SATA2 ポートに注意

ネットワーク：Intel® I210AT x 2 ポート

グラフィック：Aspeed AST2300 with 32MB VRAM

電源

２５０W電源です。

それなりの負荷や熱が発生しても、ファンの風切り音が静かです。

逆に熱が籠もった場合、危険かも知れない。

夏場は注意です。

◆設計

普通に小型のサーバー向けPCなので、自作NASとして運用していきます。

以降は個人的な備忘録のようなものです。

選定OS：Fedora 32（現在はアップグレードして35になっています）

使い慣れたRedHat系OSの最新にしました。

CentOS 8だとビルド＋インストールが出来なかったため、仕方なくFedoraへ。

半年くらいでバージョンが上がって、数年でサポート切れる（更新が無くなる）ので、定期的にバージョンアップが必要なことがデメリット。

ストレージ構成：

起動用：SSD x 1（120GBくらい）

データ保管用ストレージ：HDD x 3

データ保管用は1TB毎にパーティション作ってRAID 5を構築。

数個出来たボリュームをLVMで纏めてXFSフォーマットする。

ディスク交換時の作業が少々面倒だけど、1TB毎に区切っているので容量が異なるHDDを入れても問題なく使用出来る。

２，４，６TBのように３台のHDDがあった場合、最低容量の2TBでRAID5構築になるので約4TB使用出来ることになる。

ディスク障害が起きたときに限って、同じ型番のHDDが廃盤になっていたり、予算1万円くらいって決まっていると容量あたりの単価が安いディスクを買いたくなってしまう。

そんなことを考慮して1TB毎に区切ってみる。

HDDは8TBを3台使用して、最終イメージはこんな感じ。

1TB毎に区切ったらHDD3個分でRAID 5のアレイを順番に構築していく。

全部で8個のアレイが出来るので、それをLVMプールに突っ込む。

そしてLVMの論理ボリュームは2つ。

・仮想環境用領域

・データ保管庫領域

ネットワーク構成：

LANポートが2つあるので使用用途で通信を分ける。

・インターネットに通じる外向け

・データ通信用の内向け

NAS（OS：Fedora 35）

ソフトウェア構成(VNCユーザー１：root)：

　FFmpeg（x264、x265）

　NFS

　Samba

　KVM ( Kernel-based Virtual Machine ) + QEMU

　Kodi（DLNA/UPnP配信サーバーソフト）

　VNC（Xリモート操作）

　Clam AntiVirus （アンチウイルスソフト）

　Resilio Sync（別端末間のファイル同期）

イメージ図

ソフトウェア構成(VNCユーザー２：xxx)：

　Minecraftサーバー

　Google Chrome

　Selenium(ブラウザー自動化)

イメージ図

KVM仮想環境１(ゲストOS：Fedora 35)

ソフトウェア構成：

　NAS領域のsambaマウント

　広告アド除外用DNS（ dnsmasq ）

　メールサーバー( imaps(SSL/TLS), smtps(SSL/TLS) )

　Webサーバー( apache (https) ) # 保存領域はNAS上

　DBサーバー( MariaDB ) # 保存領域はNAS上

　Clam AntiVirus （アンチウイルスソフト）

構築が面倒なものは仮想環境を使用して運用する感じ。

ディスクリカバリーの操作を考える。（自分用メモ）

下記図のようにHDD1が故障したとする。

するとRAIDアレイは一斉に警告を出す状態となる。

この状態でメールなどで障害通知を行う必要はある。

障害通知をを受けて取り急ぎHDDを購入にはしる。

それなりの稼働時間を経過しているのであれば、同ロットの場合は他のHDDも故障する可能性はあるので３台分は用意すべき。

ひとまず今回は8TBから10TBのHDDへ交換する想定をしてみる。

コマンドからmdadmを操作して故障したHDD1を取り除いてからNASをシャットダウン、故障したHDDのシリアル番号を確認してから新品のHDDに切り替える。

NASを起動させて交換したHDDを1TB毎に区切る。

アレイ一つずつに対して交換したHDDを順番に割り当てていく。

RAID 5のデータ同期が自動で順番に始まっていき、復旧は終わる。

HDD１の復旧が完了したらHDD２を外すコマンドをmdadmから行いシャットダウン、HDD交換・・・と同じ手順を行いHDD3も行う。（恐らく１〜３日作業）

最終的にデータ同期が出来たタイミングで1TBが2つ分の未使用領域が出来るので、アレイ９とアレイ１０を作成しLVMプールへ突っ込む。

最後にLVM上の論理ボリュームのファイルシステム（xfs）の拡張操作を行って作業は完了。

若干誤差はあるものの、ランダムリードが顕著に影響が出ている。

結局は②の状態で常時稼働しているので、それが日常で使用しているスコアと捉えてよいと思う。

★2020/08/22追記

NASのシステムバックアップについて

市販品の NAS はファームウェアとしてシステムデータがアップデートされていたりするので、通常はバックアップの必要がない。

SSH などを使用して個別でコンソールへログインしてカスタマイズしている場合は必要かもしれないが・・・。

この自作 NAS は通常の PC の OS と変わらないのでシステム（ OS ）のバックアップが必須です。

可能であればスナップショットではなくフルバックアップを行い、外部記憶媒体（外付けHDD/SSD、DVD-R、BD-R、LTOテープ等）に保管する運用を定期的に行った方がよいです。

そもそものお話で、スナップショットとフルバックアップの違いがわからなければ事前に知識として入れておいた方がよい。

この知識がない状態での自作NAS運用は危なすぎる。（私は何度もデータを吹っ飛ばしている過去経験から。）

ざっくり運用としては、スナップショットは自身のNAS上で保管、フルバックアップは外部記憶媒体に保管。そんな感じでよいかと。

概念的な話はこんなところで切り上げます。

結論として、このNASでのシステムバックアップは主OSとバックアップ用OSを用意して、バックアップOS上で主OSをバックアップするという方式を取ることにしました。

単純にSSDを２つ用意して、それぞれのSSDにOSを入れ込んで、バックアップの時にOSを切り替えているだけです。

主OSは Fedora で ブートローダに Grub2 を利用しています。

下記コマンドでバックアップOSを追加して・・・

# vi /etc/grub.d/40_custom
menuentry "Ubuntu 20.04" {
set root='(hd4,1)'
chainloader +1
}

下記のコマンドを実行するとバックアップOSがブート時の起動リストに追加されます。

# grub2-mkconfig -o /boot/grub2/grub.cfg

この環境では主OSの起動リストに３つ表示されるため、バックアップ用OSは４つ目に表示されるようです。

なので、OS切り替え用コマンドは下記のようになります。

# grub2-reboot 4

# systemctl reboot

これで Grub2 が起動した際にデフォルトで４つ目が設定された状態で起動できます。

これは１回だけ４つ目に設定されるだけで、以降はデフォルト値に戻り主OSが選択された状態になります。

バックアップ用OSでのフルバックアップは、単純に dd コマンドを使用して gz 圧縮しているだけです。特に専用ソフトなどは使用しません。

/etc/rc.local に下記コマンドを記載しているだけ。

sudo rm -f /share-area/fedora-system-all_backup.img.gz
sudo dd if=/dev/disk/by-path/pci-0000:00:1f.2-ata-1 conv=sync | gzip -c > /share-area/fedora-system-all_backup.img.gz
sudo reboot

pci-0000:00:1f.2-ata-1 というのが主OSが入っているストレージ。

ちなみにバックアップ用OS（Ubuntu）が入っているストレージは下記。

当初の構想では、下記を実装する予定ではあった。

しかし、OS切り替えがうまく動作しない問題と、普段あまり使用しないのに熱量が多いというデメリットを抱えるため、結局USB接続のSSDで仮運用していくことにした。

どちらかというと熱量の排気が問題。常時稼働だからファンの風切り音を増やしたくないのです。

バックアップ取得後、主OSにて下記コマンドを実行しNASのデータ領域にバックアップを置く。

# mount /dev/mapper/vgubuntu-root /mnt/ubuntu/
# cp -f /mnt/ubuntu/share-area/fedora-system-all_backup.img.gz /data/nfs/Data/System/
# umount /mnt/ubuntu/

NASのデータバックアップの項でも述べているが、結果的に外部記憶媒体へ保存することになる。

システムの復元は単純。

別PCを使用して、システムを復元するストレージを指定して dd コマンドで戻すだけ。

とまぁ色々と書きましたが、そんな運用をしています。