Замена узла кластера

Если узел завершается сбоем в кластере GitHub Enterprise Server или если вы хотите добавить новый узел с дополнительными ресурсами, пометьте все узлы для замены как автономные, а затем добавьте новый узел.

Кто может использовать эту функцию?

GitHub определяет право на кластеризация и должен включить конфигурацию лицензии вашего экземпляра. Кластеризация требует тщательного планирования и дополнительных административных накладных расходов. Дополнительные сведения см. в разделе Сведения о кластеризации.

В этой статье

О замене узлов кластера GitHub Enterprise Server

Можно заменить функциональный узел в кластере GitHub Enterprise Server или заменить узел, который произошел сбой.

После замены узла ваш экземпляр GitHub Enterprise Server не автоматически распределяет задания на новый узел. Вы можете принудительно выполнить балансировку заданий экземпляра между узлами. Дополнительные сведения см. в разделе Перебалансирование рабочих нагрузок кластера.

Warning

Чтобы избежать конфликтов, не используйте имя узла, которое ранее было назначено узлу в кластере.

Замена функционального узла

Вы можете заменить существующий функциональный узел в кластере. Например, может потребоваться предоставить виртуальную машину с дополнительными ресурсами ЦП, памяти или хранилища.

Чтобы заменить функциональный узел, установите устройство GitHub Enterprise Server на новой виртуальной машине, настройте IP-адрес, добавьте новый узел в файл конфигурации кластера, инициализируйте кластер и примените конфигурацию, а затем переместите узел в автономный режим.

Note

Если вы заменяете основной узел MySQL, см. статью "Замена основного узла MySQL".

  1. Подготовьте и установите GitHub Enterprise Server с уникальным именем узла на заменяемом узле.
  2. Для добавления недавно подготовленного заменяющего узла на любом узле измените файл cluster.conf, чтобы удалить узел со сбоем и добавить заменяющий. Например, этот измененный файл cluster.conf заменяет ghe-data-node-3 только что подготовленным узлом ghe-replacement-data-node-3:
   [cluster "ghe-replacement-data-node-3"]
     hostname = ghe-replacement-data-node-3
     ipv4 = 192.168.0.7
     # ipv6 = fd12:3456:789a:1::7
     consul-datacenter = PRIMARY-DATACENTER
     git-server = true
     pages-server = true
     mysql-server = true
     elasticsearch-server = true
     redis-server = true
     memcache-server = true
     metrics-server = true
     storage-server = true

Вы можете отложить начальный объем базы данных нового узла реплики MySQL, что приведет к тому, что устройство будет открываться для трафика раньше. Дополнительные сведения см. в разделе Отсрочка заполнения базы данных.

  1. В административной оболочке узла с измененным cluster.conf выполните команду ghe-cluster-config-init. Эта команда инициализирует только что добавленный узел в кластере.

  2. Выполните команду ghe-cluster-config-apply из того же узла. Это позволит проверить файл конфигурации, скопировать его на каждый узел в кластере и настроить каждый узел в соответствии с измененным файлом cluster.conf.

  3. Чтобы перевести узел, который вы заменяете в автономном режиме, из основного узла MySQL кластера выполните следующую команду.

    ghe-remove-node NODE-HOSTNAME

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

Замена узла в экстренной ситуации

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

Note

Если вы заменяете основной узел MySQL, см. статью "Замена основного узла MySQL".

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

  1. Чтобы удалить узел, который сталкивается с проблемами из кластера, из основного узла MySQL кластера выполните следующую команду. Замените NODE-HOSTNAME именем узла, который вы принимаете в автономном режиме.

    ghe-remove-node --no-evacuate NODE-HOSTNAME

    Эта команда помечает узел как автономный в конфигурации и остановит трафик, который направляется на узел. Эту команду можно запустить в no-evacuate режиме, так как далее в этой процедуре вы запустите команды, которые указывают службам данных на узле копировать все реплики на другие доступные узлы в кластере. Дополнительные сведения см. в разделе Служебные программы командной строки.

  2. Добавьте узел замены в кластер.

    1. Подготовьте и установите GitHub Enterprise Server с уникальным именем узла на заменяемом узле.

    2. Чтобы добавить недавно подготовленный узел замены на любом узле, измените cluster.conf файл, чтобы добавить его. Например, этот измененный cluster.conf файл добавляет только что подготовленный узел ghe-replacement-data-node-3:

      [cluster "ghe-replacement-data-node-3"]
  hostname = ghe-replacement-data-node-3
  ipv4 = 192.168.0.7
  # ipv6 = fd12:3456:789a:1::7
  git-server = true
  pages-server = true
  mysql-server = true
  elasticsearch-server = true
  redis-server = true
  memcache-server = true
  metrics-server = true
  storage-server = true

    3. В административной оболочке узла с измененным cluster.conf выполните команду ghe-cluster-config-init. Эта команда инициализирует только что добавленный узел в кластере.

  3. Выполните команду ghe-cluster-config-apply из того же узла. Это позволит проверить файл конфигурации, скопировать его на каждый узел в кластере и настроить каждый узел в соответствии с измененным файлом cluster.conf.

  4. Удалите ссылки на службы данных на удаленном узле.

    1. Найдите UUID удаленного узла. Чтобы найти идентификатор UUID, выполните следующую команду, заменив HOSTNAME имя узла узла. Этот идентификатор UUID будет использоваться на следующем шаге.

      ghe-config cluster.HOSTNAME.uuid

    2. Чтобы удалить ссылки на службы данных, выполните следующие команды. Замените UUID UUID узла.

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

      Note

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

      git-server Для службы (используется для данных репозитория):

      ghe-spokesctl server destroy git-server-UUID

      pages-server Для службы (используется для сборок сайта GitHub Pages):

      ghe-dpages remove pages-server-UUID

      storage-server Для службы (используется для данных Git LFS, изображений аватара, вложений файлов и архивов выпуска):

      ghe-storage destroy-host storage-server-UUID --force

  5. При необходимости удалите запись для удаленного узла в cluster.conf файле. Это позволит упорядочить cluster.conf файл и сэкономить время во время будущих config-apply запусков.

    1. Чтобы удалить запись из файла, выполните следующую команду, заменив HOSTNAME имя узла удаленного узла.

      ghe-config --remove-section "cluster.HOSTNAME"

    2. Чтобы скопировать конфигурацию на другие узлы в кластере, из административной оболочки узла, в котором вы изменили, cluster.confвыполните команду ghe-cluster-config-apply.

Замена основного узла MySQL

Для предоставления служб базы данных кластеру требуется основной узел MySQL и по крайней мере один узел MySQL. Дополнительные сведения см. в разделе Сведения об узлах кластера.

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

  1. Подготовьте и установите GitHub Enterprise Server с уникальным именем узла на заменяемом узле.
  2. Откройте файл /data/user/common/cluster.conf конфигурации кластера в текстовом редакторе. Например, можно использовать редактор Vim. Создайте резервную копию cluster.conf файла перед изменением файла.
Shell
sudo vim /data/user/common/cluster.conf
  1. Добавьте новый заголовок узла и введите пары "ключ-значение" для конфигурации, заменив заполнители фактическими значениями.
  • Убедитесь, что вы включаете mysql-server = true пару "ключ-значение".
  • В следующем разделе приведен пример, а конфигурация узла может отличаться.
   ...
   [cluster "HOSTNAME"]
     hostname = HOSTNAME
     ipv4 = IPV4-ADDRESS
     # ipv6 = IPV6-ADDRESS
     consul-datacenter = PRIMARY-DATACENTER
     datacenter = DATACENTER
     mysql-server = true
     redis-server = true
     ...
   ...

  1. В административной оболочке узла с измененным cluster.conf выполните команду ghe-cluster-config-init. Эта команда инициализирует только что добавленный узел в кластере.

  2. В административной оболочке узла, в котором вы изменили cluster.conf, выполните команду ghe-cluster-config-apply. Недавно добавленный узел станет репликой узла MySQL, и все другие настроенные службы будут запускаться там.

  3. Дождитесь завершения репликации MySQL. Чтобы отслеживать репликацию MySQL с любого узла в кластере, выполните команду ghe-cluster-status -v.

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

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

  5. Убедитесь, что репликация MySQL завершена с любого узла в кластере, выполнив команду ghe-cluster-status -v.

    Warning

    Если репликация MySQL не завершится, вы рискуете потерять данные в экземпляре.

  6. Чтобы задать текущий основной узел MySQL режимом только для чтения, выполните следующую команду из узлов экземпляра.

    Shell
    echo "SET GLOBAL super_read_only = 1;" | sudo mysql

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

    Shell
    ghe-cluster-each -r mysql -- 'echo "SELECT @@global.gtid_executed;" | sudo mysql'

  8. После сопоставления GTID на первичных и репликах узлов MySQL обновите конфигурацию кластера, открыв файл /data/user/common/cluster.conf конфигурации кластера в текстовом редакторе.

    • Создайте резервную копию cluster.conf файла перед изменением файла.
    • В разделе верхнего уровня [cluster] удалите имя узла для узла, который вы заменили из mysql-master пары "ключ-значение", а затем назначьте новый узел. Если новый узел также является первичным узлом Redis, измените redis-master пару "ключ-значение".
    [cluster]
  mysql-master = NEW-NODE-HOSTNAME
  redis-master = NEW-NODE-HOSTNAME
  primary-datacenter = primary
...

  9. Из административной оболочки узла, в котором вы изменили cluster.conf, выполните команду ghe-cluster-config-apply. Это перенастроит кластер, чтобы только что добавленный узел стал основным узлом MySQL, а исходный первичный узел MySQL становится репликой узла MySQL.

  10. Проверьте состояние репликации MySQL с любого узла в кластере, выполнив команду ghe-cluster-status -v.

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