Итак:что такое Consul(для краткости буду писать КО)
первая функция:КО - это сервис обнаружения служб (если у вас много виртуалок или докеров и они ездят
по датацентрам то вам нужно же знать куда и что переехало и на каком порту и ИП это висит,те при переезде новый контейнер докер узнает куда обращаться к БД,или например сменился мастер PgSQL и контейнеры хотят узнать где новый мастерчтоб туда писать или еще что то),
собственно говоря из этого вытекает что для того чтоб знать где эти службы нужно где то хранить данные об этих службах(в самом простом понимании это порт и айпишник),
и тут у нас выплывает вторая функция :
КО - это БД (хранилище) в виде key:value,
третья функция: КО - он делает хелс чеки(health check)(в самом простом понимании можно на хост\порт отправить хттп\днс запрос(например при помощи curl) или какой нить telnet и получить ответ что у него все OK и он работает),и если например сервис не работает то он не отдает о нем данные и отдаст о другом или вообще не отдаст и скажет что все плохо,
четвертая функция: - он распределенный,балансирует свои серваки,может общаться между датацентрами,вообщем high aviability если у нас несколько серваков(от 3х,ниже будет написано...),
ну и понятно из этого что серваки синхронизируют инфу между собой,НО не так просто синхронизирую а по протоколу gossip что в переводе с английского - слухи.На википедии есть целая статья про этот вид протокола общения,в кратце его еще называют протоколом эпидемии,кароче рандомно серваки связываются между собой и отдают инфу кто где и так,через определенные промежутки времени,прям как распостраняются слухи)))
Про Gossip Protocol(кратко госсип):
Из пула выбираются соседи,они меняются инфой,один из них меняет стейт(он получил слух или же заразился эпидемией,как хотите...) ну и потом пошло поехало.Тот который заразился говорит со своим соседом и т д.
Затраты на протокол при этом очень незначительны,на вики написано что в связи с репликацией существует неявная избыточность этой информации.ну хз.может и так.
Собственно говоря если вникнуть в госсип поглубже то два агента первый раз когда встречаются проверяют у себя кэш на наличие какого нить стринга. У одного есть А а у другого Б потом они оба расходятся в кэшэ со стрнгами А и Б. Потом соответственно с информацией что у 1 его есть АБ и у второго есть АБ 1 и 2 агент уже не хотят встречаться с друг другом в ближайщее время потому что слухи знают(у обоих А и Б) и будут встречаться уже с 3 и 4 например.и понеслась...)))...ну и соответственно к каждому стрингу крепится таймстамп так как у агентов могут быть 2 одинаковых слуха и нужно узнать какой старше.
Архитекрура:
Консул агент - это прога которая может быть и клиентом и сервером.
ТЕ Есть только консул агент и ничего больше.В разных ролях.Один бинарник.Все.
Клиент режим агента -- tсли агент в режиме клиента то он просто адресует RPC запросы к серваку получает ответы в виде JSON обьека или ДНС ответа да и делов.
Серверный режим агента -- он может поднимать http или же dns сервак для ответов клиентам а также производить health check и еще плюс к этому находиться в кластере серверов менять свои роли общаться с другими серваками
Госсип протокол:
В каждом датацентре где живет консул есть ЛАН Госсип - это пул всех серваков и клиентов ДЦ.Это сделано для того чтоб клиенты могли делать автоматик дискавер и быстро находить соседей вледствии этого соответственно серваки и наоборот чтоб серваки могли быстро узнавать о клиенте.
С помощю ЛАН госсип быстро происходит распостранение информации.Например о сбое клиента.И эта инфа расшаривается самими клиентами а не только серваками те. когда слухи дойдут до серваком об этом уже могут знать многие клиенты в следствии того чтоб они пытались достучаться до своих соседей или как то достучались и поняли что там что то не так.
Опять же в этом лан будет идет быстрая широковещался на предмет выбора лидера(главного сервака в пуле серверов КО или для быстрой передачи каких либо событий,вообщем это быстро)
В связи с этим можно сказать что КО обеспечивает распределенную систему обнаружения сбоев(как по сервакам так и по клиентам)
ВАН Госсип:
В ВАН пуле участвуют только сервера.Если сервак является членом этого пула то он может посылать запросы как сервакам в своем датацентре так и в другие датацентры.Опять же система обнаружения сбоев позволяет поддерживать датацентр за счет удаленного одного или нескольких датацентров.
По серверам: они едут все на плоту(RAFT протокол) ну типа и у них есть лидер.и серваки синхронятся опять же друг с другом по госсипу и узнают кто лидер и берут всю инфу у лидера(ну и дают конечно же).ТЕ среди серваков лидер знает все что можно!типа главный сервак со всей возможной инфой.
Теперь по РАФТ протоколу:
Рафт протокол базируется на протоколе Паксос.Но он легче и имеет меньше состояний.
Главный компонент протокола - запись в логе.Проблема целостности журнала решается реплицированием лога и если при этом все серваки считают что этот записи в этом логе валидны и расположены в правильной последовательности
Логи ведутся в соответствии с ФСМ или Финит Стейт Машин.Те у логов есть какие то конечные состояния.И есть переходы между ними.Те есть последовательность в журнале.и когда пишется в журнал то позволяется в логе состояние перехода но в итоге все кто получили этот лог должны прийти в тоже состояние в котором и мастер
Набор пиров - это набор сервако в в ЛАН пуле которые разделяют репликацию главного лога
Кворум - если серверов больше 3х то они выбирают лидера кворумом по формуле
(n/2)+1
Завершенная запись - я так понимаю это запись в логе о которой есть инфа что она уже храниться на всех членах пули и только тогда она отдается клиентам.
Лидер - В любой момент времени,пиры выбирает один узел, чтобы он был лидером. Лидер отвечает за записьновых записей,раздачу членам пула своего лога чтоб они его реплицировали
Ноды серверного пула всегда в 3х состояниях:
последователь,кандидат в лидеры и лидер.Каждая нода сначала последователь и в этом состоянии она толкьо получает лог файл и может голосовать,если она не получает от лидера инфы какое то время то нода инициирует голосование и становится кандидатом.Если ее выбрали кворумом она становится лидером и раздает свой лог последователям.Как то так.
Вот так и работает протокол РАФТ.
Если у нас 3 КО то они устойчивы к падению одного ,если 5 то к падению 2х серваков.
Серваки деляться на: повторитель,кандидат в лидеры и лидер.
ЗАПИСЫВАЕТ В кей:велью ТОЛЬКО ЛИДЕР
Сеть:для того чтоб все быстрее работало консул вычисляет вес пути и типа общается с тем кто ближе,по возможности.Это вкратце
Сессия:для получения КВ делаются сесси.
когда нода зарегилась она получила ТТЛ,ИД сессии,набор хелсчеков и стоп-паузу,
чтоб сессия стала невалидной нужно чтобы:
нода дерегистрировалась,
провалились хелсчеки,
хелсчеки ответили что все плохо,
ТТЛ сесси прошел,
И ТОГДА СЕССИЯ УНИЧТОЖИТСЯ
У каждой сесси есть айдишник.
Кароче нода делает чеки и если чеки прошли и все ок то эти чеки пишуться в сессию и при это нода получает доступ к КВ базе данных.Как то так вроде.
Когда сеанс признан недействительным по причине вышепреведенным сессия убивается.
Если вкратце то есть сессии с хелс чеками и без.Если без то это проще.
АЦЛ - с версии 0.4 есть ацл ну тут думаю не стоит даже и описания.все понятно
Анти- этнропия : набор методов чтоб все было упрядочено:
Чтоб понять анти энтропию нужно понять что есть агенты и есть каталог
Агенты САМИ проводят набор своих внутренних хелсчеков и чеков сервисов и локально апдейтят свой статус
Каталог это БД для сервис дискавери те для госсипа и там хранятся все слухи.
Каталог висит только на серверах.Инфы о хелс чеках на нем меньше чем на клиентах потому что там еще есть свои внутренние хелсчеки которые нах каталогу не нужно хранить и если че можно опросить клиента
Анти энтропия состоит в том что агенты ложат в бд инфу о своем состоянии НО НЕ ПОЛНУЮ а просто типа у нас ВСЕ ОК.и потом соответственно сервер распостраняет это инфу везде.как то так.
И еще кроме по ивентам чеки проводятся периодически и проверяется актуальность каталога
КОНТРОЛЬ КОНСУЛА!:
он контролится с помощю КЛИ:
<code>$ consul
usage: consul [--version] [--help] <command> [<args>]
Available commands are:
agent Runs a Consul agent
event Fire a new event
exec Executes a command on Consul nodes
force-leave Forces a member of the cluster to enter the "left" state
info Provides debugging information for operators
join Tell Consul agent to join cluster
keygen Generates a new encryption key
keyring Manages gossip layer encryption keys
leave Gracefully leaves the Consul cluster and shuts down
lock Execute a command holding a lock
members Lists the members of a Consul cluster
monitor Stream logs from a Consul agent
reload Triggers the agent to reload configuration files
rtt Estimates network round trip time between nodes
version Prints the Consul version
watch Watch for changes in Consul
</code>
вот такие простые команда.думаю должно быть все понятно
consul agent -data-dir=/tmp/consul
==> Starting Consul agent...
==> Starting Consul agent RPC...
==> Consul agent running!
Node name: 'Armons-MacBook-Air'
Datacenter: 'dc1'
Server: false (bootstrap: false)
Client Addr: 127.0.0.1 (HTTP: 8500, DNS: 8600, RPC: 8400)
Cluster Addr: 192.168.1.43 (LAN: 8301, WAN: 8302)
Atlas: (Infrastructure: 'hashicorp/test' Join: true)
==> Log data will now stream in as it occurs:
[INFO] serf: EventMemberJoin: Armons-MacBook-Air.local 192.168.1.43
вот мы стартуем самую главную шнягу это консул агент.он стартует и должен присоединится к кластеру.можно вручную а можно авто-джоин сделать.как только он присоединился слух расползся и он попадает в каталоги понеслась.при этом о нем уже знают куча пиров и клиентов.
Ну и теперь наконец то про то как делать запросы:САМОЕ ВАЖНОЕ ДЛЯ ЧЕГО ОН СДЕЛАН!!!)))
можно делать по ДНС а можно по HTTP но по ДНС кроме ИП и порта хуй что получишь а по хттп можно получть больше
$ dig @127.0.0.1 -p 8600 consul.service.consul SRV
; <<>> DiG 9.8.3-P1 <<>> @127.0.0.1 -p 8600 consul.service.consul ANY
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50483
;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;consul.service.consul. IN SRV
;; ANSWER SECTION:
consul.service.consul. 0 IN SRV 1 1 8300 foobar.node.dc1.consul.
;; ADDITIONAL SECTION:
foobar.node.dc1.consul. 0 IN A 10.1.10.12 Вот запрос к серваку по ДНС и он отдает ИП и ПОРТ
остальное допишу завтра.устал...
Комментариев нет:
Отправить комментарий