Комбинирование разных типов affinity rules

Недавно заказчик спросил меня можно ли комбинировать affinity rules типа VM-host и VM-VM anti-affinity rules, какое влияние это окажет на систему и какие минусы такого решения.

Пример сценария
В данном примере две ВМ являют собой одно приложение, кластеризованное на уровне  приложения. ВМ 1 и 2 предоставляют сервис для  App-cluster1, точно также настроены  App-cluster2 и App-cluster3. Вычислительный кластер состоит из 6 хостов. Требование заказчика состоит в том, чтобы каждое кластеризованное приложение работало на собственных физическах серверах. Также разные приложения не должны размещаться на одном физическом сервере за исключением ситуаций обслуживания серверов. Виртуальные машины одного кластера приложений не могут работать на одном сервере.

Affinity rules VM-Host

На первом этапе необходимо создать правило соответствия виртуальной машины к физическому хосту. Для каждого кластера приложений необходимо создать DRS группу виртуальных машин, а также DRS группу хостов, на которых эти ВМ будут работать. 

 Тип правила

Первый интересный вопрос, который возникает - какой тип правила необходимо выбрать. В данном всё случае всё зависит от требований. Во время нормального функционирования комплекса DRS будет учитывать оба типа правил - и must, и should. Однако, HA не знает о правилах типа should, таким образом, в случае выхода из строя одного из хостов НА может запустить ВМ на сервере не входящим в изначальную DRS группу хостов. Если это нежелательно - тогда необходимо выбирать правило типа must. Ни DRS, ни HA не могут нарушить данное правило, и если оба хоста DRS группы выйдут из строя - ВМ не сможет быть перезапущена. Тоже самое касается antiaffinity rules VM-VM при переводе хост в maintanance mode, но в деталях этого вопроса я коснусь ближе к концу.

VM-VM antiaffinity rule

После создания правила, привязывающего ВМ к хостам необходимо создать правило по которому виртуальные машины разносились бы по разным хостам. DRS будет это правило как во время балансировки, так и при первичном размещении во время включения ВМ. По сути, VM-VM antiaffinity rules можно сравнить с правилами типа must в случае с VM-Host. Так правила типа VM-VM работают только на уровне DRS, то HA может их нарушить и запустить виртуальную машину с вышедшего из строя хоста на хосте где размещена вторая ВМ кластера. Данное нарушение будет исправлено DRS во время следующего анализа системы. Так как DRS не будет нарушать правила VM-VM, созданное правило типа VM-Host и будет определять степень портативности машины.

Комбинация VM-VM antiaffinity rules, should run on и maintanance mode

Если один из хостов, к которому привязана ВМ будет переведён в maintanance mode, то DRS нарушит правило should, так как правило типа VM-VM нарушено быть не может. Это гарантирует целостность кластера приложения, так как виртуальные машины не расположены на одном хосте.

Комбинация VM-VM antiaffinity rules, must run on и maintanance mode

Хосты, указанные в must правиле вносятся в список совместимых для данной ВМ, остальные же считаются несовместимыми. По сути, уменьшая шестинодовый кластер до двухнодового, в случае с VM1 и VM2 до хостов ESX-01 и ESX-02. Если один из двух хостов перевести в maintanance mode, то DRS не сможет нарушить VM-VM правило, а так как список совместимости сокращён до двух хостов, то виртуальной машине некуда деваться. В таком случае переход в maintanance mode закончиться с ошибкой.

Такое решение усложнит поддержку систему, так как правило типа VM-Host необходимо будет изменить на should или временно выключить.

Варианты балансировки

Antiaffinity rules предоставляют отличные возможности по контролю и улучшению надёжности работы ВМ и предоставляемых сервисов, однако, ограничивает возможности DRS по балансировке нагрузки. DRS кластер поддержтивает разные вариации смешивания правил, однако, необходимо учитывать что создание большого количества правил с взаимосвязями между собой ограничивает возможности по балансировке.



Оригинал: Frank Denneman