Padrões de arquitetura híbrida e em várias nuvens

Este artigo é a segunda parte de uma série de várias partes, em que são discutidas implementações híbridas e em várias nuvens, padrões de arquitetura e topologias de rede. Nesta parte, exploramos padrões comuns de arquitetura híbrida e em várias nuvens. No artigo, descrevemos em quais cenários esses padrões são mais adequados e indicamos as práticas recomendadas para implementá-los usando o Google Cloud Platform (GCP).

A série consiste nestas partes:

Cada empresa tem um portfólio exclusivo de cargas de trabalho de aplicativos, que estabelecem requisitos e restrições na arquitetura de uma configuração híbrida ou em várias nuvens. Você precisa projetar e adaptar sua arquitetura para atender a essas restrições e requisitos, mas pode confiar em alguns padrões comuns.

Os padrões se dividem em duas categorias:

  • Padrões que dependem de uma implantação distribuída de aplicativos. O objetivo desses padrões é executar um aplicativo no ambiente de computação que seja mais adequado, aproveitando as diferentes propriedades e características dos ambientes de computação.

  • Padrões baseados em implementações redundantes de aplicativos. Nesses padrões, você implanta os mesmos aplicativos em vários ambientes de computação com o objetivo de aumentar a capacidade ou a resiliência.

Padrões de implantação distribuída

Ao migrar de um ambiente de computação clássico para uma configuração híbrida ou de várias nuvens, pense nas restrições impostas pelos aplicativos atuais. Também pode ser útil aproveitar os recursos exclusivos, oferecidos em cada ambiente de computação. Esses padrões distribuídos visam atingir um equilíbrio ponderável entre os dois objetivos.

Híbrido em camadas

A maioria dos aplicativos pode ser categorizada como de front-end ou back-end.

  • Os aplicativos de front-end estão diretamente expostos a usuários finais ou dispositivos. Como resultado, esses aplicativos geralmente são sensíveis ao desempenho e podem estar sujeitos a frequentes mudanças de versões, à medida que novos recursos e melhorias são desenvolvidos. Como eles geralmente dependem de aplicativos de back-end para armazenar e gerenciar dados, os aplicativos de front-end geralmente são sem estado ou gerenciam apenas pequenos volumes de dados.

  • Os aplicativos de back-end geralmente se concentram no gerenciamento de dados. Entre os principais desafios desses aplicativos, estão o gerenciamento de dados em volume e a respectiva proteção adequada. Novas versões de aplicativos de back-end tendem a ser menos frequentes do que para aplicativos de front-end.

A ideia do padrão híbrido em camadas é se concentrar primeiro na implantação de aplicativos de front-end atuais para a nuvem pública. Nesse padrão, você reutiliza os aplicativos de back-end atuais que permanecem no seu ambiente de computação particular. Você migra aplicativos front-end caso a caso.

O diagrama a seguir mostra um padrão híbrido em camadas típico.

padrão híbrido em camadas

Com o tempo, a fração de aplicativos que você implanta na nuvem aumenta, a ponto de fazê-lo pensar também na possibilidade de mover aplicativos de back-end para a nuvem pública.

Vantagens

Concentrar-se em aplicativos de front-end primeiro tem várias vantagens:

  • Aplicativos de front-end dependem de back-ends e, às vezes, de outros front-ends, mas os back-ends não dependem de front-ends. Portanto, isolar e migrar aplicativos de front-end tende a ser menos complexo do que migrar aplicativos de back-end, o que pode ter dependências complexas.

  • Como os aplicativos de front-end geralmente são sem estado ou não gerenciam dados por si, eles tendem a ser menos difíceis de migrar.

A implantação na nuvem de aplicativos de front-end atuais ou recém-desenvolvidos tem várias vantagens importantes:

  • Muitos aplicativos de front-end estão sujeitos a alterações frequentes. A execução desses aplicativos na nuvem pública simplifica a configuração de um processo de integração contínua/implantação contínua (CI/CD, na sigla em inglês) que pode ser usado para implantar atualizações de maneira eficiente e automatizada.

  • Os front-ends sensíveis ao desempenho e aqueles que estão sujeitos a alterações frequentes podem se beneficiar substancialmente do balanceamento de carga, das implantações multirregionais e dos recursos de escalonamento automático, permitidos por uma implantação em nuvem.

  • Seja implementando interfaces de usuário ou APIs ou processando a ingestão de dados da Internet das Coisas (IoT, na sigla em inglês), os aplicativos de front-end podem se beneficiar dos recursos oferecidos pelos serviços em nuvem, como Firebase, Cloud CDN ou Cloud IoT.

Caso seus back-ends gerenciem dados que estão sujeitos a restrições regulamentares ou relacionadas a alguma jurisdição, mantenha-os no ambiente de computação particular, permanentemente ou pelo menos até encontrar um jeito de trabalhar dentro das restrições.

Também é possível aplicar o padrão híbrido em camadas ao contrário, ainda que seja menos comum, implantando back-ends na nuvem e mantendo front-ends em ambientes de computação particulares. Essa abordagem se aplica melhor quando você está lidando com um front-end pesado e monolítico. Nesses casos, pode ser mais fácil extrair iterativamente a funcionalidade de back-end e implantar esses novos back-ends na nuvem.

Práticas recomendadas

Quando você estiver aplicando o padrão híbrido em camadas, tenha em mente as seguintes práticas:

  • Use uma topologia de saída controlada ou em malha. Como a maior parte da interação do usuário envolve sistemas que se conectam a vários ambientes de computação, é importante ter conectividade rápida e de baixa latência entre esses sistemas. Por isso, é essencial projetar para alta disponibilidade, baixa latência e níveis de rendimento apropriados.

  • Para minimizar a latência de comunicação entre os ambientes, escolha uma região do GCP e um local de interconexão que estejam geograficamente próximos ao seu ambiente de computação particular.

  • Em uma configuração híbrida em camadas, há volumes de dados maiores chegando ao GCP (entrada) do que passando do GCP para o ambiente de computação particular (saída). Ainda assim, saiba que o tráfego que sai do GCP está sujeito a preços de saída. A utilização de Interconexão dedicada ou peering direto pode ajudar a reduzir esses encargos.

  • Verifique se a comunicação entre os ambientes é unidirecional. Os aplicativos de front-end que estão em execução na nuvem pública têm permissão para se comunicar com back-ends que estão sendo executados em ambientes de computação particulares, mas não o contrário.

  • Como os dados trocados entre os ambientes podem ser confidenciais, verifique se toda a comunicação é criptografada usando túneis de rede privada virtual (VPN, em inglês), Transport Layer Security (TLS) ou ambos.

  • Recomendamos a implantação de um gateway de API como fachada para serviços de back-end atuais, principalmente quando os protocolos, as APIs e os mecanismos de autenticação são inconsistentes nos back-ends. Além de servir como uma camada de unificação, um gateway de API pode servir como um ponto de estrangulamento. Com esse gateway, é possível implementar outras medidas de segurança e auditoria que se apliquem a todas as comunicações entre ambientes.

  • Estabeleça uma identidade comum entre os ambientes, para que a autenticação dos sistemas possa ser feita com segurança entre os limites do ambiente.

Para as cargas de trabalho individuais, analise estas outras práticas recomendadas:

  • O foco está nos aplicativos de front-end nesse padrão, mas fique atento à necessidade de modernizar os aplicativos de back-end. Se o ritmo de desenvolvimento de back-ends for substancialmente mais lento do que de front-ends, a diferença pode causar complexidade extra nos projetos.

  • Para ativar as migrações de transformação e movimentação, use o Kubernetes como a camada de ambiente de execução comum entre o GCP e os ambientes de computação particulares. É possível usar o Kubernetes para modernizar uma carga de trabalho e migrar para o GCP em momentos diferentes, o que pode ser essencial quando uma carga de trabalho depende muito de outra e não pode ser migrada individualmente.

  • Evite exigir comunicação bidirecional entre ambientes. Para isso, pense na implantação de sistemas de CI/CD na nuvem pública.

  • Em um cenário híbrido em camadas, use ferramentas consistentes e processos de CI/CD em ambientes para aumentar a eficiência operacional. Esta prática não é obrigatória.

  • Ao usar o Kubernetes para executar cargas de trabalho de front-end, use serviços sem seletores para disponibilizar qualquer serviço ou gateway de API que esteja em execução no ambiente de computação particular. Quando você usa os domínios de stub do Kubernetes, é possível integrar-se a sistemas de descoberta de serviço baseados em DNS externos, como o Consul.

Várias nuvens particionadas

O padrão de várias nuvens particionadas combina vários ambientes de nuvem pública, operados por diferentes fornecedores, o que oferece flexibilidade para implantação de um aplicativo no ambiente de computação ideal. O diagrama a seguir mostra padrão típico de várias nuvens particionadas.

padrão de várias nuvens particionadas

É possível manter a capacidade de transferir cargas de trabalho de um ambiente de nuvem pública para outro, conforme necessário. Nesse caso, a portabilidade da carga de trabalho se torna um requisito importante. Quando você implanta cargas de trabalho em vários ambientes de computação e quer manter a capacidade de mover cargas de trabalho entre esses ambientes, é preciso deixar de lado a diferenças entre eles.

O GCP fornece um conjunto avançado de serviços que pode ser usado para implantar suas cargas de trabalho de diferentes maneiras. Ainda assim, em algumas situações, faz sentido combinar o GCP com outro provedor de nuvem e particionar suas cargas de trabalho em ambientes de nuvem. Veja alguns exemplos:

  • Para evitar o comprometimento com um único fornecedor, você distribui aplicativos em vários provedores de nuvem.

  • Por motivos regulamentares, você disponibiliza um determinado segmento da sua base de usuários e dados de um país onde o GCP ainda não tenha presença.

  • Você implanta aplicativos em vários provedores de nuvem de maneira que possa escolher entre os melhores serviços oferecidos pelos provedores.

Vantagens

Aqui estão algumas vantagens importantes do padrão de várias nuvens particionadas:

  • É possível evitar a dependência de um único fornecedor. Esse padrão ajuda a reduzir o risco estratégico e oferece flexibilidade para mudar planos ou parcerias posteriormente.

  • Quando você mantém a portabilidade das cargas de trabalho, é possível otimizar suas operações deslocando as cargas de trabalho entre os ambientes de computação.

Práticas recomendadas

  • Avalie as vantagens estratégicas de uma configuração de várias nuvens particionadas, em relação à complexidade extra que essa configuração traz. O trabalho de desenvolvimento, teste e operações aumenta quando você consegue portabilidade de carga de trabalho e ferramentas consistentes em ambientes de várias nuvens.

  • Use um ambiente com várias nuvens somente para cargas de trabalho essenciais ou se, por motivos legais ou regulamentares, um único ambiente de nuvem pública não puder acomodar as cargas de trabalho.

  • Minimize dependências entre sistemas que estão sendo executados em diferentes ambientes de nuvem pública, especialmente quando a comunicação é tratada de maneira síncrona. Essas dependências podem diminuir o desempenho e a disponibilidade geral.

  • Para se abstrair das diferenças entre os ambientes, avalie o uso de contêineres e Kubernetes.

  • Verifique se os processos e ferramentas de CI/CD para implantação e monitoramento são consistentes em todos os ambientes de nuvem.

  • Use a topologia em malha ou controlada.

  • Como os dados que são trocados entre os ambientes podem ser confidenciais, verifique se toda a comunicação é criptografada usando túneis VPN, TLS ou ambos.

  • Estabeleça uma identidade comum entre os ambientes, para que a autenticação dos sistemas possa ser feita com segurança entre os limites do ambiente.

  • Ao usar o Kubernetes, avalie o uso do ExternalDNS para tornar os serviços detectáveis pelo nome DNS em todos os ambientes de computação.

  • É possível usar os balanceadores de carga do GCP baseados em IP do anycast para balancear solicitações em várias regiões do GCP, mas não é possível usá-los para distribuir solicitações de usuários em várias nuvens. Para essa distribuição, é preciso usar o round robin ou Geo DNS oferecido pelos provedores de serviços como NS1, Dyn ou Akamai.

Análise dos padrões híbrido/várias nuvens

Nos sistemas corporativos, a maioria das cargas de trabalho se enquadra nestas categorias:

  • Cargas de trabalho transacionais incluem aplicativos interativos como vendas, processamento financeiro, planejamento de recursos corporativos ou comunicação.

  • Cargas de trabalho analíticas incluem aplicativos para transformação, análise, refino ou visualização de dados, com o objetivo de ajudar nos processos de tomada de decisão.

Embora os sistemas analíticos recebam os dados deles dos sistemas transacionais, consultando APIs ou acessando bancos de dados, na maioria das empresas os sistemas analíticos e transacionais tendem a ser separados e ter pouca relação. A ideia do padrão analítico híbrido/várias nuvens é aproveitar essa divisão precedente ao executar os dois tipos de cargas de trabalho em dois ambientes de computação diferentes. Os dados brutos são extraídos primeiro das cargas de trabalho que estão sendo executadas no ambiente de computação particular e, depois, carregados no GCP, onde são usados para processamento analítico. Alguns dos resultados podem então ser retornados aos sistemas transacionais.

padrão analítico de várias nuvens

Vantagens

A execução de cargas de trabalho analíticas na nuvem tem muitas vantagens importantes:

  • As cargas de trabalho analíticas geralmente precisam processar quantidades substanciais de dados, o que pode ser feito em bursts. Portanto, elas são especialmente adequadas para serem implantadas em um ambiente de nuvem pública. Ao dimensionar recursos de computação dinamicamente, é possível processar rapidamente grandes conjuntos de dados, sem a necessidade de investimentos iniciais ou do provisionamento de equipamentos de computação em excesso.

  • O GCP fornece um conjunto avançado de serviços para gerenciar dados em todo o respectivo ciclo de vida, desde a aquisição inicial, passando pelo processamento e a análise, até a visualização final.

  • O Cloud Storage é adequado para criar um data lake.

  • Tráfego de entrada: a movimentação de dados do ambiente de computação particular para o GCP é gratuita.

Práticas recomendadas

Para implementar o padrão analítico híbrido/de várias nuvens, tenha em mente as seguintes práticas recomendadas:

Híbrido de borda

A execução de cargas de trabalho na nuvem exige que os clientes tenham conectividade de Internet rápida e confiável. Considerando as redes atuais, esse requisito raramente representa um desafio para a adoção da nuvem. Existem cenários em que não é possível confiar na conectividade contínua:

  • Plataformas petrolíferas, navios e outros veículos podem estar conectados apenas intermitentemente ou ter acesso somente a links de satélite de alta latência.

  • Fábricas ou usinas elétricas podem estar conectadas à Internet. Essas instalações podem ter requisitos de confiabilidade que excedam as garantias de disponibilidade do link.

  • Lojas ou supermercados podem estar conectados apenas de vez em quando ou usar links que não forneçam a confiabilidade ou capacidade necessárias para gerenciar transações críticas para os negócios.

O padrão híbrido de borda soluciona esses desafios, executando cargas de trabalho urgentes em termos de tempo e negócios localmente, na borda da rede, enquanto usa a nuvem para todos os outros tipos de cargas de trabalho. Em uma configuração híbrida de borda, o link da Internet é um componente não crítico que é usado no gerenciamento e para sincronizar ou fazer upload de dados, geralmente de maneira assíncrona, mas não está envolvido em transações urgentes em termos de tempo ou de negócios.

padrão híbrido de borda

Vantagens

A execução de determinadas cargas de trabalho na borda e de outras na nuvem tem muitas vantagens:

  • A execução na borda de cargas de trabalho urgentes em termos de tempo e negócios ajuda a garantir baixa latência e autossuficiência. Se a conectividade com a Internet falhar ou estiver temporariamente indisponível, você ainda poderá executar todas as transações importantes. Ao mesmo tempo, é possível se beneficiar do uso da nuvem em uma parte significativa da sua carga de trabalho geral.

  • É possível reutilizar os investimentos atuais em equipamentos de computação e armazenamento.

  • Com o tempo, é possível reduzir gradualmente a fração de cargas de trabalho que são executadas na borda, seja reformulando determinados aplicativos ou equipando alguns pontos de presença com links de Internet mais confiáveis.

  • O tráfego de entrada, ou seja, a movimentação de dados da borda para o GCP, é gratuito.

Práticas recomendadas

Esteja atento às seguintes recomendações ao implementar o padrão híbrido de borda:

  • Se a comunicação for unidirecional, use a topologia de entrada controlada. Para comunicação bidirecional, use a topologia de entrada e saída controlada.

  • Minimize as dependências entre os sistemas que estão sendo executados na borda e os sistemas em execução no ambiente de nuvem. Cada dependência pode minar as vantagens de confiabilidade e latência de uma configuração híbrida de borda.

  • Para gerenciar e operar vários locais de borda de maneira eficiente, tenha um plano de controle centralizado na nuvem.

  • Garanta que os processos de CI/CD, com as ferramentas para implantação e monitoramento, sejam consistentes em todos os ambientes de nuvem e borda.

  • Avalie o uso de contêineres e Kubernetes para abstrair as diferenças entre vários locais de borda e também entre os locais de borda e a nuvem. Como o Kubernetes fornece uma camada de ambiente de execução comum, é possível desenvolver, executar e operar cargas de trabalho consistentemente em ambientes de computação e mover cargas de trabalho entre borda e nuvem.

  • Estabeleça uma identidade comum entre os ambientes, para que a autenticação dos sistemas possa ser feita com segurança entre os limites do ambiente.

  • Como os dados trocados entre os ambientes podem ser confidenciais, garanta que toda a comunicação seja criptografada usando túneis VPN, TLS ou ambos.

Padrões de implantação redundantes

As seções a seguir exploram padrões comuns que dependem de uma implementação redundante de aplicativos em vários ambientes de computação. Nesses padrões, você implanta os mesmos aplicativos em vários ambientes de computação com o objetivo de aumentar a capacidade ou a resiliência.

Ambiente híbrido

A ideia do padrão de ambiente híbrido é manter o ambiente de produção de uma carga de trabalho no data center atual, mas usar a nuvem pública para outros ambientes de que não sejam de produção.

Ao avaliar quais cargas de trabalho migrar, talvez você perceba casos em que a execução de um aplicativo específico na nuvem pública apresenta desafios:

  • Restrições relativas a uma jurisdição ou regulatórias podem exigir que você mantenha dados em um país específico.
  • Termos de licenciamento de terceiros podem impedir que você opere determinados softwares em um ambiente de nuvem.
  • Um aplicativo pode exigir acesso a dispositivos de hardware disponíveis apenas localmente, como a movimentação de cargas de trabalho.

Nesses casos, tenha em mente não apenas o ambiente de produção, mas todos os ambientes envolvidos no ciclo de vida de um aplicativo, incluindo sistemas de desenvolvimento, teste e preparo. As restrições que podem transformar a migração de nuvem em um desafio geralmente se aplicam ao ambiente de produção e aos respectivos dados, mas não a outros ambientes.

O diagrama a seguir mostra um típico padrão híbrido de ambiente.

padrão híbrido de ambiente

Executar sistemas de desenvolvimento e teste em ambientes diferentes dos sistemas de produção pode parecer arriscado e contrariar as práticas recomendadas atuais ou as tentativas de minimizar as diferenças entre esses ambientes. Essas preocupações se justificam, mas não se aplicam se você distinguir entre os cenários dos processos de desenvolvimento e teste:

  • Os processos de desenvolvimento, teste e implantação são diferentes para cada aplicativo, mas eles geralmente envolvem variações dos seguintes cenários:

    • Desenvolvimento: criar um candidato de versão.
    • Teste funcional ou teste de aceitação do usuário: verificar se o candidato de versão atende aos requisitos funcionais.
    • Teste de desempenho e confiabilidade: verificar se o candidato de versão atende aos requisitos não funcionais.
    • Teste de implantação ou preparo: verificar se o procedimento de implantação funciona.
    • Produção.

Raramente é prático realizar mais de um desses cenários em um único ambiente, portanto, cada cenário normalmente requer um ou mais ambientes dedicados.

Para garantir que os resultados do teste sejam significativos e se apliquem à implementação de produção, é preciso que o conjunto de ambientes, usado durante o ciclo de vida de um aplicativo, atenda às seguintes regras, na medida do possível

  • Todos os ambientes são funcionalmente equivalentes. Ou seja, a arquitetura, as APIs e as versões de sistemas operacionais e bibliotecas são equivalentes e os sistemas se comportam da mesma forma em todos os ambientes. Essa equivalência evita situações em que os aplicativos funcionam em um ambiente mas falham em outro, ou um em que os defeitos não são reproduzíveis.

  • Ambientes que são usados para teste de desempenho e confiabilidade, preparo e produção são equivalentes de maneira não funcional. Ou seja, o desempenho, a escala, a configuração e a maneira como são operados e mantidos são iguais ou diferem apenas de maneiras insignificantes. Caso contrário, os testes de desempenho e preparo perderão o sentido.

É crucial que os ambientes usados para desenvolvimento e teste funcional sejam diferentes dos outros ambientes. Esta situação se encaixa bem com o padrão de ambiente híbrido:

  • Alcance equivalência funcional em todos os ambientes. Confie no Kubernetes como uma camada do ambiente de execução comum, que assegura a portabilidade da carga de trabalho e se abstrai das diferenças entre os ambientes de computação.

  • Execute ambientes para produção, teste e desempenho e testes de confiabilidade no ambiente de computação particular e garanta as equivalências funcional e não funcional.

  • Execute ambientes de desenvolvimento e testes funcionais na nuvem pública. Esses ambientes são funcionalmente equivalentes aos ambientes restantes, mas podem diferir em aspectos não funcionais, como desempenho.

Vantagens

A execução de cargas de trabalho de desenvolvimento e de testes funcionais na nuvem pública tem muitas vantagens:

  • É possível acelerar e eliminar ambientes automaticamente, conforme a necessidade. Por exemplo, é possível provisionar um ambiente inteiro para cada solicitação de confirmação ou recepção, permitir que os testes sejam executados e, em seguida, desmontá-lo novamente.

  • Ambientes de desenvolvimento e teste são frequentemente usados de maneira intermitente. É possível reduzir custos por meio da interrupção de instâncias de máquina virtual (VM, na sigla em inglês) durante períodos de inatividade ou por meio do provisionamento de ambientes apenas sob demanda.

  • A execução desses ambientes na nuvem pública ajuda a criar familiaridade e confiança na nuvem e nas ferramentas relacionadas, o que pode ajudar na migração de outras cargas de trabalho.

Práticas recomendadas

Para implementar o padrão de ambiente com sucesso, considere as seguintes recomendações:

  • Use a topologia espelhada para impedir que sistemas de ambientes distintos se comuniquem uns com os outros. Como os sistemas não precisam se comunicar entre ambientes, não é necessário estabelecer uma identidade comum.

  • Para manter a portabilidade das cargas de trabalho e se abstrair das diferenças entre ambientes, use contêineres e Kubernetes, mas esteja ciente dos limites da portabilidade da carga de trabalho.

  • Garanta que os processos de CI/CD sejam consistentes em todos os ambientes de computação e que o mesmo conjunto exato de binários, pacotes ou contêineres seja implantado nos vários ambientes.

  • Para implantar, configurar e operar cargas de trabalho, estabeleça uma cadeia de ferramentas comum, que funcione em ambientes de computação. O uso do Kubernetes fornece essa consistência, exceto por algumas pequenas diferenças em como você se conecta ou se autentica em clusters que estão sendo executados em diferentes ambientes de computação.

  • Ao usar o Kubernetes, use um sistema de CI, como o Jenkins, para implementar um canal de implantação que implante em clusters e funcione em vários ambientes. Você também pode executar o próprio Jenkins no Google Kubernetes Engine (GKE).

  • Use as mesmas ferramentas para login e monitoramento em todo o GCP e em ambientes de nuvem atuais. Avalie o uso de sistemas de monitoramento de código aberto, como o Prometheus. Se as cargas de trabalho de teste e produção forem gerenciadas por diferentes equipes, o uso de ferramentas separadas pode ser aceitável, mas o uso das mesmas ferramentas pode ajudar a reduzir o esforço e a complexidade do treinamento.

  • Ao escolher serviços de banco de dados, armazenamento e mensagens, use produtos que tenham um equivalente gerenciado no GCP. A confiança nos serviços gerenciados ajuda a diminuir o esforço administrativo de manter os ambientes de desenvolvimento e teste. A tabela a seguir mostra quais produtos da GCP são compatíveis com produtos OSS comuns.

Produto OSS Compatível com o produto GCP
Apache HBase Cloud Bigtable
Apache Beam Cloud Dataflow
Apache Hadoop Cloud Dataproc
MySQL, PostgreSQL Cloud SQL
Redis Cloud Memorystore
Sistema de arquivos de rede (NFS, na sigla em inglês) Cloud Filestore
JMS, Kafka Cloud Pub/Sub

Padrão de continuidade de negócios híbrido/várias nuvens

O ideal é que os sistemas essenciais sejam configurados para que sejam resilientes durante um desastre. Ao replicar sistemas e dados em várias regiões geográficas e evitar pontos únicos de falha, é possível minimizar os riscos de um desastre natural que afete a infraestrutura local. No entanto, essa abordagem não trata do risco de interrupções causadas por erros humanos ou defeitos de software. Portanto, é crucial também ter um plano de recuperação de desastres (DR, na sigla em inglês) que assegure a recuperação dos seus sistemas dentro de limites de tempo aceitáveis e com perda mínima de dados, caso ocorram outros tipos de desastre.

Uma parte essencial do planejamento de DR é fazer o backup de dados em um local geográfico diferente com frequência para minimizar o objetivo do ponto de recuperação (RPO, na sigla em inglês). Além disso, manter sistemas frios, mornos ou quentes em espera em um segundo local pode ajudar a minimizar o objetivo de tempo de recuperação (RTO, na sigla em inglês).

Quando você executa sistemas essenciais em um data center central, uma abordagem de DR é manter os sistemas de reserva em um segundo data center, situado em uma região diferente. Uma abordagem mais econômica, entretanto, é usar um ambiente de computação baseado em nuvem pública para fins de failover, que é a ideia por trás do padrão híbrido de continuidade de negócios.

padrão híbrido de continuidade de negócios

Uma variante menos comum (e raramente necessária) desse padrão é o padrão de continuidade de negócios de várias nuvens, em que o ambiente de produção usa um provedor de nuvem e o ambiente de DR usa um provedor de nuvem diferente. Ao implantar cópias de cargas de trabalho em vários provedores de nuvem, é possível aumentar a disponibilidade além do que uma implantação de várias regiões oferece.

Vantagens

Há muitas vantagens no uso da nuvem pública para continuidade de negócios:

  • Como o GCP tem várias regiões para escolha, é possível usá-lo para fazer backup ou replicar dados para um site diferente, no mesmo continente ou até mesmo para um site em um continente diferente.

  • As instâncias de VM interrompidas geram apenas custos de armazenamento e são substancialmente mais baratas do que as instâncias de VM que estão em execução, para que você possa minimizar o custo de manutenção de sistemas em espera frios.

  • O modelo de pagamento por uso do GCP garante que você pague somente pelo armazenamento e pela capacidade de computação que realmente usa, além de poder aumentar ou diminuir o ambiente de DR conforme necessário.

Práticas recomendadas

Quando você estiver usando o padrão de continuidade de negócios, tenha em mente as seguintes práticas recomendadas:

  • Crie um plano de recuperação de desastres que documente sua infraestrutura, juntamente com os procedimentos de failover e recuperação.

  • Com base no seu RPO e RTO, decida se o backup de dados no GCP é suficiente ou se é necessário manter sistemas em espera frios, mornos ou quentes. Consulte o guia de planejamento de recuperação de desastres para ver cenários comuns e dicas para implementá-los no GCP.

  • Quando você estiver executando apenas backups de dados, use a topologia de handover. Caso contrário, pense na topologia espelhada.

  • Minimize dependências entre sistemas que estão sendo executados em ambientes distintos, especialmente quando a comunicação é tratada de maneira síncrona. Essas dependências podem diminuir o desempenho e a disponibilidade geral.

  • Se você replicar dados bidirecionalmente entre ambientes, poderá ficar exposto ao problema do cérebro dividido. Nesse problema, se a comunicação entre os dois ambientes for interrompida, os sistemas de ambos os lados poderão concluir que o outro ambiente ficou indisponível. Os sistemas podem concluir que eles têm acesso exclusivo aos dados, levando a modificações conflitantes. Para evitar essa divisão, recomenda-se a adição de um terceiro ambiente de computação. Essa abordagem permite que um sistema que esteja confiando na replicação de dados verifique se há quorum, antes de concluir que a modificação de dados é segura. Como alternativa, é possível permitir que as modificações de dados conflitantes sejam reconciliadas, após a restauração da conectividade.

  • Garanta que os sistemas de CI/CD e os repositórios de artefatos não se tornem um ponto único de falha. Quando um ambiente não está disponível, é preciso que você possa implantar novas versões ou aplicar alterações de configuração.

  • Como os dados que são trocados entre os ambientes podem ser confidenciais, verifique se toda a comunicação é criptografada usando túneis VPN, TLS ou ambos.

  • Quando você estiver usando sistemas em espera, garanta a portabilidade das cargas de trabalho para que os sistemas permaneçam consistentes em todos os ambientes. Avalie o uso de contêineres e Kubernetes.

  • Integre a implantação de sistemas em espera ao seu processo de CI/CD. Essa integração ajuda a garantir que as versões e configurações do aplicativo sejam consistentes entre os ambientes.

  • Ao usar sistemas em espera quentes, use balanceadores de carga para criar um failover automático, mas lembre-se de que os balanceadores de carga também podem falhar. Como precaução, configure seu DNS de maneira que possa redirecionar os usuários para os sistemas em espera, no caso de um desastre. Use um TTL razoavelmente curto para garantir que as alterações de DNS sejam propagadas rapidamente e faça uso do SLA de 100% de tempo de atividade, fornecido pelo Cloud DNS.

  • Para DR, avalie soluções de parceiros, como CloudEndure, Actifio e Commvault.

Bursting de nuvem

Aplicativos da Internet, especialmente aqueles voltados para os usuários, podem passar por flutuações extremas no uso. Embora a maioria dos aplicativos corporativos não enfrente esse desafio, muitas empresas precisam lidar com um tipo diferente de carga de trabalho em bursts: jobs em lote ou CI/CD.

É possível acomodar cargas de trabalho em bursts em um ambiente de computação clássico, baseado em data center, ao provisionar recursos em excesso, mas essa abordagem não é rentável. Com jobs em lote, é possível otimizar a utilização expandindo a execução em períodos de tempo mais longos. No entanto, se os jobs forem mais urgentes, não será prático atrasá-los.

A ideia do padrão de bursting de nuvem é usar um ambiente de computação particular para a carga de valor de referência e usar bursts na nuvem temporariamente quando precisar de capacidade extra.

padrão de bursting de nuvem

Um requisito importante para cenários de bursting de nuvem é a portabilidade da carga de trabalho. Ao permitir que as cargas de trabalho sejam implantadas em vários ambientes, é preciso que você se abstraia das diferenças entre os ambientes.

O padrão de bursting de nuvem se aplica a cargas de trabalho interativas e em lote. No entanto, ao lidar com as cargas de trabalho interativas, você precisa determinar como distribuir solicitações entre ambientes:

  • É possível rotear as solicitações de usuário recebidas para um balanceador de carga que é executado no data center atual e, depois, fazer com que o balanceador de carga distribua as solicitações pelos recursos locais e na nuvem. Essa abordagem exige que o balanceador de carga ou outro sistema em execução no data center atual também monitore os recursos alocados na nuvem e inicie a ampliação ou redução automática dos recursos.

    imagem

    Por um lado, usando essa abordagem, você tem opção de desativar todos os recursos da nuvem durante períodos de baixa atividade. Por outro lado, a implementação de mecanismos para controlar os recursos pode exceder a capacidade das soluções de balanceador de carga disponíveis no mercado e, portanto, aumentar a complexidade geral.

  • Como alternativa, encaminhe as solicitações para o GCP primeiro e depois as distribua entre os ambientes. Como os balanceadores de carga do GCP oferecem suporte a balanceamento e escalonamento automático apenas entre os recursos do GCP, é necessário combinar um balanceador de carga do GCP com outros mecanismos de balanceamento de carga personalizados, para facilitar a distribuição de solicitações. Mais uma vez, essa abordagem cria mais complexidade.

    O balanceamento de carga usando o DNS round-robin não é prático se você pretende desligar todos os recursos no GCP durante períodos de baixa demanda. Como as atualizações de DNS tendem a se propagar lentamente, o uso do DNS para balanceamento de carga faz com que os usuários corram o risco de serem encaminhados para o GCP quando não houver recursos disponíveis para processar suas solicitações.

Diante desses desafios, o bursting de nuvem geralmente é melhor em cargas de trabalho em lote do que em cargas de trabalho interativas.

Vantagens

Veja as principais vantagens deste padrão de arquitetura:

  • O bursting de nuvem permite que você reutilize os investimentos atuais em data centers e ambientes de computação particulares. Essa reutilização pode ser permanente ou estar em vigor até que o equipamento atual seja substituído. Nesse ponto, talvez você deva pensar em uma migração completa da nuvem.

  • É possível aumentar a utilização e a rentabilidade dos seus ambientes de computação particulares, porque você não precisa manter o excesso de capacidade para atender às demandas de pico.

  • O bursting de nuvem permite que os trabalhos em lote sejam executados em tempo hábil, sem a necessidade de provisionamento excessivo de recursos de computação.

Práticas recomendadas

Ao implementar o bursting de nuvem, tenha em mente as seguintes práticas recomendadas:

  • Use a topologia em malha para garantir que as cargas de trabalho em execução na nuvem possam acessar os recursos da mesma maneira que as cargas de trabalho em execução em outros ambientes de computação. Se as cargas de trabalho permitirem, conceda o acesso somente da nuvem ao outro ambiente de computação, e não o contrário.

  • Para minimizar a latência da comunicação entre os ambientes, escolha uma região do GCP e um local de interconexão que estejam geograficamente próximos ao seu ambiente de computação particular.

  • Ao usar o bursting de nuvem apenas para cargas de trabalho em lote, reduza a superfície de ataque à segurança mantendo particulares todos os recursos do GCP. Assim, você impede qualquer acesso direto da Internet a esses recursos.

  • Para tarefas que não sejam executadas por mais de 24 horas e não sejam altamente essenciais em termos de tempo, considere o uso de instâncias de VM preemptivas, que são substancialmente mais baratas do que as instâncias comuns de VM. O pré-requisito é que, se a VM em que uma tarefa estiver sendo executada passar por uma interrupção forçada, é preciso que o sistema possa reiniciar a tarefa automaticamente.

  • Use contêineres para conseguir portabilidade de cargas de trabalho. Para cargas de trabalho em lote com muitos recursos, é possível implantar diretamente esses contêineres em VMs do Compute Engine e usar um grupo de instâncias gerenciadas para escalonar o número de VMs. No caso de cargas de trabalho interativas ou diversificadas e que usem menos recursos, também é possível usar o Google Kubernetes Engine (GKE) em combinação com o escalonamento automático de cluster para implantar esses contêineres. Observe, no entanto, que o GKE exige que pelo menos um nó por zona esteja em execução o tempo todo.

  • Monitore qualquer tráfego enviado do GCP para um ambiente de computação diferente. Esse tráfego está sujeito a cobranças de saída.

  • Como os dados que são trocados entre os ambientes podem ser confidenciais, verifique se toda a comunicação é criptografada usando túneis VPN, TLS ou ambos.

  • Para cargas de trabalho com uso intensivo de armazenamento, pense na integração com uma solução de armazenamento híbrida, como Cloudian, ClearSky, Avere vFXT, Egnyte ou SwiftStack.

  • Use o padrão de bursting de nuvem para dimensionar dinamicamente um sistema de CI. Ao usar o Jenkins, use o plug-in do Google Compute Engine para gerenciar e fazer o escalonamento automático das instâncias do Jenkins no Compute Engine.

  • Estabeleça uma identidade comum entre ambientes para que os sistemas possam se autenticar com segurança entre os limites do ambiente.

A seguir

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…