VNX vs. V7000

Like my previous post about the XIV, I did a little bit of research on how the IBM V7000 compares as an alternative to EMC’s VNX series (which I use now).  It’s only a 240 disk array but allows for 4 nodes in a cluster, so it comes close to matching the VNX 7500’s 1000 disk capability.  It’s an impressive array overall but does have a few shortcomings.  Here’s a brief overview list of some interesting facts I’ve read about, along with some of my opinions based on what I’ve read.  It’s by no means a comprehensive list. 

Good:

·         Additional Processing power.  Block IO can be spread out among 8 Storage Processors in a four node cluster.  You need to buy four frames to get 8 SP’s and up to 960 disks.  Storage Pools can span clustered nodes.

·         NAS Archiving Support. NAS has a built in archiving option to easily move files to a different array or different disks based on date.  EMC does not have this feature built in to DART.

·         File Agent. There is a management agent for both block and file.  EMC does not have a NAS/file host agent, you have to open a session and log in to the Linux based OS with DART.

·         SDD multipathing agent is free.  IBM’s SDD multi-pathing agent (comparable to PowerPath) is free of charge.  EMC’s is not.

·         Nice Management GUI.  The GUI is extremely impressive and easy to use.

·         Granularity.  The EasyTier data chunk size is configurable;  EMC’s FAST VP is stuck at 1GB.

·         Virtualization.  The V7000 can virtualize other vendor’s storage, making it appear to be disks on the actual V7000.  Migrations from other arrays would be simple.

·         Real time Compression.  Real time compression that, according to IBM, actually increases performance when enabled.  EMC utilizes post process compression. 

Bad: 

·         No Backend Bus between nodes. Clustered nodes have no backend bus and must be zoned together.  Inter-node IO traverses the same fabric as hosts.  I don’t see this configuration as optimal, it is a fact that the IO between clustered nodes must travel across the core fabric.  All nodes plug in to the core switches and are zoned together to facilitate communication between them.  According to IBM this introduces a 0.06ms latency, but in my opinion that latency could increase based on IO contention from hosts.  You may see an improvement in performance and response time due to the extra cache and striping across more disks, but you would see that on the VNX as well by adding additional disks to a pool and increasing the size of Fast Cache, and all the disk IO would remain on the VNX’s faster backend bus.  The fact that the clustered configuration introduces any latency at all is a negative in my mind.  Yes, this is another “FUD” argument.

·         Lots of additional connectivity required.  Each node would use 4 FC ports on the core switches (16 ports on each fabric in a four node cluster).  That’s significantly more port utilization on the core switches than a VNX would use.

·         No 3 Tier support in storage pools.  IBM’s EasyTier supports only two tiers of disk.  For performance reasons I would want to use only SSD and SAS.  Eliminating NL-SAS from the pools would significantly increase the number of SAS drives I’d have to purchase to make up the difference in capacity.  EMC’s FAST VP of course supports 3 tiers in a pool.

·         NAS IO limitation.  On unified systems, NAS file systems can only be serviced by IOgroup0, which means they can only use the two SP’s in the first node of the cluster.  File systems can be spread out among disks on other nodes, however.

 

Advertisements

VNX vs. XIV

I recently started researching and learning more about IBM’s XIV as an alternative to EMC’s VNX.  We already have many VNX’s installed and I’m a very happy EMC customer, but checking out EMC’s competition is always a good thing.  I’m looking at other vendors for comparison as well, but I’m just focusing on the XIV for this post.  On the surface the XIV looks like a very impressive system.  It’s got a fully virtualized grid design that distributes data over all of the disks in the array, which maximizes performance by eliminating hotspots.  It also offers industry leading rebuild times for disk failures.  It’s almost like a drop in storage appliance, you choose the size of the NL-SAS disks you want, choose a capacity, drop it in and go.  There’s no configuration to be done and an array can be up and running in just hours.  They are also very competitive on price.  While it really is an impressive array there are some important things to note when you compare it to a VNX.  Here’s a brief overview list of some interesting facts I’ve read about, along with some of my opinions based on what I’ve read. 

Good:

1.       It’s got more CPU power.  The XIV has more CPU’s and more overall processing power than the VNX.  It’s performance scales very well with capacity, as each grid module adds 1 additional CPU and cache.

2.       Remote Monitoring.  There’s an app for that!  IBM has a very nice monitoring app available for iOS.  I was told, however, that IBM does not provide the iPad to run it. 🙂

3.       Replication/VMWare Integration.  VNX and XIV have similar capabilities with regard to block replication and VMWare integration.

5.       Granularity & Efficiency.  The XIV stores data in 1MB chunks evenly across all disks, so reading and writing is spread evenly on all disks (eliminating hotspots).  The VNX stores data in 1 GB chunks across all disks in a given storage pool.

6.       Cloning and Rebuild Speed.  Cloning and disk rebuilds are lightning fast on the XIV because of the RAID-X implementation.  All of the disks are used to rebuild one.

7.       Easy upgrades.  The XIV has a very fast, non disruptive upgrade process for hardware and software.  The VNX has a non-disruptive upgrade process for FLARE (block), but not so much on DART (file).

Bad:

1.       No Data Integrity Checking.  The XIV is the only array that IBM offers that doesn’t have T10-DIF to protect against Data Corruption and has no persistent CRC written to the drives.  EMC has it across the board.

2.       It’s Block Only.  The XIV is not a unified system so you’d have to use a NAS Gateway if you want to use CIFS or NFS.

3.       It’s tierless storage with no real configuration choices.  The XIV doesn’t tier.  It has a large SSD Cache, similar to the VNX’s FastCache which is supported by up to 180 NL-SAS drives.  You have no choice on disk type, no choice on RAID type, and you must stay with the same drive size that you choose from the beginning for any expansions later on.  It eliminates the ability of storage administrators to manage or separate workloads based on application or business priority, you’d need to buy multiple arrays.  The XIV is not a good choice if you have an application that requires extensive tuning or requires very aggressive/low latency response times.

4.       It’s an entirely NL-SAS array.  In my opinion you’d need a very high cache hit ratio to get the IO numbers that IBM claims on paper.  It feels to me like they’ve come up with a decent method to use NL-SAS disks for something they weren’t designed to do, but I’m not convinced it’s the best thing to do.  There is still a very good use case for having SAS and SSD drives used for persistent storage.

5.       There’s an increased Risk of Data Loss on the XIV vs VNX.  All LUNs are spread across all of the drives in an XIV array so a part of every LUN is on every single drive in the array.  When a drive is lost the remaining drives have to regenerate mirror copies of any data that was on the failed drive.  The probability of a second drive failure during the rebuild of the first is not zero, although very close to zero due to their very fast rebuilt times.  What happens if a second drive fails before the XIV array has completed rebuilding the first failed drive?  You lose ALL of the LUNs on that XIV array.  It’s a “FUD” argument yes, but the possibility is real.  Note:  The first comment on this blog post states that this is not true, you can read the reply below.

6.       Limited Usable Capacity on one array.  In order to get up to the maximum capacity of 243TB on the XIV you’d need to fill it with 180 3TB drives.  Also, once you choose a drive size in the initial config you’re stuck with that size. The maximum raw capacity (using 3TB drives) for the VNX 5700 is 1485TB, the VNX 7500 is 2970TB.

Using the database query option on Celerra & VNX File commands

vnx1

EMC has added a hidden query option on some of the nas commands that allows you to directly query the NAS database. I’ve tested the ‘-query’ option n the nas_fs, nas_server, nas_slice and nas_disk commands, however it may be available on other commands as well. It’s a powerful command with a lot of options, so I took some time to play around with it today. The EMC documentation on this option in their command line reference guide is very sparse and I haven’t done much experimentation with it yet, but I thought I’d share what I’ve found so far.

You can view all of the possible query tags by typing in the commands below. There are dozens of tags available for query. The output list for all the commands is large enough that it’s not practical to add it into this blog post.

nas_fs -query:tags
nas_server -query:tags
nas_slice -query:tags
nas_disk -query:tags
 

Here’s a snippet of the tags available for nas_fs (the first seven):

Supported Query Tags for nas_fs:
Tag           Synopsis
———————————————————–
ACL         The Access Control List of the item
ACLCHKInProgress         Is ACLCHK running on this fs?
ATime         The UTC date of the item’s table last access
AccessPolicyTranslationErrorMessage         The error message of the MPD translation error, if any.
AccessPolicyTranslationPercentComplete         The percentage of translation that has been completed by the Access Policy translation thread for this item.
AccessPolicyTranslationState         The state of the Access Policy translation thread for this item.
AutoExtend         Auto extend True/False
 

The basic syntax for a query looks like this:

nas_fs -query:inuse==y:type=uxfs:IsRoot=False -Fields:Name,Id,StoragePoolName,Size,SizeValues -format:’%s,%s,%s,%d,%d\n’

In the above example, we are running the query based on three options. We want the file system to be in use, be of the type uxfs, and not be root. In the fields parameter, we want the file system’s name, ID, Storage Pool name, size, and size values. Because our output has five fields, and we want each file system to have it’s own line in the output, we add five formatting options separated by commas (for a csv type output), followed by a ‘\n’ to create a carriage return after each file system’s information has been outputted.

Here are the valid query operators:

= pattern match
== exact match
=- not less than
=+ not more than
=* any
=^ not having pattern
=^= not an exact match
=^- is less than
=^+ is greater than
=^* not any (none)

The format option is not well documented. The only parameters I’ve used for the format option are q and s. From what I’ve seen from testing the options, The tag used in the ‘-fields’ parameter is either simple or complex. A complex tag must be formatted with q, a simple tag must be formatted with s. Adding the ‘\n’ to the format option adds a carriage return to the output. If you use the wrong format parameter, it will display an error like this: “Error 2110: Invalid query syntax: the tag (‘[Tag Option]’) corresponding to this format specifier (“%q”) is not a complex tag”.

-format:’%s’ : Simple Formatting
-format:’%q’ : Complex Formatting

Below are some examples of using the query option. I will add more useful examples in the future after I’ve had more time to dive in to it.

To get the file system ID:

nas_fs -query:Name==[file system name] -format:’%s\n’ -fields:VolumeID

List all file systems with their sizes:

nas_fs -query:inuse==y:type=uxfs:IsRoot=False -Fields:Name,Id,StoragePoolName,Size,SizeValues -format:’%s,%s,%s,%d,%d\n’

List all file system quotas on the array:

nas_fs -query:\* -fields:ID,TreeQuotas -format:’%s:\n%q#\n’ -query:\* -fields:FileSystem,Path,BlockHardLimit,BlockSoftLimit,BlockGracePeriod,BlockUsage -format:’%s : %s : %s : %s : %s : %s\n’

List quota info for all file systems:

nas_fs -query:\* -fields:ID,TreeQuotas -format:’%s:\n%q#\n’ -query:\* -fields:FileSystem,Path,BlockHardLimit,BlockSoftLimit,BlockGracePeriod,BlockUsage -format:’%s : %s : %s : %s : %s : %s\n’

List all Checkpoint file systems:

nas_fs -query:inuse=y:type=ckpt:isroot=false -fields:ServersNumeric,Id,Name,SizeValues -format:’%s,%s,%s,%s\n’

List all the Server_params for a specific server_X:

nas_server -query:Name=server_2 -format:’%q’ -fields:ParamTable -query:Name== -fields:ChangeEffective,ConfiguredDefaultValue,ConfiguredValue,Current,CurrentValue,Default,Facility,IsRebootRequired,IsVisible,Name,Type,Description -format:’%s|%s|
%s|%s|%s|%s|%s|%s|%s|%s|%s|%s\n’

List the current Wins/DNSDomain Config:

nas_server -query:Name=server -fields:Name,DefaultWINS,DNSDomain -format:”%s,%s,%s\n”

For a detailed file system deduplication report:

nas_fs -query:inuse=y:isroot=false:type=uxfs -fields:Deduplications -format:’%q’ -query:RdeState=On -fields:Name,FsCapacity,SpaceSaved,SpaceReducedDataSize,DedupeRate,UnreducedDataSize,TimeOfLastScan -format:’%s,%s,%s,%s,%s,%s,%s\\n’