Fujitsu PRIMERGY RX2540 M7 конфигурация для ERP и файлов

Что нужно ERP и файловым сервисам на одном сервере

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

Типичная ERP состоит из базы данных, сервера приложений, фоновых заданий (закрытие периода, расчеты, обмены) и отчетов. В обычные часы это множество коротких запросов, а в пики нагрузка резко растет. Файловые сервисы - это общие папки, профили пользователей, сканы, CAD и офисные документы, плюс антивирусная проверка и индексирование.

Важно помнить: тесты на одинаковом «железе» не гарантируют одинаковый результат в жизни. Конфигурация Fujitsu PRIMERGY RX2540 M7 может выглядеть отлично в бенчмарках, но «проседать» в реальной работе из-за другой картины запросов к базе, большего числа одновременных пользователей, тяжелых отчетов в конце месяца или из-за тысяч мелких файлов на шаре.

Что обычно важнее в железе

Приоритеты зависят от того, где именно «болит», но чаще всего логика такая:

• CPU важен для сервера приложений, отчетов и фоновых расчетов. При большом параллелизме важнее количество ядер, а не только частота.
• Память критична для базы и кешей. Если ОЗУ мало, начинается активный своп, и все тормозит даже при быстрых дисках.
• Диски и контроллер определяют задержки и IOPS, особенно для базы и активных файловых каталогов.
• Сеть важна для файлового сервиса и резервного копирования. Часто узкое место - 1GbE до коммутатора.
• Отказоустойчивость нужна везде: блоки питания, вентиляторы, RAID, запас по дискам и понятный план восстановления.

Где чаще всего возникают узкие места

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

Бэкапы влияют сильнее, чем ожидают. Ночной полный бэкап, антивирусное сканирование и регламентные задания ERP могут совпасть, и сервер начинает жить в режиме постоянного пика. Поэтому заранее определите окно резервного копирования, дневной объем изменений и реальное число пользователей в часы пиков.

Пример: 120 пользователей, ERP с отчетами в конце месяца и общий ресурс для сканов. Днем критичны задержки базы и скорость сети до рабочих мест. Ночью - скорость бэкапа и то, как регламенты и копирование влияют на диски.

Какие вводные собрать перед выбором конфигурации

Чтобы Fujitsu PRIMERGY RX2540 M7 конфигурация для ERP получилась «в точку», сначала соберите факты о реальной нагрузке. Иначе легко переплатить за ресурсы, которые не используются, или упереться в диски и память уже через пару месяцев.

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

Минимальный набор вводных, который стоит зафиксировать письменно:

• Сколько активных пользователей в час пик и какие роли (операторы, бухгалтерия, аналитика).
• Размер базы сейчас и прогноз роста на 12-24 месяца.
• Профиль файлового сервиса: много мелких документов или крупные файлы (сканы, CAD, медизображения).
• Какая часть данных должна быть «горячей» и сколько можно оставить «холодной».
• Интеграции: терминалы, печать, обмен с внешними системами, антивирусное сканирование «на лету».

Дальше определите требования по доступности. Это влияет на выбор RAID, резервирование, количество блоков питания и подход к обновлениям.

Полезно ответить на вопросы:

• Сколько простоя допустимо в месяц или в год.
• Есть ли окно обслуживания ночью или в выходные.
• Как быстро нужно восстановиться после сбоя (RTO) и сколько данных можно потерять (RPO).
• Нужна ли работа без остановки при отказе диска, БП, вентилятора, сетевой карты.

Отдельно опишите профиль нагрузки: что преобладает (чтение или запись), много ли мелких операций (часто так в ERP) и бывают ли выраженные пики (закрытие месяца, инвентаризация, массовая печать). Если есть текущий сервер, снимите метрики CPU, памяти, очередей диска и задержек хотя бы за неделю.

И не забудьте про ограничения: место в стойке, доступное питание, требования по лицензиям (например, по ядрам CPU), политика по вендорам и поддержке. На практике именно эти рамки часто и определяют разумный профиль конфигурации.

Профиль «стандарт»: баланс под типовой офис

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

По CPU сначала решите, нужен ли один или два сокета. Для типового офиса часто хватает одного сокета с более высокой частотой: и ERP, и файловые операции чувствительны к задержкам и «быстрому» ядру. Два сокета оправданы, если много одновременных пользователей, есть тяжелые отчеты, фоновые задачи, интеграции, и нужен запас на рост на 2-3 года.

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

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

По RAID чаще всего выбирают понятную схему: зеркало для системы и RAID10 для данных, если важны скорость и предсказуемые задержки. RAID5/6 иногда берут ради объема, но нужно учитывать: перестроение после отказа диска может быть долгим и заметным для пользователей.

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

Пример «стандарта» для Fujitsu PRIMERGY RX2540 M7: офис на 60-120 пользователей, один узел под ERP и файловый сервис. Один сокет с упором на частоту, память с запасом под рост базы, SSD-массив RAID10 под данные, зеркало под систему и сеть минимум 2x под трафик плюс управление. Получается понятная, «не капризная» основа, которую легко поддерживать и расширять.

Профиль «повышенная надежность»: меньше рисков и простоев

Если ERP и файловый сервис критичны для работы, цель простая: пережить отказ одного элемента без остановки и без аврала в ИТ-отделе. Такой профиль обычно дороже «стандарта», но окупается тем, что проблемы становятся заметными, но не превращаются в катастрофу.

Начните с питания. Резервирование блоков питания имеет смысл только при двух независимых линиях: разные автоматы, разные PDU, по возможности разные ИБП. Если обе линии фактически одна, два БП не спасут.

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

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

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

Минимальный набор запчастей, который реально сокращает простой:

• диск того же типа и объема (или два, если парк большой)
• блок питания
• самый «ходовой» модуль охлаждения или вентиляторы
• запасной RAID/HBA-контроллер, если он отдельный
• комплект кабелей питания для стойки

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

Профиль «максимум IOPS»: как снизить задержки

Этот профиль нужен, когда сервер уже «живой», но пользователи жалуются на паузы: проводки подтверждаются заметно дольше, отчеты «подвисают», а на файловом ресурсе периодически тормозит открытие и сохранение множества мелких документов. Часто при этом CPU и RAM не перегружены, а причина - дисковая подсистема.

Если время отклика растет именно в часы пик, а жалобы похожи на «жду, пока прогрузится», вы, вероятнее всего, упираетесь в IOPS и задержку хранения. В таком случае конфигурация максимум IOPS NVMe начинается с правильных дисков и схемы томов, а уже потом - с «добавим еще ядер».

Диски и RAID: где выигрываются миллисекунды

Чаще всего максимальный эффект дает перенос самых «шумных» операций на NVMe или самые быстрые SSD. Для предсказуемой задержки RAID10 часто выигрывает у RAID5/6: меньше штраф за запись и более стабильное поведение под нагрузкой.

Обычно лучше всего работает такая раскладка:

• NVMe под базу данных и самые активные таблицы или индексы
• отдельный быстрый том под журналы (логи) транзакций
• отдельный том под temp (временные операции и сортировки)
• RAID10 для активных данных, где важна низкая задержка
• отдельное, более «спокойное» хранилище для архивов и редких файлов

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

Разделение ролей и честные ограничители

IOPS не спасут, если уперлись в другое место. Проверьте заранее частые «стопоры»:

• сеть 1 Гбит/с для активного файлового сервиса
• контроллер или режим массива, из-за которого растет очередь
• слишком много виртуальных дисков на одном пуле без приоритизации
• попытка одним сервером одинаково хорошо обслужить ERP и тяжелую файловую «мешанину»
• отсутствие базовых тестов нагрузки перед вводом

Для профиля «максимум IOPS» заранее планируйте отдельные тома под БД, логи и temp, и отдельный ресурс под файлы. После этого подтвердите выбор короткими тестами под ваши операции: массовые проводки, типовые отчеты, одновременное открытие и сохранение документов.

Пошагово: как выбрать конфигурацию под ваши вводные

Если собрать вводные заранее, выбор сервера для ERP и файлового сервиса становится расчетом, а не «угадайкой». Ниже порядок действий, который обычно дает меньше сюрпризов на внедрении.

5 шагов, чтобы держать проект в рамках

• Опишите роли: где приложение ERP, где база данных, где файловые шары. Если все на одном сервере, заранее решите, что можно вынести позже (например, файловый сервис на отдельный узел или NAS).
• Выберите уровень доступности и сценарий отказа. Что для вас нормально при поломке диска, контроллера, блока питания, сетевой карты? Сколько часов простоя допустимо и кто это подтверждает.
• Прикиньте CPU и ОЗУ с запасом. Проверьте ограничения лицензий по ядрам/сокетам и виртуализации, чтобы не переплатить за лишние ядра.
• Спроектируйте дисковую схему по ролям данных. Разделяйте как минимум: системный том, данные БД, логи, пользовательские файлы и место под бэкап/временные выгрузки.
• Определите сеть, резервирование и план тестов. Минимум - дублирование сетевых портов и понятная схема переключения при отказе, плюс замеры до запуска.

Пример, чтобы приземлить выбор

Допустим, у вас 120 пользователей: ERP с SQL-базой и общий файловый ресурс отдела продаж. Если простои критичны, заложите резервирование питания, вентиляторов, дисков и контроллера, а также разнесите журналы БД и файлы пользователей по разным группам дисков. Если главная боль - «тормозит проведение документов», чаще всего выигрывает ускорение хранилища для БД и правильный объем ОЗУ, а не самый мощный процессор.

Перед вводом в эксплуатацию зафиксируйте план проверок:

• замер производительности дисковой подсистемы на чтение/запись и задержку
• тест отказа одного диска и проверка времени восстановления массива
• тест резервного копирования и пробное восстановление (не только «бэкап сделался»)
• проверка сетевого резервирования и реального переключения без ручных действий

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

Сеть и резервное копирование: чтобы сервер не «задыхался»

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

Сеть: разделяйте роли и делайте резервирование

Для ERP и файловых сервисов полезно разложить трафик по ролям: так проще искать узкие места и меньше шанс, что одна задача «съест» все.

Частый базовый набор:

• трафик пользователей и приложений
• администрирование и мониторинг
• резервное копирование и репликация
• хранилище или iSCSI/NFS (если используется)
• резервирование: минимум две линии/две сетевые карты на критичных ролях

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

Резервное копирование: важнее проверка восстановления

Планируйте бэкап вокруг окна, частоты и реальной скорости восстановления. Для ERP обычно важны частые точки восстановления в течение дня и быстрый возврат сервиса. Для файлового сервиса часто критичны версии и защита от шифровальщиков.

Что стоит зафиксировать заранее:

• RPO и RTO простыми словами: сколько данных можно потерять и сколько времени можно быть «вне работы»
• тип бэкапов: полный, инкрементальный, плюс отдельные копии для особо важных баз
• хранение: несколько копий, разнесенных по местам (основное хранилище и отдельная площадка/носитель)
• регулярный тест восстановления: не «файл вернулся», а «ERP стартует и пользователи входят»
• защита от удаления: отдельные учетные записи и неизменяемые политики хранения, где это возможно

Файловые сервисы тоже требуют «гигиены»: понятные права по группам, квоты на папки отделов, расписание антивирусного сканирования так, чтобы оно не совпадало с пиковыми часами.

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

Типовые ошибки при выборе и внедрении

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

Вторая ошибка - ожидать одинаковой скорости от массива, где смешали разные диски. Берут часть SSD «побыстрее» и часть «попроще», собирают в один RAID и получают задержки как у медленного звена. Для БД ERP важно, чтобы группа дисков была однородной по типу, объему и ресурсу записи.

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

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

И наконец, многие откладывают прошивки и тест восстановления из бэкапа «на потом». Обычно это заканчивается сюрпризами при первом инциденте.

Чтобы избежать большинства провалов, держите простой порядок:

• зафиксируйте метрики: CPU/RAM, IOPS, задержки, рост данных, окно бэкапа
• проектируйте дисковые группы под разные типы нагрузки, не смешивайте «разношерстные» диски
• выбирайте RAID исходя из записи и мелких операций, а не только из емкости
• обеспечьте реальное резервирование питания и проверьте его отключением одной линии
• перед вводом обновите прошивки по плану и один раз восстановите систему из бэкапа на тест

Пример: ERP работает «терпимо», но закрытие месяца тормозит. Оказалось, что поставили быстрые CPU, а журналы БД и файлы пользователей сидят в одном RAID с разными дисками. Разделение хранилища и корректный RAID дали больше эффекта, чем замена процессоров.

Приемка партии: чеклист перед вводом

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

До включения

Сначала проверьте, что документы и «железо» совпадают:

• накладные, спецификация, серийные номера, соответствие CPU/ОЗУ/дисков/контроллеров заявленной конфигурации
• осмотр корпуса: нет ли вмятин и перекосов, пломбы и заводские наклейки на месте
• рельсы и крепеж: салазки подходят к стойке, ничего не люфтит, в комплекте есть фиксаторы и винты
• кабели и комплектность: силовые шнуры нужной длины и типа, кабели для управления, заглушки, дополнительные корзины/бэкплейны (если заказывали)
• визуально по начинке: блоки питания одной мощности и класса, вентиляторы на месте, нет «пустых» слотов там, где должны быть модули

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

После включения

Дальше убедитесь, что сервер стартует без ошибок и настройки одинаковые на всех узлах:

• BIOS и прошивки: версии BIOS/контроллера/сетевых карт, единый профиль настроек по шаблону
• CPU и память: видимый объем ОЗУ, частоты, заполнение каналов, отсутствие ошибок ECC в логах
• диски и RAID: SMART без предупреждений, корректный состав массива, наличие hot spare (если предусмотрено), кэш контроллера включен и защищен батареей/суперконденсатором
• быстрые тесты I/O: короткий тест чтения/записи 10-15 минут и контроль, что нет таймаутов или ошибок
• сеть и питание: линк на всех нужных портах, правильная скорость, проверка LACP/VLAN (если используется), тест отказа одного БП

Если принимаете 10-20 серверов, выберите 1-2 для углубленного теста (память и I/O дольше), а остальные проверьте по сокращенному сценарию.

Следующие шаги: пилот, тесты и запуск

Когда профиль выбран, зафиксируйте решение в простой матрице: какая нагрузка ожидается (ERP, файловые шары, бэкапы, рост на 12-24 месяца), какая конфигурация это закрывает (CPU, RAM, RAID/NVMe, сеть), и какими тестами вы это проверяете до запуска.

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

На пилоте измерьте:

• задержки дисковой подсистемы под типовыми операциями ERP и файлами
• IOPS и пропускную способность на чтение/запись (пиковые и средние)
• загрузку CPU и объем занятой памяти в рабочие часы
• окно бэкапа и, главное, время восстановления (RTO) и точку восстановления (RPO)
• поведение при отказе: диск/контроллер/порт (если стенд это допускает)

Параллельно оформите регламент эксплуатации. Достаточно одного документа на 2-3 страницы, но с конкретикой: график обновлений, правила мониторинга и оповещений, минимальный запас запчастей, а также критерии, когда добавлять RAM/диски и как подтверждать потребность.

Если нужна нейтральная проверка и внедрение под ваши вводные, GSE.kz (gse.kz) как производитель и системный интегратор в Казахстане может помочь с проектированием, поставкой, интеграцией и круглосуточной поддержкой, включая план тестов и критерии приемки.

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