When we first started renegotiating our last deal, about a year ago, the
discount for ProtecTier was talked about a lot, but I don't know if it was part
of the final package.
We went with capacity-based licensing for two reasons:
1) no one liked dealing with PVUs, and the TSM server team could neither easily
measure PVUs nor encourage server administrators to factoring PVUs into their
designs.
2) We manage storage growth aggressively and track it constantly. Managing that
now manages our TSM license cost at the same time.
Oddly enough, it looks like our initial architecture for the VE environment
will play to this model nicely. As of TSM 6.3, the TDP for VE doesn't yet do
"incrementals forever," so we need an architecture that reduces backup time for
the data movers, and we will look heavily at client-side dedupe, on the theory
that we'll own the datamovers and can give them all the CPU power they might
need to do client-side dedupe without impacting production CPU capacities. Of
course, this is all on paper now; ask me in six months how well it's actually
working out.
Nick
On Jul 16, 2012, at 11:42 AM, Stackwick, Stephen wrote:
> I'm a little surprised by this, as the TSM macros you run to calculate the
> storage don't know (or care) about the storage device, i.e., they just report
> the uncompressed storage amount:
>
> https://www-304.ibm.com/support/docview.wss?uid=swg21500482&wv=1
>
> That said, if you are running TSM deduplication, that *is* reported with the
> macros, so there would be a cost saving. Was IBM talking about a discount for
> ProtecTier, maybe?
>
> Steve
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf
> Of Rick Adamson
> Sent: Monday, July 16, 2012 8:44 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: [ADSM-L] Moving to TSM Capacity based licensing from PVU -
> experiences
>
> Ian,
> Our company looked into it and thought it may save some $$ and at the same
> time simplify the OVERLY complex PVU license model used for TSM/IBM.
>
> I'll start by saying to make sure you understand what TSM products are
> included in the "capacity" license proposal. From memory I don't remember the
> exact ones but it does not apply to all TSM licenses. This obviously means
> that the capacity license model may be attractive to some and unattractive to
> others. Your IBM rep should be able to clarify this.
>
> Also, in our environment we use a Data Domain backend which as you may know
> prefers all incoming data to be uncompressed and unencrypted. Since the TSM
> servers have no knowledge of the DD processes it reports the raw storage
> numbers before compression and deduplication which negatively affected the
> capacity licensing pricing.
>
> We opened discussions on this issue with IBM but they refused to budge or
> negotiate an adjustment for the "actual" storage used. Needless to say that
> position was not too warmly received and we 86'ed the whole discussion.
>
> Interestingly, had we used IBM storage/deduplication on the backend they
> would use the actual storage, but no such provision for Data Domain.
>
> Good luck....
>
> ~Rick
>
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf
> Of Ian Smith
> Sent: Monday, July 16, 2012 7:13 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: [ADSM-L] Moving to TSM Capacity based licensing from PVU -
> experiences
>
> Hi,
>
> We are in the midst of discussions on moving to capacity-based licensing from
> the standard PVU-based method for our site. We have a large number of clients
> ( licensed via TSM-EE, TDP agents, and on client-device basis
> ) and around 1PB of primary pool data. As I understand it, there is no
> published metric for the conversion from PVU to per TB licensing so I would
> be really interested and grateful if anyone would like to share their
> experiences of that conversion in a private email to me.
>
> Many thanks in advance.
> Ian Smith
> Oxford University
> England
|
