Введение С распространением философии Agile российские ИТ-специалисты с каждым годом накапливают все больше экспертизы и компетенций в области настройки и управления продуктами для команд разработки, самым популярным из которых по-прежнему остается Jira. Однако работа с самой «старой», самой производительной и высокодоступной его версией — Jira Data Center — по-прежнему вызывает массу вопросов.
В этом посте я расскажу о некоторых принципах и механизмах Jira DataCenter, которые мы используем на практике.
Начну со структуры кластера Jira.
Что такое Jira DataCenter?
Jira DataCenter — это по сути серверная версия, но с возможностью использования общей базы данных и общего индекса.Важно понимать, что сам Jira DataCenter, как продукт и как приложение, НЕТ обеспечивает отказоустойчивость и балансировку нагрузки.
За это отвечают модули и системы, к которым продукт Atlassian не имеет никакого отношения.
Другими словами, Atlassian обеспечивает поддержку работы в кластере, но сама кластеризация реализуется внешними инструментами, выбор которых достаточно богат. Подробное описание товара вы можете найти на сайте Атласиан .
Предлагается несколько вариантов строительства: 1. На собственной инфраструктуре 2. В облаке Amazon (AWS) 3. В облаке MS (Azure) В этой статье будет описано решение для вашей собственной инфраструктуры.
Какие проблемы решает Jira DataCenter?
Jira Data Center поможет вам достичь следующих целей:- Реализация отказоустойчивости.
- Обеспечение стабильной работы при высокой нагрузке.
Высокая нагрузка означает экземпляры большого/корпоративного масштаба, согласно Руководство по выбору размера Jira .
- Обеспечьте непрерывную работу, когда требуется техническое обслуживание.
На этом пункте я остановлюсь отдельно.
Приложение приходится довольно часто обновлять, и не у всех компаний есть возможность сделать это быстро и незаметно для пользователей.
Эта проблема решается путем кластеризации и использования так называемого Нулевое время простоя обновить схемы.
Из каких компонентов состоит Jira DataCenter?
Как вы можете видеть на изображении ниже, кластер Jira DataCenter представляет собой совокупность нескольких выделенных компьютеров.
Рисунок 1. Архитектура Jira Data Center
- Узлы приложений (узлы приложений или узлы кластера).
Они принимают и обрабатывают всю рабочую нагрузку и запросы.
Роль узлов выполняют обычные серверы с идентичным контентом и установленными приложениями, а также смонтированной общей файловой системой.
- Файловая система (Общая файловая система) со стандартными возможностями импорта/экспорта файлов, плагинами, кэшированием и т. д. Файловый сервер — это также отдельный сервер, на котором создается общая папка или ресурс, монтируется к узлам и используется для общих файлов.
- База данных (общая база данных).
Сервер базы данных в данном случае также является отдельным сервером и может быть построен на решениях MS SQL, PostgreSQL, MySQL и Oracle.
- Балансировщик нагрузки.
Он распределяет запросы пользователей и доставляет их на узлы, а в случае сбоя одного из них балансировщик практически мгновенно перенаправляет свои запросы на другие узлы.
Благодаря его работе пользователи даже не замечают выхода из строя одного узла.
О работе балансировщика мы поговорим отдельно ниже.
Топология кластера Jira Data Center
Вот основные принципы, по которым строится кластер в JDC:- Экземпляры Jira используют общую базу данных;
- Индекс Lucene реплицируется в реальном времени и сохраняется локально в каждом экземпляре;
- вложения хранятся в общем хранилище;
- Экземпляры Jira контролируют целостность кэша;
- несколько экземпляров могут быть активны одновременно в любое время;
- доступны блокировки кластера;
- балансировщик настроен на перенаправление запросов только на активные узлы, при этом он не должен перенаправлять запросы на неактивные узлы, а также не может адресовать все сессии на один узел.
Активные узлы отличаются тем, что они:
- Обработка запросов
- Запуск фоновых процессов и задач
- Запланированные задачи можно настроить на одном или нескольких из них.
- Во всех практических сценариях ситуация будет выглядеть так, как при использовании стандартного Jira Server. Соответственно, пассивные узлы не обрабатывают запросы и не выполняют задачи, а служат для принятия на себя краткосрочных рабочих нагрузок (например, во время запуска системы, загрузки плагинов и/или индексации).
Рисунок 2. Упрощенная схема архитектуры
О балансировщиках нагрузки
Балансировщиком может быть любой сервер с установленным обратным прокси или физическое устройство.Я приведу самые известные примеры балансиров.
1. Аппаратные балансировщики: • Сиско • Можжевельник • F5 2. Программные балансировщики: • mod_proxy (Apache) — прокси-сервер для HTTP-сервера Apache, поддерживающий большинство популярных протоколов и несколько различных алгоритмов балансировки нагрузки.
• Varnish — это обратный прокси-сервер и ускоритель HTTP, предназначенный для сайтов с высоким трафиком.
В отличие от других, это всего лишь прокси-сервер и балансировщик нагрузки для HTTP-трафика.
В частности, Varnish используют Wikipedia, NY Times, The Guardian и многие другие крупные проекты.
• Nginx — это веб-сервер №1 по популярности среди балансировщиков нагрузки и прокси-решений для сайтов с высоким трафиком.
Он активно развивается, производитель предлагает бесплатную и корпоративную версии.
Используется на многих самых посещаемых сайтах мира, таких как WordPress.com, Zynga, Airbnb, Hulu, MaxCDN. • Nginx Plus — собственно, упомянутая выше платная корпоративная версия Nginx. • HAProxy — это бесплатный инструмент с открытым исходным кодом, который обеспечивает балансировку нагрузки и возможности прокси для протоколов TCP/HTTP. Он быстрый, потребляет мало системных ресурсов и совместим с Linux, Solaris, FreeBSD и Windows. Хорошее сравнение прокси-серверов можно найти здесь по этой ссылке .
«Прямые» и «обратные» прокси
Балансировщики нагрузки могут работать как прямые, так и обратные прокси.Автор хорошо описал разницу этот комментарии stackoverflow: 1. «Переадресация прокси».
В данном случае прокси-событие — это когда «пересылающий прокси» получает данные с другого веб-сайта от имени исходного запрашивающего.
В качестве примера приведу список из трех компьютеров, подключенных к Интернету.
X = компьютер или «клиентский» компьютер в Интернете.
Y = прокси-сайт, proxy.example.org Z = веб-сайт, который вы хотите посетить www.example.net Обычно можно подключиться напрямую из X --> Z. Однако в некоторых сценариях лучше Y --> Z от имени X, что в цепочке выглядит так: X --> Y --> Z. 2. «Обратный прокси».
Представим себе ту же ситуацию, только на сайте Y настроен обратный прокси.
Обычно можно подключиться напрямую из X --> Z. Однако в некоторых сценариях администратору Z лучше ограничить или запретить прямой доступ и заставить посетителей сначала пройти через Y. Итак, как и раньше, мы получаем данные, полученные Y --> Z от имени X, а именно: X --> Y --> Z. Этот случай отличается от «прямого прокси» тем, что пользователь X не знает, что он обращается к Z, поскольку пользователь X видит, что он общается с Y. Сервер Z невидим для клиентов, и внешне виден только внешний прокси-сервер Y. Обратный прокси-сервер не требует настройки на стороне клиента.
Клиент X думает, что взаимодействует только с Y (X --> Y), но на самом деле Y перенаправляет всю связь (X --> Y --> Z снова).
Далее мы рассмотрим работу с программным балансировщиком.
Какой программный балансировщик выбрать?
По нашему опыту, Nginx — лучший выбор среди программных балансировщиков, поскольку он поддерживает липкие сеансы, а также является одним из наиболее часто используемых веб-серверов, что означает, что он хорошо документирован и достаточно известен среди ИТ-специалистов.Закрепленный сеанс — это метод балансировки нагрузки, при котором клиентские запросы передаются на один и тот же сервер в группе.
В Nginx есть липкий метод, использующий файлы cookie для балансировки, но только в коммерческой версии.
Но есть и бесплатный способ — использование внешних модулей.
Модуль создает файлы cookie и, таким образом, делает каждый браузер уникальным.
Затем файл cookie используется для перенаправления запросов на тот же сервер.
Если cookie нет (например, при первом запросе), сервер выбирается случайным образом.
Подробнее о липком методе можно прочитать на странице эта ссылка , и здесь, в этом Хабрапосте .
Теперь перейдем к практической части.
Инструкции по созданию кластера Jira DataCenter
Для кластеризации вы можете использовать либо существующий экземпляр с установленной Jira, либо новый.В нашем примере будет описана установка новых экземпляров на разные операционные системы (чтобы продемонстрировать универсальность системы).
1. Начнем с сервера базы данных.
Вы можете использовать существующий или создать новый.
Опять же, для иллюстрации была выбрана ОС Windows Server 2016 + PostgreSQL 9.4. Устанавливаем ОС, устанавливаем PG сервер, устанавливаем PG Admin, добавляем пользователя и базу данных.
2. Создайте первый узел в ОС Ubuntu 16.04 LTS. Устанавливаем необходимые пакеты и обновления репозитория.
3. Скачать и устанавливаем Jira DataCenter, запускаем, настраиваем базу данных (на всякий случай в Atlassian есть подробная инструкция).
гид ).
4. Выключите Jira, отключите ноду.
остановка службы jira 5. Для дальнейших манипуляций лучше временно отключить автозапуск Jira: update-rc.d -f jira удалить 6. Клонируйте выключенный узел.
7. Запускаем первую ноду, отключаем Jira (по умолчанию Jira добавляется в автозагрузку после установки).
8. Запускаем вторую ноду, отключаем Jira. 9. Создайте отдельный экземпляр для балансировщика.
Я выбрал Ubuntu 16.04, потому что.
она достаточно быстрая, простая и не требует дополнительных затрат в виде лицензий.
10. Установите nginx (в примере использовалась версия 1.13.4).
11. Скачайте и распакуйте nginx-sticky-module-ng: git-клон bitbucket.org/nginx-goodies/nginx-sticky-module-ng.git 12. Подготовьте nginx к перекомпиляция и добавляем модуль.
13. Скомпилируйте nginx с модулем nginx-sticky-module-ng. В моем случае строка компиляции выглядела так: .
/configure --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib/nginx/modules --conf-path=/etc/nginx/nginx. conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx. pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/ nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/ var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-compat --with-file-aio --with-threads --with-http_addition_module --with-http_auth_request_module --with-http_dav_module - -with-http_flv_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_mp4_module --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-http_stub_status_module - -with-http_sub_module --with-http_v2_module --with-mail --with-mail_ssl_module --with-stream --with-stream_realip_module --with-stream_ssl_module --with-stream_ssl_preread_module --with-cc-opt='-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fPIC' --with-ld-opt='-Wl,-Bsymbolic- функции -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -pie' --add-module=/usr/local/src/nginx-sticky-module-ng 14. Найдите файл /etc/nginx/nginx.conf, скопируйте его в .
bak, настраивать nginx для обратного режима прокси.
15. Далее нам понадобится файловый сервер (желательно тоже отказоустойчивый).
Например, я выбрал сервер Windows, на котором созданный НФС мяч.
16. На каждую ноду устанавливаем пакеты для поддержки NFS: apt-get установить nfs-common 17. Создайте папку /media/jira и выполните: chmod -R 0777 /медиа/Jira 18. Подключите общий ресурс NFS как общий (обязательно монтируйте его не в корневую папку, а, например, в /media/jira) - НА КАЖДОМ УЗЛЕ.
19.1. Далее можно выполнить либо ручной монтаж (однократно): sudo mount -t nfs -O uid=1000,iocharset=utf-8 xx.xx.xx.xx:/exists/media/exists где xx.xx.xx.xx — IP-адрес сервера с общим ресурсом NFS 19.2. Или немедленная автоматическая установка (при запуске ОС): mcedit /etc/fstab В конце нужно добавить строку: 192.168.7.239:/jira/media/jira пользователь nfs,rw 0 0 Затем сохранитесь и выйдите.
20. Присвойте идентификатор: первому узлу node1, второму узлу node2 и так далее.
#Этот идентификатор должен быть уникальным в кластере jira.node.id = узел1 #Расположение общего домашнего каталога для всех узлов Jira jira.shared.home = /media/jira 21. Запустите Jira на первом узле.
запуск службы jira проверять: перейдите в систему -> информация о системе -> найдите включенный кластер и номер узла.
22. Настройка балансировки nginx 23. Т.
к.
мы ранее отключили автозапуск Jira на узлах, то включить его можно командой: update-rc.d -f jira включить 24. Проверьте работу кластера и при необходимости добавьте узлы.
Порядок запуска кластера
1. Включите сервер общей файловой системы.2. Включите балансировщик нагрузки.
3. Включите узел 1.
4. Включите узел 2.
5. …
Кластерный стоп-ордер
1. Остановите Jira на обоих узлах с помощью команды остановки службы Jira. 2. Выключите узел 2. 3. Выключите узел 1. 4. Отключите балансировщик нагрузки.5. Выключите сервер файловой системы.
Вот и все…
Конечно, описанный метод не является единственно правильным.Это лишь один из способов реализации.
Выражаю благодарность коллегам за помощь в подготовке материала.
Комментируйте, задавайте вопросы и спасибо за внимание.
Теги: #Jira #atlassian #atlassian jira #datacenter #Разработка веб-сайтов #Системное администрирование #Управление проектами #atlassian
-
Бывает Такое...
19 Oct, 24 -
О Высшем Образовании
19 Oct, 24
