CA Directory : How to replicate from a particular server?

[Dhilip kumar Mari]

Hi,

 

We are using three CA Directory servers (A, B and C)  for Policy Store and Session Store. We want to replicate the data from server A to server B and server C.

 

Note : 

All the servers already has data. But, server A has latest updates. So, we don't want to replicate the changes from server B and server C into server A (for first/one time). After that, normal replication should happen.

 

How can we achieve this requirement?

 

If we simply delete the db file of server B and server C, will it be replicated from server A?

(or)

Do we have to create new instance on servers B and C for this?

(or)

Is there any other easy or better way to achieve the same?

 

Thanks,

Dhilip

[Patrick Dussault]

Hi Dhi1ip,

You'll find a complete description on how to setup 2 CA Directory Policy Store instances replicated in ssl here :

Policy Server : Policy Stores Failover : CA Directory in SSL

TEC1852061

I hope that helps,

Best Regards,
Patrick

[Legacy User]

For the one time, You can copy db file from dsa1 to dsa2 and dsa3. But remove the tx file from dsa2 and dsa3. Restart dsa2 and dsa3. This is a very simple DISP approach. Since it is the policy store this method should be okay, as you can make this switch when there is no changes being done by UI.

 

1. Stop dsa2 and dsa3.

2. Copy db file from dsa1 (it is best to Stop DSA1, when using this approach of copying .db file. Reason, DSA1 before stopping will update everything from memory into the flatfile).

3. Start dsa1.

4. Remove tx file from dsa2 and dsa3.

4. Start dsa2 and dsa3.

 

After this first time / one time, if replication is configured correctly that will kick in.

[Dhilip kumar Mari]

Hi Hubert,

 

Thanks for your response.

 

Could you please let me know if we have to consider any other checks/points before this approach?

 

Because we proposed a similar approach earlier (copying a db directly from required server) for User Store replication, ended by creating a new schema because of multiple issues (but we didn't use dxdisp).

 

I could see that that you have mentioned that this approach should be okay for policy store. But still, please confirm us if we have to perform any other check or validation for Policy Store and Session Store replication.

 

Also, I hope this approach should be okay as we didn't perform any modification in policy store schema.

 

Thanks,

Dhilip

[Dhilip kumar Mari]

Hi Hubert,

 

A gentle reminder.

Thanks.

 

Regards,

Dhilip

[kenpe02]

Hi Dhilip

 

The key point, as Hubert mentions, is to ensure that no updates are happening while you are carrying out the steps he describes. The safest way to ensure that is to shut down all Policy Servers before beginning with the steps.

 

And make sure that dsa2 and dsa3 are configured in the same way as dsa1

E.g. if you added access controls to dsa1 then you should do the same in dsa2 and dsa3 first.

As this is a policy store and session store, you will have already extended the schema in dsa1, so make sure to do the same in dsa2 and dsa3. Same for any other changes you may have made (e.g. increased any limits)

 

Pearse

[Legacy User]

Dhilip Dhi1ip

 

(Note : I made a correction regarding using dxdisp in my comments earlier. In an offline dump, we need not run dxdisp, because of the process).

 

One things which is a definite "YES", is that when we are syncing manually we should have zero downtime for end users / clients connecting to CA Directory. Therefore we should have the core services still up and running. In the example I provided above DSA1 is still running, hence will be available for business continuity whilst we work on DSA2 and DSA3. Hence architecturally how CA Directory is built / setup within Geo's / across Geo's, play a key role. Also how client definitions are defined. Example : In Policy Server, what is defined? Is DSA1 defined as primary PStore OR is there a RouterDSA defined. If DSA1 is defined as primary then unless DSA1 goes down, all updates / reads are performed against DSA1. Thus in a way DSA1 is what is going to replicate to DSA2/3, because most of the time PS is running against DSA1 which is primary. Thus there won't be any muti-write queues in DSA2/3 contains data to be written. But in DSA1 there'd be MultiWrite Queues.

 

The second thing we need to take care is the amount of update that occurs. We can easily stack it up. Policy Store updates are minimal, because updates are via WAMUI or XPSTools & reads are from only Policy Servers. Session Store updates are with every authentication and validation, hence the frequency of updates are 3x or 5x times when it is Session Store. User Store updates and reads are 10x times because it is not only SiteMinder which uses a User Store but there are other capabilities too trying to connect and consume user information. Thus consider the time we take a backup (either using offline i.e. .db or online method i.e. .zdb) from DSA1, transfer the .db (or.zdb) to DSA2 / 3 and update DSA 2 / 3. The longer the time gap, the longer the number of updates / replication queue grows from DSA1 (after the backup was taken from DSA1 and DSA2/3 get running post manual sync).

 

The third thing, should we take an offline dump i.e. copy the .db file OR should we take an online dump i.e. copy .zdb. Here is a comparison.

https://docops.ca.com/ca-directory/12-6/en/administrating/manage-directory-data/backing-up-data 

 

 

Here is an approach to build the mindset.

https://docops.ca.com/ca-directory/12-6/en/administrating/set-up-replication/multiwrite-groups-hubs/sample-topology-and-disaster-recovery  (Keep MW-Groups in the doc link aside for a moment; but it conceptually gives us a birds eye view of how we can manually sync. Refer the Steps under "Multiwrite Group Peer Recovery" for taking an online dump and syncing another DSA).

 

We definitely need not rebuild schema, if that is the case, then there is something way wrong in the dsa (where the schema was rebuilt), than just being out of sync.

 

 

Regards

Hubert

[Rich_Faust]

The documentation recommends creating an online backup when DSAs have gotten out of synch, then copying the .zdb file created by the to the server with the out-of-date DSA and overwrite the .db file with the .zdb file.  I presume this approach has the benefit of using some kind of file locking while the backup is in progress and thus reduces the chance of inconsistent data.  You can't do better than shutting down all DSAs before making a copy, but I would think using a copy of the current data using the backup command would have less operational impact and be better than a raw copy of the running .db file.

If you're using the DX Management UI, there's an "ONLINE BACKUP" button available once you've selected a specific DSA.

[Hitesh Patel]

Spot on Hubert. And the same approach can be taken in future should there be a need to perform a manual resync for any reason.

 

Every ones best friend (who is on learning curve of CA Directory technology) is:

CA Directory r12 Data Replication and Recovery Best Practice. 

 

In brief:

If you are configured with MW-DISP recovery replication, quick reference would be the table on page 9.

If you are configured with 'vanilla' MW replication, quick reference would be the table on page 11.

 

NOTE: Just ignore references to file extensions such as .at, .zat, .oc and .zoc as those are absolute starting CA Directory r12.0 SP2 (build 4076) version as all has been merged into one .db/.zdb file.

 

-Hitesh

[Dhilip kumar Mari]

Hi,

 

Thanks all for your response!

 

HubertDennis,

Could you please remove the lines related to dxdisp from your initial response so that I can mark the same as correct answer?

 

Thanks,

Dhilip

[Legacy User]

Dhi1ip done. Thank You.

[Rich_Faust]

I know that the PolicyStore and SessionStore share the same schema, but is it common to use the same DSA for both roles?  Perhaps I'm misunderstanding your configuration.  The documentation advises some different settings for the SessionStore, such as cache-index of all attributes for a policy store and a specfic list of attributes for a session store.  It's also recommended that you disable the transaction log and transaction log flushing for a session store.  There are additional differences, but I'll hold off until it's clear this aspect of the conversation is worth pursuing.