Monthly Archives: September 2016

Unleash the power of the NTNX-AVM – daily_health_report and monthly_ncc_health

I asked myself how could an admin use the NTNX-AVM. So I decided to show and provide some real world examples how this powerful automation VM can be used.

USE CASE: A daily health report should run on the Nutanix cluster and send to a specified email address!

Let’s start with the script itself. There is no script provided by Nutanix except the Nutanix Cluster Check (ncc). It does a decent job but because of the hundred of tests and output it may not be the easiest to start with. So based on the script provided by BMetcalf in the Nutanix Community I developed a script called “daily_health_report.sh” for the NTNX-AVM. It is automatically installed with the NTNX-AVM starting today.

It runs the following  command remote on a CVM which gives you a good overview of the current cluster status.

Okay we do have a script but how to run it once a day? For this case I introduced jobber to the NTNX-AVM.

Learn jobber the fast way

Connect via SSH to the NTNX-AVM and run:

jobber_list

In this case no job is known. I prepared an example which runs the script daily_health_report.sh every day at 04:00.

The easiest way to create this job is to copy the example from the source folder to a file called “.jobber” in the Nutanix home directory.

The last step is just to reload the jobs defined in “.jobber”.

Review the jobber list.

jobber_finished

How does the daily_health_check.sh work?

First of all, this script will not run in your environment because all parameters for the daily_health_check.sh are setup for my lab environment. Okay lets make sure it will run in your environment.

STEP1 – Enable SSH access from NTNX-AVM to the cluster CVMs

The script makes use of ssh/scp to run the commands remote on one of the CVMs. To run a script non-interactive we need to enable password-less authentication between the NTNX-AVM to the CVMs. I wrote a script which enables password-less authentication.

This scripts creates a key pair and deploy the keys to the CVMs. When you run it you need to specify the Cluster IP/Name and the PRISM admin password.

A test ssh connection should work now without requesting a password.

STEP2 – Edit the jobber file

Use an editor of your choice like “vi” and edit the line which starts with ” cmd :  daily_h…” and edit the parameters to your needs.

DO NOT use the cluster IP for host. Use one CVM IP.

  • –host=<YOUR-CVM-IP>
  • –recipient=<RECIPIENT-email>
  • –provider=other                                   // choose other to send email to a local email server
  • –emailuser=<EMAIL-USER>                //  Email user used to authenticate via SMTP (sender)
  • –emailpass=<EMAIL-PASSWORD>    //  Email password used to authenticate via SMTP
  • –server=<EMAIL-SERVER-IP>             // Email server IP
  • –port=<SMTP port>                            // Email server SMTP port

Reload the jobber file.

STEP3 – Test the job

The output should look like this:

edit_test_jobber

Check the email Account that the email was sent and received.

show_daily_email

There it is. Sorry for the German Thunderbird version but you should get the idea how the email looks like. An email with one attachment called “daily_health_report-<DATE>.txt”.

USE CASE: Run a monthly “ncc health_checks run_all” and send the output to a specified email address!

Some Nutanix people would say: “Why don’t you use the ncc instead?” Good point. This post shows how to run ncc every x hours and send an email. But how to run ncc once a month and get all ERROR/FAIL messages in the body?

For this case I created the ncc_health_report.sh script which runs the “ncc health_checks run_all” and send an email.

STEP1 – Extend the “.jobber” file to add this job

The example which can be found on the NTNX-AVM in  “~/work/src/github.com/Tfindelkind/automation/NTNX-AVM/jobber/example/monthly_ncc_health” defines a job which runs on the 1st of each month and calls the ncc_health_report.sh

Edit the ~/.jobber file and add the job text to the end of the file. BUT skip the first line “—“. the file should look like this.

both_jobs

Don’t forget to edit the parameters like in STEP2

Reload the jobber file.

STEP3 – Test the job

WARNING!!!! This may run for a while…

The output should look like this:

ncc_report_test

And an email should be in your inbox:

ncc_report_test_email

I know the format of the body is wired because all “newlines” have been removed. I hope to fix this in the near future.

BTW: I used the hMailServer in my lab environment. This was really the easiest mail server setup I have ever done.

Go hMailServer

 

Nutanix automation VM ( NTNX-AVM ) goes online

Since I started at Nutanix I thought about a way to write and run scripts/tools around the Nutanix ecosystem. But there are different languages which are used by the community. Perl/python/golang/powershell etc. So I asked myself: “Where the hack should I install the runtime and the scripts/tools, because the CVM is a bad place for this”

The answer took me a while but here we go:

Nutanix automation VM called NTNX-AVM

So there is no image which fits all but instead the NTNX-AVM is based on recipes which defines the runtime/scripts/tools which will be installed. The foundation of these are the cloud images which are designed to run on cloud solutions like AWS/Azure/Openstack. These images provide good security from scratch. Another advantage is that the images are already deployed which means there is no different way to install it other then “importing” a vendor controlled image. This is good for maintaining the whole project.

NTNX-AVM v1 when deployed provides golang , git, govc, java, ncli (CE edition), vsphere CLI and the automation scripts from https://github.com/Tfindelkind/automation preinstalled. So for example you can move a VM from container A to container B with the move_vm binary which leverage the Nutanix REST API which is not possible in AHV.

I introduced a job scheduler system called https://github.com/dshearer/jobber to automate tasks/jobs. The advantages are that you are able to review the history of already executed jobs and you have more control when something went wrong.

Use cases for the NTNX-AVM

  • Backup Nutanix VM’s to a NFS store like Synology/Qnap/linux…
  • Move VM from one container to another one
  • Do some daily tasks like generate reports of specific performance counters you would like to monitor which are not covered by Prism
  • anything which talks to Nutanix REST API and needs to be scheduled.
  • …. there will be more

Installation of NTNX-AVM on Acropolis Hypervisor (AHV)

For an easy deployment and usage I created a simple bash script which will do all the hard work.

The deployment for VMware and Hyper-V will follow. At the moment the process is more manual. I will post a “HOW-TO install”.

What you need is a Nutanix cluster based on AHV (>=4.7) and a client where you able to run the bash script. Ubuntu, Debian, Redhat, CentOS, Mac OS should work fine as a client. The Community Edition (CE) is the base of my development environment and is fully supported.

This is how the environment looks like before the deployment. My three node cluster based on Intel NUC.

cluster_before_NTNX-AVM

Image_service_before_NTNX-AVM

Step-by-Step deployment of NTNX-AVM with Deploy Cloud Image script (DCI)

We start at your client system in my case a Mac Book Pro. Download the latest stable release of DCI from https://github.com/Tfindelkind/DCI/releases.  In my case the version v1.0-stable is latest build available. The “Source code (tar.gz)” will work for me.

Release v1.0-stable · Tfindelkind-DCI Google Chrome, Heute at 11.40.54

Change to the Download folder and unpack/untar the file:

Downloads — bash — 92×28 Terminal, Heute at 11.44.46

You can see there are several recipes available but let’s focus just on NTNX-AVM v1 based on CentOS7.

NTNX-AVM recipe config file

IMPORTANT: THE NTNX-AVM needs internet connection when deployed. Because all tools need to be downloaded.

Now we need to edit the recipe config file of the NTNX-AVM to make sure that the IP,DNS,etc. is setup in the way we need it. Use a text editor of your choice to edit the “/recipes/NTNX-AVM/v1/CentOS7/config” file.

You should edit following settings to your needs:

  • VM-NAME          This is the name of the VM guest OS.
  • VM-IP                  The fixed IP
  • VM-NET              The network of VM
  • VM-MASK           The netmask of the network
  • VM-BC                 The broadcast address of the network
  • VM-GW                The gateway
  • VM-NS                 The nameserver
  • VM-USER             The username for the NTNX-AVM which will be created
  • VM-PASSWORD  The password for this user -> Support for access keys will be added soon.
  •                               You need to escape some special characters like “/” with a “\” (Backslash)
  • VCENTER_IP         IP of the vcenter when used.
  • VCENTER_USER   User of the vcenter
  • VCENTER_PASSWORD

This is an example file for my environment:

CentOS7 — bash — 92×28 Terminal, Heute at 11.47.18

NTNX -AVM with DHCP enabled

If you don’t want to specify a fixed IP,DNS,.. you could roll out the NTNX-AVM with DHCP. To do this edit the “/recipes/NTNX-AVM/v1/CentOS7/meta-data.template” file and remove the network part so the file looks like this one. The “ifdown eth0” and “ifup eth0” is related to a bug with the CentOS 7 cloud-image.

Deploy the NTNX-AVM to the Nutanix cluster

Now we are ready to deploy the VM to the Nutanix cluster with the dci.sh script.

We need to specify a few option to run it:

  • –recipe=NTNX-AVM             Use the pre build NTNX-AVM recipe
  • –rv=v1                                    It’s the first version so we use v1
  • –ros=CentOS7                      In this case we use the CentOS7 image and not Ubuntu
  • –host=192.168.178.130      This is the cluster IP of Nutanix/ CVM IP will work too
  • –username/–password      Prism user and password
  • –vm-name                            The name of the Nutanix VM object
  • –container=prod                  In my case I used the container “prod” (production)
  • –vlan=VLAN0                        The Nutanix network where the VM will be connected to

The dci.sh script will do the following:

  • First it will download the cloud image from a CentOS. Then it will download the deploy_cloud_vm binary.
  • It will read the recipe config file and generate a cloud seed CD/DVD image. Means all configuration like IP,DNS,.. will be saved into this CD/DVD image called “seed.iso”.
  • DCI will upload the CentOS image and seed.iso to the AHV image service.
  • The NTNX-AVM VM will be created based on the CentOS image and the seed.iso will be connected to the CD-ROM. At the first boot all settings will be applied. This is called the NoCloud deployment based on cloud-init. This will only work with cloud-init ready images.
  • The NTNX-AVM will be powered on and all configs will be applied.
  • In the background all tools/scripts will be installed

DCI-1.0-stable — bash — 92×28 Terminal, Heute at 12.05.51

The CentOS cloud image and the seed.iso have been uploaded to the image service.

Nutanix Web Console Google Chrome, Heute at 12.06.17

The NTNX-AVM has beed created and started.

Nutanix Web Console Google Chrome, Heute at 12.06.45

Using the Nutanix Automation VM aka NTNX-AVM the first time

Connect via ssh to the NTNX-AVM IP. 192.168.178.200 in my case. First of all we need to make sure that all tools are fully installed because this is done in the background after the first boot.

So let’s check if /var/log/cloud-init-output.log will show something like:

DCI-1.0-stable — nutanix@NTNX-AVM.~ — ssh — 105×28 Terminal, Heute at 07.45.06

The NTNX-AVM is finally up, after … seconds

You should reconnect via ssh once all tools/scripts are installed to make sure all environment variables will be set.

Everything is installed and we can use it.

Test the NTNX-AVM environment

Let’s connect to the Nutanix cluster with the “ncli” (nutanix command line) and show the cluster status.

DCI-1.0-stable — nutanix@NTNX-AVM.~ — ssh — 105×28 Terminal, Heute at 07.54.57

That’s it. NTNX-AVM is up running.

Today I start to implement the ntnx_backup tool which will be able to backup/restore a AHV VM to/from an external share  (NFS, SMB,….)  which will leverage jobber as the job scheduling engine.

Go Ubuntu