In Part 1 we covered how to deploy bitnami Cassandra image on vCenter servers. Now it’s time to configure the Cassandra database and vcloud director cell.
Configuration of Cassandra
- Open the firewall ports so the nodes can communicate with each other and also vCloud Cell with these nodes
[root@cassandra-01 ~]# firewall-cmd --zone public --add-port 7000/tcp --add-port 7001/tcp --add-port 7199/tcp --add-port 9042/tcp --add-port 9160/tcp --add-port 9142/tcp --permanent
success
[root@cassandra-01 ~]# firewall-cmd --reload
success
[root@cassandra-01 ~]$ firewall-cmd --list-ports
22/tcp 7000/tcp 7001/tcp 7199/tcp 9042/tcp 9160/tcp 9142/tcp
- We are going to make some configuration changes in Cassandra, so the first steps is to backup the original file: /opt/bitnami/cassandra/conf/cassandra.yaml
[root@cassandra-01 ~]$ cp /opt/bitnami/cassandra/conf/cassandra.yaml /opt/bitnami/cassandra/conf/cassandra.yaml.orig- Configure Cassandra Cluster Name
#connect to cassandra using the credentials located in /home/bitnami/bitnami_credentials
[bitnami@cassandra-01 ~]$ cqlsh -u cassandra -p wKlsj8LGo5aR
Connected to My Cluster at 127.0.0.1:9042.
[cqlsh 5.0.1 | Cassandra 3.11.10 | CQL spec 3.4.4 | Native protocol v4]
cassandra@cqlsh> UPDATE system.local SET cluster_name = 'vCloud Cluster' where key='local';
cassandra@cqlsh> exit- For fine tuning of Cassandra, we are going to edit /opt/bitnami/cassandra/conf/cassandra.yaml as follow:
| Original Configuration | New parameter |
|---|---|
| cluster_name: ‘Test Cluster’ | cluster_name: “vCloud Cluster” |
| seeds: “127.0.0.1” | seeds: “Your Seed Node 1 IP address, Your Seed Node 2 IP address” |
| listen_address: localhost | listen_address: “192.168.1.10” # Node IP address |
| rpc_address: localhost | rpc_address: 192.168.1.10 #This node IP address |
- Restart the Cassandra service
[root@cassandra-01 ~]$ /opt/bitnami/ctlscript.sh restart cassandra- Check nodetool status and verify node is up and had joined cluster
[bitnami@cassandra-01 ~]$ nodetool status
Datacenter: datacenter1
=======================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns (effective) Host ID Rack
UN 192.168.1.10 267.12 KiB 256 100.0% 3c3ce428-a263-40e1-8cb9-d2867a32f5c9 rack1Note: If you see any error, for example “nodetool: Failed to connect to ‘127.0.0.1:7199’ – ConnectException: ‘Connection refused (Connection refused)’. Explore the cassandra logs to identify the root cause. Cassandra logs path: /opt/bitnami/cassandra/logs/cassandra.log
- Cassandra Cluster: To add additional nodes to the Cassandra cluster, deploy 3 more Bitnami Cassandra virtual machines and repeat the above steps.
Create superuser
- We are not going to use superuser “cassandra”, so in this step we are creating a new superuser. Connect to the database cluster (from any node):
Connected to vCloud Cluster at 192.168.1.10:9042.
[cqlsh 5.0.1 | Cassandra 3.11.10 | CQL spec 3.4.4 | Native protocol v4]
Use HELP for help.
CREATE ROLE vcloud WITH SUPERUSER = true AND LOGIN = true AND PASSWORD = 'YourSecurePassword';Configure vCloud Director
The use of SSL with Cassandra is optional. In our case we decided not to enable SSL for Cassandra, so we included the configuration parameter cassandra.use.ssl to 0 in the global.properties file on each cell ($VCLOUD_HOME/etc/global.properties)
- Login to vCloud Director cell and run the cell-management-tool utility to configure a connection between vCloud Director and the nodes in the Cassandra cluster. In this case metrics data is retained for 15 days.
root@cell-alicia [ /opt/vmware/vcloud-director/bin ]# ./cell-management-tool cassandra --configure --create-schema --cluster-nodes "192.168.1.10,192.168.1.11,192.168.1.12,192.168.1.13" --username vcloud --password "YourSecurePassword" --ttl 15 --port 9042
Verifying Cassandra settings...
Cassandra setting valid for node: 192.168.1.10
Cassandra setting valid for node: 192.168.1.11
Cassandra setting valid for node: 192.168.1.12
Cassandra setting valid for node: 192.168.1.13
Cassandra configuration settings verified successfully
vcloud_metrics keyspace created...
vm_metrics table created...
adding configured metrics to the schema...
adding counter: cpu.usage.average
adding counter: cpu.usagemhz.average
adding counter: cpu.usage.maximum
adding counter: mem.usage.average
adding counter: disk.provisioned.latest
adding counter: disk.used.latest
adding counter: disk.read.average
adding counter: disk.write.average
vapp_metrics table created...
vdc_metrics table created...
org_metrics table created...
Persisting Cassandra settings...
Success. The monitoring service is now configured to persist data into cassandra nodes(192.168.1.10,192.168.1.11,192.168.1.12,192.168.1.13), vCD cell(s) must be restarted if they are already running.
root@cell-alicia [ /opt/vmware/vcloud-director/bin ] service vmware-vcd restart
Once the cell is back online you are going to see the metrics in the virtual machines tab “Monitoring Chart”:
Default metrics are: disk.read.average, disk.provisioned.latest, cpu.usage.average, disk.write.average, cpu.usagemhz.average, mem.usage.average, cpu.usage.maximum, disk.used.latest.
The current metrics are directly retrieved from the VMware vCenter Server™ database via API calls, for that reason, there are ways to add more metric performance collectors if you need to.
Additional Resources
https://docs.datastax.com/en/cassandra-oss/3.0/cassandra/configuration/secureConfigNativeAuth.html
Disclaimer
Last updated: May 17, 2018
The information contained on www.bakingclouds.com website (the “Service”) is for general information purposes only.
Baking Clouds assumes no responsibility for errors or omissions in the contents on the Service.
In no event shall Baking Clouds be liable for any special, direct, indirect, consequential, or incidental damages or any damages whatsoever, whether in an action of contract, negligence or other tort, arising out of or in connection with the use of the Service or the contents of the Service. Baking Clouds reserves the right to make additions, deletions, or modification to the contents on the Service at any time without prior notice.
One thought on “Bitnami Cassandra Database for Storing Historic vCloud Metrics Data – Part 2”
Comments are closed.