This post is also available in: Английский
В данной статье мы рассмотрим использование Flash Media Server Access плагина для распределения нагрузки на FMS среди всех его fmscore процессов. Также расскажем об одном из способов организации балансировки нагрузки для VoD контента на нескольких FMS с использованием Access плагина. Access плагин — это еще один уровень безопасности для FMS, который позволяет производить легковесную авторизацию входящих соединений до того, как они достигнут уровня SSAS приложений на fmsedge процессе.
Access плагин предоставляет следующие возможности:
- исследовать свойства клиентского соединения
- анализировать статистику сервера
- разграничивать доступ к файлам и папкам с контентом
- посылать запросы во внешние системы
После того, как клиентское соединение поступило на fmsedge процесс, последний передает управление в Access плагин (если он был установлен), где бизнес-логика может решить, что делать с этим соединением: принимать, отвергнуть или перенаправлять его на другой FMS.
Распределение нагрузки на FMS среди fmscore процессов
Одной из самый интересных возможностей, которые предоставляет access плагин, является возможность динамически, в момент поступления входящего соединения на fmsedge процесс, решить на какой fmscore процесс лучше всего направить это соединение. Это позволяет более-менее гибко управлять клиентскими соединениями на FMS в зависимости от архитектуры вашей системы, ваших ресурсов и, например, гарантировать качество сервиса определенным группам клиентов.
Сам процесс привязывания соединения к fmscore процессу хорошо описан в документации Адоби. Мы же приведем пример получения идентификатора fmscore процесса, к которому необходимо привязать соединение, полученного из URI клиентского соединения. Понятно, что изначально это идентификатор должен быть добавлен к URI, например в плеере, который используется для проигрывания контента. В свою очередь, плеер мог получить этот идентификатор от балансировщика нагрузки или был вычислен плеером на основе параметров запрошенного контента. Этот пример мы будем использовать далее в статье, когда приведем пример балансирования нагрузки с помощью SSAS приложений.
1 2 3 4 5 6 7 8 9 | void MyAdaptor::onAccess(IFCAccess* pAccess) { ......... switch(pAccess->getType()) { case IFCAccess::CONNECT: { // get client's URI const char* uri = pAccess->getValue("s-uri"); const char* tmp = 0; // marker where core id is in the URI const char *pName = "coreId="; |
if(uri && (tmp=strstr(uri, pName))!=0) {
// get a fmscore id
const char *coreId = tmp + strlen(pName);
// set the fmscore id
if(!pAccess->setValue(«coreIdNum», coreId)) {
// log that set is failed
}
}
break;
}
}
…………
}
Балансирование нагрузки для VoD контента
В качестве полезного примера использования Access плагина мы опишем и приведем фрагменты кода для системы распределения нагрузки для платформы трансляции VoD контента. Стоит отметить, что это только один из возможных способов, однако он вполне функционален и используется на видео порталах с большой посещаемостью, хотя эффектность архитектуры, конечно, зависит от типа контента.
Пусть у нас есть пул эдж серверов с FMS, который предоставляет доступ к VoD через стандартное SSAS приложение vod. Эджи получают контент с ориджин серверов, которые имеют непосредственный доступ к хранилищу VoD контента. Т.е. на эджах должно быть включено проксирование, чтобы они могли сохранять части контента локально в кеш на диске.
Итак, нашей задачей стоит разработать более-менее интеллектуальный балансировщик нагрузки на видео-платформу, который позволит снизить нагрузку на эту платформу. Снижение нагрузки подразумевает эффективное использование ресурсов каждого эдж сервера, таких как: кеш, пропускная способность сетевых интерфейсов, CPU и т.д.
Рис. 1. Архитектура комплекса балансирования VoD контента
Таким образом, клиентское приложение должно изначально обратиться к балансировщику нагрузки, передав название контента. В ответ, оно получит адрес эдж сервера и идентификатор fmscore процесса, к которому клиентский запрос должен быть присоеднен Access плагином. Балансировщик нагрузки периодически собирает статистику(содержание файл-кеша, характеристики и т.д.) с эдж серверов и на основе этой статистики распределяет постпупающие клиентские запросы метод RTMP редиректа.
SSAS приложение edge_app
Данное SSAS приложение нам необходимо для периодического сбора статистики FMS и ее кеширования. Сбор статистики происходит посредством вызовов методов FMS AdminAPI. Для примера нам достаточно 2 метода: getFileCacheStats() и getServerStats(). Первый предоставляет статистику по файл-кешу в ОЗУ с группировкой по fmscore процессам. Второй — статистику по серверу: количество активных соединений, загруженность полосы пропускания, загруженность CPU и т.д.
Также в конфигурационном файле данного приложения можно разместить физические характеристики сервера, которые баласировщик нагрузки может учитывать при распределении запросов: количестве fmscore процессов, максимальная пропускания способность данного сервера и т.д.
Все эти характеристики и свойства обрабатываются и кешируются для использования SSAS приложением balancer_app. Вот так, например, дамп статистики с эдж сервера:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
'srvStats' => { 'appURI' => 'rtmp://192.168.1.10/vod', 'maxOutBandwidth' => 6250000, 'cpuUsage' => 0, 'memoryUsage' => 24, 'phisicalMem' => 35889152, 'bwIn' => 0, 'bwOut' => 0, 'connected' => 0 }, 'cacheStats' => { 'cache' => { 'cache' => { 'sample_1.flv' => [ { 'coreId' => 2, 'useCount' => 25 } ] }, 'cores' => { '0' => 0, '1' => 0, '2' => 1 } } } |
SSAS приложение balancer_app
Данное приложение консолидирует статистику со всех эдж серверов посредством опроса SSAS приложений edge_app. Также оно является первичной точкой входа для всех запросов клиентов на проигрывание контента, т.е. ищет подходящий эдж сервер среди доступных на основе собранной статистики.
Например, балансирование нагрузки можно организовать только на основе двух критериев:
- находится ли контент в файл-кеше
- количество активных клиентов на сервере
Т.е. логика поиска подходящего эджа будет такой: если требуемый контент присутствует в файл-кеше, то необходимо найти среди всех эджей, где он присутствует, наименее нагруженный fmscore процесс; если же контента в кеше нет, то найти просто наименее нагруженный эдж сервер и fmscore процесс.
После того как эдж сервер и fmscore процесс будут найдены, приложение должно сделать RTMP редирект вернув в ответ клиентскому приложению адресс эдж сервре и идентификатор fmscore процесса на нем. Примерно так:
1 2 3 4 5 6 7 8 9 10 | application.onConnect = function(client, contentName) { ....... // find an edge server var edge = this.findEdge(contentName); // find core process id at it var coreId = this.findCoreId(edge); var errObj = {errorMsg: "Rejected due to redirection!", coreId: coreId}; application.redirectConnection(client, edge.srv.appURI, "Redirected!", errObj); ........... } |
Access плагин
Access плагин должен быть установлен на эдж сервере, чтобы правильно работала привязка клиентских входящих соединений на основе переданного идентификатора из балансировщика нагрузки(SSAS balancer_app) к fmscore процессу. Дополнительную ифнормацию смотрите выше, в начале статьи или на сайте Адоба.
Видео плеер
Клиентское приложение (плеер или AIR приложение) должно уметь взаимодействовать с балансировщиком нагрузки (SSAS balancer_app): уметь сделать запрос, понять ответ с RTMP редиректом и правильно построить URI с идентификатором fmscore процесса. См. Рис. 2.
Рис. 2. Взаимодействие клиентского приложения и балансировщика нагрузки
1 2 | var nc = new NetConnection(); nc.connect(balancer_app_uri, "sample_1.flv"); |
В ответ баласировщик нагрузки, после того как найдет подходящий эдж сервер и fmscore процесс, сделает RTMP редирект, передав URI эдж сервера и идентификатор fmscore процесса. Клиентское приложение, например, может обработать ответ так:
1 2 3 4 5 6 7 8 9 10 11 | public function onNCStatus(event:NetStatusEvent) : void { ........... if(event.info.code=="NetConnection.Connect.Rejected) { var info:Object = event.info; var app:Object = info.application; if(info.ex && info.ex.code==302) { var coreId = app.coreId); } } ............. } |
Наконец, клиентское приложение должно установить соединение с эдж сервером, передав полученный идентификатор fmscore процесса в URI на эдж сервер, где его обработает Access плагин:
1 2 3 4 5 |
...... var nc = new NetConnection(); var edgeURI = info.ex.redirect+"?coreId="+app.coreId; nc.connect(edgeURI); ...... |
Заключение
Это только один из способов балансирования нагрузки для видео-платформы, но он позволяет достаточно гибко подойти к вопросу. Например, чтобы расширить данный пример для использование при балансировании Live контента, достаточно на эдж серверах накапливать немного другую статистику и не учитывать файл-кеш. А для DVR контента так и вовсе комплекс не потребует изменений.