Dell EMC PowerScale (EMC Isilon)

NAS Storage

Capacity and Performance details of the array

Alert and Operations details

UI could have been made better

No information related to IP addresses

Performance data mismatch

The installation of the cluster is very quick and simple.

The cluster provides very high performance and throughput.

Isilon is very scalable and works on scale-out architecture. So when we add a new node, it not only increases the capacity but, also increases the performance linearly as well.

Management of the array is very easy.

GUI is very user-friendly and so does the CLI which is very smart.

In my experience, I have seen a lot of bugs in the oneFS and for remedying it, we need to install patches which requires a node reboot.

In old isilon OneFS versions, the nodes need to be rebooted every 250 days which is quite less compared to other storage devices.

The operational cost of Isilon is a bit on the higher side.

Snapshots of folders/files which integrate with Microsoft VSS (previous versions). This allows for quick recovery of lost or deleted files.

Replication of data to a secondary location. We do not need to try to backup such a large environment since we are replicating off site.

Integration with with our Identity management. We can allow users to access files using Active Directory authentication and SMB or NFS protocols.

Job engine. The larger the cluster becomes, the longer some of the jobs can run (AutoBalance, DeDupe). Some jobs can not run at the same time, meaning you have to wait for 1 to finish.

Support - Support has been less than spectacular over the last 2 years or so.

Meta Data analysis. You need to use third party tools to catalog and search meta data.

Isilon NAS scales up well and node replacement is easy. You can replace a node by simply adding a new node and evacuating the node that you want to retire.

If the file system layout is designed and executed properly it is an excellent SMB platform with the flexibility to adjust to different share structures. Make sure to take the time to fully understand the AD integration and best practices for share and NTFS permissions management.

Node redundancy allows for most upgrades to be installed and applied with rolling node reboots allowing the file systems to stay available throughout the process of applying updates.

Native replication is excellent. Jobs complete quickly and we rarely have any replication issues with our Isilon to Isilon replication.

Some upgrades require the entire cluster to be rebooted simultaneously. In this day and age, that should not be necessary. This is my biggest disappointment with Isilon to date.

When using multiple storage pools you have to be very careful with your capacity management. Filling up one pool can cause an overflow of data to a pool that is less performance driven. Do not underestimate your capacities or you will find yourself in a tight spot.

Block size is almost always an issue with Isilon. It does not handle all types of data well. In many cases PACS and VNA data is best to be stored on a different storage platform that will utilize the capacity more efficiently that Isilon is capable of.

Deduplication seems to be less efficient on Isilon than on other platforms for similar types of data.

Auto data balancing between nodes while still maintaining great performance

Directory snapshots

Universal namespace

Network load balancing across nodes

OneFS block size is somewhere around 128kb stripe unit while most of our tif image files are around 50kb so our logical vs. physical storage is far apart. This caused extra capacity to be needed. I'd like to see the minimum block size to be smaller or initially adjustable depending on user data type.

This may just be a training issue, but it's confusing looking at "free" space available when I have a file share mapped to Windows vs. what OneFS states for available free space as they do not match.

We noticed that after adding a new node to an existing cluster in production that we had to adjust the networking config in OneFS to allow for another dhcp address so the new node could get an IP address. Normally this wouldn't matter, but it did have a nasty side effect where the SMB service failed after changing the network config which caused a system wide outage since we mostly use SMB protocol. Once the SMB service was restarted via ssh, we were back in business and it was working again.