38.10 Load Balancing

Replication is an important IceGrid feature but, when combined with load balancing, replication becomes even more useful.

IceGrid nodes regularly report the system load of their hosts to the registry. The replica group’s configuration determines whether the registry actually considers system load information while processing a locate request. Its configu­ration also specifies how many replicas to include in the registry’s response.

IceGrid’s load balancing capability assists the client in obtaining an initial set of endpoints for the purpose of establishing a connection. Once a client has estab­lished a connection, all subsequent requests on the proxy that initiated the connec­tion are normally sent to the same server without further consultation with the registry. As a result, the registry’s response to a locate request can only be viewed as a snapshot of the replicas at a particular moment. If system loads are important to the client, it must take steps to periodically contact the registry and update its endpoints. Section 32.17.2 provides more information on this subject.

38.10.1 Configuring a Replica Group

A replica group descriptor optionally contains a load balancing descriptor that determines how system loads are used in locate requests. The load balancing descriptor specifies the following information:

• Type

Several types of load balancing are supported. See Section 38.10.2 for details.

• Sampling interval

One of the load balancing types considers system load statistics, which are reported by each node at regular intervals. The replica group can specify a sampling interval of one, five, or fifteen minutes. Choosing a sampling interval requires balancing the need for up-to-date load information against the desire to minimize transient spikes.

On Unix platforms, the node reports the system’s load average for the selected interval, while on Windows the node reports the CPU utilization averaged over the interval.

• Number of replicas

The replica group can instruct the registry to return the endpoints of one (the default) or more object adapters. If the specified number N is larger than one, the proxy returned in response to a locate request contains the endpoints of at most N object adapters. If N is 0, the proxy contains the endpoints of all the object adapters. The Ice run time in the client selects one of these endpoints at random (see Section 32.11.4).

For example, the descriptor shown below uses adaptive load balancing to return the endpoints of the two least-loaded object adapters sampled with five-minute intervals:

<replica‑group id="ReplicatedAdapter">
    <load‑balancing type="adaptive" load‑sample="5"
        n‑replicas="2"/>
</replica‑group>

The type must be specified, but the remaining attributes are optional.

38.10.2 Load Balancing Types

A replica group can select one of the following load balancing types:

• Random

Random load balancing selects the requested number of object adapters at random. The registry does not consider system load for a replica group with this type.

• Adaptive

Adaptive load balancing uses system load information to choose the least-loaded object adapters over the requested sampling interval. This is the only load balancing type that uses sampling intervals.

• Round Robin

Round robin load balancing returns the least recently used object adapters. The registry does not consider system load for a replica group with this type. Note that the round-robin information is not shared between registry replicas; each replica maintains its own notion of the “least recently used” object adapters.

• Ordered

Ordered load balancing selects the requested number of object adapters by priority. A priority can be set for each object adapter member of the replica group.

Choosing the proper type of load balancing is highly dependent on the needs of client applications. Achieving the desired load balancing and fail-over behavior may also require the cooperation of your clients. To that end, it is very important that you understand how and when the Ice run time uses a locator to resolve indi­rect proxies; Section 32.17.2 discusses this subject in detail.

38.10.3 Application Changes

The only change we need to make to the ripper application is the addition of a load balancing descriptor:

<icegrid>
    <application name="Ripper">
        <replica‑group id="EncoderAdapters">
            <load‑balancing type="adaptive"/>
            <object identity="EncoderFactory"
                type="::Ripper::MP3EncoderFactory"/>
        </replica‑group>
        <server‑template id="EncoderServerTemplate">
            <parameter name="index"/>
            <parameter name="exepath"
                default="/opt/ripper/bin/server"/>
            <server id="EncoderServer${index}"
                exe="${exepath}"
                activation="on‑demand">
                <adapter name="EncoderAdapter"
                    replica‑group="EncoderAdapters"
                    endpoints="tcp"/>
            </server>
        </server‑template>
        <node name="Node1">
            <server‑instance template="EncoderServerTemplate"
                index="1"/>
        </node>
        <node name="Node2">
            <server‑instance template="EncoderServerTemplate"
                index="2"/>
        </node>
    </application>
</icegrid>

Using adaptive load balancing, we have regained the functionality we forfeited in Section 38.9.3. Namely, we now select the object adapter on the least-loaded node, and no changes were necessary in the client.

38.10.4 Interacting with Replicas

In some applications you may have a need for interacting directly with the replicas of an object. For example, the application may want to implement a custom load-balancing strategy. In this situation you might be tempted to call ice_getEndpoints on the proxy of a replicated object in an effort to obtain the endpoints of all replicas, but that is not the correct solution because the proxy is indirect and therefore contains no endpoints. The proper approach is to use the findAllReplicas operation provided by the IceGrid::Query interface. See Section 38.6.5 for more information.