1. Главная
  2. ЦЕНТР ДАННЫХ
  3. Настройка кластера JIRA

Настройка кластера JIRA

Вот несколько способов настройки кластера JIRA с использованием Apache httpd-сервера в качестве обратного прокси-сервера и балансировки нагрузки. Также см. Интеграция JIRA с Apache для более общего обсуждения использования JIRA с Apache.

Существует множество решений по балансировке нагрузки и прокси-серверов, которые могут удовлетворить ваши конкретные потребности, а также лучше, чем Apache httpd.

Существует две опции:

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

Руководство высокого уровня

  1. Установите и настройте последнюю JIRA как обычно, т.е. без конкретных параметров, указанных ниже.
    1. Запустите этот экземпляр и загрузите его с помощью данных плана тестирования JIRA.
    2. Выключите этот экземпляр.

База данных HSQL по умолчанию не будет работать с кластером JIRA.

  1. Установите второй узел, не запуская его.
  2. Задайте настройки кластера в обоих случаях, как указано ниже:
    1. Укажите одну и ту же базу данных (файлы dbconfig.xml на каждом из них, вероятно, должны быть одинаковыми) и пустой общий дом.
    2. Создайте файл cluster.properties для каждого узла
  3. Скопируйте следующие каталоги из локального дома первого узла в общий дом (некоторые могут быть пустыми):
  • данные
  • плагины
  • логотипы
  • импорт
  • экспорт
  1. Запустите уже настроенный экземпляр.
  2. Установите ваш плагин и при необходимости добавьте лицензию.
  3. Запустите второй экземпляр. Он присоединится к БД, а затем заполнит свой местный дом и присоединится к общему дому. Затем он также скопирует ваш плагин.

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

Каждый узел на отдельной машине

Каждый узел JIRA (два в этом примере) работает на своей собственной машине (физической или виртуальной) с третьей машиной для общих служб. В производстве общие службы, скорее всего, будут работать на разных машинах друг от друга.

РИСУНОК

Настройка JIRA

  1. На третьей машине настройте общий домашний каталог, доступный для записи на обоих серверах.
  2. Настройте два сервера JIRA на разных машинах. Эти серверы должны:
  • Имейте  cluster.properties в локальном домашнем каталоге JIRA (см. пример ниже).
  • Быть настроены на использование одного и того же пути контекста.
  • Быть настроены на использование одной и той же базы данных.
  • Файлы dbconfig.xml на каждом из них, вероятно, должны быть одинаковыми.

Установите их имя узла Apache, добавив следующий параметр к той же переменной (заменив node1 на имя узла, используемое в конфигурации балансировки нагрузки Apache):

  • -DjvmRoute=node1
  1. Убедитесь, что базовый URL-адрес, настроенный в JIRA, является URL-адресом программ пользовательского интерфейса прокси-сервера / балансировки нагрузки.

Пример файла cluster.properties


# This unique ID must match the username and the BalancerMember entry in the Apache config
jira.node.id = node1
# The location of the shared home directory for all JIRA nodes
jira.shared.home = /net/mynfsserver/jira_shared_home

Конфигурация httpd (без контекстного пути)

Нам нужно настроить httpd аналогично стандартным обратным прокси, но с добавлением конфигурации mod_proxy_balancer.

Чтобы запустить JIRA на http: // MyCompanyServer /, добавьте блок конфигурации, подобный этому в конце http.conf.


<VirtualHost *:80>
        ProxyRequests off

        ServerName MyCompanyServer

        <Proxy balancer://jiracluster>
                # JIRA node 1
                BalancerMember http://jira1.internal.atlassian.com:8080 route=node1
                # JIRA node 2
                BalancerMember http://jira2.internal.atlassian.com:8080 route=node2

                # Security "we aren't blocking anyone but this the place to make those changes
                Order Deny,Allow
                Deny from none
                Allow from all

                # Load Balancer Settings
                # We are not really balancing anything in this setup, but need to configure this
                ProxySet lbmethod=byrequests
                ProxySet stickysession=JSESSIONID
        </Proxy>

        # Here's how to enable the load balancer's management UI if desired
        <Location /balancer-manager>
                SetHandler balancer-manager

                # You SHOULD CHANGE THIS to only allow trusted ips to use the manager 
                Order deny,allow
                Allow from all
        </Location>

        # Don't reverse-proxy requests to the management UI
        ProxyPass /balancer-manager !
        # Reverse proxy all other requests to the JIRA cluster
        ProxyPass / balancer://jiracluster/
        ProxyPreserveHost on
</VirtualHost>

Конфигурация httpd (с путем контекста)

Некоторые незначительные изменения в вышеуказанной конфигурации необходимы, если JIRA развернуто в пути контекста. Чтобы запустить JIRA в http: // MyCompanyServer / jira /, добавьте блок конфигурации, подобный этому в конце http.conf.


<VirtualHost *:80>
        ProxyRequests off

        ServerName MyCompanyServer

        <Proxy balancer://jiracluster>
                # JIRA node 1
                BalancerMember http://jira1.internal.atlassian.com:8080/jira route=node1
                # JIRA node 2
                BalancerMember http://jira2.internal.atlassian.com:8080/jira route=node2

                # Security "we aren't blocking anyone but this the place to make those changes
                Order Deny,Allow
                Deny from none
                Allow from all

                # Load Balancer Settings
                # We are not really balancing anything in this setup, but need to configure this
                ProxySet lbmethod=byrequests
                ProxySet stickysession=JSESSIONID
        </Proxy>

        # Here's how to enable the load balancer's management UI if desired
        <Location /balancer-manager>
                SetHandler balancer-manager

                # You SHOULD CHANGE THIS to only allow trusted ips to use the manager 
                Order deny,allow
                Allow from all
        </Location>

        # Immediately redirect /jira to /jira/ and don't pass it to the load balancer.
        RedirectMatch ^/jira$ /jira/
        ProxyPassMatch ^/jira$ !
        # Don't reverse-proxy requests to the management UI
        ProxyPass /balancer-manager !
        # Reverse proxy all other requests to the JIRA cluster
        ProxyPass /jira balancer://jiracluster
        ProxyPreserveHost on
</VirtualHost>

Конфигурация одного хоста

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

 

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

  • Каждый узел JIRA должен работать на разных портах.
  • Ehcache должен быть настроен для использования разных настроек; отредактируйте файл cluster.properties и добавьте «hostName» и «port» следующим образом:

Пример настроек EhCache для узла 1


ehcache.listener.hostName=localhost
ehcache.listener.port=40001

Пример настроек EhCache для узла 2


ehcache.listener.hostName=localhost
ehcache.listener.port=40002

Решение проблем

Валидация того что кеши реплицированы корректно по кластеру.

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

  1. Войдите в один узел кластера. Переход непосредственно к узлу проще всего, минуя любой балансировщик нагрузки.
    1. Перейдите в «Администрирование / Типы задач» и измените имя типа задачи
    2. Войдите в другой узел (узлы) в кластере
    3. Перейдите в «Администрирование / Типы задач» и убедитесь, что отредактированное имя с шага-b отображается правильно.

Если новое значение не видно на других узлах,  тогда, кластер не общается должным образом.

  • Возможно, вам придется отключить брандмауэр или, по крайней мере, разрешить прохождение портов, настроенных выше. Некоторые системы, особенно более поздние версии Linux, блокируют их даже во внутренней локальной сети.
  • Вам необходимо обеспечить поддержку многоадресной рассылки. Для Linux вам может понадобиться включить его. Многоадресная рассылка часто не включена для локального хоста.

# ifconfig lo multicast
# ifconfig lo
lo: flags=4169<UP,LOOPBACK,RUNNING,MULTICAST>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 0  (Local Loopback)
        RX packets 4974487  bytes 3608495877 (3.3 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 4974487  bytes 3608495877 (3.3 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
  • Каждый сервер должен иметь возможность правильно разрешать собственное имя хоста. Это не так очевидно, как кажется, и ошибки здесь могут быть трудными для обнаружения

Некоторые дистрибутивы Linux добавят записи в / etc / hosts, такие как


127.0.0.1       localhost.localdomain localhost
127.0.1.1       myhost.mycompany.com myhost

Это может привести к тому, что ehcache объявит себя другим узлам в кластере, находящимся в 127.0.1.1. Это не поможет и приведет к несогласованности кеша в кластере. Вы можете установить уровень ведения журнала на ehcache в log4j.properties для отслеживания, чтобы попытаться диагностировать такую ошибку.


log4j.logger.net.sf.ehcache.distribution = TRACE, console, filelog

Попробуйте удалить строку, ссылающуюся на 127.0.1.1, из / etc / hosts или указать свойство hostName для cacheManagerPeerListenerFactory в  cluster.properties.


ehcache.listener.hostName=com.example.myhost

По материалам Atlassian JIRA Server Developer Configuring a JIRA cluster