ну вы же знаете что такое zk и как оно работает, и какие условия set/create

разумеется. Но причём здесь скорость?

нафига?

Потому что мне нужен консул коммуницирующий с общим кластером, а не вся сеть которая была бы mesh сетью.

разумеется. Но причём здесь скорость?

я думал что это основная метрика очередей, поскольку у них функция "бассейна"

Потому что мне нужен консул коммуницирующий с общим кластером, а не вся сеть которая была бы mesh сетью.

давайте начнём с того, что consul cluster — не mesh сеть

Т.е. с точки зрения консула dc1 должен видеть dc2, dc3 а dc2 только dc1

я думал что это основная метрика очередей, поскольку у них функция "бассейна"

бассейн — в не меньшей степени про глубину

давайте начнём с того, что consul cluster — не mesh сеть

Внутри там госсип, который меш. Какая разница?

Внутри там госсип, который меш. Какая разница?

(facepalm)

бассейн — в не меньшей степени про глубину

это плохая мысль, гоните её

Если там не mesh то почему оно себя ведет как mesh?

потому что ведёт себя как raft кластер

Хорошо, но raft кластер ведет себя в mesh стиле

вы путаете

Каждый хочет знать о каждом

gossip / mesh это про модель распространения данных

raft про модель их согласования

Не претендую на исклюительные знания )

я Виталию.

Проблема у меня в том что dc2 хочет сходить в консул который dc3

Это возможно отключить?

Нужно этом мне хотя бы потому что топология сети у меня не такая.

нафига вам вообще consul, если вам не нужен raft?

😭

Виталий! Мне нужен raft в пределах dc1-dc2 И dc1-dc3

ну ок, ладно, терять данные и ронять сервис — это каждый раз весело, и за восстановление после хорошо платят

между DC никакой кластеризации в consul нет

Какой смысл в федерезации тогда?

Какой смысл в федерезации тогда?

какой кейс то изначальный ? может тебе просто 2 кластера консула нужны.

Ща

У меня тут тяжелый случай с бизнесом. Очень сложная топология приложений разнесенных по разным точкам мира. Есть "центральное" а есть подчиненные

если ты хочешь сделать так чтобы в dc1 были все сервисы а в dc2/3 только свои наборы, то от gossip ты никак не избавишься пои идее. но ты можешь сделать acl попытаться на service

И вот надо шареные параметры и некоторые сервисы хранить

Сейчас у меня топология сети построена на VPN как раз как я выше описал

ну вроде это кейс для services acl / keys acl

и там можно сделат default policy для dc

но всё равно, госсипы шляться буду и нужно как то заставить их ходить

Ну вот я вижу оно срёт в сислог и как бы это ноу го

я думал что это основная метрика очередей, поскольку у них функция "бассейна"

для разных задач — разные метрики. В некоторых случаях важно получить отказоустойчивость очереди без даунтайма, и durability операций. А десятков тысяч элементов в секунду — достаточно.

Физической связи между dc2 и dc3 быть не должно и не будет никогда

Как в таком случае заставить госсипы гулять я не представляю

Связь (параметры шареные, например) проиходит через dc1

Физической связи между dc2 и dc3 быть не должно и не будет никогда

то есть связи нет, а данные должны шарить, верно?

Там же у меня центральный MQ кластер

Все верно. dc1 выступает в роли прокси

Все кто хотят получить данные по dc3 приложению — должны спросить об этом dc1 и он ответит.

MQ работает так же. Чтобы насрать в очередь dc3 надо отправить сообщение в exchange dc2, оно улетит в dc1 а dc1 перенаправит в dc3

При чем с RabbitMQ у меня вообще нет таких проблем, такое настроить там как два пальца

так и в чём проблема взять реббит?

Рэббит для чего

Он у нас для шины сообщений используется.

Я хотел использовать кластер консула для сервис дискавери и как бэкенд к волту

Поэтому изначально хотел соеденить в единый консул-кластер

там госсип очень глубоко прошит, поэтому либо патчить, либо роуты настраивать, либо руками делать репликацию.

Ясно, буду значит нужные данные как то сам подсасывать из основного кластера

Интересно, реально ли в dc2/3 в консуле зарегать сервис который будет ходить в консул dc1 и читать оттуда "версию" креденшелов которые мне надо среплецировать. И если изменилось то запускать скрипт перекатки значений

Поидее же это возможно?

просто запускаешь на серваках в dc2/3 агентов которые join к dc1 и там делаешь watch на опредленные сервисы\ключи а вот дёргает скрипт

но честно говоря "странная" схемка )

Так сам видишь — через консул не среплицировать

Я бы рад но у меня dc2/3 визически не имею доступа друг к другу

Ибо там сеть будет шизоидной топлогии тогда

Так хотя бы все понятно в eu-central-1 идти будет.

А да сайты у нас это обычные купоны скидочные )) Чтобы внести диссонанс между сложностью доменной модели и архитектурой сервисов )

ну тогда вариант с агентами в сателитах и вотчами на них которые будут запускать перекачку в "локальный" кластер

тока непонятно чем те не подходит в таком кейсе любая базка умеющая в слейвы и в которой можно ограничить "репликацию". разве что тем что в них свою модель строить и документировать, а в консуле всё уже описано и драйверки есть

Ну консул я планировал просто для SD использовать, а Vault его как бекенд умеет.

@korotovskii а что у вас между регионами гуляет? какого типа отказоустойчивость?

базы данных реплицируются или все реббитом шлется?

Ребит только переслает PK объектов, их тип, типы событий, источник ивента и назначение

Дальше приложение само рулит в какой API за какими данными ему идти (по REST API)

А рекпликация БД как таковая есть между регионами?

Проекты совершенно разные. Зачем там быть прямой репликации?

У них даже схемы баз разные

На случай если один регион накроется, чтобы можно было в другой ходить пользователям

Грубо говоря центральный сайт это CRM для создания купонов и армии редакторов

Какой из регионов накроется?

У нас RDS multi AZ

Денех та дохуя

У нас вот us-east последнее время постоянно дохнет

Что значит дохнет