Application Provisioning

The N1 Grid software delivers a flexible provisioning capability that can provision simple individual service components (for example, a web server or EJB) or a larger collection of service components that comprise a complete business service (for example, an entire three-tier application). Combining the automated provisioning of services through repeatable, flexible frameworks with this level of flexibility opens up completely new opportunities for businesses. Although provisioning business applications is a relatively simple process, manual provisioning is time consuming and error prone. The issues that arise are usually caused by:

• Not architecting to demonstrate successful completion of use cases and delivery of CTQs as part of the test cases

• Operational aspects of the initial stand-up that are not uniform and compliant with the agreed-on standards of the business

• Service configuration and capability that are not maintained during a migration between development, testing, and production

• Impact during the movement of an application in response to something within an environment

• Interruption of service during updating or patching

Even if you do a good job of the initial provisioning, changes occur over time. For example:

• Different people set up and configure servers and applications differently, especially if there are not clear and unambiguous procedures to follow.

• Layers in the stack change above or below the original build layer (for example, the impact must be understood and control must be maintained when the operating system changes under an application).

• Changes outside of the change-control enterprise processes are not seen (for example, administrators are allowed to make changes through GUIs or other back doors into switches, servers, and storage systems).

Consider the typical data center in which a favorite application is used all of the time. The IT teams know it well and install it a lot. And still, how many times after the installation has a configuration error taken down that service or has that service inexplicably ended up in an unexpected state that is different than the state in which it was initially installed?

The N1 Grid architecture helps you smooth out your application design and provisioning throughout the life cycle and throughout the stack. The N1 Grid architecture does this by providing the tools and products that support the provisioning and operations associated with a service. No longer is there testing, manipulation, and rollback on one targeted portion of the stack without visibility to the rest of the stack or service. As with virtualization, there are options to consider for each part of the stack and for the stack as a whole.

To illustrate these provisioning examples, consider the following example of a classic three-tier architecture. Refactoring the layers of the SunTone AM cube to suit the three-tier architecture, TABLE 4-4 depicts the provisionable entities for each layer.

Table 4-4. Three-Tier Internet Architecture Layers

Layers	Presentation Tier	Business Tier	Database Tier
Application	Web server	Enterprise JavaBeans	Database
Virtual	N/A	Application server container	JDBC
Operating system	Operating system layer	Operating system layer	Operating system layer
Hardware	Hardware layer	Hardware layer	Hardware layer
Infrastructure	Infrastructure	Infrastructure	Infrastructure

In this typical three-tier architecture pattern, each tier is typically hosted in a separate set of servers or containers. The virtual layer, if present, provides an element of separation between the operating system layer and application. The layers listed denote levels of abstraction to deliver that tier's functionality:

• The presentation tier contains web servers that accept connections from the Internet. In this example, there are no servlet pages, so nothing is denoted in the virtual layer between the web server application and the operating system on which it runs.

• The infrastructure for this layer is dependent on the type of environment into which the web servers are deployed (for example, racks of blades that might include load balancer blades or racks of servers that require additional hardware or software based load balancing).

• The business tier contains application servers that host EJBs. In this case, a virtual layer can be configured to handle stateful failover in concert with load balancing between other application servers in the business tier. The infrastructure considerations are typically similar to those for the presentation tier.

• In the three-tier architecture example, the database tier contains a clustered set of servers, where the cluster resource group virtualizes the operating system from the database service. The infrastructure to enable the database service to move between servers (or domains or containers) often includes additional "cluster hearbeat" networking circuits and connectivity to larger amounts of storage than the other tiers.

In this typical Internet architecture pattern, each tier is typically hosted in a separate set of servers or platforms. The layers listed for each tier denote levels of abstraction to deliver that tier's functionality.

Even in this simplified model, there are many provisioning options for each tier:

• Some service stacks can be completely provisioned with Solaris JumpStart or Solaris™ Flash tools and technologies.

• Some service stacks are known to run only in horizontally scaled environments and can be stored as images that get provisioned onto blades.

• Some service stacks should be split, using one tool for the lower layers and another application provisioning tool for the upper layers.

• Service components can be provisioned individually (one web server at a time) or in groups (for example, five web servers simultaneously).

• Services can be created by provisioning individual service components in turn (first the presentation tier, then the application tier) or in aggregate (all tiers in parallel, then turn on the Internet access service point).

Tiers and layers provide the means to decompose the provisioning space and to choose the appropriate blends of people, processes, and technology for each deployable entity. Using the previously described example tiers and layers, Tables 4-5, 4-6, and 4-7 present possible provisioning scenarios. The shaded areas represent areas that can be addressed with N1 Grid software.

Table 4-5. Presentation Tier Options for the Provisionable Layers

Provisionable Layers	Presentation Tier Options[*]
Application	JumpStart or Flash software for entire stack	Blade image captured or stored	Webserver
Virtual			JumpStart or Flash software for any type of server
Operating system
Hardware	Provision on any type of server	Provision onto blades
Infrastructure

^[*] Shaded areas denote options that can be addressed by the N1 Grid software.

Table 4-6. Business Tier Options for the Provisionable Layers

Provisionable Layers	Business Tier Options[*]
Application	Enterprise Java Bean plus application server in a single N1 Grid SPS Plan	Enterprise Java Bean	Enterprise Java Bean
Virtual			Application server
Operating system	JumpStart or Flash software for any type of server	JumpStart or Flash software for any type of server	JumpStart or Flash software for any type of server
Hardware
Infrastructure

^[*] Shaded areas denote options that can be addressed by the N1 Grid software.

Table 4-7. Database Tier Options for the Provisionable Layers

Provisionable Layers	Database Tier Options[*]
Application	Database	Database Resource Group
Virtual	JumpStart or Flash software for both sides of the cluster on any type of server	JumpStart or Flash software for any type of server
Operating system
Hardware
Infrastructure

^[*] Shaded areas denote options that can be addressed by the N1 Grid software.

The options are presented as illustrative; there are certainly many other possibilities.

Three options are presented for the presentation tier:

• The entire service stack can be provisioned with Solaris JumpStart or Flash software.

• If the provisioning is to occur on Sun Blade hardware, the N1 Grid PS can used to capture, store, and provision blade images onto individual blades.

• The operating system software can be put onto the hardware with Solaris JumpStart or Flash software, and the N1 Grid SPS can be used to provision the web server.

Three options are also presented for the business tier:

• The operating system software can be put onto the hardware with Solaris JumpStart or Flash software, and the N1 Grid SPS can be used to provision the application server and place an EJB into the application-server EJB container.

• The operating system and application server software can be put onto the hardware with Solaris JumpStart or Flash software, and the N1 Grid SPS can be used to provision the EJB.

• The operating system can be put onto the hardware with Solaris JumpStart or Flash software, the N1 Grid SPS can be used to provision the application server, and the N1 Grid SPS can be used to provision the EJB.

There are two options presented for the database tier:

• The entire service stack on both sides of the cluster can be provisioned with Solaris JumpStart Enterprise Toolkit or Flash

• The Solaris JumpStart Enterprise Toolkit or Flash software can provision both sides of the cluster to create a running cluster into which the N1 Grid SPS can provision and register a database cluster resource group.

To be able to automate these provisioning activities, you must understand the individual steps in your current manual provisioning processes. After these steps have been identified, the N1 Grid software is ready to automate and perform many of these common provisioning tasks. Understanding the dependencies and operational activities associated with the entity to be deployed can be captured in use cases, allowing the information needed to be easily identified and extracted for use.

Dependencies and Use Cases

You must check for a good match between the service component about to be deployed and the service container that has been selected to host the service component. The N1 Grid software simplifies this activity by allowing dependency checking to be included as part of the provisioning process. Provisioning activities should be recorded in terms of base-supported use cases, with additional dependency checks during the installation or removal of a resource. These manual use cases can then be expressed in N1 Grid provisioning workflows in preparation for testing the now mobile, newly automated service deployment capabilities.

Issues to protect against include items like installing web servers on a server or in an N1 Grid Container that is already running a web server, if doing so would cause tuning and port conflicts. Other dependency conflict examples include mismatches in licensing cost models where small applications are run as one of many items on a large, multi-CPU server or an attempt to place an application that cannot be clustered into a clustered container environment. Many of the dependencies introduced in the virtualization section in this chapter also apply here. The dependencies of the N1 Grid software provisioning capability act as counterparts to the dependencies of the virtualized N1 Grid Containers, into which the service components can be provisioned.

Resource Managers

Resource management was introduced during the discussion about N1 Grid Containers. Resource managers control the assignment and sharing of resources when multiple service consumers have been deployed into a service container. Typically, a minimum threshold is set for each running process so that a baseline performance level can be guaranteed. In the absence of other loads, running processes can use all of the available CPU, memory, and network resources, but usage is ramped down to the guaranteed level as other loads begin to appear.

Consider adding the assignment of resource manager shares (that is, the fraction of operating system CPU, memory, or I/O allocated) as a part of the provisioning process to provide the appropriate capacity for the entity being deployed. This activity prepares the entity for a mobile environment as multiple applications with unknown workload needs come in and move out of the server on which they were originally provisioned. Having a guaranteed percentage of the CPU, memory, and network resources assists the original deployable entity to maintain a minimum level of service delivery and performance. The naming conventions established can serve as a basis to distinguish the identity of the resource groups that are required for a service.

Security and Trust Models

N1 Grid software is not a shortcut to bypass security. The N1 Grid software does not change the services that run, how they are configured, the protocols they use, or the way in which those configured services might be vulnerable to some particular exploit. It still requires every bit of the security considerations you currently include (or should be including) when you architect, implement, and manage business services. In fact, by capturing golden images and leveraging automation to ensure what is placed into production is an exact copy of what was tested in development, the N1 Grid solution actually helps your security efforts. However, these mobile and flexible stack entities now have several possible roles they can play in N1 Grid solution scenarios and use cases (for instance, provider, consumer, or interested party), so the roles, responsibilities, and policies of the people who run them must be rethought and refreshed. While the goal of this book is not to cover all elements of N1 Grid system security, it is obvious that elements must be added to your enterprise security policy that boost the confidentiality, integrity, and availability of assets before, during and after application provisioning activities. Your defense-in-depth additions should consider these aspects as the allowed procedures check or direct which components can live on the particular resources that might host them, for instance:

• Preventing unauthorized disclosure of sensitive information

• Preventing modification of asset or information accuracy and completeness

• Preventing destruction of information or assets or interruption of service

Concrete examples of some of these confidentiality, integrity, and availability notions include:

• Authentication of all users and other identifiable entities, with unique accountability and authorization schema for access to controlled resources

• Creation of trust models and policies to prevent situations like web server front-ends that accept Internet connections ending up on servers hosting databases that contain sensitive or important data, to avoid tuning (for example, TCP differences between DSS and HTTP sessions) and potential security conflicts (direct Internet connections on back-end databases)

• Operating system hardening (removing unneeded services), minimization (removing unneeded packages), and tuning that are visible to entities about to be provisioned to ensure that they can function and maintain their security in that environment

• Storage zoning or access isolation (created where application provisioning is used in support of mobility and density, as discussed in the following section)

The next section provides guidelines to help you prepare to automate the provisioning of application stacks and to focus on the individual layers, as well as the stack as a whole.