Which server for 1s 83. Solutions

Client-server version of work- one of the options for operating the 1C:Enterprise 8 system.

The client-server version of the work is intended for use in workgroups or on an enterprise scale. It is implemented based on a three-tier client-server architecture.

The client-server architecture divides the entire working system into three different parts that interact with each other in a certain way:

The program running for the user (client application) interacts with the 1C:Enterprise 8 server cluster, and the cluster, if necessary, accesses the database server.

In this case, the physical cluster of 1C:Enterprise 8 servers and the database server can be located either on the same computer or on different ones. This allows the administrator to distribute the load between servers if necessary.

Using a 1C:Enterprise 8 server cluster allows you to concentrate the most extensive data processing operations on it. For example, when executing even very complex queries, the program running for the user will receive only the selection it needs, and all intermediate processing will be performed on the server. Typically, increasing the capacity of a server cluster is much easier than upgrading the entire fleet of client machines.

Another important aspect of using a 3-tier architecture is ease of administration and streamlining user access to the information base. In this option, the user does not need to be aware of the physical location of the configuration or database. All access is carried out through a cluster of 1C:Enterprise 8 servers. When accessing a particular infobase, the user must specify only the cluster name and the infobase name, and the system requests the user name and password, respectively.

1C:Enterprise 8 uses the capabilities of a database management system to efficiently retrieve information:

  • the query mechanism is focused on maximum use DBMS for performing calculations and generating reports,
  • viewing large dynamic lists is provided without executing large quantity database calls; at the same time the user is given the opportunity effective search, as well as selection and sorting settings.

Deploying the client-server option and administering it is quite simple. For example, the creation of a database is carried out directly during the launch of the configurator (the same as for the file version).

Client Applications

Working in a client-server version is possible either directly with the cluster or through a web server. Moreover, in the case of direct connection to the cluster, the thick client and thin client use the TCP/IP protocol. When connecting via a web server, the thin client and web client use the HTTP or HTTPS protocol.

Server cluster

The 1C:Enterprise 8 server cluster is the main component of the platform, ensuring interaction between users and the database management system in a client-server mode. The presence of a cluster allows you to ensure uninterrupted, fault-tolerant, competitive operation of a large number of users with large information databases.

Database server

The following can be used as a database server:

Server cluster administration

The platform includes a set of various tools that allow the administrator to manage the composition of the cluster, information databases and user connections.

Performing basic functionality on the server

All work with application objects, reading and writing the database is performed only on the server. The functionality of forms and command interface is also implemented on the server.

The server prepares form data, arranges elements, and records form data after changes. The client displays a form already prepared on the server, enters data and calls the server to record the entered data and other necessary actions.

Similarly, the command interface is formed on the server and displayed on the client. Also, reports are generated entirely on the server and displayed on the client.

At the same time, the platform mechanisms are focused on minimizing the amount of data transferred to the client computer. For example, list data tabular parts and reports are not transferred from the server immediately, but as the user views them.

The server runs:

  • Database queries
  • Data recording,
  • Carrying out documents,
  • Various calculations
  • Performing processing,
  • Generation of reports,
  • Preparing forms for display.

Runs on the client:

  • Receiving and opening forms,
  • Form display,
  • “Communication” with the user (warnings, questions...),
  • Small calculations in forms that require a quick response (for example, multiplying price by quantity),
  • Working with local files,
  • Working with commercial equipment.

Using the built-in language on the client

You can manage the functionality of forms not only on the server, but also on the client. The client supports the built-in language. It is used in cases where it is necessary to carry out calculations related to the form displayed on the screen, for example, to quickly (without contacting the server) calculate the amount of a document line based on price and quantity; ask the user a question and process the answer; read file from file system computer and send it to the server.

However, the operation of the built-in language on the client is supported to a strictly limited extent. Client procedures in modules are explicitly separated from server procedures, and they use a limited composition of the object model of the built-in language.

Direct work with the database is not allowed on the client. Working directly with application objects is not allowed; for example, such types of built-in language as DirectoryObject.<имя> . Requests are not allowed. If you need to call actions with data in client code, you need to call server procedures that will already access the data.

Today, the financial product 1C has grown from an accounting application program for accounting into a wide-format complex for accounting and support of almost any type of business, claiming to compete with the world “monsters” SAP R/3 and Microsoft Dynamics AX (Axapta).

Russian companies are increasingly organizing their business processes using modern configurations 1C 8.3 “Trade Management”, “Production Management”, “ERP Enterprise Management” and the like. The accounting, marketing, production, and sales departments are being transferred to 1C, and integration with IP telephony and document management systems is being carried out. However, immediately after the intentions “let’s work in 1C”, questions arise - what resources will the central 1C database work on, what hardware will show the optimal result for a reasonable budget? In this situation, it is easier for giant public sector enterprises - a clear command has been given to numerous full-time IT integrators and architects, the mechanisms of large-budget tenders have begun, with the obligatory condition of providing a turnkey concept and further support of the system by certified specialists. But what about companies that want to purchase and install one of the 1C: Enterprise products themselves, spending their budget wisely?

The most basic mistake, if you do not take into account the use of pirated or untested software, is saving on hardware for 1C. Similar trends are especially common in startups and small companies. There is an opinion that it is not necessary to buy expensive server equipment with processors like Intel Xeon, there is no need to pre-calculate the amount of RAM, the load on the CPU and disk subsystem, that there is no need to create redundant disk arrays (Raid), use professional disk controllers with Cache-RAM, and so on. Errors in IT architecture calculations for 1C lead to dire consequences, which the company learns about after business processes have stopped. Therefore, it is very important to pay attention to each hardware node of the server platform for 1C.

Examples typical problems due to incorrect construction of the IT architecture for 1C:
  • “Slowdown” of the 1C database and interfaces due to excess load on key resources (usually RAM or disk subsystem).
  • Errors and crashes of the 1C program due to instability of incorrectly selected equipment.
  • Downtime of the company due to the failure of central hardware.
  • Partial or complete loss of 1C data due to random hardware failures or software.

1C server hardware resources

Let's consider below the most key hardware resources, an error in the selection of which can ruin the entire enterprise automation project when you independently create a server for 1C.

Central Processing Unit (CPU)

Number of physical CPU cores. The topic of eternal debate on various 1C forums is what is more important CPU frequency or multi-core. The roots of these contradictions go back to 1C 8.0 or even 1C 7.7. Indeed, the executable processes of 1C earlier versions were purely single-core, i.e. no matter how many cores the central processor provides, the 1C 8.0 enterprise server service or the 1C 7.7 thick client always occupied only one “zero” core in the operating system. Today, the picture has changed - the operating system boldly distributes the tasks of one 1C: Enterprise process (rphost) across several CPU cores (see Figure 1).




Figure 1 - CPU load when 1C server processes are running.


But this absolutely does not mean that if you buy a processor with the maximum number of cores, then a 1C server paired with a DBMS (most often by DBMS we mean MS SQL) will show fantastic performance and re-running accounting periods in the 1C program will be a matter of a few minutes. You need to understand the difference between the speed of performing one operation and the process of simultaneous processing of a large amount of information. The number of physical cores just allows us to solve the issue of stability and performance of simultaneous work with many different tasks by the 1C:Enterprise server and the DBMS. Hence the conclusion - the greater the number of 1C users, the more important the required number of cores will play for the comfortable simultaneous work of these same users. The dependence of the number of users on the number of cores for the 1C server is shown in Table 1.


Number of concurrent users on the 1C:Enterprise server Processor type and model Number of cores used
Up to 10 users Custom Intel Core from 3.1Ghz No more than 2-4
Up to 20 users Server Intel Xeon from 2.4 Ghz From 4 to 6
Up to 30 users Server Intel Xeon from 2.6 Ghz 6 to 8 cores
Up to 50 users Server Intel Xeon from 2.4 Ghz – 2 pcs. From 4 per processor

Table 1 - The ratio of the number of users on the 1C server and the recommended number of CPU cores.


CPU frequency. As opposed to the number of cores, the frequency of the central processor affects precisely the processing speed of one piece of a task at one time, which is the most popular criterion for 1C end users. The processor frequency is precisely the parameter that, when increased, will increase the speed of processing requests by the 1C server and the DBMS for an individual user and reduce the time during which the system provides the final result to the end user. In confirmation of this, the well-known specialist Gilev, in one of his articles based on practical tests, made an unambiguous conclusion - “the speed of 1C is much more influenced by the frequency of the central processor than its other parameters, be it the 1C end client or the 1C: Enterprise server.” This is the architecture of the 1C program.

Cache, virtualization and hyper threading. In the past, when multi-core processors were not yet so common, Intel came up with a special central processor technology that simulated multi-cores, the so-called “hyperthreading”. After enabling it, one physical processor (one physical core) is defined by the operating system as two separate processors (two logical cores). We recommend disabling “hyperthreading” for the 1C server. This technology does not bring any acceleration to 1C.

When using virtual machines for a 1C:Enterprise server and a DBMS, you need to take into account that the cores of virtual machines are “weaker” than real physical cores, although they are called the same – “cores”. There are no exact official coefficients, but articles on Microsoft technical portals recommend counting 4-6 processor cores per physical core in a virtual machine.

A cache is an advanced memory used by the processor to reduce the average access time to computer memory. In fact, it is an integral part of the processor, since it is located on the same chip and is part of the functional blocks. Everything is very clear here - the larger the cache size, the larger “pieces” of information the processor can process. Typically, the size of the cache depends on the processor model - the more expensive the model, the usually larger the amount of cache memory. However, we do not believe that the size of the processor cache radically affects the performance of the 1C server and DBMS. Rather, this belongs to the area of ​​“fine tuning”.

Processor type. Everyone knows that Hardware divided into server and user. Is it possible in some cases to use an inexpensive user central processor as an alternative to a professional, but expensive server CPU? It turns out that it is possible. Let's look at a table comparing the main parameters of two versions of Intel central processors (see Table 2).

Custom Intel® Core™ i7-6700T Processor (8M Cache, up to 3.60 GHz) Server Intel® Xeon® Processor E5-2680 v2 (25M Cache, 2.80 GHz)
Cache memory 8MB 25 MB
Frequency system bus 8 GT/s DMI3 8 GT/s QPI
Command set 64-bit SSE4.1/4.2, AVX 2.0 64-bit AVX 2.0
Number of Cores 4 10
Base processor clock speed 2.8 GHz 2.8 GHz
Max. amount and type of RAM 64 GB non-ECC 768 GB ECC
Estimated cost 354$ 1 280$

Table 2 - Comparison of the main parameters of home and server CPUs from Intel.


As we can see, the server processor has much higher values ​​in the number of cores, cache size, support for more RAM and, of course, a higher price. However, a server CPU is practically no different from a user CPU in support of certain processor commands (instructions) and clock speed. From this we can conclude that for small organizations it is quite acceptable to use a custom central processor for the 1C:Enterprise server. The only question is that the user processor cannot be installed in the server socket motherboard and support server RAM with parity control (ECC), and the use of custom components entails risks to the stability of the entire system as a whole.

Random access memory (RAM)

Type of RAM. Random access memory (RAM) varies according to its purpose - for multi-user server systems or for personal devices - PCs, laptops, nettops, thin clients, etc. As in the case of the CPU - the main parameters of RAM modules are approximately equivalent - modern RAM for a PC practically does not lag behind the server RAM either in the volume of one strip, or in the clock frequency, or in the type of DDR modules. The differences between server RAM and “home” RAM are in the use cases and purpose of the hardware platform - hence its higher cost:

  • Server RAM has parity control ECC (Error Correction Code) - an encoding/decoding technique that allows you to correct errors in information processing directly by the RAM module
  • A server motherboard has many more slots for installing RAM modules than a regular PC.
  • Server RAM contains registers (buffers) that provide data buffering (partial Registered or full Full Buffered), thereby reducing the load on the memory controller with many simultaneous requests. Buffered FB-DIMMs are not compatible with unbuffered ones.
  • Registered memory modules also allow for increased memory scalability - the presence of registers makes it possible to install more modules in one channel.

We can conclude that the use of server RAM modules makes it possible to install large amounts of RAM in one system, and ECC parity control techniques and the use of buffers allow the server operating system to work stably and quickly.

Amount of RAM. One of the key factors for high performance of the 1C server and DBMS is a sufficient amount of RAM. Of course, the actual RAM needs depend on many factors - the type of 1C configuration, the number of 1C:Enterprise server processes, the size of the DBMS database, and so on. However, it is possible to derive an approximate dependence of the amount of RAM on the number of users (see Table 3).


RAM requirements for 1c server and DBMS Up to 10 users Up to 20 users Up to 30 users Up to 50 users
Server 1c:Enterprise 4-6 GB 6-8 GB 12-14 GB 18-24 GB
MS SQL Server 4-6 GB 8-10 GB 16-18 GB 24-28 GB

Table 3 - Approximate ratio of the number of 1C server users and recommended RAM for 1C:Enterprise server processes and MS SQL server.


Regarding 1C:Enterprise server processes (rphost.exe) - modern 1C platforms do not allow manual mode indicate the number of 1C server processes. Instead, the system requires you to set parameters such as the number of infobases and the number of users per rphost.exe process, after which it automatically determines the optimal number of 1C:Enterprise server processes. You can also configure the rphost.exe process to smoothly release RAM if its volume exceeds a predetermined threshold. In this case, the 1C server creates a new process rphost.exe, which gradually takes over 1C tasks, allowing the required 1C process to be offloaded.

You should also pay attention that the amount of RAM allocated to the SQL service is considered sufficient if the SQL data in the cache is at least 90%. This metric is quite convenient, because... You can’t just look at the amount of RAM consumed by the SQL server – latest issues SQL has dynamically consumed RAM - it grabs as much RAM as possible and releases it as RAM is requested by other processes.

RAM frequency. In short, this is the bandwidth of the channels through which data is transmitted to the motherboard, and from there to the processor. It is desirable that this parameter matches or exceeds the permissible frequency of the motherboard, otherwise the RAM transmission channel risks becoming a bottleneck. Within one type of DDR, increasing/decreasing the frequency does not fundamentally affect the performance of the 1C server and belongs more to the area of ​​“fine tuning”.

RAM timings. This is the latency or latency of the RAM. This parameter is characterized by the data delay time during the transition between different modules of the RAM chip. Lower values ​​mean faster performance. However, the impact on the overall performance of the server system, and even more so on the 1C:Enterprise server, is low. Typically, only gamers and overclockers pay attention to these parameters, for whom every extra drop of performance is most valuable.

Disk subsystem and HDD hard drives

Controllers hard drives. The main device for connecting and organizing hard drives in a hardware system is the hard drive controller. It comes in two types:

1. Built-in – the controller module is built into the system, the hard drive cage is connected directly to the motherboard. It is considered a more economical solution.

2. External – represents a separate printed circuit board(device) that connects to the motherboard connector. It is considered a more professional solution due to the fact that it has separate chips for conducting and controlling operations with hard HDD drives. Recommended for important server systems, such as 1C:Enterprise server and DBMS.

There is also a third type - a device for receiving/transmitting block data via iSCSI, FiberChanel, InfiniBand, SAS channels. However, in this option, the disk subsystem is “removed” to a separate data storage device (DSD), connected to the server via an optical or copper cable. In our article we analyze the requirements for a standalone server for 1C, so we will not consider this type.

Types and levels of RAID arrays. It is a data virtualization technology that combines multiple disks into a logical unit for redundancy and improved performance. Let's look at the most popular levels of the RAID specification:

  • RAID 0 (“Striping”) It has no redundancy, and distributes information immediately across all disks included in the array in the form of small blocks (“stripes”). Due to this, performance increases significantly, but reliability suffers. We do not recommend using this array type, despite the performance benefits.
  • RAID 1 (“Mirroring”, “mirror”). Has protection against failure of half of the available hardware (in general case– one of two hard drives), provides an acceptable write speed and gains in read speed due to parallelization of requests. This type of array will fully support a 1C+DBMS server for up to 25-30 users, especially if 15K SAS disks or SSDs are used.
  • RAID 10. Mirrored pairs of disks are arranged in a “chain”, so the volume of the resulting volume can exceed the capacity of one hard drive. In our opinion, the most successful type of disk array, because... it combines the reliability of RAID1 and the speed of RAID 0. In combination with SAS 15K disks or SSDs, it can be used for 1C servers from 40-50 users.
  • RAID 5. Famous for its efficiency. By sacrificing the capacity of just one disk from the array for redundancy, we gain protection against failure of any of the system’s hard drives. (its variation of RAID 6 requires an extra two hard drives to accommodate checksums, but saves data even if two disks fail). This type The array is economical, reliable and has quite noticeable read performance. Unfortunately, the bottleneck of this array is low speed recording, which allows you to comfortably use it with 1C server configurations of up to 15-20 users. It is also optimal for applied purposes - storing file data, document flow archives, etc.

Types hard interfaces disks. By connection type hard disks are divided:

  • HDD Sata Home. The cheapest hard drive option designed for use in home PCs or network media centers. It is strongly not recommended to use such devices in 1c servers due to the low fault tolerance and operational stability - the components of these disks are simply not designed to operate 24/7 and quickly fail.
  • HDD Sata Server. This name usually refers to hard drives with a Sata interface and a spindle speed of 7,200 rpm. The prefix “Server” means that such disks have been tested for performance in server systems and are designed for stable operation 24/7. Typically used in 1C servers to store large volumes of information that do not require high processing speed. For example, 1C archive databases, exchange folders, office document download files, etc.
  • HDD SAS Server. There are several differences between the SAS interface (a modern analogue of SCSI) and the Sata interface. Here is the average disk response time, and work in a shared disk shelf, and work with the HDD controller at higher information exchange speeds - up to 6 GB/s (compared to Sata 3 GB/s). But the main advantage is the existence of SAS disk models with a spindle speed of 15,000 rpm. It is this design feature that allows SAS disks to perform almost 3 times more I/O operations per second compared to Sata Server HDDs. Such SAS disks have a small capacity and are recommended to be used for main 1c databases with a constantly high workload.
  • SSD drives. These drives differ from the previous ones not in the connection interface, but in their design - they are solid-state and have no moving parts, i.e. In essence, they are analogues of “flash drives”. Such technologies allow SSD drives to produce an “exorbitant” number of input/output operations per second (from 10,000 operations on the simplest SSD models). However, this advantage also has a downside - more high price SSD disks and their “life threshold”, which depends on the limit on the number of writes to SSD blocks. However, every year these discs become more affordable and durable. Because the cost SSD drives increases many times depending on the volume - it would be most reasonable to use them for small but over-loaded 1c databases that require high access speed, as well as for temporary databases of the TempDB DBMS.

IOPS – number of input/output operations per second. Essentially, IOPS is the number of blocks of information that can be read or written to the media in 1 second of time. That is, in its pure form, this is the key parameter of information processing speed hard drive, affecting the performance of 1C server. If we take a standard 4kb block of information for comparison, we can roughly highlight the following IOPS indicators (see Table 4).


HDD IOPS Interface
7,200 rpm SATA drives ~75-100 IOPS SATA 3 Gb/s
10,000 rpm SATA drives ~125-150 IOPS SATA 3 Gb/s
10,000 rpm SAS drives ~140 IOPS SAS
15,000 rpm SAS drives ~175-210 IOPS SAS
SSD drives From 8,000 IOPS SAS or SATA

Table 4 - IOPS indicators on various types of hard drives when working with a 4kb data block.


Of course, in its pure form, IOPS is of little use for calculating final calculations and requirements for the disk subsystem of a 1C server. After all, the total performance of the disk subsystem consists of the type of RAID array, disk types and indicators of its interface speed, response time (Latency), random access time, percentage of the number of read and write operations and many other factors. However, this parameter, in our opinion, is a key indicator of the speed of the disk subsystem and at the stages of developing a server architecture, it helps to determine what type of hard drives will be most suitable for certain needs. (see RAID calculator)

Practice test

What is the relationship between the number of 1C users and the number of iops? Our team conducted a practical test (see Table 5) to measure the load on the disk subsystem with a certain number of 1C sessions. Since the 1C system is a programmable environment and each company can have its own set of business processes in 1C, we needed a link to a certain reference configuration for testing. In this capacity, a specialized configuration of the 1C CPU was chosen, developed for testing and debugging. Based on it, our 1C programmers added a number of queries that simulate the normal operation of an ordinary enterprise, with the formation of accounting queries, postings, drawing up reports and posting operational documents.


System disk Disk with databases
Iteration Users IOPS write IOPS read IOPS write IOPS read
Average values
1 12 9,1 0,1 13,1 1,5
2 20 7,9 0,1 21,8 0,4
3 32 5,2 0,006 36,1 5,2
4 40 7,7 0,013 27,52 1,3
5 52 7,7 0,006 32,04 0,94

Table 5 - Results of a practical test on the load on the disk subsystem.


The test results show that the lion's share of the load on the disk subsystem occurs when 1C is written to the database of the DBMS server and to system disk operating system (on which the 1C:Enterprise cache server files are located by default).

At the same time, we carried out practical measurements of already working 1C UPP 8.2 databases during the test period - 5 working days. They show that on average a 1C + DBMS server consumes twice as many iops “for writing” as “for reading”. This difference between synthetic tests and monitoring statistics of a real 1C server is due to both periodic sampling of information data from the database during the working day, and regular reading of the database during DBMS backup or replication.

Other components of the hard drive that are worth paying attention to.

  • Physical size (form factor). Today, almost all known drives for personal computers and servers are 3.5 or 2.5 inches in size. Please note that 2.5-inch drives are not produced in large volumes.
  • Random access time- time during which HDD is guaranteed to perform a read-write operation on a specific section of a magnetic disk. As a rule, server drives have better results. This is a fairly important parameter when building a disk array for a 1C DBMS server.
  • Spindle speed- the number of revolutions of the hard drive spindle per minute. Everything here is simple and clear - the access time and average speed transfers hard data disk.
  • Hard disk buffer capacity- a buffer is a temporary memory designed to smooth out differences in the speed of reading/writing a hard drive and transferring data over the interface.
  • Reliability- is defined as the mean time between failures (MTBF). As a rule, reliability directly depends on the manufacturer, price and environment using hard disk. We consider reliability an important parameter of a hard drive that affects the quality of operation of a 1C server.

The right choice: home or server hardware

The reduction in price of hardware components and the active growth of the potential capacity of “home computers” lead to another disastrous misconception - small businesses actively use workstations as a platform for collaboration with 1C databases. At the same time, not realizing that in addition to the core frequency parameters, memory size and the ability to use budget SSD drives in a regular PC, there are more systemic, deeper and more important requirements for the operation of hardware in a commercial structure (see Table 6).

To solve the issue of organizing a 1C server, we offer rental of 1C cloud servers in Tier III class data centers. The economic feasibility of choosing to rent a server can be found in the article.


Options Server Personal Computer
Adequacy of computing power V V
Guaranteed system availability 24/7 V X
Reliability and stability of key hardware components V X
Opportunity remote control power and console (IPMI) V X
Budget cost of the hardware platform X V

Table 6 - Comparison of home and server hardware according to the criteria required for high-quality operation of the 1C server.

Fault-tolerant operation of 1C

Of course, one of the important requirements for the 1C server part is the stability of its operation and resistance to failures. Microsoft and 1C itself have put a lot of effort in this direction, creating technologies for clustering their services at a fairly serious level (see Table 7).


Fault tolerance of SQL servers Based on the concept of a single common data warehouse. Built-in clustering technology SQL Server combines two SQL servers into one cluster with a single virtual IP address and a single database. Thus, if the main SQL fails, queries are automatically transferred to the backup one.
The second option is the recently introduced AlwaysOn - a technology for automatic regular replication of DBMS databases between the main and backup SQL servers. At the same time, the duplicate SQL server is physically located on another storage, which increases risk resistance
Fault tolerance of 1C:Enterprise server service 1C Enterprise servers are combined into an active-active software fault-tolerant cluster with automatic switching in case of failure and saving current sessions.

Table 7 - Fault tolerance of SQL and 1C servers.


However, each technology has both pros and cons. In addition to the key advantages, you need to know some features of 1C and SQL clustering () so as not to end up with a deterioration in the performance of the service:

  • SQL clustering uses a virtual IP. This means that interaction between the 1C:Enterprise server and MS SQL will always occur via the network interface, even if both services are on the same operating system. Which, accordingly, will lead to slower operation of 1C in comparison with the classic version of the architecture recommended by 1C itself - the use of Shared Memory. In principle, this obstacle can be “bypassed” using, for example, MS SQL Log Shipping technology. However, in this case, switching to a backup SQL server will no longer be automatic and this option cannot be considered a full-fledged cluster.
  • A SQL cluster requires large budget expenditures. If we are talking about classic clustering of the MS SQL service, a single database storage is required, connected to the main and backup SQL servers. Typically, this role is played by expensive storage systems, which increases the budget by an order of magnitude. If we are talking about the newfangled AlwaysOn, then a single database storage is not required, the technology works with local disks main and backup servers over the network. But the SQL version is required Server Enterprise, the license for which costs 4 times more than a regular SQL Server StandarD.
  • Number of licenses. Despite the fact that the second SQL server does not process data and is in reserve, licenses will need to be purchased for both servers - both the main and the backup. Particularly painful for the budget are SQL Server Enterprise licenses for implementing a distributed cluster of AlwaysOn high availability groups.
  • There is no need to use cheap custom hardware for such an important service as accounting system the entire enterprise. The price in this case directly determines the quality, stability and durability of such a platform.
  • When choosing a server platform, we recommend paying attention to the presence of two power supplies, a remote IPMI card and the manufacturer’s brand. Of course, everyone chooses a solution based on their budget; top brands are sometimes too expensive and not entirely appropriate, but you shouldn’t skimp on the manufacturer, this can lead to uncontrollable force majeure when working with 1C. Personally, we use Supermicro server platforms in combination with Intel server CPUs.
  • There is an opinion, confirmed by practice, that 1C performance depends more on the higher frequency of the CPU than on the number of cores provided.
  • There is no need to save on the amount of RAM allocated for the 1C server and SQL service. RAM on this moment is a fairly cheap resource, and its shortage (even by 10-15 percent) will lead to a significant drop in the performance of the 1C system, because a slower swap system will turn on. Plus, swap will put additional load on the disk subsystem, which will worsen the situation even further.
  • The EFSOL company offers comprehensive services for selecting a 1C server, which includes: 1C server design, purchase, configuration and maintenance.
  • Alternative own creation 1C server option is to rent a server for 1C. Cloud technologies allow you to obtain a reliable, fault-tolerant service for comfortable work in 1C at low monthly costs.

System integration. Consulting

1C:Enterprise 8 can be a resource-intensive application even with a small number of users. When choosing a server for 1C, any owner would like to avoid “birth traumas” - potential bottlenecks inherent in it. On the other hand, today few people buy servers with excess capacity, “for growth.” It’s good if the load profile can be removed in advance - then it’s easier to design a server for a specific configuration of the company’s applications.

To be specific, let’s consider the 1C:Enterprise 8.2 platform in its popular basic configurations “Accounting”, “Trade and Warehouse”, “Salary and Personnel Management”, “Trading Enterprise Management” and, partly, “Manufacturing Enterprise Management”. We assume that for enterprises with 10 or more employees working in 1C, “1C:Enterprise 8.2” is used. Applications server". Let's take into account the option of working in Remote Desktop mode, with the number of simultaneous database users up to 100-150. The recommendations will also apply to more “heavy” 1C databases, but “severe cases” always require an individual approach.

Processors and RAM

If the company is very small (2-7 users in the system), the database is small (up to 1GB), and “1C:Enterprise 8.2” runs in file mode on the user’s computer, then we get a classic implementation of a file server. Even an Intel Core i3, much less an Intel Xeon E3-12xx, can cope with such a CPU load task. The amount of required random access memory (RAM) is calculated quite simply: 2GB for the operating system and 2GB for the system file cache.

If the company has 5-25 1C users, the database size is up to 4GB, then the 1C:Enterprise 8.2 application should be sufficient with a 4-core Intel Xeon E3-12xx or AMD Opteron 4xxx. In addition to 2GB of RAM for the OS, you need to allocate 1-4GB for 1C:Enterprise 8.2. Application Server" and the same amount under MS SQL Server as a cache - a total of 8-12GB RAM. For small databases, it is advisable to cache at least 30% of the database in RAM, or better yet, 100%.

It is a well-known (although not particularly advertised) fact: “1C:Enterprise 8.2. The application server really does not like it when the operating system unloads it into a swap file on the hard drive, and sometimes tends to lose response. Therefore, on the server where the “Application Server” is running, there should always be a supply of free space in RAM - especially since it is inexpensive today.

In larger companies, 1C users usually work through remote access to the application (Remote Desktop) - that is, in terminal mode. As a rule, with 10-100 1C users with a database of 1GB and above, “1C: Enterprise 8.2. Application server" and the user application "1C:Enterprise 8.2" run on the same server.

To determine the required processor resources, it is assumed that one physical core can effectively process no more than 8 user threads - this is due to the internal architecture of the processors. As practice shows, for 1C + Remote Desktop tasks you should not take server processors of lower lines with low frequencies computational cores and stripped-down architecture. If there are few users (up to 15-20), one high-frequency Intel Xeon E3-12xx processor will be enough. At the same time, at least one of its physical cores (2 threads) will be used for the needs of SQL Server, another one (2 threads) will be used for 1C:Enterprise 8.2. Application Server", and the remaining 2 physical cores (4 threads) are for the OS and terminal users. If the number of 1C users is more than 20 or if the database volume is more than 4GB, it’s time to move to 2-processor systems on Intel Xeon E5-26xx or AMD Opteron 62xx.

Calculating the required amount of RAM is relatively simple: 2GB should be given to the OS, 2GB or more to MS SQL Server as a cache (at least 30% of the database), 1-4GB to 1C:Enterprise 8.2. Application Server", the remaining server memory should be enough for terminal sessions. One terminal user, depending on the configuration, consumes in the applications “Accounting”, “Trade and Warehouse” - 100-120MB, “Salaries and Personnel Management”, “Trade Enterprise Management” - 120-160MB, “Manufacturing Enterprise Management” - 180-240MB. If the user additionally runs MS Word, MS Excel, MS Outlook on the server, then about 100MB must be allocated for each application. Typically, the minimum for a terminal server is 12GB RAM.

For example, for a 1C server with the entire software package, 50 terminal users in the “Trading Enterprise Management” configuration, and an 8GB database, the optimal computing power will be two Intel Xeon E5-2650 processors (8 cores, 16 threads, 2.0 GHz). Random access memory you will need at least 2 (OS) + 4 (SQL) + 4 (1C server) + 8 (160 “USP” * 50 users) = 18GB, or better yet 24-32GB (6-8 4GB DIMM channels).

Disk subsystem

Most complaints about slow work 1C:Enterprise 8 servers are associated with a lack of understanding of what types of I/O operations are performed on them, on what data and with what intensity. Often, it is the disk subsystem that is the key to ensuring sufficient performance of the server as a whole - after all, for busy databases, the biggest problem is table locking when many users are working with them simultaneously or during mass downloads/unloads/postings. Monitoring and optimization of the server disk subsystem.

1C has 5 data streams for the disk subsystem with which it works:

  • database tables;
  • index files;
  • temporary files tempDB;
  • SQL log file;
  • log file of 1C user applications.

The data structure in 1C is object-oriented, with many objects and connections between them. When working with data tables, the number of read and write operations that the disk subsystem can perform over a period of time (Input Output Operation per Second, IOPS) is extremely important. At the same time, its ability to provide high streaming data transfer rates (in MBp/s) is much less important. A very modest database of 200-300MB with 3-5 users can generate up to 400-600 IOPS in peaks. A database with 10-15 users and a volume of 400-800MB is capable of producing 1500-2500 IOPS, 40-50 users of a 2-4GB database generate 5000-7500 IOPS, and databases with 80-100 users easily reach 12000-18000 IOPS.

Of course, the average load on the disk subsystem can be 10-15% of the peak. Only in reality it is performance during peak load periods that is important: automatic downloads data from other systems, data exchange of a distributed system or re-running of the period.

Modern disks in read and write operations with random access (Random Read/Write) alone cope with the following loads:

Intel 910 400 GB

2400 – 8600 IOPS

It is clearly seen that:

  • the bottleneck for both HDD and SSD is recording;
  • traditional HDDs are not competitors to SSDs in terms of read speed in IOPS, even theoretically, the difference exceeds two orders of magnitude;
  • Even a not-so-modern desktop SSD is 3-40 times (depending on configuration) faster than any HDD in IOPS write speed, a server SSD is 12-40 times faster than an HDD;
  • Maximum performance in IOPS is provided by PCIe SSD class Intel 910 or LSI WarpDrive.

Single disks are not used in database servers, only RAID arrays. To further calculate the real performance of the disk subsystem, you need to take into account the costs (“penalty”) for writing to IOPS, which are borne by the disk group in RAID:

If you assemble 6 disks in RAID 10, then for each write of 1 IOPS of data, 2 IOPS of physical disks will be spent, and if in RAID 6, then 6 IOPS of disks. Thus, when calculating the write load capacity of a disk group, you must first add up the IOPS of all disks in the RAID group, and then divide them by the “penalty”.

Example 1: 2 HDD SATA 7200 in RAID 1 will provide write capacity: (100 IOPS *2) / 2 = 100 IOPS.

Example 2: 4 SATA 7200 in RAID 5 will provide write capacity: (100 IOPS *4) / 4 = 100 IOPS.

Example 3: 4 SATA 7200 in RAID 10 will provide write capacity: (100 IOPS *4) / 2 = 200 IOPS.

Examples 2 and 3 clearly demonstrate why RAID 10 is preferable for storing databases with a typical read/write distribution of 68/32.

From the data in the three tables, it is clear why the performance of a typical “gentleman’s set” of 2 HDD SATA 7200 in RAID 1 is not enough for a server: during peak loads the queue of disk accesses grows, users wait for a response from the system, sometimes for many hours.

How to increase the write performance of the disk subsystem? They increase the number of disks in the RAID group, move to disks with higher rotation speeds, and select a RAID level with a lower write penalty. Caching with a RAID controller with Write back mode enabled helps a lot. Data is not written directly to the disks (as in Write Through mode), but to the controller cache, and only then, in batch mode and in an ordered form, to the disks. Depending on the specifics of the task, recording performance can be increased by 30-100%.

For lightly loaded or relatively small databases (up to 20GB), an inexpensive method of “extracting IOPS” is suitable - a hybrid RAID from SSD/HDD. A branch database for 3-15 users in a distributed structure like a cafe chain or service station doesn’t need more.

For large (200GB or more) databases with a long historical data trail, or for servicing several large databases, SSD caching (LSI CacheCade 2.0 or Adaptec MaxCache 3.0 technologies) can be effective. Based on the experience of operating such systems, it is in 1C tasks that they can be used to speed up disk operations by 20-50% relatively inexpensively and without significant changes in the storage infrastructure.

The champion in performance in IOPS is predictably RAID arrays on server SSDs - both traditional, using a SAS RAID controller, and PCIe SSD. Two limitations hinder their popularity: technological (the performance of RAID controllers or the need to radically break the storage structure) and the cost of implementation.

Special mention should be made about storing index files and TempDB. Index files are updated very rarely (usually once a day), but they are read very, very often (IOPS). Such data simply needs to be stored on an SSD, with their reading performance! TempDB, used to store temporary data, is usually small in size (1-4-12GB), but very demanding in terms of write speed. What index and temporary files have in common is that their loss does not result in the loss of real data. This means that they can be placed on a separate (even better - on two separate volumes) SSD. At least on board SATA controller motherboard. From the point of view of reliability and performance, it is advisable to provide a mirror (RAID1) from an SSD for TempDB, which can be done on the on-board controller, but with the obligatory disabling of all write caches. Desktop SSDs can also cope with this role - like the Intel 520 series, where hardware data compression when writing to TempDB will be just appropriate. Removing these tasks from common system storage on a dedicated high-speed subsystem has a positive effect on the performance of the system as a whole, especially during peak loads.

In cases where it is possible to ensure the fastest possible response from administrators in case of failures, and when there are complex calculation tasks (warehouse or transport logistics, production in UPP, volume exchanges in URDB), TempDB is transferred to RAMDrive. This solution sometimes allows you to gain up to 4-12% of the overall system performance. Some inconvenience only arises if the server is restarted: if RAMDrive does not start automatically, administrator intervention will be required to start it manually - otherwise the entire system will fail.

Another important component is log files. They have an unpleasant feature for any disk subsystem - they generate an almost constant stream of small write requests. This is unnoticeable under average loads, but greatly degrades the performance of the 1C server under peak loads. It makes sense to move the log file (especially the SQL log file) to a separate physical volume that does not have high IOPS requirements and will receive almost linear writes. For peace of mind, you can create a mirror from inexpensive and bulky SATA/NL SAS (for Full log), or inexpensive desktop SSDs of the same Intel 520 series (Simple log, or Full log, with daily Backup and cleaning).

In general, we can say that the arrival of SSDs in servers has opened up new opportunities to increase the performance of mass-produced servers - through multi-level data storage and reasonable configuration of disk I/O.

The disk subsystem of the “ideal server for 1C” looks like this:

1. Database tables are hosted on RAID 10 (or RAID 1 for small databases) from reliable server SSDs with a mandatory hardware RAID controller. For high IOPS requirements, you can consider the PCIe SSD option. For large databases, SSD caching of HDD arrays is effective. If the 1C configuration used and the data structure are not too demanding on IOPS, and the number of users is small, a traditional array of HDD SAS 15K rpm will suffice.

2. Index files are placed on a fast and inexpensive single SSD, TempDB - on 1-2 (RAID 1) SSD or RAMDrive.

3. For SQL (and preferably 1C) log files, a dedicated volume (single physical disk or RAID-1) on a SATA/NL SAS HDD or inexpensive SSD, or a logical disk on a RAID array on which the server operating system is located and user files/folders.

4. operating system and user data is stored on RAID 1 from HDD or SSD.

If the IT infrastructure is virtualized, it is highly desirable that SQL Server is not installed as virtual machine, but directly to the physical server, to bare metal. The price of the issue is from 15 to 35% of the performance of the disk subsystem (depending on the equipment, drivers, virtualization tools and methods of connecting the volume). In a virtualized SQL server environment, connecting volumes with database tables, index files and TempDB to the VM is required in exclusive mode via Direct Access.

Network interfaces

When building 1C:Enterprise 8 systems for small and medium-sized enterprises (up to 100-150 active users simultaneously), losses in network operations via the Ethernet interface should be minimized. Ideally, serve both SQL Server, 1C:Enterprise 8 Application Server x64, and 1C user sessions in Remote Desktop with one physical server. Controversial from the point of view of ensuring fault tolerance, such a recommendation allows you to get the most out of hardware and software, and through the use of virtualization it provides a certain level of security and “environment repeatability” on other equipment.

Why exclude Ethernet from the chain SQL server -> Application Server 1C: Enterprise 8 -> user session 1C: Enterprise 8? The Ethernet network interface, with its packaging of data into relatively small blocks for transmission, will always create additional delays: both during packaging/unpacking of traffic, and during the transmission itself (high latency). In 1C:Enterprise 8, quite large amounts of data are transferred for processing and display along the entire chain, in some situations - in both directions. When directly transferring data from one process to another within the server’s RAM (on one server without virtualization), or through a virtual network interface (within the same physical server, with good server network adapters with transfer of RAM blocks between VMs) latency is much lower. Modern dual-processor servers with large RAM and an SSD disk subsystem allow you to comfortably serve a 1C database for 100-150 active users.

If the use of several physical hosts is unavoidable for busy databases, it is advisable to connect all servers via 10Gb Ethernet. Or at least 2-4 aggregated 1Gb Ethernet connections with hardware TCP/IP acceleration (TCP/IP Offloader) and hardware virtualization support.

Budget solutions suffer the most from performance losses on Ethernet ports. It's no secret that network adapters The 1Gb soldered on most server motherboards is not designed to handle heavy network traffic. Even if the board has 2 or 3 GbE ports, they are usually implemented on desktop chips. While sufficient for management, they generate additional overhead for servicing network communications, especially in a virtualized environment. The entire process of data transfer through such a chip is ensured by the resources of the processor, RAM and the load on the internal buses. Such chips do not provide any acceleration in the transmission of IP traffic; each received and transmitted Ethernet packet requires a separate interrupt to the processor. In a virtualized environment, network interface performance losses can reach 25-30%. The most unpleasant thing is that overloading the network interface with monitoring tools may not be noticed. The central processor bears the responsibility for it, and if it doesn’t work, it sits idle waiting for a response from the network card. It is advisable to exclude ports on desktop chips from the data flow in virtualized environments, leaving them for server management tasks. For intense network traffic, it is worth adding a discrete network card on the server chipset.

Fault tolerance or acceptable downtime?

Discussions about server performance are almost always accompanied by debates about their reliability. Ensuring fault tolerance always requires additional costs, especially when supporting continuous production processes. Without belittling the role and place of 1C, we can say that most of its users solve the “performance/reliability” dilemma in different planes: they fight for the first by optimizing hardware solutions, for the second - by organizing processes and procedures. When applications are moderately critical, the main focus in maintaining operability is not on individual server protection, but on minimizing downtime of the infrastructure as a whole.

Of course, for enterprises with relatively big amount simultaneously connected users (25-150) and placing all applications on one server, it is necessary to use uninterruptible power supplies, redundant power supplies of the servers themselves, hot-swappable drive baskets and hot-standby RAID arrays. But no hardware can replace the planned backup of the data itself. Having a daily (more precisely, nightly) backup and an operational file with Full SQL log, you can completely restore the 1C database in a relatively short period.

The permissible downtime of the central 1C system for small and medium-sized enterprises is 1-2 accidents per month, lasting 1-4 hours. In fact, this is a huge reserve of time - if you are prepared for recovery in advance. A necessary condition a quick restart is the availability of images of all virtual and physical servers in the form of VMs on a separate storage/volume - to restore the infrastructure part itself on the backup server. Daily backup is required (as well as weekly and at the end of the period) for another physical device and Full SQL log for cases where the loss of data “since the beginning of the working day” is critical and difficult to restore manually. If you have replacement equipment, you can do it in 1-2 hours to restore overall functionality, albeit with less productivity. Well, where 24×7 operational continuity is required, the primary tasks will be to select the appropriate architecture, equipment with a minimum number of points of failure and full-fledged clustering technologies. But that's a completely different story.

Original article: http://ko.com.ua/proektirovanie_servera_pod_1s_66779

With permission of the editor of the journal "Computer Review"

A 1C server is an important technical element when building an IT infrastructure. We are ready to sell server equipment with excellent configuration at an adequate price, without huge markups. Only suitable configurations to solve your problems. Leave a request and you will receive a device that can meet the technical needs of the organization.

We are ready to provide server equipment of any complexity with a configuration that meets the requirements. Convenient delivery available. Pickup is available in Moscow. In general, if you want to purchase, then just call, fill out the calculation form or write to email. We offer a variety of components, assembly options, we will make Commercial offer. We will start from the budget and assemble the most appropriate 1C servers.

If you came for information, it is located below. We tried to post full-fledged material that can give, albeit not an exhaustive, but voluminous answer to the question. We warn you right away, the information is more about hardware than software.

  • 1C server for 5-10 users
  • 1C server for 10-20 users
  • 1C server for 20-30 users
  • 1C server for 30-50 users
  • 1C server for 50-100 users
  • 1C server for 200+ users

In this case, a custom configuration is required. There is practically no point in creating a configuration at random, since the load can vary significantly depending on the tasks of the users. In some cases, you won’t be able to limit yourself to one device; you will need a cluster. Leave a request so that a specialist can contact you and clarify the details.

Any assembly can be configured individually to suit your needs!

By the way, preliminary parameters can be selected in the form below. This will allow specialists to quickly create a commercial proposal.

Receive an individual calculation for a 1C server:

What is a 1C server?

The software package "1C: Enterprise 8.3" is a set of business tools for accounting, inventory, and reporting in automatic mode. There are many opportunities for sharpening for any segment of activity. The software is quite flexible in settings, but, unfortunately, very demanding.

In fact, the complex is now used everywhere. Large organizations budgetary institutions, state. And not only in Russia, but also abroad.

The appearance of the product on the market occurred at a very opportune moment, which had a good impact on the widespread introduction of the product. At first there was a minimal set of tools for accounting, gradually the software developed, improved, and new functions and capabilities were added.

Today the product has become a full-fledged tool for automating many aspects of business and has well-deserved popularity. Despite the shortcomings, the software is constantly evolving, introducing innovations and correcting shortcomings of previous versions.

Implementation types

Most small organizations do not buy a server for 1C. They don’t see the point in such waste. After all, it is enough to deploy the complex to personal computer, then give access to other PCs. This option is called “File mode”.

It is not capable of providing decent performance and is only suitable for use in local network(of course, remote access is also available, but ineffective). When the number of simultaneous calls to the database exceeds 5, it begins to seriously slow down. Freezes periodically. In addition, the limit on the size of one table in the database is 4 GB; large companies, it should be said, often create such large tables. Of course, the disadvantage of the file mode is the following factor: the larger the database size, the more serious the requirements for hardware resources. Unfortunately, if you have a lot of people working on the software, or you have to create large spreadsheets, you may be better off choosing a different way to implement your IT structure.

And DB management systems, which operate in a client-server execution type, come to the rescue. Server 1C supports the following types of DBMS:

    MS SQL Server is a DBMS developed by Microsoft. Reliable, functional, but requires an OS Windows family. There are certain drawbacks: it loves RAM, occupies it completely, so you have to set restrictions manually, RAM leaks periodically occur when interacting with table arrays.

    PostgreSQL is a free distribution. In some places slow, which has been proven experimentally. Suitable for a small staff; a large staff may not be able to handle it. But despite the shortcomings, there are no restrictions on support e processors, and there is no RAM plateau.The main requirement is straight arms system administrator. At correct setting shows excellent results.

    Oracle Database is a versioned DBMS that has good functionality, and is also very fast, allowing you to simultaneously write and read. Weakness – demanding on RAM.

    IBM DB2 Universal Database. Well suited for processing large arrays. Has extensive functionality. Unfortunately, this DBMS contains a lot of unnecessary things to maintain compatibility with outdated computers, which reduces the effectiveness of the DBMS. It is not demanding on RAM, but because temporary tables are limited. The maximum number of supported cores is 16, which imposes some restrictions.

The most effective DBMS in tests are MS SQL Server and Oracle. If there are budget restrictions, then you should choose PostgreSQL; it is a free DBMS, but keep in mind that only the version that is made specifically for the target software works. IBM DB2 Universal Database is rarely used, because there are more productive analogues, but in support of outdated equipment and assemblies from IBM is the best.

We come to the conclusion of what to implement in a client-server performance much more effective. IN otherwise We get brakes and serious restrictions. I hope you have decided on the choice of DBMS, but in fact I will say that the most convenient and popular is MS SQL Server.It is best supported by the software package in question.

And I’ll answer one more question right away. Other SQL interpreters are not supported. At least officially.

Accordingly, it will become more complicated. Single machines turn into clusters, the composition of employees expands, and is divided into groups. But the base looks something like the diagram. For more than 50 users, you will definitely have to use two devices. One for databases, the second as a terminal server. Otherwise there will not be enough capacity.

The terminal node is needed to provide power to the thin client. A specialized device, a PC, or even a smartphone can act as a thin client. Accordingly, all operations are performed centrally, on one machine. Which makes powerful devices in the role of TC unnecessary. There are enough unproductive devices that are responsible for displaying the results of executing instructions on the screen.

Databases require hardware capable of processing the entire volume at once and transmitting information to the terminal node, which must be very powerful, since it is responsible for virtualizing applications and providing technical resources.

The larger the organization, the wider the composition of users, the more productive the equipment will be required. In some situations a cluster is needed. While the costs may seem high, in reality, buying a 1C server and low-power PCs is cheaper than trying to set up an IT infrastructure without them.

Equipment

So, what kind of hardware do we need to implementserver for 1C ? Good question, first we need to decide on the parameters according to which we will set the requirements:

    number of users;

    volume DB ;

    required fault tolerance;

    implementation type.

Place a question mark next to each item. Answer them. In fact, this is how the task is formed. Now let's try to help you navigate. Let's start with our favorite users.

The number of SQL queries is a key point when preparing a technical task. Each person or program is capable of generating a certain number of requests, occupying part of the hardware resources. So a build for 5 users may not be suitable for 10, and for 50 the requirements will also look different. Same thing for 100, 200. Of course, software that will automatically work with 1C is a separate topic that requires more detailed consideration.

Now point two. There is a database, so it needs to be placed somewhere and given the necessary amount of resources for functioning. The task only seems easy. You will have to select suitable drives that can provide the speed and required volume. It is recommended to predict the potential size of the database, then it will be easier to formulate requirements.

Fault tolerance is designed to ensure uninterrupted operation. To ensure continuous backup, one about the device duplicated by others. The higher the level of fault tolerance, the more complex and expensive the configuration.

Type of implementation - in fact, how we will use it, for what purposes. Nothing complicated. If only accounting, then power will be less important, but if all the tools are used, then more powerful equipment is required.

Let's go through the components.

CPU

CPU with a performance of at least 1700 MHz, although the requirements indicate a lower value, but should focus on it and in the end buy an even more powerful processor. Ideal for Intel Cor e i3-8100, Xeon E3-1220 v6 or AMD Ryzen 3 1200. Of course, most w will give this performance Xeon, but he is more expensive than everyone else. This is for 5-10 Human . If an increase is plannedlivestock of "users", then it’s definitely worth choosing Xeon.

For 10-20 people, the Intel Xeon E3-1230 v6 is already useful; unlike its younger brother, it has a higher clock frequency and multithreading. Although it is not so fundamental, the CPU turns out to be an order of magnitude more powerful. Less expensive ones include the Core i5-8500 and AMD Ryzen 5 1500X. But the latter will not be able to show the same performance as Xeon. So opt for the latter.

If the server for 1C is planned for 20-50 people. Then the assembly needs to be productive. It’s better to forget about processors in the user segment and look at the server segment. So. Here you will already need at least an Intel Xeon E5-1650 v4 with 6 cores 12 threads and base frequency 3.6 GHz is quite good. From AMD, the EPYC 7261 CPU with 8 cores, 16 threads and a base frequency of 2.5 GHz is suitable. Of course, it will show less performance, but it will be a little cheaper. But not by much.

For 50-100 users, it’s worth looking at the Xeon E5-1680 v4 from Intel, it is noticeably more powerful than the previous CPU. Has 8 cores, 16 threads and 3.4 GHz frequencies. You can also use AMD EPYC 7351 with 16 cores, 32 threads, base frequency 2.4 GHz. But it is significantly worse than Intel. But also noticeably cheaper.

For more serious solutions, you can even use dual-processor systems, or segment devices. For example, the Xeon E5-2643 v4 is ideal for a dual-processor system. But it makes much more sense to segment devices. That is, implement the solution on two devices at once.

In general, it should be noted that the number of cores in a 1C server does not play a decisive role. More emphasis needs to be placed on clock speed and performance in sequential operations. Therefore, feel free to discard multi-core CPUs. In the monitored software package support for multithreading and multiprocessing is implemented very poorly. Numerous cores do not provide significant advantages.

Drives

The bottleneck in the system is traditionally HDD. Let's start with interfaces. SATA Only suitable for sequential queries. Any parallelization can only be done in RAID- array. Interface SAS better, up to 10 simultaneous requests, but the throughput of hard drives still leaves much to be desired. The most adequate choice - SSD. Will fit solid state drives With SAS, from SATA We recommend refusing, but it’s also an option and they’re a little cheaper. Ideally - SSD NVMe. They are the fastest acting from the proposed . But, unfortunately, they are very expensive. Start from your budget, but we recommend choosing SSD, then a more efficient system will be implemented.

RAM

Well, all sorts of little things like the motherboard (ha ha, little thing), additional drives It is better to choose depending on the other components. But you should pay special attention to the power supply; you should take expensive versions with marks Bronze, Silver, Gold, Platinum. The latter is the best and most reliable, the first is less good, but better than the usual cheap ones.

Be sure to make RAID 1 or RAID 10 (1+0), the second option is noticeably more productive. They provide a duplicate memory entry. That is, the same thing is written to several disks at the same time. But keep in mind that to create RAID 10 you need 4 drives.

And the last point, be sure to get the source uninterruptible power supply. In the event of a network failure, there will be time to save the data and carefully turn off the server.

No, perhaps there are still important points, just learn them when drawing up the configuration and think carefully about them. The system may have to be built with a significant margin.

user takes up resources. But reading takes significantly less resources than reading/writing. Because one user can give heavy load than several others. When planning your IT infrastructure, this will also have to be taken into account in order to correctly distribute capacity.

Protection. Backup also takes up resources, therefore, so that it does not disrupt work, additional resources must be allocated to it. Firewalls, antiviruses and other security tools also require a certain amount of power.

Fault tolerance. Possibility of hot-swapping disks or power supplies, system duplication. Opportunity quick replacement components. The higher the fault tolerance, the lower the chance that there will be downtime. The greatest fault tolerance is achieved in a cluster.Server for 1C by number of users

This is a key parameter when choosing equipment. It is recommended that you familiarize yourself with this to have at least a rough idea of ​​what may be needed during the configuration process.

1C server for 5 users

For 5 people, high power is not required; configurations for small businesses are suitable. If the office is small and you need compact placement, then you can use a mini-server . This option will allow you to compactly place the equipment and will be convenient for transportation.

The cost of such a device starts from 30,000 rubles. The configuration, as a rule, is no different. CPU used entry level from the Intel Xeon E3 series, or AMD Opteron. There are many ready-made assemblies for this task. But in the case of cheap devices, there are no solid-state drives and no reserve for peak loads.

1C server for 10 users

The configuration for 10 employees is similar to the previous solution, no special power is required, just use a mini-server. But the peak load must be taken into account; if there are automated actions, such as automatic generation of reports from an online store, then the load can be much more serious.

Here you can also get by with a processor from the Intel Xeon E3 line, for example model 1240. 8 GB of RAM is enough, but 16 is better, and it’s also worth using an SSD to host the application and DB.

1C server for 20 users

Here you need equipment more powerful than in the previous version. The option for medium-sized businesses is optimal. An SSD should be present in such a system by default, and it is recommended to use a processor no lower than Intel Xeon E3-1280 v6. Otherwise, there will be no reserve for peak power.

1C server for 50 users

In this configuration, it is recommended to take into account the complexity of the tasks. If they do not create a serious load, then high powers are not needed. If the database is strong or large, then highly resource-intensive equipment will be required; in some cases, a cluster of devices is required.

Typically, a dual-processor system based on Intel Xeon E5-2643 v4 processors is assembled for this task. 2 such CPUs can cover the needs of an application and even a database. But, ideally, creating a SQL server costs separately.

Of course, in this case, solid-state drives are no longer just recommended, but vitally necessary, otherwise the disk subsystem will turn into a bottleneck.

1C server for 100 users

In this case, one device is not enough. Often a cluster of 1C servers is required that can perform operations in parallel and jointly. Custom development required.

But the approximate configuration would be:

  1. Terminal application server. 2 Intel processor Xeon Silver 4215, to host the application SSD with high TDW, two power supplies, disk subsystem for system state backups.

    Server SQL. Similar processors, SSD with high DWPD, also two power supplies and a disk subsystem with RAID 1 for storing backups.

This is conditional; the specifics will depend on the final technical infrastructure.

Server for 1C for 200 users or more

With such a number of users, advanced equipment is needed that can cope with tasks of any complexity. As in the previous option, one device will not be enough; you will need a cluster. The higher the final number of database accesses and the number of employees, the more powerful the equipment will be required and, accordingly, the more devices in the cluster. There are no universal solutions; each is worked out individually.

This article contains information about the 1C installation procedure in the client-server version.

Installation of the 1C platform is described in our other article - “1C Administration”, in the “1C Installation” section. Installation on a server is almost completely identical to installation on local computer, with only one difference. In the server version, when selecting components to install, you must select “1C:Enterprise Server” and “1C:Enterprise Server Administration”.

Install 1C on client computers from which connections to the server will be made.

Installation on client computers is no different from the method described earlier in the article “1C Administration”.

Create an infobase in SQL.

Creating an information base in SQL is also very similar to creating a database in the file version. The difference is that at the stage of selecting the information base location type, you must select “On the 1C:Enterprise server”.

In the “Server cluster” item, specify the name (or better yet, the IP address) of the server on which you installed SQL.

In the “Infobase name” section, specify any name you want to give to the database.

DBMS type – SQL.

The database user and his password are the same superuser mentioned above during the installation of MS SQL.

Leave the date offset as default.

It is necessary to check the “Create a database if it does not exist” option and click “Next”.

Now the database has been successfully created on the SQL server and added to the list of available databases. Below in the picture you can see the result of the work done.

It is worth noting that the created database is still empty. This is a framework, a place allocated in SQL for your information base. In order to load your database into this framework, you need to use the Upload/Load information base tools. The Upload/Download procedure is also described in our other article “1C Administration”.

In order to bring the system to an ideal state in the future, it will be necessary to configure a “maintenance plan” for the created database. A maintenance plan is a set of procedures that SQL will perform regularly on a given schedule. For example, will regularly do backups and delete temporary files. Working with SQL is beyond the scope of this article and will be described in one of the following.

Computer