Задать вопрос

SBB (Storage Bridge Bay) — как построить идеальный NAS?

Кратко о предмете вопроса
Storage Brigde Bay (SBB) — спецификация, созданная Storage Bridge Bay Working Group. Она описывает требования к дисковой полке, к которой непосредственно подключаются различные «контроллеры» (canister), чаще всего представляющие из себя обычный сервер в собственном (также определённом спецификацией) форм-факторе.


Грубо говоря, типичная SBB-полка представляет из себя 2 сервера, соединённых между собой двумя 10Gbps интерфейсами и подключенных к одной дисковой полке общей SAS-шиной с возможностью подключения дополнительных дисковых полок через внешние SAS-интерфейсы.

Дано
SYS-6036ST-6LR.jpg

Самая популярная (и чуть ли не единственная известная) на российском рынке* железка Supermicro 6036ST-6LR, заполненная процессорами/дисками и прочим.
*-по моим наблюдениям

Хочется

Получить отказоустойчивый NAS без излишнего дублирования данных (т.е диски в RAID и никакого DRBD). Данный NAS хочется использовать как хранилище данных NFS/CIFS, iSCSI target и… Вроде всё. Но обязательно, чтобы он был отказоустойчивым.

Имеющиеся мысли

Пока всего одна: грузим ОС с какого-либо внешнего устройства (SATA на плате, например), имеющиеся диски объединяем в RAID-массивы, при помощи LVM делаем VG, нарезаем LV и уже активируем-деактивируем их на каждом из узлов при помощи Pacemaker.

Но есть некоторые сомнения:

1) Непонятно, как поведёт себя iSCSI-инициатор при длительном (до 10 секунд) неответе таргета.

2) Какое количество данных может потеряться при переключении

3) Возможен ли iSCSI multipath при схеме «клиент подключается к двум iSCSI-таргетам, каждый из которых подключается уже по SAS к дискам»?


Есть ли у хабровчан какие-нибудь идеи или use cases?
  • Вопрос задан
  • 5582 просмотра
Подписаться 3 Оценить Комментировать
Пригласить эксперта
Ответы на вопрос 1
amc
@amc
Вы не совсем корректно смотрите на ситуацию. Вам нужен отказоустойчивый iSCSI Target, а не несколько. Хороший пример Fail-over iSCSI Target есть в WinSvr2012+, рекомендую ознакомится, даже если вы его использовать не будете.
В вашем варианте можно попробовать, но не факт, что это будет стабильно или гарантированно работать.

По соменениям:
1) Зависит исключительно от самого инициатора. MS iSCSI зачастую переживает ок. 10 нормально, вопрос лишь не отвалится ли за это время сам софт, который пишет на этот таргет.
2) Сколько угодно. В нормальных условиях есть доступ к хранилищу по двум путям, и MPIO сам видит, что один из путей встал и шлёт только по другому. В случае всяких "переключений" и "активируем/деактивируем" - никаких гарантий.
3) Как уже выше сказал - в WinSvr2012 это вполне штатно реализуется, у вас есть 1 Таргет, при подыхании одного узла кластера все его сервисы (включая IP) переезжают на другую ноду и клиент продалжает пользоваться, даже и не замечая ничего.
Для не FO/HA таргета это работает точно так же (несколько подключений на разные IP одного таргета), чем достигается FO на уровне сетевых подключений.
В вашем варианте - всё зависит от того, сможете ли вы MPIO на клиентах уговорить видеть два таргета как одно устройство с двумя путями.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы