Для начала поговорим о том, какие бывают и что из себя представляют разные типы систем хранения  данных.

Итак, мы можем воспользоваться:

Q  SAN, Storage  Area Network  – данный  тип систем  хранения предполагает  блочный доступ. Возможен  доступ к одним и тем же ресурсам нескольких  серверов одновременно. В качестве среды передачи данных может исполь-

зоваться  Fibre Channel  и iSCSI  (строго  говоря, возможны  подобные варианты с интерфейсами SAS/SCSI, но встречаются  они гораздо реже);

Q  NAS, Network Attach  Storage – системы хранения  этого типа предоставля-

ют доступ на уровне файлов. Возможен  доступ к одним и тем же ресурсам нескольких   серверов  одновременно.  ESX(i)  поддерживают  NAS  только с протоколом NFS;

Q  DAS, Direct  Attach  Storage  – данный  тип систем  хранения предполагает

блочный  доступ. Доступ к одним и тем же ресурсам  нескольких серверов одновременно не возможен  – это чрезвычайно снижает интерес к ним для инфраструктур vSphere. Обычно СХД этого типа представлены локальными дисками сервера.

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

Q  стоимость. Очевидно,  сравнение  СХД по этому параметру выходит за пре-

делы книги;

Q  функциональность самой системы хранения, например возможность создания снимков состояния (snapshot) на уровне СХД. Про это тоже говорить здесь бессмысленно,  потому что в каких-то  решениях  эти средства  будут востребованы,  а в каких-то  – нет. Также  различием  являются функциональные особенности  того или иного подхода, например файловый доступ на NAS или блочный на SAN;

Q  производительность. Производительность – непростое  понятие,  много от

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

Q  функционал относительно vSphere – а вот по этому поводу поговорим под-

робнее сейчас.

Сравнение по поддерживаемым функциям я попытался отразить в табл. 3.1.

Таблица 3.1. Сравнение функционала СХД для vSphere

Тип СХД	Загрузка ESX	Включение ВМ	VMotion sVMotion	HA DRS FT	API for Data Protection	VMFS RDM	MSCS MFC	SIOC
Fibre Channel	+	+	+	+	+	+	+	+
iSCSI	+	+	+	+	+	+	–	+
NAS	–	+	+	+	+	–	–	–
DAS	+	+	–/+	–	+	+	+/–	–

Примечания к таблице:

Q  загрузка ESX(i) с iSCSI системы хранения  возможна только с использованием аппаратного инициатора или сетевого контроллера, поддерживающего «iSCSI boot»;

Q  если оба узла кластера MSCS/MFC работают на одном ESX(i), то СХД может быть любой; MSCS/MFC кластер  возможно реализовать с системой хранения iSCSI, но такая конфигурация не будет поддерживаться VMware;

Q  VMFS и RDM показаны в одном столбце потому, что они являются альтер-

нативами  друг другу. Дисковые  ресурсы (LUN) системы хранения  с блочным доступом  ESX(i) может отформатировать в VMFS  или подключить  к виртуальной машине как RDM;

Q  SIOC  расшифровывается как Storage  IO Control,  механизм контроля про-

изводительности СХД относительно виртуальных машин. Подробнее о нем рассказывается в главе 6.

Обратите  внимание, что основные функции доступны для СХД любого типа.

Таким образом, если стоит вопрос по выбору системы хранения, то примерный  план может быть таким:

1.    Определиться с необходимыми функциями  (в  первую  очередь  имеется в виду табл. 3.1). Например, если нам нужен  RDM,  то NAS не подойдет. С другой стороны, у систем хранения  может быть свой собственный  интересный для вас функционал, например упрощающий  резервное копиро вание.

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

3.    Если после пунктов 1 и 2 выбор типа системы хранения еще актуален, сравниваем варианты по цене.

3.2.   DAS

Direct  Attach  Storage, DAS – самый простой тип систем хранения. Характер ной чертой этого типа хранилищ является то, что их дисковые ресурсы доступны лишь одному серверу, к которому  они подключены. Наиболее  характерный пример – локальные диски сервера. Да, да – их можно считать хранилищем DAS. Те DAS, что являются отдельными устройствами, часто представляют из себя просто корзину (Enclosure) для дисков в отдельном корпусе. В сервере стоит контроллер SAS или SCSI, к которому и подключается  полка DAS. Однако даже если вы используете СХД Fibre Channel,  но пара серверов подключена  к ней без использования коммутатора FC – некоторые (как правило, старые) модели СХД не смогут выделить  один и тот же LUN сразу обоим серверам. Такая конфигурация полностью подпадает под определение  DAS.

Для  администраторов ESX(i) этот тип СХД  обычно малоинтересен, потому что такие системы не предоставляют доступа к файлам одной ВМ нескольким серверам:

Q  в  крупных  внедрениях   это  необходимо  для  живой  миграции  (VMware

VMotion), для  автоматической балансировки нагрузки  (VMware  DRS),  для функций повышения доступности  VMware HA и VMware FT;

NAS (NFS)

Q  если речь идет про небольшие внедрения, где эти функции и так не предполагаются  к использованию, то ситуация  примерно  следующая: допустим, у нас есть несколько ESX(i). Если ВМ расположены на каком-то разделяе мом хранилище,  то администратор может пусть вручную, но очень быстро и с минимальными усилиями переносить  ВМ между серверами.  Если же у нас только DAS (например, несколько больших дисков локально в сервере) – то перенос ВМ возможен лишь по сети, что медленно. А если выйдет из строя сервер, к которому подключен DAS, – то ВМ будут недоступны.

По сути, DAS используются в тех случаях, когда на разделяемое хранилище с достаточной производительностью нет бюджета, ну или под наши задачи не нужны ни живая миграция,  ни высокая доступность, ни прочие «продвинутые» функции. Возможен  вариант,  когда мы используем  под ESX(i) серверы с локальными дисками, но программно реализуем доступ к этим дисковым ресурсам по iSCSI или NFS. Обычно  соответствующая служба работает  внутри  ВМ, которая  доступные для нее дисковые  ресурсы  ESX(i) предоставляет ему же, но уже по iSCSI/NFS. А еще есть возможность с помощью сторонних программных  средств реализовать репликацию файлов  ВМ между серверами.  В таком случае мы получим  дешевую инфраструктуру без СХД, с одной стороны, но с достаточно высоким уровнем доступности – в случае выхода из строя сервера есть возможность запустить реплику  ВМ с него на другом сервере, с потерей данных с момента последней репликации.

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

Кто-то может заметить, что на рынке присутствуют  модели систем хранения, которые предполагают  соединение с серверами по интерфейсу SAS, но позволяют  множественный доступ. Такие варианты, по данной классификации, имеет смысл отнести к SAN.

Источник: Михеев М. О.  Администрирование VMware vSphere 4.1. – М.: ДМК Пресс, 2011. – 448 с.: ил.