Документация Timetta
Общие сведения
Надежность и безопасность
Начало работы
Настройка панели навигации
Регистрация в Timetta
Вход в Timetta
Работа в режиме замещения
Блокировка учетной записи
Приложения Timetta
Личные настройки пользователя
Общие концепции
Объекты системы
Работа с задачами
Использование воркфлоу
Интерфейс
Жизненные циклы и воркфлоу
Мультивалютность
Учёт времени
FAQ
Управление проектами
FAQ
Управление ресурсами
FAQ
Управление финансами
FAQ
Управление затратами
Управление биллингом
Как работает биллинг
Управление задачами
Компоненты
Задача
Концепции
Задачи
Доски
Инструкции
Создание задач
On-premises
Поставка on-premises
Общая схема
Сайзинг
Доступ к докер-реестру
Конфигурация приложений
Создание сертификата
Развертывание в Docker-compose
Порядок обновления
Аналитика
Типы отчётов
Тип отчета «Центры затрат проектов»
Тип отчёта «Акты»
Тип отчёта «Баланс отсутствий»
Тип отчёта «Бронирование»
Тип отчёта «Биллинг»
Тип отчёта «Версии проектов»
Тип отчёта «Задачи»
Тип отчёта «Задачи проектов»
Тип отчёта «Затраты»
Тип отчёта «Заявки на затраты»
Тип отчёта «Заявки на отсутствия»
Тип отчёта «История ставок пользователей»
Тип отчёта «Запросы на ресурсы»
Тип отчёта «Навыки пользователей»
Тип отчёта «Пользователи»
Тип отчёта «Проводки»
Тип отчёта «Ресурсный план»
Тип отчёта «Проекты»
Тип отчёта «Сертификаты пользователей»
Тип отчёта «Счета»
Тип отчёта «Счета (строки)»
Тип отчёта «Таймшиты»
Тип отчёта «Таймшиты детально»
Тип отчёта «Финансы»
Использование отчётов
Группировка и суммирование данных источника
Группировка данных в отчете
Типы виджетов
Общие отчёты и шаблоны
Настройка отчёта
Пользовательские настройки отчёта
Вычисляемые поля
Выражения вычисляемых полей
Использование панелей мониторинга
Публикация панелей
Фильтры источников данных
Настройка и администрирование
Типовой порядок настройки системы
API
Общие сведения
Аутентификация
Reporting API
Ограничения
История изменений

Сайзинг

Обновлено: 26.06.2024

Средняя инсталляция Кластер Kubernetes / OKD Кластер PostgreSQL Кластер Redis Кластер шины сообщений Крупная инсталляция Кластер Kubernetes / OKD Кластер PostgreSQL Кластер Redis Кластер шины сообщений Горизонтальное масштабирование

Важно

Требования к оборудованию зависят от профиля использования системы и индивидуальны для каждого абонента. На практике требования могут быть как существенно ниже, так и выше.

Рекомендации ниже являются ориентировочными и усредненными значениями.

Средняя инсталляция

  1. Зарегистрированных пользователей — 200–400.
  2. Пиковое использование — 20–40 пользователей одновременно.

Кластер Kubernetes / OKD

  • Предполагаем, что все контейнеры с компонентами Timetta запускаются в кластере с одной нодой и число подов — 1 на контейнер.
  • Модель CPU: Intel Ice Lake (Xeon Gold 6338).
  • Число vCPU (с доступностью 100%): 2-4.
  • RAM: 16GB.

Примечание

Для отказоустойчивости число подов и хостов можно увеличивать.

Кластер PostgreSQL

  • Модель CPU: Intel Ice Lake (Xeon Gold 6338).
  • Число vCPU (с доступностью 100%): 4.
  • RAM: 16GB.
  • SSD накопители, прирост — 50Gb в год.

Кластер Redis

  • Модель CPU: Intel Ice Lake (Xeon Gold 6338).
  • Число vCPU (с доступностью 100%): 2.
  • RAM: 8-16GB.
  • SSD накопители (постоянное хранилище) 50Gb.

Кластер шины сообщений

  • Модель CPU: Intel Ice Lake (Xeon Gold 6338).
  • Число vCPU (с доступностью 100%): 2.
  • RAM: 8-16GB.

Крупная инсталляция

  1. Зарегистрированных пользователей — 2 000–3 000.
  2. Пиковое использование — 200 пользователей одновременно.

Кластер Kubernetes / OKD

  • Предполагаем, что все контейнеры с компонентами Timetta запускаются в кластере с двумя нодами. Требования к одной ноде. Для контейнера с API запускать 2+ пода.
  • Модель CPU: Intel Ice Lake (Xeon Gold 6338).
  • Число vCPU (с доступностью 100%): 4-8.
  • RAM: 16-32GB.

Кластер PostgreSQL

  • Модель CPU: Intel Ice Lake (Xeon Gold 6338).
  • Число vCPU (с доступностью 100%): 4-8.
  • RAM: 16-32GB.
  • SSD накопители, прирост — ~500Gb в год.
  • 2 инстанса — один для балансировки нагрузки на чтение и построение отчетов.

Примечание

Для отказоустойчивости кластера PostreSQL рекомендуется использовать кворумную репликация (quorum-based synchronous replication) и минимум два инстанса. При этом важно в строках соединения указать оба хоста.

В целях тестирования, отладки и эксплуатации мы используем пуллер соединений Odyssey и все показатели даны для кластера с данным пуллером.

Кластер Redis

  • Модель CPU: Intel Ice Lake (Xeon Gold 6338).
  • Число vCPU (с доступностью 100%): 2.
  • RAM: 16-32GB.
  • SSD накопители (постоянное хранилище) 100Gb.

Кластер шины сообщений

  • Модель CPU: Intel Ice Lake (Xeon Gold 6338).
  • Число vCPU (с доступностью 100%): 2.
  • RAM: 8-16GB.

Примечание

Для отказоустойчивости кластеры Redis и шины сообщений расширить до двух и более хостов. В настоящее время нагрузка на эти компоненты незначительная.

Горизонтальное масштабирование

  1. Все компоненты Timetta — stateless и могут быть горизонтально масштабированы. Таким образом для масштабирования можно использовать более число нод и большее число подов.
  2. Прежде всего рекомендуется увеличивать число контейнеров для API (ввиду обработки большого числа относительно простых запросов).
  3. Reporting API часто обрабатывает «сложные» запросы и увеличение числа контейнеров не ведет к росту производительности.
Предыдущая
 Общая схема
Следующая
Доступ к докер-реестру 

Содержание

Средняя инсталляция Кластер Kubernetes / OKD Кластер PostgreSQL Кластер Redis Кластер шины сообщений Крупная инсталляция Кластер Kubernetes / OKD Кластер PostgreSQL Кластер Redis Кластер шины сообщений Горизонтальное масштабирование
Ничего не найдено

Перейти на русскую версию?