Я создаю тестовое развертывание Lync в Azure; да, я знаю, что это не поддерживается, поэтому "тест".
Серверы Lync Front-End предоставляют два набора веб-служб: один для внутренних пользователей, а другой - для внешних; они прослушивают разные порты (443 и 4443) на одних и тех же серверах; когда публикуются внешние службы, вам понадобится обратный прокси-сервер или переадресация портов, чтобы сопоставить порт 443 общедоступного IP-адреса с портом 4443 сервера (-ов) переднего плана. Если у вас несколько серверов переднего плана в пуле, вам также необходимо сбалансировать их нагрузку.
Итак, типичное развертывание Lync выглядит так:
Internal users
|
443
|
Internal LB
192.168.0.20
/ \
/ \
443 443
| |
Lync FE 1 Lync FE 2
192.168.0.21 192.168.0.22
| |
4443 4443
\ /
\ /
External LB
Public IP Address
|
443
|
External Users
это должен легко реплицируется в Azure, поскольку поддерживает оба балансировка внешней нагрузки (как настроить) и внутренняя балансировка нагрузки (как настроить). Они даже поддерживаются вместе в одной облачной службе, поэтому такая конфигурация должна быть простой. Однако похоже, что здесь ключевое слово «должен».
После создания внешней конечной точки с балансировкой нагрузки (которая прослушивает внешний порт 443 и перенаправляет на порт 4443 на серверах) я пытаюсь создать внутренний балансировщик нагрузки и добавить внутренние конечные точки в is; однако, хотя ILB может быть успешно создан, добавление внутренней конечной точки, прослушивающей порт 443 и пересылки на порт 443 на серверах, терпит неудачу с ошибкой, указывающей, что порт 443 уже используется другой конечной точкой:
Update-AzureVM : BadRequest : Port 443 is already in use by one of the endpoints
in this deployment. Ensure that the port numbers are unique across endpoints
within a deployment.
Для справки, мои команды:
Add-AzureInternalLoadBalancer -InternalLoadBalancerName "LyncILB" -ServiceName "LyncFrontEnd" -SubnetName "LabSubnet" -StaticVNetIPAddress 192.168.0.20
(Это успешно завершается)
Get-AzureVM LYNCFE1 | Add-AzureEndpoint -Name "Https-Int" -Protocol "tcp" -LocalPort 443 -PublicPort 443 -LBSetName "HttpsIntLB" -DefaultProbe -InternalLoadBalancerName "LyncILB"
(Это не удается)
Существующая внешняя конечная точка настроена как таковая:
Get-AzureVM LYNCFE1 | get-azureendpoint
LBSetName : HttpsExtLB
LocalPort : 4443
Name : HTTPS-Ext
Port : 443
Protocol : tcp
Vip :
ProbePath :
ProbePort : 4443
ProbeProtocol : tcp
ProbeIntervalInSeconds : 15
ProbeTimeoutInSeconds : 31
EnableDirectServerReturn : False
Acl : {}
InternalLoadBalancerName :
IdleTimeoutInMinutes :
LoadBalancerDistribution :
Ошибка даже не имеет большого смысла; внешний балансировщик нагрузки прослушивает общедоступный IP-адрес, а внутренний балансировщик нагрузки прослушивает частный IP-адрес во внутренней сети; там не должен здесь может быть какой-то конфликт ... но похоже, что он есть.
Почему это не работает? Я что-то делаю не так, или сеть Azure снова становится глупой?
Теперь вопрос спорный, поскольку Azure теперь позволяет (и разрешает какое-то время) использовать как внутренние, так и общедоступные балансировщики нагрузки для предоставления одних и тех же служб с одних и тех же виртуальных машин.
По-прежнему остается загадкой, почему вам нужно использовать два совершенно разных объекта для выполнения одной и той же работы, только с разными интерфейсными IP-адресами. Но, по крайней мере, теперь вы можете.
Просто столкнулся с той же проблемой с другим развертыванием. Проблема в том, что вы не можете настроить более одного правила LB для одного порта и протокола, используя одни и те же внутренние пулы IP.
Чтобы добиться желаемого, вам нужно будет добавить к машинам дополнительные сетевые адаптеры и использовать разные IP-адреса для внутренних и внешних правил балансировки. В качестве альтернативы вы можете предоставить машинам общедоступные IP-адреса и баланс нагрузки на них извне (однако вы открываете машины для доступа в Интернет, что обычно нежелательно).
Надеюсь, это поможет!