PetClinic перенесли с WildFly на WildBoss Pro без изменений исходного кода. После развёртывания WAR-архива приложение добавляло клиентов и обращалось к базе данных без сбоев. Такой результат показала демонстрация, которую описало издание OSP.
Для ИТ-руководителя вывод пока узкий: совместимое Java-приложение можно вынести в пилот, не меняя код заранее. Но демонстрация не доказывает, что промышленная система сохранит прежнюю производительность, а серверы не потребуют апгрейда.
PetClinic подтвердил совместимость, но не производительность
WildBoss Pro построен на базе WildFly 26. По данным TAdviser, продукт реализует спецификацию Jakarta Enterprise Edition, также известную как Java EE. Поэтому перенос приложения с близкой версии WildFly без переписывания кода выглядит закономерно.
Демонстрация подтвердила три вещи:
- WAR-архив развернулся на WildBoss Pro;
- исходный код PetClinic менять не пришлось;
- приложение продолжило добавлять клиентов и работать с базой данных.
Этого достаточно, чтобы запланировать проверку собственного приложения. Для решения о серверном парке данных мало.
В описании OSP названы этапы переноса и проверенные операции PetClinic. Параметры стенда, версия исходного WildFly, профиль нагрузки и число одновременных пользователей там не указаны. Задержка, пропускная способность и потребление ресурсов также не входят в опубликованные результаты. Значит, демонстрация подтверждает функциональную совместимость PetClinic, но не позволяет сравнить производительность двух платформ.
Заявления о WebSphere и GlassFish ещё предстоит проверить
TAdviser указывает, что на WildBoss Pro можно переносить приложения с WildFly, IBM WebSphere Application Server и Oracle GlassFish Server. Показанный опыт относится только к PetClinic на WildFly.
Корпоративное приложение может использовать очереди сообщений, собственные модули безопасности, кластерные сессии, внешнюю аутентификацию и распределённые транзакции. Описание демонстрации подтверждает добавление клиентов и работу с базой, но не даёт результатов проверки этих механизмов. Считать их совместимыми по тесту PetClinic нельзя.
Поэтому тест не подтверждает перенос с любой западной платформы без доработок. Для приложения на WebSphere или GlassFish сначала разбери зависимости, затем проведи функциональный пилот. Покупать под него новые серверы до проверки рано.
Смена сервера приложений сама по себе не требует нового железа
TAdviser и каталог совместимости АРПП указывают, что WildBoss Pro работает на разных аппаратных платформах. OSP перечисляет поддерживаемые российские операционные системы: Astra Linux, РЕД ОС и Alt Linux.
Если нынешние узлы поддерживают выбранную ОС, начинай миграцию на них. Название нового сервера приложений ничего не говорит о потреблении процессора, памяти или IOPS.
Для виртуального развёртывания сначала сопоставь ресурсы WildBoss Pro с остальными ВМ на хосте. Отдельно проверь подходящие узлы для виртуальной нагрузки: запас считают по фактической загрузке всех машин, а не только нового сервера приложений.
Решение о замене принимай после замеров. Если прежний узел выдерживает целевую нагрузку с допустимой задержкой и резервом на отказ, оставляй его. Если тест упирается в одно ядро, память или хранилище, меняй ограничивающий компонент либо весь узел — смотря что позволяет платформа.
Реестр российского ПО не заменяет сертификат ФСТЭК
Каталог совместимости АРПП подтверждает: WildBoss Pro внесён в Единый реестр российского ПО под номером 28551. Решение датировано 23 июня 2025 года.
OSP и TAdviser сообщают, что продукт готовят к сертификации ФСТЭК. Сведений о выданном сертификате в этих публикациях нет.
Для организации, где сертификат обязателен, его отсутствие останавливает проект независимо от результатов нагрузочного теста. Реестровая запись подтверждает происхождение ПО, но не закрывает требования к защите информации. Для госсектора и медицины программные и аппаратные ограничения нужно сверять вместе — они разобраны в материале о серверной базе для регулируемых организаций.
Что проверить на пилоте
Возьми профиль нагрузки действующей системы: те же бизнес-операции, число параллельных сессий и объём данных. Сравни старую и новую платформы на одинаковом железе. Иначе ты не отделишь влияние WildBoss Pro от разницы между стендами.
Пилот должен ответить на четыре вопроса:
- разворачивается ли приложение без изменения кода;
- проходят ли транзакции, интеграции, аутентификация и очереди;
- сохраняются ли задержка и пропускная способность под рабочей нагрузкой;
- восстанавливается ли сервис после отказа процесса или узла.
PetClinic закрыл только часть первого и второго пунктов. Демонстрация подтвердила развёртывание, добавление клиентов и работу с базой данных.
Спецификация под задачу
Публикации OSP и TAdviser не дают результатов нагрузочного теста, по которым можно рассчитать промышленную конфигурацию WildBoss Pro. Поэтому ниже — стартовая платформа для пилота с явно заданной нагрузкой, а не характеристика продукта.
Считаем корпоративное Java-приложение на 200 одновременных пользователей. Для WildBoss Pro выделяем две ВМ по 8 vCPU и 32 ГБ памяти: одна обслуживает нагрузку, вторая нужна для проверки отказа и обновления. База данных работает на отдельном узле. Переподписку процессора принимаем 2:1.
Одна ВМ с 8 vCPU требует 4 физических ядра при переподписке 2:1. Две ВМ дают 8 ядер. Добавляем 4 ядра гипервизору и соседним служебным процессам, затем резервируем 25%: (8 + 4) × 1,25 = 15. Получается 16 физических ядер на узел.
Две ВМ займут 64 ГБ памяти. Гипервизору и системным службам оставляем 16 ГБ, затем добавляем 25% резерва: (64 + 16) × 1,25 = 100 ГБ. Ближайший типовой объём — 128 ГБ ECC RDIMM.
Стартовая конфигурация узла:
- процессор — 16 физических ядер с высокой частотой на ядро;
- память — 128 ГБ ECC RDIMM;
- накопители — два enterprise SSD по 960 ГБ в RAID1 под ОС, образы ВМ, журналы и временные данные;
- сеть — два порта 10 Гбит/с, разнесённые по разным адаптерам или контроллерам;
- питание — два блока с горячей заменой;
- корпус — от 2U, с двумя свободными отсеками и свободными слотами памяти.
Эта конфигурация не доказывает, что WildBoss Pro обслужит 200 пользователей. Она даёт стенд, на котором можно провести воспроизводимый тест и увидеть дефицит ресурсов.
Если на хосте будет только одна ВМ WildBoss Pro, для начала пилота хватит 64 ГБ памяти. Если база данных живёт на том же узле, расчёт не подходит: память, ядра и диски придётся пересчитать с учётом нагрузки СУБД. При двух производственных узлах каждый должен выдерживать рабочую нагрузку в одиночку. Иначе после отказа одного хоста резервирование превратится в перегрузку.
Компромисс прямой. Два узла, сеть 10 Гбит/с и резервные блоки питания увеличивают стоимость пилота, зато позволяют проверить отказ и схему дальнейшей эксплуатации. Один узел дешевле, но подтверждает только запуск приложения.
Когда сохранять серверы, а когда пересчитывать парк
Сохраняй нынешние узлы, если приложение разворачивается без правок, проходит бизнес-операции и выдерживает прежнюю нагрузку с теми же пределами по задержке. Бюджет тогда уйдёт на тестирование, резервирование и поддержку: «Интерпроком» заявляет сопровождение WildBoss Pro в режиме 24/7.
Если не проходят интеграции или приложению нужна доработка, останови закупку железа. Сначала оцени изменения в коде и архитектуре: после них профиль нагрузки может измениться.
Если функции работают, но тест упирается в ресурсы, меняй то, на что указали замеры. Постоянная загрузка процессора говорит о нехватке вычислительного запаса, рост потребления памяти — о нехватке RDIMM, высокая задержка хранилища — о проблеме в дисковой подсистеме. Сам переход на WildBoss Pro не требует обновлять серверный парк.
