ZFSで「マスターの無い共有ストレージ」は作れるか？

こんな記事がありました。
↓
遠隔地のHDD内のデータを自動同期、クラウドストレージより高速に使用可能な「トランスポーター」とは？
http://gigazine.net/news/20121209-transporter/

どうやら、マスターとなるストレージが（ユーザから見て）存在せず、自動的に同期が行われるネットワークストレージみたいなものらしい。
普通のファイル共有はマスターとなるサーバーがあって、そのマシンがある場所以外からはネットワーク越しのアクセスになってしまうところを、この「トランスポーター」では全機器にローカルデータが

存在しているからアクセスが速いぜ、ということらしい。これは確かに嬉しい。
似たようなものとしてDropboxがあるけど、こっちだとずっと使用料払わなきゃならんしデータがマスターとなるDropboxに置かれるクラウドサービスだからなんか嫌だよねと。これもわかる。
自分も実際クラウドストレージとか便利なのはわかるけどなんか好きじゃない、という理由で自鯖立ち上げて外から繋いでいるわけだし。

で、（自称）ZFS教徒のb00tとしては「これZFS snapshotをうまくゴニョれば似たようなものができねーかな？」と思ってしまったわけだ。
もちろんこの「トランスポーター」をdisっているわけではなく、このサイズでオールGUIで設定できて同期できるネットワークストレージというものは市場には無いし価値があると思う。が、PC1台分のサイズ食ってオールCUIで同期できる偽物を作れるなら面白そう。

実際、「AppleのTimeMachine便利だわー」と思ってPC1台分のサイズでオールCUIでZFS rolling snapshot+send/recvを行うスクリプトを動かすTimeMachineの偽物を面白がって作っていたりする。まぁこれの話は別の機会に。

にしても、「ストレージ」と聞くとすぐ「ZFS！」と思ってしまうこの哀れな思考回路、別にZFS関係無く似たようなものが作れそうな気もするのでちょっと考えてみる。

・基本方針
物理的に離れたところにある2つのNASをマスター/スレーブの区別なく同期させる。
USB-HDDなどのローカルストレージとしなかったのは、ソフトウェアだけで実現するとなるとストレージを繋ぐ先のPCで何らかの同期スクリプトを走らせなければならず、クロスプラットフォームで動かすには厳しいから。NASならば、NASのOS構成を決めうちにしてその上でSamba/Netatalk等を動かせば良い。NASに対してLAN経由で繋げばGbEなのでローカルストレージに近い速度は出せる。マシンに一台ではなく（物理的な）一家に一台で良いし。というか自分はNASしか作れない。

とまぁそれなりに大規模なシステムになることが想定されるので、Dropboxでは厳しいTBクラスのストレージを同期させて、バックアップも兼ねるということを目標にする（じゃないと意味が無い）。

・双方向rsync
 「ストレージ」「同期」と聞いて誰もが(?)すぐ思いつくのはやっぱり大正義rsyncだろう。
ssh経由で動かすこともできるので遠隔地のマシンと同期を取ることも可能。
とは言ってもrsyncはA→Bの片方向同期（Aの更新をBに反映）しかできず、Bの更新をAに反映するにはA側だけではなくB側でもrsyncを動かす必要がある。この点はZFS snapshotも同じことではあるが。
双方向で--updateと--deleteオプション付きでrsync動かせばできそうな気がする。
また、lsyncを使って更新チェックすればほぼリアルタイムで同期が行えそう。

・Unison
異なるコンピュータ間の同期ツールとしてUnisonがある。最初から双方向同期をするためのツールとして開発されているので、rsyncを双方で動かすとかよりもトラブルが起きにくそう。一方、lsyncみたいなツールはないので自動同期を行うにはcronとかで定期実行する必要がある。

・ZFS snapshot
ZFS本来の機能として備わっているのはsnapshot生成機能とsnapshotのsend/recvによる転送機能（sshは経由できる）だけである。というわけで同期スクリプトは自前で作る必要がある。

まずは任意の1台でsnapshotを生成し、それを各マシンへsendによってコピーして全てのマシンに共通のsnapshotを持たせることから始める。
次に全マシンでcronを動かし同時刻にsnapshotを生成し、一番前回との差分が大きいsnapshotをマスターとして他のマシンにsendする（他のマシンのsnapshotは上書きされる）という感じだろうか。「一番前回との差分が大きいsnapshotを調べる」という動作をどのマシンがやるかという問題はあるが（1台に固定するとマスターが存在することになってしまう）。
この方法だと、前のsnapshotを生成してから同期を行うまでの間に複数のマシンでデータが更新されると、更新したデータ量が少ないsnapshotは問答無用で消されるという問題がある。
inotifyあたりを上手く使って、ファイル更新に合わせてsnapshot生成が動けばほとんど回避できる気はする。
ZFSを使うメリットとしては、古いsnapshotを即時削除しなければ世代バックアップもついでに行えるという点だろうか。

とまぁちょっと（本当にちょっと）調べた限りだと双方向rsyncが安定して動くなら一番便利そうではある。次点はUnisonだろうか。ZFSはsnapshot同期で安定しなさそう、双方で編集してた場合にデータが保全される保証がない、など一番イケてないように思える。そりゃそうだ。rsyncとUnisonは同期のために設計されたちゃんとしたツールだし、一方ZFSの方は思いつきで考えた方法を書いただけだ。

というわけで実際に「トランスポーターもどき」を作ろうと思ったらZFSを利用してというのは選択肢に入らない。が、「rsyncで双方向同期！」なんて普通にやられてる（「rsync 双方向」でググれば色々出てくる）し、rsync素人の自分が導入してみました、じゃネタにもならない。Unisonも同じく。

なのでZFSで遊んでみよう。でもってrsyncやUnisonと比べてみる。検証してるフリして結論ありきだなオイ！
まぁ、UMPC話もZEVO検証もオチまで辿り着いてないのにブログネタ増やしても仕方ないんだが・・・


あとがき　inotifyについて
この手の同期を行う上でキモとなるのがファイル更新検知である。これができないとcronで定期チェックとかになってしまうが、cronを用いずにファイル更新検知による動作ができるならコンフリクトの可能性はかなり減らせる。大人数でガンガン編集する共有領域ならそれでも問題となるが、個人で拠点毎にそれぞれストレージを置くならコンフリクトはまず起きなくなるはず。

rsyncの場合、lsyncdを使えばそれが実現できるが、他のツールに転用はどうやら無理そう。
lsyncdが使ってるのはinotifyというLinuxのイベント監視機能なので、UnisonやZFSでファイル更新検知を実現するならinotifyの機能を使おうということになる（多分）。

で、inotifyを使うツールとなると何やら色々存在する。inotify-tools、incron、fsniper、gamin・・・名前的に用途に一番近そうなのはincronだが、なんだかよくわからないので調べたり試す必要がありそうである。