Hybrid Media Clusters

Document created by Cisco Documentation Team on Jan 3, 2017
Version 1Show Document
  • View in full screen mode
 

Hybrid Media Clusters

Hybrid Media Nodes are deployed in clusters. A cluster defines Hybrid Media Nodes with similar attributes, such as network proximity. Cisco Spark participants are directed to use a particular cluster or the cloud, depending on the following conditions:

  •  

    A client on a corporate network that can reach an on-premises cluster will connect to it—the primary preference for clients that are on the corporate network.

      

  •  

    A client that cannot reach an on-premises cluster will connect to the cloud—the case for a mobile device that is not connected to the corporate network.

      

Reachability is determined by the client's ability to "ping" media nodes. A variety of potential connection mechanisms such as UDP and TCP are used during an actual call. Before the call, the Cisco Spark device registers with the Cisco Collaboration Cloud, which provides a list of cluster candidates for the call.

Hybrid Media Cluster Deployment

  •  

    Create fewer clusters when resources have similar network proximity (affinity).

      

  •  

    Clusters located in different time zones can effectively serve multiple geographies by taking advantage of different peak/busy hour calling patterns.

      

Fewer clusters makes sense when the resources are fairly close together. For example: Creating clusters in San Francisco and San Jose, California will likely yield misleading statistics. From a network topology and latency standpoint, the two locations are nearly identical, because of their relatively close geographical proximity. Calls that overflow from either of the two locations to the other will most likely show similar experiences and network behaviors. Calls will likely overflow between the two locations, which is not a problem, but having the two clusters adds more management complexity. In this case, overflows would not involve a degraded or suboptimal experience. As a result, it would be better to create a "Northern California" cluster and name the nodes based on the city in which they are located.

Time-zone diversity can allow clusters to be shared during off-peak times. For example: A company with a Northern California cluster and a New York cluster might find that overall network latency is not that high between the two locations that serve a geographically diverse user population. When resources are at peak usage in the Northern California cluster, the New York cluster is likely to be off peak and have additional capacity and likewise for the Northern California cluster, during peak times in the New York cluster. These aren't the only mechanisms used for effective deployment of resources, but they are probably the two main ones.

When the capacity of all on-premises clusters are reached, an on-premises participant overflows to the Cisco Collaboration Cloud. This does not mean that all calls will be hosted in the cloud. Only those participants that are either remote or can't connect to an on-premises cluster will be directed to the cloud. In a call with both on-premises and cloud participants, the on-premises cluster is bridged (cascaded) to the cloud to combine all participants into a single call.

Spark Device Registers with Cisco Collaboration Cloud

In addition to determining reachability, the clients also perform periodic round-trip delay tests using Simple Traversal of UDP through NAT (STUN). STUN round-trip (SRT) delay is an important factor when selecting potential resources during an actual call. When multiple clusters are deployed, the primary selection criteria are based on the learned SRT delay. Reachability tests are performed in the background, initiated by a number of factors including network changes, and do not introduce delays that would impact call setup times. The following two examples show possible reachability test outcomes.

Round-trip Delay Tests—Cloud Device Fails to Reach On-Premises Cluster

Round-trip Delay Tests—Cloud Device Successfully Reaches On-Premises Cluster

Learned reachability information is provided to the Cisco Collaboration Cloud every time a call is set up. This information allows the cloud to select the best resource (cluster or cloud), depending on the relative location of the client to available clusters and the type of call. If no resources are available in the preferred cluster, additional clusters are tested for availability based on SRT delay. A preferred cluster is chosen with the lowest SRT delay. Calls are served on premises from a secondary cluster when the primary cluster is busy. Local reachable Hybrid Media resources are tried first, in order of lowest SRT delay. When all local resources are exhausted, the participant connects to the cloud.

Cluster definition and location is critical for a deployment that provides the best overall experience for participants. Ideally, a deployment should provide resources where the clients are located. If not enough resources are allocated where the clients make the majority of calls, more internal network bandwidth is consumed to connect users to distant clusters.

On-Premises and Cloud Call

On-premises Spark devices that have the same cluster affinity (preference, based on proximity to the cluster) connect to the same cluster for a call. On-premises Spark devices with different on-premises cluster affinities, connect to different clusters and the clusters then bridged to the cloud to combine the two environments into a single call.

On-Premises Call with Different Cluster Affinities

The Spark device connects to either on-premises cluster or cloud based upon its reachability. The following show examples of the most-common scenarios.

Cisco Spark Cloud Device Connects to Cloud

Cisco Spark On-Premises Device Connects to On-Premises Cluster

Cisco Spark On-Premises Device Connects to Cloud

 

Attachments

    Outcomes