ADSM-L

Re: [ADSM-L] Why do you feel it is a "bad idea" to use EMC Isilon for TSM target storage for backups?

2017-02-16 09:29:08
Subject: Re: [ADSM-L] Why do you feel it is a "bad idea" to use EMC Isilon for TSM target storage for backups?
From: Frank Kraemer <kraemerf AT DE.IBM DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 16 Feb 2017 15:26:55 +0100
Zoran, Arnaud,

I saw your posting on the ADSM-L list:

> 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.

1) dsmISI (a tool for NFS workload balancing for EMC Isilon)

I 100% agree to this. dsmISI has been developed Mr. Lars Henningsen (
mailto:lars.henningsen AT general-storage DOT de) from General Storage. This is 
a
small consulting group (only 3-4 people) based in Germany. The team has a
good Spectrum Scale (TSM) Know-how no doubt and the tool is used in several
customer installations, but it's a waste of money from my point of view :-(

2) How does the tool work and why is it needed?

The tool does an API call to the Isilon admin interface and requests the
number of currently active Isilon nodes. As each Isilon node has 2x 10 GbE
network interfaces it generates on the Spectrum Scale (TSM) server twice as
much NFS client mount points as there are Isilon nodes. (Info: the min
number of Isilon nodes is 3 the maximum is 144.) On a fully loaded Isilon
system your Spectrum Protect (TSM) server will show up to 288 NFS client
mount points. BAD IDEA! The NFS code is always running as AIX/Linux kernel
service.  As each mount point is using Kernel Level resources (Kernel
threads, mutexes and locks) it does slow down the kernel level processing
and the scheduling on the system.

3) Isilon is a "lame duck" for Spectrum Scale workloads (even with dsmISI)

In contrast to Dr. Stefan Radtke's BLOG entry, System Protect (TSM) is
fully aware of a scalable filesystem, but Isilon does not provide the OneFS
filesystem to the outside world it's only used internal to the Isilon
nodes. Isilon is a scale-out NAS server but not a scale-out Filesystem!
Each NFS Server to NFS Client relation is always a "1:1" relation
<IP-Adress-NFS-Server-on-Isilon-Node-X> to
<IP-Adress-NFS-Client-on-TSM-Server>. The dsmISI tools is trying spreading
the TSM I/O load over as much NFS client mount points as possible to
"parallelize" the I/O load. Still the total amount of I/O is not
impressive.

4) What is best way to really solve this problem?

Just using a "real" parallel filesystem on the Spectrum Scale Server is the
best way to solve this problem from my point of view. Much faster, much
more robust and you have only 1 mount point on the system and no need for
spending money on dsmISI tools :-) More reading here, this explains the
details:

https://www.ibm.com/developerworks/community/blogs/storageneers/entry/Is_a_scale_out_NAS_system_the_same_as_a_scale_out_file_system?lang=en


-frank-

p.s. Spectrum Scale User Workshop in Germany March 2017
https://www.spectrumscale.org/spectrum-scale-user-meeting-march-89-2027-ehningen-germany/

Frank Kraemer
IBM Consulting IT Specialist  / Client Technical Architect
Am Weiher 24, 65451 Kelsterbach
mailto:kraemerf AT de.ibm DOT com
voice: +49-(0)171-3043699 / +4970342741078
IBM Germany

<Prev in Thread] Current Thread [Next in Thread>
  • Re: [ADSM-L] Why do you feel it is a "bad idea" to use EMC Isilon for TSM target storage for backups?, Frank Kraemer <=