Upgrade

   


An upgrade is significantly different from a new installation. From the outset, a restriction inherently exists that a system already is running, unlike the new installation discussed in the previous section, where the system is being created from scratch.

The upgrade carries a greater risk than the new installation because a working system is being changed, file systems will be overwritten, and the potential exists for unforeseen problems to arise.

Thorough testing of the upgraded system in a test environment significantly reduces the risk of serious problems occurring, but it does not totally eliminate it. Another major difference between the upgrade and the new installation is the requirement for a fallback procedure, a way to recover if things go terribly wrong. If the upgrade fails and cannot continue, there has to be a way of restoring the entire system to the state that it was in before the upgrade commenced.

The following sections address some of the issues that need to be considered when undertaking an upgrade of an existing system.

Preparation

Thorough preparation and testing are key elements in reducing the risk of failure when carrying out an upgrade. The following list provides some useful tasks that should be carried out:

  • Test environment ”Any upgrade, whether it is for the entire operating system or an application, should first be carried out on a test environment so that problems can be resolved before the live upgrade. The mere action of performing the upgrade is not the only important part; testing the upgrade also is important, so development of comprehensive test packs is essential to reduce the risk of unforeseen problems as much as possible.

  • Compatibility ”The system manager must ensure that the system meets the minimum hardware requirements for the upgrade to proceed. Sometimes it is assumed that because the current version runs normally, the new version will, too. A simple example proves the point: An old Sun IPC workstation (architecture Sun4c) with 24Mb of RAM runs Solaris 7 quite happily. It's fairly slow, but it runs. If you now try to load Solaris 8 on the same machine, it will fail, not only on the architecture not being supported any longer, but also on the insufficient amount of RAM.

  • Upgrade path ”The normal progression of upgrades for the Solaris operating environment is fairly straightforward. However, if you have any doubts about jumping from, say, Solaris 2.4 to Solaris 7 in one go, then a call to the Sun Helpdesk will verify whether you should be aware of any special issues.

    In the case of application software, especially software supplied by a third party, this aspect can become increasingly important. Some vendors insist that a scheduled upgrade path be followed. In this case, the system manager cannot jump several versions of the software without invalidating the support warranty. This should always be checked with the supplier because it is possible that a number of interim upgrades may have to be performed to arrive at the target version. A further aspect of third-party software is that when you are upgrading the operating system, you should seek confirmation that the application is fully supported under the new version of the operating system.

  • Patches ”Upgrading to a new version of the operating environment might mean that, in addition to the installation of the operating environment, some patches are needed. For example, when doing an upgrade from Solaris 2.6 to Solaris 7, you should determine that Solaris 7 was available during 1999. The Sun Year 2000 Product Compliance Status Table shows that three patches are required to achieve full compliance. In addition, a patch cluster containing recommended and security patches should be applied to the operating environment. The system manager should be aware of the details of the patches and also of any patching policy that exists within the organization (patching is discussed in more detail in the next section).

  • Fallback procedures ”One of the most important preparatory tasks that needs to be carried out is including a plan for restoring the system if a failure requires the upgrade to be aborted or postponed. In this instance, there must be a capability to restore the entire system to the state that it was in before the upgrade started. The section " Backups ," later in this chapter, provides details on how to provide this capability.

Policy on Stability of Product

Some companies adopt a policy of extreme caution when looking to upgrade the operating system, especially if the upgrade is a major revision. For mission-critical businesses, there is a risk that the new version will not properly interact with the existing systems on the network ”even though a significant amount of testing can be carried out on a test environment, it is often difficult to replicate everything!

Other companies, however, move to a new operating system version virtually as soon as it becomes available. This is fine when a new system is being installed, but it presents other problems when upgrading an existing system. Some of these problems are outlined in the following paragraphs:

  • Clustered failover systems ”Certain kinds of configurations display problems of their own, particularly in a master/slave setup. Normally, one of the slave systems would be upgraded first and left to run for a period of time to see if any problems were encountered. If so, then that system could be reinstated without too much disruption to the operation of the business. The difficulty arises when a failover must occur onto the newly upgraded system in the live environment, which is necessary to upgrade the master system. If problems are encountered at this point, then the whole system is in danger of crashing and becoming unavailable. Careful consideration is needed in this instance, along with extremely thorough testing.

  • Third-party application software ”Sometimes a third-party supplier needs to provide a new version of the application software to run on the upgraded operating system. If this new version is not available, then it can become impossible to carry out the upgrade without incurring serious risk with no guarantee or warranty from the supplier.

  • Mission-critical nature ”The mission-critical nature of some installations dictates that a new version of an operating system must be declared stable before any kind of implementation is even considered. The difficulty here is defining what is "stable." Some companies wait for the second release ”that is, an interim release that fixes the majority of the bugs already identified; others, such as government departments, may wait until a central body declares it to be stable after it has carried out extensive research and testing.

Backups

Before an operating system upgrade can take place, a guaranteed backup of the system must be performed.

Ideally, the backup should be performed with the system at a single- user state ”that is, with no activity and no users logged in. Any databases should be shut down, and the backup should be verified . It is critical that the backup is capable of being read because it could be the only means available to restore the system if the impending upgrade failed.

The final contingency is to actually restore the system from the backup media onto a test environment. By doing this, the integrity of the backup is proved, and the capability exists to restore the system in the event of a failure.

It should be normal practice to regularly test backups, but in the real world, this is rarely done. Management and users alike are satisfied and confident as long as a backup of the system is taken. They assume that because the backup was done, there will be no problem in restoring the necessary files, if needed. Without testing, there is no guarantee that a backup can be read, particularly when the backup is written to magnetic tape.

A further option for obtaining a system backup if mirroring is being used is to break the mirror ”that is, disable one half of the mirrored pair, creating a static copy of the system disk in its current state. The static copy could then be used to reinstate the operating system to its former state if the upgrade failed, and it would also be much quicker than having to restore from backup media.

Type of Installation

Four methods exist for installing the Solaris software on a system: interactive, network, Jumpstart, or Webstart. Each of these options is discussed further here:

  • WebStart ”This installation option is only for initial installations and cannot be used for upgrading the operating environment. It is included here for completeness only. WebStart is Sun's Java-based installation program. It provides a point-and-click interface to install the operating environment as well as other software that is bundled with Solaris.

  • Interactive ”This is the preferred option for system administrators building a single system, and it is discussed in the next section.

  • Network ”In this option, the operating environment is installed over the network. Ideal for a computer without a local CD-ROM drive; a CD-ROM drive is required for a Solaris installation because this is how the software is delivered. A remote install can be carried out using a remote system's CD-ROM drive, or an image of the Solaris CD-ROM copied to the remote system's hard disk. This option is very useful when there is no local CD-ROM drive, and this is also the recommended method for the E10000 system.

  • Jumpstart ”This is a method of automating the Solaris software installation process on a number of systems. This option is discussed in the upcoming section "Multiple Systems."

Single System

The installation of a single server is more easily carried out using the interactive installation method . This still appears to be the most popular method among seasoned system administrators, partly because it is the method that they have always used, but also because it provides the system administrator full control and flexibility.

Using the interactive method, the system administrator can preserve file systems so that they are not re-created during the installation ”a process that would lose all of the current data ”and manually change only those file systems that will be directly affected by the installation process. The option of preserving existing file systems speeds up the whole process, reducing downtime.

Multiple Systems

A large number of companies now tend to use "standard builds" for their networked desktop PCs. The advantage of this is that each desktop PC is configured in exactly the same way, so this saves a lot of time because the build can be done with very little or no intervention. In much the same way, the Solaris software can be installed on multiple machines using a predefined set of configuration files. This method of installation is known as Jumpstart.

Imagine a company with 50 servers, all requiring an upgrade to the latest version of Solaris. Suppose that 10 are application servers with 1024MB (1GB) of memory, 25 are operating system servers with 512MB of memory, 8 are file and print servers with 768MB of memory, and 7 are database servers with 2GB of memory. Rules can be configured so that, in this case, the amount of memory decides how the server is to be installed ”that is, the Solaris installation options. Instead of the system administrator having to carry out 50 complete installations, this can be done automatically. One significant advantage with this option is that it eliminates the possibility of human error, an important factor when considering 50 separate installations because this can maintain consistency across many servers. This also saves on the resource and time needed, as well as greatly reducing the operational impact on the business.

A further point to note with Jumpstart installations is that scripts can be automatically called to run both before and after the installation takes place. For example, a script might be run to back up the system before the upgrade, followed by another script to restore the data file systems after the upgrade has taken place. See the Appendix for further reading on the Jumpstart option.

Recovery from a Failed Upgrade

If an upgrade fails, then there has to be a means of restoring the system to its former state ”that is, the state that it was in before the upgrade commenced. This can be done in one of two ways:

Small Versus Large Installations

The interactive installation method is useful for a scenario in which a system administrator supports only a few systems. For larger installations in which many tens or hundreds of systems are being configured, this option quickly becomes impractical and also increases the risk of human error.


  • Restore from backup ”If file systems were preserved during the upgrade, then only the Solaris operating environment file systems need to be restored from the backup media ”that is, root (/), /usr, and maybe /opt and /var, if they are separate file systems. Of course, the system boot block would have to be recreated on the system disk, but apart from that, this is a fairly simple process and doesn't take too long.

  • Use a mirrored pair ”The "Backups" section earlier described a method by which a mirrored pair of disks containing the essential operating environment file systems could be effectively broken so that a static copy remained. If the upgrade then failed, it is easy to reinstate the broken half of the mirror as the master and use it as the live system disk to recover the system. If a RAID configuration such as this is in use, then this option provides a much quicker recovery, dramatically reducing the downtime and the impact on the operation.


   
Top


Solaris System Management
Solaris System Management (New Riders Professional Library)
ISBN: 073571018X
EAN: 2147483647
Year: 2001
Pages: 101
Authors: John Philcox

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net