Vxlan на 2 ЦОД.

[myst]

Доброго коллеги, помогите наподумать.

Есть задачка обеспечить катастрофоустройчивость цод, причем на приличном расстоянии (до 5000 км).

Сейчас есть некий цод на нексус фабриках, почти классическое collapsed core и куча филиалов подключенных к бизнесовым ресурсам в ядре. Необходимо убить сразу нескольких кроликов.

1) Сделать резервный ЦОД, но по некоторым внутренним соображениям это возможно только на достаточно удаленном расстоянии

2) Реализовать хотя бы теплое (с горячим такое сложно кмк) резервирование сервисов 

3) Докучи сюда реализовать частичное распределение сервисов (для пула филиалов А приоритетный ЦОД А и сервисы специфичные для этих филиалов там же, для пула филиалов Б... ну вы поняли).

4) В случае отказа одного из ЦОД, все бизнеса автоматом поднимаются из бэкапов/снапшотов во втором цод с теми же адресами, настройками итд. Филиалы соответственно уже статически терминированы и в ЦОД А и в ЦОД Б. Время простоя в таком случае как мне видется это время старта всех сервисов + время на разгребание неучтенки (ну как обычно).

5) Сейчас виртуализация это хайперви (не ко столу будет упомянуто) и виам, но варианты тоже думаются.

 

 

Поскольку у нас КИИ, РФ в забавным законодательством, итд тихонько смотрим в сторону вывода из эксплуатации циско фабрик,  развертывания Клоза, EVPN + vxlan. Но лично я практического опыта с этим не имел, кое-что из прочитанного не складывается.

Например: у нас падает сервис в ЦОД А, каким-то образом (не важно каким)  этот сервис с готового образа поднимается в ЦОД Б.

Как там обрабатывается миграция IP (но не всей подсети) географически и насколько быстро? Я так понимаю туннелируются ARP.

Ещё вопрос: у нас ЦОД А совмещен с ГО, так вот в случае дизастера в ГО нам надо что бы сервисы (тут понятно) и вланы уползали очень избирательно в ЦОД Б, подсети рядовых пользователей ГО там точно не нужны. Посидят, покурят на время дизастера. Я так понимаю указываем что туннелировать во vni?

Ещё важный вопрос одна и та же подсеть, в ней живут сервисы которые расположены и в ЦОД А и в ЦОД Б... Как там будет с доступностью сервисов в ЦОД Б из ГО который присоединен к ЦОД А? Я так понимаю все-таки туннелировать надо.

Ещё вопрос. Туннели от филиалов  до ЦОД А и ЦОД Б треминируются на впн роутеры, внутри предположим (обсуждаемо) ospf. Как будет обрабатываться маршрутная информация если сервис из А уполз в Б. Как филиал узнает куда слать пакет?

 

 

 

 

[jffulcrum]

Половина ваших вопросов очень vendor-specific. Там быстро всплывают всякие зависшие в драфтах rfc (в лучшем случае) или лютая проприетарщина. Честно скажу, я не люблю SDN и порожденных им монстров. Они склонны быстро превосходить возможности людей, которым ими потом управлять, и результатом обычно становятся эпические факапы. Я бы ограничился multi-area OSPF и L2 QinQ между ЦОД - это просто, надежно ожидаемо работает, не прибито гвоздями к вендорам (в любой момент коробку Х нах@й, коробку Y вместо нее) и в этом сможет разобраться любой более-менее специалист за разумное время, тем более нынче половина результатов гугла географически огорожена, и даже по цисковским темам придется через гейропейский VPN гуглить. Необходимая автоматизация делается через трапы и скрипты, инструментария нынче жопой ешь. С нынешними скоростями времена сходимости получаются приемлемыми, если речь не о деревнях Гадюкино Тиходрюченских уездов. Вся та паранойя в книжках обычно относится к временам ISDN связей...

[myst]

14 часов назад, jffulcrum сказал:

Половина ваших вопросов очень vendor-specific. Там быстро всплывают всякие зависшие в драфтах rfc (в лучшем случае) или лютая проприетарщина. Честно скажу, я не люблю SDN и порожденных им монстров. Они склонны быстро превосходить возможности людей, которым ими потом управлять, и результатом обычно становятся эпические факапы. Я бы ограничился multi-area OSPF и L2 QinQ между ЦОД - это просто, надежно ожидаемо работает, не прибито гвоздями к вендорам (в любой момент коробку Х нах@й, коробку Y вместо нее) и в этом сможет разобраться любой более-менее специалист за разумное время, тем более нынче половина результатов гугла географически огорожена, и даже по цисковским темам придется через гейропейский VPN гуглить. Необходимая автоматизация делается через трапы и скрипты, инструментария нынче жопой ешь. С нынешними скоростями времена сходимости получаются приемлемыми, если речь не о деревнях Гадюкино Тиходрюченских уездов. Вся та паранойя в книжках обычно относится к временам ISDN связей...

ну таки тут какраз наоборот, уход от вендор специфик фабрик циско. mp-bgp vxlan isis/ospf вообще ниразу не вендорспецифик, так же как и клоза в которую можно пихать что угодно в отличии "от". И в добавок это не про SDN вообще опять же в отличии "от", хотя оно и упростит жизнь конечно. а вот " L2 QinQ между ЦОД" на 5000 км ожидаемо работать не будет. Вы походу то что я хочу в точности наоборот прочитали.

[VolanD666]

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

[myst]

41 минуту назад, VolanD666 сказал:

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

Тут пока есть место для маневра, хотелось бы хотя бы концептуально определиться, ответить себе на вопросы.

[VolanD666]

Мне кажется, что отказоустойчивость в вашем случае скорее всего будет обеспечиваться га уровне виртуализации, чем на сетевом. Т.е. ваша задача обеспечить надежную сетевую связность между ЦОДами, а уже виртуализация сама будет переключаться. Возможно я ошибаюсь.

[myst]

18 минут назад, VolanD666 сказал:

Мне кажется, что отказоустойчивость в вашем случае скорее всего будет обеспечиваться га уровне виртуализации, чем на сетевом. Т.е. ваша задача обеспечить надежную сетевую связность между ЦОДами, а уже виртуализация сама будет переключаться. Возможно я ошибаюсь.

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

[myst]

Вобщем, до лаб пока не дошло, не понятен один момент, как обрабатывать переезд ВМ(хоста) с одним и тем же адресом из ЦОД А в ЦОД Б с точки зрения маршрутизации? Допустим я выделяю /24 на каждый Leaf. Но в случае переезда хоста в резервный ЦОД мне как-то надо анонсировать специфику /32?

Где-то задним умом понимаю что это надо делать на гипервизорах, но на данный момент в качестве системы виртуализации выступает Hyper-V и беглое гугленье по ключам "hyperv, bgp, vxlan" вообще не дало никаких внятных результатов. 

[VolanD666]

Могу ошибаться, но вроде для этой истории придумали LISP

[jffulcrum]

Так-то пожалуйста, у Cisco вот есть OTV (или как оно там сейчас называется), решающий и L2, и L3. Просто надо продаться вендору по самые помидоры. 

 

 

L2 to L3 Network Migration Concept | RTB House Technical Blog - интересный у людей опыт получился

[myst]

17 часов назад, jffulcrum сказал:

Так-то пожалуйста, у Cisco вот есть OTV (или как оно там сейчас называется), решающий и L2, и L3. Просто надо продаться вендору по самые помидоры. 

 

 

L2 to L3 Network Migration Concept | RTB House Technical Blog - интересный у людей опыт получился

да вот как раз OTV это понятно но в моем случае "продаться вендору" вот вообще не вариант.

 

17 часов назад, VolanD666 сказал:

Могу ошибаться, но вроде для этой истории придумали LISP

не, возникает некая ясность "arp suppression с генерацией /32 + l3 evpn" вроде именно то что мне нужно.