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
Critical | about NetApp

Posts tagged ‘critical’

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

Отменена пользовательская конференция 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 (включает установку патча):

  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.

20/0.084

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