about NetApp

Несмотря на то, что современные модные тенденции в софтостроении требуют выпускать новую мажорную версию при списке whatsnew: [*] исправлена грамматическая ошибка в панели About программы, NetApp все же следует классической модели именования  изменения версий. Однако иногда эта консервативность, на мой взгляд, бывает даже чрезмерна, так, напрмер, между Data ONTAP 8.1 и 8.1.1 в функцональность были добавлены весьма существенные, важные и интересные штуки (про одну из них – Flash Pool мы уже говорили ранее). Так, например, это фича, под названием Infinite Volume. Не то чтобы это была сверхнужная для каждого возможность, но тема любопытная, и, возможно, читателям будет интересно узнать, чем же там занимаются, за закрытыми дверями отдела разработки Data ONTAP, и в какую сторону идет направление работ.

Infinite Volume – это новая возможность для кластерных систем (под Cluster-mode) NetApp, позволяющая строить очень большие тома, с доступом по NFS v3. На сегодня лимит для Infinite Volume это 20PB и 2 миллиарда файлов в одном “томе”, то есть в одном маунте (экспорте) NFS, на 10-нодовом кластере. Разумеется эти файлы распределены по множеству томов и aggregates нод кластера, но монтируются они при этом через одну точку монтирования. Таким образом, например, 200 томов по 100TB каждый, по 20 томов на каждой из 10 нод кластерной системы, будут смонтированы на сервера по единственному пути cluster:/vol/infivolume/, а не в виде 200 экспортов, на каждом из множества frontend-серверов системы, как это бы пришлось делать в “классическом” варианте.

Infinite Volume, как вы понимаете, это достаточно специализированное решение, ориентрованное на задачи секвентального чтения больших файлов, и сравнительно редкой их записи. Мне видится, что это задача похожа на что-то типа Youtube, или сходного функционала онлайнового файлового или видеохранилища, что-то такое, где себя сейчас хорошо чувствует EMC Isilon. Infinite Volume занимает нишу, в настоящий момент незакрытого в продуктах компании участка, разделяющего задачи систем E-series (бывших LSI/Engenio) и решений на его базе, подобных NetApp FMV solution и прочих StorNext с одной стороны, и “классических” FAS в Cluster-mode с другой.

Третья часть серии постов в блоге Wahl Network, посвященных вариантам использования NFS в Vmware и организаци балансировки трафика по нескольким физическим путям.

NFS в vSphere – погружение в детали: часть 3, VMware Load Balancing Teaming

В предшествующих трех постах этой серии мы рассмотрели основные ошибки и заблуждения, связанные с использованием NFS в VMware, а также рассмотрели два варианта построения сети хранерия с использованием NFS - с единой подсетью, и с множественными подсетями. Если вы не слишком хорошо знакомы с тем, как NFS работает в vSphere, рекомендую вам начать с чтения этих статей. Выводы, к которым мы пришли, состоят в том, что NFS в vSphere требует использовать множественные подсети, чтобы использовать множественные физические линки к системе хранения, за исключением, когда EtherChannel правильно настроен правильно используется на одной подсети. Однако, даже при использовании static EtherChannel, множественные таргеты на стороне стораджа, и правильно спланированные least significant bits в адресе необходимы для использования более одного физического пути к системе хранения.

Continue reading ‘VMware и использование NFS: часть 3d – Трафик NFS и балансировка Load Based Teaming’ »

Продолжаем публикацию переводов серии постов в блоге Wahl Network, посвященных вариантам использования NFS в VMware.

NFS в vSphere – погружение в детали: часть 2, порты vmkernel и экспорты NFS в разных подсетях

Apr 27, 2012

Ранее мы уже рассмотрели некоторые ошибочные концепции относительно NFS в vSphere, а также убедились в том, как трафик NFS идет при использовании одной подсети. Сейчас давайте посмотрим, как трафик NFS в vSphere пойдет в случае использования множественных подсетей. Хотя мы говорим тут прежде всего о NFS, это все также применимо и в случае iSCSI, если для него не используется binding.

Continue reading ‘VMware и использование NFS: часть 3c – Трафик NFS в разных подсетях’ »

Для рассмотрения вопроса, как работает доступ к стораджу по NFS с хоста ESXi, я снова воспользуюсь серией постов блога Wahl Network, переводы которых я публикую сегодня и в ближайшие несколько дней. Его автор провел экспериментальную работу, показав то, как работает NFS в сети хранения, когда датасторы и vmkernel расположены в одной общей подсети, в разных подсетях, и рассмотрел вариант использования Load-based teaming, доступный для пользователей версии vSphere уровня Enterprise Plus.

Я надеюсь, что эти статьи ответят на вопрос, как же все же работает NFS в сети хранения vSphere, и как стораджи с использованием этого протокола правильно использовать для VMware vSphere 5.0.

NFS в vSphere – погружение в детали: часть 1, порты vmkernel и экспорты NFS в единой общей подсети

Apr 23, 2012

Конфигурация

Для эксперимента, показывающего, как vSphere направляет трафик NFS в одной подсети, я создал тестовый стенд, с использованием 2 серверов NFS (я использовал для этого NetApp Simulator) с каждого их которых выведено по 2 экспорта, суммарно 4 экспорта NFS. Весь трафик направлен в VLAN 5 (это подсеть 10.0.5.0/24 моего стенда) и идет на хост ESXi 5.0 update 1 (build 623860). Хост имеет 2 физических порта-аплинка и 4 порта vmkernel, дающих трафику NFS множество возможны путей. Для того, чтобы создать существенный трафик в сети хранения, я развернул 4 VM с VMware IO analyzer appliance – по одному на каждый экспорт. Это позволит мне быстро создать трафик с виртуальных машин на все экспорты разом.

Continue reading ‘VMware и использование NFS: часть 3b – Трафик NFS в одной подсети’ »

Как вы помните, я обещал остановиться на вопросе как именно правильно настраивать работу NFS по нескольким физическим интерфейсам Ethernet. ??так, отдельный разоблачения заблуждений в отношении multipathing для NFS псто!

Как я уже вкратце показал, широкораспространенное заблуждение, что, использовав NFS, вы будете вынужденно ограничены ровно одним интерфейсом ethernet, так как “NFS не поддерживает multipathing” – не верно. К моему глубокому сожалению, это заблуждение местами поддерживает даже сама VMware, несмотря на то, что метод балансировки с помощью нескольких портов VMkernel и нескольких IP-алиасов описан и рекомендуется в их же Best Practices.

Я уже написал ранее, что принципы работы NFS таковы, что даже пустив трафик Ethernet по нескольким объединенным в etherchannel портам, вы не добьетесь не только равномерной их загрузки, но даже не загрузите порты кроме первого. Это по видимому связано с тем, что NFS образует ровно одну TCP/IP сессию для данной пары IP-адресов “источник-приемник”, и именно ее и пускает по первому же подходящему для этого порту. А одну сессию разбить на несколько интерфейсов нельзя. Видимо именно это явилось источником странного заблуждения, что трафик NFS нельзя распределить по нескольким интерфейсам. Это не так, можно. Но нужна некоторая хитрость, в общем-то очевидная. Нужно создать несколько пар IP “источник-получатель”, в разных подсетях, и их уже распределить по интерфейсам.  Об этом подробнее далее в постах серии.

Впрочем, как вы уже видите, неверно и обратное убеждение. Совсем недостаточно объединить несколько портов в etherchannel (у NetApp он называется VIF или ifgrp), чтобы, автоматически, увеличить пропусную способность получившегося интерфейса в Х-раз.

Давайте разберем некоторые распространенные заблуждения на этот счет:

1. Трафик NFS можно назначить на порт VMkernel также, как мы назначаем его для iSCSI.

Это не так. К сожалению.

Как вы видите на рисунке, в обведенном оранжевой рамкой боксе, можно назначить данный порт для: iSCSI, FT, Management или vMotion. Но не для NFS. Трафик NFS пойдет по первому же порту, принадлежащему подсети IP-получателя. Если порта в подсети IP-получателя трафика нет, то трафик пойдет через порт Management, в направлении его default gateway (предсказуемо), и такого варианта следует всеми силами избегать.

2. Трафик NFS равномерно распределяется по всем аплинкам (физическим vmnic) хоста, используемым для связи с системой хранения.

Увы – нет. Когда ESXi нажодит и выбирает подходящий порт vmkernel (принцип выбора описан выше), следуюшим шагом он выбирает аплинк. Независимо от типа vSwitch, хост vSphere использует конфигурацию portgroup по умолчанию (только с использованием virtual port ID), и, при наличии нескольких активных аплинков в группе, будет выбран только один (первый подходящий) аплинк для трафика NFS к данному примонтированному экспорту. Порты в группе при этом работают на поддержку high availability, то есть при выходе из строя активного порта, трафик перейдет на ранее пассивный порт, но не для load balancing, то есть трафик NFS по портам vmnic в группе не распределяется.

3. Достаточно включить несколько физических портов на стороне стораджа в VIF (etherchannel), и трафик магическим образом распределится по всем им, расширяя полосу пропускания интерфейса в Х-раз.

Тоже, к сожалению, в общем случае, без дополнительных усилий, неверно. При наличии одной TCP/IP сессии NFS с одного IP-источника на один IP-получатель, нельзя “разложить” трафик на несколько портов. Но можно это сделать для нескольких портов, нескольких IP-алиасов для получателя и/или  нескольких портов VMkernel. Тогда, создав, например 4 пары IP в разных подсетях, для четырех eth, можно гораздо более равномено загрузить их работой. Это не столь “магически-автоматически”, но это работает. Без такого разбиения и распределения  etherchannel обеспечивает только отказостоустойчивость (при отказе активного порта, трафик перенаправится в другой, ранее неактивный, в той же группе), но не балансировку нагрузки и не расширение bandwidth.

На стороне хоста ESXi для использования балансировки вам необходимо создать static Etherchannel с IPhash-based teaming policy, и иметь у vmkernel IP уникальный, между другими vmk, так называемый least significant bit.

Если у вас на VMware лицензия Enterprise Plus, и вы используете vSphere Distributed Switch, вы также можете воспользоваться Load-based Teaming для распределения трафика по VLAN или подсетям. При этом вам также понадобятся несколько VLAN или подсетей на VIF стораджа. Подробнее о таком варианте – в одном из следующих постов.

Несмотря на то, что основная тема блога – системы хранения, прежде всего системы хранения NetApp, поневоле приходится затрагивать интересные смежные темы. Раз уж мы заговорили тут про NFS, стоит затронуть тему использования LACP при организации EtherChannel, так как, как я заметил, понимание этой темы у многих все еще довольно зыбкое.

Поэтому, в очередных переводах в этом блоге – перевод поста в интересном блоге Wahl Network

Демистификация LACP и Static EtherChannel в vSphere

May 9, 2012

Удивительно часто я слышу о людях, которые воспринимают LACP как некую волшебную палочку, которой достаточно махнуть, и все чудесным образом становится лучше, а трафик волшебным образом распределяется по множеству линков. Я думаю, что это происходит от непонимания базового устройства того, как работает EtherChannel, так как я слышал множество ошибочных утверждений и FUD вокруг этого. Этот пост является попыткой описать то, что же за штука, этот LACP, почему он не работает на обычных, native vSphere switches, и почему он, на деле, имеет совсем небольшое количество преимуществ, в сравнении со static EtherChannel.

??так, что такое LACP?

LACP, иначе известный как IEEE 802.1ax Link Aggregation Control Protocol, это простой способ динамически строить EtherChannel. Для этого "активная" сторона группы LACP посылает специальный фрейм, оповещающий о возможностях и желаемых формах EtherChannel. Возможно существование, и чаще всего так и бывает, когда обе стороны являются "активными" (может быть и пассивная сторона). Также следует отметить, что LACP поддерживает только full duplex линки (в настоящий момент, в мире гигабитных, и более, линков, которые всегда full duplex, это уже не является значимым ограничением). Как только обмен фреймам произведен, и порты на обоих сторонах согласовали поддержку требований, LACP создает EtherChannel.

Внимание: LACP также имеет ряд дополнительных возможностей при установке EtherChannel, например вычисление приоритета системы или порта, конфигурацию административного ключа, и так далее. Для нас сейчас это все не важно, поэтому эти детали мы опускаем, если хотите разобраться в подробностях, вам придется изучить эти опущенные подробности самостоятельно.

LACP отсутствует в Native vSphere Switches

Ситуация проста, нативные коммутаторы vSphere не отвечают на фреймы LACP. Они не слушают и не передают соответствующие кадры. Если вы настроили LACP на внешнем коммутаторе, он не получит отклика на запросы LACP от хоста vSphere, и, следовательно, EtherChannel не будет создан.

Если вы хотите создать EtherChannel с участием хоста vSphere, вы должны создать Static EtherChannel. Когда порт установлен в Static, он не участвует в процессах объявления или распознавания LACP – канал EtherChannel немедленно создается физическим коммутатором.

Как работает распределение нагрузки (Load Distribution)?

Главная мысль:
Как Static так и Dynamic (LACP) EtherChannel используют одни и те же методы распределения нагрузки (load distribution).

Я специально выделил это курсивом и жирным шрифтом. Да, это правда. ?? Static, и LACP используют одни и те же техники балансировки нагрузки для распределения трафика по линкам. Если кто-то утверждает иное, то можете поспорить с ним на деньги, можете хорошо выиграть.

Но Static EtherChannel требует IP Hash, а LACP - нет, не так ли?

А сейчас переходим в темную часть. Ответ на заданный в заголовке вопрос: "Это не так", но вот почему это не так?

IP Hash это требование native vSphere switch. Он не поддерживает никакие другие методы load distribution.

Скриншот выше взять из vSphere Networking guide

А это уведомление из vSphere:

Отметьте, что если я хочу использовать EtherChannel, я выбираю IP Hash в качестве метода балансировки, и появляется данный бокс с сообщением.

Внимание: Термин IP Hash эквивалентен политике load distribution policy вида src-dst-ip на коммутаторе Cisco.

Static EtherChannel в других случаях может использовать любые из доступных политик распределения нагрузки. Но когда порты работают с хостом vSphere, мы вынуждены использовать только IP Hash, так как vSphere ничего другого не умеет.

Если вы хотите использовать LACP с vSphere, вам потребуется установить виртуальный коммутатор Cisco Nexus 1000V (или IBM 5000v). Нет других способов задействовать LACP с vSphere на момент написания этого поста. ??, так как 1000V это (почти) полнофункциональный коммутатор Cisco, в отличие от native vSphere switch, вы можете использовать любые политики load distribution – вы не ограничены только IP Hash (src-dst-ip)

Преимущества LACP перед Static

LACP имеет несколько "карт в рукаве", но это не относится к методам распределения трафика по каналам EtherСhannel.

Hot-Standby Ports

Если вы добавите больше поддерживаемого числа портов в LACP port channel, есть возможность использовать лишние порты в качестве портов hot-standby mode. Если произойдет отказ активного порта, порт hot-standby автоматически заменит его.

Однако, типичное число поддержваемых портов в LACP равно 8, так что для системы vSphere это не та возможность, о коорой стоит беспокоиться. Сомнительно, что у вас сделан 8-канальный EtherChannels к одному хосту vSphere.

Failover

Если у вас имеется dumb-устройство между двумя концами EtherChannel, например media converter, и один из линков, идущих через него отказывает, LACP это понимает и перестает слать трафик в отказавший линк. Static EtherChannel не мониторит состояние линков. Это не типичная ситуация для большинства систем vSphere, которые мне встречались, но в ряде случаев это может оказаться полезным.

Проверка конфигурации

EtherChannel с использованием LACP не активируется, если есть какие-то проблемы с конфигурацией. Это помогает убедиться, что все настроено нормально. Static EtherСhannel не делает каких-либо проверок перед своим задействованием, то есть вам нужно заранее быть уверенными, что все сделано правильно.

Выводы

Я не хочу сказать, что LACP (или Nexus 1000V) это плохо. LACP - это очень полезный и популярный протокол, активно используемый. Проблема, побудившая меня написать этот пост в том, что я вижу людей, которые считают что с использованием LACP они получат лучшую балансировку трафика, или же что-то еще, что он совершенно точно не делает. Так что не спешите закупать Cisco 1000V для вашей системы vSphere только оттого, что вы хотите использовать LACP, пока вы не будете иметь ясного плана того, что, на самом деле, вы хотите получить в результате.

??сточник:
http://wahlnetwork.com/2012/05/09/demystifying-lacp-vs-static-etherchannel-for-vsphere/

В части первой я написал небольшую вводную, что такое 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, о которых выше в посте я вкратце уже упомянул.

Ну, так как до выхода 8.1.1 уже совсем немного времени, давайте я уже расскажу вам, что же такое Flash Pool, который появится у NetApp начиная с этой версии.

Я ранее уже несколько раз упоминал о новой идее NetApp – включении нескольких SSD непосредственно в дисковый aggregate системы хранения, и использования их под кэш “уровня aggregate”, в том числе и для записи. Эта конструкция дополняет возможности Flash Cache, может работать как с ним вместе, так и сама по себе, причем, отметьте, также и для систем, на которых Flash Cache, по тем или иным причинам, использовать уже нельзя, например FAS3210, 3140, и даже 2240.

К моменту выпуска, реализация Hybrid Aggregate в системах NetApp получила собственное, коммерческое имя-торговую марку Flash Pool, и далее я буду пользоваться именно им. Вы же знайте, что Flash Pool это название реализации NetApp Hybrid Aggregate в Data ONTAP 8.1.1 и новее.

К сожалению, вокруг Hybrid Aggregate/Flash Pool уже начало образовываться облако недопониманий и мифов, а моя задача в очередной раз внести ясность в тему.

??так, начнем.

Прежде всего, я бы хотел сказать, что, вопреки домыслам, Flash Pool это НЕ tiering, в классическом его понимании (например в том виде, в каком он представлен в EMC FAST), это кэш. Этот момент понятен? НЕ disk tiering, not, nicht, nie. :) Это КЭШ.

Появление Flash Pool также не означает отказа от Flash Cache. Это независимое, но дополняющее решение. Он может работать с Flash Cache, может работать сам по себе. В случае работы с Flash Cache, кэширование не дублируется. Тома, работающие с Flash Pool (находящиеся в аггрегейте с SSD) не кэшируются в Flash Cache. Помните, что Flash Cache может работать со всеми aggregates и volumes системы в целом, а кэширование Flash Pool распространяется только на тома одного aggregate. Если у вас несколько aggregates, вам понадобится добавлять SSD для создания Flash Pool в каждый aggregate, который вы хотите кэшировать в Flash.

В гибридный aggregate, то есть Flash Pool вы можете преобразовать любой 64-bit aggregate, добавив в него несколько SSD NetApp, объединенных в RAID-группу, и указав для aggregate соответстующую опцию, также его можно создать “с нуля” обычным способом, как любой aggregate. Но в создании Flash Pool есть несколько тонких моментов, именно на них я хочу остановится подробнее.

Так как Flash Pool это кэш, то есть SSD, как таковые, не доступны для непосредственного хранения на них каких-то конкретных данных, а лишь кэшируют поступаюшие на и считываемые с томов aggregate данные, добавление в aggregate SSD не увеличивает его емкость. Есть и “побочный эффект” – если вы имеете aggregate, достигший максимального возможного для данного типа контроллеров размера, например 50TB для FAS3210, то вы все равно можете добавить в этот 50TB-аггрегейт диски SSD для Flash Pool.

Тип RAID-группы для дисков, добавляемых в aggregate должен быть одинаков для всего aggregate. Если вы используете RAID-DP, то добавляемые SSD тоже должны быть в RAID-DP. Нельзя в aggregate из HDD в RAID-DP добавить SSD в RAID-4, например.

Обратите внимание, что возможность добавления в aggregate дисков SSD НЕ означает возможности добавления в aggregate дисков HDD другого типа. Flash Pool може быть (по вашему выбору) из SAS/FC и SSD, или из SATA и SSD, но НЕ из SAS и SATA.

После добавления SSD в aggregate вы, как и в случае обычных дисков, добавленных в aggregate, не можете “вынуть” их оттуда (например чтобы использовать их позже в другом, более нуждающемся aggregate) не уничтожив aggregate.

Наверняка у многих уже вертится на языке вопрос: “Как же нам воспользоваться Flash Pool, если NetApp продает SSD только в составе полки на 24 диска?” Отвечаем: С появлением Flash Pool SSD NetApp будут продаваться паками по 4 штуки, что дает вам во Flash Pool 142GB кэша из 4 SSD. Диски имеют размер 100GB [84574 MiB], и когда они включаются в aggregate, построенный на RAID-DP, вы получите из 4 дисков два диска parity и два – data. Конечно, вы можее включить в Flash Pool и больше SSD.

Однако помните, что SSD имеют интерфейс SATA. Это значит, что вы НЕ МОЖЕТЕ добавить SSD непосредственно в полку с дисками SAS. Но можете – в полку с дисками SATA. Смешивать физические интерфейсы дисков в составе одной полки нельзя. Таким образом, если у вас система с “только-SAS/FC”, вам понадобится для установки SSD, даже всего 4 штук, например, дополнительная полка “только-SATA”. Не забывайте об этой сложности.

Вопрос, который я уже тоже слышу :) “Вы говорите – SSD работает на запись? А как же с исчерпанием ресурса на перезапись для SSD?”

Ну, это тема. Да, безусловно, с этой точки зрения Flash Cache был принципиально более надежен, так как работал только на чтение, а записи (заполнение кэша) в него делались сравнительно (по меркам компьютера) редко, и большими “порциями”, которые flash memory как раз обрабатывает довольно хорошо, это не random write мелкими блоками. Однако практика использования SSD enterprise-class показывает, что проблема пресловутого “исчерпания ресурсов SSD при записи” в значительной мере надумана, преувеличена, и присуща, в основном, “бытовым” SSD. Тем не менее, эта проблема возможна, так как Flash Pool действительно пишется, работая на запись (хотя, вы не забыли, записи в WAFL не рандомны, а секвентальны). Для защиты данных в случае выхода SSD из строя вы как раз и используете объединение SSD в RAID, а сами SSD, как устройства, покрыты общей трехлетней warranty на систему.

На самом деле в отношении записи вы можете столкнуться с другой, более важной, чем мифическое “исчерпание ресурса на запись” неприятностью. Дело в том, что устройство flash таково (это так для любого flash-устройства”), что его производительность на запись падает, по мере активной записи (и пере-записи) данных на нем. Производительность SSD на запись максимальна, когда он полностью пуст и только пришел с завода.  После того, как данные на SSD записываются, перезаписываются, и он постепенно заполняется данными, его производительность постепенно снижается, и стабилизируется на более низком, чем начальный, уровне, после того, как все его ячейки будут перезаписаны. С этим эффектом знакомы все владельцы SSD. Так что не экстраполируйте результаты первого испытания пустых SSD на всю его работу.

Отвечая на третий вопрос ;) : Да, TRIM для SSD поддерживается Data ONTAP на уровне системы.

Напомню, Flash Pool, новое название Hybrid Aggregate, появится в Data ONTAP 8.1.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.

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

• VMware: Best Practices for running VMware vSphere on Network Attached Storage
• NetApp (RU): Руководство по наилучшим способам использования систем NetApp
  с VMware vSphere
• NetApp (RU): ??спользование NFS в VMware
• NetApp (RU): Ethernet для систем хранения: наилучшие методы
• NetApp (EN): tr-3880 CLI Configuration Processes for NetApp and VMware vSphere.pdf
• NetApp (EN): tr-3697 Multiprotocol Performance Test of VMware ESX 3.5 on NetApp
• NetApp (EN): tr-3808 VMware vSphere 4.1 and ESX 3.5 Multiprotocol Performance Comparison Using FC iSCSI and NFS

Когда вы настраивали сетевые интерфейсы на NetApp, возможно вы обратили внимание на опцию, устанавливаемую для сетевого интерфейса: trusted/untrusted. По умолчанию интерфейс считается trusted.

ifconfig <interface> [trusted|untrusted]

В чем разница?

Руководство Network Administration Guide пишет по этому поводу следующее:

“??нтерфейс с опцией untrusted отбрасывает все пакеты, включая принимаемые пакеты ICMP responce (ping), все, кроме пакетов протокола http. Через такой интерфейс возможен доступ к системе хранения только по http в режиме read-only.

Статус untrusted не может быть применен к группе интерфейсов (vif/ifgrp), а только к физическому порту.”