За почти четырнадцатилетнюю историю использования Jira и Confluence на Московской бирже накопился огромный объем данных: у нас более 350 проектов в Jira и более 200 пространств в Confluence. Не будет преувеличением сказать, что над этими продуктами сейчас работает вся биржа, а не только ИТ-специалисты.
Операционный блок ведет чек-листы регуляторных операций в Confluence, бизнес и аналитики пишут и утверждают функциональные задачи.
Портал проекта, которым управляет Проектный офис, недавно был переведен в Jira. Фактически мы используем продукты Atlassian в режиме, близком к 24*7. Поэтому вопросы резервного копирования, восстановления в случае сбоя и вынужденного простоя для нас уже давно очень актуальны.
В прошлом году мы буквально на коленях сделали теплый резерв Jira и Confluence, о чем и поговорим в этой статье.
Ничего уникального, но чем выше шанс, что наш подход принесет пользу кому-то другому — увы, Atlassian уже начал отзывать лицензии, и неизвестно, что будет дальше.
Как это было
На рисунке ниже показана предыдущая архитектура развертывания, а также механизмы резервного копирования и восстановления:
Как вы знаете, Jira и Confluence хранят пользовательские данные в СУБД и файловой системе.
В случае проблем с основным дата-центром, чтобы запустить Jira или Confluence в резервном дата-центре, необходимо было скопировать базу данных и архив с данными файловой системы на соответствующие серверы в резервном дата-центре, развернуть базу данных, распакуйте архив и запустите службу.
У этого решения есть недостатки.
Во-первых, вы можете потерять боевые данные за сутки, если сбой в основном дата-центре произойдет непосредственно перед созданием копий из базы данных и/или файловой системы Jira или Confluence. Второй недостаток заключается в том, что при необходимости восстановления сервиса в резервном дата-центре время простоя сервиса исчисляется часами, так как резервная копия базы данных Confluence составляет более 100 ГБ, а архивы данных в файле Jira и Confluence. системы под 50 Гб, только копирование и распаковка архивов занимает 2-3 часа.
То есть нужно было как-то решить проблему оперативной доставки обновлений данных в резервный дата-центр.
Как это произошло
На следующем рисунке показана текущая архитектура развертывания, а также механизмы резервирования и репликации:
Репликация данных, хранящихся в СУБД, осуществляется стандартными средствами MS SQL Server ( см.
например
).Для репликации файловой системы была выбрана утилита lsyncd — демон, который отслеживает изменения файлов в локальном дереве каталогов и один раз в некоторое настраиваемое время отправляет изменения в удаленный, локально смонтированный каталог.
В настройках lsyncd можно указать, какие подкаталоги игнорировать (например, нет смысла копировать логи).
О lsyncd вы можете читай здесь .
В плане репликации файловой системы мы пошли немного дальше и реплицируем не только каталоги с данными (вложениями и т.п.
), но и каталоги, в которых установлены сами Jira и Confluence. Таким образом, обновление до новой версии продукта необходимо производить только в основном дата-центре; все будет автоматически скопировано в резервный центр обработки данных.
Старые механизмы резервного копирования один раз в день также работают; мы используем эти резервные копии, если нам нужно обновить данные в тестовой схеме.
В результате использования такой схемы данные реплицируются в резервный дата-центр в течение минуты.
Поднятие сервиса в резервном дата-центре занимает 5-10 минут, в чём мы убедились в ходе DR-тестирования в июле 2021 и январе 2022 года.
Сценарий запуска сервиса в резервном дата-центре на примере Confluence следующий.
- Используя MS SQL Server на сервере базы данных в резервном дата-центре, останавливаем репликацию данных.
- На сервере приложений в резервном дата-центре останавливаем сетевой доступ к общей папке, где установлен Confluence.
- Убеждаемся, что в файле confluence.cfg.xml на сервере в резервном дата-центре указан IP-адрес сервера базы данных в резервном дата-центре.
- Запустим Confluence.
- В DNS переключаемся на Confluence в резервном дата-центре и идем смотреть, что там произошло в основном дата-центре.
Решение не потребовало материальных вложений на приобретение специализированного программного или аппаратного обеспечения; все делалось на имеющиеся средства.
Теперь нам предстоит решить вопрос импортозамещения обеих продуктов.
Учитывая, что в отечественных реестрах ПО таких зрелых продуктов нет, задача выглядит сложной.
Мы поделимся нашими исследованиями и успехами на этом пути.
Теги: #it-инфраструктура #Московская биржа #atlassian #confluence #atlassian jira #moex
-
Астероид
19 Oct, 24 -
Почему Важна Документация Sre. Часть 3
19 Oct, 24 -
Неожиданная История Микропроцессоров
19 Oct, 24 -
Кенгуру Тоже Против Квадрокоптеров
19 Oct, 24 -
Удаление Папок С Подпапками
19 Oct, 24
