Как стать автором
Обновить

Детектив с Кластером Hyper-V: шаг за шагом ищем решение проблемы

Время на прочтение14 мин
Количество просмотров6.8K
Всего голосов 16: ↑16 и ↓0+16
Комментарии17

Комментарии 17

может кто подскажет по hyper-v, есть такая проблема
hyper-v на одиночном win 2019 server
в списке 9 машин, работает только 3
после перезапуска сервера (на важно, штатного или аварийного) с очень большой вероятностью в списке будет только 1 машина (всё время одна и та же) да ещё и не запустится, несмотря на то что в настройках стоит запускаться с задержкой 30 секунд
если сказать импортировать и сказать машины, (не важно что выбрать из опций про id машины при импорте) всегда говорит ошибкой, но тут же в списке появляется машина и прекрасно запускается и работает

Выделенная память у ВМ динамическая? если да, весьма вероятно, что на остальные две ВМ не хватает активной памяти на сервере. HyperV не умеет работать, если есть overprovisioning по памяти, плюс при запуске ВМ выделяет им максимум.

Поправлю — при запуске выделяется не максимум, а указанное в настройках виртуалки "стартовое значение". А уже после загрузки системы выделенная память может как уменьшиться, так и увеличиться.

всего на сервере 16gb
на виртуалки выделено жёстко 8192, 512, 1024. dynamic memory НЕ включено
Пересоздайте машины и прицепите существующие диски. Выглядит так, будето просто конфиги побились.
Теории о том, что:
есть проблемная машина или ряд проблемных машин;
есть проблемная Hyper-V нода;
отпадают, так как почти все машины из списка хоть раз да падали.

Собственно у меня сразу возник вопрос — почему исключили ноду в качестве пациента? С ВМками то понятно, это из отчёта ясно, но HTML отчёт нам ничего не говорит про ноды и расположение машин на них.
Все верно, в отчете явно не указано — на каких нодах расположены машины.

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

Я показал свою ветку развития расследования — сбор детальной информации об ошибке затем построение теории и её проверка.
Возможно я заострился на конкретной ноде, хотя у меня возникли в первую очередь подозрения именно на проблемы в среде виртуализации.
Мы открываем файл, начинающийся с Task и содержащий название VM. В нем просто ищем ошибку. Обычно нажимаем CTRL+End — это перебрасывает нас в самый низ лога, и потом крутим колесико вверх, пока не увидим нужную нам ошибку.

А что мешает воспользоваться поиском и найти ту самую ошибку по «Failed to get VM»? Так же быстрее, чем скроллить руками через весь лог?
Это из моего опыта, я описал — так как делаю. Вы можете делать как Вам удобнее)

Почему я обычно делаю так?

В HTML репорте мы смотрим сверху вниз — от самого свежего выполения листая вниз более старые.
Имея открытый репорт, желая проанализировать именно самое свежее выполнение в логах, открываю файл и перескакиваю в самый низ (CTRL+End), и снизу вверх начинаю смотреть — видно как завершалось задание, и я анализирую все этапы один за одним. То есть, самое последнее выполение задания в логах всегда в самом конце.


Почему мне более предпочтителен этот способ чем поиск по «Failed to get VM»

Открывая файл с логами, и делая поиск по ошибке вы найдете ошибку, но нужно ориентироваться на какое именно выполнение задания вы смотрите — самое свежее, самое старое, или промежуточное.
В одном выполнении задания ошибка может пробрасываться в логи много раз, и просто найдя место где написано сообщение об ошибке нужно ещё с ориентироваться, что происходит в задании в этот момент в целом — полистать вниз и вверх.

В общем, когда задача сложная, и непонятная, то я анализирую всё выполение задания с конца и до начала и потом наоборот, чтобы не упустить деталей и сформировать картину происходящего.
Я далёк от кластеризации Hyper-V, но подскажите, почему в принципе ВМ-ка должна бесконтрольно в рандомный момент времени мигрировать с одной ноды на другую? Не лцчше ли этот процесс сделать контролируемым? Я думал, что такое случается только при выключении ноды где изначально ВМ-ка крутилась.
Load balancing. Фича впервые появилась в 2016 и судя по файлу конфигурации ВМ тут речь именно о 2016/2019. Кластеру можно разрешить автоматически мигрировать ВМ между нодами для баланса памяти и нагрузки CPU.
techcommunity.microsoft.com/t5/failover-clustering/failover-cluster-vm-load-balancing-in-windows-server-2016/ba-p/372084
Всем привет.
Proxmox VE — открытая альтернатива этому «чуду» от MS — forum.netgate.com/topic/120102/proxmox-ceph-zfs-pfsense-и-все-все-все
Автобэкапы, кластеризация, ZFS (не нужен железный raid-контроллер) с мгновенными снепшотами — из коробки. Можно прикрутить Proxmox Backup Server для инкрементных бэкапов.

Two types of virtualization are supported: container-based with LXC, and full virtualization with KVM.

Hyper-V хорош тем, что у него очень маленький оверхед. Особенно в Gen2 виртуалках.

Linux KVM (Proxmox VE основан на нем) хорош тем, что у него очень-очень маленький оверхед.

Amazon (https://www.opennet.ru/opennews/art.shtml?num=47556), Google, Oracle и (внезапно) MS (или думаете, что MS для Azure windows пользуют?) не дадут соврать.

Судя по тому, что вижу я, по процессору и диску у Hyper-V оверхед меньше, чем у KVM. По памяти и сети Hyper-V некритично хуже. Кто что использует — дело другое.

Плюс у Hyper-V свои плюшки есть вроде AVMA, PSSession в виртуалку, Hyper-V WMI provider и т.д. Кому что.

Это я всё к тому, что не такое уж он и «чудо».

Зарегистрируйтесь на Хабре, чтобы оставить комментарий