proNovell

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

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

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

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

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

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

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

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

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

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

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

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

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

Иван Левшин aka Ivan L. писал(а):Novell Cluster Services изначально призван обеспечивать Fault Tolerance

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

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