Подходы к оценке сайзинга

Минимальные требования

Минимальные параметры сервера для работы платформы в односерверном режиме:

  • 4 ядра,

  • 8 GB RAM,

  • 100 GB HDD.

Рекомендуемые параметры сервера для работы платформы в односерверном режиме с БД и файловым хранилищем на сервере:

  • 8+ ядер,

  • 32+ GB RAM,

  • 250+ GB SSD TBW 3500+ TB,

  • 1+ TB HDD/SSD для БД,

  • 1+ TB HDD/SSD для файлового хранилища,

  • RAID.

Таблица производительности

Тестирование нагрузки проводилось на различных процессорах в односерверном и двухсерверном исполнении. Проводились три теста с различным упором: либо на CPS, либо на количество одновременных разговоров, либо на количество одновременных IVR. В каждом них другие два показателя были очевидно ненулевыми, но значительно меньшими, чем пиковые возможные значения.

Результат тестирования различных процессоров был обобщен и сведен к 1 ядру.

Усредненная таблица производительности в расчете на 1 ядро 2.5 GHz:

Упор на количество На одно ядро На сервер 12 ядер по 2.5 GHz

CPS

cps - 6, calls - 25, ivr - 25

cps - 72, calls - 300, ivr - 300

Calls

cps - 0.5, calls - 180, ivr - 0

cps - 6, calls - 2000, ivr - 0

IVR

cps - 0.5, calls - 125, ivr - 125

cps - 6, calls - 1500, ivr - 1500

Подходы к расчету используемых ресурсов

Выделяются три подхода:

  1. Расширение. Постепенно нагружаем, оцениваем фактическое использование ресурсов. Не хватает - добавляем.

  2. Экстраполяция нагрузки. Замеряем затраты, полученные на малом объеме исполняемых процессов в полностью функционирующей системе. Например на 10 операторах. Итог экстраполируем до ожидаемого количества одновременно исполняемых процессов. Например до 1000 операторов.

  3. Экспертная оценка. Опираясь на расчетные показатели для телефонии, применяем коэффициент 3-6 в зависимости от типа резервирования и размера системы.

Подход 1. Расширение

Устанавливаем на 1 сервере, настраиваем функциональность для полноценной работы в продакшене в 1-серверном исполнении. По мере увеличения нагрузки добавляем серверы, конфигурацию распределяем на большее количество серверов.

Начинаем всегда с 1-2-4 серверов в зависимости от типа резервирования и грубо оцениваемой нагрузки. Если загрузка подбирается к 60-70%, выявляем затратные сервисы и выделяем их на отдельные машины. Либо переконфигурируем систему исходя из увеличенного количества серверов.

Преимущественно выделяются наружу:

  • базы данных;

  • микросервисы, обслуживающие медиа-трафик;

  • микросервисы, обслуживающие SIP-сигнализацию;

  • микросервисы, обслуживающие IVR и другие сценарии;

  • микросервисы, обслуживающие модель данных

  • микросервисы веб-серверов

  • микросервисы продуктового слоя

  • микросервисы обслуживания подписок на изменения

Далее, наблюдая за использованием оставшимися микросервисами ресурсов сервера, выявлять лидеров.

Подход 2. Экстраполяция нагрузки

  1. Система настраивается на полную функциональность на заведомо необходимом количестве серверов (том количестве, от которого очевидно не придется отказываться, может быть на одном сервере). Создаются все сценарии, настраиваются все процессы, правила, подключения, интеграции.

  2. На систему переводится часть планируемых процессов или потоков обращений, долю которой можно количественно оценить по отношению к плановой пиковой нагрузке. Так, например, 10%. Подключаются не 1000 операторов, а 100, балансировщиком заводится не весь поток звонков, а только 10%, и т.д.

  3. Замеряется фактическое использование системой ресурсов при обслуживание выделенной части.

  4. Полученное значение экстраполируется до планового исходя из выделенной доли.

  5. Применяется увеличивающий коэффициент для резервирования. От 1.5 до 2.

  6. Применяется увеличивающий пиковый коэффициент для обеспечения неполной загрузки. Коэффициент 1.5 (базовый уровень использования CPU на серверах не должен быть более 70%, без учета возможных точечных пиков).

  7. Рассчитывается необходимое количество соответствующих серверов.

  8. Отдельно рассматривается БД и хранилища архивных данных и файлов.

Здесь важно, выделяя часть процессов, адекватно оценить её долю от общего количества. Каждый из процессов полностью нагруженной системы должен исполняться и быть представлен в измеряемой части.

Не должно допускаться квадратичного (экспоненциального) сокращения нагрузки в измеряемой части относительно полной. Например, сокращение коллекции в 10 раз приводит к сокращению кросс-пересечения в 100 раз, и во столько же раз быстрее отрабатывает запрос с JOIN.

Подход 3. Экспертная оценка

Оценка для телефония может быть построена исходя из показателей, приведенных в таблице.

  1. Грубо оцениваем предполагаемую нагрузку на систему в пике:

    • Сколько одновременных разговоров и каких.

    • Сколько ожидающих в очередях абонентов (вероятно, не больше чем количество внешних транков).

    • Сколько телефонных устройств будет зарегистрировано одновременно и с какой периодичностью будут производить перерегистрацию.

    • Какие процессы обработки данных будут выполняться с какой периодичностью и нагрузкой. Можно перевести в количество компонентов в секунду.

    • Какое количество пользователей будет одновременно подключено к системе.

    • Какие отчеты и дашборды будут строиться одновременно с основной работой.

    • Какой объем разговоров будет записываться и как долго будет храниться.

    • Какое количество доменов будет в системе.

  2. Определяем внешние сервисы.

    • Будет ли подключено внешнее файловое хранилище.

    • Будет ли БД вынесена на внешние серверы.

  3. Определяем тип резервирования исходя из целей.

    • Будет ли инсталляция системы, готовая к выпадению одного сервера. Расчетный коэффициент (N+1)/N, но практически от 1.5 до 2 в зависимости от конфигурации.

    • Будет ли резервирование датацентров (установка на два датацентра). Коэффициент 2.

    • Будут ли формироваться зоны, готовые к выводу из эксплуатации. Коэффициент зависит от числа и размера зон. Грубый коэффициент 2.

  4. Оценка требуемого количества ядер.

    • Исходя из приведенной выше таблицы на основании оцененных показателей по ожидаемой пиковой нагрузке, оценивается необходимое количество ядер.

    • На основании количества ядер оценивается количество соответствующих серверов.

  5. Оценка требуемой дисковой системы.

  6. Оценка требуемой оперативной памяти.

    • Базовая память 32 GB на один сервер используется стандартными процессами телефонии любого масштаба и коллцентром до 100 человек с размещением БД на сервере.

    • На увеличение требований к размеру оперативной памяти работают:

      • Большие БД, сохранящие историю в течение нескольких лет - на тех серверах, где исполняется БД;

      • Наличие процессов построения отчетности по длительным периодам дат - на тех серверах, где исполняется БД;

      • Наличие в модели данных продуктового слоя емких коллекций с кэшированием.

  7. Добавляем запас, уменьшающий загрузку в пиках.

    • усредненная нагрузка на процессор не должна быть более 70%. Коэффициент 1.5. (базовый уровень использования CPU на серверах не должен быть более 70%, без учета возможных точечных пиков).

    • Диски SSD/HDD не должны быть заполнены более чем на 50% (bytes, inodes).

    • Загрузка очереди чтения/записи на HDD диске не должна наблюдаться периодами более 1 секунды, и в общем объеме не должна превышать 1% (неактуально при использовании SSD).

  8. Добавляем запас на схему резервирования. Расчетный коэффициент (N+1/N), где N - расчетное количество серверов, на практике от 1.5 до 2.

  9. При установке БД на серверах кластера добавляем ресурсы на работу БД. (от 2 ядер и 100 GB до 24+ ядер и 1+ TB + RAID)

    • Примерный размер для расчета - 150 MB каждый месяц хранения для домена, содержащего 100 пользователей и 30 тысяч соединений в месяц.

  10. При использовании локального хранилища добавляем ресурсы (SSD/HDD) для его обеспечения.

    • Примерный размер для расчета - 1 минута стерео MP3 - 180 КБ.

    • Дополнительно необходимо оценить и учесть другие коллекции с вложениями:

      • сохраняют ли сценарии что нибудь.

      • настроены ли почтовые ящики и как долго хранятся сообщения.

      • есть ли другие исторические данные с вложениями.

      • производится ли резервное копирование БД средствами системы (даже если на внешнее хранилище).

  11. Применяем коэффициент для продуктового слоя по работе с проектной моделью данных (от 1.1 до 2).

    • коэффициент 1.1 - если продуктовый слой установлен в единственном домене и используется только для просмотра журнала звонков.

    • коэффициент 1.5 - если продуктовый слой установлен во всех доменах при их общем количестве более 20.

    • коэффициент 2.0 - если пользователи массово работают в приложениях, исполняются процессы неголосового обслуживания.

  12. ВКС. Примеры:

    • 1 сервер 8 cores и каналом 1 Gbit/s справляется с обслуживанием:

      • 1 комната на 200 человек, где у всех включены камеры, и до 10 спикеров.

      • 1 комната на 500 человек, где видео/экран и звук транслирует 1 спикер, остальные без камер и микрофонов.

      • 10 комнат по 300 человек, где транслируется только аудио.

      • 100 комнат из 3-5 участников, где у всех включено видео и все являются спикерами.

    • Микширование производится отложенно за счет свободных ресурсов сервера.

  • Персонализация
  • Увеличить шрифт
  • Уменьшить шрифт