Настройка прокси для интерконнекта
Обзор
Сетевой слой Greengage DB — интерконнект — используется для передачи SQL-запросов и их результатов между сегментами кластера. Он реализует межпроцессное взаимодействие между экземплярами PostgreSQL, работающими на разных сегментах, позволяя системе функционировать как единая логическая база данных.
Когда запрос поступает на мастер-сегмент, диспетчер запросов (Query Dispatcher, QD) формирует план параллельного выполнения и устанавливает соединения со всеми сегментами кластера. Эти соединения используются для передачи команд запроса и получения результатов. На каждом сегменте запускаются процессы-исполнители запросов (Query Executor, QE), которые выполняют свою часть плана, полученного от диспетчера. Они также могут создавать новые подключения к другим сегментам для обмена промежуточными результатами. Такой обмен данными между сегментами лежит в основе модели массово-параллельного выполнения запросов в Greengage DB.
Режимы интерконнекта
Greengage DB предоставляет разные режимы интерконнекта, позволяя выбрать оптимальный для конкретного окружения.
Активный режим интерконнекта задается параметром конфигурации gp_interconnect_type.
По умолчанию интерконнект работает в режиме UDPIFC, когда каждое внутреннее соединение использует отдельные порты на соответствующих хостах. Хотя этот режим обеспечивает высокую пропускную способность, в больших кластерах он может привести к чрезмерному использованию портов и значительным затратам на управление соединениями.
Режим proxy решает эту проблему, выделяя для внутреннего взаимодействия одно сетевое подключение на каждом хосте кластера. Это существенно сокращает количество используемых TCP-портов, упрощает управление подключениями и повышает эффективность передачи данных внутри кластера.
Когда использовать прокси для интерконнекта
Прокси для интерконнекта особенно полезны в средах с ограниченной доступностью портов, например в кластерах, работающих за межсетевыми экранами или с NAT. Их также рекомендуется использовать в крупных кластерах с большим числом сегментов, когда использование отдельного соединения для каждого исполнителя запроса может исчерпать диапазоны портов или увеличить затраты операционной системы на управление соединениями.
Настройка адресов прокси
Чтобы начать использовать прокси для интерконнекта в кластере Greengage DB, задайте адрес прокси — имя хоста или IP-адрес — и TCP-порт для всех сегментов кластера. В это число входят мастер, резервный мастер и все сегменты: основные и зеркальные.
Конфигурация задается через параметр конфигурации gp_interconnect_proxy_addresses.
В качестве значения параметра нужно указать строку из записей следующего формата, разделенных запятыми, взятую в одинарные кавычки:
<db_id>:<content_id>:<segment_address>:<port>
где:
-
<db_id>— уникальный идентификатор сегмента в кластере. -
<content_id>— уникальный идентификатор сегмента данных (-1для мастера). -
<segment_address>— имя хоста или IP-адрес, который использует сегмент. -
<port>— TCP-порт, выделенный для прокси для интерконнекта на этом сегменте.
Значения <db_id>, <content_id> и <segment_address> можно получить из системной таблицы gp_segment_configuration:
SELECT dbid, content, address FROM gp_segment_configuration;Пример вывода:
dbid | content | address
------+---------+---------
1 | -1 | mdw
2 | 0 | sdw1
6 | 0 | sdw2
3 | 1 | sdw1
7 | 1 | sdw2
10 | -1 | smdw
4 | 2 | sdw2
8 | 2 | sdw1
5 | 3 | sdw2
9 | 3 | sdw1
(10 rows)
Далее выберите номера портов (значения <port>) для прокси.
На каждом инстансе должен быть задан ровно один порт.
Подготовьте строку конфигурации, объединив все записи без пробелов и переносов строк. Разделяйте записи запятыми. Заключите всю строку целиком в одинарные кавычки. Пример:
'1:-1:mdw:40000,2:0:sdw1:40000,3:1:sdw1:40500,4:2:sdw2:40000,5:3:sdw2:40500,6:0:sdw2:41000,7:1:sdw2:41500,8:2:sdw1:41000,9:3:sdw1:41500,10:-1:smdw:40000'Используйте утилиту gpconfig, чтобы задать это значение параметру gp_interconnect_proxy_addresses:
$ gpconfig --skipvalidation -c gp_interconnect_proxy_addresses -v "'1:-1:mdw:40000,2:0:sdw1:40000,3:1:sdw1:40500,4:2:sdw2:40000,5:3:sdw2:40500,6:0:sdw2:41000,7:1:sdw2:41500,8:2:sdw1:41000,9:3:sdw1:41500,10:-1:smdw:40000'"Обратите внимание:
-
Для установки значения
gp_interconnect_proxy_addressesтребуется опция--skipvalidation. -
Значение параметра — строка в одинарных кавычках — должно быть дополнительно заключено в двойные кавычки при передаче в
gpconfig.
После обновления параметра перезагрузите конфигурацию кластера, чтобы применить изменения:
$ gpstop -uЕсли IP-адрес, привязанный к имени хоста в кластере, меняется во время работы, повторно выполните gpstop -u для перезагрузки значения gp_interconnect_proxy_addresses.
Проверка конфигурации прокси
После настройки прокси для интерконнекта проверьте, что запросы выполняются корректно и с ожидаемой производительностью.
Запустите тестовую сессию с использованием прокси, установив параметр gp_interconnect_type в proxy через PGOPTIONS:
$ PGOPTIONS="-c gp_interconnect_type=proxy" psql postgresВыполните в этой сессии проверки, описанные в этом разделе.
Выполнение распределенного запроса
Чтобы проверить корректность сетевого взаимодействия в кластере, выполните запрос с обращением ко всем сегментам. Например, следующий запрос считает количество строк таблицы на каждом сегменте:
SELECT gp_segment_id, COUNT(*) FROM orders GROUP BY gp_segment_id ;При успешном выполнении результат выглядит так:
gp_segment_id | count
---------------+--------
3 | 249860
0 | 249933
1 | 249548
2 | 250659
(4 rows)
Если запрос зависает или возвращает ошибку, конфигурация прокси может быть некорректной.
Проверьте значения в gp_interconnect_proxy_addresses, исправьте их и примените новую конфигурацию, как описано в Настройка адресов прокси.
Логи и сообщения об ошибках
После выполнения распределенных запросов проверьте логи кластера на наличие ошибок или предупреждений, связанных с прокси. Некорректные настройки прокси не всегда блокируют выполнение запросов полностью, но при этом могут приводить к проблемам при установке соединений или тайм-аутам, которые отображаются в логах.
Проверить логи можно с помощью:
-
утилиты
gplogfilter; -
представлений
gp_toolkit.gp_log_*; -
внешних инструментов анализа и мониторинга логов.
Подробнее см. Логирование.
Регулярная проверка логов рекомендуется после включения прокси, особенно на этапе первоначального развертывания.
Проверка производительности
Сравните производительность кластера при типичных нагрузках с включенными прокси и без них. Хотя прокси для интерконнекта уменьшают количество открытых портов и соединений, это дополнительный слой, который может вносить небольшие накладные расходы.
Рекомендуемые проверки:
-
Измерьте время выполнения SQL-запросов для типичных отчетных и аналитических задач.
-
Выполните несколько ресурсоемких запросов с агрегацией или объединениями, которые включают обмен данными между сегментами.
-
Отслеживайте использование ресурсов кластера (CPU, память, пропускную способность сети) инструментами Greengage DB и операционной системы.
Эти тесты помогут убедиться, что прокси обеспечивают ожидаемый баланс между эффективностью подключений и производительностью кластера.
Включение прокси для интерконнекта
После успешного тестирования конфигурации прокси в сессии включите их использование на уровне всего кластера.
Для этого установите параметр конфигурации gp_interconnect_type в proxy:
$ gpconfig -c gp_interconnect_type -v 'proxy'Перезагрузите конфигурацию для применения изменений:
$ gpstop -uПосле этого все новые сессии будут использовать интерконнект через прокси.
Отключение прокси для интерконнекта
Чтобы прекратить использование прокси для интерконнекта, переключите кластер обратно на режим интерконнекта по умолчанию:
$ gpconfig -c gp_interconnect_type -v 'udpifc'
$ gpstop -uДля полного отката также очистите конфигурацию адресов прокси:
$ gpconfig -c gp_interconnect_proxy_addresses -v ''
$ gpstop -rПри установке gp_interconnect_proxy_addresses в пустую строку это изменение вступает в силу только после полной перезагрузки кластера (gpstop -r).