Как избежать того, чтобы VMware оглушала клиента во время создания образа с помощью Veeam
Недавно наш сервер MySQL «ушел» (т. Е. Разрывается клиентское соединение). После нескольких недель попыток различных вещей (например, настройки размера пакета) мы обнаружили, что именно наши резервные копии образов Veeam используют API VMWare для создания моментальных снимков и копирования виртуальных машинных компьютеров и т. Д.
Мы используем ESXi 5 с гостевой системой Centos 6.4, работает (в значительной степени) только MySQL 5.1.69-log.
Изменение, которое, казалось, инициировало эту проблему, заключалось в увеличении размера физического диска до 300 ГБ с примерно 100 и изменении размера гостевой файловой системы для использования большей части новой емкости. С тех пор, как диск был увеличен, мы Эти проблемы возникают во время резервного копирования - предположительно из-за увеличения времени, необходимого для выполнения функций, связанных со снимками.
Новые диски - 2x300 ГБ Gen8 15k SAS в RAID1. Старые диски были бы похожи только поменьше. Целью процесса Veeam является ReadyNAS через выделенный Ethernet-порт 1 Гб (т.е. отделенный от общего офисного трафика).
Хост - башня HP DL380P:
==server spec (BASE CHASSIS)==
SERIES DL380P GEN8
PROCESSOR TYPE Intel Xeon E5-2609 v2 (2.5GHz/4-core/10MB/6.4GT-s QPI/80W)
NUMBER OF PROCESSORS 2
MEMORY 80GB
INTERNAL DRIVE BAYS 8 SFF HDD Bays
COMPATIBLE HDD SFF SAS/SATA
HARD DISK CONTROLLER SMART ARRAY P420I/ZERO MEMORY CONTROLLER (RAID 0/1/1+0)
Мой "ИТ-специалист" внес несколько изменений в Veeam config, включая пропуск пустых блоков (большая часть нового диска пуста), но это, похоже, не помогло.
Veeam тоже не сильно помог, сказав «перезагрузите цель» или «мы просто используем API VMWare ».
Я считаю, что« оглушение »означает, что виртуальная машина просто зависает на время (около 30 секунд), а затем продолжает работать нормально.
Пример VMWare.log:
Line 7411: 2016-06-08T17:11:44.910Z| vcpu-0| I120: Checkpoint_Unstun: vm stopped for 21068381 us
Line 7556: 2016-06-08T17:22:24.608Z| vcpu-0| I120: Checkpoint_Unstun: vm stopped for 19819322 us
Line 7700: 2016-06-08T17:22:30.140Z| vcpu-0| I120: Checkpoint_Unstun: vm stopped for 1130044 us
Line 7929: 2016-06-08T17:23:08.616Z| vcpu-0| I120: Checkpoint_Unstun: vm stopped for 30197618 us
Итак, у моей проблемы есть два вероятных решения:
Есть ли способ предотвратить или уменьшить «оглушение» гостевой системы VMWare во время создания образа.
Есть ли способ уменьшить влияние оглушения на MySQL или виртуальная сеть или Centos.
Это сервер HP ProLiant, работающий с RAID-контроллером Smart Array без кэш-модуля с флэш-памятью.
В результате, у вас нет кэша записи ( или чтения кэша), и от этого страдают такие операции, как снимки виртуальных машин. Вы испытали на себе эффект от этого. Текущая конфигурация не подходит для большинства рабочих нагрузок, особенно для виртуализации.
Вашим лучшим вариантом будет просто купить кэш-модуль и батарею/FBWC; HP parts 631681-B21, 631679-B21, или 631069-B21.
Это ускорит производительность и устранит проблему, которую вы видите.
Также смотрите:
FBWC и контроллер нулевой памяти (ZM) RAID на HP DL360p
BBWC: теоретически это хорошая идея, но сохранил ли он когда-нибудь ваши данные?
Ответы на мой собственный вопрос из исследования. (Я приму свой собственный ответ только в том случае, если один из этих подходов действительно сработает и это будет до чьего-то предложения)
В этой (более старой) статье ЧТО ОПАСНОСТЬ СНАФОТОВ И КАК ОПАСИТЬ? упоминается о нескольких возможных причинах и трех мерах предосторожности. Интересно, что в статье упоминается о том, как эта проблема аналогичным образом влияет на MS SQL Server и другие серверные продукты.
Если вы не хотите оглушать / приостанавливать работу виртуальной машины, вы можете установить snapshot.maxIterations на 20 (или выше). Это означает, что vSphere будет делать больше попыток (итераций) для фиксации файлов снимков. Более подробная информация в этой статье KB.
Затем она описывает риски и недостатки этого подхода.
Во-вторых, она предлагает:
Альтернативно можно установить snapshot.maxConsolidateTime на 60 секунд. Это означает, что вы можете принять паузу виртуальной машины на 60 секунд. секунд на синхронную консолидацию. Часто это лучший вариант чем ждать, пока файл снимка вырастет настолько большим, что виртуальная машина будет требуют оглушения гораздо дольше.
Но я не знаю, чем отличается "оглушение" от "паузы".
И напоследок:
ESXi 4.1 имеет обновление, которое добавило параметр snapshot.asyncConsolidate.forceSync = "FALSE", который необходимо добавить. к файлу VMX. Эта настройка отключает синхронную консолидацию и виртуальная машина никогда не будет ошеломлена. Больше информации в этом KB.
Он не описывает потенциальные недостатки этих решений, но я бы предположил, что они есть, иначе они будут по умолчанию.
Я еще не проверил, актуальны ли эти параметры или решения в v5.
UPDATE: Veeam рекомендовал внести вышеуказанные изменения, перечисленные в этом KB, которые актуальны в v4 и v5 ESXi.При удалении снимка виртуальные машины становятся невосприимчивыми более 30 минут (2039754)
UPDATE2: Мы вносим эти изменения в конфигурацию сегодня вечером и перезагружаем хост, так как это дешевле и быстрее, чем ждать кэш-памяти. Затем мы проконтролируем в течение нескольких дней, чтобы посмотреть, разрешит ли это только для нас.