Re: clustered MD

[David Teigland]

On Wed, Jun 10, 2015 at 10:27:27AM -0500, Goldwyn Rodrigues wrote:
> I thought I answered that:
> To use a software RAID1 across multiple nodes of a cluster. Let me
> explain in more words..
> 
> In a cluster with multiple nodes with a shared storage, such as a
> SAN. The shared device becomes a single point of failure.

OK, shared storage, that's an important starting point that was never
clear.

> If the
> device loses power, you will lose everything. A solution proposed is
> to use software RAID, say with two SAN switches with different
> devices and create a RAID1 on it. So if you lose power on one switch
> or one of the device is fails the other is still available. Once you
> get the other switch/device back up, it would resync the devices.

OK, MD RAID1 on shared disks.

> >, and exactly
> >what breaks when you use raid1 in that way?  Once we've established the
> >technical problem, then I can fairly evaluate your solution for it.
> 
> Data consistency breaks. If node 1 is writing to the RAID1 device,
> you have to make sure the data between the two RAID devices is
> consistent. With software raid, this is performed with bitmaps. The
> DLM is used to maintain data consistency.

What's different about disks being on SAN that breaks data consistency vs
disks being locally attached?  Where did the dlm come into the picture?

> Device failure can be partial. Say, only node 1 sees that one of the
> device has failed (link break).  You need to "tell" other nodes not
> to use the device and that the array is degraded.

Why?

> In case of node failure, the blocks of the failed nodes must be
> synced before the cluster can continue operation.

What do cluster/node failures have to do with syncing mirror copies?

> Does that explain the situation?

No.  I don't see what clusters have to do with MD RAID1 devices, they seem
like completely orthogonal concepts.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/