Cisco HCS capacity planning

(1)

Cisco HCS capacity planning

• Introduction, page 1

• Network Infrastructure capacity planning, page 1

• Unified Communications Application capacity planning, page 10

Introduction

This document provides capacity planning guidelines for the following Cisco HCS deployment models: • Full Cisco HCS offering or Large PoD

• Small PoD • Micro Node

For a description of these Cisco HCS offerings, refer to the Solution Reference Network Design for Cisco Hosted Collaboration Solution.

Network Infrastructure capacity planning

Network infrastructure metrics are very important during network integration through a fresh install or when growth occurs in the network that requires software or hardware upgrades. Network infrastructure metrics are listed inCapacity and performance monitoring.

Depending on the topology of the network deployed, the overall system capacity in terms of supported subscribers and customers can vary. It is important to regularly track the network infrastructure metrics described in the previous section to manage potential growth as Cisco HCS expands.

Network Infrastructure is key in the capacity-planning process. The information contained in this section serves as reference material to help you plan for present and future capacity requirements on the Cisco HCS Data Center.

(2)

Cisco HCS resource limits

As a part of the capacity planning process, you need to be aware of the number of tenants that the components support and take into account the future growth plans.

The table shows fixed software limits that are placed on individual network components that can be deployed within a given Cisco HCS architecture. Based on the resource-usage profile variations, the overall number of supported tenants for each deployment can differ. The usage profiles are listed inTable 3: Standard resource usage profile, on page 3andTable 4: BGP optimization resource usage profile, on page 4.

The data presented in this table is specifically for a Cisco HCS implementation and may not be the scalability or resource limits published in the Nexus documentation.

Note

Table 1: HCS resource limits

Nexus 5000 Nexus 7000 Resource 256 1,000 BGP peers 100 1,000 VRFs 256 1,000 HSRP instances 250 1,000 Static routes 1,000 2,000 VLANs

Cisco HCS resource reservation

You need to have an accurate representation of how resources are potentially used. From a capacity-planning perspective, routing resources can be used on a fixed or tenant basis. The table lists the number of fixed resources that should be reserved and subtracted from the resources shown inTable 1: HCS resource limits, on page 2. The remaining resources can be used on a per-tenant basis and ultimately determine the supported number of tenants for the architecture used.

The resource reservation is for planning purposes. It is important to know the actual count for each individual deployment. The numbers may vary.

Note

Table 2: Fixed resource reservation

Count Reserved Resource

20 BGP peers

Cisco HCS capacity planning Cisco HCS resource limits

(3)

Count Reserved Resource 10 VRFs 40 HSRP instances 50 Static routes 100 VLANs

Resource usage profiles (per-tenant basis)

Usage profiles on a per-tenant basis are divided into aggregation and core usage. Each interface has different requirements depending on the configuration used. The usage profile is different if you use BGP optimization. BGP optimization refers to how the BGP connections are provisioned between the PE and core routing. When BGP optimization is used, the cross links between PE and core routing are removed. This provides a reduction in BGP peer usage on a per tenant basis.

BGP optimization reduces the amount of links (cross-links) required on the core layer. In cases where the limiting factor is the number of BGP peers, the optimization can be beneficial.

Table 3: Standard resource usage profile

Usage at Aggregation Usage at Core VRF HSRP VLANs Static routes BGP VRF HSRP VLANs Static routes BGP Configuration 2 2 2 4 3 1 1 1 1 5

Large PoD with aggregation and core routing (pre-HCS 9.2.1) 2 2 2 4 4 1 1 1 1 5

Large PoD with aggregation and core routing + RA VPN (pre- HCS 9.2.1) 2 2 2 4 3 — — — — —

Small PoD (no core routing) 2 2 2 4 4 — — — — —

Small PoD (no core routing) + RA VPN 2 2 2 4 3 — — — — — Micro Node

Cisco HCS capacity planning

(4)

Table 4: BGP optimization resource usage profile Usage at Aggregation Usage at Core VRF HSRP VLANs Static routes BGP VRF HSRP VLANs Static routes BGP Configuration 2 2 2 4 3 1 1 1 1 4

Large PoD with aggregation and core routing (pre-HCS 9.2.1) 2 2 2 4 3 1 1 1 1 4

Large PoD with aggregation and core routing + RA VPN (pre- HCS 9.2.1) 2 2 2 4 2 — — — — —

Small PoD (no core routing) 2 2 2 4 3 — — — — —

Small PoD (no core routing) + RA VPN 2 2 2 4 2 — — — — — Micro Node

Cisco HCS capacity planning Cisco HCS resource reservation

(5)

Architecture capacity planning

This section provides the architecture outlines that are referenced in the tables that follow.

Figure 1: Reference 1: Small and Large PoD with Core and Aggregation

The Nexus 7xxx applies to the Large PoD. the Small PoD uses the Nexus 5000.

Note

In 9.2(1), the core has been removed. The graphics that show the core refer to existing pre-HCS 9.2(1) deployments.

Note

The components for the architecture illustrated on the figure are the following: • Access devices (optional): Nexus 5000

• Aggregation devices: Nexus 7XXX for the Large PoD, and Nexus 5000 for the Small PoD • Core devices: Nexus 7XXX for the Large PoD, and Nexus 5000 for the Small PoD

(6)

• Firewall: ASA 55xx • RA–VPN: ASR 100x • Nexus 1000V

• Fabric interconnect: 62xx

• UCS chassis + fabric extender: 5108 + 2048 • UCS blades: B-series

• Storage

Figure 2: Reference 2: Small and Large PoD with Core and Aggregation (with BGP optimization)

The Nexus 7xxx applies to the Large PoD. the Small PoD uses the Nexus 5000.

Note

• Aggregation devices: Nexus 7XXX for the Large PoD, and Nexus 5000 for the Small PoD

Cisco HCS capacity planning Architecture capacity planning

(7)

• Core devices: Nexus 7XXX for the Large PoD, and Nexus 5000 for the Small PoD • Firewall: ASA 55xx

• RA–VPN: ASR 100x • Nexus 1000V

• Storage

Figure 3: Reference 3: Small and Large PoD without Core

• Aggregation devices: Nexus 7XXX for the Large PoD, and Nexus 5000 for the Small PoD • Firewall: ASA 55xx

(8)

• RA–VPN: ASR 100x • Nexus 1000V

• Storage

Figure 4: Reference 4: Micro Node

Micro Node is a low-cost option for deployments of 20,000 subscribers or less. Micro Node is suited for deployments with a capacity equal to or less than 20 customers.

The following components correspond to the architecture illustrated in the figure: • Integrated computing and storage (ICS) and virtual access

◦UCS C220 M3 Series - UC on UCS TRC #2 ◦Direct attached storage (DAS)

◦VMware Standard • Aggregation plus access

◦Nexus 5548

Cisco HCS capacity planning Architecture capacity planning

(9)

• Services

◦ASA 1002-X

◦CUBE-Enterprise per tenant • WAN/edge

◦ASR 1002-X IPSec/VPN • Firewall

◦ASA 5555-X

Architectural capacity guide for standard Cisco HCS deployment

The following table provides a capacity guide for the standard Cisco HCS deployment. The resource in brackets on the last column is the resource that gets exhausted first.

The entries in the Reference architecture column on the table refer to their corresponding architecture figures in the sectionArchitecture capacity planning, on page 5.

Table 5: Architectural capacity guide for standard Cisco HCS deployment

Capacity (Tenant limit) Reference architecture BGP peer optimization Remote access Core Aggregation Nexus 7000 Nexus 5000 Nexus 7000 Nexus 5000 Configuration 20 Reference 4 — — — — — X Micro Node 45 (VRF) Reference 3 — — — — — X Small PoD 237 (static) Reference 3 — — — — X — Large PoD 45 (VRF) Reference 3 — X — — — X Small PoD 237 (static) Reference 3 — X — — X — Large PoD 45 (VRF) Reference 3 X — — — — X Small PoD 237 (static) Reference 3 X — — — X — Large PoD 45 (VRF) Reference 3 X X — — — X Small PoD 237 (static) Reference 3 X X — — X — Large PoD 237 (static) Reference 1 — — — — X — Large PoD 196 (BGP) Reference 1 — — X — X — Large PoD

(10)

Capacity (Tenant limit) Reference architecture BGP peer optimization Remote access Core Aggregation Nexus 7000 Nexus 5000 Nexus 7000 Nexus 5000 Configuration 196 (BGP) Reference 1 — X — — X — Large PoD 196 (BGP) Reference 1 — X X — X — Large PoD 237 (static) Reference 2 X — — — X — Large PoD 237 (static) Reference 2 X — X — X — Large PoD 237 (static) Reference 2 X X — — X — Large PoD 237 (static) Reference 2 X X X — X — Large PoD

Unified Communications Application capacity planning

Cisco Unified Communications applications are provisioned and resources are allocated on a customer-size basis with an OVA file. There are various sizes of OVA files available, and selection is based on the number of subscribers expected by a customer deployment. Unified Communications application utilization is expected to be the highest during the busy hour. Depending on the Unified Communications application, you might experience peak loading during different times of the day. For example, peaks in CPU usage can be experienced during backup and restore activities. Management applications might experience peak loading during maintenance windows while call processing applications experience peak loading during times of the highest-call volume.

For details on OVA information, including OVA sizing, refer to the Compatibility Matrix for Cisco Hosted Collaboration Solution.

For planning information, refer to the Cisco Hosted Collaboration Solution End-To-End Planning Guide.

SAN engineering

It is important that you collect SAN metrics to provide usage snapshots. The SAN should be engineered to handle the amount of IOPS and disk space required by the Cisco HCS system over a 24-hour period. There are many SAN vendors on the market that can scale as a Cisco HCS system grows in size. vBlock with EMC and FLEX PoD with NetApp provide SAN capability that scales to meet Cisco HCS capacity demands. Usage patterns vary based on the mix of Unified Communications applications under normal operating conditions and times of the day when backup and restore activities might occur. Depending on the number of backup and restores placed on the system, you could expect to see the highest IOPS experienced in a 24-hour period, that is, the maintenance window might be the time of day when SAN usage is highest. The SAN should be engineered to handle the peak loads that can occur over a 24-hour period. Monitoring the SAN utilization in terms of IOPS and disk utilization is important. You can monitor IOPS loading based on the sum of IOPS loading that each application type generates on Cisco HCS. After you monitor IOPS and disk space utilization on an application-type basis, you can make future IOPS projections for growth planning. You must map the

Cisco HCS capacity planning Unified Communications Application capacity planning

(11)

utilization that was experienced against the capacity specification of the purchased SAN to compare when a SAN upgrade is necessary.

Backup and restore

A service provider must take great care with backup and restore activities because there are engineering rules associated with these activities. For full details on backup and restore activities for the HCS solution, refer to Backup and Restore Guide for Cisco Hosted Collaboration Solution athttp://www.cisco.com/en/US/partner/ products/ps11363/prod_maintenance_guides_list.html.

With backup and restore activities for capacity planning, we recommend that at any given time no more than two UC application backups occur on each UCS server blade. Following this recommendation mitigates the potential for high CPU usage on a specific server blade and the elevation of IOPS on the SAN causing a RAID group/LUN performance to be degraded. It is crucial that you take this recommendation into account when configuring Platform Manager.

A service provider should have a mapping of applications provisioned on the HCS system with the

corresponding SAN RAID group and LUN location. This mapping should help identify high IOPS risk areas and allow for IOPS load balancing across the system during backup and restore activities.

You can use the Platform Manager to assist with these activities, by scripting a flow of activities.

In Micro Node data center environments, there is no SAN storage. Cisco recommends that you dedicate one or more C-series servers to the host FTP servers, using local storage for backup. Do not back up anything to the same C-series server or disk where the applications and components reside. Multiple applications for multiple customers can be backed up to the same FTP server. For more details, refer to Backup and Restore Guide for Cisco Hosted Collaboration Solution athttp://www.cisco.com/en/US/ partner/products/ps11363/prod_maintenance_guides_list.html.

Note

(12)

Cisco HCS capacity planning Backup and restore