When is it safe to position NL nodes for workflow?

Most likely in Archive data workflows.

Then how many percent of your data will you be allowed to access per day?

1%

5%

15%

50%

100%

Probably we can agree that it is NOT an archive when

ALL of the data is accessed each day, but without

a more quantitative statement the term "archive" is pretty useless...

-- Peter

PS: I am seeing NL nodes serving 10% of their theoritical

storage capacity serving per day, or 10TB out of 100TB,

and that NOT being a archive, and working well:

One doesn't need to be afraid of a sustained or average

~110 MB/s (1 Gb/s) throughput with mostly sequential

reads or writes for NL nodes.

With mostly random IO or hundreds of millions of

files, an NL cluster can be easily killed, but so

can an X series cluster without SSD for metadata.

I'm open for a discussion -- what is an archive, performance-wise?

-- Peter

Typically archive workloads consist of infrequently accessed files.  The performance that is required of the archive depends on the application, but in most cases slower than normal response times/latencies are acceptable.  Considering the nature of how many archive solutions grow, the linear scalability of an Isilon cluster provides great benefit.   NL nodes are also good for backup workflows.  These are very sequential in nature and throughput oriented without the need for low latency or the capability for ultra-fast treewalks.  This is ideal for NL Nodes.

With Isilon's modular design, a quantitative recommendation may be difficult to come by as the size of the cluster (in density and file count) and specific workflow behaviors will impact system performance.

From a non-technical perspective, this question can sometimes be answered by how the NL400 product was introduced and positioned. If the conversation starts with positioning NL400 as the "low cost" Isilon solution, this tends to drive to a non-technical solution and probably an incorrect configuration. 

Thanks, that's all the qualitative view, and there's nothing to object here.

The funny thing is, nobody shows a quantitative scenario.

I understand it this way that such an example might later serve as a reference

in "the wrong situation"... so probably it will simply never show up here.

-- Peter

For sure that's exactly the point, any example could be mistaken as a recommendation, outside the original context.

The pity is that the nice modular design and mostly linear scaling should make quantitative considerations easier than with other designs.

Anyway, thanks for the discussion!

-- Peter

Here is another qualitative view... Another point I personally take into consideration with NL clusters, especially smaller clusters, is how many of the bells and whistles (licensed features) are going to be used.  With NLnodes having somewhat less CPU cores and memory than their X or S counterparts, as well as no capability for SSD's, this can be a consideration to take in addition to front end workload.  Sometimes the NL's simply don't have the cycles to complete all the things that our features ask of them (Replciation, Snapshots, AV Scans, FSAnalyze, Quotas, etc).

This of course is with the current version of OneFS 7.0, and may even be mitigated in future versions of OneFS.