Просмотр полной версии : LoadBalance и избыточночть на свитчах L2,L3
DarkTemplar
26.10.2009, 15:18
Чёт я совсем запутался.
На сколько я понял, на L3 и L2 реально организовать load balance и избыточность(читай "страховку на случай падения").
Способ №1 (L2) ТОЛЬКО ИЗБЫТОЧНОСТЬ.
spaning tree (STP) по сути самый простой и для ленивых.
Вставляем два линка в порты, а STP сам отключит не нужный линк и подрубит когда надо(когда отвалится активный).
Способ №2 (L2) Избыточность + непонятный LB
interface Etherchannel - по сути самый простой способ load balance. Объединяет несколько интерфейсов в пул и гонит по ним трафик. Однако имеет смысл только если свитчи объединены в стек с использованием cross stack ether channel.
Остается открытым вопрос. Чес именно обеспечить LB на свитчах, не объединенных в стек?
ЗЫ. HSRP как я понял, это решить не сможет. :unsure:
---------- Добавлено в 15:18 ---------- Предыдущее сообщение было написано в 15:15 ----------
о!
Кажется нашёл :oops:
http://www.cisco.com/en/US/tech/tk389/tk213/technologies_tech_note09186a0080094714.shtml
Однако имеет смысл только если свитчи объединены в стек с использованием cross stack ether channel.
Ч0??!! :shock::shock::shock:
DarkTemplar
28.10.2009, 18:34
Etherchannel можно повесить на порты соседних свитчей, объединенных в стек.
вот чо...
---------- Добавлено в 18:34 ---------- Предыдущее сообщение было написано в 18:28 ----------
в догонку:
• Cross-Stack EtherChannel provides the ability to configure Cisco EtherChannel technology across different members of the stack for high resiliency.
http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps5023/product_data_sheet0900aecd80371991.html
мб просто у нас разный смысл вкладывается в слово стек. Для меня это несколько железок с объеденённым управлением и единым конфигом. На пример как 35хх каталисты в стек собираются. (Они правда специальным таким кабелем собираются)
Мне не понятна мысль, что обледенение нескольких ликов в один шланг имеет смысл только в стеке. Или я не так понял ??
обледенение нескольких ликов в один шланг имеет смысл только в стеке.
ну просто в этом случае ты еще и резерв по девайсам получаешь
а не только по линкам
в этом смыле у стэка бонус
т.е. эзерченел (резев по линкам и увеличенная скорость) + резерв по девайсам
при минимальном кол-ве задействованных портов
ребята, стек и резервирование понятия взаимоисключающие,
это аксиома.
slim, т.е. если "бобик сдох", то и "вся свора тоже сдохла" ???
ну и смысл тогда в нём вообще ???
DarkTemplar
29.10.2009, 11:43
ребята, стек и резервирование понятия взаимоисключающие,
это аксиома.
Нука-нука... от сюда по подробнее можно?
Нука-нука... от сюда по подробнее можно?
чего подробнее?
это просто надо запомнить.. :)
slim, т.е. если "бобик сдох", то и "вся свора тоже сдохла" ???
ну и смысл тогда в нём вообще ???
смысл кластера - работа на уровне акцесс,
резервирование акцесса, как вы понимаете - нонсенс..
смысл кластера - "многапортофф" под единым управлением
ну, в общем, да, всё остальное - логично
то-то мне "объединение коммутаторов в стэк (особенно через эзер же)" казалось несколько неестественным
а мысли о резервировании, видимо, оттого, что "стоят рядом два девайса, выполняющие, вобщем-то, одну и ту же функцию"
хмык
slim, очередные спасибы
%-)
DarkTemplar
29.10.2009, 13:41
смысл кластера - работа на уровне акцесс,
резервирование акцесса, как вы понимаете - нонсенс..
Тоесть, если мы берём 4 корда и втыкаем по 2 в Stack'ованные железки, делаем etherchannel - это не резервирование? :unsure:
И, когда выгорает одна железка из двух, а оставшаяся при этом работает и исправно тащит остаток - это тоже не резервирование?
И, когда выгорает два порта из четырех, или один порт из четырёх и т.п.?
А если я к стеку подключаю серверы тоже через etherchannel?
А если я подключаю стек коммутаторов доступа к стеку коммутаторов ядра тоже через etherchannel?
тоесть это всё не резервирование? :shock:
---------- Добавлено в 13:41 ---------- Предыдущее сообщение было написано в 13:38 ----------
то-то мне "объединение коммутаторов в стэк (особенно через эзер же)" казалось несколько неестественным
На сколько я понял стек - это объединение коммутаторов аппаратным линком на уровне ресурсов самой платы коммутатора, а не ethernet.
Тоесть, если мы берём 4 корда и втыкаем по 2 в Stack'ованные железки, делаем etherchannel - это не резервирование?
:whoa:
они уже стекованные, какой ещё эзерченнел? кольца нравятся? :)
И, когда выгорает одна железка из двух, а оставшаяся при этом работает и исправно тащит остаток - это тоже не резервирование?
с каких это пор потеря половины называется у нас резервированием?
И, когда выгорает два порта из четырех, или один порт из четырёх и т.п.?
у тебя хоть раз горели порты? у меня вот ни разу :)
у друга в домой сети горели, ещё как! вместе со свичом, бывало и с материнками клиентов после грозы, бахнувшей по меди, висевшей меж домами
то-то мне "объединение коммутаторов в стэк (особенно через эзер же)" казалось несколько неестественным
ну почему же! если там оконечка какая-нить на порту, то работаем как аксесс
а если заметили свой свич для стекирования, то никакого ethernet уже нет и работает свой внутренний протокол стекирования, такой же, если бы не по эзернету соединялось, а каким-нибудь другим, например вот 3комовский
http://www.mobitrade.ua/img/3Com/33668-190.jpg
какая разница, по каким кабелям гнать стекирование, этот или эзернет?
как-то так
DarkTemplar
29.10.2009, 16:45
они уже стекованные, какой ещё эзерченнел? кольца нравятся?
я имел ввиду crossStack-etherchannel ;) До других коммутаторов или серваков.
с каких это пор потеря половины называется у нас резервированием?
брр... перефразируй вопрос, пожалуйста.
у тебя хоть раз горели порты? у меня вот ни разу
Горели. "Горит" порт, когда выгорает выходной каскад на конкретном гнезде.
какая разница, по каким кабелям гнать стекирование, этот или эзернет?
как-то так
:shock: как это?
пример конфига в студию, когда стек по ethernet'y делается!
как это?
пример конфига в студию, когда стек по ethernet'y делается!
3com, на прошлой работе стек был
модель не помню, но если принципиально - найду, напишу, старая очень.
там 20 или 24 100мбитных порта и 2 гигабитных. Вот в гигабитники можно и другие свичи втыкать, и компы, и будут на гигабите работать. Но если соединить специальным образом (первый гигабитный порт во второй, второй в первый) автоматом стек поднимался и порты из системы пропадали.
или вы про другое разговаривали?
я имел ввиду crossStack-etherchannel До других коммутаторов или серваков.
брр... перефразируй вопрос, пожалуйста.
по ходу, это я не понял тебя :)
И, когда выгорает одна железка из двух, а оставшаяся при этом работает и исправно тащит остаток - это тоже не резервирование?
а две железки соединены etherchannel-ом?
Горели. "Горит" порт, когда выгорает выходной каскад на конкретном гнезде.
а как это происходит? чего бы ему выгорать? и за сколько по времени выгорает?
брак?
DarkTemplar
29.10.2009, 18:22
сначала было сказано:
какая разница, по каким кабелям гнать стекирование, этот или эзернет?
потом
Вот в гигабитники можно и другие свичи втыкать, и компы, и будут на гигабите работать. Но если соединить специальным образом (первый гигабитный порт во второй, второй в первый) автоматом стек поднимался и порты из системы пропадали.
а вот с этим уже всё понятно. сам так делал. только речь не за 3сомы шла, а про cisco.
BTW. кабель - это FTP, STP, UTP но никак не Ethernet. Определись уже в формулировках.
Потому и вопрос был, т.к. не видел я еще в природе свитчей, стекающихся по Ethernet.
а две железки соединены etherchannel-ом?
НЕТ!
только стековым кабелем.
etherchan между стекованными коммутаторами ядра и стекованными коммутаторами доступа или
etherchan между стекованными коммутаторами доступа и серваком(несколькими серверами)
а как это происходит? чего бы ему выгорать? и за сколько по времени выгорает?
брак?
разбирал когда-нибудь коммутаторы?
Там на внешних портах есть распайка кондеев и резисторов. И если по какой-то причине в порт приходит плохое напряжение (причин бывает много. начиная от идиота, заканчивая криво проектированной сетью) выгорают именно эти мелкие детальки. Следствие - порт в дауне.
Тоесть, если мы берём 4 корда и втыкаем по 2 в Stack'ованные железки, делаем etherchannel - это не резервирование? :unsure:
не, я за обычный стек говорю, не за кросс, и не за езерченел..
DarkTemplar
29.10.2009, 18:47
не, я за обычный стек говорю, не за кросс, и не за езерченел..
я имел ввиду такую комбинацию:
|S| |S|
|T|SW1 \ ------------------------- / SW3|T|
|A| ETHERCHAN |A|
|C|SW2 / ------------------------- \ SW4|C|
|K| |K|
SW1,2 - root
SW3,4 - access
вот скажи, зачем тебе вообще нужен именно стек?
storinger
29.10.2009, 19:23
Я встряну слегка :
Стэк нужен для единого управления, для чего ж ещё ?
А cross-stack etherchannel -- как раз для резервирования, тоже вроде бы очевидно. Как линков, так и свитчей.
Порты горят. Ещё как горят, причём обычно не поодиночке, а целыми пачками, что на одной плате. На 3750 -- по 4 в ряд. Лично наблюдал два раза. И если бы не стэк и резевирование, получил бы даунтайм, а так только Warning от мониторинга.
DarkTemplar
29.10.2009, 20:47
Стэк нужен для единого управления, для чего ж ещё ?
А cross-stack etherchannel -- как раз для резервирования, тоже вроде бы очевидно. Как линков, так и свитчей.
Порты горят. Ещё как горят, причём обычно не поодиночке, а целыми пачками, что на одной плате. На 3750 -- по 4 в ряд. Лично наблюдал два раза. И если бы не стэк и резевирование, получил бы даунтайм, а так только Warning от мониторинга.
Storinger!!! Дай я тя пацалуйу!!!! :kiss:
2slim: меня напрягает использовать два девайса с HSRP, вместо того чтобы повысить пропускную способность и организовать LoadBalance. :(
Или HSRP всётаки позволяет реализовать LB?
DarkTemplar, HSRP для роутеров, т.е. L3
если тебе надо LB на L2, то не поможет
DarkTemplar
29.10.2009, 23:54
если тебе надо LB на L2, то не поможет
мне надо LB в принцыпе. А вот как сделать его на L2 я понял (Etherchannel)
А вот на L3?
---------- Добавлено в 23:54 ---------- Предыдущее сообщение было написано в 23:50 ----------
DarkTemplar, HSRP для роутеров, т.е. L3
грей! бросай курить!
сам же сказал, что для L3. А значит и для свитчей подойдёт :)
http://www.cisco.com/en/US/docs/switches/lan/catalyst3750/software/release/12.2_50_se/configuration/guide/swhsrp.html
Кстати про HSRP и LB.
Вот, нарыл Load Sharing with HSRP (http://www.cisco.com/en/US/tech/tk648/tk362/technologies_configuration_example09186a0080094e90 .shtml)
Не совсем LB, но что-то мне подсказывает, что я на верном пути ;)
сам же сказал, что для L3. А значит и для свитчей подойдёт
ну просто ахренительная логика
%-(((
вот тебе про LB и HSRP:
HSRP has no effect on return traffic. The path taken by the return traffic depends on the routing protocol configured on the router.
виноват, неаккуратно выразился
HSRP - для организации надёжности (с применением избыточности)
при этом типовая схема такова, что резервный роутер тупо отдыхает до тех пор, пока жив основной
т.е. один спит, второй базлает
а ты со своим LB хочешь, чтоб оба базлали одновременно
если так - то накой тебе HSRP ???
два роутера, два аплинка
упс, и никакой избыточности - опять "1канал - 1 роутер"
и
плз-плз-плз
прекрати уже путать L2 и L3
ну разные они
идеологически разные
и плз-плз-плз прекрати уже путать L2 и L3 ну разные они идеологически разные
+адын
DarkTemplar
30.10.2009, 09:19
прекрати уже путать L2 и L3
ну разные они
идеологически разные
в каком месте я их спутал? :unsure:
Кстати про HSRP и LB.
Вот, нарыл Load Sharing with HSRP (http://www.cisco.com/en/US/tech/tk648/tk362/technologies_configuration_example09186a0080094e90 .shtml)
Не совсем LB, но что-то мне подсказывает, что я на верном пути ;)
кстати, да.. совсем забыл (вот что значит не юзать хстп),
таким хинтом можно действительно забалансить, практически, трафик..
DarkTemplar
30.10.2009, 10:00
(вот что значит не юзать хстп)
Дим, ты что имел ввиду, говоря "хстп", уточни плс. А то у меня уже моск кипит от количества аббревиатур и сокращений. :)
Дим, ты что имел ввиду, говоря "хстп", уточни плс. А то у меня уже моск кипит от количества аббревиатур и сокращений. :)
это опечатка. hsrp, конечно.
в каком месте я их спутал?
что для L3. А значит и для свитчей подойдёт
ну и повторюсь (из приведённой же ссылки)
HSRP has no effect on return traffic. The path taken by the return traffic depends on the routing protocol configured on the router.
и какое тут LB, которого так хочется, ась ?
DarkTemplar
31.10.2009, 13:05
Цитата:
Сообщение от DarkTemplar
что для L3. А значит и для свитчей подойдёт
эмм... яимел ввиду свитчи с поддержкой L3 еще в топике.
Или в твоём понимании все свитчи L2 only? :shock:
HSRP has no effect on return traffic. The path taken by the return traffic depends on the routing protocol configured on the router.
и какое тут LB, которого так хочется, ась ?
из этой фразы никакого.
Однако, до конца документ мною не изучен, а потому и спорить не буду :tease:
2GrayCat:
там смысловая нагрузка другая:
сказано, что хсрп не влияет на обратный трафик (трудно не согласиться
). естественно, о нем надо позаботится настройкой роутера, но
из этого вовсе не следует, что балансить таким образом невозможно.. :)
из этого вовсе не следует, что балансить таким образом невозможно..
из этого следует, имхо, что "мухи - отдельно, котлеты - отдельно"
о чем изначально и говорилось
т.е. HSRP может _помешать_ построению LB
но его можно "уговорить не мешать"
и - _всё_
сам HSRP никаким боком к LB не относится
ни на L2, ни на L3
В статье про load sharing описано как пустить трафик к серверу по одному пути, а от сервера по другому. Или я чего то не там читаю ??
в случае, когда один из "трафиков" в разу больше (f.e. трафик между пользователем и БДой) такой шаринг нафиг ни кому не упёрся в виду бессмысленности.
сам HSRP никаким боком к LB не относится
согласен, категорически :)
DarkTemplar
03.11.2009, 08:55
Ну, из всего выше сказанного, пока вижу только один вариант решения моей задачи - Etherchannel
помоему для балансировки в цисковских гайдах предлогают для каждого VLAN свой активный HSRP нод, таким образом имея:
два акцес свича, на каждом из которых свой VLAN
два дистриб свича каждый из которых активный для одного из VLAN
и два паралелньных, активных, но не паралельно нагруженых каналов.
как то так вроде?
как офтопик включить?
кстати в последних редакциях гайдов для построения кампусных сетей, упор чуть ли не в каждо предложении на то что каждый акцес свичь имеет свой вилан ( виланы не размазываются по свичам)
и еще, все более уверенно советуют на стыке акцес и дистр использовать L3 :)
n0name, вот ты мне скажи
как соответствует одно другому
каждый акцес свичь имеет свой вилан
на стыке акцес и дистр использовать L3
и вопросов особо больше не будет
%-)
как соответствует одно другому
да никак,
предложение использовать один вилан на один свич в том случае если l3 на дистр. уровне,
а ты этого не понял чтоли? ;)
да никак,
ну драсти
как раз одно с другим связано, имхо
"l3 на дистр. уровне" вообще очень хорошо следует уже из самой модели (коре -дистр - акцес)
т.е. всё вышесказанное - призыв "чётче разделять уровни"
а то на практике как обычно всё размыто и перемешано
ну драсти как раз одно с другим связано, имхо
ну ну, виланы на акцес уровне в случае если на стыке акцес и дистриб уровнях используется L3(L3 порт на акцесе смотрит в L3 порт дистра) теряет всякий смысл, они там никчему
"l3 на дистр. уровне" вообще очень хорошо следует уже из самой модели (коре -дистр - акцес)
L3 на дистр уровне уже давно (в гайдах за 2002 г) рекомендуют и используют,
до этого была модель flat-erth (плоская земля, маршрутизация L3 только на уровне ядра)
маршрутизация L3 только на уровне ядра
дык ты посмотри, на каком уровне ацльки по ип должны быть
в дистре, не правда ли
%-)))
виланы на акцес уровне теряют всякий смысл, если мы кинемся утрировать
типа, если аж целый 1 юзер в локалке - то кор-акцес-дистр нафиг не нужны
как-то мы тут зря оффтопим, имхо
%-(
чета я уже не пойму о чем ты хочешь поспорить,
L3 на всех уровнях предлагается использовать потому что:
1. сходимость протоколов маршрутизации быстрее чем по STP
2. более прозрачна топология, больший контроль над процессами сходимости
3. современные свичи быстро работают на L3 (главный фактор почему L3 раньше не использовался, это медлительность оборудования)
L3 на всех уровнях
ну не на всех, а именно на дистр
да и не спорю я
а лишь пытаюсь уточнить
что это изначально было "разумно и правильно"
%-)
ну не на всех, а именно на дистр
опять двадцать-пять!
L3 на дистр предлогали еще в далеком 2002 году, сейчас же L3 предлагают на акцес, дистр,кор уровнях (НА ВСЕХ!!), вот о чем спич,
и предлагают все это - ребята из циско в своих гайдах
роутед акцесс хорошо, только если не косяк с провиджингом..
L3 предлагают на акцес, дистр,кор уровнях (НА ВСЕХ!!)
ы, ты так бы сразу и сказал
%-)
ну, чего могу сказать
робяты тоже хочут кушать - вот пиарят своё железо
имхо
иначе на кой чёрт в в той же "кампусной сети" этот самый "роутед акцес"
роутед акцесс хорошо, только если не косяк с провиджингом..
разъясни плз.
разъясни плз.
например:
при л2 дизайне - все свитчи заранее конфигурятся,
не важно, какой куда (этаж, здание) подключен,
филд знает только то, что надо подключить вот эти 4 выделенных порта в патч-панель, а остальные порты воткнуть в кросс..
при л3 дизайне, это все дело надо контролировать, т.к. конфигурации не унифицированные, соотв. администрирование кампуса усложняется.. итд..
зато траблшутинг л3 в разы легче, чем л2 и это большой плюс.. :)
мое мнение, что если кампус не большого размера (ну, скажем, до 20 свитчей), то можно и не заморачиваться, с л3.. и наоборот, чем больше растянут л2, тем больше с ним проблем..
мое мнение, что если кампус не большого размера (ну, скажем, до 20 свитчей), то можно и не заморачиваться, с л3.. и наоборот, чем больше растянут л2, тем больше с ним проблем..
:agree:
vBulletin® v3.8.0, Copyright ©2000-2012, Jelsoft Enterprises Ltd. Перевод: zCarot