Don’t let it happen to you

April 15th, 2012 by Stefan Besling

One hundred years ago today, in the darkness of the night, more than fifteen hundred souls were lost to the chilling waters of the North Atlantic. With them went the proudest ship of the time, and much of our belief in ideas of indestructibility.

Human hubris is incurable at heart, yet seminal events such as the sinking of Titanic re-invigorate Donne’s admonition never to ask for whom the bell tolls.

Bearing in mind that it tolls for thee, what can you do to improve your chances? Which precautions can you take today so that the unexpected does not hit you quite as hard tomorrow? In this article, I explore a number of options and recommendations to keep you safe(r) even when disaster strikes.

Development

Building good applications takes care, effort, and attention to detail. You don’t want to lose the work of weeks to the vagaries of a disk sector.

VoiceObjects applications are stored in a database, so depending on the setup you work in you may already be covered by regular backups of that database. But even then it might be a good idea to create “local” backups of your applications at regular intervals to have ready access to them in times of need. Desktop for Eclipse makes this very easy by offering the option Backup All Projects right within the VoiceObjects menu.

For the purpose of protection, the backup mode “ZIP archive” is the most convenient one – it creates a single ZIP file containing exports of all your projects.

Of course you can also selectively back up individual projects as desired. On the respective project version folder in the Repository Browser, right-click and select Export.

If you use libraries, then for backup purposes it works best when you first export these individually as above, and then export the project version itself without the libraries (clear the check box “Include library objects in the export” in the Export dialog window – only relevant if libraries are actually in play).

For more information about exporting (and importing) in Desktop for Eclipse, refer to the Desktop for Eclipse Guide (PDF).

Deployment

While on the development side the main concern is that of backing up so that work can be retrieved again, on the deployment side the primary need is to keep the system running.

For serving calls, VoiceObjects is reasonably independent of its direct environment. If the Metadata Repository database fails, this has no impact other than complaints about the system license – and you have a full 72 hours to restore it. If the Infostore Repository database fails, data is buffered in message queues and remains safe so long as there is disk space.

But of course it can also happen that the box crashes on which a VoiceObjects server process runs – and there isn’t much resilience the process could have in this case. The only way to ensure continued availability of the application is to run in a cluster setup that spans multiple boxes.
VoiceObjects provides built-in support for clustering. Multiple server processes can be grouped together to represent a single logical Server object – and can then be monitored and managed as a unit from the Control Center. A single command deploys application changes across the entire cluster, and consistency of deployments among the processes is ensured – even to the point that when an individual box is taken down for maintenance and brought up again, it automatically picks up the exact same application deployments as its brethren.

Multiple adjacent boxes provide a good level of resilience, but for certain applications even more is required. In such cases the typical approach is to run clusters in multiple geographically separated locations to have protection against disruptions such as earthquakes, hurricanes, etc. VoiceObjects supports such setups through its Virtual Control Center, which I had described in a recent blog article.

Note that while it is necessary to have the VoiceObjects side of things running in a redundant cluster setup, it is by no means sufficient to deal with box failures. All non-trivial applications interact with backend systems to retrieve information, perform transactions, or store data. Ensuring resilience of these backend systems is just as essential a part of protecting the overall deployment.

Many more details on the VoiceObjects deployment architecture, clusters, and the Virtual Control Center can be found in the Deployment Guide and the Administration Guide (PDF).

Also keep in mind that, as a convenient and cost-effective alternative to a premise installation, Voxeo offers VoiceObjects On-Demand – a hosted installation of VoiceObjects with built-in redundancy and a 100% uptime guarantee that is unmatched in the industry. An option to remember!

As always, for questions and comments, reach out to me on Twitter at @voxeostefan.

Tags: ,

Leave a Reply