For this guide, we will be installing Tesora DBaaS Enterprise Edition (EE) version 1.4.
First, you will need to download the product here. Once you complete their form, instructions on supported configurations and documentation will be provided.
In our case, we wanted to plug our Tesora DBaaS EE controller into our existing Redhat Enterprise Linux (RHEL) OpenStack (OSP) 6.0 environment. Therefore, for our non-production, lab PoC environment, we created a separate VM for the DBaaS controller.
Production environments will have similar, but unique architectural requirements, therefore we strongly recommend that you replicate these steps only for lab or PoC environments. Please get in touch if you would like to discuss a more robust Tesora DbaaS production environment.
CONTROLLER_IP = br-ex interface IPv4 address on our RHEL OSP 6.0 all-in-one install
DBAAS_CONTROLLER_IP = IP of our Tesora DBaaS VM running OpenStack Trove services.
Before continuing, make sure the Tesora DBaaS VM is secured as per your organizational policies. It will also need to communicate ingress and egress to your CONTROLLER_IP. Additionally, the default iptables firewall rules on your RHEL OSP 6.0 all-in-one host will restrict external communications to some of the services you will be integrating with (RabbitMQ, MariaDB, etc). You’ll need to allow traffic from your DBAAS_CONTROLLER_IP source on your node. By default, egress traffic should not be restricted on either node. Therefore if you add an INPUT allow rule like:
to your iptables config, this should suffice.
Next, install the Tesora repo and packages:
Next, memcached and python-memcache need to be installed and configured.
Now edit: /etc/openstack-dashboard/local_settings with your favorite editor (nano, vi, etc)
and make the following changes:
At this point, you will either need to enable SELinux to allow the web server to communicate with the OpenStack Services. Alternatively, you could disable selinux in /etc/sysconfig/selinux and reboot.
Now we need to fix an ownership packaging bug:
Now set memcache and httpd to start on-boot and start now as well:
Once the above is complete, you now need to configure the Tesora’s DBaaS controller. This is done by running: /opt/tesora/dbaas/bin/setup.sh and providing it accurate inputs!
The Tesora documentation is very thorough and the script includes recommended defaults as you proceed. We recommend that you refer to the documentation when completing this step, although we will point out some helpful information for the required inputs. Note that we’ve substituted the defaults required for the RHEL OSP 6.0 environment we are integrating with. They’ll be contained within the [brackets].
For the first run, you’re going to want to answer yes to tailor the trove configuration files.
Configuration for the Trove database:
MySQL host/port? [<CONTROLLER_IP>:3306]
MySQL user for Trove? [trove]
MySQL password for Trove? [trove]
The default trove user is generally fine, but we’d recommend a stronger password for almost all environments.
Next, you’ll specify the Trove service details that will need to match what is set in Keystone. Later the installer will prompt you to ask if you’d also like the service registered in Keystone using these same details.
Tesora DBaaS admin user? [trove]
Tesora DBaaS admin password? [trove]
Tesora DBaaS admin tenant? [services]
Tesora DBaaS Region? [RegionOne]
Note, we recommend you use a stronger admin password. Also, you’ll need to confirm the tenant and region for your install. For our RHEL OSP 6.0 install, the tenant is: services by default and the default region is: RegionOne. This will vary based on the configuration and specific defaults of the different OpenStack distributions.
Now you need to provide the API end points for the other services that Trove needs to access. Note, once you submit the Keystone_admin_URL, the CONTROLLER_IP will be substituted in the latter defaults automatically.
URLs for OpenStack services:
Keystone admin URL? [http://<CONTROLLER_IP>:35357/v2.0]
Keystone public URL? [http://<CONTROLLER_IP>:5000/v2.0]
Nova URL? [http://<CONTROLLER_IP>:8774/v2]
Cinder URL? [http://<CONTROLLER_IP>:8776/v1]
Swift URL? [http://<CONTROLLER_IP>:8080/v1]
If you’re not sure on the above URLs, here’s some guidance. The keystone_admin_url can be retrieved from a node running nova. In the case of our RHEL OSP 6.0 node, if we look in the nova config, it will be listed:
The other service end points can quickly be confirmed in the Horizon -> Compute -> Access & Security -> API access.
For our RHEL OSP 6.0 installation, once the keystone_admin_url is updated correctly, all other service URLs should be correct, so you can hit enter to accept.
Next, the installer will request details on a user with admin privileges to communicate with Nova. Note that you will probably want to use a stronger password than the default. For the lab RHEL OSP 6.0 environment, we can use the defaults, except substitute the keystone password for our admin user found in /root/keystonerc_admin. Alternatively, you could create a new user with admin privileges.
Nova admin user for Trove operations
Nova user? [admin]
Nova password? [update_with_pw_in_keystonerc_admin]
Nova tenant? [admin]
For the AMQP details, we need to update the host and we can accept the default user/password as these already exist.
RabbitMQ host? [<CONTROLLER_IP>:5672]
RabbitMQ user? [guest]
Rabbit password? [guest]
Now, we need to set the IP of our RHEL OSP 6 controller again. This value will be used in the trove guest agent config to specify the RabbitMQ host to forward too. If you specify a different value from the above RabbitMQ host, this value will take precedence in the guest agent config.
Guest agent configuration:
Controller host or address reachable from guest instances? [CONTROLLER_IP]
Setup the Trove Database
On your RHEL OSP 6.0 all-in-one host:
Also, you’ll need to allow the DBAAS_CONTROLLER_IP to connect from the remote host. To do this, you’ll need to issue a grant in the MySQL prompt:
Once you’ve completed the install, you can and should remove the permissions to your admin user from the DBAAS_CONTROLLER_IP like so:
Create the Trove database?
Requires MySQL admin credentials. (y or n) [y]
MySQL admin user? [root]
MySQL admin password? [insert_MARIADB_PW]
Register Trove in Keystone
Configure Trove in the identity service?
Requires keystone admin credentials. (y or n)[y]
Keystone admin user? [admin]
Keystone admin password? [pw_from_keystonerc_admin]
Keystone admin tenant? [admin]
Trove URL? [http://DBAAS_CONTROLLER_IP:8779]
At this point, the base configuration of trove should be complete. Let’s verify that we’re able to connect to the trove.
On your RHEL OSP 6.0 node, source the keystonerc_admin file and issue a trove list command to confirm that the API call succeeds:
Since we have no trove DB instances created, the return should be empty:
~(keystone_admin)]# trove list
| ID | Name | Datastore | Datastore Version | Status | Flavor ID | Size |
Load a Datastore and Build an Instance
Foremost, we need to set some environment variables. On our DbaaS controller host, we need to replicate our /root/keystonerc_admin file. You can either copy-paste the contents, scp, or any other way you feel comfortable.
Once there, we also need to add two environment variables to the bottom:
myName and myPassword will be provided to you by Tesora.
Now, save the file and source it on the dbaas-controller.
We can now run the nifty add datastore script from Tesora which automates downloading the image from the Tesora repo, uploading it into glance and associating a new datastore with the image. In this case we’ll load a MySQL 5.6 image to test our new install.
Once we have created the first datastore, we can create a trove instance from it. This is possible via the trove API client or Horizon. In this case, we’ll do the latter. Navigate in your web browser too: http://<<controller_IP>>/dashboard/project/databases/ and click Launch instance on the right.
A few notes on the configuration of the instance:
Instance Name: [Provide a name of your choice]
Flavor: [This is a bundle of the hardware specifications of the instance. This needs to meet or exceed the requirements published by Tesora in their documentation. For our MySQL instance, we will use an m1.medium, but in practice you will likely want to create flavors for different database requirements.
Volume Size: [This is the size of the persistent data volume in cinder. We’ll use 10 – 10GB]
Datastore: [Select your MySQL 5.6 datastore]
Switch to the Networking Tab and select your private network.
Switch to the Initialize Databases tab and specify a database name name, admin user, and password. This step is not required, but will demonstrate the db provisioning capabilities of trove.
Now you’re ready to click launch! Once complete, you should have an instance in Nova, with MySQL 5.6 with your database name, user, and password created. You can test it my connecting using any MySQL client.