Then how many percent of your data will you be allowed to access per day?
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...
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.
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.
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.
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.
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!