Hi Zoltan,
Many reasons for it, which I'll try to shortly summarize :
1) Isilon makes use of NFS, whose performance is not that good on AIX systems.
We are an AIX shop, and are forced to move to Power Linux machines to get
sufficient performance to cover our backup needs.
Our first experience with Power Linux machines revealed serious lacks in the
functionalities we are accustomed to : no easy HMC setup, thus lack of call
home capabilities so far. In addition to this we needed to setup a RedHat
satellite server to allow for installation on remote servers, and so far are
unable to boot our machines from it ... This will probably work sooner or
later, but requires lots of involvement and time from our sys-admins.
2) Isilon is not perfectly fitting in a big TSM environment. In order to get
decent performance, a third party tool will be needed, whose name is dsmISI.
See following :
http://stefanradtke.blogspot.ch/2015/06/how-to-optimize-tsm-operations-with.html
This means another layer of complexity in the setup, and another vendor to
talk to, if facing performance issues. I had more than my lot of "ping-pong"
games during my career as TSM administrator, between IBM and other vendors, to
reject the responsibility on each other in case of issues. Having 3 parties
involved in our setup will make such games even more frequent ...
3) User base for such a combination in Switzerland is inexistent, at least in
the same order of size than ours. EMC has not been able to provide any customer
reference in this country, with whom we could talk to about their setup. There
must be a good reason for it ...
4) Compatibility issues : this was more kind of a guts feeling I had, but as
usually, it revealed to be true : see the problems I will now be facing with
Little/Big endian versions of TSM/Spectrum Protect (without to mention that
Spectrum Protect 8.1 is not even available for Power Linux so far). I'm
currently facing another one : the Isilon we got is running OneFS 8, and
there's so far no official statement that it is supported, whether by TSM or by
dsmISI. A downgrade to OneFS 7.x revealed to be impossible, due to the fact
that the 8 TB disks installed in the machine are not supporting it ...
5) Support by EMC : revealed to be less efficient than the one offered by IBM.
Since EMC merged with Dell, it became even worse (for a non-native English
speaking person, having a call with support based in India is a nightmare).
Also our storage administrator informed me that from his experience, upgrade
procedures on EMC devices where much more complicated than the ones for IBM
hardware, and almost always required intervention of the vendor to be conducted
properly (lots of dependencies in microcodes, switch versions and so on ...)
6) Costs ...
Of course, your mileage may vary, but in our case I'm pretty sure that
management made the wrong choice (I would have gone IBM Spectrum Scale in
conjunction with an AIX based server : one vendor, blueprints provided, and
guaranteed performance).
Cheers.
Arnaud
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Zoltan Forray
Sent: Monday, February 13, 2017 4:38 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Availability for Spectrum Protect 8.1 server software for Linux on
power system
Arnaud,
On Fri, Feb 10, 2017 at 9:21 AM, PAC Brion Arnaud <
Arnaud.Brion AT panalpina DOT com> wrote:
> because our management (despite my warnings not to do so) decided that the
> target storage for backups would be an EMC Isilon, that connects to the TSM
> server using NFS mounts.
A little off topic for this thread but why do you feel it is a "bad idea"
to use EMC Isilon for TSM target storage for backups? We are leaning in
this direction and in fact have such a configuration for our offsite
replication target server. We are aggressively moving away from expensive
VNX storage to Isilon. So I am curious why you feel the way you do?
--
*Zoltan Forray*
Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator
Xymon Monitor Administrator
VMware Administrator (in training)
Virginia Commonwealth University
UCC/Office of Technology Services
www.ucc.vcu.edu
zforray AT vcu DOT edu - 804-828-4807
Don't be a phishing victim - VCU and other reputable organizations will
never use email to request that you reply with your password, social
security number or confidential personal information. For more details
visit http://infosecurity.vcu.edu/phishing.html
|