Redundancy for Good Reason

By Inflow Communications

When it comes to disaster recovery, we can’t emphasize it enough – diversify, diversify, diversify. It’s not unlike a stock portfolio – diversifying your redundancies will help mitigate the damage should something go down. We went over this recently in one of our ShoreTel webinars, Virtualization and Disaster Recovery. It’s simple to say having as many redundancies as possible is key when it comes to disaster recover but, we thought showing an example of such a design, what happens with different types of outage scenarios and how to build in redundancies to account for outages would be the best way to explain why redundancy works.

To start, here is an example of a design, which has multiple redundancies – specifically, seven.

1. By installing a DVS at HQ all VM boxes, Auto Attendant, Desktop client and workgroups can be offloaded from the HQ server, allows us to have redundancy if the HQ server needs to be rebooted or has an issue.

2. A DVS in San Jose allows the local site to have Auto attendant, VM, Workgroup and desktop client controlled locally which minimizes WAN traffic and adding local survivability.

3. Installing ShoreGear IP switches at each site allows all local phones to register, reducing the amount of traffic that has to use the WAN connection.

4. Spare switches allow IP phones to re-register to spare switch if the IP switch they are assigned to goes down. This allows us time to resolve any issues without having all the phones on the affected switch down. Spare switches can be at each site or centralized at the HQ location.

5. By having local dial tone at each site, we are able to reduce dependency on the HQ site and WAN by having local calls answered by local users.

6. By choosing a carrier who has DID failover capabilities, we can automatically have DIDs forwarded from the down PRI/SIP to another location which can then forward the call back across the WAN to the desired destination. You can also choose to forward certain DIDs to cell phone numbers if desired.

7. By designing a MPLS with a backup VPN or another back up solution, we can create a secondary route for all calls that need to be sent between sites and can ensure ShoreTel equipment stays synced in case of a primary WAN outage.

This is an overview of some of the redundancy planning you can use but what does it really look like when disaster strikes? Let’s take a closer look at different types of outages and how we can build in redundancies to account for outages.

When the MPLS down we lose extension-to-extension calling between sites and we also lose syncing between servers and switches. The system supports PSTN failover so the system can automatically dial a user’s DID if you try to call their 4-digit extension and the MPLS is down. While the MPLS is down, we can’t make changes to the San Jose site using Shoreware Director but, with a local DVS, IP Switch and PSTN the San Jose site will still have access to Inbound/Outbound calls, VM, Auto attendants, Workgroups and the desktop client will still function allowing users to still place and receive calls.

When PSTN or dial tone at one site goes down using Inbound DID failover and least cost routing, we can allow users at one site to place outbound calls using another sites dial tone. Inbound calls will be redirected by the carrier to the other site where the phone system will route the call to the original destination using a DNIS or Extension routing. In most cases you will need SIP Trunks or a PRI delivered as SIP before being handed off as a PRI in order to have Inbound DID failover from a carrier.

When a ShoreGear switch goes down due to power or network loss a spare switch at that site or at the HQ site will take over all IP phones and Hunt Groups for the down switch. When this occurs current calls will not be affected and most users will not even know it occurred as the failover usually takes only a few seconds. The only affected devices when this happens is any analog connections that switch it is controlling (paging systems, faxes, backup 911 lines).

When a remote DVS is down, all users’ VM boxes will be taken over by the HQ server, all Auto Attendant requests will be forwarded to the HQ server and all Workgroups will be routed to the backup destination which can be a workgroup on the HQ server. Usually the biggest issue affecting users in this scenario is their desktop client may not auto redirect traffic to the HQ server so, they may not have access to communicator.

When the HQ server does down this usually means your phone system is limping along but by having a local DVS at the HQ site, we can offload a lot of responsibilities from the HQ server. In this case the only things we lose are Shoreware Director access for administration of the system, reporting and directory access. All VM boxes, Auto Attendants, Workgroup and desktop clients are handled by the DVS.

When your HQ site goes down due to complete power loss or a natural disaster, the San Jose site in this scenario will continue to function since it has it’s own dial tone, ShoreGear switches and local DVS. We have a few options if the HQ site is going to be down for a long time.

1. If you are using VMware and have a backup of it, we can restore your HQ server at another site.

2. We can restore the HQ server at the San Jose site. Both of these require a backup of your HQ server either in VMware or in the cloud.

If your interested in learning more about ways to make the most of your unified communications and contact center operations, make sure to check out our monthly webinars. We host several complimentary webinars each month. Our webinars cover in-depth admin training, ShoreTel upgrade updates and much more. We walk through scenarios, new systems and system upgrades and are available to answer your questions. We are dedicated to knowledge sharing and innovative solutions for business communications. Our webinars fill up quickly though so be sure to register to guarantee your spot!