Комментарии 12
> shared file system
Закапывайте обратно. Это сработает только пока у вас 2 гигабайта аттачей и пара тысяч тикетов.
Закапывайте обратно. Это сработает только пока у вас 2 гигабайта аттачей и пара тысяч тикетов.
Я видел примеры нормальной работы Jira Server, с гораздо бОльшим количеством issue и >100gb аттачами… Правильно спроектированному кластеру такие значения покажутся смешными. У Вас другой опыт? Расскажите, пожалуйста.
Ну как. Если оно стоит в одном ДЦ в одной стойке — тогда работать будет, вестимо. Впрочем, на третьем миллионе тикетов умрет.
Любые shared-storage плохо работают, будучи разнесенными на несколько ДЦ — медленный листинг (а jira его при каких-то операциях делает фоновых), медленная запись итд. Более или менее оно бы жило, если бы использовалось HTTP-based хранилище (S3 или шардированный webdav вообще).
И шардировать базы, как я понял, jira вообще не умеет — рано или поздно любой мастер-сервер БД кончится, а мультимастер пока что сказка, тем более под нагрузками.
Любые shared-storage плохо работают, будучи разнесенными на несколько ДЦ — медленный листинг (а jira его при каких-то операциях делает фоновых), медленная запись итд. Более или менее оно бы жило, если бы использовалось HTTP-based хранилище (S3 или шардированный webdav вообще).
И шардировать базы, как я понял, jira вообще не умеет — рано или поздно любой мастер-сервер БД кончится, а мультимастер пока что сказка, тем более под нагрузками.
Решение проблем географически распределённой инфраструктуры тема для отдельной статьи, я полагаю.
Сервер БД тоже можно кластеризовать.
Сервер БД тоже можно кластеризовать.
«Сервер БД» — можно.
Мастер-сервер БД — по сути нет. Любые multi-master решения деградируют по производительности при большом QPS на запись (галера, в которую пишут в 3 ноды держит меньше qps на запись суммарно, чем если писать только в одну из них). А Jira пишет много, местами даже через край.
Соответственно отсюда и вопрос — умеет ли она шардироваться по базам? Разные очереди задач в разные кластеры БД в самом простом варианте, например.
Мастер-сервер БД — по сути нет. Любые multi-master решения деградируют по производительности при большом QPS на запись (галера, в которую пишут в 3 ноды держит меньше qps на запись суммарно, чем если писать только в одну из них). А Jira пишет много, местами даже через край.
Соответственно отсюда и вопрос — умеет ли она шардироваться по базам? Разные очереди задач в разные кластеры БД в самом простом варианте, например.
А как же GPFS и VxFS?
Емнип, они подороже Jira DE встанут, gpfs уж точно.
Да и зачем, если есть S3 и S3-совместимые решения, которые by-design стабильнее работают вне пределов единственной стойки.
Да и зачем, если есть S3 и S3-совместимые решения, которые by-design стабильнее работают вне пределов единственной стойки.
S3 в ентерпрайзе тоже нечасто встречаются и стоит конских денег, а в AWS нет смысла её разворачивать — можно сразу взять Jira Cloud.
S3 в enterprise — это ceph, который много кто продаёт с саппортом и даже сразу на железе.
Jira Cloud далеко не всем подходит. Она не даст той гибкости в кастомизации, какую предоставят Server или DataCenter редакции. К тому же, для многих крупных компаний остро стоит тема заботы о персональных данных и/или коммерческой тайне, что автоматически блокирует использование облачных решений.
Мне кажется HA не настолько критичен в отличии от SAML 2.0, который тоже есть лишь в дорогущем Data Center.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Jira DataCenter — что это? Как работает? Как развернуть?