クラウドサーバーの追加ディスクマウント時はnofailオプションを！
「クラウドサーバーで追加ディスクをマウントする際は、/etc/fstabのマウントオプションにnofailをつけよう！」
というお話。
# vi /etc/fstab UUID=12341234-1a2a-1b1b-2c2c-3d3d4e4e5f5f /mnt/data xfs defaults,nofail 1 2
という感じ。
以下、ディスクマウント設定は、CentOS 6, CentOS 7, Amazon Linuxで動作確認済みです。
追加ディスク設定の作業ミス
先日、CentOS 7 on Microsoft Azureのサーバー設定を行う機会があったのですが、追加ディスクの設定で失敗してしまいました。
通常の手順どおり、
- 追加ボリュームの作成とアタッチ
- fdiskコマンドでパーティションテーブルを作成
- /etc/fstabにエントリーを追記
- 追加ディスクをXFSでフォーマット
- マウントポイントを作成してマウント
を順に実施。
追加ディスクへの読み書きが正しくできることを確認し、念のためOSを再起動したところ、サーバーにSSHログインできなくなってしまいました。
どうやら、OS起動時のディスクマウント処理で失敗して、起動処理が途中で止まっているようです。
オンプレミスのサーバーや国産クラウドのように、サーバーコンソール機能が使えれば、メンテナンスモードでログインして対処できます。
/etc/fstabを編集して追加ディスクのエントリーをコメントアウトして再起動すれば、とりあえずOSが起動してくるので、その後必要な対処を行います。
しかし、AzureやAWSのLinuxではコンソール機能が使えません。
今回のお仕事では、Azure側の操作はほかの方の担当だったのですが、結局、サーバーを再作成してもらいました。
Azure操作担当の方の作業を増やしてしまったのは申し訳なかったですし、自分が行ったサーバー設定も一からやり直しになってしまいました。
※ただし、本番運用に入る前にOS再起動を試して、この問題に気づけたのは不幸中の幸いでした。
元のサーバーの中は見れなくなったので、ディスクマウント処理に失敗した理由はよはっきりしませんが、ひとつ考えられるのは、「/etc/fstab でデバイス名を指定した」ということです。
# vi /etc/fstab /dev/sdb1 /mnt/data xfs defaults 1 2
Azureドキュメントにわかりやすい説明があったのですが、Azure仮想マシンでは、ディスクのデバイスIDが毎回同じになることは保証されていないので、
「/etc/fstab では、デバイス名ではなくUUIDの使用をおすすめする」
とのことです。
（参考）
・Microsoft Azureドキュメント: Linux VM へのディスクの追加
https://docs.microsoft.com/ja-jp/azure/virtual-machines/linux/add-disk
追加ディスクの推奨設定
以前からAWSのサーバー設定・運用において、
「サーバーコンソール機能がないから、ディスクマウントに失敗したら危険だな、怖いな」
と思っていて、今回、初めてこの懸念が現実となってしまいました。
ではどうするのが正しいかというと、先ほどのMicrosoft Azureドキュメントに正解がありました。
「nofail オプションを使用すると、ファイルシステムが壊れているか、ブート時にディスクが存在しない場合でも VM が起動されるようになります。」
とのことです。
（このオプションは知らなかった！）
# vi /etc/fstab UUID=12341234-1a2a-1b1b-2c2c-3d3d4e4e5f5f /mnt/data xfs defaults,nofail 1 2
nofailオプションについては、AWSユーザーガイドにも記述がありました。
（参考）
・Microsoft Azureドキュメント: Linux VM へのディスクの追加
https://docs.microsoft.com/ja-jp/azure/virtual-machines/linux/add-disk
・AWSユーザーガイド: Amazon EBS ボリュームを使用できるようにする
http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ebs-using-volumes.html
/etc/fstab に追加ディスクのエントリーを残したままサーバーのカスタムテンプレート（AWS EC2のAMI、Azure仮想マシンのカスタムイメージ）を作成し、それを基に新しいサーバーを作成したときも、nofailオプションがあれば、追加ディスクをアタッチしなくても問題なく起動します。
（参考）起動しなくなったサーバーの復旧方法
Azureで今回のようにディスクマウント処理で失敗してサーバーが起動しない場合の復旧方法として、Azureサポートチームより、以下の方法が紹介されていました。
・Support for Linux on Azure: Linux Recovery: Cannot SSH to Linux VM due to FSTAB errors.
https://blogs.msdn.microsoft.com/linuxonazure/2016/07/21/cannot-ssh-to-linux-vm-after-adding-data-disk-to-etcfstab-and-rebooting/
要は、/etc/fstab ファイルを書き換えることさえできればよいので、以下のようにルートボリュームを他のサーバーでマウントして書き換えてしまいます。
起動しなくなってしまったサーバーをAとすると、大まかには以下の手順となります。
- サーバーAを停止して、ルートボリュームVをデタッチ
- 別のサーバーBにボリュームVを追加ディスクとしてアタッチ
- サーバーBで、ボリュームVをマウントし、fstabファイルを編集
- サーバーBからボリュームVをアンマウント、デタッチ
- サーバーAでルートボリュームVをアタッチ
- サーバーAを起動
これはAWSでも同じですね。
AWSでは、上記4.で、サーバーBでルートボリュームVをアタッチするときに、デバイス名として ‘/dev/xvda’ を指定するのがポイントです。（APIの仕様で、/dev/sda は指定できないため。）
まとめ
クラウドサーバーで追加ディスクをマウントする際は、/etc/fstabのマウントオプションにnofailをつけたほうがよいです。
とくに、サーバーコンソール機能のない、AzureやAWSでは必須といってもよいでしょう。
サーバーコンソール機能がある場合でも、
「いったんほかのサーバーからマウントして/etc/fstabファイルを書き換える」
というのは手間のかかる作業ですね。
今回の僕のような作業ミスは起こり得ますし、何らかの原因で運用中にファイルシステムが壊れることもあります。
そんなときでも、マウントオプションにnofailをつけていれば、マウントできないディスクは無視してサーバーが起動してくれるので、サーバーへのアクセス手段を確保できます。
その他、ディスクマウント時の不具合に限った話ではありませんが、サーバー設定作業時は、作業ミスに備えて以下の対策をとるとよいでしょう。
- サーバー構築途中でも、定期的にスナップショットを取る。→早くリカバリーできる。
- 本番運用に入る前にOS再起動を試す。→サーバー設定ミスや、サービス・アプリケーションの自動起動等を確認できる。
※作業ミスをなくす手段としては、AnsibleやChef等のツールを利用して、サーバー設定を自動化する、という方法もありますね。
