Menu
homeInternet

The 1C 8.3 server console does not start. Administration of 1C Enterprise servers. Adding an existing infobase to the list of infobases in the 1C:Enterprise launch window

The 1C server management console or the 1C server administration console, or the 1C server cluster console is a utility included in 1C Enterprise 8.3, which is necessary for:

  • Session management;
  • Managing the list of databases;
  • Creating 1C clusters for fault-tolerant architecture and scalability;
  • Flexible configuration of work processes;
  • Limitations on resource consumption;
  • Separation of tasks performed by working servers (to transfer individual services to different working servers);
  • Security profile management.


Managing databases in the cluster console

When working in a client-server architecture, users most likely, in one way or another, encounter the server administration console, at least when they add a new database to the list of infobases. To add a new database, you need to right-click on the infobases and select “Create”.


A window will open.


In this window, the settings for connecting to the DBMS are filled in, and if it is missing, you can use the option “Create a database if it does not exist.” The rest of the settings can be left as default.

You can also open the same settings window for an already created infobase, for which you need to right-click on the infobase and select the “Properties” menu item.


Here we can set a block on the start of sessions (set a block for a certain period). While the lock is in place, no session will be able to connect to the database.


You can set a specific message that the user will see when connecting.


This option can be used, for example, when carrying out any routine maintenance on the database (usually updating the database). But when administrators are required to log into the database with session blocking imposed, you need to use the “Permission code” option. Having specified the code, in the future, using it, it will be possible to work with the database. For example, let's set the expansion code to 123 so that we can enter the database later. The parameter must be used with the permission code /UC.


A blocking parameter is an arbitrary parameter that can be used in program code. The blocking will occur when using the function GetSessionLock().

Blocking routine tasks is enabled - this means that routine tasks will not be executed in our database.

The options discussed are the most frequently used. The rest are used very rarely in life, and information about them can be read on ITS.

Working with Administration Console Sessions

In the administration console, you can manage connected sessions for a specific database, as well as general sessions on a given cluster.


The sessions window looks like this:

From this window you can get a large amount of information, starting from which user this session is, and ending with memory consumption data for the session, as well as how much DBMS data was received, how much processor time was spent, and much more.

Here you can also end sessions (starting from platform version 1C:Enterprise 8.3 (8.3.13) and set the text of the message that the user will see when closing the 1C thin client.




Using security profiles, you can configure which modules can be extended with extensions, limit extensions to certain configuration modules, limit access to the file system from application code, limit access to COM objects, external components, third-party applications, etc.

Workflows (clustering)

In the 1C 8.2 platform, it was possible to manually create application server worker processes (rphost worker process). In 8.3, worker processes are created by ragent. The number of simultaneously running processes can be controlled indirectly through the settings of working servers.



When using the default settings, one rphost will be used for 8 infobases or 128 connections. If you have a 32-bit OS (i.e. there are limits on RAM consumption per process), it is recommended to change these values, for example, set one base per process and reduce the number of connections. The optimal number of connections is selected empirically and largely depends on the specific configuration and the number of background jobs.

Since we are looking at the properties of workflows, it is worth mentioning other settings:

Value in bytes (available to all cluster worker processes on this worker server).

  • -1 – no restrictions;
  • 0 – determined automatically as 80% of the server’s RAM.

Safe memory consumption per call value in bytes.

Can take a value from -1 to 9 223 372 036 854 775 807:

  • -1 – any server call is considered dangerous if the maximum memory capacity of the working process is reached during the server call;
  • 0 – the volume value is determined automatically as 5% of the maximum memory capacity of working processes on a given working server.

If during a call the amount of memory exceeds the parameter Safe memory consumption per call, and the total memory consumption of all rphost processes has exceeded the value set in Maximum memory capacity of working processes, such a call will be interrupted.

The amount of work process memory up to which the server is considered productive, measured in bytes. A value of 0 indicates that there is no limit set. The total amount of memory occupied by all worker processes on this worker server, upon reaching which new connections will no longer be assigned to this worker server.

Flag manager for each service means that a separate instance of the cluster manager (rmngr process) will be assigned to each service. List of services that run in the cluster:


Flag Central server means that this server will be able to apply connections and synchronize the cluster registry.

Workflow settings can only be used when using CORP licenses! If you have a PRO license, the settings will be available, but you will not have the rights to use them.

Consolidating servers into a cluster

1C servers can be combined into a cluster to solve problems of scalability (load distribution) and fault tolerance. It’s easy to combine servers into a cluster; you just need to create a working server.


If the “central server” option is not installed on the new server, then such a server will be considered working and will not be able to accept session connections. This architecture of server interaction is used for scalability; it cannot be fault-tolerant, since for this there must be central servers, and the level of fault tolerance must be specified in the cluster properties.



The fault tolerance level is set as the number of central servers -1.

In the settings window, you can also set restrictions on resource consumption per worker process (rphost). The settings will be set for the entire cluster.


Restart interval– interval in seconds after which the workflow will be restarted. The countdown starts from the moment this option is installed.

Allowed memory size It should be established on the basis that if the condition for exceeding the indicator is triggered, another rphost process of the same size will be launched, i.e. point in time we will have two processes until connections from the old one are switched to the new one.

Interval for exceeding the permissible amount of memory– interval in seconds during which memory consumption set in the parameter is allowed Allowed memory size.

Interval for exceeding the permissible amount of memory. If the value of the Server Error Count Tolerance property is 0, then the error count variance check is not performed. Regardless of the value set for this property, a workflow that makes no more than 1 error per 100 requests is considered to be functioning normally and is not considered problematic. Let's look at an example of how the Tolerable deviation in the number of server errors property works. Let’s say that for 100 requests, on average, 2 errors are recorded in the last 5 minutes. If the Permissible deviation in the number of server errors property is set to 50, then the workflow for which more than 3 errors are recorded per 100 requests will be considered problematic.

Processes are restarted “softly”:

  • A new rphost process is started;
  • The old rphost process is killed but not terminated;
  • Connections are assigned to the newly created rphost process, which is immediately fully operational;
  • The old process will support existing calls on it. Already assigned calls will be supported for the time specified in the parameter “Stop processes that are turned off after” seconds

When combining several servers into a cluster, we can move certain services to separate servers. For example, we can move the work of background jobs to a separate server or create a licensing server (a server that will distribute client licenses). A complete list of services that the server performs and that can be reassigned:


Assigning a service to a specific production server is accomplished through functionality assignment requirements.



The article discussed the main capabilities of the administration console, but this topic is very extensive and comprehensive information about the specific functionality of the administration utility can be found on ITS.

Hello dear readers.

Today we'll talk about funds Server administration 1C:Enterprise.

1C:Enterprise supports the following:
Client - server version of work
File version of work

When working in client-server mode, a three-level architecture is used using a cluster of 1C:Enterprise servers, through which communication between the client part of 1C:Enterprise and the DBMS is carried out.

Server 1C does not have its own user interface; various tools can be used to control it; let’s consider the standard Client-server administration utility, it can be installed at .

Utility server administration 1C:Enterprise or 1C server console

The main tasks of the 1C server console:

  • Creating, deleting and changing production servers;
  • Creation of administrators;
  • Creating and deleting cluster worker processes;
  • Creating and deleting information security
  • Forced termination of the session;
  • Blocking new connections.

Let's briefly consider the main points of the 1C servers administration console:

Create a Central 1C server

To add a new Central Server 1C:Enterprise 8.2 we will use the context menu by first highlighting the line Central 1C servers

A window will appear where you need to enter the name of the 1C server or its IP address.

Creation of 1C server administrators

IN branches Administrators server administrators are added. Administrators have rights to administer only their own server; you do not need to be an administrator to manage the cluster. If no Administrator is added, then everyone who logs in will be able to manage the server.

Creating 1C cluster workflows

Working servers This is where worker processes are added and removed, allowing you to influence the performance of user sessions by distributing them across worker processes.

If you look at the process properties, you will see the following:
Performance: a number up to 1000 is indicated, the default value is 1000. New sessions are attached to the process that has the maximum performance and once every N minutes the system itself looks at the actual processor load and rearranges the performance number.
Property Enabled: here the activity of the process is monitored and can take the following values: Use, Don't use, Use as backup

Creating and deleting information security

In the thread Information bases connected databases are visible, it is possible to delete a database or create a new one.
If we look at the properties of the database, we will see the following:

Session start blocking is enabled– sets a ban on connecting to this database.
Message– issued when trying to join while blocked.
Permission code– allows a connection to be made when connections are blocked.

Ending a 1C user session

In general Sessions branch you can view the list of sessions for the entire cluster; to view sessions for a separate infobase, you need to select the desired information security and view its Sessions.


In most cases, to install 1C:Enterprise 8.x in the client-server version, it is enough to run the 1C:Enterprise 8.x installation program. In this case, the 1C:Enterprise server receives standard parameter values ​​necessary for its normal functioning.

Let's look at installing the 1C:Enterprise server in more detail. During the installation of the 1C:Enterprise 8.x server, the 1C:Enterprise 8.x installation program performs the following actions:

* Copies the 1C:Enterprise server boot modules to the directory specified by the 1C:Enterprise installation program as the final folder.
* If "Create user USR1CV81" is selected during installation, creates user USR1CV81. The 1C:Enterprise 8.1 server runs on behalf of this user if it is launched as a service. It has access only to those resources that the 1C:Enterprise server needs. It is important that the 1C:Enterprise server requires two directories to operate: a general directory with server data (usually "C:\Program Files\1cv81\server") and a directory of temporary files (usually "C:\Documents and Settings\usr1cv81\Local Settings \Temp" or "C:\WINNT\Temp"). User USR1CV81 receives rights to the shared directory with server data. The temporary files directory is usually accessible to all users.
* If during the installation process "Install 1C:Enterprise 8.1 server as a Windows service" is enabled, then it registers the 1C:Enterprise server agent service in Windows and starts it. At the first launch, a cluster of 1C:Enterprise servers is created with default settings. It has one worker server and one worker process. The working server address matches the name of the computer on which the installation was performed.

USR1CV81 or USR1CV82 user and his rights

1C:Enterprise Server is a server application whose operation should not depend on which user is logged into the server computer in interactive mode, if anyone is logged in at all. Therefore, when installing a 1C:Enterprise server, it is advisable to create a special user USR1CV81, endowed with the minimum rights required for the 1C:Enterprise server, and not intended for interactive login. The 1C:Enterprise server is presented to the Windows system by user USR1CV81.

Let's take a closer look at the rights set for the user USR1CV81. 1C:Enterprise server uses the following directories:

* The directory of loading modules is located in the directory specified by the 1C:Enterprise installation program as the final folder. It contains the loading modules of the 1C:Enterprise server. User USR1CV81 requires rights to read data and run programs from this directory and its subdirectories. It receives these rights implicitly by being included in the Users group.
* The server data directory is usually named "C:\Program Files\1cv81\server". User USR1CV81 requires full rights to this directory. When creating the user USR1CV81, the 1C:Enterprise installation program gives him rights to this directory.
* The temporary files directory is usually named "C:\Documents and Settings\usr1cv81\Local Settings\Temp" or "C:\WINNT\Temp", which is determined by the value of the user's environment TEMP variable or the system environment TEMP variable. You can view the value of this variable in the System Properties dialog (Start -> Settings -> Control Panel -> System -> Advanced -> Environment Variables). The 1C:Enterprise installation program gives user USR1CV81 full rights to this directory. Typically, when installing Windows, the temporary files directory is accessible to all users by including the CREATOR OWNER group in its access list. However, this access is not full. In particular, searching for files in this directory is not available to all users. Setting user USR1CV81 full rights to the temporary files directory allows the 1C:Enterprise server to perform all the operations it needs. You can view the access list in the directory properties dialog on the Security tab. The presence of the CREATOR OWNER group allows access to the directory by any user who creates any files in this directory or owns any files in this directory. In this case, in the access list of the created file, instead of the CREATOR OWNER group, the user who created the file will be written. Among the users who are allowed access to this directory, there must be user USR1CV81, who has full rights to this directory.
It is important to keep in mind that the temporary files directory for a given user (including user USR1CV81) is determined by a combination of that user's environment variables and system environment variables. To find out this directory, the 1C:Enterprise installation program requests the user context USR1CV81. To do this in Windows 2000, the user on whose behalf the 1C:Enterprise installation program is launched may need the following privileges: Act as part of the operating system and Bypass traverse checking. You can check user privileges using the Local Sequrity Settings utility in the Local Policies -> User Rights Assignment branch. When installing new software, the installer usually gains these privileges automatically.

Registering a 1C:Enterprise server as a Windows service

1C:Enterprise Server is a simple Windows console application and can be launched interactively. However, for constant use this is inconvenient, since it requires the launch of the 1C:Enterprise server from the login of an inactive user to the server computer. To eliminate this dependency, the 1C:Enterprise server can be launched as a Windows service. To do this, it must be registered in the Windows service manager.

To view a list of Windows services and their parameters, use the Component Services utility (Start -> Settings -> Control Panel -> Administrative Tools -> Services). The 1C:Enterprise server is represented in the list of services by the service "1C:Enterprise Server Agent 8.1". The service parameters determine the launch of the 1C:Enterprise Server Agent process (ragent), the user under whose name it is launched, and the method of restarting in emergency situations.

In the properties dialog of the "1C:Enterprise 8.1 Server Agent" service, on the General tab, the line for launching the ragent process, which is the 1C:Enterprise Server Agent, is shown. Typically this line looks like:


It states that:

* the Server Agent process is the boot module "C:\Program Files\1cv81\bin\ragent.exe";
* the ragent process runs as a Windows service and must be managed by a service manager (-srvc);
* used as 1C:Enterprise Server Agent (-agent);
* when starting the service for the first time, a cluster must be created with default parameters and main IP port number 1541 (-regport 1541). Using this port, client applications must connect to infobases registered in the cluster;
* The server agent IP port must be numbered 1540 (-port 1540). Using this port, the Cluster Console must connect to the central server to perform administrative functions;
* when cluster processes are launched on this server, they will be dynamically assigned IP ports from the range 1560-1591 (-range 1560:1591).
* general cluster data will be located in the "C:\Program Files\1cv81\server" directory (-d "C:\Program Files\1cv81\server").

The "1C:Enterprise 8.1 Server Agent" service can be added or removed not only when installing or uninstalling 1C:Enterprise using the 1C:Enterprise 8.1 installation program, but also manually. To do this, you can run the ragent utility from the command line, specifying the appropriate parameters.

To create a service, you need to specify the -instsrvc parameter and the following parameters: -usr - the name of the user under whose name the service should be launched, -pwd - the password of this user. In this case, the remaining parameters will become the launch line parameters of the 1C:Enterprise Server Agent as a service. For example, for standard registration of the 1C:Enterprise Server Agent service in debug mode, the set of parameters should be as follows:

"C:\Program Files\1cv81\bin\ragent.exe" -instsrvc -usr .\USR1CV81 -pwd Password -regport 1541 -port 1540 -range 1560:1591 -d "C:\Program Files\1cv81\server" - debug

To remove a service, you need to specify the -rmsrvc parameter. For example:
"C:\Program Files\1cv81\bin\ragent.exe" -rmsrvc

Sometimes it is useful to change the Server Agent startup line or other parameters of the Agent service, for example, enable debugging mode, or create several services of different versions. The service properties dialog does not allow you to edit the service application launch line and some other parameters, for example, the service identifier. To edit, you will need the regedit utility, designed to view and edit the Windows system registry.

Attention!
Editing the Windows system registry requires extreme caution, since erroneous changes to it can render the operating system inoperable.

Run the regedit utility (open Start -> Run and type regedit) and select the branch:


Among its parameters is the ImagePath parameter, the value of which is the startup string of the 1C:Enterprise Server Agent. Here you can add new launch string parameters or change the values ​​of existing ones. A complete list of possible parameters is given in the book "1C:Enterprise 8.1 Client-Server" documentation.

If you need to register several independent 1C:Enterprise Server Agent services, you need to specify different boot modules, different ports and different cluster data directories for them. You also need to register them with different service identifiers. This can be done like this:

* Create the first service:
"C:\Program Files\1cv81\bin\ragent.exe" -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d "C:\Program Files\1cv81\server"

* Using the regedit utility, change the identifier of the registered service. To do this: select a branch
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\1C:Enterprise 8.1 Server Agent

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\1C:Enterprise 8.1 Server Agent First
* Create a second service:
"C:\Program Files\1cv81_10\bin\ragent.exe" -srvc -agent -regport 1641 -port 1640 -range 1660:1691 -d "C:\Program Files\1cv81_10\server"

* Perhaps his ID should also be changed. To do this: select a branch
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\1C:Enterprise 8.1 Server Agent
and change its name, for example to:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\1C:Enterprise 8.1 Server Agent Second

What can't the 1C:Enterprise installation program do?

As already mentioned, the 1C:Enterprise installation program copies the 1C:Enterprise boot modules and performs the necessary registration in COM and in the Windows service manager. The above is information necessary to understand the internal mechanisms of this registration. If not only the server is installed on the server computer, but also the client part of 1C:Enterprise, then it is ready to work immediately after installation (and connecting the security keys).

In order for the 1C:Enterprise server to be accessible from other computers on the local network, you need to check the network settings on the server and client computers, as well as for the network as a whole. TCP/IP is used to transfer data between client applications and the 1C:Enterprise server, as well as between server cluster processes. The operation of 1C:Enterprise in the client-server version depends on its correct configuration.

Processes of a 1C:Enterprise server cluster connect to each other at the addresses defined as the values ​​of the “Computer” property in the properties dialog of working servers. The cluster requires that the value of the Computer property be either an IP address in dot notation or a symbolic address from which the IP address can be determined using the gethostbyname function defined in the TCP API. The IP address is determined either based on the local table of symbolic addresses (C:\WINNT\system32\drivers\etc\hosts) or on the address tables in available DNS servers. If the symbolic address of the working server does not determine its IP address or determines it incorrectly (for example, the IP address does not match the actual IP address of this computer), then the cluster will not work. It is important that the names of computers and their addresses defined in Windows on each of the working servers in the cluster do not contradict their names in DNS.

On each working server, cluster processes use the following ports: IP port of the working server (usually 1540); IP ports from the workflow IP port ranges (usually 1560-1591). Additionally, the cluster's central server uses the cluster port (usually 1541). If the system uses firewalls, then data transmission on these ports must be allowed. Instead of allowing ports from the list above, you can allow data transfer to cluster processes (ragent, rmngr, rphost).

The connection between the 1C:Enterprise client application and the server is performed in 2 stages. It first establishes a connection to the cluster manager. This uses the central server address (symbolic or numeric) and the cluster port (usually 1541). Next, the client application establishes a connection with one of the worker processes. The value of the "Computer" property of the corresponding working server and the working process port, which is selected from the range of IP ports of the working server, are used as its address. Data transmission to these ports must be allowed in all firewalls along the route from the client application computer to the computers of the 1C:Enterprise server cluster. The IP address of server processes is determined using the gethostbyname function on the client computer. It is important that the names of the central and working servers and their addresses defined in Windows on each of the servers in the cluster do not contradict their names in the DNS accessible to the client computer.

And one last thing. Obviously, in order to successfully access the 1C:Enterprise server from other computers, it must be on the network and the necessary settings must be made for this. Connecting to a network and setting up methods relate to the administration of networks based on Microsoft Windows and are described in the corresponding instructions.

Features of setting up a SQL server

1C:Enterprise in the “client-server” version uses a SQL server to store data. In this case, only 1C:Enterprise Server accesses the SQL server. 1C:Enterprise clients do not have direct access to the SQL server. Installing and configuring a SQL server is described in detail in the Microsoft SQL Server documentation. For the successful operation of 1C:Enterprise Server with a SQL server, you need to pay special attention to the following settings.

* Required SQL server components. To access the SQL server from the 1C:Enterprise Server side, Microsoft Data Access 2.6 or later components must be installed on the 1C:Enterprise Server computer.
* User authentication by SQL server. Access rights to SQL server databases are determined by the user on whose behalf the databases are accessed. From the computer on which the SQL server is installed, launch the SQL Server Enterprise Manager utility, find the Local node (Console Root -> Microsoft SQL Servers -> SQL Server Group -> (Local)) and open its properties. On the Sequrity tab you can see that the SQL server supports two methods of user authentication: SQL Server and Windows and Windows only. Windows authentication will allow the 1C:Enterprise Server to access the SQL server only on behalf of the user USR1CV81, which does not allow differentiating access rights to different infobases served by one 1C:Enterprise server. It is recommended to select the SQL Server and Windows mode. In this case, access to a specific infobase will be performed on behalf of the user who was specified as the SQL server user when creating this infobase. It is important that this user must have not only full rights to the infobase database, but also rights to create databases in the SQL server and to read Master database tables.
* Network protocols for accessing the SQL server. If 1C:Enterprise Server and the SQL server are located on different computers, then you need to configure the network access protocols to the SQL server. This can be done using the SQL Server Client Network Utility. On the General tab, you can select a list of network protocols used to access the SQL server. The fastest and most versatile is to use the TCP/IP protocol. When using other protocols, you must keep in mind that some of them, for example Named Pipes, perform additional authentication using Windows tools when exchanging data with the SQL server. In this case, to successfully work with the SQL server, the user USR1CV81 must be registered on the computer with the SQL server, with the appropriate rights. The access protocol for this SQL server can be changed on the Alias ​​tab.

In addition to the article

There is no doubt that the combination of MS SQL Server + 1C: Enterprise 8 server is the most popular and frequently used combination in its niche. For its high-quality support, an understanding of both products is desirable. At the same time, in practice, a support specialist usually either specializes in administering MS SQL Server and is not familiar with the features of the 1C: Enterprise 8 server, or, conversely, specializes in administering the 1C: Enterprise 8 server and is not familiar with the features MS SQL Server.

This article was written to help both those and other specialists, designed to save your time and draw your attention to the most important details when using these software products together.

To make the information easier to understand, case studies, notes and tips are provided (in italics).

Three-link circuit

As the reader may already know, the database in the case under consideration has a three-tier architecture:

Link 1: MS SQL Server DBMS. “Stores” and maintains the database, ultimately performing all types of database operations. Thus, the performance of the database, the speed and parallelism of reading and writing data are largely determined by the performance of MS SQL Server.

Link 2: Server "1C: Enterprise 8". Serves as an intermediary in the interaction between clients (users) and MS SQL Server. All client requests are sent to the server, which “translates” them into the MS SQL Server query language, receives the results of executing these queries, and sends the results to the client.

There is only a small part of the operations that are performed at the 1C: Enterprise 8 server level, without accessing MS SQL - this is, in particular, tracking the so-called “managed locks”, reading and writing “session parameters”. In such cases, access to the DBMS is not required, since these operations are performed not with database data, but with auxiliary server information.

Link 3: Client part of "1C: Enterprise 8". Accesses the 1C: Enterprise 8 server, receives results from it (that is, for example, data samples), and is responsible for the user interface.

"I wanted the best."

After reinstalling the 1C: Enterprise 8 server, users complain of a sharp drop in performance. The 1C: Enterprise software implementation specialist who carried out the reinstallation is only surprised - they say he wanted the best, the system should have started working faster... Analysis of the situation showed that the 1C: Enterprise 8 server was allocated too many resources: it processes (see point 3) rphost occupied 15.5 GB of the server’s 16 GB of RAM, as a result, there was practically no available RAM for the compliant MS SQL Server.

The result is a constant "swap", an unnecessary load on the disk subsystem, and extremely slow execution of database operations - due to the fact that MS SQL Server does not have time to process requests coming from the "overclocked" 1C: Enterprise 8 server.

Product Compatibility

Current information about versions of MS SQL Server recommended for use in conjunction with 1C: Enterprise 8 should be found at this link http://v8.1c.ru/requirements/.

At the time of writing this article, 1C developers recommend the following options:

      1. SQL Server 2008 R2.
      2. SQL Server 2008, requires installation of Service Pack 1 (SP1).
    3. SQL Server 2005, requires installation of Service Pack 3 (SP3).



It is technically possible, but not recommended, to use MS SQL Server 2000; it requires installation of Service Pack 2 (SP2), and installation of Service Pack 4 (SP4) is desirable.

Please note that this version is currently deprecated and does not have a 64-bit version for x86-64 architecture.

Note:

It is necessary to pay attention to the operating system settings: for example, for effective operation of M SQL Server 2008 under Server 2008R2 OS, you need to disable the balanced power supply mode and switch to maximum performance mode.

Installing the client-server version of "1C: Enterprise 8"

"1C installed"

For one of the customers, the installation of 1C: Enterprise 8 was carried out by a system administrator who had no experience working with 1C: Enterprise 8. And although, according to him, he “installed 1C”, there was no client part on the user computers, and there was no server part on the server. Analysis of the situation clarified the picture - the 1C: Enterprise 8 kit included 2 disks - installation of the platform and installation of database templates. The administrator did not delve into the installation procedure - and installed database templates, rather than executable files, platform components.

Of course, this is an atypical example of an exceptionally inattentive attitude to work.

When installing "1C: Enterprise 8" you should take into account that the following are installed separately:

      The 1C: Enterprise 8 platform is an executable application, an integrated environment for the development and operation of databases. When you launch it, you select one of two operating modes - “Enterprise” (user database shell) or “Configurator” (integrated development environment). A more complete description can be read at the link
      "1C: Enterprise" configuration templates are a file of the platform's internal format, with the help of which the platform can create a pure or demo database of the structure contained in the template. You can also use the update pattern to update the structure of an existing database that is already filled with data.
      When installing the platform, you should pay attention to the selection of components:





The 1C: Enterprise component may not be installed on the server(s).

In this case, the server will provide client computers with access to 1C: Enterprise databases, but working with the database in user mode directly from the server will not be possible.

Note:

The 64-bit version of the platform does not contain a client part. Therefore, when installing on a server, 64-bit server components are installed separately, and 32-bit client application components are installed separately.

The "1C Server: Enterprise" component is needed to connect to MS SQL Server - it is an application server, a connecting link between the platform on client workstations and MS SQL Server.

It is possible to install the component in the mode of a simple application or system service, and, of course, the second option is recommended.

When installed "as a service", this component will be launched and executed on behalf of the selected user:




After loading, the component spawns several processes, such as: “server agent”, “server cluster manager”, “server worker processes”.

Queries to the database are executed by worker processes, and the server cluster manager distributes the load between them.

Server worker processes can be managed (added, deleted, set limits on RAM usage, declared primary or backup) if the 1C: Enterprise Server Administration component is installed.



Note:

For the 32-bit version of the server, it is recommended to install working processes in such a number as not to leave RAM unused - each of them has a noticeable limitation on the use of RAM, from 2 to 4 GB depending on the system configuration.

For the 64-bit version of the server, two worker processes are theoretically sufficient - one worker and one backup. However, in practice, to ensure reliability and stability of connections for a significant (several hundred) number of users, a larger number is required, it depends on many factors - on the number of users, the content of the database and the volume of queries performed, so the authors believe that the number of processes in this case should be selected experimentally.

"Ouroboros"

After unsuccessful optimization of the 1C: Enterprise 8 server settings, users reported extremely slow system operation, and the system administrator noted a constant 100% processor load on the server.

An analysis of the situation showed the source of the problem - during configuration, too small a limit was set on the use of RAM by working processes.

But the fact is that this limitation works as follows:

When the server cluster manager sees that a worker process has exceeded the RAM limit, the process is terminated, it is disabled, a new worker process is created, and connections and user requests are redistributed between worker processes.

The limit set was so small (300MB) that the worker process could not fully service even one intensive user - as a result, the server cluster manager was constantly restarting worker processes and reconnecting users. As soon as a new process was created and users connected to it, the RAM limit was almost instantly reached and caused the next restart. This took 100% of the processor load.

The "1C Server: Enterprise" component is not needed on client workstations, and will not be able to start there, since it requires the physical presence of a security key.

If the number of connected users is small (less than 50), the application server is usually installed on the same computer where MS SQL Server is running.

For systems with a large number of users and/or a large volume of information flows, separate installation is recommended, as well as the use of a server cluster.

The "1C: Enterprise Server Administration" component can also be useful on clients - for example, with its help you can see a list of infobases connected to a given "1C: Enterprise" server.

It is strongly recommended to install it on the server itself.

Access

Note:

To verify that access is provided, it is not enough to use the 1C: Enterprise server administration utility, and even more so, the presence of the server in the “Network Neighborhood” is not enough!

It is necessary for each client to log in to the database installed on the server - only this will give 100% confidence that access is provided.

1. Depending on the security policies, MS SQL Server uses Windows account authentication or MS SQL Server account authentication.




In the latter case, when creating a 1C: Enterprise database, the system will request the login and password of the MS SQL Server account (for example, sa), in the first case the login and password should be left empty:



and the system user on whose behalf the 1C: Enterprise server is running must be given rights in MS SQL Server, namely:

      full rights to the database in which the information base is located
      access to the master database (public role)
      recommended - rights to create a database, otherwise each new database will need to be first created using MS SQL Sever, and only then connected to the 1C: Enterprise server
      recommended - right to delete your database



For example, you can assign the user in question the fixed role processadmin or sysadmin.

Advice.

If all users simultaneously lose access to the working database, you need to double-check the user rights and roles in MS SQL Server, including those set for a specific database, that is, User mapping:




2. Server 1C: Enterprise accesses MS SQL Server through the Microsoft Data Access mechanism, so its components must be installed, and the user of the server 1C: Enterprise (see the previous paragraph) must have rights to run them.

3. Communication between clients and server is supported by TCP protocol, so it is necessary that this protocol is supported by both sides. There may be problems matching the server name and its IP address, for example, if a peer-to-peer network is used. In this case, you should record the correspondence in the file [C:\WINDOWS\] system32\drivers\etc\hosts .

Advice.

If the network is peer-to-peer, to ensure a permanent connection to the server, create a network drive that accesses any of the folders of this server.

4. If the Named Pipes protocol is used, and if MS SQL Server and the 1C: Enterprise server are installed on different computers, the user on whose behalf the 1C: Enterprise server is running must be registered in the list of users of the computer on which MS SQL Server is running.

5. In some cases, additional configuration of the Windows firewall may be required, that is, adding exceptions.

6. Some antivirus programs may block “unwanted” network traffic, so you may need to add to their exclusion lists.

7. The release of the 1C: Enterprise 8 platform must be absolutely identical on the client and on the server.

"Twins"

"One of the customers used two database servers, each of which housed one working database. Users worked - each simultaneously with both databases. The support service updated the 1C: Enterprise 8 platform on servers and clients.... And then complaints started pouring in for the impossibility of connecting to one or another database. Analysis of the situation showed that several people did the update on clients and servers, and the installing specialists did not double-check that they were installing the same release. Therefore, there was one release of the platform on one server. the second - another, on half of the clients - the first of these releases, on the other half - the other. It turned out that each user has access to only one of the databases.

To quickly solve the problem, each user had to install both releases of the platform and create separate shortcuts to log into each database.

Initial settings of MS SQL Server and database

“And that’s how it works”

MS SQL Server is distinguished by its simple initial installation, so not all administrators bother with its additional configuration - after performing the default installation, the database is working, users are logged in - the job is done. This approach almost always entails the emergence of problems after about a month or two - and, of course, suddenly and at the most inconvenient moment.

For example, if the database is intended for accounting purposes, before submitting tax reports, there is often a need to urgently recalculate certain data, and recalculate en masse, say, “all receipts of fixed assets from the beginning of the year.” Moreover, during the working day, without stopping the work of other database users.

And, of course, it is at this moment that it will be discovered that during such a recalculation the database “freezes”, or “crashes”, or does not allow other users to work.

This kind of “Murphy’s law” applies to each of the following points.

Before starting to use MS SQL Server as a DBMS for 1C: Enterprise, it is recommended:

1. Set the value of the max degree of parallelism parameter to 1.

That is:

      After connecting to the server, enter the server properties through the context menu, Properties item
      then select the Advanced page and edit the max degree of parallelism parameter






Otherwise, some queries generated by the 1C: Enterprise server may cause the error "Intra-query parallelism caused your server command (process ID #XX) to deadlock. Rerun the query without intra-query parallelism by using the query hint option (maxdop 1 )". After this error, the client part often crashes.

The error will not appear consistently, since the query plan is formed differently depending on the accumulated statistics - it will manifest itself on large and complex queries, that is, at the most unfortunate moment.

2. Create a Maintenance Plan that shrinks the tempdb temporary table database on a nightly basis. The database of temporary tables is not always cleared automatically by the 1C: Enterprise server, and sometimes, as a result of an unsuccessfully written query, a temporary table of, for example, 50 GB in size may be created and not cleared. As a result, disk space may run out, as a result of which both the client and server parts may crash, and there is also a slight risk of data integrity violation.

That is, you need:

      go to MS SQL Management Studio
      after connecting to the server, expand the "Maintance plans" section
      create a new (or add to an existing) Service Plan,
      add the item "Execute T-SQL Statement task" to it (since you cannot select the tempdb database in the "Shrink database" task) with the code




1.USE
2.
3.GO
4.
5.DBCC SHRINKFILE (N"tempdev" , 0, TRUNCATEONLY)
6.
7.GO
8.
9.DBCC SHRINKFILE (N"templog" , 0, TRUNCATEONLY)
10.
11.GO

Note that the temporary table database file name may not be "tempdev". You can use a script to check this name

1.USE tempdb
2.
3.GO
4.
5.EXEC sp_helpfile
6.
7.GO




“Pot, don’t cook”

The most common way in practice to overfill tempdb and thereby crash the server is to forget to specify a condition when joining tables.

Namely, let’s say we have two tables in the database, each with 20 thousand records in size. Let's say we can establish a one-to-one correspondence between their records, and we write a query that creates a temporary table that contains 20 thousand records with fields from both source tables. But if we forget to specify the join condition, every record of the first table will be joined to every record of the second! That is, the resulting table will consist of 20’000 * 20’000 = 400 million records. And so on.

3. In order to reduce the load on the disk subsystem, it is recommended, if possible, to distribute the working database and tempdb, logs, and system swap file across different physical disks.

It is better to set the desired path for storing the working database files when creating it by editing the Path column:




To change the physical location of temporary table database files, use the ALTER DATABASE command, that is, in MS SQL Management Studio you need to run the following script ("New query" command)

1.USE master
2.
3.GO
4.
5.ALTER DATABASE tempdb
6.
7.MODIFY FILE (NAME = tempdev, FILENAME = "New_Disk:\New_Directory\tempdb.mdf")
8.
9.GO
10.
11.ALTER DATABASE tempdb

12.
13.MODIFY FILE (NAME = templog, FILENAME = "New_Disk:\New_Directory\templog.ldf")
14.
15.GO

4. The “growth” of the working database and its log should not be hampered - there should be no size limit, the “Autogrowth” property should be set as a percentage, the recommended value is 10%. Otherwise, adding data to the database, restoring from an archive, and other operations may take an unreasonably long time.

To set this property, you need to go to the database properties through the context menu, select the Files section, and open editing file properties:



5. It is recommended to enable support for the TCP/IP network protocol in MS SQL Server and disable all others, otherwise the joint operation of MS SQL Server and 1C: Enterprise server will be less stable.




6. In the same place - clear the Alias ​​section, because its installation leads to errors in the interaction between MS SQL Server and the 1C: Enterprise server.

Before starting to use the database, it is recommended:

1. When creating a database from "1C: Enterprise", set the "date offset" to 2000, otherwise an attempt to record a date earlier than 01/01/1753 (which is possible due to human factor) will cause failures in the database.

Attention! The date offset cannot be changed for an existing database!



2. Set the Recovery model to Simple, or create a Maintenance Plan, which will create a daily backup of the database and trim the transaction log (log file). Otherwise, during some operations the transaction log (log file) will grow very quickly: for example, when restructuring a database, the growth in the size of the log file can be several times larger than the size of the database itself.




3. Create a Maintenance Plan that performs the following routine tasks at least once a week:

      Creating a backup copy of the database.
      Update database statistics and clear the procedural cache (note that the autoupdate statistics property does not imply clearing the procedural cache).
      Clearing the procedural cache is not included in the standard operations of Maintenance Plans; this step must be defined as executing a script (Execute T-SQL Statement) with the following content:
      DBCC FREEPROCCACHE
      Reindexing database tables.






Of course, it makes sense to set up automatic sending of emails about successful/unsuccessful completion of tasks.




Conclusion

The issues that most often cause difficulties for system administrators and implementers of 1C: Enterprise 8 are considered in connection with the joint use of MS SQL Server and the client-server version of 1C: Enterprise 8.

The author hopes that he has covered “both sides of the coin” in a fairly consistent and accessible way.

P.S. Make backups often!

For various reasons, access to the 1C:Enterprise server may be lost, and then when we try to launch the cluster console, we will see a prompt to enter authentication data, but we will not be able to do anything:

We will not discuss the reasons that led to this. Let's start solving the problem. We need to restore access to the server in any way. It doesn’t matter whether we reset the password or select authentication data.

Let's take the fastest route. We have administrator rights on the server, so we can do it with the least amount of effort.

Solution

First of all, let's stop the "1C:Enterprise 8.2 Server Agent" service. To do this, run on the command line:

Sc stop" 1 C:Enterprise 8 . 2 Server Agent"

The same can be done through the graphical utility "Services":

Based on the file data, it can be judged that an “Adm” administrator was added to the server with a certain password. We can either replace the data with the user we need with the “correct” password, or delete the entry about the server administrator. Let's choose the last method. This is what the contents of the file now look like:

Let's start the server service. The next time you start the 1C:Enterprise server cluster console, the program will not ask for authentication data.

Bottom line

The article describes a method for resetting the administrator account for a 1C:Enterprise 8.2 server. It is worth considering that administrator accounts can be added for each infobase separately. In this case, look at the file "1CV8Reg.lst", which is usually located in the directory:

" C:Program Files (x86) 1 cv82srvinforeg_1541"

where "reg_1541" is the cluster settings directory, the directory name of which depends on its settings.

This file stores infobase settings, as well as authentication data of cluster administrators.

The authentication data of each IS coincides with the corresponding authentication data of the users of this information base. In order to open the properties of the database in the cluster, you need to enter the login and password of an information security user with administrative rights.

Now you already know what you need to do. Under no circumstances should you consider the described method of resetting 1C:Enterprise server administrator accounts as hacking, since without administrator rights nothing like this (stopping the server service, accessing the server settings directory, etc.) can be done.

If you are interested, here are some articles on a related topic, namely on the selection/recovery of passwords for users of the 1C:Enterprise 8.2 information base:

  1. "The lighter the password, the easier it is"

  2. "Entry without invitation"

  3. "Resetting accounts. We are writing a universal program in the .NET Framework"

In this article we will get acquainted with the server cluster administration server, and specifically with the utilities rac.exe And ras.exe, as well as programs deployka with the help of which it becomes possible to administer a cluster of 1C: Enterprise servers from the command line.

According to tradition, I suggest everyone who is too lazy to read to watch a webinar on this topic

Well, for the rest, welcome to the cut:

1. General information

Manage a cluster of 1C:Enterprise servers 8.3 it is possible both using the 1C servers administration console and from the command line. For these purposes it serves Server cluster administration server, which consists of two utilities: the server itself - the program rac.exe and command line utilities rac.exe, which, by accessing the previously running ras server, allows you to perform various operations with a cluster of 1C:Enterprise servers.

You can read more about this mechanism in the book “Administrator’s Guide” supplied with the platform. Client-server option" (or, accordingly, on the ITS website).

And the general scheme of how this link works looks like this:

The administration server must be same version, as the version of the 1C:Enterprise server cluster, and can be connected to one server cluster at the same time some administration servers, but a specific administration server can communicate with only one server agent.

Both the administration server and the command line utility can run on any OS supported by the 1C:Enterprise platform. But in this article we will limit ourselves to only the Windows family of operating systems.

2. Installation of administration server components

Both the server itself and the administration utility are included in the 1C:Enterprise server components. Accordingly, on a computer running the 1C:Enterprise server agent service, they should already be installed default.

To verify this, just go to the directory with the 1C:Enterprise server files and find the corresponding utilities in it (for convenience, the files can be grouped by type).

I wrote in detail about installing a 1C:Enterprise server.

To install the administration server on a computer where you previously was not The 1C:Enterprise server is installed, you need to run the 1C server installation distribution kit and select the item as part of the components "Server 1C:Enterprise 8".

Moreover, if this component is selected, in the next step the installation wizard will offer to install the 1C:Enterprise server as a Windows service. From this point of course should be abandoned by removing the corresponding flag.

After installation, you must ensure that all necessary components are present in the manner described above.

3. Starting the administration server

To obtain detailed information on the ras.exe utility, you can call help by running the command

From the help you can see that the administration server can work as in application mode, so and how Windows service(parameter service ). We can also set the network port on which the administration server will run (parameter port , default port is used 1545 ), and for cluster administration mode the mode is cluster . You can call help for this mode with the command:

rac help cluster

Then we will see that this mode specifies the address of the 1C:Enterprise server cluster agent as an argument. The default is localhost:1540.

Thus, if the administration server is launched on the same machine where the 1C:Enterprise server agent is running, it is enough to run the command

Well, if you need to connect to a server agent running, for example, on a computer with the network name Server1C, and the agent works on a non-standard port 2540 , then the command will be as follows:

rac cluster server1c:2540

4. Starting the administration server as a Windows service

Of course, in order not to start the administration server manually every time, it is convenient to start it once as a Windows service. But, unfortunately, the platform developers did not implement the ability to automatically register the corresponding service in the system, as, for example, it was done. To add a service, it is suggested to use the system utility sc. Let's look at this process in a little more detail.

Let this be a local user named USR1CV8_RAS and password Pass123

Register-ras.bat file:

@echo off rem %1 - full version number of 1C:Enterprise set SrvUserName=.\USR1CV8_RAS set SrvUserPwd="Pass123" set CtrlPort=1540 set AgentName=localhost set RASPort=1545 set SrvcName="1C:Enterprise 8.3 Remote Server" set BinPath="\"C:\Program Files\1cv8\% 1 \bin\ras.exe\" cluster --service --port=% RASPort % % AgentName % :% CtrlPort % " set Desctiption="1C:Enterprise 8.3 Remote Server" sc stop % SrvcName % sc delete % SrvcName % sc create % SrvcName % binPath= % BinPath % start= auto obj= % SrvUserName % password= % SrvUserPwd % displayname= % Desctiption %

In the file we indicate:

  • username and password under which the service will be launched - variables SrvUserName And SrvUserPwd
  • address and port of the server agent that we are going to administer - variables AgentName And CtrlPort
  • As well as the name of the service and the network port on which the administration server will run - variables RASPort And SrvcName . It makes sense to change these parameters only if you want to run several administration servers in parallel, for example, to service different 1C servers.

The only parameter of the bat file is the current version of the 1C:Enterprise platform. Thus, to create a service, launch the command line with administrator rights and run the file created earlier register-ras.bat, not forgetting to indicate the required version of the platform.

We check that a service with the specified name has appeared in the system. And we immediately launch it by selecting the appropriate item in the context menu.

This completes the installation of the administration server as a service.

5. Administering a server cluster using the rac.exe utility

So, we have installed the administration server. Interaction with the server is carried out using a special console utility rac.exe. Let's execute the command

to get help for this program.

As you can see from the help, the utility has one common argument, which specifies the address of the administration server (by default localhost:1545) and many operating modes: for administering the server cluster agent, the cluster itself, the cluster manager, worker processes, etc. Help for each mode can be called up with the corresponding command.

There is obviously no point in describing all operating modes. I will give just a few examples of work.

Getting a list of information about clusters:

Obtaining a list of infobases on a given server cluster:

Receiving a list of connections with the specified infobase:

The administration utility allows you to perform all the work required to administer a server cluster, with the exception of OS authentication for server cluster, production server, and infobase administrators.

6. Software wrappers for working with the administration server

As you can see from the examples, working from the command line with the rac utility is still a pleasure. But this mechanism was not created for manual control. For example, on the ITS website there is a Java archive that allows you to interact with the administration server from a program in Java, without the help of a console administration utility. You can download this package.

The main thing is that we have the ability to execute various instructions on a cluster of 1C servers from the command line. This means that you can add the necessary functions for interacting with a cluster of 1C:Enterprise servers to various programs, processing or scripts.

For example, among other things, something written in the language can work with the administration server. OneScript program deployka.

I have already talked about the OneScript skip engine.

You can learn more about the deployka program.

Well, the most complete overview of all available libraries and applications written in OneScript is given in this article.

7. Installation and configuration with the deployka program

The installation algorithm for OneScript and deployka is discussed in some detail in the articles at the links provided in the previous paragraph. Well, in short, it consists of the following points:

1. Download the OneScript distribution from the official website.

2. We install following the instructions of the wizard.

3. We log back into the system so that the new environment variables are applied.

4. We launch the command line with administrator rights, check that the previous steps are executed correctly by the command line

5. Installing the deployka program using the package manager opm by running the command

opm install deployka

6. We check that everything is working by calling the “deployment” help with the command

7. That's basically all. All operating modes of the program are visible on the screen. Next, read the help on the website or in the console, calling up a hint for each mode with the appropriate command:

This is how, for example, you can end all sessions in a specified infobase and then block the start of sessions.

deployka session kill -db Accounting_Demo -rac "C:\Program Files\1cv8\8.3.11.2867\bin\rac.exe" -db-user "AbramovGS (director)"

8. Now you can use the “deployment” in your scripts. For example, a script for updating an infobase from a repository, disconnecting users and updating the database might look like this:

@echo on rem Set the values ​​of variables set ServerName="1CAPP:2541" set RacPath="C:\Program Files\1cv8\8.3.11.2954\bin\rac.exe" set uccode="123" set BaseName="ERP_Test" set UserName="Admin" set UserPass ="Pass123" set ConStr="/1CAPP:2541\ERP_Test" set RepoPath="tcp://1CAPP/ERP_DEV" set RepoUserName="test" set RepoUserPass="123" rem Terminate users call deployka session kill -db % BaseName % -db-user % UserName % -db-pwd % UserPass % -rac % RacPath % -lockuccode % uccode % rem Update the database configuration from the repository call deployka loadrepo % ConStr % % RepoPath % -db-user % UserName % -db-pwd % UserPass % -storage-user % RepoUserName % -storage-pwd % RepoUserPass % -uccode % uccode % rem Update the database configuration call deployka dbupdate % ConStr % -db-user % UserName % -db-pwd % UserPass % -uccode % uccode % rem Unlock sessions call deployka session unlock -db % BaseName % -db-user % UserName % -db-pwd % UserPass % -rac % RacPath % -lockuccode % uccode %

Thanks to everyone who read to the end. Write if you have any questions.

Did this article help you?