High availability

В твоём случае в качестве говна и палок, думаю, подойдёт только GlusterFS с GeoReplication - http://www.gluster.org/community/documentation/index.php/Gluster_3.2:_Replica...

Чем его приклеивать к докеру я хз, но вот первое что нагуглилось это https://github.com/calavera/docker-volume-glusterfs

ну это репликация фс. А по самим сервисам?

а сервисы то какие?

начиная от базы и апача и заканчивая самописными. но по большей части все доступно через rest

Сервисы - я за Pacemaker, проверенное временем решение. Уверен что и для докера сотоварищи там есть ресурсы.

БЛЯДЬ, вас по голове всех чоле бьют перед регистрацией? докер - ссаный контейнер для сервиса, что он блядь может знать о том, что внутри сервиса происходит? чтобы делать ha для сервисов - сервисы должны уметь разумный healthcheck, а в докере они, в виртуалке, в амазоне или на Луне - мать его, да всем насрать

не нервничай. у докера правда есть подобие кластеризации для контейнеров docker swarm. грубо говоря это дело агрегирует несколько хостов в один и запускает на них контейнеры в зависимости от загрузки/забитости/рандомно. и у него действительно есть service discovery, хотя походу не слишком полноценный.

2 blind_oracle - я думаю что можно сделать ход конем и попытаться скрестить ежа и ужа. Т.е. например etcd следит какие ноды онлайн, swarm переключает контейнеры, а pcmk включает на них сервисы. Хотя профит сомнителен - pcmk может делать это все без дополнительного оркестра. Разве что можно в etcd сервисы регать для маршрутизации

да вы издеваетесь. ha - это когда каждый сервис доступен вне зависимости от нагрузки от него. как, ну вот КАК swarm, который собирает в тупоголовый кластер докеровские контейнеры, поймет что сервиснода в одном из доковских контейнеров встала сама себе на хвост в общении с базой и не сервис уже, а кусок говна в проруби, и её пора убрать нахер из кластера в принудительный ребут, а вместо неё включить другую такую же?

ha - делается по hc, который healthcheck, а не по тупым докеровским мониторингам. иначе это не ha, а профанация, грозящая многомиллионными исками за проеб SLA о котором куча админов типа ТС даже знать не знала, у них же swarm, ептыть

я из-за вас подбухнул, поэтому я вас научу:

ha автоматическими средствами делается только для балансировщиков. которые абсолютно тупые и сделаны в виде в случае RESTа - тредами на какомнить nginx'е, которые занимаются тем, что опрашивают response code и response time от специально для этого написанных эндпоинтов у всех мониторенных сервисов, после чего решают по самописным правилам, стоит его оставить в условном раундробине, или выключить из списка пока он не оклемается и не отрапортует что егоный сервис на вот этом эндпоинте понял что был неправ и исправился.

вот это все говно - делается на балансировщике, а остальные баззворды - делаются для балансировщиков, которые тупые и которых можно отследить средствами того же swarm'а - он и пустит весь траффик на балансировщик который жив. пушшо вот его-то метрикам, тупого треда, оттестированного по самое дальше некуда, можно доверять; косвенным метрикам сервисов, у которых жизненно важные параметры меняются от релиза к релизу - доверять нельзя

анон все сказал, спрашивайте ваши ответы

кэп, спасибо, я знаю что такое ha. и я не писал что докер умеет ha, я сказал что у него есть «подобие кластеризации для контейнеров». я просто хочу посмотреть что может пригодится для моей ситуации помимо того же pcmk

еще раз: в /0 нет такого, что предполагало бы ha для серверов под сервисами, скорее наоборот. единственный правильный ответ на /0 - получаешь статус сервиса от конкретной ноды сервиса и на основании ответа принимаешь решение. если тебе нужна профанация с ha для серверов под сервисами - так бы и писал, чо ты

Еще раз для тех кто в танке - я просто пытаюсь понять что есть из инструментов кроме тех что уже знаю. Про сварм документация довольно странная, потому возник нормальный wtf.

Кстати, сервис-регистратор как раз вполне относится к ha, т.к. он помимо директории может теми самыми самописными проверками следить за доступностью сервиса. У самого докера он куцый, они предлагают юзать etcd/consul.

анонимус тебе верно разьяснил. документация у сворма такая же как сам сворм, делай выводы.

вкратце история такая: если сервисы stateless, плодишь их чем-угодно много, lb сверху, все. если stateful, то в общем случае задача не решается — для каждого сервиса надо отдельно думать как нормально ему обеспечить доступность, и никто не зная подробностей устройства твоих сервисов тебе не расскажет как и что делать. из (относительно) работающих дженерик решений есть разве что FT как в VSphere. все остальное булшит и профанация. инструментов я тут могу сходу штук 100 перечислить, из того же разряда что твои. всех ты их сходу не освоишь, краткую сводку я тебе тоже в одном абзаце не дам. учти что rabbit hole учень глубок, в зависимости от жесткости требований по доступности и масштабируемости, это передний край инженерных проблем современности.

начни с определения требований (must/want, временный и нагрузочные характеристики, рост), архитектуры причастных сервисов, доступных средств. дальше смотри по одному на каждый отдельный сервис что с ним делать, и почему — не забывай про DR еще.

А kubernetes? https://habrahabr.ru/post/258443/

Для сети weave-net http://www.weave.works/products/weave-net/

эта песня хороша, начинай сначала. пойми ты, если ТСу нужен HA - ему не список клонированного бесполезного говна нужен, а четкое понимание того, какой сервис по каким правилам может считаться живым, какое резервирование необходимо для каждого сервиса его конкретной системы с учетом пиковых нагрузок и какое время простоя он может себе позволить. как только у него в голове созреет нормальное ТЗ - он перестанет задавать вопросы вида google://docker+cluster и если и вернется к вам бесполезным - то только с конкретными вопросами, и скорее всего в development. а будет вас слушать - рано или поздно вернется с конкретным вопросом в job

ок, тогда более конкретный вопрос - нормальным ли будет скажем разворачивать все это следующим образом:

• берем сварм/kubernetes и отдаем им на откуп где стартовать тот или иной контейнер (возможно ставим coro+pcmk для выдачи команды на старт контейнера)
• В контейнерах ставим те же coro+pcmk и обмазываем стартом/статусом сервисов, связываем со стартом контейнеров в качестве зависимости (либо через pcmk на хосте если он есть, либо скажем просто ssh с ключом).
• Помимо этого вешаем на каждый хост и, вероятно, контейнер агент etcd с регистратором чтоб понять что на нем запущено и с какими адресами.
• Критические директории загоняем в тот же GlusterFS

меня смущают в таком сценарии две вещи - связка старта контейнера со стартом сервиса и etcd. первое надо просто попробовать, а про второй - какую задержку может создать эта штука для обращающихся к ней сервисов?

В твоём случае в качестве говна и палок, думаю, подойдёт только GlusterFS с GeoReplication

Оно с GR — не мастер-мастер. А ему нужно во все стороны, как понимаю.

Тут только rsyncd+lsyncd. Я много чего мучил, на lsyncd в итоге остановился. Это для файлов. А MySQL неплохо и штатно реплицируется. С GTID — в произвольной топологии.

Хотя надёжность MySQL-репликации мне не очень понравилась. И сейчас экспериментирую с файловой репликацией данных — объекты в JSON и потом синк любым способом, хоть lsyncd, хоть btsync. Файлы тяжёлые вообще через ipfs пробую гонять сейчас, неплохо выходит :)

Мастер мастер это вообще зло, особенно в геораспределенной топологии. Никто не мешает несколько разных томов реплицировать крест-накрест.