測定した制約を1つの限定的なアップグレードで解消できるなら、老朽化したサーバーを拡張します。プラットフォームの老朽化によって、追加する部品すべてが新たな依存関係になるなら、移行します。
比較すべきなのは、アップグレード費用と新しい筐体の価格ではありません。今後3年間の電力、インターフェース、ファームウェアのサポート、交換部品、復旧時間、データ移行、そして最初のアップグレード直後に別の制約が発生する可能性を比較します。
判断のきっかけとなった制約を特定する
CPU使用率の飽和、メモリの逼迫、プール容量、ネットワークスループット、PCIeの空き状況、消費電力、温度、バックアップ時間を測定します。次のワークロードを妨げている制約を1つ特定してください。
実用的なホームラボのハードウェア計画は、あらかじめ容量を購入するのではなく、ワークロードとプラットフォームの役割から始めます。
測定した制約を交換可能な1つのコンポーネントで解消できるなら、拡張は有効です。CPU、メモリ上限、ストレージポート、ネットワーク速度のすべてに余裕がないなら、問題はプラットフォーム全体に及んでいます。
プラットフォームに残されたサポート範囲を確認する
マザーボードの使用年数、ファームウェアの入手可能性、対応メモリ、起動動作、ストレージコントローラーのモード、交換用PSUとファンの入手可能性、そしてレーンの競合なしに最新のネットワークカードやHBAカードを取り付けられるかを記録します。
古いエンタープライズハードウェアは保守性に優れている場合がありますが、アイドル時の消費電力が高く、専用部品が必要になることがあります。古いコンシューマーハードウェアは効率的でも、リモート管理機能や安定して入手できる交換部品がない場合があります。
マザーボードやコントローラーが故障した場合、復旧を始める前に中古市場を探す必要があるなら、移行します。重要な予備部品と構成記録がすでに用意されている場合にのみ、拡張してください。
今後3年間の総コストを比較する
電気代、アダプターカード、交換用ファン、ドライブシェルフ、UPS容量、移行にかかる時間の価値を加算します。アイドル時の高いコストや、サポート対象外のコントローラーにシステムを縛り付けるなら、安価なアップグレードでも安いとはいえません。
新しいシステムを推測上の拡張ではなく実際のワークロードに合わせて設計するなら、消費電力の削減やアダプター数の減少によって移行費用を回収できる場合があります。
| 判断項目 | 現在のサーバーを拡張 | 新しいプラットフォームへ移行 |
|---|---|---|
| 初期作業 | 1つのアップグレードなら少ない | 構築とデータ移行の作業が多い |
| アイドル時の消費電力 | 通常は変わらないか増加する | 大幅に下がる可能性がある |
| 故障リスク | 老朽化した中核コンポーネントを引き継ぐ | 移行リスクが発生する |
| 互換性 | 古いプラットフォームに制限される | 新しいインターフェースとサポートを利用できる |
| ロールバック | アップグレードを元に戻せるなら簡単 | 古いサーバーを一時的に保持する必要がある |
性能より先に復旧経路を比較する
拡張する場合は、交換不可能な最も古い部品が故障した状況を想定します。ストレージを別の場所にインポートできますか。また、ブートエントリ、暗号化キー、サービス定義はホストの外部に保存されていますか。
移行する場合は、まず1つのサービスと1つのデータサブセットを段階的に移行します。記録されたホームラボ移行事例は、アップグレード、電源イベント、ストレージ移行を個別の購入ではなく、1つの管理された移行として扱うべき理由を示しています。
テスト済みのロールバックが可能な経路を優先してください。復元、権限、DNS、クライアントアクセスが機能するまでは、より高速な新しいサーバーのほうが安全とはいえません。
1回のアップグレードルールを使う
1回のアップグレードでボトルネックを解消でき、中核プラットフォームの予備部品が把握され、アイドル時の消費電力が許容範囲に収まり、復旧が目標に合うなら、拡張します。アップグレードを恒久的に積み重ねないよう、見直し日を設定してください。
2つ以上のプラットフォーム上の制約を変更する必要がある場合、古いホストに交換手段がない場合、または年間の電力費とアダプター費用が新しいシステムの価値に近づいている場合は、移行します。新しい復旧モデルを明確に設計するために、ホームサーバーOS選択ガイドを活用してください。
アップグレードによってストレージ構成、電源、冷却、オペレーティングシステムを同時に変更することになるなら、拡張を止めてください。その時点ですでに移行していますが、明確なロールバック計画がない状態です。
製品比較
もっと読む

アプリのアップデートとロールバックにおけるProxmox上のLXCとDockerの比較
Dockerはアプリレベルのバージョン管理を提供し、LXCはゲストレベルのロールバックを可能にします。より適した方は、安全に復元できる最小の状態単位に応じて決まります。

特権ホームサービスにおけるDockerとLXCのセキュリティ境界
Dockerは用途を絞ってパッケージ化されたアプリに適しており、LXCはより完全なLinuxサービスに適していますが、共有カーネルのリスクを許容できない場合、どちらもVMの代わりにはなりません。

初心者が初めて構築するなら、ターンキー型NAS OSかモジュール型Linuxか
ガイド付きのストレージ運用にはすぐに使えるNASソフトウェアを選び、学習と明確な制御のためにより多くの管理を担う価値がある場合は、モジュール式のLinuxを選びましょう。

