Posted by: James Murray
In active directory multi-master replication is the key to a secure, successful and flexible network infrastructure.
In the early days of computing, there was the word processor.
A world processor is a device that allowed typists to fix mistakes in the computer before printing them to paper. If you’ve ever typed a document, typing errors is one of the biggest problems in business communication. Imagine typing a document by hand without making errors? Typists were measured by their speed and accuracy. A typist typing 100 words a minute with only 1 or 2 errors per page always had a job. So imagine now a device that allowed someone to type a document at 15 words per minute with 100% accuracy. This meant that the document didn’t need to be retyped. It was a revolution.
Then someone asked,
“…can we have a way of centralizing that document so that multiple people can work on that document?”
The first steps towards multi-master replication were taken. Multi-Master Replication is a method of database replication which allows data to be stored by a group of computers, and updated by any member of a specific security group that has rights to that data. In this way teams of people can work on a project or living document and maintain that document. In this model there are multiple copies of a document that can be stored on servers all over the world. Despite potentially dozens of users accessing the same files, the system keeps track of all updates and makes sure every user, automatically, has the latest copy of the data. Meaning that when User A makes a change to the document, when User B opens the document all changes made by User A are incorporated in the document User B is seeing. This despite the reality that the document User B is reviewing is a copy of User A’s document and is on a server somewhere else in the world.
This works for other types of systems besides document sharing. Microsoft’s active directory maintains the security boundary for all network objects using a multi-master replication model. Imagine a central database with all the network objects in the network. In this database of objects are all the security attributes for every system. This includes who can access a particular printer or even a file on the network.
Now if the network had physical servers in Los Angeles and in Boston there’s a problem. If the database is in Los Angeles, the users in Boston must authenticate to the server in Boston before they can access any files in the Boston servers. This can slow down production for everyone in Boston. The answer was to put a copy of this master database in both Los Angeles and Boston. This reduces logon and authentication times for all the users in both locations. The problem though is how to maintain the integrity of both databases. If a change is made in Los Angeles, how is that change replicated in Boston.
There are two methods that could be used. Originally we used a Master – Slave model. In this model all changes were made in Los Angeles. Then the slave system in Boston would receive updates of the changes from the master in Los Angeles. The problem occurs when networks continue to grow. Now instead of two offices there are thirty offices around the world. Suddenly the strain on the master is overwhelming as updates are made and distributed to multiple locations. The need for a way to update all the databases in every geographic location became more and more obvious.
In a multi-master environment, updates can be made in any location. Each database communicates with changes to all the other databases. This adds a level of flexibility to the system that allows scalable growth of the technology. The side effect though is that at any given moment, no one system matches any other system. Changes made within the environment as a whole take time to replicate. So while the overall system is maintained, the latency of the system means that there will be differences from server to server.