Embed Size (px)
Citation preview
Amsterdam - Dallas - Ottawa
www.savision.com
April 2015
Instrumenting the Hybrid Cloud
AUTHOR: MICROSOFT MVP JOHN JOYNER
Amsterdam - Dallas - Ottawa
www.savision.com
Contents
Preface 3
Introduction to Hybrid Cloud Management 4
1. Deploying Operations Manager and Management Packs 5
1.1 SCOM as part of a System Center Strategy 5
1.2 SCOM Gateways and Certificate Authentication 5
1.3 SCOM Architecture to Support Hybrid Cloud Monitoring 6
1.4 SCOM Management Packs for the Hybrid Cloud 7
2. Creating Hybrid Cloud Distributed Applications 8
2.1 Azure Cloud Service Distributed Applications 8
2.2 Authoring Custom Azure Distributed Applications 9
2.3 Authoring Custom AWS Distributed Applications 10
3. Add Fidelity by Considering all Internal and External
Dependencies 11
3.1 DA Authoring to Capture Hybrid Cloud Architecture 11
3.2 Identifying and Adding Internal and External Dependencies 12
4. Leverage Presentation and Visualization Tools 13
4.1 Diagramming Defaults in SCOM 13
4.2 Microsoft native solutions for better diagrams 14
4.3 Savision Live Maps Unity: The premier SCOM dashboard tool 15
Summary 16
Amsterdam - Dallas - Ottawa
www.savision.com
Preface Cloud service providers such as Microsoft Azure and Amazon AWS are doing a good thing by releasing ever more useful,
practical, and economically appealing cloud services. The portals, dashboards, and programmatic access cloud service
providers offer to consume and manage their services are extensive and constantly evolving.
Most every cloud service consumer depends on several interdependent cloud products working together, such as access
control, networking, and storage. And most enterprises have a hybrid mix of on-premises and in-cloud resources that work
together to perform line of business work.
A challenge emerges when you want to see “the big picture” of the availability and performance of a hybrid enterprise
application. A vital business need is to achieve a holistic viewpoint, or perspective, that synthesizes application resource
elements wherever they reside.
Amsterdam - Dallas - Ottawa
www.savision.com
Introduction to Hybrid Cloud Management Instrumenting your public cloud, private cloud, and on-premises infrastructure with System Center technologies is the best
approach an IT manager can take. From the System Center vantage, with properly deployed instrumentation, problem
identification and resolution can be dramatically accelerated.
The secrets to effectively managing distributed and hybrid cloud components are instrumentation and visualization. You need
to place the right sensors in the right places, and present data to decision makers in dashboards and diagrams that can be
processed visually and instantly. No amount of automation or even artificial intelligence can equal the human mind’s power to
reach rapid accurate conclusions based on visual representation.
Microsoft System Center is a world class platform for deploying monitoring sensors against all types of IT workloads. System
Center’s built-in distributed application model and default diagram tools are a starting point for visualization. System Center
tools from Microsoft partners, like Savision Live Maps Unity, let you visualize topology and workflow for effective decision
making in any IT scenario.
There are four high level steps to consider in this approach:
1. Deploy System Center Operations Manager (SCOM) with appropriate management packs, and then discover the
computers and services in your cloud and on-premises estates.
2. Create distributed applications in SCOM that model your hybrid cloud applications.
3. Add fidelity to your distributed applications by considering all internal and external dependencies.
4. Create a presentation layer for the health and status of your hybrid cloud applications by authoring dashboards,
charts, and diagrams that leverage the human power of visual processing.
This white paper will walk the reader though these four phases of solution deployment. Few activities in the world of cloud
management will pay higher dividends than investing in effective cloud visualization.
Amsterdam - Dallas - Ottawa
www.savision.com
1. Deploying Operations Manager and
Management Packs Microsoft System Center Operations Manager (SCOM) is the monitoring and management engine that will present a ‘single
pane of glass’ that is a ‘source of truth’ in hybrid scenarios. SCOM can do this because SCOM management packs can monitor
any hardware and any Microsoft or non-Microsoft software—thus the single pane of glass. SCOM is also the source of truth
because SCOM distributed application monitors can account for the health of all business-critical components wherever they
physical or logically reside.
1.1 SCOM as part of a System Center Strategy
SCOM is a component of the System Center 2012 suite of applications which are licensed as a bundle. Unlike many other
enterprise monitoring applications, SCOM ‘snaps into’ a deep and sophisticated framework of complementary tools that
accomplish all modern IT business functions. For example, System Center Configuration Manager (SCCM) for
updating/patching, System Center Data Protection Manager (SCDPM) for backup and data recovery, and System Center
Service Manager (SCSM) for incident management including ticketing and change control.
If an organization is already licensed for System Center as part of a Microsoft enterprise software agreement or because
another System Center component such as SCCM is already in use, then deploying SCOM can essentially occur without any
license costs. (The Windows Server OS the SCOM server is running on needs a license, but that might be included in a
Windows Server Datacenter license for the virtualization host.). Microsoft bundles a free SQL Server Standard license to
customers using SQL only for System Center databases, whether the SQL Server resides on the SCOM server itself or in a
separate SQL instance.
Even if there is no pre-existing System Center license, an organization can’t go wrong investing in the Microsoft management
solution. Because SCOM can ‘straddle’ public and private clouds, SCOM is particularly indicated for organizations with
significant hybrid and/or public cloud resources to manage today or planned for in the future.
Once SCOM has discovered (that is, inventoried and classified) those heterogeneous cloud resources; disparate elements
that are actually dependent on one another can be connected in holistic distributed application models. Diagrams of those
models represent the most accurate, and possibly the only true way, to assess and support hybrid cloud operations.
1.2 SCOM Gateways and Certificate Authentication
Architectural features of SCOM that make it the perfect engine for hybrid cloud monitoring are (1) the Gateway Server and (2)
the security mechanism of certificate-based federation between SCOM Gateway Servers and SCOM Management Servers.
By placing gateways in each public or private cloud segment as well as on-premises network(s), a single SCOM management
server can achieve a holistic view of all IT resources in all environments.
The use of digital identity certificates in place of username/password for authentication (or federation) between SCOM servers
is key--even as you span multiple Windows Active Directory domain trust boundaries and remote, disconnected network
segments. Another desirable feature of the SCOM solution is that agent to gateway, and gateway to management server
traffic, is always an outbound SSL connection that requires little special firewall consideration.
Amsterdam - Dallas - Ottawa
www.savision.com
1.3 SCOM Architecture to Support Hybrid Cloud Monitoring
The best physical network location from which to monitor all your cloud resources is the ‘high ground’ of a Management
Cloud. Consider deploying your SCOM management server in the public cloud service of your choice, or in a private cloud
with a well-connected vantage point such as a DR site. The management cloud should ideally ‘stand-alone’ and not be
dependent on resources in the cloud(s) to be monitored.
The SCOM management server does not need to be a member of any trusted Active Directory domain to fully manage
domain-joined computers in the monitored environments. As shown in Figure 1, a single SCOM management server
can monitor computers in multiple remote clouds by using Gateway Servers and certificate-based authentication.
Direct agent to management server communication is also possible using certificates.
A single “all in one” SCOM management server (that is, all SCOM management roles and SQL Server on one server)
can manage over 100 servers. As monitoring needs scale, scale the management cloud: The SQL database and
report server functions of the management server can be split off, and other management servers added to
management server pool. In this manner thousands of computers and network devices can be monitored.
Figure 1 - A single SCOM Management Server (lower right) monitoring multiple remote cloud environments.
Amsterdam - Dallas - Ottawa
www.savision.com
1.4 SCOM Management Packs for the Hybrid Cloud
In addition to deploying SCOM gateways and agents to monitored computers, SCOM management packs for the cloud fabrics
of your target environments need to be imported as well. Consult this Wiki article at Microsoft TechNet for step by step
instructions on deploying the Microsoft Azure Fabric management pack (including the download link):
http://social.technet.microsoft.com/wiki/contents/articles/29244.system-center-management-pack-for-windows-
azure-fabric-october-2014-release.aspx.
The management pack for Amazon AWS can be downloaded at this link:
https://aws.amazon.com/windows/products/system-center/
Amazon provides the following four-step procedure to use their management pack (follow these links for the details, this
white paper does not cover the detailed steps):
1. Installing the AWS Management Pack
2. Configuring the Watcher Node
3. Create an AWS Run As Account
4. Run the Add Monitoring Wizard
The way the Amazon management pack discovers and monitors resources is different from the Azure management pack. The
Azure management pack discovers all components in a subscription (VMs, Cloud Services, and Storage) and then has you
select which ones you want monitored. The AWS management pack lacks the granularity to select specific resources to
monitor; it automatically monitors all discovered AWS components (CloudFormation Stacks, CloudWatch Metric Alarms, EBS
Volumes, EC2 Instances, Elastic Beanstalk Applications, and Elastic Load Balancers).
The SCOM console in Figure 2 demonstrates host-level reporting on guest disk queues across AWS EBS Volumes.
Figure 2 - Viewing disk queue length across multiple AWS EBS volumes (a telltale sign of slow storage).
Amsterdam - Dallas - Ottawa
www.savision.com
2. Creating Hybrid Cloud Distributed
Applications A generic IT definition of a Distributed Application (DA) is software that is executed or run on multiple computers within a
network. Microsoft adapted this standard terminology to apply specifically to the DA monitoring construct in SCOM.
DAs in SCOM are custom top-level monitoring objects you author that contain user-defined components and
relationships. DAs are containers that represent Line of Business applications unique to your environment.
DAs collect and assemble monitoring objects of different classes and locations that depend on each other to get work
done. DAs conditionally evaluate the health of contained objects to facilitate accurate recovery tasks.
System Center partners can leverage DAs in their products to accelerate advanced diagramming and mapping by
directly importing DAs (Savision Live Maps Unity included).
Most Microsoft and third-party “sealed” System Center management packs (by necessity) are not flexible in the health models
they monitor and alert on—for example, everyone’s Exchange or SharePoint servers work about the same. DAs are SCOM’s
‘blank canvas’ -- or even ‘living whiteboard’ -- where you decide what components of your clouds and environments need to
be monitored together to get ‘the single pane of glass’. With accuracy and cleverness in the authoring of your hybrid cloud
DAs, a ‘source of truth’ emerges that should be of very high value to your business.
2.1 Azure Cloud Service Distributed Applications
If you have selected one or more cloud services in your Azure subscription for monitoring, the Azure fabric management pack
will create DAs. While Individual VMs in IaaS roles are not automatically monitored as service. Azure Cloud Services defined
by worker and/or web role instances deployed in scalable tiers are monitored via DAs as shown in Figure 3.
Figure 3 – An Azure web site Distributed Application with two role instances.
Amsterdam - Dallas - Ottawa
www.savision.com
As the red arrow indicates in Figure 3, SCOM management pack authors can add high value by including in-line tasks to
accomplish common administrative tasks. In this example, the Change Number of Role Instances task becomes active when
you select a scalable Azure service in the diagram view. Extending to operators the ability to interact programmatically with
the back-end public cloud provider without having to open the cloud provider portal is potentially very useful in delegated and
remote administration scenarios.
2.2 Authoring Custom Azure Distributed Applications
The Azure management pack also includes a DA Template Windows Azure Distributed Application that guides you in authoring
a DA that includes Azure fabric components. The Microsoft TechNet Wiki article previously mentioned in this white paper
walks the reader through creating a DA for an Azure application that features two IaaS VM instances that share the same
storage account for the location of their virtual hard disks (VHDs).
The end product of that Wiki Article is a DA named ‘N0004 & N0005 VMs’ which represents an Azure-based service consisting
of two independent VMs—both of which need to be running for the combined service to meet a service level objective (SLA)
of 99.0% availability. The design of the DA helps us determine if VM outages are possibly related to failure of a common
storage account.
Figure 4 shows the Live Maps Unity Services view of that DA (inside the SCOM console) when it was imported directly into
Savision Live Maps Unity. A superb benefit of the Savision product -- and doing this DA to Live Maps Unity import -- is that a
‘source of truth’ SLA definition was created automatically in the process. Live Maps Unity deftly communicates in one pre-
configured diagram that the SLA has been exceeded with an actual 99.672% availability in the past month, including instant
visual validation for every day of that month. This type of transparent service-centric SLA which transcends specific computer
health is the future.
Figure 4 –Service Map of an Azure Distributed Application imported directly into Live Maps Unity.
Amsterdam - Dallas - Ottawa
www.savision.com
2.3 Authoring Custom AWS Distributed Applications
As described in section 1.4 of this white paper, the AWS management pack creates objects for (and automatically starts
monitoring of) all discoverable CloudFormation Stacks, CloudWatch Metric Alarms, EBS Volumes, EC2 Instances, Elastic
Beanstalk Applications, and Elastic Load Balancers. Each discovered instance of each AWS object class becomes available
to add to a SCOM DA that includes AWS elements or dependencies.
Unlike the Azure fabric management pack, the Amazon AWS management pack does not include a DA template to get you
started. Instead, just start adding AWS monitored objects to a new or existing DA like any other class of SCOM object. Since
we are building a DA that includes heterogeneous cloud components, we’ll add dependent AWS EC2 instances to our existing
Azure application DA. Figure 5 shows the same DA ‘N0004 & N0005 VMs’, renamed to ‘Azure – AWS – Hybrid Application’,
and on the right side, two AWS EC2 instances (‘Master’ and ‘IIS’) are added as dependent VMs.
Figure 5 - Authoring a Distributed Application that contains Azure and AWS fabric components.
The updated DA shown in Figure 5 represents an application that requires four (4) VMs: two (2) in Azure and two (2) in Amazon
AWS to be running. The common Client Perspective object at the top indicates the same ‘SCOM1’ server is running the Azure
and Amazon management packs and querying the respective cloud services for the status of the objects of interest.
The health models for Azure VM and Amazon EC2 instance objects are very different. The Azure VM object in the DA only
represents the Windows Azure Role Status. The health model of an Amazon EC2 instance is more sophisticated and includes
performance monitoring of the EBS Volumes the EC2 instances are using, as well as automatic mapping of discovered
Windows Computer instances to corresponding EC2 instances.
Amsterdam - Dallas - Ottawa
www.savision.com
3. Add Fidelity by Considering all Internal
and External Dependencies One could say this is where the fun begins, because now you can get creative to great benefit. You can start to convert human
knowledge into DAs that through their design perform the problem-identification work an engineer would. You will determine
which objects to watch in order to identify and isolate faults in the application from an end-to-end perspective.
In every hybrid IT application, some objects to watch and check may be on-premises or in private cloud environments, and
other monitored objects in public clouds or PaaS solutions. SCOM is a fantastic platform to create a top-level ‘single source
of truth’ because you have essentially a rich pallet of sensors that when arranged thoughtfully in a DA can remove doubt when
things go wrong.
3.1 DA Authoring to Capture Hybrid Cloud Architecture
Once you have authored a Distributed Application (DA) that includes the core cloud elements that comprise your application,
a wise investment in time is to add fidelity to the DA. This is done by adding other monitored objects and relationships on
which either the core cloud elements or the overall application depend. These are additional pulse points with relationships
that add valuable meaning to otherwise isolated or difficult to interpret diagnostic data.
If you have broadly deployed SCOM agents to Windows and UNIX/Linux servers in your environment, as well as discovered
the network devices such as switches and routers in your datacenter(s), you are probably already monitoring many relevant
objects that could involve cloud dependencies. You also have the built-in SCOM Web Application, Synthetic Transaction, and
Port Monitoring features ready to use. Not to mention the ability to author custom discoveries, rules, monitors, and tasks in the
SCOM Authoring console. Consider these tips when authoring a DA:
Objects to monitor are your sensors, your ‘eyes and ears inside the machine’. Select from existing ones, or author
as many objects, rules, or monitors as you need. Check everything you would if you actually had to perform a manual
end-to-end check of every hop and step in a client-server conversation.
The DA framework includes the visual concepts of components and relationships. Components are containers that
can roll-up the health of one or more classes of objects. You can name components anything that makes sense in
your environment. Dependencies and hosting relationships are indicated by the relationships between components
that you author.
By the design of the DA, allow cause analysis to occur visually and instantly. ‘Paint’ your DA in the Distributed
Application Designer of the SCOM console using objects as sensors, and components and relationships as decision
making indicators. Opening a DA Health Explorer by default exposes only unhealthy components.
Basically, you need a SCOM monitor at each ‘critical pulse point’ of your application, and you need to arrange those monitors
in a DA such that accurate dependencies are indicated. The best DAs are designed to enable the viewer to immediately spot
the cause of a problem. Remember that DA diagram views, like all SCOM diagram views, have a Filter by Health control in
the menu bar to ‘zero in’ on objects in Critical or Warning states. DAs by design expose the components and relationships in
the DA as conventional hierarchical SCOM health models.
Amsterdam - Dallas - Ottawa
www.savision.com
The DA shown in Figure 5 can become unhealthy in a variety of ways, and by visual inspection of the DA diagram, one can
immediately discern at least the five (5) statuses as shown in Table 1:
‘Azure – AWS – Hybrid Application’ Health Model Most likely status
1 x Azure VM is down but the other is up Issue is with the one Azure VM.
All Azure VMs are down but Azure storage is up Possible Azure datacenter issue (VMs)
All Azure VMs and Azure storage is down Possible Azure datacenter issue (storage)
1 x AWS VM is down, the other is up Issue is with the one AWS VM.
All AWS VMs are down Possible AWS datacenter issue
Table 1 – Most likely possible status results from Hybrid Application DA health model.
Finally, remember that DAs, while authored and viewable as diagrams, also automatically generate a health model than can
be seen in the Health Explorer view of the DA. Monitored objects (and their included health models) will ‘roll up’ into
components. DA components will appear as top-level rollup monitors.
3.2 Identifying and Adding Internal and External Dependencies
Now step back and take a look at your DA and consider: What could bring one of the components in the DA down? Specifically,
if one or more core DA components become unhealthy, you want to anticipate what could have gone wrong and add that
knowledge to the DA. Rarely if ever will the production performance of an Azure or AWS VM depend exclusively on resources
internal to the VM. Dependencies to consider include:
1. Domain name registration, name server availability
2. Specific DNS A, CNAME, MX, SRV, or other records
3. Firewall, router, switch, proxy, and load balancer devices
4. Active Directory and/or other security identity provider(s)
5. ISP and WAN circuits to Internet and between datacenter(s)
6. Datacenter fabric aspects: Virtualization hosts, storage networks
7. External databases or data sources such as web feeds
8. Public cloud service subscription(s)
It’s not uncommon to find every one of these dependencies present in many hybrid cloud solutions—often with some
components duplicated on public and private sides. That is, users may need to straddle the corporate network and the Internet
with their devices to get their work done. So things like public and private DNS as well as inside and outside authentication
and routing paths may need to be captured in your DA design.
You don’t want to include everything possible in your DA, this will make it too noisy and/or unwieldy to work with. You know
the weaknesses of your environments the best, so you can prioritize from the list of 8 considerations above, and the many
others you may be aware of in your solutions. Ask yourself these two questions:
If everything in my DA were green and users were still reporting an outage, what are the most likely things that could
be wrong?
If something in my DA were yellow or red, what would be next things I would check to narrow down the cause?
Answers to the first question lend themselves to User Experience Monitoring (UEM) by considering what is between the client
device and the core DA components that are otherwise healthy. Answers to the second question focus inward: we attempt to
isolate faults to known (or anticipatable) dependences of the core DA components. If you could extend the fidelity of your DA
by one level in each dimension, you could potentially shave minutes or more off triage time of incidents involving this
application. You can also increase accuracy of issue identification, even collapsing hours of incident escalation to real-time
remediation path discovery.
Amsterdam - Dallas - Ottawa
www.savision.com
4. Leverage Presentation and Visualization
Tools We know the human mind can process visual messages such as diagrams, charts and gauges thousands of times faster than
from reading words. As a smart IT architect, tap into that potential by combining the rich power of System Center with that
unique human visual processing talent. In this last section of the white paper we will explain some diagramming limitations of
the built-in SCOM console, and then compare solutions using native Microsoft tools and Savision Live Maps Unity.
4.1 Diagramming Defaults in SCOM
As described in Section 3 of this white paper, we have extended the basic DA of our Hybrid Azure AWS application as seen
in Figure 5 with internal and external dependencies. Table 2 lists the additional components that were added to the DA to add
fidelity through selected external and internal dependencies.
Dependency DA Component
Azure VMs depend on on-premises AD Active Directory Doman Controller
On-premises AD depends on Azure VPN Network Device Monitor for VPN Endpoint
AWS components depends RSS Feed SCOM Web Application Monitor
Table 2 - Selected external and internal dependencies added to the DA.
In this scenario, the additional components represent two business needs: (1) for the Azure VMs to communicate with on-
premises Active Directory (AD), and (2) for the Amazon VMs to download an RSS feed over the Internet. Also, since access
to the on-premises AD depends on the Azure Site to Site (S2S) VPN, a VPN outage can be identified as a leading cause of
AD unavailability to servers in the cloud. Figure 6 shows the DA extended with these additional components.
Figure 6 - Extended DA includes dependencies on internal AD and external web site (an RSS feed).
Amsterdam - Dallas - Ottawa
www.savision.com
The DA as laid out in Figure 6, after having just been authored in the SCOM console, is clear and readable. However you
might be surprised that after you save the DA, then return to the Distributed Application Designer (DAD) to edit the DA later,
that the exact layout you created is not retained. SCOM will faithfully render a drawing with the correct components connected
to each other. However, by default, where the components appear on the DAD canvas and how the connecting arrows flow
are automatically re-laid out each time the DA is opened.
Even less useful is the default SCOM diagram view of a DA, which as is shown in Figure 7, always renders in a flat horizontal
lineup, even if you have a nested dependency structure in the DA. It is actually necessary to interact with the DA diagram view
by dragging the components around to expose the dependencies (the blue dashed lines) which are the key to problem
identification. SCOM surprisingly does not have a feature to persist diagram view layouts after you have arranged them in their
logical and most meaningful formats.
Figure 7 - SCOM diagram views of DAs do not preserve layout information, components appear in a line.
Finally, it needs to be mentioned that web access to SCOM diagrams occurs via the SCOM Web Console. Like the full SCOM
console, the web console does not persist diagram layouts. Further, the SCOM Web Console requires Microsoft Silverlight
extensions in the client web browser so use of the web console from non-Windows computers is not possible.
4.2 Microsoft native solutions for better diagrams
Recognizing the limitations in the SCOM console and web console to render a consistent, hierarchical topology map, Microsoft
has made available a variety of ways to use Microsoft Office’s Visio with or without Microsoft SharePoint for live network
topology mapping. Using Visio you can solve the problem of not being able to view SCOM diagrammatic information in a
consistent topology format across SCOM users and console sessions.
Here are two links from Microsoft Technet that cover using Visio to create dashboard views and in an integrated SharePoint
model:
Fun With SCOM 2012 Dashboards…SharePoint & Visio Included…
SCOM - Creating a Visio Dashboard and Publishing to SharePoint
These are valid methods to achieve accurate, consistent network topology diagrams (or dashboards). But, there are downsides
to this approach. Specifically, there are financial and license requirements for Visio that can get expensive for a larger
organization—plus the overhead of SharePoint can be burdensome if you are not already a SharePoint shop. Visio is not
bundled in any edition of Microsoft Office so there is always a user-level license cost to integrate Visio with SCOM. Visio
Standard is insufficient--the more expensive editions of Visio Professional or Visio Premium are required to use the SCOM
add-in for Visio. Visio diagrams don’t change dynamically when underlying DAs change. Finally, Visio doesn’t easily support
integrated ‘fly through’ and ‘drill down’ modes for exploring data across multiple diagrams.
Amsterdam - Dallas - Ottawa
www.savision.com
4.3 Savision Live Maps Unity: The premier SCOM dashboard tool
Diagrammatic presentation of network health data is particularly indicated in the hybrid cloud management space.
For illustration in this white paper, the Azure – AWS – Hybrid Application DA seen in Figure 6 was imported into Savision Live
Maps Unity using the Import Distributed Application task on the Start Page of Savision Live Maps Unity for Operations Manager
2012. The resulting Infrastructure Components list in the Live Maps console was changed from a list view using the Convert
to Diagram inline task.
Objects in the DA will appear in the Live Maps authoring space to drop onto a blank diagram canvas. Objects you want to
include in the map, but not listed, are easily added using the Membership Rules tab at the bottom of the canvas. Relationships
are drawn with auto-connecting arrows. Boxes, logos, and labels are easily added to create a live topology diagram with Visio-
like controls. Figure 8 shows the end product running in the Live Maps view of the SCOM Console.
Figure 8 - Hybrid Distributed Application diagram view in Savision Live Maps Unity.
While there are many attractive features in the Savision Live Maps Unity product, this white paper is specifically contrasting
what is possible using built-in and Microsoft tools for rendering SCOM diagram views compared to Live Maps Unity. Observe
the accurate, clear, and readable diagram of the hybrid application and selected internal and external dependencies. Consider
these benefits when using Savision Live Maps Unity for your topology diagraming needs:
Layout of monitored components is static and persists across users, sessions, and consoles. The diagram always
opens to the expected, familiar, and accurate topology view.
Background Images can represent geographic maps, or server racks to add additional intelligence.
Diagram views are available to any client via the Savision Web Console, with no Silverlight extensions required.
No investment in Microsoft Visio or Microsoft SharePoint is required for the full benefit of Live Maps Unity.
When authoring new DAs, using Live Maps Unity is much faster than the Distributed Application Designer.
Amsterdam - Dallas - Ottawa
www.savision.com
Summary System Center Operations Manager (SCOM) is the industry leading solution to monitor hybrid cloud environments. Already
recognized as the premier operating system and application monitoring technology, SCOM can be an economical choice due
to a broad System Center product and license model. Management packs for public cloud fabrics in Microsoft Azure and
Amazon AWS, when imported into SCOM, add cloud datacenter and subscription health to the toolset. Authoring SCOM
Distributed Applications that model hybrid application environments powers a ‘single source of truth’ across clouds. Built-in
SCOM diagram tools are good but lack layout persistence across sessions and a credible web console story. Hosting diagrams
in Visio and SharePoint can fill the gap but add cost and significant complexity. Savision Live Maps Unity is the best topology
diagramming solution for SCOM, and is particularly indicated in hybrid cloud management scenarios.
Amsterdam - Dallas - Ottawa
www.savision.com
About John Joyner
John is Director of Product Development at ClearPointe, a managed services provider of hosted and managed back-end 24x7
Network Operations Center (NOC) services. John is co-author of technical best-seller and industry-standard reference series,
System Center Operations Manager: Unleashed from Sams publishing. His recent focus is helping customers deploy and
manage Microsoft private clouds, architect hybrid clouds, and migrate workloads and virtual machines to public clouds such
as Windows Azure. He is a Microsoft Certified Specialist in Azure Architecture and Azure Infrastructure Implementation. In his
first career as a U.S. Navy computer scientist, John worked for NATO in Europe as Chief of Network Operations and aboard
an aircraft carrier in the Pacific.
About ClearPointe
ClearPointe delivers outsourced NOC services powered by System Center. Since 1998 ClearPointe has managed networks
for companies around the world and is currently active in over 25 countries. ClearPointe built their reputation and expertise
developing 24/7 proprietary NOCs for large companies including ones that service the financial services industry. ClearPointe
took those same proven principles of functionality, reliability and availability and created a responsive, sophisticated Microsoft-
centric NOC, including extensive libraries of protocols, routines and controls. Today, ClearPointe is an international center of
excellence for practical deployment and management of advanced Microsoft technologies.
For more information: http://azure.microsoft.com/en-us/marketplace/partners/clearpointe/clearpointe-maas/
About Savision
Savision is the market leader in Business Service and Cloud Management solutions for Microsoft System Center. The
company’s monitoring and visualizing capabilities bridge the gap between IT and business by transforming IT data into
predictive, actionable and relevant information about the entire cloud and datacenter infrastructure. Savision's intuitive and
customizable dashboards provide context for each business service.
Savision’s solutions scale from small to medium businesses, government bodies as well as Fortune 500 companies operating
in different fields and have been adopted by over 700 organizations worldwide. Founded in 2006, Savision is headquartered
in the Netherlands with offices in Dallas and Ottawa and is privately held.
For more information: https://www.savision.com
