[venara]

Здравствуйте коллеги,

Столкнулся с интересной задачей -

 

Имеется требование организовать отказоустойчивый кластер серверов Win2012,

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

 

Проблема с отказоустойчивым подключением пользователей к серверам, (как обрабатывать выход из строя Cisco свича или сетевой карты на сервере)

 

У меня имеется (пока еще не свободных) 2 catalyst 3560 (без стекирования)

 

Хочу на серверах объединить 2 интерфейса по технологии NIC Teaming

и подключить к разным 3560 (к портам в одном VLANе)

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

 

Стандартная схема

настройки HSRP предполагает 2 роутера подключенных к 1му свичу к которому подключаются конечные пользователи.

В принципе такая класическая схема соответствует 2м уровням класической 3х уровневой модели CISCO (Access-Destribution-Core)

Но сама Циска пишет что для малых сетей одно устройство может реализовать несколько уровней.

 

Кто реализовал подобные схемы или имеет опыт внедрения HSRP/GLBR

подскажите пожалуйста

ТАКАЯ СХЕМА ВЗЛЕТИТ?

 

Или нужно пускаться во все тяжкие с закупкой стекируемых цисок?

 

Заранее Спасибо :)

[NikAlexAn]

У меня имеется (пока еще не свободных) 2 catalyst 3560 (без стекирования)

 

Хочу на серверах объединить 2 интерфейса по технологии NIC Teaming

и подключить к разным 3560 (к портам в одном VLANе)

Не уверен что это будет работать.

 

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

Для HSRP оба 3560 должны быть в режиме маршрутизатора.

 

Стандартная схема

3560 имеет смысл между собой соединить

 

настройки HSRP предполагает 2 роутера подключенных к 1му свичу к которому подключаются конечные пользователи.

В принципе такая класическая схема соответствует 2м уровням класической 3х уровневой модели CISCO (Access-Destribution-Core)

Но сама Циска пишет что для малых сетей одно устройство может реализовать несколько уровней.

Два 3560 с HSRP - это и будет ваше ядро с L2 и L3, а остальные свичи соединить с каждым из коммутаторов ядра - доступ.

Вполне рабочий вариант.

Правда в ядро напрашиваются 3560G.

[Abram]

venara,

Вместо NIC Teaming использовать bridge + STP. STP же на обоих кошках и дальше.

[venara]

У меня имеется (пока еще не свободных) 2 catalyst 3560 (без стекирования)

 

Хочу на серверах объединить 2 интерфейса по технологии NIC Teaming

и подключить к разным 3560 (к портам в одном VLANе)

Не уверен что это будет работать.

 

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

Для HSRP оба 3560 должны быть в режиме маршрутизатора.

Это само собой,

Но в HSRP 1н роутер активный, а второй курит.

Конечно можно предположить что 2й роутер резервный на столько что ваще не участвует в жизни сети (только ждет когда отвалится активный роутер),

что весьма не эффективно, и полагаю что в Циско это понимают.

По этому предполагаю что 2й роутер (благо это Catalyst а значит априори заточен под коммутацию) сможет таки коммутировать трафик (в резервном режиме).

 

 

Стандартная схема

3560 имеет смысл между собой соединить

Соединить между собой предполагаю по транку, других вариантов не вижу, слота под модуль стекирования на моих 3560 нету :(

собственно по этому и провожу бесчеловечные эксперементы.

 

настройки HSRP предполагает 2 роутера подключенных к 1му свичу к которому подключаются конечные пользователи.

В принципе такая класическая схема соответствует 2м уровням класической 3х уровневой модели CISCO (Access-Destribution-Core)

Но сама Циска пишет что для малых сетей одно устройство может реализовать несколько уровней.

Два 3560 с HSRP - это и будет ваше ядро с L2 и L3, а остальные свичи соединить с каждым из коммутаторов ядра - доступ.

Вполне рабочий вариант.

Правда в ядро напрашиваются 3560G.

Если как по учебнику Ядро(Core) должно выполнять функции магистральной коммутации (между офисами или...)

HSRP это по всем признакам Destribution уровень (межсетевая маршрутизация, ACL, ...)

Чтобы получить отказоустойчивость я должен (ПО ИДЕЕ)

купить 2е 2960g и объединить их в стек (модулями стекирования)

объединить 2 или более портов в Etherchannel (на 2х же свичах)

и подключить их к сетевухам сервера объедененным по NIC Teaming.

 

Хорошо но дорого и сложно (для 2х серверов),

хочу упростить и использовать имеющееся оборудование

 

Но опять же ну уверен,

поженятся Cisco Etherchanel & Microsoft NIC Teaming?

Изменено 23 октября, 2013 пользователем venara

[NikAlexAn]

Вы с задачей и схемой определитесь. Не видно из схемы необходимости в дополнительных маршрутизаторов если есть только локалка с 2мя серверами.

Бюджет озвучьте.

А нужно ли стэкирование и тиаминг сетевых сервера? Что то часто выходит из строя?

В описанной мной схеме резервируется L3 ядро и линки до коммутаторов доступа. Нет смысла в GLBP если один из линков будет заблочен stp, но если у вас несколько ip подсетей в локалке то активным в HSRP в другой подсети можно назначить второй коммутатор, не забыть изменить и рут свич для влана если pvst или для экземпляра если mstp.

Если этого не достаточно - делайте стэк на 3750G и прямо в них втыкайте сервера двумя линками. Тогда линки в коммутаторы доступа можно в etherchannel перевести а не использовать протоколы stp.

Если есть связь с миром или другими офисами удалёнными - добавить к схеме маршрутизатор или два - целесообразность сильно зависит от того сколько и какие у вас каналы связи.

Ну и дальше в зависимости от потребностей и бюджета.

[venara]

venara,

Вместо NIC Teaming использовать bridge + STP. STP же на обоих кошках и дальше.

STP это отказоустойчивость на уровне сети

Мне нужна более широкая отказоустойчивость в которую будут (в 1ю очередь) вовлечены и сервера.

По этому не вариант

[NikAlexAn]

STP это отказоустойчивость на уровне сети

Мне нужна более широкая отказоустойчивость в которую будут (в 1ю очередь) вовлечены и сервера.

По этому не вариант

Какие типы тиаминга поддерживают карты на серверах?.

Насколько я понял предлагается не типа etherchannnel а типа bridge(не знаю может ли такое винда, хотя гипервизор в 2008 вроде умел такое). В таком случае кольцо stp даст вам отказоустойчивость но не будет балансировки нагрузки по картам. Защититься от любых неисправностей в сети - вряд ли возможно при любой схеме.

[venara]

Вы с задачей и схемой определитесь. Не видно из схемы необходимости в дополнительных маршрутизаторов если есть только локалка с 2мя серверами.

Бюджет озвучьте.

А нужно ли стэкирование и тиаминг сетевых сервера? Что то часто выходит из строя?

В описанной мной схеме резервируется L3 ядро и линки до коммутаторов доступа. Нет смысла в GLBP если один из линков будет заблочен stp, но если у вас несколько ip подсетей в локалке то активным в HSRP в другой подсети можно назначить второй коммутатор, не забыть изменить и рут свич для влана если pvst или для экземпляра если mstp.

Если этого не достаточно - делайте стэк на 3750G и прямо в них втыкайте сервера двумя линками. Тогда линки в коммутаторы доступа можно в etherchannel перевести а не использовать протоколы stp.

Если есть связь с миром или другими офисами удалёнными - добавить к схеме маршрутизатор или два - целесообразность сильно зависит от того сколько и какие у вас каналы связи.

Ну и дальше в зависимости от потребностей и бюджета.

 

Извините если не внятно выразился в начале.

Преамбула-

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

Принято решение поставить 2 новых сервера с MS Hyper-V, объединить их в кластер

с участием общей SAN корзины, и перенести все сервера на виртуалки

(по нынешним временам вполне стандартное решение)

 

Проблема с подключением к сети становится более актуалиной, по тому что при отвале 1й сетевухи,

нерабочими станут сразу несколько серверов :(

 

Существующая технология Microsoft NIC Teaming, позволяет обезопасится со стороны сервера,

но остается вероятность отвала свича.

Логичный выход - это (КАК ТО) подключить разные сетевухи на сервере к разным свичам(или маршрутизаторам)

Очевидно что свичи должны быть одинаковыми, имеются 2а потенциальных catalyst3560

В эту сторону и изучаю вопрос.

 

Логичное решение как то использовать HSRP

[NikAlexAn]

Какого рода отказы с сетевыми подключениями?

Почему Hyper-V а не ESXi? Тут, на мой взгляд, единственный довод в пользу MS это если брать лицензию enterprise то можно бесплатно 4 виртуалки поднять (если на гипервизоре нет приложений) или гипервизор и три виртуалки (ну так на 2008r2 вроде было).

Почему SAN а не дисковый массив с подключениями по FC или SAS? Мало проблем с сетевыми подключениями ещё и диски через сеть цеплять?

Если кластер то с одной ноды линки в один коммутатор а со второй ноды в другой коммутатор и линк между коммутаторами вполне решат вопросы отказоустойчивости данной конструкции.

 

HSRP решает вопрос отказоустойчивости шлюза на L3. На L2 - либо stp либо etherchannel на стэк.

Если использовать кластер серверов - для обеспечения доступности сервисов можно и без стэка обойтись наверно. Как там контроль рабочего узла происходит - через межнодовый линк или по ответу на обращения по общему адресу кластера?

[venara]

Вы с задачей и схемой определитесь. Не видно из схемы необходимости в дополнительных маршрутизаторов если есть только локалка с 2мя серверами.

Бюджет озвучьте.

А нужно ли стэкирование и тиаминг сетевых сервера? Что то часто выходит из строя?

В описанной мной схеме резервируется L3 ядро и линки до коммутаторов доступа. Нет смысла в GLBP если один из линков будет заблочен stp, но если у вас несколько ip подсетей в локалке то активным в HSRP в другой подсети можно назначить второй коммутатор, не забыть изменить и рут свич для влана если pvst или для экземпляра если mstp.

Если этого не достаточно - делайте стэк на 3750G и прямо в них втыкайте сервера двумя линками. Тогда линки в коммутаторы доступа можно в etherchannel перевести а не использовать протоколы stp.

Если есть связь с миром или другими офисами удалёнными - добавить к схеме маршрутизатор или два - целесообразность сильно зависит от того сколько и какие у вас каналы связи.

Ну и дальше в зависимости от потребностей и бюджета.

 

Извините если не внятно выразился в начале.

Преамбула-

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

Принято решение поставить 2 новых сервера с MS Hyper-V, объединить их в кластер

с участием общей SAN корзины, и перенести все сервера на виртуалки

(по нынешним временам вполне стандартное решение)

 

Проблема с подключением к сети становится более актуалиной, по тому что при отвале 1й сетевухи,

нерабочими станут сразу несколько серверов :(

 

Существующая технология Microsoft NIC Teaming, позволяет обезопасится со стороны сервера,

но остается вероятность отвала свича.

Логичный выход - это (КАК ТО) подключить разные сетевухи на сервере к разным свичам(или маршрутизаторам)

Очевидно что свичи должны быть одинаковыми, имеются 2а потенциальных catalyst3560

В эту сторону и изучаю вопрос.

 

Логичное решение как то использовать HSRP

[venara]

Какого рода отказы с сетевыми подключениями?

Почему Hyper-V а не ESXi? Тут, на мой взгляд, единственный довод в пользу MS это если брать лицензию enterprise то можно бесплатно 4 виртуалки поднять (если на гипервизоре нет приложений) или гипервизор и три виртуалки (ну так на 2008r2 вроде было).

Почему SAN а не дисковый массив с подключениями по FC или SAS? Мало проблем с сетевыми подключениями ещё и диски через сеть цеплять?

Если кластер то с одной ноды линки в один коммутатор а со второй ноды в другой коммутатор и линк между коммутаторами вполне решат вопросы отказоустойчивости данной конструкции.

 

HSRP решает вопрос отказоустойчивости шлюза на L3. На L2 - либо stp либо etherchannel на стэк.

Если использовать кластер серверов - для обеспечения доступности сервисов можно и без стэка обойтись наверно. Как там контроль рабочего узла происходит - через межнодовый линк или по ответу на обращения по общему адресу кластера?

 

Hyper-V, по тому что у нас очень любят продукты Microsoft, (и по опыту многолетнего использования не напрасно)

даже арендовали 2е DataCentr лицензии по которым на виртуалки можно засунуть все...

К чести микрософт могу добавить что их кластеризация на Hyper-V, работает как из ружья.

Если один сервер падает навзничь то второй начинает отвечать на пинги буквально через 3-5 запросов.

К тому-же аренда лицензий это просто шоколад и для финансистов и для админов.

 

По этому так.

 

Я поиграюсь с 3560 когда они освободятся,

если не выйдет то будем покупать 2е 2960 со стек модулями

и Etherchanel.

 

Напишу как пойдет

[NikAlexAn]

Лучше 3750G