EMC2 | Smarts Architecture Overview - Dell EMC · PDF fileEMC Smarts Architecture Overview 22...

EMC Smarts Architecture Overview1© 2006 EMC Corporation. All rights reserved.

© 2006 EMC Corporation. All rights reserved.

EMC2 | Smarts Architecture Overview

Marie-Pierre BelangerSr. Product Manager

andSylvia Isler

Staff Software Engineer


EMC Smarts Architecture Overview 2© 2006 EMC Corporation. All rights reserved.

Smarts Application Structure

• Typical Smarts Application Deployment Architecture

SAMSmarts

<<Domain Mgr>>

SmartsAM/PMSmarts

AM/PMSmarts



Smarts Architecture – 100,000 feet

Collection

Analysis

Presentation



Application FunctionalityFrom Start To Finish

Build Knowledge Base

Collect

Correlate data & EventsCodebook Correlation Technology™ to automatically analyze any behavior, in any technology

ICIM-Common Information Model across infrastructure & Business

Smart Discovery, SMART Mediation, Open APIs



Smarts Internal Server Architecture

Managed Domain

Collection Layer

PollersEvent ImportersTopology Importers




TopologyCheckpointDatabase

(.rps)

Managed Domain

Analysis

PollersEvent Importers

PolicyManagerTopology

&Persistence

Manager ICIM Object Repository

Topology Importers

Correlator

MonitorControl

ApplicationLogic




TopologyCheckpointDatabase

(.rps)

Managed Domain

API, Client Applications, and Adapters

Pollers

Subscription Dispatcher

Event Importers

PolicyManagerTopology

&Persistence

Manager ICIM Object Repository

Topology Importers

Correlator

MonitorControl

ApplicationLogic

ICIM Query & Update Handler



Application Logic

Application logic determines the capabilities of the application

There are typically three types of application logic:

A data model deriving from the ICIM core and reference models that describes the domain and analysis logic

Settings that control the analysis logic and link the data model to external instrumentation

Mediation layer that interacts with the external environment to populate or instrument the model.

ApplicationLogic



Smarts Application Logic

• A top-down approach – Focused on authentic problems™ –

problems that matter• Problem behaviors are codified in models

that describe managed object classes– Physical objects – e.g., router, trunk cable,

server– Logical objects – e.g., application, customer,

service, VLAN– Relationships between objects

• A behavior model for each object class describes– Attributes, relationships, problems, symptoms,

and causal propagation of symptoms along relationships

• Base classes are based on CIM

ApplicationLogic



ICIM

• Unified Data Model– Common Context Shared by all Smarts

Applications• Base Classes Based on DMTF CIM Model• Type of Objects/Entities Managed

– Physical – Routers, Switches, Cards, Interfaces, etc

– Logical – IP Networks, VLANs, Business Process/Users, etc

• Properties and Relationships– Composition – ComposedOf, ConsistsOf,

PartOf, etc– Layering – Underlying, Realizes,

LayeredOver, etc– Connectivity – Peer, ConnectedVia, etc– NOT JUST SIMPLE PARENT-CHILD-

CONTAINER!

ApplicationLogic

Slide 11: SMARTS Smarts Information Model

This slide is intended to emphasize the value of a common data model and the depth of the relationships. The important point here is that ICIM is a very rich deep model that provides a base for all Smarts analysis tools.

The Topology Repository leverages the industry-standard Common Information Model (CIM) defined by the Distributed Management Task Force, and is the first commercial implementation of this important standard. Smarts’s implementation is the Smarts Information Model. This in-depth representation of the managed topology organizes the knowledge about IT objects and their authentic problems provides a single common topological context for all Smarts analysis tools as well as events received from 3rd party tools. This means that when an operator receives a notification of a problem they can rapidly view all the current problem information for the device regardless of source. The infrastructure devices and their components are also related to the logical topologies that are overlain on the physical topology. This permits impact analysis to extend to customers, business processes, geographies, etc.


ICIM provides an in-depth representation of the managed objects. If represents physical components such a routers, switches, hosts, interfaces, connections, IPs, etc as well as logical entities such as IP Networks, VLANs, Service Offerings, Service Subscribers, geography, etc. The key to the data model is that it is not simply a Parent-Child-Container model as implemented in most competing products, ICIM provides a full set of attributes and relationships to fully describe the network. Smarts tracks 3 classes of relationships:

Composition, for example: ComposedOf, ConsistsOf, PartOfLayering, for example: Underlying, Realizes, LayeredOverConnectivity, for example: Peer, ConnectedVia

All this information is created by device discovery which we will discuss in more depth on the next slide.



The ICIM Data Model

ServiceSubscriber

Host

HostedApplication

Switch

Router

ServiceOffering

Subscribes

ComposedOf

HostedBy

NeighboringSystems

NeighboringSystems

• Types of Managed Entities– Physical Entities

• Routers, Switches, Hosts• Cards, Ports, Interfaces

– Logical Entities• IP, Logical Ports

– Applications– Service Offerings and Customers

• Properties of these Classes– Attributes

• Name and Operational Status

– Relationships• Composition and Connectivity

– Events• Problem Down• Event Unreachable



ICIM Object Repository

• An in-memory database constructed automatically by applying behavior models to the discovered infrastructure

• Represents physical and logical objects in the managed environment and their relationships

• Maintains both static and real-time information obtained on demand

• Used to compute problem signatures for the Codebook




The ICIM Object Topology

• In-depth representation of – Physical Topology– Logical Topology

ServiceSubscriber::John

Host::WebServer1

Hosted Application::URL1

Service Offering:: SecureWeb

Subscribes

ComposedOf

HostedBy

Hosted Application::FW1

HostedBy

Router::Firewall1

ServedBy

HostedBy

Hosted App::URL1

Host::WebServer2

Domain specific knowledge: • Actual Elements to be

Managed• Actual Relationships between

Elements• Actual State of the Managed

Elements


add slide about ece.



ICIM Repository - Common Data Model

• Types of Managed Entities– Physical Entities

• Routers, Switches, Hosts• Cards, Ports, Interfaces

– Logical Entities• IP, Logical Ports

– Applications– Service Offerings and Customers

• Properties of these Classes– Attributes

• Name and Operational Status

– Relationships• Composition and Connectivity

ServiceSubscriber

Host

Hosted Application

Switch

Router

ServiceOffering

HostedBy

NeighboringSystems

NeighboringSystems

Subscribes

ComposedOf



Application Logic, cont.

Topology Importers instantiate the data model

Topology Importers know how to query the external environment and update representation in ICIM object repository

Settings plug into the Smarts Policy Manager infrastructure

Settings know how to connect data model to instrumentation sources

Application logic may include application-specific pollers or other adapters to provide model instrumentation

ApplicationLogic



Smarts Architecture

DiscoveryAuto

SmartsManagers

EMS’sSMART

Adapters

ICMPPing/SNMP

TL1 SMARTAdapter

SmartsDomains

EMS’sSMART

Adapters

Discovery Event Collection

Topology Manager

ICIM Object RepositoryMonitor Control

PolicyManager

ApplicationMODEL Correlation Engine

ICIM Query & Update Subscription

IC Console CRM’sScripting,Java, CLI,

C, C++

ODBCDatabase

EmailPage Others



Smarts Distributed Architecture

• Smarts managers may be linked to create a distributed applications

• Topology importer of one manager imports data from another through ICIM Query and Update Handler

• Event Importer of one manager imports events from another through the Subscription Dispatcher

• Supports hierarchical or peer-to-peer configuration

DiscoveryAuto

SmartsManagers

EMS’sICMPPing/SNMP

TL1 SmartsDomains EMS’s


Topology Manager

ICIM Object Repository Monitor Control

PolicyManager



IC Console CRM’s

Scripting,Java, CLI,

C, C++

ODBCDatabase

EmailPage

SmartsManager

DiscoveryAuto

SmartsManagers

EMS’sICMPPing/SNMP

TL1 SmartsDomains EMS’s


Topology Manager

ICIM Object Repository Monitor Control

PolicyManager



IC Console

SmartsManager

Scripting,Java, CLI,

C, C++Smarts

ManagerEmailPage

ODBC

Subscription

Published Events

Topology



Software Development Kit, Dynamic Model and APIs



Dynamic Model

• Dynamic Model is an alternate implementation of the Managed Object Definition Language (MODEL)– Traditional Model produces executable code– Dynamic Model produces something similar to Java bytecodes– Languages and semantics are identical, with some minor

limitations• Traditional Model requires access to all of the source

code in order to make modifications



Dynamic Model

• Dynamic Model enables you to add new classes, and refine classes that are already defined in the data model libraries without needing the original source code..

• Dynamic Model can add attributes, events, and so on to an existing class. These new attributes will be visible in all subclasses, traditional or dynamic. They are saved and restored with the repository just like the ones in the base.



SDK and APIs

• The Remote API is the architectural component that enables developers to integrate the EMC Smarts system with their particular application

• Defined in a language-independent fashion• System-independent “wire protocol” – any two systems can talk• Bound to multiple languages• Full bindings:

– C (least common denominator, runs everywhere)– Java (best documented, most widely used)– C++ (internal only, public support planned)– Perl

• Partial bindings:– dmctl (command line)– ASL (scripting language)– XML



SDK and APIs



Data Representation

• Language bindings differ in data representation• Simple types (integers, string) have natural mappings• Structures built from simple types• API makes heavy use of an “any value” union type. This

has many different realizations:– C uses a union type with an embedded discriminator– Java has a abstract base class and a subclass for each

supported kind of “value”.

• Similar differences in such things as error handling (C error value vs. Java thrown exception) and memory management (by hand in C, automatic in Java)



Nature of the Remote API

• Total of about 140 defined calls, though most are specialized and rarely used.

• Defined in a text file from which most API’s are generated automatically.

• Calls fall into multiple groups, accessing the repository, the server itself, the event subsystem, and the correlation subsystem



For a copy of this presentation, visit the developer conference website:

http://developer.emc.com/developer/devcon2006

EMC2 | Smarts Architecture Overview - Dell EMC · PDF fileEMC Smarts Architecture Overview 22...

Documents

Transcript of EMC2 | Smarts Architecture Overview - Dell EMC · PDF fileEMC Smarts Architecture Overview 22...