Vmware - постоянная консолидация

[ZhenyaKazakov]

Добрый день уважаемые знатоки.
Около 1.5 месяца столкнулся со следующей проблемой
Имеется сервер с установленным exsi 5.5.0 (рис 1)
http://imageshack.com/a/img924/7725/4G8MIn.jpg
Подключаюсь к нему через vSphere Client. Там установлено 2 виртуальные машины на безе ОС win srv
Так же по железу:
1tB ВИНТ
32gB оЗУ
Для 1 srv выделено - 302гб на винте и 9гб озу
для 2 srv выделено - 550гб на винте и 15гб озу
http://imageshack.com/a/img922/9572/G5tkPl.jpg
http://imageshack.com/a/img924/9121/20mqX1.jpg
http://imageshack.com/a/img923/7017/EhyjmR.jpg
Так же имплантировано NAS хранилище в которое скидываютс образа
http://imageshack.com/a/img924/6084/RQ1NXs.jpg
 
Вопрос в том что при запуске скрипта ghettoVCB 1 машина бэкапится и все норм, а следом вторая машина , так же бэкапится, но потом требует консолидацию сделать, и пока ее не сделаешь она не создает образ.
Настройки скипта
Хранить 3 образа
и высылать лог по почте
так вот пока не проведу консолидацию уведомление в почту не приходит
Ранее такова не было.
В чем может быть дело??
 
Заметил еще 1 особенность 2 машины
http://imageshack.com/a/img923/8414/K57xJT.jpg
Для 1 вм данные параметры одинаковы а для 2 нет
может ли из за этого быть? и как исправить?
Настройки скрипта не менялись, скрип работал около 3х лет исправно, настроек не каких не производилось.
Просто 2 вм стала просить консолидацию и после заканчивается бэкапт и приходит уведомление.
При этом если ребутнуть всю ESXI то 2 раза бэкап делается нормально, а потом снова просит консолидацию.
Может кто нибуть помочь?

[Finikiez]

Проверьте у проблемной ВМ наличие старых неудаленных снапшотов.

Это можно проверить посмотрев путь к виртуальному диску через Edit settings . Если в нем есть цифры вида 000001, 000002 и т.п. значит есть снапшоты.

Также посмотрите, видет ли snapshot manager какие-либо снапшоты.

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

Вторая рекомендация - на дворе 2017 год. Используйте какой-нибудь софт резервного копирования. Veeam с бесплатной лицензией или Nakivo.

[ZhenyaKazakov]

Все чисто. Снапшотов нету.

Дело в том что данный скрипт работает по расписанию, и вполне устраевает.

Всего 4 физических серверов, на которых 12 вм.

И только 1 что то парит мозг.

До этого на протяжении 3х лет такой проблемы не замечалось.

[Finikiez]

Тогда нужно вот что смотреть: запустить скрипт, получить ошибку и читать на ESXi vmkernel.log, hostd.log и vmware.log самой виртуальной машины.

Если есть возможность, приаттачте сюда логи, посмотрим вместе.

[ZhenyaKazakov]

Запустил руками скрипт следующим образом

vmfs/volumes/datastore1/ghettoVCB/ghettoVCB.sh -f vmfs/volumes/datastore1/ghettoVCB/vmslist -g vmfs/volumes/datastore1/ghettoVCB/ghettoVCB.conf -I

в vmslist указал только 1 машину с которой проблема

все забэкапилось норм

Но до этого удалил самый старый образ из папки куда скидывается.

т.е. там хранится 3 образа, и скрипт сам удаляет самый старый.

Может проблема что он не может удалить папку из за большого размера, там около 550гб  размер.

Попробую удалить самый старый образ в пятницу и что б в автомате запустилось все по расписанию.

Еще в расписании указаны немного другие ключи, но не даю что они как то влияют

/vmfs/volumes/datastore1/ghettoVCB/ghettoVCB.sh -a -g /vmfs/volumes/datastore1/ghettoVCB/ghettoVCB.conf

Т.е. бэкапить все машины а не из vmslist

Там их 2 всего и он бэкапит их по очереди, 1 машина бэкапится норм, но там размер около 350гб.

Где лежат данные логи: vmkernel.log, hostd.log и vmware.log

В понедельник гляну если вывалит опять ошибку и выложу суда.

[ZhenyaKazakov]

Вот логи нашел.Ссылка на майл облако.

https://cloud.mail.ru/public/62wH/zfekGNLYf

[Finikiez]

У вас вот такие ошибки консолидации были

2017-11-04T01:14:04.168Z [3E391B70 info 'Vmsvc.vm:/vmfs/volumes/527d839d-82a68002-4042-3464a995befc/ss02/SS02.vmx'] Consolidate Disks failed: vim.fault.GenericVmConfigFault

2017-11-04T01:14:04.168Z [3E391B70 verbose 'Vmsvc.vm:/vmfs/volumes/527d839d-82a68002-4042-3464a995befc/ss02/SS02.vmx'] Consolidate Disks message: The virtual machine has exceeded the maximum downtime of 60 seconds for disk consolidation.

--> Synchronous consolidate failed for scsi0:0: Operation was canceled.

--> An error occurred while consolidating disks: The operation failed.

-->

11 числа такая же

2017-11-11T01:12:44.267Z| vcpu-0| I120: SnapshotVMXConsolidateHelperProgress: Stunned for 64 secs (max = 60 secs). Aborting consolidate.

2017-11-11T01:12:44.267Z| vcpu-0| I120: DISKLIB-VMFS_SPARSE : Cancelling vmfs combine.

2017-11-11T01:12:44.267Z| vcpu-0| I120: SNAPSHOT: SnapshotCombineDisks: Failed to combine: Operation was canceled (33).

2017-11-11T01:12:44.278Z| vcpu-0| I120: DISKLIB-VMFS  : "/vmfs/volumes/527d839d-82a68002-4042-3464a995befc/ss02/ss02-000002-delta.vmdk" : closed.

2017-11-11T01:12:44.304Z| vcpu-0| I120: DISKLIB-VMFS  : "/vmfs/volumes/527d839d-82a68002-4042-3464a995befc/ss02/ss02-flat.vmdk" : closed.

2017-11-11T01:12:44.304Z| vcpu-0| I120: SNAPSHOT: Snapshot_ConsolidateWorkItem failed: Operation was canceled (5)

2017-11-11T01:12:44.304Z| vcpu-0| I120: SnapshotVMXConsolidateOnlineCB: Synchronous consolidate failed for disk node: scsi0:0. Adding it to skip list.

2017-11-11T01:12:44.311Z| vcpu-0| I120: SnapshotVMXConsolidateOnlineCB: nextState = 1 uid 0

2017-11-11T01:12:44.311Z| vcpu-0| I120: SnapshotConsolidateWorkItemArrayGet: Skipping node scsi0:0.

2017-11-11T01:12:44.311Z| vcpu-0| I120: Checkpoint_Unstun: vm stopped for 67148355 us

У вас слишком медленно идет консолидация дельта файла. Как видно, ВМ замораживается при синхронной консолидации и консолидация обрывается при достижении порога в 60 секунд.

Порог 60 секунд возникает из-за следующей настройки в конфигурации ВМ

snapshot.maxConsolidateTime = "30"

(с учетом коэффициента 2 = 60 секунд).

Факт в том, что консолидация у вас идет очень-очень медленно.

Line 2281: 2017-10-21T01:14:08.420Z| SnapshotVMXCombiner| I120: SnapshotVMXCalculateConsolidateRate: ConsolidateSize = 1210056704 bytes, consolidateTime = 789159090  usec, consolidateRate = 1.533350 MBps

    Line 2281: 2017-10-21T01:14:08.420Z| SnapshotVMXCombiner| I120: SnapshotVMXCalculateConsolidateRate: ConsolidateSize = 1210056704 bytes, consolidateTime = 789159090  usec, consolidateRate = 1.533350 MBps

    Line 3160: 2017-10-28T01:28:05.174Z| SnapshotVMXCombiner| I120: SnapshotVMXCalculateConsolidateRate: ConsolidateSize = 1025507328 bytes, consolidateTime = 990741771  usec, consolidateRate = 1.035090 MBps

    Line 3160: 2017-10-28T01:28:05.174Z| SnapshotVMXCombiner| I120: SnapshotVMXCalculateConsolidateRate: ConsolidateSize = 1025507328 bytes, consolidateTime = 990741771  usec, consolidateRate = 1.035090 MBps

    Line 4064: 2017-11-04T01:12:50.120Z| SnapshotVMXCombiner| I120: SnapshotVMXCalculateConsolidateRate: ConsolidateSize = 1059061760 bytes, consolidateTime = 789028547  usec, consolidateRate = 1.342235 MBps

    Line 4064: 2017-11-04T01:12:50.120Z| SnapshotVMXCombiner| I120: SnapshotVMXCalculateConsolidateRate: ConsolidateSize = 1059061760 bytes, consolidateTime = 789028547  usec, consolidateRate = 1.342235 MBps

    Line 4236: 2017-11-04T02:22:06.034Z| SnapshotVMXCombiner| I120: SnapshotVMXCalculateConsolidateRate: ConsolidateSize = 404750336 bytes, consolidateTime = 370855057  usec, consolidateRate = 1.091398 MBps

    Line 4236: 2017-11-04T02:22:06.034Z| SnapshotVMXCombiner| I120: SnapshotVMXCalculateConsolidateRate: ConsolidateSize = 404750336 bytes, consolidateTime = 370855057  usec, consolidateRate = 1.091398 MBps

    Line 5015: 2017-11-11T01:11:37.163Z| SnapshotVMXCombiner| I120: SnapshotVMXCalculateConsolidateRate: ConsolidateSize = 807403520 bytes, consolidateTime = 615314493  usec, consolidateRate = 1.312180 MBps

    Line 5015: 2017-11-11T01:11:37.163Z| SnapshotVMXCombiner| I120: SnapshotVMXCalculateConsolidateRate: ConsolidateSize = 807403520 bytes, consolidateTime = 615314493  usec, consolidateRate = 1.312180 MBps

    Line 5188: 2017-11-11T02:32:35.798Z| SnapshotVMXCombiner| I120: SnapshotVMXCalculateConsolidateRate: ConsolidateSize = 421527552 bytes, consolidateTime = 392020470  usec, consolidateRate = 1.075269 MBps

    Line 5188: 2017-11-11T02:32:35.798Z| SnapshotVMXCombiner| I120: SnapshotVMXCalculateConsolidateRate: ConsolidateSize = 421527552 bytes, consolidateTime = 392020470  usec, consolidateRate = 1.075269 MBps

Если вам не принципиально, что виртуальная машина замораживается на долгое время и недоступна при этом, вы можете просто увеличить параметр snapshot.maxConsolidateTime до 60, например.

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

[ZhenyaKazakov]

да, консолидация занимает примерно 1 час времени +-5-10 мин.

Так как быть то?  пробовать увеличить с 30 на 60 таймаут?

[Finikiez]

Увеличив параметр до 60 вы позволите тем самым виртуальной машине "уйти в себя" на большее время, чем 60 минут. Если быть точнее, то ВМ может быть заморожена на 120 секунд для синхронного процесса консолидации снапшота.

Иными словами ВМ все это время работать не будет.

Если вас это устраивает, то увеличивайте.

Если нет, то нужно бороться с низкой скоростью консолидации.

[ZhenyaKazakov]

а как бороться? какие есть варианты?

[ZhenyaKazakov]

а может быть что превышаеться время удаления снапшота и после этого он уже просит консолидацию??? если такой параметр как максимальное время удаления снапшота?

[Finikiez]

Я прошу прощения, в прошлом посте опечатался. Не минуты конечно же, а секунды.

Вопрос в том насколько быстро идет переключение на основной диск и удаление дельты-помощника. VMware Knowledge Base

Change the snapshot.maxConsolidateTime to 60 seconds. The default value is 6 seconds. If you set the value to 60 seconds, the consolidate helper sees an opportunity to do the synchronous consolidate earlier (before the snapshot grows to a 30 minute issue after 10 iterations). Setting snapshot.maxConsolidateTime to 60 means that you can afford to have the virtual machine stunned for 60 seconds so the virtual machine can perform synchronous consolidate within the iterations.

Note: There is a coefficient of 2 on maxConsolidateTime. A value of 60=120 seconds. The default is 6 but that stuns for 12 seconds.

Поставьте сначала это значение в 60.

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

Но так или иначе, начните сначала с установки параметра.

[ZhenyaKazakov]

я так понял что б установить данный параметр wm нужно выключить, потом применить и потом включать и уже пробовать.

[ZhenyaKazakov]

Set snapshot.maxIterations to 20 (or higher). The default value is 10. If you cannot converge within default maxIteration (10), you just stun and perform synchronous consolidation, which may cause the virtual machine to be stunned for a long time. If you increase maxIterations to 20 or higher, then it is possible that the virtual machine will find a period within the maxIterations to perform synchronous consolidate.

А эти параметры менят нужно?? или нет??

[ZhenyaKazakov]

Сейчас глянула, остальных параметров кроме как maxConsolidateTime у меня нету.

[Finikiez]

Я рекомендую начать только с maxConsolidateTime.

Скорее всего вам этого будет достаточно. Для изменения параметра виртуальную машину надо выключить.

Попробуйте поменять, если ничего не изменится, посмотрим дальше.

[ZhenyaKazakov]

Ну я в понедельник уже думаю проверить. С утра выкл. srv, внесу изменения и потом уже погляжу.

Просто расписание стоит бэкапить ночью в субботу. т..е. с пятницы на субботу в 2 ночи запуск и до 7:30 бэкапит там 2 машины.

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

Вдруг дело в большом обьеме.

1.5 месяца назад такой проблемы не наблюдалось если честно.

[ZhenyaKazakov]

Добрый день еще раз.

Я в общем промониторили выяснил следующие

Если я заранее вручную удаляю папку с уже сделанным обьразом ( самую старую которую должен удалить скрип после бэкапа)

то у меня бжэкап проходит нормально в автоматическом режиме

Обьем папки 500Гб

Проверял 3 недели, заранее перед созданием бжкапа удалял папку, и скрип запускался в автомате и все норм.

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