n🐈
как можно для анонса во внешний мир настроить ецмп?)
Size: a a a
2020 February 13
n🐈
всмысле там же нет никаких крутилок
A
как можно для анонса во внешний мир настроить ецмп?)
Зачем?
n🐈
не знаю, я процитировал сообщение выше)
A
Там, видимо, имелся в виду ecmp анонсов с разных балансировщиков внутри as
AS
Я вам (и себе) принес почитать - https://nag.ru/articles/reviews/105272/ecmp-i-prevratnosti-balansirovki-na-setevom-oborudovanii.html
Тут в конце статьи подборка ссылок. Надо изучить, переварить, и потом возобновить обсуждение )
Тут в конце статьи подборка ссылок. Надо изучить, переварить, и потом возобновить обсуждение )
A
перетащил ip - это например haproxy + keepalived + vrrp, и это только внутри одной AS будет работать (или внутри одного зоны в терминах клауда)
Не внутри AS, если что, а внутри L2-домена. AS же с физической топологией сети имеет мало общего (и, уж тем более, не ограничивается AZ в клаудах).
n🐈
зачем для ецмп л2?)
A
зачем для ецмп л2?)
В каком моем сообщении вместе ecmp и l2?
n🐈
ничего не понимаю что происходит)
A
ничего не понимаю что происходит)
Бывает. Про l2 я говорил в ответ на сообщение про vrrp. Ecmp же обсуждался совсем в другом контексте. Смотри, что является реплаем на что.
2020 February 14
LB
Ну, условно. L3-балансировка выглядит так:
1. В разных зонах стоят разные border router'ы, они анонсят один и тот же самый VIP (IP адрес балансера) с одним весом
2. Для анонса настроен ECMP, с помощью которого гарантируется, что трафик из одного sip:sport:dip:dport пройдёт через тот же самый border router
3. Внутри зоны обычно эта схема повторяется в маленьком масштабе, то есть internal bgp, ecmp и так трафик доползает до нужного бекенда. Кроме того есть автоматика, которая проверяет хелсчеки и снимает/поднимает анонсы на iBGP.
4. Анонсы iBGP прорастают в eBGP, что гарантирует, что если внутри зоны что-нибудь анонисится, то этот IP и вовне заанонсится.
Теперь что у вас будет с HTTP/1. У вас десять tcp соединений, каждое из них будет иметь свой sport, что позволит на 10 бекендов рассыпать трафик. С HTTP/2 у вас будет один набор sip:sport:dip:dport и всё посыплется на один бекенд. Альтернатив тут особых нет: сетевое оборудование ничего не знает про http2 streams и никаких железных технологий для этого нет
1. В разных зонах стоят разные border router'ы, они анонсят один и тот же самый VIP (IP адрес балансера) с одним весом
2. Для анонса настроен ECMP, с помощью которого гарантируется, что трафик из одного sip:sport:dip:dport пройдёт через тот же самый border router
3. Внутри зоны обычно эта схема повторяется в маленьком масштабе, то есть internal bgp, ecmp и так трафик доползает до нужного бекенда. Кроме того есть автоматика, которая проверяет хелсчеки и снимает/поднимает анонсы на iBGP.
4. Анонсы iBGP прорастают в eBGP, что гарантирует, что если внутри зоны что-нибудь анонисится, то этот IP и вовне заанонсится.
Теперь что у вас будет с HTTP/1. У вас десять tcp соединений, каждое из них будет иметь свой sport, что позволит на 10 бекендов рассыпать трафик. С HTTP/2 у вас будет один набор sip:sport:dip:dport и всё посыплется на один бекенд. Альтернатив тут особых нет: сетевое оборудование ничего не знает про http2 streams и никаких железных технологий для этого нет
Интересно , облака так не делают. У fastly всё на свичах, bird на каждом сервере и отдельный демон, который mac address переносит с сервера на сервер . У кого-то там maglev, тоже с отдельным демоном. ECMP все сессии рвет при изменении количества нод, клиентам не нравится
AS
Хорошо бы почитать где-то best practices по построению мульти ДЦ инфраструктуры, ориентированной на максимальный HA. Как в применении к собственному железу, так и поверх IaaS (всё на виртуалках, сетевые железки ставить возможности нет).
AS
У меня вот сейчас как раз второй вариант - всё на виртуалках, продублировано в двух ДЦ, а HA между ДЦ - только на хелсчеках и днс на Route53.
AS
Хотелось бы сделать лучше, но вот куда рыпнуться тут можно без бэкграунда в сетях глубокого и без возможности что-то накрутить у хостера, кроме тех самых виртуалок - не очень понятно.
Р
Интересно , облака так не делают. У fastly всё на свичах, bird на каждом сервере и отдельный демон, который mac address переносит с сервера на сервер . У кого-то там maglev, тоже с отдельным демоном. ECMP все сессии рвет при изменении количества нод, клиентам не нравится
Это какие сессии, тспшные? Не очень понимаю, почему ecmp должен их рвать при изменении колва нод
n🐈
не рвет. просто при отсутствии консистент хешинга он твои пакеты в другой бекенд лить начнет
n🐈
это равносильно порванной сессии)
n🐈
на деле он конечно ничего про сессии не знает