LevT
Platinum Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Сколько хошь, если ФС на клиентской стороне кластерная (такая, как VMFS) Добавлено: Итак, первичное в стораджах понятие - лун. Луны можно определить как диски, реальное содержимое которых скрыто в чуждой "системе хранения" и ею виртуализовано, а для доступа в общем случае требуется преодоление административного барьера. Или так: доступ к которым контролируется административно чуждым стораджем (который однако может быть настроен дружелюбно к потребителю, вплоть до полной прозрачности границы). Через тот барьер инициаторы проламываются к таргетам. Экспортированные стораджем луны видны инициаторам после того, как те прошли контроль доступа на таргете и успешно к нему подключились. Какие именно видны луны и в каком порядке - определяется административными настройками таргет-управлялки (сторадж-подсистемы многоцелевой оси или фирмвари специализированного контроллера). Луны за подключённым таргетом становятся "дисками" для оси инициатора, пригодными для побивки на разделы и форматирования присущими ей инструментами(непосредственными, либо с участием софтового рейда/LVM/ZFS). iSCSI-сессия инициатора с не таргетом, а луном устанавливается поверх сетевого TCP-подключения инициатор-портала к "таргет-порталу" (портал это всего лишь пара IP:port, где стандартный порт 3260 может быть изменён). Проломившимся через админ.барьер инициаторам таргет ВСЕГДА даёт доступ к набору своих лунов (набор этот может определяться софтом стораджа динамически в зависимости от цвета штанов инициатора и-или использованного таргет-портала. Инициатор может и сам "закрыть глаза" на какие-то луны по произволу своего администратора, но это, кажется, проприетарное расширение стандарта). Кроме того, по запросу инициатора таргет-портал рассказывает о лежащих за ним таргетах и об альтернативных таргет-порталах. (Возможно, что рассказывает не всем подряд инициаторам, а только прошедшим контроль?? или просто успешно подключившимся, например, по ipsec ??? последнее в вмваре неактуально, в отличие например от венды) Несколько одновременных коннектов к таргету от единственного инициатора (или даже разных инициаторов присущих одной оси??) приводит к lun multipahing. Оптимизацией доступа в этом случае занимается специальный софт на стороне инициатора (нередко проприетарный и сильно платный; у любимого нашего вендора за всё уже уплОчено вместе с кейгеном : )) Такой софт может устанавливать по своему усмотрению дополнительные iSCSI cессии по существующему TCP-соединению и балансировать нагрузку по путям, но как минимум он рулит логикой файловера при сбоях. Простейший iSCSI мультипас гарантированно обеспечивается параллельным подключением пары порталов одного инициатора к паре порталов одного таргета по разным L3 подсетям, L2 вланам и физически разным путям (хотя в целях обучения всё можно пропустить по одному шнурку, в продуктиве это бессмысленно). Одновременный доступ к одному луну разных осей-инициаторов технически возможен, а запрет его не всегда реален из-за трудностей администрирования. (Платные управлялки SAN полезны энтерпрайзам именно проприетарными ограничениями свободы администратора, которые позволяют тем нанимать низкоквалифицированный ит-персонал, достойный своего доширака). Но осмыслен он только в том случае, если инициаторами используется кластерная файловая система - то есть такая, которая знает о подключившихся осях-инициаторах и ведает блокировками отдельных файлов, не допуская разрушительных последствий. Кластерный софт на стороне инициатора технически блокирует разрушительные операции с луном, затеянные администратором кластерной оси - но бессилен против записи бессмыслицы на кластерный лун левой осью, как-то преодолевшей административный барьер таргета! Подсистема стораджа в любой оси, а также фирмваре "железных" рейдов занимаются виртуализацией локально доступных "дисков" для административно чуждого потребителя. То есть, формирует набор лунов, которые далее экспортируются подсистемой таргета для инициаторов SAN. Именно в этом задача фирмвари "железных" рейд-контроллеров и (иногда красиво упакованных со множеством бесплатных и отдельно платных наворотов) многоцелевых осей хранилок в SAN-сети. SAS - это тоже разновидность SAN: таргетами и маппингом лунов в "железных" контроллерах ведает embedded ось. Заточенная в дешёвых вариантах на локального лишь потребителя, а потому с сознательно заниженным административным барьером. Фирмваре обычно не занимается зонированием доступа, но легко можно вообразить проприетарную SAN или распределённую СХД с таким функционалом. Присущие осям софтовые рейды и LVM тоже занимаются виртуализацией локально доступных "дисков", но для самой оси-хозяина (на выходе получаются не луны и даже не "диски", а сразу "тома", которые наравне с разделами старорежимных дисков подлежат форматированию в файловые системы). ZFS похожа в этом смысле на LVM - но идёт дальше и выдаёт локальной оси не тома под формат, а готовые папки (в терминологии zfs "файловые системы"). А заодно и блочные устройства - zvol-ы - основное предназначение которых быть отданными дальше SAN-инициаторам в виде лунов. Солярка (не знаю, как фрибсд) при этом автоматически расшаривает их по NFS и-или SMB, если у "файловой системы" есть атрибут-свойство sharenfs=on. Также автоматически работает и shareiscsi=on для лунов, но последнее скорее сбивает с толку инициатор вмваре, если маппинг на солярном таргете ранее не был полностью автоматическим, а как-то администрировался. Добавлено: Это всё черновик, комментарии и исправления приветствуются. | Всего записей: 17126 | Зарегистр. 14-10-2001 | Отправлено: 20:04 08-02-2012 | Исправлено: LevT, 13:07 09-02-2012 |
|