Hello Latha,

Here are the answers to your questions:

a) Depends on the ldap client application's needs: 1. If the client application(s) need data consistency and immediate data availability its better to go for 4 way peer (or master) topology. In this case updates made onto any master will reach any consumer in 1 hop. 2. If network bandwidth savings is the goal then the choice would be to use 1 master and 1 gateway per site, the gateway servers on both sites will replicate to each others. In this case the updates made directly to any gateway may take 1 hop to reach its peer gate way and onsite master, and 2 hops to the other site's master. In addition updates made directly to a master will take 1 hop to reach its onsite gateway, 2 hops to reach other site's gateway and 3 hops to reach other site's master.

b) If you consider case 1 of having all masters then you'll need to set up 3 replication agreements (each agreement represents a replication queue) from each master going to other 3 masters. If you consider case 2, then you'll have 2 replication agreements on each gateway server going to its onsite master and other site's gateway, and 1 replication agreement going from a master to its onsite gateway.

c) According to the picture presented, you need to configure the servers replicating across sites as gateway servers. Gateway configuration is a well supported configuration. The advantage is network bandwidth savings. Disadvantages include it may take more hops which may affect critical applications that may look for data consistency across sites and downtime on any gateway affects cross site replication.

Now a days, the network bandwidth is cheaper, so most of our customers prefer to use multi master setup as explained in case 1.

I hope this answers your questions.

Thanks,

Ram.

Hello Latha,

Here are the answers to your questions:

a) Depends on the ldap client application's needs: 1. If the client application(s) need data consistency and immediate data availability its better to go for 4 way peer (or master) topology. In this case updates made onto any master will reach any consumer in 1 hop. 2. If network bandwidth savings is the goal then the choice would be to use 1 master and 1 gateway per site, the gateway servers on both sites will replicate to each others. In this case the updates made directly to any gateway may take 1 hop to reach its peer gate way and onsite master, and 2 hops to the other site's master. In addition updates made directly to a master will take 1 hop to reach its onsite gateway, 2 hops to reach other site's gateway and 3 hops to reach other site's master.

b) If you consider case 1 of having all masters then you'll need to set up 3 replication agreements (each agreement represents a replication queue) from each master going to other 3 masters. If you consider case 2, then you'll have 2 replication agreements on each gateway server going to its onsite master and other site's gateway, and 1 replication agreement going from a master to its onsite gateway.

c) According to the picture presented, you need to configure the servers replicating across sites as gateway servers. Gateway configuration is a well supported configuration. The advantage is network bandwidth savings. Disadvantages include it may take more hops which may affect critical applications that may look for data consistency across sites and downtime on any gateway affects cross site replication.

Now a days, the network bandwidth is cheaper, so most of our customers prefer to use multi master setup as explained in case 1.

I hope this answers your questions.

Thanks,

Ram.

Interesting Discussion !

If you don't mind, let me expand the complexity just a tiny bit. Would like to address some other associated themes as well and share some concerns / trade-off discussion.

My scenario is a requirement to support a second but also a 3rd replicated site.

At all cost, we want only onsite LDAP clients to consume LDAP services available in that replicated site. Each site would be running a master to master LDAP server pair for onsite local HA support. Overall, we do not want any LDAP clients within a site to connect to LDAP services available of other 2 (n) sites.

With a 3^rd site, without a Gateway server configuration within each site, I am concerned that the number of replicated agreements overall (between masters within each site and between them and each other masters in other sites) will just become unmanageable. Although the replication agreement will connect directly to every other master, thus lowering number of hops, we will have more replication queues processing in parallel. This could (or not) offset the benefit of less hops in the case that more parallel queue processing somewhat adds latency. Comments ?

Although it is true that a Gateway server configuration within each site adds an extra hop for data replication, the extra cost hop does not increase anymore beyond that 2nd site with gateway replication in each site.

But as you pointed out, the local Gateway server configuration in each site introduces a single point of failure for data replication across sites but given that we opt to only have onsite LDAP clients consume LDAP services within a site, I'm less concerned with data consistency issues latency that could arise if they last a (couple) minute or so for small data updates (not large bulk upload) to be replicated between all sites.

One of the reasons I am trying to exclude onsite LDAP clients to reach services within other sites is to try reducing spaghetti infrastructure. Also, an LDAP client often will use some form of DNS resolution caching so should the IP address for reaching global LDAP services would be updated (as a result of onsite service unavailability), because of the cached dns entries in the LDAP client process (JVM for instance), this will likely prevent that client from picking up the updated IP  address (maintaining the unavailability condition). A manual intervention is then required to restart LDAP clients so that they can pick up the updated LDAP connect information. Although some LDAP clients can support numerous LDAP server entries (such as ISAM in ldap.conf), most other generic LDAP clients will feature only one configuration entry for connecting to LDAP services. Comments ?

I'm curious to know how IBM or other clients are dealing with the single point of failure possibility around the Gateway replication setup in each site (easy to restore backup VM image of that ISDS Suite image, quick monitoring/alerting, …) to compensate for that possibility of unavailability.

Glad to hear to Gateway replication is well support configuration.

Hello Latha,

Here are the answers to your questions:

a) Depends on the ldap client application's needs: 1. If the client application(s) need data consistency and immediate data availability its better to go for 4 way peer (or master) topology. In this case updates made onto any master will reach any consumer in 1 hop. 2. If network bandwidth savings is the goal then the choice would be to use 1 master and 1 gateway per site, the gateway servers on both sites will replicate to each others. In this case the updates made directly to any gateway may take 1 hop to reach its peer gate way and onsite master, and 2 hops to the other site's master. In addition updates made directly to a master will take 1 hop to reach its onsite gateway, 2 hops to reach other site's gateway and 3 hops to reach other site's master.

b) If you consider case 1 of having all masters then you'll need to set up 3 replication agreements (each agreement represents a replication queue) from each master going to other 3 masters. If you consider case 2, then you'll have 2 replication agreements on each gateway server going to its onsite master and other site's gateway, and 1 replication agreement going from a master to its onsite gateway.

c) According to the picture presented, you need to configure the servers replicating across sites as gateway servers. Gateway configuration is a well supported configuration. The advantage is network bandwidth savings. Disadvantages include it may take more hops which may affect critical applications that may look for data consistency across sites and downtime on any gateway affects cross site replication.

Now a days, the network bandwidth is cheaper, so most of our customers prefer to use multi master setup as explained in case 1.

I hope this answers your questions.

Thanks,

Ram.