Обзор

Взаимодействие между узлами (Interconnect, IC) — это основной механизм обмена данными между сегментами при выполнении распределённых запросов в YMatrix. YMatrix поддерживает три типа IC.

Типы

Традиционные типы IC:
- ic-tcp: реализован поверх TCP.
- ic-udpifc: реализован поверх UDP и обеспечивает надёжность, аналогичную TCP.
Новый тип IC:
- ic-tunnel: представлен в YMatrix 6.7.1. Разработан для преодоления ограничений традиционных типов IC и обеспечивает повышенную совместимость с окружением и лучшую производительность.

Подробное сравнение

Тип IC	Ключевые характеристики	Типичные сценарии использования	Способ настройки	Поддерживаемые версии
`ic-tcp`	— Наивысшая теоретическая производительность (на основе TCP);— Подвержен зависаниям запросов;— Ограничен количеством системных TCP-портов; слабая масштабируемость в крупных кластерах или при высокой параллельности.	— Малые кластеры с хорошими сетевыми условиями и небольшим числом узлов;— Сценарии, чувствительные к задержкам и требующие пиковой производительности.	— Установите GUC `gp_interconnect_type=tcp`.— Настройте глобально через `gpconfig`.— Установите на уровне сеанса: `PGOPTIONS="-c gp_interconnect_type=tcp" psql`.	Все версии
`ic-udpifc`	— Чувствителен к сетевым условиям: высокая задержка или малый MTU значительно снижают производительность.	— OLAP-запросы;— Сети с низкой задержкой и большим MTU;— Общие рабочие нагрузки с большими объёмами данных — предпочтителен, за исключением миграции данных (очень высокий объём), где производительность `ic-udpifc` резко падает.	— Установите GUC `gp_interconnect_type=udpifc`.— Настройте глобально через `gpconfig`.— Установите на уровне сеанса: `PGOPTIONS="-c gp_interconnect_type=udpifc" psql`.	Все версии
`ic-tunnel`	— Новый тип IC, разработанный для максимальной совместимости с окружением;— Не требует ручной настройки;— Автоматически определяет топологию кластера и адаптируется при масштабировании (вверх/вниз) или сбое master → standby.	— Крупные кластеры, где `ic-tcp` может зависать или останавливаться из-за количества узлов;— Миграция данных, особенно когда производительность `ic-udpifc` резко снижается;— Детализированные запросы со множеством столбцов, где векторизованный motion работает неэффективно;— Окружения с плохими сетевыми условиями или ограничением скорости установки соединений.	— Установите GUC `gp_interconnect_type=tunnel`.— Настройте глобально через `gpconfig`.— Установите на уровне сеанса: `PGOPTIONS="-c gp_interconnect_type=tunnel" psql`.	6.7.1 и новее

Примечание!
ic-tunnel демонстрирует высокую производительность в большинстве сценариев. Однако в следующих специфических случаях рекомендуется оценить традиционные типы ic-tcp или ic-udpifc, чтобы достичь пиковой производительности:

Развертывания с одним узлом

OLTP-нагрузки с точечными запросами

Использование `ic-tunnel`

Управляющие параметры

ic-tunnel поддерживает следующие GUC:

mx_interconnect_compress: управляет включением сжатия данных.
— При значении on сжатие активируется внутри ic-tunnel, что значительно снижает сетевой трафик между узлами за счёт увеличения загрузки CPU процессов QE. Рекомендуется при передаче больших объёмов данных (например, миграция) или в средах с ограниченной пропускной способностью.
matrix.ic_tunnel_port_delta: задаёт смещение порта прослушивания ic-tunnel. Значение по умолчанию — 200.
— Порт сервера ic-tunnel вычисляется как postmaster-port + delta. Пользователь должен гарантировать, что полученный порт уникален и не занят.

Обзор архитектуры

Серверный процесс

ic-tunnel использует прокси-модель. Каждый postmaster сегмента запускает отдельный серверный процесс ic-tunnel. Вся сетевая коммуникация между процессами QE проходит через этот сервер. Между любыми двумя сегментами требуется лишь одно постоянное TCP-соединение.

Список серверных процессов ic-tunnel можно получить командой ps:

$ ps -ef | grep ic-tunnel
u        2769149 2769130  0 03:33 ?        00:00:03 postgres:  4004, ic-tunnel server
u        2769150 2769129  0 03:33 ?        00:00:03 postgres:  4003, ic-tunnel server
u        2769164 2769128  0 03:33 ?        00:00:03 postgres:  4002, ic-tunnel server
u        2769195 2769170  0 03:33 ?        00:00:02 postgres:  4000, ic-tunnel server

При включённом параметре hot_standby = on серверные процессы ic-tunnel также запускаются на standby- и mirror-узлах.

Порт прослушивания

Каждый серверный процесс ic-tunnel требует выделенного TCP-порта прослушивания. На одном хосте все такие порты должны быть различны. Порт вычисляется по формуле:

ic-tunnel-server-port := postmaster-port + delta

Порт определяется автоматически путём прибавления фиксированного смещения (delta) к порту прослушивания postmaster. Ручная настройка не требуется — однако пользователь обязан обеспечить, чтобы вычисленный порт был одновременно уникальным и свободным.

Смещение управляется GUC matrix.ic_tunnel_port_delta, принимающим любое целое число (положительное или отрицательное). Значение по умолчанию — 200.

Динамическая загрузка

ic-tunnel использует новую архитектуру «горячей» замены, построенную на базе недавно введённого в YMatrix фреймворка плагинов IC. Реализация предоставляется разделяемой библиотекой matrixts.so. Поэтому:

Для использования ic-tunnel параметр shared_preload_libraries должен включать matrixts.
Создавать расширение matrixts не требуется.

Примечание!
Если gp_interconnect_type установлен в tunnel, но shared_preload_libraries не содержит matrixts, кластер запускается успешно и клиентские сеансы могут подключиться. В этом случае плагин IC автоматически переходит на резервный режим ic-tcp, и в логе базы данных появляется предупреждение вида WARNING: ic: unknown interconnect type "tunnel", fallback to "tcp" temporarily. Такой переход гарантирует работоспособность кластера при некорректной конфигурации, однако администратору следует оперативно исправить настройку.

Релизы

Русский English 简体中文