Best practices for implementing CA Client Automation 14.x within AWS Amazon Web Services
Article ID: 107728
CA Automation Suite for Data Centers - Configuration AutomationCA Client Automation - Asset ManagementCA Client Automation - IT Client ManagerCA Client AutomationCA Client Automation - Remote ControlCA Client Automation - Asset IntelligenceCA Client Automation - Desktop Migration ManagerCA Client Automation - Patch Manager
I would like some best practices documentation, guidelines and/or recommendations for how to install/implement a Windows Server 2016 based ITCM DSM* version 14.0 SP2 WAN environment within our Amazon Web Services (AWS) solution.
*ITCM / ITCA / DSM - CA Client Automation, IT Client Manager, CA Desktop and Server Management, and Unicenter Desktop and Server Management are all references to the same product at different points in it's lifetime and for different versions of it's existence from 11.0 to current day.
These are recommendations based on internal feedback and discussion and not formally certified CA Technologies recommendations
Release: Component: DTSVMG
The main concern would be using the default CAM communication port 4104 UDP. UDP has no error correction or guaranteed delivery, so it would not be wise to use that over a WAN connection. What you need to do depends on whether your Scalability Servers are external / remote or in the same network as your web services. If External E.G. on remote sites, perhaps connected via a smaller pipe or leased line or VPN, then those SS machines can be configured to use TCP 4105 for CAM, however the actual traffic will come across on TCP port 7163 because TCP CAM traffic is handled by the port multiplexer and SHIM DLL on each end of the communication and DEMUXed locally.
Agents will pull packages from their SS machines, so that bandwidth will either all share the same pipe or be distributed over X number of pipes, depending on your topology.
The basic two scenarios are:
1. All external agent communication has to come in through a centralized point and then to the SS machines 2. All external agent communication comes in to local Scalability Servers (SS) and then all SS traffic goes in through a central point to your Domain Manager.
ENC would be a viable solution to handle scenario #2, but scenario #1 only allows a partial benefit for ENCs' use and some detriment.
Essentially in case #2 ENC would help with:
1. Reducing all traffic down to a single outbound-only port on the end points (443 TCP by default) 2. Allow for traffic distribution across multiple remote ENC Routers so data transfers would not all have to go through the central hub* 3. It allows for end points to connect regardless of location as long as an internet connection is present.
*A continuous low bandwidth connection to the central hub would ALWAYS be required but utilization should be quite low.
Scenario #1 would not allow for benefit #2 item 2, and would force all communication through the central hub and back again to the local SS which would result in increased latency for all transactions and may be untenable in your situation. In that case, if connectivity allows, a more 'open' setup would be required with two ports being opened bi-directionally in order to manage the traffic in a way that would not incur this latency. But this would not work in scenarios where end points are not connected to the corporate network in some fashion (E.G. VPN) and would be less secure.
A formal evaluation by a CA Systems Architect is recommended if you wish to have a certified implementation done.