お知らせ

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

最近のストレージ業界では、格納データの削減と言いますと重複排除機能に注目が
集まっています、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時間あれば、復旧
可能でしょう。

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

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

それでは、また次回。


誠に勝手ながら、2015年12月26日(土)~2016年1月3日(日)まで、FOBASコンサルティング株式会社は年末年始休業とさせていただきます。

ご不便をおかけしますが、何卒ご理解いただきますようお願い致します。

24時間サポートサービスをご利用のお客様は所定の方法でご連絡ください。

また、電子メールでいただきましたお問い合わせにつきましては、2016年1月4日(月)以降に順次対応させていただきます。


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

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

FOBASコンサルティング、
統合ファイルサーバアプライアンス「FOBAS CFSA」の販売を8月25日に開始

~ キャッシュゲートウェイ採用 クラウド型ファイルサーバサービス ~

 

FOBASコンサルティング株式会社(所在地:東京都港区、代表取締役:松下 悟、以下 FOBAS)は、クラウド型ファイルサーバサービス「FOBAS CFSA(Cloud File Server Appliance)」の販売を2015年8月25日(火)に開始いたします。

 

「FOBAS CFSA」: http://www.fobas.jp/products_cfsa_summary.html

 

■背景
近年、ファイルサーバは企業における基本的な情報基盤として、その重要性は非常に高くなっています。加えて、格納される情報の重要性や機密性も高くなり、求められる機能要件も非常に高度かつ複雑になってきています。
極めて高価、高機能な統合ストレージ製品の中には、多くの機能を標準で備え導入すればすぐ利用可能になるものも存在します。しかしながら、限られた投資の中で、高度かつ複雑な要件を満たすファイルサーバを顧客自身が構築し、維持管理するのは容易なことではありません。

そこで、ファイルサーバをクラウドで提供するサービスが多く登場しています。クラウドファイルサーバサービスは、提供する事業者がファイルサーバに求められる機能を、予め設定済みの状態でサービス化して提供するため、必要な機能がすぐに使えるメリットがあります。
反面、インターネット経由あるいはVPN-WAN経由で利用することに起因する性能、あるいはスケーラビリティの制限や、サービスの容量単価が比較的高価である点などから、導入に踏み切れない企業も数多く存在します。
このような背景から、高い性能やスケーラビリティを実現しながら、リーズナブルな容量単価で利用できるクラウド型ファイルサーバが求められています。

■「FOBAS CFSA」の特長
FOBAS CFSA(Cloud File Server Appliance)は、クラウド型のファイルサーバサービスです。従来のサービスとの相違点は、お客様ネットワークに専用のキャッシュゲートウェイ装置を設置する点です。それにより以下のようなユニークな特長があります。

1) 高速、快適な性能とスムーズな認証統合
キャッシュゲートウェイを経由することにより、従来のクラウド型ファイルサーバの問題点であった、WANネットワークの影響を極小化し、極めて快適な利用性能と、顧客拠点のADとのスムーズな連携を可能にします。キャッシュゲートウェイハードウェアには大容量の高速SSDを搭載し、マルチユーザ利用時でも極めて高いパフォーマンスを提供します。

2) 必要な機能をすぐに使用可能
クラウド型ファイルサーバの特長である「必要な機能がすぐに使える」ことで、ファイルサーバに求められる全ての要件を満たしながら、構築におけるリードタイムを短縮し、SIコストとリスクを低減します。
オプション機能は、コントロールパネルから有効にすることで即日利用可能になります。(DRオプションはデータセンタ内にサーバを構築しますのでお時間がかかります)

3) スムーズで高い拡張性
同一キャッシュゲートウェイでの容量追加は、サブスクリプションの契約変更のみで即日行えます。キャッシュゲートウェイの容量上限を超える場合は、キャッシュゲートウェイのアップグレードが必要になりますが、格納されたデータの移行は必要ありません。新しい筺体にバックアップを復元するだけで30分程度で交換が完了します。小規模モデルでは概ね100ユーザ、4TBまで、中規模モデルでは概ね1,000ユーザ、10TBまでご利用いただけます。

4) クライアントゼロインストール
キャッシュゲートウェイがネットワーク通信の暗号化を行いますので、利用するクライアントにVPNなどの専用ソフトウェアを導入する必要はありません。従来のNASと同様にWindows ExplorerやMac Finderから直接利用が可能です。
また、クラウド型ファイルサーバに多い、クライアント数による課金がありません。キャッシュゲートウェイの性能が許す限り、柔軟に利用ユーザ数を増やすことが可能です。

5) 業界最高レベルのコストパフォーマンス
主要クラウド事業者の国内データセンタを利用しながら、15,000円/1TB/月という業界最高レベルの低コストを実現しました。増え続ける企業データをコスト面でしっかりサポートします。

■サービス主要機能
・アクセス権設定
・データ暗号化(AES256bit)
・通信経路暗号化(TLS1.x)
・5分間隔の差分データバックアップ
・バックアップ簡単リストア
・以前のバージョンの復元
・ゴミ箱機能
・Web管理画面
・Windows Explorer/Mac Finderから直接利用可能
・ファイルの直接編集が可能
・主要クラウド事業者の国内データセンタを複数分散利用

■提供価格(税別)
<小規模モデル>
ユーザ数       :~100名くらいまで
データ容量      :~4TBまで
ハードウェア(初期費用):¥198,000
データ課金(月額費用) :¥15,000/1TB/月
ハードウェア冗長化  :オプション(個別見積り)

<中規模モデル>
ユーザ数       :~1,000名くらいまで
データ容量      :~10TBまで
ハードウェア(初期費用):¥1,500,000
データ課金(月額費用) :¥15,000/1TB/月
ハードウェア冗長化  :標準

<オプション機能>
AD連携        :¥20,000/月
アクセスログ     :¥10,000/月
アンチウィルス    :¥5,000/月
WebDAVアクセス    :¥5,000/月
DR(コールドスタンバイ):¥50,000(初期費用)
:¥10,000/月(小規模モデルの場合)
:¥30,000/月(中規模モデルの場合)
DR(ホットスタンバイ) :個別見積

 

「FOBAS CFSA」詳細URL: http://www.fobas.jp/products_cfsa_summary.html

 

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

 


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

 

 

 

チャーリー

のほほ~ん。

クリス先輩

あれ、今日は珍しくゆったりしてるね。(笑)

チャーリー

あ、クリス先輩。お盆休みでちょっとヒマしてますよ。社内も静かだし。

クリス先輩

そうだな~。すっかりお休みモードだなぁ。

お休みと言えば、この時期はマルウェアの検出数が増えるって知ってた?

チャーリー

それは。。。お休みで時間をもてあましている人がウィルスを仕掛けるからとか。

クリス先輩

確かにそういう可能性も否定できないけど。。。(^^;

休暇中はPCを停止するでしょ。マルウェアのパターンファイルが更新されないことで、休み明けにPCを起動したときに感染するリスクが高まるんだって。

あとは自宅で仕事するために外部記憶媒体でファイルを持ち出して、ウィルスを一緒に職場に持ち込むパターンが多いみたい。

チャーリー

ああ、そんな話を聞くと休み明けが憂鬱だなぁ。(TT)

そういえば、クラウドファイルサーバではウイルス対策はどうなってるんですか?

クリス先輩

FOBAS CSC では、標準で Clam AntiVirus
というウィルススキャンエンジンが組み込まれているよ。パターンファイルは11回自動的に更新されるようになっているから休暇中でも問題ないね。

自宅からファイルを使うなら外部媒体で持ち出すよりは、WebDAV I/F 経由で直接ファイルを編集した方がいいね。外部媒体のように紛失して情報漏えいするリスクはないし、自宅のPCにデータを保存する必要もない。

ファイルを更新する時にはサーバがリアルタイムでウィルススキャンしてくれるからウィルスが持ち込まれるリスクも低減できるね。

チャーリー

なら休み明けも安心ですね!

※ローカルPCのウイルス対策は別途必要です。あしからず。(^^)

クリス先輩

アンチウイルスの導入も大事だけど、根本的に企業として情報セキュリティに対する意識を高く持ち、ITIT以外のユーザも含めたセキュリティレベルの向上が必要だね。

チャーリー

日々精進なり。です。

そうだ。お盆と言えば、クリス先輩知ってます?

最近は「お盆玉袋」っていうのが出ているらしいですよ。

クリス先輩

お、おぼんだまぶくろ?

チャーリー

はい、要するにお盆版のぽち袋ですよ。ルーツは古くからあるらしいんですが、新たな習慣が認知されつつありますね。

クリス先輩

子供達のお小遣いもすっかりインフレ気味だね。甥っ子姪っ子にオネダリされないように夏休みは「う居留守」でも使って注意しないと。

チャーリー

・・・・・・(さぶっ)

クリス先輩

やっぱり、お盆休みのオフィスが静かで平和だなぁ~

チャーリー

クリス先輩、ドンマイです。

 

 

 

 

 

To be continued(^^)


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

 

 

 

チャーリー

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

クリス先輩

いつも忙しそうだねぇ。今日はどうしたんだい?

チャーリー

あ、クリス先輩。んも~っ、大変です!

我が社のWeb受発注システムのH/W保守切れが迫っていて、クラウド化したファイルサーバが好評なものだから、このシステムもクラウド化できないかって。

クリス先輩

おっ、いいね!人気者っ!!

チャーリー

あ、いや、だって過去の注文履歴のデータだけでも10TBくらいあって、24時間365日稼働してるんですよ。(TT)

考えてみてくださいよ、クラウドはインターネット経由でデータを移行しないといけないんですよ。10TBのデータを転送するのに何日かかることやら。

その間、システムサービスを止めるか、少なくとも過去の注文データが参照できない事になります。あぁ、でもそんなのあり得ないし。

クリス先輩

大丈夫だよ。FOBAS DARPを使えば10分程度のサービス停止でクラウドに移行できるよ。

チャーリー

えええ~っ!!

クリス先輩

(しくみはここを見てね。)

ステップ1では、まず、オンプレミスにある FOBAS DARP にデータファイルをコピーするんだ。

コピーしたデータファイルは裏でクラウドの FOBAS DARP にゆっくりレプリケーションされているんだよ。その間、既存システムは稼働したままで大丈夫。

 

ステップ2では、いよいよ新環境に切替えするよ。

旧環境のシステムサービスを一時的に停止する。データファイルの更新差分を FOBAS DARP に同期して、クラウド側にレプリケーションするんだ。そしてクラウド側の業務アプリケーションにつなぎ先を切り替えてオンライン。その間僅か10分!

チャーリー

すごいですぅ~。(TT)

クリス先輩

でしょ~(^^)

予め、クラウドには業務アプリケーションはインストールしておくんだよ。

チャーリー

まるで、分身の術みたいですね。

あ、そういえば、クリス先輩って双子なんですよね。

クリス先輩

え、そうだけど・・・。

チャーリー

子供の頃、やりましたでしょ?分身の術。(^^)

クリス先輩

や、やってねーよ!

チャーリー

絶対やってますって~。(笑)

クリス先輩

いいから仕事しろって。

チャーリー

はぁーい。

 

 

 

 

 

To be continued(^^)


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

 

 

 

チャーリー

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

クリス先輩

いつも忙しそうだねぇ。今日はどうしたんだい?

チャーリー

今度、営業にタブレット端末が配られる事になって、これが評価機なんですけどね、やっと WiFi で社内ネットワークに繋がるようにまでなりましたよ。

クリス先輩

へぇ~、ウチの会社もやるようになったねぇ。って事はサポート用にIT部にも支給されるな。ラッキー。(^^)

チャーリー

クリス先輩、喜んでる場合じゃないですよ。タブレットからファイルサーバにある資料を見られるようにしなさいって部長から言われてて大変なんですから。

この後、データをどうやって同期しようかとか、タブレットを紛失した時のセキュリティの確保とか、難しい事いっぱいでもう頭が痛いです。(TT)

クリス先輩

そんなに難しく考えなくても大丈夫。FOBAS CSC WebDAV というネットワーク標準の接続方式をサポートしているから、タブレット端末からでも接続できるよ。リバースプロキシを経由すればインターネットを通じて外出先からでもファイルサーバにアクセスできるんだ。

チャーリー

へぇ~!そんなことができるんですか!?

クリス先輩

うん、簡単だから早速やってみよう!まずタブレット端末に WebDAV 対応しているアプリをダウンロードする。

アプリの設定で、サーバアドレスに https://<サーバFQDN名>/CSCDav/ を入れて・・・認証欄にユーザ名とパスワードを設定すれば設定完了。(^^)

チャーリー

えっ、たったこれだけですか?

クリス先輩

うん、簡単でしょ?このパスワードは、FOBAS CSC Webコントロールパネルから WebDAV 専用のパスワードとして設定できるんだ。

チャーリー

わぁ~すごい。ファイルサーバでアクセス権のあるフォルダだけが表示されていますね。

クリス先輩

dropbox などのファイル共有サービスは確かに便利だけど、端末にデータを同期してため込むものだから、常にデータ容量を意識しないといけないし、紛失時の情報漏えいリスクを考えると、リモートでデータ削除するMDM(デバイス管理ソフト)を導入しないとダメだろうね。

一方、WebDAV でのアクセスは文字通りWebでドキュメントを見る方式だから、保存容量を気にする必要はないし、通信は全て暗号化されている。万が一、デバイスを紛失してもWebDAVパスワードをWebコントロールパネルから変更すれば悪用される心配はないんだよ。アクセスログもあるから、パスワード変更する前にアクセスされてしまったファイルがあれば影響範囲が把握できる。

チャーリー

簡単な設定ですぐに使えるし、セキュリティも安心という事ですね!

クリス先輩

そうそう。簡単で安全なのが一番。(^^)

社外から使うにはリバースプロキシの設定が必要だから、ネットワーク担当のエマちゃんに頼んでおくといいよ。

チャーリー

はい、そうします。これで課題解決ですね。クリス先輩助かりました。(^^)

クリス先輩

それじゃ今日は早めに帰って、サポート用タブレットに入れるアプリでも物色しようかな。楽しみ楽しみ。(#^m^#)

SOUND Canvas のアプリ出たんだよなぁ。往年のDTMファンとしては外せませんな。あとマイクラは定番だし、ブツブツ・・・・お先でーす。

 

 

 

部長

なにか話聞こえてたぞ。FOBAS CSC だと、タブレットアクセスもすごく簡単らしいじゃないか。営業が自分でできる程度なら、サポート用のタブレットは要らんな。予算が浮いて助かる助かる。クリスにも言っておいてくれ。(^^)

チャーリー

あぁ・・・、クリス先輩、ドンマイです・・・・。

 

 

 

 

 

To be continued(^^;


何回かに分けて 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 のアクセスログ機能をご紹介しました。

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


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

 

 

 

チャーリー

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

クリス先輩

今日も忙しそうだね。そんなに慌ててどうしたんだい?

チャーリー

それが・・・、ユーザさんがファイルサーバに置いてあったファイルが消えたって。。。

クリス先輩

それは大変だね。ユーザさんが最後にファイルを確認したのがいつで、無くなったのに気が付いたのはいつかは確認したかな?

チャーリー

はい。午前中、ファイルサーバに保存したファイルを午後開こうとしたら見つからないって。

クリス先輩

クラウドファイルサーバだけに、ファイルが雲隠れしちゃったという訳か・・・。

なーんて、冗談言ってる場合じゃないね。それじゃあ、アクセスログを見てみよう!

チャーリー

アクセスログって・・・最近よく話題には上がりますけど。

情報漏えい対策に必要だからちゃんと対策しないといけないって部長が言ってました。

クリス先輩

うん。もちろん情報漏えいの対策としても有効なのだけど、ユーザさんのファイル操作の記録が全部残っているのでファイルの紛失等にも役に立つんだよ。

FOBAS CSC はスナップショットの保存期間の範囲でファイルのアクセスログ(利用履歴)をファイル出力することができるんだ。

チャーリー

それは便利ですね。早速やってみます!

Webコントロールパネルから・・・

 

 

 

 

 

わっせ、わっせ。(ログ取得中)詳しくはここを見てね。

 

 

 

 

 

よし、ログファイルが出たぞ。どれどれ・・・・。無くなったファイル名で検索すればいいのか・・・。

あ、あったあった。これは・・・・、パスが変更されたという事みたいです

クリス先輩

エクスプローラ上でドラッグアンドドロップしちゃったんじゃないかな。ユーザの操作ミスではよくある話だよ。

チャーリー

どれどれ・・・、本当だ、違うフォルダに移動されてました。ユーザさん助かりますね。(^^)

クリス先輩

良かったね。これで一件落着だ。

FOBAS CSC のアクセスログは、操作の時間や、操作したユーザ、操作内容や対象ファイルがわかりやすくカンマ区切りで出力されるんだ。Excel に取り込めば、利用傾向の分析にも使えるよ。

元データはバイナリ形式でクラウドに保管されているから、改ざんが難しいというのも重要なポイントだね。

チャーリー

本当ですね、今回のファイルは、12:35 chris1 (ver.3.1.4 からユーザIDで出力されます)ユーザが移動してるのがわかります。

あれ、chris1 ってクリス先輩のIDじゃあ・・・・

クリス先輩

マジか~っ!(TT)

チャーリー

クリス先輩、ドンマイ。

 

 

 

 

 

To be continued(^^;


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

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


ページトップへ戻る