Hey all,
In the Cloud Insights world, we now have twp approaches for discovering Dell / EMC Symmetrix arrays - why, and which is right for you?
Historically, we have had a Symcli + SMI-S approach:
+s = We support many generations of hardware. We have access to rich, deep configuration information. We have individual, per volume statistics
-s = We only have performance information at a 15 minute granularity, per EMC's SMI-S limitations. Managing Solutions Enabler version matching rules can be tedious.
In prior years, we would occasionally look at Unisphere:
+s = No CLI version matching pain. Unisphere present via embedded instances on newer arrays. Performance data at a 5 minute granularity
-s = Thin inventory API compared to the richness of the CLI. No per volume statistics whatsoever
But we are now at the point where 2 very important things happened:
SMI-S was announced as deprecated, and is gone in Solutions Enabler 10.0+
Unisphere 10.0+ has added per volume statistics.
We are now at the point where we have taken the "Preview" label off our Unisphere collector, and we view it as production ready for these scenarios:
Vmax 3 All Flash
PowerMax 2000 + 8000
PowerMax 2500 + 8500
We support these platforms with this collector type via Unisphere 9.2+. BUT, only with Unisphere 10.0+ will you additionally get per volume statistics
This may mean your organization will want to deploy Unisphere 10.0+ instances to facilitate harvesting of volume statistics if your array's embedded instances of Unisphere are 9.2, and cannot be upgraded to 10.0+.
The CI collector will discover ALL the "local" arrays on a Unisphere instance, meaning if any of the arrays on it have a SRDF replication relationship to a "remote" array, the CI collector will implicitly ignore that remote array. To discover the remote array, simply deploy an additional Unisphere collector pointed at the appropriate Unisphere instance that sees that array as local.
Questions you may have:
What functionality will I lose by migrating?
Nearly none - certainly from a performance standpoint, you are going to move to 5 versus 15 minute statistical granularity, which is a nice win. Any missing inventory/configuration aspects are likely trivial in comparison to the ease of use benefits and improved performance granularity.
How should I actually migrate?
Both the CLI+SMI/S and Unisphere collectors both support include and exclude capability.
Imagine collector 1 is a CLI+SMI-S instance discovering arrays A,B,C. A is a legacy Vmax 200 that is going away in 6 months, and we want to leave as is for now, until the decommission.
Arrays B and C are more current, and monitored by a Unisphere 10 instance.
Steps:
Leave collector 1 alone for the moment.
Deploy collector 2, a Unisphere collector.
When 2 has discovered both array B and C, we have 2 active collectors discovering the same 2 arrays B and C. This is NOT a long term state you want to be in.
Edit collector 1:
Toggle the "Include" option, and fill the list with the "Sym-$Aserialnumber" for array A OR
Toggle the "Exclude" option, and fill the list with the "Sym-$Bserialnumber, Sym-$Cserialnumber" for arrays B and C OR
Save collector 1, force a poll.
What should happen with EITHER of these new include/exclude approaches is that you are telling CI that collector 1 is either to:
Only to discover A
Discovery any array that is NOT B NOR C
When collector 1 finishes , CI will realize that collector 2 is now the source of truth for arrays B and C.
This approach should provide a seamless migration
Matt
