Em uma arquitetura de nuvem que usa o arquétipo básico de implantação por zona, o
aplicativo é executado em uma única zona Google Cloud , conforme mostrado no
diagrama a seguir:
Para se recuperar de interrupções de zona, use uma arquitetura de zona dupla
em que uma réplica passiva da pilha de aplicativos é provisionada em uma segunda
zona (failover), conforme mostrado no diagrama a seguir:
Se ocorrer uma interrupção na zona principal, promova o banco de dados em espera
como o banco de dados primário (gravação) e atualize o balanceador de carga para enviar tráfego
ao front-end na zona de failover.
Casos de uso
Veja a seguir exemplos de casos de uso em que o arquétipo de implantação zonal é uma escolha adequada:
Ambientes de desenvolvimento e teste do Cloud: é possível usar o arquétipo de implantação zonal para criar um ambiente de baixo custo para desenvolvimento e testes.
Aplicativos que não precisam de alta disponibilidade: o arquétipo de implantação zonal pode ser suficiente para aplicativos que tolerem a inatividade.
Rede de baixa latência entre componentes de aplicativos: uma arquitetura de zona única
pode ser adequada para aplicativos como computação em lote
que precisam de conexões de rede de baixa latência e alta largura de banda entre os
nós de computação.
Migração de cargas de trabalho comuns: o arquétipo de implantação zonal fornece um caminho de migração na nuvem para apps locais comuns para os quais você não tem controle sobre o código ou que não oferecem suporte a arquiteturas além de outras uma topologia ativa-passiva básica.
Executar software com restrição de licença: o arquétipo de implantação por zona pode ser adequado para sistemas com restrição de licenças em que executar mais de uma instância por vez é muito caro ou não é permitido.
Considerações sobre o design
Ao criar uma arquitetura baseada no arquétipo de implantação zonal,
considere o possível tempo de inatividade durante interrupções de zona e região.
Falhas na zona
Se o aplicativo for executado em uma única zona sem zona de failover, quando ocorrer uma falha
na zona, o aplicativo não poderá atender às solicitações. Para evitar essa situação,
é preciso manter uma réplica passiva da pilha de infraestrutura em outra
zona (failover) na mesma região. Se ocorrer uma interrupção na zona principal,
será possível promover o banco de dados na zona de failover para ser o primário e
garantir que o tráfego de entrada seja roteado para o front-end na zona de failover.
Depois que o Google resolver a interrupção, você poderá voltar para a
zona principal ou torná-la a nova zona de failover.
Falhas na região
Se ocorrer uma falha temporária na região, você precisará aguardar o Google
resolver a interrupção e verificar se o aplicativo funciona conforme o esperado. Se você precisar de robustez
contra interrupções de região, use o arquétipo de implantação multirregional.
[[["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 2024-11-20 UTC."],[[["\u003cp\u003eThe zonal deployment archetype involves running an application within a single Google Cloud zone, suitable for environments like development, testing, or applications that can tolerate downtime.\u003c/p\u003e\n"],["\u003cp\u003eTo recover from zone outages, a dual-zone architecture can be implemented, using a passive replica in a failover zone, that you can promote to primary in case of a primary zone outage.\u003c/p\u003e\n"],["\u003cp\u003eThis architecture is appropriate for applications requiring low-latency networking between components, migrating commodity workloads, or operating license-restricted software.\u003c/p\u003e\n"],["\u003cp\u003eDuring zone outages in a single-zone setup, the application becomes unavailable; therefore, using a failover zone is recommended to ensure continued operation.\u003c/p\u003e\n"],["\u003cp\u003eRegion outages will cause service interruption, so for applications needing protection from this, a multi-regional deployment archetype should be considered instead.\u003c/p\u003e\n"]]],[],null,["# Google Cloud zonal deployment archetype\n\nThis section of the\n[Google Cloud deployment archetypes](/architecture/deployment-archetypes)\nguide describes the zonal deployment archetype.\n\nIn a cloud architecture that uses the basic zonal deployment archetype, the\napplication runs in a single Google Cloud zone, as shown in the following\ndiagram:\n\nTo be able to recover from zone outages, you can use a dual-zone architecture\nwhere a passive replica of the application stack is provisioned in a second\n(failover) zone, as shown in the following diagram:\n\nIf an outage occurs in the primary zone, you can promote the standby database\nto be the primary (write) database and update the load balancer to send traffic\nto the frontend in the failover zone.\n| **Note:** For more information about region-specific considerations, see [Geography and regions](/docs/geography-and-regions#regions_and_zones).\n\nUse cases\n---------\n\nThe following are examples of use cases for which the zonal deployment\narchetype is an appropriate choice:\n\n- **Cloud development and test environments**: You can use the zonal deployment archetype to build a low-cost environment for development and testing.\n- **Applications that don't need high availability**: The zonal deployment archetype might be sufficient for applications that can tolerate downtime.\n- **Low-latency networking between application components**: A single-zone architecture might be well suited for applications such as batch computing that need low-latency and high-bandwidth network connections among the compute nodes.\n- **Migration of commodity workloads**: The zonal deployment archetype provides a cloud migration path for commodity on-premises apps for which you have no control over the code or that can't support architectures beyond a basic active-passive topology.\n- **Running license-restricted software**: The zonal deployment archetype might be well suited for license-restricted systems where running more than one instance at a time is either too expensive or isn't permitted.\n\nDesign considerations\n---------------------\n\nWhen you build an architecture that's based on the zonal deployment archetype,\nconsider the potential downtime during zone and region outages.\n\n### Zone outages\n\nIf the application runs in a single zone with no failover zone, then when a zone\noutage occurs, the application can't serve requests. To prevent this situation,\nyou must maintain a passive replica of the infrastructure stack in another\n(failover) zone in the same region. If an outage occurs in the primary zone, you\ncan promote the database in the failover zone to be the primary database, and\nensure that incoming traffic is routed to the frontend in the failover zone.\nAfter Google resolves the outage, you can choose to either *fail back* to the\nprimary zone or make it the new failover zone.\n| **Note:** For more information about region-specific considerations, see [Geography and regions](/docs/geography-and-regions#regions_and_zones).\n\n### Region outages\n\nIf a region outage occurs, you must wait for Google to resolve the outage and\nthen verify that the application works as expected. If you need robustness\nagainst region outages, consider using the multi-regional deployment archetype.\n\nReference architecture\n----------------------\n\nFor a reference architecture that you can use to design a zonal deployment on\nCompute Engine VMs, see\n[Single-zone deployment on Compute Engine](/architecture/single-zone-deployment-compute-engine)."]]
