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, о которых выше в посте я вкратце уже упомянул.