Strict Standards: call_user_func_array() expects parameter 1 to be a valid callback, non-static method GoogleSitemapGeneratorLoader::Enable() should not be called statically in /home/sync4me/domains/aboutnetapp.ru/public_html/blog/wp-includes/plugin.php on line 311
Nas | about NetApp

Posts tagged ‘nas’

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

Третья часть серии постов в блоге 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’ »

fpolicy – простая блокировка файлов по расширению в NAS

Если вы используете систему NetApp как NAS, то есть как файловое хранилище по протоколу CIFS, то вы можете настроить в ней несложную блокировку нежелательных файлов по расширению (это конечно не сработает при смене расширения, но уже само по себе хоть что-то). Механизм этот назывется fpolicy и описан в документации.

filer> fpolicy create Media screen
File policy Media created successfully.
filer> fpolicy ext inc set Media .mp3
filer> fpolicy monitor set Media -p cifs -f create,rename
filer> fpolicy options Media required on
filer> fpolicy enable Media -f
Thu Feb 10 14:12:52 CST [hounas04: fpolicy.fscreen.enable:info]: FPOLICY: File policy Media (file screening) is enabled.
File policy Media (file screening) is enabled.
filer>

Не забудьте также отдельно включить fpolicy в целом, установив соответствующую опцию системных настроек

filer> options fpolicy.enable on

Далее можно посмотреть на установленные параметры и статистику работы.

filer> fpolicy show Media

File policy Media (file screening) is enabled.

No file policy servers are registered with the filer.

Operations monitored:
File create,File rename
Above operations are monitored for CIFS only

List of extensions to screen:
.MP3

List of extensions not to screen:
Extensions-not-to-screen list is empty.

Number of requests screened          :  0
Number of screen failures            :  0
Number of requests blocked locally   :  0

NetApp System Analyser for CIFS

Продолжая тему контроля пользователей NAS, начатую постом про команду cifs top, хочу отметить любопытную утилиту, доступную на сайте NOW: NetApp System Analyser for CIFS

Это автономная утилита под x32 и x64 Windows, помогает контролировать и анализировать загрузку NAS-системы пользователями по протоколу CIFS.

image

Утилита состоит из четырех компонент:

Dashboard: основная панель, показывающая обзор состояния контроллера системы хранения, таких его параметров, как CPU utilization, объемы трафика, счетчики производительности CIFS и общую информацию по системе.

image

Analyzer: Создает отчеты и делает рекомендации по вашей ситуации, определяя возможные источники проблем.

image

User Statistics: Показывает статистику по пользователям,  позволяет оценить кто из пользователей (а также серверов или приложений) и сколько использует ресурсов CIFS.

 

Support Report: Собирает данные, необходимые для работы NetApp Support, для анализа и устранения проблем, связанных с CIFS. Вывод может быть послан непосредственно в NetApp из самой утилиты, или записан и отослан отдельно.

Полезные команды: cifs top

Если с занимающими много места на дисках пользователями NAS можно справиться механизмом квот, то что делать с пользователями, которые используют много, но не места, а системных ресурсов, например загружая систему большим числом операций ввода-вывода?

Прежде всего таких следует найти и оценить загрузку от них. В этом поможет команда cifs top.

Для начала нам надо включить системную опцию:

fas1> options cifs.per_client_stats.enable on

Далее, собрав некоторую статистику, введем команду:

fas1> cifs top –n 3 –s w - показать трех самых активных пользователей, отсортировав список по объемам записи

    ops/s  reads(n, KB/s) writes(n, KB/s) suspect/s   IP              Name
     263 |     29   215 |     137   627 |        0 | 10.56.10.120 ENGR\varun
     248 |     27   190 |     126   619 |        1 | 10.56.10.120 ENGR\jill
     246 |     26   195 |     125   616 |       19 | 10.56.12.118 MKTG\bob

 

Более подробно о доступных ключах команды можно узнать из встроенной документации и манов.

Поддержка SMB2.0 в протоколе CIFS на NetApp

Появившийся на Wndows Vista, а позднее и на Windows Server 2008 протокол SMB2.0, дальнейшая разработка Microsoft своего сетевого протокола, показывает заметное улучшение производительности, однако требует для своей работы пока не слишком распространенных платформ Vista и Server 2008.

Но для тех, кто уже перешел на новые платформы, интересно будет узнать, что SMB2.0 поддерживается в протоколе CIFS в NetApp FAS начиная с версии ONTAP 7.3.1
Для включения SMB2.0 надо изменить значение системной опции options cifs.smb2.enable

Любопытное исследование, показывающее эффект от перехода на SMB2.0 с Jumbo Frames в гигабитной локальной сети найдено тут:
http://www.alternativerecursion.info/?p=48

image

Пожалуйста, обратите внимание, что SMB2.0 поддерживается только в Vista, Windows 7 и Server 2008, включать его при использовании в сети клиентов XP и Server 2003 нельзя.

Официальный документ из технической библиотеки NetApp:
SMB 2.0 – Next Generation CIFS protocol in Data ONTAP®

VMware на NFS: в жизни

Пример по настоящему большой системы, использующей NFS для VMware:

Около 1000 виртуальных машин, на 35 ESX-серверах, в двух локациях. Все на NFS нескольких NetApp FAS. С августа 2006 года отказались от FC SAN и перешли на NFS.

Система, созданная и работающая в крупной международной инвестиционной компании Invesco, получила 2007 NetApp Innovation Awards в категории Enterprise Infrastructure - награду, ежегодно присуждаемую за наиболее значимое внедрение технологий и решений NetApp.

“Я всерьез уверен, что даже сам NetApp не видел своего потенциала в этой области, пока мы не продемонстрировали значение снэпшотов и технологий репликации от NetApp в среде VMware” Dan Pancamo.

“В августе 2006 года, когда был анонсирован NFS для VMware, мы планировали крупное обновление нашей инфраструктуры VMware. На тот момент наша инфраструктура состояла из примерно 20 ESX-хостов, с, примерно, 750 виртуальными машинами, использующими по Fibre Channel систему хранения Hitachi. Мы также использовали много систем хранения NetApp, и, зная преимущества NFS перед SAN, мы решили исследовать возможность использовать системы NetApp по NFS с VMware. Я почти уверен, что мы были первыми клиентами NetApp, сделавшими это.

Конечно, первым барьером была производительность. К счастью, у нас были результаты производительности нашей VMware-системы, примерно за годичный период. После внимательного анализа этих данных, мы обнаружили, что уровень используемой полосы нашей SAN был весьма низок. В среднем он был в районе 10-15MB/s по всем 20 серверам, с пиками не превышающими 50MB/s. Так как миграция на NFS была проста, мы решили перенести несколько тестовых серверов на NFS. Все что мы сделали, это смотнитровали том NFS на ESX-сервер и запустили перенос виртуальных машин. После миграции примерно 100 VM на NFS в течении 6 месяцев, мы решили строить нашу новую инфраструктуру целиком на NFS.

Мы купили два выделенных специально под эту задачу NetApp 3070 и несколько новых восьмипроцессорных серверов, под ESX-хосты новых проектов. Мы также используем уже имеющийся у нас NetApp R200, хранящий снэпшоты за 21 день, для онлайн-бэкапов. Этот R200 также используется как запасная система, в случае полного выхода из строя основных хранилищ. В течении 6 месяцев мы полностью перенесли все наши виртуальные машины с SAN в NetApp NFS. Сегодня у нас примерно 1000 виртуальных машин в нашей системе VMware VI.

С нашей текущей загрузкой NetApp FAS3070 мы оцениваем возможности по расширению текущей системы по меньшей мере еще на 2000 виртуальных машин просто добавлением новых ESX-хостов. Нынешняя нагрузка по вводу-выводу на наш NetApp FAS3070C составляет в среднем 4MB/s с несколькими пиками до 30MB/s в течени дня. Никаких проблем с производительностью ввода-вывода не возникало. Наши администраторы VMware сказали, что все стало работать даже быстрее, чем в случае SAN, когда они устанавливают OS, при работе VMotion и клонировании.

Мы сейчас не запускаем в виртуальных машинах Exchange или SQL Server, однако с запланированным 10Gbit Eternet и Infiniband, как я думаю, скоро все реальные сервера перейдут в виртуальные.”

VMware на NFS: подробности о плюсах.

Я решил не раздувать прошлый пост, упихивая в него всю тему.
Сегодня подробнее о том, почему, и как именно вы получите “больше от того же NetApp” при использовании VMware на NFS.

Простое и эффективное использование всех фич NetApp, таких как thin provisioning (динамическое выделение пространства тому по мере его потребности в месте, а не сразу в момент нарезки тома или LUN), дедупликация, снэпшоты.

Почему оно хорошо работает с NFS и что ему мешает работать также хорошо на FC/iSCSI?

Схема работы VMware ESX по NFS с NetApp FAS

Thin Provisioning (подробнее было здесь)
Я уже ранее писал о thin provisioning. Это любопытная технология, которая позволяет экономить место на дисковой системе хранения за счет того, что, в отличие от традиционного метода, место для занимающего пространство объекта, будь то LUN или файл, например тот же VMDK, выделяется и резервируется не в момент создания, а по мере заполнения его реальным содержимым.

Простой пример. Вы администратор системы хранения и у вас есть 1TB. Но кроме терабайта пока свободного места у вас есть пользователи со своими проектами. Например к вам пришли трое, каждый желает получить по 500GB под свои базы данных. У вас есть несколько вариантов решения. Вы можете выделить первым двум запрашиваемые 500 и отказать третьему. Вы можете урезать их треования и выдать всем троим по 330GB вместо просимых 500.

В обоих случаях вы окажетесь с полностью “занятым” стораджем, при том, что вы точно знаете, что в ближайший год все три базы едва ли по 50-70GB объема наберут, остальное же выданное место будет лежать “про запас”, “чтобы два раза не ходить”, распределенным и не доступным другим нуждающимся. Обычное дело, всем знакомо.

В случае использования thin provisioning-а вы смело выдаете всем троим по просимым 500GB. Все трое видят для себя доступным LUN размером 500GB, ура. Они создают на нем базы, каждая из которых постепенно растет и использует место. С точки зрения же вас, как администратора, свободное пространство на дисках, общей емкостью в 1TB, несмотря на то, что на нем лежит три якобы 500GB LUN, уменьшилось всего на 50*3=150GB, и вы все еще имеете 850GB свободного места, постепенно уменьшающееся по мере роста реального размера баз. Придет к вам четвертый - получит пространство под свои задачи и он.

Традиционный вопрос и традиционный ответ.
Q: А как же фрагментация? Ведь мы еще со времен Windows 95 привыкли отключать динамически изменяемый своп и фиксировать его для достижения лучшей производительности? Если мы предоставим LUN-у рсти как ему вздумается, то он начнет писаться куда попало, а не подряд?

A: Ну наверное для Windows на FAT это действительно верно. Но в случае WAFL это особого смысла не имеет. WAFL как файловая система устроена так, что он в любом случае будет писать “вразнобой” (см. статью про устройство WAFL), “куда попало” AKA “Write Anywhere”. То есть выделили-ли вы фиксированный LUN, или предоставили ему расти самостоятельно (autogrow), хоть так, хоть сяк, оно будет работать, с точки зрения файловой системы, одинаково. ? если вас устраивало быстродействие в случае традиционного provisioning-а “одним куском”, то нисколько не медленнее оно будет и в случае thin provisioning-а.

Почему это хорошо работает для NAS, и часто не так хорошо для SAN?
Дело в том, что в случае NAS система хранения обладает полной информацией о хранимых данных. Ведь она создает и поддерживает на своей стороне файловую систему, и знает все о том, что у нее хранится. В случае же хранения LUN, она просто предоставляет внешнему пользователю “массив байт”, и далее не знает ничего о том, что и как там на нем происходит.
Вся информация, которой она располагает, это то, что вот эти байты были “потроганы”, и, значит, скорее всего, содержат информацию, а вот эти - нет, и скорее всего они пусты и не используются.

Простой пример, приведший к созданию опции Space Reclamation в новых версиях SnapDrive for Windows.
Мы создаем LUN размером 500GB и размещаем на нем файловую систему, например NTFS. Мы форматируем ее, создаем на ней некую структуру файловой системы, и начинаем записывать данные. Спустя какое-то время мы записали на данный LUN 90% его емкости и решили его почистить от ненужного, надеясь за счет thin provisioning-а получить больше свободного места на системе хранения. Но, после удаления более ненужной информации, наш LUN на системе хранения продолжает занимать все те же 450GB, как и до чистки. Почему?

Потому что SAN-сторадж ничего не знает о том, что на нем произошла чистка. Вы знаете, что отличие свободного от занятого блока, с точки зрения файловой системы, это просто наличие специального атрибута блока “свободен, можно использовать повторно”. С точки зрения системы хранения все 450GB нашего LUN-а несут какую-то информацию, а таблица “занято-свободно” файловой системы для стораджа недоступна.

?менно для решения такой проблемы и была создана опция Space Reclamation. SnapDrive, работая “послом” на уровне OS и взаимодействуя с драйвером файловой системы, сообщает “вниз”, своему стораджу, что там “наверху” происходит, какие из ранее использованных блоков можно опять считать незанятыми и освободить их.
Но такое доступно, повторюсь, только при использовании нового SnapDrive.

Зато просто и естественно получается при использовании стораджа как NAS. Веь в данном случае он сам следит за тем, какие блоки занимаются и высвобождаются.
Следовательно, thin provisioning на NAS получается, обычно, гораздо эффективнее.

Дедупликация.

Подробнее и в деталях о дедупликации можно почитать на русском языке в статьях “A-SIS: Дедупликация созрела” и “Насколько безопасна дедупликация?”
Кроме того, хочу обратить ваше внимание на русскоязычную рассылку, которую проводит российский дистрибутор NetApp - компания Verysell. Ссылка на уже вышедшие выпуски находится справа, в колонке “Ссылки” - “Русскоязычные документы”.

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

Deduplication

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

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

Если вы используете “классический метод” подключения LUN к ESX-серверу, с созданием на нем VMFS и хранением в ней файлов виртуальных дисков VMDK, то вы тоже можете воспользоваться дедупликацией. Так как она работает на уровне тома WAFL, то она заработает и для LUN-ов.

Однако вот в чем хитрость. При использовании дедупликации для LUN, экономию места вы увидите на уровне “администратора системы хранения”, а не “администратора VMware”. То есть после завершения postprocess-цикла дедупликации вы не увидите больше места на LUN. Но вот зато на томе NetApp, где располагается этот LUN, вы действительно получите больше места (например для размещения снэпшотов), так как физический объем LUN-а уменьшился, относительно содержащего его тома.
А вот если мы дедуплицируем содержимое NFS-шары, то вот прямо свободное место, непосредственно доступное админу VMware на этой шаре, в результате и получаем. Опять же по вышерассмотренной причине.

Снэпшоты - один из краеугольных камней системы хранения NetApp и одна из ее самых главных технических фишек. Мгновенные копии состояния системы хранения, не занимают в момент создания места, не ухудшают при использовании производительность системы в целом и весьма просты в применении.

Традиционный подход это подключение LUN по FC или iSCSI, форматирование его в VMFS и создание на нем datastore, для размещения в datastore файлов виртуальных дисков VMDK.
Обычно, когда мы не ограничиваемся одной-двумя виртуальным машинами, мы объединяем и группируем диски виртуальных машин по датасторам. Тут у нас Эксченджи, тут файловые сервера, а тут - базы данных. Это облегчает администрирование, увеличивает надежность сервисов, и улучшает производительность, группируя сходную нагрузку в пределах одного потока ввода-вывода.

Но, как известно бэкап - ничто, без процесса восстановления. А вот с восстановлением все будет непросто. Так как в снэпшоте у нас окажется LUN целиком, то и восстановить его, привычным образом через “snap restore ” мы можем только целиком, вместе со всеми VMDK от разных машин. Хорошо ли будет из за сбоя на одном сервере откатывать всю группу? Сомневаюсь.
Конечно есть выходы, можно смонтировать снэпшот как отдельный датастор, и из получившегося “датастор-прим” вытащить только нужные нам VMDK, а затем перенести их в основной датастор, заменив ими текушие файлы…
Но как-то… неаккуратненько.

Какой же выход?
Можно перейти от LUN/VMFS, рассмотренных выше, к LUN/RDM. То есть каждой виртуальной машине мы цепляем свой, созданный специально для нее LUN (или, чаще, два LUN. Один под систему, второй под swap и temp или /var). Казалось бы, мы решаем проблему с недостаточной гранулярностью восстановления, так как в данном случае мы сможем восстановить любой желаемый виртуальный диск, любой виртуальной машины по выбору.

Однако это хорошо работает только при сравнительно небольшом количестве виртуальных машин. Во первых, “датацентр” VMware, включающий в себя все входящие в него ESX-сервера, объединенные процессом VMotion, ограничен в количестве используемых на нем LUN-ов числом 254 LUN-а.
Да и управление, например, двумя-тремя десятками виртуальных машин, каждая по два-три LUN в RDM, все эти LUN, как их не документируй, обязательно блудят и путаются. Решение для сильных духом и очень аккуратных админов.

Во вторых, мы в полный рост столкнемся с проблемой “заблудившихся LUN-ов”. Если наша виртуальная машина на одном из ESX-серверов использует LUN/RDM, то _все_ остальные ESX-сервера, входящие в “датацентр” будут видеть этот LUN как неиспользуемый, не понимая, что это RDM LUN для виртуальной машины. ? существует весьма серьезная опасность, что однажды вы его таки отформатируете как незадействованный, в VMFS, вместе со всем его содержимым. Спрятать его нельзя, так как он должен быть доступен всем входящим в “датацентр” серверам для работы VMotion и перемещении нашей виртуальной машины между хостами. Это на самом деле серьезная опасность.

Таким образом при использовании снэпшотов на NFS-томе вы можете получить гораздо более “гранулярный” и удобный в использовании результат как при бэкапе, так и при восстановлении.

Как, вы все еще думаете, использовать ли для вашего VMware наш NFS? ;)

NAS и SAN. Что это. Чем схоже и чем отличается.

Часто приходится сталкиваться с принципиальным непониманием у клиентов разницы между NAS и SAN-подключением внешнего дискового массива.

?так, что есть что, чем отличается друг от друга и какие плюсы-минусы у каждого.

NAS хорошо знаком большинству пользователей, использующих в локальной сети своей организации файловый сервер. Файловый сервер - это NAS. Это устройство, подключенное в локальную сеть и предоставляющее доступ к своим дискам по одному из протоколов “сетевых файловых систем”, наример CIFS (Common Internet File System) для Windows-систем (раньше называлась SMB - Server Message Blocks) или NFS (Network File System) для UNIX/Linux-систем.
Остальные варианты встречаются исчезающе редко.

SAN-устройство, с точки зрения пользователя, есть просто локальный диск.
Обычные варианты протокола доступа к SAN-диску это протокол FibreChannel (FC) и iSCSI (IP-SAN). Для использования SAN в компьютере, который хочет подключиться к SAN, должна быть установлена плата адаптера SAN, которая обычно называется HBA - Host Bus Adapter.
Этот адаптер представляет собой с точки зрения компьютера такую своеобразную SCSI-карту и обращается с ней так же, как с обычной SCSI-картой. Отсылает в нее команды SCSI и получает обратно блоки данных по протоколу SCSI. Наружу же эта карта передает блоки данных и команды SCSI, завернутые в пакеты FC или IP для iSCSI.

На приведенном рисунке вы видите 1 диск, подключенный с NAS-устройства (внизу), и один диск, подключенный по SAN по протоколу iSCSI.

Здесь мы видим, как SAN-диск виден в диспетчере устройств. Microsoft iSCSI Initiator это софтверный (программный) адаптер протокола iSCSI, представляющийся системе как SCSI-карта, через которую идет обмен данными с SAN-диском.
В случае FC на его месте находился бы HBA FC, он тоже является с точки зрения OS “SCSI-адаптером”.

Когда мы подключаем компьютер к SAN, нужно сделать rescan all disks и вскоре в Disk Manager появится новый неотформатированный раздел. На нем обычным образом можно создать партицию, отформатировать ее и получить локальный диск, который физически будет являться выделенным разделом на большой системе хранения и соединяться с компьютером оптическим кабелем FC или сетью gigabit ethernet в случае использования iSCSI.

Каковы же плюсы и минусы обеих этих моделей доступа к данным системы хранения?

  • NAS работает поверх локальной сети, используя обычное сетевое оборудование.
  • Он работает преимущественно с файлами и информацией, оформленной как файлы (пример: документы общего пользования, word- и excel-файлы).
  • Он позволяет коллективное использование информации на дисках (одновременный доступ с нескольких компьютеров).
  • SAN работает в собственной сети, для использования которой нужен дорогостоящий Host Bus Adapter (HBA).
  • Он работает на уровне блоков данных. Это могут быть файлы, но это могут быть и нефайловые методы хранения. Например база данных Oracle на т.н. raw-partition.
  • Для компьютера это локальный диск, поэтому коллективное использование информации на SAN диске обычно невозможно (или делается очень сложно и дорого).

Плюсы NAS:

  • дешевизна и доступность его ресурсов не только для отдельных серверов, но и для любых компьютеров организации.
  • простота коллективного использования ресурсов.

минусы NAS:

  • невозможно использовать “нефайловые” методы.
  • доступ к информации через протоколы “сетевых файловых систем” зачастую медленнее, чем как к локальному диску.

Плюсы SAN:

  • можно использовать блочные методы доступа, хранение “нефайловой” информации (часто используется для баз данных, а также для почтовой базы Exchange).
  • “низкоуровневый” доступ к SAN-диску обычно более быстрый, чем через сеть. Гораздо проще сделать очень быстрый доступ к данным с использованием кэширования.
  • Некоторые приложения работают только с “локальными дисками” и не работают на NAS (пример - MS Exchange)

Минусы SAN:

  • трудно, дорого или вовсе невозможно осуществить коллективный доступ к дисковому разделу в SAN с двух и более компьютеров.
  • Стоимость подключения к FC-SAN довольно велика (около 1000-1500$ за плату HBA). Подключение к iSCSI (IP-SAN) гораздо дешевле, но требует поддержки iSCSI на дисковом массиве.

?так, что же общего между этими двумя методами? Оба этих метода используются для “сетевого хранения данных” (networking data storage).

Что из них лучше? Единственного ответа не существует. Попытка решить задачи NAS с помощью SAN-системы, как и обратная задача, зачастую есть кратчайший путь потратить большие деньги без видимой выгоды и результата. Каждая из этих “парадигм” имеет свои сильные стороны, каждая имеет оптимальные методы применения.

20/0.124

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