Re: storage for mailserver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]





On 2020-09-16 11:26, Stephen John Smoogen wrote:
On Wed, 16 Sep 2020 at 12:12, Michael Schumacher <
michael.schumacher@xxxxxxxx> wrote:

hi,

I am planning to replace my old CentOS 6 mail server soon. Most details
are quite obvious and do not need to be changed, but the old system
was running on spinning discs and this is certainly not the best
option for todays mail servers.

With spinning discs, HW-RAID6 was the way to go to increase reliability
and speed.
Today, I get the feeling, that traditional RAID is not the best
option for SSDs. I am reading that all RAID members in SSD-arrays age
synchronously so that the risk of a massive failure of more than one
disk is more likely than with HDDs. There are many other concerns like
excessive write load compared to non-raid systems, etc.

Is there any common sense what disk layout should be used these days?

I have been looking for some kind of master-slave system, where the
(one or many) SSD is taking all writes and reads, but the slave HDD
runs in parallel as a backup system like in a RAID1 system. Is there
any such system?

I don't think so because the drives would always be out of sync but in a
restart it would be hard to know if the drive is out of sync for a good
reason or a bad one. For most of the SSD raids, I have seen people just
making sure to buy disks which are spec'd for more writes or similar
'smarter' enterprise trim. I have also read about the synchronicity problem
but I think this may be a theory vs reality problem. In theory they should
all fail at once, in reality at least for the arrays I have used for 3
years, they seem to fail in different times. that said, I only have 3
systems over 3 years with SSD drives running RAID6 so I only have anecdata
versus data.


I fully agree about synchronous failure of SSDs in RAID to be made up or grossly overrated. SSD failure _probablity_ is increased with number of write operations (into the same area). Failure still has stochastic nature. If SSD is spec'ed for N number of writes, it doesn't mean on the write N+1 SSD will fail. It only means that after N number of writes failure probability is below [some acceptable value], which, however is much higher of that of unused SSD.

That said, single SSD failure probability after long run is some small value, say q. Event of failure of another SSD is independent event from failure of first failed SSD (even though their probabilities q both increase with number of writes) hence probability of failures are:

one SSD failed:  q

two SSDs failed: (q)^2

three SSDs failed: (q)^3

thus multi-failures (say, within some period of time, say 1 day, or 1 week) still are way less probable events than single failure. The following numbers have nothing to do with probability of failure of some devices, it is just an illustration, so:

if q = 10 ^ (-10) (ten to the minus 10th power), then

(q)^2 = 10 ^ (-20)

(q)^3 = 10 ^ (-30)

My apologies for saying trivial things, they just give IMHO a feeling of what to take into consideration, and what to ignore safely.

And no, I don't intend to start flame war on views of statistics, or on hardware vs software RAIDs, or RAIDs vs zfs. Just think it over and draw your own conclusions.

Valeri




Any thoughts?

best regards
Michael Schumacher

_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos




--
++++++++++++++++++++++++++++++++++++++++
Valeri Galtsev
Sr System Administrator
Department of Astronomy and Astrophysics
Kavli Institute for Cosmological Physics
University of Chicago
Phone: 773-702-4247
++++++++++++++++++++++++++++++++++++++++
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos



[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]


  Powered by Linux