System Architecture Overview
Relevant source files
The following files were used as context for generating this wiki page:
ManageIQ is an open-source Management Platform designed to discover, optimize, and control hybrid IT environments including containers, virtual machines, networks, and storage. The system is built on a modular architecture that facilitates insight through monitoring and reporting, control via policy-based management, and automation through complex IT processes and orchestration.
The architecture is distributed and hierarchical, relying on core server instances, specialized workers, and management providers to handle diverse infrastructure backends. It integrates with external systems using a robust plugin system and a dedicated automation engine.
Sources: README.md:18-28, spec/lib/vmdb/plugins_spec.rb
Core Platform Components
The system's high-level functionality is categorized into four primary domains:
- Insight: Handling discovery, utilization, performance, and chargeback.
- Control: Implementing security, compliance, and alerting.
- Automate: Managing IT processes, workloads, and orchestration.
- Integrate: Connecting with web services, CMDBs, and event consoles.
Hierarchical Management Structure
The architecture organizes infrastructure into Regions and Zones. An MiqServer belongs to a specific zone and handles roles assigned to that zone.
The diagram above represents the hierarchical relationship between regions, zones, servers, and workers.
Sources: app/models/ext_management_system.rb:147-152, spec/models/miq_server_spec.rb:250-258
Provider Architecture (ExtManagementSystem)
The ExtManagementSystem (EMS) class serves as the base for all management providers. It uses Single Table Inheritance (STI) to support various infrastructure types such as Cloud, Infra, Network, and Container managers.
Provider Lifecycle and Maintenance
Providers can be "paused" by moving them to a maintenance zone, which disables their operations and stops associated workers.
| Method | Description |
|---|---|
pause! | Moves EMS to maintenance zone and backs up the original zone. |
resume! | Restores EMS to its original zone and reenables operations. |
orchestrate_destroy | Safely removes a provider by killing active workers before deletion. |
refresh_ems | Queues a refresh of the provider's inventory. |
Sources: app/models/ext_management_system.rb:271-311, app/models/ext_management_system.rb:584-596
Feature Support and Attributes
The EMS model tracks supported features for each provider subclass through a standard interface.
Server and Worker Lifecycle
The MiqServer is the primary execution unit. It monitors its own resource usage and manages a pool of MiqWorker processes.
Shutdown and Quiesce Process
When a server shuts down, it enters a "quiesce" state to ensure all workers complete their current tasks and active messages are cleaned up.
The sequence shows the transition from an active server to a stopped state, ensuring data integrity in workers.
Sources: spec/models/miq_server_spec.rb:149-165
Automation and Provisioning
The system includes a robust Automation Engine (AE) and Provisioning Workflow system to handle complex infrastructure requests.
Automation Engine (MiqAeMethod)
Automation logic is encapsulated in methods that can be stored in the database. These methods support multiple locations:
- Inline: Ruby code executed within the process.
- Builtin: Pre-defined system methods.
- Expression:
MiqExpressionbased logic. - Playbook/Ansible: Integration with Ansible jobs.
Sources: app/models/miq_ae_method.rb:26-30
Provisioning Workflow
MiqProvisionVirtWorkflow manages the multi-step process of creating virtual resources. It handles:
- Source template selection.
- Field validation and visibility (e.g., hiding network fields if auto-placement is enabled).
- Integration with Automation for dynamic dialog names.
- Execution of the request through the provider's specific provisioning class.
Sources: app/models/miq_provision_virt_workflow.rb:42-65, app/models/miq_provision_virt_workflow.rb:304-325
Environment and Plugins
The platform is extensible via a plugin architecture. Each plugin is treated as a Rails Engine, allowing it to provide its own models, controllers, and automation content.
Plugin Types
- Provider Plugins: Add support for new infrastructure backends (e.g., Amazon, VMware).
- UI Plugins: Extend the classic or service-based user interfaces.
- Content Plugins: Provide Ansible playbooks or Automate domains.
Sources: spec/lib/vmdb/plugins_spec.rb:58-85, lib/manageiq/environment.rb:10-35
Summary
The ManageIQ architecture is defined by its ability to abstract heterogeneous infrastructure into a unified model controlled by hierarchical servers and zones. Through its provider-based STI structure and an event-driven automation engine, it facilitates comprehensive lifecycle management of hybrid IT resources. Significant emphasis is placed on the safe lifecycle management of its processes, evidenced by rigorous quiesce and maintenance protocols.