Мы у себя рассматривали gitlab-ci как альтернативу jenkins для сборки .net проекта. На текущий момент как ci он нормально работает, но есть пару моментов:
— нельзя задать какое количество сборок, для которых нужно хранить артефакты, только время их хранения.
— сам файл конфигурации хранится в репозитории как результат сложно сделать схему, когда deploy должен быть предварительно одобрен (или в ручную запущен) ограниченным количеством ответственных лиц. Это можно попробовать сделать при помощи protected branch, но никто не мешает разработчику изменить файл в своём бранче и залить что угодно на прод.
В результате как cd его пока использовать сложно.
Если есть у кого-нибудь опыт использования в реалиях, которые я описал, прошу поделиться своим опытом.
Мы используем CEPH как block-storage, Gluster насколько я знаю это именно FileSystem, соответственно тут они не конкуренты.
Основными причинами, почему мы начали использовать Ceph были:
1. Quorum-based система выбора мастера, то есть при 2n+1 нодах split-brain мы не получаем.
2. Самолечение при сбое ( то есть если произошёл отказ ceph сам создаст умершие копии / выведет — введёт osd в кластер и всё само нормализуется через некоторое время)
3. Достаточно детальная документация и адекватная производительность (при условии следования документации — 2 разные сети, одна для виртуалок, вторая под ceph)
ИМХО: кластерная система хранения должна сама отрабатывать сбои, а не требовать вмешательства администратора, всё что я читал про Gluster говорит о том, что он так не умеет.
Расскажите как на CRS125 STP на всех портах сделать.
У меня получилось только если свитч переводить в решим роутера с бриджём, после чего ожидаемо упала производительность.
github.com/aspnet/Home/issues/1093 проблема с OSX и Linux
По поводу красношапки — она вообще в RC1 не поддерживается, о чём написано в информации по релизу
В случае если нужен shared datastore, можно поднять Metadata Server и использовать для этого Ceph FS.
1. CephFS не production-ready
2. При падении основного Metadata сервера, все клиенты, которые работают с ней встают в deadlock на уровне ядра, после этого помогает только перезагрузка, что не есть хорошо
У нас подобная схема не заработала стабильно ибо:
1. Как БД использовали Precona Cluster (master-master) и он не стартовал сам в случае одновременного отключения всех нод и их последующего запуска (отказ по питанию в стойке)
2. У вас в схеме нет shared system datastore / shared file datastore — соответственно не получится загружать файлы ядер или скрипты контекстуализации. Мы делали его сначала на NFS, потом на SAMBA и он перемещался между нодами вместе с OpenNebula тут тоже возникли проблемы из-за невозможности размонтировать rbd т.к. он используется.
3. Проблемы с обновлением OpenNebula т.к. нужно обновлять все ноды.
В итоге пришли к простой схеме:
1. Всё хранится в CEPH
2. OpenNebula + MySQL для неё работают на виртуалке, которая тоже хранится в CEPH
3. На нодах лежит файл для virsh, с описанием виртуалки OpenNebula
4. corosync занимается только тем, что запускает виртуалку с OpenNebula в virsh на одной из нод и следит, чтобы она всегда работала
Как бонус — меньше кластеризованных сервисов — меньше коллизий.
Я знаю про maildir, и dovecot'товские форматы, а также не использую формат mailbox практически нигде (где остался — требования стороннего ПО).
В данном случае я показывал, что как минимум бонус в том чтобы иметь отдельный ящик на каждую учётку, а не общую помойку на всех.
вам exim + dovecot не просто так посоветовали, в этой связке (да и по отдельность) можно хранить данные про учётки (а также сопутствующую информацию) в БД. На выходе получаем возможность заводить учётку при регистрации пользователя на сайте без необходимости менять конфигурацию почтовика, а так же разложенную по учёткам почту (для каждой учётки — свой файл).
В дальнейшем нам лишь останется разобрать, кому и чья почта принадлежит и отдать уже фактическому владельцу на нашем сайте.
Вот тут то и кроются проблемы, если поток почты будет достаточно большой, то ваш файл «для всех» будет быстро распухать, а дальше — либо будет требоваться большое количество RAM для быстрого разбора файла, либо получаем тормоза при чтении почты.
А почему не воспользовались asterisk realtime? Я года 4 назад таким образом управлял очередями через самописную веб админку и не пришлось городить кучу выборок на ael
OpenStack и vCloud какраз я не рекомендую по той причине, что это монстры, которые для поддержания только своей работоспособности требуют немалых ресурсов. OpenNebula же лично у меня прекрасно работает дома, на «сервере», собранном из десктопного железа, который кроме этого является роутером, файл помойкой и торрент качалкой. При этом никакой ощутимой нагрузки она не создаёт ибо представляет из себя посути 2 c++ демона, набор bash/ruby скриптов и web на руби ( остальные компоненты ставятся по желанию ), в отличие от того же OpenStack, состоящего из приличного количества компонентов, в Небуле даже бд по-умолчанию SQLite. Но при этом она даёт возможность комфортного управления виртуалками и всем, что с ними связано, за исключением бэкапов, которые делаются методом snapshot + rsync.
— нельзя задать какое количество сборок, для которых нужно хранить артефакты, только время их хранения.
— сам файл конфигурации хранится в репозитории как результат сложно сделать схему, когда deploy должен быть предварительно одобрен (или в ручную запущен) ограниченным количеством ответственных лиц. Это можно попробовать сделать при помощи protected branch, но никто не мешает разработчику изменить файл в своём бранче и залить что угодно на прод.
В результате как cd его пока использовать сложно.
Если есть у кого-нибудь опыт использования в реалиях, которые я описал, прошу поделиться своим опытом.
Основными причинами, почему мы начали использовать Ceph были:
1. Quorum-based система выбора мастера, то есть при 2n+1 нодах split-brain мы не получаем.
2. Самолечение при сбое ( то есть если произошёл отказ ceph сам создаст умершие копии / выведет — введёт osd в кластер и всё само нормализуется через некоторое время)
3. Достаточно детальная документация и адекватная производительность (при условии следования документации — 2 разные сети, одна для виртуалок, вторая под ceph)
ИМХО: кластерная система хранения должна сама отрабатывать сбои, а не требовать вмешательства администратора, всё что я читал про Gluster говорит о том, что он так не умеет.
У меня получилось только если свитч переводить в решим роутера с бриджём, после чего ожидаемо упала производительность.
Кстати судя по #r именно он и используется для repl в студии
По поводу красношапки — она вообще в RC1 не поддерживается, о чём написано в информации по релизу
github.com/aspnet/Announcements/issues/69
1. CephFS не production-ready
2. При падении основного Metadata сервера, все клиенты, которые работают с ней встают в deadlock на уровне ядра, после этого помогает только перезагрузка, что не есть хорошо
1. Как БД использовали Precona Cluster (master-master) и он не стартовал сам в случае одновременного отключения всех нод и их последующего запуска (отказ по питанию в стойке)
2. У вас в схеме нет shared system datastore / shared file datastore — соответственно не получится загружать файлы ядер или скрипты контекстуализации. Мы делали его сначала на NFS, потом на SAMBA и он перемещался между нодами вместе с OpenNebula тут тоже возникли проблемы из-за невозможности размонтировать rbd т.к. он используется.
3. Проблемы с обновлением OpenNebula т.к. нужно обновлять все ноды.
В итоге пришли к простой схеме:
1. Всё хранится в CEPH
2. OpenNebula + MySQL для неё работают на виртуалке, которая тоже хранится в CEPH
3. На нодах лежит файл для virsh, с описанием виртуалки OpenNebula
4. corosync занимается только тем, что запускает виртуалку с OpenNebula в virsh на одной из нод и следит, чтобы она всегда работала
Как бонус — меньше кластеризованных сервисов — меньше коллизий.
В данном случае я показывал, что как минимум бонус в том чтобы иметь отдельный ящик на каждую учётку, а не общую помойку на всех.
Вот тут то и кроются проблемы, если поток почты будет достаточно большой, то ваш файл «для всех» будет быстро распухать, а дальше — либо будет требоваться большое количество RAM для быстрого разбора файла, либо получаем тормоза при чтении почты.