お知らせ

何回かに分けて 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名位のユーザで利用しても、快適に
お使いいただけるレベルではないかと思います。

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


『おしえて、クリス先輩』は頼りないがヤル気だけはあるチャーリーがクリス先輩にクラウドの知識、CSCの仕様を教えてもらいながらクラウドにファイルサーバを構築する奮闘記である。

 

 

 

チャーリー

あたふた、あたふた(汗)

クリス先輩

そんなに慌ててどうしたんだい?

チャーリー

構築したばかりのファイルサーバがHDD障害で起動しなくなっちゃって・・・

メーカーに新品のHDDに交換してもらったんですが、データは消えちゃってますよね。(TT)

 

 

 

 

 

(なんて都合がいいシナリオなんでしょう~ ^^;

 

 

 

クリス先輩

それは災難だったね。じゃあ、スナップショットから復旧しよう。

チャーリー

えっ!? 特にバックアップとか取ってないんですけど~

クリス先輩

大丈夫。(^^) FOBAS CSC は何もしなくても自動的にクラウドにスナップショットというバックアップを取っているんだ。

第一話でも話した秘密鍵があるよね?その秘密鍵があればスナップショットからデータを復元することができるんだよ。

チャーリー

へぇ~っ、データもバックアップも全部クラウドにあるから大丈夫って事なんですね。

クリス先輩

その通り。FOBAS CSC の仮想マシンイメージを新規で展開して、秘密鍵を使ってスナップショット戻せば元通りに復旧できるのだよ。

チャーリー

なんだかクラウドってすごいですね。

クリス先輩

うむ。では、早速やってみよう。

チャーリー

はい、クリス先輩!

 

 

わっせ、わっせ。(復旧中) 詳しくはここ 『秘密鍵からリストア』 を見てね。

 

 

 

クリス先輩

FOBAS CSC は自動的に週1回の全体スナップショットと、5分毎に差分スナップショットを取ってクラウドストレージに保存しているんだ。

HDD障害で止まる5分前の状態まで戻せるはずだよ。

チャーリー

それなら、ほとんどのデータは残ってるはずですね。本当に助かりました。(TT)

クリス先輩

一般的なファイルサーバのバックアップは特定点のもので、例えるなら写真みたいなものだね。FOBAS CSCのスナップショットはずっと連続的に取ってる訳だから、動画に例えるとわかりやすいかな。

チャーリー

要するにデータの連続性が保存されていて、任意の時間を指定して戻せる。ってことですね!

クリス先輩

そうそう、録画してあるから好きなところで止められる。ああ~っ!!録画。。。

チャーリー

クリス先輩、どうしたんですか?

クリス先輩

「ダウントンアビー」を録画予約するの忘れてたぁああ(泣)

チャーリー

クリス先輩、ドンマイ。

 

 

 

 

 

To be continued(^^;


報道関係者各位
プレスリリース

2015年6月23日
FOBASコンサルティング株式会社

 FOBASコンサルティング、
高速クラウド移行ソリューション「FOBAS DARP」の提供を6月23日に開始。
クラウドへ短時間でアプリケーション移行・再配置が可能なプラットフォーム。

FOBASコンサルティング株式会社(所在地:東京都港区、代表取締役:松下
悟、以下 FOBAS)は、インターネットで接続可能な分散された環境で、アプリケーションを自在に再配置可能にするプラットホーム「FOBAS DARP(Distributed Application Relocatable Platform)」の提供を2015623日に開始いたします。

 

FOBAS DARP」: http://www.fobas.jp/products_darp_summary.html

 

■背景
クラウドファーストという考え方が定着し、企業の様々なシステムがクラウド基盤に構築・移行されるようになりました。その工程でシステムの移行、特にインターネットを経由したデータの移行には長い時間を要し、業務サービスへの影響が大きい事が課題として認識されています。

また、初期費用なしで容易に始められるというクラウドの利点に反して、本格的な採用に向けたクラウド事業者の選定は、非常に高度なビジネス判断が求められます。これは、特定のクラウドでシステムを稼働してしまうと別のクラウドへの移行やオンプレミスへの回帰が非常に困難になる事が理由として挙げられます。

このような背景から、オンプレミスからクラウドへ、クラウドからクラウドへ、システムの移行や再配置を容易にするソリューションが望まれていました。

 

■「FOBAS DARP」の機能
1) わずかなサービス停止時間で、安全、確実なクラウド移行が可能
「FOBAS DARP」は、企業の基幹システム移行に求められる、最小限の停止時間で安全、確実な移行方法を提供します。「FOBAS DARP」を用いたクラウド移行では、OSおよびプログラムバイナリの移行と、アプリケーションデータの移行を分離して行うアプローチを採用しています。これにより、OSおよびプログラムは移行先環境での十分な稼働確認を行う事ができます。アプリケーションデータは、「FOBAS DARP」が提供するレプリケーション機能により、わずか10分程度の遅延で移行先での利用が可能になります。

 

2) クラウド間での容易なシステム移行・再配置の実現
「FOBAS DARP」に配置されたアプリケーションは、様々なクラウド基盤に配置されたDARPコンテナ上で自在に移行・再配置する事が可能になります。移行・再配置にかかる時間は、10分間のデータ同期遅延時間のみです。DARPコンテナは、最大128ノードのクラスタ構成でインターネット接続可能な任意の環境に配置が可能です。

 

3) クラウド時代の新しいデータ管理基盤を提供
「FOBAS DARP」に格納されたアプリケーションデータは、圧縮、重複排除、暗号化された後に、複数のクラウドストレージに分散格納されます。データはクラウドストレージの機能で高度に冗長化され、低コストで高い保全性が保証されます。また、予め指定した期間のデータを履歴で保持するため、保持期間中の、どの時点のスナップショットでも、後から必要な時に必要な粒度で作成が可能です。クラウドの持つ力を最大限に活用した、新時代のデータ管理基盤を提供します。 

 

FOBAS DARP」:http://www.fobas.jp/products_darp_summary.html

※価格については、個別に相談

 

■FOBASコンサルティング株式会社について
FOBASは、IT基盤、クラウド・コンピューティングを専門とするコンサルティング会社であり、日本国内におけるクラウド・ストレージ・ゲートウェイ製品のパイオニアです。
詳細は、FOBASコンサルティング株式会社のWebサイト( http://www.fobas.jp/ )をご参照ください。

 

■本リリースに関するお問い合わせ
FOBASコンサルティング株式会社
〒105-0003 東京都港区西新橋一丁目18番6号 クロスオフィス内幸町607
E-mail: sales@fobas.jp

 

 


何回かに分けて 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より割安になります。

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

 


   『おしえて、クリス先輩』は頼りないがヤル気だけはあるチャーリーがクリス先輩にクラウドの知識、CSCの仕様を教えてもらいながらクラウドにファイルサーバを構築する奮闘記である。

 

 

 

チャーリー

せっせ、せっせ・・・・

クリス先輩

随分忙しそうだね。

チャーリー

先週、クリス先輩に教えてもらって FOBAS CSC をインストールしたのでみんなが使えるようにアカウントの作成をしてるんです。でも人数が多いと結構大変ですね。組織に合わせてアクセス権も付けなきゃいけないし・・・

クリス先輩

FOBAS CSC は社内のActiveDirectory を利用してユーザアカウントの連携ができるって知ってるかな?

チャーリー

と言うことは?

クリス先輩

FOBAS CSCにいちいちユーザやグループを作らなくても良いんだ。PCにログオンすればシングルサインオンでそのまま FOBAS CSC にもアクセスできるし。

チャーリー

画期的ですね!

クリス先輩

そうなんだ。何度もユーザID/パスワードを入力しないですむからオンプレミスと変わらずシームレスにクラウド環境が利用できるんだよ。

チャーリー

じゃあ、既存のActiveDirectoryで管理しているユーザ、グループ情報を基にフォルダ、ファイルのアクセス権を設定できるんですね!

クリス先輩

その通り。ではやってみよう。

チャーリー

はい、クリス先輩!

Webコントロールパネルで「ActiveDirectoryで管理する」を設定して、ファイルエクスプローラでフォルダを新規作成して、右クリックのプロパティ、セキュリティから権限を付与して・・・

 

 

簡単、簡単。(^^)   詳しくはここを見てね。

 

 

 

クリス先輩

CIFSの場合は「\\<NetBIOS>\public」の配下にグループフォルダを作成して、グループの権限を付与しよう。

 

 

 

 

 

\\<NetBIOS>

 

 

 

 

 

public

 

 

 

 

 

(グループフォルダ)

 

 

 

 

 

(ユーザフォルダ)

 

 

 

 

 

ユーザフォルダは各ユーザがログオンした時に自動的に作成されるんだよ。

チャーリー

では、全部署のフォルダを作成したので、クリス先輩も所属部署のフォルダにアクセスしてみてください!

クリス先輩

どれどれ。・・・あれ?アクセス拒否されたぞ。

チャーリー

ええーっ!? クリス先輩、もしかして先般の組織変更で部署が変わったんじゃないですかぁぁぁ?

クリス先輩

・・・

チャーリー

だって、フォルダのアクセス許可にちゃ~んとグループが追加されてますよ!

クリス先輩

えーっと、グループに対してフルコントロール権限を付与したのかな?

チャーリー

失礼しました~!(汗)

 

 

 

 

 

To be continued(^^;


何回かに分けて 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 サポートについてご紹介しようと思います。

それではまた。


  『おしえて、クリス先輩!』は頼りないがヤル気だけはあるチャーリーがクリス先輩にクラウドの知識、CSCの仕様を教えてもらいながらクラウドにファイルサーバを構築する奮闘記である。

 

 

 

クリス先輩

どうしたの?困った顔して。

チャーリー

あ、クリス先輩。それが、ファイルをバックアップから復元しようとしたのですが、バックアップ用のHDDが壊れててファイルを復元できない上にHDD修理の見積もりを取ったら結構な金額になって。。。

クリス先輩

それは困ったね。外付けHDDは安価で手軽に設置でき大容量を読み書きできるメリットがあるけど、装置故障を想定した運用に工夫がいるね。クラウドにファイルサーバを構築すれば、冗長化もしてるしバックアップも自動的にしてくれるよ。

チャーリー

クラウドって難しくないですか?

クリス先輩

クラウドストレージゲートウェイ製品のFOBAS CSCでつなげば簡単にクラウドファイルサーバが構築できるよ。

チャーリー

じゃあ、やってみます!

クリス先輩

FOBAS CSCは主要クラウドストレージサービスはほとんどサポートしているから、業者を選定してアカウント契約しておいてね。

チャーリー

はい!

 

 

 

 

 

1週間後>

 

 

 

クリス先輩

今日はFOBAS CSCを使ってクラウドに社内ファイルサーバを構築する方法を覚えよう。

チャーリー

はい、クリス先輩。FOBAS CSCは仮想マシンアプライアンスなんですよね。ということは、オンプレミス環境に仮想マシンを用意するんですね。

クリス先輩

うん、そうだね。仮想マシンソフトはVMWareHyper-VCitrix
Xen
等もカバーしているから対応バージョンは最新のドキュメントで確認しよう。

チャーリー

今回はVMWareESXiで構築することにします。最新のFOBAS CSCの仮想マシンイメージはHPからダウンロードできました!

クリス先輩

あとは、最適なリソースを算出するためのサイジングシート、環境設定プロパティシートを見ながらインストール手順書に従えば簡単だ。クラウドストレージサービスの契約は済んでいるのかな?

チャーリー

はい、アカウント情報も入手済みです。

 

 

 

 

 

(インストール中。。。わっせ、わっせ!)詳しい手順はここを見てね。

 

 

 

 

 

できた。

クリス先輩

次はクライアントPCからクラウドにつながっているか見てみよう。

ファイルエクスプローラのアドレスバーに「\\<NetBIOS >\public\」を入力してごらん。

チャーリー

フォルダが見えます!これがクラウドの中なんですね。普通のファイルサーバと同じですね。

クリス先輩

FOBAS CSCはクラウドストレージが提供する専用のAPIを身近なインターフェース(WebDAVCIFSNFSFTPなど)に変換してくれるからファイルエクスプローラから直接クラウドストレージを利用することができるんだ。

チャーリー

へぇ~、すっごいですね!

クリス先輩

それだけじゃないんだ。FOBAS CSCはキャッシュ機能があり、インターネット経由で利用するクラウドストレージへのパフォーマンスを補完してるんだ。

チャーリー

だから社内ファイルサーバのようにサクサクとアクセスできるんですね。

クリス先輩

セキュリティ対策も万全さ。FOBAS CSCが読み込んだデータは一定のブロックサイズに分割、暗号化してからクラウドに分散配置されるんだ。しかも、暗号化鍵はユーザが保持するから、データの実態は外部にあっても復号化する鍵は別なところにあるから安全なんだ。

チャーリー

画期的ですね!

クリス先輩

クラウドのメリットでいえば、オンプレミスファイルサーバの課題にありがちな拡張性、耐障害性、可用性についても柔軟で高いサービスを提供してくれる。これからのITは省スペース、省エネルギーを目指さないと。

チャーリー

:

クリス先輩のお腹も省スペース、省エネルギーになるといいですね!

クリス先輩

:

・・・

 

 

 

 

 

To be continued(^^)


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

 


ページトップへ戻る