Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Stardust/Knowledge Base/Deployment/PossibilitiesforProductionDeployment"
< Stardust | Knowledge Base | Deployment
(New page: == Introduction == There are three aspects to be considered when deploying a Stardust runtime environment: *Deployment Variants *Runtime Administration *IPP in a Clustered Environmen...) |
m (Simone.seurer.sungard.com moved page Stardust/KnowledgeBase/Deployment/PossibilitiesforProductionDeployment to Stardust/Knowledge Base/Deployment/PossibilitiesforProductionDeployment) |
||
(5 intermediate revisions by 3 users not shown) | |||
Line 5: | Line 5: | ||
*Deployment Variants | *Deployment Variants | ||
*Runtime Administration | *Runtime Administration | ||
− | * | + | *Stardust in a Clustered Environment |
− | == | + | == Deployment Variants == |
==== Standalone ==== | ==== Standalone ==== | ||
− | * | + | *Lightweight Spring-based environment |
*JMS can be enabled | *JMS can be enabled | ||
*Useful for Continuous Integration | *Useful for Continuous Integration | ||
Line 55: | Line 55: | ||
*This also includes the monitoring capabilities a certain application Server provides with regards to load Balancing and failover. | *This also includes the monitoring capabilities a certain application Server provides with regards to load Balancing and failover. | ||
− | == | + | == Runtime Administration – Database Server == |
==== AuditTrail Database ==== | ==== AuditTrail Database ==== | ||
Line 81: | Line 81: | ||
==== Model Deployment <br> ==== | ==== Model Deployment <br> ==== | ||
− | * | + | *Version vs. Overwrite.<br> |
*Deployment via console command line tool, API or Administration Portal. | *Deployment via console command line tool, API or Administration Portal. | ||
Line 100: | Line 100: | ||
*Trigger actions based on certain time-based events (Event Daemon). | *Trigger actions based on certain time-based events (Event Daemon). | ||
− | ==== Stardust daemons | + | ==== Stardust daemons are background threads that:<br> ==== |
*Can be started and stopped via console command line tool.<br> | *Can be started and stopped via console command line tool.<br> | ||
Line 133: | Line 133: | ||
==== Load Balancing ==== | ==== Load Balancing ==== | ||
− | *Stardust supports Sticky Session load balancing for | + | *Stardust supports Sticky Session load balancing for HTTP requests |
*JMS load balancing is possible using distributed queues for | *JMS load balancing is possible using distributed queues for | ||
Latest revision as of 03:38, 25 June 2014
Contents
Introduction
There are three aspects to be considered when deploying a Stardust runtime environment:
- Deployment Variants
- Runtime Administration
- Stardust in a Clustered Environment
Deployment Variants
Standalone
- Lightweight Spring-based environment
- JMS can be enabled
- Useful for Continuous Integration
Managed Environment
- Spring-managed
- 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
Transaction Management
- 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
AuditTrail Database
- 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
Model Deployment
- Version 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 are background 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
Clustering
- 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.
Load Balancing
- Stardust supports Sticky Session load balancing for HTTP requests
- JMS load balancing is possible using distributed queues for
- CarnotApplicationQueue
- CarnotSystemQueue
Failover
- 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.