Team,
A valuable tool I have found useful, is located within the CA Directory samples folder, e.g. dxsoak.
Normally, this tool is expected to stress test the CA Directory DSAs, by performing searches, updates, deletes, creation via a LDIF/LDT file, in a loop.
Since CA Identity Suite's Identity Manager Provisioning Tier uses CA Directory, I have noticed that this tool can be used with the Provisioning Service, imps, over TCP 20389.
The only two (2) cons, I have found with dxsoak, is that it does not work over TLS for initial connection;and the testing password will be clear text.
### ###
Example to stress test the IM provisioning tier to a managed endpoint through the IAMCS(JCS) and CCS connectors.
Step 0: Perform an explore operation prior to any effort to confirm access to endpoint.
Step 1: Build the input LDT File for use with dxsoak.
a) Use the IMPS GUI to perform the update you wish to the managed endpoint.
b) Select the managed endpoint, right click, then select content.
c) Select a user search (if OU), then select an manage endpoint account (at this stage, you are viewing the "pointer" object within CA Directories IMPD main DSA)
d) Select / double-click until you can view the attributes of the endpoint accounts (at this stage, you have now engaged the IMPS provisioning/connector tier to show live data in the endpoint)
e) Update an attribute (not group object membership at this time) and then click Apply.
f) Confirm this update was made, if you wish with a native/3rd party tool.
g) View the IMPS etatrans*.log for the user object.
h) Pull this update data and its DN syntax from this log file for use to build the LDT file.
Example for ADS managed endpoint.
- Note the DN syntax for the managed endpoint.
dn: eTADSAccountName=bugs bunny001,eTADSContainerName=Users,eTADSDirectoryName=192.168.242.154,eTNamespaceName=ActiveDirectory,dc=im,dc=eta
changetype: modify
replace: eTADSDescription
eTADSDescription: ANY_INFORMATION_HERE_FOR_TESTING
i) Duplicate this entry, (with a new line entry between them), update the 2nd entry attribute field, then save to a text file:
dn: eTADSAccountName=bugs bunny001,eTADSContainerName=Users,eTADSDirectoryName=192.168.242.154,eTNamespaceName=ActiveDirectory,dc=im,dc=eta
changetype: modify
replace: eTADSDescription
eTADSDescription: ANY_INFORMATION_HERE_FOR_TESTING
dn: eTADSAccountName=bugs bunny001,eTADSContainerName=Users,eTADSDirectoryName=192.168.242.154,eTNamespaceName=ActiveDirectory,dc=im,dc=eta
changetype: modify
replace: eTADSDescription
eTADSDescription: ABCDEFGHIJKLMNOPQRSTUVWXYZ
Step 2: Execute this input file with dxsoak command:
a) su - dsa (if on the Identity Suite Appliance)
b) change folder to ./samples/dxsoak
c) Select switch to use: Max Time (-l), Stop on Errors (-s), # of threads (-t) [Recommend to not go above 50 threads]
d) Example:
[dsa@vapp0001 dxsoak]$ ./dxsoak -l 60 -s -t 50 -h localhost:20389 -D "eTGlobalUserName=etaadmin,eTGlobalUserContainerName=Global Users,eTNamespaceName=CommonObjects,dc=im,dc=eta" -w Password01 -f imps_ads_test.ldt
Step 3: Monitor updates with an active tail on IMPS etatrans*.log
a) su - imps (if on the Identity Suite Appliance)
b) change folder to ./logs
c) Example:
tail -f etatransXXXXXXX.log (where ****** is the current time-date stamp)
Additional Notes:
To determine when an environment should be scaled, I have found that within my lab (vmware workstation using same disk between images), the maximum updates to a manage ADS endpoint via the IMPS/IAMCS/CCS data tier, is about thirty (30) updates/second per IAMCS/CCS connector.
- With this small environment, this will give us a conservative number to work with.
- To increase this data flow, we needed to add additional IAMCS/CCS connector servers, where we will get roughly a linear progression of thirty (30) updates/second per connector server.
- Other limiting factors would be shared disk space on Virtualized severs, excessive logging to monitor, endpoint tuning that may need to be adjusted.
Lab Example:
- One (1) IMPS server with four (4) IAMCS/CCS (remote connector server with embedded CCS) to one (1) ADS Manage endpoint.
- IAMCS connector servers are setup with default Routing Rules strings to allow load-balancing to all data paths.
We can expect to see minimally, 4x30 updates/second = 120 updates/sec = 720 updates/min = 43,200 updates/hr, for ADS. Other endpoints should be validated to determine when their PEAK use-cases should be accounted for scaling the solution.
I am using this process at customers' sites as well to determine when to scale for PEAK use-cases.
Cheers,
Alan