а) Добавление узлов с учетом AZ
Новые узлы должны быть подготовлены аналогично другим узлам (как описано в опубликованной вами ссылке) с точки зрения настроек ulimit, подготовки диска данных, установки программного обеспечения YugaByte DB и т. д.
Во время расширения кластера, учитывая, что уже имеется достаточно узлов, на которых запущены процессы yb-master, новым узлам нужно только запустить процесс yb-tserver. Шаги, относящиеся к yb-master процессам, можно пропустить при добавлении узлов в кластер. [Чтобы узнать больше о роли процессов yb-master и yb-tserver, см. https://docs.yugabyte.com/latest/architecture/concepts/universe/.]
При подготовке файла конфигурации yb-tserver для вновь добавленных узлов обязательно установите соответствующие флаги информации о их размещении (облако/регион/зона), которые сообщают системе и ее балансировщику нагрузки необходимую информацию о том, где находится каждый из узлов:
Например, для первого нового узла эти флаги могут быть такими:
--placement_cloud=aws
--placement_region=us-west
--placement_zone=us-west-2a
а для двух других узлов --placement_zone может быть, скажем, us-west-2b и us-west-2c.
Вы бы сделали нечто подобное при настройке yb-tserver на первых 6 узлах, разбросанных по трем зонам доступности.
Запуск этих yb-tserver не будет отличаться от начальных серверов. Например:
~/tserver/bin/yb-tserver --flagfile ~/yb-conf/tserver.conf >& /mnt/d0/yb-tserver.out &
Примечание. Значение главного адреса gflag tserver_master_addrs в tserver.conf должно совпадать со значением существующего yb-tservers. Это то, что гарантирует, что эти узлы будут беспрепятственно присоединяться к существующему кластеру.
б) Узлы могут быть добавлены/запущены все сразу. Нет необходимости добавлять их по одному с некоторым интервалом ожидания между ними. Последнее может фактически привести к перебалансировке/перемещению данных больше раз, чем необходимо. Когда система знает, что ей нужно сразу перейти из состояния с 6 узлами в состояние с 9 узлами, она может более оптимально достичь желаемого конечного состояния сбалансированного кластера, выполняя только необходимый объем перемещения данных.
c) Никаких дополнительных шагов для запуска балансировки нагрузки не требуется! Система автоматически перебалансирует планшеты (осколки) с ограниченной скоростью, чтобы свести влияние на приложение переднего плана к минимуму. В настоящее время этот предел скорости для каждого узла контролируется флагом gflag remote_boostrap_rate_limit_bytes_per_sec, и его значение по умолчанию составляет 100 МБ/с. Но в зависимости от рабочей нагрузки и доступной пропускной способности этот параметр можно настроить на более агрессивный или консервативный. Обратите внимание, что эта перебалансировка является фоновой и онлайн-операцией в базе данных YugaByte и выполняется путем копирования сжатых файлов с соответствующих ведущих планшетов. Следовательно, это значительно легче, чем в конечном итоге согласованные базы данных (такие как Apache Cassandra или MongoDB), которые должны выполнять логическое (несжатое) чтение данных со всех одноранговых узлов.
person
Mikhail at YugaByte
schedule
22.01.2019
