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

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

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

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

Выбор сервера для 1С

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

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

В аппаратной структуре 1С сервера для нас будут важны характеристики процессора, оперативной памяти, дисковой подсистемы и сетевые интерфейсы.

Необходимо, чтобы они обеспечивали стабильную и достаточно производительную работу следующих компонентов:

• операционная система;
• сервер баз данных (чаще всего это );
• серверная часть 1С (не для всех случаев, так как маленькая компания на 2-10 пользователей может работать с 1С в файловом режиме);
• работа пользователей в режиме Remote Desktop;
• работа удаленных пользователей через тонкий клиент или веб-клиент.

Выбор процессора для сервера 1С

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

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

Сколько памяти нужно серверу 1С

В дополнение к сказанному, если вам нужен сервер под 1С на 100 и более пользователей, мы рекомендуем разворачивать кластер из как минимум двух физических серверов 1С.

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

• 2 Гб потребуется под работу операционной системы
• минимум 2 Гб под работу кэша MS SQL Server, а лучше чтобы эта величина составляла 20-30% реального объема базы данных – это обеспечит комфортную работу пользователей с ней
• 1 – 4 Гб для сервера приложений 1С
• 100 – 250 Мб потребует одна пользовательская терминальная сессия, в зависимости от набора функций сервера 1С, используемой конфигурации

Приведем свои ориентировочные расчеты параметров сервера 1С 8.3:

Оперативную память лучше приобретать с запасом – это один из важнейших факторов высокой производительности 1С-сервера и в то же время это сейчас один из самых дешевых компонентов. Если недостаточно памяти на сервере 1С Предприятия, это будет очень ощутимо при работе, поэтому, когда стоит вопрос, какой сервер 1С выбрать, всегда обращайте внимание на то, чтобы у него был достаточный объем RAM.

Сервер 1С: оборудование для дисковой подсистемы

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

При проектировании сервера 1С, требования к оборудованию дисковой подсистемы мы советуем соблюдать такие:

• Неважно, какой сервер для 1С вы создаете, мы ни в каком случае не советуем использовать одиночные диски в серверах – желательно организовывать их в RAID-массивы (RAID 10 для больших или RAID 1 для небольших баз данных), где будут находиться таблицы БД.
• Файлы индексов рекомендуем выносить на отдельный SSD для более быстрого доступа к ним
• TempDB - на 1-2 (RAID 1) SSD.
• ОС и данные пользователей помещайте на RAID 1 из SSD/HDD.
• Под log-файлы отведите отдельный логический диск из массива или физический диск SSD.
• По возможности используйте аппаратный контроллер – нам приходилось видеть ситуации, когда мощный и дорогой сервер тормозил из-за недостаточной производительности контроллера.

Подбор сервера для 1С

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

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

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

Для начала предлагаю выделить несколько сценариев работы:

1.) Работа с файловой базой через общий ресурс (веб-сервер)

2.) Работа с файловой базой в терминале

3.) Работа с серверной (MSSQL) базой

Работа с файловой базой через общий ресурс (веб-сервер)

Здесь всё довольно таки просто. Если это обычные формы и 1-3 пользователя. То на "сервер" (машина, на которой будет лежать база выбираем:

• быстые винты - обращаем внимание на скорость вращения шпинделя (берем 7200rpm). Например, не берем у WD серию green, берем black или red. У Seagate можно посмотреть серию Constellation.
• Процессор - не столь важны ядра, как их частота. 1С довольно таки плохо использует многоядерность(вообще никак), поэтому выгоды от 8ми ядерного процессора вы не получите, 2ух-ядерный процессор с бОльшей частотой уделает его. Например, core i3 4360 - на текущий момент это максимальная частота у intel (4ghz в turbo режиме).
• Оперативная память - роли она тут не сыграет. Учитывая как современные приложения пожирают память, поставьте 8гб
• сеть - ну собственно, от 1гбит сети особо вы не выиграете, но тем не менее, если растянута 8ми жильная витая пара (можете посмотреть в коннекторах), то имеет смысл поставить гигабитный коммутатор, заодно будет быстрее файлообмен.
  И последний штрих в этом сценарии - не нужно размещать базу где-то на отдельной машине - длительные операции будут выполняться намного быстрее локально, чем по сети. Поставьте эту машину на рабочее место, откуда планируется, например,закрывать месяц или производить обновления ИБ.

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

• SSD накопитель* вместо обычного винта нас спасёт. Возьмите накопитель на 120гб, благо даже с учетом роста курса стоят они приемлемо. Рекомендую обратить внимание на intel 520/530 series, kingston v300. А лучше просто почитайте обзоры на свежие модели, т.к. этот рынок довольно быстро развивается и на рынок выходят новинки
  *Примечание: Если будете объединять диски в RAID с зеркалированием, например,RAID1. В этом случае есть такой момент: большинству SSD дискам требуется trim для очистки мусора(в основном, касается довольно старых моделей), в режиме raid команда может не поддерживаться и накопитель по мере работы будет деградировать в скорости. Чтобы избежать этой проблемы можно воспользоваться минимум двумя способами: в идеале, приобрести SSD enterprise уровня, например, intel DC3500. Если это покажется дорого можно использовать связку: мат.плата с чипсетом
• Процессор - аналогично с предыдущим пунктом. Чем больше частота тем лучше.
• Оперативная память - большойроли она тут не сыграет. Учитывая как современные приложения пожирают память, поставьте 8гб

Если с базой будет работать локально 1 пользователь то этого достаточно для его комфортной работы, но скорость сетевой работы через общий ресурс будет всё так же медленной. Но и здесь есть выход - работа через web сервер. На просторах интернета вы сможете найти большое количество статей, где описывается как организовать работу с 1С подобным образом, не буду останавливаться в данной статье на этом. Единственное, поделюсь с Вами своими наблюдениями: предпочтительнее настроить работу у пользователей не через web-браузер, а через тонкий клиент (когда добавляем в список ИБ новую базу, на странице размещения ИБ есть пункт "на web сервере"). Это, по моим наблюдениям, быстрее чем через браузер. Кроме того при работе через браузер встречаются ошибки в интерфейсе (съехавшая ТЧ и т.п.), которых нет при работе через тонкий клиент.

Собственно, воспользовавшись данным рецептом (ssd,процессор с большой частотой,web-сервер,тонкий клиент). Можно развеять миф "если число пользователей больше 1 (по некоторой версии больше 0:)) - нужна серверная база*.

*Хотя, конечно, с оговоркой что это не УПП или база размером > ~4гб, а количество пользователей не превышает 4 (это максимальные размер базы и количество пользователей, которые видел я, возможно кто-то встречал случаи, когда через web-сервер с файловой базой работало больше человек? Напишите в комментариях)

Работа с файловой базой в терминале

Перейдем к следующему варианту. У нас есть терминальный сервер и есть файловая база. Здесь всё аналогично сценарию 1 за исключением процессора:

• SSD накопитель вместо обычного винта.*
  *Примечание: обязательно соберите в диски в RAID с зеркалированием, например,RAID1. В этом случае есть такой момент: большинству SSD дискам требуется trim для очистки мусора(в основном, касается довольно старых моделей), в режиме raid команда может не поддерживаться и накопитель по мере работы будет деградировать в скорости. Чтобы избежать этой проблемы можно воспользоваться минимум двумя способами: в идеале, приобрести SSD enterprise уровня, например, intel DC3500. Если это покажется дорого можно использовать SSD пользовательского класса, но тогда убедитесь, что его ресурс перезаписи достаточен для вашего сценария работы.
• Процессор - Здесь имеет смысл взять corei5 вместо i3, т.к. 1С будет работать на терминале, дополнительные 2ядра не помешают, но не забываем и про частоту.
• Оперативная память есть такое устойчивое выражение у админов: памяти много не бывает). Из моей практики 7 человек при работе в БП3 занимают 8-12гб на терминале (зависит сколько документов открыто у каждого пользователя). Для обычных форм количество памяти можно поделить на 2:).Примерный расчет можно сделать так: 256мб для самой терминальной сессии + 1,5гб для 1С

Работа с серверной (MSSQL) базой

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

• Размещение SQL сервера и сервера 1С. На разных машинах или на одной. Есть такой момент: если они находятся на одной машине, то общение между ними происходит через протокол shared memory, и в этом случае мы получаем бонус в быстродействии, которого нет, когда они находятся на разных машинах.
• Процессор. А вот здесь уже пригодится и высокая тактовая частота и многоядерность. Т.к. у нас есть процесс SQL сервра, если он на этой же машине, и несколько процессов сервера 1С rphost которые будут загружать ядра процессора.Отдельно хочу выделить двухпроцессорные системы (т.е. когда на мат.плате два сокета для и более сокета). Даже если берете с одним пустым сокетом "про запас, докупить процессор потом, если вдруг понадобится". Я видел большое количество двухсокетных серверов, которые до глубокого end of life так и простояли с пустым вторым сокетом. Хотя, если фирма платит...зачем отказывать себе в удовольствии:)
• Оперативная память . В своей работе SQL сервер* активно использует оперативную память, если её недостаточно, он будет лезть на диски, которые даже в случае ssd медленее оперативной памяти. Поэтому тут на памяти экономить не стоит. Заложите в бюджет максимально возможное количество (не забываем, конечно о здравом смысле:)), и оставьте свободные слоты на материнской плате, чтобы иметь возможность всегда доставить дополнительную планку.
  *Примечание: не забудьте ограничить максимально используемую SQL сервером ОЗУ, чтобы её хватило для ОС и терминальных сессий, а также увеличьте шаги увеличения tmp и базы SQL (по-умолчанию шаг 1мб, что очень мало, установите 200 МБ на базу и 50 МБ на лог)
• Дисковая подсистема. Может появится мысль, что если объем ОЗУ будет больше размера базы, то она вся будет лежать в памяти и всё будет летать. Оно может так и было бы...до первой операции записи:) которая будет писать на диски. И вот тут то жесткие диски обломают вас:) Используйте SSD диски. И вот тут уже не экономьте не десктопных SSD, приобретите нормальные SSD enterprise уровня. Intel DC3700 -200гб,ресурс 3.7 петабайта (по 10 перезаписей всего объема накопителя в день в течение 5 лет), можно найти за 24000р/шт+второй для RAID1=48000. На лицензии уйдет во много больше.

Вроде всё. Если вопросы/жалобы/предложения - wellcome в комментарии;)

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

Для определенности, рассмотрим платформу «1С:Предприятие 8.2» в ее популярных базовых конфигурациях «Бухгалтерский учет», «Торговля и склад», «Зарплата и Управление Персоналом», «Управление Торговым Предприятием» и, отчасти, «Управление Производственным Предприятием». Исходим из того, что для предприятий с 10 и более сотрудниками, работающими в 1С, используется «1С:Предприятие 8.2. Сервер приложений». Учтем вариант работы в режиме удаленного рабочего стола (Remote Desktop), с количеством одновременных пользователей базы данных до 100-150. Рекомендации будут применимы и для более «тяжелых» БД 1С, но «тяжелые случаи» всегда требуют индивидуального подхода.

Процессоры и оперативная память

Если компания совсем маленькая (2-7 пользователей в системе), база невелика (до 1GB), а «1С:Предприятие 8.2» работает в файловом режиме на пользовательском компьютере, то мы получаем классическую реализацию файл-сервера. С такой задачей по нагрузке на CPU справится даже Intel Core i3, тем более Intel Xeon E3-12xx. Объем необходимой оперативной памяти (RAM) считается совсем просто: 2GB под операционную систему и 2GB под системный файловый кеш.

Если в компании 5-25 пользователей 1С, размер базы данных до 4GB, то приложению «1С:Предприятие 8.2» должно хватить 4-х ядерного Intel Xeon E3-12xx либо AMD Opteron 4ххх. Кроме 2GB оперативной памяти под ОС, необходимо выделить 1-4GB под «1С:Предприятие 8.2. Сервер приложений» и еще столько же под MS SQL Server в качестве кеша - итого 8-12GB RAM. Для небольших БД желательно кешировать в оперативной памяти не менее 30% БД, а лучше все 100%.

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

В компаниях побольше пользователи 1С обычно работают через удаленный доступ к приложению (Remote Desktop) - то есть в терминальном режиме. Как правило, при10-100 пользователях 1С с базой данных от 1GB и выше, «1С:Предприятие 8.2. Сервер приложений» и пользовательское приложение «1С:Предприятие 8.2» запускается на одном и том же сервере.

Для определения необходимых процессорных ресурсов исходят из того, что одно физическое ядро может эффективно обрабатывать не более 8 пользовательских потоков - это связано с внутренней архитектурой процессоров. Как показывает практика, под задачи 1С + Remote Desktop не стоит брать серверные процессоры младших линеек с низкими частотами расчетных ядер и урезанной архитектурой. Если пользователей немного (до 15-20), хватит одного процессора из высокочастотных Intel Xeon E3-12xx. При этом минимум одно его физическое ядро (2 потока) уйдет под нужды SQL Server, еще одно (2 потока) - под «1С:Предприятие 8.2. Сервер приложений», а оставшиеся 2 физических ядра (4 потока) - под ОС и терминальных пользователей. При количестве пользователей 1С более 20 или при объемах БД более 4GB пора переходить к 2-х процессорным системам на Intel Xeon E5-26xx или AMD Opteron 62xx.

Расчет нужного объема оперативной памяти относительно прост: 2GB надо отдать ОС, 2GB и больше - MS SQL Server в качестве кеша (не менее 30% БД) , 1-4GB - под «1С:Предприятие 8.2. Сервер приложений», остальной памяти сервера должно хватать под терминальные сессии. Один терминальный пользователь, в зависимости от конфигурации, потребляет в приложениях «Бухгалтерский учет», «Торговля и склад» - 100-120MB, «Зарплата и Управление Персоналом», «Управление Торговым Предприятием» - 120-160MB, «Управление Производственным Предприятием» - 180-240MB. Если пользователь запускает дополнительно на сервере MS Word, MS Excel, MS Outlook, то на каждое приложение надо выделить еще порядка 100MB. Как правило, минимум для сервера терминалов - 12GB RAM.

К примеру, для сервера 1С со всем пакетом ПО, 50 терминальными пользователями в конфигурации «Управление Торговым Предприятием», и базой данных в 8GB оптимальной будет вычислительная мощность двух процессоров Intel Xeon E5-2650 (8 ядер, 16 потоков, 2.0 GHz). Оперативной памяти понадобится минимум 2 (ОС) + 4(SQL) + 4(1C-сервер) + 8 (160 «УТП» * 50 пользователей) = 18GB, а лучше 24-32GB(6-8 каналов DIMM по 4GB).

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

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

У 1С есть 5 потоков данных для дисковой подсистемы, с которыми она работает:

• таблицы баз данных;
• индексные файлы;
• временные файлы tempDB;
• log-файл SQL;
• log-файл пользовательских приложений 1С.

Структура данных в 1С - объектно-ориентированная, со множеством объектов и связей между ними. Для работы с таблицами данных чрезвычайно важно количество операций чтения и записи, которые способна проделать дисковая подсистема за промежуток времени (Input Output Operation per Second, IOPS). При этом ее способность выдать высокую потоковую скорость передачи данных (в MBp/s) куда менее важна. Очень скромная база объемом 200-300MB с 3-5 пользователями может генерировать в пиках до 400-600 IOPS. База на 10-15 пользователей и объёмом в 400-800MB способна выдать 1500-2500 IOPS, 40-50 пользователей БД 2-4GB порождают5000-7500 IOPS, а базы под 80-100 пользователей легко достигают 12000-18000 IOPS.

Разумеется, средняя нагрузка на дисковую подсистему может составлять и 10-15%от пиковой. Только в реальности важна именно производительность в период пиковых нагрузок: автоматических загрузок данных из других систем, обмена данных распределённой системы или перепроведения периода.

Современные диски в операциях чтения и записи со случайным доступом (Random Read/Write) в одиночку справляются с такими нагрузками:

					Intel 910 400 GB
				2400 – 8600 IOPS

Хорошо видно, что:

• узким местом и для HDD, и для SSD является запись;
• традиционные HDD - не конкуренты SSD по скорости чтения в IOPS даже теоретически, разница превышает два порядка;
• даже не самый современный десктопный SSD в 3-40 раз (в зависимости от конфигурирования) превосходит по скорости записи в IOPS любой HDD, серверный SSD - в 12-40 раз быстрее HDD;
• максимальную производительность в IOPS дают PCIe SSD класса Intel 910 или LSI WarpDrive.

Одиночные диски в серверах БД не используются, только RAID-массивы. Для дальнейшего расчета реальной производительности дисковой подсистемы нужно учесть затраты («штраф») на запись в IOPS, которые несет дисковая группа в RAID:

Если собрать 6 дисков в RAID 10, то на каждую запись в 1 IOPS данных будет потрачено 2 IOPS физических дисков, а если в RAID 6 - то 6 IOPS дисков. Таким образом, при расчете нагрузочных возможностей дисковой группы на запись нужно вначале сложить IOPS всех дисков RAID-группы, а затем разделить их на «штраф».

Пример 1: 2 HDD SATA 7200 в RAID 1 обеспечат на запись: (100 IOPS *2) / 2 = 100 IOPS.

Пример 2: 4 SATA 7200 в RAID 5 обеспечат на запись: (100 IOPS *4) / 4 = 100 IOPS.

Пример 3: 4 SATA 7200 в RAID 10 обеспечат на запись: (100 IOPS *4) / 2 = 200 IOPS.

Примеры 2 и 3 наглядно демонстрируют, почему для хранения баз данных, у которых типовое распределение чтение/запись составляет 68/32, предпочтителен RAID 10.

Из данных трех таблиц понятно, по какой причине производительности типового «джентльменского набора» 2 HDD SATA 7200 в RAID 1 серверу недостаточно: при пиковых нагрузках растет очередь обращений к диску, пользователи ожидают ответа системы, иногда по многу часов.

Как увеличить производительность дисковой подсистемы на запись? Наращивают количество дисков в RAID-группе, переходят к дискам с большей скоростью вращения, выбирают уровень RAID c меньшим штрафом на запись. Хорошо помогает кеширование RAID-контроллером с включенным режимом отложенной записи Write back. Данные пишутся не напрямую на диски (как в режиме Write Through), а в кеш контроллера, и только затем, в пакетном режиме и упорядоченном виде - на диски. В зависимости от специфики задачи, производительность записи удается поднять на 30-100%.

Под слабо нагруженные или относительно небольшие БД (до 20GB) подойдет недорогой способ «добычи IOPS» - гибридный RAID из SSD/HDD . Большего и не нужно филиальной БД на 3-15 пользователей в распределённой структуре вроде сети кафе или СТО.

Для объемных (200GB и более) БД с длинным историческим шлейфом данных, либо для обслуживания нескольких объемных БД эффективным может оказаться SSD-кеширование (технологии LSI CacheCade 2.0 или Adaptec MaxCache 3.0). По опыту эксплуатации таких систем, именно в задачах 1С с их помощью можно относительно недорого и без существенных изменений в инфраструктуре хранения ускорить дисковые операции на 20-50%.

Чемпионом по быстродействию в IOPS предсказуемо являются RAID-массивы на серверных SSD - как традиционные, с использованием SAS RAID-контроллера, так и PCIe SSD. Мешают их популярности два ограничителя: технологический (производительность RAID- контроллеров или необходимость радикально ломать структуру хранения) и цена реализации.

Отдельно следует сказать о хранении индексных файлов и TempDB. Индексные файлы обновляются очень редко (обычно 1 раз в сутки), зато читаются очень и очень часто (IOPS). Таким данным просто необходимо храниться на SSD, c их показателями по чтению! TempDB, используемые для хранения временных данных, как правило, невелики по объему (1-4-12GB), зато очень требовательны к скорости записи. Индексные и временные файлы объединяет то, что их потеря не приводит к потере реальных данных. А значит, они могут размещаться на отдельном (еще лучше - на двух отдельных томах) SSD. Хотя бы и на бортовом контроллере SATA материнской платы. С точки зрения надежности и быстродействия, под TempDB желательно отдать зеркало (RAID1) из SSD, можно на бортовом контроллере, но с обязательным выключением всех кешей на запись. С этой ролью справятся и десктопные SSD - вроде Intel 520-серии, где аппаратная компрессия данных при записи в TempDB будет как раз уместной. Вынос этих задач с общей системы хранения на выделенную скоростную подсистему положительно сказывается на производительности системы в целом, особенно в моменты пиковых нагрузок.

В случаях, когда есть возможность обеспечить максимально быструю реакцию администраторов при сбоях, и когда имеются сложные расчетные задачи (складская или транспортная логистика, производство в УПП, объемные обмены в УРБД), TempDB выносят на RAMDrive. Такое решение позволяет выиграть иногда до 4-12% общей производительности системы. Некоторое неудобство возникает только в случае рестарта сервера: если автоматически RAMDrive не запустится, потребуется вмешательство администратора для ручного старта - иначе станет вся система.

Еще один важный компонент - log-файлы. Они имеют неприятную для любой дисковой подсистемы особенность - генерировать почти постоянный поток мелких обращений на запись. Это незаметно при средних нагрузках, но сильно ухудшает быстродействие сервера 1С при пиковых нагрузках. Разумно выносить log-файл (в особенности, log-файл SQL) на отдельный физический том, к которому нет высоких требований по IOPS, и на который будет идти практически линейная запись. Для спокойствия можно создать зеркало из недорогих и объемных SATA/NL SAS (для Full log), либо недорогих десктопных SSD все той же Intel 520-й серии (Simple log, или Full log, с ежедневным его Backup и очисткой).

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

Дисковая подсистема «идеального сервера под 1С» выглядит так:

1. Таблицы базы данных размещены на RAID 10 (или RAID 1 для малых БД) из надежных серверных SSD с обязательным аппаратным RAID-контроллером. При высоких требованиях по IOPS можно рассмотреть вариант PCIe SSD. Для БД большого объема эффективно SSD-кеширование массивов HDD. Если используемая конфигурация 1С и структура данных не слишком требовательны к IOPS, а количество пользователей невелико - хватит традиционного массива из HDD SAS 15K rpm.

2. Индексные файлы вынесены на быстрый и недорогой одиночный SSD, TempDB - на 1-2 (RAID 1) SSD или RAMDrive.

3. Под log-файлы SQL (а желательно и 1С) отведен выделенный том (одиночный физический диск или RAID-1) на SATA/NL SAS HDD или недорогих SSD, либо логический диск на RAID-массиве, на котором расположена операционная система сервера и пользовательские файлы/папки.

4. Операционная система и пользовательские данные хранятся на RAID 1 из HDD или SSD.

Если IT-инфраструктура виртуализирована, крайне желательно, чтобы SQL Server был установлен не как виртуальная машина, а непосредственно на физический сервер, на «голое железо». Цена вопроса - от 15 до 35% производительности дисковой подсистемы (в зависимости от оборудования, драйверов, средств виртуализации и способов подключения тома). В виртуализированной среде SQL-сервера подключение томов с таблицами БД, индексными файлами и TempDB к VM обязательно в монопольном режиме по Direct Access.

Сетевые интерфейсы

При построении систем 1С:Предприятие 8 для малых и средних предприятий (до 100-150 активных пользователей одновременно) следует минимизировать потери на сетевых операциях через интерфейс Ethernet. В идеале - обслуживать и SQL Server, и «1С:Предприятие 8 Сервер приложений х64», и пользовательские сессии 1С в Remote Desktop одним физическим сервером. Спорная с точки зрения обеспечения отказоустойчивости, такая рекомендация позволяет выжать максимум из оборудования и ПО, а за счет применения виртуализации дает определенный уровень безопасности и «повторяемость среды» на другом оборудовании.

Зачем исключать Ethernet из цепочки SQL-сервер -> Сервер приложений 1С:Предприятие 8 -> пользовательская сессия 1С:Предприятие 8? Сетевой интерфейс Ethernet, с его упаковкой данных в относительно небольшие блоки для передачи, всегда будет создавать дополнительные задержки: и при упаковке/распаковке трафика, и при самой передаче (высокая латентность). В 1С:Предприятие 8 довольно большие массивы данных передаются для обработки и отображения по всей цепочке, в некоторых ситуациях - в обе стороны. При прямой же передаче данных от одного процесса другому в рамках оперативной памяти сервера (на одном сервере без виртуализации), или же через виртуальный сетевой интерфейс (в рамках все того же одного физического сервера, при хороших серверных сетевых адаптерах с переносом блоков RAM между VM) задержки намного ниже. Современные двухпроцессорные серверы с большой оперативной памятью и дисковой подсистемой на SSD позволяют комфортно обслужить БД 1С на 100-150 активных пользователей.

Если для нагруженных БД использование нескольких физических хостов неизбежно, желательно связать все серверы по 10Gb Ethernet. Или, как минимум, 2-4агрегированными соединениями 1Gb Ethernet с аппаратным ускорением TCP/IP (TCP/IP Offloader) и аппаратной поддержкой виртуализации.

Больше всего от потерь производительности на портах Ethernet страдают бюджетные решения. Не секрет, что сетевые адаптеры 1Gb, распаиваемые на большинстве серверных материнских плат, не предназначены для обслуживания интенсивного сетевого трафика. Даже если на плате есть 2 или 3 порта GbE, они, как правило, реализованы на десктопных чипах. Достаточные для управления, они порождают дополнительные накладные расходы по обслуживанию сетевых обменов, особенно в виртуализированной среде. Весь процесс передачи данных через такой чип обеспечивается за счет ресурсов процессора, оперативной памяти и нагрузки на внутренние шины. Никакого ускорения передачи IP-трафика такие чипы не дают, каждый принимаемый и передаваемый Ethernet-пакет требует отдельного прерывания на процессор. В виртуализированой среде потери производительности сетевого интерфейса могут достигать 25-30%. Самое неприятное, что перегрузки именно сетевого интерфейса средствами мониторинга можно и не заметить. За него отдувается центральный процессор, а если не работает, то простаивает в ожидании ответа от сетевой карты. Порты на десктопных чипах желательно исключить из потока данных в виртуализированных средах, оставив их под задачи управления сервером. Под интенсивный сетевой трафик стоит добавить дискретную сетевую карту на серверном чипсете.

Отказоустойчивость или допустимое время простоя?

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

Разумеется, для предприятий с относительно большим количеством одновременно подключенных пользователей (25-150) и размещением всех приложений на одном сервере обязательно применение источников бесперебойного энергоснабжения, избыточных блоков питания самих серверов, корзин горячей замены дисков и RAID-массивов с горячим резервированием. Но никакие аппаратные средства не заменят планового резервирования самих данных. Имея ежедневный (точнее, еженощный) backup и оперативный файл с Full SQL log, можно полностью восстановить БД 1С за относительно короткий промежуток.

Допустимое время простоя центральной системы 1С для малых и средних предприятий - 1-2 аварии в месяц, продолжительностью 1-4 часа. На самом деле, это огромный запас времени - если к восстановлению быть готовыми заранее. Необходимым условием быстрого рестарта является наличие образов всех виртуальных и физических серверов в виде VM на отдельном хранилище/томе - для восстановления самой инфраструктурной части на резервном сервере. Обязателен ежедневный backup (а также еженедельный и по закрытию периода) на другое физическое устройство и Full SQL log для случаев, когда потеря данных «с начала рабочего дня» критична и трудно восстановима вручную. При наличии подменного оборудования можно уложиться в 1-2 часа для восстановления работоспособности в целом, пусть и с меньшей производительностью. Ну а там, где требуется непрерывность работы 24×7, первоочередными задачами будут выбор соответствующей архитектуры, оборудования с минимальным количеством точек отказа и полноценных технологий кластеризации. Но это уже совсем другая история.

Оригинал статьи: http://ko.com.ua/proektirovanie_servera_pod_1s_66779

С разрешения редактора журнала "Компьютерное обозрение"

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

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

Если организации необходимо обеспечить надежность и высокую производительность, то, как правило, выбирают внедрение 1С 8 с использованием промышленной СУБД - Microsoft SQL Server. В таком случае в качестве операционной системы используется Windows Server 2003, а оборудование должно отвечать высоким требованиям.

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

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

Также необходимо отметить, что для такого варианта внедрения для рабочих мест нужны лицензии клиентов на подключение к Windows Server 2003/2008. В случае высоких нагрузок на информационную базу 1С производительность Windows SBS 2003/2008 может оказаться недостаточной. В таком случае существует возможность выделить дополнительный сервер, Microsoft SQL Server 2005/2007.

Еще один способ, который нередко используется при внедрении 1С - терминальный сервер. Служба терминальных соединений, встроенная в ОС Windows Server 2003 позволяет получить большой резерв производительности, возможность безопасной и полноценной работы, а также высокий уровень защиты.

Список программного обеспечения для внедрения программ 1С: Предприятие.

Как правило, для внедрения программ на платформе 1С: Предприятие используется следующее программное обеспечение: Windows 7, Vista, XP Professional, Windows Server 2003-2008, Windows Small business server.

Windows XP Professional давно является базовой версией ОС и установлена она во многих организациях. Windows 7 представляет собой достаточно новую операционную систему для персональных компьютеров, которая обеспечивает высокую производительность за счет интеграции сетей, технологий и систем. Компьютеры, оснащенные операционными системами Windows Vista, XP Professional и 7 могут использоваться как серверы для начального уровня. Данные операционные системы поддерживают до 10 подключений, однако скорость работы и безопасность оставляют желать лучшего.

Windows Server 2003 или 2008 являются самыми популярными серверными ОС, которые позволяют внедрить решения 1С:Предприятия, обеспечить надежность и легкость в обслуживании.

Windows Small Business Server 2008 представляет собой программный продукт, состоящий из целого пакета серверных продуктов и дополнительных компонентов. Данный вариант подходит для небольших компаний, не планирующих серьезные нагрузки на информационную базу 1С Предприятие. Основным преимуществом Windows SBS 2008 является низкая цена.

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

Релиз подготовлен магазиномлицензионного программного обеспечения 1cmarket.ru

Комментарии и отзывы

Сетевые источники раскрыли подробные характеристики смартфона Black Shark 2 Pro, который будет официально...

Компания HTC пополнила ассортимент бюджетных смартфонов моделью Wildfire E, которая оценена в 9000 рублей...

Компании LG объявила, что в их телевизорах появится поддержка технологий Apple AirPlay 2 и HomeKit. По з...

Компания Phanteks накануне представила уникальное решение для сборки кастомной СВО. Новый Glacier D140 с...