">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.
What we really need is for the SAN performance to be easily integrated
into the system. I know that might be difficult for non-IBM vendors but
minimally I think that PT/400 needs to be able to integrate the SAN
performance information. Not sure that it's easy but it would make life
so much easier. I don't need another black hole when it comes to
performance issues. I get enough of that from the network people. In
some ways it's not a technology problem - it can be people related - but
it would be great to attempt to eliminate islands of information -
integrate it somehow.
Disaster recovery - I agree. I've not looked into this in great detail
but I think that a good SAN environment would allow for the best DR
solution. I'm not to enthusiastic with the software solution for DR -
it takes to much care and feeding if you ask me.
On the cost side you are correct. We run so tight from a budget
perspective that it is very hard for me to get a project approved if it
increases costs for a current year and either saves or potentially saves
in future years. Effectively, we would have to remove something from
the current year to make the budget stay flat.
I see it as inevitability for us. It's a question of timing for the
most part. If we were driven to absolutely implement an in house
redundant environment I think I'd be able to accomplish it. But I'm not
holding my breath here....we are held accountable but not empowered.
:-)
Michael Crump
Manager, Computing Services
Saint-Gobain Containers, Inc.
1509 S. Macedonia Ave.
Muncie, IN 47302
765.741.7696
765.741.7012 f
Planning
Much work remains to be done before we can announce our total failure to
make any progress.
This email and its attachments may be confidential and are intended
solely for the use of the individual to whom it is addressed. Any views
or opinions expressed are solely those of the author and do not
necessarily represent those of Saint-Gobain. If it did, it would be
folded, mutilated, watered down, politically corrected, and would show
up a week later if at all. If you are not the intended recipient of
this email and its attachments, you must take no action based upon them,
nor must you copy or show them to anyone.
Please contact the sender if you believe you have received this email in
error.
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
Michael_Smith@xxxxxxxxxxxxxx
Sent: Thursday, November 08, 2007 8:43 AM
To: midrange-l@xxxxxxxxxxxx
Subject: SAN was RE: system p announcement (Crump, Mike)
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.
midrange.com
