I understand the issue with a limited budget, but in the end, you should ask
your boss/customer if a non-restorable server (with the included data loss) is
ok?
In the end, TSM does 2 things:
a) It takes all the data that was written by all other servers in your
organisation and secures it on disk & tape within the TSM server. Preferably,
you also want the TSM server todo this in 1/4th (or whatever your backup window
is) of the time the rest of your servers had to write the data.
b) When everything else fails, your organisation will turn to that TSM server
and pray it will restore the data they lost. Your organisation probably wants
this to be done in 1/4th of the time aswell.
The TSM server isnt some periferable device sitting in a corner collecting
dust. It's the insurance the rest of your servers bought to be able to handle
an outage. So spending that extra buck on RAID, or getting the extra 10%
performance will in the end be worth every $ spent.
Regretably, most organisations need an outage before they realize this. And
when the disaster has happened, the people deciding about investments usually
dont have a problem spending that extra buck. To bad they spent it after the
disaster and not before though.
Getting enough money to build a TSM server that will hold usually just comes
down to explaining the risks and the costs of not doing the investment.
And on a side-note, TSM isnt about backing up as fast as possible, or expiring
in as short time as possible, but getting the data back where it belongs as
quickly as possible so that your organisation can continue working. If the TSM
server has issues handling internal data movement, backup times or other
administrative jobs, I'd be looking at restore times aswell since they will get
hit long before you notice you have internal issues within the TSM server.
Best Regards
Daniel Sparrman
-----"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> skrev: -----
Till: ADSM-L AT VM.MARIST DOT EDU
Från: Henrik Ahlgren <pablo AT SEESTIETO DOT COM>
Sänt av: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
Datum: 11/23/2010 08:27
Ärende: Re: Ang: Re: DB2: SSD vs more RAM
With limited budget and spinning disks you often have to choose security only.
But it's somewhat an illusion, since disks are so slow that your system really
doesn't work: your expiration cycles take days to complete (at least with
fragmented db - maybe TSM6 is much better), and doing many simultaneusly
restores (tons of small files) during disaster recovery takes forever when your
db disk setup is the bottleneck.
Short stroking Intel MLC SSD:s makes them last longer specifically with random
writes. Of course they still wear out faster than SLC, so heavy database
workload propably would be too much. (But they are used for many server
workloads) With SLC it's almost a non-issue.
Data loss is never acceptable, but for some organizations outages just might
be. After all, many run TSM in single server without any H/A clustering.
Anyway I have to agree that if your db is 200GB and budget allows six
performance disks, go with disks. if the DB would be 50 GB and same budget
(let's say $1500) I would not even think using disks instead of SSD.
------- Original message -------
> From: Daniel Sparrman <daniel.sparrman AT EXIST DOT SE>
> To: ADSM-L AT VM.MARIST DOT EDU
> Sent: 2010-11-23, 1:01
>
> Skipping raid/mirroring is probably the worst thing he could do. When the
> database hits that size, you can expect your organisation to want the TSM
> server up at all times. A disk outage would not really meet that requirement.
>
> SSD disks only have a longer lifespan during lots of reads / less writes. In
> a TSM environment, that wouldnt be true, thus not giving the SSD's a longer
> lifespan.
>
> a) Secure your TSM server, it's your lifeline whenever everything else goes
> wrong
>
> b) Go for performance
>
> Never turn those 2 points the other way around.
>
> Regards
>
> Daniel Sparrman
>
> -----"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> skrev: -----
>
>
> Till: ADSM-L AT VM.MARIST DOT EDU
> Från: Henrik Ahlgren <pablo AT SEESTIETO DOT COM>
> Sänt av: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
> Datum: 11/22/2010 23:27
> Ärende: Re: DB2: SSD vs more RAM
>
> Yep, doing a 200 GB database with high-end and reduntant SLC NAND is
> definedly not cheap (let alone the 2 TB Bill Colwell described in his post).
> Not that bunch of 15K disks and the power to run them is free, either. Cost
> per IOPS for disk is actually terrible.
>
> Just a thought (don't take too seriously!): what if you'd be willing to take
> the risk and forget RAID/mirroring, after all solid state is pretty reliable
> these days. Of course - in addition to perfect DB backup strategy you need
> anyhow - put your transaction logs to different disk: spinning disk is great
> for that (it's more or less sequential I/O). And maybe even use cheaper MLC
> NAND - if you "short stroke" (google for intel ssd overprovisioning) a 160 GB
> X25-M down to 128 GB, you get three times the endurance, so it should last
> for quite a long time even with DB workload. Of course, like tapes, you have
> to treat NAND media as consumables, and keep an eye on the S.M.A.R.T. media
> wearout indicators.
>
> Yeah, too radical and risky for most. We'll just have to wait for couple of
> years more to finally get rid of rotating rust for random IO usage once and
> for all.
>
> On Nov 22, 2010, at 7:13 PM, Pretorius, Louw <louw AT sun.ac DOT za> wrote:
>
>> Well as I was specing a new TSM server i thought, why not try for the best
>> performance possible and although the SSD drives drives the server costs up
>> by 50% it wasn't out of the ballpark, therefore I wanted to hear from the
>> community what their ideas were.
>>
>> As it stands I have a 100GB DB currently ~50% used but according to IBM TSM
>> 6.2 will require double DB size hence 200GB and since we are expecting a 40%
>> data-growth next year and will be implimenting Dedupe I thought why not see
>> how the price/performance goes on other sites.
>>
>> As db2 is a fully featured DB I thought that the alternative would be to
>> give it more RAM, as it's so much cheaper than SSD's. And also how I could
>> configure my DB2 to use the extra RAM that I will be throwing at it in any
>> case.
>>
>> With the current feedback I will be sticking to 6 x SAS 15K and 24GB RAM...
>>
>> Please if there's any other opinions let's hear it, the more opinions the
>> more wisdom...
>>
>> Regards
>> Louw Pretorius
>>
>> -----Original Message-----
>> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf
>> Of Henrik Ahlgren
>> Sent: 22 November 2010 11:25
>> To: ADSM-L AT VM.MARIST DOT EDU
>> Subject: Re: [ADSM-L] DB2: SSD vs more RAM
>>
>> Or maybe he has a huge amount of DB entries? If his options are either six
>> SAS 15K or eight SSDs (50GB each), it means his DB is propably in the
>> multi-hundred gigabyte range. If he just needs the IOPS for smaller DB, then
>> he would not need 8 SSDs to beat 6 platters, even one or two could be
>> enough. (Just one Intel X25E does 35K IOPS random 4K read.) I'm not sure how
>> much doubling the RAM would help with operations such as expiration, DB
>> backup etc. compared to nice SSD setup.
>>
>> I'm wondering why so little discussion here on using solid state devices for
>> TSM databases? Some of you must be doing it, right?
>>
>> On Nov 17, 2010, at 7:50 PM, Remco Post wrote:
>>
>>> SSD to me seems overkill if you already have 24 GB of RAM, unless you need
>>> superfast performance and are going to run a very busy TSM server with a
>>> huge amount of concurrent sessions.
>>>
>>> --
>>>
>>> Gr., Remco
>>>
>>> On 17 nov. 2010, at 12:16, "Pretorius, Louw <louw AT sun.ac DOT za>" <louw
>>> AT SUN.AC DOT ZA> wrote:
>>>
>>>> Hi all,
>>>>
>>>> I am currently in the process of setting up specifications for our new
>>>> TSM6.2 server.
>>>>
>>>> I started by adding 8 x SSD 50GB disks to hold OS and DB, but because of
>>>> the high costs was wondering if it's possible to rather buy more RAM and
>>>> increase the DB2 cache to speed up the database.
>>>>
>>>> Currently I have RAM set at 24GB but its way cheaper doubling the RAM
>>>> than to buy 8 x SSD's Currently I have 8 x SSD vs 6 x SAS 15K
>>
>>
>> --
>> Henrik Ahlgren
>> Seestieto
>> +358-50-3866200
>
>
> --
> Henrik Ahlgren
> Seestieto
> +358-50-3866200
|
