A second collection server for OCI

[JBARBALACE]

Hello,

We are trying to rebuild a Solutions Enabler server for data collection from our DR data center.  We've run out of space to build another VM, so our storage team is throwing out some options.  One of the suggestions was to build a second OCI collection server - this doesn't sound feasible as it might prove problematic when it comes to collection and reporting.  Below are the two suggestions, and I am pro-#2:

1. 1) Build a 2^nd Collection server for OCI. This server can run a compatible 32 bit code for Solutions enabler to connect to our existing physical server at the DR site which runs the corresponding level of SE and has all the gatekeepers already masked to it. Currently there is only 1 collection server for OCI and we cannot run a 32 and 64 bit version of SE on the same server. The Production and Lab are running 64 bit versions. The One at our DR site is running 32 bit which is why we would need a 2^nd OCI collection server to support a 32 bit version.
2. 2) Build a new physical server at Boyers and we install SE 64 bit on it and configure the existing OCI collection server to work directly with it. The server can be a windows server and will have to be san attached to both even and odd fabrics at boyers.

Any insight you might be able to provide would be helpful. I'm just doing some homework here and would like some input.

Thank you!

Julia

[ostiguy]

Hey Julia,

Here are some semi-random thoughts:

#1. OCI 6.4.0 and higher are all 64 bit only, so they must be installed on a 64bit Windows. However, it may be that 3rd party 32bit software will work fine on OCI (FYI, my experience is that a lot of HP CommandView EVA versions will not install on 64bit windows).

#2. I don't think that you should need to worry about 32 vs 64bit for Solutions Enabler. SE is cross platform, and I am not aware of any known issues using 64bit vs 32bit in client/server mode.

#3. I don't see the idea of an OCI Remote Acquisition Unit (RAU) in your options - this .msi will install a "SANscreen Acq" on the Windows server of your choosing - it simply needs to be able to *initiate* HTTPS connections to your OCI server. The RAU is a tool to make working around firewalls possible, as well as a way to reduce latency issues by pushing OCI acquisition closer to distributed devices

So, my thinking is:

Do you own Perform?

Do you want to collect Symmetrix performance?

If yes to both, you may want to stand up a new 2vcpu / 8 GB Windows 64bit VM - map gatekeepers to it as RDMs, and install the SMI-S enabled version of Solutions Enabler, and the OCI RAU software. Then, you can create an OCI datasource, living on the RAU where the connection type is "local".

The upside of this topology is it gets you out of Solutions Enabler version matching, as the OCI datasource has direct access to the Symms.

I have a global insurer that is doing a lot of their Symmetrix discovery this way, as they were having trouble managing Solutions Enabler versions, as well as not having the SMI-S enabled version of Solutions Enabler deployed.

Solutions Enabler is somewhat picky with regard to latency - if the ping time from the OCI server to the remote SolEnabler server is >= 15ms, you may see very slow OCI inventory acquisition times. Deploying a RAU into the remote site can eliminate this.

Matt

[JBARBALACE]

Hi Matt,

Thanks for the follow-up!  We have licenses for the full OCI suite, Performance included. 

I was wondering about an RAU, but I've not had to deal with that in the past and wanted to throw out the suggestions from our storage team first, and see if there were any alternate ideas.  The SE server at our DR site has been failing and we're working on rebuilding and trying again.  We did this in our Production environment, that was also having an issue, and we now have a successful acquisition.  We planned on doing the same at the DR site, but we discovered a lack of space to build a build a new VM at our DR site.  There is a new cluster planned to be built, but we need this up and running now, not in a month or more.

One of the issues that I didn't note was that the DR site and our site here are in two different states and there seems to be a need for the SE server to be in proximity to the Symmetrix because of the gatekeepers.  But an RAU should solve that?  Will it be able to poll a Symmetrix in Pennsylvania from a server here in Virginia?

Do you have good documentation on setting up an RAU that I can provide to them?  I know there is some information in the OCI manual, but if there is something more detailed about the set-up, I would be very appreciative for that.

Julia

[ostiguy]

The RAU install is pretty pain free -  "next next next yes ok" -> The only questions you need to answer are what do you want to name the RAU (defaults to the simple RAU hostname), and what is the OCI server name.

SE servers do need to be in proximity to Symms - they communicate via FC.

OCI can either remotely communicate to the SE server, by installing the same or older SE version on the OCI server, or "locally" (in Solutions Enabler terms) by installing a RAU onto the SE server.

With the remote communication mode, latency can be an issue - this will probably not be a problem from PA to VA. I had a banking customer whose NJ servers could not remotely discover Symms in TN - the OCI Solutions Enabler datasource defaults to a 2 hour timeout. Trying to discover 5 TN arrays remotely from NJ took 18ish hours - by moving that datasource to a new RAU deployed in TN, the inventory time was cut to under an hour.

FYI, you can easily move datasources from one RAU to another, or the local AU - on the first page of datasource creation, there is a pulldown box that you probably don't even think to look at in a non-RAU environment. This pulldown defaults to local. It will additionally be populated with the RAU name once the RAU registers properly with the server.

FYI, from an ongoing maintenance perspective, you will need to install OCI data source service packs onto your RAUs when you install them on your OCI server.

The latency issues matter for inventory. OCI's recommended approach for performance collection is SMI-S. If you don't have the SMI-S enabled version of Solutions Enabler installed, that might tilt you towards deploying into onto a new host/VM, and making that host a RAU for OCI.

Matt

[JBARBALACE]

We do have SMI-S installed on all of the SE servers, but it's getting that SE server up and running at the DR site that's been an issue.  It looks like we really do need to rebuild the SE server since it's running an older ESX version and it won't deploy the virtual appliance template that we want to run (the one that is now working in our Production environment).  There are 8 RDMs attached to it (3MB gatekeeper devices).  That ESX version will eventually get an update, but that's over a month away, and the cluster that our server is sitting on now is out of room to build another.

With this in mind, would installing an RAU on the existing SE server (no rebuilding) be worth a shot?  And is any other good documentation on installing an RAU on the SE server?  I found the documentation in the Installation guide and I see the .msi file on the downloads page.  I just want to make sure there isn't anything else I can forward to the storage team to set this up.

[ostiguy]

Is the existing SE server 64bit windows? It would need to be to go the RAU route

I am not sure if we document the RAU install - there is really  just one page where you have to fill in some values

[JBARBALACE]

No, 32-bit.  We were going to make it 64-bit by uploading the virtual appliance template, but since the existing VM is running a too old ESX version, it won't deploy the vapp. 

So, back to my original question - a 2nd collection server or a new physical server?  What we have in Production is working great to date, as well as in our Lab environment.  We've just hit a snag with the DR site.

[ostiguy]

How large is the DR site? My inclination would be to use a RAU instead of creating a second instance of OCI. The RAU can be a VM or a physical server, but it needs to be 64bit windows.

[JBARBALACE]

So what is the suggestion of the two that I gave above?  That we go ahead and build the physical server, with the 64bit SE, and add an RAU?  The VM we have at the DR site never really worked very well, and we want to mimic the SE server set-up that we are successfully using in Production and Lab, both of which are now 64bit.  Since we are out of capacity to simply build another VM to replace the exisitng SE VM, we need another option. 

We are using the SE server to poll one DMX4, approx 90TB.   

Just to cover all bases, that first suggestion provided is not a possibility, correct?  It just sounds as if that will cause an issue with reporting -

1. Build a 2^nd Collection server for OCI. This server can run a compatible 32 bit code for Solutions enabler to connect to our existing physical server at the DR site which runs the corresponding level of SE and has all the gatekeepers already masked to it. Currently there is only 1 collection server for OCI and we cannot run a 32 and 64 bit version of SE on the same server. The Production and Lab are running 64 bit versions. The One at our DR site is running 32 bit which is why we would need a 2^nd OCI collection server to support a 32 bit version.

[JBARBALACE]

Can we use the SE server here, add an RAU, and poll the Symmetrix in Pennsylvania? 

[ostiguy]

The SE server in Virginia has nothing to do with Pennsylvania.

If the OCI server is in VA, deploy a RAU into Pennsylvania.

The RAU can be either a VM or a physical server, but it needs to be 64bit Windows.

Either:

Install Solutions Enabler on the RAU, install the same version or older than the SE server in PA. Configure the netcnfg file on the RAU, and create an OCI Solutions Enabler datasource that lives on the RAU, pointing at your new netcnfg alias that refers to the PA Solutions Enabler server

Or:

Install Solutions enabler on the RAU, provision 6 gatekeeper volumes via FC. Create an OCI Solutions Enabler datasource that lives on the RAU, that performs "local" discovery

[JBARBALACE]

Ok, I mentioned it because there was a suggestion to build a VM here, where there is space, and point it to PA, but that's not going to work.  It seems that, either way, we are going to need a new server.  I believe they can build a physical server, steering away from the need to find capacity on a VM.  Once we have that, we'll install the RAU to hopefully help with acquisition.

As always, thank you for the guidance and putting up with my questions. 

Regards,

Julia