Схемы резервирования N+1, N+M в Flussonic Media Server¶

Обзор схем резервирования¶

Использование схем резервирования сервисов особенно важно в индустрии IPTV для обеспечения доступности и надежности системы. Простои могут привести к потере доходов и недовольству клиентов, поэтому необходимо внедрять схемы резервирования для минимизации риска сбоев.

Flussonic Media Server включает в себя функциональность кластерного захвата, которая позволяет внедрять различные схемы резервирования. В этой статье мы рассмотрим, как использовать функцию кластерного захвата для настройки схем резервирования в Flussonic, включая схемы N+1 и N+M.

Схемы резервирования N+1 и N+M — это два распространенных типа схем резервирования сервисов, которые могут использоваться для обеспечения надежности и доступности системы. В схеме N+1 имеется одно дополнительное устройство сверх минимально необходимого количества для выполнения требуемых задач, а в схеме N+M имеется M дополнительных устройств сверх минимально необходимого количества.

Одним из ключевых различий между схемами N+1 и N+M является уровень резервирования, который они обеспечивают. Схемы N+1 обеспечивают более низкий уровень избыточности, поскольку в них имеется одно дополнительное устройство, которое может быть использовано в качестве резервного в случае отказа. Схемы N+M, с другой стороны, обеспечивают более высокий уровень избыточности, поскольку они имеют M дополнительных устройств, которые могут быть использованы в качестве резервных, но если более одного из этих устройств выйдет из строя, система все равно будет подвержена риску отказа.

Еще одно различие между схемами N+1 и N+M заключается в стоимости и сложности реализации. Схемы N+1, как правило, более экономичны и просты в реализации, поскольку для них требуется только одно дополнительное устройство. Схемы N+M, с другой стороны, требуют M дополнительных устройств, что может увеличить стоимость и сложность системы.

Итак, в каких случаях следует использовать схему N+1, а в каких — схему N+M? Это действительно зависит от ваших конкретных нужд и требований. Если вам нужен высокий уровень избыточности и вы готовы заплатить более высокую цену и согласиться на более сложную систему, схема N+M может быть хорошим выбором. С другой стороны, если вы ищете более экономичное и простое решение, схема N+1 может оказаться более подходящей.

Помимо схем резервирования N+1 и N+M, существует еще несколько типов схем резервирования, которые могут быть использованы для обеспечения надежности и доступности системы. К ним относятся:

Горячий резерв: в системе горячего резерва одно устройство используется в качестве основного, а второе — в качестве резервного. Резервное устройство находится в состоянии ожидания и готово приступить к работе, если основное устройство выйдет из строя. Этот тип схемы резервирования часто используется в критически важных системах, где важно минимизировать время простоя и обеспечить бесперебойную работу системы.
Холодный резерв: в системе холодного резерва резервное устройство находится в спящем состоянии и активируется только в случае отказа основного устройства. Этот тип схемы резервирования обычно дешевле в реализации, чем система горячего резервирования, поскольку резервное устройство не находится в состоянии ожидания и не требует столько обслуживания или ресурсов. Однако для активации резервного устройства в случае сбоя может потребоваться больше времени, что может привести к увеличению времени простоя.
Кластеризация: в кластерной системе несколько устройств работают вместе для выполнения одних и тех же задач и могут автоматически взять на себя управление, если одно из устройств выходит из строя. Этот тип схемы резервирования часто используется в системах, где важно обеспечить высокую доступность и способность продолжать работу, даже если одно из устройств выходит из строя.

Введение в функциональность кластерного захвата в Flussonic и как ее можно использовать для настройки схем резервирования¶

Функция кластерного захвата в Flussonic Media Server позволяет конфигурировать несколько серверов Flussonic или устройств Flussonic Coder, которые работают вместе как кластер для выполнения одних и тех же задач. Каждый сервер в кластере называется "пиром", и каждый пир может быть настроен на выполнение определенных задач, таких как транскодирование, запись или передача видео на другие серверы.

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

Функциональные возможности кластера можно использовать для настройки различных типов схем резервирования, включая схемы N+1 и N+M. В схеме N+1 имеется одно дополнительное устройство сверх минимального количества, необходимого для выполнения требуемых задач, а в схеме N+M — M дополнительных устройств. Настроив несколько пиров в кластере и используя опции cluster_ingest и capture_at, вы можете настроить схему резервирования N+1 или N+M в Flussonic.

Подробные примеры настройки схемы резервирования N+1 и N+M с использованием функциональности кластерного захвата в Flussonic¶

Чтобы настроить схему резервирования с помощью функции кластерного захвата Flussonic, выполните следующие шаги:

Настройте кластер серверов в Flussonic. Для этого необходимо указать один и тот же ключ кластера в файле конфигурации для всех серверов кластера, а также указать список других серверов кластера для каждого сервера.
Используйте опцию cluster_ingest в конфигурации потока, чтобы указать, что поток должен обрабатываться кластером серверов.
Используйте опцию capture_at, чтобы указать основной сервер для потока. Если основной сервер выйдет из строя, один из других серверов в кластере автоматически возьмет на себя его роль.

Вот пример конфигурации, которая устанавливает схему резервирования N+1 с использованием функции кластерного захвата Flussonic:

cluster_key abcd;
peer transcoder1;
peer transcoder2;
peer transcoder3;

stream mystream1 {
    url rtmp://source.com/live/mystream1;
    cluster_ingest;
    capture_at transcoder1;
}
stream mystream2 {
    url rtmp://source.com/live/mystream2;
    cluster_ingest;
    capture_at transcoder2;
}

Эта конфигурация устанавливает схему резервирования N+1, используя функцию захвата кластера Flussonic. В этой конфигурации в кластере имеется три сервера: transcoder1, transcoder2 и transcoder3. Каждый из этих серверов настроен на обработку всех потоков в системе.

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

Опции peer используются для указания других серверов в кластере для каждого сервера. Это позволяет серверам общаться друг с другом и координировать свою деятельность как единое целое.

Опции stream используются для указания потоков, которые должны обрабатываться кластером. Опция cluster_ingest указывает, что поток должен обрабатываться кластером серверов, а опция capture_at указывает первичный сервер для потока. Если основной сервер выйдет из строя, один из других серверов в кластере автоматически возьмет на себя ответственность и продолжит обработку потока.

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

В этой конфигурации кластер захватывает и обрабатывает два потока: mystream1 и mystream2. Каждый поток обрабатывается определенным основным сервером, как указано в параметре capture_at. Например, mystream1 обрабатывается транскодером1, а mystream2 — транскодером2.

Если один из основных серверов выходит из строя, то один из других серверов в кластере автоматически принимает на себя управление и продолжает обработку потоков, которые обрабатывались вышедшим из строя сервером. Например, если выйдет из строя транскодер1, то, скорее всего, его место займет транскодер3, и продолжит обработку видео потока mystream1, так как транскодер2, уже занят обработкой mystream2.

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

Используя функциональность кластерного захвата Flussonic, вы можете легко настроить схему резервирования для обеспечения надежности и доступности ваших потоков, независимо от количества потоков или серверов в системе.

Советы по устранению неполадок и отладке проблем со схемой резервирования¶

При настройке схемы резервирования с помощью Flussonic Media Server важно быть готовым к возможным проблемам и знать, как их устранить и отладить. Ниже приведены некоторые советы по устранению неполадок и отладке проблем со схемой резервирования:

Проверьте лог-файлы. Flussonic Media Server регистрирует подробную информацию о своей деятельности, включая любые ошибки или проблемы, которые могут возникнуть. Просмотрев логи, вы сможете определить причину любых проблем и предпринять шаги по их устранению.
Протестируйте процесс резервирования. Чтобы убедиться, что процесс резервирования функционирует должным образом, вы можете имитировать сбой, выключив один из серверов в кластере и проверив, что другие серверы принимают на себя управление и продолжают обрабатывать потоки, как и ожидалось.
Проверьте конфигурацию сети. Убедитесь, что серверы в кластере правильно настроены и могут взаимодействовать друг с другом по сети. Это особенно важно, если вы используете различные сетевые интерфейсы или виртуальные локальные сети для кластера.
Просмотрите конфигурацию. Убедитесь, что конфигурация кластера и потоков верна и соответствует желаемой схеме резервирования. Дважды проверьте параметры cluster_key, peer и capture_at, чтобы убедиться, что они установлены правильно.
Если вы не можете решить проблему самостоятельно, обратитесь за помощью в службу технической поддержки Flussonic. Они смогут предоставить квалифицированный совет и руководство, чтобы помочь вам решить проблему. Дополнительную информацию о том, как связаться с технической поддержкой Flussonic, можно найти на странице Поддержка.

Следуя этим советам, вы сможете эффективно устранить неполадки и отладить любые проблемы, которые могут возникнуть со схемой резервирования в Flussonic Media Server.

Резюме ключевых моментов и лучших практик для настройки схемы резервирования с помощью Flussonic¶

Ниже приведено краткое описание ключевых моментов и лучших практик для настройки схемы резервирования с помощью Flussonic Media Server:

Настройте кластер серверов в Flussonic, указав один и тот же ключ кластера в файле конфигурации для всех серверов и указав список других серверов в кластере для каждого сервера.
Используйте опцию cluster_ingest в конфигурации потока, чтобы указать, что поток должен обрабатываться кластером серверов.
Используйте опцию capture_at, чтобы указать первичный сервер для потока. Если основной сервер выйдет из строя, один из других серверов в кластере автоматически возьмет на себя его роль.
Убедитесь, что каждый сервер в кластере имеет полный и точный список других серверов в кластере. Это необходимо для того, чтобы серверы могли взаимодействовать и работать вместе как единое целое.
Выберите подходящую схему резервирования, исходя из ваших потребностей и требований системы. Варианты включают N+1, N+M, кластер и горячий резерв (1+1).
Протестируйте и проконтролируйте схему резервирования, чтобы убедиться, что она работает правильно и обеспечивает необходимый уровень надежности и доступности.

Следуя этим рекомендациям, вы сможете эффективно настроить схему резервирования с помощью Flussonic Media Server для обеспечения надежности и доступности ваших потоков.