【fitletのページ】

昨年初めの家庭内サーバ空のの引退以降、予備機として机上に おいてはあったのですが、事実上使用していない状態が続いていました。

結局mSATA SSD が空のまま保管機行きか、と思っていたのですが、 メインマシンの Mac mini(M1, 2020)への移行に伴う x86_64 環境として 現役復帰、という次第となりました。

[現役復帰の経緯]

M1 Mac への移行と Intel Mac の運用終了予定に伴い、 素の x86_64 な Windows 環境が無くなってしまうことになります。

これまで、Intel Mac 上の Paralles の Windows 仮想マシンで 手持ちの古いゲーム類の多くを、 BootCamp で起動した Windows10 環境で 仮想マシンでは動かなかった一部のソフトウエアや USB接続のハードウェアのファームウエア更新、SSDのSecureErace を 行ってきました。この辺りをどうするか考える必要が生じます。

まあ、LIVA Z2 のデュアルブート環境に残してある Windows10 Pro環境で 対応は可能なのですが、通常時の家庭内サーバとしての機能と排他利用ということに なります。 さらに、たまに Windows でブートしてみたら Windows 10 そのものの Version Up が必要な場合とかだと、サーバとしてのダウンタイムが数時間レベル (実運用上は一晩とかになるわけですが)になったりしますし、 それで何か操作待ちとかエラーで止まっていたりした日には目もあてられません。 どうにか、LIVA Z2 の家庭内サーバ機能は維持したまま、Windows環境を 準備できないか、と色々考えました。

ある意味考えが煮詰まってしまって、 せめて仮想マシン上でのソフトウエアの動作だけでも何とかならないか、 と、LIVA Z2 の
「ubuntu server 20.04LTS 環境上の LXD で管理する VM」
という、そうそう一般的ではない環境に Windows 10 を入れてみたのですが、 割り当てた CPU 2Core / メモリ 4GBの環境にリモートデスクトップ接続してみての 動作では、操作や表示がいちいち引っかかるような有様で、到底実用的とは 言い難い状況でした。

流石にこの結果には、「今の環境では解決できないのでは」と 大きく失望してしまい、 この際、Ryzen の ミニPCを導入してしまう、という、使う側からすれば 非常に魅力的ではあるものの予算面や消費電力的には本末転倒な思いつきも あったのですがぐっと堪え、 限られた性能で安価な Windows PC の入手も選択肢として考えるように。

で、ここでふと思いつきました。限られた性能でいいのなら、予備機の fitlet で いいんじゃないか、と。AMD A10micro 6700T と非力な CPU ではあるものの、 　 8GB のメモリと 256GB の mSATA SSD を入れてあります。下位の Celeron で 4GBメモリ、eMMC 64GB なんていうスペックのものよりちゃんと 動くんじゃなかろうか、と。

[fitlet への Windows10 のインストール]

早速インストールしてみることにします。

Microsoft のサイトから、Windowws10 のインストール用USBメモリを作成します。 手順は同ページにもありますし、いろいろなところで記事にされていますので、 そちらをご参照ください。

なお、このUSBメモリ、インストール用の iso イメージをただ書き込んだものでは ないらしく、macOS 上で iso イメージを元にインストール用USBメモリを 作成するのは可能ではあるものの、結構な手順を踏む必要があるとのこと。 今回は素直に Windows環境上で作成しました。

次は fitlet 側。
fitPC Wiki の Fitlet drivers for Windows 10 から、Windows10用のドライバをダウンロードしておきます。 今回は、もう一つ別のUSBメモリにコピーしておきました。

次に、BIOSで、Boot順をUSBメモリが優先されるように変更しておきます。

あとは、USBメモリを差した状態で起動すれば、Windows10 のインストーラが 起動しました。動作は遅いものの、後の手順はごくごく普通の Windows10 の インストールと同じです。

インストールが終わって再起動完了したら、fitlet の Windows ドライバを インストールします。手元では、Chipsett/Video/Audio あたりを入れました。 LAN のドライバは、インストールしようとしたら「Windows10 では動作が不完全」 な旨のダイアログが出たので、現時点ではインストールを保留しています。

[fitlet の Windows10 の動作確認]

DELL U2520DRに接続したところ、モニタの最大解像度であるWQHD(2560x1440)まで 選択可能でしたが、全体的に非力な CPU でもあり動作の重さを感じたので、 まずはフルHD(1920x1080)まで落として確認します。

表示自体は問題ありませんが、youtube の動画再生を試してみたあたりで 流石に荷の重さが目立つようになりました。1080p60Hz の動画は 試したものがほぼ静止画状態。720pをフルスクリーン表示 してみてもコマ落ち気味なので、画面解像度の方を 1280x720 まで落としてみると 何とか再生できていそうです。 ただ、見ていると恐らく所々でコマ落ちしてそうなぎこちなさがあります。 480p まで落とすと恐らく問題なさそう、と言ったところでした。

実際、x86_64 な Windows環境が必要な場合の想定には動画視聴は入っていないので、 高画質の動画の再生が難しくても困らないのではありますが。

なお、BIOS での CPU のTDP設定は、標準の 4500mW です。動作が重たいなら TDPを増やしてみれば、というのもあるのですが、この状態で CrystalDiskInfoで 見た内蔵SSDの温度が55℃あたり。大きく TDP を増やすには躊躇します。 まずはこのまま標準状態で運用することにします。

[fitlet の Windows10運用]

結論として、用途を限って限定運用する扱いとしました。 x86_64 な Windows環境でなければ動作しないものを、 (LIVA Z2 を Windows 起動して実行する代わりに) 多少の遅さや不便さは甘受して運用する、と。
まあ、5年以上前に入手した、それも当時でもスペック重視ではない 超小型ファンレスPC に、2021年になって Windows10 を入れて それで何とか動いているのだからよしとするべきでしょう。

[電源投入トラブルと限定運用の断念]

と、ここまではある程度動いていたのですが、数日後に起動しようと したところ、電源ボタンを押しても起動しません。 LEDがオレンジに点灯しているので、ACアダプタからの電源はきているの ですが、電源スイッチに反応していないようです。

以前からやや電源が入りにくいこともあったのですが、サーバー運用時には あまり問題になりませんでしたし、騙し騙し運用していました。 電源スイッチ自体は、基盤上のかなり小さなマイクロスイッチで、 動作の状況もよくは見えないサイズです。

ということで、すぐには修理に手も出せず、限定運用への復帰は 諦めることになってしまいました。Windows10の環境が必要になった 場合は、当面は LIVA Z2 の切り替えブートでしのぎ、今後は (本末転倒ですが)別のミニPCの導入も含めて検討してみたいと思います。

【うちのMacintoshたち】の 「(家庭内LAN の 2.5GbE 化の試行)」にも買いたように、 MacBook Pro の TimeMachine バックアップの高速化を目指し、 LANの2.5GbE化を図ることになりました。

[USB-LAN2500R の導入]

fitlet 用として入手したのは、PLANEX社の USB-LAN2500R です。Linuxでは OS 標準搭載のドライバで動作する、という 触れ込みでした。

実際には、Realtek から Linux 4.15まで、との限定付きで公開されている ドライバをダウンロードし、buildして組み込む必要がありました。

なお、ドライバの build の際に LANG が日本語の指定になっていると、 make も make install も失敗するので、一時的に LANG の指定を解除する 必要があります。
また、kernelがバージョンアップされる度に再度buildして組み込み直す 必要があります。DKMS という仕組みで自動化もできるようですが、 利用する場合はその仕組みを自前で設定する必要があります。
当面はとりあえず手動更新で運用することにしました。

MacBook Pro 側も 2.5GbE化して、2.5GbEのスイッチ経由で接続し、 iperf3 で通信速度をテストしてみました。結果、

• MacBook Pro -> fitlet: 1.90 Gbits/sec
• fitlet -> MacBook Pro: 1.66 Gbits/sec

程度の結果になりました。2.5GbE としてはかなり遅い数値です。

[MTUの設定]

この時点ではまだ MTU 1500 のままだったので、Jumbo frame として 定番の MTU 9000 にしたところ、むしろ遅くなってしまいました。

その後、MTUのサイズ指定を色々変えながら調べたところ、その時点では MTU 8142 が最も転送速度と両方向の速度のバランスが良さそうでした。

• MacBook Pro -> fitlet: 2.14 Gbits/sec
• fitlet -> MacBook Pro: 1.80 Gbits/sec

ぐらいまでは向上しましたが、他サイトでのテスト結果にはまだまだ 及びません。

[fitlet の TDP を 7000mW に]

並行して、Sambaでのファイルコピーのパフォーマンスを見ていたのですが、 コピー中に smbd が cpu を 100%近く使ってしまっています。 動作温度とパフォーマンスを見ながら、TDP を 7000mW に変更したところ、 温度はおおよそ +1℃で、ファイルコピーの速度は数%程度は改善しました。 ただ、iperf3 のテスト結果にはほとんど差が見られませんでした。

[MacBook Pro の LUA-U3-A2G とのアダプタ入れ替え]

転送速度の問題がアダプタ固有なのかどうかの切り分けのため、 MacBook Pro で使用していた LUA-U3-A2G と入れ替えてみました。
どちらも、RTL8156系のチップを搭載しているようで、入れ替えても ほぼそのまま動作しました。

ただ、入れ替えても転送速度に違いはほとんど見られませんでした。

[QNAP QNA-UC5G1T の導入]

となれば、あとは RTL8156というチップかドライバの問題、あるいは 相性問題か、といったところが気になります。MTU 8142 での転送速度が MTU 9000 の場合より良好なことなども考え合せ、少なくとも うちの環境では RTL8156及びドライバの方に癖がありそうな印象です。

色々調べて考えた結果、切り分けのために RTL8156チップではない USB3.0接続の5GbE アダプタ、 QNAP QNA-UC5G1T を導入し比較してみることにしました。

QNAP QNA-UC5G1T は AQC111Uチップを使用しており、ubuntu server 18.04 の HWE カーネルにはドライバが含まれている状況です。fitlet の環境を 再度 HWE カーネルにしたところ、そのまま認識されました。

で、iperf3 でテストしてみたのですが、転送速度はほとんど変わりません。 全く異なるチップ/ドライバで転送速度がほとんど変わらないことから、 fitlet そのものに速度面での制約が生じてしまっている可能性が高く なりました。

ここに至り、LANの2.5GbE化について、やや低い転送速度で我慢するか、 それとも原因と思しき fitlet をより高速の機材に入れ替えて 2.5GbEの転送速度を追い求めるか、の判断をしなくてはならなくなりました。

fitlet を家庭内サーバとして運用し出して3年半弱。過去の家庭内サーバである OpenBlockS266 や fit-PC2 の運用期間に比べると5,6割の運用期間になって しまうので、かなり悩みました。

ただ、今回は明らかなボトルネックが見えてしまっているため、我慢する という判断ができませんでした。性能が不足してしまっているのに 気がついてしまった以上、むしろ家庭内の趣味の世界だからこそ ちゃんと手当てしたい、という思いが強いです。

というわけで、至急新しい機材を選定して入れ替えることになりました。
LIVA Z2のページに続きます。

この辺り にも書いた、TimeMachine backup の対応プロトコルから afp が消えている 件に対処することにしました。fitlet 上で Samba を動作させ、 smb プロトコルで共有することにします。

以前から気になってはいたのですが、使用していて問題が出ないこと、 やはり移行するとなると面倒になってしまい、netatalk での運用が 続いていました。

ただ、しばらく前から、fitlet の ubuntu server 上で autofs で 運用しているバックアップ先のパーティションが、mount されたままに なってしまう症状が出ていました。これまではちゃんと unmount されて いたので、そう大きな実害は無いとはいえ気になります。

どうせなら、この際 smb プロトコルによる共有に切り替えてしまう ことにしました。

[事前準備]

最初に、現時点での TimeMachine backup を二次バックアップしておきます。

macOS側での作業です。 Finder から TimeMachine のバックアップ先をマウントし、バックアップ先の sparse bundle ファイルをそのまま G-RAID with Thunderbolt2 にコピーしました。

[samba の更新]

samba は、Version 4.8系列以降で TimeMachine バックアップへの対応が 行われています。残念ながら、ubuntu server 18.04 では 4.7.6 が インストールされています。

自前での build は面倒だなあ、と思いながら探してみると、 ubuntu の PPA(Personal Package Archive、公式ではなく個人/団体が配布しているパッケージ)に、4.9.8 がありました。今回はこちらをインストールしてみることにします。

sudo add-apt-repository ppa:linux-schools/samba-latest

sudo apt-get update
      

ただ、この PPA、依存関係等が ubuntu 標準のものと異なっているようで、 色々とエラーらしきものが表示されました。
表示に従って対処したり再起動したりしたところ、なんとか動くように なりました。

[smb.confの設定]

「Samba TimeMachine」で検索して見つかったサイトを参考に、 TimeMachine 用の共有に設定を行います。

[macOS側の設定]

本来、TimeMachineに対応した Samba 相手なら不要なのだと思うのですが、 うまく繋がらなかったので。

sudo defaults write com.apple.systempreferences TMShowUnsupportedNetworkVolumes 1

sudo tmutil setdestination smb://user.pass@server/TimeMachine
      

一応これで、netatalk時代のTimeMachine backup を引き継いで動き出しました。 問題があるかもしれませんが、その時はまた対応する、ということで。

PPAのsambaのインストールに悪戦苦闘していた際に、問題が出ていないか ログを確認していたところ、起動時に内蔵 mSATA SSD に関するエラーだか 警告だかが出ているのに気づきました。実際の運用では問題は生じていません が、このSSDが3年保証の2年11ヶ月目ということもあり、詳細に調べる手間を かけるよりは予防交換してしまうことにしました。

で、問題になったのが mSATA SSD の選択肢の少なさです。使用中の SanDisk ものは既に流通していないようで、目に付くのは ややマイナーなメーカーや子細のわからないメーカーのものばかり。 しばらく途方に暮れていました。

NANDチップを自社製造しているメーカーのものとしては、 唯一 Samsung の 860EVO シリーズのものが販売されていました。 幸いにして、500GBクラスのもの前回のSanDiskのものより安価に 販売されており、早速手配することにしました。

[mSATA から SATA への変換アダプタの入手]

データの移行ですが、fitlet には mSATA SSD が 1枚しか装着できないので、 新旧いずれかの SSD は、USB3.0変換で接続する必要があります。 手持ちに USB3.1-SATA 3.0変換ケーブルがあったので、mSATA - SATA の 変換アダプタを探すことにしました。

入手したのは、 玄人志向のmSATA SSD→2.5型SATA SSD変換基板 KRHK-mSATA/S7 です。変換だけに特化した、より小さな基盤だけのものもあるのですが、 mSATA SSD の保護も兼ねて、2.5inch SATA型のフレームのあるこの製品 を選択しました。

[変換アダプタの電源供給の確認]

で、発注してしまってから気づいたのですが、3.3Vの電源供給が 正しく行われるか、この時点では確認ができていませんでした。 というのも、

• USB3.1-SATA 3.0変換ケーブルは、3.3Vは供給しない旨の但し書きがある
  (SATA 3.2規格からは 3.3Vの電源供給は廃止されてはいる)
• mSATA コネクタの規格では、電源供給は3.3Vのみ
• KRHK-mSATA/S7 上で、5V→3.3Vの変換が行われていると思うが 事前確認できない
• 現物が到着してから実装チップを確認しようとしたが、 コネクタとフレームに囲まれていて全く確認できない

という事態に。どうせなら、ということで安価なデジタルテスターも 手配して、USB3.1-SATA 3.0変換ケーブルと KRHK-mSATA/S7 を接続し、 mSATAコネクタの電源ピンの電圧を確認しました。
(ちゃんと 3.3V前後の電圧が出ていて、正直ほっとしました。)

[デバイスの容量が減る方向でのまるごとのコピー]

今回の最後の山です。単に SSD を変えるだけなので、 新規インストールでの設定/データ移行ではなく、まるごとの コピーで済ませてしまいたいところですが、今回は 512GBのSSDから 500GBのSSDへの移行です。一手間かけないと うまくゆきません。

検索して見つけた、
「小さいディスクへのコピー（HDDからSSDへの移行など）」
「ddとGPartedを使ってOSの乗ったドライブを新しいドライブへ移動する」
の内容を参考に移行しました。

個人の好みで、移行前に SSD を交換してしまい、元のSSDを USB3.1-SATA変換ケーブル+KRHK-mSATA/S7 側に接続。 USBカードリーダのmicroSDカードの gparted からブートして データを移行しました。
必要なら設定を調整して、無事新しい mSATA SSD からの起動に 成功しました。

[余談:キーボードが壊れてしまっていました]

普段は事実上ヘッドレス運用のため、作業用のキーボードも 外してしまっているのですが、今回久しぶりに繋いでみたら うんともすんとも言わなくなっていました。

考えてみれば、fit-PC2の導入時に作業用として入手した キーボードです。大した使用時間ではないとはいえ、 入手から10年弱。寿命といえば寿命です。

早速、似たようなサイズの日本語キーボードを探して 手配しました。 サンワサプライのSKB-SL28BK です。かなり安く販売されていたので助かりました。

使用感ですが、やはりキーのストロークがバタバタしているのは サイズなり・実売価格なりではあります。 また、「^」「¥」「[」「]」「*」「_」 のキーが通常の位置にはなく、作業していても思った以上に ミスタイプが多くなってしまいました。まあ、あくまで 緊急時・初期設定時の作業用として捉え、 能うる限り早くネットワーク接続・ssh接続を確立できるようにして、 後はsshで接続して作業、という方針で行くことにしました。

fitlet上の Ubuntu Server 16.04 LTS にログインする度に、 18.04への更新を促すメッセージが表示されるようになっていました。

16.04 LTS のサポート期間は 2021年4月までとなっているので まだ慌てる必要もないのですが、動作するソフトウエア、 特にSambaのバージョンを新しくしておきたい含みもあり、 今回更新することにしました。

[Parallels Desktop for Mac の VM上でのリハーサル]

18.04にアップデートしていきなり「動かない」というのも大問題なので、 一旦 Parallels の VM上でリハーサルすることにしました。

以前から、設定変更等のテスト用として利用している VM があるので、 その上で

sudo apt-get update
sudo apt-get dist-upgrade
      

した上で一旦 VM を再起動した後、

sudo do-release-update
      

するだけです。
結果、設定ファイル2個の移行確認(内容が変更されているので 18.04の設定ファイルに置き換えるか、今のファイルをそのまま残すか) がありましたが、後はそのまま移行できました。

[fitlet上のUbuntu Serverのアップデート]

リハーサルで大きな問題がなかったため、先の3連休の初日に fitlet上の本番環境もアップデートしました。
アップデート前の更新を済ませた上で、メール処理を停止し、 MacBook Pro側の TimeMachine自動バックアップを停止した上で アップデートを行います。

sudo do-release-update
      

した結果、設定ファイル 7個の移行確認が生じました。 うち、4個の設定ファイルは 18.04 のものに置き換えて、変更点を 再度手動で反映し、apcupsd と autofs の設定ファイル合わせて3個は、 以前のファイルのままでも動作に問題がなさそうだったので そのまま引き継ぎました。

設定ファイルの変更箇所の手動での反映後、再起動してサーバとしての 運用に復帰させていますが、今までのところ以前との動作の差異は 感じていません。無事アップデート完了、というところです。

先日 TimeMachineバックアップの高速化のために Sophos Anti-Virus for Linux の設定を変更しましたが、使用している netatalk では、管理に用いている CNID DB を /var/lib/netatalk/CNID/ 下に置いており、 ファイルやディレクトリの更新があると、このディレクトリ下への アクセスが発生します。

sudo /opt/sophos-av/bin/savconfig add ExcludeFilePaths /var/lib/netatalk/CNID/
      

で、このディレクトリもスキャンの除外設定に追加しました。

mac の Parallels Desktop for Mac 13 が Ubuntu 18.04 に 対応したので、仮想マシン上ですが少し触って見ました。

[日本語設定]

まず、技術評論社さんのサイトの連載の記事、 「Ubuntu Weekly Recipe / 第520回　Ubuntu 18.04 LTSの日本語入力」 の、「18.04 LTSログイン直後の初回設定」を参考に、mozc を使うよう設定 しましたが、日本語入力できませんでした。

16.04 の頃に、「システムツール」-「入力メソッド」で fcitx を使うように 設定していたので、今回は一旦 iBus を使うようにした上で 「有効な設定」を auto に設定し直し、念のため Ubuntu の環境を 再起動したところ、正しく日本語入力できるようになりました。

[Gnome Shell Extension]

以前使っていた環境と同様にするため、Gnome Shell Extension を 2つ追加しています。

• Window List
• Workspace Indicator

[端末ベルを停止]

アプリの音量等と、端末のbeep音であるベルの音量をうまく両立できず、 当面端末のベルを鳴らさないようにしました。
端末の「Preference」-「文字」-「Sound」の「端末ベルを鳴らす」の チェックを外しました。

[Firefoxの縦スクロール速度: track pad での二本指スクロール]

Firefoxの縦スクロールを track pad 上の二本指スクロールで行う際、 ちょっと反応が大きすぎて使いにくい状態でした。
遅すぎる場合の例ですが、 「ubuntuのFirefoxのマウスホイールのスクロール速度を変更する」 を参考に、(うちでは逆に遅くしたいので)値を 50 にしてみました。 随分ましになったので、しばらくこれで使ってみます。

fitlet で netatalk を動作させ、MacBook Pro の TimeMachine バックアップ先としていますが、ここのところバックアップ容量の割に バックアップ時間がかかることが増えていました。場合によっては 大したバックアップ容量でもないのに30分程度かかることがあります。

何か原因があるに違いないので、TimeMachine バックアップ実行中に fitlet に ssh でログインして top コマンドで CPUの負荷状況を眺めていたら、 savscand というプロセスが2つ、結構な CPU負荷となっていいました。 その CPU負荷は変動していますが、TimeMachine バックアップが終わると 大きな CPU負荷ではなくなります。

この savscand, インストールしてある Sophos Anti-Virus for Linux の 常駐スキャナだと思われます。TimeMachine バックアップの実行中に CPU負荷がかかるのは、TimeMachineバックアップの書き込みデータを スキャンしているのでしょう。

バックアップデータなので、元の MacBook Pro 上で F-Secure SAFE による ウィルススキャン済のデータです。 動作面で大きな影響がないのならダブルチェックの意味で fitlet 側でも ウィルススキャンする意味があります。ただ、見込み通り TimeMachine バックアップのウィルススキャンで重くなり時間がかかっているなら、 無理に fitlet 側でウィルススキャンしなくても良いといえば良い話です。

試しに、TimeMachie バックアップのデータを置いてあるフォルダを ウィルススキャン対象から除外してみました。
標準的な位置にインストールしているなら、

sudo /opt/sophos-av/bin/savconfig add ExcludeFilePaths (除外する path)
      

で除外対象に追加できます。設定した除外対象の path の確認は、

sudo /opt/sophos-av/bin/savconfig query ExcludeFilePaths
      

です。

この設定を行ってからの TimeMachie バックアップは、今のところ 5分〜8分程度で完了することがほとんどです。稀に10分強ぐらい。 スキャンの除外設定を行った効果が現れています。
しばらくこの設定で様子を見ながら運用して見ます。

主として MacBook Pro に外付で接続し実験等に使用していた Intel 520 SSD がおかしな動作をし出したので運用終了にしました。 その際、S.M.A.R.T情報で製品寿命を示す値が寿命の2.5倍程度の 値となっている一方、TBW の 3分の2 程度しか書き込みしておらず、 何が原因で寿命を大きく超えた評価となっているのかが良くわかりません。

いずれにせよ、SSDの使用状況を確認しておかないと安心できません。 fitlet に内蔵してある mSATA SSD は、SanDiskの Ultra II シリーズです。 この製品は、TBW が公開されていません。
smartctl で 見て見ると、ID#173 の Wear Leveling Count に 相当する値は「1」でした。
これは、書き換え可能回数に制限のある SSD の NAND Flash 全体を 満遍なく使うことで寿命を使い切る処理、ウエアレベリングに関連 する回数で、さすがにこの数字だと寿命にはまだまだ程遠いでしょう。

少し安心しました。

【Linuxのページ】 でも触れましたが、Ubuntu 18.04 LTS がリリースされました。
うちでもアップグレードを考えていますが、事前に影響を 確認しようと思っていた、macの Parallels Desktop for mac 13上の 仮想マシンでの追加ドライバの問題があり、実際の確認が行えていません。

一部パッケージを PPA からインストールしていること、 及び TimeMachineバックアップ先として運用しているために 不具合があって運用が止まるのが困ることもあり、 fitlet上でのアップグレードはしばらく先になりそうです。

この1週間ぐらいの間の Ubuntu Server 16.04の更新で、 linux kernel の

• 4.4.0-122(新版)
• 4.4.0-122

がアップデートされました。

この1週間ぐらいの間の Ubuntu Server 16.04の更新で、 linux kernel の

• 4.4.0-121
• 4.4.0-122

がアップデートされました。

しばらく更新間隔が空いてしまったので、現況をまとめてみます。

ubuntu server 16.04には、あの後、

• 4.4.0-112
• 4.4.0-116
• 4.4.0-119

の kernel の更新が公開されています。lwn.orgでこの間のlinux-kernel そのものの変更箇所を見ると、 ちょこちょこと Meltdown/Spectre の文字が見えますが、基本的には x86アーキテクチャ向けの修正は、4.4.113辺りまでで一旦落ち着いているように 見えます。

[RS-EC32-U31Rの運用状況]

HDD温度が40℃で空冷ファンが回るように設定していましたが、 流石に最近の気温では、回っている期間が伸びて来ました。
一旦取り外して MacBookPro に接続し、RAIDManagerで 空冷ファンが回るようになる温度を45℃に変更しています。

FreeStyleWiki に、3/28付でバージョン3.6.5の正式版が出ていたので、こちらでもアップデート しています。

[ubuntu の Meltdown対策 kernel]

米国時間の1/9に、ubuntu server 16.04 にも 4.4.0-108 としてリリースされました。しかしながら、一部環境で 起動できない(?)問題があったようで、すぐに 4.4.0-109 が リリースされています。

fitlet上では、4.4.0-108でも4.4.0-109でも問題なく起動できていました。
また、TimeMachine バックアップの毎秒あたり書き込みデータ量で 見る限りは、Meltdown対策前の kernel、4.4.0-104 での実行時と ほぼ同様の数字となっています。
＃ AMDのAPUには Meltdown の影響はないとのことなので、
　 パッチ部分の影響も受けていない、ということなのでしょう。
　 今後の対応で影響が出てくるかどうか、が気になるところです。

ubuntu の対応パッチは、米国時間の1/9のようです。
今回のはおそらく Meltdown 対応のパッチなので、 AMDのCPU(APU)を積んだfitletにはパフォーマンス的な問題は 出ないはずですが、念のため適用後に確認して見ます。

fitlet は BIOSのTDP設定によってパフォーマンスが変わります。
出荷時の設定、TDP 4500mW では、BIOS上や cpufreq-info で見た 最大周波数が、1.2GHz になっています。
# 本来は、通常時 1.2GHz, Boost時に 2.2GHz というスペックです。

今回は、TDP設定を 10000mW にした上で、

• BIOS上や cpufreq-info で見た最大周波数
• TimeMachineバックアップ時間への影響
• openssl の実行速度の変化
• 発熱への影響

といった視点で見て見ます。

[BIOS上や cpufreq-info で見た最大周波数]

最大 1.2GHz のままでした。

[TimeMachineバックアップ時間への影響]

netatalk.log 上で、

• 毎回のTimeMachineバックアップ毎に記録される、Login/logoutの経過時間
• その回の afpd から見た書き込みデータ量

を元に、毎秒あたりの書き込みデータ量を比較してみました。
もちろん、毎回のバックアップ内容により相当ばらつきがありますが、 極端な値を除いて平均したところ、おおよそ50〜60%程度高速、という 結果になりました。

[openssl の実行速度]

CPUのAES高速化 というサイトで、openssl の処理の速度について調査されていました。
参考にさせていただいているだけになってしまっているのですが、 以前の測定結果を記録していたため、今回ベンチマークとして使わせて いただきました。

openssl speed -evp aes-128-ctr
      

の結果を比較したところ、おおよそ 60%強 高速な結果が出ました。

[発熱への影響]

muninでの5分間隔の測定結果を元に比較すると、 アイドル時で1℃前後、ピーク時で5〜6℃上昇しました。
＃実行中の室温は、おおよそ15℃前後でした。

温度のピーク時の時刻からすると、おおよそ TimeMachine バックアップ実行中 だと思われます。

[評価]

最大周波数は1.2GHzのままだったものの、おおよそ6割程度のパフォーマンス 向上となります。但し、5〜6℃の温度上昇を伴い、室温に対して最大+27℃程度の 値となります。
ただこれは、単純計算で夏場の酷暑時を想定すると、ちょっと怖い温度です。 酷暑時の室温の最悪想定値を40℃とすると、67℃とかになってしまいます。 真冬と真夏で状況が異なる部分もあるにせよ、安心できる温度ではありません。
運用としては、TDPを一旦元の 4500mW に戻すことにしました。

fitletをファイルサーバー運用する以上、やはり瞬停やミスによるブレーカー断 を含む電源トラブルへの対策として、UPS(無停電電源装置)を導入することに しました。

UPSのメーカーも機種も多種多様ですが、linux上で動作する UPSの管理及び電源連動ソフトウエア、apcupsd を利用することを想定して、 APCブランド(現在は シュナイダーエレクトリック 社のブランドです)のUPSから選定することにしました。

[バックアップ対象]

まず、サーバーである fitlet。次に、外付RAID1 及び接続に使用している セルフパワーのUSBハブ。メインで使っている MacBook Pro は バッテリー動作可能なので除外して、無線LAN AP + GbEハブとして 運用している TimeCapsuleまでを対象とします。
ちゃんと容量を選択すれば、これで TimeMachineバックアップ中の 電源トラブルでも問題が起きないはずです。

[電源容量の見積もりと機種選定]

UPSの選定時には、バッテリバックアップ対象の機器の消費電力と、 バッテリバックアップする時間を見積もり、容量を決定する必要があります。
今回の場合、fitletは仕様上の最大が10.5W, 外付HDDケースが最大約13W, 内蔵HDDが 読み書き時の平均で 6.4W x 2, USBハブは接続機器が自前の電源なので ほぼ誤差程度でしょう。
以上合計で36.3W+αなので、上に丸めて40Wをみておきます。
TimeCapsuleの消費電力は不明ですが、無線LAN機能とGbEハブ機能だけの 利用なので、15Wぐらいで見積もっておきます。
合わせて55W、これも多目の方に丸めて、60Wを想定しておきます。

次にバッテリバークアップの時間ですが、 できれば稼働20分+シャットダウン用5分で、25分以上は欲しいところです。
＃20分あれば、ほとんどのTimeMachineバックアップは完了します。

厳密には、消費電力だけでなく VA も調べる必要があるのですが、 その辺は今回はざっくりでいくことにします。代わりに、バックアップ容量に 余裕を持たせます。

APCのサイトのランタイムチャート を見る限り、RSシリーズ、ES550、及びSmart-UPSなら大丈夫そうです。 設置場所の面積の問題でSmart-UPSは置けないので除外し、ES550は LCDパネルなしでLEDなのがちょっと楽しくありません。
＃電源トラブル時等、トラブル時には単純な操作で情報が得られる方が ありがたいので。
あとは、RS400/550辺りです。実はバッテリーバックアップのコンセント数が 足りていない(3口)なのですが、今回の接続形態に限っては問題なさそうなので、 USBハブの電源を他の機器に同居させてもらうことにします。
最後に、大は小を兼ねるということで、 RS550(BR550S-JP) を選択しました。

現行のRS 550には、型番が2つ(BR550S-JP と BR550S-JP E)あります。 末尾に E が付くのは、保証期間が2年のもの、Eがないのが保証期間 3年です。 購入した販売店での価格差が約2,000円程度だったので、3年保証の物を 手配しました。

[設置と接続]

箱から出し、バッテリーを結線したあと、コンセントに繋いで充電します。 メインのコンセントと2番目のコンセントの間隔が狭く、fitletのACアダプタを メインのコンセントに挿すと2番目のコンセントが使えませんでした。
30cmの短いAC延長ケーブルを使って回避しています。あとは、USBケーブルで UPSとfitletを接続します。

ちなみに、RS550の前面パネルの表示によると、TimeMachineバックアップ中の 消費電力が27W程度で、バッテリ持続時間は57分ということでした。

[apcupsdの導入]

ubuntu server のパッケージで、apcupsd と apcupsd-cgi をインストール しました。
Setup APC UPS on Ubuntu Workstation using apcupsd といったページを参考にして　/etc/apcupsd/apcupsd.conf を修正し、 /etc/default/apcupsd の ISCONFIGURED=no を yes に修正した後、サービスを起動しました。

apcacess コマンドや、fitlet上の /cgi-bin/apcupsd/multimon.cgi 以下で 取得している情報を確認したところ、RS550のLCD上で確認できる情報は ほぼ取得できています。シャットダウン開始のタイミング等は、今後 詰めていきます。

いずれにせよ、これで約1時間弱程度の電源障害には対応する準備ができました。 これで瞬停やブレーカー断が発生しても、データ破損や機材の故障のトラブル を気にせず、心安らかでいることができます。

IPv6環境になったこともあり、勘違いや先のひかり電話ルータの設定漏れの ような事が生じた際のセキュリティも考慮して、fitlet上の環境でも firewall をちゃんと設定することにしました。

まず、

netstat -nap
      

で、実際に LISTEN している IPアドレスとポート、プロトコル及び LISTEN しているプログラムを確認します。
うちでは、IPv4 で sshd と Samba と avahi が、IPv6 で sshd と apache, Samba に imap, afpd が LISTEN していました。

ufwの基本操作 を参考に、設定内容を確認しながら設定していきます。avahi の通信を 許可する設定はデフォルトでされているようなので、 IPv4 で sshd と Samba, IPv6 で sshd, apache, Samba, imap, afpd を 許可するように設定しました。いずれも、LAN内からの通信に限定しています。

で、大凡これで大丈夫だったのですが、いくつか設定を追加しました。

(IPv4での apache, afpd とマルチキャストの許可)

稀に avahi での名称解決に失敗するケースがありますが、 その際でも Webサーバーにアクセスできるよう、IPv4 での apache を許可しました。
IPv4 では LISTEN していないように見えるのですが、 IPv4アドレスで指定 したURLで接続できます。
後の2つは、/var/log/ufw.log に BLOCK した記録が残り続けるための 対処です。afpd も IPv4 では LISTEN していないように見えるのですが、 MacBook Pro からパケットが飛んでいるようなので。同じく、マルチキャストは 224.0.0.251 宛の通信なのですが、調べたらそれこそ Bonjour/avahi の multicast DNS そのもののようですので、こちらも 許可しておきます。

この設定で、今の所想定外の BLOCK はログに記録されていません。 しばらく様子を見てみることにします。

以前から、自分のメモ代わりとして、 FreeStyleWiki をfit-PC2やfitlet上で動作させています。オーナーの方がお忙しいのか 安定版がずいぶん長くリリースされておらず、最近のバージョンの Perl5 では動作しない機能があるなど、ある意味運用に制限がかかる状態でした。

最近、SVN版の管理をされている方(?)が、Perl5.26以降に対応し、 最近の修正を含む版をダウンロードできるようにしています。

うちでも、画像の表示やPDF生成に問題があったので、ありがたく 更新させていただきました。
画像の方は問題ないのですが、PDFの方は macOSの Preview.app と 相性があまり良くないようで、白紙表示されることが多いです。 Firefoxの内蔵Viewerだと正常に表示されます。

FreeStyleWikiは、Perlで書かれたCGIです。高速化するために、 Apacheのモジュールとして mod_perl があります。

Ubuntu 16.04 で Apache2 + mod_perl の環境を構築(英文) のページを参考に、mod_perl の環境を構築しました。
Path を自分の環境に合わせ、あとは REMOTE_ADDR が IPv6 のアドレスに なっているようだったので、LANの環境に合わせて Require ip の行を 書き換えました。
FreeStyleWikiは Apache::Registry に対応しているとのことなので、 ModPerl::Registry を指定しました。あとは、FreeStyleWiki の docs/readme.html に記載のあるように、wiki.cgiの先頭付近を書き換え、 実際の Path に chdir() するように書き換えました。

結果、ページの表示・更新はかなり速くなっています。メモリの使用量が 多いと言われていますが、fitlet では cache 以外にはそう多くのメモリを 使っていないので、そう気にする必要はないのではないか、と思っています。

IPv6はそれこそ20年ものの規格で、修正・更新が繰り返されています。 古い記事やドキュメントでは当たり前のこととして書かれていることが 後にはオプションになったり廃止されたりと、古い記事は間違っている ことがあることを前提として読む必要があります。

と言いながら、Impress の Internet Watch の記事、 20歳を超えたIPv6の現状、修正版RFCで廃止／アップデートされる仕様も を読んでいてびっくりしました。言われてみればおっしゃる通りなのですが、 「EUI-64によるアドレス生成の非推奨（RFC4291の修正）」とのこと。 MAC Address から生成されるインターフェイス識別子はプライバシー保護上 よろしくない、と。

で、確認して見たところ、fitlet がまんま EUI-64を基にした インターフェイス識別子で、しかも匿名アドレスを使用していませんでした。 慌てて、

• /proc/sys/net/ipv6/conf/enp4s0/use_tempaddr に 2を書き込み
• /etc/sysctl.d/10-ipv6-privacy.conf に以下の行を追加

net.ipv6.conf.enp1s0.use_tempaddr = 2
net.ipv6.conf.enp2s0.use_tempaddr = 2
net.ipv6.conf.enp3s0.use_tempaddr = 2
net.ipv6.conf.enp4s0.use_tempaddr = 2
      

といった措置を施しました。

[動作音の測り直し]

色々なサイトを見て見たのですが、あの状態の夜間の枕元で 20db というのは やはりちょっと数値が低すぎる気がします。

そこで、iOS用の別の簡易騒音計アプリを入手して比べてみることにしました。
今度は、「デシベルメータープロ」というものにして見ました。

結果、

• 空冷ファン動作中(10cm): 52db
• 夜間の枕元: 32〜33db

ぐらいの結果になりました。前よりはそれっぽい数値なのではないか、と思います。

この一週間に、一度だけTimeMachineバックアップがエラーになりました。 MacBook Pro 側にエラーの旨の通知が表示され、「詳細」をクリックしたら バックアップ先が見つからない旨が表示されました。
netatalkのログでは、TimeMachineバックアップ毎に記録される login が記録されていませんでした。
直後の TimeMachineバックアップは正常に動作しており、以後再発していません。
しばらく様子を見てみます。

[RS-EC32-U31Rの運用状況]

HDD温度が40℃で空冷ファンが回るように設定していますが、 室温が17〜18℃でも間歇的に回っている状態です。 smartmontools で見た温度の履歴でも、最高41℃。 空冷ファンが回りっぱなしの状態での最高温度は34℃でしたから、

• 空冷ファンで冷却しないと、HDD温度は40℃以上まで上昇すること
  現時点でどこまで上昇するかは不明
• 空冷ファンが回れば、HDD温度は低下すること
  回し続ければ34℃ぐらいまで下げられること

は確かなことです。

現時点の状況であればこのまま運用できますが、 暖房を入れたり、あるいは春以降に気温が上がってきた場合には、 空冷ファンの回転する閾値の温度を変更することになるでしょう。

あと、空冷ファンが周りだすとそれなりに音はします。構造上、 やはり吸気があまりスムーズではないのかな、という気もします。
もちろん、開口部が大きければ吸入抵抗は少ないのでしょうが、その分 内部の動作音が漏れてくるわけで……。なかなか難しいところではあります。

ちなみに、現状の空冷ファンの音ですが、iPhoneの簡易騒音計アプリで、 RAID1ケースから10cmぐらいのところに置いて 40db台前半 50db強ぐらい(iPhoneの別の簡易騒音計アプリで測りなおしました) の数値になるぐらいのレベルです。まあ、昼間は気にしなければ 気にならないレベル、といったところでしょうか。
夜間は、同じアプリを使っての枕元での測定で 20db前後 30db強ぐらいですので、 起きている時に空冷ファンが回りだせば気がつきますが、 寝ている時にそれで目が覚めるほどではありません。

2017.7.22 の「(fitlet稼働からの1年を振り返って)」でも書きましたが、 fitlet を導入して以来、やはり放熱面を気にして、fitletでは 新しいことを積極的には行なっていませんでした。

ですが、そう書いて見たものの 「せっかく買ったのに、あれだけしか使っていないのは……。」 と思う部分は少なからずありました。何かきっかけがあれば 運用をいろいろと検討する、ぐらいの感じにはなっていました。
そんな時に、まさにその「きっかけ」の組み合わせが出てきました。

[きっかけ その1: TimeCapsuleの不調]

【わが家のMacintoshなどたちの紹介】の MacBook Pro(Mid 2014) のところにも書きましたが、今年2回ほど TimeCapsule の TimeMachine バックアップイメージファイルのエラーに見舞われました。
それ以後は問題なく使ってきましたが、バックアップ用途という こともあり不安は残ります。また、この TimeCapsule も購入から そろそろ3年を迎えますが、Appleからの後継機種のリリースがなく、 やむなくサードパーティー製品への移行について考えるようになりました。
以前の経験から、外付ドライブへの TimeMachineバックアップは高速ですが、 使用していない時点ではHDDの回転を止める省電力運用だと、TimeMachine バックアップの度に(HDDのスピンアップ待ちで)全体が一時的に止まってしまう ようになります。TimeCapsule での運用が快適だったため、移行先についても NAS で検討することにしました。

[きっかけ その2: NASの機種選定]

TimeMachineバックアップ対応をうたうNASも多く、機種選定は 悩ましかったのですが、今回は NASを主力とする海外メーカーのものに 傾きました。

NASを主力とする海外メーカーのNAS製品は、種々のアプリケーションが 追加インストール可能で、最早 NAS機能のあるミニサーバー、といった体を なしています。今回はその中から、 Synology社の2ベイのモデルの導入に 傾いていました。

エントリーモデルの DS218j では多機能な割にメモリが少なく、 DS218+ や DS718+も検討していましたが、ハードウエアのスペックを 見ているうちに、ある意味 fitlet と同じあたりのものだと気づきました。 このあたりで、fitletのファイルサーバー運用についても考えるように なりました。

[きっかけ その3: fitlet heatsinkの調達]

久しぶりに fitletのサイトを見ていたら、 日本からは CompuLab社からしか入手できず、送料の高さ(88$)で 手をこまねいていたfitlet専用の放熱板、fitlet heatsinkが、 米amazonから日本に発送可能になっていました。

早速、米amazonのアカウントを作って購入手配をし、どうせなので 2〜4営業日で配送だという AmazonGlobal Priority Shipping を選択 したところ、注文から3日半で到着しました。
heatsink本体が15$、送料が16.39$でした。本体より送料が高いのは 何ですが、なにせ以前検討した時の送料、88$に比べれば大したことは ない、と思えてしまいます。

[fitlet heatsink 外観]

[fitlet heatsink 装着前・後]

fitlet heatsink を装着した結果、従来の環境との内部温度の変化は、 実際にはせいぜい1〜2℃程度のようです。

これまでの、ジャンクの放熱板+熱伝導シートで、 合計4〜5℃程度の内部温度低下の効果があったので、合わせると 素の状態のfitletに対して、5〜6℃程度の温度低下効果があることになります。

fitlet heatsink で放熱面は僅かとはいえ改善できるだろうこと、 現在 fitlet に任せている機能全てが NAS に載せられるわけでは無いので、 NASを導入しても fitletとの併用になること、 fitlet で運用してうまくいかなかった時点で NAS の導入を再検討する手も あることから、今回は NASの導入を取り止め、fitlet のファイルサーバー運用に 踏み出すことにしました。

[外付 RAID1 HDDケースの選定]

HDDの容量や容量あたり単価を考えて、ファンレス運用を諦めて USB3.0接続の 3.5inch RAID1 ケースで行くことにしました。
3.5inch HDD 用のケースは種々あるのですが、

1. 保証期間経過後のトラブル時には、短時間での復旧のために 同一製品で交換することも考慮して、すぐには販売終了にならないであろう 比較的最近発売されたもの
2. できれば設置面積の少なくて済むもの
3. もし fitlet での運用がうまく行かなかった場合、外付HDDとして 運用するので、どうせなら USB3.1接続のもの

あたりを考慮し、かつこの1年以上 fitlet の外付RAID1ケースとして 問題のなかった RS-EC22-U3R のメーカー、RATOCSYSTEMS さんの RS-EC32-U31R を選定しました。
但し、この製品も 「Windows 7/8.1/10 及び MacOSX 10.10/10.11, macOS 10.12 への対応」 とされています。
Linuxは動作環境外 ですが、FAQ等を読む限り、対象外の環境からでも単なる USB HDD に見える ようなので、購入に踏み切りました。

[HDDの選定]

TimeCapsule の載せ替え用として 3TB、fitletのバックアップ先の 分で 500GB、都合 3.5TB以上の容量が欲しいところです。 あとは24時間付けっ放しの運用になるので、比較的発熱の少ない 製品を、と考えました。
この時点で、WD Red の 4TB以上のものにすることにして、 あとは容量です。流石に4TBだと事実上これまでとほぼ同容量で、 ケースのFAQで8TB越えのHDDは未テスト、ということから、 6TBか8TBの選択になります。
シーク音が煩い、という話はあったのですが、容量と「ヘリウム充填」の 誘惑に負けて、今回は WD Red の 8TB(WD80EFZX) を選定しました。

[外付RAID1ケースの準備]

前面下部のロックを外して蓋を開け、HDDをそれぞれ差し込見ます。 下面からネジ2本でHDDを固定し、蓋を閉めるだけです。
あとはUSBケーブルを繋がず電源を入れて、RAIDモードをRAID1に しました。

この時点で、MacBook Pro に繋いでフォーマットし、Black Magic Disk Speed Test でアクセス速度を測ってみると、

程度のアクセス速度になりました。WD80EFZXのデータシートによると 内部転送速度が 178(MB/sec) となっているので、ディスク性能は ほぼ出ています。

[パーティション分割, ファイルシステム作成]

次に、fitletに繋いでパーティション分割とファイルシステムの作成です。 先頭から、TimeMachine用 4TB, Samba共有用 2.3TB, fitletのバックアップ用 1TB にパーティションを切り、それぞれ ext4 でファイルシステムを作成しました。 hdparm -t の結果は、各パーティションで以下のようになりました。

第1パーティションの値を見ると、MacBook Pro直結時やHDDの内部転送速度からは 数%程度低い数字になっていますが、実用上問題にはならないでしょう。 第3パーティションでも、これまで使っていた 2.5inch RAID1 よりも 多少早くなっています。

[既存のfitletバックアップデータのコピー]

http://howm.osdn.jp/cgi-bin/hiki/hiki.cgi?Pdumpfs のスクリプトを使わせていただいてバックアップしている内容です。 ハードリンクを使用しており、それをそのままコピーする必要がある わけですが、これまでパーティションのコピーに多用していた tar コマンドは、ハードリンクを実ファイルのコピーに置き換えてしまう らしいので、ちょっと困ってしまいました。
cp -r でのシンボリックリンクとハードリンクの扱い によると、linuxの場合は、cp コマンドの -d オプションでハードリンクのまま コピーしてくれるとのことです。

[Sambaの設定]

ubuntu server 16.04 でインストールされる、Samba 4.3.11 をそのまま 使っています。Netatalkとの併用環境になることもあり、念のため NetatalkとSambaの統合 のページを参考に、オプションを追加しています。

[Netatalkの設定]

最初は ubuntu server 16.04 でインストールされる、netatalk-2.2.5 を 使っていたのですが、色々気になることがあったので、 OSX Time Machine Ubuntuサーバ を参考に、PPA(Personal Package Archives)として公開されている netatalk-3.1.11 をインストールして使っています。
公開用のフォルダを作成し、接続用のアカウントを所有者にしてあります。

まずは、Netatalk及びSamba経由でのアクセス速度を、Black Magic Disk Speed Test で測定して見ました。

Samba の WiFi接続は結果があまり安定せず、上記の結果はかなり低い方の値を 取っています。

NetatalkのWriteには重い処理があるようで、Readよりは遅くなっています。 NetatalkのReadと、有線LANでのSambaのWrite/Readは、netperfでの通信速度の 9割程度の結果になっており、共有プロトコルのオーバーヘッドを考えると ほぼ帯域を使い切っているのだろうと思います。

[TimeMachineバックアップ]

「システム環境設定」の「Time Machine」を開き、 「ディスクを選択…」で fitlet の netatalk共有を選択するだけで 切り替わります。

最初は、TimeCapsule から TimeMachineバックアップの .sparsebundle ファイル (フォルダ)をコピーして、継続してのバックアップにしようとしたのですが、 どうも毎回のバックアップ量が多い気がして、tmutilで確認した差分の内容に ついてもあまり納得がいかず、ゼロからの TimeMachineバックアップと することにしました。

[動作音やfitletの発熱状況]

事前情報通り、やはりHDD(WD80EFZX)はシーク音がやや重く響きます。
気休めですが、ゴムのインシュレーターを筐体の下に敷いてあります。
また、空冷ファンが回っている場合は、そう大きな音ではありませんが 音がしています。

その RS-EC32-U31R ですが、「特徴」のページやFAQに、 「HDD 温度が45℃以上になったら空冷ファンが回転する」 ように書いてありますが、うちの環境では常に空冷ファンが 回転しっぱなしでした。smartmontoolsで取得したS.M.A.R.T情報では、 30℃台前半(最高34℃)になっており、辻褄が合いません。
netatalkとsambaを停止し、利用しているパーティションをアンマウント した上で取り外し、MacBook Pro に繋いで「RATOC RAID監視マネージャー」 の「省電力」のページを開いたところ、空冷ファンの回転が止まりました。 その時点で、空冷ファンの回転する閾値の温度設定が行われたのだと 思います。

45℃だと冬場の閾値としてはちょっと高い気もするので、40℃に設定し直しました。 しばらく状況を見てみることにします。

これまでの更新で書き忘れていたトラブルが1件ありましたので、今更ながら。

2017年5月頭、これまで精々2〜3分だった再起動が、10分以上かかるように なりました。 コンソールで確認すると、シャットダウン時に LVM の停止のメッセージの後に 時間がかかっているようです。 調べてみると、 【Ubuntu】シャットダウンが遅い というページが見つかりました。同様に、/etc/systemd/system.confの

DefaultTimeoutStopSec=10s
	

の行のコメントアウトを外して保存したところ、次からは以前と同程度の時間で 再起動ができるようになりました。

自宅内でMacBook Proからfitletにはsshで公開鍵を利用して接続しています。
先日、別件で調べていて、 「 お前らのSSH Keysの作り方は間違っている」 という、ちょっと刺激的なタイトルの記事に行き当たりました。

このページ内の記載にある方法で、.ssh/ 下の鍵の鍵長を調べてみたところ、 1024bitでした。4096bitで作り直した上で、公開鍵の内容を MacBook Pro上の 端末で表示し、fitlet の ubuntu server 側の authorized_key2 を vi で 開いてコピー&ペーストしたのですが、うまく接続できませんでした。 MacBook Pro側の keychain から削除しても、MacBook Proを再起動しても ダメでした。
結局は、 SSHでPermission deniedが解決しないと思ったらauthorized_keysに"\n"が紛れ込んでいた あたりを見て、コピー&ペーストではなく scp で公開鍵を fitlet 側にコピーし、

cat (公開鍵へのpath) >> authorized_key2
	

したところ、正常に動作するようになりました。やはりうちでも改行が悪さを していたのではないか、と思われます。

2017年8月に、電源ボタンを押しての強制再起動が必要となるトラブルが 2件発生しました。

[TimeCapsule再起動後、ssh接続できない]

[apt autoremove後の再起動後に正常起動せず]

sudo apt autoremove
sudo reboot
	  

fitletを家庭内サーバーとして稼働して、丸一年が経過しました。

先述した外付HDDのトラブルはあったものの、fitletそのものには 問題なく一年を過ごすことができました。
しかしながら、これは当初予定したことややってみたかったこと全てが できたわけではありません。そこで、その辺りを含めて一年を振り返って 見る事にします。

[先に：まとめ]

想定より発熱に気を使う必要がありましたが、fit-PC2で行なっていたこと は余裕を持って全て行えています。ただ、パフォーマンスと発熱に余裕が あるかどうかの確信が持てず、新しいことはほとんど行えていません。

[発熱の問題]

まずはここに尽きます。1年間サーバーとして運用した範囲で、muninで 記録されたCPU/HDDの最高温度が55℃程度。なんとか当初想定していた 程度の温度で運用できました。

ただ、発熱対策として行なった設定の中に、パフォーマンスやレスポンスを 悪化させる(省電力に繋がる)ものがあります。結果として、発熱を 気にして大きな負荷のかかるようなことを取りやめた面もあります。

もちろん、あくまでうちの現状の、ファンレスかつ平日昼間は空調なし、 という環境においての話ではあります。 なんらかの冷却手段を講じるか、あるいは空調の効いた場所に置けば 状況は相当改善すると思います。

[パフォーマンス]

これは、事前の調査不足というか、そもそも情報を掴むのが難しかった事に なります。

パフォーマンスを高めるには、fitletのTDP設定を標準の4500mWより 上げる必要があり、それは発熱の増大を伴います。また、オプションの 「fitlet-heat-sink」の利用等、放熱効率の改善を行うか、冷却効率の改善の 為に送風や空調、あるいはその組み合わせで温度環境を改善することが 望ましいでしょう。

先週、熱対策は「なんとかなった」と思ってホッとしていたら、 外付の USB RAID HDDがエラーを起こしました。

ディスクから「カタン、カタン」という音が繰り返ししており、 インジケーターを見るとHDD2のトラブルのようです。

ただ、この外付USB RAID HDD、RAID対応ケースに自分でディスクを 組み込んだものなのですが、2012年の暮れにもトラブルを起こし、 結局はケースと付属電源を一式交換する羽目になっています。
今回も同種のトラブルの可能性があり、またこの商品が販売終了と なっていること、及びUSB2.0接続であることから、この際新しい 外付HDDに交換してしまう事にしました。

で、USB3.0接続で2.5inch x 2 でRAID-1の組めるもの、と思って 色々探してみたのですが、国内である程度流通していそうなものとなると ラトックシステムのRS-EC22-U3R ぐらいしか見当たりませんでした。
使われている方がWebに書かれている記事を読んでみても、大きな問題は なさそうです。 いつもの好みで、HGSTの2.5inch HDD (HTS545050A7E680) 2台を手配して 組み込みました。

結果、接続にもファイルアクセスにも問題ありません。これまでのバックアップ運用が復活できました。

先日の対策以降、数日間の昼間は空調なしでの運用となりました。 最寄りのアメダスの観測点の記録を見る限り、外気温が極端に高い日が 1日しかなかったことの影響があるのかもしれませんが、やはり 1〜2℃程度の動作温度の低下があったように思います。

もう少しで一年で一番暑い時期も終わります。今夏の熱対策は、これで 「なんとかなった」で良いのかもしれません。

fitletの発熱状況は随時見ているのですが、どうも漸次的に 温度が上がっていく、あるいは空調をかけた際の最低温度が少し下がらなくなる 傾向が見えていました。ある意味、周囲の熱容量を使い切った側面もあるのかも しれない、と不安になっていました。

そこで、いくつか熱対策を講じてみました。が、残念ながら劇的な効果は ありませんでした。

[上に置いてあるヒートシンクを取り除いてみる]

上に載せてある、ジャンクのヒートシンクが結構熱くなっており、 長時間触っていられない印象でした。ヒートシンクが蓄熱してしまい、 そこからの放熱がうまく行っていないのでは、と思い、 ヒートシンクを取り除いてみました。

[結果]

APU,SSDとも約3℃程度温度が上昇しました。
再度ヒートシンクを載せると、元の温度に戻りました。このヒートシンクは、 載せるだけで約3℃の温度低下効果がある、ということになります。

[BIOSのTDP指定を3000mWにしてみる]

cpupower 等で見てみても、95%程度の時間 APUが1GHzで動作しているので あまり影響はないとは思ったのですが、デフォルトの TDP 4500mW 指定に していた BIOS の TDP 指定を、3000mW にしてみました。

[結果]

負荷監視ツール、munin の毎回(5分ごと)の情報取得を行う munin-update の実行時間が約1.5倍になりました。また、fitlet上の fswikiの動作など、体感でも確実に動作は遅くなりました。
ですが、動作温度には僅かな差しか生じませんでした。せいぜい、 0.5℃〜1℃程度。レスポンス悪化と引き換えにするには小さすぎる効果だと 感じます。結局、BIOS の TDP は 4500mW 指定に戻しました。

[上部のヒートシンクとの間に熱伝導シートを挟む]

fitletの天板の上面には、約8mm程度の間隔で短辺方向に筋状の高さ1mm未満 (目見当で0.5mm程度)のリブがあります。載せているヒートシンクでは、 このリブと「線」で接触しているため、熱伝導シートを挟むことで 「面」での接触にすることで、より熱伝導がスムーズになるのではないか、 と考えました。

入手性の関係で、今回使用したのは ainex の HT-11 (熱伝導率: 13W/m・K)です。 40mm角のものなので、とりあえず2枚使用しています。

[結果]

微妙です。idle時で1〜2℃程度の動作温度低下はあるように思いますが、 そこまで劇的なものでもありません。本体との接触面積が足りないのかも しれません。
ただ、静的に副作用なく1℃下がるのならそれはそれでありがたいので、 とりあえずそのままにして様子を見ています。

fitlet は、Compulab社の超小型PCです。その中でも、 今回導入したfitlet-XA10 LANは、4portのGbEポートを持つモデルです。

これまで使用していた fit-PC2 と 同じ会社の製品なのですが、fit-PC2と異なり、国内の代理店が取り扱って いないようです。Amazon.co.jp にfitletの並行輸入品が出てはいるのですが、 高い上に XA10 LAN は出ていませんでした。

CompuLab社のサイトを見ると、米amazonでも販売しているようでしたが、 確認すると日本への発送は不可でした。

数少ない日本語でのfitletの記事、yaegashi さんの 「ほげめも 最近の買い物: CompuLab fitlet」 によると、昨年 CompuLab社に直接注文して入手されたようです。
私もそれに倣って、CompuLabのサイトから直接注文しました。 入手まで約1週間、価格改定があったのか、 本体 $315 + 日本への配送料 $88 + 国内消費税でした。

[メモリとSSD]

fitlet-XA10 LAN はベアボーンなので、メモリとストレージ(mSATA接続) が必要です。メモリはDDR3L-1600 SO-DIMMの8GBのものを、mSATAのSSDは よくわからなかったので値段の比較的安かった SanDiskの512GBのもの (SDMSATA-512G-G25)を手配しました。

[本体への取付]

ユーザーマニュアルに載っていない部品や手順があるので、 fitPC wikiのfitletのページ を参考にしながら、多少の常識を働かせながら作業します。

fitletの底面のネジを4箇所外した後、FACETカード(GbE 3port)の 中央付近にあるネジを外してから、側板をスライドさせて FACETカードを取り外します。天板は少しスライドさせてから取り外します。

SO−DIMMスロットは上面にあります。mSATAスロットは下面にあります。 SSD用のheatplateがついているので、 Fitlet mSATA Heatplate Assembly を参考にしながら、mSATAを取り付けます。

後は、天板を取付け、FACETカードのLANコネクタを側板の穴とうまく合わせながら 両者を取付け、FACETカードのネジを止めてから底板をネジ止めします。

[OSのインストール]

今回、fitletにインストールするOSは、Ubuntu Server 16.04 LTS にしました。 イメージファイルをUSBメモリに書き込んで、USBメモリからブートし インストーラーを起動。後は画面の指示に従ってゆくだけで、 基本的に問題なくインストールできました。細かなパッケージは 後でインストールすることにして、この時点ではごく基本的なもののみ インストールした状態です。

[試験稼働]

ファンレスの機材だと、どうしても放熱が辛くなります。まずは この状態で机上で試験稼働して、APU や SSD の温度を確認することにしました。

結果、idle状態で APU/SSDとも50〜52℃ぐらい。室温が27〜28℃だったので、 +25℃ぐらいのイメージでしょうか。

本体/SSDとも動作時の温度上限が70℃なので、真夏の室温の最悪値として 40℃を想定し負荷がかかるケースを考えると、ちょっと余裕がない感じです。
本稼働に際し、fit-PC2の時も使っていた PowerMac G4 (QucikSilver, 867MHz)のオリジナルCPUに ついていたヒートシンクに載せ、上部にはこれもfit-PC2の時にも使っていた ジャンクのヒートシンクを載せてみたところ、4〜5℃程温度が下がりました。
また、 Aggressive Link Power Management (ALPM) を参考に(そのままでは動作しなかったので、/etc/rc.local から呼んでいます) して、SSDのALPMを有効にする他、幾つかの対策を施したところ、 負荷監視ツールで見る限り、空調の効いた室温26℃程度の場合には APU/SSDとも 40〜47℃程度、空調の切れた状態の室温30℃程度の場合でも 46〜52℃程度で運用できているようです。室温+15〜22℃ぐらい、といった ところでしょうか。 idle時の温度で見ると、全ての対策の効果を合わせて、おおよそ-10℃分ぐらいの 効果があったことになります。これならなんとか真夏を越せそうです。

いずれにせよ、今後とも監視と調整を続けていきます。

参考URL: Application note - good thermal management of fitlet

家庭内サーバとしてほぼ7年使用していた fit-PC2 の後継として、同じくCompuLab社の fitlet を導入し、家庭内サーバを移行しました。

詳しいことは今後追記してゆきます。