Не знал как правильнее сформулировать тему, решил обозвать так как есть.Допустим есть клиент, со своей AS, своя сеть.
Есть два ЦОДа, в каждом стоит по маршрутизатору ЦОДа, который смотрит в инет. К этому маршрутизатору подключается клиентский маршрутизатор.
У клиента в каждом ЦОДе стоит виртуальная машина. В одном ЦОДе рабочая, в другом резервная.
Чтобы ничего не путать, представим, что она отдает просто статический контент и знать о существовании друг друга им необязательно.Задача такая: настроить что-то вроде "disaster recovery" на уровне сети для ЦОДов.
То есть, клиент хочет, чтобы в случае уничтожения ЦОДа, виртуальная машина в резервном ЦОДе начала работать на тех же IP адресах.По сути надо сделать так, чтобы сеть клиентской AS начала анонсироваться со второго ЦОДа в случае падения первого.
Первое, что приходит на ум - анонсировать с обоих маршрутизаторов одинаковые сети, полностью идентично. Тогда обе машины будут задействованы и равны между собой. В случае пропадания одного ЦОДа, в BGP будет светиться только один маршрут. Не возникнет ли проблем при этом?Может быть есть ссылки где описано как это правильно делать по дизайну?
Предложения о том, что лучше резервировать на уровне сервисов или еще какими-то средстави, а не IP лучше не писать. Понимаю, но задача именно такая.
Хотя тут может возникнуть проблема.
В рамках одной TCP сессии пакет может полетить по одному пути на первый сервер, а потом по другому на второй. В этом случае сессия развалится.
> Хотя тут может возникнуть проблема.
> В рамках одной TCP сессии пакет может полетить по одному пути на
> первый сервер, а потом по другому на второй. В этом случае
> сессия развалится.не может, BGP слишком неповоротлив для таких вещей. Просто часть клиентов будет заходить через один канал, часть через другой
какого размера блок PI адресов?
если /24, то можно ли между ЦОДами организовать доп. VPN канал? Если да, то можно ЦОДы объединить по iBGP например, и анонсировать единую DMZ через оба канала.
> какого размера блок PI адресов?
> если /24, то можно ли между ЦОДами организовать доп. VPN канал? Если
> да, то можно ЦОДы объединить по iBGP например, и анонсировать единую
> DMZ через оба канала.Думал про такой вариант, и iBGP между ЦОДами будет. Правда непонятно как настроить конечные роутеры.
Получается что на основном роутере сеть должна анонсироваться, напрямую, на резервном через iBGP. В случае падения iBGP с резервного - напрямую. И выплывает еще момент, что если упадет просто линк между цодами, то каждый из них будет анонсировать.
> Думал про такой вариант, и iBGP между ЦОДами будет. Правда непонятно как
> настроить конечные роутеры.
> Получается что на основном роутере сеть должна анонсироваться, напрямую, на резервном через
> iBGP. В случае падения iBGP с резервного - напрямую. И выплывает
> еще момент, что если упадет просто линк между цодами, то каждый
> из них будет анонсировать.Это вопрос ресурсов и критичности отказоустойчивости сервиса. Если ресурсов достаточно, можно и два канала между ЦОДами сделать.
as-path prepend?
>[оверквотинг удален]
> По сути надо сделать так, чтобы сеть клиентской AS начала анонсироваться со
> второго ЦОДа в случае падения первого.
> Первое, что приходит на ум - анонсировать с обоих маршрутизаторов одинаковые сети,
> полностью идентично. Тогда обе машины будут задействованы и равны между собой.
> В случае пропадания одного ЦОДа, в BGP будет светиться только один
> маршрут. Не возникнет ли проблем при этом?
> Может быть есть ссылки где описано как это правильно делать по дизайну?
> Предложения о том, что лучше резервировать на уровне сервисов или еще какими-то
> средстави, а не IP лучше не писать. Понимаю, но задача именно
> такая.Делал такое на основе http://habrahabr.ru/post/150969/
Время расхождения нового анонса, инициированного от бордера, будет больше чем заранее анонсируемый тот же самый анонс с длинным препендом.
1. В данном случае BGP лишь решает задачу анонсирования сетей. Дальнейшая схема, так или иначе требует стабильной связности между ЦОД, в противном случае, возможно возникновение коллизий.
Итак, мы анонсируем сеть x.x.x.x/x из ЦОД-один (Ц1) и ЦОД-два (Ц2). Я, даже, не думаю, что надо выделять основной/резервный бордер. Зачем? У нас же есть быстрая линия, по которой обеспечивается связность между Ц1 и Ц2. Однако, надо не забыть, что в iBGP следует грамотно выставить приоритеты. Если даже нам не важно, как (куда) придет внешний клиент, надо избежать внутрисетевых коллизий и колец: redistribute/lp и т.д. в руки.2. Следует как-то сообщать где находится резервируемый адрес (пусть это будет x.x.x.10/x). Статика тут не прокатит, по крайней мере, тот же OSPF с экспортом нужного пулла с конкретной машины.
3. Резервирование самого IP - задача, уже фактически, тривиальная - начиная от ucarp...
Что в итоге:
- AS, завязанная на N-ое кол-во операторов связи, пропускающих анонс x.x.x.x/x;
- необходимая связность между машинами, обеспечивающими резервирование конкретного пулла адерсов (один ли это адрес или 100500). Это может быть как VLAN (при директ соединении между Ц1 и Ц2), так и GRE или что-то еще;
- динамический экспорт нужного адреса /32 или пулла адресов на конкретный бордер (в случае отказа ЦОД) или оба роутера (в случае работы всей схемы);
- резервирование сервисов привязывается к конкретной реализации резервирования самого IP.Как-то так.
> Не знал как правильнее сформулировать тему, решил обозвать так как есть.
> Допустим есть клиент, со своей AS, своя сеть.
> Есть два ЦОДа, в каждом стоит по маршрутизатору ЦОДа, который смотрит в
> инет. К этому маршрутизатору подключается клиентский маршрутизатор.
> У клиента в каждом ЦОДе стоит виртуальная машина. В одном ЦОДе рабочая,
> в другом резервная.
> Чтобы ничего не путать, представим, что она отдает просто статический контент и
> знать о существовании друг друга им необязательно.Нужно настроить OSPF между клиентской виртуалкой и клиентским маршрутизатором в каждом ДЦ и между обоими клиентскими маршрутизаторами.
Или vrrp на каждом клиентском маршрутизаторе и OSPF между ними.
Затем по OSPF или eBGP (в зависимости от принадлежности этих IP) анонсировать эти IP маршрутизатору ЦОД.
Или статиком/vrrp прописать эту сеть на маршрутизаторах ЦОД.
Анонсируйте одну сеть по eBGP с обоих ЦОДов. Между ЦОДами используйте iBGP. Так же между ЦОДами используйте какой-нибудь IGP-протокол с редистрибуцией в BGP. Через IGP анонсируйте из обоих ЦОДов одну и ту же сеть, но с разным приоритетом. В этой сети разместите виртуалку с одним и тем же адресом в обоих ЦОДах.Благодаря eBGP будет резервироваться анонсирование в инет, при помощи iBGP будет резервироваться связность ЦОДов. Пока будет жить ЦОД-1, трафик по IGP будет идти к первой виртуалке. Если он выйдет из строя, трафик автоматом пойдёт ко второй виртуалке.
Чтобы решать такую задачу нужно знать приложения. Что у вас там такое стоит, что вам за тридевять земель надо таскать "теже адреса".Бизнес задача какая? Приложения? Сервисы?
Задача эта не новая и имеет множество решений. Причем добрая половина решений этой проблемы к маршрутизации вообще отношения не имеет.
> Чтобы решать такую задачу нужно знать приложения. Что у вас там такое
> стоит, что вам за тридевять земель надо таскать "теже адреса".
> Бизнес задача какая? Приложения? Сервисы?
> Задача эта не новая и имеет множество решений. Причем добрая половина решений
> этой проблемы к маршрутизации вообще отношения не имеет.Сорри за поздний ответ)
Есть такие клиенты, которые спят и видят, что если у них взорвется один цод, то все будет работать из второго при минимуме действий со своей стороны. =)
> Есть такие клиенты, которые спят и видят, что если у них взорвется
> один цод, то все будет работать из второго при минимуме действий
> со своей стороны. =)Повторяюсь конкретный список задачь\сервисов\приложений - конкретное решение.
"Оно само" переключится для незнаю чего с незнаю чем внутри - это фантазии.
>[оверквотинг удален]
> По сути надо сделать так, чтобы сеть клиентской AS начала анонсироваться со
> второго ЦОДа в случае падения первого.
> Первое, что приходит на ум - анонсировать с обоих маршрутизаторов одинаковые сети,
> полностью идентично. Тогда обе машины будут задействованы и равны между собой.
> В случае пропадания одного ЦОДа, в BGP будет светиться только один
> маршрут. Не возникнет ли проблем при этом?
> Может быть есть ссылки где описано как это правильно делать по дизайну?
> Предложения о том, что лучше резервировать на уровне сервисов или еще какими-то
> средстави, а не IP лучше не писать. Понимаю, но задача именно
> такая.Может решение этой задачи - OTV?
otv, dcb, lisp, thousands of them...