VMware и использование NFS: часть 1

Как вы знаете, я убежденный сторонник того, что системы хранения NetApp – это лучший выбор для использования в среде серверной и десктопной вируализации. А для самой этой виртуализации – использование протокола NFS, который для систем NetApp, более чем родной, в свою очередь, лучший способ подключить дисковое хранилище. Со мной согласны уже 36% пользователей систем виртуализации (согласно отчету Forrester за май прошлого года), причем процент использования NFS растет, и уже превысил процент использования iSCSI (23%) на этих задачах.

Я уже не раз писал в этом блоге про различные аспекты использования NFS (посмотрите старые статьи по тегу NFS), и даже переводил на этут тему Best Practices (про Ethernet Storage вообще и про VMware в частности), однако все это были разрозненные публикации “к случаю”. Мне захотелось собрать основные темы вопроса в одном месте, и обсудить их, наконец, “раз и навсегда”, или пока тема не изменилась значительно.

Но для начала несколько вводных слов, для тех, только что подключился к блогу.

NFS (Network File System) – это протокол “сетевой файловой системы” разработанной компанией Sun в глубокой исторически-компьютерной древности, и предназначенный для доступа к данным в файлах по сети, в том числе для совместного доступа к ним от нескольких клиентов. NFS, вследствие своей сравнительной простоты реализации, стал очень популярным в UNIX-мире, где работу по NFS поддерживают практически любые OS. Несмотря на то, что сегодня “файловой системой” обычно принято называть нечто иное, за протоколом доступа к файлам по сети, NFS, исторически закрепилось название “файловая система”.  С момента своего изобретения, NFS прошел большой путь, и на сегодня достиг версии 4.2, обретя множество важных на сегодня возможностей, таких как использование не только UDP, как первоначально в исходной версии протокола, но и TCP (в v3), улучшенные технологии разграничения доступа и безопасности (v4), поддержка распределенных кластерных и объектных хранилищ (v4.1) и различные методы offload-а (v4.2).

К сожалению, за NFS водится два своеобразных недостатка. Во-первых, он так и не появился в OS семейства Windows (если не считать крайне проблемной реализации, вышедшей в составе продуктов MS Services for UNIX) и остался “чужим и непонятным” для win-админов. И второе, но более важное, не все его реализации “одинаково полезны”. Многие пользователи, познакомившиеся с NFS через имеющую кучу проблем с производительностью и стабильностью, широкораспространенной реализацией в Vanilla Linux, считают, что “весь NFS такой, глючный, тормозной, для продакшна не пригодный”. А это не так.

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

А теперь о достоинствах. Во-первых следует отметить сравнительную простоту использования NFS. Его использование не требует внедрения и освоения сложной, особенно для новичка, FC-инфраструктуры, непростых процессов настроек зонинга, или разбирательства с iSCSI. Использовать NFS для доступа к датастору также просто и тем, что гранулярность хранения при этом равна файлу VMDK, а не целиком датастору, как в случае блочных протоколов. Датастор NFS это обычная монтируемая на хост сетевая “шара” с файлами дисков виртуальных машин и их конфигами. Это, в свою очередь, облегчает, например, резервное копирование и восстановление, так как единицей копирования и восстановления является простой файл, отдельный виртуальный диск отдельной виртуальной машины. Нельзя сбрасывать со счетов и то, что при использовании NFS вы “автоматически” получаете thin provisioning, а дедупликация высвобождает вам пространство непосредственно на уровень датастора, оно становится доступно непосредственно администратору и пользователям VM, а не на уровень стораджа, как в случае использования LUN-а. Это все также выглядит крайне привлекательно с точки зрения использования виртуальной инфраструктуры.

Наконец, используя датастор по NFS, вы не ограничены лимитом в 2TB, даже с VMFS ранее 5, а это очень полезно, например, если вам приходится администрировать большое количество сравнительно слабонагруженных вводом-выводом машин. Их всех можно поместить на один большой датастор, бэкапить, и управлять которым гораздо проще, чем десятком разрозненных VMFS LUN-ов по 2TB(-512bytes) каждый.

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

Однако, какие у нас имеются минусы?

Ну, во-первых, это невозможность использовать RDM (Raw-device mapping), который может понадобиться, например, для реализации кластера MS Cluster Service, если вы его хотите использовать. С NFS нельзя загрузиться (по крайней мере простым и обычным способом, типа boot-from-SAN). Использование NFS сопряжено с некоторым увеличением нагрузки на сторадж, так как ряд операций, которые, в случае блочного SAN, реализуются на стороне хоста, в случае NFS поддерживатся стораджем. Это всяческие блокировки, разграничение доступа, и так далее. Однако, практика показывает, что оверхед отражается на производительности крайне незначительно.

Большим плюсом использования NFS на стораджах NetApp является то, что выбор NFS там не диктует вам “жесткого выбора” для вашей инфраструктуры в целом. Если вам понадобится также и блочный протокол для RDM, или для крайне критичной даже к возможному 10-15% падению производительности виртуальной машины, вы можете использовать для нее iSCSI или даже FCP, все на том же сторадже, параллельно с NFS, и всеми его плюсами, для основного датастора.

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

Рекомендуется также почитать по теме:

10 комментариев

  1. Dmitriy:

    Меня больше всего огорчает отсутствие поддержки VAAI с NFS в vSphere 4. Пятую использовать не могу в силу ряда причин.

  2. Dmitriy:

    Объясните мне хоть кто-нибудь, ЗАЧЕМ нужен VAAI на NFS?
    У него там, по-моему, есть ровно одна юзабельная функция - делать thick provisioned vmdk (у самого п себе NFS файлы VMDK всегда thin, “тонкие”).

  3. Dmitriy:

    @romx:

    например, клонирование машинки с VHDD в 300 гигов (реально занято 50, полноценный Thin provisioning) по iSCSI занимает минуту, по NFS - около 10 минут.

  4. Dmitriy:

    Откройте для себя FlexClone. :)
    Работает еще быстрее и не загружает сторадж, в отличие от того клона, о котором вы говорите выше. К тому же экономит пространство на дисках.

  5. Alexey Savva:

    Основные минусы NFS vs FC, которые я открыл для себя при работе в нагруженном продакшене:
    1) Дольшее время failover (до 45 секунд) против 1-2
    2) Сложнее балансировака нагрузки (подсети, vmk и т.д.)
    3) Сложнее осуществить High Availability - мы даже перешли на использование beacon probing в VMWare
    4) 8 GB FC в целом дешевле (включая операционные расходы), чем 10 GB Ethernet

    В целом согласен с плюсам NFS, приведенными в статье - ресайзинг datastore будет очень болезнен для нас :(

  6. Alexey Savva:

    > 1) Дольшее время failover (до 45 секунд) против 1-2

    Это не так “в общем случае”. И совершенно точно в долгом процессе файловера не виноват NFS как таковой.
    Либо у вас что-то с настройками.
    Ну то есть да, если у вас под сотню шар, смонтированных на десятке серверов, тогда - да, конечно, файловер займет довольно продолжительное время. Но он также станет длиннее в случае, если у вас будет множество LUN-ов.

    > 2) Сложнее балансировака нагрузки (подсети, vmk и т.д.)

    Это таки довольно “вкусовой” параметр: “сложнее”. Вдобавок, в однажды построенной сети “сложность настройки подсетей” это далеко не первоочередная или ежедневная проблема. А вот то, что NFS дает в плюсах - это как раз вполне может быть ежедневно ощущаемым преимуществом.

    > 3) Сложнее осуществить High Availability

    Снова, я не понимаю такого критерия “сложнее”. А также того места, в котором “более сложно” отделяется от “менее сложно”.

    > 4) 8 GB FC в целом дешевле (включая операционные расходы), чем 10 GB Ethernet

    Ну, знаете… 10GB Ethernet, это было технологической новинкой года три наад, сейчас уже говорят о 40GB Ethernet, как там с этим у 8G FC? ;)

    Вопрос расчета стоимости (в том числе “операционных расходов”) по моей практике сильно зависит от того, кто считает. ;)

  7. Border:

    Со скоростью у FC все нормально. Сейчас доступны к заказу карточки и коммутаторы со скоростью порта 16Gb. Будет надо - появятся 32 и 64. План по возможным скоростям известен давно.

  8. Border:

    > Будет надо - появятся 32 и 64.

    Вы явно знаете что-то, чего не знают даже организации, разрабатывающие FC, так как пока существуют планы только до 20Gb, причем по нему неизвестна даже ориентировочная дата выпуска стандарта, а у вас уже о как размахнулось, и 32, и даже 64. ;D
    http://en.wikipedia.org/wiki/Fibre_Channel_Protocol#History

  9. Border:

    Попробуйте перейти по ссылке, на которую ссылается таблица из статьи Википедии, на которую ссылаетесь вы.

  10. Border:

    Ну так я не спорю с тем, что Fibre Channel еще будет долго где-то существовать. Вон Token Ring или FICON тоже существуют как стандарты до сих пор :D

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

20/0.139

Данный блог не спонсируется, не аффилирован, и не санкционирован компанией 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.