Ask the Expert: Are you ready to manage deep archiving workloads with Isilon’s HD400 node and OneFS 7.2.0? Find out more about the Data Lake Foundation products

Karthik  and Peter Nealy  can you tell us more why the HD400 node requires OneFS 7.2. What are the features of OneFS 7.2. that support Data Lake Foundation workloads on HD400, such as deep archiving and instant analytics?

OneFS 7.2 is the first release to add support for a couple of items required for the HD400:

1. New protection levels.  Given that each HD400 has more moving mechanical parts than any node we've ever sold before, and that customers are putting even larger volumes of data in 1 single node it was important to create new protection levels that accounted for the MTTDL of these nodes.

2. 6TB drive support. (this may have been backported to a few slightly older families, but I cannot confirm this)

3. L3 Cache in NL/HD nodes using an SSD

4. New Drive layout.  No longer are the disks simply 1-36, because of the top-down insertion they are arranged in a grid, which required changes in the OneFS UI and CLI to accomodate the grid orientation.

~Chris

> In addition to Rob's answer, yes, a HD400-based cluster will spend proportionally more time running Flexprotect due to the increased number of drives and the relatively limited amount of compute in the platform.  But our modeling shows that it will be a manageable amount, maxing out at less than 1/3 the time (on a max-size cluster composed of only HD400 nodes)

I'd like to follow up on this. From my experience with NL400 (36x3TB) nodes MultiScan after FlexProtect and drive replacement takes about an order of magnitude longer than the FlexProtect job. What total MultiScan run times can be expected with HD400 nodes? Is there any general notion of what customers will consider acceptable?

Moreover, MultiScan jobs after cluster extensions have much more rebalancing work to do than after drive replacements, and they usually take substantially longer. Same question -- is there a target range for MultiScan run times after enlarging a HD400 pool?

Curious, and slightly sceptic 

-- Peter

I do performance benchmarking for Isilon.  Strictly from a node comparison point of view, the HD400 is at parity with, or better than, the NL400 in most of my testing.  For instance, the HD's increased spindles aids it in certain sequential I/O tests, and in tests like SpecSFS it can do more raw ops/s/node than the NL.  Given that you have no existing performance issues on the 72NL, I have no concerns with you moving to the HD400 platform.

As with any potential platform/OS move, though, it's good to discuss it with your Isilon SE.  He/she will be able to help you understand the changes in OneFS 7.2 (e.g. new NFS protocol server) which may have an effect on your particular workloads...

--kip

We are current customers with 5 nodes of 72NL and have been really happy with it and never had any performance problems.  Our initial thought was to replace those nodes with 400NL, but we really like the capacity options for the HD400 and wondered if you recommended that as a replacement?  I am sure it depends on our workload and it would be tough to answer, but the HD400 seems like a "deep archive" solution, interested to know if you could see it as a replacement for NL nodes.  Thanks!

OneFS 7.2 is our most recent OneFS release to support our largest capacity file system. OneFS 7.2 introduces new protection models to support HD400. In addition, OneFS 7.2 brings to bare a number of enhancements in Hadoop to support Data Lakes. Ambari support, HDFS 2.2, 2.3 and 2.4 support comes in OneFS 7.2.

Thank you so much for the quick reply.  We talked a bit with our sales team and there was some hemming and hawing, it is nice to hear something with authority.  I did see the notes on uNFS versus kNFS, it is very interesting and we are looking in to how that would change our existing workflow.  We are trying to virtual appliance now to test out that very thing, thank you so much for bringing it up. 

Hi Peter. The performance of all LIN-based jobs, (MultiScan, Collect, AutoBalance, SmartPools, FlexProtect), is determined by multiple variables such as file size distribution, filesystem age, and cache state of the system.  We expect, on average, that these types of jobs will take longer on a cluster with many HD400s, but it is very situational.  We know that job execution time is a customer concern and have made performance improvements in all recent releases, including OneFS 7.2 to ensure it meets the needs of the platforms they run on.

One thing to consider - if you have a 5-node 72NL cluster, the HD400 is not a direct replacement, since one node is nearly the same capacity (raw) as your entire cluster.  OTOH, if you are looking to archive material to the tune of 2 PB or more, then the HD400 could very well be the node of choice.  I would echo the thoughts above to chat with your Isilon SE on what options you have to replace/refresh your 72NL.  Best of luck!

Thanks for the reply Rob.  We are looking to scale past the 2 PB mark, so this certainly looks like the best solution, now if we can afford it is another conversation entirely .  A quick side note, you came out to San Diego for a customer executive dinner event in 2012 and I still reference some of the things you said there.  It was an excellent talk that left an impression on me, so thank you!

Hello,

I work with the backup division, and in the past we use to have lot of problems performing NDMP restores with Isilon. The backup operation runs perfectly, so fast, but when we have to restore using NDMP, the performance is not so good.

In the latest version, with snapshots backups this has been "solved", but, would we still have problems I we continue using common NDMP?

Regards.

Hi Pablo.  I had to get some consultation to answer this, so hopefully I do it justice. There are multiple use cases here that can affect the answer, and dataset plays a key part. Three-way NDMP restores are inherently slow since the data goes over the front end next. Next, if there are small files in the dataset to restore, since our writes on many small files don't perform as well as larger files it will be slower (three-way NDMP worsens this). One of things we did in OneFS 7.1.1 was introduce parallel restores which are multi threaded restores. Earlier to OneFS 7.1.1 we were doing single stream backups. Some performance evaluations have shown about a 2x performance increase with local restores using backup accelerators and the parallel restore feature.

Would it become economic in certain scenarios to push data from Isilon to ECS via the upcoming (and already demoed in 2014) Isilon CloudPools feature?

Thank you

-- Peter

Does 7.2 bring any new reporting options? Especially around smartquotas?