Comparing Three Solutions

Transcription

1 Melissa Swartz, Swartz Consulting Elizabeth English, EE and Associates Comparing Three Solutions Case studies of live sample projects May or may not have been implemented with most redundant configurations ShoreTel Premises Avaya Premises Cisco Hosted Interactive discussion of strengths and weaknesses of each design. (based on design as implemented, not manufacturer issues) 1

2 Case Study 1 ShoreTel Premises Case Study 1 Description Two Data Centers: Data Center and Head Quarters 250 Remote sites (most small) SIP trunks into both data center and HQ (distributed load) Primary and backup Servers all in Data Center (Director and DVS) MPLS and SIP on shared Ethernet from Sprint 2

3 Case Study 1 Strengths Dual SIP connectivity SIP failover from the carrier if connection fails, calls are routed by Sprint to predetermined numbers Redundant SBCs in both Data Center and HQ (2 each) Redundant servers Site switches will maintain calls if connectivity to servers is lost Case Study 1 Design Improvements Separate MPLS and SIP on different Ethernet circuits/carriers Separate redundant Directors geographically (different buildings, different parts of the country) Add 3 rd party software to automatically failover to second Director (Double Take) Separate DVS between DC and HQ and/or add to some sites ShoreTel fails up Cross connect DVS at DC to HQ Director, DVS at HQ to DC director Add backup power to servers, gateways, and switches at DC and HQ N+1 Shoregear switches at Data Center and HQ. N+1 switches at critical sites 3

4 ShoreTel Failover Architecture At least one server is always required in a ShoreTel deployment and is referred to as the Headquarters (HQ), or root, server. Additional servers can be added for better fault tolerance, redundancy and survivability. Whether referred to as Distributed Voice Mail servers (DVMs) or, more recently, Remote Application Servers, these additional servers rely on the HQ server to receive configuration changes but, otherwise, can run entirely independent from the HQ server for extended periods of time. An additional server can be added to a remote site to keep local Auto Attendant (AA) and Voice Mail (VM) traffic off the WAN and to provide survivable AA & VM access even when connectivity to the Headquarters site/server has been lost. An additional server can be added to the Headquarters site to enable failover & redundancy in case the HQ server is taken off line for maintenance or upgrades. All the servers communicate with each other and work together to "back each other up" in case one server is unreachable. ShoreGear Switches: Selection of Primary and Secondary Servers Each ShoreGear switch, starting with full knowledge of all ShoreTel servers in it's own site and all sites above it, will select a primary server and a backup, or secondary, server. When a ShoreGear switch needs any server based service (such as an Auto Attendant prompt or a Voice Mail box) the switch will first try to connect to its primary server and, if that server is unreachable, will connect to it's secondary server. The selection of primary and secondary servers is done dynamically by the switches and is done by each switch individually and from its unique position and perspective of the ShoreTel site hierarchical tree. If there are two (or more) ShoreTel servers at a site, then the ShoreGear switches at that site will always select those local servers for their primary and secondary servers. In fact, different switches will select different servers for their primary and secondary to effectively load balance across all servers at a site. If there is only one server at a site, then that server will always be selected as the primary server for each switch at that site. The switches then select the next "nearest" server by looking up the ShoreTel site hierarchical tree. This hunting will continue up the tree until each switch has selected both its primary and secondary server or it reaches the HQ site and has run out of servers to choose from. In practice, with most simple, hierarchical tree structures, this often will mean that each switch will use it's local DVM server as it's primary server and the HQ server as its secondary server. Note: When a switch is selecting it's primary and secondary servers it will always hunt up the site tree (towards parent sites and the root/hq site) and will never hunt to the side or down the tree (to a sibling site or a child site). Distributed Server Services Many of the ShoreTel server based services are fully distributed, such as all AA prompts and the recorded names of all users. When one of these services is needed by a ShoreGear switch it will connect, as always, to its primary server and that server will be able to service the request locally. But some server based services are performed only by one, single server, such as the storage of each individual users Voice Mail messages and greetings. When a ShoreGear switch needs, for example, to route a caller to leave a voice mail message for a particular user the switch will connect to it's primary server and that server will then redirect the call to the appropriate server that hosts the specified user's voice mail box. Since Servers fail from "child" to "parent" you may consider the HQ server at the DR site and DVM's as your main voice mail servers. Case Study 2 Avaya Premises 4

5 Case Study 2 Description Headquarters site with 2 remote sites Each remote has survivable gateways connected via MPLS Dual CPUs in headquarters system Separate DR site with Single Server ESS, Session Manager and Gateway Customer network infrastructure does not support VoIP (no POE network switches) Digital phones, PRIs at HQ site, POTS at remotes Case Study 2 Strengths Dual CPUs at HQ + Survivable gateways + Backup DR site Trunking at each location MPLS failure would not take down any single site Disaster routing service on toll free numbers allows re routing to pre assigned alternate numbers Survivable ESS will take over automatically in case of main system CPU failure 5

6 Case Study 2 Design Improvements 2 Local and 2 LD PRIs at HQ do not provide flexibility afforded by SIP trunking for redundancy, re routing and backup No redundant MPLS Backup data center is only 12 miles from HQ; probably far enough away to avoid losing both to a tornado but other widespread outage (power, prolonged ice storm) could impact both sites Case Study 3 Cisco Hosted 6

7 Case Study 3 Description Dual Hosted Data Centers 50 locations, some large, most medium, few small SIP provided by Level 3 MPLS provided by AT&T Remote Sites with DMVPN and SRST Case Study 3 Strengths Active Active redundant CUCM servers Redundant MPLS connectivity Redundant SIP DMVPN at each site (via internet [Cox, Comcast, T1 etc] SRST at each site Backup internet connected to client network router, rather than provider managed SRST router 7

8 Case Study 3 Design Improvements Use Data Centers in different Geographic area (time zone) Consider E911 centralized solution. Periodic test of 911 from each site. POTs line issues and subnet issues. (remote site POTS lines always at risk for local interference ) Consider LTE for backup circuit as opposed DSL or Cable internet Validation of core infrastructure at sites prior to conversion Things to consider LTE versus landline for backup network connection What state is maintained during failover? In survivable mode at the edge, which features are maintained without subscriber connection? Which ones are critical? Consider network failover alternatives, not just manufacturer alternatives Different kinds of SIP failover 8

9 Melissa Swartz Elizabeth English 9