test

N1 Service Provisioning System 4.1 User's Guide

The N1 Service Provisioning System Software Object Model

N1 Service Provisioning System software provides an object-oriented methodology for managing application deployment and configuration. It provides increased visibility and control of the servers, installed applications, and file structures.

The objects are loosely grouped as infrastructure, main, and supporting. Infrastructure objects are things like Users, User Groups, Hosts and Host Sets. Main objects are things like Resources, Components, and plans. Supporting objects are things like Comparisons and Notifications.

Components

A component is a logical grouping of source information (software and/or file structures or other components) that define an application.

The N1 Service Provisioning System software supports two types of components, simple and composite. A simple component is a component that references a single source item. The type of source items that simple component references corresponds to the component's Component Type. For example, a file, a directory of files, a registry key, a COM object, a JavaTM Archive (JAR), an EAR, an IIS website, etc. A composite component is a component that references other components. Composite components can contain any number of simple and/or composite components.

All components, regardless of whether they are simple or composite have the following characteristics in common:

Name

A text field that identifies the component. This includes the path where the component is stored.

Type

A user definable object (Component Type) that is used to control how to handle source information. The component type object is actually another component that manages the acquisition and deployment of source objects such as files, directories, and configurations. The provisioning software comes populated with a large number of component types that support WebLogic and Windows, UNIX® , and some generic models.

Version

The revision number of the component. Each time a component is modified, the repository increments its version number.

Platform

Identifies the platform(s) or operating system(s) that are valid targets for the component's deployment.

Source

Identifies from where the component source information came. This include the path.

Checked in

The date and time when the component was checked in. That is, created or modified.

Checked in by

The user ID of the person who checked in the component. This provides an audit trail when trying to troubleshoot problems or inconsistencies.

Label

A user definable text string that can be used to control the sorting on the components page.

Description

A text string that describes the component object. This attribute is not used by the provisioning software but can provide meaningful information to the user.

For a more complete description of component attributes see Building a Component.

The N1 Service Provisioning System software stores each component along with metadata that contains important information about the component, including how to:

By reading this metadata and comparing components, the provisioning software can identify and track dependencies among components.

Figure 1–2 shows the contents of a component.

Figure 1–2 N1 Service Provisioning System software components include software, templates, and metadata.

>

In addition to this metadata, components include configuration templates that enable IT operators to adjust specific configuration parameters—for example, port numbers—on a server-by-server basis or according to the rules defined in an execution plan. These variables can be set when an operation is performed, rather than being hard-coded in traditional data center scripts.

Component models are written in XML. The object model incorporates features from the Common Information Model (CIM) and from JSR-77, a Java Specification Request proposing a standard management model for J2EE components. Through the N1 Service Provisioning System software console, you can use component templates to quickly customize existing components. You can also author new templates for applications developed in-house. To perform advanced customizations on complex J2EE components, you can edit components through the HTML interface on the console or with an XML editing tool such as XML Spy.

The provisioning software stores components and plans in a secure repository. Using the console, you check components and plans in and out of the repository, run comparisons, and make changes.

To perform a data center operation such as a deployment, you apply plans to components. Through the N1 Service Provisioning System software , every data center operation incorporates all the knowledge available about each component. Errors are automatically detected. Missing information is flagged. Through automation, deployments and configuration changes become faster and more accurate.

The Component Library

N1 Service Provisioning System software makes it easy for IT operators to begin using component models right away. The Master Server includes a component library with templates for the most common components used in Internet data centers. Table 1–2 lists the templates included in the library.

Table 1–2 Templates in the Component Library

Application Component Templates 

Simple Files and Directories 

J2EE Enterprise Archive (EAR) 

J2EE Web Archive (WAR) 

J2EE Java Archive (JAR) 

Solaris Package 

Solaris OS Patch 

IIS Web Site or Virtual Directory 

COM+ Application 

COM Component 

MSI Application 

Windows Registry Keys 

Windows Data Source 

.Net Application 

ASP .Net Application 

Web Server Templates 

SunTMONE /iPlanetTM (admin with managed instances)

Apache Web Server 

Microsoft IIS (with Metabase settings) 

Application Server Templates 

BEA WebLogic (admin with simple, managed, and clustered instances) 

IBM WebSphere (admin with simple and cloned instances) 

Microsoft Component Services/COM+ 

Microsoft Transaction Server (MTS) 

In addition to working with these components, the provisioning software can coordinate activities with standard databases, load balancers, and operating systems as part of deploying, configuring, and analyzing applications. Table 1–3 lists the databases, load balancers, and operating systems that can be acted upon.

Table 1–3 Databases, Operating Systems, and Load Balancers that can be acted upon

Databases 

Oracle Enterprise 

Microsoft SQL Server  

Supported Operating Systems 

SolarisTM 6, Solaris 7, or Solaris 8 releases

IBM AIX 4.3.x, 5.1, 5.2 

Red Hat Linux 7.2, 7.3, 8.0 

Red Hat Advanced Server 2.1 

Microsoft Windows Server 2000 

Load Balancers 

Nortel/Alteo WebSystems ACEdirector 

Foundry ServerIron 

Plans

Just as it captures information about applications in component models, the N1 Service Provisioning System software stores information about data center procedures in plans. A plan is an XML document containing a sequence of instructions used to manipulate one or more components or calls to other plans. Plans can encode this information explicitly, or they can leave some details, such as specific server names and port numbers, for the IT operator to specify at run time. When the provisioning software runs a plan, it reads component models for details about configuration requirements, dependencies, and instructions for performing specific operations, such as installing a particular set of files and setting permissions on a directory.

N1 Service Provisioning System software uses plans to:

There are two types of Plans, simple and composite. Simple plans contain a sequence of instruction that is performed on the target host or hosts unilaterally and cannot call other plans. Composite Plans can only call other Plans so that each step in a multi-step deployment—shutting down an application, removing servers from a load balancer, etc.—can be managed by its own carefully written plan.

For example, a plan to roll out a multi-tiered application might consist of four sub-plans:

The rollout plan itself would coordinate activities among the sub-plans and servers. For example, running this plan on a cluster of 10 servers, the N1 Service Provisioning System software would ensure that each subplan had completed successfully and all ten servers were synchronized before proceeding with the next subplan.

Inserting variables in components, plans, and sub-plans gives operators fine-grained control over data center operations. For example, a component can be configured to include a variable for a port number. A plan can assign a value for this variable. Alternatively, the IT operator can assign a value for variable (overriding the value specified in the plan) through the CLI or the HTML interface. Variable settings can be applied to sets of hosts or individual hosts.

By providing a common format for execution plans, the provisioning software replaces the chaotic variety of script formats and languages found in most data centers. Rather than trying to understand the contents of a hastily written script, operators can select the plans they need from a central, version-controlled repository.

Built-In Procedures vs. Plans

The N1 Service Provisioning System software automatically generates procedures for many operations, such as installation and un-installations, for the most common types of components. If your deployments involve installing one component at a time on a single set of hosts, you can use these built-in procedures and never have to author a plan.

Use plans, rather than built-in procedures, if you want to:

Hosts

The N1 Service Provisioning System software makes it easier to manage servers or hosts by modeling them as objects and storing the model in the host database. The provisioning software enables you to define host types, so you can classify hosts by their configuration or function. The software also enables you to create host sets–groups of hosts that you can manage as a single unit. Host searches enable you to dynamically group hosts based on current attributes. These host management functions, combined with the component and plan objects described above, significantly reduce the complexity of deploying, configuring, and analyzing applications in data centers. To enable the provisioning software to work with a host it must have a Remote Agent installed, registered in the database, and prepared by the provisioning software for use. Hosts that have gone through all of these processes are also called Nodes. For more information on Hosts see Chapter 4, Hosts.

Object Attributes

All of the N1 Service Provisioning System software objects have many attributes that either serve to identify the object such as its name, to classify it in some way, provide revision tracking, define grouping, hiding, and so on. Some attributes are unique to a specific object while others are available for some or all of the objects.

Categories

The N1 Service Provisioning System software includes a built-in category called system, which is automatically applied to internal resources. All other categories are user definable. As with naming conventions, careful planning should go into defining categories. When category naming conventions are well thought through they become powerful tools when used with searches and views to quickly identify or select groups of objects. Categories for each object are discussed in more detail in the sections relating to each particular object.

You can use categories to classify:

Show/Hide

Over time these objects may become obsolete. To reduce the visual clutter you can hide unwanted objects so that they are not shown by default on web pages or listed by CLI commands. It is also possible to delete most of the objects.