public.dhe.ibm.compublic.dhe.ibm.com/software/dw/wes/1405_woolf/PureAppAdoptionS… · Adoption...

A comprehensive task-based handbook for using IBM PureApplication System May 2014

Adoption Scenarios for IBM PureApplication System

Rajeev Gandhi Senior Technical Staff Member Venkata Gadepalli Senior Management Consultant Kyle Brown Distinguished Engineer Bobby Woolf Certified Consulting IT Specialist IBM Software Services for WebSphere

Copyright © 2014 IBM Corporation

Adoption Scenarios for PureApplication System

Table of Contents

Table of Contents............................................................................................................ 2 1 Introduction................................................................................................................. 6 2 Stories ........................................................................................................................ 8

2.1 Install and setup system ...................................................................................... 8 2.2 Determine and develop patterns.......................................................................... 8 2.3 Develop a data architecture............................................................................... 10 2.4 Determining the pattern for an application ....................................................... 10 2.5 Deploy and manage workloads......................................................................... 11 2.6 Monitor and manage system ............................................................................. 12 2.7 Dynamically reconfigure resources .................................................................. 13 2.8 Dynamically add new capacity ......................................................................... 13

3 Use cases................................................................................................................... 14 3.1 Administrative setup ......................................................................................... 14

3.1.1 Install system ............................................................................................ 14 3.1.2 Setup authentication.................................................................................. 15 3.1.3 Configure system ...................................................................................... 16 3.1.4 Setup cloud environment .......................................................................... 16 3.1.5 Additional customization .......................................................................... 17

3.2 Administrative management ............................................................................. 18 3.2.1 Add new user groups ................................................................................ 18 3.2.2 Add IP addresses....................................................................................... 19 3.2.3 Add VLANs to the customer network ...................................................... 20 3.2.4 Add product licenses................................................................................. 21 3.2.5 Reallocate computing resources ............................................................... 22 3.2.6 Expand system size ................................................................................... 22 3.2.7 Replace failing hardware .......................................................................... 23 3.2.8 Recover failed management nodes ........................................................... 24 3.2.9 Upgrade system version............................................................................ 24

3.3 Workload........................................................................................................... 27 3.3.1 Develop virtual application pattern........................................................... 27 3.3.2 Develop virtual system pattern ................................................................. 28 3.3.3 Develop DBaaS pattern............................................................................. 29 3.3.4 Develop DB2 virtual system pattern......................................................... 30 3.3.5 Maintain virtual application pattern.......................................................... 31 3.3.6 Maintain virtual system pattern ................................................................ 32 3.3.7 Evaluate virtual application readiness ...................................................... 33 3.3.8 Evaluate existing virtual system patterns.................................................. 34

3.4 Deployment....................................................................................................... 35 3.4.1 Allocate cloud resources ........................................................................... 35 3.4.2 Deploy shared services ............................................................................. 37 3.4.3 Deploy pattern........................................................................................... 39 3.4.4 Deploying for DR ..................................................................................... 40

3.5 Development ..................................................................................................... 41 3.5.1 Plan development teams ........................................................................... 42

Copyright © 2014 IBM Corporation 2 / 137


3.6 Monitoring and management ............................................................................ 42 3.6.1 Monitor system and workloads................................................................. 43 3.6.2 Maintain workload .................................................................................... 44 3.6.3 Tune virtual machine ................................................................................ 47 3.6.4 Troubleshooting ........................................................................................ 47 3.6.5 Incident management ................................................................................ 49

4 Tasks ......................................................................................................................... 51 4.1 IBM CE............................................................................................................. 51

4.1.1 Ship hardware ........................................................................................... 51 4.1.2 Perform physical installation .................................................................... 52 4.1.3 Update system software ............................................................................ 52 4.1.4 Perform software installation.................................................................... 53 4.1.5 Replace hardware...................................................................................... 55 4.1.6 Install additional compute node ................................................................ 56 4.1.7 Restore a management node ..................................................................... 56 4.1.8 Perform system restore ............................................................................. 57

4.2 Data center operations – Configure .................................................................. 58 4.2.1 Complete TDA.......................................................................................... 58 4.2.2 Position hardware...................................................................................... 58 4.2.3 Configure LDAP settings.......................................................................... 59 4.2.4 Configure users ......................................................................................... 60 4.2.5 Configure user groups............................................................................... 60 4.2.6 Add roles to a user or group...................................................................... 61 4.2.7 Configure network settings ....................................................................... 62 4.2.8 Configure DNS settings ............................................................................ 62 4.2.9 Configure NTP settings............................................................................. 63 4.2.10 Configure SMTP settings.......................................................................... 63 4.2.11 Configure SNMP settings ......................................................................... 64 4.2.12 Configure IP groups.................................................................................. 65 4.2.13 Configure cloud groups............................................................................. 66 4.2.14 Configure for high availability.................................................................. 67 4.2.15 Configure product licenses ....................................................................... 68 4.2.16 Configure system backup.......................................................................... 68 4.2.17 Script system configuration tasks ............................................................. 69 4.2.18 Consider appliance service upgrades ........................................................ 70

4.3 Data center operations – Manage...................................................................... 71 4.3.1 Monitor support resources ........................................................................ 71 4.3.2 Contact support ......................................................................................... 72 4.3.3 Collect system logs ................................................................................... 73 4.3.4 Enable system trace................................................................................... 74 4.3.5 Schedule IBM CE ..................................................................................... 74 4.3.6 Enable the IBMENG account ................................................................... 75 4.3.7 Purchase additional computing capacity................................................... 75 4.3.8 Remove compute node from cloud group................................................. 76 4.3.9 Add compute node to cloud group............................................................ 77 4.3.10 Monitor hardware...................................................................................... 77



4.3.11 Monitor events and problems.................................................................... 78 4.3.12 Monitor job queue..................................................................................... 79 4.3.13 View activity reports................................................................................. 79 4.3.14 Monitor product licenses........................................................................... 80

4.4 Application operations – Cloud admin ............................................................. 80 4.4.1 Deploy base service for internal monitoring............................................. 80 4.4.2 Deploy base service for external monitoring ............................................ 81 4.4.3 Deploy middleware monitoring services .................................................. 83 4.4.4 Deploy database monitoring service......................................................... 84 4.4.5 Deploy caching service ............................................................................. 85 4.4.6 Deploy elasticity service ........................................................................... 86 4.4.7 Deploy Red Hat update service................................................................. 86 4.4.8 Deploy endpoint management service ...................................................... 88 4.4.9 Update existing shared service instance ................................................... 89

4.5 Application operations – Middleware admin.................................................... 89 4.5.1 Create environment profile ....................................................................... 89 4.5.2 Deploy a virtual application or DBaaS pattern ......................................... 91 4.5.3 Deploy a virtual system pattern ................................................................ 91 4.5.4 Apply fix to virtual system instance ......................................................... 92 4.5.5 Apply fix to WebSphere virtual application or DBaaS instance .............. 93 4.5.6 Apply updates to virtual application instance........................................... 94 4.5.7 Apply fix to DB2 HADR instance ............................................................ 94 4.5.8 View virtual machine status...................................................................... 95 4.5.9 Administer virtual machines ..................................................................... 96 4.5.10 Add storage to a virtual machine .............................................................. 97 4.5.11 Log into a virtual machine ........................................................................ 97 4.5.12 View workload status................................................................................ 98 4.5.13 Enable workload trace............................................................................... 99 4.5.14 View Storehouse browser ....................................................................... 100 4.5.15 Program application monitoring ............................................................. 100 4.5.16 Monitor middleware................................................................................ 101 4.5.17 Delete workload instance when not needed............................................ 102 4.5.18 Script workload management tasks ........................................................ 103 4.5.19 Perform application data restore ............................................................. 104 4.5.20 Implement pattern deployment lease policies......................................... 105 4.5.21 Maintain RHEL on virtual machine........................................................ 106 4.5.22 Deploy DB2 HADR for database disaster recovery ............................... 107 4.5.23 Deploy GPFS for disaster recovery ........................................................ 107 4.5.24 Enable GPFS on a virtual system instance ............................................. 108 4.5.25 Deploy application code into a virtual system instance.......................... 109

4.6 Database operations ........................................................................................ 110 4.6.1 Database data restore .............................................................................. 110

4.7 Finance and compliance.................................................................................. 111 4.7.1 Configure external audit logging ............................................................ 111 4.7.2 Script auditing tasks................................................................................ 112 4.7.3 Review audit logs.................................................................................... 113



4.7.4 Chargeback for resource usage ............................................................... 113 4.7.5 Review system upgrade or new racks requests....................................... 114

4.8 Content enablement ........................................................................................ 114 4.8.1 Import virtual image ............................................................................... 114 4.8.2 Export virtual application pattern ........................................................... 115 4.8.3 Export virtual system pattern .................................................................. 116 4.8.4 Import virtual application pattern ........................................................... 116 4.8.5 Import virtual system pattern .................................................................. 117 4.8.6 Import and install virtual application components.................................. 118 4.8.7 Develop custom image using extend and capture................................... 119 4.8.8 Develop custom image using ICCT........................................................ 119 4.8.9 Develop script package ........................................................................... 121 4.8.10 Develop add-on....................................................................................... 122 4.8.11 Create and edit virtual system patterns ................................................... 123 4.8.12 Create and edit virtual application and DBaaS patterns ......................... 123 4.8.13 Install and configure application backup ................................................ 124 4.8.14 Develop virtual application component .................................................. 125 4.8.15 Add fix to virtual image.......................................................................... 126 4.8.16 Apply fix to virtual system pattern ......................................................... 126 4.8.17 Apply fix to virtual application pattern................................................... 127 4.8.18 SCM of workload catalog ....................................................................... 128 4.8.19 Configure authorization .......................................................................... 129 4.8.20 Enabling DB2 HADR for disaster recovery in virtual system pattern.... 130 4.8.21 Enabling GPFS for disaster recovery in virtual system pattern.............. 131 4.8.22 Enabling GPFS for disaster recovery in virtual application pattern ....... 132

4.9 Application architecture.................................................................................. 132 4.9.1 Select appropriate pattern for an application .......................................... 132 4.9.2 Create DevOps environment................................................................... 133

4.10 Application development ................................................................................ 134 4.10.1 Determine the pattern to use for your application .................................. 134 4.10.2 Other tasks .............................................................................................. 135

4.11 Database administration.................................................................................. 135 4.11.1 Configure database monitoring service .................................................. 135 4.11.2 Other tasks .............................................................................................. 136

5 Resources ................................................................................................................ 137



1 Introduction This document explains how to be successful with IBM® PureApplication® System. It endeavors to explain all work necessary to make use of the system, from taking delivery at the data center to using it to host production applications as cloud-enabled workloads. It explains this work in terms of reusable use cases and tasks, standardized procedures that can be combined and repeated as necessary to produce solutions customized to evolving needs. It does not document features of the product; it documents how to use them to produce successful outcomes. With this guidance, you and your organization have the know-how to successfully achieve your goals predictably and reliably.

While this paper can be read alone, it is best understood as the third in a three-part series:

1. Best practices for patterns adoption in IBM PureApplication System – This article lays out a series of best practices for how to best adopt patterns into your organization to take best advantage of PureApplication System.

2. Organizational structure in PureApplication System operations – This article describes the transformative effect that PureApplication System can have on your IT organization, and which roles should be present to get the most out of the technology.

3. Adoption Scenarios for IBM PureApplication System – This paper describes in detail which tasks the roles in the second article should carry out in order to implement the best practices described in the first article.

This document is organized into three layers with the following relationships:

Stories – These discuss the major reasons why an organization would use PureApplication System, defining goals that set the stage for describing how to use it. Each story leads to a set of use cases.

Use cases – These discuss how to use the system in terms of broad scenarios. Each is a repeatable, governable process that takes a period of time to perform and involves multiple people performing coordinated tasks. This paper organizes them into role categories that correspond to the teams that will use the system.

Tasks – These discuss repeatable units of work performed by individuals that correspond roughly to product features. This paper organizes them into roles that correspond to the types of users who use the system.

Where you begin reading this document depends on the level of detail with which you want to start:

Executives – Start with section 2 Stories, which gives an overview of the major functionality promised by PureApplication System. This leads to the use cases for how to use the system to achieve this functionality.

Team leads – Start with section 3 Use cases, specifically the subsection for the roles category corresponding to your team’s purpose. (For example, if your team is responsible for developing patterns, go to section 3.3 Workload.) These are


http://www.ibm.com/developerworks/websphere/techjournal/1307_brown1/1307_brown1.html



plans of action for fulfilling the stories, and in turn compose collaborations of people performing individual tasks.

Team members – Start with section 4 Tasks, specifically the subsection for the role corresponding to your responsibilities. (For example, if you personally are responsible for maintaining applications while they are running, go to section 4.5 Application operations – Middleware admin.) The use cases are fulfilled by you performing your tasks collaboratively with others performing their tasks. By learning the tasks in your role, you will be prepared to perform your responsibilities within the team.



2 Stories IBM PureApplication System (W1500 and W1700 v1.0 and v1.1) is a cloud computing system-in-a-box with integrated hardware and software to deploy and execute workloads in a cloud — in other words, everything an enterprise data center needs to add a private cloud environment. To explain how to be successful with it, let’s start by reviewing the major capabilities offered by PureApplication System. For each, we’ll discuss what functionality that capability provides and the use cases for taking advantage of that functionality.

2.1 Install and setup system A big part of the value of PureApplication System is that it is an appliance that comes from the factory very nearly ready to provide immediate return on your investment. However, there are a few physical installation and configuration steps that need to be done, followed by some basic software configuration that is required before the PureApplication System can be used for its intended purpose.

First, the system needs to be physically installed into a data center; that work is primarily performed by IBM, with help and assistance from the customer. This involves physically moving in the rack, then connecting it to power and networking. Then, administrative security has to be set up so that the appliance can remain secure through the rest of its configuration. Once the box is physically connected to the network, you can set up the networking configuration that enables the system to talk to the rest of your data center network. Finally, you need to “divide up” the resources in the rack into different secure and isolated partitions for the different purposes (for example, development and production) that it will be used for. Once this has happened, you might also need to start up “shared services” for common tasks like monitoring and elasticity within these partitions that are used by the applications. Typically, this entire set of actions can be performed within a 36 hour period (or less), enabling you to move on to the next set of stories as quickly as possible.

Performing the initial system configuration involves this set of use cases:

3.1.1 Install system – Making the system available in your data center

3.1.2 Setup authentication – Configuring who can log into the system

3.1.3 Configure system – Configuring the rest of how the system interfaces with your data center

3.1.4 Setup cloud environment – Configuring the cloud that will host your workloads

3.1.5 Additional customization – Configuring the more advanced, optional features of the system

2.2 Determine and develop patterns Patterns are a central feature of the way in which users work with PureApplication System. In general terms, a pattern is a reusable approach for solving a particular set of problems that developers encounter. In PureApplication System, our patterns are reusable



middleware topologies that can be used with many similar customer applications. For example, installing and configuring IBM WebSphere® Application Server for a production environment can be a complex and time consuming endeavor. Patterns, like the WebSphere Application Server pattern, simplify this by providing reusable topologies that a developer, tester, or system administrator can just choose from a catalog.

Think of patterns as a cookie cutter; you choose the shape you want — say a WebSphere Application Server installation or an IBM BPM installation — and then “stamp out” many copies for the different purposes you need. IBM ships a number of patterns with PureApplication System, including patterns for WebSphere Application Server and IBM DB2® products, but each pattern will usually need to be customized to a specific user environment. This is because each user has different corporate security standards, networking standards, preferred automation tooling, and other standards that influence the way that the “instances” created from the patterns will be used.

Therefore, the next major set of activities that a customer team will need to carry out after installing the system is developing new patterns content, or modifying existing patterns to suit their needs. PureApplication System supports two types of patterns:

1. Virtual system patterns are straightforward middleware topology templates that create environments very much like those that most teams are currently using.

2. Virtual application patterns are a more advanced, policy-driven approach to creating topologies that can dynamically resize themselves and add support for other non-functional requirements through configuration.

As part of this set of activities, your team will need to determine which patterns to build or customize, and which type of pattern you will need to develop. Over time, these patterns will need to be modified to deal with new requirements emerging from development teams’ efforts to on-board applications. Alternatively, new versions of supported software will also come out from vendors like IBM, necessitating changes in the patterns to support the new versions.

Determining the patterns to develop and developing them involves this set of use cases:

3.3.1 Develop virtual application pattern – Implement an application topology that manages itself

3.3.2 Develop virtual system pattern – Implement an application topology you can configure in greater detail

3.3.3 Develop DBaaS pattern – Implement a database topology

3.3.5 Maintain virtual application pattern – Update an application topology that manages itself

3.3.6 Maintain virtual system pattern – Update an application topology you can configure in greater detail



2.3 Develop a data architecture PureApplication System has the built-in capability to provide hosting of DB2 databases. However, this is not the best solution for all possible data hosting problems. One of the ways in which a team needs to think through how to best leverage the capabilities offered by PureApplication System is by developing a comprehensive data architecture that involves PureApplication System. Some of the considerations that enter into this data architecture are:

How large are your databases? PureApplication System in its current form has a fixed storage capacity of 54.4 terabytes. Devoting the entire storage capacity of the entire appliance to one or two databases might not be a good use of its capabilities.

How many processors does your database processing take? PureApplication System also has a limitation that a single database cannot take up more cores than are contained in a single compute node. Therefore, on Power, the maximum number of cores you can assign to processing queries and updates for a single database instance is 32, while on Intel it is 16 due to the differences in the node architecture between the two.

As a result, databases that require more processing or storage capacity than PureApplication System can provide are not a good fit for implementation on the system. Instead, we would recommend that a better solution for these larger databases is IBM PureData™ for Transactions; this appliance offers a larger storage capacity, and its special implementation of DB2 enables the assignment of hundreds of cores to a particular database. Another potential hosting solution would be to host these databases on traditional pSeries or zSeries hardware. Given this recommendation, what we find is that the best type of databases that should be hosted on PureApplication System are what we refer to as “Tier 2” databases. These include configuration databases for products like IBM BPM or IBM WebSphere Portal, as well as test databases, and smaller, departmental databases. These can be deployed in a high availability configuration within a single machine, or in a DR-style solution across multiple PureApplication Systems. With this in mind, the next decision that has to be made is whether to host each database in a more traditional virtual system configuration, or in a Database as a Service (DBaaS) approach.

The following set of use cases address determining which database approach to take:

3.3.3 Develop DBaaS pattern – Developing a virtual application pattern to host databases

3.3.4 Develop DB2 virtual system pattern – Developing a virtual system pattern to host databases

2.4 Determining the pattern for an application On-boarding an application is the process of matching the requirements of an application to the capabilities and services provided by existing patterns, and either selecting an existing pattern in which to deploy your application, or determining that either an existing



pattern needs to be modified to be compatible with your application’s requirements or to create an entirely new pattern.

In any case, the first step is to evaluate your application for virtual application readiness. Virtual applications provide the most complete set of desirable features for application deployment, such as autoscaling. After evaluating your application, if it turns out that the application can be deployed as a virtual application, then the next step is to develop a virtual application pattern. If it turns out for any reason that the application is not suitable for virtual application deployment, then the next step is to evaluate existing virtual system patterns to see if a pattern match exists. If an existing matching virtual system pattern does not exist, then the next step is to either develop a new virtual system pattern or extend an existing virtual system pattern.

Determining the patterns to use for hosting your application involves this set of use cases:

3.3.7 Evaluate virtual application readiness – Can your application be deployed as a virtual application?

3.3.1 Develop virtual application pattern – If a virtual application pattern suitable for your application does not already exist, create one.

3.3.8 Evaluate existing virtual system patterns – Does a virtual system pattern suitable for your application already exist?

3.3.2 Develop virtual system pattern – If a virtual system pattern suitable for your application does not already exist, create one.

3.5.1 Plan development teams – Organize the developers who will use the patterns to deploy their applications.

2.5 Deploy and manage workloads Simply creating new patterns or customizing existing patterns does not, however, provide the value from PureApplication System that it promises. In order to gain the business value in terms of increased productivity and reduced errors that patterns promise, someone has to use those patterns to build environments that are used in the software development lifecycle. We define the combination of a pattern instance and an application running on that pattern instance as a workload.

Workloads are used in many different ways, and by many different roles. Application developers can perform their development and unit testing inside pattern instances set aside for development. Application testers can perform their integration testing, system testing, and performance testing inside pattern instances set aside for those purposes. System administrators can create pattern instances for use in production environments. In every case, the environments built from the same pattern will be completely consistent, and the construction process will both be very rapid (usually 30 minutes or so) and completely repeatable.

In order to prepare for this, though, your corresponding teams (development team, test team, production management team, and so on) need to gain access to particular patterns in the catalog and to the particular cloud resources set aside for use by those teams. Administrators create environment profiles to provide this access. After a pattern has



been deployed, or as part of the deployment process (at least for virtual application patterns) the application files (deployment artifacts like JAR and WAR files, or configuration files) need to be deployed onto the pattern instance to finish its transformation into a complete workload. Once a team member has deployed a pattern to build a particular environment, they can use the built-in monitoring infrastructure provided by PureApplication System to observe resource consumption, diagnose issues, and gain the information needed to perform capacity planning. That knowledge might lead you to tune the virtual machines that the pattern instances are comprised of.

Finally, once an environment has been built, things will go wrong. Thus, you will need to be able to perform incident management and troubleshoot problems when they occur. As a result of that troubleshooting, you may need to perform patches on the instance itself to provide emergency production fixes, address zero-day security exploit patches, or address other critical issues.

Deploying your application as a workload and managing the workload involves this set of use cases:

3.4.1 Allocate cloud resources – Set aside a portion of the cloud for your workloads to use

3.4.2 Deploy shared service – Add common functionality to your cloud that your workloads will share

3.4.3 Deploy pattern – Create a middleware topology environment for your application to run in and deploy your application in that environment

3.4.4 Deploying for DR – Deploy a single logical pattern as two instances distributed across two systems and configured for disaster recovery

3.6.2 Maintain workload – Once the workload is running, keep it updated

3.6.3 Tune virtual machine – Once the workload is running, adjust the resources available to a VM

3.6.4 Troubleshooting – Find the root cause of one or more problems

3.6.5 Incident management – Get help from IBM to solve a problem

2.6 Monitor and manage system Once different software development and application operations teams begin using the PureApplication System, system administrators will have to observe the utilization of the different shared infrastructure resources (compute, storage, and networking) and determine if problems are occurring in the underlying infrastructure, or if the resources are being used in the most efficient way possible. If the system is not being used efficiently, or if more resources are required, the system administrator may need to change the allocation of the resources available among the different teams. If a hardware element develops a fault, it may need to be replaced, and in the meantime, work should be reallocated around it.

Managing the system that hosts the workloads involves this set of use cases:



3.6.1 Monitor system and workloads – Top to bottom monitoring of the system as a whole, its workloads, and the hardware on which they are running

3.2.5 Reallocate computing resources – Reassign hardware between clouds

3.2.7 Replace failing hardware – Resolve hardware failures

3.2.8 Recover failed management nodes – Resolve management node failures

3.2.9 Upgrade system version – Install a new version of the system software and firmware

3.6.4 Troubleshooting – Find the root cause of one or more problems

3.6.5 Incident management – Get help from IBM to solve a problem

2.7 Dynamically reconfigure resources As much as you try to configure the system for your organization’s requirements, that configuration will sometimes need to change, due to evolving requirements and an evolving understanding of the requirements. New user groups will be needed to more finely separate who can do what. You’ll deploy more pattern instances than you anticipated, so you’ll need more IP addresses – maybe even more virtual networks and more product licenses. These can all be adjusted without causing a system outage.

Rearranging the existing capacity within the cloud environment involves this set of use cases:

3.2.5 Reallocate computing resources – Reassign hardware between clouds

3.2.1 Add new user groups – Group users to align them with permissions

3.2.2 Add IP addresses – More IP addresses so you can deploy more VMs

3.2.3 Add VLANs to the customer network – More separate paths of communication so that your applications can communicate independently

3.2.4 Add product licenses – More licenses so that you can deploy more pattern instances that use them

2.8 Dynamically add new capacity The PureApplication System is an expandable system. It can be configured with as few as 32 cores, or as many as 608 cores. These new compute resources become available as new compute nodes (also known as blades) are physically added to the system, which can occur without incurring any outages. An IBM engineer can configure the system to accept new compute nodes that you purchase, and your system administrators can then make those new computing resources available to your development and operations teams by allocating the new compute resources to those teams.

Increasing the existing capacity within the cloud environment involves this set of use cases:

3.2.6 Expand system size – Purchase and install additional computing capacity



3 Use cases Next, let’s consider the broad scenarios for using the system. These include everything you need to do to use the system, from setting up and maintaining the system, to developing patterns, deploying them, and maintaining the running workloads. Each use case is a repeatable endeavor, but a complex one that typically takes place over a period of time and involves multiple people performing coordinated tasks. They help you think about and understand the major scenarios for using the system that you should be prepared to perform and should be performing as needed.

Most use cases are performed as collaborations amongst members of your staff; that is, the members of the organization that owns the system. An exception is the use cases for setting up, changing, and fixing the system; those require collaboration between the client’s system administrators and the IBM CEs, who are employees of IBM who perform work in your data center.

The use cases are grouped by the category of roles for an entire team. A team will typically focus on a particular category, enabling it to focus on learning that set of use cases and preparing to execute them.

Use Case Category Description 3.1 Administrative setup Initial setup of the system 3.2 Administrative management Ongoing management of the system 3.3 Workload Creation of patterns for deploying applications 3.4 Deployment Installing applications as pattern instances 3.5 Development Creation of applications using patterns for testing 3.6 Monitoring and management Keeping the system and its workloads running well

3.1 Administrative setup These use cases install and configure your new PureApplication System so that you can start using it to develop and deploy patterns. As shown in the table below, they should be performed in sequence, although some are mandatory while others can be deferred. The system must be installed and must have a cloud environment defined. It is preferable to also define a user registry and refine the system settings, however this is not absolutely required and can be done after defining the cloud environment. The advanced settings are not required but make the system more robust.

Use Case Priority Description 3.1.1 Install system Highest IBM enables your system 3.1.2 Setup authentication Medium Users other than “admin” 3.1.3 Configure system Medium Settings other than TDA’s 3.1.4 Setup cloud environment Highest Pattern deployment runtime 3.1.5 Additional customization Lowest System robustness

3.1.1 Install system This is what to do when PureApplication System arrives in the data center, so as to install the rack in the data center, power it up, and connect it to the client data center network.



3.1.1.1 Preconditions The customer has ordered a system and specified the data center to which it will be shipped.

3.1.1.2 Result The system is now installed and ready for you to configure.

3.1.1.3 Tasks Task Role 4.2.1 Complete TDA Data center operations 4.1.1 Ship hardware IBM CE 4.2.2 Position hardware Data center operations 4.1.2 Perform physical installation IBM CE 4.1.3 Update system software IBM CE 4.1.4 Perform software installation IBM CE

3.1.2 Setup authentication PureApplication System provides an internal user registry for authentication. It can also be configured to use an external LDAP server for authentication.

3.1.2.1 Preconditions The system has been installed; see 3.1.1 Install system.

The enterprise has an LDAP-compliant user registry deployed in the data center.

These tasks need to be performed by a security administrator. When setting up a new system for the first time, the system administrator (whose user name is usually “admin”) is the only user in the system, so you must login as that user to perform these tasks.

3.1.2.2 Result The system uses the LDAP registry to authenticate users. It uses groups for separation of duties (SoD).

Next, configure the system; see 3.1.3 Configure system.

3.1.2.3 Tasks Task Role 4.2.3 Configure LDAP settings Data center operations 4.2.4 Configure users Data center operations 4.2.5 Configure user groups Data center operations 4.2.6 Add roles to a user or group Data center operations



3.1.3 Configure system PureApplication System contains a number of system settings that configure it to integrate with services in the data center. Many of these were specified in the TDA and configured as part of installing the system (see 3.1.1 Install system).

Now you need to complete the configuration, which means reviewing each set of settings, validating the values that have already been set, and changing or adding any additional ones that might be needed. Some configuration is optional, such as configuring external monitoring via SNMP events and external audit logging. Any of these settings can be changed later. Once this configuration is set, it generally doesn’t need to change unless your requirements change.


If users and user groups have been set up (see 3.1.2 Setup authentication), you should have different user groups for the system’s security roles. If so, these tasks need to be performed by a hardware administrator, except for the last task which is performed by an auditing administrator. Otherwise, use the system administrator to perform all of these tasks.

3.1.3.2 Result Content enablers and solution developers can create the workloads, deploy in the cloud and test them.

The system settings have been configured.

Next, configure the cloud environment; see 3.1.4 Setup cloud environment.

3.1.3.3 Tasks Task Role 4.2.7 Configure network settings Data center operations 4.2.8 Configure DNS settings Data center operations 4.2.9 Configure NTP settings Data center operations 4.2.10 Configure SMTP settings Data center operations 4.2.11 Configure SNMP settings Data center operations 4.7.1 Configure external audit logging Finance and compliance

3.1.4 Setup cloud environment PureApplication System serves as an environment for running workloads in a cloud, making hardware available for patterns as they’re deployed (often called Infrastructure as a Service or IaaS). A very simple cloud environment was created as part of installing the system (see 3.1.1 Install system) so that the validation application could be deployed.

Now you need to build a more complete cloud environment, one suited for the different groups of workloads to be deployed to the system and the different groups of people who will deploy, manage, and use these workloads. This requires some design (to determine



details like the cloud groups and their settings, the IP groups, and how many IP addresses each will need) that is beyond the scope of this document.

For details on designing the cloud environment, see:

1. IBM developerWorks: Managing application runtime environments in IBM PureApplication System

With your cloud environment’s design in mind, now is when you implement it. In doing so, you might reconfigure the existing cloud components (such as the cloud group named “Shared”) or delete them entirely. To delete them, you’ll first need to delete the validation application.


If users and user groups have been set up (see 3.1.2 Setup authentication), you should have different user groups for the system’s security roles. If so, these tasks need to be performed by a cloud group administrator. Otherwise, use the system administrator to perform these tasks.

3.1.4.2 Result The system now has a cloud environment suitable for deploying patterns into.

3.1.4.3 Tasks Task Role 4.2.12 Configure IP groups Data center operations 4.2.13 Configure cloud groups Data center operations 4.2.14 Configure for high availability Data center operations 4.2.15 Configure product licenses Data center operations

3.1.5 Additional customization Having completed the previous use cases, you have pretty much finished configuring your PureApplication System: It is installed and you’ve configured the user registry, system settings, and cloud environment.

What’s left is some of the more advanced settings. They’re optional and do not have to be set for the system to work properly, but they will make the system more robust. These tasks do not need to be performed immediately but should be performed soon.


If users and user groups have been set up (see 3.1.2 Setup authentication), you should have different user groups for the system’s security roles. If so, these tasks need to be performed by a user in the role specified by each task. Otherwise, use the system administrator to perform these tasks.


http://www.ibm.com/developerworks/websphere/library/techarticles/1210_woolf/1210_woolf.html



3.1.5.2 Result The system is now fully configured.

3.1.5.3 Tasks Task Role 4.2.16 Configure system backup Data center operations 4.2.17 Script system configuration tasks Data center operations 4.2.18 Consider appliance service upgrades Data center operations

3.2 Administrative management Once set up, the system does not require a lot of maintenance. Most of the settings used to set it up are for connecting to services in the data center, so if the specifics for connecting those services change, the settings in the system will have to be changed as well. As you discover new user groups are needed within the system, you’ll need to add those. As you see how the system is used, you may need to add resources, reallocate them, or even expand the system’s computing capacity. And of course, if a hardware component fails, you’ll need to get it replaced.

Use Case Description 3.2.1 Add new user groups Expand the user registry 3.2.2 Add IP addresses Expand the set of IP addresses 3.2.3 Add VLANs to the customer network Expand the set of virtual networks 3.2.4 Add product licenses Expands the set of product licenses 3.2.5 Reallocate computing resources Rearrange the set of compute nodes 3.2.6 Expand system size Expand the set of compute nodes 3.2.7 Replace failing hardware Fix hardware that isn’t working 3.2.8 Recover failed management nodes Fix management nodes that aren’t working

3.2.1 Add new user groups After setting up an initial user registry, you’ll later find the need for more entries. If your registry is hosted on an LDAP server (which it should be; see 4.2.3 Configure LDAP settings), adding users is easy; simply add them to your LDAP registry and they’ll be available in the system. Otherwise, create them in the system’s local directory. Adding user groups takes a little more work.

You will discover the need for new groups as you discover new tasks, which some users should be able to do but others should not. To control who can perform the task, you have three choices:

1. If a group already exists that represents that set of users, grant the permission to that group.

2. If you want, you can grant the permission to every user individually, but this tedious and difficult to maintain. (Avoid granting permissions to users.)



3. You can create a new user group for that set of users.

You will usually need option #3. Adding a new user group takes three steps:

1. Create the user group in your user directory (local or LDAP).

2. Add users to the user group (local or LDAP).

3. Grant permissions to the user group. This is always done in the system (even when using LDAP).

Permissions can be granted to users in one of two ways:

1. Add security roles to the group.

2. Add the group to the “access to” attribute of workload components such as patterns and pattern instances.

3.2.1.1 Preconditions The system has been setup; see 3.1 Administrative setup.

3.2.1.2 Result New user groups now exist in the system. You can now associate them with tasks or components to give the users in the group the permissions to perform the tasks or to view or change the components.

3.2.1.3 Tasks Task Role 4.2.5 Configure user groups Data center operations 4.2.6 Add roles to a user or group Data center operations

3.2.2 Add IP addresses When you initially create IP groups and populate them with IP addresses (see 4.2.12 Configure IP groups), you have to guess somewhat about how many IP addresses to put in each IP group, based on a rough estimate of how many virtual machines (VMs) will run in each one. With experience, you are likely to find that some of your estimates are off, and that you need to increase the number of IP addresses available for deploying VMs.

Assuming the system is configured with your desired set of VLANs, you only need to add more IP addresses so that you can deploy more VMs. This can be accomplished in one of two ways:

1. By adding additional IP addresses to existing IP groups.

2. By defining new IP groups using VLANs that are already configured on the system and stocking those with IP addresses.



The first approach is the simplest. With the second approach, you also need to add the IP groups to cloud groups so that subsequent pattern deployments can use the new IP groups’ addresses.

You can also move unused IP addresses from one IP group to another as long as they are configured for the same VLAN. To do this, edit one IP group to remove the addresses, then edit the other group to add the addresses. Addresses that are assigned to VMs are in use. To remove them from the IP group, you must first delete the VMs, which should be accomplished by deleting the pattern instances containing those VMs.

While editing IP groups that are assigned to cloud groups, you might want to quiesce its compute nodes so that pattern instances can’t be deployed. This prevents new pattern instances, which would consume IP addresses while you’re trying to move them.


The new IP addresses are part of VLANs already configured on the system. To configure new VLANs on the system, see 3.2.3 Add VLANs to the customer network.

3.2.2.2 Result Some combination of these:

The existing IP groups now contain more IP addresses.

The cloud groups now contain more IP groups, giving them access to more IP addresses.

3.2.2.3 Tasks Task Role 4.2.12 Configure IP groups Data center operations 4.2.13 Configure cloud groups Data center operations

3.2.3 Add VLANs to the customer network The customer network is composed of one or more VLANs the user workloads use to communicate. After the initial system setup is complete, you might decide that you wish to make a new VLAN available to these workloads. For example, you might want to deploy a new set of workloads whose network traffic should be isolated from that of the existing workloads, so the new workloads should use a new VLAN.

Workloads get their IP addresses from an IP group, which specifies not only a set of IP addresses but also the VLAN that those addresses belong to. An IP group can only specify a single VLAN, so using a new VLAN will require one or more new IP groups. Furthermore, defining a new IP group with a new VLAN requires that the new VLAN must also be defined within the system so that its networking hardware will permit the VLAN’s traffic.



Once the new IP group specifying the new VLAN has been defined, it must be added to a cloud group. Patterns deployed to that cloud group can then use IP addresses defined in that IP group.


3.2.3.2 Result Three changes have occurred:

1. The system’s networking hardware has been configured to use the new VLAN.

2. One or more IP groups exist with IP addresses for the new VLAN.

3. The new IP groups have been added to cloud groups.

3.2.3.3 Tasks Task Role 4.2.7 Configure network settings Data center operations 4.2.12 Configure IP groups Data center operations 4.2.13 Configure cloud groups Data center operations

3.2.4 Add product licenses When you initially configure the product licenses, you typically stock the product licenses page with all of the licenses you have purchased for all middleware on PureApplication System. If you have multiple systems, you have to divide the licenses across those systems.

With experience, you might find that your system does not have enough licenses for all of the pattern instances you’d like to deploy. There are a couple of strategies for resolving this situation:

1. The product licenses page shows which pattern instances are consuming a product’s licenses. See if you can store (or delete) some of those instances, which will cause their licenses to be released. They will need those licenses to start again.

2. If one system has licenses to spare (for the particular product the other system is short on), you can decrease the license limit for that product on one system and increase it on the other system.

3. You need to buy more licenses (for the product that is running out) and then increase the license limit on one or more systems.

This work is all performed on the product licenses page.




3.2.4.2 Result Your system now has licenses available to deploy more pattern instances.

3.2.4.3 Tasks Task Role 4.2.15 Configure product licenses Data center operations

3.2.5 Reallocate computing resources When you initially group compute nodes into cloud groups (see 4.2.13 Configure cloud groups), you have to guess somewhat about how many compute nodes to put in each cloud group, based on a rough estimate of how many workloads will run in each one. With experience, you are likely to find that some of your estimates are off, and that you need to redistribute compute nodes amongst cloud groups.

For cloud groups that need more capacity, you will increase it by adding unused compute nodes to those cloud groups. This assumes that you have unused compute nodes to add. If you don’t, you’ll need to create some by removing them from cloud groups that have too much capacity.

This approach of redistributing the capacity of your system assumes that not only do some cloud groups have too little capacity because of not enough compute nodes, but that some other cloud groups have too much capacity and therefore can run just fine with fewer compute nodes. If none of your cloud groups have any compute nodes to spare (or at least not as many to give as the other cloud groups need to receive), then what you need to do is not redistribute the capacity of your system but expand the capacity of your system; see 3.2.6 Expand system size.


3.2.5.2 Result The cloud groups with too little capacity now have more capacity.

3.2.5.3 Tasks Task Role 4.3.8 Remove compute node from cloud group Data center operations 4.3.9 Add compute node to cloud group Data center operations

3.2.6 Expand system size PureApplication System can be expanded to add additional computing capacity for running more workloads. This is accomplished by installing additional compute nodes, which increases the number of CPU cores and the amount of memory in the system. The storage in the system cannot be expanded, nor can the networking bandwidth. You



control the number of IP addresses and licenses available, and since they are not based on hardware, you can expand those yourself at any time.

An IBM CE must install the new compute nodes. Doing so does not cause or require a system outage or any loss of functionality of the system or its workloads.


3.2.6.2 Result These new compute nodes are visible in the system console compute nodes list, and the cloud administrator can either add one or more compute nodes to an existing cloud group (thereby increasing the allocated computing resources to that cloud), or create new cloud groups.

3.2.6.3 Tasks Regardless of the size of the upgrade, the process remains the same. First, you will purchase the upgrade package. Then, an IBM CE will come on site to perform the upgrade. This process ends with enabling the new compute nodes to be visible to your cloud administrators so they can add the compute nodes to new or existing cloud groups.

Task Role 4.3.7 Purchase additional computing capacity Data center operations 4.1.6 Install additional compute node IBM CE 4.3.9 Add compute node to cloud group Data center operations

3.2.7 Replace failing hardware System and hardware monitoring can indicate when a hardware component is not working properly. This is usually a software problem that IBM Support can help resolve. However, if software fixes do not resolve the problem, Support will determine that the component’s hardware is failing and needs to be replaced.

Replacing hardware in PureApplication System is much easier than in most computers. The hardware is very redundant and modular, so the system can keep functioning properly even with a failed hardware component, and that component can be replaced while the rest of the system is running so that the system does not suffer an outage.

An IBM CE is needed to replace hardware. He has access to the replacement components and is able to configure the system to stop using the old component and start using the new one.


Monitoring indicates there might be a hardware problem:

1. See 4.3.10 Monitor hardware



2. See 4.3.11 Monitor events and problems

3.2.7.2 Result The IBM CE replaces the old hardware component with a new one and verifies the system is using it properly.

If the replacement hardware is a management node, it needs to be restored; see 3.2.8 Recover failed management nodes.

3.2.7.3 Tasks Task Role 4.3.2 Contact support Data center operations 4.3.5 Schedule IBM CE Data center operations 4.3.6 Enable the IBMENG account Data center operations 4.1.5 Replace hardware IBM CE

3.2.8 Recover failed management nodes If a management node stops working, it must be restored. The system contains two pairs of management nodes. If one stops working, it can be restored from the other. If both stop working, they must be restored from a system backup.


If a management node is suffering a hardware failure, replace the hardware; see 3.2.7 Replace failing hardware.

A system backup must be available in order to perform a system restore; see 3.1.5 Additional customization.

3.2.8.2 Result One or both sets of management nodes have been restored. Both sets are once again working properly.

3.2.8.3 Tasks Task Role 4.1.7 Restore a management node IBM CE 4.1.8 Perform system restore IBM CE

3.2.9 Upgrade system version The system software on PureApplication System is like an operating system for the rack. It consists of the firmware on all the hardware components and the management software running on the management nodes. It is divided into two parts, shown in the integrated console as the system and workload tabs. The version of each software part is shown on



the About page (go to the tab for the part, either the System Console or the Workload Console, and select Help > About). A typical system software version number is v1.1.0.2.

Periodically, IBM produces a new version of this system software, released as updates (called fix packs, releases, and so on) that can be installed on existing systems. These updates consist of four separate but related parts:

1. System Update – Changes to the system software. These must be installed by the IBM CE.

2. Base OS Update – New versions of the virtual images for the operating system without any middleware installed. Loaded by the system’s workload administrator.

3. Group Fix – New versions of the pattern types for the shared services. Each Group Fix requires its corresponding System Update and Base OS Updates as a prerequisite that must be installed first. Loaded by the system’s workload administrator.

4. Virtual Image and Pattern Updates – New versions of the entitled virtual images and patterns included with the system. Released individually on an on-going schedule independent of each other and of the schedule for system and group fix pairs. Loaded by the system’s workload administrator.

These updates are published in the PureSystems® Centre. You should monitor it to learn of the availability of updates. When one is available, find a convenient time to install it and arrange for an IBM CE to install the System Update. After that is installed, your workload administrator needs to install any Base OS Updates, Group Fixes, and Virtual Image and Pattern Updates.


3.2.9.2 Result Several updates have now been made:

The system is now running the latest version of the system software.

The workload catalog contains the latest component versions.

The latest versions of the shared services are running.

3.2.9.3 Tasks An update consists of four parts, and there are tasks for each.

System Update is the first part of the update. For that, you need an IBM CE to install the update.

Task Role 4.3.1 Monitor support resources Data center operations 4.3.2 Contact support Data center operations 4.3.5 Schedule IBM CE Data center operations




Task Role 4.3.6 Enable the IBMENG account Data center operations 4.1.3 Update system software IBM CE

Base OS Update is the second part of the update. These may well be bundled in with the other updated virtual images. They can be imported before or after the Group Fix, but they need to be imported before deploying the shared services in the group fix.

Task Role 4.8.1 Import virtual image Content enablement

Group Fix is the third part of the update. This contains new versions of the shared services. These new versions often depend on the System Update to run correctly. Therefore, they can be imported before or after performing the System Update, but they shouldn’t be deployed until after:

1. The System Update is loaded.

2. The Base OS Updates (if any) are loaded.

3. New pattern types and plug-ins (if any) are loaded.

But the new shared service versions should be deployed soon after installing the System Update so that each shared service can leverage any corresponding improvements in the System Update.

Importing the shared services in the Group Fix is only the first step. The shared services are patterns, so they must be deployed, which is the second step. A cloud group can only have one running instance of a particular shared service, so it can’t have two versions of the same shared service running at the same time. If the shared service has already been deployed to the cloud group, the instance can be updated in place to load the code changes.

Task Role 4.8.6 Import and install virtual application components Content enablement 4.4.9 Update existing shared service instance Application operations

Virtual Image and Pattern Updates is the fourth part of the update. Each of these updates can contain a combination of virtual images, virtual system patterns, and virtual application patterns. Import each one by following the appropriate task.

Task Role 4.8.1 Import virtual image Content enablement 4.8.5 Import virtual system pattern Content enablement 4.8.4 Import virtual application pattern Content enablement


3.3 Workload Once you have the system set up, you need to develop patterns for your applications.

Use Case Comments 3.3.1 Develop virtual application pattern Create a new virtual application pattern 3.3.2 Develop virtual system pattern Create a new virtual system pattern 3.3.3 Develop DBaaS pattern Create a new virtual application database

pattern 3.3.4 Develop DB2 virtual system pattern Create a new virtual system database

pattern 3.3.5 Maintain virtual application pattern Update an existing virtual application

pattern 3.3.6 Maintain virtual system pattern Update an existing virtual system pattern 3.3.7 Evaluate virtual application readiness Does your application fit the requirements

for a virtual application pattern? 3.3.8 Evaluate existing virtual system patterns

Is an existing virtual system pattern suitable for your application?

3.3.1 Develop virtual application pattern This use case walks through the development of a new virtual application pattern. Virtual application patterns differ from virtual system patterns in that each virtual application pattern represents a single, unique environment definition; for example, when you are defining a virtual application pattern you are specifying parameters such as LDAP locations, URIs or even application EAR files that are specific to a particular environment. However, the construction of a virtual application pattern is something that is also very simple: it can be done by an application or database developer or tester and does not require a centralized content creation team.

3.3.1.1 Preconditions The application for which you are building this pattern should be known, and all existing documentation about the application design, its prerequisites, and its requirements should be gathered.

3.3.1.2 Result Your virtual application pattern is created and instances can be deployed from it.

3.3.1.3 Tasks Building a virtual application pattern is usually a fairly simple series of operations. However, it does require some knowledge about the functionality of the application that you are building it around in order to plan it out properly. Essentially, your first job is to determine which virtual application components you need. In many cases, most of this is determined for you, such as when using the Business Intelligence Pattern or the Business Process Pattern. But when you are building a WebApp Pattern, for example, there are several different options that your application might require. Options for a web



application include connections to databases (either external or hosted as DBaaS on PureApp), LDAP (again, either external or internally hosted), and WebSphere MQ.

Once you have determined the “base” topology of the application, then you need to determine which policies need to be implemented. One example of the different policies that are applicable is a scaling policy to introduce autoscaling. However, in some cases, you will find that the available components and policies that you have in the catalog do not meet all of your needs. For example, if you need a very specific server type that is not available (say, you wanted to host node.js applications and wanted to create a node.js component type), then you may need to use the IBM Pattern Development Kit (PDK) to create those component types. Once the component type has been created, then you can use it just as you use the existing component types.

Finally, once you have decided upon the architecture of your application, you will need to build the application in the patterns editor and then export it and check it into a source code management (SCM) system for future reference, or for import into other PureApplication System machines.

Task Role 4.8.12 Create and edit virtual application and DBaaS patterns

Content Enablement

4.8.1 Import virtual image Content Enablement 4.8.7 Develop custom image using extend and capture Content Enablement 4.8.8 Develop custom image using ICCT Content Enablement 4.8.14 Develop virtual application component Content Enablement 4.8.13 Install and configure application backup Content Enablement 4.8.18 SCM of workload catalog Content Enablement

3.3.2 Develop virtual system pattern This use case walks through the development of a new virtual system pattern.

3.3.2.1 Preconditions The class of applications for which you are developing a virtual system pattern should be known. All of the topology requirements of the class of applications should be documented. Your software development lifecycle should be known and documented, and you should know which environments will be created from this pattern.

Also, before you begin developing a virtual system pattern you need to understand who will be deploying it, for which applications, and for what purposes. Thus, another precondition is that you have considered your team organization as outlined in use case 3.5.1 Plan development teams.

3.3.2.2 Result Your virtual system pattern is created and instances can be deployed from it.



3.3.2.3 Tasks Creating a virtual system pattern is a somewhat involved exercise in that you are creating a completely reusable asset that can be configured for a number of different uses. As documented here, a best practice is that you want to keep application-specific information and configuration out of the pattern code so that the pattern can be reused for not only multiple applications, but for multiple environments for each application. Therefore, you need to first spend time carefully architecting the pattern. This will involve evaluating the class of applications it is meant to support, and making sure that your planned topology will meet the needs of this class of applications in all of the different environments. Once you have determined the architecture for your virtual system pattern, you can begin constructing the pattern in the pattern editor. Here, you will generally start with selecting parts (virtual images) from the palette and adding in script packages that have been written by others as well, but in many cases you will find you need to add additional script packages to meet the needs of your particular class of applications. In particular, you will often find that you need to add script packages for tasks like application backup. Also, as part of the analysis process, you might find that you need parts that don’t yet exist in your catalog. Those will either need to be purchased from the PureCentre and imported, or developed manually using extend and capture or ICCT. Finally, once you have created the pattern and any new script packages, you need to export it and check it into source code control for archival purposes.

Task Role 4.8.11 Create and edit virtual system patterns Content Enablement 4.8.1 Import virtual image Content Enablement 4.8.7 Develop custom image using extend and capture Content Enablement 4.8.8 Develop custom image using ICCT Content Enablement 4.8.9 Develop script package Content Enablement 4.8.10 Develop add-on Content Enablement 4.8.13 Install and configure application backup Content Enablement 4.8.18 SCM of workload catalog Content Enablement

3.3.3 Develop DBaaS pattern This use case walks through the development of a new Database as a Service (DBaaS) pattern. The IBM DB2 with BLU Acceleration Pattern 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.

3.3.3.1 Preconditions The application for which you are building this DBaaS pattern should be known. You should also know what type of workload standard you would like to apply for this pattern.



3.3.3.2 Result Your DBaaS pattern is created and instances can be deployed from it.

3.3.3.3 Tasks The tasks involved in building a DBaaS pattern are not that different from how you would go about building a virtual application pattern. It is in fact simpler than building a virtual application pattern.

Building a DBaaS pattern requires you first to know the version of the database you are building and what purpose you will be using it for. Based on the purpose, you can use the pre-canned workload standards that are shipped with the product or provide your own customized workload standard. For example, use the departmental transactional default workload standard primarily for online transaction processing. The departmental transactional workload standard is optimized for transactional applications. Transactional databases are designed for speed, simplicity, and volume. However, if the main purpose of the database is to use it for data warehousing, use the data mart default workload standard. The data mart workload standard is optimized for analytics and reporting applications. With this option selected, you can also enable BLU Acceleration for DB2 10.5 databases, which uses in-memory caching and columnar storage.

In terms of scalability, you can either pick standard or “high.” Standard means deploying the database on the PureApplication system itself, while picking “high” requires you to have a DB2 pureScale instance deployed on the PureData System for Transactions.

Finally, once you have decided upon the architecture of your database, you will need to build the database pattern in the patterns editor and then export it and check it into a Source Code Control system for future reference or for import into other PureApplication System machines.


Content Enablement

4.8.13 Install and configure application backup Content Enablement 4.8.18 SCM of workload catalog Content Enablement 4.8.6 Import and install virtual application components Content Enablement

3.3.4 Develop DB2 virtual system pattern This use case walks through the development of a new virtual system pattern using DB2 as the middleware.

3.3.4.1 Preconditions You should already have made the determination whether your database could be hosted as a dataset, as a service, or because of the administrative flexibility required, it should be deployed as a virtual system pattern. You also need to determine whether you just want a standalone database or need to create a pattern, which could be deployed in HADR mode.



If HADR is required, the determination needs to be made whether the secondary node will reside on the same PureApp rack or on another PureApp rack.

Also, before you begin developing a virtual system pattern, you need to understand who will be deploying it, for which applications, and for what purposes. Thus, another precondition is that you have considered your team organization as outlined in use case 3.5.1 Plan development teams.

3.3.4.1 Result Your virtual system pattern for hosting a DB2 database is created and instances can be deployed from it.

3.3.4.2 Tasks The process of building a virtual system pattern to host a DB2 instance is no different than how you would build any other virtual system pattern. Once you have determined the architecture for your virtual system pattern, you can begin constructing the pattern in the pattern editor. Here, you will generally start with selecting DB2 specific parts (virtual images) for the version you are interested in from the palette. In many cases, you will find you need to add additional script packages to meet the needs of your particular class of applications. In particular, you will often find that you need to add script packages for tasks like application backup, or operating system hardening. The default file system size that gets allocated for a DB2 system out of the box is generally not sufficient and you might want to add one or more add-ons that let you allocate additional storage to your VM based on your need. If you are building a DB2 HADR pattern, the three out-of-the-box patterns shipped with PureApplication System do give you a good starting point. Finally, once you have created the pattern and any new script packages, you need to export it and check it into source code control for archival purposes.

Task Role 4.8.11 Create and edit virtual system patterns Content Enablement 4.8.1 Import virtual image Content Enablement 4.8.9 Develop script package Content Enablement 4.8.10 Develop add-on Content Enablement 4.8.18 SCM of workload catalog Content Enablement

3.3.5 Maintain virtual application pattern This use case walks through the maintenance and modification of an existing virtual application pattern.

3.3.5.1 Preconditions The virtual application pattern exists and is in the catalog of the PureApplication System.

3.3.5.2 Result Your virtual application pattern has been modified and new instances can be deployed from it.



3.3.5.3 Tasks There are some common situations that might cause you to modify an existing virtual application pattern. Those include:

A new version of an underlying product part (or an efix to that part) has been released and the pattern should be updated to take advantage of the newer version or efix.

A policy needs to be added or modified in the virtual application.

There is a new version of an application artifact.

Any or all of these can occur in any combination. In any case, after the pattern is modified, it should be exported to an SCM system for archival purposes.

Task Role 4.8.15 Add fix to virtual image Content Enablement 4.8.17 Apply fix to virtual application pattern Content Enablement

3.3.6 Maintain virtual system pattern This use case walks through the maintenance and modification of an existing virtual system pattern.

3.3.6.1 Preconditions The virtual system pattern exists and is in the catalog of the PureApplication System.

3.3.6.2 Result Your virtual system pattern has been modified and instances can be deployed from it.

3.3.6.3 Tasks There are some common situations that might cause you to modify an existing virtual system pattern. Those include:

A new version of a hypervisor edition (HVE) of a product used by the pattern has been released, or an efix to the image has been released and the pattern should be updated to take advantage of the newer version.

The pattern has been in use for some time and it has been shown that there is insufficient storage allocated to some particular directory (often a logs directory), necessitating adding additional storage to future pattern instances using the add disk add-on.

An application requirement specifies a particular configuration object that is not currently being created by a script package. In order to allow for the creation of this new object, a new script package needs to be added or an existing script package needs to be updated.

Any or all of these can be combined together at any time within a single revision of a pattern. In any case, after the pattern and any associated script packages are modified, they should be exported to an SCM system for archival purposes.



Task Role 4.8.10 Develop add-on Content Enablement 4.8.9 Develop script package Content Enablement 4.8.15 Add fix to virtual image Content Enablement 4.8.16 Apply fix to virtual system pattern Content Enablement 4.8.18 SCM of workload catalog Content Enablement

3.3.7 Evaluate virtual application readiness This use case assesses if an application is ready for deployment as a virtual application. This is a necessary prerequisite for creating a virtual application pattern as many applications do not meet the criteria for deployment as a virtual Application. Note that the tasks listed below are guidelines only; as more virtual applications are added to the PureSystems Centre catalog, other options might become available, but these are the most common assessments.

3.3.7.1 Preconditions The application should be known, and all existing documentation about the application design, its prerequisites, and its requirements should be gathered.

3.3.7.2 Result It has been determined that your application is suitable for deployment as a virtual application pattern.

3.3.7.3 Tasks The process for evaluating an application requires that you follow these steps to determine if an existing virtual application pattern is suitable for your application.

1. Determine if your application is a BPM application. If that is true, then is there a requirement to customize your BPM deployment environment? If not, then your application can be deployed using the IBM Business Process Manager application pattern.

2. Determine if your application is an IBM Cognos® Business Intelligence application. If so, then you can deploy it using the IBM Business Intelligence Pattern.

3. Determine if your application is a standard Java™ EE application. If so, follow the steps outlined in Preparing for IBM PureApplication System, Part 2: Is your application ready to become virtual? If the steps indicate that you can deploy as a virtual application pattern, then you can create a Web Application virtual application pattern from the existing parts and then deploy your new web application pattern.


Content enablement


https://www.ibm.com/developerworks/websphere/library/techarticles/1204_brown/1204_brown.html

https://www.ibm.com/developerworks/websphere/library/techarticles/1204_brown/1204_brown.html



Task Role 4.5.2 Deploy a virtual application or DBaaS pattern Application operations

3.3.8 Evaluate existing virtual system patterns This use case gives guidance for assessing the suitability of existing virtual system patterns for hosting an application. Given that every existing virtual application pattern developed by a company can be unique, the steps provided here are very high-level and are meant to cover a wide variety of situations.

3.3.8.1 Preconditions The application should be known, and all existing documentation about the application design, its prerequisites, and its requirements should be gathered.

3.3.8.2 Result It has been determined that your application is suitable for deployment within an existing virtual system pattern.

3.3.8.3 Tasks

1. Determine if this is a new or existing application. If it is a new application, then determine if the application topology design can be modified to fit within the capabilities provided by existing virtual system patterns. If so, then your application is suitable for deployment within that pattern. If not, move on to the next step.

2. Compare the topology of your existing application hosting to the different virtual system patterns hosted in the PureApplication System catalog. If your application fits within an existing topology (for example, all the components of your topology match corresponding components in this virtual system pattern, including the numbers of different node types needed for scalability and redundancy) then you can move onto the next evaluation step. Otherwise, you will need to modify an existing virtual system pattern to meet your topology design.

3. Next, examine the script packages in the closest matching virtual system pattern in the catalog. Compare the list of actions that the script packages take and the set of parameters that they operate on to the detailed requirements of your application. If your application requires a configuration step (such as the creation of a Java EE object or the injection of an agent) for which no script package exists, then you will need to modify the existing virtual system pattern to extend it to add a new script package.


3.4 Deployment Once you have developed patterns for your applications, deploy them so that you can run your applications.

Use Case Description 3.4.1 Allocate cloud resources Control how teams share resources 3.4.2 Deploy shared service Install functionality shared by multiple

applications 3.4.3 Deploy pattern Create an application runtime environment 3.4.4 Deploying for DR Create an application across two systems

3.4.1 Allocate cloud resources A significant advantage of cloud computing is that resources are sharable. Cloud resources such as CPU, memory, storage, IP addresses, and middleware licenses are pooled so that workloads can take what they need when they need it and release it when they aren’t needed anymore. In this way, when one application doesn’t need a resource, another can use it.

Yet, resource sharing must be managed to prevent a few workloads from taking too many resources so that all workloads get their fair share. Placing limits on how resources are shared is called allocation. Resources are allocated to the teams that deploy one or more sets of workloads to make sure each set gets a fair amount of the total.

Allocating resources requires balance:

They should not be too restrictive or a workload that needs more resources won’t be able to get them even when resources are available.

They should not be too permissive or the first few workloads will consume all resources and nothing will remain for later workloads.

Most allocation settings are configured in environment profiles. Cloud groups create isolation boundaries between each other, yet allow unlimited sharing internally. Environment profiles subdivide cloud groups, specifying how much of the cloud group a set of workloads can use. Creating an environment profile is just a matter of filling in property values, but designing an environment profile requires understanding those properties and planning how workloads should share resources.

These factors decide how many environment profiles to create:

Profile per cloud group – Each environment profile should deploy to only one cloud group. (Otherwise allocations are split across cloud groups, which makes them less meaningful.) Therefore, you will need at least one environment profile for each cloud group.

Profile per team – When multiple teams are deploying patterns to the same cloud group, they should each have their own environment profile. This enables setting allocations separately for each team.



Priority – If a team wants the pattern instances it deploys to have different profile deployment priorities (Platinum, Golden, Silver, and Bronze), create multiple environment profiles for that team, one for each priority.

IP address provider – If a team wants some of the pattern instances it deploys to have IP addresses assigned automatically using IP groups, and other pattern instances to have IP addresses assigned by the deployer, create multiple environment profiles for that team, one for each provider.

Once you’ve created the environment profiles, these are the settings to configure:

Access – Each environment profile should grant access as follows:

o Full access to the group (or users) who will maintain it.

o Read access to the group for the team who will deploy using it.

Environment limits – This is where you get to allocate resources, the upper limit on how much of the cloud group this team’s workloads are allowed to use. Limits can be set for CPU, memory, storage, and licenses per product. This prevents one team from taking up too much of a cloud group’s resources.

IP groups – The cloud group can have multiple IP groups. One use is to create different IP groups for different teams and assign them to their respective profiles. This way, one team cannot use another team’s addresses.

Various other customizations per team, such as: virtual machine name format, time zone, and so on.

For more information, see:

IBM developerWorks: Managing application runtime environments in IBM PureApplication System

3.4.1.1 Preconditions The cloud environment should already exist:

3.1.4 Setup cloud environment

3.4.1.2 Result You now have an environment profile for a team to use for deploying patterns to a particular cloud group. They can now use it to deploy patterns:

3.4.3 Deploy pattern

3.4.1.3 Tasks With an allocation design in mind — which accounts for the cloud environment, teams that will deploy to it, and the cloud resources each should get for their workloads — you can create the needed environment profiles. Give each team read access to their profile(s) by assigning their user group. If there is no user group for the team, work with the security administrator to create one.





Task Role 4.5.1 Create environment profile Application operations 3.1.2 Setup authentication Data center operations

3.4.2 Deploy shared services PureApplication System provides several shared services that provide common infrastructure for your workloads. These shared services provide functionality that is available to all workloads within a cloud group. There are several categories of services that you may need for your production environment, with your development and test environments needing a subset of those. The categories are:

1. Middleware monitoring

2. Elasticity and caching

3. Workload updating

Middleware monitoring needs additional explanation.

First, there are multiple monitoring services:

1. A base monitoring service

2. Several middleware monitoring services

3. Database monitoring services

Second, middleware monitoring is implemented using IBM Tivoli Monitoring features, which means it requires a feature called Hub TEMS and some related features. The base monitoring feature must be configured to specify how Hub TEMS is provided:

1. Internal – The service will host its own Hub TEMS server.

2. External – The data center already hosts its own Hub TEMS server that the service should use, so the service acts as a proxy to that external service.

Third, the base monitoring service must be deployed before any of the middleware monitoring services are deployed, because they require it as a prerequisite.

Fourth, the database monitoring services can be deployed without the base monitoring service because it does not require the base service as a prerequisite.

Fifth, each middleware monitoring service is preconfigured to monitor a specific middleware product, but they do not monitor the custom applications (that is, the business logic) running in those middleware servers. If you would like to monitor your applications, the middleware monitoring agents are extensible, so you can program them with additional monitoring logic for your applications.

3.4.2.1 Preconditions The cloud environment should already exist so that the shared services can be deployed into it:

3.1.4 Setup cloud environment



3.4.2.2 Result Your cloud group now has services your workloads can use. Next, deploy patterns to use these services:

3.4.3 Deploy pattern

3.4.2.3 Tasks There are different tasks for the different categories of shared services.

Middleware monitoring is the first category of shared services.

First, to enable integrated monitoring of your workloads, you will need to start by deploying the base middleware monitoring service. It can be configured for either internal or external monitoring, so perform one of these tasks (but not both):

Task Role 4.4.1 Deploy base service for internal monitoring Application operations 4.4.2 Deploy base service for external monitoring Application operations Second, to enable integrated monitoring of your middleware servers, you will need to deploy the middleware monitoring services, which require the base workload monitoring service from above. Optionally, you can also program the middleware agents to monitor your applications.

Task Role 4.4.3 Deploy middleware monitoring services Application operations 4.5.15 Program application monitoring Application operations

Third, to enable integrated monitoring of your database servers, you will need to deploy that service. These do not require the base monitoring service.

Task Role 4.4.4 Deploy database monitoring service Application operations 4.11.1 Configure database monitoring service Database administration

Elasticity and caching is the second category of shared services.

For production deployments of virtual applications, you can get scalability and caching with these services:

Task Role 4.4.5 Deploy caching service Application operations 4.4.6 Deploy elasticity service Application operations

Workload updating is the third category of shared services.

To update the OS running in your deployed VMs, you will need these services:

Task Role




Task Role 4.4.7 Deploy Red Hat update service Application operations 4.4.8 Deploy endpoint management service Application operations

3.4.3 Deploy pattern Deploying patterns is really the reason that PureApplication System exists. The ability to rapidly create new, completely consistent environments for development, test, or production is the key benefit that it provides. But what is important to this use case is understanding the cases when you need to deploy a pattern to create a new pattern instance. There are several reasons why you may need to do this, all of which follow the same sequence of steps.

3.4.3.1 Preconditions The pattern that needs to be deployed should already exist (for example, you have already followed 3.3.1 Develop virtual application pattern or 3.3.2 Develop virtual system pattern).

3.4.3.2 Result A pattern instance has been deployed and is ready to be used as a particular SDLC environment. The pattern instance will need to be monitored and maintained:

3.6 Monitoring and management

3.4.3.3 Tasks Executing this use case depends upon some decisions about how your team is structured. In most cases, as described in an earlier use case, the members of your development or operations team can deploy the patterns into those environment profiles for each of the environments that need to be created. Thus, the first task is to create environment profiles that reflect your team structure and gives access for specific patterns in the catalog to specific team members in specific cloud groups. Next, you need to consider the reasons for creating pattern instances. Those you need to examine are:

Developers may need new development environments for new applications

Testers may need new test environments for new applications

You may need to deploy an application for the first time into production

You may need to replace an application already in production.

You may want to replace an existing environment (for development, test or production) with one built from a newer version of the pattern.

In every one of these examples, you need to create a new pattern instance through deploying a pattern. If you are using a virtual system pattern, then you will also need to separately deploy the appropriate version of your application code and configuration into your pattern instance. That step follows a best practice from Best practices for patterns adoption in IBM PureApplication System, which is to separate the middleware topology




(the pattern itself) from the application configuration (the files that together comprise the application). If you are using a virtual application pattern, then the application code is already included in the pattern as you draw it in the editor, so this step is not needed.

Finally, however, the last two reasons may need a little bit of additional explanation. The article referenced above explains another best practice for PureApplication System, whereby we state that environments created on the system should not, in general, be long-lived assets. Essentially, the reason is that because creating a new environment in PureApplication System is so fast, it's usually easier and simpler to replace the environment with one created from a newer version of the pattern than it is to try to update the existing environment. So, in those last two cases, you would need to perform the deployment of the pattern and the code to create a new workload and then redirect traffic from the old instance to the new instance.

Task Role 4.5.1 Create environment profile Application operations 4.5.2 Deploy a virtual application or DBaaS pattern Application operations 4.5.3 Deploy a virtual system pattern Application operations 4.5.25 Deploy application code into a virtual system instance

Application operations

3.4.4 Deploying for DR This use case describes building systems that can recover in the case of a disaster that takes out an entire data center containing one PureApplication System. Most solutions built with PureApplication System will use one or both of WebSphere Application Server or DB2, which are pre-entitled with PureApplication System. What’s more, there is usually a need to build systems that are highly resilient; that is, they can survive the failure of one or more components (they are highly available) or they can survive the loss of an entire data center and can recover within a particular period (known as the RTO or time to Return To Operations). The second case is often referred to as Disaster Recovery and is the subject of this particular use case.

3.4.4.1 Preconditions The solution you are developing is based on DB2 and/or WebSphere Application Server. You have two separate PureApplication System machines, one in each data center that you have installed (3.1.1 Install system). Your two data centers are less than 168 miles (300 km) apart.

3.4.4.2 Result Your PureApplication System solution is deployed and available such that a primary pattern instance is taking traffic on one machine and the backup pattern instance is ready to take over upon failure of the primary.



3.4.4.3 Tasks DB2 HADR is one of the patterns that is available in the catalog for every PureApplication System. So, building a DB2 database capable of acting in a disaster recovery role consists of two steps; first, you have to define a DB2 HADR pattern containing the primary and the secondary databases, then you have to deploy each pattern into the PureApplication System in its respective data center. Thus, this first task is 4.8.20 Enabling DB2 HADR for disaster recovery in virtual system pattern. The second task is to 4.5.22 Deploy DB2 HADR for database disaster recovery.

However, in most systems, DB2 is only part of the solution. While your critical data might be stored in DB2, there is still the risk of losing in-flight transactions that are being processed inside WebSphere Application Server in the case of the loss of an entire datacenter or an entire WebSphere Application Server pattern instance within the primary PureApplication System. For that reason, you need to provide a mechanism for recovering the WebSphere Application Server pattern instance in the backup data center as well. In this situation, the first step is to Deploy GPFS for disaster recovery. GPFS is IBM's General Parallel File System, a solution for creating highly available file systems that can be replicated across multiple PureApplication System racks. This is a critical step for enabling the transaction logs in WebSphere Application Server that contain these in-flight transactions to be recovered. Once the GPFS pattern has been deployed on both racks and the two patterns are connected together, you can then proceed on to creating virtual system patterns for WebSphere Application Server that take advantage of GPFS. That task is performed in 4.8.21 Enabling GPFS for disaster recovery in virtual system pattern. Once you have built the prerequisite patterns, you can then deploy them into each PureApplication System.

Task Role 4.8.20 Enabling DB2 HADR for disaster recovery in virtual system pattern

Content enablement

4.5.22 Deploy DB2 HADR for database disaster recovery Application operations 4.8.21 Enabling GPFS for disaster recovery in virtual system pattern

Content enablement

4.5.23 Deploy GPFS for disaster recovery Application operations 4.5.3 Deploy a virtual system pattern Application operations 4.5.24 Enable GPFS on a virtual system Application operations

3.5 Development Once you have patterns and know how you’re going to deploy them for production, you need to think about how you’re going to deploy them for other stages of your software development lifecycle (SDLC).

Use Case Description 3.5.1 Plan development teams Determine teams to deploy patterns



3.5.1 Plan development teams One of the key decisions that a team needs to make in adopting PureApplication System is who will be responsible for deploying patterns in the different environments representing different stages of the software development lifecycle (SDLC).

3.5.1.1 Preconditions There are no special preconditions for carrying out this use case.

3.5.1.2 Result Your team is organized and users have been created and given authorization rights to perform deployments on your PureApplication System.

3.5.1.3 Tasks A common tactic (and best practice) is for teams to follow a DevOps style approach; rather than restricting pattern deployment only to the operations team, the ability to deploy patterns should be divided by SDLC. In that case, you might have developers and testers given the right to create “lower” environments such as development and test environments. “Higher” environments such as performance test and production might still be deployed by dedicated operations personnel.

The first task you have to take on is to create user groups for each of the different roles in your organization and match those to users in your existing LDAP directory. The next task to do is to think carefully about the roles in your organization, and then create the environment profiles matching those roles and fitting into the divisions of your cloud groups. This will enable the people in those roles to deploy patterns into the environment profiles.

Task Role 4.2.5 Configure user groups Data center operations 4.5.1 Create environment profile Application operations

3.6 Monitoring and management Once you have the system set up, you should keep an eye on it to make sure it keeps operating the way you want it to and to adjust its operations as necessary.

Use Case Description 3.6.1 Monitor system and workloads Monitoring different levels of the system 3.6.2 Maintain workload Applying fixes to patterns and instances 3.6.3 Tune virtual machine Adjusting a VM’s performance 3.6.4 Troubleshooting Problem determination 3.6.5 Incident management Getting help from IBM Support



3.6.1 Monitor system and workloads PureApplication System provides integrated, layered monitoring on all areas of your integrated solution. System, middleware, and hardware monitoring facilities let you gain quick access to the status, performance, and resource usage of all areas of your integrated solution.

Monitoring on PureApplication System operates in three levels:

1. Hardware – At the hardware level, the system provides an infrastructure map that contains all the important monitoring information in one place. It shows an overview of the compute nodes, storage system, network switch, and LED status.

2. Middleware – You can monitor the workloads and instances with PureApplication System. For the monitoring facilities to be displayed in the workload console, you must deploy monitoring shared services. A subset of middleware monitoring functions is required to use installed agents. Information for monitoring is also provided by the integrated parts of the system.

3. System – The system monitoring service provides the monitoring infrastructure that collects performance and availability information. Use the system monitoring service to troubleshoot your system and make business decisions about your hardware and service usage.

Hardware is the most fundamental: If a hardware component is not working, workloads will not be able to use that component.

System is the most comprehensive: It’s the easiest way to check overall health of the entire system including its central functionality and its workloads.

Middleware monitoring gives the most specific view of individual workloads and the detailed view of how each workload fits into the bigger picture of everything on the system.


3.6.1.2 Result You should be able to view deep monitoring data, which will show you system, hardware, or middleware performance issues. Based on the data, you can manage your capacity and then review the division of the system to the different groups and readjust if needed.

3.6.1.3 Tasks Monitoring is not a single series of tasks but an ongoing effort that makes use of various tasks as needed. It operates in three levels, and there are tasks for each.

Hardware monitoring is the first level of monitoring.

Task Role 4.3.10 Monitor hardware Data center operations



Middleware monitoring is the second level of monitoring.

Task Role 4.5.8 View virtual machine status Application operations 4.5.12 View workload status Application operations 4.4.1 Deploy base service for internal monitoring Application operations 4.5.15 Program application monitoring Application operations 4.5.16 Monitor middleware Application operations

System monitoring is the third level of monitoring.

Task Role 4.3.11 Monitor events and problems Data center operations 4.3.12 Monitor job queue Data center operations 4.3.13 View activity reports Data center operations 4.3.14 Monitor product licenses Data center operations 4.7.3 Review audit logs Finance and compliance

3.6.2 Maintain workload Middleware and operating system vendors periodically make fix packs and other updates available for their software. How can you apply these fixes to your patterns and pattern instances?

At a minimum, you should wait for IBM (or whomever is the vendor of the pattern) to issue a new pattern version that contains the fix. When they do, you should import that new version onto your system, incorporate it into your own patterns, and redeploy the pattern instances so that they’re running the new version with the fix. You should also hide the previous versions of the pattern to help unclutter the catalog and avoid accidentally deploying out-of-date software.

In the meantime, you often need fixes before the vendor issues a new pattern version. This situation creates a couple of new issues to address. You need to:

1. Patch existing instances – Apply an emergency fix or manually run commands.

2. Patch future instances – Incorporate a fix or commands into a pattern so that it automatically gets applied as part of deploying a new instance.

Emergency fixes are pretty handy in PureApplication System. You import one from IBM or create one yourself, much like a script package. You then associate it with the virtual image or plug-in containing the software the patch applies to. Each pattern instance knows a history of the emergency fixes that are available to be applied and those that have already been applied. The pattern instance owner can apply available fixes when convenient.

Not only can emergency fixes be manually run on existing pattern instances, they can also be incorporated into patterns so that they can be run automatically as part of deploying new instances. Virtual application patterns have a feature to incorporate



interim fixes. Virtual system patterns do not have this feature, but you can add a script package that runs as part of deploying an instance that applies the emergency fixes.

An alternative to creating an emergency fix is to run commands on the command line. For a virtual system pattern, you can implement these commands in a script package and add it to the pattern so that it gets run on each new deployment. There is no similar way to add commands to a virtual application pattern. The set of commands must be manually run on each existing pattern instance, and if they’re not incorporated in a script package, they will need to be run manually on new instances as well. Whereas a pattern instance shows the history of emergency fixes that have been run and are available to be run, it has no idea what commands have been manually run.

PureApplication System includes some shared services to help facilitate applying updates.

Red Hat OS Update shared service – This service enables Red Hat Enterprise Linux® (RHEL) running in virtual machines in the cloud group to run yum (Yellow dog Update, Modified) commands. The service implements a yum repository populated with packages downloaded from Red Hat using the system’s license. The RHEL virtual machines automatically configure themselves with this repository so that the OS can then run yum commands. This option is only available on the W1500.

IBM Endpoint Manager shared service – This service connects an IBM Endpoint Manager server installed in your data center and the virtual machines running on the system. Then you can use Endpoint Manager to manage the operating systems on the virtual machines. This option works with both the W1500 and W1700. On the W1500, one option is to use both shared services so that Endpoint Manager can run yum commands.

These shared services help facilitate running commands on the OS’s command line. These commands can be run manually, automated using a tool like IBM Endpoint Manager, or scripted using a script package or emergency fix.

Even if you keep your pattern instances current using emergency fixes, when a new pattern version is available, you should start using it.


3.6.2.2 Result Pattern instances are now updated with fixes and are ready for test.

3.6.2.3 Tasks The first set of tasks applies to acquiring an updated pattern version when it’s available. How you import it depends on what component type it is: virtual image, virtual system pattern, or virtual application pattern.

Task Role 4.3.1 Monitor support resources Data center operations




Task Role 4.8.1 Import virtual image Content enablement 4.8.5 Import virtual system pattern Content enablement 4.8.4 Import virtual application pattern Content enablement 4.4.9 Update existing shared service instance Application operations

The second set of tasks applies to keeping the middleware in current pattern instances up-to-date until an updated pattern version is available. This can be accomplished using emergency fixes.

Task Role 4.8.15 Add fix to virtual image Content enablement 4.8.16 Apply fix to virtual system pattern Content enablement 4.8.17 Apply fix to virtual application pattern Content enablement 4.5.4 Apply fix to virtual system instance Application operations 4.5.5 Apply fix to WebSphere virtual application or DBaaS instance

Application operations

The third set of tasks applies to keeping the OS in current pattern instances up-to-date until an updated pattern version is available. Which of these tasks you use depends on which OS each virtual machine is running:

W1500: Red Hat Enterprise Linux (RHEL) or Microsoft Windows

W1700: IBM AIX

To run yum tasks in RHEL, you can set up a yum repository hosted in the system using the Red Hat OS Update shared service. To automate running batches of commands on a range of virtual machines, you can use IBM Endpoint Manager, which can easily find the virtual machines deployed on the system using the IBM Endpoint Manager shared service. For a virtual system pattern, you can also write a script package to perform commands as a batch. Once you add a script package to a pattern, it will be part of all subsequent deployments of that pattern, but will not be part of previously existing deployments.

The Endpoint Manager and script package approaches can also be used to run commands to update middleware.

Task Role 4.4.7 Deploy Red Hat update service Application operations 4.4.8 Deploy endpoint management service Application operations 4.5.21 Maintain RHEL on virtual machine Application operations 4.8.9 Develop script package Content enablement


3.6.3 Tune virtual machine You may need to start, stop or delete VMs. Or, due to changes in the environment, you may need to change the resources (like vCPU, memory, storage) used by the deployment VMs. For VMs that you own or have access to, you can change the following:

Increase vCPU used by the VM.

Increase memory allocated to the VM.

Attach additional storage volumes to the VM.


3.6.3.2 Result VMs will have more resources, or VMs will be started, stopped or deleted.

3.6.3.3 Tasks Task Role 4.5.9 Administer virtual machines Application operations 4.5.10 Add storage to a virtual machine Application operations

3.6.4 Troubleshooting PureApplication System provides several approaches to diagnose problems on the system.

Problems are detected in two main ways:

1. Routine monitoring proactively indicates a problem (see 3.6.1 Monitor system and workloads).

2. Users report that workloads aren’t running properly.

To determine why a workload isn’t running properly, these questions can help you determine the scope of the problem:

1. Is there one problem occurring or multiple problems that seem to be related (such as all having started at about the same time)?

2. Are the problems all occurring in the same virtual machine (VM), in multiple VMs in the same pattern instance, or in multiple pattern instances?

3. If multiple pattern instances, do they share a cloud or hardware component in common (such as all running on the same compute node)?

If the problem is only affecting one VM, here are some things you can do to investigate:

View the VM’s status in the console.

You can use VNC and SSH to connect to the VM and use its normal debugging facilities.



If the problem is affecting a workload in general, here are some things you can do to investigate:

Look at the workload logs in the workload console.

Look at the storehouse browser to see the details of the patterns and deployments.

If the problem is affecting multiple workloads, then it is probably a system problem, such as a problem with a cloud or hardware component. Here are some things you can do to investigate:

Look for errors in the Event Log and Problem Log.

Review the status of the hardware components.

If you cannot resolve the problem on your own and want help from IBM Support, see 3.6.5 Incident management.


3.6.4.2 Result You now have some leads on how to troubleshoot problems on your system.

3.6.4.3 Tasks Troubleshooting is not a single series of tasks but an ongoing effort that makes use of various tasks as needed. You may need to enlist several roles with different skill sets to help with troubleshooting:

PureApplication Systems administrators

Middleware administrators

Your application development team.

Prior to executing the following tasks, the process of troubleshooting will usually involve:

Reviewing logs in the system console.

Examining events in the system console.

Reviewing overall system status in the system console.

To investigate problems affecting a single virtual machine (VM):

Task Role 4.5.8 View virtual machine status Application operations 4.5.11 Log into a virtual machine Application operations

To investigate problems affecting a single workload (a pattern instance, which is a collection of VMs):



Task Role 4.5.12 View workload status Application operations 4.5.13 Enable workload trace Application operations 4.5.14 View Storehouse browser Application operations

To investigate problems affecting multiple workloads (which could be caused by a single system problem):

Task Role 4.3.10 Monitor hardware Data center operations 4.3.11 Monitor events and problems Data center operations

3.6.5 Incident management IBM provides a single integrated point of support for all PureApplication System issues, for all components that are in the system or provided by IBM, whether they are hardware or software. This includes:

Hardware components (computing, storage, and networking)

Virtualization software (VMware or PowerVM®)

Operating system software (Red Hat Linux, Windows®, or AIX)

Middleware software (WebSphere Application Server, DB2)

Pattern deployment errors.

To request help from IBM Support, open a Service Request (SR, also known as a PMR or Problem Management Record) ticket for PureApplication System similar to what you already do for all other IBM products.

IBM Support will work with you to resolve the issue. Support might ask you to gather logs of different components. These logs can be downloaded using either the console or the command line interface (CLI).

For hardware failures, IBM will send a customer engineer (IBM CE) on site to resolve the issues. The IBM CE will need to log into the system using the IBMENG account, which you must enable.


3.6.5.2 Result You have contacted IBM Support and they have helped you to resolve your issue.

3.6.5.3 Tasks Task Role 4.3.1 Monitor support resources Data center operations




Task Role 4.3.2 Contact support Data center operations 4.3.3 Collect system logs Data center operations 4.3.4 Enable system trace Data center operations 4.3.5 Schedule IBM CE Data center operations 4.3.6 Enable the IBMENG account Data center operations


4 Tasks Finally, let’s consider the specific tasks that are performed by individual people using the system. Each task is performed by a single person working in a single role. They should be able to perform it in a single sitting, meaning that the person can accomplish the task in one uninterrupted period of time (a duration that could range from minutes to days) that requires very little collaboration with or waiting on the efforts of other people.

PureApplication System tasks are organized by role. If your job within the team is to perform a single role, learn those tasks and you’ll be well prepared to perform that role.

The first role, IBM CE, is fulfilled by IBM personnel. The other roles are fulfilled by your staff — that is, by members of the organization that owns the system.

Role Description 4.1 IBM CE Performed by IBM 4.2 Data center operations – Configure Initial setup of the system 4.3 Data center operations – Manage Ongoing management of the system 4.4 Application operations – Cloud admin Customization of the clouds 4.5 Application operations – Middleware admin Management of the workloads 4.6 Database operations Management of the databases 4.7 Finance and compliance Governance of usage 4.8 Content enablement Development of patterns 4.9 Application architecture Design of topologies 4.10 Application development Using patterns for application dev. 4.11 Database administration Using patterns for database dev.

4.1 IBM CE These are the tasks IBM personnel will perform to install and maintain a PureApplication System. You do not need to perform these tasks, but should be aware when IBM is performing them.

4.1.1 Ship hardware The hardware is shipped from the factory to the client location.

4.1.1.1 Preconditions You have ordered a system and specified the data center to which it should be shipped.

4.1.1.2 Result The hardware is now at the data center facility, presumably at the loading dock or elsewhere in the building. It needs to be placed in the proper position on the server floor. (See 4.2.2 Position hardware.)

4.1.1.3 Steps IBM performs these steps:



1. Manufactures the system in its factory, including installing system software.

2. Delivers the system to your data center.

4.1.2 Perform physical installation The hardware is prepared, connected to electricity, and powered on.

4.1.2.1 Preconditions You have:

1. Received the system (see 4.1.1 Ship hardware).

2. Placed it in the proper position in the data center (see 4.2.2 Position hardware).

4.1.2.2 Result The system is now powered on and the hardware is running.

Next step: 4.1.4 Perform software installation.

4.1.2.3 Steps The IBM CE performs these steps:

1. Inspect the site to verify that the system has adequate space, air conditioning, power, network connections, and so on.

2. Inspect the hardware for damage from shipping and correct any problems found.

3. Connect data center power to the PDUs.

4. Power on the hardware.

5. Verify the LEDs indicate the hardware is running properly.

4.1.3 Update system software There are essentially two types of updates in PureApplication System:

1. System – Updates to the system software.

2. Workload – Updates to the patterns and pattern instances.

This task focuses on system updates. A system update must be installed by the IBM CE.

Some notes about availability during a system upgrade:

A system update can be installed on a running system without causing an overall outage. However, individual system components might be taken offline and rebooted to install firmware updates. When this is necessary, each component comes in pairs (that is, the system contains two or more of each component; see 4.2.14 Configure for high availability), so the update process updates one component then the other, so that one is always online. This means no loss of functionality but does cause temporary losses of capacity.

A best practice is to ensure that each cloud group contains unused capacity equal to or greater than one compute node. If a compute node’s firmware needs to be updated, it



must temporarily be removed from the cloud group, which means the rest of the cloud group needs sufficient capacity to run the workloads. Otherwise, the update process will stop the lowest priority workloads so that it can upgrade the cloud group, and an administrator will need to restart them. One way to ensure adequate unused capacity is to temporarily enable each cloud group’s setting to reserve resources for availability.

A best practice for updating a PureApplication System with a system fix is to schedule it during a downtime period (weekends or after hours) so the update process will not degrade the running workloads. Because a fix can touch any combination of network, storage, compute firmware and management software, it is best to avoid updating the system during times of heavy usage. There are also breakpoints in the update process so you can add granularity to the maintenance window.

While the management nodes are being updated, the Integrated Console, CLI, and REST API will be unavailable. Workloads will keep running unaffected and administrators can still SSH into the OS of individual VMs. However, administrators will not be able to perform tasks that require logging into the system, such as deploying, starting, stopping, storing, and deleting pattern instances, developing patterns, collecting system logs, and so on.

4.1.3.1 Preconditions The system must be installed and running. See 4.1.4 Perform software installation.

4.1.3.2 Result The system is now running updated system software.

The system software version and build ID is shown in the System Console in the lower right corner and on the Help > About screen.

The workload software version and build ID is shown in the Workload Console in the lower right corner and on the Help > About screen.

Once the system software has been updated, the workload components (base OS images, shared services patterns, and virtual images and patterns) also need to be updated.

4.1.3.3 Steps These are the tasks the IBM CE performs to make sure the hardware is running the latest build of the system software.

1. If the currently installed release is not the latest, install the latest release.

2. If the currently installed fix pack is not the latest, install the latest fix pack(s).

3. If the currently installed cumulative fix is not the latest, install the latest cumulative fix(es).

4.1.4 Perform software installation The initial configuration of the system software is performed in accordance with the information gathered in the TDA.



4.1.4.1 Preconditions These tasks must have already been performed:

1. 4.1.2 Perform physical installation

2. 4.2.1 Complete TDA

4.1.4.2 Result The system is now ready for you to use.

4.1.4.3 Steps The IBM CE runs the system setup wizard, which has three main steps:

1. Run system diagnostics

a. Verifies the system is ready for system configuration.

2. Update firmware

a. This essentially does 4.1.3 Update system software.

3. System configuration

a. Uses the information from the TDA (see 4.2.1 Complete TDA).

b. Configures the networking, including DNS and NTP servers, which will connect the system to the data center network.

c. Configures a sample IP group and cloud group.

You help perform the last few steps of the system configuration:

d. You must accept the license agreements.

e. Specify the user name and password for the root system administration account.

After the wizard completes successfully, the IBM CE connects the data center network cables to the system’s top of rack switches. The system is now live, connected to the data center’s network, and ready for use. You are now responsible for the system.

You should perform a few verification steps:

1. Open the integrated console.

a. Log in using the credentials for the system administration account.

b. This is the main user interface for the system.

2. Deploy the validation application.

a. This verifies that the system can deploy a pattern.

b. The pattern instance is created in the sample IP group and cloud group.

c. The validation application includes a web UI that shows that the application is running.

You have now verified that the system has been installed and is working properly.



4.1.5 Replace hardware Each component in PureApplication System comes in pairs (that is, the system contains two or more of each component; see 4.2.14 Configure for high availability), so when a hardware component fails, the system loses redundancy and probably loses capacity but doesn’t lose functionality. The hardware components (disks, switches, compute nodes, and so on) are modular so that they can be replaced without causing a system outage. However, to replace a hardware component, an IBM CE must perform the work.

If a disk drive must be replaced, you will be permitted to keep the old drive only if you have purchased Hard Drive Retention Service. Hardware replacements are typically performed next business day, but can be performed the same day if you have purchased Business Critical Service. See 4.2.18 Consider appliance service upgrades.

4.1.5.1 Preconditions Perform these tasks first:

1. Report the hardware problem to IBM Support; see 4.3.2 Contact support.

2. Arrange access to your system for an IBM CE; see 4.3.5 Schedule IBM CE.

3. Arrange for the IBM CE to be able to log into the system as an IBM CE; see 4.3.6 Enable the IBMENG account.

4. If the hardware component is a compute node and it is still a member of a cloud group, remove it from that cloud group; see 4.3.8 Remove compute node from cloud group.

4.1.5.2 Result The defective hardware component has been replaced and the new component is now available for use by the system.

The system will start to use most components (such as disk drives and switches) automatically. If the component is a compute node, you need to add it to a cloud group to use it; see 4.3.9 Add compute node to cloud group.


1. Stops and powers down the old hardware component.

2. Pulls the old hardware component out of the rack.

3. Inserts the new hardware component into the rack.

4. Powers up and starts the new hardware component.

5. Verifies that the system now shows the new hardware component as available.

6. Returns the old hardware component to IBM.



4.1.6 Install additional compute node You have decided to upgrade your system from one capacity to another (see 4.3.7 Purchase additional computing capacity), which increases the number of CPU cores and the amount of memory in the system. This increase is accomplished by installing additional compute nodes into the system. New compute nodes must be installed by the IBM CE.

Compute nodes are installed without incurring an outage, so system availability is not affected. When complete, the system will show that it has additional unused compute nodes available.


1. Purchase additional capacity for your system; see 4.3.7 Purchase additional computing capacity.



4.1.6.2 Result The new compute node now shows in the list of compute nodes. The cloud administrator can now add it to a new or existing cloud group; see 4.3.9 Add compute node to cloud group.


1. Inserts the new compute node into the rack.

2. Powers up and starts the new compute node.

3. Verifies that the system now shows the new compute node as available.

4.1.7 Restore a management node If a management node becomes corrupted, the system will continue to function because the hardware components are redundant (see 4.2.14 Configure for high availability). Meanwhile, the malfunctioning management node needs to be fixed or replaced.

If the management node’s hardware is failing, it needs to be replaced (see 4.1.5 Replace hardware). If the management node has just been replaced, or otherwise, if its software is corrupt, it needs to be restored using its peer that is functioning properly. Restoring a management node from its peer ensures that their configurations are consistent. The task of restoring a management node from its peer must be performed by an IBM CE.






4.1.7.2 Result The defective management node is now functioning properly. It is now probably the standby node, but can become the primary if the IBM CE forces a failover.


1. Verifies that the hardware in the management node is working properly.

2. Uses the active node to restore its software and configuration onto the defective node.

3. Verifies that the restored node is working properly and is operating as a standby to the active node.

4. Optional: Forces a failover to verify that the restored node takes over properly.

4.1.8 Perform system restore If both sets of management nodes on a system become corrupted, the only way to fix them is to restore a system backup. This, of course, requires that a system backup was performed successfully (at least once) and that administrators have access to the backup archives. A system restore can only be performed by an IBM CE.


IBM developerWorks: PureApplication System Backup and Restore, Part 2: System Backup

4.1.8.1 Preconditions To perform a system restore, a system backup must have been performed first. The backup is encrypted; the IBM CE will need an administrator to input the passphrase for the private key.

1. Perform a system backup to be prepared to perform a system restore if necessary; see 4.2.16 Configure system backup

Perform these tasks first:



4.1.8.2 Result The system is now restored to the state it was in when the last backup was taken. The virtual images may need to be restored separately. If any workloads are still running, the


https://www.ibm.com/developerworks/websphere/techjournal/1402_woolf2/1402_woolf2.html



system might no longer know about them, so they will need to be stopped and deleted manually.


1. Accesses the backup archives.

a. These are accessed through the same System Backup settings used to store the archives.

b. To decrypt the archives, in the restore GUI, an administrator will need to type in the passphrase for the private key (or the administrator can give this passphrase to the IBM CE).

2. The restore process will take several hours.

a. Any workloads still running will continue to run, but cannot be managed.

4.2 Data center operations – Configure These are the tasks data center operations personnel will perform to initially configure a new PureApplication System.

4.2.1 Complete TDA The Technical and Delivery Assessment (TDA) needs to be completed.

4.2.1.1 Preconditions The IBM CE will provide you with the empty TDA template document.

4.2.1.2 Result The completed TDA represents an agreement between you and IBM that will guide the process for delivering and placing the system within the data center, wiring it into the data center, and setting its initial configuration.

4.2.1.3 Steps Data center operations and the IBM CE work together to complete the TDA. It documents:

Shipping and delivery logistics.

Power and wiring requirements.

Network connectivity information (VLANs, IP groups for the client data and management network in the rack).

4.2.2 Position hardware The hardware needs to be received and moved into the data center.



4.2.2.1 Preconditions The system must be ordered and shipped to the customer. (See 4.1.1 Ship hardware.)

4.2.2.2 Result The system is now positioned on the floor in the data center and ready for the IBM CE to power it on. (See 4.1.2 Perform physical installation.)

4.2.2.3 Steps Documentation about the system and preparing for it:

Information Center: Site-readiness planning (W1500) (W1700)

Information Center: W1500 system specifications (mini) (large)

Information Center: W1700 system specifications (mini) (large)

The IBM CE will assist with:

Selecting a site — including a data center and a specific place on the server floor — that meets the system’s requirements for space, air conditioning, power, and so on.

Data center operations will perform these steps (with guidance from the IBM CE):

1. The system is received from the shipper at the client’s data center. (See 4.1.1 Ship hardware.) Except for the power and the external network connections, PureApplication System comes pre-configured and pre-wired.

2. Unpack the system.

3. Move the system into position within the data center.

4. Do not connect the system to the data center power supply or turn it on. The IBM CE will do that.

4.2.3 Configure LDAP settings A user registry hosted in an LDAP server should be used to manage the users and user groups for logging into the system. LDAP provides better management of passwords and account lifecycles.

4.2.3.1 Preconditions The data center must host a user registry in an LDAP server. This directory must contain accounts for all of the users who will log into the system. (Additional users can be declared in the system locally, but most should be mapped from LDAP.)

To perform this task, you will need the Security Administration role with permission to Manage security (Full permission).

4.2.3.2 Result The system is now configured to use the LDAP server to get group definitions and membership.


http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/installguide/planning/purescaleplankickoff.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1700.doc/installguide/planning/purescaleplankickoff.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/installguide/planning/ps_sysreq_mini.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/installguide/planning/ps_sysreq.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1700.doc/installguide/planning/ps_sysreq_mini.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1700.doc/installguide/planning/ps_sysreq.html


4.2.3.3 Steps Perform these steps:

1. Information Center: Integrating with LDAP servers

4.2.4 Configure users The administrator does not need to define users in the system for those that are mapped from the LDAP server’s user registry. However, any system users that are not mapped from LDAP must be defined in the system’s local registry. If the system is not configured to use LDAP, all users must be defined in the system’s local registry.

4.2.4.1 Preconditions To create a user, you will need the Security Administration role with permission to Manage security (Full permission).

4.2.4.2 Result Users are defined in the system’s local user registry. People can now log into the system via these user accounts. Each user can be added to user groups.


1. Information Center: Managing system users

4.2.5 Configure user groups User groups should be designed for various roles on the system. These groups enable separation of duties (SoD).

Permissions for users and groups: There are several fine grain access security roles that can be granted to the users and groups. The administrative roles are workload, cloud, hardware, auditing, disaster recovery, and security. Workload management also defines four sub-roles. Users can be granted roles and there is a mechanism by which they can delegate their roles to other users or groups. Users in groups inherit the group permissions, and inherit a permission if any one of its groups possesses that permission.

4.2.5.1 Preconditions The user groups should implement a design that captures roles and responsibilities.

To map groups from LDAP, the system must be configured with access to an LDAP server. (See 4.2.3 Configure LDAP settings.)

To create a group, you will need the Security Administration role with permission to Manage security (Full permission).


http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/iwd/ldap_integrate_overview.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/iwd/aat_manusui.html


4.2.5.2 Result The user group design is now implemented as a set of user group objects in the system, each with the permissions for the roles specified by the design. You can now assign roles to the user groups to allow access to system tasks.


1. Information Center: User management

2. Information Center: Security roles

3. Information Center: Managing user groups


IBM developerWorks: Managing administrative access in IBM PureApplication System

4.2.6 Add roles to a user or group Once users and user groups are created, to perform most tasks in the system, they need to be assigned the role for that task. Although roles can be assigned to individual users, roles should be assigned to groups to help preserve uniformity between users in a group. To assign a role to a user or group, the user assigning the role must himself already have permission for that role and permission to delegate roles.

Note that Auditing is a special role. A user or group with the Auditing role should not have any other security roles, and vice versa. This prevents a user from making a change to the system’s configuration and then deleting the record of that change.

4.2.6.1 Preconditions This task assumes that the user or user group already exists so that its roles can be modified. (See 4.2.4 Configure users and 4.2.5 Configure user groups.)

To assign a security role to a user or user group:

1. You will need to be able to edit users and groups: You will need the Security Administration role with permission to Manage security (Full permission).

2. You will need to be able to assign roles: The role you wish to assign must be assigned to you, with Full permission, before you can assign it to others. You will also need the permission to Allow delegation when full permission is selected.

4.2.6.2 Result The user or group now has the assigned roles. When that user or a member of that group attempts to access or change part of the system, his new roles will determine whether he is permitted to perform that task.



http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/iwd/aac_user_compliance_security.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/iwd/aac_user_permissions.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/iwd/aat_manugui.html




1. This effort is best described in Information Center: Administering users. The steps work the same for a user group.

4.2.7 Configure network settings The customer network is composed of one or more VLANs the user workloads use to communicate. Their traffic transmits on the networking hardware within the system, as well as outside of the system to and from the rest of the data center. These VLANs must be defined on the system so that it will allow their traffic, starting with the top of rack switches that connect the system to the external network in the data center. Ports and link aggregation must be defined on the top of rack switches, and the VLANs must be assigned to the ports. Configure network settings on the Customer Network Configuration page. (Go to System Console > System > Customer Network Configuration.)

When you make changes to the network configuration, it takes time for the system to update the configuration of all of its LAN switches and adapters (typically 5-15 minutes, depending in part on the size of the system). The configuration is performed as a job shown on the job queue. (See 4.3.12 Monitor job queue.) You can watch for completion of the job to know that the configuration has been updated.

You can see what VLANs the system is configured to use. The system’s VLANs are shown on the Virtual Networks page. (Go to System Console > Hardware > Virtual Network.) The attributes page for a customer data network shows the ports and links in the top of rack switch for that network and the IP groups and cloud groups defined to use that network.

You can look at the network devices to see what VLANs are declared on each. View the network devices on the Network Devices page. (Go to System Console > Hardware > Network Devices.) Select a network switch, and in the Switch Status section, run the command to show VLANs.

4.2.7.1 Preconditions To perform this task, you will need the Hardware administration role with permission to Manage hardware resources (Full permission).

4.2.7.2 Result The management VLAN will be configured (if it wasn’t already). Additional customer data VLANs will be configured.


1. Information Center: Configuring network settings

4.2.8 Configure DNS settings Modify Domain Name System (DNS) settings for the system. The system DNS is used to display IP groups in the system console.


http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/iwd/aat_user_manage.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/systemconsole/t_mngean.html



4.2.8.2 Result The system has access to the network’s DNS servers. It uses these to resolve the IP addresses and hostnames used in the IP groups. (See 4.2.12 Configure IP groups.)


1. Information Center: Administering the DNS server

4.2.9 Configure NTP settings Modify Network Time Protocol (NTP) server settings for the system. The system uses NTP to set its clock, which is turn is used to set the clocks of everything running on the system (hardware components, the OS in each virtual machine, and so on).


4.2.9.2 Result The clocks for the system and all the workloads will now be synchronized with the data center’s time system.


1. Information Center: Configuring date and time settings

4.2.10 Configure SMTP settings Configure the Simple Mail Transfer Protocol (SMTP) server for the system to use. If the SMTP server is set, the system will provide e-mail notification on events.


4.2.10.2 Result The system can now send e-mail notifications using this server.



http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/iwd/aat_dnsui.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/iwd/aat_dattimui.html


1. Information Center: Configuring email delivery

4.2.11 Configure SNMP settings You might want to use external monitoring of the system so that you can use your data center’s monitoring solution to process important events generated by the system. To do so, configure the system with SNMP traps, which will forward events to the trap destinations you specify. You can also download the MIB and OMNIbus rules for your SNMP server to process the traps.

The events that are forwarded are filtered from the Events list. See 4.3.11 Monitor events and problems.

Many external enterprise monitoring solutions can be used with PureApplication Server. For example, an IBM Tivoli® Netcool®/Omnibus external server can be configured as a trap destination for SNMP events from PureApplication System. These events include selected hardware and software events. A single PureApplication Server MIB is provided for external enterprise monitoring solutions and a set of OMNIbus rules are provided for Netcool/OMNIbus. The system provides a download link for MIB and OMNIbus rules from the GUI. PureApplication System v1.1 also has the ability to directly route Event Integration Facility (EIF) events to a Netcool/OMNIbus infrastructure.

PureApplication System includes the Monitoring Agent for IBM PureApplication System, known more simply as the PureApplication System Agent (sometimes referred to as the “Q8 agent”). It is included as part of the System Monitoring shared service (see 4.4.1 Deploy base service for internal monitoring), but you can also install it externally and connect it to an existing external IBM Tivoli Monitoring environment. This agent monitors high level events occurring in PureApplication System.

Finally, DB2 databases installed on PureApplication system come pre-installed with the monitoring agent for Optim Performance Manager. While you can view the OPM events within the OPM console inside PureApplication System, it is also possible to connect the OPM to an external monitoring infrastructure through generation of SNMP events.


4.2.11.2 Result The system will now forward monitoring events to the external monitor:

Configure your external system as an SNMP trap destination and configure PureApplication System to send those events to enable external monitoring of PureApplication System.

Configure your external monitoring system as a destination for EIF events.

Install the PureApplication System agent that comes with the system to connect to an existing external IBM Tivoli Monitoring environment.


http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/iwd/aat_maildeui.html



1. Information Center: Configuring event forwarding

4.2.12 Configure IP groups An IP group is a cloud component that provides the ability to group a set of IP addresses in a VLAN on a network into a pool of reusable addresses. When a pattern is deployed as a pattern instance, each virtual image is instantiated as a virtual machine and each VM needs an IP address. To help automate the deployment of patterns, the deployment process can get the IP address for each VM from the pool in an IP group. When a pattern instance is deleted, the IP addresses assigned to its VMs are returned back to the pool so they can be reused to deploy other VMs.

An IP group is created using settings obtained from the network administrator. This is a set of IP addresses, all part of the same VLAN, with other settings to specify the network the VLAN is part of.

Once an IP group is created, you need to add some IP addresses to make it functional.

An IP group’s configuration can be modified to:

Add more IP addresses.

Remove any unused IP address and optionally add them to another IP group.

Remove the IP group from the cloud (as long as all of its IP addresses are unused) and optionally add it to another cloud group.

Change the access control. (See 4.8.19 Configure authorization.)

Once you create an IP group, you cannot rename it or change its VLAN. To change its network properties (gateway, DNS, and so on), all IP addresses must be unused.

4.2.12.1 Preconditions For an IP group to use a VLAN, that VLAN must be configured on the system’s networking hardware. See 4.2.7 Configure network settings.

To perform this task, you will need the Cloud group administration role with permission to Manage all cloud groups (Full permission).

4.2.12.2 Result A new IP group exists in the system and is available to be added to a cloud group.


1. Consult with the application and database operations teams on their requirements for IP addresses and VLANs.

2. Consult with the network administrator to get a set of IP addresses on a VLAN that will meet these requirements.


http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/iwd/mot_overview.html


3. Create or update an IP group as described in: Information Center: Administering IP groups

4.2.13 Configure cloud groups A cloud group is a cloud component that creates a cluster of compute nodes so that they act as one. It includes IP groups to assign IP addresses to virtual machines as they’re deployed. Each cloud group is isolated from the others so that each one’s CPU and memory resources are independent from the others.

After creating a cloud group, you need to add at least one compute node and at least one IP group to make it functional.

A cloud group’s configuration can be modified to:

Add an unused compute node to increase cloud capacity.

Remove a compute node to shrink cloud capacity, and optionally add it to another cloud group.

Add additional IP groups.

Remove an IP group (as long as all of its IP addresses are unused) and optionally add it to another cloud group.

Set quality of service. (See 4.2.14 Configure for high availability.)

Change access control. (See 4.8.19 Configure authorization.)

4.2.13.1 Preconditions At least one unassigned compute node and one unassigned IP group must be available.


4.2.13.2 Result A new cloud group exists in the system and is available to be used by an environment profile.


1. Consult with the application and database operations teams on their requirements for deployment environments.

2. Information Center: Administering cloud groups




http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/iwd/srt_admipui.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/iwd/srt_admipui.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/systemconsole/t_mngcloudgroups.html




4.2.14 Configure for high availability Everything in PureApplication System is redundant to prevent any single point of failure. The system contains at least two of each piece of hardware: LAN switches, storage units, SAN switches, power units, management modules, management nodes, compute nodes, LAN and SAN adapters. A hardware failure could cause a loss of capacity but not a loss of functionality. Each piece of hardware is a modular unit that can be replaced while the rest of the system is still running. This redundancy means that collectively all of the hardware in a system is highly available, that the system has high availability (HA).

Since a workload runs in a cloud group, to help make the workloads HA, the cloud groups must be HA. That way, if part of a cloud group fails, it can failover the affected workloads to the remaining parts. For a cloud group to be HA, you have to configure it that way.

A cloud group can be configured for high availability. To do so:

Configure the cloud group with at least two compute nodes.

Enable it to reserve resources for availability.

When adding multiple compute nodes to a cloud group in a large system, the compute nodes should be spread evenly across the three chassis. In a W1500 system, select compute nodes from both columns. In other words, if you are adding three compute nodes to a cloud group, add one from each chassis; on a W1500, chose two compute nodes from one column and one from the other column.

The high availability indicator on a cloud group shows whether sufficient unused capacity exists in the cloud group so that if one compute node failed, all of its VMs could be migrated to the remaining compute nodes.

Not all cloud groups need to be configured for high availability. A cloud group for production workloads probably needs it to ensure sufficient capacity, whereas another for development workloads may not need this assurance.

4.2.14.1 Preconditions To perform this task, you will need the Cloud group administration role with permission to Manage all cloud groups (Full permission).

4.2.14.2 Result The cloud group is now configured for high availability, such that its workloads will keep running even when one of its compute nodes fails.

4.2.14.3 Steps You can confirm the high availability status of the system in the High Availability section of the System Troubleshooting page.

1. Go to System Console > System > Troubleshooting > High Availability.

2. Confirm that the status is Online.

For more information on HA in the system’s hardware, see:



IBM developerWorks: A tour of the hardware in IBM PureApplication System

To configure a cloud group with multiple compute nodes for HA:

See 4.2.13 Configure cloud groups

4.2.15 Configure product licenses The system enables product licenses to be pooled and managed like any other shared resource. Just like the system contains certain amounts of CPU, memory, and storage, and can be configured with sets of IP addresses, it can also be configured with sets of middleware licenses. As patterns containing the middleware are deployed, they will consume licenses from the pool.

The page also enables you to connect the system to an external IBM License Metric Tool (ILMT) server.

4.2.15.1 Preconditions To perform this task, you will need either of these permissions:

The Hardware administration role with permission to Manage hardware resources (Full permission)

The Cloud group administration role with permission to Manage all cloud groups (Full permission)

4.2.15.2 Result The system is now configured with pools of licenses for various middleware products. For each product, the system knows what to do when the limit is reached and when to notify the middleware administrator. Optionally, it is now also configured to use ILMT.


1. Information Center: Administering product licenses

4.2.16 Configure system backup As with other systems, administrators should maintain a current set of backups of the system and its workloads. System backup creates an archive the system’s internal management data, its cloud environment, and its workload catalog. It stores the archives on an external server you specify. You can configure it to run on a set schedule, such as daily. The first backup produces a baseline; subsequent backups are deltas.



http://www.ibm.com/developerworks/cloud/library/cl-ps-aim1302-hardwarepureapp/

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/iwd/lit_licensui.html


4.2.16.2 Result The system is now configured to perform a system backup and will do so on the schedule you configured. You can also run it manually with the press of a button.


1. Information Center: Managing backup and restore


IBM developerWorks: PureApplication System Backup and Restore, Part 2: System Backup

4.2.17 Script system configuration tasks We’ve shown tasks for configuring the system using the console. Once you’re comfortable with how to do this, it can be helpful to write CLI scripts to perform the configuration. These scripts automate the tasks to avoid mistakes, represent the tasks as source code so it can be stored in an SCM system, and are useful for configuring multiple systems consistently.

4.2.17.1 Preconditions To run the scripts that populate the user registry, you will need:

The Security Administration role with permission to Manage security (Full permission).

To run the scripts that configure the system settings, you will need:

The Hardware administration role with permission to Manage hardware resources (Full permission).

To run the scripts that create the cloud environment, you will need:

The Cloud group administration role with permission to Manage all cloud groups (Full permission).

To run the scripts that configure backup, you will need:

The Hardware administration role with permission to Manage hardware resources (Full permission).

4.2.17.2 Result You can configure the system to your specifications by running a set of scripts. Store these in SCM for later use. Use these to keep a record of your configuration, to fix the configuration if it gets messed up, and as a basis to configure another system the same as or similar to the first.



http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/iwd/brc_overview.html




1. Understand the CLI

a. Information Center: Using the command-line interface

b. Information Center: Using the command line interface for the system console

2. Populate user registry

a. Information Center: Change LDAP setting

b. Information Center: Create a user

c. Information Center: Create a group

d. Information Center: Add new roles to the group

3. Configure system settings

a. Information Center: VLANs - add

b. Information Center: Add DNS servers

c. Information Center: Add NTP servers

d. Information Center: SMTP server - set up

e. Information Center: Create trap destination

4. Create cloud environment

a. Information Center: IP groups - create

b. Information Center: Cloud groups - create

c. Information Center: License management command-line interface reference

5. Configure backup

a. Information Center: Change a specific backup setting

4.2.18 Consider appliance service upgrades You should consider purchasing two optional service upgrades for your system:

1. Business Critical

2. Hard Drive Retention

The standard hardware replacement agreement for PureApplication System is next business day. This means that if you submit a Service Request and IBM Support determines at 8 PM on a Friday that a hardware replacement is needed, this will be scheduled for sometime on Tuesday (assuming Monday and Tuesday are business days). This delay may be undesirable if the system is being used to host production workloads.

IBM has a program called the Business Critical Service option whereby once it is determined that a part needs to be replaced, the replacement will be started within 4 hours (365 days a year).


http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/iwd/cct_usingcli.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/clihelp/cliForSystemConsole.html


http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/clihelp/change_LDAP_setting.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/clihelp/create_a_user.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/clihelp/create_a_group.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/clihelp/add_new_roles_to_group.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/clihelp/add_vlan.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/clihelp/add_DNS_servers.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/clihelp/add_NTP_servers.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/clihelp/setup_smtp_server.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/clihelp/create_trap_destination.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/clihelp/create_an_ip_group.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/clihelp/create_a_cloud_group.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/iwd/lir_cli_license.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/iwd/lir_cli_license.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/clihelp/change_specific_backup_setting.html


Customers with confidential data should consider purchasing the Hard Drive Retention Service option. When an IBM CE replaces a hardware component, they are required to return the old component to IBM. With Hard Drive Retention, when the IBM CE replaces a disk drive, you get to keep the defective drive to ensure it is erased satisfactorily.

For more details, see:

Service upgrades are described in the IBM Passport Advantage Appliance Support Handbook. Go to: http://www.ibm.com/software/appliance/support/ to download the handbook.

See also: Maintenance option for Hard drive Retention: http://www-935.ibm.com/services/us/en/it-services/maintenance-option-for-hard-drive-retention.html

4.2.18.1 Preconditions You must own a system.

4.2.18.2 Result The system now has upgraded support.


1. Contact your IBM sales representative to purchase these options.

4.3 Data center operations – Manage These are the tasks data center operations personnel will perform continually to keep a PureApplication System running well.

4.3.1 Monitor support resources The PureSystems Centre lists all software available for PureApplication System:

1. Patterns from IBM and third-party vendors

2. System software updates

3. Updates to shared services, patterns, and virtual images

The PureApplication System Support Portal lists all of IBM Support’s materials for PureApplication System. This includes:

1. Documentation

2. Fixes

3. Tools

4. Subscribe to support notifications

The PureApplication System section of developerWorks lists articles and other resources for learning about PureApplication System.


http://www.ibm.com/software/appliance/support/

http://www-935.ibm.com/services/us/en/it-services/maintenance-option-for-hard-drive-retention.html




4.3.1.1 Preconditions None, though the Support Portal provides a better experience if you create and login with an IBM ID.

4.3.1.2 Result You know where to look to stay abreast of new software released for PureApplication System.


1. Visit the PureSystems Centre

a. Go to: http://www.ibm.com/PureSystems/Centre.

b. On the Patterns tab, select PureApplication System.

c. On the System Updates tab, select PureApplication System.

2. Visit the PureApplication System Support Portal

a. Go to: http://www.ibm.com/support/ and look up PureApplication System.

b. Or go directly to: http://www.ibm.com/support/entry/myportal/product/puresystems/pureapplication_system

3. Visit the PureApplication System section of developerWorks

a. Go to: http://www.ibm.com/developerworks/puresystems/pureappsystem.html

4.3.2 Contact support When you need help from IBM Support, you open a Service Request (SR) (also known as a Problem Management Report or PMR). There are two main ways to open an SR:

The preferred method is to use the web-based Service Request Tool: Service requests & PMRs.

o This tool requires that you have a user account for the IBM Support Portal, that your account is associated with the IBM Customer Number (ICN) your company used to purchase PureApplication System, and that your company’s Passport Advantage administrator has authorized you to open SR’s for PureApplication System using that ICN.

Another option is to report a problem to IBM Support using the telephone, a service known in the United States as 1–800–IBM-SERV.

o Use the telephone menu to follow the route to PureApplication System: Choose the options for non-Lenovo, Software, and Middleware.

o Specify the product as PureApplication System running firmware OS.


http://www.ibm.com/PureSystems/Centre

http://www.ibm.com/support/

http://www.ibm.com/support/entry/myportal/product/puresystems/pureapplication_system


http://www.ibm.com/support/servicerequest/Home.action



o Be prepared with your company’s ICN and your system’s serial number (also known as model type and serial number, or MT/SN).

4.3.2.1 Preconditions IBM Sales provided your company with an IBM Customer Number (ICN) for the PureApplication System purchase. Your company’s Passport Advantage administrator must authorize you by name to report problems on this product.

4.3.2.2 Result You now have an existing service request with a unique three-part ID: <service request number>,<branch>,<country/region code>. You can query this request to see its current status; go to Service requests home. You may need to upload log files and collection sets for your SR; see the documents on exchanging information.

4.3.2.3 Steps Here are some resources that explain how to work with IBM Support for PureApplication System:

IBM Support Portal: Welcome to PureApplication System Support (Reference #: 1599652)

IBM Support Portal: Contacting IBM PureApplication System Support (Reference #: 1609051)

IBM Support Portal: Organizing your problem information when reporting PureApplication System problems (Reference #: 1654210)

IBM Support Portal: MustGather: Read first for PureApplication System (Reference #: 1610259)

IBM Support Portal: Exchanging information with IBM PureApplication System Technical Support for problem determination (Reference #: 1596913)

IBM Support Portal: Customer Support Plan for PureApplication System W1500 & W1700 (Document ID: PRS4980)

Information Center: Troubleshooting and support

IBM Redbook: Adopting IBM PureApplication System V1.0 (see Chapter 8: Troubleshooting PureApplication System Environment)

4.3.3 Collect system logs To help diagnose problems on your system, IBM will often ask you to take a collection set, which is a set of multiple system logs from various components in the system. There are different types covering different portions of the system and individual components. IBM Support will tell you which type(s) to take, based on the problem symptoms you report.



http://www.ibm.com/support/docview.wss?uid=swg21599652







http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/PRS4980

http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/PRS4980

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/iwd/tst_trouble_overviewnonUI.html


4.3.3.1 Preconditions To perform this task, you will need the Hardware administration role with permission to View all hardware resources (Read-only).

4.3.3.2 Result You now have a collection set you can send to IBM Support for analysis.


1. Information Center: Viewing and downloading log files

4.3.4 Enable system trace A trace shows IBM the exact code paths your system follows when performing a task. This is invaluable for diagnosing a problem you’re encountering. To enable a trace, you select the code components whose operations you want to log, and the granularity of logging for each. IBM Support will tell you when to enable tracing and how to configure it, based on the problem symptoms you report. Trace costs performance overhead, so when finished diagnosing the problem, remember to turn off tracing.


4.3.4.2 Result You now have a trace log you can send to IBM Support for analysis.


1. Information Center: Managing trace settings

4.3.5 Schedule IBM CE Certain work on the system has to be performed by an IBM Customer Engineer (IBM CE), such as replacing faulty hardware, adding new hardware, installing system software fix packs, and so on. To do so, the IBM CE needs physical access to the system in the data center. You must arrange with IBM to request that this work be performed and to allow the IBM CE access to the system.

4.3.5.1 Preconditions Arrange with IBM Support for the work to be performed. (See 4.3.2 Contact support.)

4.3.5.2 Result You, IBM Support, and the IBM CE now agree on what work the engineer will do, where, and when. You are now in contact with the IBM CE to arrange any last-minute changes.


http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/iwd/tst_logging.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/iwd/t_trace.html



1. Request help from IBM Support, part of which includes determining what needs to be done by an IBM CE. Give Support your contact information, which they will pass on to the engineer.

2. Wait for the IBM CE to contact you. Make specific arrangements with the engineer.

4.3.6 Enable the IBMENG account To perform maintenance on the system, an IBM CE will need to log into the system using the IBMENG account. This account has complete access to the system hardware but lacks any of the permissions of the Workload resources administration role, and so has no access to your system’s patterns, pattern instances, or application data.


4.3.6.2 Result The IBM CE will use the key you generated to obtain a password to log into your system using the IBMENG account.


1. Information Center: Enabling ibmeng access for the IBM service representative

4.3.7 Purchase additional computing capacity Here here here PureApplication System is available in two models — W1500 Intel and W1700 Power — and several configurations. The configurations support various workload capacities, whose size is described by the number of CPU cores in the system, which represents the number of compute nodes. Typical sizes are 96, 192, 384, and 608 cores. An existing system can be expanded in 32-core multiples by adding additional compute nodes.

If your system needs additional computing capacity, you can purchase an upgrade to a larger configuration from IBM Sales. The hardware upgrade itself is performed by an IBM CE who installs the additional compute nodes for the upgrade.

4.3.7.1 Preconditions You must already own an existing system. Its chassis must contain empty bays into which additional compute nodes can be installed.


http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/iwd/tst_enablece.html


4.3.7.2 Result After the IBM CE installs the additional compute nodes, the new nodes will appear in the System Console as available. You can:

Add one or more available compute nodes to an existing cloud group. (See 4.3.9 Add compute node to cloud group.)

Create a new cloud group and add available compute nodes to it. (See 4.2.13 Configure cloud groups.)


1. Contact your IBM sales representative to purchase a larger configuration.

2. Arrange an IBM CE to install the upgrade. (See 4.3.5 Schedule IBM CE.)

4.3.8 Remove compute node from cloud group If a cloud group contains too much computational capacity, you can reduce that capacity by removing a compute node. This makes the compute node available to be added to another cloud group to increase its computational capacity. Configure cloud groups on the Cloud Groups page. (Go to System Console > Cloud > Cloud Groups.)


4.3.8.2 Result The cloud group now contains less computational capacity and one or more additional compute nodes are now available.


1. In the cloud group’s list of compute nodes, delete one. See Information Center: Viewing and modifying cloud groups.

The delete command takes care of all (or at least most) of the dirty work:

The system quiesces the compute node.

If the compute node contains running VMs, the system evacuates them onto the other compute nodes. (This works much like putting the compute node into maintenance mode.) Evacuation is a planned failover, so each VM remains available except for a brief outage to switch connections from the original to the copy.

If the rest of the cloud group contains sufficient available capacity for the VMs, the evacuation succeeds and the compute node is removed from the cloud group.


http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/iwd/cgt_cgvmwedi.html


If the available capacity in the rest of the cloud group is insufficient, the system evacuates the VMs it can and then leaves the compute node quiesced. You have to manually resolve the remaining VMs, then delete the compute node from the cloud group.

4.3.9 Add compute node to cloud group If a cloud group needs additional computational capacity, you can increase that capacity by adding a compute node.


Your system must contain an available compute node—one that is running properly and is not already a member of any cloud group. To make one available, remove it from its current cloud group. (See 4.3.8 Remove compute node from cloud group.)

4.3.9.2 Result The cloud group now contains more computational capacity. The compute nodes that were added are no longer available to be added to other cloud groups.


1. In the cloud group’s list of compute nodes, add an available one. See Information Center: Viewing and modifying cloud groups.

Once the compute node has been successfully added to the cloud group, here’s what happens:

The cloud group will not immediately redistribute VMs to the new compute node since they’re already running happily where they are.

New deployments will make use of the capacity in the new compute node.

If a compute node in the cloud group runs into capacity issues — such as CPU overcommit in an average cloud group causing contention — to increase performance, the cloud group can decide to redistribute some VMs onto the new compute node.

4.3.10 Monitor hardware The console views for many of the hardware components in the system show not only the attributes of the component but also real-time status information about the component.

4.3.10.1 Preconditions To perform this task, you will need the Hardware administration role with permission to View all hardware resources (Read-only).


http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/iwd/cgt_cgvmwedi.html


4.3.10.2 Result You’re able to see the status of hardware components and any problems that have been detected.


1. The Infrastructure Map shows an overview of all hardware components in the system. In the graphical view, overlays for Status, LEDs, Temperature, and Performance show events, front panel indicator lights, heat, and utilization of each component. See Information Center: Viewing the hardware infrastructure.

2. Individual component types show details about their status. See Information Center: Monitoring the hardware.

4.3.11 Monitor events and problems The Event Log is a centralized, real-time reporting of all problem and status notifications from all system-level components and software. When a component detects a situation and announces it, that announcement is added to the Event Log.

The Problem Log is a subset of the Event Log, the events that indicate problems, events whose category is “Call Support.” Each problem in the list shows additional details that will be helpful to support. (See 4.3.2 Contact support.)

The System Console indicates major events with a number that quantifies how many events (major and above) are listed. It opens a summary that lists the most recent error events. View this summary by clicking on the error symbol on the system console’s menu bar.

4.3.11.1 Preconditions To perform this task, you will need the Hardware administration role:

To view the list, you will need permission to View all hardware resources (Read-only).

To hide or delete events from the list, you will need permission to Manage hardware resources (Full permission).

4.3.11.2 Result You’re able to see the event notifications that have occurred in the system and, optionally, to hide or delete events. You can easily see which ones are problems and details that will help you describe the problem to IBM Support.


1. Information Center: Monitoring system events

2. Information Center: Monitoring system problems


http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/systemconsole/t_infragraphic.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/iwd/vit_monitoring_hardware.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/systemconsole/t_mngevents.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/systemconsole/t_sysprob.html


4.3.12 Monitor job queue The system performs most complex tasks as batch jobs that are queued up for execution. The job queue shows the jobs that are currently started and pending.

4.3.12.1 Preconditions To perform this task, you will need the Hardware administration role:

To view the queue, you will need permission to View all hardware resources (Read-only).

To delete jobs from the queue, you will need permission to Manage hardware resources (Full permission).

4.3.12.2 Result You’re able to see the jobs the system is performing and, optionally, are able to delete jobs.


1. Information Center: Administering the job queue

4.3.13 View activity reports PureApplication System provides several reports that can also be used to see the utilization of the system resources and take corrective steps. There are several different types of reports: Machine activity, User activity, Metering, Chargeback, and IP usage.


The Hardware administration role with permission to View all hardware resources (Read-only)

The Cloud group administration role with permission to View all cloud resources (Read-only)

The reports include links to individual hardware and cloud group resources. To open those links, you’ll need permissions to view that resource.

4.3.13.2 Result The reports show you how system resources are being utilized over time.


1. Information Center: Administering reports


http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/iwd/aat_overview_taskQ.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/iwd/ret_reportin.html


4.3.14 Monitor product licenses The page used to configure product licenses also shows how licenses are being used. The licenses tables include columns that show how many licenses are reserved, how many of those are being used, and which pattern instances are using them. The page also provides the ability to download license usage data.

Separately, there are related reports for Metering and Chargeback. See 4.3.13 View activity reports.


The Hardware administration role with permission to View all hardware resources (Read-only)

The Cloud group administration role with permission to View all cloud resources (Read-only)

4.3.14.2 Result You can now see which pattern instances are consuming which licenses. If the system runs out of licenses for a product, this view can be used to determine which pattern instances are consuming licenses; you can consider stopping or deleting them to make their licenses available once more.


1. Information Center: Administering product licenses

4.4 Application operations – Cloud admin These are the tasks application operations personnel will perform to initially configure a cloud group with the shared services its applications will need.

4.4.1 Deploy base service for internal monitoring You can monitor the virtual machines (VMs) of the deployed virtual system and virtual application instances. This task configures the service for internal monitoring, so the service hosts three servers (each in its own VM) that together comprise a Tivoli Monitoring hub:

1. ITM-Hub-TEMS – Tivoli Enterprise Monitoring Server (Hub-TEMS) and Tivoli Enterprise Portal Server (TEPS)

2. ITM-Remote-TEMS – Remote TEMS

3. ITM-Data-Warehouse – Tivoli Data Warehouse

If you prefer to connect directly to a Tivoli Monitoring hub hosted in the data center, skip this task and perform the one for external monitoring: 4.4.2 Deploy base service for


http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/iwd/lit_licensui.html


external monitoring. Don’t perform both tasks; the service cannot be deployed in the same cloud group twice.

4.4.1.1 Preconditions The base monitoring shared service, like all shared services, is implemented as a virtual application pattern. The virtual application pattern for the base monitoring shared service is:

System Monitoring

That pattern must be loaded on the system before the shared service instance can be deployed in a cloud group.

To perform this task, you will need all of these permissions:

Allow delegation when full permission is selected.

Workload resources administration role with permission to Manage workload resources (Full permission).

Cloud group administration role with permission to View all cloud groups (Read-only).

Hardware group administration with permission to View all hardware resources (Read-only).

Security Administration role with permission to View users and groups (Read-only).

4.4.1.2 Results The system monitoring shared service is deployed and running. It hosts its own Tivoli Monitoring hub.

1. Next, to add custom monitoring for individual middleware products, deploy those shared services. (See 4.4.3 Deploy middleware monitoring services.) You can also add monitoring of your custom application. (See 4.5.15 Program application monitoring.)

4.4.1.3 Tasks Perform these steps:

1. Information Center: Deploying shared services

2. Information Center: Deploying an internal System Monitoring shared service

4.4.2 Deploy base service for external monitoring You can monitor the virtual machines (VMs) of the deployed virtual system and virtual application instances. This task configures the service for external monitoring, so the service connects to an existing Tivoli Monitoring hub (ITM Hub-TEMS) that is already hosted in the data center. This is useful if you want to have a central ITM hub monitor workloads from multiple PureApplication System racks. This monitoring is per cloud


http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/index.jsp?topic=%2Fcom.ibm.puresystems.appsys.1500.doc%2Fiwd%2Fapt_deploy_sharedservices.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/index.jsp?topic=%2Fcom.ibm.puresystems.appsys.1500.doc%2FITM_shared_service%2Ffac_deploy_monitoring_service.html


group, so you might choose to monitor one externally (such as production) and another internally (such as test).

If you prefer to host a Tivoli Monitoring hub hosted within PureApplication System, skip this task and perform the one for internal monitoring: 4.4.1 Deploy base service for internal monitoring. Don’t perform both tasks; the service cannot be deployed in the same cloud group twice.

4.4.2.1 Preconditions The base monitoring shared service, like all shared services, is implemented as a virtual application pattern. The virtual application pattern for the base monitoring shared service is:

System Monitoring


The data center must already host an existing Tivoli Monitoring hub (ITM Hub-TEMS) that includes Tivoli Enterprise Portal Server (TEPS) and Tivoli Data Warehouse. You will need the hostnames, ports, and user credentials to connect to TEMS, TEPS, and Data Warehouse.

You will need the packaged JDBC JAR files (a .zip, .tgz, or .tar.gz file) for Data Warehouse.





Hardware group administration with permission to View all hardware resources (Read-only).

Security Administration role with permission to View users/groups (Read-only).

4.4.2.2 Results The system monitoring shared service is deployed and running. It connects to an existing Tivoli Monitoring hub (Hub-TEMS) in the data center. The service hosts a Remote TEMS server that connects to the central Hub-TEMS.

1. Next, to add custom monitoring for individual middleware products, deploy those shared services. (See 4.4.3 Deploy middleware monitoring services.) You can also add monitoring of your custom application. (See 4.5.15 Program application monitoring.)





2. Information Center: Deploying an external System Monitoring shared service.

4.4.3 Deploy middleware monitoring services You can extend the System Monitoring shared service to collect performance and availability data about middleware servers running in a cloud group’s workloads. The following shared services are included pre-entitled with the system:

System Monitoring for HTTP Server

System Monitoring for WebSphere Application Server

System Monitoring for WebSphere MQ

System Monitoring for WebSphere Message Broker

Additional monitoring shared services, which require additional license, are also available.

4.4.3.1 Preconditions Each middleware monitoring shared service, like all shared services, is implemented as a virtual application pattern. The virtual application patterns for the middleware monitoring shared services are:

System Monitoring for HTTP Servers




And so on for other middleware products

Those patterns must be loaded on the system before the shared service instance can be deployed in a cloud group.

The base monitoring shared service, System Monitoring, must already be deployed. (See 4.4.1 Deploy base service for internal monitoring and 4.4.2 Deploy base service for external monitoring.)


Workload resources administration role with permission to Manage workload resources (Full permission)

Cloud group administration role with permission to View all cloud groups (Read-only)



http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/index.jsp?topic=%2Fcom.ibm.puresystems.appsys.1500.doc%2FITM_shared_service%2Ffac_deploy_ext_monitor_service.html


4.4.3.2 Results The middleware monitoring shared services are deployed and running. The monitoring hub can now process agent data specific to the particular middleware product.

1. Next, you can add monitoring of your custom application. (See 4.5.15 Program application monitoring.)



2. Information Center: Deploying the System Monitoring for WebSphere Application server service

3. Information Center: Deploying the System Monitoring for HTTP Servers service

4. Information Center: Deploying the System Monitoring for WebSphere MQ service

5. Information Center: Deploying the System Monitoring for WebSphere Message Broker service

4.4.4 Deploy database monitoring service The DB2 database patterns in PureApplication System include built-in monitoring of the database servers running in the virtual machines (VMs) of the deployed virtual system and virtual application instances. To use it, you need to deploy the database monitoring shared service.

4.4.4.1 Preconditions The database monitoring shared service, like all shared services, is implemented as a virtual application pattern. The virtual application pattern for the database monitoring shared service is:

Database Performance Monitoring






Security administration role with permission to View users/groups (Read-only).



http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/ITM_shared_service/fac_deploy_monitoring_service_WAS.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/ITM_shared_service/fac_deploy_monitoring_service_WAS.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/ITM_shared_service/fac_deploy_monitoring_service_HTTP.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/ITM_shared_service/fac_deploy_monitoring_service_MQ.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/ITM_shared_service/fac_deploy_monitoring_service_MQ.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/ITM_shared_service/fac_deploy_monitoring_service_MB.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/ITM_shared_service/fac_deploy_monitoring_service_MB.html


4.4.4.2 Results The database monitoring shared service is deployed and running. DB2 databases can now be monitored.


1. Information Center: Deploying Shared Services

2. Information Center: Deploying the Database Performance Monitoring shared service

4.4.5 Deploy caching service The caching service enables virtual application instances to cache data to improve the performance of repeatedly reading the data, and so that the data can be shared amongst servers in different workloads. The caching service also provides auto-scale capabilities so that new servers can be added to a pattern instance without retransmitting data. The caching service is based on IBM WebSphere eXtreme Scale. The service provides highly efficient caching and is self-managed and highly available. To use the caching service, you need to deploy the caching shared service.

4.4.5.1 Preconditions The caching shared service, like all shared services, is implemented as a virtual application pattern. The virtual application pattern for the caching shared service is:

Caching Service





4.4.5.2 Results The caching shared service is deployed and running. Virtual application instances can now use it to cache and share data.



2. Information Center: Deploying the Caching shared service



http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/index.jsp?topic=%2Fcom.ibm.puresystems.appsys.1500.doc%2Fiwd%2Fvit_deploydpmss.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/index.jsp?topic=%2Fcom.ibm.puresystems.appsys.1500.doc%2Fiwd%2Fvit_deploydpmss.html


http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/iwd/apt_caching_deploy.html


4.4.6 Deploy elasticity service The elasticity service enables scaling and routing policies to load balance client requests across a dynamic cluster of servers in a virtual application instance. It acts as a proxy with known IP addresses so that the internal IP addresses of the dynamic cluster members don’t need to be externally visible. Requests are routed to an application instance based on the defined virtual host and context root of this application. A single instance of the service is shared by all virtual application instances in the cloud group.

4.4.6.1 Preconditions The elastic load balancing (ELB) proxy shared service, like all shared services, is implemented as a virtual application pattern. The virtual application pattern for the ELB proxy shared service is:

ELB Proxy Service





4.4.6.2 Results The ELB proxy shared service is deployed and running. Virtual application instances can now use it to support elasticity.



2. Information Center: Deploying the Elastic load balancing proxy shared service

4.4.7 Deploy Red Hat update service The Red Hat update service enables you to run Yellowdog Updater, Modified (YUM) commands to update the Red Hat Enterprise Linux (RHEL) OS running in each of the virtual machines (VMs) in your virtual application and virtual system instances in a cloud group. The service receives updates and fixes directly from Red Hat as they become available. This service is based on the Red Hat Update Infrastructure (RHUI) model to provide a YUM repository containing Red Hat Package Manager (RPM) updates and fixes directly from Red Hat.

The service hosts three servers (each in its own VM):

1. Two content distribution servers (CDS). Each CDS instance hosts a YUM repository.



http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/index.jsp?topic=%2Fcom.ibm.puresystems.appsys.1500.doc%2Fworkloadconsole%2Ft_addssinstmonitorelb.html


2. One Red Hat Update Appliance (RHUA) server. This service connects to Red Hat’s web site to download packages.

The Red Hat update service is only available on PureApplication System W1500, not on W1700. It can be used to update VMs running RHEL but not those running Microsoft Windows.

4.4.7.1 Preconditions The Red Hat OS Update shared service, like all shared services, is implemented as a virtual application pattern. The virtual application pattern for the Red Hat OS Update shared service is:

RedHat OS Update Shared Service





A few details specific to this service to keep in mind:

The Red Hat Update Appliance (RHUA) server needs an Internet connection.

The service needs a Red Hat content certificate.

Internet connection

How does the service get its RPM packages? It requires a connection to Red Hat’s public RHN service. The service uses Security First’s SPx Connect to connect to RHN securely. Therefore, the service needs Internet access to connect to these two domains:

access.cdn.redhat.com securityfirstcorp.com

It connects through ports 443 and 80. You can configure this Internet access in one of two ways:

Through an Internet gateway/proxy hosted in your data center and accessible by the service.

By deploying the service with IP addresses that have Internet access. (Each service instance needs three IPs. These can be put in a separate IP group that is used to deploy this service.)

In general, if you already have a YUM repository or Satellite service in your data center, it already has a way to connect to RHN. Configure the service to access RHN the same way.

Red Hat content certificate



To connect to RHN, the service’s plug-in (rhusservice) needs to be configured with a Red Hat Content Certificate. Each system gets its own certificate, based on its serial number, which can be reused for all of the cloud groups on that system. Request a certificate from IBM Support.

The service plug-in also documents its attributes, which you’ll need to set when deploying the shared service. Set the storage to the space you want for RPM packages (the default is 50 GB), and set the four HTTP Proxy parameters if the service needs to use one to connect to the Internet.

4.4.7.2 Results The RedHat OS Update shared service is deployed and running. Virtual system and virtual application instances can now use it to run YUM commands.



2. Information Center: Red Hat OS Update Shared Service

4.4.8 Deploy endpoint management service The endpoint management service enables you to use an external IBM Endpoint Manager server (v9.0 and later) to manage the operating system (OS) in the virtual machines (VMs) in your virtual application and virtual system instances in a cloud group. Endpoint Manager can be used in conjunction with the Red Hat update service to run YUM commands on the VMs.

4.4.8.1 Preconditions The IBM Endpoint Manager shared service, like all shared services, is implemented as a virtual application pattern. The virtual application pattern for the IBM Endpoint Manager shared service is:

IBM Endpoint Manager Service





4.4.8.2 Results The IBM Endpoint Manager shared service is deployed and running. The existing Endpoint Manager server can now run commands on the virtual system and virtual application instances’ VMs.



http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/index.jsp?topic=%2Fcom.ibm.puresystems.appsys.1500.doc%2Fiwd%2Fapc_redhat_service.html




2. Information Center: Deploying the IBM Endpoint Manager Shared Service

4.4.9 Update existing shared service instance When the vendor makes available a new version of a shared service, not only do you need to download it and import it into your workload catalog, you also need to redeploy the service to each cloud group that is running the service. Some service types require that you delete the running service instance and deploy the new service version, but this causes a disruption to the running workloads that are using the service. When possible, upgrade the service instance in place to avoid service disruptions.

4.4.9.1 Preconditions You must have imported the updated shared service pattern type or plug-in the catalog. (See 4.8.6 Import and install virtual application components.)

To perform this task, you will need the Workload resources administration role with permission to Manage workload resources (Full permission).

4.4.9.2 Result The shared service instance is now upgraded with the updated pattern types and plug-ins.


1. Information Center: Updating shared service instances

You may also need to update the monitoring agents; see:

1. Information Center: Updating the external PureApplication System Agent

2. Information Center: Updating a monitoring agent

4.5 Application operations – Middleware admin These are the tasks application operations personnel will perform to deploy pattern instances and maintain them.

4.5.1 Create environment profile An environment profile associates user groups with cloud groups so that the users in those user groups can deploy patterns to those cloud groups. An environment profile grants access to user groups to specify who can use the profile to deploy patterns. A profile can grant access to multiple user groups and a user group can be granted access to multiple profiles. An environment profile also specifies what cloud groups it can deploy to. Multiple environment profiles can deploy to the same cloud group, and a profile can deploy to multiple cloud groups.



http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/index.jsp?topic=%2Fcom.ibm.puresystems.appsys.1500.doc%2Fiwd%2Fapc_tem_relay.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/workloadconsole/t_upgradess.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/agent_IPAS/t_upgrade_external_ipas_agent.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/ITM_portal/adminuse/mngsys_deployupdate_tep.html


For more information about environment profiles, see:


4.5.1.1 Preconditions You will need to make sure that the following conditions are met:

A Cloud Group has been created.

An IP Group has been created and is associated with a cloud group.

In addition you will need the following security role.

Create Environment Profile.

4.5.1.2 Result Once the environment profile has been created, you can then use it as a target for deploying your patterns.

4.5.1.3 Steps Tasks involved in working with an environment profile include:

1. Create Environment Profile. Assign one or more cloud groups and select the IP Group that will be used for this environment profile. In addition you can also specify if the target deployment gets its IP from the IP Group or by having the pattern deployer specify it at deployment time. This is also the place where you can change the default prefix name of the virtual machines you will be instantiating as part of your pattern deployment.

2. Modify Environment Profile: You might want to change the cloud group, IP Groups, change its quality of service or readjust the IP addresses assigned to the cloud. Tasks involved in modifying the environment profile:

a. Add one or more new cloud groups.

b. Remove one or more existing cloud groups.

c. Change how IPs are assigned to deployment.

d. Change access control (see 4.8.19 Configure authorization).

e. Set environment limits so that one group does not consume all resources assigned, when the same cloud group is shared among multiple environment profiles. The limits that could be set can be on any of the following resources:

Virtual CPU

Virtual Memory

Storage

License usage for non-entitled products.






Information Center: Creating Environment Profiles

Information Center: Modifying Environment Profiles

4.5.2 Deploy a virtual application or DBaaS pattern Deploying a virtual application or the Database as a Service (DBaaS) pattern is simple and straightforward. The deployment of a virtual application pattern can take anywhere between 15 minutes to about an hour, based on the complexity of the pattern.

4.5.2.1 Preconditions To deploy a virtual system pattern, you must have the following:

Access to the virtual application pattern you are trying to deploy.

Access to the environment profile target where you pattern will be deployed.

By default, all users have deploy permission and hence no other permission is needed.

4.5.2.2 Results The pattern is deployed and you can view the details from the instance menu, and manage the life cycle of the deployed instances. You can access the details of the deployed pattern instances thru the console as shown below:

For all instances, go to Workload Console > Instances > All Instances.

For virtual application instances, go to Workload Console > Instances > Virtual Applications Instances.

4.5.2.3 Steps Perform these tasks to deploy a virtual application pattern:

1. Information Center: Deploying virtual application patterns

Perform these tasks to deploy a DBaaS pattern:

1. Information Center: Deploying databases from database patterns

4.5.3 Deploy a virtual system pattern Deploying a virtual system pattern is simple and straightforward. The deployment of a virtual system pattern can take anywhere between 15 minutes to a couple of hours, based on the complexity and number of the parts in the patterns.

4.5.3.1 Preconditions To deploy a virtual system pattern, you must have the following:

Access to the virtual system pattern you are trying to deploy.

Access to the environment profile target where you pattern will be deployed.

By default, all users have deploy permission and hence no other permission is needed.


http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/index.jsp?topic=%2Fcom.ibm.puresystems.appsys.1500.doc%2Fiwd%2Fept_creaprof.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/index.jsp?topic=%2Fcom.ibm.puresystems.appsys.1500.doc%2Fiwd%2Fept_editprof.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/index.jsp?topic=%2Fcom.ibm.puresystems.appsys.1500.doc%2Fiwd%2Fapt_deployapp.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/index.jsp?topic=%2Fcom.ibm.puresystems.appsys.1500.doc%2Fvirt_app_patterns%2Fdb%2Fdbt_pattern-db.html


4.5.3.2 Results The pattern is deployed and you can view the details from the instance menu, and manage the life cycle of the deployed instances. You can access the details of the deployed pattern instances thru the workload console as shown below:

For all instances, go to Workload Console > Instances > All Instances.

For virtual system instances, go to Workload Console > Instances > Virtual Applications Instances.

4.5.3.3 Steps Perform these tasks to deploy a virtual application pattern:

1. Information Center: Deploying virtual system patterns

4.5.4 Apply fix to virtual system instance A virtual system instance can require maintenance to the product code using a feature pack or emergency fix, as well as to the operating system. There could also be cases where you might have to run an updated script package to deploy an application or update an application already running in the virtual system instance.

4.5.4.1 Preconditions To apply a fix to a pattern instance:

The pattern instance must already exist.

The fix must already exist.

To perform this task, you will need these permissions:

Create new catalog content sub-role of Workload management.

Write permission on the pattern instance.

The Workload resources administration role with permission to Manage workload resources (Full permission).

4.5.4.2 Results The running virtual system instance is update to the latest level supported by the middleware or operating system or the application has been updated with an update.

4.5.4.3 Steps When executing a newer updated script package, if the script package is set to “when I initiate it,” the deployer will initiate the running of the script from the deployment console. This is a good way to debug the script and when the scripts are fully debugged, you can set it to run at initial pattern deployment stage.

1. Go to the Script Packages page (Workload Console > Catalog > Script Packages) and upload the new package.


http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/index.jsp?topic=%2Fcom.ibm.puresystems.appsys.1500.doc%2Fiwd%2Fmpt_deplpatt.html


2. Go to the Virtual System Instances page (Workload Console > Instances > Virtual System Instances) and identify the instance on which you need to run the updated script.

3. Identify the virtual machine where the script needs to run from the virtual system instance’s details.

4. Run the script from the deployment console by clicking on “Execute Now.”

If you are applying emergency fixes or service level fixes (example: from WebSphere 8.5.0.0 to 8.5.0.1), use the following steps:

1. Download the fixpack or emergency fix from PureSystems Center or from IBM Support Portal for the specific middleware product.

2. Make sure the fix or the new service level virtual image is imported in the catalog.

3. Place the deployed instance in “service” mode; you will see a list of fixes and/or service level applicable to one or more images in the instance.

4. Select the applicable fixes and/or service level to be applied on the deployed instance.

5. The system will create a snapshot of the VMs before applying the fixes – you can roll back if you do not like the results of the update.


Information Center: Applying fixes to virtual system instances

4.5.5 Apply fix to WebSphere virtual application or DBaaS instance Just like in the case of applying fixes to a virtual system instance, there will be cases where running virtual application deployments would also need to be upgraded to the latest level. This applies only to middleware that provides this functionality; for example, WebSphere Application Server or DB2 for DBaaS VMs.

4.5.5.1 Preconditions To apply a fix to a pattern instance:

The pattern instance must already exist.

The fix must already exist.

To perform this task, you will need these permissions:

Create new catalog content sub-role of Workload management.



4.5.5.2 Results Pattern instance is upgraded with the middleware fix.


http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/index.jsp?topic=%2Fcom.ibm.puresystems.appsys.1500.doc%2Fiwd%2Fsit_service_vs.html


4.5.5.3 Steps To apply an emergency fix or fixpack that has been uploaded to the catalog, perform these steps:

1. Information Center: Applying a WebSphere Application Server fix to an existing deployment.

2. Information Center: Updating virtual application pattern types by using the workload console

4.5.6 Apply updates to virtual application instance There are several situations in which you might want to apply updates to a pattern type to a deployed virtual application. For example, if you updated a pattern type or customized a plug-in that is associated with a pattern type, you might want to apply the changes to a virtual application based on the pattern type.

4.5.6.1 Preconditions You must have imported the updated pattern type or plug-in the catalog. You must be the owner or have access permission on the instance.

To perform this task, you will need either:

The Create new catalog content sub role of Workload management.


4.5.6.2 Result Virtual application instance is updated with the updated pattern types and/or the plug-ins.

4.5.6.3 Steps For update the pattern types on a virtual application instance, perform these steps:

1. Information Center: Updating deployed pattern types

2. Information Center: Applying fixes to virtual application instances

4.5.7 Apply fix to DB2 HADR instance Since DB2 HADR involves multiple VMs, the fix needs to be synchronized in a specific order such that there is availability of DB2 for the clients. The DB2 HADR topology discussed here is where you have the DB2 primary and secondary parts in different virtual system instances, maybe on the same or different rack.

4.5.7.1 Preconditions To apply a fix to the pattern instance:

The primary and the secondary DB2 HADR patterns have been deployed.

The emergency fix for DB2 is imported in the catalog and associated with the DB2 virtual image


http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/index.jsp?topic=%2Fcom.ibm.puresystems.appsys.1500.doc%2Fvirt_app_patterns%2Fap%2Fapt_wascacheifix_existing.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/index.jsp?topic=%2Fcom.ibm.puresystems.appsys.1500.doc%2Fvirt_app_patterns%2Fap%2Fapt_wascacheifix_existing.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/iwd/apt_solutioninstaller.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/iwd/apt_solutioninstaller.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/index.jsp?topic=%2Fcom.ibm.puresystems.appsys.1500.doc%2Fiwd%2Fapgst_upgradepattern.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/index.jsp?topic=%2Fcom.ibm.puresystems.appsys.1500.doc%2Fiwd%2Fapt_maintfix_ov.html


To perform this task, you will need either of these permissions:



4.5.7.2 Results The DB2 HADR instances have the fix.

4.5.7.3 Steps Perform these actions in the following sequence:

1. Make the secondary DB2 HADR instance the primary one, and make the old primary one the secondary one.

2. Stop the old primary one and apply the fix. For DB2 VSys VM, you will need to log into the VM and apply the fix.

3. Start the fixed VM (old primary one).

4. Swap the primary and secondary so that it is back to the way it was.

5. Stop the secondary instance and apply the fix by logging into the VM and applying the fix.

6. Start the secondary one.

4.5.8 View virtual machine status Once a virtual machine has been created as part of a pattern deployment, you may need to monitor the status of a running VM. The virtual machine details page shows information such as status, CPU utilization memory utilization, any events, and so on. Based on the status shown on this page, you have the option of performing operations such as increasing the vCPUs, increasing memory, or adding additional storage to a VM.

4.5.8.1 Preconditions A virtual machine must have been already deployed and running.


4.5.8.2 Results You should be able to view the status of a virtual machine and monitor data such as CPU utilization, memory utilization, any critical events, and so on.

4.5.8.3 Steps There are two ways to view the status of a virtual machine:

1. Using the workload console

a. Go to Workload Console > Instances > Virtual System Instances.



b. Select the instance you want.

c. Expand the details of the VM you want to monitor.

d. Click on “Manage” and select “More.”

e. You should now be in the Virtual Machine details screen for that particular VM.

2. Using the system console

a. Go to System Console > Cloud > Virtual Machines.

b. Select the virtual machine you are interested in from the list. You can also look for the virtual machine by using the filter.

c. You should now be in the Virtual Machine details screen for that particular VM.


Information Center: Viewing and modifying virtual machine settings

4.5.9 Administer virtual machines Once a virtual machine has been deployed as part of a pattern deployment, you can modify the virtual machine characteristics by doing the following task:

Start a virtual machine

Stop a virtual machine

View and modify virtual machine instances

4.5.9.1 Preconditions A pattern has been deployed successfully.

4.5.9.2 Results One of the following operations would have taken place:

Start a virtual machine.

Stop a virtual machine.

Configure a virtual machine.

4.5.9.3 Steps In order to modify the characteristics of a virtual machine:

1. Go to System Console > Cloud > Virtual Machines. You can also get to this screen by going to Workload Console > Instances > Virtual Machines.

2. Select the VM and click on Manage.

3. To update the CPU Count or Virtual Memory, click on Configure.


http://pic.dhe.ibm.com/infocenter/psappsys/v1r0m0/index.jsp?topic=%2Fcom.ibm.ipas.doc%2Fsystemconsole%2Ft_mngvirtmachine.html


4. You can add additional storage to the virtual machine by selecting the drop down for “Storage Volumes.”


Information Center: Administering virtual machines

4.5.10 Add storage to a virtual machine The storage within PureApplication System is managed by the system. The VMs are allocated storage in the storage area network (SAN). If a VM requires additional storage, an administrator can create a new storage volume and associate it with the VM. Configure storage volumes on the Storage Volumes page. (Go to System Console > Cloud > Storage Volumes.)

Rather than add storage to an existing pattern instance, it is easier and better to add additional disks to the pattern’s parts as add-ons in the pattern editor. Then, when you deploy a new instance, it’ll include the additional disk and the storage volume’s lifetime will be bound to that of the pattern instance. Creating a storage volume manually should only be done to add storage to an existing pattern instance which cannot be redeployed easily.


4.5.10.2 Result You’ve created a new storage volume, added to a VM, and configured a new disk on the VM to use that storage.

4.5.10.3 Steps Application operations performs these steps:

1. Information Center: Administering storage volumes

2. Select the virtual machine and add the storage volume, as described in Information Center: Viewing and modifying virtual machine settings

3. Configure the new disk on the virtual machine, as described in Information Center: Increasing storage for a DB2 virtual application pattern after it is deployed

4. IBM developerWorks: Best practices using infrastructure as a service in IBM PureApplication System

4.5.11 Log into a virtual machine Each virtual system instance consists of a set of virtual machines that represent a physical node in an application server environment. You can access and view details about the individual virtual machines from your virtual system instance screen.


http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/systemconsole/t_mngvirtmachine.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/systemconsole/t_mngstorage.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/systemconsole/t_editvm.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/iwd/mpt_syspat_increase_storage_after.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/iwd/mpt_syspat_increase_storage_after.html

http://www.ibm.com/developerworks/cloud/library/cl-aim1301-bestpractices-iaas-pureapp/

http://www.ibm.com/developerworks/cloud/library/cl-aim1301-bestpractices-iaas-pureapp/


4.5.11.1 Preconditions A virtual system pattern should have been deployed.




4.5.11.2 Result You should have been able to login into the virtual machine using VNC or SSH.


1. Go to Workload Console > Instances > Virtual Systems.

2. Select the virtual system instance associated with the virtual machine that you want to access.

3. Expand Virtual machines to view the list of virtual machines in the virtual system instance.

4. Expand the details for your selected virtual machine by clicking the Expand icon next to the virtual machine name. The number of virtual machines that exist for the virtual system instance is dependent on the pattern that was deployed to create it.

5. To access the virtual machine, use one of the following steps:

o Click Login under the SSH column to open a new browser window and access the virtual machine by using SSH.

6. You can also use utilities like Putty and other SSH clients by connecting to the virtual machine by hostname or IP address of the virtual machine.


Information Center: Accessing Virtual Machines

4.5.12 View workload status You can view information about the virtual machines that are associated with a virtual system instance in the console.

4.5.12.1 Preconditions A pattern representing your workload has been deployed successfully


Read permission on the pattern instance.


http://pic.dhe.ibm.com/infocenter/psappsys/v1r0m0/index.jsp?topic=%2Fcom.ibm.ipas.doc%2Fsystemconsole%2Ft_mngvirtmachine.html


The Workload resources administration role with permission to View all workload resources (Read-only).

4.5.12.2 Result You have viewed the information about the virtual machines that have been deployed as part of your pattern.


1. Go to Workload Console > Instances >Virtual Systems.

2. Select the instance you want.

3. View the instance details on the right side.

4. If your deployment was successful, the current status should show as “virtual system has been deployed.”

5. In addition, you can see details such as: which pattern was this instance created from, when it was created, which environment profile it is deployed into, and details of the individual virtual machines that make up the instance.

4.5.13 Enable workload trace Occasionally you will notice some of your deployments might fail. Sometimes the reason is not very obvious as observed from the pattern instances view. In such a case, enabling workload trace settings helps with troubleshooting and resolving problems with the system. When a PMR is opened with IBM, the support person might also ask for additional traces to be enabled in order to get information about a failure.

4.5.13.1 Preconditions To perform this task, you will need the Workload resources administration role with permission to Manage workload resources (Full permission).

4.5.13.2 Result You now have a trace log you can send to IBM Support for analysis.


1. Go to Workload Console > System > Troubleshooting.

2. Modify existing trace levels or add a new trace setting.


Information Center: Managing trace settings


http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/iwd/t_trace.html


4.5.14 View Storehouse browser The Storehouse in PureApplication System is a repository that contains the virtual system and virtual application workload artifacts. When you import the pattern type into the PureApplication System, the binary tar archive file will be uploaded to the Storehouse repository. The Storehouse repository stores product binaries to be accessed by virtual application pattern instances during instance activation.

When application operations import a new pattern type and try to deploy a pattern that uses that pattern type but get errors upon deployment, they can follow this task to determine whether the pattern type was imported into the Storehouse successfully.

4.5.14.1 Preconditions Content enablement has performed 4.8.6 Import and install virtual application components to import a new pattern type.

Application operations has performed 4.5.2 Deploy a virtual application or DBaaS pattern and the pattern deployment failed. The failure looks like the pattern type is missing or corrupt.

To perform this task, you will need the Workload resources administration role with permission to Manage workload resources (Full permission).

4.5.14.2 Results You can check if the pattern type that you imported has been imported successfully by looking in the storehouse browser.


1. Go to Workload Console > System > Storehouse Browser.

2. View the artifacts that are in the Storehouse browser to make sure that your pattern type has been successfully imported.

3. Make sure that the pattern type you imported has the corresponding patterntype.json file also imported.

4.5.15 Program application monitoring Within the system monitoring shared service, you can look for predefined situations that comes with middleware monitoring, such as WebSphere Application Server. In addition, you can define custom situations. Situations can trigger events and potentially look for issues proactively before they cause an outage.

You will need to have the base knowledge on how situations are defined, created in IBM Tivoli Monitoring.

4.5.15.1 Preconditions The System Monitoring shared service has to be deployed in the cloud group where the workload is running.



The corresponding Monitoring shared service for the middleware also needs to be deployed in the cloud group where the workload is running. At present, the following shared services are available:





To perform this task, you will need the Workload resources administration role with permission to View all workload resources (Read-only).

4.5.15.2 Results You are able to view situations and proactively act on issues.

4.5.15.3 Steps The actual steps are outside the scope of this document, and need to be performed by someone knowledgeable in IBM Tivoli Monitoring. The following links will help:

IBM Redbooks

o Deployment Guide Series: IBM Tivoli Monitoring V6.2

o Certification Study Guide Series: IBM Tivoli Monitoring V6.2

Information Center

o IBM Tivoli Monitoring Information Center

4.5.16 Monitor middleware You can monitor workloads and instances (for example, virtual system instances and virtual application instances) with PureApplication System. You can access the monitoring screens through the workload console.

4.5.16.1 Preconditions The System Monitoring shared service has to be deployed in the cloud group where the workload is running.

The corresponding Monitoring Shared Service for the middleware also needs to be deployed in the cloud group where the workload is running. At present, the following shared services are available:






http://www.redbooks.ibm.com/abstracts/sg247456.html?Open



4.5.16.2 Results You should be able to view deep monitoring data and look at the middleware performance issues. Based on the data, you can manage your capacity and adjust the application accordingly.

4.5.16.3 Steps To monitor a virtual system instance:

1. Go to Workload Console > Instances > Shared Services.

2. For middleware-level monitoring:

a. Select the System Monitoring instance in your cloud group.

b. Select the “Endpoint” link next to the “Hub-TEMS” under “Middleware perspective” in the details.

c. This should launch the ITM Console via a Java start session.

3. For database monitoring:

a. Select the Database Performance Monitoring instance in your cloud group.

b. Select the “Endpoint” link next to “OPM” under “Middleware perspective” in the details.

c. This should launch the Optim database performance monitoring screen.

To monitor a virtual application instance:

1. Go to Workload Console > Instances > Virtual Applications.

2. Select your particular instance.

3. For Database monitoring, select the “Monitor” link next to the node representing “Database-db2.<some unique number>.” That should launch the Optim DB Monitoring console.

4. For WebSphere level monitoring, select the “Monitor” link next to the node representing “Enterprise_Application_was_<some unique number>.” This should launch the ITM monitoring console.


Information Center: Monitoring Workloads Monitoring the middleware

4.5.17 Delete workload instance when not needed Don’t leave a pattern instance deployed after it is no longer being used. To replace it with a new version, deploy an instance of the newer pattern, migrate the application data and user load to the new instance, and delete the old instance.

Whenever an instance is no longer being used, consider stopping, storing, or deleting it:


http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/index.jsp?topic=%2Fcom.ibm.puresystems.appsys.1500.doc%2Fiwd%2Fvit_monitoring_middleware.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r0m0/topic/com.ibm.ipas.doc/iwd/vit_monitoring_middleware.html


Stopping an instance prevents it from utilizing any system resources but maintains its reservations so that it will have adequate resource reservations to start again.

Storing an instances stops it and releases some of its resource reservations — CPU, memory, and product licenses.

Deleting an instance stops and stores it and releases the rest of its resource reservations — IP addresses and storage volumes.

Releasing resource reservations makes those resources available for deploying other pattern instances.

4.5.17.1 Preconditions The unneeded pattern instance must already exist.


All permission on the pattern instance.


4.5.17.2 Results The deployed instance will be deleted. Any scripts (for virtual system instances) configured to run at delete time will be executed. All VMs will be stopped and deleted. The resources reservations (CPU, memory, storage, IP addresses, and product licenses) will be released back to the cloud group.


1. Information Center: Deleting virtual system instances

2. Information Center: Deleting a virtual application instance

3. Information Center: Deleting shared service instances

Go to the workload console instance panel and select the instance to be deleted. Click on the “Delete” link. If you manually created any storage volumes (see 4.5.10 Add storage to a virtual machine), be sure to manually delete those storage volumes to release their disk space.

4.5.18 Script workload management tasks Anything that can be managed in IBM PureApplication System is a resource object on the command line interface. The PureApplication System command-line interface (CLI) manages different types of resources, such as patterns, virtual images, and virtual system instances.

4.5.18.1 Preconditions The user used to run the script to perform a task must have the necessary permissions to perform the equivalent task in the console. Generally this means:


http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/iwd/sit_delete_vs.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/workloadconsole/t_delvappinst.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/workloadconsole/t_deletess.html


Read permission on a component to see its contents or to export the component.

Write permission on a component to change its state.

All permission on a component to delete it.

In addition, to create most components requires a Workload management sub-role. Of course, Workload resources administration role with permission to View all workload resources (Read-only) or permission to Manage workload resources (Full permission) gives you access to all components.

To deploy a pattern, the user needs read access to the pattern and read access to the environment profile used to deploy the pattern.

4.5.18.2 Results A well-written set of scripts will give operations an easier and more automated way of managing the workloads.


1. Information Center: Downloading the command-line interface

2. Information Center: Using the command line interface for the workload console

A good starter set of scripts is provided as part of the CLI download zip in the samples directory.

4.5.19 Perform application data restore PureApplication System does not backup the entire VM to external storage. Workload backup and restore is handled through exporting the state within a pattern instance’s VMs, and importing it when needed to the same pattern instance or one like it. For the Database as a Service (DBaaS) pattern, if you used the built-in Tivoli Storage Manager client to back up the database, you can use that to restore the data. For a virtual system pattern DB2, you can configure the DB2 to use any supported backup solution, similar to DB2 hosted on traditional hardware.

4.5.19.1 Preconditions Identify the pattern instance whose state you need to repopulate.

You need an existing backup of the application data. This means you should have already identified and have a documented strategy for backing up application related data that resides on a virtual machine that could be restored at a later stage. (See 4.8.13 Install and configure application backup.)

4.5.19.2 Results The state of the pattern instance has been restored to what it (or one like it) contained when it was backed up.


http://pic.dhe.ibm.com/infocenter/psappsys/v1r0m0/topic/com.ibm.ipas.doc/iwd/cct_dowloclt.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r0m0/index.jsp?topic=%2Fcom.ibm.ipas.doc%2Fiwd%2Fccr_availres.html


4.5.19.3 Steps However, since the deployment of patterns is quite fast and easy, it is easy to recreate critical deployments, if you have the patterns saved and then restored.

For backup: Export patterns that are critical

For restore: Import patterns that need to be restored

For virtual application DBaaS VMs, you can configure Tivoli Storage Manager to back up the database. New DBaaS VMs can be deployed with the data from Tivoli Storage Manager.

For virtual application deployed DB2 databases, or databases that are deployed as part of a virtual system pattern, you can use the normal backup and restore supported by the DB2.

You also can install an agent like BMC, which takes a backup of the entire contents of the virtual machine.

4.5.20 Implement pattern deployment lease policies With the increase in interest in cloud computing, we have seen an enormous increase in the number of deployments onto our cloud computing environments. However, with that increase in interest comes a chance that some of these deployments will over time become forgotten and abandoned. This situation is typical of any large cloud environment, no matter what technology is used to provision the cloud. Therefore, you will need a strategy around how to maintain or remove environments that have been around for a long time.

4.5.20.1 Preconditions You have already created the virtual system patterns you intend to deploy.

4.5.20.2 Results The virtual system pattern instance will be removed, or a workflow to begin the process of removal will be started.

4.5.20.3 Steps As described above, deployments should not last forever. Currently, there are two different ways you can manage the length of time that a deployment lasts.

First, the Information Center describes a deployment option for virtual system patterns: when you schedule the deployment of a virtual system you can specify a “Run Until” date, at which time the pattern instance will be stopped. The downside of this approach is that deployers cannot be forced to select this option when deploying; the default is “Run Indefinitely.”

Information Center: Deploying virtual system patterns

Because of this limitation, a more proactive approach is needed. The following two articles provide strategies around how to work with these long lived environments that involve managing deployments with defined lease times.


http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/iwd/mpt_deplpatt.html


IBM developerWorks: Pattern deployment lease policies for IBM Workload Deployer and IBM PureApplication System

IBM developerWorks: Best practices for patterns adoption in IBM PureApplication System

4.5.21 Maintain RHEL on virtual machine Most virtual system patterns and virtual application patterns on the Intel PureApplication System are built out of images running the Red Hat Enterprise Linux (RHEL) operating system. Once a pattern instance has been created, applying service to one of those running RHEL virtual machines is done using the YUM (Yellowdog Update Manager) package installation software from Red Hat. Each individual Linux virtual machine in a pattern instance must be updated separately.

4.5.21.1 Preconditions You have deployed the Red Hat update shared service.

You know what updates you want to apply.

4.5.21.2 Results Yum will update the instance of the operating system on the VM in which it is run.

4.5.21.3 Steps 1. Login the VM and run yum.

SSH into the appropriate VM that you wish to update. Remember that in a pattern comprised of multiple VM images, you may need to update several or all images with a specific package, such as a package representing a security patch.

At the Linux command line, run yum update <package name/s> where <package name/s> is the list of packages you wish to update. This command will update the named packages to the latest available version. If you do not specify a package name, then yum will update all packages (which could take a long time).

2. Alternatively, for a virtual system instance, build the pattern that includes a script package to the pattern part that will enable you to run a yum command post deployment, passing the package name you would like install on the VM.

Execute the script package from the virtual system instance console for the specific VM.


Information Center: Red Hat OS Update Shared Service


http://www.ibm.com/developerworks/websphere/techjournal/1309_col_zhu/1309_col_zhu.html

http://www.ibm.com/developerworks/websphere/techjournal/1309_col_zhu/1309_col_zhu.html



http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/iwd/apc_redhat_service.html


4.5.22 Deploy DB2 HADR for database disaster recovery DB2 patterns include an HADR solution that includes a primary part and a standby part for HA and DR. These parts can be included in the same pattern or different patterns (within the same or different PureApplication System rack).

4.5.22.1 Preconditions You must have created the patterns that include the DB2 primary and standby part,

either part of the same pattern or in different patterns.

If you are deploying the DB2 parts across the rack, the patterns containing the standby part need to be imported in the second rack.

You need to have access to the pattern.

4.5.22.2 Results DB2 HADR will manage the data synchronization between the primary and standby DB2 instances participating in the HADR.

In your middleware using the HADR DB2, you will need to specify the standby DB2 host for the middleware to be aware of the standby DB2.

4.5.22.3 Steps If both the primary and the secondary DB2 parts are in the same pattern, you don’t need to do any configuration or ordering. The pattern is configured so that the DB2 primary and standby instances are configured for HADR. Note that the suggested pattern for production environment is where you have the primary and secondary DB2 parts in different patterns. The steps for that topology is:

1. Deploy the pattern that contains the standby DB2 part.

2. Note the IP address or hostname, DB2 service port and root credential of the standby DB2 VM.

3. Deploy the pattern that contains the primary part and configure it with the host name or IP address, DB2 service port and root credentials of the standby DB2 part. Once the primary DB2 part is deployed, it will setup the HADR with the standby part.


Blog: High transaction DB2 HADR system on IBM PureApplication

4.5.23 Deploy GPFS for disaster recovery There are three GPFS virtual system patterns that need to be deployed to create a GPFS environment for disaster recovery:

GPFS Basic Cluster Multi Rack Tie breaker pattern

GPFS Basic Cluster Multi Rack B pattern

GPFS Basic Cluster Multi Rack A pattern



4.5.23.1 Preconditions You must have access to the GPFS patterns.

4.5.23.2 Results Once the three patterns are deployed, you can add the GPFS client scripts to any pattern part. When deployed, the scripts on any part can access the shared file system provided by GPFS.

4.5.23.3 Steps From the workload console, virtual system pattern, deploy the following:

1. GPFS Basic Cluster Multi Rack Tie breaker pattern, providing the root password, the disk size (in GB). For the tie breaker pattern, you can accept the default disk size.

a. Ideally the tie breaker should reside in a separate environment outside PureApplication System to give you the best HADR resiliency. However, you may choose to deploy the pattern on one of the racks as a next best alternative solution.

2. GPFS Basic Cluster Multi Rack B pattern on rack B, providing the root password, the disk size (in GB). The disk size will be the starting disk size for your shared file system.

3. GPFS Basic Cluster Multi Rack A pattern on rack A, providing the root password and the disk size (in GB). The disk size should be the same as specified for rack B.

4.5.24 Enable GPFS on a virtual system instance You have added the GPFS client scripts to the pattern parts and deployed the pattern. At deployment time, the GPFS client is installed in the VM for that part. You will now need to have your VM client interact with the GPFS server or cluster so that it can participate in the GPFS shared file system.

When the instance is deployed, the GPFS is initialized in the client VM through the script that you had added when creating the pattern.

Note: You need to assure that there is a trust model between all the GPFS clients connecting to a GPFS server, since you can see all the filesets created by the GPFS client. If you need isolation, you will need to create separate GPFS server environments.

4.5.24.1 Preconditions GPFS server cluster patterns have been deployed and your deployed VM have network connectivity to the GPFS cluster.

Your pattern has been deployed.



Note the IP address or the host name of the GPFS server VM of the deployment of “GPFS Basic Cluster Multi Rack A.” This is the host that the GPFS clients will connect to.

4.5.24.2 Results Your deployed VM now has access to the GPFS file system and can start I/O operations on the shared file system.

4.5.24.3 Steps From the workload console, go to the Instances and open the virtual system instance. Click the instance that has your VM that has been enabled to participate in GPFS.

1. From the virtual system instance UI, expand the “Virtual machines” and expand the details of the client VM that need to participate in GPFS.

2. Find the “GPFS Add Client Node” and run it be clicking “Execute Now”. Specify the VM root is and password, and then specify the IP address or host name of the GPFS server (rack A), and GPFS server user id and password.

3. You can now create a fileset, if one has not already been created. You will need to decide which client VM in a multiple client environment will create a fileset that is used by all the clients.

a. Find the “GPFS Create FileSet” and run it by clicking “Execute Now.” Specify the VM root ID and password, and then specify the name of the fileset. GPFS will create a directory by that name. You can see that directory on your client under the /gpfs/gpfsdev/<fileSet-name>.

4. You can use the fileset or directories in the gpfs/gpfsdev/<fileSet-name>. A better option is to link the fileset to another local directory. This will enable the middleware in your client VM to look for shared file system via known directory.

a. Find the “GPFS Link FileSet” and run it be clicking “Execute Now.” Specify the VM root ID and password, and then specify the fileset name and the local link directory

4.5.25 Deploy application code into a virtual system instance

If you are following the best practice referred to in the use case 3.4.3 Deploy pattern, in which you separate the application topology (the pattern) from the application code, then you will need to separately deploy your code into a virtual system pattern instance. This can occur multiple times within the lifecycle of your application, as you will need to perform this task every time that your application code or configuration has changed in a development or test environment, or on a regular release cycle basis in a production environment.

4.5.25.1 Preconditions Your virtual system pattern has been deployed and an instance is available.



4.5.25.2 Results Your application code is now available within the pattern instance and a complete workload is ready to run.

4.5.25.3 Steps To understand the purpose of this task, consider the lifecycle of an application being worked on by a developer, Mary, inside a development environment. Within that particular pattern instance that represents her development environment, Mary might want to perform multiple deployments of different versions of the application as her development progresses. This is where a tool like IBM UrbanCode uDeploy can help to automate this process. In its simplest form, you add a script package that can deploy a uDeploy agent to each virtual machine in your pattern, including in the virtual machine representing a middleware control point like a WebSphere Application Server deployment manager. Once you associate the agents to the server, then the uDeploy server is then able to contact those agents and is intelligent enough to be able to deploy a particular combination of application code and configuration to that pattern instance either upon a manual trigger, or through an automated trigger caused by a continuous build system, such as Jenkins or IBM Rational Team Concert.

However, you don’t have to use an automated tool like uDeploy. If you want, you can implement your own scripts to manage your own deployments. For example, your deployment scripts can pull updated application files from a common staging area such as an HTTP server or a shared NFS or GPFS file server. The script package would first pull those files from the shared server, and then invoke the command line tools to deploy applications for your particular middleware, such as wsadmin in WebSphere Application Server. While this does not require any additional tooling outside of what is provided in PureApplication System, the building and maintenance of these deployment script packages does add additional work to the system. These scripts should be configured to run “on demand” so that they can be executed at any time when new files become available.

4.6 Database operations These are the tasks database operations personnel will perform to configure and maintain a database running in a workload.

4.6.1 Database data restore Workload backup and restore is handled through exporting from a system, and importing it when needed to the same machine or a DR machine. There are no backups of the VM outside the system. For the Database as a Service (DBaaS) pattern, you can use external Tivoli Storage Manager to back up the database. For virtual system pattern DB2, you can configure DB2 to use any supported backup, similar to if it’s hosted outside PureApplication System.

4.6.1.1 Preconditions Database backup should have been done using either Tivoli Storage Manager or using database’s backup mechanisms.



If you are restoring a DBaaS database, the existing database must be at the same version level as the new database receiving the migrated data. For example, data from a DB2 v9.7 database should only be moved into a DB2 v9.7 database.

4.6.1.2 Result Database has been restored either from Tivoli Storage Manager or from the backup.

4.6.1.3 Steps For DBaaS, you can create a new database using a customized workload standard.

For database instances created using virtual system patterns, you can restore either from Tivoli Storage Manager or by using the DB2 restore capability.


DB2 Information Center: Data Recovery in DB2

PureApplication Information Center: Applying a default database workload standard

4.7 Finance and compliance These are the tasks finance and compliance personnel will perform to govern usage of the system and expenditures to improve it.

4.7.1 Configure external audit logging The auditing function logs administrative and security-related events that occur on the system. PureApplication System has a separate Auditing role to be used exclusively by personnel performing audits for compliance. The user with full auditing permissions can set up the system to push the audit data to an external file system when the internal database has reached its threshold. Saving audit record packages externally lets you analyze data offline and also archive data to meet various compliance and regulation requirements.

4.7.1.1 Preconditions Configure an external server with a file system and the login credentials for a user with write permission to that file system.

Additionally, to perform this task, you will need the Auditing role with permission to Manage auditing (Full permission).

4.7.1.2 Result This enables the audit compliance person to set up the audit data being automatically pushed to the external file system.


1. Information Center: Configuring external storage servers


http://pic.dhe.ibm.com/infocenter/db2luw/v9r7/index.jsp?topic=%2Fcom.ibm.db2.luw.admin.ha.doc%2Fdoc%2Fc0052073.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/index.jsp?topic=%2Fcom.ibm.puresystems.appsys.1700.doc%2Fvirt_app_patterns%2Fdb%2Fdbt_workloadstandard.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/index.jsp?topic=%2Fcom.ibm.puresystems.appsys.1700.doc%2Fvirt_app_patterns%2Fdb%2Fdbt_workloadstandard.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/index.jsp?topic=%2Fcom.ibm.puresystems.appsys.1500.doc%2Fsystemconsole%2Ft_audconfig.html



Information Center: Auditing overview

4.7.2 Script auditing tasks We’ve shown tasks for configuring auditing using the console. Once you’re comfortable with how to do this, it can be helpful to write CLI scripts to perform the configuration. These scripts automate the tasks to avoid mistakes, represent the tasks as source code so it can be stored in an SCM system, and are useful for configuring multiple systems consistently.

4.7.2.1 Preconditions To run the scripts that configure auditing, you will need:

The Auditing role with permission to Manage auditing (Full permission).

To run the scripts that view audit records, you will need:

The Auditing role with permission to View all auditing reports (Read-only).

4.7.2.2 Result You can configure auditing to your specifications by running a set of scripts. Store these in SCM for later use. Use these to keep a record of your configuration, to fix the configuration if it gets messed up, and as a basis to configure another system the same as or similarly to the first.


1. Understand the CLI

a. Information Center: Using the command-line interface

b. Information Center: Using the command line interface for the system console

2. Configure auditing settings

a. Information Center: Get external storage server configuration for auditing

b. Information Center: Set external storage server configuration for auditing

3. Access audit records

a. Information Center: List all auditing records

b. Information Center: Verifying audit record packages using the command line interface

c. Information Center: Retrieve specific auditing record information


http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/index.jsp?topic=%2Fcom.ibm.puresystems.appsys.1500.doc%2Fiwd%2Faac_audit_overview.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/iwd/cct_usingcli.html



http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/clihelp/get_current_external_storage_server_configuration.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/clihelp/set_current_external_storage_server_configuration.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/index.jsp?topic=%2Fcom.ibm.puresystems.appsys.1500.doc%2Fclihelp%2Flist_all_auditing_records.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/iwd/aat_audit_record_verify_cli.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/iwd/aat_audit_record_verify_cli.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/index.jsp?topic=%2Fcom.ibm.puresystems.appsys.1500.doc%2Fclihelp%2Fretrieve_a_specific_auditing_record_info.html


4.7.3 Review audit logs The auditing function logs administrative and security-related events that occur on the system. Each event in the log records user actions that might affect system integrity: who performed the action, when, from where, what resource was involved, and whether the action was successful. You can use this audit data to determine security breaches and to follow a history of changes to the system’s configuration.

4.7.3.1 Preconditions To perform this task, you will need the Auditing role with permission to View all auditing reports (Read-only).

4.7.3.2 Result You can now see the changes that have been made to the system’s configuration and confirm compliance.


1. Information Center: Generating audit record packages


Information Center: Managing auditing

4.7.4 Chargeback for resource usage IBM PureApplication System provides a diverse set of standard reports that you can use for chargeback:

Machine activity reports – Used to track the physical and virtual resources that are used in the cloud.

Virtual machine usage reports – Used to show specifics about individual VMs.

User activity reports – Show resources that are used by each user account: active virtual machines, reserved storage, reserved CPU, and reserved memory. The user activity report displays the physical and virtual usage that is broken down for a time period.

4.7.4.1 Preconditions To view the reports or download them, you need to have one or more of the following security roles:

For reports that contain information about compute nodes: Hardware administration role with permission to View all hardware resources (Read-only).

For reports that contain information about cloud groups, IP groups, or virtual machines: Cloud group administration role with permission to View all cloud resources (Read-only).


http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/index.jsp?topic=%2Fcom.ibm.puresystems.appsys.1500.doc%2Fsystemconsole%2Ft_audrecpack.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/systemconsole/t_sysaudit.html


4.7.4.2 Results You can view the reports in the PureApplication System console or you can download them as CSV files that can be studied offline.


1. Go to System Console > Reports and click on any of the choices on the submenu to view reports.

2. Specifically, go to the Chargeback page (System Console > Reports > Chargeback), where you download chargeback reports in various formats.


Information Center: Administering Reports

4.7.5 Review system upgrade or new racks requests While working with different system users to determine their current and future needs, the IBM PureApplication System administrator can proactively review the resource utilization to determine the need for a system upgrade or the need for a new rack,. If an update is required, they would have to follow the organization’s process to put in a request to the Finance team to evaluate and approve the request.

4.7.5.1 Preconditions Requests from the System admin for upgrade.

4.7.5.2 Results Decision will need to be conveyed to the appropriate teams to either place an upgrade or new rack order, or take no action at this time.

4.7.5.3 Steps The team would need to evaluate the requests and weigh them against the current finance situation of the organization.

4.8 Content enablement These are the tasks that content enablement personnel will perform to develop the topologies on which applications can be deployed.

4.8.1 Import virtual image Occasionally, the virtual image provider will provide an update to their virtual image, or you may want to import a new virtual image in PureApplication System’s workload catalog. The virtual image is provided as an .ova file. This image might be for one of the entitled products or un-entitled products for which you have purchased a license so that you can use the product in PureApplication System. In most cases, IBM bundles the


http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/index.jsp?topic=%2Fcom.ibm.puresystems.appsys.1500.doc%2Fiwd%2Fret_reportin.html


virtual image along with its pattern in a single tar.gz or .tgz file. This will be discussed in 4.8.5 Import virtual system pattern.




4.8.1.2 Result Once you have imported the virtual image in PureApplication System, the image will be shown in the workload catalog. This will not replace any older existing virtual image. The parts of the new virtual image (for example, WebSphere Deployment Manager, or IBM HTTP Server, and so on.) can then be used in existing or new virtual system patterns.

4.8.1.3 Steps 1. Download the virtual image file from the vendor’s web site. For IBM products,

you can download this from links provided from the PureSystems Centre.

2. Import the virtual image using the PureApplication System console or CLI. For large file sizes over 2GB, CLI is a better option.

a. Information Center: Importing virtual images to the catalog

b. Information Center: Virtual images command-line interface reference

Using the deployer.virtualimages.create command

3. Accept the license for the new image.

4.8.2 Export virtual application pattern The virtual application export function can be used to move a workload from one system to another system. It could also be used to store the pattern artifacts in some SCM. Virtual application pattern resources are stored in a single zip file.

4.8.2.1 Preconditions You must have access permissions to the virtual application pattern.

4.8.2.2 Result None.

4.8.2.3 Steps There are two ways to export the virtual application pattern.

To use the console, perform these steps:

1. Information Center: Exporting virtual application patterns


http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/index.jsp?topic=%2Fcom.ibm.puresystems.appsys.1500.doc%2Fiwd%2Fpct_addvi.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/index.jsp?topic=%2Fcom.ibm.puresystems.appsys.1500.doc%2Fiwd%2Fpcr_cli_virt_image.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/index.jsp?topic=%2Fcom.ibm.puresystems.appsys.1700.doc%2Fworkloadconsole%2Ft_exportapp.html


To use the CLI, perform these steps:

1. Information Center: Virtual application pattern command-line interface reference

4.8.3 Export virtual system pattern The virtual system pattern export function can be used to move a workload from one system to another system, or it can be used to store the pattern artifacts in an SCM repository. Virtual system pattern resources are stored in a single zip file.

Since virtual system pattern could have multiple artifacts (virtual images, scripts, pattern definition), you can select the subset of artifacts you would like to export through the CLI export command. You need to ensure that if you import the pattern on another rack, artifacts that are not included in the export file must already exist in the catalog on the other rack.

4.8.3.1 Preconditions You must have access permissions to the virtual system pattern.

4.8.3.2 Result None.

4.8.3.3 Steps Export can be performed only using the CLI. Perform these steps:

1. Information Center: Export virtual system patterns

4.8.4 Import virtual application pattern The virtual application pattern import function can be used to move a workload from one system to another system, or it can be used to recreate a pattern from artifacts stored in an SCM repository. Virtual application pattern resources are stored in a single zip file.

4.8.4.1 Preconditions You must have access permissions to the virtual application pattern. The pattern types and its plug-ins must already have been imported into the catalog.

4.8.4.2 Result Once imported, the virtual application pattern will appear in the Catalog.

4.8.4.3 Steps First you need to download the pattern:

1. You will need to download the virtual pattern tar zip file from the vendor’s web site. For IBM products, one can download this from links provided from the PureSystems Centre.

Second, there are two ways to import the virtual application pattern.

From the virtual application pattern console for file size less than 2 GB:


http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/index.jsp?topic=%2Fcom.ibm.puresystems.appsys.1500.doc%2Fiwd%2Fair_apppattern.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/index.jsp?topic=%2Fcom.ibm.puresystems.appsys.1500.doc%2Fiwd%2Fmpr_vsyspexim.html


1. Go to virtual application pattern console.

2. Select the “Import” icon

3. Specify the pattern zip file.

From CLI:

1. Command line import can be used for all file sizes. The details are available in the Information Center: Virtual application pattern command-line interface reference

4.8.5 Import virtual system pattern Occasionally, the virtual system pattern provider will provide an update to the contents of their virtual system patterns (virtual image, script packages, or patterns that consume the image and script packages).

The virtual system pattern import function can be used to move a workload from one system to another system, or it could be used to recreate a pattern from artifacts stored in an SCM repository.

The virtual system pattern and its content are bundled in a single tar.gz or .tgz file. These patterns can be for one of the entitled products or un-entitled products for which you purchased a license to use the product in PureApplication System.




4.8.5.2 Result Once you have imported the virtual system pattern in PureApplication System, the pattern’s contents will be visible in the workload console:

From the Workload Console > Patterns > Virtual Systems page for patterns.

From the Workload Console > Catalog > Virtual Images page.

From the Workload Console > Catalog > Script Packages page.

4.8.5.3 Steps 1. You will need to download the virtual pattern tar zip file from the vendor’s web

site. For IBM products, you can download this from links provided from the PureSystems Centre.

2. Import the virtual system pattern using the PureApplication System CLI.

Information Center: Updating virtual system patterns by using the command-line interface


http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/index.jsp?topic=%2Fcom.ibm.puresystems.appsys.1500.doc%2Fiwd%2Fair_apppattern.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/index.jsp?topic=%2Fcom.ibm.puresystems.appsys.1500.doc%2Fiwd%2Fsir_updatepattern.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/index.jsp?topic=%2Fcom.ibm.puresystems.appsys.1500.doc%2Fiwd%2Fsir_updatepattern.html


o Use the sample script, importPatterns.py, included in the samples directory when you download the Command line tool from the Welcome page.

3. Accept licenses for virtual images that are included in the zip file.

4. Accept licenses for script packages, if present.

4.8.6 Import and install virtual application components Virtual application pattern types, plug-ins, and shared services are defined by the pattern types and plug-ins in the catalog. The artifacts are bundled in a single tar.gz or .tgz file.

4.8.6.1 Preconditions In most cases, the pattern types will include the plug-ins that have been modified and required by the pattern types. Rarely will you need to import a plug-in, except in cases where IBM is providing a fix and would like you to try the plug-in fix before the pattern type is updated.

You would also need to ensure that the appropriate versions of the pre-req pattern types have already been imported. This would be documented on the web page where you will download the new or updated pattern types.




4.8.6.2 Result Once you have imported the virtual application pattern types or plug-ins or shared service in PureApplication System, they will be visible in the following workload console pages:

The Pattern Types page

The System Plug-ins page

4.8.6.3 Steps 1. Download the new or updated virtual application pattern type or plug-ins zip file

from the vendor’s web site. For IBM products, you can download this from the PureSystems Centre or IBM Fix Central.

2. From the workload console (for files less than 2 GB):

Information Center: Importing pattern types

3. Or, use the CLI (specially for large files):

Information Center: Virtual application pattern command-line interface

4. Accept the license for the new pattern types and enable the pattern type.


http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/index.jsp?topic=%2Fcom.ibm.puresystems.appsys.1500.doc%2Fiwd%2Fapt_importpatterntype.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/index.jsp?topic=%2Fcom.ibm.puresystems.appsys.1500.doc%2Fiwd%2Fapr_patterntype.html


5. In some cases, based on the pattern type, you may need to configure one or more plug-ins associated with the pattern type.

From the pattern type console, click on “Show me all plug-ins in this pattern type”. The System Plug-ins page will be displayed. You can then go through the plug-ins and you will see the “:Configure” option on the ones that need to be configured. You must configure them before you can start using the virtual system pattern-type or the shared service.

4.8.7 Develop custom image using extend and capture Extending and capturing an image enables you to customize the image that has been provided by a vendor such as IBM. Extend and capture is used when you want to make permanent changes to the image, like adding a new software package, installing a temporary fix to the middleware, changing some of the valid behavior, and so on. There are various ways to customize the image, such as adding script packages, ICCT. We suggest you use Extend and capture as the last resort if other customization methods do not suit the changes you need in the image.


The Create new catalog content sub-role of Workload management.


4.8.7.2 Result The new image created as a result of extend and capture will have the changes permanently baked in the image. Any deployment using that image will contain the changes by default.

The side effect of this is that you will have to maintain the image. When the vendor releases a new image, you will have to extend and capture that image to include the changes you need to add.


1. Information Center: Extending and capturing virtual images

4.8.8 Develop custom image using ICCT This should only be used to make a virtual image for a product that doesn’t already have a virtual image.

Use the Image Construction and Composition Tool (ICCT) to build virtual images for deployment into cloud environments. Experts build particular software bundles for reuse by others. This simplifies the complexity of image creation and reduces errors. You can reuse and manage images and software in a cloud environment, and build and share images that are self-descriptive, customizable, and manageable.


http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/iwd/pct_extend_vi.html


ICCT can be installed and used as a standalone application or enabled as a virtual application in PureApplication System (recommended).


The Create new catalog content sub-role of Workload management.


4.8.8.2 Result The new image created as a result of building the image using ICCT can then be used in any new or existing virtual system pattern, or even as a base OS for the virtual application patterns.

4.8.8.3 Steps These are the high-level steps:

1. Instantiate an instance of ICCT.

2. You can start with a new OVF file and import that as your new image, or import an existing virtual image from the Catalog, or create an image from an ISO image. The preinstalled IBM OS image (Red Hat Linux or AIX) from the catalog can provide a clean base on which you can install your software bundles. Alternatively, you can start with any other image and add additional bundles to it.

3. Create or get the software bundles from other developers and add that to the image.

4. For each bundle, you specify the installation scripts, configuration scripts, firewall, and reset scripts that will run at different points in the lifecycle of the image deployment. You can specify the license files that will be displayed when the image is added to the catalog.

5. You can then add the bundles to the image and provide the install configuration default values.

6. At this point, synchronize the image. This will deploy the image in PureApplication System as a virtual machine; run the installation tasks and copies over the configuration artifacts from the bundles.

7. Once you are satisfied with the state of the running virtual machine, you can capture it.


Information Center: Working with IBM Image Construction and Composition Tool


http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/index.jsp?topic=%2Fcom.ibm.puresystems.appsys.1500.doc%2FICON%2Ftopics%2Fiwd_cicn_overview.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/index.jsp?topic=%2Fcom.ibm.puresystems.appsys.1500.doc%2FICON%2Ftopics%2Fiwd_cicn_overview.html


4.8.9 Develop script package Script packages are added to virtual system pattern parts to customize their behavior. They are simple zip files that contains all the required artifacts to run the scripts. The scripts can be almost any set of executable files (OS or middleware specific).

When creating the script package, you would specify the executable that the VM will execute, its arguments, working directory, logging directory, timeouts, environment variables used by the scripts (the values of which can be provided by the deployer at deployment time), license agreements, access control, and so on. All these values can be either specified in the console, or better, provided in a json file called cbscript.json.

By default, your scripts are run on the deployed virtual machines using the root user context.

You have the option of running the scripts at deployment time after the VM has started, or on demand, or when the VM is deleted.

When multiple scripts are added to a virtual system pattern part, you can specify the order of the scripts that are run during deployment.

There are examples in the Information Center to show how to create a script package.

4.8.9.1 Preconditions You must create the script package zip file outside PureApplication System before you can import then into the catalog.


The Create new catalog content sub role of Workload management

The Workload resources administration role with permission to Manage workload resources (Full permission)

4.8.9.2 Result Once the script package is created and imported into the catalog, you can then add the script package to any virtual system pattern topology part. Once the pattern is deployed, the script package is copied to the VM and, based on the execution mode, it is either executed at deployment time, or an option is provided for you to run on demand, or executed when the VM is deleted.


1. Information Center: Adding script package


Information Center: Manage script packages


http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/iwd/pct_crescrpa.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/index.jsp?topic=%2Fcom.ibm.puresystems.appsys.1500.doc%2Fiwd%2Fpct_scipacui.html


4.8.10 Develop add-on Add-ons are specialized scripts that customize your virtual machine configuration. Add-ons provide fine tuning for hardware and operating system configurations. A set of basic add-ons with an initial configuration is provided. They are added to the virtual system pattern part.

You can create your new add-on, or clone an add-on and customize it. You can create an add-on for type disk (adding formatted or unformatted disk to VM), NIC (adding additional virtual network interface controller), User (defining additional user) or Network Storage attachment (like NFS).

As part of the add-on, you would provide the zip file that contains the required artifacts to run the add-on scripts on the deployed VM. You would specify the executable that the VM will execute, its arguments, working directory, logging directory, timeouts, environment variables used by the scripts (the values of which can be provided by the deployer at deployment time), license agreements, access control, and so on. All these values can be either specified in the console, or better, provided in a json file called cbscript.json.

By default, your scripts are run on the deployed virtual machines using the root user context.

There are examples in the Information Center to show how to create an Add-on package.

4.8.10.1 Preconditions You must create the add-on package zip file outside PureApplication System before you can import then into the catalog.




4.8.10.2 Result Once the add-on package is created and imported into the catalog, you can then add the add-on package to any virtual system pattern topology part. Once the pattern is deployed, the script package is copied to the VM and executed before any user scripts are executed.

4.8.10.3 Steps To add an add-on package, perform these tasks:

1. Information Center: Create add-ons


Information Center: Manage add-ons


http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/index.jsp?topic=%2Fcom.ibm.puresystems.appsys.1500.doc%2Fiwd%2Faot_addaddon.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/index.jsp?topic=%2Fcom.ibm.puresystems.appsys.1500.doc%2Fiwd%2Faot_addonsui.html


4.8.11 Create and edit virtual system patterns Once the pattern has been architected and the components (images, scripts, patterns, and so on) have been planned out, you need to develop them:

Create the script packages and import them in the catalog. Make sure you use SCM to save the scripts and version them.

If the pattern requires a custom image, create the custom image using ICCT or Extend and Capture. Once created, import the image in the catalog, and also save in SCM.

4.8.11.1 Preconditions Once you have architected the components of the patterns and the scripts, you need to do the following:

Develop any required script packages and import them in the catalog. Make sure you use SCM to save the scripts and version them.

If the pattern requires a custom image, create the custom image using ICCT or Extend and Capture. Once created, import the image in the catalog, and save the file in an SCM repository.




4.8.11.2 Result The new pattern created can now be used by the application development, test, and middleware teams. Once created, export the pattern and save the file in an SCM repository.


1. Information Center: Creating virtual system patterns

2. Information Center: Modifying virtual system patterns

4.8.12 Create and edit virtual application and DBaaS patterns

Virtual application patterns including the Database as a Service (DBaaS) patterns are a higher level abstraction of creating patterns that simplifies the work done by the pattern developer. The focus is on the applications, and applying policies to application components. PureApplication System creates the topology to satisfy the application and specified policies.


http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/index.jsp?topic=%2Fcom.ibm.puresystems.appsys.1500.doc%2Fiwd%2Fmpt_crenewpa.html


4.8.12.1 Preconditions The pattern type for the virtual application pattern you are creating should be in the catalog.




You also need access to the application code artifact that needs to be deployed into the virtual system pattern (at least in the case of the Web App pattern).

4.8.12.2 Result The new pattern created can now be used by the application development, test, and middleware teams. Once created, export the pattern and save the file in an SCM repository.


1. Information Center: Creating virtual application patterns

2. Information Center: Updating virtual application pattern types by using the workload console

For the DBaaS pattern, perform these steps if you want to create a customized workload standard.

Information Center: Working with customized workload standards

4.8.13 Install and configure application backup While PureApplication System provides backing up the system configuration data, the application data is very dependent on the workload running in deployed instances.

For the application backup, you have to mostly rely on traditional backups that you have within your organization. The use case where PureApplication System assists in the application data backup is the Database as a Service (DBaaS) virtual application instance. In that case, you can setup the database to be backed up by an external Tivoli Storage Manager. For the rest of the use cases, you can configure the VM via scripts to add the necessary backup code to back up the files or directories to some remote location, and restore it when needed.

4.8.13.1 Preconditions None.


http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/index.jsp?topic=%2Fcom.ibm.puresystems.appsys.1500.doc%2Fiwd%2Fapt_createapp.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/index.jsp?topic=%2Fcom.ibm.puresystems.appsys.1500.doc%2Fiwd%2Fapt_solutioninstaller.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/index.jsp?topic=%2Fcom.ibm.puresystems.appsys.1500.doc%2Fiwd%2Fapt_solutioninstaller.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/index.jsp?topic=%2Fcom.ibm.puresystems.appsys.1500.doc%2Fvirt_app_patterns%2Fdb%2Fdbt_customwls.html


4.8.13.2 Result Once the pattern is setup with the necessary scripts to leverage the backup solution that you use in your environment, the application data can be backed up for all instances of the same pattern.

4.8.13.3 Steps Create script packages to bundle the client backup code to be inserted in the VM whose files or directories you want to back up to a remote location. Add these script packages to the pattern parts.


Information Center: Configuring IBM Tivoli Storage Manager

IBM developerWorks: IBM PureApplication System backup and restore, Part 3: Workload backup

4.8.14 Develop virtual application component IBM provides several virtual application pattern types from which you can create your virtual application patterns. IBM also provides an Eclipse-based Plug-in Development Kit (PDK) to enable you to create custom virtual application pattern types and its plug-ins.

Virtual application pattern types consist of developing one or more plug-ins. Pattern types and plug-ins are available for technical experts to create their custom pattern types. Some of the links below provides details on how to create them.

4.8.14.1 Preconditions You need to download the PDK tool from the welcome page of the PureApplication System workload console. You can then use the Eclipse tooling to create the pattern type or the plug-ins.

4.8.14.2 Result Once you have created the virtual application pattern-type or the plug-ins, you can import them, as shown in the task 4.8.6 Import and install virtual application components.

4.8.14.3 Steps Use the PDK to develop your pattern type or plug-ins. Listed below are some of the helpful links to show how to create them.

Redbook: Creating Composite Application Pattern Models for IBM PureApplication System

IBM developerWorks: Create and customize virtual application patterns

Information Center: Plug-in development guide


http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/virt_app_patterns/db/dbt_configtsm.html



http://www.redbooks.ibm.com/Redbooks.nsf/RedbookAbstracts/SG248146.html

http://www.redbooks.ibm.com/Redbooks.nsf/RedbookAbstracts/SG248146.html

https://www.ibm.com/developerworks/cloud/library/cl-puresystem-plugintoolkit/

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/index.jsp?topic=%2Fcom.ibm.puresystems.appsys.1500.doc%2Fiwd%2Fpgr_plugindevcomp.html


4.8.15 Add fix to virtual image Emergency fixes, such as fix packs or interim fixes, are used to update the product binary files of deployed instances. Emergency fixes can be individual fixes or a group of fixes that are associated with particular virtual system or virtual application types.

For workloads for IBM middleware products, you can download the middleware from Fix Central or IBM PureSystems Centre. These fixes are either the normal middleware fixes or fixes created for virtual images in PureApplication System.

You can create and package your own fix to apply custom maintenance to your virtual system instances. For more information, see Packaging emergency fixes.

4.8.15.1 Preconditions Identify the fix for your workload and download from the appropriate site. To perform this task, you will need either of these permissions:



4.8.15.2 Result Once you have imported the emergency fix and associated it with the virtual image to which the fix can be applied, you can apply to the fix to any virtual system instances and virtual application instances containing that virtual image. The fix can be applied via the console or CLI or REST APIs. In addition, the fix can also be applied to virtual application pattern containing that image.

4.8.15.3 Steps For more information, see:

Information Center: Adding emergency fixes to the catalog

Information Center: Apply emergency fixes

4.8.16 Apply fix to virtual system pattern PureApplication System is pre-installed with virtual images and patterns that can be used to create virtual system instances. In order to apply maintenance or fixpacks to the pattern, the appropriate fixes need to be applied to the image. Once you have the updated virtual image, you would clone the virtual system pattern, and in the new cloned pattern, you would replace the virtual image with the new updated one. This is simple, where you would replace the version of the image part to point to the updated image part. The rest of the pattern remains the same.


http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/index.jsp?topic=%2Fcom.ibm.puresystems.appsys.1500.doc%2Fiwd%2Fpct_package_ef.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/topic/com.ibm.puresystems.appsys.1500.doc/iwd/pct_add_ef.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/index.jsp?topic=%2Fcom.ibm.puresystems.appsys.1500.doc%2Fiwd%2Fpct_package_ef.html


4.8.16.1 Preconditions You must have an updated image available in the catalog. There are three ways you would get or create the updated virtual image part:

1. The provider of the virtual image (IBM or an ISV) would provide the image which you would import into the catalog.

2. Bundle the fix in a script package and add the script package to the part in the pattern on which you want to apply the fix. The logic to perform silent install of the fix will need to be part of the script package.

3. Use the extend and capture function to apply the fixpack or emergency fix on the virtual image. This would be if the vendor has not yet supplied the updated image and you are in a critical need to get the fix applied to the pattern. Where possible, choose bundling the fix in a script package, since it lets you keep the original image, and minimizes the proliferation of image and the need for you to maintain the image.




4.8.16.2 Result The cloned virtual system pattern would use the new updated image parts that contain the fix. All new future deployments would then include the fix.

4.8.16.3 Steps From the virtual system pattern console:

1. Select the pattern you would like to update.

2. Clone the pattern and create a new one.

3. Edit the pattern to use the new updated image, replacing the old image. This is changing the version number of the updated image on the image part.

4. Save the pattern.

5. Deploy the pattern and test it to validate the fix.

4.8.17 Apply fix to virtual application pattern The virtual application pattern can be configured to accept an emergency fix to the pattern for certain virtual application component parts, like a web application part. This enables interim emergency fixes to be added to the pattern. When the pattern is deployed, the interim emergency fix will also be applied to the deployed instances.



4.8.17.1 Preconditions You must have imported the emergency fixes in the workload catalog, and associated the fix to one of more images that are used in this virtual application pattern. You must be the owner or have write permission on the pattern.

4.8.17.2 Result The interim emergency fix will be applied to all future deployed instances of the virtual application pattern.


1. Information Center: Applying a WebSphere Application Server fix to a new deployment

4.8.18 SCM of workload catalog The current release of PureApplication System does not support versioning in the platform. However, it is very important that you use a source control management (SCM) system to store and track the versions of your workload resource components (such as custom images, scripts, add-ons, and patterns). Like source code, these pattern components are valuable assets that took effort to create and whose versions should be managed. Naming of the resources based on versioning will help identify the artifacts that make up the custom pattern, and hence, provide you with the capability of recreating a custom pattern.

The ability to quickly recover your components from SCM will give you the flexibility to store them in PureApplication System only when you need them, deleting them when not needed, thereby reducing the clutter in your workload catalog.

An SCM repository is external to PureApplication System and is managed separately from the system. You can use CLI or REST to import/export resources from your SCM to PureApplication System, along with any APIs provided by your SCM tool.

4.8.18.1 Preconditions You must select your SCM solution and script or configure it to check in and check out files.


Both the Create new catalog content sub role of Workload management and the Workload resources administration role with permission to View all workload resources (Read-only).



http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/index.jsp?topic=%2Fcom.ibm.puresystems.appsys.1700.doc%2Fvirt_app_patterns%2Fap%2Fapt_wascacheifix_new.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/index.jsp?topic=%2Fcom.ibm.puresystems.appsys.1700.doc%2Fvirt_app_patterns%2Fap%2Fapt_wascacheifix_new.html


4.8.18.2 Result You can automate the export of workload resources and check them into the SCM repository, as well as automate checking them out and importing them into the PureApplication System workload catalog.

4.8.18.3 Steps To export from PureApplication System and check in the resources into SCM:

Write export scripts to export resources from PureApplication System (other tasks show how to export the resources from the system).

Write scripts using SCM APIs to check in those resources.

To check out from SCM and import into PureApplication System:

Write scripts using SCM APIs to check out resources from SCM.

Write import scripts to import the resources into PureApplication System (other tasks show how to import those resources into the system).

4.8.19 Configure authorization Workload resource administrators have access to all components in the workload catalog. To allow non-administrator users and groups access to a component, set the “access granted to” property on the component.

The resource owner can provide read, write, or all access to their resources to other users and groups, thereby providing others access to manage resources they own.

Some of the workload resource types that enable component-level access are:

Virtual images

Script packages and add-ons

Emergency fixes

Virtual system patterns and instances

Virtual application patterns and instances.

As an owner or someone who has all access to that resource, you can give read or write or all access to any user or group. Someone with all access to a resource can also delete that resource.

4.8.19.1 Preconditions To perform this task, you will need one of these permissions:

You must be an owner of that resource or have full access to that resource.

Workload resources administration role with permission to View all workload resources (Read-only).




4.8.19.2 Result The user or group that has been given access will be able to perform appropriate tasks on that resource based on the permission of read, write, or all.


1. In the console, select the resource to which you want to give access.

2. In the “Access granted to” field, select the user or group from the pull down menu and then toggle the permissions you want to give to that user or group.

4.8.20 Enabling DB2 HADR for disaster recovery in virtual system pattern

The DB2 HADR solution for virtual system patterns is comprised of two different parts, primary and standby. The solution is packaged as separate primary and standby patterns, each containing the corresponding part, so that the two parts can be deployed independently. To implement an HADR topology, the two DB2 HADR primary and standby parts should be deployed on different systems or at least deployed independently on the same system, which is why the two parts are contained in two different patterns.

When developing the topology for your own application that will use DB2 HADR, develop it as two patterns, where each contains the corresponding DB2 primary or standby part.

4.8.20.1 Preconditions The DB2 HADR primary and standby parts are part of the base catalog and should be in your catalog.




4.8.20.2 Results Once you have developed the patterns, you will need to deploy them. The steps of deploying the patterns for DB2 HADR are described in task 4.5.22 Deploy DB2 HADR for database disaster recovery.

4.8.20.3 Steps In the virtual system pattern editor, edit the patterns as follows:

1. In the pattern that should have the primary DB2 HADR, use the DB2 primary part.

2. In the pattern that should be the standby DB2 HADR, use the DB2 standby part.




Information Center: High transaction DB2 HADR system on IBM PureApplication

4.8.21 Enabling GPFS for disaster recovery in virtual system pattern

If the application in your virtual system pattern requires access to files in a GPFS shared file system, you will need to add GPFS client scripts to those parts in your pattern. This enables the VMs for those parts to access the shared file system.

4.8.21.1 Preconditions The GPFS pattern should already be imported in the rack. That pattern includes client scripts that will be needed to be included in your pattern.

You need to have access to edit the patterns that will utilize GPFS.

4.8.21.2 Results Once the pattern containing the GPFS client scripts is deployed, the scripted VMs will have access to the shared file system. Deployment of the shared file system is explained in task 4.5.23 Deploy GPFS for disaster recovery.

GPFS clients create a file set within the shared file system, then other clients can use the files and directories created within that file set. The GPFS cluster works in a trusted mode where all clients can share the files across all the file sets within that GPFS cluster instance. To create isolation across clients, create different GPFS cluster instances.

4.8.21.3 Steps Edit the virtual system pattern whose application needs access to files in the GPFS shared file system. Add these script packages to each part that needs access to the shared files:

1. GPFS Shared SSH certificate – This is run at deployment time to install the certificate needed between the GPFS client and the server.

2. GPFS Install – This is run at deployment time to install the GPFS client code in the VM.

3. GPFS Add Client Node – This is run when you initiate it to add the VM node to the GPFS server.

4. GPFS Remove Client Node – This is run when the pattern instance is deleted to remove the VM node to the GPFS cluster.

5. GPFS Create FileSet – This is run when you initiate it to create a file set in GPFS which can then be shared.

6. GPFS Link FileSet – This is run when you initiate it to create a link from shared GPFS directory to your local file directory, without you needing to SSH into the VM to create the link.

Once these scripts are added to any part, the deployed VM can then use the GPFS shared file system.


http://expertintegratedsystemsblog.com/2012/11/high-transaction-db2-hadr/

http://expertintegratedsystemsblog.com/2012/11/high-transaction-db2-hadr/


4.8.22 Enabling GPFS for disaster recovery in virtual application pattern

If the application in your virtual application pattern requires access to files in a GPFS shared file system, you will need to add GPFS’s pattern type to your pattern. This enables the virtual application VMs to access the shared file system.

4.8.22.1 Preconditions The GPFS pattern should already be imported in the rack. That pattern includes GPFS’s pattern type (named gpfsclient) that contains the policy to be added to the pattern component.

You need to have access to edit the patterns that will utilize GPFS.

4.8.22.2 Results Once deployed, your virtual application instance VMs will have access to the shared file system. Deployment of the shared file system is explained in task 4.5.23 Deploy GPFS for disaster recovery.

4.8.22.3 Steps Edit the virtual application pattern whose application needs access to files in the GPFS shared file system.

1. Add the GPFS client policy either to the pattern components or to the pattern (applies to all components). A unique GPFS file set is created on the server for each virtual application pattern deployment.

2. For each GPFS policy, specify the GPFS server IP address (primary server), one or more directories on GPFS file sets, file set quota (minimum and max storage), and link directories for each of the specified GPFS directories.

3. Save the changes and close the editor.

4.9 Application architecture These are the tasks application architecture personnel will perform to determine the strategy for using patterns for their application development and software development lifecycle (SDLC) efforts.

4.9.1 Select appropriate pattern for an application To make an application into a pattern, the needs of the application, especially the topology requirements, will drive the selecting of the pattern to use to deploy the application. You will need to work with the Content Enablement team to find or develop an appropriate pattern. You can choose from three approaches:

1. Use an existing pattern that satisfies the needs of the application

2. Modify an existing pattern to satisfy the needs of the application

3. Work with them to create a new pattern for the needs of the application.



4.9.1.1 Preconditions The Content Enablement team has already developed some patterns that you can consider for your application.

4.9.1.2 Result Once you have selected the pattern, you will provide the pattern to the application development teams, testers, and middleware application administrators to deploy and test the application in development, test, and production phases.

4.9.1.3 Steps Here is the general approach:

Review your organization’s existing patterns. Select one if it satisfies the application’s needs.

If none of the existing patterns is suitable, work with the Content Enablement team to have them provide a pattern. It could be a modified pattern from an existing one, or it could be a new pattern. Developing a suitable pattern will be a close collaboration between this Application Architecture team and the Content Enablement team.

4.9.2 Create DevOps environment PureApplication System provides a robust DevOps environment to enable continuous building and testing of your application, which is especially needed during application development.

Included with PureApplication System is a set of IBM Software Delivery and Lifecycle Patterns that include the following:

IBM Collaborative Lifecycle Management (virtual system pattern)

IBM Rational Application Developer Pattern (virtual system pattern)

IBM Rational Test Workbench Pattern (virtual system pattern)

IBM Rational Test Virtualization Server (RTVS) and Rational Performance Test Server (RPTS) (shared services)

IBM Rational License Key Server (shared service)

In addition, there is integration with Rational Urban Code Deploy (uDeploy) to enable you to push the configuration of the supported middleware to the deployed instance within PureApplication System.

4.9.2.1 Preconditions Work with the Content Enablement team to get a pattern that takes into account the DevOps requirement for your application.



4.9.2.2 Result The patterns you select can be used to support the DevOps environment in development and test phases, and possibly even in the production environment.


Review the patterns available for PureApplication System to support DevOps.

Use these patterns to implement a DevOps process for developing your applications.

4.10 Application development These are the tasks application development personnel will perform to use patterns for their application development and software development lifecycle (SDLC) efforts.

4.10.1 Determine the pattern to use for your application When developing an application, you need a simple environment to deploy the application into so that you can perform basic unit and functional testing. PureApplication System makes it quite easy to create these unit test environments. To use this approach, you will need a pattern that creates an environment or middleware topology suitable for deploying and testing your application.

You will need to work with the Application Architecture team to select a pattern appropriate for deploying your application. You will use that pattern to create a unit test environment you can use for your application development.

4.10.1.1 Preconditions The Application Architecture team has worked with the Content Enablement team to develop a pattern suitable for deploying your application and other applications requiring a similar middleware topology.

4.10.1.2 Result Once the Application Architecture team has selected the appropriate pattern, you can deploy the pattern and manage its lifecycle, as show in the subsequent tasks.


Ask the Application Architecture team what pattern you should use to create an environment for unit testing your application.

If a pattern suitable for your application is not available, work with the Application Architecture team to ensure they work with the Content Enablement team to create one.



4.10.2 Other tasks The tasks performed to use a pattern for application development are a subset of those performed to use a pattern to deploy an application into production. For details, see the tasks for these activities, listed in section 4.5 Application operations – Middleware admin:

Deploy a pattern

Monitor workloads

Apply fix pack to virtual system pattern

Apply fix pack to virtual application pattern

Apply maintenance to virtual system deployment

Apply maintenance to virtual application deployment

Administer virtual machines

Script workload management tasks

Perform application data restore

Delete the workload instance when not needed.

4.11 Database administration These are the tasks database administration personnel will perform to use patterns to develop and deploy databases.

4.11.1 Configure database monitoring service General database monitoring techniques are outside the scope of this document. This task addresses the lifecycle of Database as a Service (DBaaS) or DB2 instances — specifically, monitoring DB2 servers using the Optim Performance Manager built into the Database Monitoring shared service included with PureApplication System. The task of deploying the Database monitoring shared service is described earlier.

4.11.1.1 Preconditions The Database shared service has to be deployed in the cloud group where the workload is running. See task 4.4.4 Deploy database monitoring service.


4.11.1.2 Result You can now monitor your DB2 servers using Optim Performance Manager. This enables you to view performance information about the servers, create situations, and proactively act on issues.



4.11.1.3 Steps The actual steps are outside the scope of this document, and need to be performed by someone knowledgeable in Optim Performance Manager. For help:

IBM Integrated Data Management Information Center: Monitoring and reporting with Optim Performance Manager

4.11.2 Other tasks The tasks performed to use a pattern for deploying databases are a subset of those performed to use a pattern to deploy an application into production. For details, see the tasks for these activities, listed in section 4.5 Application operations – Middleware admin:

Deploy a pattern

Monitor workloads

Apply fix pack to virtual system pattern

Apply fix pack to virtual application pattern

Apply maintenance to virtual system deployment

Apply maintenance to virtual application deployment

Administer virtual machines

Script workload management tasks

Perform application data restore

Delete the workload instance when not needed.


http://pic.dhe.ibm.com/infocenter/idm/v2r2/topic/com.ibm.datatools.perfmgmt.monitor.doc/opm_monitor_report.html

http://pic.dhe.ibm.com/infocenter/idm/v2r2/topic/com.ibm.datatools.perfmgmt.monitor.doc/opm_monitor_report.html



5 Resources Here are some sites with more information about the product and how to use it:

IBM PureApplication System

IBM PureApplication System Version 1.1 Information Center

IBM PureSystems Centre

PureApplication System Support Portal

IBM Education Assistant for IBM PureApplication System

IBM PureSystems Redbooks

PureApplication System resources on developerWorks

IBM Passport Advantage Appliance Support Handbook

© IBM Corporation 2014 Version 1.0, May 2014 Copyright and trademark information

http://www.ibm.com/ibm/puresystems/us/en/pf_pureapplication.html

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/index.jsp

http://www.ibm.com/puresystems/centre/


http://publib.boulder.ibm.com/infocenter/ieduasst/stgv1r0/index.jsp?topic=/com.ibm.iea.ipas/plugin_coverpage.html

http://www.redbooks.ibm.com/Redbooks.nsf/portals/puresystems

http://www.ibm.com/developerworks/puresystems/pureappsystem.html

http://www.ibm.com/software/appliance/support/

http://www.ibm.com/legal/us/en/copytrade.shtml

public.dhe.ibm.compublic.dhe.ibm.com/software/dw/wes/1405_woolf/PureAppAdoptionS… · Adoption...

Documents

Transcript of public.dhe.ibm.compublic.dhe.ibm.com/software/dw/wes/1405_woolf/PureAppAdoptionS… · Adoption...