Прозрачное межпроцессное взаимодействие

Прозрачная межпроцессная связь ( TIPC ) — это служба межпроцессного взаимодействия (IPC) в Linux, предназначенная для работы в масштабе всего кластера. Иногда его представляют как Cluster Domain Sockets , в отличие от известного сервиса Unix Domain Socket ; последний работает только на одном ядре.

Функции

Некоторые особенности TIPC:

Examples of Service Addressing and Tracking

• Адресация служб - адресация служб, а не сокетов.
• Сервис трекинг, - подписка на привязку/отвязку сервисных адресов к сокетам
• Служба IPC в масштабе всего кластера — местоположение службы прозрачно для отправителя.
• Обмен дейтаграммами с использованием одноадресной, произвольной и многоадресной рассылки — ненадежная доставка.
• Обмен сообщениями, ориентированный на соединение , - надежная доставка
• Групповой обмен сообщениями - обмен дейтаграммами с надежной доставкой.
• Отслеживание топологии кластера — подписка на добавленные/потерянные узлы кластера.
• Отслеживание подключений — подписка на активацию/отключение отдельных ссылок между узлами.
• Автоматическое обнаружение новых узлов кластера
• Масштабируется до 1000 узлов с обнаружением сбоев на второй скорости.
• Очень хорошая производительность
• Реализован как модуль ядра в дереве на kernel.org.

Реализации

Протокол TIPC доступен в виде модуля в основном ядре Linux и, следовательно, в большинстве дистрибутивов Linux. Проект TIPC также предоставляет реализации протокола с открытым исходным кодом для других операционных систем, от Wind River включая VxWorks от Sun Microsystems и Solaris . Приложения TIPC обычно пишутся на C (или C++ ) и используют сокеты семейства адресов AF_TIPC. поддержка Go , D , Perl , Python и Ruby Также доступна .

Сервисная адресация

Приложение TIPC может использовать три типа адресов.

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

Адресация службы TIPC

• Диапазон обслуживания . Этот тип адреса представляет собой диапазон адресов служб одного типа и экземпляров между нижним и верхним пределом диапазона. Привязав сокет к этому типу адреса, можно заставить его представлять множество экземпляров, что во многих случаях оказывается полезным.
• Адрес сокета . Этот адрес является ссылкой на определенный сокет в кластере. Он содержит 32-битный номер порта и 32-битный номер узла . Номер порта генерируется системой при создании сокета, а номер узла либо задается конфигурацией, либо (в Linux 4.17) генерируется на основе соответствующего идентификатора узла. Адрес этого типа можно использовать для подключения или отправки сообщений так же, как и адреса служб, но он действителен только до тех пор, пока существует указанный сокет.

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

Обмен дейтаграммными сообщениями

Сообщения дейтаграмм представляют собой дискретные блоки данных длиной от 1 до 66 000 байт, передаваемые между неподключенными сокетами. Как и их аналоги UDP , датаграммы TIPC не гарантированно дойдут до места назначения, но их шансы на доставку все равно намного выше, чем у первых. Из-за гарантии доставки на канальном уровне единственным ограничивающим фактором для доставки датаграмм является размер буфера приема сокета. Шансы на успех также может увеличить отправитель, присвоив своему сокету соответствующий приоритет важности доставки . Датаграммы могут передаваться тремя различными способами.

• Одноадресная передача . Если указан адрес сокета, сообщение передается именно на этот сокет. В TIPC термин одноадресная передача зарезервирован для обозначения этого режима адресации.
• Anycast . Когда используется адрес службы, может быть несколько совпадающих пунктов назначения, и метод передачи становится так называемым Anycast , т. е. может быть выбран любой из совпадающих пунктов назначения. Внутренняя функция преобразования адреса службы в адрес сокета использует алгоритм циклического перебора , чтобы снизить риск смещения нагрузки между пунктами назначения.
• Многоадресная рассылка . Тип адреса диапазона обслуживания также используется как адрес многоадресной рассылки . Когда приложение указывает диапазон службы в качестве адреса назначения, копия сообщения отправляется во все соответствующие сокеты в кластере. Любой сокет, привязанный к соответствующему экземпляру службы внутри указанного диапазона многоадресной рассылки, получит одну копию сообщения. Многоадресная рассылка TIPC будет использовать многоадресную рассылку UDP или широковещательную рассылку Ethernet, когда это возможно.

Обмен сообщениями, ориентированный на соединение

Соединения могут быть установлены так же, как и при использовании TCP , с помощью accept() и connect() на Сокеты SOCK_STREAM . Однако в TIPC клиент и сервер используют служебные адреса или диапазоны вместо номеров портов и IP-адресов. TIPC также предоставляет две альтернативы этому стандартному сценарию установки.

• Сокеты могут быть созданы как SOCK_SEQPACKET, подразумевая, что обмен данными должен происходить в блоках сообщений размером не более 66 000 байт.
• Клиент может инициализировать соединение, просто отправив сообщение с данными в принимающий сокет. Аналогично, порожденный серверный сокет может ответить сообщением данных обратно клиенту для завершения соединения. Таким образом, TIPC предоставляет подразумеваемый механизм установки соединения , также известный как 0-RTT , который во многих случаях особенно экономит время.

Наиболее отличительным свойством соединений TIPC по-прежнему является их способность оперативно реагировать на потерю контакта с одноранговым сокетом, не прибегая к активному пульсированию соседа.

• Когда сокет непреднамеренно закрывается пользователем или из-за сбоя процесса, код очистки сокета ядра по своей собственной инициативе выдает одноранговому узлу сообщение FIN/ERROR.
• Когда контакт с узлом кластера потерян, локальный канальный уровень выдает сообщения FIN/ERROR всем сокетам, имеющим соединения с этим узлом. Время обнаружения сбоя однорангового узла можно настроить до 50 мс, тогда как значение по умолчанию составляет 1500 мс.

Групповой обмен сообщениями

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

• Обмен сообщениями может осуществляться только внутри закрытой группы сокетов-членов.

  

  Режимы передачи внутри группы связи

• Сокет присоединяется к группе, используя адрес службы, где поле типа указывает идентификатор группы , а поле экземпляра указывает идентификатор участника. Следовательно, участник может привязаться только к одному адресу службы.
• При отправке произвольного сообщения алгоритм поиска применяет обычный алгоритм циклического перебора, но также учитывает текущую нагрузку, т. е. объявленное окно отправки, на потенциальных получателях, прежде чем выбрать один из них.
• Многоадресная рассылка осуществляется по адресу службы, а не по диапазону, поэтому копия отправленного сообщения дойдет до всех участников, которые присоединились к группе именно с этим адресом.
• Существует режим группового вещания , при котором сообщение передается всем членам группы без учета их личности.
• Последовательность сообщений гарантируется даже между режимами передачи.

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

Отслеживание услуг

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

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

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

Кластер

Сеть TIPC состоит из отдельных обрабатывающих элементов или узлов . Узлы могут быть физическими процессорами, виртуальными машинами или сетевыми пространствами имен, например, в форме Docker-контейнеров. Эти узлы объединяются в кластер в соответствии с назначенными им идентификаторами кластера . Все узлы, имеющие одинаковую идентификацию кластера, будут устанавливать связи друг с другом при условии, что сеть настроена так, чтобы обеспечить взаимное обнаружение соседей между ними. Изменить идентификатор кластера со значения по умолчанию необходимо только в том случае, если узлы в разных кластерах потенциально могут обнаружить друг друга, например, если они подключены к одной и той же подсети. Узлы в разных кластерах не могут взаимодействовать друг с другом с помощью TIPC.

Два физически связанных, но логически отдельных кластера TIPC.

До Linux 4.17 узлам необходимо было настроить уникальный 32-битный номер или адрес узла , который должен соответствовать определенным ограничениям. Начиная с Linux 4.17, каждый узел имеет 128-битный идентификатор узла , который должен быть уникальным в пределах кластера узла. Затем номер узла рассчитывается как гарантированный уникальный хеш этого идентификатора.

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

Обнаружение соседей выполняется посредством многоадресной рассылки UDP или широковещательной рассылки L2, если это возможно. Если в инфраструктуре отсутствует поддержка широковещательной/многоадресной рассылки, обнаружение может выполняться по явно настроенным IP-адресам.

Межузловые связи

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

• Он гарантирует доставку и последовательность всех пакетов.
• Он действует как магистраль для межузловых соединений и отслеживает их.

  

  Узлы соединены между собой одним или двумя звеньями.

  • Когда все контакты с одноранговым узлом потеряны, сокеты с подключениями к этому одноранговому узлу уведомляются, чтобы они могли разорвать соединения.
• Каждая конечная точка отслеживает привязки адресов одноранговых узлов в локальной реплике таблицы привязок службы.
  • Когда контакт с одноранговым узлом потерян, все привязки этого однорангового узла очищаются, а события отслеживания услуг отправляются всем соответствующим подписчикам.
• Когда нет регулярного трафика пакетов данных, каждый канал активно контролируется с помощью зондирования/пульса.
  • Допуск обнаружения сбоя настраивается от 50 мс до 30 секунд, настройка по умолчанию — 1,5 секунды.
• По соображениям производительности и резервирования можно установить два канала на пару узлов - на отдельных сетевых интерфейсах.
  • Пара каналов может быть настроена для распределения нагрузки или режима активного ожидания.
  • В случае сбоя канала произойдет бесперебойное переключение на оставшийся канал, если таковой имеется.

Масштабируемость кластера

Начиная с Linux 4.7, TIPC поставляется с уникальным, запатентованным, автоадаптивным иерархическим алгоритмом мониторинга соседей. Этот алгоритм мониторинга перекрывающихся колец , на самом деле являющийся комбинацией мониторинга колец и протокола Gossip , позволяет создавать полносвязные кластеры до 1000 узлов со временем обнаружения сбоя 1,5 секунды, в то время как в меньших кластерах его можно сделать намного больше. короче.

Производительность

TIPC обеспечивает выдающуюся производительность, особенно в отношении времени задержки в обоих направлениях. Межузловая передача обычно на 33% быстрее, чем TCP, внутриузловая — в 2 раза быстрее для небольших сообщений и в 7 раз быстрее для больших сообщений. Между узлами он обеспечивает максимальную пропускную способность на 10–30 % ниже, чем TCP, тогда как его пропускная способность внутри узла на 25–30 % выше. Команда TIPC в настоящее время изучает, как добавить поддержку GSO/GRO для обмена сообщениями внутри узла, чтобы даже здесь соответствовать TCP.

Транспортные средства массовой информации

Хотя он предназначен для использования всех видов транспортных средств, по состоянию на май 2018 г. реализации поддерживают UDP , Ethernet и InfiniBand . Реализация VxWorks также поддерживает разделяемую память , к которой могут обращаться несколько экземпляров операционной системы, одновременно работающих на одном и том же оборудовании.

Безопасность

В настоящее время безопасность должна обеспечиваться транспортной средой, несущей TIPC. При работе через UDP можно использовать IPSec, а в Ethernet лучшим вариантом является MACSec. Команда TIPC в настоящее время изучает, как поддерживать TLS или DTLS, либо напрямую, либо путем дополнения к OpenSSL.

История

Этот протокол был первоначально разработан Джоном Полом Малой из Ericsson в 1996–2005 годах и использовался этой компанией в кластерных приложениях в течение нескольких лет, а затем был выпущен для сообщества открытого исходного кода и интегрирован в основное ядро ​​Linux. С тех пор он претерпел множество усовершенствований и обновлений, выполненных специальной командой проекта TIPC с участием представителей различных компаний. Инструмент управления TIPC является частью пакета инструментов iproute2 , который входит в стандартную комплектацию всех дистрибутивов Linux.

Справочные ссылки

• Iproute2
• IProute2 Веб-сайт
• Домашняя страница TIPC
• Страница проекта TIPC на SourceForge
• Загрузка демоверсий и утилит на SourceForge