Jump to content
Калькуляторы

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

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

 

post-69988-1290609905_thumb.png

 

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

Edited by msdt

Share this post


Link to post
Share on other sites

почитайте хотя бы про 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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
По-моему такие схемы только интеграторы предлагают :)
адекватные интеграторы, даже будучи в сильнейшем опъянении, даже отдаленно похожее на эту схему не предложат.

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

 

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

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

 

Edited by darkagent

Share this post


Link to post
Share on other sites
По-моему такие схемы только интеграторы предлагают :)

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

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

 

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

 

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

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

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

 

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

 

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

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

касательно 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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
Подключите сервера по 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 by msdt

Share this post


Link to post
Share on other sites

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

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

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

Edited by LiuPing

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
Локальная задача - обеспечить бесперебойную работу системы в случае отказа одного из ее компонентов, в данном случае коммутатора ядра сети. Хотя и говорят, что циски сами по себе не дохнут...
циски сами по себе не дохнут, заисключением редких эксклюзивных ситуаций (например 3750 очень болезненно реагируют на резкие перепады напряжения при отсутствующем заземлении).

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

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

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

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

 

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

Edited by darkagent

Share this post


Link to post
Share on other sites

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

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

 

Share this post


Link to post
Share on other sites

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

Edited by Beliar

Share this post


Link to post
Share on other sites
Не проще ли релизовать схему на стеке двух 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 нафик не нужны будут.

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
Неделю назад у меня стэк из 3750 умер. Проблемы были с одной кошкой, вторая при этом тоже толком не работала. В общем для резервирования эта схема плохо подходит.
не исключаю что могут сказаться программно-аппаратные особенности 3750.

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

Share this post


Link to post
Share on other sites
Не проще ли релизовать схему на стеке двух 3750X.
Вариант неплохой, но как тут сказали, стек не гарантирует отказоустойчивости. К тому же я боюсь упереться в ограничения 3750 - число вланов, в которых нужно будет роутить разные подсети, может достигать нескольких сотен (мне навскидку выдали 400), а число хостов - многих тысяч.

 

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

Share this post


Link to post
Share on other sites
Кстати, на каких еще каталистах возможно делать стекирование?

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

Share this post


Link to post
Share on other sites
Не проще ли релизовать схему на стеке двух 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 технология.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this