SSH Reference Manual

Load Balancing
With SSH2, it is possible to distribute the CPU load generated by the encryption of SSH sessions across multiple
processors of a NonStop system. This is true for both inbound and outbound sessions.
Load-Balancing Outbound SSH Sessions
For outbound sessions, CPU load balancing can be achieved by starting multiple SSH2 instances and distributing client
processes across processors. The load-balancing for outbound ssh sessions depends on client processing and can only be
influenced by settings in the client environment controlling the client’s processing.
All clients delivered with SSH2 (SSH, SSHOSS, SFTP, and SFTPOSS) employ a heuristic method in which an SSH2
process is opened to create the outbound session. The heuristic method works as follows:
1. If no explicit SSH2 process is configured (which is done by specifying the –S option on the command line), the
client evaluates first the define =SSH2^PROCESS^NAME and then the environment variable
SSH2_PROCESS_NAME to determine the process name of the SSH2 instance to connect to.
2. If neither define =SSH2^PROCESS^NAME nor environment parameter SSH2_PROCESS_NAME exists, the
client evaluates an environment variable named SSH2PREFIX to determine the process name prefix of the
SSH2 instances. The default is "$SSH".
3. If an open action fails, the client will look for an instance of an SSH2 process with the next higher processor
number, up to 15. After processor number 15 is searched, "00" will be tried. For example, if the SSH2PREFIX
is set to $ABC and there are two SSH2 processes running, one in cpu 4 with port 22, subnet $ztc0, and name
$ABC04, and one in cpu 5 with port 22, subnet $ztc1, and name $ABC05, an invocation of client SSH with
no -S and -p params connecting to a remote Unix box will find one of the two SSH2 processes, depending in
which cpu the client SSH was started: $ABC04 if SSH was started in a cpu other than 5, and $ABC05 if it was
started in cpu 5.
4. If all process names fail, the client will terminate with an error message.
The process names of the SSH2 instances serving the clients must be correctly configured to facilitate this heuristic
method. For example, you could decide to start an SSH2 instance in every CPU of your system, naming the instances
according to the number of the CPU they are running in:
RUN SSH2/NAME $SSH00, CPU 0, …/ …
RUN SSH2/NAME $SSH01, CPU 1, …/ …
…
After you have started multiple SSH2 instances in the manner described above, the distribution of the client processes
over CPUs will also ensure that the sessions are distributed across the available SSH2 instances. This distribution of
client processes can either be achieved manually, or by using any standard load-distributor tool available on your system.
Load-Balancing Inbound SSH Sessions
For incoming sessions, SSH2 can facilitate the round-robin filtering feature of TCPIPv6. In addition, parallel round-robin
filtering allows you to start multiple SSH2 listening processes in different processors that share the same port.
To enable round-robin filtering with SSH2, you have to configure the PTCPIPFILTERKEY
parameter for every SSH2
instance listening on the same port as follows:
RUN SSH2/NAME $SSH00, CPU 0, .../ ALL; PORT 22, PTCPIPFILTERKEY mykey
RUN SSH2/NAME $SSH01, CPU 1, .../ ALL; PORT 22, PTCPIPFILTERKEY mykey
After you have started multiple SSH2 processes in the manner described above, inbound SSH sessions will then be
distributed across the SSH2 instances in a round-robin manner.
The application processes started by SSH2 for incoming connection can be distributed over CPUs on a user level via
different settings of USER attribute CPU-SET and SFTP-CPU-SET. The SSH2 parameters CPUSET and SFTPCPUSET
134 • Configuring and Running SSH2 HP NonStop SSH Reference Manual