LB commands

LB commands contain load balancing manipulating functions, with the most important function being LB:routing which allows you to select the backend:

LB:routing(value) — Routes the request to the content routing server.

LB:get_valid_routing() — Returns a list of backend names configured on the current Virtual Server in the form of a Lua table (number as key, string as value).

LB:get_current_routing() — Returns the currently allocated backend for this request.

LB:method_assign_server() — Returns the server through the current load balance method configured on current the Virtual Server.

LB:set_real_server() — Sets a real server from the configured pool directly.

LB:routing(value)

Routes the request to the content routing server.

Syntax

LB:routing(value);

Arguments

Name	Description
value	A string which specifies the content routing to route.

Example

when HTTP_REQUEST {

LB:routing(“content_routing1”);

}

--supports multiple routing

LB:routing(“cr1”)

LB:routing(“cr2”)

--It will be routed to cr2; the final one prevails.

Note:

When a VS enables both content-routing and scripting, then this function will perform a cross-check to check the content-routing used in scripting is applied to the VS.

FortiADC version: V4.3

Used in events: HTTP_REQUEST / HTTP_DATA_REQUEST

LB:get_valid_routing()

Returns a list of backend names configured on the current Virtual Server in the form of a Lua table (number as key, string as value).

Since there must be at least one backend, the returned value cannot be nil or empty. In case of a single routing with zero or one content routing configured, the pool name will be returned.

Syntax

LB:get_valid_routing();

Arguments

N/A

Example

when HTTP_REQUEST {
t=LB:get_valid_routing()
for k, v in pairs(t) do
debug("Key: %d Value: %s\n", k, v)
end
}

FortiADC version: V7.2

Used in events: HTTP_REQUEST / HTTP_DATA_REQUEST / AUTH_RESULT

LB:get_current_routing()

Returns the currently allocated backend for this request.

If there is only one backend configured, this function returns the backend name in a string format. If there are multiple backends available, and they are already set via LB:routing(), then this function returns the backend name as a string. Otherwise, this returns an empty string if no backend is configured.

In case of a single routing with zero or one content routing configured, the pool name will be returned.

Syntax

LB:get_current_routing();

Arguments

N/A

Example

when HTTP_REQUEST {
t=LB:get_current_routing()
if (s == nil or s == '') then
       s = "No backend returned."
       end
      debug("current routing: %s\n", s).
}

FortiADC version: V7.2

Used in events: HTTP_REQUEST / HTTP_DATA_REQUEST / AUTH_RESULT

LB:method_assign_server()

Returns the server through the current load balance method configured on current the Virtual Server.

The implementation will first check whether the backend is already set. If the backend is set, then it runs the load balance algorithm to assign a server and returns the server name as a string. If the backend is not set, the function returns an empty string, and then FortiADC will set the backend only if there is only one backend available. If there is no server available in the corresponding pool or all the servers are down in the pool, an empty string will also be returned.

Syntax

LB:method_assign_server();

Arguments

N/A

Example

when HTTP_REQUEST {
    s=LB:method_assign_server()
    if (s == nil or s == '') then
    s = "No Server returned."
    end
   debug("assign server: '%s'\n", s)
}

Note:

The result may be overwritten by functions in PERSISTENCE events, which happen after HTTP_REQUEST. For example, this function returns server01. But the PERSISTENCE event specifies to use server02. The result from the PERSISTENCE event (server02) will always supercede results from non-PERSISTENCE events (server01).

FortiADC version: V7.2

Used in events: HTTP_REQUEST / HTTP_DATA_REQUEST / AUTH_RESULT

LB:set_real_server()

Sets a real server from the configured pool directly.

This function returns Boolean true if successful, otherwise, returns Boolean false.

Syntax

LB:set_real_server(rs_name);

Arguments

Name	Description
rs_name	A Lua string as the name of the real server. A valid real server must meet the following conditions: The real server name is valid and complies with name requirements (character limit, etc.) The real server's is a member of the selected pool. The real server is usable.

Examples

For events with manual routing selection:

when HTTP_REQUEST {
	debug("===>>============begin HTTP scripting============\n")
	-- routing to set
	sr = "test07"
	s = LB:get_current_routing()
	if (s == nil or s == "") then
	    debug("===>>set routing to be '%s'\n", sr)
		LB:routing(sr)
		s = sr
	end
	debug("===>>current routing: %s\n", s)

    -- Real Server name 
	rs = "rs05"
	ret = LB:set_real_server(rs)
	if ret then
		debug("LB:set_real_server(%s) Success.\n", rs);
	else 
        debug("LB:set_real_server(%s) Failed.\n", rs);
	end
	debug("===>>============end  HTTP scripting============\n")
}

For events without manual routing selection:

when PERSISTENCE {
	debug("===>>============begin scripting============\n")
       -- Real Server name 
	rs = "rs06"
	ret = LB:set_real_server(rs)
	if ret then
		debug("set_real_server(%s) Success.\n", rs);
	else 
        debug("set_real_server(%s) Failed.\n", rs);
	end
	debug("===>>============end scripting============\n")
}

FortiADC version: V7.4.3

Used in events:

• HTTP_REQUEST

• HTTP_DATA_REQUEST

• BEFORE_AUTH

• AUTH_RESULT

• PERSISTENCE

• POST_PERSIST