VMware ESXi: приостановка процесса виртуальной машины (для разрешения перезапуска хранилища NFS), какие-либо побочные эффекты для баз данных, AD, особые случаи?

Ситуация:

На интегрированном сервере All-In-One ESXi / ZFS-Storage, где виртуальная машина хранения использует голые металлические диски и экспортирует файловые системы через NFS (или iSCSI) обратно в ESXi, который использует его в качестве хранилища пула для других виртуальных машин, существует проблема, когда приходит время обновить виртуальную машину хранилища, потому что от нее зависят многочисленные запущенные виртуальные машины, и время ожидания истекает из-за NFS.AllPathsDown или по аналогичным причинам, что эквивалентно извлечению диска из обычного сервера без его выключения.

Конечно, можно выключить все виртуальные машины, но это занимает очень много времени, а также утомительно (или требует написания сценария). Перемещение виртуальных машин на другой хост может быть возможным, но занимает еще больше времени и может оказаться невозможным в небольших установках, где достаточно одной машины. Приостановка виртуальных машин может работать, но также довольно медленно (иногда медленнее, чем выключение).

Возможные решения...

Кажется, что простое, но эффективное решение - остановить процессы виртуальной машины через CLI с участием kill -STOP [pid] найдя это с ps -c | grep -v grep | grep [vmname], выполните обновление / перезапуск виртуальной машины хранения, затем продолжите выполнение процессов виртуальной машины, используя kill -CONT [pid].
Подобным решением может быть комбинация быстрая перезагрузка (доступно на Solaris / illumos через reboot -f или в Linux через kexec-reboot), который занимает секунды вместо минут, и тайм-аут NFS в ESXi (при потере соединения NFS все операции ввода-вывода приостанавливаются, я думаю, на 120 секунд, пока предполагается, что хранилище не работает навсегда). Если время перезагрузки находится внутри окна ESXi NFS, оно теоретически должно быть сопоставимо с диском, который не отвечает в течение минуты из-за исправления ошибок, но затем возобновляет нормальную работу.

... а проблемы?

Теперь мои вопросы:

Какой метод предпочтительнее, или они одинаково хороши / плохи?
Каковы непредвиденные побочные эффекты в особых случаях, таких как базы данных, контроллеры Active Directory, машины с пользователями, выполняющими задания и т. Д.?
Где нужно быть осторожным? В комментарии к связанному блогу упоминаются проблемы с хронометражом, которые могут возникнуть, например, при зависании ЦП.

Изменить: чтобы уточнить объем этого вопроса

Получив первые два ответа, я думаю, что сформулировал свой вопрос недостаточно ясно или упустил слишком много информации для краткости. Мне известно следующее:

Он не поддерживается ни VMware, ни кем-либо еще, не делайте этого!: Я не упомянул об этом, потому что первая ссылка уже говорит об этом, и я бы не стал спрашивать, управлялась ли эта машина службой поддержки VMware. Это чисто технический вопрос, поддержка здесь не рассматривается.
Если вы разрабатываете новую систему сегодня, некоторые вещи можно было бы сделать другими способами.: Верно, но так как система стабильно работает в течение нескольких лет, я предпочитаю не выбрасывать ребенка вместе с водой из ванны и начинать совершенно заново, привнося новые проблемы.
Купите оборудование X, и у вас не будет этой проблемы! Правда, я мог бы купить 2 или 3 дополнительных сервера с аналогичной стоимостью и иметь полную настройку высокой доступности. Я знаю, как это делается, это не так сложно. Но здесь не такая ситуация. Если бы в моем случае это было жизнеспособным решением, я бы вообще не задавал этот вопрос.
Просто примите задержку выключения и перезагрузки: Я знаю, что это возможно, поскольку я этим занимаюсь сейчас. Я задал вопрос, чтобы найти лучше альтернативы в рамках текущей настройки или узнать о обоснованный по техническим причинам, некоторые из описанных методов будут иметь проблемы - «это непредсказуемо» без каких-либо объяснений, почему это не обоснованный ответ в моей книге.

Поэтому, перефразируя вопросы:

Какой из этих двух методов технически предпочтительнее и почему, если предполагается, что настройка исправлена, а цель состоит в том, чтобы сократить время простоя без каких-либо отрицательных побочных эффектов для целостности данных?
Каковы непреднамеренные побочные эффекты в особых случаях, например:
- активные / незанятые / неактивные базы данных с пользователями и / или приложениями, обращающимися к ним
- Контроллеры Active Directory на этом компьютере и / или на других машинах (в том же домене)
- машины общего назначения, работающие на холостом ходу, или когда пользователи выполняют задания или выполняют задания автоматического обслуживания, такие как резервное копирование
- устройства, такие как мониторинг сети или маршрутизаторы
- сетевое время с использованием или без использования NTP на этом сервере, на другом или на нескольких серверах
В каких особых случаях этого не рекомендуется делать, потому что недостатков больше, чем преимуществ? Где нужно быть осторожным? В комментарии к связанному блогу упоминаются проблемы с хронометражом, которые могут возникнуть, например, при зависании ЦП, но не приводятся какие-либо аргументы, доказательства или результаты тестов.
Каковы фактические, технические различия между этими двумя решениями и
1. Замедленное выполнение процессов ВМ из-за перегрузки ЦП на хосте
2. Увеличено время ожидания дискового ввода-вывода из-за неисправных дисков или контроллеров, если оно ниже порога NFS?

Хороший вопрос...

Но зачем вообще нужно перезагружать сервер NFS?

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

Так...

Установите порядок запуска и выключения виртуальной машины (хорошо иметь место).

Вы можете выбрать несколько виртуальных машин, которые будут отключены или приостановлены одновременно. (Раньше я приостановить ВМ, когда я это сделал)

Делайте все, что вам нужно, с виртуальной машиной NFS.
Ешьте время простоя.

Если у вас не может быть такого простоя, вам не следует запускать универсальное хранилище и настраивать виртуальную машину или следует рассмотреть традиционное хранилище SAN. (или недорогая версия) и несколько хостов виртуальных машин.

Я предлагаю вообще избежать этой проблемы. Вы упомянули, что увеличение затрат и полная перестройка архитектуры являются препятствиями для демонстрации, но в этой ситуации вы могли бы подумать о том, чтобы иметь две виртуальные машины хранения на хосте в двухузловом отказоустойчивом кластере. Это позволит вам исправить любой из них (но не оба одновременно), не влияя на доступность NFS или iSCSI, обслуживаемых кластером. Это все еще не поддерживаемое решение, но оно, по крайней мере, обеспечивает некоторую гибкость в обслуживании за счет увеличения накладных расходов на ресурсы (в основном, сколько памяти вы отдаете второй виртуальной машине хранения) для хранения.

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

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

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

Наконец, если вы хотите приостановить процессы (и проверили, что это действительно работает), я настоятельно рекомендую вам сначала синхронизировать все диски в гостевой системе (в Linux это будет сделано с помощью / bin / sync. Предоставляемая утилита от SysInternals для Windows: http://technet.microsoft.com/en-us/sysinternals/bb897438.aspx) и выполняйте техническое обслуживание быстро, чтобы часы не переводились слишком далеко назад.

Что касается потенциальных побочных эффектов, любой компьютер, подключенный к AD, должен (по умолчанию) находиться в пределах 5 минут от времени DC. Поэтому после любого решения, при котором виртуальная машина не доступна постоянно, кроме обычного выключения, я бы посоветовал вам заставить возобновленную гостевую систему обновить свои часы. На серверах баз данных не делайте этого, когда сервер занят, поскольку это увеличивает вероятность повреждения файловой системы.

Главный риск во всех вариантах помимо обычного завершения работы или хранилища с высокой доступностью - это повреждение. В буфере потенциально может быть некоторый ввод-вывод, который будет удален, что приложение может ошибочно считать завершенным успешно. Что еще хуже, операции ввода-вывода могли быть переупорядочены на более низком уровне для более оптимальной схемы записи. Это может привести к тому, что данные будут частично записаны не по порядку. Возможно, счетчик строк был увеличен до того, как данные строки БД были записаны, или контрольная сумма обновилась до того, как данные контрольной суммы были физически изменены. Это можно смягчить, разрешив только синхронную запись в ваше хранилище, но за счет производительности.

Какой метод предпочтительнее, или они одинаково хороши / плохи?

Ни то, ни другое.

Это цена ужасного дизайна, я бы не ухудшил эту ситуацию, сделав что-нибудь, кроме выключения ваших виртуальных машин, работы с виртуальной машиной хранения и перезапуска других виртуальных машин. Я также попросил бы кого-нибудь перепроектировать вашу установку с использованием поддерживаемой / поддерживаемой архитектуры.

Каковы непредвиденные побочные эффекты в особых случаях, таких как базы данных, контроллеры Active Directory, машины с пользователями, выполняющими задания и т. Д.?

Это по своей сути непредсказуемо, то, что может случиться на этот раз, может не произойти, если вы сделаете это снова. Это недопустимо.

Где нужно быть осторожным? В комментарии к связанному блогу упоминаются проблемы с хронометражом, которые могут возникнуть, например, при зависании ЦП.

На это сложно ответить конструктивно.