Магистраль данных: подробное объяснение технологии кластерной связи хранилища данных.

[Предварительный просмотр прямой трансляции] Облачная виртуальная машина за 99 юаней × Собственная облачная архитектура за 9 юаней √

Эта статья опубликована Ху Латаном в облачном сообществе Huawei « Обзор прямой трансляции | Шоссе данных — подробное объяснение технологии связи кластера хранилища данных ».

В эпоху больших данных масштабы кластеров становятся все больше и больше, параллелизм бизнеса становится все выше и выше, а также возрастает коммуникационное давление между узлами кластера базы данных. В этой прямой трансляции на тему «Шоссе данных — подробное объяснение технологии кластерной связи хранилища данных» мы пригласили г-на Вэй Дэна, технического евангелиста Huawei Cloud GaussDB (DWS), подробно объяснить, как технология кластерной связи GaussDB (DWS) может быть развернуто в больших масштабах.Как реализовать высокопроизводительную распределенную систему связи при переносе сервисов с высоким параллелизмом в кластере.

1. Обзор взаимодействия кластера GaussDB (DWS)

В кластере GaussDB (DWS) будет один или несколько узлов координации (CN), каждый хост имеет несколько узлов данных (CN), глобальный контроллер транзакций (GTM), модуль управления эксплуатацией и обслуживанием (OM), модуль управления кластером ( CM), модуль импорта и экспорта данных (GDS).

Координационный узел (CN): отвечает за декомпозицию запроса, планирование и возврат результатов; синтаксический анализ и оптимизация SQL; сохраняются только метаданные, а не данные.
Узел данных (DN): отвечает за хранение фактических данных таблицы (указанный метод распределения: хеш-таблица, таблица репликации, таблица RroundRobin); выполнение задач SQL и возврат результатов выполнения в CN.
Глобальный контроллер транзакций (GTM) : отвечает за создание и поддержание глобальных идентификаторов транзакций, снимков транзакций, временных меток и другой глобальной уникальной информации.
Модуль управления эксплуатацией и техническим обслуживанием (OM) : обеспечивает ежедневную эксплуатацию, обслуживание и управление конфигурацией.
Модуль управления кластером (CM) : управление кластером и мониторинг использования физических ресурсов каждого устройства.
GDS Loader : пакетная загрузка данных, параллельное ускорение

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

На следующем рисунке представлен обзор кластера GaussDB (DWS).Этот общий доступ к контенту упростил иллюстрацию. GaussDB (DWS) — это распределенная база данных MPP, использующая архитектуру Share Nothing. Данные распределяются и хранятся в различных узлах DN. CN не хранит данные. В качестве точки входа для получения запросов сгенерированный план будет передан в DN для максимально возможного параллельного выполнения для повышения производительности. Когда DN выполняет соединение нескольких таблиц, поскольку локальный DN содержит только частичные данные, требуется обмен данными между DN для централизованного распределения данных таблицы или промежуточных результатов.

Процесс передачи данных общего запроса GaussDB (DWS) : (зеленая стрелка)

Клиент подключается к CN и отправляет запрос;
CN соединяет все DN, генерирует и выдает планы выполнения;
Обмениваться табличными данными или промежуточными результатами между DN через сеть;
DN выполняет обработку данных локально и возвращает набор результатов в CN;
CN агрегирует и обрабатывает набор результатов и возвращает его клиенту.

Обзор связи кластера GaussDB(DWS)

2. Введение в структуру коммуникации CN

1. Информация об IP и порте

Клиент подключается к CN через IP-порт.Системная таблица pgxc_node в CN сохраняет информацию об IP-адресах и портах всех узлов в кластере, помогая CN подключаться к другим узлам в кластере.

В системной таблице pgxc_node на рисунке ниже node_port и node_host — это информация о хосте; node_port1 и node_host1 — резервная информация. Hostis_primary имеет отношение главный-резервный. Когда это значение равно t, CN сначала подключается к хосту, а затем к резервному, и наоборот. Значение hostis_primary автоматически обновляется компонентом управления кластером CM во время переключения между активным и резервным режимами.

2. Клиент общается с CN

Клиент выполняет процесс запроса:

Клиент инициирует соединение с прослушивающим портом CN;
Основной поток CN postmaster принимает соединение, создает поток postgres и передает соединение этому потоку для обработки;
Клиент отправляет запрос в CN;
Поток postgres CN доставляет план запроса другим CN/DN, а результаты запроса возвращаются клиенту по исходному пути;
Запрос клиента завершается, и соединение закрывается;
Соответствующий поток postgres на CN уничтожается и завершается.

Схема связи между клиентом и CN

Процесс установления соединения между CN и DN в основном такой же, как и между клиентом и CN. Чтобы уменьшить накладные расходы на установление соединения между CN и DN, а также на создание и уничтожение потоков postgres в процессе DN, на стороне CN реализуется пул соединений с пулером.

3. Пул соединений пулера

Пул соединений Pooler сохраняет все соединения между CN и другими процессами CN/DN. Каждое соединение соответствует потоку postgres на другом CN/DN. Пул соединений Pooler снижает затраты на установление соединений, а также на создание и уничтожение потоков postgres за счет повторного использования соединений и потоков.

Процесс повторного использования пулера :

Когда сеансу необходимо подключиться, найдите правильный пул соединений пула для ключа через DB+USER и сначала извлеките из него существующее соединение;
После завершения запроса поток postgres CN не вернет соединение, и соединение можно будет использовать для следующего запроса текущего сеанса;
После завершения сеанса поток postgres CN вернет соединение соответствующему пулу. Поток postgres на соответствующем DN не выйдет. Он находится в ReadCommand и ожидает, пока новый поток postgres CN инициирует задачу после повторного использования.

Схема пула соединений пулера

4. Вид на пулер

Представление pg_pooler_status записывает всю информацию о соединениях в пуле соединений средства объединения. Как показано на рисунке ниже, каждая строка представляет соединение, инициированное этим CN, соответствующее потоку postgres противоположного процесса. in_use имеет значение «t», что означает, что соединение используется потоком, и «f», что означает, что неактивное соединение ожидает повторного использования. tid указан как номер потока этого CN, который поддерживает это соединение, node_name указан как номер однорангового процесса, а Remote_pid указан как номер однорангового потока. Если query_id равен 0 или CN/DN несовместимы, найдите связь соединения CN и DN с помощью представления пула.

5. Очистка соединения пулера

Существует два типа механизмов очистки пула соединений: соединения, удерживаемые сеансом, и соединения в пуле простаивающих соединений Pooler.

Соединение удерживается сеансом:

cache_connection, следует ли использовать пул соединений средства объединения для кэширования соединений;
session_timeout, клиентское соединение сообщит об ошибке после тайм-аута простоя, завершит работу и вернет соединение;
Enable_force_reuse_connections — принудительно вернуть соединение после завершения транзакции;
conn_recycle_timeout (2.1), возвращает соединение после истечения времени ожидания сеанса простоя CN.

Соединения пулера в пуле простаивающих соединений:

pg_clean_free_conn, очищает 1/4 соединений пула неактивных соединений, CM вызывает его регулярно;
очистить соединение, очистить все неактивные соединения, соответствующие БД или пользователю.

3. Введение в структуру связи DN

1. Потоковый оператор

GaussDB (DWS) — это распределенная база данных MPP, использующая архитектуру Share Nothing. Данные хранятся в различных узлах DN. Данные в двух таблицах, которые соответствуют условиям соединения, должны быть распределены по одному и тому же DN. Таблицы, которые не соответствуют условиям, должны быть То есть генерируется потоковый оператор.

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

2. Потоковая ветка

Каждому оператору потока на DN необходимо запустить поток потока для асинхронной отправки сетевых данных. Если включен параллелизм SMP, оператору потока может потребоваться запустить несколько потоков потока и установить больше соединений между DN. Существует три типа потоковых операторов (Streaming):

СБОР: CN взаимодействует с DN и собирает наборы результатов DN.
BROADCAST: DN передает все локальные данные другим DN.
ПЕРЕРАСПРЕДЕЛЕНИЕ: DN хэширует локальные данные и отправляет их соответствующему DN.

3. Пул потоков потоков

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

Пул потоковых потоков реализован с использованием очереди без блокировки, одновременно запускаются 2000 потоковых потоков, а время оптимизировано от 2 секунд до 10 мс. Когда оператору потока требуется поток потока, он сопоставляет соответствующий пул потоков потока через имя БД и сначала повторно использует существующие потоки той же БД. Созданный поток потока помещается в пул потоков для ожидания повторного использования после завершения запроса. Сами потоки в пуле потоковых потоков имеют функцию таймаута при простое, и 1/4 перезапускается каждые 60 с. Параметр max_stream_pool устанавливает верхний предел кэша пула потоков. Когда он равен 0, функция пула потоков потока отключена. Его также можно временно установить для очистки потока потока.

Диаграмма пула потоков потока

4. Коммуникационная библиотека Libcomm

Когда кластер достигает 1000 DN, каждый поток потока должен установить 1000 соединений. Если одновременно выполняются 1000 потоков потоков, DN необходимо установить в общей сложности 1 миллион соединений, что потребует большого количества ресурсов соединения, памяти и FD. На основе этой ситуации была разработана коммуникационная библиотека Libcomm.Коммуникационная библиотека Libcomm имитирует n логических соединений по физическому длинному соединению, так что все одновременные данные передаются по одному физическому соединению, что решает проблему чрезмерного количества физических соединений и затрат времени. потребляющее установление соединения.Проблема.

4. Обнаружение проблем со связью

1. Проблема зависания связи.

Действия по обнаружению проблем с зависанием связи:

Найдите query_id проблемного запроса в представлении pgxc_stat_activity;
Запросить представление pgxc_thread_wait_status на основе query_id;
После фильтрации узла ожидания, очистки данных и синхронизации состояний завершения находится точка блокировки запроса;
Если все три вышеуказанных состояния находятся в трех вышеуказанных состояниях, используйте представление логического соединения Libcomm для дальнейшего позиционирования;

2. Проблема с ошибкой связи.

Типичные проблемы с ошибками связи показаны на рисунке:

3. Обнаружение проблем с производительностью связи

Используйте объяснение анализа производительности;

Найдите стек горячей блокировки в соответствии с проблемой зависания;
Используйте инструмент gsar, чтобы проверить, происходят ли в среде потеря и повторная передача сетевых пакетов;

4. Проблемы с сетевой средой

Используйте инструмент gsar, чтобы проверить, происходят ли потеря и повторная передача сетевых пакетов;
Используйте команду netstat, чтобы подтвердить, по какому соединению происходит повторная передача;

Используйте команду top, чтобы проверить, является ли загрузка ЦП процессом ksoftirq ненормальной на компьютерах на обоих концах соединения;
Используйте ping, telnet и tcpdump для дальнейшего анализа проблем с потерей пакетов;

На этом обмен данными прекращается. Для получения дополнительной информации о техническом анализе продуктов GaussDB (DWS) и внедрении новых функций продуктов хранилищ данных обратите внимание на форум GaussDB (DWS). Будут опубликованы инструкции по обмену техническими блогами и прямым трансляциям. как можно скорее на форуме GaussDB (DWS).

Ссылка на форум: https://bbs.huaweicloud.com/forum/forum-598-1.html .

Ссылка на повтор в реальном времени: https://bbs.huaweicloud.com/live/cloud_live/202312191630.html .

Нажмите, чтобы подписаться и узнать о новых технологиях Huawei Cloud как можно скорее~