За почти четырнадцатилетнюю историю использования 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 следующий.
Cредствами MS SQL Server на сервере БД в резервном ЦОДе останавливаем репликацию данных.
На сервере приложения в резервном ЦОДе прекращаем сетевой доступ к отшаренной папке, где установлен Confluence.
Убеждаемся, что в файле confluence.cfg.xml на сервере в резервном ЦОДе указан IP-адрес сервера БД в резервном ЦОДе.
Запускаем Confluence.
В DNS переключаемся на Confluence в резервном ЦОДе и идем смотреть, что там приключилось в основном ЦОДе.
В итоге мы получили возможность перевода сервисов Jira и Confluence в резервный ЦОД в случае проблем в основном ЦОДе за 5-10 минут практически без потери данных. Решение не потребовало материальных вложений на закупку специализированного ПО или железа, все было сделано имеющимися средствами. Теперь нам предстоит решить вопрос с импортозамещением обоих продуктов. С учетом того, что таких проработанных продуктов в реестрах отечественного ПО нет, задача выглядит непростой. Будем делиться изысканиями и успехами на этом пути.
Комментарии (42)
PupkinVasili
21.03.2022 15:37+1Я думаю у разработчиков отечественного ПО хорошие шансы. Ведь много хороших программных продуктов уже написано и много проблем уже решено. Уже заранее известны хорошие и плохие стратегии в архитектуре. Жаль, что первое время прийдется изобретать собственные велосипеды, даже если они будут отличного качества.
meganuke
21.03.2022 15:55А что из них годится на замену Jira/Confluence?
PupkinVasili
21.03.2022 16:02+2Как будно в стране специалистов нет? Напишем свои, назовем как-нибудь, например "Буратино".
Думаю скоро появится много замен, т.к. пока замены нет. Ведь свято место пусто не бывает.
paxlo
21.03.2022 16:18Этого не было написано ранее в более жирные года и бюджеты, а уж теперь и подавно не будет.
PupkinVasili
21.03.2022 16:33+2Ранее был Atlassian и поэтому новое решение продать было некому. А сейчас столько компаний только и ждут и спрашивают "ну где же альтернатива?"
paxlo
21.03.2022 17:43+1>Ранее был Atlassian и поэтому новое решение продать было некому.
Ога. Ранее был мерседес, поэтому хундай, рено, ваз продать было некому. В чистом виде демонстрация принципа "Если у них нет хлеба, пусть едят пирожные"
То, что вменяемые аналоги не появились раньше, это не заслуга жиры, которая якобы всех устраивает. Это неумение создать конкурирующий продукт и криворукость. Опыта создания нет, и сейчас ему тем более неоткуда взяться. Разве что один-в-один сдирать функционал, а потом выдавать за аналоговнетный.
Сбер вон тоже трындит про экосистему и лайфстайл услуги. А на деле в каком отделении карту получали туда и идите. С бумажной копией аусвайса и прочими бумажками в окошко №13.
KirovA
21.03.2022 18:43Ну, справедливости для, - начинать все же с чего-то надо. Возможно, даже и с копирования. Пока копируешь, можно увидеть проблемы продукта и попробовать их решить. Условно, к 15 версии может и получится конкурентоспособный продукт. И тут есть проблема. Проблема потому, что все это импортозамещение нужно делать явно не тогда, когда мировой рынок закрыт, на нем и в лучшие годы российскому ПО было не сладко, а еще позавчера, что называется. И сказки про то, что "столько компаний только и ждут и спрашивают" - не более чем сказки. Рынок ПО в РФ будет сокращаться. Т.к. кредитоспособный заказчик, по-сути, останется один - гос-во и квазигосударственные компании. В таких условиях работать могут только шарашки за еду. Ни о каких прибыльных бизнесах в условиях отсутствия рынка не может быть и речи.
alexander_kuznetsov
22.03.2022 11:55Аналогия с производством машин понятна, но не совсем подходит применительно к IT. Стоимость изготовления новой копии продукта практически равна нулю. Не адаптации под конкретного заказчика, а именно развёртывания готовой системы «из коробки». В результате удачный продукт быстро захватывает ключевую долю рынка, чего физически нельзя сделать в производстве машин.
K0styan
22.03.2022 14:25Так тем более) Если уж даже плохо копируемые (в любом смысле) Лады успешно продавали при наличии на рынке Мерседесов, то качественный софт тем более на рынке место бы нашёл.
KirovA
21.03.2022 16:32Ога, ога.. Все это я уже 20 лет слушаю. Вот сейчас как возьмемся, как роснано заработает, как вот импортозаместимся! Тут вот(https://habr.com/ru/post/656677/) по соседству статья о состоянии отечественной микроэлектроники есть. В принципе, почти все применимо и к ПО. Если коротко, то чтобы написать свою Жыру с Конфой, - нужно еще дофига чего своего писать.
TheRikipm
21.03.2022 16:45Ога, ога.. Все это я уже 20 лет слушаю.
Ранее не было смысла писать аналоги т. к. была доступна джира.
Если коротко, то чтобы написать свою Жыру с Конфой, - нужно еще дофига чего своего писать.
Например?
KirovA
21.03.2022 17:03Например - всё. Это если коротко.
TheRikipm
21.03.2022 17:51Можете привести более конкретный пример?
KirovA
21.03.2022 18:23Нужен ЯП, нужна вменяемая IDE, нужна СУБД, нужна ОС, нужен банальный браузер, в котором пользователь будет отрывать ЖыРус. И во всем этом не должно быть использовано опенсорсное ПО в виду недавних событий.
TheRikipm
21.03.2022 20:23Нужен ЯП
Большинство известных компиляторов и интерпретаторов опенсорсные.
вменяемая IDE
А что, все существующие вменяемые IDE уже перестали продавать в России?
нужна ОС
Тут проблем точно нет.
нужен банальный браузер, в котором пользователь будет отрывать ЖыРус.
Хромиум - опенсорный, даже Яндекс.Браузер на нем сделали. Запретить стандарт ECMAScript в РФ точно никто не сможет.
aegoroff
21.03.2022 22:23Большинство известных компиляторов и интерпретаторов опенсорсные.
Да это не проблема
А что, все существующие вменяемые IDE уже перестали продавать в России?
Перестали - Microsoft и JetBrains остановили продажи в России
Тут проблем точно нет.
Очень спорно - Linux все таки вещь больше для гиков, нежели чем для обычных людей
Хромиум - опенсорный, даже Яндекс.Браузер на нем сделали. Запретить стандарт ECMAScript в РФ точно никто не сможет.
Возможно
aegoroff
21.03.2022 22:19+1В принципе, почти все применимо и к ПО
Применимо, но с софтом не все так печально и сделать все можно сильно быстрее и ГОРАЗДО дешевле чем с микроэлектроникой, для которой нужна прорва времени и денег
JaoDa
21.03.2022 16:35+2Знаю успешный кейс перехода с Jira на опенсорсный Redmine одной крупной компании с сотнями проектов и довольно сложными процессами. В Redmine есть как широкие возможности кастомизации (добавление полей и их взаимозависимости), так и много различных тем (была подобрана тема максимально близкая к Jira). Для простых случаева доступна миграция из коробки.
Уже несколько лет полет нормальный, из плюсов - скорость работы и безперебойность значительно возрасла (не могу сказать заслуга ли это админов или самого Redmine). По функционалу - некоторых вещей первое время не хватало (кое-что дописывали в ручную), но есть очень многое чего нет в Jira.
Moscow_Exchange Автор
21.03.2022 17:28День добрый! Звучит весьма интересно. Сможете поделиться подробностями? Особенно волнует вопрос, как переехать из Jira в Redmine со всем накопленным.
JaoDa
21.03.2022 21:11+1Всех подробностей я не знаю, поэтому попросил вам отписаться человека который непосредственно занимался миграцией.
barloc
21.03.2022 23:53Да просто взять и переехать :)
Как-то приходилось менять систему с багажом в 2 года активной работы. В одном месте через апи выгрузили все нужные данные, конвертнули в новую схему, загрузили - речь про миграцию из трелло в жиру.Бизнес пользователи гораздо дольше будут привыкать к новому интерфейсу, чем технически ехать.
И плюсую за редмайн, он реально классный.
goodbear
22.03.2022 00:47Тоже поддержу, правда у меня обратный кейс, несколько лет назад использовал по работе Redmine, а потом со сменой места работы начал пользоваться Jira / Confluence.
Должен сказать что мнение было не в пользу последнего, так как по скорости работы и удобству в то время лично для меня Redmine был заметно лучше.
aleks_pingvin
21.03.2022 16:54Прошу прощения, а redmine в качестве альтернативы jira или youtrack, не вариант? Он у нас когда то был и если бы не накрылся сервер и бекапы, то и остался бы. Основные вещи он делает, а остальное можно плагинами добить.
P. S> с jira лет 10 назад работал, потому могу просто не знать её киллер фич.
D_Shini
22.03.2022 10:27Мы используем EvaTeam порядка 6 месяцев. Есть 80% необходимого функционала Jira.
Filex
21.03.2022 19:14А репозитории в какой системе у вас? Наверняка bitbucket?
Moscow_Exchange Автор
22.03.2022 12:33+1Jira внедряли в те времена, когда исходники хранились в svn и даже в MS VSS. Потом какие-то проекты переехали в Mercurial, какие-то в Git. Сейчас подавляющее большинство проектов хостится в Git с Gitlabом сверху. Что делать с последним - отдельный вопрос, смотрим опенсорсные тулы.
Filex
22.03.2022 12:59Напишите, пожалуйста, что выбрали и как проходила миграция
Moscow_Exchange Автор
22.03.2022 15:21+1Не совсем поняли, какую миграцию вы имеете в виду - с продуктов Atlassian или с Gitlab. Расскажем и о том, и о другом, как только будут конкретные решения и действия.
skymal4ik
21.03.2022 21:07Много лет искал замену Конфлуенсу, особенно после того, как они убрали возможность хостинга у себя своего инстанса…
Смотрел и dokuwiki, и mediawiki, и redmine, и sphinx.
Но все они по удобству до конфлуенса с draw.io вообще не дотягивают… хотя для многих, в том числе и для меня, подошла бы упрощённая версия с древовидной структурой страниц, версиями страниц и синтаксисом наподобие markdown и возможностью хранить файлы и диаграммы…
Может сейчас кто заполнит эту нишу?)
a0fs
21.03.2022 22:31+1Попробуйте [bookstack](https://www.bookstackapp.com/). Этим приложением завершился мой поиск идеала. Что-то лучше найти уже не надеюсь
zeldigas
21.03.2022 23:48+1Буквально недавно в контексте проработки Docs as code вопроса выяснилось что у draw io есть оффлайн редактор который позволяет все делать вне браузера/конфлюнса сохраняя результат в переносимый svg или png (тоже вроде заявляется что остаётся редактируемым, но не проверял).
В итоге получаем вполне рабочую связку - markup language (markdown, asciidoc) + svg диаграммы. А там заливайте куда нужно (например в тот же confluence) или генерит статический сайт той же анторой.
a-tk
22.03.2022 08:46Умолчим о факте того, что этот оффлайн-редактор таскает за собой браузер.
zeldigas
22.03.2022 11:30Без злого умысла было сделано. Тем не менее это все равно достаточно автономный вариант не отвязывающий от "плагина в конфлюнсе"
И если смотреть по офф сайту ограничений не так много: https://drawio-app.com/use-draw-io-offline/
AkshinM
21.03.2022 21:30+1Схема хороша, мы также сделали у себя, но пошли еще дальше. В отличии от этой схемы, АПП серверы у нас на windows, поэтому репликация идет уровне DFSR. DB сервер один на Jira App и Confluence (пользователей обеих систем много, но DB тянет спокойно) и + reverse proxy сервер, так что юзеры напрямую к jira не подключаются. Best practice это ставить reverse proxy между юзерами и серверами jira.
На уровне MS SQL подняли кластер, условно JiraCluster, и в Availability group добавили оба бд с репликацией. Автоматический failover, отключен конечно же. В connection string обеих конфигураций добавили jiracluster. Это позволяет уже не думать о том какой ip указан, потому что при ручном failover смене primary member DB, IP адрес listener-a автоматически меняется на резервную сетку в Ad DNS. Репликация директории jira_home и conf_home гарантирует полную идентичность конфигурации и прочих файлов, соответственно проверять xml файл нет необходимости.
Сделали отдельный сенсор в мониторинге который проверяет, реально ли происходит репликация, и если нет то посылает алерт, на который мы реагируем.
a-tk
Так ведь битрикс же есть /s
numb
Извините за оффтоп.
Аж скулы свело(