IBM WebSphere Application Server Network Deployment Edition

Windows Azure Installation and Support Guide

This guide will provide step by step instructions how to start using the installed products on your Azure instance.

1. Launching an instance

In order to launch IBM WebSphere Application Server (referred as WAS), a few settings need to be configured on the Azure console as follows:
  1. Open new Azure Virtual Machine wizard;
  2. Select the IBM WAS Azure image based on your requirements from gallery;
  3. Choose VM name, size, Authentication user and credentials. The Standard A2/medium type or larger is recommended when running IBM WebSphere Application Server Network Deployment with a Deployment Manager and Node Agent profile on the same instanceBasic A2 is the minimal requirement, which will be sufficient to run only one Node Agent or Deployment Manager profile. Larger instances may be required based on the number of IBM WebSphere application servers, clusters etc required and the expected resource use of each;
  4. Define cloud service DNS name, Regions and open endpoint ports.
Port 22 to connect via SSH (enabled by default),

Port 9060 to reach the IBM WAS administration Web Application (Integrated Solutions Console),

Port 9090 to reach RapidDeploy web console, 

Port 20000 and 20100 to open for RapidDeploy Remote Agent (optional), - In the scenario where you want to use the Deployment manager with remote node agents, you will need to open further ports used by IBM WebSphere network communications, usually in a range of 25 ports starting from the unsecured web console port (By default 9060-9085). You can check the ports required on your running IBM WebSphere console. FAST PATH: Specify a security group that opens all TCP ports from Anywhere

2. Getting started with RapidDeploy and IBM WebSphere using the setup wizard (firstrunsetup.sh)

2.1 Initial configuration

The IBM WebSphere Application Server Network Deployment Edition products are shipped with a base binary installation, without having any profiles created. On the first login to the instance, you will be placed into a console wizard, which will guide you through the process of creating IBM WebSphere Network Deployment profile(s). The following is an overview of the steps you will be guided through to create the required profiles on the instance:
  1. Log onto the instance via SSH with your Azure user and credentials.
  2. Once the admin user is logged in, please log in as the  ‘midvision’ user via the command 'sudo su - midvision'.
  3. You are placed in a setup wizard.
  4. Choose whether to install a Deployment Manager profile,
  5. Choose whether to install a Node Agent profile
  6. Set initial password for RapidDeploy user "mvadmin"
  7. Choose which ports to open on Red Hat Linux firewall
All inputs asking for specific data can be left as blank just by hitting [return], which will pick the default value displayed at the end of the question. Once the product is started and configured, you can reach it by default on http://[publicip]:9060/ibm/console and log in unauthorized.
Please note that in order to keep your WebSpshere server working after an instance restart/stop&start, you will need to re login as midvision user and the new IP will be autoupdated. 
If the hostname of the instance changes after the profiles are created, it will break the WebSpshere server connectivity. 
In case of localhost binding, your Dmgr will not be extendable with remote node agents. 

2.1.1 Creating the Deployment manager profile

You will be prompted to enter the following values, or accept the defaults:
  • dmgrHostName: the host name binding for the deployment manager profile. This resource has a default value of the current public host name of the instance. You are strongly recommended to assign an elastic IP address for the instance before proceeding with the deployment manager profile creation.
  • cellID: the id of the WebSphere cell containing the profile
  • startingPort: the WebSphere service ports will be incremented from this number, assigning each unused ports to the WebSphere services.
  • profileName: the name of the profile to create

2.1.2 Creating the Node agent profile

You will be prompted to enter the following values, or accept the defaults:
  • nodeAgentHostName: the host name binding for the Node Agent profile. This resource has a default value of the current public host name of the instance. It is strongly recommended to assign an elastic IP address for the instance before proceeding with the node agent profile creation.
  • nodeAgentStartingPort: the WebSphere service ports will be incremented from this number, assigning each unused port to the WebSphere services.
  • nodeAgentCellID: the id of the WebSphere cell containing the profile
  • nodeAgentAdminUserName: the username to authenticate against the deployment manager (if required)
  • nodeAgentAdminPassword: the password to authenticate against the deployment manager (if required)
  • nodeAgentProfileName: the name of the profile
  • dmgrHostName: the host name the deployment manager is running at. This resource has a default value of the current public host name of the instance. If necessary,change this to the hostname, IP or DNS of the remote Deployment Manager instance. Note that if you use a remote deployment manager host, you will need to make sure all the required ports are open on both machines.
  • dmgrPort: the deployment manager SOAP connector port to connect to for the purposes of federation and subsequent synchronisation.

2.1.3 Changing RapidDeploy initial password

For security reasons, you will need to change the default password (default value is 'mvadmin') for user mvadmin. This will be requested the first time only when you log in to the instance.

2.1.4 Opening firewall ports

You can open the necessary ports quickly using the initial setup wizard or the openwasports.sh script. Port 9090 will be automatically opened for RapidDeploy web console, also the IBM WebSphere web console port will be opened if Deployment manager profile is created through the wizard. Further ports on the Red Hat Linux firewall can be opened by typing port numbers. There is an option to open all ports used by IBM WebSphere services, by entering 'process' input. Alternatively, you can choose to open all ports on the instance by entering 'all' input. If you are creating a distributed cell over multiple nodes, we strongly recommend you don’t try to estimate which ports should be opened, but select the ‘process’ option, which will open all the required ports to ensure node agent synchronisation will work correctly. Port opening options:
  • <port number> - Open this port. Multiple ports can be entered, separated by pressing the ‘return’ key. 
  • process’            - Open all WebSphere ports for all WebSphere processes detected on the instance. 
  • all’                    - Open all ports on the instance (effectively remove the firewall).
  • exit’                  - Exit the port opening script.

2.2 Post install login

When logging into the instance after the first time, you will be asked if you need to reassign the bound hostnames in the IBM WebSphere configuration. You will need to do this if you have not used elastic IP addresses, and you have stopped and started your instance. In this situation, your instance will probably get a new IP address, whereas the IBM WebSphere configuration still references the old host name of the instance in the deployment manager and node agent profile configurations. In order to fix this issue, you can run the fixhosts.sh script provided in the midvision user home directory, which will search and replace for the old host name occurrences in the configuration files. See the section below for detailed instructions running fixhosts.sh

2.3 RapidDeploy

RapidDeploy server and agent will start up automatically when you start your instance. You can access the web console on http://[publicip]:9090/MidVision Note: make sure you have port 9090 open in your Security group when trying to access RapidDeploy web console. For the first time, you can set the password for the default username "mvadmin". You can prevent auto starting RapidDeploy on instance startup by removing it from the system chkconfig list. 
[midvision@ ] sudo chkconfig --del rapiddeploy

3. Accessing the instance via SSH, files, scripts, technical info

3.1 Logging into the instance

Once the instance has started up (you can see it by having "Running" status in Azure console). You can connect to the instance via any SSH client. You can log in to your instance with provisioned Azure username  and the credentials which can be based on password or certificate file.

3.2 Users

  • azureuser: This is the provisioned Azure user. The username can vary due to can be customised. It is permitted to use all SUDO rights. To switch to the midvision user, type "sudo su - midvision".
  • midvision: This is the midvision user, You can log in as any other user without using passwords. E.g: "su wasadmin". To switch to the root user, type "sudo su". If you want to switch back to root user, type "exit", this will take you back to the previous user session.
  • root: This is the superuser in linux systems. You can log in as any other user without using passwords. E.g: "su -azureuser", "su wasadmin", "su midvisionIf you want to switch back to root user, type "exit", this will take you back to the previous user session.
  • wasadmin:  This user does not have SUDO rights. If you want to switch back to root user, type "exit", this will take you back to the previous user session.
  • mbadmin:   This user does not have SUDO rights. If you want to switch back to root user, type "exit", this will take you back to the previous user session.

3.3 Provided post-install scripts

Scripts are provided in the midvision home directory, as detailed in the following sections:

3.3.1 Opening CentOS Linux firewall with the open-firewall.sh script

CentOS instances are shipped with a firewall by default to protect your machine. For security reasons, the instance is only accessible via SSH (port 22) at first, so further ports can be opened on the firewall as needed. You will need to open all the ports in this internal firewall, which you have open in your Security group. There is a script placed in the user home of midvision (/home/midvision), which is also the starting location when logged in. You will need to be the root user to run this script. Example usage:
[midvision@ ] sudo ./open-firewall.sh 9090 Open firewall port 9090 iptables: Saving firewall rules to /etc/sysconfig/iptables:[ OK ]

3.3.2 Open IBM WebSphere ports with the openwasports.sh script

This script is run as part of the first run setup to open DeploymentManager and Node Agent ports if the ‘process’ option is specified. This script should be run if the firewall is active and you create any new IBM WebSphere application servers, clusters, node agents etc that need to be accessed from outside the instance. The script will find and open any necessary firewall ports to ensure the WebSphere JVM’s can be accessed from outside the instance. Run the script on all instances hosting the new application servers or clusters.

3.3.3 Changing hostname or IP address for restarted non-elastic IP instances with the fixhosts.sh script

If you restart your instance(s), your instance(s) might get new IP address(es), whereas the IBM WebSphere configuration still references the old host name of the instance in the deployment manager and node agent profile configurations. In order to fix this issue, you can run thefixhosts.sh script provided in the midvision user home directory, which will search and replace for the old host name occurrences in the configuration files. See the section below for detailed instructions running fixhosts.sh

3.3.3.1 Example changing IP addresses in a distributed system

Please see below for the example steps for the case where a Deployment Manager and remote Node Agent instance are both stopped and restarted without an elastic IP address: Take a note of the four IP addresses: the original deployment manager host (referred as oldDmgrHost), the original node agent host (ref oldNodeagentHost), the current deployment manager host (ref newDmgrHost), the current node agent host (ref newNodeAgentHost)
  • Record [oldDmgrHost] and [oldNodeagentHost] addresses
  • Start DMGR instance - get a [newDmgrHost] instance address
  • Login to Dmgr instance - You will be prompted for [oldDmgrHost] and [newDmgrHost] host to replace. Answer and run.
  • Start NodeAgent instance - get a [newNodeAgentHost] instance address
  • Login to NodeAgent instance - You will be prompted for [oldNodeagentHost] and [newNodeAgentHost] host to replace. Answer and run.
  • On Dmgr host , run sudo ./setuphost.sh, entering the [oldNodeagentHost] and [newNodeAgentHost]
  • On NodeAgent host, run ./setuphost.sh, entering the [oldDmgrHost] and [newDmgrHost]
  • Restart the NodeAgent
  • In the AdminConsole, run a full resynchronise from System Administration -> Nodes -> Select the nodes and click “Full resynchronise"

3.4 Starting and stopping RapidDeploy manually

To restart RapidDeploy manually from the filesystem, use the rapiddeploy linux service. The RapidDeploy version is 3.4.9. RapidDeploy home is located at /var/rd/midvision Example usage:
  [midvision@ ] sudo service rapiddeploy start [midvision@ ] sudo service rapiddeploy stop 
The RapidDeploy server uses an in-memory database, so your RapidDeploy framework needs to be shut down properly to save your work. This happens when the instance is stopping or when calling the stop service manually from the command line. Note that on instance restart, unsaved data will be lost.

3.5 Files used for DevTestCloud services

There are a few scripts and other files in midvision and root users home directory, which will need to remain unchanged in order to keep the provided scripts working. Files are placed under /root/WAS_install are required to create the IBM WebSphere profiles. There are a set of scripts in midvision home directory. Those scripts are executed when logging into the instance controlled by .bash_profile, but you can also execute them manually whenever they are needed. There are some hidden files used as well,

.firstrun indicates that the setup wizard has already ran once,

.dontask indicates that the user will not be prompted again for running the setuphost script (if chosen not to ask again),

.host file is needed to determine the previously bound hostname to WebSphere service.

4.0 Troubleshooting

4.1 Session loss during setup

If you lose your SSH connection to the target instance during the first run setup script execution (e.g. as a result of a network problem), we advise you to delete and recreate the EC2 instance and run the script again.

4.2 Profile startup exceptions

If the profile fails to start with the startmanager.sh or startnode.sh commands, check that you are running as the root user, either by being in a root shell, or by prepending ‘sudo’ to the start command.

4.3 Cannot access the IBM WebSphere admin console (ISC)

Check that  the deployment manager is running, and you have correctly opened all the required ports on the firewall, and that your instance was created using a security group definition that allows TCP access to the instance on the required ports.

4.4 Contacting MidVision support

Please visit our support website.