[AskTheExperts]PowerScaleコーデ 2021冬

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

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

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に保存すると、「対象のパスが長すぎます」とエラーになります。

このような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バイトまで(デフォルト)

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

 次にコマンドラインからの設定方法ですが、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文字までしか読み取れない。

Long File Nameの補足情報

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

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

Dell EMC PowerScale OneFS: Long Filename Support

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

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に今後もご期待下さい。

# 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の方は物理も論理もサイズがゼロとなっており容量が一切消費されていないことがわかります。

# 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

まず、Writable Snapshotのファイルに対して書き込みができましたね。感動。
サイズを見ると、追記された分だけの容量が消費されていることがわかります。わずかな文字列だったので、論理サイズはファイルシステムのブロックサイズである8KB（8192バイト）となり、保護レベルが+2d:1nの実行環境だったので物理的には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はまだファーストステップに過ぎなく、まだまだ十分ではないかもしれません。性能や機能改善がなされていく予定ですので、今後の進化に乞うご期待！

# 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つ目のトピックです。
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以上である必要があるので、適合したバージョンを利用してください。

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

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

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

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

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

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

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

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

　インストールバンドルが提供されるようになったのは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がまさにスマートに接続を制御しています。

　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をよろしくお願いいたします。

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

　こんにちは。今回はOneFSの監査ログの新機能について紹介します。

　システム管理者にとって、ストレージに限らずシステム運用では、ログの管理は重要な業務のひとつというのは周知の事実となっています。ファイルサーバの運用で重要なログは、HW障害通知やQuota超過などのイベントログの他に、監査ログと呼ばれる「保存ファイルに対するアクセスログ」と「ファイルサーバの設定情報の変更ログ」が挙げられます。

　監査ログは、昨今のランサムウェア攻撃やファイル漏えいなどのセキュリティ脅威に遭遇した際に、いつどのファイルが誰からアクセスされたか、また、ファイルサーバの設定がどのように変更されたかなどの証跡調査に利用されるケースがあります。監査ログが取得されていない環境では、被害の範囲やいつから攻撃を受けていたのかを特定することは困難となり、被害状況の全貌解明に時間がかかる場合も考えられます。監査ログにはそのような証跡管理の目的があるため、PowerScaleでは永久に保存するものという考えでした。

　一方、PowerScaleはデータ移行することなく機器の入れ替えが簡単なため、長く利用されるケースが大半です。PowerScaleの利用期間の長期化に伴い、データに対するアクセス回数もおのずと増えるため監査ログも増え続けていきます。また、環境によっては、監査ログを収集・解析し見やすく表示する3rd Partyのログ管理ツールを利用しており、そのツールが監査ログを保管するためPowerScale側では永久に保存する必要はない、というケースもあります。増え続ける監査ログは時には数十TBになることもあります。クラスタ内で増え続ける監査ログの扱いは、管理者の悩みのたねのひとつでもありました。

　これらのシステム管理者の悩みを解決すべく、OneFS9.1で「Audit purging」という監査ログをパージする機能が追加されました。この機能の説明の前に、OneFSの監査ログについて簡単に振り返りたいと思います。OneFSで取得可能なログは下記の2種類あります。

# 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 -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}}

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

　設定例を紹介します。

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」についての紹介でした。

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やメモリを搭載してます。このリソースのほとんどがユーザーアクセスに使用されるので性能アップ期待できますね。

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

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

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

Backup Accelerator Nodes B100

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

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

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

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

  

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

PowerScale Accelerator Nodes Overview and General Best Practices

PowerScale F600 のアップデート

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

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

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

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

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