In a WSOD environment, the client workstations are non-functional when the WSOD server is down. Since the workstation has no software loaded locally, the loss of the server is catastrophic. To provide critical application availability, Golden Code introduced the "Offline Partition". This is a minimal OS/2 installation created for the purpose of running a specific application that must be available when the server is down. This installation is kept as static as possible, while still retaining the most recent version of the application. There are multiple strategies for accomplishing this.
The real "trick" in this implementation is allowing a user to choose to boot the workstation from either the network (WSOD server) or from this local Offline Partition. Golden Code invented technology to enable this capability to be provided through the well known boot manager menu.
Registration Server/WSOD Client Installation
Even though there is no software on the WSOD client, the system itself must be properly configured to allow for the RIPL or PXE boot. The CMOS settings must be set to a known state. The NIC may need its boot ROM flashed with the correct firmware level. On-board boot and network devices may need to be enabled/disabled. The hard disk will need to be partitioned and formatted. Providing manual instructions for these steps is tedious, error prone and thus costly.
On the server, definitions must exist in LAN Server for this workstation. A hardware specific template or set of templates is used to create the workstation-unique files and directories necessary to make this system boot properly. LAN Server provides an interface to generate these definitions, but the results are almost never ready for use as a production system. Thus there is a need to "post-process" these files and directories to ensure that all updates, additions and deletions occur and the workstation is customized to the exact requirements of this environment.
Golden Code built a client/server process to handle these tasks. A server side daemon called Registration Server handles the requester definitions and a set of OS/2 boot diskettes with access to network drives allows an automated, menu driven setup on the client side. CMOS updates are handled via an automated, menu driven DOS based diskette process.
This process provides for:
The core of any single system image environment is a configuration manager. In order to have the same exact server system apply to a variety of hardware, LAN topologies, WAN topologies, applications, geographical or organizational groupings... one must be able to have a single program generate the entire server configuration.
In addition, this program must be aware of the values that are unique to a site/server so that the IP address, SNA configuration and other items can be customized as necessary.
Having a single process implement this capability provides a highly standardized result. This eliminates errors and minimizes risk. In addition, if built such that it can be called on an unattended basis, then it can be used during change control to push out any configuration changes to the server, without complicated logic.
Golden Code has built an extensive set of programs comprising this capability. A Java GUI can be provided to allow on-site technicians to edit the site's custom configuration and the results are stored in a simple database. The configuration programs read their input from this same database and can be called from the GUI or on an unattended basis. After years of research and development in this area, Golden Code has "pushed the envelope" in the single system image, especially in large enterprise environments where this same image must support a wide range of system uses.
Possibly the most challenging subsystem to manage in any LAN system is the print environment. It is complicated, its configuration resides in a wide set of files and locations, it involves every major system component (clients, server, printers, print servers, LAN hardware) and it is highly reliant upon devices that were never designed to be managed well (the printers themselves). If every part of this environment is not 100% right, the entire printing capability may be non-functional.
In addition, the printers can be in a completely unknown state from powered off to jammed to out of paper or toner. Users routinely interact with these devices, making their state impossible to predict. On top of this, the manufacturers typically provide only weak tools to manage these devices. Usually these tools are not programmable, but instead require a user to manually run the GUI.
With this in mind, the setup of a new printer must be as automated as possible. This includes the following:
Over time as the configuration, firmware, drivers or other parts of the software support (in the server AND in the printers/print servers themselves) require changes, one must be able to control all aspects of this environment in a programmatic and unattended manner. This allows new configuration templates or other changes to be applied during change control and then pushed out without any manual intervention.
Through a unique library of both OS/2 and Lexmark printing services, 100% of these activities can (for the first time in the industry) be automated and handled in a completely unattended manner. This can cut down the number of printer related problems and support/management effort to an absolute minimum and thus save a huge amount of money over the system's lifetime.
With WSOD, the boot of a client is now inextricably linked to the network and server. This is a more complicated environment to optimize than a traditional Warp v4 system. In addition, boot performance and boot reliability is highly variable. With the right configuration, a very large number of systems can reliably and quickly boot simultaneously. With the wrong configuration, few systems may boot at all when multiple systems are attempting to load at once. This scenario is what IBM terms a "boot storm". It is one of the key design points for a WSOD system because for a production system, one must tune the system with this scenario in mind.
Golden Code invented an automated stress testing environment that allows a wide range of tests to be run without user intervention. For example, the systems developer may specify that the a progression of 10 then 20 then 30 systems should simultaneously boot, logon, print and then reboot. The stress test environment will track the status of each system and capture statistics on the boot, logon... performance. This stress environment was designed to handle up to 64 machines per LAN segment/boot server, but it could be extended if required.
Interestingly, it turns out that in some ways the simultaneous logon of many WSOD clients can be more sensitive than even a WSOD boot. This is somewhat counter intuitive as during boot the server must transfer the entire boot image (20-25MB) over the network. It is easy to envision how a boot storm can saturate a network, or a server NIC and poor performance and/or reliability can result. It turns out that performance and reliability are also at issue in a "logon storm".
With Golden Code's system and network skills, and by using the stress environment, Golden Code consultants have been able to make 64 machines boot simultaneously without any failures. And all of the systems are on a single LAN segment and boot within 8 minutes. At just 40 machines, these systems can be made to boot with no failures within 4 minutes. This is so close to normal FAT client boot time that it is not an issue for the majority of customers, especially since this is the worst case scenario that only would happen in the event of a power outage or other boot storm scenario.
Note that it is challenging to make these systems boot within a short period of time anyway but what is really difficult is making them boot with great performance but without failures. This is the classic trade-off that is often made and without a stress environment, one cannot even begin to explore these issues.
In addition, it has been our experience that a wide variety of system and network problems can be made to occur when the system or network is put under stress. Thus this technique has been made a standard part of the Golden Code development process, during the certification (testing) phase.
Shutdown/Poweroff/Reboot Daemon
In large corporate installations of OS/2, where there are a large number of remote sites, there can be great difficulties generated by users leaving their systems on at night. One example of a problem this can cause is locked files on the server when maintenance activities like change control are trying to update these same files. Golden Code implemented a daemon process that can be run on every client system, in a detached mode. This daemon listens for a request to shutdown, poweroff or reboot the workstation.
A command program is provided that broadcasts a shutdown, poweroff or reboot message to these client side daemons. The target(s) can be a single system, a group of systems or all client systems. This program can be run in an unattended mode so that it can be used from within a change control process. This same tool can be easily modified to provide Wake-On-LAN services to this same set of targets.
It can be very handy to provide each user with access to a list of desktops, with each desktop having a different purpose. For example, a primary desktop can be provided for standard use, a desktop can be provided with computer based training applications and yet another desktop can be provided for administration functions.
While this capability is nothing unique or new, Golden Code did implement a mechanism to dynamically swap these desktops on the fly at WSOD logon time. WSOD does not provide this capability itself. In WSOD, each user has exactly one desktop. By modifying the logon process, using user exits and directly modifying the LAN Server DCDB on a dynamic basis, the user can select the desktop which want to access at logon time. When the desktop is displayed, WSOD provides the one chosen.
Thus the restricted WSOD shell is still in use, but the multiple desktop facility was added.
Early in the WSOD implementation process, Golden Code identified gaps in the WSOD client that made it impossible to fully replace Warp v4 client systems at a large enterprise customer. A one-for-one replacement system could not be made using WSOD.
Golden Code worked closely with the IBM WSOD development team to specify and test a set of 7 WSOD improvements that eliminated these gaps. All of these functional enhancements were released in WSOD client fixpacks and are now part of the standard WSOD implementation.
For more information on any of the above innovations or other Golden Code technologies, please contact info@goldencode.com. Some of these technologies may be readily available for licensing and some of them may require customization for a specific environment.