Требования 1С к серверу

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

Как настроить терминальный сервер для 1С

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

Использование терминального сервера для 1С

Если не использовать терминальные сервера, компьютеры пользователей самостоятельно выполняют расчеты, для которых передается информация из базы данных на клиенты. Этот процесс не зависит от типа БД. Такой вариант работы предполагает серьезные вложения, чтобы производительность на сервере и рабочих местах была достойного уровня.

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

С ростом популярности программ 1С и увеличением областей, в которые это ПО внедряется, все больше компаний используют терминальный сервер 1C. Экономия на технике – далеко не единственная причина, по которой многие организации склоняются в пользу варианта работы с 1С при помощи сервера.

Преимущества терминальных серверов

Помимо экономии за счет удешевления рабочих клиентов и сети эксплуатация терминальных серверов позволяет:

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

Кроме этого, возможности серверных ОС от Microsoft позволяют силами штатных администраторов настроить возможность подключения терминальных клиентов к серверу 1С, поэтому настройка сервера 1С — такой важный вопрос.

Установка терминального сервера для 1С

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

Но если вы решили действовать самостоятельно, рассмотрите пример установки терминального сервера для 1С в ОС Windows Server 2012:

  • Необходимо зайти на сервере в свойства соединения и прописать нужный IP-адрес;

Рис.1 Прописываем IP-адрес

  • Чтобы проверить, виден ли наш сервер, попробуйте на клиентском компьютере прописать команду ping в командной строке;
  • Если пинг прошел успешно, на сервере откройте «Диспетчер серверов» и щелкните «Добавить роли и компоненты»;

Рис.2 Добавляем роли и компоненты

  • Выберите тип установки сервера – «Установка ролей и компонентов»;
  • Выбираем наш сервер для 1С из пула серверов и нажимаем «Далее»;

Рис.3 Выбираем сервер

  • На этапе выбора ролей сервера нам нужно найти и поставить галку напротив роли «Службы удаленных рабочих столов»;

Рис.4 Служба удаленных рабочих столов

  • Нажимаете два раза «Далее» и на этапе выбора служб ролей на сервере необходимо проставить две галки:
    • Лицензирование удаленных рабочих столов. При установке нажмите на всплывающую кнопку «Добавить компоненты»;
    • Узел сеансов удаленных рабочих столов.

Рис.5 Узел сеансов удаленных рабочих столов

  • В следующем окне проставьте «Автоматический перезапуск сервера, если требуется» и запустите установку сервера терминалов;

Рис.6 Установка сервера терминалов

  • Через некоторое время терминальный сервер для 1С будет успешно установлен.

Настроим сервер для 1С

Теперь нам необходимо настроить доступ клиентских пользователей к серверу. Для этого:

  • Установите 1С на сервере;
  • Откройте «Администрирование». Зайдите в «Управление компьютером». Зайдите в раздел «Локальные пользователи» и выберите «Пользователи». Создайте нового пользователя на сервере;
  • В открывшемся окне заполните поля «Пользователь», «Полное имя», «Описание», «Пароль» и «Подтверждение пароля»;

Рис.7 Информация о пользователе

  • Нажимаем «Создать». Затем заходим в свойства созданного пользователя сервера. На вкладке «Членство в группах» добавьте «Пользователи удаленного рабочего стола»;

Рис.8 Пользователи удаленного рабочего стола

  • Затем на сервере зайдите в «Локальная политика безопасности». Нажмите слева «Назначение прав пользователя» и справа зайдите в свойства «Разрешить вход в систему через службу удаленных рабочих столов»;
  • Сервер по умолчанию дает доступ только администраторам. Добавьте пользователей, используя «Добавить пользователя или группу…»;

Рис.9 Добавление пользователя или группы

  • Когда все пользователи будут в списке на сервере, нажмите «Применить».

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

Подключение к терминальному серверу

Подключение к настроенному терминалу 1С происходит через протокол RDP. В системах семейства Microsoft есть встроенный инструмент, названный «Подключение к удаленному рабочему столу». Чтобы найти этот инструмент, зайдите в «Пуск» – «Все программы» – «Стандартные»:

Рис.10 Подключение к настроенному терминалу 1С происходит через протокол RDP

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

  • В поле «Компьютер» впишите адрес терминального сервера;
  • В поле «Пользователь» необходимо указать имя, под которым вы хотите зайти на данный сервер. Естественно, для этого пользователю должно быть разрешено удаленное управление;

Рис.11 Доступ на сервер

  • В следующем окне необходимо будет ввести пароль пользователя для доступа на сервер.

Рис.12 Логин/Пароль для доступа на сервер

Если настройки сделаны правильно и данные введены верно, то развернется окно, в котором вы увидите немного измененный рабочий стол.

Рис.13 Рабочий стол

Дальнейшая работа не отличается от ситуации, в которой 1С установлена на вашем компьютере.

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

Это все еще воздушный код, я еще не полностью проверил, но это должно привести вас в правильном направлении

Select ‘create index IX_’ + sys.objects.name + isnull(replace(‘_’ + equality_columns, ‘,’, ‘_’), ”) + isnull(replace(‘_’ + inequality_columns, ‘,’, ‘_’), ”) + ‘ on ‘ + sys.objects.name + ‘(‘ + coalesce(equality_columns + ‘,’ + inequality_columns, equality_columns , inequality_columns ) + ‘) ‘ + isnull(‘ include (‘ + included_columns + ‘)’, ”) as CreateIndexSql, (CONVERT(Numeric(19,6), sys.dm_db_missing_index_group_stats.user_seeks)+CONVERT(Numeric(19,6), sys.dm_db_missing_index_group_stats.unique_compiles))*CONVERT(Numeric(19,6), sys.dm_db_missing_index_group_stats.avg_total_user_cost)*CONVERT(Numeric(19,6), sys.dm_db_missing_index_group_stats.avg_user_impact/100.0) AS Score, sys.schemas.schema_id, sys.schemas.name AS schema_name, sys.objects.object_id, sys.objects.name AS object_name, sys.objects.type, partitions.Rows, partitions.SizeMB, sys.dm_db_missing_index_details.equality_columns, sys.dm_db_missing_index_details.inequality_columns, sys.dm_db_missing_index_details.included_columns, sys.dm_db_missing_index_group_stats.unique_compiles, sys.dm_db_missing_index_group_stats.user_seeks, sys.dm_db_missing_index_group_stats.user_scans, sys.dm_db_missing_index_group_stats.avg_total_user_cost, sys.dm_db_missing_index_group_stats.avg_user_impact, sys.dm_db_missing_index_group_stats.last_user_seek, sys.dm_db_missing_index_group_stats.last_user_scan, sys.dm_db_missing_index_group_stats.system_seeks, sys.dm_db_missing_index_group_stats.system_scans, sys.dm_db_missing_index_group_stats.avg_total_system_cost, sys.dm_db_missing_index_group_stats.avg_system_impact, sys.dm_db_missing_index_group_stats.last_system_seek, sys.dm_db_missing_index_group_stats.last_system_scan FROM sys.objects JOIN ( SELECT object_id, SUM(CASE WHEN index_id BETWEEN 0 AND 1 THEN row_count ELSE 0 END) AS Rows, CONVERT(numeric(19,3), CONVERT(numeric(19,3), SUM(in_row_reserved_page_count+lob_reserved_page_count+row_overflow_reserved_page_count))/CONVERT(numeric(19,3), 128)) AS SizeMB FROM sys.dm_db_partition_stats WHERE sys.dm_db_partition_stats.index_id BETWEEN 0 AND 1 –0=Heap; 1=Clustered; only 1 per table GROUP BY object_id ) AS partitions ON sys.objects.object_id=partitions.object_id JOIN sys.schemas ON sys.objects.schema_id=sys.schemas.schema_id JOIN sys.dm_db_missing_index_details ON sys.objects.object_id=sys.dm_db_missing_index_details.object_id JOIN sys.dm_db_missing_index_groups ON sys.dm_db_missing_index_details.index_handle=sys.dm_db_missing_index_groups.index_handle JOIN sys.dm_db_missing_index_group_stats ON sys.dm_db_missing_index_groups.index_group_handle=sys.dm_db_missing_index_group_stats.group_handle WHERE sys.dm_db_missing_index_details.database_id=DB_ID() AND (CONVERT(Numeric(19,6), sys.dm_db_missing_index_group_stats.user_seeks)+CONVERT(Numeric(19,6), sys.dm_db_missing_index_group_stats.unique_compiles))*CONVERT(Numeric(19,6), sys.dm_db_missing_index_group_stats.avg_total_user_cost)*CONVERT(Numeric(19,6), sys.dm_db_missing_index_group_stats.avg_user_impact/100.0) > 100

На сегодняшний день финансовый продукт 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 — Соотношение количества пользователей на сервере 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С.

Кеш, виртуализация и гиперпоточность (hyper threading).

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

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

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

Тип процессора.

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

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

Пользовательский 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$

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

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

Тип оперативной памяти.

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

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

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

Объем оперативной памяти.

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

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

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

Касательно процессов сервера 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).

Таблица 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

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

(см. RAID-калькулятор)

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

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

Таблица 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. С экономической целесообразностью выбора аренды сервера можно ознакомиться в статье.

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

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

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

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

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

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

Однако, каждая технология имеет как плюсы, так и минусы. Помимо ключевых преимуществ, требуется знать некоторые особенности кластеризации 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.

Выводы и рекомендации по созданию архитектуры для сервера 1С

  • Не нужно использовать дешевое пользовательское аппаратное обеспечение для столь важного сервиса как учетная система всего предприятия. Цена в данном случае напрямую предопределяет качество, стабильность и долговечность такой платформы.
  • Рекомендуем при выборе серверной платформы обращать внимание на наличие двух блоков питания, удаленную карту IPMI и бренд производителя. Конечно же, каждый подбирает решение, исходя из своего бюджета, топовые бренды иногда слишком дороги и не совсем уместны, однако не стоит уж совсем экономить на производителе, это может привести к неконтролируемым форс-мажорам в работе с 1С. Лично мы используем серверные платформы Supermicro в сочетании с серверными ЦПУ Intel.
  • Есть мнение, подтвержденное практикой, что производительность 1С больше зависит от более высокой частоты работы ЦПУ, чем от количества предоставленных ядер.
  • Не нужно экономить на объеме оперативной памяти, выделяемой для сервера 1С и службы SQL. ОЗУ на данный момент является достаточно дешевым ресурсом, а ее нехватка (даже на 10-15 процентов) приведет к сильному падению производительности системы 1С, т.к. включится более медленная система подкачки (swap). Плюс ко всему swap даст дополнительную нагрузку на дисковую подсистему что еще сильнее ухудшит ситуацию.
  • Компания EFSOL предлагает комплексные услуги по подбору сервера 1С , в которые входит:
    • проектирование сервера 1С,
    • закупка,
    • настройка,
    • обслуживание
  • Альтернативным собственному созданию сервера 1С вариантом является аренда сервера для 1С. Облачные технологии позволяют при небольших ежемесячных затратах пролучить надежный отказоустойчивый сервис для комфортной работы в 1С.

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

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

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

Главное, о чем стоит помнить: чтобы сервер работал в комфортном режиме, требуется обеспечить высокую производительность дисковой системы. Самым быстрым типом дисковых массивов является RAID 10, однако он крайне нерационально расходует место на дисках. Чтобы хранение данных было более эффективным, лучше использовать RAID5. Также следует помнить, что разные дисковые подсистемы чувствительны к разным нагрузкам и при необходимости, в зависимости от числа пользователей, их следует изменять. Важным подспорьем здесь может являться показатель IOPS (Output Operations Per Second) – число операций ввода-вывода в секунду. По сути, речь идет о количестве блоков информации, которое считывается или записывается на носитель за одну секунду. В чистом виде именно его принято считать ключевым параметром скорости обработки информации жестким диском, который влияет на производительность 1С-сервера.

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

Подбирая конфигурацию терминального сервера 1С важно понимать, что все клиентские приложения будут выполняться непосредственно на сервере. Соответственно выбор оперативной памяти должен отталкиваться от числа пользователей. Влияние типа оперативной памяти, а также ее тайминга и частоты на работу 1С-приложений невелико; ключевым параметром здесь выступает объем. Не следует экономить на объеме оперативной памяти, выделяемой для сервера 1С и службы SQL. ОЗУ на данный момент является относительно недорогим ресурсом, а ее нехватка (даже на 10-15 процентов) может привести к сильному падению производительности системы 1С из-за включения более медленной системы подкачки (swap), увеличивающей также нагрузку на дисковую подсистему.

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

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

Серверные платформы

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

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

Вопрос производительности 1С в файловом режиме стоит довольно остро, особенно перед небольшими фирмами, которые не могут позволить себе существенных вложений в оборудование. Тем не менее «аппетиты» приложения от релиза к релизу только растут и задача повышения быстродействия при умеренных затратах бюджета становится все актуальнее. В этом случае неплохим решением будет приобретение и размещение баз на SSD.

Один из наших клиентов, небольшая фирма по бухгалтерскому обслуживанию, начал жаловаться на медленную работу 1С:Предприятие. Собственно и так не очень быстрая работа приложения стала совсем тоскливой после перехода с Бухгалтерии 2.0 на Бухгалтерию 3.0.

В наличие имелся простой терминальный сервер на Core i3 2120, 8 Гб RAM, с дисковым массивом RAID 1 из двух Western Digital RE4, который обслуживал от трех до шести пользователей, каждый из которых работал с двумя — тремя базами одновременно.

Анализ производительности сразу выявил узкое место — дисковая подсистема (скриншот сделан уже после установки SSD, поэтому к RAID массиву относятся логические диски C: и E:).

Несложные расчеты показали, что запуск даже одной информационной базы практически полностью использует производительность массива, около 150 IOPS при текущем соотношении чтение/запись — фактический предел для зеркала из двух не самых быстрых дисков. На что косвенно указывает и размер очереди.

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

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

Стало ясно — требуется модернизация дисковой подсистемы. Даже по предварительным прикидкам, создание производительного массива на основе массовых HDD упиралось как в доступный бюджет, так и в физические возможности железа, которое просто не имело необходимого количества SATA-портов и дисковых корзин в корпусе. Поэтому было принято решение о приобретении SSD.

Так как высоких дисковых нагрузок не предусматривалось, то выбор производился в первую очередь из соображений цены. Скоростные характеристики также отходили на второй план, так как узким местом становился интерфейс SATA-II. В итоге был приобретен 128Gb Corsair Neutron LAMD, который будучи установленным в сервер показал следующие скоростные характеристики:

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

Следующий вопрос, который нужно решить: это создать ли «зеркало» из SSD и пожертвовать TRIM ради отказоустойчивости или оставить одиночный диск, выбрав скорость вместо отказоустойчивости. Следует отметить, что современные SSD кроме команды TRIM используют собственные технологии борьбы с деградацией, такие как сбор мусора, что позволяет довольно эффективно работать даже на системах без TRIM. Используемый в данной серии SSD контроллер LAMD (Link_A_Media Devices) как раз таки отличается весьма эффективными технологиями сбора мусора, на уровне накопителей корпоративного уровня, что в общем неудивительно, так как его разработчики давно работают в enterprise-сегменте.

Так как объем ежедневно вводимых документов невелик, то мы ограничились единственным SSD при обязательных ежедневных бекапах. Косвенно эффект от применения твердотельного диска можно оценить по монитору производительности:

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

Для этого мы провели небольшое экспресс-тестирование в ходе которого измеряли время загрузки информационной базы и время группового перепроведения комплекта документов за определенный период времени. В ходе тестирования применялась конфигурация 1С:Бухгалтерия 3.0.27.7 на платформе 8.3.3.721.

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

Как видим, перенос информационных баз на SSD сразу уменьшил время их загрузки более чем вдвое, а перепроведение ускорилось приблизительно на 30%. При этом полностью сняласть проблема с падением производительности при совместной работе.

Перенос на SSD временных папок позволяет сократить время загрузки более чем втрое и приблизительно в два раза ускорить проведение документов. Здесь есть над чем подумать даже убежденным приверженцам экономии ресурсов диска. Наше мнение по данному вопросу следующее, если вы купили SSD — то следует использовать его по полной программе.

Сделаем небольшое отступление. Используемый нами диск Corsair Neutron имеет ресурс 2-3K циклов стирания/записи. Несложные расчеты показывают, что если ежедневно полностью перезаписывать всю емкость диска, то для исчерпания ресурса потребуется 5-8 лет. Кроме того статистика показвает, что основная причина выхода из строя SSD в течении гарантийного срока не связана с исчерпанием ресурса, а представляет собой производственный брак или ошибки в прошивке.

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