七回目の投稿です。今回の内容は、参画中の運用保守案件にて経験した障害対応業務の紹介です。

参画から5ヵ月ほど経ったこともあり、顧客のサービスに影響が及ぶ規模の障害にとうとう遭遇して

しまいました。障害の解消に大きく貢献できたわけではないのですが、非常に多くのことを学べたので

共有します。

◆障害の内容

まずは、今回出会った障害について説明します。

※ 実際の障害内容と環境に一部修正を加えたものを紹介します

・環境：

 4台のRed Hat系LinuxサーバA、B、C、Dがあり、このうちAとBは同じ仕様／同じ設定でアクティブ-

 アクティブ構成をとるアプリケーションサーバ群、CとDは同じ仕様／同じ設定でアクティブ-スタンバイ

 構成をとるNFSサーバ群である。また、CとDのNFSプロセスはクラスタリングソフトによって制御

 されており、 平常時はCの特定のファイルシステムが AとBからマウントされ、Cに障害が発生した

 際は、Dの特定のファイルシステムがマウントされる。当該ファイルシステムには、AとBにおける

 アプリケーションの実行に必要な資材が配置されており、マウント方式はautofsを採用している。

・障害内容：

 CとDのバックアップデータ取得のため、CとDを停止した。バックアップ取得後にCとDを起動すると、

 AからCへのNFSマウント失敗のアラームが発報されるようになった。一方のBはCへ正しくマウント

 できており、アラームは発報されない。AからCにマウントできなくなったため、Aでのアプリケー

 ションの実行が失敗し、サービスに支障が出た。

一言で言うと、「あるサーバのファイルシステムを別のサーバからマウントできなくなった」という

ことです。

◆用語の確認

障害対応について触れる前に、関連する用語について補足しておきます。

・マウント：

 OS上でSSDやHDDなどの記憶媒体を扱うための操作のことです。Linuxでは、原則「mount」コマンドを

 用いて記憶媒体をマウントする必要がありますが、Windowsの場合は自動でマウントが行われます。

 Windows PCにUSBメモリを接続し、USBメモリ上のデータの読み書きを行ったことは誰しもあるかと

 思います。USBメモリをUSBポートに指すだけで使えるように見えますが、実際は、Windows側で

 マウント処理が行われています（自動マウントさせないように設定することも可能）。

・NFS（Network File System）：

 ファイル共有機能を提供するプロトコルです。Linux系OSでは標準的に搭載されているため、Linux系

 サーバ同士でのファイル共有の際に用いられることが多いです。あるサーバのファイルシステムを

 ネットワーク経由でマウントすることにより、マウント先のファイルシステム内のファイルや

 ディレクトリをマウント元のサーバから扱えるようになります。

・autofs：

 マウント先のディレクトリにアクセスしようとすると、自動的にマウントしてくれる機能です。また、

 マウント先のディレクトリに一定時間アクセスしないと、自動的にアンマウントも行ってくれます。

 上述のNFSと組み合わせることができ、必要なときだけマウントすることで、サーバの負荷軽減が期待

 できるという特徴があります。

◆障害対応

それでは、障害発生から復旧までの対応内容を記載します。

１．AからCへの疎通確認

まずは、サーバAで次のコマンドを実行します。

$ ping <サーバC>

$ nslookup <サーバCのホスト名>

コマンドの結果としては、ping疎通や名前解決は問題なくできていました。

２．autofsの再起動

サーバBでは問題なくNFSマウントができるということで、サーバA側の異常を疑います。

サーバAにて、autofsの状態を確認し、一度再起動します。

$ systemctl status autofs.service

$ systemctl stop autofs.service

$ systemctl status autofs.service

$ systemctl start autofs.service

$ systemctl status autofs.service

autofsの再起動後、NFSマウント先のファイルシステムにアクセスできるかどうかを確認します。

$ ls <マウント先ディレクトリ>

残念ながらautofsの再起動だけでは解消しませんでした。この後の対応としては、サーバの再起動

などが考えられますが、日中時間帯のサーバ停止は更なるサービス停止につながってしまうため、

以降の対応はサービスが停止している夜間帯に実施しています。

３．クラスタリングソフトによるプロセスの再稼働

サーバを再起動する前に、CのNFSプロセスをクラスタリングソフトから手動で停止してみます。

CのNFSプロセスを停止すると、DでスタンバイしていたNFSプロセスが稼働し始めます。その後、

再度CのNFSプロセスを再開し、AからCへNFSマウントできるかどうかを確認します。

$ ls <マウント先ディレクトリ>

クラスタリングソフトにてプロセスを再稼働させることで、AからCへNFSマウントできるように

なりました。AやCを再起動することなく、また、BからもNFSマウントできなくなるといった障害が

発生することもなく、元通りの構成に復旧しました。

後日、インフラ構築事業者とクラスタリングソフトのメーカにそれぞれ問い合わせましたが、

はっきりした原因は分かっていない状況です。

◆感想など

顧客にとってはたまったものではありませんでしが、個人にとってはトラブルシューティングに関する

ナレッジを蓄積するとともに、場数を踏む機会となりました。トラブルシューティングについて知って

いることと、実際にトラブルシューティングができるということの間には、大きな差があるなと痛感

しました。

◆参考

・ https://www.designet.co.jp/faq/term/?id=TkZT