Estou criando uma implantação de teste do Lync no Azure; sim, eu sei que isso não é suportado, portanto, "teste".
Os servidores Lync Front-End expõem dois conjuntos de serviços da Web, um para usuários internos e outro para 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 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 precisa fazer o balanceamento de carga deles.
Portanto, uma implantação típica do Lync se parece com isto:
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 ao balanceamento de carga externo ( como fazer de configuração ) e balanceamento de carga interno ( como fazer de configuração ). Eles são suportados juntos no mesmo serviço de nuvem, então essa configuração deve ser fácil. No entanto, parece que "deveria" é a palavra-chave aqui.
Depois de criar o endpoint externo com balanceamento de carga (que escuta na porta externa 443 e encaminha para a porta 4443 nos servidores), estou tentando criar um balanceador de carga interno e adicionar endpoints internos a ele; no entanto, embora o ILB possa ser criado com sucesso, 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 ponto de extremidade:
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 conclui com sucesso)
Get-AzureVM LYNCFE1 | Add-AzureEndpoint -Name "Https-Int" -Protocol "tcp" -LocalPort 443 -PublicPort 443 -LBSetName "HttpsIntLB" -DefaultProbe -InternalLoadBalancerName "LyncILB"
(Isso falha)
O endpoint 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 deveria haver nenhum conflito aqui... no entanto, parece que há um em seu lugar.
Por que isso não funciona? Estou fazendo algo errado ou a rede do Azure está apenas sendo boba como sempre?
A questão agora é discutível, pois o Azure agora permite (e permitiu por um tempo) o uso de balanceadores de carga internos e públicos para expor os mesmos serviços das mesmas VMs.
Ainda é um mistério por que você precisa usar dois objetos completamente diferentes para fazer exatamente o mesmo trabalho, apenas com endereços IP de front-end diferentes. Mas pelo menos agora você pode.
Acabei 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 de IP de back-end.
Para conseguir o que você deseja, você precisará adicionar NICs adicionais às máquinas e usar os diferentes IPs para regras de balanceamento interno x externo. Como alternativa, você pode fornecer às máquinas IPs públicos e balancear a carga nelas externamente (no entanto, você expõe as máquinas à Internet, geralmente indesejável).
Espero que ajude!