<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 07/09/2015 01:54 PM, Lars Marowsky-Bree wrote:<br>
<blockquote cite="mid:20150709085427.GK3309@suse.de" type="cite">
<pre wrap="">On 2015-07-07T14:15:14, Muhammad Sharfuddin <a class="moz-txt-link-rfc2396E" href="mailto:M.Sharfuddin@nds.com.pk"><M.Sharfuddin@nds.com.pk></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">now msgwait timeout is set to 10s and a delay/inaccessibility of 15 seconds
was observed. If a service(App, DB, file server) is installed and running
from the ocfs2 file system via the surviving/online node, then
wouldn't that service get crashed or become offline due to the
inaccessibility of the file system(event though its ocfs2) while a member
node goes down ?
</pre>
</blockquote>
<pre wrap="">
You're seeing a trade-off of using OCFS2. The semantics of the file
system require all accessing nodes to be very closely synchronized (that
is not optional), and that requires the access to the fs to be paused
during recovery. (See the CAP theorem.)
The apps don't crash, they are simply blocked. (To them it looks like
slow IO.)
The same is true for DRBD in active/active mode; the block device is
tightly synchronized, and this requires both nodes to be up, or cleanly
reported as down.
</pre>
<blockquote type="cite">
<pre wrap="">If cluster is configured to run the two independent services, and starts one
on node1 and ther on node2, while both the service shared the same file
system, /sharedata(ocfs2), then in case of a failure of one node, the
other/online wont be able to
keep running the particular service because the file system holding the
binaries/configuration/service is not available for around at least 15
seconds.
I don't understand the advantage of Ocfs2 file system in such a setup.
</pre>
</blockquote>
<pre wrap="">
If that's your setup, indeed, you're not getting any advantages. OCFS2
makes sense if you have services that indeed need access to the same
file system and directory structure.
If you have two independent services, or even services that are
essentially node local, you're much better off using independent,
separate file system mounts with XFS or extX.
Regards,
Lars
</pre>
</blockquote>
<font size="1">Thanks for keeping this thread alive and the
explanation share.<br>
<br>
Sorry, I didn't understand, at one point you wrote:<br>
a - The apps don't crash, they are simply blocked.<br>
<br>
while on the other you wrote:<br>
b - If that's your setup, indeed, you're not getting any
advantages.<br>
<br>
If the service configured to run on the node, which survives /
remains online, but get blocked(due to slow I/O) and <br>
eventually becomes healthy after like 30 seconds, then its also
acceptable. E.g a user is connected to the service <br>
via a client app, that was running on a node that will remain
online, and the other member goes down, that client app wont <br>
get the response from service till next 35 seconds, but the
queries client has executed or information that was being <br>
uploaded at the time when the other member goes down, wont be lost
as the service will resume shortly, isn't ?<br>
<br>
<br>
--<br>
Regards,<br>
<br>
</font>
<font size="2">Muhammad Sharfuddin</font><br>
</body>
</html>