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

Замените функциональный или неудачный узел в GitHub Enterprise Server кластере при сохранении служб, предоставляемых узлом.

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

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

В этой статье

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

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

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

Предупреждение

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

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

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

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

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

Примечание.

Если вы заменяете узел базы данных-источника, см . раздел "Замена узла базы данных-источника".

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

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

  3. Чтобы добавить недавно подготовленный узел замены на любом узле, измените cluster.conf файл, чтобы добавить его. Сохраните узел, в который вы заменяете cluster.conf , пока не будете работать ghe-remove-node позже в этой процедуре. Например, этот измененный 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
  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, что приведет к тому, что устройство будет открываться для трафика раньше. Дополнительные сведения см. в разделе Отсрочка заполнения базы данных.

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

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

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

    ghe-remove-node NODE-HOSTNAME

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

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

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

Примечание.

Если вы заменяете узел базы данных-источника, см . раздел "Замена узла базы данных-источника".

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

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

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

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

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

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

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

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

    3. Чтобы добавить недавно подготовленный узел замены на любом узле, измените 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

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

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

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

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

      ghe-config cluster.HOSTNAME.uuid

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

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

      Примечание.

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

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

  ```shell
  ghe-spokesctl server destroy git-server-UUID
  ```

  Для сервиса (используемого `pages-server` для GitHub Pages строительства сайтов):

  ```shell
  ghe-dpages remove pages-server-UUID
  ```

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

  ```shell
  ghe-storage destroy-host storage-server-UUID --force
  ```
  1. При необходимости удалите запись для удаленного узла в cluster.conf файле. Это позволит упорядочить cluster.conf файл и сэкономить время во время будущих config-apply запусков.

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

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

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

Замена узла базы данных-источника (MySQL или MySQL и MSSQL)

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

Если ваш кластер GitHub Actions включён, вам также нужно будет учесть MSSQL в следующих шагах.

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

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

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

  3. Чтобы подключиться к ваш экземпляр GitHub Enterprise Server, SSH в любом из узлов кластера. На рабочей станции выполните следующую команду. Замените HOSTNAME именем узла. Дополнительные сведения см. в разделе Доступ к административной оболочке (SSH).

    Shell
    ssh -p 122 admin@HOSTNAME

  4. Откройте файл /data/user/common/cluster.conf конфигурации кластера в текстовом редакторе. Например, можно использовать редактор Vim. Создайте резервную копию cluster.conf файла перед изменением файла.

    Shell
    sudo vim /data/user/common/cluster.conf

  5. Файл конфигурации кластера перечисляет каждый узел под заголовком [cluster "HOSTNAME"]. Добавьте новый заголовок для узла и введите пары ключ-значение для конфигурации, заменив заполнятели на реальные значения.

    • Убедитесь, что вы включаете mysql-server = true пару "ключ-значение".
    • Если GitHub Actions он включен в кластере, нужно будет включить mssql-server = true пару ключ-значение.
    • В следующем разделе приведен пример, а конфигурация узла может отличаться.
    ...
[cluster "HOSTNAME"]
  hostname = HOSTNAME
  ipv4 = IPV4-ADDRESS
  # ipv6 = IPV6-ADDRESS
  consul-datacenter = PRIMARY-DATACENTER
  datacenter = DATACENTER
  mysql-server = true
  redis-server = true
  ...
...

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

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

    Примечание.

    Предыдущий фрагмент не предполагает GitHub Actions , что включен в кластере.

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

    Если GitHub Actions он включён в кластере, придётся дождаться завершения репликации MSSQL.

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

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

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

    Предупреждение

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

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

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

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

    Shell
    ghe-cluster-each -r mysql -- 'echo "SELECT @@global.gtid_executed;" | sudo mysql'
    • Чтобы проверить успешность установки глобальной переменной MySQL, выполните следующую команду.
    Shell
     echo "SHOW GLOBAL VARIABLES LIKE 'super_read_only';" | sudo mysql

  13. Если GitHub Actions в кластере включено, подключите SSH к узлу, который станет новым основным узлом MSSQL.

    Shell
    ssh -p 122 admin@NEW_MSSQL_NODE_HOSTNAME
    • В сеансе screen выполните следующую команду, чтобы повысить уровень MSSQL на новый узел.
    Shell
    /usr/local/share/enterprise/ghe-mssql-repl-promote

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

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

    Shell
    ghe-cluster-status-redis -v

    Убедитесь, что в отчетах о записи ok нового узла и Redis replication is in syncо том, что запись текущего основного узла Redis также сообщает ok.

    Предупреждение

    Не устанавливайте redis-master узел, который не является перехватной репликой. Если это сделать, кластер может перенастроить текущий первичный узел Redis в качестве реплики нового узла и отменить все данные, которые еще не реплицированы.

ghe-cluster-status-redis сообщает о свежести синхронизации, а не точных смещениях репликации. Непосредственно перед изменением redis-master на следующем шаге найдите текущее имя узла Redis основного узла Redis. Так как mysql-master и redis-master настроены независимо, текущий основной узел Redis не обязательно является узлом базы данных, который вы заменяете.

Shell
ghe-config cluster.redis-master

Затем сравните смещения напрямую, заменив NEW-NODE-HOSTNAME имя узла нового узла и CURRENT-REDIS-MASTER-HOSTNAME значение из предыдущей команды. Сначала проверьте новый узел, а затем текущий первичный узел Redis, чтобы совпадение отражало последнее состояние первичного.

Shell
ghe-redis-cli --remote -h NEW-NODE-HOSTNAME INFO replication
ghe-redis-cli --remote -h CURRENT-REDIS-MASTER-HOSTNAME INFO replication

Убедитесь, что значение нового узла соответствует текущему значению основного узла slave_repl_offset``master_repl_offset Redis. Если значения не совпадают, подождите и проверьте еще раз. Не продолжайте работу до тех пор, пока не будут совпадать смещения.

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

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

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

    Примечание.

    Предыдущий фрагмент не предполагает GitHub Actions , что включен в кластере.

  3. Если GitHub Actions включено в кластере, выполните следующую команду из нового узла MySQL и MSSQL.

    Shell
    /usr/local/share/enterprise/ghe-repl-post-failover-mssql

  4. Если вы изменились redis-master, убедитесь, что новый первичный узел Redis обслуживает трафик и что бывший первичный узел Redis перенастройлен в качестве работоспособной реплики. Выполните указанные ниже команды.

    Shell
    ghe-redis-cli PING
ghe-cluster-status-redis -v

    Убедитесь, что ghe-redis-cli PING возвращается PONG через конечную точку HaProxy Redis по умолчанию, отчеты okо записи нового узла и отчеты ok о записи бывшего первичного узла Redis и Redis replication is in sync.

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

  6. После завершения репликации MySQL (или MySQL и MSSQL) от любого узла в кластере отключите режим обслуживания. См . раздел AUTOTITLE.