午前2時のブラックスクリーン：サーバーが起動しない恐怖
火曜日の午前2時、私の監視ダッシュボードが赤く染まりました。本番環境のデータベースサーバーで定期的なカーネルアップデートと再起動が予定されていましたが、一向に応答が返ってきません。IPMIコンソールにログインすると、すべてのシステム管理者が最も恐れるメッセージが表示されていました。You are in emergency mode. After logging in, type "journalctl -xb" to view system logs.（エマージェンシーモードです。ログイン後、”journalctl -xb”と入力してシステムログを確認してください。）
原因は何だったのでしょうか？それは /etc/fstab ファイル内の単純なタイプミスでした。その日の早い時間に、2TBのバックアップドライブを追加していたのです。エントリの検証を怠ったため、ディスクが見つからず、起動プロセス中にシステム全体がハングアップしてしまいました。これがLinux管理における緊張感のある現実です。/etc/fstab ファイルはストレージ設定のバックボーンですが、たった1文字の書き間違いがインフラ全体をオフラインにする可能性があります。
なぜ /etc/fstab が単一障害点（SPOF）になるのか
/etc/fstab (File System Table) ファイルは、どのパーティションをマウントし、それらをどのように処理するかをLinuxカーネルに伝えます。起動プロセス中、systemd はこのファイルを読み取ってファイルシステムツリーを構築します。リストされたデバイスが見つからないか、パラメータが正しくない場合、通常、起動プロセスは停止します。これは、システムが不整合な状態で実行されたり、データが破損したりするリスクを防ぐためです。
ほとんどの失敗は、次の3つの一般的なミスから生じます：
- 不安定なデバイス名： UUIDの代わりに
/dev/sdb1を使用している。SATAケーブルを差し替えたりUSBドライブを追加したりすると、sdb1がsdc1に変わる可能性があり、マウントに失敗します。 - ネットワークのタイミング問題： ネットワークスタックが完全に初期化される前にNFS共有をマウントしようとする。デフォルトでは、システムは返ってこないかもしれない応答を待ち続けます。
- 構文エラー： 列を忘れたり、
defaultsのようなマウントオプションの綴りを間違えたりする。
/etc/fstab エントリの構造
/etc/fstab の各行は、厳格な6列構造に従います。ここでは正確さが不可欠です。
# <ファイルシステム> <マウントポイント> <タイプ> <オプション> <ダンプ> <パス>
UUID=abc-123 /data ext4 defaults 0 2- ファイルシステム： パーティションの一意識別子です（UUIDがゴールドスタンダードです）。
- マウントポイント： ディスクが表示されるディレクトリ（例：
/mnt/storage）。 - タイプ： ディスクのフォーマット（
ext4、xfs、nfsなど）。 - オプション：
rw（読み書き可能）やnoexec（バイナリの実行を禁止）などの特定の動作設定。 - ダンプ： レガシーなバックアップフラグ。通常は
0に設定します。 - パス：
fsckチェックの順序を決定します。ルートには1、その他の物理ディスクには2、ネットワーク共有には0を使用します。
プロのテクニック：ローカルストレージにはUUIDを使用する
/dev/sda1 のようなデバイスパスの使用はやめましょう。これらは動的で危険です。代わりに、ハードドライブを別のポートに移動しても変わらないUniversally Unique Identifier (UUID) を使用してください。UUIDを確認するには、次のコマンドを実行します：
lsblk -fエントリは次のようになります：
UUID=550e8400-e29b-41d4-a716-446655440000 /storage ext4 defaults 0 2起動を妨げないNFS共有のマウント方法
NFSマウントは、起動を失敗させる原因として悪名高いものです。リモートサーバーがダウンしている場合、クライアントはデフォルトの90秒のタイムアウトまで画面が止まったままになるか、完全に失敗する可能性があります。システムの回復力を維持するために、_netdev と nofail フラグを使用してください。
_netdev: マウントを試行する前に、ネットワークがアクティブになるまで待機するようシステムに強制します。nofail: ディスクが見つからない場合でも、システムの起動を継続できるようにします。
# 安全なNFSマウント
192.168.1.50:/exports/data /mnt/nfs_share nfs defaults,_netdev,nofail 0 0Tmpfsによるパフォーマンス向上
セッションデータやキャッシュのように、アプリケーションが数千の小さな一時ファイルを書き込む場合は、SSDの書き換え寿命を無駄にしないでください。tmpfs を使用して、それらのファイルをRAMに保存します。これにより、レイテンシを大幅に削減し、ハードウェアの寿命を延ばすことができます。
# /tmp を2GB制限でRAM上にマウント
tmpfs /tmp tmpfs rw,size=2G,nodev,nosuid 0 0黄金のルール：テストなしで再起動してはいけない
50台以上のLinuxサーバーを管理してきた経験から、fstab を編集した直後の再起動はギャンブルだということを学びました。システムが稼働している間に、安全に変更を確認できます。まずターゲットドライブをアンマウントし、次に以下を実行します：
sudo mount -aこのコマンドは、システムに /etc/fstab 内のすべてのエントリのマウントを試行するよう指示します。構文エラーや誤ったUUIDがある場合、アクティブなシェルに即座にエラーメッセージが表示されます。コマンドが何も出力せずに終了すれば、設定は有効であり、安全に再起動できます。
リカバリ：エマージェンシーモードからの脱出
もしエマージェンシーモードに陥ってしまっても、慌てないでください。修正は通常2分程度で終わります：
- rootパスワードを入力してシェルを取得します。
- ルートパーティションを読み書き可能として再マウントします：
mount -o remount,rw / - ファイルを開きます：
nano /etc/fstab - 最近追加した行の先頭に
#を置いてコメントアウトします。 - 保存して終了し、
rebootと入力します。
推奨されるマウントオプションのまとめ
| ストレージの種類 | 推奨オプション |
|---|---|
| 内蔵SSD/HDD | defaults |
| 外付けUSBドライブ | defaults,nofail |
| NFS/Samba共有 | _netdev,nofail,x-systemd.automount |
| 機密データ | defaults,nosuid,nodev,noexec |
/etc/fstab をマスターすることは、単にディスクをマウントすること以上の意味があります。それは、ハードウェアの不具合にも耐えられるシステムを構築することです。UUIDを優先し、重要でないボリュームには nofail を活用し、常に mount -a でテストすることで、午前2時に何かが起きてもサーバーをオンラインに保つことができます。
