Как присвоить полномочия ESXI пользователю Windows AD, для работы с VMware vMA?
Это звучит, как будто, проблемы масштабируемости в сервере приложений а не сервере базы данных. Поэтому лучший выбор состоит в том, чтобы загрузиться, балансируют серверы приложений.
Выравнивание нагрузки довольно легко и может быть сделано на сетевом уровне. Это позволяет Вам помещать X количества реальных или виртуальных машин позади VIP и распределять загрузку через машины в одностороннем порядке. Данный пользователь поразит различные машины в каждый запрос.
Когда выравнивание нагрузки, ее лучшее для предотвращения информации о состоянии сеанса. Однако, если Вы не можете избежать его, сервер состояния сеанса будет необходим, что все машины могут соединиться с. Это довольно тривиально в.NET, так как поставщики состояния сеанса могут быть легко включены в использовании Web.config. Это позволяет самим серверам приложений быть не сохраняющими состояние и поэтому, VIP может направить входящий трафик к любому серверу, который он хочет.
Выравнивание нагрузки также позволит Вам выводить машину из обслуживания, если это станет проблематичным, или обслуживание должно быть развернуто. Это также пригождается во время развертывания, поскольку можно вывести половину машин из обслуживания и сделать развертывание и затем подкачать их. Это предотвращает наличие 2 версий кода приложения, работающего одновременно.
В руководстве по vMA предполагается, что вы уже предприняли шаги для присоединения хоста ESXi к Active Directory и предоставили разрешения, позволяющие запускать эти команды.
Соответствующую документацию можно найти здесь в документации ESXi и vCenter Server 5.5. В частности, в разделе Безопасность vSphere - Защита хостов ESXi - Использование Active Directory для управления пользователями ESXi .
Спасибо совету Райана из документации. Я нахожу правильное направление.
Во-первых, я должен присоединить мою машину ESXi к Windows AD, что можно сделать через viclient.
Во-вторых, согласно документу VMware vSphere, я должен создать группу AD с именем ] Администраторы ESX (без чепухи, вы должны использовать это имя группы) и сделать chjadmin членом ее.
Теперь я могу выполнить esxcli с идентификатором пользователя AD:
esxcli --server=172.27.120.147 -u chjadmin -p 123456 system version get
Я подтверждаю, что указанная выше команда не зависит от предварительных условий vifp addserver 172.27.120.147 .... и он выполняет быстро (за две секунды).
Пока все хорошо.
ОДНАКО, существует другая проблема. Команды vifp выполняются так медленно.
vifp addserver 172.27.120.147 --authpolicy adauth --username 'velab.chj\chjadmin' # costs 10 seconds
vifptarget -s 172.27.120.147 # cost 30+ seconds
Почему они так долго стоят?
Что еще хуже, прежде чем я выполню vifptarget -c , чтобы выйти из целевого контекста ESXi по умолчанию , каждое нажатие клавиши Enter в командной строке стоит 20+ секунд. Что случилось внутри?
Я быстро понимаю, что внутри PS1 может быть что-то странное. Оказывается, да.
Команда
LD_PRELOAD=`__get_ld_preload_without_vmalibs` /opt/vmware/vma/bin/vitargetquery.sh
выполняется так долго, 20+ секунд. Может кто-нибудь помочь объяснить это?
Кстати: Моя настроенная PS1 (дословно из командной строки Bash):
PS1="\n[\[\033[32m\]$(tty) \d \t\[\033[31m\] jobs:\j\[\033[0m\] "'ERR:$?$(if [ $? != 0 ];then echo -e \a; fi)] \n'"[\u @\h \[\033[33m\w\033[0m\]]\n\[\033[1;37;44m\]#\[\033[0m\] "
[Обновление] медленное выполнение команд vifp решена
Чтение исходного кода Bash / opt / vmware / vma / bin / vifptarget и / opt / vmware / vma / bin / vitargetquery .sh , я обнаружил, что они оба выполняют настоящий двоичный fastVmaTargetCheck , например, этот / opt / vmware / vma / sbin / fastVmaTargetCheck 172.27.120.147 , на который уходит большая часть времени .
Поскольку у меня нет исходного кода для fastVmaTargetCheck , мне пришла в голову идея обнюхивания пакетов на машине vMA и, наконец, раскрыть причину. fastVmaTargetCheck 172.27.120.147 безоговорочно выполняет обратный поиск DNS для 172.27.120.147 с примерно 12-секундным таймаутом, а у моего DNS-сервера интрасети не было зоны обратного просмотра, поэтому он перенаправлял запрос на DNS-серверы в Интернете, которые также истекли. Команды vifp выполняют такой запрос много раз, поэтому я видел медленное выполнение. Решение состоит в том, чтобы добавить зону обратного просмотра 120.27.172.in-addr.arpa на мой DNS-сервер, чтобы дать vMA мгновенный ответ (неважно положительный или отрицательный), и задержка выполнения исчезнет.