<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<blockquote cite="mid:1281658030.3527.39.camel@newgen.localdomain"
 type="cite">
  <blockquote type="cite">
    <pre wrap="">Absolutely, RHCS != IPVS ... I do got that, sorry for my mis-stating it as such.

My response and focus should not have been squarely on IP takeover and/or load-balancing -- as I was not even thinking (strangely) that CMAN was even part of Ana's question (how the {bleep} did I come to that?)  It could very well be in play, and that it might be an issue considering its LAN requirements.  My bad comes from our tendancies to only implement RHCS for IPVS only; and all that it offers in cman, fencing, clvmd, rgmanager, et al is only configured & started when we have GFS / GFS2 filesystems in play.

Slightly OT, I have "heard" that multicasting can be routed -- is that true, and if so, couldn't cman then work on different subnets?  Or is there some other constriction or no-no besides "best practices" that I am missing?  And I know you cannot have a node playing in two clusters, despite configuring it to meet network requirements, which could be construed as a shame.

    </pre>
  </blockquote>
  <pre wrap=""><!---->CMAN relies on multicast that can be routed indeed, but the services IP
address (in the HA world) are in general unicast IP addresses. How would
you manage these IP failover if on different subnets ?
  </pre>
</blockquote>
When a company owns an AS number and a Provider Independent subnet, it
is possible to announce via BGP that subnet via 2 separate geographical
sites, while running a separate subnet for each site; the active site
would announce it normally and the
backup/failover site would announce it by prepending it's own AS number
to the AS_PATH attribute. Therefore, if the main site fails, IP traffic
would go to the only remaining option, the backup/failover site. But
this is more related to IP routing then anything else.<br>
<br>
My 2c.<br>
<blockquote cite="mid:1281658030.3527.39.camel@newgen.localdomain"
 type="cite">
  <pre wrap=""> 
  </pre>
  <blockquote type="cite">
    <pre wrap="">Ok, have a good night!  Myself, I am off to the first tee ... :)


-----Original Message-----
From: <a class="moz-txt-link-abbreviated"
 href="mailto:linux-cluster-bounces@redhat.com">linux-cluster-bounces@redhat.com</a> [<a
 class="moz-txt-link-freetext"
 href="mailto:linux-cluster-bounces@redhat.com">mailto:linux-cluster-bounces@redhat.com</a>] On Behalf Of Laszlo Beres
Sent: Thursday, August 12, 2010 3:06 PM
To: linux clustering
Subject: Re: [Linux-cluster] RHCS separate datacenter

On Thu, Aug 12, 2010 at 8:35 PM,  <a class="moz-txt-link-rfc2396E"
 href="mailto:rhurst@bidmc.harvard.edu"><rhurst@bidmc.harvard.edu></a> wrote:

    </pre>
    <blockquote type="cite">
      <pre wrap="">stretches a 100 inches or a 100 miles.  I think Ana should reveal more 
about her implementation rather than hearing about yours.  ;)
      </pre>
    </blockquote>
    <pre wrap="">Cannot agree more :)

    </pre>
    <blockquote type="cite">
      <pre wrap="">And what part of what I said is "false"?  I didn't say anything that fail-over AND load-balancing were required.  Fail-over can be achieved in numerous ways and without RH supplied tools; the load-balancing is native to Linux using IPVS.  But back to the original question: will Red Hat support ... ?  If you use your OWN fail-over strategy, you OWN it.
      </pre>
    </blockquote>
    <pre wrap="">It was your statement "RHCS is IPVS" that I felt false.

    </pre>
    <blockquote type="cite">
      <pre wrap="">Yes, OpenAIS (and likewise the former pulse on RHEL4, sorry for dating myself) is for fail-over which (either) can operate on different LANs.  And to my knowledge and not practical use, the load-balancing (IPVS) can work on different LANs -- if the tunneling option is used.  But my point was that I have not seen any implementation that also maintains IPVS client-session tracking on DIFFERENT LANs (which is NOT a problem if it is on the same physical LAN, like your setup).  It is that last point that has obvious implications on the scope and objectives for those seeking a "supportable" Linux-based solution.
      </pre>
    </blockquote>
    <pre wrap="">I'm afraid there's still a misunderstanding there - either on my or your side.

Pulse was and is a mechanism to ensure a heartbeat channel between two ipvs primary and backup routers. Pulse never had anything to do in the failover cluster core (which is cman in RHEL4, or OpenAIS starting with RHEL5). cman is not supported to be operated on different subnets.

    </pre>
    <blockquote type="cite">
      <pre wrap="">Have a great day!
      </pre>
    </blockquote>
    <pre wrap="">Rather night here in Europe ;)

--
László Béres            Unix system engineer <a
 class="moz-txt-link-freetext"
 href="http://www.google.com/profiles/beres.laszlo">http://www.google.com/profiles/beres.laszlo</a>

--
Linux-cluster mailing list
<a class="moz-txt-link-abbreviated"
 href="mailto:Linux-cluster@redhat.com">Linux-cluster@redhat.com</a>
<a class="moz-txt-link-freetext"
 href="https://www.redhat.com/mailman/listinfo/linux-cluster">https://www.redhat.com/mailman/listinfo/linux-cluster</a>

--
Linux-cluster mailing list
<a class="moz-txt-link-abbreviated"
 href="mailto:Linux-cluster@redhat.com">Linux-cluster@redhat.com</a>
<a class="moz-txt-link-freetext"
 href="https://www.redhat.com/mailman/listinfo/linux-cluster">https://www.redhat.com/mailman/listinfo/linux-cluster</a>
    </pre>
  </blockquote>
  <pre wrap=""><!---->

--
Linux-cluster mailing list
<a class="moz-txt-link-abbreviated"
 href="mailto:Linux-cluster@redhat.com">Linux-cluster@redhat.com</a>
<a class="moz-txt-link-freetext"
 href="https://www.redhat.com/mailman/listinfo/linux-cluster">https://www.redhat.com/mailman/listinfo/linux-cluster</a></pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">-- 
Dan FRINCU
Systems Engineer
CCNA, RHCE
Streamwide Romania
</pre>
</body>
</html>