Как многие из вас знают, в среде VMware vSphere есть специализированные виртуальные машины, которую выполняют служебные функции, специфические для виртуальной инфраструктуры. К ним, например, можно отнести, виртуальные агенты (Agent VMs) - машины, предназначенные для того, чтобы присутствовать на хосте всегда (т.е. не участвовать в DRS/DPM) и обслуживать другие ВМ. Хороший пример - это антивирусные виртуальные модули (Virtual Appliance), которые сейчас есть у Trend Micro и Касперского и которые работают через vShield Endpoint и VMsafe API:
Логично предположить, что эти виртуальные машины в среде VMware vSphere надо обрабатывать как-то по-особенному. Это так и происходит. Давайте посмотрим, как это делается:
1. Платформа vSphere помечает внутри себя такие виртуальные машины как виртуальные агенты (Agent VMs).
2. Поскольку виртуальный агент должен предоставлять сервис для других виртуальных машин, агенские ВМ, в случае сбоя, на каждом хосте запускаются в первую очередь, чтобы не оставить никого без этого сервиса.
Таким образом, в случае сбоя порядок загрузки ВМ на хосте ESXi следующий:
стартуют виртуальные агенты
запускаются Secondary виртуальные машины для тех, которые защищены технологией Fault Tolerance
поднимаются виртуальные машины с высоким, средним и низким приоритетом, соответственно
3. Механизм VMware DRS/DPM, осуществляющий балансировку виртуальных машин по хостам средствами vMotion и экономию электропитания серверов средствами их отключения при недогрузке датацентра, также в курсе о виртуальных агентах. Поэтому здесь следующее поведение:
DRS учитывает Reservations, заданные для агентов, даже в том случае, когда они выключены
для режимов обслуживания (maintenance mode) и Standby - виртуальные агенты никуда с хоста автоматически не мигрируют
виртуальные агенты должны быть доступны на хосте перед тем, как там будут включены обычные ВМ или они туда будут смигрированы
RSS
