Решение существует
Чем же может с первого взгляда подкупить NFS? Прежде всего, это простота управления, масштабируемость, эффективное хранение данных, простота резервного копирования. Также аргументом «за» выступает стоимость решения. Нет необходимости в закупке оптических коммутаторов, FC-HBA в сервера —достаточно традиционного Ethernet. Как и протоколы Fiber Channel, iSCSI, файловый протокол NFS позволяет организовать подключение между хостом VMware ESX/(i) и системой хранения данных. При этом доступен весь функционал платформы виртуализации — горячая миграция виртуальных машин, высокая доступность, миграция между хранилищами — присущий методам блочного подключения.
При использовании протокола NFS не стоит забывать о ряде неподдерживаемых функций на фоне с блочными протоколами. Например, невозможно загрузить гипервизор с системы хранения данных, что заставляет заранее продумать конфигурацию тех же блейд-систем, которые часто закупаются как бездисковые. Кроме того, протокол NFS не поддерживает RDM (Raw Device Mapping).
Впрочем, сегодня существует множество вариантов решения той или иной задачи. Данная технология — не исключение. Так, можно найти альтернативу настройки NLB-кластера, который требует Raw-диски. Однако при использовании протокола NFS также не получится управлять распределением количества операций ввода-вывода через механизм SIOC (Storage I/O Control). Правда тут в поддержку NFS выступает то, что данный функционал нельзя использовать с технологией RDM.
От теории к практике
Во всём вышесказанном нас заверяют основные игроки рынка, которые производят NAS-системы хранения данных — EMC и NetApp. Что же нас ждёт на практике, и каким окажется использование протокола NFS в разрезе виртуализации?
В качестве тестируемых продуктов выступила связка VMware vSphere 4.1 как платформа виртуализации, EMC VNX VG2 как NFS-шлюз и СХД Clariion CX4, а так же блейд-система Dell PowerEdge M1000e.
Подключение хранилища по протоколу NFS осуществлялось посредством двух Ethernet 10G адаптеров, которые были агрегированы и подключались в два коммутатора Cisco Nexus серии 5000. Для достижения отказоустойчивости и максимальной производительности была задействована функция Virtual Port Channel на коммутаторах.
Со стороны сетевой настройки гипервизоров была включена агрегация сетевых карт. Для этого выделялась отдельная порт-группа с балансировкой нагрузки по методу route based on ip hash. Таким методом достигается отказоустойчивость и балансировка нагрузки. Вот тут и поджидает первый подводный камень.
Протокол NFS использует иную модель обеспечения многопутевого соединения, чем блочные протоколы iSCSI или FC. У них на уровне инициатора формируется путь к таргету. А при использовании протокола NFS выбор пути осуществляется по Ethernet MAC-адресам от хоста к коммутатору, от коммутатора к NFS-шлюзу. Каждый датастор NFS монтируется в рамках только одной TCP-сессии. По этой сессии передаются и служебный трафик, и данные. В связи с этим верхний порог пропускной способности для одного хоста ESX, подключенного к одному датастору по NFS (вне зависимости от использования или неиспользования link aggregation), равен пропускной способности одного линка. Иными словами мы получаем статическую агрегацию, при которой TCP-сессия устанавливается один раз и проходит через один путь в течение всего времени жизни.
Логическая топология решения
Multipathing или максимальная производительность NFS
Некоторые вендоры советуют использовать VMware vNetwork Distributed Switch для получения динамической агрегации. Однако это влечет за собой дополнительные затраты на лицензии и дополнительные работы по настройке. Также можно сбалансировать трафик путем использования нескольких IP-адресов. Для этого со стороны гипервизоров создается еще VMKernel, а со стороны NFS-шлюза — еще один виртуальный IP. Подключение в этом случае осуществляется по разным путям. Пропускной способности в 10 гигабит к NFS-хранилищу оказалось достаточно. В итоге более оптимальным был выбран вариант без балансировки, но с режимом отказоустойчивости для данной порт-группы. Еще один аспект, на который необходимо обратить внимание, — размещение файла подкачки виртуальных машин. В идеологии VMware даже при достаточном количестве оперативной памяти они довольно интенсивно используют файл подкачки. При использовании протокола NFS целесообразно располагать его на локальных жестких дисках. В случае с решениями без дисковых блейд-систем это становится невозможным, как и загрузка гипервизора с сети SAN. Интенсивно используемый файл подкачки расположен на NFS-хранилищах, что в свою очередь дает дополнительную нагрузку на сеть. При FC-подключении такая нагрузка тоже существует, однако она значительно меньше ввиду меньшего overhead протокола FC в сравнении с NFS.
Делаем тайм-аут
Возвращаясь к озвученным преимуществам протокола NFS, а именно, простоте управления, отметим, что помимо базовых настроек необходимо произвести так называемые тонкие настройки для достижения максимальной производительности и отказоустойчивости. У каждого производителя СХД они свои. Однако есть и общие рекомендации от компании VMware. К ним можно отнести установку специфических тайм-аутов в профилях гипервизоров. Например, установка частоты проверки доступности хранилища по всем рекомендациям составляет 12 с, а число неудачных попыток проверки доступности равно 10.
Изменения данных значений помогли разрешить еще одну нестандартную ситуацию, описанную далее. При кратковременной недоступности одного из коммутаторов идет процедура восстановления VPC-домена на коммутаторах Cisco Nexus. Активные сетевые устройства данную процедуру понимают, а в случае с гипервизорами это занимает несколько секунд. В результате vCenter считает хранилища недоступными и отключает виртуальные машины. Ту же процедуру увеличения таймеров необходимо произвести в самих гостевых операционных системах. Иначе уже на уровне самой операционной системы скажется недоступность SCSI-диска на виртуальном адаптере.
Быть протоколу или не быть?
Из общих рекомендаций можно отметить и выравнивание дисков, и изменение значений TCP Heap с ростом количества LUN. Всех этих действий при работе с протоколами FC\iSCSI не будет. В итоге простота управления и развертывания оказывается не столь уж простой, как кажется на первый взгляд. Как только встанет вопрос о резервном копировании и сценариях восстановления — появится ряд новых задач, которые тоже необходимо решить.
Несомненно, протокол NFS имеет недостатки и ограничения. Однако он имеет право на жизнь. Вполне реально использовать протокол NFS наряду, а главное, вместо других популярных блочных протоколов — решение остается за архитекторами проекта.
Автор статьи — руководитель отдела технологий центров обработки данных компании
«ЭС ЭНД ТИ УКРАИНА»
