Category Archives: ViPR

ViPR

Dell EMC, DevOps, And The World Of Infrastructure Automation

Posted on by

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)

REST

All of our automation Power Tools use REST

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

Secure

  • 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.

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

Posted on by

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.”

 

iStock-Unfinished-Business-3

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

Posted on by

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.

VSI1

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 ViPR 2.0

Posted on by

There’s a bunch of stuff being announced at EMC World this week. But there’re also plenty of people who are actually at the event and getting paid to tell you about that stuff. I’m no tech reporter, but I thought the “software-defined-curious” amongst you might be interested in a little coverage of EMC‘s ViPR 2.0 announcement.

Here’re the rough highlights, including some pictures:

1. ViPR 2.0 now supports third-party commodity hardware support (HP SL4540 certified at launch, with more to follow)

HP_SL4540

2. It also has improved native array support, including:

ViPR_array_support

There’s also additional array support via OpenStack.

Ÿ3. ViPR Block delivered by ScaleIO:

  • ŸManaged by the ViPR controller in a similar fashion to other ViPR data services.
  • ŸCreate virtual pools of storage with varying performance tiers.
  • ŸCreates a server-based SAN from local storage to deliver performance and capacity on demand
  • Scales to 1000s of nodes

Mark has a nice write-up here, while Chad has his own special take on why this is a big deal.