Server calculation for 1s. Prices and delivery procedure

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 the Intel Core i3, especially Intel Xeon E3-12xx. Volume required random access memory(RAM) is considered quite simple: 2GB for the operating system and 2GB for the system file cache.

If a company has 5-25 1C users, the database size is up to 4GB, then the 1C:Enterprise 8.2 application should be enough for 4 Nuclear 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 doesn’t like it when the operating system unloads it into a swap file on HDD, and tends to sometimes lose response. Therefore, on the server where the “Application Server” is running, there should always be a reserve 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, you should not use 1C + Remote Desktop for tasks server processors junior lines with low frequencies of 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). RAM will need at least 2 (OS) + 4 (SQL) + 4 (1C server) + 8 (160 “USP” * 50 users) = 18GB, or better yet 24-32GB (6-8 DIMM channels of 4GB).

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 locking tables when many users work 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 these three tables it is clear why the performance of the typical “ gentleman's set» 2 HDD SATA 7200 in RAID 1 server is not enough: during peak loads the queue of disk requests 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 a higher rotation speed, 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 the on-board SATA controller of the 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) is allocated on a SATA/NL SAS HDD or inexpensive SSD, or logical drive on a RAID array on which the server operating system and user files/folders are located.

4. Operating system and user data are 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.

Most of all the productivity losses on Ethernet ports budget decisions suffer. It's no secret that network adapters 1Gb, soldered on most servers motherboards, are 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. Taking the rap for him CPU, and if it doesn’t work, then 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 for a quick restart is the presence 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"

When choosing which server is needed for 1C, you should remember that while users are working with it, many data read and write operations will be performed per second.

Most likely, it is immediately clear why competent server design for 1C is so important - if the hardware was initially selected incorrectly and does not correspond to the load on the system, then there is a risk that it will work intermittently or that important data will be lost. On the other hand, create a server for 1C, buy all the hardware and software can cost a significant amount for the company, so it is advisable to select equipment in such a way as to avoid unnecessary costs.

Selecting a server for 1C

When our specialists need to make a choice of configuration for a 1C server, the first thing they ask is how many users will work with 1C in the company and what set of services they plan to use, what they will be, who will administer the 1C servers and how. We start from this information when creating a 1C server.

Requirements for 1C server

In the hardware structure of the 1C server, the characteristics of the processor, RAM, disk subsystem and network interfaces will be important to us.

It is necessary that they ensure stable and sufficiently productive operation of the following components:

  • operating system;
  • database server (most often this);
  • 1C server part (not for all cases, since a small company with 2-10 users can work with 1C in file mode);
  • Users work in Remote Desktop mode;
  • work of remote users via a thin client or web client.

Choosing a processor for 1C server

The optimal number of processor cores is usually calculated based on the fact that 1-2 cores need to be reserved for operating the OS, 1-2 cores for operation SQL databases, 1 more for running the application server and approximately 1 core for every 8-10 simultaneous user sessions (so that users don’t complain later that the 1C server is slow).

Please note that the speed of processing requests depends not so much on the number of cores, but on the processor clock frequency, and the number of cores has a greater impact on the stability of operation with a large number of users and simultaneous tasks from them.

How much memory does a 1C server need?

In addition to the above, if you need a 1C server for 100 or more users, we recommend deploying a cluster of at least two physical 1C servers.

We propose to calculate the size of the required RAM based on the following indicators:

  • 2 GB will be required for the operating system
  • at least 2 GB for running the MS SQL Server cache, and it is better that this value is 20-30% of the actual database volume - this will ensure comfortable work for users with it
  • 1 – 4 GB for 1C application server
  • 100 – 250 MB will be required by one user terminal session, depending on the set of functions of the 1C server and the configuration used

Here are our approximate calculations of the parameters of the 1C 8.3 server:

It is better to purchase RAM with a reserve - this is one of the most important factors in the high performance of a 1C server and at the same time it is now one of the cheapest components. If there is not enough memory on the 1C Enterprise server, this will be very noticeable during operation, therefore, when the question is which 1C server to choose, always pay attention to ensuring that it has sufficient RAM.

Server 1C: equipment for the disk subsystem

When choosing which server is needed for 1C, you should remember that while users are working with it, many data read and write operations will be performed per second. This parameter - the speed at which the hard drive allows you to process data - is also one of the key parameters for the performance of the 1C server.

When designing a 1C server, we recommend observing the following hardware requirements for the disk subsystem:

  • It doesn’t matter what kind of server you create for 1C, we under no circumstances recommend using single disks in servers - it is advisable to organize them into RAID arrays (RAID 10 for large or RAID 1 for small databases), where the database tables will be located.
  • We recommend moving index files to a separate SSD for faster access to them
  • TempDB - on 1-2 (RAID 1) SSD.
  • Place the OS and user data on RAID 1 from SSD/HDD.
  • For log files, allocate a separate logical disk from the array or a physical SSD disk.
  • If possible, use a hardware controller - we have seen situations where a powerful and expensive server slowed down due to insufficient controller performance.

Server selection for 1C

In this article we have provided some tips and rough calculations on how to choose a server for 1C, we hope they will be useful to you.

In conclusion, let’s add one more thing - you shouldn’t try to save money by using a user computer for a 1C server (as is often done in small companies) - user hardware is much less reliable and fault-tolerant than server hardware of similar performance. You shouldn’t risk your company’s accounting system. If purchasing suitable hardware is not within your budget, you may want to consider deploying 1C in the cloud

If you find it difficult to figure out which server to choose for 1C Enterprise 8.3, how to make a 1C server, because you have not encountered this task before, you can always contact a system integrator company so that experienced technical specialists can help you design, purchase, install and set up a server that suits you for 1C.

The 1C:Enterprise platform versions 8.2 and 8.3 are considered standard application for accounting and management tasks of companies. A wide range of application solutions has been developed for public and private enterprises. When implementing their own information infrastructure, every executive or IT manager of a company has a question about what kind of server is needed for 1C. The problem is complicated by the fact that purchasing equipment requires significant financial costs, and not every enterprise can afford to choose top-end configurations.

We have collected recommendations from leading equipment manufacturers (HP, Dell, IBM) and developers software product"1C" 8.3 so that our clients can profitably purchase required server. The optimal network infrastructure can be obtained on the basis of any operating system, but hardware capabilities play a more important role in this.

Server selection criteria

The 1C platform may require significant hardware resources from the server. If the company’s budget is unlimited, which is rarely the case, you can take the platform without hesitation last generations, fill all disk baskets, RAM slots and require the IT specialist to ensure uninterrupted operation of the system. Selecting equipment with limited funds requires a more considered approach. To understand which 1C server will be able to cope with this, it is necessary to carefully analyze the structure of the computing loads. If they are known in advance, it will be much easier to design a ready-made solution.

When choosing a server for “1C” (8.2; ​​8.3), they are guided by the following points:

  • the number of operators simultaneously performing data entry and generating reports;
  • the ability to allocate separate physical servers for SQL and the 1C application;
  • planned volumes of data processing;
  • load distribution structure in client-server architecture

Selecting a processor and RAM

Calculating the frequency, the required number of processor cores, and the amount of RAM is the first and most important step. To consider several options, we will choose a server for 1C taking into account the company’s staff.

Small organization (up to 15 employees). With a small number of users, the database volume, as a rule, does not exceed 2 GB, and the 1C program in the form of a file version is installed on client machines. The OS needs in this case amount to 4–6 GB and another 4 GB are allocated for the system file cache. The processor load distribution looks like this:

  • 2 cores – for the OS and terminal users;
  • 1 core – for the 1C application server;
  • 1 core – for SQL database.

Machines can handle this task entry level with one quad-core processor. These can be either rack or tower servers. The latter option is preferable because it does not require the allocation of a separate room for a server room.

Medium organization (up to 40 employees). With such a number of users, 1C developers recommend using terminal mode to access the application. The database size can be up to 4 GB. For such a load you need at least two processors with 4–6 cores. The optimal amount of RAM will be 16–64 GB, since a minimum of 700 MB must be allocated for each user. It is believed that the 1C application solution in which the client machine runs requires from 240 to 480 MB, and another 200–220 MB is allocated for office applications.

With such a number of processes, it is recommended to use one medium-level machine with virtualization or two physical servers. One of them will be used for terminal access, and the second for SQL. It is best to implement the 1C application server on the first machine or even allocate a separate single-processor system for this. The required configuration is selected in each specific case based on an analysis of processor time.

Large organization (more than 40 employees). The basic equipment configuration in this case will consist of three physical servers:

  • terminal,
  • DBMS,
  • "1C".

Database volumes with such a number of employees often exceed 4 GB, and under system cache It is recommended to allocate at least as much RAM. Another 4 GB will be used operating system, and 1C applications will require about 8 GB. Thus, you need at least 16 GB of RAM.

For such tasks, dual-processor servers with support for Intel Xeon E5-2600 or higher are selected. If the number of employees does not exceed 50 people, only one machine can be left for terminal access and 1C applications. However, given the company's growth prospects, it is better to provide a separate server for each task. If the number of personnel involved approaches 100 employees, you need to deploy a cluster of two machines for 1C, and leave one for other tasks.

Selecting a disk subsystem

Server performance directly depends on the disk subsystem. When running 1C applications, data reading and writing operations are performed with high intensity. Most complaints about server operation are related to tables being blocked when a large number of users access them simultaneously.

The task of choosing a server for 1C includes monitoring the disk subsystem, allowing you to find the optimal balance of performance and reliability. An extremely important factor affecting performance is its ability to perform a certain number of read/write operations per second (IOPS). If the database is up to 300 MB, and the number of 1C users is up to 6 people, this parameter is 400–600. If the number of server users reaches 100 people, then the IOPS will be 18,000. Streaming transfer speed plays a secondary role.

For each type hard disk read/write speeds are set to:

  • SATA – 100/80;
  • SAS – 240/220;
  • SSD – 35,000/8,600.

This shows that 1C database servers are best suited solid state drives. The main factor limiting their use is their high cost. Therefore, to reduce the budget, SAS drives are also used. For storing critical data, including 1C, hard disks combined into RAID arrays different levels, and the inherent redundancy should be included in server performance calculations.

When designing a solution, system fault tolerance plays an important role. For this purpose, both hardware and software. The servers are equipped with hot-swappable power supplies and disk cages, and use a UPS for uninterrupted power supply. Data safety is ensured by backing it up. A log file is created at least once a day to ensure information recovery in case of system failures.

You can find the required server and configure it for 1C on the website. Our specialists will assist in solving this problem. For advice, contact them by phone or contact the manager via chat.

Submit a solution question We answer on weekdays
In one hour

How to choose a server to work with 1C

Let's consider several basic examples of basic server configurations for 1C, guided by two main criteria - the number of users and the method of implementing the program itself: file-based 1C or 1C: application server + SQL.

Let’s make a reservation right away - this division is very arbitrary, since it is not a large number of users, having a large database, will significantly load both the processor and the disk subsystem. But at the same time, a relatively large number of users can use a fairly limited set of functionality and work with a small database, and even not work simultaneously. Those. when choosing a server, you need to consult with a specialist and try to convey to him “the whole truth” about your work.

    Small company (2-10 users), database up to 1 Gb, 1C Enterprise - file mode, this is nothing more than a classic implementation file server.

    You can choose one of the younger Intel Xeon models of the E3-12XX series as the base processor.

    The calculation of RAM is simple: without going into details of the specifics of the operation of the system and file cache, we’ll simply designate it as approximately 2 Gb for the OS and the same amount for working with the file system.

    We do not consider cases of “pseudo-servers”, i.e. when they try to “adapt” a workstation of a decent configuration to a server for 1C, even for 2-3 users. Despite the fact that many “sysadmins” have “rich” experience in using ordinary computers as a server, we do not discuss such options and do not recommend such a choice.

    You can’t even raise your hand to install only 4Gb of RAM on an Intel Xeon - a server series processor. Still, we recommend 8Gb (the principle of more, not less, works here).

    Disk system. Modern drives, even server-grade ones that implement the SATA data transfer interface, differ very little in price depending on the disk size. Therefore, “catching fleas” by trying to reduce the cost of a server due to the difference in price between 500 Gb and 1 Tb disks is not worth it. In addition, the line of 500 GB SATA drives from all manufacturers is already disappearing from their offerings. On the other hand, no one has canceled the well-known postulate - filling speed disk space directly proportional to its volume. Those. The larger the disk, the more information is stored on it, even if this was not initially needed. We insist that there must be at least 2 disks in order to be able to organize the so-called. software “mirror” - minimal data protection if one of the disks fails.

    So, we get the basic configuration of a 1C file server for use by up to 10 users:

  1. If there are 15-20 users, then the database size can reach 4 GB. As a rule, in this case they use version 1C: Enterprise 8.3 Application Server or SQL version of 1C.

    Hence the RAM requirements: the same 2GB for the OS, up to 4GB for 1C:application server and the same amount for MS SQL Server. The best option, when the database is completely cached in RAM. We get the required minimum size of RAM - 10GB. In practice, there are often situations when the 1C: Application Server version loses its response. This happens when there is insufficient RAM, when the OS is forced to swap 1C to disk. To prevent this from happening, we always recommend having a supply of RAM - a total of 16GB.

    Regarding the processor, again, the quad-core processor of the Intel Xeon E3 12XX series will cope quite well, we will only choose a higher clock frequency. Moreover, the dependence of 1C operating speed on the clock frequency in version 1C-8.3 is compensated by a certain effective frequency - the number of processor cores multiplied by the core clock frequency.

    The disk subsystem gets a little more complicated. Again, without going into details of the operation of disks with read-write operations (so-called IOPS), we note that the average operating speed in the same “mirror” will approximately double if we increase the number of disks in the mirror to four ( so-called RAID 10).

    Summing up, we get the basic server configuration for 15-20 users in the 1C: Application Server 8.3 system:

    • CPU - Intel Xeon E3 1240V3 3.4 GHz,
    • RAM - 16GB,
    • Disk subsystem - a mirror of 4 4x1TB disks.

  2. To improve the performance and reliability of the system as a whole, when the number of 1C:Enterprise users is more than 30, as a rule, a terminal solution is used. The essence of this solution is that user applications (in this case 1C) are launched and run on the terminal server itself, and the user sees only a graphic image that the server sends to his computer (terminal). In addition to high performance and scalability, we have additional reliability and protection of your data, which is determined by the configuration of the terminal server.

    Here, as a rule, disk arrays of a higher level of protection are already used (RAID 6, 60, combinations of RAID arrays implemented on a hardware, usually dedicated RAID controller).

    The choice of processor for such servers is determined by simple calculations - usually at least one physical core is allocated to SQL, at least one core for 1C: Application Server, 2 for the OS. The remaining cores are allocated to users.

    It is known that one processor core can effectively handle no more than 8 users. From the above criteria it is not difficult to understand that for efficient work more than 30 users, you need to make a choice in favor of 2-processor servers - at least in terms of the total number of cores.

    A typical configuration of a terminal server + 1C:Application server is shown below:

    • Processor: 2 x 4C/4T CPU | Intel Xeon E5-2609 V2,
    • Memory modules: 4 x DDR3-ER 8Gb,
    • Storage: 4 x HDD 1Tb, 4 x HDD 1Tb,
    • Controller: RAID.

  3. For more than 50 users, the roles of the terminal server (application server) and the database server are usually separated.

About two years ago we published material about the 1C Enterprise server on the Linux platform; interest in this topic is still great. At the same time, a lot has changed, the 1C platform does not stand still, and most often implementation goes beyond simply repeating instructions. This is not surprising, the 1C Enterprise server is a complex product, so we decided to start this series of articles aimed at a deeper study of the subject.

Before picking up the mouse and running to the server room, you should clearly understand the required minimum knowledge, namely, have an idea of ​​the structure of the 1C Enterprise server and the purpose of its individual components. Most of the problems during implementation are due to the fact that the 1C Enterprise server is perceived as a kind of monolithic formation in which all components are interconnected in a cunning way known to only one developer. However, this is not so, and today we will figure out what our server consists of and how it all works together.

I would like to once again emphasize the extreme importance of what will be discussed below. Without this knowledge, it will be difficult to achieve stable operation, not to mention diagnosing bottlenecks and increasing productivity. The result may be a classic picture: the hardware seems to be powerful, everything was done according to the instructions, but it slows down. Unfortunately, most instructions for beginners (including ours) contain information only on how to do it, without focusing on what exactly is being done and why. So let's start fixing things.

The client-server version of 1C Enterprise is a three-level structure (the so-called “three-tier”), which includes: a client, a 1C Enterprise server and a DBMS server. These are completely independent components that can be combined in any valid combination to achieve best result. Consider the following diagram:

Let's start with clients; the current version of the platform (8.2) provides for the use of three types of clients. Let's look at them in more detail.

Fat client

This is a classic 1C client application; before the release of platform 8.2, it was the only available type of client. The thick client operation scheme is as follows: the client application requests data from the 1C server, then in turn requests it from the database and passes it back to the client, where it is processed. As you can see, this scheme is not optimal: the 1C server is essentially just a layer between the client and the database, all calculations take place on the client. This imposes increased requirements on client PCs, because The server's computing power is not used. It is worth clearly understanding that in thick client mode you will not get an increase in performance from switching to the client-server version, perhaps even vice versa.

Thin client

It can be called the main type of client application for the 8.2 platform; in theory, in practice, not everything is so smooth and we will return to this. The way it works is radically different: the client requests data from the 1C server, which receives it from the database, processes it and returns the calculation result to the client. The main computing load falls on the server, so there are no special requirements for client PCs and the channel from the client to the server.

Also, the thin client can work using either the TCP/IP protocol or local network, and via HTTP over the Internet. This requires another intermediary - a web server, which transmits client requests to the 1C server; no data processing is performed on the web server, it is used exclusively as a transport. The advantages of a thin client are clear; if you have a powerful server, it allows you to significantly speed up work with the program; network traffic is also significantly reduced, which is very important for office networks.

Web client

Its existence logically follows from some properties of a thin client; indeed, if all requests are processed by the server, HTTP is used as transport, then why not use a browser for work? The way the web client works is no different from the thin client, however, today not all functions supported by the thin client are implemented and work correctly in the web client. In part, this can be corrected in the configuration; in part, the mechanism for displaying information in the browser imposes restrictions. However, 1C has a web client and it works and no one bothers you (again in theory) to work in the program while lying on the beach with a tablet.

Now about the fly in the ointment. For normal operation in thin and web client mode, the configuration must work in managed application mode and support all functions in this mode. Managed application mode is the main one for the 8.2 platform and is quite radically different from what was before, including in appearance. The visually driven application can be identified by its new interface, which features tabs and hyperlinks:

At the very least, it’s unusual, especially in comparison with the classic interface, but don’t rush to rejoice when you see new interface, except appearance, the configuration must support the execution of all its functionality on the server; it may well turn out that not all features will be available in the thin and web client modes.

Today, only a part of typical configurations work in managed application mode, such as: Small Firm Management, Trade Management 11, Retail 2 and Salary and HR Management. These solutions can take full advantage of the new platform. Enterprise Accounting 2.0 does not use a managed application mode and will not work in thin and web clients, the same applies to many third-party solutions, such as “Kamin”, etc.

conclusions

If possible, you should use a thin client, as this allows you to shift all calculations to the server side and work comfortably even on slow channels, incl. through the Internet. It should be remembered that working in Configurator mode is only possible through a thick client, which will also have to be used to work with configurations that have not yet been transferred to managed application mode.

The web client should be used when it is not possible to use a thin one, for example from someone else’s PC on a business trip, but you should be prepared for the absence or incorrect operation some functions.

1C server cluster

Having dealt with clients, let's move on to servers. The system provides for the use of three types of servers: 1C Server, DBMS server and web server. It is important to understand that the server data is completely independent of each other; this gives the system flexibility and allows rational use of computing resources.

Also, the system does not impose any requirements on platforms. You can share both Windows and Linux servers, Apache and IIS can be used as a web server; PostgreSQL, MS SQL Server, IBM DB2 and Oracle are supported from the DBMS. Therefore, no one is stopping you from creating a scheme in which a 1C server running on the Linux platform will work together with a database server running Windows control Server and IIS and vice versa. In addition, you can use several DBMS servers (as well as web servers) by placing different databases on different servers.

This approach allows you to flexibly combine, expand and change the existing configuration depending on current needs, while everything will be as transparent as possible for the end user. For example, you can move resource-intensive information security to a separate DBMS server by changing only the database connection parameters in the server settings without affecting the client settings.

And finally the most interesting thing: a cluster of 1C Enterprise servers. Yes, that’s right, not a single server, but a cluster of servers. Usually this is where confusion begins, especially if there is only one server. However, everything falls into place if we take into account that the concept of a server cluster is primarily logical, but this approach easily allows you to scale the scheme, increasing its performance or fault tolerance.

Any cluster consists of a 1C Enterprise Central Server and working servers. In the simplest configuration, this will be the same physical server. However, if necessary, we can add additional working servers, the load of which will be balanced by the central server. This allows you to quickly and transparently increase the computing power of the system and increase fault tolerance. The cluster also does not impose requirements for platform homogeneity; it can include servers running both Windows and Linux.

What conclusions can be drawn from the above? Firstly, the 1C Enterprise client-server system is very flexible and allows you to optimally use the available computing resources to obtain the optimal result. Which configuration to choose depends on the specific tasks and the funds allocated to solve them.

For example, if you have a light load and are using a thick client and a configuration that does not support managed application mode, it makes sense to combine a cluster of 1C servers and a DBMS server on one physical server, since it is very wasteful to allocate a separate machine for the layer between the client and the database.

Conversely, when using a managed application in thin client mode, it is better to separate the DBMS server and the server cluster into different servers, each of which will be optimized for its own task.