INSSLR - Redundant HTTP Input Gateway with SSL Support

	At a Glance
	Catalog	System
	Category	Gateways
	User volumes	yes
	Min. memory	64M
	OS	Linux
	Constraints	no
	Questions/Comments	Ask Forum

The INSSLR appliance is a layer-7 gateway for secure HTTP requests. It converts the requests to unencoded HTTP requests. This can be used whenever it is necessary to support secure HTTP on the client's side, but the back-end processing infrastructure does not or cannot support SSL, including:

• using a fast and light-weight HTTP server that does not have SSL support
• using multiple back-end servers, for performance or for redundancy, connected through a load-balancing switch
• using multiple back-end servers for unrelated functions, connected through a URL switch
• offloading the SSL encryption/decryption to a separate server to improve throughput

In its default configuration INSSLR acts as an INSSL and requires the same resources. When configured, two INSSLR appliances can be used in failover mode to provide a redundant service. In this case, INSSLR IP address (configured via ip_addr) is running on only one of the nodes and is automatically transferred to the other INSSLR appliance in case of failure. At any given moment, only one of the INSSLR appliance is active. When running in failover mode INSSLR can be configured to run in several modes:

• asymmetric - one of the appliances is primary and whenever it is online it takes over the IP address and becomes active. The backup appliance becomes active only if the primary node fails (or is stopped). Whenever the primary appliance becomes available again, it takes over the IP address and becomes active. The primary appliance is the one with the lowest IP address (string comparison) as set in the fover_local_ip property.
• symmetric - both appliances are primary and whichever appliance starts first takes over the IP address and becomes active. The other appliance becomes active only if the first appliance fails (or is stop). Whenever the first appliance becomes available again, it does not automatically take over the IP address.

INSSLR provides a firewalled entry point for network traffic into an AppLogic application, which can be configured with an Internet-accessible static IP address.

To support applications that need to appear at a single IP address for more than one service, INSSLR can be configured to direct non-HTTP traffic transparently to a separate output terminal. For such connections, the appliance acts as a layer-3 firewall/NAT router.

Boundary

Resources

Note: When using INSSLR in failover mode ( fover_mode is not none), the minimum recommended memory is 96M.

Note2: the amount of memory given to INSSLR does not affect its throughput. Use more memory only to support more concurrent requests that have been forwarded to a back end server, pending a response, if the back-end servers hold up requests for excessively long times.

Terminals

Properties

Advanced Properties (used in failover scenarios)

fover_mode	String	Failover mode. Possible values are none (no failover), symmetric and assymetric. When set to none INSSLR acts just like an INSSL appliance and does not provide failover capabilities. When set to symmetric, INSSLR will run in symmetric failover mode (you need two INSSLR appliances, both running in symmetric failover mode). When set to asymmetric, INSSLR will run in asymmetric failover mode (you need two INSSLR appliances, both running in asymmetric failover mode). When running in failover mode, both appliances must have fover_mode set to the same value.
fover_local_ip	IP addr	Local IP address to be used in failover mode for communicating with the other INSSLR appliance. This can be any available IP, including any reserved private address (as defined by rfc1918). This address is used only for monitoring the status of the other INSLLR appliance. This should be set to the same IP as the fover_remote_ip property on the other INSSLR appliance. Leave this empty if you have set fover_mode to none. Default: (empty)
fover_remote_ip	IP addr	Remote IP address of the other INSSLR appliance used in failover mode. This should be set to the same IP as the fover_local_ip property on the other INSSLR appliance. Leave this empty if you have set fover_mode to none. Default: (empty)
fover_netmask	IP addr	Netmask for fover_local_ip. Leave this empty if you have set fover_mode to none. Default: (empty)
fover_nfy_prefix	String	Url prefix that will be requested whenever a failover occurs. The requested URL will be http://nfy/fover_nfy_prefixfover_mode=fover_mode&state=<start|stop>&ip_addr=ip_addr&fover_local_ip=fover_local_ip&fover_remote_ip=fover_remote_ip&fover_netmask=fover_netmask and it will go through the nfy terminal. Default: ?

Volumes

Performance

Application Failover

INSSLR detects the failure of the other INSSLR in about 10 seconds. It takes an additional 10 seconds to failover to the other application. The total time from when the application failure first occurs to when the other application takes over the traffic is about 20 seconds.

Request Rate

INSSLR routes no less than 700 http or 120 https transactions (request/response pairs) per second, when operating on a single 2GHz CPU.

Data Throughput

INSSLR routes no less than 3MB/s over http or 0.5MB/s over https, on a 3K average packet size (request and response).

Concurrent Connections

When given its maximum memory requirement, SSL should be able to handle no less than 300 concurrently pending requests. (A "pending request" being an open TCP connection from the client, on which there is one or more un-completed HTTP request in progress).

Notifications

INSSLR send two notifications:
* A notification to the grid dashboard: "INSSLR appliance APP_NAME:COMP_NAME <acquired|gave up> resource ip_addr"
* An http request via the nfy terminal. It is up to the receiving end to take some action based on the notification. The requested URL is:

http://nfy/fover_nfy_prefixfover_mode=fover_mode&state=<start|stop>&ip_addr=ip_addr&fover_local_ip=fover_local_ip&fover_remote_ip=fover_remote_ip&fover_netmask=fover_netmask

When using fover_nfy_prefix different than the default make sure it ends with ? if fover_nfy_prefix is just the path the the script or & if fover_nfy_prefix includes additional parameters.
If a node becomes unavailable it may not be able to send a notification that it became passive and only the node that became active will send notification.
The timeout for the http request is 5 seconds so that the failover is not slowed.

Certificates

In order to use SSL you need both the signed certificate and the private key it was encrypted with. The key and the certificate should be in PEM format and put in a single file specified by the cert_file property.

Generating a certificate

First, you need a private key. You can generate one by executing:

• openssl genrsa -out privkey.pem 2048

To generate a pass protected key, use the following (note that in order to use the key with INSSLR you need a passwordless key, if you create a pass protected key you need to remove the password before using it in INSSLR)

• openssl genrsa -des3 -out privkey.pem 2048

Next you need a certificate. You have two options here - create a certificate request and have it signed by a trusted CA (for which they will charge you), or create a self-signed certificate for test purposes (in this case browsers requesting your site will issue warnings that the certificate is not signed by a trusted CA).

To generate a certificate request, execute the following:

• openssl req -new -key privkey.pem -out server.csr

After you send the .csr file to your trusted CA, it will give you back a signed certificate ( .crt file) which you can use.

To generate a self signed certificate, execute the following:

• openssl req -new -x509 -key privkey.pem -out server.crt -days 1095

Using the certificate

You can now put the certificate and the key in a file and use it in INSSLR:

• cat privkey.pem  server.crt > server.pem

If your key is password protected, you can remove the password by executing the following:

• openssl rsa -in key_with_pass.pem -out privkey.pem

Using existing apache+mod_ssl certificate

If you have an existing certificate that you use in Apache, you can use it in INSSLR as well. Just make sure the key is not password protected (see above) and put the private key and the certificate in one file in that order. Example:

• cat privkey.pem  server.csr > server.pem

If you are using a chained certificate, you should also include the intermediate certificate provided by the issuer. Put the private key, the certificate and the intermediate certificate in one file in that order. Example:

• cat privkey.pem server.csr sf_issuing.crt > server.pem

The server signing key is your Web site's "proof of identity". It is also vulnerable, since it is not password-encrypted (so that the appliance can read it without your help). Take the necessary measures to protect the key file, when installing it on the data volume. Do not use the same data volume for other purposes and don't make it visible to a Web server, e.g., to host Web-accessible data (HTML pages, scripts and such).

Typical Usage

Web applications

To provide http(s) access to your application, connect the http terminal directly to the WEB appliance.


If you need a scalable web application hook the http terminal to a HLB appliance.

Configuration for web applications

Note: the configuration examples list only properties set to non-default values and lack the network configuration (ip_addr, netmask, gateway).

Web application with additional services

If you have more services than just http in your application, you can use INSSLR to pass http traffic to its http terminal and use the aux terminal for other services.

Web applications with > 1 additional services

If you have multiple tcp/udp services and http, you can use INSSLR to pass http traffic to its http terminal and use the aux to feed the rest of the traffic to PS8, which will feed the desired traffic to the backend servers.

Redundant Web applications

If you need to provide a redundant web application, you can copy the application and use INSSLR in order to provide failover capabilities for the external IP address.

Backup Web application

If you just want a backup application that will notify users for the downtime, you can use INSSLR to build a backup application that requires a minimum resources.

Appliances in use:

• user - input gateway for user requests
• web - web server displaying maintenance message

INSSLR on primary application:

INSSLR on backup application:

Redundant Web application (single application)

If you want to have your application run in redundant mode without creating a new application, you can just double the appliances in it and run them in redundant mode. Since this involves using (at least) two web servers and two database appliances, in normal mode their are all used (providing scalability), but each of them is able to server the application alone in case the other appliance fails. If you need additinal scalability yuo can add more web and database appliances. In this example half of the appliances (in1, sw1, web1, db1) are running in one failover group and the rest (in2, sw2, web2, db2) are in another failover group so that the application can survive a server crash. This application provides redundancy at a very low cost as all of the appliances (except for one INSSLR and one HLB appliance which require very low resources) are in active state and no resources are spent for a backup application that will run only when the primary fails.

in1

in2

db1

db2

Redundant Web application (two identical applications)

You can run two identical applications on the same grid (but on separate servers so that failure of a server can only affect one of the application), or on different grids, provided that the IP address you use is accessible from both grids. The example below shows an application that uses a database appliance which is also running in redundant mode so in case of failure of one application, the other application can take over without data loss.

Appliances in use:

• in1 - redundant input gateway for user requests
• admin - input gateway for log files access
• sw - redirect port 8080 from admin to ui on db
• repl_in - input for the remote application to connect to the db appliance in order to replicate the database
• web_lb - web load-balancer for user requests
• web1, web2 - web servers with active content (e.g., CGI scripts)
• db - MYSQLR configured to be both a master and a slave at the same time
• content - storage for database error log files, web content and web logs
• logs - storage for database error log files
• repl_out - output gateway for the db appliance to connect to the remote application in order to replicate the database
• mon - MON appliance

Client request arrive on the in1 gateway. The gateway forwards the requests to the web_lb load balancer, which directs the request to one of the web servers web1 and web2. The web servers access the db database. The db appliance connects to the remote application (which is an identical copy, the only difference being the server_id of db and the network setup) in order to replicate the database. The remote application connects to the db appliance via the repl_in gateway which is configured to allow connection only from the repl_out gateway of the remote application. The db appliances in the two applications are running in master-master setup so they always have identical data.

Example property configuration (properties that are not listed should be left to their default values):

Web access to db is available via admin gateway on port 8080.

in1

db

Only one of the applications is active at any time, the other one is running just for failover and will be used when the active application fails.

Notes and Links

Notes

• the INSSLR input supports HTTP 1.0 and HTTP 1.1, but if the client identifies itself as MSIE, HTTP 1.1 support is turned off for that connection (to avoid bugs in some versions of MSIE).
• if the client is not MSIE, the SSL appliance will support HTTP 1.1 for the client (incl, the multiple requests per TCP session ability), even if the back-end server uses supports only HTTP 1.0.
• The INSSLR clas supports a single external IP and therefore a single SSL certificate may be used.

Related Documents

• Implementation Design
• Test Plans and Results
• Release Notes?

Questions and Comments

To post a question or comment on this appliance, visit our forum.