2.2.7. Cluster load balancing

   

2.2.7.1. Available performance of a working process

Each working process has the Available performance property. It defines how quickly the working process can perform reference operations compared to other working processes. Reference operations include:

• Memory operations: array allocation, population, and deallocation.
• File operations: creation, saving, and deletion.
• Assessment of processor load for the computer running the working process and defining the number of threads to run. This value increases execution time of the reference call.

  On Windows, the user that runs a server must belong to the Performance Log Users group. Otherwise, processor load assessment is not performed.

Value of the Available performance property is calculated by dividing 10,000 by the average time (within 5 minutes) required by the current working process to perform reference operations. The speed with which reference operations are performed is measured every 5 seconds.

Clients are allocated among working processes so as to ensure a roughly equivalent available performance for each working process. The 25% difference in available performance levels is considered substantial.

When balance between the available performance of working processes changes, the clients are dynamically reallocated to working processes within 10 minutes.

When a working process is disabled, clients allocated to it are dynamically reallocated to the remaining active working processes.

2.2.7.2. Establishing a new connection

2.2.7.2.1. Direct server connection

When establishing a new connection to 1C:Enterprise server, you can specify how the working process will be selected (the Load balancing mode server cluster property):

• By performance
• By available memory

A list of suitable working servers with performance not less than 75% of the most efficient server is generated. Server performance is defined as the performance level of the most efficient working process on this server. On each suitable server, suitable working processes are selected. Their performance cannot be less than 75% of performance of the most efficient working server. Per each working server, the most suitable working process from available working processes is selected based on one of the following criteria:

• A working process has the greatest number of connections with the serviced infobase.
• A working process has the greatest number of connections with any infobase whenever there are no working processes servicing the infobase for which connection is established.

A random working process is selected from the best working processes of all servers for even distribution in case of mass load. This working process will be used to establish a new connection.

An existing connection to 1C:Enterprise server can be re-established with another working process in one of the following cases:

• Current working process is disconnected.
• Available performance of the current working process is less than 75% of available performance of the most efficient working server.

Connection can be re-established only if the following conditions are met:

• Client thread is not executed on the server.
• No open transactions exist.
• No temporary tables were created.

Working servers whose performance is not less than 25% from performance of the most efficient working server are selected. Server performance is defined as the performance level of the most efficient working process on this server. On each selected working server, working processes are selected. Their performance cannot be less than 25% of performance of the most efficient working server. Working processes servicing the required infobase are selected from the list of suitable working processes. Selected working process depends on search results:

• If only one working process is found, it will be used to establish connection.
• If several working processes are found, a working process with the greatest amount of free RAM available is selected.
• If no such process is found, a working process with the greatest amount of free RAM available will be selected from the list of suitable processes to establish connection.

An existing connection to 1C:Enterprise server can be re-established with another working process in one of the following cases:

• Current working process is disconnected.
• Available performance of the current working process is less than 25% of available performance of the most efficient working server.

Connection can be re-established only if the following conditions are met:

• Client thread is not executed on the server.
• No open transactions exist.
• No temporary tables were created.

2.2.7.2.2. Connection via web server extension

When calling the server on behalf of a new session:

• The system selects any connection from the connection pool available in the web server extension.
• If no connections are available, a new connection is created according to the Load balancing mode cluster parameter.

When calling the server on behalf of an existing session:

• The system searches the connection pool for a connection to the working process that was used during the previous call. If the search is successful, the found connection is used.
• The system attempts to select a working process based on the Load balancing mode cluster parameter. Higher priority is given to the working process that was previously used for the server call. A new working process will be selected if it significantly exceeds the current working process in terms of performance or available memory. If there are free connections to the resulting working process, one of them will be used.
• Otherwise, a new connection is created based on the Load balancing mode cluster parameter.

2.2.7.3. Functionality assignment rules

2.2.7.3.1. General information

Server cluster provides a set of features called assignment rule objects. You can manage their allocation among working servers within a cluster. For example, you can specify a working server to run all background jobs in the cluster.

To assign a connection or cluster service to a working server, you need to create a functionality assignment rule for this working server. This rule determines whether the server is allowed to execute a particular job. Let us examine functionality assignment rules in detail.

A functionality assignment rule determines:

• An object for which the rule is created. Some cluster services, client connections, or arbitrary assignment rule objects can be used as assignment rule objects. Cluster services with enabled migration can be assignment rule objects.
• A rule type, which determines how the working server is used:
  • Do not assign. It means that the working server for which this rule is created will not be assigned to the rule object that meets the rule conditions.
  • Assign. It means that the working server for which this rule is created will be one of the candidates for this rule object (if several working servers are available).
  • Auto. It means that the working server can be used for this rule object if there is no working server explicitly assigned for use.

• Additional parameters the server cluster sometimes needs to make decisions:
  • Infobase name. Infobase name is used to specify the rule to generate rules for client connections and all cluster services that can be a rule object, except for the licensing service. Please keep in mind that infobase name is case-insensitive.
  • Additional parameter value. You can use it to adjust the requirements when hosting a client connection or a session data service. When you host a client connection, a new session in the session data service, or the Data Accelerator service, the object to host has an additional parameter. The additional parameter consists of one or several dot-separated words. Comparing the value of an additional requirement parameter with the value of an additional object parameter is done word by word, from left to right. The additional object parameter corresponds to the additional requirement parameter if all words in the additional requirement parameter match the corresponding words in the additional object parameter. An empty value of the additional requirement parameter corresponds to any value of the additional object parameter.

    The additional object parameter can take one of the following values:

    • Hosting a new session in the session data service:
      • Designer: Designer.
      • Thick client: 1CV8.
      • Thin client: 1CV8C.
      • Thin client in case of a direct connection to the 1C:Enterprise server: 1CV8CDirect.
      • Web client: WebClient.
      • COM connection: COMConnection.
      • Web service call: WSConnection.
      • HTTP service call: HTTPServiceConnection.
      • Standard OData Interface call: ODataConnection.
      • Collaboration System bot: BotConnection.
      • Mobile client: MobileClient.
      • 1С:Analytics system client: AnalyticsSystemClient.
      • 1С:Analytics system query: AnalyticsSystemQuery.
      • System background job: SystemBackgroundJob:
        • Infobase context preload.
        • Background restructuring.
      • Background job executing the 1C:Enterprise language method: <Common module name>.<Method name>.
      • Another background job: BackgroundJob.
    • Hosting a client connection:
      • Designer: Designer.
      • Thick client: 1CV8.
      • Thin client: 1CV8C.
      • Thin client in case of a direct connection to the 1C:Enterprise server: 1CV8CDirect.
      • COM connection: COMConnection.
      • Connection to the infobase via a web server (web client, thin client if connected via a web server, mobile client, Internet service): WebServerExtension.
      • Scheduled job: BackgroundJob.ScheduledJob.<Configuration object name>.
      • Background job started from 1C:Enterprise language: BackgroundJob.CommonModule.<Module name>.<Method name>.
      • Background job for full-text search indexing: BackgroundJob.FullTextSearchIndexUpdate.
      • Background job for report generation (including an external report): BackgroundJob.GenerateReport.<Full name of configuration object>.
      • Background job for input by string: BackgroundJob.InputByString.<Full name of configuration object>.
      • Background job for searching in the list: BackgroundJob.DynamicListSearch.<Full form name>.<Name of form table associated with list>.
      • Background job for initial database copy filling: BackgroundJob.DBCopiesFilling.
      • Background job for updating database copies BackgroundJob.DBCopiesNotification.
      • Background job that updates data history immediately after a versioned object is written: BackgroundJob.UpdateDataHistoryImmediatelyAfterWrite.
      • Background job that performs processing after versions are written: BackgroundJob.AfterWriteDataHistoryVersionsProcessing.
      • Background job used by the global search to search by:
        • Functions menu: BackgroundJob.GlobalSearchFunctionsMenu.
        • Data: BackgroundJob.GlobalSearchFullTextSearch.
        • Help: BackgroundJob.GlobalSearchHelp.
        • Metadata: BackgroundJob.GlobalSearchAllFunctions.
      • Background job that calls a search procedure in background mode. This search procedure is implemented in 1C:Enterprise language and specified in the global search plan: BackgroundJob.GlobalSearch.<module name>.<method name>.
      • Background restructuring: SystemBackgroundJob.DBConfigUpdate.
      • Background job for recalculating totals: SystemBackgroundJob.RecalcTotals.
      • Standalone infobase mode (create new nodes, prepare for exchange, exchange, delete unused nodes): BackgroundJob.StandaloneExchange.
    • Hosting the Data Accelerator service:
      • The additional parameter can contain the name of the database copy with the built-in Data Accelerator. In this case, only the copy with the specified name will be serviced on the selected working server. Multiple copies with the built-in Data Accelerator can be serviced on one working server. In an infobase, database copies are managed using the Database copies management standard function.

Once you created the functionality assignment rules, you need to apply them through the cluster administration console.

Let us examine how the server cluster processes assignment rules. If an assignment rule object must be allocated, the cluster does the following:

• All cluster servers process functionality assignment rules specified for these servers. The rules are processed in order specified in the cluster console.
• In every list of rules, the system selects the first rule that matches the object to be assigned based on the object, infobase, and additional parameter.
• Then the list of working servers is sorted by the rule type so that working servers explicitly assigned for use are placed at the top of the list. Working servers prohibited from use by applicable rules are excluded from the list of available working servers. Servers are assigned as follows:
  • If any working servers are explicitly assigned for use, the assignment rule object will be processed by one of these servers.
  • If no working servers are explicitly assigned for use, the system attempts to use working servers with the Auto rule type or with no rule type specified.
• When allocating a client connection, the server running a working process with the highest available performance will be selected from the list of available servers.

The client application that initiates allocation of an assignment rule object will be terminated in these cases:

• The list of working servers for the assignment rule object is empty. In this case, there is no working server that can process the object. If that happens, the assignment rule object is not allocated and an exception is thrown.
• The assignment rule object cannot be assigned to the selected working server (for example, when the server has failed and no alternate servers are available).

2.2.7.3.2. Assigning assignment rule objects

Let us examine the algorithm used to assign a working server for processing a cluster service.

Cluster services can have the following assignment rule objects:

• Service of one type, provided that the service is not divided by infobases
• Service of one type for one infobase, provided that the service is divided by infobases
• Session data service
• Licensing service

Services are allocated to working servers as follows:

• From the list of working servers selected to host the service according to the functionality assignment rules, select working servers that are currently functioning. From these working servers, select those with the highest Priority property value. If there is no functioning working server, an attempt to place the service results in an error.
• Services are distributed evenly among the selected working servers.
• Services supporting replication can be assigned to multiple working servers. Number of used working servers is equal to the cluster fault tolerance level plus 1. In this case, one service is set as active and its internal data is replicated to other (backup) services. Replication is performed asynchronously. Data is synchronized every second.
• Services that do not support data migration (No migration characteristic) are assigned to all working servers with selected Main server check box.
• A separate instance of the session data service is created for each session processed by the server cluster. When selecting working servers that can process a specific service instance, additional parameters of the rule are considered. Servers processing the lowest number of cluster services are selected from the list of available servers. Number of used working servers is equal to the cluster fault tolerance level plus 1.
• If you need to use the licensing service, select a working server to which the software license will be attached and assign the service to this server in the rules explicitly.
• Other services are assigned as a single instance.

Cluster services can be reassigned between working servers in the following cases:

• When a working server is added, services are partially reassigned. The reassignment is performed automatically.
• When a working server is removed from the cluster or becomes unavailable, assignment rule objects processed by the unavailable server are reassigned. The reassignment is performed automatically.
• When an infobase is added or removed from the cluster, services are partially reassigned. The reassignment is performed automatically.
• Services are reassigned when the cluster administrator applies all or some rules from the cluster console.

2.2.7.3.3. Assigning working processes

At cluster startup, one working process is started on each working server, and the available performance of each working server is computed.

The client application connects to 1C:Enterprise server cluster according to these rules:

• A working server is selected in accordance with assignment rules and RAM usage restrictions.

  RAM usage restrictions are considered when connecting to an infobase with no established connections on the selected working server. If the RAM usage limit is exceeded, the working server is excluded from the list (provided that another working server that has not exceeded the limit is available). Working servers that cannot process the requested connection according to the assignment rules are also excluded.

• A list of working processes that are available and can process the connection is created for the selected server. A working process is added to the list of available working processes when:
  • The maximum number of connected infobases (see the Number of infobases per process property of the working server) is not reached for the working process.
  • The maximum number of processed connections (see the Number of connections per process property of the working server) is not reached for the working process.
  • The working process is not preparing for automatic restart.
• The system prefers working processes that already process connections to the required infobase. If there is no such working process, a working process with the greatest number of connections served is selected.
• If the system fails to select any working process, a new working process is started on the working server to process the requested connection.

When establishing connection from an existing session (if the previous server call failed to reconnect) the working process that processed the previous connection of this session will be selected. Another working process can be also selected if its available performance exceeds the available performance of the current working process by 25% or more.

When two working processes concurrently run for 20 minutes on the same working server and the number of connections and infobases processed by these processes together is less than the values specified in the working server properties (Number of connections per process and Number of infobases per process correspondingly), the process that serves fewer connections will be marked as obsolete and stopped after closing the last connection. Existing connections with the obsolete working process will be prompted to stop using the working server during the next server call over the connection. The obsolete working process is ignored when requests for processing new assignment rule objects are allocated.

When calculating the number of processed connections, all connections created by the debugger to check the access rights for debugging purposes are included.

2.2.7.4. Cluster management examples

2.2.7.4.1. General information

A server cluster described below will be used to examine sample functionality assignment rules.

Cluster specifications:

• Number of working servers: 3
• Fault tolerance level: 1
• Number of main servers: 2 (SRV1 and SRV2)
• Operating systems on working servers:
  • SRV1 server, Windows
  • SRV2 server, Linux
  • SRV3 server, Windows

Cluster infobases:

• DemoDB
• WorkDB

2.2.7.4.2. Assigning all background jobs to a single working server

To assign all background jobs to the SRV1 working server, use the functionality assignment rules for SRV1 as described below:

• Assignment rule object: Client infobase connection.
• Rule type: Assign.
• Infobase name: not specified.
• Additional parameter value: BackgroundJob.CommonModule.

2.2.7.4.3. Assigning the licensing service to a dedicated working server

To activate a multi-user client license for the computer running the SRV2 working server, assign the licensing service to this computer, and make sure no other service are assigned to this computer, use the functionality assignment rules for SRV2 as described below:

• Rule 1:
  • Assignment rule object: Licensing service.
  • Rule type: Assign.
  • Infobase name: not specified.
  • Additional parameter value: not specified.
• Rule 2:
  • Assignment rule object: Any assignment rule object .
  • Rule type: Do not assign.
  • Infobase name: not specified.
  • Additional parameter value: not specified.

Rule 1 will ensure that the licensing service is running on the SRV2 server. Rule 2 will ensure that only the licensing service is running on the SRV2 server (no other cluster services will be running on the SRV2 server).

When activating a software license via 1C:Enterprise server, specify SRV2 as the server name. Otherwise, the server cluster will not be able to use the license as it will be activated for another computer.

2.2.7.4.4. Prohibiting assignment of the external data source access service to a working server

You must allow operation of the external data source access service on the SRV1 and SRV3 working servers and prohibit it on the SRV2 working server. To do it, specify the assignment rule for the SRV2 working server as described below:

• Assignment rule object: External data source access service.
• Rule type: Do not assign.
• Infobase name: not specified.
• Additional parameter value: not specified.

2.2.7.4.5. One working process processing a single infobase

To configure the server cluster so that each infobase is processed by one working process, set the Number of infobases per process property for each working server to 1.

As a result, two working processes will be created on each server (6 in total, 2 working processes for each of the 3 working servers). In this case, one infobase will be processed by 3 working processes on 3 working servers.

2.2.7.4.6. Assigning working servers to specific infobases

Configure the server cluster so that the DemoDB infobase is processed only by the SRV3 working server and the WorkDB infobase is processed by two working servers: SRV1 and SRV2. To do it, specify the following rules:

• For the SRV3 working server:
  • Assignment rule object: Any assignment rule object .
  • Rule type: Assign.
  • Infobase name: DemoDB.
  • Additional parameter value: not specified.
• For the SRV1 and SRV2 working servers:
  • Assignment rule object: Any assignment rule object .
  • Rule type: Assign.
  • Infobase name: WorkDB.
  • Additional parameter value: not specified.

These rules will allocate all server cluster mechanisms: connections, background jobs, session data services, and so on.

2.2.7.4.7. Assigning specific background jobs to specific working servers

Configure the server cluster so that the SRV1 working server only runs reports, SRV2 runs the FullTextSearchUpdateIndex and SalesAggregateUpdate scheduled jobs, and SRV3 runs any other background jobs. To do it, specify the following rules:

• For the SRV1 working server:
  • Rule:
    • Assignment rule object: Client infobase connection.
    • Rule type: Assign.
    • Infobase name: not specified.
    • Additional parameter value: BackgroundJob.GenerateReport.
• For the SRV2 working server:
  • Rule:
    • Assignment rule object: Client infobase connection.
    • Rule type: Assign.
    • Infobase name: not specified.
    • Additional parameter value: BackgroundJob.CommonModule.FullTextSearchOperation.FulltextSearchIndexUpdate.
  • Rule:
    • Assignment rule object: Client infobase connection.
    • Rule type: Assign.
    • Infobase name: not specified.
    • Additional parameter value: BackgroundJob.CommonModule.AggregatesScheduledJobs.SalesAggregateUpdate.

2.2.7.4.8. Group distribution of background jobs

Configure the cluster so that the SRV1 working server serves all background jobs that start from the ServiceJobsServer common module, and the SRV2 working server serves only the search in dynamic lists.

To do it, specify the following rules:

• For the SRV1 working server:
  • Rule:
    • Assignment rule object: Client infobase connection.
    • Rule type: Assign.
    • Infobase name: not specified.
    • Additional parameter value: BackgroundJob.CommonModule.ServiceJobsServer.
• For the SRV2 working server:
  • Rule:
    • Assignment rule object: Client infobase connection.
    • Rule type: Assign.
    • Infobase name: not specified.
    • Additional parameter value: BackgroundJob.DynamicListSearch.