Cisco Validated Design Guide, Cisco WebEx Social Release 3.3
Architecture Overview
Downloads: This chapterpdf (PDF - 1.18MB) The complete bookPDF (PDF - 2.35MB) | Feedback

Architecture Overview

Table Of Contents

Architecture Overview

System Overview

Nodes

Director

Analytics Store

App Server

Cache

Index Store

JSON Store

Message Queue

Notifier

RDBMS Store

Search Store

Worker

Network Troubleshooting Features

Offline Service Performance

Data Inconsistency Tolerance


Architecture Overview


This chapter provides an overview of Cisco WebEx Social and its nodes, and describes high-level network troubleshooting features.

This chapter includes these topics:

System Overview

Nodes

Network Troubleshooting Features

System Overview

Cisco WebEx Social is a collaboration platform that allows you to work in an environment in which you can easily share information such as documents, videos, and presentations, conduct meetings, click-to-dial a contact, post information, join communities, participate in discussion forums, create blogs, and much more.

Cisco WebEx Social integrates with products such as Cisco Unified Communications Manager, Cisco Show and Share, Cisco WebEx Connect, WebEx Meeting Center, Cisco Unity Connection, Cisco Unified IP Phones, WebEx Meeting Center, Content Management Interoperability Services, LDAP directory, and Microsoft Calendar.

Figure 1-1 shows the layered architecture approach that was taken when designing Cisco WebEx Social.

Figure 1-1 WebEx Social High Level Architecture

Cisco WebEx Social supports standards-based open interfaces for extensibility and integration with third-party applications. These features are built on the Cisco WebEx Social application framework, which provides application services that are common across system features. Cisco WebEx Social leverages Cisco networking and computing assets for its deployment infrastructure, and provides security and policy enforcement at various levels.

Figure 1-2 shows the components and high level layout of a Cisco WebEx Social deployment.

Figure 1-2 Cisco WebEx Social Components

Cisco WebEx Social leverages Cisco network services such as security, policies, and medianet at the network level. It also leverages XMPP for IM, presence, and as the basis of its notification infrastructure.

Cisco WebEx Social uses a variety of data stores, both internal and external. Collaboration data is maintained in Oracle and Mongo databases, and the document/media repository is in a Storage Area Network (SAN).

Cisco WebEx Social synchronizes with corporate directories for directory information. Non-local repositories such as Show and Share are accessed through web service interfaces.

A data access and policy layer operates on top of a data aggregation layer, and a variety of collaboration and Unified Communications services are built on top of this infrastructure. At the network level, Cisco WebEx Social leverages Wide Area Application Services (WAAS) for WAN optimization and ACE load balancers for client load balancing and SSL termination.

Nodes

The Cisco WebEx Social user interface has a node-based architecture. This deployment topology is stored centrally. Each node type has identical binaries. Each node connects to the central provisioning server, and then downloads the configuration for its specific role. For more detailed information about WebEx Social nodes, including the number of each node type that can be deployed, see the "Overview of Cisco WebEx Social Nodes" section in Cisco WebEx Administration Guide.

Deploying multiple nodes of a certain type can increase performance, but requires additional resources for the additional virtual machines.

The following sections describe the Cisco WebEx Social nodes:

Director

Analytics Store

App Server

Cache

Index Store

JSON Store

Message Queue

Notifier

RDBMS Store

Search Store

Worker

Director

Each Cisco WebEx Social deployment includes one Director node. This node provides the following:

Central provisioning for all Cisco WebEx Social nodes in the cluster

Monitoring of health and status of all Cisco WebEx Social nodes in the cluster

Storage of configuration settings for other individual nodes and of global system settings and parameters

Central logging and upgrade functionality, including storing logs from all other nodes

Trust store for certifications from integrated applications

The Director uses Yum (a Linux software package manager) for updates within the cluster and Puppet (a configuration management tool) to control the entire cluster.

Figure 1-3 Director

Analytics Store

The Analytics Store is one of the data stores for Cisco WebEx Social. The data is stored in a Mongo database, which is based on the schema-free NoSQL architecture. The schema-free database architecture is designed for large data warehousing, processes a high number of database reads and writes, and is commonly used in modern web architectures.

Figure 1-4 Analytics Store

The Analytics Store provides data analysis functionalities for data triples of the RDBMS Store and the JSON Store. A data triple is based on the Resource Description Framework (RDF), in which the underlying structure of any expression in RDF consists of a subject, a predicate (also called a property), and an object. A data triple states that some relationship, indicated by the predicate, holds between the items its subject and object denote.

A set of data triples is called an RDF graph, and the subjects and objects in an RDF graph are called nodes. Based on its analyses of data relationships, the Analytics Store can provide suggestions to end users. The RDF graph can identify data relations to a level in which, for example, it is possible to differentiate between a person who understands the programming language Java or lives on the island Java. This capability helps end users connect and find a resource in Cisco WebEx Social.

The direction of the links between the nodes in a data triple always points toward the object.

(Subject) ' Predicate ' (Object)
 
   

In the following example data triple, "Jon" is the subject, "Texas" is the object, and "lives" is the predicate:

Jon lives in Texas

App Server

The App Server provides the front-end user interface for Cisco WebEx Social end users. It runs a Tomcat web service for HTTP deliveries, and a Cisco Application Control Engine (ACE) or other load balancer can be used in deployments that require secure access via HTTPS or high availability.

Figure 1-5 App Server

Each App Server can deliver up to 1,500 concurrent user sessions. Configuration and user data is replicated automatically across all App Servers in a deployment. For example, if a user creates a community via one App Server, users who access any other App Server see the community immediately.

Cache

To reduce the amount of database IO operations in a Cisco WebEx Social cluster, a Cache node uses its virtual memory to cache frequently requested data. The caching algorithms use Memcached, an open source memory cache engine, to determine cache and memory handling. Each Cache node connects to the RDBMS Store to request data and updates. When using one or more Cache nodes, App Servers have a higher throughput. There is no limit to the number of Cache nodes in the Cisco WebEx Social cluster that can be paired with an App Server.

Figure 1-6 Cache Node

Index Store

To reduce the need for complex, resource-intensive queries to the RDBMS Store from the Search Store nodes, the Index Store provides an autonomous data store to serve requests for the Search Store nodes.

For example, the Index Store can cache metadata such as author, creation date, and related information for uploaded videos and for the auto-completion feature.

Multiple instances of the Index Store can be deployed for redundancy.

Figure 1-7 Index Store

JSON Store

The JSON Store is a data store that contains metadata for Cisco WebEx Social items such as posts, contact lists, micro blogs, watch lists, activity collections, and so on. The data is stored in a Mongo database, which is based on the schema-free NoSQL architecture.

Several actions that Cisco WebEx Social users perform invoke the JSON Store database. For example, when a user creates a post, the system stores metadata such as creation time, likes, and shares for the post on the JSON Store.

Figure 1-8 JSON Store

Message Queue

The Message Queue node provides a message bus service that is based on Apache ActiveMQ and RabbitMQ for the Cisco WebEx Social cluster.

A message bus is a logical component that provides connection management and handling for applications within a web service cluster. It specializes in transporting messages between applications and contains these key elements:

A set of agreed-upon message schemas

A set of common command messages

A shared infrastructure for sending bus messages to recipients

With a message bus, an application that sends a message does not require individual connections to each application that is intended to receive the message. Instead, the sending application simply passes the message to the message bus, and the message bus transports the message to other applications that are listening for bus messages through a shared infrastructure. Similarly, an application that receives a message does not obtain it directly from the sender. Instead, the receiving application obtains the message from the message bus. In effect, the message bus reduces the fan-out of each application from many to one.

The message bus typically does not preserve message ordering. Internal optimizations, routing, buffering, or the underlying transport mechanism might affect how messages travel to receiving applications. Therefore, the order in which messages reach each receiver is nondeterministic. Preserving the order of messages requires additional logic, which can be provided by the participating applications. For example, the sending application could insert sequence numbers into the outgoing messages, and the receivers could use those numbers to reorder the incoming messages. The logic could also be provided by the bus, and the logic could be transparent for the participating applications.

The Message Queue node enables higher performance for end users through asynchronous database updates. The node connects to NFSv4 to be mounted as a shared file system. Two Message Queue nodes can be deployed for redundancy.

Figure 1-9 Message Queue

Notifier

The XMPP provider in a Cisco WebEx Social cluster runs on the Notifier, and is based on Ignite Realtime Openfire, an Open Source XMPP server. The Notifier node is responsible for notification of end user events, such as system alerts, announcements, and activities, and pushes information to the Notification bar of Cisco WebEx Social. The connection between the App Servers and the Notifier node uses XMPP over TCP. The connection between Cisco WebEx Social users to the App Server and then to the Notifier uses XMPP on Bidirectional-streams Over Synchronous HTTP (BOSH) in Java.

Figure 1-10 Notifier

XMPP is a standard protocol for chat and presence functionalities. It can be extended for generic use in application communications, and several such extensions have been defined and standardized. Cisco WebEx Social uses the XEP-060 extension for publish and subscribe functionalities.

RDBMS Store

The RBMS Store is the central database store of the Cisco WebEx Social cluster.

Figure 1-11 RDBMS Store

This node runs an embedded Oracle Database 11gR2, and provides a data store for the App Server and Notifier nodes. Administrators can access the database for troubleshooting and monitoring by using the Oracle Enterprise Manager, a web-based administrator interface.


Note The required Oracle license for the database instance is included with Cisco WebEx Social.


Search Store

The Search Stores processes search reads and writes for the Cisco WebEx Social cluster.

Figure 1-12 Search Store

The Search Store nodes run Apache Solr, a widely used Open Source search engine. These nodes use a master and slave model, in which one master and at least one slave are configured as a pair. The Search Store master node is the location for indexing of new search elements, and therefore the primary location for writes from the App Servers. Up to 10 App Servers act as slave nodes with write permissions on the Search Store Master. The Search Store Slave nodes synchronize the index from the Search Store Master node and are the primary locations for reads when a user performs a search query in Cisco WebEx Social.

Worker

While App Server nodes process time critical tasks such as synchronizing data between multiple App Server nodes, the Worker node runs in the background and handles offloaded process-intensive, asynchronous activities. For example, the Worker node handles email digest generation, outbound and inbound email processing, report and metric generation, and activity feed processing. The Worker node also processes data migration operations for upgrades of the Cisco WebEx Social cluster.

Figure 1-13 Worker

Network Troubleshooting Features

The following Cisco WebEx Social features can assist you with troubleshooting network issues:

Offline Service Performance

Data Inconsistency Tolerance

Offline Service Performance

Table 1-1 shows which actions can be performed successfully when a particular server or service is offline. With the exception of the RDBMS Store, all function continue to work if a node is down.

You can use this information to quickly determine what service or server to investigate when troubleshooting. For example, if a user tries to create a community and receives an error message that the request was not processed successfully, the table suggests that you start troubleshooting by verifying the proper operations of the RDBMS Store, JSON Store, and Index Store

.

Table 1-1 Store Operations 

Action
RDBMS
Store
JSON
Store
Analytics
Store
Search
Master
Search
Store
Index
Store
NFS
Server

Create Post

Error

Error

Success

Success

Success

Success

Success

View Post

Error

Error

Success

Success

Success

Success

Success

View Watchlist

Error

Error

Success

Success

Success

Success

Success

System Search

Error

Success

Success

Error

Error

Error

Success

Create Community

Error

Error

Success

Success

Success

Error

Success

View Community

Error

Success

Success

Success

Success

Success

Success

Create Attachment

Error

Success

Success

Success

Success

Success

Error


Data Inconsistency Tolerance

Cisco WebEx Social uses a relaxed data model for content that helps ensure tolerance of data inconsistency. Data inconsistency can occur in situations such as the following:

Data backups become corrupt or have varying timestamps.

In geographically-dispersed deployments, data might be replicated to the JSON Store but not yet replicated to the RDBMS Store, or vice versa. The relaxed database model makes the system more highly available in this situation.

In a disaster recovery situation, multiple data stores, such as the JSON Store and the RDBMS Store, may need to be recovered. It is possible that data might not be backed up to all stores, or that a backup of one system might be missing for the day or hour the backup was created. A restore can be successful without a complete backup—you do not have to roll back to the last time a backup was successful for all data stores. In the case of an incomplete backup, a restore omits the missing information instead of generating an error.