На сегодняшний день финансовый продукт 1С из прикладной учетной программы для бухгалтерии вырос в широкоформатный комплекс для учета и сопровождения практически любого вида бизнеса, претендуя на конкуренцию с мировыми «монстрами» SAP R/3 и Microsoft Dynamics AX (Axapta).

Российские компании все чаще организовывают свои бизнес-процессы с помощью современных конфигураций 1С 8.3 «Управление торговлей», «Управление производством», «ERP Управление предприятием» и тому подобных. На 1С переводятся отделы бухгалтерии, маркетинга, производственные, продаж, проводится интеграция с системами IP-телефонии и документооборота. Однако, сразу после намерений «давайте работать в 1С» возникают вопросы - на каких ресурсах будет работать центральная база 1С, какое «железо» покажет оптимальный результат за разумный бюджет? Предприятиям-гигантам госсектора в этой ситуации проще – дана чёткая команда многочисленным штатным ИТ-интеграторам и архитекторам, завертелись механизмы крупнобюджетных тендеров с обязательным условием предоставления концепции «под ключ» и дальнейшего сопровождения системы сертифицированными специалистами. А как же быть компаниям, которые хотят сами приобрести и установить себе один из продуктов 1С: Предприятие, разумно расходуя бюджет?

Самой основной ошибкой, если не брать в расчёт использование пиратского или непроверенного ПО, является экономия на аппаратном обеспечении для 1С. Подобные тенденции особенно часто прослеживаются в стартапах и небольших компаниях. Бытует мнение, что не обязательно покупать дорогое серверное оборудование с процессорами типа Intel Xeon, не нужно предварительно рассчитывать объемы ОЗУ, нагрузку на ЦПУ и дисковую подсистему, что нет необходимости создавать избыточность дисковых массивов (Raid), использовать профессиональные дисковые контроллеры с Cache-RAM и так далее. Ошибки в расчетах ИТ-архитектуры для 1С приводят к печальным последствиям, о которых компания узнает уже по факту остановки бизнес-процессов. Поэтому очень важно уделять внимание каждому аппаратному узлу серверной платформы для 1С.

Примеры типичных проблем из-за неправильного построения ИТ-архитектуры под 1С:
  • «Торможение» базы и интерфейсов 1С из-за превышения нагрузки на ключевые ресурсы (обычно, ОЗУ или дисковую подсистему).
  • Ошибки и «вылеты» программы 1С из-за нестабильности работы неверно подобранного оборудования.
  • Простои работы компании по причине выхода из строя центрального аппаратного обеспечения.
  • Частичные либо полные потери данных 1С из-за случайных сбоев аппаратных комплектующих или программного обеспечения.

Аппаратные ресурсы сервера 1С

Рассмотрим ниже наиболее ключевые аппаратные ресурсы, ошибка в выборе которых может загубить весь проект автоматизации предприятия при самостоятельном создании сервера под 1С.

Центральный процессор (CPU)

Количество физических ядер центрального процессора. Тема извечных споров на всевозможных форумах по 1С – что важнее частота CPU или многоядерность. Корни этих противоречий уходят в прошлое, к 1С 8.0 или даже 1С 7.7. Действительно, исполняемые процессы 1С более ранних версий были сугубо одноядерными, т.е. сколько бы ядер не предоставлял центральный процессор – служба сервера предприятия 1С 8.0 или «толстый клиент 1С 7.7» всегда занимали только одно «нулевое» ядро в операционной системе. На сегодняшний день картина изменилась – операционная система смело распределяет задания одного процесса 1С: Предприятие (rphost) по нескольким ядрам ЦПУ (см. рисунок 1).




Рисунок 1 - Нагрузка на ЦП при работе процессов сервера 1С.


Но это абсолютно не значит, что если купить процессор с максимальным количеством ядер, то сервер 1С в паре с СУБД (чаще всего под СУБД имеется ввиду MS SQL) покажут фантастическую производительность и перепроведение бухгалтерских периодов в программе 1С станут делом нескольких минут. Нужно понимать отличие между скоростью выполнения одной операции и процессом одновременной обработки большого объема информации. Количество физических ядер как раз позволяет решить вопрос стабильности и производительности одновременной работы с множеством разных заданий сервером 1С:Предприятия и СУБД. Отсюда вывод – чем больше количество пользователей 1С, тем больше будет играть роль нужное количество ядер для комфортной одновременной работы этих самых пользователей. Зависимость количества пользователей от количества ядер для сервера 1С показана в таблице 1.


Количество одновременно работающих пользователей на сервере 1С:Предприятие Тип и модель процессора Количество используемых ядер
До 10 пользователей Пользовательский Intel Core от 3.1Ghz Не более 2-4
До 20 пользователей Серверный Intel Xeon от 2.4 Ghz От 4 до 6
До 30 пользователей Серверный Intel Xeon от 2.6 Ghz От 6 до 8 ядер
До 50 пользователей Серверный Intel Xeon от 2.4 Ghz – в количестве 2 шт От 4 на каждый процессор

Таблица 1 - Соотношение количества пользователей на сервере 1С и рекомендуемого количества ядер ЦП.


Частота центрального процессора. В противовес к количеству ядер – частота работы центрального процессора влияет именно на скорость обработки одного кусочка задания в один момент времени, что является самым популярным критерием конечных пользователей 1С. Частота процессора – это именно тот параметр, при увеличении которого у отдельно взятого пользователя увеличится скорость обработки запросов сервером 1С и СУБД и уменьшится время, за которое система предоставит итоговый результат конечному пользователю. В подтверждение этому известный специалист Гилев в одной из своих статей на базе практических тестов сделал однозначный вывод - «на скорость работы 1С гораздо больше влияет частота центрального процессора, нежели остальные его параметры, будь то конечный клиент 1С или же сервер 1С:Предприятие». Такова архитектура программы 1С.

Кеш, виртуализация и гиперпоточность (hyper threading). В прошлом, когда многоядерные процессоры еще не были так распространены – компанией Intel была придумана специальная технология центрального процессора, имитирующая многоядерность, так называемая «гиперпоточность». После её включения один физический процессор (одно физическое ядро) определяется операционной системой как два отдельных процессора (два логических ядра). Рекомендуем для сервера 1С «гиперпоточность» отключать. Никакого ускорения работы 1С эта технология не приносит.

При использовании виртуальных машин для сервера 1С:Предприятие и СУБД нужно учитывать, что ядра виртуальных машин «слабее» реальных физических ядер, хотя называются одинаково – «ядра». Точных официальных коэффициентов нет, но статьи на технических порталах Microsoft рекомендуют на одно физическое ядро считать 4-6 ядер процессора в виртуальной машине.

Кеш – это сверхоперативная память, используемая процессором для уменьшения среднего времени доступа к компьютерной памяти. По сути, она является неотъемлемой частью процессора, поскольку расположена на одном с ним кристалле и входит в состав функциональных блоков. Здесь всё предельно ясно – чем больше объем кэша, тем более крупные «кусочки» информации сможет обрабатывать процессор. Обычно величина кэша зависит от моделей процессора – чем модель дороже, тем обычно больше там объем кеш-памяти. Однако мы не считаем, что величина кеша процессора кардинально влияет на производительность сервера 1С и СУБД. Скорее это относится к области «тонкого тюнинга».

Тип процессора. Всем известно, что аппаратное обеспечение делится на серверное и пользовательское. А можно ли в отдельных случаях использовать недорогой пользовательский центральный процессор как альтернативу профессиональному, но дорогостоящему серверному ЦПУ? Оказывается – можно. Рассмотрим таблицу сравнения основных параметров двух вариантов центральных процессоров Intel (см. таблицу 2).

Пользовательский Intel® Core™ i7-6700T Processor (8M Cache, up to 3.60 GHz) Серверный Intel® Xeon® Processor E5-2680 v2 (25M Cache, 2.80 GHz)
Кэш-память 8 MB 25 MB
Частота системной шины 8 GT/s DMI3 8 GT/s QPI
Набор команд 64-bit SSE4.1/4.2, AVX 2.0 64-bit AVX 2.0
Количество ядер 4 10
Базовая тактовая частота процессора 2.8 GHz 2.8 GHz
Макс. объем и тип оперативной памяти 64 GB non-ECC 768 GB ECC
Ориентировочная стоимость 354$ 1 280$

Таблица 2 - Сравнение основных параметров домашнего и серверного ЦП от Intel.


Как мы видим, серверный процессор имеет гораздо более высокие значения в количестве ядер, в объеме кэша, поддержке большего объема оперативной памяти и, конечно же, в более высокой цене. Однако, серверный ЦПУ практически не отличается от пользовательского в поддержке определенных процессорных команд (инструкций) и в тактовой частоте. Отсюда можно сделать вывод – для небольших организаций вполне допустимо применение пользовательского центрального процессора для сервера 1С:Предприятие. Вопрос только в том, что пользовательский процессор не может быть установлен в сокет серверной материнской платы и поддерживать серверную ОЗУ с контролем четности (ECC), а использование пользовательских комплектующих влечет за собой риски стабильности работы всей системы в целом.

Оперативная память (ОЗУ)

Тип оперативной памяти. Планка оперативной памяти (ОЗУ) различается по ее предназначению – для многопользовательских серверных систем или для персональных устройств – ПК, ноутбуков, неттопов, тонких клиентов и т.д. Как и в случае с ЦПУ – основные параметры модулей ОЗУ примерно равнозначны – современная ОЗУ для ПК практически не отстает от серверной ни в объеме одной планки, ни в тактовой частоте, ни в типе модулей DDR. Отличия серверной ОЗУ от «домашней» в вариантах использования и предназначения аппаратной платформы - отсюда же формируется ее более высокая стоимость:

  • Серверная ОЗУ имеет контроль четности ECC (Error Correction Code) - технику кодирования/декодирования, позволяющая исправлять ошибки в обработке информации непосредственно модулем ОЗУ
  • Серверная материнская плата имеет гораздо больше разъемов под установку модулей ОЗУ, чем обыкновенный ПК
  • Серверная ОЗУ содержит регистры (буферы), обеспечивающие буферизацию данных (частичную Registered либо полную Full Buffered), за счет чего уменьшается нагрузка на контроллер памяти при множестве одновременных запросов. Буферизованные модули "FB-DIMM", несовместимы с небуферизованными.
  • Модули регистровой памяти также позволяют повысить масштабируемость памяти - наличие регистров дает возможность устанавливать больше модулей в одном канале.

Можем сделать вывод, что использование серверных модулей оперативной памяти дает возможность устанавливать большие объемы ОЗУ в одной системе, а техники контроля четности ECC и использование буферов позволяют серверной операционной системе работать стабильно и быстро.

Объем оперативной памяти. Одним из ключевых факторов для высокой производительности сервера 1С и СУБД является достаточный объем оперативной памяти. Конечно же фактические потребности в ОЗУ зависят от многих факторов – тип конфигурации 1С, количество процессов сервера 1С:Предприятие, объем базы СУБД и так далее. Однако можно вывести примерную зависимость объема ОЗУ от количества пользователей (см. таблицу 3).


Потребность ОЗУ для сервера 1с и СУБД До 10 пользователей До 20 пользователей До 30 пользователей До 50 пользователей
Сервер 1с:Предприятие 4-6 Гб 6-8 Гб 12-14 Гб 18-24 Гб
Сервер MS SQL 4-6 Гб 8-10 Гб 16-18 Гб 24-28 Гб

Таблица 3 - Примерное соотношение количества пользователей сервера 1С и рекомендуемой оперативной памяти на процессы сервера 1С:Предприятие и сервера MS SQL.


Касательно процессов сервера 1C:Предприятия (rphost.exe) - современные платформы 1С не позволяют в ручном режиме указывать количество процессов сервера 1С. Вместо этого, система требует задать параметры, такие как количество информационных баз и количество пользователей на один процесс rphost.exe, после чего сама автоматически определяет оптимальное количество процессов сервера 1С:Предприятие. Так же можно настроить плавное освобождение процессом rphost.exe ОЗУ в случае, если ее объем превышает заданный заранее порог. При этом сервер 1С создает новый процесс rphost.exe, который постепенно берет на себя задания 1С, позволяя разгрузить требуемый процесс 1С.

Также нужно обратить внимание, что объем ОЗУ, выделенный службе SQL считается достаточным, если попадание данных SQL в cache составляет не менее 90%. Эта метрика довольно удобна, т.к. просто посмотреть количество потребляемой ОЗУ сервером SQL нельзя – последние выпуски SQL имеют динамически потребляемую ОЗУ - захватывается максимально возможное количество ОЗУ и высвобождается по мере запроса ОЗУ другими процессами.

Частота оперативной памяти. Если коротко, то это пропускная способность каналов, по которым данные передаются на материнскую плату, а оттуда - в процессор. Желательно, чтоб этот параметр совпадал с допустимой частотой материнской платы или превышал ее, иначе канал передачи ОЗУ рискует стать «узким местом». В рамках одного типа DDR увеличение\уменьшение частоты кардинальным образом не влияет на производительность сервера 1С и относится больше к области «тонкого тюннинга».

Тайминги оперативной памяти. Это задержи или латентность (Latency) ОЗУ. Характеризуется этот параметр временем задержки данных при переходе между разными модулями микросхемы ОЗУ. Меньшие значения означают более высокое быстродействие. Однако, влияние на общее быстродействие серверной системы, а уж тем более, на сервер 1С:Предприятия – невысоко. Обычно, внимание на эти параметры обращают только геймеры и оверклокеры, для которых каждая лишняя капля производительности - дороже всего.

Дисковая подсистема и жесткие диски HDD

Контроллеры жестких дисков. Основным устройством соединения и организации жестких дисков в аппаратной системе является контроллер жестких дисков. Он бывает двух типов:

1. Встроенный – модуль контроллера встроен в систему, корзина с жесткими дисками подключается непосредственно в материнскую плату. Считается более экономным решением.

2. Внешний – представляет собой отдельную печатную плату (устройство), которая подключается в разъем материнской платы. Он считается более профессиональным решением за счет того, что имеет отдельные чипы проведения и контроля операций с жесткими дисками HDD. Рекомендуется для важных серверных систем, таких как сервер 1С:Предприятия и СУБД.

Существует еще третий тип – устройство приема\передачи блочных данных по каналам iSCSI, FiberChanel, InfiniBand, SAS. Однако в этом варианте дисковая подсистема «вынесена» на отдельное устройство хранения данных (СХД), соединяемое с сервером посредством оптического или медного кабеля. В нашей статье мы делаем разбор требований к автономному серверу для 1С, поэтому данный тип мы рассматривать не будем.

Типы и уровни RAID-массивов. Это технология виртуализации данных, которая объединяет несколько дисков в логический элемент для избыточности и повышения производительности. Рассмотрим наиболее популярные уровни спецификации RAID:

  • RAID 0 (“Striping”) избыточности не имеет, а информацию распределяет сразу по всем входящим в массив дискам в виде небольших блоков («страйпов»). За счет этого существенно повышается производительность, но страдает надежность. Мы не рекомендуем использовать этот тип массива, несмотря на повышение производительности.
  • RAID 1 (“Mirroring”, «зеркало»). Имеет защиту от выхода из строя половины имеющихся аппаратных средств (в общем случае – одного из двух жестких дисков), обеспечивает приемлемую скорость записи и выигрыш по скорости чтения за счет распараллеливания запросов. Такой тип массива вполне «потянет» сервер 1С+СУБД до 25-30 пользователей, особенно, если будут использованы диски SAS 15K либо SSD.
  • RAID 10. Зеркальные пары дисков выстраиваются в «цепочку», поэтому объем полученного тома может превосходить емкость одного жесткого диска. По нашему мнению, наиболее удачный тип дискового массива, т.к. в нем соединяются надежность RAID1 и быстродействие RAID 0. В сочетании с дисками SAS 15K либо SSD может быть использован для серверов 1С от 40-50 пользователей.
  • RAID 5. Знаменит благодаря своей экономичности. Жертвуя ради избыточности емкостью всего одного диска из массива, получаем защиту от выхода из строя любого из жестких дисков системы. (его вариация RAID 6 требует лишние два жестких диска для размещения контрольных сумм, но зато сохраняет данные даже при выходе из строя двух дисков). Данный тип массива экономичен, надежен и имеет довольно ощутимое быстродействие «на чтение». К сожалению, узким местом этого массива является низкая скорость записи, что позволяет комфортно использовать его при конфигурациях сервера 1С до 15-20 пользователей. Также он оптимален для прикладных целей – хранения файловых данных, архивов документооборота и т.д.

Типы интерфейсов жестких дисков. По типу подключения жесткие диски разделяются:

  • HDD Sata Home. Наиболее дешевый вариант жестких дисков, предназначенный для использования в домашних ПК либо сетевых медиа-центрах. Убедительно не рекомендуется использовать подобные устройства в серверах 1с в связи с низким коэффициентом отказоустойчивости и стабильности работы – компоненты этих дисков попросту не предназначены для работы в режиме 24/7 и быстро выходят из строя.
  • HDD Sata Server. Под данным наименованием обычно понимаются жесткие диски с интерфейсом Sata и скоростью вращения шпинделя 7 200 оборотов\мин. Приставка «Server» означает, что такие диски проходили тестирование на работоспособность в серверных системах и рассчитаны на стабильную работу в режиме 24/7. Обычно используются в серверах 1С для хранения больших объемов информации, не требующей высокой скорости ее обработки. К примеру – архивные базы 1с, папки обмена, файлы выгрузок офисных документов и т.д.
  • HDD SAS Server. Отличий интерфейса SAS (современного аналога SCSI) от интерфейса Sata несколько. Здесь и среднее время отклика диска, и работа в общей дисковой полке, и работа с контроллером HDD на более высоких скоростях обмена информацией – до 6 Гб\с (по сравнению с Sata 3 Гб\с). Но главное преимущество - существование моделей SAS-дисков со скоростью вращения шпинделя 15 000 оборотов\мин. Именно эта конструктивная особенность позволяет SAS-дискам проводить почти в 3 раза больше операций ввода\вывода в секунду по сравнению с HDD Sata Server. Такие диски SAS имеют небольшой объем и их рекомендуется использовать под основные базы данных 1с с постоянно высокой рабочей нагрузкой.
  • SSD диски. Эти диски отличаются от предыдущих не интерфейсом подключения, а своей конструкцией – они твердотельные и не имеют движущихся частей, т.е. по своей сути являются аналогами «флешек». Такие технологии позволяют SSD-дискам производить «запредельное» количество операций ввода\вывода в секунду (от 10 000 операций на самых простых моделях SSD). Однако подобное преимущество имеет и обратную сторону – более высокая цена SSD-дисков и «порог их жизни», который зависит от предела количества записи в блоки SSD. Впрочем, с каждым годом эти диски становятся все более доступными и долговечными. Поскольку стоимость SSD дисков многократно возрастает в зависимости от объема – разумнее всего будет использовать их под небольшие, но сверх-нагруженные базы данных 1с, требующие высокой скорости доступа, а так же под временные базы СУБД TempDB.

IOPS – количество операций ввода-вывода в секунду. По сути, IOPS - это количество блоков информации, которое успевает считаться или записаться на носитель за 1 секунду времени. То есть, в чистом виде - это и есть ключевой параметр скорости обработки информации жестким диском, влияющий на производительность 1С сервера. Если брать для сравнения стандартный блок информации 4кб, то можно примерно выделить следующие показатели IOPS (см. таблицу 4).


Жесткий диск IOPS Интерфейс
7,200 об/мин SATA-диски ~75-100 IOPS SATA 3 Гбит/с
10,000 об/мин SATA-диски ~125-150 IOPS SATA 3 Гбит/с
10,000 об/мин SAS-диски ~140 IOPS SAS
15,000 об/мин SAS-диски ~175-210 IOPS SAS
SSD-диски От 8 000 IOPS SAS либо SATA

Таблица 4 - Показатели IOPS на различых типах жестких дисков при работе с блоком данных 4кб.


Конечно же, в чистом виде IOPS мало чем полезен для калькуляции итоговых расчетов и требований к дисковой подсистеме сервера 1С. Ведь суммарная производительность дисковой подсистемы складывается из типа RAID-массива, типов диска и показателей скорости его интерфейса, времени отклика (Latency), времени произвольного доступа, процентного соотношения количества операций чтения и записи и множества других факторов. Однако данный параметр, по нашему мнению, является ключевым показателем скорости дисковой подсистемы и на этапах разработки серверной архитектуры, помогает определить – какой же тип жестких дисков вообще будет наиболее подходящим для тех или иных потребностей. (см. RAID-калькулятор)

Практический тест

Какая же зависимость между количеством пользователей 1С и количеством iops? Наша команда провела практический тест (см. таблицу 5) по измерению нагрузки на дисковую подсистему определенным количеством сессий 1С. Поскольку система 1С является программируемой средой и каждая компания может иметь свой набор бизнес-процессов в 1С – нам требовалась привязка к некой эталонной конфигурации для тестирования. В этом качестве была выбрана специализированная конфигурация ЦУП 1С, разработанная для тестирования и отладки. На ее базе наши программисты 1С добавили ряд запросов, имитирующих нормальную работу обычного предприятия, с формированием бухгалтерских запросов, проводок, составлением отчетов и проведением операционных документов.


Системный диск Диск с базами данных
Итерация Пользователи IOPS write IOPS read IOPS write IOPS read
Средние значения
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

Таблица 5 - Результаты практического теста по нагрузке на дисковую подсистему.


Результаты теста показывают, что львиная доля нагрузки на дисковую подсистему возникает при записи 1С в базу данных сервера СУБД и на системный диск операционной системы (на котором по умолчанию располагаются файлы кеш-сервера 1С:Предприятие).

Параллельно мы провели практические замеры уже работающих баз 1С УПП 8.2 на протяжении тестового периода – 5 рабочих дней. Они показывают, что в среднем сервер 1С + СУБД потребляет в два раза больше iops «на запись», чем «на чтение». Такая разница между синтетическими тестами и статистикой мониторинга реального сервера 1С обусловлена как периодическими выборками информационных данных с базы в течение рабочего дня, так и регулярным чтением базы при резервном копировании или репликации СУБД.

Прочие составляющие жесткого диска, на которые стоит обратить внимание.

  • Физический размер (форм-фактор). На сегодняшний день почти все известные накопители для персональных компьютеров и серверов имеют размер 3,5 либо 2,5 дюйма. Отметим, что диски 2,5 дюйма не производятся больших объемов.
  • Время произвольного доступа (random access time) - время, за которое жесткий диск гарантированно выполнит операцию чтения-записи на определенном участке магнитного диска. Как правило, более высокими результатами обладают серверные диски. Это является достаточно важным параметром при построении массива дисков для сервера СУБД 1С.
  • Скорость вращения шпинделя - количество оборотов шпинделя жесткого диска в минуту. Здесь все просто и понятно - от скорости вращения шпинделя с магнитными пластинами зависят время доступа и средняя скорость передачи данных жесткого диска.
  • Объём буфера жесткого диска - буфером называется временная память, предназначенная для сглаживания различий в скорости чтения/записи жесткого диска и передачи данных по интерфейсу.
  • Надёжность - определяется как среднее время наработки на отказ (MTBF). Как правило, надежность напрямую зависит от производителя, цены и среды использования жесткого диска. Мы считаем надежность важным параметром жесткого диска, влияющим на качество работы сервера 1С.

Правильный выбор: домашнее или серверное «железо»

Удешевление аппаратных комплектующих и активный рост потенциальных мощностей «домашних компьютеров» приводят еще к одному губительному заблуждению – малый бизнес активно использует рабочие станции в качестве платформы для совместной работы с базами 1С. При этом, не осознавая, что помимо параметров частоты ядра, объема памяти и возможности использования бюджетных SSD-дисков в обычном ПК – существуют более системные, более глубокие и важные требования к работе аппаратного обеспечения в коммерческой структуре (см. таблицу 6).

Для решения вопроса организации сервера 1С мы предлагаем аренду облачных серверов 1С в дата-центрах класса Tier III. С экономической целесообразностью выбора аренды сервера можно ознакомиться в статье .


Параметры Сервер Персональный компьютер
Достаточность вычислительных мощностей V V
Гарантированная работоспособность системы в режиме 24/7 V X
Надежность и стабильность ключевых аппаратных комплектующих V X
Возможность удаленного управления питанием и консолью (IPMI) V X
Бюджетная стоимость аппаратной платформы X V

Таблица 6 - Сравнение домашнего и серверного железа по критериям, требуемым для качественной работы сервера 1С.

Отказоустойчивая работа 1С

Безусловно, одним из важных требований к серверной части 1С является стабильность ее работы и устойчивость к отказам. Компания Microsoft и сама фирма 1С приложили много усилий в этом направлении, создав технологии кластеризации своих сервисов на довольно серьезном уровне (см. таблицу 7).


Отказоустойчивость SQL серверов Базирована на концепции единого общего хранилища данных. Встроенная технология кластеризации SQL Server объединяет два SQL сервера в один кластер с единым виртуальным IP-адресом и единой базой. Таким образом при выходе из строя основного SQL - запросы автоматически переводятся на резервный.
Вторым вариантом является недавно появившаяся AlwaysOn - технология автоматической регулярной репликации баз СУБД между основным и резервным серверами SQL. При этом дублирующий сервер SQL находится физически на другом хранилище, что повышает устойчивость к рискам
Отказоустойчивость службы сервера 1С:Предприятие Серверы 1С Предприятия объединяются в программный отказоустойчивый кластер active-active с автоматическим переключением при сбое и сохранением текущих сессий.

Таблица 7 - Отказоустойчивость SQL и 1С-серверов.


Однако, каждая технология имеет как плюсы, так и минусы. Помимо ключевых преимуществ, требуется знать некоторые особенности кластеризации 1С и SQL (), чтобы не получить в итоге ухудшение работоспособности сервиса:

  • Кластеризация SQL использует виртуальный IP. А это значит, что взаимодействие сервера 1С:Предприятие и MS SQL всегда будет происходить по сетевому интерфейсу, даже если оба сервиса находятся в одной операционной системе. Что соответственно приведет к замедлению работы 1С в сравнении с классическим вариантом архитектуры, рекомендуемым самой компанией 1С – использованием разделяемой памяти Shared Memory. В принципе, эту помеху можно «обойти», используя, к примеру, технологию MS SQL Log Shipping. Однако, в таком случае переключение на резервный сервер SQL уже не будет автоматическим и этот вариант нельзя считать полноценным кластером.
  • Кластер SQL требует крупных бюджетных затрат. Если речь идет о классической кластеризации сервиса MS SQL – требуется единое хранилище баз, подключенное к основному и резервному серверам SQL. Обычно в этой роли выступают дорогостоящие системы хранения данных СХД, что увеличивает бюджет на порядок. Если речь идет о новомодной AlwaysOn, то единое хранилище баз не требуется, технология работает с локальными дисками основного и резервного серверов по сети. Зато требуется версия SQL Server Enterprise, лицензия на которую стоит в 4 раза больше, чем на обычный SQL Server StandarD.
  • Количество лицензий. Несмотря на то, что второй сервер SQL не обрабатывает данные и находится в резерве – лицензии нужно будет приобрести на оба сервера – как основной, так и резервный. Особенно болезненным для бюджета являются лицензии SQL Server Enterprise для реализации распределенного кластера групп высокой доступности AlwaysOn.
  • Не нужно использовать дешевое пользовательское аппаратное обеспечение для столь важного сервиса как учетная система всего предприятия. Цена в данном случае напрямую предопределяет качество, стабильность и долговечность такой платформы.
  • Рекомендуем при выборе серверной платформы обращать внимание на наличие двух блоков питания, удаленную карту IPMI и бренд производителя. Конечно же, каждый подбирает решение, исходя из своего бюджета, топовые бренды иногда слишком дороги и не совсем уместны, однако не стоит уж совсем экономить на производителе, это может привести к неконтролируемым форс-мажорам в работе с 1С. Лично мы используем серверные платформы Supermicro в сочетании с серверными ЦПУ Intel.
  • Есть мнение, подтвержденное практикой, что производительность 1С больше зависит от более высокой частоты работы ЦПУ, чем от количества предоставленных ядер.
  • Не нужно экономить на объеме оперативной памяти, выделяемой для сервера 1С и службы SQL. ОЗУ на данный момент является достаточно дешевым ресурсом, а ее нехватка (даже на 10-15 процентов) приведет к сильному падению производительности системы 1С, т.к. включится более медленная система подкачки (swap). Плюс ко всему swap даст дополнительную нагрузку на дисковую подсистему что еще сильнее ухудшит ситуацию.
  • Компания EFSOL предлагает комплексные услуги по подбору сервера 1С , в которые входит: проектирование сервера 1С, закупка, настройка и обслуживание.
  • Альтернативным собственному созданию сервера 1С вариантом является аренда сервера для 1С . Облачные технологии позволяют при небольших ежемесячных затратах пролучить надежный отказоустойчивый сервис для комфортной работы в 1С.

Системная интеграция. Консалтинг

Сегодня мы рассмотрим выбор серверного «железа» для небольшой организации на 25-30 пользователей, с распределенной инфраструктурой (торговые точки, склад), которой требуются терминальный сервер и программа «1С: Предприятие». Этими сервисами будут пользоваться все сотрудники.

Большинство малых компаний, для удешевления стоимости оборудования, предпочитают минимизировать количество приобретаемой техники и просят администраторов «впихнуть» все запрошенные ими сервисы в один физический сервер. Желание понятное и простительное, но тут «есть нюансы».

Можно организовать терминальный сервер и использовать там файловую версию 1С, но при таком количестве пользователей компания-разработчик рекомендует переходить на клиент-серверный вариант. Поэтому нам потребуется еще сервер под «1С: Предприятие» и сервер баз данных. Уточним сразу, что организовать терминальный сервер, сервер SQL и сервер 1С на одной операционной системе возможно, но, с точки зрения безопасности и стабильности работы сервисов, это крайне не рекомендуется. А если всё-таки очень хочется использовать один физический сервер для всех трёх ролей, то рекомендуем использовать виртуализацию, например, VMWare ESXi или Hyper-V.
Таким образом, вырисовывается три варианта:

  1. Один сервер с файловой 1С. Плохой вариант, далее мы его рассматривать не будем.
  2. Один сервер с двумя виртуальными машинами.
  3. Два физических сервера, один терминальный, второй с БД и 1С.

Для решения этих задач можно предложить следующую конфигурацию серверов:

В случае с одним физическим сервером мы остановили выбор на Dell R710, с двумя шестиядерными процессорами Xeon X5650, 64 Гб оперативной памяти и шестью дисками: два SSD в RAID 1 и четыре SAS-диска в RAID 10.

В случае с двумя физическими серверами мы остановили выбор на таких конфигурациях:

  • Терминальный сервер: IBM x3550 M3 с одним процессором Xeon E5620, 32 Гб оперативной памяти и двумя SSD в RAID 1, с дополнительной сетевой картой на два гигабитных интерфейса. У этого сервера также есть богатые возможности для апгрейда, так как он двухпроцессорный, имеет 18 слотов под модули памяти и поддерживает до 288 Гб ОЗУ.
  • Сервер баз данных: IBM x3250 M5 с одним процессором Xeon E3-1220v3, 16 Гб ОЗУ, дополнительным RAID-контроллером SAS/SATA, четырьмя SAS-дисками в RAID 10, с дополнительной сетевой картой на 2 гигабитных интерфейса.
Почему мы выбрали именно такие конфигурации? Для ответа на этот вопрос давайте подсчитаем, что нам нужно для обеспечения комфортной работы пользователей в нашей небольшой организации на 25-30 сотрудников. Чтобы не было недопонимания: это лишь один из примеров недорогого внедрения 1С, и во многих случаях целесообразнее выбрать другие конфигурации.

Процессор

С точки зрения процессорного времени терминальные сессии занимают не очень большую долю. По опыту внедрения терминальных решений в различных организациях, для поддержания комфортной работы 30-ти пользователей достаточно будет 4-6 физических ядер процессора, по одному ядру на 6-8 сессий.

Для небольшой базы SQL-серверу понадобится одно ядро. Но мы будем ориентироваться на расширение базы в будущем (или увеличение количества баз) и возьмем два ядра на SQL.

Для сервера «1С: Предприятие» важно не столько количество ядер, сколько их тактовая частота и частота шины. Поэтому заложим еще два ядра на сервер 1С.
И не забудем, что в случае использовании виртуализации одно или два ядра нам пригодится для обеспечения работы хостовой операционной системы.

Итого у нас получается:

  • для сервера с двумя виртуальными машинами нужно 12 физических ядер. Можно и меньше, но всегда должен оставаться запас по мощности. Сервер с двумя шестиядерными процессорами подходит для этого идеально.
  • для терминального сервера достаточно одного процессора Xeon E5620 с шестью ядрами, для сервера баз данных - процессора Xeon E3-1220v3 с четырьмя ядрами.

Оперативная память

Сначала посмотрим, сколько нужно оперативной памяти под сервисы:
  • Операционная система Windows Server только под себя требует 2 Гб ОЗУ.
  • Для SQL и небольшой базы 1С достаточно будет 4-6 Гб ОЗУ.
  • Сервер «1С: Предприятие» требует еще 2-3 Гб ОЗУ.
  • Рассчитываем, что каждому пользователю потребуется 700 Мб ОЗУ в терминальной сессии, тогда на 30 пользователей потребуется 21 Гб.
Теперь применим это к нашим вариантам.
  • Для одного сервера с двумя виртуальными машинами нужно около 40 Гб ОЗУ.
  • Для терминального сервера достаточно будет 24 Гб или 32 Гб ОЗУ (возьмем с запасом, предполагая будущее расширение). Для сервера с базами данных нужно не менее 8 Гб, но это «впритык», поэтому 16 Гб с запасом. Память сейчас - один из самых дешевых компонентов сервера.

Дисковая подсистема

Это традиционное бутылочное горлышко многих систем. Правильный выбор жестких дисков очень важен для обеспечения быстродействия серверов. При работе 1С с базой SQL происходит множество операций чтения/записи в секунду (IOPS). Если пользователи работают на терминальном сервере с тонких клиентов (т.е. полноценно используют терминальный сервер как рабочую среду), это сильно нагружает дисковую систему сервера. Например, 30 пользователей терминального сервера на RAID 1, SATA 3 Гбит/с, с дисками WD Velociraptor чувствуют себя некомфортно при работе с почтой и активном сёрфинге в интернете. Для терминальных серверов мы рекомендуем использовать SSD-накопители. Для серверов баз данных - SAS-диски, собранные в отказоустойчивые массивы.

Помимо накопителей, следует уделить внимание и дисковому контроллеру. Современные серверы имеют на борту довольно хорошие контроллеры, например, HP SmartArray и DELL PERC. Однако некорректно будет использовать «набортные» решения при серьёзной нагрузке, когда требуется максимальная производительность. Немного сэкономив, вы легко можете получить мощный сервер, который совершенно не тянет нагрузку. Поэтому контроллер должен быть , со своей энергонезависимой памятью.

Рассмотрим варианты решения этой задачи.

  • Для одного сервера с двумя виртуальными машинами желательно использовать два RAID-массива: на одном будут располагаться файлы виртуальной машины терминального сервера, на втором - файлы виртуальной машины сервера баз данных и «1C: Предприятия». Для создания первого массива лучше всего использовать два SSD-накопителя в RAID 1 (зеркало).

    Второй массив лучше создать из четырёх SAS-диска в RAID 10 (зеркало + страйп), но можно и из двух SSD-накопителей в RAID 1. Выбор зависит только от стоимости дисков и модели сервера.

  • Для двух серверов всё то же самое, только массивы будут разнесены по серверам. На терминальном - RAID 1 из двух SSD, на сервере баз данных - RAID 10.

Один или несколько серверов

Как сказано выше, у небольших организаций довольно велико желание разместить все сервисы на одном сервере.

К преимуществам использования одного сервера и виртуализации можно считать более низкое энергопотребление и более гибкое распределение ресурсов между виртуальными машинами. Ну и перенос виртуальных машин, в случае чего, гораздо удобнее, чем перенос физических ОС.

Однако два сервера имеют более широкие возможности по апгрейду. Например, в нашем варианте недорогой IBM x3550 M3 с добавлением еще одного процессора и ОЗУ превращается в элегантные шорты терминальный сервер на 50 и даже более пользователей.

Еще одно «узкое место» в нашем случае, которое необходимо учитывать при выборе двух физических серверов, это обмен данными между ними по сети. У виртуальных серверов обмен данными идёт через виртуальный коммутатор. Здесь же, для увеличения пропускной способности сети, можно установить в каждый сервер по сетевой карте с двумя гигабитными интерфейсами, которые можно агрегировать между собой и напрямую соединить оба сервера агрегированными 2-х гигабитными линками. Или же использовать сетевые карты с SPF+ 10GBASE, но это дорогое удовольствие.

Запас по мощности

При расчетах и выборе сервера необходимо принимать во внимание пиковые нагрузки. Также обязательно нужно помнить, что база данных будет только «пухнуть», объёмы данных на терминальном сервере будут расти, а количество пользователей может увеличиться. Многие предприятия экономят на запасе мощности и через полгода-год сталкиваются с перебоями в работе и жалобами пользователей. Это тот случай, когда чрезмерная экономия приводит к новым затратам в будущем - скупой платит дважды. Выбранные нами варианты рассчитаны с запасом мощности и возможностью апгрейда. Учтено, что в DELL R710 можно будет добавить еще два жестких диска и ОЗУ, а также заменить процессоры на более производительные.

Так что, если вам потребуется расширение, или количество сервисов увеличится, то тут есть большие перспективы, а существующие серверы еще долгое время будут эффективно выполнять свои задачи. Возможно, через год нам неожиданно потребуется увеличить количество пользователей в два раза, до 60 человек? Пожалуйста.

Если вы использовали один сервер DELL R710, то можно докупить недорогой IBM x3550 M3, поднять на нём гипервизор, перенести туда виртуальную машину с БД и 1С-сервером, а на DELL-е все ресурсы отдать виртуальной машине с терминалом. Это будет быстро, и не потребуется «всё выкинуть и купить новое».
Если же вы использовали два сервера IBM, то x3550 M3 с добавлением второго процессора и небольшого количества ОЗУ превращается из середнячка в довольно мощную машину. А в x3250 M5 можно обновить процессор с E3-1220v3 до E3-1285v3.

Сервер 1С – это специальная программа, которая позволяет запустить 1С в компании в клиент серверном режиме. Что все это значит?

Вообще 1С может работать в двух режимах. Первый обычно называют файловый. Программа, которую запускает пользователь () на своем компьютере самостоятельно работает с базой данных.

Второй режим называют клиент серверный (или просто – серверный). Это значит, что на сервере (компьютере) запущена специальная программа – сервер 1С (программа, еще ее называют Сервер приложений 1С). Программа, которую запускает пользователь (клиент 1С) на своем компьютере, работает с программой сервер 1С, а уже та в свою очередь работает с базой данных. В качестве базы данных используется СУБД – MS SQL или подобная.

Сервер 1С обычно используют в следующих случаях:

  • База данных большая (4Gb+)
  • Количество пользователей большое (20-30+)
  • Используется тонкий или веб клиент 1С (вообще любая разновидность связки 1С и веб)
  • Хочется работать с 1С на Linux.

Сегодня мы обсудим как настроить сервер 1С.

Что такое сервер 1С

Для исключения путаницы разберемся что имеют ввиду, когда говорят «Сервер 1С»:

  • Это программа Сервер 1С (обычно запускаемая как сервис Windows)
  • Это сервер, на котором работает эта программа (т.е. компьютер)
  • Это сервер, на котором работает MS SQL, на котором расположена база данных, которой управляет программа Сервер 1С
  • Это сервер, на котором работает веб сервер Apache или MS IIS, через который работает веб-клиент 1С.

Если я добавлю еще, что сервер 1С может быть кластером (т.е. группой серверов, на которых работают подчиненные программы сервер 1С), то можно окончательно запутаться.

Реальная схема работы Сервера 1С

Сервер 1С (точнее сервер приложений 1С) – это программа 1С, установленная [чаще всего] как сервис Windows. Также ее можно установить как обычную программу и использовать автозагрузку для ее старта при загрузке Windows. Также сервер 1С можно установить под Unix/Linux, для этого есть отдельный дистрибутив (ссылку как установить под Linux смотри здесь).

Сервер 1С не является одной программой, а состоит из несколько процессов:

  • Агент сервера (ragent.exe) – собственно и является сервером 1С. Он ничего не делает кроме хранения и идентификации одного или группы кластеров 1С.
  • Кластер 1С (rmngr.exe) – группа рабочих процессов 1С, которые осуществляют собственно обработку данных. Сам по себе кластер ничего не обрабатывает, а осуществляет менеджмент рабочих процессов.
  • Рабочий процесс 1С (rphost.exe) – собственно «рабочая лошадка», которая обрабатывает сеанс работы пользователя.

Таким образом один сервер 1С может состоять из нескольких кластеров (которые могут быть расположены на разных компьютерах), а каждый кластер может состоять из нескольких процессов. Что это дает?

С помощью создания нескольких кластеров Вы балансируете общую стабильность системы. При падении одного из кластеров (или серверных компьютеров) – работу продолжит другой кластер.

С помощью создания нескольких процессов Вы балансируете нагрузку на процессор и количество доступной памяти.

Схема работы сервера 1С с другими составляющими 1С системы

В случае, когда используется толстый клиент 1С, то сервер 1С нужен чтобы передавать запросы на SQL сервер 1С. В случае, когда используется тонкий клиент 1С или веб клиент 1С, сервер 1С производит все вычисления. Соответственно нагрузка на компьютер сервер повышается.

СУБД (в разговоре многие называют SQL, хотя это неправильно) – это система управления базами данных. Устно часто называют как «эс-ку-эль» или «скуль» или «сиквел». В большинстве случаев с 1С используют MS SQL, так как это сложилось исторически. В версии 8.2 появилась поддержка Oracle и IBM DB2, а также для тех, кто хотел бы собрать полностью лицензионную и бесплатную систему на Linux – PostgreSQL, распространяемый бесплатно (лицензионный).

СУБД в малонагруженных системах обычно ставят на тот же компьютер сервер, что и сервер 1С. В этом случае необходимо проследить за настройками MS SQL, в том числе по использованию памяти.

В сильнонагруженных системах MS SQL и сервер 1С разносят на разные компьютеры (в сложных случаях даже сам сервер 1С разносят на несколько компьютеров). Они по разному используют ресурсы компьютера, обоим требуется процессор и винчестер. Со стороны сервера 1С нагрузка больше на процессор и память (на винчестере только хранятся временные файлы). Со стороны MS SQL при активной работе пользователей по вводу документов – это множество мелких чтений/мелких записей.

В веб варианте дополнительно используется веб сервер. Он требуется когда:

  • нужна работа 1С с веб (веб сервисы, веб расширение)
  • использование тонкого клиента 1С через интернет
  • использование веб клиента.

Веб сервер не выполняет никаких 1С действий и выполняет функцию прокладки между клиентом и сервером 1С. Т.е. все действия он передает (транслирует) для выполнения на сервер 1С. Работа веб сервера IIS с сервером 1С построена на базе ISAPI расширения, из дистрибутива 1С.

Управление сервером 1С

Управление сервером 1С производится с помощью специальной утилиты Администрирование серверов 1С. Утилита находится в меню 1С:Предприятие по кнопке Пуск.

Если у Вас на компьютере установлено несколько версий 1С, то консоль обычно запускается – последней версии (при установке регистрируется версия консоли). Обратите внимание, что версия консоли и версия программы сервер 1С должны совпадать.

Если Вам нужно запустить консоль предыдущей версии – в меню Пуск конкретной версии 1С можно выбрать команду Регистрировать утилиту администрирования. После чего попробуйте запустить консоль снова.

Окно консоли управления делится на две части – левую (со списком параметров) и правую (информационная панель). При первом запуске панель слева будет пустая.

Чтобы добавить сервер 1С, которым мы будем управлять, и который уже установлен и запущен – необходимо нажать правой кнопкой на строку Центральные серверы 1С и выбрать Новый сервер 1С. В качестве Имени нужно ввести IP адрес или имя компьютера, на котором установлен и запущен сервер 1С.

Чтобы войти в добавленный/выбранный сервер – раскройте ветку нажав на крестик слева от имени/IP адреса:

  • ветка Администраторы
    Здесь указываются (т.е. добавляются) администраторы сервера 1С. Администраторы сервера 1С имеют права на управление собственно сервером (не кластером!). Если ни один не добавлен – то управление сервером может выполнять каждый вошедший.
  • ветка Кластеры
    Здесь расположен список кластеров. Если он пуст – создайте первый кластер по умолчанию.
    Раскрыв ветку кластера Вы можете произвести управление кластером:
  • ветка Администраторы
    Здесь указывают (т.е. добавляются) адинистраторы кластера 1С. Администраторы кластера 1С имеют права на управление кластером, но не сервером 1С. Если ни один не добавлен – то управление кластером может выполнять любой вошедший. Чтобы управлять кластером не нужно быть администратором сервера.
  • ветка Рабочие серверы
    Здесь можно добавлять и удалять рабочие процессы. Как уже говорилось выше, это позволяет балансировать нагрузку на производительность сеансов пользователей, разводя их по разным процессам. В свойствах процесса есть:
    o Использовать/Не использовать/Резервный – активность процесса
    o Производительность – цифра до 1000, по умолчанию 1000; позволяет манипулировать текущим приоритетом процесса; новые сеансы коннектятся к тому процессу, у которого максимальная цифра производительности; однако раз в N минут система сама переставляет эту цифру по фактической загрузке процесса.
  • ветка Информационные базы
    Собственно здесь и расположены подключенные (расположенные на этом сервере 1С) базы данных. В свойствах базы данных есть:
    o Блокировка сеансов – запрет подключения к этой базе сейчас
    o Сообщение – выдается при попытке присоединиться, когда заблокировано
    o Код разрешения/Параметр – разрешает коннектится даже если поставлен запрет.
  • ветка Информационные базы/Имя базы/Сеансы
    Список подключенных к базе данных пользователей. Выделив сеанс курсором его можно удалить кнопкой Del. Можно выделить сразу всех. Аккуратно – не удалите себя!

Клиент-серверный вариант работы - один из вариантов работы системы 1С:Предприятие 8 .

Клиент-серверный вариант работы предназначен для использования в рабочих группах или в масштабе предприятия. Он реализован на основе трехуровневой архитектуры «клиент-сервер».

Клиент-серверная архитектура разделяет всю работающую систему на три различные части, определенным образом взаимодействующие между собой:

Программа, работающая у пользователя, (клиентское приложение) взаимодействует с кластером серверов 1С:Предприятия 8, а кластер, при необходимости, обращается к серверу баз данных.

При этом физически кластер серверов 1С:Предприятия 8 и сервер баз данных могут располагаться как на одном компьютере, так и на разных. Это позволяет администратору при необходимости распределять нагрузку между серверами.

Использование кластера серверов 1С:Предприятия 8 позволяет сосредоточить на нем выполнение наиболее объемных операций по обработке данных. Например, при выполнении даже весьма сложных запросов программа, работающая у пользователя, будет получать только необходимую ей выборку, а вся промежуточная обработка будет выполняться на сервере. Обычно увеличить мощность кластера серверов гораздо проще, чем обновить весь парк клиентских машин.

Другим важным аспектом использования 3-х уровневой архитектуры является удобство администрирования и упорядочивание доступа пользователей к информационной базе. В этом варианте пользователь не должен знать о физическом расположении конфигурации или базы данных. Весь доступ осуществляется через кластер серверов 1С:Предприятия 8. При обращении к той или иной информационной базе пользователь должен указать только имя кластера и имя информационной базы, а система запрашивает соответственно имя и пароль пользователя.

1С:Предприятие 8 использует возможности системы управления базами данных для эффективной выборки информации:

  • механизм запросов ориентирован на максимальное использование СУБД для выполнения расчетов и составления отчетов,
  • просмотр больших динамических списков обеспечивается без выполнения большого количества обращений к базе данных; при этом пользователю предоставляются возможности эффективного поиска, а также настройки отбора и сортировки.

Развертывание клиент-серверного варианта и его администрирование выполняется довольно просто. Например, создание базы данных производится непосредственно в процессе запуска конфигуратора (так же, как и для файлового варианта).

Клиентские приложения

Работа в клиент-серверном варианте возможна как напрямую с кластером, так и через веб-сервер. При этом в случае непосредственного подключения к кластеру толстый клиент и тонкий клиент используют протокол TCP/IP . При подключении через веб-сервер тонкий клиент и веб-клиент используют протокол HTTP или HTTPS .

Кластер серверов

Кластер серверов 1С:Предприятия 8 - основной компонент платформы, обеспечивающий взаимодействие между пользователями и системой управления базами данных в клиент-серверном варианте работы. Наличие кластера позволяет обеспечить бесперебойную, отказоустойчивую, конкурентную работу большого количества пользователей с крупными информационными базами.

Сервер баз данных

В качестве сервера баз данных могут использоваться:

Администрирование кластера серверов

В поставку платформы входит набор различных инструментов , позволяющих администратору управлять составом кластера, информационными базами и подключением пользователей.

Выполнение основной функциональности на сервере

Вся работа с прикладными объектами, чтение и запись базы данных выполняется только на сервере. Функциональность форм и командного интерфейса также реализована на сервере.

На сервере выполняется подготовка данных форм, расположение элементов, запись данных форм после изменения. На клиенте отображается уже подготовленная на сервере форма, выполняется ввод данных и вызовы сервера для записи введенных данных и других необходимых действий.

Аналогично командный интерфейс формируется на сервере и отображается на клиенте. Также и отчеты формируются полностью на сервере и отображаются на клиенте.

При этом механизмы платформы ориентированы на минимизацию объема данных, передаваемых на клиентский компьютер. Например, данные списков, табличных частей и отчетов передаются с сервера не сразу, а по мере просмотра их пользователем.

На сервере выполняются:

  • Запросы к базе данных,
  • Запись данных,
  • Проведение документов,
  • Различные расчеты,
  • Выполнение обработок,
  • Формирование отчетов,
  • Подготовка форм к отображению.

На клиенте выполняется:

  • Получение и открытие форм,
  • Отображение форм,
  • «Общение» с пользователем (предупреждения, вопросы…),
  • Небольшие расчеты в формах, требующие быстрой реакции (например, умножение цены на количество),
  • Работа с локальными файлами,
  • Работа с торговым оборудованием.

Использование встроенного языка на клиенте

Управлять функциональностью форм можно не только на сервере, но и на клиенте. На клиенте поддерживается работа встроенного языка. Он используется в тех случаях, когда необходимо провести расчеты, связанные с отображенной на экране формой, например, быстро (без обращения к серверу) подсчитать сумму строки документа на основе цены и количества; задать пользователю вопрос и обработать ответ; прочитать файл из файловой системы компьютера и отправить его на сервер.

Однако работа встроенного языка на клиенте поддерживается в строго ограниченном объеме. Клиентские процедуры в модулях в явном виде отделяются от серверных, и в них используется ограниченный состав объектной модели встроенного языка.

На клиенте не допускается непосредственная работа с базой данных. Не допускается работа непосредственно с прикладными объектами, например, недоступны такие типы встроенного языка, как СправочникОбъект.<имя> . Не допускается использование запросов. При необходимости вызова действий с данными в клиентском коде нужно вызывать серверные процедуры, которые уже будут обращаться к данным.