Cisco HCS capacity planning

Transcription

1 Introduction, page Network Infrastructure capacity planning, page Unified Communications Application capacity planning, page 0 Introduction This document provides capacity planning guidelines for the following Cisco HCS deployment models: Full Cisco HCS offering or 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 in Capacity 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. Capacity Planning Guide for Cisco Hosted Collaboration Solution 9.()SU OL

2 Cisco HCS resource limits 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 in Table 3: Standard resource usage profile, on page 3 and Table : BGP optimization resource usage profile, on page. Note 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 documentation. Table : HCS resource limits Resource BGP peers VRFs HSRP instances Static routes VLANs 7000,000,000,000,000, ,000 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 in Table : HCS resource limits, on page. The remaining resources can be used on a per-tenant basis and ultimately determine the supported number of tenants for the architecture used. Note The resource reservation is for planning purposes. It is important to know the actual count for each individual deployment. The numbers may vary. Table : Fixed resource reservation Reserved Resource BGP peers Count 0 Capacity Planning Guide for Cisco Hosted Collaboration Solution 9.()SU OL

3 Cisco HCS resource reservation Reserved Resource VRFs HSRP instances Static routes VLANs Count Table 3: Standard resource usage profile 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. Usage at Core Usage at Aggregation Configuration BGP Static routes VLANs HSRP VRF BGP Static routes VLANs HSRP VRF with aggregation and core routing (pre-hcs 9..) 5 3 with aggregation and core routing + RA VPN (pre- HCS 9..) 5 Small PoD (no core routing) 3 Small PoD (no core routing) + RA VPN Micro Node 3 Capacity Planning Guide for Cisco Hosted Collaboration Solution 9.()SU OL

4 Cisco HCS resource reservation Table : BGP optimization resource usage profile Usage at Core Usage at Aggregation Configuration BGP Static routes VLANs HSRP VRF BGP Static routes VLANs HSRP VRF with aggregation and core routing (pre- HCS 9..) 3 with aggregation and core routing + RA VPN (pre- HCS 9..) 3 Small PoD (no core routing) Small PoD (no core routing) + RA VPN 3 Micro Node Capacity Planning Guide for Cisco Hosted Collaboration Solution 9.()SU OL

5 Architecture capacity planning Architecture capacity planning This section provides the architecture outlines that are referenced in the tables that follow. Figure : Reference : Small and with Core and Aggregation Note The 7xxx applies to the. the Small PoD uses the Note In 9.(), the core has been removed. The graphics that show the core refer to existing pre-hcs 9.() deployments. The components for the architecture illustrated on the figure are the following: Access devices (optional): 5000 Aggregation devices: 7 for the, and 5000 for the Small PoD Core devices: 7 for the, and 5000 for the Small PoD Capacity Planning Guide for Cisco Hosted Collaboration Solution 9.()SU OL

6 Architecture capacity planning Firewall: ASA 55xx RA VPN: ASR 00x 000V Fabric interconnect: 6xx UCS chassis + fabric extender: UCS blades: B-series Storage Figure : Reference : Small and with Core and Aggregation (with BGP optimization) Note The 7xxx applies to the. the Small PoD uses the The components for the architecture illustrated on the figure are the following: Access devices (optional): 5000 Aggregation devices: 7 for the, and 5000 for the Small PoD Capacity Planning Guide for Cisco Hosted Collaboration Solution 9.()SU 6 OL

7 Architecture capacity planning Core devices: 7 for the, and 5000 for the Small PoD Firewall: ASA 55xx RA VPN: ASR 00x 000V Fabric interconnect: 6xx UCS chassis + fabric extender: UCS blades: B-series Storage Figure 3: : Small and without Core The components for the architecture illustrated on the figure are the following: Access devices (optional): 5000 Aggregation devices: 7 for the, and 5000 for the Small PoD Firewall: ASA 55xx Capacity Planning Guide for Cisco Hosted Collaboration Solution 9.()SU OL

8 Architecture capacity planning RA VPN: ASR 00x 000V Fabric interconnect: 6xx UCS chassis + fabric extender: UCS blades: B-series Storage Figure : Reference : Micro Node Micro Node is a low-cost option for deployments of 0,000 subscribers or less. Micro Node is suited for deployments with a capacity equal to or less than 0 customers. The following components correspond to the architecture illustrated in the figure: Integrated computing and storage (ICS) and virtual access UCS C0 M3 Series - UC on UCS TRC # Direct attached storage (DAS) VMware Standard Aggregation plus access 558 Capacity Planning Guide for Cisco Hosted Collaboration Solution 9.()SU 8 OL

9 Architecture capacity planning Services ASA 00- CUBE-Enterprise per tenant WAN/edge ASR 00- IPSec/VPN Firewall ASA 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 section Architecture capacity planning, on page 5. Table 5: Architectural capacity guide for standard Cisco HCS deployment Configuration Aggregation Core 7000 Remote access BGP peer optimization Reference architecture Capacity (Tenant limit) Micro Node Reference 0 Small PoD 5 (VRF) 37 (static) Small PoD 5 (VRF) 37 (static) Small PoD 5 (VRF) 37 (static) Small PoD 5 (VRF) 37 (static) Reference 37 (static) Reference 96 (BGP) Capacity Planning Guide for Cisco Hosted Collaboration Solution 9.()SU OL

10 Unified Communications Application capacity planning Configuration Aggregation Core 7000 Remote access BGP peer optimization Reference architecture Capacity (Tenant limit) Reference 96 (BGP) Reference 96 (BGP) Reference 37 (static) Reference 37 (static) Reference 37 (static) Reference 37 (static) Unified Communications Application capacity planning SAN engineering 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. 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 -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 FLE 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 -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 -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 Capacity Planning Guide for Cisco Hosted Collaboration Solution 9.()SU 0 OL

11 Backup and restore 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 at products/ps363/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. Note 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 at partner/products/ps363/prod_maintenance_guides_list.html. Capacity Planning Guide for Cisco Hosted Collaboration Solution 9.()SU OL

12 Backup and restore Capacity Planning Guide for Cisco Hosted Collaboration Solution 9.()SU OL