OCI and the new EMC VMAX-3 eManagement

[Don_Childers]

Now that EMC has started embedding Solutions Enabler (SE) and the SMI-S Provider directly on to the new VMAX-3 arrays (eManagement), I'm wondering what NetApp's plans are to utilize this feature. Currently, for VMAX arrays, OCI requires that a SE with SMI-S server is available to install a RAU on. The data source has to point to that RAU on that server to communicate. Then any VMAXes are discovered.

On our new VMAX-3 arrays, we are utilizing the embedded SE and SMI-S software (and using the embedded Unisphere for array management) so that we don't have to build even more standalone SE servers. As we slowly migrate off of our old VMAX arrays, we eventually won't have standalone SE servers to install a RAU on.

We do have one SE Windows server with SE v.8 (but without SMI-S) pointing to a VMAX-3 as a test. I did install the RAU on that SE server and communication works fine. I also did test pointing SMI-S collection directly to the embedded SMI-S on the VMAX. The default ports are different but it does work. I just can't test pointing to the embedded SE on the VMAX since there is no option for that. I have to use a RAU.

So, I'm just wondering if NetApp is working on OCI being able to utilize both the embedded SE and SMI-S on the new arrays *without* having to use a RAU. Basically, creating a VMAX data source that doesn't need the RAU installed on a SE server.

Hopefully this all makes sense. 🙂

--Don

[ostiguy]

Hey Don,

OCI simply needs to be able to talk to the Symm in a timely fashion.

In some customer environments, RAUs have to be deployed to reduce the amount of latency between a Solutions Enabler client and Solutions Enabler server.

Here is an example of what I expect could happen:

Customer has an OCI server in NYC

Customer has a Vmax 3 in LA.

Regardless of whether the customer has the eManagement Solutions Enabler server running on that Vmax3 in LA, or a traditional Solutions Enabler server in LA, you can bet your bottom dollar that OCI in NYC will have trouble inventorying that Vmax3 in LA because fundamentally, Solutions Enabler is very latency sensitive, and CLI commands will take a long, long time to execute across ~3000 miles from NYC to LA

So, installing a RAU into LA allows the Solutions Enabler client <-> server traffic to become LAN latency versus WAN latency, because  the RAU has Solutions Enabler installed to act as a client.

So, fundamentally, from an inventory perspective, there isn't anything all that exciting about running Solutions Enabler on the Symm itself.

Now, things I don't know:

Does the eManagement Solutions Enabler have the storsrvd daemon running by default?

If it does, is it listening on tcp 2707?

If those requirements are met, that is at least 85% of the way there (I qualify this statement because Solutions Enabler has a gazillion nerd knobs and security regimes resulting from various initiatives over the years. No rational observer could look at the security options available within Solutions Enabler and describe the whole as the logical output of a consistent vision. Ahem)

Matt

[Don_Childers]

Thanks Matt. Yeah, both the OCI server and the new arrays are in the same data center so I think we're good on any latency concerns. I'm looking into the embedded SE commands and ports. Zach and I were talking about it also during our DPP meeting yesterday. I'm using the DPP environment for testing all of this stuff out. I'll let you know what I find out.

And thanks Moechnig. I'm going to try setting up the VMAX-3 that doesn't have a standalone SE server using the netcfg file. We are already doing that for all of the other VMAXes in our DPP environment.

--Don

[moechnig]

The practice of installing an RAU on your FC-attached Solutions Enabler server is recommended, but is not required.  Solutions Enabler is architected as client-server software, and the default mode of installation with OCI is to install the Solutions Enabler  client wherever you prefer to run acquisition, then configure it via a netcfg file to talk over the network to your FC-attached Solutions Enabler server.  If you don't have a compelling reason, you don't need to use an RAU.  Solutions Enabler client can be installed right on the OCI server. 

Potentially compelling reasons to use an RAU anyway include: 

• a high latency link between OCI and your SYM; symcli seems to be very sensitive to latency
• firewalls between OCI and your SYM
• needing to run multiple versions of Solutions Enabler to support your various versions of array firmware
• already having a convenient RAU

The SMI-S provider is mostly independent of Solutions Enabler and should work just like you've already discovered.  In fact, if EMC is shipping this stuff pre-configured, that should eliminate a recurring pain point around getting the SMI-S provider to collect node and array latency from Unisphere, which has required manual setup until now. 

The OCI manual provides brief instructions on setting up the SYM data source here:  https://library.netapp.com/ecmdocs/ECMLP2573779/html/frameset.html  The KB article here has some additional details on testing the Solutions Enabler client on your acquisition unit:  https://kb.netapp.com/support/s/article/ka21A0000000ZUE/oncommand-insight-what-are-the-requirements-for-symcli-deployment-setup