新しい会話を開始

未解決

Community Manager

 • 

3.1K メッセージ

4275

2021年11月24日 18:00

[AskTheExperts]PowerScaleコーデ 2021冬

2001年Isilon Systems社で生まれ、EMCで育ち、そして洗練され、Dell Technologies に引き継がれた一つのファイルシステム=OneFSは今もまだ進化を遂げています。増え行くデータ、社会環境の移り変わりに柔軟に,そしてダイナミックに対応し、装いを新たにしたOneFSとそのハードウェアプラットフォームについてExpertsが深堀りします!

 

期間:12月6日から12月17日まで

Topick別Quickリンクはこちら・・(一気に読みたい人はこのまま読み進んでください!)

PowerScale第6期ニューフェイスの顔ぶれ update Part1

待望の新機能ロングファイルネーム

スナップショット書ける書けない問題終結?!

NFSがRDMAに乗ってやってきた

アップグレード機能も着実に進化中

Cluster Configuration export & importってなに?しらべてみました!!

気になる部分をスッキリ?!監査ログの新機能

PowerScale第6期ニューフェイスの顔ぶれ-update-Part2

 

エキスパートはこちら・・・

amako.jpg

amako.jpgAmano, Koichi (amako 

いつの間にか15年選手。一通りこなした経験豊かなSEがたどり着いたのはIsilon (PowerScale)。
クラスター構成が好きすぎて、回転ずしでは同じ色の皿は最低3ノード以上!食べる。
しかしかわいい子供達のためにも働き続けないといけないパパはバーチャルランニングをこなしてメタボ解消。

 

 

Ima.jpg

Imamoto, Keiji (KZ-2011)           

社歴10年越えの敏腕エンジニア。且つてVNXに向けていた愛をIsilon/PowerScaleへ向けて5年以上。
冷静沈着に見えても「iPhoneのデータ移行よりもPowerScaleの機器更改のほうが簡単なんだぜ!」と叫ぶほどにIsilon/PowerScale愛で満ちている。

この想い、空を飛んでたくさんの人に届けたい!

 

mori.jpgMori,Hiroaki ( m_h )              

チームの中ではまだまだ新人だけれどエキスパートイベントへは2回目の参戦。
できる先輩達に見守られ,F900並みにパワフルなSEになるべく毎日奮闘中!
プライベートでは子供とのプール通いで親子の絆を深めてきたが、最近寒さに負けてゲーム対戦にシフト中!

 

 

 

 

tomizawa.jpgTomizawa, Wataru (Tommy21)  

社歴は7年。プロダクトサポートをしていたが大ボスからYou are PowerScale SE! といきなりいわれてPowerScale担当へ。他のプロダクトも知っているからこそPowerScaleの良さをみんなに伝えたいと思う今日この頃。
ハマると止まらなくなるタイプでコーヒーは手回し焙煎機で自家製ロースト!
減量目的の水泳は筋力アップにつながってスーツを新調!
写真は太ももパンパンになったのでスーツを新調し妻がほめてくれた時に撮影したもの!


14 メッセージ

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

Tommy21_7-1638752034804.png

 

※既存の一部モデルは割愛しています

 

新しいPowerScaleモデルの紹介。そう、A300/A3000とH700/H7000は既存A200/A2000とH400やH500/H5600の後継機として登場したニューカマーだ。

俺たちの新しい相棒、Isilonの身体を受け継いだ新しいPowerScale、頼りがいのあるソリューション。

4Uシャーシモデルを受け継いだ、OneFS魂を持つモジュール型ノードの新しいPowerScaleだ。

Tommy21_8-1638752977977.png

 

詳細については上記の通り。

A200やH400と同じように、サポートするドライブとして12TBや16TBが加わったことにより、4U内でも高い容量密度を誇るのはそのままに、一方でA3000/H7000といった高密度モデルでは10TBドライブを廃止として、ラインナップ全体でのドライブのオプションはより明快になった。

 

Tommy21_9-1638752997229.png

また後継機である兄弟の関係としては上記のように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神が設計された。

 Tommy21_10-1638753030380.png

 

同じ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」なしによって、後継機としてどちらにも対応できるようにお行儀よく住み分けできる仕様になった。

Tommy21_11-1638753053237.png

※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モデル最強のモンスタースケールマシーンだ。

Tommy21_12-1638753073298.png

ただ、怪物は1匹だけとは限らない。

まだ語るべき時ではないが、もうまもなく新たな兄弟を君に紹介できることだろう。

 

 

S5232

 

OneFS 9.3の誕生を祝福するかのようにBackendに利用できるスイッチも新しい産声をあげた。
これからのワークロードに対応するため、Z9100の後継機としてS5232がリリースされた。

もはや多くの言葉は無粋だろう、基本的なスペックは以下の通りだ

 

  • 32 ports 40/100GbE QSFP28
  • 4 x 10GbE と4 x 25GbEのBreakout cableをサポート
    • 10GbE/25GbEは1スイッチあたり124Portまでサポート
  • 16GB CPU Memory

 

以下の仕様一覧から見えるように

S5232は40/100GbEをサポートし4 x 10GbE と4 x 25GbEのBreakout cableもサポートする。このスイッチがラインナップに加わったことにより、PowerScaleのモデルを幅広くしっかりとサポートできるようになった。

Tommy21_13-1638753095705.png

以上

Ask The Expert Gen6 モデルupdateのすべてだ。

まだなにかわからないことがあったら、俺達に聞いてくれ。

4 メッセージ

2021年12月6日 19:00

待望の新機能ロングファイルネーム

 

lfn_image01.JPG「もう長いファイル名には困らない」

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バイト使用するので、

さらに短いファイル名長が上限となります。

  • 全て3バイト文字の場合 (255バイト – 5 文字 (拡張子 .docx .jpeg など) ) ÷ 3バイト ≒ 83 文字
  • 255バイトを超えるファイル名長の例 (84文字 + .docx 拡張子 = 257バイト)
    ながぁぁぁぁぁーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーいぃぃぃ名前.docx
  • このファイルをPowerScaleに保存すると、「対象のパスが長すぎます」とエラーになります。

lfn_image02.jpg

 

このような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を有効にしたフォルダに保存できます。

  • 全て4バイト文字の場合 (1,024バイト – 5 文字 (拡張子 .docx .jpeg など) ) ÷ 4バイト ≒ 255 文字
  • 1文字4バイト 255文字のファイル名長の例 (250文字 + .docx 拡張子 = 255バイト)
    𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕𩸽𩸕.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のプルダウンメニューを選択します。

  • Full length (255 characters, 1,024 bytes)          :255文字1,024バイトまで
  • Inherited (255 characters, 1,024 / 255 bytes)  :上位フォルダの設定を継承
  • Restricted (255 characters, 255 bytes)             :255文字255バイトまで(デフォルト)

lfn_image03.jpg

 

またSMB共有の設定画面からも +See File name limit details リンクからLFN設定が確認できます。

lfn_image04.JPG

 

 次にコマンドラインからの設定方法ですが、isi namelengthコマンドを使用します。

  • isi namelengthコマンドのサブコマンド
    • create       Create a file name length configuration domain.
    • delete       Delete a file name length configuration or all configurations.-
    • modify       Modify a file name length configuration domain.
    • list              View a list of file name length configuration domains.
    • view           View detailed properties of a file name length configuration domain.

 

  • /ifs/lfnフォルダを1,024バイト 255文字対応にする場合
# isi namelength create --max-bytes=1024 --max-chars=255 /ifs/lfn
  • LFNの設定を確認する場合
# isi namelength list
Path     Policy  Max Bytes  Max Chars
--------------------------------------
/ifs/lfn full    1024       255
--------------------------------------



  • /ifs/lfnフォルダを1,024バイト 255文字対応にする場合
# isi namelength create /ifs/lfn
  •      クラスター全体でLFN機能を有効する場合
# isi namelength create --policy=full /ifs

 

なお半角英数字などの1バイト文字で255文字を超えるファイル名を付けた場合は、

たとえ1,024バイト以下であっても、255文字が上限となるのでエラーになります。

# isi namelength list
Path       Policy     Max Bytes  Max Char
-------------------------------------------
/ifs/lfn   full       1024       255
-------------------------------------------
# touch 01234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890.docx
touch: 01234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890.docx:
File name too long





 

前述のようLFNを有効にしたフォルダは1,024バイト255文字が上限ですが、255文字の上限を変更するカスタム設定もあります。このカスタム設定でOneFSからは1バイト文字で最大1,024文字のファイル名を保存できますが、Windowsからそのファイルを参照すると、Windowsの上限255文字までしかファイル名を読み取れないので、LFNのカスタム設定を使う際は、ユーザー側の文字数制限も確認のうえご検討下さい。

  • 1,024バイト1024文字のLFN設定をした例
    • OneFSから /ifs/salesフォルダに1,024バイト1,024文字のLFN設定をして、
      1,024文字のテキストファイルを保存してみる。
# isi namelength list
Path       Policy     Max Bytes  Max Chars
------------------------------------------- /ifs/lfn   full       1024       255
/ifs/sales custom     1024       1024
/ifs/se    restricted 255        255
-------------------------------------------
Total: 3
# cd /ifs/sales
# touch 123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890.txt
#








  • Windowsのエクスプローラから、このファイルをみると最初の255文字までしか読み取れない。

lfn_image05.jpg

 

Long File Nameの補足情報

その他LFNをお使いいただく上での主な考慮点やご留意事項も紹介します。

詳しくはこちらのホワイトペーパーからもご確認いただけます。

Dell EMC PowerScale OneFS: Long Filename Support

  • 255バイトを超えるLFNを表示する際、NFSクライアントでは超えた部分は短縮して表示されます。

lfn_image06.jpg

NFS Exportの設定画面から 「File name limits」を1,024バイトにすることで、

NFSクライアントでもファイル名が省略されずフルレングスで表示できます。

ただしNFSクライアントおよびアプリケーションにてLFNは対応していないことが多いため、NFS ExportのLFN有効化は動作検証をした上でご検討下さい。

 

  • LFNとOneFSその他のデータサービスとの互換性について
    • SnapshotIQやSmartQuotasはLFN有効後も従来通り利用可能です。
    • SyncIQについてはソース側だけでなくターゲット側のクラスターも
      OneFS9.3以降且つLFNを有効にしている必要があります。
    • AntiVirus機能について、ICAPは非対応ですが、CAVAは対応となります。
    • Audit(アクセス監査ログ)ではLFNにてAudit Logに記載されます。

 

今回はOneFS9.3にて追加された Long File Name (LFN)についてご紹介しました。

LFNによりWindows環境で使用されている「ながぁぁ――――――(省略)――――――い名前」のファイルも、そのままPowerScaleへ移行できるようになりました。もちろん追加費用なしでお使いいただけます。

より使いやすくなったPowerScaleに今後もご期待下さい。

1 Rookie

 • 

122 メッセージ

2021年12月7日 16:00

スナップショット書ける書けない問題終結?!

 

「この世には、書けるスナップショットと書けないスナップショットの2つが存在する」ー そんな言葉を残した偉人がいたかどうかは知りませんが(笑)、本日は、OneFS 9.3の目玉新機能の一つである「書き込み可能スナップショット」についてご紹介します。

 

スナップショットって書けるの?

photo_omoide.pngスナップショットは、ある一瞬を切り取るスナップ写真から来ており、ストレージ視点では「ある対象領域のある時点の状態(データ)をそのまま保持する」機能を指しています。スナップショットは、そのままの状態を保つためにRead Onlyが常です。簡易的な一時バックアップのような使い方では、Read Onlyが最適でした。一瞬で取得できるスナップショットは非常に便利で、他の用途でも使える場面が色々考えられるのですが、Read Onlyがネックとなるケースもあります。

アプリケーションの動作確認は、その一例です。アプリケーションの動作確認では、本番データが使えるのが理想です。とは言え、本当に本番データをそのまま使うわけにはいきません。テスト用に本番データをコピーすることが考えられますが、コピーするには時間と容量が必要となり簡単にはできないことが多々あります。

スナップショットが使えたらと考えたくなりますよね。一瞬で本番データのイメージを取得でき、容量も必要ない点は申し分ありません。データがRead Onlyで動作確認できるアプリケーションであればよいのですが、書き込みが必要なケースがほとんどだと思います。残念ながら、Read Onlyのスナップショットでは目的とする動作確認ができません。

このような場面で、書き込み可能なスナップショットを取ることができれば、一石二鳥、いや一石三鳥(一瞬で本番データのイメージを取得、容量も消費しない、書き込み可能)となるわけです。他にも災対サイトへの切り替え試験は、書き込みスナップショットが活用できる代表例の一つです。

この書き込み可能スナップショット機能が、OneFS 9.3で新たに追加されました。

 

Writable Snapshotの仕組み 

OneFS 9.3の書き込み可能スナップショット(以降、Writable Snapshot)について、詳しく見ていきたいと思います。

図1.png

 

Writable Snapshotは、ベースとなるスナップショットが必要となります。例えば、本番環境で/ifs/prodというディレクトリがあり、そのディレクトリのWritable Snapshotを作成したい場合は、まず/ifs/prodのスナップショット(図中のSnap_prod_1)を取得します。そのスナップショットをベースにWritable Snapshotを作成するのですが、その際に指定した任意のディレクトリ(図中の/ifs/wsnap)に紐付けます。Writable Snapshotは通常のディレクトリと同じようにアクセスして利用でき、利用ユーザがアクセスする分には、通常のディレクトリとWritable Snapshotの区別は付きません。

内部的には、以下のような仕組みになっています。

図2-1.png

例えば、/ifs/prodというディレクトリにファイルが4つ(A、B、C、D)あったとします。

図2-2.png

この状態でベースとなるスナップショット(Snap_prod_1)を取得、その後ファイルBが上書きされてファイルBがスナップショットで保持され、新しB1が/ifs/prodに保存された状態に変わったとします。ここまでは通常のスナップショットの動きですね。新しいのは次からです。

図2-3.png

このスナップショットをベースとしてWritable Snapshotを/ifs/wsnapディレクトリに紐付けて作成します。この状態で/ifs/wsnapにアクセスするとファイルA、B、C、Dが見え、実体としてはファイルBはスナップショット(Snap_prod_1)に保持されたものを参照し、それ以外は/ifs/prodのファイルA、C、Dを参照しています。

図2-4.png

 /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という名前で作成する例)

# isi snapshot snapshots create /ifs/prod --name=Snap_prod_1
# isi snapshot snapshots list
ID Name Path
--------------------------
10 Snap_prod_1 /ifs/prod
--------------------------
Total: 1






② Writable Snapshotを作成します。(Snap_prod_1をベースに/ifs/wsnapディレクトリに紐付ける例)

# isi snapshot writable create Snap_prod_1 /ifs/wsnap ※既に/ifs/wsnapが存在しているとコマンドが失敗します
# isi snapshot writable list
Path       Src Path  Src Snapshot
----------------------------------
/ifs/wsnap /ifs/prod Snap_prod_1
----------------------------------
Total: 1





非常に簡単ですね。
一つのスナップショットをベースとして複数のWritable Snapshotを作成できるので、複数条件でのテストが必要な場合でも、それらの環境をWritable Snapshotで簡単に用意できます。なんとも簡単かつ便利ですね。

実は、Writable Snapshotを作成すると、Quotaエントリも自動作成されます。Writable Snapshotでどれぐらい容量を消費したかをQuotaの機能で確認することができるようになっています。

# isi quota quotas list
Type      AppliesTo Path       Snap Hard Soft Adv Used  Reduction Efficiency
-----------------------------------------------------------------------------------
directory DEFAULT   /ifs/wsnap No   -    -    -   76.00 -         0.04 : 1
-----------------------------------------------------------------------------------
Total: 1




 

さらに、前述したメタデータがどのようになっているのか確認してみましょう。メタデータは"isi get"コマンドで確認することができます。

# isi get -D /ifs/prod/a |grep LIN:
* LIN: 1:01a9:0002
# isi get -D /ifs/wsnap/a |grep LIN:
* LIN: 1:01bc:000b


Writable Snapshot取得直後でファイル"a"は編集されていない状態です。大元のファイルとWritable SnapshotのファイルとではLINが異なっていることがわかります。これは、Writable Snapshot内のファイル"a"用にメタデータが割り当てられていることを表しています。

# isi get -D /ifs/prod/a |grep -e "Physical Blocks" -e "Logical Size"
* Physical Blocks: 2190
* Logical Size: 11862016
# isi get -D /ifs/wsnap/a |grep -e "Physical Blocks" -e "Logical Size"
* Physical Blocks: 0
* Logical Size: 0




ファイル"a"のサイズを見てみると、期待通りにWritable Snapshotの方は物理も論理もサイズがゼロとなっており容量が一切消費されていないことがわかります。

この状態からファイル"a"に文字列を追記してみましょう。

# echo "Update writable snapshot" >> /ifs/wsnap/a
# isi get -D /ifs/wsnap/a |grep -e "Physical Blocks" -e "Logical Size"
* Physical Blocks: 3
* Logical Size: 8192


pose_kandou_woman.pngまず、Writable Snapshotのファイルに対して書き込みができましたね。感動。
サイズを見ると、追記された分だけの容量が消費されていることがわかります。わずかな文字列だったので、論理サイズはファイルシステムのブロックサイズである8KB(8192バイト)となり、保護レベルが+2d:1nの実行環境だったので物理的には3面ミラー分の3ブロックが消費された状態となっています。
こういったところもスナップショットの特長ですね。echoコマンドで追記書きしたのでこのようになりましたが、アプリケーションによっては一部の変更でもファイルを丸ごと置き換えることもあります。部分的な消費で済むかどうかはアプリケーションに依存するという点は、意外と落とし穴ですので覚えておいてください。

また、Quotaでも使用容量が増えていることを確認できます。

# isi quota quotas list
Type      AppliesTo Path       Snap Hard Soft Adv Used  Reduction Efficiency
-----------------------------------------------------------------------------------
directory DEFAULT /ifs/wsnap No   -    -    -   8.07k 1.01 : 1  0.25 : 1
-----------------------------------------------------------------------------------
Total: 1




 

これまでのSnapshotIQをご存知の方は、「設定した保持期限を経過したベーススナップショットが自動削除されてしまったら、Writable Snapshotはどうなるの?」、「ベーススナップショットは手動で削除できるの?」と疑問に持たれるのではないでしょうか。答えは、Writable Snapshotがある限り、そのベーススナップショットは保護されます。つまり、保持期限を迎えたタイミングでも手動でも削除できなくなっています。ベーススナップショットがなくなるとWritable Snapshotは元も子もなくなってしまいますからね。

# isi snapshot writable list
Path       Src Path  Src Snapshot
----------------------------------
/ifs/wsnap /ifs/prod Snap_prod_1 ←Writable Snapshotがある状態
----------------------------------
Total: 1
# isi snapshot snapshots delete Snap_prod_1
Are you sure? (yes/[no]): yes
Snapshot "Snap_prod_1" can't be deleted because it is locked ←削除ができませんでした







 

最後は削除ですね。以下のコマンドでWritable Snapshotの削除ができます。

# isi snapshot writable delete /ifs/wsnap
Are you sure? (yes/[no]): yes

なお、SnapshotDeleteジョブではなく、TreeDeleteジョブによりWritable Snapshotの削除処理が行われます。削除されたWritable Snapshotのトップディレクトリは、"wsnap.101a90014.deleted"のような名前に変更されてTreeDeleteジョブにより非同期で削除されます。タイミングによってはこのようなディレクトリ名が見える場合がありますが、いつかは削除されますので焦らず温かい目で見守ってください。何らかの理由でTreeDeleteジョブが失敗した場合は、もう一度削除を試みてください。その場合は、Writable Snapshotはrenameされたフォルダ名を指定してください。

# isi snapshot writable delete /ifs/wsnap.101a90014.deleted

 

Writable Snapshotの制約

最後にWritable Snapshotを活用頂く際の制約や気を付けて頂きたい点を挙げておきます。ここではいくつか主だったものの紹介となるので、詳細はWritable Snapshotのホワイトペーパーを参照してください。
PowerScale OneFS: Writable Snapshots 

  1. Writable Snapshotをネストすることはできません。
    例えば、 /ifs/wsnapに紐付けたWritable Snapshotがあった場合、/ifs/wsnap/wsnap2にWritable Snapshotを作成できません。
  2. Writable Snapshotに対して、スナップショットを取得できません。
  3. Snapshot Aliasに対して、Writable Snapshotを作成できません。
  4. SyncIQが内部的に自動作成したスナップショットに対して、Writable Snapshotを作成できません。
  5. Writable Snapshot内のファイルおよびフォルダを外のディレクトリに移動できません。
    例えば、/ifs/wsnapのWritable Snapshot配下にあるファイルやディレクトリは、/ifs/dataといったディレクトリへ移動できません。
  6. Writable Snapshotの数は、クラスタ全体で30個までが推奨となっています。
    それを超える場合には、sysctlパラメータの変更が必要となります。ただし、sysctlパラメータの変更はサポートの指示の下、実施してください。最大2,048個までサポートされていますが、同時に大量のWritable Snapshotを削除しないでください。TreeDeleteジョブが大量に実行され、ジョブのキューが一杯となり他のジョブが起動できなくなってしまいます。

 

日常的に利用する機能ではないかもしれませんが、使うと便利な場面はきっとあるはず。その時にはWritable Snapshotの存在を思い出してもらえると幸いです。
OneFS 9.3で実装されたWritable Snapshotはまだファーストステップに過ぎなく、まだまだ十分ではないかもしれません。性能や機能改善がなされていく予定ですので、今後の進化に乞うご期待!

1 Rookie

 • 

122 メッセージ

2021年12月8日 16:00

 NFSがRDMAに乗ってやってきた

 

OneFSは、NFSについても地道に進化を続けています。OneFS 9.2と9.3でそれぞれ大きなアップデートがありましたので、ご紹介したいと思います。

トピックは二つ。

  1. NFS over RDMA のサポート ※OneFS 9.2のアップデート
  2. NFSv4.1およびv4.2のサポート ※OneFS 9.3のアップデート

 

1. NFS over RDMAのサポート

RDMAは、『Remote Direct Memory Access』の略です。古くからあるテクノロジーなので、耳にされた方も多いかもしれません。詳しくはネット検索をして頂くとして、ここでは簡単に。RDMAは、CPUやOSを介さずにネットワーク(※イーサーネットとは限りません)を介して異なるコンピュータのメモリに直接アクセスする仕組みです。データの受け渡しをする登場人物を減らすことで、CPUに負荷を掛けずに低遅延の高速なデータアクセスを実現しています。

RoCE.png「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だけではなくクライアントおよびネットワークも要件を満たす必要があります。

PowerScale
  • OneFS 9.2以降
  • 25GbE/40GbE/100GbEのフロントエンド ネットワーク インタフェースカードを搭載したGen6以降のノード
    ※10GbEインタフェースは含まれません
  • NFS over RDMAを有効化

クライアント
  • Mellanox ConnectX-3 Pro、4、5、6(ネットワーク インタフェースカード)
  • 適合OSおよびドライバ

ネットワーク
  • 接続スイッチのポートをPriority Flow Control有効化
  • クライアントとPowerScaleは、L3スイッチ/ルータを介した接続(異なるセグメント)が推奨
    ※同一セグメントでは、SmartConnect(Dynamic IP移動)による切り替えができない場合があるため
  • ポート4791で通信ができること(RoCEv2で利用されるポート)
  • ポート20049で通信ができること(NFS over RDMAで利用されるポート)

NFSoRDMA.png

 

NFS over RDMAの利用要件を満たした上で、クラスタ側ではNFS over RDMAアクセスのためのIP Poolを作成するだけで利用できます。もし、非対応の10GbEインタフェースカードを持つノードがクラスタに混在する場合には、そのノードをNFS over RDMA用のIP Poolには含めないでください。言うまでもなく、利用要件を満たさなくなります。それを未然に防ぐために、IP Pool作成画面で[Enable NFSoRDMA]というチェックボックスが追加されています。これにチェックを入れるとNFS over RDMA対応のインタフェースだけがリストされ、間違って非対応のインタフェースを選択してしまうことがないようにしてくれています。

WebUI-pool.png

 

PowerScaleを利用する上ではIP Poolはそもそも必要ですし、NFS over RDMAの有効化はNFS設定画面(後述)にあるチェックボックスにチェックを入れるだけなので、PowerScale側のハードルはないに等しいぐらいすごく簡単です!
ただし、以下の点の考慮が必要です。

  1. Link Aggregationインタフェースは非対応
  2. VLANは非対応
  3. IPv6は非対応

一方、クライアント側は、インタフェースカードのドライバを組み込むなどすれば、あとはmountコマンドのオプションでRDMAを指定することでNFS over RDMAのマウントができます。

# mount -t nfs -o nfsvers=3,proto=rdma,port=20049 powerscale:/ifs/export_rdma /mnt/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つ目のトピックです。
NFS_history.pngOneFS 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を利用するのは簡単です。管理画面のチェックボックスにチェックを入れるだけです!
NFS_Setting.JPG

一目瞭然ですが、各バージョンを使用するか否かを細かく選択することができるようになっています。デフォルトではOFFになっているので、使うバージョンだけをONにしてください。使わないバージョンはオフっておきましょう。なお、前述したNFS over RDMAもこの画面で有効化します。

 

セッショントランキング

最後に、NFSv4.1のセッショントランキングを紹介しておきたいと思います。1つのNFS接続で複数のTCPコネクションを張れるというものです。

NFS_session_trunking.png

 

例えば、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以上である必要があるので、適合したバージョンを利用してください。

# mount -t nfs -o nfsvers=4.1,nconnect=4 powerscale:/ifs/nfs01 /mnt/nfs01
# netstat -an |grep 2049
tcp        0      0 10.119.81.82:1000      10.119.80.31:2049       ESTABLISHED
tcp        0      0 10.119.81.82:810        10.119.80.31:2049       ESTABLISHED
tcp        0      0 10.119.81.82:674        10.119.80.31:2049       ESTABLISHED
tcp        0      0 10.119.81.82:701        10.119.80.31:2049       ESTABLISHED
↑クライアント(10.119.81.82)から1つのノード(10.119.80.31)に対して4つのTCPコネクションが張られていることがわかります
※1台のクライアントからは1ノードに対してのみNFS接続するので、ノードに渡って複数TCPコネクションが張られるわけではありません






 

長らくNFSの機能拡張がなかったのですが、ここにきて立て続けに目玉が2つリリースされました。いずれもさらなる機能改善が期待できるので、NFSをご利用の方は今後の地道な進化にも注目しておいてください!

1 Rookie

 • 

5 メッセージ

2021年12月9日 15:00

アップグレード機能も着実に進化中

 

こんにちは。今回はOneFSのアップグレードに関する機能について紹介します。

 OneFSのバージョンが新しくなり次々と新機能を実装するのと並行して、アップグレードに関する機能も着実に改良されていることはご存知でしょうか。アップグレード機能の改良の背景には、少しでもアップグレード時のメンテナンス時間を短縮し利便性の向上を図りたい、という想いがあります。ご存知のように、PowerScaleは容易にスケールアウトが可能であり、どれだけ大規模なクラスタになってもワンボリューム構成という圧倒的な利便性を持っています。そのため、ワークロードの追加や変化に合わせてノードを追加すればよく、クラスタのノード数は年々増加傾向にあります。そのような背景から、大規模クラスタにおけるアップグレード時間の短縮を望む声に応えるべくアップグレード機能も一歩一歩改良され続けています。

 OneFS8.0以降、以下のような改良がなされてきました。

OneFSバージョン 追加された機能
8.0

メジャーバージョンのアップグレード時でもローリングアップグレードが可能

ロールバック機能追加

8.2.2 Parallel upgradeを実装
9.2

drain based upgradeを実装

アップグレード時にノードファームウェアの同時適用が可能(リブート回数の削減)
9.3 drain based upgrade時にoplock/leaseを持たないSMB接続をクラスタ側から切断

 OneFS8.2.2以降で利用できる3種類のアップグレード方式(Parallel/Rolling/Simultaneous)については、こちらのリンクを参照してください。PowerScaleアップグレード編

 アップグレードで使用するファイルとしては、以下のようなものがあります。

名称 用途
OneFS Installation file OneFS本体のインストール用ファイル
Rollup Patch

月例のロールアップパッチ(OneFS初期リリースからの累積パッチ)

OneFSのバージョン表記の4桁目がRollup Patchの世代を表している

例えば、OneFS 9.3.0.1は、OnFS 9.3.0リリースして1ヶ月後のRollup Patchを適用したバージョン
OneFS Installation Bundle

Rollup Patch適用済のOneFS本体のインストール用ファイル

Rollup Patchのリリースに合わせて、インストールバンドルも毎月リリースされる
Node Firmware Package ノードファームウェアのアップグレード用ファイル

 これらのファイルは弊社サポートサイトからダウンロードが可能です。m_h_0-1639092404922.png

 

 インストールバンドルが提供されるようになったのは2020年の3月ですが、それまでは初期リリースのOneFSで一旦アップグレードしたのちに最新のRollup Patchを適用するという2ステップを踏んでいました。Rollup Patchでもノードのリブートが必要なためアップグレード作業が長時間に及んでしまい、正直スマートではありませんでした。インストールバンドルのおかげでOneFSアップグレードとRollup Patch適用が1ステップで済むようになり、大幅なアップグレード時間の短縮が図られました。

 アップグレード時間短縮の施策はまだ続きます。それがParallel Upgradeとノードファームウェアの同時適用の二つです。

 一例として、F900 ×4nodeとA300 ×10nodeが混在した14ノード構成のクラスタに対して、ノードファームウェアのアップグレードとOneFSのアップグレードを「Rolling upgrade」と「Parallel upgrade」で実施した場合の作業時間を比較してみます。各作業時間と作業内容は下記の前提とします。※下記数値は例示のための参考値となり保証値ではありません。

<前提条件>

  • アップグレードパス:OneFS9.2.1をOneFS9.3.0へアップグレード
  • 1ノード当たりのノードファームウェアの適用に必要な時間:20分/1ノード (内訳・・・パッケージのロードと適用:10分、ノード単体の再起動:10分)
  • 1ノード当たりのOneFSのアップグレードに必要な時間:20分/1ノード (内訳・・・パッケージのロードと適用:10分、ノード単体の再起動:10分)

 

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がまさにスマートに接続を制御しています。

m_h_1-1639092585989.png

 OneFS9.3以降では、drain based upgradeでSMB接続がなくなるのをただ待つだけではなく、oplock/leaseを持たない、つまり切断しても安全なSMBセッションをクラスタ側から強制的に切断する仕様が追加されました。無駄に待たなくても済むような仕組みになります。

 Drain based upgaradeの利用方法は、WebUIから[Cluster management]→[Upgrade]を選択し[Upgrade OneFS]を押下します。

m_h_2-1639092616068.png

 なお、「drain based upgrade」はParallel upgrade時のみ利用可能となり、対象のプロトコルアクセスはSMB接続となります。

 このようにアップグレードに関する機能も拡充されており、ますます使いやすくなっています。今後ともPowerScaleをよろしくお願いいたします。

14 メッセージ

2021年12月12日 21:00

Cluster Configuration export & importってなに?
しらべてみました!!

 

OneFS9.2からCluster Configuration export & import(以下export & importという)機能が新たに追加されたという噂を耳にしました。

Tommy21_0-1639274167890.png

export & importって?

この機能の適用範囲って?

想定される用途は?

ライセンス料はかかるの?

いろいろわからないことだらけですねー。

なので調べてみました!
ついでに検証もしてみました!

 

 

まずOneFS9.2から実装された export & import機能はOneFSクラスタの構成情報のバックアップを取得し、またそのバックアップデータから、同じクラスタや別のクラスタに対してリストアできる機能のようです。

 

使用が想定される主な用途は

 

  • バックアップ(構成変更をする前や障害時など)
  • クラスタ構築/再構築の工数削減

 

らしいです!またライセンス料は不要とのことです!

障害が発生した際にクラスタの構成を再構築しなければならない事態や、検証環境でいろいろと試した際などに、クラスタの設定をもとの状態へコマンド一つで簡単に戻せるのが、このexport & importの主な利点のようですね。

検証部分の記述が長くなってしまったので感覚ベースとして結論を先に お話すると、社内などの検証環境にとても使えるかと思います!

我々チームも検証機を用いて日々検証をしているのですが、チームで機器を共有しているので検証用に作った構成を、その度に構築したり壊したり戻したりと正直めんどーだなーと感じていました。

ですが、この export & importを用いれば、自分の構築した設定のバックアップを取得しておいて、次の機会にリストアすれば再構築するコストを削減できますし、元の設定に戻すのも簡単です。検証環境でいろいろなパターンの構成情報をバックアップしておいて、チームで共有もできるので生産性を向上できるのでは?と期待しています。

exportによるバックアップを取っておくことによって削除された項目や設定もimportによりリストアできますので、設定項目のバックアップとリストアというか観点では検証環境ではもちろんのこと本番環境にも活用できる機能です!
少なくともexportは実行しておいて損はないかと思います!

 

■ 適用範囲

 

今回 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を実行してファイルを取得します。

すべての項目の exportを取得する場合 
# isi cluster config exports create
あるコンポーネントを指定して取得する場合 (下の例はsnapshotとnfsのみ)
# isi cluster config exports create --components=snapshot, nfs


 

exports createを実行すると以下の画像のように export idが発行されます

※今回以下で取得したexport idは「node1-20211209034515」になります。

PowerScale OneFS 9.3.0.0 
node1-1# isi cluster config exports create
Are you sure you want to export cluster configuration? (yes/[no]): yes
This may take a few seconds, please wait a moment
Created export task 'node1-20211209034515'



 

② このexportが成功したか失敗したかは、上記の段階ではわかりませんので

以下のコマンドで確認します。

# isi cluster config exports view 対象のexport id 
# isi cluster config exports list –-verbose

実際に実行しますと、さきほど発行された export idの結果が以下のように出力されます

※以下は成功例です

node1-1# isi cluster config exports view node1-20211209034515 
ID: node1-20211209034515
Status: Successful
Done: ['http', 'quota', 'snapshot', 'nfs', 'smb', 's3', 'ndmp']
Failed: []
Pending: []
Message:
Path: /ifs/data/Isilon_Support/config_mgr/backup/node1-20211209034515






またexportデータに関しては上記にPassの記載があるように、ファイルエクスプローラーの「/ifs/data/Isilon_Support/config_mgr/backup」以下からアクセスして確認できます。

Tommy21_1-1639274167881.png
 

③ それでは無事にexportできていることも確認できましたので、このexportをもとにimportを実行して構成情報のリストアを実施してみたいとおもいます。

importを実行する場合に必要なのが export idです。

以下のimport実行例では先程発行された export id(node1-20211209034515)を用いて、importを実行します。

その際にexport≒バックアップを取得した状態と同じ設定のままでは、import実行後に本当にリストアできたかどうか検証して確認できませんよね。

なので、設定情報に変化をもたせるために予め作っておいたsnapshotなどのコンポーネントの設定を、export後にちょっと変更して、実際 importをしてリストアされるのか検証しました。

※コマンドに関しては先ほど紹介したexportの箇所がimportになっている程度なので割愛します。

node1-1# isi cluster config imports create node1-20211209034515 
※importの場合は必ず対象のexport idを指定する必要があります
Are you sure you want to import cluster configuration? (yes/[no]): yes
create時と同様に実行するか確認がされます。
This may take a few seconds, please wait a moment
Created import task 'node1-20211209035644'
import idがここで発行されます。





④ さきほど発行されたimport idでimportが成功したか確認します。

※以下は成功例です。

node1-1# isi cluster config imports view node1-20211209035644 
ID: node1-20211209035644
Export ID: node1-20211209034515
Status: Successful
Done: ['http', 'quota', 'snapshot', 'nfs', 'smb', 's3', 'ndmp']
Failed: []
Pending: []
Message:
Path: /ifs/data/Isilon_Support/config_mgr/restore/node1-20211209035644







無事に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で実施しています。

Spoiler

検証したコンポーネント

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の日曜日にリストアされた

 

検証したコンポーネントExport実行後に追加・設定したアイテムExport実行後に変更した設定項目 import (リストア)検証結果SmbSMB共有作成新規フォルダ自動作成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の日曜日にリストアされた 

 

 

Tommy21_2-1639274166978.jpeg

 

 

 

 

表にまとめてみたけど分かりづらいですね。。。

掲載上はたたんで隠しまたので気になる方は参照してください!

 

気を取り直して、snapshotを例に取り以下の画像で説明しますと。

snapshot設定のパスや、スケジュールに関してはimportによるリストアの対象外でした。

Tommy21_3-1639274167909.png

 

その一方で、たとえば下記画像のようにsnapshot機能自体に対するSetting項目ではimportによるリストの対象でした!

Tommy21_4-1639274167207.png

 

各コンポーネントおよびそれ自体に対する設定(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つの種類があることが分かりました。

  1. 各コンポーネントそれ自体
    • quotaやSMB共有など
  2.  各コンポーネントの設定項目
    • たとえば各quota内のoft/hard limit、またはSMB共有の個別アクセス権など
  3.  コンポーネント自体に対する設定項目(General Settingなど)
    • たとえばquotaのレポート作成間隔や保持数など

上記の結果を踏まえた大まかに結論をまとめますと、以下のことは少なくとも明らかになったとおもいます。

  • export後から追加された①に関してはimportによるリストア後に消されず維持される
  • export後に削除された①に関してはimportによってリストアされる
    (設定項目含めてimportの対象)
  • ②に関してはバックアップとリストアの対象だが、一部コンポーネントによって違いがある。
    (Snapshotのスケジュールは既に設定がされている場合にはリストア対象外である一方で、directory quotaのHard limitの値はリストア対象であった。)
  • ②に関してコンポーネントが削除からリストアされた場合は、設定されていた項目は、それがexport(バックアップ)実施される直前の設定項目が維持(リストア)される。
  • ③に関してはexport & importの対象であり、バックアップされリストアされる。

 

ドキュメント上ではconfig backupとだけ記載があり、またリストアによって現在ある共有などは消去されないとありましたが、importによって削除された共有などもリストアされるとの記載はなかったので検証って大事なことが身にしみて分かりました!

 

■ そのほかの利用上の注意点は?

 

  • バージョンアップ中はexport & importは実施できません。
  • 検証を様々なパターンで実施していくと、いくつものexport idとimport idが発行され、どれがどの時点でのデータなのかゴチャゴチャになってしまいました。あるexport idが習得された際の構成はどうだったのか。管理のために一覧表などを作成しておくと便利かもしれません
  • exportを実行する際に、ライセンスを持っていない項目を含めるとエラーが発生してしまいます
    →例えばsnapshotの項目だけをexportする場合を例に取ると、以下の コマンドで解決できます
    # isi cluster config exports create --components=snapshot

    createのあとに “--components=任意のコンポーネント”とコマンドを加えればいいだけなので簡単ですね!


  • さらに、上記のようにコンポーネントを指定した export の場合は、検証によって判明した大事な注意点があります!
    このコンポーネントを指定した export データをもとにリストアする場合には、以下のコマンドのようにリストアする項目を同時に指定あげる必要があります。
    指定されたコンポーネントとexport データが合わない場合は importがエラーになります。これで誤ったリストアを避ける仕組みなんですね!
    # isi cluster config imports create 任意のexport id --components=snapshot


 

以上です!

いかがでしたか?

OneFSはますます便利になっていきますね。この機能もGUIによるサポートや機能の拡充も予定されているので unstoppableなPowerScaleを今後もよろしくお願いいたします!

1 Rookie

 • 

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に対応

/ifs/.ifsvar/audit/logs/ /protocol
コンフィグログ OneFSの設定内容の変更ログ /ifs/.ifsvar/audit/logs/ /config

 

 監査ログは、下記の例のように連番のファイル名で保存され1GBに達すると圧縮されます。

# cd /ifs/.ifsvar/audit/logs/node001/protocol
# ls -l
-rw-r----- 1 root wheel 53M Mar 23 23:10 00000000.gz
-rw-r----- 1 root wheel 53M Mar 24 02:10 00000001.gz
-rw-r----- 1 root wheel 53M Mar 24 05:10 00000002.gz
-rw-r----- 1 root wheel 53M Mar 24 08:11 00000003.gz
-rw-r----- 1 root wheel 53M Mar 24 11:11 00000004.gz
-rw-r----- 1 root wheel 53M Mar 24 14:13 00000005.gz
-rw-r----- 1 root wheel 54M Mar 24 17:08 00000006.gz
-rw-r----- 1 root wheel 53M Mar 24 20:07 00000007.gz
-rw-r----- 1 root wheel 53M Mar 24 23:08 00000008.gz
-rw-r----- 1 root wheel 53M Mar 25 02:09 00000009.gz
-rw-r----- 1 root wheel 53M Mar 25 05:09 0000000a.gz
-rw-r----- 1 root wheel 53M Mar 25 08:10 0000000b.gz
-rw-r----- 1 root wheel 757M Mar 25 10:33 0000000c













 これらのログファイルはバイナリファイルのため、中身を確認するにはisi_audit_viewerコマンドを利用する必要があります。

<コマンド例>

# isi_audit_viewer -t protocol | head -10
[0: Sun Dec 5 17:08:05 2021] {"id":"e9a54e0f-55ed-11ec-af8a-005056b03e6d","timestamp":1638724085717774,"payloadType":"7afb8d54-0aa7-4ed4-9691-341313ee37e3","payload":"Audit Driver: flt_audit_nfs Loaded"}
[1: Sun Dec 5 17:09:56 2021] {"id":"2bda4c40-55ee-11ec-af8a-005056b03e6d","timestamp":1638724196794700,"payloadType":"c411a642-c139-4c7a-be58-93680bc20b41","payload":{"protocol":"SMB2","zoneID":1,"zoneName":"System","eventType":"create","detailType":"open-file-read","createResult":"DOES_NOT_EXIST","isDirectory":false,"desiredAccess":1179785,"clientIPAddr":"10.109.3.185","createDispo":1,"userSID":"S-1-22-1-0","userID":0,"fileName":"\\ifs\\desktop.ini","ntStatus":3221225524,"fsId":1,"partialPath":"desktop.ini","rootInode":2}}
[2: Sun Dec 5 17:10:03 2021] {"id":"2fec50b7-55ee-11ec-af8a-005056b03e6d","timestamp":1638724203623654,"payloadType":"c411a642-c139-4c7a-be58-93680bc20b41","payload":{"protocol":"SMB2","zoneID":1,"zoneName":"System","eventType":"create","detailType":"open-file-read","createResult":"OPENED","isDirectory":false,"desiredAccess":1179785,"clientIPAddr":"10.109.3.185","createDispo":1,"userSID":"S-1-22-1-0","userID":0,"fileName":"\\ifs\\test\\a.txt","ntStatus":0,"fsId":1,"partialPath":"test\\a.txt","rootInode":2,"inode":4295541261}}


 

 では本題の「Audit purging」です。この機能はOneFSが取得した監査ログに対して削除したい期間を指定し、その期間分のログを削除する機能です。これにより、簡単かつ効率的に監査ログをトリミングすることが可能になりました。ログの削除は、保持期間のポリシーに基づいて自動的かつ定期的に削除する方法(Auto deletion)と、手動で削除する方法(Manual deletion)の2つがあります。いずれもコマンドラインからのみ設定が可能です。

 Auto deletionは保持期間に基づいて動作します。次の図に示すように、内部タイマージョブが1時間ごとにトリガーされ保持期間外の監査ログを削除します。自動パージポリシーは時間範囲、つまり保持期間 (日数) に基づいています。ログ消去処理は自動的にバックグラウンドプロセスで1時間に1回実行されます。

m_h_0-1639455912648.png

 

 設定例を紹介します。

1. デフォルトでは、Auto Purgingは無効になっているので有効にします。

# isi audit settings global modify --auto-purging-enabled=true
You are enabling the automatic log purging.
Automatic log purging will run in background to delete audit log files.
Please check the retention period before enabling automatic log purging.
Are you sure you want to do this?? (yes/[no]): yes​



2.保持期間を指定します。

# isi audit settings global modify --retention-period=250​

3. 設定内容を確認します。

# isi audit settings global view
Protocol Auditing Enabled: No
Audited Zones: -
CEE Server URIs: -
Hostname:
Config Auditing Enabled: No
Config Syslog Enabled: No
Config Syslog Servers: -
Protocol Syslog Servers: -
Auto Purging Enabled: Yes ★Auto Purging機能が有効化されています
Retention Period: 250 ★250日に設定されています









 

 次に、2つ目の削除方法のManual deletionについて説明します。Manual deletionでは明示的に削除したい期間を指定し削除を実施します。設定例を紹介します。

1. isi audit logsコマンドの「delete –before=」を用いて、削除したい日を指定します。この例では2020年9月5日より前のログが削除されます。

# isi audit logs delete --before=2020-09-05
You are going to delete the audit logs before 2020-09-05.
Are you sure you want to do this?? (yes/[no]): yes
The purging request has been triggered.
`isi audit logs check` can be used to monitor the process.​



2. Statusを確認します。

# isi audit logs check
Purging Status:
Using Before Value: 2020-09-04
Currently Manual Purging Status: COMPLETED ★Status が COMPLETED になっています​


 このように、保持期間を設定して自動的に削除するほか、指定した期間のログを手動で削除することで肥大化するログを制御できるようになりました。

 最後に制約事項を記載します。

  • パージは、クラスタ内のすべてのノードに適用されるため、特定ノードの監査ログを削除もしくは残すということはできません
  • パージは、プロトコルアクセスログとコンフィグログの両方に適用されるため、プロトコルアクセスログおよびコンフィグログの一方だけを削除もしくは残すということはできません
  • 旧バージョンからアップグレードした場合は、監査ログのパージ機能はコミット後にのみ使用できます

 以上、OneFS9.1の新機能「Audit Purging」についての紹介でした。

4 メッセージ

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

amako_0-1639391303050.png

PowerScaleはノードを追加することで性能と容量の両方をリニアに拡張することができるスケールアウト型NASであることは、ご存じの方も多いと思います。今回登場したP100ノードは、容量は増やさず性能だけアップさせたい。そんなときに最適なノードです。

P100はSSDやHDDのようなストレージリソースを持たないので、他のノードと比べるとコストを抑えて性能をアップできます。またP100は1ノードから追加することができ、ライセンス費用もかからないのもコストを抑える要因です。ちなみにIDRにも対応してます。

OneFS9.3以降のPowerScale / Isilonクラスターであれば、P100を追加できます。P100を追加することで、CPU、メモリ、ネットワークインターフェイスなどのコントローラリソースを搭載したノードがクラスターに追加されるので、ユーザーからのワークロードを処理するノードが一台増え、クラスター全体としての処理能力が向上するのがP100導入のメリットです。

気になるP100のスペックですが、なんとF600と同じCPUやメモリを搭載してます。このリソースのほとんどがユーザーアクセスに使用されるので性能アップ期待できますね。

Spec P100 Performance Accelerator B100 Backup Accelerator
Chassis 1U PowerEdge R640 1U PowerEdge R640
CPU  (per node) Dual Socket Intel Cascade Lake 4210R (2.4GHz, 10C) Dual Socket Intel Cascade Lake 4210R (2.4GHz, 10C)
Memory (per node) 384GB / 768GB 384GB
Front End I/O 2x10/25GbE (SFP+ / SFP28)
2x40/100GbE (QSFP+ / QSFP28)
2x10/25GbE (SFP+ / SFP28)
2x40/100GbE (QSFP+ / QSFP28)
Back End I/O 2x10/25GbE (SFP+ / SFP28)
2x40/100GbE (QSFP+ / QSFP28)
2xInfiniBand QDR

2x10/25GbE (SFP+ / SFP28)
2x40/100GbE (QSFP+ / QSFP28)
2xInfiniBand QDR

 

そんなP100とA300クラスターを組合わせて「A300 + P100 性能増強パッケージ(仮)」の構成も今後増えていきそうです。

amako_0-1639459743561.png

他にどんなお客様に向いてるんでしょうか?
既にPowerScaleをお使いで、導入後にユーザーアクセス数が増えた、高い性能が必要になった、InsightIQで性能監視をしてみたら以外とノードの使用率が高かった、など何かしらの理由で性能面を補強したい場合、それとNVIDIA GPU Directのような非常に高い性能が必要な環境で、F600やF900のノード数を減らし代わりにP100ノードを搭載する。そのような用途で使ってもらえることを想定しています。特にリードが多いワークロードではP100の効果が見込めるので、低コストで性能のみ上げたい環境にはもってこいです。

  • こちらがP100の見た目です。同じPowerEdge R640ベースのF200とそっくりですね。

amako_2-1639457123702.png

amako_0-1639531596156.png

 

 

Backup Accelerator Nodes B100

amako_0-1639404177471.png

続いてB100ノードの紹介です。Backup Accelerator Nodesの名前のとおりPowerScaleクラスター内のデータを、NDMP(2-Way)で外部にバックアップを取りたい場合に追加するノードです。これまでもNDMP(2-Way)バックアップ接続用にFCポートをノードに追加するNDMPアクセラレータカード(Sheba Card)は用意していましたが、B100はFCポートを搭載しているだけでなく、バックアップのジョブも請け負うことで、既存ノードのコントローラリソースを使うことなくバックアップジョブを実施できます。

PowerScaleクラスターにB100を追加するメリットです。

  • バックアップストレージと直接FC接続することで、
    ユーザーのトラフィックが流れるネットワークへの影響を抑える。
  • B100がバックアップのジョブを実施することで、
    他のノードのリソース消費を抑え、ファイルサービスへの影響を最小限に抑える。

amako_0-1639464948159.png

  • こちらがB100の見た目です。NDMP接続用のFCポートを搭載しているのがP100との違いすね。

    amako_1-1639531637717.png

 

今回お伝えしきれなかった詳細については、こちらのホワイトペーパーからも確認できます。

PowerScale Accelerator Nodes Overview and General Best Practices

 

 

PowerScale F600 のアップデート

新しいモデルではありませんが、F600に追加された構成オプションについても紹介します。F600といえばPowerScaleファミリーの中でも、高い性能要件で選ばれるオールフラッシュモデルですが、EDA市場の高い性能要件のご要望に応え、従来より高性能のCPUと、容量の増えた736GBメモリを選択できるようになりました。

このF600の追加オプションで、これまでカバーできなかったこんなご要望にも応えることができます。

  • 非常に高い性能要件だがF900を選ぶほど容量を必要としない。
  • F900よりもコストを抑えたい。
  • ラックスペースを抑えたい。※F900(2U)に対してF600(1U)は半分のラックスペースです。

amako_1-1639402933322.png

F600含めPowerScale All Flash Nodeのスペックはこちらからもご確認できます。
Dell EMC PowerScale All-Flash Family Specification Sheet

今回のAsk The Expert PowerScaleコーデ2021冬編に、最後までお付き合いいただきありがとうございました。今後も進化し続けるPowerScaleにご期待下さい。

イベントは見つかりませんでした!

Top