< Stardust | Knowledge Base | Deployment
Revision as of 02:02, 17 November 2011 by Srinivasan.iyer.sungard.com
There are three aspects to be considered when deploying a Stardust runtime environment:
- Deployment Variants
- Runtime Administration
- Stardust in a Clustered Environment
- Light-Weight Spring-based environment
- JMS can be enabled
- Useful for Continuous Integration
- JMS enabled
- JEE component
- Stateful / Stateless
Runtime Administration – Application Server
- Stardust process engine relies on the application server infrastructure for the following:
- Transaction Management
- Data Source Pooling (Audit Trail)
- JMS Resource Provider
- Clustering, Load Balancing and Failover capabilities
- Transactions are bound to Global Transaction via JTA managed by the container.
- JTA transaction monitoring of application server can be utilized.
Data Source Pooling
- Audit Trail Data Source is registered in application server and looked up via JNDI.
- Data Source pooling is managed by the container.
- JDBC connection monitoring of application server can be utilized.
JMS Resurce Provider
- Connection Factory as well as required Queues are registered in application server and looked up via JNDI.
- Connection Pool and Queue monitoring of application server can be utilized.
Clustering, Load Balancing and Failover capabilities
- Stardust completely relies on the capabilities of the underlying application server for these features.
- This also includes the monitoring capabilities a certain application Server provides with regards to load Balancing and failover.
Runtime Administration – Database Server
- Contains process model and process runtime and history information.
- Continuous maintenance of DB tables and indexes required.
- Monitoring via SlowQuery logging.
- Analysis via Explain Plan execution.
- Regular calculation of statistics recommended.
AuditTrail Archive Strategy
- Archive strategy should be in place from day 1.
- 2 Level Archive strategy
- Level 1: Production AuditTrail data older than X days is loaded into an archive database.
- Level 2: Archive AuditTrail data older than Y days is completely purged.
- Archive strategy depends on the business requirements and mandatory retention period.
- Stardust provides a command line tool (sysconsole) for the Archive process.
Runtime Administration – Model Deployment
- Versionize vs. Overwrite.
- Deployment via console command line tool, API or Administration Portal.
Deployment Strategy (Production Environment)
- Process models should always be versioned.
- Use Valid From date for new model deployments.
- Use the console command line tool for model deployments.
- Stop Stardust daemons prior model deployment.
- Archive dead (unused) process models on a regular basis.
Runtime Administration – Stardust Daemons
Stardust daemons are used to:
- Trigger processes based on a certain time interval (Timer Trigger) .
- Trigger processes based on incoming mails into a certain inbox (Mail Trigger).
- Trigger actions based on certain time-based events (Event Daemon).
Stardust daemons arebackground threads that:
- Can be started and stopped via console command line tool.
- Can be automatically monitored via a Daemon Watchdog.
- Need to be stopped during model deployment
Stardust Daemon Watchdog
- Checks health status of daemons periodically.
- Restarts daemons in case of an abnormal crash.
- Is needed to enable failover capability of Stardust daemons.
Stardust in a clustered environment
- Stardust relies on clustering capabilities of the underlying application server.
- The process engine as well as portals can be deployed on multiple nodes within a cluster.
- There is no need to synchronize state between the nodes.
- Single point of synchronization is the AuditTrail.
Exception: Process Model Deployment
- Model cache is only updated on the node where the deployment is applied.
- All other nodes need to be re-initialized (console command line tool).
- Use of Valid From date to make sure, each node relies on the same model version at the same time.
Exception: Stardust Daemons
- Daemons need to be started on one node only.
- Stardust supports Sticky Session load balancing for http requests
- JMS load balancing is possible using distributed queues for
- Stardust relies on failover capabilities of the underlying application server.
- Stardust needs to be deployed as EJB-component or Spring-managed with JMS enabled.
- Stardust queues must be clustered.
- Daemon Watchdog enables failover capability for Stardust daemons.