How does an existing and heterogeneous data center start a transition to a private cloud implementation?
In this post I'll present an EMC-specific greenfield private cloud, describe an IT management SW architecture for it, and use it as the end goal of a transition from a heterogeneous data center. The goal here is to shed some architectural insight into the Ionix plans for private cloud.
As part of this exercise I'll touch on Ionix software plumbing (previously discussed here and here). In particular my example will focus on the recently-introduced Data Center Insight (DCI) product, and how it would manage a bladed-UCS system attached to homogeneous EMC storage. This initial use case focuses on monitoring only.
Here's the Ionix version of a software architecture for greenfield private cloud IT monitoring:
At the bottom of the picture, DCI communicates with private cloud data sources using native protocols. UCS presents the blades, switches, and VM mappings, ADM (Application Discovery Manager) discovers the applications in the private cloud, SMARTS does root cause analysis and fault monitoring within the private cloud, and ECC monitors the storage aspects of the private cloud. The EMC legacy product names I'm using in the diagram are now mapped to a new name in the Ionix portfolio (I map the old names to the new at the end of the post).
DCI internals fetch management data real-time to generate an up-to-date private cloud blueprint (shown to the right). This blueprint can drill down to the smallest detail, from the application all the way down to the disk level.
The specifics of the DCI internals aren't covered here (they're worthy of a separate post). However, one of the more important things going on within DCI is the concept of "identity matching". Each data source may natively report the exact same device; the DCI internals sense this and map these instances to a unique class id.
Out of the top of DCI a common, REST-ful, ATOM-based subscription model provides a standard protocol and method to gather the appropriate private cloud management information. In this example Ionix Service Manager is the top-level tool being used by IT personnel. An Infra connector has been written to pull the data from DCI and store it to the ever-important CMDB. The connector only pulls a subset of the real-time blueprint. This avoids "CMDB bloat" yet satisfies the need to represent each CI (Configuration Item) that is part of the private cloud.
This model presents a method for complete monitoring of a greenfield private cloud. High-level IT workflows and monitoring are done through the Ionix Service Manager GUI, lower-level hands-on administrators can pull up the DCI blueprint for more detailed monitoring.
A Real World Transition
Today's data centers do not have the greenfield combination of all of the above products. Some data centers may only be running SMARTS for root cause analysis of their network. Others might be using ECC to monitor their storage gear but aren't using ADM for application discovery. Still others may be using a different CMDB management tool (e.g. BMC's Atrium).
Back to the original question: How does an existing and heterogeneous data center start a transition to a private cloud implementation?
The Ionix answer to this question is DCI. The back-end is designed to connect to legacy data center protocols presented by existing management tools. The "blue-print" interface is designed to display a deep-dive of an existing infrastructure. The top-end presents a standard protocol for CMDB integration. DCI already integrates with the BMC Atrium CMDB; a connector was written for just this purpose.
Deploying DCI into an existing data center provides a converged management point, the transition to private cloud technologies occurs underneath it.
DCI's architecture directly addresses the integration gap of point-to-point integration of multiple data sources. It's not sufficient to view silos of independent vendors; they must be integrated, meshed, and presented (both visually and programatically). And of course, the individual Ionix products still work standalone in the original data center paradigm.
Finally, DCI contains a set of interesting services as part of its internal architecture. Future posts can explore them. I'd also like to write some posts to expand beyond monitoring and into the configuration steps that move services over to new private cloud hardware.
Jeff Abbott does a good job of describing DCI in this YouTube video.
SMARTS = Ionix IT Operations Intelligence
ECC = Ionix Data Center Automation and Compliance
ADM = Ionix Service Discovery and Mapping.