IBM HTTP Servers 6.1 and 7.0 take advantage of Apache's virtual hosting feature but having all of your virtual sites in one IHS server means all virtual hosts must be turned off to stop the http server resulting in outages or reduced capacity for all sites sharing that IHS instance. There is an unofficial way to use isolated IBM HTTP server processes to get the job done. We can build isolated independant configurations for the HTTP server which you can be stop and start without impacting another shared application on the same server. This configuration is largely unsupported by the DMGR console and must be configured at the command prompt level. The information within is an unsupported hack and should not used for production runs.
The first step is to build the HTTP server config. A more elegant file naming method than what is shown in the linked document involves creating descriptive application folder locations for each virtual application so you could have conf/app_marketing/httpd.conf, log/app_marketing/access_log, and /app_marketing/index.html but for brevity, I will just number the instances in this guide. This approach is successful if the new http server is defined with isolated files and folders such as cgisock, sidd, ./htdocs2, etc. for its own run. Copy your httpd.conf to httpd2.conf, then make all the edits shown in the build document so the web server has unique ports/IPs, folders, and files it needs for run time. You will perform a second round of steps using the deployment manager after the command line tasks are completed. Note that the deployment manager is a repository and the plugin data will be overwritten by it so the webserver1 data is used only to make sure its starts without errors. You could leave the folders blank and test after all steps are completed.
After all of the command line configuration is completed, you should test the web server to see if it works using curl, wget, or a browser. The web server should be started if you used the build document. Since webserver2 is a copy of webserver1, testing static content using your favorite testing tool is a better idea. Some web apps keep all static content in the enterprise application resource so check your access and error log files to ensure requests are coming through and they are logged.
You may further test the J2EE application if your virtual host (vhost) already enables the new server's hostname and port combination to run the application. This example doesn't show such a configuration but if you are removing an existing vhost and using this guide to isolate it then, a curl test on the application would work smoothly at this point because the definition would already exist in the plugin file.
Move on to the next step ff the new web server, webserver2, passes these basic tests.
The web server is working but it is just a copy of the data in webserver1 and since you wanted process level isolation for a different application so you must also go to the Deployment Manager to make the application specific changes, pushing out the remaining configuration from the management console. After all shell level configuration is done, proceed to the WebSphere deployment manager in System Administration -> Nodes. Create an unmanaged node pointing to the host of the http server.
The first step is to build the HTTP server config. A more elegant file naming method than what is shown in the linked document involves creating descriptive application folder locations for each virtual application so you could have conf/app_marketing/httpd.conf, log/app_marketing/access_log, and /app_marketing/index.html but for brevity, I will just number the instances in this guide. This approach is successful if the new http server is defined with isolated files and folders such as cgisock, sidd, ./htdocs2, etc. for its own run. Copy your httpd.conf to httpd2.conf, then make all the edits shown in the build document so the web server has unique ports/IPs, folders, and files it needs for run time. You will perform a second round of steps using the deployment manager after the command line tasks are completed. Note that the deployment manager is a repository and the plugin data will be overwritten by it so the webserver1 data is used only to make sure its starts without errors. You could leave the folders blank and test after all steps are completed.
After all of the command line configuration is completed, you should test the web server to see if it works using curl, wget, or a browser. The web server should be started if you used the build document. Since webserver2 is a copy of webserver1, testing static content using your favorite testing tool is a better idea. Some web apps keep all static content in the enterprise application resource so check your access and error log files to ensure requests are coming through and they are logged.
You may further test the J2EE application if your virtual host (vhost) already enables the new server's hostname and port combination to run the application. This example doesn't show such a configuration but if you are removing an existing vhost and using this guide to isolate it then, a curl test on the application would work smoothly at this point because the definition would already exist in the plugin file.
Move on to the next step ff the new web server, webserver2, passes these basic tests.
The web server is working but it is just a copy of the data in webserver1 and since you wanted process level isolation for a different application so you must also go to the Deployment Manager to make the application specific changes, pushing out the remaining configuration from the management console. After all shell level configuration is done, proceed to the WebSphere deployment manager in System Administration -> Nodes. Create an unmanaged node pointing to the host of the http server.
Add Unmanaged Node
WebNode02 On IHS 6.1 Server
Now, you may create webserver2 in that node in Servers -> Web servers. Now, you will see that webserver2 is defaulted with the original httpd.conf. We must use the GUI and change the name from httpd.conf to httpd2.conf. WebSphere will read the configuration information from the file. Propagate the plugin key store and config files now to check for any possible errors which you should stop and correct. If you can read the configuration file, your deployment manager is now connected to webserver2. Scroll to the bottom to see your changes and ensure you have the webserver2 file. A hint could have been added to the top of the file that like "# WebServer2 conf," identifying the proper file for other admins. Next, you must set the application to use webserver2 in Enterprise Applications -> YourApplicationName -> Manage Modules. Ensure your virtual host is set in Virtual Hosts -> YourVhost -> Host Aliases. Now it is time to push the configuration files out. You will now have a plugin file to propogate which contains details of your application for this new isolated HTTP process in the WebSphere Applicaton Server. You must also build a key store for the HTTP server and a plugin key store but this guide uses a new build and such steps are not shown. Push these out using the DMGR gui, too. Restart the HTTP server using the console and check for any errors before testing.
Create webserver2
Set Configuration File Name to httpd2.conf
Configuration Readable
Sample Application Mapped to WebServer 2
Separate Virtual Host for Sample Application
WebServer 2 Files Push Successfully
Sample Application on Port 8080
RSS Feed
