50Micron.com

Ok – certain people do certain things well.

I’m a storage administrator/architect.  If you present me a problem I will *ALWAYS* look at it from a storage standpoint.  If you present me with a non-storage problem, I’ll try and make it fit.

I’ve identified four types of systems engineer-type-people:

Storage people

Server people

Network people

Desktop people

I think that just about anyone in IT either fits into one of those four roles or supports one of those roles.

Now when you are looking to solve a problem, the solution you get depends on who you go to.  If you ask a desktop person to solve a network problem for instance, they will probably come up with something under the desk.  (IE throwing a linksys router under a desk.)

If you try and throw a server person a storage role, you’re going to get a server solution to that role.

Enter IBM GPFS.

GPFS is a server solution to a storage problem.  It’s obvious that the person who came up with the idea of solving a storage problem by loading software on a server is not a storage person.

POSIT:  Mutliple hosts in a web-farm need access to data.  Filesystems need to be R/W to an ingest server and R/O to the web-content servers.

Storage Solution:  NAS/NFS – Trunked connection to a real backbone and multiple Apache webserver front-ends running at 1G to play out data.  (Fastest data transfer is going to be the 45MB/Sec backbone coming into the building, so a single Gigabit connection can handle it.   F5 Round-robin load-balancer to distribute the front-end load.  (might also be proposed by Savvy network people, who tend to understand NAS)

Server Solution:  IBM GPFS solution.  Over a million dollars in net-new server hardware + software licensing (not including storage).   Each host accessing storage requires HBA’s, Drivers, fast RELIABLE network. and a level of complexity unheard of even in government.

From what I can tell, and maybe someone can give me a little more insight, works very much like Sun’s Shared QFS.  A metadata server acts as a gatekeeper telling which member servers can access which blocks on which disks.  There is still no simultaneous disk access because a SCSI lock is a SCSI lock.

Now from a storage standpoint, this is rife with problems.

First off, it would seem that if network access was compromised during a write data integrity could easily be compromised.

Secondly, Other than block-level mirroring of the underlying disks, I can’t see a good way to replicate this.  And block-level mirroring of the underlying disks would require an identical infrastructure at the remote/DR site wouldn’t it?  That is of course assuming that the metadata can be mirrored.

Now in database uses or other types of distributed computing I can see it being VERY valuable.  But for flat file storage and web retrieval I can’t think of a single good reason to use something so obnoxiously complicated.  Especially when EMC Celerra, NetApp, or just about any of the other higher-end NAS appliances would cost *SO MUCH* less and be *SO MUCH* more reliable.

/EndOfRant

I went to a NetApp demo today, and they were trying desparately to show me where they competed with the Centerra.

First off, i think the demo went in the wrong direction.  I am not the “average” customer, I wouldn’t have been there if I wasn’t interested, so it should have been very much less ‘sales-pitch’ and more nuts and bolts, ‘geeky details’.

My first question, and one that they were not able to answer was about the compliance clock.

First off, the coolest part of the netapp is that the structure of the fileserver itself is stored within the metadata on the disks, as well as in the processor.  This means that (in theory, because I’ve never seen it happen) you can pull the disks out of one filer, put them in a new one, power it up, and have everything exactly as it was when you shut down the original.

Now this is a good thing, except that I understand the compliance clock exists and has to be initialized within the processor.  Now once it’s set it is locked.  The gentleman who ran the demo even admitted he doesn’t know of a way to “clear” it, though I’m sure it can be done through a fairly routine clearing of the NV ram in the storage processor.

So if you’ve got data on a raid group that can’t be deleted, you shut the array down, move the disks to a new array, and boot it.  You then go and initialize and set the compliance clock in the new unit to 30 years ahead and poof, you can now delete data from the disks.

Yes – it’s an unrealistic scenario, but I have always pictured my job in situations like this to be to find the hole in the ruleset and drive a truck through it.

if you can move the disks to a new array and tinker with the clock there, then it’s not a true compliance product.

Can anyone tell me if I’m off base?  Is the compliance clock dependant on the disks as well as the array?

My second problem is the idea of “block-level” remote replication.  The one thing I liked about the centerra is that it’s policy-based replciation is object based, meaning that when a file is replicated it’s pushed to the remote array.  This, among other things, protects the integrity of the remote filesystem. (not that Centerra has a filesystem per-se)  Block level writes, when interupted, can cause filesystem-wide corruption and other general weirdness.

On another (minor) point, the fact that replication is accomplished by reading the data just written to the disk, would double the IO load on the devices.  (Why do it that way, when it could be simply written directly from cache to two locations…but that’s just crazy talk, right?)

 

Interestingly enough, my favourite Veritas sales guy from Strategic Technologies (www.stratech.com) actually managed to do the virtually impossible.

He got me to thinking and questioning my blind believe in “what EMC says.”

I’m looking at a different options for WORM archiving right now.  Of course the first player in the game is the G5 Centerra.  It’s reportedly bulletproof, and when the auditors come through testing your compliance, their sales shtick is that “they just look at the centerra and wave it through”.  (Much like the san diego border patrol, right?)

So what got me thinking about the NetApp “Archive and Compliance Solution” is that it offers everything Centerra does, without locking you into the API that Centerra does.

One of the biggest problems with the Centerra is that you are locked into their technology.  Once you start archiving to centerra, it’s a nightmare to get off it should you decide to years down the line.  This is because there is no “filesystem” per-se to migrate off of.  Everything going to the centerra has to go through their API.

The Network Appliance product however offers a CIFS/NFS solution, so saving files to the archive can be as simple as copying files to a directory.  (I don’t know the details of how revisions are kept yet, I got about 100 pages of documentation that I was planning on going through this weekend, before the yard-work hit me. )

This means that not only can you browse the filesystem and copy anything out of it you want to, but that you can also migrate out of it with a minimal of fuss if you need to.

The CIFS/NFS solution also makes it more compatible than the Centerra.  Since the Centerra CAS system requires the Centerra API, a limited number of applications work with it.  Now as of this writing the Centerra meets my needs, however who knows what the higher-ups are going to decide to bring in.  And if they bring in a new application that A- requires archiving of data, and B- doesn’t support the Centerra, then we’re screwed and have to go out and get something new anyway.

Now the other bonus is that it’s my understanding that the price point of 4TB (Usable – Replicated) of NetApp storage is much more pleasant than 4TB (Usable – Replicated) of Centerra storage.

Now I know that most of my readership are Hitachi/NetApp people, so i know the way the responses to this are going to go.  My question is actually this:

Does anyone (other than my EMC sales team) see a compelling reason to stick to the Centerra?