[gpfsug-discuss] Strategies - servers with local SAS disks

[Zachary Giles]

Just remember that replication protects against data availability, not
integrity. GPFS still requires the underlying block device to return good
data.

If you're using it on plain disks (SAS or SSD), and the drive returns
corrupt data, GPFS won't know any better and just deliver it to the client.
Further, if you do a partial read followed by a write, both replicas could
be destroyed. There's also no efficient way to force use of a second
replica if you realize the first is bad, short of taking the first entirely
offline. In that case while migrating data, there's no good way to prevent
read-rewrite of other corrupt data on your drive that has the "good copy"
while restriping off a faulty drive.

Ideally RAID would have a goal of only returning data that passed the RAID
algorithm, so shouldn't be corrupt, or made good by recreating from parity.
However, as we all know RAID controllers are definitely prone to failures
as well for many reasons, but at least a drive can go bad in various ways
(bad sectors, slow, just dead, poor SSD cell wear, etc) without (hopefully)
silent corruption..

Just something to think about while considering replication ..



On Wed, Nov 30, 2016 at 11:28 AM, Uwe Falke <UWEFALKE at de.ibm.com> wrote:

> I have once set up a small system with just a few SSDs in two NSD servers,
> providin a scratch file system in a computing cluster.
> No RAID, two replica.
> works, as long the admins do not do silly things (like rebooting servers
> in sequence without checking for disks being up in between).
> Going for RAIDs without GPFS replication protects you against single disk
> failures, but you're lost if just one of your NSD servers goes off.
>
> FPO makes sense only sense IMHO if your NSD servers are also processing
> the data (and then you need to control that somehow).
>
> Other ideas? what else can you do with GPFS and local disks than what you
> considered? I suppose nothing reasonable ...
>
>
> Mit freundlichen Grüßen / Kind regards
>
>
> Dr. Uwe Falke
>
> IT Specialist
> High Performance Computing Services / Integrated Technology Services /
> Data Center Services
> ------------------------------------------------------------
> ------------------------------------------------------------
> -------------------
> IBM Deutschland
> Rathausstr. 7
> 09111 Chemnitz
> Phone: +49 371 6978 2165
> Mobile: +49 175 575 2877
> E-Mail: uwefalke at de.ibm.com
> ------------------------------------------------------------
> ------------------------------------------------------------
> -------------------
> IBM Deutschland Business & Technology Services GmbH / Geschäftsführung:
> Frank Hammer, Thorsten Moehring
> Sitz der Gesellschaft: Ehningen / Registergericht: Amtsgericht Stuttgart,
> HRB 17122
>
>
>
>
> From:   "Oesterlin, Robert" <Robert.Oesterlin at nuance.com>
> To:     gpfsug main discussion list <gpfsug-discuss at spectrumscale.org>
> Date:   11/30/2016 03:34 PM
> Subject:        [gpfsug-discuss] Strategies - servers with local SAS disks
> Sent by:        gpfsug-discuss-bounces at spectrumscale.org
>
>
>
> Looking for feedback/strategies in setting up several GPFS servers with
> local SAS. They would all be part of the same file system. The systems are
> all similar in configuration - 70 4TB drives.
>
> Options I?m considering:
>
> - Create RAID arrays of the disks on each server (worried about the RAID
> rebuild time when a drive fails with 4, 6, 8TB drives)
> - No RAID with 2 replicas, single drive per NSD. When a drive fails,
> recreate the NSD ? but then I need to fix up the data replication via
> restripe
> - FPO ? with multiple failure groups -  letting the system manage replica
> placement and then have GPFS due the restripe on disk failure
> automatically
>
> Comments or other ideas welcome.
>
> Bob Oesterlin
> Sr Principal Storage Engineer, Nuance
> 507-269-0413
>
>  _______________________________________________
> gpfsug-discuss mailing list
> gpfsug-discuss at spectrumscale.org
> http://gpfsug.org/mailman/listinfo/gpfsug-discuss
>
>
>
>
> _______________________________________________
> gpfsug-discuss mailing list
> gpfsug-discuss at spectrumscale.org
> http://gpfsug.org/mailman/listinfo/gpfsug-discuss
>



-- 
Zach Giles
zgiles at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20161130/26857f7a/attachment-0002.htm>