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

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

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

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

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

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

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

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
     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.

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

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

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

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

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

3. Чтобы пометить узел со сбоем в автономном режиме, измените файл конфигурации кластера (cluster.conf) в соответствующем разделе узла для включения текста offline = true.

   Например, этот измененный cluster.conf помечает узел как автономный ghe-data-node-3:

   [cluster "ghe-data-node-3"]
   hostname = ghe-data-node-3
   offline = true
   ipv4 = 192.168.0.6
   # ipv6 = fd12:3456:789a:1::6
   

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

5. Для добавления недавно подготовленного заменяющего узла на любом узле измените файл 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
     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 реплика, что приведет к тому, что вы сможете открыть (модуль) для трафика раньше. Дополнительные сведения см. в разделе Отсрочка заполнения базы данных.

6. Если вы заменяете основной узел Redis, cluster.confизмените redis-master значение с именем узла замены.

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

   Например, этот измененный cluster.conf файл указывает только что подготовленный узел кластера в ghe-replacement-data-node-1 качестве основного узла Redis:

   redis-master = ghe-replacement-data-node-1
   

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

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

9. Если вы принимаете узел в автономном режиме, предоставляющий службы данных, например git-server, pages-serverили storage-serverэвакуировать узел. Дополнительные сведения см. в разделе Эвакуирование узла кластера с службами данных.

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

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

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

1. Подготовьте и установите GitHub Enterprise Server с уникальным именем узла на заменяемом узле.
2. Откройте файл /data/user/common/cluster.conf конфигурации кластера в текстовом редакторе. Например, можно использовать редактор Vim. Создайте резервную копию cluster.conf файла перед изменением файла.

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

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

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

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

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

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

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

   Shell

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

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

   Shell

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

7. После сопоставления 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
   ...
   

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

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