ZeroPoint ZAppSvr Technical Support

ZeroPoint Application Server 2 Configuration

Configuring ZAppSvr 2

Setting up ZAppSvr is not very difficult, but there are a lot of options and features that require some explanation in order for you to get the maximum benefit from using ZAppSvr. There are many potential uses for ZAppSvr so first we will examine configurable parameters, options, features. Then we will show you specific examples for solving popular implementation problems.

As you can see, configuring ZAppSvr is not difficult and there are many useful options provided. These features are designed to be simple to implement and execute as quickly as possible. With ZAppSvr you can solve a wide range of real-world issues that can make your network scalable, secure, and easier to manage.

The main configuration panel is the place to start ZAppSvr configuration. It is advisable to use ZAppSvrRC (The remote program) for configuration. It will always be usable on the server, but the remote program can be used anywhere that can access the server's IP address. The Remote program needs an IP address, port, and remote security string in order to access the server. You must also allow remote configuration changes before anyone can change server settings.

ZAppSvr can be used as a load balancer, so it is configurable as to whether a Plugin class is going to be used. If you are going to use a Plugin, just check the Use Plugin checkbox.

Concurrent Users indicates how many instances of the Plugin are going to be pooled and initialized for use. This is the maximum number of users that can be using the system at the same time. We have tested with over 1,000 users.

Force No-Cache Header Directive is used only in cases where a caching firewall interferes with your Web Service. It is seldom needed, but a life saver in a few situations where firewalls and caching systems are not properly configured. This reduces efficiency, so this feature should not be used unless required.

Use Logging is pretty easy to understand, the log file path is where on your system you want to write the log. This is the access log for the system in 'common-log' format. This is NOT the custom log, which will be discussed elsewhere.

Remote Address and Port configure the Remote Control port of ZAppSvr. You can use this feature to remotely monitor ZAppSvr, and if the Allow Remote Configuration Changes checkbox is checked, remotely modify server parameters. A highly secure key-pair encryption system keeps the data from being intercepted, or accessed. If you set the ip address to localhost, it becomes inaccessible from the outside. The Remote Security String is part of the encryption system, and must match the key in use on the remote client.

SSL Configuration is accomplished by filling in the SSL fields properly. If the SSL certificate path is empty, SSL will not start running, and the listener will not be available. ZAppSvr uses Java SSL Certificate generation. If you are installing the certificate on a Windows server, you do not need to install the certificate for use in IIS. Only ZAppSvr needs the certificate, unless your web server is visible to the outside world on a different port.

ZAppSvr Cfg Screen

SSL Certificate Installation

1. Generate the unsigned server certificate and untrusted keystore file.

   keytool -genkey -alias www.<yourdomain>.com -keyalg RSA -keypass <keypassword> -storepass <storepassword> -keystore <storename>.jks

   a. When asked for your first and last name, type the alias from above as in www.<yourdomian>.com.
   b. When it asks for your state type the full name as in Utah.
   c. Both the key password and keystore password can be the same.
   d. To view the certificate type: keytool -list -v -keystore <storename>.jks

2. Have the certificate signed by Thawte or other signing authority.

   a. Generate a Certificate Signing Request (CSR) for Thawte to sign:

      keytool -certreq -alias www.<yourdomain>.com -keyalg RSA -file <requestname>.csr -keystore <storename>.jks

   b. Send the contents of <requestname>.csr to Thawte for signing. (Instructions on the Thawte.com site)
   c. Receive the signed certificate via E-mail or from their web page. Save it as directed by Thawte into file <svrname>.cer.

3. Create the trust-store file <certsname>.jks and add the server certificate to the trust-store.
Run keytool from the directory where you created the keystore and server certificate with the following parameters:

   keytool -import -v -alias www.<yourdomain>.com -file <svrname>.cer -keystore <certsname>.jks -keypass <keypassword> -storepass <storepassword>

Information on the certificate, such as that shown below will display:
<INSTALL>
/jwstutorial12/examples/gs 60% keytool -import
-v -trustcacerts -alias server-alias -file server.cer -keystore cacerts.jks -keypass changeit -storepass changeit
Owner: CN=localhost, OU=Sun Micro, O=Docs, L=Santa Clara, ST=CA, C=US
Issuer: CN=localhost, OU=Sun Micro, O=Docs, L=Santa Clara, ST=CA, C=US
Serial number: 3e932169
Valid from: Tue Apr 08
Certificate fingerprints:
MD5: 51:9F:49:6A:ED:7C:6F:39:37:F1:98:B3:6A:6B:0F:91
SHA1: EE:2E:2B:B6:9E:03:9A:3A:1C:17:4A:2A:5E:97:2A:78:3C:
Trust this certificate? [no]:

4. Enter yes. Then strike the Enter or Return key. The following information displays:
Certificate was added to keystore
[Saving <certsname>.jks]

5. Copy <certsname>.jks to the ZAppSvr directory.

6. Change the ZAppSvr.cfg file to include the correct name and passwords for the SSL keystore file <certsname>.jks. You must include the full path to the keystore file.

7. Restart ZAppSvr.

Remote Address and Port configure the Remote Control port of ZAppSvr. You can use this feature to remotely monitor ZAppSvr, and if the Allow Remote Configuration Changes checkbox is checked, remotely modify server parameters. A highly secure key-pair encryption system keeps the data from being intercepted, or accessed. If you set the ip address to localhost, it becomes inaccessible from the outside. The Remote Security String is part of the encryption system, and must match the key in use on the remote client.

ZAppSvr Groups and Targets Configuration

This configuration tool is used to configure load balancing for stateful and stateless server groups. There is no programmatical limit on the number of groups or targets that can be configured. There is a logical limit imposed by how many requests per second that can be serviced by ZAppSvr. This is a function of computer power and Plugin complexity (if used). On a generic 1800 MHz Athlon box we’ve seen >1250 requests per second. On a really fast box the number of requests/second that can be processed will be much higher. Using multiple listeners with multiple network cards should increase throughput as well. (This reduces latency caused by network connection setup time.)

The ZappSvrGroup.cfg file must exist in order for Groups and Targets Configuration to work properly. A sample file is included in the current distribution file.

In a mixed environment with varying load, and differing computer power, you can assign different numbers of servers per group.

CPU Speed and the number of processors are used to determine the relative computing power of members of the server groups. Requests are routed to servers that appear to offer the greatest uncommitted resources, for optimum throughput.

Intuitively you can see that if under load on server is not as busy as it should be, raising CPU speed slightly will encourage ZAppSvr to use that server more often. As a general rule the best thing to do is just configure the correct server CPU speed and number of processors and forget about ‘tweaking’. On average load balance performance will be excellent.

Group List is a list of all the currently defined server groups. The Target Server List lists all the servers assigned to that group. A server may be included in multiple groups. There must be at least one server in each group.

Load balancers need to be able to route stateful requests back to the server that they connected to originally. This is accomplished by using a Session ID Cookie Name. The incoming request identifies which server group the request should be returned to, and the proper member of the group will receive the request. The Session Timeout in Min sets the session timeout.

When you do not specify a cookie name, the server group will do stateless load balancing. The ‘-‘ just indicates that no cookie is assigned.

Target Host Name will reassign the “Host:” header to a different host name. This can be a useful feature for easy site mirroring of static content, etc.


Cache Configuration

Maximum Allocated Memory allows you to determine how much memory you would like to dedicate to caching static content, like images, pages, etc.

Max File Size To Cache sets the maximum file size and Cache Object Timeout sets the timeout on objects to be stored in cache.

The Set Button stores the values you have selected.


IP Address Filter Settings

                This screen allows you to eliminate requests from specific IP addresses.

 


Listener Settings

This tool allows you to easily add and remove listeners.
To add a new listener, (ServerSocket) just specify it in ipaddress:port form.
The new listener will start right up without restarting ZAppSvr. You can use as many listeners as you want.

You can choose 0.0.0.0 as the IP Address of the listener, which will cause ZAppSvr to listen on all available interfaces on the specified port.

Always specify the port.

 


Authentication Settings

This list allows you to specify what requests are going to be routed into your Plugin for processing. The request can be specified in one of four ways. Authentication implies that these requests must be processed by the plugin prior to delivery.

  • Starts With - begins without an asterisk
  • Ends With - ends without an asterisk
  • Contains - starts and ends with an asterisk
  • Exact - starts and ends without an asterisk

As you can see from the samples shown, you must specify what file types you’re going to process. Without this information, your Plugin will never execute.
When parsing this information, the HTTP/1.x is stripped from the request and can be disregarded.

For example, if you do not include .gif files in this list, all gif files will be considered cacheable. Cacheing of static objects will occur so long as cache memory is allocated and they are NOT specified in this list.

Specifying graphic file extensions here implies that authentication by the plugin is required before the file can be delivered.


Do Not Cache Filters

This is an exception list. Even though the gif extension is normally cacheable, we are choosing to make roses.gif non-cacheable.


We could add *.vb* for example, so that a visual basic request would be handled properly without being handled like a static request, by servers in the default server group.


Request Filter Settings

Some requests are malicious, obsolete, or just a waste of resources. In these cases we can configure which requests are to be ignored outright, as quickly as possible.

 

©Copyright 2012, ZeroPoint, LLC.      Questions? Comments? Email Us.