lun masking что это
Системы хранения данных (СХД),
дисковые массивы,
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. Вы можете оценить, в частности, нагрузку от хост-компьютеров на систему хранения. Рекомендуется периодически включать протоколирование и просматривать результаты.
| Fibre Channel | |
|---|---|
| Уровень 4. Отображение протокола | |
| Маскировка LUN | |
| Уровень 3. Общие службы | |
| Уровень 2. Сеть | |
| Ткань Fibre Channel Зонирование Fibre Channel Уведомление об изменении зарегистрированного состояния | |
| Уровень 1. Канал передачи данных | |
| Кодирование Fibre Channel 8B / 10B | |
| Уровень 0. Физический |
Маскировка номера логического устройства или же Маскировка LUN является разрешение процесс, который делает Номер логической единицы доступен для некоторых хозяева и недоступен для других хостов.
Маскирование LUN в основном реализовано на адаптер главной шины (HBA) уровень. Преимущества безопасности от маскирования LUN, реализованного на HBA, ограничены, поскольку со многими HBA можно ковать исходные адреса (WWN/MAC/IP-адреса) и скомпрометировать доступ. Многие контроллеры хранилища также поддерживают маскирование LUN. Когда маскирование LUN реализовано на уровне контроллера хранилища, сам контроллер применяет политики доступа к устройству, и в результате он становится более безопасным. Однако в основном это реализовано не в качестве меры безопасности. как таковой, а скорее как защита от некорректной работы серверов, которая может повредить диски, принадлежащие другим серверам. Например, Windows серверы, подключенные к SAN будет, при некоторых условиях, повреждать не Windows (Unix, Linux, NetWare) в сети SAN, пытаясь записать на них метки томов Windows. Это можно предотвратить, скрывая другие LUN от сервера Windows, поскольку сервер Windows даже не осознает, что другие 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 для серверов.
А дальше на системах хранения нарезаются ресурсы, они же диски (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). С остальными вендорами я так глубоко не копал, но догадываюсь, что тонкая настройка есть у каждого.
* до первого серьезного сбоя, после него обычно покупается поддержка у производителя или поставщика системы.
Поскольку в песочнице комментариев нет, закину в личный блог.
Технологии хранения данных VMware vSphere 6. Часть 1 – Old School
VASA – vSphere API for Storage Awareness / Набор API для отслеживания хранилищ
VASA это набор API, предоставляемый VMware и предназначенный для разработки провайдеров хранилищ (storage providers) для инфраструктуры vSphere. Storage provider-ы это программные компоненты, предоставляемые vSphere или разрабатываемые 3-ей стороной, предназначенные для интеграции (отслеживания) хранилищ (программных и аппаратных СХД) и фильтров ввода-вывода (VAIO) с инфраструктурой vSphere.
Storage provider (VASA-провайдер) нужен для того, чтобы виртуальная инфраструктура:
VASA-провайдеры сторонних разработчиков используются как сервисы отслеживания информации о данном хранилище для vSphere. Такие провайдеры требуют отдельной регистрации и установки соответствующих плагинов.
Встроенные storage provider-ы являются компонентами vSphere и не требуют регистрации. Так, например, провайдер для Virtual SAN автоматически регистрируется при её развертывании.
vSphere посредством storage provider собирает информацию о хранилищах (характеристики, статус, возможности) и сервисах данных (фильтрах VAIO) во всей инфраструктуре, данная информация становится доступной для мониторинга и принятия решений через vSphere Web Client.
Информацию, собираемую VASA-провайдерами, можно разделить на 3 категории:
К одному storage provider-у могут одновременно обращаться несколько серверов vCenter. Один vCenter может одновременно взаимодействовать с множеством storage provider-ов (несколько массивов и фильтров ввода-вывода).
VAAI — vSphere API for Array Integration / Набор API для интеграции массива
API данного типа можно разделить на 2 категории:
Storage Hardware Acceleration (VAAI для Hardware Acceleration)
Данный функционал обеспечивает интеграцию хостов ESXi и совместимых СХД, позволяет перенести выполнение отдельных операций по сопровождению ВМ и хранилища с гипервизора (хоста ESXi) на массив (СХД), благодаря чему увеличивается скорость выполнения данных операций, при этом снижается нагрузка на процессор и память хоста, а также на сеть хранения данных.
Storage Hardware Acceleration поддерживается для блочных (FC, iSCSI) и файловых (NAS) СХД. Для работы технологии необходимо, чтобы блочное устройство поддерживало стандарт T10 SCSI либо имело VAAI-плагин. Если блочный массив поддерживает стандарт T10 SCSI, то VAAI-плагин для поддержки Hardware Acceleration не нужен, все заработает напрямую. Файловые хранилища требуют наличия отдельного VAAI-плагина. Разработка VAAI-плагинов ложится на плечи производителя СХД.
В целом VAAI для Hardware Acceleration позволяют оптимизировать и переложить на массив следующие процессы:
Пояснение
VMFS является кластерной ФС (файловая система) и поддерживает параллельную работу нескольких хостов ESXi (гипервизоров) с одним LUN-ом (который под неё отформатирован). На LUN-е с VMFS может размешаться множество файлов ВМ, а также метаданные. В обычном режиме, пока не вносятся изменения в метаданные, все работает параллельно, множество хостов обращается в VMFS, никто никому не мешает, нет никаких блокировок.
Если Hardware Acceleration (VAAI) не поддерживаются блочным устройством, то для внесения изменений в метаданные на VMFS каким-либо хостом приходится использовать команду SCSI reservation, LUN при этом передается в монопольное использование данному хосту, для остальных хостов на момент внесения изменений в метаданные этот LUN становится недоступен, что может вызвать ощутимую потерю производительности.
Метаданные содержат информацию о самом разделе VMFS и о файлах ВМ. Изменения метаданных происходят в случае: включения/выключения ВМ, создания фалов ВМ (создание ВМ, клонирование, миграция, добавление диска, создание снапшота), удаление файлов (удаление ВМ или дисков ВМ), смена владельца файла ВМ, увеличение раздела VMFS, изменение размера файлов ВМ (если у ВМ «тонкие» диски или используются снапшоты – это происходит постоянно).
Hardware Acceleration для VMFS не отработает и нагрузка ляжет на хост если:
Multipathing Storage APIs — Pluggable Storage Architecture (PSA) / Набор API для мультипафинга
Для управления мультипафингом гипервизор ESXi использует отдельный набор Storage APIs называемый Pluggable Storage Architecture (PSA). PSA – открытый модульный каркас (framework), координирующий одновременную работу множества плагинов мультипафинга (multipathing plug-ins – MPPs). PSA позволяет производителям разрабатывать (интегрировать) собственные технологии мультипафинга (балансировки нагрузки и восстановления после сбоя) для подключения своих СХД к vSphere.
PSA выполняет следующие задачи:
NMP в свою очередь также является расширяемым модулем, управляющим двумя наборами плагинов: Storage Array Type Plug-Ins (SATPs), and Path Selection Plug-Ins (PSPs). SATPs и PSPs могут быть встроенными плагинами VMware или разработками сторонних производителей. При необходимости разработчик СХД может создать собственный MPP для использования в дополнение или вместо NMP.
SATP отвечает за восстановление пути посте сбоя (failover): мониторинг состояния физических путей, информирование об изменении их состояния, переключение со сбойного пути на рабочий. NMP предоставляет SATPs для всех возможных моделей массивов, поддерживаемых vSphere, и осуществляет выбор подходящего SATP.
PSP отвечает за выбор физического пути передачи данных. NMP предлагает 3 встроенных варианта PSP: Most Recently Used, Fixed, Round Robin. Основываясь на выбранном для массива SATP, модуль NMP делает выбор варианта PSP по умолчанию. При этом vSphere Web Client дает возможность выбрать вариант PSP вручную.
Принцип работы вариантов PSP: