未解決
Community Manager
•
3.1K メッセージ
7
4330
[AskTheExperts]PowerScaleコーデ 2021冬
2001年Isilon Systems社で生まれ、EMCで育ち、そして洗練され、Dell Technologies に引き継がれた一つのファイルシステム=OneFSは今もまだ進化を遂げています。増え行くデータ、社会環境の移り変わりに柔軟に,そしてダイナミックに対応し、装いを新たにしたOneFSとそのハードウェアプラットフォームについてExpertsが深堀りします!
期間:12月6日から12月17日まで
Topick別Quickリンクはこちら・・(一気に読みたい人はこのまま読み進んでください!)
*PowerScale第6期ニューフェイスの顔ぶれ update Part1
*Cluster Configuration export & importってなに?しらべてみました!!
*PowerScale第6期ニューフェイスの顔ぶれ-update-Part2
エキスパートはこちら・・・
Amano, Koichi (amako)
いつの間にか15年選手。一通りこなした経験豊かなSEがたどり着いたのはIsilon (PowerScale)。
クラスター構成が好きすぎて、回転ずしでは同じ色の皿は最低3ノード以上!食べる。
しかしかわいい子供達のためにも働き続けないといけないパパはバーチャルランニングをこなしてメタボ解消。
Imamoto, Keiji (KZ-2011)
社歴10年越えの敏腕エンジニア。且つてVNXに向けていた愛をIsilon/PowerScaleへ向けて5年以上。
冷静沈着に見えても「iPhoneのデータ移行よりもPowerScaleの機器更改のほうが簡単なんだぜ!」と叫ぶほどにIsilon/PowerScale愛で満ちている。
この想い、空を飛んでたくさんの人に届けたい!
Mori,Hiroaki ( m_h )
チームの中ではまだまだ新人だけれどエキスパートイベントへは2回目の参戦。
できる先輩達に見守られ,F900並みにパワフルなSEになるべく毎日奮闘中!
プライベートでは子供とのプール通いで親子の絆を深めてきたが、最近寒さに負けてゲーム対戦にシフト中!
Tomizawa, Wataru (Tommy21)
社歴は7年。プロダクトサポートをしていたが大ボスからYou are PowerScale SE! といきなりいわれてPowerScale担当へ。他のプロダクトも知っているからこそPowerScaleの良さをみんなに伝えたいと思う今日この頃。
ハマると止まらなくなるタイプでコーヒーは手回し焙煎機で自家製ロースト!
減量目的の水泳は筋力アップにつながってスーツを新調!
写真は太ももパンパンになったのでスーツを新調し妻がほめてくれた時に撮影したもの!
Tommy21
14 メッセージ
6
2021年12月5日 19:00
PowerScale第6期ニューフェイスの顔ぶれ update Part1
ヴオーーーーガガピー
新しく開設されたOtemachi Oneタワー内のサーバルームに乾いた風が吹く、シアトルに吹くあの風を、君は覚えているはずだ。22億5000万ドルの匂いはまだ、色褪せちゃいない。
PowerScaleという新しい名前を手に入れ、フレンチマンクーリーのようにそびえ立つ雄大なスケールアウトNASは、むしろあの頃よりも…
2021年 秋 大手町 Tokyo
ピー...ガッチャ
無機質にIDが承認され、まだ誰も出社していないオフィスの扉が開く。
自動化された照明は人の歩みよりも早くサーバルームを照らし出し、ラックにマウントされた新しい筐体があらわになる。
新しいPowerScale
こいつを拝むために、コロナ禍でまだ誰もいないオフィスに足を踏み入れた。
待望の新モデル。IsilonとPowerScaleを結び、繋ぐ存在。Gen6のニューフェイス
ここから、新しいPowerScaleの話をはじめよう。
PowerScale A300/A3000、H700/H7000
※既存の一部モデルは割愛しています
新しいPowerScaleモデルの紹介。そう、A300/A3000とH700/H7000は既存A200/A2000とH400やH500/H5600の後継機として登場したニューカマーだ。
俺たちの新しい相棒、Isilonの身体を受け継いだ新しいPowerScale、頼りがいのあるソリューション。
4Uシャーシモデルを受け継いだ、OneFS魂を持つモジュール型ノードの新しいPowerScaleだ。
詳細については上記の通り。
A200やH400と同じように、サポートするドライブとして12TBや16TBが加わったことにより、4U内でも高い容量密度を誇るのはそのままに、一方でA3000/H7000といった高密度モデルでは10TBドライブを廃止として、ラインナップ全体でのドライブのオプションはより明快になった。
また後継機である兄弟の関係としては上記のようにA300はA200やH400の、H700はH500やH400の後継機として、そしてA3000はA2000の、H7000はH5600の後継機として位置付けられる。
PowerScaleという名前だが、新たなモデルはIsilon Gen6の直系の弟。本物の兄弟だ。
だから基本的な仕様やアーキテクチャは先ほど触れたようにIsilon Gen6を踏襲している。
※Gen6の詳細については以前のAsk the Expertを参照してほしい。
だが、新しいモデルは安定した既存のアーキテクチャをただ改良しただけじゃない。
仕様一覧をみて分かるように、CPUやメモリを強化している。
そう、新しいモデルであるA300/A3000とH700/H7000はPowerScaleであり、ラインナップに記載のあるようにIDR―インラインデータ削減をサポートする。
このIDRに対応するためのリソースとしても、新しいモデルではCPUやメモリを強化しているわけだ。
そのため新しいPowerScale Archive / Hybrid NodeはIsilon Gen6と同じシャーシモデルで同じ容量のCapacity Driveをサポートしているとしても、IDR機能によって、より高い容量効率を実現する。
※もちろん君はIDR機能をoffにして、より高いパフォーマンスを選択することも可能だ。
※OneFS 9.0以降導入されたIDRについて詳しくはリンク先を参照してほしい
PowerScaleとIsilon Gen6とのCompatibilityについて
Isilon Gen6とPowerScale はファミリアだ。
シアトル、ボストン、テキサスと場所は変わり名前が変わっても、OneFSの魂を受け継いだ家族である。
だからというわけでもないのだが、Isilon Gen6とPowerScale の間では異なるモデル、異なるナンバー同士とでも同一NodePoolを作ることができる。
主な組み合わせはA200とA300、H500とH700にA2000とA3000、H5600とH7000といった後継機同士となるのだが、
特徴的な組み合わせとしてH400とA300の間でも同一NodePoolを構築可能だ。
この二つのモデルは知っての通りArchiveモデルとHybridモデルだが、A300はH400の後継機・代替機としてもポジショニングしているので、同じNodePoolを形成できるよう偉大なるNAS神が設計された。
同じNodePoolをつくる条件は今までと同様だ
同じCapacity Driveと適合するSSD Driveを用いているNode同士ならばサポートする。
そしてSSDが適合するサイズでない場合でも諦めるのは早い。
その場合でも既存のSSDをアップグレードすることによって対応できる組み合わせがある。
またL3キャッシュ利用に限るならばSSDのサイズと枚数が合致しなくても同じNode poolを構成可能な組み合わせがある。
同一NodePoolを形成できる組み合わせは多岐に渡るためここで一度に紹介することは差し控えたい。
詳しくは愛すべきUDS SEや感謝の念が尽きることのない友人Dellコミュニティに問い合わせしてほしい。
※基本はCapacityとSSDが既存のNodePoolを構成するものと同じサイズが推奨される
A300L/A3000Lについて
ここまで読んでくれた君ならもう、言うまでもなく疑問に思っていることだろう。先程の後継機種対応表に、まだ説明されていない、見なれないモデルが紛れ込んでいることを。
その通り、対応表にあるようにPowerScaleのA300/A3000にはその後ろに「L」のつくA300L/A3000Lオプションがある。
A300/A3000は選択したCapacity DriveによってサポートするSSDの容量が変わる仕様だが、
「L」がつくA300L/A3000Lは容量に関係なく、SSDは800GB固定となる。
そう、PowerScale/Isilonを知り尽くした君らならわかるように、「L」のあるなしによって、メタデータ戦略に違いを持たせている。
A300は先ほどの後継機対応図でもあるようにA200の後継機でもありながら、H400の後継機でもある。
つまりH400といったGen 6 HybridモデルでSSDの用途を選べたように、SSD戦略をArchiveモデルであるA300でも選べる必要がある。そのためにA300は容量DriveによってSSD Driveがスケールする形になった。
また一方で、A300はA200の後継機として同一NodePoolを構成できるようにSSDを固定する必要もある。そのために、A300Lを用意することによって、「L」ありと「L」なしによって、後継機としてどちらにも対応できるようにお行儀よく住み分けできる仕様になった。
※A300L/A3000Lという表記は、資料によってA300/L3やA300L3と表記されている場合もあります
F900
レイモンド・チャンドラーの小説の中にこんな一節がある
「強くなければ生きていけない、しかし優しくなければ生きる資格がない。」
そう、PowerScaleは強く、そしてユーザー様に優しいソリューションだ。
F900はPowerScaleのF200やF600といった新しいDell PowerEdge base兄弟のハイエンド機 だ
F200やF600が1U1Nodeのモデルに対して、弟であるF900は2U1Nodeなのでお兄ちゃんより大きい弟ということになる。
R740ベース、NVMe SSD採用、もちろんIBにも対応 している。
CPUはCascade lake・MEMは驚愕の736GB・Disk本数はNodeあたり24本と他の全てを圧倒的に凌駕する、All-Flashモデル最強のモンスタースケールマシーンだ。
ただ、怪物は1匹だけとは限らない。
まだ語るべき時ではないが、もうまもなく新たな兄弟を君に紹介できることだろう。
S5232
OneFS 9.3の誕生を祝福するかのようにBackendに利用できるスイッチも新しい産声をあげた。
これからのワークロードに対応するため、Z9100の後継機としてS5232がリリースされた。
もはや多くの言葉は無粋だろう、基本的なスペックは以下の通りだ
以下の仕様一覧から見えるように
S5232は40/100GbEをサポートし4 x 10GbE と4 x 25GbEのBreakout cableもサポートする。このスイッチがラインナップに加わったことにより、PowerScaleのモデルを幅広くしっかりとサポートできるようになった。
以上
Ask The Expert Gen6 モデルupdateのすべてだ。
まだなにかわからないことがあったら、俺達に聞いてくれ。
amako
4 メッセージ
6
2021年12月6日 19:00
待望の新機能ロングファイルネーム
「もう長いファイル名には困らない」
Long File Nameの特徴
今回はOneFS9.3で追加されたPowerScaleファン待望の機能
「Long File Name (略称LFN)」のご紹介です。
Windows環境からPowerScaleへデータ移行する際に気になっていたこと。それは「日本語の長いファイル名がないか」ではないでしょうか?
Windows環境ではファイル名に255文字まで設定することができますが、
これまでPowerScaleでは255バイトまでしか設定することができませんでした。
PowerScaleは通常UTF-8の文字コードでファイルを保存していますが、
ほとんどの日本語は1文字で3バイト使用しますので、全て日本語(3バイト)で名前をつけると、ファイル名の上限は83文字ほどになります(拡張子を除く)。
ちなみに𩸽(ほっけ)や𩸕(はも)など一部の珍しい漢字は1文字4バイト使用するので、
さらに短いファイル名長が上限となります。
ながぁぁぁぁぁーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーいぃぃぃ名前.docx
このような255バイトを超える名前のファイルが既存のWindows環境にあった場合には、
対象ファイルの名前を変更してからPowerScaleへデータ移行していました。
この問題を解決すべく今回リリースされたOneFS9.3にて、
Long File Name (略称LFN)機能が追加されました。
LFNによりファイル名長の上限が255バイトから1,024バイトに拡張されたので、
これまでPowerScaleで扱えなかったWindows上の「長い日本語名のファイル」を、
そのままPowerScaleに移すことができます。
LFNで1,024バイトまでサポートされるので、1文字3バイト文字はもちろんですが、
全て1文字4バイト文字で255文字のファイル名だとしても、1,024バイト未満なのでそのままのファイル名でLFNを有効にしたフォルダに保存できます。
𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕.docx
またフォルダ名もファイル名と同じ1,024バイトまでサポートされます。ファイル名やフォルダ名が長い名前をサポートしたので、パス長の上限も1,024バイトから4096バイトまで拡張されました。これでWindows環境からのデータ移行も安心です。
Long File Nameの設定方法
それではWebUIとCLIからのLFN設定方法をご紹介します。
OneFSではデータの保護レベルや、スナップショット、クォータなどのデータサービスを、フォルダ単位で設定できるのが特徴の一つですが、LFNも同じくフォルダ毎に設定できます。
クラスター全体に対しても設定できますが、性能面の観点からLFNが必要なフォルダ毎に設定いただくのがおすすめです。
WebUIからの設定は、File system explorerから設定を行います。
LFNを設定したいフォルダのView/Editボタンから、画面下段にあるFile name limitsのプルダウンメニューを選択します。
またSMB共有の設定画面からも +See File name limit details リンクからLFN設定が確認できます。
次にコマンドラインからの設定方法ですが、isi namelengthコマンドを使用します。
なお半角英数字などの1バイト文字で255文字を超えるファイル名を付けた場合は、
たとえ1,024バイト以下であっても、255文字が上限となるのでエラーになります。
前述のようLFNを有効にしたフォルダは1,024バイト255文字が上限ですが、255文字の上限を変更するカスタム設定もあります。このカスタム設定でOneFSからは1バイト文字で最大1,024文字のファイル名を保存できますが、Windowsからそのファイルを参照すると、Windowsの上限255文字までしかファイル名を読み取れないので、LFNのカスタム設定を使う際は、ユーザー側の文字数制限も確認のうえご検討下さい。
1,024文字のテキストファイルを保存してみる。
Long File Nameの補足情報
その他LFNをお使いいただく上での主な考慮点やご留意事項も紹介します。
詳しくはこちらのホワイトペーパーからもご確認いただけます。
Dell EMC PowerScale OneFS: Long Filename Support
NFS Exportの設定画面から 「File name limits」を1,024バイトにすることで、
NFSクライアントでもファイル名が省略されずフルレングスで表示できます。
ただしNFSクライアントおよびアプリケーションにてLFNは対応していないことが多いため、NFS ExportのLFN有効化は動作検証をした上でご検討下さい。
OneFS9.3以降且つLFNを有効にしている必要があります。
今回はOneFS9.3にて追加された Long File Name (LFN)についてご紹介しました。
LFNによりWindows環境で使用されている「ながぁぁ――――――(省略)――――――い名前」のファイルも、そのままPowerScaleへ移行できるようになりました。もちろん追加費用なしでお使いいただけます。
より使いやすくなったPowerScaleに今後もご期待下さい。
KZ-2011
1 Rookie
1 Rookie
•
122 メッセージ
8
2021年12月7日 16:00
スナップショット書ける書けない問題終結?!
「この世には、書けるスナップショットと書けないスナップショットの2つが存在する」ー そんな言葉を残した偉人がいたかどうかは知りませんが(笑)、本日は、OneFS 9.3の目玉新機能の一つである「書き込み可能スナップショット」についてご紹介します。
スナップショットって書けるの?
スナップショットは、ある一瞬を切り取るスナップ写真から来ており、ストレージ視点では「ある対象領域のある時点の状態(データ)をそのまま保持する」機能を指しています。スナップショットは、そのままの状態を保つためにRead Onlyが常です。簡易的な一時バックアップのような使い方では、Read Onlyが最適でした。一瞬で取得できるスナップショットは非常に便利で、他の用途でも使える場面が色々考えられるのですが、Read Onlyがネックとなるケースもあります。
アプリケーションの動作確認は、その一例です。アプリケーションの動作確認では、本番データが使えるのが理想です。とは言え、本当に本番データをそのまま使うわけにはいきません。テスト用に本番データをコピーすることが考えられますが、コピーするには時間と容量が必要となり簡単にはできないことが多々あります。
スナップショットが使えたらと考えたくなりますよね。一瞬で本番データのイメージを取得でき、容量も必要ない点は申し分ありません。データがRead Onlyで動作確認できるアプリケーションであればよいのですが、書き込みが必要なケースがほとんどだと思います。残念ながら、Read Onlyのスナップショットでは目的とする動作確認ができません。
このような場面で、書き込み可能なスナップショットを取ることができれば、一石二鳥、いや一石三鳥(一瞬で本番データのイメージを取得、容量も消費しない、書き込み可能)となるわけです。他にも災対サイトへの切り替え試験は、書き込みスナップショットが活用できる代表例の一つです。
この書き込み可能スナップショット機能が、OneFS 9.3で新たに追加されました。
Writable Snapshotの仕組み
OneFS 9.3の書き込み可能スナップショット(以降、Writable Snapshot)について、詳しく見ていきたいと思います。
Writable Snapshotは、ベースとなるスナップショットが必要となります。例えば、本番環境で/ifs/prodというディレクトリがあり、そのディレクトリのWritable Snapshotを作成したい場合は、まず/ifs/prodのスナップショット(図中のSnap_prod_1)を取得します。そのスナップショットをベースにWritable Snapshotを作成するのですが、その際に指定した任意のディレクトリ(図中の/ifs/wsnap)に紐付けます。Writable Snapshotは通常のディレクトリと同じようにアクセスして利用でき、利用ユーザがアクセスする分には、通常のディレクトリとWritable Snapshotの区別は付きません。
内部的には、以下のような仕組みになっています。
例えば、/ifs/prodというディレクトリにファイルが4つ(A、B、C、D)あったとします。
この状態でベースとなるスナップショット(Snap_prod_1)を取得、その後ファイルBが上書きされてファイルBがスナップショットで保持され、新しB1が/ifs/prodに保存された状態に変わったとします。ここまでは通常のスナップショットの動きですね。新しいのは次からです。
このスナップショットをベースとしてWritable Snapshotを/ifs/wsnapディレクトリに紐付けて作成します。この状態で/ifs/wsnapにアクセスするとファイルA、B、C、Dが見え、実体としてはファイルBはスナップショット(Snap_prod_1)に保持されたものを参照し、それ以外は/ifs/prodのファイルA、C、Dを参照しています。
/ifs/wsnap配下は書き込み可能ですので、例えばファイルCを上書きしてファイルC1を保存することができます。
ふと疑問に思う方もいるのではないでしょうか。「書き込み可能であるということはメタデータを個別で持っているのか?」と。答えは、「Yes」です。すると、さらに疑問が湧くかもしれません。「ディレクトリやファイルが大量にある場合、Writable Snapshotの作成に時間が掛かるのか?」と。答えは、「No」です。
ディレクトリやファイルの数に関わらず、Writable Snapshotは瞬時に作成できます。これは、Copy on Readという仕組みで実現されています。では、Readした時に何がコピーされるのでしょうか? ファイルに最初にアクセスするタイミングで、そのファイルのメタデータが作成されます。Copyという表現にはなっていますが、実際は必要な情報を引き継いで新しく作成されます。ファイルの実体がコピーされるわけではなく、あくまでもメタデータだけが作成されます。このメタデータが指し示すファイルの実体はスナップショット内のファイルを参照しています。Writable Snapshot内のディレクトリやファイルに対するメタデータをオンデマンドに作成するCopy on Readによって、Writable Snapshot作成が瞬時に完了できるのです。
一方、最初のアクセス時にメタデータを作成するので、応答が少し遅くなります。2回目以降は通常ファイルのアクセスと遜色ない応答になりますが、このことからも性能が必要となるようなケースではWritable Snapshotを使わないようにしてください。
Writable Snapshotの操作
では、実際にWritable Snapshotを作成してみましょう。なお、Writable Snapshotの操作は、CLIもしくはPAPIからのみ可能です。WebUIは提供されていません。
※Writable Snapshotは、SnapshotIQのライセンスが必要となります。
① ベースとなるスナップショットを作成します。(/ifs/prodのスナップショットをSnap_prod_1という名前で作成する例)
② Writable Snapshotを作成します。(Snap_prod_1をベースに/ifs/wsnapディレクトリに紐付ける例)
非常に簡単ですね。
一つのスナップショットをベースとして複数のWritable Snapshotを作成できるので、複数条件でのテストが必要な場合でも、それらの環境をWritable Snapshotで簡単に用意できます。なんとも簡単かつ便利ですね。
実は、Writable Snapshotを作成すると、Quotaエントリも自動作成されます。Writable Snapshotでどれぐらい容量を消費したかをQuotaの機能で確認することができるようになっています。
さらに、前述したメタデータがどのようになっているのか確認してみましょう。メタデータは"isi get"コマンドで確認することができます。
Writable Snapshot取得直後でファイル"a"は編集されていない状態です。大元のファイルとWritable SnapshotのファイルとではLINが異なっていることがわかります。これは、Writable Snapshot内のファイル"a"用にメタデータが割り当てられていることを表しています。
ファイル"a"のサイズを見てみると、期待通りにWritable Snapshotの方は物理も論理もサイズがゼロとなっており容量が一切消費されていないことがわかります。
この状態からファイル"a"に文字列を追記してみましょう。
まず、Writable Snapshotのファイルに対して書き込みができましたね。感動。
サイズを見ると、追記された分だけの容量が消費されていることがわかります。わずかな文字列だったので、論理サイズはファイルシステムのブロックサイズである8KB(8192バイト)となり、保護レベルが+2d:1nの実行環境だったので物理的には3面ミラー分の3ブロックが消費された状態となっています。
こういったところもスナップショットの特長ですね。echoコマンドで追記書きしたのでこのようになりましたが、アプリケーションによっては一部の変更でもファイルを丸ごと置き換えることもあります。部分的な消費で済むかどうかはアプリケーションに依存するという点は、意外と落とし穴ですので覚えておいてください。
また、Quotaでも使用容量が増えていることを確認できます。
これまでのSnapshotIQをご存知の方は、「設定した保持期限を経過したベーススナップショットが自動削除されてしまったら、Writable Snapshotはどうなるの?」、「ベーススナップショットは手動で削除できるの?」と疑問に持たれるのではないでしょうか。答えは、Writable Snapshotがある限り、そのベーススナップショットは保護されます。つまり、保持期限を迎えたタイミングでも手動でも削除できなくなっています。ベーススナップショットがなくなるとWritable Snapshotは元も子もなくなってしまいますからね。
最後は削除ですね。以下のコマンドでWritable Snapshotの削除ができます。
なお、SnapshotDeleteジョブではなく、TreeDeleteジョブによりWritable Snapshotの削除処理が行われます。削除されたWritable Snapshotのトップディレクトリは、"wsnap.101a90014.deleted"のような名前に変更されてTreeDeleteジョブにより非同期で削除されます。タイミングによってはこのようなディレクトリ名が見える場合がありますが、いつかは削除されますので焦らず温かい目で見守ってください。何らかの理由でTreeDeleteジョブが失敗した場合は、もう一度削除を試みてください。その場合は、Writable Snapshotはrenameされたフォルダ名を指定してください。
Writable Snapshotの制約
最後にWritable Snapshotを活用頂く際の制約や気を付けて頂きたい点を挙げておきます。ここではいくつか主だったものの紹介となるので、詳細はWritable Snapshotのホワイトペーパーを参照してください。
PowerScale OneFS: Writable Snapshots
例えば、 /ifs/wsnapに紐付けたWritable Snapshotがあった場合、/ifs/wsnap/wsnap2にWritable Snapshotを作成できません。
例えば、/ifs/wsnapのWritable Snapshot配下にあるファイルやディレクトリは、/ifs/dataといったディレクトリへ移動できません。
それを超える場合には、sysctlパラメータの変更が必要となります。ただし、sysctlパラメータの変更はサポートの指示の下、実施してください。最大2,048個までサポートされていますが、同時に大量のWritable Snapshotを削除しないでください。TreeDeleteジョブが大量に実行され、ジョブのキューが一杯となり他のジョブが起動できなくなってしまいます。
日常的に利用する機能ではないかもしれませんが、使うと便利な場面はきっとあるはず。その時にはWritable Snapshotの存在を思い出してもらえると幸いです。
OneFS 9.3で実装されたWritable Snapshotはまだファーストステップに過ぎなく、まだまだ十分ではないかもしれません。性能や機能改善がなされていく予定ですので、今後の進化に乞うご期待!
KZ-2011
1 Rookie
1 Rookie
•
122 メッセージ
5
2021年12月8日 16:00
NFSがRDMAに乗ってやってきた
OneFSは、NFSについても地道に進化を続けています。OneFS 9.2と9.3でそれぞれ大きなアップデートがありましたので、ご紹介したいと思います。
トピックは二つ。
1. NFS over RDMAのサポート
RDMAは、『Remote Direct Memory Access』の略です。古くからあるテクノロジーなので、耳にされた方も多いかもしれません。詳しくはネット検索をして頂くとして、ここでは簡単に。RDMAは、CPUやOSを介さずにネットワーク(※イーサーネットとは限りません)を介して異なるコンピュータのメモリに直接アクセスする仕組みです。データの受け渡しをする登場人物を減らすことで、CPUに負荷を掛けずに低遅延の高速なデータアクセスを実現しています。
「RDMAと言えばInfiniband」というセット物のようなイメージがあるかもしれませんが、それは昔の話で、今ではイーサーネット上でもRDMAが利用できる時代になっています。Converged Ethernetの登場により、イーサーネットでもロスレス通信ができるようになりました。その流れの中、イーサーネット上でRDMAを利用するためのRoCE(RDMA over Converged Ethernet)と呼ばれる仕様が2010年に策定されました。現在では2014年に策定されたRoCEv2となっています。
OneFS 9.2からRoCEv2をサポートしており、フロントエンド ネットワークのイーサーネットポートを利用してNFS over RDMAを実現しています。余談ですが、NFS over RDMAはRFC8267で標準化されています。
活用シーン
NFS over RDMAの代表的な活用シーンとしては、High Performance Computing (HPC) のワークロードがあります。HPCは、ストレージから大量のファイルを読み出し、高速計算をした結果を書き出すという低遅延・広帯域がストレージには求められます。昨今活用が広がっているAI/Deep Learningのトレーニング ワークロードが、これに似ています。高性能GPUを搭載し大量の計算を実行するサーバが注目されがちですが、Deep Learningでは大量のデータを扱うためストレージも重要な要素の一つとなります。規模が大きくなると、トレーニングデータを共有ストレージに配置し、複数のGPUサーバでトレーニングするというアーキテクチャが必要となります。高価なGPUが遊んでしまっては投資が無駄になるので、ストレージには低遅延・広帯域が必要とされます。GPUの進化に伴い、その要求は益々高まることが予測できます。このような背景のもと、GPUメーカーであるNVIDIA社は、GPUDirectというGPUがCPUを介さずにデータにアクセスできる技術を提供しています(NVIDIA社 GPUDirect Storage)。
GPUDirectは、GPUサーバと外部ストレージとの接続方式としてNFS over RDMAに対応しています。GPUが直接NFSサーバ上のトレーニングデータを読み込むなんてすごいですね。PowerScaleは、GPUDirect対応ストレージとして利用頂けます。PowerScale F600を使ったGPUDirectでの性能レポートが公開されているので、興味がある方はチェックしてみてください。Deep LearningとスケールアウトアーキテクチャであるPowerScaleの相性の良さもP.12のFigure 4で見て取れると思います!
PowerScale and NVIDIA GPUDirect Performance Report
NFS over RDMAの利用要件
NFS over RDMAを利用するためには、PowerScaleだけではなくクライアントおよびネットワークも要件を満たす必要があります。
※10GbEインタフェースは含まれません
※同一セグメントでは、SmartConnect(Dynamic IP移動)による切り替えができない場合があるため
NFS over RDMAの利用要件を満たした上で、クラスタ側ではNFS over RDMAアクセスのためのIP Poolを作成するだけで利用できます。もし、非対応の10GbEインタフェースカードを持つノードがクラスタに混在する場合には、そのノードをNFS over RDMA用のIP Poolには含めないでください。言うまでもなく、利用要件を満たさなくなります。それを未然に防ぐために、IP Pool作成画面で[Enable NFSoRDMA]というチェックボックスが追加されています。これにチェックを入れるとNFS over RDMA対応のインタフェースだけがリストされ、間違って非対応のインタフェースを選択してしまうことがないようにしてくれています。
PowerScaleを利用する上ではIP Poolはそもそも必要ですし、NFS over RDMAの有効化はNFS設定画面(後述)にあるチェックボックスにチェックを入れるだけなので、PowerScale側のハードルはないに等しいぐらいすごく簡単です!
ただし、以下の点の考慮が必要です。
一方、クライアント側は、インタフェースカードのドライバを組み込むなどすれば、あとはmountコマンドのオプションでRDMAを指定することでNFS over RDMAのマウントができます。
なお、NFS over RDMAはNFSv3のみをサポートしていますので、クライアント側でバージョンを指定してマウントをしてください。
性能特性
性能特性について簡単に触れておきたいと思います。具体的なグラフなどを提示できないのですが。。。
通常のTCP通信のNFSと比較した場合、ノード当たり少ないスレッド数でのReadスループットで最も大きな差となる結果が出ています。RDMAの方が2倍~3倍高いスループットとなるケースもあります。また、PowerScaleおよびクライアントのCPU負荷が低減された結果も残っています。同等負荷の場合にRDMAの方が30%~40%程度CPU負荷が軽減されたケースもあります。一方、多数のクライアントから同時に負荷を掛けた場合には、TCPとRDMAで差がない結果となっています。
だからというわけではありませんが、ノード当たりNFS over RDMAの接続数は32までが推奨となっています。
この特性からも、前述のHPCやAI/Deep Learningでの利用に合っていると言えます。他にも、限られた台数のクライアントから広帯域の読み出しが必要となる4K/8K高画質のメディア制作などのワークロードにも適していると言えようかと思います。(参考:PowerScale OneFS: NFS over RDMA for Media)
NFS over RDMAのメリットが活かせそうなワークロードがありましたら、是非試してみてください!
2. NFSv4.1および4.2のサポート
2つ目のトピックです。
OneFS 9.3で新たにNFSv4.1と4.2がサポートされ、NFSのサポートバージョンがv3/4.0/4.1/4.2となりました。v4.1が2010年にRFC5661で標準化されて10年以上経ちますが、世の中ではv3の利用が多かったこともあり、ようやく開発チームも対応してくれたという感じです。
「NFSv4.1に対応したということは、pNFS(Parallel NFS)が使えるの?」と思う方もいるかもしれませんが、対応していません。RFCで定義された機能(オペレーション)の中には、必須機能とオプション機能があります。OneFSは必須機能に対応しており、オプション機能であるpNFSには対応していません(実装していません)。そもそも、PowerScaleはブロックストレージのインタフェースを持っていないので、実装することもできないわけですが。
実は、v4.2のRFCで定義された機能は全てオプション機能なため、OneFS 9.3はv4.2での接続ができることに間違いはありませんが、v4.2の機能が使えるわけではありません。今後の進化に期待したいところです!
NFSv4.1およびv4.2を利用するのは簡単です。管理画面のチェックボックスにチェックを入れるだけです!
一目瞭然ですが、各バージョンを使用するか否かを細かく選択することができるようになっています。デフォルトではOFFになっているので、使うバージョンだけをONにしてください。使わないバージョンはオフっておきましょう。なお、前述したNFS over RDMAもこの画面で有効化します。
セッショントランキング
最後に、NFSv4.1のセッショントランキングを紹介しておきたいと思います。1つのNFS接続で複数のTCPコネクションを張れるというものです。
例えば、NFSクライアント上のアプリケーションAがNFS exportから重いRead処理を行っている最中に、別のアプリケーションBが同一のNFS exportにアクセスするとなった際、TCPコネクションが一つだとアプリケーションBの処理は待たされてしまいます。このような場合でも、複数のTCPコネクションが張られていると、アプリケーションBはアプリケーションAとは異なるTCPコネクションを利用して即座にNFS exportにアクセスできます。NFSクライアント上の複数スレッドがNFS exportにアクセスするような環境ではNFSv4.1のセッショントランキングが有効です。高負荷利用では、All Flashモデルとの相性はバッチリです。
これを利用するためには、OneFS側ではNFSv4.1をONにするだけです。あとは、クライアント側でNFSマウントする際に"nconnect"オプションを指定します。ただし、nconnectはLinuxカーネル5.3以上である必要があるので、適合したバージョンを利用してください。
長らくNFSの機能拡張がなかったのですが、ここにきて立て続けに目玉が2つリリースされました。いずれもさらなる機能改善が期待できるので、NFSをご利用の方は今後の地道な進化にも注目しておいてください!
h_m
1 Rookie
1 Rookie
•
5 メッセージ
5
2021年12月9日 15:00
アップグレード機能も着実に進化中
こんにちは。今回はOneFSのアップグレードに関する機能について紹介します。
OneFSのバージョンが新しくなり次々と新機能を実装するのと並行して、アップグレードに関する機能も着実に改良されていることはご存知でしょうか。アップグレード機能の改良の背景には、少しでもアップグレード時のメンテナンス時間を短縮し利便性の向上を図りたい、という想いがあります。ご存知のように、PowerScaleは容易にスケールアウトが可能であり、どれだけ大規模なクラスタになってもワンボリューム構成という圧倒的な利便性を持っています。そのため、ワークロードの追加や変化に合わせてノードを追加すればよく、クラスタのノード数は年々増加傾向にあります。そのような背景から、大規模クラスタにおけるアップグレード時間の短縮を望む声に応えるべくアップグレード機能も一歩一歩改良され続けています。
OneFS8.0以降、以下のような改良がなされてきました。
メジャーバージョンのアップグレード時でもローリングアップグレードが可能
ロールバック機能追加
drain based upgradeを実装
アップグレード時にノードファームウェアの同時適用が可能(リブート回数の削減)OneFS8.2.2以降で利用できる3種類のアップグレード方式(Parallel/Rolling/Simultaneous)については、こちらのリンクを参照してください。PowerScaleアップグレード編
アップグレードで使用するファイルとしては、以下のようなものがあります。
月例のロールアップパッチ(OneFS初期リリースからの累積パッチ)
OneFSのバージョン表記の4桁目がRollup Patchの世代を表している
例えば、OneFS 9.3.0.1は、OnFS 9.3.0リリースして1ヶ月後のRollup Patchを適用したバージョンRollup Patch適用済のOneFS本体のインストール用ファイル
Rollup Patchのリリースに合わせて、インストールバンドルも毎月リリースされるこれらのファイルは弊社サポートサイトからダウンロードが可能です。
インストールバンドルが提供されるようになったのは2020年の3月ですが、それまでは初期リリースのOneFSで一旦アップグレードしたのちに最新のRollup Patchを適用するという2ステップを踏んでいました。Rollup Patchでもノードのリブートが必要なためアップグレード作業が長時間に及んでしまい、正直スマートではありませんでした。インストールバンドルのおかげでOneFSアップグレードとRollup Patch適用が1ステップで済むようになり、大幅なアップグレード時間の短縮が図られました。
アップグレード時間短縮の施策はまだ続きます。それがParallel Upgradeとノードファームウェアの同時適用の二つです。
一例として、F900 ×4nodeとA300 ×10nodeが混在した14ノード構成のクラスタに対して、ノードファームウェアのアップグレードとOneFSのアップグレードを「Rolling upgrade」と「Parallel upgrade」で実施した場合の作業時間を比較してみます。各作業時間と作業内容は下記の前提とします。※下記数値は例示のための参考値となり保証値ではありません。
<前提条件>
Rolling upgradeの場合
Rolling upgradeかつノードファームウェアの適用を別々に実施する場合は1ノードずつ順次OneFSアップグレードを実施し、その後1ノードずつ順次ノードファームウェアを適用します。OneFS 8.2.2よりも前のアップグレード作業はこれが一般的でした。
結果、トータル560分 (9時間20分)掛かる計算になります。
内訳)
1ノード当たりのノードファームウェアアップグレード時間 (再起動の10分含む) :20分/1node × 14node = 280分
1ノード当たりのOneFSアップグレード時間 (再起動の10分含む) :20分/1node × 14node = 280分
Parallel upgradeの場合
OneFS 8.2.2以降ではParallel upgradeができるようになり、OneFS 9.2以降ではノードファームウェアも同時に適用できるようになったので、OneFS 9.2.1からのアップグレードであれば、これらを活用してトータル300分(5時間)で完了できる計算となります。
Parallel upgradeなのでノード数が多いA300 ×10nodeの方で時間を考えればよく、ノードファームウェアの同時適用では、ノードの再起動がノード当たり1回で済むため内訳は以下のようになります。
内訳)
1ノード当たりのノードファームウェアアップグレード (再起動時間の10分を除く) :10分/1node × 10node = 100分
1ノード当たりのOneFSアップグレード (再起動時間の10分を除く) :10分/1node × 10node = 100分
1ノード当たりの再起動:10分/1node × 10node = 100分
このように、インストールバンドル提供開始後の改良だけで見ても、半分近い時間短縮となっています。単一モデルの小規模クラスタでは大差ないですが、複数モデル構成やノード数が多くなればなるほどアップグレード時間の差は大きくなっていきます。アップグレード作業の長時間化を理由に、これまでアップグレードをしたくてもできなかった方もいるのではないでしょうか?そのようなケースの時には、この進化したアップグレード機能を思い出してください。
drain based upgrade
次に、OneFS9.2から実装された「drain based upgrade」について紹介します。
アップグレードを実施する際はノードの再起動が必要です。再起動されるノードに接続しているクライアントのSMB接続が強制的に切断されます。OneFS9.2で追加された「drain based upgrade」は、すべてのSMB接続が再起動しようとするノードからなくなるまでの間、ノードの再起動を待たせることが可能になりました。利用者を考慮したより安全なアップグレードの選択肢を提供しています。とは言え、いつまでも切断されないSMBクライアントが存在した場合には、アップグレードが無期限に遅延する可能性があります。それを回避するために、接続数がゼロにならない場合は設定したタイムアウト経過後にリブートを開始させる、という選択が可能となっています。
また、SmartConnectもdrain based upgradeと連携しており、ドレイン中のノードにはSMB接続を割り振りません。割り振ってしまうと接続が延々となくならずdrain based upgradeの意味がなくなってしまうので、SmartConnectがまさにスマートに接続を制御しています。
OneFS9.3以降では、drain based upgradeでSMB接続がなくなるのをただ待つだけではなく、oplock/leaseを持たない、つまり切断しても安全なSMBセッションをクラスタ側から強制的に切断する仕様が追加されました。無駄に待たなくても済むような仕組みになります。
Drain based upgaradeの利用方法は、WebUIから[Cluster management]→[Upgrade]を選択し[Upgrade OneFS]を押下します。
なお、「drain based upgrade」はParallel upgrade時のみ利用可能となり、対象のプロトコルアクセスはSMB接続となります。
このようにアップグレードに関する機能も拡充されており、ますます使いやすくなっています。今後ともPowerScaleをよろしくお願いいたします。
Tommy21
14 メッセージ
5
2021年12月12日 21:00
Cluster Configuration export & importってなに?
しらべてみました!!
OneFS9.2からCluster Configuration export & import(以下export & importという)機能が新たに追加されたという噂を耳にしました。
export & importって?
この機能の適用範囲って?
想定される用途は?
ライセンス料はかかるの?
いろいろわからないことだらけですねー。
なので調べてみました!
ついでに検証もしてみました!
まずOneFS9.2から実装された export & import機能はOneFSクラスタの構成情報のバックアップを取得し、またそのバックアップデータから、同じクラスタや別のクラスタに対してリストアできる機能のようです。
使用が想定される主な用途は
らしいです!またライセンス料は不要とのことです!
障害が発生した際にクラスタの構成を再構築しなければならない事態や、検証環境でいろいろと試した際などに、クラスタの設定をもとの状態へコマンド一つで簡単に戻せるのが、このexport & importの主な利点のようですね。
我々チームも検証機を用いて日々検証をしているのですが、チームで機器を共有しているので検証用に作った構成を、その度に構築したり壊したり戻したりと正直めんどーだなーと感じていました。
ですが、この export & importを用いれば、自分の構築した設定のバックアップを取得しておいて、次の機会にリストアすれば再構築するコストを削減できますし、元の設定に戻すのも簡単です。検証環境でいろいろなパターンの構成情報をバックアップしておいて、チームで共有もできるので生産性を向上できるのでは?と期待しています。
■ 適用範囲
今回 OneFS9.2にて追加されたexport & importの適用範囲である各種コンポーネントは以下の7つになります。
※今後コンポーネントと言及する際は以下のいずれかを指します。
'http', 'quota', 'snapshot', 'nfs', 'smb', 's3', 'ndmp’
上記コンポーネントの全ての設定を検証できたわけではありませんが、この機能はあくまで OneFS上の各種機能における構成情報に対するexport & importになります。保存されているデータが対象ではないので注意が必要ですね。
またネットワーク設定や認証関連の設定、システムパラメータなどは未対応ですので今後に期待ですね!
■ export & importの操作方法
現状サポートしているインターフェイスは CLI と PAPIになりWebUIは非対応です。
それではCLIの操作方法の説明といっしょに、実際にexport & importという新しい機能を、設定項目のバックアップとリストア機能として用いるという観点から検証してみたいとおもいます!
私が今回の検証で実施した手順の簡単な流れとしては、以下のような手順で検証しています。
「export」→「各コンポーネントの追加や設定変更」→「import」→「リストアされているか確認」
① まず exportを実行してファイルを取得します。
exports createを実行すると以下の画像のように export idが発行されます
※今回以下で取得したexport idは「node1-20211209034515」になります。
② このexportが成功したか失敗したかは、上記の段階ではわかりませんので
以下のコマンドで確認します。
実際に実行しますと、さきほど発行された export idの結果が以下のように出力されます
※以下は成功例です
またexportデータに関しては上記にPassの記載があるように、ファイルエクスプローラーの「/ifs/data/Isilon_Support/config_mgr/backup」以下からアクセスして確認できます。
③ それでは無事にexportできていることも確認できましたので、このexportをもとにimportを実行して構成情報のリストアを実施してみたいとおもいます。
importを実行する場合に必要なのが export idです。
以下のimport実行例では先程発行された export id(node1-20211209034515)を用いて、importを実行します。
その際にexport≒バックアップを取得した状態と同じ設定のままでは、import実行後に本当にリストアできたかどうか検証して確認できませんよね。
なので、設定情報に変化をもたせるために予め作っておいたsnapshotなどのコンポーネントの設定を、export後にちょっと変更して、実際 importをしてリストアされるのか検証しました。
※コマンドに関しては先ほど紹介したexportの箇所がimportになっている程度なので割愛します。
④ さきほど発行されたimport idでimportが成功したか確認します。
※以下は成功例です。
無事にimportが成功していることが確認できました。
実際の検証ではOneFS9.3 simulatorと弊社の検証環境にあるOneFS9.2.1.3の双方で試したところ、どちらの環境でもexportからのimportに成功しました!
大事な第一歩として、simulatorでも物理Nodeのクラスタ構成でも、OneFS9.2でも9.3でもexport & importは問題なく実行できることがわかりましたので、次はいろいろな角度から検証した結果を共有します。
■ export & import機能の検証
結果の判断が分かりやすい4つのコンポーネントをメインに検証をすすめました。
検証の際のおおまかな流れは以下のようになります
「デフォルトの設定」→「export」→「各コンポーネントの追加」→「各コンポーネントの設定変更」→「import」→「デフォルトの設定に戻っているか確認」
検証した項目は文章にすると冗長になり検証項目と結果がわかりにくので以下表にまとめスポイラで格納しました。
※検証環境はOneFS 9.3 simulatorで実施しています。
検証したコンポーネント
Export実行後に追加・設定したアイテム
Export実行後に変更した設定項目
import (リストア)検証結果
Smb
SMB共有作成
新規フォルダ自動作成
continuous availability timeout
を5 minに変更
permission levelをRead-onlyからFull controlに変更
・フォルダと共有は維持された
・continuous availability timeoutもpermission levelも
元にリストアされた
nfs
新規ディレクトリ作成
それに対しNFS共有作成
NFSv4 no domainの
Global setting項目のnfs4を
enableを変更
PermissionをRead-onlyに変更
・ディレクトリと共有は維持された
・nfs4のenableが外れ元の設定にリストアされた。
snapshot
あるフォルダを毎日1回
11AMにスケジュール設定
Auto-create snapshotsを
disableに変更
あるsnapshotのscheduleの
Snapshot expiration期間を
1Weekから1Monthに変更
・作成したsnapshotのスケジュールは維持された
・Auto-create snapshotsと
Snapshot expirationは
元にリストアされた。
quota
あるフォルダのHard limitを
300GBに設定
その後で500GB等に変更
Quota reporteのNumber of scheduled reports retainedを20に、
取得間隔を週1の土曜日に変更
・directory Quota自体は維持
・Hard limitはリストアされた
・Quota reporteのNumber of scheduled reports retainedは元の10に、取得間隔を週1の日曜日にリストアされた
表にまとめてみたけど分かりづらいですね。。。
掲載上はたたんで隠しまたので気になる方は参照してください!
気を取り直して、snapshotを例に取り以下の画像で説明しますと。
snapshot設定のパスや、スケジュールに関してはimportによるリストアの対象外でした。
その一方で、たとえば下記画像のようにsnapshot機能自体に対するSetting項目ではimportによるリストの対象でした!
各コンポーネントおよびそれ自体に対する設定(Setting)の項目が対象であるのは間違いないと思います。
しかしその一方で、quota機能の場合ですと、directory quotaで設定したHard limitの容量設定を変更し検証したところ、import実行後には元の設定に戻っていましたので、リストアの対象ということも分かりました。snapshotとquotaで違いがあるようなので、検証の結論を出すにはまだ早そうです。
それに、まだちょっと気になる点がありますよね?
そうです。上記の検証ではexport実行後に各コンポーネントを作成・追加しましたが、削除は実施していません。
SMB共有やsnapshotのスケジュールなど各コンポーネントを削除した場合はどうなのかな?と思いますよね。同じように削除したコンポーネントも削除されたままになるのでしょうか。。。
■検証!追加だけではなく、削除もしてみた
そこでexport後にコンポーネントを削除してみてimportを実施するという手順で検証したところ衝撃の事実が判明しました(私の想像とはちょっと違っていたので、やっぱり検証って大事ですねー)
手順としましては
「各コンポーネントを追加設定しておく」→「export」→「各コンポーネントの設定変更」→「各コンポーネントの削除」→「import」→「各コンポーネントがどうなっているか確認」
結果はといいますと、smbでもnfsでもexport後に削除した共有についてはimportによって共有それ自体もリストアされることが確認されました!
更に、snapshotのスケジュールとdirectory quotaもexport後に削除して、importを実施してみたところ、削除したsnapshotのスケジュールもdirectory quotaそれ自体や設定項目も含めリストアされていました。
■まとめ
これらの結果から、export & importの適用範囲には大きく3つの種類があることが分かりました。
上記の結果を踏まえた大まかに結論をまとめますと、以下のことは少なくとも明らかになったとおもいます。
(設定項目含めてimportの対象)
(Snapshotのスケジュールは既に設定がされている場合にはリストア対象外である一方で、directory quotaのHard limitの値はリストア対象であった。)
ドキュメント上ではconfig backupとだけ記載があり、またリストアによって現在ある共有などは消去されないとありましたが、importによって削除された共有などもリストアされるとの記載はなかったので検証って大事なことが身にしみて分かりました!
■ そのほかの利用上の注意点は?
→例えばsnapshotの項目だけをexportする場合を例に取ると、以下の コマンドで解決できます!
createのあとに “--components=任意のコンポーネント”とコマンドを加えればいいだけなので簡単ですね!
このコンポーネントを指定した export データをもとにリストアする場合には、以下のコマンドのようにリストアする項目を同時に指定あげる必要があります。
指定されたコンポーネントとexport データが合わない場合は importがエラーになります。これで誤ったリストアを避ける仕組みなんですね!
以上です!
いかがでしたか?
OneFSはますます便利になっていきますね。この機能もGUIによるサポートや機能の拡充も予定されているので unstoppableなPowerScaleを今後もよろしくお願いいたします!
h_m
1 Rookie
1 Rookie
•
5 メッセージ
5
2021年12月13日 20:00
気になる部分をスッキリ?!監査ログの新機能
こんにちは。今回はOneFSの監査ログの新機能について紹介します。
システム管理者にとって、ストレージに限らずシステム運用では、ログの管理は重要な業務のひとつというのは周知の事実となっています。ファイルサーバの運用で重要なログは、HW障害通知やQuota超過などのイベントログの他に、監査ログと呼ばれる「保存ファイルに対するアクセスログ」と「ファイルサーバの設定情報の変更ログ」が挙げられます。
監査ログは、昨今のランサムウェア攻撃やファイル漏えいなどのセキュリティ脅威に遭遇した際に、いつどのファイルが誰からアクセスされたか、また、ファイルサーバの設定がどのように変更されたかなどの証跡調査に利用されるケースがあります。監査ログが取得されていない環境では、被害の範囲やいつから攻撃を受けていたのかを特定することは困難となり、被害状況の全貌解明に時間がかかる場合も考えられます。監査ログにはそのような証跡管理の目的があるため、PowerScaleでは永久に保存するものという考えでした。
一方、PowerScaleはデータ移行することなく機器の入れ替えが簡単なため、長く利用されるケースが大半です。PowerScaleの利用期間の長期化に伴い、データに対するアクセス回数もおのずと増えるため監査ログも増え続けていきます。また、環境によっては、監査ログを収集・解析し見やすく表示する3rd Partyのログ管理ツールを利用しており、そのツールが監査ログを保管するためPowerScale側では永久に保存する必要はない、というケースもあります。増え続ける監査ログは時には数十TBになることもあります。クラスタ内で増え続ける監査ログの扱いは、管理者の悩みのたねのひとつでもありました。
これらのシステム管理者の悩みを解決すべく、OneFS9.1で「Audit purging」という監査ログをパージする機能が追加されました。この機能の説明の前に、OneFSの監査ログについて簡単に振り返りたいと思います。OneFSで取得可能なログは下記の2種類あります。
いつ誰がどのファイルに対してどのような操作をしたのかを記録したもの
※SMB/HDFS/NFSに対応
監査ログは、下記の例のように連番のファイル名で保存され1GBに達すると圧縮されます。
これらのログファイルはバイナリファイルのため、中身を確認するにはisi_audit_viewerコマンドを利用する必要があります。
<コマンド例>
では本題の「Audit purging」です。この機能はOneFSが取得した監査ログに対して削除したい期間を指定し、その期間分のログを削除する機能です。これにより、簡単かつ効率的に監査ログをトリミングすることが可能になりました。ログの削除は、保持期間のポリシーに基づいて自動的かつ定期的に削除する方法(Auto deletion)と、手動で削除する方法(Manual deletion)の2つがあります。いずれもコマンドラインからのみ設定が可能です。
Auto deletionは保持期間に基づいて動作します。次の図に示すように、内部タイマージョブが1時間ごとにトリガーされ保持期間外の監査ログを削除します。自動パージポリシーは時間範囲、つまり保持期間 (日数) に基づいています。ログ消去処理は自動的にバックグラウンドプロセスで1時間に1回実行されます。
設定例を紹介します。
1. デフォルトでは、Auto Purgingは無効になっているので有効にします。
2.保持期間を指定します。
3. 設定内容を確認します。
次に、2つ目の削除方法のManual deletionについて説明します。Manual deletionでは明示的に削除したい期間を指定し削除を実施します。設定例を紹介します。
1. isi audit logsコマンドの「delete –before=」を用いて、削除したい日を指定します。この例では2020年9月5日より前のログが削除されます。
2. Statusを確認します。
このように、保持期間を設定して自動的に削除するほか、指定した期間のログを手動で削除することで肥大化するログを制御できるようになりました。
最後に制約事項を記載します。
以上、OneFS9.1の新機能「Audit Purging」についての紹介でした。
amako
4 メッセージ
5
2021年12月14日 17:00
PowerScale第6期ニューフェイスの顔ぶれ update Part2
今回製品ラインナップに追加されたH700/H7000や、A300/A3000ノードが注目を集める中、先週12月7日に「アクセラレータノード」と呼ばれる2つのモデルも登場しましたので紹介します。
このアクセラレータノードは、SSDやHDDなどのストレージリソースを持たないノードです。クラスターの性能を向上させるP100と、バックアップ用途に使用するB100という2つのモデルが登場しましたので、それぞれ特徴をみていきます。
Performance Accelerator Nodes P100
PowerScaleはノードを追加することで性能と容量の両方をリニアに拡張することができるスケールアウト型NASであることは、ご存じの方も多いと思います。今回登場したP100ノードは、容量は増やさず性能だけアップさせたい。そんなときに最適なノードです。
P100はSSDやHDDのようなストレージリソースを持たないので、他のノードと比べるとコストを抑えて性能をアップできます。またP100は1ノードから追加することができ、ライセンス費用もかからないのもコストを抑える要因です。ちなみにIDRにも対応してます。
OneFS9.3以降のPowerScale / Isilonクラスターであれば、P100を追加できます。P100を追加することで、CPU、メモリ、ネットワークインターフェイスなどのコントローラリソースを搭載したノードがクラスターに追加されるので、ユーザーからのワークロードを処理するノードが一台増え、クラスター全体としての処理能力が向上するのがP100導入のメリットです。
気になるP100のスペックですが、なんとF600と同じCPUやメモリを搭載してます。このリソースのほとんどがユーザーアクセスに使用されるので性能アップ期待できますね。
2x40/100GbE (QSFP+ / QSFP28)
2x40/100GbE (QSFP+ / QSFP28)
2x40/100GbE (QSFP+ / QSFP28)
2xInfiniBand QDR
2x40/100GbE (QSFP+ / QSFP28)
2xInfiniBand QDR
そんなP100とA300クラスターを組合わせて「A300 + P100 性能増強パッケージ(仮)」の構成も今後増えていきそうです。
他にどんなお客様に向いてるんでしょうか?
既にPowerScaleをお使いで、導入後にユーザーアクセス数が増えた、高い性能が必要になった、InsightIQで性能監視をしてみたら以外とノードの使用率が高かった、など何かしらの理由で性能面を補強したい場合、それとNVIDIA GPU Directのような非常に高い性能が必要な環境で、F600やF900のノード数を減らし代わりにP100ノードを搭載する。そのような用途で使ってもらえることを想定しています。特にリードが多いワークロードではP100の効果が見込めるので、低コストで性能のみ上げたい環境にはもってこいです。
Backup Accelerator Nodes B100
続いてB100ノードの紹介です。Backup Accelerator Nodesの名前のとおりPowerScaleクラスター内のデータを、NDMP(2-Way)で外部にバックアップを取りたい場合に追加するノードです。これまでもNDMP(2-Way)バックアップ接続用にFCポートをノードに追加するNDMPアクセラレータカード(Sheba Card)は用意していましたが、B100はFCポートを搭載しているだけでなく、バックアップのジョブも請け負うことで、既存ノードのコントローラリソースを使うことなくバックアップジョブを実施できます。
PowerScaleクラスターにB100を追加するメリットです。
ユーザーのトラフィックが流れるネットワークへの影響を抑える。
他のノードのリソース消費を抑え、ファイルサービスへの影響を最小限に抑える。
今回お伝えしきれなかった詳細については、こちらのホワイトペーパーからも確認できます。
PowerScale Accelerator Nodes Overview and General Best Practices
PowerScale F600 のアップデート
新しいモデルではありませんが、F600に追加された構成オプションについても紹介します。F600といえばPowerScaleファミリーの中でも、高い性能要件で選ばれるオールフラッシュモデルですが、EDA市場の高い性能要件のご要望に応え、従来より高性能のCPUと、容量の増えた736GBメモリを選択できるようになりました。
このF600の追加オプションで、これまでカバーできなかったこんなご要望にも応えることができます。
F600含めPowerScale All Flash Nodeのスペックはこちらからもご確認できます。
Dell EMC PowerScale All-Flash Family Specification Sheet
今回のAsk The Expert PowerScaleコーデ2021冬編に、最後までお付き合いいただきありがとうございました。今後も進化し続けるPowerScaleにご期待下さい。