ハクソク

世界を動かす技術を、日本語で。

アイドル時にスリープ状態にし、必要に応じてウェイクアップするLinuxホームサーバーの作成 (2023)

265日前原文(dgross.ca)

概要

  • Ubuntuサーバー のTime Machineバックアップ用ホームサーバーを、自動スリープ＆オンデマンド起動対応にカスタマイズ
  • Wake-on-LAN（WOL） とARP Stand-inで、ネットワーク経由の自動起動を実現
  • Raspberry Pi などの常時稼働デバイスを活用し、ARP応答やmDNSサービスを代行
  • 省電力化 と利便性を両立し、手動操作不要のバックアップ運用を実現
  • 設定手順・注意点 を具体的に解説

Ubuntuホームサーバーの自動スリープ＆オンデマンド起動構成

  • 高消費電力PCサーバー （例：HP ProDesk 600 G3 SFF、Intel I219-LM NIC）を Ubuntu Linux で運用
  • 常時稼働の低消費電力デバイス （例：Raspberry Pi、Ubuntu Linux）を同一ネットワークに配置
  • ネットワークサービス （SSH、AFP、Time Machineバックアップ等）を利用
  • サーバーはアイドル時に自動スリープ、必要時はネットワーク経由で自動復帰
  • Wake-on-LAN（WOL） は ユニキャストパケット 対応NICが必須

サーバー側の設定

  • Wake-on-LAN（WOL） を ユニキャストパケット で有効化し、永続化
    • sudo ethtool -s eno1 wol ug
    • /etc/networkd-dispatcher/configuring.d/wolスクリプト作成・実行権付与
  • アイドル検知＆自動スリープスクリプト をcronで定期実行
    • SSHログインユーザー数・AFP接続数でアイドル判定
    • アイドル時のみsystemctl suspendでRAMスリープ
    • 例：/home/ubuntu/auto-sleep.sh
  • IPv6無効化 （ARP利用のため）
    • /etc/default/grub編集：GRUB_CMDLINE_LINUX="ipv6.disable=1"
    • sudo update-grub後、再起動
  • ネットワークサービスのスリープ前停止 （不要な復帰防止、例：Netatalk）
    • netatalk-sleep.serviceをsystemdで作成・有効化

常時稼働デバイス側の設定

  • ARP Stand-in （Rubyスクリプト等）で、スリープ中サーバーのARPリクエストに代理応答
  • Avahi で、サーバーのmDNSサービス（例：_afpovertcp._tcp）をスリープ中もアナウンス
    • avahi-publish.serviceをsystemdで作成・有効化

注意点・要件

  • NICがユニキャストWOL対応 必須
  • 不要なパケット送信で意図しない復帰 が発生しないよう、ネットワーク監視・設定に注意
  • ARPオフロード はLinuxドライバ未対応の場合が多い（Windowsは対応）
  • ARPキャッシュ切れ問題 はARP Stand-inで解決

サーバーアイドル検知・自動スリープ実装

  • アイドル判定基準 ：SSHログインユーザー数、AFPポート（548）接続数
    • whoコマンドでログイン数取得
    • lsof -i:548でAFP接続数取得
  • cronジョブ で10分毎にスクリプト実行、アイドル時のみRAMスリープ
  • circadian 等の高度なツールも検討可だが、シンプルなbashスクリプトで十分

Wake-on-LANとARPキャッシュ問題

  • Wake-on-LAN（WOL） は通常「マジックパケット」で復帰
  • ユニキャストWOL で通常パケットによる復帰も可能（NIC対応必須）
  • ARPキャッシュ切れ でサーバーMACアドレスが解決できず、パケット未送信→復帰不能問題発生
  • ARPオフロード （NICがスリープ中もARP応答）はLinux非対応が多い

ARP Stand-inによる解決策

  • ARP Stand-in は、常時稼働デバイス（例：Raspberry Pi）がスリープ中サーバーのIP/MACに代理応答
  • クライアントは通常通りサーバーにアクセス可能 となり、ARP解決→パケット送信→WOLで復帰
  • mDNS（Avahi） 併用でTime Machine等のサービス検出も維持

まとめ・応用ポイント

  • 完全自動のバックアップ運用 と 省電力化 を両立
  • LinuxサーバーのWOL運用 にはARP Stand-in等の補助が必須
  • Raspberry Pi等の活用 で、より高度なホームラボ構築が可能
  • ネットワーク機器の機能・Linuxカーネルの制限 に留意し、運用設計を行うこと

Hackerたちの意見

それ、俺も思ってた。俺の自宅サーバーは15Wくらいしか消費しないし、静かなんだよね。データセンター用のラックマウントサーバーをクローゼットに入れて音が聞こえないようにするなら、確かにそのアプローチは理にかなってるかも。

└

俺はMac Mini使ってる。何も動いてないときは、7Wくらいしか使わないよ！

└

イギリスでは、24時間365日稼働する負荷の10Wごとに約£25（約33ドル）かかるんだよね。小さなことでも積もると結構な額になるよ。

よくやったね。でも、ATXコントロールボードを使ったり、RPiをUSBガジェットとして設定して、電源ボタンやキーボードでマシンを起動することもできるからね。

└

最近これやったんだけど、消費者向けPCでWoLを動かすのに苦労してたんだ。こういう超低レベルのことは運次第みたいだから、電源ボタンを配線するだけで済むなら、それがいい選択だと思う。結局、俺は思い切ってPiKVMをセットアップしたから、今はマシンのネットワークを壊しても（OSを完全に壊しても）リモートで復旧できるんだ。ちゃんとしたBMCとかはないけどね。一般的にはこのアプローチは原理的にはイマイチだけど、実際にはすごく気に入ってる。消費者ハードウェアにしっかりしたリモート機能を追加できるから、選択肢が広がるんだよね。

└

これ、賢い選択肢だね。完全にフリーズしたときにリモートで電源サイクルもできるんじゃないかな。

└

注意：もしSBCをウェイクアップ信号専用で使うつもりなら、RPiの代わりにRadxa RockPi Sみたいな選択肢を考えてみるといいかも。[1] 例えば、俺の自宅サーバーは7Wで常時稼働してるから、いくつかのRPiモデルよりも優れてるよ。もちろん、ウェイクアップ用のPiはそんなに電力を必要としないし、古いモデルでも大丈夫だけど、それでも「無駄なワット」を消費することになる。もちろん、RockPiにはKVMのような機能はないけどね。[1]: https://wiki.radxa.com/RockpiS

20年前、家でSlackwareを動かしてるLinuxサーバーがあって、オフになってる2台のPCを起こしてデータをバックアップしてたんだ。もしPCがオンの状態なら、WOLパケットをLinuxサーバーに送って、サーバーがオフだったら起動させてバックアップルーチンを始めるって感じ。最後にはLinuxサーバーに自分をオフにするように指示してた。すごくうまくいってたし、いい思い出だよ。

一部のマザーボードはスリープ時にイーサネットポートへの電源を切るから、WoLが動かないことがあるよ。特にNICが電力を多く消費する10GbEポートの場合はよくある話。ただ、俺が見つけた特定のケースでは、マザーボードが接続されたUSB GigEアダプターへの電源も切ってた。俺が見つけた解決策は、（空の）SDスロットと統合GigEポートを持つUSBハブを接続することだった。SDカードはマウントを維持するために電力が必要だから、マザーボードはこのアダプターへの電源を切らず、WoLが動いたんだ。

└

これ、作業場の隅にある空の箱を思い出させるな。「取らないで！」って書いてあるやつ。

└

BIOS/UEFIに「EuP 2013」って設定があるから、それを無効にしてみて。Windowsを使ってるなら、デバイスマネージャーでそのデバイスがコンピュータを起こせる設定があるか確認してみて。（正確な名前は思い出せないけど。）

そんなことも考えたけど、結局は小さなサーバーをスマートプラグに繋ぐシンプルな方法にしたんだ。サーバーをシャットダウンして、Wi-Fi経由でプラグの電源を切る。プラグの電源を入れればサーバーが起動する仕組み。プラグはほとんど電力を消費しないし、サーバーはARM SoCで1〜4Wしか使わない。1台はHDDを搭載していて約10W消費するけど、そのディスクが必要ないときはアンマウントして電源を切れるし、サーバーはそのまま動かしておける（SSDも搭載してるしね）。

投稿ありがとう、すごく参考になったよ。私はこれを半手動でやってる。常に稼働していて電力効率の良いSBCサーバーにCGIスクリプトを置いて、誰かが必要なときに大きなサーバーを起こすようにしてるんだ。大きなサーバーは、バックアップが動いてないとき、みんなが寝てる時間に自動でシャットダウンするようになってる。これを改善して、サーバーの使用状況や太陽光発電を測定してシャットダウンを決めることを考えてるんだ。たぶん、追加の警告メールも送るようにして。「需要がなくて太陽光発電もないから、サーバーは5分後にシャットダウンします。これを防ぎたい場合はこのリンクをクリックしてください: http://server.lan/cgi-bin/keepalive」

前回やったときは結構簡単だったと思う。BIOSでWoLを有効にして、ルーターからetherwakeを実行するだけだったから（ネットワーク上の他のマシンからでも）。でも、これは非マジックリクエストで起こす話だよね、ただのリクエストで？

ハハ、妻の治療でタイに行ったときに似たようなことを試したんだけど、見事に失敗したよ。幸い、ノートパソコンにはすべてのファイルがあったけど、その時はTailscaleがなかったんだ。デスクトップはWoLがオンで、動作確認済みのAndroidフォンも常に稼働してて、SyncThingがインストールされてた。モバイルにはTaskerも入れてあって、SyncThing内のフォルダーをTaskerに監視させるつもりだった。コンピュータが必要なとき、そのフォルダーにファイルを入れると、Taskerがそのフォルダーを見つけてデスクトップにWoLを送信し、ファイルを削除する。ファイルが削除されたら、コンピュータが起きたってわかるんだ。でも、実際にタイから試したとき、ファイルは削除されなかったし、コンピュータも起きなかった。どうなったかっていうと、モバイルが一定時間の無操作後に自動で再起動しちゃったんだ。それでTaskerがロックアウトされて、全プロセスが失敗した。だから、「獣を起こす作戦」は失敗したってわけ。

└

もうTaskerを使ってるなら、起動時にTailscaleを立ち上げるように設定できるよ。私はそうしてるから、再起動後に自動でTailscaleに再接続できるんだ。

└

なんでインターネット越しにWOLを直接送らないの？

同じような機能をDNSサーバーに組み込んで、ローカルネットワークの外からでもデバイスを起こせるようにしたよ。ここにちょっとした説明がある: https://github.com/RyanGibb/eon/tree/main/bin/hibernia こちらにも少し書いてあるよ: https://www.sicsa.ac.uk/wp-content/uploads/2024/11/LOCO2024_...

あなたの解決策ほど洗練されてはいないけど、「バックアップの使い方」にはすべてのハードウェアで使えるよ。メカニカルタイマーを使って、バックアップ開始の10分前にセットして、バックアップが通常終わった30分後に電源を切るって感じ。これ、電気代も節約できるし、10分で実装できるから楽だよ（Amazonでの注文に5分、タイマーをバックアップ時間に合わせてセットするのに5分）。それに、トラブルも少ないしね。バックアップサイズが増えると、バックアップ時間と電気代/時間の節約をうまくバランス取る必要があるけど。