Estou criando uma implantação de teste do Lync no Azure; sim, eu sei que isso não é suportado, portanto, "teste".
Os servidores front-end do Lync expõem dois conjuntos de serviços da Web, um para usuários internos e um para usuários externos; eles escutam em portas diferentes (443 e 4443) nos mesmos servidores; Quando serviços externos são publicados, você precisa de um proxy reverso ou de um encaminhamento de porta para mapear a porta 443 de um endereço IP público para a porta 4443 do (s) servidor (es) front-end. Quando você tem vários servidores front-end em um pool, também é necessário balancear a carga deles.
Assim, uma implantação típica do Lync é assim:
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
Isso deve ser facilmente replicado no Azure, pois oferece suporte a ambas balanceamento de carga externo ( howto de configuração ) e balanceamento de carga interno (configuration howto ). Eles são até mesmo suportados juntos no mesmo serviço de nuvem, portanto, essa configuração deve ser fácil. No entanto, parece que "deveria" é a palavra-chave aqui.
Depois de criar o ponto de extremidade de balanceamento de carga externo (que escuta na porta externa 443 e encaminha para a porta 4443 nos servidores), estou tentando criar um balanceador de carga interno e adicionar pontos de extremidade internos a is; no entanto, enquanto o ILB pode ser criado com êxito, adicionar um ponto de extremidade interno escutando na porta 443 e encaminhando para a porta 443 nos servidores falha miseravelmente, com um erro informando que a porta 443 já está em uso por outro terminal:
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.
Para referência, meus comandos são:
Add-AzureInternalLoadBalancer -InternalLoadBalancerName "LyncILB" -ServiceName "LyncFrontEnd" -SubnetName "LabSubnet" -StaticVNetIPAddress 192.168.0.20
(isso é concluído com êxito)
Get-AzureVM LYNCFE1 | Add-AzureEndpoint -Name "Https-Int" -Protocol "tcp" -LocalPort 443 -PublicPort 443 -LBSetName "HttpsIntLB" -DefaultProbe -InternalLoadBalancerName "LyncILB"
(isso falha)
O terminal externo existente é configurado como tal:
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 :
O erro nem faz muito sentido; o balanceador de carga externo escuta em um endereço IP público, enquanto o balanceador de carga interno escuta em um endereço IP privado na rede interna; não deve haver qualquer conflito aqui ... no entanto, parece que existe um.
Por que isso não funciona? Estou fazendo algo errado ou a rede do Azure está sendo tola como de costume?
A questão agora é discutível, já que o Azure agora permite (e permitiu por algum tempo) o uso de balanceadores de carga internos e públicos para expor os mesmos serviços das mesmas VMs.
Ainda é um mistério porque você precisa usar dois objetos completamente diferentes para fazer exatamente o mesmo trabalho, apenas com diferentes endereços IP front-end ... mas pelo menos você agora pode.
Acabamos de encontrar o mesmo problema com uma implantação diferente. O problema é que você não pode ter mais de uma regra de LB configurada na mesma porta e protocolo usando os mesmos pools IP de back-end.
Para alcançar o que você está querendo, você precisará adicionar placas de rede adicionais às máquinas e usar os IPs diferentes para as regras de balanceamento interno vs Externo. Alternativamente, você poderia dar às máquinas públicas IP's e balancear a carga nelas externamente (no entanto você expõe as máquinas à internet, geralmente indesejáveis).
Espero que ajude!
Tags azure load-balancing