PureApplication Deployment Models
This chapter describes the deployment models that are available in IBM PureApplication System. It explains their main features, topologies, and the tools of each model. This chapter also describes implementation strategies so you can determine the best model for your application migration or create a new one. The main offerings of PureSystems Centre also are covered in the final section.
The following topics are covered in this chapter:
4.1 Introduction
Before IBM PureApplication System deployment models are described, it is important to introduce some initial concepts that are behind the PureApplication System architecture principles, as shown in Figure 4-1.
Figure 4-1 IBM PureApplication System architectural principles
IBM PureApplication System architecture is based on the following principles:
•Built-in expertise: Capture and automate what experts do when infrastructure and application expertise enhance application time to value.
•Integration by design: Deeply integrate and tune hardware and software.
•Simplified experience: Make every part of IT lifecycle easier by using an integrated management and an open solution ecosystem to broaden choices.
This section focuses on the Built-in expertise feature. One of the concepts within this feature is the Patterns of expertise that are proven best practices. These patterns are a collection of expertise that is gathered from solving complex tasks. This expertise was developed over decades of captured client and partner engagements, lab tested, and optimized into a deployable form.
A pattern is a model of deployment. IBM provides predefined deployment models with settings that are based on years of experience. These models include the following features:
•Pre-defined architecture of an application
•Each component of the application (such as the database or web server) has the following features:
– Pre-installation of an operating system
– Pre-installation across components
– Pre-configured and tuned
– Pre-configured monitoring
– Pre-configured security
– Lifecycle management
These features are packaged in a deployable form. This design results in a repeatable deployment with full lifecycle management and delivers the following results:
•Agility: Faster time to value
•Efficiency: Reduced costs and resources
•Simplicity: Simpler skills requirements
•Control: Lower risks and errors
There are three main pattern types with distinct IT domains, as shown in Figure 4-2.
Figure 4-2 Three types of patterns
The following main pattern types are available:
•Infrastructure Patterns
An automated, policy-driven infrastructure management approach across compute, storage, and networking resources. According to customer feedback, 60 - 70% of IT expenses are wasted in infrastructure management. Infrastructure patterns reduce operational expense by using an intelligent resource allocation and management.
•Platform Patterns
A pre-configured and policy-managed platform. This platform’s capabilities, such as caching, failover, load balancing, and security monitoring are combined with an application server, database, and messaging middleware. Applications require fast deploy and must efficiently manage platform capabilities to respond to business agility needs. Examples of this type of pattern are Web Application, DB2, and Business Process Manager (BPM).
•Application Patterns
A predefined application architecture and corresponding platform services that are deployed and managed according to a set of policies. The value that is gained is the ability to rapidly and easily deploy a complete application, which reduces risks. One example of this pattern type is the SAP CRM pattern that provides specific set of policies that, when configured in advance, save time and costs and can be deployed into the cloud at any time.
IBM PureApplication System provides different patterns or deployment models according to business needs. As shown in Figure 4-3, there are three deployment model types.
Figure 4-3 PureApplication System deployment models
Virtual appliances are the most generic type of deployment. They can be used to deploy any generic Open Virtualization Format (OVF) file to the IBM PureApplication System catalog and into a cloud. Though you have complete control over the image content, IBM PureApplication System is unaware of the internal features of this image. From the PureApplication perspective, the image is a black box.
The PureApplication System provides basic execution services such as stopping and starting the virtual machines where your image is deployed. It can be observed that you have more flexibility to build product images; however, it uses a few capabilities of IBM PureApplication System and it can be an intense labor activity that increases resource time, effort, and costs. An example of this approach is COBOL images that must be deployed by using this model. The PureApplication System also provides basic image management functions from the image catalog in the workload console for virtual appliances.
For business use, there are other styles of deployment models that are optimized for labor savings. These deployment models are virtual systems and virtual applications.
4.1.1 Virtual systems
The virtual systems deployment model uses IBM’s hypervisor edition images. The hypervisor edition images are a set of virtual images that use VMware ESX hypervisor technologies with preinstalled middleware. By using this feature, you can define your topology as a pattern, customize it with script packages and other add-ons that represents your application customization, and deploy the designed pattern into the cloud. This model provides rich customization capabilities and allows fast, automated provisioning of IBM middleware that is based on the specific topology that you defined. You define the virtual machine images, the software components that are installed on them, the script packages that run to configure them, and any monitoring agents that you want them to include.
For example, you can define a virtual system pattern as a multi-node WebSphere Application Server topology that contains a deployment manager, one or more custom nodes, and an IBM HTTP Server. After you have that topology defined as a pattern, PureApplication System provisions that pattern for you with minimal effort on your part. That pattern can then be deployed multiple times with the same results each time as the deployment is fully automated.
IBM also provides a set of patterns that follow proven best practices that are based on years of experience that guarantees high reliability. You can use those patterns that are available from the product catalog or use them as a starting point for your own patterns, customizing them as needed. You also can create your own custom images to be deployed as virtual systems by using the IBM Image Construction and Composition Tool. This tool is useful for the cases where you need an image that contains middleware where IBM does not provide a hypervisor edition image and for vendor software you want to deploy.
The virtual systems deployment model is middleware-centric and does require you to configure the middleware. This model is designed to provide automated middleware provisioning. Virtual systems and virtual appliances have flexibility but differ in that virtual systems provide more labor savings.
4.1.2 Virtual applications
While virtual system patterns focus on the topology, virtual application patterns (as the name implies) take an application-centric approach. With virtual system patterns, you describe a middleware topology and IBM PureApplication System builds that topology in the cloud. With virtual application patterns, you describe an application and IBM PureApplication System builds the appropriate infrastructure and deploys the application to it. IBM PureApplication System then manages the lifecycle of the application, including growing and shrinking the resources that are needed to satisfy specified service levels. The virtual applications model is fully automated and is similar to the virtual systems deployment model but adds integrated lifecycle management. IBM PureApplication System includes a set of preinstalled web applications, database patterns, and Java patterns. You can also create your own patterns from your own design or by using a supplied pattern as a template. In system management scope, IBM PureApplication System manages the middleware that is needed to run those applications and determines the topology that is based on your artifacts and any policies you specify.
By using the virtual applications model, you have less flexibility than the use of virtual appliances or virtual systems. However, you can deploy your application quickly and easily. More information about these models and best practices is available in the rest of the chapter.
4.2 Trade-offs between control against total cost of ownership and total time to value
This section provides a comparison between deployment models from the business perspective in terms of total cost of ownership (TCO) and total time to value (TTV) business variables. Deployment models and more information about these variables are shown in Figure 4-4.
Figure 4-4 Deployment models comparison between TCO and TTV
Figure 4-4 shows that customization and control are high by using the virtual appliances model. However, there are significant increases in terms of TCO and TTV. The following factors contribute to the increases in resource costs when the virtual appliance model is used:
•Responsibility for standard software installation of middleware, applications, operational system level configuration, and image creation for deployment.
•Responsibility for all infrastructure updates to the image. IBM PureApplication System is unaware of what the image contains and runs only steady state activities, such as stop, start, and recycle. You have total control.
•Specialized team is needed to maintain the solution.
The virtual appliances model can be a useful solution, though the model does not use the potential of IBM PureApplication System and therefore reflects an increase in costs and time. When IBM PureApplication System does not provide the level of customization that is needed and you must move to a cloud environment as quickly as possible, the virtual appliances model is an option. As an example, with little effort you can package an existing, matured, market-tested COBOL application as a single-image virtual appliance, which immediately becomes deployable into the cloud.
Moving to virtual systems, you can save time and ownership cost by relying on IBM pre-built hypervisor edition images. These pre-built images support many product capabilities, such as WebSphere, IBM HTTP Server, and DB2. You still can customize your topology deployments through image extension, define the specific topology and middleware levels for your application, or use script packages to customize specific components as needed. Examples of these options include a WebSphere Application Server Cluster pattern that contains IBM Deployment Manager, one or more custom nodes, IBM HTTP Server, and configuration scripts for installing applications to the topology.
Administration scope is business as usual with the products you deploy. For example, with WebSphere Application Server, you can use the administration console or wsadmin command and the capabilities that are available to you in the PureApplication System administration console. This configuration allows for quick deployment of highly customized middleware, which reduces TTV. The cost of ownership also is reduced considerably when you rely on IBM to maintain the product images.
Looking at virtual applications, as shown in Figure 4-24 on page 142, you reduce the TCO and TTV even further because the solutions are pre-built and integrated for a specific use case. Core components of the pattern include web applications, databases, queues, connections to existing resources, business process models, batch jobs, and mediations. Core policies of the pattern include high availability, service level agreements (SLAs), security, multitenancy, and isolation.
Instead of defining topologies, you provide your application artifacts, and PureApplication System determines the appropriate underlying topology that is based on the SLA that you provide. While the use of the virtual application deployment model is the most cost-effective option, its high level of standardization and cross-product integration results in fewer product configuration options that are exposed for customization. For instance, with WebSphere Application Server deployments, you do not have access to the administrative console. Instead, you have a limited set of customizations that are available to you through the PureApplication System workload console.
4.3 Virtual Appliances
Virtual appliances are a key component of the cloud deployment model. A virtual appliance is a prepackaged software stack that combines the operating system, middleware, and applications in one package. Virtual appliances facilitate a quicker transition to cloud and require much less installation and configuration than traditional deployment methods. Virtual appliances address key issues to cloud computing, software licensing, and standardization, and it applies to traditional independent software vendors (ISVs) and software as a service (SaaS) providers.
Virtual Appliances include the following main features:
•You can create a virtualized environment for middleware that is not provided by IBM (for example, create a new virtual image for the Tomcat Server).
You can easily host other software packages on the same shared cloud resources to which you deploy IBM middleware.
•You can extend an existing image that is provided by IBM to add software to the image.
•You can extend the use of the virtual appliance beyond what is provided in PureApplication System by adding a custom image to your virtual system pattern.
You often define templates and assemble parts to configure a system to deploy and then generate a file from that data. By using PureApplication System virtual appliances, you skip the creation steps and instead begin with a defined file. You can deploy that file repeatedly and create multiple virtual appliance instances from a single virtual appliance. You can supply some override values for properties in your deployments.
You also can add Virtual appliances to the catalog and deploy them directly into the VMware ESX cloud, as shown in the following examples:
•You can take an existing matured, market-tested COBOL application and with little effort, package it as a single-image virtual appliance, which immediately becomes deployable into the cloud.
•You can package a newly implemented, highly distributed, service-oriented application and integrate with the services that are provided by the cloud. This ability allows ISVs to respond more rapidly to their customer's changing business needs with flexibility and agility.
For more information about administering virtual appliances, see this website:
To create an image, you can use the Image Construction and Composition Tool. This tool is available for download from the PureApplication System on the Welcome page of the workload console. For more information, see Chapter 5.3, “Build virtual images by using the IBM Image Construction and Composition Tool” on page 213.
4.4 Virtual Images
Virtual images that are used by IBM PureApplication System are Open Virtualization Format (OVF) compliant images with special activation logic to help in deployment. There are a growing number of these virtual images for IBM Software products, which are named Hypervisor Editions.
The most fundamental of building blocks for virtual system patterns are parts that are delivered with hypervisor edition images. The following sections describe the content (hypervisor edition images with composing elements, and the parts that are used to deliver those elements and images). For more information about virtual system patterns, see 4.5, “Virtual Systems” on page 121.
4.4.1 Hypervisor edition images
A hypervisor edition image is the delivery of some middleware product that is packaged according to the OVF in an Open Virtualization Archive (OVA) file. These images are imported into a virtual image catalog within IBM PureApplication System.
A hypervisor edition image consists of some middleware product (such as WebSphere Application Server) that is preinstalled and pre-configured with an operating system (often Linux or AIX), and is designed for virtual environments. As an example, for the WebSphere Application Server, the following the virtual image includes the following features:
•An operating system
•WebSphere Application Server
•IBM HTTP Server binary files
•WebSphere Application Server profiles
•A combination of code and tuning that is built into the image to optimize the server for a virtual environment
To view virtual images on the IBM PureApplication System workload console, select Catalog → Virtual Images, as shown in Figure 4-5.
Figure 4-5 Browse to virtual images
Selecting this option displays the virtual images in the IBM PureApplication System catalog, as show in Figure 4-6.
Figure 4-6 An example of loaded Virtual Images
The following preinstalled virtual images for the IBM PureApplication System offering are available:
•IBM WebSphere Application Server Hypervisor Edition virtual images
A set of IBM WebSphere Application Server Hypervisor Edition virtual images for VMware ESX hypervisor technologies.
•IBM OS image for Red Hat Linux Systems
IBM OS image for Red Hat Linux Systems in the system catalog. They provide the operating environment on which workload patterns run, including the operating system and infrastructure that is unique to the product.
•DB2 Enterprise virtual image
IBM DB2 Enterprise 9.7 Fix Pack 6 and 10.1 in the system catalog.
Figure 4-7 shows the Hypervisor edition images.
Figure 4-7 Overview of a Hypervisor Edition Image
For more information about virtual images, see this website:
Hypervisor edition image elements
The hypervisor edition image features the following main elements:
•Preinstalled and pre-configured image
•Image-specific tuning
•Fast deploy-time activation capabilities
All of the elements, operating system, middleware, middleware dependencies and feature packs, and necessary maintenance for all elements are preinstalled into the image. You do not need to install the middleware, an operating system, or develop a script to perform any installation task. The process is handled automatically by using the hypervisor edition image.
Because IBM is preinstalling middleware and the underlying operating system, the image is tuned for best practices and optimal performance in a virtual environment. It is fast when deploying images because the installation and optimization is done already. All that is necessary to do during deployment is to refine the configuration and run some activation logic. Maintenance also is simplified because it is available as fully installed images for the complete solution.
4.4.2 Parts of hypervisor edition image
The elements of the middleware are delivered in the hypervisor image as parts. For example, the WebSphere Application Server Hypervisor Edition image includes parts for the deployment manager, custom node, stand-alone node, and job manager. Having these common profiles pre-configured in the image again saves significant deployment time when compared with traditional deployment processes where profile creation is done later by scripting.
Detailed middleware configuration and provisioning for specific purposes is handled by an activation agent. While the preinstallation, configuration, and tuning are strengths, you can consider activation the real power of the hypervisor edition image.
For WebSphere, the activation capabilities support having this one image transform into different WebSphere Application Server configurations when it is started. This capability enables one template image to be copied and quickly reconfigured for rapid provisioning of different WebSphere Application Server environments. This task is accomplished through an activation code that is included within the image that reads input parameters, maps these parameters to different pre-configured profiles, and performs reconfiguration tasks.
During activation, reconfiguration scripts inside the image complete the following tasks:
•Inject the new network settings for IP address, host name, passwords, and so on.
•Reconfigure WebSphere Application Server parameters for cell name, node name, and so on.
•Start the WebSphere Application Server profile corresponding to the server type.
Replacement or injection of the configuration metadata for the OS and WebSphere Application Server profiles provides a significant time savings. The activation enables an image to quickly assume and adjust for new network settings, passwords, and WebSphere Application Server personalities, from deployment managers to custom nodes and job managers.
Parts are the primary building block of any virtual system pattern. However, there are other fundamental pieces of a virtual system pattern that are necessary to support detailed customization; namely, script packages and add-ons.
Script packages
In IBM PureApplication System virtual system patterns, a script package is your vehicle to provide custom middleware configuration. This ability might mean installing applications, configuring application dependencies, or otherwise tuning the middleware layer.
Script packages are compressed files that include some executable files (shell script, wsadmin script, Java program, and so on) and optionally, artifacts that support the running of the script. There is not a singular, mandatory format for a script. You can reuse many of the same scripts that you were using in your traditional deployments.
As was the intention, you can achieve just about anything you want with a script package. By using a script package, you can be as flexible and creative as you must be. Scripts can be designed to accept input parameters at the time of deployment. This feature allows a common script to be applied for many purposes on many parts. Scripts are imported into the IBM PureApplication System script catalog and can then be associated with parts that are contained in virtual system patterns.
Add-ons
Add-ons are specialized scripts to customize the virtual machine configuration. By using add-ons, you can modify the virtual machine configuration during deployment without the need to modify and save a new image configuration. You can use add-ons to augment the hardware and OS configuration of a virtual machine.
Add-ons simplify the task of performing lower-level OS configuration changes. For example, with the Add disk add-on, you must drag only the add-on from the Pattern Editor palette to the appropriate part and then configure the parameters.
You use add-ons such as custom scripts. You create and clone them in the catalog as necessary and then drag them onto parts in the Virtual System Pattern Editor. The primary difference is that add-ons are run before any custom scripts and they target the virtual machine configuration.
However, while add-ons are like scripts, there are significant differences. First, add-ons are not listed with the custom scripts. They have their own category in the catalog. Add-ons are run at deployment time before any custom scripts that are associated with a part. Unlike custom scripts, you cannot specify the order of add-on runs on a part. Add-ons are run only during system creation; you cannot initiate them on demand. They use hypervisor-level APIs to configure new hardware in virtual machines during deployment.
4.5 Virtual Systems
Virtual systems that consist of one or more virtual images are a foundational deployment model of PureApplication System.
A virtual system is defined in PureApplication System through a virtual system pattern. A virtual system pattern is a provisionable unit of one or more virtual images to be installed, configured, and integrated together to implement a topology. Virtual system patterns can be as simple as a single server product instance or as complex as a multi-product, multi-node deployment. Several virtual system patterns, which are provided by IBM that uses best practice design experience, are preinstalled in the catalog. After a virtual system pattern is deployed, it is referred to as a virtual system instance.
Virtual system patterns can be customized or patterns can be created by using the PureApplication System workload console. Customization is achieved by using parts, script packages, and add-ons.
Figure 4-8 Virtual system pattern concepts
The IBM PureApplication System comes with a set of Hypervisor Edition virtual images in the virtual image catalog. These virtual images consist of parts that can be added to virtual system patterns. For example, the WebSphere Application Server virtual image consists of the following parts: administrative agents, custom nodes, deployment manager, IBM HTTP Server, job manager, stand-alone server, and on-demand routers. When you create a pattern, the parts of the virtual images in the catalog are available for you to add to the pattern.
Some patterns have advanced options, for example, a virtual system pattern that includes parts for WebSphere Application Server deployment manager and custom nodes provides advanced options. These options are used to define clusters, enable the default messaging provider, configure session persistence, and enable global security. By using patterns, you also can define the startup order for parts and script packages.
As described in “Script packages” on page 120, a script package is an archive (.zip) file that contains artifacts to be run and artifacts to be run upon. The code that is included in the script package can be as simple as a.war file or as complex as a complete product.
During deployment, script packages are transferred to the target virtual machines at a file location you specify in the configuration. After they transfer, they are extracted in that same location. When the virtual machines successfully start, script packages are then extracted and the scripts are run by using the supplied command line. The goal of the use of script packages is to customize your middleware environment beyond the customization provisions that are standard with IBM PureApplication System. A typical scenario might be to install a WebSphere Application Server application and configure the required JDBC resources into a server or cluster environment that is rendered by IBM PureApplication System. The product provides a catalog of script packages that perform customization tasks. You can clone and then tailor these packages for your use, or you can create script packages.
Add-ons, which are available for parts in the pattern, include the capability to add a new virtual disk to the virtual machine (formatted or unformatted). They also canbe used to add and configure a virtual network interface controller (NIC), and add another user ID to the virtual machine. As another and important feature, you also have access to the IBM Image Construction and Composition Tool to build customized virtual images. These images can then be deployed in a virtual system pattern, as shown in Figure 4-9.
Figure 4-9 Image Construction and Composition Tool and PureApplication System integration
4.5.1 Virtual System Patterns
Virtual system patterns that are provided with the product from IBM represent hardened topologies of IBM middleware, which can be provisioned immediately.
To view virtual system patterns, from the PureApplication System workload console, select Patterns → Virtual Systems, as shown in Figure 4-10.
Figure 4-10 Browse to virtual systems
Creating the virtual system pattern
The virtual system pattern editor is an easy drag-and-drop interface that is used to create your virtual system topology. The initial pane is shown in Figure 4-11.
Figure 4-11 Virtual system patterns in the workload console
The Virtual Systems Patterns pane
When you select a virtual system pattern, the details about that pattern are shown in the workload console. A view of the topology for the pattern is displayed with the detailed information.
The topology for a virtual system pattern is described graphically for editing purposes. Virtual image parts, add-ons, and script packages can be dropped onto an editing canvas to create or change relationships between the parts that define the topology. All of these tasks are done in the Pattern Editor.
The Pattern Editor pane
Clicking the edit icon in the toolbar in the Virtual System Patterns pane opens the Pattern Editor for the selected virtual system pattern. The Virtual System Patterns pane provides lists to select virtual image parts, add-ons, and script packages. Figure 4-12 on page 126 shows the details of the selected virtual system pattern.
Figure 4-12 Virtual system pattern in Pattern Editor
Virtual image parts
Select Parts list in the Pattern Editor to see a listing of the parts that can be dropped onto the Virtual System pattern canvas. The Virtual System pattern canvas is on the right side panel of the Pattern pane. The following common virtual image parts are available:
• Administrative agents
•Custom nodes
•Deployment managers
•HTTP servers
•Job managers
•Stand-alone servers
•On-demand routers
•DB2 servers
•Others
The parts are determined by the virtual images that you are using. Some virtual image parts represent multiple nodes. There is an indicator on the part when you drop it onto the canvas that indicates the number of nodes of each part.
You can configure the properties of a selected part in the Pattern Editor or later when the pattern is deployed. To configure the part in the Pattern Editor, click the Properties icon in the part on the editing canvas. Selecting to lock a property prevents changes in that property during deployment.
Script packages
The Parts list on the Pattern Editor provides a listing of the script packages that can be dropped onto the virtual image parts. This list can contain script packages that are associated with the virtual image and any that you defined for use with IBM PureApplication System.
Add-ons
The following common add-ons can be added to parts on the editing canvas:
• Default add disk: Adds a virtual disk to the virtual machine and, optionally, formats and mounts the disk.
•Default add NIC: Adds a virtual NIC to the virtual machine, configures IP address information for the virtual NIC, and activates it.
•Default add user: Defines another user on the virtual machine.
•Default add raw disk: Adds a virtual disk to the virtual machine but does not format or mount the disk.
Customized versions of add-on types also can be created and made available to meet your particular needs and added to the catalog. An add-on can be created as a new add-on or cloned and modified from the default set.
Interaction between virtual image parts
Virtual image parts can be defined to interact with other virtual image parts. When the interacting virtual image parts are included in the same virtual system pattern, cross-configuration results. For example, when a custom node and a deployment manager are placed in the same virtual system pattern, they are automatically cross-configured. This configuration results in the custom node that is federated to the deployment manager. Similarly, administrative agents (or deployment managers) are registered with a job manager.
Virtual image parts can be cross-configured if the virtual system pattern editor can determine a unique relationship. If it is unable to do so, no cross-configuration occurs. For example, if a custom node is added to a virtual system pattern with two deployment managers, no federation takes place. However, if one of the deployment managers is later removed, cross-configuration occurs because a unique relationship now exists.
You can use the version indicator on the parts to ensure that they are referencing the same version of the virtual image in the catalog. If the version of a part is incorrect, you can change it when the part is on the Editing canvas. Hovering the cursor over the part name opens a window that has more information about the virtual image.
Preinstalled virtual system patterns
IBM PureApplication System ships with predefined virtual system patterns that represent best practices that are derived from years of experience in working with customers. These patterns represent common configurations from simple to advanced WebSphere environments and various DB2 configurations.
The predefined patterns might fit your needs exactly and you can deploy them without any changes. However, it is more likely that you want to clone and extend these patterns or create your own new custom patterns. For more information about how to create your own custom pattern, see Chapter 5, “Customizing Virtual System Patterns” on page 199.
An example of an application-ready topology that comes preinstalled on the IBM PureApplication System is the WebSphere advanced cluster virtual system pattern, as shown in Figure 4-13.
Figure 4-13 WebSphere advanced cluster
DB2 virtual system patterns
Like other applications that run on IBM PureApplication System, DB2 is available as a DB2 virtual system pattern or as part of a DB2 database workload pattern. The DB2 virtual system pattern allows for more flexibility in the control and configuration of the middleware environment. The following images are available that can be deployed as a DB2 virtual system pattern:
•DB2 Enterprise
•DB2 Express
•DB2 Enterprise (Primary Node for High Availability Disaster Recovery (HADR) feature)
•DB2 Enterprise (Secondary Node for HADR)
•DB2 Express (Primary Node for HADR)
•DB2 Express (Secondary Node for HADR)
4.5.2 Planning and designing your virtual system pattern
Virtual system patterns fully automate the deployment of complex applications and platforms while taking advantage of best practices. The most important technical role in virtual system pattern development is that of the application deployer.
The application deployer is the subject matter expert in the following areas:
•Identifying application prerequisites (hardware and software).
•Understanding the solution architecture from the perspective of high availability, scalability, failover, and fault tolerance.
•Applying best practices for application deployment and understanding the installation and configuration bottlenecks.
•Installing all components of the application.
•Scripting the installation of the application (by using shell, Jython, or DDL scripts).
•Administering prerequisite middleware and software products.
•Running basic functional tests on the application.
Ideally, the application deployer has enough installation, deployment, and configuration experience to identify the automation touch points of key manual tasks and to build into the pattern industry best practices. For example, if most customers or users run with a specific Java virtual machine (JVM) heap size in WebSphere, this setting should be built into the pattern.
Key pattern design concepts
You must consider the following concepts when a virtual system pattern is designed and developed:
•Elasticity
•Topology
•Orchestration
•Security
These concepts are described next.
Elasticity
Elasticity in a cloud environment involves automatic horizontal and vertical scaling of your application by using dynamic assignment of resources. In a virtual system pattern, WebSphere Application Server environments can be made elastic by using the Intelligent Management Pack (IMP) feature in IBM PureApplication System.
The IMP feature can grow or shrink a WebSphere Application Server cell in a virtual system pattern on demand. This elasticity is based on service level agreements or performance metrics that are described by policies. An example of how IMP achieves horizontal scaling is when it detects a workload spike in the WebSphere Application Server cell. The spike might exhaust all available current CPU capacity. To prevent this problem, the IMP feature automatically provisions a new WebSphere Application Server node to meet workload demand. Furthermore, IMP is flexible enough to implement vertical scaling when it is configured. To fulfill a response time SLA to prevent performance degradation, IMP can trigger the starting of new virtual machines in a WebSphere cluster.
If elasticity is a requirement for your application, consider the use of the IMP enhanced WebSphere Application Server environment on IBM PureApplication System.
Topology
If existing topological best practices were applied within your current environment, these best practices also are relevant to the virtual system pattern.
For example, if you use a clustered WebSphere Application Server setup with eight virtual machines and in-memory session replication as your best practice for production, the same configuration applies to the production trend of your virtual system pattern.
For a development or test environment of the virtual system pattern, you can choose a single server configuration and smaller heap sizes on JVMs.
As part of designing the virtual system pattern, it is helpful to create a diagram of the topology in which each product is listed (including the number of VMs per product) and the relationship between each VM is reflected. For example, if WebSphere Application Server must connect to a WebSphere MQ server, this communication should be reflected in the topology diagram, as shown in Figure 4-14.
Figure 4-14 Topology best practice example
Orchestration
After a topology is identified for the virtual system pattern, the next logical step is to list the actions that are needed in each VM to orchestrate the startup of the system. The order of each action also should be determined.
For example, if your application's installation process requires that a database should be running with a schema in place, orchestrate the database setup before the application installation process is begun, as shown in Figure 4-15.
Figure 4-15 Orchestration approach example
To enable this kind of orchestration, by using virtual system patterns the designer can specify two orders: the order in which virtual machines are brought up, and the order in which automation scripts are run across the virtual machines.
Security
Lightweight Directory Access Protocol (LDAP) support is one of the security-related topics to consider when a virtual system pattern is designed. Applications often do not mandate dedicated LDAP servers. Most applications connect to an existing LDAP server (such as a corporate LDAP directory) for authorizing access to protected resources. In such a situation, an LDAP server component is not included in a virtual system pattern.
From a WebSphere Application Server perspective, connection to an existing LDAP server in a virtual system pattern can be captured by using a script package that takes LDAP server information (host, user, password, and so on) as input parameters. The script package automates the configuration of an LDAP connection in WebSphere Application Server by a Jython script. The script alleviates the need for you to perform this configuration manually.
If an application requires a dedicated LDAP server, a new Tivoli Directory Server instance can be started first by using the Web Application virtual application pattern. WebSphere instances in the virtual system pattern can then connect to the Tivoli Directory Server LDAP server. Script packages in the virtual system pattern can be used to configure WebSphere Application Server with the new Tivoli Directory Server.
4.5.3 Deploying virtual patterns
Virtual system patterns are deployed to the cloud to build complex, application-ready middleware topologies. Weeks of assembling hardware and software can be replaced by specifying a few parameters in the IBM PureApplication System virtual system pattern deployment wizard. The pattern example, which is shown previously in Figure 4-13 on page 128, can be deployed through an easy-to-follow wizard by completing the following steps:
1. Select Patterns → Virtual Systems.
2. Select WebSphere Advanced cluster in the list of patterns and click Deploy in the cloud icon, as shown in Figure 4-16.
Figure 4-16 Deploy the virtual system pattern
A pop-up window opens with links to each configurable category. Each link can be selected to view or configure the options. The check mark to the left of the Choose Environment and Schedule deployment links indicate that they need no other configuration.
3. Enter a name for the virtual system. Figure 4-17 shows the name as ITSO-Adopting IBM PureApplication System. Click Configure virtual parts to expand that section.
Figure 4-17 Deployment configuration
4. Click Deployment manager. You see several settings that you can modify to customize the deployment manager, as shown in Figure 4-18. At minimum, enter the passwords for the root user, the WebSphere administrator, and the database administrator.
Figure 4-18 Settings for deployment manager
The following parameters are available to optionally configure, which provides optimal flexibility for customizing the environment:
– Virtual CPUs
– Memory size
– Reserve physical CPUs
– Reserve physical memory
– Cell and node names
– Feature packs to install
– Passwords for root
– User ID and password for the WebSphere administrator
– Data source name and JNDI name
– Database settings, including the database name, user ID and password, host, and port
– Web cluster prefix, number of clusters, and number of servers per node
5. Click OK.
6. Expand Custom nodes and enter the passwords for the root and WebSphere administrative users. Click OK.
7. Expand IBM HTTP servers and enter the passwords for the root and WebSphere administrative users. Click OK.
Figure 4-19 Deployment wizard that completed
9. The user interface opens the new virtual system instance for you to monitor, as shown in Figure 4-20. The following information is available:
– The Current status section shows the current state of the virtual system instance.
– The History section has a log with information about the transfer of the files to the system. Click Refresh occasionally to follow the progress of the deployment.
Figure 4-20 Pattern status
– The virtual machines that are created for the instance are listed in the Virtual machines section, as shown in Figure 4-21.
Figure 4-21 Virtual machines
– You can expand each virtual machine to find more information, including the status of the machine and the hypervisor where it is deployed. Figure 4-22 shows the virtual machine for the deployment manager. The systems are operational and the middleware is configured and started. This display shows information about the deployment manager configuration. It also provides links to log in to the console or to the system by using VMC. You can review the output of the script packages.
Figure 4-22 Virtual machine details
4.5.4 Customizing images and patterns
When the preinstalled content does not meet the needs of an enterprise, IBM PureApplication System provides many powerful options for customization. These customization options enable more flexibility to satisfy various requirements. Customization can occur in virtual system patterns and in virtual images. For more information about how to perform customization options in virtual system patterns, see Chapter 5, “Customizing Virtual System Patterns” on page 199.
4.5.5 Image Construction and Composition Tool and AMC tools usage
The IBM Image Construction and Composition Tool is a web-based application that simplifies the construction and creation of virtual images through several wizards. It also aids in the packaging of automation scripts that can be used to extend (customize) existing virtual images and to deploy software on these images.
The Image Construction and Composition Tool provides the capabilities to combine your own operating system definition with custom software bundles to compose virtual images that can be provisioned into the cloud. With Image Construction and Composition Tool, you can configure the PureApplication System as the cloud provider. By using this feature, you can import x86 or AIX images from the catalog, extend those images with software bundles, then capture the new image back into PureApplication System. You can then deploy the new image in PureApplication System.
For more information about how to use the IBM Image Construction and Composition Tool, see Chapter 5.3, “Build virtual images by using the IBM Image Construction and Composition Tool” on page 213.
PureApplication System also includes Advanced Middleware Configuration (AMC) as a workload. AMC stores configuration data on a framework server and uses the AMC Import Script Package to update that data. The AMC Integration Script Package incorporates that configuration data (including applications) in new virtual system patterns.
Use Advanced Middleware Configuration when one or more of the following conditions applies to you:
•You want to deploy applications as virtual system patterns.
•You do not have reliable end-to-end automation for the installation and configuration of applications.
•Your existing automation is specific to a single topology.
•You want to reduce your investment in low-level automation.
•You want to migrate WebSphere products into the cloud.
4.5.6 Logical to physical mapping for virtual systems
The virtual system focus becomes topology-centric when the user creates the topology pattern and deploys the solution. Application and configuration scripts that customize the environment according to a specific client environment are added to the virtual system pattern when needed. This environment is shown in Figure 4-23.
Figure 4-23 Logical to physical mapping for virtual systems
Showing the virtual system deployment model from the client view, you see that all that is needed is to create a virtual system pattern and deploy it. Rather than focusing on the application, you focus instead on the topology of the system to be deployed. To deploy an application in this model, you must provide application and configuration scripts rather than leaving PureApplication System to do it for you automatically. The virtual system pattern translates in the logical view to seven distinct instances. There is an instance that is created for each part that is contained in your virtual system pattern. This configuration includes a deployment manager, two custom nodes, a non-demand router, a DB2 standby instance, a DB2 primary instance, and an HTTP server. Finally, this configuration translates to seven distinct virtual machines that are created for you with the associated virtual image middleware in the PureApplication System rack. Unlike virtual application deployments, you determined this topology explicitly in your pattern definition.
4.5.7 Benefits and trade-offs
Determining what works best in your environment is a balance of benefits and trade-offs.
Virtual systems include the following benefits:
•Virtual system patterns provide repeatable, reproducible system deployments
Virtual systems offer repeatability, consistency, reproducible system deployment, and rapid deployment times for simple and complex middleware configurations. Virtual systems also preserve the control and flexibility of traditional middleware environments. As you define and customize a topology, you can reproduce in any place without more effort.
•Virtual system patterns are simple to create and deploy
The virtual system patterns are simple to create and deploy but it does take a little more work on your part than a virtual application deployment. To install your applications during the virtual system deployment, you must provide script packages that you created.
After deployment, users can access the environment and middleware infrastructure as before. This ability means they could run administrative scripts, access the workload console that is provided by the deployed middleware software, and any other task they would normally perform.
•Takes existing middleware topology and provides instant migration
With the virtual system deployments, you can take existing middleware topology along with any middleware configuration scripts and create a similar topology for the supported IBM middleware on PureApplication System. This ability is possible because the virtual system deployment model allows for far more customization than the virtual application deployment model. Because virtual system patterns use middleware topology, it provides an instant migration path from existing topology.
•Provides more control and administration
You have full access to the administration model of the middleware components in the topology. This access provides more control and the ability for you to manage the middleware components in the topology.
The use of virtual systems includes the following trade-offs:
•Virtual system configuration scripts are required
To provide this customization, all virtual system deployments require script packages to automate the configuration of your virtual system and make the deployment repeatable. This requirement might result in an investment of time and effort on your part (as opposed to money) to create these script packages.
To simplify this process for WebSphere applications, PureApplication System includes the AMC tool. AMC makes it easier for you to create repeatable and deployable virtual system patterns. This AMC tool includes applications and configurations by inspecting an existing application cell, extracting all of the configuration details, and encapsulating them in a script package that re-creates that configuration when the pattern is deployed. In this context, an existing application cell refers to the WebSphere Application Server cell definition in which an application is deployed.
A deployed application is made up of the application binary (WAR, EAR, and so on), the server topology, the configuration of that topology to support the application, and external resources. The inspection of this application (from a WebSphere pattern perspective) includes attaching to and inspecting a WebSphere cell and identifying the wanted topology to support the application. The configuration settings that are contained with the WebSphere Cell definition and the application deployment options and artifacts also are inspected. It does not include the analysis of the application source. This configuration is useful for WebSphere Application Server applications that do not conform to the constraints of any PureApplication System virtual application patterns and do not have a complete, reusable, and reliable set of deployment and configuration scripts.
•Putting to much content in virtual machine images
When virtual system patterns are created, it is helpful to think about how a pattern can support many applications, which requires taking a layered approach. If you put too much content in the virtual machine images, the patterns become difficult to reuse. It is common to include the operating system and middleware in the images and then use the script packages to lay down the application and configure the middleware. This configuration affords greater reuse.
4.6 Virtual applications
A virtual application is defined by a virtual application pattern. It is a complete set of platform resources that fulfill a business need, including web applications, databases, user registries, messaging services, and transaction processes. Each virtual application pattern is associated with a pattern type, which is a collection of plug-ins that provide these resources and services for a particular business purpose in the form of components, links, and policies. The pattern types, product extensions of the cloud system, and the types of virtual application that you build depend on the pattern types that you enabled. In the next sections, the concepts and several topics of virtual applications are described.
4.6.1 Concepts
Virtual application patterns are application-centric in their design. They provide a mechanism to represent middleware applications in a simplified model that abstracts away the underlying middleware infrastructure. For example, you describe a middleware topology with IBM HTTP Servers, IBM WebSphere Application Servers, and databases. The IBM PureApplication System then builds appropriate infrastructure and deploys the application into a cloud environment.
Virtual application patterns are highly optimized and are constructed solely for supporting a singular workload. This pattern requires the least amount of customization during deployment and provides the most direct method for obtaining a rapid return on investment. These patterns are implemented by using virtual application pattern types. These pattern types integrate the capabilities of multiple middleware software elements into a cohesive, built for purpose solution. By using this solution, you can represent your complete, often complex, environments as a single deployable unit.
Because it is an application-centric approach, you provide the application files and describe the characteristics of how the application should be run and managed by using policies. The appliance generates the middleware topology to meet your requirements, as shown in Figure 4-24. Also shown in Figure 4-24 is an overall picture of the relationship between virtual applications instance and virtual application patterns.
Figure 4-24 The overall picture: Virtual application pattern to virtual application instance
The virtual application deployment model is a platform as a service (PaaS) model in which your application is the focal point.
A virtual application pattern is the critical element that with which you rapidly set up and manage cloud application infrastructure. To create a virtual application pattern, you start with your application and define its specific requirements, such as what services it requires and the quality of service (QoS) that is needed. Based on the assets in your virtual application pattern, PureApplication System deploys and configures the appropriate middleware components in the background to run your application. This configuration simplifies the end-to-end process of creating, deploying, and configuring the middleware components for your applications. PureApplication System handles it all. After deployment, PureApplication System also takes care of monitoring the application for you, which adds resources as needed, for example, to meet the QoS requirements.
4.6.2 Virtual application patterns
Virtual application patterns represent a new cloud deployment model. The patterns are an evolution of the traditional topology patterns that are supported in virtual system patterns. Fundamentally, virtual application patterns raise the level of abstraction one notch higher than virtual system (topology) patterns and put the focus on the application. This difference means that when you use a virtual application pattern, the focus is on the application instead of the application infrastructure.
Virtual application patterns encapsulate the installation, configuration, and integration of middleware, and the installation and configuration of applications that run on that middleware. Most of this feature is hidden from you, the user, which means that you have less control over configuration and integration. However, you also reduced labor and increased agility. You can concentrate on the development of the application and its components and IBM PureApplication System can create and manage the infrastructure that services that application.
Reducing deployment time, increasing consistency, and fostering agility are benefits that you would likely expect when cloud-based approaches for your middleware application environments are explored. The IBM PureApplication System solution tackles these issues by making the deployment of cloud middleware environments fast, repeatable, and efficient.
The pattern-based approach is the foundation of IBM PureApplication System. It is consistent for virtual application patterns and virtual system patterns. By using the cloud appliance, you build and deploy patterns that represent your configured application environments. When you are ready to use a particular application environment, you pick a pattern and deploy it. IBM PureApplication System automates the deployment, configuration, and integration of the various virtual machines that make up your environment and delivers the completed product in a matter of minutes.
General features
Some of the virtual application patterns main features are shown in Figure 4-25.
Figure 4-25 General features of virtual application patterns
Automated scaling
You can include a policy in your virtual application pattern that provides automated scaling, which is managed by PureApplication System. As PureApplication System monitors the resources on the system, it scales up and down based on the application load.
Failover
PureApplication System automatically replaces a failed virtual machine if a virtual machine has a problem at any time. This feature provides application failover automatically.
Load balancing
Load balancing is also done for you by PureApplication System when the proxy shared service in your cloud is used. Requests that are serviced by your virtual application automatically are distributed across available instances.
Security
Security is an important feature in virtual applications. Highly secure environments can be easily integrated with LDAP for application security.
Monitoring
All the various components of the virtual application environments are monitored for you by PureApplication System. Through this monitoring, you can gain quick access to the status, performance, and resource usage of all areas of your virtual application.
All of these features are built in by using IBM PureApplication System infrastructure without any other costs. The unique requirement is configuring the solution according to your needs; for example, to use LDAP as an application security endpoint.
Elements and functions of a virtual application pattern
There are five main elements in a virtual application pattern features the following main elements, as shown in Figure 4-26:
•Pattern types
•Plug-ins
•Components
•Links
•Policies
Figure 4-26 Virtual application pattern elements
Virtual application pattern type
A virtual application pattern type is a collection of plug-ins that define components, links, and policies, with configuration files, which are packaged in a .tgz file. The virtual application patterns are used to build a virtual application that includes these components, links, and policies.
Virtual application pattern types are the containers of solution-specific and topology-specific resources that are required for different types of virtual applications. Pattern types are really the aggregation of various capabilities for a specific type of application. The actual solution-specific intelligence is delivered via plug-ins. A plug-in can participate in multiple pattern types; however, a plug-in always has one primary pattern type. The pattern types also provide shared services that incorporate runtime services, such as caching services and elastic load balancing.
The following types of virtual application patterns included with the PureApplication System:
•IBM Foundation Pattern
This pattern type is used to provide shared services for deployed virtual applications, such as monitoring and load balancing.
•IBM Web Application Pattern
This pattern type is used to build and deploy web applications. The IBM Web Application Pattern provides a set of components that often are needed for online web applications. These applications include Java Platform Enterprise Edition applications, databases, Lightweight Directory Access Protocol (LDAP) servers, and messaging. These components are based on products such as WebSphere Application Server, and Tivoli Directory Server. By using the Web Application Pattern, you can incorporate connectors to remote systems, such as WebSphere MQ, CICS®, and IMS™ into your virtual application pattern.
•IBM Database Patterns
This pattern type is used to build and deploy database instances. You can use IBM Database Patterns separately or you can incorporate them into a virtual application pattern that is based on the Web Application Pattern. The IBM Database Patterns provide support for DB2 in a database as a service (DBaaS) model, with which you can simplify and standardize the creation of databases. The following database patterns available that based on your needs:
– The Transactional Database pattern is primarily used for online transaction processing and is optimized for transactional applications.
– The Data Mart pattern is primarily used for data warehousing and is optimized for reporting applications.
•Application Pattern Type for Java
This pattern type is used to build and deploy Java applications. The Java Pattern provides support for building Java applications. This pattern type provides an easy and fast mechanism for provisioning Java applications. It also includes components with which you can connect to network resources, such as databases and web services.
•Other patterns
These patterns are the patterns that are included with PureApplication System and other patterns that you can import into the PureApplication System from the PureSystems Centre offering.
•Creating your pattern
You also can create your own patterns by using the Plug-in Development Kit, which is available for download. For information about how to create your own pattern, see Chapter 7, “Integrating PureData for Transaction” on page 309.
Some topics, such as web application patterns, Java patterns, database patterns, and PureSystems Centre are described in other sections of this book.
Templates
Templates are previously created patterns that you save as application templates for reuse. You build a virtual application pattern according to a specific pattern type and an optional template. For instance, to build a standard Java Platform, Enterprise Edition web application, you can choose the Web Application Pattern Type 2.0 and the template Blank Java EE web application.
Plug-ins
A plug-in is the primary mechanism for delivering and installing extensions to PureApplication System in support of customer workloads and applications. For example, a plug-in is the basic unit of content for virtual application workloads. It generally implements a specific capability for an application such as the WebSphere Application Server plug-in, which provides components to host Web Archive (WAR), Enterprise Archive (EAR), or Enterprise Bundle Archive (EBA) applications in WebSphere Application Server. It also functions for DB2 or Tivoli Directory Server plug-ins, which provide a link to connect a WAR, EAR, or EBA file with a database, as shown in Figure 4-27.
Figure 4-27 Plug-in functionality example
Plug-ins provide the key parts of a virtual application and the underlying implementation that makes the application deployable in the cloud.
Plug-ins are responsible for providing all of the necessary functionality to create and manage the real entities that are realized for the components, links, policies, services, and other features. Plug-ins first provide the visual elements that you see in the virtual application builder when your virtual application pattern is built. Plug-ins also are responsible for providing functions that are necessary to build the model of the system and eventually are deployed to the cloud. Plug-ins provide the necessary scripts to provision and configure the particular application elements. They also include the logic to federate the necessary elements to react to changes in the configuration, and to provide dynamic processing in support of policies. At deployment time, the plug-in provides implementation details and can further augment the deployed foundation image.
IBM PureApplication System provides many utilities to make this process easy and orchestrates the interaction with the plug-ins to deliver the necessary function in support of the application. This process is optimized and automated within the pattern so that a typical user of the pattern need not understand all of the mechanisms of the middleware. The user can instead focus on the wanted behavior of the application. For more information about how to use plug-ins, see 6.5, “Plug-in environment setup and creation of custom patterns” on page 286.
For a list of preinstalled plug-ins, see this website:
Components
Components represent an application artifact such as a WAR file, and attributes such as a maximum transaction timeout. In terms of the order management application example, the components for the application are the WebSphere Application Server nodes and the DB2 nodes. The WebSphere Application Server components include the WAR file for the application and the DB2 components connect the application to the existing DB2 server.
The available components in the virtual application patterns that are provided with IBM PureApplication System are shown in Table 4-1. Some components can vary according to the standard application pattern that is selected, such as web application pattern, database pattern, or Java application pattern.
Table 4-1 Application components
|
Component Name
|
Description
|
|
Extra archive file (web application)
|
Specifies the external archive file that contains other files that are needed by the WAR or EAR file.
|
|
Extra archive file (Java application)
|
You can upload other archive files and your Java application archive file. You can use these archive files to deploy more resources, such as JDBC drivers or .war files, into an application server, or to overwrite parts of the deployed Java application, such as configuration files.
|
|
Enterprise Application Component
|
The enterprise application (WebSphere Application Server) component that represents an execution service for Java Platform, Enterprise Edition EAR files.
|
|
Existing Web Service Provider Endpoint
|
A web service provider that is provided by a remote server.
|
|
Java application (IBM Java Runtime Version 7)
|
The Java application component represents an execution service for the Java SE platform. You can use this component to deploy any application that requires a Java runtime environment.
|
|
Policy Set
|
A policy set is a component that is used to define QoS policies. It is a collection of assertions about how services are defined, which can be used to simplify security configurations.
|
|
Web application component
|
The web application component represents an execution service for the Java Platform, Enterprise Edition WAR files.
|
In Figure 4-28, you can see the Application Components palette in the IBM PureApplication System.
Figure 4-28 Application components palette
The database components are shown in Table 4-2.
Table 4-2 Database components
|
Component Name
|
Description
|
|
Database Studio web console
|
The Database Studio web console component is a database tool that is included with the IBM Database Patterns. This plug-in component is not available on the Virtual Application Builder unless you accept the license for the IBM Database Patterns.
|
|
Database (DB2)
|
The DB2 database component represents a pattern-deployed database service.
|
|
Existing database (DB2)
|
An existing DB2 database component represents a connection to a remote DB2 database instance that is running remotely outside of the cloud infrastructure. The configuration properties allow a connection to the remote DB2 database.
|
|
Existing database (Informix®)
|
An existing Informix database component represents a connection to a remote Informix database that is running remotely outside of the cloud infrastructure. The configuration properties allow a connection to the remote Informix database.
|
|
Existing database (Oracle)
|
An existing Oracle database component represents a connection to an Oracle database instance that is running remotely outside of the cloud. The configuration properties allow a connection to the remote Oracle database.
|
|
Existing IMS database
|
An Information Management Systems Database IMS DB component represents a connection to an IMS database instance that is running remotely outside of the cloud infrastructure. The configuration properties allow a connection to the IMS DB system.
|
The Database Components palette in IBM PureApplication System is shown in Figure 4-29.
Figure 4-29 Database components palette in IBM PureApplication System
The Messaging components are shown in Table 4-3.
Table 4-3 Messaging components
|
Component Name
|
Description
|
|
Existing Messaging Service (WebSphere MQ)
|
An existing message service component represents a connection to an external messaging system, such as WebSphere MQ. The presence of a messaging system allows an enterprise application that is running on WebSphere Application Server to connect to the external messaging resource, such as WebSphere MQ.
|
|
Topic
|
A topic represents a message destination on a WebSphere MQ messaging service through which messages are published and subscribed.
If you purchased and enabled the Messaging Extension for Web Application Pattern pattern type, you can connect to an external WebSphere MQ messaging service or a WebSphere MQ messaging service that is deployed by using the Messaging Extension for Web Application Pattern.
|
|
Queue
|
A message queue is a message queue on a WebSphere MQ service from which messages are sent and received.
If you purchased and enabled the Messaging Extension for Web Application Pattern pattern type, you can connect to an external WebSphere MQ messaging service or a WebSphere MQ messaging service that is deployed by using the Messaging Extension for Web Application Pattern.
|
In Figure 4-30, you can see the Messaging components palette in IBM PureApplication System.
Figure 4-30 Message components palette in IBM PureApplication System
The OSGi components are shown in Table 4-4.
Table 4-4 OSGi Components
|
Component Name
|
Description
|
|
Existing OSGi Bundle Repository (WebSphere Application Server)
|
This component provides the URL of an existing WebSphere Application Server OSGi bundle repository.
|
|
OSGi Application (WebSphere Application Server)
|
This component represents the OSGi application on WebSphere Application Server.
|
In Figure 4-31, you can see the OSGi components palette in IBM PureApplication System.
Figure 4-31 OSGi components palette in IBM PureApplication System
The Transaction Processing components are shown in Table 4-5.
Table 4-5 Transaction Processing components
|
Component Name
|
Description
|
|
Existing CICS Transaction Gateway
|
An existing CICS Transaction Gateway (TG) component represents a connection to an existing CICS TG instance that is running remotely outside of the cloud. The configuration properties allow a connection to the CICS Transaction Gateway.
|
|
Existing IMS Transaction Manager
|
An existing Information Management Systems Transaction Manager (IMS TM) component provides an enterprise or web application that is running on WebSphere Application Server to connect to and submit transactions to an existing IMS system that is running remotely outside of the cloud.
|
In Figure 4-32, you can see Transaction Processing components palette in IBM PureApplication System.
Figure 4-32 Transaction Processing components palette in IBM PureApplication System
The User Registry components are shown in Table 4-6.
Table 4-6 User Registry components
|
Component Name
|
Description
|
|
Existing User Registry (IBM Tivoli Directory Server)
|
An existing user registry cloud component represents an existing LDAP service (IBM Tivoli Directory Server) that can be attached to a web application component or an enterprise application component. The LDAP service provides a user registry for container-managed security.
|
|
Existing User Registry (Microsoft Active Directory)
|
An existing user registry cloud component represents an existing LDAP service (Microsoft Active Directory) that can be attached to a web application component or an enterprise application component. The LDAP service provides a user registry for container-managed security.
|
|
User Registry (Tivoli Directory Server)
|
A user registry (Tivoli Directory Server) cloud component represents a pattern-deployed LDAP service that can be deployed alone or attached to a web application component or an enterprise application component. The LDAP service provides a user registry for container-managed security.
|
In Figure 4-33 on page 153, you can see the User Registry components palette in IBM PureApplication System.
Figure 4-33 User Registry components palette in IBM PureApplication System
The Other components that are available in the system are shown in Table 4-7.
|
Important: The components that are shown in Table 4-7 can appear or not depending on the virtual application pattern that is selected.
|
Table 4-7 Other components
|
Component Name
|
Description
|
|
Connect In
|
This component is used to open the firewall for inbound TCP connections from a specified address or range of addresses to a specified port in the target application component.
|
|
Connect Out
|
Specifies a component that is used to open the firewall for outbound TCP connections from a web or enterprise application to a specified host and port.
|
|
Monitored file
|
Use the monitored file component to specify a file, or collection of files, to monitor and be available in the logging view.
|
In Figure 4-34, you can see the Other components palette in IBM PureApplication System.
Figure 4-34 Other components palette in IBM PureApplication System
For more information about attributes and properties, see this website:
Policies
A policy is a set of automated system processes that can perform actions, schedule work for users, or automate manual tasks. For example, you can attach an optional QoS policy to the virtual application. Two virtual applications might include identical components, but require different policies to achieve different service level agreements.
When policies are added to the application, you can extend the capability of the application. For example, if you want a web application to be highly available, you can add a scaling policy in the virtual application builder and IBM PureApplication System creates the application and topology to achieve that requirement.
The following common policies for the Web Application pattern type are available:
•Scaling policy
Scaling provides runtime capability to scale the application platform as the load changes. A scaling policy component defines this capability and the conditions under which scaling activities are performed for your application, as shown in Figure 4-35.
Figure 4-35 Scaling policy properties
•Routing policy
Consider a routing policy that is a client policy for the proxy shared service. It provides routing and load balancing to multiple deployed web applications and supports HTTP and HTTPS requests. To enable an application to use the Elastic Load Balancing (ELB) shared service, you must add a routing policy to provide a virtual host name and a request protocol for the application, as shown in Figure 4-36.
Figure 4-36 Routing policy properties
•Java virtual machine policy
As shown in Figure 4-37, you can control the underlying Java virtual machine by using the JVM policy.
Figure 4-37 JVM policy
•Log policy
The log policy specifies the configuration for log records. Figure 4-38 shows a Log Policy example.
Figure 4-38 Log policy
Policies can affect the number of virtual machines that are started. For example, if you attach a scaling policy, multiple application server instances are connected with a load balancer and, optionally, an IBM WebSphere eXtreme Scale server for sharing sessions. Application artifacts are then deployed by starting the components and configuring them appropriately.
Policies can be applied globally at the application level or specified for individual components. For example, a logging policy defines logging settings. A scaling policy defines criteria for dynamically adding or removing resources from the virtual application. In terms of the order management application example, a Response Time Based scaling policy is applied. That policy scales the virtual application in or out to keep the web response time 1000 - 5000 ms.
When you deploy a virtual application, the virtual application pattern is converted from a logical model to a topology of virtual machines that are deployed to the cloud. Behind the scenes, the system determines the underlying infrastructure and middleware that is required for the application. It also adjusts them as needed to ensure that the quality of service levels that are set for the application are maintained. A deployed topology that is based on a virtual application pattern is called a virtual application instance. You can deploy multiple virtual application instances from a single virtual application pattern.
The components, links, and policies that are available to design a particular virtual application pattern are dependent on the pattern type that you choose and the plug-ins that are associated with the pattern type. Therefore, components, links, and policies are defined by plug-ins. When you create a virtual application pattern, the available components, links, policies, and configuration options are determined by the plug-ins that are included with the selected pattern type, as described in the following sections.
Links
Links connect components. Links represent some dependency or interaction between components. For example, certain components in the Web Application pattern type support links to other components in other pattern types, such as to a database component in the IBM Database Patterns type.
A link serves the following purposes:
•It ensures that the origin and destination components of the link are properly configured to support the connection.
•The link also ensures that the network and firewalls are configured appropriately to allow communication.
•The link ensures that dependencies are accepted and supported so that components can appropriately react to dependencies changes or failures.
Virtual Application Builder
The Virtual Application Builder in the IBM PureApplication System supports the application-centric approach for deploying applications to the cloud. This support provides the means of creating virtual application patterns.
A virtual application pattern consists of a combination of application components, links, and policies. The application component represents the middleware (such as WebSphere Application Server) to run the application instance. Links represent connections (such as JDBC), and policies represent the middleware configuration or quality of service.
To access Virtual Application Builder, you must have at least the Create new patterns permission.
Browse to the Patterns → Virtual Applications console page. By default, IBM Workload Deployer includes the following sample applications in the Virtual Application Patterns list:
•Sample Java EE web application
•Sample Web Application Only
•Secured Java EE web application
Figure 4-39 shows the Virtual Application Patterns sample applications pane.
Figure 4-39 Virtual Application Pattern sample applications
Figure 4-40 shows the Virtual Application Builder.
Figure 4-40 Virtual Application Builder
Use Virtual Application Builder to create your virtual application pattern. The palette on the left side of the pane shows the components that are available for your virtual application pattern. Figure 4-40 shows the Web Application Pattern so you see application components such as Enterprise application and Web application. You also see that the pattern contains Database Components, Messaging Components, and User Registry Components.
To build your pattern, you drag the needed components from the application onto the canvas in the middle of the interface. The canvas, as shown in Figure 4-40, is showing a pattern that includes an enterprise application that connects to a User Registry component and a Database component. On the right side of the pane, you define the components and tell PureApplication System what enterprise application to deploy. If you click a User Registry component, you see properties such as an LDIF file that defines which LDAP database to use.
Reference layering
Virtual Application Builder is used to create virtual application layers that provide a way to control the complexity of your virtual application and to reuse virtual applications. In Virtual Application Builder, the layering function is in the Assets panel of the Diagram view. It is at the bottom of the pane and under the components, as shown in Figure 4-41. It is collapsed by default.
Figure 4-41 Layers capability in the Virtual Application Builder
The layer is a generic container in a virtual application for a collection of components. It helps you to control the complexity in the application diagram by disabling or enabling layers and to reuse the application by importing an existing application as a reference layer. By default, a virtual application consists of one layer when you first create it. When you use application layering, you can modify an existing virtual application by adding separate layers. A virtual application can contain multiple layers. A layer can contain component types of the virtual application, or the layer can reference another virtual application, which is called a reference layer.
For more information about creating, editing, importing, and deleting layers, see this website:
http://pic.dhe.ibm.com/infocenter/psappsys/v1r0m0/topic/com.ibm.ipas.doc/workloadconsole/t_mngpatterns.html
Web Application Pattern
The IBM Web Application Pattern is a standardized application-centric pattern solution. It is based on common client experiences that can be reused to deploy and manage resources in the Web Application Pattern manages application deployment and lifecycle. The product extension sits on top of the IBM PureApplication System. Plug-in APIs run within the virtual application pattern to support models, patterns, binary files, and automation. A collection of existing services, such as DB2, WebSphere MQ, WebSphere Application Server, and CICS can be selected for the virtual application pattern, which allows for a customized environment.
Specifically, the Web Application Pattern provides a set of components that are typical for online web applications, like Java Platform, Enterprise Edition applications, databases, LDAP servers, and messaging. After the virtual application is built in the Virtual Application Builder, you can deploy the application and the system determines the underlying topology configuration.
The Web Application Pattern includes a scalable application server, a database, and an elastic caching component. These components are managed together as a single unit, which reduces the management and operational complexity of an end-to-end environment for hosting Java Platform, Enterprise Edition web applications. The following components are available:
•Scalable application server
The Web Application Pattern includes a dynamically scalable application server that expands to meet the resource needs of the applications that are hosted within it. The expansion is based on processor consumption. Interaction with Web Application Pattern occurs through artifacts and policies. By providing artifacts, such as EAR files and data definition language (DDL) files, and specifying deployment and management policies, you are ready to use your application. The deployable artifact describes the operational policy for which the application server is managed. For example, you can specify that a WAR file is hosted in a highly available manner, with transactions tracked by using an external product.
•Database
Web Application Pattern also includes a database. The use of the database component is as simple as providing a DDL file that describes the application schema. You can optionally define the amount of storage that is allocated to your database. It is also possible to connect to an externally managed database if you must use a database outside the scope of PureApplication System. However, the use of an external database removes the benefit of the solution, but the value from the remaining components still exists.
•Elastic caching
In addition to the ability to dynamically scale the application server footprint in response to fluctuating processor consumption metrics, Web Application Pattern provides scalability by using an elastic caching component. This caching component is a distributed in-memory cache, which is highly scalable and fast.
IBM Database Patterns
IBM Database Patterns is a product extension that is used to build online DB2-based databases.
IBM Database Patterns manages a DB2 database deployment. IBM PureApplication System plug-in APIs run within the workload pattern to support models, patterns, and automation. You can select the database requirements to support typical departmental-style applications for a workload pattern. After a database is deployed, the IBM PureApplication System system determines the underlying topology configuration.
By using IBM Database Patterns, you can create and deploy DB2 databases in a database as a service (DBaaS) cloud environment. You select the database requirements that meet your needs and PureApplication System builds the underlying topology to meet those requirements.
Sometimes there is a need for databases that are independent of DBaaS offering. The following usages scenarios require an independent database:
• Separate management team
• Lifecycle independent of application lifecycle
• People or teams need database access across multiple applications
In many usage scenarios, the database is a distinct entity with its own administrative team and lifecycle. PureApplication System models this behavior with database patterns and database instances. You inform the PureApplication System of your database requirements in the form of a database pattern. Then, it builds and deploys a DB2 database instance for you, as shown in Figure 4-42.
Figure 4-42 Database pattern overview in regards to separated administrative teams
Database patterns
In the context of PureApplication System, there are multiple ways to deploy or configure a database. As IBM DB2 software is integrated inside PureApplication System, the use of DB2 as a deployed application's database involves no extra costs. This configuration reduces overhead and other license tracking mechanisms and the total cost of ownership of the platform. The unified nature of DB2 within PureApplication System allows for best practices and expert-focused integration to be applied and followed throughout an application's use of DB2 as the database back end service. Like other applications that run on IBM PureApplication System, DB2 is available as a DB2 virtual system pattern or as part of a DB2 database workload pattern.
IBM Database Patterns can be created and managed independent of any virtual application pattern as DBaaS or as a Remote database (existing database component) that deploys a database pattern as part of the virtual application, as shown in Figure 4-43.
Figure 4-43 Deploy database pattern options
In most real world usage scenarios, databases are managed independently of any one application.
To more closely model this paradigm, database patterns were introduced. You can create, delete, update, backup, and restore databases that are created by using a database pattern. These management activities are independent of your virtual application. Deleting your virtual application has no impact on the deployed database or database pattern.
In Figure 4-43, label 1 shows that you can include an existing database as part of your virtual application pattern. This ability is considered an existing database component and is not deployed as part of your virtual application. The database exists and is used by the application that is deployed as part of the virtual application. It can be created as a database instance in PureApplication System.
Identified as label 2 in Figure 4-43, is an aExisting Remote Database that was created outside of the PureApplication System environment.
In these cases where an existing database component is being used, deletion of the database does not affect the state of the virtual application instance. Similarly, changes to the virtual application instance do not affect the database.
Label 3 in Figure 4-43 on page 162 shows it also is possible to deploy a database pattern as part of the virtual application. Instead of including an existing database component in the virtual application pattern, you can include a database component that becomes a pattern-deployed database service. In the case of a pattern-deployed database service, the database is deployed as part of the virtual application. When the virtual application is deleted, the database also is deleted.
DB2 virtual system patterns
The DB2 virtual system pattern allows for more flexibility in the control and configuration of the middleware environment. It is explained in more detail in 4.5, “Virtual Systems” on page 121.
DB2 database workload patterns
In addition to the DB2 virtual system patterns available, DB2 database workload patterns are found within PureApplication System where the configuration and best practices are applied for a specific context. The deployment of a DB2 database workload patterns is simple with the flexibility for changes to some of the configuration parameters within the database layer. The following database workload patterns are available for DB2:
•IBM Transactional Database Pattern
•IBM Data Mart Pattern
•Custom Standard
The IBM Transactional Database Pattern is designed to accommodate departmental online transaction processing (OLTP) applications that do not require high levels of database customization. This database workload pattern includes automated configuration for departmental OLTP deployment, virtual machine deployment sizing templates, and database backup scheduling. Within this pattern, the DB2 Enterprise edition is used with the Storage Optimization feature enabled for data compression.
The IBM Data Mart Pattern provides a set of capabilities that are essential to the provisioning and management of the data mart infrastructure for data-centric applications within PureApplication System. Tuned for the unique I/O throughput that is required of data mart workloads, the IBM Data Mart Pattern includes data compression capabilities and data movement tools. These tools are designed to help move the business forward with the information that is needed without delay. Within this pattern, the DB2 Enterprise edition is used with the Storage Optimization feature enabled for data compression. Included inside this pattern are the SQL Warehousing tools for creating and modifying physical models, control flows, and data flows of the target data marts.
By using the Custom Standards, you can define your own workload standard when you must customize the deployed database to meet some of the required tuning or corporate standards.
Clone support
Cloning is a provisioning approach that uses an existing database image as a model for creating database patterns. When an image is selected, the metadata that is stored during backup is retrieved. A new virtual machine is created with the same resource settings. The DB2 Restore command creates a database with the same license and configurations. This cloned database then sits on the new virtual machine. You should use manually created images in preference to automatically created backups for this task. You can manually create a database image with the Create a Database Image function in the Database Service Console.
IBM Database Patterns requires the IBM Tivoli Storage Manager server to store database images. If there is no available Tivoli Storage Manager server, database images cannot be created in IBM Database Patterns. Tivoli Storage Manager must be configured to use clone support function. Without it, you cannot take an existing database that was backed up to Tivoli Storage Manager and clone it (copying it and all its configurations exactly). For more information about how to configure IBM Tivoli Storage Manager for clone support, see this website:
Deployment and operations flow
Figure 4-44 shows the overall flow for deploying a database in PureApplication System.
Figure 4-44 Deployment and operations flow
Label 1 in Figure 4-44, shows that you have two options to start. You can start a deployment from an existing pattern or you can perform a one step deployment by passing the pattern selection. If you use a pattern, you can use a pattern that was saved or create a pattern.
When you create a pattern you have two deployment options, as shown in label 2 in Figure 4-44 on page 164. You also are given these same two options for the one step deployment. You can select the type of workload standard to apply to the DB instance to be created or you can select to clone an existing DB image that was backed up to your DB image catalog repository. Tivoli Storage Manager is used by PureApplication System to store these DB images.
If a workload standard from which to create your pattern is selected, in the Blank DB option, you have the following options:
•Departmental Transactional
This option is the default. By using this custom option, you can add an unlimited number of custom workload standards that define specific tuning requirements that are required for your particular applications or workloads.
•Data Mart
The IBM Data Mart Pattern provides a set of capabilities that are essential to the provisioning and management of the data mart infrastructure for data-centric applications within PureApplication System. Tuned for the unique I/O throughput that is required of data mart workloads, the IBM Data Mart Pattern includes data compression capabilities and data movement tools that helps to move the business forward with the information needed without delay.
•Custom
By using customized workload standards, you can define specific tuning requirements that might be required for mature applications or workloads.
After you have your pattern set up as you want, deploy the database pattern. Deploying causes a DB instance to be deployed, as seen in label 3 in Figure 4-44 on page 164. The deployment process makes many decisions for you to tailor your DB instance. The deployed DB instance includes standardization, best practices, and workload optimization that correspond to the workload standard selected.
After deployment, you have a fully functional robust database for your IT environment, as shown in label 4 of Figure 4-44 on page 164.
Label 5 in Figure 4-44 on page 164 shows some operations that are available to you from the PureApplication System Database Service Console. These options include the backup of your image to the DB Image catalog, as shown in label 6 of Figure 4-44 on page 164. This operation requires Tivoli Storage Manager.
DB2 service for cloud: Oracle or DB2 applications
IBM PureApplication System supports DB2 applications and Oracle applications, as shown in Figure 4-45.
Figure 4-45 Oracle and DB2 support
In cases where you might need Oracle databases, PureApplication System supports an Oracle Compatibility mode, with which you can support your Oracle applications. When you are defining your database pattern, you can select the Oracle compatibility mode, as shown in Figure 4-45 on page 166. By using DBaaS for database deployment, a single skill set for your application group is possible.
Logical to physical mapping for database
In Figure 4-46, you can see the mapping from logical view to physical view in terms of the database patterns perspective.
Figure 4-46 Logical to physical mapping in database patterns
Looking at DBaaS from the client view, you again must create a pattern (database pattern) and deploy it. One of the options that is available when you create your database pattern is pointing to an existing image to copy it for your new deployment. The logical view shows that a database is created for each deployment and each of those database deployments translates to a separate virtual machine that is created in the PureApplication System rack. After it is created, you can delete, update, backup, and restore the deployed databases.
Application Pattern Type for Java
The Application Pattern Type for Java is a virtual application pattern type that you can use to build Java applications. This pattern type provides an easy and fast mechanism for provisioning Java applications.
The Application Pattern Type for Java manages Java application deployment and lifecycle. This product extension sits on top of the IBM PureApplication System. Plug-in APIs run within the virtual application pattern to support models, patterns, binary files, and automation. A collection of other components allows connections to network resources, such as databases or web services, to deploy more files and to enable monitoring of log files. After the virtual application in the Virtual Application Builder is built, you can deploy the application. The system determines the underlying topology configuration.
The Application Pattern Type for Java provides an instance of IBM 64-bit SDK Java Technology Edition Version 7. By using the pattern, you can bundle an existing Java application with all of the resources it requires as a compressed archive file and deploy it into the cloud. In addition to providing the Java runtime environment, the Application Pattern Type for Java provides some pre-configuration, which implements best practices for performance and monitoring. The following monitoring and performance best practices should be considered:
•Enabling the use of compressed references
•Logging verbose garbage collection information
•Providing a mechanism for enabling the use of IBM Monitoring and Diagnostic Tools for Java - Health Center
Application Pattern Type for Java prerequisites
Before you use the Application Pattern Type for Java, verify that your hardware and software meet the minimum requirements.
The official set of hardware and software requirements is available on the System Requirements page of the product support site. If there is a conflict between the information that is provided in the information center and the information about the System Requirements page, the information about the System Requirements page takes precedence. The following requirements are for application pattern type for Java from PureApplication System information center:
•Hardware requirements:
– IBM PureApplication System Version 1.0
– IBM System x® servers, supporting VMware ESX Version 4.1, Version 4.0 U1 or higher, or Version 3.5 U5 or higher
•Software requirements:
– IBM OS image for Red Hat Linux Systems (required for the use of Application Pattern Type for Java with VMware ESX hypervisors)
– IBM Foundation Pattern
– VMware ESX Version 4.1, Version 4.0 U1 or higher, or Version 3.5 U5 or higher
Building blocks of a Java virtual application
The IBM Application Pattern for Java provides five simple building blocks that you can use to create a Java virtual application. You can deploy your application and any other libraries or configuration files it might require, configure the incoming and outgoing firewall, and add your application log files in to the provided monitoring framework. The framework consists of the following components:
•Java application
This application is the component that you use to supply and configure the main part of a Java application. You must provide the application itself as an archive file, such as a .zip, TAR.GZ, or TGZ file. This file must contain the compiled Java application code. After you supply the application, you declare the appropriate option for how the application runs. Then, you can use the main method (com.ibm.sample.HelloWorld along with any parameters and other class path entries) or a command line if a startup script (such as /bin/start.sh) starts your application.
In addition to the configuration of the Java application you are deploying, you can optionally add a JVM Policy. By using this policy, you can alter the configuration of the underlying Java run time. You can set minimum and maximum Java heap sizes, enable debug mode, enable Health Center monitoring, or add other Generic JVM Arguments. Enabling debug mode or Health Center monitoring also causes the necessary firewall ports to be opened. You can limit the range of IP addresses that are allowed to connect to the Java application.
|
Important: Health Center is a no cost, low-overhead diagnostic tool for monitoring an application that is running on an IBM Java virtual machine. It is available as part of the IBM Support Assistant. The IBM Application Pattern for Java uses its late attach capability so that you can start monitoring at run time.
|
•Additional archive file
By using this component, you can add files to the virtual application by supplying an archive file that contains the other files. It can be a Java archive (a Java archive, WAR, or EAR file) that is deployed as-is into the specified location, or a normal archive file (.zip, TAR.GZ, or TGZ) that contains the other files that can be unpacked into the wanted location. The Java archive option is useful for adding components such as JDBC drivers or deploying a web application if the main Java application is an application server, such as Apache Tomcat. The normal archive option is useful for adding or overwriting default configuration files, such as a server.xml file, to change default port usage or add user IDs.
•Connect In
By default, the deployed application does not allow any incoming or outgoing network traffic. By using the generic listener component, you can configure the firewall for incoming network traffic. This option configures only the firewall and does not cause an HTTP server to be deployed. However, you can use an IP/netmask to limit the range of IP addresses that can connect to the application.
•Connect Out
The generic target is the counterpart to the generic listener but is used for configuring outgoing network connections. You specify an IP address or range of IP addresses to which the application can connect. For example, if the application connects to a database, a generic target is required to allow the connection.
•Monitored file
By using the monitored file component, you can add one or more files into the Log Viewer of the workload console that is provided by the IBM SmartCloud, IBM Workload Deployer, and IBM PureApplication System user interface. The monitored file component allows the use of wildcards, and several monitored file components can be added if multiple files or multiple directories must be added to the Log Viewer. For example, /logs/*.log adds any file in the logs directory with a .log suffix to the Log Viewer.
Using Java application templates
The Application Pattern Type for Java provides some templates for deploying common applications. You must specify some information before you can deploy the application. For example, the Apache Tomcat template already contains the port that Tomcat listens on, the log directory that Tomcat uses, and the directory from which Tomcat automatically retrieves web applications. You must specify the web application to be hosted by Tomcat and the Tomcat file that you downloaded earlier.
Use these templates to quickly deploy the following applications: Apache Derby, Apache JMeter, and Apache Tomcat.
To get started, download the application that you want to deploy. The templates are set for specific versions of these applications. You can download different versions, but you must modify some of the template information. The following templates are the built-in versions:
•Apache Derby 10.8.2.2 (a Java database application)
This application is a template for deploying the Apache Derby 10.8.2.2 database.
•Apache JMeter 2.7 (a load test application).
This application is a template for deploying Apache JMeter 2.7 to conduct load testing. When you deploy this application to the same cloud as your Java application, you can test your application with much greater loads than if you used JMeter from outside the cloud.
•Apache Tomcat 7.0.27 (a web server application)
This application is a template for deploying Apache Tomcat 7.0.27 and a Web Application. The required information is the Archive File entry when you specify the .zip, TAR.GZ, or TGZ file that contains the Java application that is uploaded.
For all of these templates, the following fields are required:
•Archive File: Specifies the .zip, TAR.GZ, or TGZ file that contains the Java application that is uploaded.
•Application Launch Type, one of two options:
– Main Class: Specify the class that contains the main() method that uses a fully qualified class name, for example com.ibm.myApp.
• Program Arguments: Specifies arguments to pass to the main() method.
• Class path: Specifies other entries for the class path, uses ':' as a separator.
– Command Line: Specifies the command line to start the Java application.
4.6.3 Simple topology instantiation
Simple topology instantiation represents a basic configuration of a virtual application. Figure 4-47 on page 171 shows that the simple virtual application topology is instantiated by PureApplication System. The virtual application pattern consists of an enterprise application component and a database component. Each of those components is deployed into a separate VM with the needed middleware and a deployer agent, which orchestrates the deployment. The middleware that is installed in the case of the Enterprise Application component is WebSphere Application Server. In the case of the database component, DB2 is installed. You see that an .ear file also is installed and a database is created in the respective VMs.
Figure 4-47 Simple topology instantiation for a Virtual Application
4.6.4 Topology with scaling policy instantiation
Shown in Figure 4-48 on page 172 is a simple topology instantiation. By adding a scaling policy to the virtual application pattern, you get a much more sophisticated instantiation. This enhancement is determined by PureApplication System that is based on your simple virtual application pattern. In this case, your application relies on two shared services: the proxy service and the caching service.
The proxy shared service provides routing and load balancing for the multiple web applications that are deployed on your behalf. The scaling policy also requires the use of the caching shared service, which allows for highly efficient caching that is based on WebSphere eXtreme Scale. The shared services are shared among all deployments within a cloud environment. They are not deployed when this pattern is instantiated. The shared services already are running and available for use, as shown in Figure 4-48 on page 172.
Figure 4-48 Virtual Application with Scaling policy instantiation
4.6.5 Shared services
As shown in Figure 4-49 on page 173, shared services are predefined virtual application patterns that can be deployed and shared by multiple application deployments (virtual applications, virtual systems, and virtual appliances) in the cloud. They provide some runtime services to multiple applications, or services to users on behalf of multiple applications. Shared services create a simplified consumer (users/application deployments) and provider (implementation/shared service deployment) model. Shared services often are installed as part of the Foundation Pattern.
Figure 4-49 Shared services overview
Shared services provide a predefined virtual application pattern that is deployed and shared by multiple application deployments. These application deployments include virtual applications, virtual systems, and virtual appliances in the cloud.
To view shared services, you must be assigned the Workload resources administration with full permissions or the Cloud Administrator role.
IBM PureApplication System allows virtual applications to use a common (or shared) set of services. These services are used to proxy HTTP requests, cache session data, and monitor components of the virtual application. When they are deployed, these services are shared between all virtual applications within a cloud group. Each cloud group must have its own instance of a shared service for it to be available, which means that only one instance of a type of shared service can be deployed in a cloud group (physical group of hardware that defines a cloud). This shared service can be used by all application deployments in the cloud group, which means that the shared service must provide multi-tenant access. Virtual applications that enable a routing policy use the shared proxy service. Those services that enable session caching in a scaling policy use the shared caching service. These shared services offer automatic failover, a reduced resource footprint in the cloud, and improved performance.
Shared services provide the following features:
•A plug-in design service that provides full lifecycle management capabilities in the same way as a virtual application.
•Specific runtime services to multiple applications, or services to users on behalf of multiple applications.
•A simplified consumer (users/application deployments) and provider (implementation/shared service deployment) model.
•Viewed as a multi-tenant service.
Shared services are used in the following ways:
•Directly exposed by a resource in the Virtual Application Modeler by using routing policy.
•Indirectly exposed though a setting that implies the usage of a shared service, such as HTTP session caching inside scaling policy.
•Injected though transformation process, such as injecting the Logging service client.
Caching Service 2.0.x
The IBM PureApplication System hosted caching service is a shared service that is deployed in the cloud to allow other deployments from Workload Deployer to use common cached information. It enables in-memory cached objects in virtual applications.
Virtual applications share cache service in the cloud group to which they are deployed. Sharing the cache service function reduces the footprint of resources that are required for each virtual application. The smaller footprint is a result of the fact that applications do not have to maintain their own memory overhead to support the cache. Caching service also eliminates redundant virtual machines to support high availability.
The caching service is not only for session replication. A virtual system can use the caching service for sessions, as a dynamic cache or as a simple object grid. The caching service is based on WebSphere eXtreme Scale code and provides highly efficient caching. The caching service is self-managed and highly available, providing simple, and quick usage.
To deploy a caching service that is hosted as a shared service, complete the following steps:
Figure 4-50 Caching Service 2.0.x
2. Click the Deploy icon.
3. Specify the instance size, number of instances, maximum number of instances, and the rules for auto-scaling (if automatic scaling is enabled), as shown in Figure 4-51.
Figure 4-51 Caching service properties
The following settings determine the size and initial number of virtual machines in the cloud that are devoted to the caching service:
– Instance information
The initial number of instances provides the minimum number of instances that share in session persistence and provide failover. For example, if you select 8 GB for size per instance and four initial instances, the caching service deploys with four virtual machines. Each machine can each handle 8 GB of caching information, for a total capacity of 32 GB. The information about each instance is replicated automatically to other caching virtual machines.
The estimated cache grid provides a total of 32 GB in this example. The total virtual machine instance size is larger than 32 GB because of the administrative and OS memory requirement additions.
– Scaling information
When you choose Enable Automatic Scaling, you must specify the following settings:
• Automatic scaling threshold range percentage
Use the slide rule to define the automatic scaling range when the capacity is outside the limits. The lower capacity limit is for scale down and upper capacity limit is for scale up.
• Minimum time to trigger automatic scaling
To trigger automatic scaling, the capacity must exceed a specified range. You specify the minimum range (in seconds) that must be exceeded to trigger the automatic scaling.
If you choose to Disable Automatic Scaling, the scaling properties are removed from the deployment pane, as shown in Figure 4-52.
• Automatic Scaling Disabled
You must manually scale out and scale in the cache instances from the Virtual Application Console up to the maximum number of instances.
Figure 4-52 Disabling automatic scaling in the caching service
4. Complete the deployment by providing the cloud group information for the service and click OK.
5. You can view the new shared caching service virtual machines by selecting Instances → Shared Services and then selecting the shared service instance, as shown in Figure 4-53. You can monitor the deployment status in the virtual machine perspective section. The role status is caching when the instance is running.
Figure 4-53 Caching service virtual machines
In Figure 4-53 on page 177, you see that the virtual machines have different functions as indicated by the name (catalog, master catalog, and container). Cached data is stored in the containers. The catalog service maintains topology information for the containers and controls balancing and routing for all clients. The last virtual machine to reach a running state is the master.
Managing the service
You can use the Virtual Application Console to manage the caching service. To open the console, click Manage from the shared service instance. If automatic scaling is disabled, use the scale out and scale in operations to increase and decrease the number of cache instances in the cloud. You cannot have automatic scaling enabled and also manually scale out and scale in because these operations conflict with the automatic scaling rules. You also can use the Virtual Application Console to manage grid caching directly. If you are using a virtual application pattern with a scaling policy and shared services, the grid is managed and configured for your WebSphere Application Server automatically. You can manage the grid in the cloud yourself from the Virtual Application Console in the following cases (see Figure 4-54):
•If you are not using a virtual application pattern (that is, you are deploying a WebSphere Application Server virtual system) and want to customize that installation for caching manually.
•If you have an application that has direct WebSphere eXtreme Scale appliance grid operations.
Figure 4-54 Virtual Application Console grid operations
Grid caching maintains data that can be accessed from multiple clients, which minimizes network latency and reducing bandwidth. You can set the following options when you are using the caching service to configure grid caching:
•Create grid: Create a grid to maintain cached data. When a grid is created, you must provide a name, specify the type of grid, and assign the grid an ID and password.
•List grid: Return a list of all of the grids that exist in the caching service.
•List grid details: Return the details of a specific grid.
•Delete grid: Delete the specified grid. If you choose to delete a grid, all of the cached data on that grid is deleted. This action cannot be undone. Deleting a grid also deletes the user ID that is associated with the grid.
Caching Service (External) 2.0.x
You can also connect to an external caching appliance collective with by browsing to Cloud → Shared Services → Caching Service (External) 2.0.x. Click Deploy to display the required parameters for the external cache, as shown in Figure 4-55.
Figure 4-55 Configuring an external caching service
In this pane, you can point to an external WebSphere DataPower XC10 Appliance. The following parameters are required to point to an external appliance:
•External Caching Appliance Host Name
•External Caching Appliance Administrative User Name
•External Caching Appliance Administrative User Password
•External Caching Appliance Public Certificate
You can obtain the External Caching Appliance Public Certificate by using a browser to access the XC10 appliance and then downloading the public certificate. When you deploy an application with a scaling policy that is configured to a cloud with an external caching service, the application caches according to the configured external service settings.
ELB proxy service
The primary benefit of enabling a proxy service is that the IP addresses that are used internally are not visible externally on the web. A typical environment has a first tier (a well-known host such as www.ibm.com). The first tier sprays requests to a second tier of internal servers that host the application and content (protected and secured). The IBM PureApplication System ELB proxy service is on the second tier. The multiple ELB instances, set up by the service, are the internal IP addresses that the first tier sprays with requests.
The ELB proxy service provides a front end to virtual applications in the cloud by balancing the load across the instances of virtual applications. The ELB shared service is shared by virtual applications that are deployed to the same cloud group. Removing the redundant component from each virtual application that participates in sharing improves cloud density. Requests are routed to an application that is based on the protocol (HTTP and HTTPS) and the application’s host name. Complete the following steps to enable the ELB proxy service:
1. Browse to Cloud → Shared Services, select ELB Proxy Service 2.0, and then click the Deploy icon.
2. Configure the number of initial instances, as shown in Figure 4-56. The initial number of ELB instances values is how many ELB instances should be created. This number indicates the number of virtual machines that share the responsibility of load balancing and provide failover. The default value is 2.
Figure 4-56 Configuring ELB proxy service
3. Select Instances → Shared Services and select the service to monitor the deployment. The Deploy Virtual Application page shows the target environment profile or target group, as shown in Figure 4-57. Wait for your ELB service to reach the running state to be ready for load balancing and fail over. If something fails, you can see in Log link the reason for failure.
Figure 4-57 ELB service virtual machines
The ELB instance virtual machines are the actual load balancer virtual machines. The ELB manager is the virtual machine for all ELB-related operations and management. After the ELB proxy service is deployed, click Manage from the instance to open the Virtual Application Console, which is shown in Figure 4-58.
Figure 4-58 Management operation options
For the ELB instances, you can export the server certificate or root signer certificate, as shown in Figure 4-59.
Figure 4-59 Performing operations on the ELB cache service
In the ELB management virtual machine, you can scale in or scale out the number of ELB instances you provisioned for the shared service, as shown in Figure 4-60.
Figure 4-60 Manual scaling the ELB instances
Monitoring
IBM PureApplication System allows virtual applications and systems to use a common, or shared, set of services to provide advanced monitoring capabilities. When deployed, these services are shared between all virtual applications and systems within a cloud group. Each cloud group must have its own instance of a shared service for it to be available.
Links for the system monitoring shared service open a new window by using Java WebStart. At this time, only 32-bit Java is supported. The default view for a virtual application provides a topology view of the components of the application. When you click the Endpoint link for the System Monitoring shared service, the monitoring service opens to the topology view for the shared service. From the topology overview, a deployer can drill into the operating system metrics for each virtual machine that is included in the virtual application.
For more information, see Chapter 8, “Troubleshooting PureApplication System Environment” on page 329.
Media shared service
Often a virtual application deployment requires some form of prerequisite binary media to install (such as binary files on a build server or ISO DVD images). There might be reasons not to package these binary files with the application pattern or components plug-ins. Some of these reasons are licensing, code distribution concerns, or the binary must be updated independently of the application pattern.
In a cloud environment, multiple application deployments might need to reference the same media files. If the required files are on a slower (remote) network outside the cloud, it can take considerable time to download the files into each deployed virtual application.
To solve these problems, we suggest creating a media shared service that hosts a binary file repository for use by any virtual application in the cloud group. The media service can be deployed and loaded with prerequisite files independently of the virtual applications and plug-ins.
Rather than copying files from something outside the cloud each time new application deployments are started, you can copy the files once into the media service VM, which makes them locally available in the cloud. By using this configuration, the administrator can manage this service in a more centralized design versus independent VMs that share no common framework.
The file copy speed from the media service to the virtual application is much faster. It is internal to the rack (the PureApplication System) and cloud group, which allows multiple deployments to quickly access the data.
The following example is a typical flow for the media service:
1. Deploy the shared service/media service.
2. The media service VM starts and is loaded with binary files to share via NFS on the cloud group.
3. Deploy a virtual application that uses the media service (component flag or policy in the pattern).
4. The virtual application asks the media service for the binary file locations or connection information.
5. The virtual application can network file system (NFS) mount the file repository from the media service VM.
6. Repeat the process for multiple virtual application deployments. Each deployment is given access to the shared files via the media service.
A Plug-in Development Kit (PDK) is the product in IBM PureApplication System, which provides a strong starting point to create shared services. For more information, see this website:
For more information about PDK usage, see Chapter 6, “Customizing Virtual Application Patterns” on page 267.
4.6.6 Benefits and trade-offs
To understand what is best for you or your organization, it is useful to review the following benefits and trade-offs of the use of PureApplication System:
•Simplicity: Virtual applications are simple to create, deploy, or monitor. Virtual applications are the quickest way to deploy applications without worrying about the infrastructure configuration. PureApplication System handles deploying applications for you, which reduces much of the complexity.
•Easy-to-use interface: PureApplication System provides an easy-to-use graphical interface to build virtual applications with drag-and-drop features and easy view of over all solution.
•Ease of configuration: PureApplication System handles the infrastructure configuration, set up, and tear down. Having PureApplication System handle the configuration also reduces configuration and deployment time errors, which helps reduce your application deployment time.
•Savings: Significant time and resource savings through the reduction in configuration and deployment times, middleware skill requirements, and configuration and deployment time errors. These savings reduce the required time that is needed to configure and deploy your applications.
•Scalability: Using policy-based features guarantees dynamic scalability. While the virtual application deployment model provides scalability for your web-based applications, it completes this task by using a single server topology.
•Built in shared services available for all virtual applications: Dynamic registration to shared services is a built-in feature in IBM PureApplication System. It provides a simplified consumer (users/application deployments) and provider (implementation/Shared Service deployment) model.
The use of PureApplication System includes the following trade-offs:
•Less control over your environment’s configuration: One potential trade-off with the virtual application deployment model is the lack of control over your environment’s configuration. If you require a specific configuration for your application, you might not be able to use the virtual applications deployment model because of the limited number of customizations available.
•Not ideal for Tier 1 applications: The PureApplication System is ideal for many Tier 2 and Tier 3 application scenarios, but not for Tier 1 applications. While there is some failover capability built into virtual applications, the database components feature limited failover. As a result, this deployment model is not ideal for Tier 1 applications at this time where a high degree of failover capability is required.
•Only web-based applications are supported: Currently, only web-based applications are supported in the virtual application deployment model. Because the full WebSphere Application Server programming model is not supported, you might not be able to use virtual applications for your deployments if your application uses some unsupported functions. For example, remote enterprise beans are not supported in the virtual application deployment model.
•Does not support full scalability and failover: While the virtual application deployment model provides scalability for your web-based applications, it provides this scalability with a single server topology. As a result, the full scalability that is available in the Network Deployment configuration is unavailable. This unavailability means that QoS features such as the HA manager, Core Groups, and Data Replication Services (DRS) are not supported in this environment.
However, the rule of thumb is to review your particular application to see whether you can use this particular deployment model. For more information about application migration, see 4.7, “Implementation strategy” on page 184.
4.7 Implementation strategy
When you consider migrating or creating an application, it is important to understand why you must put your application in a cloud infrastructure that is provided by the IBM PureApplication System. One of the reasons is to support fast business response and workload demands by using a cloud environment. With this reason in mind, you can enable cloud service providers to serve your application as PaaS by using infrastructure, platform, and application patterns in a fast deployment configuration with provisioning.
Based on a cloud environment approach to migration, whether you create an application or migrate an existing one (including code, middleware, and database) consider the following implementation strategy. The best approach for migration is to understand there can be changes in an application lifecycle. Therefore, one solution might not always be applicable.
You should base your decision on your requirements and management needs for the particular application that is considered. Virtual systems can be the best strategy.
For each application, you decide whether the middleware infrastructure-centric approach of virtual system patterns or the application-centric approach of virtual application patterns works best for your organization. You might be driven by the need to support specific configurations that do not easily fit into an existing virtual application pattern type. In that case, you might choose to create your own virtual application pattern type or use a virtual system pattern to create the exact topology that your application requires. This consideration could include replicating a physical environment that you previously implemented. In other cases, you might find that your application fits well into one of the virtual application pattern types that are already provided.
Whenever possible, use the optimization and convenience of a virtual application pattern because this pattern always provides the lowest total cost of ownership and shortest time to value. However, there are scenarios where you require detailed configurations and therefore decide to use the detailed control that is available with virtual system patterns.
The most important thing is to understand all of the options and make an informed decision. Review your use case, understand what is available to help you accomplish that use case, and then decide on what you want your user experience to be.
It is also important to note that IBM PureApplication System supports both of these models concurrently. You can have a mix of virtual applications, virtual systems, and even virtual appliances that are all deployed to the same pool of cloud resources. The robust capabilities that are built into IBM PureApplication System enable these various deployments. By using these capabilities, you can choose the deployment model for each application that delivers the best fit with the highest return on investment.
4.7.1 Questions for consideration in application migration or creation
There are some important questions to consider when you are deciding to use virtual application or virtual system in application migration or creation. This section reviews those questions and provides more information to help you frame what option might work best in your organization. Consider the following list of questions:
1. Are you building a new application?
The simplest deployment model that is offered by PureApplication System is the virtual application. If you are building a new application and can influence the technology and design choices that are made in the application, choose the technology and design that makes an application compatible with a virtual application.
However, in most cases, the applications that you deal with daily are not greenfield applications. Instead, you often deal with an existing pre-built application that runs in an existing environment. You then must consider the next question in this series.
2. Is this application a web application?
What is meant by this question is: Does this application take requests on inbound HTTP or HTTPs only? This more specific question incorporates various patterns in application development. The answer can cover any of the following application types:
– An application that provides RESTful services to a user interface that is written by using JavaScript and Ajax technologies.
– A Web Services provider that implements SOAP services for external clients on the Internet.
– A classic web application that is built with servlets and JavaServer Pages.
However, this definition excludes some application types. For example, consider a Java client/server application that uses a Java thick client that connects through RMI or RMI/IIOP to Enterprise JavaBeans in a back end. This type of application is not defined as a web application that uses this definition. That consideration also leads to the next question.
3. Do you use remote Enterprise JavaBeans?
Enterprise JavaBeans are a useful part of the Java Platform, Enterprise Edition programming model almost since its inception. However, the benefit of remote Enterprise JavaBeans is balanced by a trade-off in the complexity of your application topology. Your application servers must handle incoming HTTP traffic to your servlets, JavaServer Pages, and Web Services, and incoming RMI/IIOP traffic from the Enterprise JavaBeans clients. Usually, this configuration is accomplished through building two tiers of application servers. One tier is dedicated to handling HTTP traffic, and the other is dedicated to handling RMI traffic. As part of the simplification process that uses virtual applications, you must give up some of these topological options. If you need remote Enterprise JavaBeans, use virtual systems where these topology options are available for your use.
4. Is your application packaged in a standard way?
In this case, standard packaging is considered packaging as an EAR file, WAR file, compressed archive, or an OSGi Enterprise Bundle Archive (EBA). Although the Java Platform, Enterprise Edition standard is to package applications as EAR or WAR files, and the OSGi Standard introduced EBA archives, many applications are still not packaged that way. Instead, they are shipped as exploded directory structures. While that format might work for simple servers such as Tomcat, a nonstandard way makes it complicated to move to new Java Platform, Enterprise Edition servers, such as the ones that support virtual applications. It is best to repackage your application in one of these standard formats. There are many other packaging strategies in WebSphere Application Server that you might want to use; for instance, server associated shared libraries. Again, to simplify the model, these strategies are not used in virtual applications. If you cannot avoid the use of these approaches, then consider the use of virtual systems instead.
5. Is your application using standard Java Platform, Enterprise Edition programming models?
An old phrase states that “One of the great things about standards is that there are so many of them to choose from.” Unfortunately, this statement is true when you are speaking about programming models. New APIs are introduced at a rapid pace. The Java community process is littered with the remains of Java Specification Requests that were never approved or never gained wide enough acceptance to officially become part of the Java Platform, Enterprise Edition standard. The problem is that with virtual applications, you want to keep things simple. Therefore, you must restrict the set of APIs that are supported to a manageable set. If your application uses only standard APIs from JEE5, J2EE (1.4, 1.3, or 1.2), OSGi, JPA, JAX-RPC, JAX-WS, and JAX-RS, you should be fine.
If you are writing to a newer Java Platform, Enterprise Edition level (such as Java Platform, Enterprise Edition 6), or are using some obscure API from deep within the bowels of the Java Community Process, your application probably does not work as a virtual application. IBM takes the approach to offer support for newer APIs through Feature Packs. If you are planning for a new API level, consider building a virtual system by using WebSphere Application Server V8 and incorporating the Feature Pack (and support for that API) when it becomes available.
6. Does this application run on WebSphere Application Server Version 7 or Version 8?
There are different answers to this question to consider. If your answer to this question is yes, but you fall into one of the previous categories that addressed the programming model, packaging, or use of remote Enterprise JavaBeans, your decision is already made for you. Your application cannot be a virtual application. If you answer no, you might still be able to run as a virtual application. If your application is compliant with the previous programming model questions and packaging questions, there is a possibility to run as a virtual application. If your application is running on a much earlier version of WebSphere Application Server or on another application server, there is another consideration. You might have a migration effort to complete first before you can move to a virtual application or a virtual system.
7. Does your application require any WebSphere family products like WebSphere Portal Server or WebSphere Process Server?
The virtual application approach is targeted at building Web applications. If your application type (or workload) is not a web application, the current virtual application approach is not appropriate for you. This statement is purely a point in time statement. New workload types will be added to PureApplication System over time. Also, even if you have a business process management application, you can take advantage of the higher levels of automation that virtual applications offer to web applications today. However, at this moment, if you require any of these products to support your business process application such as WebSphere Process Server or you web application such as WebSphere Portal, you must build a virtual system. These patterns can be obtained separately through PureSystems Centre.
8. Is your application ready to take advantage of session management with WebSphere eXtreme Scale?
Essentially, you must first consider your use of the HttpSession API. Many applications are written in a stateless way and do not use the HttpSession API. Those applications are perfectly suited for virtual applications. However, if you are using HttpSessions in your application, you must consider how you use them.
Review if all the contents of your HttpSession are declared to be java.io.Serializable. If not, you have an issue to manage. The model that scaling policies follow for virtual applications is designed so that application server instances can be dynamically created and deleted as needed, which is done to handle the amount of load that an application is taking on at any time. If you assume that your server is long-lived and its memory is a safe repository for session information if you try to implement a virtual application, your application cannot work as designed.
Likewise, if your sessions are large (hundreds of megabytes), you can have problems by the time it takes to load a session over the network from the WebSphere eXtreme Scale grid. If you have small, serializable sessions that are compliant with HttpSession best practices, you can use virtual applications. Ensure that your HttpSession objects are small and serialized. If they are, you can use virtual application pattern. If they are not, you must change your code to use virtual application or you must use virtual system pattern.
9. Does your application use an external security product or does it use special security APIs such as Trust Authentication Interceptors (TAI) or Java Authentication and Authorization Service plug-ins?
Consider the security requirements that are placed on your application. If your application does not have security requirements or uses WebSphere security such as local OS security, you can implement your system as a virtual application. Also, if your WebSphere security uses one of the supported user registries (IBM Tivoli Directory Server, Microsoft Active Directory), you can also implement your system as a virtual application. However, if you use a separate security product such as Tivoli Authentication Manager, a competitor product, or any of the special WebSphere Security features like Java Authentication and Authorization Service or TAIs, you must plan to build a virtual system.
10. Consider the scenario: Your application does not conform to the constraints of any PureApplication System virtual application patterns. Your application also does not have a complete, reusable, reliable set of deployment and configuration scripts. What is the best strategy?
The best strategy for this situation is to use virtual system patterns because this pattern type allows a wide set of customization options. You must create scripts to complete your configuring work. Another option is to use Advanced Middleware Configuration to capture your environment and create repeatable and deployable virtual system patterns.
Picking the correct approach at the optimum time
Applications have lifecycles and a single deployment model might not hold for the entire lifetime of the application. For instance, you might want to deploy an application in your development and test environments as a virtual application. This deployment is the simplest model and ensures that you correctly capture the configuration parameters (like the Java virtual machine policy) in those environments. However, you might want to deploy as a virtual system in production to set up the most highly optimized environment for that application. Likewise, you might change the code in later versions of an existing application that is deployed as a virtual system to make it compatible for deployment as a virtual application.
4.7.2 Database best practices to deploy
In the context of PureApplication System, there are multiple ways to deploy or configure a database. Because IBM DB2 software is integrated inside PureApplication System, the use of DB2 as a deployed application's database involves no extra costs. Thus, there is a reduction in overhead and other license tracking mechanisms. This inherent benefit of DB2 in PureApplication System reduces the total cost of ownership of the platform. The unified nature of DB2 within PureApplication System allows for best practices and expert-focused integration to be applied and followed throughout an application's use of DB2 as the database back end service.
DB2 patterns in IBM PureApplication System
IBM PureApplication System features the following options for DB2 patterns:
•DB2 virtual system patterns that are described in “DB2 virtual system patterns” on page 128.
•DB2 database workload patterns that are described in “IBM Database Patterns” on page 160.
DB2 SQL compatibility feature
For users that have not used IBM DB2 software as a database solution before, PureApplication System is an excellent environment to evaluate DB2 for production deployments with the existing enterprise applications. By using the DB2 virtual system and database workload patterns, you can enable an SQL compatibility mode to assist with migrations of applications that are written to use other competing database software. With this feature enabled, native SQL that is written for other competing databases is compiled natively in the DB2 engine without the use of slow emulation software. A compatible data concurrency model also is available. DB2 also includes tools that are compatible with existing scripts and personnel skills, which simplifies the transition to DB2.
For more information about the DB2 SQL compatibility feature, see this website:
Using a remote database outside of PureApplication System
In some use cases, you might need a deployed application within PureApplication System to access and link to a remote database system. For example, perhaps performance and other criteria categorized a particular database workload to be in a mission critical tier one database category. Thus, a dedicated physical system is required to host such a database system.
When a virtual application pattern is defined, you can attach existing remote database components to the pattern. These databases are outside of PureApplication System. The configuration properties of these components define the connection parameters to the remote database.
Choosing a database
The following steps are a simplified procedure for choosing a database deployment for an associated application in PureApplication System:
1. Use the DB2 database workload patterns. These patterns already incorporate best practice guidelines in their implementation of DB2. If needed, create and reference a database workload standard to apply the changes in the configuration to an associated application.
2. Because of performance or other criteria, you might choose to have the database outside of PureApplication System. If the database is outside, use an appropriate interface to attach an existing remote database component into a virtual application pattern.
3. If DB2 database workload patterns are too restrictive to use with an application, use a DB2 virtual system pattern. By using these patterns, you have greater flexibility to control this middleware environment.
For more information about procedures for deployment of DB2 in PureApplication System, see this website:
4.8 PureSystems Centre
Use the PureSystems Centre site to access solutions from IBM and IBM Business Partners, updates to systems and solutions, and expertise for maximizing the benefit of systems and solutions.
The PureSystems Centre offers a simplified experience for PureSystems users to obtain PureSystems optimized content, fixes, updates, and access to IBM and IBM Partner expertise.
Accessing the PureSystems Centre
Complete the following steps to access information about PureApplication System in the PureSystems Centre:
1. Browse to this website:
2. On the welcome page, select PureApplication System, then select Browse Solutions, as shown Figure 4-61 on page 190.
Figure 4-61 PureSystems Welcome page
You also can access the PureSystems Centre by completing the following steps:
1. From the IBM PureApplication System console, you can access PureSystems Centre, as shown in Figure 4-62.
Figure 4-62 PureSystems Centre access from IBM PureApplication System console
2. Click the Browse IBM PureSystems Centre for additional solutions link to go directly to the Browse solutions tab, as shown Figure 4-63.
Figure 4-63 PureSystems Centre Browse solutions
Selecting a provider
From the PureSystems Centre main menu, select PureApplication System → Browse Solutions. There are two main providers, IBM and IBM Partners, as shown in Figure 4-64.
Figure 4-64 PureSystems Centre providers
IBM as the provider
When you select IBM as the provider, a list of offerings for IBM PureApplication System are displayed, as shown in Figure 4-65.
Figure 4-65 IBM Provider view
The list shows all of the IBM offerings that extend current IBM PureApplication System built-in virtual image offerings. To see the built-in images that are supported in IBM PureApplication System, see the following websites:
For example, consider that you must get an IBM Business Intelligence Pattern for your solution. Select the IBM Business Intelligence Pattern, scroll down and select Purchase, as shown in Figure 4-66.
Figure 4-66 Selecting a pattern to purchase
Continue through the purchase process to the section where you select media packs (CD-ROMs, DVDs). Your order is processed.
IBM Partners
Selecting IBM Partners in the provider list shows a complete list of partners that produce patterns or solutions for IBM PureApplication System, as shown in Figure 4-67. You can select a Partner, learn more about the solutions, and follow the necessary links on that solution's page.
Figure 4-67 IBM Partners view
Asking an expert
From the main page, you can select the Ask an Expert tab (as shown in Figure 4-68) to get answers to your questions by using the knowledge base of community experts. This section offers the opportunity for you to contribute. To contribute on this site, you must be registered.
Figure 4-68 Ask an Expert view
Library
By selecting the Library tab on the main menu (Figure 4-69), you can search for topics about which you want to learn more information. This tab contains web articles, information center topics, and IBM Education articles. The library contains a breadth of knowledge, resources spanning initial information, overviews, and in-depth documentation and videos to help you learn about IBM PureSystems.
Figure 4-69 Library view
Browse updates
From the PureSystems Centre welcome page, select PureApplication System, in which there is an option is to view the updates. Select Browse Updates, as shown in Figure 4-70.
Figure 4-70 Browse updates
A list of PureApplication System fix packs (firmware and system updates for a specific version) and Group Fix Updates (updates for add-ons and shared services) are displayed, as shown in Figure 4-71.
Figure 4-71 Available updates
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.