vSphere70u1 — Как виртуальные машины агента vCLS могут предоставлять службу кластеризации?

vSphere 7 Update 1 добавил новую «vSphere Clustering Service (vCLS)» и, согласно документ:

• Базовая архитектура

  Базовая архитектура плоскости управления vCLS состоит из максимум 3 виртуальные машины (ВМ), также называемые виртуальными машинами системы или агента, которые размещаются на отдельных узлах в кластере. Это облегченные виртуальные машины агентов, образующие кворум кластера. В небольших кластерах с менее чем 3 хостами количество виртуальных машин агента равно количеству хостов ESXi. Виртуальные машины агентов управляются vSphere Cluster Services.. Пользователи не должны поддерживать жизненный цикл или состояние виртуальных машин агентов, их не следует рассматривать как обычные виртуальные машины рабочей нагрузки.

Меня очень сбивает с толку то, как эти виртуальные машины vCLS могут помочь обеспечить Служба кластеризации. У этих виртуальных машин даже нет сетевых адаптеров, поэтому они не могут напрямую общаться друг с другом. На самом деле хосты ESXi кластера обмениваются информацией о своем состоянии. Таким образом, с технической точки зрения служба ESXi (работающая как процессы) может делать то же, что и виртуальные машины vCLS.

Попробуйте погуглить «vsphere отключить vcls», и вы увидите, что эта новая функция действительно вводит пользователей в замешательство. Итак, в чем смысл использования виртуальных машин vCLS?

«поэтому они не могут напрямую общаться друг с другом» — у виртуальных машин есть больше способов общаться друг с другом и с vCenter, чем просто Ethernet/IP.

С тех пор как были представлены DRS и HA, они в значительной степени зависели от работоспособности vCenter — венчурный капитал решал, какие виртуальные машины следует переместить для DRS, и организовывал перемещение хостов, а HA нуждался в венчурном капитале, чтобы помочь координировать процесс голосования HA и планировать «карту отказов». '.

vCLS позволяет DRS и HA не только продолжать работу в отсутствие VC, но также разрешать голосование HA и планы развития в зависимости от доступности хоста при наличии VC. Думайте об этом как о функциях <7.0u1 VC DRS и HA, отправленных из VC в трехсторонний кластер, чтобы выполнять эту роль для него — имеет ли это смысл?

В любом случае просто игнорируйте их, они эффективно управляются самостоятельно, во что бы то ни стало поместите их в свою собственную папку виртуальной машины, чтобы скрыть их, но не беспокойтесь о них.