В последнее время наш сервер MySQL «уходит» (т. Е. Пропадает клиентское соединение). После нескольких недель экспериментов (например, с настройкой размера пакета) мы обнаружили, что именно наши резервные копии изображений Veeam используют API VMWare для создания моментальных снимков и копирования виртуальных машин VMDK и т. Д.
Мы используем 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, включая пропуск пустых блоков (большая часть нового диска пуста), но это, похоже, не помогло.
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 631681-B21, 631679-B21 или 631069-B21.
Это повысит производительность и устранит проблему, которую вы видите.
Также см:
RAID-контроллер FBWC и Zero Memory (ZM) на HP DL360p
BBWC: теоретически хорошая идея, но сохранял ли кто-нибудь ваши данные?
Отвечая на свой вопрос из исследования. (Я приму свой собственный ответ только в том случае, если один из этих подходов действительно работает, и он предшествует чьему-либо предложению.)
Эта (более старая) статья КАКОВЫ ОПАСНОСТИ СНИМКОВ И КАК ИЗБЕЖАТЬ? упоминает несколько возможных причин и три профилактических меры. Интересно, что в нем упоминается, как проблема аналогичным образом влияет на MS SQL Server и другие серверные продукты.
Если вы не хотите останавливать / останавливать виртуальную машину, вы можете установить snapshot.maxIterations на 20 (или выше). Это означает, что vSphere будет делать больше попыток (итераций) для фиксации файлов моментальных снимков. Дополнительная информация в этой статье базы знаний.
Затем описываются риски и недостатки этого подхода.
Во-вторых, это предполагает:
В качестве альтернативы вы можете установить snapshot.maxConsolidateTime на 60 секунд. Это означает, что вы можете принять паузу виртуальной машины на 60 секунд, чтобы выполнить синхронную консолидацию. Часто это лучший вариант, чем ждать, пока файл моментального снимка вырастет до такого размера, что виртуальную машину потребуется отключить на гораздо более длительное время.
Но я не знаю разницы между «оглушением» и «паузой».
И наконец:
ESXi 4.1 имеет обновление, в которое добавлен параметр snapshot.asyncConsolidate.forceSync = «FALSE», который необходимо добавить в файл VMX. Этот параметр отключает синхронную консолидацию, и виртуальная машина никогда не будет отключена. Больше информации в этом КБ.
В нем не описываются потенциальные недостатки этих решений, но я предполагаю, что они есть, иначе они будут использоваться по умолчанию.
Я еще не проверил, актуальны ли эти параметры или решения в v5.
ОБНОВЛЕНИЕ: Veeam рекомендовала внести вышеупомянутые изменения, перечисленные в этой базе знаний, которые актуальны для версий v4 и v5 ESXi.При удалении моментального снимка виртуальные машины перестают отвечать на запросы более 30 минут (2039754)
ОБНОВЛЕНИЕ 2: Мы вносим эти изменения конфигурации сегодня вечером и перезагружаем хост, так как это дешевле и быстрее, чем ждать кеша. Затем мы будем следить в течение нескольких дней, чтобы увидеть, решит ли это одно только это за нас.