Automating MySQL InnoDB Cluster Deployment for HPE Morpheus Enterprise HA Environments

Introduction

Understanding HPE Morpheus Enterprise HA Architecture

1. Application Tier

2. Transactional Database Tier (MySQL) 🎯

3. Non-Transactional Database Tier (OpenSearch)

4. Messaging Tier (RabbitMQ)

The Architecture Diagram

MySQL Requirements for Morpheus HA

The Pain of Manual MySQL InnoDB Cluster Setup

Introducing morpheus-innodb-cluster

Architecture at a Glance

Step-by-Step Walkthrough

Getting Started

Step 1/11 — Environment Setup

Step 2/11 — Cluster Configuration

Configuration Summary

Steps 3–4 — Inventory Generation & SSH Connectivity Test

Steps 5–7 — Pre-Flight Checks

Step 8/11 — MySQL Version Selection

Step 9/11 — Deployment Confirmation

Step 10/11 — Ansible Playbook Execution

Step 11/11 — Setup Report

What Makes This Project Different

✅ Truly Idempotent

✅ OS-Aware Automation

✅ Production-Grade Tuning

✅ Security by Default

Connecting Morpheus to Your New Cluster

1. Create the Morpheus Database

2. Bootstrap MySQL Router on Each App Node

3. Configure Morpheus

Network Requirements

MySQL InnoDB Cluster Ports (between DB nodes)

Morpheus App Node to MySQL Cluster

Additional Morpheus HA Ports (for reference)

PaaS Alternatives

Conclusion

References A single Python script that turns a painful, multi-hour manual process into a guided 10-minute deployment. 🔗 GitHub Repository: emrbaykal/morpheus-innodb-cluster 👤 Author: Emre Baykal If you deploy HPE Morpheus Enterprise in a 3-Node HA configuration, the installer automatically clusters the Application Tier, OpenSearch, and RabbitMQ — but leaves the Transactional Database Tier (MySQL) entirely in your hands. You must stand up a resilient, production-grade MySQL InnoDB Cluster before you can even start the Morpheus HA installation. The morpheus-innodb-cluster project solves this with a single interactive Python script backed by modular Ansible roles — it turns a multi-day manual task into a 10-minute guided wizard. If you've ever deployed HPE Morpheus Enterprise in a High Availability (HA) configuration, you know the drill: the application tier, messaging tier, and non-transactional database tier all install and cluster automatically across your three nodes — but the Transactional Database Tier is left entirely in your hands. That tier is MySQL, and for a production HA environment, it needs to be a properly configured, redundant, multi-node cluster. As the HPE Morpheus Enterprise v8.1.0 HA Installation Overview clearly states: "In this architecture, all tiers are deployed on three machines by HPE Morpheus Enterprise during the installation, with the exception of the Transactional Database Tier. This provides HA not just for the HPE Morpheus Enterprise Application Tier but all underlying tiers that support HPE Morpheus Enterprise. The Transactional Database Tier will remain external, either as a separate cluster or PaaS, following the supported services. An external MySQL cluster must still be set up outside of the HPE Morpheus Enterprise app nodes." This means you are responsible for standing up a resilient, properly tuned MySQL cluster before you can even begin the Morpheus HA installation. There is no embedded option — Morpheus disables its internal MySQL (mysql['enable'] = false) and expects you to provide an external endpoint. This is where the morpheus-innodb-cluster project comes in. It is a single interactive Python script, backed by modular Ansible roles, that automates the entire process of deploying a production-ready 3-node MySQL InnoDB Cluster on Ubuntu or RHEL-based systems. In this post, I'll walk you through why this tool exists, what problems it solves, and how to use it from start to finish. HPE Morpheus Enterprise is a unified hybrid cloud management platform that provides provisioning, orchestration, monitoring, and governance across private and public clouds. It can start as a simple single-machine instance, or it can be split into individual services per machine and configured in a high availability (HA) configuration. According to the official HPE documentation (v8.1.0, February 2026), there are four primary tiers of services within the Morpheus appliance: The stateless services layer — Nginx and Tomcat. These can be installed across all regions and placed behind a central load balancer or geo-based load balancer. Shared storage (NFS, Amazon S3, or OpenStack Swift) is required for deployment archives, virtual image catalogs, and backups. This is the focus of this article. The HPE documentation states: "The Transactional Database tier consists of a MySQL compatible database. It is recommended that a lockable clustered configuration be used, such as a Galera cluster, which can also provide high availability." For the recommended 3-Node HA architecture, this tier must be external — it is not deployed by the Morpheus installer. Used for log aggregation, stats, metrics, and temporal data. Morpheus clusters OpenSearch automatically during installation — no manual setup required. An AMQP-based tier with STOMP protocol for agent communication. RabbitMQ needs at least 3 instances for HA. While RabbitMQ is installed automatically during Morpheus setup, it does require manual clustering afterward. The recommended 3-Node HA deployment looks like this: three Morpheus application nodes sit behind a load balancer, each running embedded RabbitMQ and OpenSearch. On the side, a separate 3-node MySQL Database Cluster provides the transactional database tier, connected via port 3306. Shared storage connects to all application nodes. HPE Morpheus Enterprise 3-Node HA Architecture — the external MySQL cluster on the right is exactly what this tool automates. The HPE 3-Node HA Install documentation specifies the following MySQL requirements: There is also an important note: "Morpheus does not create primary keys on all tables. If you use a clustering technology that requires primary keys, you will need to leverage the invisible primary key option in MySQL 8." Once the MySQL cluster is up, you must create the Morpheus database and user before installing Morpheus itself: Then, in each Morpheus app node's /etc/morpheus/morpheus.rb, you configure: Notice mysql['enable'] = false — this tells Morpheus to skip its embedded MySQL and use your external cluster instead. The host points to 127.0.0.1:6446, which is the MySQL Router read-write endpoint running locally on each app node. The HPE documentation tells you that you need an external MySQL cluster, but it doesn't deploy one for you. You're on your own. Here's what you're typically facing: 1. Repetitive Per-Node Configuration — OS tuning, kernel parameters, firewall rules for ports 3306, 33060, and 33061, NTP sync, locale settings, and MySQL installation on every node. 2. MySQL Installation Complexity — Repository management, correct stream/version selection, package locks, and systemd overrides. On RHEL, you also deal with AppStream module conflicts. 3. InnoDB-Specific Tuning — Enable GTID mode, enforce GTID consistency, set unique server_id, tune innodb_buffer_pool_size to RAM, configure binary log expiration, and bind addresses correctly. 4. Cluster Bootstrap Choreography — dba.configureInstance() on every node, dba.createCluster() on the primary, cluster.addInstance() for each secondary with the correct recovery method. Order matters. 5. Security Considerations — MySQL root passwords, cluster admin credentials, SSH keys, and sudo escalation — all of which need to be managed securely. 6. OS-Specific Differences — Ubuntu/Debian vs. RHEL differ in repository management, package names, services, paths, and security frameworks (AppArmor vs. SELinux). Put it all together and you're looking at multiple hours — or days — of careful, error-prone work before you can even begin the Morpheus installation itself. The morpheus-innodb-cluster project eliminates all of this manual toil. It is a single Python script (innodb_cluster_setup.py) that orchestrates the entire deployment through an interactive 11-step wizard, backed by four modular Ansible roles that handle the actual configuration work. The script is designed to run from the master node of the cluster. It installs its own dependencies (Ansible, sshpass, community.mysql collection), connects to all three nodes via SSH, and executes the Ansible playbook that does the heavy lifting. You don't need to pre-install anything other than Python 3.6+ and sudo access. Let's walk through the entire deployment process, using screenshots from a real deployment on RHEL 9 nodes. Clone the repository and run the script on the node you want to be the primary (master) node: The script begins by detecting your operating system family and automatically installing all required prerequisites. On RHEL systems, it checks for the Ansible Automation Platform repository in subscription-manager; if it's not enabled, the script gracefully falls back to installing Ansible via pip3. In the screenshot above, you can see the tool detecting RHEL 9, installing sshpass and python3-pip via the OS package manager, falling back to pip for Ansible (since the AAP repository wasn't enabled in subscription-manager), and installing the community.mysql Ansible collection. The entire environment is ready in seconds. This is the heart of the wizard. It collects all the information needed in five organized sections: Section 1/5 — Cluster Nodes: You provide the hostname and IP address for each of the three cluster nodes. The first node is automatically designated as the master (primary), and the other two become secondaries. Section 2/5 — SSH Connection: The script asks for the SSH user, key file (or password), privilege escalation method (sudo or dzdo), and sudo password. Section 3/5 — MySQL Credentials: You set the MySQL root password and the InnoDB Cluster admin credentials. The cluster admin user (default: clusterAdmin) is the account that will manage the InnoDB Cluster. Section 4/5 — Cluster Settings: You name your cluster (in our case, morpheus-cluster) and set a password for the MySQL Router user account (routeruser) that will be created for application connectivity. Section 5/5 — System Settings: NTP server configuration for time synchronization across all nodes — critical for Group Replication to function correctly. Before anything is written to disk or executed, the script presents a complete summary table of everything you've entered — cluster nodes with IPs, SSH connection details, MySQL configuration, and system settings. You review and confirm with y before proceeding. This is a safety net. All passwords are masked, and the configuration is saved to cluster_config.json with mode 0600 so it can be reused on subsequent runs without re-entering everything. The script generates an Ansible inventory file from your inputs and then tests SSH connectivity to every node. This catches authentication problems, firewall issues, or unreachable hosts before the deployment begins. In our deployment, all three nodes — innodb-rhel-1 (192.168.42.100), innodb-rhel-2 (192.168.42.102), and innodb-rhel-3 (192.168.42.101) — came back as reachable. The inventory uses IP addresses throughout, making the deployment DNS-independent. Note the ansible_ssh_common_args='-o StrictHostKeyChecking=no' setting, which prevents SSH from blocking first-time connections. The script performs three validation checks before deployment: On RHEL systems, the script presents the available MySQL AppStream streams (8.0 and 8.4) and then lists the specific versions within your chosen stream. In our deployment, we selected MySQL 8.4.7 from the 8.4 LTS stream — well above the HPE minimum requirement of v8.0.72. A final confirmation screen shows exactly what will be deployed: the cluster name (morpheus-cluster), admin user (clusterAdmin), and all three nodes with their roles. The master node is marked with a star. Once you confirm, the Ansible playbook executes with real-time streaming output. You can watch every task as it runs across all three nodes. The playbook applies five roles in sequence: In our deployment, the entire Ansible playbook completed in 4 minutes and 31 seconds with zero failures across all three nodes. ⚡ After completion, the script generates a comprehensive setup report that includes everything you need to verify and manage your new cluster. The NODE STATUS section shows the Ansible PLAY RECAP for each node — in our deployment, the master node had 70 OK / 32 Changed tasks, while each secondary had 61 OK / 26 Changed, with zero unreachable or failed across the board. The APPLIED ROLES section shows what each role did, and the NEXT STEPS section provides ready-to-use commands: The entire workflow is safe to re-run. The script saves your configuration to cluster_config.json and offers to reuse it on subsequent runs. Ansible tasks check the current state before making changes. MySQL root password handling tries socket authentication first, then falls back to the existing password. The Ansible roles automatically detect ansible_os_family and execute the appropriate tasks for each distribution. Whether you're running Ubuntu 22.04, Ubuntu 24.04, RHEL 8, or RHEL 9, the same script handles everything. This isn't just a "get MySQL running" script. It applies production-grade OS and database tuning: All generated configuration files are created with mode 0600. Passwords are never logged (Ansible no_log: true). Terminal input is masked for all password prompts. Temporary credential files in /tmp/ are cleaned up after cluster creation. Once the InnoDB Cluster is running, you need to bridge it with your Morpheus application nodes. Here's the complete workflow: Log into your new cluster's primary node and create the database and user that Morpheus expects: Install MySQL Router on each Morpheus application node and bootstrap it against the cluster: MySQL Router will automatically discover all cluster members and create local read-write (port 6446) and read-only (port 6447) endpoints. Edit /etc/morpheus/morpheus.rb on each app node, pointing MySQL to the local router endpoint: Then reconfigure and proceed with the rest of the Morpheus HA installation: With this setup, MySQL Router handles automatic failover. If the primary node goes down, Group Replication elects a new primary, and MySQL Router transparently redirects traffic — all without any Morpheus downtime. The HPE documentation also lists supported PaaS offerings as alternatives to self-managed MySQL clusters: As you can see, PaaS support for MySQL is limited to AWS and GCP. For on-premises deployments, private cloud, or any other environment, a self-managed MySQL cluster is your only option — which is exactly what this tool provides. Setting up a MySQL InnoDB Cluster for HPE Morpheus Enterprise HA shouldn't be a multi-day project requiring deep MySQL expertise. The morpheus-innodb-cluster tool reduces it to a single command and a 10-minute guided wizard. It handles OS detection, prerequisite installation, interactive configuration, pre-flight validation, Ansible-driven deployment, and post-deployment reporting — all in one cohesive workflow. While HPE Morpheus Enterprise excels at automatically clustering OpenSearch and providing the framework for RabbitMQ clustering, the Transactional Database Tier remains the one piece that administrators must provision themselves. This tool fills that gap, giving you a consistent, repeatable, production-ready MySQL InnoDB Cluster every time. Whether you're deploying Morpheus HA for the first time or rebuilding your database tier after a migration, you're three commands away: If you found this useful, give the GitHub repository a ⭐ and feel free to open issues or contribute. Templates let you quickly answer FAQs or store snippets for re-use. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse