Re: Deploying PostgreSQL on CentOS with SSD and Hardware RAID - Mailing list pgsql-general

From Matt Brock
Subject Re: Deploying PostgreSQL on CentOS with SSD and Hardware RAID
Date
Msg-id 9E5057DA-91BC-48D3-9AE2-C4DA6E4145B8@mattbrock.co.uk
Whole thread Raw
In response to Re: Deploying PostgreSQL on CentOS with SSD and Hardware RAID  (Merlin Moncure <mmoncure@gmail.com>)
List pgsql-general
So a week after asking our HP dealer, they've finally replied to say that they can't tell us what manufacturer and
modelthe SSDs are because "HP treat this information as company confidential". Not particularly helpful. 

They have at least confirmed that the drives have "surprise power loss protection" and "tools to present information on
thepercentage of life used and amount of life remaining under the workload-to-date". 

Given that these are enterprise class drives, and given that they have the high availability features that we would
needin database servers, and given that the deadline on this project is very tight so I don't really have time to do
anytesting on third-party drives, I'm guessing we'll go with the HP drives, even though they most likely are a little
behindthe times. Whilst we will perhaps lose in a little bit of performance compared to the latest Intel drives, we
willgain in terms of high availability reassurance and simplicity of deployment which is crucial for this project given
itstight deadline. However, after going through all the advice on this thread and having had time to think, I'll
probablygo for a four-disk RAID 10 array with SLCs, rather than a two-disk RAID 1 array with MLCs (for the OS) and a
two-diskRAID 1 array with SLCs (for the database). 

If I had more time and resources for testing I would likely end up going a different route, however.

Many thanks to all who've contributed their thoughts and opinions - much appreciated.

Matt.

On 13 May 2013, at 14:49, Merlin Moncure <mmoncure@gmail.com> wrote:

> On Sun, May 12, 2013 at 8:20 PM, John R Pierce <pierce@hogranch.com> wrote:
>> On 5/12/2013 6:13 PM, David Boreham wrote:
>>>
>>>
>>> Not quite. More like : a) I don't know where to buy SLC drives in 2013
>>> (all the drives for example for sale on newegg.com are MLC) and b) today's
>>> MLC drives are quite good enough for me (and I'd venture to say any
>>> database-related purpose).
>>
>>
>> Newegg wouldn't know 'enterprise' if it bit them.   they just sell mass
>> market consumer stuff and gamer kit.
>>
>> the real SLC drives end up OEM branded in large SAN systems, such as sold by
>> Netapp, EMC, and are made by companies like STEC that have zero presence in
>> the 'whitebox' resale markets like Newegg.
>
>
> The industry decided a while back that MLC was basically the way to go
> in terms of cost and engineering trade-offs, at least in cases where
> you needed a lot of storage. Yes, you can still get SLC in mid-tier
> and up storage but:
>
> *) a lot of these drives are simply re-branded intel etc
> *) When it comes to SSD, I have zero confidence in vendor provided
> hardware specs (lifetime, iops, etc).  The lack of 3rd party test
> coverage and performance benchmarking is a big problem for me.  Ever
> bought a SAN and have had it not do what it was supposed to?
> *) The faster moving white box market has chosen MLC.  Three years
> back, the jury was still out.  This suggests to me that SAN vendors
> are still behind the curve in terms of SSD, which is typical of
> enterprise storage vendors. But,
> *) In many cases, the performance of the latest MLC drives is so fast
> that many applications that would have needed to scale up to high end
> storage would no longer need to do so.   A software raid of say for
> s3700 drives would probably outperform most <100k SANs from a couple
> years back.
>
> merlin
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>



pgsql-general by date:

Previous
From: Fabrízio de Royes Mello
Date:
Subject: Re: WAL contains references to invalid pages
Next
From: Tom Lane
Date:
Subject: Re: problem with lost connection while running long PL/R query