Summary

In our first ATC Insight Examples of High-impact Automations Across IT Infrastructure  we dove into a couple of automation efforts that we use in our daily work life in the lab to help speed up the delivery of Proof of Concepts (POCs).  Consider this ATC Insight as the next volume (Volume 2).  In this volume, we continue to highlight a few more time-saving automated tricks specifically in the world of compute and virtualization.  Again, these automation use cases help speed up the time to delivery of POCs to our customers in the ATC.

ATC Insight

In our first ATC Insight, Examples of High-impact Automations Across IT Infrastructure we dove into a couple of specific automation efforts we built to help with scaling the demand around the ATC Lab Services POCs (Proof of Concepts).  Now, in this next volume, we continue to highlight a few more time-saving tricks that automation can give us to speed up the time of delivery of POCs to our customers.

vCenter Ansible Deployment

By: Phil Canman

The Problem

After reading the heading of this section, most of you might say "Why would you need to automate a vCenter deployment?" If you have not installed vCenter in a while, the ISO install is pretty easy to follow. You mount the ISO, fill out the forms, and viola it just works. So why again? Well, in the lab we deploy vCenters all the time...we mean all the time, like every day! So, because this is a very repetitive task for us, we use Ansible to cut down the time it takes to deploy vCenters.  Specifically, we use the embedded OVF tool to save us time in the deployment. Yes, it still follows pretty much the same process, but there are no ISO's to mount.  Just fill out the form and a few minutes later you have deployed vCenter. Below are some detailed steps we took to get the Ansible playbook to work.

The Solution

Ansible Tower was used to deploy the solution below.  Here is the documentation we provided to the ATC teams to perform the vCenter deployment:

After you log in to the Ansible Tower instance, click on the template button on the left side menu bar. From there, you can see all the available playbooks that can be deployed/used. Look for the "Deploy VCSA Appliance (vCenter) to ESXi Host" template, and then click the launch button (rocket ship icon) to start the survey. 

Currently, you can deploy 3 versions of vCenter. This is a multiple-choice option in the survey named vCenter version.

The 3 choices are:
1. VMware-vCenter-Server-Appliance-6.7.0.14000-9451876_OVF10.ova
2. VMware-vCenter-Server-Appliance-6.7.0.40000-14367737_OVF10.ova
3. VMware-vCenter-Server-Appliance-7.0.0.10100-15952498_OVF10.ova

  • All the password options default and you will be asked to change the password upon deployment.
  • The vCenter network name must be a standard switch-backed port group
  • You cannot use this playbook to deploy vCenter to another vCenter. If there is a need to do this, we create another playbook for this purpose.

See the survey screenshot below to identify what information you will need to deploy vCenter via tower.

How much time did it save?

The finished job looks like the below screenshot. The actual deployment of vCenter takes less than 10 minutes to complete depending on the network and the server speed. Once vCenter is deployed, it takes another 10 minutes or so for vCenter to configure itself.  If you compare this with deploying vCenter manually for those that do not have the ISO handy, or deploy vCenter every now and then and would need to review the process every time, the savings are substantial.  We believe the time it takes to deploy is cut in half from roughly an hour down to 20 minutes.

You can watch the post-deploy vCenter configuration process by going to the management web GUI at port 5480. See the post-deploy message in Ansible Tower for the URL below.

SPEC CPU 2017 Ansible Automated Deployment

By: Phil Canman

The Problem

SPEC CPU 2017 is a CPU benchmark utility used by the industry to provide several sets of scores to compare CPU performance.  Once again, we call out the fact that we pick our automation efforts based on the demand of the activity. The common use case in the ATC is to compare two different hardware servers and identify the strong and/or weak areas of the servers in question (from the CPU perspective).  We use this tool quite often in our testing in the Advanced Technology Center (ATC).  More information can be found about SPEC CPU 2017 from their website at https://www.spec.org/cpu2017/.  Although SPEC CPU 2017 is not complicated to install, it can be time-consuming to read the documentation and understand it.  Having an easy button here is a great win for the testing teams.  

The Solution

Ansible automation for the win!  The Ansible scripts were designed to aid in the speed of installation of SPEC CPU 2017.  The Ansible scripts solve this problem by automating the installation of SPEC CPU 2017 and also kicking off the first test for the user.  The SPEC CPU 2017 automation with Ansible also has the added benefit of keeping our tests consistent and standardized across separate installations for different customer Proof of Concepts (POCs).

How much time did it save?

With automation, we can have SPEC CPU 2017 installed and benchmarking in as little as 4 minutes.  This is a drastic improvement over the 1 to 2 hours needed to research what is needed to install the benchmark and then perform the install.  

The high-level Ansible installation process:

  • installs all the needed dependencies
  • transfers the SPEC CPU 2017 ISO to the server
  • runs the installer utility
  • customizes the benchmark input file
  • kicks off the benchmark

The user just needs to come back in 24 hours to get the results!

PowerCLI for VMware 

By: Mark Cooper

The Problem

WWT clients may have hundreds or thousands of VMs running on VMware ESXi. These client request changes to some or all of VMs regularly. These changes are typically simple but doing them through the GUI on this scale of VMs would be too cumbersome. There is a better way. 

The Solution

PowerCLI and the Windows PowerShell ISE provides a robust mechanism for executing changes at scale. Here are a few examples of the types of tasks we regularly complete here.  

Example:

This script connects to vCenter, gets all the VMs that are powered on, disconnects the NICs, changes to VLAN 100, sets the NICs to connect at startup and reboots them.  The reboot ensures the VM requests a new DHCP address. It is easy enough to do subgroups of VMs as long as the VM naming scheme allows for it. For example, if all Windows VMs started with a W then W* on the 3rd line would focus the script on the Windows machines. 

$newVLAN = "vlan100"
connect-viserver vCenter.wwtpoc.local | -user administrator@vsphere.local
$vm = get-vm -name *  | Where-object {$_.powerstate -eq "poweredon"} 
Get-VM -Name $vm | Get-NetworkAdapter | Set-NetworkAdapter -Connected:$false -Confirm:$false
Get-vm $vm | Get-NetworkAdapter | Set-NetworkAdapter -NetworkName $newVLAN -Confirm:$false
Get-VM -Name $vm | Get-NetworkAdapter | Set-NetworkAdapter -StartConnected:$true -Confirm:$false
Restart-VMGuest -VM $vm

Example:

This script clones VMs based on all the variables in Section 1 in the script. It powers them on and sets the NIC to connected. There is even a three-second delay built in to help with turning on too many VMs too fast. 

# Section 1
#
$TargetCluster = Get-Cluster -Name "Simcity"   
$SourceVMTemplate = Get-Template -Name deb10slTemplate   
$SourceCustomSpec = Get-OSCustomizationSpec -Name "LinuxPolicy"  
$DatastoreName = "behemoth02"                                     
$LocationName = "test"                                           
$QuantityOfVMs = "251"                                           
$vmName = "test"                                               
#                                          
$CNT = 1                                                         
#End of Section 1                                                #
# _______________________________________________________________________________________________________________________________________________________________________________
#
# Section 2
#
Do 
{
  $VM = $vmName + $CNT.ToString()  
  New-VM -Name $vm -Template $SourceVMTemplate -ResourcePool $TargetCluster -OSCustomizationSpec $SourceCustomSpec -Datastore $DatastoreName -Location $LocationName
  Start-VM -VM $vm
 Start-Sleep -Seconds 3
 Get-VM -Name $vm | Get-NetworkAdapter -Name "Network adapter 1" | Set-NetworkAdapter -Connected:$true -Confirm:$false 
     
  $CNT = $CNT + 1
  
} While ($CNT -lt $QuantityOfVMs)
#
# end of the Section 2

 

Here is an example of the script being executed. The job was set to build 250 VMs and was on 38 at the time of the screenshot. 

How much time did it save?

The amount of time saved is significant. It is with great pleasure that this author is unable to state the amount of time it takes to manually change a VLAN on a thousand VMs, or how much time it will take to manually clone hundreds of VMs. What is safe to say is what could likely take days to complete at this scale will takes minutes using PowerCLI. 

PowerShell for Windows 

The Problem

WWT clients often need to simulate production environments in the lab. They may need hundreds or thousands of shared folders loaded with dummy data used as mapped drives or redirected system folders. The customer environment may take decades to get to where it is but we only have a few hours to simulate. Here is how that is done.

The Solution

To simulate client data we first need to create folders to store it. Here is a screenshot of a script used to create 600 unique folders 

After the folders are created we need to populate the folders with random dummy data. Here's a screenshot of a script used to populate the folders with a bunch of dummy random data.

How much time did it save?

The folder creation process could take someone hours to complete by hand and then the chance of errors is high. The folder creation script took less than a minute to complete and with 100% accuracy. 

The Dummy Data population script did take several hours to complete. If someone had to create this type of data by hand then the process could take years. This type of time investment is often impossible for administrators which could tempt the risky shortcut of using production data. By using this script we remove the legal and data integrity risks.

Conclusion

As with our first ATC Insight around automation, this volume two shows how automation can save real time in your daily tasks. The trick with automation is to make sure a clearly defined repeatable task is identified, and the dedication of an engineer or architect to drive that automation to a finished product. The amount of effort it takes to automate these tasks is only overshadowed by the time that it saves in the end.

If you would like more information about anything we covered, you can contact:

Test Tools

SPEC CPU 2017 - Is a CPU benchmark utility used by the industry to provide several sets of scores to compare CPU performance. 

Ansible - Ansible's simple automation framework means that previously isolated network administrators can finally speak the same language of automation as the rest of the IT organization, extending the capabilities of Ansible to include native support for both legacy and open network infrastructure devices. Network devices and systems can now be included in an organization's overall automation strategy for a holistic approach to application workload management.

Powershell - PowerShell is a task automation and configuration management framework from Microsoft, consisting of a command-line shell and associated scripting language.

Technologies