Questions related to Container pools

2017-05-03 Thread PAC Brion Arnaud
Hi Team !

IBM recently released an interesting document summarizing best practices with 
regards to container storage pools 
(https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/Tivoli 
Storage Manager/page/Container Pool Best Practices ) and some of the 
information in it triggered two questions, which I would like some Spectrum 
Protect insider (Del ?) or anyone having good knowledge of this to answer ...

First question :  page 14 of the PDF document, chapter 1.4 , states that it is 
not appropriate to use container pools in the case of NDMP backups. What is the 
reason for it ? My understanding is that it is possible to make use of NDMP 
without a tape based storage pool, thus I don't get the point here ...

Second question : several references in the book are seeming to stress that one 
should make use of ONE SINGLE container storage pool for a whole TSM server 
(chapter 1.2.5.1.2 page 13, chapter 1.5.1 page 15). I do understand that 
deduplication is made at storage pool level, and that segregating backup data 
in several storage pools will weaken deduplication rates, but are there some 
other reasons which are not explained in the book, that would justify the use 
of only ONE container pool (like more hammering on the TSM DB during backup 
times if we make use of several storage pools, or others I did not think about)
We plan to build a new TSM environment which will be based only on container 
storage pool(s ?), and I feel kind of uncomfortable to send all of my data in 
the same bucket (less granularity for reporting, auditing, protecting and so on 
...).  Does someone have arguments (pro or cons) or experience to share about 
this ?

Thanks in advance for your feedback !

Cheers.

Arnaud

**
Backup and Recovery Systems Administrator
Panalpina Management Ltd., Basle, Switzerland,
CIT Department Viadukstrasse 42, P.O. Box 4002 Basel/CH
Phone: +41 (61) 226 11 11, FAX: +41 (61) 226 17 01
Direct: +41 (61) 226 19 78
e-mail: arnaud.br...@panalpina.com
This electronic message transmission contains information from Panalpina and is 
confidential or privileged. This information is intended only for the person 
(s) named above. If you are not the intended recipient, any disclosure, 
copying, distribution or use or any other action based on the contents of this 
information is strictly prohibited.

If you receive this electronic transmission in error, please notify the sender 
by e-mail, telephone or fax at the numbers listed above. Thank you.
**


Re: TSM 7.1.7 server CPU behavior

2017-05-03 Thread Stefan Folkerts
Eric,

Yes, we are running server-side dedup and compression on the site mentioned
earlier, I can't say I see these spikes but the system is rather busy
during the day as well so it would be kind of difficult to spot I guess. :-)



On Wed, May 3, 2017 at 2:51 PM, Ryder, Michael S 
wrote:

> You didn't mention the OS.
>
> Have you considered running any diagnostic tools to figure out exactly what
> process is causing the extra spikes?  For example, top or collectl (unix),
> or perfmon or resource monitor (windows)?
>
> Mike
>
> On Wed, May 3, 2017 at 7:08 AM, Loon, Eric van (ITOPT3) - KLM <
> eric-van.l...@klm.com> wrote:
>
> > By the way, it's not a monitoring tool because the spikes disappear right
> > after the backup window...
> > Kind regards,
> > Eric van Loon
> > Air France/KLM Storage Engineering
> >
> >
> > -Original Message-
> > From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of
> > Stefan Folkerts
> > Sent: woensdag 3 mei 2017 10:58
> > To: ADSM-L@VM.MARIST.EDU
> > Subject: Re: TSM 7.1.7 server CPU behavior
> >
> > Hi Eric,
> >
> > I only have sar data of last night but I see a load around 40% that
> breaks
> > down to 15% user, 5% system 10-20% iowait and the rest being idle.
> > 10% is very low, it must be overpowered or still running a very low load.
> >
> > Maybe it's a monitoring tool that is hitting the system every 5 minutes,
> > do you see entries in the activity log that match the load? do you seen
> > more iop/s on the database?
> >
> >
> >
> >
> > On Wed, May 3, 2017 at 10:30 AM, Loon, Eric van (ITOPT3) - KLM <
> > eric-van.l...@klm.com> wrote:
> >
> > > Hi all!
> > > We are running a 7.1.7 server with a directory container storagepool
> > > (dedup and compression enabled). When we have multiple clients (with
> > > client-dedup disabled) backing up to it, we notice a peculiar CPU
> usage.
> > > Overall CPU is about 10%, but we see short peaks to approx. 30% every
> > > 5 minutes. Since this server is the only one with container storage
> > > pools in our company I cannot compare this behavior to other TSM
> > > servers. Is this behavior seen on other servers too?
> > > Thanks for any help in advance!
> > > Kind regards,
> > > Eric van Loon
> > > Air France/KLM Storage Engineering
> > > 
> > > For information, services and offers, please visit our web site:
> > > http://www.klm.com. This e-mail and any attachment may contain
> > > confidential and privileged material intended for the addressee only.
> > > If you are not the addressee, you are notified that no part of the
> > > e-mail or any attachment may be disclosed, copied or distributed, and
> > > that any other action related to this e-mail or attachment is strictly
> > > prohibited, and may be unlawful. If you have received this e-mail by
> > > error, please notify the sender immediately by return e-mail, and
> delete
> > this message.
> > >
> > > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or
> > > its employees shall not be liable for the incorrect or incomplete
> > > transmission of this e-mail or any attachments, nor responsible for any
> > delay in receipt.
> > > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal
> > > Dutch
> > > Airlines) is registered in Amstelveen, The Netherlands, with
> > > registered number 33014286
> > > 
> > >
> > 
> > For information, services and offers, please visit our web site:
> > http://www.klm.com. This e-mail and any attachment may contain
> > confidential and privileged material intended for the addressee only. If
> > you are not the addressee, you are notified that no part of the e-mail or
> > any attachment may be disclosed, copied or distributed, and that any
> other
> > action related to this e-mail or attachment is strictly prohibited, and
> may
> > be unlawful. If you have received this e-mail by error, please notify the
> > sender immediately by return e-mail, and delete this message.
> >
> > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its
> > employees shall not be liable for the incorrect or incomplete
> transmission
> > of this e-mail or any attachments, nor responsible for any delay in
> receipt.
> > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch
> > Airlines) is registered in Amstelveen, The Netherlands, with registered
> > number 33014286
> > 
> >
>


Re: TSM 7.1.7 server CPU behavior

2017-05-03 Thread Ryder, Michael S
You didn't mention the OS.

Have you considered running any diagnostic tools to figure out exactly what
process is causing the extra spikes?  For example, top or collectl (unix),
or perfmon or resource monitor (windows)?

Mike

On Wed, May 3, 2017 at 7:08 AM, Loon, Eric van (ITOPT3) - KLM <
eric-van.l...@klm.com> wrote:

> By the way, it's not a monitoring tool because the spikes disappear right
> after the backup window...
> Kind regards,
> Eric van Loon
> Air France/KLM Storage Engineering
>
>
> -Original Message-
> From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of
> Stefan Folkerts
> Sent: woensdag 3 mei 2017 10:58
> To: ADSM-L@VM.MARIST.EDU
> Subject: Re: TSM 7.1.7 server CPU behavior
>
> Hi Eric,
>
> I only have sar data of last night but I see a load around 40% that breaks
> down to 15% user, 5% system 10-20% iowait and the rest being idle.
> 10% is very low, it must be overpowered or still running a very low load.
>
> Maybe it's a monitoring tool that is hitting the system every 5 minutes,
> do you see entries in the activity log that match the load? do you seen
> more iop/s on the database?
>
>
>
>
> On Wed, May 3, 2017 at 10:30 AM, Loon, Eric van (ITOPT3) - KLM <
> eric-van.l...@klm.com> wrote:
>
> > Hi all!
> > We are running a 7.1.7 server with a directory container storagepool
> > (dedup and compression enabled). When we have multiple clients (with
> > client-dedup disabled) backing up to it, we notice a peculiar CPU usage.
> > Overall CPU is about 10%, but we see short peaks to approx. 30% every
> > 5 minutes. Since this server is the only one with container storage
> > pools in our company I cannot compare this behavior to other TSM
> > servers. Is this behavior seen on other servers too?
> > Thanks for any help in advance!
> > Kind regards,
> > Eric van Loon
> > Air France/KLM Storage Engineering
> > 
> > For information, services and offers, please visit our web site:
> > http://www.klm.com. This e-mail and any attachment may contain
> > confidential and privileged material intended for the addressee only.
> > If you are not the addressee, you are notified that no part of the
> > e-mail or any attachment may be disclosed, copied or distributed, and
> > that any other action related to this e-mail or attachment is strictly
> > prohibited, and may be unlawful. If you have received this e-mail by
> > error, please notify the sender immediately by return e-mail, and delete
> this message.
> >
> > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or
> > its employees shall not be liable for the incorrect or incomplete
> > transmission of this e-mail or any attachments, nor responsible for any
> delay in receipt.
> > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal
> > Dutch
> > Airlines) is registered in Amstelveen, The Netherlands, with
> > registered number 33014286
> > 
> >
> 
> For information, services and offers, please visit our web site:
> http://www.klm.com. This e-mail and any attachment may contain
> confidential and privileged material intended for the addressee only. If
> you are not the addressee, you are notified that no part of the e-mail or
> any attachment may be disclosed, copied or distributed, and that any other
> action related to this e-mail or attachment is strictly prohibited, and may
> be unlawful. If you have received this e-mail by error, please notify the
> sender immediately by return e-mail, and delete this message.
>
> Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its
> employees shall not be liable for the incorrect or incomplete transmission
> of this e-mail or any attachments, nor responsible for any delay in receipt.
> Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch
> Airlines) is registered in Amstelveen, The Netherlands, with registered
> number 33014286
> 
>


Re: TSM 7.1.7 server CPU behavior

2017-05-03 Thread Loon, Eric van (ITOPT3) - KLM
By the way, it's not a monitoring tool because the spikes disappear right after 
the backup window...
Kind regards,
Eric van Loon
Air France/KLM Storage Engineering


-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Stefan 
Folkerts
Sent: woensdag 3 mei 2017 10:58
To: ADSM-L@VM.MARIST.EDU
Subject: Re: TSM 7.1.7 server CPU behavior

Hi Eric,

I only have sar data of last night but I see a load around 40% that breaks down 
to 15% user, 5% system 10-20% iowait and the rest being idle.
10% is very low, it must be overpowered or still running a very low load.

Maybe it's a monitoring tool that is hitting the system every 5 minutes, do you 
see entries in the activity log that match the load? do you seen more iop/s on 
the database?




On Wed, May 3, 2017 at 10:30 AM, Loon, Eric van (ITOPT3) - KLM < 
eric-van.l...@klm.com> wrote:

> Hi all!
> We are running a 7.1.7 server with a directory container storagepool 
> (dedup and compression enabled). When we have multiple clients (with 
> client-dedup disabled) backing up to it, we notice a peculiar CPU usage.
> Overall CPU is about 10%, but we see short peaks to approx. 30% every 
> 5 minutes. Since this server is the only one with container storage 
> pools in our company I cannot compare this behavior to other TSM 
> servers. Is this behavior seen on other servers too?
> Thanks for any help in advance!
> Kind regards,
> Eric van Loon
> Air France/KLM Storage Engineering
> 
> For information, services and offers, please visit our web site:
> http://www.klm.com. This e-mail and any attachment may contain 
> confidential and privileged material intended for the addressee only. 
> If you are not the addressee, you are notified that no part of the 
> e-mail or any attachment may be disclosed, copied or distributed, and 
> that any other action related to this e-mail or attachment is strictly 
> prohibited, and may be unlawful. If you have received this e-mail by 
> error, please notify the sender immediately by return e-mail, and delete this 
> message.
>
> Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or 
> its employees shall not be liable for the incorrect or incomplete 
> transmission of this e-mail or any attachments, nor responsible for any delay 
> in receipt.
> Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal 
> Dutch
> Airlines) is registered in Amstelveen, The Netherlands, with 
> registered number 33014286
> 
>

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



Re: TSM 7.1.7 server CPU behavior

2017-05-03 Thread Loon, Eric van (ITOPT3) - KLM
Hi Stefan!
The load is rather low, it's sized for future growth. I'm just curious if you 
see those short peaks too or is the load overall the same?
Do you use server-side dedup by the way?
Thanks again for your help!
Kind regards,
Eric van Loon
Air France/KLM Storage Engineering

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Stefan 
Folkerts
Sent: woensdag 3 mei 2017 10:58
To: ADSM-L@VM.MARIST.EDU
Subject: Re: TSM 7.1.7 server CPU behavior

Hi Eric,

I only have sar data of last night but I see a load around 40% that breaks down 
to 15% user, 5% system 10-20% iowait and the rest being idle.
10% is very low, it must be overpowered or still running a very low load.

Maybe it's a monitoring tool that is hitting the system every 5 minutes, do you 
see entries in the activity log that match the load? do you seen more iop/s on 
the database?




On Wed, May 3, 2017 at 10:30 AM, Loon, Eric van (ITOPT3) - KLM < 
eric-van.l...@klm.com> wrote:

> Hi all!
> We are running a 7.1.7 server with a directory container storagepool 
> (dedup and compression enabled). When we have multiple clients (with 
> client-dedup disabled) backing up to it, we notice a peculiar CPU usage.
> Overall CPU is about 10%, but we see short peaks to approx. 30% every 
> 5 minutes. Since this server is the only one with container storage 
> pools in our company I cannot compare this behavior to other TSM 
> servers. Is this behavior seen on other servers too?
> Thanks for any help in advance!
> Kind regards,
> Eric van Loon
> Air France/KLM Storage Engineering
> 
> For information, services and offers, please visit our web site:
> http://www.klm.com. This e-mail and any attachment may contain 
> confidential and privileged material intended for the addressee only. 
> If you are not the addressee, you are notified that no part of the 
> e-mail or any attachment may be disclosed, copied or distributed, and 
> that any other action related to this e-mail or attachment is strictly 
> prohibited, and may be unlawful. If you have received this e-mail by 
> error, please notify the sender immediately by return e-mail, and delete this 
> message.
>
> Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or 
> its employees shall not be liable for the incorrect or incomplete 
> transmission of this e-mail or any attachments, nor responsible for any delay 
> in receipt.
> Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal 
> Dutch
> Airlines) is registered in Amstelveen, The Netherlands, with 
> registered number 33014286
> 
>

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



Re: TSM 7.1.7 server CPU behavior

2017-05-03 Thread Stefan Folkerts
Hi Eric,

I only have sar data of last night but I see a load around 40% that breaks
down to 15% user, 5% system 10-20% iowait and the rest being idle.
10% is very low, it must be overpowered or still running a very low load.

Maybe it's a monitoring tool that is hitting the system every 5 minutes, do
you see entries in the activity log that match the load? do you seen more
iop/s on the database?




On Wed, May 3, 2017 at 10:30 AM, Loon, Eric van (ITOPT3) - KLM <
eric-van.l...@klm.com> wrote:

> Hi all!
> We are running a 7.1.7 server with a directory container storagepool
> (dedup and compression enabled). When we have multiple clients (with
> client-dedup disabled) backing up to it, we notice a peculiar CPU usage.
> Overall CPU is about 10%, but we see short peaks to approx. 30% every 5
> minutes. Since this server is the only one with container storage pools in
> our company I cannot compare this behavior to other TSM servers. Is this
> behavior seen on other servers too?
> Thanks for any help in advance!
> Kind regards,
> Eric van Loon
> Air France/KLM Storage Engineering
> 
> For information, services and offers, please visit our web site:
> http://www.klm.com. This e-mail and any attachment may contain
> confidential and privileged material intended for the addressee only. If
> you are not the addressee, you are notified that no part of the e-mail or
> any attachment may be disclosed, copied or distributed, and that any other
> action related to this e-mail or attachment is strictly prohibited, and may
> be unlawful. If you have received this e-mail by error, please notify the
> sender immediately by return e-mail, and delete this message.
>
> Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its
> employees shall not be liable for the incorrect or incomplete transmission
> of this e-mail or any attachments, nor responsible for any delay in receipt.
> Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch
> Airlines) is registered in Amstelveen, The Netherlands, with registered
> number 33014286
> 
>


TSM 7.1.7 server CPU behavior

2017-05-03 Thread Loon, Eric van (ITOPT3) - KLM
Hi all!
We are running a 7.1.7 server with a directory container storagepool (dedup and 
compression enabled). When we have multiple clients (with client-dedup 
disabled) backing up to it, we notice a peculiar CPU usage. Overall CPU is 
about 10%, but we see short peaks to approx. 30% every 5 minutes. Since this 
server is the only one with container storage pools in our company I cannot 
compare this behavior to other TSM servers. Is this behavior seen on other 
servers too?
Thanks for any help in advance!
Kind regards,
Eric van Loon
Air France/KLM Storage Engineering

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286