ESA 3.4 Q4 release

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:

Click to enlarge – use browser back button to return to post

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.

actionsClick to enlarge – use browser back button to return to post

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:

recommendation_fileClick to enlarge – use browser back button to return to post

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.

recommendationClick to enlarge – use browser back button to return to post

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.

change_slo_1Click to enlarge – use browser back button to return to post

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.

change_slo_2Click to enlarge – use browser back button to return to post

The final dialog box appears, informing you where to look to see if the task was successful.

change_slo_3Click to enlarge – use browser back button to return to post

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.

change_slo_completeClick to enlarge – use browser back button to return to post

If we go back to the EMC Storage Topologies now, the SLO has changed to Diamond.

slo_newClick to enlarge – use browser back button to return to post

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.

change_slo_errorClick to enlarge – use browser back button to return to post

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.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Blog at

Up ↑

%d bloggers like this: