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

Содержание

Глава 5. Концепции хранилищ vSphere и управление
Сопоставление локального и удалённого хранилищ
Протоколы хранения
Понимание групп RAID
LUN
Подключаемая архитектура хранилищ (PDA)
Типы массива хранения
Настройка доступа к хранилищу FC
Проектирование для резервирования
Устранение единой точки отказа в хосте ESXi
Устранение единой точки отказа в связной архитектуре
Устранение единой точки отказа в массиве хранения
Зонирование и маскирование
WWN
Настройка доступа к хранилищу iSCSI
Как работает iSCSI?
Типы инициатора iSCSI
Типы массива iSCSI
Применение программного iSCSI в хосте ESXi
Настройка инициатора iSCSI для доступа к хранилищу
Настройка множества путей для iSCSI
Что необходимо настроить для сцепления порта?
Как мы проходим настройку сцепления порта?
Группировка NIC
Сцепление интерфейсов vmkernel к адаптеру iSCSI
Настройка доступа к хранилищу NFS
Что нам нужно?
Как монтировать совместные ресурсы NFS?
Монтирование NFS на множество хостов
Управление складом хранения
Файловая система ВМ
Создание склада хранения VMFS
Информация множества путей устройств LUN
Управление ёмкостью хранилища склада хранения
Наращивание/ рост VMFS склада хранения
Расширение/ распространение VMFS склада хранения
Удаление доступа к LUN
Управление снимками VMFS
SIOC
Включение SIOC
DRS хранилища
Начальное размещение
Балансировка использования пространства
Балансировка нагрузки ввода/вывода
Выводы

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

В данной главе мы изучим следующие темы:

  • Сопоставление локальных и удалённых хранилищ

  • Протоколы систем хранения

  • Архитектура подключаемых хранилищ

  • Типы массивов хранения

  • Настройку доступа к хранилищам Fiber channel

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

  • Настройку доступа к хранилищам NFS

  • Управление хранилищами данных

  • Управление операциями ввода/ вывода хранилищ

  • DRS хранилища

Сопоставление локального и удалённого хранилищ

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

 

Рисунок 1



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

  • SATA

  • SCSI

  • IDE

  • USB

  • SAS

  • {Прим. пер.: NVMe}

Тип жёсткого диска, применяемого в используемом вами удалённом хранилище может иметь любой поддерживаемый этим массивом хранения типом. Это обусловлено тем, что доступ к такому удалённому хранилищу осуществляется через интерфейс, подобный некоторому сетевому адаптеру (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:

 

Рисунок 2



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

 

Рисунок 3



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

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

 

Рисунок 4



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

 

Рисунок 5



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

 

Рисунок 6



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

 

Рисунок 7



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

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

 

Рисунок 8



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

Понимание групп RAID

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

  • Чередованием (Striping) называется действие по распределению блоков записываемых данных на все данные диски в данной группе RAID

  • Зеркалированием (Mirroring) называется действие по записи идентичных копий данных на более чем один диск.

Чередование и зеркалирование создают основу для всех прочих типов групп 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

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

 

Рисунок 9



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

Подключаемая архитектура хранилищ (PDA)

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

 

Рисунок 10



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

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

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

  • SATP (Storage Array Type Plugin, Подключаемый модуль типа массива хранения)

  • PSP (Path Selection Plugin, Подключаемы модуль выбора пути)

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 может быть выполнена следующая команда:


# esxcli storage nmp satp list
 	   

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

  • Наиболее часто используемый (MRU)

  • Фиксированный (Fixed)

  • Карусельный (Round robin, RR)

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

  • VMW_PSP_MRU

  • VMW_PSP_Fixed

  • VMW_PSP_RR

[Замечание]Замечание

Для просмотра списка поддерживаемых данной инфраструктурой PSP может быть выполнена следующая команда:


#esxcli storage nmp psp list
 	   
  • Политика выбора MRU (Most Recently Used, Наиболее часто применяемого) пути продолжит применять тот же новый путь после отказа, даже если отказавший путь впоследствии станет активным. MRU является обычно используемой в качестве PSP для массивов активный/ пассивный.

  • Политика выбора Fixed (Фиксированного) пути будет иметь предпочтительный путь, настроенный для транспортировки данных. В случае если предпочтительный путь становится становится активным вслед за неким отказом, данная политика вернётся назад к пути, назначенному предпочтительным. Данная политика обычно применяется для массивов активный/ активный или ALUA.

  • RR (Round robin, карусельная) политика выбора будет распределять операции ввода/ вывода по активным или оптимальным активным путям (в случае массива ALUA) карусельным образом после каждых 1000 IOPS на путь.

Типы массива хранения

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

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

  • Массивы активный/ активный

  • Массивы активный/ пассивный

  • Массивы ALUA (Asymmetric Logical Unit Access, Асимметричного доступа к логическим устройствам)

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

 

Рисунок 11



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

[Совет]Совет проектирования

При проектировании архитектуры хранения с симметричным массивом активный/ активный вы можете выбирать различные предпочитаемые пути на различных наборах хостов ESXi в кластере/ центре обработки данных. Например, Если у вас имеется кластер из 10 хостов, тогда вы можете установить пять хостов с применением в качестве предпочтительного пути через controller-1 и второй набор из пяти хостов, применяющих предпочтительным путь через controller-2. Это приведёт к достижению распределения нагрузки обработки ввода/ вывода на уровне контроллера.

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

 

Рисунок 12



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

[Совет]Совет проектирования

При проектировании некоторой среды с массивом активный/ пассивный убедитесь что все хосты ESXi настроены на то, чтобы видеть все LUN через свои собственные контроллеры. Неверная настройка вызовет посягательство этого массива на владение LUN, что может повлечь за собой переполнение пути.

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

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

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

[Совет]Совет проектирования

Администратор хранилища должен время от времени распределять имеющиеся LUN по всем контроллерам так как необходимо получать эффективное использование массива ALUA.

 

Рисунок 13



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

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

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

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

  • Проектирование для резервирования

  • Зонирование и маскирование

  • Всемирные имена (WWN, World Wide Name)

Проектирование для резервирования

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

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

  • Неисправные кабели сетевой структуры

  • Отказы порта/ HBA

  • Отказы порта/ коммутатора среды

  • Отказы порта/ контроллера массива хранения

  • Отказы жёсткого диска

Устранение единой точки отказа в хосте 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) и таргеты (контроллеры). Существует два вида зон:

  • Аппаратные (hard) зоны

  • Программные (soft) зоны

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

 

Рисунок 14



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

 

Рисунок 15



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

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

  • При выполненном зонировании мы имеем два хоста [H1] и [H2] выделенных в зону для доступа к контроллерам [A] и [B].

  • Контроллер [A] имеет LUN [L1] и [L2], соответствующие ему, а Контроллер [B] имеет LUN [L2] и [L3], соответствующие ему:

     

    Рисунок 16



  • Теперь давайте предположим, что не все хосты ESXi в данной зоне должны иметь доступ ко всем расположенным в этой зоне LUN. В данном случае, для H1 необходим доступ только к LUN 1 и 4, а H2 необходим доступ только к LUN 2 3. Это может быть достигнуто за счёт Списков управления доступом (ACL, Access Control Lists) в портах контроллеров A и B. По этой причине такой контроллер с портом A будет иметь некую запись ACL для H1 и LUN 1 и 4, а порт B будет иметь запись ACL для H2 и LUN 2 и 3:

     

    Рисунок 17



WWN

Во многом аналогично с тем, что подразумевают 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

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

[Совет]Совет проектирования

Рекомендуется поддерживать отдельные коммутаторы для обмена iSCSI в среде центра обработки данных. {Прим. пер.: на самом деле достаточно гарантировать надлежащий QoS для выделяемой под iSCSI полосы, см. Под капотом SDDC, аппаратные средства.}

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

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

  • Как работает iSCSI?

  • Типы инициаторов iSCSI

  • Типы массивов iSCSI

  • Настройку инициатора iSCSI

  • Как получить множество путей?

Как работает iSCSI?

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). Такой сеанс может иметь несколько соединений со своим порталом таргета:

 

Рисунок 18



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

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

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

 

Рисунок 19



Примеры:

  • iqn.2014-12.com.vdescribed.store1

  • iqn.2014-12.com.vdescribed.store2

  • iqn.1998-01.com.vmware.esx02-404f1ad6

Типы инициатора iSCSI

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

  • Программный инициатор iSCSI является компонентом vmkernel и может быть включён в некотором хосте ESXi. Он требует настроенного порта vmkernel с каким- то связанным с ним IP адресом для установления соединения с соответствующим массивом iSCSI. Так как он является программной конструкцией, все его настройки и обработки всех пакетов iSCSI обрабатываются сетевым стеком vmkernel.

    [Замечание]Замечание

    В некотором хосте ESXi может быть только один Программный инициатор iSCSI.

  • Аппаратный инициатор iSCSI выполняет разгрузку части или даже всей работы в своём аппаратном устройстве. Существует два типа аппаратных инициаторов, зависимые и независимые. зависимый аппаратный инициатор iSCSI имеет возможность разгрузки обработки всех сетевых пакетов в TOE (TCP Offload Engine, механизме разгрузки TCP) в имеющемся аппаратном устройстве. Однако, настройка такого инициатора должна выполняться совместно со связанным портом vmkernel данного инициатора. независимый аппаратный инициатор iSCSI может обрабатывать и конфигурацию и соответствующую обработку всех сетевых пакетов. Его настройка осуществляется через встроенное программное обеспечение (firmware) такого устройства, в то время как обработка пакетов может разгружаться в TOE данного устройства.

Типы массива 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.

Применение программного iSCSI в хосте ESXi

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

  1. Создайте некий новый интерфейс vmkernel для его применения с iSCSI. Глава 4, Концепции сетевых сред vSphere и управление имеет разделы, описывающие такое управление интерфейсами vmkernel.

  2. Подключитесь к vCenter при помощи веб клиента vSphere и в странице реестра Home кликните по Hosts and Clusters.

  3. Выберите тот хост ESXi, вкотором в собираетесь включить iSCSI и переместитесь в Manage | Storage | Storage Adapters:

     

    Рисунок 20



  4. Кликните по иконке + и выберите Software iSCSI adapter:

     

    Рисунок 21



  5. В окне Add Software iSCSI Adapter просмотрите своё подтверждение и кликните OK для его утверждения:

     

    Рисунок 22



  6. Выполнив это, порт TCP 3260 в межсетевом экране будет открыт и для входящего, и для исходящего обмена, а затем соответствующий клиент iSCSI будет включён в данном хосте. Кроме того, вы теперь должны видеть некий iSCSI Software Adapter перечисленным под Storage Adapters:

     

    Рисунок 23



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

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

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

  • Обнаруженный IP адрес такого сервера таргета iSCSI и его номер порта

  • Подробности аутентификации CHAP (если они требуются)

  • Массив iSCSI настроенный на предоставление хостам ESXi доступа к необходимым LUN. Чтобы настроить доступ к такому массиву, вам необходимо иметь в руках IQN соответствующего Программных адаптеров iSCSI.

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

  1. Переместиесь в Manage | Storage | Storage Adapters и выберите требующийся программный адаптер iSCSI.

  2. Для выбранного адаптера перейдите в соответствующую закладку Targets, а затем под Dynamic Discovery кликните по Add…:

     

    Рисунок 24



  3. В появившемся окне Add Send Target Server предоставьте необходимые IP адрес/ FQDN данного сервера iSCSI и кликните OK для завершения добавления этого таргета:

     

    Рисунок 25



  4. Когда вы это выполнили, выполните повторное сканирование такого адаптера для обнаружения всех доступных в данном таргете LUN. На самом деле повторное сканирование будет предложено самим UI:

     

    Рисунок 26



  5. Для повторного сканирования самого адаптера при выбранном Программном адаптере iSCSI кликните по иконке повторного сканирования адаптера в панели данного Программного адаптера.

  6. Теперь переместитесь в закладку Devices под панелью подробностей данного адаптера iSCSI. Она должна отображать перечень обнаруженных устройств хранения:

  7.  

    Рисунок 27



    Если вы видите все представленные вами данному хосту ESXi устройства в таком массиве, это означает что вы успешно настроили досту ко всему массиву iSCSI.

Настройка множества путей для iSCSI

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

 

Рисунок 28



Чтобы сделать доступной балансировку нагрузки или избыточность для исходящего в сторону хоста 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. Следующая схема описывает то, что мы пытаемся получить:

 

Рисунок 29



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

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

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

 

Рисунок 30



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

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

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

  1. Переместитесь в Manage | Storage | Storage Adapters чтобы определить Software iSCSI Adapter.

  2. Для выбранного адаптера перейдите в закладку Network Port Binding под Adapter Details.

  3. Находясь в закладке Network Port Binding кликните по иконке чтобы отобразить список VMkernel network adapters для выбора из него:

     

    Рисунок 31



  4. В окне Bind vmhbaXX with Vmkernel Adapter выберите те группы портов, которые были созданы для iSCSI и кликните OK:

     

    Рисунок 32



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

  6. Когда повторное сканирование завершится, вы должны увидеть все состояния имеющихся новых путей в своей закладке Network Port Binding. Возможными состояниями являются Active или Not Used.

     

    Рисунок 33



  7. Кроме того, если вы просмотрите соответствующие пути для данного хранилища, они должны отображать два пути:

     

    Рисунок 34



  8. Если вы видите, что общее число путей на устройство в точности равно общему числу сетевых интерфейсов vmkernel, которые вы связали с соответствующим Программным адаптером iSCSI, это означает что вы успешно выполнили данную задачу.

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

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

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

Что нам нужно?

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

  • Нам необходим доступ к тому сетевому сегменту, в котором расположено требующееся нам хранилище NFS. Таким образом, нашему хосту ESXi понадобится интерфейс VMKernel в той же самой подсети, что и рассматриваемое хранилище NFS. Для ознакомления с созданием интерфейса VMKernel отсылаем вас к Главе 4, Концепции сетевых сред vSphere и управление.

  • Совместные ресурсы NFS должны иметь настроенной опцию no_rootsquash.

Как монтировать совместные ресурсы NFS?

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

  1. Переместитесь в просмотр реестра Host and Clusters.

  2. Кликните правой кнопкой по тому хосту ESXi, которому вы намереваетесь включить доступ к обсуждаемому совместному ресурсу NFS и переместитесь в Storage | New Datastore:

     

    Рисунок 35



  3. В мастере New Datastore выберите в качестве Type NFS. На следующем экране выберите необходимую NFS version и кликните для продолжения Next.

     

    Рисунок 36



  4. Определите Datastore name, путь к совместному ресурсу NFS и соответствующий адрес IP сервера NFS, после чего кликните для продолжения Next:

     

    Рисунок 37



  5. На следующем экране вам будет представлен выбор для включения аутентификации Kerberos. Хосты ESXi должны быть участниками соответствующей Active Directory чтобы это было возможным.

  6. В экраене Ready to Complete просмотрите все установленные настройки и кликните Finish для монтирования данного совместного ресурса NFS.

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

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

 

Рисунок 38



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

Управление складом хранения

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

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

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

  • Файловая система виртуальной машины

  • Создание складов хранения VMFS

  • Управление ёмкостью хранения склада данных

  • Управление снимками VMFS

Файловая система ВМ

Сырые устройства хранения предоставляемые некоторому хосту 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 Терабайт.

Создание склада хранения VMFS

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

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

  1. Воспользуйтесь своим веб клиентом vSphere для соединения с соответствующим сервером vCenter.

  2. Переместитесь в Home | Storage.

  3. Выбрав необходимый объект центра обработки данных, переместитесь в Related Objects | Datastores.

  4. Для подъёма мастера New Datastore кликните по иконке .

  5. В данном мастере выберите типом VMFS и кликните для продолжения Next.

  6. Предоставьте этому складу данных некоторое Имя и выберите какой- то хост из имеющегося списка для просмотра предоставляемых ему сырых LUN. Выберите намеченные LUN и кликните Next для продолжения.

  7. В экране Partition Configuration выберите нужный размер склада данных и кликните Next для продолжения.

  8. На экране Ready to Complete просмотрите установленные настройки и кликните Finish для создания такого склада данных.

Информация множества путей устройств LUN

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

  1. Воспользуйтесь своим веб клиентом vSphere для соединения с сервером vCenter.

  2. Нажмите Ctrl + Alt + 5 для запуска своего реестра Datastore.

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

  4. Переместитесь в Manage | Settings | Connectivity and Multipathing для просмотра перечня всех имеющихся хостов ESXi которые имеют доступ к этом выбранному складу данных.

  5. Выберите конкретный хост ESXi для проверки его текущей политики Множетсвенных путей и соответствующие пути.

  6. Вы можете изменить эту политику выбора пути для выбранного LUN кликнув по Edit Multipathing:

     

    Рисунок 39



  7. Окно Edit Multipathing Policies отобразит все текущие отобранные политики выбора пути и общее число путей к конкретному LUN, лежащему в основе склада хранения. Вы можете воспользоваться ниспадающим меню для изменения этой политики Множественных путей.

     

    Рисунок 40



Управление ёмкостью хранилища склада хранения

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

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

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

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

  1. Воспользуйтесь веб клиентом vSphere для соединения с имеющимся сервером vCenter.

  2. Переместитесь в Home | Storage.

  3. В выбранном объекте центра обработки данных переместитесь в Related Objects | Datastores.

  4. Кликните правой кнопкой по тому складу данных, который вы намереваетесь расширить и кликните по Increase Datastore Capacity.

  5. Выберите лежащий в основе этого склада данных LUN и кликните Next.

  6. Воспользуйтесь ниспадающим меню Partition Configuration для выбора всего оставшегося свободного пространства в DS01 для наращивания этого склада данных:

     

    Рисунок 41



  7. В экране Ready to Complete просмотрите всю информацию и кликните Finish для наращивания этого склада данных.

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

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

  1. Воспользуйтесь веб клиентом vCenter для соединения с имеющимся сервером vCenter.

  2. Переместитесь в Home | Storage.

  3. В выбранном объекте центра обработки данных переместитесь в Related Objects | Datastores.

  4. Кликните правой кнопкой по тому складу данных, который вы собираетесь расширить и кликните Increase Datastore Capacity.

  5. Выберите доступный RAW LUN для расширения на него склада данных.

  6. Выберите Use all available partitions из ниспадающего блока настройки раздела, выберите размер для использования и кликните по Next:

     

    Рисунок 42



  7. Просмотрите подробности в экране Ready to Complete и кликните Finish.

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

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

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

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

  1. Определите тот склад данных, который следует удалить.

  2. Проверьте используют ли этот склад данных какие- либо виртуальные машины.

  3. Размонтируйте этот склад данных.

  4. Отключите то устройство LUN, которое относится к данному складу данных.

  5. Удалите представление данного LUN из рассматриваемого массива хранения.

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

Управление снимками VMFS

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

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

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

 

Рисунок 43



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

 

Рисунок 44



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

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

 

Рисунок 45



  • Самый первый вариант состоит в создании некоторой новой подписи для данного тома VMFS перед его монтированием. Это должно применяться в том случае, если вы монтируете некий клон или моментальный снимок существующего склада данных VMFS на том же самом хосте (хостах). Данная опция представлена как Assign a new signature: в вашем мастере New Datastore. Данный процесс назначения некоторой новой подписи не только обновит такой заголовок LVM вновь созданным UUID, но также и все идентифиакаторы физического устройства (NAA ID) ланного моментального снимка LUN. При этом такой том/ склад данных VMFS будет переименован при помощи префикса словом snap с последующим случайным числом и именем первоначального склада данных:

     

    Рисунок 46



  • Второй вариант состоит в монтировании такого тома VMFS без какого- либо создания подписи или обновления такого заголовка LVM определяемого тома. Такая опция представлена как Keep existing signature в вашем мастере New Datastore. Это применяется тогда, когда вы пытаетесь временно монтировать такой том моментального снимка на том ESXi, который не видит первоначального тома. Если бы вы попробовали смонтировать такой том VMFS с сохранением существующей подписи и если такой хост обнаруживает такой первоначальный том, тогда вам не будет разрешено монтирование данного тома и вы получите предупреждение о наличии другого тома VMFS с тем же самым UUID:

     

    Рисунок 47



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

SIOC

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

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

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

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

 

Рисунок 48



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

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

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

 

Рисунок 49



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

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

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

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

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

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

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

 

Рисунок 50



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

 

Рисунок 51



Включение SIOC

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

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

  1. Подключитесь к своему серверу vCenter и переключитесь на просмотр реестра Datastore.

  2. Выберите нужный вам склад данных в данном реестре и переместитесь в Manage | Settings | General.

  3. На странице настроек General определите Datastore Capabilities и кликните по Edit для открытия окна Configure Storage I/O Control:

     

    Рисунок 52



  4. В окне Configure Storage I/O Control выберите флаговую кнопку Enable Storage I/O Control. Просмотрите пороговые значения перегрузок и убедитесь что они подходят для вашей среды. По умолчанию SIOC динамически устанавливает значения задержек, изучаемые в процессе работы данного склада данных при пиковой пропускной способности 90%:

     

    Рисунок 53



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

  6. Вот таблица, которая может помочь вам выровнять до идеального значения латентности:

    Тип носителя хранилища Пороговое значение латентности в миллисекундах (мс)

    Fiber Channel (FC)

    20 - 30 мс

    Serial Attached SCSI (SAS)

    20 - 30 мс

    Serial ATA (SATA)

    30 - 50 мс

    Solid State Device (SSD)

    15 - 20 мс

  7. Вы также можете выбрать исключение статистик ввода/ вывода из SDRS в данном месте.

  8. Выберите Enable Storage I/O Control и кликните OK.

DRS хранилища

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

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

  • Склады данных в некотором кластере складов хранения должны быть доступны хостам ESXi из единого центра обработки данных (объект регистрации Центра обработки данных vCenter)

  • Один кластер склада данных не может содержать и VMFS и тома NFS

  • Все имеющиеся хосты ESXi, осуществляющие доступ к таким складам данных должны иметь версию ESXi 5.0 или более старшую.

  • Дополнительные требования перечисляются в официальном Руководстве управления ресурсами vSphere 6 на странице 91

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

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

  1. Подключитесь к серверу vCenter и переместитесь в Home | Storage.

  2. Кликните правой кнопкой по тому центру данных, в котором вы намереваетесь создать кластер склада данных и кликните по New Datastore Cluster… для приведения в действие мастера New Datastore Cluster.

  3. Предоставьте кластеру название. Так как основная цель создания такого кластера склада данных состоит во включении в нём Storage DRS, по умолчанию выбирается опция Turn ON Storage DRS. Для продолжения кликните OK.

  4. Выберите необходимый Cluster automation level. имеется два уровня автоматизации:

    • Без автоматизации (Ручной режим) - Это режим устанавливаемый по умолчанию

    • Полная автоматизация

    Также вы в данном месте можете установить пространство, дисбаланс ввода/ вывода, правила усиления родства, политику хранилища/ ВМ, а также уровни эвакуации ВМ. По умолчанию, все эти параметры установлены в значение Use cluster settings:

     

    Рисунок 54



  5. В следующем экране установите все Storage DRS Runtime Settings, которые содержат:

    • Пороговое значение пространства: 80% (по умолчанию)

    • Пороговое значение латентности ввода/ вывода: 15мс (по умолчанию)

    • Родственность ВМ по умолчанию: Сохранять VMDK вместе по умолчанию

    • Пороговое значение разницы пространства перед созданием рекомендаций: 5%

    • Частота проверки дисбаланса ввода/ вывода^ 8 часов (по умолчанию)

    • Пороговое значение дисбаланса ввода/ вывода: Aggressive+5 (по умолчанию)

  6. По окончанию выберите тот кластер, из которого выбирать склады данных.

  7. Выберите тот склад данных, который вы собираетесь сделать частью создаваемого кластера Склада данных.

  8. Просмотрите весь экран Ready to Complete и кликните Finish для создания кластера склада данных с включённым SDRS в нём.

Когда 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 и управлять ими. Наконец, мы рассмотрели некоторые темы управления Расширенной инфраструктурой.