Lun это виртуальный диск
Решил написать небольшую статейку о сетях хранения данных (СХД), тема эта достаточно интересная, но на Хабре почему-то не раскрыта. Постараюсь поделиться личным опытом по построению и поддержке 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 для серверов.
Сервера подключают к СХД через HBA - Host Bus Adapter-ы. По аналогии с сетевыми картами существуют одно-, двух-, четырехпортовые адаптеры. Лучшие собаководы рекомендуют ставить по 2 адаптера на сервер, это позволяет как осуществлять балансировку нагрузки, так и обеспечивает надежность.
А дальше на системах хранения нарезаются ресурсы, они же диски (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). С остальными вендорами я так глубоко не копал, но догадываюсь, что тонкая настройка есть у каждого.
* до первого серьезного сбоя, после него обычно покупается поддержка у производителя или поставщика системы.
Поскольку в песочнице комментариев нет, закину в личный блог.
LUN – это уникальный идентификатор одного или нескольких физических или виртуальных устройств хранения данных, выполняющих команды ввода-вывода, поступающие с сервера. Это номер логической единицы системы хранения (употребляется также перевод «номер логического устройства»).
LUN-ы используются, чтобы идентифицировать подмножества данных на диске для выполнения операций над ними вычислительными устройствами. LUN представляется серверу как физический локальный диск. После назначения LUN серверу он появится в виде диска на этом сервере, и на этом диске можно будет создать один или несколько томов. Характеристики производительности и надежности всех томов, созданных на диске, определяются типом этого LUN.
Логической единицей может быть часть диска хранения, весь диск или несколько дисков хранения, включая жесткие диски, твердотельные диски или ленточные накопители, в одной или нескольких системах хранения. LUN может ссылаться на весь набор RAID (Redundant Array of Independent Disks), один диск или раздел или несколько дисков или разделов хранения. Весь объём дисков можно нарезать на разные LUN и раздать разным серверам.
Примеры типов LUN:
· зеркальный LUN – отказоустойчивый LUN с идентичными копиями на двух физических дисках для обеспечения избыточности данных и реализации резервного копирования;
· объединенный LUN – несколько LUN, объединенных в одну логическую единицу или том;
· чередующийся LUN – LUN, обеспечивающий запись данных на несколько физических дисков, потенциально повышающий производительность за счёт того, что запросы ввода-вывода распределены по дискам;
· чередующийся LUN с контролем четности – отказоустойчивый LUN, распределяющий данные и сведения о четности поочерёдно по трем или более физическим дискам. В случае выхода из строя физического диска данные могут быть восстановлены на основе информации на оставшихся дисках. Расчет четности может повлиять на производительность записи.
Виртуальный LUN может быть создан для отображения нескольких физических LUN, а также для виртуализации емкости, которая может быть создана с превышением доступного физического пространства (последний случай - тонкий LUN). Виртуальный LUN может быть настроен на уровне операционной системы сервера (ОС), гипервизора или контроллера хранилища.
LUN-ы можно создавать и управлять ими с помощью «Диспетчера хранилища для сетей SAN» в дисковых подсистемах хранения протоколов Fibre Channel и iSCSI, которые поддерживают виртуальную дисковую службу (VDS).
Объект LUN (логический номер устройства) моделирует логическую единицу адресного пространства хранилища, созданного поставщиком оборудования и выпадающего подсистемой. Каждый LUN состоит по крайней мере из одного плекса LUN, который, в свою очередь, состоит из экстентов одного или нескольких дисков.
LUN Types
VDS supports five LUN types: simple, spanned, striped, mirrored, and striped with parity. Simple, spanned, and striped LUNs are non-fault tolerant; mirrored and parity LUNs are fault tolerant. The remainder of this section describes each of the VDS LUN types.
- A simple LUN is a non-fault tolerant LUN that is made up of a single contiguous drive extent from a single drive. The contiguous extent can comprise of a single range of blocks or multiple ranges of blocks linked together.
- A spanned LUN is a non-fault tolerant LUN that is made up of multiple discontiguous extents from multiple drives. Data is written linearly to each of the extents on the first drive until all of the first drive extents are filled, and then to each of the extents on the second drive, and so on. Spanned LUNs provide for efficient use of drive space in subsystems that comprise of drives of various sizes.
- A striped LUN is a non-fault tolerant LUN made up of multiple, interleaved, contiguous extents from multiple drives. Striped LUNs use a RAID-0 configuration, such that data is "striped" cyclically across the extents on the contributing drives. Striped LUNs work best with drives of the same size, model, and manufacturer.
- Mirrored LUNs are fault tolerant LUNs that provide for disaster recovery by duplicating the data to multiple LUN plexes. Each plex in a mirrored LUN contains a copy of the data that is stored on the original plex. Each of the plexes resides on a separate drive. All data that is written to a mirrored LUN is written simultaneously to each of its plexes. Should one of the contributing drives fail, the plex on that drive becomes unavailable, but the system continues to operate using the unaffected plex or plexes. A mirrored LUN can have any number of plexes.
- Striped with parity LUNs are fault-tolerant LUNs that provide for disaster recovery by striping parity data intermittently across three or more drives. Should one of the contributing drives fail, the lost data can be recreated from the remaining data and parity.
Режим маски LUN
Служба VDS поддерживает расмаску LUN для подсистем, которые обеспечивают эту возможность. Все LUN отображаются на компьютере, на котором выполняется поставщик. Снятие маски LUN позволяет вызывающему объекту "снять маску" выбранных LUN для других компьютеров в сети. Если снять маску LUN для компьютера, компьютер будет иметь доступ к LUN. Компьютеры, для которых маска LUN не используется.
Немаскированный LUN предоставляет интерфейсы ивдслун и ивдсдиск на локальный узел. Ивдсдиск можно использовать для добавления LUN в пакет поставщика программного обеспечения, создания и удаления томов, назначения букв дисков и т. д. Дополнительные сведения об операциях, выполняемых на диске, см. в разделе объект Disk.
После того как LUN размаскируется на целевой компьютер или маскируется от целевого компьютера, видимость LUN на этом компьютере может измениться, пока не будет выполнено повторное сканирование шины. Приложение VDS на целевом компьютере инициирует повторное сканирование шины путем вызова ивдссервице:: Rescan. За запуск повторного сканирования шины отвечает приложение VDS, а не поставщик оборудования.
LUN Creation
VDS supports four models by which applications can create LUNs: explicitly directed, partially directed, automagic, and vendor-specific. All hardware providers must support explicitly and partially directed LUN creation, and are strongly encouraged to support automagic LUN creation. (Vendor-specific LUN creation is outside the scope of this guide.)
Explicitly directed LUN creation enables the caller to specify all of the attributes of the LUN. Partially directed LUN creation enables the caller to specify only those attributes that are of particular interest, and then allows the provider to choose the rest. Automagic LUN creation involves enabling the caller to simply specify the LUN type and size along with a set of "automagic hints" (predefined preferences for LUN attributes), and then allowing the provider to create the LUN automatically.
Работа с LUN
Чтобы создать новый объект LUN, используйте метод ивдссубсистем:: креателун . Можно запросить номера LUN, вызываемые определенной подсистемой, вызвав метод куерилунс , который также предоставляется ивдссубсистем. Вызывающий объект может получить указатель на конкретный LUN, выбрав нужный объект LUN из перечисления, возвращаемого куерилунс. С помощью объекта LUN можно задать состояние LUN. запрос всех активных контроллеров, плексов и советов по автоволшебу; расширение и сжатие LUN; Добавление и удаление плексов; Задание масок; применить указания; и удалите LUN.
В дополнение к идентификатору объекта, имени и серийному номеру свойства объекта LUN включают тип LUN, размер, состояние, работоспособность, состояние перехода и флаги. Список размаскирования; и параметр приоритета перестроения.
В следующей таблице перечислены связанные интерфейсы, перечисления и структуры.
Тип | Элемент |
---|---|
Интерфейсы, которые всегда предоставляются этим объектом | ивдслун |
Интерфейсы, которые всегда предоставляются этим объектом в службе VDS 1,1 и 2,0 Fibre Channel только поставщики | ивдслунконтроллерпортс |
Интерфейсы, которые всегда предоставляются этим объектом в поставщиках iSCSI для VDS 1,1 и 2,0 | ивдслунискси |
Интерфейсы, которые могут предоставляться этим объектом* | ивдсмаинтенанце, ивдслунмпио, ивдслуннаминги ивдслуннумберWindows server 2008, Windows Vista и Windows server 2003: интерфейс ивдслуннумбер не поддерживается. |
Связанные перечисления | Служба VDS _ _Флаг LUN и _ _ состояние LUN VDSи _ _ тип LUN VDS |
Связанные структуры | Служба VDS _ _Сведения о LUN, "Служба VDS _ LUN _" и _ _ уведомление о LUN VDS |
* См. раздел объект диска для дополнительного интерфейса (ивдсдиск), который предоставляется, если LUN размещается в виде диска на локальном компьютере узла.
A LUN (logical unit number) object models a logical unit of addressable storage space that is created by a hardware provider and surfaced by a subsystem. Each LUN comprises at least one LUN plex, which is in turn composed of extents from one or more drives.
Working with LUNs
Use the IVdsSubSystem::CreateLun method to create a new LUN object. You can query the LUNs that are surfaced by a specific subsystem by invoking the QueryLuns method, also exposed by IVdsSubSystem. A caller can get a pointer to a specific LUN by selecting the desired LUN object from the enumeration that is returned by QueryLuns. With a LUN object, you can set the LUN status; query for all active controllers, plexes, and automagic hints; extend and shrink the LUN; add and remove plexes; set masks; apply hints; and delete the LUN.
In addition to an object identifier, a name, and a serial number, LUN object properties include the LUN type, size, status, health, transition state, and flags; an unmasking list; and a rebuild priority setting.
The following table lists related interfaces, enumerations, and structures.
Type | Element |
---|---|
Interfaces that are always exposed by this object | IVdsLun |
Interfaces that are always exposed by this object in VDS 1.1 and 2.0 Fibre Channel providers only | IVdsLunControllerPorts |
Interfaces that are always exposed by this object in VDS 1.1 and 2.0 iSCSI providers only | IVdsLunIscsi |
Interfaces that may be exposed by this object* | IVdsMaintenance, IVdsLunMpio, IVdsLunNaming, and IVdsLunNumberWindows Server 2008, Windows Vista and Windows Server 2003: The IVdsLunNumber interface is not supported. |
Associated enumerations | VDS_LUN_FLAG and VDS_LUN_STATUS, and VDS_LUN_TYPE |
Associated structures | VDS_LUN_INFORMATION, VDS_LUN_PROP, and VDS_LUN_NOTIFICATION |
* See Disk Object for additional interface (IVdsDisk) that is exposed if the LUN is unmasked as a disk on the local host computer.
В сказевых системах (а также FC, SAS и практически всех рэйд контроллерах, даже саташных) используется следующая схема адресации устройств - шина (Bus) - адрес (ID) - подадрес (LUN). Аналогия простая: улица - дом - квартира.
Понятие лунов введено в скази стандарт, т.к. существует много систем, где на одном адресе сидит много разных устройств. Например внешние дисковые системы, которые цепляются к серверу одним кабелем - один порт имеет один адрес. Вот чтобы на этом одном адресе видеть кучу дисков, и нужны луны.
Луном может быть не только логический диск. Это может быть например мониторинговый SES процессор или сам контроллер (для управления непосредственно через шину, без эзернетовского хвоста).
Теперь ближе к обыденности.
В просторечии лунами обычно называют логические диски - что не совсем корректно, но общепринято.
Внутри рэйд системы существуют массивы (array) и логические диски (logical drive). Логический диск фактически является партицией массива - только не на уровне операционки, а внутри контроллера.
Грубо говоря, LUN (Logical Drive), с представляет собой кусок рэйд массива, который контроллер представляет операционной системе в качестве "физического" диска. Именно это как правило и имеется в виду, когда говорят "лун".
Смысл разбиения массива на луны в том, что на разных лунах можно иметь разные политики кэширования, что невозможно в случае обычных софтовых партиций. А на многих контроллерах еще и разные уровни рэйд (например контроллеры Адаптек или LSI). Еще момент - не всегда операционки понимают диски более 2ТБ (хотя это со временем пройдет) - тогда большой массив можно просто порезать.
Обладатели PCI контроллеров могут дальше не читать
Сами по себе логдрайвы никому не видны. Для того, чтобы их увидела система, им надо присвоить номера - LUNы.
В PCI контроллерах это делается автоматом, т.к. вариантов нет (т.е. LUN=LogDrive).
Во внешних дисковых системах все гораздо сложнее. Например может существовать логический драйв, не имеющий собственного луна вообще - например разного рода теневые копии. Или наоборот, в случае инкрементального снапшота один и тот же драйв может быть опубликован под разными номерами - как снимки на разный момент времени.
Еще момент - storage partitioning. Это означает виртуальное деление дисковой системы на несколько (для удобства подключения большого количества серверов). В этом случае с разных хостов под одними и теми же номерами лунов будут видны разные логдрайвы.
LUN Mapping - маскирование лунов для разных серверов. Это для того, чтобы разные сервера не видели луны соседа и не мешали друг другу. Можно сказать упрощенный вариант сторадж партишенинга.
В общем, во внешних системах логические диски и луны - это не одно и то же. И задание номеров лунов есть задача админа.
Создание LUN
Служба VDS поддерживает четыре модели, с помощью которых приложения могут создавать LUN: явное, частичное, перенаправленное, автомагическое и зависящее от поставщика. Все поставщики оборудования должны поддерживать явное и частично направленное создание LUN, и настоятельно рекомендуется поддерживать создание LUN с автоволшебием. (Создание LUN, зависящего от поставщика, выходит за рамки данного руководством.)
Явное направление создания LUN позволяет вызывающему объекту указать все атрибуты LUN. Создание LUN с частичным направлением позволяет вызывающему объекту указывать только те атрибуты, которые относятся к определенному интересу, а затем позволяет поставщику выбрать остальные. Автоматическое создание LUN включает в себя предоставление вызывающей стороне простого указания типа и размера LUN вместе с набором "автомагическых советов" (предопределенные настройки для атрибутов LUN), а затем позволяет поставщику автоматически создавать LUN.
Многопутевое расположение LUN
Поставщики оборудования, поддерживающие Multipath I/O (MPIO), могут устанавливать политики балансировки нагрузки для путей между LUN и локальным узлом. LUN, поддерживающие эту возможность, предоставляют интерфейс ивдслунмпио локальному узлу.
LUN Masking
VDS supports LUN unmasking for subsystems that offer this capability. All LUNs are surfaced to the computer on which the provider is running. LUN unmasking allows a caller to "unmask" selected LUNs to other computers on the network. If you unmask a LUN to a computer, the computer has access to the LUN. Computers for which a LUN is masked do not.
An unmasked LUN exposes both the IVdsLun and IVdsDisk interfaces to the local host. You can use IVdsDisk to add a LUN to a software-provider pack, create and remove volumes, assign drive letters, and so on. For more information about the operations performed on a disk, see the Disk Object.
After a LUN is unmasked to a target machine or masked from a target machine, the LUN's visibility on that machine may not change until a bus rescan is performed. The VDS application on the target machine initiates the bus rescan by calling IVdsService::Reenumerate. The initiating of the bus rescan is the responsibility of the VDS application, not the hardware provider.
Типы LUN
Служба VDS поддерживает пять типов LUN: простые, составные, чередующиеся, зеркальные и чередующиеся с четностью. Простые, составные и чередующиеся LUN не являются отказоустойчивыми; зеркальные и контрольные номера логических устройств являются отказоустойчивыми. В оставшейся части этого раздела описываются все типы LUN VDS.
- Простой LUN — это неотказоустойчивый LUN, который состоит из одного непрерывного экстента диска с одного диска. Непрерывный экстент может состоять из одного диапазона блоков или нескольких диапазонов связанных друг с другом блоков.
- Составной LUN — это неотказоустойчивый LUN, который состоит из нескольких несмежных экстентов с нескольких дисков. Данные записываются линейно в каждый экстент на первом диске, пока все области первого диска не будут заполнены, а затем к каждому экстенту на втором диске и т. д. Составные LUN обеспечивают эффективное использование дискового пространства в подсистемах, составляющих диски различных размеров.
- Чередующийся LUN — это неотказоустойчивый LUN, состоящие из нескольких чередующихся непрерывных экстентов с нескольких дисков. Чередующиеся LUN используют конфигурацию RAID-0, так что данные распределяются циклически по экстентам на участвующих дисках. Чередующиеся LUN лучше подходят для дисков того же размера, модели и производителя.
- Зеркальные LUN — это отказоустойчивые LUN, которые обеспечивают аварийное восстановление путем дублирования данных на несколько плексов LUN. Каждый плекс в зеркально отображенном LUN содержит копию данных, хранящихся на исходном плекс. Каждый из этих плексов находится на отдельном диске. Все данные, записываемые в зеркальный LUN, записываются одновременно на каждый из его плексов. В случае сбоя одного из таких дисков Плекс на этом диске становится недоступным, но система продолжит работать с использованием нетронутого плекса или плексов. У зеркально отображаемого LUN может быть любое количество плексов.
- Чередующиеся с контролем четности LUN — это отказоустойчивые LUN, которые обеспечивают аварийное восстановление путем временного чередования данных четности на трех или более дисках. В случае сбоя одного из участвующих дисков потерянные данные могут быть созданы повторно из оставшихся данных и четности.
LUN Multipathing
Hardware providers that support multipath I/O (MPIO) can set load balancing policies on paths between a LUN and the local host. LUNs that support this capability expose the IVdsLunMpio interface to the local host.
Читайте также: