We use EMC storage. Most of our TSM databases and disk pools are on VNX/VNX2.
In general we like them, especially since they came out with the VNX2 - they
finally have enough processor power to drive the array.
We use all fat luns. We have a charge back system for storage and thin
provisioning doesn't fit well with charge back. I don't see that it would
really matter with TSM. I would think you would fatten out any thin luns
fairly quickly as you use your pools. My understanding is that there is a
small performance hit as you do initial writes as it allocates backend storage,
but that's a one time hit. We use all raw volumes for disk pools volumes. If
you use OS level files for disk pool volumes, don't you have to format them
first? That would fatten up any think vols right then! For DB2 files, thin
luns would be good since DB2 allocates files as needed.
All your VNX storage will be in a big VNX pool stripped across all the disks,
so you get lots of spindles/heads working for you.
We do purchase some SSD storage for Fast Cache on each VNX. EMC keeps wanting
us to use VNX FAST VP to migrate hot spots up onto SSD storage, but we've
stayed away from that. I believe the slice/chunk size that FAST VP moves is
256MB. That's a very large hot spot chunk. We've been using FAST CACHE -
just a normal read type cache - that caches in 64k chunks. This seem a much
better use of the SSD.
On some VNX2 systems we use snapshots - mostly for databases. They have a new
snapshot type that performs a redirect-on-write which supposedly much more
efficient than the older type which uses copy-on-write.
What we don't like about the VNX is performance tools. Yes they have them -
even give some away free. But when you start to use them to dig they come up
lacking.
We've had some problems with some AIX and Windows 2008 systems surviving a
microcode upgrade. The upgrade process reboots one SP, then the other.
There's a gap between the reboots, but sometimes some servers don't recover
paths before the second SP reboot. We've been working with support about this,
but they haven't been exactly responsive.
Support - it's all been moved overseas, and can be anything from good to bad.
It can be very frustrating.
Rick
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Vandeventer, Harold [OITS]
Sent: Thursday, January 08, 2015 3:56 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: SAN hardware hints
I've just learned we'll be migrating our systems to new SAN hardware;
specifically EMC VNX.
A little reading indicates some features such as thin-provisioning vs thick-
provisioning of LUNs will be available.
Anyone out there using EMC VNX for their TSM storage pools and/or database
LUNs? Any hints about thin vs thick regarding TSM performance?
Thanks.
------------------------------------------------------------
Harold Vandeventer
Systems Programmer
State of Kansas - Office of Information Technology Services
STE 751-S
910 SW Jackson
(785) 296-0631
[Confidentiality notice:]
***********************************************************************
This e-mail message, including attachments, if any, is intended for the
person or entity to which it is addressed and may contain confidential
or privileged information. Any unauthorized review, use, or disclosure
is prohibited. If you are not the intended recipient, please contact
the sender and destroy the original message, including all copies,
Thank you.
***********************************************************************
-----------------------------------------
The information contained in this message is intended only for the personal and
confidential use of the recipient(s) named above. If the reader of this message
is not the intended recipient or an agent responsible for delivering it to the
intended recipient, you are hereby notified that you have received this
document in error and that any review, dissemination, distribution, or copying
of this message is strictly prohibited. If you have received this communication
in error, please notify us immediately, and delete the original message.
|
