Folks,
I'm currently planning a shift in our use of LDAP to incorporate mirror mode masters for the sake of high availability. The plan is to hide a mirror mode master pair behind a virtual IP using "sorry server" fail-over, such that the primary mirror server takes 100% of the load when it's up and responsive, with fall-back to the secondary mirror server when the primary is down. In this way, the virtual IP presents a "virtual master" to the outside world, and the plan is for *all* outside LDAP interaction with the masters to happen over this single virtual IP.
There will be other "slave" servers which replicate the master (to distribute read-only load), and the plan is for them to syncrepl from the master virtual IP. I gather that a possible alternative to this arrangement is to have the "slave" servers act as syncrepl consumers to *both* masters simultaneously, via their real IP addresses. If this is indeed a valid configuration, does it convey any advantages? The single "virtual master" approach seems architecturally simpler, but is it considered robust by those in the know?
Thanks in advance.
On Wed, 14 Mar 2012, Brett Watson wrote:
I'm currently planning a shift in our use of LDAP to incorporate mirror mode masters for the sake of high availability. The plan is to hide a mirror mode master pair behind a virtual IP using "sorry server" fail-over, such that the primary mirror server takes 100% of the load when it's up and responsive, with fall-back to the secondary mirror server when the primary is down. In this way, the virtual IP presents a "virtual master" to the outside world, and the plan is for *all* outside LDAP interaction with the masters to happen over this single virtual IP.
There will be other "slave" servers which replicate the master (to distribute read-only load), and the plan is for them to syncrepl from the master virtual IP. I gather that a possible alternative to this arrangement is to have the "slave" servers act as syncrepl consumers to *both* masters simultaneously, via their real IP addresses. If this is indeed a valid configuration, does it convey any advantages? The single "virtual master" approach seems architecturally simpler, but is it considered robust by those in the know? Thanks in advance.
Well, people test this quite regularly (via OpenLDAP's included test suite) and it seems to work without issue; there are also live sites using mirrormode and (anecdotally) I don't believe they have an excessive defect rate versus other installations.
As with most the-other-node-must-be-dead scenarios, the ugly edge cases rest more on the traffic direction methods than the actual application. You'd probably be well served by taking a careful stock of your "virtual IP" methods -- split brain, false positives, what have you -- and OpenLDAP will likely serve you well.
Excerpts from Brett Watson's message of 2012-03-13 23:31:10 -0700:
I'm currently planning a shift in our use of LDAP to incorporate mirror mode masters for the sake of high availability. The plan is to hide a mirror mode master pair behind a virtual IP using "sorry server" fail-over, such that the primary mirror server takes 100% of the load when it's up and responsive, with fall-back to the secondary mirror server when the primary is down. In this way, the virtual IP presents a "virtual master" to the outside world, and the plan is for *all* outside LDAP interaction with the masters to happen over this single virtual IP.
There will be other "slave" servers which replicate the master (to distribute read-only load), and the plan is for them to syncrepl from the master virtual IP. I gather that a possible alternative to this arrangement is to have the "slave" servers act as syncrepl consumers to *both* masters simultaneously, via their real IP addresses. If this is indeed a valid configuration, does it convey any advantages? The single "virtual master" approach seems architecturally simpler, but is it considered robust by those in the know?
At my site, the replicas are configured to consume updates directly from both masters simultaneously, bypassing the VIP used by other traffic. Configuring replicas to bypass the VIP means that replication and replica consistency aren't dependent on the failover behavior of the VIP, which makes it easier to reason accurately about the impact of a failure.
Our mirrormode setup is essentially the one you propose for your site, and it works well for our needs.
Dear Aaron,
On 14/03/12 09:58 -0400, Aaron Richton wrote:
On Wed, 14 Mar 2012, Brett Watson wrote:
I'm currently planning a shift in our use of LDAP to incorporate mirror mode masters for the sake of high availability. The plan is to hide a mirror mode master pair behind a virtual IP using "sorry server" fail-over, such that the primary mirror server takes 100% of the load when it's up and responsive, with fall-back to the secondary mirror server when the primary is down. In this way, the virtual IP presents a "virtual master" to the outside world, and the plan is for *all* outside LDAP interaction with the masters to happen over this single virtual IP.
There will be other "slave" servers which replicate the master (to distribute read-only load), and the plan is for them to syncrepl from the master virtual IP. I gather that a possible alternative to this arrangement is to have the "slave" servers act as syncrepl consumers to *both* masters simultaneously, via their real IP addresses. If this is indeed a valid configuration, does it convey any advantages? The single "virtual master" approach seems architecturally simpler, but is it considered robust by those in the know? Thanks in advance.
Well, people test this
Test what? Replicating from the VIP to the slaves or replicating from both masters to the slaves?
quite regularly (via OpenLDAP's included test suite) and it seems to work without issue; there are also live sites using mirrormode and (anecdotally) I don't believe they have an excessive defect rate versus other installations.
As with most the-other-node-must-be-dead scenarios, the ugly edge cases rest more on the traffic direction methods than the actual application. You'd probably be well served by taking a careful stock of your "virtual IP" methods -- split brain, false positives, what have you -- and OpenLDAP will likely serve you well.
On Thu, 15 Mar 2012, Nick Urbanik wrote:
Test what? Replicating from the VIP to the slaves or replicating from both masters to the slaves?
The VIP is out of band relative to OpenLDAP. Traffic direction is assumed to exist, apart from OpenLDAP Software, so you won't find code/tests on point within OpenLDAP. But replication, including starting back up after a failure, is covered in the test suite. See, for example, test050 and test063.
Kevan,
Kevan Carstensen schrieb (14.03.2012 17:21 Uhr):
Excerpts from Brett Watson's message of 2012-03-13 23:31:10 -0700:
There will be other "slave" servers which replicate the master (to distribute read-only load), and the plan is for them to syncrepl from the master virtual IP. I gather that a possible alternative to this arrangement is to have the "slave" servers act as syncrepl consumers to *both* masters simultaneously, via their real IP addresses. If this is indeed a valid configuration, does it convey any advantages? The single "virtual master" approach seems architecturally simpler, but is it considered robust by those in the know?
At my site, the replicas are configured to consume updates directly from both masters simultaneously,
How do you achieve this? With two syncrepl statements in one database, are there any downsides, like doing all replication (checks) twice?
Marc
openldap-technical@openldap.org
-
Aaron Richton -
Brett Watson -
Kevan Carstensen -
Marc Patermann -
Nick Urbanik