O Cloud Service Mesh e o Traffic Director são agora o Cloud Service Mesh. Para mais informações, consulte a vista geral do Cloud Service Mesh.

Esta página foi traduzida pela API Cloud Translation.

Isolamento para a Cloud Service Mesh

Esta página mostra como configurar a malha de serviços com um melhor isolamento de pedidos para o serviço de back-end através da criação de uma configuração de isolamento.

Esta funcionalidade oferece suporte de isolamento adicional para os back-ends dos seus serviços para evitar o excesso de capacidade entre regiões.

Por predefinição, o Cloud Service Mesh usa o algoritmo de hierarquia por região para decidir para onde o tráfego de utilizadores deve ser encaminhado. Com este algoritmo, o Cloud Service Mesh encaminha o tráfego para a região mais próxima até que os back-ends estejam a funcionar no respetivo limite de capacidade configurado. Depois disso, o tráfego começa a transbordar para uma região mais distante.

Com esta funcionalidade, com base na sua região de frontend e configuração de isolamento, o tráfego é limitado à região mais próxima ou local e não transborda se a região mais próxima estiver a ficar sem capacidade. Isto ajuda a evitar potenciais falhas em cascata e a limitar potenciais indisponibilidades na mesma região. Caso contrário, continua a gerir a configuração do serviço ao nível global.

diagrama de isolamento

A utilização ou não desta funcionalidade depende dos seus exemplos de utilização reais e deve explorar cuidadosamente as seguintes considerações antes de a utilizar:

Se os seus back-ends numa região estiverem sobrecarregados, a malha de serviços na nuvem pode continuar a enviar-lhes tráfego adicional, mesmo que os back-ends noutras regiões possam processar o tráfego. Isto significa que é mais provável que cada região individual fique sobrecarregada devido ao tráfego adicional, e tem de planear em conformidade.
O seu tráfego continua a ser encaminhado com um plano de controlo global. Isto significa que ainda existe a possibilidade de falhas coordenadas a nível global em várias regiões.
Esta funcionalidade é configurada com o recurso serviceLbPolicy. Todas as restrições continuam a aplicar-se.
Com o modo de isolamento ESTRITO, os pedidos falham se não existirem backends de publicação na mesma região.

Existem dois cenários após a aplicação desta funcionalidade:

Isolamento mais próximo

O isolamento regional mais próximo é onde um front-end com back-ends colocados em conjunto é isolado apenas para essa região. Se não estiver disponível nenhum back-end na localização local, é feita a ligação à região do back-end enquanto se otimiza a latência da rede.

Diagrama de isolamento mais próximo

Isolamento rigoroso

O isolamento regional rigoroso é quando as localizações de front-end só podem alcançar back-ends na região local. Os frontends sem backends de publicação na região local vão rejeitar todo o respetivo tráfego.

Diagrama de isolamento rigoroso

Ativar isolamento

gcloud

Siga os passos seguintes para criar uma configuração de isolamento através da CLI do Google Cloud.

Execute o seguinte comando para criar um serviceLbPolicy:
```
gcloud network-services service-lb-policies create my-isolation-policy \
    --isolation-config-granularity=REGION \
    --isolation-config-mode=ISOLATION_MODE \
    --location=global
```
Substitua ISOLATION_MODE por uma das seguintes opções:
1. MAIS PRÓXIMA: o tráfego é enviado para a região mais próxima.
2. ESTRITO: o tráfego falha se não estiverem disponíveis back-ends de publicação na mesma região que o front-end.
Se não for fornecido explicitamente, NEAREST é o valor predefinido. Tenha em atenção que só pode especificar este campo se a flag --isolation-granularity também estiver definida.

Em alternativa, se tiver uma política existente, atualize-a com o seguinte comando:
```
gcloud network-services service-lb-policies update POLICY_NAME \
    --isolation-config-granularity=REGION \
    --isolation-config-mode=ISOLATION_MODE \
    --location=global
```
Substitua POLICY_NAME pelo nome da sua política existente.
Depois de criar ou atualizar um recurso serviceLbPolicy, anexe-o ao recurso backendService:
```
  gcloud compute backend-services update BACKEND_SERVICE_NAME \
  ‐‐service-lb-policy POLICY_URL
```
Substitua BACKEND_SERVICE_NAME pelo nome do seu serviço de back-end.

Desative o isolamento

Para desativar esta funcionalidade, tem duas opções:

Defina o isolationConfigs como não especificado.
Remova o ServiceLbPolicy do serviço se for a única funcionalidade que ativou com esta política

Defina `isolationConfigs` como não especificado

Execute o seguinte comando para definir o isolationConfigs como não especificado:

gcloud network-services service-lb-policies update my-isolation-policy \
  --isolation-config-granularity=unspecified \
  --isolation-config-mode=unspecified \
  --location=global

Remova `ServiceLbPolicy` do serviço

Execute o seguinte comando para remover o ServiceLbPolicy:

gcloud network-services service-lb-policies delete my-isolation-policy --location=global

Capacidade de apoio técnico, diagnóstico e resolução de problemas

Esta secção descreve potenciais problemas após a ativação desta funcionalidade.

Back-ends sobrecarregados

Esta funcionalidade oferece suporte de isolamento e, por isso, o tráfego não é transferido para uma região remota se a região local estiver cheia. Assim, alguns dos seus backends podem ficar sobrecarregados se esta funcionalidade estiver ativada. Se não é este o comportamento que procura, considere desativar esta funcionalidade. Também pode considerar ativar o dimensionamento automático para lidar melhor com as sobrecargas do back-end.

O tráfego foi mudado

Esta funcionalidade impede o excesso de tráfego baseado na capacidade. Assim, se os seus backends estiverem sobrecarregados antes de ativar esta funcionalidade, o tráfego pode já ter sido transferido para uma região remota. Nesse caso, a ativação desta funcionalidade pode fazer com que este tráfego seja novamente deslocado.

O tráfego não foi mudado

Esta funcionalidade impede o excesso de tráfego baseado na capacidade. Assim, se os seus back-ends não estavam sobrecarregados antes de ativar esta funcionalidade, é provável que a região mais próxima seja capaz de processar todo o tráfego. Nesse caso, a ativação desta funcionalidade pode não causar alterações no tráfego a curto prazo.

O tráfego foi mudado depois de os back-ends serem adicionados ou removidos de uma região

Quando esta funcionalidade está ativada, o tráfego pode ser mudado se forem adicionados novos back-ends a uma região. Isto é esperado, uma vez que o Cloud Service Mesh tenta encaminhar o tráfego para estes back-ends para otimizar a latência geral da rede. Da mesma forma, quando os back-ends finais são removidos, o Cloud Service Mesh começa a enviar tráfego para uma região remota. Este comportamento também é o esperado.

Pedidos falhados

Se o modo de isolamento STRICT estiver ativado e não existirem back-ends a servir na mesma região que o front-end, espera-se que o tráfego falhe. Se não for o comportamento pretendido, certifique-se de que tem back-ends em cada uma das regiões onde espera que o tráfego seja enviado.