Типовые предложения для средних компаний

Серверы 1С для средних компаний

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

Системой 1С пользуются компании с весьма разным родом и характером деятельности, поэтому приведенные здесь параметры машин надо воспринимать лишь как ориентировочные. Для выработки точных спецификаций мы рекомендуем обратиться к нашим специалистам, например на форуме. Компании подобного размера обычно работают не первый год и уже используют 1С, поэтому ниже Вы очень часто будете видеть рекомендации воспользоваться мониторингом производительности (Windows Perfomance Monitor, perfmon.exe). На основании этих данных, и зная конфигурацию нынешнего сервера, как правило можно с достаточной точностью определить требуемые параметры новой машины.

В процессе выбора и конфигурирования сервера советуем так же ознакомиться с нашими рекомендациями общего плана.

Для Вашего удобства предложения разбиты на категории и сопровождаются комментариями по выбору.

До 30-50 пользователей 1С

До 50-100 пользователей 1С 

Отказоустойчивые кластерные конфигурации

До 30-50 пользователей 1С

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

В качестве сервера базы данных мы рекомендуем следующие машины: E240-M3, E220-M3, E230-M3. Первые два сервера отличаются в основном конструктивно (напольный и стоечный соответственно) , а третий вмещает большее количество дисков и оперативной памяти, что может потребоваться при очень высокой нагрузке или на будущее, если бизнес компании бурно растет. Если недостаточно места в стойке, можно обратить внимание на компактный 1U сервер E210H-M3.

Основными узкими местами сервера базы данных обычно является дисковая подсистема и связанный с этим объем оперативной памяти. Поскольку размер базы данных в таких компаниях как правило невелик (обычно не более 5-10ГБ), то вполне возможно полное кэширование БД в ОЗУ сервера. В общем-то это не обязательно, особенно если актуальна не вся БД (например в ней присутствуют данные по прошлым годам, нужные лишь время от времени), но как минимум нужно заложить объем ОЗУ не менее 30-50% от размера БД для целей кэширования. Плюс, разумеется, как минимум 1ГБ для нужд ОС. Если на этом физическом сервере работает и сервер приложений 1С, то надо выделить память и ему - от 1ГБ до 2-4ГБ (лучше проконсультироваться с франчайзи - это зависит от их конфигурации). Кстати, не стоит уповать на то, что БД, полностью кэшированная в ОЗУ, решит все проблемы производительности. Система 1С генерирует очень мощную нагрузку на запись, что не может быть компенсировано оперативной памятью.

Дисковая система, разумеется, должна быть выполнена на дисках SAS, настоятельно рекомендуется использовать RAID10 или RAID1E. Количество дисков исключительно сильно зависит от интенсивности работы пользователей и от использования аналитики. Как правило достаточно 6-8 дисков, но если Ваша компания интенсивно растет, лучше взять сервер с большим числом дисковых отсеков - можно будет добавить дисков по мере роста. Для более точного расчета обязательно нужно промониторить нагрузку на дисковую подсистему (reads/sec, writes/sec, queue lenght) на нынешней машине в показательный период (нужно знать данные в среднем и в пиках). Основной счетчик - дисковая очередь (queue lenght). Если Вы видите в среднем цифры в десятки и сотни единиц, значит основным тормозом производительности является именно дисковая система. Пиковые всплески не так страшны, если только они не повторяются слишком часто и не длятся десятки секунд (в это время пользователи видят внезапные увеличения времени отклика приложения). Прогресс в производительности дисков остановился много лет назад, поэтому для получения нужной производительности основной параметр - количество дисков в сервере. Не стоит забывать, что если в старом сервере узким местом были процессоры, то новые четырехъядерники скорее всего создадут гораздо большую нагрузку на диски. Т.е. нужно заложить запас, иначе ожидаемого эффекта не будет. И обязательно необходим аппаратный RAID контроллер с включенным write-back cache и BBU (контроллеры в наших серверах стоят по умолчанию, а BBU надо заказать опционально) - кэш контроллера помогает "проглатывать" короткие всплески нагрузки.

Процессоры, как это ни странно, являются не самым главным параметром сервера базы данных. Дело в том, что разница в производительности процессоров одного поколения не превышает 1,5-2 раз (а вот цена растет непропорционально). Пользователи едва ли субъективно заметят ускорение отклика приложения (или уменьшение времени проведения отчета) меньше, чем в полтора раза. Недостаточность же дисковой производительности может вызвать резкий "ступор" во время проведения отчетов или больших документов, причем не у одного пользователя, а у всего офиса разом. Общее правило планирования мощности процессоров - их средняя загрузка не должна превышать 30%, максимум 50%. Это даст достаточный запас для временных всплесков нагрузки. Это опять же лучше всего выяснить мониторингом нынешнего сервера и экстраполировать на новые процессоры. Таким образом, нет смысла выбирать максимально мощные CPU - принципиальная разница видна только при смене "через поколение", когда производительность вырастает в несколько раз. Топовые процессоры уместны только в редких случаях - когда нагрузка очень велика (например выполняется какая-то сложная аналитика). Однако не стоит забывать, что начиная с 1С 8.1 эту аналитику можно переносить на сервера приложений, тем самым значительно уменьшая процессорные требования для сервера баз данных.

В качестве терминальных серверов мы предлагаем E210-M3 и более дешевый E210C-M3. Отличаются они большим объемом ОЗУ и наличием дублированных блоков питания в старшей модели.

В терминальном сервере основные параметры - достаточность объема ОЗУ и процессорная мощность. Необходимый объем ОЗУ - приблизительно по 150-200МБ на каждую клиентскую сессию (иногда бывают существенные отклонения, лучше всего предварительно выяснить, сколько памяти нужно типовому клиенту в Вашей конфигурации), плюс 1ГБ для ОС. Избыток памяти никакого эффекта не даст, а вот недостаток вызовет swap на диски во время работы, что катастрофически сказывается на производительности.

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

Сильной дисковой нагрузки на терминальном сервере обычно нет, можно использовать зеркало из SATA дисков. Но в ряде случаев бывает высокая нагрузка на временные файлы, создаваемые 1С на локальных дисках - в этом случае можно укомплектовать машины аппаратным RAID контроллером и SAS дисками (это можно сделать и в процессе эксплуатации).

Часто на терминальном сервере, помимо 1С, выполняются и другие приложения (обычно офисные пакеты, интернет). Это, разумеется, вызывает рост загрузки процессоров и, особенно, оперативной памяти. В этом случае надо выяснить, сколько памяти занимают типовые приложения и соответственно увеличить размер ОЗУ на сервере (в среднем нужно удвоить, что не смертельно - памяти серверы поддерживают много). Процессорную загрузку выяснить сложнее, но можно порекомендовать изменить требования примерно в полтора раза.

Если для Вашей задачи все же потребуется выделенный сервер приложений 1С, можно обратить внимание на однопроцессорные машины, например E110-M2 (достаточно пары SATA дисков и 4ГБ памяти). 

 До 50-100 пользователей 1С

Основные соображения по выбору серверов рассмотрены в пункте выше, поэтому сосредоточимся на основных отличиях. 

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

В качестве сервера базы данных мы рекомендуем серверы E230-M3, E240H-M3 и E220H-M3. Они имеют мощные дисковые подсистемы на 16 и 24 диска. Если нагрузка на сервер БД постоянно растет, мы рекомендуем не экономить и выбирать серверы на большее количество дисков, пусть даже не в полной набивке - лучше потом добавить дисков и памяти, чем через год покупать более мощную машину.

В качестве сервера приложений оптимальным будет E210-M3 с 4-8ГБ памяти. В принципе конечно можно посмотреть и однопроцессорную машину, но лучше два более слабых процессора, чем один мощный (не путать со старой 1С8.0 - там требовался один процессор максимальной мощности). Нагрузка на сервер приложений очень сильно зависит от используемой Вами конфигурации 1С, поэтому рекомендуем проконсультироваться с Вашими внедренцами 1С, а еще лучше - предварительно промониторить нагрузку.

С сервером терминалов проще всего - они масштабируются горизонтально. Т.е. можно просто поставить два или три E210-M3 или E210C-M3 - в зависимости от нагрузки. Причем и отказоустойчивость обеспечивается автоматически - при поломке одного сервера клиентские сессии можно перезапустить на другом. Главное - заранее поставить ОЗУ с запасом.

 Отказоустойчивые кластерные конфигурации

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

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

Разные серверы, входящие в инфраструктуру 1С, резервируются разными средствами.

Серверы терминалов кластеризовать сторонними средствами не требуется. При наличии двух или более серверов терминальные сессии одного из них могут быть запущены на любом другом - это обеспечивается средствами Windows. Пользователям потребуется только заново запустить приложения. Мы рекомендуем лишь иметь в терминальных серверах запас ОЗУ и процессорной мощности, чтобы в случае сбоя не получить сильное падение производительности. А машины можно использовать такие же, как описано выше (причем, в целях экономии, можно использовать даже недорогие серверы с одиночными БП - E210C-M3).

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

Сложнее всего обстоит дело с сервером базы данных. Поскольку сервер БД работает с данными на дисках, то при сбое сервера пропадает так же и доступ к его встроенной дисковой подсистеме. Поэтому обязательно требуется использование внешней системы хранения данных (причем, по соображениям отказоустойчивости, двухконтроллерной) и двух серверов (активный и резервный узлы кластера), подключенных к СХД по интерфейсам SAS или FibreChannel. Так же необходимо программное обеспечение, отслеживающее сбои сервера и автоматически запускающее СУБД на резервном сервере (такое ПО входит в состав Windows Server Enterprise Edition).

Поскольку дисковая система у нас внешняя, в самих серверах не требуется высокая производительность дисковой подсистемы (достаточно зеркала для загрузки ОС) и можно использовать такие же E210-M3  или E210C-M3, как и для серверов приложений и терминалов. 

В качестве СХД для задач такого уровня мы рекомендуем недорогие (10-30 тыс. долл.) двухконтроллерные системы IBM DS3500. СХД с интерфейсом SAS позволяют подключить 2-3 сервера (с дублированием каналов связи), что вполне достаточно для подобной задачи. Помимо решения задачи кластеризации СХД обеспечивают так же масштабирование производительности по мере роста нагрузки (добавлением дополнительных JBOD), а так же дополнительные функции. Например интерфейс FibreChannel позволяет создать SAN и использовать ресурсы СХД и для других серверов (например кластеризовать файловые или почтовые серверы), а встроенные средства snapshot (мгновенных снимков) упрощают резервное копирование. Дисковая система является критической точкой информационной системы (SPOF), поэтому она обязательно должна иметь дублированные RAID контроллеры, а в особых случаях две СХД можно зеркалировать при помощи дополнительного ПО Symantec Storage Foundation (при разнесении дисковых систем и узлов кластера система станет катастрофоустойчивой).

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

Некоторой альтернативой кластеризации может быть блэйд система, например недорогая IBM BladeCenter S. Она представляет собой единое шасси, в котором находится шесть серверов-лезвий. Помимо обычных преимуществ блэйд систем (консолидация и дублирование всех компонентов, единая удобная консоль управления), можно воспользоваться дополнительной опцией Open Fabric. В этом случае лезвия загружаются с разделов внешней СХД, а при сбое одного из них запасное лезвие автоматически загружается и подменяет собой вышедшее из строя. Т.е. функционально аналогично кластеризации, но проще в части настройки ПО. Правда в случае сбоя произойдет кратковременная приостановка работы (несколько минут - для загрузки ОС и ПО), что зачастую не так уж критично. Впрочем, блэйд систему можно использовать и с традиционной технологией кластеризации.

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

Замечания общего характера для всех систем 1С:

- использовать RAID5 можно лишь при условии очень малой нагрузки, поскольку он имеет весьма низкую производительность на операциях записи, которых система 1С производит очень много. Мы рекомендуем RAID1 (зеркало - при малой нагрузке), RAID10 или RAID1E. Последний отличается тем, что может состоять из нечетного числа дисков, поэтому мы особенно рекомендуем его использовать - это позволит выделить один диск для HotSpare (диск горячего резерва, автоматически подменяющий сбойный) в корпусах с четным числом дисковых отсеков.

- зачем нужен дорогой аппаратный RAID контроллер, если есть интегрированный на материнской плате? Интегрированный контроллер не блещет стабильностью и подходит разве что для зеркалирования. Кроме того, в качестве кэша он использует часть основной оперативной памяти сервера - в случае сбоя питания или просто зависания данные в этом кэше будут однозначно потеряны. Отключение же кэша весьма плачевно сказывается на производительности. Аппаратный контроллер имеет собственный кэш, который, за исключением самых дешевых моделей, можно защитить при помощи BBU. Он так же спокойно переносит отключение кэша самих дисков (что категорически рекомендуется для БД), в отличие от интегрированного. Ну и, разумеется, возможности мониторинга и управления аппаратных и интегрированных контроллеров отличаются самым радикальным образом.

- использование кэша RAID контроллера на запись (Write-Back Cache) очень сильно повышает производительность дисковой подсистемы (в разы), но создает риск потери данных при сбое питания или поломке аппаратуры. Поэтому при наличии аппаратного RAID контроллера всегда рекомендуется установка BBU (батарея аварийного питания кэша). В случае программного зеркалирования или интегрированного контроллера такой опции, к сожалению, нет. Кэш дисков, кстати, по соображениям целостности данных всегда настоятельно рекомендуется выключать - его защитить нельзя ничем.

- зачем BBU, если есть UPS? UPS спасает только от пропадания питания в розетке. От сбоев самого UPS, блоков питания, материнской платы, кабелей он не поможет. BBU не исключает UPS, оно его дополняет.

- зачем нужна мощная дисковая, если база данных целиком кэшируется в ОЗУ сервера? Это конечно замечательно, но информационная система данные не только читает, но и пишет на диск. Даже если Вы полностью закэшируете БД, все равно останется нагрузка на запись, которая весьма велика. И во время всплеска активности пользователей производительность сервера может резко упасть (как раз тогда, когда она нужна), несмотря на простаивающие процессоры и свободную оперативную память.

- можно ли сделать на RAID контроллере два массива - под ОС и под данные? Можно, но не нужно. ОС не создает дисковой нагрузки и производительность дисков будет потрачена зря. Лучше сделать один массив и поделить его средствами контроллера на два LUN (разделы массива, видимые ОС как независимые физические диски) - работать будет быстрее.

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