uCosminexus Application Server, Security Management Guide

[Contents][Index][Back][Next]

8.3 Load balancer APIs executed using the operation management functionality

This section describes the load balancer APIs that are executed with the operation management functionality.

Organization of this section
(1) Load balancer APIs executed using Management Server (Smart Composer functionality)
(2) Load balancer API executed using Virtual Server Manager

(1) Load balancer APIs executed using Management Server (Smart Composer functionality)

The following section describes load balancer APIs that are executed by using Smart Composer functionality.

Below is an example sequence diagram of a load balancer API. In this example, cmx_build_system uses cookie switching (for building a Web system).

Figure 8-1 Example load balancer API sequence diagram (cmx_build_system for building a Web system)

[Figure]

The VirtualServer object represents the load balancer's virtual server, which accepts requests. One VirtualServer object is created for each management unit. The ServiceGroup object provides service management for requests accepted by the load balancer's VirtualServer. One ServiceGroup object is created for each VirtualServer object. The RealServer object represents a real server to which requests accepted by the load balancer's VirtualServer are transferred. The number of RealServer objects is equal to that of virtual servers belonging to the management unit.

Before accessing the load balancer through an API that uses persistent cookies for ACOS, you need to create CookiePersistence (cookie persistence). Using CookiePersistence, specify the hold period for each cookie-based session. Delete any used instances of CookiePersistence as necessary. For details about how to create and delete CookiePersistence, see the documentation for the load balancer used.

Reference note
The names VirtualServer, ServiceGroup, RealServer, and CookiePersistence, vary depending on the load balancer product.

(2) Load balancer API executed using Virtual Server Manager

The following section describes load balancer APIs executed using Virtual Server Manager.

Below is an example sequence diagram of a load balancer API. In this example, vmiunit update uses cookie switching (for building a new system).

Figure 8-2 Example load balancer API sequence diagram (vmiunit update for building a new system)

[Figure]

The VirtualServer object represents the load balancer's virtual server, which accepts requests. One VirtualServer object is created for each management unit. The ServiceGroup object provides service management for requests accepted by the load balancer's VirtualServer. One ServiceGroup object is created for each VirtualServer object. The RealServer object represents a real server to which requests accepted by the load balancer's VirtualServer are transferred. The number of RealServer objects is equal to that of virtual servers belonging to the management unit.

Before accessing the load balancer through an API that uses persistent cookies for ACOS, you need to create CookiePersistence (cookie persistence). Using CookiePersistence, specify the hold period for each cookie-based session. Delete any used instances of CookiePersistence as necessary. For details about how to create and delete CookiePersistence, see the documentation for the load balancer used.

Reference note
The names VirtualServer, ServiceGroup, RealServer, and CookiePersistence, vary depending on the load balancer product.