Конфигурация шардированного кластера

Настройки шардирования задаются в YAML-файле конфигурации кластера. Для корректной работы механизма шардирования требуется задать настройки двух модулей: vshard и CRUD. Полный список опций конфигурации приведен в документации платформы Tarantool.

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

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

• управление шардированием данных в кластере;
• выполнение операций чтения и записи для распределенных данных.

Для корректной работы модуля vshard создайте этого пользователя в конфигурации кластера в секции credentials и назначьте ему роль sharding. Набор параметров и значений в конфигурации пользователя должен быть фиксированным, за исключением параметра password. В примере ниже пользователь имеет название storage:

 
credentials:  users:    storage:       password: 'secret'      roles: [sharding]

Здесь:

• storage: имя пользователя для работы с модулем шардирования;
• password: пароль пользователя;
• roles: роли, назначенные пользователю. Роль определяет разрешенные действия для пользователя в кластере.

Затем в секции iproto укажите пользователя для подключения роутера к узлам хранилищ:

 
iproto:  advertise:    sharding:      login: storage

Укажите число сегментов в кластере. Пример расчета количества сегментов:

1. Определите максимальное количество объектов, под которое разворачивается кластер. В примере это 10000000000.

2. Рассчитайте средний размер каждого объекта, например 160 байт.

3. Вычислите число объектов в каждом сегменте, учитывая, что стандартный размер сегмента составляет примерно 5 МБ. Значение рассчитывается по формуле ниже:

   (5 МБ) / (средний размер объекта)
   

   В примере получается 5242880 / 160 ≈ 32768.

4. Посчитайте необходимое количество сегментов по следующей формуле:

   (количество объектов в кластере) / (число объектов в сегменте)
   

   В примере получается 10000000000 / 32768 ≈ 305176.

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

 
sharding:  bucket_count: 30000

Для групп узлов в секции sharding.roles укажите роль, которую выполняет эта группа в шардировании:

• router — группа узлов-роутеров для перенаправления запросов;
• storage — группа узлов-хранилищ для хранения данных.

 
groups:  routers:    sharding:      roles: [router]    replicasets:      router-msk:        instances:          router-msk:      router-spb:        instances:          router-spb:  storages:    sharding:      roles: [storage]    replicasets:      storage-1:        instances:          storage-1-msk:          storage-1-spb:      storage-2:        sharding:          weight: 1        instances:          storage-2-msk:          storage-2-spb:

Модуль vshard позволяет управлять балансировкой сегментов на шардах вручную. С помощью параметра sharding.weight система может пропорционально менять количество сегментов на шарде, то есть вес шарда:

 
#...  storages:    replicasets:      storage-2:        sharding:          weight: 1

Например, если в системе 30000 сегментов и три шарда, сегменты распределятся так:

Поскольку вес шарда C в таблице выше равен нулю, этот шард не получает сегменты при балансировке. Шард без сегментов может использоваться в качестве резервного (standby) или при дальнейшем масштабировании.

Финальная конфигурация модуля vshard может выглядеть так:

 
credentials:  users:    storage:       password: 'secret'      roles: [sharding]iproto:  advertise:    sharding:      login: storagesharding:  bucket_count: 30000groups:  routers:    sharding:      roles: [router]    replicasets:      router-msk:        instances:          router-msk:      router-spb:        instances:          router-spb:  storages:    sharding:      roles: [storage]    replicasets:      storage-1:        instances:          storage-1-msk:          storage-1-spb:      storage-2:        sharding:          weight: 1        instances:          storage-2-msk:          storage-2-spb:          #...

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

• roles.crud-router — предоставление IPROTO API CRUD-функций для клиентских запросов к данным. CRUD-функции можно вызвать через коннектор;
• roles.crud-storage — выполнение CRUD-операций на хранилище.

Примеры поддерживаемых методов CRUD:

• crud.select('bands') — вернуть содержимое спейса полностью;
• crud.select('bands', {{'>=', 'year', 1980}}, {first = 10}) — вернуть кортежи, соответствующие заданному условию. Узнать больше: Запрос на выборку по условию;
• crud.insert('bands', {id = 1, band_name = 'Roxette', year = 1986}) — вставить кортеж;
• crud.update('bands', 3, {{'+', 'year', 1}}) — обновить кортеж;
• crud.get('bands', 1) — получить один кортеж;
• crud.delete('bands', 4) — удалить кортеж;
• crud.truncate('bands') — очистить спейс полностью.

Подробные примеры использования методов CRUD можно посмотреть в разделе Запросы к данным c помощью модуля CRUD.

В группе узлов-роутеров задайте технологическую роль roles.crud-router (секция groups.routers.roles):

 
groups:  routers:    sharding:      roles: [router]    roles:      - roles.crud-router

Дополнительно для роутеров можно включить и настроить сбор метрик модуля CRUD. Это можно сделать в секции roles_cfg.roles.crud-router. API для сбора метрик предоставляет технологическая роль roles.metrics-export. По умолчанию сбор метрик отключен (roles.crud-router.stats = false).

Конфигурация со включенным сбором метрик может выглядеть так:

 
#...roles_cfg:  roles.crud-router:    stats: true    stats_driver: metrics    stats_quantiles: true    stats_quantile_tolerated_error: 0.001    stats_quantile_age_buckets_count: 5    stats_quantile_max_age_time: 180

В группе экземпляров хранилища задайте технологическую роль roles.crud-storage (секция groups.storages.roles):

 
groups:  #...  storages:    sharding:      roles: [storage]    roles:      - roles.crud-storage    replicasets:      storage-1:        instances:          storage-1-msk:          storage-1-spb:      storage-2:        instances:          storage-2-msk:          storage-2-spb:            #...

Финальная конфигурация модуля CRUD может выглядеть так:

 
groups:  routers:    sharding:      roles: [router]    roles:      - roles.crud-router    roles_cfg:      roles.crud-router:        stats: true        stats_driver: metrics        stats_quantiles: true        stats_quantile_tolerated_error: 0.001        stats_quantile_age_buckets_count: 5        stats_quantile_max_age_time: 180    replicasets:      router-msk:        instances:          router-msk:      router-spb:        instances:          router-spb:            #...  storages:    sharding:      roles: [storage]    roles:      - roles.crud-storage    replicasets:      storage-1:        instances:          storage-1-msk:          storage-1-spb:      storage-2:        instances:          storage-2-msk:          storage-2-spb:            #...

Полный список опций конфигурации crud можно найти в Справочнике по конфигурации.

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

Начиная с версии Tarantool DataBase 3.1.0 при старте балансировки кластер автоматически включает безопасный режим, чтобы обеспечить согласованность и целостность данных. Производительность кластера в этом режиме снижается (примерно на 15% для операций REPLACE). Безопасный режим включается независимо на каждом хранилище, участвующем в балансировке сегментов. Запросы к спейсам на движке vinyl всегда выполняются в безопасном режиме независимо от текущего статуса безопасного режима.

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

• вызвать метод crud.rebalance_safe_mode_status();
• проверить значение метрики tnt_crud_storage_safe_mode_enabled.

Чтобы вернуть кластер в нормальный режим работы после окончания процесса балансировки, выполните следующие шаги:

1. Дождитесь полного завершения миграции сегментов.

2. Очистите кэш карты маршрутов на каждом роутере:

    
   crud.rebalance.router_cache_clear()

   Проверить время последней очистки кэша можно с помощью метрики tnt_crud_router_cache_clear_ts.

3. Отключите безопасный режим вручную на каждом хранилище — как на мастер-узлах, так и на репликах:

    
   crud.rebalance_safe_mode_disable()

Кроме того, существуют следующие особенности, касающиеся балансировки сегментов:

• Поскольку во время миграции сегмента невозможно выполнять операции с кортежами в этом сегменте, CRUD-операции при балансировке могут завершаться с ошибками. Для исправления ошибок требуется повторно выполнить соответствующие запросы;

• Когда *_many-запрос выполняется над данными из нескольких шардов, на роутере эти данные автоматически разбиваются на пачки по шардам и параллельно отправляются на соответствующие узлы хранилища. Во время балансировки запрос может завершиться с ошибкой на некоторых хранилищах. В этом случае операция будет выполнена частично, а пользователю вернется ошибка с указанием хранилища, где не удалось выполнить запрос. Пользователю нужно быть готовым к тому, что операция может быть выполнена не полностью, и при необходимости повторить соответствующие запросы или выполнить другие необходимые действия;

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