Основной способ горизонтального масштабирования 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-запросов).
- Использовать альтернативный механизм балансировки запросов на уровне приложения.
