about NetApp

Процедура полного обновления OS и firmware системы хранения NetApp FAS

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

Загрузите с now.netapp.com:

• свежие прошивки для полок (all shelf firmware updates)
• свежие прошивки дисков (all disk firmware updates)
• прошвку firmware контроллера CFE
• новую версию DataONTAP
• документацию соответствующей версии DataONTAP

Рекомендуется: Сообщите в саппорт о том, что вы приступаете к обновлению. Сгенерируйте письмо в AutoSupport с темой Maintenance или Upgrade, иначе вы можете получить кучу открытых кейсов для вашей системы и обеспокоенные звонки из техподдержки “чего это у вас там все ребутится в кластере?”
( > option autosupport.doit maintenance )
На крайний случай просто временно выключите AutoSupport (не рекомендуется, можно забыть включить назад)
(> option autosupport.enable off)

Смонтируйте на вашем компьютере как сетевой диск ресурс \\filerA\c$ и \\filerB\c$
Данное монтирование (C$) возможно в том числе, если вы не используете и не имеете лицензию CIFS.
Аналогично это возможно и с NFS в случае Linux/UNIX.

Сделайте резервную копию содержимого c$\etc\ на обоих системах

Скопируйте эту резервную копию в папку c$\backup\etc_хх-хх-хххх

Распакуйте архив прошивок полок в etc\shelf_fw на обоих контроллерах filerA и filerB

Распакуйте архив прошивок дисков в etc\disk_fw на обоих контроллерах filerA и filerB

* Обновление прошивки полок

Войдите в админскую консоль системы хранения.

Проверьте текущую версию shelf firmware ( > sysconfig -v )

Войдите в режим с повышенными привилегиями ( > priv set advanced )

Запустите обновление прошивки полок ( > storage download shelf )
Этот процесс обновит прошивки всех дисковых полок системы. Если вы хотите обновить только какие-то определенные, то используйте команду
> storage download shelf adapter_number.

Согласитесь на обновление, нажмите “y” и Enter.

После завершения проверьте версию прошивки полок ( > sysconfig -v )

Выйдите из режима повышенных привилегий ( > priv set admin )

* Обновление прошивки дисков

Прошивки дисков автоматически обновятся во время перезагрузки, если новые версии на этот момент будут лежать в папке disk_fw. Чтобы предотвратить такое поведение, например в случае очень больших систем с большим количеством дисков, можно изменить следующую системную опцию:
( > options raid.background_disk_fw_update.enable), она может быть в состоянии on или off. Рекомендуется оставить ее в on.

* Обновление Data ONTAP

Проверьте соответствие вашей системы опуликованным для полученного релиза Data ONTAP. При необходимости обновить версии прошивок полок и дисков сделайте это как описано выше.
Проверьте разделы known problems and limitations сопровождающей релиз информации. Проверьте списики исправленных багов между вашей рабочей системой и обновляемой.

* Процесс обновления

Распакуйте полученные архивы с новым дистрибутивом OS на смонтированные диски C$ обоих контроллеров в соответствуюшие папки (\etc\boot). Если вы проделываете это из под Windows, то рекомендуется воспользоваться стандартным путем, запустив на локальной машине самораспаковывающийся архив дистрибутива Data ONTAP и указав смонтированный на локальную машину диск \\filer\c$, как это указано в подсказке распаковки.

Запустите установку обновления новой OS на обоих системах ( > download )

Проверьте состояние кластера ( > cf status ) чтобы быть уверенным, что кластерный файловер работает

Выполните перехват системой filerB сервисов системы filerA ( > cf takeover )
Это отправит filerA в перезагрузку

Во время перезагрузки filerA нажмите ( ctrl-c ) для входа в maintenance mode
Вы должны делать это подключенным консольным кабелем к системе хранения, или через RMC (Remote Management Controller).

Находясь в maintenance mode наберите ( > halt ) чтобы выполнить полную перезагрузку

Нажмите ( del ) во время теста памяти, чтоы получить консоль CFE

Запустите прошивку нового firmware в flash командой CFE ( CFE> update_flash )

Перезагрузитесь командой ( bye ) на консоли и дождитесь завершения нормальной загрузки OS системы хранения filerA
Система filerA должна находиться в состоянии …waiting for giveback state

Для возвращения кластерных ресурсов на filerA мы должны дать команду
( > cf giveback –f ) с консоли filerB
Это необходимо сделать вручную, так как у нас сейчас различные версии Data ONTAP на контроллерах кластера.

После завершения giveback, проверьте версию прошивки и OS системы filerA
( > sysconfig –v )

После проверки успешности обновления повторяем действия с системой filerB:

Система filerA перехватывает сервисы filerB ( > cf takeover –n )

Наберите ( > halt ) в консоли filerB для перезагрузки

Во время перезагрузки filerB нажмите ( ctrl-c ) для входа в maintenance mode.
В maintenance mode наберите в консоли ( > halt ) для выполнения полной перезагрузки.
Нажмите ( del ) по время тестирования памяти чтобы получить консоль CFE.
Запустите обновление firmware командой ( CFE> update_flash )

Введите ( bye ) в консоли после завершения перепрошивки и выполните перезагрузку filerB

Если система filerB находится в состоянии …waiting for giveback state сделайте ручной giveback ( > cf giveback –f ) с контроллера filerA
Если процесс giveback завершен успешно, проверьте firmeware и версию OS на filerB при помощи ( > sysconfig –v )

Обе системы полностью обновлены.

Статья “Уменьшение стоимости хранения за счет экономии дискового пространства” о использовании сравнительно новой и все еще пока малоизвестной опции Space Reclamation в SnapDrive.

Статья “Oracle на NFS”, о некоторых аспектах все еще пока не слишком распространенного способа хранения данных баз Oracle на NAS-системе, с использованием NFS.

О плюсах и преимуществах использования дедупликации NetApp в задачах построения катастрофоустойчивых конфигураций на VMware Virtual Infrastructure.

О некоторых аспектах отказоустойчивого использования Exchange 2007 и его встроенных средств репликации LCR и CCR.

Вторая часть серии про работу Oracle на NetApp, на этот раз на FC.

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

Руководство Best Practices по развертыванию хранилища MS Exchange 2007 SP1 на системе хранения NetApp.

Статья о том, почему при использовании Oracle на системах NetApp протокол доступа, FC, iSCSI или NFS, на самом деле не важен, и как добиться этого.

Руководство по интеграции средств системы NetApp VTL и ПО NetBackup Vault.

Статья “A-SIS созрела”, о том, как устроена, как работает, и что может вам дать технология дедупликации в системах хранения NetApp.

Статья о трех задачах резервного копирования в VMware, и как можно их решить с использованием средств предлагаемых NetApp.

О использовании систем хранения NetApp для резервного копирования Disk-to-Disk, и какие преимущества имеет такая система перед традиционными решениями.

О том, как создавалась FAS3100, какие цели были поставлены, и как удалось создать экономически эффективную систему хранения midrange-класса.

А подписаться на получение новых выпусков можно на странице компании Verysell Distribution.

В Москве, во вторник, 23 сентября, Verysell проводит семинар по тематике Symantec и NetApp. Заходите, может быть интересно.
Тема Symantec: NetBackup for UNIX (NBU) и Veritas Cluster Server (VCS).
Подробную программу по NetApp не объявляли, но судя по всему это будет обзор с вопросами-ответами.
От Симантека читает Алексей Казем, от НетАппа - Дмитрий Шишин.
Уровень слушателей: базовый.

Прекрасная возможность потиранить вопросами “первоисточники”.

Дата мероприятия: 23 сентября 2008 года
Время проведения: 11:00 – 16:00
Место проведения: г. Москва, ул. Новопоселковая, д.6 корп. 2.
Continue reading ‘Семинар Verysell в Москве: Symantec и NetApp’ »

Любопытные цифры приведены в аналитическом отчете ESG (Enterprise Strategy Group Inc.), опубликованном в начале этого года (доступен на сайте NetApp).

Более половины (54%) из 329 опрошенных ответило, что, после внедрения решеня серверной виртуализации, объемы хранения увеличились (причем ответ “свыше 20%” дали 18% от этого количества).

68% ответивших считают, что FibreChannel есть “технология, предлагающая максимальную производительность” (и всего 22% ответили так для NFS).

Всего 19% считают о NFS, что она “наилучшим образом оптимизирована для задач виртуализации серверов” (против 49% FC и 45% iSCSI)

При этом среди тех, кто уже использует то или иное решение, ситуация обратная.
“Мы уже используем эту технологию и она нас полностью устраивает” 65% назвали NFS, и уже только 53% FC.

Еще несколько деталей о NFS, чаще неспецифических для NetApp, но не менее важных и интересных.

Очереди Ввода-вывода.

Если вы используете в качестве datastore LUN под VMFS, то ввод-вывод вашего ESX, неважно FC или iSCSI, будет ограничен одной очередью ввода-вывода на LUN, для всех VM хранящих свои виртуальные диски в VMFS data store на нем. Ведь ESX обращается к одному единственному LUN, с точки зрения ввода-вывода это одно SCSI-устройство, и параллельность ввода-вывода тут невозможна или очень ограничена.
В случае NFS вы можете использовать произвольное количество очередей ввода-вывода. Каждая VM, хранящая свои виртуальные диски на data store на NFS-шаре, будет иметь индивидуальную и независимую от других очередь ввода-вывода (IO queue).

VMFS LUN. Одна очередь ввода-вывода ко всем VM на data store.

NFS Data Store. Каждая VM имеет собственную очередь ввода-вывода.

Bandwidth Is not a Speed

В значительном количестве случаев при переходе с FC на NFS вы, как ни странно, можете даже выиграть в скорости.
“Как же так?” - наверняка спросите вы, “Ведь всем известно, что скорость FC это 4 GB/s, а NFS в случае 1GB Ethernet работает на 1GB/s, значит NFS просто обязана работать вчетверо медленнее!”
Ответить нетрудно. “Полоса пропускания” (англ. “bandwidth”) не равно “Скорость” (англ. “Speed”). ??, к слову, не всегда равно “Производительность” (англ. “Performance”). Смешивать эти понятия будет большой ошибкой.
Я уже писал об этой “смысловой коллизии” раньше, процитирую себя вкратце:

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

Ввод-вывод VMware ESX производится мелким блоками (4-8kb), и при этом предельно рандомно (что неудивительно для системы, хостящей множество независимых процессов множества виртуальных машин). При таком характере ввода-вывода роль играет не bandwith интерфейса, а его латентность и производительность в IOPS. А вот тут уже NFS имеет очень хорошие показатели, за счет чего и выигрывает в этих гонках. Так что, если при переходе с 4Gb/s FC на 1Gb/s NFS вы еще и выиграете в производительности, то не ищите, где же вы ошиблись. Это вполне вероятный поворот дела.

Увеличивать и уменьшать datastore без необходимости ковырять приложения и ESX.

??нтересной особенностью использования datastore на NFS-томе NetApp является то, что вы можете не только увеличивать его размер, но, при необходимости и уменьшать, причем и то и другое без какого-либо колдовства с сервером ESX или виртуальными машинами, чтобы они могли это увидеть и использовать.
Если увеличение это частая и в целом довольно обычная процедура, то вот уменьшение для LUN задача не из простых, а порой и вовсе нерешаемая.
Зато для NFS-тома NetApp вы вольны делать изменение в обе стороны.

На днях закончил перевод документа “NetApp and VMware VI3 Best Practices Guide”.

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

Архив уже вышедших публикаций доступен в виде PDF, по ссылке в колонке справа, “Русскоязычные документы”.

Следующий текст: “Руководство владельца NetApp” – мануал по сервису “для владельца”. Как настроить Autosupport; куда и как звонить если “все сломалось”; какие данные подготовить перед звонком в поддержку, чтобы не бегать в серверную, не искать где там на корпусе серийник; как правильно обновлять прошивку и версию DataONTAP, и так далее. Мне, в свое время, такого сильно не хватало. :)

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

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

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

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

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

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

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

Если вы используете “классический метод” подключения 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? ;)

Начиная с версии 3.0 флагманский продукт компании VMware - ESX Server поддерживает три типа подключения внешней дисковой системы: FC, iSCSI и NFS.
На сегодняшний день примерно 90% инсталляций VMware используют FC. В оставшихся 10% царит iSCSI, а на долю NFS пока приходится совсем малое количество систем.
Отчего так?

Причин я вижу две. Во первых, поддержка подключения дисковых систем хранения по NFS появилась только в ESX 3, то есть сравнительно недавно. А enterprise-сисадмины существа подозрительные, недоверчивые, злопамятные и консервативные (привет, коллеги!).
?? во вторых, в среде IT все еще довлеет мнение, что NAS “это что-то такое несерьезное, коробка от списанного сервера под столом, с виндой или линуксом, для хранения экселевских файлов нашей бухгалтерии и mp3-шек”, устройство, с обычным названием, хорошо отражающим отношение к ней сисадмина - “файлопомойка”. Какое там enterprise, работает и ладно.
Однако с известных пор, и стараниями известной вам компании, все это уже не совсем так.

Как это сделано:

Если у вас есть NAS работающий по NFS, например любой NetApp, или, возможно, EMC Celerra (хотя, как вы догадываетесь, и не все NAS “одинаково полезны”), то вы можете подключить созданный на нем дисковый ресурс как “сетевой диск” по протоколу NFS.

При этом вы НЕ используете VMFS (собственную файловю систему VMware для ее datastores), вы НЕ создаете LUN и НЕ монтируете эти LUNы ни в ESX (традиционный способ VMFS/LUN), ни в виртуальную машину (способ RDM/LUN - Raw Disk Mapping).
Вы получаете для своего ESX “сетевой диск”, и просто размещаете на нем файлы виртуальных дисков vmdk и vmx так, как будто это локальный диск вашего ESX, отформатированный в VMFS.

Странно и необычно? Только на первый взгляд. Просто воспринимайте этот “NFS-диск” как локальный. “А как же VMFS?”. Такие ее ключевые функции как, например, “кластерность”, то есть множественный доступ к ее разделу с разных виртуальных машин - обычная и традиционная функция NFS как сетевой файловой системы.

?? все? ?? все.

Чем вы платите:

1. Примерно, в среднем, 5% производительности на дисковых операциях.

2. Примерно, в среднем, 5% большей загрузкой процессоров хост-серверов ESX.

?? то и другое приведено на максимально возможной и максимально тяжелой тестировочной нагрузке, заметно превышающей существующую в реальной жизни.
Официальные результаты сравнения быстродействия протоколов от VMware тут: http://www.vmware.com/files/pdf/storage_protocol_perf.pdf
Там много интересных подробностей, но если лень читать - примите вышеприведенные цифры.
Чуть более подробный документ, совместное исследование той же темы NetApp-ом и VMware тут: http://media.netapp.com/documents/tr-3697.pdf

Что вы получаете (плюсы):

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

2. Эффективное “умное” кэширование, в том числе и с использованием PAM (Performance Acceleration Module).

3. Легкое управление: создание, удаление, перенос, резервное копирование и восстановление.

4. Отказоустойчивость и “многопутевость” подключения, обеспечиваемая отказоустойчивостью IP.

5. В ближайшей перспективе возможность использования 10Gb Ethernet. (Ну, как “в перспективе”. Купить 10Gb, в том числе и порты расширения этого стандарта в NetApp вы можете уже сейчас, разве что это пока все же дороговато. Хотя, наверное, не намного дороже, чем перейти на 8Gb FC. А то может и дешевле уже.)

6. В еще большей перспективе вы можете использовать сверхвысокопроизводительную многоузловую grid-систему Data ONTAP GX, которая сейчас уже доступна и работает в качестве NFS NAS (но пока очень ограниченно применима как SAN).

Что вы не получаете (минусы):

1. Вы, скорее всего не сможете использовать VCB (VMware Consolidated Backup) - автономную бэкап-систему VMware ESX.
Довольно сомнительный на мой взгляд недостаток, учитывая примитивность самого VCB, с учетом наличия при этом, как альтернативы, снэпшотов и SMVI. Но вдруг кто-то себе жизни не видит без него.
Также в блоге Ника Триантоса описывается остроумный способ “псевдо-VCB” - просто смонтировать файлы vmdk как разделы в linux-машине и, при наличии утилиты чтения NTFS, вы сможете делать пофайловый бэкап содержимого даже и windows-разделов.
Также обратите внимание, что работа по NFS, с недавних пор, стала доступна для VCB, входящего в версию 3.5, но есть ограничения.

2. Вы не сможете использовать внутри виртуальных машин MSCS - Microsoft Cluster Services - кластерную систему Microsoft. Ей нужны RDM(Raw Disk Mapping)-диски, то есть LUN-ы подключеные внутрь VM как raw-диски. Зачем нужен MSCS при наличии VMotion, HA и DRS? Ну может MSCS у нас бесплатен (в составе MS Windows Server Enterprise), а лицензия VMware HA за деньги, или мы по каким-то внутренним причинам переносим без изменений в виртуальную инфраструктуру физическую серверную систему на MSCS, почем знать.

В обоих этих случаях вы можете совместить NFS и LUN-ы SAN. Выбор одного варианта не отбирает и не запрещает вам второй.

Частый вопрос:
Q: “Будет ли это все работать у меня, если мои виртуальные сервера - Windows?”
A: “Да, к NAS, с дисками по NFS, подключается не “гостевая” виртуальная OS, а сам ESX. А для гостевых OS диски, получаемые ESX-ом c системы хранения, выглядят как локальное пространство дисков ESX-сервера, и с NFS как таковым виртуальные машины дела не имеют, все для них уже сделал ESX. Ваша виртуальная машина создает диск, и вы получаете на NFS-томе обычные файлы vmdk, словно это локальный диск ESX под VMFS”.

Характерный комментарий к одному из постов на эту тему:
“Dan Pancamo said:
950 VMs across 35 ESX servers. ALL on Netapp over NFS for more than a year now. FC/iSCSI? No thanks!”

Ну что, убедил посмотреть тему повнимательнее и пересмотреть предубеждения?

Еще почитать на тему:

Nick Triantos, один из разработчиков NetApp
VMware over NFS (07.09.2007)

Обзор Gartner:
Choosing Network-Attached Storage for VMware: What You Should Know

Mark Mayo
VMware Server and NFS? Am I alone?

Chuck Hollis, Вице-президент EMC по технологическим альянсам, вечный оппонент Хитца, который никогда не упустит в своем блоге возможности злобно куснуть NetApp ;), придерживается того же мнения:
Storage Protocols and VMware (4.12.2007)
VMware Virtual Infrastructure 3 – Climbing The Mountain (21.12.2006)

Ничего удивительного, ведь NAS продают и EMC.
Using EMC Celerra IP Storage with VI3 over iSCSI and NFS.

Dan Pancamo
Why VMware over Netapp NFS

Ну и наконец еще раз упомяну на мой взгляд интереснейший, полезнейший и очень активно пополняющийся блог Михаила Михеева, преподавателя по теме VMware VI в УЦ Микроинформ. Если вы занимаетесь VMware, то имеет смысл на него подписаться, множество важной и интересной информации собранной “на просторах” там публикуется.
Вот, например, все о теме NFS: http://www.vm4.ru/search?q=NFS

Ну что-ж. Так и не уложил в один пост всю тему. To be continued.