Куперс

Владимир Ряничев, технический специалист компании «ГЭНДАЛЬФ»

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

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

Это связано с тем, что пользователи, которые сэкономили на покупке или покупали компьютерное оборудование 3-5 лет назад, сейчас сталкиваются с тем, что «1С» работает крайне медленно и тормозит рабочий процесс.

Принято считать, что в офис для работы с документами и «1С» можно купить самый простой компьютер, т.к. на нем не будут запускать ресурсоемкие игры или программы 3D-моделирования. Но это ошибка! За последние годы учетные программы превратились в мощные инструменты анализа, которые дают специфическую нагрузку и потребляют гораздо больше ресурсов.

Мы провели эксперимент и выяснили, какие параметры системного блока позволят «1С» работать максимально эффективно!

Тестировали с помощью специальной обработки, которая при тестировании, запускает одновременное проведение 150 документов разного вида, но пересекающихся по регистрам (ПКО, РКО и РТУ) в рабочей базе «1С:Бухгалтерия», ред. 3.0 текущего релиза с интерфейсом «Такси». Объем базы 4 Гб.

Тесты проводились на 6 компьютерах разных конфигураций:

• разные процессоры 4-х и 8-ми ядерные.

• количество оперативной памяти 4 – 8 GB, с SSD диском Silicon Power SATA-III 60Gb SP060GBSS3S60S25 S60 2.5″ w490Mb/s и без него.

• программное обеспечение: Windows 10 PRO 64 bit.

Тестовый экземпляр №1

Процессор: AMD FX 4330, (4 ядра, 4 ГГц, 95Вт)

Материнская плата: Asus M5A78L-M LX3 Soc-AM3 AMD760G

Оперативная память: Память DDR3 4Gb 1333MHz Kingston KVR13N9S8/4-SP 2 шт.

Жесткий диск: HDD Toshiba 500 GB HDWD105UZSVA P300
Стоимость: 16 200 р.

Тестовый экземпляр №2

Процессор: AMD FX 8320E, (8 ядер, 3.2 ГГц и 4 ГГц в режиме Turbo)

Материнская плата: Asus M5A78L-M LX3 Soc-AM3 AMD760G

Оперативная память: Память DDR3 4Gb 1333MHz Kingston Kingston KVR13N9S8/4-SP 2 шт

Жесткий диск (HDD): HDD Toshiba 500 GB HDWD105UZSVA P300
Стоимость: 21 900 р.

Тестовый экземпляр №3

Процессор: AMD A4-6300 Richland (FM2, L2 1024Kb)

Материнская плата: Asus A68H

Оперативная память: Память DDR3 4Gb 1333MHz Kingston KVR13N9S8/4-SP

Жесткий диск (HDD): HDD Toshiba 500 GB HDWD105UZSVA P300
Стоимость: 12 500 р.

Тестовый экземпляр №4

Процессор: Intel® Core™ i3-4170 Processor3M Cache, 3.40 GHz

Материнская плата: Asus чипсет H81

Оперативная память: Память DDR3 4Gb 1333MHz Kingston KVR13N9S8/4-SP

Жесткий диск (HDD): HDD Toshiba 500 GB HDWD105UZSVA P300
Стоимость: 22 500 р.

Тестовый экземпляр №5

Процессор: Intel® Celeron® Processor G1840 2M Cache, 2.80 GHz

Материнская плата: Asus чипсет H81

Оперативная память: Память DDR3 4Gb 1333MHz Kingston KVR13N9S8/4-SP

Жесткий диск (HDD): HDD Toshiba 500 GB HDWD105UZSVA P300
Стоимость: 18 000 р.

Тестовый экземпляр №6

Процессор: Intel® Pentium® Processor G3260 3M Cache, 3.30 GHz

Материнская плата: Asus чипсет H81

Оперативная память: Память DDR3 4Gb 1333MHz Kingston KVR13N9S8/4-SP

Жесткий диск (HDD): HDD Toshiba 500 GB HDWD105UZSVA P300
Стоимость: 19 400 р.

После установки и запуска «1С:Бухгалтерии» 3.0 сразу выявились лидеры и аутсайдеры.

Минимальное время загрузки заняло ~45 сек, максимальное ~2 мин. 10 сек. Лучшую скорость работы показал Тестовый экземпляр № 2, а аутсайдером оказался экземпляр №5. Именно в базовой конфигурации экземпляр №2 превысил скорость загрузки трех сеансов «1С» практически в 3 раза, относительно №5.

На втором месте оказался экземпляр № 1. Оставшиеся конфигурации показали примерно одинаковые результаты: ~1 мин 10 сек.

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

Далее на каждом тестовом экземпляре была запущена обработка для проведения документов.

Ниже приведен сводный график по всем тестируемым компьютерам со средним временем проведения документов.

Оцените сравнительные графики:

Итоги тестирования

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

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

Самый слабый результат, как в и предполагалось, показал системный блок на базе процессора AMD A4-6300 без SSD диска. Среднее время проводки превышало 300 мс.

Самым сбалансированным по цене и результату получился системный блок на базе процессора: AMD FX 4330 с объёмом памяти в 4GB с SSD диском.

При своей цене в 17 200 р., он дороже системного блока на базе процессора AMD A4-6300 4GB с SSD диском на 11 %, а прирост в мощности получается 29%. Выгода более чем в два раза.

Системный блок AMD A4-6300 4GB без SSD диска, с его невысокой ценой в 12 500 р., будет достаточен для стандартных офисных задач и небольших информационных баз с маленьким количеством операций.

Лучшее Время при проведении документов показал системный блок на базе процессора Intel® Core™ i3-4170. Он подойдет, если вы используете не только офисные программы и «1С», но и другие приложения, т.к. стоимость компьютера Intel® Core™ i3-4170 4 GB с SSD 25 500 р. на 48 % выше AMD FX 4330 4GB с SSD и на 64% AMD A4-6300 4GB с SSD. Прирост производительности в этих случаях – 21% и 44% соответственно.

Что же выбрать?

Ценовая категория до 16 000 рублей

Тестовый экземпляр №1

Стоимость – 14 200 р.

Ценовая категория до 21 000 рублей

Тестовый экземпляр №1 с SSD диском

Стоимость – 17 200 р.

Ценовая категория от 21 000 рублей

Тестовый экземпляр №4

Выбирая сервер под 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 . Объем необходимой оперативной памяти (RAM) считается совсем просто: 2GB под операционную систему и 2GB под системный файловый кеш.

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

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

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

Для определения необходимых процессорных ресурсов исходят из того, что одно физическое ядро может эффективно обрабатывать не более 8 пользовательских потоков — это связано с внутренней архитектурой процессоров. Как показывает практика, под задачи 1С + Remote Desktop не стоит брать серверные процессоры младших линеек с низкими частотами расчетных ядер и урезанной архитектурой. Если пользователей немного (до 15-20), хватит одного процессора из высокочастотных Intel Xeon . При этом минимум одно его физическое ядро (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.

3-5 польз., 300 MB	10-15 польз., 800 MB	40-50 польз., 4 GB	80-100 польз., 20 GB
400-600 IOPS	1500-2500 IOPS	5000-7500 IOPS	12000-18000 IOPS

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

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

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

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

Стоит сказать, что это усредненные параметры, для каждой БД количество необходимых IOPS нужно рассчитывать отдельно. Все зависит от того как работают пользователи с БД. В моей практике были БД объемом 50 ГБ и средней нагрузкой 500 IOPS, а в пике 1024 IOPS. Особо актуально подсчет IOPS критичен в виртуальных средах, когда дисковая система хранится на СХД, когда приходится выбирать недорогой протокол iSCSI или более дорогой вариант Fiber Chennal Protocol.

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

	RAID 0	RAID 1 (or 10)	RAID 5	RAID 6
Read	1	1	1	1
Write	1	2	4	6

Если собрать 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.

Не забываем про регламентные задания средствами SQL, рекомендованные службой Техподдержки 1С . Особенности эксплуатации SQLServer 2005-2008 для 1C-Предприятие 8

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

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

Регламентные задачи SQL для 1С
Параметры сервера для работы в 1С