How to create a Horizontal Partitioned DSA in CA Directory r8.1
Article ID: 54703
Updated On:
Products
Issue/Introduction
Description:
This document is prepared with step-by-step instructions on how to convert a large flat DIT DSA into multiple Horizontal Partitioned DSAs for better performance, handling and maintenance.
Environment
Component:
Resolution
Solution:
Purpose:
There might be a situation (especially with eTrust Admin using CA Directory 8.1) that your Admin container could go up to having high number of objects. E.g. 500,000 or 1 million. By design Admin container is a flat DIT (Director Information Tree) and by having high number of objects within that one container can cause performance issues as well as issues with managing the data (i.e. backup, restore, tune etc can take hours to finish). This document walks you through the exercise of how you can split that one flat DIT into separate manageable size DSAs. A.K.A Horizontal Partitioned DSAs.
How to split a large flat DIT DSA into separate "Horizontal Partitioned" (HP) DSAs.
The following exercise is based on the sample 'democorp' and 'router' DSAs that is provided with CA Directory. I have separated the 'Administration' branch of 'democorp' DSA and partitioned it to be two separate HP DSAs. This branch in this example only has 10 entries so I will be performing this exercise with TWO new DSAs making them HP DSAs. Depending upon your requirement, you can create as many HP DSAs as you want.
In brief, this exercise requires you to:
- Create two new DSA (which we will modify later on to make it HP DSA) with two new databases to host the data.
- Dump the particular branch (in this case 'Administration') to an LDIF file using DXsearch command.
- Load the newly created DSAs via Router DSA.
NOTE: PLEASE DO NOT COPY / PASTE the 'dx' or any commands from this document to your system prompt on WINDOWS. Somehow copy / paste of commands fails to execute so I would encourage you to type it manually.
STEPS:
- Create two new DSAs. This will also create the appropriate Services for these DSAs.
Command:
dxnewdsa democorp_administration_hp1 democorp_admin_hp1 20389 c AU o Democorp ou Corporate ou Administration
dxnewdsa democorp_administration_hp2 democorp_admin_hp2 20489 c AU o Democorp ou Corporate ou Administration - Modify the KNOWLEDGE files for both of above DSAs. Basically the 'prefix' and 'dsa-name' lines.
For 'democorp_administration_hp1.dxc' it should read:
prefix = <c AU><o Democorp><ou Corporate><ou Administration ><cn "[hash1(2)=0]">
dsa-name = <c AU><o Democorp><ou Corporate><ou Administration> <cn "[hash1(2)=0]"><cn democorp_administation_hp1>
For 'democorp_administration_hp2.dxc' it should read:
prefix = <c AU><o Democorp><ou Corporate><ou Administration> <cn "[hash1(2)=1]">
dsa-name = <c AU><o Democorp><ou Corporate><ou Administration> <cn "[hash1(2)=1]"><cn democorp_administation_hp2>
As to what the different parameters are, an explanation is below:
prefix = <c AU><o Democorop><ou Corporate><ou Administration><cn "[hash1(2)=0]">
The prefix in this example indicates that the HP DSA's are going to manage the "ou=Administration,ou=Corporate,o=Democorp,c=AU" namespace.
<cn "[hash1(2)=0]"> The CN value indicates that the entries that are going to be managed by the HP DSA's are all going to have the RDN attribute of CN
<cn " [hash1 (2)=0]"> The HASH1 indicates that the hashing algorithm number "1" is going to be used to determine which HP DSA an inbound operation is going to be sent to.
<cn "[hash1 (2) =0]"> The in brackets figure "2" indicates that there are going to be two DSA's participating in this HP set
<cn "[hash1(2)= 0 ] "> The figure after the equals sign indicates the unique HP number of THIS DSA. As there are 2 HP DSA's in this set, the valid numbers can be "0 or 1".
NOTE: If your are using RDN attribute of UID, then simply replace 'cn' with 'uid'.
e.g. <uid "[hash1(2)=0]"> - Dump the required data using DXsearch command from original 'democorp'.
Command:
dxsearch -h <hostname>:19389 -s subsearch -b "ou=Administration,ou=Corporate,o=Democorp,c=AU" "(objectclass=*)" > admin_corp.ldif - Modify the KNOWLWDGE file (most likely a group file) that is the ROUTER DSA is sourcing to have knowledge of these newly created HP DSAs.
e.g. If the Router DSA is sourcing 'sample.dxg' then the content of this file should be:
source "router.dxc';
source "democorp.dxc';
source "democorp_administration_hp1.dxc";
source "democorp_administration_hp2.dxc";
source "unspsc.dxc"; - Modify the SERVERS (the .dxi) file for newly created HP DSAs to source the 'group' KNOWLEDGE file (which we modified above).
e.g. 'democorp_administration_hp1.dxi' should have:
# knowledge
clear dsas;
source "../knowledge/sample.dxg";
Make the same change in 'democorp_administration_hp2.dxi' as well. - Via JXplorer connect to 'democorp' DSA and delete the 'Administration' branch (which we will load later to HP DSA via Router DSA)
- Shutdown and restart all the required DSAs.
dxserver stop democorp
dxserver stop democorp_administration_hp1
dxserver stop democorp_administration_hp2
dxserver stop unspsc
dxserver stop router
dxserver start router
dxserver start unspsc
dxserver start democorp
dxserver start democorp_administration_hp1
dxserver start democorp_administration_hp2 - Load the data using 'dxmodify' via Router DSA.
Command:
dxmodify -a -h <hostname>:19289 -f admin_corp.ldif
When the above executes, the ROUTER DSA will decide which entry to be sent to which HP DSA through "hash1" algorithm. - Once the load is successful, start JXplorer and connect to 'democorp' or 'router' DSA. You should be able to see the data exactly you saw it before the split to separate HP DSA. But now you have your entire 'Administration' branch stored in two separate DSAs/DBs. When looking at the data from a front end tool, it appears to be still under the same branch within 'democorp' DSA.
Feedback
