Single management for all arrays.. doing it?

[jrich52352]

I currently have two arrays, a prod and a non-prod setup.

I was debating on creating a group with them but obviously there is some concern with mixing anything that is prod and non-prod.

what would you guys do?

even if they are grouped, is it still really obvious with what array you're working on?

thanks

[Nick_Dyer]

Hey Justin,

Good question. What you could do is have a single group but have two disparate pools - one called Prod & one called Non-Prod, and have the arrays assigned into those pools.

When you merge two separate arrays together into a single group you are asked whether you want the systems to be in different pools, or placed into one. The default is different pools - so it would mean less work for you afterwards.

There will be a few blog posts coming out soon which detail pools and merging arrays together on this site - hopefully they may answer some questions. There are some caveats to merging arrays too - it's not a non-disruptive process for one of your arrays.

[jrich52352]

so... that other array requires down time? bummer... well im not doing that!

[Nick_Dyer]

Correct - merging arrays into a single group means one array becomes the "master" with it's management & discovery IPs being pushed onto the other systems. This means volumes need to be momentarily offline during the merge process (takes about 30 seconds) and then rescanned with the new discovery IP info on the hosts.

Not a big piece of work, but requires a maintenance window all the same.

[rfenton4 · Accepted solution]

Justin - if you've not done so already then check out the blog on merging two groups and the steps involved.

In answer to your question - I suspect it may depend on what your trying to achieve;  for instance if your non-production array is also a place where you wish to 'prove' code before deploying then I'd recommend not grouping the two arrays together;  (Note: I've seen some environments where Test/QA often is a very critical workload and not a second class citizen).  For example, if you wanted to familiarise yourself with a new code deployment in an environment that was non-production then having a non-production array is potentially useful (obviously merging these into a group would make that more difficult).  Alternatively if the value is having a single management interface and using the grouping and storage pooling features may in fact be appealing and provide ease of management and flexibility should either environment become resource constrained. 

Unfortunately there is no right or wrong answer.