Home > Articles > Intercloud Architecture and Technologies

Intercloud Architecture and Technologies

  • Sample Chapter is provided courtesy of Cisco Press.
  • Date: Sep 26, 2016.

Chapter Description

In this sample chapter from Intercloud: Solving Interoperability and Communication in a Cloud of Clouds, authors Jazib Frahim, Venkata Josyula, Monique Morrow, and Ken Owens explore how cloud providers have set up data centers at many locations to service their customers. For example, Amazon, Google, Microsoft, Salesforce.com, and others have established data centers for hosting cloud application services such as social networking, gaming portals, and business applications. In many of these social networks, the service components run in separate virtual machines that may be hosted in data centers owned by different cloud computing providers. In order to link the services provided by different providers at different locations around the world and to provide quality service to a consumer, it is necessary to build an Intercloud to bring the services together. This chapter details Intercloud architecture mode, Intercloud use cases, and Intercloud deploy.

Cloud Operational Support Systems (OSS)

The OSS consist of the following management aspects:

  • Change management means managing break/fix and new features to the system following the change process and change windows.

  • Configuration management means managing the configuration.

  • Capacity management means managing the capacity needs of the physical infrastructure.

  • Performance management means managing the expected performance of the systems involved in delivering the service.

  • SLA management means managing the SLA thresholds set by configuration and performance management.

  • Incident management means managing incidents as they occur, documenting results, and creating tickets.

  • Problem management means managing incidents that happen frequently or cause major downtime.

  • Service desk is the name for the support staff available to provide assistance.

  • Log and event management means managing all the logs and events from the data sources.

  • Reporting and analytics means analyzing the events, logs, and data generated by the services to look for incidents or problems and to enhance the performance of the system.

  • Service delivery means working alongside the business to deliver the service required.

  • Image/lifecycle management means managing software images and patching these images.

  • Asset and license management means managing the assets and licenses of the underlying hardware and software.

In the Intercloud, Cisco provides all these elements of OSS as a service. For partners and enterprises that already have OSS capabilities in place, Cisco provides an API into the Intercloud OSS for consumption by the partner/enterprise OSS systems.


OpenStack has a project for monitoring called Ceilometer. Ceilometer has for several cycles failed to accomplish the performance and scaling that several OpenStack projects require. Ceilometer value can be divided into two major components:

  1. OpenStack data collection through notifications (events) and polling

  2. Metering API


Monasca is the de facto OpenStack project for monitoring. It is not an OpenStack project yet but is targeted to become one at the Liberty release of OpenStack. Monasca strengths are quite complementary to Ceilometer since it has a very solid and scalable storage architecture as well as inline alarming, and it will soon be integrated with Heat, providing a superior solution to Ceilometer for autoscaling. Monasca, though, does not have a full suite of agents and currently does not integrate with events from OpenStack (there is a plan to leverage StackTach V3).

The Intercloud requires a new standard for OSS called Ceilosca, which is a combination of Monasca and Ceilometer. Monasca is really seen as a storage driver for Ceilometer, and its value is in its scalability. Ideally Monasca should be considered a “black-box” component of Ceilometer. Ceilometer will push meters and lately events to the Monasca API. Monasca will store them and provide them back through the same API. Ceilometer will consume meters and samples from the Monasca API and convert them back in the Ceilometer format to be served through the Ceilometer API as shown in Figure 2-10.

Figure 2-10

Figure 2-10 Cisco Intercloud Monasca API with OpenStack

The system now presents two APIs that can be used to POST or GET data, and they can be interchangeably used to store and retrieve monitoring and metering data. This not only allows Cisco to store all the data in a single scalable data storage unit but allows other parties to communicate leveraging standard and open APIs.

Intercloud Monitoring

Tenant resources that are in the Cisco and/or partners’ Intercloud need to be monitored across clouds, regions, and data centers. The monitoring agents in the partner clouds can POST the relevant subset of the monitoring data to Cisco clouds for the tenants that have instances running on those clouds as well as POST metrics to their internal monitoring system. Similarly, they can consume monitoring data from Cisco clouds if needed for their monitoring solution. Figure 2-11 displays the relationships for Intercloud monitoring.

Figure 2-11

Figure 2-11 Intercloud Monitoring

Intercloud Metering

Similarly to the monitoring solution, Intercloud partners can POST samples to the Ceilometer API (and potentially the Monasca API) and collect the metering data and samples. Partners can use data collected from Cisco clouds to provide an overall view of resource usage to tenants belonging to partner clouds as well as perform show-back/charge-back operations, as can be seen in Figure 2-12.

Figure 2-12

Figure 2-12 Intercloud Metering

6. Cloud Back-Office Support Systems (BSS) | Next Section Previous Section

There are currently no related articles. Please check back later.