Настройка репликации с высоким уровнем доступности для кластера

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

В этой статье

Сведения о репликации с высоким уровнем доступности для кластеров

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

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

Рекомендуется настроить высокий уровень доступности в рамках комплексного плана аварийного восстановления для кластеризации GitHub Enterprise Server. Мы также рекомендуем выполнять регулярное резервное копирование. Дополнительные сведения см. в разделе Настройка резервных копий в экземпляре.

Необходимые компоненты

Оборудование и программное обеспечение

Для каждого узла в вашем активном кластере необходимо подготовить вторую виртуальную машину с идентичными аппаратными ресурсами. Например, если в кластере есть 13 узлов, и каждый узел имеет 12 виртуальных ЦП, 96 ГБ ОЗУ и 750 ГБ подключенного хранилища, необходимо подготовить 13 новых виртуальных машин, у которых есть 12 виртуальных ЦП, 96 ГБ ОЗУ и 750 ГБ подключенного хранилища.

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

Примечание. Узлы, которые вы планируете использовать для репликации с высоким уровнем доступности, должны быть изолированными экземплярами GitHub Enterprise Server. Не инициализировать узлы реплики в качестве второго кластера.

Network

Вам нужно назначить статический IP-адрес каждому новому подготовленному узлу и настроить подсистему балансировки нагрузки для приема подключений и направления их в узлы на интерфейсном уровне кластера.

Задержка между основными и реплика узлами должна быть меньше 70 миллисекунд. Не рекомендуется настраивать брандмауэр между сетями узлов. Дополнительные сведения о сетевом подключении между узлами в кластере реплики см. в разделе "Конфигурация сети кластера".

Создание реплики с высоким уровнем доступности для кластера

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

  1. Назначьте активные узлы основному центру обработки данных.
  2. Добавьте узлы реплики в файл конфигурации кластера.
  3. Просмотрите пример конфигурации.

1. Назначение активных узлов основному центру обработки данных

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

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

  1. Запишите имя основного центра обработки данных кластера. В верхнем разделе [cluster] файла конфигурации кластера определяется имя основного центра обработки данных с помощью пары "ключ-значение" primary-datacenter.

    [cluster]
  mysql-master = HOSTNAME
  redis-master = HOSTNAME
  primary-datacenter = primary
    • При необходимости измените имя основного центра обработки данных на более информативное или точное, изменив значение primary-datacenter.

  2. Файл конфигурации кластера перечисляет каждый узел под заголовком [cluster "HOSTNAME"]. Под заголовком каждого узла добавьте новую пару "ключ-значение", чтобы назначить узел центру обработки данных. Используйте то же значение, что и в primary-datacenter на шаге 3 выше. Например, если вы хотите использовать имя по умолчанию (default), добавьте следующую пару "ключ-значение" в соответствующий раздел для каждого узла.

    datacenter = primary

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

    [cluster "HOSTNAME"]
  datacenter = default
  hostname = HOSTNAME
  ipv4 = IP-ADDRESS
  ...
...

    Примечание. Если вы изменили имя основного центра обработки данных на шаге 3, найдите пару "ключ-значение" consul-datacenter в разделе для каждого узла и измените значение на новое имя основного центра обработки данных. Например, если вы присвоили основному центру обработки данных имя primary, используйте для каждого узла следующую пару "ключ-значение".

    consul-datacenter = primary

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

     ghe-cluster-config-apply

  4. После завершения инициализации GitHub Enterprise Server отобразит следующее сообщение.

    Finished cluster configuration

Когда GitHub Enterprise Server вернет вас в командную строку, это будет означать, что вы завершили назначение узлов основному центру обработки данных кластера.

2. Добавление узлов реплики в файл конфигурации кластера

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

  • Создать копию файла конфигурации активного кластера.
  • Измените копию, чтобы определить узлы реплики, соответствующие активным узлам, добавив IP-адреса подготовленных виртуальных машин.
  • Объединить измененную копию конфигурации кластера с конфигурацией активного кластера.
  • Применить новую конфигурацию для запуска репликации.

Пример конфигурации см. в разделе "Просмотр примера конфигурации".

  1. Для каждого узла в кластере подготовьте соответствующую виртуальную машину с идентичными характеристиками, запустив одну и ту же версию GitHub Enterprise Server. Запишите IPv4-адрес и имя узла для каждого нового узла кластера. Дополнительные сведения см. в разделе Предварительные требования.

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

  2. Подключение к любому узлу в кластере по протоколу SSH. Дополнительные сведения см. в разделе Доступ к административной оболочке (SSH).

  3. Создайте резервную копию существующей конфигурации кластера.

    cp /data/user/common/cluster.conf ~/$(date +%Y-%m-%d)-cluster.conf.backup

  4. Создайте копию существующего файла конфигурации кластера в временном расположении, например /home/admin/cluster-replica.conf.

    grep -Ev "(?:|ipv|uuid)" /data/user/common/cluster.conf > ~/cluster-replica.conf

  5. Удалите раздел [cluster] из временного файла конфигурации кластера, скопированного на предыдущем шаге.

    git config -f ~/cluster-replica.conf --remove-section cluster

  6. Определите имя дополнительного центра обработки данных, где вы подготовили узлы реплики, а затем обновите файл конфигурации временного кластера с новым именем центра обработки данных. Замените SECONDARY выбранным вами именем.

    sed -i 's/datacenter = default/datacenter = SECONDARY/g' ~/cluster-replica.conf

  7. Определите шаблон для имен узлов реплики.

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

  8. Откройте в текстовом редакторе временный файл конфигурации кластера из шага 3. Например, можно использовать редактор Vim.

    sudo vim ~/cluster-replica.conf

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

    • Измените имя узла в заголовке раздела и значение hostname в разделе на имя узла реплики в соответствии с шаблоном, выбранным на шаге 7 выше.
    • Добавьте новый ключ с именем ipv4и задайте значение статического IPv4-адреса узла реплики.
    • Добавьте новую пару "ключ-значение" replica = enabled.
    [cluster "NEW REPLICA NODE HOSTNAME"]
  ...
  hostname = NEW REPLICA NODE HOSTNAME
  ipv4 = NEW REPLICA NODE IPV4 ADDRESS
  replica = enabled
  ...
...

  10. Добавьте содержимое временного файла конфигурации кластера, созданного на шаге 4, в активный файл конфигурации.

    cat ~/cluster-replica.conf >> /data/user/common/cluster.conf

  11. Назначьте основные узлы MySQL и Redis в дополнительном центре обработки данных. Замените и REPLICA REDIS PRIMARY HOSTNAME на REPLICA MYSQL PRIMARY HOSTNAME имена узлов узла реплики, подготовленного для сопоставления существующих первичных объектов MySQL и Redis.

    git config -f /data/user/common/cluster.conf cluster.mysql-master-replica REPLICA-MYSQL-PRIMARY-HOSTNAME
git config -f /data/user/common/cluster.conf cluster.redis-master-replica REPLICA-REDIS-PRIMARY-HOSTNAME

    Предупреждение. Прежде чем продолжить, проверьте ваш файл конфигурации кластера.

    • В разделе верхнего уровня [cluster] убедитесь, что значения для mysql-master-replica узлов реплики redis-master-replica и являются правильными именами узлов реплики в дополнительном центре обработки данных, который будет служить основными центрами MySQL и Redis после отработки отказа.
    • В каждом разделе для активного узла с именем [cluster "ACTIVE NODE HOSTNAME"] дважды проверьте следующие пары "ключ-значение".
      • Значение datacenter должно соответствовать значению primary-datacenter в верхнем разделе [cluster].
      • Значение consul-datacenter должно соответствовать значению datacenter, которое должно совпадать со значением primary-datacenter в верхнем разделе [cluster].
    • Убедитесь, что для каждого активного узла конфигурация имеет один соответствующий раздел для одного узла реплики с одинаковыми ролями. В каждом разделе для узла реплики дважды проверьте каждую пару "ключ-значение".
      • datacenter должен соответствовать всем остальным узлам реплики.
      • consul-datacenter должен соответствовать всем остальным узлам реплики.
      • Значение hostname должно соответствовать имени узла в заголовке раздела.
      • Значение ipv4 должно соответствовать уникальному статическому IPv4-адресу узла.
      • Значение replica должно быть enabled.
    • Воспользуйтесь возможностью удалить разделы для автономных узлов, которые больше не используются.

    Чтобы просмотреть пример конфигурации, см. статью "Просмотр примера конфигурации".

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

    ghe-cluster-config-init

  13. После завершения инициализации GitHub Enterprise Server отобразит следующее сообщение.

    Finished cluster initialization

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

     ghe-cluster-config-apply

  15. После завершения выполнения конфигурации убедитесь, что репликация кластера настроена и работает правильно.

    ghe-cluster-repl-status

  16. После завершения инициализации GitHub Enterprise Server отобразит следующее сообщение.

    Finished cluster configuration

  17. Настройте подсистему балансировки нагрузки, которая будет принимать подключения от пользователей после отработки отказа на узлы реплики. Дополнительные сведения см. в разделе Конфигурация сети кластера.

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

3. Просмотр примера конфигурации

Конфигурация [cluster] верхнего уровня должна выглядеть так, как показано в следующем примере.

[cluster]
  mysql-master = HOSTNAME-OF-ACTIVE-MYSQL-MASTER
  redis-master = HOSTNAME-OF-ACTIVE-REDIS-MASTER
  primary-datacenter = PRIMARY-DATACENTER-NAME
  mysql-master-replica = HOSTNAME-OF-REPLICA-MYSQL-MASTER
  redis-master-replica = HOSTNAME-OF-REPLICA-REDIS-MASTER
  mysql-auto-failover = false
...

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

...
[cluster "UNIQUE ACTIVE NODE HOSTNAME"]
  datacenter = default
  hostname = UNIQUE-ACTIVE-NODE-HOSTNAME
  ipv4 = IPV4-ADDRESS
  consul-datacenter = default
  consul-server = true
  git-server = true
  pages-server = true
  mysql-server = true
  elasticsearch-server = true
  redis-server = true
  memcache-server = true
  metrics-server = true
  storage-server = true
  uuid = UUID SET AUTOMATICALLY
...

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

  • Важные отличия от соответствующего активного узла выделены полужирным шрифтом.
  • GitHub Enterprise Server назначает значение uuid автоматически, поэтому не следует определять это значение для узлов реплик, которые будут инициализироваться.
  • Роли сервера, определенные ключами *-server, согласуются с соответствующим активным узлом.
...
[cluster "UNIQUE REPLICA NODE HOSTNAME"]
  replica = enabled
  ipv4 = IPV4 ADDRESS OF NEW VM WITH IDENTICAL RESOURCES
  datacenter = SECONDARY DATACENTER NAME
  hostname = UNIQUE REPLICA NODE HOSTNAME
  consul-datacenter = SECONDARY DATACENTER NAME
  consul-server = true
  git-server = true
  pages-server = true
  mysql-server = true
  elasticsearch-server = true
  redis-server = true
  memcache-server = true
  metrics-server = true
  storage-server = true
  uuid = DO NOT DEFINE
...

Мониторинг репликации между активными и репликами узлов кластера

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

Вы можете отслеживать ход выполнения на любом узле кластера с помощью инструментов командной строки, доступных в административной оболочке GitHub Enterprise Server. Дополнительные сведения об административной оболочке см. в разделе "Доступ к административной оболочке (SSH)".

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

ghe-cluster-repl-status

Для проверки общей работоспособности кластера можно использовать ghe-cluster-status. Дополнительные сведения см. в разделе "Служебные программы командной строки".

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

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

  • Подготовьте и настройте новый набор узлов реплик для каждого из новых активных узлов в дополнительном центре обработки данных.
  • Используйте исходные активные узлы в качестве новых узлов реплики.

Процесс перенастройки высокого уровня доступности аналогичен начальной настройке высокого уровня доступности. Дополнительные сведения см. в разделе Создание реплики с высоким уровнем доступности для кластера.

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

Отключение репликации с высоким уровнем доступности для кластера

Вы можете остановить репликацию на узлы-реплики для развертывания кластера GitHub Enterprise Server.

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

  1. В верхнем разделе [cluster] удалите пары "ключ-значение" redis-master-replica и mysql-master-replica.

  2. Удалите каждый раздел для узла реплики. Для узлов replica реплики настраивается как enabled.

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

     ghe-cluster-config-apply

  4. После завершения инициализации GitHub Enterprise Server отобразит следующее сообщение.

    Finished cluster configuration