Integrated load balancer description

Since node.js is single threaded, on a multi-processor machine several instances of node.js have to be started in order to really use the capabilities of the machine. At big customer sites also a cluster of machines may have to be established. There is some load balancing mechanism necessary to distribute the requests to the different node.js instances. This document describes them.

How the Load balancer works

All node.js instances running on the same physical server will be started and stopped by a so-called nanny process. This process will also restart a node.js instance when it has crashed. Each nanny process can also serve as a load balancer (the load balancer is just the nanny process which will be assigned for the requests from outside).

Distribution of the first requests to node.js instances follows a round-robin mechanism based on the number of sessions (in the session table) which already run on the node.js instance. This means that for all node.js instances, the list of instances (in some fixed ordering) will be taken which have the least number of sessions, and the first node.js instance in this list will get the new session. This will distribute the new sessions equally to the node.js instances. Instances on the same machine will get precedence because the requests can be handled faster. All requests of the same session will be executed on the same node.js instance.

The requests will be transparently sent to the server where they will be executed. This allows for bookmarking links.

An entity with name "host" contains all information about the installed servers in the cluster. For details see the description in Host entity.

Some nanny process functionality

Via command line

When a nanny process has started, it will notify the other started and active nannies that it has started. It receives their versions and the main version. When the local nanny process has the same version as the main version, its child process will be started. When the child processes have all been started and are ready to accept requests, the nanny process will notify the other nannies again.

Special setting in nodelocal.js

When load balancing should be only locally (that is, only to Syracuse processes on the local server), in nodelocal.js the following must be set (all other settings are not shown):

exports.config = {hosting: {localBalancer: true}}

This is useful when an external load balancer is used which distributes the requests to servers. But that external load balancer must also be able to send all requests for the same session to the same server.

Via http

When you append the path /nannyCommand/info to the URL, you can find out the status of all nanny processes in the cluster without having to start a session. Sample URL: http://server:8000/nannyCommand/info. The output is rather technical and useful mainly for error detection. Whenever possible, look directly at the host entity which will display the data in a much mor user friendly way.

Here some commented sample output (comments will start with '#') - real data may not contain all of these items

hostname: 'VIL-004674-NB', # host name of that server, as returned by hostname command, is key in host entityconnectionData:# overview of all ports on which the nanny can listen[ { port: 8111, # port numberactive: true,# nanny will listen on that port?ssl: false, # SSL connection?clientAuth: false, # SSL with client authentication?serverCert: null, # reference to instance of server certificate - not readable hereclientCert: null, # reference to instance of client certificate - not readable herehost: [Object], # for internal use_uuid: 'ffb9be61-278c-467c-a3c4-019d52e1d484' } ], # for interhal usechildren: 1,# number of child processeswsChildren: 0, # number of child processes for web service executiondeactivated: false, # server has explicitly been deactivatedstarted: true, # server has been started (using node nanny) and not yet stopped (using node nanny stop)respawnCount: 10, # number of attempts to restart child processes before giving uprespawnTime: 120, # maximal time in seconds for start attempts for child processreturnRequestTimeout: 30, # number of seconds which a Syracuse process will wait for an internal answer of the nanny process.tcpHostName: 'vil-004674-nb', # TCP name or IP address (obtained from server certificate) for HTTP requests to that serverpid: 3376, # process IDstatus: -5, # status (see explanation in host entity): 5: finish all, 4: finishing, 3: OK, 2: starting, 1: init, 0: inactive, -1: low version, -2: wrong version, -3: time difference, -4: repawn limit, -5: unknown, -6: unreachable, -7: not started, -8: no database, -9: no licensechallenge: 'adcfe27d-db5c-43fe-889f-94e94ea9e3e0', # for internal usependingRequest: true, # for internal usedhKey: '***',# secure connection established to that host: certificate transfer possibleversion: '2.999.2.42-0', # internal version numberlocal: true, # request has been executed on that servermissingCert: [],# missing certificates on that servermissingCA: [], # missing CA certificates on that serveruntrusted: [ 'VIL-SRV-DX3-2' ] # hosts to which no secure connection has been established