Deployment Framework Best Practices for Red Hat Enterprise Linux on HP ProLiant

specific kernel errata are required or HP and Red Hat codevelop Driver Update Packages (DUP) that

deliver updated device drivers necessary to enable the respective HP ProLiant generation server.

BEST PRACTICE: HP publishes minimum operating system versions for each ProLiant generation

platform, noting any special requirement, such as specific kernel errata or driver updates. You must

review any applicable HP Customer Advisory (CA) reports to understand possible required additional

actions. Boot critical device driver updates are also made available as part of the HP ProLiant Gen8

IP offering, presented to the operating system on the Virtual Install Disc (VID). You must explicitely

enable this function in order to present the VID to the operating system as a USB device. The format

of these driver updates should integrate directly with the native Anaconda based RHEL installer.

Agentry - The category of agentry is focused on components, typically supplied by the hardware

platform vendor, that interface directly, or through the operating system, to provide specific

functionality or manageability with the hardware. These are delivered in custom formats or in

operating system compatible packages.

In the context of this document, HP ProLiant Gen8 agentry is contained within the SPP and is

accompanied by the HPSUM utility but can also be found in the Software Delivery Repository (SDR)

which you can directly install with normal operating system utilities.

Applications and Services - For the application and service components, these are often under

the explicit control and discretion of the business entity. These are either contained in the operating

system distribution itself, delivered in other formats, or even locally developed by the business entity.

Additional Deployment Considerations - Providing a more complete representation of the

aspects that should be considered for a deployment framework, several other realms must be included

in the overall model. Ways to continually manage configurations, monitor the health of the

components, and being able to cope with disaster recovery through backup and recovery are key

areas to account for. A full treatment of these areas is well beyond the scope of this document,

however representative examples will be provided. With all these consideration, the key attributes for

the deployment framework to take into account and to provide include the client-side application, if

any, plus the model for data transport and the version control of any changes applied. A brief

description of each of the consideration follows:

• Configuration Management - Similar to the previous discussion of scale and process

preferences, the means to manage the configuration of the deployments vary from very simple

(divergence) to complex (convergence). In addition, local preferences, tendencies, or policies

can dictate how configurations must be managed, whether applied ad-hoc by direct file edits

or through a more formal change management process where changes are packaged into

operating system compatible formats.

• Monitoring - Many different characteristics should be considered in the deployment

framework. Often the monitoring is done across the following:

• availability (basic binary quality of on/up or off/down)

• performance (continuous, analog measure of given quantity's value)

• security (reporting and compliance to policy)

• integrity (consistency of desired results versus actual results)

• Backup/Recovery - To address possible disaster recovery, a core discipline present in the

environment is likely the backup and recovery processes. Depending upon the tendencies

and scale discussed in previous sections, an environment can decide to have the deployment

framework to completely recreate any business service, leaving only actual service data for