[CentOS] storage for mailserver

Wed Sep 16 16:26:47 UTC 2020
Stephen John Smoogen <smooge at gmail.com>

On Wed, 16 Sep 2020 at 12:12, Michael Schumacher <
michael.schumacher at pamas.de> 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.




> Any thoughts?
>
> best regards
> Michael Schumacher
>
> _______________________________________________
> CentOS mailing list
> CentOS at centos.org
> https://lists.centos.org/mailman/listinfo/centos
>


-- 
Stephen J Smoogen.