A porta do aplicativo Microsoft Service Fabric já está em outro aplicativo

Question

Estamos executando um cluster de fabric de serviço no local (5.4.145.9494), mas temos algumas peculiaridades engraçadas com ele. Basicamente, sempre que executamos uma aplicação (e especialmente quando contém réplicas), notamos que os serviços não podem iniciar a maior parte do tempo. Dentro do SF, a mensagem de erro não é descritiva (partição não íntegra ...), mas nos logs de eventos fica evidente que o serviço não pode ser iniciado porque a porta escolhida já está sendo usada por outro aplicativo (variando de um processo svchost para winit basicamente qualquer aplicativo).

Neste caso, os desenvolvedores NÃO atribuem uma porta, então, basicamente, SF tem que descobrir isso. Em nossa configuração, atribuímos portas efêmeras e portas de aplicativos de acordo com o link e nós tentamos as duas opções, pois a documentação é silenciosa e confusa, considerando que as portas de aplicativos são um subconjunto de portas efêmeras, enquanto os exemplos mostram que não. Outra coisa engraçada é que, como a configuração de portas efêmeras basicamente altera o intervalo de portas dinâmicas das próprias janelas, qualquer coisa que mudarmos aqui também altera os intervalos de portas de QUALQUER outra aplicação executada dentro do Windows.

Próximo a isso, parece que o SF não está tentando usar outra porta, uma vez que a porta já está em uso, então ela também não será consertada. Snippet simples do log de eventos:

transport 35d3ce77c0 failed to bind on 0.0.0.0:49160, error = 0x80072740, port 49160 already held by process 204

neste caso, o processo 204 é o spoolsv.exe, mas novamente pode ser qualquer processo.

Neste momento, a configuração do nó é definida como:

<NodeType Name="NodeType0">

  <Endpoints>

    <ClientConnectionEndpoint Port="19000" />

    <LeaseDriverEndpoint Port="19002" />

    <ClusterConnectionEndpoint Port="19001" />

    <HttpGatewayEndpoint Port="19080" Protocol="http" />

    <HttpApplicationGatewayEndpoint Port="19081" Protocol="http" />

    <ServiceConnectionEndpoint Port="19003" />

    <ApplicationEndpoints StartPort="49152" EndPort="50000" />

    <EphemeralEndpoints StartPort="49152" EndPort="65534" />

  </Endpoints>

Mas, como dito anteriormente, nós já tentamos colocar os ApplicationEndpoints em seu próprio intervalo, o que não irá consertá-lo; -).

Qualquer ajuda seria muito bem vinda; -)

    

Answer 1

Encontramos o mesmo problema em nosso ambiente de controle de qualidade no local. Resolvemos o problema garantindo que o valor especificado para [HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ Tcpip \ Parameters \ MaxUserPort] ( link ). é menor que a porta mais baixa especificada no manifesto do cluster do Service Fabric (e).

Primeiro modificamos o valor de MaxUserPort de acordo com a regra acima, mas seu valor foi redefinido para a reinicialização. Vendo isso, nós adaptamos os valores do cluster SF ApplicationEndpoints e EphemeralEndpoints e o tempo de execução SF não reclama mais.