VMware на NFS: экзотика или новый хит?

Начиная с версии 3.0 флагманский продукт компании VMware - ESX Server поддерживает три типа подключения внешней дисковой системы: FC, iSCSI и NFS.
На сегодняшний день примерно 90% инсталляций VMware используют FC. В оставшихся 10% царит iSCSI, а на долю NFS пока приходится совсем малое количество систем.
Отчего так?

Причин я вижу две. Во первых, поддержка подключения дисковых систем хранения по NFS появилась только в ESX 3, то есть сравнительно недавно. А enterprise-сисадмины существа подозрительные, недоверчивые, злопамятные и консервативные (привет, коллеги!).
И во вторых, в среде IT все еще довлеет мнение, что NAS “это что-то такое несерьезное, коробка от списанного сервера под столом, с виндой или линуксом, для хранения экселевских файлов нашей бухгалтерии и mp3-шек”, устройство, с обычным названием, хорошо отражающим отношение к ней сисадмина - “файлопомойка”. Какое там enterprise, работает и ладно.
Однако с известных пор, и стараниями известной вам компании, все это уже не совсем так.

Как это сделано:

Если у вас есть NAS работающий по NFS, например любой NetApp, или, возможно, EMC Celerra (хотя, как вы догадываетесь, и не все NAS “одинаково полезны”), то вы можете подключить созданный на нем дисковый ресурс как “сетевой диск” по протоколу NFS.

При этом вы НЕ используете VMFS (собственную файловю систему VMware для ее datastores), вы НЕ создаете LUN и НЕ монтируете эти LUNы ни в ESX (традиционный способ VMFS/LUN), ни в виртуальную машину (способ RDM/LUN - Raw Disk Mapping).
Вы получаете для своего ESX “сетевой диск”, и просто размещаете на нем файлы виртуальных дисков vmdk и vmx так, как будто это локальный диск вашего ESX, отформатированный в VMFS.

Странно и необычно? Только на первый взгляд. Просто воспринимайте этот “NFS-диск” как локальный. “А как же VMFS?”. Такие ее ключевые функции как, например, “кластерность”, то есть множественный доступ к ее разделу с разных виртуальных машин - обычная и традиционная функция NFS как сетевой файловой системы.

И все? И все.

Чем вы платите:

1. Примерно, в среднем, 5% производительности на дисковых операциях.

2. Примерно, в среднем, 5% большей загрузкой процессоров хост-серверов ESX.

И то и другое приведено на максимально возможной и максимально тяжелой тестировочной нагрузке, заметно превышающей существующую в реальной жизни.
Официальные результаты сравнения быстродействия протоколов от VMware тут: http://www.vmware.com/files/pdf/storage_protocol_perf.pdf
Там много интересных подробностей, но если лень читать - примите вышеприведенные цифры.
Чуть более подробный документ, совместное исследование той же темы NetApp-ом и VMware тут: http://media.netapp.com/documents/tr-3697.pdf

Что вы получаете (плюсы):

1. Простое и эффективное использование всех фич NetApp, таких как thin provisioning (динамическое выделение пространства тому по мере его потребности в месте, а не сразу в момент нарезки тома или LUN), дедупликация, снэпшоты. Почему, и за счет чего это так, я остановлюсь отдельно.

2. Эффективное “умное” кэширование, в том числе и с использованием PAM (Performance Acceleration Module).

3. Легкое управление: создание, удаление, перенос, резервное копирование и восстановление.

4. Отказоустойчивость и “многопутевость” подключения, обеспечиваемая отказоустойчивостью IP.

5. В ближайшей перспективе возможность использования 10Gb Ethernet. (Ну, как “в перспективе”. Купить 10Gb, в том числе и порты расширения этого стандарта в NetApp вы можете уже сейчас, разве что это пока все же дороговато. Хотя, наверное, не намного дороже, чем перейти на 8Gb FC. А то может и дешевле уже.)

6. В еще большей перспективе вы можете использовать сверхвысокопроизводительную многоузловую grid-систему Data ONTAP GX, которая сейчас уже доступна и работает в качестве NFS NAS (но пока очень ограниченно применима как SAN).

Что вы не получаете (минусы):

1. Вы, скорее всего не сможете использовать VCB (VMware Consolidated Backup) - автономную бэкап-систему VMware ESX.
Довольно сомнительный на мой взгляд недостаток, учитывая примитивность самого VCB, с учетом наличия при этом, как альтернативы, снэпшотов и SMVI. Но вдруг кто-то себе жизни не видит без него.
Также в блоге Ника Триантоса описывается остроумный способ “псевдо-VCB” - просто смонтировать файлы vmdk как разделы в linux-машине и, при наличии утилиты чтения NTFS, вы сможете делать пофайловый бэкап содержимого даже и windows-разделов.
Также обратите внимание, что работа по NFS, с недавних пор, стала доступна для VCB, входящего в версию 3.5, но есть ограничения.

2. Вы не сможете использовать внутри виртуальных машин MSCS - Microsoft Cluster Services - кластерную систему Microsoft. Ей нужны RDM(Raw Disk Mapping)-диски, то есть LUN-ы подключеные внутрь VM как raw-диски. Зачем нужен MSCS при наличии VMotion, HA и DRS? Ну может MSCS у нас бесплатен (в составе MS Windows Server Enterprise), а лицензия VMware HA за деньги, или мы по каким-то внутренним причинам переносим без изменений в виртуальную инфраструктуру физическую серверную систему на MSCS, почем знать.

В обоих этих случаях вы можете совместить NFS и LUN-ы SAN. Выбор одного варианта не отбирает и не запрещает вам второй.

Частый вопрос:
Q: “Будет ли это все работать у меня, если мои виртуальные сервера - Windows?”
A: “Да, к NAS, с дисками по NFS, подключается не “гостевая” виртуальная OS, а сам ESX. А для гостевых OS диски, получаемые ESX-ом c системы хранения, выглядят как локальное пространство дисков ESX-сервера, и с NFS как таковым виртуальные машины дела не имеют, все для них уже сделал ESX. Ваша виртуальная машина создает диск, и вы получаете на NFS-томе обычные файлы vmdk, словно это локальный диск ESX под VMFS”.

Характерный комментарий к одному из постов на эту тему:
“Dan Pancamo said:
950 VMs across 35 ESX servers. ALL on Netapp over NFS for more than a year now. FC/iSCSI? No thanks!”

Ну что, убедил посмотреть тему повнимательнее и пересмотреть предубеждения?

Еще почитать на тему:

Nick Triantos, один из разработчиков NetApp
VMware over NFS (07.09.2007)

Обзор Gartner:
Choosing Network-Attached Storage for VMware: What You Should Know

Mark Mayo
VMware Server and NFS? Am I alone?

Chuck Hollis, Вице-президент EMC по технологическим альянсам, вечный оппонент Хитца, который никогда не упустит в своем блоге возможности злобно куснуть NetApp ;), придерживается того же мнения:
Storage Protocols and VMware (4.12.2007)
VMware Virtual Infrastructure 3 – Climbing The Mountain (21.12.2006)

Ничего удивительного, ведь NAS продают и EMC.
Using EMC Celerra IP Storage with VI3 over iSCSI and NFS.

Dan Pancamo
Why VMware over Netapp NFS

Ну и наконец еще раз упомяну на мой взгляд интереснейший, полезнейший и очень активно пополняющийся блог Михаила Михеева, преподавателя по теме VMware VI в УЦ Микроинформ. Если вы занимаетесь VMware, то имеет смысл на него подписаться, множество важной и интересной информации собранной “на просторах” там публикуется.
Вот, например, все о теме NFS: http://www.vm4.ru/search?q=NFS

Ну что-ж. Так и не уложил в один пост всю тему. To be continued.

2 комментария

  1. ivs:

    Отличный текст!

    Я только не понял, почему же “для гостевых OS диски, получаемые ESX-ом c системы хранения, выглядят как локальное пространство дисков ESX-сервера” и при этом не работает MCSC?

    P.S. WSFC также не будет работать?

  2. Если отвечать коротко, то это “Not supported”.

    А вообще, посмотри в комментах к посту Ника Триантоса
    http://storagefoo.blogspot.com/2007/09/vmware-over-nfs.html

    он там на такой же вопрос человека с ником Phani отвечает.
    Вот этот фрагмент начинается:
    http://storagefoo.blogspot.com/2007/09/vmware-over-nfs.html?showComment=1195227840000#c9189872204520561733

Оставить комментарий

20/0.137

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

This content is not endorsed, sponsored or affiliated with NetApp, Inc. The views expressed in this blog are solely those of the author and do not represent the views of NetApp, Inc.