Bug 1251462 - [rfe] Identify which path of the mirror was the last to be modified
[rfe] Identify which path of the mirror was the last to be modified
Status: CLOSED CANTFIX
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: lvm2 (Show other bugs)
6.8
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Heinz Mauelshagen
cluster-qe@redhat.com
:
Depends On:
Blocks: 1172231
  Show dependency treegraph
 
Reported: 2015-08-07 07:33 EDT by Javier Ramirez
Modified: 2015-08-21 12:08 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-08-21 12:08:10 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Javier Ramirez 2015-08-07 07:33:41 EDT
In the following scenario (HA cluster storage split):

RHEL 6.6 stretch cluster with lvm2-2.02.111-2.el6_6.1.x86_64 using lvm mirror with segment_type=raid1

- Service running in node1
- The storage that becomes split. 
The cluster is happy because quorum is maintained. Granted, only one side will be running and there is no corruption yet.
- But the service could be relocated to the other side for any number of reasons.  
- Both sites believe the disk from the other site has failed and both sites have changed the contents of their storage.

There are ways to avoid this scenario from resource manager point of view, for instance using partial_activation in pacemaker lvm resource agent, but is there a way to prevent this from a storage point of view?

What if the service is stopped and need to be started while the storage is still split, how can we identify which path of the mirror was the last to be modified?
Comment 5 Jonathan Earl Brassow 2015-08-13 16:48:35 EDT
I want to point out that if a storage (but not cluster) split is a concern, multipathing should be employed to ensure redundancy of the storage connections.

Note You need to log in before you can comment on or make changes to this bug.