Tungsten Clustering is an extraordinarily flexible tool, with options at every layer of operation.
In this blog post, we will describe and discuss the two different methods for installing, updating and upgrading Tungsten Clustering software.
When first designing a deployment, the question of installation methodology is answered by inspecting the environment and reviewing the customer's specific needs.
Staging Deployment Methodology
All for One and One for All
Staging deployments were the original method of installing Tungsten Clustering, and relied upon command-line tools to configure and install all cluster nodes at once from a central location called the `staging server`.
This staging server (which could be one of the cluster nodes) requires SSH access to all database nodes.
The simple steps include:
- cd to the top-level software staging directory. The default directory for extracting new tarballs is under /`opt/continuent/software`
- extract the software tarball
- cd into the newly-extracted directory
- configure with `tools/tpm configure`
- install using the `tools/tpm install` command
During execution, the `tools/tpm install` command uses SSH to install the Tungsten software on all nodes in the cluster in parallel. For example, you could install a 4-site composite cluster with 3 nodes per site across multiple global regions with a single command and all 12 nodes would be handled at once.
Future configuration updates would be handled the same way (i.e. via `tools/tpm update` from the extracted software directory), and normally would affect all the cluster nodes at once.
The `--no-connectors` option may also be used to allow for the graceful cycling of the Connector connectivity layer.
INI Deployment Methodology
The Strength of Individuality
The INI methodology was developed with two situations in mind - no SSH access, and the ability to support per-node configuration files for automation tools like Chef, Puppet and Ansible.
In this deployment model, an INI file is placed on every host associated with the cluster first (`/etc/tungsten/tungsten.ini` by default). This is the equivalent to running the `tools/tpm configure` step from the staging method.
In the INI world, any `tpm install` or `tpm update` reads the configuration for that one node and executes the install or update ON THAT NODE ONLY. The presence of an INI file tells `tpm` to limit install and update actions to the current host.
In Tungsten Clustering v4.0 and later, `tpm` will automatically search all INI files within the `/etc/tungsten` and current directories.
Once the INI file is populated on all cluster nodes, the procedure is similar to the staging method, except for the fact that it must occur on EVERY node individually.
The simple steps include:
- cd to the top-level software staging directory. The default directory for extracting new tarballs is under /`opt/continuent/software`
- extract the software tarball
- cd into the newly-extracted directory
- install using the `tools/tpm install` command
Note that the `tpm configure` step is gone since the configuration is now stored in the INI file.
Staging versus INI - Differences
What's the difference between the two methods of deployment?
Here are some of the key differences between Staging and INI deployments:
Staging
- there is just one staging directory needed which resides on a single host (which may be a member cluster node or a separate host)
- configuration is performed centrally in the staging directory on a single host
- requires passwordless SSH
- installs and updates multiple cluster nodes
- provides a one-command cluster upgrade path
INI
- every node has a locally-extracted staging directory
- configuration is performed locally on each node via the `/etc/tungsten/tungsten.ini` file
- does NOT require passwordless SSH
- installs and updates one single cluster node at a time
- installs and updates must be performed on every node one-by-one
- there is NO one-command cluster upgrade path
- ideal for automated environments
- possible to have multiple configuration files in
/etc/tungsten
Click here to read more about "Comparing Staging and INI tpm Methods".
Staging versus INI - Decision
We always recommend the INI deployment for many reasons:
- INI deployments have a very clear standard configuration location
- INI deployments are very easy to tweak on a per-host basis
- INI deployments are cloud and devops-friendly
- INI is required for certain topologies (i.e. Composite Multimaster)
Deployment Type - How Do I Know?
Determining the deployment type after install
To determine which method your current deployment uses, check the output of:
shell> tpm query deployments | grep deployment_external_configuration_type
"deployment_external_configuration_type": "ini",
If you see the value of "ini", then the INI method was used to deploy your cluster.
~or~
shell> ls -l /etc/tungsten/*
-rw-rw-r-- 1 tungsten tungsten 1347 Oct 5 16:06 /etc/tungsten/tungsten.ini
If you use the `ls` command and see at least one `.ini` file, then you are using the INI method to configure your cluster.
Staging Directory - How Do I Know?
Determining the staging directory location
To determine the staging directory location from where your cluster was installed, check the output of:
shell> tpm query staging
# Installed from tungsten@staging-host:/opt/continuent/software/tungsten-clustering-5.0.1-136
When using the INI method of configuration, the staging-host in the above example output would display the host name of the local host.
Tungsten Clustering is the most flexible, performant global database layer available today - use it underlying your SaaS offering as a strong base upon which to grow your worldwide business!
For more information, please visit https://www.continuent.com/solutions
Want to learn more or run a POC? Contact us.
Comments
Add new comment