Using a Database Server or Service
Turbonomic supports a remote Database for historical data. This configuration allows for high availability, backups and handling more IO demands for larger environments or from remote SQL queries (reporting, etc).
This is an overview of the requirements for a remote DB. The DB needs to be created before deploying Turbonomic. Once created, you will need to make changes in the cr yaml. The following are typical settings for a MySQL or MariaDB instance.
- Preference: MariaDB 10.5.13. MySQL 5.7 is also supported
- Cluster configuration: master/replica where Turbo communicates to a single replica.
- Galera configuration is not supported
- MariaDB 10.5 requires min. 10.5.13.
- Select network and security policies that allows communication between the k8s cluster and the Database server. Leave DB port as 3306.
- 8 Gb Memory / 2 vCPU minimum
- Storage: 100 GB, set to auto-increase, or provide 500 GB
- encryption is supported
Your DB will require the following configurations:
-
Create the DB instance with the specifications above, and then in Server Configuration (AWS RDS Parameter Group), make the following changes and save:
- event_scheduler on
- log_bin_trust_function_creators on (set its value to ’1′)
- max_allowed_packet 200000000
- sql_mode ERROR_FOR_DIVISION_BY_ZERO, NO_AUTO_CREATE_USER, NO_ENGINE_SUBSTITUTION
- explicit_defaults_for_timestamp should be set to OFF
- wait_timeout set to 28800
-
Create a Turbonomic admin user that will be used by the deployment to create application users, grant privileges. You can define whatever password you want, but it should be reflected in the custom resource yaml. Using an mysql client or CLI, run the following commands against your DB:
CREATE USER 'turboadmin'@'%' IDENTIFIED BY 'vmturbo';
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD, PROCESS, REFERENCES, INDEX, ALTER, SHOW DATABASES, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, REPLICATION SLAVE, REPLICATION CLIENT, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, CREATE USER, EVENT, TRIGGER ON *.* TO 'turboadmin'@'%' WITH GRANT OPTION;- If you are using an Azure DB service, see section for “Azure DB Service – Additional Configuration”.
- Update the Turbonomic Custom Resource yaml for the external DB properties, and apply. Options to specify the user and password include:
- Values directly in CR
- Use kubernetes secrets, see section Using a Database: Secrets
- Leverage a vault + webhook injection method documented here
For values directly defined in the CR, use the example below as a guide that would be used for MYSQL. This example also contains optional parameters. For a complete list of options, refer to our custom resource definition for our operator under the validation openAPIV3Schema section in the CRD yaml here.
global:
externalDBName: yourDB.yourURL.com
properties:
global:
enableSecureDBConnection: true
#comment out sqldialect parameter for MariaDB
sqlDialect: MYSQL
dbPort: 6033
dbRootPassword: vmturbo
dbRootUsername: turboadmin- Apply the custom resource yaml to deploy Turbo.
When using a supported Azure DB PaaS service, you will need to pre-create the application databases and users, and then provide this information to the custom resource yaml.
- First, complete steps 1 and 2 from “DB Configurations” in the first section.
- Next create application users and empty databases that Turbonomic will use. Note, do not change the user name.
create user 'action'@'%' identified by 'vmturbo';
create user 'auth'@'%' identified by 'vmturbo';
create user 'clustermgr'@'%' identified by 'vmturbo';
create user 'cost'@'%' identified by 'vmturbo';
create user 'group_component'@'%' identified by 'vmturbo';
create user 'market'@'%' identified by 'vmturbo';
create user 'plan'@'%' identified by 'vmturbo';
create user 'repository'@'%' identified by 'vmturbo';
create user 'topology_processor'@'%' identified by 'vmturbo';
create user 'history'@'%' identified by 'vmturbo';
create database action;
create database auth;
create database clustermgr;
create database cost;
create database group_component;
create database market;
create database plan;
create database repository;
create database topology_processor;
create database vmtdb;
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, REFERENCES, INDEX, ALTER, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, EVENT, TRIGGER ON action.* TO 'action'@'%';
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, REFERENCES, INDEX, ALTER, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, EVENT, TRIGGER ON auth.* TO 'auth'@'%';
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, REFERENCES, INDEX, ALTER, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, EVENT, TRIGGER ON clustermgr.* TO 'clustermgr'@'%';
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, REFERENCES, INDEX, ALTER, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, EVENT, TRIGGER ON cost.* TO 'cost'@'%';
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, REFERENCES, INDEX, ALTER, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, EVENT, TRIGGER ON group_component.* TO 'group_component'@'%';
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, REFERENCES, INDEX, ALTER, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, EVENT, TRIGGER ON market.* TO 'market'@'%';
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, REFERENCES, INDEX, ALTER, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, EVENT, TRIGGER ON plan.* TO 'plan'@'%';
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, REFERENCES, INDEX, ALTER, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, EVENT, TRIGGER ON repository.* TO 'repository'@'%';
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, REFERENCES, INDEX, ALTER, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, EVENT, TRIGGER ON topology_processor.* TO 'topology_processor'@'%';
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, REFERENCES, INDEX, ALTER, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, EVENT, TRIGGER ON vmtdb.* TO 'history'@'%';
GRANT PROCESS on *.* TO 'history'@'%';
GRANT PROCESS on *.* TO 'cost'@'%';
GRANT PROCESS on *.* TO 'group_component'@'%';
flush privileges;- Modify the custom resource yaml to reflect the external DB endpoint and all the users created, and apply. Options to specify the user and password include:
- Values directly in CR
- Use kubernetes secrets, see section Using a Database: Secrets with SCENARIO 2
- Leverage a vault + webhook injection method documented here
For values directly defined in the CR, use the example below as a guide. Remember to substitute your values for your “turboadmin” (dbRootUsername), the turboadmin password (dbRootPassword), and “yourDB”.
global:
externalDBName: yourDB.yourURL.com
properties:
global:
enableSecureDBConnection: true
dbRootPassword: vmturbo
dbRootUsername: turboadmin@yourDB
action-orchestrator:
actionDbUsername: action@yourDB
actionDbPassword: vmturbo
auth:
authDbUsername: auth@yourDB
authDbPassword: vmturbo
clustermgr:
clustermgrDbUsername: clustermgr@yourDB
clustermgrDbPassword: vmturbo
cost:
costDbUsername: cost@yourDB
costDbPassword: vmturbo
group:
groupComponentDbUsername: group_component@yourDB
groupComponentDbPassword: vmturbo
history:
historyDbUsername: history@yourDB
historyDbPassword: vmturbo
market:
marketDbUsername: market@yourDB
marketDbPassword: vmturbo
plan-orchestrator:
planDbUsername: plan@yourDB
planDbPassword: vmturbo
repository:
repositoryDbUsername: repository@yourDB
repositoryDbPassword: vmturbo
topology-processor:
topologyProcessorDbUsername: topology_processor@yourDB
topologyProcessorDbPassword: vmturbo- Apply the custom resource yaml to deploy Turbo.