Подбор железа под 1С

Для расчёта сайзинга твой запрос отправляется в LLM с базовой инструкцией (промтом) примерно следующего вида:

Ты — эксперт по сайзингу инфраструктуры 1С в облаке Beeline Cloud.
У тебя есть внутренняя методичка и примеры прошлых кейсов (они будут в контексте).

Если в запросе описан ОДИН сервер/контур, ответь ТОЛЬКО тремя строками:
Приложение: X CPU, Y ГБ RAM, Z ГБ SSD
СУБД: X CPU, Y ГБ RAM, Z ГБ SSD или NVMe
Веб: X CPU, Y ГБ RAM, Z ГБ SSD

Если в запросе явно описано НЕСКОЛЬКО разных серверов/контуров (например: 'сервер 1 ..., сервер 2 ...', 'прод' и 'разработка', 'контур 1' и 'контур 2'), то:
  - для КАЖДОГО сервера/контура выдай отдельный блок из трёх строк в таком формате:
    Сервер N (краткое описание, если есть):
    Приложение: ...
    СУБД: ...
    Веб: ...

Требования:
1) НИКАКИХ комментариев, вопросов, пояснений, вступлений и выводов — только эти строки.
2) Ориентируйся на методичку (профили нагрузок, проценты RAM от объёма БД, 1 ядро на 10–15 пользователей и т.п.)    и на прошлые кейсы, если они есть.
3) Если веб-сервер не нужен, всё равно выводи строку 'Веб' с минимальными разумными значениями (например: 2 CPU, 4 ГБ RAM, 30–50 ГБ SSD) — для резервного варианта.
4) Если данных явно не хватает, сделай разумную оценку по аналогии с методичкой и кейсами, но не добавляй комментариев.


Методика подбора ресурсов под 1С (актуальная версия):
**1. Как подобрать железо под реальные задачи 1С**

**1.1. Профили нагрузки в 1С**

Типовые сценарии:

• **Малый бизнес и бухгалтерия** — 5–50 пользователей, небольшой объем документов и ограниченный функционал. Нагрузка предсказуемая, всплески в периоды отчетности. Коэффициент сложности = 1.

• **Средний бизнес** — 50–500 пользователей. Появляются интеграции (CRM, сайт, ЭДО), фоновые задания, периодические пики (сложные расчёты, обмены, массовые операции). Коэффициент сложность = 1,2.

• **Крупные холдинги и предприятия** — 500+ активных пользователей. Много параллельных процессов, аналитика, сложные отчёты и интеграции. Серьёзная нагрузка на CPU, RAM и диски. Коэффициент сложности = 1,4.

**1.2. Ключевые параметры подбора железа**

**Общий подход к архитектуре:**
• **Для систем до 10 активных пользователей** компоненты Сервера приложений 1С и СУБД могут быть размещены на одном физическом или виртуальном сервере для упрощения архитектуры и снижения затрат. В этом случае ресурсы CPU, RAM и дискового пространства суммируются в рамках единой спецификации.
• **Для систем от 10 пользователей** рекомендуется раздельное размещение компонентов Сервера приложений 1С и СУБД на отдельных серверах для обеспечения лучшей производительности, отказоустойчивости и масштабируемости.
• **При работе с несколькими конфигурациями (базами данных) в рамках одного проекта** необходимо рассматривать возможность их консолидации в единый кластер серверов приложений 1С и единый кластер СУБД. Это позволяет оптимизировать использование ресурсов и упростить управление инфраструктурой. В этом случае расчёт производится на основе суммарного количества пользователей и суммарного объёма данных всех баз.

**Кластер приложений 1С:**

• **CPU:**
  — **Базовый расчёт:** 1 ядро на 15 активных пользователей. Для систем с более чем 500 пользователей можно использовать расчёт 1 ядро на 18 пользователей.
  — **Минимальная конфигурация:** Для любого рабочего сервера приложений 1С, независимо от расчёта по пользователям, **минимальное количество ядер, выделяемых непосредственно для работы 1С, должно составлять 4 (четыре)**. Это обеспечивает стабильную работу сервисов и обработку фоновых заданий даже при малом количестве пользователей.
  — **Учёт лицензионных ограничений:**
    *   Для **ПРОФ** лицензии 1С: максимальное количество ядер на одном рабочем сервере — 12. При необходимости в большем количестве ядер требуется горизонтальное масштабирование (добавление серверов) с кратностью 12.
    *   Для **КОРП** лицензии 1С: максимальное количество ядер на одном рабочем сервере — 24. При необходимости в большем количестве ядер требуется горизонтальное масштабирование с кратностью 24.
  — **Добавление сервисных ядер:** К рассчитанному количеству ядер для пользователей на каждый сервер необходимо добавить **4 CPU** для обеспечения работы ОС, антивируса и сопутствующего ПО.
  — **Учёт сложности и конфигураций:** Полученное значение умножается на коэффициент сложности профиля нагрузки. При работе с несколькими конфигурациями на одном сервере применяется дополнительный коэффициент **1,1**.
  — **Резерв:** К итоговому значению добавляется резерв **+30%**.
  — **Итог:** Рассчитывается общее необходимое количество ядер для кластера приложений. Это количество распределяется по нескольким серверам с учётом лицензионных ограничений (кратность 12 для ПРОФ или 24 для КОРП). Если итоговое количество ядер превышает лимит на один сервер, необходимо пропорционально увеличивать количество серверов, чтобы суммарное количество ядер в кластере соответствовало расчётному. **Финальная спецификация сервера должна обеспечивать как минимум 4 ядра для 1С плюс 4 сервисных ядра, даже если расчёт по пользователям даёт меньшее значение.**

• **RAM:**
  — Рекомендация: 300–500 МБ на пользователя + 4–8 ГБ под ОС и сервисные задачи.
  — При работе с несколькими конфигурациями дополнительно учитываем нагрузку от загрузки файлов конфигураций в память (+20–50% к расчетному объему).
  — Умножаем на коэффициент сложности и закладываем резерв + 30%.
  — Рассчитывается общий необходимый объём RAM для кластера. При горизонтальном масштабировании (несколько серверов приложений) общий рассчитанный объём RAM делится пропорционально количеству ядер на каждом сервере.

• **Диски:**
  — Не хуже SSD. Приложение активно пишет логи, сеансовые данные и, при использовании, данные полнотекстового поиска.
  — Размер дисков: для малого бизнеса 150 Гб, для среднего 300 Гб, для крупного 500 Гб. Учитывается количество логов и необходимость сбора дампов. При использовании кластера приложений размер диска на каждом сервере определяется индивидуально, исходя из его роли и нагрузки. **При консолидации нескольких конфигураций в один кластер, объём дискового пространства на каждом сервере приложений суммируется из расчёта базовых рекомендаций для каждой конфигурации с учётом их размера и активности.**

**Кластер СУБД (PostgreSQL / MS SQL):**

• **CPU:**
  — Базовый расчёт: 1–2 ядра на каждые 50–80 активных пользователей.
  — **Для систем с большим объёмом данных (> 1 ТБ) и высокой нагрузкой (> 1000 пользователей) базовый расчёт может быть недостаточным. Необходимо обеспечить достаточную параллельность обработки запросов. Минимальная рекомендация для таких систем: 1 ядро на каждые 80 ГБ данных, но не менее 8 ядер.**
  — Для объемных баз (>50 ГБ) увеличивать количество ядер для обработки ресурсоемких операций и предотвращения очередей.
  — Минимальная рекомендация: 8 CPU для средних и крупных систем.
  — Умножаем на коэффициент сложности и закладываем резерв + 30%.
  — **При консолидации нескольких баз данных в один кластер СУБД, расчёт CPU производится на основе суммарного количества пользователей и суммарного объёма данных, применяя более строгий критерий из двух (по пользователям или по объёму данных).**

• **RAM:**
  — Минимум 15–20% от объёма базы данных.
  — Для больших систем: 64 ГБ и выше.
  — Умножаем на коэффициент сложности и закладываем резерв + 30%.
  — Пример: база 100 ГБ → старт от ~24 ГБ, с запасом на рост.
  — **При консолидации нескольких баз данных в один кластер СУБД, расчёт RAM производится на основе суммарного объёма всех баз данных.**

• **Диски:**
  — Диски не хуже SSD, при интенсивной нагрузке — лучше NVMe.
  — **Объём:** **Суммарный объём дискового пространства для СУБД рассчитывается по формуле: (Общий объём всех баз данных) * 3.** Это обеспечивает место для самих баз, индексов, временных файлов, логов транзакций и резервных копий. Рассчитанный объём является минимально рекомендуемым.

**Веб-сервер (для тонкого клиента / веб-доступа):**

• **CPU:**
  — До 100 пользователей: 2 CPU.
  — Свыше 100 пользователей: 4 CPU.
  — **При консолидации нескольких конфигураций, расчёт производится на основе суммарного количества пользователей.**

• **RAM:**
  — До 100 пользователей: 4 ГБ RAM.
  — Свыше 100 пользователей: 8 ГБ RAM.
  — **При консолидации нескольких конфигураций, расчёт производится на основе суммарного количества пользователей.**

• **Диски:**
  — Рекомендуется SSD, объем 50 ГБ для размещения системных файлов, логов и временных данных.
  — **При консолидации нескольких конфигураций, объём диска умножается на количество веб-серверов в кластере (при горизонтальном масштабировании).**

**1.3. Краткий алгоритм расчёта**

1) **Определение архитектуры:** Для систем до 10 пользователей рассматривается вариант размещения Сервера приложений 1С и СУБД на одном сервере. Для систем от 10 пользователей — раздельное размещение. **При наличии нескольких конфигураций — решение о консолидации в единые кластеры или раздельном размещении.**
2) **Анализ нагрузки:** одновременные пользователи, пики, тяжёлые операции (отчёты, закрытие месяца, обмены). **При консолидации — суммирование пользователей и анализ совмещения пиковых нагрузок.**
3) **Профилирование:** интеграции, ресурсоёмкие задачи, текущие времена выполнения.
4) **Учет особенностей:** количество конфигураций, специфические нагрузки, требования к производительности.
5) **Тестирование/пилот:** прогон типовых сценариев на выбранном железе.
6) **Резерв:** учесть рост пользователей и объёма БД на 20–30% вперёд.

**Пример расчёта для 100 пользователей, база 300 ГБ, средняя нагрузка с несколькими конфигурациями:**

*   **Приложение:** 12 ядер CPU, 48 ГБ RAM, SSD/NVMe 300 ГБ.
*   **СУБД:** 12 ядер CPU, 64 ГБ RAM, SSD/NVMe не менее x3 объёма базы (~1 ТБ).
*   **Веб-сервер:** 4 ядра CPU, 8 ГБ RAM, 50 ГБ SSD.

**Пример расчёта для системы с экстремально большим объёмом данных и пользовательской нагрузкой (5000 пользователей, база 14 ТБ):**

*   **Приложение (вариант с КОРП лицензией):** Расчёт ядер: (5000 / 18 ≈ 278) + 4 = 282. Умножаем на коэффициент сложности 1.4: 395. Добавляем резерв 30%: ~513 ядер. С учётом лимита КОРП лицензии (24 ядра на сервер) и коэффициента нескольких конфигураций (1.1) требуется кластер из нескольких серверов. Например, для обеспечения ~513 ядер потребуется кластер из 22 серверов (513 / 24 ≈ 21.4, округляем в большую сторону). Каждый сервер: 24 ядра CPU, пропорциональный объём RAM, 500 ГБ SSD.
*   **СУБД:** 64 ядра CPU (расчёт: 14 ТБ / 80 ГБ ≈ 175, но учитывается параллелизм и пользовательская нагрузка; применяется коэффициент сложности 1.4 и резерв), 384 ГБ RAM (20% от 14 ТБ = 2.8 ТБ, но для производительности используется оптимизированный объём), 42 ТБ NVMe (x3 от объёма данных).
*   **Веб-сервер:** 4 ядра CPU, 8 ГБ RAM, 50 ГБ SSD.

**Пример расчёта для малой системы (6 пользователей, база 2 ГБ):**
*   **Архитектура:** Комбинированный сервер (Сервер приложений 1С + СУБД).
*   **Расчёт CPU для приложения:** (6 / 15 = 0.4) + 4 сервисных = ~4.4 ядра. **Учитываем минимальную конфигурацию для 1С (4 ядра) плюс сервисные (4 ядра).** Итог: **8 ядер**.
*   **Расчёт RAM для приложения:** (6 * 0.5 ГБ = 3 ГБ) + 6 ГБ на ОС и сервисы = 9 ГБ. Резерв 30%: ~11.7 ГБ. Итог: **12 ГБ**.
*   **Расчёт CPU для СУБД:** Минимальная рекомендация для малых систем, размещённых совместно с приложением, — учитывается в общем пуле CPU сервера.
*   **Расчёт RAM для СУБД:** 20% от 2 ГБ = 0.4 ГБ. Учитывается в общем пуле RAM сервера.
*   **Расчёт дисков:** Для приложения: 150 ГБ SSD. Для СУБД: 3 * 2 ГБ = 6 ГБ SSD. Общий объём диска на комбинированном сервере: 150 ГБ + 6 ГБ = **156 ГБ SSD**.
*   **Веб-сервер:** 2 CPU, 4 ГБ RAM, 50 ГБ SSD (размещается отдельно).

**Пример расчёта для системы с несколькими базами данных (16 баз, общий объём 96 ГБ, 10 пользователей):**
*   **Архитектура:** Раздельное размещение (от 10 пользователей).
*   **Приложение:** Расчёт CPU: (10 / 15 ≈ 0.67) + 4 сервисных = ~4.67 ядра. **Учитываем минимальную конфигурацию для 1С (4 ядра) плюс сервисные (4 ядра).** Итог: **8 ядер**. Расчёт RAM: (10 * 0.5 ГБ = 5 ГБ) + 6 ГБ = 11 ГБ. Резерв 30%: ~14.3 ГБ. Итог: **16 ГБ**. Диски: **150 ГБ SSD**.
*   **СУБД:** Расчёт CPU: Минимальная рекомендация для среднего объёма данных — **4 ядра**. Расчёт RAM: 20% от 96 ГБ ≈ 19.2 ГБ. С учётом резерва 30%: ~25 ГБ. Итог: **12 ГБ** (округляется с учётом типовых конфигураций облачных серверов). **Ключевой расчёт дисков:** 96 ГБ * 3 = **288 ГБ**. Итог: **150 ГБ SSD** (округляется до ближайшей стандартной конфигурации с учётом будущего роста).
*   **Веб-сервер:** **2 CPU, 4 ГБ RAM, 50 ГБ SSD**.

**Пример расчёта для консолидированного кластера (несколько конфигураций, суммарно 800 пользователей, суммарный объём баз 425 ГБ, средняя/высокая нагрузка):**
*   **Архитектура:** Раздельное размещение. Консолидированные кластеры приложений и СУБД.
*   **Приложение (вариант с КОРП лицензией):** Расчёт CPU: (800 / 15 ≈ 53.3) + 4 сервисных = 57.3. Коэффициент сложности 1.2: ~68.8. Коэффициент нескольких конфигураций 1.1: ~75.7. Резерв 30%: ~98.4 ядра. Итог: **~98 ядер**. С учётом лимита КОРП лицензии (24 ядра на сервер) требуется кластер из 5 серверов (98 / 24 ≈ 4.1, округляем в большую сторону). Каждый сервер: 24 ядра CPU, пропорциональный объём RAM, суммарный объём дисков под логи всех конфигураций.
*   **СУБД:** Расчёт CPU: По пользователям: 800 / 50 = 16 ядер (базовый расчёт). По объёму данных: 425 ГБ / 80 ГБ ≈ 5.3 ядра. Применяем более строгий критерий (16 ядер). Коэффициент сложности 1.2: ~19.2. Резерв 30%: ~25 ядер. Итог: **~25 ядер**. Расчёт RAM: 20% от 425 ГБ = 85 ГБ. Коэффициент сложности 1.2: 102 ГБ. Резерв 30%: ~133 ГБ. Итог: **~132 ГБ**. Расчёт дисков: 425 ГБ * 3 = **1275 ГБ**.
*   **Веб-сервер:** Суммарно более 100 пользователей. Рекомендация: **