Installing WebSphere

We can’t install Connections until both WebSphere and the DB2 (or Oracle or SQL) databases are in place so let’s start with WebSphere.  On previous posts we looked at installing Installation Manager (IM) and setting up a software repository to point to the WebSphere installers

skitch.21

My first check is to decide what version and fixpack I need and I do that by checking the System Requirements. These can change any time so I make a point to check them just before doing an install.   According to the current requirements Connections 5.5 needs a minimum of WebSphere Application Server Network Deployment 8.5.5 Fixpack 6. Since the requirement is a minimum I could install the most recent Fixpack 8 but for my purposes I’m sticking with Fixpack 6 today.

skitch.20

Even though at this point I’m not installing IHS I can see on the system requirements that it only supports 8.5.5 fixpack 6 of IHS.  This is something I need to remember later.

skitch23

When  launching IM and clicking “Install” I am presented with serveral products with their latest versions and options.  I have to click the checkbox “Show All Versions” to choose an earlier fixpack such as Fixpack 6

skitch.19

There are now hundreds of products and versions to choose from so to make it easier I type “network deployment” in the search bar at the top to filter the product choices (and so I don’t accidentally choose the wrong one). I then select 8.5.5.6 as the version I want to install. I haven’t downloaded 8.5.5.6, only 8.5.5 so I’m relying on IM to get the fixpack from the Passport Advantage site.

skitch.18

There are already several fixes available for 8.5.5.6 but, having checked the System Requirements to ensure there are no specifics fixes I need, I let IM choose the recommended ones only.

skitch.17

I now identify two locations, The first is the location for the shared resources directory used by IM.  This is the location for IM to store the installers, fixes and rollback files, not the location of the WebSphere program itself.

skitch.16

Now I can tell IM where to install WebSphere.  The default “WebSphere” directory will always be /IBM/WebSphere/AppServer and I would only change this if I was installing multiple WebSphere versions on the same machine (unlikely).  On Linux this defaults to /opt/IBM/WebSphere/AppServer and on Windows I try to put it on a separate drive partition from the OS such as D:\IBM\WebSphere\AppServer.  This location is your “WebSphere program directory” that is referred to in documentation.

skitch.15

These are the standard features I install for Connections.  At this point the total install size should be about 2.5GB across both directories.

skitch.14

Our confirmation screen just before the install starts shows what products will be installed into which locations.  Read the target location details at the top of this screen to confirm you have entered them correctly.

skitch.13

Our WebSphere install is now complete (love that big green tick) but now I need to create profiles to set up the servers.  Selecting OK here will launch the profile management GUI tool but this can also be launched later off the GUI menu or you can create profiles by using the /opt/IBM/WebSphere/AppServer/bin/manageprofiles.sh command

skitch.12

Since this is the first server in my deployment I need to create a new cell which will include both a deployment manager and an application server.  I often like to create the deployment manager standalone on its own machine if I’m building a HA cluster but for our purposes in Connections101 I’m just locating both the deployment manager and my first application server together.  These are the first servers on “bogart” as shown below.  If I were creating an additional Application Sever on “marlowe” then I would be creating an Application Server profile only at this point.

WebSphereExamples

 

skitch.11

Often during profile creation I would just choose the “Typical” option which is a far simpler series of choices with some default settings.  I’m choosing Advanced profile creation here to show you all the settings available to you.  The difference between “Typical” and “Advanced” is purely the ability to custom set options like ports, certificates and passwords – all of which can also be changed later after the profile already exists.

skitch.10

I always want to deploy the administrative console if I’m deploying a new cell because that’s how I’m going to manage all the servers.  If I add an existing Application server into an existing cell by federating it, its administrative console will be removed so it can be managed only by the deployment manager.

I often choose not to deploy the default applications for security reasons because it just gives me more things to have to lock down.  It can be useful for WAS troubleshooting but I rarely use it.

skitch.9

The first deployment manager on a node is usually put in a profile Dmgr01, similarly the first application server is put in the profile AppSrv01.  You can change both of these to something more meaningful if you want.  I never usually do. One thing to note in WebSphere world is to stay away from anything that could be a special character for path names or passwords.  As I mentioned on the previous post, all WAS configuration is stored in XML files and often encrypted so decrypting those special characters can fail and cause WebSphere itself to stop working.

Specific special characters to avoid for anything WebSphere related include

\/*,;:=+?{}[]<>_%^&$'”^()

but I like to avoid anything that could be problematic including accented characters.  Longer passwords can be just as effective.

skitch.8

The hostname for the server is picked up from the server’s local settings or host file. You need to make sure it’s a fully qualified name and not just “bogart”.  It also needs to be fully resolvable with an IPV4 address from itself and any other server.  The default deployment manager and application node names will be “servername”CellManager01 and “servername”Node01.  This is important because the servers will be installed with these names and a lot of nested directories will use the names.  IBM recommend your server name is no longer than 8 characters for this reason (avoiding creating very very long filepaths) but if your servername is long you can change the node names here to something shorter..

The cell name and node names cannot be changed post install and will be used to reference the servers internally.  It will always be possible to add another resolvable fully qualified hostname like “hammett.connecitons101.info” as an alias later but you can never fully remove these names.

skitch.6

When WebSphere is installed new SSL certificates are created using an IBM internal Certificate Authority and the servers’ hostnames and roles.  These certificates are usually replaced by me post install with valid SSL certificates from a public or internal provider.  If however you have a wildcard certificate for your organisation already you could add it during the install and avoid having to replace the internal IBM certificate later.  You would still need to add the trusted root though and I’m a control freak so I like to let IBM create its certificates then manually go in and replace them later.

skitch.5

The default certificates that are created (assuming you didn’t choose to replace them on the previous screen) will have keystore passwords of WebAS.  This is well known as IBM’s  default keystore password and for that reason WebSphere will see it as a security issue if you don’t change the password for keystores on a running server.

Again I prefer to let it install and then change it later but you can change it here during the install process.

skitch.4

There are three pages of ports that WebSphere will use for different services.  Unless there’s a specific reason you can’t use one of the default ports I suggest leaving these as they are (in a “Typical” install you never see these screens).  If you must change them I would suggest only incrementing them by “1” until you get to a port number you are happy with.

skitch.3

On Linux and Windows you are presented with the option to add the Deployment Manager to run as a service when the server starts.  You don’t get that option for either the nodeagent or any of the application servers which you will have to add manually after all the install work is complete.

skitch.2

Finally I get the option to create an IHS server definition.  I will need to do this at some point since we are going to put IHS in front of our Connections servers but I haven’t installed IHS yet and so I’m going to leave this for later.

That’s our WebSphere install complete.  It should take anywhere from 15 mins to an hour depending on your disk write speed.

skitch.1

Once installed, if you have a GUI, you will see IBM Websphere on the Application menu. From here you can find the profiles that were created as well as create new ones and start or stop individual servers.

skitch

The above screenshot shows me checking the install completed successfully.

First I do an “ls” to see there are both profiles there.  The system shows me Dmgr01 (the deployment manager profile) and AppSrv01 (the application server profile).  That’s good.

Now I navigate to /opt/IBM/WebSphere/AppServer/Dmgr01/bin and run ./startManager.sh (note case sensitivity).  This should start the deployment manager from within its own profile.

Once it has started I want to check it’s listening and I know the deployment manager listens on port 9043 for the Integrated Solutions Console so I type

netstat -tulvn |grep :9043 to find if that service is listening.

We now have WebSphere installed.  If you are setting up multiple servers on different boxes you would now need to go and repeat the install but this time choosing to create only an Application Server profile on each of those boxes.  Remember to keep your WAS version on every server in your cell aligned at 8.5.5.6.

A WebSphere Primer..

Before you start installing WebSphere you should really understand some core concepts behind its architecture and options. This is going to make it easier to decide where and how to build servers.

Connections uses WebSphere 8.5.5 Network Deployment.  When you go to install your Connections applications you’re going to need at least one instance of WAS to install onto, however a single WAS install may be running multiple independent servers each running different applications. Our Connections environment could therefore be a single host machine with multiple WebSphere servers or multiple host machines each with single WebSphere servers.

Every WAS server must be installed into what is called a Node  and similarly each Node must exist inside what is called a Cell. For Connections101 I am building two “nodes” on two physical hosts with each running multiple WAS instances hosting different applications.

Each Cell has one process called a Deployment Manager whose job it is to manage the configuration settings and changes for all servers in its cell.

Each server then also has another parent process called the Node Agent. Its job is to talk to the Deployment Manager and receive the latest sync information (XML files) for the server it is managing. It’s also responsible for starting and stopping the server.  You cannot start any WAS server unless its corresponding node agent is also running.  You can’t stop any WAS server unless its corresponding node agent is also running.

Here’s an example diagram of how the architecture for Connections101 might be designed. In this design I have built a deployment manager and two separate nodes which are full clusters of each other.

WebSphereExamples

In WebSphere terms only individual servers need to be clustered, not entire nodes so I could easily just cluster the busiest components in my environment such as Cluster2 which contains search , homepage and profiles.  This is why it’s important to think about WebSphere design as well as the locations of the applications and which ones you may want to cluster, before starting the install.

The Deployment Manager directory holds XML files for every server.  It copies those files into the individual server directories when you Sync the servers.   You do all your configuration by logging into the administrative interface for the deployment manager (the Integrated Solutiions Console) and from there any changes push out to the managed servers.

Based on this there are important things to bear in mind

  1. Each server will have only one node agent
  2. Each node agent can manage multiple servers
  3. So from this we know that every single WAS cell will have, at minimum, one deployment manager, one node agent and the application server itself.
  4. Changes made to server configuration on the deployment manager will need to sync down to the nodes before the server itself will pick them up
  5. Syncing basically results in copies of the XML files for a server being sent from the Deployment Manager’s directory to the Server’s directory
  6. This means there will be at least 2 copies of every configuration file for a server, one owned by the Deployment Manager and one by the Server
  7. If you try and change a server setting in the Deployment Manager without syncing, the server won’t take the change
  8. If you try and change a server setting directly on the server without updating the Deployment Manager, it will be overwritten
  9. If you install the deployment manager and server on the same machine, it still has to sync to push out changes.  From a file system perspective, there are multiple copies of the same files.  If the servers are on different boxes the files will be too,  WAS is designed to work as if all servers are physically different and isolated from each other regardless of hardware infrastructure.  Sometimes you will be asked to locate a certain file, and you may find more than one.  It’s important to learn the locations of files and their purposes (i.e are you looking at the deployment manager’s copy of the file, or the servers’).  We will get to file locations in a later post.
  10. There are a lot of restarting servers required when working with WebSphere since server changes don’t just happen on the fly, they require a sync and a server restart to take effect as the XML files can be read as the server starts up.