Category: Dell

Katamari さん

ProxyNASサーバーはUnityの中ではNAS Serverの一つなので

他のNAS サーバーの運用方法において違いはないと考えて頂いて結構です。

そのため通常のNAS サーバー運用のように一度設定してマウントしっぱなし、でも問題はないです。

Document にもproxy NAS Server must reside on the same SP as the NAS Server that it will be providing access to.という条件の他

注意点はないです。

https://support.emc.com/docu81240_Dell-EMC-Unity:-NAS-Capabilities—A-Detailed-Review.pdf?language=en_US ( page 55 )

Proxy Nas server でのマウント問題などで調べてみても情報はありませんでした。

Detect, investigate, and respond to advanced threats. Confirm and manage identities. Ultimately, prevent IP theft, fraud, and cybercrime.

Explore products and solutions from RSA.

Visit RSA.com

前回は、Elastic Cloud Storage(ECS)をご紹介いたしました。その中でIsilonとECSの連携について軽く触れましたが、今回は具体的にどのように動作するのか設定と併せてご紹介します。

IsilonとECSの連携はIsilonのCloudPoolsという自動階層化の機能によって実現しますが、CloudPoolsに入っていく前に少しだけストレージの自動階層化についてご説明します。

自動階層化の機能自体は古くからILMやHSMなどと言われており、高速な（性能単価に優れている）ストレージと低速な（容量単価に優れている）ストレージ間でデータを自動で移動させる技術のことを指します。特に新しい技術ではありませんが、最近では非構造化データの肥大化や分析基盤のアーキテクチャにおいて高速（オールフラッシュ）で分析を行い結果の保管のために低速（アーカイブ）に移動させるようなニーズが高まっています。

Isilonには性能単価に優れたノード、容量単価に優れたノードなど様々なタイプのノードがありますがSmartPoolsによりノードの混在が可能となりノード間でポリシベースの自動階層化を行うことができます。長期間参照されないファイルは容量単価の良いノードに自動的に移すことにより性能と容量とコストのバランスが取れTCOの削減につながります。

このSmartPoolsの機能を拡張してクラウドストレージにアーカイブする機能のことをCloudPoolsと言います。また、クラウドストレージ以外にもECSや別クラスタのIsilonなどに階層化することもできます。

なお、ECSは容量無制限にスケールアウトできるのでIsilonとECSを組み合わせることにより、実質無制限のストレージシステムを作ることができます！（と言ってもIsilonのみで68PBまでスケールアウトできます）

どの階層にファイルがあってもクライアントやアプリケーションからは透過的にアクセスできます

上記のとおり自動階層化自体は最新の技術ではないですが、実は意外と自動階層化の機能を有していないストレージ製品もあります。特に従来型のNASではRAIDでデータ保護を行っていたりボリュームという概念があるためファイル単位での自動階層化が出来ないものや、そもそも自動階層化をサポートしていない製品があります。Isilonには以前から自動階層化の機能であるSmartPoolsが実装されており、OneFS 8.0から実装されたCloudPoolsも2年以上の実績があります。Isilonであればノード間やパブリッククラウドに対してファイル単位で階層化を行うことができます。

今回は以下とおり、Isilon(OneFS)シミュレータ 1台と、ECS Community Edition 1台を用意しました。実際に試して頂く際にECS Community Editionは前回の内容を参考に準備いただければと思いますが、準備するのが大変な場合はECS TEST DRIVEをご利用頂くこともできます。

1. ECSの設定

ECS側では、CloudPools用の専用NamespaceとCloudPoolsからアクセスする際の専用のユーザを作成していきます。なお、Bucketは自動的に作成されますので作成不要です。

1.1 Namespaceの作成

はじめにCloudPools用のNamespaceを作成します。ECS Portalにログインして「Manage」から「Namespace」を選択します。次に「New Namespace」をクリックして以下を入力します。

・Name = cloudpools

入力後「Save」をクリックします。

以下のとおりcloudpoolsというNamespaceが作成されたことを確認します。

1.2 ユーザの作成

CloudPoolsからアクセスする際に必要なユーザを作成します。「Manage」から「Users」を選択します。次に、「New Object User」をクリックして以下を入力します。

・Name = cloudpools_user1

・Namespace = cloudpools

入力後「Save」をクリックします。

以下のとおりcloudpools_user1というユーザが作成されたことを確認します。

1.3 Secret Keyの生成

上記1.2で作成したcloudpools_user1のSecret Keyを生成していきます。cloudpools_user1の「Actions」にある「Edit」をクリックします。以下の画面のS3 / Atmosにある「Generate & Add Secret Key」をクリックします。「Show Secret Key」のチェックボックスにチェックを入れるとSecret Keyが表示されますので内容をコピーします。（コピーしたSecret Keyは2.2で使用します。）

2. Isilon CloudPoolsの設定

Isilon側の設定の流れとしては、先ずSmartPoolsとCloudPoolsの評価ライセンスを有効化します。次にCloudPoolsの設定（Cloud Storage AccountとCloudPoolの作成）を行い、自動階層化のポリシを定義していきます。

2.1 ライセンスの有効化

CloudPoolsの利用にあたりライセンスを有効化する必要があります。OneFS 8.1では製品やシミュレータの評価ライセンスをお客様やパートナ様のほうでも有効化いただけるようになりました。

OneFS web administration interface（Web UI）にログインします。「Cluster Management」から「Licensing」を選択します。一番下に「Manage trial versions of software modules」という項目がありますので、「Manage Trials」をクリックします。

Manage trialsの画面がポップアップされ、どの機能を評価するか選択します。CloudPoolsはSmartPoolsのライセンスも必要になるため最低限SmartPoolsとCloudPoolsを選択し「Start Trial」をクリックして有効にしてください。（下記は全部の機能を有効にした例です。）

2.2 Cloud Storage Accountの作成

ECSにアクセスするためのアカウントを作成します。「File System」メニューから「Storage Pools」の「CloudPools」を選択し「Create a Cloud Storage Account」をクリックします。

以下のとおりECSの接続情報を入力していきます。

・Name or Alias = ecs_cloudpools_user1

・Type = EMC ECS Appliance

・URI = http://luna.isilonian.local:9020

・User Name = cloudpools_user1

・Key = my2DnVGKC7xdh+D2Cg148nhN8NPXL/GPZkvwk0zH（1.3 で生成/確認したSecret Key）

入力後に「Connect Account」をクリックします。このタイミングで接続のテストが行われ、ECS側にBucketが生成されます。

2.3 CloudPoolの作成

続いて、「Create a CloudPool」をクリックして以下の内容を入力します。

・Name = ecs_cloudpool1

・Type = EMC ECS Appliance

・Account in CloudPool = ecs_cloudpools_user1

登録が完了した後、以下のとおりCloud Storage AccountsとCloudPoolsの状態がEnabledとなっていることを確認します。

2.4 ECS PortalからBucketsの確認

ECS PortalからBucketsを確認するとcloudpoolsのnamespace配下にBucketが作成されたことがわかります。

同様に、S3 Browserからも空のBucketsが確認できます。

3. 自動階層化の設定

自動階層化にあたりポリシを設定していきます。SmartPoolsでIsilon内で階層化する場合でもCloudPoolsで外部ストレージへ階層化する場合でもFile Pool Policyで設定することで、きめ細かいポリシを一気通貫で作成することができます。ポリシで設定可能な項目としては、ファイル名、ファイルパス、ファイルタイプ、ファイルサイズ、作成日時、更新日時、アクセス日時、ファイル属性、属性変更日時があり、これらをANDもしくはORで組み合わせて設定することができます。

「File System」メニューから「Storage Pools」の「File Pool Policies」を選択します。次に「Create a File Pool Policy」をクリックします。

各フィールドに以下の内容を入力します。

・Policy Name = archive_to_ecs

・File Matching Criteria = “Modified” “is older than” “1” “second” agoを選択（条件にマッチすれば何でもOKです。）

・Move to cloud storage = チェックボックスのチェックをつける

・CloudPool Storage Target = ecs_cloudpool1

入力後、「Create Policy」をクリックします。

4. 動作確認

4.1 テストファイルの作成

/ifs配下にhogeという名前のディレクトリを作成してSMB共有を設定し幾つかファイルを配置します。配置するファイルは何でも良いですが、今回は動作確認しやすいように少し大きめなサイズのファイルを作成します。なお、簡単に大きめなサイズのファイルが作れる＆圧縮が効くという目的でペイントを使ってビットマップを作成します。

9.3MBのファイルが作成されました。File System Explorerからは以下のとおり確認できます。

duコマンドを実行しても同様に9.3MBのビットマップが確認できます。

sim-1# du -sh 画像.bmp 9.3M 画像.bmp

isi getコマンドで実体があるか確認します。SmartLinkedの項目がTrueになっているファイルはIsilon側に実体が存在せずクラウド（今回の場合はECS）に移動しています。現時点では以下のとおりFalseになっています。ちなみに、OneFS 8.0ではSmartLinkedではなくStubbedと表示されます。

sim-1# isi get -DD 画像.bmp | grep -i smartlinked * SmartLinked: False

4.2 SmartPools Jobの実行

SmartPoolsのJobを手動で実行します。（通常はスケジュールによる自動実行となりますが動作確認のため。）

「Cluster Management」の「Job Operations」、「Job Types」と辿りSmartPoolsの「Start Job」をクリックします。以下の画面が表示されますので「Start Job」を実行します。

CloudPoolsの状態はisi cloud jobs listコマンドで確認ができます。”Effective State”がrunningからcompletedに変わります。

sim-1# isi cloud jobs list ID Description Effective State Type ————————————————————————————– 1 Write updated data back to the cloud running cache-writeback 2 Expire CloudPools cache running cache-invalidation 3 Clean up cache and stub file metadata running local-garbage-collection 4 Clean up unreferenced data in the cloud running cloud-garbage-collection 10 completed archive

isi getコマンドを実行すると”SmartLinked”がTrueに変化していることが確認できます。

sim-1# isi get -DD 画像.bmp | grep -i smartlinked * SmartLinked: True SmartLinked file flags 0 5 SmartLinked file size 5 9

duコマンドを実行すると、ファイルサイズが減っている（512B）ことが確認できます。これは、Isilon側に実体は存在せずSmartLinkのみ保存されているためです。もちろんユーザからの見た目のパスや実際のファイルサイズに変更はありません。

sim-1# du -sh 画像.bmp 512B 画像.bmp

4.3 ECSのBucketの確認

ECSのBucketをS3 Browserで確認すると、1MBのオブジェクトが9個と316.85KBのオブジェクトが1個存在していることが確認できます。クラウドストレージにアーカイブされたデータをIsilonではCloud Data Object（CDO）と呼んでいます。CDOは1MB単位で分割されECSへ格納されます。1個だけある316.85KBは端数（残り）です。

4.4 CloudPoolsによる圧縮機能

CloudPoolsは転送する際に圧縮と暗号化を行うオプションがあります。先程試したファイルと同じものを圧縮した場合にどうなるか試してみます。（なお、今回作成したビットマップは非常に圧縮が効くようになっておりWindowsの標準のZIP圧縮ツールを使うと9.42KBとなりました。）

sim-1# du -sh 画像2.bmp 9.3M 画像2.bmp

「File System」メニューから「Storage Pools」の「File Pool Policies」を選択します。上記3.で作成したFile Pool Policyを「View / Edit」をクリックし編集します。Compress data before transferにチェックを入れ「Save Changes」で保存後、上記4.2と同様の操作でSmartPoolsを実行します。

4.5 ECSのBucketの確認

ECSのBucketを確認すると、今度は1.08KBのオブジェクトが8個、1.12KBのオブジェクトが1個と408Bのオブジェクトが1個となりました。合計で約10KBですので約900分の1に圧縮されていることが確認できます。

ご覧頂きましたように、IsilonのCloudPoolsとECSの組み合わせによって性能と容量のバランスに優れたシームレスなストレージシステムを作ることができます。また、ECSはIsilonのアーカイブ先だけではなくバックアップのターゲットやS3を用いたモバイル/Webベースのアプリケーションの基盤などにも使用可能ですので、これらのデータを統合する中核のストレージとしてECSを配置することによりTCOの削減にも繋がります。なお、ECSのGeoレプリケーションは高い保護レベルでデータのオーバヘッド削減できるアルゴリズムを採用していますので特にGeoレプリケーションを検討されている場合は是非ご連絡ください。

CloudPools含めIsilonおよびECSは今後も様々な機能がエンハンスされていきますのでご期待ください。

ISILON CLOUDPOOLS AND ELASTIC CLOUD STORAGE (Solution Guide)

DELL EMC ISILON CLOUDPOOLS

Isilon Simulator download

ECS CE download

ECS Test Drive

IsilonianTech 第1回 Isilonとオープンソース ～REX-Ray編～

IsilonianTech 第2回 Isilonとオープンソース ～OpenStack Manila編～

IsilonianTech 第3回 Isilonとオープンソース ～Isilon Data Insights Connector～

IsilonianTech 第4回 Software Defined Storage ～IsilonSD Edge～

IsilonianTech 第5回 Isilonとオープンソース ～Isilon-POSH～

IsilonianTech 第6回 Isilonとオープンソース ～Elastic Stack編～

IsilonianTech 第7回 Isilonとデータアナリティクス ～Cloudera編～

IsilonianTech 第8回 Elastic Cloud Storage (ECS) ～ECS Community Edition～

IsilonianTech 第9回 ISILON + ECS = UNLIMITED ～Isilon CloudPools～

安井 謙治

Dell EMC │Unstructured Data Solutions

UDS事業本部SE部

Detect, investigate, and respond to advanced threats. Confirm and manage identities. Ultimately, prevent IP theft, fraud, and cybercrime.

Explore products and solutions from RSA.

Visit RSA.com

Detect, investigate, and respond to advanced threats. Confirm and manage identities. Ultimately, prevent IP theft, fraud, and cybercrime.

Explore products and solutions from RSA.

Visit RSA.com

	Having worked in tech for the last 25 years, I have geeked out on my fair share of new devices. But nothing gets me more excited than the opportunity to deploy tech in ways that can solve real challenges. This week in partnership with the Basel Action Network (BAN), I’m thrilled to introduce a new pilot program that will use global tracking technology utilized by BAN to provide greater transparency into our own US electronics recycling programs. As part of BAN’s new EarthEye tracking service, the trackers will be placed on non-working electronics that enter our consumer takeback programs and … READ MORE
ENCLOSURE:https://blog.dellemc.com/uploads/2018/06/Dell-E-Waste-Boards-Von-Wong_1000x500-600×356.jpg
Update your feed preferences

Wrapping up these articles on OneFS groups, we’ll take a look at what and how we can learn about a cluster’s state and transitions. Group state is a list of nodes, drives and protocols which are participating in a cluster at a particular point in time.

Under normal operating conditions, every node and its requisite disks are part of the current group, and the group status can be viewed from any node in the cluster using the ‘sysctl efs.gmp.group’ CLI command. If a greater level of detail is desired, the syscl efs.gmp.current_info command will report extensive current GMP information.

When a group change occurs, a cluster-wide process writes a message describing the new group membership to /var/log/messages on every node. Similarly, if a cluster ‘splits’, the newly-formed sub-clusters behave in the same way: each node records its group membership to /var/log/messages. When a cluster splits, it breaks into multiple clusters (multiple groups). This is rarely, if ever, a desirable event. A cluster is defined by its group members. Nodes or drives which lose sight of other group members no longer belong to the same group and therefor no longer belong to the same cluster.

The ‘grep’ CLI utility can be used to view group changes from one node’s perspective, by searching /var/log/messages for the expression ‘new group’. This will extract the group change statements from the logfile. The output from this command may be lengthy, so can be piped to the ‘tail’ command to limit it the desired number of lines.

Please note that, for the sake of clarity, the protocol information has been removed from the end of each group string in all the following examples. For example:

{ 1-3:0-11, smb: 1-3, nfs: 1-3, hdfs: 1-3, swift: 1-3, all_enabled_protocols: 1-3 }

Will be represented as:

{ 1-3:0-11 }

In the following example, the ‘tail -10’ command limits the outputted list to the last ten group changes reported in the file:

tme-1# grep -i ‘new group’ /var/log/messages | tail –n 10

2018-06-15-T08:07:50-04:00 <0.4> tme-1 (id1) /boot/kernel.amd64/kernel: [gmp_info.c:1863] (pid 1814=”kt: gmp-drive-updat”) new group: : { 1:0-4, down: 1:5-11, 2-3 }

2018-06-15-T08:07:50-04:00 <0.4> tme-1 (id1) /boot/kernel.amd64/kernel: [gmp_info.c:1863] (pid 1814=”kt: gmp-drive-updat”) new group: : { 1:0-5, down: 1:6-11, 2-3 }

2018-06-15-T08:07:50-04:00 <0.4> tme-1(id1) /boot/kernel.amd64/kernel: [gmp_info.c:1863] (pid 1814=”kt: gmp-drive-updat”) new group: : { 1:0-6, down: 1:7-11, 2-3 }

2018-06-15-T08:07:50-04:00 <0.4> tme-1 (id1) /boot/kernel.amd64/kernel: [gmp_info.c:1863] (pid 1814=”kt: gmp-drive-updat”) new group: : { 1:0-7, down: 1:8-11, 2-3 }

2018-06-15-T08:07:50-04:00 <0.4> tme-1 (id1) /boot/kernel.amd64/kernel: [gmp_info.c:1863] (pid 1814=”kt: gmp-drive-updat”) new group: : { 1:0-8, down: 1:9-11, 2-3 }

2018-06-15-T08:07:50-04:00 <0.4> tme-1 (id1) /boot/kernel.amd64/kernel: [gmp_info.c:1863] (pid 1814=”kt: gmp-drive-updat”) new group: : { 1:0-9, down: 1:10-11, 2-3 }

2018-06-15-T08:07:50-04:00 <0.4> tme-1 (id1) /boot/kernel.amd64/kernel: [gmp_info.c:1863] (pid 1814=”kt: gmp-drive-updat”) new group: : { 1:0-10, down: 1:11, 2-3 }

2018-06-15-T08:07:50-04:00 <0.4> tme-1 (id1) /boot/kernel.amd64/kernel: [gmp_info.c:1863] (pid 1814=”kt: gmp-drive-updat”) new group: : { 1:0-11, down: 2-3 }

2018-06-15-T08:07:51-04:00 <0.4> tme-1 (id1) /boot/kernel.amd64/kernel: [gmp_info.c:1863] (pid 1814=”kt: gmp-merge”) new group: : { 1:0-11, 3:0-7,9-12, down: 2 }

2018-06-15-T08:07:52 -04:00 <0.4> tme-1 (id1) /boot/kernel.amd64/kernel: [gmp_info.c:1863] (pid 1814=”kt: gmp-merge”) new group: : { 1-2:0-11, 3:0-7,9-12 }

All the group changes in this set happen within two seconds of each other, so it’s worth looking earlier in the logs prior to the incident being investigated.

Here are some useful data points that can be deduced from the example above:

1. The last line shows that the cluster’s nodes are operational belong to the group. No nodes or drives report as down or split. (At some point in the past, drive ID 8 on node 3 was replaced, but a replacement disk was subsequently added successfully.)
2. Node 1 rebooted. In the first eight lines, each group change is adding back a drive on node 1 into the group, and nodes two and three are inaccessible. This occurs on node reboot prior to any attempt to join an active group, and is indicative of healthy behavior.
3. Nodes 3 forms a group with node 1 before node 2 does. This could suggest that node 2 rebooted while node 3 remained up.

A review of group changes from the other nodes’ logs should be able to confirm this. In this case node 3’s logs show:

tme-1# grep -i ‘new group’ /var/log/messages | tail -10

2018-06-15-T08:07:50-04:00 <0.4> tme-3(id3) /boot/kernel.amd64/kernel: [gmp_info.c:1863] (pid 1814=”kt: gmp-drive-updat”) new group: : { 3:0-4, down: 1-2, 3:5-7,9-12 }

2018-06-15-T08:07:50-04:00 <0.4> tme-3(id3) /boot/kernel.amd64/kernel: [gmp_info.c:1863] (pid 1814=”kt: gmp-drive-updat”) new group: : { 3:0-5, down: 1-2, 3:6-7,9-12 }

2018-06-15-T08:07:50-04:00 <0.4> tme-3(id3) /boot/kernel.amd64/kernel: [gmp_info.c:1863] (pid 1814=”kt: gmp-drive-updat”) new group: : { 3:0-6, down: 1-2, 3:7,9-12 }

2018-06-15-T08:07:50-04:00 <0.4> tme-3(id3) /boot/kernel.amd64/kernel: [gmp_info.c:1863] (pid 1814=”kt: gmp-drive-updat”) new group: : { 3:0-7, down: 1-2, 3:9-12 }

2018-06-15-T08:07:50-04:00 <0.4> tme-3(id3) /boot/kernel.amd64/kernel: [gmp_info.c:1863] (pid 1814=”kt: gmp-drive-updat”) new group: : { 3:0-7,9, down: 1-2, 3:10-12 }

2018-06-15-T08:07:50-04:00 <0.4> tme-3(id3) /boot/kernel.amd64/kernel: [gmp_info.c:1863] (pid 1814=”kt: gmp-drive-updat”) new group: : { 3:0-7,9-10, down: 1-2, 3:11-12 }

2018-06-15-T08:07:50-04:00 <0.4> tme-3(id3) /boot/kernel.amd64/kernel: [gmp_info.c:1863] (pid 1814=”kt: gmp-drive-updat”) new group: : { 3:0-7,9-11, down: 1-2, 3:12 }

2018-06-15-T08:07:50-04:00 <0.4> tme-3(id3) /boot/kernel.amd64/kernel: [gmp_info.c:1863] (pid 1814=”kt: gmp-drive-updat”) new group: : { 3:0-7,9-12, down: 1-2 }

2018-06-15-T08:07:50-04:00 <0.4> tme-3(id3) /boot/kernel.amd64/kernel: [gmp_info.c:1863] (pid 1828=”kt: gmp-merge”) new group: : { 1:0-11, 3:0-7,9-12, down: 2 }

2018-06-15-T08:07:52 -04:00 <0.4> tme-3(id3) /boot/kernel.amd64/kernel: [gmp_info.c:1863] (pid 1828=”kt: gmp-merge”) new group: : { 1-2:0-11, 3:0-7,9-12 }

Since node 3 rebooted at the same time, it’s worth checking node 2’s logs to see if it also rebooted simultaneously. In this instance, the logfiles confirm this. Given that all three nodes rebooted at once, it’s highly likely that this was a cluster-wide event, rather than a single-node issue. OneFS ‘software watchdog’ timeouts (also known as softwatch or swatchdog), for example, cause cluster-wide reboots. However, these are typically staggered rather than simultaneous reboots. The Softwatch process monitors the kernel and dumps a stack trace and/or reboots the node when the node is not responding. This helps protects the cluster from the impact of heavy CPU starvation and aids the issue detection and resolution process.

If a cluster experiences multiple, staggered group changes, it can be extremely helpful to construct a timeline of the order and duration in which nodes are up or down. This info can then be cross-referenced with panic stack traces and other system logs to help diagnose the root cause of an event.

For example, in the following log excerpt, a node cluster experiences six different node reboots over a twenty-minute period. These are the group change messages from node 14, which that stayed up the whole duration:

tme-14# grep -i ‘new group’ /var/log/messages

2018-06-10-T14:54:00-04:00 <0.4> tme-14(id20) /boot/kernel.amd64/kernel: [gmp_info.c:1863] (pid 1060=”kt: gmp-merge”) new group: : { 1-2:0-11, 6-8, 9,13-15:0-11, 16:0,2-12, 17-18:0-11, 19-21, diskless: 6-8, 19-21 }

2018-06-15-T06:44:38-04:00 <0.4> tme-14(id20) /boot/kernel.amd64/kernel: [gmp_info.c:1863] (pid 1060=”kt: gmp-split”) new group: : { 1-2:0-11, 6-8, 13-15:0-11, 16:0,2-12, 17- 18:0-11, 19-21, down: 9}

2018-06-15-T06:44:58-04:00 <0.4> tme-14(id20) /boot/kernel.amd64/kernel: [gmp_info.c:1863] (pid 1066=”kt: gmp-split”) new group: : { 1:0-11, 6-8, 13-14:0-11, 16:0,2-12, 17- 18:0-11, 19-21, down: 2, 9, 15}

2018-06-15-T06:45:20-04:00 <0.4> tme-14(id20) /boot/kernel.amd64/kernel: [gmp_info.c:1863] (pid 1066=”kt: gmp-split”) new group: : { 1:0-11, 6-8, 14:0-11, 16:0,2-12, 17-18:0- 11, 19-21, down: 2, 9, 13, 15}

2018-06-15-T06:47:09-04:00 <0.4> tme-14(id20) /boot/kernel.amd64/kernel: [gmp_info.c:1863] (pid 1066=”kt: gmp-merge”) new group: : { 1:0-11, 6-8, 9,14:0-11, 16:0,2-12, 17- 18:0-11, 19-21, down: 2, 13, 15}

2018-06-15-T06:47:27-04:00 <0.4> tme-14(id20) /boot/kernel.amd64/kernel: [gmp_info.c:1863] (pid 1066=”kt: gmp-split”) new group: : { 6-8, 9,14:0-11, 16:0,2-12, 17-18:0-11, 19-21, down: 1-2, 13, 15}

2018-06-15-T06:48:11-04:00 <0.4> tme-14(id20) /boot/kernel.amd64/kernel: [gmp_info.c:1863] (pid 2102=”kt: gmp-split”) new group: : { 6-8, 9,14:0-11, 16:0,2-12, 17:0-11, 19- 21, down: 1-2, 13, 15, 18}

2018-06-15-T06:50:55-04:00 <0.4> tme-14(id20) /boot/kernel.amd64/kernel: [gmp_info.c:1863] (pid 2102=”kt: gmp-merge”) new group: : { 6-8, 9,13-14:0-11, 16:0,2-12, 17:0-11, 19- 21, down: 1-2, 15, 18}

2018-06-15-T06:51:26-04:00 <0.4> tme-14(id20) /boot/kernel.amd64/kernel: [gmp_info.c:1863] (pid 85396=”kt: gmp-merge”) new group: : { 2:0-11, 6-8, 9,13-14:0-11, 16:0,2-12, 17:0-11, 19-21, down: 1, 15, 18}

2018-06-15-T06:51:53-04:00 <0.4> tme-14(id20) /boot/kernel.amd64/kernel: [gmp_info.c:1863] (pid 85396=”kt: gmp-merge”) new group: : { 2:0-11, 6-8, 9,13-15:0-11, 16:0,2-12, 17:0-11, 19-21, down: 1, 18}

2018-06-15-T06:54:06-04:00 <0.4> tme-14(id20) /boot/kernel.amd64/kernel: [gmp_info.c:1863] (pid 85396=”kt: gmp-merge”) new group: : { 1-2:0-11, 6-8, 9,13-15:0-11, 16:0,2-12, 17:0-11, 19-21, down: 18}

2018-06-15-T06:56:10-04:00 <0.4> tme-14(id20) /boot/kernel.amd64/kernel: [gmp_info.c:1863] (pid 2102=”kt: gmp-merge”) new group: : { 1-2:0-11, 6-8, 9,13-15:0-11, 16:0,2-12, 17-18:0-11, 19-21}

2018-06-15-T06:59:54-04:00 <0.4> tme-14(id20) /boot/kernel.amd64/kernel: [gmp_info.c:1863] (pid 85396=”kt: gmp-split”) new group: : { 1-2:0-11, 6-8, 9,13-15,17-18:0-11, 19-21, down: 16}

2018-06-15-T07:05:23 -04:00 <0.4> tme-14(id20) /boot/kernel.amd64/kernel: [gmp_info.c:1863] (pid 1066=”kt: gmp-merge”) new group: : { 1-2:0-11, 6-8, 9,13-15:0-11, 16:0,2-12, 17-18:0-11, 19-21}

First, run the isi_nodes “%{name}: LNN %{lnn}, Array ID %{id}” to map the cluster’s node names to their respective Array IDs.

Before the cluster node outage event on June 15 there was a group change on June 10:

2018-06-10-T14:54:00-04:00 <0.4> tme-14(id20) /boot/kernel.amd64/kernel: [gmp_info.c:1863] (pid 1060=”kt: gmp-merge”) new group: : { 1-2:0-11, 6-8, 9,13-15:0-11, 16:0,2-12, 17-18:0-11, 19-21, diskless: 6-8, 19-21 }

After that, all nodes came back online and the cluster could be considered healthy. The cluster contains nine X210s with twelve drives apiece and six diskless nodes (accelerators). The Array IDs now extend to 21, and Array IDs 3 through 5 and 10 through 12 are missing. This confirms that six nodes were added to or removed from the cluster.

So, the first event occurs at 06:44:38 on 15 June:

2018-06-15-T06:44:38-04:00 <0.4> tme-14(id20) /boot/kernel.amd64/kernel: [gmp_info.c:1863] (pid 1060=”kt: gmp-split”) new group: : { 1-2:0-11, 6-8, 13-15:0-11, 16:0,2-12, 17- 18:0-11, 19-21, down: 9, diskless: 6-8, 19-21 }

Node 14 identifies Array ID 9 (LNN 6) as having left the group.

Next, twenty seconds later, two more nodes (2 & 15) are marked as offline:

2018-06-15-T06:44:58-04:00 <0.4> tme-14(id20) /boot/kernel.amd64/kernel: [gmp_info.c:1863] (pid 1066=”kt: gmp-split”) new group: : { 1:0-11, 6-8, 13-14:0-11, 16:0,2-12, 17- 18:0-11, 19-21, down: 2, 9, 15, diskless: 6-8, 19-21 }

Twenty-two seconds later, another node goes offline:

2018-06-15-T06:45:20-04:00 <0.4> tme-14(id20) /boot/kernel.amd64/kernel: [gmp_info.c:1863] (pid 1066=”kt: gmp-split”) new group: : { 1:0-11, 6-8, 14:0-11, 16:0,2-12, 17-18:0- 11, 19-21, down: 2, 9, 13, 15, diskless: 6-8, 19-21 }

At this point, four nodes (2,6,7, & 9) are marked as being offline.

Almost two minutes later, the previously down node (node 6) rejoins the group:

2018-06-15-T06:47:09-04:00 <0.4> tme-14(id20) /boot/kernel.amd64/kernel: [gmp_info.c:1863] (pid 1066=”kt: gmp-merge”) new group: : { 1:0-11, 6-8, 9,14:0-11, 16:0,2-12, 17- 18:0-11, 19-21, down: 2, 13, 15, diskless: 6-8, 19-21 }

However, twenty-five seconds after node 6 comes back, node 1 leaves the group:

2018-06-15-T06:47:27-04:00 <0.4> tme-14(id20) /boot/kernel.amd64/kernel: [gmp_info.c:1863] (pid 1066=”kt: gmp-split”) new group: : { 6-8, 9,14:0-11, 16:0,2-12, 17-18:0-11, 19-21, down: 1-2, 13, 15, diskless: 6-8, 19-21 }

Finally, the group returns to its original composition:

2018-06-15-T07:05:23-04:00 <0.4> tme-14(id20) /boot/kernel.amd64/kernel: [gmp_info.c:1863] (pid 1066=”kt: gmp-merge”) new group: : { 1-2:0-11, 6-8, 9,13-15:0-11, 16:0,2-12, 17-18:0-11, 19-21, diskless: 6-8, 19-21 }

As such, a timeline of this cluster event could read:

1. June 15 06:44:38 6 down
2. June 15 06:44:58 2, 9 down (6 still down)
3. June 15 06:45:20 7 down (2, 6, 9 still down)
4. June 15 06:47:09 6 up (2, 7, 9 still down)
5. June 15 06:47:27 1 down (2, 7, 9 still down)
6. June 15 06:48:11 12 down (1, 2, 7, 9 still down)
7. June 15 06:50:55 7 up (1, 2, 9, 12 still down)
8. June 15 06:51:26 2 up (1, 9, 12 still down)
9. June 15 06:51:53 9 up (1, 12 still down)
10. June 15 06:54:06 1 up (12 still down)
11. June 15 06:56:10 12 up (none down)
12. June 15 06:59:54 10 down
13. June 15 07:05:23 10 up (none down)

The next step would be to review the logs from the other nodes in the cluster for this time period and construct similar timeline. Once done, these can be distilled into one comprehensive, cluster-wide timeline.

Note: Before triangulating log events across a cluster, it’s important to ensure that the constituent nodes’ clocks are all synchronized. To check this, run theisi_for_array –q datecommand on all nodes and confirm that they match. If not, apply the time offset for a particular node to the timestamps of its logfiles.

Here’s another example of how to interpret a series of group events in a cluster. Consider the following group info excerpt from the logs on node 1 of the cluster:

2018-06-15-T18:01:17 -04:00 <0.4> tme-1(id1) /boot/kernel.amd64/kernel: [gmp_info.c:1863] (pid 5681=”kt: gmp-config”) new group: <1,270>: { 1:0-11, down: 2, 6-11, diskless: 6-8 }

2018-06-15-T18:02:05-04:00 <0.4> tme-1(id1) /boot/kernel.amd64/kernel: [gmp_info.c:1863] (pid 5681=”kt: gmp-config”) new group: <1,271>: { 1-2:0-11, 6-8, 9-11:0-11, soft_failed: 11, diskless: 6-8 }

2018-06-15-T18:08:56-04:00 <0.4> tme–1(id1) /boot/kernel.amd64/kernel: [gmp_info.c:1863] (pid 10899=”kt: gmp-split”) new group: <1,272>: { 1-2:0-11, 6-8, 9-10:0-11, down: 11, soft_failed: 11, diskless: 6-8 }

2018-06-15-T18:08:56-04:00 <0.4> tme-1(id1) /boot/kernel.amd64/kernel: [gmp_info.c:1863] (pid 10899=”kt: gmp-config”) new group: <1,273>: { 1-2:0-11, 6-8, 9-10:0-11, diskless: 6-8}

2018-06-15-T18:09:49-04:00 <0.4> tme-1(id1) /boot/kernel.amd64/kernel: [gmp_info.c:1863] (pid 10998=”kt: gmp-config”) new group: <1,274>: { 1-2:0-11, 6-8, 9-10:0-11, soft_failed: 10, diskless: 6-8 }

2018-06-15-T18:15:34-04:00 <0.4> tme-1(id1) /boot/kernel.amd64/kernel: [gmp_info.c:1863] (pid 12863=”kt: gmp-split”) new group: <1,275>: { 1-2:0-11, 6-8, 9:0-11, down: 10, soft_failed: 10, diskless: 6-8 }

2018-06-15-T18:15:34 -04:00 <0.4> tme-1(id1) /boot/kernel.amd64/kernel: [gmp_info.c:1863] (pid 12863=”kt: gmp-config”) new group: <1,276>: { 1-2:0-11, 6-8, 9:0-11, diskless: 6-8 }

The timeline of events here can be interpreted as such:

1. In the first line, node 1 has just rebooted: node 1 is up, and all other nodes that are part of the cluster are down. (Nodes with Array IDs 3 through 5 were removed from the cluster prior to this sequence of events.)
2. The second line indicates that all the nodes have returned to the group, except for Array ID 11, which has been smartfailed.
3. In the third line, Array ID 11 is both smartfailed but also offline.
4. Moments later in the fourth line, Array ID 11 has been removed from the cluster entirely.
5. Less than a minute later, the node with array ID 10 is smartfailed, and the same sequence of events occur.
6. After the smartfail finishes, the cluster group shows node 10 as down, then removed entirely.

Because group changes document the cluster’s actual configuration from OneFS’ perspective, they’re a vital tool in understanding which devices the cluster considers available, and which devices the cluster considers as having failed, at a point in time. This information, when combined with other data from cluster logs, can provide a succinct but detailed cluster history, simplifying both debugging and failure analysis.

Detect, investigate, and respond to advanced threats. Confirm and manage identities. Ultimately, prevent IP theft, fraud, and cybercrime.

Explore products and solutions from RSA.

Visit RSA.com

	As a member of the LGBTQ community and a proud 19-year tenure at Dell, I am excited to take a few moments to reflect on what this year’s Dell Pride month theme, “Pride Beyond Borders,” means. Personally, I have had the honor of being on the leadership team of Dell Pride Employee Resource Group (ERGs) for the last six years and being a Global Lead for the ERG for last four years. Over that time, I have seen the growth of the Pride ERG chapters globally across Europe, Latin America, and most recently into our Asia Pacific region with the … READ MORE
ENCLOSURE:https://blog.dell.com/uploads/2018/06/Austin-Pride-March-cropped-600×356.jpg
Update your feed preferences