CAPACITY PLANNER, ПРОГНОЗ РЕСУРСОВ И РАЗМЕЩЕНИЕ РОЛЕЙ Продукт: Control Center Версия: [ТРЕБУЕТ УТОЧНЕНИЯ: VERSION] Тип документа: Руководство по capacity management Последнее обновление: 09.09.2026 ЧТО МЫ НАСТРОИМ Инструкция описывает использование Capacity Planner для оценки CPU, RAM, storage, производительности дисков, сети, баз данных, текущей и исторической нагрузки, тенденций роста, требований ролей и Market-модулей, выявления bottleneck и what-if моделирования. КЛЮЧЕВОЙ ПРИНЦИП Capacity Planner дает рекомендации на основании наблюдаемых данных и известных требований, но не заменяет инженерную проверку fault domains, SLA, RPO/RTO и внешних ограничений. Не существует одного универсального процента CPU/RAM, который подходит всем ролям. ПРЕДВАРИТЕЛЬНЫЕ ТРЕБОВАНИЯ Требование | Значение Monitoring | Сбор метрик работает Freshness | Данные актуальны История | Достаточный период для оценки типичной/пиковой нагрузки Inventory | CPU/RAM/storage/network обнаружены Роли/модули | Известны размещение и resource profiles HA | Известна требуемая отказоустойчивая модель Права | Read для capacity; отдельные права для placement Change АРХИТЕКТУРА Telemetry + Inventory + Role requirements + Growth trends | v Capacity Planner / | \ Bottleneck Forecast What-if \ | / v Placement/Scale recommendation ИСТОЧНИКИ ДАННЫХ Planner должен учитывать, где доступны: - CPU utilization/pressure; - RAM usage/pressure; - storage capacity; - disk throughput, IOPS и latency; - network throughput/errors/latency; - database size/load/connection or transaction pressure согласно поддерживаемой telemetry; - текущую и историческую нагрузку; - пиковые интервалы; - тенденции роста; - требования установленных ролей; - требования Market-модулей; - ограничения fault domains/HA. [ТРЕБУЕТ УТОЧНЕНИЯ: точный набор метрик и алгоритм confidence]. ПЕРЕД НАЧАЛОМ 1. Устраните Stale/Unknown telemetry. 2. Не принимайте capacity-решение только по нескольким минутам наблюдения, если workload цикличен. 3. Отметьте периоды резервного копирования, обновлений, batch jobs и других известных пиков. 4. Зафиксируйте прогноз роста: пользователи, endpoints, объем данных, трафик, модули. 5. Для HA оценивайте сценарий потери узла, а не только нормальную работу. Шаг 1. Открытие Capacity Planner Откройте [Уточнить название элемента интерфейса Capacity Planner]. Выберите scope: - весь Control Center; - site/cluster; - конкретный node; - роль; - Market module; - другой поддерживаемый объект. Ожидаемый результат: Отображаются текущий capacity, utilization, история и известные ограничения выбранного scope. Шаг 2. Проверка качества данных Перед анализом проверьте: - last sample/freshness; - пропуски telemetry; - длительность исторического окна; - аномальные периоды; - изменение hardware/role placement внутри периода. Если данные неполные, Planner должен явно показывать ограниченную уверенность или отсутствие рекомендации. [ТРЕБУЕТ УТОЧНЕНИЯ: точное отображение confidence]. Шаг 3. Анализ CPU Смотрите одновременно: - среднюю нагрузку; - длительные высокие интервалы; - пики; - распределение по узлам/ролям; - рост во времени. Bottleneck подозревается не по одиночному пику, а по устойчивой корреляции высокой CPU-нагрузки с деградацией workload/queue/latency. Шаг 4. Анализ RAM Проверьте: - рабочий объем RAM; - pressure/swap, если поддерживается; - рост resident/workset по времени; - запас при failover/переносе ролей. Не размещайте новую роль, если после ее расчетного потребления исчезнет запас на отказ другого узла. Шаг 5. Анализ storage capacity Проверьте: - used/free; - темп роста; - прогноз даты достижения организационного safety threshold; - потребление по ролям/данным; - резерв под backup/update/migration. Planner должен выдавать forecast по наблюдаемой тенденции, но резкий будущий импорт данных необходимо моделировать вручную через what-if. Шаг 6. Производительность дисков Capacity в GB/TB не означает достаточную производительность. Проверяйте: - IOPS; - throughput; - latency; - queue/pressure, если доступно; - пики backup/database workloads; - тип storage и разделение конкурирующих ролей. Если роль ограничена disk latency, добавление CPU не решит bottleneck. Шаг 7. Сеть Проверьте: - bandwidth utilization; - packet errors/drops, если доступны; - latency между зависимыми узлами; - направление трафика; - пики replication/backup/PXE/deployment; - запас WAN/LAN links. Для multi-site отдельно учитывайте ограничение WAN и периоды разрыва связи. Шаг 8. Database capacity Для stateful платформенных или модульных БД используйте поддерживаемые показатели: - размер и рост; - latency; - transaction/query pressure; - connection pressure; - replication lag, если применимо; - storage performance. [ТРЕБУЕТ УТОЧНЕНИЯ: точные database metrics, которые экспортирует Planner]. Шаг 9. Выявление bottleneck 1. Выберите период деградации. 2. Сопоставьте Health/Alert с ресурсами. 3. Найдите ресурс, который достиг ограничивающего состояния раньше других. 4. Проверьте корреляцию на нескольких аналогичных периодах. 5. Смоделируйте устранение ограничения. Примеры инженерной логики: - CPU высокий, disk/network нормальны → рассмотреть CPU/placement; - disk latency высокий при умеренном CPU → рассмотреть storage; - RAM pressure + swap → увеличить RAM/переразместить роли; - WAN saturated во время backup → изменить расписание/канал/топологию. Это примеры анализа, а не фиксированные автоматические диагнозы. Шаг 10. What-if: новая роль Создайте scenario: - роль/модуль: ; - целевой узел/узлы; - ожидаемый workload profile; - growth factor; - HA requirement. Проверьте прогноз CPU/RAM/storage/IO/network после placement. Ожидаемый результат: Planner показывает, достаточно ли capacity и какие ограничения станут критическими. Шаг 11. What-if: отказ узла Для HA обязательно моделируйте: `Node unavailable`. Проверьте: - куда переместятся роли; - останется ли quorum; - достаточно ли CPU/RAM; - выдержат ли storage/network дополнительную нагрузку; - какие roles останутся без допустимого placement. Нормальная работа с 30% свободных ресурсов не гарантирует N+1, если при отказе один оставшийся сервер должен принять почти всю нагрузку. Шаг 12. What-if: рост Сценарии: - +% endpoints; - +% data volume; - новый Market-модуль; - дополнительный site; - рост backup retention; - увеличение интенсивности Inventory/PXE/Automation. Используйте организационные прогнозы вместо случайно выбранных процентов. Шаг 13. Рекомендация размещения роли Перед созданием Change проверьте: - recommendation reason; - ресурсный запас; - fault domain; - data locality; - network path; - dependencies; - HA after placement; - planned growth. После выбора placement создайте обычный Change по документу 04, а не изменяйте роль непосредственно из расчетной модели без контроля. Шаг 14. Рекомендации расширения Planner может рекомендовать: - добавить RAM; - увеличить/ускорить storage; - добавить node; - перенести роль; - разделить конфликтующие workloads; - увеличить network capacity; - изменить расписание тяжелых jobs. [ТРЕБУЕТ УТОЧНЕНИЯ: точный каталог рекомендаций и возможность автоматического Change generation]. ПРОВЕРКА CAPACITY - [ ] telemetry fresh; - [ ] историческое окно репрезентативно; - [ ] CPU проанализирован; - [ ] RAM pressure проанализирован; - [ ] storage capacity и growth проверены; - [ ] disk performance проверена; - [ ] network capacity проверена; - [ ] database growth/lag проверены при наличии; - [ ] требования Market modules учтены; - [ ] N+1/failure what-if выполнен для HA; - [ ] growth scenario выполнен; - [ ] placement не нарушает fault domains; - [ ] решение подтверждено фактическим Health после Change. ТИПОВЫЕ ОШИБКИ Симптом | Причина | Проверка | Решение Planner дает нестабильные выводы | мало истории/stale telemetry | freshness/window | собрать репрезентативные данные Много свободного диска, но сервис медленный | IOPS/latency bottleneck | disk performance | ускорить/разнести storage workload После отказа узла перегрузка | capacity считался только для normal state | failure what-if | добавить headroom/node/изменить placement Forecast неожиданно ошибся | был одноразовый импорт/изменился workload | history/events | пересчитать модель с известным будущим событием Роль помещается по RAM, но сеть перегружена | placement оценен по одному ресурсу | network what-if | выбрать другой placement/расширить сеть РЕКОМЕНДАЦИИ ДЛЯ PRODUCTION - пересматривайте capacity регулярно и перед крупными изменениями; - сохраняйте headroom под failure/maintenance; - моделируйте не только рост, но и отказ; - отличайте capacity от performance; - сопоставляйте показатели с Health и пользовательским эффектом; - учитывайте backup, replication, Inventory, PXE и Automation как реальные нагрузки; - проверяйте рекомендации после Change фактическими метриками. ИТОГ Capacity Planner объединяет ресурсы, производительность, историю, рост и требования ролей в единый анализ. Решение о placement или расширении должно проходить через bottleneck analysis и what-if для normal, growth и failure-сценариев, после чего изменение выполняется штатным Change и проверяется фактическим Actual State/Health. ТРЕБУЕТ УТОЧНЕНИЯ ПЕРЕД ПУБЛИКАЦИЕЙ - VERSION; - UI names; - точный metric catalog; - sampling/retention; - confidence model; - forecast algorithm/time horizons; - role/module resource profiles; - database metrics; - recommendation catalog; - automatic Change integration; - supported failure/fault-domain modeling.