× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



from: "Crump, Mike" <Mike.Crump@xxxxxxxxxxxxxxxx>
?subject: SAN was RE: system p announcement

">Time. I manage multiple terabytes of data (db2, Domino, etc.) and by my
calculations I use .03 of an FTE to manage anything that is related to
storage (space, backups, performance, etc.) My belief is that a SAN
will require much more care and feeding than .03. I'm not knocking
benefits by any stretch. I just can't afford to do so without reducing
efforts in another area. Yes that is .03, not .3. And that's not
because I'm some wiz (especially since my wife tells me I'm not) I think
that is typical in most System i installations."

True, it is another piece of equipemnt so there will be some
administration. We
have a z9 attached to an old shark (F20), an 810 with about 1 TB of
internal and
an EMC Clarion SAN with hundreds of Windows and a smattering of Novell.
IBM came in an set up the Shark with a bunch of MOD 3 3390's and we haven't
touched it in over
four years. The 810 has had a little work done to it with some ASPs but for
the most part,
it just sits there. The EMC SAN (18 TB) on the other hand is some work,
but that certainly
no to imply we have someone dedicated to storage. Just seems that the
explosion on Windows severs
is more the issue than the SAN technology. If I had hundreds of IXS cards,
I'd still have to spend some
time getting the storage spaces created and attached, grow the volumes
because no one ever deletes anything on
a PC server.


">SAN ownership - SAN's are typically owned by non-System i admin types.
This means that problem determination may span multiple bodies. As well
as ongoing support etc. It adds complexity that didn't exist in the
internal storage world. Not a problem of SAN's but a reality of our
world I think."

I agree and who's SAN you have and the tools they have to help you
determine problems
is a very important feature that is sometimes overlooked. Every one
worries about
scalability because they can 'hide' from troubleshooting if the box can
handle a bunch of IOPS.
I believe most businesses don't come near the high IOPS. Next they look at
how much disk
they can cram into it, looking at the interface to create LUNs and assign
them to host...
all the while forgetting that if they have to troubleshoot something they
might be out of luck.
Our first SAN (HP) would only set you look at current stats.. Hit enter.
That's how the SAN
is performing. Hit enter. That's how it performing now... No trending
whatsoever.



">Visibility - I don't believe the current tools allow a System i
administrator good visibility into the performance characteristics of a
SAN. You have those today with internal disks. If there is a question
of performance issues you again have to span different technologies and
potentially different people."

See above. There are some vendors that have decent tools. We're in the
process of looking at
a new DS6800, EMC DMX or a Hitachi unit. They all have some things to help
with troubleshooting and we're just getting to the point of looking at
those tools.


">Cost to transition - hard for me to explain but as we make some system
changes I sometimes have to carry over older drives in order to keep
costs flat. Every time I've looked at a potential SAN solution it tends
to put me in a cost increase situation. It's a blip and over time you
should be able to decrease costs but it's a hurdle none-the-less."

Cost. We all know the System i disk prices. After the upfront cost of the
cabinet and controllers (we still have to buy expansion cabinets, raid
controllers and such for the System i), the cost of the disk is
substantially cheaper. Plus, if you have more than an System i in the shop
you have the flexability to slide that resource around. There are some
restrictions on most SANs sliding a disk unit from Mainframe to OpenSystems
and System i but it can be done if needed.


">My stick in the mud pricing attitude - SAN storage is almost a must in
other environments and I think other systems gain much more from a
functionality and cost standpoint. Therefore I always think I should
have to pay less for any SAN storage that is attached to a System i."

I'd say fairly accurate, but for heavy System i shops. When you start to
get a bunch of Window servers (we have about 200 to 225 Windows server),
then that arguement (IMO) isn't that strong.


Replication. I know there are software vendors out there that have cool
products, but from a DR prospective a SAN has alot to offer. You replicate
at the controller level and set sync point for all you platforms. If you
declare, you bring up your hosts at the remote site (and those would be
"Capacity Backup models" - read cheaper to have at remote site because
their not allow to be powered up except for testing and DR) and all
applications across multiple platforms are at a consistency point or sync
point. To me, that really big.



Michael Smith
Technical Support and Data Center Manager
Farm Family Insurance cos.


-----------------------------------------

Confidentiality / Privilege Notice: This transmission, including
attachments, is intended solely for the use of the designated
recipients(s). This transmission may contain information that is
confidential and/or privileged or otherwise protected from
disclosure. The use or disclosure of the information contained in
this transmission for any purpose other than that intended by its
transmittal is strictly prohibited. If you are not an intended
recipient of this transmission, please immediately destroy all
copies received and notify the sender.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.