【ASK the Expert（翻訳版）】Isilon OneFS 7.1「Waikiki」のすべて

Peter_Sero からの質問 (MRWA への返信)

どこかにVirtual Node　のデモはあるかな？

プラスディスカッションでやってほしいなと思っているのは

＝一般的なNFSのパフォーマンスについて

＝Layout変更やSmall File への対応への変更点？

＝NDMP/SyncIQ scans（ snaphotのようなトラッキング変更について）

＝restripeの向上？

-- Peterより

Jim Gossett からの返信 (Peter_Sero への返信)

Peter、

Virtual Node→デモはNewCodeのリリースト同時に作成されるはずだよ

おそらく10月の終わりとか11月の初めだなあ。

それぞれの質問に関しては以下が答えです。

NFSのパフォーマンス＞ OneFS 7.1では変更はありません

Layout変更やSmall File への対応＞

Diskへのjournal writeのバランスをとるようにしたり、 I/O schedulerの内部のタイミングの変更などがあります。、

（これによりSmall File稼働へのIOPSの向上が期待できる）レイアウト変更こそないけれど、Small File へのWorkFlowの変更など、User には

顕著に見えない領域での細かな変更があります。

NDMP/SyncIQ scans（ snaphotのようなトラッキング変更について）＞

SyncIQはOneFS 7.1以降でのSync job ではすでに適応されており、変更率の高いファイルというより

変更率の低いファイル同期時に有効な方法となっています。OneFS 7.1ではNDMPは snapshot-basedの変更時に適応され、差分同期をサポートするようになりました。

restripe＞New OneFSの Engine は同時並行で複数のJOBを処理することによってrestripe オペレーションを助けています。また

Available なリソースからクラスターへの影響度といったものも計算可能です。もっと具体的にどの部分が知りたいのか教えてくれればもっと詳しくはなしをしますよ。

Jim より

Peter_Sero からの返信

Jim ... 期待高まる返信をありがとう。

Restripeに関しては改良の余地あり、、と僕は踏んでいるんだけれど。。

Disk交換後のMultiScanはある一定のBlockを新しいDiskへ移動させるのではなく

Pool全体のblockを並べ替えるわけだけど、naiveな動きだといっても

User にとっては改善点があるのではと思うのだけれど。。。

また、Restripeは僕の経験からすると inodeをドライブ越しに広めるという

奇妙な動きを見せているか、。こういった点に関しては

今回のOneFS7.1 で改善されていることを望むけどね。

Ｊim Gossett

こんにちはjasdav02、さん

新しいjob engineに関して＞Job Engine v2ではそれぞれのJobはだいたい同じ速度で処理されるはず（clusterに顕著な負荷がかかっていないのが前提）

OneFS 7.1での大きなプラス、それはDrive がFail すればSmartfailが始まり、SnapshotDeleteを停止することはないし一時ポーズする必要もない。

しかしすべての処理がこうやってDriveFail時に無停止にできるというわけじゃないのでその情報はまたあとでお知らせするね。

SmartConnectについて＞もうすこし詳しくSmartConnectFailOverとNFSv4のことを教えてくれないかな？この点に関しては今回の

OneFS 7.1 ではまったく手を付けられていないから。7.0.1 で言われてきたLock関連の不具合だとか、そういったものが君の言っている

問題とかぶるかもしれないからね。

pNFS supportについて＞

これに関してはまだ社内でのroadmapどまり。。。残念ながらみんなとシェアできる情報はまだないんだ。。。

jasdav02　からの質問

私は新しいjob engineにかなり期待しています。cluster環境下での簡単なパフォーマンス結果とかはないのかな。。

こっちの環境ではcluster　load が稼働中のjobに負荷をかけるといった不具合が起きているので・・・

SmartConnectに関しては話しには上っていないけれど、NFSv４と兼ね合いの中で何か進展はないかな。

SMBだとNode間でのやり取りがスムーズではないから・・・

また、pNFS supportに関するアップデートはないかな・・・

Jim Gossett からの返信

Peter...

君に同意するよ。 AutoBalance/MultiScanはOneFS 7.1には入っていないよ。2014にもう少し進んだ技術で

盛り込まれる予定だよ。

君の2番目の話、inode の動きだけどこういった問題に関しては6.5.xではよく見られたがOneFS 7.0

では大丈夫のはずだよ

hupea からの質問

7.1でほかに新しくなったことは？

SyncIQ でData だけでなく、DRサイトでのFailOver時に便利なようにmetadata ( Shares/Exports, Quotas, Kerberosといった種類のもの）もreplicate できないかって思っているんだが。。。

Jim Gossett からの返信

他の新しい機能というと。。。結構細かいところが変わっているよ。

SyncIQでのcontinuous modeとか、 small fileやheavy stat workflowsでのIOPS の機能向上、

システムsnapshot総数が15Ｋまでサポートになったとか、LDAPのサポートとか。。。どんな点が

興味ある？

残念なことに、metadata機能に関してはOneFS 7.1ではまだ対応できていないんだ。

いつともいえないけど今まさに研究中。。ってとこだよ。

skoburn からの質問

Hi Jim !

deduplication（重複排除）ってライセンスいる？

Jim>―→Deduplication (or "DedupeIQ") はOneFS 7.1ではライセンスが必要だよ。

Peter_Sero からの質問

dry run(デモ)　でもライセンスが必要なのかな。

Diskとmemoryでのオーバヘッドはどれくらい？

Jim Gossett からの返信

DedupeAssessをdry runするだけならライセンスはいらないよ。"low" priority settingしかできないけどね。

一度Dedupe jobが起動してしまえばmemory でのオーバーヘッドはないよ。起動中のオーバーヘッドの基準としては

Autobalanceと同等。。と考えれば妥当かな。

Diskにかんしてはshadow storeがmeta data を保持しているがそれは128KB につきほんの数Byte。またHashを含むdata base もdedupのスキャン時にあるけれどこれは時間の経過で128GBまで(最大）大きくなる。それぞれのDedupFileにはこれ以外のオーバーヘッドはないよ。

shadow storeへのポインターはfileの B-treeにある決められたBlockで起動することになるね。

注釈：B-Tree＞＞＞、Balanced Tree（バランス木）の略で、木構造（注）のインデックスツリー（索引木）により検索を高速化するアルゴリズム。

パフォーマンスについては、O（n）であるブロックアルゴリズムに対してO（log n）で行えるという圧倒的な優位性がある。

jasdav02 からの質問

重複排除のDB は段階的にたまっていくものだろうけどこれはDiskに保存され、そして頻繁にアクセスされるような種類であればmemory cacheに「拡大Cache」効果の対象になるのだろうか。

重複排除のDBのコピーはもし設定がそうであれば設定された通り、SSDのnode に移動され、Meta data がされるように、そこにへ保存されるの？

Disk圧縮について何かニュースはない？IPCの性能向上やintel core の増加が、inline compression の性能を2倍にした？？？といった想像もできないことはないけれど、そうであれば、こういうcompressionをcluster FSで行うのはそうじゃない環境で行うよりよっぽど難しいんだろうね。。。

Jim Gossett からの回答

重複排除のDBは重複排除のときにのみ参照され、その処理時にメモリーに載せられることはあっても通常のClusterオペレーションにに関係するような使われ方はしないよ。

重複排除中は別として。。基本的にSSDへはアロケーションはしないよ。

Disk 圧縮に関してはあまり情報はないんだ、、、しかし僕が考える限り、パフォーマンスオーバーヘッド、clustered Storage

でのロジックの問題、といった点はこれに関してタッチする価値がないんじゃないか・・・・と考えられているのではないかな。

clustered device が圧縮のアルゴリズムを書き込みの前にFS 全体に流すのか、もしくはストライプごとにその圧縮をかけるのか。もしストライプごとであればこれは大きな期待を寄せられるが、FS 全体となると大きなオーバーヘッドが生じるだろうなあ。

これはもちろん僕の個人的な見解なのでIsilon としての発言ではないけれどね。。。。

Peter_Sero からの質問

このスレッドで"feature request" 「未来の機能リクエスト大会」ができないかな。。

ほとんどの質問がかなり先を見越したもの（技術的にはまだ現実的でなさそうなもの。。）ばかりだから。

話題がなくなる前にSSD使用量とGNAについて聞きたいな、

7.0ではread only のmetadata　acceleration　では6.5のそれよりもSSDスペースを使っていた気がするんだけど

（GNA installationを破って、inode 情報が3倍でSSDにためられる）

これは7.1になっても同じ？

もしくはどんなmetadata accelerationオプションが7.1ではあるの？

ぼくはSSD使用量低下や、accelerating file layouｔの減少、Seek Seek Operation のほうが

興味はあるけどね。。

注：GNA　（Global namespace acceleration）とは

DataをSSDのスペースを使わずにNoodPoolに格納する方法。代わりにSSDに追加の情報を持つmetadata mirrorを格納する。

追加で格納されたこのmetadata mirrorはreadに対し絶大なパフォーマンスを与える。少なくとも全cluster の2%の

storage がSSD Based である前提でGNSがEnableになることが望ましい。

Jim Gossett からの返信

未来の機能リクエスト大会とはいい考えだね、機能的に可能かどうか、一つ一つしていこうか。

SSDとGNSの関係に関して＞

君の言っていることは正しいとは言えないかもしれない。 read-only accelerationがSSDのスペースを6.5よりもとっているのは確かだけれど。それが大きな違いになることはあまりないよ、実際問題としてね。

FS のInodode はSSDに完璧に保存され、metadata は一度きりの保存、ということもありうるし。（SSDにあるすべてのmetadata は"read/write acceleration"と呼ばれ、これがかなりのSSDの容量を使うこともある）

基本的な問題は "broken Global Namespace Acceleration installations‘‘なんだ。

OneFS 7以前は動的Media とSSD storageの割合はcluster のサイズによって強く推されていた。また、clusuterがGNAの起動をさせない程度の最低限のdisk数というのもあった。

OneFS 7ではこの最低限のdisk数、は,強い推奨値の増加とともに増えていいったけどもしclusterがOneFS 7以前のものでも、アップグレードを予定している場合はGNAの最低条件に合致するのか、しない場合はwarning をあげたりした。しかしこれを無視してアップグレードをすることでGNAがDisable とするケースも少なくなかった。

そのため7.1においてこの点の改善変更点はないよ。（SSD/GNA usageについて）

しかし low-level kernel での改善はなされており、少なくともある一定のoperationへのパフォーマンス効果はあるよう。これはまだ検証段階のためおおっぴらにお知らせはできないけどかなりの効果っていう噂だよ。。