ここは ECS 社の LIVA Z2 上でのLinuxについてのページになっています。
現在利用しているディストリビューションは Ubuntu Server 22.04 です。
なお、このページに書かれている内容は、当方での事例を参考の為に まとめたものであり、内容の正誤も含め無保証です。 当然、このページの内容を基に行われた行為の結果も保証できません。 あくまで自己責任で御願いします。
さて、PN42 の方は純 ubuntu server 機となってしまったので、 Windows環境として LIVA Z2 の方を整備することにしました。
前回の更新から Windows Update をかけていなかったので、 取り急ぎ更新。随分長い時間がかかった後、1つ当たっていなかったので もう一度 Windows Update したら…… Windows で起動しなくなりました。
BIOS(UEFI)から見てみると、Windows の入っている eMMC が認識されて いません。ubuntu server で起動してログを見てみると、デバイスの存在は 認識した後、情報取得に失敗しているようです。
その後、再起動したり一旦電源を落として放置してみたりしても、 状況は変わりませんでした。Windows Update でのアクセスの際に eMMC が破損してしまったことが確定しました。
eMMC は lIVA Z2 のマザーボードにはんだ付けされており、
素人には交換等のできないものです。
落胆しましたが、しょうがありません。
Windows PC としての活用は一旦諦めます。
しかし、「Windows Update したらストレージが壊れた」
のは流石に初めての経験です。
仕事の上でも、Windows Update 後の起動トラブル等は
そこそこ経験してきたのですが、デバイス丸ごとは
直接経験したことはありませんでした。
予備機としての運用を想定したため、外部からの Wake on LAN での起動ができるように設定しました。
LIVA Z2 ではない機種だと思いますが、LIVA シリーズでの Wake on LAN設定について書かれたページを見つけたので、 その記述通りに BIOS 設定。
あとは、QNAP QNA-UC5G1T 経由ではどうやっても WOL が起動しません。 On Board の GbE を有効にして接続し、こちらに WOL の設定を 行ったところ、正常に起動するようになりました。
なお、外部から直接 magic packet は届くようにはしていません。 内部の PC 経由になります。
予備サーバ化に伴い運用に余裕が出たので、 久しぶりに Windows10 で起動して Windows Update する ことにしました。
Windows Update、それも Windows10 のバージョンが上がるような バージョンアップには非常に時間がかかったこともあり、 サーバ運用している間はなかなか踏み切れませんでした。
BIOS設定画面で Boot Manager を Windows のものに切り替え。 起動順も Windows の方の変更して、Windows を起動させます。
ただ、あまりに久しぶりすぎてログインパスワードを忘れてしまっている 為体。秘密の質問をクリアしてパスワードを再設定して、 ようやくログインできました。
ログインして確認したところ、前回のログインは 2021/11。 およそ 2年2ヶ月ぶりの Windows 起動でした。 ちなみに Windows10 20H2。前回の Windows起動時は、 アップデート時間を考慮して 21H2 への更新は 行っていなかったようです。
早速 Windows Update を実施しました。
ダウンロード・インストールに約45分、再起動後の
更新の適用が終わりログイン可能になまで10分弱。
合計で1時間弱程度で 22H2 への更新が完了しました。
あと、すっかり勘違いしていたのですが、 LIVA Z2 の CPU, Pentium Silver N5000 は Windows11 の動作対象となる CPU でした。 Windows Update にも、Windows11 への更新の 選択肢が表示されていました。
ただ、現在メインで使用している USB接続の 5GbE LAN アダプタ、 QNSP QNA-UC5G1T のドライバが Windows10迄の提供で、 Windows11 での提供予定はない旨、メーカーのサイトに 記載があります。
ファイルサーバ役をしている TimeMachine バックアップ時に load avarage が跳ね上がる問題はあったものの、 LIVA Z2 導入時のような気になる問題は他にありませんでした。
ただ、LIVA Z2 自体の導入から丸4年を経過しようとしており、
家庭内サーバの載せ替えの検討は始めていました。
そんなタイミングで、「2024年には NANDフラッシュメモリの
大幅な値上げ。SSDも値上がり必須。」との報道が出てきたこともあり、
どうせなら、ということで家庭内サーバの入れ替えを行うことになりました。
移行先は、ASUS ExpressCenter PN42 です。
詳細はPN42のページで。
今の所、LIVA Z2 は以後 LXDコンテナのバックアップ先及び予備サーバと しての運用を予定しています。
さて、時間が開いてしまいましたが続きです。
今回も、 gihyo.jp の ADMINISTRSTOR STAGE の連載記事、「 Ubuntu Weekly Recipe 」の LXD 関連の記事を参考にしています。
「 第636回 LXD MosaicでLXDをウェブブラウザーから操作する 」を参考にしています。
さて、コンテナではない VM環境の話にはなりますが、 自宅で使っている Parallels Desktop for Mac にしろ、 職場で使っている VMWare にしろ、仮想マシンの管理は GUI で行えます。
コンテナ環境ではありますが、LXD も GUI環境(Web UI)で コントロールできるような仕組みがあります。 上記参考記事で紹介されている、LXD Mosaic 環境を構築して みることにします。
インストール手順は、上記参考ページの手順そのままですので、 省略します。ただ、1点誤記らしきところがありました。
一番手っ取り早いのはプロキシデバイスを設定してしまうことです。たとえばホストの443ポートを，lxdMosaicの10443ポートに転送してしまいましょう。
の箇所で、転送元と転送先のポートが入れ違っています。
(例示されているコマンドの記述の方は合っています。)
「たとえばホストの10443ポートを，
lxdMosaicの443ポートに
転送してしまいましょう。」
が正しいポート番号になります。
あと、手許の環境ではファイアウォールを有効にしているので、 IPv4/IPv6 それぞれで該当ポートを開く必要があります。
まだあまり使いこなせていないのですが、 複数のコンテナの状態を俯瞰して何かを見るのに、特に便利に使っています。
多分一番便利に使っているのは、コンテナを跨っての proxy 設定の一覧でしょうか。lxc コマンドでは コンテナごとにしか確認できないので。
但し、lxc コマンド側でしか確認できない情報もあります。 NAT かどうか、とか。
さて、今回の一連の目的の一つ、LXD のコンテナ内で Docker を 動作させる、です。
導入としては、古い記事なりますが、 「 第459回 LXDを使ってDockerコンテナをマイグレーション 」 を参考にしています。ただ、この記事の3ページ目に出てくる Docker の docker プロファイルは既に廃止されているとのことで、 lxdMosaic の時のようにそのままタイプするだけ、とはいきませんでした。
これも古い記事ですが、 「 LXD上でDockerを動かす方法 」 の Ubuntu 18.04 の 箇所を参考にして Docker 環境を構築しました。 お決まりの hello-world まではこのページの手順に沿って進めました。
さて、このままでは Docker も GUI(Web UI)で管理したいところです。
以前、Impress の PC Watch の
「西川和久の不定期コラ」の記事、
「
Raspberry Pi 4 Model B / 4GB」Part2
～実践編。openmediavaultでNAS化に挑戦! そしてDockerで遊ぶ
」
で知った、
Portainer の無償版(Community Edition)
をインストールしてみました。
インストールの際に参考にしたのは、公式サイトのドキュメントと、
2018年7月の記事ですが、
「
DockerにおけるGUI管理(Portainer 導入編)
」
です。
うちの環境では、lxd の proxy 設定とファイアウォールのポート解放も 行ってあります。
先にテストで作成した、hello-world の dockerコンテナも認識されています。 dockerコンテナの一覧性も高く、もっぱらこちらからコンテナの 起動等を行っています。
なお、時折画面上にバージョンアップを促す表示がされることがありますが、 その表示部分をクリックすると、バージョンアップ手順を含む 情報のある Webサイトが表示されます。うちでは その手順だけでバージョンアップも行えました。
さて、これまた以前ネット上の記事で見て試してみたかった、 iperf3 の docker コンテナでの運用です。
Portainer の中から iperf3 のコンテナイメージを探し、 コンテナを作成します。ただ、そのままだと速度が ホスト上で直接動作させる時より下がったので、
したところ、コンテナ上でもホスト上とほぼ同じ結果が出るように なりました。
今回はここまで。
昨年少し齧り始めていたのですが、諸般の事情で一旦置いておいた LXD に、一念発起して再度取り組みました。
と言っても、動機はそう大仰なものではありません。16GB積んでいる メモリですが、ファイルを大量にコピーするようなことでも なければメモリ使用量はそう多くなりません。 放置しておくのも勿体無いので、有効活用 しようというのがまず一つ。あとは、LXDは比較的「軽い」らしいので、 Pentium Silver N5000 という非力目な CPU であっても、 ある程度実用的な動作をするのではないか、という期待を込めて、でした。
もちろん、Docker あたりのコンテナ技術の理解を、食わず嫌いを含めて 怠っていて、頭の体操を兼ねて触ってみようというのもあります。 さらに、Docker 環境を LXD のコンテナ内に構築することも可能と いうことで、この手の実験/学習用環境を実運用環境から 切り離して建てられる、というのも魅力でした。
設定ミスとかで設定ファイルをぐちゃぐちゃにしてしまっても、 最悪コンテナごと消してしまえば以前の状態に戻るはず、 というのは安心感があります。
参考にしたのは、ほぼほぼ gihyo.jp の ADMINISTRSTOR STAGE の
連載記事、「
Ubuntu Weekly Recipe
」の LXD 関連の記事です。やや古い記事ではあるのですが、
「
第521回 入門システムコンテナマネージャーLXD 3.0
」以降の記事を参考にしています。
記事との相違点は、大凡以下の通りです。
さて、始める前に LIVA Z2 の環境を一部いじります。
うちでは、それこそ OpenBlockS266 の頃から、 内蔵ストレージは比較的細かくパーティションを分けて 運用してきました。fit-PC2 から LIVA Z2 に移行する際、 パーティションの分け方も大凡踏襲し、ストレージが 512GB->1TBになったので、それぞれ少しづつ増やしたぐらい。 残りは /home 用のパーティションにまとめて割り振っていました。
で、LXD は標準では /var 以下にファイルを作成します。 元の割り当てでは 10GB しか割り振っていなかったので、 流石に容量が足りません。そこで、以前から使っている GParted を使ってパーティションを切り直すことにしました。
たまたま、最終パーティションが /home 用のパーティション、 その直前が /var 用のパーティションだったため、
といった手順で作業しました。/var に 10GB, /home に 800GB強の 割り当てだったものを、/var に 500GB, /home に 300GB今日の割り当てに 変更しています。
さて、次は初回の設定です。
今回は、「 第521回 入門システムコンテナマネージャーLXD 3.0 」での内容通り、
sudo lxd init
での初期値で設定しました。ストレージバックエンドは btrfs をループバックイメージファイルで利用する形のままに しています。サイズはとりあえず 100GBで。
足りなかったらコマンドでいろいろやれば拡張できるようなので。
こちらも参考ページの記載を元に、ubuntu 20.04 を指定して、
lxc lanunch ubuntu:20.04 (インスタンス名)
でインスタンス生成と起動を行います。イメージがまだダウンロード されていないので、リモートからコンテナのイメージもダウンロード されます。
なお、ダウンロードされtイメージはキャッシュされ、更新も行われます、
lxc exec (インスタンス名) bash
で、管理者権限のアカウントでログインしたような状態になります。 普通にコマンドも使えて、CLI環境にログインしたのと変わりません。 また、exit コマンドで普通に抜けられます。
なので、本当に普通に別のサーバ環境が出来上がってしまっています。
ただ、このままだと LIVA Z2 以外の環境から インスタンスと 通信することができません。コンテナ内で建てたサーバと外部との間で 通信するためには、例えば プロキシデバイスを設定してあげる必要が あります。
lxc stop (インスタンス名)
でインスタンスが停止します。
また、インスタンスが本当に不要になれば
lxc delete (インスタンス名)
で、インスタンスが削除されます。
なお、インスタンスの作成に使用したイメージは、このコマンドでは
削除されません。
とりあえず今回はここまで。
2021年1月の首都圏への緊急事態宣言の折、自宅環境に 新たに EIZOの4Kモニタ、FlexScan EV2785 を導入しました。 導入の経緯等は うちのMacintoshたち のページで見ていただくとして、LIVA Z2 の接続モニタも EV2785 に切り替えたのですが、うまく表示されませんでした。
これまでの FlexScan S1910HR へは、HDMI→DVI-D変換コネクタを介して 接続していたのですが、EV2785 は HDMI入力が可能なので 新たに購入した HDMI ケーブルで直結しています。
モニタ側の素の解像度が高すぎてうまくいかないのかも、 とは思ったのですが、モニタ側から見ればあくまで デバイス側から送られてきた信号に合わせて表示しているだけ。 地デジ/BS・CSチューナからは正常に表示されているので、 コネクタ不良を疑って差し替えてみましたが、状況は 変わらず。古めの機材を通せば解像度が限定されるかと重い、 以前入手していた外部電源レスのHDMI切り替え機を通してみましたが、 状況は改善できませんでした。
手持ちの機材に、Sonyのサラウンドヘッドホンシステム、 MDR-DS7500 があります。こちらは、 映像ソースとTVの間に挟み込む形で接続するのですが、 複数のソース入力に対応し切り替え機能もあります。 リリース時期的に HD想定の機材なので、これを間に挟めば HDの解像度が強制されるのではないか、と考えました。
やってみたところ、予想通りHD解像度で画面が表示できました。 サラウンドヘッドホンシステムとしての運用としては、 MacBook 上で動作させた Bluelay Player Pro の出力を HDMI経由で入力し、今回からは EV2785 に表示することに なります。映像ソースの切り替え操作にうまくハマるので、 LIVA Z2 の画面表示が必要な場合は、この結線で行くことにしました。
根本的な対策としては、なぜ直結ではうまく表示されないのか、 HDMI の表示の際のネゴシエーション等について調べる必要があります。 そこは今後の宿題ということにしておいてください。
外付USB-RAID HDD として運用している、 RATOC SYSTEM の HDDケース、RS-EC32-U31R に内蔵している WD Red シリーズの 8TB HDD, WD80EFZX の運用期間が3年を超えました。 WD Red シリーズは NAS向けとされているシリーズで、保証期間は3年 です。S.M.A.R.T.情報を見る限り特段障害が発生するような予兆もない のですが、保証期間を超えたために予防交換を行うことにしました。
本来なら、WD Redシリーズの 8TB の現行モデル、WD80EFAX が 候補に上がります。容量も全く同一で、1本づつ差し替えることで おそらく RAID-1 のリビルドで済み、時間こそかかれ移行の手間や ダウンタイムは最小で済みます。
ただ、WD80EFZX がヘリウム封入モデルであったのに対し、 WD80EFAX はヘリウム封入モデルではありません。そのせいなのか 価格は WD80FFZX の購入当時の価格より安価なのですが、 動作時の温度がかなり高くなる傾向があるようです。
詳細な環境は不明ですが、ファンのあるPCケースに内蔵して 動作時温度が50℃前後、という情報を見かけました。
うちの稼働状況では、動作温度が高いのは致命的です。
やむなく、他社製も含めて交換用のHDDの候補を見繕うことにしました。
例によってダラダラと続くので、最初は非表示にしておきます。
選定の際の基準は以下のようになりました。
また、現在 3.5inch HDD のメーカー及びNASあるいは24時間連続稼働向け のHDDのシリーズとしては、以下のようなものがあります。
※ 保証期間は国内代理店扱いのモデルの例。バルク品だと1年とかのことが多い。
この中で価格が合うものの中から、容量が8TB以上でかつ 比較的静かで発熱が少なめ、信頼性の高いもの、 といったあたりで選びたいところです。
動作音については、「耳障りな音かどうか」といった音の質の部分は データシートからは読み取れないので、Internet上での レビュー等が頼りになってしまいます。発熱については、 データシートの消費電力を主に参考にしています。 もちろん、Internet上のレビューもある程度参考になりますが、 設置状況やケース内の他の熱源、冷却状況等により変動するものなので、 数を読み込んで想像・分析する必要があります。 信頼性については、全モデルの情報が有るわけではありませんが、 アメリカのデータセンターが公開している四半期ごとの障害発生状況と Internet上のレビュー等を参考にしています。
後は、前回もヘリウム充填タイプだったので、今回もそちらから、と 行きたいところなのですが、以前はヘリウム充填モデルであることを セールスポイントにしていたように思うのですが、最近はそうでも ないようです。同シリーズの同容量の製品であっても、 モデル切り替え時にヘリウム充填→従来の空気のモデルに 変わっていることもあります。
先に挙げた各社のモデルを 1TB辺りの単価で見てみると、
大きく2つのグループに分けられます。
2,500.-/TB辺りのグループ(IronWolf, WD Red, MNシリーズ)と、
4,000.-〜4,500.-/TB辺りもしくはそれ以上のグループ(上記以外)です。
保証3年と保証5年のグループにもなっており、メーカー側の
製品の位置付け/販売戦略もそう分かれているのでは、と思われます。
さて、動作温度の見込みとなる消費電力です。各社の製品の データシート(場合によっては英語版)を眺めてみると、 平均消費電力あるいはActive/Idleでの消費電力が10Wを超えるようなもの、 7〜9W 辺りのもの、 6W台(あるいはそれ以下)のものとに分けられるようです。
| メーカー | シリーズ |
消費電力 (平均、あるいはActive/Idle) |
備考 |
|---|---|---|---|
| Seagate | IronWolf | 7.8〜8.8 | 8TB以上のモデルの値 |
| IronWolf Pro | 7.6〜8 | ヘリウム充填 | |
| Exos E | 12.81 | Exos 7E8 8TBモデルの値 | |
| Exos X |
7.8 8.0〜8.4 |
Exos X12モデルの平均、 及び Exos X10モデルの最大書き込み/読み取り |
|
| Western Digital | Wd Red |
6.3〜6.5 8.4〜8.8 |
12TB・14TBモデル(ヘリウム充填)と 10TB・8TBモデル |
| WD Red Pro |
5.7〜6.2 8.4〜8.8 |
12TB以上のモデル、10TBのヘリウム充填の旧モデルと 10TB/8TBの空気充填モデル |
|
| WD Gold |
6.0〜6.9 8.8〜9,2 |
12TB以上のモデルと 8TB/10TBのモデル |
|
| Ultrastar |
6.0〜6.9 8.8〜9,2 |
14TB/12TBのモデルと 8TB/10TBのモデル |
|
| 東芝 | MNシリーズ |
6.49〜6.91 7.88〜9.6 |
12TB〜16TBのモデルと 10TB/8TBのモデル |
| MGシリーズ | 7.63〜8.09 | 16TB/14TB/12TB のみ |
ちなみに、これまで使っていた WD80EFZX では 読み取り/書き込みで 6.4W (データシートによる)となっていましたから、7W以上のものだと 発熱が心配です。なのでそれ未満ということになると、
に限られてくることになります。事実上、ヘリウム充填モデル のみ、ということになりました。
さらに、コスト面からも絞り込みます。消費電力からの 絞り込み結果のうち、WD Red Pro, WD Gold, Ultrastar の 各モデルは、TB辺りの単価の高いグループで、私が手配可能な 入手先での価格が1本6万円を超えてきています。RAID-1で 2本必要なこともあり、流石にこれは導入に踏み切れません。
残る WD Red の 12TB/14TB, 東芝 MNシリーズの 12TB/14TB/16TBも
容量が大きくなれば高価になります。入手可能な手配先での金額が、
WD Red 12TB が 約3.3万円、14TB が 4万円強。
東芝 MNシリーズ 12TB が約3万円、14TB が 約3.6万円、16TB が約4.5万円、
といったところでした。
これまでが 8TB であったこともあり、候補の中では最小容量の 12TB で十分です。WD Red 12TB と 東芝 MNシリーズ 12TB に 絞り込みました。
Internet上のレビューを探してみたのですが、WD Red の 12TB の ものはあまり見つかりません。東芝の MNシリーズの 12TB のものは 多少見つかりますが、「静か」だというものと「Seek時にうるさい」 というものが混ざっています。ただ、動作温度があまり高くならない、 というのは共通していました。
モデル特有の障害情報も見つからなかったこと、及びこれまで 使用して来た WD Red WD80EFZX では BMS(Background Media Scan) で数秒おきにアクセス音がしたりしていたことから、今回は 東芝の MNシリーズの 12TBモデル、MN07ACA12T/JP を選定しました。
東芝のMNシリーズの 12TBモデル、MN07ACA12T/JP ですが、 たまに使う通販サイトで在庫ありになっており、秋葉原店頭の 最安値とされる価格とほぼ同等でした。早速手配して 即日の発送となりました。
なお、この通販サイトでは、現在は商品自体の取り扱いが なくなっています。ちょっと嫌な気分にならなくもないですが。
さて、RATOC SYSTEM の HDDケース、RS-EC32-U31R は、容量の大きな HDDに入れ替える場合、リビルドでの対応ができません。FAQでも、 「一旦バックアップを撮った後、HDDを入れ替えてRAIDを構築し リストアしろ」となっています。
なので、手持ちの Micron 1100 SSD(2TB)や Crucial MX500(2TB)、 LIVA Z2 に内蔵している SSD の空きエリアを使用して載せ替えを、 と考えていました。
TimeMachine バックアップ部分は MacBook Pro から、
他の smbファイル共有部分は LIVA Z2 の ubuntu 上から
問題なくバックアップできたのですが、LIVA Z2 の バックアップ
部分のバックアップに手間を撮られました。
Micron 1100 SSD をUSB-SATA変換アダプタ経由で LIVA Z2 に繋いで
バックアップを、と思ったのですが、エラーを生じます。
結局原因は判明したのですが、今回のバックアップ時点では 解決しておらず、その他のデバイスの空き容量を駆使して バックアップしました。ただ、rsync系のバックアップのコピーには 非常に時間がかかってしまい、TimeMachine や LIVA Z2自体の 日常のバックアップが数日止まってしまう羽目になりました。
箇条書きにします。
前回の記事に書いた、LIVA Z2 の発熱対策ですが、大凡期待通り (もしくは期待以上)の結果になったようです。
設定変更後、うちの辺りで気温が高かった9月途中までの期間、 munin による 5分毎のログから推測すると、
といった結果になっています。
純粋な室温の測定記録を取っていませんが、 在室時に見た最寄りの気温測定点と室温との違いを考慮すると、 該当期間の最高室温はおそらく35〜36℃辺りだったと 推測します。 事前想定の室温 40℃のケースより 4〜5℃低かったことになりますが、 それを考慮に入れて、
もちろん、munin での 測定が 5分間隔のため、スパイク状に 高負荷/高温が生じている可能性はありますが、 CPU の方は負荷が下がった際の温度低下も迅速であることを見ていますし、 SSD の方は SMART情報での温度記録の最高が(今回の対策前も含めて) 61℃。Crucial MX500シリーズの動作上限温度 70℃にはまだゆとりがあります。
結論として、今夏の発熱対策は十分な結果が得られた、と言えるでしょう。 少なくとも、来夏以降もこの設定で運用するつもりです。
あとは冬場、室温が低い時に省電力設定を行わないようにするか、 でしょうか。
冬場は夏場とは逆に空調を入れた際の温度の状況を見ながら、と 言うことになりますが、通常20℃台前半〜半ばの室温です。 powertop による省電力設定なしでも運用温度に問題はなさそうですが、 設定を切り替える手間が生じはします。
省電力設定でパフォーマンスやレスポンスは多少低下しているとは 思うのですが、それが気にならなければこのままの設定で運用 してみようかと思っています。
8月に入って、今年はいよいよ夏本番と言うべき最高気温になってきました。 例年暑くなってくると在宅時にはエアコンをかけているものの、不在時には 切っています。酷暑を迎える前に、LIVA Z2 の動作時の温度対策を行うことに しました。
以前にも書きましたが、munin の 5分間隔での測定では、以下のようになっています。
これに、酷暑時かつ空調なしの(上目に見積もった)室温想定 40℃ を 考え合わせると、
となります。
CPUの方の動作温度上限、Tjunk は 105℃ なのでまだ数字上での ゆとりはありますが、 munin の 5分間隔の測定のため、スパイク状に高負荷/高温が生じていると 上限にかなり近づく、あるいは上回ってしまう可能性があります。
SSD の方はより深刻です。Crucial MX500シリーズのデータシートでは、 動作温度の上限は 70℃とされていますが、 現時点での想定ですらギリギリで全くゆとりがありません。
また、直接の因果関係は調べがついていないのですが、 そもそも(体感でも温度計の表示でも)他の部屋より室温が高いことも 気になるところです。LIVA Z2 以外にも発熱している機材は有るとはいえ、 LIVA Z2 の発熱が室温に影響を与えているレベルなら、 どうにか対策してしまいたいところです。
fit-pc2 や fitlet の頃、発熱対策のための省電力の設定を行なっていました。
powertop というコマンドを利用するものです。
Linuxで動作しているノートPCで、稼働時間を伸ばすために
不要なデバイスや機能を無効にして消費電力を削減することが可能です。
消費電力削減という意味では同じことなので、今回も powertop で
省電力の設定を行うことにしました。
sudo powertop
で powertop を起動し、対話的に使用した場合、 powertop から見て省電力設定が行われている/行われていない 項目をそれぞれ表示し、個別に設定が可能です。 また、
sudo powertop --auto-tune
とすることで、powertop のおすすめ設定を一括して行うことが可能です。 再起動すると元に戻ってしまうので、毎回起動時に実行されるよう 設定する必要があります。
うちの場合、ネットワーク共有周りで調査中の事柄があったため、 QNAP QNA-UC5G1T に関連する省電力設定のみは行わないように したため、powertop --auto-tune ではうまくいきません。 powrtop --auto-tune 実行前後の設定状況をそれぞれ
sudo powertop --html=<保存するファイル名>
で保存。実行前後で変わっている部分を diff コマンドで調べて
/etc/rc.local に追記し、起動時に実行されるようにしました。
# うちでは、未だに /etc/rc.local が起動時に実行されるように
してあります。楽なので。
この設定により、munin の5分間隔での記録で、
の効果が見られました。先の室温40℃想定時の温度の見積もりに反映すると、
となります。CPUの方はこれだけ Tjunk までのマージンがあれば おそらく大丈夫でしょう。SSDの方も、とりあえずは 10℃分ぐらいは マージンができたことになるので、少しは安心できます。
設定後のパフォーマンスも、実運用の体感上は大きな問題は感じなかったので、 少なくとも気温が高い間はこの設定で運用することにします。
MacBook Pro + Sonnet Solo 10G Thunderbol2 Edition と LIVA Z2 + QNAP QNA-UC5G1T との間を、Buffalo LXW-10G2/2G4 経由で 接続したところ、MacBook Pro -> LIVA Z2 側の通信だけ 速度が遅くなる症状が出ていました。
色々と調べた結果、macOS の AQC107 のドライバに原因が あるのではなかろうか、ということになりました。 その調査中、QNA-UC5G1T 側に原因がないかを調べていた最中、 Ubuntu 18.04 の HWE kernel が 5.3.0, 20.04 の kernel が 5.4.0 であることから、何かよくなるかも知れないとの期待を込めて Ubuntu Server 20.04 にアップグレードすることにしました。
検索で引っかかった、 【Ubuntu 20.04 LTS Server】Ubuntu 18.04 LTS Server からアップグレード を参考に、ほとんど記載のままの手順で進めました。
うちの環境で手間がかかったのは、大凡以下の3点です。
18.04 の頃は、QNA-UC5G1T には MACアドレスを元にした interface名がついていました。20.04 になったら、普通に eth0 に なったので、netplan の設定ファイル内の interface名部分を 変更しました。
アップグレード途中での選択肢を誤ったのか、いくつか削除された プログラムがありました。いざ使おうとしたらなくなっていたので、 気づいた時点で再度インストールしています。
なお、最初に気づいたのは locate コマンドがなくなっていたことでした。
以前に自分でコンパイルして使っていたバイナリの中に、動かなくなるものが 発生しました。調べてみると、libssl1.0.0 がなくなり libssl1.1 のみに なったためのようです。
同種のトラブルに見舞われた方は他にもいらしたようで、 Ubuntu 20.04のインストール を参考に、18.04 の libssl-1.0.0.deb パッケージをインストールして 当座の回避をした上で、素のバイナリを、libssl 1.1 で動作するようビルド し直して対処しました。
libssl 1.0.0 と 1.1 では、構造体のメンバへのアクセス作法とかが 変わっており、場合によってはソースコードの変更が必要とのことでした。 今回問題となったプログラムでは、libssl のごく一部の機能のみ 使用しており、その範囲ではコード修正の必要はないようでした。
導入後全く手をつけていなかった、プリインストールの Windows10 Pro 環境 ですが、ファームウエアの更新確認も兼ねて一度起動してみることにしました。
ですが、先ににプリインストールされている eMMC をフルバックアップしておくことにします。
まず、普段は eMMC を無効にしてあるので、BIOS設定画面で
eMMC Support を Enable にし、OSから見えるようにします。
Ubuntu Server 環境からは、/dev/mmcblk0 に見えていました。
バックアップ自体は、ddコマンドでイメージファイルへの保存としました。
dd if=/dev/mmcblk0 of=/path/to/backup.image bs=16M
といった感じで実行しました。ちなみに、バックアップしたイメージファイル のサイズは約57.7GiB(約61.9GB)でした。
さて、バックアップを取ったので、次は Windows10 Pro 環境の初回起動と Windows Update 等です。
BIOS の Boot設定で、内蔵SSDより eMMC の優先順位を上げて、eMMC から 起動するようにした方が良いでしょう。
こちらでは、設定変更を面倒臭がって、 起動時に F7 キーを押して設定する、一時的なBootデバイス変更で 行なってしまいましたが、後の Windows Update の際に逆に手間でした。
Windows10 Pro の初回起動時のアカウントの作成や諸々の設定を行なって 起動します。確認したところ、Windows10 Pro の v1809 でした。
そこから、v1809の最新になるまでに Windows Update(+再起動) を 2回、さらに v1909への更新で長時間のダウンロードと複数回の 再起動が発生しました。正味時間の合計で3時間半強。ほとんど 半日仕事になってしまいました。
この、v1909 へのアップデートの際、自動で何回か再起動が 行われるのですが、再起動するタイミングでの特段の表示は ありません。画面が暗転して再起動するだけです。 先述の、F7キーによる一時的な Bootデバイス変更では、 この再起動の際も F7キーを押しての操作が必要です。 そのため、画面に張り付いている必要がありました。 また、v1909へのアップデート処理中には、再起動しないけれど 短時間の画面の暗転が何回かあったので、 F7キーを押すべきかどうかの判断もシビアと言えばシビアでした。
いずれにせよ、ただ最新版に更新するだけでこれだけ時間がかかると いうのは、趣味の道具としてはちょっと悩ましいところです。 OSの更新中もPCは(多少パフォーマンスは下がるにしても)普通に 使えて、バックグラウンドで更新が行われ、再起動したら 最新版になっている、とかになると良いのですが。
一応、今の Windows10 では、バックグラウンドで更新ファイルの ダウンロード+αまで行い、事前に設定しておいた「使用していない時間帯」 に再起動+残りの更新、という仕組みまでは実装されています。
ですが、更新時に何かエラーやトラブルが生じた際の対応が難しいので それに頼るのを躊躇するところではあります。 Windows10 Pro ではないのですが、 先日職場の Windows Server マシンで、Windows Update をかけると 実は更新に失敗しており、起動にも更新の自動切り戻しにも失敗して 延々と再起動し続ける、なんていうこともありましたし。 ちなみにその原因は、Microsoft のバッチファイルかその構成の バグだったようです。
さて、ようやく今回の目的であった、LIVA Z2 の BIOS の更新確認です。 プリインストールされている専用ツール、eBLU を起動して確認したところ、 最新の BIOS だと表示されました。
合わせて、driver の更新支援ツール、eDLU も起動して driver の 更新を確認しようとしましたが、こちらはうまくいきません。
ECS社のサイトのダウンロードページをWebブラウザで開き、driver を 表示しようとするのですが、検索キーを機種名ではなくマザーボード名 (GLKM-MINI)としてしまうため、該当する driver を見つけられないようです。
キーワードとして LIVA Z2 を指定して driver を確認できますが、 最新かどうかの判定が悩ましいところです。Webサイトの driver の バージョンと、インストールされているどのファイルのバージョンを 比較すれば良いのか……。 今回は、Windows Update に時間を取られすぎたこともあり、driver の更新確認については次の機会とすることにしました。
なお、eBLU, eDLU 自体の更新も確認しましたが、いずれも最新でした。
Windows10 Pro 上でデバイスのプロパティから見ると、 総容量 56.5GBで、v1909への更新後の空き容量は 19.4GB と なっていました。今すぐどうこうということはないのですが、 Windows10 Pro で運用される場合、将来的には Windows Update や 新バージョンへの更新の際に空き容量の問題が生じる可能性がありそうです。
内蔵SSDや外付ストレージの増設を強くお勧めしますし、 可能なら増設した内蔵SSDヘのOSの再セットアップを お勧めしたいところです。
さて、ようやく一段落したので Ubuntu Server 運用へ復帰させます。
誤って破損させないよう、BIOS設定で eMMC Support を Disable に 戻しておきます。また、Boot設定を変更していた場合は元に戻します。
eMMC についてあまり詳しくないのですが、SSDで言われているのと 同様、もし長時間通電しないと内容が消えるようなら、 たまには Enable にした上で内容を確認した方が良さそうですね。 まあ、そうであるなら Enable にしたままにするのが一番楽そうですが。
後は再起動して、いつもの環境に戻っていることを確認しました。
この辺り に書いた、家庭内サーバを入れ替える件です。至急、新しいサーバの 機種選定を行うことにしました。以下、だらだらとうちでの個人レベルでの 機種選びの過程を書きましたが、蛇足気味なので最初は非表示にしておきます。 つまらなくても中身が薄くても構わない方だけご覧ください。
さて、新しい機種の条件ですが、
と言ったあたりになります。
最初の条件は当然ですね。今回のサーバ入れ替えの理由そのものです。
サイズについては、設置場所の都合です。ただ、fitlet の設置面積は この手の製品では最小クラスだと思うので、現状よりある程度のサイズの 増大は許容しないと機種選定といえるほどの候補が集まりません。
ファンレスについては、OpenBlockS266 導入以来の16年以上の実績、 と言ったところでしょうか。可動部分がないのはやはり強いです。
x64なのは、既存環境をできるだけそのまま移行したいから、という 意味合いです。
「Ubuntu が動作する」というのは、メーカー/代理店の表記あるいは ネット上での動作の事例を探してみる、という意味合いです。
全ての条件を明確にクリアする機種が少ないであろうことから、 とりあえずざっくりと候補を拾い集めてみることにしました。
あたりまで予算面を見ながら一旦手を広げてリストアップしてみました。
個人の判断と好みで絞り込みました。
まず、Atom系だと Apollo Lake 世代は避けることにしました。
「Apollo Lakeが長期稼働で信号劣化し品質基準を満たさず。ステッピング変更へ」(Impress PC Watch)
「大幅に価格を下げたCascade Lake インテル CPUロードマップ 」(ASCII.jp)
に書かれている問題点が気になったので。もちろん、1世代前で、さらに 次世代のリリースも噂されていますから、おそらくすぐに2世代前になって しまうことも考慮しました。
なお、この条件で Compulab社の fitlet2 は除外することになりました。
以前から色々眺めていた機種ではあったのですが……。fit-PC2以来10年半
同社の製品にお世話になってきたので、ちょっと寂しくもあります。
また、この時点で NASメーカーのNASもほぼ除外となります。 機種選定時には、予算を考慮すると CPU が ARM 系か Atom の Apollo Lake のものが殆どでした。つい最近、Gemini Lake のものが 発表されたりしていますが。
次にサイズ面。設置場所を見ながら、置いてみたらどうなるか、 ケーブル類の取り回しは大丈夫か、と色々想定してみました。 結果、小型ベアボーンはちょっと無理、スリムPCだとサイズと置き方次第、 と言ったことに。この時点でリストに残っていたスリムPCが、 サイズオーバーかCPU性能が低めのものだったため、実際にはこちらも 除外となりました。
最後に、空冷ファンのあるものについては、動作音が気になるとの情報を 見つけたものは避けることにします。
この時点で、実は残った候補は3機種になっていました。 ECS社のLIVA Z2 と Intel NUC の NUC7PJYH, NUC8I3BEH です。 ファンレスなのは LIVA Z2 のみ、LIVA Z2 と NUC7PJYH は CPU が Gemini Lake世代, NUC8I3BEH が 第8世代の Core i3 です。 外部IFも、LIVA Z2 と NUC7PJYH は似たり寄ったりですが、 NUC8I3BEH のみ Thunderbolt3 や USB 3.1 gen2 が備わっています。
あえて分ければ、NUC8I3BEH が(CPUの性能やTDP, 外部IF等を考えると) 別ランクの製品で、LIVA Z2 と NUC7PJYH は事実上の類似製品、という ことになるでしょうか。
この3機種、どれを選ぶか相当悩みました。ネット上でのレビューや事例も 相当探してみましたし、どの機種でも今回の家庭内サーバ入れ替えの目的は 達成できそうです。結局、最後は「発熱(TDPの小ささ)」「ファンレス」が 決め手になり、LIVA Z2 を選定しました。
LIVA Z2 は、ECS社の小型ファンレスPCです。CPU/メモリ/OSの種類で複数のモデルが ありますが、今回手配したのは CPU が Pentium Silver N5000 のモデル、 LIVA Z2 (N5000) 64G (国内代理店の商品情報ページ) の、メモリ 4GB/Windows10 Pro のモデルです。
Windows10 Pro 環境は常用する予定はないのですが、 ファームウエア/ドライバ更新が Windows環境のみで、プリインストールで 専用ツールが入っているとのこと。 もし利用する場合はリモートデスクトップ接続できた方が楽なので、 こちらを選択しました。
メモリについては、増設前提で4GBのモデルを選択しています。 なお、Intel公式では、Gemini Lake の CPU のメモリ上限は 8GB とされて いますが、ネット上には 「非公式かつ未確認だが、メモリを選べばおそらく32GBまで認識する」 との情報がありました。また、GeminiLake 世代のCPUで 16GB以上のメモリを 使用した事例も見つけたことから、Crucial の DDR4 2400 SO-DIMM の 8GBx2 のメモリを手配しました。もしうまく認識されないなら、8GBx1で運用する つもりでした。
なお、今回のモデルは内蔵の 64GB のeMMC に Windows10 Pro が プリインストールされていますが、そこには手を付けずに、 別途内蔵する 2.5inch SATA SSD に ubuntu server をインストールする 目論見です。こちらも、最終的には衝動買いで Crucial MX500 の 1TBモデル を手配しました。
実はこのシリーズのSSDの発熱が多めかもしれないことを失念していました。 NANDを製造しているメーカーのブランドなので、販売経路が怪しくなければ 偽装品や部品の素性の怪しいものをつかまされないであろうことは 安心なのですが。
到着した LIVA Z2 を開梱し、セットアップします。
天地をひっくり返して底面の止めネジを外し、底面(後面と一体)を、 後面のインターフェイスのコネクタとの引っ掛かりに気をつけながら外します。 開いたところには 2.5inch SATAベイがありますが、これは フレーム側面と嵌め合わせてあるだけで、ねじ止めされていません。 細いリボン状のSATAケーブルの扱いに気をつけながら 2.5inch ベイを 外します。
(見慣れないのでちょっとロゴの表記が読み取りづらかったのですが) Ramonster ブランドの 4GB メモリがついていました。調べたところ、 台湾 TERABYTE 社 のブランドのようです。同社のサイトの言語表示を英語にしてみても、 コンテンツは英語にならないようで、詳細は調べきれていません。
2.5inch ベイの両サイドが結構キツめで、SATAコネクタにセットするのも サイドを気にしながら行う必要があります。9.5mm厚を想定した作りで、 7mm厚のデバイスの場合そのままだとコネクタでの片持ち支持のような 状態になります。ベイの両サイドがキツめなので、運用できなくはないと 思いますが、安定させるにはスペーサーを噛ませるか、別途用意した 2.5inch SATAデバイス用固定ネジ2本で、片側のみ固定する必要があります。
2.5inchデバイス固定用のネジは付属していません。また、ネジ用の 穴があるのはで片側だけです。
あとは、SATAケーブルに気をつけながらコネクタ/ベイを 元の位置にセットします。
開いた時の逆の手順で閉じます。後面のインターフェイス との 嵌め合わせに気を使いながら、丁寧に合わせ、ねじ止めします。
最初は、fitlet で使用していた mSATA の内容を、Gpartd を 使ってうまくコピーして完了としてしまおうと思っていました。 実際にそのように作業してみたのですが、起動できません。
後になって考えてみれば当然なのですが、fitlet は BIOS 起動、 LIVA Z2 は UEFI 起動です。後から UEFI boot 用パーティションを 追加してみてもうまくいかず、結局は ubuntu server 18.04 を 再インストールし、データのみ移行することになりました。
isoイメージを書き込んだUSBメモリから起動してインストール。 パーティションサイズを多少変更し、残りは全部 /home に追加する 形でインストールしました。また、kernel は 5.0.0 にしています。
流石にこれなら普通に起動します。eMMCとの起動順の設定だけは 気をつける必要がありますが。なお、現時点では eMMC は UEFI の 設定で無効にしてあります。
あとは、fitlet の mSATA からデータ等を移行し、環境設定については fitlet の環境構築時のメモを見ながら順次再現。一番問題だったのは、 ネットワーク設定が netplan に変わっていたこと。設定しても 思うように動かないことも生じましたが、その度にインターネットで 検索してみたら、何処かでは情報が見つかりました。
結局、2020.1.12には、おおよその設定を終えて家庭内サーバとして 稼働させることができました。
まず、サイズが大きくなりました。設置面積で約1.7倍、 (fitlet heatsink抜きのサイズとの比較で)容積比で約4倍です。 ただ、fitlet がいくら小さくてもケーブルの取り回しに必要な スペースはどうしても必要だったので、その範囲まで考慮すれば そこまで大きくなってはいない、という実感です。 容積比の方も、fitlet heatsink 付きの状態に外接する直方体サイズ との比較なら約2.1倍。それぐらいのサイズ増大で済んだ、というのが 正直なところです。
性能面ですが、dhrystone-2.1で、fitlet(TDP 4500mW)の 約2.8倍、TDP 7000mW の場合の約1.9倍の結果となっています。 また、
openssl speed -evp aes-128-ctr
の結果だと、fitlet(TDP 4500mW)との比較で、約3.2倍の結果が出ています。
現時点では一番気になっているところです。CPUについては、アイドル時で 室温+30℃、過去のピークで室温+45〜46℃といったところです。このCPUの 動作上限 Tjunk が 105℃なので、CPU自体の動作温度には真夏の室温を 想定してもまだ余裕がありますが、 周辺回路等まで含めてどうかは運用してみないとわかりません。
内蔵SSDですが、こちらはアイドル時に室温+20℃前後、ピーク時で 室温+30℃弱となっています。Crucial MX500 シリーズの動作温度の 上限は 70℃ なので、ゆとりを保つためには夏を迎えるまでになんらかの 対策を考えておきたいところです。
さて、今回のサーバ入れ替えの直接の原因となった、iperf3 による 通信速度のテストです。前から見て左端のUSB3.0ポートに QNAP QNA-UC5G1T を接続し、LXW-2G5とはCAT6のケーブルで接続。 MTUは9000としています。MacBook Pro 側は、MTUのみ 9000 に変更しました。
結果、MacBook Pro <-> fitlet どちらの方向でも、2.47 Gbits/sec を 記録しています。ほぼ 2.5GbE の規格の速度が出ている状態です。
費用も手間も一時期の試行錯誤の苦労もありましたが、最終的には なんとかなった、という感じです。
MacBook Pro が SONNET Solo10G Thunderbolt2 Edition を使用する事に なったため、LIVA Z2 の QNAP QNA-UC5G1T と直結する事で そこだけは 5GbE での運用を行う事になりました。
で、向こうのページにも書きましたが、 MacBook Pro と LIVA Z2 については、常時 5GbE と GbE 両方の インターフェイスでネットワークに接続する、(広義の)マルチホーム運用を 行う事になりました。
5GbE と GbE、両方のインターフェイスを利用できるようにするのは 比較的簡単です。これまで使用していなかった GbE のインターフェイスに これまで QNA-UC5G1T が使用していた IPアドレスを割り当て、 ゲートウエイもこちらにしておきます。QNA-UC5G1T には MacBook Pro の Solo10G と同じセグメントの固定IPアドレスを付与し、 ゲートウエイやDNSの指定は「なし」にしておきます。
MacBook Pro の macOS 側のネットワーク設定も合わせて行い、 MacBook Pro から LIVA Z2 への通信は全て 5GbE 側で行えるように なったので、問題はないように思えたのですが……。一点だけ。 LIVA Z2 上で MacBook Pro の名称解決を行うと、5GbE 側ではなく GbE 側の IPアドレスが返される事に気づきました。 もちろん、それが間違っているわけではないのですし、通信ができない 訳でもないのですが……。
現状、LANでの名称解決は Bonjour/Avahi で行っています。 これらは、今回のようなネットワーク環境での運用を想定していないようで、 確実に動作させるためには自前で LAN上の DNS を運用する必要があるよう です。もちろん、やって出来なくはないのですが DHCP との絡みもあり、 本当に全部きっちりやるとかなり面倒です。
正直に言って、LAN内の通信だけの話なので、ad hoc な対処で逃げてしまう 事にしました。LIVA Z2 の ubuntu server で、/etc/hosts に MacBook Pro の ホスト名と 5GbE 側の 固定IPアドレスを書いてしまう、 というものです。5GbE 側がダウンしていない限り、これで問題は 生じないはず。やってみたらうまくいっているので、当面これで 運用してしまいます。
サーバ入れ替え騒動と並行して、クリティカルな問題ではないのですが、 外付USB RAID HDDケースである RS-EC32-U31R の空冷ファンが異音を 発するようになっていました。夏場は45℃、冬場は40℃を超えたら ファンが回るように設定を変えているのですが、今冬は設定変更を失念して いました。なので、しばらくの間はあまり空冷ファンが回っていませんでした。
設定変更を思い出して実施したところ、やけに空冷ファンの音が大きいと
感じました。また、音の質もあまり良くありません。
保証も切れているし、買い直す前にまず自分での対処を試みることにします。
分解してグリスアップすれば治るのかもしれませんが、そこまで
やるならいっそのことファンを交換してしまうことにしました。
RS-EC32-U31R そのもののファン交換の事例は見つけられませんでしたが、
外装がほぼ同じ前モデル、RS-EC32-U3R のファンを交換されている例は
見つかりました。
「RS-EC32-U3Rのファンを交換してみた」
です。こちらを参考に、うちでもファンを交換してみることにしました。
上記サイトには、元々ついているファンが 12V 0.055A の 40mm の物だと 記載されています。さらに型番で検索してみると、4500RPMで4.5CFM, 21dBA とのこと。こちらもおおよそ同じものがついているだろうと予測して、 交換用ファンを探しました。
先のサイトで使用されているファンは廃盤ですが、後継商品が出ています。 そちらは 12V 0.07A, 3500RPM で 4CFM, 18.24dBA という仕様になって いました。
これぐらいの電源負荷なら問題ないとは思うのですが、色々探しているうちに 12V 0.06A, 3500RPM で 4.2CFM, 14dBA との触れ込みのものを見つけました。 MINI-KAZE 2 というものです。先の後継商品より消費電流は少なめ、風量は多め、 動作音は低め、と良い事だらけのように見えます。 よく使う通販サイトに在庫もあったので、早速手配しました。
RS-EC32-U31R の分解は、先のサイトにあった RS-EC32-U3R の分解手順と ほぼ同じです。裏面のパネルはうまく外せなかったので、100円ショップで 買ってきた細い竹の棒と小さなハンマーで、前側から基板等の載っていない 隙間を叩いて、少しずつ外枠との嵌め合わせを外しました。
ファンを外してみると、先のサイトと同じ型番のものでした。 交換用ファンとはケーブルの長さが少し異なっていたので、ファンの 装着する角度をひねることで調整しています。
装着後は分解の逆の手順で組み立てます。裏面のパネルに取り付けた 基板上に直接 SATA コネクタがあり、その位置により微妙にHDDと前面の 金属パネルとの隙間が変わります。つけようとするとちょっとキツめに なっていたので、再度バラして基板の取り付け位置を微妙に調節しています。
再組み立て後、ファンの回転には問題ありませんでした。 実は期待していた、14dBA という動作音の小ささについては、思ったほど 小さくなりませんでした。これは、ファンの動作音がどうこういうより、 この筐体自体があまりエアフローがよくないように見えるので、吸気抵抗が 大きいのが原因ではないか、と思っています。 それでも、耳障りな音ではないですし、以前よりは小さくなったと思われる ので、交換自体は大成功でした。
[「Linux関連のページ」に戻る] [karg's Home Page]