Ever wonder how you would install and deploy IBM WebSphere Application Server in large scale in enterprise environments? Interested in patching your WebSphere binaries in record time? If so, this session is for you. Cerner experts will share their experiences rapidly installing, deploying and managing WAS ND at scale and we will look at proven and tested strategies and techniques like creating master images for massive deployment and swinging profiles that will make managing your WebSphere infrastructure a breeze.
Tech-Forward - Achieving Business Readiness For Copilot in Microsoft 365
Rapid Deployments of IBM WebSphere ND at Scale
1. Rapid Deployments of IBM
WebSphere ND at Scale
Matt Boveri (Cerner)
matt.boveri@cerner.com
Yee-Kang Chang (IBM)
yeekangc@ca.ibm.com
2. What about you?
• WebSphere Administrators?
• Application Developers or Architects?
• Infrastructure Architects?
• Managers?
• Others?
2
3. IBM’s statements regarding its plans, directions, and intent are subject to change or withdrawal without notice
and at IBM’s sole discretion.
Information regarding potential future products is intended to outline our general product direction and it should
not be relied on in making a purchasing decision.
The information mentioned regarding potential future products is not a commitment, promise, or legal obligation
to deliver any material, code or functionality. Information about potential future products may not be incorporated
into any contract.
The development, release, and timing of any future features or functionality described for our products remains
at our sole discretion.
Performance is based on measurements and projections using standard IBM benchmarks in a controlled
environment. The actual throughput or performance that any user will experience will vary depending upon many
factors, including considerations such as the amount of multiprogramming in the user’s job stream, the I/O
configuration, the storage configuration, and the workload processed. Therefore, no assurance can be given that
an individual user will achieve results similar to those stated here.
Please note
5. Notices and disclaimers continued
Information concerning non-IBM products was obtained from the
suppliers of those products, their published announcements or other
publicly available sources. IBM has not tested those products about
this publication and cannot confirm the accuracy of performance,
compatibility or any other claims related to non-IBM products.
Questions on the capabilities of non-IBM products should be
addressed to the suppliers of those products. IBM does not warrant
the quality of any third-party products, or the ability of any such third-
party products to interoperate with IBM’s products. IBM expressly
disclaims all warranties, expressed or implied, including but not
limited to, the implied warranties of merchantability and fitness
for a purpose.
The provision of the information contained herein is not intended to,
and does not, grant any right or license under any IBM patents,
copyrights, trademarks or other intellectual property right.
IBM, the IBM logo, ibm.com and [names of other referenced IBM
products and services used in the presentation] are trademarks of
International Business Machines Corporation, registered in many
jurisdictions worldwide. Other product and service names might
be trademarks of IBM or other companies. A current list of IBM
trademarks is available on the Web at “Copyright and trademark
information” at: www.ibm.com/legal/copytrade.shtml.
14. WAS Install
(Binaries)
Profile (Config) + Apps
Installer / Install Data
Anatomy of a WAS
(traditional) install
• WAS Install
• Jars, scripts etc – Your WAS
• Profile
• Server configuration, applications
etc – Your data
• Installer
• IBM Installation Manager and its
data – What you need to install and
update your WAS
• Profile is created under your WAS
install location by default – Hence, it
appears that the Install and the Profile
go as one
15. WAS Install
(Binaries)
Profile (Config) + Apps
Installer / Install Data
Separation of Install &
Config
• Your WAS and your data do not have
to be put under the same location!
• They can be in different locations
• Separation → Flexibility and
opportunity for rapid deployments
• Setup and manage your WAS
install (binaries) separate from
your WAS data (profile)
• Create images of your WAS
installs for rapid and large scale
deployments
31. • Work directly with the Installation
Manager installer (install kit)
• Co-locate the agent data location
and the shared resources directory
with each of your install (package
group)
<install_home>
/was
/iim_data
/iim_shared
• You have a master image!
• Service each image or instance by
referencing the co-located agent
data
Creating & Servicing Master Images
WAS Binaries
/was
IIM Agent Data
/iim_data
IIM Install Kit
unzipped
IIM Shared Resources
/iim_shared
Master Image
<install_home>
IIM Repo with
WAS Offering
33. Unexpected problems with
recent fix pack update in
production
• Swing profiles and servers
back to last good level easily
• No time-consuming rollback
operations
Swinging Profiles: Examples
Performance comparisons
• Swing common set of profiles
quickly between installs of
choice for testing
• No multiple installs of identical
profiles and servers
• No single install that is
repeatedly updated or rolled
back
34. Shared Binaries
Similar in concept to Swinging Profiles
• A variation on the technique
Install WAS on a shared drive
• Read-only install
• Share (mount) the drive across systems
• Profiles on the target systems (nodes)
• Manage WAS install (updates) on the shared drive centrally
35. Assess
• Determine if this is what you need
Setup
• Decouple install from configuration
• Setup to handle and distribute master images
Execute
• Manage installs and profiles separately
• Clone from images and swing profiles on subsequent updates
Automate
• Automate what is needed
• Find ways to further optimize
37. Resources
Create and service WebSphere Application Server master images with IBM
Installation Manager
https://www.ibm.com/support/knowledgecenter/SSAW57_9.0.0/com.ibm.w
ebsphere.installation.nd.doc/ae/tins_sm_images.html
Swinging profiles between product service levels
https://www.ibm.com/support/knowledgecenter/SSAW57_9.0.0/com.ibm.w
ebsphere.installation.nd.doc/ae/tins_sp_overview.html
Sharing a WebSphere Application Server traditional installation
http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP102730
41. Background: Concepts & Terminology
Separation of install
(binaries) and
configuration
• tWAS configuration = Profiles
Techniques for Enterprise
Deployments
Leveraging separation of install
and configuration for large scale
deployments
• Swinging profile
• Shared binaries
42. IBM Installation Manager’s Concepts & Patterns
Enterprise
Repository
Host
IMShared
Agent Data
IM
Agent Data
IMShared
Host
Host
Agent Data
IMShared
IM Install Kit
Unzipped
Mount Drive with IM
Mount Drive with IM
43. Patterns for IBM Installation Manager
Enterprise
Repository
Centralized
Installation
Manager
Agent Data
IMShared
CIM Target
HostIM Install Kit
• Response Files
• Install Jobs
IM Repository
Inventory Info
Host
IMShared
Agent Data
IM
Agent Data
IMShared
Host
Host
Agent Data
IMShared
IM Install Kit
Unzipped
Mount Drive with IM
Mount Drive with IM
44. Working with Repositories in the Enterprise
The IBM Packaging Utility (PU) is a free companion tool to
Installation Manager
IBM Packaging Utility and IBM Installation Manager can be used
independently of each other
IBM Packaging Utility capabilities:
Generate a new repository containing one or more
product offerings
Delete packages from an existing repository, such as
unneeded fix pack levels
Combine a split repository into a single repository
(important for servers)
Can extract offerings for a single operating system
from a large repository, producing a smaller “platform-
scoped” repository
Repositories can be made available to your own
organization using a web server or FTP server
Hosting a single repository containing multiple
packages means fewer repositories need to be added
to Installation Manager's preferences
45. Managing WAS Installs
WAS 8.x and 9.0 installs
•Set the Agent Data and Shared Resources directories of Installation Manager to
custom (non default) location that are local to the host
•Backup Agent Data and Shared Resources directories after installation and
maintenance
•Recommend use of imcl command line. You can create custom scripts to automate
installs with imcl
•Enterprise Repository is the best way to host content for all WAS offerings to share
and reuse in house
•Installation Manager installer (install kit) is good way to do installation – This
eliminates the need to update IIM before every fix pack update
•For new 8.5.5.x installs, use Java SE 8 as the default SDK if application is
compatible with Java SE 8
46. Swinging Profiles: What is it?
• An environment in which WebSphere Application Server traditional Profiles
are loosely coupled to any number of WebSphere installations, rather than
the typical setup in which Profiles are bound to a single installation.
• Participating Profiles and WebSphere installations can be added or deleted
as required at any time.
• Participating WebSphere installations will typically be at differing service
levels.
• 'Swinging' refers to the act of associating all Profiles (en masse) to a
selected installation.
• After a 'Swing' takes place, all participating Profiles, and associated
application servers, will assume the service level of the selected installation.
About Cerner - Matt
WAS usage at Cerner - Matt
Challenges - Matt
What Cerner has tried - Matt
Concepts - YK
Separation of install and config
Working with master images
Cerner’s solution - Matt
How does Cerner use Swinging Profile
Benefits
Quantitative improvements
Automation
What’s Next?
Techniques/How Tos - YK
Creating master images with IIM
Swinging Profiles
Shared Binaries
Resources - YK
From the beginning, Cerner has innovated at the intersection of health care and information technology. Our mission remains to contribute to the systemic improvement of health care delivery and the health of communities.
With health information technology at our core, we employ some of the world’s most talented software engineers, developers and clinicians to ensure the solutions we create for our clients are consistently state-of-the-art. Today, with over 28,000 associates, Cerner is the world’s largest publicly-traded health IT company. Our 2017 revenue was $5.1 billion and we attribute much of our success to nearly 40 years of creating solutions for some of health care’s toughest challenges.
At Cerner we leverage IBM WebSphere Application Server Network Deployment or “Traditional WebSphere” to deliver our Enterprise Java Applications to our clients. Depending on the size and needs of a given client the CELL may contain as few as 2 app nodes up to as many as 12 on our largest single CELLs. All of our applications are deployed to dynamic clusters to allow us to scale and leverage the APC. Most of our clusters house a single ear; however, some of these clusters will contain many ears depending on the application needs. Given the wide variance from one CELL to another we need to ensure we take extra care to manage our entire WebSphere deployment efficiently. From a node and profile level we try to keep our CELLs as similar as possible to allow management and automation the opportunity to deliver repeatable and efficient results.
At Cerner we have hundreds of traditional WebSphere ND CELLs to meet our ever evolving client's needs. With the constant risks in the Cyber Security space we need to be able to regularly keep our WebSphere CELLs up to date with WebSphere Fix Packs, iFixes and security patches in order to stay secure. Additionally, we need to be able to quickly grow our scale as our clients grow or their needs change. All of this needs to be done quickly and consistently without impacting our end users.
How can we quickly and efficiently deploy and scale our WebSphere ND CELLs?
Today at Cerner we are in the final stages of our transition from WebSphere on Windows to WebSphere on Linux. While our Windows Cells are very similar to one another due to our automation around installs and maintenance events, they still require hours of engineer’s time to build and maintain these Cells. While much of the management of these Cells is automated, there is still engineering time to kick off, monitor, and manage the scripts. With the various tasks done by our system engineers we wanted to alleviate some of their regular maintenance tasks to free them up to manage their other responsibilities.
As part of our proof of concept for WebSphere on Linux our next option we tested was a manual install of WebSphere on Linux using IMCL to do the install. While this worked similar to our Windows installs it did not give us the opportunities we were looking for to fully automate patching as there was still a reliance on IBM Installation Manager (IIM). It did; however, allow us to prove moving our applications from Windows to Linux did not include a development cost as part of the re-architecture.
Once we proved we could leverage WebSphere on Linux and validated that there would not be an impeding development cost to move our applications from running on Windows to running on Linux we began validating and working with WebSphere on Linux using Swinging Profiles installs. Swinging profiles allows us the opportunity to create an install binary and ship that to all of our nodes, rather than running IIM on each node. Since swinging profiles relies on a central binary that can be reviewed and validated before shipping we open the door to doing FP and iFix installs with our automated reboots.
I am going to let YK explain the concepts behind swinging profiles and then we will discuss more specifically how this addresses our issues and what opportunities this opens for us going forward.
Overview of what is within or inside a WAS installation
Perhaps unbeknownst to many, you can separate your WAS installation and configuration i.e. they don’t have to reside under the same location.
Call out directory structure to make them more concrete
With separation of install and configuration, we can accomplish rapid deployments.
Where we can achieve optimizations
Where we can achieve optimizations
Starting with Version 8.5.5.9, you can configure your environment to use a common set of profiles that you associate with multiple installations. Because the profiles are decoupled from any specific installation, you can associate the profiles with different application server installations, or swing the profiles.
Leveraging swinging profiles allows us to create a master image of the given WebSphere binaries, including Fix Packs, iFixes and security fixes then quickly deploy the same binary across our entire WebSphere ND deployment.
Since we are no longer reliant on installing or updating of WebSphere on each server our only time constraint is the time to stop and start WebSphere on the box, as the act of swinging the profiles takes less than a second. The ability to create a binary with the entire install on a single node and deploy the exact same binary to all nodes ensures consistency. Further, since the binary is always the same, we know the binary used in testing is the same deployed to our non-production and production environments. This saves us time in testing as we can decouple problems related to the install of WebSphere from potential issues with the version of WebSphere we are running. If you have 1000 nodes taking 1 hour each to update and had a single person in charge of always keeping these nodes current it would take that person 25 weeks to update every node working a 40 hour week. Given WebSphere fix packs come out roughly every 14 weeks and iFixes come out almost weekly there is no way this person could ever keep up. Given the consistency of the binary extract we are able to trust our automation around fix pack installs with a higher degree of certainty than ever before. Our end goal is to have swinging profiles updates happen on reboot, thus removing the management needs from our operations groups. Being able to always stay current with WebSphere Fix Packs means we are able to take advantage of all of the security and performance benefits contained in those Fix Packs. Since we are already gracefully stopping and rebooting our WebSphere nodes as part of this process we are also able to take advantage of the opportunity and apply OS patching.
Testing on the same binary across environments means we can trust the results we see in our validation environments and development domains through our client facing non-production and production domains. This ensures a more consistent management experience for our developers and our end users.
With windows we were needing to run IIM on every node to do the fix pack updates. This process took about 1 hour per node with the automation we have designed to help keep this process running smoothly. With Linux we are able to land the binaries ahead of time and prep nodes as needed. This means the time to update a fix pack is the amount of time it takes to change the symbolic links related to the new binaries.
Today we have what we call our Menu script. This is an options driven menu that allows our operations team to manage their CELL without needing to launch the console. This allows them to take actions from cycling a process through managing a Fix Pack install. There are options to download the latest binaries as well as update the binaries through the menu. If the engineer has not stopped WebSphere on a given node prior to running the menu script we also ensure WebSphere is gracefully stopped before running the swinging profile update. This was our first step to the path of fully automated fix packs on reboots.
Working with IM install kit i.e. without IM installed on the target system to create and service master images. Creating and pushing images will enable rapid deployments.
Procedure to setup swinging profiles. Details are available in Knowledge Center.
What you can do with Swinging Profiles and example scenarios
A variation of Swinging Profiles where WAS binaries (installs) are shared on a common location instead of being pushed around.
Key steps to take away if users want to implement the Rapid Deployment approaches discussed here