DS3512 + LSI SAS6160 - схема подключения

[victor75]

Всем привет!
Решили мы немного озаботиться вопросом подключения доп. серверов к СХД DS3512 SAS с помощью коммутаторов LSI SAS6160.
В результате изобразили следующую схемку (во вложении), но так как на отказоустойчивости у главного небольшой бзик, то появилось несколько вопросов:
1) является ли приведенная схема подключения верной?
2) можно ли подключить каждый SAS коммутатор к контроллерам СХД не двумя кабелями, а четырьмя (8 кабелей всего)? Если да, то в результате получится ли таким образом увеличить пропускную способность от серверов к СХД, или просто создаст излишний геморрой?

[gs]

1. Зачем соединили коммутаторы?
2. 24Гбит/с мало?

[Tert]

victor75
Соединение коммутаторов не нужно, т.к. при падении одного коммутатора у вас прервется линк и на втором, пока он будет переопределять топологию.

[victor75]

1. Зачем соединили коммутаторы?

Это уже будет другой вопрос - про каскадирование коммутаторов

Рядом со стойкой с этим СХД и коммутаторами, будет располагаться вторая стойка, тоже с DS3512 и двумя коммутаторами. Планируется сделать дешевый вариант с резервным восстановлением виртуальных машин, в случае сбоя одной из СХД, на другой СХД, с целью уменьшения времени восстановления. Т.е. бэкапы с СХД DS3512#1 будут храниться на DS3512#2 и наоборот. В случае сбоя DS3512#2 или DS3512#1 мы оперативно разворачиваем виртуалки на оставшейся в живых СХД (место там будет предусмотрено).
Бэкап делается Veeam'ом, если чего.

Из-за ограниченного бюджета придумали соединить каскадом этим четыре коммутатора, примерно как изображено на новой прилагаемой схеме, чтобы бэкап гонять не по сети, а по SAS, ну и чтобы можно было бы маневрировать резервными серверами - т.е. в случае чего имеем один или два резервных (или малонагруженных) сервера, которые могут быть подключены как к одной СХД, так и к другой, через коммутаторы SAS, которые соединены друг с другом каскадом...

2. 24Гбит/с мало?

Я же говорю - у главного бзик на отказоустойчивости и максимизации производительности
Если это излишне, то об этом ему так и доложим

[victor75]

victor75
Соединение коммутаторов не нужно, т.к. при падении одного коммутатора у вас прервется линк и на втором, пока он будет переопределять топологию.

Понял, так и доложим

[gs]

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

И еще интересно - чем Вы собираетесь гонять бэкапы прямо через сас?

[victor75]

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

И еще интересно - чем Вы собираетесь гонять бэкапы прямо через сас?

Бэкап будет делаться Veeam'ом. Есть пара железных серверов, планируется их подключить к SAS коммутаторам, есть еще виртуальные агенты.

Т.е. если я правильно понял, то коммутаторы между стойками желательно соединять так, как на новой схеме?

[gs]

Угу.

[victor75]

Угу.

Спасибо! Так действительно логичнее, чем в первом варианте

[Stranger03]

Спасибо! Так действительно логичнее, чем в первом варианте

Честно говоря глупость. Если бы у вас было 2-а ЦОД-а, было бы понятно, построить 2-е фабрики. Но резервировать САС коммутаторы в одном ЦОД-е, разве что если не хватает САС портов....

[victor75]

Спасибо! Так действительно логичнее, чем в первом варианте

Честно говоря глупость. Если бы у вас было 2-а ЦОД-а, было бы понятно, построить 2-е фабрики. Но резервировать САС коммутаторы в одном ЦОД-е, разве что если не хватает САС портов....

Здесь дело не сколько в резервировании коммутаторов, а в резервировании СХД, чтобы в случае сбоя одной из СХД, все ВМ (или хотя бы самые критически важные из них) можно было бы запустить на второй.
Стойки рядом, СХД рядом, а использование SAS коммутаторов и Veeam - весьма бюджетное, а главное рабочее решение.

И да, портов на СХД таки не хватит, так как к обоим СХД подключат еще хосты.

[Stranger03]

И да, портов на СХД таки не хватит, так как к обоим СХД подключат еще хосты.

У 3524 можно получить:
- 8-мь САС портов, по 4-е на контроллер
- 4-е САС + 8-мь FC (по 4-е на кнонтроллер)
Таким образом без коммутаторов можно подключить 6-ть серверов с резервированием. Вам мало? По любому 3524 не такая уж мощная, чтобы выдержать нагрузку 10-ти и более серверов. И там надо будем над чем-то другим.

[victor75]

И да, портов на СХД таки не хватит, так как к обоим СХД подключат еще хосты.

У 3524 можно получить:
- 8-мь САС портов, по 4-е на контроллер
- 4-е САС + 8-мь FC (по 4-е на кнонтроллер)
Таким образом без коммутаторов можно подключить 6-ть серверов с резервированием. Вам мало? По любому 3524 не такая уж мощная, чтобы выдержать нагрузку 10-ти и более серверов. И там надо будем над чем-то другим.

Это-то да, но главная задача - это именно резервирование СХД.

[Stranger03]

Это-то да, но главная задача - это именно резервирование СХД.

И чем вы собираетесь обеспечивать резервирование? Опции ремоте-миррор не дешовые. Та же Вмварь вместе с Виимом прекрасно умеет бекапить и восстанавливать виртуальные машины, и для этого ей не нужны опции ремоте-миррор. Кроме того, при прямых руках выход из строя СХД крайне маловероятен. Ну а если их 2-е, то восстановить вирт.машину на другой СХД - делов на полчаса - час. Ну а если у вас 2-е СХД, подключив 2-а луна от разных СХД, вы спокойно можете настроить зеркало на уровне ОС.

[victor75]

Это-то да, но главная задача - это именно резервирование СХД.

И чем вы собираетесь обеспечивать резервирование? Опции ремоте-миррор не дешовые. Та же Вмварь вместе с Виимом прекрасно умеет бекапить и восстанавливать виртуальные машины, и для этого ей не нужны опции ремоте-миррор. Кроме того, при прямых руках выход из строя СХД крайне маловероятен. Ну а если их 2-е, то восстановить вирт.машину на другой СХД - делов на полчаса - час. Ну а если у вас 2-е СХД, подключив 2-а луна от разных СХД, вы спокойно можете настроить зеркало на уровне ОС.

Насчет маловероятен - надеюсь что это так, но самолично во время тестирования СХД DS3512 и двух серверов IBM 3650M3 (в течение двух месяцев!) поменял по гарантии: мат. плату на сервере, контроллер на СХД, диск из СХД - наверное не повезло, хотя после этих замен все работает как часы вот уже полтора года (тьфу три раза). В связи с этим было принято от греха подальше подстраховаться, так как в данный момент бэкапы делаются по сети и хранятся на двух железных серверах, и время восстановления всех ВМ в случае полного отказа одной из СХД, составит не менее 10-12 часов (при условии, что на работающей СХД найдется достаточно места).

Что касается того, что мы хотим сделать сейчас, то все очень просто. Так как опции ремоте-миррор действительно недешёвы, то бэкапы ВМ, которые делаются Veeam'ом на СХД DS3512#1, будут теперь храниться на DS3512#2 и наоборот. Бэкапные сервера будут подключены к коммутаторам SAS, сами хосты VMware тоже подключаются к коммутаторам, сами коммутаторы подключаются друг к другу попарно, по схеме выше. В случае сбоя DS3512#2 или DS3512#1, ВМ из бэкапа оперативно разворачиваются на оставшейся в живых СХД (место для восстановления там будет предусмотрено), и все хосты также переключаются на работу с оставшейся СХД. Время восстановления всех ВМ при этом уменьшается до 2-3-х часов, что в принципе приемлемо, так как теперь не нужно их гонять по сети.
Время самого резервного копирования ВМ также уменьшается до каких-то минут, а не часов, так как бэкап теперь будет идти через SAS а не по сети.