Как стать автором
Обновить

Комментарии 28

если у нас аплинк по 3G/LTE, то как нам поможет кластер?
Под рукой таких устройств нет, но если 3g-модемы будут установлены в оба устройства, то проблем возникнуть не должно, кмк.
ну так там же ppp и для полноценного failover должна быть поддержка на стороне оператора.

а кластером мы от какой беды пытаемся защититься?
ну у вас будет просто две независимых ppp-сессии, вот и все.

Защититься мы пытаемся от выхода из строя одной из железок, либо от нарушения связности с одним из устройств (т.е. failover происходит как при падении одной из нод, так и по падению портов в redun-группе
Защититься мы пытаемся от выхода из строя одной из железок, либо от нарушения связности с одним из устройств

Это самые простые и наименее вероятные сценарии. Рассматривайте другой сценарий: «control plane встал колом, пакеты не ходят, фейловера нет».
Это не главный бордер в сети, тут достаточно предусмотреть именно эти сценарии.
>ну у вас будет просто две независимых ppp-сессии, вот и все.

так там будут разные адреса и failover будет означать разрыв всех сессий.

>Защититься мы пытаемся от выхода из строя одной из железок

события маловероятные, имхо. гораздо более реалистичны проблемы по питанию, а это требует двух БП и желательно наличие двух вводов.

>либо от нарушения связности с одним из устройств

тогда и свитчи надо резервировать, и опять же — вопросы питания. а так — srx стоят рядом и требуют линка между ними(который тоже надо будет резервировать ведь? :)))

если железки стоят в одной(или соседних) стойке — тут тоже масса проблем.

вообщем, я о том, что честное резервирование подразумевает неслабые вложения в инфраструктуру и вот просто пара железок мало чем помогут. да и ту же задачу можно решить куда более дешевыми способами :)
так там будут разные адреса и failover будет означать разрыв всех сессий

Увы, увы :( Но для меня такой задачи не стояло, и даже девайсов под рукой нет, чтобы можно было как-то протестировать возможные варианты.

события маловероятные, имхо. гораздо более реалистичны проблемы по питанию, а это требует двух БП и желательно наличие двух вводов

В каждой железке два БП «по умолчанию» (в смысле что мы по умолчанию к каждой покупаем второй БП, это очевидные вещи). Они стоят в ЦОДе с резервированием упсами и ДГУ. Так что тут все гуд.

>тогда и свитчи надо резервировать, и опять же — вопросы питания. а так — srx стоят рядом и требуют линка между ними(который тоже надо будет резервировать ведь?
uplink/downlink идут на разные пары коммутаторов, линки между ними — это прямые патчкорды между стойками. В принципе, их тоже можно резервировать — главное, чтобы портов хватило, а то придется еще и карточки интерфейсные покупать ;)

>вообщем, я о том, что честное резервирование подразумевает неслабые вложения в инфраструктуру и вот просто пара железок мало чем помогут. да и ту же задачу можно решить куда более дешевыми способами :)
Я сейчас рассматриваю вполне конкретную модель оборудования и описываю вполне конкретные методы failover, которые она предоставляет. Я не претендую ни разу на всеобъемлющую статью по резервированию сетевой инфраструктуры, способную работать в условиях ядерной войны.
Что-то я вас не понял.
если нужен не просто роутинг/свитчинг, но нечто более «интеллектуальное» (например, те же NAT или IPSec), то без кластера тут точно не обойтись.

Ничего «интеллектуального» в этих технологиях нет. Да, NAT не терпит асимметрии, но на это есть SNAT, синхронизирующий таблицы. Для IPSec единственным правильным решением является создание независимых туннелей на независимых устройствах, желательно по независимым каналам связи, а репликация SA между устройствами не нужна.

Кластеризацией вы лишь создали огромную единую точку отказа в виде единого control plane у кластера. А говорите, хотите крепкого сна… Теперь вы будете со страхом выполнять любые действия на кластере. Особенно — нечто глобальное вроде обновления. А когда есть независимые устройства — просто мягко уводите пакеты с одного из них, делаете на нем что хотите, возвращаете трафик, на пару дней оставляете поработать, потом те же самые действия на другом устройстве выполняете. Без влияния на сервис, без риска положить второе устройство манипуляциями с первым.

В общем, думаю, сейчас эйфория от упрощения администрирования пройдет, и спустя месяцы/годы вы придете к тому, что никогда и нигде не будете иметь дела с кластерами, пока есть хоть какой-то выбор.
Для меня еще важный фактор — это упрощение конфигурации. Я разделяю ваш скепсис по поводу кластеров, так что стараюсь их использовать по минимуму. Однако здесь другой случай — у меня порядка сотни с лишним ipsec-туннелей, делать резервную сессию для каждого — нереально. Отслеживать актуальность всей сотни подключений — тем более. Так что кластеризация в данном случае была необходима, имхо. Про риски вставшего раком control plane знаю, но учитывая, что это не единственный кластер в сети, и cp раком вставал даже у шеститонника в VSS… Считаю это неизбежным злом :)
у меня порядка сотни с лишним ipsec-туннелей

DMVPN. FlexVPN. Какие-нибудь жуниперовские аналоги. В центре будет один туннель. На споках тоже. Пора переходить.
делать резервную сессию для каждого — нереально. Отслеживать актуальность всей сотни подключений — тем более.

На несколько часов развлечений, если руками, и примерно столько же — скриптом. Отслеживать можно любой системой мониторинга или скриптами.
и cp раком вставал даже у шеститонника в VSS

Ага-ага. Я сталкивался с кластерными проблемами на ВСЕХ видах кластеров, включая и ASA, и VSS, и стеки, и так далее.
DMVPN. FlexVPN. Какие-нибудь жуниперовские аналоги. В центре будет один туннель. На споках тоже. Пора переходить.

Конкретизирую — сотня туннелей с сотней разных заказчиков через голый интернет. Тут никаких DMVPN не прокатит
На несколько часов развлечений, если руками, и примерно столько же — скриптом. Отслеживать можно любой системой мониторинга или скриптами.

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

Ой. Сочувствую. Лично у меня что ни туннель со сторонней организацией, то долгий траблшутинг и рекомендации по изменению их конфигурации/архитектуры, так как по ту сторону туннеля обычно сидят не сказать чтобы уж очень компетентные люди (хотя все поголовно — IT компании, большинство — интеграторы).

Тогда, возможно, остается молиться на стабильность кластера.
> Однако здесь другой случай — у меня порядка сотни с лишним ipsec-туннелей, делать резервную сессию для каждого — нереально.

а в чем проблема? неужели вы это руками делаете?

>Отслеживать актуальность всей сотни подключений — тем более.

неужели вы это руками делаете? :)
нуу… может, скажу банальность, но RADIUS?

и у заказчиков тоже всё так же зарезервировано?
а при чем тут RADIUS?
у вас ipsec на сертификатах? psk? или что-то еще?

просто можно за всем этим хозяйством ходить в radius.
на PSK. При этом нужно новые туннели заводить в двух местах сразу, дружить с RADIUS, что само по себе отдельный геморрой, ибо радиус в наличии тока виндовый и админю его не я. Т.е. — еще и радиус свой поднимать. Куда ни кинь — сплошное пложение лишних сущностей
>Для IPSec единственным правильным решением является создание независимых туннелей на независимых устройствах, желательно по независимым каналам связи

вот и я этого не понял :) проще сделать несколько независимых туннелей, а поверх сделать какой-нибудь IGP с быстрой сходимостью.
результат будет тот же, но без вот этого болезненного прикручивания HA к IPSEC.

Так я и говорю, что нужны независимые IPSec туннели с независимых устройств по независимым каналам связи. Внутри туннелей, само собой, IGP.
На дальнем конце туннелей — не мои устройства, так что IGP отпадает
Кстати, кто-то в посте писал про архитектуру, когда IGP при общении с контрагентами — RIP. Первая моя мысль была «идиоты, зачем откапывать и насиловать труп? Закопайте RIP обратно». Вторая мысль — «черт побери, разумно. Протокол DV, легко фильтруемый. Хуже, чем BGP, зато любой шарманкой поддерживается, в отличие от, и сопровождать его несложно. Много анонсов слать не надо, одна сеть туда, одна обратно. Быстрая сходимость не требуется, резерва все равно нет, некуда перемаршрутизировать. Получается, вариантов нет, и особых недостатков подхода тоже».
Возможно и интересно, но есть заказчики, которые и пальцем шевелить не будут ради тебя одного и настраивать динамику. Т.е. с одним-двумя-десятком договориться можно. Когда заказчиком являешься ты, и сам говоришь настройки туннеля (и их немного) — тоже можно. Во всех остальных случаях чем проще, тем лучше
Хорошая статья, спасибо, помогла в некоторых вопросах. Было бы замечательное если бы вы указали если в каком режиме выполняются команды:
edit interfaces
edit chassis cluster
сначала заходите в режим configure.
edit позволяет «зайти» в определённую ветку конфигурации и писать команду уже не от самого начала, а от начала ветки, в которую вы вошли.
Я прошу прощения, а не сталкивались с ситуацией, что одна нода отключена, а на праймари коммит не проходит?

надо траблшутить состояние кластера. Возможно, принудительно погасить HA-линки. Вполне возможно, что нода не опознала, что вторая отвалилась, и пытается на неё закоммитить конфигурацию

Зарегистрируйтесь на Хабре , чтобы оставить комментарий