about NetApp

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

Вы наверняка уже знаете, что такое снэпшоты в NetApp, и как их используют, это, если вкратце, для вновь подключившихся мгновенная “виртуальная копия” даных диска или тома, “снимок состояния дисков” (отсюда Snapshot – “фотоснимок”). Принципиальная реализация в решении NetApp от всех прочих реализаций под тем же именем у других производителей, в том, что они не тормозят систему и занимают на диске место как differential copy, то есть только измененные с предыдущего снятия снэпшота блоки.

У NetApp есть два способа восстанавливать данные на дисках из созданных снэпшотов, это простым копированием нужного файла из псевдо-директории .snapshots на его прежнее место, и с помощью команды snap restore. Последняя использует технологию SnapRestore, это отдельно лицензируемая, но, наверное, почти у всех имеющаяся функция, которая используется во многих продуктах NetApp, например в SnapManager for Apps.

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

Однако в использовании SnapRestore есть один, как оказалось, довольно неочевидный для новичка “факап”, как выражается современная молодежь.

Дело в том, что SnapRestore восстанавливает из снэпшота файловую систему соответствующего тома целиком, на момент создания соответствующего снэпшота. “Целиком” означает вообще целиком, совсем целиком. И набор доступных после восстановления снэпшотов для этой файловой системы – тоже.

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

Вы выбираете, например в SnapManager, или же просто вручную, снэпшот недельной давности, и делаете ему snap restore vol1 weekly.1

Вы откатываете состояние тома на состояние неделю назад. Отлично, неделю назад проблемы не было. Но восстанавливать целую неделю работы слишком долго. Может быть три дня назад тоже еще не было ошибки? Надо восстановиться из более нового, трехдневного, или даже вчерашнего.

Опа. А у вас нету на томе снэпшота “три дня назад”. Том восстановился на состояние “неделя назад”, и никаких более новых, чем “неделя назад” снэпшотов на нем еще нет. Вы же помните, я не зря сказал, что восстанавливается том целиком, включая и состояние снэпшотов на нем.

Что делать: Ну, во-первых хорошо понимать то, как работает механизм снэпшота на NetApp. Не восстанавливать через snap restore том целиком, если есть необходимость оставить доступными более новые, чем точка восстановления, снэпшоты, или ради всего нескольких файлов. Наконец, пользоваться SnapVault, средством для “резервного копирования” снэпшотов на другой сторадж NetApp.

О любопытной функции внутри Data ONTAP прочитал недавно в блоге ntapgeek. Эта фича называется WAFL File Folding и позволяет экономить место на дисках для файлов, отдаваемых по протоколу CIFS.

Принцип работы File Folding таков. Как вы уже знаете (а кто не знает – идите и читайте), все перезаписи данных на WAFL осуществляются, согласно конструкции файловой системы, таким образом, что они не меняют собственно содержимого блока данных в файле, а записываются в отдельный свободный блок, куда переставляется “указатель”-inode. Это позволяет быстро и просто делать снэпшоты, так как в WAFL не нужно, как во всех прочих реалиациях снэпшотов, переносить содержимое перезаписывамых блоков в отдельное место. Единожды записанный блок, помещенный в снэпшот, уже никак не будет изменен, так устроена FS.

Однако представим себе такую странную ситуацию, когда обширный файл, с которого у нас взят снэпшот, перезаписывается, целиком или полностью, ровно теми же данными, что уже лежат в нем. Для каждого блока такого файла на диске будет занято по меньшей мере два физческих блока. Один – оригинальный, лежащий запертым в снэпшоте, и второй – измененный, лежащий в пространстве “активной файловой системы”, даже несмотря на то, что содержимое этих блоков совершенно идентичное.

Я теряюсь в догадках, что это за операция такое проделвывает, но факт того, что это сделано именно для CIFS, подсказывает мне, что что-то в CIFS любит перезаписывать целиком файлы, даже, например, при незначительных изменениях в нем. Например, представм, что это какой-нибудь Winword, и в нем большой файл, в котором мы поправили запятую, и нажали “сохранить”. И весь этот файл, блок за блоком, перезаписался поверх теми же данными, что были (за исключением этой запятой). Не знаю, возможно кто-то подскажет, о чем тут идет речь.

Так или иначе, в результате такой перезаписи, мы будем иметь на дисках два файла, из равного набора блоков, один в снэпшоте, а один в собственно файловой системе, ведь WAFL не видит, что там такое произошло с файлом. Попросили из приложения перезаписать стотыщ блоков – вот вам стотыщ свободных блоков, пишите в них, ведь исходный файл в снэпшоте, блоки его нельзя трогать.

Вот для решения такой проблемы и предназначена малоизвестная фича, под названием WAFL File Folding.

Включают ее командой:

> options cifs.snapshot_file_folding.enable on

и эта команда делает следующее:

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

Теоретически, как и любой процесс экономии пространства, этот процесс дополнительно нагружает процессор и занимает память задачей попарного сравнения блоков. Однако, если этот процес достигает определенного для него лимита использования RAM, он приостанавливается, и ждет ее освобождения, так что в принципе страшного ничего произойти не должно.

Утверждается, что фича эта тихо живет уже довольно давно, полагаю она была добавлена по заказу какого-нибудь Особо Любимого Клиента и его специфической задачи, и не особенно раскручивается для прочих. Данная опция существует в Data ONTAP вплоть до версии 8.1 в 7-Mode.

Так что если в ващем хранилище CIFS есть сходная проблема с перезаписью, то можете попробовать, по идее это должно экономить какое-то количество пространства на дисках, при использовании снэпшотов. Помните, однако, что это займет сколько-то процессора и памяти, так что включив это обязательно проследите за поведением системы какое-то время.

UPD: из комментариев к “зеркалу” данного поста на https://communities.netapp.com/groups/netapp-ru (если вы там еще не были - сильно рекомендую сходить и ознакомиться, это форум и сообщество по NetApp, созданное мною на официальном сайте NetApp, чтобы было удобнее вести дискуссии и обсуждения, в формате форума, и так далее. Я туда также зеркалю свои посты отсюда).

“Ну именно офисные приложения word и exel и перезаписывают файлы целиком. При открытии файла на редактирование ms офис создает новый временный файл и работаем в нем, а операция сохранения это удаляем старый, копируем новый. То есть файл всегда пишется целиком. А так как на CIFS разделах делать снепшоты очень удобно (в винде встроены механизмы отслеживания версионности файлов и нет необходимости привлекать администраторов чтоб открыть любой файл из предыдущих версий) то начинает быстро “распухать” раздел по них.

Поэтому на томах доступных для CIFS где работают с офисными приложениями и снепшоты делаются по сколько раз в день, что затрудняет возможность проведения дедупликации перед ними, данная опция маст хэв :) “

Наверняка вы уже слышали о том, как NetApp использует flash-память в форме памяти, а не эмуляции диска (SSD), я уже не раз рассказывал о том, что такое Flash Cache (ранее PAM-II), как он работает и насколько значительное дает преимущество с точки зрения производительности. С использованием обширного кэша во flash-памяти построен также нетапповский метод Virtual Storage Tiering, по многим своим параметрам превосходящий “классический” tiering, путем физического переноса данных между разными типами дисков.

Увы, все это, про “преимущества и производительность”, лишь слова, так как “потрогать руками”, не купив, Flash Cache довольно сложно, ведь ни один из российских партнеров, как я знаю, не держит систему Flash Cache для триала и демонстраций.

Однако, есть хорошая новость – на любой системе хранения NetApp вы можете оценить эффект от работы Flash Cache даже не имея ее физически, с помощью встроенного средства, под названием PCS – Predictive Cache Statistics.

Continue reading ‘Predictive Cache Statistics (PCS)’ »

Для начала несколько слов о том, что такое собственно этот VASA Provider.

VASA – это новая придумка VMware для больших сред виртуализации. Когда у вас всего один-два стораджа и всего несколько датасторов, то вам это не надо. Вы и так помните что у вас где. А вот когда систем хранения у вас будет с десяток, и несколько сотен датасторов,  несколько человек админов в три смены, вот тогда вам захочется как-то разбираться, что у вас где, и, по-возможности, быстро.

Continue reading ‘Установка NetApp VASA Provider’ »

Я уже рассказывал о том, что, начиная с ONTAP 8.х, и на 64-bit aggregate, у WAFL есть механизм компрессии хранимых на дисках данных. Механизм онлайн-компрессии сравнительно хорошо знаком пользователям, так как, например, давно поддерживается на NTFS. Однако, по моим наблюдениям, используют его не так часто, боясь его заметного влияния на производительность, и большей нагрузки на процессор сервера. Следует, тем не менее, отметить, что для современных процессоров, производительность которых сильно выросла со времен Stacker и MS DiskDrive, такая дополнительная нагрузка на процессор операций запаковки-распаковки весьма незначительна по абсолютной величине, но при этом значительно уменьшает объемы дискового трафика. Например, если компрессия, вдвое уменьшает “футпринт”, то есть хранимый объем данных, то за счет сравнительно небольшого увеличения (проценты, как правило) нагрузки на процессор, мы можем вдвое увеличить производительность чтения-записи, так как объем данных считываемых и записываемых на диск уменьшается, в нашем случае, вдвое, данные попадают на диск и считываются с него всегда уже сжатыми.

Так что влияние компрессии на производительность может быть совсем не столь однозначно отрицательным.

Но любопытно подробнее разобраться с тем, как реализована компрессия у NetApp. Дело в том, что для файловых систем, хранящих данные в фиксированных блоках-“кластерах” файловой системы, компрессия внутри этих кластеров, зачастую, бесполезна. Данные не могут занимать места менее одного блока (для WAFL – 4KB), то есть экономия места внутри блока никак не может быть использована. Сложность вызывает также работа с большим файлами. Например, в случае “обычной” компрессии файла архиватором типа ZIP, и прочими аналогичными, нам, часто, для того, чтобы извлечь, изменить или записать данные в середину большого файла, приходится распаковать и перепаковать его целиком. Это влечет за собой большую затрату времени и занятой памяти RAM. То что годится для оффлайновых архиваторов – не подходит для онлайн-компрессии.

При создании механизма компрессии инженерам NetApp пришлось решить как эти, так и многие другие проблемы.

Первый интересный с точки зрения “техники процесса” момент организации работы компрессии состоит в том, что алгоритм компрессии работает не с “файлом” целиком, а бъет его на фиксированные сегменты, под названием “Compression Groups”. Каждая Compression Group содержит 8 секторов WAFL, размером 4KB, и имеет размер 32K.

Каждый файл, размещенный на томе, со включенной компрессией, рассматривается алгоритмом компрессии как разбитый на некоторое количество независимо обрабатываемых Compression Groups (CG). Например файл, размером 60KB будет содержать две CG, одну размером 32KB, и одну неполную, размером 28KB. При этом компрессия не применяется к файлам, размерам 8KB и менее.

Каждая CG обрабатывается отдельно, а, при необходимости считывания части файла “из середины”, считывается и распаковывается не весь файл, а только необходимая Compression Group в нем.

Но это еще не все интересное.

Выглядит довольно очевидным решение как-то определять факт невозможности или низкой эффективности сжатия для данных, и данные, которые не жмутся (например JPEG, ZIP, MP3 или AVI) не жать вовсе, сэкономив на этом ресурсы процессора. Ведь в противном случае процессор будет полноценно занят сжатием-разжатием содержимого Compression Groups ради жалких долей процента результата. Именно так поступили в NetApp. Перед операцией для Compression Group определяется эффективность сжатия, и, если результат получается ниже 25% (менее четверти содержимого группы, то есть менее 8KB, удается высвободить в результате компрессии), то сжатие для данной группы не прозводится вовсе и она записывается неизменной.

Наконец, любопытным решением является разделение операций на онлайновые (inline), то есть производящиеся непосредственно “на лету”, по ходу поступления данных, и постпроцессные (postprocess). Постпроцессный метод уже широко применяется в механизме дедупликации, и позволяет свести к минимуму влияние процесса дедупликации на работу системы и ее производительность.

Несмотря на то, что большинство операций компрессии могут выполнятьcя inlne, в ряде случаев часть операций может оуществляться постпроцессно. Постпроцессная компрессия применяется, в первую очередь, к данным, которые уже лежат на диске, до того, как для содержащего их тома была включена компрессия. Кроме этого, в случае, если инлайновая компрессия не успевает обрабатывать данные, например при большом объеме записей, они также откладываются, записываются несжатыми, и становятся в очередь постпроцессной компрессии.

Постпроцессная компрессия выполняется по тому же расписанию, что и дедупликация, и запускается после выполнения процесса дедупликации для данного тома. Стоит также отметить, что дедупликация и компрессия возможны на одном и том же томе, прекрасно сосуществуют, и не отменяют одна другую. Более того, компрессия после дедупликации вполне возможна. Представьте себе множество виртуальных машин, которые хорошо дедуплицируются, так как содержат одно и то же содержимое, и дедупликация позволит нам хранить не сто виртуальных машин, а одну (и некоторое количество сохраненной “дельты” между этой VM и сотней индивидуальных VM с дедуплицированным нами содержимым) . Но ведь файлы Program Files или пользовательские файлы этого единственного экземпляра, как правило, можно еще и сжать раза в полтора! И эта компрессия будет осуществлена над уже дедуплицированным содержимым.

Следует также отметить, что компрессия, так как она осуществляется над фиксированными Compression Groups, не мешает работе дедупликации. Два идентичных и хорошо дедуплицируемых файла, будут разбиты на одинаковое количество Compression Groups, и получившиеся 32KB группы после компрессии останутся по-прежнему идентичными и по прежнему дедуплицируемыми.

Хотя в NetApp предприняли значительные усилия, чтобы повысить эффективность и постараться обеспечить наименьшее влияние на производтельность при работе компрессии, какое-то влияние на производительность (зависящее от множества факторов, как то объемы записей, характер доступа, и так далее) все равно, безусловно, будет иметь место.

Лаборатория NetApp опубликовала следующие оценки производительности для системы FAS6080 (на сегодня это уровень хорошего такого midrange класса FAS3240, пожалуй). Для такой системы были достигнуты показатели работы постпроцессной компрессии на уровне 140MB/s для одного процесса, и 210MB/s максимальной производительности для нескольких процессов одновременно. На загрузке характера файлового сервера, с нагрузкой на процессор не более 50%, задачи inline-компрессии увеличивали нагрузку на менее чем 20% для датасетов, сжимающихся минимум на 50%.

Оценочная эффективность компрессии и дедупликации показывается NetApp для разных наборов данных на следующем графике:

Я бы хотел также упомянуть, что имеющаяся у партнеров NetApp утилита SSET (Space Savings Estimation Tool) в текущей версии позволяет провести оценку эффекивности дедупликации И компрессии на реальных пользовательских данных, вычисляя на них результат работы алгоритма NetApp. Эта утилита запускается на реальных данных пользователя, работая в read-only, и, никак не изменяя и не повреждая эти данные, позволяет оценить результат дедупликации и компрессии даже без использования стораджа NetApp, например до его покупки. Эту утилиту можно просить у партнеров, она имеется для Linux и Windows.

Итак, в постах о том, как работает Cluster-mode я уже упоминал то, как работает доступ к данным на кластере. А сейчас давайте рассмотрим подробнее процесс создания LUN-а на кластере, для обычного блочного подключения его с хост-сервера Windows.

Несмотря на то, что System Manager 2.0 уже умеет работать с системами в Cluster-mode, мы посмотрим на то, как создаются объекты хранения данных Data ONTAP 8.1 Cluster-mode из консоли. Это нагляднее и проще заскриншотить.

Создадим Vserver. В предыдущем посте я рассказывал что это и зачем нужно в Cluster-mode. А вот как он создается.

Создадим Vserver под названием MyVserver на aggregate с именем aggr1:

Допустим, мы хотим обращаться к данным, хранимым на MyVserver по протоколу FCP, для версии 8.1 у нас уже есть возможность работать с данными в Cluster-mode по блочным протоколам. Для этого, включим для Vserver протокол FCP (и проверим его включение):

Target Name это физическое имя (nodename) соответствующего контроллера.

Далее нам нужно создать так называемый LIF – Logical Interface, о котором я уже также упоминал в посте ранее. LIF – это логический интерфейс, который динамически мапится на физический интерфейс того или иного узла кластера, на котором работает Vserver, и через который обеспечивается ввод-вывод данных. Создадим и посмотрим на то, что у нас получилось.

Network Address/Mask эквивалентен физическому WWPN у порта контроллера.

Создадим igroup – специальную группу, в которую включим нужные нам сервера, чтобы ограничить доступ и видимость LUN-ов только необходимыми серверами. Для этого нам понадобится знать имена WWPN тех портов серверов, которых мы назначим в группу, именно по WWPN и будем определять, наш сервер это или нет.

Создадим группу MyIGroup и включим туда FCP WWPN initiator-ов с соответствующих портов.

Наконец, создадим том FlexVol под названием MyVol:

Теперь создадим LUN по имени MyLUN на этом томе:

Смапим LUN соответствующей igroup

А теперь подключаем созданный LUN обычным образом на сервер Windows, с помощью стандартной оснастки Disk Management.

Готово. У нас на сервере подключен LUN по FCP, расположенный в кластере контроллеров NetApp под управлением Data ONTAP 8.1 Cluster-mode.

За основу поста взят пост из блога специалиста NetApp “Pseudo Benchmark”, из которого я позаимствовал скриншоты.