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.
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
- Each server will have only one node agent
- Each node agent can manage multiple servers
- 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.
- 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
- 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
- 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
- If you try and change a server setting in the Deployment Manager without syncing, the server won’t take the change
- If you try and change a server setting directly on the server without updating the Deployment Manager, it will be overwritten
- 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.
- 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.