Прозрачное межпроцессное взаимодействие ( TIPC ) - это сервис межпроцессного взаимодействия (IPC) в Linux, предназначенный для работы в масштабе кластера. Иногда его представляют как сокеты кластерного домена , в отличие от хорошо известной службы сокетов домена Unix ; последний работает только на одном ядре.
Функции
Некоторые особенности TIPC:
- Адресация сервисов, - адрес сервисов, а не сокетов
- Отслеживание услуг, - подписаться на привязку / отвязку служебных адресов к сокетам
- Общекластерный IPC-сервис - местоположение сервиса прозрачно для отправителя
- Обмен дейтаграммами с одноадресной, произвольной и многоадресной рассылкой - ненадежная доставка
- Подключение ориентированных сообщений, - надежная поставка
- Групповой обмен сообщениями - обмен дейтаграммами с надежной доставкой
- Отслеживание топологии кластера - подписка на добавленные / потерянные узлы кластера
- Отслеживание подключения, - подписка на увеличение / уменьшение отдельных ссылок между узлами
- Автоматическое обнаружение новых узлов кластера
- Масштабирование до 1000 узлов с обнаружением сбоев на второй скорости
- Очень хорошая производительность
- Реализован как встроенный модуль ядра на kernel.org.
Реализации
Протокол TIPC доступен как модуль в основном ядре Linux и, следовательно, в большинстве дистрибутивов Linux. Проект TIPC также предоставляет реализации протокола с открытым исходным кодом для других операционных систем, включая VxWorks от Wind River и Solaris от Sun Microsystems . Приложения TIPC обычно пишутся на C (или C ++ ) и используют сокеты из семейства адресов AF_TIPC. Также доступна поддержка Go , D , Perl , Python и Ruby .
Обращение к сервису
Приложение TIPC может использовать три типа адресов.
- Адрес службы . Этот тип адреса состоит из 32-битного идентификатора типа службы и 32-битного идентификатора экземпляра службы . Идентификатор типа обычно определяется и жестко кодируется программистом пользовательского приложения, но его значение, возможно, придется согласовывать с другими приложениями, которые могут присутствовать в том же кластере. Идентификатор экземпляра часто вычисляется программой на основе критериев, специфичных для приложения.
- Диапазон услуг . Этот тип адреса представляет собой диапазон служебных адресов одного типа и с экземплярами между нижним и верхним пределом диапазона. Привязав сокет к этому типу адреса, можно сделать так, чтобы он представлял множество экземпляров, что во многих случаях оказалось полезным.
- Адрес сокета . Этот адрес является ссылкой на конкретный сокет в кластере. Он содержит 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.
До версии Linux 4.17 узлы должны иметь уникальный 32-битный номер или адрес узла , который должен соответствовать определенным ограничениям. Начиная с Linux 4.17, каждый узел имеет 128-битный идентификатор узла, который должен быть уникальным в пределах кластера узла. Затем номер узла вычисляется как гарантированный уникальный хэш от этого идентификатора.
Если узел будет частью кластера, пользователь может либо полагаться на возможность автоматической конфигурации узла, где идентификатор генерируется при подключении первого интерфейса, либо он может установить идентификатор явно, например, с хоста узла. имя или UUID. Если узел не будет частью кластера, его идентификатор может оставаться равным нулю по умолчанию.
Обнаружение соседей выполняется с помощью многоадресной рассылки UDP или широковещательной рассылки L2, если доступно. Если в инфраструктуре отсутствует поддержка широковещательной / многоадресной рассылки, обнаружение может быть выполнено с помощью явно настроенных IP-адресов.
Межузловые ссылки
Кластер состоит из узлов, соединенных между собой одним или двумя звеньями. Канал представляет собой надежную услугу передачи пакетов, иногда называемую канальным уровнем «L2.5».
- Это гарантирует доставку и последовательность для всех пакетов.
- Он действует как магистраль для межузловых соединений и отслеживает их.
- Когда все контакты с одноранговым узлом потеряны, сокеты с подключениями к этому одноранговому узлу уведомляются, чтобы они могли разорвать соединения.
- Каждая конечная точка отслеживает привязки адресов однорангового узла в локальной реплике таблицы привязки служб.
- Когда контакт с одноранговым узлом теряется, все привязки от этого однорангового узла очищаются, и события отслеживания службы выдаются всем совпадающим подписчикам.
- Когда нет регулярного трафика пакетов данных, каждое соединение активно контролируется с помощью зондирования / контрольных сигналов.
- Допуск обнаружения отказов настраивается от 50 мс до 30 секунд, - настройка по умолчанию - 1,5 секунды.
- По соображениям производительности и избыточности можно установить два канала на каждую пару узлов - на отдельных сетевых интерфейсах.
- Пара каналов может быть сконфигурирована для распределения нагрузки или активного режима ожидания.
- Если канал не работает, произойдет переключение на оставшийся канал без помех, если таковой имеется.
Масштабируемость кластера
Начиная с Linux 4.7, TIPC поставляется с уникальным, запатентованным, автоматически адаптивным иерархическим алгоритмом мониторинга соседей. Этот алгоритм мониторинга перекрывающегося кольца , на самом деле являющийся комбинацией мониторинга кольца и протокола сплетен , позволяет создавать кластеры с полной сеткой из до 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.