Что такое lun в схд
LOGICAL UNIT NUMBER (LUN)
LUN – понятие, связанное с системами хранения данных (СХД) и с сетями хранения данных (SAN- Storage Area Network).
LUN – это уникальный идентификатор одного или нескольких физических или виртуальных устройств хранения данных, выполняющих команды ввода-вывода, поступающие с сервера. Это номер логической единицы системы хранения (употребляется также перевод «номер логического устройства»).
LUN-ы используются, чтобы идентифицировать подмножества данных на диске для выполнения операций над ними вычислительными устройствами. LUN представляется серверу как физический локальный диск. После назначения LUN серверу он появится в виде диска на этом сервере, и на этом диске можно будет создать один или несколько томов. Характеристики производительности и надежности всех томов, созданных на диске, определяются типом этого LUN.
Логической единицей может быть часть диска хранения, весь диск или несколько дисков хранения, включая жесткие диски, твердотельные диски или ленточные накопители, в одной или нескольких системах хранения. LUN может ссылаться на весь набор RAID (Redundant Array of Independent Disks), один диск или раздел или несколько дисков или разделов хранения. Весь объём дисков можно нарезать на разные LUN и раздать разным серверам.
Примеры типов LUN:
· зеркальный LUN – отказоустойчивый LUN с идентичными копиями на двух физических дисках для обеспечения избыточности данных и реализации резервного копирования;
· объединенный LUN – несколько LUN, объединенных в одну логическую единицу или том;
· чередующийся LUN – LUN, обеспечивающий запись данных на несколько физических дисков, потенциально повышающий производительность за счёт того, что запросы ввода-вывода распределены по дискам;
· чередующийся LUN с контролем четности – отказоустойчивый LUN, распределяющий данные и сведения о четности поочерёдно по трем или более физическим дискам. В случае выхода из строя физического диска данные могут быть восстановлены на основе информации на оставшихся дисках. Расчет четности может повлиять на производительность записи.
LUN-ы можно создавать и управлять ими с помощью «Диспетчера хранилища для сетей SAN» в дисковых подсистемах хранения протоколов Fibre Channel и iSCSI, которые поддерживают виртуальную дисковую службу (VDS).
О сетях хранения данных
Решил написать небольшую статейку о сетях хранения данных (СХД), тема эта достаточно интересная, но на Хабре почему-то не раскрыта. Постараюсь поделиться личным опытом по построению и поддержке SAN.
Что это?
Сеть хранения данных, или Storage Area Network — это система, состоящая из собственно устройств хранения данных — дисковых, или RAID — массивов, ленточных библиотек и прочего, среды передачи данных и подключенных к ней серверов. Обычно используется достаточно крупными компаниями, имеющими развитую IT инфраструктуру, для надежного хранения данных и скоростного доступа к ним.
Упрощенно, СХД — это система, позволяющая раздавать серверам надежные быстрые диски изменяемой емкости с разных устройств хранения данных.
Немного теории.
Сервер к хранилищу данных можно подключить несколькими способами.
Первый и самый простой — DAS, Direct Attached Storage (прямое подключение), без затей ставим диски в сервер, или массив в адаптер сервера — и получаем много гигабайт дискового пространства со сравнительно быстрым доступом, и при использовании RAID-массива — достаточную надежность, хотя копья на тему надежности ломают уже давно.
Однако такое использование дискового пространства не оптимально — на одном сервере место кончается, на другом его еще много. Решение этой проблемы — NAS, Network Attached Storage (хранилище, подключенное по сети). Однако при всех преимуществах этого решения — гибкости и централизованного управления — есть один существенный недостаток — скорость доступа, еще не во всех организациях внедрена сеть 10 гигабит. И мы подходим к сети хранения данных.
Главное отличие SAN от NAS (помимо порядка букв в аббревиатурах) — это то, каким образом видятся подключаемые ресурсы на сервере. Если в NAS ресурсы подключаются протоколам NFS или SMB, в SAN мы получаем подключение к диску, с которым можем работать на уровне операций блочного ввода-вывода, что гораздо быстрее сетевого подключения (плюс контроллер массива с большим кэшем добавляет скорости на многих операциях).
Используя SAN, мы сочетаем преимущества DAS — скорость и простоту, и NAS — гибкость и управляемость. Плюс получаем возможность масштабирования систем хранения до тех пор, пока хватает денег, параллельно убивая одним выстрелом еще несколько зайцев, которых сразу не видно:
* снимаем ограничения на дальность подключения SCSI-устройств, которые обычно ограничены проводом в 12 метров,
* уменьшаем время резервного копирования,
* можем грузиться с SAN,
* в случае отказа от NAS разгружаем сеть,
* получаем большую скорость ввода-вывода за счет оптимизации на стороне системы хранения,
* получаем возможность подключать несколько серверов к одному ресурсу, то нам дает следующих двух зайцев:
o на полную используем возможности VMWare — например VMotion (миграцию виртуальной машины между физическими) и иже с ними,
o можем строить отказоустойчивые кластеры и организовывать территориально распределенные сети.
Что это дает?
Помимо освоения бюджета оптимизации системы хранения данных, мы получаем, вдобавок к тому что я написал выше:
* увеличение производительности, балансировку нагрузки и высокую доступность систем хранения за счет нескольких путей доступа к массивам;
* экономию на дисках за счет оптимизации расположения информации;
* ускоренное восстановление после сбоев — можно создать временные ресурсы, развернуть на них backup и подключить к ним сервера, а самим без спешки восстанавливать информацию, или перекинуть ресурсы на другие сервера и спокойно разбираться с умершим железом;
* уменьшение время резервного копирования — благодаря высокой скорости передачи можно бэкапиться на ленточную библиотеку быстрее, или вообще сделать snapshot (мгновенный снимок) с файловой системы и спокойно архивировать его;
* дисковое место по требованию — когда нам нужно — всегда можно добавить пару полок в систему хранения данных.
* уменьшаем стоимость хранения мегабайта информации — естественно, есть определенный порог, с которого эти системы рентабельны.
* надежное место для хранения mission critical и business critical данных (без которых организация не может существовать и нормально работать).
* отдельно хочу упомянуть VMWare — полностью все фишки вроде миграции виртуальных машин с сервера на сервер и прочих вкусностей доступны только на SAN.
Из чего это состоит?
Как я писал выше — СХД состоит из устройств хранения, среды передачи и подключенных серверов. Рассмотрим по порядку:
Системы хранения данных обычно состоят из жестких дисков и контроллеров, в уважающей себя системе как правило всего по 2 — по 2 контроллера, по 2 пути к каждому диску, по 2 интерфейса, по 2 блока питания, по 2 администратора. Из наиболее уважаемых производителей систем следует упомянуть HP, IBM, EMC и Hitachi. Тут процитирую одного представителя EMC на семинаре — «Компания HP делает отличные принтеры. Вот пусть она их и делает!» Подозреваю, что в HP тоже очень любят EMC. Конкуренция между производителями нешуточная, впрочем, как и везде. Последствия конкуренции — иногда вменяемые цены за мегабайт системы хранения и проблемы с совместимостью и поддержкой стандартов конкурентов, особенно у старого оборудования.
Среда передачи данных. Обычно SAN строят на оптике, это дает на текущий момент скорость в 4, местами в 8 гигабит на канал. При построении раньше использовались специализированные хабы, сейчас больше свитчи, в основном от Qlogic, Brocade, McData и Cisco (последние два на площадках не видел ни разу). Кабели используются традиционные для оптических сетей — одномодовые и многомодовые, одномодовые более дальнобойные.
Внутри используется FCP — Fibre Channel Protocol, транспортный протокол. Как правило внутри него бегает классический SCSI, а FCP обеспечивает адресацию и доставку. Есть вариант с подключением по обычной сети и iSCSI, но он обычно использует (и сильно грузит) локальную, а не выделенную под передачу данных сеть, и требует адаптеров с поддержкой iSCSI, ну и скорость помедленнее, чем по оптике.
Есть еще умное слово топология, которое встречается во всех учебниках по SAN. Топологий несколько, простейший вариант — точка-точка (point to point), соединяем между собой 2 системы. Это не DAS, а сферический конь в вакууме простейший вариант SAN. Дальше идет управляемая петля (FC-AL), она работает по принципу «передай дальше» — передатчик каждого устройства соединен с приемником последующего, устройства замкнуты в кольцо. Длинные цепочки имеют свойство долго инициализироваться.
Ну и заключительный вариант — коммутируемая структура (Fabric), она создается с помощью свитчей. Структура подключений строится в зависимости от количества подключаемых портов, как и при построении локальной сети. Основной принцип построения — все пути и связи дублируются. Это значит, что до каждого устройства в сети есть минимум 2 разных пути. Здесь тоже употребимо слово топология, в смысле организации схемы подключений устройств и соединения свитчей. При этом как правило свитчи настраиваются так, что сервера не видят ничего, кроме предназначенных им ресурсов. Это достигается за счет создания виртуальных сетей и называется зонированием, ближайшая аналогия — VLAN. Каждому устройству в сети присваивается аналог MAC-адреса в сети Ethernet, он называется WWN — World Wide Name. Он присваивается каждому интерфейсу и каждому ресурсу (LUN) систем хранения данных. Массивы и свитчи умеют разграничивать доступ по WWN для серверов.
А дальше на системах хранения нарезаются ресурсы, они же диски (LUN) для каждого сервера и оставляется место в запас, все включается, установщики системы прописывают топологию, ловят глюки в настройке свитчей и доступа, все запускается и все живут долго и счастливо*.
Я специально не касаюсь разных типов портов в оптической сети, кому надо — тот и так знает или прочитает, кому не надо — только голову забивать. Но как обычно, при неверно установленном типе порта ничего работать не будет.
Из опыта.
Обычно при создании SAN заказывают массивы с несколькими типами дисков: FC для скоростных приложений, и SATA или SAS для не очень быстрых. Таким образом получаются 2 дисковые группы с различной стоимостью мегабайта — дорогая и быстрая, и медленная и печальная дешевая. На быструю вешаются обычно все базы данных и прочие приложения с активным и быстрым вводом-выводом, на медленную — файловые ресурсы и все остальное.
Если SAN создается с нуля — имеет смысл строить ее на основе решений от одного производителя. Дело в том, что, несмотря на заявленное соответствие стандартам, существуют подводные грабли проблемы совместимости оборудования, и не факт, что часть оборудования будет работать друг с другом без плясок с бубном и консультаций с производителями. Обычно для утряски таких проблем проще позвать интегратора и дать ему денег, чем общаться с переводящими друг на друга стрелки производителями.
Если SAN создается на базе существующей инфраструктуры — все может быть сложно, особенно если есть старые SCSI массивы и зоопарк старой техники от разных производителей. В этом случае имеет смысл звать на помощь страшного зверя интегратора, который будет распутывать проблемы совместимости и наживать третью виллу на Канарах.
Часто при создании СХД фирмы не заказывают поддержку системы производителем. Обычно это оправдано, если у фирмы есть штат грамотных компетентных админов (которые уже 100 раз назвали меня чайником) и изрядный капитал, позволяющий закупить запасные комплектующие в потребных количествах. Однако компетентных админов обычно переманивают интеграторы (сам видел), а денег на закупку не выделяют, и после сбоев начинается цирк с криками «Всех уволю!» вместо звонка в саппорт и приезда инженера с запасной деталью.
Поддержка обычно сводится к замене умерших дисков и контроллеров, ну и к добавлению в систему полок с дисками и новых серверов. Много хлопот бывает после внезапной профилактики системы силами местных специалистов, особенно после полного останова и разборки-сборки системы (и такое бывает).
Про VMWare. Насколько я знаю (спецы по виртуализации поправьте меня), только у VMWare и Hyper-V есть функционал, позволяющий «на лету» перекидывать виртуальные машины между физическими серверами. И для его реализации требуется, чтобы все сервера, между которыми перемещается виртуальная машина, были подсоединены к одному диску.
Про кластеры. Аналогично случаю с VMWare, известные мне системы построения отказоустойчивых кластеров (Sun Cluster, Veritas Cluster Server) — требуют подключенного ко всем системам хранилища.
Пока писал статью — у меня спросили — в какие RAIDы обычно объединяют диски?
В моей практике обычно делали или по RAID 1+0 на каждую дисковую полку с FC дисками, оставляя 1 запасной диск (Hot Spare) и нарезали из этого куска LUN-ы под задачи, или делали RAID5 из медленных дисков, опять же оставляя 1 диск на замену. Но тут вопрос сложный, и обычно способ организации дисков в массиве выбирается под каждую ситуацию и обосновывается. Та же EMC например идет еще дальше, и у них есть дополнительная настройка массива под приложения, работающие с ним (например под OLTP, OLAP). С остальными вендорами я так глубоко не копал, но догадываюсь, что тонкая настройка есть у каждого.
* до первого серьезного сбоя, после него обычно покупается поддержка у производителя или поставщика системы.
Поскольку в песочнице комментариев нет, закину в личный блог.
Быстрая настройка СХД Аэродиск Engine
Мы продолжаем вас знакомить с российскими системами хранения данных AERODISK ENGINE N-серии. Предыдущая – вводная – статья находится здесь. Также у ребят появился свой YouTube канал с обучающими видео по настройке и работе с системой. А еще перед новым годом Аэродиск запустил промо-программу, в рамках которой можно купить СХД со скидкой до 60%! Предложение, на наш взгляд, отличное.
В этот раз Аэродиск нам предоставил систему хранения ENGINE N2 в All-flash конфигурации для самостоятельного изучения и настройки, и мы поделимся этим опытом.
В рамках знакомства с ENGINE мы сделаем цикл из 3-х статей:
Распаковка
В руках у нас оказалась вот эта коробка. Как говорит производитель, в ней 40 ТБ с производительностью 300 000 IOPS. Звучит интригующе, будем проверять.
Распаковываем и видим следующее:
На наш взгляд, сделано все удобно, на корпусе приведены подсказки на английском и русском языке: как можно, а как нельзя делать. Наличие русского языка, конечно, радует.
Спереди видим слоты под 24 диска, сзади – модульные контроллеры и блоки питания. На контроллерах установлены FC-порты, Ethernet-порты (обычный RJ-45 и 10 гигабитный на оптике), а также SAS-порты для подключения дисковых полок. То, что все типы популярных портов ввода-вывода есть в одной коробке – несомненный плюс. Все задублировано, значит, может меняться на горячую, и поэтому с работой в режиме нон-стоп проблем, по идее, быть не должно. Но мы проверим.
Монтируем СХД в стойку, подключаем к серверу через коммутаторы (и FC, и Ethernet), включаем СХД и начинаем настройку. Подключение можем осуществить через командную строку по SSH или Web. С командной строкой будем разбираться позже, сразу идем в веб-интерфейс:
На дашборде видим общую текущую нагрузку на два контроллера, состояние кластера и сенсоров. Слева – основное меню, справа вверху – логон меню, там же задаем время и меняем пароль. Слева вверху – полезная информационная панель, на которой отображаются статусы «здоровья» различных компонентов СХД. Если что-то не так, можно сразу щёлкнуть по проблеме, и система сама отправит тебя в нужное меню. Снизу лог, в котором отображаются последние операции.
В целом, все удобно и логично. Переходим к настройке СХД.
Настраиваем группы хранения
По документации ENGINE может отдаваться наружу по следующим протоколам:
Имеем два типа дисковых групп: RDG, который умеет отдавать блочку и файлы и DDP, который умеет отдавать только блочку (и специально заточен под неё). В прошлой нашей статье про Аэродиск было приведено подробное описание и сценарии применения RDG и DDP. Поскольку RDG больше нашпигован полезными функциями, будем настраивать его. К DDP мы вернемся в следующей статье, когда надо будет тестировать различные сценарии производительности.
Создаем группу хранения RDG
Делаем гибридную группу из 4-х SSD дисков (2 под кэш, 2 под тиринг с уровнем RAID-10 и 7 HDD дисков уровнем RAID-6P (тройная четность). В итоге получаем быстрый «верхний» уровень на SSD и медленный, но очень надежный «нижний» уровень из HDD.
Процесс создания группы вопросов у нас не вызвал, состоит из двух этапов, в начале создается основной «нижний», а потом на него накидываются «верхние» уровни. По ходу создания можно включить дедупликацию и компрессию (включаем). Также нас сразу предупреждают о том, сколько дисков автозамены у нас останется для нештатных ситуаций. Один диск оставляем для автозамены, чтобы протестировать этот механизм.
После создания видим «скелет» нашей рэйд-группы. Выглядит наглядно и удобно:
Также после создания группы можно добавить дисков на любой из уровней в специальном меню:
Группа создана. В свойствах самой группы есть вкладки с LUN-ами и шарами:
Оттуда же пошли создавать LUN. В процессе создания LUN-а нам предлагают различные опции. Из явно полезных отметим возможность создания «тонкого» LUN-а, свой размер блока на конкретный LUN (очень полезно для различных типов нагрузки) и возможность отдельно на каждый LUN включить или выключить дедупликацию и компрессию. Делаем «тонкий» LUN с дедупом и компрессией. LUN создан:
С созданным LUN-ом можно делать много разных операций. После того, как LUN отдадим серверу, мы их проверим.
Теперь создаем файловые ресурсы. Процесс создания NFS и SMB мало чем отличается от создания LUN-а, также можно выбрать индивидуальный блок, «тонкость» или «толстость», но есть и отличие. Задать индивидуальное включение дедупликации и компрессии на файловый ресурс нельзя, то есть настройка будет браться с родительского объекта. Таким образом если хотим, чтобы на файловые шары работала дедупликация и компрессия это нужно включать на уровне RDG. В принципе это ОК, но менее гибко, чем с LUN-ами.
Также отдельная тема — это настройка доступа к файловым ресурсам. Для NFS предусмотрено разграничение доступа (на чтение и/или запись) по IP-адресам и/или пользователям.
Для SMB предусмотрено создание локальных пользователей и интеграция с Active Directory. Для использования AD, при создании файлового ресурса можно разрешить авторизацию из AD и включить шару в домен. В этом случае права на файловый ресурс будут управляться через Active Directory.
Итак, создали два файловых ресурса: NFS и SMB.
После создания смотрим, какие операции мы можем выполнить. В принципе, все то же самое, что и с LUN-ами: изменение размеров, снэпшоты, тип доступа и т.д. Теперь задача отдать эти созданные ресурсы хосту.
Начнем с LUN-а
LUN мы можем отдать по iSCSI и/или FC. Это не опечатка, судя по документации Аэродиска, действительно, есть возможность отдать один LUN одновременно и по FC, и iSCSI. Зачем это нужно не очень понятно, но вендор говорит, что эта функция может пригодиться для диагностики. Ну, допустим, так. В любом случае мы будем делать «по-старинке» и один LUN отдадим по FC, а другой по iSCSI. Чтобы заново ничего не создавать, сделаем клон существующего LUNа.
Описывать процесс настройки SAN-коммутаторов мы не будем, он не отличается от настройки для других СХД. Отметим, что на портале поддержки Аэродиска в базе знаний есть примеры настройки различных вариантов SAN-коммутаторов, что, безусловно, плюс в карму вендора.
Делаем маппинг LUN-а по FC
Идем в инициаторы, видим, что с хоста прилетели WWN-ы инициаторов. Создаем таргет на СХД, связываем таргеты и инициаторы в группу устройств.
Выбираем нужный LUN и делаем маппинг через созданную группу устройств.
В приложении руководства администратора есть отдельный гайд, как правильно презентовать ресурсы СХД по каждому из протоколов с настройками для популярных ОС. Презентация LUN-а по FC особых вопросов не вызвала. В ОС CentOS предварительно должен быть установлен пакет device-mapper-multipath. Хост-сервер в итоге увидел блочное устройство, понял, что это AERODISK.
Кстати, в процессе маппинга обнаружили полезную вещь. Можно задать руками LUN ID. По умолчанию этот ID присваивается по порядку автоматически, но иногда возникают ситуации, когда его надо указывать руками. Например, для SAN boot (загрузка ОС с LUN-а СХД), а также в больших ЦОД-ах, где много разных СХД, а ещё больше LUN-ов с них. Там LUN ID служит для корректного учета и быстрого поиска. На наш взгляд функция – мастхэв и мастюз.
Теперь проверяем – видим, что LUN доступен с двух активных контроллеров (второй как неоптимальный путь – классическая ALUA).
Форматируем LUN в NTFS получаем диск «D».
Переходим к iSCSI
Создаем еще один LUN на той же дисковой группе. С презентацией по iSCSI пришлось потрудиться. Дело в том, что для iSCSI, кроме таргета, инициатора и их связи есть ещё одна дополнительная сущность — HA-ресурс. HA-ресурс — это виртуальный интерфейс, на который вешается виртуальный IP (VIP), который смотрит одновременно на два (или более) физических Ethernet-интерфейса на двух разных контроллерах и служит для отказоустойчивости. Схематично это выглядит так:
HA-ресурс привязывается к конкретной RDG. На туже группу можно привязать еще один HA-ресурс и отдать с него VIP в другую подсеть (может в жизни пригодиться).
В итоге разобрались. Создали HA-ресурс, поставили iSCSI-инициатор в винду, скопировали имя инициатора (IQN) винды. Далее создали iSCSI-таргет на СХД и связали таргет с инициатором.
Подключили LUN в винду. Отформатировали, создали диск D.
Подключаем файловые ресурсы
Этот процесс максимально простой, что с SMB, что с NFS. Единственный момент, на Windows нужно поставить штатный NFS-клиент. Все эти нюансы описаны в документации. Файловый доступ также требует HA-ресурс. Мы его создали на предыдущем шаге, поэтому будем использовать тот же.
Обе наши файловые шары подключаем с в Windows с помощью сетевого диска, соответственно, G и E.
Системы хранения данных (СХД),
дисковые массивы,
RAID корпуса и контроллеры
Статьи
Некоторые особенности современных систем хранения данных
Мы начнем с кратких описаний основных относительно новых понятий, используемых в системах хранения данных. Без понимания таких понятий остальной материал читать нет смысла.
 |
| В этом примере Local Spare диск HDD4 используется для замены вышедшего из строя диска HDD1 в нулевой дисковой группе DG0 |
 |
| В этом примере Global Spare диск HDD5 может использоваться для замены вышедшего из строя диска HDD2 в первой дисковой группе DG1 или диска HDD6 во второй дисковой группе DG2. |
Если в системе есть несколько Global Spare дисков, то они используются последовательно, в порядке возрастания своего ID.
Исторически считалось и многие продолжают считать, что «RAID массив» есть понятие, жестко привязанное к конкретным дискам. Иными словами, если на трех дисках создан RAID 5, то все диски принадлежат этому и только этому RAID 5. В большинстве современных и даже продвинутых RAID контроллерах на конкретной группе дисков вы сможете создать только один столь же конкретный RAID массив. Да, конечно, вы можете разделить массив на логические с точки зрения RAID контроллера и физические с точки зрения внешнего мира диски (LUN), но при этом каждый жесткий диск в обычном RAID будет принадлежать только одному RAID массиву.
У любого нормального человека, незнакомого до сих пор с подобными системами, неминуемо возникнет по крайней мере 2 вопроса. Первый: Как понимать различную избыточность у RAID разного уровня? Второй: А зачем вообще это нужно? Попытаемся ответить на оба вопроса.
Как понимать различную избыточность у RAID разного уровня
Пожалуй, это как раз не самый сложный вопрос применительно к многораидным дисковым группам. Поясним ответ на примере выше. Если один диск (любой, разумеется) из 5 выйдет из строя, то произойдет следующее:
LD0 (RAID5) продолжит функционировать, потери данных не будет и LD0 получит статус Degraded.
LD1 (RAID0) будет разрушен, данные на нем потеряны и LD1 получит статус Faulty.
LD2 продолжит функционировать, потери данных не будет и LD2 получит статус Degraded.
Другими словами, избыточность для каждого LD будет определяться уровнем RAID логического диска вне зависимости от уровня RAID других LD.
Задач, которым требуется, такое построение системы на самом деле довольно много. Приведем хотя бы пару примеров.
Разбиение общей емкости системы хранения на логические диски с емкостью не более 2 терабайт на диск для удобства работы с некоторыми операционными системами/приложениями. Если сделать тоже самое на нескольких дисковых группах вместо одной, то на избыточность придется потратить 3-4 диска вместо одного при использовании единственной дисковой группы.
Если требуется иметь небольшой по размеру логический диск с высокой надежностью хранения данных, а все остальное место отдать под задачу, требующую максимальной производительности без требований к надежности, то вы можете создать RAID 6 небольшой емкости, построив на оставшемся месте RAID 0.
Уже зная и понимая основные понятия для систем хранения данных, мы попытаемся выяснить как именно и в какой последовательности нам следует конфигурировать современную систему хранения. Итак, в конечном итоге структура созданного нами хранилища будет приблизительно выглядеть так:
Последовательность наших действий на самом деле очень проста.
Далее все зависит от задачи. Можно объединить несколько логических дисков в том (Volume) и ему присвоить LUN, можно логический диск (диски) экспортировать напрямую, назначив ему (им) LUN.
После присвоения LUN вам необходимо решить, на какие каналы (порты для Fibre Channel) вы будете отображать (мапировать) логический диск (диски) или том. Другими словами, вы должны «подсоединить» каждый логический диск, он же LUN, к нужному каналу устройства хранения. Если вы планируете использовать систему хранения в SAN системе, то возможно «подключение» логического диска к нескольким каналам (портам) системы хранения данных одновременно. Эта операция называется LUN Mapping.
На этом собственно конфигурирование системы хранения закончено.
Итак, мы настроили систему хранения, применив большинство настроек по умолчанию. Теперь мы познакомимся с некоторыми специфическими настройками систем хранения для правильной работы с подключенными к системе хост-компьютерами.
Настройки метода использования Fibre Channel системы хранения данных
Для Fibre Channel систем следует также указать системе хранения ее будущую роль (в соответствии с решаемой задачей), называемую также Storage Provisioning. Возможны, например, такие варианты: Simple method (Простой метод), Symmetric method (Симметричный метод) и Selective method (Избирательный метод). Расскажем подробнее о каждом варианте использования.
На рисунке показано соединение двух FC каналов на хост-компьютере с двумя дисковыми группами в системе хранения. Это, разумеется, самый редкий вариант применения Simple method (Простой метод). В большинстве случаев хост-компьютер просто подключается по одному каналу к одной группе дисков. Выбрав Simple method (Простой метод), вы далее сможете установить соответствие (отобразить) LUN-ы системы на ее Fibre Channel порты, а LUN-ы в свою очередь связать с логическими дисками или томами. В зависимости от конкретной системы хранения для изменения могут быть доступны передаваемые во внешний мир параметры диска, такие как размер сектора, количество цилиндров, секторов и т.д.
 |
Мощнейшей и часто используемой возможностью настройки в Selective method (Избирательный метод) является LUN Masking (Маскирование LUN). Эта возможность позволяет вам любые LUN делать как доступными для определенных хост-компьютеров, так и невидимыми (замаскированными) для тех хост-компьютеров, которым не разрешено иметь доступа к этим же LUN.
Итак, мы сконфигурировали систему хранения и она успешно используется для решения ваших задач. В процессе эксплуатации часто возникает необходимость изменения параметров собственно системы хранения «на лету», т.е. в «горячем» режиме, без выключения или перезагрузки системы. Например, вы через год-другой захотите увеличить емкость системы хранения простой заменой дисков, но не можете позволить себе потерять данные на существующих дисках, и временно перенести данные такого объема некуда. Это и ряд других возможностей вполне доступны и мы расскажем, как можно реализовать подобные задачи.
Задача: Перенести RAID из одной системы хранения в другую. Например, у вас есть в системе хранения RAID из 8 дисков и вы хотите перенести эти 8 дисков в другую аналогичную систему хранения. Для этих целей используется функция Array Roaming (Перенос массива). Для этого всего лишь надо включить в системе хранения Auto Array Roaming Control (Автоматическое управление переносом массива), установить в нее 8 дисков и все. В случае переноса массива с повреждением данных следует «заставить» систему принять такой массив установкой параметра Force to import abnormal group (Принудительно импортировать некорректную группу) или аналогичного ему.
С 2006 года и у недорогих систем появилась возможность «горячего» расширения БЕЗ потери данных и тем самым необходимости их временного сохранения где-либо в сети.
Существующий уровень RAID
По завершении успешного конфигурирования системы хранения нам останется только следить за ней, предварительно приняв все меры к тому, чтобы исключить возможные внезапные аварии системы. Для систем с высоким требованиям к надежности мы рекомендуем использовать следующие методы и способы диагностики и обслуживания.
В фоновом режиме, во время минимальной загрузки системы (по вечерам в выходные, например), запускать процедуры проверки жестких дисков. Эти процедуры известны:
Следует обязательно иметь копию всей конфигурации системы хранения у себя на защищенном от аварии диске. В этом случае даже при выходе системы хранения из строя все данные могут быть «подняты» на другой аналогичной системе после простого переноса дисков. Современные системы хранения имеют возможность сохранения своей конфигурации как на жестких дисках «у себя», так и в любом месте локальной сети.
Обязательно настройте все способы оповещения администратора о возможных возникающих проблемах. Это можно сделать как отправкой почты от системы к администратору, так и по SNMP протоколу.
Современные системы хранения умеют протоколировать (logging) операции как по FC портам, так и по LUN. Вы можете оценить, в частности, нагрузку от хост-компьютеров на систему хранения. Рекомендуется периодически включать протоколирование и просматривать результаты.