Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Last reviewed 2023-12-14 UTC
Com o padrão de handover, a arquitetura é baseada no uso de
serviços de armazenamento do Google Cloud para conectar um ambiente de computação privado
a projetos no Google Cloud. Esse padrão se aplica principalmente
às configurações que seguem o
padrão de arquitetura multicloud híbrida de análise,
em que:
As cargas de trabalho em execução em um ambiente de computação privado ou em
outra nuvem fazem o upload de dados para locais de armazenamento compartilhado. Dependendo dos casos de uso, os uploads podem ocorrer em massa ou em incrementos menores.
Cargas de trabalho hospedadas pelo Google Cloud ou outros serviços do Google (por exemplo, análises
de dados e serviços de inteligência artificial) consomem dados
dos locais de armazenamento compartilhado e processam eles em streaming ou em lote.
Arquitetura
O diagrama a seguir mostra uma arquitetura de referência para o padrão de
handover.
O diagrama de arquitetura anterior mostra os seguintes fluxos de trabalho:
No lado do Google Cloud, você implanta cargas de trabalho em uma VPC
de aplicativo. Essas cargas de trabalho podem incluir processamento de dados, análises
e aplicativos front-end relacionados à análise.
Para expor aplicativos front-end com segurança aos usuários, você pode usar
o Cloud Load Balancing ou o gateway de API.
Um conjunto de buckets do Cloud Storage ou filas do Pub/Sub faz o upload dos dados
do ambiente de computação privado e os disponibiliza
para o processamento por cargas de trabalho implantadas no Google Cloud. Usando
as políticas do Identity and Access Management (IAM),
é possível restringir o acesso a cargas de trabalho confiáveis.
Use o
VPC Service Controls
para restringir o acesso a serviços e minimizar riscos de exfiltração de dados injustificada de serviços do Google Cloud.
Nesta arquitetura, a comunicação com buckets do Cloud Storage
ou do Pub/Sub é realizada em redes públicas ou pela
conectividade privada usando VPN, Cloud Interconnect ou Cross-Cloud Interconnect. Normalmente, a decisão sobre como se conectar
depende de vários aspectos, como:
Volume de tráfego esperado
Configuração temporária ou permanente
Requisitos de segurança e conformidade
Variação
As opções de design descritas no
padrão de entrada controlado,
que usa endpoints do Private Service Connect para APIs do Google, também podem
ser aplicadas a esse padrão.
Especificamente, ele dá acesso ao Cloud Storage, BigQuery,
e outras APIs de serviços do Google. Essa abordagem requer um endereçamento IP privado em
uma conexão de rede híbrida e multicloud, como VPN, Cloud Interconnect e Cross-Cloud Interconnect.
Práticas recomendadas
Bloqueie o acesso a buckets do Cloud Storage e
tópicos do Pub/Sub.
Quando aplicável, use soluções de movimentação de dados integradas e com priorização da nuvem
como o pacote de soluções
do Google Cloud.
Para atender às suas necessidades de caso de uso, essas soluções foram projetadas para
mover, integrar e transformar os dados com eficiência.
Avalie os diferentes fatores que influenciam as opções de transferência de dados
como custo, tempo esperado de transferência e segurança. Para mais
informações, consulte
Avaliando as opções de transferência.
Para minimizar a latência e evitar a transferência e a movimentação de alto volume de dados
na Internet pública, use o Cloud Interconnect ou
Cross-Cloud Interconnect, incluindo o acesso aos
endpoints do Private Service Connect na nuvem privada virtual para
APIs do Google.
Para proteger os serviços do Google Cloud nos projetos e reduzir
o risco de exfiltração de dados, use o VPC Service Controls. Esses controles de serviço
podem especificar perímetros de serviço no nível do projeto ou da rede VPC.
Comunique-se com cargas de trabalho de análise de dados veiculadas publicamente que são
hospedadas em instâncias de VM usando um gateway de API, um balanceador de carga ou um
dispositivo de rede virtual. Use um desses métodos de comunicação para aumentar a
segurança e evitar tornar essas instâncias diretamente acessíveis na
Internet.
Se for necessário ter acesso à Internet, o
Cloud NAT
pode ser usado na mesma VPC para lidar com o tráfego de saída das instâncias
na Internet pública.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2023-12-14 UTC."],[[["\u003cp\u003eThe handover pattern uses Google Cloud storage services to bridge data between private computing environments and Google Cloud projects, especially within analytics hybrid multicloud architectures.\u003c/p\u003e\n"],["\u003cp\u003eData is uploaded from private environments to shared Cloud Storage buckets or Pub/Sub queues, where Google Cloud workloads can then consume and process it.\u003c/p\u003e\n"],["\u003cp\u003eAccess to Cloud Storage and Pub/Sub can be secured using IAM policies and VPC Service Controls, limiting access to trusted workloads and minimizing data exfiltration risks.\u003c/p\u003e\n"],["\u003cp\u003eConnectivity between private environments and Google Cloud can be over public networks, VPN, Cloud Interconnect, or Cross-Cloud Interconnect, depending on factors like traffic volume, security, and setup duration.\u003c/p\u003e\n"],["\u003cp\u003eTo minimize latency and data movement over public networks, utilize Cloud Interconnect or Cross-Cloud Interconnect, and for added protection, use Private Service Connect endpoints within your Virtual Private Cloud for accessing Google APIs.\u003c/p\u003e\n"]]],[],null,["# Handover patterns\n\nWith the *handover* pattern, the architecture is based on using\nGoogle Cloud-provided storage services to connect a private computing\nenvironment to projects in Google Cloud. This pattern applies primarily to\nsetups that follow the\n[*analytics hybrid multicloud* architecture pattern](/architecture/hybrid-multicloud-patterns#analytics-hybrid-multicloud-patterns),\nwhere:\n\n- Workloads that are running in a private computing environment or in another cloud upload data to shared storage locations. Depending on use cases, uploads might happen in bulk or in smaller increments.\n- Google Cloud-hosted workloads or other Google services (data analytics and artificial intelligence services, for example) consume data from the shared storage locations and process it in a streaming or batch fashion.\n\nArchitecture\n------------\n\nThe following diagram shows a reference architecture for the handover\npattern.\n\nThe preceding architecture diagram shows the following workflows:\n\n- On the Google Cloud side, you deploy workloads into an application VPC. These workloads can include data processing, analytics, and analytics-related frontend applications.\n- To securely expose frontend applications to users, you can use Cloud Load Balancing or API Gateway.\n- A set of Cloud Storage buckets or Pub/Sub queues uploads data from the private computing environment and makes it available for further processing by workloads deployed in Google Cloud. Using Identity and Access Management (IAM) policies, you can restrict access to trusted workloads.\n- Use [VPC Service Controls](/vpc-service-controls) to restrict access to services and to minimize unwarranted data exfiltration risks from Google Cloud services.\n- In this architecture, communication with Cloud Storage buckets, or Pub/Sub, is conducted over public networks, or through private connectivity using VPN, Cloud Interconnect, or Cross-Cloud Interconnect. Typically, the decision on how to connect depends on several aspects, such as the following:\n - Expected traffic volume\n - Whether it's a temporary or permanent setup\n - Security and compliance requirements\n\nVariation\n---------\n\nThe design options outlined in the\n[*gated ingress* pattern](/architecture/hybrid-multicloud-secure-networking-patterns/gated-ingress),\nwhich uses Private Service Connect endpoints for Google APIs, can also\nbe applied to this pattern.\nSpecifically, it provides access to Cloud Storage, BigQuery,\nand other Google Service APIs. This approach requires private IP addressing over\na hybrid and multicloud network connection such as VPN, Cloud Interconnect\nand Cross-Cloud Interconnect.\n\nBest practices\n--------------\n\n- Lock down access to Cloud Storage buckets and Pub/Sub topics.\n- When applicable, use cloud-first, integrated data movement solutions like the Google Cloud [suite of solutions](/data-movement). To meet your use case needs, these solutions are designed to efficiently move, integrate, and transform data.\n- Assess the different factors that influence the data transfer options,\n such as cost, expected transfer time, and security. For more\n information, see\n [Evaluating your transfer options](/architecture/migration-to-google-cloud-transferring-your-large-datasets#step_3_evaluating_your_transfer_options).\n\n- To minimize latency and prevent high-volume data transfer and movement over\n the public internet, consider using Cloud Interconnect or\n Cross-Cloud Interconnect, including accessing\n Private Service Connect endpoints within your Virtual Private Cloud for\n Google APIs.\n\n- To protect Google Cloud services in your projects and to mitigate\n the risk of data exfiltration, use VPC Service Controls. These service\n controls can specify service perimeters at the project or VPC network level.\n\n - You can [extend service perimeters](/vpc-service-controls/docs/overview#hybrid_access) to a hybrid environment over an authorized VPN or Cloud Interconnect. For more information about the benefits of service perimeters, see [Overview of VPC Service Controls](/vpc-service-controls/docs/overview).\n- Communicate with publicly published data analytics workloads that are\n hosted on VM instances through an API gateway, a load balancer, or a\n virtual network appliance. Use one of these communication methods for added\n security and to avoid making these instances directly reachable from the\n internet.\n\n- If internet access is required,\n [Cloud NAT](/nat/docs)\n can be used in the same VPC to handle outbound traffic from the instances\n to the public internet.\n\n- Review the\n [general best practices](/architecture/hybrid-multicloud-secure-networking-patterns/general-best-practices)\n for hybrid and multicloud networking topologies."]]
