The code here has been merged into the https://github.com/PureStorage-OpenConnect/vertica repository as of 2021-June-07. Please look there for more validated versions of the code and releases.
This repository contains example Ansible playbooks with code related to cloning Vertica databases on Pure Storage FlashBlades. There are two main examples, aligned with the two most common use cases:
- Test/Dev for production databases — Cloning a database on the same FlashBlade where the production database operates. This example is in the vertica-clone-db.yml playbook.
- Validation testing for DR database copies — Cloning from a DR copy of a production database being continuously replicated via FlashBlade Object Replication. This example is in the vertica-test-dr.yml playbook.
While these examples will likely work with minor modification for many environments, they're meant to be adapted for before being used in production. The rest of this README file explains the structure of the playbooks and how to customize them for experiments.
- The base assumption is that you already have a Vertica PoC environment where you can experiment with this functionality.
- That environment is already configured with Ansible, the right versions of Python, and the Pure Storage FlashBlade collection from Ansible Galaxy.
- The code is being run from the Management Console node (
mc
), and that node has the FlashBlade collection from Ansible Galaxy. It doesn't have to be the MC host if there isn't one; a regular test host with the right setup and keys will work too. Usegit clone
to get a copy of this repository onto that node. - The playbooks use the
root
user to connect to the Ansible hosts. When they need to execute commands as the Vertica DB user, they userun_as
.
The code in this repo was developed and tested using the Vertica PoC environment set up using the playbooks in the Vertica PoC repository. It might be useful option if you're starting from scratch or evaluating Vertica Eon mode.
- Modify the hosts.ini file to match your testing environment. There are four main host groups:
mc
— the Management Console host where the playbooks are going to runsrc_cluster
— the group of hosts that constitute a (sub)cluster providing the source database that will be cloned.dr_cluster
— the group of hosts that will be used to revive the clone of the DR database copy at the DR destination site.test_cluster
– the group of hosts that will be used for test/dev work at the primary site where the production database lives.
- Modify the
ansible_user
andansible_ssh_private_key_file
variables in the hosts.in file to point to the appropriate user and files. The playbooks usesu
as thebecome_method
to become the Vertica DB user, so the ansible_user needs to be able to do that. Otherwise, you may need to modify the method to something that works for you. - Set the appropriate values in the source_me.sh file. These are used to set the environment variables picked up by the playbooks and configure the infrastructure details during the run. Each variable includes a comment explaining that it does and how it should be set. If you're testing with a single site and FlashBlade (e.g., Test/Dev cloning), there's no need to set the Destination variables.
Once you've made the customizations, running the playbooks is simple:
- Go into the directory where this code got installed. If you need to activate a Python virtual environment to get access to the right versions and paths, do so.
- Source (don't execute) the
source_me.sh
file in that terminal session. This will make the configuration variables available in the environment for the playbooks to pick up during the run. If you need to change a particular variable afterwards during testing, you can either edit and source the file again, or just export a new value from the command line. - Run the playbook for the scenario you want to test, specifying the local
hosts.ini
file as the source of the host definitions:- Test/Dev Cloning —
ansible-playbook -i hosts.ini vertica-clone-db.yml
- DR Validation —
ansible-playbook -i hosts.ini vertica-test-dr.yml
- Test/Dev Cloning —
There might be certain assumptions of configurations in the playbook code that don't match your environment. If that's the case, either change them in the playbook, or parameterize them and add the new parameters to the source_me.sh
file.