何回かに分けて FOBAS CSC Ver.3 の特徴のご紹介して行くシリーズの第３回目です。
今回は、Ver.2から提供はしていたものの、Ver.3 からはファイルシステムネイティブ
でサポートするようになった機能をご紹介していきます。
「ネイティブでサポート？機能が使えるならどのように実装しようが同じでしょ？」
おっしゃる通りです。(^^;
現実には、Ver.2 までの実装では、お使いになるインタフェース毎に、機能の実装が別
であったり、機能レベルに差があったりという状況でしたので、ユーザ視点で見ても機
能レベルが統一されたり、C言語での実装に変わる事で性能向上や即時性の向上などの
メリットが得られます。
個別の機能について、Ver.2 からの改善点をご紹介していきます。
1) ゴミ箱機能
地味ですが、この機能に助けられたという方も多いのではないでしょうか。ご存じ、
ファイルが削除された場合に、一定期間保存する機能を持つフォルダです。
Ver.2 では、CIFS では Samba の実装に含まれる vfs objects = recycle ディレクテ
ィブを利用し、WebDAV では、その動きを模写して Java で独自に実装していました。
Ver.3 では、cscfs3 の機能として実装されていますので、CIFS, NFS, WebDAV, FTP
全てのインタフェースで同じ機能が利用できるようになりました。
2) アクセス権設定
FOBAS CSC で利用可能なアクセス権は、POSIX パーミッションと POSIX ACL ですが、
Ver.2 では、WebDAV では POSIX ACL の利用がサポートされていませんでした。また
参照するアクセス権の格納場所も、CIFS ではキャッシュファイルシステムの属性、
WebDAV はデータベースとなっており、情報反映の時間差がありました。
Ver.3 では、全てキャッシュファイルシステムの属性、および拡張属性の情報を参照
しており、CIFS, NFS, WebDAV, FTP 間で機能の差異や反映の時間差はありません。
また、POSIX ACL もスナップショットデータとして管理されるようになりましたので
ファイルシステムのリストアによってアクセス権が失われる事もなくなりました。
3) ファイルアクセスログ
Ver.3 の目玉機能のひとつとなっているファイルアクセスログです。
Ver.2 までのアクセスログは非常に限られたものでした。WebDAV では、アプリケー
ションのトレースレベルを上げて出力する仕組みであり、CIFS は専門の機能が無い
ため、OS の audit log を取得するしかなく、解析には別途専用のツールの利用が必
要でした。これらはシステムのオーバヘッドも大きく、出力されるログも大量になる
ため現実的な利用は難しいものでした。
Ver.3 では、ファイルシステムのオーバヘッドが全くなく、全てのインタフェースで
利用可能なアクセスログ、および環境変更ログ機能を提供しています。
FOBAS CSC Ver.3 では、差分スナップショットとして、ファイルシステムで行われた
全ての操作と、設定変更を5分間隔でクラウドストレージにアップロードしています。
ファイルアクセスログ、および環境変更ログは、これらの差分スナップショットを
見やすいログ形式でダンプする機能です。
少し余談になりますが、ファイルのアクセス履歴を取得する目的での audit log 設
定例に、open() システムコールのみを記録しているものがあります。Linux のみの
環境であればこれでも良いのですが、Windows クライアントが存在すると Explorer
でディレクトリリストしただけでファイルを open しますので、実際に誰が読み書き
しているのか全く分からないログになります。
もちろん、read(), write() システムコールを含めてトレースすると、大量のログが
出ますので、少なからずパフォーマンスオーバヘッドが発生します。
FOBAS CSC はファイルシステムネイティブに、open() したファイルを実際に read()
write() した時点で、メモリにフラグを立てて、close() のタイミングで ftaskq に
エントリを追加します。これを後で可読できるようダンプするというものですので、
ファイルシステムのオーバヘッドが一切なく、厳密にファイルの内容にアクセスした
記録だけを残すことができます。
4) バージョン管理
Ver.2 でもファイルのバージョン管理機能は高い評価を頂いていましたが、Ver.3 か
らは、ファイル属性の全てがバージョン毎に保持するようになりました。具体的には、
Ver.2 ではファイルサイズと同期完了日、もちろんデータ本体が保持されていました
が、Ver.3 では、全てのタイムスタンプ、パーミッション、所有者、グループ情報、
最終更新者などの情報がバージョン毎に保存されるようになりました。
また、ユーザはWebコントロールパネルから、自身で権限を持つファイルについて自
由に過去のバージョンをリストアできるようになりました。
5) ディスククオータ機能
Ver.2 でもクオータ機能はファイルシステムネイティブの機能として実装されていま
した。しかし使用量が非同期での管理だったため、チェックに即時性が無く、厳密な
管理が難しいというものでした。なぜ非同期だったかは、話が長くなりますので後述
します。興味のある方だけ読んでください。
Ver.3 では、ファイルシステムの属性としてオンメモリで管理されています。もちろ
んチェックポイントで非同期にディスクに永続化されています。それにより通常のフ
ァイルシステム同様に、即時で厳密にクオータチェックや超過の検出、エラーリター
ンが出来るようになっています。もちろん全てのサービスインタフェースで利用可能
です。
さて、Ver.2 がなぜ非同期で使用量管理を行っていたかというウラ話です。
この連載の第１回でエンジン実装での Java EE 利用を諦めた理由として、JPA の楽
観ロックが高スループットトランザクションに耐えられなかった事を挙げました。
その端的な例がこの使用量管理です。クオータの管理は、ユーザ単位だけではなく、
グループやマルチテナントでの組織単位で行っています。つまり複数のユーザが一斉
にデータの書き込みや削除をすると、そのwrite() システムコール毎にクオータ管理
レコードの更新が発生します。これを同期処理で行うと性能が極端に低下するだけで
なく、楽観ロックエラーによるロールバックリトライが多発し、ファイルシステムが
まともに動作しなくなる事態になります。苦肉の策として、JMSキューに容量変更リ
クエストをエンキューし、MDBで容量更新をシリアライズして処理していたというオ
チです。
今になって思えば、JPA にこだわらず、シングルトンのクラスでも作って管理させれ
ばよかったのですが、当時はなぜか頑なに「これでやるのだ」的に意地になっていた
部分もあるのかもしれません。お恥ずかしい話でした。
余談も多くなってしまいましたが、Ver.3 ではアーキテクチャ上もファイルシステム実
装上も無理のない、自然でシンプルな構造になっている事が理解いただけたかと思いま
す。
次回は、Ver.3 大容量サポートのウラ話をご紹介しようと思います。
では、今日はこのへんで。