Надежная многоадресная передача — это любой протокол компьютерной сети , который обеспечивает надежную последовательность пакетов нескольким получателям одновременно, что делает его пригодным для таких приложений, как передача файлов нескольким получателям .
Multicast — это метод сетевой адресации для доставки информации группе адресатов одновременно с использованием наиболее эффективной стратегии доставки сообщений по каждому каналу сети только один раз, создавая копии только тогда, когда каналы к нескольким адресатам разделяются (обычно сетевые коммутаторы и маршрутизаторы ). Однако, как и протокол пользовательских датаграмм , multicast не гарантирует доставку потока сообщений. Сообщения могут быть потеряны, доставлены несколько раз или доставлены не по порядку. Надежный протокол multicast добавляет возможность получателям обнаруживать потерянные и/или не по порядку сообщения и предпринимать корректирующие действия (по принципу, аналогичному TCP ), что приводит к потоку сообщений без пропусков и в порядке.
Точное значение надежности зависит от конкретного экземпляра протокола. Минимальное определение надежной многоадресной рассылки — это конечная доставка всех данных всем членам группы без навязывания какого-либо конкретного порядка доставки . [1] Однако не все надежные многоадресные протоколы обеспечивают этот уровень надежности; многие из них по-разному жертвуют эффективностью ради надежности. Например, в то время как TCP возлагает ответственность за надежность передачи на отправителя, многоадресные протоколы на основе NAK перекладывают ответственность на получателей: отправитель никогда не знает наверняка, что все получатели фактически получили все данные. [2] RFC-2887 исследует пространство проектирования для массовой передачи данных с кратким обсуждением различных вопросов и некоторыми намеками на возможные различные значения надежного .
Надежная групповая доставка данных (RGDD) — это форма многоадресной рассылки, при которой объект должен быть перемещен из одного источника в фиксированный набор получателей, известный до начала передачи. [3] [4] Такая доставка может потребоваться различным приложениям: Hadoop Distributed File System (HDFS) реплицирует любой фрагмент данных два дополнительных раза на определенные серверы, репликация виртуальной машины на несколько серверов может потребоваться для масштабирования приложений, а репликация данных на несколько серверов может потребоваться для балансировки нагрузки, позволяя нескольким серверам обслуживать одни и те же данные из своих локальных кэшированных копий. Такая доставка часто встречается в центрах обработки данных из-за большого количества серверов, взаимодействующих при запуске высокораспределенных приложений.
RGDD также может происходить между центрами обработки данных и иногда называется межцентровыми передачами точка-многоточка (P2MP). [5] Такие передачи доставляют огромные объемы данных из одного центра обработки данных в несколько центров обработки данных для различных приложений: поисковые системы периодически распространяют обновления поискового индекса (например, каждые 24 часа), приложения социальных сетей отправляют новый контент во многие кэш-памяти по всему миру (например, YouTube и Facebook), а службы резервного копирования создают несколько географически распределенных копий для повышения отказоустойчивости. Чтобы максимально использовать полосу пропускания и сократить время завершения массовых передач, были предложены различные методы для выбора деревьев многоадресной пересылки. [5] [6]
Современные системы, такие как Spread Toolkit , Quicksilver и Corosync, могут достигать скорости передачи данных 10 000 многоадресных рассылок в секунду и более и могут масштабироваться до крупных сетей с огромным количеством групп или процессов.
Большинство платформ распределенных вычислений поддерживают одну или несколько из этих моделей. Например, широко поддерживаемые объектно-ориентированные платформы CORBA поддерживают транзакции, а некоторые продукты CORBA поддерживают транзакционную репликацию в модели сериализуемости с одной копией. «Стандарт отказоустойчивых объектов CORBA» основан на модели виртуальной синхронности. [7] Виртуальная синхронность также использовалась при разработке отказоустойчивой архитектуры Нью-Йоркской фондовой биржи, французской системы управления воздушным движением, системы AEGIS ВМС США, архитектуры репликации бизнес-процессов IBM для WebSphere и архитектуры кластеризации Windows Microsoft для корпоративных серверов Windows Longhorn . [8]
Виртуальная синхронизация впервые была поддержана Корнелльским университетом и называлась «Isis Toolkit». [9] Самая последняя версия Корнелла, Vsync , была выпущена в 2013 году под названием Isis2 (название было изменено с Isis2 на Vsync в 2015 году после террористической атаки в Париже экстремистской организацией под названием ИГИЛ), с периодическими обновлениями и доработками с тех пор. Самая последняя стабильная версия — V2.2.2020; она была выпущена 14 ноября 2015 года; версия V2.2.2048 в настоящее время доступна в виде бета-версии. [10] Vsync нацелена на крупные центры обработки данных, поддерживающие облачные вычисления .
Другие подобные системы включают систему Horus [11], систему Transis, систему Totem, систему IBM Phoenix, распределенную систему управления ключами безопасности Rampart, «систему Ensemble», [12] систему Quicksilver , «проект OpenAIS», [13] ее производную Corosync Cluster Engine и ряд продуктов (включая продукты IBM и Microsoft, упомянутые ранее).