Дача Бойлеры Отопление

Какой сервер нужен под 1с 8.3. Решения. Отказоустойчивость или допустимое время простоя

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

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

Отправить вопрос по решению По будням отвечаем
в течение часа

Как выбрать сервер для работы с 1С

Рассмотрим несколько основных примеров базовых конфигураций серверов для 1C, руководствуясь двумя основными критериями - количество пользователей и способ реализации самой программы: файловая 1С или 1С:сервер приложений + SQL.

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

    Небольшая компания (2-10 пользователей) , база до 1 Gb, 1С Предприятие — файловый режим, это есть не что иное, как классическая реализация файлового сервера.

    В качестве базового процессора можно выбрать одну из младших моделей Intel Xeon серии Е3-12XX.

    Расчет ОЗУ прост: не вдаваясь в подробности специфики работы системного и файлового КЭШа, просто обозначим — примерно 2 Gb под ОС и столько же для работы с файловой системой.

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

    Рука не поднимается ставить к Intel Xeon — процессору серверной серии всего 4Gb ОЗУ. Все-таки рекомендуем 8Gb (здесь как раз работает принцип больше — не меньше).

    Дисковая система. Современные диски, пусть даже и серверного исполнения, реализующие интерфейс передачи данных SATA, очень мало отличаются по цене в зависимости от объема диска. Поэтому «ловить блох», пытаясь уменьшить стоимость сервера за счет разницы в цене между дисками 500 Gb и 1 Tb не стоит. Кроме того, у всех производителей линейка SATA-дисков объемом 500 Gb уже исчезает из предложений. С другой стороны, никто не отменял известный постулат — скорость заполнения дискового пространства прямо пропорциональна его объему. Т.е. чем больше диск, тем больше информации на нем хранится, даже если изначально это было не нужно. Мы настаиваем на том, что дисков должно быть не менее 2-х, чтобы можно было организовать т.н. программное «зеркало» - минимальную защиту данных при выходе из строя одного из дисков.

    Итак, получаем базовую конфигурацию файлового сервера 1С для использования до 10 пользователей:

    • Процессор Intel Xeon E3 1220V3,
    • ОЗУ — 8 Gb,
    • HDD — 2 х 1 Tb SATA.
  1. Если работает 15-20 пользователей, то размер базы данных может достигать 4 ГБ. Как правило, в этом случае используют версию 1C: Предприятие 8.3 Сервер приложений или SQL-ную версию 1С.

    Отсюда требования к ОЗУ: те же 2ГБ под ОС, до 4ГБ под 1С:сервер приложений и столько же под MS SQL Server. Оптимальный вариант, когда база данных полностью кэшируется в ОЗУ. Получаем необходимый минимум размера оперативной памяти — 10ГБ. На практике часто бывают ситуации, когда версия 1С:Сервер приложений теряет отклик. Такое случается при недостатке ОЗУ, когда ОС вынуждена свопировать 1С на диск. Чтобы такого не происходило, всегда рекомендуем иметь запас оперативной памяти — итого 16ГБ.

    По поводу процессора, опять же четырехядерный процессор серии Intel Xeon E3 12XX вполне справится, выберем лишь тактовую частоту повыше. Тем более, что зависимость скорости работы 1С от тактовой частоты в версии 1С-8.3 компенсируется некой эффективной частотой — количеством ядер процессора, умноженной на тактовую частоту ядра.

    Дисковая подсистема немного усложняется. Опять же, не вдаваясь в подробности работы дисков с операциями чтения- записи (т.н. IOPS), отметим, что средняя скорость работы в том же «зеркале» вырастет примерно в два раза, если мы увеличим количество дисков в зеркале до четырех (т.н. RAID 10).

    Подитожив, получаем базовую конфигурацию сервера для работы 15-20 пользователей в системе 1С:Сервер приложений 8.3:

    • CPU — Intel Xeon E3 1240V3 3.4ГГц,
    • ОЗУ — 16ГБ,
    • Дисковая подсистема — зеркало из 4-х дисков 4х1ТБ.
  2. Для повышения производительности и надежности системы в целом, при количестве пользователей 1С:Предприятие больше 30 , как правило, используется терминальное решение. Суть этого решения состоит в том, что пользовательские приложения (в данном случае 1С), запускаются и работают на самом терминальном сервере, а пользователь видит лишь графическую картинку, которую сервер посылает на его компьютер (терминал). Помимо высокой производительности и возможностей масштабирования, мы имеем дополнительную надежность и защиту ваших данных, которая определяется конфигурацией терминального сервера.

    Здесь, как правило, уже используются дисковые массивы более высокого уровня защиты (RAID 6, 60, комбинации RAID — массивов, реализуемых на аппаратном, обычно выделенном RAID — контроллере).

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

    Известно, что одно ядро процессора может эффективно обработать не более 8 пользователей. Из вышеуказанных критериев не сложно понять, что для эффективной работы более 30 пользователей, необходимо делать выбор в пользу 2-х процессорных серверов — хотя бы по совокупному количеству ядер.

    Типичная конфигурация терминального сервера + 1C:Сервер приложений приведена ниже:

    • Процессор: 2 x 4C/4T CPU | Intel Xeon E5-2609 V2,
    • Модули памяти: 4 x DDR3-ER 8Gb,
    • Накопители: 4 x HDD 1Tb, 4 x HDD 1Tb,
    • Контроллер: RAID.
  3. Для количества пользователей более 50, обычно разделяют роли терминального сервера (сервера приложений) и сервера базы данных.

Сервер для 1С

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

Начиная с какого количества пользователей нужен сервер для 1С?

Бесплатный PostgreSQL для 1С появился уже давно. А сравнительно недавно появилась такая замечательная позиция в прайсе 1С:

Мы уверенно рекомендуем использовать 1С в клиент-серверном режиме начиная с 3-5 пользователей. Файловый вариант остается для совсем небольших баз и если нет потребности работать в базе из дома, командировок, других офисов, если остаться без 1С в случае сбоя на пару дней совсем не страшно. Мы также считаем работу в RDP устаревшей технологией, которая годится только тогда, когда по каким-то причинам используется платформа старая (8.0 или 8.1) или платформа древняя, так и тянет написать "древнерусская" (7.7). Поэтому все, что написано ниже, относится к варианту "на сервере 1С установлена СУБД и сервер приложений 1С:Предприятие, работа ведется в тонком клиенте 8.2".

Покупать брендовый сервер или собрать самим, или заказать сборку поставщикам?

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

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

Небольшое уточнение. Под "брендом" мы понимаем IBM, HP и подобные им марки. Любые местные "интеграторы", собирающие силами вчерашних студентов компьютеры на базе серверной платформы Intel "под заказ", с конфигурацией, записанной со слов клиента, брендами не являются. Даже если этот сервер собран в корпусе для установки в стойку. Даже если ему на лицевую панель налепили красивую этикетку. Это самосбор, и у нас есть множество примеров, когда, скажем так, при подборе компонентов сборщики делают ошибки. Например, мы видели, как в серьезном сервере за более чем 300 000 рублей аппаратный RAID-контроллер конфликтовал с материнской платой, и выдавал 15% от заявленной пропускной способности. Видели мы и конфигурации с огромными перекосами, например машину с четырьмя Xeon и единственным дисковым массивом из двух дисков. Обращайтесь за покупкой сервера под 1С к тем, кто понимает, каким он должен быть.

Что важно, сегодня брендовый сервер, гарантированно работоспособный, проверенный и надежный, стоит дешевле самосбора с сопоставимыми характеристиками. Поэтому сэкономить, покупая самосборный сервер среднего уровня, скорее всего не получится. На сегодня самосбор имеет право на жизнь только в сегменте серверов на базе обычных ("настольных") компонентов, то есть, самого начального уровня, которые брендами практически не выпускаются.

Операционная система


Не устраивая священных войн, рекомендуем использовать Windows Server 2012. Это надежная, проверенная платформа для сервера 1С. Другие решения имеют право на жизнь, но, скажем, если вы решили поставить Ubuntu Server, рекомендации вам вряд ли нужны. Да и вряд ли помогут. Linux для 1С каждый раз уникален и общих рекомендаций дать невозможно.

Для серверов начального уровня вполне можно использовать десктопную Windows, например, Windows 7/8. Если вам не нужны Active Directory, RDS, и в качестве СУБД вы не будете использовать MS SQL Server. Нужно только иметь ввиду, что по умолчанию в Windows 7 Professional количество одновременных подключений по TCP не может превышать 20. В Windows 8 это ограничение сняли.

Память

Памяти должно хватать. Если поставить памяти больше, чем нужно, роста производительности не будет. Если поставить меньше, чем нужно, работа пользователей превратится в пытку. Расчет такой: минимум 2Гб под нужды операционки, от 2Гб под СУБД, от 4Гб под сервер 1С:Предприятия. Итого минимум 8Гб. Такого объема вполне хватит для работы 5-10 пользователей с одной базой. На скриншоте типичная картина распределения памяти при неспешной работе нескольких пользователей с одной небольшой базой:

Обратите внимание, как любит сервер приложений 1С (rphost.exe) память. Сразу же после открытия базы ему нужно около гигабайта. При напряженной работе, например, перепроведении документов за месяц, он вполне способен освоить 6Гб при одном-единственном активном подключении. Еще нужно иметь ввиду, что синяя полоска ("Ожидание") это не свободная память, а системный кэш. Вот та же система, в которой начали более-менее интенсивно работать:

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

16Гб хватит для работы 20-30 пользователей с двумя-тремя базами. Обязательно нужно настроить максимальный выделяемый объем для сервера 1С:Предприятия (это делается в консоли администрирования) и для СУБД! Если этого не сделать, то, например, Postgree "из коробки" памяти будет использовать всего 200-300Мб. По умолчанию он "задушен". А вот сервер приложений 1С, наоборот, вполне может "съесть" все, сколько не дай.

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

Во-первых, даже на сервере начального уровня обязательно нужно разнести диск с системой и диск с базами. Далее, если позволяют финансы, добавляем третий диск для хранения большого объема данных (бэкапы и т.д.). Для Postgree обязательно создаем RAM-диск для временного размещения статистики.

Диск для системы вполне можно использовать не самый быстрый и не самый объемный. 500 Гб более чем достаточно.

Диск для баз однозначно SSD. Для баз 1С у обычных дисков и их массивов нет ни малейших преимуществ. При типичном размере базы среднего предприятия 2-3 Гб объема в 120Гб, как понимаете, вполне хватит. А быстродействие, при прочих равных, отличается в 10 и более раз. Ограничения по числу циклов перезаписи уже в прошлом, на сегодня SSD надежнее любого "механического" диска. Обязательно нужно брать SSD с технологией TRIM (дозапись кэша при отключении питания), и нужно внимательно смотреть на заявленную скорость записи, сейчас на рынке много разных вариантов.

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

Архивирование можно настроить средствами СУБД или написать командный файл, который будет запускаться планировщиком Windows и делать выгрузку баз из пакетного режима 1С:Предприятия. Это не очень важно. Важно, чтобы каждую ночь система автоматически делала архив, и записывала его на отдельный диск сервера. Система архивации, которая требует запуска вручную, является не системой архивации, а ерундой. После создания выгрузок баз очень рекомендуем заливать их в облачное хранилище. Это может быть Google Drive, Yandex Disk, Dropbox или ваш собственный ftp-ресурс. Главное, чтобы эти выгрузки хранились не в том же помещении, где стоит сервер. Почему? Потому что нормальный бизнес должен спокойно перенести все что угодно. Пожар, кражу со взломом, визит из органов с изъятием. Не дай бог конечно, но всякое бывает.

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

Блок питания и ИБП

Не экономьте на блоке питания. Никогда. На всем остальном можно экономить в разумных пределах, а блок питания для сервера должен быть идеальным. Сервер отличается от обычного компьютера в первую очередь тем, что включен постоянно. Двукратный запас по ваттам и производитель с именем (Thermaltake, Powerman, Enermax), вот наша рекомендация. ИБП (Источник Бесперебойного Питания) нужен для двух задач. Во-первых, при серьезных скачках напряжения, он должен дать возможность выжить блоку питания сервера, приняв удар на себя (или лучше на свой предохранитель). Во-вторых, он должен корректно выключить сервер при пропадании напряжения в сети. ИБП не должен и не может позволять работать без внешнего напряжения, это иллюзии. Даже 15 минут. Его задача - дать операционке сервера команду на выключение. Поэтому не подключенный и не настроенный ИБП является предметом интерьера, не более того.

Процессор

При работе 5 пользователей любой "настольный" процессор достаточно высокого класса, например четырехядерный Core i7 в среднем будет загружен на 5-7%. Процессор, как правило, не является узким местом. Он должен соответствовать остальным параметрам, не более того. Поэтому процессор лучше выбирать в последнюю очередь, из подходящих для выбранной системы. Цифровые характеристики (число ядер, размер кэша, частота) не являются определяющими. Например, свежие Core i5 обгоняют Core i7 предыдущего поколения.

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

Программное обеспечение

Не нужно ставить на сервер антивирусное ПО. Это лишнее. Безопасность и отсутствие вирусов обеспечивается тремя правилами:

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

Не рекомендуем совмещать сервер 1С и файловый, почтовый, прокси и веб сервер. Эти задачи прекрасно решают специализированные устройства и сервисы. Например, роутер Zyxel Keenetic 4G и подобные ему прекрасно умеют раздавать интернет в сети, работать ftp- и файл-сервером. Веб-сервер небольшой и средней компании асболютно точно лучше перенести на VDS в датацентр. Почту туда же, или вообще на Google или Yandex почту для вашего домена.

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

Безусловно, для hi-end серверных решений это очень востребованная технология. Однако, для предприятий среднего размера (20-50 пользователей) преимущества виртуализации далеко не очевидны, а для небольших компаний ничего кроме головной боли не дают. Во-первых, виртуализация серверов не бесплатна, и на нее тратятся ресурсы машины. Во-вторых, все преимущества "настройки производительности на лету" и "мобильности" разбиваются об кучу проблем с потерей программных лицензий 1С в случае любых изменений. В-третьих, делить-то по большому счету нечего (ресурсов немного), да и несколько серверов такому предприятию просто не нужны. Арендовать же виртуальный сервер в датацентре под 1С на сегодня рискуют очень немногие предприятия, да и в таком случае лучше не арендовать сервер, а подключиться к сервису "1С Онлайн".

Сколько стоит сервер для 1С?

На момент написания этой статьи примерная стоимость сервера:

    • от 30 000 рублей на 5-10 пользователей
    • от 60 000 рублей на 15-20 пользователей
    • от 90 000 рублей на 30-50 пользователей

При большем количестве пользователей уже становится необходимым разносить сервер СУБД и сервер приложений на разные физические машины.

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

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

Мы собрали рекомендации ведущих производителей оборудования (HP, Dell, IBM) и разработчиков программного продукта «1С» 8.3, чтобы наши клиенты могли выгодно приобрести нужный сервер. Оптимальная инфраструктура сети может быть получена на базе любой операционной системы, но возможности оборудования играют в этом более важную роль.

Критерии выбора серверов

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

При выборе сервера для «1С» (8.2; 8.3) ориентируются на следующие моменты:

  • количество операторов, одновременно выполняющих ввод данных и формирование отчетов;
  • возможность выделения отдельных физических серверов для SQL и приложения «1С»;
  • планируемые объемы обработки данных;
  • структуру распределения нагрузки в архитектуре клиент-сервер

Выбор процессора и оперативной памяти

Расчет частоты, нужного количества ядер процессора, а также объема оперативной памяти является первым и самым важным шагом. Чтобы рассмотреть несколько вариантов, выбирать сервер для «1С» будем с учетом штата компании.

Малая организация (до 15 сотрудников). При небольшом количестве пользователей объем базы данных, как правило, не превышает 2 Гб, а программа «1С» в виде файловой версии устанавливается на клиентские машины. Нужды ОС при этом составляют 4–6 Гб и еще 4 Гб выделяют на системный файловый кэш. Распределение нагрузки процессора выглядит следующим образом:

  • 2 ядра – для ОС и терминальных пользователей;
  • 1 ядро – для сервера приложений «1С»;
  • 1 ядро – для БД SQL.

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

Средняя организация (до 40 сотрудников). При таком количестве пользователей разработчики «1С» рекомендуют использовать терминальный режим доступа к приложению. Размер баз данных может составлять до 4 Гб. Для такой нагрузки нужно уже как минимум два процессора на 4–6 ядер. Оптимальный объем оперативной памяти составит 16–64 Гб, поскольку для каждого пользователя необходимо выделить минимум 700 Мб. Считается, что прикладное решение «1С», в котором работает клиентская машина, требует от 240 до 480 МБ, а еще 200–220 МБ выделяется под офисные приложения.

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

Большая организация (более 40 сотрудников). Базовая конфигурация оборудования в этом случае будет состоять из трех физических серверов:

  • терминального,
  • СУБД,
  • «1С».

Объемы БД при таком количестве сотрудников часто превышают 4 Гб, и под системный кэш рекомендуется выделять не меньший объем оперативной памяти. Еще 4 Гб будет использоваться операционной системой, а для приложений «1С» потребуется около 8 Гб. Таким образом, нужно не менее 16 Гб ОЗУ.

Под такие задачи подбираются двухпроцессорные серверы с поддержкой Intel Xeon E5-2600 или выше. Если количество сотрудников не превышает 50 человек, для терминального доступа и приложений «1С» можно оставить только одну машину. Однако с учетом перспективы роста компании лучше предусмотреть отдельный сервер для каждой задачи. Если количество задействованного персонала приближается в 100 сотрудникам, нужно развернуть кластер из двух машин для «1С», а для остальных задач оставить по одной.

Выбор дисковой подсистемы

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

В задачу выбора сервера для 1С входит мониторинг дисковой подсистемы, позволяющий найти оптимальное соотношение производительности и надежности. Чрезвычайно важным фактором, влияющим на быстродействие, оказывается ее способность выполнять определенное количество операций чтения/записи в секунду (IOPS). Если база данных составляет до 300 Мб, а количество пользователей «1С» – до 6 человек, этот параметр составляет 400–600. Если количество пользователей сервера доходит до 100 человек, то IOPS будет равняться 18 000. Потоковая скорость передачи играет второстепенную роль.

Для каждого типа жестких дисков установлены значения скорости чтения/записи:

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

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

При проектировании решения важную роль играет отказоустойчивость системы. Для этого используются как аппаратные, так и программные средства. На серверы устанавливают блоки питания и дисковые корзины с горячей заменой, используют ИБП для бесперебойной подачи электроэнергии. Обеспечение сохранности данных производится путем их резервирования. Минимум раз в сутки создается log-файл, обеспечивающий восстановление информации при сбоях в системе.

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

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

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

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

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

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

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

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

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

Процессор

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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