Prosfund17 - 2013 - SRG BY EMC

Welcome to EMC ProSphere Fundamentals.
Copyright 1996, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013 EMC Corporation. All Rights
Reserved. EMC believes the information in this publication is accurate as of its publication date. The information is subject to change
without notice.
THE INFORMATION IN THIS PUBLICATION IS PROVIDED AS IS. EMC CORPORATION MAKES NO REPRESENTATIONS OR WARRANTIES OF
ANY KIND WITH RESPECT TO THE INFORMATION IN THIS PUBLICATION, AND SPECIFICALLY DISCLAIMS IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Use, copying, and distribution of any EMC software described in this publication requires an applicable software license.
EMC2, EMC, Data Domain, RSA, EMC Centera, EMC ControlCenter, EMC LifeLine, EMC OnCourse, EMC Proven, EMC Snap, EMC SourceOne,
EMC Storage Administrator, Acartus, Access Logix, AdvantEdge, AlphaStor, ApplicationXtender, ArchiveXtender, Atmos, Authentica,
Authentic Problems, Automated Resource Manager, AutoStart, AutoSwap, AVALONidm, Avamar, Captiva, Catalog Solution, C-Clip, Celerra,
Celerra Replicator, Centera, CenterStage, CentraStar, ClaimPack, ClaimsEditor, CLARiiON, ClientPak, Codebook Correlation Technology,
Common Information Model, Configuration Intelligence, Configuresoft, Connectrix, CopyCross, CopyPoint, Dantz, DatabaseXtender, Direct
Matrix Architecture, DiskXtender, DiskXtender 2000, Document Sciences, Documentum, elnput, E-Lab, EmailXaminer, EmailXtender,
Enginuity, eRoom, Event Explorer, FarPoint, FirstPass, FLARE, FormWare, Geosynchrony, Global File Virtualization, Graphic Visualization,
Greenplum, HighRoad, HomeBase, InfoMover, Infoscape, Infra, InputAccel, InputAccel Express, Invista, Ionix, ISIS, Max Retriever,
MediaStor, MirrorView, Navisphere, NetWorker, nLayers, OnAlert, OpenScale, PixTools, Powerlink, PowerPath, PowerSnap, QuickScan,
Rainfinity, RepliCare, RepliStor, ResourcePak, Retrospect, RSA, the RSA logo, SafeLine, SAN Advisor, SAN Copy, SAN Manager, Smarts,
SnapImage, SnapSure, SnapView, SRDF, StorageScope, SupportMate, SymmAPI, SymmEnabler, Symmetrix, Symmetrix DMX, Symmetrix
VMAX, TimeFinder, UltraFlex, UltraPoint, UltraScale, Unisphere, VMAX, Vblock, Viewlets, Virtual Matrix, Virtual Matrix Architecture, Virtual
Provisioning, VisualSAN, VisualSRM, Voyence, VPLEX, VSAM-Assist, WebXtender, xPression, xPresso, YottaYotta, the EMC logo, and where
information lives, are registered trademarks or trademarks of EMC Corporation in the United States and other countries.
All other trademarks used herein are the property of their respective owners.
Copyright 2013 EMC Corporation. All rights reserved. Published in the USA.
Revision Date: February 2013

Revision Number: MR-1WN-PROFUN.1.7.2.0
Copyright 2013 EMC Corporation. Do not copy - All Rights Reserved.
EMC ProSphere Fundamentals
This course covers the current business challenges in storage resource management and how
the ProSphere application has been engineered to address those challenges. Building on this
foundation, you should be able to describe how ProSphere has been designed to provide
agentless discovery of SAN devices, how its REST API is used as the interface to stored
configuration data, and the considerations that should be made for deploying the ProSphere
application. At the conclusion of this course, you should also be able to describe ProSphere
topology mapping, ProSpheres application architecture, the software packages used for core
services, and ProSpheres performance data collection capability.
This module provides an overview of Storage Resource Management related challenges

addressed by the underlying architecture and functionality of ProSphere.
This lesson covers the current and future business challenges in storage resource
management. ProSphere is the EMC response to those challenges and this lesson will
introduce its core values and benefits in addressing these challenges.
The International Data Corporation has predicted the amount of information storage capacity
required by businesses will multiply by 44 times between the year 2010 and the year 2020. It
is estimated that more than a third of this data will reside or pass through cloud services. The
always-on accessibility and lower upfront costs of these cloud services encourage customers
to transition from traditional data centers to increasingly virtualized environments. This
drastic change in IT architecture forces businesses to rethink the way they are managing their
SAN. While ControlCenter is still the most widely deployed SRM software in the storage
industry, a new architecture is required to meet the needs of these highly virtualized data
centers.
With ProSphere, EMC adheres to a set of core architectural values to ensure that it meets the
requirements of next-generation data centers. The first core value is to lower the cost of
ownership. ProSphere lowers cost of ownership by moving to a virtual appliance based
deployment model that will simplify the initial installation process, and implementing
agentless discovery, which will eliminate the time and effort currently spent managing host
agents.
Another core value is Best of breed scalability which is achieved through improved data
modeling, and by ensuring that no single bottleneck exists in the design. This improved
architecture will lower the hardware requirements needed to manage large environments,
thereby improving refresh rates. In addition to increased performance and scale, significant
investments have been made to improve end user productivity in large data centers. A search
function will enable customers to quickly find objects in their environment. Once found,
ProSphere will bring up an end-to-end view of the portion of the IT environment associated
with that component, to provide visibility into infrastructure dependencies.
A third core value is Increased flexibility and integration. This will enable faster support for
new technologies by launching device managers in context. Launch-in-context allows EMC to
take advantage of its engineering investments in device management, which results in faster
support for new functionality. Further, employing REST technology allows for faster
integration with new application services.
Many EMC customers want a global, federated view across their data centers to simplify
management and reporting. As the adoption of cloud computing grows, more customers will
have data residing in multiple sites increasing the number of customers requiring a global,
federated view of their entire IT environment.
Prosphere is built to handle the scale of next generation data centers. This means not only
being capable of handling the size of these data centers from a performance and scale
perspective, but also providing a user interface that will improve productivity in tomorrows
larger, more complex data centers. ProSphere is deployed on VMWare ESX/ESXi 4.x or 5.0.
ProSpheres user interface has been designed to leverage the EMC Common User Interface
Toolkit, which delivers a consistent user experience across EMC management applications.
This lesson covers the current and future business challenges in storage resource
management. ProSphere is the EMC response to those challenges and this lesson will
introduce its core values and benefits in addressing these challenges.
ProSphere discovers objects without the installation of agents. SMI-S and SNMP are used to
gather information from SAN switch and storage array providers. To run inquiry commands to
discover host properties, ProSphere uses Windows Management Instrumentation (WMI) or
Web Services-Management (WS-MAN) for Windows operating systems. Discovery may also
take place with Secure Shell (SSH) for AIX, HP-UX, Solaris and Linux. The Software
Development Kit (SDK) for VMware Infrastructure API objects is utilized to launch inquiries
against vCenter and ESX/ESXi servers.
Using standard protocols, ProSphere will discover and store topology, capacity, and
performance information. This information can be obtained without installing agents on any
host or SAN device.
This lesson covers the functionality and flexibility in relationship views within the ProSphere
User Interface.
EMC ProSphere Fundamentals 10
The ProSphere user interface is designed to improve productivity in large complex

environments. A built-in search function locates objects across data center sites. Discovered
objects display with an end-to-end view in a Configuration Item window pane. Users may
quickly drill down within the Configuration Item window to see more details. A birds-eye
view pane provides the visual perspective to know where you are at all times as you analyze
your environment. With this new management suite, you gain a visual understanding of the
complex relationships that exist in large, highly virtualized environments to improve service
levels and increase productivity.
ProSphere monitors SAN performance across the entire data center. Threshold alerts aid in
proactive identification of performance issues to maintain service levels. A search function
quickly locates hosts or other SAN objects and displays an end-to-end view of performance
across all component dependencies. As you analyze the storage path, key performance
indicators with historical perspectives help identify performance trends or isolate
bottlenecks to quickly resolve issues.
ProSphere array lun performance can be viewed against the top five most demanding host
connections. In this screen, storage array 1120 has given performance data for the top five
most demanding luns and it has been graphed as response time over several hours.
When the cursor flys over a data point on the graph, a box pops up for each lun containing its
performance contribution for the data at that point.
From this chart, a launch-in-context service for SPA can be exercised, assuming the
discovered host is connected to a discovered array. SPA may also be launched in the context
of a Symmetrix FE director. In the case shown here, we launch SPA in the context of an Array
LUN. To do so, check a box next to the host with a LUN belonging to the array configuration
item in this window and highlight the entry. The Launch SPA option hyperlink will highlight.
The Compare Days option may also be excercised when the hyperlink is highlighted. The
dialog box for Compare Days allows you to examine a performance metric gathered on
different days for a given item highlighted in the bottom panel. The Compare Days dialog box
has two parts:
The top part of the dialog box shows a line chart with one line for each day you select in
your time range. For example, if you examine Host Devices - IO over the time period of 1w,
seven lines appear in the chart - one for each day in the week.
The bottom part of the dialog box shows a grid with detail data about the Configuration
Item you are examining. You can view detailed statistics for each day in the line chart.
A federated architecture aggregates information across sites to simplify the management of

multi-site environments. Federation is managed from within ProSphere and uses access over
the internet for remote connection to other ProSphere instances. You can search across
remote ProSphere sites to identify objects, attain an end-to-end view of all relationships and
key performance indicators, and drill down to quickly to see more details.
This module provided an overview of the Storage Resource Management related challenges
addressed by the functionality, scalability, and performance of ProSphere.
This module focuses on the architectural components of the ProSphere vApp, and describes
how they interact with each other.
This lesson discusses the foundations layer of ProSphere, the core appliances that implement
the funtionality of the ProSphere application, and the hardware requirements to install
ProSphere.
The ProSphere Foundations layer represents the core functionality within the ProSphere
suite. It manages all of the discovery processes, ProSphere user authentication, alert
notification, and User-Interface display for all of the ProSphere modules. It also manages
product licensing, topology mapping, grouping, search functions, and launch-in-context for
Symmetrix Performance Analyzer, Symmetrix Management Console, and Connectrix
Manager (Converged Network Edition).
ProSphere is deployed as a VMware vApp that bundles a set of virtual appliances running in
one or more ESX 4.x or ESX 5.0 servers. Each core virtual machine in a ProSphere vApp
participates as a member of an in-memory data grid. The data grid is a data management
system composed of a cache cluster that stores information in memory to achieve high
performance and redundancy during the service of I/O requests rather than passing the I/O
to disk.
ProSphere virtual machines can be quickly added, moved, or removed as necessary, which
gives ProSphere flexibility to adjust to changes in the data center. In large environments,
multiple instances of ProSphere can be combined in a federated manner, through a simple
but secure mechanism that runs over HTTPS and standard TCP ports using passphrases for
authentication. This avoids the need to create complex firewall policies.
The ProSphere vApp comprises three virtual machines, that are the core virtual machines of
ProSphere. The core VMs are the Storage Resource Manager, the Discovery Appliance, and
the Historical Database.
Whether a single ESX/ESXi server or a cluster is chosen as the target of a ProSphere

deployment, a standard deployment requires that a minimum of 12 virtual CPUs be available
for the vApp. The core appliances utilize a CPU clock speed of around 9320 MHz average. For
a standard deployment, you will also need 22 GB of RAM, and 600GB of disk storage space
on a single datastore if you are using thick formatted storage. This latter figure includes swap
file space.
A secondary Storage Resource Manager VM may be used with the core deployment to
offload the processing of performance data and improve ProSphere performance when there
are multiple concurrent users of the application.
When collectors are used, the Storage Resource Manager VM will require 10GB of memory
when three or four collectors are included in a ProSphere deployment. Each collector
requires two virtual CPUs, 6 GB of RAM, and 20 GB of storage space, which need not be on
the same datastore. A collector uses around 606 MHz average from the vCPUs.
EMC recommends that installations that use two or more collectors, should configure the
disk storage as RAID10 on 15k RPM Fibre Channel drives.
A standard deployment of the core product does not require either a Collector or a
secondary Storage Resource Manager. A datacenter with a higher number of configuration
items than can be effectively managed by a single discovery appliance requires a scaled-out
deployment, which may include from one to four collectors. The table presented here
defines guidelines on how to deploy ProSphere.
This lesson covers the fundamental deployment considerations for ProSphere including vApp
considerations, latency, and connecting to the application.
ProSphere deployments must abide by acceptable network latency figures.

The maximum latency between the core ProSphere VM components should not exceed 15
milliseconds.
The maximum latency between the Discovery Engine and providers or discovered objects
cannot exceed 50 milliseconds. The following exceptions hold:
Discovered Windows hosts configured for WMI must not exceed 15ms.
Hosts with more than 30ms latency must have path performance collection set to 15
minutes or more.
Between collectors and the ProSphere Storage Resource Manager, the maximum latency
should not be more than 50 milliseconds.
The maximum latency between the following ProSphere components should not be more
than 200 milliseconds:
The ProSphere Storage Resource Manager and the users web browser;
A Workload Analyzer (WLA) Archiver and the ProSphere Storage Resource Manager;
and
Any two federated ProSphere instances.
The ProSphere Application can only be accessed through the Web. However, across the Web,
there may be firewalls. These firewalls could prevent access to the ProSphere Storage
Resource Manager which hosts the web application server and may therefore require
authentication to pass through.
After intially authenticating at a firewall, a user may still be unable to access ProSphere. If so,
the possibility may exist that a DNS server being used to resolve IP addresses and DNS names
may not include the virtual machines DNS name and IP address for the ProSphere Storage
Resource Manager hosting the web application. In this case, the DNS settings would require
reconfiguration. Both the forward and reverse lookup zones should be updated.
After reconfiguring DNS however, ProSphere may still remain inaccessible. Focus then on the
users hosts file. The hosts file is a local file, which may help your local computer locate
ProSphere in the IP network.
It is important to remember that ProSphere uses standard ports for web operations and for
communication with the service providers SMI-S, WMI, SSH, SNMP, and WS-MAN. These
ports must be available to ProSphere.
The following TCP ports are used by the ProSphere Storage Resource Manager virtual
machine (typically the ProSphere Console) to communicate with browsers:
80: HTTP port for the Web Console, will redirect to the HTTPS port
443: HTTPS for the Web Console
This lesson covers the fundamental architecture of the core ProSphere virtual machines that
support the application. A brief overview of the vApp topology is also discussed.
The ProSphere Storage Resource Manager is a virtual machine that hosts the web interface
providing access to the ProSphere Console and the services running in it. The ProSphere
Storage Resource Manager also hosts the REST API and respository of discovered objects and
configuration components.
The ProSphere Console is built around Apache 2.2., Tomcat 6, Adobe Flex, and the EMC
Common User Interface Toolkit (ECUIT). Apache is an open-source HTTP server for operating
systems such as UNIX, Linux, and Windows. Tomcat 6 is an open-source Servlet/JSP container
for Apache that provides an HTTP environment for Java code to run in and Adobe Flex is
a software development kit (SDK) for the deployment of cross-platform rich Internet
applications based on the Adobe Flash platform.
The ProSphere Storage Resource Manager is the primary appliance (or virtual machine) for
servicing all Representational State Transfer (REST) API Uniform Resource Indicator
statements.
More than two dozen services run in the ProSphere Storage Resource Manager. These
services are related to application security, appliance configuration, resource configuration,
topology mapping, inter-service message handling, and application services in support of
performance management.
The Big Data Repository is the ProSphere Storage Resource Managers Resource Description
Framework (RDF) store, which also resides in this appliance. The Big Data Repository uses
REST technology and ATOM, the XML language used for web feeds. This repository stores
the configuration and topology information used in ProSphere. For more information on
Bigdata technology, go to http://www.systap.com/bigdata.htm.
The Discovery Appliance is responsible for discovering SAN devices in the data center, and for
periodically refreshing data collected from them according to user-defined policies.
Agentless discovery techniques are supported for this process. The Discovery Appliance uses
a variety of standard network protocols and standards-based interfaces to collect data from
many SAN device types. It also utilizes domain managers (DM) specialized in gathering data
from specific SAN objects such as hosts, arrays, and switches.
The Indications Domain Manager (DM) is the domain manager that receives SMI-S
indications from the SMI-S providers. SMI-S providers are used for Brocade and McData
switch discoveries and data stroage array discoveries. Indications occur when configuration
changes take place and a rediscovery must be initiated. The Indications Domain Manager
also processes SMI-S health alert traps from the Symmetrix when they occur.
Indications from Cisco SNMP traps are handled by the Traps Domain Manager.
The Path Domain Manager directs all discovery, rediscovery and performance collection jobs
to the proper domain manager responsible for handling specific discovery job types.
The Data Collection Service is responsible for collecting performance data from discovered
hosts, using switches and arrays.
When additional scalability is required, a Discovery Appliance may also manage up to four
collectors. A Discovery Appliance Collector is a specialized Discovery Appliance focused
solely on resource data collection, leaving discovery coordination and management to the
Discovery Appliance to which it reports.
More information on the Discovery Appliance components is provided in The ProSphere
Implementation and Management course.
ProSpheres Historical Database manages the historical performance data which requires
persistent storage. Historical performance data is gathered either from the near realtime
Peformance Data Collection process in ProSphere or the Performance Metric Integration
server which imports performance data from ControlCenter.
The Historical Database also keeps capacity data about the storage arrays.
Data kept in separate schemas within the Historical Database can be interrogated using a
database login through a Postgres client.
The Historical Database uses EMC Greenplum technology on the backend and PostgreSQL
services on the Frontend.
A minimal ProSphere implementation requires a virtual appliance managing three virtual

machines. In this basic configuration, the three virtual machines are the Storage Resource
Manager, Historical Database, and Discovery Appliance. The three groups of SAN objects to
be discovered are arrays, switches, and hosts. The SAN objects may be linked to supported
Element Manager applications for launch-in-context.
This lesson covers the srm-service-common service in the ProSphere application. Discussion
of this services functionality, package dependencies, and inter-dependent packages will be
included.
Here is a select listing of the services running on the ProSphere Storage Resource Manager.
Some of these services are essential to the functioning of ProSphere as a whole. In this
module, only the SRM Service Common will be covered.
One of the ProSphere Web Application servers most basic services is the SRM Service
Common.
The script that runs the SRM Service Common service contains common portions of all SRM
init scripts. It includes the logic to start, stop, and restart a service, as well as the logic to
check service status. The srm-server-common service resides in /etc/init.d.
The SRM Service Common package, which uses an EMC Ionix package license, is part of the
emc/ionix/srm package group.
The srm-service-common package is dependent on the Bourne shell and the commonsdaemon-jsvc package used to launch and control Java daemon processes.
The SRM Service Common package interacts with the packages shown here. Each package
listed is a service in ProSphere and has a number of package dependencies and
interdependent packages. An example would be:
The package srm-timeservice is listed as the service Time Service and is interdependent on
the srm-service-common service.
This module provided an overview of the Storage Resource Management related challenges
addressed by the functionality, scalability, and performance of ProSphere.
This module focuses on the Representational State Transfer (REST) API technology supported
within the ProSphere vApp, and describes how information can be managed in ProSphere
using this technology with Web Browsers.
This lesson covers the technology and functionality of the ProSphere REST API. Included in
this lesson is a discussion of REST API attributes, the REST API has been implemented in the
ProSphere application, and the hierarchy of data structure accessed through REST Uniform
Resource Identifiers (known as URIs).
In order for computer programs to access information managed by ProSphere, the ProSphere
application offers an API that follows the REST model and principles.
REST is an architectural style for designing and building distributed Web applications - first
formally described in 2000 by Roy Thomas Fielding. Mr. Fielding wrote the specifications for
Relative Uniform Resource Locators (Internet RFC 1808, June 1995), and revised them three
years later to set the standards on Uniform Resource Identifiers (URI is the generic syntax).
The Internet RFC is 2396, written in Aug. 1998. Fielding also co-authored the HTTP/1.0
specification (Internet RFC 1945, May 1996), and went on to become the primary architect of
HTTP/1.1 (Internet RFC 2616, June 1999).
REST is based on Hypertext Transfer Protocol (HTTP) standards in its purest form. It does not
require Remote Procedure Call applications over HTTP, or complex specifications for building
Web services such as those collectively known as the WS-* stack. REST does not depend on
Simple Object Access Protocol (SOAP), WS-Notification, WS-Addressing, WS-Transfer, WSMakeConnection, WS-Resource Framework (WSRF), or WS-Security.
Typically, a well-designed RESTful service does not drop HTTP cookies on the web client,
because that violates one of the guiding principles of REST, namely statelessness. For REST,
the client-server interaction must be stateless; that is, every client request must be
understood without the need for data about the state of the web session previously stored
on the server. The state of the web session must be kept entirely on the client; that is what
statelessness means in this context.
REST requires statelessness, not only for the sake of visibility and reliability between client
and server, but also for scalability purposes. Stateful web applications do not scale well, since
the server has to collect, store, and manage the state of resource usage across client
requests.
Server-created cookies are intrinsic components of stateful web architectures, because they
contain session IDs for accessing the state of the web application kept on the server. But not
all cookies are RESTless. Cookies are okay as long as the client controls their contents.
Cookies containing representations of web resource usage are RESTful, if the client creates
them and are not imposed by the server as a condition for web interaction.
RESTs key construct for information is the concept of Resource. Any piece of information can
be a resource as long as it can be the target of a hypertext reference: documents, games,
weather services, news services, and so on. Even a person may be a resource.
Some resources remain static over time, while others exhibit a great degree of variability.
However, one thing is expected to stay the same - the conceptual mapping of the entity that
is the object of a hypertext reference, the way in which the resource was conceptualized. If
the semantics of the mapping changes, the identity of the resource is lost.
This leads us to the concept of Uniform Resource Identifier (URI), which is used for linking to
a particular resource. A URI can be a Uniform Resource Locator (URL) or a Uniform Resource
Name (URN). One identifies the resource by its location; the other, by its name. Both
complement each other.
RFC 3305 discusses the differencesand confusionsurrounding the partitioning of URI
namespace and the relationships among URI, URL, and URN.
This lesson covers implementation of the ProSphere REST API. Included in this lesson is a
discussion of the RESTlet container, Model Supplier Adapters (MSA) as a common API style,
MSA compliance in ProSphere for URI syntax, and extended support for additional REST
request types.
Now we examine how the REST API has been implemented in ProSphere.
Since ProSphere runs on Apache Tomcat6, REST has been deployed inside a Tomcat Servlet
container. A servlet is a Java component that can be plugged into a Java-enabled web server
to provide custom services, such as runtime changes to content and presentation, new
standard protocols, or new custom protocols. Servlets are designed to work within a
request/response processing model.
Again, REST has been implemented inside the Tomcat Servlet container, using the leading
REST framework for Java, which is the Noelios Restlet Framework (or NFR). NFR was the first
piece of software across all languages to propose a development framework designed on the
basis of REST concepts. NFR matches all REST concepts to concrete Java class equivalents.
The Restlet API offers a higher level view of the HTTP protocol. It tries to abstract and
present in a clean object model, the application-level semantics of HTTP.
Originally, the term MSA was used to describe an approach by Ionix products to expose IT
Infrastructure information through a REST interface. The purpose was to define a set of REST
patterns and best practices that any Ionix product could use to open its information model to
other products. Those patterns and best practices, however, were crafted with the explicit
intention of not imposing a common information model, but rather to leverage pre-existing
ones through a simple and uniform set of RESTful directives.
The Model Supplier Adapter sits on top of the product, imposing little or no change to the
underlying code in the product. Neither the product's UI, core logic, functions, nor data are
required to be modified when an MSA API is added.
More than one MSA API can exist depending on the type of interaction different users want
to have with the product. For instance, a fine grained MSA API may be used that exposes a
rich body of product resources, or a coarse grained MSA API may be used for users
concerned with a limited subset of product resources.
ProSphere 1.0 introduced a RESTful interface that exposes managed information to other
computers.
In ProSphere version 1.5, the REST interface was made compliant with the Model Supplier
Adapter (MSA) 2.0.
MSA compliance allows ProSphere to be consistent with a common REST API style across
EMC products.
By using the ProSphere Rest API to retrieve data discovered and processed by ProSphere,
application developers can build their own applications and mashups that leverage this
information. The ProSphere Rest API is accessible through the ProSphere Application using
any browser or programming platform that can issue an HTTP Get request.
The base URL of the REST API is:
https://<Prosphere_StorageResourceManager DNS Name
address>/srm/topology/msa/types.
At present, Prospheres REST API provides information on storage arrays, SAN switches,
hosts, and performance data. The Base URL is modified to access the array, switch, or host
data by appending to the URL the type of data being requested. A modified URL for arrays is:
https://<StorageResourceManager DNS
name>/srm/topology/msa/types/StorageArray/instances. Substitute arrays for switches or
hosts to receive the appropriate data.
The ProSphere MSA-compliant REST API allows you to extract the following data:
*Topology for arrays, hosts, switches and fabrics, ports, LUN paths, volumes, datastores,
partitions, RDM disks and VMFS disks.
*Performance data for arrays, hosts and devices, switch ports, and system health.
*Capacity data for arrays, storage volumes, storage pools, and service levels.
*Alert data, service level & storage tier data, software update data, and log management
data.
With the ProSphere REST API, you can view the representations of discovered configuration
items in the ProSphere storage environment. Other activities include: obtaining event
information, sorting and filtering for specific criteria on discovered configuration items and
events, deleting discovered configuration items and events, and viewing information about
data imported from the EMC ControlCenter Performance Manager.
ProSpheres URI syntax is MSA 2.0 compliant. The MSA URI identifiers accurately describe
which resource is being specified. This conforms with the REST architecture style.
The base URI to retrieve log management information however, is not MSA compliant in
ProSphere (use /srm/logmgmt in the path).
The base URI for performance data import jobs from a WLA Archiver also, is not MSA
compliant in ProSphere(/srm/system/migration/jobs/performance).
The underlying reason for these exceptions is that MSA 2.0 follows the Resource Oriented
Architecture (ROA) approach to the REST API design. The ROA design approach exposes two
major resources: resource instances and resource types. Resource Instances are
representations of IT Infrastructure items. Resource Types represent metadata about a
resource's "class, "type, or "kind". Neither log management information nor WLA Archiver
imported information fall into these categories.
Log files kept in ProSphere are not accessed using REST methods. Log categories and associated files are accessed using
https requests inside a browser. Several examples follow:
https://{ServerName}/srm/logmgmt/categories returns a collection of component categories you can use to retrieve
log management information.
https://{ServerName}/srm/logmgmt/alerting/components returns log level and log file size information for the
Alerting Service.
https://{ServerName}/srm/logmgmt/discovery/components returns log level and log file size information on the
following discovery components:
o Discovery REST Service
o Array Domain Manager
o Active Discovery Probe Service
o Broker Service
o Discovery Configuration Service
o Host Domain Manager
o Indication Domain Manager
o Path Domain Manager
o SAN Domain Manager
o Service Daemon
o Trap Daemon
o VMware Domain Manager
https://{ServerName}/srm/logmgmt/infrastructure/components returns log level and log file size information on the
following infrastructure components:
o Configuration Service
o Events Manager Service
o Events REST Service
o Events REST Service
o Launch-in-context Service
o Log Management Service
URI https://{ServerName}/srm/logmgmt/monitoring/components returns log level and log file size information for
the Monitoring Service.
URI number 6 returns log level and log file size information on the following performance components:
o Historical Service
o Performance-metric Integration Server
o Active Directory Probe Service
o Data Collection Registry Service
o Data Collection Thread Manager Service
o Discovery Service RESTlet Service
Use URI number 7 to obtain a list of log level and log file size information on the following
components:
o Apache Web Server Service
o Cache Server
o Firewall Service
o Time Service
o VAMI
o XML Database Service
URI number 8 returns log level and log file size information on the following topology components:
o Discovery Data Service
o Map Service
o Topology Service
URI number 9 returns log level and log file size information on the following Web Server components:
o Flex Proxy
o User Management Service
o Tomcat Service
o Login Monitor Service
Shown here are the base URIs for some capacity metrics collected by ProSphere. Executing a
GET at these URIs will display a list of all objects existing in ProSphere which conform to the
object type shown. More capacity-related URIs are available and documented in the
ProSphere REST API Online Help.
ProSpheres MSA Configuration service manages configuration data required for communication between
ProSphere appliances, as well as information exchange between various services within the appliances. The
Configuration service outputs details regarding its operations through MSA compliant feeds. The MSA URIs
shown above can be accessed from any one of the ProSphere appliances, however attempting to access the
URIs on the Discovery Engine, Collector, or Historical Database results in a redirection to the ProSphere
Application through the MSA Proxy Configuration Service. This should be expected, since the MSA
Configuration Service only exists on the ProSphere application, but handles activity throughout the entire
ProSphere instance.
Purposes for the MSA URIs shown here are as follows:
/srm/configuration/msa/types/SRMAppliance/instances
ProSphere Application details from OVF XML
/srm/configuration/msa/types/SRMDBAppliance/instances
Historical Database details from OVF XML
/srm/configuration/msa/types/DiscoveryAppliance/instances
Discovery Engine details from OVF XML
/srm/configuration/msa/types/ServiceAccount/instances
Historical Database credentials
/srm/configuration/msa/types/TopologyService/instances
IIL filter used for discovery push from the Discovery Engine
/srm/configuration/msa/types/DMBroker/instances
Discovery Engine broker port and credentials
/srm/configuration/msa/types/TCNSubscriber/instances
List of events and recipients related to TCN routing mechanism
/srm/configuration/msa/types/HostResolutionConfiguration/instances
Host Resolution Enabled/Disabled
If a ProSphere user is experiencing difficulty accessing any of the URIs listed above, the log files shown can be
searched for errors regarding the Configuration MSA service.
In addition to servicing Get requests from the REST client, ProSphere supports PUT, POST,
PATCH, and DELETE in MSA 2.0
This module covered the background and technology behind the use of the REST API in
ProSphere. The concept of Model Supplier Adapters was discussed with a focus on URI
syntax, data available to be queried through the REST API, and supported request types from
REST clients.
This module focuses on the deployment of ProSphere and basic considerations that must be
made in the environment for successful discovery.
This lesson covers the fundamental issues that must be considered for a successful
deployment. Fundamental configuration issues are considered for hosts, providers, the ESX
servers on which ProSphere will be deployed, and the vApp to be created on the ESX servers
in a VMware environment.
All communication between ProSphere and discovered SAN objects must take place on
certain IP ports. These ports will be identified in this lesson.
Successful host discovery with ProSphere requires EMC-supported host bus adapter (HBA)
drivers, firmware, and host names that are alphanumeric. Host names may also contain a
hyphen, but not special characters. The ProSphere Deployment Guide contains the list of
illegal characters.
Although, preparation of an environment for deployment of the product requires HBA
validation and configuration of the SMI-S provider that supports resource discovery and data
collection, you might think that the prep work is limited to the configuration of host, switch
and array related components in the discovery infrastructure. But this is not entirely correct.
ProSphere is a network application depending on Web availability, not only for access to its
console, but also for exposure of its data to internal processes and external applications via
REST technology. Because of this Web dependence, the deployment of ProSphere demands
attention to the IT components stretching from the Web to the arrays.
Connecting to the ProSphere application from a workstation with a supported browser

requires that a number of tasks be accomplished to assure the connection will be successful.
The following concerns should be addressed:
When connecting to the application, if a firewall must be passed, it must be determined
that it will allow communication over port 443?
Does the connecting workstation have Adobe Flash Player version 10.2.153.1 or later
installed for browser support?
Will certificates be used for security during the setup of connections?
Is the connecting workstation setup so that the DNS Fully Qualified Domain Name of the
ProSphere Web Application server can be resolved to its IP address? And will it also resolve
for a reverse DNS lookup?
Prior to deployment of the ProSphere vApp, your solution should consider the following
points:
How many datacenters does the business have where ProSphere will be deployed?
Will the business use an internal web server or ISO files for ProSphere updates?
Will there be migration of historical performance data from Ionix ControlCenter to
ProSphere?
Will LDAP authentication be used for user accounts in ProSphere? If so, does Active
Directory include Identity Management for UNIX role service?
Will business specific SSL be deployed with ProSphere? ProSphere supports only X.509
certificates and is deployed with self-signed SSL certificates. For added security, EMC
recommends obtaining and deploying signed SSL certificates specific to the business.
You can deploy ProSphere on a single ESX/ESXi server or a cluster. A single ESX/ESXi-server
deployment is recommended for small-to-medium-sized installations that do not anticipate
significant growth in the near future.
If deploying on a cluster, all ESX/ESXi servers must be synchronized to an external Network
Time Protocol (NTP) server. Unsynchronized ESX/ESXi servers will lead to issues with many
different operations and services within the ProSphere architecture.
ProSphere discovery may collect details on the presence of switches, arrays, and hosts in a
datacenter infrastructure. Discovery is a straight forward agentless process where discovery
jobs are created in ProSphere. Discovery jobs are then managed and processed by the
Discovery Appliance to determine the SAN objects which exist in the infrastructure.
The nature of the agentless discovery process is that ProSphere uses standard interfaces and
protocols, which if configured properly on the SAN device, permit ProSphere to authenticate
to the device and query it for specific information which ProSphere will then display in its
User Interface.
ProSphere can identify hosts without launching an active discovery. This can be
accomplished through SAN configuration name data. This type of host identification, which is
sometimes referred to as agentless passive discovery, results in system created hosts.
Agentless passive discovery utilizes a zone name to identify a host, the host name is then
validated using host resolution against a DNS server. If DNS validation succeeds, host
resolution collects additional host attributes, including the IP address of the host and the
name of the hosts domain.
In order for this operation to work, consistent zone naming conventions must be followed. It
is recommended that only one zone per host exist in the fabric, and that the name of this
zone include the exact fully qualified domain name of the host. If pre-existing zone names
are not in a format that would allow ProSphere to extract the host name, it may require
extensive manual work to adjust the zone names.
During the discovery process it is vital that communication between the Discovery Appliance
and the SAN object being discovered take place over the port required for a successful
discovery. The following TCP ports are used for communication between the Discovery
Appliance and hosts that serve as data sources:
Some hosts may serve as a proxy for arrays.
22 (TCP): SSH port
135 (UDP): Required for WMI discovery of Windows hosts
136 (UDP): For the PROFILE naming system
138 (UDP): For the NETBIOS datagram service

161: SNMP
162 (UDP): SNMP trap adapter used to receive SNMP traps
443 (TCP): For both VMware infrastructure discovery and WS-MAN discovery over SSL
5988: For SMI. Configurable in the SMI-S Access Credential dialog box
5989: For secure SMI. Also configurable in the SMI-S Access Credential dialog box
5985 (TCP): For WS-MAN discovery over HTTP
5986 (TCP: For WS-MAN discovery over HTTPS
This module provided an overview of the fundamental considerations that should be made in
a SAN infrastructure prior to deploying ProSphere as a Storage Resource Management
application.
This course covered the fundamental concepts of the ProSphere application including its
architecture, SAN object discovery methods, deployment considerations, and the REST API.
This concludes the training.

Prosfund17 - 2013 - SRG BY EMC

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Prosfund17 - 2013 - SRG BY EMC

Hochgeladen von

Copyright:

Verfügbare Formate

Welcome to EMC ProSphere Fundamentals.

Revision Date: February 2013

Copyright 2013 EMC Corporation. Do not copy - All Rights Reserved.

EMC ProSphere Fundamentals

Copyright 2013 EMC Corporation. Do not copy - All Rights Reserved.

EMC ProSphere Fundamentals

This module provides an overview of Storage Resource Management related challenges

Copyright 2013 EMC Corporation. Do not copy - All Rights Reserved.

EMC ProSphere Fundamentals

Copyright 2013 EMC Corporation. Do not copy - All Rights Reserved.

EMC ProSphere Fundamentals

Copyright 2013 EMC Corporation. Do not copy - All Rights Reserved.

EMC ProSphere Fundamentals

Copyright 2013 EMC Corporation. Do not copy - All Rights Reserved.

EMC ProSphere Fundamentals

Copyright 2013 EMC Corporation. Do not copy - All Rights Reserved.

EMC ProSphere Fundamentals

Copyright 2013 EMC Corporation. Do not copy - All Rights Reserved.

EMC ProSphere Fundamentals

Copyright 2013 EMC Corporation. Do not copy - All Rights Reserved.

EMC ProSphere Fundamentals

Copyright 2013 EMC Corporation. Do not copy - All Rights Reserved.

EMC ProSphere Fundamentals 10

The ProSphere user interface is designed to improve productivity in large complex

Copyright 2013 EMC Corporation. Do not copy - All Rights Reserved.

EMC ProSphere Fundamentals 11

Copyright 2013 EMC Corporation. Do not copy - All Rights Reserved.

EMC ProSphere Fundamentals 12

Copyright 2013 EMC Corporation. Do not copy - All Rights Reserved.

EMC ProSphere Fundamentals 13

A federated architecture aggregates information across sites to simplify the management of

Copyright 2013 EMC Corporation. Do not copy - All Rights Reserved.

EMC ProSphere Fundamentals 14

Copyright 2013 EMC Corporation. Do not copy - All Rights Reserved.

EMC ProSphere Fundamentals 15

Copyright 2013 EMC Corporation. Do not copy - All Rights Reserved.

EMC ProSphere Fundamentals 16

Copyright 2013 EMC Corporation. Do not copy - All Rights Reserved.

EMC ProSphere Fundamentals 17

Copyright 2013 EMC Corporation. Do not copy - All Rights Reserved.

EMC ProSphere Fundamentals 18

Copyright 2013 EMC Corporation. Do not copy - All Rights Reserved.

EMC ProSphere Fundamentals 19

Whether a single ESX/ESXi server or a cluster is chosen as the target of a ProSphere

Copyright 2013 EMC Corporation. Do not copy - All Rights Reserved.

EMC ProSphere Fundamentals 20

Copyright 2013 EMC Corporation. Do not copy - All Rights Reserved.

EMC ProSphere Fundamentals 21

Copyright 2013 EMC Corporation. Do not copy - All Rights Reserved.

EMC ProSphere Fundamentals 22

ProSphere deployments must abide by acceptable network latency figures.

Any two federated ProSphere instances.

Copyright 2013 EMC Corporation. Do not copy - All Rights Reserved.

EMC ProSphere Fundamentals 23

Copyright 2013 EMC Corporation. Do not copy - All Rights Reserved.

EMC ProSphere Fundamentals 24

Copyright 2013 EMC Corporation. Do not copy - All Rights Reserved.

EMC ProSphere Fundamentals 25

Copyright 2013 EMC Corporation. Do not copy - All Rights Reserved.

EMC ProSphere Fundamentals 26

Copyright 2013 EMC Corporation. Do not copy - All Rights Reserved.

EMC ProSphere Fundamentals 27

Copyright 2013 EMC Corporation. Do not copy - All Rights Reserved.