Early Draft of Management Frameworks Architecture
The Storage Management Initiative Specification (SMI) as well as CIM and WBEM have laid the foundation for interoperable management by providing an information model and interoperable protocols for instrumentation of storage, server and other resources. Greater productivity has been achieved for management software vendors by freeing up engineers formerly tasked with maintaining one-off device adapters. They can now create a single adapter that works with any device of a given type.
When creating a management application to manage resources for the first time, there are a number of hurdles that must be overcome before the desired management functionality can be realized. Functions such as a repository, topology and event handling are done over and over each time someone creates a new management application. For existing management applications this work has already been done, but may depend on legacy models and interfaces that cannot take advantage of the emerging instrumentation standards such as SMI-S. Even for existing management vendors, acquiring new companies can lead to incompatibilities that mean they cannot immediately take advantage of the newly acquired value.
The SNIA has been working on a solution to this problem by standardizing a set of services that form a Management Framework. An implementation that conforms to the standard framework can then be used by storage management software developers to rapidly create value for customers. Also, that software can then run in multiple vendors' frameworks, effectively decoupling the infrastructure from the added management value. The expectation is that this will lead to an ecosystem of best of breed standards-based management software that end users can mix and match to meet their needs.
This week the first (early) draft of a reference architecture for this standard framework was released publicly. The SNIA Management Framework Reference Architecture is the foundation for the eventual specification of the framework services themselves. It details what is expected from the definition of each of the services that make up the framework. Framework Services (management services that are defined as part of the framework) include: Discovery, Collectors, Event (Notification), Data Model, Topology and Policy. Below is a diagram of the framework from the tutorial I gave at the last Storage Networking World.
The Discovery service discovers instrumentation agents and the model they implement and tells other services about those agents. The Collectors collect management information from the agents and represent that information for other services. The Notification service is a conduit for notifications from agents and other services based on topics. The Data Model service is probably the most interesting as it is the one place you can go to find the model instances for what is being managed, including historical information. The Topology service takes the raw information from the agents and distills a model of the topology (storage network topology, for instance) that is then available to other services. The Policy service is a runtime environment (some people like to use the term Policy Engine) for executing policy in the context of the framework. A Policy running there can base its decisions and actions off of the model in the Data Model service. More details can be found in the initial draft of the reference architecture on the SNIA site. The next step will be to start defining the actual service interfaces that are part of the framework based on submissions from member companies. Should be interesting and fun as I am one of the chairs of the group.
Update: original Sun Blog post: 6/19/07
The Discovery service discovers instrumentation agents and the model they implement and tells other services about those agents. The Collectors collect management information from the agents and represent that information for other services. The Notification service is a conduit for notifications from agents and other services based on topics. The Data Model service is probably the most interesting as it is the one place you can go to find the model instances for what is being managed, including historical information. The Topology service takes the raw information from the agents and distills a model of the topology (storage network topology, for instance) that is then available to other services. The Policy service is a runtime environment (some people like to use the term Policy Engine) for executing policy in the context of the framework. A Policy running there can base its decisions and actions off of the model in the Data Model service. More details can be found in the initial draft of the reference architecture on the SNIA site. The next step will be to start defining the actual service interfaces that are part of the framework based on submissions from member companies. Should be interesting and fun as I am one of the chairs of the group.
Update: original Sun Blog post: 6/19/07
