EF & E-Series, SANtricity, and Related Plug-ins

Simplified version of E-Series Performance Analyzer v3.0.0

elementx
1,866 Views

As many of you are aware there's a nice NetApp repo with an E-Series performance monitor, InfluxDB and Grafana put together as one monolithic docker-compose setup which runs all these things on one VM:

https://github.com/netApp/eseries-perf-analyzer

I created a friendly fork of it with Collector as a stand-alone container:

https://github.com/scaleoutsean/eseries-perf-analyzer

 

What this does is lets you - an E-Series admin or Ops guy - run and manage one Collector per one array, and not touch shared Grafana or InfluxDB containers. You still need InfluxDB (the older v1) to send data to, but it can be set up and managed by one team/person for the entire organization. So for example three teams can each have their own Collector and manage SANtricity password rotation without touching a shared instance or being able to access other people's E-Series.

 

Upstream EPA v3..0.0 (current version) doesn't make it very easy to run multiple collectors.  It is possible and done by default, in fact, but it makes use of SANtricity Web Service Proxy (WSP), which means one container that can manage all E-Series arrays, which many admins don't like: the moment you let one admin access WSP, they can accidentally access all arrays, break InfluxDB, etc.

 

My fork removes Collector's dependency on WSP - all an admin has to do is run a Python script (inside or outside of a single container) - and specify a monitor (not admin) account of their E-Series array.

 

If you already use EPA v3.0.0, it is possible to run additional Collectors outside and send data to existing EPA v3.0.0 without adding Grafana and InfluxDB instances. The fork retains upstream's Docker Compose with Grafana/InfluxDB and adds another Compose for a stand-alone Collector (or Collectors).

 

The Collector container(s) can also be deployed to run on Kubernetes or run containerless.

 

It needs less than 32 MB of RAM so it takes less than 1GB of memory to collect data from 32 arrays. In that way running one per each E-Series array is very affordable, given the security and operational benefits. Says I.

 

EPA users who wish to contribute or have an opinion or question are welcome to leave their comment here.

2 REPLIES 2

elementx
1,578 Views

Small update.

 

In v3.1.0 WSP was removed and now users can have one collector per each array, independent of each other which means Grafana/InfluxDB can be operated and maintained by one person, while collectors can be configured and executed by different teams without disclosing storage credentials to others.

Collectors now collect SSD wear level info from E-Series with flash media (Grafana panel to show data - visible in the screenshot - can be easily added by users who need that info).

 

epa-ssd-wear-monitor.png

elementx
1,405 Views

Another small update:

- EPA v3.2.0 completes the main goal of this fork, which is to completely separate E-Series-related code (namely collector and dbmanager containers) from the rest (InfluxDB, Grafana) and make it possible to run EPA in orchestrated environments such as Kubernetes and Hashicorp Nomad

- This version adds support for recent Kubernetes versions (tested with 1.25), while Docker (and Docker Compose) remain usable

- There are no new features related to dashboards or monitoring

https://github.com/scaleoutsean/eseries-perf-analyzer/releases/tag/v3.2.0

 

Public