What addNode does

What addNode does

The addNode command adds a new node to an existing administrative cell.
The actions the command performs are:

1. Connects to the deployment manager process. This is necessary for the file transfers performed to and from the deployment manager in order to add the node to the cell.


2. Attempts to stop all running application servers on the node.


3. Backs up the current stand-alone node configuration to the


4. <profile_home>/config/backup/base/ directory


5. Copies the stand-alone node configuration to a new cell structure that
   matches the deployment manager structure at the cell level.


6. Creates a new local config directory and definition (server.xml) for the node
   agent.


7. Creates entries (directories and files) in the master repository for the new
   node’s managed servers, node agent, and application servers.


8. Uses the FileTransfer service to copy files from the new node to the master
   repository.


9. Uploads applications to the cell only if the -includeapps option is specified


10. Performs the first file synchronization for the new node. This pulls everything
    down from the cell to the new node.


11. Fixes the node’s setupCmdLine and wsadmin scripts to reflect the new cell
    environment settings.


12. Launches the node agent.

What removeNode does

What removeNode does

You can remove a Node using either the WAS Admin Console or using command line .
The command performs the following operations:

1. Connects to the deployment manager process to read the configuration data.


2. Stops all of the running server processes of the node, including the node agent process.


3. Removes servers in the node from clusters
   
   .


4. Restores the original stand-alone node configuration. This original configuration was backed up when the node was originally added to the cell. When a node is removed, it is restored to its original configuration,except when it was added to the cell.


5. Removes the node’s configuration from the master repository of the cell. The local copy of the repository held on each node will get updated at the next synchronization point for each node agent. Although the complete set of configuration files are not pushed out to other nodes, some directories and files are pushed out to all nodes.


6. Removes installed applications from application servers in the cell that are part of the node being removed.


7. Copies the original application server cell configuration into the active configuration.

wsadmin script for creating cluster and adding cluster members

You can use this Jython script to create cluster and add members to it

AdminTask.createCluster('[-clusterConfig [-clusterName samplecluster] -replicationDomain [-createDomain true]]')

AdminTask.createClusterMember('[-clusterName samplecluster -memberConfig [-memberNode dmgrNode01 -memberName SampleMember1 -memberWeight 2 -replicatorEntry true] -firstMember [-templateName "Sample Template" -nodeGroup DefaultNodeGroup -coreGroup DefaultCoreGroup]]')

AdminTask.createClusterMember('[-clusterName samplecluster -memberConfig [-memberNode sunpatilNode02 -memberName SampleMember2 -memberWeight 2 -replicatorEntry true]]')

This script creates samplecluster by calling AdminTask.createCluster command and then creates SampleMember1 as cluster member using AdminTask.createClusterMember call. The AdminTask.createClusterMember is made for adding additional cluster members

Managing cluster member

Managing cluster member

After creating a cluster you can add members to it by following these steps

• In the WAS Admin Console, go to Servers - cluster - cluster_name


• On the cluster configuration page, expand the Cluster Member section like this

• Click on the details button to get cluster members listing. You can either add or remove cluster members from this page


• I want to create additional server on SunpatilNode02, so i did enter necessary information on the next page

• On the summary page click finish and it starts adding cluster member


• Once the cluster member is added you can verify the updated cluster topology

Creating cluster

Creating cluster

Clusters consist of one or more application servers grouped together for Work load management. All the members in the cluster will have same set of application and similar configuration.

The way cluster creation works is you need to have one server which will act as Template server or you can create first cluster server based on existing template and then cluster creation process will take care of creating other servers based on the first server. Other servers can be on same machine (Vertical scaling) or on different machine(Horizontal scaling)

I wanted to create a cluster in which one server instance will be on the same machine as DMGR and other server will be on a separate machine. I already created a custom profile on separate machine and federated it to the DMGR so my node agent on machine 2 is ready.

• Now go to the WAS Admin Console and Server - Cluster and click on New


• On the first page it will ask you for Cluster Name so i entered Sample Cluster i did check the Configure HTTP Session memory-to-memory replication because i want distributed session support

On the next page it will ask you information for the first cluster, This member will act as template for all other clusters. In my case instead of choosing existing server i choose to create new Server based on Sample Template

 

 On this page it will ask us to add additional cluster member i want to create one server on sunpatilNode2 so i selected that node and set SampleMember2 as server name

 

On the summary page just click finish so that the cluster creation process can start

 

It will take few minutes but once the cluster is created you can look at the details of the cluster by going to Server - Cluster - cluster_name tab.

 

You can take a look at the topology of the cluster by going to Local topology tab
 

WebSphere Naming architecture

WebSphere Naming architecture

WebSphere Application Server

name servers are an implementation of the CORBA CosNaming interface. WebSphere Application Server provides a JNDI implementation that you can use to access CosNaming name servers through the JNDI interface. CosNaming provides the server-side implementation and is where the name space is stored. JNDI essentially provides a client-side wrapper of the name space stored in CosNaming, and interacts with the CosNaming server on behalf of the client.

I copied this diagram from System Management Handbook red book, that explains the Naming service architecture

 

wsadmin script to print namespace

wsadmin script to print namespace

You can dump namespace of a managed process i.e. either DMGR, NodeAgent or Server using dumpNamespace tool. Other option is to use the following wsadmin script

def printNameSpace(processname):
 print "Printing name space for " + processname
 nameserver =AdminControl.queryNames("*:*,type=NameServer,process="+porcessname)
 print AdminControl.invoke(nameserver,"dumpServerNameSpace",'["-report long"]')   

printNameSpace('dmgr')

The printNameSpace command takes name of the process as argument and generates dump which is same as the output of the dumpNameSpace for that process 

JNDI dumpNameSpce

The dumpNameSpace tool is used to dump the contents of a name space accessed through a name server. The tool can be run from the websphere_root/AppServer/bin directory in a command

JNDI dumpNameSpce

The dumpNameSpace tool is used to dump the contents of a name space accessed through a name server. The tool can be run from the websphere_root/AppServer/bin directory in a command



Important Note: The dumpNameSpace command line utility does not dump java: or local: name spaces. These name spaces, along with the server: name space, can be dumped using a Managed Bean (MBean) called NameServer

Naming service feature

The following are features of a WebSphere Application Server V6 name space
that remain unchanged from WebSphere Application Server V5:

• Distributed name space: For additional scalability, the name space for a cell is distributed among the various servers. The deployment manager, node agent, and application server processes all host a name server. The default initial context for a server is its server root. System artifacts, such as EJB homes and resources, are bound to the server root of the server with which they are associated.


• Transient and persistent partitions: The name space is partitioned into transient areas and persistent areas. Server roots are transient. System-bound artifacts such as EJB homes and resources are bound under server roots. There is a cell persistent root, which can be used for cell-scoped persistent bindings, and a node persistent root, which can be used to bind objects with a node scope.


• Federated name space structure: A name space is a collection of all names bound to a particular name server. A name space can contain naming context bindings to contexts located in other servers. If this is the case, the name space is said to be a federated name space, because it is a collection of name spaces from multiple servers. The name spaces link together to cooperatively form a single logical name
  space.
  The name space for the WebSphere Application Server V6 cell is federated among the deployment manager, node agents, and application servers of the cell. Every server process hosts a name server. All name servers provide the same logical view of the cell name space, with the various server roots and persistent partitions of the name space being interconnected by means of the single logical name space.



• Configured bindings: Administrators can configure bindings into the name space. A configured binding is different from a programmatic binding in that the system creates the binding every time a server is started, even if the target context is in a transient partition.


• Support for CORBA Interoperable Naming Service (INS) object URLs WebSphere Application Server contains support for CORBA object URLs (corbaloc and corbaname) as JNDI provider URLs and lookup names

 

 

 

 

Virtual Host

A virtual host is a configuration enabling a single host machine to resemble multiple host machines. It consists of a host alias or aliases, which consist of a host name and a port number. If you specify an asterisk (*) as a host name, all host names and IP addresses that the Web server can receive will be mapped to that virtual host.
There are two virtual hosts defined during installation: default_host and admin_host.

• The default_host virtual host is intended for access to user applications, either through the HTTP transport or through a Web server. At installation time, it is configured as the default virtual host for the server1 application server. It is configured to match requests to ports 80, 9080, and 9443 for any host name.


• The admin_host virtual host is used for access to the WebSphere administrative console. It is configured to match requests to the secure ports 9090 (HTTP transport) and 9043 (Web server) for any host name.


• The proxy_host virtual host includes default port definitions, port 80 and 443, which are typically initialized as part of the proxy server initialization. Use this proxy host as appropriate with routing rules associated with the proxy server.

When you install an application, you associate a virtual host with each Web module in the application. By associating a virtual host with a Web module, requests that match the host aliases for the virtual host should be processed by servlets/JSPs in this Web module. The Web server plug-in also checks the URI of the request against the URIs for the Web module to determine whether the Web module can handle them or not.

A single virtual host can be associated with multiple Web modules unless each application has unique URIs. If there are same URIs among applications, different virtual hosts must be created and associated with each of the applications.