[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Using virtual IP and N-way mutlimaster mode



On Tue, Jan 16, 2018 at 10:24:42AM +0400, Jephte Clain wrote:

> all nodes run with -h ldap:// and I have as many olcServerID as defined nodes
> my cn=config is also replicated  between all nodes
> 
> for example, I have:

> olcServerID: 1 ldap://ldapm3.univ.run/
> olcServerID: 2 ldap://ldapm4.univ.run/

> olcSyncrepl: {0}... rid=0 provider="ldap://ldapm3.univ.run/"; ...
> olcSyncrepl: {1}... rid=3 provider="ldap://ldapm4.univ.run/"; ...

There is an important variation of this problem when running cloud
machines in services like AWS. The actual machines have IPv4 addresses
in private address space - usually 10.x.x.x - but if you need to access
them from outside their own availability zone (datacentre) you must use
a different (public) IP address. The machines usually have hostnames of
the form ip-10-x-x-x and there is no way to resolve those globally.

So, we might have one server in each of three zones and need to set up
MMR between them:

Zone A:
Server IP: 10.21.0.1
Public IP: 134.82.17.63
Default hostname: ip-10-21-0-1

Zone B:
Server IP: 10.22.0.71
Public IP: 193.17.65.123
Default hostname: ip-10-22-0-71

Zone C:
Server IP: 10.35.0.5
Public IP: 7.45.81.52
Default hostname: ip-10-35-0-5

Not too much of a problem if each server has a separate config, but if
we want replicated configs it gets harder.

The first problem is that the private IP ranges used by the three zones
may overlap. Indeed, there are cases where the three servers could have
identical local IPs (and thus identical default hostnames).

Even without that, we have to cope with the fact that the servers are on
private addresses but have to contact each other using public addresses.

One option would be to set new hostnames on the servers and use those
to key into the appropriate config values. The hostnames would need to be
resolvable to public IP addresses so that the MMR config would work properly.
Does anything check that the hostname actually resolves to an IP address
bound to the server I wonder? Even if OpenLDAP is OK with that, it might
break something else running on the machine.

Another option would be to use the new hostnames in the -h URL list, but as has
already been mentioned this will fail because the server cannot bind to the
public IP.

What is best practice here? I am leaning towards *not* replicating config
because it makes some updates really hard (think changing the max size of
an MDB database without stopping all the servers at the same time). I still
like the idea that the config should be identical on all servers during
normal operation though.

[ Note that I am not considering the OP's virtual IP problem here, as
load-balancing/failover in this environment would be done separately ]

Andrew
-- 
-----------------------------------------------------------------------
|                 From Andrew Findlay, Skills 1st Ltd                 |
| Consultant in large-scale systems, networks, and directory services |
|     http://www.skills-1st.co.uk/                +44 1628 782565     |
-----------------------------------------------------------------------