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

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

Итак, перейдем к некоторым конкретным вопросам, на которые приодится отвечать, выбирая NFS в качестве протокола доступа к датастору в VMware. Впервые такой вариант появился еще в VMware ESX 3.0, и постепенно зарабатывает все большую популярность, потесняя “классический” блочный способ подключения по FCP или iSCSI. О преимуществах, и некоторых недостатках я писал в первой части данной серии.

Какие же основные проблемы принято называть, когда речь идет о испоьзовании NFS для VMware?

1. На NFS нет multipathing.

И значит, выбирая NFS, я ограничен производительностью только одного интерфейса Ethernet” добавляется явно или подразумеваемо. Ну, на самом деле это “и так и не так”. Пока оставим “за скобками” практическую надобность расширения канала к дискам даже для Gigabit Ethernet NFS или iSCSI (во многих системах это расширение bandwidth имеет довольно спорную практическую ценность). На NFS действительно нет multipath в том виде, в котором он понимается в блочных протоколах, потому что multipathing (MPIO, Multipathed Input Output) – это фича исключительно блочных протоколов. А так как NFS это не блочный протокол, то фичи блочных протоколов в нем быть не может “по определению”. Это так. Однако, NFS, как протокол поверх TCP/IP, конечно же имеет возможности реализации отказоустойчивости, путем использования множественных путей (как его имеет сам нижележащий TCP/IP), а также использования нескольких параллельных каналов доступа к данным, для расширения bandwidth.

Но тут есть некотрая тонкость. Проблема связана с тем, что NFS, для связи с данным датастором, с данным IP, и всеми его файлами, использует только одну TCP-сессию. А одну сессию, имеющую один IP-source и один IP-destination никак нельзя забалансировать по нескольким физическим портам Ethernet, даже с использованием etherchannel, формально работающем уровнем ниже.

Но можно (и нужно) выйти из положения хитрым трюком. Дело в том, что можно создать для destination несколько так называемых IP-алиасов, а также несколько портов VMkernel в качестве IP-source. Датастор, тем самым может быть доступен по нескольким равноправным IP-адресам. Если мы подключим датастор таким образом, у нас уже могут быть несколько различных IP-destination, через разные IP-source в VMkernel и, значит, заработает балансировка по IP-хэшу. Такой трафик, вышедший из нескольких IP-source в своих подсетях, и пришедший на сторадж в разные IP-алиасы, можно распределить по нескольким физическим eth-интерфейсам. Просто это присходит не “мистически-автоматически”, как в случае iSCSI MPIO, а путем ручной настройки этой балансировки, и дальнейшей ее самостоятельной работы.

Подробнее о этом методе рассказывается в TR-3802 Ethernet для систем хранения: Наилучшие методы (глава 4.6 IP-алиасы), и в TR-3749 Руководство по наилучшим способам использования систем NetApp с VMware vSphere (глава 3.3 Основы сети хранения с использованием Ethernet, глава 3.6 Сеть хранения с использованием Multiswitch Link Aggregation).

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

UPD: Если вы счастливый обладатель VMware в лицензии Enterprise Plus, то тогда вам доступен еше один вариант загрузки нескольких NFS-линков к стораджу - это режим Load-based Teaming для интерфейсов vnic. Об этом способе мы также поговорим чуть позднее в отдельном посте.

2. NFS нестабилен в работе и имеет проблемы с призводительностью.

“Мы видели это своими глазами, собрав сервер NFS на Linux” – добавляется явно или подразумеваемо. И это снова “и так, и не так”. Да, действительно, реализация NFS на Linux давно страдает серьезными проблемами, ее обычно приходится в продакшне твикать и патчить, только чтобы поправить некоторые наиболее вопиющие проблемы. В vanilla code она в продакшн малопригодна. Но это не значит, что любой NFS server также непригоден, только потому что он – NFS! Реализация NFS от NetApp зарекомендовала себя во множестве систем крайне высокого класса, ей по плечу задачи от небольших систем, до масштабов Yahoo!, Oracle, Siemens и Deutsche Telecom. NetApp имеет опыт разработки и эксплуатации NFS-серверов уже около 20 лет, в самых жестких условиях и требованиях по производительности и надежности.

Итак: Не все реализации NFS “одинаково полезны”. И реализацией NFS в Linux многообразие их не исчерпывается. Не нужно интерполировать на NetApp неудачные реализации одной отдельно взятой подсистемы, в одной конкретной OS (или группе OS, использующих общих прародителей данного кода).

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

Один комментарий

  1. Владимир:

    Не могу понять: почему в документе TR-3749 при использовании Multiswitch Link Aggregation на стороне ESXi можно обойтись одним vmkernel для балансировки, а при использовании обычных коммутаторов обязательно несколько vmkernel из разных подсетей?
    Подскажите пожалуйста

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

20/0.131

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