In our previous blog post, we got to the stage of the Mobile EBC shutdown where the Cohesity platform protection jobs were disabled and any active job runs canceled. The next few steps in the shutdown procedure were infrastructure- related. For instance, when we powered on the truck, using the truck’s 4G internet connection, we called out to Microsoft Azure and powered on an instance of our software running there (Cloud Edition) which was used to showcase Office 365 backup and recovery. Instead of using the 4G connection to download the data to the truck, we felt it would be better to isolate all those components to our cloud account and just issue a startup and shutdown command. This saved on 4G data costs, as well.
Also, this was the stage where we started shutting down virtual machine infrastructure. Early in the inception of the truck, we had a Microsoft Hyper-V 2016 clustered environment, however, we didn’t see much use of the cluster and no longer showcased ait unless specifically asked for. We did have some shutdown procedures for it, but it involved using VMware’s PowerCLI and talking to the SCVMM virtual machine to issue shutdowns of the virtual machines in the environment, as well as issuing host shutdowns from a Windows environment. We issued the commands to SCVMM using the PowerCLI cmdlet Invoke-VMScript. This used the VMware Tools installation on the VM to remotely execute a PowerShell script that was on the SCVMM device. Here is an example of what that call looked like:
Invoke-VMScript -ScriptText { powershell c:scriptsshutdown.ps1 } -VM “scvmm01.ebc.cohesity.mobi” -GuestCredential $vmCredential -ScriptType Powershell
In this case, we told this cmdlet to execute another Powershell script on the VM named scvmm01.ebc.cohesity.mobi. We did this because of our usage of PowerShell Core as the initiator. At the time this procedure was created, Hyper-V 2016 cmdlets were only available in Windows PowerShell, not PowerShell Core. So, we relayed a call to the SCVMM device that ran a script, called shutdown.ps1, that performed the necessary SCVMM cmdlet calls to shut down the VMs in the Hyper-V environment and then shut the hosts down using Windows PowerShell cmdlets for remote shutdown of a Windows Server 2016 device. The other parameters were to send a guest credential, stored in the variable vmCredential (as a PSCredential object), and to tell Invoke-VMScript to handle a Powershell script. This made it pretty easy to hand off the job to SCVMM to perform the shutdown tasks and to shut down the hosts as well, once finished.
Also, we issued the command to stop the Cloud Edition virtual machine in our Microsoft Azure subscription (as mentioned earlier). We installed the Azure PowerShell module (available here). After using the cmdlet to connect (Connect-AzAccount), we issued the following cmdlet to connect to our resource group, get our VM, and to stop the running process:
Get-AzResourceGroup -Name truckce0 | Get-AzVM -Name truckce00 | Stop-AzVM -StayProvisioned -Force
So, as stated, we connect to our accounts resource group, in this case truckce0. From there, we pipe that information over to the Get-AzVM cmdlet and specify we want to find the VM named truckce00. Then we pipe that information over to the Stop-AzVM cmdlet, which will then start the process of stopping the running VM process. We added the extra parameters of -StayProvisioned to ensure that the VM was not deleted (default behavior in Azure is to delete the VM when you stop it using the cmdlet), as well as using -Force to make sure this process did not get hung up by any minor error. In this case, we did not want to let the cmdlet finish until we were successful in shutting down the Azure workload.
While this blog didn’t really contain much related specifically to Cohesity, if you are interested in more about our integrations and SDKs, feel free to visit our Developer website for more information.
