Создание кластера¶

В данном разделе приведена информация по развертыванию кластера Picodata из нескольких инстансов для разных сценариев. Описанные способы предназначены в первую очередь для локального использования при разработке. О промышленной эксплуатации читайте в разделе Развертывание кластера через Ansible.

Общие сведения¶

Имя кластера¶

Кластер в Picodata может быть идентифицирован по имени, которое задается администратором при запуске одного или нескольких инстансов. Имя кластера необходимо инстансам для первоначальной сборки кластера (bootstrap).

Постоянные и динамические параметры¶

Параметры кластера и инстансов могут быть заданы несколькими способами:

с помощью параметров команды picodata run
через экспорт соответствующих переменных окружения в командной строке
с помощью файлов конфигурации, в которых задаются нужные переменные окружения

В данном руководстве используется последний метод, при котором параметры задаются в файле конфигурации.

См. также:

Конфигурирование

Простой кластер¶

Для примера мы запустим кластер из 3 инстансов на локальном сетевом интерфейсе 127.0.0.1. Приведенный набор параметров явно задает имя кластера "cluster_name" и фактор репликации 3.

Файл конфигурации¶

Использование файла конфигурации — более удобный способ управления настройками инстанса и кластера. Используйте образцы конфигурации для трех инстансов в кластере, приведенные ниже, или сгенерируйте свой файл конфигурации командой picodata config default. Полный перечень возможных параметров конфигурации приведен в разделе Описание файла конфигурации.

Файл конфигурации для инстанса с именем i1:

i1.yml

cluster:
  name: my_cluster
  shredding: False

  tier:
    default:
      replication_factor: 3

instance:
  instance_dir: './i1'
  name: 'i1'
  tier: 'default'
  peer: [ 127.0.0.1:3301 ]

  iproto_listen: '0.0.0.0:3301'
  iproto_advertise: '127.0.0.1:3301'
  http_listen: '0.0.0.0:8081'
  pg:
    listen: '0.0.0.0:5432'

  memtx:
    memory: 64M

Файл конфигурации для инстанса с именем i2:

i2.yml

cluster:
  name: my_cluster
  shredding: False

  tier:
    default:
      replication_factor: 3

instance:
  instance_dir: './i2'
  name: 'i2'
  tier: 'default'
  peer: [ 127.0.0.1:3301 ]

  iproto_listen: '0.0.0.0:3302'
  iproto_advertise: '127.0.0.1:3302'
  http_listen: '0.0.0.0:8082'
  pg:
    listen: '0.0.0.0:5433'

  memtx:
    memory: 64M

Файл конфигурации для инстанса с именем i3:

i3.yml

cluster:
  name: my_cluster
  shredding: False

  tier:
    default:
      replication_factor: 3

instance:
  instance_dir: './i3'
  name: 'i3'
  tier: 'default'
  peer: [ 127.0.0.1:3301 ]

  iproto_listen: '0.0.0.0:3303'
  iproto_advertise: '127.0.0.1:3303'
  http_listen: '0.0.0.0:8083'
  pg:
    listen: '0.0.0.0:5434'

  memtx:
    memory: 64M

Примечание

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

Запуск кластера¶

Запустите каждый из инстансов в отдельном окне терминала следующими командами:

Запуск инстанса i1:

picodata run --config i1.yml

Запуск инстанса i2:

picodata run --config i2.yml

Запуск инстанса i3:

picodata run --config i3.yml

Полный перечень возможных параметров запуска и их описание содержатся в разделе Аргументы командной строки. Приведенные в примере параметры приведут к созданию кластера с веб-интерфейсом, доступным по адресам 127.0.0.1:8081, 127.0.0.1:8082, 127.0.0.1:8083.

Читайте далее:

Кластер из нескольких тиров¶

Тир — это группа инстансов, объединенных по функциональному назначению.

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

На каждом тире запускаются свои сервисы плагинов.

Конфигурация инстансов (выделяемая память и т.д.) и фактор репликации также настраивается на уровне тиров.

Набор тиров, равно как и принадлежность инстансов тирам, определяется на момент развертывания кластера и в дальнейшем не изменяется. Каждый инстанс принадлежит ровно одному тиру.

Файлы конфигурации¶

Следующий пример показывает запуск кластера, состоящего из двух тиров — compute и storage. Создайте отдельные файлы конфигурации для каждого из тиров:

compute-1.yml

cluster:
  name: multi_tier_cluster
  tier:
    compute:
      replication_factor: 1
      bucket_count: 1500
      can_vote: true
    storage:
      replication_factor: 2
      bucket_count: 1500
      can_vote: false

instance:
  tier: compute
  instance_dir: './compute-1'
  name: 'compute-1'
  peer:
  - 127.0.0.1:3301

  iproto_listen: '0.0.0.0:3301'
  iproto_advertise: '127.0.0.1:3301'
  http_listen: '0.0.0.0:8081'
  pg:
    listen: '0.0.0.0:5432'

  memtx:
    memory: 64M

storage-1.yml

cluster:
  name: multi_tier_cluster
  tier:
    compute:
      replication_factor: 1
      bucket_count: 1500
      can_vote: true
    storage:
      replication_factor: 2
      bucket_count: 1500
      can_vote: false

instance:
  tier: storage
  instance_dir: './storage-1'
  peer:
  - 127.0.0.1:3301

  iproto_listen: '0.0.0.0:3302'
  iproto_advertise: '127.0.0.1:3302'
  http_listen: '0.0.0.0:8082'
  pg:
    listen: '0.0.0.0:5433'

  memtx:
    memory: 1024M

storage-2.yml

cluster:
  name: multi_tier_cluster
  tier:
    compute:
      replication_factor: 1
      bucket_count: 1500
      can_vote: true
    storage:
      replication_factor: 2
      bucket_count: 1500
      can_vote: false

instance:
  tier: storage
  instance_dir: './storage-2'
  peer:
  - 127.0.0.1:3301

  iproto_listen: '0.0.0.0:3303'
  iproto_advertise: '127.0.0.1:3303'
  http_listen: '0.0.0.0:8083'
  pg:
    listen: '0.0.0.0:5434'

  memtx:
    memory: 1024M

Примечание

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

Запуск кластера¶

В данном примере создается один инстанс для тира compute и два инстанса для тира storage. Инстансы тира storage образуют один репликасет.

Запустите каждый из инстансов в отдельном окне терминала следующими командами:

Запуск инстанса compute-1:

picodata run --config compute-1.yml

Запуск инстанса storage-1:

picodata run --config storage-1.yml

Запуск инстанса storage-2:

picodata run --config storage-2.yml

Зоны доступности (failure domains)¶

Использование зон доступности¶

Зона доступности — дополнительный параметр instance.failure_domain, который может быть использован в файле конфигурации инстанса для того, чтобы не допустить объединения в репликасет инстансов из одного и того же датацентра.

Параметр instance.failure_domain отражает физическое размещение сервера, на котором выполняется инстанс Picodata. Это может быть как датацентр, так и какое-либо другое обозначение расположения: регион (например, eu-east), стойка, сервер, или собственное обозначение (blue, green, yellow).

Для установки зоны доступности добавьте в файл конфигурации инстанса указанный выше параметр. Например:

...
instance:
  tier: storage
  instance_dir: './storage-2'
  failure_domain: { "DC":"['DC1']","HOST":"trn1" }
  peer:
  - 127.0.0.1:3301
...

После запуска инстанса с таким файлом конфигурации, добавление инстанса в репликасет произойдет так:

если в каком-либо репликасете количество инстансов меньше необходимого фактора репликации, то новый инстанс добавится в него при условии, что установленные для них значения instance.failure_domain отличаются (регистр символов не учитывается)
если подходящих репликасетов нет, то Picodata создаст новый репликасет

Значение параметра instance.failure_domain играет роль только в момент добавления инстанса в кластер. Принадлежность инстанса репликасету впоследствии не меняется. Для изменения зоны доступности следует остановить инстанс, отредактировать его файл конфигурации, изменив значение instance.failure_domain, и затем перезапустить инстанс.

Добавляемый инстанс должен обладать, как минимум, тем же набором параметров, которые уже есть в кластере. Например, инстанс { "DC":"['DC1']" } не сможет присоединиться к кластеру с зоной { "DC":"['DC1']","HOST":"trn1" } и вернет ошибку.

Как было указано выше, сравнение зон доступности производится без учета регистра символов, поэтому, к примеру, два инстанса с зонами { "DC":"['DC1']" } и { "DC":"['dc1']" } будут относиться к одному региону и, следовательно, не попадут в один репликасет.