Расчёт сайзинга на примере простой системы (WS)
опубликовано: ⏰ 5Год назад я писал статью про Расчёт сайзинга на примере простой системы (CLI). Это схожая статья, но с использованием веб-сервиса вместо CLI. В ней немного больше возможностей и более удобный интерфейс, чем работа с XML и консолью.
Введение
Веб-сервис позволяет выполнять те же действия, что и CLI, но с более удобным интерфейсом. Движок расчёта у них общий, поэтому разница в основном только редактировании модели инфраструктуры.
В этом примере я покажу, как создать проект, добавить в него элементы, выполнить расчёт сайзинга.
Проект
Для начала необходимо создать проект, в котором будут расположены все основные элементы для планирования. По аналогии с прошлым примером для CLI создам проект ACME Systems. После создания его необходимо выбрать, чтобы стали доступны дополнительные элементы рабочей области проекта. Ниже пример некоторых экранов.
Окружения
Когда проект создан, необходимо создать окружения. О каких окружениях идёт речь? Это могут быть: dev, test, staging, prod. В данном примере я создам 3 окружения: test, uat, prod. Далее, в основном, буду использовать примеры только для prod, чтобы не увеличивать количество шагов.
Дополнительно потребуются системы к которым будут принадлежать сервисы. Создавать несколько не обязательно, может быть только одна для небольшого проекта. В данном примере я создам 2 системы:
Infra Services– всё что связано с инфраструктурой: наблюдаемость, сетевые файловые системы и т.д.App System– всё, что связано с приложениями.
Сервисы
После того как созданы системы, можно создавать сервисы. Сервисы создаются в рамках систем, что позволяет сгруппировать их по логическим блокам. Это удобно при работе с большим количеством сервисов.
Каждый из сервисов это шаблон сервиса для развёртывания, т.е. если нужен кластер, то не обязательно на каждый экземпляр отдельный сервис. Необходимое количество экземпляров сервиса будет определяться в его шаблоне. Для примера укажу количество реплик по паре штук на сервис.
Для части сервисов будет использоваться балансировщик нагрузки, для распределения запросов по кластеру. А для баз дополнительно включена репликация (master-slave). На скриншотах нет, но для сервиса сбора метрик ещё установлен лимит(retention) в 64GiB, чтобы не переполнить дисковое пространство.
Каждый из сервисов имеет модули, которые описывают его структуру. Это могут быть REST API ендпоинты, модули баз данных, модули веб-интерфейса и т.д. Модули могут быть как общими, так и уникальными для конкретного сервиса. Все последующие потоки данных в системе будут описываться через модули сервисов.
Итоговый список сервисов под разные окружения ниже на скриншоте.
Потоки данных
Теперь необходимо описать потоки данных, которые и будут генерировать полезную нагрузку на основе которой рассчитываются метрики. В данном случае это будут потоки чтения и записи во фронтенд, бэкенд и базу данных.
В примере ниже показаны потоки чтения и записи в фронтенд, бэкенд и базу данных. Основная нагрузка на чтение: 1К RPS, а запись 1 в минуту.
Также для примера добавлю пару потоков получения метрик и логов с фронтенда.
Резервное копирование
Резервирование, также как и в прошлом примере, на каждое 2 число месяца для базы и в дополнение для хранилища метрик.
Прогноз нагрузки
На этом этапе есть всё необходимое для создания прогноза нагрузки. Он будет основываться на ранее описанных потоках данных и резервных копиях.
Количество создаваемых прогнозов не ограничено и может быть как один, так и несколько с возможностью переключения между ними. Это позволяет создавать прогнозы для разных сценариев, например, при увеличении нагрузки или при снижении нагрузки. Пример создания прогноза ниже.
После того как прогноз рассчитан, можно посмотреть процесс выполнения в журнале. Также можно выбрать его в качестве основного для дальнейшего планирования оборудования и посмотреть его метрики.
Метрики рассчитываются по модулям сервисов, что позволяет оценить, какие из них наиболее нагружены. В большинстве случаев это избыточно, поэтому в отчёте модули скрыты по умолчанию и показаны суммарные метрики по сервисам и системам.
Дополнительно метрики появятся в ранее созданных сервисах и могут быть редактированы при необходимости.
Создание сервера
Далее, если необходимо распределение сервисов по серверам, необходимо их создать.
Серверы могут создаваться на основе шаблонов или полностью вручную. В примере ниже используется готовый из tekBlueprint.kbase – kb@main://hardware-server/enterprise:hp-dl360:1.0:gen10-8sff, чтобы не заполнять самому. После планирования компоненты сервера станут доступными для редактирования. По сути, на данном этапе это шаблон сервера.
Также укажу, что нужно 2 юнита, они будут созданы автоматически.
Далее необходимо запустить планирование сервисов. Они могут быть добавлены на сервер вручную, либо автоматически при создании плана. В данном примере, сервисы будут добавлены автоматически.
После того как план создан, его можно выбрать в качестве основного и отредактировать при необходимости. В списке серверов видно, что их стало два (units=2) и сервисы распределены между ними примерно одинаково.
Заключение
Ещё остался один шаг – генерация документации по созданным прогнозам и планам, об этом будет позже.