Boot image control |
A boot image control strategy is a common way to reduce total cost of operations in organizations with large numbers of similar computers being used by users with common needs, e.g. a large corporation or government agency.
Very often a large computer vendor is required to explain in a bid in response to an RFP how they intend to simplify the purchaser s boot image control problems and the attendant service costs:
The total cost of operations correlates strongly to the total number of different images, not the total number of computers, so this is a major cost concern. Three basic strategies are commonly advised: *a single base boot image for each type of computer in the organization, customized by each user with no central control *a thin client strategy where the smallest possible boot image is used, typically one that does not include a full operating system *a departmental boot image strategy where a base boot image is customized with applications to fit each group of users, but, the users do not have the ability to upgrade or alter the configurations
Organizations that do not closely track, control and set common standards for, acquisition of new computer hardware, typically can only practice a thin client strategy. A Linux boot image can be thought of as a thin client for this purpose, as Linux can be made to deal with a wide range of computer hardware with no need for additional device drivers to be detected and installed.
Which strategy will reduce total cost of operations the most depends on several factors: *whether the capabilities of a full operating system are required, or just those of a thin client *whether applications with inflexible software licenses are in use that must be paid for not only if they are used, but even if they are only installed *whether poorly-behaved applications that interact badly are in use *LAN or removable disk limits that make it easy or difficult to do re-imaging on demand
While the departmental boot image strategy seems to be the most flexible, the complexity of creating and managing several large boot images, and determining when a department needs to upgrade its applications, can easily outweigh these. Especially if users object and try to subvert the discipline of waiting for a regular boot turn to upgrade all machines at once. If each user is allowed to do this on their own, then, the discipline soon degrades into effectively a bunch of home computer whose issues are not really diagnosable nor comparable to each other. In which situation thin clients may become the only practical answer:
Many organizations use thin clients for applications which require high security, involve unreliable users or repurpose older machines for continued use. This much simplifies boot image control by facilitating centralized management of computers, and has many advantages: *since servers manage clients and the local environment is highly restricted (and often stateless), providing protection from Malware, support costs are reduced *since no application data typically resides on the thin client (it is entirely rendered), it is securely stored on network drives upon its creation *since disk, application memory, and processors are minimal in thin client hardware, they go obsolete slowly and cost much less *since they are not as useful as ordinary computers they are of less interest to thieves
While control of the images is simpler, there are disadvantages. Thin clients: *require more network bandwidth *require more host computer power and must typically be served by much larger host boxes *typically cannot run arbitrary PC or Mac software *perform poorly in multimedia applications or games - an advantage in many business environments
Many organizations try to gain the advantages of thin clients without the disadvantages by treating many very standard machines as if they were terminals, but with very much greater capabilities. As they buy new computers, they put the demanding applications on those. On the rest:
Administrators perform a regular (often bi-annual) boot turn that re-images many older, off-spec machines at once so that new hardware can be deployed for higher-end use. This procedure is called cascading: the oldest hardware is repurposed with simpler software to let it continue in use for some less demanding or more access-controlled applications, but subjects it to much more rigorous control to minimize the number of images.
The total cost of operations correlates strongly to the total number of different images, not the total number of computers. To minimize the number of images requires additional discipline:|
|