Managing the New Solaris Environment

The methodology chapter discusses, in detail, the process for the design of a management solution. The case study described in this chapter was a project that was identified to end when the final user acceptance test was successfully completed. Both backup and job management tasks are discussed in this section of the case study, but the key work performed by the migration team was the design and implementation of the solution.

Operations management remained the responsibility of the customer's computer operations department. One of the reasons for this was that while the HP/UX systems were to be retired , the PC LAN and legacy mainframe remained part of the production environment. Therefore, the management problem was a heterogeneous one.

The two key management requirements were to provide off-line recovery capability and to allow business superusers to start and manage application jobs. Both of these functional areas were subjected to a business requirements capture, design, and test life cycle before handover.

Backup

The move to the Solaris OS gave the customer the opportunity to take advantage of the predecessor product, Sun StorEdge ¢ Enterprise NetBackup. The source system was also bundled with a backup solution, and the Sun team captured the policies for occurrence, strategy, and tape maintenance and reimplemented them in the new technology. This involved implementing the "No worse than before" strategy. One of the solution-design constraints was the customer's tape pool size policy. The company also dumped the production database directly to tape, using Sybase's online backup utility.

The change in technology mandated a change in the backup technology. Fact-finding was undertaken, user policy constraints discovered , and a suitable backup solution implemented. This involved configuring a small robotic tape device on the production domain of the multidomain system and the second system. Network backups were used for the QA domain. Note that the MIS environment was not backed up because it changed only once a month.

Job Management

The key problem introduced by the proposed platform architecture was related to job management. The COTS solution had an integrated job manager for which certain jobs (for example, accounts journaling jobs) had to be organized. System tasks could be organized by traditional Solaris/UNIX solutions, but application- related tasks had to be organized by the application's encapsulated job manager. In addition, a solution to the consolidation/workload sharing design had to be found.

Another problem was that the software had not been designed to run in a work-sharing environment. It was network aware ”for example, it used TCP/IP for its interprocess communication ”but two instances of the job scheduler could not be distinguished in the UNIX process table. System managers could not distinguish between the development and training instances of the job management daemon when using the UNIX utilities. While these daemons were correctly manipulated by an applications component running on remote PC systems, the system's managers felt uneasy about this new feature. A feature in the software was discovered that permitted this problem to be overcome .