понедельник, 28 августа 2017 г.

После повторного добавления хоста в VMM, узел не подключается к Network Controller, error 20611

Привет.

Разберём следующий сценарий:
Нам необходимо по каким-либо причинам вывести хост виртуализации из под управления VMM, а затем добавить его обратно. Ситуация осложняется тем, что узел использует SDNv2 на базе Windows Server 2016 и System Center VMM 2016.

Симптом:
После повторного добавления узла в VMM и кластер не устанавливаются подключения к Network Controller по порту TCP 6640. 

Как исправить:
Рекомендую обратить внимание на закладку "Status" в свойствах узла виртуализации.


Нажмите кнопку "Repair ALL"  и нажмите "ОК".


Если вы не удаляли сертификат, выданный SCVMM, то он останется прежним при добавлении узла. После этого все соединения по портам 6640 восстановятся.



P.S. Сервисы  Network Controller зависят от VMM. Если в VMM сервис находиться в сбойном состоянии - он работать не будет.

Настройка и нюансы балансировки с помощью SLB

При использовании SDNv2 существует возможность создать балансировщик сетевой нагрузки и предоставить его в использование гостевым виртуальным машинам, допустим: тенанта в Azure Pack.

К сожалению, это невозможно сделать в графике, by-design (пока что).

Для начала, мы создаём такой балансировщик, с помощью Powershell.
Исходя из снимка экрана, Вы видите VIP адрес, ссылающийся на 2 DIP адреса ВМ внутри тенанта. Я выбрал свободный адрес из Public VIP пула, как это указано в статье.
Далее,  я беру обе ВМ, настраиваю IIS, перезапускаю его, предварительно модифицировав LANDING PAGE на обоих серверах.


И вуаля, всё работает.



Однако, не бывает простых решений. Давайте внимательно посмотрим на IP-pool Public VIP в VMM.


Public VIP pool ничего не знает по этот IP адрес. Предполагаю, что VMM может выдать его любому тенанту случайным образом. И я подозреваю, что в данном сценарии могут быть риски дублирующихся IP адресов, т.к. пул Public VIP, ничего не знает про адрес.

Пока это требует исследования.

Я планирую вернуться к этому вопросу в ближайшее время.
Однако, как решить проблему с SLB и фиксацией IP адреса в Public VIP пуле?


Приведённое ниже решение не является официальным и Вы делаете его на свой страх и риск.

Могу предложить выход из ситуации:

На днях я протестировал создание внешнего балансировщика на IP адресе прибитом к отдельному NAT, в отдельной виртуальной сети Azure Pack + SCVMM - это работает. Однако, при таком сценарии на NAT перестают работать правила и отвечает только порт, указанный в балансировщике. Имейте это в виду при работе с Azure Pack.

P.S. внутренняя балансировка изолирована от внешней. На сколько я понял, на текущий момент, невозможно балансировать внешний трафик внутренним балансировщиком - это разомкнутые контуры. По крайней мере, у меня не получилось привести внешний трафик из Public VIP диапазона на Private VIP балансировщика - на мой взгляд это схема не рабочая by-design.