- Overview of Solaris Flash Archives and Live Upgrade Technology
- Creating Software Stacks
- Deploying Software Stacks
- Provisioning and Reprovisioning Systems
- Acknowledgements
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Provisioning and Reprovisioning Systems
In addition to using the SunMC Change Manager to rapidly deploy or provision systems, you can use it to reprovision systems. For example, if a farm of web servers has a hardware failure disabling one of its servers, you could use the SunMC Change Manager to rapidly reprovision a host from a free hardware pool to replace the failed servers.
You can also use the software to implement rolling upgrades, that is, software upgrades of a large number of systems. You can deploy upgrades to managed systems and to systems that are scheduled to reboot into the upgraded system at a convenient time. This approach helps ensure a smooth transition to the new software, with minimal impact to the end user.
Whether you use it to provision or reprovision systems, the SunMC Change Manager server uses a shared profile template to drive the software installation or upgrade. A shared profile is a configuration profile that can be used for multiple managed systems or for groups of managed systems. The shared profile is used to specify configuration information such as disk partitioning, name services, and network interfaces. This is essentially information that will be passed on to the JumpStart framework to build the sysidcfg file and the JumpStart profile. You can create these profile templates using an ASCII text editor or through the SunMC Change Manager graphical user interface by selecting parameters and then supplying relevant values for those parameters.
Additionally, you can use a system profile to specify per system information. The values specified in this profile override or complete information from the shared profile, and are applied only to the specified individual host.
The following example shows the shared profile template and system profile template used to install a software stack on a system named barossa.
NOTE
These profile templates use the JumpStart framework profile keyword rootdisk. Using this keyword avoids the need to know the Small Computer Systems Interface (SCSI) or fibre disk configuration of the target system.
The system disk layout specified by the shared template is suitable for a 36-gigabyte disk:
Root device: rootdisk.s0
Root size: 8192
Swap device: rootdisk.s1
Swap size: 2048
These templates also specify that an LU ABE is to be created when the software stack is installed. The ABE location information specified is:
ABE root device: any
ABE root size: 8192
The shared profile used to install barossa is as follows.
# sharedProf.template #Wed Jul 29 13:06:44 PDT 2002 base_config_be_1_root_size=8192 base_config_sysidcfg_nameservice=NIS base_config_sysidcfg_terminal=dtterm base_config_be_1_root_device=any base_config_sysidcfg_domainname=EE_Lab.West.Sun.COM base_config_sysidcfg_ipv6=NO base_config_sysidcfg_rootpw=4KjH13s4L0do2 base_config_sysidcfg_timezone=US/Pacific PERMS=rwx base_config_be_0_root_size=8192 base_config_be_0_swap_device=rootdisk.s1 base_config_sysidcfg_systemlocale=C base_config_sysidcfg_netmask=255.255.255.0 FNAME=default.foubar base_config_flar_archive=/jumpstart/FlashArchives/s9-server.flar base_config_be_0_swap_size=2048 base_config_sysidcfg_timeserver=localhost base_config_sysidcfg_defaultroute=FIND_ONE CONTENTS=changed in shared profile base_config_sysidcfg_networkinterface=PRIMARY base_config_be_0_root_device=rootdisk.s0 base_config_sysidcfg_dhcp=NO
The profile template used to install barossa follows. However, barossa has only an 18-gigabyte disk drive, so this profile overrides the following specifications from the shared template:
Root size: 4096
ABE root device: rootdisk.s5
ABE root size: 4096
Network timeserver host: timehost
The specifications that have been overridden are in bold.
# barossaProf.template #Wed Jul 29 13:42:29 PDT 2002 base_config_be_1_root_size=4096 base_config_sysidcfg_nameservice=NIS base_config_sysidcfg_terminal=dtterm base_config_be_1_root_device=rootdisk.s5 base_config_sysidcfg_domainname=EE_Lab.West.Sun.COM base_config_sysidcfg_ipv6=NO base_config_sysidcfg_rootpw=4KjH13s4L0do2 base_config_sysidcfg_timezone=US/Pacific PERMS=rwx base_config_be_0_root_size=4096 base_config_be_0_swap_device=rootdisk.s1 base_config_sysidcfg_systemlocale=C base_config_sysidcfg_netmask=255.255.255.0 FNAME=default.foubar base_config_flar_archive=/jumpstart/FlashArchives/s9-server.flar base_config_be_0_swap_size=2048 base_config_sysidcfg_timeserver=timehost base_config_sysidcfg_defaultroute=FIND_ONE CONTENTS=changed in shared profile base_config_sysidcfg_networkinterface=PRIMARY base_config_be_0_root_device=rootdisk.s0 base_config_sysidcfg_dhcp=NO
Installing and Managing Software Patches
In addition to using it to install or upgrade system software, you can use the SunMC Change Manager to manage and deploy software patches.
To deploy a patch or set of patches using the SunMC Change Manager, install, verify, and validate the patches on a single system. The verification and validation of the patches on a single system is very important. At this time, you should validate not only that patches address the issue for which they were designed, but also that they do not negatively interact with other third-party software and that they do not negatively affect software performance.
After you have tested and validated the patches, use the patched system as a master system for creating a software stack that contains the system software, any other installed software, and all installed patches. You can then deploy this software stack on all similar systems or on all systems that require the patched software stack.
Using the bart auditing tool, you can deploy the patched software stack automatically. You can also use the tool to determine which systems need the patched software stack, but do not yet have the patched software stack installed. After making this determination, schedule the patched software stack for installation on the necessary systems. You can schedule this installation manually or automatically.
It is also important to keep in mind that because LU technology is being used, you can deploy the patched software stack to an ABE. If you later determine that a problem exists with the patched software stack, the previous software stack is still available in the previously activated BE. This fact might also be used to mitigate exposure to risk during the deployment of new versions of system software or application software.