|Oracle® Virtual Assembly Builder User's Guide
11g Release 1 (18.104.22.168)
Part Number E22514-03
|PDF · Mobi · ePub|
Increased operating costs, inefficient hardware utilization and rapidly expanding data centers have made virtualization the most compelling IT technology in years. Virtualization for desktop and server environments has evolved to finally deliver on its promise to lower operating costs by increasing the utilization of hardware and reducing the overall amount of hardware required.
While virtualization has solved a multitude of problems, it is still difficult to deploy and manage complex applications made up of multiple tiers and components. Furthermore, virtualization is quickly becoming a commodity and the focus now shifts to directly virtualizing applications to reap the next level of benefits associated with virtualization.
Virtualization is the process of abstracting hardware resources, such as CPU, memory, storage, and network interfaces, from the operating system and applications. The hardware runs virtualization software (for example, a hypervisor) that enables the installation of multiple operating systems, each capable of running simultaneously and independently, in its own secure physical environment.
The goal of virtualization is to make deployment of complete environments faster, easier, and more efficient. Virtualization's capabilities must be integrated to facilitate deployment and management of complete stacks. Virtualization must enable the entire stack to be easier to deploy, manage, and support.
Figure 1-1 Virtualization
The development and deployment of applications in your virtualized environment involves a sequence of operational stages including testing, staging, and production. The transition between these stages can be difficult as there are few facilities within existing virtualization infrastructure that guarantee consistency and correctness of the collection of software components. Implementing the physical to virtual (P2V) or virtual to virtual (V2V) transitions seems simple: create virtual images of the original deployments, then instantiate them in the target environment. Oracle VM can be used to implement such solutions.
Handcrafting the virtualization solution has many pitfalls. Details of network connectivity may change in the deployment environment, but no automatic mechanism exists to perform or even to track these changes. Images may be specific to particular details of the deployment environment. The proliferation of images results in sprawl, creating maintenance overhead as each of the images must be patched at the operating system and application layers. These pitfalls create unanticipated costs.
Oracle Virtual Assembly Builder is a tool for virtualizing installed Oracle components, modifying those components, and then deploying them into your own environment. Using Oracle Virtual Assembly Builder, you capture the configuration of existing software components in artifacts called software appliances. Appliances can then be grouped, and their relationships defined into artifacts called software assemblies which provide a blueprint describing a complete multi-tier application topology.
Oracle Virtual Assembly Builder allows the logical connections between appliances within an assembly to be reconfigured by a process known as assembly editing. When a desired assembly configuration has been achieved, you use Oracle Virtual Assembly Builder to prepare the assembly for deployment and then deploy it into your environment. The components and processes are described below.
Figure 1-2 Oracle Virtual Assembly Builder
A software assembly (assembly) is a collection of interrelated software appliances that are automatically configured to work together upon deployment. Assemblies are deployed onto a pool of hardware resources with minimal user input.
While assemblies are simply a collection of appliances with defined interconnects, assemblies must provide a set of capabilities in order to be useful in a production environment, including:
Allow for the composition of appliances as well as external systems
Externalize configuration in the form of metadata that can easily be customized
Optionally define the start order of appliances to reflect interdependencies
Provide a management domain which integrates into existing management infrastructure allowing for metadata definition, deployment, oversight and diagnostics
In addition to being comprised of appliances, assemblies can also contain references to external systems. This is necessary to represent infrastructure such as databases, servers or security providers that cannot or should not be included in an assembly.
To summarize, the notion of being able to create pre-built assemblies for deployment is extremely powerful and has a number of advantages that drive down operational costs and complexity. These include:
Ability to easily replicate assemblies in production, even allowing for variations of the assembly without adding complexity
Reduced risk of configuration errors as assemblies are moved between development, test and production environments
Replicated environments facilitate high-level standardization and consistency across application infrastructures, allowing for simple implementation of best practices.
Accelerated deployment of new infrastructures and applications
In order to realize these benefits, a simple means of composing assemblies of appliances is required. Specifically what is needed is tooling that allows for the composition of appliances as well as endpoint mapping of externalized systems and other larger non-virtual appliance-based systems such as databases and identity management servers.
Oracle Virtual Assembly Builder includes an intuitive visual environment, command line interface, and supporting infrastructure. Oracle Virtual Assembly Builder enables administrators to construct and deploy complete assemblies encompassing all of the components and systems that make up a potentially complex application structure or infrastructure.
Oracle Virtual Assembly Builder provides the following capabilities:
Ability to browse a catalog of existing appliances and assemblies allowing for simple re-use of existing infrastructure
Ability to modify connections between appliances using drag-and-drop
Ability to create templatized definitions of complete configurations, allowing for simple deployment
Single-step deployment of virtualized multi-tier applications onto a pool of virtualized resources
Figure 1-3 Virtualized Multi-Tier Applications
Assembly creation and deployment is a straightforward, four-step process. First, in the introspect phase, the necessary metadata and configuration information is captured from an existing deployment for all components that make up the appliances within an assembly. During the configure phase, the relationships are established among the appliances and any external resources. The prepare phase creates the deployment artifacts necessary for the assembly that is relevant to the particular virtualization platform (that is, virtual images). Finally, the deploy phase deploys the assembly into your environment.
In the introspect phase, you capture configuration metadata for individual software components, or collectively capture metadata for multiple distributed components. Target components may reside locally or remotely on multiple distributed systems that may be physical or virtual.
In the configure phase, you:
Visually drag-and-drop components for creating complex assemblies using appliances maintained in a navigable catalog
Establish relationships and connections between appliances using a wiring tool that automatically checks for protocol compatibility
Create connections from appliances to external resources (such as database, security provider, messaging, and so on) not included within the assembly
In the prepare phase, you:
Create bootable virtual machine disk images with customized Oracle Enterprise Linux operating system distributions and configurable metadata allowing for deploy-time customization of the software component
In the deploy phase, you:
Create customized deployment configurations for assemblies that override base configuration properties for the appliances within the assembly
Accommodate late-binding appliances automatically through deployment-specific customization
Stage all appliance disk images and deploy entire assemblies onto targets in a single step
Scale appliance instances after initial deployment of an assembly and automatically wire the newly deployed instances into the existing assembly
Oracle Virtual Assembly Builder captures the existing condition of a specific set of Oracle Fusion Middleware and Oracle Database software components from your environment, represents them as assemblies and appliances, and enables their deployment into your environment. Oracle Virtual Assembly Builder does not include the ability to administer the components and does not replace the administrative tools supplied with them.
Oracle Virtual Assembly Builder does not supply the virtual environment into which you deploy your Assemblies. You must establish the deployment environment using one of the target environments that Oracle Virtual Assembly Builder supports. For more information about supported deployment environments, see Oracle Virtual Assembly Builder Installation Guide.
Oracle Virtual Assembly Builder consists of two major product components:
Oracle Virtual Assembly Builder Studio provides you the capabilities to perform the first three phases of the assembly creation, the introspect phase, configure phase, and prepare phase. Oracle Virtual Assembly Builder Studio allows you to create and edit the assemblies, create assembly archives, and create templates and deployment plans which support deployment from Oracle Virtual Assembly Builder Deployer.
Oracle Virtual Assembly Builder Deployer is a J2EE application that maintains a repository of assembly archives created by Oracle Virtual Assembly Builder Studio. The Deployer provides operations for registering these assembly archives to virtualized systems such as Oracle VM and provides operations for orchestrating the deployment of the software system defined by the assembly archive.
The interface to Oracle Virtual Assembly Builder Deployer is a Web service which provides operations for uploading assembly archives, registering the assembly archive virtualization system and managing assembly instances for the system defined in the assembly archive. See Oracle Virtual Assembly Builder Developer's Guide for a description of the Web service.
A minimal appliance consists of metadata (name and value pairs) describing the condition of the original component, together with a set of component-specific files that allow its configuration to be recreated at deployment time. As you use Oracle Virtual Assembly Builder to prepare an assembly for deployment into your environment, additional configuration information is created and stored along with the metadata.
The appliance metadata includes a description of each of the component's logical inputs and outputs. These inputs and outputs are collectively called endpoints. The HTTP input of an Oracle HTTP Server component is an example of an input endpoint. The
mod_wl_ohs output of the same Oracle HTTP Server component is an example of an output endpoint.
The metadata describing endpoints includes protocols, port numbers, URLs, and so on. Oracle Virtual Assembly Builder captures enough information about each endpoint to allow the connection to be updated after the component is captured and before it is deployed. This capability allows Oracle Virtual Assembly Builder to ensure that the appliances will connect correctly within the deployment environment.
Appliances are grouped into assemblies. An assembly is a logical container for the appliances and the connections between them. You create assemblies using Oracle Virtual Assembly Builder and populate them with the appliances and the other assemblies (assemblies may contain other assemblies).
The process of capturing a software component from your environment as an Oracle Virtual Assembly Builder appliance begins with introspection.
Introspection is an operation performed on a software component or a group of related components (to create an appliance or assembly). During introspection, Oracle Virtual Assembly Builder creates an xml description of the component and captures a component-specific set of configuration files. This information forms a snapshot of the component's configuration at the time of introspection. The introspection architecture is plug-in based and there is a plug-in for each supported component type. See Appendix B, Oracle Virtual Assembly Builder Introspection Plug-ins for more information about available plug-ins.
In most cases, the result of introspecting a component is an appliance. When you use Oracle Virtual Assembly Builder to introspect an Oracle WebLogic Server domain, however, the Introspector plug-in generates an assembly. The generated assembly contains an appliance representing the domain's Administration Server and other appliances representing each of the domain's Managed Servers.
Oracle Virtual Assembly Builder can introspect components on a local host or components located on remote, network-accessible hosts. Oracle Virtual Assembly Builder uses the industry-standard SSH protocol to transport the introspection engine to the remote host and to return the introspection results.
Whether the introspection is local or remote, the results are stored locally in the catalog.
External appliances are virtual machine templates, created using non-Oracle Virtual Assembly Builder tools, that you import into your Oracle Virtual Assembly Builder installation. Once imported, the external appliance participates in all Oracle Virtual Assembly Builder operations, with certain limitations that result from the lack of introspection metadata. External appliances can be edited, added, and deployed as part of any assembly as you would any other appliance. Only Oracle virtual machines are eligible to be imported as external appliances at this time.
Use the abctl
importExternalTemplate command to have an assembly template (created outside of Oracle Virtual Assembly Builder) captured in your catalog as an external appliance. For more information on using this command, see Appendix A, Command Line Reference.
Appliances constructed using the appliance type called "GenericProd". These type of appliances do not make use of product-specific logic to capture configuration or product location, instead a simple appliance is created and a set of user-supplied properties, paths, and scripts that make up the product are added to it in a generic manner. Also it does not make use of any product-specific logic to configure and start the product upon deployment, instead the set of scripts passed in at creation are executed at deployment to perform the necessary operations.
This allows user to create and deploy an opaque, standalone, and self-contained product or application as an appliance for which Oracle Virtual Assembly Builder does not have built-in support.
Assemblies and appliances are represented on disk in an area called the Catalog. Assembly and appliance metadata is stored in nested directories within the metadata subfolder of the catalog root directory. Additional artifacts required for deployment are stored in other subdirectories defined by Oracle Virtual Assembly Builder. Since some of the on-disk artifacts may be very large, the catalog uses a sharing model for some artifacts of appliances and assemblies.
Only Oracle Virtual Assembly Builder-supplied tools should be used to operate on the catalog. Manually editing Oracle Virtual Assembly Builder metadata files is not supported.
When defining an assembly, it may be necessary to make reference to servers that lie outside it. Your IT environment may, for example, include database, identity management, or other servers that are shared by many unrelated virtual deployments. It may be undesirable or impossible to include these systems within any specific assembly. For this reason, Oracle Virtual Assembly Builder enables you to define external components representing server resources that exist in your environment and will not be deployed as appliances. Representing them as external resources ensures that referencing appliance(s) within the assembly are correctly configured at deployment time, making it unnecessary to manually correct their network configuration after they are deployed to the virtual environment.
The introspection process captures the condition of a component and generates a metadata description of the actual component installation. Introspection does not capture the executables, shared libraries or other binaries of the component. Instead, introspection generates file set definitions that specify one or more file system hierarchies that must be captured to reproduce the same component installation in the deployment environment. By default, after the introspection is complete, Oracle Virtual Assembly Builder automatically captures a copy of the actual installation described by the metadata. This step is known as capturing file sets.
By default, introspection and capturing file sets are done together whether you use Oracle Virtual Assembly Builder Studio or Oracle Virtual Assembly Builder command line interface. Optionally, you can choose to do these steps separately.
The assembly archives created by Oracle Virtual Assembly Builder Studio contain information about a software system composed of multiple, related software stacks which work together to form an application. This system is referred to as an assembly. The assembly archive contains metadata about the assembly and assembly templates that are used to instantiate an instance of the assembly in a virtualized environment.
You can configure a file set as shared or local. If supported by the underlying infrastructure platform, you can specify that file sets be shared with individual appliances within assemblies.
The assembly archive defines a set of logical networks for the application it represents. For each appliance, the assembly archive also defines one or more network interfaces. Each network interface is associated with one of the archive's networks, allowing the assembly archive to fully represent the network connectivity requirements of the assembly.
The deployment plan specifies a network in the virtualization environment to be used for each logical network declared in the assembly archive. The model supports the configuration and binding to both public and private networks (where private is defined as existing between two appliances in an assembly and not surfaced as part of the public network for access to the deployed application topology.)
The Deployer creates and attaches one or more Vnets to the virtual machines it creates using the underlying interfaces of the virtualization system. Note that these Vnets are hypervisor-level Vnets, as opposed to virtual machine-level Vnets. If the virtualization system supports it, the Deployer may also dynamically create private networks to associate these Vnets with.
An assembly template is a set of virtual disk images that can be used to create and start new virtual machine instances. A template is created for each appliance in an assembly, consisting of a guest operating system, the appliance's file sets and metadata, and supporting Oracle Virtual Assembly Builder infrastructure. Templates are made available to the virtualized environment by registering them to that environment, at which point virtual machine instances can be created based on the templates.
Oracle Virtual Assembly Builder supports Oracle Enterprise Linux as the virtual machine guest operating system.
Deployment plans are used to customize assemblies prior to deployment. You can create a deployment plan in which you customize default assembly and appliance properties, and provide deployment-specific information such as network configuration. In some cases you may be required to customize certain properties in order to proceed with a successful deployment (for example, static IP address, or password properties).
This section describes Deployer concepts.
Different virtualization systems organize their resources in different ways and require different information for referencing and accessing them. In order to provide a common user experience across different systems, Oracle Virtual Assembly Builder Deployer defines the notion of a target. Targets are configured using administration interfaces defined later in this document and are used to reference a resource or pool of resources in the virtualized system. The configuration information provided for each target is specific to the virtualization system containing the target.
Oracle Virtual Assembly Builder Deployer supports Oracle VM and Oracle Exalogic. Oracle Exalogic comes pre-configured with a single target.
An assembly instance is a deployable instance of an assembly archive for a specific target virtual environment.
An appliance instance is an instance of an appliance running and/or created in the target virtual environment.
After you deploy an assembly instance, the target number of appliance instances for each appliance is started. The initial target for each appliance is specified in the deployment plan. You can dynamically specify a new target after an assembly instance has been deployed.
An assembly instance is a deployable artifact. You would need to create an assembly instance by selecting an assembly, one of the its deployment plans and the target to which it must be deployed to. CreateAssemblyInstance can be used to create the assembly instance.
At deployment time, you choose the assembly instance to be deployed.
Deployment of an assembly instance will transition through various phases (Figure 1-4). The phases include: Staged, Deployed, and Failed. Each state allows a subset of operations. For example, when an assembly instance is deployed, you may start and stop the appliance instances, or you may increase or decrease the number of appliance instances associated with that deployed assembly instance. Oracle Virtual Assembly Builder does not monitor the health of the deployed application; it will only inform you of whether or not an assembly is deployed or staged, as well as the success or failure of a deployment-related operation.
Figure 1-4 Deployment Life Cycle
Here is a summary of the assembly instance phases:
Deployed When the assembly instance is deployed and the operation has successfully completed, it reaches the deployed state. The operations that can be performed on a Deployed assembly instance are:
StopAssemblyInstance This operation will shut down all the running appliance instances for the assembly instance. The assembly instance is transitioned to the Staged phase after this operation is completed. It leaves the appliance instances in the virtualized environment so that they can be restarted later.
UndeployAssemblyInstance This operation will stop all the running appliance instances and remove them from the environment. After this operation is completed, the assembly instance will kept in the system so that it can be deployed again.
RestartAssemblyInstance This operation will restart all the running appliance instances of the assembly instance. The assembly instance will transition to the Staged and then transition back to Deployed.
RedeployAssemblyInstance This operation will redeploy the assembly instance. As part of this operation all appliance instances will be stopped and removed from the target environment. New appliance instances will be created and started.
Scale Scales the scaling group within an assembly instance. Scaling can be performed to scale up or down a scaling group with the assembly instance. The number of appliance instances that can be running for a scaling group must lie between its configured minimum and maximum instance limits. The Deployment continues to remain in the Deployed state.
Failed When there is a failure in a deploy or undeploy operation, the assembly instances reaches this phase. A deployment operation may fail for a variety of reasons, such as insufficient resources. The operations that can be performed on a failed deployment are:
DeleteAssemblyInstance This operation will do the necessary cleanup (such as stopping and removing the appliance instances). After this operation is completed, the assembly instance no longer exists.
Staged The staged phase is reached by stopping an assembly instance. In this phase all the appliance instances have been shut down. The operations that can be performed from this phase are:
StartAssemblyInstance This operation will start up all the appliance instances that have been shut down. After this operation is completed, the assembly instance is returned to the Deployed state.
UndeployAssemblyInstance This operation will remove all the appliance instances that have been shut down from the virtualized environment. After this operation is completed, the assembly instance will be kept around so that it can be deployed again.