Logical architecture
High availability is provided by the main components and the way that they interact in the logical architecture of Maximo® Application Suite. You have a choice of multiple application services that provide the primary features for managing, monitoring, inspecting assets, and determining their health and predicting when they require maintenance.
The Maximo Application Suite core services are deployed automatically with any instance. These services handle the basic administration and configuration of the suite, and they store metadata in a deployed MongoDB in a three-node instance.
Application services are containerized, assigned to pods, and configured through Kubernetes operators to start and stop based on their configuration.
Each of these application services uses their own persistence stores that have some flexibility
for the instance location. In particular, the application state and user data are spread across the
following types of persistence stores:
- Document database
- A MongoDB variant, which can be enterprise, community, or AWS Document DB, where most of the metadata, preferences, configuration settings, user, and security management are kept. This database is configured with multinode replication and without sharding, which improves resiliency. It also provides backup and restore utilities.
- Relational database
- Typically an IBM® Db2® database or Oracle Database that holds most of the user data that is necessary for application function, with complete atomicity, consistency, isolation, and durability (ACID) transactional control. Backup services for full and incremental backups and restore services can also apply transaction log changes from the last backup point. This choice enables a wide range of usage patterns and integration with BI Reporting and Replication tools.
- Cloud object storage
- IBM Cloud® Object Storage, AWS S3, or similar object storage that stores big files, which can range from attachments to video images to the actual backup images. The goal is to provide inexpensive storage for large content with high reliability. Because of its high availability through automatic replication, it doesn’t require backups, but you might prefer to enable versioning to protect from certain scenarios.
- Red Hat® OpenShift® persistence storage
- etcd or other persistent volumes that are attached to the worker nodes that are used byRed Hat OpenShift to operate. This option requires special backup and restore operations that range from Kubernetes operator logic to storage-level utilities.