Ok, so far we have two installations of the ACS 5.x. The only thing we changed after installation is installing trusted certificates. At this point both servers are acting as a primary instances. What does this mean?
Well, we can have a distributed model in which one installation is acting as a primary instance and one or more installation(s) acting as a secondary instances. The main idea behind this is that we could have several ACSs geographycaly separated so that, for example users in our Europe offices get authenticated to an ACS server located, say, in Wienna. Similary, our US users can be authenticated to ACSs located in New York, Huston or Los Angeles. That way the authentication process is faster. But at the same time we don’t want some change to be made on all of our ACS servers. That’s where this distributed model comes into play. We have only one primary instance on which we make changes, and we have other instances receive these changes.
With regard to number of primaries, there can be only one. But what about secondaries? That depends on the ACS version and licenses. Version 5.3, for example has a “1+9” model, meaning that there is one primary and up to none secondaries for a total of ten ACS installations. In version 5.4 we have “1+12” or “1+20” models, depending on a license. Whatever model we have the principal is the same: we make a change only on a primary instance and this change gets replicated to all secondaries. It’s worth noting that this replication is change based or incremenatal, which means that only changes get replicated. This is in contrast to version 4.x where a full replication was triggered by any change we make.
Setting up the replication in 5.x version is very simple task. In version 4.x you had to match what you are sending from primary to that what secondary should accept. And you had to know and decide which components of the ACS database you want to replicate. With the 5.x it’s really very easy proces. On the future secondary instance (remember that at this time both our instances are primary instances!) we issue a request to the primary instance. Then on the primary instance we accept this request and we have primary-secondary relationship. It’s that easy!
So, let’s do that…
We want our “ACS52” instance to become a secondary. Under the “System Administration->Operations->Local Operations->Deployment Operations”, we fill in the required parameters and click “Register to Primary”:
The information popup appears:
Now depending on how the primary instance is set up, the replication registration request may be granted automatically or we may need to approve this request manually. The default is to approve the request automatically. But before we check the replication status, one thing I would like to point out. If we used the same PAK numbers on both instances, we will receive the error:
“This System Failure occurred: server cannot be addedd to the deployment. Server has same License ID as server ‘acs51’ that already exists in the deployment. Your changes have not been saved. Click OK to return to the list page.”
My license type is such that a change/upgrade was not possible, so the only way I could think of was reinstalling the “acs52” and apply different license ID. So be carefull!
When we send a request from a secondary-to-be instance, we will be logged out and a status on the loggin page will show:
On the primary replica, this replication status is in pending state. This can be viewed under the “System Administration->Operations->Distributed System Management” pane:
After a while, the replication will trigger and we will see a different and expected replication status:
And now we have our “Primary-Secondary” relationship.
Thanks for following up!