Symantec Access Management

 View Only
  • 1.  Too many router DSAs

    Posted Jan 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 Jan 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

     

    Cons

    • 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. dummyFQDNrouter.ca.com and in each policy server host entry for dummyFQDNrouter.ca.com 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).