Глава 5. Концепции хранилищ vSphere и управление

ESXi сопровождает применение и локальных и удалённых хранилищ. Локальные хранилища являются категорией, которая включает в себя устройства хранения, непосредственно вставляемые в данный сервер или любой тип решения хранения, которое подключается напрямую. Удалённое хранилище является категорией, которая включает в себя устройства хранения, подключаемые либо через сетевую среду Ethernet, либо через сеть Fiber channel:

Когда вы планируете некую среду без удалённого хранилища, необходимо принимать во внимание специальные меры для применения различных типов жёстких дисков. VMware ESXi осуществляет поддержку следующих типов дисков:

Тип жёсткого диска, применяемого в используемом вами удалённом хранилище может иметь любой поддерживаемый этим массивом хранения типом. Это обусловлено тем, что доступ к такому удалённому хранилищу осуществляется через интерфейс, подобный некоторому сетевому адаптеру (NIC) или инициатору хранилища (FC HBA).

При проектировании некоторой инфраструктуры vSphere, важно понимать что существуют различные промышленные стандарты протоколов хранения, из которых можно осуществлять выбор. VMware поддерживает применение широко используемых, которые включают в себя Fiber Channel (FC), Internet SCSI (iSCSI), Network File System (NFS) и Fiber Channel Over Ethernet (FCoE).

Протокол Fiber Channel (FC) применяется для включения в свой состав кадров SCSI и их естественной отправки по кабелям FC:

Любому устройству, которому необходим доступ к данным через некий массив FC необходим какое- то аппаратное устройство инициатора, имеющее название Host Bus Adapter (HBA, адаптера шины хоста). Терминальная точка в таком массиве хранения называется процессором хранения, контроллером хранения или процессором службы. HBA и рассматриваемые контроллеры хранения подключаются к коммутатору FC.

Управление связной архитектурой FC выполняется в коммутаторах этой связной архитектуры (коммутатор FC) через создание зон доступа или сегментов для осуществляющих к данному массиву хранения инициаторов. Показатель FC Infrastructure отображает восемь возможных путей доступа к каждому из имеющихся массивов хранения. VMware поддерживает перечень совместимых массивов FC, HBA. Данная информация может быть ограничена путём поиска с применением различных поисковх фильтров при помощи Руководства совместимости VMware. Вы ознакомитесь с созданием и управлением хранилищ FC в разделе Управление складом хранения в данной главе.

FCoE является протоколом, который может применяться для включения в свой состав полезной нагрузки FC в кадрах Ethernet. Полезная нагрузка FC в свою очередь содержит соответствующую команду SCSI в некотором кадре FC:

Настройка некоторой инфраструктуры FCoE потребует получения конвергентных сетевых адаптеров ( CNA, Converged Network Adapters), коммутатора FCoE и инфраструктуры Ethernet без потери данных. Имейте в виду, что FCoE не применяет для своего взаимодействия TCP/IP:

Для отправки SCSI команд через инфраструктуру TCP/IP применяется iSCSI (Internet SCSI):

Одним из основных преимуществ iSCSI является тот факт, что он не заставляет вас иметь специальное оборудование для формирования канала взаимодействия. Он просто может применять существующую инфраструктуру TCP/IP в вашем центре обработки данных для взаимодействия с имеющимся массивом хранения iSCSI. {Прим. пер.: тем не менее, рекомендуем применять DCB и PFC для обеспечения надлежащего QoS соответствующего iSCSI.}

Мы ознакомимся с настройкой доступа к LUN iSCSI в разделе Настройка доступа к хранилищу iSCSI данной главы.

Для доступа к совместно используемым ресурсам файловой системы через сетевую среду TCP/IP применяется NFS (Network File System):

В настоящее время VMware vSphere 6 поддерживает версии NFS NFSv3 и NFSv4.1. Хосты ESXi могут быть настроены для доступа к смонтированным NFS; однако, важно убедиться что вы не настроили доступ к тому же самому монтированию NFS с применением других версий NFS. Это может привести к разрушению данных. Вы дополнительно ознакомитесь с настройкой к совместным ресурсам NFS в разделе Настройка доступа к хранилищу NFS данной главы.

RAID (Redundant Array Of Independent Disks, Массив независимых дисков с избыточностью) является механизмом группирования жёстких дисков в виде организации для логических устройств хранения. Разделы логического диска (дисков) или LUN с файловыми системами или сырые LUN могут размещаться в группах RAID. Каждая группа RAID имеет две основные характеристики: производительность и устойчивость к отказам. Произнося это важно осознавать, что существуют различные типы групп RAID основанные на двух принципах, которые диктуют как эти назначенные данной дисковой группе данные будут записаны, и этими принципами являются чередование и зеркалирование:

Чередование и зеркалирование создают основу для всех прочих типов групп RAID, которые могут быть созданы. Хотя объяснение всех возможных уровней RAID и выходит за рамки данной книги, мы представим краткий обзор нескольких обычно используемых в современных центрах обработки данных. При использовании пространства RAID их использование максимально если вы имеете жёсткие диски идентичного размера, либо если имеющийся размер самого маленького диска станет применяемым размером сегмента для логических дисковых устройств, применяемых в данной группе RAID. Например, если у вас имеется три жёстких диска с размерами 50ГБ, 100ГБ и 200ГБ, тогда используемый размер сегмента уменьшается до 50ГБ, по этой причине оставляя неиспользуемым пространство на жёстких дисках 100ГБ (50ГБ неиспользуемых) и 150ГБ (100ГБ неиспользуемых).

RAID-0 или чередование требует как минимум двух дисков. Все блоки данных последовательно распределяются (записываются) на доступные диски. Эта настройка имеет целью лишь увеличение производительности и даёт нулевую устойчивость к сбоям, так как утрата одного диска может сделать недоступными всю группу данных.

RAID-1 или зеркалирование требует как минимум два диска. На дисковой паре поддерживаются идентичные копии блоков данных. Этот RAID является устойчивым к отказам; он также предоставляет удвоенную скорость ЧТЕНИЯ и производительность одного диска при ЗАПИСИ.

RAID-10 требует как минимум четырёх жёстких дисков. Данный уровень RAID является чередующимися группами зеркалированного набора дисков. Он является группированием RAID-0 (чередованием) RAID-1 (зеркалированных) дисков. Таким образом имеется два набора дисков, которые затем чередуются по зеркалированному набору, а не внутри данного зеркалированного набора дисков. Этот уровень RAID предлагает исключительную производительность и резервирование данных, делающее его устойчивым к отказам.

RAID-5 требует как минимум три жёстких диска. Оно применяет чередование для распределения всех блоков данных на все имеющиеся в данной группе жёсткие диски, но также распределяет везде и информацию контрольных сумм (чётности). Данный уровень RAID может выдерживать отказ отдельного жёсткого диска и предлагает хорошую производительность.

LUN (Logical Unit Number, номер логического устройства) является значением, назначаемым логическому дисковому устройству, созданному в некотором дисковом массиве. Он является единицей хранения, которое может быть уникально идентифицировано вне зависимости от протокола хранения (FC/iSCSI/FCoE). Такое логическое дисковое устройство также называется устройством LUN. Устройству LUN также назначается уникальный NAA ID (Network Address Authority Identifier, Сетевой адрес идентификатора права доступа). Дисковый массив является ничем иным кроме как некоего массива жёстких дисков одного и того же типа, либо различных типов в зависимости от типов, моделей и планируемых конфигураций массивов хранения. Все диски собираются в группы RAID для предоставления требуемого уровня производительности и службы восстановления после сбоев. Такие группы RAID могут обслуживать пространство хранения для одного или более устройств LUN:

На приведённой выше схеме вы можете заметить, что отдельная группа RAID-10 предоставляет пространство хранения единственному LUN-A, в то время как группа RAID-5 обслуживает до трёх LUN - LUN-B, LUN-C и LUN-D. Некий хост ESXi может обнаруживать до 256 устройств LUN.

PSA (Pluggable Storage Architecture, Подключаемая архитектура хранилищ) является модульной инфраструктурой управления хранилищем, которая появилась в VMware vSphere 5. Она обладает инфраструктурой подключаемых модулей, которая может применяться сторонними разработчиками для создания подключаемых модулей со Множеством путей, которые могут давать дополнительную мощность специфичным для массива Множественность путей, балансировку нагрузки или свойства отказоустойчивости. VMware имеет свой собственный подключаемый модуль Множественных путей, именуемый NMP (Native Multipathing Plugin, Встроенным подключаемым модулем Множества путей):

Поскольку рассмотрение подключаемых модулей сторонних разработчиков выходит за рамки данной книги, мы углубимся далее в компоненты и функции VMware NMP.

Каждое определяемое хостом ESXi устройство хранения будет связываться с MPP (Multipathing Plugin, подключаемым модулем Множества путей). Это достигается при помощи некоторого правила требования (claim rule). Если нет никаких правил требований для MPP сторонних разработчиков, тогда NMP VMware будет запрашивать это устройство и связывать с ним SATP и PSP.

VMware имеет два основных компонента:

SATP отвечает за хранение неоторого ярлыка по всем состояниям каждого пути хранения, с которым он связан, а также перехватываемых подробностей отказа некоторого пути , в то время как PSP определяет какой физический путь должен быть выбран для отправки данной операции ввода/ вывода к этому устройству. PSP полагается на информацию состояния данного пути от соответствующего SATP.

Vmware NMP применяет и SATP, и PSP для сопровождения доступа к тем устройствам хранения, которые предоставлены данному хосту ESXi. Когда применяется операция ввода/ вывода для некоторого устройства хранения, данный NMP проинструктирует тот PSP, который соответствует необходимому LUN для помещения данной операции ввода/ вывода в некий путь на основании выбранной определённой политики (MRU/ Fixed/ RR). Если по некоторой причине данная операции ввода / вывода отказывает в исполнении, об этом сообщается обратно в NMP. Данный NMP по очереди уведомляет все SATP для определения конкретной причины данного отказа и предпринимает соответствующее действие. Если данный ввод/ вывод отказал из- за отказа некоторого пути, SATP пометит этот путь как заблокированный и сделает активным другой путь. NMP затем снова вызовет PSP для повтора данного ввода/ вывода. В этот раз PSP может выбрать для применения новый активный путь.

PSA позволяет производителям хранилищ кодировать свои собственные SATP, PSP, либо сам MPP целиком. SATP и PSP производителя могут подключаться в NMP VMware и находиться в активном состоянии совместно с поставляемыми самим VMware SATP и PSP.

VMware NMP включает некий SATP для каждого поддерживаемого массива хранения. В зависимости от имеющегося типа массива, каждый SATP будет иметь некий PSP по умолчанию.

Хотя каждый тип массива будет иметь некий SATP, связанный с ним, может существовать всего три следующих PSP, связанных с ним:

Каждая из этих функций PSP (Path Selection Policies, Политик выбора пути) уникальна. VMware NMP применяет следующие имена для представления их в соответствующей инфраструктуре PSA:

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

Существует три вида массивов основанных на присущих им возможностям балансировки нагрузки и отказоустойчивости:

Массив Активный/ Активный, или симметричный Активный/ Активный, будет иметь все три порта на своих контроллерах включёнными на одновременную обработку всех предлагаемых операций ввода/ вывода на одном и том же уровне производительности и доступа ко всем LUN:

В симметричном массиве активный/ активный отсутствует концепция контроллера в режиме ожидания (standby).

Массивы Активный/ Пассивный будут иметь активный контроллер и контроллер в режиме ожидания. Контроллер называется активным или пассивным в зависимости от тех LUN, которыми они владеют. В массиве активный/ пассивный некий ввод/ вывод к набору LUN может выполняться только владеющим ими контроллером хранения. Тот контроллер, который владеет неким набором LUN называется активным контроллером для этих LUN:

Например, существует два LUN, созданных в некотором массиве активный/ пассивный с контроллерами хранения SPA и SPB. SPA был настроен на владение LUN A, а SPB на вледение LUN B. В таком случае SPA становится активным, а SPB пассивным для LUN A. Аналогичным образом, SPB становится активным, а SPA пассивным контроллерами для LUN B.

Массив ALUA (Asymmetric Logical Unit Access, Асимметричного доступа к логическому устройству) является неким типом массива активный/ активный, который имеет возможность одновременного использования всех своих контроллеров для обработки ввода/ вывода, а также ожидания в готовности в качестве отказоустойчивого партнёрства по отношению друг к другу.

Во многом как и в случае массива активный/ пассивный, LUN или набор LUN могут находиться во владении только одного контроллера. Контроллер- владелец будет иметь симметричный (прямой) доступ к этому LUN, а следовательно, наилучшую производительность. Контроллер, не являющийся владельцем, может обрабатывать данный ввод/ вывод косвенно (асимметрично) для такого LUN посредством передачи подобного ввода/ вывода через взаимодействие с контроллером- владельцем.

Так как такой массив представляет некий способ непосредственной и косвенной обработки ввода/ вывода для присутствующих LUN, должен иметься способ позволить ESXi знать о прямых и косвенных путях к такому LUN. Это достигается путём некоторой функции массива, имеющей название TPGS (Target Port Groups, Группы целевых портов). TPGS собирают прямые и косвенные пути к неким LUN по отдельности. ESXi видит их как Активный (оптимизированный) и Активный (не оптимизированный) пути к данному LUN. Такой активные (не оптимизированный) порты контроллера хранения могут быть активными (оптимизированными) портами для другого набора LUN. ESXi всегда будет помещать имеющийся ввод/ вывод в такой активный (оптимизированный) путь:

Если вам пришлось настроить некий массив так, как показано на схему вверху, тогда ввод/ вывод для LUN A осуществляющийся через контроллер CNTL-B будет иметь результатом передачу всего обмена CNTL-B через взаимодействие с контроллером CNTL-A, который затем должен осуществлять этот ввод/ вывод. Такой альтернативный путь будет называться как активный путь без оптимизации.

Нет ничего необычного в том, чтобы инфраструктура предприятия применяла хранилище Fiber channel для размещения своих рабочих нагрузок. Хотя прочие технологии, подобные NFS и iSCSI предлагают корпоративный класс производительности, FC всё ещё сохраняет превосходную репутацию, рассматриваемую как технологию хранилищ с наилучшей производительностью. VMware ESXi поддерживает доступ к хранилищам FC практически всех производителей. В данном разделе мы изучим как настраивать некий хост ESXi для доступа к LUN в FC хранилище.

В данном разделе мы рассмотрим следующие темы:

Современные центры обработки данных наполнены таким большим количеством компонентов, что очень просто проглядеть единую точку отказа. Отказы компонентов являются достаточно распространёнными, когда вы имеете большую инфраструктуру. Следовательно, становится необходимым проектировать эту инфраструктуру с возможностью обслуживать такие отказы. Доступ к хранилищу является интегрирующей частью любой инфраструктуры VMware. В основном по этой причине критически важно гарантировать что он разработан и реализован таким образом, что не только достигает желаемого уровня производительности, но также делает его устойчивым к отказам.

По этой причине, прежде чем мы начнём понимать как проектировать устойчивую к отказам среду хранения, было бы неплохо ознакомиться с основными типами отказов, которые включают в себя:

Устранение единой точки отказа в хосте ESXi

Хосты ESXi, которым необходим доступ к хранилищу FC, должны оборудоваться Инициаторами FC или HBA (Host Bus Adapters, адаптерами шины хоста). Некоторые серверы поступают с адаптерами на основной плате, некоторые с возможностью установки карт, а некоторые являются комбинацией и того, и другого. HBA выполняются либо с одним, либо с множеством портов на карту. Вне зависимости от общего числа портов, каждый отдельный HBA является некоторой точкой отказа, поэтому важно убедиться, что у вас имеется по крайней мере два HBA на сервер, на котором установлен ESXi.

Устранение единой точки отказа в связной архитектуре

Сетевая среда Fiber channel создаётся при помощи набора Коммутаторов среды. Такие сетевые среды называются Fabric (Связной архитектурой). Рекомендуется применять более одного коммутатора для того, чтобы ваша связная архитектура не стала единой точкой отказа.

Устранение единой точки отказа в массиве хранения

Сам массив хранения является самым сердцем и солью любого центра обработки данных. Он содержит основную часть бизнес данных. Первейшим делом является обеспечить наличие различных уровней резервирования внутри некоторого массива данных во избежание единых точек отказа. Для начала, все ваши LUN, которые создаются в таком массиве данных должны основываться на множестве жёстких дисков (HDD) в некоторой группе RAID для поддержки надлежащей производительности и имеющейся возможности восстановления. Если отсутствуют группы RAID и если в основе таких LUN находится отдельный HDD большого размера, тогда такие компоненты жёстких дисков, такие как имеющийся в наличии контроллер HDD, становятся единой точкой отказа. Большая часть массивов сегодня имеют более одного контроллера хранения, предоставляющих доступ ко всем имеющимся LUN, исключая единую точку отказа.

Когда вы реализуете некую инфраструктуру посредством хранилища FC, крайне важно убедится что такое предоставляемое хостам ESXi хранилище выполнено с целью гарантировать что только те хосты ESXi, которым это необходимо, видят требующиеся LUN. Это достигается двумя методами, называемыми зонированием и маскированием.

Зонирование настраивается в Коммутирующей среде, к которой подключаются кабелями соответствующие HBA ESXi и контроллеры рассматриваемого хранилища. Функция зонирования применяется для создания логических сегментов внутри среды коммутации. Взаимодействовать друг с другом могут только те узлы, которые находятся в одной зоне, имея инициаторы (HBA) и таргеты (контроллеры). Существует два вида зон:

Аппаратное зонирование выполняется путём группирования имеющихся F-портов в некую зону. F- порт является физическим портом в коммутирующей среде. Любое подключённое к некоторому F- порту устройство в данной зоне получит доступ к прочим устройствам в этой же зоне. Каждый F- порт будет иметь динамически назначаемый адрес FC, выделенный ему когда такой порт регистрируется в данной сетевой структуре. Именно зонирование рассматривается как основной тип безопасности, однако так как так как такие адреса FC могут быть подвержены воздействию со стороны изменений настроек в данной сетевой структуре, подобное событие потребует от вас повторное назначение зон с вновь назначенными адресами FC соответствующих F- портов:

Программное зонирование выполняется с применением WWN (World Wide Names, Всемирных имён) тех узлов, которые регистрируются в данной сетевой структуре (fabric). Так как WWN являются статичными и не страдают изменениями, данный тип зонирования рассматривается как наиболее гибкий способ. Вы можете даже переключить кабель данного узла к другому F- порту в коммутирующей среде без какого бы то ни было воздействия на настройку этой зоны:

Маскирование может выполняться либо на самом массиве хранения, либо в соответствующем хосте ESXi. Зонирование не может выходить за пределы границ указанных портов узлов, которые зарегистрированы в данной сетевой среде. Маскирование осуществляется для добавления некоторого более глубокого уровня безопасности внутри какой- то зоны. Когда вы собираете в зону HBA и контроллеры хранилища, такие HBA имеют доступ ко всем LUN, представляемым данными контроллерами хранилища. В некоторой большой среде, какой- то массив хранения будет размещать большое число LUN и не все из них должны быть видимыми для всех находящихся в данной зоне узлов инициаторов. Именно здесь выходит на сцену маскирование. Маскирование дополнительно сегментирует некую зону на списки управления доступом, позволяя только имеющим на то полномочия хостам видеть необходимые LUN.

Давайте рассмотрим следующий пример:

Во многом аналогично с тем, что подразумевают MAC адреса для некоторой инфраструктуры Ethernet, в инфраструктуре Fiber Channel каждому устройству назначается уникальный 64- битный идентификатор, имеющий название Всемирного имени (WWN).

WWN могут быть двух типов: WWNN (World Wide Node Name, Всемирное имя узла) и WWPN (World Wide Port Name, Всемирное имя порта). WWPN также именуются как Node Port ID.

Например, некий адаптер HBA с двумя портами будет иметь некие WWPN назначенные каждому из его портов и один WWNN для самого HBA целиком.

iSCSI, или SCSI поверх интернета, является одним из ведущих соперников на первое место в корпоративных центрах обработки данных. Основным преимуществом iSCSI является то,что нет необходимости затрат в поддержку специального коммутирующего оборудования для вас чтобы включить доступ к имеющемуся хранилищу. Следовательно, всё что вам требуется,это убедиться что такой массив iSCSI находится в сетевой среде, которая достижима для интерфейса vmkernel в вашем хосте ESXi.

Для получения дополнительных сведений об интерфейсах vmkernel прочтите Главу 4, Концепции сетевых сред vSphere и управление.

В данном разделе мы обсудим следующие темы:

iSCSI (Internet Small Computer System Interface) является стандартом хранения данных который делает возможным доступ к нелокальным устройствам хранения поверх сетевой инфраструктуры с IP. Подробности этого стандарта приводятся в IETF документе RFC с номером 7143 (https://tools.ietf.org/html/rfc7143).

В соответствии с этим стандартом, вовлекаемые в такой обмен данными источник и получатель должны инкапсулировать команды SCSI в пакеты IP. И источник и получатель должны иметь возможность инкапсулировать и извлекать такие пакеты для чтения и интерпретации вложенных в них команд SCSI. Источником обычно является оборудование или программный модуль, присутствующие в машине хоста и имеющие возможность встраивать кадры SCSI в такие пакеты IP. Такой источник называется инициатором iSCSI. Аналогично, такой получатель будет иметь некий ответный модуль в качестве таргета iSCSI:

Устанавливаемый между инициатором iSCSI и таргетом iSCSI канал взаимодействия называется сеансом (session). Такой сеанс может иметь несколько соединений со своим порталом таргета:

Портал таргета является комбинацией некоторых IP адреса и порта TCP (по умолчанию 3260) соответствующих узлу данного массива iSCSI. Будет ли некий портал соответствовать отдельному таргету или будет иметься множество порталов на таргет это целиком основывается на архитектуре производителя данного масива. Мы дополнительно обсудим различные типы массивов iSCSI в последующем разделе Типы массива iSCSI.

Аналогично порталу таргета, всякий инициатор также будет иметь сетевой портал, обозначаемый своим IP адресом данного инициатора (vmkernel IP данного инициатора, в случае если он не является независимым аппаратным инициатором iSCSI). Мы ознакомимся с различными типами инициаторов iSCSI в теме Типы инициатора iSCSI.

Всякий iSCSI узел должен иметь связанный с ним уникальный идентификатор. Такое соглашение об именах достигается при помощи схем именования, например, IQN, EUI и NAA. IQN (iSCSI Qualified Name ) является схемой, которая позволяет связывать некий идентификатор (с ограничением в 255- символов) с каждым узлом iSCSI. Такой идентификатор начинается со строки iqn с последующими годом и месяцем установления авторизации, доменом такой авторизации имён в обратном порядке, а также уникальным именем для такого узла хранения. Каждая из таких строк отделяется точкой (.):

Примеры:

Существует две основных категории инициаторов iSCSI, а именно, Программный инициатор iSCSI и Аппаратный инициатор iSCSI:

Имеются различные типы массивов iSCSI различающиеся по общему числу таргетов или порталов таргетов, представляемых ими своему инициатору. Основным отличие между неким таргетом и порталом таргета состоит в том, что таргет iSCSI будет иметь связанный с ним уникальный IQN, в то время как портал идентифицируется некоторой комбинацией IP адрес: Номер порта. Отдельный IQN таргет может иметь более одного связанного с ним портала таргета.

Имея ввиду это отличие, мы возможно можем подразделить их на три категории:

В массивах одиночного портала массив хранения выставляет единственный портал для его обнаружения источником (инициатором). Таким образом, общее число путей к такому массиву будет зависметь от общего числа связанных с таким iSCSI инициатором интерфейсов vmkernel. Общий процесс ассоциации интерфейсов vmkernel с неким инициатором iSCSI имеет название связывания порта (port binding). Мы дополнительно рассмотрим связывание порта в разделе Настройка множества путей для iSCSI данной главы. Массивы, подобные HP left hand и Dell Equalogic являются примерами массивов с одиночным порталом.

В массивах множественного портала такой массив хранения выставляет множество порталов для их поиска соответствующим инициатором iSCSI. Таким образом, общее число путей к массиву не будет зависеть только от общего числа связываемых с данным инициатором iSCSI портов vmkernel, а также и от общего числа выставляемых порталов. Например, если два порта vmkernel связываются с таким выставляющим четыре портала таргета инициатором iSCSI, тогда общее число путей к данному таргету iSCSI составит значение восемь.

В массивах множественного таргета такой массив хранения может иметь более одного таргета iSCSI, причём с одним или более связанных с ними порталов.

Общая вормула для вычисления полного числа возможных путей зависит от общего числа источников (портов vmkernel), а также порталов таргета, но не от общего числа таргетов.

Число путей = Число порталов Источника X Число порталов Таргета

Здесь портал Источника является ничем иным как связываемыми с данным инициатором iSCSI интерфейсами vmkernel.

Когда вы просматриваете информацию о Множественных путях для массивов с Одиночным/ Множественным порталом в GUI vCenter, каждый обнаруживаемый портал будет перечисляться как некий таргет. Эти таргеты будут иметь один и тот же IQN, однако различные связанные с ним IP адреса портала. Однако, массивы со Множеством таргетов будут выглядеть также как таргеты с различными IQN.

VMware ESXi имеет встроенный модуль инициатора iSCSI, который по умолчанию отключён. Программный iSCSI зависит от сетевого стека vmkernel, применяемого для взаимодействия с данным массивом iSCSI. Включение программного iSCSI в ESXi является достаточно простой процедурой. Вам будет необходимо осуществить доступ к своему хосту ESXi через имеющегося клиента vSphere либо, если данный хост добавлен в сервер vCenter, тогда данная задача также может быть выполнена через GUI vCenter. Он спроектирован с применением практических приёмов для создания некоторой отдельной сетевой среды для самостоятельного обмена iSCSI с целью достижения производительности и безопасности. Следовательно, вам необходимо создать некий отдельный интерфейс vmkernel для iSCSI прежде чем вы начнёте:

Настройка инициатора iSCSI для доступа к хранилищу

Раз у вас имеется такой включённый инициатор iSCSI, он должен быть настроен для доступа к тем LUN, которые сделаны доступными в данном массиве iSCSI. Излишне говорить, что данный массив должен быть настроен на предоставление необходимых LUN для их поиска. Это задание относится к предварительной подготовке и должно быть выполнено вашим администратором массива. Так как это действие отличается от производителя к производителю, мы не собираемся обсуждать никакие примеры в данном разделе.

Теперь, предположим, что ваш массив уже был правильно настроен, и нам необходимо пройтись по следующей информации для дальнейшех действий:

Когда вы получите на руки все эти подробности, в соответствующем хосте ESXi:

По умолчанию ESXi создаёт отдельный путь между своим программным адаптером iSCSI и соответствующим таргетом iSCSI, если только такой массив iSCSI не является массивом со множеством порталов, делающих возможным доступ к таргету через более чем один сетевой интерфейс. Если мы просмотрим общее число путей доступных для данного устройства LUN, к которому мы настроили доступ в предыдущей задаче, вы можете заметить, что он имеет только единственный путь к данному устройству:

Чтобы сделать доступной балансировку нагрузки или избыточность для исходящего в сторону хоста ESXi обмена iSCSI, возможно связать более одного адаптера/ интерфейса vmkernel с таким программным адаптером iSCSI. Однако, имееется одна важная хитрость для данного типа настроек, а именно: интерфейсы vmkernel и имеющиеся порталы таргета iSCSI не могут находиться в неравноправных подсетях сетевых сред. Другими словами, они должны находиться в одном и том же широковещательном домена (VLAN). Это не означает что iSCSI не поддерживает маршрутизацию; это всего лишь является ограничением со связыванием данного порта. Связывание порта осуществляется только с имеющимся программным адаптером iSCSI. VMKernel адаптеры не могут связываться с какими- либо аппаратными адаптерами iSCSI.

Что необходимо настроить для сцепления порта?

Нам понадобится идентифицировать свои vmnics/dvUplinks, которые будут соединены с объединёнными в транки физическими портами коммутатора для поддержки нужного обмена по VLAN. Нам необходимы адреса IP, которые можно назначить соответствующим интерфейсам vmkernel и, конечно, нам необходимы дополнительные интерфейсы vmkernel, создаваемые в зависимости от общего числа путей, которое мы планируем включить между данным хостом и массивом iSCSI.

Как мы проходим настройку сцепления порта?

Чтобы настроить связывание порта, вам необходимо создать два интерфейса vmkernel с IP адресами в той же самой подсети, в которой находится необходимый портал таргета iSCSI. Затем мы воспользуемся GUI свойствами Программного инициатора iSCSI для связывания с ним соответствующих интерфейсов vmkernel. Мы не будем повторно проходить эту процедуру создания необходимых интерфейсов vmkernel, так как мы уже помогли вам в Главе 4, Концепции сетевых сред vSphere и управление ознакомиться с данной процедурой. Вместо этого мы рассмотрим группирование NIC и процедуру добавления интерфейсов VMKernel в соответствующий Программный инициатор iSCSI. Следующая схема описывает то, что мы пытаемся получить:

Группировка NIC

При настройке группирования (teaming) NIC для его применения со связанными портами важно убедиться что только нужный вам NIC является активным адаптером. Все остальные адаптеры должны быть настроены как не используемые (Unused). Таким образом, как вы уже должно быть поняли, нам понадобится раздельная настройка для каждого из имеющихся портов vmkernel. Если вы применяете в своём окружении Распределённые коммутаторы vSphere, тогда имейте ввиду, что вам необходимо будет вручную создать две отдельные группы Распределённого порта перед началом создания таких интерфейсов vmkernel.

Если вы применяете Стандартный vSwitch, каждый создаваемый вами интерфейс vmkernel будет по- существу помещаться в своей собственной группе порта:

Сцепление интерфейсов vmkernel к адаптеру iSCSI

Когда мы выполним все подготовительные задачи создания интерфейсов vmkernel и настройки группирования NIC в их соответствующие группы портов, следующим этапом будет поставить в соответствие эти интерфейсы необходимому инициатору iSCSI. Связывание сетевого порта iSCSI является процессом установления соответствия интерфейсов vmkernel определённым программным адаптерами iSCSI.

Вот как это делается:

Как и хранилище iSCSI, хранилище NFS также является подключаемым через сетевую среду и легко может быть сделано участником инфраструктуры вашего центра обработки данных усиливая его текущую сетевую среду TCP/ IP. В отличие от iSCSI, NFS не является блочным хранилищем, что означает, что NFS работает и сопровождается своей собственной файловой системой. Следовательно, ESXi не может форматировать и создавать новую файловую систему на томах, представляемых ей из некоторого массива NFS. Вместо этого все тома NFS, или правильно именуемые экспортами, всего лишь являются точками монтирования в некотором хосте ESXi для удалённого совместного использования в некотором массиве хранения NFS.

Данный раздел главы рассматривает все процедуры, вовлечённые в настройку доступа к совместным ресурсам в некотором хранилище NFS.

Предварительными требованиями, необходимыми для данной задачи являются:

Совместные ресурсы NFS могут быть смонтированы с применением мастера настройки New Datastore. Имеется более одного метода для запуска этого мастера. Мы в данный момент обсудим один из самых простых:

Монтирование NFS на множество хостов

Когда необходимое хранилище данных NFS создано вы легко можете смонтировать его на прочие хосты ESXi. Это можно сделать кликнув правой кнопкой по такому хранилищу данных NFS и выбрав соответствующую опцию Mount Datastore to Additional Hosts:

Это должно привести к выводу окна со списком всех хостов ESXi в имеющемся центре обработки данных. Выберите хосты для монтирования в них данного NFS и кликните OK. Таким образом выполнится монтирование данного совместного ресурса NFS на отобранных хостах с применением той же самой информации, которая была предоставлена для монтирования этого совместного ресурса в самый первый раз.

После того, как мы настроили доступ к своему массиву хранения, нам понадобится создать в нём контейнеры файловой системы. Те LUN, которые представлены некоторому хосту ESXi, только если они не являются экспортами NFS, не имеют никакой файловой системы внутри себя. Такие LUN имеют название сырых (Raw) LUN. ESXi может создать на них некую распределённую файловую систему с названием VMFS (

Virtual Machine File System, файловой системой виртуальной машины). Будучи созданным, некий контейнер логических данных, называемый складом данных (datastore) предоставляется миру пользователя в данном ESXi. Склад данных, однако, является общим термином для названия томов VMFS и монтироаний NFS. В данном разделе этой главы вы будем изучать как создавать и управлять складами данных.

Мы рассмотрим следующие темы:

Сырые устройства хранения предоставляемые некоторому хосту ESXi могут быть отформатированы под собственную файловую систему VMware с названием VMFS (

Virtual Machine File System). Это зрелая файловая система, котрая в настоящее время имеет версию 5 в vSphere 6, а начала она своё путешествие в версии ESXi 1.x. С тех пор наблюдался ряд улучшений и в настоящее время она поддерживает максимальный размер 64ТБ при поддержке схемы разбиения на разделы GPT (GUID Partition Table). VMFS-5 была представлена совместно с vSphere 5 при наличии некоторых улучшений масштабируемости в сравнении с предыдущим поколением Файловых систем Виртуальных машин - VMFS-3.

Снабжённая поддержкой GPT (GUID Partition Table), VMFS-5 теперь может поддерживать тома VMFS, которые имеют размер более 2 Терабайт. Текущий порог в максимальном размере некоторого тома VMFS составляет 64 Терабайта.

В отличие от VMFS-3, которая имела размеры файлового блока от 1 Мегабайта до 8 Мегабайт, VMFS-5 имеет единый размер блока, составляющий 1МБ. Она также поддерживает некий суб-блок меньшего размера в 8кБ, в отличие от 64кБ в VMFS-3. Суб-блоки меньшего размера переводятся в уменьшение пустых трат пространства хранения в случае, когда те тома VMFS, где хосты перечисляют файлы меньшего размера, такие как файлы журналов виртуальной машины.

Том VMFS может быть создан с применением мастера Добавления хранилища (Add Storage) или из командной строки хоста ESXi. В данном разделе этой главы мы рассмотрим оба этих варианта. Чтобы иметь возможность создания некоторого тома, вам понадобится некое устройство LUN с размером менее 64 Терабайт предоставленное данному хосту ESXi. Сказав это, необходимо отметить, что некий том может располагаться не только внутри границ отдельного LUN. Том VMFS может расширяться на максимум из 32 физических экстентов LUN. Однако, общий размер такого тома VMFS не может превосходить 64 Терабайт.

Когда у нас имеются предоставленные некоторому хосту ESXi сырые LUN с целью применяться в качестве контейнера хранения для данных виртуальной машины, они должны быть отформатированы с применением VNFS. Создание склада данных VMFS состоит в процессе форматирования некоторого LUN путём создания в нём какого- то раздела VMFS. Некий склад данных (том VMFS) может быть создан либо при помощи веб клиента мастера Нового склада данных (New Datastore) vSphere или посредством интерфейса командной строки ESXi. Однако, важно чтобы вы имели на руках необходимые NAA ID, LUN ID, и предоставленный данному LUN размер, чтобы гарантировать что вы не получите в конце концов применение непредусмотренного LUN. Выполните повторное сканирование своего HBA для определения представленных LUN.

Мастер Нового склада данных доступен в GUI веб клиента vSphere. Приведённая ниже процедура даст вам руководство для этапов, необходимых для достижения этого:

Вы можете просмотреть или изменить настройки Множества путей устройств LUN соответствующих какому- либо складу данных:

Скорее всего, у вас со временем не останется свободного пространства не томе VMFS, поскольку вы в конечном счёте развёртываете на нём всё больше и больше виртуальных машин, в особенности в растущем окружении. К счастью, возможно укомплектование дополнительным свободным пространством некоторого тома VMFS. Однако, это требует того, чтобы либо данный LUN имел остающимся в себе свободное пространство, либо он был расширен/ изменён в размере в данном массиве хранения. Сама процедура изменения размера/ расширения конкретного LUN в имеющемся массиве хранения отличается от производителя к производителю и, так как это выходит за рамки данной книги, мы считаем, что данный LUN либо имеет свободное пространство внутри, либо уже был расширен.

Наращивание/ рост VMFS склада хранения

Прежде чем вы попытаетесь вырастить свой склад данных VMFS, выполните повторное сканирование в данном HBA чтобы убедиться что данный ESXi обнаружил увеличение размера данного LUN. Кроме того, обратите внимание на NAA ID, номер LUN и имеющийся размер данного LUN, лежащего в основе такого склада хранения VMFS, который вы пытаетесь нарастить/ вырастить.

Мы пройдём приведённый ниже процесс по наращиванию имеющегося склада данных VMFS при помощи GUI веб клиента vSphere:

Наращивание некоторого склада данных VMFS относится к действию по увеличению его размера внутри своего собственного экстента VMFS. В данном случае экстентом называется некий LUN, лежащий в основе такого тома VMFS. Это возможно только если имеется свободное пространство, доступное сразу после наращивания экстента. Общий максимальный размер некоторого LUN составляет 64ТБ, поэтому общий максимальный размер тома VMFS также составляет 64ТБ. Все размещающиеся в этом складе данных виртуальные машины продолжат быть во включённом состоянии и оставаться непрерывными, в то время как выполняется эта задача.

Расширение/ распространение VMFS склада хранения

В отличие от наращивания/ роста тома VMFS, расширение тома выполнит охват данным томом множества LUN, и это осуществляется путём добавления дополнительных экстентов в такой том VMFS. Склад данных VMFS может охватывать тома до общего максимума из 32 экстентов LUN. Общий размер такого экстента теперь может быть больше чем 2ТБ, общий предел составляет максимум тома VMFS с размером в 64ТБ.

Когда вы добавляете экстенты к складу данных, самый первый LUN, который первоначально составлял основу такого склада данных становится заглавным экстентом так как он содержит всю относящуюся к прочим экстентам информацию. Если, по какой- то причине, вы утратите такой заголовочный экстент, тогда это может повлечь за собой выход из рабочего состояния всего склада данных VMFS. Однако, если вы утрачиваете некий экстент, который не является заглавным, тогда такой склад данных всё ещё остаётся доступным, однако стану недоступными только те виртуальные машины, чьи VMDK зависели от утраченного экстента.

Удаление доступа к LUN

На текущий момент вы ухватили как создаются и управляются в размере Склады данных VMFS.Однако, в любой момент вы можете столкнуться с потребностью удалить доступ к определённому Складу данных или даже целой их связке из некоторого хоста/ кластера ESXi. Но то может иметься целый ряд причин, одной из которых могут быть сопровождение или вывод из эксплуатации. Вне зависимости от причины для такого удаления, настоятельно рекомендуется удалять доступ к такому Складу данных согласно предписанной процедуре. Данный радел этой главы проведёт вас через такую процедуру:

Данный процесс может быть осуществлён либо в GUI vCenter, либо в интерфейса командной строке соответствующего ESXi. Дополнительно по этой теме вы можете получить инструкции в статье 2004605 Базы знаний VMware: http://kb.vmware.com/kb/2465.

Инструменты управления массивом хранения позволяют нам клонировать/ делать моментальные снимки/ реплицировать LUN, которые лежат в основе складов данных VMFS. Моментальные снимки создаются в массиве хранения с использованием интерфейса управления таким массивом. Однако, невозможно смонтировать идентичную копию некоторого существующего склада хранения VMFS в одном и том же хосте ESXi. Это преднамеренно запрещено во избежание порчи данных, только если они не используют в качестве основы различные ID устройств.

ESXi идентифицирует каждый том VMFS при помощи его подписи, отмеченного UUID (Universally Unique Identifier, Универсальным уникальным идентификатором). Такой UUID вырабатывается при первом создании тома или его повторном подписании и сохраняется в заголовке LVM каждого тома LMFS.

Для вывода перечня всех имеющихся складов данных VMFS совместно с их подробностями можно применить команду esxcli storage filesystem list, которая содержит такой UUID в виде столбцов, как это отображено ниже:

Следующая схема отображает структуру UUID VMFS:

Когда некий хост ESXi выполняет сканирование на предмет поиска новых устройств LUN и томов VMFS в них, он сравнивает идентификатор такого физического устройства (NAA ID) данного LUN с тем значением идентификатора устройства (NAA ID), которое хранится в LVM заголовке таких томов VMFS. Если он обнаруживает некоторое расхождение, тогда он обозначает этот том как некий том моментального снимка. По умолчанию тома, определяемые как моментальные снимки не монтируются.

Существует две возможности смонтировать такие тома/ склады данных. Эти варианты делаются доступными через мастер New Datastore, причём только если вы выбрали некий клон/ моментальный снимок/ реплику LUN с неким размещённым там томом VMFS:

Однако, как упоминалось выше, такой том может быть смонтирован на некотором хосте ESXi, который не видит такого первоначального склада хранения, причём с тем же самым именем склада данных.

Перед тем как мы обсудим чем является управление SIOC (Storage I/O Control, Управление вводом/ выводом хранилища), имеется несколько понятий, которые формируют основу и также поясняют необходимость для механизма подобного SIOC.

ESXi выполняет на локальном хосте планировщик для балансировки такого ввода/ вывода между имеющимися виртуальными машинами. Это означает, что если существуют виртуальные машины, перемешивающие рассматриваемые объёмы ввода/ вывода (более чем обычный), тогда важно убедится что другие виртуальные машины расположенные в том же самом склдае данных остаются не подверженными воздействию, в том плане, что им не дозволено выполнять ввод/ вывод к такому устройству. Это достигается путём управления всего объёма ввода/ вывода, который может выполнять каждая из участвующих виртуальных машин с применением совместных ресурсов для каждого vmdk. Это работает во многом похоже на то как это происходит с совместным использованием ЦПУ или Оперативной памяти. Такой диск с относительно большим значением совместных ресурсов получит выполнение большего объёма операций ввода/ вывода с данным устройством.

Теперь всё этобудет работать просто великолепно пока такой склад данных виден только отдельным хостом ESXi. К несчастью, это не является распространённым вариантом. Склады данных часто совместно используются множеством хостов ESXi. Когда склады данных используются совместно, вы включаете в процесс более одного планировщика локального хоста в этот процесс балансировки общего ввода/ вывода между всеми виртуальными машинами. Более того, такие тратящие впустую усилия планировщики хоста не могут общаться друг с другом. Их видимость ограничена теми хостами ESXi, на которых они работают. Это легко приводит к серьёзным проблемам под названием ситуации шумного соседа.

В следующем примере, поскольку VM-C является единственной виртуальной машиной в ESX-02, она становится потребителем всей глубины данной очереди, которая может обслуживать виртуальные машины на других двух хостах. Если VM-C, на самом деле, не потребляет весь ввод/ вывод общей длины очереди LUN, тогда это будет называться шумным соседом:

Задание SIOC состоит во включении некоторой формы взаимодействия между такими планировщиками локальных хостов с тем, чтобы такой ввод/ вывод мог выполнять балансировку между выполняющимися на отдельных хостах виртуальными машинами. Он делает это сопровождая совместно используемый файл в данном складе данных, который могут читать/ записывать/ обновлять все хосты. Когда в некотором складе хранения включён SIOC, он начинает наблюдать за задержккой такого устройства на данном LUN, поддерживающим такой склад данных. Если замеряемая латентность превышает некое установленное пороговое значение, механизм дросселирует глубину очереди данного LUN на каждом из обслуживаемых хостов ESXi с попыткой распределения справедливого совместного доступа к данному LUN для всех виртуальных машин, выполняющих данный ввод/ вывод.

Давайте рассмотрим предыдущий сценарий, в котором имеется шесть виртуальных машин на трёх различных хостах ESXi, получающих доступ к единственному совместно используемому LUN. Среди всех шести ВМ, четыре из них имеют нормальное совместно используемое значение 100, а оставшиеся две имеют высокое (2000) значение совместного использования наборов диска. Эти виртуальные машины имеют только один VMDK подключённый к ним. VM-C на хосте ESX-02 выполняет большое число операций ввода/ вывода. Так как это единственная ВМ, осуществляющая доступ к совместному ресурсу LUN с данного хоста, она получает всю полосу пропускания очереди. Это может наводить задержку на операции ввода/ вывода, осуществляемые другими ВМ: ESX-01 и ESX-03. Если имеющийся SIOC определяет что значение латентности становится выше чем устанавливаемый динамически порош, тогда он начинает дросселировать общую глубину очереди.

Приводимая ниже таблица поможет вам понять как вычисляется процентное соотношение справедливости совместного ресурса со стороны SIOC:

Дросселируемое DQLEN для некоторой ВМ вычисляется так:

DQLEN для ВМ = (Процент совместного ресурса ВМ) от (Глубины очереди)

Пример: 12.5% от 64 -> (12.5% * 64)/100 = 8

Дросселируемое DQLEN для хоста вычисляется следующим образом:

DQLEN для Хоста = Сумма DQLEN для ВМ в нём

Пример: VM-A (8) + VM-B (16) = 24

Следующая схема показывает эффект от дросселирования общей глубины очереди SIOC:

Локальный планировщик на каждом из имеющихся хостов ESXi использует файл iostats с тем, чтобы сопуствующие ему хосты знали о статистиках ввода/ вывода данного устройства, наблюдаемого на текущем LUN. Данный файл помещается в каталоге (naa.xxxxxxxxx) в том же самом складе данных:

SIOC может быть включён только на уровне имеющегося склада хранения. Для настройки SIOC вам потребуется доступ к имеющемуся серверу vCenter управляющему хостами. Установка такого SIOC не зависит от имеющегося vCenter ни для какой из его операций.

Следующая процедура послужит вам руководством по шагам, требующимся для включения SIOC:

Во многом как и хосты ESXi, склады данных VMFS могут группироваться для создания некоторого кластера склада данных. Это помогает включать на нём Распределённый планировщик хранения (Storage Distributed Scheduler) для более простого управления складом данных.

Как и в случае с кластеризацией ваших вычислительных ресурсов, кластеры хранения также должны отвечать определённым требованиям. Вот некоторые из наиболее важных из них:

Вот URL этого руководства: http://bit.ly/vspherermg60.

Следующая процедура послужит вам наставлением по шагам, необходимым для создания некоторого кластера склада данных и включения на нём DRS:

Когда Storage DRS включён, он создаёт рекомендации по миграции хранилища, основывающиеся на использовании пространства и пороговых значениях задержек. Балансировка нагрузки основывающаяся на используемом пространстве не может быть отключена, однако балансировка нагрузки, основывающаяся на перегрузках общего ввода/ вывода может быть отключена.

Когда вы развёртываете некую ВМ в кластере центра обработки данных со включённой SDRS, SDRS предоставит рекомендации размещения,основанные на общем использовании пространства и нагрузки ввода/ вывода в имеющихся складах данных. Это уменьшает сложность при принятии решения в случае, когда у вас имеется большое число складов данных в вашей среде и, конечно, они должны являться частью кластера склада данных для такой работы. SDRS предоставляет рекомендации по размещению и выбирает один из рекомендуемых складов хранения. Однако, руководящий процессом пользователь может выбрать другой рекомендуемый склад данных. Хотя балансировка ввода/ вывода может быть отключена, SDRS всё ещё имеет доступ к статистикам ввода/ вывода имеющихся складов данных. Если SDRS обнаруживает более одного склада данных пригодных для размещения виртуальных машин, тогда он выберет тот склад хранения, который имеет наименьшую загруженность ввода/ вывода.

В случае отключённого Storage DRS, вполне может случиться, что со временем при развёртывании всё большего числа виртуальных машин, в конечном итоге вы насытите свободное пространство в наборе складов данных, оставив некоторые другие склады данных недоиспользуемыми. Это может время- от- времени вызывать условия "исчерпания пространства", воздействуя на исполняющиеся ВМ, однако когда в кластере склада данных включён Storage DRS, осуществляется наблюдение за использованием пространства в таких складах данных и соотношением роста имеющихся VMDK (в случае с динамическим выделением). Пороговым значением по умолчанию для использования пространства является величина в 80%. При превышении данного порогового значения Storage DRS начнёт создавать рекомендации Storage VMotion.

Загруженность ввода/ вывода в некотором складе данных измеряется на основании текущих значений латентности ввода/ вывода, которая отслеживается по работающим в нём виртуальным машинам. Пороговым значением по умолчанию для латентности является значение 15 миллисекунд (15 000 микросекунд). Если включена балансировка нагрузки для ввода/ вывода, тогда статистики задержек ввода/ вывода оцениваются каждые восемь часов. SDRS применяет значение 16 часов стоимости данных для генерации рекомендаций Storage vMotion. Все миграции, основанные на дисбалансе нагрузки ввода/ вывода происходят только один раз в день.

В данной главе мы стартовали с основ хранилища vStore, осознали разницу между локальным и удалённым хранением, а также все возможные протоколы хранения, поддерживаемые vSphere. Затем мы изучили архитектуру подключаемых хранилищ (PSA, Pluggable Storage Architecture), модульную инфраструктуру API, которая позволяет производителям хранилищ строить свои собственные подключаемые модули SATP или PSP. Мы изучили как настраивать доступ к хранилищам Fiber Channel, iSCSI и NFS. Мы ознакомились с тем, как создавать склады данных VNFS и управлять ими. Наконец, мы рассмотрели некоторые темы управления Расширенной инфраструктурой.