Most applications must eventually deal with increased workload; some will scale up by adding more memory or CPU to a server and others will scale out by adding more nodes and servers to handle the application load. Here, we're going to cover some of the basic principles to scale your application running on WebLogic Server and understand how to leverage services offered by the container among other tools and products of the WebLogic Suite, such as Coherence.
Scalability is the main theme of this chapter, but inherent in that is high availability; this is a technique to ensure that your application will keep running with an acceptable response time, even when multiple aspects may try to compromise its scalability; for instance, having a huge number of users accessing your application at a given time or simply when one of your servers fail and you need to redirect all requests to the only working node.
To start, we are going to check out the tools and services WebLogic provides to help you manage more than one server and the kinds of changes that can be applied to an application to scale it up.
One of the first changes we need to do in order to scale an application is to make the environment where it runs more flexible to accommodate the necessary changes, which usually involves creating WebLogic components such as clusters, servers, and machines. In order to interact with multiple (remote) machines, it's recommended that you set up the WebLogic Node Manager process. The Node Manager is a small Java process that runs standalone and can perform basic operations on WebLogic Server instances like start, stop, and restart.
Until Version 12.1.1, you could have only one Node Manager running on a specific machine and all requests to start or stop Managed Server applications from different domains were sent to it. The concept is really nice, having just one component running to deal with all resources available on that machine. But things would usually get tangled and this topology proved hard to maintain; for instance, different domains are managed by different groups, each having their own patching and downtime schedule.
So, starting with Version 12.1.2, Node Managers are attached to a domain. The most notable effect of this change is that now the script to start the Node Manager is located inside the domain $DOMAIN_HOME/bin/startNodeManager.sh on our environment.
As the Node Manager is now part of the domain, all we have to do to enable it is fire up its start script using the following steps:
- Open a command shell and go to the folder
$DOMAIN_HOME/bin. - Run the
startNodeManager.shscript (orstartNodeManager.cmdin Windows) and it's done.
The script will output several items of configuration information and the most relevant is the last one, stating that our domain is mapped by it:
Domain name mappings: tickets -> /opt/packt/domains/tickets