Ask The Expert – Isilon’s New Releases: IsilonSD Edge, OneFS.NEXT and CloudPools

This Ask the Expert session is now open for questions. For the next couple of weeks our Subject Matter Expert will be around to reply to your questions, comments or inquiries about our topic.

Let’s make this conversation useful, respectful and entertaining for all. Enjoy!

Hello,

what's new in OneFS.NEXT in terms of upgrades/roll-back functionality ? 

Thanks

To expand on dynamox's question, can you give more details on release rollback and level of disruption when performing one?

Have the IsilonSD the same features (smartpols,InsightIQ,etc) of the hardware version?

Why is there a 36TB limit on IsilonSD? Will that be increased in the future? It really limits the utility of the system. I'm much more interested in using it to essentially build non-standard nodes (more cpu, ram, faster ethernet) that would not be particularly commercially viable for EMC, but that size makes it a non-starter.

As far as the level of disruption in the upgrades, will OneFS.Next finally stomp the clusterwide hangs caused by group change issues? 7.2.1 is better, but still not good enough...

To expand on these question even further, what happens to config changes done after an upgrade when that upgrade gets rolled back? Revert to config settings from before the upgrade, or back-migrate the changes? Think of creating new shares, modifying quotas or network settings.

Thank you

-- Peter

What else will be new beyond edge, cloud and roll-back? Interested in performance of NAS and job engine, SSD usage modes, and monitoring/reporting.

Thank you

-- Peter

To follow on to Peter's question, will there be changes to how L3 is structured/allocated? I've put in requests before to be able to designate some SSDs in a node pool for L3 and others for GNA, if one has, say, 6 SSDs/node in some pools and other pools with no SSDs.

--Ken

Could we use CloudPool as a disaster recovery solution?

Hello go.y,

CloudPools is intended to be an archive solution where customers can archive their cold, infrequently used data to one of the supported cloudpools targets. It is not going to be a second copy of data in the cloud. The data stored in the cloud will be pointed to by smartlinks (stubs) on the OneFS cluster. You can copy/syncIQ these smartlinks (stubs) to another Isilon Cluster that can be used for Failover purposes in case your primary Isilon cluster becomes unavailable.

Thanks

kt

Hello Sleutze,

The data from Edge to Core or from Core to Edge has to be transferred using SyncIQ policies. You need to setup the SyncIQ policies.

Thanks

kt

Hi,

will OneFS.NEXT be capable of a real "oneclick-Failover" in which quotas and shares are replicated without EMC Arbitrator or Superna Eyeglass?

-- sluetze

Hi,

How is data Transfer from the Edge to the core (and back) implemented? Do i have to schedule SyncIQs or ist this a continious process? Does all "at the edge" requested data get there fully automated? Or are there manual steps to do?

-- sluetze

mn3umonic wrote: Hi Carlilek, Please say more. Are you looking at datacenter scale deployment and with which non-standard typed of HW are you interested? 36TB managed capacity are intended primarily for  Edge location deployments.

Yes, I'd be looking at datacenter scale deployment.

I currently run a 5PB 70 node cluster (which is extraordinarily heterogenous) with a 3PB 10 node HD cluster for backups in another datacenter. That cluster serves SMB and NFSv3, authenticated against LDAP and AD, to all of the desktops, laptops, and servers in the building (> 500 end users, probably around 1500-2000 clients altogether) as well as providing the primary NFS storage for our HPC compute cluster (5000 cores). We automount Linux home directories stored in this Isilon cluster.

Historically and currently, Isilon uses insufficient CPUs for larger scale deployments. When so much relies on CPU in a cluster, that will become the bottleneck pretty quickly. We have to run most of our storage jobs (e.g. Multiscan, Smartpools, etc.) after hours because they will contend for CPU with clients. We also run the risk of exhausting the NFS RPC threads available per node due to insufficient CPU, which can cause HPC cluster jobs to fail.

Isilon appliances are also inflexible in terms of memory allocation. We would like to be able to have significantly more than 256GB of RAM in nodes in order to have more caching (typical cached data age for us is ~1hr.)

More options in terms of drive layout is also highly appealing. Being able to have fully enabled L3 (or GNA) from SSDs in NL class nodes (ie 6TB drives + 1 or 2 SSD) would simplify our configurations.

The networking is also a big issue. Isilon has been stuck at 10GbE for a long time. In order to serve our HPC cluster better (which is all 10GbE clients at a 4:1 oversubscription to ToR), I would like to see much faster networking options available in the Isilon, particularly 50GbE and 100GbE. This has recently become more practical since the OneFS has improved to the point where the nodes can actually saturate the 10GbE links they have (a very recent development).

Back end networking improvements over the currently rather dated QDR IB would also help. With an SDS solution like this, we wouldn't be stuck with ancient back end networking for older nodes, because we could just replace the hardware in the nodes.

This is really the promise of the whole thing, not being stuck with older hardware because of the need to replace entire pools at once. If we were to discover that a pool of nodes had insufficient RAM, we could just add it rather than calling EMC and spending ludicrous amounts of money and time to get it changed (yes, we've done this, and it is completely ludicrous). If we decide that our (relatively) cheap 'n' deep nodes really do need an SSD or two, we could add it, again without the absolutely absurd cost that Isilon charges for upgrading a node and without the need to remove an HDD to make this work.

Ultimately, we'd rather see a SDS option that didn't require VMware so that we can build some of these wildly performing nodes ourselves without the hypervisor overhead, but I can understand why Isilon is starting there.

--Ken