In our last article we demonstrated how to use the new vSphere PowerCLI 5.8 SPBM cmdlets to create vSphere Storage Policies. In this article we will demonstrate how to quickly associate a vSphere Storage Policy with a new or existing VM.
Example Provisioning Scenario
To illustrate how to leverage PowerCLI to associate vSphere Storage Policies with VMs we will continue with the provisioning example from our previous article.
Single virtual disk
Virtual SAN datastore
Follow these links for more information on creating vSphere Storage Policies for Virtual SAN:
Previously in order to create, manage, and associate vSphere Storage Policies with VMs using PowerCLI, one would need to leverage an intermediary method as well (e.g. Esxcli, RVC, REST API, etc). Often this could require the use of third party applications to bridge the gap in interfacing with the vSphere Storage Policy Based Management service. This resulted in added complexities and additional processing time for workflows that were automated with PowerCLI.
With the new PowerCLI 5.8 cmdlets for vSphere Storage Policy Based Management we are able to greatly reduce the complexity of vSphere Storage Policies with PowerCLI now by using PowerCLI exclusively. In the example below, we will demonstrate how to enhance the VM provisioning process by associating a vSphere Storage Policy with a virtual machine.
One of the relatively newer use cases for SRM is planned migration. With this use case, customers can migrate their business critical workloads to the recovery or cloud provider sites in a planned manner. This could be in planning for an upcoming threat such as a hurricane or other disaster or an actual datacenter migration to a different location or cloud provider. Continue reading →
A protection group is a group of virtual machines that fail over together to the recovery site. Protection groups contain virtual machines whose data has been replicated by array-based replication or by VR. Typically contains virtual machines that are related in some way such as:
A three-tier application (application server, database server, Web server)
Virtual machines whose virtual machine disk files are part of the same datastore group.
The purpose of the exercise was to demonstrate use cases for disaster recovery of real business critical applications (BCA) leveraging VMware solutions such as VMWare Site Recovery Manager (SRM). Techniques to protect against disaster for common business critical applications such as Microsoft Exchange, Microsoft SQL Server, SAP and Oracle Databases are discussed.
Greetings and welcome to our next article in the PowerCLI 5.8 series for the new vSphere Policy Based Management cmdlets. In today’s article we are going to dive right in and start building our own vSphere storage policies leveraging the new SPBM cmdlets within PowerCLI.
Before we begin though, if you have not yet had an opportunity to familiarize yourself with vSphere Storage Policy Based Management, here are a few key blog articles that can help you build a good foundation.
Big Data Extensions enables the deployment of Hadoop and HBase clusters in virtual machines on the VMware vSphere platform. This article gives you a brief introduction to the new features in BDE version 2.1. BDE ships as a virtual appliance (an OVA file) and it is a free download for users of vSphere Enterprise or Enterprise Plus.
BDE users are interested in using their favorite management tools from their Hadoop distro vendors, along with BDE and vCenter, to manage their newly created virtualized Hadoop clusters. The 2.1 release of BDE implements this feature in an elegant way!
Now you can use BDE and Cloudera Manager or Ambari together to install and manage your Hadoop clusters without leaving your Web Client BDE seat. You can also use the earlier styles of provisioning a Hadoop cluster as shown under the “BDE Only” and “BDE 2.0″ headings below. The first method on the left allows BDE to use a repository to install the Hadoop vendor’s software on to the virtual machines. BDE does the whole job of provisioning everything in this case – hence referred to as “BDE Only”.
Using BDE 2.0 (shown in the center column) you can create a basic cluster, i.e. one with no Hadoop software in it. Then you can use the Hadoop vendors’ installation and configuration tool to install the Hadoop software on those virtual machines. With BDE 2.1 you don’t have to go between the different tools; the full Hadoop installation can be done inside BDE’s user interface, but using the vendor’s APIs under the covers to do that. The difference between the BDE 2.0 and 2.1 methods is that in 2.1 the management tool from the Hadoop vendor is called by BDE directly.
This new blog series will focus on Virtual SAN day-to-day operations related tasks and their recommended operating procedures. I will start the series by covering one of the key and most important aspects of Virtual SAN, which is the management of disk groups.
Managing Disk Groups
Disk groups are logical management constructs designed to aggregate and manage locally attached flash devices and magnetic disks on ESXi hosts. When disk groups are created the flash devices are utilized to create a performance (caching) layer, while magnetic disks are utilized to create the persistent storage layer and provide storage capacity.
Creating Disk Groups
Disk groups are individually created on every host that is a member of a Virtual SAN enabled cluster. Creating a disk group requires the existence of a single flash device and a single magnetic disk at the very least. A disk group supports a maximum of one flash device, and up to seven magnetic disks.
Disk groups can be created through the vSphere Web Client as well as the command line interface utilities such as esxcli after the Virtual SAN feature has been enabled in a cluster. The vSphere Web Client presents the simplest method for small environments, while command line utilities such as esxcli can provide automation capabilities for large environments.
Welcome to part 2 of the vSphere Storage Policy Based Management Overview. In our previous article, we looked at challenges with traditional storage provisioning models, the advantages of the Software-Defined Storage model, as well as an introduction and background to VMware vSphere Storage Policy Based Management. If you have not yet had opportunity to read it, it might be beneficial to glance through before continuing on.
In today’s article, we will be carrying on with the vSphere Storage Policy Based Management (SPBM) theme as we look to understand the components of the vSphere Storage Policy. Afterwards we will display a few policy examples for single VM provisioning and options for a collection of VMs as well.
I recently published an article describing the procedure to configure and enable the VMware Virtual SAN Observer tool to work without the requirement of Internet access. This operating mode is known as the offline-mode.
The Virtual SAN Observer tool provides three different options for monitoring statistics. The offline monitoring option is probably the most utilized option out of the three as it presents the most flexibility for archiving and data transportability. A brief description of the Virtual SAN Observer monitoring modes is listed below.
Virtual SAN Observer Monitoring Modes
Live Monitoring – This mode displays the performance statistics in real time as they are being generated by the system.
Offline Monitoring – This mode provides the ability to create a tar.gz package with html bundle which can be utilized for archiving purposes or future inspection.
Full raw status bundle – This mode provides the ability to collect all the stats into a large JSON file for deeper analysis.
With this release, we now have the ability to interface with the vSphere Storage Policy Manager through the addition of the new VMware.VimAutomation.Storage snap-in. This snap-in provides PowerCLI cmdlets that let you manage vSphere policy-based storage from the PowerCLI command line or by automating through PowerCLI scripting.
In this blog series we will look to provide indepth coverage along with real-world scripting examples for each of the cmdlets. All scripts provided will be examples only and unsupported however I do validate each script with great scrutiny in multiple testing environments so you may not require much adaptation, if any, if you choose to leverage them in your own environments. As always, please ensure all coding is validated in a non-production environment prior to production deployment.