Our fourth quarter release of ESA has arrived just as the year is coming to a close. The developers continue to grow platforms and enhance the product quarter after quarter. ESA 3.4 has a laundry list of new features including support for a new platform – Isilon along with IPv6 support for the major platforms, and enhancements for VNX/VNXe, XtremIO, and ScaleIO. Starting with vROps 6.1 VMware now requires that management packs (e.g. ESA) are signed – it is part of the certification process. It has no bearing on the installation or the user experience and the only way the user will know (which is why I mention it) is during the installation of the pak file:
As usual I’m only going to cover the VMAX additions in detail so for information on all the other platform enhancements have a look at the Release Notes.
Along with IPv6 support, we have two additional features for the VMAX platform which are both concerning the ability to take “Actions” from within vROps and ESA. They are:
- Expand a device on the VMAX2 only (Solutions Enabler and SMI-S version 8.1 required) – there is no VMAX3 support
- Change the service level objective (SLO) of a storage group for VMAX3
Note that in order to use these actions, the user that is configured in the VMAX Adapter Instance for the array (SMI-S user) must have administrator privilege in ECOM. Remember it is possible to use ESA with just a “monitor” role, so any attempt to use an action without administrator privilege will fail. This provides a layer of security for the storage administrator.
An action is exactly what it sounds like. The user is alerted to a condition, say a device filling up, and has the ability to execute an action to resolve it – in this case expanding the device. You can find the Actions menu in vROps by navigating to Content –> Actions. I have highlighted the two actions added in this release.
In the image you will notice a Recommendations column. If an action has a recommendation, it will be one of two types. The first type is nothing more than a description of what the action does. This is the most common. Here is an example for extending a VNX file system:
The second type is one where it provides recommendations of other things the user can do BEFORE using this action. For instance, for VMAX2 device expansion, the recommendation tells the user he can run a reclaim or UNMAP to alleviate the problem before taking the action.
Now unfortunately I haven’t worked on a VMAX2 box in a while as I do not have one in my lab environment. Therefore I can’t show you the action menu, but I can tell you how the expansion works. The nice thing is if you have ever used device expansion in VSI, then you’re in luck, it works the same way in ESA (mostly). If the device is a non-meta device it will be converted to a striped meta device during expansion. If it is already a meta (striped or concatenated) it will be expanded by the additional size request divided by the max single disk size (240GB). Admittedly, the calculation that VSI and ESA use is not the best one since you can get very different meta member sizes. I do have an enhancement request in so I will work with development to try and get a better algorithm in place. Now where ESA and VSI differ is that unlike VSI, ESA is not going to expand the datastore for you. That part you must do yourself through vCenter. Since VSI has direct access to the vCenter while ESA does not, for ESA to expand a datastore it will take more time to develop.
The other available action is to change the SLO of a storage group on a VMAX3. This might be done in response to KPIs that the customer sets up, standard latency metrics that ESA offers for the storage group, or more commonly because the business decides the current SLO is not appropriate for the application (storage group) any longer. Remember that the purpose of Service Level Objectives is to allow the customer to decide what response times are required for an application (storage group) and set the appropriate one, e.g. Silver+OLTP. The VMAX3 then manages the storage extents of those devices to ensure an average response time within the given range for an SLO. If the storage group breaches the target response times, Unisphere will alert the storage administrator while the VMAX3 will aggressively attempt to bring the group back into compliance. I think it more likely, therefore, that this action will be used when new requirements dictate an application needs more or less performance.
Let’s see how it works. Navigate to Environment –> EMC Storage Topologies then highlight and expand the desired storage group. Once expanded you can see the current SLO. Now on the right-hand side, the Action menu is available and the only task “Change SLO” is there.
In this example I need better response times for my application so I am going to change from Platinum to Diamond. The dialog box allows both the SLO and workload to change (if desired). Once chosen, select Begin Action.
The final dialog box appears, informing you where to look to see if the task was successful.
If you select the Recent Tasks link, it will bring you to the location in vROps where you will see (in this case) that the task completed successfully.
If we go back to the EMC Storage Topologies now, the SLO has changed to Diamond.
Note that if you do receive an error message for the task, I’m afraid it may or may not be informative. While we make every attempt to give a logical error, some of them are not. In such cases you will see the following error: “An exception occurred: The selected SLO is not currently supported on this array for this storage group.” It doesn’t mean anything specific so you’ll have to investigate the ESA and ECOM logs to discover the real reason behind the error. It may involve opening an SR with support since the ECOM logs in particular can be very code-centric and are difficult for regular users to interpret.
So that’s it for this release and VMAX. You can find the product documentation and download here.
As I don’t anticipate another blog this year, Happy New Year to all.