- Installation Scenarios : WebSphere Install Architectures
- Web Server in DMZ
i. When ever anything is installed in the DMZ, the ports must be opened on the firewall, typically only Web Servers will be in the firewall and if SSL is enabled then port 443 is opened, or if SSL is not enabled then port 80 must be opened. Talk to Network guys to open the ports on the firewall.
- WAS v5
i. ND, Standalone ( NO PROFILES in v5 and no Embedded Messaging in V6 [ which uses JPM or Java Platform Messaging ] )
- WAS v6
i. ND, Standalone, Custom Profile
- Security
i. SSL
1. SSL between Browser and Web-Server
2. SSL between Web-Server and Application Server.
- Reverse Proxy
i. TAI
- Co-existence Scenario
i. When multiple installs of WebSphere are done on the same machine, then this scenario is called co-existence scenario. The major point to be noted during a co-existence scenario is the value for ports. Make sure that different ports are used, and if there is a conflict, resolve the conflict on the serverindex.xml.
- Using Load Balancer
i. Load Balancers are used to distribute traffic load, some examples are BIG-IP, F5 switches (hardware load balancer), these load balancers are often called as Network Dispatchers.
ii. Steps to take into account when using a load balancer
1. Talk to your network admin to create the load balancer rules, for example lets assume the alias created by your network admin is mywebsite, then map it to your web server host name and port on which the web server is running, here is an mapping rule table. Also remember when the alias name is created by the network admin it is to allow your customers to come in on port 80 and can be mapped to any web server port number [ Load balancer rule]
| S.NO | Network Dispatcher Alias/Host name | Web Server Host Name and Port |
| 1 | Hostname:10005 |
Also when ever an alias is created you need to add the alias to the virtual hosts in websphere. For instance in our example you will add mywebsite.com and port 80 as a host alias to the default_host or any other virtual host you have created. Also remember when ever you add anything to the virtual hosts you need to re-generate the plugin. Also when cluster members are created you will have to regenerate the plugin. Other scenario’s where plugin must be re-generated is during the application install, so that the URI’s are reflected in the plugin file. Its advised to add the IP address of the alias to the host alias of the virtual host too, just in case if people are using the ipaddress instead of the alias name.
- HTML Link
ii. Web-Server Plugin à http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/topic/com.ibm.websphere.nd.doc/info/ae/ae/tins_scenario5.html
iii. Overall Scenario à http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/topic/com.ibm.websphere.nd.doc/info/ae/ae/tins_scenario4.html
iv. Setting up the Application Server Environment (End-to-End) à http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/topic/com.ibm.websphere.nd.doc/info/ae/ae/welc6planning.html
- OS Pre-requisites
- SOLARIS à http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/topic/com.ibm.websphere.nd.doc/info/ae/ae/tins_solsetup.html
- AIX à http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/topic/com.ibm.websphere.nd.doc/info/ae/ae/tins_aixsetup.html
- Installation
- GUI Install à http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/topic/com.ibm.websphere.nd.doc/info/ae/ae/tins_customn.html
- Silent Install à http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/topic/com.ibm.websphere.nd.doc/info/ae/ae/tins_runSilent.html
- Steps to verify Installation
i. Run First Steps or ivt.sh/bat from ${WASHOME}/bin
ii. Log on to the admin console (Default port for WAS v6 is 9060)
iii. If Default Application is installed make sure you can access snoop (Default HTTP port for snoop is 9080)
iv. More Information on First Steps http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/topic/com.ibm.websphere.nd.doc/info/ae/ae/rins_firststeps.html
- Installation Trouble Shooting
i. Always look at the install log files, first and most important file to check for installation is log.txt in the ${WASHOME}/logs/log.txt
ii. Always look for these messages INSTCONFSUCCESS or INSTCONFPARTIALSUCCESS in the log files for successful installation. If you find the message INSTCONFFAILED then the installation failed.
iii. More on this topic @ http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/topic/com.ibm.websphere.nd.doc/info/ae/ae/tins_trouble.html
iv. Most Important look at the sub-topics section.
- Restarting the App Server automatically
i. Windows
1. As a Windows Service
ii. AIX, SOLARIS, LINUX
1. Run as UNIX service (rc scripts)
2. For an e.g look at an rc.was script in the ${WASHOME}/bin directory and talk to your UNIX SA, the idea behind this concept is just like windows, when ever the Physical machine is restarted the rc level 3 scripts will start WebSphere automatically.
- Creating Profiles
i. Profiles can be created either silently or using GUI.
ii. wasprofile command is used to create profiles in v6.0, but in 6.1 of WebSphere this command has been replaced by manageProfiles.sh/bat.
iii. Wasprofile has various options (Remember to replace .sh by .bat for windows)
1. To list profiles use wasprofile.sh –listProfiles
2. To create profiles use wasprofiles.sh –create
3. to delete profiles use wasprofiles.sh –delete
4. More Info on this command @ http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/topic/com.ibm.websphere.nd.doc/info/ae/ae/rxml_wasprofile.html
iv. Federation of nodes to DMGR
1. Scaling
a. Two kinds of scaling
i. Horizontal à Adding more nodes [Physical Machines]
ii. Vertical à Adding more JVM’s [ Application Servers] on the same node {WebSphere Node}
2. Clustering
a. Cluster Members can span across many machine [ Meaning can have any number of WebSphere Nodes, remember each WebSphere installation on different physical machine has a different node name]
b. Cluster Members do the same function.
c. Cluster members have weights to do load balancing, and can do round-robin or weighted round robin load balancing using the plug-on.
d. Cluster Member Scaling can be done either horizontal or vertical (Add more nodes and jvm’s on those nodes OR add more jvm’s to the same node).
3. Adding Nodes to the DMGR
a. Federation is done using the addNode command. When using this command we must user the deployment manager host name and soap port. [All administration for WebSphere is done using the SOAP or RMI port].
b. When nodes are added to DMGR, any admin console on the standalone profile/server is removed and the DMGR is used for administration.
v. Install the maintenance packages
1. All maintenance packages must be installed from the
2. Always maintenance package should be installed as root. Also WebSphere 6.0.x must be installed as root, or else IBM will not support it. But with WebSphere 6.1 can be installed as non-root. Also remember when ever installing GSK toolkit it should be installed as root, since it writes to the OS registry.
3. Always when installing updates you need to run the setupCmdLine.sh script.
4. More details on this install can be obtained from http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/topic/com.ibm.websphere.nd.doc/info/ae/ae/tins_ptfLevels.html
- WebSphere Operations and Administration
- Start/Stop Application Servers
i. Always start the servers in the following sequence
1. Start the Deployment Manager (startManager.sh)
2. Start the node agents next (startNode.sh)
3. Start the individual applications servers then.(startServer.sh
ii. Always stop the servers in the following sequence
1. Stop the application servers (stopServer.sh
2. Then Stop the node agents next (stopNode.sh)
3. Stop the deployment manager (stopManager.sh)
iii. Note: everything is similar to WebSphere v5, except that a new option of –profileName is supplied to these commands, and also you can start and stop the servers from the individual profile directories.
- Status of application Server
i. There are two ways to status the application server JVM’s
1. run serverStaus.sh
2. On Unix Systems (Linux, AIX, Solaris) run the ps command. E.g of the ps command is
a. ps –ef | grep java | grep ${WASHOME}, where WASHOME is the home directory of WebSphere.
- Backup and Recovery of WebSphere Configuration
i. WebSphere configuration directory alone can be backed up using the backupConfig.sh commands and restored using the restoreConfig.sh.
ii. For all other things like regular file system backup (directory where websphere is installed), you need to talk to your UNIX SA or the backup and job-scheduling team to run the regular disk backup, where they write the data to a tape drive. Some of the popular backup softwares are Control-M and FDR.
iii. It is advised to take backup of the configuration and application binaries (you need to tar you installedApps directory and run backupConfig.sh) when ever you do maintenance (Fixes, Fix Packs, Cumulative fixes, Refresh packs) etc.
- Sending Information about your WebSphere to IBM
i. Run the collector.sh script from the $WASHOME/profiles/bin and send the files to IBM
ii. Open an PMR with IBM using the 1-800-IBM-SERV directory
iii. Use your clients support account number
iv. Three kind of support tickets can be opened
1. SEV1 à production down
2. SEV2 à next level, where you can wait and is not affecting business
3. SEV3 à for all other issues.
v. Run the versionInfo.sh script to get the version level information
- Synchronizing WebSphere configuration in ND.
i. Run the syncnode.sh command, talk to the deployment manager using the SOAP port. Make sure your node agents are down when running these commands.
- WebSphere Administration Automation
i. Automation of WebSphere configuration can be done using the wsadmin and ws-ant.
ii. Refer to infocenter for basic wsadmin commands.
- Application Server Administration
i. Configuration of JVM from Admin Console
1. Memory Related Settings for JVM
a. Tuning the HEAP SIZES [MAX and MIN HEAP SIZES] à by default the max heap size is 256M for JDK 1.4 jvm’s. You can configure this setting on the console. You change this setting if your JVM runs out of memory (crashes). Typically when JVM’s crash due to an out of memory error, you will have heap dumps generated. Heap dumps are files which show all the java objects in the memory at the time of a crash. This file can be analyzed by experts using the Heap Analyzer provided for free on the IBM website (google it) or sent to IBM for analysis.
b. Turn on the verbose garbage collection. à turning on the verbose garbage collection so that more information about garbage collection is written to the native_stderr.log or native_stdout.log depending on the Operating System.[ For aix and linux its native_stderr.log and for Solaris its native_stdout.log]
2. Logging and Tracing
a. By default WebSphere writes the logs to ${PROFILE_HOME}/logs/${SERVERNAME}/ directory. (NOTE: always in v5 PROFILE HOME is the same as websphere home since there are no profiles in v5 WebSphere). The directory to which logs are written might need to be changed based on your client’s requirement, which can be configured from the Logging and Tracing.
b. Size of log files, number of files to be maintained can be configured here. This technique is called log rotation.
c. For web Server and applications you need to have your own implementation of log rotation.
3. Web Container Related Settings.
a. Thread Poolà If there is huge load on your website you might need to actually increase the thread pool size of the Web Container.
b. Session Management à Configuring Session Affinity and Session Persistence.
ii. Creating Clusters
1. Backup clusters can be created when creating a new cluster
2. Replication domains can be created.
- Application Administration
i. Applications can be deployed using the Install Application link.
ii. Each Application name has to be unique
iii. The context root of each application has to be unique or if the context root is same you have bind the web modules to different virtual hosts.
iv. When deploying EJB’s make sure the deployEJB’s options is checked [check this option if the EJB deploy tool was not run during assembly of application into EAR file è talk to developers].
v. Make sure you check the deploy WebServices option when deploying an ear file which has web services [ check this if wsdeploy has not been run earlier à talk to your developers ]
vi. When applications are installed to clusters, make sure the application server target is the name of the cluster, also when installing the application on different JVM’s other than server1 the server target is the name of the JVM.
vii. More about this topic @ http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/topic/com.ibm.websphere.nd.doc/info/ae/ae/trun_app_instwiz.html
viii. Application roles can be mapped using Map roles to users link after install or on the user role mapping screen during install.
ix. Make sure all the bindings (jndi names) are all on the ear file, if some thing is blank talk to your developer to get the jndi name to be used.
x. Read this for sure its application administration on v5 but very similar in v6. http://publib.boulder.ibm.com/infocenter/ieduasst/v1r1m0/topic/com.ibm.iea.was_v5/was/5.0/Administration/WAS50_AppAdmin/player.html?dmuid=20061227171528670927
- Resources Creation
i. Resources can be created at various scopes Cell, Node and Server. With WAS v6 you can create a resource at a Cluster level too.
ii. JDBC Providers
1. Creating ORACLE JDBC connection
a. Need the jar files for type 4 driver and the client for type 2 drivers [ called oci drivers]
b. Drivers can be downloaded from oracle website
c. Need to setup the oraenv file and source it in setupCmdLine.sh or the unix user profile to get the native libraries required for the oracle client. Your DB administrator will give the settings, copy and paste in a file. [Only for type 2 drivers].
2. Creating DB2 connection
a. Need the db2jcc jars for type4 drivers, and the db2client (install) and use the db2java.zip for type 2 drivers.
3. Similarly for other databases (mostly you might encounter for Sybase) à use the jConnect drivers for Sybase.
iii. JMS providers
1. Created for talking to external MQ or other JMS servers, most important things required are Queue Manager Name, queue manager port, queue manager host name.
2. When ever the application has MDB’s (Message driven beans) make sure to create listener ports under the server administration link for each jvm.
a. Create the message listener service firsthttp://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/topic/com.ibm.websphere.nd.doc/info/ae/ae/tmb_adm08.html
b. Create the listener ports next http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/topic/com.ibm.websphere.nd.doc/info/ae/ae/tmb_adm08.html
c. Start/Stop Listener Ports http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/topic/com.ibm.websphere.nd.doc/info/ae/ae/tmb_adm03.html
3. Using MQ as a JMS provider à Configuration on Console http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/topic/com.ibm.websphere.nd.doc/info/ae/ae/tmj_admrm.html
4.
iv. More on Resource Providers
2. Creating all the resource providers is very straight forward.
- Environment Management Link in WebSphere
- Virtual Host
i. Create new virtual hosts
ii. Define aliases
iii. When ever any changes are done to virtual hosts, the virtualhosts.xml is updated and the plugin has to be regenerated and websphere needs to be restarted.
iv. Also as indicated earlier in the document, when adding an alias or IP address for the network dispatcher, you need to add them to the host alias of the virtual host.
- Shared Libraries
i. There might be situations where multiple application run on websphere and all these applications use the same code base, in which case you will create a shared library, basically you create a shared library with a name and specify the classpath of the jar files which your application uses. Again your developer has to give this information.
- WebSphere Variables
i. Websphere variables are created to act as shortcuts of referencing a particular path on the physical system. Variables can be created at any level cell, node or server.
- System Administration in ND
- Default node synchronization interval is 1 minute, you can change this to a good number, so that there is less network traffic
- By default the node agent starts up any server when has been running and suddenly went down (for instance a JVM that crashed or was killed), you can disable this policy by going to the Application Serversà
à Java and Process Management à Process Definition à Monitoring Policy and disabled automatic restart option. Similar in v5 but the link is a little different. - Security
- When enabling global security, remember to disable java 2 security, unless required, in which case the server.policy file needs to be modified
- There are three types of User registries supported by websphere
i. LDAP
ii. LOCAL OS
iii. CUSTOM
- Each user registry mechanisms have their own merits and de-merits. Typically LDAP is the most recommended registry; some times you might find LDAP in QA and PROD, and custom user in dev.
- Local OS is not used much, since user id’s have to be maintained. Local OS authenticates using the OS user id’s who have a login to the machine.
- When configuring LDAP remember these points
i. You need to supply a server user id and password
ii. You need to supply an LDAP BIND ID and password (basically a login to LDAP)
iii. You need to specify the base DN to tell websphere where to start the search in the LDAP tree
iv. The LDAP host name and port number.
v. Typically in an ideal environment the advanced ldap settings don’t need to change, but if your ldap objects are a little different you may need to change the group and user filters.
- There are two authentication mechanisms available in websphere namely
i. LTPA (Light Weight Third Party Authentication)
ii. SWAM (Simple WebSphere Authentication Mechanism)
iii. SWAM supported only in standalone installs, cannot configure SSO (Single Sign ON) with SWAM.
- When using LTPA as the authentication mechanism, remember to supply the LTPA password.
- When configuring SSO, you need to use LTPA as the authentication mechanism. Also remember to specify the domain name when you configure SSO.
- When using a reverse proxy in your environment remember that you need to configure TAI (Trust Association Interceptor) so that websphere will not re-authenticate the user. Different kinds of reverse proxy in market are Webseal from IBM, Siteminder from Netegrity(CA), iChain from Novell. The vendor supplies the TAI code for Websphere.
- To disable security, when you can’t access the admin console, change enable=false on the security.xml
- When security is enabled all websphere administration commands require you to supply a user name and password, except for the start commands.
- Also when ever you enable security populate the soap.client.props and sas.client.props and run the PropsFileEncoder.sh to encode the plain text passwords in these files. Once you do this you need not supply any user id and password on any websphere administration commands. http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/topic/com.ibm.websphere.nd.doc/info/ae/ae/tsec_securepwds.html
- Exact syntax of PropFileEncoder.sh http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/topic/com.ibm.websphere.nd.doc/info/ae/ae/rsec_propfilepwdencoder.html
- Also console users/groups and roles can be created from the admin console and the admin-authz.xml will be updated. Remember any changes made to security configuration of websphere require a restart. To create the console user/group make sure that the user/group exists in the user registry (LDAP or LOCAL OS or CUSTOM).
- SSL à
i. Between IE (browser and Web Server)
1. need to use ikeyman to configure, and the key type is CMS
3. When ever you do this you need to get the CA root and intermediate certificates. The above link has reference to this.
4. REMEMBER, when you request for a CA signed certificate you will have to pay for it (in the sense the company has to), so you request certificates only for production and in some cases QA. FOR DEV AND INT you need to create self signed certificates using IKEYMAN. (Typically the CA will be verisign). Note in some cases your client/company will have a PKI interface to get the certificates for all environments talk to your team to find out more.
ii. Between Web Server and App Server
1. need to use ikeyman to configure, also you need two key types one is CMS and other is JKS.
iii. Between LDAP and WebSphere
1. need to use ikeyman to configure, again two keys required one is JKS for WebSphere and typically the LDAP team gives you the other certificate (required for LDAP) and you import it in WebSphere Key Store.
iv. Remember for SSL communication to happen, you need to exchange certificates, and certificates are always (most of the times) stores in key stores (like CMS or JKS). Once the certificates are exchanged (which means you have imported the certificate of the other server in your key store, then SSL communication can happen.
vi.
- Performance Monitoring
- Performance Monitoring in WebSphere is done using PMI (performance monitoring interface).
- In websphere v6 PMI is enabled by default on v5 you have to explicitly turn it on. Turning PMI is very simple, go to the Application Servers à
à Performance Monitoring Interface and check the enable PMI and set the level to Basic, etc, based on the level of monitoring required. - Remember turning PMI metrics on has a overhead from 2-5%.
- It is recommended to turn PMI on.
- PMI metrics can be seen using TPV (Tivoli Performance viewer) which is shipped by default with websphere. In version 5 of websphere TPV was a separate thick client (requires x11) and need to be started using the tperfviewer.sh. In Websphere 6, TPV is integrated in the console.
- Few handy things to look for from PMI are
i. Web container thread pools
ii. JDBC thread pools and JDBC use and wait time
iii. JVM memory
iv. Average response time of individual JSP’s and servlets
v. Number of concurrent invocations of JSP’s
vi. Number of Active and Live Sessions.
- There are also a bunch of third party monitoring tools available
i. Wily Introscope (more popular)
ii. ITCAM (IBM Tivoli Composite application manager).
iii. All you need to configure these tools are to install the agents on the machine which is running websphere, and install the manager (the one which collects data from these agents) on a different or same machine and configure the Application server machine to use the agents. Typically to do so you will modify the generic JVM arguments under the Application Server à ${SERVERNAME} à Java and Process Management à JVM à Generic JVM Arguments. Check with the vendor on the install docs.
- Plugin-Cfg specifics
- Plugin-cfg.xml uses the Server clone id to maintain the session affinity.
- Session affinity/Server Affinity which is the same in this case means re-routing to the same server.
- Plugin marks the JVM unavailable if the JVM is down for maintenance or if the JVM crashed, so the users don’t get an error page.
- Some HTTP return codes
i. 404 à means user is requesting for a page which is not available
ii. 500 à typically means the Websphere Application server serving the http request is down.
- Plugin can be re-generated from the command line using GenPluginCfg.sh from the bin directory of Websphere.
- IHS Specifics
- Uses the httpd.conf as the configuration file and reads it when it starts up
- When installing the plugin, the plugin installation configures the IHS to use the right plugin file.
- In case of a network deployment / if the plugin was installed remotely (App server and plugin + web server on a different box), then you need to manually edit the httpd.conf and add the load module line for loading the plugin binary and also point to the right plugin-cfg.xml file.
- Remember to copy the plugin-cfg.xml when regenerating the plugin to the web server node.
- Just like the application server (Websphere), you can also create virtual hosts on the webservers too.
- Virtual hosts are used for logical separation of applications.
- Application Isolation
- Application can be isolated in several ways
i. Install application on separate websphere instances (more than one install of websphere)
ii. Create separate profiles using the same websphere install (issue here is when patching all profiles will be patched, since they share the binaries).
iii. Create separate JVM’s for each application (best scenario if you are having ND).
iv. Create separate virtual hosts.
v. Some cases (you can do steps 11.(a).(iii) and 11.(a).iv) together which is the best way)
- Trouble Shooting
- Divide and Conquer
i. Always take one product at a time to test, for instance first try to test the application using the Websphere Internal transport ports, if the application is responding then test with the Web Server port, and if the application is not responding then you know the issue is on the web server or the plugin.
ii. Try to isolate the problem, and take baby steps during trouble shooting.
iii. SystemOut.log and SystemErr.log are the most important log files which gives the JVM information (Run time)
iv. Garbage collection information is written to the native_stdxxx.log based on the OS.
v. FFDC is used by IBM for troubleshooting.
- Also make sure there are no issues with the backend components
i. E.g. LDAP, DB, etc (for DB you can do a test connection from the console, for LDAP you can try to login to the admin console).
ii. Eliminate network related issues by using tools like ping, telnet etc.
iii. Enable Tracing as per IBM’s supports advice. Remember tracing has a lot of overhead so do not enable tracing till IBM suggests you do.
iv. Make sure the application and the application servers started with no issues.
v. In case of errors first look for any stack traces or errors on the SystemOut.log and SystemErr.log.
vi. Take a thread dump when application server hangs do a “kill -3 PID of app server” ( you can find the PID from the file
vii. Turn on heap dump generation during an out of memory error.
viii. Follow the links for MUST GATHER INFORMATION TO SEND TO IBM DURING HANG AND HEAP DUMP SCENARIO, here is an example (search on google or ibm.com)
1. search string “ must gather hung thread aix”
2. “must gather hung thread solaris”
3. “must gather out of memory conditions”
ix. enabling AUTOMATIC heap dump only on v6+ http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/topic/com.ibm.websphere.base.doc/info/aes/ae/tprf_enablingheapdump.html?resultof=%22%65%6e%61%62%6c%65%22%20%22%65%6e%61%62%6c%22%20%22%68%65%61%70%22%20%22%64%75%6d%70%22%20
x.
- Generic Information
- LPARs à logical partitions in the unix machines.
i. Each LPAR can have a unique host name and IP address.
ii. In solaris terms LPAR can be called as domains or zones.
- File Systems
i. Directories in Unix, but is independent of other directories/file systems. Advantages of file systems are if this file system runs out of disk space it will not affect other unix process which require disk space.
ii. Typically install websphere on its own file system. Also create a separate file system for the logs. (File systems are created by your UNIX SA).
- Machine Names
i. IBM pSeries (p570 and p595) à used for AIX mainly.
ii. FUJITSU à t2000 servers (for running solaris typically)
- Security Issues
i. From an OS perspective nothing should be running as root, so in this case after you install WebSphere as root, make sure you follow this document (find Link below) to make websphere run as non-root. When running as non-root choose a good user id and group id to run websphere as, and talk to your unix admins to create the user and group ids. Here is the link/document to follow when configuring websphere to run as a non-root user. http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/topic/com.ibm.websphere.nd.doc/info/ae/ae/trun_svr_nonroot.html?resultof=%22%72%75%6e%6e%69%6e%67%22%20%22%72%75%6e%22%20%22%77%65%62%73%70%68%65%72%65%22%20%22%77%65%62%73%70%68%65%72%22%20%22%6e%6f%6e%2d%72%6f%6f%74%22%20
ii. Give you ip address to a unix SA, and run a X11 client software like reflection, or hummingbird and the UNIX SA will shoot a window to your IP Address with root privileges and then you can do the install.
iii. You can login to a unix terminal using
1. telnet (mostly blocked in many places)
2. ssh ( your best bet). à a free ssh client for windows is putty.
iv. Uploading files/Copying files to remote servers can be done in two ways
1. scp (secure copy) inside the company,
2. ftp or sftp ( outside company or inside company)
- Change Management Process
- Change management is a process by which all the people involved in supporting and maintaining the applications, including the various managers are aware of any new changes that go into the environment. For .e.g when a new application is to be deployed in production, it has to be first deployed in DEV, then QA and then Production, while deploying to production a ticket is created letting the groups involved to know about the new application which will be deployed in the environment during a particular time frame, for instance between Friday 6pm- 9pm, during this time the teams will co-ordinate with the Admins to deploy the application, inform the business clients about an outage during this window. This time frame is called a “DEPLOYMENT WINDOW”. Patching also follows the same process. Some of the change management tools available in the market are
- As administrators you people must know how to use the change management tool (get a login) and make sure the ticket status is approved and you co-ordinate will all the various groups involved in the change.
- SLA’s and Operational Procedures
- Administrators always need to stick to the
- Always make sure the term “STANDARDS” is used and followed. Standards are nothing but a set of rules defined by your team for installation of websphere. Some handy standards are
i. WebSphere will be installed as root, but will run as non-root.
ii. Websphere will be installed on its own files system
iii. WebSphere logs will be on a separate file system
iv. All JVM that are created will follow a naming convention, for instance lets say you have a new application called Credit Monitoring that needs to be deployed on a new JVM, you will create a JVM called Credit-Monitor (basically something that makes sense).
v. The websphere file system will have permissions of 754 always.
vi. All patches and maintenance (including application updates) will be certified (meaning it will first be installed on dev, then qa and once you get the approval you will open a change management ticket and then install on production).
vii. Developers will be given access to production logs and will have websphere monitor ID’s only on the console.
- 6365945516 george
- kshetty@somaflexsoftware.com references 516 633 0595
dani…..srinivas
No comments:
Post a Comment