At a client site recently, a hardware problem took down the server that ran most of the site's Perl and Windows NT shell scripts. Almost immediately, users began calling about problems being caused by the scripts not running. This situation brings to mind several important questions that you need to answer for your site. If you lost the server on which you run your scripts, which crucial script operations would your site immediately miss? How would this situation affect your users?
After you determine which scripts are crucial, you need to create a high-availability environment for those scripts by setting up a secondary administrative server and preparing your primary administrative server and scripts for a quick rollover if a failure occurs. Here are the steps:
- Centralize the storage and execution of your scripts on your primary server, and put the scripts in a common directory. Centralizing your scripts in a common directory speeds deployment to the secondary server because you don't have to search and replace the server's path in the scripts. However, you can centralize only those scripts that you can run over the network. You can't centrally store scripts that require local execution.
- Adapt your scripts so that they're server independent. Use environment variables such as ComputerName, SystemRoot, and Temp instead of hard-coding the server name. That way, you don't have to alter the scripts before you run them on the secondary server.
- Set up the second server that you'll use to run your scripts if your primary server fails. You can use the Robocopy utility from the Microsoft Windows NT Server 4.0 Resource Kit to duplicate the primary server's script directory on the secondary server. Schedule a .bat file that triggers Robocopy periodically to refresh the secondary server's script directory so that the directory stays up-to-date. If you use Microsoft Visual SourceSafe (VSS) to manage your scripts, have VSS deploy them to both the primary and secondary server. Install all the files and extensions you need to run the scripts (e.g., Windows resource kit utilities, ActivePerl and related extensions, Windows Script Host—WSH) on the secondary server, and verify that they all run correctly. If you use the Task Scheduler to run your scripts, set up the scheduled jobs with permissions and the scheduled runtimes on the secondary server. Clear the Enabled check box on the Task properties dialog box so that you can switch to the secondary server with only a few clicks. To clear this check box in NT, double-click My Computer, open Scheduled Tasks, right-click the scheduled job, and select Properties from the drop-down menu. In Windows 2000, open Control Panel, open Scheduled Tasks, right-click the scheduled job, and select Properties from the drop-down menu.
- Create a script configuration and deployment document for each script. This document needs to include all the details necessary to understand a script's operation, placement, and dependencies. Figure 1, page 7, shows an example of this document. You can use this example document as a starting point, modifying it to fit your environment and corporate policies. If you ever accidentally delete a crucial task or lose a server on which you're running scripts, this document can be a big help in getting scripts back online and back on schedule.
- Use the script configuration and deployment document to create a master monthly calendar of your scripts and their execution schedule. You might also want to include the backup schedule and other scheduled events, such as maintenance outages, and high load times, such as end-of-month reports.
If you take these steps, you'll have a high-availability environment for your crucial scripts.
