Interesting.
But why bothering with making your ypserv clustered, as, clients, when
configured in non broadcast or ypset mode
(Unix : /var/lib/yp/binding/ypservers, Linux: /etc/yp.conf) are able to
automatically and almost instantaneously switch to a slave server.
With this kind of setup, which is the most common I have seen in a lot
of companies (managing thousands of Unix/Linux servers), the only thing
to care about is to promote a slave server by regenerating the maps by
changing the Makefile and run a single make.
On Thu, 2010-05-20 at 13:48 -0400, bergman@xxxxxxxxxxxx wrote:
> Here are some brief notes on using RHCS to cluster an NIS (ypserv) master.
> These are intended mainly as search-engine fodder, in case anyone is looking
> for info on the same process in the future.
>
> NIS was written long, long before HA clustering. The NIS utilities
> make assumptions about hostnames that conflict badly with RHCS. In
> particular, the use of a virtual IP (for example, vdirectory) to separate
> the NIS server from a single physical machine breaks because the name
> returned by gethostbyname (for example, "server1" or "server2") differs
> from the virtual server. There's no way to instruct the NIS processes (yperv,
> yppush, etc.) to communicate over specified interfaces.
>
> This difference between the VIP name that should be associated with the NIS
> service and the name of the physical server comes up in several places:
>
> [1] When running "ypinit -m" to initialize the NIS master,
> the hostname of the master server is queried by the yphelper
> program within /var/yp/Makefile and that value is encoded into the
> DBM map files. This means that, for example, "server1" would be encoded
> in the NIS maps. If the NIS (ypserv) process fails over to the other
> cluster node ("server2"), then NIS clients will refuse to accept updates,
> since they appear to come from the machine "server2", even if the VIP
> for the directory service ("vdirectory") also fails over to server2.
>
> This can be circumvented by editing the /var/yp/Makefile to avoid using
> yphelper, but to instead specify the name of the virtual server
> ("vdirectory"), as in changing from:
> DBLOAD = $(YPBINDIR)/makedbm -c -m `$(YPBINDIR)/yphelper --hostname`
> to:
> DBLOAD = $(YPBINDIR)/makedbm -c -m vdirectory.fqdn
>
>
> [2] The yppush program compares the value of gethostbyname on the server to
> the name of the master server encoded in the DBM files. Since
> they will not be equal, maps will not be pushed to clients. The
> /var/yp/Makefile can be set not to push maps to clients (which
> is actually the default), and NIS clients can poll the server to
> retrieve maps.
>
> In our case, I created a "ypxfr-all" script to enumerate and transfer maps
> using ypxfr, and modified /var/yp/Makefile to connect to each NIS slave
> and trigger the slave to request maps from the master.
>
>
>
> I hope this helps someone.
>
> Mark
>
>
>
> --
> Linux-cluster mailing list
> Linux-cluster@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/linux-cluster
--
Linux-cluster mailing list
Linux-cluster@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-cluster
