Databases
Now let's deploy the MariaDB database cluster.
Before we proceed, let's ensure that you have correctly set or defined quite a few settings.
dalet_flex_db_mysql_admin_password: "{{ vault_dalet_flex_db_mysql_admin_password }}"
dalet_flex_db_mysql_exporter_password: "{{ vault_dalet_flex_db_mysql_exporter_password }}"
dalet_flex_db_mysql_replication_password: "{{ vault_dalet_flex_db_mysql_replication_password }}"
dalet_flex_db_mysql_db_flex_enterprise_password: "{{ vault_dalet_flex_db_mysql_db_flex_enterprise_password }}"
dalet_flex_db_mysql_db_flex_authentication_password: "{{ vault_dalet_flex_db_mysql_db_flex_authentication_password }}"
dalet_flex_db_mysql_db_flex_metadata_password: "{{ vault_dalet_flex_db_mysql_db_flex_metadata_password }}"
dalet_flex_db_mysql_db_flex_webtransfer_password: "{{ vault_dalet_flex_db_mysql_db_flex_webtransfer_password }}"
dalet_flex_db_mysql_db_flex_usage_password: "{{ vault_dalet_flex_db_mysql_db_flex_usage_password }}"
Like many other places in collection's configuration, password-related variables map to their vault-encrypted vault_-prefixed equivalent. It is manadatory that these variables are defined in the secrets.yml file.
If you've used templating, these vaulted variables have already been randomly defined for you. Nothing's required for operator's perspective.
Database Type
This step is only required when not using Database-as-a-service (e.g. AWS RDS).
This is conditionned by the variable:
dalet_flex_platform_dbaas_enabled: bool
If enabled, Ansible will assume you're using a third-party managed MariaDB instances.
If disabled, Ansible will deploy a self-managed MariaDB cluster.
Database-as-a-Service
Please ensure that the next variables are defined in correctly defined in your platform's settings so Dalet Flex is instructed to connect to the third-party managed database.
dalet_flex_db_mysql_host: ""
dalet_flex_db_mysql_port: 3306
dalet_flex_db_mysql_allowed_hosts_rw: []
dalet_flex_db_mysql_allowed_hosts_ro: []
where the allowed_hosts ones allows for client network address whitelisting as defined in reference guide.
You're all set, you can now skip the rest of this section.
Self-Managed Cluster
If instructed to do so, Ansible will be used to deploy a master-slave cluster with high-availability and failover support on the 2 server instances that are part of the db group in your Ansible's inventory file.
Please ensure beforehand that the group exist with 2 defined DB instances (not 1, not 3: 2).
Data Storage
Databases handle data and data resilience is paramount.
It is usually recommended to use multiple disks for database instances:
- Disk for OS itself
- Disk for database content
The main reason is that OS data is not necessarily important. OS doesn't grow much in terms of disk space, can crash or, when using virtual machines, can be fully destroyed and recreated. Data disk however, must be preserved, no matter what.
How database disk is managed, is up to operator but multiple options can be adopted:
- Single virtual disk on virtual machine, because underlying block device storage provided already provides replicated, distributed storage.
- Clustered physical disks on metal, using software or hardware RAID replication, or advanced filesystems like ZFS.
- Logical Volume Management (LVM) or ZFS-like approach to ensure volume can grow overtime, disks can be replaced and so on ...
Regardless on how data volume is being managed, Flex default configuration is to store MariaDB content within the /flex/mariadb directory as defined in ansible/collections/ansible_collections/dalet/flex/playbooks/group_vars/db.yml file:
dalet_dbaas_mariadb_base_dir: "{{ dalet_flex_storage_global_data_dir }}/mariadb"
It is important that the data volume you have provisionned is mounted in the chosen directory described by the aformentionned variable. This is achieved by adding a custom Ansible pre-tasks file for db group of machines in ansible/tasks/db/pre.yml.
Redundancy and Failover
The deployed MariaDB cluster will run against 2 nodes:
- a master (or primary, active), which handles all read/write requests.
- a slave (or secondary, inactive), which real-time replicates any change from master and is ready to take over, should master instance fails.
This mechanism works through usage of a virtual IP (or VIP) within your private network. VIP is basically a floatting IP address, an IP moving from one server instance to another depending on various criteria.
For database cluster, DB VIP is assigned to the master instance (whoever that is from the pool). This ensures that SQL clients always connect to the very same IP address (no configuration change), whatever happens at the infrastructure level. Should MariaDB service fails on current master (crash, intended maintenance, disk issue, network issue, anything really ...), the VIP binding criteria will fail and the current slave will bind DB VIP and take over traffic. Once former master comes back to life, it'll boot as a slave and will recover changes from the newly elected master peer.
A key element to take into account is that VIP works through VRRP protocol at network L2 layer. It relies on unique virtual router identifier (VRID) to be known and shared only by the peers who are eligible for the given VIP.
The VIP address be unique on the given network L3 network, so one must be picked carefully. You must ensure that this is a free, unused IP address, that is not assigned to any existing (or future) machine (including the database instances themselves). The VIP must not be part of any DHCP server's pool, again, to ensure it won't be assigned to anyone.
The following parameters must be filled (example):
dalet_flex_db_mysql_host: "DB VIP ADDRESS"
dalet_flex_db_mysql_private_virtual_router_id: 1-255
dalet_flex_db_mysql_private_interface: eth0
dalet_flex_db_mysql_private_control_interface: eth0
This defines which VIP and VRID are to be used and which instance's network interface is to be used to share VRRP packets (control) and to bind the VIP (can be the same network interface).
Many other settings can be used to fine-tune your self-managed database and optimize its inherent performances, as described in reference guide.
Deployment
Finally, let's deploy the MariaDB cluster:
$ opsctl deploy -p dalet.flex.db