Sobre serviços publicados
Neste documento, apresentamos uma visão geral de como usar o Private Service Connect para disponibilizar um serviço para os consumidores de serviço.
Como produtor de serviço, use o Private Service Connect para publicar serviços usando endereços IP internos na rede VPC. Os serviços publicados podem ser acessados pelos consumidores de serviços que usam endereços IP internos nas redes VPC.
Para disponibilizar um serviço aos consumidores, crie uma ou mais sub-redes dedicadas. Em seguida, crie um anexo de serviço que se refere a essas sub-redes. O anexo de serviço pode ter diferentes preferências de conexão.
Tipos de consumidores de serviços
Dois tipos de consumidores podem se conectar a um serviço do Private Service Connect:
Endpoints têm base em uma regra de encaminhamento.
Back-ends têm base em um balanceador de carga.
Sub-redes NAT
Os anexos de serviço do Private Service Connect são configurados com uma ou mais sub-redes NAT, também conhecidas como sub-redes do Private Service Connect. Os pacotes da rede VPC do consumidor são convertidos usando a NAT de origem (SNAT) para que os endereços IP de origem sejam convertidos em endereços IP de origem da sub-rede NAT na rede VPC do produtor.
Os anexos de serviço podem ter várias sub-redes NAT. É possível adicionar sub-redes NAT extras ao anexo de serviço a qualquer momento sem interromper o tráfego.
Um anexo de serviço pode ter várias sub-redes NAT configuradas, mas uma sub-rede NAT não pode ser usada em mais de um anexo de serviço.
Não é possível usar sub-redes NAT do Private Service Connect para recursos como instâncias de máquina virtual (VM) ou regras de encaminhamento. As sub-redes são usadas apenas para fornecer endereços IP para SNAT de conexões de consumidor recebidas.
Dimensionamento de sub-rede NAT
Ao publicar um serviço, você cria uma sub-rede NAT e escolhe um intervalo de endereços IP. O tamanho da sub-rede determina quantos endpoints ou back-ends simultâneos do Private Service Connect podem se conectar ao anexo de serviço.
Os endereços IP são consumidos na sub-rede NAT de acordo com o número de conexões do Private Service Connect. Se todos os endereços IP na sub-rede NAT forem consumidos, qualquer outra conexão do Private Service Connect falhará. Por isso, é importante dimensionar a sub-rede NAT adequadamente.
Ao escolher um tamanho de sub-rede, considere o seguinte:
-
Há quatro endereços IP que não podem ser usados em uma sub-rede NAT. Por isso, o número de endereços IP disponíveis é 2(32 - PREFIX_LENGTH) - 4. Por
exemplo, se você criar uma sub-rede NAT com
tamanho de prefixo
/24
, o Private Service Connect poderá usar 252 dos endereços IP para SNAT. Uma sub-rede/29
com quatro endereços IP disponíveis é o menor tamanho de sub-rede compatível com redes VPC. - Um endereço IP é consumido a partir da sub-rede NAT para cada endpoint ou back-end que está conectado ao anexo de serviço.
- Ao estimar quantos endereços IP você precisa para endpoints e back-ends, considere todos os serviços multilocatários ou consumidores que usam acesso multiponto para apps particulares Service Connect
- O número de conexões TCP ou UDP, clientes ou redes VPC de consumidor não afeta o consumo de endereços IP da sub-rede NAT
Por exemplo, se houver dois endpoints conectados a um único
anexo de serviço, dois endereços IP serão consumidos na sub-rede
NAT. Se o número de endpoints não mudar, será possível usar uma
sub-rede /29
com quatro endereços IP utilizáveis para este anexo de serviço.
Monitoramento de sub-rede NAT
Para ajudar a garantir que as conexões do Private Service Connect não falhem devido a endereços IP indisponíveis em uma sub-rede NAT, recomendamos estas ações:
- Monitore a métrica do anexo de serviço
private_service_connect/producer/used_nat_ip_addresses
. Verifique se o número de endereços IP NAT usados não excede a capacidade das sub-redes NAT de um anexo de serviço. - Monitore o status das conexões do anexo de serviço. Se uma conexão tiver o status Requer atenção, talvez não haja mais endereços IP disponíveis nas sub-redes NAT do anexo.
- Para serviços com multilocatário, é possível usar Limites de conexão para garantir que um único consumidor não esgote a capacidade de sub-redes NAT de um anexo de serviço.
Se necessário, sub-redes NAT podem ser adicionadas ao anexo de serviço a qualquer momento sem interromper o tráfego.
Especificações NAT
Considere as seguintes características da NAT do Private Service Connect ao projetar o serviço que você publicará:
O tempo limite de inatividade do mapeamento UDP é de 30 segundos e não pode ser configurado.
O tempo limite de inatividade da conexão estabelecida TCP é de 20 minutos e não pode ser configurado.
Para evitar problemas de tempo limite das conexões de cliente, siga um destes procedimentos:
Garanta que todas as conexões durem menos de 20 minutos.
Garanta que parte do tráfego seja enviado mais de uma vez a cada 20 minutos. É possível usar um sinal de funcionamento ou sinal de atividade no seu aplicativo ou sinais de atividade TCP. Por exemplo, é possível configurar um sinal de atividade no proxy de destino de um balanceador de carga de aplicativo interno regional ou um balanceador de carga de rede de proxy interno regional.
O tempo limite de inatividade da conexão TCP transitiva é de 30 segundos e não pode ser configurado.
Há um atraso de dois minutos antes que qualquer tupla de cinco (endereço IP de origem da sub-rede do Private Service Connect e porta de origem mais o protocolo de destino, endereço IP e porta de destino) possa ser reutilizada.
A SNAT do Private Service Connect não é compatível com fragmentos de IP.
Número máximo de conexões
Uma única VM de produtor aceita no máximo 65.536 conexões TCP e 65.536 conexões UDP de um único endpoint do Private Service Connect. Não há limite para o número total de conexões TCP e UDP que um endpoint do Private Service Connect pode receber de maneira agregada em todos os back-ends do produtor. As VMs de consumidor podem usar todas as 65.536 portas ao iniciar conexões TCP ou UDP para um endpoint do Private Service Connect. Toda a conversão de endereços de rede é feita localmente no host do produtor, o que não requer um pool de portas NAT alocado centralmente.
Anexos de serviço
Os produtores de serviços expõem o serviço deles utilizando um anexo.
Para expor um serviço, um produtor de serviço cria um anexo de serviço que se refere à regra de encaminhamento do balanceador de carga do serviço.
Para acessar um serviço, um consumidor de serviço cria um endpoint que se refere ao anexo de serviço.
O URI do anexo de serviço tem este formato:
projects/SERVICE_PROJECT/regions/REGION/serviceAttachments/SERVICE_NAME
Cada balanceador de carga só pode ser referenciado por um anexo de serviço. Não é possível configurar vários anexos de serviço que usam o mesmo balanceador de carga.
Preferências de conexão
Cada anexo de serviço tem uma preferência de conexão que especifica se as solicitações de conexão são aceitas automaticamente. Há três opções:
- Aceitar automaticamente todas as conexões. O anexo de serviço aceita automaticamente todas as solicitações de conexão de entrada de qualquer consumidor. A aceitação automática pode ser substituída por uma política da organização que bloqueie as conexões de entrada.
- Aceitar as conexões das redes selecionadas. O anexo de serviço só aceitará solicitações de conexão de entrada se a rede VPC do consumidor estiver na lista de aceitação do consumidor do anexo de serviço.
- Aceitar conexões para os projetos selecionados. O anexo de serviço só aceitará solicitações de conexão de entrada se o projeto de consumidor estiver na lista de aceitação do consumidor de anexo de serviço.
Recomendamos que você aceite conexões para redes ou projetos selecionados. A aceitação automática de todas as conexões pode ser apropriada se você controla o acesso do consumidor por outros meios e quer ativar o acesso permissivo ao serviço.
Status da conexão
Os anexos de serviço têm status de conexão que descrevem o estado das respectivas conexões. Para mais informações, consulte Status da conexão.
Listas de aceitação e rejeição do consumidor
Listas de aceitação do consumidor e Listas de rejeição do consumidor são um recurso de segurança dos anexos de serviço. As listas de aceitação e rejeição permitem que os produtores de serviços especifiquem quais consumidores podem estabelecer conexões do Private Service Connect com os serviços deles. As listas de aceitação do consumidor especificam se uma conexão é aceita, e as listas de rejeição do consumidor especificam se uma conexão é rejeitada. Ambas as listas permitem especificar consumidores pela rede VPC ou pelo projeto do recurso de conexão. Se você adicionar um projeto ou uma rede à lista de aceitação e à lista de proibições, as solicitações de conexão desse projeto ou rede serão rejeitadas. Não é possível especificar consumidores por pasta.
As listas de aceitação e de rejeição do consumidor permitem que você especifique projetos ou redes VPC, mas não ambos ao mesmo tempo. É possível alterar uma lista de um tipo para outro sem interromper as conexões, mas você precisa fazer a alteração em uma única atualização. Caso contrário, algumas conexões poderão mudar temporariamente para o estado pendente.
Para informações sobre como as listas de aceitação do consumidor interagem com as políticas da organização, consulte Interação entre listas de aceitação do consumidor e políticas da organização.
Limites de lista de aceitação do consumidor
As listas de aceitação do consumidor têm limites de conexão. Esses limites definem o número total de conexões de endpoint e back-end do Private Service Connect que um anexo de serviço pode aceitar do projeto de consumidor especificado ou da rede VPC.
Os produtores podem usar esses limites de conexões para evitar que consumidores individuais consumam endereços IP ou cotas de recursos na rede VPC do produtor. Cada conexão do Private Service Connect aceita é subtraída do limite configurado para um projeto de consumidor ou rede VPC. Os limites são definidos ao create ou atualizar listas de aceitação do consumidor. É possível ver as conexões de um anexo de serviço ao descrever um anexo de serviço.
As conexões propagadas não são contabilizadas nesses limites.
Por exemplo, considere um caso em que um anexo de serviço tenha uma lista de aceitação do consumidor que inclua project-1
e project-2
, ambos com um limite de uma conexão. O projeto project-1
solicita duas conexões, project-2
solicita uma conexão e project-3
solicita uma conexão. Como project-1
tem um limite de uma conexão, a primeira é aceita e a segunda permanece pendente.
A conexão de project-2
é aceita, e a conexão de project-3
permanece pendente. A segunda conexão de project-1
pode ser aceita ao aumentar o limite de project-1
. Se
project-3
for adicionado à lista de aceitação do consumidor, essa conexão mudará de
pendente para aceita.
Reconciliação de conexão
A reconciliação de conexão determina se as atualizações nas listas de aceitação ou rejeição de um anexo de serviço podem afetar as conexões atuais do Private Service Connect. Se a reconciliação de conexão estiver ativada, a atualização de listas de aceitação ou rejeição poderá encerrar as conexões atuais. As conexões que foram rejeitadas anteriormente podem se tornar aceitas. Se a reconciliação de conexão estiver desativada, a atualização das listas de aceitação ou rejeição afetará apenas as conexões novas e pendentes.
Por exemplo, considere um anexo de serviço que tenha várias conexões aceitas de Project-A
. Project-A
está na lista de aceitação do anexo de serviço. O anexo de serviço é atualizado removendo Project-A
da
lista de aceitação.
Se a reconciliação de conexão estiver ativada, todas as conexões existentes de Project-A
farão a transição para PENDING
, o que encerra a conectividade de rede entre as duas redes VPC e interrompe imediatamente o tráfego de rede.
Se a reconciliação de conexão estiver desativada, as conexões atuais de
Project-A
não serão afetadas. O tráfego de rede ainda pode fluir entre as conexões atuais do Private Service Connect. No entanto, novas conexões do Private Service Connect não são permitidas.
Para informações sobre como configurar a reconciliação de conexão para novos anexos de serviço, consulte Publicar um serviço com aprovação explícita.
Para informações sobre como configurar a reconciliação de conexão para anexos de serviço atuais, consulte Configurar a reconciliação de conexão.
Conexões propagadas
Os consumidores que se conectam ao seu anexo de serviço usando endpoints podem ativar a propagação de conexão. As conexões propagadas permitem que as cargas de trabalho em spokes de VPC do consumidor acessem serviços gerenciados em redes VPC dos produtores como se as duas redes VPC estivessem diretamente conectadas por meio de endpoints. Cada conexão propagada consome um endereço IP da sub-rede NAT do anexo de serviço.
É possível acessar o número de conexões propagadas associadas a um endpoint conectado ao visualizar os detalhes de um serviço publicado. Essa contagem não inclui conexões propagadas que são bloqueadas pelo limite de conexões propagadas do produtor.
Limite de conexão propagada
Os anexos de serviço têm um limite de conexões propagadas, o que permite que os produtores de serviços limitem o número de conexões propagadas que podem ser estabelecidas com o anexo de serviço por um único consumidor. Se não for especificado, o limite padrão para as conexões propagadas será de 250.
- Se a preferência de conexão do anexo de serviço for
ACCEPT_MANUAL
, o limite será aplicado a cada projeto ou rede VPC listado na lista de aceitação do consumidor. - Se a preferência de conexão for
ACCEPT_AUTOMATIC
, o limite será aplicado a cada projeto que contiver um endpoint conectado.
Se um consumidor exceder o limite de conexões propagadas, nenhuma outra conexão propagada será criada. Para permitir a criação de endpoints mais propagados, aumente o limite de conexões propagadas. Quando você aumenta esse limite, o Network Connectivity Center cria conexões propagadas que foram bloqueadas pelo limite, desde que as novas conexões não excedam o limite atualizado. A atualização desse limite não afeta as conexões propagadas atuais.
Como evitar o esgotamento da cota
O número total de endpoints do Private Service Connect e
conexões propagadas de qualquer consumidor que podem acessar sua rede VPC
do produtor é controlado pela
cota PSC ILB consumer forwarding rules per producer VPC network
.
Particularmente para
serviços multilocatários,
é importante proteger contra o esgotamento dessa cota.
Use os limites a seguir para se proteger contra o esgotamento da cota:
- Os limites de conexão de lista de aceitação do consumidor controlam o número total de endpoints do Private Service Connect que podem criar conexões com um anexo de serviço de uma única rede VPC ou projeto do consumidor. A redução desses limites não afeta as conexões atuais. Esses limites não se aplicam a conexões propagadas.
- Os limites de conexão propagada controlam o número total de conexões propagadas que podem ser estabelecidas para um anexo de serviço de um único consumidor. A redução desse limite não afeta as conexões propagadas atuais.
Exemplo
O exemplo a seguir mostra como os limites de conexão propagada e os limites de lista de
aceitações do consumidor funcionam em relação à
cota PSC ILB consumer forwarding rules per producer VPC network
.
Considere um caso em que um consumidor criou dois
endpoints em uma rede VPC spoke, spoke-vpc-1
. Os dois endpoints
se conectam a service-attachment-1
em producer-vpc-1
. O spoke está conectado a
um hub do Network Connectivity Center que tem a propagação de conexão ativada, e não há outros spokes conectados a esse hub.
O produtor de serviços configurou service-attachment-1
para ter um limite de quatro listas de aceitação do consumidor para cada projeto na lista de aceitação. O produtor configurou um limite de duas conexões propagadas, especificando que um único projeto pode ter até duas conexões propagadas.
A cota e o uso limite para essa configuração são os seguintes:
Cota / Limite | Uso | Explicação |
---|---|---|
Regras de encaminhamento de consumidor do ILB de PSC por rede VPC do produtor | 2 | um por endpoint |
Limite de conexão de lista de aceitação do consumidor de anexo de serviço para consumer-project-1 |
2 | um por endpoint |
Limite de conexão propagada do anexo de serviço para consumer-project-1 |
0 | nenhuma conexão propagada |
Suponha que consumer-project-1
conecte outro spoke chamado spoke-vpc-2
ao
mesmo hub do Network Connectivity Center que spoke-vpc-1
. Isso cria duas conexões propagadas no consumer-project-1
, uma para cada endpoint atual.
A cota e o uso limite para essa configuração são os seguintes:
Cota / Limite | Uso | Explicação |
---|---|---|
Regras de encaminhamento de consumidor do ILB de PSC por rede VPC do produtor | 4 | uma por endpoint e uma por conexão propagada |
Limite de conexão de lista de aceitação do consumidor de anexo de serviço para consumer-project-1 |
2 | um por endpoint |
Limite de conexão propagada do anexo de serviço para consumer-project-1 |
2 | uma por conexão propagada |
Consumer-project-1
esgotou o limite de conexões propagadas. Se o consumidor adicionar outro spoke VPC, o Private Service Connect não criará nenhuma nova conexão propagada.
Suponha que outro consumidor tenha dois spokes de VPC
em consumer-project-2
. Os spokes se conectam a um hub do Network Connectivity Center com conexões propagadas
ativadas. Um dos spokes de VPC contém um único endpoint que se conecta a service-attachment-1
.
A cota e o uso limite para essa configuração são os seguintes:
Cota / Limite | Uso | Explicação |
---|---|---|
Regras de encaminhamento de consumidor do ILB de PSC por rede VPC do produtor | 6 | quatro de consumer-project-1 e duas de consumer-project-2 |
Limite de conexão de lista de aceitação do consumidor de anexo de serviço para consumer-project-1 |
2 | um por endpoint em consumer-project-1 |
Limite de conexão de lista de aceitação do consumidor de anexo de serviço para consumer-project-2 |
1 | um por endpoint em consumer-project-2 |
Limite de conexão propagada do anexo de serviço para consumer-project-1 |
2 | uma por conexão propagada em consumer-project-1 |
Limite de conexão propagada do anexo de serviço para consumer-project-2 |
1 | uma por conexão propagada em consumer-project-2 |
Configuração do DNS
Para informações sobre a configuração de DNS para serviços publicados e endpoints que se conectam a serviços publicados, consulte Configuração de DNS para serviços.
Configuração de várias regiões
É possível disponibilizar um serviço em várias regiões criando as configurações a seguir.
Configuração do produtor:
Implante o serviço em cada região. Cada instância regional do serviço precisa ser configurada em um balanceador de carga que seja compatível com acesso por um back-end.
Crie um anexo de serviço para publicar cada instância regional do serviço.
Configuração do consumidor:
Crie um back-end para acessar serviços publicados. O back-end é baseado em um balanceador de carga de aplicativo externo global e inclui as seguintes configurações:
Um NEG do Private Service Connect em cada região que aponta para o anexo de serviço dessa região.
Um serviço de back-end que contém os back-ends de NEG.
Nessa configuração, o endpoint encaminha o tráfego usando a política de balanceamento de carga global padrão: primeiro por integridade, e depois pelo local mais próximo ao cliente.
Conversão de versão de IP
Para conexões entre endpoints do Private Service Connect para serviços e anexos de serviço publicados, a versão de IP do endereço IP da regra de encaminhamento do consumidor determina a versão de IP do endpoint e o tráfego que sai do endpoint. A versão IP do endpoint pode ser IPv4 ou IPv6, mas não as duas opções. Os consumidores podem usar um endereço IPv4 se a sub-rede do endereço for pilha única. Os consumidores podem usar um endereço IPv4 ou IPv6 se a sub-rede do endereço for de pilha dupla. Os consumidores podem conectar endpoints IPv4 e IPv6 ao mesmo anexo de serviço, o que pode ser útil para migrar serviços para o IPv6.
Para conexões entre endpoints do Private Service Connect para serviços publicados e anexos de serviço, a versão do IP da regra de encaminhamento do produtor determina a versão do IP do anexo de serviço e o tráfego que sai do anexo de serviço. A versão de IP do anexo de serviço pode ser IPv4 ou IPv6, mas não as duas opções. Os produtores podem usar um endereço IPv4 se a sub-rede do endereço for de pilha única. Os produtores podem usar um endereço IPv4 ou IPv6 se a sub-rede do endereço for de pilha dupla.
A versão IP do endereço IP da regra de encaminhamento do produtor precisa ser compatível com o tipo de pilha da sub-rede NAT do anexo de serviço. Se a regra de encaminhamento do produtor for IPv4, a sub-rede NAT poderá ser de pilha única ou dupla. Se a regra de encaminhamento do produtor for IPv6, a sub-rede NAT precisará ser de pilha dupla.
O Private Service Connect não oferece suporte à conexão de um endpoint IPv4 com um anexo de serviço IPv6. Nesse caso, a criação do endpoint falha e exibe a seguinte mensagem de erro:
Private Service Connect forwarding rule with an IPv4 address
cannot target an IPv6 service attachment.
As seguintes combinações são possíveis para as configurações compatíveis:
- Endpoint IPv4 para anexo de serviço IPv4
- Endpoint IPv6 para anexo de serviço IPv6
-
Endpoint IPv6 para anexo de serviço IPv4
Nessa configuração, o Private Service Connect faz a conversão automaticamente entre as duas versões de IP.
Para conexões entre back-ends e anexos de serviço do Private Service Connect, as regras de encaminhamento do consumidor e do produtor precisam usar IPv4.
Recursos e compatibilidade
indica "sem" indica que um recurso não tem suporte.
Dependendo do balanceador de carga do produtor escolhido, o serviço de produtor pode aceitar acesso por endpoints, back-ends ou ambos.
Suporte para endpoints
Esta seção resume as opções de configuração disponíveis para consumidores e produtores ao usar endpoints para acessar serviços de publicação.
Configuração do consumidor
Veja nesta tabela um resumo das opções de configuração e dos recursos compatíveis dos endpoints que acessam serviços publicados.
Configuração do consumidor (endpoint) | Balanceador de carga do produtor | |||
---|---|---|---|---|
Balanceador de carga de rede de passagem interna | Balanceador de carga de aplicativo interno regional | Balanceador de carga de rede de proxy interno regional | Encaminhamento de protocolo interno (instância de destino) | |
Acesso global do consumidor |
Independente da configuração de acesso global no balanceador de carga |
Somente se o acesso global seja ativado no balanceador de carga antes da criação do anexo de serviço. |
Somente se o acesso global seja ativado no balanceador de carga antes da criação do anexo de serviço. |
Independente da configuração de acesso global no balanceador de carga |
Tráfego do Cloud VPN | ||||
Configuração automática de DNS | Somente IPv4 | Somente IPv4 | Somente IPv4 | Somente IPv4 |
Propagação da conexão | Somente IPv4 | Somente IPv4 | Somente IPv4 | Somente IPv4 |
Endpoints IPv4 |
|
|
|
|
Endpoints IPv6 |
|
|
|
|
Configuração do produtor
Veja nesta tabela um resumo das opções de configuração e dos recursos compatíveis dos serviços publicados que são acessados pelos endpoints.
Configuração do produtor (serviço publicado) | Balanceador de carga do produtor | |||
---|---|---|---|---|
Balanceador de carga de rede de passagem interna | Balanceador de carga de aplicativo interno regional | Balanceador de carga de rede de proxy interno regional | Encaminhamento de protocolo interno (instância de destino) | |
Back-ends de produtor compatíveis |
|
|
|
Não aplicável |
Protocolo de proxy | Somente tráfego TCP | Somente tráfego TCP | ||
Modos de afinidade de sessão | NONE (5 tuplas) CLIENT_IP_PORT_PROTO |
Não aplicável | Não aplicável | Não aplicável |
Versão IP |
|
|
|
|
Diferentes balanceadores de carga oferecem suporte a diversas configurações de porta; alguns balanceadores de carga aceitam uma única porta, alguns aceitam uma variedade de portas e alguns aceitam todas as portas. Para mais informações, consulte Especificações de porta.
Suporte para back-ends
Um back-end do Private Service Connect para serviços publicados requer dois balanceadores de carga: um do consumidor e um do produtor. Esta seção resume as opções de configuração disponíveis para consumidores e produtores ao usar back-ends para acessar serviços de publicação.
Configuração do consumidor
Nesta tabela, descrevemos os balanceadores de carga do consumidor compatíveis com os back-ends do Private Service Connect para serviços publicados, incluindo quais protocolos de serviço de back-end podem ser usados com cada balanceador de carga do consumidor. Os balanceadores de carga do consumidor podem acessar serviços publicados hospedados em balanceadores de carga de produtor compatíveis.
Balanceador de carga do consumidor | Protocolos | Versão IP |
---|---|---|
Balanceador de carga de aplicativo externo global (compatível com várias regiões) Observação: o balanceador de carga de aplicativo clássico não é compatível. |
|
IPv4 |
|
IPv4 | |
|
IPv4 | |
|
IPv4 | |
|
IPv4 | |
|
IPv4 | |
|
IPv4 | |
Balanceador de carga de rede de proxy externo global Para associar esse balanceador de carga a um NEG do Private Service Connect, use a CLI do Google Cloud ou envie uma solicitação de API. Observação: o balanceador de carga de rede de proxy clássico não é compatível. |
|
IPv4 |
Configuração do produtor
Nesta tabela, descrevemos a configuração dos balanceadores de carga do produtor que são compatíveis com os back-ends do Private Service Connect para serviços publicados.
Configuração | Balanceador de carga do produtor | ||
---|---|---|---|
Balanceador de carga de rede de passagem interna | Balanceador de carga de aplicativo interno regional | Balanceador de carga de rede de proxy interno regional | |
Back-ends de produtor compatíveis |
|
|
|
Protocolos da regra de encaminhamento |
|
|
|
Portas da regra de encaminhamento | O uso de uma única porta é recomendado. Consulte Configuração da porta do produtor | Oferece suporte a uma única porta | Oferece suporte a uma única porta |
Protocolo de proxy | |||
Versão IP | IPv4 | IPv4 | IPv4 |
Configuração da porta do produtor
Quando um back-end do consumidor se conecta a um serviço publicado hospedado em um o balanceador de carga de rede de passagem interna, o Google Cloud escolhe uma porta para o consumidor usar. A porta é escolhida com base na configuração da porta da regra de encaminhamento do produtor. Considere o seguinte ao criar a regra de encaminhamento para a carga do produtor balanceador de carga:
- Recomendamos que você especifique uma única porta. Nessa configuração, o back-end do consumidor usa a mesma porta.
Se você especificar várias portas, o seguinte se aplica:
- Se a porta
443
estiver incluída, o back-end do consumidor usará a porta443
. - Se a porta
443
não estiver incluída, o back-end do consumidor usará a primeira porta na lista, depois que ela for classificada em ordem alfabética. Por exemplo, se você especificar a porta80
e a porta1111
, o back-end do consumidor usará a porta1111
. Alterar quais portas são usadas pelos back-ends do produtor pode resultar em uma e interromper interrupções de serviço para os consumidores.
Por exemplo, digamos que você crie um serviço publicado com uma regra de encaminhamento que usa as portas
443
e8443
e as VMs de back-end que respondem nas portas443
e8443
. Quando um back-end do consumidor se conecta a esse serviço, usa a porta443
para comunicação.Se você alterar as VMs de back-end para responder apenas na porta
8443
, a back-end do consumidor não podem mais alcançar o serviço publicado.
- Se a porta
Não usar
--port=ALL
. Se essa configuração for usada, o back-end do consumidor usa a porta1
, que não funciona.
VPC compartilhada
Os administradores de projetos de serviço podem criar anexos de serviço em projetos de serviço de VPC compartilhada que se conectam a recursos em redes VPC compartilhadas.
A configuração é a mesma de um anexo de serviço normal, exceto para o seguinte:
- A regra de encaminhamento do balanceador de carga do produtor está associada a um endereço IP da rede VPC compartilhada. É preciso compartilhar a sub-rede da regra de encaminhamento com o projeto de serviço.
- O anexo de serviço usa uma sub-rede do Private Service Connect da rede VPC compartilhada. Ela precisa ser compartilhada com o projeto de serviço.
Logging
É possível ativar os registros de fluxo de VPC nas sub-redes que contêm as VMs de back-end. Os registros mostram fluxos entre as VMs de back-end e os endereços IP na sub-rede do Private Service Connect.
VPC Service Controls
O VPC Service Controls e o Private Service Connect são compatíveis entre si. Se a rede VPC em que o endpoint do Private Service Connect estiver implantado estiver em um perímetro do VPC Service Controls, esse endpoint faz parte do mesmo perímetro. Todos os Serviços com suporte com o VPC Service Controls que são acessados por meio do endpoint estão sujeitos às políticas desse perímetro do VPC Service Controls.
Quando você cria um endpoint, as chamadas de API do plano de controle são feitas entre os projetos do consumidor e do produtor para estabelecer uma conexão do Private Service Connect. Estabelecer uma conexão do Private Service Connect entre projetos do consumidor e do produtor que não estão no mesmo perímetro do VPC Service Controls não exige autorização explícita com políticas de saída. A comunicação com os Serviços com suporte com o VPC Service Controls por meio do endpoint é protegida pelo perímetro do VPC Service Controls.
Como visualizar as informações de conexão do consumidor
Por padrão, o Private Service Connect converte o endereço IP de origem do consumidor para um endereço em uma das sub-redes do Private Service Connect na rede VPC do fornecedor de serviços. Se você quiser ver o endereço IP de origem original do consumidor, ative o protocolo PROXY ao publicar um serviço. O Private Service Connect oferece suporte à versão 2 do protocolo PROXY.
Nem todos os serviços são compatíveis com o protocolo PROXY. Para mais informações, consulte Recursos e compatibilidade.
Se o protocolo PROXY estiver
ativado, é possível conseguir o endereço IP de origem e o ID da conexão do PSC (pscConnectionId
) do consumidor no
cabeçalho do protocolo PROXY.
O formato dos cabeçalhos do protocolo PROXY depende da versão do IP do endpoint do consumidor. Se o balanceador de carga do anexo de serviço tiver um endereço IPv6, os consumidores poderão se conectar com endereços IPv4 e IPv6. Configure seu aplicativo para receber e ler cabeçalhos do protocolo PROXY para a versão IP do tráfego que ele está recebendo.
Para o tráfego do consumidor que flui por uma conexão propagada, o endereço IP de origem e o ID da conexão do PSC do consumidor referem-se ao endpoint do Private Service Connect que foi propagado.
Quando você ativa o protocolo PROXY para um anexo de serviço, a alteração se aplica apenas a novas conexões. As conexões existentes não incluem o cabeçalho do protocolo PROXY.
Se você ativar o protocolo PROXY, verifique a documentação do software do servidor da Web de back-end para ver informações sobre como analisar e processar cabeçalhos de protocolo PROXY recebidos nos payloads TCP de conexão do cliente. Se o protocolo PROXY estiver ativado no anexo do serviço, mas o servidor da Web de back-end não estiver configurado para processar cabeçalhos de protocolo PROXY, as solicitações da Web poderão estar malformadas. Se as solicitações estiverem incorretas, o servidor não poderá interpretá-las.
O ID de conexão do Private Service Connect (pscConnectionId
) é
codificado no cabeçalho do protocolo PROXY no
formato tipo-comprimento-valor (TLV).
Campo | Comprimento do campo | Valor do campo |
---|---|---|
Tipo | 1 byte | 0xE0 (PP2_TYPE_GCP)
|
Comprimento | 2 bytes | 0x8 (8 bytes) |
Valor | 8 bytes | O pscConnectionId de 8 bytes na ordem de rede |
Visualize o valor pscConnectionId
de 8 bytes da regra de encaminhamento do consumidor ou do anexo de serviço do produtor.
O valor pscConnectionId
é globalmente exclusivo para todas as conexões ativas em um
determinado momento. No entanto, com o tempo, um pscConnectionId
pode ser reutilizado nestes cenários:
Em uma determinada rede VPC, se você excluir um endpoint (regra de encaminhamento) e criar um novo usando o mesmo endereço IP, o mesmo valor
pscConnectionId
poderá ser usado.Se você excluir uma rede VPC que contenha endpoints (regras de encaminhamento), após um período de espera de sete dias, o valor
pscConnectionId
usado para esses endpoints poderá ser utilizado para um endpoint diferente em outra rede VPC.
Você pode usar valores pscConnectionId
para depuração e rastrear as origens de
pacotes.
Um ID de anexo de serviço (pscServiceAttachmentId
) separado de 16 bytes do Private Service Connect está disponível no anexo de serviço do produtor.
O valor pscServiceAttachmentId
é um ID globalmente exclusivo que identifica um
anexo de serviço do Private Service Connect. É possível usar o
valor pscServiceAttachmentId
para visibilidade e depuração. Esse valor não está
incluído no cabeçalho do protocolo PROXY.
Preços
Os preços do Private Service Connect são descritos na página de preços da VPC.
Cotas
O número total de endpoints do Private Service Connect e
conexões propagadas de qualquer consumidor que pode acessar sua
rede VPC de produtor é controlado pela
Cota PSC ILB consumer forwarding rules per producer VPC network
.
Os endpoints contribuem para essa cota até serem excluídos, mesmo que o anexo de serviço associado seja excluído ou configurado para rejeitar a conexão. As conexões propagadas contribuem para essa cota até que o endpoint associado seja excluído, mesmo que a propagação da conexão esteja desativada no hub do Network Connectivity Center ou que o spoke da conexão propagada seja excluído.
Acesso no local
Os serviços do Private Service Connect são disponibilizados usando endpoints. Esses endpoints podem ser acessados de hosts locais compatíveis conectados. Para mais informações, consulte Acessar o endpoint de hosts locais.
Limitações
Os serviços publicados têm as seguintes limitações:
- Os balanceadores de carga do produtor não dão suporte aos seguintes recursos:
- Várias regras de encaminhamento que usam um endereço IP compartilhado (
SHARED_LOADBALANCER_VIP
) - Subconfiguração de back-ends
- O Espelhamento de pacotes não pode espelhar pacotes para o tráfego de serviços publicados do Private Service Connect.
- Use a Google Cloud CLI ou a API para criar um anexo de serviço que aponte para uma regra de encaminhamento usada no encaminhamento de protocolo interno.
Para problemas e soluções alternativas, consulte Problemas conhecidos.