お知らせ

少し地味な話題ですが、今回は格納データの圧縮について取り上げてみます。

最近のストレージ業界では、格納データの削減と言いますと重複排除機能に注目が
集まっています、FOBAS CSC もオブジェクト(クラウド)ストレージに格納する
データの重複排除を行っていますが、これはまた別の機会に取り上げたいと思います。

データの圧縮はご存じの通り古くからある技術ですが、圧縮・復元に比較的多くの
CPU リソースと処理時間を要するため、かつてはパフォーマンスへの影響が懸念されて
ストレージ I/O のインラインで処理される事は稀でした。

最近は、CPU 性能の向上や、圧縮アルゴリズムの改善、圧縮・復元専用のプロセッサ、
大容量の書き込みキャッシュなどの恩恵により、I/O のインラインで圧縮・復元する
事のパフォーマンスデメリットよりも、データが圧縮される事でディスクデバイスとの
データ転送時間を短縮できるメリットが上回るようになり、多くのストレージシステム
で圧縮処理がサポートされるようになってきています。

FOBAS CSC でも、ユーザが格納したデータをオブジェクト(クラウド)ストレージに
格納する際に圧縮を行っています。FOBAS CSC の場合は、I/O のインライン処理という
よりは、キャッシュ上ではそのままの形で保持されており、クラウドに格納する非同期
タスクの中で圧縮処理を行っています。

さて、世の中で扱われる非構造化データ(ファイル)は、圧縮の効果はどれくらい
あるのでしょうか。かつての非構造化データはアプリケーションがそのまま利用できる
形で格納されており、その結果として圧縮によりデータを非常にコンパクトにできました。

ここ最近では、アプリケーションデータの多くは高度に圧縮された形で格納されて
います。例としては、画像・映像データや、Officeドキュメントなどは、既に圧縮
された形でファイルになっています。

一方、ログデータなどに代表されるテキストデータは、非常に圧縮効果の高いデータ
です。これらを圧縮せずにストレージに格納してしまうのは、リソースの有効活用の
点で望ましいものではありません。

つまり、世の中の非構造化データは、圧縮効果が高いものとほとんど無いものが混在
しているという点に注意が必要です。

 

ブロックレベル圧縮とオブジェクトレベル圧縮の違い

世の中の一般的なストレージシステムは、ディスクブロックレベルで圧縮を行います。
また、FOBAS CSC や Windows Server などは、オブジェクト(ファイル)レベルで
圧縮を行っています。

一見どちらでも良さそうですが、圧縮に必要な CPU リソースという点では、大きく差が
出ます。

先述のとおり、ディスクに格納されるデータには、圧縮の効果が高いものとそうでない
ものが含まれています。あるストレージベンダの圧縮機能では、特定のブロックを圧縮
して、25%以上の圧縮効果が無いブロックは圧縮せずにそのまま格納するそうです。

これは、圧縮による I/O 転送時間短縮のメリットよりも、復元にかかるCPUコストや
レイテンシ増加のデメリットが上回ってしまう事による境界線なのだと思われます。

ブロックレベル圧縮では、25% 以上の圧縮ができるか否かは、圧縮してみるまで分かり
ません。これは全ての格納データを一度は圧縮処理をしているという事になります。

オブジェクト(ファイル)レベルでの圧縮の場合、ファイルの種類(マジックナンバー)
を調べる事で、特定のファイルについては圧縮済みでこれ以上の圧縮効果が期待できない
事がファイルを圧縮しなくても判断できます。

ユーザによって格納するファイルタイプは異なりますので、一概には言えませんが
一般的なオフィスドキュメントを中心に扱うファイルサーバにおいては、ほぼ半数の
ファイルの圧縮が不要であり、そのほとんどはマジックナンバーで判別できるものです。

FOBAS CSC では、オブジェクトベースでの圧縮を採用する事で、無駄な圧縮処理に
CPU リソースを浪費する事なく、全体の性能とリソース使用量の最適化を図っています。

今回は、ストレージ格納データの圧縮について取り上げました。

 


このテクノロジートピックも長らく間が開いてしまいましたが、またボチボチと新しく
追加された機能のご紹介や、その時々の旬な話題について FOBAS の視点から記事に
していきたいと思います。

先日、IT系のイベントに伺う機会がありました。IoT やセキュリティの話題が大きな
盛り上がりを見せていたように思います。

FOBAS が関連しそうなホットな話題で言えば、ランサムウェア対策でしょう。
感染すると、知らないうちにファイルを暗号化してしまい、ファイル複号の身代金と
して金銭を要求するというマルウェアの一種で、ここ最近は被害が爆発的に増えて
います。

FOBAS が得意とするファイルサーバの領域も、ランサムウェアの影響は甚大です。
社内に感染したPCが一台あれば、ネットワーク経由でファイルサーバのファイルを
暗号化し利用出来なくしてしまいます。

イベントでは、多くのセキュリティベンダがランサムウェア対策のソリューションを
出展していましたが、ファイルサーバのランサムウェア対策はどうすれば良いかを
いくつかの展示ブースで尋ねてみました。

残念ながら、ソリューションのほとんどはエンドポイント(端末のPC)への感染を
可能な限り防ぐもので、ファイルサーバの被害を防ぐものはありませんでした。

いずれのブースでも仰っていたのは、ランサムウェアのように次々と新しい種類や
攻撃方法が生まれてくるマルウェアは、完全に感染を防ぐ方法は無いので、感染して
しまった時に被害を拡大しないためのの善後策や、データを失わないための事前の
備え(バックアップ)が重要だという事でした。

まさしくその通りで、バックアップ製品のベンダもここぞとばかりに、きめ細かい
バックアップを取るソリューションや、素早くバックアップをリストアするソリュー
ションをランサムウェア対策としてアピールしていました。

FOBAS CSC もこの部分では非常に強力なソリューションを備えていますのでご紹介
したいと思います。

FOBAS CSC のバックアップの考え方は非常にユニークです。

一般的なバックアップソリューションは、特定時点のファイルシステム全体、あるいは
一部を複製して保存します。例えて言えば、写真を撮るイメージです。

FOBAS CSC では、非常に乱暴な言い方をすれば、バックアップを目的としたデータの
複製はしません。代わりに全てのファイル更新履歴を一定期間保持しています。
例えて言えば、常に動画を録画し続けているイメージです。

これらの更新履歴は、FOBAS CSC の実際のデータ格納場所であるオブジェクト
(クラウド)ストレージで、トリプルミラーなどの方法でデータが冗長保存され
その安全性が担保されています。

Windows のボリュームシャドーコピー(VSS)や、NetApp Snapshot は更新履歴を保持
するという観点では、よく似た機能を提供しています。ファイルに更新があった場合、
既存のデータブロックを上書きするのではなく、新規ブロックに書く事で履歴データを
保持しています。しかしながら、バックアップという視点では特定時点のデータ
ブロックのポインタだけを複製して保存する仕組みであるため、写真を撮るイメージ
である事に代わりはありません。

そのため、本当にきめの細かいバックアップが取得できる仕組みではありませんし、
取得可能な世代数も上限 (255世代など) があるため、きめ細かく取得すれば長期間
保存には限りがでてきます。

また、バックアップデータを保持したブロックが同一ボリューム上に存在する点も
ランサムウェア対策としては、少々不安な部分です。

さて、実際にランサムウェアの被害に遭った場合、これらのバックアップから必要な
ファイル、あるいはファイルシステム全体をリストアする訳ですが、従来のバック
アップ手法では大きく2つの問題があります。

ひとつめは、対象のファイルがいつ暗号化されてしまったのか分からないため、どの
バージョンのバックアップからリストアすれば良いか手当たり次第調べる必要がある点。

もうひとつは、必ずしも暗号化されてしまった直前のバージョンをリストアできる
保証が無いという点です。

ひとつめの課題に関しては、取得したバックアップから対象ファイルがランサムウェア
感染しているか否かを容易に調べる事ができる仕組みなどが提供されている製品も
あるようです。

あるいは、アクセスログの仕組みを持っていれば、当該ファイルのアクセス履歴から
どのタイミングで感染したのかを読み取る事ができるかもしれません。

FOBAS CSC ではファイル毎に、更新履歴の世代が表示され任意にリストアする事が
可能です。アクセスログ機能ももちろんありますが、管理者がそれを調べる事なく、
ユーザ自身で必要なファイルの過去バージョンをリストアする事が可能です。

VSS (NetApp SnapshotもVSSを経由して) でも、ユーザ自身が過去のファイルをリストア
する事ができますが、二つ目の課題は解決できません。一定間隔で保存されている
特定点のバックアップからその時点のファイルを取り出せるだけです。

FOBAS CSC はファイル単位で全ての更新履歴を保持しているので、感染する直前の
ファイルをユーザ自身で取りだす事ができます。

ご利用のPC環境がランサムウェアに感染しないよう、エンドポイントセキュリティは
おろそかにはできませんが、FOBAS CSC でファイルサーバを構築していれば、
万が一の感染でも、ユーザ自身でファイルをリストアし、感染したファイルを削除
すれば復旧が完了します。ユーザ自身の手間を除けば、ファイルの被害はありません。

少し視点を変えて、ファイルサーバが機能不全に至る程の深刻な感染に陥った場合
どの様に復旧できるかを考えてみます。

本来、適切なアクセス権限管理が施されていれば、この様な事態に至る事は稀ですが、
基盤ソフトウェアの脆弱性などを突いたマルウェアであれば、可能性が無い訳では
ありません。

一般的なファイルサーバでは、サーバの完全な初期化を行い、外部媒体に取得した
バックアップから全てのデータをリストアするという手順で復旧する事になります。

ここでは先ほどの2つの課題に加えて、リストアに非常に長時間を要するという
課題が発生します。バックアップ媒体の速度にも依存しますが、10TB程の規模の
ファイルサーバであれば、相当に高価なバックアップソリューションを用いても
24時間程度はリストア時間が必要でしょう。

FOBAS CSC はこの部分でも良いソリューションを持っています。

まず、サーバ全体のリストアですが、元々が仮想マシンイメージなのでテンプレート
から仮想マシンを再構築します。もちろん構築済みの仮想マシンイメージのバック
アップをリストアしても良いかもしれません。

あとは、オブジェクト(クラウド)ストレージからバックアップデータをボタン
ひとつでリストアします。FOBAS CSC のリストアは、メタデータを優先してリストア
しますので、10TB規模のファイルシステムであっても、30分程度でリストアが完了
します。

また、どの時点のファイルサーバの状態に戻すかという問題ですが、最初のファイルが
感染したタイミングをアクセスログ等で確認できれば、例えばその1分前の状態を指定
してリストアする事も可能です。(ポイントインタイムリストア機能)

10TB規模のファイルサーバも、アクセスログの調査を含めて2、3時間あれば、復旧
可能でしょう。

容量が増える一方のファイルサーバのバックアップ、そろそろ方法を考え直す良い
機会ではないでしょうか。

今回は、ランサムウェアによるファイルサーバ被害からの復元というテーマで
お送りしました。

それでは、また次回。


何回かに分けて FOBAS CSC Ver.3 の特徴のご紹介して行くシリーズの第8回目です。

今回は、最近話題のファイルサーバのアクセスログを取り上げてみようと思います。

話題のきっかけは、もちろん皆様もご存じの、某教育コンテンツ企業の大規模顧客情報
流出事件と、某官公庁での個人情報漏えい事故です。詳しい内容は当事者ではありませ
んので触れるつもりはありませんが、情報管理基盤のアクセスログを残す重要性につい
て再認識させられた出来事であった事は間違いありません。

報道によれば、後者の事故では本来システムとしてデータベースで管理されていた個人
情報を、一時的な作業用としてデータ抽出してファイルサーバで保管していた点が問題
の一つとして指摘されていました。

実際の作業生産性を考えた場合、定型的なアプリケーション画面だけではなく、Excel
のようなフレキシブルなツールでデータを扱う事は珍しい事ではないと思います。

そうであるならば、それらのデータを扱う基盤としてのファイルサーバにも必要なせキ
ュリティ対策を施すべきであると考えるのは自然な流れです。

FOBAS CSC でもこのような世の中の流れを受けて、アクセス権の設定 (POSIX ACL サポ
ート) と、ファイルアクセスログ、および環境変更ログの取得をサポートしています。

FOBAS CSC のアクセスログ機能について説明する前に、そもそも従来のファイルサーバ
でアクセスログを取得しようとした場合、どのような方法があったのか簡単にまとめて
みました。

1) Windows Server の場合

Windows Server では、監査ログという機能があります。サーバ内で実行された様々
な操作をイベントログに記録するものです。基本的にはこれを利用するのが OS標準
機能での取得方法です。
この方法はいくつか運用が難しい点があります。まずは大量にログが出るという点で
す。一つのファイル操作で10件以上のログが出ます。また目的のログを探すのもお世
辞にも使いやすいインタフェースではありません。

2) Linux サーバの場合

Linux サーバで有名な方法は、auditd を使ったイベントトレースです。Kernel
レベルでシステムコールをフィルターしてログを記録する事ができます。
これも適用が難しいと思われるのは、必要なログを出力するための設定を専用のコマ
ンドや定義言語で記述する必要があり難易度が高いです。また出力されるログの量も
非常に多くなります。

3) 汎用 NAS の場合

低価格なNASボックス等の汎用NASそのものの機能としては、アクセスログを記録する
仕組みは殆ど備わっていません。
EMC や NetApp 等の高機能な汎用ストレージとしての NAS には監査機能があるため
それを利用する事になります。

一般的には、これらの標準機能ではアクセスログの機能が無かったり、あっても運用が
難しい点が多く、市販のアクセスログツールを組み合わせて使う事が多いようです。
市販のアクセスログ取得製品としては以下のようなタイプがあります。

1) OS、製品標準ログの収集と整形タイプ

前述の OSやNAS標準ログをユーザオペレーションと直感的に結び付けやすい形に集約
し、整形するものです。

2) ネットワークキャプチャ方式

ネットワークでファイルアクセス用のプロトコル (CIFS や NFS) パケットをキャプ
チャして記録するものです。ログの取得対象サーバの変更が不要な点や、ログ取得の
負荷を掛けない点がメリットとされています。
SMB3.0、NFSv4 の暗号化された通信では利用できません。

いずれの方法についても、本来の目的とは違う情報(Kernel のシステムコールトレース
おびただしい量の監査ログ、あるいは、ネットワークパケットダンプ)から、頑張って
ファイルの利用情報を抜き出す、あるいは編集するというものですので、相当泥臭い実
装になっていると思われます。上記製品ベンダの皆様には敬意を表したいですね。

さて、物事をシンプルに考えるのであれば、ファイルの利用について最もよくわかって
いるのは、ファイルを管理するファイルシステムです。FOBAS CSC のアクセスログは、
この非常にシンプルな考え方に基づいています。

シリーズの3回目で少し触れましたが、FOBAS CSC では、いつ、誰が、どのファイルに対
して、何をしたかを差分スナップショットとしてリストア時に適用するために記録して
います。アクセスログ機能はこの記録をわかりやすい形でダンプしただけのものです。

従ってアクセスログのために何か特別な事をしている訳ではありません。本来のファイ
ル利用とは関係ない情報を扱う必要もなければ、冗長なログを出す必要もなく、事実上
オーバーヘッドゼロのログ機能です。

どんな形で出力されるのか、簡単にご紹介します。詳しくはドキュメントにありますの
で併せて参照ください。

出力例)

1: 2015-07-04 10:22:04.768048,OPER_MKNOD,1,1,cscadm,/cscfs3/default/users/cscadm/file2
2: 2015-07-04 10:22:04.769036,OPER_WRITE,1,1,cscadm,/cscfs3/default/users/cscadm/file2
3: 2015-07-04 10:22:04.770455,OPER_READ,1,1,cscadm,/cscfs3/default/users/cscadm/file2
4: 2015-07-04 10:22:04.771048,OPER_MKDIR,1,1,cscadm,/cscfs3/default/users/cscadm/dir1
5: 2015-07-04 10:22:04.786615,OPER_RENAME,1,1,cscadm,/cscfs3/default/users/cscadm/dir1,/cscfs3/default/users/cscadm/dir2

説明のため、実際の出力内容の前に行番号を n: の形で入れました。

共通項目としては左のから、タイムスタンプ(マイクロ秒精度)、操作内容(後述)、
操作クラスタノード、組織番号、操作ユーザ名、となっています。

操作内容は、linux 系のコマンドに明るい方であれば、直観的にわかりやすいかと思い
ますが以下のように読み替えて理解します。ここでは上記ログに含まれているものだけ
記載します。

OPER_MKNOD : ファイルの作成
OPER_WRITE : ファイルに書き込み
OPER_READ : ファイルの読み込み
OPER_MKDIR : フォルダの作成
OPER_RENAME : ファイル名/フォルダ名の変更や、移動

6カラム目以降は、操作によって内容が異なります。1行目から4行目までは、操作対象
のファイル名がフルパスで表示されています。

5行目はフォルダ名の変更なので、変更前、変更後の順番でフルパスで表示されます。

一点、注意が必要なポイントは、出力されるログは必ずしも時系列でソートされていま
せん。時系列でソートが必要な場合は、以下の例を参考に、sort コマンドが利用でき
ます。

# sort -t, -k1.1 {ソート前ログファイル} > {ソート後ログファイル}

今回は FOBAS CSC のアクセスログ機能をご紹介しました。

次回は、監査機能でもう一つ重要なログである環境変更履歴についてご紹介します。
ではでは。


何回かに分けて FOBAS CSC Ver.3 の特徴のご紹介して行くシリーズの第7回目です。
これくらい続くと、ようやく3日坊主と言われるリスクが減ってきました。(^^;

今回は、以前少し予告しましたが、FOBAS CSC が実際どの程度性能が出るのか
試してみようという企画です。

性能の確認と言えばベンチマークプログラムですね。世の中には Disk の I/O 性能を
測定するベンチマークは数多く存在ますが、ここでは filebench を利用してみました。

Filebench は、単にシンプルなシーケンシャル I/O やランダム I/O の性能を計測する
マイクロベンチマークとは異なり、実際の利用を想定したワークロードモデルを作成し
その全体スループットを測定する事ができる非常に柔軟なベンチマークプログラムです。

とはいえ、いろいろな環境で共通のワークロードで比較する事が重要ですので、製品に
標準的に含まれている fileserver ワークロードを利用してテストしてみました。

実際の構築手順を含めてご紹介します。

1) filebench のインストール

事前準備として、ビルドに必要なパッケージをインストールします。
以下の例は CentOS での例です。FOBAS CSC 内部で動かす場合にはインストール
済みのため不要です。

# yum -y install gcc make
http://sourceforge.net/projects/filebench/ から最新のソースコードを
ダウンロードします。本記事記載時の最新バージョンは、1.4.9.1 でした。

# wget http://sourceforge.net/projects/filebench/files/latest/download \
-O filebench-1.4.9.1.tar.gz
ダウンロードしたアーカイブを展開して、コンパイル、インストールします。

# tar xvfz filebench-1.4.9.1.tar.gz
# cd filebench-1.4.9.1
# ./configure
# make
# make install

2) filebench の実行

filebench コマンドを実行すると、filebench 専用のプロンプトが起動します。

# filebench
Filebench Version 1.4.9.1
IMPORTANT: Virtual address space randomization is enabled on this machine!
It is highly recommended to disable randomization to provide stable Filebench runs.
Echo 0 to /proc/sys/kernel/randomize_va_space file to disable the randomization.
17034: 0.000: Allocated 170MB of shared memory
filebench>

プロンプトに対して、実行したいワークロードを指定します。ここでは fileserver
ワークロードを使用します。

filebench> load fileserver
17034: 122.255: File-server Version 3.0 personality successfully loaded
17034: 122.255: Usage: set $dir=<dir>
17034: 122.255: set $meanfilesize=<size> defaults to 131072
17034: 122.255: set $nfiles=<value> defaults to 10000
17034: 122.255: set $nthreads=<value> defaults to 50
17034: 122.255: set $meanappendsize=<value> defaults to 16384
17034: 122.255: set $iosize=<size> defaults to 1048576
17034: 122.255: set $meandirwidth=<size> defaults to 20
17034: 122.255: run runtime (e.g. run 60)
filebench>

表示される Usage に従って、ベンチマーク用のプロパティを指定します。
今回は、テストを行うディレクトリ、スレッド数を変更してあとは初期値を利用しま
した

filebench> set $dir=/cscfs3/default/users/cscadm
filebench> set $nthreads=100

いよいよ実行です。あまり時間が短いと誤差が大きくなり適正な計測ができなくなり
ますので、5分間実行してみました。

filebench> run 300

3) 今回使用した仮想マシン環境および FOBAS CSC バージョンおよび変更プロパティ

純粋にソフトウェアアプライアンスとしての性能を知るために、ハードウェアリソー
スがネックになっては元も子もありません。少し潤沢な(といってもエントリーの
IAサーバより低スペックですが・・・)リソースを使ってみました。

CPU : 2.4GHz 4VCPU (4core 1CPU 相当)
Memory : 4GB
HDD : 20GB SSD (Sequencial I/O 450MB/sec, Random 42,000 IOPS)

FOBAS CSC は Ver.3.1.3 を使用し、以下のプロパティをデフォルトから変更して
います。

USE_RECYCLE = FALSE

4) fileserver ワークロードの内容

ベンチマークに使われる fileserver ワークロードでは、どのような処理が行われて
いるのか簡単に調べてみました。ドキュメントによれば SPECsfs を模したものとの
記述がありますので、文字通りファイルサーバのワークロードをシミュレーションし
たもののようです。スクリプトを読み解くと以下のような処理をしています。

テスト前に 128KB のファイルを10,000個作成

  1. ファイル作成 (with/OPEN)
  2. データ書き込み 128KB
  3. ファイルクローズ
  4. ファイルオープン
  5. ファイルのランダム書き込み 16KB
  6. ファイルクローズ
  7. ファイルのオープン (Random)
  8. ファイル全体の読み込み 128KB
  9. ファイルのクローズ
  10. ファイルの削除
  11. ファイルの存在チェック

これらの一連の処理を並列スレッドで繰り返し行い、実行できたステップ数をカウン
トするというものです。

5) 結果

比較対象として ext4, ext3 そのままと、前回取り上げた s3fs をやってみました。
もちろん、s3fs をこういう用途で使うのはアンチパターンですので念のため。

ext4 6207.362 ops/sec
ext3 5428.292 ops/sec
CSCFS3 2844.107 ops/sec
s3fs 52.499 ops/sec

ext4 や ext3 をそのまま使う場合と比較すると、明らかにオーバヘッドがあります。
とはいえ、アンチウィルスのリアルタイムスキャン、アクセスログ取得、マルチノー
ドクラスタのレプリケーション機能が含まれてこの性能なので、まぁ良しとしていた
だけると嬉しいです。

s3fs をファイルサーバ的に使おうというのも、この値を見るとかなり無理があると
いうことがご理解いただけると思います。
今回は、FOBAS CSC が実際どれくらいの性能が出るのか試してみる企画でした。
2,500 ops/sec 以上が出ていますので、1,000名位のユーザで利用しても、快適に
お使いいただけるレベルではないかと思います。

さて次回は、最近特に話題のアクセスログについて取り上げたいと思います。
それではまた。


何回かに分けて FOBAS CSC Ver.3 の特徴のご紹介して行くシリーズの第6回目です。

今回は、AWSユーザにはお馴染みの s3fs と FOBAS CSC を比較してみたいと思います。

AWS S3 は言わずと知られたオブジェクトストレージであり、ファイルシステムとしては
そのままはマウント出来ません。それを可能にするオープンソースとして有名なのが
s3fs です。

今回、比較をまとめるためにネットをいろいろ検索してみたのですが、s3fs を使って
みたけどイマイチ的な記事やブログが多い事に驚きました。それらの記事やブログの多
くは、s3fs のアーキテクチャや特性を理解せずに、ファイルシステムという断面だけ
を捉えてあまり適さない 使い方をしているものが多いように感じます。

s3fs に限った話ではありませんが、ツールとしての正しい理解がされずに、そのポテ
ンシャルや価値が評価されないのはとても残念に感じます。今回はアーキテクチャを
正しく理解して、適材適所で使う一助になればとも思います。その意味でも s3fs の
ソースコードも軽くハックしてみましたのでそのご紹介も含めます。

FOBAS CSC の中核となっているのは、ファイルシステムである CSCFS3 です。s3fs と
比較するのであれば、むしろ CSCFS3 の方が適切かもしれません。両者、実は同じ
FUSE (Filesystem in Userspace) という仕組みを用いて実装されているファイルシス
テムです。また、データの格納先が S3 をはじめとするオブジェクトストレージという
点でも非常に良く似ています。

もちろん、相違点も多く存在します。それが適用場所の違いに関係してきますので、
まずは主要な違いについて取り上げて、その後にそれぞれに適した利用方法は何かに
ついてご紹介していきます。

相違点その1) オブジェクトストレージへのデータ入出力タイミング(方式)

ファイルシステムに書き込まれたデータをオブジェクトストレージ (AWS S3) に書込
む処理が、s3fs は同期処理で、CSCFS3 は非同期処理で行われているという違いがあ
ります。

s3fs では、ソースを見た限りは、write() システムコールレベルで同期処理をして
いる訳ではなく、ローカルファイルに書き込みをしており、close() 後に S3 に
curl ライブラリを使って PUT しているようです。いずれにしてもファイルの書き
込み完了と共に、S3 にオブジェクトを書き込んで応答します。

CSCFS3 では、ローカルキャッシュに書き込みが完了した時点で応答します。オブジ
ェクトストレージへの書き込みは、非同期で行われます。

同じように、データを読込む時も動きが異なります。

s3fs では、20MB 以下のファイルは必ず S3 からローカルの一時ファイルとしてダウ
ンロードした後に、その一時ファイルをオープンしてユーザに応答します。20MB以上
のファイルは、必要な部分を Multi Part GET してユーザに戻しているようです。

CSCFS3 では、要求されたファイルがキャッシュに存在するかを確認し、存在する場
合はキャッシュの内容を応答します。キャッシュに存在しない場合のみオブジェクト
ストレージからデータを読込みます。もう少し書くと、オブジェクトストレージから
並列処理でブロックデータを先読みし、ユーザにはストリーム処理で要求された内容
を応答しています。

相違点その2) オブジェクトの扱い

もうひとつの相違点は、s3fs ではオブジェクトをそのまま S3 に格納する点です。
言い換えるとファイルシステム上で見えているひとつのファイルは、S3 の上でもひ
とつのファイルです。これにはメリットとデメリットがあります。

メリットは分かりやすいと思います。s3fs を通して格納したオブジェクトは、ブラ
ウザとインターネット接続を使って直接 S3 にアクセスすれば、そのまま利用できま
す。S3 を World Wide の CMS エッジとして利用するのであれば、ファイルがそのま
ま格納できる事は必須要件です。

CSCFS3 はこれが出来ません。理由は後述するデメリットとも関係しますが、オブジ
ェクトストレージの特性を生かしながら、性能、信頼性、可用性、セキュリティなど
様々な機能を実現するためには、このオブジェクトの扱いを妥協する必要があったた
めです。

そういう意味では、s3fs と CSCFS3 は、競合するソリューションではなく、適材適

所で相互補完できるソリューションだと考えています。

さて、オブジェクトをそのまま扱う事に伴うデメリットについてです。ひとつは性能
です。ファイルシステムの構造をそのまま S3 上に構築するためには、ローカルで発
生したファイルシステムイベントをそのままの順序で S3 上に展開しなければなりま
せん。そうでないと論理矛盾がでてしまうからです。簡単な例を挙げれば、フォルダ
を作る処理の後にそのフォルダ内にファイルを作るという処理で、順序通りであれば
問題は発生しませんが、フォルダの無い場所にファイルを作ろうとすれば失敗します。
この事は処理の並列化が困難である事を意味しています。インターネットのようなレ
イテンシの大きなネットワークで処理を並列化できないと性能の影響は非常に大きな
ものとなります。

もうひとつのデメリットは少し難しい話になります。これにはオブジェクトストレー
ジのユニークな特性を理解する必要があります。厳密には、CAP定理だの BASEトラン
ザクションだのという話が関連するのですが、詳しい内容はここでは割愛します。
ご興味がある方は、CSCFS3 のホワイトペーパに多少記述しましたのでご覧ください。

簡単に言えば、オブジェクトストレージは一時的に整合性(一貫性)が取れない状態
が存在するという事です。これは、マルチユーザでの利用や、複数のサーバから同じ
バケットを NFS のように共有して使おうと考えると問題が発生します。シングルユ
ーザであっても、高い頻度でデータの読み書きを行うと、書き込んだはずのデータの
存在が一時的に確認できなかったり、削除したはずのデータが一時的に存在するとい
った問題が発生する可能性があります。

これはオブジェクトストレージの欠点ではなく、高い可用性や分断耐性、拡張性と
いった、従来のRAIDやファイルシステムでは達成できなかった特性のために部分的な
妥協をした結果です。

CSCFS3 では、オブジェクトストレージをオブジェクトを構成するデータブロックの
格納場所としてのみ利用し、上記のオブジェクトストレージの特性に影響を受けない
作りをしています。

相違点その3)その他もろもろ

これは先の2つと比較すれば些細な違いかもしれません。s3fs はファイルシステムと
しての以下の機能が微妙に違いますので利用する際には注意が必要です。

- link 機能が無い(シンボリックリンクは可能ですのである程度の代替は可能)
- ファイルシステムとしての属性取得API statfs() が使えない。
- 拡張属性が利用できない。(POSIX ACL などが使えない)
- ファイルシステムの時間精度は1秒
- NFS export できない。(FUSE Path レベルでの実装なのでちょいと問題あります)

どう使い分けるか

ここまでの説明で s3fs を正しく使うには、以下のような用途には向かない事が理解
いただけると思います。

- 高いI/O性能が求められる用途(細かいファイルの作成・削除は絶望的に遅い)
- 高い頻度で読み書きを行う用途
- マルチユーザでの共有(利用するフォルダ・ネームスペースを分ければ可)
- マルチサーバでの共有(利用するフォルダ・ネームスペースを分ければ可)

これは s3fs の特性というよりは、オブジェクトストレージそのものの特性であり、
s3fs が単に、オブジェクトストレージの API をファイルシステム用のシステムコ
ールでラッピングしたものであるが故の特性です。

多少主観も入りますが、s3fs は以下の用途であれば、低速ですが非常にコストパフ
ォーマンスの優れたソリューションになると思います。

- ログファイル、あるいはバックアップアーカイブの格納場所(サーバあるいはユー
ザ毎にフォルダを分けて格納する)
- S3 を CMSエッジとして利用する際の、マスタサーバからの公開用途

間違っても s3fs を NFS や CIFS の export ポイントとして使ってはいけません。

AWS のサービスであれば EFS(容量単価がかなり高価ですが・・・)のサービスが
始まっていますし、FOBAS CSC のようなストレージゲートウェイであれば、AWS内外
問わず共有ファイルシステムとしての快適な利用が可能です。

2TB を超える容量を使われるのであれば、FOBAS CSC のサブスクリプション費用や、
インスタンス費用を考慮しても、EFSより割安になります。

最後はちょっと宣伝も入ってしまいましたがご勘弁ください。
今日はこのあたりで。

 


何回かに分けて FOBAS CSC Ver.3 の特徴のご紹介して行くシリーズの第5回目です。
今回は、ようやく GA にこぎつけた NFS サポートをご紹介します。

Ver.3.1.3 から、NFS が GA となりました。今までサポートができなかった背景は、詳
しい方はご存じかもしれません。

FOBAS CSC は、CSCFS3 というファイルシステムを、FUSE (Filesystem in Userspace)
という Linux カーネルモジュールとそれを利用するためのライブラリ libfuse を使用
して実装しています。

この FUSE を利用したファイルシステム、通常の ext3 や ext4 と比較しても遜色ない
機能が実現できるのですが、なぜか NFS Export すると特定の利用シーケンスで Kernel
ごとハングしてしまう不具合がありました。FOBASとしてもコミュニティへの不具合報
告や、テストケース提供などを通して問題解決に取り組んで来ましたが、ここにきて
ようやく、最新の Kernel パッチで問題の修正が確認できました。

FOBAS が提供するパッチリリースでは、Kernel Patch を適用する機能は含めていない
ので、NFS をご利用になりたいユーザの方は、Kernel Patch 適用済みの最新のイメー
ジをダウンロードしてお使いください。

さて、FOBAS CSC が提供する NFS インタフェースは、以下の様なセキュリティの観点か
ら NFSv4 に限定しています。

- アプライアンスとしてインターネットゾーンに配置される事も想定し Firewall が
標準で設定されている。NFSv3 以前は UDP ポートを大量に開放する必要があり、潜
在的なセキュリティリスクが高い。

- NFSv3 以前は、ホストベースおよび uid/gid ベースのセキュリティ(アクセス制御)
であるため、IP 偽装や uid/gid 偽装が容易。

現在はほとんどの OS が NFSv4 での接続をサポートしています。NFS クライアント側
の要件で、どうしても NFSv3 での接続が必要な場合は、FOBAS のコンサルティングサ
ービスにご相談ください。

NFSv4 に限定しているという事は、裏を返せば先述のセキュリティの課題を NFSv4 は
解決しているという事になります。NFSv4 に詳しい方には釈迦に説法となりますが、
NFSv4 がどの様に課題を解決しているのか、そして FOBAS CSC の NFS インタフェース
をどのように利用するのか、簡単に紹介していきたいと思います。

1) 通信ポートについて

NFSv3 では、111/udp,tcp 2049/udp 以外にも、mountd, statd, lockd といったプ
ロセスが動的に UDP ポート番号を確保して通信します。このためポート番号でフィ
ルタするタイプの Firewall (FOBAS CSC も iptables を使っています) では、利用
するポートを固定化し、その UDP ポートを解放する必要があります。
NFSv4 では、2049/tcp のみを利用する事になっており、非常にシンプルなポリシー
で Firewall を定義できます。

2) アクセス制御について

NFSv3 では、先に述べたとおり、root 権限を持つサーバのIPアドレスを偽装してマ
ウントしてしまえば、サーバ側のファイルの uid, gid と同じ番号のユーザであれば
ファイルのアクセスは出来てしまいます。no_root_squash で export されていれば
もうやりたい放題です。

NFSv4 では、これらの問題を防ぐ意味で user@domain、group@domain という識別子
を使ってアクセス制御を行います。これだけでは uid, gid という整数が文字列に
置き換わっただけですので、大きくセキュリティが向上したとは言えません。

FOBAS では、NFS クライアントとサーバ間で、ユーザ、グループの識別子を統一する
目的で外部のアカウント管理システム、例えば LDAP を利用します。これにより
LDAP で認証されない限り、特定のユーザ識別子は利用できませんので、ユーザ偽装
を防ぐ事ができます。

加えて NFSv4 では Kerberos を用いた認証統合が利用可能です。Active Directory
でも利用されいてる技術として有名ですが、ユーザは KDC から認証をされると、
認証レルムの中で利用可能なチケットを与えられます。各サーバ(ここでは NFSv4
サーバ)はチケットの有無でユーザ認証を代替しアクセスを許可します。この機能に
よって、NFSv4 は非常にセキュアなユーザ認証の仕組みを提供できる事になります。

FOBAS CSC でも、Kerberos 認証統合をサポートしています。ただし、Kerberos には
ユーザを認証する仕組みはありますが、グループという概念がありません。小規模で
限られたユーザで運用する仕組みであれば管理上の懸念はありませんが、大規模な企
業のファイルサーバ用途となると、グループレベルでアクセス制御を行いたい需要が
存在します。

FOBAS CSC では、その問題を避けるため LDAP サーバとの組み合わせにおいてのみ
Kerberos 認証をサポートしています。

FOBAS CSC での NFS インタフェースの利用方法についても触れたかったのですが、思
いのほかボリュームが大きくなってしまったので、詳しくはドキュメントを参照くだ
さい。実際の NFS クライアントの設定スクリプト等も含め記載がありますので、参考
になると思います。

これまでずっと NFSv3 を使ってきた方からすると、少々繁雑で厄介な設定と感じるか
もしれませんが、設定は慣れの問題だと思います。強固なセキュリティにより、情報の
漏洩や喪失リスクを低減できるのであれば、管理者の心理的負担は低くなり、結果的に
楽ができるものになると思います。

それでは今日はこのへんで。

 


何回かに分けて FOBAS CSC Ver.3 の特徴のご紹介して行くシリーズの第4回目です。

今回は、Ver.3 大容量サポートについて実際の課題と解決法についてご紹介します。

FOBAS CSC はどれくらいのデータを格納できるのでしょうか?

Webページやパンフレットの表記では、Ver.2 から変わらず 4EB(エクサバイト)とし
ています。これは内部的なデータアドレスを掛け算して得られる設計上の理論値です。
もちろん実際に 4EB などというデータ量は途方もないサイズなので、現実味のある数
字としては感じられないと思います。

では、実際に大容量データを格納していくとどのような点でボトルネックになっていく
のでしょうか。Ver.2 で実際にボトルネックになったポイントについて、その理由と
Ver.3 でどのように改善されているかをご紹介します。

1) 連続書込みスループット

当たり前の話ですが、大容量データを扱うためには、FOBAS CSC にデータを格納しな
ければなりません。シリーズの第1回目で触れましたが、データの格納には連続書き
込みスループットという性能が重要になります。格納できるデータ量は、この連続書
き込みスループットと格納時間の掛け算で決まります。

Ver.2 はこの性能が 5MB/sec 程度でしたので、1日ずっと書込みを続けても
5MB * 86400sec = 432GB しかデータ投入できません。1年続けても 157.68TB となり
とても PB(ペタバイト)級の大容量データを扱う事は現実的ではありませんでした。

Ver.3 では、この性能が 20MB/sec にまで向上されています。加えてルーズリークラ
スタ機能により最大128ノードまでスケールアウトし、スループットをリニアに向上
させる事ができます。机上の空論になりかねませんが、128ノードで1日に書込み可能
な最大データ量は、20MB * 86400sec * 128node = 221TB となり、一気に PB 級のデ
ータを扱う現実味が出てきます。

2) メタデータサイズ

FOBAS CSC では、ファイルの属性情報やクラウドストレージへの格納データの情報を
メタデータとして RDBMS (PostgreSQL) で管理しています。このデータベースのサイ
ズは、扱うデータ量に比例して大きくなっていきます。後述するバックアップ時間と
も関連しますが、このデータベースが運用に耐えうる上限がファイルシステムの上限
にもなります。

ドキュメントには、ファイルシステムに格納するデータ量からおおよそのスナップシ
ョットサイズ(メタデータダンプのサイズ)を求める計算式があります。Ver.2 では
0.2% 程度、Ver.3 では 0.05% 程度となっています。(ドキュメントの記載は安全係
数がかかっていますので実際はもっと小さいですが・・・)

Ver.3 ではメタデータサイズが 4分の1 程になっています。かなり地道な容量削減
の努力の賜物です。Ver.3 の DB の中身を見ても恐らくユーザの方は何が入っている
のかよくわからないと思います。

実際のデータベースサイズは、メタデータダンプのおおよそ5倍程度になります。
PostgreSQL のコミュニティには、32TBのデータベースの事例がありますが、運用難
易度やキャッシュの実装容量を考えると、データベースサイズは10TB 以下に抑える
べきと考えます。

そう考えると、Ver.2 では (データ量) * 0.2% * 5 < 10TB から、データ量は 1PB
程度、Ver.3 では (データ量) * 0.05% * 5 < 10TB から 4PB 程度がメタデータサ
イズから考えた実装上のデータ量上限となります。

3) バックアップ時間

FOBAS CSC におけるバックアップは、前述のメタデータダンプをクラウドストレージ
に格納します。この作業が運用時間に収まる事が現実的な運用を考えた場合のもう
一つの制限となります。

Ver.2 では、メタデータ全体のダンプとバックアップを日次処理で行っていました。
つまり先ほどのサイズのファイルを1日以内でクラウドに格納しなければなりません。
オンプレミスに構築したオブジェクトストレージであれば、1Gbps のネットワークを
利用できますのでもう少し限界値は大きくなりますが、インターネット経由での格納
となると 100Mbps 実効速度では 2.5MB/sec 程度でしか格納できないのが現実です。

ここから逆算すると、メタデータダンプのサイズは 200GB 程度が上限となり、Ver.2
で格納できるデータサイズの上限は (データ量) * 0.2% < 200GB から 100TB 程度と
いうことになります。

Ver.3 からは、差分スナップショットが機能追加されました。これによりメタデータ
全体のバックアップは週次処理に変更されています。これにより先述の 100Mbps ネ
ットワークであっても、メタデータダンプのサイズは、1.4TB 程度まで許容できる事
になります。差分スナップショットがサポートされた事で、リストア時間が長くなる
デメリットはありますが、メタデータ全体のバックアップサイクルをより長くする事
も可能です。

少し込み入った計算式も出てきましたが、Ver.3 では PB オーダのファイルシステムを
現実に構築・運用できるものになっている事がご理解いただけたかと思います。

次回は、ようやくGAにこぎつけた、NFS サポートについてご紹介しようと思います。

それではまた。


何回かに分けて FOBAS CSC Ver.3 の特徴のご紹介して行くシリーズの第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 がなぜ非同期で使用量管理を行っていたかというウラ話です。

この連載の第1回でエンジン実装での Java EE 利用を諦めた理由として、JPA の楽
観ロックが高スループットトランザクションに耐えられなかった事を挙げました。
その端的な例がこの使用量管理です。クオータの管理は、ユーザ単位だけではなく、
グループやマルチテナントでの組織単位で行っています。つまり複数のユーザが一斉
にデータの書き込みや削除をすると、そのwrite() システムコール毎にクオータ管理
レコードの更新が発生します。これを同期処理で行うと性能が極端に低下するだけで
なく、楽観ロックエラーによるロールバックリトライが多発し、ファイルシステムが
まともに動作しなくなる事態になります。苦肉の策として、JMSキューに容量変更リ
クエストをエンキューし、MDBで容量更新をシリアライズして処理していたというオ
チです。
今になって思えば、JPA にこだわらず、シングルトンのクラスでも作って管理させれ
ばよかったのですが、当時はなぜか頑なに「これでやるのだ」的に意地になっていた
部分もあるのかもしれません。お恥ずかしい話でした。

余談も多くなってしまいましたが、Ver.3 ではアーキテクチャ上もファイルシステム実
装上も無理のない、自然でシンプルな構造になっている事が理解いただけたかと思いま
す。

次回は、Ver.3 大容量サポートのウラ話をご紹介しようと思います。
では、今日はこのへんで。

 


何回かに分けて FOBAS CSC Ver.3 の特徴のご紹介して行くシリーズの第2弾です。
3日坊主にならないように頑張ります。(^^;

今回は前回の予告通り、アーキテクチャの変更による具体的なメリットについてご紹介
していきます。

■アーキテクチャの変更

前回も触れましたが、Ver.2 では、Javaアプリケーションサーバ (jboss) をベースに
実装の全てが JavaEE の EAR としてパッキングされていました。

これは、アプリケーションをまとめてライフサイクル管理できたり、クラスローダ階層
を自由にコントロールでき、FOBAS CSC のようにオープンソースライブラリを多用する
アプリケーションには大きなメリットがありました。

ただ、ライフサイクルをひとつに出来る事は、FOBAS CSC のようなインターネット接続
を用いるアプリケーションにとっては諸刃の剣で、ネットワークの不測の障害や、アプ
リケーションの些細な問題で、ログレベルを変更したり再起動したいニーズは発生しま
す。その際に、ユーザから見て最も重要なファイルシステムサービスも停止してしまう
という問題がありました。

Ver.3 では、C言語実装への変更に伴い、ファイルシステムサービスとバックグラウンド
サービスのプロセスを分離し、バックグラウンドの問題やサービス停止がファイルシス
テムに影響しない構造にしました。

FOBAS CSC Ver.3 では、以下のプロセス構造を持っています。

1) cscfs3 (cscis3) ファイルシステム(iSCSIデバイスファイル) 実装

FUSE Low-Level API を用いたファイルシステム実装です。Ver.2 では High-Level
API を JNI でブリッジし、Java でエンジン処理が記述されていました。JNI コール
によるコンテキストスイッチコストが大きく、Ver.2 の性能ボトルネックになって
いました。Ver.3 では全て Native C で実装されていますので、ボトルネックが解消し
快適な性能で利用できるようになりました。

2) cscftaskd メタデータ更新機能(クラスタレプリケーション機能)実装

ファイルシステムの変更点をメタデータに反映する処理を担います。
cscfs3, cscis3 とは、ftaskq キューで非同期接続されています。このメッセージを
取り出して、メタデータを管理するデータベースを更新します。

さらに、5分毎にメッセージをアーカイブして、マスタテーブルの更新差分と併せて
クラウドストレージにアップロードします。これが差分スナップショット処理です。

別のスレッドでは、5分毎にクラウドストレージに他のクラスタノードの差分スナッ
プショットファイルが存在しないかチェックしています。ファイルがあればダウンロ
-ドしてデータベースを更新します。

3) cscsyncd ステージデータ作成機能実装

ファイルシステムに格納されたデータをクラウドに格納する形式に加工する処理を担
います。
cscftaskd とは、syncq キューで非同期接続されています。クラウドへの格納対象フ
ァイルを分割、圧縮、暗号化します。

4) cscslaved クラウドデータ入出力機能実装

クラウドストレージなどのバックグラウンドストレージとのデータ入出力を行います。
cscsyncd とは、slaveq* キューで非同期接続されています。存在するストレージサー
ビス数分のキューが存在し、それぞれにスレッドが起動されています。

実際のストレージへ格納するためのプログラムは、Java の SPI に合わせて実装され
ているため、JNI 経由で呼び出す構造になっています。ストレージへのコネクション
コストを下げるため、コネクションプールが実装されています。

cscslaved はもうひとつ重要な機能があります。格納データの重複排除です。各スレ
ッドは、データの格納前にハッシュ値とバイナリの比較により重複するデータの格納
を回避します。

バックグラウンドプロセスは、キャッシュアウトされたファイルのロード処理
(cscslavedが実行)を除いては、ファイルシステム実装とは切り離されており、一時
的なプロセス停止の影響はありません。

ファイルシステム実装を含む全てのプロセスは、cscfs3_mater デーモンにより 10秒間
隔で死活監視され、プロセス障害時には自動的にリカバリされます。

ユーザ視点で見た場合のメリットは、「障害やメンテナンスによるサービスへの影響が
小さくなった」とという短い一文で終わってしまうのですが、システムを保守する視点
から見れば、非常に大きな改善なのではないかと思います。

第2回目は、プロセスアーキテクチャの変更に伴う改善点についてご紹介しました。
次回は、様々な機能がファイルシステムネイティブでサポートされるようになった点を
ご紹介します。

 


先週末、FOBAS CSC Ver.3 の最新版、Ver.3.1.3 がリリースされました。

FOBASコンサルティングも、おかげさまで6月から6期目に入り、このお知らせも最近は
随分更新せずに放置されていましたので、今後出来るだけタイムリーな情報提供をして
いこうと考えています。

まずは、今さら感がありますが何回かに分けて FOBAS CSC Ver.3 の特徴のご紹介して
いきたいと思います。

と言っても表面的な事はホームページをご覧いただければ良いと思いますので、少々
技術的な中身や開発のウラ話に触れながらご紹介したいと思います。

■エンジン実装言語の変更

FOBAS CSC Ver.2 では、ファイルシステムの中核部分が Java もう少し言えば、Java EE
の技術をフル活用して実装されていました。これは以下の理由によります。

- データの格納場所(クラウドストレージ)へのアクセス方法(API) について、最も
多くのストレージプロバイダが Java のライブラリを提供していた事。
- アプリケーション開発の生産性が Native C 言語と比較して圧倒的に高い事。

Java EE は、システム開発の複雑でプリミティブな部分を隠蔽、抽象化し、素早く高機
能なアプリケーション開発を可能にする素晴らしいフレームワークです。
しかしながら、FOBAS CSC が多くのお客様で利用される中で以下のような点でプログラ
ミングフレームワークとしての限界を感じるようになりました。

- 100tps を超えるトランザクションで、JPA の楽観ロックに起因するロールバック・
リトライコストの影響が大きくなった。
- CMT によるトランザクション時間で処理しきれないものが出てきた。
- JMS エンジンの絶対性能やメッセージ数の実装上限を超えるリスクが出てきた。
- 暗号化や圧縮処理の絶対性能が不足した。
- サービス起動時間が長かった。

結果として、Ver.3 からは、エンジンのほぼすべてを C言語で書き直しています。

誤解が無いように補足しますと、Java EE がダメと言っているのではなく、適材適所が
重要かなという話です。

Ver.3 でも、Webコントロールパネルは、Java Servlet, JSP, JPA を利用していますし、
RestAPI では、JAX-RS, JAXB, JSONバインディングも利用しています。

C言語での実装は、開発に必要な時間、コストが増加しましたが、前述の限界をブレーク
スルーできました。

具体的なメリットとしていくつか挙げられます。

1) ファイルシステムスループットの向上

Ver.2 では、概ね200TPS程度が処理性能の上限でした。Ver.3 では、概ね3,000TPS
程度の性能が達成できるようになりました。これは別の機会に実際のベンチマーク
結果を含めてご紹介したいと思います。

上記は単体ノードでの性能ですので、Ver.3 のルーズリークラスタを用いてノード数
を増加すれば、さらにスケーラブルにシステム全体のスループットを向上させる事が
できます。

2) 連続投入スループットの向上

ここでは、ファイルシステムスループットをユーザが読み書きする性能の意味で用い
ていますが、FOBAS CSC はクラウドストレージゲートウェイですので、クラウドスト
レージへの書き込み性能も重要な性能指標となります。弊社ではこれを連続投入スル
ープットとしてスペック表記しています。

Ver.2 では、5MB/sec (40Mbps) 程度が連続投入スループットの上限でした。圧縮や
暗号化を行うと、さらに性能が下がり、1.5MB/sec (12Mbps) 程度が実効性能となっ
ています。Ver.3 では、最大で20MB/sec (160Mbps) 程度まで性能が向上しました。

こちらも、ルーズリークラスタ機能でノード数に応じてリニアに性能向上できます。

3) 起動時間の短縮

Java EE を使う場合、コンテナであるアプリケーションサーバが必要になります。
Ver.2 では、JBoss 5 を利用しており起動に概ね1分程度の時間がかかっていました。
JMSキューにメッセージが大量に溜まった状態ですと、さらに起動時間がかかり、特
に HAクラスタ構成時のフェールオーバ時間を2分以下に短縮できないという限界があ
りました。

Ver.3 では、C言語による実装の恩恵に加え、ファイルシステムインタフェースとなる
プロセスとバックグラウンドプロセスを分割した事で、1秒程度でファイルシステムが
起動できるようになりました。

これにより、HAクラスタ構成でも、障害の検知時間を含めても30秒以内のフェールオ
ーバーが可能になります。
初回は、実装言語の変更による具体的な改善点についてご紹介しました。次回はアーキ
テクチャの変更によって、具体的に改善された点をご紹介していきたいと思います。

では、本日はこのへんで。

 


ページトップへ戻る