Symantec Access Management

Expand all | Collapse all

Too many router DSAs

  • 1.  Too many router DSAs

    Broadcom Employee
    Posted 01-09-2018 10:26 PM

    My customer has 4 data DSAs/user store, then they install router DSAs on each CA SSO policy server; policy server connect to local router DSAs, then traffic is routed to the data DSAs.


    There are around 32 policy servers in one data center, so there are 32 router DSAs on those policy server boxes. I don't see benefits to have such a configuration and it is hard to manage so many router DSA instances, but is there any  negative impact on performance and system stability with so many router DSAs?

  • 2.  Re: Too many router DSAs

    Posted 01-16-2018 10:26 AM

    The benefit of having the RouterDSA on the CA SSO Policy Server machine is that

    • For the Policy Server it'd seem that the User Store is on the same box. Hence no network in between Policy Server and User Store. As long as there is one Data DSA up and alive, CA SSO Policy Server will show no connection errors in smps.log.
    • Not sure if I'd call this a benefit, but here's a thought. Since the RouterDSA is on same machine may be we cab get off SSL connection between CA SSO PS and RouterDSA. The communication between Router and Data DSA I believe is encrypted.
    • The Router DSA is not overloaded with connections from multiple Policy Servers. Because it has only connection requests from its local Policy Server. So the Router in this case is bearing less burden



    • Yes it adds management / administrative overheads.
    • Stability issue, depends on if Data DSA can cope with the connection count. Because Data DSA interoperability with Router DSA is far better than DataDSA interoperability with a Client. From Data DSA perspective it is receiving requests from 32 Router DSA's (not clients). But it is more connections from 32 originators than 2 or 3 originators. So Data DSA is bearing the brunt of requests from 32 originators.
    • One question that is in my mind is whether they were able to define LDAP Banks in the UD Object for Load Balancing. Using this method I think we can only define one FQDN (e.g. and in each policy server host entry for which points to itself) in the User Directory Load Balancing configuration. For Failover there are ways to define FO's.


    Though I don't see an issue. I think the topology should be reversed. Which mean Router DSA has to perform more load balancing / Fail Over / Funneling functions. So I believe having a Router isolated from the Client would be best, as the Router can handle more requests from multiple originators, but act as a gateway to the Data DSA (rather than DataDSA handling requests from multiple originators, even though the originator is a Router).