Smarty

  1. Главная
  2. Документы
  3. Smarty
  4. Масштабирование и отказоустойчивость

Масштабирование и отказоустойчивость

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

Хорошей практикой является выделение роли сервера так, чтобы каждый сервер занимался только своей задачей. Не рекомендуется использовать один и тот же сервер и для Smarty, и для СУБД и для балансировщика.

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

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

Стандартная конфигурация

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

В данной конфигурации на одном сервере установлены nginx с порталом и uwsgi proxy, сервер uWSGI и сервер Redis для кеширования. Абонентские приложения взаимодействуют с веб-сервером nginx на этом сервере.

На отдельных серверах установлены SQL Database (для примера это MySQL) для хранения метаданных и MongoBD для сохранения статистических данных.

Конфигурация с балансировкой нагрузки uWSGI с частичной отказоустойчивостью

В этом варианте добавляется балансировщик запросов и дополнительные серверы Smarty.

В роли балансировщика может выступать nginx с использованием механизма upstream и директивы uwsgi_pass. Также может быть использован аппаратный балансировщик HTTP-запросов (в этом случае на Application-серверах также необходимо настроить свой веб-сервер для uwsgi proxy).

nginx на балансировщике взаимодействует с uwsgi-серверами через tcp-сокет.

Три сервера Application server работают автономно (специфических настроек Smarty на этих серверах не требуется) и подключаются к общим серверам SQL, Redis и MongoDB.

Регулярные команды crontab, такие как импорт EPG, могут быть настроены только на одном из серверов Smarty, а для синхронизации медиа-файлов (иконки телеканалов, обложки передач, обложки фильмов и другие загружаемые файлы) между серверами необходимо использовать NFS или любое другое решение (например, btsync или GlusterFS).

Данная схема является частично отказоустойчивой в связи с тем, что балансировщик, SQL и Redis не зарезервированы.

Поскольку MongoDB не является обязательным для работы сервисом, и его состояние не влияет на доступность IPTV/OTT сервиса для абонентов, то его резервирование будет рассматриваться только в самой сложной конфигурации.

Конфигурация с балансировкой нагрузки uWSGI + Redis Cluster с частичной отказоустойчивостью

Этот вариант повторяет предыдущий, однако добавляется Redis Cluster и повышается отказоустойчивость.

Вместо отдельного сервера Redis в этом варианте мы размещаем по 3 инстанса Redis на каждом сервере: master и 2 slave так, что каждый master-инстанс связан с двумя slave-инстансами на других серверах.

В этой схеме незарезервированными остаются SQL-сервер и балансировщик.

Отказоустойчивая конфигурация uWSGI + Redis Cluster + SQL Master-Slave Replication с балансировкой нагрузки

В этом варианте добавляется несколько балансировщиков и базовая SQL-репликация.

Два балансировщика запросов (или более) должны резервировать друг друга и иметь одинаковый плавающий IP-адрес. Это обеспечивается протоколом VRRP, и может быть реализовано с помощью сервиса keepalived или аналогичного. Так, если один из балансировщиков будет отключен, то его белый IP-адрес автоматически поднимется на втором, и сервис продолжит быть доступным.

Репликация базы данных в режиме Master-Slave позволяет распределить нагрузку и иметь холодный резерв. В случае выхода из строя Master-ноды SQL-сервера необходима будет ручная перенастройка для подключения к новой Master-ноде.

Multi-Master репликация будет рассмотрена далее.

Отказоустойчивая конфигурация uWSGI + Redis Cluster + SQL Master-Master Replication с балансировкой нагрузки

Данный вариант конфигурации повторяет предыдущий, однако вместо базовой репликации Master-Slave здесь используется Multi-Master СУБД Percona Xtra DB Cluster.

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

Стрелками на всех схемах отображаются прямые подключения сервисов друг к другу, таким образом Smarty подключается к каждой ноде SQL-сервера напрямую, с указанием его роли (Master или Slave).

Вместо Percona может быть использовано другое решение, поддерживающее такой режим работы, например Oracle RAC (однако в этом случае для Smarty будет подключение к единственному пулу RAC и отказоустойчивость будет прозрачной).

Отказоустойчивая конфигурация uWSGI + Redis Cluster + SQL Master-Master Replication + MongoDB Sharded Cluster с балансировкой нагрузки

Для полностью отказоустойчивой конфигурации, включая дополнительный сервис MongoDB, необходимо использовать механизмы шардинга и репликации MongoDB. В таком варианте подключение будет производится через роутер mongos, как показано далее.

Такая схема может быть необходима при очень большом объеме данных, значительном количестве пользователей онлайн и высоких технических требованиях к сервису.

Дальнейшее масштабирование

В качестве следующих шагов увеличения производительности системы вы можете:

  • Увеличить количество инстансов в кластерах.
  • Настроить Redis Cluster на отдельных серверах.
  • Настроить хостинг Web-портала на отдельных серверах или в CDN.
  • Настроить хранение медиа-файлов (загружаемых иконок каналов, обложек EPG и фильмов) в CDN.
  • Использовать встроенный механизм распределенного выполнения crontab-задач с учетом кластерного режима.
  • Распределить роли Smarty-серверов на отдельные кластеры (например, отдельный кластер для обработки статистики телесмотрения, отдельный кластер для инвалидации общих кешей, отдельный кластер для обработки API-запросов).
  • Использовать альтернативный механизм балансировки запросов на уровне приложения.