FreeBSDでHAST/NFS Serverを立てる

本記事は、現在書き直し中です。

以前の記事は、ここにあります。

書き直しの背景

以前の記事を基に FreeBSD/HAST/NFS/CARPを利用した冗長化Network File Systemを構築していたが、以下の問題が残っていた。

File Server(NFS Server)がFailoverすると、結局NFS Client側で以前のFilesystemをmountできない
起動時に様々な理由によりHASTがうまく初期化されなかったり、Filesystemがexportできなかったりする

これらの問題は、結局のところ

FreeBSDにおける起動処理の問題
- しかし、これはあまりにも特殊要件すぎて、起動処理を適切に作れるようにすることは困難
NFSの問題
- NFS v3/v4共に、NFS Serverが切り替わることは想定されていない

という問題に帰着する。

という問題を、とある某東京工業大学に所属し、かつFreeBSD Projectでも活躍されている、某佐藤先生に気合を込めて語っていたら、とんでもない方法でHASTで構築されたファイルシステムを認識する方法を開拓されてしまったので、「問題提供者の責任」という名前の「ただやってみたいから」というモチベーションでまとめる。

この記事は、FreeBSD ワークショップ第15回で私が発表した内容と、それに対する佐藤先生の案の資料を基に記載する。

私の発表資料 : FreeBSDで完全冗長化されたNetwork Filesystemを
佐藤先生の資料 : https://people.allbsd.org/~hrs/sato-FBSDW20160218.pdf

根本的なMotivation

Mail Serverなどに供給するFilesystemは安定性と冗長性が重要である。しかしながら、Filesystemの冗長化は非常に難しい。 Network Filesystemとして利用するならば、難易度は激烈に上がってしまう。まして、Freewareだけで構築しようとすると絶望的に難しい。

このような要望をなんとか満たすことを考える。

Linuxで頑張る場合
- DRBD
  - StorageをBlock Deviceレベルで同期
  - 機構としてはMirrorに似ているが、Networkを超えて同期することができる
- lsyncd/rsync
  - Linux kernelのinotifyを利用したファイルの書き換え検出(lsyncd)と、検出されたファイルの同期(rsync)の組み合わせで実装
  - ファイル単位の同期が行えるが、Symbolic Linkの取り扱いなどに難がある
FreeBSDを利用する場合
- HAST
  - StorageをBlock Deviceレベルで同期
  - DRBDと同様の機能を持つ
- GEOM (未確認。論理的にはできそうな気もするが、機能が足りない気もする)
  - geom_mirror と geom_gate を組み合わせることで提供できる可能性はあるが未確認
    - geom_mirror : GEOM Storage Moduleの一つ。RAID-1機構を提供する
    - geom_gate : GEOM 仮想化モジュールの一つ。ネットワークディスクをバックエンドに用いた仮想Diskを作成する

これらの技術を利用して完全冗長にできるだけ近いネットワークファイルシステムを構築したいというのがモチベーション。

では、何に使うのか？

完全冗長なNetwork File Systemが欲しい局面としては、

SMTP ServerのMail Storage
HTTP ServerのContents Storage

など、いわゆるある程度以上の頻度で書き換えが発生する、ある程度以上の規模のシステムがある。

例えばSMTP Serverを考える。

今時、SMTP Serverを構築する際には、Lock問題が発生しないように、

Maildirを利用し
どこかのStorageに
ファイル単位で
受信したメールを保存する

というのが一般的だろう。

この時に、SMTP Server冗長性を確保したいという要望が出ることはしばしばある。

このような場合に、SMTP Server自身の冗長性は、比較的確保しやすい。しかし、受信したメールを格納するStorageが冗長性を持たなければ、結局、システムとしてはStorageがSPoF(Single Point of Failure)になってしまう。

このような状況を多少なりとも改善するには、Storageを冗長性を上げる必要がある。

以上が、この仕組みを実装するモチベーションである。

なお、HASTの冗長は「片側を書き換えたら即逆側も書き換わる」冗長であり、いわゆるBackupではない。したがって、Backupは別途検討する必要がある。

方式検討

本記事のポイントは、大きく分けると３つ

Block Storage Deviceの冗長化手法 (1)
冗長化されたStorageのNetwork Filesystemへの提供方法 (2)
提供されたStorageのNetwork Filesystemとしての公開方法 (3)

(1) Block Storage Deviceの冗長化手法

今回はFreeBSDを前提としているので、手法としては２択。

HASTdを利用する
GEOMを利用する方式

今回は、HASTdを利用する方式とする。

理由は、HASTdしか知らないから。

(2) 冗長化されたStorageのNetwork Filesystemへの提供方法

ここが、佐藤先生と自分の実装の大幅に異なる点。

自分の実装では、FreeBSDに標準添付されている carp-hast-switchを利用し、HASTdとmountを利用する手法を採用

これに対し、佐藤先生は、geom_nopとHASTdを組み合わせた上で、iSCSIを利用して提供する手法を採用

(3) 提供されたStorageのNetwork Filesystemとしての公開方法

Network Filesystemとして公開する方法は数多ある。

しかし、今回は、Client側の実装として、FreeBSD/NetBSD/OpenBSD/CentOS/Ubuntu/MacOS-Xなどがあるため、汎用性が高いプロトコルを利用する必要がある。加えて、できるだけFreeBSDの標準Distributionで配布されているものを利用したかった。

そのため、NFSを利用する。

ほほほのほ

目次