Kult
1 Copper

Centralized monitoring of VMAX arrays

Hello,


I think of a way to use some external monitoring to gather information about my arrays and send me relevant notifications. There's a way to use ESI management pack for SCOM, however it requires SMI-S agent to be installed and, ultimately, provides full access to VMAX, which is not good in my case. So I'm curious what solution could you used with such requirements.

Thanks in advance.

Labels (1)
0 Kudos
5 Replies
umichklewis
4 Tellurium

Re: Centralized monitoring of VMAX arrays

For simplicity, you could install ProSphere.  It's capable of doing both the monitoring and notification of multiple arrays, and will do what you're talking about with limiting privileges.  If that's not an option, you'll have to do most of the work you'd do so implement ProSphere, then rely on what's in your SCOM pack.

If each one of your VMAX has a host connected with Solutions Enabler, specifically the Solutions Enabler package with SMI-S, you can enable remote access for SYMCLI.  Specifically, take a look at the netcnfg file on a host that has Solutions Enabler installed.  It should be in <INSTALL PATH>\EMC\SYMAPI\config.  I'm attaching a diagram to illustrate.

SMI-S.jpg

In the netcnfg file on the ESI management host (IP 10.10.1.9 in my picture), you can set an entry for each one of your remote SMI-S hosts.

The netcnfg entry looks like:

# SECURE_SERVER  -  TCPIP  node001  111.222.333.444  2707  SECURE             #
# NONSEC_SERVER  -  TCPIP  node002  -                2707  NONSECURE          #
# ANYSEC_SERVER  -  TCPIP  node003  111.222.333.444  2707  ANY                #

So, if want secure remote access to my three VMAX, I'd create the following entries, using the IPs from my picture:

SECURE_SERVER  -  TCPIP  -  10.5.10.5  2707  SECURE             #
SECURE_SERVER  -  TCPIP  -  10.20.30.5 2707  SECURE             #
SECIRE_SERVER  -  TCPIP  -  10.10.20.5 2707  SECURE             #

You can still use the symauth to create users with limited authorization (i.e. roles), so on each VMAX, I'd make a user with MONITOR role only, then modify the daemon_users file to give that account the necessary rights.  I leave that an exercise for you to figure out.

Let us know if that helps!

Karl

Kult
1 Copper

Re: Centralized monitoring of VMAX arrays

Hey Karl,

Thank you for the answer. I'm going to try to implement this solution. I'll let you know as soon as I have results, however it's not going to be soon.

0 Kudos
chinmayakar
1 Copper

Re: Centralized monitoring of VMAX arrays

Hi Karl,

Thanks for the nice explanation. I have a few questions:

1.Will I be also able to see arrays that are local to the SE client, if i try to monitor Arrays connected to another SE host which acts as a server to this SE host?

2. Are there any SE commands to check if my SE Server is catering to clients and vice-versa apart from checking netcnfg and options file?

0 Kudos
Highlighted

Re: Centralized monitoring of VMAX arrays

Hi Karl,

Thru Solutions Enabler you will be able to perform the following command,

symcfg list, you will see all your arrays attached, and -v flag for detail

regards

0 Kudos
umichklewis
4 Tellurium

Re: Centralized monitoring of VMAX arrays

Hello!

1) Arrays that are local the SE client (i.e., have a GK attached to a local array) will be visible.  In my example above, if the host with IP 10.10.1.9 has an array locally attached, I would be able to "see" it and issue SYMCLI commands against it.

2) Yes.  Take a look at the Solutions Enabler Installation Guide.  It has a section on configuring remote client/server relationships.  If you run " stordaemon action storsrvd -cmd list -sessions " on the SE server, you can see all of the active sessions.  You can also find historic data by looking in the appropriate SYMAPI log files.  Refer to the Installation Guide for more details.

Let us know if that helps!

Karl

0 Kudos