Требования к инфраструктуре и рекомендации для Tarantool DB

В этом разделе приведены следующие рекомендации:

• Общие требования и рекомендации
• Рекомендации по топологии Tarantool DB
• Рекомендуемые настройки для больших кластеров
• Расчет дисковой емкости

Рекомендации:

• Лучшие результаты показывают физические сервера.
• Если сделать виртуальные машины очень большими, такие машины будет долго ждать выделения ресурсов гипервизором.
• Если сделать виртуальные машины очень маленькими (под 1—2 экземпляра Tarantool), будет сложно управлять большим количеством виртуальных машин. Расход ресурсов при этом может быть нерациональным.

Количество необходимых роутеров вычисляется:

• в соответствии с производительностью и количеством хранилищ;
• из расчёта 1 роутер на 3—5 хранилищ и минимум 1 роутер на хост.

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

При подборе серверного оборудования заложите отдельно ресурсы под систему и дополнительное ПО.

Требования для одного роутера, TCM и failover-координатора:

• CPU: 1,5 vCPU (x86_64, ARM);
• RAM: 128 МБ;
• HDD: 256 МБ.

Требования для одного хранилища:

• CPU: 2 vCPU (x86_64, ARM);
• RAM: 32 ± 8 ГБ;
• HDD: 2 x RAM.

1. Экземпляры координатора отказоустойчивости (failover coordinator) должны размещаться на разных физических серверах, лучше — в разных центрах обработки данных. При развёртывании в виртуальной среде обязательно использование anti-affinity-правил, запрещающих размещение однотипных компонентов (координаторов отказоустойчивости, экземпляров хранилища конфигурации) на одном физическом хосте — без этого отказоустойчивость схемы не обеспечивается.
2. Минимальное количество координаторов отказоустойчивости — 2 экземпляра.
3. Количество координаторов отказоустойчивости должно соответствовать фактору резервирования кластера: например, при факторе резервирования 4 достаточно 4 координаторов. Создавать больше можно, не имеет смысла — избыточные экземпляры не повышают отказоустойчивость, а лишь создают дополнительный трафик.
4. Хранилище конфигурации etcd или Tarantool-based configuration storage (далее TBCS) должно иметь нечётное количество экземпляров, не менее 3. Оптимальное количество узлов — 3: с ростом числа экземпляров надёжность повышается, но производительность записи падает и растут задержки, поскольку подтверждать запись должен кворум из большего числа экземпляров. Конфигурация из 5 экземпляров допустима при использовании TBCS и обоснованной необходимости (например, при факторе резервирования кластера 4–5). Использовать 7 и 9 экземпляров не рекомендуется. Экземпляры должны размещаться на разных физических серверах, лучше — в разных ЦОД (в виртуальной среде — с anti-affinity-правилами). Если кластер располагается в двух ЦОД, важно иметь третью площадку только под хранение кластерной конфигурации для реализации схемы 2,5 ЦОД.
5. Сайзинг количества роутеров и хранилищ выполняется от ожидаемой нагрузки: ориентировочно до 20 000 RPS на одно хранилище и до 5 000 RPS на один роутер (значения включают запас на пиковые нагрузки). На практике это даёт соотношение 3–4 роутера на одно хранилище: например, кластер на 1 млн RPS — это порядка 50 хранилищ и 200 роутеров. Показатели получены при следующих условиях испытаний: опубликованные результаты испытаний. При развёртывании в виртуальной среде указанные показатели достижимы при уровне переподписки ресурсов не выше 1:3 — при большей конкуренции за ресурсы потери производительности могут достигать 60%.
6. Рекомендуемый размер одного узла хранилища в memtx — 30–32 ГБ. Это оптимальный размер для быстрой загрузки и восстановления узла; превышение увеличивает время создания снимков данных и нагрузку на дисковую подсистему.
7. Сумма памяти (memtx, кэш vinyl) всех узлов кластера на машине должна быть меньше объёма её оперативной памяти: должен оставаться запас для памяти для Lua, среды выполнения Lua-кода (runtime arena), а также память для сетевых, дисковых и прочих операций. Подробности приведены в документации инсталлятора ATE.

Указанные значения приведены для 640 экземпляров Tarantool DB:

• Увеличьте значения iproto.net_msg_max и readahead на экземплярах до 1536 и 32640 соответственно

• Увеличьте значение параметра config.etcd.http.request.timeout, чтобы снизить количество повторных запросов (и «спам») в etcd. Значение времени ожидания подбирайте под реальное время ответа вашего кластера etcd под нагрузкой.

• Настройте время ожидания опроса экземпляров и etcd в TCM:

   
  cluster.refresh-state-period: 30cluster.refresh-state-timeout: 10storage.etcd.dial-timeout: 0.5sstorage.etcd.dial-keep-alive-time: 2sstorage.etcd.dial-keep-alive-timeout: 1s

Требуются следующие точки монтирования:

• /app/tarantool

  • 30-50% от суммарного объема памяти, выделенного узлам Tarantool на данном хосте;
  • Локальный SSD;

• /app/snap

  • рекомендуется для НТ, ПредПРОМ и ПРОМ контуров;
  • 100% от суммарного объема памяти, выделенного узлам Tarantool на данном хосте;
  • локальный SSD или том на СХД (flash);

• /app/logs

  • 1 GB * N, где N — количество узлов Tarantool на хосте;
  • SSD или HDD;

• /app/backup

  • 100% * N * M, где N — количество узлов Tarantool на хосте, M — глубина резервирования;
  • HDD;

• /app/etcd

  • достаточно 5 ГБ;
  • SSD или HDD;

• /app/nginx (если нужен HTTPS)

  • достаточно 5 ГБ;
  • SSD или HDD.