Re: NetAps vs EMC

["Mr. Alcourt" <alcourt@execpc.com>]

-----BEGIN PGP SIGNED MESSAGE-----

On Wed, 31 Jan 2001, Brad Knowles wrote:

> At 8:56 AM -0600 2001/1/31, Mr. Alcourt wrote:
>
> >  My problem with EMC is that I don't have _any_ management interface that
> >  EMC is willing to tell me about.  Because of the model of local disk and
> >  the fact that we were forced to run at Solaris 2.6, we were forced to
> >  reboot after editing the /kernel/drv/sd.conf file just to allow the system
> >  access to access a bit more drive space that already existed inside the
> >  EMC array.
>
> 	Surely this is a filesystem or volume manager issue, and not a
> problem with EMC.  Are you using Veritas VxVM and/or VxFS?  I know
> that VxVM gives you tools to grow volumes online, and I know that
> VxFS gives you tools to grow and shrink filesystems online.
> Therefore, so long as the volume can be grown in a manner that VxFS
> understands, you don't even necessarily have to be running VxVM.

That's what the problem was.  Before Veritas VxVM could see the disks, we
had to get a "bin file" update to reconfigure the storage array to make
more disks visible to the system, and it also required a microcode update.
We were informed it is a five day process to create a new bin file.
Because Solaris limits us to 120 luns per controller (target?), we had to
also modify the sd.conf file to tell the system that new controllers and
targets were visible along the fiber strands to the EMC array.

Now that we have made those disks visible, if we were to decide in the
future to ask for another third of the available disk (we only have about
one third visible right now) for use, that would require another bin file
and downtime on the EMC array.

Another issue I have with them is they seem to not understand inherent
security risks in some of their proposed solutions.  They couldn't
understand why I didn't want a chassis to chassis mirror (SRDF) to go over
the public internet.  "It's virtually encrypted".  (Never mind why it
would have hit the public internet in the first place, that's a disaster
that still makes me shudder.)  Something about having every single bit of
data hitting the public network makes me nervous.

> >  I admit, there is a good chance that my problems are due to the
> >  individuals at EMC that I am dealing with.  But I get nervous when I'm
> >  told to pretend it's just a very big disk array with no management control
> >  needed, until we decide to take advantage of a little more hard drive
> >  space and are told we need a new bin file and new microcode and only EMC
> >  can provide such.  (Yet the hard drives were already installed in the
> >  array, we just weren't using them yet.)
>
> 	If that's what EMC is telling you, then I absolutely agree --
> they are not doing their job, and they should be required to pull the
> equipment out of the computer room with their "undercarriages" (see
> <http://www.ananova.com/news/story/sm_165238.html>).

After looking at that URL, I have to shudder.  Somehow it seems an
appropriate punishment however for the design features that I am finding
out about the hard way.

Because of my very recent experience with EMC in a recent project, I
cannot reccomend EMC, especially on a Solaris 2.6 platform.  While EMC in
theory "phones home" when it has a problem, we didn't discover we had a
problem until a EMC support tech came on site to do some of the work in
preparation for our bin file upgrade, which resulted in delays and
scheduling additional downtime for the system.

- -- 
Mr. Alcourt                           http://www.execpc.com/~alcourt/
"I may disagree with what you say, but I will defend unto the death
your right to say it."  -- Voltaire

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: Made with pgp4pine 1.75-6

iQCVAwUBOni7ItHXH7Z+KmdxAQGPdAQAkzYULwhG/wkL3LWIMxGcHS4quZRjpAfq
UwUZ8IRYZSb2JY2jPulvSHNyTtu+xiEBD0JTxn/qvAsqvQB4g+8FvLqLiVAaKEYE
P/Z/vkTr8Mvm2odwQw+bcsm541GhhIQfUW3vXihKHAXVIN4pBmxXrEJRJG09vRWO
CnIKSCD2jlw=
=3NJF
-----END PGP SIGNATURE-----