Article

Submitted by paca on 9 July 2008 - 10:49am.

No, they are same. (You can thing master and write replicas as multiple masters)
Information syncing between replicas, but theres could be small delay.
You can tune sync time at common and at attribute level.

You can tune common sync time as low as you want, so everything is syncing faster. this can lead problems when directory is under heavy modifications on all replcas at same time.

I would prefer to set most critical attributes to sync immediately right when they are changed. And leave common sync setting tuned at reasonable level.

Submitted by geoffc on 9 July 2008 - 11:43am.

Basically an eDirectory Master replica is in charge of partitioning, schema changes, and obituary processing for the partition. So for those processes there can be only one.

Having said that, a Uni I used to work at lost a server and in rebuilding it we did not notice that in one replica ring, we had three RW replicas, and no masters. (Sort of the easiest way to get there, delete the Master replica server from the tree, since the tools will not let you get into the situation where there is no Master for a parition). We ran for months in production, without noticing, and it was not an issue.

You need one Master per partition. Moving it takes about 2 seconds, irrespective of tree size. But for day to day operations it is almost immaterial.

Any RW replica can be promoted to a Master replica (probably a RO replica as well, but I am not sure). The only that cannot (well it can, but it would be intensely stupid to do so) be promoted to a master is a Subordinate reference replica. (A Sub Ref basically stores a pointer to other partitions and thus does not have any data, and if you make it a master, you will loose all the data in your replica ring. But you never would, and the tools make it hard to do so, even by accident).

Submitted by dbenjamin on 9 July 2008 - 12:31pm.

Welcome to eDirectory!

Here is a link to the different types of replicas: http://www.novell.com/documentation/edir873/index....

There can be only one Master replica. There can and should be additional Read/Write Replicas. "eDirectory can access and change object information in a read/write replica as well as the master replica. All changes are then automatically propagated to all replicas."

I think the Multi-Master that you are referring to would be like a Master and Read/Write replicas in eDirectory.

Most attributes in eDirectory are pre-tuned and often it is best to leave it that way. Passwords and name changes are synced immediately and phone numbers and addresses wait. If you are expanding the schema then maybe you would need to change or set the times on those attributes.

Submitted by Rama1509 (not verified) on 10 July 2008 - 11:01pm.

Hi All,

Thanks for your responses.
Let me explain my question once again more clearly.My question is that:
How you achieve Master-Master for a database which is 100% repliacted (ie,.. in eDirectory terms both partition and original db has same data)?
This is our requirement:
--Any time in the network,I need two Masters Up (Same database mastered by two servers) and running with same functionality for the use by users and applications(like Access and Identity Manager)
--Even if one is down the other should automatically be able to serve all the users without making any difference in availibilty.

This is what I am asking for..This feature is available with RHDS.Please tell me whether we can achieve this with eDirectory as well (without any manual configurations like making a R/W or Read only as master if Master is down).
Thanks in advance.

Submitted by geoffc on 11 July 2008 - 9:05am.

I think the point everyone has been trying to make is that what eDirectory calls a Master is not a Master in the sense you are thinking of... That is, a RW replica and a Master replica differ basically only in the aspects mentioned above. Those things (Schema, partitioning, (obits are a slightly different story that I will ignore for a moment for simplicity)) that they differ in, should be rare events and not matter in a production system that is doing LDAP searches and updates.

So, then you can have as many RW replicas as you want, and they will function identically (minus our exceptions that are mostly immaterial) as Master replicas.

Now, your specific request is about availability. Does your Red Hat version use one IP address that is load balanced across multiple servers, and watches for a box failing? Whatever you use to front end that, should work for the most part across eDirectory.

There will be a slight delay for replication of changes between replicas, but unless you need within the second updates (In which case, change schema to mark the attrs you care about SYNC_IMMEDIATE) it should be ok.

Submitted by Rama1509 on 13 July 2008 - 9:57pm.

Thanks geoffc for your valuable input.One more question.If a master in edrirectory replica ring is down,can the users of that partition be able to authenticate to a R/W replica?
This is our main motive for opting a Multi-Master thing.Bcos in the admin guide,this edirectory object authentication is given in the functions list of Master.So I thought that if Master is down users of access manager cant get authenticated unless we bring the master up...
Is it like that?
--According to my understanding,from a R/W replica I think we can do updates on present data.
--Is adding a new entry to R/W replica possible ?
Kindly clarify.Thanks for all for being patient with me...

Submitted by geoffc on 14 July 2008 - 11:19am.

If the master replica server is not currently running, you can definitly authenticate to the tree via a RW replica.

The caveat to that is that you need to make sure that you have IP names/addresses set up in such a way that the client finds a replica that is running.

If it is an LDAP bind, you can put it behind some kind of load balancer. If it is an NCP bind, Client 32 should be smart enough to find a running server with a replica.

If it is Access Manager, I am not sure if you can specify either a load balanced eDir replica, a round robin, or if it has something else built in. (I.e. Provide a list of 3 servers to use for Auth). I would have to defer to someone with more knowledge of Access Manager.

As I said earlier in this thread, we ran at a Uni for months without a Master replica, and no one noticed. I.e. We logged in hundreds if not thousands of students, and added, and deleted students as needed on a regular basis.

So yes, a RW can be read and written too. A Read only replica is basically useless as you can only read from it. A master gets some extra specail roles, but otherwise is nothing different.

If one server is down, the changes will be replicated to it, when it returns to service. Deletes/Renames/move events are all specail cases that will pile up stuck obituaries, which normally are not a big deal, until the server comes back up.

Submitted by macleajb on 14 July 2008 - 3:44pm.

I wish it was always that easy for me. Sure, if you do some fancy rules you can pretend that another server is the R/W for the failed server that a client wants to authenticate to but:

1. The client doesn't always pick the same R/W. There are rules the client uses for choosing it, but I have not had much luck predicting them. So any R/W may be used for authentication and yes the gurus can explain why the Master tends to be the R/W of choice. I know about the cost client parms, but when eveything is on the same subnet, or you have more then 2 R/Ws...

2. When the master goes down, prey you get it back and also cross you fingers that it gets all its updates that it is missing. Sounds easy enough in theory, and our site is no huge Uni, but we've had to get Novell in at least once a year when the partitions don't want to play together. There appears to be no fix-it-yourself process once the messages/updates get stuck.

3. I have never tried to fully fake the Master's IP to redirect to another R/W, but it would seem to me that the NDS would start trying to update/act upon the transient R/W IP as a Master. Maybe no harm except for the extra traffic, but that can not be good for the NDS's health either? Also, maybe the suggestion is that every important master be clustered? Perhaps.

4. If you have a local R/W down the tree on a partition, and even one call requires something not off that branch, then bang, up to the top you go looking for your object/attribs, and if you think that doesn't happen that often, then you are not sharing resources between different groups/replicas as departments do in business.

5. Then try doing a Unix NCPMount through a filtered path. Which servers do you allow the Unix client to see? But that doesn't work either becaue the login procedure includes the client being told which IP to get it's credentials negotiated with and, at least in our environment, that is not a constant. If a private IP is passed, you just won't get there easily to authenticate.

Yes, certainly, it's all doable, and many of us are doing parts/all of it. But I can not make the same offer that it is as simple as faking an IP.... Sorry :(.

Submitted by geoffc on 15 July 2008 - 11:28am.

The feeling I got from the original poster has to do with using eDirectory as an LDAP directory.

Most of the things talked about are NCP related and how the various clients (Client 32, NCPmount, and Client for Linux) handle a server going down.

If you are using eDirectory as an LDAP store, then your application controls which replica it talks too.

Changes syncing between master and replica as the box goes down gets into a level of complexity that no doubt there are terrible cases you can run into. But my experience at a large Uni was actually that it was pretty robust! Which was good. :) However I concede that you can still get into trouble!!