Два коммутатора Catalyst 4948 в ядро отказоустойчивой сети

[msdt]

Покритикуйте, пожалуйста, схему. Требуется построить отказустойчивое ядро сети для большого офисного здания и центра обработки данных с некоторым количеством серверов. Сеть будет разбита на вланы по подсетям, маршрутизация между вланами будет на двух Cisco Catalyst 4948 10 Gbit, соединенных десятигигабитным линком и объединенных с помощью VRRP. Сервера будут подключаться двумя гигабитными линками, по одному к каждому каталисту, и агрегированным с помощью 802.3ad. Коммутаторы СКС (скорее всего каталисты 29XX или 35XX) будут соединены в кольцо с включенным STP, концы которого также будет замыкаться на 4948. В СКС может быть несколько вланов. Серверы также будут в разных вланах.

 

 

Возможна ли такая схема? Подходящее ли оборудование выбрано? Может ли работать link aggregation с концами на разных коммутаторах? Можно ли совместно использовать VRRP и link aggregation / STP? Я вполне могу чего-то не понимать, т.к. в основном имел дело с сетями на основе дэлинков, в которых не было ничего сложнее VLAN и STP. Но потребовалось реализовать крупный проект и появились вопросы...

Edited November 24, 2010 by msdt

[darkagent]

почитайте хотя бы про 802.3ad..

обязательно условие оного - подключение типа "точка - точка".

даже педевикия об этом четко говорит

All physical ports in the link aggregation group must reside on the same logical switch, which in most scenarios will leave a single point of failure when the physical switch to which both links are connected goes offline.

[mschedrin]

По-моему такие схемы только интеграторы предлагают :)

[darkagent]

По-моему такие схемы только интеграторы предлагают :)

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

есть подозрение, что и сами 49ые здесь через чур избыточны. Но про ТЗ автор ни слова не упомянул.

 

ах да, обманул.. 802.3ad позволяет подключение типа "точка - многоточка", протоколы, позволяющие это сделать, именуются как SMLT, DSMLT и RSMLT (MLT), только вот сиська их не умеет.

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

 

Edited November 24, 2010 by darkagent

[msdt]

По-моему такие схемы только интеграторы предлагают :)

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

Можно ли чуть развернутее ткнуть меня в наиболее вопиющие ляпы? ;)

 

есть подозрение, что и сами 49ые здесь через чур избыточны. Но про ТЗ автор ни слова не упомянул.

 

ах да, обманул.. 802.3ad позволяет подключение типа "точка - многоточка", протоколы, позволяющие это сделать, именуются как SMLT, DSMLT и RSMLT (MLT), только вот сиська их не умеет.

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

Схема была приведена упрощенная, серверов будет много (до нескольких десятков), некоторые (в перспективе) могут потребовать 10Gbit, СКС будет тоже больше одной, и, кроме этого, будет шлюз в интернет и несколько шифровалок вроде такой для связи с удаленными офисами.

 

Может быть, в ядро вместо пары коммутаторов лучше брать сразу шасси Catalyst 65XX и забивать его по мере необходимости? Или заменить два Cat 4948 на стек из двух шасси Allied Telesis SwitchBlade x908? В последнем случае 802.3ad вроде должен работать.

 

[s.lobanov]

Подключите сервера по bgp, если там bsd или linux. Если нужна бо`льшая скорость сходимости, то можно по ospf, если они под вашим управлением. А ещё лучше резервировать на уровне сервисов, когда один сервер терминируется на одном роутере/L3-свитче, а резервный на другом, но это намного сложнее делать, чем поднимать всякие vrrp и т.п.

 

Про коммутаторы СКС - если есть порты, то лучше сделайте по два линка на каждый, чем кольцо. Тогда можно резервировать дефолт по vrrp, а в случае кольца не очень ясно как будут уживаться vrrp и stp, если заблокированный порт будет посреди кольца(в случае проблем не позавидуешь тому, кто будет диагностировать это безобразие).

[darkagent]

ну уже информации чуток побольше чем было ранее.. что уже не может не радовать.

касательно x908 ничего не скажу - не имел дела с телесисами вобще. и вобщем то не многие с ними имели дело. так что когда встанет вопрос о необходимости консультаций, по 4948 вы получите ответы гораздо оперативнее, и более полные - т.к. по ним вам тут чуть ли не каждый второй раскажет что к чему.

 

ставить вместо двух 4948 одну 65хх - шило на мыло. при цене 4948 в ~5k$, вы упираетесь в бюджет для 65хх в ~10k$. тут вы или собираете б/у, или малопортовку со слабым супом. но если денег не жалко - то собирайте сразу 76ую с rsp720 (3cxl например), и комплектуйте картами с dfc - запас по мощности будете иметь очень хороший.

4948 умеет port-channel (именно он в вашем случае будет поднимать по 2м сетевым одну линию в 2G например) - etherchannel, lacp, pagp; но если вы изначально свяжете 4948 десяткой между собой и сервера будете подключать хорошим патчкордом к хорошей сетевой - вам никакие 802.3ad не понадобятся - будет работать все долго и упорно. если нужно обеспечить Link failover, то копайте в направлении кластеризации серверов, и резервирования на уровне приложений (у некоторых серьезных enterprise applications подобные возможности предусмотрены, в частности в решениях для дата-центров).

 

что же касается адеватных интеграторов - то большая часть времени взаимодействия с ними - это конкретизация и детализация ТЗ до мельчайших подробностей (вплоть до замеров растояний с линейкой), и конечное решение, выдается не в виде одной простой схемки нарисованной в visio, а проектной документацией, объем которой порой превосходит все ожидания. и в таких проектных решениях обычно расписано все до мельчайших подробностей - где какой кабель класть, где какие расходники идут, где какие железки, с какими настройками, и т.д.

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

[LiuPing]

Я предлагаю топикстартеру начать с ТЗ - от чего он хочет защититься такой схемой, какие еще проблемы могут возникать, какая частота возникновения проблем для него критична и сколько можно выделить времени на ее устранение. Часто клиент после того как определится с угрозами, их последствиями и сформулирует требования просто забивает на резервирование т.к. оно становится неактуальным или решается даже административным способом.

[msdt]

Подключите сервера по bgp, если там bsd или linux. Если нужна бо`льшая скорость сходимости, то можно по ospf, если они под вашим управлением.

Про коммутаторы СКС - если есть порты, то лучше сделайте по два линка на каждый, чем кольцо. Тогда можно резервировать дефолт по vrrp, а в случае кольца не очень ясно как будут уживаться vrrp и stp, если заблокированный порт будет посреди кольца(в случае проблем не позавидуешь тому, кто будет диагностировать это безобразие).

Насколько я понимаю, интерфейс коммутатора с назначенным VRRP, перешедшим в режим 'backup', будет работать как обычный коммутируемый интерфейс, т.е. пересылать пакеты на коммутатор с VRRP == 'master'. IMHO stp с vrrp уживутся.

 

Большая часть серверов будет на windows. Вероятно - в виртуалках VMware ESX на блейд-сервере (это уже не моя компетенция). "Обычных" серверов также предостаточно. Самостоятельно администрировать мы будем лишь меньшую их часть. Соответственно, использовать ospf/bgp на серверах будет далеко не всегда возможно.

ставить вместо двух 4948 одну 65хх - шило на мыло. при цене 4948 в ~5k$, вы упираетесь в бюджет для 65хх в ~10k$. тут вы или собираете б/у, или малопортовку со слабым супом. но если денег не жалко - то собирайте сразу 76ую с rsp720 (3cxl например), и комплектуйте картами с dfc - запас по мощности будете иметь очень хороший.

Варианты с б/у в принципе не рассматриваются, и бюджет может быть при необходимости много больше $10000 (хотя хотелось бы придерживаться разумной достаточности, но при этом получить наращиваемое решение).

4948 умеет port-channel (именно он в вашем случае будет поднимать по 2м сетевым одну линию в 2G например) - etherchannel, lacp, pagp; но если вы изначально свяжете 4948 десяткой между собой и сервера будете подключать хорошим патчкордом к хорошей сетевой - вам никакие 802.3ad не понадобятся - будет работать все долго и упорно. если нужно обеспечить Link failover, то копайте в направлении кластеризации серверов, и резервирования на уровне приложений (у некоторых серьезных enterprise applications подобные возможности предусмотрены, в частности в решениях для дата-центров).

Локальная задача - обеспечить бесперебойную работу системы в случае отказа одного из ее компонентов, в данном случае коммутатора ядра сети. Хотя и говорят, что циски сами по себе не дохнут...

что же касается адеватных интеграторов - то большая часть времени взаимодействия с ними - это конкретизация и детализация ТЗ до мельчайших подробностей (вплоть до замеров растояний с линейкой), и конечное решение, выдается не в виде одной простой схемки нарисованной в visio, а проектной документацией, объем которой порой превосходит все ожидания. и в таких проектных решениях обычно расписано все до мельчайших подробностей - где какой кабель класть, где какие расходники идут, где какие железки, с какими настройками, и т.д.

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

Я предлагаю топикстартеру начать с ТЗ - от чего он хочет защититься такой схемой, какие еще проблемы могут возникать, какая частота возникновения проблем для него критична и сколько можно выделить времени на ее устранение. Часто клиент после того как определится с угрозами, их последствиями и сформулирует требования просто забивает на резервирование т.к. оно становится неактуальным или решается даже административным способом.

Цель - предоставить максимально надежную централизованную сетевую инфраструктуру для целого ряда организаций, с минимальным временем простоя в случае аварий или каких-то работ. Думаю, предельно допустимым временем простоя можно считать время не более часа. Реально, даже минутный простой станет большим ЧП.

 

В итоге работа, скорее всего, и будет отдана интегратору. Но хотелось бы и самому прикинуть решение для нашего случая (чтобы получить опыт и адекватно оценивать сторонние предложения).

Edited November 24, 2010 by msdt

[LiuPing]

Если время восстановления час, то за это время можно даже вручную переткнуть все линки в коммутатор из ЗиП.

Поломки надо смотреть по времени средней наработки на отказ, на каталисты такая инфа есть. Возможно здесь вообще не нужно замарачиваться.

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

Edited November 24, 2010 by LiuPing

[dsk]

Интересно, эти расходы потом на ваших арендаторов лягут, типа на эксклюзиве, или же для своих нужд делаете?

[darkagent]

Локальная задача - обеспечить бесперебойную работу системы в случае отказа одного из ее компонентов, в данном случае коммутатора ядра сети. Хотя и говорят, что циски сами по себе не дохнут...

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

если хочется отказоустойчивое ядро - то тут вариантов несколько:

- два ядра в паралели, и четко отлаженная система бэкапа

- одно ядро, но уже с резервирующей платой на борту (если вернуться к варианту с 76й - то тут например можно воткнуть два RSP, и один из них будет сидеть в ожидании, пока другой исправно работает).

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

 

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

Edited November 25, 2010 by darkagent

[Stak]

Картинка красивая, но на 49хх не реализуема.

У нас реализовано нечто подобное, но на 65х в VSS. На 76х multichassis etherchannel поддерживается только на ES-картах.

 

[Telesis]

 

Вот как на SB908 один из вариантов. How To Create Resilient Connections using the Host Attach solution

[Beliar]

Не проще ли релизовать схему на стеке двух 3750X.

Edited November 25, 2010 by Beliar

[darkagent]

Не проще ли релизовать схему на стеке двух 3750X

упустил из виду сию железку, - по описанию очень интересное решение, в частности для описанной топикстартертом задачи.

Cross-Stack EtherChannel provides the ability to configure Cisco EtherChannel technology across different members of the stack for high resiliency.

с наличием StackPower, CS EC - отказоустойчивость "комплекса" получается потрясающей.

Производительности вполне достаточно, чтобы удовлетворить нужды топикстартера, при этом уже никакие vrrp нафик не нужны будут.

[Telesis]

Не проще ли релизовать схему на стеке двух 3750X.

и при отвале 1одго, умирает и второй...

[darkagent]

и при отвале 1одго, умирает и второй...

с чего бы?

[Beliar]

и при отвале 1одго, умирает и второй...

При отвале мастера второй перезагружается, при отвале слейва мастер продолжает работать.

[mschedrin]

Неделю назад у меня стэк из 3750 умер. Проблемы были с одной кошкой, вторая при этом тоже толком не работала. В общем для резервирования эта схема плохо подходит.

[Beliar]

В таком случае любая схема не подходит, если один из узлов работает но криво.

[darkagent]

Неделю назад у меня стэк из 3750 умер. Проблемы были с одной кошкой, вторая при этом тоже толком не работала. В общем для резервирования эта схема плохо подходит.

не исключаю что могут сказаться программно-аппаратные особенности 3750.

все таки 3750-X - это более новое железо, и вероятней всего к нему идет и более свежий софт. имеет смысл хотя бы взять парочку на тестирование и опробовать в лабораторных условиях.

[msdt]

Не проще ли релизовать схему на стеке двух 3750X.

Вариант неплохой, но как тут сказали, стек не гарантирует отказоустойчивости. К тому же я боюсь упереться в ограничения 3750 - число вланов, в которых нужно будет роутить разные подсети, может достигать нескольких сотен (мне навскидку выдали 400), а число хостов - многих тысяч.

 

Кстати, на каких еще каталистах возможно делать стекирование?

[Stak]

Кстати, на каких еще каталистах возможно делать стекирование?

На nexus 7000 МЕС тоже поддерживается :)

[darkagent]

Не проще ли релизовать схему на стеке двух 3750X.

Вариант неплохой, но как тут сказали, стек не гарантирует отказоустойчивости. К тому же я боюсь упереться в ограничения 3750 - число вланов, в которых нужно будет роутить разные подсети, может достигать нескольких сотен (мне навскидку выдали 400), а число хостов - многих тысяч.

описания железок смотрите:

Total VLANs 1005

http://www.cisco.com/en/US/prod/collateral...c78-584733.html

 

Кстати, на каких еще каталистах возможно делать стекирование?

3750, 3750-E, 3750-X - StackWise технология

2960-S - FlexStack технология

2975G - Stack EtherChannel технология.