В офисной системе на базе 1С:Предприятия, CRM или отраслевого ПО сервер приложений принимает пользовательские запросы и выполняет вычисления, а сервер баз данных хранит информацию и отдает ее по запросу. Эти роли создают разную нагрузку, хотя могут работать как на отдельных физических серверах, так и в виртуальных машинах. Такое разделение определяет требования к оборудованию еще до выбора конкретной модели.
Требования к процессору и оперативной памяти на этой роли отличаются от требований к файловому серверу или серверу баз данных. При проектировании инфраструктуры под серверное приложение эти роли стоит разделить на старте: если сервер приложений и сервер баз данных работают на одном узле, при пиковой нагрузке они конкурируют за процессор и память, и снижение отклика системы сложнее диагностировать — неясно, какая роль уперлась в предел ресурса.
Что такое сервер приложений и чем он отличается от других серверных ролей
Сервер приложений (application server) — серверная роль, которая выполняет код бизнес-логики приложения и промежуточный слой между клиентом и базой данных. Он принимает запросы от клиентских приложений или веб-интерфейса, обрабатывает их согласно логике системы и обращается к серверу баз данных за нужными данными.
Файловый сервер в основном принимает и отдает файлы по протоколам SMB или NFS. Сервер приложений выполняет процессорные вычисления и обрабатывает пользовательские сессии, поэтому его профиль нагрузки отличается. При совместном размещении интенсивный файловый обмен конкурирует с бизнес-логикой за память и системные ресурсы, что усложняет диагностику и подбор оборудования.
Похожая путаница возникает с веб-сервером: он принимает HTTP-запросы и отдает статические или динамические страницы, но не всегда выполняет глубокую бизнес-логику приложения. Сервер приложений и веб-сервер могут стоять на одном физическом узле в небольшой инфраструктуре, но по мере роста нагрузки их разделяют — у веб-слоя и слоя бизнес-логики разный профиль потребления ресурсов.
Какие задачи решает сервер приложений в инфраструктуре компании
Сервер приложений обрабатывает бизнес-логику системы: выполняет расчеты и проверяет права доступа. Обмен данными между модулями также проходит через прикладной слой. Он держит открытые пользовательские сессии, поэтому рост одновременных подключений увеличивает нагрузку на процессор и оперативную память узла.
На платформе 1С:Предприятие сервер приложений в кластерной конфигурации распределяет рабочие процессы между несколькими серверами — это снижает нагрузку на каждый отдельный узел при росте числа пользователей. В Java-стеке и .NET работает похожий принцип: приложение запускается на нескольких экземплярах сервера приложений, а балансировщик распределяет между ними входящие запросы.
Число задач на сервере приложений растет вместе с числом бизнес-процессов, которые обслуживает система: формирование печатных форм и интеграция с внешними сервисами по API. Дополнительную нагрузку добавляет фоновая обработка очередей — она использует процессор независимо от того, сколько пользователей одновременно работает в системе в конкретный момент.
Как распределить роли между сервером приложений и сервером базы данных
Нагрузка на сервер приложений и сервер базы данных отличается по характеру. Сервер приложений зависит в первую очередь от процессора и объема оперативной памяти — здесь идет многопоточная обработка запросов и хранение сессий. Сервер баз данных больше зависит от скорости дисковой подсистемы и объема RAM под кэш: чем быстрее диск отдает данные, тем меньше времени сервер приложений ждет ответа на запрос.
Разносить эти роли по отдельным серверам имеет смысл начиная с определенного числа пользователей: конкуренция за ресурсы на одном узле проявляется в момент пиковой нагрузки, когда вычисления бизнес-логики и запросы к базе данных происходят одновременно. Раздельная архитектура упрощает диагностику: видно, какая роль исчерпала ресурс — процессор сервера приложений или диск сервера базы данных.
На практике разделение ролей выглядит так: компания с ERP-системой на 80 активных пользователей выносит сервер приложений и сервер базы данных на два физических узла, соединенных сетью с низкой задержкой. Такая схема позволяет обновлять или перезагружать сервер приложений без остановки базы данных — обслуживание одной роли не затрагивает вторую.
Типовая конфигурация: процессор, память, диски
Типовая конфигурация сервера приложений под 50-100 одновременных сессий — от 16 физических ядер процессора и 64-128 ГБ оперативной памяти. Точные цифры зависят от платформы: сервер приложений 1С рассчитывают иначе, чем сервер под Java-стек или .NET-приложение, потому что модели обработки запросов и потребление памяти на сессию у них разные.
Дисковая подсистема сервера приложений обычно ограничена конфигурацией NVMe или SSD под операционную систему и кэш самого приложения — без требований к объему хранения, характерных для файлового сервера или системы хранения данных. Ключевой параметр здесь не объем, а скорость отклика диска: она влияет на то, как быстро запускается сервер приложений и восстанавливается работа кластера после перезапуска узла.
Для платформы 1С в кластерной конфигурации отдельно считают память под рабочие процессы и память под менеджер кластера — рост числа пользователей увеличивает в первую очередь потребление рабочими процессами. Для Java-приложений объем кучи JVM зависит от профиля запросов, сборщика мусора и числа процессов. Поэтому память рассчитывают по результатам нагрузочного теста с запасом под операционную систему и пиковые сессии, а не по единому нормативу на процесс.
Горизонтальное масштабирование против вертикального
Горизонтальное масштабирование сервера приложений — это добавление дополнительных узлов с балансировкой нагрузки между ними. Каждый новый сервер приложений берет на себя часть сессий пользователей, а балансировщик распределяет запросы так, чтобы ни один узел не перегружался.
Вертикальное масштабирование чаще используют для сервера базы данных: администраторы увеличивают вычислительные ресурсы одного узла. Дисковую подсистему при необходимости модернизируют отдельно. Для сервера приложений вертикальный апгрейд тоже возможен на старте, но при устойчивом росте числа пользователей горизонтальная схема с несколькими узлами и балансировщиком обходится предсказуемее. Дополнительные узлы часто размещаются на сервере для виртуализации, где каждый экземпляр приложения работает в отдельной виртуальной машине.
Порог перехода к горизонтальной схеме оценивают по загрузке процессора. При пиках до 60-70% вертикальный апгрейд одного сервера остается более простым решением. Устойчивая загрузка выше 70-80% несколько дней подряд уже указывает на необходимость пересчитать конфигурацию и рассмотреть второй узел с балансировщиком.
Как понять, что текущего сервера приложений уже недостаточно
Признак того, что текущей конфигурации сервера приложений не хватает — устойчивая утилизация процессора выше 70-80% на пике рабочего дня и рост времени ответа приложения при том же числе пользователей, что и раньше. Если оба показателя держатся выше порога несколько дней подряд, это повод пересчитать конфигурацию.
Второй сигнал — очередь запросов к серверу приложений растет быстрее, чем успевает обрабатываться, даже когда сервер базы данных отвечает в пределах нормы. В этом случае узкое место находится на уровне сервера приложений, поэтому расширение стоит начинать с процессора и памяти этого узла.
Дополнительный ориентир — доля времени, которое сервер приложений тратит на ожидание ответа от сервера базы данных, а не на собственные вычисления. Если эта доля растет при прежнем числе пользователей, следует проверить базу данных и начинать расширение с того узла, где подтвержден дефицит ресурсов.
Итак, сервер приложений отличается от файлового сервера и сервера баз данных своей ролью: он выполняет бизнес-логику и держит пользовательские сессии. Его конфигурацию рассчитывают прежде всего по процессорной нагрузке и потреблению памяти, отдельно проверяя влияние базы данных и дисковой подсистемы. При росте нагрузки отказоустойчивая виртуализация помогает разместить несколько экземпляров на разных узлах и сократить последствия отказа. Точное число ядер и объем оперативной памяти определяются по платформе, числу пользователей и результатам нагрузочного тестирования.