This topic explains how to architect the CA Service Catalog system to meet the requirements for the following scenario: "I have 60,000 end users distributed across the country and my system is located in a centralized data center owned by the service provider. We may also need to integrate with CA Service Desk Manager, CA APM, and other products. Our expected load is about 100 requests per day with an average of 1000 concurrent connections. We are planning to define CA Process Automation processes to meet our requirements."
This scenario is common. Because of the variability around usage patterns and architecture there is no simple calculator that can generate sizing estimates. However, the CA Service Catalog components are dynamically scalable.
The CA Service Catalog architecture is n-tier, stateless, and web-based. Users make HTTP requests. These HTTP requests are passed to one or more application servers and the application server performs the processing logic using a pool of connections to the database. The web server can be co-located with application server instances. In addition, several computational engines run independently from any user interactions; examples include the billing, SLA correlation, and CA Workflow engines. Several additional web servers, application servers, and computational engines can be added, as needed. The database, where state is maintained, is the potential performance bottleneck. The scalability of the database platform is very important. Therefore, the sizing and architecture of the MDB is the most critical factor.
|
Copyright © 2013 CA.
All rights reserved.
|
|