??з текущих новостей
Отменена пользовательская конференция 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 HA и оказываются не защищены от 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 (включает установку патча):
- Скачайте патч ESX350-200808401-BG
- Выберите ESX server, на который вы установите патч
- ??спользуя VMotion смигрируйте запущенные VMы на другой нод VMware ESX
- Установите этот патч на выбранный VMware ESX server
- В настройках Advanced Configuration settings убедитесь, что NFS file locking разрешен (enabled) и NFS.Lock.Disable=0 (вы можете также использовать команду esxcfg-advcfg для этой установки)
- Отредактируйте файл /etc/vmware/config добавив следуюшие строки:
prefvmx.ConsolidateDeleteNFSLocks = "TRUE" - Запишите изменения в файле и перегрузите хост VMware ESX
- С помощью VMotion переместите VMы назад на patched/NFS lock enabled/prefvmx enabled хост
- Повторите эти шаги для каждого хоста в кластере
?? еще раз, если вы не поставили ESX350-200808401-BG, пожалуйста сделайте это максимально быстро, и убедитесь, что NFS locking включен. Если вы ранее запрещали (disable) NFS locking, то следуйте шагам, описанным выше, и восстановите NFS locking, защитив себя от возможного split-brain в системе VI.
Оставить комментарий