ФайлОхранилище под Новелл - как ?

[Андрей Тр. aka RH]

Снова вылезла старая тема про iscsi. Теперь вопрос такой - есть у меня, к примеру, два сервера - на SLES10 ( или на Вин 2003 ) и NW6.5. И есть железка iscsi.

Вопрос : какие будут варианты с файловой системой для этой железки ? 6.5 поддерживает NSS, понятное дело, остальные - нет. Могу ли я на iscsi держать более одного раздела с разными ФС для разных инициаторов ( совсем разных ) ? и если до кучи у меня на этой железке еще и RAID5, то можно ли его таким образом "поделить" .. Или таки этого лучше избегать ( или вообще нельзя ), и нужны будут отдельные железки ( таргеты ) под разные ОС / ФС ?

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

[Alex-M]

Андрей Тр. aka RH
Могу ли я на iscsi держать более одного раздела с разными ФС для разных инициаторов ( совсем разных ) ?
Ну а почему ж нет? Конечно можно. На ФЦшных массивах все так и работают. Поскольку никакой разницы между ФЦ и iSCSI на уровне дискового драйвера нету - и там и там SCSI command set, только в одном случае поверх FCP, а в другом - поверх IP.

если до кучи у меня на этой железке еще и RAID5, то можно ли его таким образом "поделить" .. Или таки этого лучше избегать ( или вообще нельзя ), и нужны будут отдельные железки ( таргеты ) под разные ОС / ФС ?
Ну, берёшь и нарезаешь массив на ЛУНы для разных хостов. Всё ровно также, как и на ФЦшных. Потом разрулить енто дело в контроллере или на коммутаторах - по адресу, имени или как там ещё...
И никакие отдельные железки не нужны...

если хочется повысить надежность хранилища путем постоянной синхронизации железки iscsi с ее клоном
Это зависит от железки. Некоторые сами могут реплицироваться (синхронно или асинхронно) - НетАпп, например. Некоторые не могут, которые просто тупые таргеты. Тогда да, только средствами ОС на хостах...

[Андрей Тр. aka RH]

Андрей Тр. aka RH
Могу ли я на iscsi держать более одного раздела с разными ФС для разных инициаторов ( совсем разных ) ?
Ну а почему ж нет? Конечно можно. На ФЦшных массивах все так и работают. Поскольку никакой разницы между ФЦ и iSCSI на уровне дискового драйвера нету - и там и там SCSI command set, только в одном случае поверх FCP, а в другом - поверх IP.

если до кучи у меня на этой железке еще и RAID5, то можно ли его таким образом "поделить" .. Или таки этого лучше избегать ( или вообще нельзя ), и нужны будут отдельные железки ( таргеты ) под разные ОС / ФС ?
Ну, берёшь и нарезаешь массив на ЛУНы для разных хостов. Всё ровно также, как и на ФЦшных. Потом разрулить енто дело в контроллере или на коммутаторах - по адресу, имени или как там ещё...
И никакие отдельные железки не нужны...

Ага .. ну я-то пытался сравнить не ФЦ и iscsi, а iscsi и обычный scsi. При простом железяка находится под контролем одного сервера, и одной ОС, соответственно. И я так думал, что в iscsi вся железка видна инициатору как ЛУН - соответственно, два должны ее как-то поделить. Получается, что на железке можно держать типа несколько разных ЛУНов - для разных инициаторов, соответственно. Тогда вроде понятно. А ЛУНы-то нарезаются с инициаторов или как-то средствами таргетов же ?

[Alex-M]

Если это _аппаратный_ iSCSI таргет (в отличие от NAS, который даёт файловый доступ, а не блочный), то он практически ничем не отличается от ФЦ массива по архитектуре. Т.е. имеет контроллер(ы), которые ведают всей логикой работы и порты для подключения хостов (в данном случае, GE) и дисковых полок (FC, SCSI или eSATA; впрочем их может и не быть, если девайс нерасширябельный).
Некоторые массивы верхнего уровня имеют оторванные от собственно контроллера хост-порты - в такие можно одновременно воткнуть порты FC и iSCSI.
Вот на контроллерах и настраивают всё - ЛУНы, разграничения по хостам, параметры производительности/кэширования и т.п. Контроллеры для этого обычно имеют консольный порт и порт сетевого управления (иногда отдельный, иногда совмещённый с основными портами iSCSI - что несколько нехорошо).
Настраивается железка (адрес, пароли и т.п.), затем на ней нарезаются ЛУНы (размер, уровень RAIDа, политики кэширования и т.п.) и наконец настраивается какому хосту на какой ЛУН можно ходить (по имени, адресу, МАКу или как-то ещё). Всё.
Потом инициатором цепляется нужный таргет/ЛУН и он виден как просто диск. А уж ФС - дело ОС хоста.

[Андрей Тр. aka RH]

Настраивается железка (адрес, пароли и т.п.), затем на ней нарезаются ЛУНы (размер, уровень RAIDа, политики кэширования и т.п.) и наконец настраивается какому хосту на какой ЛУН можно ходить (по имени, адресу, МАКу или как-то ещё). Всё.
Потом инициатором цепляется нужный таргет/ЛУН и он виден как просто диск.

Во .. теперь еще понятнее. Сравнение с ФЦ мне, к сожалению, не помогает - т.к. пока не довелось работать ни с тем, ни с другим ( FC/iSCSI ). FC, я думаю, в ближайшем будущем не светит, да и к iscsi присматриваемся достаточно недорогим ( в данный момент - из Dell ).

Поясню суть идеи. В связи с грядущей виртуализацией всего есть мысль попробовать держать аппликухи на виртуальных серверах на меньшем количестве железа. При этом сторадж под него держать отдельно на iscsci. К примеру, собрать в кучу Вин 2003 ( под вялотекущие аппликухи типа Сквида ( евоный кэш - на локальном сторадже ), ИДМ, всякую хрень на ДотНет и пр. ), ОЕС СЛЕС9 ( или просто СЛЕС10 ) и НВ65 ( не файлсервер, а под Зен, ДНС/ДХЦП, ИДМ и т.п. ) - все это виртуально на СЛЕС10 / Xen. Сиквел сервер держать отдельно на виндозном сервере, к которому бы коннектились виртуальные аппликухи.

Вопрос такой - реально ли вынести на iscsi хранилища под постоянно используемые данные типа домашних каталогов и пр. ( на максимум 2хGE, с инициатором на НВ65 ), или же это вариант больше для архивов, бэкапа и т.п. ?

[Alex-M]

Вынести вполне реально - я тут уже как-то писал про опыт использования iSCSI на НетВари. Но есть несколько но:
1) Под iSCSI желательно использовать отдельную сеть, отрезанную физисськи или VLANами от основной. Если используются VLANы, то желательно настроить приоритеты для стораджных VLANов повыше и по возможности использовать Jumbo Frames.
2) Сетевухи для стораджной сети желательны с поддержкой TOE - здесь мне видится основная проблема с использованием iSCSI в виртуальной инфраструктуре, т.к. там сетевухи эмулируемые и не самой высокой производительности.
3) На сторадже сетевух надо побольше, ИМХО 2 GE - это абсолютный минимум. Дальше - больше. Пик - суммарная скорость дисковых каналов на сторадже, т.е. для двух U320 каналов надо 6 GE.
4) Вывод нумбер ван из п.3 - всё это надо в транк на хороший свитч, плюс будет отказоустойчивость.
5) Вывод нумбер ту из п.3 - стораджный сервер должен иметь достаточное количество PCI шин для нормального прокачивания всего этого добра.

Ну, где-то так...

[Владимир Горяев]

Тестю железяку KraftWay Storage 100-12 (вроде какая-то Интеловская штуковина, пока не разобралси). Заделал RAID5 из 11 750Г SATA дисков + 1 SPARE. Итого массив 7 с копейками Тб. Инициатор на NW65SP5 видит только 2 Тб (делал по TID10087321 и доке дистр., через RemoteManager, через NSSMU почему-то не вышло, C1 вообще сказала, что нет подключаемых модулей), сделал NSS том 2 Тб на iSCSI, пока что.
Вроде припоминаю, что том в 32 разрядн. системе не превышает 2 Тб...

Куда делись еще 5 Тб? Может нужно в самом массиве логические тома нарезать или LUN переопределить??

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

Луны нарезать надо по другому. Опираясь на личный опыт, смею заметить - использование очень больших массивов и томов (1.5-2Тб) чревато жутким геморроем что с их бэкапом (очень долго и нудно делается), что с восстановлением в случае сбоя.

NSS поддерживает размер пула до 8 Тб. Соответственно, и размер тома - такой же

[v13]

Както странно оно поддерживается.
На oes2 linux так и не смог создать raid5 на 8x750гб sata дисках.
После танцев с бубном плюнул и сделал через yast linux raid на 5тб

Раньше думал проблема в 32бит... На линуксе и на 32бит и на 64бит
без проблем 5тб массивы собрались, nss же ни 32бит ни 64бит не выходит каменный цветок.

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

Все, мною сказанное, справедливо для нетвари. Относительно линуха - пока ничего не скажу, не копенгаген я в нем пока настолько.

[Константин Ошмян]

Итого массив 7 с копейками Тб. Инициатор на NW65SP5 видит только 2 Тб

Хм, а документацию настоящий админ читает только, "когда ничего другого не помогает"?

1.3 Understanding NSS
NSS is a 64-bit file system that can manage a virtually unlimited number of file objects. On each physical storage device, NSS abstracts up to four physical NetWare partitions to make them appear as contiguous free space. NSS recognizes physical and logical devices up to 2 TB in size from which you can create any number of virtual storage resources, called pools. You can choose space from at least four logical devices of up to 2 TB each to create a pool with a maximum pool size of 8 TB. A pool can contain any number of volumes, depending on the pool size where the minimum volume size is 10 MB. If the pool spans devices by using space from them for the pool, the volumes automatically span the devices. A single volume can contain up to 8 trillion files and grow to 8 TB in size, depending on the size of the pool and space consumed by other volumes in the pool.

[Владимир Горяев]

Хм, а документацию настоящий админ читает только, "когда ничего другого не помогает"?

Я ж говорю, что припоминается, так все суета, то одно, то другое... после лета вылазит. Может и в закладках где есть. Лучше в выходной прийти и спокойно поработать. Да...

[Владимир Горяев]

Опираясь на личный опыт, смею заметить - использование очень больших массивов и томов (1.5-2Тб) чревато жутким геморроем что с их бэкапом (очень долго и нудно делается), что с восстановлением в случае сбоя.

Дык массивчик брался как раз чтоб бекапы серверов на нем хранились, помимо лент. А то бывает на ленту весь сервак не влезает и мафоны кассету (800гиг и по 400) выплевывает и просит добавить, приходишь сутреца и проверяй. С библиотекой как-то парится не охота, решили с iSCSi попробовать. Т.ч. бекапить бекап не будем.

[v13]

1.3 Understanding NSS
NSS is a 64-bit file system that can manage a virtually unlimited number of file objects. On each physical storage device, NSS abstracts up to four physical NetWare partitions to make them appear as contiguous free space. NSS recognizes physical and logical devices up to 2 TB in size from which you can create any number of virtual storage resources, called pools. You can choose space from at least four logical devices of up to 2 TB each to create a pool with a maximum pool size of 8 TB. A pool can contain any number of volumes, depending on the pool size where the minimum volume size is 10 MB. If the pool spans devices by using space from them for the pool, the volumes automatically span the devices. A single volume can contain up to 8 trillion files and grow to 8 TB in size, depending on the size of the pool and space consumed by other volumes in the pool.

О, а это к какой версии nss дока ? я искал чтото подобное, не нашёл в своё время...

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

Доке - сто лет в обед, это описание к нетваревому НСС. Версия которого, если мне не изменяет память - 3.1.

Владимир Горяев - Володь, а всякую там компрессию, разбивки заданий по дням недели не пробовал? Что ж у вас там за объемы такие, что 800 гиг не хватает? Всю Смоленску волость бэкапишь штоль? ))