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

В этом документе рассмотрены наилучшие практики и рекомендованные решения по использованию универсальных систем хранения NetApp для виртуальной серверной инфраструктуры VMware® vSphere™. NetApp создает решения для хранения данных под VMware с 2001 года. Все эти годы NetApp разрабатывает операционные руководства для администраторов систем хранения для Data ONTAP® и ESX/ESXi Server. Эти наработки были документированы и закреплены как наилучшие практики и рекомендованные решения. Этот документ собрал их все воедино.

1.2 Использование

Рекомендации и практики, представленные в этом документе, следует рассматривать как требования, если не оговорено иное. Хотя неследование приведенным рекомендациям чаще всего не влияет на ваши возможности получать поддержку NetApp и VMware для ваших решений, но отметьте, что, как правило, отказ от реализации той или иной рекомендации приводит к необходимости ее реализовать позднее, на уже значительно более обширной системе, что часто уже приводит к необходимости остановки работы приложений, или системы в целом. По этой причине мы выступаем за то, чтобы вы реализовали все приведенные в документе практики и рекомендации непосредственно при начальном развертывании (или миграции с более старой версии) своей виртуальной инфраструктуры.

Все рекомендации этого документа применимы конкретно к использованию систем хранения NetApp с VMware vSphere. В тех случаях, когда написанное в этом документе пересекается с утверждениями в других документах, оно должно заменять все ранее опубликованные рекомендации из других документов NetApp, в применении к использованию NetApp c vSphere.

Внимание: Для использования плагинов NetApp к vSphere вам нужно использовать Data ONTAP версии 7.3.1.1 или новее. Если вы используете более раннюю версию Data ONTAP, вам придется использовать ручные процедуры при выполнении некоторых из описанных в документе действий.

В дополнение к этому документу, NetApp и наши партнеры предлагают услуги professional services по разработке и развертыванию решений, описанных в данном документе. Такие услуги могут помочь вам построить ваш виртуальный датацентр с максимальной эффективностью и в сжатые сроки, с учетом всей вашей индивидуальной специфики.

1.3 Целевая аудитория

Данный документ является частью обширной коллекции рекомендаций, доступной в NetApp Technical Library и нацелен на использование людьми, занимающимися разработкой архитектуры решений, управления и поддержки VMware Virtual Infrastructure. Читатели данного документа должны, как минимум, быть знакомыми с принципами работы VMware ESX/ESXi Server 4.0, vCenter™ Server 4.0, и NetApp Data ONTAP 7G.

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

2 Обзор хранилищ данных для VMware

Администраторам системы хранения

Администраторам Virtual Infrastructure

2.1 Введение в хранилища для виртуальной инфраструктуры

VMware ESX позволяет использовать три типа конфигурации хранилища данных при подключении сетевых систем хранения: датасторы VMFS, датасторы NAS, и непосредственно подключаемые разделы, так называемые raw device mappings, RDM. Подразумевается, что планирующий развертывание инфраструктуры VMware понимает, что использование совместно используемой сетевой системы хранения необходимо для таких возможностей VMware, как HA, DRS, VMotion™, и FT (fault tolerance). Цель данной главы – дать необходимую информацию для разработки пользователем своего виртуального датацентра.

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

2.2 Преимущества многопротокольных систем хранения

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

VMware и NetApp поддерживают технологии мультипротокольного использования. Эти технологии позволяют пользователям выбирать и использовать лучшие, и наиболее подходящие им средства построения виртуального датацентра, воспользовавшись наиболее сильными сторонами каждого из протоколов. Вместо спора «SAN против NAS», рассмотрите задачу в разрезе операционной стоимости, исходя из типа сети хранения, используемого виртуальным датацентром.

Вне зависимости от того, используете ли вы Fibre Channel (FC) или Ethernet (NFS, iSCSI, и FCoE), эти технологии могут быть использованы совместно в системе хранения NetApp для того, чтобы добиться максимального эффекта консолидации и виртуализовать большинство приложений, не нуждаясь в дополнительном оборудовании, чтобы обеспечить требования всей инфраструктуры. Это и есть виртуализация, и это то, что наиболее ценно в системе хранения для нее.

2.3 Правило '80/20'

При разработке архитектуры хранения для виртуального датацентра вы можете воспользоваться правилом 80/20, согласно которому 80% всех систем обычно могут быть виртуализированы для консолидации их хранилищ. Оставшиеся 20% можно охарактеризовать как сервера приложений класса business-critical, и, хотя они также могут быть успешно виртуализированы, их данные, как правило, следует размещать в изолированных датасетах.

Свойства консолидированных датасетов

• Использующие их виртуальные машины не нуждаются в специальных агентах резервного копирования и восстановления для данных своих приложений.

• Несут в себе множество виртуальных машин и используют значительные объемы на системе хранения.

• Каждая отдельная VM может не использовать значительный объем пространства или ввода-вывода, однако все вместе такие VM могут иметь значительные требования по этим параметрам.

• Такие датасеты хранятся на большом, совместно используемом многими такими датасетами массиве хранения (датасторе).

Свойства изолированных датасетов (для критичных приложений)

• Использующие их виртуальные машины нуждаются в агентах резервного копирования и восстановления для данных своих приложений.

• Каждая такая виртуальная машина работает с большим объемом хранения или большим объемом операций ввода-вывода.

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

• Такой датасет хранится на отдельном, высокопроизводительном, индивидуальном и не разделяемом с другими задачами датасторе.

Консолидированный датасет хорошо работает с датастором NFS, так как его использование дает большую гибкость в распределении емкости, большую, чем при использовании датасторов в SAN, в случае использования сотен и тысяч VM. Изолированные датасеты хорошо работают с использованием любых протоколов хранения; однако, некоторые инструменты или приложения могут иметь ограничения в области совместимости при использовании NFS и/или VMFS.

Несмотря на то, что каждый случай внедрения виртуализации по своему уникален, эволюция вашего датацентра из «физической» в «виртуальную» форму, как правило, будет следовать «правилу 80/20», и мультипротокольные возможности систем хранения NetApp для VMware позволят вам виртуализовать больше систем, быстрее и проще, чем с использованием традиционных систем хранения.

2.4 Датасторы VMFS

VMware Virtual Machine File System (VMFS) это высокопроизводительная кластерная файловая система, обеспечивающая для датасторов создание совместно используемого пространства хранения. Датасторы VMFS могут быть созданы поверх LUN-ов, подключенных по Fibre Channel, iSCSI, или Fibre Channel over Ethernet (FCoE). VMFS позволяет традиционному LUN-у быть одновременно доступным каждому серверу ESX в кластере.

Рисунок 1) Кластер ESX подключенный к датастору VMFS с помощью FC, FCoE, или iSCSI.

VMFS обеспечивает администратору VMware достаточную независимость от администратора системы хранения. При использовании совместно используемых (shared) датасторов, администратор VMware может свободно распределять пространство хранения виртуальным машинам, по мере возникновения в нем потребности. При такой схеме большинство задач управления данными осуществляется через VMware vCenter Server.

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

Эта схема использования системы хранения может создать трудности при мониторинге и анализе производительности, а также масштабировании. Так как общий, совместно используемый массив хранения, обслуживает весь агрегированный поток ввода-вывода для всех хранящихся на нем виртуальных машин, такая архитектура не позволяет простым способом идентифицировать и проанализировать индивидуальную загрузку ввода-вывода отдельной виртуальной машины.

Датастор типа Spanned VMFS

VMware позволяет создавать том VMFS, состоящий из конкатенации нескольких LUN-ов в один логический датастор, который называется spanned datastore. Так как spanned datastore не ограничен величиной 2TB для размера LUN, он обычно может быть использован для преодоления ограничений по масштабированию и ограничений очереди ввода-вывода (I/O queues) на один LUN. Традиционные архитектуры имеют ограничение по количеству команд, одновременно посланных в данный момент времени на LUN (ограниченных так называемой «очередью ввода-вывода»), что может влиять на общую производительность ввода-вывода датастора.

Системы хранения NetApp, работающие под управлением OS Data ONTAP свободны от таких ограничений традиционных архитектур, по этой причине NetApp не рекомендует использовать spanned VMFS datastores.

Рисунок 2) Кластер ESX, подключенный к датастору типа spanned VMFS.

Датасторы VMFS на LUN NetApp

NetApp расширяет возможности использования датасторов VMFS с помощью ряда своих технологий, куда входят средства thin provisioning средствами системы хранения; использование дедупликации данных; мгновенное, не занимающее места на дисках создание клонов данных; и несколько инструментов интеграции, таких как Site Recovery Manager, SnapManager® for Virtual Infrastructure, инструмент Rapid Cloning Utility, Virtual Storage Console, и SANscreen® VM Insight. Наша архитектура LUN, свободная от ограничений «глубины очереди», позволяет датасторам VMFS масштабироваться значительно более широко, чем это доступно для архитектур традиционных систем хранения.

2.5 Датасторы NFS

vSphere позволяет использовать производительные системы хранения NFS для создания датасторов с параллельным доступом к нему со всех узлов кластера ESX. Этот метод доступа очень похож на доступ к датастору VMFS. Реализация NFS, предлагаемая NetApp, обеспечивает высокую производительность, малые затраты «на порт» системы хранения, и ряд улучшенных возможностей управления данными.

Рисунок 3 показывает пример такой конфигурации. Отметьте, что, хотя структура хранилища и выглядит похожей на использование датастора VMFS, каждый виртуальный диск имеет свою собственную очередь ввода-вывода (I/O queue), непосредственно управляемую NetApp FAS.

Рисунок 3) Кластер ESX, подключенный к датастору NFS.

Датасторы NFS на NetApp

Использование для размещения датасторов VMware протокола NFS на системах хранения NetApp позволяет создать высокопроизводительное, легко администрируемое и расширяемое решение, с высокой степенью использования пространства хранения, которое обычно превышает достижимое с помощью других протоколов хранения, таких как, например, Fibre Channel. Эта архитектура позволяет в десять раз увеличить плотность VM на датастор с пропорциональным уменьшением количества датасторов в виртуальной инфраструктуре. При использовании NFS, виртуальная инфраструктура позволяет добиться операционной экономии, так как при этом возможно использование меньшего количества пулов хранения для распределения, управления, резервного копирования, репликации и так далее. Используя NFS, пользователи получают преимущества интеграции технологий виртуализации VMware с WAFL®, средством управления и виртуализации хранения от NetApp. Такая интеграция обеспечивает прозрачный доступ к таким возможностям на уровне VM, как дедупликация, мгновенное создание клонов отдельных VM или датасторов целиком, thin provisioning средствами самой системы хранения, автоматизированное изменение размеров датасторов с помощью политик, и непосредственный доступ к содержимому снэпшотов, созданных средствами самой системы хранения.

NetApp предлагает ряд интеграционных инструментов, таких как Site Recovery Manager, SnapManager for Virtual Infrastructure, Rapid Cloning Utility, и Virtual Storage Console.

2.6 Raw Device Mapping

ESX позволяет виртуальным машинам иметь прямой доступ к LUN-ам для определенных случаев их использования, таким, как, например P2V clustering или использование средств управления хранилищем от производителя системы хранения. Такой тип доступа называется raw device mapping (RDM) или «непосредственный доступ» и этот режим может быть сконфигурирован для Fibre Channel, iSCSI, и Fibre Channel over Ethernet (FCoE). В таком варианте использования, ESX действует как прокси между VM и системой хранения. В отличие от VMFS и NFS, разделы типа RDM не обеспечивают совместное использование датасторов несколькими VM. Рис.4 показывает пример такой конфигурации.

RDM это технология, позволяющая использовать кластеризацию на уровне хостов physical-to-virtual, такую как, напримерs, Microsoft® Cluster Server (MSCS). RDM обеспечивает традиционный доступ к LUN для хоста, по этой причине он обеспечивает максимально возможную производительность дискового ввода-вывода, и ее легко мониторить обычными средствами контроля и анализа дисковой производительности на системе хранения.

Рисунок 4) Кластер ESX, в котором VM подключены к RDM LUN при помощи FC или iSCSI.

RDM LUN на NetApp

Разделы формата RDM доступны в двух режимах: «физическом» (physical) и «виртуальном» (virtual). Оба режима поддерживают основные возможности VMware, такие как VMotion и могут использоваться в кластерах HA и DRS. Основное отличие между этими двумя формами заключается в объеме виртуализации SCSI, происходящем на уровне VM. Эта разница вызывает ряд ограничений при использовании MSCS и снэпшотов VMware.

NetApp улучшает возможности использования RDM путем обеспечения thin provisioning на стороне системы хранения, дедупликации данных, использования интеграционных компонентов, таки как SnapDrive®, резервного копирования данных приложений с помощью снэпшотов и SnapManager, а также создания эффективных клонов RDM LUN с помощью технологии FlexClone®.

Техническое замечание: Виртуальные машины, на которых работает MSCS, должны использовать политику выбора пути - MRU.

2.7 Таблицы сравнения различных типов датасторов

Выбор между тем или иным протоколом хранения требует оценки множества необходимых параметров и возможностей. Приведенные ниже таблицы сравнивают различные возможности для каждого протокола хранения. Сходная таблица по функциональности VMware находится в VMware ESX and ESXi Server Configuration Guide.

Таблица 1) Общие поддерживаемые возможности.

Возможности	FC/FCoE	iSCSI	NFS
Формат	VMFS или RDM	VMFS или RDM	NetApp WAFL
Максимальное количество датасторов или LUN-ов	256	256	64
Максимальный размер датастора	64TB	64TB	16TB или 100TB*
Максимальный размер LUN/файловой системы NAS	2TB минус 512b	2TB минус 512b	16TB или 100TB*
Оптимальная величина queue depth на LUN	64	64	N/A
Доступные скорости интерфейса	4 и 8Gb FC и 10Gb Ethernet	1 и 10Gb Ethernet	1 и 10Gb Ethernet

*для использования 100TB необходимо использование 64-bit aggregates и соответствующей модели контроллера NetApp.

Таблица 2) Поддерживаемые функциональные возможности VMware.

Возможности	FC/FCoE	iSCSI	NFS
VMotion	Да	Да	Да
Storage VMotion	Да	Да	Да
VMware HA	Да	Да	Да
DRS	Да	Да	Да
VCB	Да	Да	Да
MSCS внутри VM	Да, с помощью RDM для Shared LUN	Инициатор в GOS поддерживается	Не поддерживается
Fault Tolerance	Да, с eager-zeroed thick VMDK или Virtual Mode RDM**	Да, с eager-zeroed thick VMDK или Virtual Mode RDM**	Да, с eager-zeroed thick VMDK
Site Recovery Manager	Да	Да	Да
Thin Provisioned VM	Да	Да	Да*
VMware Native Multipathing	Да	Да	N/A
Boot from SAN	Да	Да с HBA	Нет

* Это значения по умолчанию для всех VM на NetApp NFS

** NetApp SnapDrive for Windows® не поддерживает virtual-mode RDM devices

Таблица 3) Поддерживаемы возможности управления хранилищем NetApp.

Возможности	FC/FCoE	iSCSI	NFS
Дедупликация	Экономия на уровне системы хранения	Экономия на уровне системы хранения	Экономия на уровне датастора
Thin Provisioning	Датастор или RDM	Датастор или RDM	Датастор
Изменение размера датастора	Только увеличение	Только увеличение	Увеличение и сжатие
SANscreen VM Insight	Да	Да	Да
SnapDrive в гостевой OS	Да	Да	Нет*
ESX Host Utilities/VSC 2.0	Да	Да	Да
Backup и Recovery через VSC 2.0	Да	Да	Да
Provisioning и Cloning в VSC 2.0	Да	Да	Да

* Поддержка управляемых по NFS-дисков VMDK в SnapDrive запланировано в будущей версии SnapDrive.

Таблица 4) Поддерживаемые возможности резервного копирования.

Возможности	FC/FCoE	iSCSI	NFS
Снэпшоты	Да	Да	Да
Replicated backup в SRM	Да	Да	Да
SnapMirror	Датастор или RDM	Датастор или RDM	Датастор или VM
SnapVault	Датастор или RDM	Датастор или RDM	Датастор или VM
Доступ к VMDK как к образу диска	VCB	VCB	VCB, VIC File Explorer
Доступ к файловому содержимому VMDK	VCB, только Windows	VCB, только Windows	VCB, и сторонние приложения
Гранулярность NDMP	Датастор	Датастор	Датастор или VM

2.8 Форматы виртуальных дисков VMware

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

Тип виртуального диска Thick

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

Рисунок 5) thick VMDK и как он соотносится с блоками на системе хранения.

Тип виртуального диска Thin

Этот тип виртуального диска очень похож на тип thick, за исключением того, что не занимает в момент своего создания пространство на датасторе. Когда требуется пространство для хранения, VMDK распределяет его цепочками последовательных байт (chunks), равных размеру блока файловой системы. Для VMFS это размер между 1MB и 8MB (зависит от общего размера файловой системы), а для NFS он всегда равен 4KB. Процесс выделения блоков на совместно используемом датасторе VMFS задействует операции с метаданными, и по этой причине выполняется SCSI locks для целиком датастора на время, пока исполняется операция выделения пространства. Хотя длительность этого процесса и очень коротка, он, тем не менее, задерживает на это время операции записи всех виртуальных машин на этом датасторе.

Рисунок 6) thin VMDK и как он соотносится с блоками на системе хранения.

Как и в случае типа thick, тип thin VMDK не форматируется в момент создания. Это также означает, что перед записью в ранее неиспользованное место такого диска возникает пауза на время записи нулей в запрошенное для записи место. Этот процесс выделения блоков внутри датастора происходит всякий раз, когда происходит операция записи в диапазон, после создания диска не записывавшийся.

Суммируя различие и сходство между thick и thin-типами виртуальных дисков, помните, что оба они приостанавливают ввод-вывод на время записи новых, ранее неиспользованных областей виртуального диска, так как эти области требуют предварительной инициализации записью туда нулей, однако, в случае типа виртуального диска thin, он также должен предварительно получить дополнительное пространство у датастора.

Тип виртуального диска Eager Zeroed Thick

Этот тип виртуального диска похож на thick, также предварительно занимает емкость в датасторе при создании; однако, в отличие от типа thick и thin, тип виртуального диска eager-zeroed thick непосредственно форматирует содержимое блоков данных, заполняя их нулями в момент своего создания.

Рисунок 7) eager-zeroed thick VMDK и как он соотносится с блоками на системе хранения.

2.9 Увеличение уровня использования хранилища

NetApp предлагает технологии виртуализации хранения, которые улучшают результаты экономии пространства, предлагаемые VMware с помощью технологии thin-provisioning. Дедупликация типа FAS data deduplication и thin provisioning для датасторов VMFS и RDM LUN предлагают существенную экономию пространства и увеличивают уровень использования дискового массива FAS. Обе эти технологии являются «родными» для дисковых систем NetApp, и не требуют каких-либо изменений конфигурации, когда используются для серверов ESX.

Внимание: Все виртуальные диски, хранящиеся на NetApp NFS, всегда являются thin-provisioned VMDK и поддерживают кластерные возможности VMware.

Рисунок 8) Отметьте, что VM развернутые на NetApp NFS всегда являются thin provisioned и для них включена поддержка кластерности.

2.10 Использование Thin Provisioning

Вы наверняка хорошо знакомы с традиционным способом распределения пространства на системах хранения, и с тем, как пространство хранения заранее определяется и назначается серверу, а в случае VMware – виртуальной машине. Обычной практикой для серверных администраторов является традиция выделять при этом пространство «с запасом», «на вырост», с тем, чтобы обезопасить себя от ситуации внезапного исчерпания места и остановки приложения на время вынужденного расширения исчерпавшегося пространства под задачу. Поскольку ни одна система не может использовать мгновенно все 100% выделенного ей пространства, то возможен метод виртуализации, позволяющий администраторам делать так называемый oversubscribe для хранилища, сходным образом, как это делается с прочими серверными ресурсами (например CPU, памятью, сетевыми ресурсами, и так далее). Такая форма виртуализации хранилища называется thin provisioning.

Традиционный метод распределения пространства хранения сразу занимает все выделенное пространство; thin provisioning обеспечивает занятие места только по мере возникновения в нем потребности у задачи. Преимущество пространства системы хранения, использующейся в режиме thin-provision в том, что оно работает как совместно используемый пул ресурсов, которое занимается только по мере того, как соответствующей VM потребуется место для записи ее данных. Такая схема «совместного использования ресурсов» увеличивает общий уровень использования, устраняя ситуацию с неиспользуемыми, но распределенными и недоступными другим задачам областями, обычно часто встречающуюся при использовании традиционных систем хранения.

«Ценой» использования thin provisioning и oversubscribing является то, что попытка всех VM одновременно занять все выделенное им пространство разом приведет к исчерпанию пространства на системе хранения, и требует от администратора наблюдения за уровнем использования пространства и своевременного добавления дополнительных физических дисков.

Опции Thin Provisioning в NetApp

Возможности thin provisioning средствами системы хранения NetApp расширяют возможности thin provisioning для VMDK в VMware, и позволяют LUN-ам, которые несут датасторы VMFS, занимать на дисках системы хранения только то место, которое занимают находящиеся в них файлы VMDK (они сами при этом могут быть как в thick-, так и в thin-формате). Кроме этого, LUN-ы, подключенные как RDM, также могут быть организованы какs thin provisioned.

NetApp рекомендует при использовании thin-provisioned LUN-ов, развертывать их на томах FlexVol®, также использующих thin provision с емкостью, равной 2x от размера LUN. При развертывании LUN таким образом, том FlexVol будет действовать как квота (quota). Пространство хранения, потребленное LUN сообщается FlexVol и содержащему его aggregate.

2.11 Дедупликация данных на системе хранения

Одна из самых популярных возможностей VMware это возможность быстро создать виртуальную машину из так называемых «шаблонов» (VM templates). Такой VM template включает в себя конфигурационный файл VM (.vmx) и один или несколько файлов виртуальных дисков (.vmdk), на которых расположена операционная система, приложения и патч-файлы, или системные обновления. Развертывание виртуальной машины из такого шаблона экономит время администратора, так как сводится только к копированию конфигурационного файла и файлов виртуального диска, а затем регистрации этой копии как отдельной, независимой виртуальной машины. При этом такой процесс порождает дублирующиеся файлы для каждой новой развернутой VM. Рисунок 9 показывает пример типичного использования пространства хранения в vSphere.

Рисунок 9) Использование пространства на традиционной системе хранения.

NetApp предлагает технологию дедупликации под названием FAS data deduplication. С использованием NetApp FAS data deduplication, в виртуальных серверных инфраструктурах VMware можно устранить дублирующиеся фрагменты данных, что обеспечивает значительное увеличение эффективности хранения. Дедупликация, как форма виртуализационной технологии, позволяет нескольким виртуальным машинам совместно использовать одни и те же физические блоки системы хранения NetApp FAS образом, сходным с тем, как виртуальные машины совместно используют системную память. Дедупликацию данных можно непосредственно использовать в «виртуальном датацентре», без необходимости изменять практику или пути решения задач администраторами VMware. Дедупликация отрабатывает на системах хранения NetApp FAS по расписанию, через заданные интервалы, и не использует ресурсы CPU сервера ESX. Рис. 10 показывает пример эффекта дедупликации на использование пространства в системе vSphere.

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

Рисунок 10) Использование пространства хранения после включения дедупликации.

Использование дедупликации с VMFS и RDM LUN

Включение дедупликации для данных на LUN-ах дает результат в виде экономии пространства. Однако обычное поведение LUN состоит в предварительном резервировании пространства, равного определенному при создании LUN-а размеру. Такая схема означает, что хотя система хранения в ходе дедупликации снизит объем занятого на дисках пространства, результат дедупликации останется почти невидимым на уровне LUN-ов, так как пространство, уже зарезервированное на томе при создании LUN-ов не уменьшится.

Для того, чтобы увидеть эффект от дедупликации с LUN-ами, вы должны включить на NetApp LUN thin provisioning. Заметьте, что хотя дедупликация и уменьшает объем занятого на системе хранения пространства, администратор VMware не видит это высвобожденное пространство непосредственно, так как смотрит на хранилище на уровне LUN, а LUN-ы всегда сообщают о себе только величину своего распределенного размера, неважно, будут они обычными (thick-) или thin-provisioned. Однако NetApp Virtual Storage Console (VSC) обеспечивает администратору VI информацию о использовании пространства на хранилище на всех уровнях стека хранения.

NetApp рекомендует, планируя использование дедупликации на thin-provisioned LUN-ах, развертывать их на томах FlexVol®, также использующих thin provision с емкостью, равной 2x от размера LUN. При развертывании LUN-ов таким образом, том FlexVol будет действовать как квота (quota). Пространство хранения, потребленное LUN сообщается FlexVol и содержащему его aggregate

Преимущества дедупликации при использовании NFS

В отличие от ситуации с LUN-ами, когда вы выполняете дедупликацию с NFS, то результат экономии пространства становится немедленно доступен для администратора VMware. Выгода от дедупликации прозрачна для хранилища и команды администраторов VI. Для такого использования нет каких-то особых условий.

Управление дедупликацией из VMware

Используя NetApp vCenter plug-ins, администраторы VMware имеют возможности включить, выключить, обновить результаты работы дедупликации на уровне непосредственно датастора. Подробности смотрите в разделе 5.

2.12 vStorage Array Integration в VMware vSphere 4.1

С выходом vSphere 4.1 у VMware появился набор средств для улучшения интеграции систем хранения в vSphere. Эти средства состоят из трех основных компонент: vStorage APIs for array integration (VAAI), storage I/O control (SIOC), и новые средства сбора статистики производительности системы хранения.

vStorage APIs for Array Integration (VAAI)

VAAI предоставляет механизм ускорения ряда функций, обычно выполняемых гипервизором, путем переноса их на систему хранения. Цель VAAI обеспечить больший уровень масштабируемости на уровне хоста, освободив ресурсы гипервизора (CPU, память, ввод-вывод, и так далее) при таких операциях, как, например, распределение емкости и клонирование. Первый релиз VAAI обеспечивает поддержку новых возможностей только для датасторов VMFS. В случае датасторов NFS на системе хранения NetApp, многие операции, например распределение пространства и клонирование, уже перенесены на систему хранения, путем использования возможностей Virtual Storage Console и FlexClone. Первая версия VAAI добавляет подобные возможности и для датастора VMFS. Текущая версия VAAI реализует три новых возможности:

• Full copy: Когда хост ESX/ESXi инициирует копирование данных, VAAI позволяет системе хранения самостоятельно произвести это копирование внутри системы хранения, без необходимости хосту проводить считывание и запись данных. Это снижает время операции и загрузку сети во время клонирования и миграции виртуальных машин при vMotion.

• Block zeroing: Когда создается новый виртуальный диск, например в формате eager-zeroed thick VMDK, этот диск при создании должен быть отформатирован и заполнен нулями. VAAI позволяет системе хранения самостоятельно провести заполнение такого диска нулями, снимая такую загрузку с хоста и канала передачи данных между хостом и системой хранения.

• Hardware-assisted locking: VMFS это совместно используемая кластерная файловая система, поэтому ей требуются средства управления метаданными и локированием, чтобы гарантировать то, что два хоста не смогут получить доступ к одни и тем же данным на запись одновременно. VAAI обеспечивает альтернативный метод локирования, вместо обычного метода SCSI-2 reservations, который использовался ранее. Такой метод локирования работает с гораздо более тонкой гранулярностью объектов, управляется автоматически хостом и системой хранения, и позволят достичь гораздо большего уровня масштабируемости датасторов VMFS,чем ранее использованный.

Использование VAAI требует соответствующей поддержки от системы хранения. Для использования VAAI на системах хранения NetApp, она должна работать под версией Data ONTAP 8.0.1 (и новее), которая выйдет в конце 2010 года. VAAI включена по умолчанию для Data ONTAP и ESX/ESXi. Версия 2.0 Virtual Storage Console показывает, имеется ли поддержка VAAI со стороны системы хранения.

Storage I/O Control (SIOC)

Функция Storage I/O Control, появившаяся в vSphere 4.1, обеспечивает quality of service для системы хранения, используя концепцию совместного использования и ограничений, сходно с тем, как управляют ресурсами CPU и памяти. SIOC позволяет администраторам обеспечить, чтобы конкретная VM имела приоритетный доступ к ресурсам системы хранения, в сравнении с другими VM, основываясь на распределении совместного использования ресурсов, лимитов на максимум в IOPS, и того, достиг ли данный датастор заданных порогов. SIOC в настоящий момент поддерживает только датасторы VMFS, подключенные по FC или iSCSI.

Для использования SIOC его надо разрешить на уровне датастора, а затем определить лимиты для VM на данном датасторе. Лимиты для VM определяются на закладке Resources в диалоге VM Edit Settings. По умолчанию все VMs в датасторе имеют равные доли ресурсов и не ограничены по IOPS.

Рисунок 11) Включение SIOC на датасторе и VM в vSphere.

Помните, что SIOC не предпринимает никаких действий по ограничению пропускной способности, пока не превышен установленный порог. Пока общая производительность датастора достаточна, находясь ниже установленного порога, все VM на этом датасторе получают равный доступ к хранилищу. Порог этот устанавливается на датастор, и измеряется в миллисекундах задержки (latency). Значение по умолчанию равно 30ms, и для большинства система нет необходимости менять эту величину. Уровень приоритета устанавливается в low, normal, и high; или 500, 1000, и 2000 resource shares, соответственно, или же можно установить свое собственное значение^{^[*]}.

Величина resource shares используется для того, чтобы определить то, какая доля пропускной способности на датасторе с включенным SIOC будет предоставлена одной виртуальной машине по сравнению с другой. Например, когда ограничения SIOC действуют на датасторе, VM с 1000 shares будет иметь вдвое больший приоритет по доступу к ресурсам, чем VM с 500 shares. Реальный уровень пропускной способности, достижимый каждой VM, зависит от возможностей и потребностей виртуальных машин. Посмотреть существующие значения установок параметров SIOC виртуальных машин можно в клиенте vSphere, выбрав датастор, а затем закладку virtual machine.

Доступ VM к датастору может быть также ограничен на уровне IOPS. Установка ограничения maximum IOPS для VM организует постоянно действующее ограничение vSphere для пропускной способности этой VM по уровню IOPS, даже если общий порог по latency, рассмотренный выше, и не был превышен. Для того, чтобы ограничить VM по величине в MB/сек, вам надо использовать лимит по IOPS, установив его из расчета на типичный размер блока ввода-вывода этой виртуальной машины: например, чтобы ограничить VM с типичным размером блока ввода-вывода в 8k на уровне пропускной способности 10MB/сек, установите значение maximum IOPS для VM на уровне 1280. Можно использовать формулу: MB/sec ÷ I/O size = IOPS. Например: 10240000 ÷ 8000 = 1280.

Показатели производительности системы хранения

Дополнительное усовершенствование, появившееся в vSphere 4.1 это увеличение доступных параметров сбора статистики и счетчиков производительности хранилища, как в vCenter, так и в команде esxtop. В системе VI3 сбор метрик производительности подсистемы хранения непосредственно в vCenter был ограничен просмотром производительности определенных физических дисков. Это дает возможность наблюдать производительность хранилища раздельно по датасторам на системе хранения NetApp, так как типичный датастор, подключеный по FC с системы хранения NetApp, это обычно один отдельный LUN на системе хранения, и представленный в vCenter performance monitor как отдельный физический диск. Однако когда несколько дисков или LUN-ов используются для создания одного датастора, то трудно изолированно оценить производительность такого датастора в целом; это ограничение также присутствует в vSphere 4.0. Кроме этого, новая возможность просмотреть метрики по датастору NFS или индивидуальным виртуальным дискам, подключенным к виртуальным машинам недоступна для VI3 и vSphere 4.0. Метрики, доступные для хостов и VM в vSphere 4.0 показаны на рис. 12.

Рисунок 12) Статистика производительности, доступная в vSphere 4.0.

Дополнительные показатели производительности, появившиеся в vSphere 4.1, позволяют администратору виртуальной инфраструктуры просматривать статистику по вводу-выводу хоста отдельно по путям к датасторам, и по адаптерам FC при использовании инфраструктуры FibreChannel. Отчеты по производительности датастора доступны для всех протоколов: FC, FCoE, iSCSI, и NFS. Метрики производительности VM теперь включают в себя производительность датастора с разбивкой по VM и производительность по отдельным виртуальным дискам. Рис. 13 показывает дополнительные метрики производительности, появившиеся в vSphere 4.1.

Рисунок 13) Дополнительная статистика производительности, доступная в vSphere 4.1.

Некоторая проблема при использовании NAS заключалась в невозможности определить, какой из датасторов NFS наиболее активный, или какой из виртуальных дисков какой VM наиболее активен. Рис. 14 это пример метрики по виртуальным дискам, в vSphere 4.1.

Рисунок 14) Статистика производительности по виртуальным дискам, доступная в vSphere 4.1.

Таблица 5) Статистика производительности системы хранения, доступная в зависимости от протокола, и версии vSphere.

Объект	Компонент	Статистика	Протокол	Доступно
Объект	Компонент	Статистика	Протокол	vCenter	ESXTOP*
Хост ESX/ESXi	Datastore	Полоса (throughput) и задержки (latency)	FC, iSCSI, NFS	4.1	4.1
	Storage Adapter	Полоса (throughput) и задержки (latency)	FC	4.1	4.0+
	Storage Path	Полоса (throughput) и задержки (latency)	FC	4.1	4.0+
	LUN	Полоса (throughput) и задержки (latency)	FC, iSCSI	4.0+	4.0+
VM	Datastor	Полоса (throughput) и задержки (latency)	FC, iSCSI, NFS	4.1	4.1
	Virtual Disk	Полоса (throughput) и задержки (latency)	FC, iSCSI, NFS	4.1	4.1

* Доступ к команде esxtop для хостов ESXi требует использования команды vSphere CLI resxtop.

3 Разработка и создание сети хранения

Администраторам системы хранения

Администраторам Virtual Infrastructure

Администраторам локальной сети

Целью любой сети хранения данных является бесперебойное обслуживание всех подключенных к ней узлов. В этом разделе мы в первую очередь сфокусируемся на том, как построить сеть хранения на технологии Ethernet, с обеспечением высокой доступности. Причина сфокусироваться на Ethernet двоякая. Во-первых, сети хранения Fibre Channel работают с одним протоколом, Fibre Channel Protocol (FCP). По этой причине, такая сеть естественным образом получается проще при разработке и развертывании высокодоступной конфигурации. Во-вторых, нынешний тренд в отрасли однозначно указывает на развитие многоцелевых сетей Ethernet (так называемые converged networks) обеспечивающих в пределах единой сети Ethernet хранение и передачу данных, голосовые сервисы, и пользовательский доступ.

Условия создания производительной сети хранения данных

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

• Использовать избыточность коммутаторов в многокомутаторной системе

• Использовать так много доступных физических путей, как это возможно

• Масштабироваться по множеству физических интерфейсов или портов

3.1 Основы сети хранения SAN и NAS

Для vSphere основная разница между типами хранилищ SAN и NAS состоит в области обеспечения multipathing. В текущей версии ESX/ESXi, NFS требует ручного конфигурирования статических путей, в то время, как для iSCSI, FC, и FCoE доступны опции как ручного, так и автоматического multipathing (отметьте, что iSCSI требует ряда дополнительных опций конфигурации).

Multipathing и обеспечение ограничения доступа к датастору в виде экспортов NFS и механизмов LUN masking (для iSCSI FC, и FCoE) динамически устанавливаются, когда команда администраторов VMware занимается развертыванием и распределением пространства системы хранения. Подробности об этой процедуре можно найти в разделе 5, где рассматривается утилита RCU.

3.2 Основы сети хранения Fibre Channel

Сети хранения Fibre Channel составляют значительную часть крупных инфраструктур хранения VMware. Такая значительная доля рынка принадлежит FC прежде всего потому, что он стал первым протоколом сети хранения, поддерживаемым ESX в версии 2.0. Кроме того, FC широкоизвестная и зрелая технология, данный раздел рассматривает практики и рекомендации по развертыванию и использованию VMware с Fibre Channel на системах хранения NetApp.

Основы сетевого подключения

И сервера ESX, и системы хранения NetApp подключаются к фабрике SAN с помощью так называемых host bus adapter (HBA). Подключение к фабрике FCoE осуществляется с помощью converged network adapter (CNA). Каждый HBA/CNA может работать или как initiator (ESX/ESXi) или как target (NetApp). Каждый адаптер имеет глобально уникальный идентификатор, который называется World Wide Name (WWN). Необходимо знать каждый участвующий в соединении WWN, для того, чтобы сконфигурировать доступ к LUN на системе хранения NetApp.

Как NetApp, так и VMware настоятельно рекомендуют использовать для подключения каждого хоста ESX/ESXi по меньшей мере два порта адаптеров. Для подробностей о рекомендациях VMware по FC смотрите VMware Fibre Channel SAN Configuration Guide.

3.3 Основы сети хранения с использованием Ethernet

10GBE или Data Center Ethernet (DCE)

NetApp Data ONTAP и VMware ESX/ESXi 4, оба поддерживают 10GbE. Преимуществом 10GbE является возможность снизить количество сетевых портов инфраструктуры, в особенности, хотя и не только, для blade-серверов. Для проверки совместимости с вашим оборудованием смотрите ESX I/O compatibility guide.

VLAN Tagging или 802.1Q

Если вы сегментируете сетевой трафик с помощью VLAN, интерфейсы могут быть или выделены под отдельный VLAN или поддерживать на них несколько VLAN-ов с помощью технологии VLAN tagging.

Для систем, которые имеют небольшое количество сетевых интерфейсов, таких как, например, blade-сервера, использование VLAN-ов может быть очень полезным. Соединение в channel двух сетевых интерфейсов обеспечивает серверу ESX избыточность физических линков. Путем добавления нескольких VLAN-ов, вы можете сгруппировать общий IP-трафик по отдельным VLAN-ам для оптимальной производительности. Рекомендуется сделать так, чтобы доступ к сервис-консоли с сетью виртуальных машин находился в одной VLAN, а трафик VMkernel в IP-сети хранения и VMotion располагались в другой VLAN.

VLAN-ы и VLAN tagging играют простую, но важную роль в обеспечении безопасности IP-сети хранения.

Экспорты NFS могут быть ограничены диапазоном IP-адресов, доступных только в IP storage VLAN. Система хранения NetApp также позволяет определить ограничения доступа для протокола iSCSI на определенные интерфейсы и/или теги VLAN. Эти простые конфигурационные настройки имеют исключительный эффект для обеспечения безопасности и доступности датасторов, используемых по IP-сети. Если вы используете несколько VLAN-ов по одному интерфейсу, убедитесь, что имеете достаточный запас по пропускной способности для всего запланированного трафика.

Flow Control

Flow control это процесс управления скоростью передачи данных между двумя узлами, для предотвращения того, что более быстрый передающий переполнит передаваемыми данными порт и буфера принимающего. Flow control может быть сконфигурирован на серверах ESX/ESXi, системах хранения FAS, и сетевых коммутаторах. Рекомендуется сконфигурировать «конечные точки» трафика, то есть сервера ESX и системы хранения NetApp, с установками «send on» и «receive off».

После того, как эти настройки будут установлены на контроллере системы хранения и портах коммутаторов, вы получите желаемую конфигурацию без модификации настроек flow control в ESX/ESXi. Для подробностей по установке flow control в vSphere, смотрите VMware KB 1013413.

Для сетевых коммутаторов рекомендуется выставлять для портов, соединенных с хостами ESX и системами хранения FAS значение «Desired» или, если такой вариант отсутствует, ставить на этих портах значение «send off» и «receive on».

Внимание: Порты коммутатора конфигурируются со значениями, обратными установкам ESX/ESXi и FAS.

Рисунок 16) Конфигурирование настроек flow control.

Протокол Spanning Tree

Spanning Tree Protocol (STP) это сетевой протокол, который обеспечивает построение сетевой топологии без петель трафика. В модели OSI протокол STP лежит ниже OSI Layer-2. STP позволяет сетевой структуре иметь запасные избыточные соединения для обеспечения автоматических резервных путей данных, в случае, если основные пути будут неработоспособны, при этом без опасности возникновения bridge loops, или необходимости ручного включения/выключения таких резервных линков. Следует опасаться возникновения bridge loops, так как это ведет к появлению эффекта «сетевого потопа» (flood).

При подключении ESX и систем хранения NetApp к сети хранения Ethernet, настоятельно рекомендуется, чтобы порты Ethernet коммутатора, к которым эти системы подключаются, были сконфигурированы как RSTP edge ports или использовали функцию коммутаторов Cisco - portfast. Если ваша сетевая инфраструктура использует возможности Cisco portfast и вы можете использовать 802.1q VLAN trunking на сервере ESX или системе хранения NetApp, то рекомендуется использовать spanning-tree portfast trunk.

Когда порт сконфигурирован как edge port на поддерживающем RSTP коммутаторе, то такой edge port немедленно переключит свое состояние передачи в активное. Такой немедленный переход ранее был особенностью собственной возможности Cisco под названием portfast. Порты, которые подключены к другим портам коммутатора не должны конфигурироваться как edge port или иметь включенной функцию portfast.

Маршрутизация и IP-сеть хранения

Всегда, когда это возможно, NetApp рекомендует конфигурировать IP-сеть хранения как единую сеть, без маршрутизации. Такая схема поможет вам обеспечить необходимую производительность и безопасность.

Включение Jumbo Frames

Когда вы принимаете решение начать использовать jumbo frames в вашей сетевой инфраструктуре, следует помнить о том, что ваши сетевые устройства делятся на два основных типа. Одни устройства передают (и принимают) jumbo frames (это, например, системы хранения NetApp и сервера ESX), другие jumbo frames транспортируют (это коммутаторы Ethernet). Некоторые устройства, передающие и принимающие jumbo frames, конфигурируются на использование VLAN trunking, а некоторые - нет. Кадр Ethernet содержит «полезную нагрузку» в виде передаваемых данных, заголовок кадра, так называемый Ethernet header (18 байт), и иногда VLAN tag (4 байта, если используется VLAN). Устройства, передающие jumbo frames (системы хранения и сервера) обычно позволяют установить размер блока полезной нагрузки в кадре Ethernet (обычно это 9000 байт). Далее система дополняет этот размер заголовком фрейма и, если используется, тегом VLAN, при этом размер передаваемого кадра может варьироваться от 9018 до 9022 байт (с VLAN tagging). Из-за такого переменного возможного размера кадра, наилучшим решением будет установить на транспортирующем устройстве (коммутаторе Ethernet) размер поддерживаемого фрейма на максимальный возможный для этого устройства.

В современных коммутаторах, применяемых в датацентрах, максимальный размер обычно составляет 9216 байт. Если ваша коммутирующая инфраструктура не позволяет такой размер, то вы должны убедиться, что вы можете принять на стороне коммутатора кадр Ethernet размером «полезная нагрузка» фрейма, плюс заголовок (18 байт), плюс VLAN tag (4 байта), при необходимости пропорционально уменьшив размер «полезной нагрузки» кадра. Если сетевая инфраструктура не сконфигурирована правильно и не позволяет передать jumbo frame заданного размера, то это может привести к неправильной работе сети, проблемах в соединении и передаче данных, или сильному падению производительности.

Рисунок 17) Выбор размеров MTU при использовании jumbo frames.

Хосты ESX/ESXi требуют создания vSwitch и назначенного ему порта VMkernel, которые оба поддерживают jumbo frames.

Для включения jumbo frames на vSwitch, проделайте следующее:

1. Подключитесь к хосту ESX/ESXi (с помощью vSphere CLI).

2. Для конфигурирования выполните следующую команду:
vicfg-vswitch -m <MTU> <vSwitch>

Эта команда устанавливает размер MTU для всех аплинков на данном vSwitch. Установите размер MTU соответствующий наибольшему размеру MTU, среди используемых всеми виртуальными адаптерами, подключенными к этому vSwitch.

3. Для проверки конфигурации выполните следующую команду:
vicfg-vswitch -l

Для включения jumbo frames на порту VMkernel, выполните следующие шаги.

1. Подключитесь к хосту ESX/ESXi (с помощью vSphere CLI).

2. Для конфигурирования выполните следующую команду:
esxcfg-vmknic –a –I <ip address> -n <netmask> -m <MTU> <port group name>

Эта команда создаст порт VMkernel с поддержкой jumbo frame.

3. Для проверки конфигурации выполните следующую команду:
esxcfg-vmknic –l

Для установки размера MTU на системе хранения FAS, запустите NSM (NetApp System Manager), выберите для нужного дискового массива Configuration, Network и Interfaces, и выберите Edit. Смотрите рис. 18. Повторите для каждой системы хранения и каждого ее интерфейса, на котором нужно включить jumbo frames.

Рисунок 18) Конфигурирование jumbo frames в NetApp System Manager.

Отдельная сеть для задач хранения с использованием Ethernet

Как наилучшее решение NetApp рекомендует отделить трафик IP-сети хранения от общей публичной IP-сети с помощью создания отдельной физической сети, или же сегментирования в VLAN. Создание второй сети в ESX требует создания еще одного vSwitch для отделения трафика в отдельные физические NIC. Серверу ESX требуется также создать порт VMkernel к новому vSwitch.

Рекомендуемое VMware решение для кластеров HA определить каждому серверу ESX второй порт сервисной консоли (service console port).

При такой схеме NetApp рекомендует не позволять маршрутизацию данных между системой хранения или VMkernel и другими сетями. Иными словами, не указывайте default gateway для сети VMkernel storage network.

При использовании NFS требуется задать второй service console port на виртуальном коммутаторе VMkernel в каждом сервере ESX.

Соединение в IP-cети хранения, или VMkernel, можно проверить с помощью команды vmkping.

Для датастора подключенного по NFS, синтаксис тестовой команды будет:
vmkping <NFS IP address>.

NetApp Virtual Interfaces (EtherChannel)

«Виртуальные сетевые интерфейсы» (VIF), термин NetApp для обозначения EtherChannel, это механизм агрегирования сетевых интерфейсов в единый логический «метаинтерфейс». Будучи создан, VIF неотличим от обычного физического сетевого интерфейса. VIF-ы используются для обеспечения отказоустойчивости сетевого соединения и, в ряде случаев, для повышения пропускной способности, доступной системе хранения.

NetApp позволяет использовать два типа VIF с поддержкой балансировки нагрузки: статический «ручной» и динамический LACP (IEEE 802.3ad). NetApp также позволяет использовать active-passive вариант VIF, называемый single-mode VIF, не поддерживающий балансировку трафика. NetApp VIF могут быть также сгруппированы в двухслойную структуру путем объединения VIF-ов «первого уровня» в VIF «второго уровня».

Multimode VIF это статически сконфигурированный EtherChannel. В multimode VIF все физические интерфейсы, включенные в VIF, одновременно активны и могут переносить трафик. Этот режим требует, чтобы все интерфейсы были включены в коммутатор, который поддерживает агрегирование нескольких портов. Коммутатор следует настроить так, чтобы он понимал, что все порты соединения совместно используют один общий MAC-адрес и являются частями единого логического интерфейса. В случае отказа физического соединения одного из интерфейсов, VIF продолжает автоматически передавать данные по оставшимся соединениям без потери соединения.

LACP VIF это динамический (IEEE 802.3ad) EtherChannel. В LACP VIF все физические соединения одновременно активны и используются для передачи трафика, как и в случае обычного multimode VIF, который мы описали ранее.

LACP VIF использует передачу специальных сигналов между контроллером системы хранения и сетевым коммутатором. Такие сигналы уведомляют удаленного партнера по каналу о состоянии линков, и, если обнаружен отказ или иная невозможность передачи данных, устройство идентифицирует проблему, уведомляя о ней удаленного партнера, что позволяет безопасно вывести данный линк из состава EtherChannel. Эта возможность отличает LACP VIF от обычного, static multimode VIF, так как в последнем отсутствуют средства уведомления между партнерами по каналу. Единственным способом удалить интерфейс из standard multimode VIF будет обнаружение отсутствия физического соединения (link loss).

Multimode и LACP EtherChannels, оба используют одинаковые алгоритмы балансировки IP-трафика. Эти алгоритмы основаны на IP-адресах источника и получателя, адресах MAC, или номерах портов TCP/UDP^{^[†]}.

NetApp рекомендует использовать балансировку трафика основываясь на IP-адресах источника и получателя, и, в особенности, если сеть использует маршрутизацию трафика сети хранения, так как это работает на самом широком наборе конфигураций IP-сети хранения.

В single-mode VIF только одно физическое соединение активно в каждый момент времени. Если контроллер системы хранения определяет отказ активного соединения, активируется второе соединение, пребывавшее в standby. При использовании single-mode VIF не требуется конфигурирование на стороне коммутатора, так как физические интерфейсы, составляющие VIF, не работают одновременно. Отметьте, что балансировка трафика не работает на single-mode VIF.

3.4 Cisco Nexus 1000V VNetwork Distributed Switch

Cisco Nexus 1000V System VLAN

Когда вы развертываете 1000V vNetwork Distributed Switch (vDS), имейте ввиду, что он состоит из двух компонентов, так называемых Virtual Supervisor Module (VSM) и Virtual Ethernet Module (VEM).

VSM работает как виртуальная машина, и это «мозг» всех операций с 1000V. Если VSM откажет, трафик по-прежнему будет идти, но будут невозможны действия управления над vDS. VSM-ы должны быть установлены в пару active-passive. Эти два appliance не должны располагаться на одном физическом сервере ESX. Эта конфигурация должна быть настроена с помощью политик DRS.

VEM встроен во все хосты ESX/ESXi, и управляется с помощью VSM. Он должен присутствовать на каждом хосте в кластере, который входит в Cisco Nexus 1000V vDS.

Возможен вариант, когда VSM управляет соединением к датастору, на котором лежит сама VSM VM, при этом процесс файловера для VSM может не сработать. Чтобы избежать такой ситуации, NetApp и Cisco рекомендуют убедиться, что все порты service console и интерфейсы VMkernel (vswif и vmknic) расположены в «системной VLAN» (System VLAN). «Системная VLAN» определяется с помощью дополнительного параметра, устанавливаемого в профиле порта. Не конфигурируйте сеть самой VM как «системную VLAN»

Включение Jumbo Frames

Хотя Cisco Nexus 1000V vDS поддерживает использование jumbo frames, на нем нельзя включить jumbo frames на уже существующем интерфейсе VMkernel. Для использования jumbo frames на порту VMkernel, вы должны сначала создать традиционный vSwitch и порт VMkernel, включить на них поддержку jumbo frames, и затем импортировать эти порты в таком виде в 1000V vDS.

Для включения jumbo frames на vSwitch, выполните следующие шаги:

1. Сконфигурируйте vSwitch и порты VMkernel для поддержки jumbo frame (глава 3.3).

2. Соединитесь с хостом ESX/ESXi с помощью vCenter client.

3. Назначьте созданный ранее порт VMkernel с созданному vSwitch.

4. Мигрируйте vSwitch в 1000V vDS (см. Рис. 19).

Рисунок 19) Миграция виртуального адаптера с vSwitch в 1000V.

3.5 Возможности IP-коммутации, определяющие архитектуру сети хранения

Дизайн инфраструктуры хранения, который вы создаете, в значительно мере диктуется функциональными возможностями IP-коммутаторов. Идеальным случаем было бы использовать коммутаторы Ethernet с поддержкой так называемой multiswitch link aggregation (MSLA). Если у вас имеется коммутатор с такими возможностями, например Cisco Nexus (virtual port channels), Cisco Catalyst 3750 series (cross-stack EtherChannel), или Cisco Catalyst 6500 series с модулями VSS 1440 (multichassis EtherChannel), то дизайн и архитектура вашей сети станут значительно проще.

Смотрите далее главу 3.6 для указаний по конфигурированию этого типа коммутации.

Рисунок 20) Коммутация с использованием multiswitch link aggregation.

Если же ваша сеть использует более традиционные коммутаторы, не использующие multiswitch link aggregation, вам потребуется выполнить ряд дополнительных шагов по конфигурации на ESX/ESXi, Data ONTAP, в конфигурациях коммутаторов.

Рисунок 21) Традиционная IP-коммутация.

Смотрите далее главу 3.7 для указаний по конфигурированию этого типа коммутации.

3.6 Сеть хранения с использованием Multiswitch Link Aggregation

В этой конфигурации IP-коммутатор сети хранения использует multiswitch link aggregation. В таком варианте каждый контроллер системы хранения требует одно физическое соединение к каждому коммутатору; два порта, подключенные к каждому контроллеру объединяются в один multimode LACP VIF с включенной балансировкой по IP. Такая схема позволяет обеспечить несколько активных линков к каждому контроллеру, при этом возможно масштабирование полосы пропускания путем добавления дополнительных линков, и каждый контроллер использует два физических линка для каждого активного сетевого соединения, что дает высокую доступность для пути передачи данных.

Преимущества MSLA

• Обеспечивает несколько активных соединений к каждому контроллеру.

• Легко масштабируется на большее число соединений добавлением NIC и алиасов.

• Балансировка нагрузки автоматически задается политикой EtherChannel.

Рисунок 22) Multimode VIF с использованием multiswitch EtherChannel.

Балансировка нагрузки

Чтобы использовать для передачи данных в IP-сети хранения нескольких физических путей одновременно, требуется использовать EtherChannel и нескольких IP-адресов на стороне контроллера системы хранения. Использование такой схемы позволяет добиться балансировки доступа к датастору по всем имеющимся интерфейсам. Такая балансировка может быть автоматически настроена при создании датастора с помощь утилиты Rapid Cloning Utility (RCU).

Рисунок 23 показывает пример потоков трафика сети хранения при использовании нескольких серверов ESX и нескольких датасторов.

Рисунок 23) Соединение с датастором с помощью multiswitch EtherChannel.

Конфигурирование портов IP-сети хранения на NetApp

Если вы планируете использовать систему хранения, работающую по IP, например через NFS, или iSCSI, вам следует сконфигурировать несколько линков Ethernet для их совместной работы в виде EtherChannel. EtherChannel обеспечивает агрегированную полосу пропускания и доступность линков от сетевого коммутатора до контроллера системы хранения. Рекомендуется использовать такую схему, поскольку контроллер системы хранения обрабатывает агрегированный поток ввода-вывода с узлов ESX/ESXI.

NetApp поддерживает все режимы EtherChannel, которые совместимы с 802.3ad LACP, и/или static EtherChannel. В Data ONTAP EtherChannel традиционно для NetApp носит название virtual interfaces (VIF). NetApp рекомендует конфигурировать ваш EtherChannel или VIF как LACP VIF, когда это возможно.

Для использования коммутаторов с multiswitch link aggregation, вам следует создать multilink EtherChannel или VIF, сконфигурированный с несколькими IP-адресами. Число IP-адресов должно быть примерно равно числу vmnics, используемых для трафика ввода-вывода сети хранения хостов ESX/ESXi. Этот процесс можно выполнить через NSM.

Рисунок 24) Создание порта LACP EtherChannel с двумя физическими NIC на первом контроллере.

Внимание: Существует один неочевидный момент в первой половине создания EtherChannel на кластерной системе хранения; При назначении партнерского интерфейса вам придется выбрать для него обычный физический NIC. Причина этому в том, что на втором контроллере в этот момент еще не сконфигурирован EtherChannel. После того, как на втором контроллере также будет сконфигурирован EtherChannel, вам следует вернуться на первый контроллер и отредактировать партнерский интерфейс, чтобы он указывал на EtherChannel, созданный на втором контроллере.

Рисунок 25) Завершение процесса создания порта LACP EtherChannel из двух физических NIC на первом контроллере.

Рисунок 26) Выполнение процесса создания порта LACP EtherChannel из двух физических интерфейсов на втором контроллере хранения. Отметьте, что EtherChannel на первом контроллере доступен для выбора как партнерский интерфейс.

Рисунок 27) Выполнение процесса создания порта LACP EtherChannel. На первом контроллере, партнерский интерфейс установлен на EtherChannel, сконфигурированный на втором контроллере. Дополнительные IP-адреса могут быть добавлены редактированием EtherChannel.

Конфигурирование портов VMkernel в ESX/ESXi для сети хранения

Если коммутатор, используемый для построения IP-сети хранения, поддерживает multiswitch EtherChannel trunking или virtual port channeling, тогда каждому серверу ESX необходимо одно физическое соединение к каждому из коммутаторов в стеке, с включенной балансировкой трафика. Требуется один порт VMkernel с одним IP-адресом. При организации нескольких физических соединений до контроллера системы хранения к датастору, для того, чтобы было возможно использовать для передачи данных все имеющиеся физические пути, необходимо использовать для доступа к этим данным в датасторе различные целевые IP-адреса (target IP).

Преимущества

• Прост.

• Обеспечивает два активных соединения к каждому контроллеру хранения.

• Легко масштабируется увеличением соединений.

• Соединение контроллера системы хранения автоматически управляется с помощью политики балансировки нагрузки по IP.

• Требуется только один порт VMkernel для IP-хранилища, чтобы использовать множественные физические пути.

В конфигурации сервера ESX, показанной на рис. 28, виртуальный коммутатор vSwitch (названный vSwitch1) создан специально для подключения IP-сети хранения. Два физических адаптера сконфигурированы для этого vSwitch (в данном случае они называются vmnic1 и vmnic2). Каждый из этих адаптеров соединен с отдельным физическим коммутатором, и порты коммутаторов сконфигурированы в cross-stack EtherChannel trunk.

Внимание: В настоящий момент VMware не поддерживает LACP, или IEEE 802.3ad, которые отвечают за динамическое распознавание транков Ethernet.

Рисунок 28) Соединения физических NIC сервера ESX с multiswitch EtherChannel.

В vSwitch1 создан один порт VMkernel (VMkernel 1) и сконфигурирован с одним IP-адресом, а свойства «тиминга» (teaming) для NIC этого порта VMkernel сконфигурированы так:

• VMkernel 1: IP-адрес установлен в 192.168.1.101.

• VMkernel 1 свойства порта: политика Load-balancing установлена «Route based on IP hash».

Рисунок 29) Свойства порта VMkernel сервера ESX с multiswitch EtherChannel.

3.7 Сеть хранения с использованием традиционных Ethernet-коммутаторов

В этой конфигурации используемый коммутатор IP не поддерживает multiswitch link aggregation, поэтому каждый контроллер системы хранения потребует четыре физических сетевых соединения. Этот вариант обеспечивает несколько активных физических соединения к каждому контроллеру системы хранения, при этом возможно масштабирование полосы пропускания сети передачи данных путем простого добавления дополнительных физических соединений. Однако это требует использования нескольких IP-адресов на контроллере, и каждый из них использует два физических линка для каждого активного сетевого соединения, чтобы обеспечить высокую доступность путей передачи данных.

Single Mode

Схема, называемая single-mode требует, чтобы каждая пара сетевых линков была сконфигурирована как single-mode (active-passive) EtherChannel или VIF. Каждый VIF имеет подключение к обоим коммутаторам и использует один IP-адрес, назначенный ему, обеспечивая два IP-адреса на каждом контроллере. Команда vif favor используется для того, чтобы принудительно задать использование каждым VIF определенного коммутатора для активного интерфейса. Эта схема является предпочтительной, поскольку проста в реализации и не требует каких-либо специальных возможностей или особой конфигурации от сетевых коммутаторов.

Преимущества использования Single Mode EtherChannel

• Простота: Не нужно конфигурирование на стороне коммутаторов.

• Доступ с ESX/ESXi к датастору не требует multiswitch hop.

Недостатки использования Single Mode EtherChannel

Трафик ввода-вывода на один IP не агрегируется по нескольким линкам.

Рисунок 30) Single-mode VIF со стороны системы хранения.

«Двухслойный» дизайн использования режима multimode

Для пользователей, предпочитающих использовать «двухслойный» дизайн сетевой архитектуры, мы включили сетевую диаграмму его построения в приложения к этому документу^{^[‡]}.

Балансировка нагрузки системы хранения

Чтобы использовать для передачи данных в IP-сети хранения нескольких физических путей одновременно, требуется использовать EtherChannel и нескольких IP-адресов на стороне контроллера системы хранения, и несколько портов VMkernel для трафика ввода-вывода хостов ESX/ESXi. Такая модель позволяет организовать сбалансированные соединения с датастором, с использованием всех используемых интерфейсов. При создании датастора с помощью Rapid Cloning Utility (RCU), такая балансировка создается и настраивается автоматически.

Несколько портов VMkernel

Использование нескольких портов VMkernel впервые было предложено NetApp в качестве стандартного решения, и в дальнейшем также поддержано и используется производителями других систем хранения, предлагающих мультипротокольный доступ. NetApp рекомендует определять отдельные VMkernel для каждого протокола хранения. Сделав так, вы получите очень простую конфигурацию с iSCSI и NFS. Каждый из этих портов VMkernel обеспечивает трафик IP в отдельную подсеть. Использование схемы адресации с использованием разных подсетей для iSCSI и NFS обеспечивает ряд преимуществ в управлении тем, какой из портов VMkernel используется для передачи какого из протоколов. В качестве примера смотрите рисунок 31. Так как два порта VMkernel находятся в одном vSwitch, он могут совместно использовать vmnics в этом vSwitch.

Для датасторов NFS, каждый порт VMkernel конфигурируется с одним активным vmnic, и с одним или более vmnic в standby. Это позволяет администратору управлять тем, какой vmnic используется для трафика каким из портов VMkernel.

Рисунок 31) Несколько портов VMkernel для iSCSI и NFS.

Рисунок 32 показывает пример потоков трафика сети хранения при использовании нескольких серверов ESX и нескольких датасторов.

Рисунок 32) Соединение с датастором по традиционному EtherChannel.

Поведение при отказе адаптера сервера ESX при использовании iSCSI

В случае отказа сетевого адаптера сервера ESX (из за обрыва кабеля или неисправности NIC), трафик, изначально идущий через сбойный компонент, перенаправляется через второй адаптер. Файловер происходит и управляется через собственные средства multipathing VMware, поэтому нет нужды обеспечивать файловер средствами коммутатора или VMkernel. Трафик возвращается на исходный адаптер, когда его работоспособность восстановлена.

Поведение при отказе адаптера сервера ESX при использовании NFS

В случае отказа сетевого адаптера сервера ESX (из-за обрыва кабеля или неисправности NIC), трафик, изначально идущий через сбойный компонент, перенаправляется через второй адаптер, но в той же подсети, что была изначально. Обе подсети активны на продолжающем работать адаптере. Трафик возвращается на исходный адаптер, когда его работоспособность восстановлена. В таком сценарии EtherChannel обеспечивает сетевой файловер.

Отказ коммутатора

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

Рисунок 33) Нормальная работа ESX vSwitch1.

Рисунок 34) Работа ESX vSwitch в случае отказа.

Конфигурирование портов IP-сети хранения на NetApp

Если вы планируете использовать систему хранения, работающую по IP, например через NFS, или iSCSI,вам следует сконфигурировать несколько линков Ethernet для совместной работы в виде EtherChannel. EtherChannel обеспечивает агрегированную полосу пропускания и доступность линков от сетевого коммутатора до контроллера системы хранения. Рекомендуется использовать такую схему, поскольку контроллер системы хранения обрабатывает агрегированный поток ввода-вывода с узлов ESX/ESXI.

NetApp поддерживает все режимы EtherChannel, которые совместимы с 802.3ad LACP, и/или static EtherChannel. В Data ONTAP EtherChannel традиционно для NetApp называется virtual interfaces (VIF). NetApp рекомендует конфигурировать ваш EtherChannel или VIFs как single mode при использовании с традиционными коммутаторами, так как это наиболее простая сетевая архитектура.

Для использования в традиционной конфигурации коммутаторов, вам следует создать single-mode EtherChannel или VIF, сконфигурированный с одним IP-адресом. Этот процесс можно выполнить через NSM.

Рисунок 35) Создание порта LACP EtherChannel из двух физических NIC а первом контроллере.

Рисунок 36) Выполнение процесса создания порта single-mode EtherChannel из двух физических NIC на первом контроллере системы хранения.

Рисунок 37) Выполнение процесса создания порта single-mode EtherChannel из двух физических интерфейсов на втором контроллере хранения. Отметьте, что EtherChannel на первом контроллере доступен для выбора как партнерский интерфейс.

Рисунок 38) Выполнение процесса создания порта single-mode EtherChannel. На первом контроллере партнерский интерфейс указывает на EtherChannel, сконфигурированный на втором контроллере.

Конфигурирование портов VMkernel в ESX/ESXi для сети хранения

В случае использования традиционных коммутаторов для сети хранения, каждый хост ESX/ESXi должен быть сконфигурирован, по меньшей мере, с двумя портами VMkernel, смотрящими в различные подсети. Как и в случае ранее рассмотренного варианта, для множественных соединений с датастором через контроллер систем хранения необходимо использование различных целевых IP-адресов. Без добавления второго порта VMkernel, он (VMkernel) будет просто маршрутизировать все исходящие обращения через один и тот же физический интерфейс, без использования дополнительных vmnic на vSwitch. В этой конфигурации, каждый порт VMkernel имеет свой собственный адрес в разных подсетях. Система хранения в свою очередь также сконфигурирована с IP-адресами в каждой из этих подсетей, таким образом, возможно управление конкретными интерфейсами vmnic.

Преимущества

• Обеспечивает два активных соединения для каждого контроллера (но только один активный путь на датастор).

• Легко масштабируется для большего количества соединений.

• Балансировка трафика контроллера системы хранения осуществляется автоматически политикой балансировки виртуальных портов. Это решение не-EtherChannel.

Недостатки

• Требует конфигурацию из, как минимум, двух портов VMkernel.

В конфигурации хоста ESX/ESXi показанной на рис. 39, vSwitch (названный «vSwitch1») создан специально для соединения IP-сети хранения. Два физических адаптера сконфигурированы для этого vSwitch (в данном случае это vmnic1 и vmnic2). Каждый из этих адаптеров подключен в отдельный физический коммутатор.

Рисунок 39) Соединения физических NIC сервера ESX с традиционным Ethernet.

В vSwitch1, созданы два порта VMkernel (VMkernel 1 и VMkernel 2). Каждый порт VMkernel сконфигурирован с IP-адресом в отдельной подсети, и параметры NIC teaming каждого порта VMkernel сконфигурированы так, как указано ниже:

• VMkernel 1: IP-адрес установлен в 192.168.1.101.

• Свойства порта VMkernel 1:

− Enable the override vSwitch failover order option.

− Для NFS и iSCSI, установите активным адаптером vmnic1.

− Для NFS, установите standby-адаптером vmnic2.

− Для iSCSI, установите другой адаптер в unused.

• VMkernel 2: IP-адрес установлен в 192.168.2.101.

• Свойства порта VMkernel2:

− Enable the override vSwitch failover order option.

− Для NFS и iSCSI, установите активным адаптером vmnic2.

− Для NFS, установите standby-адаптером vmnic1.

− Для iSCSI, установите другой адаптер в unused.

Рисунок 40) Свойства порта VMkernel сервера ESX с традиционным Ethernet.

3.8 Включение поддержки Multiple TCP Sessions для iSCSI

В vSphere появилась возможность использовать так называемые multiple TCP sessions в iSCSI. Эта возможность позволяет «карусельную» балансировку (типа round robin) с использованием VMware native multipathing и требует определения порта VMkernel для каждого vmnic назначенного на использование под трафик iSCSI.

В случае подключенных по iSCSI датасторов, каждый порт VMkernel конфигурируется с только одним vmnic. Использование standby vmnics для VMkernel невозможно.

Внимание: Конфигурирование порта VMkernel для iSCSI, как это описано в данной главе, приведет к тому, что данный порт VMkernel будет сконфигурирован без использования NIC teaming, и, следовательно, не будет иметь избыточности на сетевом уровне. В этой конфигурации избыточность для iSCSI обеспечивается средствами native multipathing в ESX/ESXi. В этом случае избыточность и отказоустойчивость iSCSI осуществляется тем же способом, что и в случае FC. Включение multiple TCP session support для iSCSI на хосте ESX/ESXi, использующем также и NFS, не поддерживается, и использовать его не следует, так как это может приводить к тому, что монтирование NFS может быть осуществлено через порт iSCSI VMkernel, не имеющий избыточности сетевого уровня.

NetApp рекомендует, в тех случаях, когда необходимо параллельное использование и iSCSI, и NFS, для обеспечения избыточности путей подключения положиться на уровень TCP с помощью NIC teaming, как это описано в предыдущей главе.

Рисунок 41) Отображение нескольких портов VMkernel для iSCSI с поддержкой multiple TCP sessions.

Внимание: ESX/ESXi 4 поддерживают максимально четыре порта iSCSI на хост.

Создание нескольких iSCSI VMKernels для поддержки Multiple TCP Sessions в iSCSI

1. Откройте vCenter Server.

2. Выберите хост ESX.

3. В правой панели выберите закладку Configuration.

4. В Hardware, выберите Networking.

5. В верхнем правом углу, щелкните Add Networking чтобы запустить мастер Add Network.

6. Выберите радиокнопку VMkernel и нажмите Next.

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

7. Сконфигурируйте интерфейс VMkernel, указав необходимую информацию о сети. Значение default gateway не требуется для сети VMkernel IP storage network.

8. Каждый интерфейс VMkernel должен быть сконфигурирован на использование одного активного адаптера, не используемого ни одним другим iSCSI VMkernel. Также VMkernel не должен иметь ни одного standby-адаптера. См. рис. 42 и 43.

Необходимо привязать программный iSCSI daemon к каждому интерфейсу VMkernel. Эти шаги делаются с использованием CLI.

9. Подключитесь к консоли ESX или ESXi и запустите следующее:
esxcli swiscsi nic add –n <VMkernel ID> -d <Virtual HBA ID>
Как пример:
esxcli swiscsi nic add -n vmk0 -d vmhba33
esxcli swiscsi nic add -n vmk1 -d vmhba33

10. Проверьте привязку iSCSI-to-VMkernel. Подключитесь к консоли ESX или ESXi и выполните следующие команды:
esxcli swiscsi nic list -d <Virtual HBA ID>
Как пример:
esxcli swiscsi nic list -d vmhba33

Смотрите рис. 44.

Рисунок 42) iSCSI VMkernel 0: Отметьте активный адаптер vmnic0.

Рисунок 43) iSCSI VMkernel 1: Отметьте активный адаптер vmnic1.

Рисунок 44) Привязка (binding) iSCSI к VMkernel для использования multiple TCP sessions.

4 Планирование и настройка системы хранения

Администраторам системы хранения

Администраторам Virtual Infrastructure

4.1 Новая процедурная модель: Распределение из пула ресурсов

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

Рисунок 45) Что можно сделать с помощью NetApp vCenter plug-in.

В этой новой модели, администратор системы хранения отвечает за конфигурирование физической системы хранения, организацию защиты данных и путей доступа. Когда физическая система хранения установлена и настроена, администратор системы хранения просто выделяет пул ресурсов хранения (aggregates, томов FlexVol и сетевых интерфейсов) для использования их виртуальной инфраструктурой и ее администраторами.

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

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

Тем не менее, мы рекомендуем новую модель использования, так как она дает значительные преимущества в работе команды администраторов как VMware, так и NetApp, упрощает их работу, повышает эффективность использования ресурсов и более логично распределяет области ответственности.

Плагины NetApp для VCenter

Плагины NetApp для vCenter, такие как Virtual Storage Console (VSC) и Rapid Cloning Utility (RCU), были объединены в единый «плагинный фреймворк» с выходом VSC версии 2.0. Вдобавок к этому, VSC 2.0 включает в себя доступ ко всем возможностям NetApp SnapManager for Virtual Infrastructure (SMVI), непосредственно из клиентского интерфейса vSphere.

VSC устанавливает настройки конфигурации на рекомендованные для хостов ESX/ESXi значения. Кроме этого, VSC 2.0 обеспечивает динамическое распределение ресурсов общего пула ресурсов хранения в виде датасторов, силами администраторов VMware. Такая схема распределения пространства позволяет также назначать выделяемым ресурсам рекомендованные NetApp настройки и параметры, обеспечивающие максимальную доступность, производительность, управление доступом и путями передачи данных.

4.2 Концепции архитектуры хранения

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

1. Отделите сеть управления системой хранения от сети ввода-вывода данных. Эта концепция применима ко всем протоколам хранения, но особенно важна для Ethernet-решений (NFS, iSCSI, FCoE). Такое разделение может быть физическим (подсети) или логическим (VLAN), но оно должно быть.

2. Если вы настраиваете протокол, использующий IP (NFS или iSCSI), вам может потребоваться более чем один IP в качестве адреса на стороне системы хранения. Конкретнее это зависит от возможностей и особенностей вашего сетевого оборудования.

3. При использовании IP в качестве протокола (NFS или iSCSI) вы можете использовать один или несколько «каналов» (EtherChannel), объединяя порты Ethernet вместе. NetApp называет этот функционал VIF (часто он же неправильно называется «транк»). Рекомендуется, когда это возможно, создавать и использовать LACP VIF-ы в режиме multimode.

4.3 Из чего состоит система хранения NetApp

Побочным результатом любой консолидации является растущий риск отказа всей платформы консолидации целиком. Поскольку физические сервера преобразованы в виртуальные машины и множество их работают поверх одной физической платформы, то влияние отказа этой физической платформы могут быть поистине катастрофическими. К счастью, VMware обеспечивает множество технологий, которые служат повышению доступности виртуального датацентра. Сюда входят технологии улучшенной доступности VM, балансировка нагрузки с помощью VMware HA и кластера DRS, обеспечения целостности и непрерывности работы приложений VMware Fault Tolerance, и возможности непрерывающей миграции работающей VM, а также ее данных, между физическими серверами ESX с использованием VMotion и storage VMotion, соответственно.

Сосредоточившись на доступности хранилища, мы увидим много доступных для использования уровней избыточности, включая возможность покупки и использования физических серверов с несколькими каналами подключения системы хранения или HBA, использование резервных путей подключения, и использование системы хранения с избыточными контроллерами. Схема построения хранилища данных, которая удовлетворяет всем этим критериям, позволяет создать систему без «единой точки отказа».

Защита данных и RAID-DP

Действительность такова, что требования по защите данных для виртуальной инфраструктуры выше, чем для традиционной, физической серверной инфраструктуры. Защита данных исключительно важна для совместно используемого хранилища, когда потеря данных может привести к недоступности множества серверов разом. NetApp RAID-DP® это технология RAID, использующаяся по умолчанию на всех системах NetApp FAS. RAID-DP защищает данные от одновременного выхода из строя двух дисков в одной RAID-группе. Использование RAID-DP также весьма экономно; RAID-оверхед на группе стандартного размера составляет всего 12.5%.

Такой уровень устойчивости к сбоям и эффективности хранения делает размещение данных на RAID-DP безопаснее, чем на RAID 5 и более эффективным с точки зрения пространства хранения, чем RAID 10. NetApp рекомендует использовать RAID-DP для всех групп RAID, используемых для хранения данных VMware.

Рисунок 46) NetApp RAID-DP.

Aggregates

Так называемый aggregate это «слой виртуализации» в системах хранения NetApp, который абстрагирует логическую структуру тома flexible volume от физических жестких дисков. Aggregate позволяет поместить физические диски в ресурсный пул так, чтобы суммарная производительность в IOPS, доступная томам на таком aggregate, равнялась сумме IOPS всех входящих в пул дисков. Такой механизм хорошо подходит для смешанной и плохо предсказуемой по характеру рабочей нагрузки.

Контроллер системы хранения NetApp хранит необходимые ему для работы файлы на так называемом root aggregate. В тех случаях, когда это возможно NetApp рекомендует вам выделять для него отдельный двухдисковый aggregate. По умолчанию root aggregate занимает три диска, так как использует RAID-DP. Чтобы снизить число дисков до двух, вам следует изменить настройки RAID type с RAID-DP на RAID-4. Отметьте, что этой рекомендации трудно следовать, если вы имеете небольшое количество дисков в системе в целом. В таком случае возможно лучшим вариантом будет не использовать под root volume выделенного root aggregate, совместив хранение тома root volume с прочими данными на общем aggregate.

Оставшееся пространство дисков следует разместить в минимальное количества максимально больших aggregates. Общий характер нагрузки ввода-вывода системы VMware традиционно произволен (random) по своей природе, потому такая модель дает оптимальную производительность, так как большое количество физических жестких дисков одновременно доступны для обслуживания операций ввода-вывода. На небольших системах FAS, может быть не слишком практично использовать более одного aggregate, вследствие ограниченного количества жестких дисков системы. В этом случае приемлемым вариантом будет использовать только один единственный aggregate.

Тома типа Flexible

Тома типа flexible несут на себе LUN-ы или файлы виртуальных дисков, с которыми работают сервера VMware ESX.

NetApp рекомендует при развертывании виртуальных серверов делать соответствие «один к одному» между датасторами VMware и flexible-томами NetApp. В случае виртуальных десктопов NetApp рекомендует делать соответствие «один к одному» между VMware desktop pools и flexible-томами NetApp.

Такая модель позволит вам легко понимать структуру данных VMware, когда вы будете рассматривать ее со стороны системы хранения. Такое соответствие позволит также легко использовать резервное копирование с помощью снэпшотов и использовать политики репликации SnapMirror для датасторов, так как NetApp реализует эти возможности на уровне томов flexible volume.

LUN

LUN-ы это SCSI-адресуемые единицы хранения (FC, iSCSI, и FCoE), которые подключены к кластеру ESX/ESXi, и используются как совместно доступные датасторы под VMFS или как устройства raw device mapping (RDM). Для подробностей смотрите VMware Storage/SAN Compatibility Guide for ESX/ESXi.

Правила именования

Системы хранения NetApp позволяют использовать «человекочитаемые» имена ресурсов. В хорошо спланированной виртуальной инфраструктуре, «самоописывющие» имена помогают идентификации и сопоставлению на многочисленных уровнях виртуализации, от системы хранения до виртуальной машины. Простой, эффективный и понятный свод правил именования также упрощает конфигурирование репликации и процессов disaster recovery и снижает вероятность ошибок администрирования.

NetApp рекомендует следовать таким правилам именования:

• Имя aggregate: Может быть любым именем по выбору администратора.

• Имя тома FlexVol: Должно соответствовать имени датастора.

• Имя LUN для VMFS: Должно соответствовать имени датастора.

• Имя LUN для RDM: Должно включать в себя как имя хоста, так и метку тома диска (volume label) или его имя.

4.4 Конфигурирование дискового массива NetApp

В этом разделе мы пройдем всеми шагами, необходимыми для конфигурирования и распределения пространства на дисковом массиве NetApp.

NetApp System Manager

NetApp разработала специальную программу NetApp Systems Manager (NSM) как удобное средство развертывания новых систем хранения, и управления инфаструктурами хранения NetApp среднего размера. Это еще один способ управления системами хранения под OS Data ONTAP, дополняющий традиционные методы через командну строку (CLI) и веб-интерфейс FilerView®, и далее, для больших инфраструктур, с помощью средства глобального управления и наблюдения NetApp Operations Manager.

Обнаружение в сети систем под управлением Data ONTAP

Скачайте NSM с сайта NOW™ и установите на сервер или виртуальную машину под Windows. Установите и подключите к локальной сети систему хранения NetApp. Вам потребуется соединить с сетью по крайней мере один порт Ethernet при выполнении сетевой установки, если вы хотите получить IP-адрес с помощью DHCP. Либо вы можете подключиться к системе через консольный последовательный кабель и выполнить начальную установку из командной строки, которая запускается при первом включении системы или по команде setup.

В обоих случаях вы можете включить NSM и запустить процедуру autodiscover для вашей системы хранения, ведением ее IP-адреса или же адреса подсети, в которой нужно провести поиск. Для подробностей об установке новой системы хранения с помощью NSM, смотрите NetApp Systems Manager Quick Start Guide.

Рисунок 47) Обнаружение дисковых контроллеров с помощью NetApp Systems Manager.

Конфигурирование интерфейсов сети хранения

Если вы планируете развернуть конфигурацию с использованием FC или FCoE, кроме включения собственно протокола на системе хранения не требуется дополнительных настроек. Утилита Rapid Cloning Utility (RCU) позволяет управлять всеми необходимыми процессами по созданию LUN, создания маскирования, и прочих действий.

Рисунок 48) Активация протокола в NetApp Systems Manager.

Если вы планируете развернуть конфигурацию с использованием IP-протоколов, например NFS, или iSCSI, рекомендуется сконфигурировать несколько линков Ethernet для работы вместе как EtherChannel. То, сколько сетевых портов следует сконфигурировать для EtherChannel, зависит от возможностей ваших сетевых коммутаторов. Детальное рассмотрение темы, возможных вариантов и процедур конфигурирования портов, приведено в разделе 3.

Мониторинг хранилища с помощью NetApp System Manager

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

Когда вы используете технологии экономии пространства, такие как thin provisioning и дедупликацию, очень важно наблюдать за наличием свободного пространства на aggregate. Своевременное уведомление о наличии, изменениях или исчерпании свободного места позволяет администратору вовремя реагировать и добавлять диски прежде, чем aggregate заполнится целиком.

NetApp рекомендует устанавливать уведомления на e-mail и пейджер ответственного администратора, а также организовать мониторинг по SNMP. Все это можно сконфигурировать в NSM.

Рисунок 49) Установка мониторинга в NetApp Systems Manager.

Мониторинг хранилища с помощью NetApp Operations Manager

NetApp Operations Manager наблюдает, управляет, и создает отчеты по всем системам NetApp FAS в организации, размером от среднего до большого. Когда вы используете NetApp thin provisioning, то NetApp рекомендует развернуть Operations Manager и установить уведомления по e-mail и на пейджер для соответствующих администраторов. Используя хранилище в thin-provisioned, очень важно своевременно мониторить доступное свободное пространство на aggregates. Своевременное уведомление о доступном пространстве означает, что дополнительное место будет добавлено прежде, чем aggregate полностью заполнится. Для подробного описания процедур установки уведомлений смотрите DataFabric Manager Server: Operations Manager Administration Guide.

4.5 Создание специальной учетной записи для VSC 2.0

Хотя вы можете использовать обычную учетную запись root на NetApp, в качестве служебной учетной записи VSC, это не рекомендуется. В этой главе мы рассмотрим то, как создать специальную ограниченную учетную запись в Data ONTAP для использования в качестве service account для VSC. Этой учетной записи будут даны только необходимые ей для работы права, чтобы обеспечить функциональность VSC 2.0, ограничение прав будет сделано через средства role-based access controls (RBAC) системы хранения.

Отметьте, что эта глава описывает только права RBAC во фреймворке VSC 2.0.

Конфигурирование на стороне массива

Для использования RBAC (Role-Based Access Control) следует создать новую учетную запись пользователя, группу и роль, и назначить эту роль группе, в которой будет находиться учетная запись такого ограниченного в правах пользователя. Выполните приведенные шаги в командной строке Data ONTAP (подключитесь через SSH, консольное соединение или telnet).

Внимание: Копирование команд путем «copy-paste» из данного документа может приводить к ошибочному результату, так как при этом могут быть скопированы нужные символы переноса строки, разделяющие часть команд. Такие символы приведут к ошибке в выполнении команды. Рекомендуется предварительно скопировать и вставить приведенные команды в простой текстовый редактор для проверки и удаления лишних переносов строки перед вводом их в консоль NetApp CLI.

Шаг 1: Создание роли, определяющей права, необходимые для работы VSC Core Features

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

useradmin role add "role_name" -a login-http-admin,api-aggr-list-info,api-cf-get-partner,api-cf-status,api-disk-list-info,api-ems-autosupport-log,api-fcp-adapter-list-info,api-fcp-get-cfmode,api-license-list-info,api-lun-get-vdisk-attributes,api-lun-list-info,api-lun-map-list-info,api-nfs-exportfs-list-rules,api-qtree-list,api-snmp-get,api-snmp-get-next,api-system-get-info,api-system-get-version,api-volume-autosize-get,api-volume-list-info,api-volume-options-list-info

Рисунок 50) Создание роли для VSC core feature service account.

Шаг 2: Создание группы пользователей и назначение роли этой группе

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

useradmin group add "group_name" -r "role_name"

Рисунок 51) Создание группы для учетной записи VSC core feature service account.

Шаг 3: Создание в группе учетной записи пользователя, использующей VSC

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

useradmin user add "user_name" -g "group_name"

Внимание: Будет запрошен пароль для учетной записи.

Рисунок 52) Создание пользователя для VSC core feature service account.

Шаг 4: Проверка сделанной работы

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

useradmin user list "user_name"

Информация, показываемая для пользователя и группы должна соответствовать введенной на предыдущих трех шагах.

Рисунок 53) Проверка созданного VSC core feature service account.

Используйте в дальнейшем именно этот ограниченный service account при установке VSC.

4.6 Настройка управления для Provisioning and Cloning в VSC 2.0

Возможность распределения ресурсов хранения руками членов команды админов виртуальной инфраструктуры резко увеличивает эффективность администрирования и ускоряет процессы выделения пространства, упрощает таковые процедуры в виртуальном датацентре. Эта модель позволяет ограничить функциональность Rapid Cloning Utility одной из четырех ролей.

На сегодня эти роли и присущие им права назначаются глобально, всем администраторам в vCenter. Будущее обновление позволит назначать роли индивидуально отдельным пользователям и группам vCenter.

Доступные роли

Модуль Provisioning and Cloning в VSC 2.0 позволяет администратору системы хранения делегировать некоторые свои возможности администратору виртуальной инфраструктуры путем создания одной из четырех ролей, показанных на рисунке 54. Каждая из ролей базируется на функциональности нижележащих ролей. Чем больше прав дано в RBAC для администратора виртуальной инфраструктуры, тем большая функциональность доступна в VSC.

Destroy Datastores: Отключение и удаление

Modify Datastores: Изменение размера и дедупликация

Create Datastores: Распределение на SAN и NAS

Create Clones: Создание клонированных VM

Рисунок 54) Четыре роли для распределения пространства и клонирования в VSC.

Эти роли подключаются при создании специальной учетной записи на системе хранения, используемой для работы интерфейса Provisioning and Cloning. Эта учетная запись может быть в любое время изменена на стороне системы хранения, и сделанные изменения станут доступны в vCenter. Это позволяет администраторам системы хранения сохранять права root над системой хранения, позволяя вместе с тем команде администраторов VMware управлять выделенным им пулом ресурсов хранения.

О том, как использовать эти учетные записи в VSC, смотрите главу 5.3.

Для создания такой учетной записи выполните следующие шаги:

Шаг 1: Создание роли для распределения пространства хранения и клонирования

В этом разделе мы рассмотрим создание базовой роли для создания клонов. Эта роль является базовой ролью, требуемой VSC для функциональности Provisioning and Cloning. Эта роль создается на системе хранения и необходима для использования функциональности «верхнего уровня» в VSC. Введите приведенную ниже команду на каждом из контроллеров системы хранения. Для примеров создания роли смотрите главу 4.5.

useradmin role add create_clones -a login-http-admin,api-system-get-version,api-system-get-info,api-system-cli,api-license-list-info,cli-ifconfig,api-aggr-list-info,api-volume-list-info,api-lun-list-info,api-lun-map-list-info,api-igroup-list-info,api-ems-autosupport-log,api-file-get-file-info,api-clone-*,api-file-create-directory,api-file-read-file,api-file-delete-file,api-file-write-file,cli-mv,api-file-delete-directory,cli-ndmpd,cli-ndmpcopy,api-useradmin-user-list,api-cf-status,api-snapshot-list-info,api-volume-autosize-get,api-iscsi-session-list-info,api-iscsi-portal-list-info,api-fcp-service-status,api-iscsi-service-status,cli-df,api-snapmirror-get-volume-status,api-quota-report,api-qtree-list,api-system-api-list,api-vfiler-list-info

Шаг 2: Добавление опциональных ролей

Здесь мы создадим три дополнительные роли на системе хранения, а затем назначим их учетной записи для операций распределения пространства (provisioning) и клонирования (cloning), используемой VSC для этих действий. Введите приведенную ниже команду на каждом из контроллеров системы хранения Для примеров создания роли смотрите главу 4.5.

useradmin role add create_datastores -a api-volume-create,api-volume-set-option,api-volume-autosize-set,api-sis-enable,api-sis-start,api-snapshot-create,api-snapshot-set-reserve,api-volume-clone-create,api-nfs-exportfs-list-rules-2,api-nfs-exportfs-modify-rule-2,api-nfs-exportfs-load-exports,api-igroup-create,api-lun-create-by-size,api-lun-map,api-lun-set-comment,api-igroup-add,cli-qtree,cli-iscsi

useradmin role add modify_datastores -a api-volume-create,api-volume-set-option,api-volume-autosize-set,api-sis-enable,api-sis-start,api-snapshot-create,api-snapshot-set-reserve,api-volume-clone-create,api-nfs-exportfs-list-rules-2,api-nfs-exportfs-modify-rule-2,api-nfs-exportfs-load-exports,api-igroup-create,api-lun-create-by-size,api-lun-map,api-lun-set-comment,api-igroup-add,cli-qtree,cli-iscsi ,api-volume-size,api-sis-disable,api-sis-stop,api-lun-resize

useradmin role add destroy_datastores -a api-volume-create,api-volume-set-option,api-volume-autosize-set,api-sis-enable,api-sis-start,api-snapshot-create,api-snapshot-set-reserve,api-volume-clone-create,api-nfs-exportfs-list-rules-2,api-nfs-exportfs-modify-rule-2,api-nfs-exportfs-load-exports,api-igroup-create,api-lun-create-by-size,api-lun-map,api-lun-set-comment,api-igroup-add,cli-qtree,cli-iscsi,api-volume-size,api-sis-disable,api-sis-stop,api-lun-resize,api-volume-offline,api-volume-destroy,api-lun-offline,api-lun-destroy

Шаг 3: Создание группы и назначение ей ролей для Provisioning и Cloning

useradmin group add "group_name" -r "role1_name" "role2_name"

Не забудьте добавить необходимые роли create_clones и другие опциональные роли. Для примера создания групп смотрите главу 4.5.

Шаг 4: Создание пользовательской учетной записи в группе

useradmin user add "user_name" -g "group_name"

Внимание: Будет запрошен пароль для учетной записи.

Шаг 5: Проверка сделанной работы

useradmin user list "user_name"

Информация, показываемая для пользователя и группы должна соответствовать введенной на предыдущих шагах.

Используйте в дальнейшем именно этот ограниченную в правах учетную запись, когда будете добавлять данную систему хранения в Provisioning and Cloning в VSC 2.0.

5 Динамическое распределение и управление в vSphere

Администраторам системы хранения

Администраторам Virtual Infrastructure

Администраторам локальной сети

5.1 Управление хранилищем с помощью средств vCenter

Как рассматривалось ранее (см. рис. 45), с выпуском vSphere, NetApp представил новую модель управления системой хранения, которая позволяет команде администраторов виртуальной инфраструктуры непосредственно создавать и манипулировать датасторами и виртуальными машинами поверх пула хранения, предоставляемого им администратором NetApp. Данная функциональность предоставляется средством Provisioning and Cloning, интегрированном в Virtual Storage Console 2.0 vSphere plug-in.

Введение в NetApp Virtual Storage Console 2.0 vCenter plug-in

Virtual Storage Console (VSC) 2.0 это бесплатный продукт, доступный пользователям NetApp. Будучи установлен, VSC доступен через иконку NetApp на «домашней странице» клиента vSphere. Возможности, предоставляемые VSC plug-in, таковы:

• Virtual Storage Console: Здесь доступна базовая функциональность VSC ранее версии 2.0. Эти возможности доступны бесплатно всем пользователям NetApp.

• Provisioning and Cloning: В этом разделе собраны возможности, ранее предоставлявшиеся через отдельную утилиту NetApp Rapid Cloning Utility (RCU). Такие возможности, как создание и распределение датасторов, управление настройками дедупликации, а также ряд других возможностей, бесплатно доступны с помощью этого инструмента. Возможности быстрого создания клонов данных, обеспечиваемые Provisioning and Cloning, требуют лицензии NetApp FlexClone на системе хранения, где будут создаваться клоны.

• Backup and Recovery: В этом разделе находится доступ к возможностям NetApp SnapManager for Virtual Infrastructure, через VSC 2.0 plug-in framework. Они требуют поддерживаемого VMware протокола хранения, лицензии SMVI, и лицензии SnapRestore®. Лицензия SnapMirror требуется для использования репликации средствами системы хранения, а лицензия на FlexClone требуется для системы, использующей NFS.

Рисунок 55) Virtual Storage Console 2.0.

Базовые возможности VSC обеспечивают оптимальную доступность и производительность с хостами ESX/ESXi.

Ниже лист базовых возможностей VSC.

• Определение и конфигурирование оптимальных настроек параметров ввода-вывода для FC, FCoE, iSCSI, и NFS на хосте ESX/ESXi

• Определение и конфигурирование оптимальных политик выбора пути доступа для существующих датасторов FC, FCoE, и iSCSI

• Определение и использование поддержки VAAI на системе хранения

• Определение того, какие хосты ESX/ESXi к каким системам хранения подключены

• Наблюдение и создание отчетов об уровне использования пространства от уровня датастора, до физических дисков

• Обеспечение централизованного интерфейса для сбора данных с контроллера системы хранения, сетевых коммутаторов, хостов ESX/ESXi, помогающих решить возникающие проблемы с производительностью ввода-вывода.

Provisioning and Cloning в VSC обеспечивает оптимальное распределение пространства и управление датасторами SAN и NAS на NetApp. Список возможностей Provisioning and Cloning доступный в VSC 2.0:

• Делегирование полномочий от администратора системы хранения к администратору виртуальной инфраструктуры по исполнению задач и функций Provisioning and Cloning.

• Распределение пространства под датасторы FC, FCoE, iSCSI, и NFS.

• Автоматизация назначения политик multipathing для датасторов, с использованием архитектуры VMware pluggable storage architecture для LUN-ов, в том числе и с включенным ALUA, а также путей NFS с использованием политики выбора round robin.

• Применение автоматизированных правил безопасности по разграничению доступа, когда датастор создан. Ограничение доступа в форме LUN masking и NFS exports.

• Динамическое изменение размеров датасторов FC, FCoE, iSCSI, и NFS «на ходу».

• Организация централизованного интерфейса по сбору данных с контроллера системы хранения, сетевых коммутаторов, и хостов ESX/ESXi для помощи в поиске причин возможных проблем, связанных с вводом-выводом.

5.2 Установка Virtual Storage Console 2.0

VSC обспечивает полную поддержку для хостов под ESX/ESXi 4.0 и новее, и ограниченную поддержку функциональности для хостов ESX/ESXi 3.5. Прежде чем начать установку VSC, убедитесь, что у вас есть все необходимые компоненты.

• vCenter Server version 4.0 или новее. VSC может быть установлена на vCenter Server или на другой сервер или виртуальную машину.

• Если установка проводится на другой сервер или VM, эта система должна работать под 32- или 64-bit версией Windows Server 2008, 2003 SP1 или новее, или 32-bit версией XP Professional SP2 или новее.

• На системе хранения необходима версия Data ONTAP 7.3.1.1 или новее.

Для списка поддерживаемых адаптеров и firmware, смотрите NetApp Interoperability Matrix.

Установка VSC 2.0

Скачайте установочную программу на сервер Windows, запустите мастер установки, и следуйте выводимым на экран инструкциям. После завершения установки на диск процесс открывает окно браузера для регистрации VSC как plug-in в vCenter Server. Этот финальный шаг требует наличия прав vCenter administrator для завершения процесса регистрации. В ходе процесса инсталляции, вас спросят выбрать набор возможностей VSC 2.0, который будет включен в системе. Должен быть выбран, по крайней мере, базовый набор Virtual Storage Console (выбор этого пункта в диалоге неснимаем). Пункты Provisioning and Cloning и Backup and Recovery это бывшие Rapid Cloning Utility и SnapManager for Virtual Infrastructure, и соответствующие возможности могут требовать лицензий, как это было описано ранее. Как минимум, NetApp рекомендует установить Provisioning and Cloning, поскольку ряд процедур, описанных в этом документе, зависят от наличия данных интерфейсов.

Рисунок 56) Выбор необходимых возможностей при установке VSC 2.0.

Рисунок 57) Процесс инсталляции запускает процесс регистрации в vCenter.

Рисунок 58) Регистрация VSC в vCenter Server.

5.3 Добавление контроллеров систем хранения в Virtual Storage Console

Добавление в VSC контроллеров систем хранения, обслуживающих виртуальную инфраструктуру происходит довольно просто. Используя vSphere client, подключитесь к vCenter, далее, на домашней странице, щелкните по иконке NetApp. Выберите закладку Virtual Storage Console слева. После выполнения этого шага, VSC запустит и автоматически идентифицирует все контроллеры систем хранения, работающие под Data ONTAP, подключенные к хостам ESX/ESXi виртуальной инфраструктуры. Как альтернативный вариант запуска обнаружения во всей системе, вы можете выбрать хост ESX/ESXi или кластер в vSphere client и тогда выбрать закладку NetApp на левой панели. VSC начнет поиск всех контроллеров систем хранения с хранилищами, подключенными к выбранному хосту или кластеру.

Запускается мастер Controller Credentials, позволяющий вам ввести назначенную учетную запись пользователя или службы, назначенную для управления VSC на контроллере системы хранения. Эта учетная запись должна быть либо root, либо одна из ранее созданных специально для VSC, как мы описывали ранее.

Рисунок 59) Добавление контроллера системы хранения в VSC.

5.4 Оптимальные настройки для хостов ESX/ESXi

VSC позволяет вам автоматически установить рекомендованные и оптимальные настройки для всех хостов ESX/ESXi 4.x, подключенных к контроллерам NetApp. Администраторы VMware могут установить нужные настройки для одного или нескольких хостов ESX/ESXi, выбрав рекомендованные настройки и значения для этих хостов. Данная функциональность устанавливает настройки HBA и CNA, плагины выбора пути, а также обеспечивает правильные настройки для программных механизмов ввода-вывода (NFS и iSCSI).

Рисунок 60) Установке рекомендованных настроек системы хранения для хостов ESX/ESXi 4.x, включая multipathing для существующих LUN.

5.5 Добавление контроллеров систем хранения в Provisioning and Cloning

Использование Provisioning and Cloning в VSC 2.0 в настоящий момент требует ре-аутентификации системы хранения, для задания прав, необходимых для связи с ней. Чтобы сделать это с помощью vSphere client, подключитесь к vCenter, щелкните иконку NetApp на домашней странице, и выберите закладку Provisioning and Cloning слева. Щелкните по кнопке Add для запуска мастера конфигурации.

Рисунок 61) Запуск мастера добавления контроллера в Provisioning and Cloning.

Выберите закладку Storage Controllers и выберите Add. Этот процесс позволит вам вручную добавить контроллеры системы хранения, на которых вы хотите распределять пространство хранилища и клонировать виртуальные машины из vCenter. Введите учетную запись пользователя или службы, назначенную соответствующему контроллеру. Данная учетная запись может быть или root или одной из ранее определенных для использования с Provisioning and Cloning.

Рисунок 62) Добавление контроллера системы хранения для управления с помощью RCU.

5.6 Добавление ресурсов хранения в Provisioning and Cloning

После того, как RCU установлен, администратор системы хранения может назначить ресурсы хранения, которые могут быть использованы виртуальной инфраструктурой. В эти ресурсы входят сетевые интерфейсы, тома FlexVol (для использования в SAN), и aggregates (для использования в NAS). Чтобы назначит эти ресурсы как доступные, откройте закладку Provisioning and Cloning в VSC, выберите контроллер, нажмите кнопку Resources, и назначьте ресурсы для использования их виртуальной инфраструктурой.

Выбрав prevent further changes (см. рисунок 63), администратор системы хранения ограничит возможности несанкционированного изменения этого списка в дальнейшем, с помощью введения имени пользователя и пароля. Учетная запись, которая разрешает изменения этих установок, создается при первом использовании данной настройки и безопасно сохраняется внутри VSC.

Рисунок 63) Добавление доступных ресурсов хранения в VSC с опцией ограничения дальнейших изменений только аутентифицированными членами группы администраторов.

5.7 Процедура создания датасторов в vCenter

После того, как система хранения и ее ресурсы назначены в Provisioning and Cloning в VSC, администратор VMware может начать распределять датасторы из vCenter.

Процесс начинается выбором и щелчком правой клавиши на датацентре, кластере или хосте ESX/ESXi; выборе опции меню NetApp; и щелчке по Provisioning and Cloning, а затем выборе Provision datastore.

Рисунок 64) Запуск процесса создания нового датастора на всех хостах кластера.

Этот процесс запускает NetApp Datastore Provisioning wizard, который позволяет вам выбрать контроллер системы хранения; тип датастора (VMFS или NFS); указать детали, такие как, например, протокол доступа и block size (если используется VMFS); и должен ли LUN быть создан как thin provisioned. Далее процесс подключает датастор ко всем узлам выбранной кластерной группы. Для датасторов, подключаемых по iSCSI, FC, и FCoE, VSC настраивает доступ, создавая initiator groups, включает ALUA, устанавливает LUN masking, назначает path selection policies, и форматирует LUN в формат VMFS. Для датасторов, подключенных по NFS, VSC настраивает права доступа в файле exports, и балансировку по всем доступным сетевым интерфейсам.

Помните, если вы планируете включить дедупликацию, то необходимо использование thin-provisioned LUN-ов, чтобы высвобожденное пространство хранения попало в пул свободного пространства контроллера системы хранения.

Рисунок 65 показывает пример создания датастора Fibre Channel под названием TR3749 на LUN в режиме thin-provisioned, размещенном на томе FlexVol.

Рисунок 65) Создание датастора VMFS с помощью NetApp Datastore Provisioning wizard.

Процесс создания датастора на NFS очень похож на процесс создания его на VMFS. Одна дополнительная опция доступна для датастора на NFS — он может быть сконфигурирован на автоматическое увеличение своего размера с помощью опции autogrow. Рисунок 66 иллюстрирует процесс создания такого датастора с опциями thin provisioned и autogrow.

Рисунок 66) Создание датастора NFS с помощью NetApp Datastore Provisioning wizard.

5.8 Выбор схемы размещения данных виртуальной машины

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

Схема размещения данных по умолчанию

Когда создается виртуальная машина, администратор VMware должен выбрать датастор, на котором будут храниться файлы, составляющие вместе VM. Созданная директория называется VM home directory. По умолчанию, все файлы одной VM расположены в этой home directory. В этой дирктории хранятся конфигурационный файл VM, виртуальный диск и его дескриптор, VMkernel swapfile, файлы снэпшотов VMware, файл NVRAM VMware, и так далее.

С позиции простоты использования такая схема хороша, так как содержимое VM home directory и есть виртуальная машина целиком. Смотрите рис. 67 в качестве общего вида этой схемы.

Рисунок 67) Схема размещения данных виртуальной машины и vswap VMware по умолчанию.

Схема размещения данных VM при использовании NetApp Snapshots

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

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

Рекомендуемая схема: Использование централизованного датастора VMkernel swap

Сервера ESX создают файл VMkernel swap или vswap для каждой запущенной VM. Размер этого файла может быть различен; по умолчанию vswap равен объему памяти, выделенной при конфигурировании каждой VM. Так как эти данные быстро изменяющиеся по природе, и не нужны для восстановления VM из резервной копии, или с помощью Site Recovery Manager, то NetApp рекомендует размещать файл VMkernel swap для каждой виртуальной машины вне VM home directory, в датасторе на отдельном томе NetApp, выделенном под хранение всех файлов VMkernel swap. Рисунок 68 показывает общую концепцию такой схемы.

Рисунок 68) Рекомендуемая схема размещения данных: централизованный датастор для vswap всего кластера.

Для использования такой схемы следует создать отдельный датастор для хранения файлов vswap. Так как требования к пространству хранения у VMware swap file могут изменяться, то NetApp рекомендует создать или большой thin-provisioned LUN или том FlexVol со включенной опцией autogrow. Использование thin-provisioned LUN и Autogrow FlexVol дает большие преимущества с точки зрения управления хранением swap-файлов. Такая организация хранения устраняет необходимость постоянного ручного управления пространством swap, а также снижает степень непроизводительного расхода пространства системы хранения.

Датастор, хранящий vswap, это единый общий датастор для всего кластера. NetApp не рекомендует организовывать локальные датасторы на каждом хосте ESX/ESXi для хранения vswap, так как это негативно скажется на времени проведения миграции VMotion.

Рисунок 69 иллюстрирует простоту конфигурирования централизованного датастора для VMkernel swap с помощью vCenter Server.

Рисунок 69) Конфигурирование и размещения файлов VMkernel swap.

Опциональная схема: Размещение VM swap/Pagefile на втором датасторе

Эта схема похожа на рассмотренную в предыдущей главе. Разница состоит в том, что мы также перемещаем на отдельный датастор и своп самой виртуальной машины. Эта схема имеет «за» и «против», которые стоит взвесить перед тем, как выбирать такой вариант. Эти детали мы рассмотрим ниже.

Каждая VM создает так называемый swap, pagefile («файл подкачки»), который имеет размер обычно от 1,5 до 2 раз больше распределенной VM при конфигурировании памяти. Так как эти данные неценные и быстро изменяющиеся по своей природе, то мы сможем сэкономить много пространства хранилища (а также полосы пропускания и трафика репликации), если уберем эти данные с датастора, который хранит важные рабочие business-critical данные. Для такой схемы построения swap или pagefile OS виртуальной машины должны быть помещены на другой виртуальный диск, размещенный на отдельном датасторе, на отдельном томе NetApp volume. Рисунок 70 показывает общую концепцию такой схемы.

Рисунок 70) Структура расположения данных виртуальных машин по опциональной схеме:
VM pagefile отделен от данных виртуальной машины на специальный pagefile datastore и создан vswap datastore для кластера целиком.

Как уже было упомянуто ранее, такая схема имеет свои «за» и «против». Преимущество ее состоит в том, что в снэпшот тома данных, используемый для резервного копирования или репликации не попадают неценные, временные и быстроизменяющиеся данные своп-файла, что экономит много пространства хранения на системе при создании таких снэпшотов.

Использование этой схемы может вызвать сложности в настройке при использовании VMware vCenter Site Recovery Manager. Следует настроить систему так, чтобы датастор со своп-файлами не реплицировался на DR-сайт. Использование такой схемы влечет за собой некоторое увеличение административных затрат, так как требует дополнительных настроек SRM для каждой VM, где будет указано размещение предварительно созданного pagefile VMDK на DR-сайте в SRM recovery plan. Для подробностей об использовании такой схемы с SRM, смотрите приложение в документе TR-3671: VMware vCenter Site Recovery Manager in a NetApp Environment.

5.9 Изменение размеров датастора в vCenter

Используя VSC 2.0, администратор VMware имеет возможность динамически изменять размеры датасторы «на ходу», без прерывания нормальной работы системы. VSC поддерживает возможности «расширения» или увеличения размеров датасторов VMFS и NFS, а также уменьшения размеров для датасторов NFS. Для изменения размеров датасторов, щелкните правой клавишей на объекте datastore в vCenter, и выберите NetApp, Provisioning and Cloning, и Resize.

Рисунок 71) Выбор изменяемого датастора.

Рисунок 72) Задание нового размера датастора VMFS.

5.10 Мониторинг датастора и системы хранения в vCenter

Средства VSC предлагают администраторам VMware средства для наблюдения за ресурсами хранения, на различных их уровнях, от датастора, до физического уровня дисков. На верхнем уровне отчеты по SAN и NAS выглядят довольно простыми, но следует выделить несколько моментов, на которые следует обратить особое внимание.

Мониторинг хранилища NFS

Выберите закладку NetApp в vCenter, и в закладке VSC выберите Storage Details - NAS или Storage Details - SAN, чтобы увидеть информацию о вашем датасторе. Выбрав конкретный датастор, вы увидите дополнительные детали о его конфигурации. В этом разделе мы рассмотрим несколько ключевых элементов датасторов NFS.

Рисунок 73) Подробности о датасторе на странице Storage Details в VSC.

Модуль Capacity

Модуль Capacity на странице Storage Details показывает использование датастора, томов FlexVol, aggregate или физических дисков. При использовании NFS, датастор и тома FlexVol показывают равную емкость, так как являются одними и теми же объектами. Ключевой компонент для мониторинга тут это емкость aggregate.

Для датасторов VMFS, емкость датастора и LUN всегда показывает идентичную емкость, так как они являются одним и тем же объектом. Два ключевых компонента для мониторинга это емкость тома FlexVol и емкость aggregate. Том FlexVol содержит LUN, и если LUN сделан как thin provisioned, то важно чтобы том FlexVol был сконфигурирован с опцией autogrow для того, чтобы он мог вместить всю емкость LUN. Если LUN окажется ограниченным жестко заданным размером тома FlexVol, и упрется при своем увеличении в это ограничение, то LUN перейдет в offline, пока на томе, на котором он располагается, не появится достаточно места.

Вам следует планировать оставить неиспользуемыми примерно 85% емкости aggregate. Также существуют варианты добавить дополнительные диски в aggregate или мигрировать некоторые VM или датасторы на другой aggregate или дисковый массив.

NetApp предлагает NetApp Data Motion™, как непрерывающий вариант миграции всего датастора между системами хранения, не останавливающий работу использующих его виртуальных машин.

Модуль Volume

Модуль Volume показывает несколько важных деталей о выбранном томе FlexVol. Все доступные опции устанавливаются автоматически при использовании Provisioning and Cloning. VSC распознает датасторы NFS созданные ранее, не через VSC, и может автоматически настроить правильные для них установки, в соответствии с рекомендациями NetApp.

Модуль Deduplication

Экономия пространства хранения, возникающая в результате дедупликации, показывается в модуле Deduplication. При использовании датасторов NFS, экономия в ходе дедупликации доступна непосредственно датастору, и может немедленно быть использована для работы уже существущих VM или создания на этом месте новых VM. Данные о экономии места при дедупликации также доступны правым щелчком на датасторе, выбором NetApp, и далее Deduplication management.

Рисунок 74) Просмотр деталей о дедупликации NetApp на датасторе.

Рисунок 75) Просмотр сэкономленного после дедупликации места на датасторе.

6 Конфигурация виртуальной машины и оптимальные настройки

Администраторам системы хранения

Администраторам Virtual Infrastructure

Администраторам конфигурирования виртуальных машин

6.1 Производительность файловой системы VM с OS Windows

Оптимизация файловой системы Windows для наилучшей производительности

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

Эти изменения снижают количество операций ввода-вывода, используемых самой файловой системой. Для этих изменений следуйте приведенным шагам:

1. Войдите в Windows VM.

2. Выберите Start > Run и введите CMD.

3. Введите fsutil behavior set disablelastaccess 1.

Утилиты дефрагментации диска

Виртуальные машины, хранящие свои данные на системе хранения NetApp, не требуют использования утилиты дефрагментации их собственной файловой системы, так как нижележащий уровень файловой системы WAFL оптимально размещает данные гостевой OS. Если производитель используемого вами в гостевой OS ПО рекомендует проводить дефрагментацию внутри VM, то прежде чем делать это, проконсультируйтесь с the NetApp Global Support Center.

6.2 Обеспечение максимальной доступности виртуальной машины

Оптимизация VM SCSI BUS

Один из компонентов VSC, о котором стоит упомянуть в этом документе это так называемые GOS timeout scripts, которые представляют собой набор образов ISO, монтирующиеся в виртуальную машину, для конфигурирования установок SCSI на оптимальные для виртуальной инфраструктуры значения.

Для установки таймаутов используйте предоставленные VMware скрипты (GOS timeout scripts), и выполните следующие шаги:

1. Смонтируйте образ ISO, который предоставлен VSC.

2. В vCenter Server, выберите VM для обновления, щелкните правой клавишей и выберите edit settings.

3. Выберите CDROM и выберите затем для него радиокнопку ISO.

4. Выберите соответствующий ISO, соответствующий OS виртуальной машины.

5. Выберите OK.

6. Подключитесь к консоли VM.

7. Запустите скрипт для соответствующей OS в VM.

8. Выйдите и размонтируйте образ ISO.

9. Повторите для каждой VM.

6.3 Как достичь оптимальной производительности хранилища

Выравнивание партиции VM и VMFS с системой хранения

Виртуальные машины хранят свои данные в файлах виртуальных дисков. Как и в случае физических дисков, такие виртуальные диски содержат партиции и файловые системы на них, которые создаются «гостевой OS» внутри VM. Для того чтобы обеспечить оптимальные характеристики ввода-вывода виртуальной машины, вам следует использовать правильное смещение партиций виртуального диска относительно границ блоков VMFS и границ блоков системы хранения. Ошибка во взаимном выравнивании трех этих объектов приводит к заметному падению производительности ввода-вывода на системе хранения, и негативно сказывается на производительности всех виртуальных машин, расположенных на данной системе хранения.

Существует ряд рекомендаций от NetApp, VMware, других производителей систем хранения, и партнеров VMware в которых содержатся процедуры выравнивания партиций виртуальных машин и датасторов VMFS относительно нижележащих структур системы хранения. Вы можете найти больше информации о выравнивании смещения VMFS и файловых систем гостевых OS в следующих документах:

• VMware: Recommendations for Aligning VMFS Partitions

• IBM: Storage Block Alignment with VMware Virtual Infrastructure

• EMC: Celerra IP Storage with VMware Virtual Infrastructure

• Dell: Designing and Optimizing SAN Configurations

• EMC: CLARiiON Integration with VMware ESX server

• Vizioncore: vOptimizer Pro FAQ

• Citrix, Microsoft, NetApp, and VMware: Best Practices for File System Alignment in Virtual Environments: TR-3747

Ссылки на все документы можно найти в разделе 9, «Ссылки на документы».

Выравнивание датастора

Системы хранения NetApp автоматизируют установку выравнивания VMFS при использовании LUN-ов NetApp по iSCSI, FC, и FCoE. Это происходит автоматически, при создании LUN под датастор, когда вы выбираете для типа LUN в его настройках значение «VMware». Пользователям, устанавливающим датастор VMware по NFS, не требуется выравнивание датастора.

На любом типе датастора, VMFS или NFS, виртуальный диск, содержащий партиции гостевой OS, также требует выравнивания ее относительно блоков нижележащей системы хранения.

Выравнивание партиции виртуальной машины

При выравнивании партиции виртуальной машины относительно нижележащего уровня системы хранения NetApp FAS, начальное смещение партиции должно нацело делиться на 4096. Как пример, смещение партиции после установки Microsoft Windows 2000, 2003, и XP составляет 32256. Это значение не делится нацело на 4096 и требует коррекции.

Виртуальная машина, созданная в результате «чистой» установки Microsoft Windows Server 2008 или Windows 7, или Windows Vista® автоматически установит значение смещение партиции на величину 1048576. Такое значение не требует коррекции.

Внимание: Если ваша виртуальная машина с Windows 2008 или Windows Vista была сделана путем обновления установленной ранее более старой версии Windows, то, скорее всего, смещение осталось неверным с прежней версии, и вам нужно провести выравнивание.

6.4 Обеспечение правильного выравнивания партиции VM

Важность правильного смещения данных

Мы хотим привлечь внимание читателей к важности выравнивания файловой системы виртуальной машины относительно структур системы хранения. Этот процесс нельзя рассматривать как «опциональный». Неправильное выравнивание на «верхнем уровне» приводит к снижению уровня использования системы.

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

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

6.5 Определение смещения партиции

Проверка величины смещения в OS Windows

Для того, чтобы проверить значение стартового смещения партиции для виртуальной машины под OS Windows, зайдите в VM и запустите утилиту msinfo32. В ней вы найдете значение смещения партиции. Для запуска msinfo32, выберите Start > All Programs > Accessories > System Tools > System Information (см Рис. 76).

Рисунок 76) Использование приложения msinfo32 для определения величины смещения партиции.

NetApp MBRtools: определение состояния смещения партиции

NetApp предлагает утилиту под названием MBRScan, которая запускается на хосте ESX и может идентифицировать ситуацию со смещением в виртуальных машинах с Windows и Linux®, хранящихся на датасторах VMFS или NFS.

MBRScan запускается и анализирует файлы виртуальных дисков, используемых виртуальной машиной. Процесс занимает несколько секунд на каждую VM (виртуальная машина должна быть выключена), и по завершении выводит отчет о состоянии смещений партиций. Необходимость выключить виртуальную машину для работы MBRScan в ряде случаев делает более простым вариантом определение смещения изнутри VM, например вышеописанным способом с msinfo32, так как такой вариант не прерывает работу VM. MBRScan теперь это компонент VSC.

6.6 Исправление VM с неверным смещением партиции

Начнем с исправления в шаблонах VM

После того, как вы обнаружили проблему с неверным выравниванием партиции виртуальной машины, рекомендуется начать корректировку с исправления ситуации в эталонной виртуальной машине (template). Этот шаг позволит вам в дальнейшем получать вновь создаваемые из этого эталонного образа виртуальные машины с правильно выровненными партициями.

Исправление неверного смещения партиции с помощью NetApp MBRtools

В составе пакета VSC, NetApp поставляет инструмент, под названием MBRAlign, который запускается на хосте ESX и может исправлять неверное смещение для MBR-партиций типов primary и secondary. MBRAlign требует, чтобы на время проведения исправлений виртуальная машина должна быть в выключенном (powered off) состоянии.

MBRAlign обеспечивает гибкие возможности исправления. Например, его можно использовать для миграции и выравнивания виртуального диска, а также преобразования его типа из thin в thick vmdk. Настоятельно рекомендуется перед запуском MBRAlign создать снэпшот NetApp. Когда VM скорректирована, включена, и результат проверен, тогда этот снэпшот может быть безболезненно удален.

MBRAlign можно взять в наборе инструментов, доступных по линку из VSC. NetApp рекомендует связаться с NetApp Global Support Center если вам требуется помощь при проведении этих исправлений смещения.

Внимание: Виртуальные машины Linux,которые загружаются с использованием GRUB boot loader, требуют следующих шагов после завершения работы MBRAlign.

1. Подключите в Linux VM CD с Linux или образ CDROM ISO.

2. Включите VM.

3. Выберите boot from the CD.

4. После загрузки с CD выполните установку GRUB для исправления загрузчика.

Исправление неверного смещения партиции сторонними инструментами

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

6.7 Создание правильного смещения партиции для новой VM

Создание правильного смещения VMDK для новой VM с помощью DISKPART

Виртуальные диски могут быть сформатированы с правильным смещением в момент своего создания, если вы загрузитесь в виртуальной машине до установки в нее OS, и создадите диск с заведомо правильным смещением вручную. Для гостевой OS Windows, можно воспользоваться Windows Preinstall Environment boot CD, либо одним из альтернативных "live CD/DVD". Для установки начального смещения партиции следуйте приведенным шагам и смотрите рис. 77.

1. Загрузите VM с помощью Microsoft WinPE CD.

2. Выберите Start > Run и наберите DISKPART.

3. Введите Select Disk0.

4. Введите Create Partition Primary Align=32.

5. Выйдите и перезагрузитесь.

6. Установите нужную OS как обычно.

Рисунок 77) Запуск diskpart для установки правильного смещения партиции.

Вы можете также создать правильно выровненный VMDK с помощью команды fdisk из консоли ESX.

6.8 Добавление пространства хранения для VM

Увеличение виртуального диска (VMDK)

В ESX/ESXi 4 виртуальный диск может быть увеличен в то время, как VM включена и работает. Увеличение виртуального диска это только половина всей задачи увеличения пространства хранения; вам также надо увеличить файловую систему после загрузки VM. Загрузочные и корневые тома, такие как C:\ для Windows или '/' для Linux не могут быть увеличены динамически, или во время работы системы. Для таких томов смотрите главу «Увеличение загрузочных томов гостевой OS» ниже в этом документе. Для всех остальных томов вы можете использовать родные для OS средства увеличения тома. Для увеличения виртуального диска выполните следующие шаги:

1. Откройте vCenter Server.

2. Выберите VM.

3. Щелкните правой клавишей на VM и выберите Properties.

4. Выберите виртуальный диск и увеличьте его размер (см рис. 78).

5. Запустите VM.

Рисунок 78) Увеличение размера виртуального диска.

Для подробностей о расширении виртуального диска смотрите VMware ESX and ESXi Server Configuration Guide.

Рисунок 79) Удаление VMDK из VM.

Расширение файловой системы из гостевой OS (NTFS или EXT3)

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

6. Подключитесь к VM.

7. Увеличьте файловую систему.

Для Windows VM, вы можете использовать утилиту diskpart для увеличения файловой системы. Подробнее смотрите: http://support.microsoft.com/default.aspx?scid=kb;en-us;300415.

или

Для Linux VM, вы можете использовать утилиту ext2resize для увеличения файловой системы. Подробнее смотрите: http://sourceforge.net/projects/ext2resize

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

Увеличение загрузочного тома гостевой OS

Корневой или системный том гостевой OS, в зависимости от возможностей OS, может поддерживать возможность расширения «на ходу». На момент написания данного документа у нас было подтверждение такой возможности для Windows 2008. Для всех остальных гостевых OS корневой или загрузочный том, такой как C:\ в Windows VM и '/' в Linux VM не может быть расширен на ходу или пока OS работает.

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

7 Резервная копия с помощью снэпшотов

Администраторам системы хранения

Администраторам Virtual Infrastructure

7.1 Технологии снэпшотов, дополняющие друг друга

VMware vSphere обеспечивает возможность создания снэпшотов данных дисков виртуальных машин. Технология снэпшотов позволяет создание моментальных «снимков состояния», «виртуальных копий» данных, которые могут быть созданы значительно быстрее, чем традиционная копия, и восстановление на любую сохраненную точку прошлого состояния из которых занимает значительно меньше времени. NetApp предлагает свою технологию создания снэпшотов хранимых данных с 1992 года, и хотя базовая концепция снэпшота сходна и у NetApp, и у VMware, вам следует понимать существенную разницу между ними, и различать случаи, когда один из них более применим, чем другой.

VMware Snapshot обеспечивает создание моментальной (point-in-time) версии состояния VM, позволяющую быстрое из него восстановление. Преимущества VMware Snapshot заключаются в простоте его создания и использования, поскольку это можно сделать вручную, или по заданному расписанию из vCenter Server. Однако VMware не рассматривает свою реализацию Snapshot для ESX как средство полнофункционального резервного копирования vSphere. Для подробностей о собственных VMware Snapshot, включая руководство по правильному применению, смотрите VMware Basic System Administration Guide.

Технология NetApp Snapshot может быть легко интегрирована в систему VMware, обеспечивая создание так называемых crash-consistent копий виртуальных машин для задач полного восстановления VM, полного клонирования VM, или репликации сайта для создания катастрофоустойчивости. Это единственная технология создания снэпшотов, которая не оказывает значительного отрицательного влияния на производительность системы в целом.

VMware указывает на то, что для достижения оптимальной производительности и масштабируемости, реализуемые системой хранения (hardware-based) Snapshot предпочтительнее, чем software-based решения. Недостатком таких технологий является то, что они обычно не могут управляться через vCenter Server, требуя сторонних скриптов или средства организации расписания их создания. Для подробностей смотрите VMware Basic System Administration Guide и VMware ESX and ESXi Server Configuration Guide.

7.2 Резервное копирование средствами снэпшотов NetApp

Возможность быстро сохранить данные десятков виртуальных машин, без заметного влияния на их производительность, может существенно ускорить принятие новых технологий VMware в организации. NetApp позволяет делать это через модуль Backup and Recovery в составе Virtual Storage Console 2.0. Эта возможность ранее предоставлялась как отдельный продукт с отдельным интерфейсом, под названием SnapManager for Virtual Infrastructure (SMVI). Это компонент общего портфолио решений NetApp семейства SnapManager, обеспечивающих резервное копирование средствами снэпшотов системы хранения, который сохраняет только изменения на блочном уровне для каждой VM, и обеспечивает возможность восстановления на любую сохраненную точку прошлого, кроме того, будучи интегрирован с возможностями системы хранения, SMVI обеспечивает время восстановления меньшее, чем любое конкурирующее решение.

Рисунок 80) Назначение расписания резервного копирования датастора в панели Backup and Recovery в VSC.

Рисунок 81) Новое задание создано в панели Backup and Recovery в VSC.

Для подробностей и рекомендаций по использованию резервного копирования данных vSphere через NetApp Snapshot, смотрите документ TR-3737: SnapManager 2.0 for Virtual Infrastructure Best Practices.

8 Выводы

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

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

Комментарии и замечания по содержанию этого документа приветствуются. Вы можете связаться с авторами по электронной почте, послав письмо на адрес xdl-vgibutmevmtr@netapp.com ; укажите в строке «тема» вашего письма «TR-3749 v2.0». По вопросам, связанным с русским переводом, пожалуйста обращайтесь по адресу romx@mail.ru с аналогичной строкой темы письма.

9 Дополнительные документы по теме

VMware

• VMware Introduction to VMware vSphere
http://www.vmware.com/pdf/vsphere4/r40/vsp_40_intro_vs.pdf

• ESXi Server Configuration Guides
http://www.vmware.com/pdf/vsphere4/r41/vsp_41_esxi_server_config.pdf
http://wwwvmware.com/pdf/vsphere4/r40/vsp_40_esxi_server_config.pdf

• vSphere System Administration Guides
http://www.vmware.com/pdf/vsphere4/r41/vsp_41_dc_admin_guide.pdf
http://www.vmware.com/pdf/vsphere4/r40/vsp_40_admin_guide.pdf

• VMware Fibre Channel SAN Configuration Guides
http://www.vmware.com/pdf/vsphere4/r41/vsp_41_san_cfg.pdf
http://www.vmware.com/pdf/vsphere4/r40/vsp_40_san_cfg.pdf

• iSCSI SAN Configuration Guides
http://www.vmware.com/pdf/vsphere4/r41/vsp_41_iscsi_san_cfg.pdf
http://www.vmware.com/pdf/vsphere4/r40/vsp_40_iscsi_san_cfg.pdf

• vSphere Upgrade Guide
http://vmware.com/pdf/vsphere4/r40/vsp_40_upgrade_guide.pdf

• Performance Study of VMware vStorage Thin Provisioning
www.vmware.com/pdf/vsp_4_thinprov_perf.pdf

• Все документы VMware расположены
http://www.vmware.com/support/pubs/vs_pubs.html

Разное

• Total Cost Comparison: IT Decision-Maker Perspectives on EMC and NetApp Storage Solutions in Enterprise Database Environments
www.netapp.com/library/ar/ar1038.pdf

• Wikipedia RAID Definitions and Explanations
http://en.wikipedia.org/wiki/Redundant_array_of_independent_disks

• Microsoft Diskpart Utility
http://support.microsoft.com/default.aspx?scid=kb;en-us;300415

• Ext2resize
http://sourceforge.net/projects/ext2resize

• IBM: Storage Block Alignment with VMware Virtual Infrastructure
ftp://service.boulder.ibm.com/storage/isv/NS3593-0.pdf

• EMC: Celerra IP Storage with VMware Virtual Infrastructure
www.vmware.com/files/pdf/VMware_VI3_and_EMC_Celerra_IP.pdf

• Dell: Designing and Optimizing SAN Configurations
www.dell.com/downloads/global/power/ps4q04-20040149-Mehis.pdf

• EMC: CLARiiON Integration with VMware ESX Server
www.vmware.com/pdf/clariion_wp_eng.pdf

• Vizioncore: vOptimizer Pro FAQ
www.vizioncore.com/products/vOptimizerPro/documents/vOptimizerProFAQ.pdf

• Cisco Nexus 1000V Series Switches Deployment Guide
www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9902/guide_c07-556626.html

NetApp

• NetApp VM Insight with SANscreen
http://www.netapp.com/us/products/management-software/sanscreen-vm-insight.html

• NetApp TR-3348: Block Management with Data ONTAP 7G: FlexVol, FlexClone, and Space Guarantees
www.netapp.com/library/tr/3348.pdf

• NetApp TR-3737: SnapManager for Virtual Infrastructure Best Practices
http://www.netapp.com/us/library/technical-reports/tr-3737.html

• RAID-DP: NetApp Implementation of RAID Double Parity
http://media.netapp.com/documents/wp_3298.pdf

• NetApp TR-3671: VMware Site Recovery Manager in a NetApp Environment
http://media.netapp.com/documents/tr-3671.pdf

• Data ONTAP File Access and Protocol Management Guide
http://now.netapp.com/NOW/knowledge/docs/ontap/rel731/html/ontap/filesag/accessing/task/t_oc_accs_file_sharing_between_NFS_and_CIFS.html

• DataFabric Manager Server 3.7: Operations Manager Administration Guide
http://now.netapp.com/NOW/knowledge/docs/DFM_win/rel371/html/software/opsmgr/index.htm

• NetApp: Data ONTAP File Access and Protocol Management Guide
http://now.netapp.com/NOW/knowledge/docs/ontap/rel731/html/ontap/filesag/accessing/task/t_oc_accs_file_sharing_between_NFS_and_CIFS.html

• NetApp Systems Manager Quick Start Guide
http://now.netapp.com/NOW/knowledge/docs/netapp_sys_mgr/rel10/html/software/qkstart/index.htm

• Setting RBAC Access with the VSC
https://now.netapp.com/Knowledgebase/solutionarea.asp?id=kb54084

• Citrix, Microsoft, NetApp, and VMware: Best Practices for File System Alignment in Virtual Environments
http://media.netapp.com/documents/tr-3747.pdf

• The Virtual Storage Guy Blog
http://blogs.netapp.com/virtualstorageguy

10 История изменений

Версия	Содержание изменений
1.0	Май 2009. Исходная версия
1.0.1	Август 2009. Небольшие правки. Переформатировано.
2.0	Январь 2010. Большие обновления в связи с появлением интегрированных в vCenter инструментов распределения пространства и конфигурирования. Перенесены в приложения все вручную конфигурируемые процедуры. Ручные процедуры заменены на процедуры с использованием NSM, RCU и VSC. Реорганизован документ с 16 разделов до 8.
2.1	Август 2010. Небольшие правки. Обновления до vSphere 4.1 Добавлено указание о неподдерживаемости комбинации из iSCSI multiple TCP sessions и NFS на одном и том же хосте. Удалены приложения с устаревшими ручными процедурами.

^{^[*]} Используемый термин resource shares следует понимать в смысле «акции», «голоса» на доступ к ресурсу.

^{^[†]} Подробнее о конфигурировании и использовании VIF в документе TR-3802

^{^[‡]} Приложения к TR-3749 отсутствуют в оригинале документа. Информацию о использовании «многослойного» дизайна сетевой инфраструктуры сети хранения можно найти в документе TR-3802 (есть перевод на русский язык)