[cyberbat]

Здравствуйте!

 

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

У каждого сервера есть горячий резерв: как только какой-то выходит из строя, остальные настроены так, что начинают работать с его дублем. В итоге узким местом остается только тот самый коммутатор. При выходе его из строя вся система горячего резервирования сходит на нет.

Возможно ли как-нибудь организовать горячее резервирование коммутатора? Слышал, что такое бывает, но конкретных методик придумать не могу. Бюджет, предположим, не лимитирован, хотя интересует конечно же оптимальное решение.

 

Заранее спасибо за помощь.

[dazgluk]

Глобально - 2 методики:

 

1. Отказоустойчивый коммутатор с системами резервирования собственных компонентов. (Например Cisco 6500) хотя уверен - есть и более дешевые решения.

 

 

2. Можно воткнуться 2мя сетевыми картами в 2 разных коммутатора и настроить механизм резервирования (MC-LAG, STP, FlexLinks или вообще протокол динамической маршрутизации). Так или иначе в данном случае серверы должны учавствовать в процессе резервирования, и постоянно проверять на живучесть своих соседей через определенный коммутатор. Чисто теоретически можно вообще написать скрипт рода:

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

 

Все зависит от задачи :)

[zhenya`]

и коммутаторы взять что-нить типа 4948 с двумя БП.

[martin74]

vrrp ?

lvs ?

[-Pave1-]

Самый простой и дешевый типовой способ: поставить 2 стекируемых коммутатора и подключить каждый сервер к обоим посредством LACP агрегирования. В качестве коммутатора например Cisco 3750.

Изменено 14 сентября, 2012 пользователем -Pave1-

[mukca]

2 коммутатора в стеке

2 линка от каждого сервера (по линку в коммутаторе)

 

как бы все...

[-Pave1-]

Так или иначе в данном случае серверы должны учавствовать в процессе резервирования, и постоянно проверять на живучесть своих соседей через определенный коммутатор. Чисто теоретически можно вообще написать скрипт рода:

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

 

Зачем городить колхоз из сложных кастомных решений, когда есть простое типовое решение?

LACP решает все поставленные задачи прямо из коробки.

[azhur]

Самый простой и дешевый типовой способ: поставить 2 стекируемых коммутатора и подключить каждый сервер к обоим посредством LACP агрегирования. В качестве коммутатора например Cisco 3750.

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

Это правда или мне "насвистели"?

[NiTr0]

Если нужно обеспечить связь исключительно между серверами - то ИМХО стек городить не нужно, достаточно будет бондинг с 2 линками на 2 коммутатора (соединенных между собой линком на всякий); коммутаторы - исключительно по соображениям кошерности при этом выбираются, по функционалу хватит и мыльниц; их задача - тупо свичевать трафло. Режим - balance-rr или active-backup (LACP скорее всего не заведется, хотя не экспериментировал в таком конфиге).

Да и 3750 - из пушки по воробьям, ставить л3 в роли тупого свича жирновато ИМХО.

[dazgluk]

Так или иначе в данном случае серверы должны учавствовать в процессе резервирования, и постоянно проверять на живучесть своих соседей через определенный коммутатор. Чисто теоретически можно вообще написать скрипт рода:

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

 

Зачем городить колхоз из сложных кастомных решений, когда есть простое типовое решение?

LACP решает все поставленные задачи прямо из коробки.

 

Согласен, про стекируемые свичи я что-то не подумал.

Dlink-DGS3120, дешего и сердито :)

[random7]

Хм, ну а если у каждого сервера есть дубль, то даже два линка у сервера не нужны: можно один сервер подключить к одному коммутатору, второй - к другому.

[Saab95]

А если есть бухта витухи, можно вообще все сервера друг с другом соединить без использования коммутаторов=)

[zhenya`]

2960s тоже может cross stack etherchannel) оно дешевле 3750 :)

Изменено 15 сентября, 2012 пользователем zhenya`

[s2n]

А вот подскажите недорогой, не д-линк, не б/у, л2 коммутатор с поддержкой etherchannel в стэке, на 24*1Gb медных или SFP (как вариант с 2*10Gb SFP+)портов, пожалуйста.

[-Pave1-]

2960s тоже может cross stack etherchannel) оно дешевле 3750 :)

 

Дык сначала речь то об SFP шла.

Дешевле циски экстримы.

[cmhungry]

А вот подскажите недорогой, не д-линк, не б/у, л2 коммутатор с поддержкой etherchannel в стэке, на 24*1Gb медных или SFP (как вариант с 2*10Gb SFP+)портов, пожалуйста.

вроде как 3120 это умеют.

[tester-str]

 

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

Это правда или мне "насвистели"?

Если стек состоит из 2х коммутаторов - да, 3 и более не пробовал.

 

Если нужно обеспечить связь исключительно между серверами - то ИМХО стек городить не нужно, достаточно будет бондинг с 2 линками на 2 коммутатора (соединенных между собой линком на всякий); коммутаторы - исключительно по соображениям кошерности при этом выбираются, по функционалу хватит и мыльниц; их задача - тупо свичевать трафло. Режим - balance-rr или active-backup (LACP скорее всего не заведется, хотя не экспериментировал в таком конфиге).

Да и 3750 - из пушки по воробьям, ставить л3 в роли тупого свича жирновато ИМХО.

 

Плохое решение. При обрыве одного из линков на аплинк или одного из линков на сервере до свитча получите затык.

Тут несколько вариантов:

1. hot-stack свитчей

2. Схема с *STP и на серверах сетевушки объединить в бридж. Только по умолчанию линуксовый бридж фильтрует bpdu-ки, надо патчить и пересобирать. Если нужна более быстрая сходимость - *STP заменить EAPS или что-то похожее.

3. На серверах подымаем квагу, резервируем с помощью OSPF.

Изменено 20 сентября, 2012 пользователем tester-str

[dmvy]

 

2. Схема с *STP и на серверах сетевушки объединить в бридж. Только по умолчанию линуксовый бридж фильтрует bpdu-ки, надо патчить и пересобирать. Если нужна более быстрая сходимость - *STP заменить EAPS или что-то похожее.

 

 

dmvy@dmvy-tn:~$ brctl show br0
bridge name     bridge id               STP enabled     interfaces
br0             8000.000000000000       yes
dmvy@dmvy-tn:~$ brctl showstp br0
br0
bridge id              8000.000000000000
designated root        8000.000000000000
root port                 0                    path cost                  0
max age                  20.00                 bridge max age            20.00
hello time                2.00                 bridge hello time          2.00
forward delay            15.00                 bridge forward delay      15.00
ageing time             300.01
hello timer               0.00                 tcn timer                  0.00
topology change timer     0.00                 gc timer                   0.00
flags

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

[tester-str]

 

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

Да, если RSTP на бридже включить - тоже вполне можно.

Изменено 20 сентября, 2012 пользователем tester-str

[NiTr0]

При обрыве одного из линков на аплинк или одного из линков на сервере до свитча получите затык.

Свичи соединены патч-кордом, так что затык не получится.

[tester-str]

При обрыве одного из линков на аплинк или одного из линков на сервере до свитча получите затык.

Свичи соединены патч-кордом, так что затык не получится.

 

 

Вот схема, линки, начинающиеся с одинакового символьного индекса объедиенены в статические группы для серверов и коммутатора на аплинке:

 

 

 

Навскидку, несколько ситуаций:

1. Алгоритм балансировки определил следующие линки для передачи трафика: A1 -> D -> C2. С аплинка трафик не летит. Если линк С2 будет оборван - передача трафика прекратится.

2. Оборван линк D. Идёт обмен трафиком между серверами. Первый сервер ведёт передачу с линка A1, второй отвечает ему по B2 - в итоге трафик начинает флудится.

3. Broadcast и multicast, прилетающие с аплинка будет туда же и заворачиваться.

[NiTr0]

Алгоритм балансировки...

 

Какой алгоритм балансировки в active-backup (или round robin)?

Насчет LACP аплинка - экспериментировать надо в общем-то. С ходу не скажу, как свич отнесется к фактически соединению LACP портов между собой. Хотя - можно и STP или чем-то подобным на нем обойтись. Особенно если трафик не упирается в гиг.

 

А вот если критичен любой обрыв связи между серверами - то ребутящийся стек это совсем не то, что нужно.

[azhur]

У нас собрана похожая на последний рисунок схема на работе:

Каждый сервер с виртуалками (ESX) подключен к двум свитчам (без стека!), к каждому своей сетевкой (линки а1,а2, б1, б2), прямого линка между свитчаси (д) - нет.

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

На ядрах HSRP плюс RSTP на всех коммутаторах и никакого LACP или статических групп.

В какой из линков запулить исходняк с сервера решает сам ESX, входящий скорее всего летит через 1 линк, но траффику далеко до гигабита, поэтому это не проблема.

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

Что будет если так же подключить сервак без виртуализации - хз, может и заведётся, не пробовали.

Может можно сделать и лучше, но мы не смогли придумать как, и интригатор ничего заметно лучшего не за космические деньги не предложил.