<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Please don't top-post, it makes the
thread harder to read (ie, harder to help you).<br>
<br>
On 08/07/16 02:01, James Ault wrote:<br>
</div>
<blockquote
cite="mid:CAOKkDvD6Emm82jV5o2cH3KygJY4BJGC7ets1be4xn9HgqrLXzQ@mail.gmail.com"
type="cite"><br>
</blockquote>
<br>
<br>
<blockquote
cite="mid:CAOKkDvD6Emm82jV5o2cH3KygJY4BJGC7ets1be4xn9HgqrLXzQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_default"
style="font-family:verdana,sans-serif"><br>
</div>
</div>
<div class="gmail_extra"><br clear="all">
<div>
<div class="gmail_signature" data-smartmail="gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">
<div>-James Ault, <a moz-do-not-send="true"
href="http://www.linkedin.com/in/aultj/"
target="_blank">http://www.linkedin.com/in/aultj/</a>
<a moz-do-not-send="true"
href="http://tinyurl.com/link2jimault"
target="_blank">http://tinyurl.com/link2jimault </a><br>
</div>
<div><a moz-do-not-send="true"
href="http://www.bornofthespirit.today/"
target="_blank">Life's Biggest Decision is...</a><br>
</div>
<div><br>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
<div class="gmail_quote">On Thu, Jul 7, 2016 at 10:48 AM, Lars
Ellenberg <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:lars.ellenberg@linbit.com" target="_blank">lars.ellenberg@linbit.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb">
<div class="h5">On Thu, Jul 07, 2016 at 07:16:51AM -0400,
James Ault wrote:<br>
> Here is a scenario:<br>
><br>
> Two identical servers running RHEL 6.7,<br>
> Three RAID5 targets, with one Logical volume group
and one logical volume<br>
> defined on top of each target.<br>
> A DRBD device defined on top of each logical
volume, and then an XFS file<br>
> system defined on top of each DRBD device.<br>
><br>
> The two identical servers are right on top of one
another in the rack, and<br>
> connected by a single ethernet cable for a private
network.<br>
><br>
> The configuration works as far as synchronization
between DRBD devices.<br>
><br>
> We do NOT have pacemaker as part of this
configuration at management's<br>
> request.<br>
><br>
> We have the XFS file system mounted on server1, and
this file system is<br>
> exported via NFS.<br>
><br>
> The difficulty lies in performing failover actions
without pacemaker<br>
> automation.<br>
><br>
> The file system is mounted, and those status flags
on the file system are<br>
> successfully mirrored to server2.<br>
><br>
> If I disconnected all wires from server1 to
simulate system failure, and<br>
> promoted server2 to primary on one of these file
systems, and attempted to<br>
> mount it, the error displayed is "file system
already mounted".<br>
><br>
> I have searched the xfs_admin and mount man pages
thoroughly to find an<br>
> option that would help me overcome this state.<br>
><br>
> Our purpose of replication is to preserve and
recover data in case of<br>
> failure, but we are unable to recover or use the
secondary copy in our<br>
> current configuration.<br>
><br>
> How can I recover and use this data without
introducing pacemaker to our<br>
> configuration?<br>
<br>
</div>
</div>
If you want to do manual failover (I believe we have that
also<br>
documented in the User's Guide), all you do is<br>
<br>
drbdadm primary $res<br>
mount /dev/drbdX /some/where<br>
<br>
That's also exactly what pacemaker would do.<br>
<br>
If that does not work,<br>
you have it either "auto-mounted" already by something,<br>
or you have some file system UUID conflict,<br>
or something else is very wrong.<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
</font></span></blockquote>
</div>
</div>
</blockquote>
<blockquote type="cite">
<div class="gmail_default" style="font-family:verdana,sans-serif">I
see the Manual Failover section of the DRBD 8.4.x manual, and I
see that it requires that the file system be umounted before
attempting to promote and mount the file system on the
secondary. <br>
<br>
</div>
</blockquote>
Assuming san1 is primary, and san2 is secondary.<br>
<br>
If you want to do a "nice" failover:<br>
a) on san1 stop whatever processes are "using" the filesystem (eg,
NFS, samba, etc...)<br>
b) on san1 umount the filesystem<br>
c) on san1 change DRBD resource to secondary<br>
d) on san2 change DRBD resource to primary<br>
e) on san2 mount the filesystem<br>
f) on san2 start whatever processes to export the filesystem (eg
NFS, samba, etc)<br>
<br>
<blockquote type="cite">
<div class="gmail_default" style="font-family:verdana,sans-serif">What
I meant by "those status flags" in my first message is that when
a node mounts a file system, that file system is marked as
mounted somewhere on that device. The "mounted" status flag is
what I'm trying to describe, and I'm not sure if I have the
correct name for it. <br>
</div>
</blockquote>
<br>
Me neither, and I'm not familiar with XFS at all, however, the
unclean failover looks like this:<br>
<br>
a) san1 crashes, on san2, it sees the remote is missing, and changes
to disconnected status<br>
b) on san2 change DRBD resource to primary<br>
c) on san2 mount the filesystem<br>
d) on san2 start whatever processes to export the filesystem (eg
NFS, samba, etc)<br>
<br>
As far as step (C), this would be an identical process as if you
were not using DRBD at all, and the machine had "crashed", and you
had rebooted it, and were now trying to mount the FS. ie, its just a
standard unclean mount. Maybe you need to run a fsck first, maybe
there is some other process, but generally, most FS's I've used, you
simply mount it and it will either "clean up" (if it is a journal
based FS) or continue as normal until it encounters some
corruption/error.<br>
<blockquote type="cite">Does pacemaker or manual failover handle the
case where a file server experiences a hard failure where the
umount operation is impossible? How can the secondary copy of
the file system be mounted if the umount operation never occurred
and cannot occur on server1?<br>
</blockquote>
<br>
Yes, pacemaker simply automates the above processes, so that the
decision to do the failover, and the actual failover process will
happen more quickly (hopefully before your clients/services notice
any interruption).<br>
<br>
BTW, have you actually tried it yet? You should definitely test a
number of scenarios, so if you have a scenario with a specific
problem, please provide a description of what you did, what commands
you tried, and the output of those commands so we can provide better
information.<br>
<br>
Hope that helps...<br>
<br>
<div class="moz-signature">-- <br>
Adam Goryachev
Website Managers
<a class="moz-txt-link-abbreviated" href="http://www.websitemanagers.com.au">www.websitemanagers.com.au</a></div>
</body>
</html>