Dell EMC, DevOps, And The World Of Infrastructure Automation

Disclaimer: I recently attended Storage Field Day 19.  My flights, accommodation and other expenses were paid for by Tech Field Day. There is no requirement for me to blog about any of the content presented and I am not compensated in any way for my time at the event.  Some materials presented were discussed under NDA and don’t form part of my blog posts, but could influence future discussions.

Dell EMC recently presented at Storage Field Day 19. You can see videos of the presentation here, and download my rough notes from here.


Silos? We Don’t Need No Silos

The data centre is changing, as is the way we manage it. There’s been an observable evolution of the applications we run in the DC and a need for better tools. The traditional approach to managing infrastructure, with siloed teams of storage, network, and compute administrators, is also becoming less common. One of the key parts of this story is the growing need for automation. As operational organisations in charge of infrastructure and applications, we want to:

  • Manage large scale operations across the hybrid cloud;
  • Enable DevOps and CI/CD models with infrastructure as code (operational discipline); and
  • Deliver self service experience.

Automation has certainly gotten easier, and as an industry we’re moving from brute force scripting to assembling pre-built modules.


Enablers for Dell EMC Storage (for Programmers)


All of our automation Power Tools use REST

  • Arrays have a REST API
  • REST APIs are versioned APIs
  • Organised by resource for simple navigation


  • HTTPS, TLS 1.2 or higher
  • Username / password or token based
  • Granular RBAC

With REST, development is accelerated


Ansible for Storage?

Ansible is a pretty cool automation engine that’s already in use in a lot of organisations.

Minimal Setup

  • Install from yum or apt-get on a Linux server / VM
  • No agents anywhere

Low bar of entry to automation

  • Near zero programming
  • Simple syntax


Dell EMC and vRO for storage

VMware’s vRealize Orchestrator has been around for some time. It has a terrible name, but does deliver on its promise of simple automation for VMware environments.

  • Plugins allow full automation, from storage to VM
  • Easily integrated with other automation tools

The cool thing about the plugin is that you can replace homegrown scripts with a pre-written set of plugins fully supported by Dell EMC.

You can also use vRO to implement automated policy based workflows:

  • Automatic extension of datastores;
  • Configure storage the same way every time; and
  • Tracking of operations in a single place.

vRO plugs in to vRealize Automation as well, giving you self service catalogue capabilities along with support for quotas and roles.

What does the vRO plugin support?

Supported Arrays

  • PowerMax / VMAX All-Flash (Enterprise)
  • Unity (Midrange)
  • XtremIO

Storage Provisioning Operations

  • Adds
  • Moves
  • Changes

Array Level Data Protection Services

  • Snapshots
  • Remote replication


Thoughts and Further Reading

DevOps means a lot of things to a lot of people. Which is a bit weird, because some smart folks have written a handbook that lays it all out for us to understand. But the point is that automation is a big part of what makes DevOps work at a functional level. The key to a successful automation plan, though, is that you need to understand what you want to automate, and why you want to automate it. There’s no point automating every process in your organisation if you don’t understand why you do that process in the first place.

Does the presence of a vRO plugin mean that Dell EMC will make it super easy for you to automate daily operations in your storage environment? Potentially. As long as you understand the need for those operations and they’re serving a function in your organisation. I’m waffling, I know, but the point I’m attempting to make is that having a tool bag / shed / whatever is great, and automating daily processes is great, but the most successful operations environments are mature enough to understand not just the how but the why. Taking what you do every day and automating it can be a terrifically time-consuming activity. The important thing to understand is why you do that activity in the first place.

I’m really pleased that Dell EMC has made this level of functionality available to end users of its storage platforms. Storage administration and operations can still be a complicated endeavour, regardless of whether you’re a storage administrator comfortably ensconced in an operational silo, or one of those cool site reliability engineers wearing jeans to work every day and looking after thousands of cloud-native apps. I don’t think it’s the final version of what these tools look like, or what Dell EMC want to deliver in terms of functionality, but it’s definitely a step in the right direction.

Dell EMC Announces VMAX Enhancements

Disclaimer: I recently attended Dell EMC World 2017.  My flights, accommodation and conference pass were paid for by Dell EMC via the Dell EMC Elect program. There is no requirement for me to blog about any of the content presented and I am not compensated in any way for my time at the event.  Some materials presented were discussed under NDA and don’t form part of my blog posts, but could influence future discussions.

Dell EMC today announced some enhancmenets to its VMAX platform, along with a new all-flash model. I thought I’d run through the highlights.



Dell EMC are saying that the 950F offers a “68% increase over the VMAX 850F”.  They’re also saying that they’re seeing “sustained low latency across most workloads”.



The primary reason behind this improvement is the V-Brick engines being refreshed with the latest Intel Broadwell 18-core CPUs.  Each V-Brick has 4-18 core CPUs, bringing the total scale of a 950F up to 576 CPU cores. This is a whole lot of cores to work with and provides some tangible benefits, including reduced response time (compared to the VMAX 850F). A side benefit of this is that you can now get the same performance and capacity as the 850F in a 25% smaller footprint.



The cache on the 950F is based on newer high-speed DDR4 memory, the same as the 250F.  As with the 250F, different V-bricks can have difference cache sizes (1TB or 2TB). You can also jam up to 4PB of effective capacity in these things by leveraging the latest high-capacity 15.36TB  SSDs.  The 950F uses 16 links of 6Gb SAS for connectivity to the drives which provides the same bandwidth per engine as all other VMAX All Flash systems.

V-Brick scaling for open systems is consistent with the 450F and 950F with V-Bricks starting with 53TB of flash capacity and scaling out storage via 13TB Flash Capacity packs.  Host connectivity ports on a fully loaded system is 192 for open and 256 for FICON if running all mainframe.



D@RE External Key Manager

If you’re into D@RE, you might just be excited to hear this news.

  • Allows customers to use a standardized key management infrastructure for D@RE across their entire environment.
  • Support for external key managers using KMIP (Key Management Interoperability Protocol).  KMIP defines message formats for the manipulation of cryptographic keys on a key management server.
  • Allows customers to integrate VMAX with existing key management infrastructure.
  • Leverage external key manager platforms such as Gemalto (SafeNet) KeySecure, IBM Secure Key Lifecycle Manager and other KMIP compatible servers (in the future).   The client runs securely on the VMAX Management Module Control Station (MMCS) inside the VMAX engine.

This simplifies key management (i.e. key generation, escrow, recovery) for VMAX and other KMIP compatible encryption solution like Unity. It also:

  • Simplifies security compliance across the DC;
  • Provides a centralised audit log and FIPS 140-2 Level 3 compliance with Hardware Security Module (HSM) integration; and
  • Allows multiple key server appliances to be clustered (even in geographically dispersed DCs) providing even higher levels of availability.

This gives the security keys to the array back to the teams who need them.

Customers who’ve been using the embedded key manager on VMAX 3 or VMAX All Flash can non-disruptively migrate those keys to the external key manager. Dell EMC tell me this is both “painless and secure”.


Secure Snaps with TimeFinder SnapVX

Secure Snaps are a cool feature that provide a secure option to protect against accidental deletion or malicious attacks on data.


ProtectPoint for VMAX

ProtectPoint support now extends to Microsoft SQL Server and Microsoft Exchange. You can now backup Microsoft SQL and Exchange directly to Data Domain.

Also new is the Instant Recovery feature for File Systems. Once a file system restore is initiated the data is immediately accessible to the host. Any application recovery workflow that uses file systems can benefit from this.



In what I think is great news, RecoverPoint is now available for VMAX3 and VMAX AF platforms. With this you get:

  • Heterogeneous replication, with support for XtremIO, UNITY, VNX, VMAX, VMAX2, and third-party arrays via VPLEX;
  • Granular recovery from particular points in time (meaning RPOs as low as a minute).

RecoverPoint uses VMAX TimeFinder SnapVX local snapshot technology. The SnapVX-based replication relies on the delta between consecutive snapshots. Note that the data differential is further compressed and deduped to minimize the WAN bandwidth consumption.


  • Is supported on both VMAX3 (100K/200K/400K) and VMAX All Flash platforms: VMAX 250F, 450F, 850F and 950F;
  • Supports flexible fan-in and fan-out configurations; and
  • Requires Gen 5 or Gen 6 hardware and RecoverPoint 5.1.



VMAX isn’t the sexiest array on the block any more. There’s nothing wrong with that though. It does what it does really well. And the people buying these arrays are interested in performance and reliability. So why would you buy VMAX now when there’s a slew of alternative solutions available? Some of it is sweat equity. Shops running VMAX invariably have a big investment in processes and tools to support the VMAX environment. They work in places that don’t necessarily move at a rapid pace, or they do things that require a reliable, repeatable result. That doesn’t mean they don’t need useful things like external key management systems though. Financial services places are rife with security folk ready to put the boot into hapless storage operators in the name of compliance. But I digress.

There aren’t a million new features in this release, but it’s nice to see some of the features finally make it to VMAX. I’m hopeful that Dell EMC continue to invest in the platform, and continue to integrate useful protection tools such as ProtectPoint and Secure Snaps across the portfolio. The VMAX 950F is orderable this month and will be generally available in June. You can read more about it in a blog post from Dell EMC here.

EMC – VSI for VMware vSphere 6.5 Linked Mode Issue – Redux

I wrote in a previous post about having some problems with EMC’s VSI for VMware vSphere 6.5 when running in vCenter 5.5 in Linked Mode. I spoke about deploying the appliance in just one site as a workaround. Turns out that wasn’t much of a workaround. Because workaround implies that I was able to get some functionality out of the situation. While the appliance deployed okay, I couldn’t get it to recognise the deployed volumes as EMC volumes.


A colleague of mine had the same problem as me and a little more patience and logged a call with EMC support. Their response was “[c]urrent VSI version does not support for Linked mode, good news is recently we have several customers requesting that enhancement and Dev team are in the process of evaluating impact to their future delivery schedule. So, the linked mode may will be supported in the future. Thanks.”



While this strikes me as non-optimal, I am hopeful, but not optimistic, that it will be fixed in a later version. My concern is that Linked Mode isn’t the problem at all, and it’s something else stupid that I’m doing. But I’m short of places I can test this at the moment. If I come across a site where we’re not using Linked Mode, I’ll be sure to fire up the appliance and run it through its paces, but for now it’s back in the box.

EMC – VSI for VMware vSphere 6.5 Linked Mode Issue

As part of a recent deployment I’ve been implementing EMC VSI for VMware vSphere Web Client v6.5 in a vSphere 5.5 environment. If you’re not familiar with this product, it “enables administrators to view, manage, and optimize storage for VMware ESX/ESXi servers and hosts and then map that storage to the hosts.” It covers a bunch of EMC products, and can be really useful in understanding where your VMs sit in relation to your EMC storage environment. It also really helps non-storage admins get going quickly in an EMC environment.

To get up and running, you:

  • Download the appliance from EMC;
  • Deploy the appliance into your environment;
  • Register the plug-in with vCenter by going to https://ApplianceIP:8443/vsi_usm/admin;
  • Register the Solutions Integration Service in the vCenter Web Client; and
  • Start adding arrays as required.

So this is all pretty straightforward. BTW the default username is admin, and the default password is ChangeMe. You’ll be prompted to change the password the first time you log in to the appliance.


So the problem for me arose when I went to register a second SIS appliance.


By way of background, there are two vCenter 5.5 U2 instances running at two different data centres. I do, however, have them running in Linked Mode. And I think this is the problem. I know that you can only register one instance at a time with one vCenter. While it’s not an issue to deploy a second appliance at the second DC, every time I go to register the service in vCenter, regardless of where I’m logged in, it always points to the first vCenter instance. Which is a bit of a PITA, and not something I’d expected to be a problem. As a workaround, I’ve deployed one instance of the appliance at the primary DC and added both arrays to it to get the client up and running. And yes, I agree, if I have a site down I’m probably not going to be super focused on storage provisioning activities at my secondary DC. But I do enjoy whinging about things when they don’t work the way I expected them in the first instance.


I’d read in previous versions that Linked Mode wasn’t supported, but figured this was no longer an issue as it’s not mentioned in the 6.5 Product Guide. This thread on ECN seems to back up what I suspect. I’d be keen to hear if other people have run into this issue.


EMC announces new VMAX range




Powerful, trusted, agile. That’s how EMC is positioning the refreshed range of VMAX arrays. Note that they used to be powerful, trusted and smart. Agile is the new smart. Or maybe agile isn’t smart? In any case, I’m thinking of it more as bigger, better, more. But I guess we’re getting to the same point. I sat in on a pre-announcement briefing recently and, while opinionalysis isn’t my strong point, I thought I’d cover off on some speeds and feeds and general highlights, and leave the rest to those who are good at that kind of thing. As always, if you want to know further about these announcements, the best place to start would be your local EMC account team.

There are three models: the 100K, 200K and 400K. The 100K supports

  • 1 – 2 engines;
  • 1440 2.5″ drives;
  • 2.4PB of storage; and
  • 64 ports.

The 200K supports

  • 1 – 4 engines;
  • 2880 2.5″ drives;
  • 4.8PB of storage; and
  • 128 ports.

Finally, the 400K supports

  • 1 – 8 engines;
  • 5760 2.5″ drives;
  • 9.6PB of storage; and
  • 256 ports.

*Note that the capacity figures and drive counts are based on code updates that are scheduled for release in 2015.

Hypermax Operating System is a significant enhancement to Enginuity, and is built to run not just data services inside the box, but services coming in from outside the box as well. This includes an embedded data storage hypervisor allowing you to run services that were traditionally run outside the frame, such as management consoles, file gateways, cloud gateways and data mobility services.

Dynamic Virtual Matrix is being introduced to leverage the higher number of cores in the new hardware models. In the largest 400K, there’ll be 384 CPU cores available to use. These can be dynamically allocated to front-end, back-end or data services. Core / CPU isolation is also an available capability.

While they look like an ultra-dense 10K, they’re not. You can have two engines and drives in a single cabinet. All models support all-flash configurations. If money’s no object, you could scale to 4PB of flash in one frame.

Virtual Matrix is now Infiniband, while the backend is now SAS.

EMC claims base support for 6 * 9s of availability, and 7 * 9s availability with VPLEX (that’s 5 seconds per year of downtime).

Snapshotting has been refreshed, with SnapVX supporting up to 1024 copies per source. Doesn’t impact I/O, and doesn’t require target configuration.

Finally, read up on EMC ProtectPoint, it’ll be worth your time.