Из текущих новостей:

Отменена пользовательская конференция NetApp Accelerate, подготовка к которой шла почти полгода. Костлявая рука мирового экономического кризиса вынуждает многие компании резать косты. Устраивать в таких условиях конференцию с фуршетами было бы по меньшей мере неразумно, а по большей - неэтично. Жаль, конечно, обычно это место для копании выкатить "много вкусного".

Вот, например, объявленная на днях выкатка для широкой публики VTL OS 6.0 c дедупликацией на системах VTL. Многострадальный проект, наконец-то, не настолько многострадальный, как Data ONTAP GX и "восьмерка", но все же больше года делали.
VTL в мире очень хорошо приняли, а такая "горячая тема" как дедупликация, причем ориентированная именно на бэкап, только прибавит им популярности.

Очень важный пост обнаружен в блоге Скотта Лоу за 18 октября. Найдена критическая ошибка в рекомендациях по использованию VMware на NFS NetApp-а. В текущей версии (от сентября) эта рекомендация уже поправлена авторами, но если вы используете VI на NFS, и при его настройке пользовались ранней версией этого Best Practices, в том числе той, которую я перевел для Верисел, обязательно, ОБЯЗАТЕЛЬНО прочтите этот пост и рекомендации по исправлению.
Ошибка взаимодействия (НЕ ошибка NetApp), после установки патча, с изменениями в настройках VI, и использование ранее рекомендованного выключения NFS Lock может привести к split brain в VMware VI.  

В нашу переведенную версию мы также внесем правки в ближайшие дни, о чем я объявлю отдельно.

Вот кратко перевод:

"…Проблема по видимому находится в некоторых (ныне отмененных) рекомендациях NetApp при использовании NFS с VMware ESX. В июне этого года NetApp рекомендовал в своем документе TR-3428, “NetApp and VMware Virtual Infrastructure 3 Storage Best Practices”, чтобы пользователи выключали (disable) параметр NFS locking на системе хранения, устанавливая опцию NFS.Lock.Disable в 1. Версия  4.0 документа TR-3428, опубликованная в июне, содержит в себе эту рекомендацию.

Как я разобрался, эта рекомендация вызвана багом, который существовал в VMware ESX, и вызывал большие задержки при удалении VMware snapshots. Как workaround, NetApp рекомендовал устанавливать опцию NFS.Lock.Disable. После того, как VMware починила этот баг своим патчем, текущая версия TR-3428 (version 4.2, опубликованная в September 2008 и доступная с вебсайта NetApp) больше не содержит этой рекомендации по установке опции NFS.Lock.Disable.

К сожалению, пользователи, которые последовали на тот момент действующему best practices могли установить эту опцию, и, в таком случае, могут получать состояние “split brain”, при котором VM одновременно регистрируются и исполняются на нескольких хостах VMware ESX. Пользователи также могут находиться под угрозой, если они используют VMware и оказываются не защищены от isolation response (подробно позже, по мере анализа). У нас есть один крупный пользователь, столкнувшийся с этой проблемой, и еще один со схожими симптомами так что мы думаем, что причина та же.

Вот несколько важных моментов:

• Это не проблема NetApp, но это результат рекомендации от NetApp. В то время эта установка, я думаю, была необходима.
• В большинстве случаев VMы, работающие в условиях split-brain будут повреждены, и потребуется восстановление их из бэкапа.

Мы не единственные, кто столкнулся с этой проблемой:

VMWare and NFS on NetApp Filers

NFS Datastores and what was their BIG issue…

Ключевые моменты исправления ситуации таковы:

Если вы не поставили патч ESX350-200808401-BG, вы должны его поставить. Не ждите, поставьте его сейчас. Проверить, установлен ли он, можно командой esxupdate query | grep ESX350-200808401-BG 
Если вы использовали рекомендации NetApp по установке NFS.Lock.Disable, то смотрите инструкцию ниже (написана Rick Scherer и несколькими другими, спасибо им!) для исправления ситуации.

Инструкция по исправлению ситуации с NFS locking (включает установку патча):

1. Скачайте патч ESX350-200808401-BG
2. Выберите ESX server, на который вы установите патч
3. Используя VMotion смигрируйте запущенные VMы на другой нод VMware ESX
4. Установите этот патч на выбранный VMware ESX server
5. В настройках Advanced Configuration settings убедитесь, что NFS file locking разрешен (enabled) и NFS.Lock.Disable=0 (вы можете также использовать команду esxcfg-advcfg для этой установки)
6. Отредактируйте файл /etc/vmware/config добавив следуюшие строки:
   prefvmx.ConsolidateDeleteNFSLocks = "TRUE"
7. Запишите изменения в файле и перегрузите хост VMware ESX
8. С помощью VMotion переместите VMы назад на patched/NFS lock enabled/prefvmx enabled хост
9. Повторите эти шаги для каждого хоста в кластере

И еще раз, если вы не поставили ESX350-200808401-BG, пожалуйста сделайте это максимально быстро, и убедитесь, что NFS locking включен. Если вы ранее запрещали (disable) NFS locking, то следуйте шагам, описанным выше, и восстановите NFS locking, защитив себя от возможного split-brain в системе VI.