ADSM-L

Re: [ADSM-L] TSM 5.5 using LANFree backup really "slow"

2009-08-01 12:38:08
Subject: Re: [ADSM-L] TSM 5.5 using LANFree backup really "slow"
From: Steven Langdale <Steven.Langdale AT CAT DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Sat, 1 Aug 2009 17:36:43 +0100
LAN Free will be poor with this kind of data.

What is your actual backup & restore requirement?  What's your backup 
window, how much data and how much changed data per day.

Steven

Steven Langdale
Global Information Services
EAME SAN/Storage Planning and Implementation
( Phone : +44 (0)1733 584175
( Mob: +44 (0)7876 216782
ü Conference: +44 (0)208 609 7400 Code: 331817
+ Email: steven.langdale AT cat DOT com

 



Flavio Junior <billpp AT GMAIL DOT COM> 
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
01/08/2009 17:10
Please respond to
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>


To
ADSM-L AT VM.MARIST DOT EDU
cc

Subject
Re: [ADSM-L] TSM 5.5 using LANFree backup really "slow"




Caterpillar: Confidential Green Retain Until: 31/08/2009 



Hi David,

Well FileServer is exact what i'm backup ;/
A lot of files with sizes between 100k and 20Mb.

So, there is nothing that can be done to improve this, at least for 
100GB/h?
Just to point my head toward right direction.. LANFree backups or LAN 
backups.

Thanks,

--

Flávio do Carmo Júnior aka waKKu
Florianópolis/SC - Brazil

On Sat, Aug 1, 2009 at 12:02 PM, David
McClelland<david.mcclelland AT networkc.co DOT uk> wrote:
> What is the nature of the data that you're backing up here? Large
> files/objects or lots of smaller files/objects? The classic 
recommendation
> for SAN backups direct to tape is that it's best used only for larger
> objects (eg database backups, TDPs or disk image etc) to ensure optimal
> streaming to tape. Backing up a file server with millions of individual
> small files direct to tape won't always produce a great overall 
throughput
> figure.
>
> /David Mc
> London, UK
>
> Sent from my iPhone
>
> On 1 Aug 2009, at 15:37, Flavio Junior <billpp AT GMAIL DOT COM> wrote:
>
>> Hi Steve, thanks for answering...
>>
>> Yeah, the destination is tape, i see on StorageAgent console the
>> connection to server and opening tape, during the backup I see the
>> bytes increasing on "Backup by LANFree: " (but, this value is ALWAYS
>> lower than the value of normal backup... i don't know if this is
>> normal).
>> VALIDATE LANFREE node policyset shows me that the node is capable to
>> LANFree backups.
>>
>> During the backup (using webclient interface) I can see two speeds,
>> well.. A screenshot of backup report is at link:
>> http://img18.imageshack.us/img18/9278/backupz.jpg
>>
>> The screenshot is in portuguese but I think is easy to you guess what
>> is each value...
>> Time: 5:45 Hours
>> Size: 181 Gb
>> No compression
>>
>> Rede == Network
>> Agregada == Aggregate, combination... (not sure how TSM show it)
>>
>> Ok, this is what I have... If need more info just let me know.
>>
>> Thanks again.
>>
>> --
>>
>> Flávio do Carmo Júnior aka waKKu
>> Florianópolis/SC - Brazil
>>
>> On Sat, Aug 1, 2009 at 3:51 AM, Steven Harris<steve AT stevenharris DOT info>
>> wrote:
>>>
>>> Flavio
>>>
>>> Is the destination of your backup pool tape? Have you confirmed with
>>> VALIDATE LANFREE on the server
>>> Are you seeing a "proxied by" message in the client log to indicate 
that
>>> the
>>> storage agent is in use?
>>> Is the *network* path configured as 1Gb - I'm suspecting you have a 
LAN
>>> backup and that the lan path has issues.
>>>
>>> HTH
>>>
>>> Regards
>>>
>>> Steve
>>>
>>> Steven Harris.
>>> TSM Admin, looking for work, Sydney Australia
>>>
>>>
>>>
>>> Flavio Junior wrote:
>>>>
>>>> Hi folks,
>>>>
>>>> I'm here, again, asking for help :)
>>>> More I read, more doubts I have.
>>>>
>>>> I'm now implementing a TSM For SAN setup, to performance comparison
>>>> with my currently LAN backup.
>>>>
>>>> I'll describe my scenario below, any doubt's feel free to ask me:
>>>> - 2 Production nodes using RHEL 5.3 connected to SAN
>>>> - 1 IBM DS4700 storage with 14 FC disks (13 raid5 + 1 hot-spare)
>>>> - Each node have a emulex dual-port HBA
>>>> - 2 Brocade TotalStorage fiber switches, with coherent zonings
>>>> - Library is a IBM TS3100 LTO4 SAN, with only one drive
>>>>
>>>> Ok, i'm using TSM with LAN backups for a week, the transfer rate 
comes
>>>> among 60~80GB per hour.
>>>> The tape has a nominal write speed of 120MB/s that says me 430GB/h,
>>>> ok.. this is a *nominal* speed, I was expecting something near
>>>> 300GB/h, good enough for me.
>>>>
>>>> For these tests I've configured TSM Server on node1 and TSM Client on
>>>> node2. Each node has 6 1Gbps NIC's, 4 to public network 2 for
>>>> cluster-heartbeat + backups.
>>>> With this setup I've got, as said above, 60~80GB/h.
>>>>
>>>> So, I decide to setup TSM for SAN.. Download a lot of docs/books and
>>>> start reading/doing.
>>>> I end up with:
>>>>
>>>> - Fabric zoning changes, isolating a HBA port on each dual-port cards
>>>> for
>>>> nodes
>>>> - Installed StorageAgent on node2
>>>> - Installed TSM Client on node2
>>>> - - Configured the client to connect on storageagent
>>>> - Redefine all my TSM Server setup
>>>> - - Make Library as shared=yes, configure storage agent as a server,
>>>> configure path, configure datawritepath=lanfree and so on...
>>>>
>>>> Ok, time to backup.
>>>> And, for my surprise i got only ~500MB per minute.. I thought it very
>>>> strange.. I've no idea what is the problem, I've tried with
>>>> compression and without, DATAREADPATH=LAN and SAN, VirtualMountPoints
>>>> or Physical ...
>>>>
>>>> Does anybody have an idea the reason of that bad transfer rate?? The
>>>> servers are Samba Servers, with all kind of file and all size
>>>>
>>>> As I said before, I'm really new with TSM so is really possible that
>>>> I've misconfigured something :)
>>>>
>>>> Anyway, thanks in advance, and any help will be appreciated.
>>>>
>>>> --
>>>>
>>>> Flávio do Carmo Júnior aka waKKu
>>>> Florianópolis/SC - Brazil
>>>> 
------------------------------------------------------------------------
>>>>
>>>>
>>>> No virus found in this incoming message.
>>>> Checked by AVG - www.avg.com Version: 8.5.392 / Virus Database:
>>>> 270.13.38/2274 - Release Date: 07/31/09 05:58:00
>>>>
>>>>
>>>
>