Сегментированный том на SAN под NW65... ?

[Дмитрий Иванов]

Доброго времени суток!
Встала задача организовать надежный массив данных очень большого размера на SAN EVA 4100, который подключен по FC к 4 Proliant ML370G5. Максимальный размер LUN'а в SCSI протоколе 2 ТБ, а массив хотелось бы получить размером около 6 ТБ.
И вот, как вариант, можно расширить NSS POOL и объединить 3 LUN'а по 2ТБ. Отказоустойчивость на физическом уровне обеспечивается самой железкой, а вот как все это хозяйство будет себя вести при возможных сбоях ОС и NSS для меня вопрос... хотя я, лично не видел умерших по вине NSS томов.
Очень интересуют ваши мнения на этот счет!
Спасибо!

[v13]

Нормально работать будет
Только имейте в виду что если файлов много мелких, то чекаться такой пул будет ой как долго(ели не дай бог что поломается). Да и бэкапы тома делать будет напряжно.

[Дмитрий Иванов]

Ну, файлы там как раз очень большие! Круглосуточная запись видео в формате DV - 13 gb/h, кусками около 13 gb. Срок хранения 2-3 недели.
Вот еще мои мысли вслух:
В нашем случае критична 100% доступность массива без тормозов и затыков, т.к. кроме записи со спутника, это еще и круглосуточное телевещание достаточно серьезного телеканала. Скорость самой Сети Хранения Данных очень высокая. EVA4100 имеет внутреннюю архитектуру Fibre Channel и обеспечивает внешнюю скорость - порядка 1024мегабайта/c, а для обеспечения телевещания достаточно 100мегабит/c... Т.е. железка обеспечивает огромный запас. Остается ЛВС + сервер. ЛВС - отдельный VLAN на Cisco 3560G (видимо понадобится еще такой-же коммутатор для обеспечения горячего резервирования сетевого сегмента). Сервер тоже достаточно надежен - HP ML370G5.
Но вот, пока, не дает мне покоя эта связка с сегментированными томами... Выше ли вероятность сбоя по вине операционной или файловой системы, в сравнении с обычными томами???

[v13]

Это штатная хорошо отработанная схема.
В теории может и менее надёжная чем монолитные тома в плане аварийного восстановления, каких нибудь 3rd party утилит восстановления.
В практике у меня сервер с подключенной sata полкой на которой 2 логических тома объединены в один пул ~4тб работает давно и без проблем.

[Дмитрий Иванов]

Спасибо! Ваш опыт очень ценный!
И последний вопрос, а из сегментированных томов кластер получится?
Т.е. берем 2 сервера, подключенных по FC, отдаем обоим серверам по несколько одних и тех-же партиций по 2 ТБ, затем на одном инициализируем все партиции и расшариваем их. Далее, создаем один большой сегментированный том, и подключаем ко 2-му серверу... А второй сервер увидит уже созданный том? Я с кластерной технологией, пока еще не встречался, по сему и задаю такие, возможно, глупые вопросы.
Спасибо!

[v13]

Лично я таких конфигураций не тестировал врать не буду.
Хотя, подняв пару виртуалок можно легко проверить. В netware встроена бесплатная лицензия на 2-х нодовый кластер, даже покупать ничего не придётся.
Имейте в виду, в кластере netware активная нода по доступу к файлам через ncp может быть только одна. Чтоб разочарований потом не было

[Иван Левшин aka Ivan L.]

Novell Cluster Services изначально призван обеспечивать Fault Tolerance, соответственно, сколько бы ни было узлов в кластере - каждый ресурс активен на одной и только одной ноде. Зачатки Load Balancing там есть (на уровне VLL.NLM реализованы соответствующие механизмы), но политические соображение не дали развиться NCS Load Balancing. А жаль... Было бы совершенно замечательное решение с точки зрения удобства и скорости.

Пулы/тома по 4Тб - жуткий геморрой в случае, когда не дай бог что-нибудь случается. Опять же бэкап такого объема - задача интересная сама по себе Мой совет - зеркалировать силами SAN на резервные луны, так быстрее всего и надежнее. Минус - сильно затратно по деньгам.

Замечание относительно NCP некорректно - клиентам все равно, где именно расположен физический ресурс, по всем протоколам доступ осуществляется одинаково (кластерный ресурс по сути - как бы не наследник Server с порезанными атрибутами). Так что LUN смонтируется только на один узел и доступ к нему будет осуществляться с использованием любого протокола как к классическому серверу.

Да, и еще - чтобы смонтировать Cluster shared volume, надо иметь на сервере библиотеки NCS (если не сам сервис запущенным).

[Дмитрий Иванов]

Имейте в виду, в кластере netware активная нода по доступу к файлам через ncp может быть только одна. Чтоб разочарований потом не было

Мне, насколько я понимаю, это подходит, т.к. основная задача это обеспечение отказоустойчивости и прозрачности для пользователя файловых операций. И должна быть, в конце-концов, возможность, когда-нибудь, перезагрузить хотябы один из серверов. А то если все на одном и круглосуточное телевещание...

[Иван Левшин aka Ivan L.]

Для realtime-потока NCS не годится - на время переезда ресурса с одного узла на другой будет временной разрыв (отвал ресурса, выгрузка IP, загрузка IP, монтирование тома, обновление ARP на клиентской стороне). Так что если речь идет о системе видеонаблюдения (насколько я понял, она и строится) - надо озаботиться буферизацией потока на клиентской стороне Да и настройки клиента надо будет подточить - чтобы сделать переезд максимально безболезненным.

[v13]

Novell Cluster Services изначально призван обеспечивать Fault Tolerance

Вроде как можно делать load balance на сервисы типа cifs
ну или просто разные сервисы делать активными на разных серверах.

[Иван Левшин aka Ivan L.]

Нет, NCS обеспечивает только Fault Tolerance. Разные сервисы можно разносить по разным узлам - но это не будет Load Balancing (при котором, как принято считать, один и тот же сервис работает на нескольких узлах одновременно). Грубо говоря, NCS обеспечивает просто-напросто отказоустойчивый файловый ресурс - все остальные сервисы (NDPS, GW, CIFS и т.д.) работают именно с отказоустойчивым перемещаемым файловым ресурсом. Некоторым приложениям (таким, как ГВ, например) необходимо четко указывать, что они работают в кластерном окружении.