This article does not cover capacity planning for the Hybrid Calendar Service Cisco TMS integration with Office 365 or Cisco TMS integration with Google Calendar. Although these integrations use the Cisco Expressway, they currently only support a single node. For capacity information, see the Deployment Guide for Cisco Webex Hybrid Calendar Service.

We provide this article to address your capacity planning questions and explain how we calculate user scale. To model your scenario, try the Hybrid Services capacity calculator.

Planning Considerations

When planning Expressway capacity for your Hybrid Services user population, consider the following questions:

  • Which Hybrid Services do you need?

    The Expressway can host connectors for Hybrid Call Service, Hybrid Calendar Service, and Hybrid Message Service.

  • How many users do you have, for each service?

    The more users you have for each service, the more likely it is that you will want to dedicate Expressway clusters to services. For smaller populations, running multiple connectors on a shared cluster (coresidency) is a valid choice.

  • Are your needs going to change?

    You may want to start small, with one Expressway cluster providing service to a group of early adopters in your organization, and plan growth for a future rollout. You can migrate from a shared model to a dedicated model, or scale your existing cluster, to meet your evolving requirements.

Contributing Factors

We define a cluster’s capacity in terms of the following variables:

  • Node size—Each Expressway virtual machine has a “VM size” that is determined at install time by the resources assigned to the VM. The Expressway installation guides describe those requirements. If you already have an Expressway, you can read the VM size on the Status > System information page of the Expressway interface.

  • Node count—An Expressway cluster may have between one and six nodes. They must be the same node size and run the same version of software.

  • Service continuity strategy—The services use different strategies to ensure continuous service to users. Calendar Service and Message Service use a failover strategy, while Call Service uses a high availability strategy.

    The different strategies are detailed in the Service Continuity Strategies and Scale of Dedicated Clusters table.

  • Coresidency—When the connectors share an Expressway cluster, the resources available to each service are significantly lower as compared with the dedicated cluster.

    There may also be other Expressway-based services on your connector host, like business to business calling (B2B) or Mobile and Remote Access (MRA). In the limited scenarios where this type of coresidency is supported, the scale numbers we document here are constrained to what we have tested. Beyond what is described in this article, the connector host Expressway cluster must not be shared with other services; this is unsupported.

  • Service-specific limitations—For example, we currently limit Calendar Service support to a maximum of one cluster of two nodes per organization.

Calculations for Dedicated Expressway Clusters

We set a hard limit to the number of service users that a dedicated single Expressway can manage (a “cluster of one”), based on evidence that we gather in testing and trials.

Table 1. User Number Limits on Dedicated Single Expressway
Expressway Node Size Hybrid Call Service Scale Hybrid Calendar Service Scale Hybrid Message Service Scale
1. Small 2500 5000 5000
2. Medium 5000 10000 6500
3. Large 5000* 15000 15000

*Assuming 2 devices per user, the resulting capacity translates to no more than 5000 users per Call Connector (or 2500 with 1:1 redundancy).

We use the service continuity algorithms to extrapolate the single node numbers to multiple node clusters, as explained in the following table. If you want the results without the explanation, see:

Table 2. Service Continuity Strategies and Scale of Dedicated Clusters

Compare

Hybrid Call Service

Hybrid Calendar Service

Hybrid Message Service

1. Model

High availability model (HA)

Failover model

Failover model

2. Description

We assign each Call Service user to two different nodes in the cluster. If a node goes down, user assignments on that node are lost but the users are unaffected - they are already assigned to another node.

We assign each user to one node in the cluster. This spreads the users across all nodes.

If a node goes down, we recreate the user assignments from that node on the other nodes.

When the node comes back up, we rebalance user assignments across all active nodes.

We assign each user to one node in the cluster. This spreads the users across all nodes.

If a node goes down, we recreate the user assignments from that node on the other nodes.

When the node comes back up, we rebalance user assignments across all active nodes.

3. Formula

UcallN= N/2 * Ucall1

UcalN= (N-1) * Ucal1

UmsgN= (N-1) * Umsg1

4. Definitions

Where:

UcallN is the cluster of N capacity for Call Service users

N is the node count

Ucall1 is the single node capacity for Call Service users

Where:

UcalN is the cluster of N capacity for Calendar Service users

N is the node count

Ucal1 is the single node capacity for Calendar Service users

Where:

UmsgN is the cluster of N capacity for Message Service users

N is the node count

Umsg1 is the single node capacity for Message Service users

5. Notes

If N=1, there is no HA.

HA is automatic and mandatory if N>1.

If N=2, the capacity is the same as if N=1, with better continuity of service.

Scale benefits from N>=3 or by using a larger node size.

If N=1, there is no failover.

Failover is automatic and mandatory if N>1.

If N=2, the capacity is the same as if N=1, with better continuity of service.

N is currently limited to 2 for Calendar Service.

Scale benefits by using a larger node size.

If N=1, there is no failover.

Failover is automatic and mandatory if N>1.

If N=2, the capacity is the same as if N=1, with better continuity of service.

Scale benefits from N>=3 or by using a larger node size.

Calculations for Shared Expressway Clusters

Our algorithm assumes that coresident connectors proportionately share the resources of a single node. This algorithm conservatively sets the limit for each type of user on the node.

For example, the following table shows the maximum number of users for all the dedicated cases and the coresidency cases on a single, medium Expressway.

Table 3. Scale of One Medium Expressway for Dedicated or Coresidency Scenarios
Expressway Purpose Calendar Service Users Call Service Users

Message Service Users

Dedicated to Calendar Service

10,000

Dedicated to Call Service

5,000

Dedicated to Message Service

6,500

Calendar Service and Call Service

3,400

3,400

Calendar Service and Message Service

4,000

4,000

Call Service and Message Service

2,900

2,900

Calendar, Call, and Message Services

2,300

2,300

2,300

We do not exhaustively list all the coresidency states for all cluster sizes. Instead, you can monitor capacity of your existing Hybrid Services deployment, or use the calculator to plan a new deployment.


The calculator lets you choose connectors, node size, and node count, so you can model your deployment. The remainder of this section explains how it calculates the user numbers from your model.

Just as we did for the dedicated Expressway, we extrapolate the algorithm for shared Expressways to determine user numbers for multiple nodes. The difference from the dedicated cases is that we apply the appropriate service continuity calculation to get the user scale for a particular service on the cluster. We cannot calculate the user scale for the cluster because the cluster hosts competing, user-based, service continuity strategies.

To illustrate that point, if there are two nodes in a cluster hosting both Message Service and Call Service, then Ucal = Ucall because N/2 is 1 and N-1 is also 1. However, if there are three nodes in the cluster, then Ucall is 3/2 * the single node capacity but Umsg is 2 * the single node capacity. See the following table:

Table 4. User Capacity on Clusters of Medium Nodes

Cluster Purpose

Hybrid Call Service Users for 1,2, and 3 nodes

Hybrid Message Service Users for 1,2, and 3 nodes

1. Dedicated to Call Service

5,000

5,000

7,500

2. Dedicated to Message Service

6,500

6,500

13,000

3. Shared by Call Service and Message Service

2,900*

2,900*

4,300

2,900*

2,900*

5,700*

* The numbers shown here, and in the calculator, are rounded up to the nearest hundred. This is consistent with the behavior of the capacity percentage indicators in Control Hub.

Additional Contributing Factors

There may be competing demands on the cluster’s resources that will decrease the user capacity. These are the known examples:

Calendar Service—The connector host may also service O365 users. The numbers and calculations shown here assume that only your on-premises Exchange infrastructure provides the Calendar Service. For more on the ‘hybrid’ Calendar Service, we have some numbers and graphs in the Calendar Service section of this article.

Call Processing—The connector host may also process call signalling and media for Hybrid Call Service. This is effectively a “Business to business” integration between your organization and the Cisco cloud. This reduces the capacity as described in Coresidency with Other Expressway Solutions.

You can use Cisco Webex Control Hub to view a percentage value of the current user capacity of each of your Hybrid Services Expressway resources. A color bar indicates whether the capacity is within acceptable limits. This view lets you evaluate the health of your hybrid service deployments and guides you as to when you need more Expressways.

  • Green—Your Expressways are within acceptable capacity limits. (1%–60%)

  • Amber—You have enough Expressways but you are close to reaching capacity limits. (61%–90%)

  • Red—You don't have enough Expressways and must add more. (91% and up)


    If your Expressways are in a resource group, the capacity indicator appears under a filtered view of the clusters in the resource group.

  • For deployments without resource groups (default):

    1. From the customer view in https://admin.webex.com, go to Services, and then scroll to the hybrid service cards to view the percentage of capacity used on the Expressway resources for each service.

  • For deployments with resource groups:

    1. From the customer view in https://admin.webex.com, go to Services, scroll to the hybrid service cards, and then under Resources click View All.

      The capacity bar only indicates the capacity for clusters outside of resource groups. If all clusters are part of one or more resource groups or the service has no clusters that are configured, the capacity bar is not displayed.

    2. If the capacity value is N/A, choose a resource group from Filter to review resource groups & capacity.

      The value updates to show the percentage of capacity that is used for clusters in that resource group and color-coding to indicate the health.

Things to Keep in Mind

  • The cluster capacity varies depending on the node size, the number of nodes in the Expressway cluster, how many services are running on the cluster, and the high availability or failover strategy. For more information, see the individual Call, Calendar, and Message scale sections.

  • Coresidency reduces the user scale for existing services; the capacity algorithm assumes that every user is using all services.


    We recommend coresidency when you're trying out multiple services, or if you have a small-scale deployment. For services in production, or for large-scale deployments, we recommend that you run the different hybrid services on dedicated Expressway clusters.

What to do next

To add more Expressways for Hybrid Services, use the deployment guide steps for registering connector hosts to the cloud and adding them to existing clusters:

An Expressway cluster's capacity for servicing Hybrid Calendar Service users depends on the size of the constituent Expressway-C nodes, the number of nodes in the Expressway cluster, and the service continuity strategy.

The following table shows the maximum number of users on a single Expressway dedicated to the different Hybrid Calendar Service environments.

Table 5. Hybrid Calendar Service Capacity on One Dedicated Expressway

Calendar Environment

Small Expressway

Medium Expressway

Large Expressway

On-premises Exchange only

5,000 users

10,000 users

15,000 users

Office 365 only*

1,000 users

1,000 users

1,000 users

On-premises Exchange and Office 365* (Hybrid Exchange deployments)

Max of 1,000 Office 365 users out of 5,000 total users

Max of 1,000 Office 365 users out of 10,000 total users

Max of 1,000 Office 365 users out of 15,000 total users

* To avoid this scale limitation, we recommend that you use the cloud-based Calendar Service instead of the on-premises connector. For the Expressway-based Hybrid Calendar Service, the limitation of Office 365 user capacity to 1,000 per cluster is independent of the cluster's node size or count; this limitation derives from interaction with the Microsoft cloud service and not from the scale of the on-premises Expressway deployment.

Figure 1. Hybrid Calendar Service User Capacity by Cluster Type for a Dedicated Cluster.

This diagram shows the maximum user capacity levels as you increase nodes on a dedicated cluster for Hybrid Calendar Service.

Note that the user capacity is the same for a cluster of one node and for a cluster of two nodes. This is because Calendar Service uses failover to improve service continuity. All users are assigned to one node when there are two nodes in the cluster; the other node is a redundant backup. See Planning Expressway Cluster Capacity for Hybrid Services Users for a detailed explanation.

Figure 2. Hybrid Calendar Service On-Premises Exchange and Office 365 User Capacity.

This diagram shows the maximum user capacity levels on a dedicated cluster for Hybrid Calendar Service with both Exchange and Office 365.

An Expressway cluster's capacity for servicing Hybrid Call Service users depends on the size of the constituent Expressway-C nodes, the number of nodes, and the service continuity strategy. The following table shows the maximum number of users on a single Expressway dedicated to Hybrid Call Service.

Table 6. Hybrid Call Service Capacity on One Dedicated Expressway

Small Expressway

Medium Expressway

Large Expressway

2,500 users

5,000 users

5,000 users

This chart shows how the maximum user capacity changes with the number and size of the Expressway nodes in a cluster dedicated to Hybrid Call Service:
Figure 3. Hybrid Call Service User Capacity by Cluster Type for a Dedicated Cluster

Note that the user capacity is the same for a cluster of one node and for a cluster of two nodes. This is because Call Service uses high availability (HA) to improve service continuity, but a single node cluster cannot be highly available. All users are automatically assigned to two nodes when there are two or more nodes in the cluster. See Planning Expressway Cluster Capacity for Hybrid Services Users for a detailed explanation.

An Expressway cluster's capacity for servicing Hybrid Message Service users depends on the size of the constituent Expressway nodes, the number of nodes in the cluster, and the service continuity strategy.

The following table shows the maximum number of users on a single Expressway that is used for the Hybrid Message Service.

Table 7. Hybrid Message Service User Capacity on One Dedicated Expressway

Small Expressway

Medium Expressway

Large Expressway

5,000 users

6,500 users

15,000 users

Figure 4. Hybrid Message Service User Scale on Dedicated Connector Host Clusters. This diagram shows the maximum user scale levels as you increase nodes on a dedicated cluster for Hybrid Message Service

The user numbers are the same for a cluster of one node and for a cluster of two nodes. This is because Message Service uses failover to improve service continuity. Users are distributed evenly across the multiple nodes in the cluster: if one node fails, that node's users are assigned to the other nodes.

Figure 5. Coresidency Example: Hybrid Message Service and Hybrid Call Service User Scale by Cluster Type. This diagram shows the maximum Message Service users and Call Service users per cluster, for different types of clusters hosting both Message and Call Connectors.
Figure 6. Coresidency Example: Hybrid Message Service and Calendar Service User Scale by Cluster Type. This diagram shows the maximum Message Service users and Calendar Service users per cluster, for different types of cluster hosting both Message and Calendar Connectors.

This topic is about sharing a connector host Expressway between the connectors for multiple Hybrid Services, including Calendar Service, Call Service, and Message Service. The connector host is not shared with other Expressway-based solutions such as MRA, B2B, or call traversal for Call Service.

The connector host cluster's capacity depends on the size of the constituent Expressway nodes, the number of nodes, the connectors that are running on the cluster, and the service continuity strategy. See Planning Expressway Cluster Capacity for Hybrid Services Users for a detailed explanation of these factors.

There is also a calculator for you to model different connector host clusters and see how many users of each service your proposed cluster can support.

Example: Connector Host Scale with Three Coresident Connectors

The following table shows an example of scale and coresidency. It gives the maximum number of users per cluster, for each service, with different specifications of the connector host cluster. The cluster is shared between Hybrid Calendar Service (using your on-premises Exchange), Hybrid Call Service, and Hybrid Message Service.

Table 8. Example: Connector Host Scale with Three Coresident Connectors

Service

Two Small Nodes

Two Medium Nodes

Two Large Nodes

Calendar Service users

1,300

2,300

3,000

Call Service users

1,300

2,300

3,000

Message Service users

1,300

2,300

3,000

Different Calendaring Environments on a Calendar Connector Coresident with Call Connector

The table shows the maximum number of users per cluster of Expressway-C connector hosts, when the cluster has one or two nodes. The numbers shown assume that both Hybrid Call Service and Hybrid Calendar Service are active on the cluster. Note that this cluster is not doing call traversal for Hybrid Call Service.

Table 9. Coresident Calendar Service and Call Service Scale (Shared Connector Host Cluster, No Call Traversal)

Service

Small Nodes in Cluster

Medium Nodes in Cluster

Large Nodes in Cluster

Hybrid Calendar Service

On-premises Exchange

1,700 users

3,400 users

6,000 users

Office 365 (On-Premises Connector)*

1,000 users

1,000 users

1,000 users

On-premises Exchange and Office 365 (Hybrid Exchange deployments)

Max of 1,000 Office 365 users out of 1,700 total users

Max of 1,000 Office 365 users out of 3,400 users

Max of 1,000 Office 365 users out of 6,000 users

Hybrid Call Service

1,700 users

3,400 users

5,000 users

* To avoid this scale limitation, we recommend that you use the cloud-based Calendar Service instead of the on-premises connector. For the Expressway-based Hybrid Calendar Service, the limitation of Office 365 user capacity to 1000 per cluster is independent of the cluster's node size or count; this limitation derives from interaction with the Microsoft cloud service and not from the scale of the on-premises Expressway deployment.

Introduction

This topic is about sharing a connector host Expressway with other Expressway-based solutions. When you choose to host connectors on an Expressway that you are using for other purposes, the following important caveats apply:

  • We cannot support the scalability model that applies to a dedicated connector host Expressway. The user numbers that you derive from reading the other topics in this article, or using the calculator, do not apply when the connector host is shared with other Expressway services.

  • The combinations of Expressway-based services and hybrid services connectors described in this article, and the associated user numbers, are the only supported scenarios. We have not tested other scenarios, and you cannot expect them to work in your environment.

Expressway-based Calendar Service with Call Connector and Call Service Traversal

In this scenario, a two node Expressway cluster is hosting Hybrid Call Service and Hybrid Calendar Service connectors. The cluster is also doing the call traversal for Hybrid Call Service (SIP signaling and media).

The table shows the different calendar environments that you can use with the Expressway-based connector. The Expressway-based Calendar connector is not supported on clusters with more than two nodes. Use the cloud-based connector for greater scale with Office 365 (see Calendar Service Scale).

Table 10. User Scale for Coresident Call Service and Calendar Service, with Call Traversal

Service

Two Small Node Cluster

Two Medium Node Cluster

Two Large Node Cluster

Calendar Service

On-premises Exchange

500 users

1,000 users

1,000 users

Office 365

500 users

1,000 users

1,000 users

On-premises Exchange and Office 365 (Hybrid Exchange deployments)

Max 500 users for both

Max 1,000 users for both

Max 1,000 users for both

Call Service

250 users

500 users (redundant/single failure)*, including 100 MRA users

1,000 users

2,000 users (redundant/single failure)*

2,500 users

5,000 users (redundant/single failure)*

Call Traversal

200 audio sessions

100 video sessions

200 audio sessions

100 video sessions

1,000 audio sessions

500 video sessions

† To avoid this scale limitation, we recommend that you use the cloud-based Calendar Service instead of the on-premises connector. For the Expressway-based Hybrid Calendar Service, the limitation of Office 365 user capacity to 1,000 per cluster is independent of the cluster's node size or count; this limitation derives from interaction with the Microsoft cloud service and not from the scale of the on-premises Expressway deployment.

* In the case of a normally redundant deployment with two Expressways, if one Expressway fails, the other can temporarily handle both sets of users for all services until redundancy is recovered.

Calendar and Call Service with Mobile and Remote Access

In this scenario, an MRA cluster of one or two small Expressway VMs is hosting the Calendar Connector and Call Connector. This scenario assumes the cluster is only used for MRA and the two connectors. The cluster is limited to one or two small nodes.

Table 11. Call and Calendar Connector Scale on small MRA Expressway-C

Expressway Purpose

Cluster of One Small Expressway-C

Cluster of Two Small Expressway-Cs

Calendar Service users (On-premises connector to Exchange)

500 users

500 users

Call Service users

500 users

500 users

Mobile and Remote Access users

100

100