Sun Microsystems 10 manual Upgrade- and Patch-management in a virtual environment, Da Live upgrade

Version 3.1-enSolaris 10 Container Guide - 3.1 3. Use Cases Effective: 30/11/2009

3.16. Upgrade- and Patch-management in a virtual environment

Requirement

[da] Virtualization by means of Solaris Containers allows the application to be disengaged from the hardware. An application can thus be run very simply on different servers. Data center operations must ensure the availability of these applications by means of suitable measures. This includes scheduled downtime requirements but also the requirement to protect against unscheduled downtime. Scheduled downtime is required for preventive maintenance of any IT infrastructure. By far the most scheduled downtime is required for patching systems. Solutions that merely focus on transferring an application from one machine to another therefore completely miss the actual point. Simple and automated release management is much more important for the entire operating system. Downtimes for updating the application and for patching the operating system (OS) in a virtualized environment can therefore be regarded as completely independent of each other.

Solution

[da] By using live upgrade and upgrade-on-attach associated with ZFS, the required prerequisites for efficient release management arise as a result for data center operations.

Installing a kernel patch for an operating system is possible
without downtime for the application. An operating system can be
upgraded while running by using live upgrade. Activation will
occur at a later, planned point in time which in many data centers
fits in with the service level agreement.
Solaris live upgrade is the optimal procedure for performing an
upgrade for such a "virtualized" system or installing patches. The
procedure, in particular by the use of ZFS, is characterized by the
fact that the length of the required maintenance window and thus
the downtime of system applications are minimal. This also
always implies that all applications installed on the system are
affected simultaneously. If several applications with different
maintenance windows are run together on one system, a live
upgrade cannot be performed.		Figure 20: [da] Live upgrade
With the new update-on-attach technology for local zones, another		mechanism is available in Solaris
by which this problem can be solved. It allows an update to be
performed on a Solaris Container including the application,
scheduled and within the maintenance period defined for the
application in the Service Level Agreements (SLAs). In the
process, the actual update is done by simply relocating the
containers to another system with a newer version of the operating
system. Relocatable containers also allow an application "to be
protected" from a live upgrade. If operations cannot find a common
maintenance window for the applications on a system, individual
containers that contain these applications can be relocated to
other systems with the same version of the operating system. This
occurs systematically during the timeslot available for the			Figure 21: [da] Update-on-attach
application respectively. The concept was published	in a
whitepaper that can be accessed through the following link:

http://wikis.sun.com/display/SAPonSun/Links+(to+SAP+and+or+Solaris+topics)

Assessment

[da] This use case has the following characteristics, among others:

∙Minimal downtime required through live upgrade and ZFS

∙High flexibility and "plan-ability" through update-on-attach

∙High security through "rollback" options

∙Simple administration and simple operation

∙Technologies are available in Solaris 10 free of licensing fees

31