2019年7月現在、私のまわりではサーバーノード間でファイルを共有する際にはやっぱりNFSがいいよねという雰囲気である。
一時期、ファイルサーバーが単一障害点(SPOF)になるのが嫌で、なおかつ複雑なクラスタをクラウドで組むことに抵抗があったので、Azure File Storage という SMB3.0 ストレージサービスをLinuxからマウントする運用をしていた。
でもやっぱり、パーミッションがUNIXの世界と違ったり、ネットワーク距離があるため、ランダムアクセスの性能が残念であったりで、やはり同一リージョン、同一ネットワークにあるVMでNFSサーバーを立てるべきと一周回って元の場所に戻ってきたところだ。
とはいえ単一障害点(SPOF)はやはり嫌なので、DRBD + Corosync + Pacemaker でHAなNFSサーバーを構築したいところ。
DRBDは、複数のLinuxサーバーの間でブロックデバイスレベルでディスクの内容を同期してくれるカーネルモジュールで、一般的には Pacemaker などのクラスタリングソフトウェアと組み合わせてHAなサービスを構築する際に使うことができる。
単にブロックデバイスなので、その上にファイルシステムを構築すれば普通にファイルとして保存しているだけで、別のサーバーのディスクにも同期されているという優れものだ。
この環境を自分で構築するのはかなり面倒でつまらない作業だ。
結論からいうとこの構成を自分で作成する必要はなかった。Azureの可用性セットとロードバランサーを含め適切に構成されたテンプレートが用意されているからだ。
Azureのポータルにログインしている状態なら以下のリンクからすぐに作成することができる。
クラスタをぶら下げたい仮想ネットワーク（Subnet Id）を指定して、あとは Node0 と Node1 のIPアドレス、およびロードバランサで提供されるクラスタの代表IPアドレス、サーバーにアタッチしたいディスクの数とサイズを指定するだけですべてがセットアップされたクラスタが作成される。
クラスタが切り替わる様子はこちら。
DRBDでブロックデバイスをミラーリングして、高可用性なNFSサーバーを構築し、書き込みながら切り替えた様子。 pic.twitter.com/dB8IpWdWUf
— 石田健亮 (@kensuke_ishida) July 23, 2019
アクティブなノードをいきなり電源ダウンしたときも２分かからずにNFSクライアントからは復旧できている。
サブネットのIDはAzure CLIがあれば以下のコマンドで調べることができる。
$ az network vnet subnet list --resource-group={リソースグループ名} --vnet-name={仮想ネットワーク名}
なお、DRBDはカーネルモジュールで動いているので、Ubuntuの自動更新・自動アップデートは停止しておいた方がいいだろう。
特にカーネルの更新にはナイーブなので要注意。